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

[Martin Hannigan]

On Thu, Jul 23, 2009 at 12:08 PM, Jason Schiller<schiller at uu.net> wrote:
> OK, first off let me say I am not arguing for a petition, but rather
> trying to ask a question to see if a debate stirs up.
>
> (I often try to ask the hard questions when discussing policy because I
> think they need to be considered and addressed.  Unfortunately I think
> most people believe this makes me in favor or opposed to a particular
> proposal...  Mr chairman, I am neither in favor nor against this proposal
> until debate around my questions is discussed.)
>
> On Wed, 22 Jul 2009, Owen DeLong wrote:
>
>> On Jul 22, 2009, at 1:53 PM, Martin Hannigan wrote:
>>
>> 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?
>
> The original (now current) 2005-9 policy intended to set dates when ARIN
> would:
>
> 1. start assigning 32 bit ASNs by request and 16 bit by default
> 2. start assigning 32 bit ASNs by default and 16 bit by request
> 3. make no distinction
>
> The rationale included:
>
> 1. allow providers to get a 32 bit ASN to enable them to prepare for
> supporting 32 bit ASNs prior to the depletion of the 16 bit ASNs.
>
> 2. send a message to vendors that there is a real date when 32 bit ASNs
> will need to be supported
>
> 3. Create some certainty about the date when 32 bit ASNs will become
> common (and hence a reasonable expectation the providers will be ready to
> support it by then).
>
> -----
>
> Marla's abandoned proposal 87 to "Extend 16 bit ASN Assignments" intended
> to push the date where ARIN makes no distinction out by one year.  This is
> to address the concern that more time is needed for the vendors and / or
> providers to be able to support 32 bit ASNs in a real way.
>
> -----
>
> The current suggested implementation plan does address the concern of
> extending the date when vendors and providers have to support 32 bit ASNs
> in a real way.
>
> However, it negates much of the original intent the now current policy
> 2005-9.  It removes the date where it is reasonable to expect that vendors
> and providers should support 32 bit ASNs.  And based on my read of this
> interpretation, post 2010 providers will not be able to request a higher
> valued ASN (over the 16 bit boundary) in order to test and prepare for
> supporting 32 bit ASN.  In other words I can get a 32 bit ASN through
> December and test, but if I don't feel the need to test prior to December,
> then my next chance to get one is whenever we run out of 16 bit ASNs.
>
> -----
>
> So the question is does the community still feel we need to send a message
> to the vendors and the providers that they need to support 32 bit ASNs in
> a real way?
>
> Does the community feel there is value in arbitrarily setting a date to
> aid in setting a reasonable expectation of when vendors and providers
> need to be able to support 32 bit ASNs in a real way?
>
> Or is vendor support and provider support sufficiently advanced that is is
> no longer a concern?
>
> If vendor support and / or provider support is not sufficiently advanced,
> is the community confident that they will be on the date that 16 bit ASNs
> deplete?
>
> Does the community feel that removal of the date and giving out low
> numbered 32 bit ASNs will slow adoption of 32 bit ASNs as the "problem of
> needing to support 32 bit ASNs" will be out of sight and out of mind, and
> then suddenly and surprisingly re-emerge on some unknown date when the
> lowest valued 32 bit ASN clicks over that 16 bit boundary?
>
> Does the community think there is value in being able to request a higher
> valued (over the 16 bit boundary) 32 bit ASN when smaller valued ASNs are
> available to allow providers to test and prepare for supporting 32 bit
> ASNs?
>
> ----
>
> The AC stated, "Proposal #87: Extend 16 bit ASN Assignments has been
> abandoned by the AC because the ARIN staff has now made an
> implementation plan to combine both sets of numbers into one pool, and
> issue in numerical order starting with the lowest numbers first
> (starting in January 2010). With this plan in place the intention of
> this proposal is addressed and the need for this proposal no longer
> exists."
>
> -----
>
>> 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.
>>
>
> I think the question is rather if the community feels staff's recent
> interpretation of the policy is in line with the original intent, and if
> not, then a new proposal needs to be floated to give clear guidance to
> staff.  That new proposal needs to also address Marla, et al, concerns
> about extending the life of 16 bit ASNs to some extent.


I had intended to follow up with that and you did a superb job in a
much more detailed fashion. This was my original point in the earlier
message to Scott as well when I said that I felt that the "original
intent" had not been accounted for. The withdrawal of Marla's proposal
is fine by me; Marla doesn't need my protection. Administratively
addressing a proposal to modify a policy that had already reached
consenus to condense the workload  = FAIL in my [humble] opinion.

Best,

Martin