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

"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> Fri, 19 August 2016 19:01 UTC

Return-Path: <ietf@kuehlewind.net>
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 59B1C12D9DF for <i2rs@ietfa.amsl.com>; Fri, 19 Aug 2016 12:01:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.149
X-Spam-Level:
X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 rJKx9hFO8I-t for <i2rs@ietfa.amsl.com>; Fri, 19 Aug 2016 12:01:37 -0700 (PDT)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9C0C12D803 for <i2rs@ietf.org>; Fri, 19 Aug 2016 12:01:29 -0700 (PDT)
Received: (qmail 19614 invoked from network); 19 Aug 2016 20:54:47 +0200
Received: from p5dec255c.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.37.92) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 19 Aug 2016 20:54:46 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
In-Reply-To: <013701d1fa45$b58980f0$209c82d0$@ndzh.com>
Date: Fri, 19 Aug 2016 20:54:45 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <33A86029-D3D3-4BD6-9B48-2273F2632673@kuehlewind.net>
References: <147142304704.12189.4149817417200297360.idtracker@ietfa.amsl.com> <00c001d1f8e5$b5d94790$218bd6b0$@ndzh.com> <D10CA079-8934-4FCB-8006-20ECB04D196D@kuehlewind.net> <013701d1fa45$b58980f0$209c82d0$@ndzh.com>
To: Susan Hares <shares@ndzh.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/0J8NKCr2uOfVhPRzRnQ6lrNhwHg>
Cc: jhaas@pfrc.org, i2rs@ietf.org, The IESG <iesg@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: Fri, 19 Aug 2016 19:01:39 -0000

Hi Sue,

thanks for addressing my comments! 

The only remaining one is if this doc should be published as an own RFC or merged with the other requirement documents. I mainly wanted to raise this point for discussion and will leave the decision to the responsible AD.

Mirja


> Am 19.08.2016 um 20:15 schrieb Susan Hares <shares@ndzh.com>om>:
> 
> Mirja: 
> 
> Thank you for your reply.  I have removed the text regarding RFC4949.  I believe version-08.txt resolves these comments. 
> 
> Sue 
> 
> -----Original Message-----
> From: Mirja Kuehlewind (IETF) [mailto:ietf@kuehlewind.net] 
> Sent: Friday, August 19, 2016 1:30 PM
> To: Susan Hares
> Cc: The IESG; jhaas@pfrc.org; i2rs@ietf.org; i2rs-chairs@ietf.org; draft-ietf-i2rs-protocol-security-requirements@ietf.org
> Subject: Re: [i2rs] Mirja Kühlewind's No Objection on draft-ietf-i2rs-protocol-security-requirements-06: (with COMMENT)
> 
> Hi Sue,
> 
> thanks for you replies and background information. Please see further below.
> 
> Mirja
> 
>> Am 18.08.2016 um 02:15 schrieb Susan Hares <shares@ndzh.com>om>:
>> 
>> 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.   
> 
>> I understand that this helped the writing process and discussion in the working group. However, I still advise to remove this from the final RFC given that readers can easily >check the referred RFC if needed and this avoids text duplications (which e.g. makes updates very hard).
> 
> Sue: I removed the RFC4949 cut and paste in version -08.txt.   Can I consider this item closed? 
> 
>>> 
>>> 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.  
> 
>> Okay. I would still recommend to spell this simply out in the draft instead of just giving the reference.
> 
> Sue: I removed this text. 
> 
>>> 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. 
> 
>> Thanks that's very useful background information. However, even though I’m happy to hear that this process worked well, the question for 
>> final publication in one or multiple RFCs is if there is a benefit for the final reading audience. 
>> Given that these docs are rather short so could be well structured in one RFC and have interdependencies I don’t see this benefit. 
>> I’d rather would assume that a reader would anyway need to look at multiple docs in any case which would suggest to have one doc.
> 
> This is a non-normative section: 
> 
> Perhaps I was unclear.  The final reading audience includes the following: NETCONF WG, NETMOD WG,  vendors, prototype implementers, and operators. 
> The final audience review begins as soon as you approve it.  The NETCONF/NETMOD WG will not consider it real until it is an RFC.   
> In a re-use protocol, we can begin work as soon as you approve the requirements. 
> 
>>> Given that these docs are rather short so could be well structured in one RFC and have interdependencies I don’t see this benefit. 
>>> I’d rather would assume that a reader would anyway need to look at multiple docs in any case which would suggest to have one doc.
> 
>> As you’ve been mention the IESG review process, I’d like to comment on this. There is some discussion in the IESG about how to treat different documents differently as they 
>> might need a different level of review (and consensus). However, from my perspective the main goal is to speed up the publication process. For me the workload is basically the > same no matter if I read 3 drafts with 15 pages each or 1 draft with 45 pages. So with respective to this discuss the question for me would rather be if this doc
>> must be published at RFC at all: Does a document provide valuable information for future readers or is it just a documentation of the wig’s working process? 
>> We in the IESG didn’t conclude this discussion and therefore I did not and am not intending to ask this question regarding this document.
> 
> This is a meta-question on IESG process.  And off-topic to the review of the document.  In your consider of the solution, I think you need to reconsider the re-use protocols as different than other protocols.  This document must be published as an RFC or we cannot get NETCONF/NETMOD WG to expand their protocols to include I2RS Features.   
> The Pub/SUB work in NETCONF/RESTCONF needs these requirements finalizer to make progress.  Fast approval of the requirements for a re-use protocol is critical to the WG trying to re-use a protocol.    
> 
>> 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
>> 
> 
>