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
