[arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements

Thu Sep 28 13:20:57 EDT 2017

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 <owen at delong.com> 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 <kevinb at thewire.ca <mailto:kevinb at thewire.ca>> 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:arin-ppml-bounces at arin.net <mailto:arin-ppml-bounces at arin.net>] On Behalf Of John Curran
>> Sent: Wednesday, September 27, 2017 5:59 PM
>> To: Jason Schiller <jschiller at google.com <mailto:jschiller at google.com>>
>> Cc: arin-ppml at arin.net <mailto:arin-ppml at arin.net>
>> Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements
>>  
>> On 26 Sep 2017, at 3:18 PM, Jason Schiller <jschiller at google.com <mailto:jschiller at google.com>> 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 (ARIN-PPML at arin.net <mailto:ARIN-PPML at arin.net>).
>> 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 info at arin.net <mailto:info at arin.net> if you experience any issues.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170928/8fc73ab3/attachment.htm>