[arin-ppml] Support for ARIN Proposal 2011-3

[Owen DeLong]

On Apr 7, 2011, at 1:58 AM, Mike Joseph wrote:

> Owen, I do have a few questions and comments about this proposal:
> Your new section 6.5.4 simply indicates that 6.5.8 requirements and sizing shall be used for reassignment to end users.  However, this seems to conflict with the existing section 6.9.  This proposal doesn't seem to amend or delete 6.9, so can you speak to resolving that conflict?

The best answer I can give is that this appears to be an oversight on my part. Indeed, we should add the following
to the draft policy:

delete section 6.9

> This policy replaces all of 6.5.4, but doesn't substitute anything for 6.5.4.3.  That would leave operators with no way to justify assignments to their own infrastructure.

This also appears to be an oversight on my part. I wish you had spotted these before text freeze. I recommend
that we amend the draft policy to retain the original language from 6.5.4.3.
> You seem to want to eliminate the HD-ratio from policy, but this proposal doesn't modify various other parts of the NRPM which mention HD-ratio (such as 6.5.9 and the aforementioned 6.9; section 6.5.5 also uses HD-ratio, but 2010-14 already replaces it).  Moreover, it doesn't delete or modify 6.7, which spends much NRPM real-estate describing the HD-ratio at great length.

This proposal seeks to eliminate HD-ratio from ISP allocation policy. 6.5.9 would continue to use HD-Ratio
for now. 2010-14 eliminated it from end-user assignment policy. A future proposed update
to the community networks policy may replace HD-Ratio in 6.5.9 which would then eliminate the
dependency on 6.7 and should include deleting it. For the time being, those are intentionally not
tackled by this proposal. It is complicated enough as it is.
> Are you intending to remove the transition technology clause for subsequent allocations in section 6.5.2.1?  I ask because this proposal seems to have that effect, and yet this clause was only added a few months ago as part of the implementation of 2010-12.
No, the proposal was written prior to the adoption and implementation of 2010-12.  That language should
be carried over.
> I can't find any maximum allocation size defined in this proposal or current policy.  However, this proposed policy would have the potential to allocate very large blocks.  I would like to see language fixing the maximum size at a /16 or perhaps a /12.  It's just too risky to leave it completely open-ended.
I disagree. I think it would be very difficult for more than a handful of providers to make a credible case for /16s and
virtually impossible for anyone to make a case for a /12 under this policy. I'm not opposed to adding language
fixing the maximum, but, I think the risk of leaving it open ended is very nearly nil.

To wit, the easiest way to qualify for a /16 would be to require 16 bits for POPs and 16 bits of customers in your
largest POP. To get beyond that, you'd need to show that your largest POP contained more than 49,152
customers _AND_ that you had more than 49,152 POPs planned for deployment. I think that's a hard sell
for any but the very largest of service providers.

I think given the number of organizations likely to be pushing IPv6 forward between this meeting and the
next, it is worth advancing this policy through an extended last call with as many of the changes as can be
considered editorial in nature and not a substantial change to the policy intent and then using a separate
proposal to correct the remaining issues you have raised.

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110407/5a1226b2/attachment.htm>