Re: [Gen-art] Gen-ART review of draft-ietf-i2rs-architecture-07
"Susan Hares" <shares@ndzh.com> Thu, 17 December 2015 02:16 UTC
Return-Path: <shares@ndzh.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 3E7AA1A0026; Wed, 16 Dec 2015 18:16:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.054
X-Spam-Level:
X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no
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 jbNr7tBsY65S; Wed, 16 Dec 2015 18:16:13 -0800 (PST)
Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37D071A000E; Wed, 16 Dec 2015 18:14:51 -0800 (PST)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.177;
From: Susan Hares <shares@ndzh.com>
To: 'Russ Housley' <housley@vigilsec.com>, draft-ietf-i2rs-architecture.all@ietf.org
References: <4F973679-69F7-476B-AA33-86F2F12E2E97@vigilsec.com>
In-Reply-To: <4F973679-69F7-476B-AA33-86F2F12E2E97@vigilsec.com>
Date: Wed, 16 Dec 2015 21:07:18 -0500
Message-ID: <067a01d1386f$a90dbc30$fb293490$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_067B_01D13845.C039B000"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQEJyu0tEp35d/7F7ksgfhYA0XbKCKBZfq0Q
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/i1YUMhTibctMLb7V0woX3abKXeA>
X-Mailman-Approved-At: Wed, 16 Dec 2015 18:28:55 -0800
Cc: 'IETF Gen-ART' <gen-art@ietf.org>, "'BRUNGARD, DEBORAH A'" <db3546@att.com>
Subject: Re: [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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 17 Dec 2015 02:16:23 -0000
Russ: I am following up on your GEN-ART review Last January. It has taken us a year to make sure we handled the security issues raised by the sec-dir review. We created two new requirements documents focused on security: http://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requiremen ts/ http://datatracker.ietf.org/doc/draft-ietf-i2rs-security-environment-reqs/ In addition to our security requirements, we defined requirements for the protocol regarding publication of notification streams, ephemeral state, and logging/traceability. http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ http://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ Please review this with the following I2RS requirement documents, and this improved architecture document. All documents except the I2RS protocol security environment and the draft-ietf-i2rs-ephemeral state have passed WG LC. The ephemeral state simply needs to indicate what NETCONF minimum features need to be implemented. These minimum NETCONF features for I2RS will be described in detail in a protocol-strawman (which is still to be published). See my answer to your specific the comments inline below. Thank you for your patience, but we wanted to provide the security documents. Sue -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com] Sent: Monday, December 15, 2014 7:02 PM To: draft-ietf-i2rs-architecture.all@ietf.org Cc: IETF Gen-ART Subject: Gen-ART review of draft-ietf-i2rs-architecture-07 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> 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. Sue: Version-11 No mention of groups is made outside of the section 2. The only mention of groups is in this text: Groups: NETCONF Network Access [RFC6536] refers uses the term group in terms of an Administrative group which supports support the well-established distinction between a root account and other types of less-privileged conceptual user accounts. Group still refers to a single identity (e.g. root) which is shared by a group of users. 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." The updated text in version 11 has the following text: Sue: A routing element need not implement all routing components described nor provide the associated I2RS services. I2RS Services 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. Sue: All identity work is in section 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. Version 11: Only confidentiality is used 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. Sue: The following is the sentence in version-11 In addition it must be noted that there may be indirect interactions between write operations. A basic example of this is when two different but overlapping prefixes are written with different forwarding behavior. Detection and avoidance of such interactions is outside the scope of the I2RS work and is left to agent design and implementation. Is this sufficient? 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. Sue: "accounting" has been removed. Section 6.2 now states the following: Meaningful logging of the application and removal of changes is recommended The I2RS has a "traceability requirements" draft that provides the details on logging of things that change in the I2RS Agent. Please let me know if you feel the current version of I2RS architecture has a valid 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 ..." Sue: This I2RS architecture assumes that there is a single I2RS protocol for control and data exchange comprised of IETF protocols or expansions of IETF existing protocols to support the I2RS architecture. Two the protocols to be expanded to support the I2RS protocol are NETCONF [RFC6241] and RESTCONF [draft-ietf-netconf-restconf]. This helps meet the goal of simplicity and thereby enhances deployability. 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 ...". Sue: Change made in version 8 In section 1, is says: "... in domain other than routing, ...". s/domain/domains/ Change made in Sue: Change made in version 8 Typo: s/E.g./e.g./ Change made in version 8
- [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