<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 15 (filtered medium)">
<style><!--
/* Font Definitions */
@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:Monaco;
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* 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.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.hoenzb
{mso-style-name:hoenzb;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.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">Boy did you hit the nail on the head… thanks Jason as we are one of those who are hoping to ride out this transition period and continue to have IPV4 ip’s to
feed our sales and expansion efforts…It is not a fun process right now keeping a steady supply of /22’s or /21’s coming in
<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"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> arin-ppml-bounces@arin.net [mailto:arin-ppml-bounces@arin.net]
<b>On Behalf Of </b>Jason Schiller<br>
<b>Sent:</b> Friday, May 13, 2016 2:38 PM<br>
<b>To:</b> Owen DeLong <owen@delong.com><br>
<b>Cc:</b> arin-ppml@arin.net<br>
<b>Subject:</b> Re: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">I am highly confused now.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">We have the 25% utilization check which really is the only verifiable <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">check to rate-limit aggressively optimistic requests.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">On one hand, ARIN does not check this figure. As such the policy <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">change is a no-op.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">On the other hand the 25% utilization goal remains part of the <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">policy and having no intention of complying is fraud.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">ARIN could make random checks, or check all of them.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">ARIN should check if they have reason to suspect there might<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">be fraud.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I know I worked very hard to get my recent end-user assignment<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">over 25% by the deadline. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I know in my case the 25% number limited the size of the block.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I suspect there are a lot of honest organizations / people who are<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">trying to do the right thing while maximizing their requested size<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">within the constraints of policy.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">So in that respect the policy change is not a no-op.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">It would make it easier for end-sites who want to stay <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">in compliance with policy to get more IP space by <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">simply optimistically and aggressively accelerating their <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">deployment plans by compressing a 5 or 10 year plan into <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">two years. Noting there is no harm, no foul if in two years<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">time the plans have changed, or a simply not achieved.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">On another topic... <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Arguments that IPs are being locked up outside of the <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">needs assessment and therefor we should remove the <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">needs assessment all together suggests we should <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">remove speed limits because so many people speed.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Ignoring the fraud aspect for a moment, stockpiling IP <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">addresses that are registered to you is very different <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">than a future in terms of risk profile. Lowering the risk <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">will encourage this behavior. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">If the IPs are in the free pool, or available on the transfer<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">market doesn't change the fact that the numbers are a <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">limited and shared resource whose value comes from <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">the insurance that the resource holder has exclusive <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">claim to a unique set of numbers. In fact I would argue<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">that the supply of IPs are more limited now then they <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">ever were, especially for large blocks, and especially<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">for organizations that have been priced out of the <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">market and as such stewardship is even more <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">important.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Organizations that have "delusions of grandeur" and <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">purchase "extra" IPs will not necessarily "pay dearly".<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Sure it is a costly mistake to buy what turns out to be<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">a 50 year supply of addresses. But the real window<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">is between the two years which is currently permitted<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">and the day when IPv6 has wide spread adoption <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">such that a transit provider can offer IPv6-only service<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">and their customers are not inconvenienced, and <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">content providers can offer IPv6-only service and not <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">risk losing customers that cannot reach them.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The goal is to have enough IPv4 addresses to get <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">through the transition period to when there is wide<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">spread support of IPv6, and if you can't secure that<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">much, than at least more that your competition in a <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">given market segment such that you don't have a <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">competitive disadvantage of offering a service that<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">can reach "most of the internet" and if it can reach<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">the IPv4-only Internet is will be through costly, and<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">possibly performance and security impacting <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">translation middle boxes.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">A small overage such as buying an 8 year supply <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">when you only need a 4 year supply is easily <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">justified as an insurance policy and preferable<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">to having bought a 4 year supply when you needed<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">an 8 year supply.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Nobody complains at the end of the year that they <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">wasted a bunch of money on health insurance and <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">didn't get sick all year.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">___Jason<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Fri, May 13, 2016 at 1:06 AM, Owen DeLong <<a href="mailto:owen@delong.com" target="_blank">owen@delong.com</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">I see the policy itself largely as a no-op. I have no objection for it going to the board,<o:p></o:p></p>
<div>
<p class="MsoNormal">nor do I have any significant support for it to do so.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#888888"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#888888">Owen<o:p></o:p></span></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On May 12, 2016, at 18:53 , David Farmer <<a href="mailto:farmer@umn.edu" target="_blank">farmer@umn.edu</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Monaco",serif">Jason,<br>
<br>
Even though the last call period formally ended May 9th, I try my best<br>
to consider all feedback received for a policy even following the<br>
formal last call deadline, and while I can't speak for directly for<br>
other AC members, I believe most of them do the same. However, when<br>
feedback comes in late sometimes it might not get full consideration,<br>
especially if it comes in immediately prior to one of our conference<br>
calls. To help avoid this I explicitly noted when AC would be<br>
considering the feedback. I will additionally note at this point it<br>
is extremely important to get any additional feedback in ASAP to allow<br>
the AC due time for its consideration prior to its May 19th conference<br>
call.<br>
<br>
As for the issues and questions you have raise, I believe John and<br>
Richard have been answering your questions. Further, I believe the<br>
community consensus remains to move forward with removing the 25%<br>
Immediate (30 day) use requirement for end users as this policy<br>
suggests. I would specifically ask anyone who disagrees and thinks we<br>
need to consider the issues more to speak up ASAP.<br>
<br>
Thanks.<br>
<br>
On Tue, May 10, 2016 at 11:32 AM, Jason Schiller <</span><a href="mailto:jschiller@google.com" target="_blank"><span style="font-size:9.0pt;font-family:"Monaco",serif">jschiller@google.com</span></a><span style="font-size:9.0pt;font-family:"Monaco",serif">>
wrote:<br style="text-align:start;word-spacing:0px">
<br>
</span><o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Monaco",serif">I seem to have missed the this thread in last call, and hope you<br>
will consider the discussion on the other thread: " Re: [arin-ppml]<br>
ARIN-2015-3:(remove 30-day...) Staff interpretation needed"<br>
<br>
I maintain that the 30-day [60-day for transfers] check has<br>
been useful in mitigating abusively large requests, and<br>
without it there is no teeth in the policy to prevent abuse.<br>
<br>
<br>
I asked if I was wrong about this, please explain what<br>
mechanisms are in place to mitigate an end-user asking for<br>
approval for a 10 year supply of addresses on the grounds that<br>
if things go really really well, it will only be a 2 year supply?<br>
<br>
I heard no response to indicate there was any mechanism.<br>
<br>
<br>
I asked staff about information about stats that might help<br>
determine what level of push back ARIN provides against two<br>
year projected need in general, and if that push back would be<br>
sufficient to prevent outlandishly large claims.<br>
<br>
We found that 50% - 75% of all requests are approved with<br>
past utilization more heavily weighed.<br>
<br>
It remains unclear what level of oversight ARIN has to<br>
question future looking projections. John Curran provided<br>
some text about approvals of future looking projections.<br>
<br>
"When we [ARIN] ask organization for their forward<br>
projections, we [ARIN] also ask them to provide details<br>
to show how they've arrived at their projections. We [ARIN]<br>
take into account factors such as new networks, locations,<br>
products, services they plan on offering (and this includes<br>
consideration of anticipated address utilization within the<br>
first 30 days for end-users.)<br>
<br>
From the text John provided it seems one could get IP<br>
addresses solely on future looking plans which are<br>
unverifiable. As such an end-user could easily get a 10<br>
year supply of addresses simply by providing very<br>
optimistic deployment plans for the next 24 months.<br>
<br>
<br>
<br>
I asked if I was not wrong about this, then did people realize<br>
that this policy is basically an end-run around giving out<br>
addresses based on need when they voted to move this<br>
policy forward?<br>
<br>
I heard no response to this.<br>
<br>
Thanks,<br>
<br>
__Jason<br>
<br>
<br>
On Thu, May 5, 2016 at 11:45 AM, David Farmer <<a href="mailto:farmer@umn.edu" target="_blank">farmer@umn.edu</a>> wrote:<br>
<br>
<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Monaco",serif"><br>
As shepherd for this policy I welcome any additional last call<br>
feedback for this policy. It is especially important to speak up if<br>
you feel there are any issues remaining that need to be considered.<br>
But, even if you simply support the policy as written that is<br>
important and useful feedback as well.<br>
<br>
The last call period formally continues through, Monday, May 9th, and<br>
the AC will consider the feedback during its scheduled call on<br>
Thursday, May 19th.<br>
<br>
Thanks<br>
<br>
On Mon, Apr 25, 2016 at 1:38 PM, ARIN <<a href="mailto:info@arin.net" target="_blank">info@arin.net</a>> wrote:<br>
<br>
<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Monaco",serif">The ARIN Advisory Council (AC) met on 20 April 2016 and decided to<br>
send the following to last call:<br>
<br>
Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization<br>
requirement in end-user IPv4 policy<br>
<br>
Feedback is encouraged during the last call period. All comments should<br>
be provided to the Public Policy Mailing List. This last call will<br>
expire on 9 May 2016. After last call the AC will conduct their<br>
last call review.<br>
<br>
The draft policy text is below and available at:<br>
<a href="https://www.arin.net/policy/proposals/" target="_blank">https://www.arin.net/policy/proposals/</a><br>
<br>
The ARIN Policy Development Process is available at:<br>
<a href="https://www.arin.net/policy/pdp.html" target="_blank">https://www.arin.net/policy/pdp.html</a><br>
<br>
Regards,<br>
<br>
Communications and Member Services<br>
American Registry for Internet Numbers (ARIN)<br>
<br>
<br>
## * ##<br>
<br>
<br>
Recommended Draft Policy ARIN-2015-3<br>
Remove 30 day utilization requirement in end-user IPv4 policy<br>
<br>
AC's assessment of conformance with the Principles of Internet Number<br>
Resource Policy:<br>
<br>
ARIN 2015-3 contributes to fair and impartial number resource<br>
administration<br>
by removing from the NRPM text that is operationally unrealistic for the<br>
reasons discussed in the problem statement. This proposal is technically<br>
sound, in that the removal of the text will more closely align with the<br>
way<br>
staff applies the existing policy in relation to 8.3 transfers. There<br>
was<br>
strong community support for the policy on PPML and at ARIN 36, which<br>
was<br>
confirmed at ARIN 37. There was a suggestion to replace this text with<br>
an<br>
alternate requirement. However, the community consensus was to move<br>
forward<br>
with the removal alone.<br>
<br>
The staff and legal review also suggested removing RFC2050 references<br>
and<br>
pointed out that 4.2.3.6 has an additional 25% immediate use clause,<br>
community feedback was to deal with those issues separately.<br>
<br>
Problem Statement:<br>
<br>
End-user policy is intended to provide end-users with a one year supply<br>
of<br>
IP addresses. Qualification for a one-year supply requires the network<br>
operator to utilize at least 25% of the requested addresses within 30<br>
days.<br>
This text is unrealistic and should be removed.<br>
<br>
First, it often takes longer than 30 days to stage equipment and start<br>
actually using the addresses.<br>
<br>
Second, growth is often not that regimented; the forecast is to use X<br>
addresses over the course of a year, not to use 25% of X within 30 days.<br>
<br>
Third, this policy text applies to additional address space requests. It<br>
is<br>
incompatible with the requirements of other additional address space<br>
request<br>
justification which indicates that 80% utilization of existing space is<br>
sufficient to justify new space. If a block is at 80%, then often<br>
(almost<br>
always?) the remaining 80% will be used over the next 30 days and<br>
longer.<br>
Therefore the operator cannot honestly state they will use 25% of the<br>
ADDITIONAL space within 30 days of receiving it; they're still trying to<br>
use<br>
their older block efficiently.<br>
<br>
Fourth, in the face of ARIN exhaustion, some ISPs are starting to not<br>
give<br>
out /24 (or larger) blocks. So the justification for the 25% rule that<br>
previously existed (and in fact, applied for many years) is no longer<br>
germane.<br>
<br>
Policy statement:<br>
<br>
Remove the 25% utilization criteria bullet point from NRPM 4.3.3.<br>
<br>
Resulting text:<br>
<br>
4.3.3. Utilization rate<br>
<br>
Utilization rate of address space is a key factor in justifying a new<br>
assignment of IP address space. Requesters must show exactly how<br>
previous<br>
address assignments have been utilized and must provide appropriate<br>
details<br>
to verify their one-year growth projection.<br>
<br>
The basic criterion that must be met is a 50% utilization rate within<br>
one<br>
year.<br>
<br>
A greater utilization rate may be required based on individual network<br>
requirements. Please refer to RFC 2050 for more information on<br>
utilization<br>
guidelines.<br>
<br>
Comments:<br>
<br>
a.Timetable for implementation: Immediate<br>
<br>
b.Anything else<br>
<br>
#####<br>
<br>
ARIN STAFF ASSESSMENT<br>
<br>
Draft Policy ARIN-2015-3<br>
Remove 30 day utilization requirement in end-user IPv4 policy<br>
Date of Assessment: 16 February 2016<br>
<br>
___<br>
1. Summary (Staff Understanding)<br>
<br>
This proposal would remove the 25% utilization (within 30 days of<br>
issuance)<br>
criteria bullet point from NRPM 4.3.3.<br>
<br>
___<br>
2. Comments<br>
<br>
A. ARIN Staff Comments<br>
This policy would more closely align with the way staff applies the<br>
existing<br>
policy in relation to 8.3 transfers. Because there is no longer an IPv4<br>
free<br>
pool and many IPv4 requests are likely to be satisfied by 8.3 transfers,<br>
the<br>
adoption of this policy should have no major impact on operations and<br>
could<br>
be implemented as written.<br>
<br>
Note that both NRPM 4.3.3 and NRPM 4.2.3.6 contain references to<br>
obsolete<br>
RFC 2050. Additionally, 4.2.3.6 references the 25% immediate use (within<br>
30<br>
days of issuance) requirement.<br>
<br>
Staff suggests removing the first two sentences of 4.2.3.6 to remove the<br>
references to RFC 2050 and the 25% requirement. Additionally, staff<br>
suggests<br>
removing the reference to the obsolete RFC 2050 in section 4.3.3.<br>
<br>
B. ARIN General Counsel – Legal Assessment<br>
No material legal risk in this policy.<br>
<br>
___<br>
3. Resource Impact<br>
<br>
This policy would have minimal resource impact from an implementation<br>
aspect. It is estimated that implementation would occur immediately<br>
after<br>
ratification by the ARIN Board of Trustees. The following would be<br>
needed in<br>
order to implement:<br>
* Updated guidelines and internal procedures<br>
* Staff training<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" target="_blank">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" target="_blank">info@arin.net</a> if you experience any issues.<o:p></o:p></span></p>
</blockquote>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Monaco",serif"><br>
<br>
<br>
--<br>
===============================================<br>
David Farmer Email:farmer@<a href="http://umn.edu" target="_blank">umn.edu</a><br>
Networking & Telecommunication Services<br>
Office of Information Technology<br>
University of Minnesota<br>
2218 University Ave SE Phone: <a href="tel:612-626-0815" target="_blank">612-626-0815</a><br>
Minneapolis, MN 55414-3029 Cell: <a href="tel:612-812-9952" target="_blank">612-812-9952</a><br>
===============================================<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" target="_blank">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" target="_blank">info@arin.net</a> if you experience any issues.<o:p></o:p></span></p>
</blockquote>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:9.0pt;font-family:"Monaco",serif"><br>
<br>
<br>
<br>
--<br>
_______________________________________________________<br>
Jason Schiller|NetOps|<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a>|<a href="tel:571-266-0006" target="_blank">571-266-0006</a><o:p></o:p></span></p>
</blockquote>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Monaco",serif"><br>
<br>
<br>
-- <br>
===============================================<br>
David Farmer Email:</span><a href="mailto:farmer@umn.edu" target="_blank"><span style="font-size:9.0pt;font-family:"Monaco",serif">farmer@umn.edu</span></a><span style="font-size:9.0pt;font-family:"Monaco",serif"><br>
Networking & Telecommunication Services<br>
Office of Information Technology<br>
University of Minnesota<br>
2218 University Ave SE Phone: <a href="tel:612-626-0815" target="_blank">612-626-0815</a><br>
Minneapolis, MN 55414-3029 Cell: <a href="tel:612-812-9952" target="_blank">612-812-9952</a><br>
===============================================<br>
_______________________________________________<br>
PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (</span><a href="mailto:ARIN-PPML@arin.net" target="_blank"><span style="font-size:9.0pt;font-family:"Monaco",serif">ARIN-PPML@arin.net</span></a><span style="font-size:9.0pt;font-family:"Monaco",serif">).<br>
Unsubscribe or manage your mailing list subscription at:<br>
</span><a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank"><span style="font-size:9.0pt;font-family:"Monaco",serif">http://lists.arin.net/mailman/listinfo/arin-ppml</span></a><span style="font-size:9.0pt;font-family:"Monaco",serif"><br>
Please contact </span><a href="mailto:info@arin.net" target="_blank"><span style="font-size:9.0pt;font-family:"Monaco",serif">info@arin.net</span></a><span style="font-size:9.0pt;font-family:"Monaco",serif"> if you experience any issues.</span><o:p></o:p></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier New";color:#555555">_______________________________________________________</span><span style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-family:"Courier New";color:black">Jason Schiller|NetOps|<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a>|571-266-0006</span><span style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>