Re: [sidr] I-D Action: draft-ietf-sidr-algorithm-agility-01.txt

Sandra Murphy <Sandra.Murphy@sparta.com> Mon, 11 July 2011 21:29 UTC

Return-Path: <Sandra.Murphy@cobham.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 E101121F8F55 for <sidr@ietfa.amsl.com>; Mon, 11 Jul 2011 14:29:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.891
X-Spam-Level:
X-Spam-Status: No, score=-100.891 tagged_above=-999 required=5 tests=[AWL=1.708, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-2tUPy0qoFT for <sidr@ietfa.amsl.com>; Mon, 11 Jul 2011 14:29:58 -0700 (PDT)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7153121F8EB4 for <sidr@ietf.org>; Mon, 11 Jul 2011 14:29:57 -0700 (PDT)
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p6BLTpqj009875; Mon, 11 Jul 2011 16:29:51 -0500
Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p6BLToMe013673; Mon, 11 Jul 2011 16:29:51 -0500
Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.116]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Jul 2011 17:29:50 -0400
Date: Mon, 11 Jul 2011 17:29:49 -0400
From: Sandra Murphy <Sandra.Murphy@sparta.com>
To: Stephen Kent <kent@bbn.com>
In-Reply-To: <p06240808ca40f463bf6d@[128.89.89.24]>
Message-ID: <Pine.WNT.4.64.1107111645070.5584@SMURPHY-LT.columbia.ads.sparta.com>
References: <20110708161252.27961.972.idtracker@ietfa.amsl.com> <42FAFCD2-C5F0-471C-8E90-A6AF0EC17DE6@cisco.com> <AAA28269-7DC5-4E19-A05B-6FAA4DF01388@cisco.com> <p06240800ca40dd314fe7@[192.168.1.10]> <Pine.WNT.4.64.1107111340180.3744@SMURPHY-LT.columbia.ads.sparta.com> <p06240808ca40f463bf6d@[128.89.89.24]>
X-X-Sender: sandy@mailbin.sparta.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-OriginalArrivalTime: 11 Jul 2011 21:29:50.0150 (UTC) FILETIME=[AA3ABE60:01CC4011]
Cc: "sidr@ietf.org wg" <sidr@ietf.org>
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-algorithm-agility-01.txt
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: Mon, 11 Jul 2011 21:29:59 -0000

On Mon, 11 Jul 2011, Stephen Kent wrote:

> At 1:44 PM -0400 7/11/11, Sandra Murphy wrote:
>>>> ...
>>> 
>>> Agreed. The CP cites the alg spec (draft-ietf-sidr-rpki-algs). However, 
>>> this doc say that the alg specs doc will be updated to reflect the new alg 
>>> suite, and to include the timeline for the alg transition. Once that 
>>> happens, a failure to comply with the alg transition procedure described 
>>> here will imply noncompliance with the CP.
>> 
>> S---T---R---E---T---C---H???
>> 
>> If the non-compliance with this draft was to fail to update the algs 
>> document, then the failure to comply with the procedure would not imply 
>> non-compliance with the CP.
>> 
>> --Sandy, speaking as wg chair
>
> Sandy,
>
> But stretching is the usual pre-exercise warm up, and the transition to a
> new alg suite will be an exercise, so ... :-).
>

Yes, especially when the exercise involves significant muscle movement, 
and alg transition involves significant movement of the brain muscle, 
so...  :-)

> Stated less circuitously, the CP currently mandates support for the algs
> in the Alg Spec. These algs used to be in the CP, but it was decided to
> move them into a separate doc, to avoid the need ti change the CP when the
> algs change. An early version of the alg transition doc called for updating
> the CP to reflect alg transition. But, we moved the algs spec to a separate
> doc, so the alg transition now cals for the alg spec to be replaced with
> a new doc that calls out the new algs and provides the transition timeline.
>
> We have gone down the path of document modularization and indirection, this 
> is where we wound up!

I understand the reasoning (I can stretch that far).

But the desired outcome is for any violation of the transition procedure 
to violate the CP.  Right?

As you said, this follows from the first step of the procedure, which is 
to update the alg document with the transition timeline, thereby 
indirectly updating the CP with the transition.  Subsequent violation of 
the transition procedure would therefore violate the CP.

But if the violation of the transition procedure is to fall at the first 
hurdle - to fail to update the alg document with the transition timeline, 
then any subsequent violation of the procedure would no longer violate the 
CP, even indirectly.

Right?

--Sandy, speaking as wg chair.


>
> Steve
>