[arin-ppml] ARIN 2014-13

[Matthew Petach]

On Sat, Jul 19, 2014 at 11:04 AM, Steven Ryerse <
SRyerse at eclipse-networks.com> 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:gary.buhrmaster at gmail.com]
> Sent: Friday, July 18, 2014 9:41 PM
> To: Steven Ryerse
> Cc: Owen DeLong; arin-ppml at arin.net
> Subject: Re: [arin-ppml] ARIN 2014-13
>
> On Fri, Jul 18, 2014 at 11:42 PM, Steven Ryerse <
> SRyerse at eclipse-networks.com> 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 (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/20140721/fe997a86/attachment.htm>