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

[Joe Maimon]

Owen,

Thanks for the excellent feedback. I suppose at this time I can wait and 
see if the AC wants to adopt the proposal and to work on it or if a 
rewrite is in order.

I'll give it some thought.

Joe

Owen DeLong wrote:
> On May 2, 2012, at 12:20 PM, Joe Maimon wrote:
>
>> 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?
>>
> I'm generally opposed to putting ARIN in the "custom license plate" business because I think there are other better higher priorities for number resource management.
>
>> But if dropping it is all it would take to win public support, its an easy loss.
>>
> Don't know about that. Certainly dropping it is a requirement to garner my support.
>
>>> 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.
>>
> I have no problem with policy enabling ARIN to operate a 4-octet wall of shame. However, if that is the intent, let's have the paragraph say that. I can't even parse what it says currently.
>
> I don't think ARIN knows why 4-octet ASN utilization is so low (in the ARIN region and uniquely in the ARIN region, btw).
>
>>> 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.
>>
> I would modify to remove the restriction from 8.2 transfers and set the limit at 48 months (if we're going to allow 8.3 transfers of ASNs at all which I still feel is a bad idea).
>
>>> 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.
>>
> Ah, but if we eliminate 5.2.3 as I suggested, that becomes inoperative.
>
>>> 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.
>>
> Move that statement to the rational. It's an operational concern, not a policy issue.
>
>>> 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?
>>
> A fair amount, actually. I don't think that there are many, if any unused or obsolete sections currently in the NRPM and there have been several proposals which have removed them just in my tenure so far on the AC (a little more than 4 years) and many more in the decade+ that I have been active in the policy process.
>
>> 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.
>>
> In the past, we have generally eschewed sunset clauses. As such, I don't think having one in this policy is particularly more desirable than any of the past cases where the community has opted not to put one in.
>
>> 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.
>>
> Then it should say that. The proposal for ASN transfers is (unfortunately) in last call, but, it has not been recommended to the board for adoption, let alone been adopted.
>
> Owen
>
>
>