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

Stephen Kent <kent@bbn.com> Fri, 04 November 2011 09:02 UTC

Return-Path: <kent@bbn.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 D69BA21F8C1E for <sidr@ietfa.amsl.com>; Fri, 4 Nov 2011 02:02:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.503
X-Spam-Level:
X-Spam-Status: No, score=-106.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 vjlrB7txMf9Q for <sidr@ietfa.amsl.com>; Fri, 4 Nov 2011 02:02:49 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id DED2221F8BFB for <sidr@ietf.org>; Fri, 4 Nov 2011 02:02:48 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:56623 helo=[193.0.26.186]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1RMFfj-0008rK-6h; Fri, 04 Nov 2011 05:02:47 -0400
Mime-Version: 1.0
Message-Id: <p06240805cad956d57fa4@[193.0.26.186]>
In-Reply-To: <CAD973A8.1E7DD%terry.manderson@icann.org>
References: <CAD973A8.1E7DD%terry.manderson@icann.org>
Date: Fri, 4 Nov 2011 04:56:51 -0400
To: Terry Manderson <terry.manderson@icann.org>
From: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
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: Fri, 04 Nov 2011 09:02:49 -0000

At 5:49 PM -0700 11/3/11, Terry Manderson wrote:
>On 2/11/11 6:34 PM, "Stephen Kent" <kent@bbn.com> 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
>space.

One of the initial set of SIDR RFCs is draft-ietf-sidr-rpki-algs. The 
new alg suite will be defined in a new version of that doc. I 
envisioned that this doc would also be the place where the milestones 
will be published.  But, a BCP specifying the milestones seems 
reasonable as well.

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

I think the BCP idea is appropriate.  I don't agree with your gray 
area argument. Let's avoid terms like "desperate."

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

let's just say we disagree, modulo the idea of putting the milestones in
a BCP.

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

In principle the RIRs & IANA, perhaps the NRO & IANA, would be an 
appropriate group to issue such a statement. So far, this process has 
been rocky, which is probably why there is an IAB-issused statement 
re IANA as a global TA for the RPKI. Nonetheless, this might be a 
reasonable split of responsibility, i.e., alg spec through the IETF 
process, and milestone publication via an RFC authored by the NRO and 
IANA.

Steve