Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ntp-checksum-trailer-04

[Paul Kyzivat <[e-mail]>]

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