[babel] Benjamin Kaduk's No Objection on draft-ietf-babel-yang-model-12: (with COMMENT)

Benjamin Kaduk via Datatracker <noreply@ietf.org> Thu, 16 September 2021 21:38 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: babel@ietf.org
Delivered-To: babel@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EC60E3A0598; Thu, 16 Sep 2021 14:38:41 -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-babel-yang-model@ietf.org, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake <d3e3e3@gmail.com>, d3e3e3@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.37.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <163182832115.20818.13304017783978901966@ietfa.amsl.com>
Date: Thu, 16 Sep 2021 14:38:41 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/lhmC2zeBQPjxZhsP0v80Q9mq_-8>
Subject: [babel] Benjamin Kaduk's No Objection on draft-ietf-babel-yang-model-12: (with COMMENT)
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Sep 2021 21:38:42 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-babel-yang-model-12: 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:


Many thanks for the updates between the -10 and the -12; I'm happy to
report that they address my DISCUSS points (and all the COMMENT points
that I checked, as well)!

I'm terribly sorry to have failed to notice this previously, but when we
discuss the "cached_info" TLS extension, we mention its use in the
ClientHello and ServerHello messages.  However, for TLS 1.3 it seems
that this extension would probably not belong in the ServerHello, but
rather in the EncryptedExtensions message; unfortunately, this does not
actually seem to be formally specified anywhere (see
https://github.com/tlswg/tls13-spec/issues/1237).  If we're not
comfortable mentioning EncryptedExtensions by name, my suggestion would
be to make the change

               "Indicates whether the cached_info extension is enabled.
                The extension is enabled for inclusion in ClientHello
                and ServerHello messages if the value is 'true'.";

               "Indicates whether the cached_info extension is enabled.
                The extension is enabled for inclusion in TLS handshake
                messages if the value is 'true'.";

Appendix A

[Just noting that I did not review the new tree diagram or modified
examples, on the assumption that they were mechanically generated, and
the tool used to produce them is a more reliable cross-check against the
actual YANG model than a human (me).]