[sidr] Fwd: New Version Notification for draft-ietf-sidr-algorithm-agility-04.txt

Roque Gagliano <rogaglia@cisco.com> Tue, 29 November 2011 17:15 UTC

Return-Path: <rogaglia@cisco.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 719281F0C72 for <sidr@ietfa.amsl.com>; Tue, 29 Nov 2011 09:15:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id YzUCZiG1c9-s for <sidr@ietfa.amsl.com>; Tue, 29 Nov 2011 09:15:06 -0800 (PST)
Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com []) by ietfa.amsl.com (Postfix) with ESMTP id 9CADD1F0C76 for <sidr@ietf.org>; Tue, 29 Nov 2011 09:15:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rogaglia@cisco.com; l=12732; q=dns/txt; s=iport; t=1322586905; x=1323796505; h=from:subject:date:references:to:message-id:mime-version; bh=oZ07PG7cbLjsyA809feZg14DpRRPmOf556DSXKHRqv8=; b=Y4CQAIZlPthrrxAKbLCNoQpHXXEkRuqlOW0kks0sdxAMYVSeg4eh/G0p VI/iCacX/mXwEAFp77ngnx1dN9A6KkYJh973G3oxUUMVZFHac09dVOs8P xmIQ0rmz8chCUzGuIDOhzagqrVjN++DgjltaC05wR5drG6pQuQN8TRwgb A=;
X-Files: smime.p7s : 4389
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAA4S1U6Q/khR/2dsb2JhbABDqnqBBYFyAQEBAwESAWQHCxwDAQIvAksCCAYTIodjmQMBnkyKO2MEjgmGS5IS
X-IronPort-AV: E=Sophos; i="4.69,592,1315180800"; d="p7s'?scan'208,217"; a="4008878"
Received: from ams-core-1.cisco.com ([]) by ams-iport-4.cisco.com with ESMTP; 29 Nov 2011 17:15:03 +0000
Received: from ams3-vpn-dhcp6503.cisco.com (ams3-vpn-dhcp6503.cisco.com []) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pATHF3vX003299 for <sidr@ietf.org>; Tue, 29 Nov 2011 17:15:03 GMT
From: Roque Gagliano <rogaglia@cisco.com>
Content-Type: multipart/signed; boundary="Apple-Mail-486-682318500"; protocol="application/pkcs7-signature"; micalg="sha1"
Date: Tue, 29 Nov 2011 18:14:56 +0100
References: <20111129171026.13083.85070.idtracker@ietfa.amsl.com>
To: sidr wg list <sidr@ietf.org>
Message-Id: <54B2A2BE-451F-4EF8-BE9A-11BA454B3712@cisco.com>
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [sidr] Fwd: New Version Notification for draft-ietf-sidr-algorithm-agility-04.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: Tue, 29 Nov 2011 17:15:07 -0000

Dear WG, 

We just submitted a new version of the agility draft, where we believe we addressed all the comments during WGLC.

	- Decoupling the documents to be updated in two, one signaling the algorithms and another one (BCP) with the specific dates.
	- Adding a roll-over mechanism for the process.
	- Several text improvements and editorial nits


Begin forwarded message:

> From: internet-drafts@ietf.org
> Date: November 29, 2011 6:10:26 PM GMT+01:00
> To: rogaglia@cisco.com
> Cc: turners@ieca.com, rogaglia@cisco.com, kent@bbn.com
> Subject: New Version Notification for draft-ietf-sidr-algorithm-agility-04.txt
> A new version of I-D, draft-ietf-sidr-algorithm-agility-04.txt has been successfully submitted by Roque Gagliano and posted to the IETF repository.
> Filename:	 draft-ietf-sidr-algorithm-agility
> Revision:	 04
> Title:		 Algorithm Agility Procedure for RPKI.
> Creation date:	 2011-11-29
> WG ID:		 sidr
> Number of pages: 29
> Abstract:
>   This document specifies the process that Certification Authorities
>   (CAs) and Relying Parties (RP) participating in the Resource Public
>   Key Infrastructure (RPKI) will need to follow to transition to a new
>   (and probably cryptographically stronger) algorithm set.  The process
>   is expected to be completed in a time scale of months or years.
>   Consequently, no emergency transition is specified.  The transition
>   procedure defined in this document supports only a top-down migration
>   (parent migrates before children).
> The IETF Secretariat