[arin-ppml] ARIN-prop-168 Promote 4byte ASN Usage

[Joe Maimon]

Hey Owen,

Owen DeLong wrote:
> I could support this policy with the following changes:
>
> 5.2.2 Remove "AS Number or" from the first sentence.


To clarify, you are objecting to language that would allow an org to 
request a specific AS from ARIN, assuming it knows it is available.

Yes, this allows an org the chance to try and get an aesthetically or 
otherwise pleasing ASN they may not have otherwise.

Whats the harm in that?

But if dropping it is all it would take to win public support, its an 
easy loss.


>
> 5.2.3 I don't understand what causes are being rectified, so, this entire
> paragraph does not yet make sense to me. I would appreciate clarification
> from the author.


In the simplest case, it would allow ARIN to explain to the room at some 
future ppm why 4byte ASN utilization is so low, put the pages in the 
wiki, document and present to the community other potentially valid 
concerns, produce material that can be useful to parties involved in 
similar situations, etc...

Yes, this may allow ARIN to operate a 4byte wall of shame.

>
> 5.2.4 I would prefer to see a longer period.

Anything from 12-48 months is fine with me, personally.

However, consider that this restriction as written applies to both 8.2 
and 8.3 transfers.

>
> 5.2.5 I don't really see a purpose to this clause. I would delete it.


An organization that wants to transfer an ASN, but cannot because 5.2.4 
applies to it, has the option to exchange the ASN for a 5.2.1 which has 
no such restriction, should they wish to avail themselves of it.

I suppose some grace time for renumbering may not be a bad idea.


>
> 5.2.6 is a no-op. It should be removed.


Its there to prevent ARIN staff from concluding that in order to 
implement 5.2.2 they need to publish an entire list of available ASNs, 
which they may reasonably do so without making it explicitly non-dependent.


>
> 5.2.7 should also be removed. The policy can be retired by a proposal that
> 	achieves community consensus. There is no need for an auto-
> 	expiry process that is optional at the discretion of staff.


How much effort is expended on policy cleanup for unused sections?

Without active interest, I dont expect such a proposal to ever show up, 
unless the ARIN staff solicits one for disuse. So in that case, let them 
just remove it at that point.

Also not a pivotal aspect of the proposal.


>
> I don't believe this policy will do anything to achieve the objective stated
> in the title, however, perhaps that is because I cannot decipher 5.2.3.
> If the author manages to sufficiently clarify 5.2.3 and/or modify the policy
> such that it would demonstrably achieve the titled objective, I would
> support that objective.
>
> Otherwise, it just looks like an attempt to back-door ASN transfers which
> I oppose.
>
>
> Owen


The proposal was written with the expectation that directed ASN 
transfers are likely to be allowed via policy sometime soon, it is not 
intended to allow or disallow them on its own, except to add this 
additional restriction, applicable ONLY inasmuch as an ASN transfer is 
allowed, either via 8.2 currently or as 8.3 might be amended.

Best,

Joe