| Russ, thanks for your review. Tal, thanks for addressing Russ’ review. I entered a No Objection ballot.
Best, Alissa
Hi Russ,Many thanks for the thorough review.Please see the proposed changes below and let us know if they makesense. If there are no further comments we will implement thesechanges along with other changes following IETF last call.Cheers,Tal.On Fri, Feb 7, 2020 at 9:42 PM Russ Housley via Datatracker<noreply@xxxxxxxx> 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 thedevice under test and the value of a reference clock at the same timeinstant.NEW:Timestamp: A value that represents a point in time, corresponding toan event that occurred or is scheduled to occur.Timestamp error: The difference between the timestamp value and thevalue of a reference clock at the time of the event that the timestampwas 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 packettimestamp is expected to include the synchronization aspects of usingthe timestamp. While the synchronization aspects are not strictly partof the timestamp format specification, these aspects provide thenecessary context for using the timestamp within the scope of theprotocol. Further details about synchronization aspects are discussedin Section 5.NEW:Synchronization aspects:The specification of a network protocol that makes use of a packettimestamp is expected to include the synchronization aspects of usingthe timestamp. While the synchronization aspects are not strictly partof the timestamp format specification, these aspects provide thenecessary context for using the timestamp within the scope of theprotocol. 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 thatthe timestamp does not correspond to a synchronized time reference,and may discuss how this affects the usage of the timestamp. Furtherdetails 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 orreporting 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 oftimestamped messages, and in security protocols a timestamp is oftenused 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 listGen-art@xxxxxxxxhttps://www.ietf.org/mailman/listinfo/gen-art
|
