[arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised

Mon Jul 15 18:07:29 EDT 2013

One more thing.  I think the ARIN Mission Statement was well crafted and does a very good job of providing us with the principles of how policies should be crafted.  Why don’t we start there and build principles that follow the Mission Statement.  Otherwise the Mission Statement should be changed to reflect a different mission.   (I for one wouldn’t support a Mission Statement change.)

Steven L Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA  30338
770.656.1460 - Cell
770.399.9099 - Office
770.392-0076 - Fax

[Description: Description: Description: Eclipse Networks Logo_small.png]℠ Eclipse Networks, Inc.
        Conquering Complex Networks℠

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Steven Ryerse
Sent: Monday, July 15, 2013 5:57 PM
To: Chris Grundemann
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised

Chris, I would use their existing network size first and then company size if available to help determine exceptions.  The big guys with a big request like T-Mobile who got around three quarters of a /8 awhile back are probably going to be handled by ARIN management anyway.  If for example AT&T or Verizon decided they needed a /8 today I suspect that ARIN would help them get what they say they need. I realize this subject is political and somewhat controversial based on the past discussions about T-Mobile and Microsoft obtaining large blocks, and I don’t wish to rehash that here - but it is debatable whether ARIN in real life would make them prove they need it with a zillion ARP logs and whatever.  And  I know John would say publicly ARIN would make them prove it and I don’t have a problem empowering John with the authority to determine what a big guy needs to provide to prove it.  So let the big guys get big blocks and let the small guys get small blocks and make them all use their existing network size to help right size the request.  I think ARIN managers are capable of handling the exceptions and I’m guessing there are probably not that many times a small existing network wants a big block.  Lastly let an org that doesn’t like the size of their allocation have an appeal option to ARIN management and empower ARIN management to look to see if they think an exception is warranted.

One of the definitions of Conserve is to Preserve.  I know the definition in the proposal tries to better define what is meant by Conserve but we can’t preserve IPv4 and really for the same reasons we can’t preserve IPv6 forever.  Better we be good technical stewards and have ARIN fulfill its mission to grow the Internet wherever it can and we all benefit.  So I think William was on the money when he suggested removing the word Conservation.

David asked:  In your "right sized allocations" vision for policy is it necessary for a large company with a /8 to demonstrate that they are using the current
/8 they have before they can get another one?  How long after they get there new /8 can they ask for another one, 1 day, 1 month, 1 year, 2 years..?

As I said above, in the real world with a real allocation request of a large block request, John is going to do his fiduciary duty and do what he thinks is best based on everything he knows.  I’m sure he did ask T-Mobile if they needed a /8 or the three quarters of the /8 that they got.  I’m sure they did respond with what he thought was a reasonable answer at that time.  I doubt he asked to see oodles of ARP table reports or other physical evidence of need.  (I could be wrong of course.)  I doubt he made them calculate how long the allocation they requested would last per ARIN’s then current policy.  (I could be wrong of course.)

I think the answer to when should T-Mobile (or anyone else) get another large (or smaller) allocation is when they have actual use for it.  Need based policies encourage fibbing (or outright lying) and I haven’t seen any allocations rescinded based on the org not using all of the allocation as fast as the org told ARIN they would actually use them.  It is better to just have ARIN follow its mission and get allocations out in the real world where they can be used and not try to preserve them when we all know they can’t be preserved.

Getting IP allocations out there worked great by Jon Postel to grow the Internet and we all have benefitted.  Trying to find ways to not get allocations out there does the opposite and we all lose when that happens.  We should follow Jon’s lead and get as many right sized allocations out there as we can so we all can continue to win.  ☺

Steven L Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA  30338
770.656.1460 - Cell
770.399.9099 - Office
770.392-0076 - Fax

[Description: Description: Description: Eclipse Networks Logo_small.png]℠ Eclipse Networks, Inc.
        Conquering Complex Networks℠

From: Chris Grundemann [mailto:cgrundemann at gmail.com]
Sent: Monday, July 15, 2013 5:05 PM
To: Steven Ryerse
Cc: Blake Dunlap; arin-ppml at arin.net<mailto:arin-ppml at arin.net>
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised

On Mon, Jul 15, 2013 at 2:23 PM, Steven Ryerse <SRyerse at eclipse-networks.com<mailto:SRyerse at eclipse-networks.com>> wrote:
If you are publicly traded and your company’s revenues are public then the size of the company is available to all.  This could be used to make sure only a large organization who might actually have use for it can get a /8 or other large

I can imagine many organizations that make lots of money but have very small networks, and many other organizations that make little to no money but have large networks. In other words, I don't see size of revenue as a good proxy for size of network. The same is generally true for number of employees, and basically every stat other than "how big is the network you operate and how fast is it growing?" That may effect the other metrics but I don't see a conclusive, reliable, direct, and proportional link between any of them.

block size.  The other info that could be used is how much resource does an org have now.  If they have a /8 they might really have use for another /8.  If they have a /22 they might really have use for another /22.  Obviously the org with a /22 isn’t likely to have use for a /8.  Orgs with multiple allocations already can add them together including legacy blocks.  An org that has no allocation or one up to a /22 allocation should be able to qualify for the currently defined minimum sized block which I believe is currently a /22 .  The rare case where an org with a very small or no current allocation has use for a very large block can be handled as an exception with more proof required that the block they are requesting – I’m thinking this would require a manager at ARIN to handle.  I’m guessing it is rare that an org needs to add more than double what they already have allocated and those can be special cases handled as exceptions with additional proof required.  In this way the blocks allocated are right sized for the size of the org requesting the allocation.  There are some smart folks in this community who might be able to tweak this idea and make it better, especially for larger allocations.

A lot of this sounds reasonable, it all also sounds like possible tweaks to the manner in which need is assessed at ARIN. I don't see anything here that is inherently or necessarily out of line with the principle of conservation. What you are describing here are implementation details of one of the principles included in this draft policy from what I can tell.

Cheers,
~Chris

Steven L Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA  30338
770.656.1460<tel:770.656.1460> - Cell
770.399.9099<tel:770.399.9099> - Office
770.392-0076<tel:770.392-0076> - Fax

[Description: Description: Description: Eclipse Networks Logo_small.png]℠ Eclipse Networks, Inc.
        Conquering Complex Networks℠

From: Blake Dunlap [mailto:ikiris at gmail.com<mailto:ikiris at gmail.com>]
Sent: Monday, July 15, 2013 3:01 PM
To: Steven Ryerse
Cc: Matthew Wilder; David Farmer; arin-ppml at arin.net<mailto:arin-ppml at arin.net>
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised

Exactly how is this "right sized allocation" based on network size different than needs basis allocation?
-Blake

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20130715/d4de77ac/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 1473 bytes
Desc: image001.jpg
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20130715/d4de77ac/attachment.jpg>