[arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3

[Mike Burns]

RE: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3Hi Bill,

It's still not clear to me.
Referencing "values" of an RFC is not terribly clarifying when attempting to match transfer needs requirements which already are out of sync with RFC2050's 1 year window.

And anyway, I say that requiring a needs test is *NOT* consistent with the values expressed here in RFC2050:

4.  Operational Guidelines For Registries

   1.  Regional Registries provide registration services as its
       primary function.

By requiring a needs test for inter-RIR transfers, we run the risk of driving these transfers off the books in contravention of our PRIMARY function as stewards.

Just so we all understand. 
APNIC has a great need, and probably less underutilized addresses in its market to supply that need.
A good chunk of available space is likely to be found in the legacy pools which are overrepresented in our region.
The majority of this legacy space is not under any RSA with any RIR.

You can route legacy space from inside Asia.

A likely action that will occur is the purchases of address blocks from legacy holders which will be routed in Asia by network operators there, but ARIN will not be notified and Whois will not be updated.

I have said that I think we are moving into a future with more, rather than less, conflict over IPv4 address control. This is only to be expected, as the availability of free pool addresses has always provided a replacement option for any addresses in conflict. In addition, the underlying monetary value of address control, once understood, provides ample motive to drive conflict.

In an age of conflict, the accuracy of Whois will be related to the level of trust afforded to it. The absence of a strong trust authority could open the doors to a private registry.

Suppose there is conflict between private organizations over address control.  Then add to that conflict between RIRs over which registry is the authoritative. What is to stop a real international trust authority, say Lloyds of London, from using its trust to establish a pricey but generally recognized registry?

Or even worse, what if the door is opened to the ITU to claim the RIR system was failing in a post-exhaust era, and seek to create its own registry system, or otherwise take control?

Once again, I make the point that a market in IPv4 addresses, such as envisaged in 8.3 or in the APNIC transfer policy, meets the stewardship goal of conservation through natural market forces.
If we ladle on an extra helping of steward meddling, we are taking action in contravention of our primary duty to maintain a viable and trusted registry.

So I would support the proposal if the requirement was simply that both RIRs approve, leaving off the "signal" sent by the needs language, which signal reads like a shot across the bow to me.

Regards,

Mike










  ----- Original Message ----- 
  From: Bill Darte 
  To: Mike Burns ; Chris Grundemann 
  Cc: ARIN-PPML List 
  Sent: Friday, May 27, 2011 7:38 AM
  Subject: RE: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3


  The word you say is subjective...'compatible'... in the DP is interpreted by..
  'that exercise Internet stewardship consistent with the values expressed in RFC2050'


  -----Original Message-----
  From: arin-ppml-bounces at arin.net on behalf of Mike Burns
  Sent: Thu 5/26/2011 4:28 PM
  To: Chris Grundemann
  Cc: ARIN-PPML List
  Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3

  > What is to be gained by including that language, except to engender
  > Inter-RIR conflict?
  > The wording already includes both RIRs to approve the transfer.
  > There is no definition in the policy or elsewhere in the NRPM of
  > "compatible" needs policies.
  > I don't see the point in including it.

  The point of that statement is to signal the intentions of the ARIN
  community both to ARIN staff and to other RIRs. It provides guidance
  to ARIN staff that they should not agree to any transfer that does not
  include needs-based policy on the recipient end. It also ensures that
  recipients in other regions will not be surprised when a transfer is
  denied for lack of said needs-based policies. The point, in short, is
  clarity and transparency.

  Cheers,
  ~Chris


  Hi Chris,

  But how clear is it exactly?
  Do you mean it to signal that *any* needs test is compatible?
  If that is the intent, then I think the language can be clearer.
  If you want clarity, then using a subjective word like "compatible" which is
  undefined in the proposal is sub-optimal.
  Since its definition and application is left to ARIN staff, and ARIN staff
  is required to decide on transfer approval anyway, I don't see any great
  clarity or transparency.
  What I do see reads like a political statement added onto a policy proposal,
  to no real effect except to exacerbate inter-RIR tensions.
  What better way to incite the APNIC stewards to unilaterally decide to
  accept transfers into their region of legacy space with no RSA in place?
  This is currently a lacuna in policy awaiting a test case, as far as I know.

  It's not like there are hundreds of different transfer policies, I'm sure
  those requesting inter-RIR transfers will be aware of the current policies
  without brandishing our disdain for their version of stewardship in
  additional and functionally inoperative language.

  Regards,
  Mike

  _______________________________________________
  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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110527/e7066c7b/attachment.htm>