Hi Paul, A new version of the draft has been posted, and I believe it addresses all the comments you raised. https://tools.ietf.org/html/draft-ietf-ntp-checksum-trailer-05
Thanks, Tal. >-----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 _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
