[arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements
Matthew Wilder
Matthew.Wilder at telus.com
Fri Sep 29 19:04:39 EDT 2017
Without a doubt the words "should" and "shall" are very different words from a legal standpoint. Should can be understood as "may" while shall can be understood as "must". The difference between permission and obligation is night and day in a legal context.
Out of curiosity I took a look through NRPM for instances of should and shall. I found 30 instances of "should" and 67 of "shall". Of these, 5 instances were "ISP/ISPs should" and none were "ISP/ISPs shall". From that standpoint, the should text is more consistent with NRPM language in general. If there is to be some question of the teeth the policy provides to ARIN, I suggest that be considered under another policy discussion / proposal.
Also worth noting is that much of the use of shall is generally improper, given that shall is a verb reserved for subjects, not objects. People and entities "shall" would be proper usage, whereas things "shall be" is not generally accepted. I found many such examples, such as:
2.10. End site
"The term End Site shall mean..."
A bit of an aside there that network folk may not always provide the most legally conscious text, and that was probably fine when we didn't have to, but as we enter a new phase of the Internet with IPv4 address markets, maybe there is need for some attention to this.
tl;dr. I support the text as written given the significant change in meaning with the use of the word shall. (full disclosure: TELUS already reports IPv6 reassignments on each service with over /48 size, and then some).
Regards,
mw
On September 29, 2017 12:07 PM, John Santos wrote:
> +1
>
> I would also prefer "shall" to "should", but the current text is
> acceptable to me.
>
> The "should", as I read it, only applies when downstream customers
> who have an assignments of /48 or longer request to be SWIPed by their
> upstream provider. If their assignment is a /47 or more, or if it is
> a re-allocation, the SWIP is required. Therefore most or all ISP's
> will have a mechanism and procedures for SWIPing their customers, and
> this proposal just changes the situations when they do it. Since the
> current policy actually requires them to SWIP *all* their IPv6
> customers (/64 or more), they should already have mechanisms and
> procedures in place, so either "should" or "shall" reduces, not
> increases, any perceived burden on the upstream ISPs.
>
> Are there any ISP's that would be happy to SWIP their smaller
> customers, but aren't really sure that it is allowed? "Should"
> would make it clear that they are permitted to do so. Are there any
> other reasons to prefer "should" over "shall", or is the objection
> merely that making this change would delay implementation of the rest
> of the policy?
>
> I would guess most smaller customers would be happy to leave the burden
> of dealing with abuse complaints, but as a very small end user (IPv4
> /24) who already has an abuse contact (me), I would be happy to be
> SWIPed for IPv6.
>
> On 9/29/2017 10:55 AM, Michael Peddemors wrote:
>> +1
>>
>> On 17-09-29 06:58 AM, Jason Schiller wrote:
>> David, Kevin, Alison>>
>> I am actually comfortable with an implementation that is short of
>> revocation, but I am still not comfortable with "should".
>>
>> Should makes it optional. Officially not being out of compliance
>> with ARIN policy makes it optional.
>>
>> I suggest that an ISP refusing to register a downstream customer is
>> out of compliance with ARIN policy, and not just choosing to ignore
>> an optional recommendation.
>>
>> If it is only "should" then an ISP can still hold the moral high
>> ground while refusing to support SWIP on the grounds that they will
>> not implement tooling and commit resources when it is only optional.
>>
>> It is a question of if you can hold someone accountable for not
>> complying or if they are free to ignore something that is optional.
>>
>>
>>
>> Owen, Chris, Kevin,
>>
>> Certainly if there is enough support to move this forward, we
>> shouldn't wait another cycle. (I recognize this weakens the "shall"
>> position)
>>
>> My hope is if we can close out the discussion of this topic at the
>> meeting with a clear understanding of if there is community support
>> to move forward the policy with "shall" and also if there is clear
>> support to move the policy forward with "should" in this cycle. This
>> will give the AC a maximum of leverage to do what is needed, and
>> insure it doesn't fall to the next cycle by forcing people to support
>> only what they perceive as the best option.
>>
>> Assuming there is support for both "shall" and "should" the AC could
>> choose to move "shall" to last call, and if there are then issues,
>> move should to last call.
>>
>>
>> We need to get clear on how to structure the question here.
>>
>> My thoughts are
>>
>> 1. Do you support the policy with "shall" if it doesn't require an
>> extra cycle
>> and support "should" in this cycle if "shall" cannot advance?
>>
>> 2. Do you only support the policy as written?
>>
>> 3. Do you oppose both the policy as written and with "shall"?
>>
>> When considering if there is enough support to move the policy as
>> written forward, the AC should consider the hands in both questions 1
>> & 2.
>>
>>
>> I support the policy with "shall" with a fall back to "should".
>>
>> __Jason
>>
>>
>> On Thu, Sep 28, 2017 at 1:18 PM, David Farmer <farmer at umn.edu
>> <mailto:farmer at umn.edu>> wrote:
>>
>> I agree with Kevin if a bigger stick is need to ensure compliance
>> in
>> the future we can take that step if/when there proves to be a
>> serious non-compliance issue in the future. Personally, I'm not
>> ready to threaten revocation, in this case. My intent in
>> suggesting
>> what is now 6.5.5.4 was to crate an avenue for ARIN Staff to
>> intervene with ISPs on behalf of customers, if a customer wanted
>> their assignment registered and their ISP refused to register
>> their
>> assignment as requested, the customer can appeal the issue to
>> ARIN. I'm fine with that intervention being short of threatening
>> revocation, at least until their proves to be a serious issue
>> with
>> ISP's refusing valid requests by endusers to register
>> assignments. I think the current language provides the proper
>> balance.
>>
>> I'm fine with the standard procedure starting with ARIN Staff
>> forwarding such complaints to an ISP requesting an explanation of
>> the situation. However, if this develops into a chronic matter
>> for
>> an ISP, I would expect ARIN Staff to escalate the issue beyond
>> simply asking for an explanation. Further after escalation, if
>> the
>> matter continues to be chronic, I would expect eventually the
>> community to be altered to the situation. Probably not the
>> specifics
>> of which ISP and customers, but at least that there is an issue
>> and
>> some sense of the situation involved.
>>
>> Therefore, I support the policy as written. I'm not strongly
>> opposed
>> to changing from "should" to "shall" for section 6.5.5.4, but I'd
>> prefer keeping that change in reserve, so we can go there, if
>> there
>> proves to be serious issues with non-compliance in the future.
>> Put
>> another way, I think voluntary compliance is highly preferred for
>> this issue, and if voluntary compliance proves insufficient, then
>> we
>> can deal with that in the future.
>>
>> Thanks.
>>
>> On Thu, 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.
>>
>>
>>
>>
>> -- ===============================================
>> David Farmer Email:farmer at umn.edu <mailto:Email%3Afarmer at umn.edu>
>> Networking & Telecommunication Services
>> Office of Information Technology
>> University of Minnesota
>> 2218 University Ave SE
>> <https://maps.google.com/?q=2218+University+Ave+SE&entry=gmail&source
>> =g>
>> Phone: 612-626-0815 <tel:%28612%29%20626-0815>
>> Minneapolis, MN 55414-3029 Cell: 612-812-9952
>> <tel:%28612%29%20812-9952>
>> ===============================================
>>
>>
>>
>>
>> --
>> _______________________________________________________
>> Jason Schiller|NetOps|jschiller at google.com
>> <mailto:jschiller at google.com>|571-266-0006
>>
>>
>>
>> _______________________________________________
>> 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.
>>
>
>
>
--
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539
_______________________________________________
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.
More information about the ARIN-PPML
mailing list