[Int-area] Roman Danyliw's Discuss on draft-ietf-intarea-provisioning-domains-10: (with DISCUSS and COMMENT)

Roman Danyliw via Datatracker <noreply@ietf.org> Wed, 22 January 2020 17:52 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: int-area@ietf.org
Delivered-To: int-area@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C6D120837; Wed, 22 Jan 2020 09:52:55 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-intarea-provisioning-domains@ietf.org, Erik Kline <ek@loon.com>, intarea-chairs@ietf.org, ek@loon.com, int-area@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.116.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <157971557533.12303.3211893249207374638.idtracker@ietfa.amsl.com>
Date: Wed, 22 Jan 2020 09:52:55 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/zGEkip6bYDgFe3IRX4p0MsDBZEA>
Subject: [Int-area] Roman Danyliw's Discuss on draft-ietf-intarea-provisioning-domains-10: (with DISCUSS and COMMENT)
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jan 2020 17:52:56 -0000

Roman Danyliw has entered the following ballot position for
draft-ietf-intarea-provisioning-domains-10: Discuss

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-intarea-provisioning-domains/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Section 4.4.  Per “When a host retrieves the PvD Additional Information, it
MUST verify that the TLS server certificate is valid for the performed request
(e.g., that the Subject Alternative Name is equal to the PvD ID expressed as an
FQDN).  This authentication creates a secure binding between the information
provided by the trusted Router Advertisement, and the HTTPS server.”, what is
the trust anchor the client is supposed to use to valid the server certificate
is valid?  How is that trust anchor provisioned?


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

I support Ben Kaduk and Adam Roach’s DISCUSS positions.

Section 4.1.  Per “If the HTTP status of the answer is between 200 and 299,
inclusive, the host MAY get a file containing a single JSON object”, what
should be the behavior of a host that gets 200 status code  but no JSON object
– should it try again, conclude (like in a 4xx status code) that there is not
further information, etc.?