[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].