[sidr] Alissa Cooper's Discuss on draft-ietf-sidr-rpki-oob-setup-06: (with DISCUSS and COMMENT)

"Alissa Cooper" <alissa@cooperw.in> Tue, 17 January 2017 18:00 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: sidr@ietf.org
Delivered-To: sidr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C84129424; Tue, 17 Jan 2017 10:00:29 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alissa Cooper <alissa@cooperw.in>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.40.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148467602955.32082.12289843566112325669.idtracker@ietfa.amsl.com>
Date: Tue, 17 Jan 2017 10:00:29 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/q-u6z96J-eVIsOZlAtuR6Zu5fa4>
Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-rpki-oob-setup@ietf.org, sidr@ietf.org
Subject: [sidr] Alissa Cooper's Discuss on draft-ietf-sidr-rpki-oob-setup-06: (with DISCUSS and COMMENT)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Jan 2017 18:00:29 -0000

Alissa Cooper has entered the following ballot position for
draft-ietf-sidr-rpki-oob-setup-06: 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:


(1) I agree with Mirja that this document seems to be missing the actual
protocol specification, unless Section 6 is meant to provide the
normative specification of how the messages are to be exchanged. Is it?
If so, I would expect that to be explicit in the document.

(2) If there is in fact supposed to be a protocol specified here, I have
the same question as I had on draft-ietf-sidr-publication, which is how
do the entities migrate from one version to another and do version


5.2.4: Per my comment on  draft-ietf-sidr-publication, it would be good
if service_uri accommodated either HTTPS or HTTP URLs, if HTTP URLs must
be supported.

5.4: If it becomes obvious that a new reason code needs to be added to
the <error /> element in the future, will that require a new version of
the protocol? That seems like a bit of a heavy lift as compared to, say,
creating a registry for these with an appropriate registration policy.