Re: [Ntp] Robert Wilton's Discuss on draft-ietf-ntp-interleaved-modes-05: (with DISCUSS and COMMENT)

[Miroslav Lichvar <[e-mail]>]

On Fri, Jul 16, 2021 at 09:39:47AM +0000, Rob Wilton (rwilton) wrote:
> Regarding the issue with the extension mechanism, another possible choice could be for the client to try and open two parallel sessions, one using a new extension field, and one without.  The client could then monitor the responses to the two sessions and choose whether to use the other with the extension or not.

To me that doesn't look like a very practical solution. It wastes
bandwidth. SNTP clients use only one server and might not easily be
modified to work with multiple associations. In case of a heavy packet
loss, the client would be randomly switching between the two
associations, or if it stuck to the interleaved mode once it was found
working, it wouldn't fall back to RFC5905 if the server lost the
support (e.g. after changing implementation implementation or
reconfiguration), so it would have to restart the parallel association
periodically.

Using a 28-octet extension field to convey a single bit of information
is quite wasteful anyway.

> Hence, I propose three possible alternatives:
> 
> (1) Change this document to somehow make use of NTPs extension mechanism and continue down the path of publishing as a proposed standard.  This, I think, would probably entail taking the document back to the WG.
>
> (2) Change the document status to Informational rather than Standards Track, modifying the text to focus on documenting how some implementations work rather than as an endorsement from IETF that this is the right way to modify the NTP protocol.
> 
> (3) Alternatively, if the authors/WG believe that publishing that document as proposed standard is definitely the right choice, then I would be willing to change my ballot position to abstain.  I.e., I don't agree with what is being done here, but neither will I block progression of the document, given that you say that this modification does not cause operational issues in practice.

If those are the only options, the preference of the WG seems to be
the second one.

Could you please clarify why you don't see the proposal as the right
way? Do you agree with the RFC5905 interpretation that Daniel Franke
pointed out in his objection, that SNTP clients are free to put
anything in the origin timestamp because the "An SNTP client can
operate with any subset of the NTP on-wire protocol" doesn't have
a MUST?

Thanks,

-- 
Miroslav Lichvar