Re: [Ntp] [Last-Call] Genart last call review of draft-ietf-ntp-interleaved-modes-04

[Lars Eggert <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/last-call