Subject: [Ntp] Semantic difference between SHOULD and MAY?

From: [email-masked]
Date: Tue, 26 Mar 2019 15:58:14 +0100

Hello all,

I was trying to push this in as a last voluntary item in the WG session 
but was unsuccessful.
I had a follow-up question about people's understanding about the 
difference between SHOULD and MAY (triggered by Harlan's request about the 
Data Minimization draft).

Basically, I am frustrated about not being able to make a clear and 
meaningful semantic distinction from the text in 2119 that matches my 
intuition (or that of anyone that I have heard mention it).
I am trying to approach this from the viewpoint of someone trying to judge 
to what extent a given implementation conforms to a given specification 
(which I believe is the only relevant viewpoint for distinction in 
normative language).

1) Harlan says that he thinks that "SHOULD is basically MUST", which I 
find obvious to not be true: 
- If MUST is used and your code doesn't do it, then it doesn't conform, no 
further questions asked.
- If SHOULD is used and your code doesn't do it, then it might still 
conform if... something? (Some unnamed entity which cannot be held 
accountable must understand the full implications, is all I can find. This 
seems like a pretty generic get-out-of-nonconformity-free-card)

2) I thought myself (and at least Harlan seems to be of the same mind) 
that SHOULD is somehow stronger than MAY... but now I don't see that in 
2119's language:
- If SHOULD is used and your code doesnt do it, there is no mention of 
what actually happens further other than the elusive "full implications 
understood" clause.
- If MAY is used, then there are actual listed rules that any 
implementation "MUST" be prepared to interoperate with another 
implementation that decided differently on the MAY clause... this is a 
pretty strong (and palpable) requirement that can 100% let you decide on 
conformity of a given implementation - and which is completely missing 
from the explanation for SHOULD. I'm guessing it is supposed to be there, 
implicitly, in only the direction that an implementation that decides to 
ignore the SHOULD / SHOULD NOT clause must be prepared to interoperate 
with any implementation that follows it? But that's a frustratingly big 
thing to have to interpret into the actual text.

So, is there anything you can give me (and support with written language) 
about an actual, normative (!) difference between SHOULD and MAY?
Would you agree that MUST / SHALL and MUST NOT / SHALL NOT are the only 
normative clauses that actually allow a deterministic and objective code 
conformity evaluation after the fact?
Am I missing something obvious? This does not seem like an issue that 
should be open for interpretation.
Is there a better resource than 2119 on this that I did not find?

Best regards and everyone please forgive my ignorance,
Kristof

P.S.: 
Note that I am NOT looking for an explanation that the difference between 
SHOULD and MAY can be used to communicate degrees of 
preference/recommendation/default if someone is unsure.
I understand that, but I find that it matters very little for the 
normative evaluation of standard text.

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 26 Mar 2019 17:53:09 +0100

>>> <[email-masked]> schrieb am 26.03.2019 um 15:58 in Nachricht
<[email-masked]>:
> I had a follow‑up question about people's understanding about the 

Maybe like this ;-)
SHOULD: Your karma will increase if you do so.
SHOULD NOT: Your karma will decrease if you do so
MAY: Your karma does not decrease if you do.
MUST: Your karma will significantly decrease if you do not.
MUST NOT: Your karma will significantly decrease if you do.

OK, heading for good karma...

Regards,
Ulrich

---

From: Daniel Franke <[email-masked]>
Date: Tue, 26 Mar 2019 18:04:08 +0100

See also RFC 6919.

On Tue, Mar 26, 2019 at 5:53 PM Ulrich Windl
<[email-masked]> wrote:
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 27 Mar 2019 03:12:46 -0700

On 3/26/2019 7:58 AM, [email-masked] wrote:
> difference between SHOULD and MAY (triggered by Harlan's request about
> the Data Minimization draft).
> 
> I am trying to approach this from the viewpoint of someone trying to
> judge to what extent a given implementation conforms to a given
> specification (which I believe is the only relevant viewpoint for
> distinction in normative language).
> 

I do not believe that SHOULD is as strong as MUST, in most cases.

This case is different.

My complaint is the use of this unequivocal language in the Introduction:

 ... However, in mode 3 packets (requests from client to
 server), most of these fields serve no purpose.  Server
 implementations never need to inspect them, and they can
 achieve nothing by doing so.  Populating these fields with
 accurate information is harmful to privacy of clients
 because...

If these statements are true, then the SHOULD recommendations really
becomes more imperative to me.

If there are cases where one might not implement these choices, then by
definition the statement "server implementations never need to inspect
them, and they can achieve nothing by doing so." is clearly wrong.

The end of the introduction says "clients which implement these updates
will remain fully interoperable with existing servers."  This is
technically true, but I see it as an attempt to drive a stake thru the
heart of any proposal that tries to relax this proposal's assertions and
recommendations.  We have already seen this proposal deterring any
future proposals that would seek to use correct information in these
fields, with vague suggestions of "oh, just put the data you want in an
EF".  As if space in a UDP packet is not already limited.

Later in Section 3, blanket recommendations are made about zeroing other
fields without thought or regard for any use-cases or circumstances
where the information might be useful or beneficial.

To me, the language in the proposal as written lacks accountability and
integrity.  I find the existing language to be imperious and
short-sighted, dishonest and unbelievable.  I start to wonder where else
the authors have done this, in all of their proposals.

Aanchal, do you stand by this document as it is written?

-- 
Harlan Stenn, Network Time Foundation
http://nwtime.org - be a Member!