[arin-ppml] ARIN's Authority - One view (was: Re: LRSA concerns)
Milton L Mueller
mueller at syr.edu
Sun Aug 24 11:13:47 EDT 2008
I disagree. ARIN should focus on efficient and appropriate management of
the scarcity of IPv4 resources. Neither you, nor I, nor ARIN knows when
or even if a migration will occur. All policies should be based on
acceptance of that fact, and seek to manage both v4 and v6 resources as
effectively and efficiently as possible.
> -----Original Message-----
> I would like to see ARIN focus on the end-game of IPv4 and the
> IPv6, both through policy and press. I think all of the efforts to
> manipulate and control IPv4 space are, as Randy put it, just
> deck chairs on the Titanic, and presents a picture to the public that
> are ways to artificially extend the life of IPv4. It would be better
> ARIN said "IPv4 is on its way out, we'll manage what we have left, but
> not going to work at extending its natural life."
> On 8/23/08 8:59 AM, "John Curran" <jcurran at istaff.org> wrote:
> > On Aug 23, 2008, at 10:40 AM, William Herrin wrote:
> >> What's more, the presentations made to gain the community consensus
> >> that led to NCR-9218742's amendment 6 repeatedly promised that what
> >> came to be known as the legacy registrations would remain untouched
> >> ARIN except to provide whois and rdns services.
> >> http://rip.psg.com/~randy/970414.fncac.pdf is was such a
> >> made to the FNC in support of ARIN's formation. See page 9,
> >> specifically: "Current and old allocations and their DNS will be
> >> maintained with no policy changes"
> > You're right! That presentation was made after adoption of RFC
> > which specifically calls for invalidation of existing assignments
> > are no longer needed.
> > No change to address management policy was implied by creation of
> > the same address blocks that were obtained via US government
> > so that one could to participate in the Internet and Internet
> > development were already covered by this policy in place at the
> >> Inclusion of that statement was no mistake. "The Community"
> >> on it.
> > Correct!
> >> We're left with: no explicit grant of authority over the legacy
> >> registrations, and the historical documents that do talk about it
> >> suggest that the intention was to -not- grant such authority.
> > I'm sorry, why did you expect such? Your allocations were always
> > under the authority of the IANA and based on your need for address
> > space.
> > The fact that we corrected the address subnet boundaries to allow
> > a better fit (CIDR) was the only major change, and if you happen to
> > been sitting on a "class A" or class B address block, it sure would
> > been nice if you returned the excess space which was provided to you
> > due to this technical flaw in the original block allocation sizes.
> > reasons that some organizations did not are varied, and mostly
> > to
> > pain of renumbering, sparse allocation, and similar technical issues
> > [ref: <http://www.faqs.org/rfcs/rfc2071.html>]
> >>> Frankly, I'd rather not think about this, and hope that this
> >>> particular chain of succession remain nothing more than an
> >>> interesting historical tidbit best ignored.
> >> You'll get no argument from me on this point.
> >> However, when v4 depletion is reached you'll find yourself under
> >> pressure to reclaim the fallow address space, however little it may
> >> be. To do so successfully you'll need to first normalize relations
> >> with the registrants whose legacy space is still in service. The
> >> two ways you do that without creating a godawful mess for yourself
> >> to either seek an explicit grant of authority from the USG that
> >> supersedes the old community agreements
> > The first direction above (reliance upon "authority") doesn't follow
> > principles of industry self-governance, and should be avoided at all
> > costs.
> > There's an fairly large "mess" whether one relies upon existing
> > delegation
> > of authority or whether one attempts to refresh it in some manner.
> >> -OR- convince the vast majority of legacy registrants to
> >> sign contracts with ARIN so that when you declare the rest of the
> >> space
> >> dead and expired there's no one left to raise a stink.
> > The second direction above is the correct one (IMHO), although I
> > there'll always be someone left to "raise a stick" and ARIN must
> > prepared
> > accordingly if we're directed by the community to do anything with
> > respect
> > to legacy address reclamation.
> >> ..
> >> ARIN's authority and autonomy derive from the *strong* consensus of
> >> the community it serves. That autonomy will end when ARIN places
> >> itself at the center of a dispute that results in a fall to weak
> >> consensus and the defection of any significant minority of that
> >> community.
> > We aim to please. If the consensus of the Internet community in the
> > ARIN
> > region is to undertake some action here, then we will very likely do
> > It should be made very clear that ARIN serves the entire Internet
> > community
> > in the ARIN region, and not simply those who have taken the time and
> > effort
> > to participate as members. It is that reality which 1) causes ARIN
> > undertake more outreach than might otherwise be expected, and 2)
> > the
> > measurement of consensus for the "ARIN region Internet community"
> > difficult.
> > /John
> > (my opinions only; 100% of the electrons used in this email are from
> > recycled matter)
> > _______________________________________________
> > 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.
> 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:
> Please contact info at arin.net if you experience any issues.
More information about the ARIN-PPML