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

Eric Osterweil <eosterweil@verisign.com> Fri, 04 November 2011 14:24 UTC

Return-Path: <eosterweil@verisign.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 5FF2121F8B8E for <sidr@ietfa.amsl.com>; Fri, 4 Nov 2011 07:24:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 hIbfq5KqRICG for <sidr@ietfa.amsl.com>; Fri, 4 Nov 2011 07:24:45 -0700 (PDT)
Received: from exprod6og109.obsmtp.com (exprod6og109.obsmtp.com [64.18.1.23]) by ietfa.amsl.com (Postfix) with ESMTP id A20F921F8AD8 for <sidr@ietf.org>; Fri, 4 Nov 2011 07:24:19 -0700 (PDT)
Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP; Fri, 04 Nov 2011 07:24:45 PDT
Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id pA4EOFh6020489; Fri, 4 Nov 2011 10:24:15 -0400
Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.131.30.68]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Nov 2011 10:24:14 -0400
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Eric Osterweil <eosterweil@verisign.com>
In-Reply-To: <p06240803cad951813fd9@[193.0.26.186]>
Date: Fri, 04 Nov 2011 10:24:14 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <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]>
To: Stephen Kent <kent@bbn.com>
X-Mailer: Apple Mail (2.1084)
X-OriginalArrivalTime: 04 Nov 2011 14:24:14.0741 (UTC) FILETIME=[6DDB8C50:01CC9AFD]
Cc: "draft-ietf-sidr-algorithm-agility@tools.ietf.org" <draft-ietf-sidr-algorithm-agility@tools.ietf.org>, "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: Fri, 04 Nov 2011 14:24:46 -0000

Hey Steve,

On Nov 4, 2011, at 4:45 AM, Stephen Kent wrote:

> Eric,
> 
> 1- Yes, there is a need for global coordination for alg transition, under the design  presented. If you have an alternative proposal, please share it. This design was originally documented in June, 2010, in an individual I-D authored by me.  It has been briefed at several SIDR WG meetings, starting at IETF 78 in July, 2010. This is not new.

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

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.

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

Eric