Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03

Stephen Kent <> Mon, 07 November 2011 19:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E082821F853E for <>; Mon, 7 Nov 2011 11:56:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.355
X-Spam-Status: No, score=-106.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id USA0OLiBzSRh for <>; Mon, 7 Nov 2011 11:56:47 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 538D821F8532 for <>; Mon, 7 Nov 2011 11:56:47 -0800 (PST)
Received: from ([]:49163) by with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <>) id 1RNVIr-000KpO-Gu; Mon, 07 Nov 2011 14:56:21 -0500
Mime-Version: 1.0
Message-Id: <p06240802cadde494171b@[]>
In-Reply-To: <>
References: <> <p06240803cad6af1b0ce7@[]> <> <p06240803cad951813fd9@[]> <>
Date: Mon, 07 Nov 2011 14:46:37 -0500
To: Eric Osterweil <>
From: Stephen Kent <>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: "" <>
Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 07 Nov 2011 19:56:48 -0000

>I can appreciate that this document represents some long standing 
>thought and effort.  However, the fact that I believe there is a 
>flaw does not seem to need the support of an alternate design, 
>right?  I'm pointing out an operational misalignment in _this_ 
>design.  I think to offer an alternative at the same time as we are 
>discussing a shortcoming here would be an inappropriate conflation 
>(i.e. I think that would confuse this issue with another).

The authors do not agree that the global coordination requirement is a flaw.

>So, more specifically: I think that trying to mandate global 
>coordination at this scale is an operational non-starter.  Why can't 
>the design be made to accommodate different choices of algorithms 
>and different operational schedules?  I think this is actually a 
>requirement: that operational entities be able to choose their own 
>schedules and make their own configuration choices.

If there is not a schedule when old algs die and new ones MUST be 
supported, then one at least doubles the size of the repository 
system, and imposes a burden on all CAs and RPs to support old algs 

>  > 2- Not exactly. The milestones, as well as the alg suite spec, 
>will appear in a revised version of draft-ietf-sidr-rpki-algs. Any 
>operational problem that requires a delay in any transition phase 
>would be brought to the attention of the IESG (if the SIDR WG is no 
>longer active) requesting that a this RFC be re-issued, with new 
>milestone values for the affected phase(s).
>I'm sorry, but I really think this is likely to have trouble in a 
>real operational setting.  I don't think anyone would claim that the 
>IETF's processes operate at the same pace as operations.  For 
>instance, if there is an emergency at the last minute of this roll, 
>can the working group be expected to mint a new RFC and disseminate 
>in short order (say, days)?  There is a vey fundamental misalignment 
>here: creating standards and managing operations are very loosely 
>coupled.  I think this is a very inappropriate place to try to 
>enforce operational schedules.

I think you overstate the problem. The intervals for each phase are 
not expected to be short, and there are phases that accommodate both 
old and new als in a fashion that allows considerable CA and RP 

Nonetheless, I think Terry's suggestion has merit. I can imagine 
having the milestone RFC be coordinated through the NRO and IANA, and 
published by the IETF, to help ensure that there is appropriate ISP 
input to the milestone