Oops, in my list of cases where the existing wording does not make it
optional (in my previous reply), I left out "the prefix is being
separately routed".
On 9/29/2017 2:25 PM, David Farmer wrote:
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]
<mailto:[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] <mailto:email%[email protected]>
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 612-626-0815
<tel:%28612%29%20626-0815>
Minneapolis, MN 55414-3029 Cell: 612-812-9952 <tel:%28612%29%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.
--
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 ([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.
