[arin-ppml] ARIN-2017-5
Rudolph Daniel
rudi.daniel at gmail.com
Fri Sep 29 13:16:39 EDT 2017
"shall"
Ref: John's comment.
...........
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.).
End quote.
Would ARIN legal have an issue with suggested consequence .above.. of
chronic failure to comply ?
rd
Sep 29, 2017 12:26 PM, <arin-ppml-request at arin.net> wrote:
>
> Send ARIN-PPML mailing list submissions to
> arin-ppml at arin.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.arin.net/mailman/listinfo/arin-ppml
> or, via email, send a message with subject or body 'help' to
> arin-ppml-request at arin.net
>
> You can reach the person managing the list at
> arin-ppml-owner at arin.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ARIN-PPML digest..."
>
>
> Today's Topics:
>
> 1. Re: Recommended Draft Policy ARIN-2017-5: Improved IPv6
> Registration Requirements (Michael Peddemors)
> 2. Re: Recommended Draft Policy ARIN-2017-5: Improved IPv6
> Registration Requirements (Michael Winters)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 29 Sep 2017 07:55:57 -0700
> From: Michael Peddemors <michael at linuxmagic.com>
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5:
> Improved IPv6 Registration Requirements
> Message-ID: <53f61942-1409-a7e1-0ffb-bd129d879827 at linuxmagic.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> +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.
> >
>
>
>
> --
> "Catch the Magic of Linux..."
> ------------------------------------------------------------------------
> Michael Peddemors, President/CEO LinuxMagic Inc.
> Visit us at http://www.linuxmagic.com @linuxmagic
> ------------------------------------------------------------------------
> A Wizard IT Company - For More Info http://www.wizard.ca
> "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
> ------------------------------------------------------------------------
> 604-682-0300 Beautiful British Columbia, Canada
>
> This email and any electronic data contained are confidential and intended
> solely for the use of the individual or entity to which they are
addressed.
> Please note that any views or opinions presented in this email are solely
> those of the author and are not intended to represent those of the
company.
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 29 Sep 2017 16:25:31 +0000
> From: Michael Winters <mwinters at edwardrose.com>
> To: Jason Schiller <jschiller at google.com>, David Farmer
> <farmer at umn.edu>
> Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5:
> Improved IPv6 Registration Requirements
> Message-ID:
> <
bf6e80e57c734e1da104f9072fd4315a at kz-mail01.manifold.edwardrosekzoo.com>
>
> Content-Type: text/plain; charset="utf-8"
>
> If you are going to change it to shall, then you also need to define the
consequences of non-compliance.
>
> From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jason
Schiller
> Sent: Friday, September 29, 2017 9:59 AM
> To: David Farmer <farmer at umn.edu>
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved
IPv6 Registration Requirements
>
> 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
> 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
>
>
> ________________________________
>
> ________________________________
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
http://lists.arin.net/pipermail/arin-ppml/attachments/20170929/b714fd1f/attachment.html
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> ARIN-PPML mailing list
> ARIN-PPML at arin.net
> http://lists.arin.net/mailman/listinfo/arin-ppml
>
> ------------------------------
>
> End of ARIN-PPML Digest, Vol 147, Issue 58
> ******************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170929/96b72987/attachment.htm>
More information about the ARIN-PPML
mailing list