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

Tue May 31 11:57:20 EDT 2011

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 <mailto:frnkblk at iname.com>  

To: 'Scott Leibrand' <mailto:scottleibrand at gmail.com>  

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/88ad35c2/attachment.htm>