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

Terry Manderson <> Wed, 02 November 2011 01:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B900A1F0C41 for <>; Tue, 1 Nov 2011 18:29:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.578
X-Spam-Status: No, score=-106.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qZOOtFL3QIJL for <>; Tue, 1 Nov 2011 18:29:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 43BC51F0C38 for <>; Tue, 1 Nov 2011 18:29:09 -0700 (PDT)
Received: from ([]) by ([]) with mapi; Tue, 1 Nov 2011 18:29:09 -0700
From: Terry Manderson <>
To: Stephen Kent <>
Date: Tue, 01 Nov 2011 18:29:06 -0700
Thread-Topic: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03
Thread-Index: AcyYhBKeawFgPH9ESIiti6BbibxnvgAer0IL
Message-ID: <>
In-Reply-To: <p06240801cad455872b85@[]>
Accept-Language: en-US
Content-Language: en
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Wed, 02 Nov 2011 01:29:09 -0000

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.

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

>> I'm still not with you on this - I understand that it makes life easy to say
>> "the IETF said 12/12/2018 is D-Day, get with it" .. ... buuuutt I see that
>> as a step beyond what the IETF should do.
> If not the IETF, then whom? The IETF (via SIDR) is the author of the
> CP. This is an extension of the CP, in many respects.

The IETF (via SIDR) doesn't implement the hierarchy, nor operate the CAs.

Perhaps the parent(s) and 'non-leaf' CAs should work on this and issue a
statement of transition in following RFCXXXX (this draft). I'm reasonably
sure the non-leaf CAs are capable of making noise when required ;)

As an example of flag day events, even though RFC5855 ( Nameservers for IPv4
and IPv6 Reverse Zones ) was published as an IETF document. It was left to
the various operators (root-servers, reverse-servers et al) to work on the
transition. Admittedly no change was required on the user's software. The
principle isn't that much different.

What I do like about the document is the pre-canned phases, of what happens
when, and how. This is good.. and I think that satisfies the request from
the SEC ADs, but specifying the "when" in IETF - I just don't buy.