[Dots] Benjamin Kaduk's Yes on draft-ietf-dots-rfc8782-bis-06: (with COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Thu, 27 May 2021 04:58 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 501403A08F9; Wed, 26 May 2021 21:58:30 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk 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: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <162209150978.23407.5280863704183505347@ietfa.amsl.com>
Date: Wed, 26 May 2021 21:58:30 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/f6ctja36YHAiwMpVJKdbWvyrpnE>
Subject: [Dots] Benjamin Kaduk's Yes on draft-ietf-dots-rfc8782-bis-06: (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: Thu, 27 May 2021 04:58:31 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-dots-rfc8782-bis-06: Yes 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: ---------------------------------------------------------------------- In Section 4.4.1.3, the description of 'conflict-scope' for the case of conflicting requests from different clients has lost the "a list of prefixes" item as a possible scope. (The analogous text for the "conflicting with a different 'mid' case does still list prefixes as possible.) I see that there was some discussion in the genart thread about whether the "conflict-information" tree is really "optional" in certain cases. However, in going from the -04 to the -06, we also lost the marking that it "must only be used for responses", and I didn't quite follow why that change was needed. (I am not sure that we need to change the text, but please help me understand whether the node can be present in requests as well.) The genart reviewer also remarked: > Also, you need to specify whether > the connection to the alternate server is a new session (with > independent state) or whether it is expected to be a continuation of > the existing session (carrying the same state). to which Med responds "This is covered here: When the DOTS client receives a 5.03 response with an alternate server included, it considers the current request to have failed, but it SHOULD try resending the request to the alternate DOTS server." This wording seems to imply that the session state is preserved, but I think it would be beneficial to be explicit about it. >From the secdir thread, in Section 7.3, we may not need a new normative requirement that essentially duplicates what's already stated in RFC 6347. Since RFC 6347 already has a "MUST fit" requirement, we could just rely on that and avoid using new normative language, perhaps as: To avoid DOTS signal message fragmentation and the subsequent decreased probability of message delivery, the DLTS records need to fit within a single datagram [RFC6347].
- [Dots] Benjamin Kaduk's Yes on draft-ietf-dots-rf… Benjamin Kaduk via Datatracker