<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<div class="">On 26 Sep 2017, at 3:18 PM, Jason Schiller <<a href="mailto:jschiller@google.com" class="">jschiller@google.com</a>> wrote:</div>
<div>
<blockquote type="cite" class=""><br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">
I oppose as written.
<div class=""><br class="">
</div>
<div class="">There should not be a different standard of requirement for:</div>
<div class="">- re-allocation</div>
<div class="">- reassignment containing a /47 or more addresses</div>
<div class="">- subdelegation of any size that will be individually announced</div>
<div class=""><br class="">
</div>
<div class="">which is "shall"</div>
<div class=""><br class="">
</div>
<div class="">and Registration Requested by Recipient</div>
<div class=""><br class="">
</div>
<div class="">which is "should"</div>
<div class=""><br class="">
</div>
<div class="">I would support if they are both "shall".</div>
<div class=""><br class="">
</div>
<div class="">Can ARIN staff discuss what actions it will take if an ISP's</div>
<div class="">down stream customer contacts them and explains that their</div>
<div class="">ISP refuses to SWIP their reassignment to them?</div>
<div class=""><br class="">
</div>
<div class="">Will they do anything more than reach out to the ISP and tell</div>
<div class="">them they "should" SWIP it?</div>
</div>
</div>
</blockquote>
<br class="">
</div>
<div>Jason - <br class="">
<br class="">
If this policy change 2017-5 is adopted, then a provider that has IPv6 space from ARIN </div>
<div> but routinely fails to publish registration information (for /47 or larger reassignments) </div>
<div> would be in violation, and ARIN would have clear policy language that would enable </div>
<div> us to discuss with the ISP the need to publish this information in a timely manner. </div>
<div><br class="">
Service providers who blatantly ignore such a provision on an ongoing basis will be <br class="">
in the enviable position of hearing me chat with them about their obligations to follow <br class="">
ARIN number resource policy, including the consequences (i.e. potential revocation </div>
<div> of the IPv6 number resources.)</div>
<div><br class="">
</div>
<div> If the langauge for the new section 6.5.5.4 "Registration Requested by Recipient” </div>
<div> reads “… the ISP should register that assignment”, then ARIN would send on any</div>
<div> received customer complaint to the ISP, and remind the ISP that they should</div>
<div> follow number resource policy in this regard but not otherwise taking any action. </div>
<div><br class="">
</div>
<div> If the language for the new section 6.5.5.4 "Registration Requested by Recipient” </div>
<div> reads “… the ISP shall register that assignment”, then failure to do so would be</div>
<div> a far more serious matter that, if left unaddressed on a chronic manner, could have </div>
<div> me discussing the customer complaints as a sign of potential failure to comply with </div>
<div> number resource policy, including the consequences (i.e. potential revocation of </div>
<div> the IPv6 number resources.)</div>
<div><br class="">
</div>
<div> I would note that the community should be very clear about its intentions for ISPs</div>
<div> with regard to customer requested reassignment publication, given there is large </div>
<div> difference in obligations that result from policy language choice. ARIN staff remains, </div>
<div> as always, looking forward to implementing whatever policy emerges from the </div>
<div> consensus-based policy development process. </div>
<div><br class="">
</div>
<div>Thanks!</div>
<div>/John</div>
<div><br class="">
</div>
<div>John Curran</div>
<div>President and CEO</div>
<div>American Registry for Internet Numbers</div>
<div><br class="">
</div>
<div><br class="">
</div>
<div><br class="">
</div>
<div><br class="">
</div>
<div><br class="">
</div>
<div><br class="">
</div>
<div><br class="">
</div>
</body>
</html>