[arin-ppml] ARIN Board consideration of IAB consultationresponse on 2011-5

John Santos JOHN at egh.com
Fri Jul 22 18:05:19 EDT 2011


I've been away for a couple of weeks, but it doesn't appear anyone has
responded to this...

On Fri, 8 Jul 2011, Owen DeLong wrote:

> 
> On Jul 7, 2011, at 7:40 AM, Mike Burns wrote:
> 
> >> John,
> >> 

> >> I want to thank you and the Board.  While i still support the intent
> >> of 2011-5, I think the Board is correct. 
> >> ===============================================
> >> David Farmer               Email:farmer at umn.edu
> >> 
> > 
> > +1
> > 

> > I think we are unfortunately bound to this decision by the MoU and
> > should not subject the idea of Internet self-governance to the stress of
> > feuding organizations at the level of IANA and IETF. 
> > I'm sure the Board members feel the pressure from the community but
> > made the right decision. 
> > I also have doubts about 154 for the same reason.
> > We engender discord with the IETF.
> 

I think Mike is referring to ARIN stepping on the IETF's toes by reserving
space and implicitly threatening to go it alone using it even if the IETF
ultimately decides to do nothing.

> 154 should not engender any discord with IETF, it seeks to have ARIN do
> what can be done
> within their process and continue to work within their process to
> achieve the desired result. 
> 
> > We engender discord with APNIC over their transfer policies.
> 
> Care to explain how 2011-5 or 154 have anything at all to do with APNIC
> or their transfer policies? 

I think Mike was listing other potential activities which might cause
discord among the various cooperating entities involved in Internet
governance, and advising against such, at least when avoidable.

> 
> If you're talking about other proposals, then, one could argue that
> APNIC's transfer policy has
> engendered discord with the other RIRs, since they currently stand alone
> as the only RIR to
> abandon needs-basis in their transfer policy.
> 

Agree.

> > We engender discord with all other registries when we consider
> > regional hoarding policies. 
> 
> I don't believe that 154 is a regional hoarding policy. Perhaps you are
> confused with 155? 

155 is another example of discord-producing policy.

> 
> > All under the rubric of stewardship, or our particular views of
> > stewardship. 
> > We are stewards not only of addresses and routing tables, but of a
> > unique governance system which requires tolerance and voluntary
> > cooperation to survive. 
> > 
> 
> True. However, such a system of governance can also break down if we do
> not stand up to
> protect fundamental principles. While I realize APNIC has chosen to
> abandon it, I still believe
> that needs basis is a fundamental principle underpinning the management
> of address
> space for the internet. There is a big difference between tolerance of
> regional differences
> and abandonment of fundamental principles simply because one region
> chose to do so. 

I think this is exactly what needs to be balanced when deciding when
to go along for the sake of harmony versus doing something different
because we need to.

> 
> > We could be sowing the seeds of escalating problems which could open
> > the door for government to claim the self governance model can not 
> > work in lean times. 
> > 
> 
> Fortunately, we are not really facing lean times. We are facing a
> temporary shortage
> of one particular resource which will over time become largely irrelevant.
> 
> Owen

If as John Curran recently said, ARIN can reserve a /10 for shared
infrastructure use without an explicit policy, pending IETF action,
and that this will prevent the ugly scenario of the IETF publishing an
enabling RFC and ARIN (or the IANA or another RIR) not being able to
supply a /10 to make it usable, then I'm fine.

Also agree this all goes away when IPv6 becomes the default.  (Now
back to breaking our internal SMTP/POP/IMAP server by attempting to
enable IPv6 on it...)

-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539




More information about the ARIN-PPML mailing list