<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jul 19, 2014 at 11:04 AM, Steven Ryerse <span dir="ltr"><<a href="mailto:SRyerse@eclipse-networks.com" target="_blank">SRyerse@eclipse-networks.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.  </blockquote>
<div><br></div><div>Steve,<br><br></div><div>I count four uses of the word "need" in that sentence;<br>I suspect part of the problem here is that you're using<br></div><div>"need" in two different ways, while the rest of the list<br>
is thinking of just one use of the word "need".<br><br></div><div>You say <br>"I think it will hurt an Org that needs a /20 or a /22"<br></div><div>--ok, we've established their org has a requirement<br>
for a certain size block--to keep it straight, let's<br></div><div>say their use case requires a /22.<br></div><div><br>You than continue by saying<br>"as the needs test that are applied will force them into qualifying for the /24"<br>
</div><div>--here's where the confusion starts; you seem to<br>be saying the needs test will evaluate their stated<br>requirement, and determine only a /24 is actually<br>required for their use case.  That is, the evaluation<br>
</div><div>of the requirements by the Org are different than the<br>evaluation of the requirements by ARIN.<br><br></div><div>You then conclude by saying<br>"but not the /20 or /22 they legitimately need."<br></div>
<div>--here, the use of "legitimately need" seems to<br>be designed to try to frame it in opposition to<br>the "need" of "needs test" used in the previous<br>clause, and seems to focus on reinforcing the<br>
</div><div>idea that the Org has evaluated their requirements<br>differently from ARIN.<br><br></div><div>As humans, we sometimes have a tendency to<br>think we know best; that when we come up with<br>an idea, it's somehow the best possible idea, the<br>
best possible way to approach a situation.  And<br></div><div>yet, it's not uncommon to find that others have<br>in the past come up with similar ideas, with<br></div><div>possibly slightly different solutions, some of<br>
which might actually be more efficient when<br>viewed objectively.<br><br>Part of the drive here from the community is<br>to help guide organizations into using the most<br></div><div>efficient solutions we have available to us as a<br>
whole.  In the past, people thought that web hosting<br>meant you needed a different IP address for every<br>virtual host you ran; I know I configured my early<br>web farms that way.  But then use of the Host:<br>header became more widespread, and we slowly<br>
learned we didn't need to allocate huge swaths of<br>IP space to webservers just to handle multiple<br>virtual hosts.  We've codified that knowledge into<br></div><div>the allocation guidelines, so that future Orgs that<br>
show up asking for a /22 so that they can run<br>multiple virtual hosts on their one server can be<br>gently steered towards how to configure their<br>servers in a more efficient manner, using less<br>of a scarce resource.<br>
<br></div><div>This doesn't mean the Org coming with the request<br></div><div>for a /22 didn't feel they had a completely legitimate<br>need, that their installation *required* the full block<br>of address space.  In their eyes, that was what was<br>
needed, and anyone saying otherwise was trying<br>to stop them from doing business.  But from an<br>outside perspective, the Org was attempting to make<br>use of a less efficient way to run their web farm,<br>and pushing back on the request with a nudge towards<br>
a more efficient means of serving virtual hosts off<br>a single IP address would be the only reasonable<br></div><div>response; it would be unethical for the community<br>to not help guide that Org towards a more efficient<br>
mode of operation.<br><br></div><div>I've never seen an organization get turned down<br>for IP space that could clearly document the<br>basis for their IP address requirements.  I *have*<br></div><div>been turned down myself, in the past, when my<br>
thoughts on what number resources were required<br></div><div>did not follow the best practices for the industry;<br>and I took the gentle rejection and recommendation<br>to heart, learned a better way to do virtual hosting,<br>
and came back with an updated request that better<br>matched what the industry best practices actually<br>required.<br><br></div><div>What we're doing here is not trying to stifle new<br></div><div>businesses; what we want to do is make sure that<br>
new businesses understand that there are efficient<br>ways to use resources, and inefficient ways to use<br>resources, and as a community, we're trying to steer<br></div><div>those businesses towards using the resources in the<br>
most efficient way we've discovered so far.<br><br></div><div>So, getting back to your original statement, with its<br>somewhat confusing 4 uses of the word "needs", I<br>think a clearer statement of  your concern would<br>
have been:<br><br>I've said this before, but this proposal might help an Org <br>that only optimally requires a /24 but I think it will hurt an <br>Org that thinks their application will require a /20 or a /22,<br>but
 the needs test that are applied will recommend a more<br>efficient solution that only requires a /24, not the /20 or /22<br>they initially felt would be needed.<br><br></div><div>If the organization truly has a 'legitimate need', in that<br>
