Hi Tal,
On 2/28/16 1:31 AM, Tal Mizrahi wrote:
Hi Paul,
Isn't this serious? IIUC in many (most?) cases the transmitters and
intermediate nodes won't know if the receiver supports [NTP-Ext].
Inserting this for those that don't will deny them of the time they are looking
for.
Shouldn't there be some discussion of how a decision can be made about
when to use this in order to avoid breaking receivers?
I believe that the Checksum Complement is most useful in LANs and in locally
administered environments, where both client and server are managed by the same
administrator. These are the cases where you need a high clock accuracy, and
you will want to get the extra juice from hardware timestamping + Checksum
Complement.
I believe it is less likely that the Checksum Complement will be used by a
client that connects to a random NTP server.
Having said that, I agree that this should be reflected in the draft, and thus
I suggest the following text for Section 3.3:
"The behavior defined in this document does not impose new requirements on the
reception of NTP packets beyond the requirements defined in [NTP-Ext]. Note that, as
defined in [NTP-Ext], a host that receives an NTP message with an unknown extension
field SHOULD ignore the extension field and MAY drop the packet if policy requires
it. Thus, transmitters and intermediate nodes that support the Checksum Complement
can transparently interoperate with receivers that are not
Checksum-Complement-compliant, as long as these receivers ignore unknown extension
fields. It is noted that existing implementations that discard packets with unknown
extension fields cannot interoperate with transmitters that use the Checksum
Complement.
It should be noted that when hardware-based timestamping is used, it will likely be
used at both ends, and thus both hosts that take part in the protocol will support
the functionality described in this memo. If only one of the hosts uses
hardware-based timestamping, then the Checksum Complement can only be used if it is
known that the peer host can accept the Checksum Complement."
OK. That seems like a reasonable way to deal with it.
I think so. However the erratam also has exactly the text I was hoping to find
describing how extensions and the mac are parsed out of the packet by the
receiver, and I don't see that in [NTP-Ext]. In principle it is not necessary
(it is
an exercise for the reader to figure out how to do this) but having it ensures
that developers get it right.
Is there a reason why [NTP-Ext] doesn't also pick that up from the erratam?
(Of course that has no bearing on *this* draft.)
Actually, [NTP-Ext] uses the exact text from the erratum (with some additional
text in the middle).
What *isn't* in [NTP-Ext] are the notes from the erratum - notably the
2nd one. ISTM that would be very helpful to readers.
(But my review of *this* document isn't conditioned on dealing with that.)
Do you plan to have a revised version out soon? So far this has been a
LC review. I'm also on the hook to to a telechat review. There is an
amazingly short gap (two days) between end of LC and the telchat. (I've
never seen it so tight. I wonder if people will have time to review a
revised document for the telechat?
If there is no revised document from the LC before the telechat then I
will simply send my same review again as the telechat review, along with
a note that we have agreed on some changes. If you plan on getting a new
revision out I will try to update my review accordingly.
Thanks,
Paul
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
