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

Mike Burns mike at nationwideinc.com
Fri May 27 12:06:38 EDT 2011


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

My point is that the guidelines you posted are already obseleted by current transfer requirements involving not 12 months, but three months of usage in the current needs test.
Could RIPE refuse to transfer to us because we are violating the "values" of RFC2050 by not allowing a 12 months of need?

So attempting to claim that RFC2050 somehow clears up the uncertainty about the word "compatible" doesn't suffice.
And as far as cherry picking, my quote of 4.1 says "the primary", while you degrade that language to "a primary" in your reply.

And anyway, what is the point of trying to use RFC 2050 to justify or explain language that could be clearly inserted in the NRPM?

This is similar to when I pointed out that section 12 of the NRPM would not give ARIN the right to revoke addresses for utilization as it is written now, and John proffered RFC2050 as providing that justification, which is lacking in the current NRPM language.

That is like using the Declaration of Independence to make a legal finding absent from the Constitution. Sure it can give guidance, but the actual rules are better clearly established in the NRPM, if that is an option.

Regards,
Mike





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


  Mike,

  Please don't cherry-pick the guidance of RFC 2050.

  It also says, more pertinent and fundamental to the issues of transfers and efficiency....

1. Introduction   Internet address space is distributed according to the following
   three goals:

   1) Conservation: Fair distribution of globally unique Internet address
   space according to the operational needs of the end-users and Internet
   Service Providers operating networks using this address space.
   Prevention of stockpiling in order to maximize the lifetime of the Internet address space.   2) Routability: Distribution of globally unique Internet addresses
   in a hierarchical manner, permitting the routing scalability of
   the addresses. This scalability is necessary to ensure proper
   operation of Internet routing, although it must be stressed that
   routability is in no way guaranteed with the allocation or
   assignment of IPv4 addresses.

   3) Registration: Provision of a public registry documenting address
   space allocation and assignment.  This is necessary to ensure
   uniqueness and to provide information for Internet trouble shooting
   at all levels.
Conservation is the first principle, registration services is a primary duty of the RIR, to be sure, but its goals are not record keeping alone, but for the purposes of achieving the goals otherwise described.Moreover, 3.1  Common Registry Requirements

   Because the number of available IP addresses on the Internet is
   limited, the utilization rate of address space will be a key factor
   in network number assignment.  Therefore, in the best interest of the
   Internet as a whole, specific guidelines have been created to govern
   the assignment of addresses based on utilization rates.

   Although topological issues may make exceptions necessary, the basic
   criteria that should be met to receive network numbers are listed
   below:

                25% immediate utilization rate
                50% utilization  rate within 1 year   The utilization rate above is to be used as a guideline, there may be
   be occasions when the 1 year rate does not fall exactly in this
   range.  Organizations must exhibit a high confidence level in its 1
   year utilization rate and supply documentation to justify the level
   of confidence.

   Organizations will be assigned address space based on immediate
   utilization plus 1 year projected utilization.  A prefix longer than
   /24 may be issued if deemed appropriate.  Organizations with less
   than 128 hosts will not be issued an IP address directly from the
   IRs.  Organizations may be issued a prefix longer than /24 if the
   organization can provide documentation from a registry recognized ISP
   indicating the ISP will accept the long prefix for injection into the
   global routing system.

   Exceptions to the criteria will not be made based on insufficient
   equipment without additional detailed justification.  Organizations
   should implement variable length subnet mask (VLSM) internally to
   maximize the effective utilization of address space.  Address
   assignments will be made under the assumption that VLSM is or will be
   implemented.

   IP addresses are valid as long as the criteria continues to be met.
   The IANA reserves the right to invalidate any IP assignments once it
   is determined the the requirement for the address space no longer
   exists.  In the event of address invalidation, reasonable efforts
   will be made by the appropriate registry to inform the organization
   that the addresses have been returned to the free pool of IPv4
   address space.
4.  Operational Guidelines For Registries
   7.  The transfer of IP addresses from one party to another must be
       approved by the regional registries.  The party trying to obtain
       the IP address must meet the same criteria as if they were
       requesting an IP address directly from the IR.
Clearly, the guidelines call for efficient utilization by entities that have need and can justtify the needand transfers would be according to local policies of RIRs....which have all agreed to conform to these principles.bd


----------------------------------------------------------------------------
    From: Mike Burns [mailto:mike at nationwideinc.com] 
    Sent: Friday, May 27, 2011 9:16 AM
    To: Bill Darte; Chris Grundemann
    Cc: ARIN-PPML List
    Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3


    Hi 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/d1c51e4b/attachment.html>


More information about the ARIN-PPML mailing list