Re: [sidr] WGLC for draft-ietf-sidr-bgpsec-protocol-05

Stephen Kent <kent@bbn.com> Fri, 28 September 2012 13:54 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 3B5CB21F85A2 for <sidr@ietfa.amsl.com>; Fri, 28 Sep 2012 06:54:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 ghpouESNZ0y1 for <sidr@ietfa.amsl.com>; Fri, 28 Sep 2012 06:54:06 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id A080021F859A for <sidr@ietf.org>; Fri, 28 Sep 2012 06:54:06 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:33449 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1THb0z-000DJc-Jb; Fri, 28 Sep 2012 09:54:01 -0400
Message-ID: <5065ABF9.6050303@bbn.com>
Date: Fri, 28 Sep 2012 09:54:01 -0400
From: Stephen Kent <kent@bbn.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Rob Austein <sra@hactrn.net>, sidr <sidr@ietf.org>
References: <24B20D14B2CD29478C8D5D6E9CBB29F625F706AF@CMA-MB003.columbia.ads.sparta.com> <20120927165848.2BECA7DC673@minas-ithil.hactrn.net>
In-Reply-To: <20120927165848.2BECA7DC673@minas-ithil.hactrn.net>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [sidr] WGLC for draft-ietf-sidr-bgpsec-protocol-05
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, 28 Sep 2012 13:54:07 -0000

Rob,

A reply to a couple of your comments:

>
>>   4.1.  Originating a New BGPSEC Update
> ...
>>      In particular, this AS number MUST match the AS number in
>>      the AS number resource extension field of the Resource PKI end-entity
>>      certificate(s) that will be used to verify the digital signature(s)
>>      constructed by this BGPSEC speaker.
> "The" or "an"?   Is it legal for the EE certificate to cover more RFC
> 3779 resources than just a single ASN?
yes, an EE cert can contain multiple ASNs, if they were allocated to the
cert holder by the same parent.
>
>>   6.1.  Algorithm Suite Considerations
> ...
>>      To this end, a mandatory algorithm suites document will be created
>>      which specifies a mandatory-to-use 'current' algorithm suite for use
>>      by all BGPSEC speakers [12].  Additionally, the document specifies an
>>      additional 'new' algorithm suite that is recommended to implement.
> Badly phrased, unless the real intent here is to say that we're going
> to pick both the current and next algorithms right off the bat, which
> seems unlikely to me.   I think it would be more correct to say that
> we will specify an initial mandatory algorithm suite, and, once we
> have some idea of what the next algorithm should be, we will publish
> a series of updated documents phasing in the new one and (eventually,
> years later) phasing out the old one.
that would be consistent with the alg migration strategy described in
draft-ietf-sidr-algorithm-agility-07

Steve