Without a doubt the words "should" and "shall" are very different words from a
legal standpoint. Should can be understood as "may" while shall can be
understood as "must". The difference between permission and obligation is
night and day in a legal context.
Out of curiosity I took a look
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
+1
I would also prefer "shall" to "should", but the current text is
acceptable to me.
The "should", as I read it, only applies when downstream customers who
have an assignments of /48 or longer request to be SWIPed by their
upstream provider. If their assignment is a /47 or more, or if it
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
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 ha
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-boun...@arin.net] On Behalf Of Michael Winters
Sent: Friday,
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
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-boun...@arin.net] On Behalf Of Jason Schiller
Sent: Friday, September 29, 2017 9:59 AM
To: David Farmer
Cc: arin-ppml@arin.net
Subject: Re:
+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
> On Sep 29, 2017, at 8: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
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
As the author of the original proposal, I do want to see the main part of
this proposal advance and be passed. Since it has now been pointed out
that the language is currently frozen until the meeting, I note for the
record that I have no problem with the draft as currently written, and
would
On 28 Sep 2017, at 11:59 PM, Alexander, Daniel
> wrote:
Hello All,
I just wanted to mention some procedural points to consider in this discussion
and thank you all for contributing to this debate. It does provide helpful
13 matches
Mail list logo