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

[Tal Mizrahi <[e-mail]>]

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:[e-mail]]
>Sent: Sunday, February 28, 2016 11:38 PM
>To: Tal Mizrahi; [e-mail]
>Cc: General Area Review Team; Brian Haberman ([e-mail]);
>Suresh Krishnan; Karen ODonoghue ([e-mail])
>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