I agree with Owen’s assessment. If there is sufficient community support for changing the phrase to “shall” at the PPM - I’d define “sufficient community support” as a show of hands on that specific word choice, in addition to the discussion here - I see no need to require another public consultation in order to go to last call incorporating that change in terms.
I’m personally in favor of “shall", although I still support as written. Perfect as enemy of good, etc etc. Thanks, -C > On Sep 28, 2017, at 9:03 AM, Owen DeLong <[email protected]> wrote: > > 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. > > The AC has, as has been mentioned before, significant discretion in > determining what is a “minor change”. > > This is strictly my own opinion and may or may not be shared by other AC > members, staff, or anyone else. > > Owen > >> On Sep 28, 2017, at 10:46 AM, Kevin Blumberg <[email protected] >> <mailto:[email protected]>> wrote: >> >> I support the policy as written. <> >> >> 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. >> >> I would like to point out that “should” is currently used 30 times in the >> NRPM. >> >> 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. >> >> Out of curiosity, how often has ARIN had to deal with SWIP issues like this, >> where the other party ignored you? >> >> Thanks, >> >> Kevin Blumberg >> >> >> From: ARIN-PPML [mailto:[email protected] >> <mailto:[email protected]>] On Behalf Of John Curran >> Sent: Wednesday, September 27, 2017 5:59 PM >> To: Jason Schiller <[email protected] <mailto:[email protected]>> >> Cc: [email protected] <mailto:[email protected]> >> Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 >> Registration Requirements >> >> On 26 Sep 2017, at 3:18 PM, Jason Schiller <[email protected] >> <mailto:[email protected]>> wrote: >> >> I oppose as written. >> >> There should not be a different standard of requirement for: >> - re-allocation >> - reassignment containing a /47 or more addresses >> - subdelegation of any size that will be individually announced >> >> which is "shall" >> >> and Registration Requested by Recipient >> >> which is "should" >> >> I would support if they are both "shall". >> >> Can ARIN staff discuss what actions it will take if an ISP's >> down stream customer contacts them and explains that their >> ISP refuses to SWIP their reassignment to them? >> >> Will they do anything more than reach out to the ISP and tell >> them they "should" SWIP it? >> >> Jason - >> >> If this policy change 2017-5 is adopted, then a provider that has IPv6 >> space from ARIN >> but routinely fails to publish registration information (for /47 or >> larger reassignments) >> would be in violation, and ARIN would have clear policy language that >> would enable >> us to discuss with the ISP the need to publish this information in a >> timely manner. >> >> Service providers who blatantly ignore such a provision on an ongoing >> basis will be >> in the enviable position of hearing me chat with them about their >> obligations to follow >> ARIN number resource policy, including the consequences (i.e. potential >> revocation >> of the IPv6 number resources.) >> >> If the langauge for the new section 6.5.5.4 "Registration Requested by >> Recipient” >> reads “… the ISP should register that assignment”, then ARIN would send >> on any >> received customer complaint to the ISP, and remind the ISP that they >> should >> follow number resource policy in this regard but not otherwise taking any >> action. >> >> If the language for the new section 6.5.5.4 "Registration Requested by >> Recipient” >> reads “… the ISP shall register that assignment”, then failure to do so >> would be >> a far more serious matter that, if left unaddressed on a chronic manner, >> could have >> me discussing the customer complaints as a sign of potential failure to >> comply with >> number resource policy, including the consequences (i.e. potential >> revocation of >> the IPv6 number resources.) >> >> I would note that the community should be very clear about its intentions >> for ISPs >> with regard to customer requested reassignment publication, given there >> is large >> difference in obligations that result from policy language choice. ARIN >> staff remains, >> as always, looking forward to implementing whatever policy emerges from >> the >> consensus-based policy development process. >> >> Thanks! >> /John >> >> John Curran >> President and CEO >> American Registry for Internet Numbers >> >> >> >> >> >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List ([email protected] >> <mailto:[email protected]>). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> <http://lists.arin.net/mailman/listinfo/arin-ppml> >> Please contact [email protected] <mailto:[email protected]> if you experience any >> issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ([email protected]). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues.
_______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
