Re: [i2rs] Mirja Kühlewind's No Objection on draft-ietf-i2rs-protocol-security-requirements-06: (with COMMENT)

"Susan Hares" <shares@ndzh.com> Thu, 18 August 2016 00:17 UTC

Return-Path: <shares@ndzh.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAF0B12B03F; Wed, 17 Aug 2016 17:17:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.738
X-Spam-Level: *
X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no autolearn_force=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 LXuLTuqA0fb8; Wed, 17 Aug 2016 17:17:10 -0700 (PDT)
Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D05712B007; Wed, 17 Aug 2016 17:17:09 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.169.225;
From: "Susan Hares" <shares@ndzh.com>
To: "'Mirja Kuehlewind'" <ietf@kuehlewind.net>, "'The IESG'" <iesg@ietf.org>
References: <147142304704.12189.4149817417200297360.idtracker@ietfa.amsl.com>
In-Reply-To: <147142304704.12189.4149817417200297360.idtracker@ietfa.amsl.com>
Date: Wed, 17 Aug 2016 20:15:58 -0400
Message-ID: <00c001d1f8e5$b5d94790$218bd6b0$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQI+ckvMtsLj2hKLR4cahhlPTc8O8Z904frw
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/ba_w8irxqXCSOxYZy5aFL_IGN2c>
Cc: jhaas@pfrc.org, i2rs@ietf.org, i2rs-chairs@ietf.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org
Subject: Re: [i2rs] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-i2rs-protocol-security-requirements-06=3A_=28with_COMMENT?= =?utf-8?q?=29?=
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Aug 2016 00:17:12 -0000

Mirja: 

Thank you for the review.  Please see the comments below.    Your comments are sensible, but the sections were put in place to provide background for the multiple working groups utilizing these requirements.  Please let me know if I can answer additional questions. 

 Sue Hares 

-----Original Message-----
From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Mirja Kuehlewind
Sent: Wednesday, August 17, 2016 4:37 AM
To: The IESG
Cc: jhaas@pfrc.org; i2rs@ietf.org; i2rs-chairs@ietf.org; draft-ietf-i2rs-protocol-security-requirements@ietf.org
Subject: [i2rs] Mirja Kühlewind's No Objection on draft-ietf-i2rs-protocol-security-requirements-06: (with COMMENT)

Mirja Kühlewind has entered the following ballot position for
draft-ietf-i2rs-protocol-security-requirements-06: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

A few comments:

1) I don't think copy&paste from RFC4949 is necessary. I would recommend to remove this part and just name the definitions that are needed.

Sue: Initially, the WG and the authors ran into problems with security words.  We included definitions that seem to resolve issues for the WG and those who will need to implemented in NETCONF/RESTCONF.   

2) The following sentence seems to indicate that the refernce to RFC4949 should be normative.
"The transfer of data via the I2RS protocol has the property of data integrity described in [RFC4949]."
As I don't think this is needed, I would recommend to rather spell out the properties here in this sentence. Also, to be honstest I not sure what this sentence tells me at all. So maybe stating clearing what you mean (instead of just having the reference) would help anyway.


Sue: I have moved RFC4949 to normative.   RFC4949 states data integrity means: a) data has not been changed, destroyed or lost in an unauthorized (or accidental) manner,  and b) the information has not been modified or destroyed in an unauthorized manner.   This statement covers man-in-the middle attacks or unauthorized changes.  
 

3) To me it's not really clear why there are several requirments docs (that also are connected and refer each other; see e.g. section 3.6 and SEC-REQ-16). The actually context of this doc is only 4 pages (3.1-3.6). Couldn't those docs be combined to one requirements doc?

Sue: This is a good process question for a re-use protocol.   A re-use protocol has a different process than a protocol created out of a single WG. 

I2RS broke the requirements into pieces so that as we got agreement on one piece, the NETCONF/RESTCONF team could begin to work on that piece.  For example, the pub/sub requirements (RFC7923) is already being worked on in NETCONF.  The I2RS ephemeral state requirements have been delayed by the NETMOD/NETCONF discussions on opstate.  If the IESG wishes, after we have completed this work, we can compile these requirements into a single document.    This process focuses on running code and rough consensus rather than a single review process for the IESG. 

4) Section 3.1 says:
"The I2RS architecture [I-D.ietf-i2rs-architecture] sets the following requirements:"
Why is this needed is RFC7921 already sets these requirements?

Sue:  What a logical and rational statement, but unfortunately this assumption ran into problems in the working groups (NETMOD/NETCONF) who reviewed the requirements.  Therefore, this section is there to provide explicit definitions that resolved inter-group (I2RS to NETCONF and I2RS to NETMOD) questions on lists. 

_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs