<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;background-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;">
<p>Chris's excellent question jogs my brain to ask a related-but-different question:</p>
<p><br>
</p>
<p>ARIN has traditionally had a large number of AS numbers (almost all 2-byte) in the "hold" bucket. These are ASNs which have been revoked for years due to non-payment and separation from the RSA. But they're still found in the DFZ. </p>
<p><br>
</p>
<p>Can't ARIN ask requestors who say they need 2-bytes if they'd be willing to accept a 2-byte ASN that may have route announcements present in the DFZ, and due to circumstances blah blah blah? It boils down to "we have 2-byte ASNs, but they're not quite as
clean as one might expect - is that ok?", because I'm pretty sure the answer will always be "HECK YEAH!" <span style="font-size: 12pt;">ASNs aren't quite like IP addresses in this context. There's no conflict I know of unless the new registrants tries
to directly exchange routes with the old registrant, which is mathematically highly improbable.</span></p>
<br>
<br>
<div style="color: rgb(0, 0, 0);">
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> arin-ppml-bounces@arin.net <arin-ppml-bounces@arin.net> on behalf of Chris Woodfield <chris@semihuman.com><br>
<b>Sent:</b> Monday, April 4, 2016 4:30 PM<br>
<b>To:</b> Adam Thompson<br>
<b>Cc:</b> arin-ppml@arin.net<br>
<b>Subject:</b> Re: [arin-ppml] 2-byte ASN policy</font>
<div> </div>
</div>
<div>
<div class="">Do we have information on how many 2-byte ASNs get returned, compared to the rate of requests for them? Is there a surplus? </div>
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Apr 3, 2016, at 11:36 AM, Adam Thompson <<a href="mailto:athompso@athompso.net" class="">athompso@athompso.net</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">IMO, 2-byte ASNs should simply be retired and not reallocated. "Solving the technical problem", as described in your email, is actually ensuring the perpetuation of a different technical problem.<br class="">
It's the same sort of thing as the IPv4 vs IPv6 --transition, but this time ARIN has an opportunity to at least avoid being part of the problem, even if it can't really be part of the "solution".<br class="">
Let's please not prolong this problem, too... even in central Canada, known for a paucity of upstream carriers, it's now commercially feasible to work around the 2-byte technical limitations.<br class="">
<br class="">
-Adam<br class="">
<br class="">
<br class="">
<div class="gmail_quote">On April 3, 2016 12:59:37 PM CDT, Andrew Dul <<a href="mailto:andrew.dul@quark.net" class="">andrew.dul@quark.net</a>> wrote:
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<pre class="k9mail">Hello,<br class=""><br class="">I am starting a new thread in PPML, as a follow up to the ARIN <br class="">suggestion and consultation which recently started regarding creating a <br class="">2-byte ASN waiting list.<br class=""><br class="">The original suggestion is here:<br class=""><br class=""><a href="https://www.arin.net/participate/acsp/suggestions/2016-04.html" class="">https://www.arin.net/participate/acsp/suggestions/2016-04.html</a><br class=""><br class="">ARIN opened a consultation on this suggestion on the arin-consult <br class="">mailing-list. This thread starts here for those who are not subscribed <br class="">to arin-consult.<br class=""><br class=""><a href="http://lists.arin.net/pipermail/arin-consult/2016-March/000713.html" class="">http://lists.arin.net/pipermail/arin-consult/2016-March/000713.html</a><br class=""><br class=""><a href="http://lists.arin.net/pipermail/arin-consult/2016-April/000722.html" class="">http://lists.arin.net/pipermail/arin-consult/2016-April/000722.html</a><br class=""><br class="">As the thread evolved it has been suggested that this issue should be <br class="">resolved via the policy development process rather than through a <br class="">suggestion.<br class=""><br class="">There are a number of questions that have been raised by this thread. I <br class="">am copying them here to continue the discussion on PPML.<br class=""><br class="">===<br class=""><br class="">Working problem statement: ARIN will receive 2-byte ASNs as returns <br class="">over time, and these ASNs have perceived or additional value to<br class="">organizations compared to 4-byte ASNs. How should ARIN allocate these <br class="">2-byte ASNs?<br class=""><br class="">===<br class=""><br class="">Should they be given to the next requester, regardless of technical need <br class="">for a 2-byte ASN? (What are the technical qualifications we should use <br class="">if there is a specific technical need? e.g. provides transit to more <br class="">than 1 ASN?)<br class=""><br class="">If there is really a technical need for 2-byte ASNs, shouldn't we <br class="">attempt to build an inventory of 2-byte ASNs?<br class=""><br class="">Should returns be held in reserve?<br class=""><br class="">Should ARIN hold them for some period of
time
before reallocating them?<br class=""><br class="">Should they be put up for auction to qualified organizations?<br class=""><br class="">Should they be given to the 1st organization on a wait-list for 2-byte <br class="">ASNs?<br class=""><br class="">Would an organization looking for a 2-byte ASN have the option to <br class="">receive a 4-byte ASN in the interim? If they did would they have to <br class="">return it?<br class=""><br class="">Should the waiting list be closed to organizations that already have a <br class="">2-byte ASNs?<br class=""><br class="">I and the AC would appreciate your comments on these questions so that <br class="">we can start to build a draft policy that best matches with what the <br class="">community would like to see implemented by ARIN.<br class=""><br class="">Thanks,<br class="">Andrew<br class=""><br class=""><br class=""><br class=""><hr class=""><br class="">PPML<br class="">You are receiving this message because you are subscribed to<br class="">the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" class="">ARIN-PPML@arin.net</a>).<br class="">Unsubscribe or manage your mailing list subscription at:<br class=""><a href="http://lists.arin.net/mailman/listinfo/arin-ppml" class="">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br class="">Please contact <a href="mailto:info@arin.net" class="">info@arin.net</a> if you experience any issues.<br class=""></pre>
</blockquote>
</div>
<br class="">
-- <br class="">
Sent from my Android device with K-9 Mail. Please excuse my brevity.</div>
_______________________________________________<br class="">
PPML<br class="">
You are receiving this message because you are subscribed to<br class="">
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" class="">ARIN-PPML@arin.net</a>).<br class="">
Unsubscribe or manage your mailing list subscription at:<br class="">
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" class="">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br class="">
Please contact info@arin.net if you experience any issues.</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
</body>
</html>