<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>+1<br>
</p>
<br>
<div class="moz-cite-prefix">On 7/21/2017 12:34 PM, Scott Leibrand
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAGkMwz7z-wzrFZRd4JRCHBmpY5F1bpiAoayqs4RnACatvSsykg@mail.gmail.com">
<div dir="ltr">This looks good: I support.
<div><br>
</div>
<div>For clarity, so we don't all have to do it, and to help
make sure we're not missing anything, here's what the
resulting 6.5.5 looks like after modification:</div>
<div><br>
</div>
<div>
<div>6.5.5. Registration</div>
<div><br>
</div>
<div>ISPs are required to demonstrate efficient use of IP
address space allocations by providing appropriate
documentation, including but not limited to assignment
histories, showing their efficient use.</div>
<div><br>
</div>
<div>6.5.5.1. Reassignment information</div>
<div><br>
</div>
<div>Each static IPv6 assignment containing a <span
style="color:rgb(153,51,102);font-family:Calibri,sans-serif;font-size:14.6667px">/47
or more addresses, or sub-delegation of any size that will
be individually announced,</span> shall be registered in
the WHOIS directory via SWIP or a distributed service which
meets the standards set forth in section 3.2. Reassignment
registrations shall include each client's organizational
information, except where specifically exempted by this
policy.</div>
<div><br>
</div>
<div>6.5.5.2. Assignments visible within 7 days</div>
<div><br>
</div>
<div>All assignments shall be made visible as required in
section 4.2.3.7.1 within seven calendar days of assignment.</div>
<div><br>
</div>
<div>6.5.5.3. Residential Subscribers</div>
<div><br>
</div>
<div>6.5.5.3.1. Residential Customer Privacy</div>
<div><br>
</div>
<div>To maintain the privacy of their residential customers,
an organization with downstream residential customers may
substitute that organization's name for the customer's name,
e.g. 'Private Customer - XYZ Network', and the customer's
street address may read 'Private Residence'. Each private
downstream residential reassignment must have accurate
upstream Abuse and Technical POCs visible on the WHOIS
record for that block.</div>
<div><br>
</div>
<div>-Scott</div>
</div>
</div>
<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" moz-do-not-send="true">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 link="blue" vlink="purple" lang="EN-US">
<div class="m_-9114795104324841326WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">Happy
Friday, everybody.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366"> </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:</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"
moz-do-not-send="true">https://www.arin.net/policy/<wbr>proposals/2017_5.html</a></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366"> </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</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</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">or
non-operational.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">----</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">Problem
Statement:</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.
</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).</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.</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.</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.</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.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">Policy
statement:</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,"</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">and
</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"</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">Comments:</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">a.
Timetable for implementation:</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.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">b.
Anything else:</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366"> Author
Comments:</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.</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</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.</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.
</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.
</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. </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.</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.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">---</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">Leif
Sawyer</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">Advisory
Council</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366"> </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" moz-do-not-send="true">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" moz-do-not-send="true">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net"
moz-do-not-send="true">info@arin.net</a> if you experience
any issues.<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (<a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).
Unsubscribe or manage your mailing list subscription at:
<a class="moz-txt-link-freetext" href="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</a>
Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.</pre>
</blockquote>
<br>
</body>
</html>