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

[Mike Joseph]

Following up on-list for those that weren't present at the public policy
meeting this week.  I am satisfied that Owen has addressed most of my
concerns through the errata presented in the meeting.  I hope to review and
be able to support a final version of this proposal during last call.

-MJ

On Thu, Apr 7, 2011 at 1:07 PM, Owen DeLong <owen at delong.com> wrote:

>
> 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/20110414/7d073b76/attachment.htm>