[arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3

Mike Burns mike at nationwideinc.com
Tue May 31 12:08:09 EDT 2011


Hi Frank,

Don't you think that every purchaser will have the same impetus towards aggregation (slimmer table)?
And the network operator community has the same desire (slimmer table).
(The network community which maintains routers also does request blocks, I think that they will probably be among the most active buyers and sellers.)
So why create policy whose effect in this area is unproven, despite evidence that it does not work well in certain scenarios?
By that I mean some who need now will have to wait, some who want to sell will keep addresses on the sideline, etc.
My argument is that our primary responsibilty is maintaining an accurate Whois registry, and these increasing complex mechanisms work against that responsibility by incentivizing off-the-books transfers.

Regards,
Mike

  ----- Original Message ----- 
  From: Frank Bulk - iName.com 
  To: 'Mike Burns' 
  Cc: arin-ppml at arin.net ; 'Scott Leibrand' 
  Sent: Tuesday, May 31, 2011 11:57 AM
  Subject: RE: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3


  Rather than let my transit and peering providers summarize routes for me, I prefer to have the IPv4 tables be as slim as possible.

   

  Those who request blocks are not those who maintain and purchase routers.  

   

  If we find out that disaggregation is not an issue we can always eliminate those policies.

   

  Frank

   

  From: Mike Burns [mailto:mike at nationwideinc.com] 
  Sent: Tuesday, May 31, 2011 10:50 AM
  To: frnkblk at iname.com; 'Scott Leibrand'
  Cc: arin-ppml at arin.net
  Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3

   

  This is all an unnecessary and needlessly confusing set of rules whose only purpose is to attempt to impose some restriction on the downwards slide towards disaggregation which will happen whatever policies we prescribe.

   

  In a fluid transfer market, nobody will purposely select to fill their needs with a smattering of smaller netblocks, they will by nature attempt to acquire the largest block to suit their purchase requirements, if only to relieve them of configuration complexity.

   

  In fact, my guess is that people will tend to round up, to allow for a little more room to grow within a contiguous block, bounded of course by the cost of holding unused inventory of addresses. 

   

  Larger netblocks are more likely to be routed everywhere than smaller ones, and this alone will drive consumers towards aggregation.

   

  Creating a new and confusing set of rules related to timeframes for allowed purchases, tracking original registration sizes through potentially multiple transactions, restricting sellers from selling off chunks of their holdings, these things are exactly what would be wrong in putting the steward's lightest touch on things.

   

  Because they would inevitably lead to buyers with a real need not getting addresses in a timely fashion, additional listing requirements (like original allocation size), and of course, lots more transactions happening off the books and leading to a decay in Whois accuracy and representing a failure of our primary stewardship role.

   

  And where is the evidence that this will serve as an actual check on disaggregation, and where is the evidence that we are BGP-table bound, in any real sense?

   

  The check on the growth of the table will not come from the RIR's, in a post-exhaust world, it will come from the decisions of the network operator group about what the minimum routable block size is.

   

  I oppose the policy.

   

  Regards,

  Mike

   

   

   

    ----- Original Message ----- 

    From: Frank Bulk 

    To: 'Scott Leibrand' 

    Cc: arin-ppml at arin.net 

    Sent: Tuesday, May 31, 2011 8:10 AM

    Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3

     

    As long as everyone works within the ARIN transfer policy, attaching the limits on the recipients would seem sufficient.  

     

    Echoing previous posters' concerns, those who fall under the "3 month" needs demonstration may create more disaggregation if they have to get small chunks every time rather than a chunk two or three times larger.  Ideally they're buying the chunks contiguously.  I don't know if we can/should incent them to do that, or if having a contiguous block and not having to find a new seller each time is incentive enough.  I mean, if they really think they're going to grow, they'll likely want to create a contract from the same seller to buy more chunks.

     

    Frank

     

    From: Scott Leibrand [mailto:scottleibrand at gmail.com] 
    Sent: Tuesday, May 31, 2011 12:27 AM
    To: frnkblk at iname.com
    Cc: Owen DeLong; arin-ppml at arin.net
    Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3

     

    ARIN deaggregates /8s into /22s and /20s today, so that's not really much different. It seems that any restriction needs to be on the recipient getting a bunch of deaggregates, not on a large block holder transferring to lots of smaller recipients. 

    Scott


    On May 30, 2011, at 7:16 PM, "Frank Bulk" <frnkblk at iname.com> wrote:

      That's a good goal, but how does this policy manage disaggregation where a larger block owner has the opportunity to sell to different buyers?  For example, the owner of a /8 that has an unused /10 could sell /12's to four different buyers.   On one hand there's a desire to minimize disaggregation, on the other hand if there's unused space that others with a validated need could use, why not.

       

      Frank

       

      From: Owen DeLong [mailto:owen at delong.com] 
      Sent: Monday, May 30, 2011 11:28 AM
      To: frnkblk at iname.com
      Cc: arin-ppml at arin.net
      Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3

       

      If they can find two /15s that started out as /15s, then there's no problem. The issue comes if they, for example,

      find someone with a /8 and want to get two disparate /15s from within that /8. The intent here is to require

      the /8 holder to renumber enough to make a contiguous /14 available rather than transferring two disparate

      /15s and disaggregating them.

       

      Owen

       

      On May 29, 2011, at 9:34 PM, Frank Bulk wrote:

       

      I'm confused.  If an organization can demonstrate need for a /14 and they can only find a /15 in the market today, why should they have to wait a whole year if they can find another /15 just a few months later?  Why should we penalize them for the fact that the supply at the time of need is low?  Is it because you want someone else with demonstrable need to get that second /15?  If that's the case, won't that be based on who's willing to pay top dollar for that /15? 

       

      Frank

       

      From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong
      Sent: Sunday, May 29, 2011 10:46 PM
      To: Brett Frankenberger
      Cc: arin-ppml at arin.net
      Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3

       

      <snip>

       

      What I would think makes more sense as policy would be:

       

        Organizations may transfer multiple address blocks but

        no organization shall receive more than one address block

        per year where said address block is smaller

        than its original registered size.

       

      <snip>

       

       

      _______________________________________________
      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/20110531/6b894484/attachment.htm>


More information about the ARIN-PPML mailing list