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: [email protected] [mailto:[email protected]] On Behalf
Of Steven Ryerse
Sent: Monday, July 15, 2013 5:57 PM
To: Chris Grundemann
Cc: [email protected]
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:[email protected]]
Sent: Monday, July 15, 2013 5:05 PM
To: Steven Ryerse
Cc: Blake Dunlap; [email protected]<mailto:[email protected]>
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised
On Mon, Jul 15, 2013 at 2:23 PM, Steven Ryerse
<[email protected]<mailto:[email protected]>> 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:[email protected]<mailto:[email protected]>]
Sent: Monday, July 15, 2013 3:01 PM
To: Steven Ryerse
Cc: Matthew Wilder; David Farmer; [email protected]<mailto:[email protected]>
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
<<inline: image001.jpg>>
_______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
