[arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements
Leif Sawyer
lsawyer at gci.com
Fri Sep 29 12:40:59 EDT 2017
Thanks for the feedback, everybody.
I've captured these thoughts into the slide deck that I'll be presenting during the meeting.
Definitely looking forward to the lively discussion next week.
Leif
From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Michael Winters
Sent: Friday, September 29, 2017 8:31 AM
To: Owen DeLong; Jason Schiller
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements
[External Email]
Shall is not minor. Ask ARIN legal counsel if there is a big or small difference between should and shall.
Additionally, if you are going to say shall, what happens if there is non-compliance?
You should define the consequences if you want to say shall.
Thanks,
Mike
From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong
Sent: Friday, September 29, 2017 10:13 AM
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 Sep 29, 2017, at 8:58 AM, Jason Schiller <jschiller at google.com<mailto:jschiller at google.com>> 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)
Other than AC sophistry or community confusion, there’s absolutely no reason, IMHO,
that we can’t get community support and consensus around shall as a minor change
prior to last call, so I don’t think it actually weakens the argument.
I agree that if we have enough of either of the above that it won’t move forward
with shall until another cycle, it’s not worth waiting another cycle and we should
push through an additional separate policy for this single-word correction, so I
suppose to that extent, it could be seen as weakening the argument for doing it now.
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.
100% Agreed.
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.
Excellent idea, IMHO.
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:(612)%20626-0815>
Minneapolis, MN 55414-3029 Cell: 612-812-9952<tel:(612)%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<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.
________________________________
________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170929/8f6d4d53/attachment.htm>
More information about the ARIN-PPML
mailing list