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

Stephen Kent <> Mon, 07 November 2011 23:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D197C1F0C45 for <>; Mon, 7 Nov 2011 15:38:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.416
X-Spam-Status: No, score=-106.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y5X0c4kifkqg for <>; Mon, 7 Nov 2011 15:38:43 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 5CE651F0C44 for <>; Mon, 7 Nov 2011 15:38:43 -0800 (PST)
Received: from ([]:49176) by with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <>) id 1RNYlu-0006cB-PM; Mon, 07 Nov 2011 18:38:34 -0500
Mime-Version: 1.0
Message-Id: <p06240811cade1873e723@[]>
In-Reply-To: <>
References: <> <p06240803cad6af1b0ce7@[]> <> <p06240803cad951813fd9@[]> <> <p06240802cadde494171b@[]> <>
Date: Mon, 07 Nov 2011 18:38:25 -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 23:38:43 -0000


I didn't miss your point; I just do not agree with it.  I was noting that
Terry suggested that a milestone doc ought to reflect input from the CAs and
RPs, and that the NRO and IANA are reasonable candidates for such 
input coordination.

You have said, repeatedly, that you feel that a global schedule for 
alg transition is a terrible idea.  You have explained why you 
believe so. I have grave doubts about the high level scenario that 
you have described. Your comments seem to ignore the fact that the 
transition plan incorporates phases precisely to enable CAs and RPs 
to verify that they have working code to deal with the new alg suite 
before the old one is turned off.  You postulate a major problem that 
precludes a transition to a new alg Suite (presumably for Phase 4), 
but that phase occurs only after CAs have been generating products 
and RPs have been consuming them for some time.

This is not a productive discussion.