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

Tue May 31 11:49:46 EDT 2011

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/938e6a83/attachment.htm>