[Dots] Martin Duke's No Objection on draft-ietf-dots-rfc8782-bis-07: (with COMMENT)
Martin Duke via Datatracker <noreply@ietf.org> Tue, 01 June 2021 22:39 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: dots@ietf.org
Delivered-To: dots@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 003043A2A12; Tue, 1 Jun 2021 15:39:38 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Martin Duke via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dots-rfc8782-bis@ietf.org, dots-chairs@ietf.org, dots@ietf.org, valery@smyslov.net, valery@smyslov.net
X-Test-IDTracker: no
X-IETF-IDTracker: 7.30.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Martin Duke <martin.h.duke@gmail.com>
Message-ID: <162258717896.27217.11487555052395475135@ietfa.amsl.com>
Date: Tue, 01 Jun 2021 15:39:38 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/JmkST38y9Jjnxq48aDcjjXLTGoM>
Subject: [Dots] Martin Duke's No Objection on draft-ietf-dots-rfc8782-bis-07: (with COMMENT)
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Jun 2021 22:39:39 -0000
Martin Duke has entered the following ballot position for draft-ietf-dots-rfc8782-bis-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dots-rfc8782-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing Michael Tuexen's TSVART review. As I did not review RFC8782, I'm taking this opportunity to review the entire document, rather than just the bis. I found numerous clarity issues: (4.4.1.1) How do DOTS servers detect a CUID collision? I believe Sec. 7 explains this is based on client authentication, but mentioning it here would be helpful. In the "mid" definition: s/no attack is detected/no attack is underway In the "target_fqdn" definition. The text appears to assume a DNS resolution; is there a not a use case where the DOTS server would rely on e.g. SNI inspection and not defend an entire IP address that had multiple domains? "lifetime" definition: The text says the DOTS server MAY reject unlimited lifetime, which implies that it MUST accept any finite lifetime. I presume you mean to say that DOTS servers are free to set a policy limit on the maximum allowable lifetime? (4.4.1.2) "cdid" definition: The example in Fig. 9 does not have a cdid that matches the cuid. The text indicates that these might not match if a client-side gateway added the cdid, but then later says that "only the first on-path server-domain DOTS gateway can insert a 'cdid' value." After reading this a few times, I think what you are saying is (a) clients MUST NOT add cdid; (b) client-side gateways SHOULD add them; (c) the first server-side gateway MUST strip them and then add their own; and (d) subsequent server side gateways MUST NOT change the cdid. Is this correct? Either way, it could be expressed less confusingly. (4.4.1.3) Fig. 11: Where does the second cuid come from? Is this generated by the server on behalf of the client? If so, I recommend s/a new request with a new 'cuid'/a new request with a new, server-provided 'cuid' When extending the lifetime, does the new lifetime field measure from the initial trigger or from the moment of extension? If the former, a change in the lifetime value is mandatory, not "potential." If the latter, how does the server distinguish this from a duplicate request? (4.4.2) Fig. 14 uses a string to represent the status instead of one of the values in Table 3. (4.4.3) Same with Fig. 16 and Table 4. (4.4.2.1) If updates are non-confirmable, how does the client know if it's gotten out of sync on state updates? (4.5.1) What is the unit of probing rate? (8) s/should/SHOULD, s/must/MUST throughout.
- [Dots] Martin Duke's No Objection on draft-ietf-d… Martin Duke via Datatracker
- Re: [Dots] Martin Duke's No Objection on draft-ie… mohamed.boucadair
- Re: [Dots] Martin Duke's No Objection on draft-ie… Martin Duke
- Re: [Dots] Martin Duke's No Objection on draft-ie… mohamed.boucadair
- Re: [Dots] Martin Duke's No Objection on draft-ie… Martin Duke
- Re: [Dots] Martin Duke's No Objection on draft-ie… mohamed.boucadair
- Re: [Dots] Martin Duke's No Objection on draft-ie… Martin Duke