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

Eric Osterweil <> Thu, 03 November 2011 20:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 96E811F0C56 for <>; Thu, 3 Nov 2011 13:06:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8RSkR9xi5Yqc for <>; Thu, 3 Nov 2011 13:06:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 75C811F0C35 for <>; Thu, 3 Nov 2011 13:06:17 -0700 (PDT)
Received: from ([]) (using TLSv1) by ([]) with SMTP; Thu, 03 Nov 2011 13:06:55 PDT
Received: from ( []) by (8.13.6/8.13.4) with ESMTP id pA3K67id010757; Thu, 3 Nov 2011 16:06:07 -0400
Received: from ([]) by 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 <>
In-Reply-To: <p06240803cad6af1b0ce7@[]>
Date: Thu, 03 Nov 2011 16:06:07 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <p06240803cad6af1b0ce7@[]>
To: Stephen Kent <>
X-Mailer: Apple Mail (2.1084)
X-OriginalArrivalTime: 03 Nov 2011 20:06:07.0335 (UTC) FILETIME=[05E73F70:01CC9A64]
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: 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" <> 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?