On Sat, Jul 19, 2014 at 11:04 AM, Steven Ryerse < [email protected]> wrote:
> I've said this before, but this proposal might help an Org that only needs > a /24 but I think it will hurt an Org that needs a /20 or a /22 as the > needs test that are applied will force them into qualifying for the /24 but > not the /20 or /22 they legitimately need. Steve, I count four uses of the word "need" in that sentence; I suspect part of the problem here is that you're using "need" in two different ways, while the rest of the list is thinking of just one use of the word "need". You say "I think it will hurt an Org that needs a /20 or a /22" --ok, we've established their org has a requirement for a certain size block--to keep it straight, let's say their use case requires a /22. You than continue by saying "as the needs test that are applied will force them into qualifying for the /24" --here's where the confusion starts; you seem to be saying the needs test will evaluate their stated requirement, and determine only a /24 is actually required for their use case. That is, the evaluation of the requirements by the Org are different than the evaluation of the requirements by ARIN. You then conclude by saying "but not the /20 or /22 they legitimately need." --here, the use of "legitimately need" seems to be designed to try to frame it in opposition to the "need" of "needs test" used in the previous clause, and seems to focus on reinforcing the idea that the Org has evaluated their requirements differently from ARIN. As humans, we sometimes have a tendency to think we know best; that when we come up with an idea, it's somehow the best possible idea, the best possible way to approach a situation. And yet, it's not uncommon to find that others have in the past come up with similar ideas, with possibly slightly different solutions, some of which might actually be more efficient when viewed objectively. Part of the drive here from the community is to help guide organizations into using the most efficient solutions we have available to us as a whole. In the past, people thought that web hosting meant you needed a different IP address for every virtual host you ran; I know I configured my early web farms that way. But then use of the Host: header became more widespread, and we slowly learned we didn't need to allocate huge swaths of IP space to webservers just to handle multiple virtual hosts. We've codified that knowledge into the allocation guidelines, so that future Orgs that show up asking for a /22 so that they can run multiple virtual hosts on their one server can be gently steered towards how to configure their servers in a more efficient manner, using less of a scarce resource. This doesn't mean the Org coming with the request for a /22 didn't feel they had a completely legitimate need, that their installation *required* the full block of address space. In their eyes, that was what was needed, and anyone saying otherwise was trying to stop them from doing business. But from an outside perspective, the Org was attempting to make use of a less efficient way to run their web farm, and pushing back on the request with a nudge towards a more efficient means of serving virtual hosts off a single IP address would be the only reasonable response; it would be unethical for the community to not help guide that Org towards a more efficient mode of operation. I've never seen an organization get turned down for IP space that could clearly document the basis for their IP address requirements. I *have* been turned down myself, in the past, when my thoughts on what number resources were required did not follow the best practices for the industry; and I took the gentle rejection and recommendation to heart, learned a better way to do virtual hosting, and came back with an updated request that better matched what the industry best practices actually required. What we're doing here is not trying to stifle new businesses; what we want to do is make sure that new businesses understand that there are efficient ways to use resources, and inefficient ways to use resources, and as a community, we're trying to steer those businesses towards using the resources in the most efficient way we've discovered so far. So, getting back to your original statement, with its somewhat confusing 4 uses of the word "needs", I think a clearer statement of your concern would have been: I've said this before, but this proposal might help an Org that only optimally requires a /24 but I think it will hurt an Org that thinks their application will require a /20 or a /22, but the needs test that are applied will recommend a more efficient solution that only requires a /24, not the /20 or /22 they initially felt would be needed. If the organization truly has a 'legitimate need', in that they are already working towards the most efficient solution the industry is aware of, and have documented their application of that best practice, I don't think these proposals will in any way jeopardize their ability to get those resources. > Orgs that legitimately need a slightly larger allocation because of the > gyrations they must go thru to try and justify a larger allocation, will > end up not qualifying even though they have a legitimate need. The > solution here is to completely remove the needs tests at the low end and > not just on a /24. Proposal like 2014-13 are just dancing around the > problem instead of trying to legitimately fix it. > Again, I suspect the use of the term "legitimately need" here is slightly mis-used. You don't "legitimately need" a larger allocation just because you feel there's gyrations you have to go through. The community is helping guide you to a more efficient way of using number resources; those 'gyrations' are efforts to avoid learning the more efficient ways to use the resources. It's rather like burning coal for electricity. Yes, it's quick and easy and people wonder why they can't just do that, rather than developing more sustainable alternatives like solar, hydro, or wind power; but the fact is, as a community, we can't allow the ongoing destruction of limited community resources (limited supply of coal in the ground, limited supply of fresh, unpolluted air to breathe) simply because it's easier for you to do business that way. Water is in a similar position; for centuries, everyone took water for granted; now that fresh water is running out, we're suddenly faced with the same challenges as the ARIN community. We're having to push back on people and companies that have been used to using it inefficiently for years, and trying to explain that there's just not enough left--you can't continue doing business as usual, you have to learn more efficient ways of using the resource if we're all going to survive. Removing all "needs" testing sounds great in the short term; but I suspect those who cry out most loudly for removing the needs requirements would soon be crying out for subsidies or other interventions when the well runs dry, and the only way to get more is to buy from those that still have some. Much better to learn how to be efficient now while you still can, than count on being profligate until suddenly there's nothing left in the well to draw from. > > Small Organizations are very much under-represented in this Community and > therefore their reasonable interests go under-represented. I do appreciate > you asking Gary but I don't see the needs of small Organizations truly > represented in this Community. > Fair enough; I suspect, however, as there's no particular barrier to entry for those smaller organizations to participate in this community, that most of them are sufficiently well served currently to not feel a need to speak out. I know when I'm happy, I tend to not feel the need to jump up and tell everyone I'm happy with the way the world is; but when I'm unhappy, I'm much more inclined to speak out. I *suppose* ARIN could add a one-line question to the renewal process for annual resource fees-- "Please indicate how well represented you feel your interests are in the ARIN community, on a scale of 1 to 10, 1 being 'I feel my interests are completely unrepresented', and 10 being 'John Curran carries out my every whim and waking desire.'" That would give us more concrete insight into whether small Organizations feel their interests are not well represented. But I'll have to leave that to John to decide whether gathering that level of data is practical or not. Thanks! Matt > > Steven Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > www.eclipse-networks.com > 770.656.1460 - Cell > 770.399.9099- Office > > ℠ Eclipse Networks, Inc. > Conquering Complex Networks℠ > > -----Original Message----- > From: Gary Buhrmaster [mailto:[email protected]] > Sent: Friday, July 18, 2014 9:41 PM > To: Steven Ryerse > Cc: Owen DeLong; [email protected] > Subject: Re: [arin-ppml] ARIN 2014-13 > > On Fri, Jul 18, 2014 at 11:42 PM, Steven Ryerse < > [email protected]> wrote: > > > > You are entitled to your opinion and I’m entitled to mine. > > Absolutely, but you have been unable to articulate a compelling scenario > as to how this will negatively impact the region and the members who > request numbers. If you would share the specific example of how being able > to get a /24 (whereas before they would qualify for nothing having too > small of a justified need) will end up hurting the community, you need to > share. We are not mind readers (well, at least I am not, I can not speak > to any psychic abilities that others that participate on this list may > claim to have). Thanks. > _______________________________________________ > 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. >
_______________________________________________ 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.
