Theresa, thank you for your review. I have entered a No Objection ballot for this document for now, but support Warren's Discuss and may eventually Abstain, depending on how the discussion goes. Lars > On 2021-4-7, at 4:43, Theresa Enghardt via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Theresa Enghardt > Review result: Ready with Issues > > 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 > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-ntp-interleaved-modes-04 > Reviewer: Theresa Enghardt > Review Date: 2021-04-06 > IETF LC End Date: 2021-04-14 > IESG Telechat date: Not scheduled for a telechat > > Summary: The draft is basically ready for publication as a Standards Track RFC, > but it has some clarity issues that need to be addressed before publication. > > Major issues: None. > > Minor issues: > > Section 1: > The introduction describes design considerations for changing the semantics of > existing timestamps, rather than introducting additional packets. However, it > does not mention negotiation. Please add ome text to the introduction clrifying > how interleaved mode is negotiated, implicitly (if I understand correctly). > Furthermore, the introduction should mention that clients, servers, and peers > now have to infer whether a received packet is in basic mode or interleaved > mode from the timestamps themselves and their cached knowledge (if I understand > correctly). Has explicit negotiation been considered? What would be the > consequence of a client, server, or peer failing to correctly determine whether > a received packet is in basic or interleaved mode, perhaps due to an > implementation error? Please consider adding a few sentences to discuss this > scenario. > > The introduction also does not mention whether a client, server, or peer that > supports interleaved mode has to operate in interleaved mode exclusively, or > whether it can switch between interleaved mode and basic mode. The document > later clarifies this, but please consider already clarifying here that an > implementation must support both modes if it wants to use interleaved mode, and > that a given sequence of messages can switch between both modes, to make the > scope clearer and the subsequent sections easier to understand. > > Section 2: > Here the document first mentions the origin timestamp, where previously the > document has only talked about transmit and receive timestamps. I think it > would be good to briefly explain what the origin timestamp is, how this > document is changing its semantics, and why. Section 7.3 of RFC 5905 defines > "Origin Timestamp (org): Time at the client when the request departed for the > server", but this document says "A client request in the basic mode has an > origin timestamp equal to the transmit timestamp from the previous server > response, or is zero." If basic mode is RFC 5905, I would have expected these > definitions to match. Has the definition of origin timestamp changed from RFC > 5905 to what this document terms basic mode? Please clarify. > > Can a server only respond in interleaved mode if the client request was in > interleaved mode? Please clarify. (Section 3 says that a peer "MUST NOT respond > in the interleaved mode if the request was not in the interleaved mode", but I > have not found a similar statement for client/server interleaved mode.) > > "Both servers and clients that support the interleaved mode MUST NOT send a > packet that has a transmit timestamp equal to the receive timestamp in order to > reliably detect whether received packets conform to the interleaved mode." I > think the document should reiterate in this section that a server or client has > to perform such detection (on each incoming packet?), and how to make this > determination. > > Section 3: > "The peer A has an active association with the peer B which was specified with > an option enabling the interleaved mode" This sentence reads as if there is an > option to explicitly enable the interleaved mode. Howeve, this document does > not change the NTP packet format or add an option. Please clarify/rephrase. > > Nits/editorial comments: > > Section 1: > "in the user space" -> "in user space" > > "would enable a traffic amplification" -> "would enable a traffic amplification > attack" > > To make Section 2 easier to navigate, maybe it would help to add subsections, > e.g., "Field semantics", "Protocol operation", and "Example". > > Section 3: > "The peers SHOULD compute the offset and delay using one the two sets of > timestamps specified in the client/server section" -> "[…] using one of the two > sets of timestamps […]" > > > -- > last-call mailing list > last-call@xxxxxxxx > https://www.ietf.org/mailman/listinfo/last-call
Attachment:
signature.asc
Description: Message signed with OpenPGP
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
