<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)">
<base href="x-msg://26642/"><style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:"MS Mincho";
panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 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.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle18
{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-size:10.0pt;}
@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">I don’t view this to be needs based at all, I view it to be a way to right size allocations without the needs tests. For example nowhere does it ask for router
ARP logs or any other form of proof of need nor does it ask how long it will take to use up the allocation. It just asks what size network are you now with size of org thrown in for larger allocation requests. It also empowers ARIN management to consider
unusual situations and allows ARIN to give a positive allocation if ARIN deems it reasonable after discussion. It simplifies a lot and could replace several policies. It removes the need to even define which org is an end user and which org is an ISP. It
levels the playing field which in my opinion needs to be done. I think this is pretty far from the current allocation policies. This is a simple way to accomplish what has been proposed for RIPE to remove all of the needs test from their policies. Simple
is good and simple is fair.<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>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<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""> Owen DeLong [mailto:owen@delong.com]
<br>
<b>Sent:</b> Wednesday, July 17, 2013 4:21 PM<br>
<b>To:</b> Steven Ryerse<br>
<b>Cc:</b> Blake Dunlap; arin-ppml@arin.net<br>
<b>Subject:</b> Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">You've just described pretty much what happens now. This is, to me at least, indistinguishable other than a few subtle operational details from the current needs-basis policy and process(es).<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Owen<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<p class="MsoNormal">On Jul 15, 2013, at 3:53 PM, Steven Ryerse <<a href="mailto:SRyerse@eclipse-networks.com">SRyerse@eclipse-networks.com</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">If you are publicly traded and your company’s revenues are public then the size of the company is available to all. This could be used to make sure only a
large organization who might actually have use for it can get a /8 or other large block size. The other info that could be used is how much resource does an org have now. If they have a /8 they might really have use for another /8. If they have a /22 they
might really have use for another /22. Obviously the org with a /22 isn’t likely to have use for a /8. Orgs with multiple allocations already can add them together including legacy blocks. An org that has no allocation or one up to a /22 allocation should
be able to qualify for the currently defined minimum sized block which I believe is currently a /22 . The rare case where an org with a very small or no current allocation has use for a very large block can be handled as an exception with more proof required
that the block they are requesting – I’m thinking this would require a manager at ARIN to handle. I’m guessing it is rare that an org needs to add more than double what they already have allocated and those can be special cases handled as exceptions with
additional proof required. In this way the blocks allocated are right sized for the size of the org requesting the allocation. There are some smart folks in this community who might be able to tweak this idea and make it better, especially for larger allocations. </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><i><span style="font-size:11.0pt;font-family:"Trebuchet MS","sans-serif";color:#1F497D">Steven L Ryerse</span></i><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><i><span style="font-size:11.0pt;font-family:"Trebuchet MS","sans-serif";color:#1F497D">President</span></i><o:p></o:p></p>
</div>
<div>
<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</span></i><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><i><span style="font-size:11.0pt;font-family:"Trebuchet MS","sans-serif";color:#1F497D">770.656.1460 - Cell</span></i><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><i><span style="font-size:11.0pt;font-family:"Trebuchet MS","sans-serif";color:#1F497D">770.399.9099 - Office</span></i><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><i><span style="font-size:11.0pt;font-family:"Trebuchet MS","sans-serif";color:#1F497D">770.392-0076 - Fax</span></i><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"MS Mincho";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><image001.jpg></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><o:p></o:p></p>
</div>
<div>
<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><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span class="apple-converted-space"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> </span></span><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">Blake
Dunlap [mailto:ikiris@<a href="http://gmail.com"><span style="color:purple">gmail.com</span></a>]<span class="apple-converted-space"> </span><br>
<b>Sent:</b><span class="apple-converted-space"> </span>Monday, July 15, 2013 3:01 PM<br>
<b>To:</b><span class="apple-converted-space"> </span>Steven Ryerse<br>
<b>Cc:</b><span class="apple-converted-space"> </span>Matthew Wilder; David Farmer;<span class="apple-converted-space"> </span><a href="mailto:arin-ppml@arin.net"><span style="color:purple">arin-ppml@arin.net</span></a><br>
<b>Subject:</b><span class="apple-converted-space"> </span>Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Exactly how is this "right sized allocation" based on network size different than needs basis allocation?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">-Blake<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">On Mon, Jul 15, 2013 at 11:02 AM, Steven Ryerse <<a href="mailto:SRyerse@eclipse-networks.com" target="_blank"><span style="color:purple">SRyerse@eclipse-networks.com</span></a>> wrote:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Note that I did say "right sized allocations" and have said multiple times that it is fine to match allocations with the size of the organization and/or the size of the organization's current network. I also have stated that we need to
be good technical stewards and I think most folks here agree with that. I do not think a small organization like ours for example should ever get the technical equivalent of a /8 or even close to it. I do strongly think that every organization should be
able to get a right sized allocation if they are going to use it as that grows the Internet - which in case folks forget is ARIN's mission.<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><br>
Steven L Ryerse<br>
President<br>
100 Ashford Center North, Suite 110, Atlanta, GA 30338<br>
770.656.1460 - Cell<br>
770.399.9099 - Office<br>
770.392-0076 - Fax<br>
<br>
<span style="font-family:"MS Mincho"">℠</span><span class="apple-converted-space"> </span>Eclipse Networks, Inc.<br>
Conquering Complex Networks<span style="font-family:"MS Mincho"">℠</span><br>
<br>
-----Original Message-----<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">From: Matthew Wilder [mailto:<a href="mailto:Matthew.Wilder@telus.com"><span style="color:purple">Matthew.Wilder@telus.com</span></a>]<br>
Sent: Friday, July 12, 2013 12:18 PM<br>
To: Steven Ryerse; David Farmer<br>
Cc:<span class="apple-converted-space"> </span><a href="mailto:arin-ppml@arin.net"><span style="color:purple">arin-ppml@arin.net</span></a><br>
Subject: RE: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles - revised<br>
<br>
In that case, I would like to request a /8 of IPv6 space. That seems right to me since conservation isn't a concern anymore.<br>
<br>
To be clear, IP Address schemes can only be updated so far. As far as I can tell IPv4 address schemes have never extended beyond the initial 32 bits they started off with, and IPv6 also will not change from a 128 bit address length. Granted, CIDR was introduced
to IPv4 to extend the timeline for exhaust of IPv4 address resources, but this is exceptional, and not the rule (certainly for the future).<br>
<br>
And the cost you mention is not a negligible one. Think of the amount of time and energy that has already gone into IPv6 only to approach 2% of global IP traffic on IPv6. I believe it is in the community's best interest to conserve the word conservation in
some form. As David said, the conservation of IPv6 resources is going to be much different than conservation of IPv4 resources.<br>
<br>
By the way, for those not following, there is a push from many member nations of the ITU and others in the international community to redistribute the governance of the internet in their interests. Do not be surprised if the nations gain the ability to allocate
IP Address resources to the entities within their borders. In that world, IPv6 exhaust is only a short matter of time. If we can at least embed the concept of conservation of IPv6 resources now in some way, the global community will thank us a generation
or two from now.<br>
<br>
mw<br>
<br>
On July 12, 2013 at 08:50 AM, "Steven Ryerse" <<a href="mailto:SRyerse@eclipse-networks.com"><span style="color:purple">SRyerse@eclipse-networks.com</span></a>> wrote:<br>
<br>
> I disagree. Unlike say land which they aren't making more of, address schemes can alway be updated like IPv4 to IPv6. When IPv6 runs out we'll switch to IPv8 or whatever (albeit at a cost) or something better than IP. Thus we don't need to conserve at all
- we just need to do right sized allocations so we don't have to pay the additional cost to switch sooner than we have to. Nothing like ipv4 or ipv6 or asn numbers need to somehow be conserved for a rainy day if there are folks that want to use them.<br>
<br>
<br>
> Bill is right that the word conserve needs to be removed.<br>
<br>
> Sent from my iPhone<br>
<br>
> On Jul 11, 2013, at 7:59 PM, "David Farmer" <<a href="mailto:farmer@umn.edu"><span style="color:purple">farmer@umn.edu</span></a>> wrote:<br>
<br>
> > I really don't understand this debate on Conservation. :{<br>
> ><br>
> > There are some that seem to be claim that conservation is irrelevant with IPv4 free pool run-out.<br>
> ><br>
> > I say so what! We still have IPv6 and ASNs to worry about, and while both resource pools are GARGANTUAN by comparison, they are not infinite. Therefore some concept of conservation remains necessary, obviously not the same concept that we have had in
IPv4 for the last 20 years or so. But, completely eliminating conservation as a concept, principle, or goal, of how we manage Internet number resources, seems like the proverbial "throwing the baby out with the bath water."<br>
> ><br>
> > Then others are not willing to concede that anything changes with IPv4 run-out.<br>
> ><br>
> > I'll can say I really hope something changes, the focus on conservation that became necessary in the late '90s for IPv4, has nearly lead to the abandonment of other principles like the end-to-end model, open availability of resources (anyone building a
network should be able to get unique addresses), etc...<br>
> ><br>
> > So how do we move forward? I suggest;<br>
> ><br>
> > 1. Can everyone concede that going forward, conservation is much less important, but that the need for some concept of conservation doesn't completely go away either.<br>
> ><br>
> > 2. Lets focus the conversation on other issues for a while, let this cool down a little, then come back to it after we've cooled down and maybe have resolved some of the other issues.<br>
> ><br>
> > 3. Are there other concepts, principles, or goals that were missing?<br>
> > I suggested earlier that there were additional principles we should<br>
> > be looking at. An candidates has come up in the conversation today<br>
> > that I would like to propose;<br>
> ><br>
> > 0.2 Fair Distribution<br>
> ><br>
> > The principle of Fair Distribution is the precept that the<br>
> > fundamental purpose of Internet number resources management is to<br>
> > distributed unique number resources in a fair and impartial manner<br>
> > to entities building and operating networks, for benefit of all<br>
> > Internet users equally, and thereby facilitating the growth and<br>
> > sustainability of the Internet.<br>
> ><br>
> > I'd make this #2 behind Registration, and I'd suggest Conservation could follow and ties into this principle through the concepts of "fairness" and "sustainability"<br>
> ><br>
> > Thanks<br>
> > --<br>
> > ================================================<br>
> > David Farmer Email:<span class="apple-converted-space"> </span><a href="mailto:farmer@umn.edu"><span style="color:purple">farmer@umn.edu</span></a><br>
> > Office of Information Technology<br>
> > University of Minnesota<br>
> > 2218 University Ave SE Phone: 1-612-626-0815<br>
> > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952<br>
> > ================================================<br>
> > _______________________________________________<br>
> > PPML<br>
> > You are receiving this message because you are subscribed to the<br>
> > ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net"><span style="color:purple">ARIN-PPML@arin.net</span></a>).<br>
> > Unsubscribe or manage your mailing list subscription at:<br>
> ><span class="apple-converted-space"> </span><a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank"><span style="color:purple">http://lists.arin.net/mailman/listinfo/arin-ppml</span></a><br>
> > Please contact<span class="apple-converted-space"> </span><a href="mailto:info@arin.net"><span style="color:purple">info@arin.net</span></a><span class="apple-converted-space"> </span>if you experience any issues.<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"><span style="color:purple">ARIN-PPML@arin.net</span></a>).<br>
> Unsubscribe or manage your mailing list subscription at:<br>
><span class="apple-converted-space"> </span><a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank"><span style="color:purple">http://lists.arin.net/mailman/listinfo/arin-ppml</span></a><br>
> Please contact<span class="apple-converted-space"> </span><a href="mailto:info@arin.net"><span style="color:purple">info@arin.net</span></a><span class="apple-converted-space"> </span>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"><span style="color:purple">ARIN-PPML@arin.net</span></a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank"><span style="color:purple">http://lists.arin.net/mailman/listinfo/arin-ppml</span></a><br>
Please contact<span class="apple-converted-space"> </span><a href="mailto:info@arin.net"><span style="color:purple">info@arin.net</span></a><span class="apple-converted-space"> </span>if you experience any issues.<o:p></o:p></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"">_______________________________________________<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"><span style="color:purple">ARIN-PPML@arin.net</span></a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml"><span style="color:purple">http://lists.arin.net/mailman/listinfo/arin-ppml</span></a><br>
Please contact<span class="apple-converted-space"> </span><a href="mailto:info@arin.net"><span style="color:purple">info@arin.net</span></a><span class="apple-converted-space"> </span>if you experience any issues.<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>