they are already working towards the most efficient<br>solution the industry is aware of, and have documented<br>their application of that best practice, I don't think these<br></div><div>proposals will in any way jeopardize their ability to get<br>
</div><div>those resources.<br> </div><div><br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br>
</blockquote><div><br><br></div><div>Again, I suspect the use of the term "legitimately need" here<br>is slightly mis-used.  You don't "legitimately need" a larger<br>allocation just because you feel there's gyrations you have<br>
</div><div>to go through.  The community is helping guide you to a more<br></div><div>efficient way of using number resources; those 'gyrations'<br>are efforts to avoid learning the more efficient ways to<br>use the resources.<br>
<br></div><div>It's rather like burning coal for electricity.  Yes, it's<br>quick and easy and people wonder why they can't<br>just do that, rather than developing more sustainable<br></div><div>alternatives like solar, hydro, or wind power; but the<br>
fact is, as a community, we can't allow the ongoing<br>destruction of limited community resources (limited <br>supply of coal in the ground, limited supply of fresh,<br>unpolluted air to breathe) simply because it's easier<br>
for you to do business that way.<br><br></div><div>Water is in a similar position; for centuries, everyone<br>took water for granted; now that fresh water is<br>running out, we're suddenly faced with the same<br></div>
<div>challenges as the ARIN community.  We're having to<br>push back on people and companies that have been <br>used to using it inefficiently for years, and trying to <br>explain that there's just not enough left--you can't <br>
continue doing business as usual, you have to learn <br>more efficient ways of using the resource if we're all <br>going to survive.<br><br></div><div>Removing all "needs" testing sounds great in the<br>short term; but I suspect those who cry out most<br>
loudly for removing the needs requirements would<br>soon be crying out for subsidies or other interventions<br>when the well runs dry, and the only way to get more <br>is to buy from those that still have some.<br></div><div>
Much better to learn how to be efficient now while<br>you still can, than count on being profligate until<br>suddenly there's nothing left in the well to draw from.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<br>
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.<br>
</blockquote><div><br></div><div>Fair enough; I suspect, however,<br>as there's no particular barrier to entry<br></div><div>for those smaller organizations to<br>participate in this community, that<br>most of them are sufficiently well<br>
served currently to not feel a need<br></div><div>to speak out.  I know when I'm happy,<br>I tend to not feel the need to jump up<br>and tell everyone I'm happy with the<br></div><div>way the world is; but when I'm unhappy,<br>
</div><div>I'm much more inclined to speak out.<br><br>I *suppose* ARIN could add a one-line<br>question to the renewal process for<br></div><div>annual resource fees-- "Please indicate<br>how well represented you feel your interests<br>
are in the ARIN community, on a scale of<br></div><div>1 to 10, 1 being 'I feel my interests are<br>completely unrepresented', and 10 being<br></div><div>'John Curran carries out my every whim<br>and waking desire.'"  That would give us<br>
</div><div>more concrete insight into whether small<br></div><div>Organizations feel their interests are not <br>well represented.  But I'll have to leave that<br>to John to decide whether gathering that level<br>of data is practical or not.<br>
<br>Thanks!<br><br>Matt<br><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im"><br>
Steven Ryerse<br>
President<br>
100 Ashford Center North, Suite 110, Atlanta, GA  30338<br>
<a href="http://www.eclipse-networks.com" target="_blank">www.eclipse-networks.com</a><br>
<a href="tel:770.656.1460" value="+17706561460">770.656.1460</a> - Cell<br>
<a href="tel:770.399.9099" value="+17703999099">770.399.9099</a>- Office<br>
<br>
</div><div class="im">℠ Eclipse Networks, Inc.<br>
                     Conquering Complex Networks℠<br>
<br>
</div><div class="im">-----Original Message-----<br>
From: Gary Buhrmaster [mailto:<a href="mailto:gary.buhrmaster@gmail.com">gary.buhrmaster@gmail.com</a>]<br>
</div><div class="im">Sent: Friday, July 18, 2014 9:41 PM<br>
To: Steven Ryerse<br>
</div><div class="im">Cc: Owen DeLong; <a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a><br>
Subject: Re: [arin-ppml] ARIN 2014-13<br>
<br>
</div><div class=""><div class="h5">On Fri, Jul 18, 2014 at 11:42 PM, Steven Ryerse <<a href="mailto:SRyerse@eclipse-networks.com">SRyerse@eclipse-networks.com</a>> wrote:<br>
><br>
> You are entitled to your opinion and I’m entitled to mine.<br>
<br>
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.<br>

_______________________________________________<br>
PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.</div></div></blockquote></div><br></div></div>