<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>On Jul 21, 2017, at 8:31 PM, John Springer <<a href="mailto:3johnl@gmail.com">3johnl@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">I support this Draft Policy as re-written.<div><br></div><div>I shared the author's distaste for the requirement that IPV6 /64s be SWIP'd, but was not reassured when the discussion veered to consider prefixes between /48 and /64. AFAIK, ISPs have long been encouraged to apply for their allocations based on the idea of assigning a /48 to each 'customer' to provide room for unknown technologies, among other things. I did not wish to endanger that premise, but current language appears to moot that concern.</div><div><br></div><div>To be explicit, to me, "/47 or more addresses, or sub-delegation of any size that will be individually announced," refers to /47s, /46s, /45s ... and not /48s, /49s, /50s, etc.</div></div></div></blockquote><div><br></div><div>That's not what it says. It says /48s (or longer) should be individually SWIPped if they're going to be announced. Otherwise there's no reason for the extra clause. </div><div><br></div><div>Blocks in the GRT need to be SWIPped to the announcing party if that's a different organization from the holder of the larger block. </div><div><br></div><div>-Scott</div><br><blockquote type="cite"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 21, 2017 at 9:44 AM, Leif Sawyer <span dir="ltr"><<a href="mailto:lsawyer@gci.com" target="_blank">lsawyer@gci.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-US" link="blue" vlink="purple">
<div class="m_-4922502725559143804WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">Happy Friday, everybody.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">As promised, here is the latest rewrite of the draft policy below,  and it will soon be updated at:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366"><a href="https://www.arin.net/policy/proposals/2017_5.html" target="_blank">https://www.arin.net/policy/<wbr>proposals/2017_5.html</a><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">There are two changes noted in the policy statement: the first of which reflects what seems to be the current<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">consensus of the PPML regarding netblock sizing; the second is to strike language that may be read as either restrictive<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">or non-operational.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">----<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">Problem Statement:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">       Current ARIN policy has different WHOIS directory registration requirements for IPv4 vs IPv6 address assignments. 
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">       IPv4 registration is triggered for an assignment of any address block equal to or greater than a /29 (i.e., eight IPv4 addresses).<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">       In the case of IPv6, registration occurs for an assignment of any block equal to or greater than a /64, which constitutes one entire IPv6 subnet and
 is the minimum block size for an allocation.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">       Accordingly, there is a significant disparity between IPv4 and IPv6 WHOIS registration thresholds in the case of assignments, resulting in more work
 in the case of IPv6 than is the case for IPv4.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">       There is no technical or policy rationale for the disparity, which could serve as a deterrent to more rapid IPv6 adoption.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">       The purpose of this proposal is to eliminate the disparity and corresponding adverse consequences.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">Policy statement:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">       1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to strike "/64 or more addresses" and change to "/47 or more addresses, or sub-delegation
 of any size that will be individually announced,"<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">and 
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">       2) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the NRPM by deleting the phrase "holding /64 and larger blocks"<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">Comments:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">a.    Timetable for implementation:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">       Policy should be adopted as soon as possible.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">b.    Anything else:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">    Author Comments:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">         IPv6 should not be more burdensome than the equivalent IPv4 network size.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">         Currently, assignments of /29 or more of IPv4 space (8 addresses) require registration<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">         The greatest majority of ISP customers who have assignments of IPv4 space are of a single IPv4 address which do not trigger any ARIN registration requirement
 when using IPv4.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">         This is NOT true when these same exact customers use IPv6, as assignments of /64 or more of IPv6 space require registration. 
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">         Beginning with RFC 3177, it has been standard practice to assign a minimum assignment of /64 to every customer end user site, and less is never used. 
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">         This means that ALL IPv6 assignments, including those customers that only use a single IPv4 address must be registered with ARIN if they are given
 the minimum assignment of /64 of IPv6 space.  <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">         This additional effort may prevent ISP's from giving IPv6 addresses because of the additional expense of registering those addresses with ARIN, which
 is not required for IPv4.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">         The administrative burden of 100% customer registration of IPv6 customers is unreasonable, when such is not required for those customers receiving
 only IPv4 connections.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">---<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">Leif Sawyer<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">Advisory Council<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366"><u></u> <u></u></span></p>
</div>
</div>

<br>______________________________<wbr>_________________<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" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br></blockquote></div><br></div>
</blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>PPML</span><br><span>You are receiving this message because you are subscribed to</span><br><span>the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).</span><br><span>Unsubscribe or manage your mailing list subscription at:</span><br><span><a href="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</a></span><br><span>Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.</span></div></blockquote></body></html>