[arin-ppml] ARIN's Authority - One view (was: Re: LRSA concerns)

[Milton L Mueller]

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
adoption of
> IPv6, both through policy and press.  I think all of the efforts to
> manipulate and control IPv4 space are, as Randy put it, just
rearranging
> the
> deck chairs on the Titanic, and presents a picture to the public that
> there
> are ways to artificially extend the life of IPv4.  It would be better
if
> ARIN said "IPv4 is on its way out, we'll manage what we have left, but
> we're
> not going to work at extending its natural life."
> 
> Regards,
> 
> Mike
> 
> 
> 
> 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
by
> >> ARIN except to provide whois and rdns services.
> >> http://rip.psg.com/~randy/970414.fncac.pdf is was such a
presentation,
> >> 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
2050,
> > which specifically calls for invalidation of existing assignments
which
> > are no longer needed.
> >
> > No change to address management policy was implied by creation of
ARIN;
> > the same address blocks that were obtained via US government
auspices
> > so that one could to participate in the Internet and Internet
Protocol
> > development were already covered by this policy in place at the
time.
> >
> >> Inclusion of that statement was no mistake. "The Community"
insisted
> >> 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
made
> > 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
for
> > a better fit (CIDR) was the only major change, and if you happen to
have
> > been sitting on a "class A" or class B address block, it sure would
have
> > been nice if you returned the excess space which was provided to you
> > due to this technical flaw in the original block allocation sizes.
The
> > reasons that some organizations did not are varied, and mostly
related
> > 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
only
> >> two ways you do that without creating a godawful mess for yourself
are
> >> 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
the
> > 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
voluntarily
> >> 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
expect
> > 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
so.
> > 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
to
> > undertake more outreach than might otherwise be expected, and 2)
makes
> > the
> > measurement of consensus for the "ARIN region Internet community"
quite
> > 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.
> 
> _______________________________________________
> 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.