[arin-ppml] Advisory Council Meeting Results - July 2009

[Owen DeLong]

On Jul 22, 2009, at 1:53 PM, Martin Hannigan wrote:

> On Tue, Jul 21, 2009 at 4:09 PM, Owen DeLong<owen at delong.com> wrote:
>>> I can try, and I'm sure someone will correct me if I'm wrong...
>>>
>>> Up until January 1 2010, ARIN distinguishes between 2-byte and 4- 
>>> byte
>>> ASNs, and lets you have a 2-byte if you need it, but gives out 4- 
>>> bytes
>>> otherwise, to spur adoption.
>>>
>>> After January 1 2010, ARIN ceases to make any distinction between  
>>> 2-byte
>>> and 4-byte ASNs.  Instead, they simply give out ASNs as they  
>>> always have,
>>> working up from the bottom.  At first, the ASNs given out will be  
>>> <64k.
>>>  Eventually, when that block of ASNs is used up, they'll move on  
>>> to higher
>>> numbers >64k.  Presumably by then everyone with a growing network  
>>> will have
>>> rolled out code to support 4-byte ASNs.
>>
>> More importantly, by then, it really doesn't matter since there  
>> aren't any
>> 16-bit ASNs left to give out.
>
>
> How's that? There is likely some churn. If anything, it significantly
> pushes out 4 byte allocations since this seems to imply that as long
> as there are 2 byte ASN's they will be allocated.
>
Right.  It will push additional 4-byte allocations (after 2010) out by
some amount of time (not much, IIRC). Until January, 2010, the
distinction will remain and you can apply for whichever type of ASN
you prefer.

Is that a problem? Why?

As to churn, I suspect ARIN will not rapid-cycle the limited churn
in ASNs <65536.

> This is a good candidate for a petition. We lost transparency by the
> abandonment and the second interpretation of the intent of the
> original policy. It's possible that there are also technical
> implications to recycling (if that is the intent) on a rapid basis
> some previously utillized ASN's. I admit, I can't really think of
> anything significant besides number reputation. That could be enough
> though. I'm honestly not sure.
>
I don't know why you think there was a loss of transparency.

The author's statement about why the policy was needed was
rendered moot by staff's clarification about how things would be
handled in the next phase.

If you still feel that this policy is useful or necessary in light of  
staff's
clarification of how they would process requests after 1/1/2010,
please do petition, and, please elaborate on why you think the
policy is still needed.

Owen