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

Eric Osterweil <eosterweil@verisign.com> Thu, 03 November 2011 20:06 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 96E811F0C56 for <sidr@ietfa.amsl.com>; Thu, 3 Nov 2011 13:06:56 -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=[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 8RSkR9xi5Yqc for <sidr@ietfa.amsl.com>; Thu, 3 Nov 2011 13:06:56 -0700 (PDT)
Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) by ietfa.amsl.com (Postfix) with ESMTP id 75C811F0C35 for <sidr@ietf.org>; Thu, 3 Nov 2011 13:06:17 -0700 (PDT)
Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP; Thu, 03 Nov 2011 13:06:55 PDT
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id pA3K67id010757; Thu, 3 Nov 2011 16:06:07 -0400
Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.131.30.68]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Nov 2011 16:06:07 -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: <p06240803cad6af1b0ce7@[193.0.26.186]>
Date: Thu, 3 Nov 2011 16:06:07 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <7B40776F-D906-46DA-A788-C4E9C0E758A9@verisign.com>
References: <CAD6DA02.1C611%terry.manderson@icann.org> <p06240803cad6af1b0ce7@[193.0.26.186]>
To: Stephen Kent <kent@bbn.com>
X-Mailer: Apple Mail (2.1084)
X-OriginalArrivalTime: 03 Nov 2011 20:06:07.0335 (UTC) FILETIME=[05E73F70:01CC9A64]
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: Thu, 03 Nov 2011 20:06:56 -0000

On Nov 2, 2011, at 4:34 AM, Stephen Kent wrote:

> At 6:29 PM -0700 11/1/11, Terry Manderson wrote:
>> On 31/10/11 11:59 PM, "Stephen Kent" <kent@bbn.com> wrote:
>> 
>> 
>>>> 
>>>> I understand why you want to, but don't come to the same conclusion as to
>>>> the mechanism.
>>>> 
>>>> Is that really the IETF's job?
>>> 
>>> SIDR was tasked by the SEc ADs to develop an alg transition architecture.
>>> The authors believe that uniform milestones are necessary as part of
>>> a credible plan.
>>> 
>> 
>> Architecture, yes. Structured approach, yes. To both of those I agree.
>> Having the IETF define the dates when algorithms shift. I am not convinced.
> 
> An architecture that ignores the need to have a global, uniform set of milestones for transition phases is incomplete.

Having a model that requires independent administrative entities (the CA operators here) in the Internet to obey a traffic cop sounds a little... hard to swallow (operationally).  I also remain quite unconvinced.  I think this indicates that there is a misalignment in the design, not a problem in the above question.

> 
>> >> Call me a dirty rotten cynic but I just don't see this operational aspect of
>> >> one or more running RPKI hierarchies as part of the IETF. Although you can
>>>> prove me wrong, and I'll concede to an already enacted example where dates
>>>> were set for some artifact.
>>> 
>>> We have to have two, parallel hierarchies to avoid a flag day. This
>>> is not a situation where every CA can decide, locally, when to
>>> transition, because the the alg change affect ALL RPs.
>> 
>> We are talking years. The overlap will be significant. And I disagree - in
>> this case every CA has to consciously decide - there may well be a situation
>> that a mid term operational impact requires an important CA in the middle of
>> the chain to delay. That then renders all dates specified in any RFC next to
>> meaningless.
> 
> Yes, we are talking years. No, it cannot be a local, per-CA decision, because
> the transition affects all RPs. I anticipate that the stakeholders, CAs and RPs, will have the ability to comment on the proposed dates, and that the IETF/IESG will take into account these comments when developing the timeline. If a major problem arises that makes it infeasible for CAs to adhere t the timeline, a new RFC can be issued.

So, to make sure I understand: if operational issues arise that cause an independent administrative entity (one of the CA operators) to need to delay an operational action, they need to get an RFC published?  I must have misunderstood?

Eric