Re: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-rfc6810-bis-08.txt

Rob Austein <> Sat, 07 January 2017 23:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 63068129684 for <>; Sat, 7 Jan 2017 15:51:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.1
X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id thQ0vg0ODqWL for <>; Sat, 7 Jan 2017 15:51:12 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 019FE129687 for <>; Sat, 7 Jan 2017 15:51:11 -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 A8E8739811 for <>; Sat, 7 Jan 2017 23:51:10 +0000 (UTC)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id A11784608565 for <>; Sat, 7 Jan 2017 18:51:09 -0500 (EST)
Date: Sat, 07 Jan 2017 18:51:09 -0500
From: Rob Austein <>
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: <>
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-rfc6810-bis-08.txt
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: Sat, 07 Jan 2017 23:51:19 -0000

With apologies to the WG and our AD for taking so ridiculously long
(deadlines on other projects, but that's no excuse), we have finally
uploaded an updated I-D which we hope deals with most (all?) of the
issues that came up during AD review, as well as a few minor
clarifications and wording tweaks.  No protocol changes, just (we
hope) better description of the protocol.

The one important change here in terms of IETF standardization is that
we've dropped the notion that this document should obsolete RFC 6810.
While Alvaro kindly offered to help us find a twisty path which would
let us write a single document which would both deprecate RFC 6810
(protocol version zero) and also specifying how to downgrade from
version one to version zero, on reflection the authors agreed that
this is not worth the procedural headache.