[arin-ppml] Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension - IAB comment

[Owen DeLong]

I believe there may be a fifth option.

I believe that the ISPs who need this space might be able to  form a consortium and
use this as a standard justification to have the IPs registered to the consortium
as an organization. It would be up to the consortium after that whether they
expressed a willingness for non-members to make duplicate use of their
address space for this purpose or not.

John Curran, could you please comment on whether such a request from
a consortium for an allocation or assignment could be processed within
staff interpretation of existing policy?

Thoughts?

Owen

On Jun 27, 2011, at 10:43 AM, William Herrin wrote:

> On Sat, Jun 25, 2011 at 11:11 PM, John Curran <jcurran at arin.net> wrote:
>>> In keeping with the spirit of RFC 2860 with respect to the assignment
>>> of specialized address blocks, ARIN Staff will consult with the IANA and
>>> the IAB regarding implementation of this draft policy.
>> 
>>> == A Procedural Issue: ARINA 2011-005 and RFC2860 section 4.3 ==
>>> 
>>> The IAB honors and values the division of responsibilities as
>>> documented in RFC 2860 section 4.3. That section forms the basis for
>>> Unicast address allocation via ICANN through the RIR system.
>>> 
>>> Policy proposal 2011-005 is not a regular proposal in the sense that
>>> it adheres to Unicast space. In contrast, it allows for an allocation
>>> of addresses for special and global use very similar to, and almost
>>> indistinguishable from, RFC1918 local addresses. Because of the impact
>>> beyond the ARIN region the management (i.e. creation
>>> and subsequent changes) of such reservation should be global and RFC2860
>>> puts the management responsibility with the IETF.
>>> 
>>> The IAB believes that the adoption by ARIN would be in conflict with the
>>> provisions in RFC2860 and would set a bad precedent: Setting aside
>>> special addresses should be done within the existing process, i.e. by
>>> the IETF.
>>> 
>>> If there is consensus for 2011-005 in the ARIN region we would be
>>> happy to work with you to resubmit the proposal to the IETF and, as
>>> usual, have the IESG judge consensus. This would include our reaching
>>> out to other RIRs to have members of their community provide input on
>>> this proposal. Clear support from the various RIR communities might
>>> bring new insights into to the IETF, producing a level of support that
>>> was not present with the earlier drafts.
> 
> Hi Folks,
> 
> In light of the IAB's objection, it seems to me that the ARIN board
> has four options to consider:
> 
> 1. Submit an internet draft as the IAB requests, along with the
> implications of doing so.
> 
> 2. Implement 2011-5  as recommended by the AC and community, and over
> the IAB's objection.
> 
> 3. Abandon 2011-5. Proponents may make their case to the IETF.
> 
> 4. Implement 2011-5 as a temporary stopgap policy pending further IETF action.
> 
> 
> 
> 1. The case for complying with the IAB's request:
> 
> The Internet standards process works because of the cordial and
> cooperative atmosphere between the various NGOs and individual
> participants. The IETF is indeed the appropriate venue for global
> assignment of IP addresses to specific purposes as opposed to specific
> end users. However, we must observe that the IANA has insufficient
> unicast (class A, B or C) addresses available to award the IETF for
> the implementation of 2011-5's intended use.
> 
> Accordingly, ARIN should reserve the /10 that 2011-5 calls for and
> hold it unused while championing an RFC through the IETF's standards
> process that uses the /10 as contemplated in 2011-5. Upon publication
> of such an RFC, the /10 would be ceded to IANA for use with the RFC.
> Upon a failure to reach consensus within the IETF process, the /10
> would be returned to the ARIN free pool for general use.
> 
> 
> 2. The case for implementing 2011-5 over the IAB's objection.
> 
> a. ARIN's constituents have expressed a well defined, well supported
> and consensus need for addresses to be used similar like RFC1918 space
> but with the expectation that such space crosses the administrative
> boundary between ISP and end-user and should, thus, not be used by the
> end-user.
> 
> b. The IETF had the opportunity to act on these constituents' concerns
> but failed to take leadership citing, among other reasons, that it
> would deplete the pool of addresses available to the RIRs from IANA.
> 
> c. The ARIN region is satisfied with depleting its own address pool
> for this purpose.
> 
> d. The IAB's suggestion that the proposal be brought back to the IETF
> is rendered disingenuous by the fact that no addresses remain at the
> IANA for implementation.
> 
> e. Precedent exists for RIRs to unilaterally act on regional
> imperatives despite potentially global impact. Witness APNIC's
> abandonment of needs-based allocation.
> 
> Because of these points, ARIN has a moral duty to act on behalf of its
> constituents. Should the IETF desire to reclaim leadership in this
> matter, ARIN's open public policy process is available to all comers
> who may request that the addresses be reassigned to any RFC that is
> produced.
> 
> 
> 3. The case for abandoning 2011-5:
> 
> The IETF is the proper venue for a proposal like 2011-5. Such
> proposals were considered and rejected. 2011-5 is an end-run around
> around the proper process.
> 
> 
> 4. The case for 2011-5 as a stopgap pending IETF action:
> 
> ARIN constituents within the ARIN region have an immediate and
> pressing need for IP addresses to be used for the interior of multiple
> NAT translators. This need is not adequately served by the delay
> inherent in initiating a fresh proposal in the IETF's standards
> process, it is not adequately served by RFC1918 and it is poorly
> served by having every ISP use its own unique space allocated by ARIN.
> Due to the IETF's failure to act in a timely manner while addresses
> were still available to them from IANA, ARIN has a duty to act on its
> constituents' imperative.
> 
> Nevertheless, global assignment of addresses to purposes rather than
> registrants properly belongs with the IETF. ARIN should facilitate the
> IETF retaking the leadership on the matter by ending the ARIN-region
> policy and ceding the /10 address block back to IANA after the IETF
> debates, drafts and publishes an RFC that the board of trustees
> believes meets or exceeds ARIN constituents' expectations for these
> addresses.
> 
> 
> For your consideration,
> Bill Herrin
> 
> 
> 
> --
> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.