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

[Jason Schiller]

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.

__Jason