<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>+1 Also support "shall" rather than "should"</p>
<p>Remember that this is a relaxation of requirements, not an
increase. Current requirements require ALL /64 and larger be
registered in WHOIS. This policy requires registration for /48 to
/64 assignments only if the recipient requests it.<br>
</p>
<br>
<div class="moz-cite-prefix">On 10/12/2017 9:39 AM, Jason Schiller
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAC4yj2Vst2vGs1ntV86OFV_vMyiXC+JaM7mFraxxVe3e_u92mA@mail.gmail.com">
<div dir="ltr">Support as written (amended with Shall).
<div><br>
</div>
<div>As a follow up to Owen, clarity is important.</div>
<div>I urge those who do not support it as written (amended with
Shall)</div>
<div>to also note if they would support it without the shall
amendment.</div>
<div><br>
</div>
<div><br>
</div>
<div>Also as a separate question to supporting the proposal </div>
<div>is if the process is supported. </div>
<div><br>
</div>
<div>
<div>Can the PPM chair call separate questions? </div>
<div>Yes.</div>
</div>
<div><br>
</div>
<div>Can the Shepherd / AC make (minor) text changes after the
30 day freeze?</div>
<div>Yes.</div>
<div><br>
</div>
<div>Was there adequate discussion of the change on list and at
the meeting?</div>
<div>Yes.</div>
<div><br>
</div>
<div>___Jason</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Oct 11, 2017 at 7:29 PM, Owen
DeLong <span dir="ltr"><<a href="mailto:owen@delong.com"
target="_blank" moz-do-not-send="true">owen@delong.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">I’d like to request that
if anyone objects to the change made in sending the
recommended draft to last call (should->shall), they
make that clear.
<div><br>
</div>
<div>I believe we it is likely “Support as written” will
actually be interpreted as “Support as amended and sent
to last call”.</div>
<div><br>
</div>
<div>Sorry for being pedantic, but as an AC member, I’d
like to make sure that we have the clearest possible
understanding of community intent as we move forward.</div>
<div><br>
</div>
<div>Thanks,</div>
<div><br>
</div>
<div>Owen</div>
<div>
<div class="h5">
<div><br>
<div>
<blockquote type="cite">
<div>On Oct 11, 2017, at 4:25 PM, Carlton
Samuels <<a
href="mailto:carlton.samuels@gmail.com"
target="_blank" moz-do-not-send="true">carlton.samuels@gmail.com</a>>
wrote:</div>
<br
class="m_-216713572467015844Apple-interchange-newline">
<div>
<div dir="ltr">
<div class="gmail_default"
style="font-family:comic sans
ms,sans-serif;font-size:large">Support as
written.</div>
<div class="gmail_default"
style="font-family:comic sans
ms,sans-serif;font-size:large"><br>
</div>
<div class="gmail_default"
style="font-family:comic sans
ms,sans-serif;font-size:large">-CAS</div>
</div>
<div class="gmail_extra"><br clear="all">
<div>
<div
class="m_-216713572467015844gmail_signature"
data-smartmail="gmail_signature">
<div dir="ltr">
<div><br>
==============================<br>
<i><font face="comic sans ms,
sans-serif">Carlton A Samuels</font></i><br>
<font face="comic sans ms,
sans-serif"><i>Mobile: <a
href="tel:%28876%29%20818-1799"
value="+18768181799"
target="_blank"
moz-do-not-send="true">876-818-1799</a><br>
<font color="#33CC00">Strategy,
Planning, Governance,
Assessment & Turnaround</font></i></font><br>
=============================</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">On Wed, Oct 11,
2017 at 2:16 PM, ARIN <span dir="ltr"><<a
href="mailto:info@arin.net"
target="_blank" moz-do-not-send="true">info@arin.net</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">The ARIN
Advisory Council (AC) met on 6 October
2017 and decided to send the following
to Last Call:<br>
<br>
Recommended Draft Policy ARIN-2017-5:
Improved IPv6 Registration Requirements<br>
<br>
The AC provided the following statement
to the community:<br>
<br>
"Based on strong community support - on
both the Public Policy Mailing List and
in person at ARIN 40 during the policy
consultation - for<br>
replacing the "should" qualifier in
section 6.5.5.4 with "shall", the
Advisory Council, after careful review
and discussion, has made the requested
change to the text."<br>
<br>
Feedback is encouraged during the Last
Call period. All comments should be
provided to the Public Policy Mailing
List. This Last Call period will expire
on 10 November 2017. After Last Call,
the AC will conduct their Last Call
review.<br>
<br>
The full text is below and available at:<br>
<a
href="https://www.arin.net/policy/proposals/"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://www.arin.net/policy/pr<wbr>oposals/</a><br>
<br>
The ARIN Policy Development Process is
available at:<br>
<a
href="https://www.arin.net/policy/pdp.html"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://www.arin.net/policy/pd<wbr>p.html</a><br>
<br>
Regards,<br>
<br>
Sean Hopkins<br>
Policy Analyst<br>
American Registry for Internet Numbers
(ARIN)<br>
<br>
<br>
<br>
AC's Statement of Conformance with
ARIN's Principles of Internet Number
Resource Policy:<br>
<br>
This proposal is technically sound and
enables fair and impartial number policy
for easier IPv6 Registrations. The staff
and legal review noted a single
clarification issue which has been
addressed. There is ample support for
the proposal on PPML and no concerns
have been raised by the community
regarding the proposal.<br>
<br>
Problem Statement:<br>
<br>
Current ARIN policy has different WHOIS
directory registration requirements for
IPv4 vs IPv6 address assignments. IPv4
registration is triggered for an
assignment of any address block equal to
or greater than a /29 (i.e., eight IPv4
addresses). 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. 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. There is no technical
or policy rationale for the disparity,
which could serve as a deterrent to more
rapid IPv6 adoption. The purpose of this
proposal is to eliminate the disparity
and corresponding adverse consequences.<br>
<br>
Policy statement:<br>
<br>
1) Alter section 6.5.5.1 "Reassignment
information" of the NRPM to strike
"assignment containing a /64 or more
addresses" and change to "re-allocation,
reassignment containing a /47 or more
addresses, or subdelegation of any size
that will be individually announced,”<br>
<br>
and<br>
<br>
2) Alter section 6.5.5.2. "Assignments
visible within 7 days" of the NRPM to
strike the text "4.2.3.7.1" and change
to “6.5.5.1"<br>
<br>
and<br>
<br>
3) Alter section 6.5.5.3.1. "Residential
Customer Privacy" of the NRPM by
deleting the phrase "holding /64 and
larger blocks"<br>
<br>
and<br>
<br>
4) Add new section 6.5.5.4
"Registration Requested by Recipient" of
the NRPM, to read: "If the downstream
recipient of a static assignment of /64
or more addresses requests publishing of
that assignment in ARIN's registration
database, the ISP shall register that
assignment as described in section
6.5.5.1."<br>
<br>
Comments:<br>
<br>
a. Timetable for implementation:
Policy should be adopted as soon as
possible.<br>
<br>
b. Anything else:<br>
<br>
Author Comments:<br>
<br>
IPv6 should not be more burdensome than
the equivalent IPv4 network size.
Currently, assignments of /29 or more of
IPv4 space (8 addresses) require
registration. 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. This is NOT true when these same
exact customers use IPv6, as assignments
of /64 or more of IPv6 space require
registration. 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. 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. 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. The
administrative burden of 100% customer
registration of IPv6 customers is
unreasonable, when such is not required
for those customers receiving only IPv4
connections.<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"
target="_blank" 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"
target="_blank" moz-do-not-send="true">info@arin.net</a>
if you experience any issues.</blockquote>
</div>
<br>
</div>
______________________________<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"
target="_blank" 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"
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"
target="_blank" moz-do-not-send="true">info@arin.net</a>
if you experience any issues.</div>
</blockquote>
</div>
<br>
</div>
</div>
</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>
<br clear="all">
<div><br>
</div>
-- <br>
<div class="gmail_signature" data-smartmail="gmail_signature"><font
face="'courier new', monospace" color="#555555">
<div><span style="color:rgb(0,0,0);font-family:arial"><font
face="'courier new', monospace" color="#555555">_______________________________________________________<br>
</font>
<div><font face="'courier new', monospace">Jason
Schiller|NetOps|<a
href="mailto:jschiller@google.com" target="_blank"
moz-do-not-send="true">jschiller@google.com</a>|571-266-0006</font></div>
<div><font face="'courier new', monospace"><br>
</font></div>
</span></div>
</font></div>
</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>
<pre class="moz-signature" cols="72">--
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539
</pre>
</body>
</html>