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

Stephen Kent <> Wed, 02 November 2011 08:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EDC3311E810F for <>; Wed, 2 Nov 2011 01:53:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.417
X-Spam-Status: No, score=-106.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RsII+218wEgJ for <>; Wed, 2 Nov 2011 01:53:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7D36F11E810B for <>; Wed, 2 Nov 2011 01:53:33 -0700 (PDT)
Received: from ([]:58894 helo=[]) by with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <>) id 1RLWZY-000HQj-4k; Wed, 02 Nov 2011 04:53:24 -0400
Mime-Version: 1.0
Message-Id: <p06240803cad6af1b0ce7@[]>
In-Reply-To: <>
References: <>
Date: Wed, 02 Nov 2011 04:34:45 -0400
To: Terry Manderson <>
From: Stephen Kent <>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
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 08:53:35 -0000

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.

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

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.

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

See comments above re setting and revising the timeline.

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

I disagree. Because an alg transition does impact all RPs, there is a 
big difference.

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

So, who do you propose as alternates? Your comment above about 
parent(s) and "non-leaf" CAs issuing a statement encompasses IANA, 
the RIRs, and thousands of ISPs.  When has that set of players issued 
a statement analogous to this?