<div dir="ltr">David, Tony, Thank you for bringing up the IPS must SWIP when address user asks.<div><br></div><div>Scott, Thank you for putting the changes in context.</div><div><br></div><div><br></div><div>I oppose as written.  I support with the David/Tony friendly admendment.</div><div><div><br></div><div>Why?</div><div>> It should be required for an ISP to SWIP / Rwhois any reassignment </div><div>> when the down stream address user has requested such.  </div><div>></div><div>> It is sometimes useful to SWIP the reassignemnts to the down stream</div><div>> organization so that the down stream organization can provide their abuse</div><div>> contact or technical support contact info, or public comments.</div><div>> </div><div>> I fear without my friendly amendment the policy change may send </div><div>> the wrong message and suggest that an ISP can safely conclude</div><div>> that if they are never going to support mutli-homing, and if they never </div><div>> give out anything larger than a /48, that they do not need to support the</div><div>> facility to SWIP at all, and can openly refuse all SWIPs for IPv6  </div><div>> re-assignments.</div></div><div><br></div><div>Possible simple text addition:</div><div><br></div><div>On Fri, Jul 21, 2017 at 1:34 PM, Scott Leibrand <span dir="ltr"><<a href="mailto:scottleibrand@gmail.com" target="_blank">scottleibrand@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><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. <span style="color:rgb(153,51,102);font-family:Calibri,sans-serif;font-size:14.6667px">Re-allocation / </span>Reassignment information</div><div><br></div></div></div></blockquote><div> </div><div><span style="color:rgb(153,51,102);font-family:Calibri,sans-serif;font-size:14.6667px">Each of the following  </span></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><br></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div><span style="color:rgb(153,51,102);font-family:Calibri,sans-serif;font-size:14.6667px">- </span>static IPv6 <span style="color:rgb(153,51,102);font-family:Calibri,sans-serif;font-size:14.6667px">re-</span>assignment containing a <span style="color:rgb(153,51,102);font-family:Calibri,sans-serif;font-size:14.6667px">/47 or more addresses,</span> </div></div></blockquote><div><span style="color:rgb(153,51,102);font-family:Calibri,sans-serif;font-size:14.6667px">-  sub-delegation of any size that will be individually announced,</span></div><div><span style="color:rgb(153,51,102);font-family:Calibri,sans-serif;font-size:14.6667px">- any re-assignment where the address holder specifically requests a reassign simple, reassign detail, or (if applicable) privacy registration</span></div><div><span style="color:rgb(153,51,102);font-family:Calibri,sans-serif;font-size:14.6667px">- re-allocations of any size</span><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></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><span class="gmail-HOEnZb"><font color="#888888"><div><br></div><div>-Scott</div><div><br></div></font></span></div></blockquote></div><div><br></div><div>I'd like to (mostly) stay out of the MUST/SHOULD discussion wrt</div><div>the requirement to SWIP if the intent is to route.  </div><div>I prefer MUST over SHOULD and SHOULD over no advice.</div><div>I feel strongly that at the least the advice should be preserved.  </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 Mon, Jul 24, 2017 at 5:07 PM, David Farmer <span dir="ltr"><<a href="mailto:farmer@umn.edu" target="_blank">farmer@umn.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Honestly, I could live with it just those three lines.  However, I'm willing to recognize at least the possibility there is a legitimate community interest in having records for assignments that are shorter than /48. <div><br></div><div>As for IPv4, I'd also be just fine with those three lines.  Again, recognizing at least the possibility there is a legitimate community interest in having records for assignments that are shorter than /24</div><div><div class="gmail_extra"><span class=""><br><div class="gmail_quote">On Mon, Jul 24, 2017 at 2:51 PM, Tony Hain <span dir="ltr"><<a href="mailto:alh-ietf@tndh.net" target="_blank">alh-ietf@tndh.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="m_-967949504121622973gmail-m_2696747385615973633WordSection1"><p class="MsoNormal"><font size="2" color="#1f497d" face="Calibri"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">While I agree with the general direction David is heading, his text is still overly complex to deal with the goal. This whole thread only requires 3 lines:<u></u><u></u></span></font></p><p class="MsoNormal"><font size="2" color="#1f497d" face="Calibri"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></font></p><p class="MsoNormal"><font size="2" color="#1f497d" face="Calibri"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Reallocations MUST provide SWIP.<u></u><u></u></span></font></p><p class="MsoNormal"><font size="2" color="#1f497d" face="Calibri"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Requests by the assignee MUST provide SWIP.<br>Anything appearing independently in the global routing table SHOULD provide SWIP.<u></u><u></u></span></font></p><p class="MsoNormal"><font size="2" color="#1f497d" face="Calibri"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></font></p><p class="MsoNormal"><font size="2" color="#1f497d" face="Calibri"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">All the rest is noise that doesn’t add to solving any problem known to mankind, and is simply an artifact of the IPv4-think insane conservation mindset. Size is irrelevant in both protocol versions, and even if you think it is, the only time it comes up is in #3. In any case the length of #3 might change over time, and there is no reason the policy text needs to change to track it. If something is independent, no matter what it’s length is, the intent is to have accurate contact info. <u></u><u></u></span></font></p><p class="MsoNormal"><font size="2" color="#1f497d" face="Calibri"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></font></p><p class="MsoNormal"><font size="2" color="#1f497d" face="Calibri"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Saying anything more is trying to legislate ISP behavior, which is explicitly outside the scope of ARIN.<u></u><u></u></span></font></p><p class="MsoNormal"><font size="2" color="#1f497d" face="Calibri"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></font></p><p class="MsoNormal"><font size="2" color="#1f497d" face="Calibri"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Tony</span></font></p></div></div></blockquote></div><br clear="all"><div><br></div></span><span class="">-- <br><div class="m_-967949504121622973gmail_signature">==============================<wbr>=================<br>David Farmer               <a href="mailto:Email%3Afarmer@umn.edu" target="_blank">Email:farmer@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)%20626-0815" value="+16126260815" target="_blank">612-626-0815</a><br>Minneapolis, MN 55414-3029   Cell: <a href="tel:(612)%20812-9952" value="+16128129952" target="_blank">612-812-9952</a><br>==============================<wbr>================= </div>
</span></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>