<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 7/15/2014 10:04 AM, Matthew Kaufman
wrote:<br>
</div>
<blockquote cite="mid:53C55F2A.7010105@matthew.at" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 7/14/2014 6:44 PM, John Curran
wrote:<br>
</div>
<blockquote
cite="mid:329F6ABF-5623-4469-B9EC-0F75408CC5AB@corp.arin.net"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
On Jul 14, 2014, at 9:06 PM, Jeffrey Lyon <<a
moz-do-not-send="true"
href="mailto:jeffrey.lyon@blacklotus.net">jeffrey.lyon@blacklotus.net</a>>
wrote:<br>
<div>
<blockquote type="cite">
<p dir="ltr">It applies to all but is of zero benefit to
large orgs with contiguous space. This idea that it allows
big orgs to horde space is a red herring.</p>
</blockquote>
</div>
<div>Jeffrey - </div>
<div> </div>
<div> For sake of argument, imagine a large ISP which over the
course of time has</div>
<div> ended up with a /8, two /16, and a /14 IPv4 blocks (with
the /14 being the most</div>
<div> recently issued block because of nearly full utilization
of all prior blocks at the</div>
<div> time.)</div>
<div> </div>
<div> Under present policy, the ISP cannot request address
space until they have </div>
<div> brought the utilization of the most recently issued block
(the /14) up to 80%.</div>
<div> </div>
<div> Under the proposed policy, the ISP is immediately
eligible to request space,</div>
<div> since their aggregate utilization (even with a completely
unused /14) is going </div>
<div> to be very high (potentially as much as 97% due to the
fully-used /8 block.)</div>
<div><br>
</div>
<div> The proposed policy allows organizations to request space
so long as their </div>
<div> aggregate utilization is higher than 80%, and this means
many existing </div>
<div> organization with large IPv4 holdings will suddenly
qualify to receive an </div>
<div> additional allocation if they choose to request it.
Whether that is desirable</div>
<div> or not is a matter for the community to decide.</div>
<div><br>
</div>
<br>
</blockquote>
<br>
Your theoretical argument assumes a certain kind of large ISP. Let
me propose a couple of alternative scenarios:<br>
<br>
Imagine a large ISP which over the course of time has ended up
with a /8, two /16, and a /14 block with the /14 being the most
recently issued block.<br>
<br>
Under present policy, they cannot get more space until the /14 is
documented at 80% utilization, which they've got the documentation
all ready for.<br>
<br>
Under the proposed policy, the ISP can't get any space, because
their recordkeeping on the /8 is terrible. They got the /8 and the
/16 pre-ARIN, probably as two different entities than the one that
got the /14, and now instead of submitting the detailed
documentation they started keeping not long after they got that
second /16 (so they could get the /14, and so they could get more
when the /14 filled) they'd need to spend more time and effort
than they have to dredge up utilization records for that /8 just
to get another 3 months worth of space from ARIN (even though the
scrap papers laying around and the routing tables strongly suggest
that all that space really is in use, and isn't easily reclaimed
to meet their pressing need). So they get nothing.<br>
<br>
Or imagine a large ISP which over the course of time has ended up
with a /8, two /16 and a /14 with the /14 being the most recently
issued block.<br>
<br>
Under present policy, they cannot get more space until the /14 is
documented at 80% utilization, and they're all ready to do that.<br>
<br>
Under the proposed policy, the ISP can't get any space because
while they've got great records for how the /8 and the two /16s
are utilized, the customer and internal assignments they did back
then are deemed to be inefficient by ARIN staff when they review
the utilization records for everything. All those point-to-point
links using whole /24s, and dialup pools that are sized for what
was needed back in the days of dialup but nowadays only have a
handful of customers on them aren't ok any more. So instead of
being able to just pounce on some space because of this policy
change, they're actually blocked from getting more.<br>
<br>
Overall, I think the answer is that for certain kinds of ISPs in
certain kinds of growth patterns, the change in policy would make
it easier for them to qualify. But for many others, it would make
it harder. <br>
<br>
I am not in favor of pulling the rug out from under people at the
last minute, and given how close we are to runout it would be
exactly that to change IPv4 policy on them. So I oppose this
policy as written, and any other attempts to make last-minute
changes. For people who've planned ahead, stability is the best we
can give them. For people who haven't planned ahead, they're
screwed whether we change the policy or not.<br>
</blockquote>
<br>
Matthew,<br>
<br>
Thank you for your detailed explanation of your arguments against
this policy as written. Would you support this policy after the
free pool has been exhausted? Some have suggested that this type of
policy also eases the transfer market because it refocuses an
organization on their entire address holdings and gives them a
potentially larger buffer than they could carry previously.<br>
<br>
Thanks,<br>
Andrew<br>
</body>
</html>