<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Moin,<br>
<br>
am 23.03.2017 um 19:34 schrieb Martin Huněk:<br>
</div>
<blockquote cite="mid:4386755.pjWc2apoCa@hunator-ntb.site"
type="cite">Let say that, end user (MNT) would be able to indicate
that ASN should be hidden from the BGP and provide remarks for a
reason (IXP or whatever) - mandatory.</blockquote>
<br>
Sorry, but as a public ASN is to serve public inter-AS-uses, why
even think about private usage of a public resource? If you use a
public AS internally only, you should switch to a private AS.<br>
<br>
<br>
<div class="moz-cite-prefix">Am 23.03.2017 um 18:26 schrieb Hank
Nussbacher:<br>
</div>
<blockquote
cite="mid:70c81c4b-6f95-8d42-5c7e-95bed5df8ae6@efes.iucc.ac.il"
type="cite">
<div class="moz-cite-prefix">On 23/03/2017 14:18, Laurens
Hoogendoorn wrote:<br>
</div>
<blockquote
cite="mid:9570203a-051f-0c92-64c9-41713110a2c5@ripe.net"
type="cite"> Our Proposal<br>
[…]<br>
<br>
</blockquote>
Very often, companies get bought or merge and then get bought out
again.<br>
A company that received an ASN 15 years ago and hasn't updated
their whois and isn't announcing the ASN will be difficult to
track down.</blockquote>
Well, so what? If the ASN isn't used where it counts, why should it
stay assigned to an organization that clearly doesn't care at all
(or, for that matter, exists)?<br>
<br>
<br>
Am 23.03.2017 um 13:18 schrieb Laurens Hoogendoorn: <br>
<blockquote type="cite">There are a number of legitimate reasons why
an ASN might not be advertised in the routing system. <br>
</blockquote>
<br>
Care to list at least a few?
<a class="moz-txt-link-freetext" href="https://www.ripe.net/publications/docs/ripe-679">https://www.ripe.net/publications/docs/ripe-679</a> looks rather
straightforward — and against hidden usage of assigned ASNs?<br>
<br>
<blockquote type="cite">
<h3>2.0 Assignment Criteria</h3>
<p class="western">In order to help decrease global routing
complexity, a new AS Number should be used only if a new
external routing policy is required, see <a
href="ftp://ftp.ripe.net/rfc/rfc1930.txt">RFC1930</a>.</p>
<p class="western">A network must be multihomed in order to
qualify for an AS Number.</p>
<p class="western">When requesting an AS Number the routing policy
of the Autonomous System must be provided. The new unique
routing policy should be defined in RPSL language, as used in
the RIPE Database.</p>
</blockquote>
<br>
So, you need a "new" *external* routing policy to receive a (public)
ASN. If your ASN does not show up in the global routing anymore, you
obviously lost the need for that '"new" *external* routing policy',
no?<br>
<br>
While I don't see any need to reclaim "virtually unused" ASNs since
the protocol got extended to 32 bits, I don't see why there should
be any fuzz about those ASNs not seen in the public routing tables
either. Define January 1st and July 1st of each year as checkpoint
dates, if an ASN isn't present in global routing of IPv4 and IPv6 on
two consecutive checkpoint dates, it's scheduled for unassignment
after the next checkpoint date. Send out appropriate information
based on whois data *once*, put the AS on a red list on the RIPE
website for these six months. No reaction: it's free to go, end of
story.<br>
<br>
Regards,<br>
-kai<br>
<br>
</body>
</html>