[OPSAWG] Benjamin Kaduk's No Objection on draft-ietf-opsawg-sdi-12: (with COMMENT)

Benjamin Kaduk via Datatracker <noreply@ietf.org> Fri, 19 June 2020 22:22 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: opsawg@ietf.org
Delivered-To: opsawg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F41F23A0ED0; Fri, 19 Jun 2020 15:22:53 -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-opsawg-sdi@ietf.org, opsawg-chairs@ietf.org, opsawg@ietf.org, Michael Richardson <mcr+ietf@sandelman.ca>, mcr+ietf@sandelman.ca
X-Test-IDTracker: no
X-IETF-IDTracker: 7.3.2
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <159260537351.29279.9667056597503083162@ietfa.amsl.com>
Date: Fri, 19 Jun 2020 15:22:53 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/YfQ-Kk8tkjbSyQdwXs5fUn572Hg>
Subject: [OPSAWG] Benjamin Kaduk's No Objection on draft-ietf-opsawg-sdi-12: (with COMMENT)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jun 2020 22:22:54 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-opsawg-sdi-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 IESG DISCUSS and COMMENT positions.


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



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

Thanks for the updates in the -12 (and -11?  My notes claim I reviewed the -10,
though the datatracker history says it was the -11; perhaps there was some skew
between when I opened the doc and balloted).  They get most of the way to where
I want us to be, so I'm switching to No Objection.  That said, the Abstract and
Introduction still feel like they're slightly overstating the confidentiality
protection attainable with this mechanism:

The Abstract currently says "to provide confidentiality to initial configuration
during bootstrapping", but we may need to hedge that a bit more, e.g., that
this is partial or limited confidentiality.  Similarly, Section 1 currently
says "while maintaining confidentiality of the initial configuration", and
would get similar treatment.

Finally, I see that you took my suggestion of using "directory service" instead
of "Certificate Publication Server".  It may be worth a reference for this
concept -- e.g., Section 2.1 of RFC 5280 references both [X.500] and RFC 4510
as potential ways to provide directory service for obtaining certificates.