[Gen-art] Gen-ART review of draft-ietf-i2rs-architecture-07
Russ Housley <housley@vigilsec.com> Tue, 16 December 2014 00:02 UTC
Return-Path: <housley@vigilsec.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9381A8547; Mon, 15 Dec 2014 16:02:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7NXcy0Kpla5; Mon, 15 Dec 2014 16:02:54 -0800 (PST)
Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id CB9DA1A6FDA; Mon, 15 Dec 2014 16:02:53 -0800 (PST)
Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 4C2BE9A4003; Mon, 15 Dec 2014 19:02:43 -0500 (EST)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id vvAcO43TXBRY; Mon, 15 Dec 2014 19:02:22 -0500 (EST)
Received: from [192.168.2.108] (pool-96-255-26-251.washdc.fios.verizon.net [96.255.26.251]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 183A19A4001; Mon, 15 Dec 2014 19:02:22 -0500 (EST)
From: Russ Housley <housley@vigilsec.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Date: Mon, 15 Dec 2014 19:02:10 -0500
Message-Id: <4F973679-69F7-476B-AA33-86F2F12E2E97@vigilsec.com>
To: draft-ietf-i2rs-architecture.all@ietf.org
Mime-Version: 1.0 (Apple Message framework v1085)
X-Mailer: Apple Mail (2.1085)
Archived-At: http://mailarchive.ietf.org/arch/msg/gen-art/mHM4e0K2bEq8LTB0nsnT80wI1xY
Cc: IETF Gen-ART <gen-art@ietf.org>
Subject: [Gen-art] Gen-ART review of draft-ietf-i2rs-architecture-07
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Dec 2014 00:02:56 -0000
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. This review is in response to a request for early Gen-ART review. Document: draft-ietf-i2rs-architecture-07 Reviewer: Russ Housley Review Date: 2014-12-15 IETF LC End Date: unknown IESG Telechat date: unknown Summary: Almost Ready. Major Concerns: The different between an identity and a role is not clear to me. Does each identity have exactly one role? It would help for this to be covered in section 2, and it may need to be expanded upon in section 4. Section 4.2 talks about "groups or roles." Groups needs to be defined, even if it is just a list of identities. Section 6.4 include a sentence that begins, "When a full implementation is not mandatory, an I2RS Service should ..." What determines if an implementation must be "full"? I think you can make this point without having to delve into this question. I suggest: "When a implementation does offer all of the capabilities specified for an I2RS Service, the implementation should include a capability model so that peers can determine which parts of the service are supported." Section 7.4 says: "Each I2RS Client will have a unique identity; it can also have secondary identities to be used for troubleshooting." The definition in in section 2 offer a proxy-related reason for secondary identities. Perhaps all of the discussion of identities can be placed in one section. Right now it is split into sections 4 and 7.4. Minor Concerns: The document seems to use "confidentiality" and "privacy" to mean the same thing. They are different. See RFC 2828 for definitions. I think that this document should use confidentiality throughout. The last paragraph in section 1.2 says that the "detection and avoidance of such interactions is outside the scope of the I2RS work," and that seems fine, except for one point. I assume that when there are two overlapping write operations, one of them will get an error. The previous paragraph says that "errors should produce predictable behaviors." So, the write operation that fails needs to get an error that will allow the application to take appropriate action. In section 4.1, is the reference to "accounting" also a call for audit trail? If so, please be explicit. The need for audit log comes up later in section 6.2. Section 7.1 begins: "As agreed by the I2RS working group, this I2RS architecture assumes ..." I am sure this was important at one time to say this, but it seems odd in the final RFC. I suggest: "The I2RS architecture assumes ..." Other Comments: In the abstract, please spell out I2RS. Several places starting in the Abstract: s/internet/Internet/ In section 1, it says: "... for registering for and requesting ..."; it should say: "... for registering and for requesting ...". In section 1, is says: "... in domain other than routing, ...". s/domain/domains/ Typo: s/E.g./e.g./
- [Gen-art] Gen-ART review of draft-ietf-i2rs-archi… Russ Housley
- Re: [Gen-art] Gen-ART review of draft-ietf-i2rs-a… Susan Hares
- Re: [Gen-art] Gen-ART review of draft-ietf-i2rs-a… Susan Hares