Re: [sidr] I-D Action: draft-ietf-sidr-algorithm-agility-01.txt
Stephen Kent <kent@bbn.com> Mon, 11 July 2011 17:27 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 E170321F8DAF for <sidr@ietfa.amsl.com>; Mon, 11 Jul 2011 10:27:14 -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 iwFlLHnTDlkl for <sidr@ietfa.amsl.com>; Mon, 11 Jul 2011 10:27:14 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id CD50611E8086 for <sidr@ietf.org>; Mon, 11 Jul 2011 10:27:10 -0700 (PDT)
Received: from dhcp89-089-024.bbn.com ([128.89.89.24]:49196) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1QgKGD-0003WK-BI; Mon, 11 Jul 2011 13:27:10 -0400
Mime-Version: 1.0
Message-Id: <p06240800ca40dd314fe7@[192.168.1.10]>
In-Reply-To: <AAA28269-7DC5-4E19-A05B-6FAA4DF01388@cisco.com>
References: <20110708161252.27961.972.idtracker@ietfa.amsl.com> <42FAFCD2-C5F0-471C-8E90-A6AF0EC17DE6@cisco.com> <AAA28269-7DC5-4E19-A05B-6FAA4DF01388@cisco.com>
Date: Mon, 11 Jul 2011 13:17:22 -0400
To: Brian Weis <bew@cisco.com>
From: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
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 17:27:15 -0000
At 12:08 PM -0700 7/8/11, Brian Weis wrote: >Hi Roque, > >This draft seems very complete. I have just a few questions and comments: > >1. Section 2. "A failure to comply with this process during an >algorithm transition MUST be considered as non-compliance with ... >I-D.ietf-sidr-cp". I can't detect in the CP where failing to comply >with this process would be result in non-compliance. It would be >hopeful to more specific here. 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. >2. Section 3. The definition of a "Non-Leaf CA" is "A CA that issues >certificates to entities not under its administrative control." I >believe this effectively means "CAs that have children", and if >that's the intended meaning perhaps that's a better statement. The >present definition could apply to a CA cross-certifying another CA >and other non-child certificate signing. Even if those situations >don't expect to be possible within the RPKI, it would be helpful to >clarify the definition. Also, it's not clear to me that a child CA >is "under its administrative control" in the sense that the child CA >(e.g., ISP) might not be administered by the parent (e.g., RIR). There is no cross-certification (in the common, but incorrect, use of the term) in the RPKI, because of the constraints imposed by the 3779 extensions. Still, I agree that the definition could be improved. How about: Non-leaf CA: A CA that issues certs to other CAs in a non-leaf CA. In contrast, a leaf CA is a CA that issues only EE certs. >... > > >5. Section 4.5. "During this phase all signed product sets MUST be >available using both Algorithm Suite A and Algorithm Suite B." It >isn't clear to me what "During this phase" means in Phase 2. Does it >mean "By the end of this phase"? Or does it mean "Before the start >of Phase 3", which is not the same moment in time according to the >figures in Section 4.2. I'm inclined to think it means "Before the >start of Phase 3", because by Phase 3 "all product sets are >available". Although again, Section 4.6 uses the phrase "During this >phrase" so that also isn't clear and I would recommend being more >precise here too. Yes, it would be more accurate to say "at the start of Phase 2, all signed products ..."
- [sidr] I-D Action: draft-ietf-sidr-algorithm-agil… internet-drafts
- Re: [sidr] I-D Action: draft-ietf-sidr-algorithm-… Roque Gagliano
- Re: [sidr] I-D Action: draft-ietf-sidr-algorithm-… Brian Weis
- Re: [sidr] I-D Action: draft-ietf-sidr-algorithm-… Roque Gagliano
- Re: [sidr] I-D Action: draft-ietf-sidr-algorithm-… Sandra Murphy
- Re: [sidr] I-D Action: draft-ietf-sidr-algorithm-… Brian Weis
- Re: [sidr] I-D Action: draft-ietf-sidr-algorithm-… Roque Gagliano
- Re: [sidr] I-D Action: draft-ietf-sidr-algorithm-… Roque Gagliano
- Re: [sidr] I-D Action: draft-ietf-sidr-algorithm-… Stephen Kent
- Re: [sidr] I-D Action: draft-ietf-sidr-algorithm-… Sandra Murphy
- Re: [sidr] I-D Action: draft-ietf-sidr-algorithm-… Stephen Kent
- Re: [sidr] I-D Action: draft-ietf-sidr-algorithm-… Brian Weis
- Re: [sidr] I-D Action: draft-ietf-sidr-algorithm-… Stephen Kent
- Re: [sidr] I-D Action: draft-ietf-sidr-algorithm-… Sandra Murphy
- Re: [sidr] I-D Action: draft-ietf-sidr-algorithm-… Stephen Kent