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

Stephen Kent <kent@bbn.com> Mon, 07 November 2011 19:56 UTC

Return-Path: <kent@bbn.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E082821F853E for <sidr@ietfa.amsl.com>; Mon, 7 Nov 2011 11:56:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.355
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USA0OLiBzSRh for <sidr@ietfa.amsl.com>; Mon, 7 Nov 2011 11:56:47 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 538D821F8532 for <sidr@ietf.org>; Mon, 7 Nov 2011 11:56:47 -0800 (PST)
Received: from dhcp89-089-006.bbn.com ([128.89.89.6]:49163) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1RNVIr-000KpO-Gu; Mon, 07 Nov 2011 14:56:21 -0500
Mime-Version: 1.0
Message-Id: <p06240802cadde494171b@[128.89.89.6]>
In-Reply-To: <CB6FE413-BEC2-4910-AEEF-98D6EAFD4E83@verisign.com>
References: <CAD6DA02.1C611%terry.manderson@icann.org> <p06240803cad6af1b0ce7@[193.0.26.186]> <7B40776F-D906-46DA-A788-C4E9C0E758A9@verisign.com> <p06240803cad951813fd9@[193.0.26.186]> <CB6FE413-BEC2-4910-AEEF-98D6EAFD4E83@verisign.com>
Date: Mon, 7 Nov 2011 14:46:37 -0500
To: Eric Osterweil <eosterweil@verisign.com>
From: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: <http://www.ietf.org/mail-archive/web/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: 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 
forever.

>  > 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 
flexibility.

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
development.

Steve