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

Terry Manderson <> Fri, 04 November 2011 00:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3F0D211E80C2 for <>; Thu, 3 Nov 2011 17:49:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.579
X-Spam-Status: No, score=-106.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aJdaVZdVAHWZ for <>; Thu, 3 Nov 2011 17:49:14 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CAFB611E80BF for <>; Thu, 3 Nov 2011 17:49:14 -0700 (PDT)
Received: from ([]) by ([]) with mapi; Thu, 3 Nov 2011 17:49:14 -0700
From: Terry Manderson <>
To: Stephen Kent <>
Date: Thu, 03 Nov 2011 17:49:12 -0700
Thread-Topic: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03
Thread-Index: AcyZPPQVh/LIpqbdTca8uS+/+fMmRgBTp15e
Message-ID: <>
In-Reply-To: <p06240803cad6af1b0ce7@[]>
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: Fri, 04 Nov 2011 00:49:15 -0000

On 2/11/11 6:34 PM, "Stephen Kent" <> wrote:

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

I appreciate your view Steve. And in the traditional sense you are correct,
unfortunately I think that level of completion, as a standards document,
will be the 'enemy of the good' as that flips right over into operational

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

If you are that desperate to see this in play, then perhaps SIDR should
consider creating an operational BCP that provides the recommendation for
algorithms phase-in/phase-out dates. And in that comes the warning, that
IETF specified dates (except for past events) are in a very grey area WRT
the IETF.

But neither this document (in blessing the idea) nor
draft-ietf-sidr-rpki-algs (as standards track) is the place for it.

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

Surely the ISPs would be represented by or through the RIRs?

I'm not an expert in communications between IANA/ICANN/RIRs but if they
needed to issue a statement based on stakeholder (RP) consultation for 'the
good of the internet', its likely they would.