Re: [sidr] AD Review of draft-ietf-sidr-rpki-oob-setup-04

Rob Austein <> Wed, 21 December 2016 01:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 50D0C1296E4; Tue, 20 Dec 2016 17:15:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.001
X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yll6dcXQ1WHB; Tue, 20 Dec 2016 17:15:50 -0800 (PST)
Received: from ( [IPv6:2001:418:8006::30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 29C2B1296D5; Tue, 20 Dec 2016 17:15:50 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "", Issuer "Grunchweather Associates" (not verified)) by (Postfix) with ESMTPS id 944AB1399E; Wed, 21 Dec 2016 01:15:48 +0000 (UTC)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id D34DF446EADB; Tue, 20 Dec 2016 20:14:42 -0500 (EST)
Date: Tue, 20 Dec 2016 20:14:42 -0500
From: Rob Austein <>
To: "Alvaro Retana (aretana)" <>
In-Reply-To: <>
References: <> <> <>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <>
Archived-At: <>
Cc: Chris Morrow <>,, Rob Austein <>,,
Subject: Re: [sidr] AD Review of draft-ietf-sidr-rpki-oob-setup-04
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 Dec 2016 01:15:51 -0000

Proposed -05, reflecting comments from AD review:

Absent objections, I will post to I-D repository, probably tomorrow.

Note for anybody going over the changes with a fine-tooth comb: there
was one minor correction which could be construed as substantive.
It's purely a syntax issue, with no effect on protocol semantics.  The
textual description of the <authorization/> token reflected an earlier
version of the protocol syntax in which there was an extra <bpki_ta/>
element nested within the <authorization/> element.  This changed some
time ago in the schema, the examples, and the running code, but
apparently nobody (including me) noticed the old syntax lurking in the
text.  Had this come up after publication I would called it an
erratum, but since we caught it now, I just went ahead and fixed it. :)