<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"MS Mincho";
panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
{font-family:"MS Mincho";
panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"\@MS Mincho";
panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
{font-family:"Trebuchet MS";
panose-1:2 11 6 3 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Being that it is an improvement, I could live with David Huberman’s verbiage. I support what you are trying to accomplish since it is a step in the right direction.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">In the big picture as I’ve mentioned before I support an overhaul of current ARIN policies in the same way as this proposal that was submitted over in the RIPE
region:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><a href="https://www.ripe.net/ripe/policies/proposals/2013-03">https://www.ripe.net/ripe/policies/proposals/2013-03</a> and I recognize this would be a significant
change to current ARIN policy requiring considerable work by the talented policy makers in this community. This proposal says it in a much better way than I ever could. Not sure if you can find language to your liking in it but if you haven’t looked at this
then I think it is worth your time. Cheers!<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><i><span style="font-size:11.0pt;font-family:"Trebuchet MS","sans-serif";color:#1F497D">Steven Ryerse<o:p></o:p></span></i></p>
<p class="MsoNormal"><i><span style="font-size:11.0pt;font-family:"Trebuchet MS","sans-serif";color:#1F497D">President<o:p></o:p></span></i></p>
<p class="MsoNormal"><i><span style="font-size:11.0pt;font-family:"Trebuchet MS","sans-serif";color:#1F497D">100 Ashford Center North, Suite 110, Atlanta, GA 30338<o:p></o:p></span></i></p>
<p class="MsoNormal"><i><span style="font-size:11.0pt;font-family:"Trebuchet MS","sans-serif";color:#1F497D">770.656.1460 - Cell<o:p></o:p></span></i></p>
<p class="MsoNormal"><i><span style="font-size:11.0pt;font-family:"Trebuchet MS","sans-serif";color:#1F497D">770.399.9099- Office<o:p></o:p></span></i></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"MS Mincho";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><img border="0" width="56" height="37" id="Picture_x0020_1" src="cid:image001.jpg@01CEEA05.BE8D9950" alt="Description: Description: Eclipse Networks Logo_small.png"></span><span style="font-size:10.0pt;font-family:"MS Mincho";color:#1F497D">℠</span><span style="font-size:14.0pt;font-family:"Trebuchet MS","sans-serif";color:#1F497D">
</span><span style="font-size:11.0pt;font-family:"Trebuchet MS","sans-serif";color:#1F497D">Eclipse Networks, Inc.</span><span style="font-size:14.0pt;font-family:"Trebuchet MS","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal" style="text-indent:.5in"><sup><span style="font-size:9.0pt;font-family:"Trebuchet MS","sans-serif";color:#1F497D"> Conquering Complex Networks</span></sup><sup><span style="font-size:9.0pt;font-family:"Calibri","sans-serif";color:#1F497D">℠</span></sup><sup><span style="font-size:9.0pt;font-family:"Trebuchet MS","sans-serif";color:#1F497D"><o:p></o:p></span></sup></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Scott Leibrand [mailto:scottleibrand@gmail.com]
<br>
<b>Sent:</b> Monday, November 25, 2013 4:40 PM<br>
<b>To:</b> Steven Ryerse<br>
<b>Cc:</b> arin-ppml@arin.net<br>
<b>Subject:</b> Re: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Steven,<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Do you have some specific policy language (or can you point to specific language from another region) to illustrate how you think new allocations should be appropriately sized? I understand that you want something simpler and more liberal
than both the current ISP and end-user requirements, but I'm not completely clear on what that would look like.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Scott<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Mon, Nov 25, 2013 at 1:29 PM, Steven Ryerse <<a href="mailto:SRyerse@eclipse-networks.com" target="_blank">SRyerse@eclipse-networks.com</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal">My opinion absolutely does not change just because organizations have been made to jump thru unnecessary hoops for 16 years. I strongly think that needs to be corrected. Obviously I'm not alone in that opinion given that other's in other
regions have made similar proposals.<br>
<br>
As I said I agree with and support what Scott is trying to accomplish as it is a slight improvement to the status quo.<o:p></o:p></p>
<div>
<p class="MsoNormal"><br>
Steven Ryerse<br>
President<br>
100 Ashford Center North, Suite 110, Atlanta, GA 30338<br>
<a href="tel:770.656.1460">770.656.1460</a> - Cell<br>
<a href="tel:770.399.9099">770.399.9099</a>- Office<br>
<br>
<span style="font-family:"MS Mincho"">℠</span> Eclipse Networks, Inc.<br>
Conquering Complex Networks<span style="font-family:"MS Mincho"">℠</span><br>
<br>
<br>
-----Original Message-----<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">From: David Huberman [mailto:<a href="mailto:David.Huberman@microsoft.com">David.Huberman@microsoft.com</a>]<br>
Sent: Monday, November 25, 2013 4:23 PM<br>
To: Steven Ryerse; '<a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a>'<br>
Subject: RE: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion<br>
<br>
Ok, quick question then:<br>
<br>
Does your opinion change if I tell you that 4.2.0, 4.2.1, 4.3.0, and 4.3.1 are the exact rules end-users have been subject to for 16 years? ARIN has reviewed thousands and thousands of requests every year under the policy framework described in 4.2.0, 4.2.1,
4.3.0, and 4.3.1.<br>
<br>
And a quick observation:<br>
<br>
Scott's proposed change isn't big at all. It just lowers the bar from /22 to /24 (a good thing) using a mechanic that hasn't worked for newer/smaller ISPs (yourself included, Steven, as you told this list many times when you first joined) in a long time.<br>
<br>
<br>
David R Huberman<br>
Microsoft Corporation<br>
Senior IT/OPS Program Manager (GFS)<br>
<br>
-----Original Message-----<br>
From: Steven Ryerse [mailto:<a href="mailto:SRyerse@eclipse-networks.com">SRyerse@eclipse-networks.com</a>]<br>
Sent: Monday, November 25, 2013 1:18 PM<br>
To: David Huberman; '<a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a>'<br>
Subject: RE: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion<br>
<br>
I'm all for eliminating the definition of what constitutes an end user vs. ISP vs. whatever, as it doesn't really matter unless there is a technical issue involved that ARIN needs to manage. I also agree that it might be easier making smaller steps to fixing
these kinds of issues given the dramatic difference of opinion surrounding how blocks should be allocated.<br>
<br>
I would point out though that in real life the requirements set out below in Sections 4.2.0, 4.2.1, 4.3.0, and 4.3.1 can all be manipulated and I'm sure that in past real life requests that ARIN has received and allocated, some organizations have done so to
get a successful allocation request filled. I don't believe ARIN goes back and checks to see if an organization met their predicated allocations in the timeframe policies require. The requirements based on future usage require us to be able to predict the
future and of course none of us really can do that.<br>
<br>
I am for what Scott is trying to accomplish. I know it would be a big change in policy but isn't it finally time to jettison the needs tests altogether and just allocate based on rightsizing blocks allocated to the size of the requesting organization and the
size of their existing network and existing allocations. Requiring organizations to predict the future and fudge their numbers just to get a block allocated is not what we want to incent organizations to do. Regardless of the original intentions this is
just a game organizations are forced to play and why would this community want to force anyone to do that?<br>
<br>
Just my two cents.<br>
<br>
Steven Ryerse<br>
President<br>
100 Ashford Center North, Suite 110, Atlanta, GA 30338<br>
770.656.1460 - Cell<br>
770.399.9099- Office<br>
<br>
<span style="font-family:"MS Mincho"">℠</span> Eclipse Networks, Inc.<br>
Conquering Complex Networks<span style="font-family:"MS Mincho"">℠</span><br>
<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:arin-ppml-bounces@arin.net">arin-ppml-bounces@arin.net</a> [mailto:<a href="mailto:arin-ppml-bounces@arin.net">arin-ppml-bounces@arin.net</a>] On Behalf Of David Huberman<br>
Sent: Monday, November 25, 2013 3:46 PM<br>
To: '<a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a>'<br>
Subject: Re: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion<br>
<br>
Scott wrote:<br>
<br>
> I'm not sure it's all that helpful to ask me to re-justify the entire<br>
> NRPM. That requirement, in a more strict form, is what is present in the NRPM today.<br>
<br>
But we can't make policy for policy's sake. ARIN exists to, in part, provide number resources to the operator community who needs them. Section 4 of the NRPPM serves the needs of the network operator community circa 1996, not 2014 and beyond. So how about:<br>
<br>
4.2.0:<br>
<br>
An ISP can obtain an initial allocation of a /24 or larger by demonstrating a need to use at least 25% of the space within 90 days, and at least 50% of the space within one year.<br>
<br>
4.2.1<br>
<br>
An ISP can obtain an additional allocations by demonstrating 80% or better utilization of existing address space. The additional allocation block size determination uses the criterion in 4.2.0<br>
<br>
4.3.0<br>
<br>
An end-user can obtain an initial assignment of a /24 or larger by demonstrating a need to use at least 25% of the space within 90 days, and at least 50% of the space within one year.<br>
<br>
4.3.1<br>
<br>
An end-user can obtain an additional assignment by demonstrating 80% or better utilization of existing address space. The additional assignment block size determination uses the criterion in 4.3.0<br>
<br>
Throw in a section on SWIP, keep 4.5 MDN as-is, and presto, you're done with section 4, and you've fixed NRPM 8.3 and you've harmonized the very broken ISP v End-user mechanic.<br>
<br>
Doesn't this serve the network operator community in 2014 better than making small changes to walls and walls of text from 1996?<br>
<br>
David R Huberman<br>
Microsoft Corporation<br>
Senior IT/OPS Program Manager (GFS)<br>
_______________________________________________<br>
PPML<br>
You are receiving this message because you are subscribed to 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.<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.<o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>