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

[Miroslav Lichvar <[e-mail]>]

On Wed, Jul 21, 2021 at 11:19:39AM +0000, Rob Wilton (rwilton) wrote:
> > Could you please clarify why you don't see the proposal as the right
> > way?
> 
> I think that my objections really come down to two points:
> 
> (1) The protocol has an extension mechanism, but the solution is choosing not to use it.

My view is that the fact that the protocol supports extension fields
doesn't necessarily mean they should be used for all extensions of the
protocol. So far, all specified extension fields provided additional
information that is not in the header.

With the interleaved mode we don't add information, we only switch the
reference of the transmit timestamp to correspond to the previous
packet instead of the packet in which the timestamp is contained. To
clearly indicate that we extend the protocol to allow the origin
timestamp to have a value that is not allowed by RFC5905 (in the
strict interpretation).

> I appreciate that the extension mechanism is deemed to be broken and NTPv5 is meant to fix it, but then I question why standardize this particular extension now, 10 years after NTPv4 was standardized.  I.e., presumably you could bake this enhancement into NTPv5 in a very clean way.

The interleaved mode was already included in the reference
implementation of RFC5905 when it was finalized. I wasn't following
the work of the WG at the time. I guess it was too late for the
addition. My understanding is that the WG was expected to provide a
specification for it at some point. Yes, it took a long time.

We are working on NTPv5. That may take many years. FWIW, one of the
current NTPv5 proposals has an interleaved mode. It doesn't use an
extension field for it. There is a flag in the header to select the
reference of the transmit timestamp.

> (2) It seems to be redefining the meaning of some of the protocol fields, not in a small way, and I'm not really sure that this is the right thing to be endorsing.  I.e., balloting "No objection" wouldn't really be right, because I do have an objection to what is being done here.

Ok, fair enough.

I don't view it as redefining the meaning, but rather as adding new
meanings, similarly to a field which has reserved values and their
meaning is defined only later in an extension.

Per RFC5905 the origin timestamp can be either zero (meaning unknown
or unsynchronized), or a copy of the transmit timestamp from the
received packet.

In this document we add a new possibility. It can be a copy of the
receive timestamp from the received packet.

> > 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?
> 
> I really don't know the protocol, and I think that I would need to have a much better understanding of RFC5905 to give a properly meaningful answer here.  Looking back at Daniel's comments, I am somewhat persuaded that RFC5905 states that these fields can be ignored, and doesn't say what value field must contain if they are 'ignored'.  But equally, if the field had a non-zero value then would that not also mean that field is being used, assuming that there are no other bits in the packet to indicate whether the field has meaning?  Hopefully, clarifying this is in the plan for the next version of NTP ...

Generally, if some field is ignored by server, does it mean that the
client is free to set it to whatever it likes? I suspect many other
protocols would be difficult to extend if that was the case.

Thanks,

-- 
Miroslav Lichvar