[sidr] Alissa Cooper's No Objection on draft-ietf-sidr-rpki-oob-setup-08: (with COMMENT)

Alissa Cooper <alissa@cooperw.in> Wed, 22 February 2017 21:28 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 6FE52129B7A; Wed, 22 Feb 2017 13:28:32 -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.45.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148779891245.31095.471497857432449461.idtracker@ietfa.amsl.com>
Date: Wed, 22 Feb 2017 13:28:32 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/UxeGPXYS9xMouXidpz1kEx4ebtk>
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 No Objection on draft-ietf-sidr-rpki-oob-setup-08: (with 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: Wed, 22 Feb 2017 21:28:32 -0000

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


Thanks for addressing my DISCUSS points, keeping COMMENTs below for

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.