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

Lars Eggert <lars@eggert.org> Mon, 12 July 2021 14:27 UTC

Return-Path: <lars@eggert.org>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E983A19C1; Mon, 12 Jul 2021 07:27:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level:
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lMY48ul0EPh; Mon, 12 Jul 2021 07:27:40 -0700 (PDT)
Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E21B3A1A08; Mon, 12 Jul 2021 07:27:36 -0700 (PDT)
Received: from smtpclient.apple (unknown [85.131.57.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id CFDA460034E; Mon, 12 Jul 2021 17:27:29 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1626100050; bh=1hovcOHuO/U+1Dm0G5QeycfkduQd5xheIuk1AyFF+Gw=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=Y5KuTOIe0Db1SbAgD8znlBiyppUScAkZso3y/uGLeQPv5rPEGxNHThgdXKqbH1b+I j6w/DE4YfE40kG+VyY7lsNiUJ04Ih4H/8w4haGAVNNVORN1x+NXw91KVnsByH8UXkI N64imkWhSVtzhj6mSxy8C7WSM4UeMvsGG3v4ZpTQ=
From: Lars Eggert <lars@eggert.org>
Message-Id: <B8293FE9-1B46-4B59-8D36-6C36340D6BFD@eggert.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_E9F943BD-4FEF-4873-AE44-223FFE622765"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Date: Mon, 12 Jul 2021 17:27:29 +0300
In-Reply-To: <161775979281.30506.6808949864064810668@ietfa.amsl.com>
Cc: General Area Review Team <gen-art@ietf.org>, last-call@ietf.org, ntp@ietf.org, draft-ietf-ntp-interleaved-modes.all@ietf.org
To: Theresa Enghardt <ietf@tenghardt.net>
References: <161775979281.30506.6808949864064810668@ietfa.amsl.com>
X-MailScanner-ID: CFDA460034E.A342E
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/NptTVrjpiuwuui0SXCX2Hz3cOP8>
Subject: Re: [Gen-art] [Last-Call] Genart last call review of draft-ietf-ntp-interleaved-modes-04
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Jul 2021 14:27:45 -0000

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@ietf.org> 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@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call