[Ntp] Antwort: Re: WGLC - draft-ietf-ntp-ntpv5-requirements

[[e-mail]]

Hey all,

in home office with an injured wife, one kid whose daycare personnel have too many sick to take him today and another kid who is sick himself... I'm going to treat these piecemeal over multiple mails. 

Sorry for any lack of clarity that might result, but I do think it is better to treat as much of this as possible before our call later.

First, all things related to #1:

>> General comments:
>> - It often seems unclear what this document is regulating (what its
>MUST, SHOULD, etc. applies to).
>
>(#1) My comment in response to this is in the next point raised.
>
>> * Sometimes, it explicitly states that it applies to "the
>[upcoming NTPv5] specification"; this is at least clear and
>verifiable and seems helpful. We give a soft recommendation to change
>to this wherever possible.
>
>(#1) Thank you for providing a recommendation, however what is
>specifically ambiguous of it being absent? The very first section of
>the document - the abstract - makes it clear we're talking about
>NTPv5 throughout. Are there any specific points where there is
>relative language is referring to a different protocol or could be
>(mis)interpreted as such?

You're right that it is very clear that it's about NTPv5, but: does it regulate the NTPv5 specification (the upcoming document), or NTPv5 implementations (the code), or the NTPv5 user base, or something else?

Because the present document behaves like a specification, mostly by using normative language, which means it tries to regulate something. 

But if I have a list of requirements or normative clauses, then I need to know which object, once complete, I should check against said list of requirements.

The present document clearly is not a standards track specification (if it were, it wouldn't have the 'informational' designation), so if I have an NTPv5 implementation candidate, I shouldn't check it against this document (and instead against the actual NTPv5 standards track RFC).

And the abstract 'the protocol' (I guess the union of all NTPv5 specifications and implementations) is IMO simply not concrete enough for anyone to sit down and check it against a requirement list. 

The best sense I can then see in us having the present document as an RFC (and I agree with Daniel, it is not obvious to me that we need it as such) is if we use it as a mostly binding commitment to check our upcoming NTPv5 RFC against what we decided was important.

And I'm saying I don't want to be reading all of that into the document myself, I want it to be explicit about it.

A short statement to this effect would go a long way (and then the rest of the text needs to be looked at for instances where it instead tries to regulate implementations or user behavior, see below).

>> * Sometimes, it alludes to "the WG should be doing X"; we
>are unsure if this is proper for an RFC.
>
>(#1) The only immediate statement I note is in Section 4.3
>(Algorithms) where it is suggested without normative text the WG
>create a separate document regarding algorithms as it has been a
>long-standing goal of NTPv5 to keep them separate from protocol
>specification to endorse agility. For all those allusions, which ones
>exactly are of concern to you, and what do you propose exactly?

You're right, this 'sometimes' could have been a 'once'.

The way I would like this done would be to mention only that which fits with the scope outlined above: 

If we can agree to add a sentence earlier to the effect of 'this document is supposed to be an orientation for how the upcoming NTPv5 standards track RFC is to be written', then we can for the current point just add one line 

"The NTPv5 RFC should/SHOULD cover the on-wire protocol only; processing algorithms and clock disciplining techniques can be covered in separate documents.", 

and I'd be content.

This is one of those instances where it would be really easy to adapt the language to focus on 'we regulate how the upcoming NTPv5 RFC should behave'.

>> * Sometimes, the context implies that the requirements
>apply to a (to each?) protocol implementation; we are unsure about
>this.
>
>(#1) Could you provide specific examples of what you mean please.

I get that this is bordering on the pedantic (especially since each of these could also be read as 'this document requires that the specification require that clients/servers do X'), but: 

4.1 "Clients SHOULD periodically re-establish connections with servers"

"Servers SHOULD be able to migrate and change  any identifier used"

4.6 "Servers that support multiple versions of NTP MUST send a response in  the same version as the request"

There are more instances, but they are even more debatable.

>> * Most often, requirements are stated to apply to "the
>protocol"; this seems very abstract, non-verifiable, and overall
>confusing.
>
>(#1) This appears to be a duplicate point to one already made
>regarding the recommendation of using language of "the [upcoming
>NTPv5] specification". Is that correct, or is there something I have
>missed?

See above: this is what is generally done most in the document and I think it is too ambiguous.

>> - There are lots of instances of non-capitalized "should" (and
>possibly others?); these need to be checked and either eliminated or
>capitalized. Related, there is at least one SHALL NOT between more
>MUST NOTs; overall, consistency needs to be improved for normative
>clauses.
>
>(#1) The use of normative vs non-normative wording is not erratic and
>intentional, recognising the strength and impact normative language
>has on defining the limits and capabilities of the NTPv5 protocol.
>This document is not just about setting explicit MUST and MUST NOTs;
>it's also a reflection of discussion and viewpoint. If there is any
>normative or non-normative language you disagree with please state
>which ones exactly, what you propose they change to and why - I do
>not agree to any suggestion that all should either be made normative
>or removed.

Fair.

I think there is a point to be made that any non-normative 'should' could be replaced with some synonym/alternative ('ought to', 'needs to', 'could', 'is expected to', depending) so as to not be confusing.

There are also  6 (I think) instances of non-capitalized 'must', and I find it hard to believe that all of those are intentional (also, I think there is an even stronger point to be made that confusion should be avoided via synonyms/alternatives if it is intentional).

>> - The overwhelming majority of normative terms are "SHOULD"; it
>seems more helpful to have more "MUST" - if we're going to regulate
>things, we should avoid so much use of a term that basically means
>"we would like you to do this, but in the end do whatever you want".
>
>(#1) The choice of using SHOULD has been in recognition that MUST can
>be confrontational and there may be valid circumstances where
>exceptions could be made, foresight is generally more limited than
>hindsight. As I've previously stated - if there are specific
>normative words you feel require changing please state which
>specifically. Please keep in mind just because this document says it
>"MUST" does not prevent future specification deviating.

I mean, none of these remarks around normative language are in themselves blocking issues to me, so might as well ignore them for now.

Still I feel that if we're reporting on WG consensus, we want to be stating a clear decision (probably using MUST) as much as sensible (because checking a finished NTPv5 spec against a list of SHOULD is pretty meaningless, it fulfills the requirement whether it does the thing it SHOULD have done or not).

I'm also missing any allusion to the WG not having full/clear consensus on something; I can barely believe we are in this much agreement :)

>> - We think the document should state the scope of its requirements
>(on-wire protovol only vs. including processing algorithms vs.
>everything, including clock disciplining).
>
>(#1) The document does state that it covers what should be part of
>the protocol, and that algorithms should be done separately in
>section 4.3. If you feel this is insufficient - please could you
>clarify further on what is unclear, or suggest what it should state.

See above.

And I think it might make this statement (that the spec should treat the on-wire protocol, and that the rest can be treated elsewhere) earlier than 4.3, at the latest in the introduction of 4.

Best regards,

Kristof