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

Mike Burns mike at nationwideinc.com
Wed May 25 12:21:13 EDT 2011


RIPE requires their final /8 to be distributed in /22 chunks, and you have to already have an IPv6 allocation.
What if they regard us as not having compatible needs requirements?
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.

Mike


  ----- Original Message ----- 
  From: Owen DeLong 
  To: frnkblk at iname.com 
  Cc: ARIN-PPML List 
  Sent: Wednesday, May 25, 2011 12:00 PM
  Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3


  I would prefer since we are venturing into inter-RIR territory to have this policy be as specific and complete
  as possible and stand alone to the greatest possible extent. In this case, I think excessive clarity where
  practicable is worth while.


  Owen


  On May 24, 2011, at 8:35 PM, Frank Bulk wrote:


    Since currently ARIN policy implements the needs-basis, isn’t mentioning that requirement in 2011-1 redundant?  Or are you concerned that some ARIN policies might remove the needs-basis requirement and you want to preserve the requirement in the inter-RIR transfer?

    Frank

    From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong
    Sent: Tuesday, May 24, 2011 12:47 AM
    To: Scott Leibrand
    Cc: ARIN-PPML List
    Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3

    I still would prefer to see the needs-basis comment preserved as well.

    Owen

    On May 23, 2011, at 10:07 PM, Scott Leibrand wrote:



    So perhaps:

    + to another RIR, for transfer to a specified recipient in that RIR's service region, if both RIRs agree and the request meets both RIRs' transfer policies.

    I agree it's useful to preserve discretion. I think I might prefer this to the text I originally had below...  Thoughts?

    Scott

    On May 23, 2011, at 9:56 PM, Owen DeLong <owen at delong.com> wrote:

      I prefer to preserve the safety valve of requiring agreement from both RIRs.

      Owen

      On May 23, 2011, at 8:53 PM, Frank Bulk wrote:



      Why don’t we change the second point to:

      + to another RIR, for transfer to a specified recipient in that RIR's service
      region, if the request meets both RIRS’ transfer policies.

      Frank






          ----- Original Message -----
          From: Scott Leibrand
          To: Owen DeLong
          Cc: ARIN-PPML List
          Sent: Monday, May 23, 2011 5:21 PM
          Subject: Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3

          On Mon, May 23, 2011 at 2:05 PM, Owen DeLong <owen at delong.com> wrote:
          I could support this, but, I have a couple of lingering concerns.

          I think that the last sentence dictates too much in the case of a transfer to another region and should only apply to transfers within the ARIN region.

          Yeah, I was wondering about that myself.  Possible slight revision inline below...


            On May 23, 2011, at 15:54, Scott Leibrand <scottleibrand at gmail.com> wrote:

              In light of the discomfort a number of community and AC members feel with the original 2011-1 text, I thought I'd make an attempt at integrating it into the framework of NRPM 8.3, to see if the result would be tighter and less ambiguous.  Here's what I came up with:

              8.3. Transfers to Specified Recipients

              In addition to transfers under section 8.2, IPv4 number resources may be released to ARIN by the authorized resource holder, in whole or in part, for transfer:
                a.. to a specified organizational recipient within the ARIN region, or 
                b.. to another RIR, for transfer to a specified organizational recipient in that RIR's service region, if the two RIRs agree and maintain compatible, needs-based transfer policies.
              Such transferred number resources may only be received under RSA by organizations that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies.  

          How about "Such number resources may only be received under RSA by organizations that can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN, or recipient RIR, policies." ?

          Or, feel free to suggest text...

          -Scott


              For reference, existing policy reads:
              8.3. Transfers to Specified Recipients

              In addition to transfers under section 8.2, IPv4 number resources within the ARIN region may be released to ARIN by the authorized resource holder, in whole or in part, for transfer to another specified organizational recipient. Such transferred number resources may only be received under RSA by organizations that are within the ARIN region and can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies.

              And original 2011-1 text reads:
              Any RIR's resource registrant may transfer IPv4 addresses to the resource registrant of another RIR as long as the two RIRs agree and maintain compatible, needs-based transfer policies that exercise Internet stewardship consistent with the values expressed in RFC2050.
              _______________________________________________
              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.

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

    =




------------------------------------------------------------------------------


  _______________________________________________
  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/20110525/a2a78e30/attachment.htm>


More information about the ARIN-PPML mailing list