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

[Warren Kumari via Datatracker <[e-mail]>]

Warren Kumari has entered the following ballot position for
draft-ietf-ntp-interleaved-modes-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ntp-interleaved-modes/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I'm quite uncomfortable with the "we'll just change the meaning of some fields,
and implementations will be fine with this" tone. The document says: "An
explicit negotiation would require a new extension field, which would not work
well with implementations that do not respond to requests with unknown
extension fields.", and so this plays some tricks to encode information in
existing fields. This feels incredibly hacky, but I figured that it's probably
all fine if it has been shown to work well across a very very large set of
implementations without causing backward issues.

The Shepherd Writeup
(https://datatracker.ietf.org/doc/draft-ietf-ntp-interleaved-modes/shepherdwriteup/
) says: "There are multiple implementations of the document. They are discussed
in Section 5, entitled "Implementation Status".", so I felt hopeful that there
had been extensive testing, but I was not able to find a section entitled
"Implementation Status" in any version of draft-mlichvar-ntp-interleaved-modes
or draft-ietf-ntp-interleaved-modes.

What I *did* find was:
5.  Acknowledgements

   The interleaved modes described in this document are based on the
   implementation written by David Mills in the NTP project [1].  The
   specification of the broadcast mode is based purely on this
   implementation.  The specification of the symmetric mode has some
   modifications.  The client/server mode is specified as a new mode
   compatible with the symmetric mode, similarly to the basic symmetric
   and client/server modes.

So, from what I understand, the broadcast mode is based in the linked
implementation (a pointer to where in the codebase this is implemented would
have been much more helpful than just a link to http://www.ntp.org), but the
more complex, and (FWICT) likely to cause interoperability issues pars have 
"some modifications" and "a new mode compatible with the symmetric mode".

So, are there in fact "multiple implementations of the document."? Has there
been interoperability testing to confirm that there are no backwards
compatibility issues? Much of the document feels somewhat hand-wavy regarding
the compatibility with existing implementations, as well as in things like:
"The client SHOULD limit the number of requests in the interleaved mode between
server responses to prevent processing of very old timestamps in case a large
number of consecutive requests is lost." -- SHOULD limit to what number? 1? 3?
17?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

When the document says things like:
"A peer A SHOULD send a peer B a packet in the interleaved mode only when the
following conditions are met:" I'm assuming that this means "only when the
**all** following conditions are met:"? If so, it needs to be explicit.

To be clear, when the document says:
"1.  The peer A has an active association with the peer B which was
       specified with the option enabling the interleaved mode, OR the
       peer A received at least one valid packet in the interleaved mode
       from the peer B."

If "peer A has an active association with the peer B which was **not**
specified with the option enabling the interleaved mode" and "peer A receive[s]
at least one valid packet in the interleaved mode from the peer B." should it
enable interleaved mode? How is an operator supposed to know if they should
enable this mode when talking to a peer?

As far as I can tell, this adds a significant amount of state keeping to server
implementations. The document does somewhat mention this ("A server which
supports the interleaved mode needs to save pairs of local receive and transmit
timestamps.  The server SHOULD discard old timestamps to limit the amount of
memory needed to support clients using the interleaved mode."), but it seems
like this is a fairly large change, and this bit of text doesn't really cover
the state requirements.