-----Original Message-----
From: Paul Kyzivat [mailto:pkyzi...@alum.mit.edu]
Sent: Sunday, February 28, 2016 11:38 PM
To: Tal Mizrahi; draft-ietf-ntp-checksum-trailer....@ietf.org
Cc: General Area Review Team; Brian Haberman (br...@innovationslab.net);
Suresh Krishnan; Karen ODonoghue (odonog...@isoc.org)
Subject: Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ntp-checksum-
trailer-04
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
