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 <far...@umn.edu
<mailto:far...@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 <kev...@thewire.ca
<mailto:kev...@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-boun...@arin.net
<mailto:arin-ppml-boun...@arin.net>] *On Behalf Of *John Curran
*Sent:* Wednesday, September 27, 2017 5:59 PM
*To:* Jason Schiller <jschil...@google.com
<mailto:jschil...@google.com>>
*Cc:* arin-ppml@arin.net <mailto:arin-ppml@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 <jschil...@google.com
<mailto:jschil...@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@arin.net
<mailto:ARIN-PPML@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 i...@arin.net <mailto:i...@arin.net> if you
experience any issues.
--
===============================================
David Farmer Email:far...@umn.edu <mailto:email%3afar...@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|jschil...@google.com
<mailto:jschil...@google.com>|571-266-0006
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.
