Re: [Gen-art] Genart last call review of draft-ietf-ntp-packet-timestamps-07

[Alissa Cooper <[e-mail]>]

Russ, thanks for your review. Tal, thanks for addressing Russ’ review. I entered a No Objection ballot.

Best,
Alissa


> On Feb 16, 2020, at 9:20 AM, Tal Mizrahi <[e-mail]> wrote:
> 
> Hi Russ,
> 
> Many thanks for the thorough review.
> 
> Please see the proposed changes below and let us know if they make
> sense. If there are no further comments we will implement these
> changes along with other changes following IETF last call.
> 
> Cheers,
> Tal.
> 
> 
> On Fri, Feb 7, 2020 at 9:42 PM Russ Housley via Datatracker
> <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Reviewer: Russ Housley
>> Review result: Almost Ready
>> 
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed
>> by the IESG for the IETF Chair.  Please treat these comments just
>> like any other last call comments.
>> 
>> For more information, please see the FAQ at
>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>> 
>> Document: draft-ietf-ntp-packet-timestamps-07
>> Reviewer: Russ Housley
>> Review Date: 2020-02-07
>> IETF LC End Date: 2020-02-20
>> IESG Telechat date: Unknown
>> 
>> 
>> Summary: Almost Ready
>> 
>> Major Concerns: None
>> 
>> 
>> Minor Concerns:
>> 
>> Abstract: It is too long.  In my opinion, the second paragraph should
>> be moved to the Introduction.
> 
> [TM] Agreed.
> 
>> 
>> 
>> Section 2.1: Please use:
>> 
>>   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>>   "OPTIONAL" in this document are to be interpreted as described in
>>   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
>>   capitals, as shown here.
>> 
> 
> [TM] Agreed.
> 
>> 
>> Section 2.3, paragraph 1: I think it would be better to define timestamp
>> error without using the phrase "device under test".  If you disagree,
>> please add a definition for "device under test".
>> 
> 
> [TM] We propose the following text update:
> OLD:
> Timestamp error: The difference between the timestamp value at the
> device under test and the value of a reference clock at the same time
> instant.
> NEW:
> Timestamp: A value that represents a point in time, corresponding to
> an event that occurred or is scheduled to occur.
> Timestamp error: The difference between the timestamp value and the
> value of a reference clock at the time of the event that the timestamp
> was intended to indicate.
> 
> 
>> 
>> Section 3, Synchronization aspects: The paragraph should also say that
>> there might not be any synchronization considerations.  For example, an
>> epoch since the device was powered up does not have any.
>> 
> 
> 
> [TM] We propose the following text update:
> OLD:
> Synchronization aspects:
> 
> The specification of a network protocol that makes use of a packet
> timestamp is expected to include the synchronization aspects of using
> the timestamp. While the synchronization aspects are not strictly part
> of the timestamp format specification, these aspects provide the
> necessary context for using the timestamp within the scope of the
> protocol. Further details about synchronization aspects are discussed
> in Section 5.
> 
> NEW:
> Synchronization aspects:
> 
> The specification of a network protocol that makes use of a packet
> timestamp is expected to include the synchronization aspects of using
> the timestamp. While the synchronization aspects are not strictly part
> of the timestamp format specification, these aspects provide the
> necessary context for using the timestamp within the scope of the
> protocol. In some cases timestamps are used without synchronization,
> e.g., a timestamp that indicates the number of seconds since power up.
> In such cases the Synchronization Aspects section will specify that
> the timestamp does not correspond to a synchronized time reference,
> and may discuss how this affects the usage of the timestamp. Further
> details about synchronization aspects are discussed in Section 5.
> 
> 
>> 
>> Section 9:  Please say "such as Message Authentication Codes (MAC)".
>> HMAC is one instance of a MAC, and you are not trying to name a specific
>> algorithm here.
>> 
> 
> [TM] Agreed.
> 
>> 
>> Section 11.2:  RFC 1323 has been obsoleted by RFC 7323.  Is there a
>> reason that it is better ot reference the older document here?
>> 
> 
> [TM] Agreed.
> 
>> 
>> Nits:
>> 
>> General: Some places this Internet-Draft refers to itself as "this memo"
>> and other places if refers to itself as "this document".  Please pick.
>> 
> 
> [TM] Agreed.
> 
>> 
>> Section 1, paragraph 1: Nonces often have a timestamp embedded in them.
>> For example, TLS 1.2 [RFC5246] defined the nonce as:
>> 
>>         struct {
>>             uint32 gmt_unix_time;
>>             opaque random_bytes[28];
>>         } Random;
>> 
>> So, I think the paragraph should include something about using time to
>> create an unlikely to repeat value.
>> 
> 
> [TM] We propose the following text update:
> OLD:
> Timestamps are widely used in network protocols for various purposes,
> including delay measurement, clock synchronization, and logging or
> reporting the time of an event.
> NEW:
> Timestamps are widely used in network protocols for various purposes:
> timestamps are used for logging or reporting the time of an event,
> delay measurement and clock synchronization protocols both make use of
> timestamped messages, and in security protocols a timestamp is often
> used as a value that is unlikely to repeat (nonce).
> 
> 
>> 
>> Section 3: I do not find the "+" improves readability.
> 
> [TM] Agreed. We will use a different bullet symbol.
> 
> 
>> 
>> Section 3 says:
>> 
>>      The structure of the timestamp field consists of:
>> 
>>      + Size: The number of bits (or octets) used to represent the
>>      packet timestamp field.  If the timestamp is comprised of more
>>      than one field, the size of each field is specified.
>> 
>> Since there is only one item, I suggest:
>> 
>>      Size: The structure of the timestamp field consists of the number
>>      of bits (or octets) used to represent the packet timestamp field.
>>      If the timestamp is comprised of more than one field, the size of
>>      each field is specified.
> 
> [TM] Agreed.
> 
> 
>> Questions:
>> 
>> Should RFC 6019 be included in the table in Section 6?
> 
> [TM] Agreed.
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/gen-art <https://www.ietf.org/mailman/listinfo/gen-art>