<div dir="ltr"><div>Rudi,</div><div>Thanks for commenting on the "shall question".</div><div><br></div>Chris,<div><br></div><div>Can you comment on the "shall" question?</div><div><br></div><div>Rudi,</div><div><br></div><div>As it currently stands all static IPv6 customers with a /64 or more are SWIP'd</div><div><br></div><div>"Each static IPv6 assignment containing a /64 or more addresses </div><div>shall be registered in the WHOIS directory via SWIP" </div><div><br></div><div>Dynamic customers don't get a re-assignment or re-allocation.</div><div>Usually there is a large aggregate re-assigned to the ISP </div><div>and designated as used by that ISP's customers in a given market.</div><div><br></div><div><br></div><div>I imagine there are not very many customers with a static IPv6 address</div><div>smaller than a /64 who would want their address SWIP'd, likely even less</div><div>who plan to have static down stream customers, and certainly</div><div>won't be multi-homing, or routing their space discreetly.</div><div><br></div><div><br></div><div>In the unlikely event that there are, I expect there would be a 6 month </div><div>time period pending implementation, and even after that point ARIN</div><div>would happily work with ISPs who are working in good faith, and making </div><div>progress towards removing hurdles to accomplish this. </div><div><br></div><div>As it stands this proposed policy has a lower SWIP burden than the current</div><div>one.</div><div><br></div><div>___Jason</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 28, 2017 at 1:26 PM, Chris Woodfield <span dir="ltr"><<a href="mailto:chris@semihuman.com" target="_blank">chris@semihuman.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"><div>Rudolph,</div><div><br></div><div>My reading of the proposal is that the registration is triggered by the request from the downstream recipient, which implies that if no prior requests have been received, then there would be no duty to register. Requests from downstreams received after the policy is implemented would be subject to these terms.</div><div><br></div><div>I’ll agree that this is ambiguous re: requests from downstreams received prior to implementation, but in practical terms, I’d expect interested downstreams to be aware of the policy change and simply resubmit that request, if the prior request was not granted.</div><div><br></div><div>Thanks,</div><div><br></div><div>-C</div><div><div class="h5"><br><div><blockquote type="cite"><div>On Sep 28, 2017, at 10:13 AM, Rudolph Daniel <<a href="mailto:rudi.daniel@gmail.com" target="_blank">rudi.daniel@gmail.com</a>> wrote:</div><br class="m_4800007685826427466Apple-interchange-newline"><div><div dir="ltr"><div class="gmail_default" style="font-family:'comic sans ms',sans-serif;font-size:large">I am in support of the policy proposal with "shall" but I would like to know of possible negative impact if approved as policy; on the past reassignments that were not SWIP ed.</div><div class="gmail_default" style="font-family:'comic sans ms',sans-serif;font-size:large">Is this perceived as an issue; or will the policy be retroactive? Either way.</div><div class="gmail_extra"><br clear="all"><div><div class="m_4800007685826427466gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><br><div><font size="4"><span style="font-family:comic sans ms,sans-serif">Rudi Daniel</span></font><div><font size="4"><span style="font-family:comic sans ms,sans-serif"><i><a href="http://www.facebook.com/pages/Kingstown-Saint-Vincent-and-the-Grenadines/DanielCharles/153611257984774" target="_blank">danielcharles consulting</a></i></span></font></div><div><font color="#006600"><span style="font-size:large"><b><br></b></span></font><div><span style="font-size:large"><br></span></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Thu, Sep 28, 2017 at 12:05 PM, <span dir="ltr"><<a href="mailto:arin-ppml-request@arin.net" target="_blank">arin-ppml-request@arin.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send ARIN-PPML mailing list submissions to<br>
<a href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<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>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:arin-ppml-request@arin.net" target="_blank">arin-ppml-request@arin.net</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:arin-ppml-owner@arin.net" target="_blank">arin-ppml-owner@arin.net</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of ARIN-PPML digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: Recommended Draft Policy ARIN-2017-5: Improved IPv6<br>
Registration Requirements (Owen DeLong)<br>
2. Re: Recommended Draft Policy ARIN-2017-5: Improved IPv6<br>
Registration Requirements (Owen DeLong)<br>
<br>
<br>
------------------------------<wbr>------------------------------<wbr>----------<br>
<br>
Message: 1<br>
Date: Thu, 28 Sep 2017 10:46:01 -0500<br>
From: Owen DeLong <<a href="mailto:owen@delong.com" target="_blank">owen@delong.com</a>><br>
To: John Curran <<a href="mailto:jcurran@arin.net" target="_blank">jcurran@arin.net</a>><br>
Cc: Jason Schiller <<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a>>, "<a href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a>"<br>
<<a href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a>><br>
Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5:<br>
Improved IPv6 Registration Requirements<br>
Message-ID: <<a href="mailto:314B3DC2-87BA-434D-9EEC-F2BD60F678EC@delong.com" target="_blank">314B3DC2-87BA-434D-9EEC-F2BD6<wbr>0F678EC@delong.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Given this, I personally think that shall is the better choice of wording for 6.5.5.4.<br>
<br>
Owen<br>
<br>
> On Sep 27, 2017, at 4:59 PM, John Curran <<a href="mailto:jcurran@arin.net" target="_blank">jcurran@arin.net</a>> wrote:<br>
><br>
> On 26 Sep 2017, at 3:18 PM, Jason Schiller <<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a> <mailto:<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a>>> wrote:<br>
>><br>
>> I oppose as written.<br>
>><br>
>> There should not be a different standard of requirement for:<br>
>> - re-allocation<br>
>> - reassignment containing a /47 or more addresses<br>
>> - subdelegation of any size that will be individually announced<br>
>><br>
>> which is "shall"<br>
>><br>
>> and Registration Requested by Recipient<br>
>><br>
>> which is "should"<br>
>><br>
>> I would support if they are both "shall".<br>
>><br>
>> Can ARIN staff discuss what actions it will take if an ISP's<br>
>> down stream customer contacts them and explains that their<br>
>> ISP refuses to SWIP their reassignment to them?<br>
>><br>
>> Will they do anything more than reach out to the ISP and tell<br>
>> them they "should" SWIP it?<br>
><br>
> Jason -<br>
><br>
> If this policy change 2017-5 is adopted, then a provider that has IPv6 space from ARIN<br>
> but routinely fails to publish registration information (for /47 or larger reassignments)<br>
> would be in violation, and ARIN would have clear policy language that would enable<br>
> us to discuss with the ISP the need to publish this information in a timely manner.<br>
><br>
> Service providers who blatantly ignore such a provision on an ongoing basis will be<br>
> in the enviable position of hearing me chat with them about their obligations to follow<br>
> ARIN number resource policy, including the consequences (i.e. potential revocation<br>
> of the IPv6 number resources.)<br>
><br>
> If the langauge for the new section 6.5.5.4 "Registration Requested by Recipient?<br>
> reads ?? the ISP should register that assignment?, then ARIN would send on any<br>
> received customer complaint to the ISP, and remind the ISP that they should<br>
> follow number resource policy in this regard but not otherwise taking any action.<br>
><br>
> If the language for the new section 6.5.5.4 "Registration Requested by Recipient?<br>
> reads ?? the ISP shall register that assignment?, then failure to do so would be<br>
> a far more serious matter that, if left unaddressed on a chronic manner, could have<br>
> me discussing the customer complaints as a sign of potential failure to comply with<br>
> number resource policy, including the consequences (i.e. potential revocation of<br>
> the IPv6 number resources.)<br>
><br>
> I would note that the community should be very clear about its intentions for ISPs<br>
> with regard to customer requested reassignment publication, given there is large<br>
> difference in obligations that result from policy language choice. ARIN staff remains,<br>
> as always, looking forward to implementing whatever policy emerges from the<br>
> consensus-based policy development process.<br>
><br>
> Thanks!<br>
> /John<br>
><br>
> John Curran<br>
> President and CEO<br>
> American Registry for Internet Numbers<br>
><br>
><br>
><br>
><br>
><br>
><br>
><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">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" target="_blank">info@arin.net</a> if you experience any issues.<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.arin.net/pipermail/arin-ppml/attachments/20170928/6d6c415b/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.arin.net/piperma<wbr>il/arin-ppml/attachments/<wbr>20170928/6d6c415b/attachment-<wbr>0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Thu, 28 Sep 2017 11:03:55 -0500<br>
From: Owen DeLong <<a href="mailto:owen@delong.com" target="_blank">owen@delong.com</a>><br>
To: Kevin Blumberg <<a href="mailto:kevinb@thewire.ca" target="_blank">kevinb@thewire.ca</a>><br>
Cc: John Curran <<a href="mailto:jcurran@arin.net" target="_blank">jcurran@arin.net</a>>, Jason Schiller<br>
<<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a>>, "<a href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a>" <<a href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a>><br>
Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5:<br>
Improved IPv6 Registration Requirements<br>
Message-ID: <<a href="mailto:A2F929CE-30CE-47F6-BA94-6DAA69BCA668@delong.com" target="_blank">A2F929CE-30CE-47F6-BA94-6DAA6<wbr>9BCA668@delong.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
While I wouldn?t consider it an editorial change, I would consider it a minor change, which, if it had good community discussion and support at the meeting, would, IMHO, be within the scope of pre-last-call changes that could be made between the PPM and last call.<br>
<br>
The AC has, as has been mentioned before, significant discretion in determining what is a ?minor change?.<br>
<br>
This is strictly my own opinion and may or may not be shared by other AC members, staff, or anyone else.<br>
<br>
Owen<br>
<br>
> On Sep 28, 2017, at 10:46 AM, Kevin Blumberg <<a href="mailto:kevinb@thewire.ca" target="_blank">kevinb@thewire.ca</a>> wrote:<br>
><br>
> I support the policy as written. <><br>
><br>
> If the stick isn?t big enough it appears a simple policy change could be used, not just for this section but all the other areas ?should? is used.<br>
><br>
> I would like to point out that ?should? is currently used 30 times in the NRPM.<br>
><br>
> In reading John?s explanation, I can?t see ?should? and ?shall? being considered an editorial change. To extend the policy cycle to another meeting would be far worse.<br>
><br>
> Out of curiosity, how often has ARIN had to deal with SWIP issues like this, where the other party ignored you?<br>
><br>
> Thanks,<br>
><br>
> Kevin Blumberg<br>
><br>
><br>
> From: ARIN-PPML [mailto:<a href="mailto:arin-ppml-bounces@arin.net" target="_blank">arin-ppml-bounces@arin<wbr>.net</a>] On Behalf Of John Curran<br>
> Sent: Wednesday, September 27, 2017 5:59 PM<br>
> To: Jason Schiller <<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a>><br>
> Cc: <a href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a><br>
> Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements<br>
><br>
> On 26 Sep 2017, at 3:18 PM, Jason Schiller <<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a> <mailto:<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a>>> wrote:<br>
><br>
> I oppose as written.<br>
><br>
> There should not be a different standard of requirement for:<br>
> - re-allocation<br>
> - reassignment containing a /47 or more addresses<br>
> - subdelegation of any size that will be individually announced<br>
><br>
> which is "shall"<br>
><br>
> and Registration Requested by Recipient<br>
><br>
> which is "should"<br>
><br>
> I would support if they are both "shall".<br>
><br>
> Can ARIN staff discuss what actions it will take if an ISP's<br>
> down stream customer contacts them and explains that their<br>
> ISP refuses to SWIP their reassignment to them?<br>
><br>
> Will they do anything more than reach out to the ISP and tell<br>
> them they "should" SWIP it?<br>
><br>
> Jason -<br>
><br>
> If this policy change 2017-5 is adopted, then a provider that has IPv6 space from ARIN<br>
> but routinely fails to publish registration information (for /47 or larger reassignments)<br>
> would be in violation, and ARIN would have clear policy language that would enable<br>
> us to discuss with the ISP the need to publish this information in a timely manner.<br>
><br>
> Service providers who blatantly ignore such a provision on an ongoing basis will be<br>
> in the enviable position of hearing me chat with them about their obligations to follow<br>
> ARIN number resource policy, including the consequences (i.e. potential revocation<br>
> of the IPv6 number resources.)<br>
><br>
> If the langauge for the new section 6.5.5.4 "Registration Requested by Recipient?<br>
> reads ?? the ISP should register that assignment?, then ARIN would send on any<br>
> received customer complaint to the ISP, and remind the ISP that they should<br>
> follow number resource policy in this regard but not otherwise taking any action.<br>
><br>
> If the language for the new section 6.5.5.4 "Registration Requested by Recipient?<br>
> reads ?? the ISP shall register that assignment?, then failure to do so would be<br>
> a far more serious matter that, if left unaddressed on a chronic manner, could have<br>
> me discussing the customer complaints as a sign of potential failure to comply with<br>
> number resource policy, including the consequences (i.e. potential revocation of<br>
> the IPv6 number resources.)<br>
><br>
> I would note that the community should be very clear about its intentions for ISPs<br>
> with regard to customer requested reassignment publication, given there is large<br>
> difference in obligations that result from policy language choice. ARIN staff remains,<br>
> as always, looking forward to implementing whatever policy emerges from the<br>
> consensus-based policy development process.<br>
><br>
> Thanks!<br>
> /John<br>
><br>
> John Curran<br>
> President and CEO<br>
> American Registry for Internet Numbers<br>
><br>
><br>
><br>
><br>
><br>
><br>
><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">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" target="_blank">info@arin.net</a> if you experience any issues.<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.arin.net/pipermail/arin-ppml/attachments/20170928/0fbeb396/attachment.html" rel="noreferrer" target="_blank">http://lists.arin.net/piperma<wbr>il/arin-ppml/attachments/<wbr>20170928/0fbeb396/attachment.<wbr>html</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
______________________________<wbr>_________________<br>
ARIN-PPML mailing list<br>
<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a><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>
<br>
------------------------------<br>
<br>
End of ARIN-PPML Digest, Vol 147, Issue 43<br>
******************************<wbr>************<br>
</blockquote></div><br></div></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">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/<wbr>listinfo/arin-ppml</a><br>Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.</div></blockquote></div><br></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">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><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><font color="#555555" face="'courier new', monospace"><div><span style="color:rgb(0,0,0);font-family:arial"><font color="#555555" face="'courier new', monospace">_______________________________________________________<br></font><div><font face="'courier new', monospace">Jason Schiller|NetOps|<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a>|571-266-0006</font></div><div><font face="'courier new', monospace"><br></font></div></span></div></font></div>
</div>