[Dots] John Scudder's No Objection on draft-ietf-dots-robust-blocks-05: (with COMMENT)

John Scudder via Datatracker <noreply@ietf.org> Thu, 29 September 2022 21:09 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 B4604C14F607; Thu, 29 Sep 2022 14:09:15 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: John Scudder via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dots-robust-blocks@ietf.org, dots-chairs@ietf.org, dots@ietf.org, valery@smyslov.net, valery@smyslov.net
X-Test-IDTracker: no
X-IETF-IDTracker: 8.17.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: John Scudder <jgs@juniper.net>
Message-ID: <166448575573.6840.2785747652855537014@ietfa.amsl.com>
Date: Thu, 29 Sep 2022 14:09:15 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/gaXB1HvYi4VBPODxW2s9DRzTqT8>
Subject: [Dots] John Scudder's No Objection on draft-ietf-dots-robust-blocks-05: (with COMMENT)
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.39
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, 29 Sep 2022 21:09:15 -0000

John Scudder has entered the following ballot position for
draft-ietf-dots-robust-blocks-05: 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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dots-robust-blocks/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this spec. Also, thanks to Valery Smyslov for the carefully-
written shepherd writeup.

I have just one comment, and one question, about this in Section 3:

   max-payloads:  This attribute echoes the MAX_PAYLOADS parameter in
      [RFC9177].

      This is an optional attribute.  If the attribute is supplied in
      both 'idle-config' and 'mitigating-config', then it MUST convey
      the same value.  If the attribute is only provided as part of
      'idle-config' or 'mitigating-config', then the other (missing)
      definition MUST be updated to the same value.

I think what you're saying here is that if max-payloads is set for
either idle-config or mitigating-config, then that parameter shall be
deemed set for both configs, and to the same quantity. I found the
way of saying it above to be quite confusing, especially the "(missing)"
thing, since if it's optional it can hardly be said to be "missing" just
because it isn't present.

I also wonder if you need to supply some answer to the question of
what should happen if the MUST is violated. E.g. one option might be
to say that if two different values are supplied, the larger of the
two shall be used for both.