I will note the standard will not universally be "should", if the reason the endusers wants the prefix registered is they were given permission to route it, or its shorter than /47, then the standard will be "shall", because of the clauses in 6.5.5.1.
On Fri, Sep 29, 2017 at 8:58 AM, Jason Schiller <[email protected]> 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. > Further, a "shall" standard would not allow the ISP or ARIN Staff any discretion, with a "shall" standard the mere fact that the enduser made the request means the ISP MUST make the registration, except for the reasons explicitly provided in policy. If the ISP has a valid reason, not explicitly covered in policy, to not make the registration, a "should" standard allows ARIN Staff to consider that on equal footing with the reasons the enduser wants the registration. 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. > "Should" is not completely optional, it recognizes there could be valid reasons for an exception. Where as, "shall" is required, unless an exception is explicitly provided. "May" is completely optional. Therefore, with a "should" standard, if the situation escalated to the point of ARIN making an official inquiry, the ISP will need to articulate a valid reason why they have not made the requested registration, that is at least as compelling as the reason for the request by the enduser. Not doing so would be tantamount to being out of compliance with ARIN policy. Thanks. -- =============================================== David Farmer Email:[email protected] Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> ===============================================
_______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
