[ppml] Policy Proposal: IPv6 Policy Housekeeping

[Leo Bicknell]

In a message written on Wed, Aug 22, 2007 at 05:04:56PM -0400, Azinger, Marla wrote:
> - I cant support this until the things that are to be taken out
>   have a place to go like the creation of NPOG (Number Policy Operational
>   Guidelines).

I would humbly suggest several of these sections have no place in any
document produced by ARIN.

For instance the 6.1.1 "Overview" section is an introduction to a
stand alone document that no longer exists, and does not make sense
as a NRPM or NPOG item.

It may be worth trying to separate things worthy of the NPOG and things
not, though.

> -Change I.  Make this a separate proposal due to it removing a
> /48 as a specification.  In fact take it out of this proposal and
> let the other proposal(Definition of known ISP and changes to IPv6
> initial allocation criteria) that was submitted address this issue.

This problem was actually created by 2005-8, which can be found at
http://www.arin.net/policy/proposals/2005_8.html

That proposal specifically addressed that it was ok to allocate
/56's to customers.  I believe ARIN staff (although it may have been a
member of the public) stood up at the last meeting and pointed out that
6.5.1.1.d states:

] be an existing, known ISP in the ARIN region or have a plan for making
] at least 200 /48 assignments to other organizations within five years.

Prompting the question: If you came to ARIN with a plan to allocate
250 /56 customers, does that meet the requirement of 6.5.1.1.d.
Literally by the text it does not, meaning someone with 250 /56
customers is either forced to give them all a /48 (which would be
allowed), or not receive IPv6 address space at all.

My concern with letting Kevin Loch's proposal address this problem
is that it is a side effect of his policy.  His policy is about
defining the term "existing known ISP", and it is only as a side
effect of that he rewrites 6.5.1.1.d.  People may well want the
clarification in Change I (200+ /56 customers is good enough) without
wanting his additional criteria that the requester must already
have space, and must have at least a /23 of IPv4, or a /44 of IPv6
already.

That said, I wouldn't put up a lot of resistance to a different course
of action.

> -Change H.  I don't support removing this.  I suggest relocating
> it to 6.5.1.2 because the wording is more clarifying in an example
> manner than what is currently written in 6.5.1.2 already.

] 6.5.1.2:
] 
] Organizations may qualify for an initial allocation greater than /32 by
] submitting documentation that reasonably justifies the request. If so,
] the allocation size will be based on the number of existing users and
] the extent of the organization's infrastructure.

] 6.4.4:
] 
] Where an existing IPv4 service provider requests IPv6 space for
] eventual transition of existing services to IPv6, the number of present
] IPv4 customers may be used to justify a larger request than would be
] justified if based solely on the IPv6 infrastructure.

Really?  You think the second sentence of 6.5.1.2 is harder to
understand that 6.4.4?

I would be more inclined to put it in the NPOG, but could live with it
in 6.5.1.2 if people feel that's better.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070822/0f3ae983/attachment.sig>