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 <tal.mizrahi....@gmail.com> 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 > <nore...@ietf.org <mailto:nore...@ietf.org>> 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 > Gen-art@ietf.org <mailto:Gen-art@ietf.org> > https://www.ietf.org/mailman/listinfo/gen-art > <https://www.ietf.org/mailman/listinfo/gen-art>
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
