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

["Susan Hares" <[e-mail]>]

Mirja: 

Thank you for your input.  I believe version-08.txt resolves all your comments, and I have answered your questions in another email.

Sue 



-----Original Message-----
From: Mirja Kuehlewind (IETF) [mailto:[e-mail]] 
Sent: Friday, August 19, 2016 1:30 PM
To: Susan Hares
Cc: The IESG; [e-mail]; [e-mail]; [e-mail]; [e-mail]
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 <[e-mail]>:
> 
> 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:[e-mail]] On Behalf Of Mirja Kuehlewind
> Sent: Wednesday, August 17, 2016 4:37 AM
> To: The IESG
> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
> 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).

> 
> 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.

> 
> 
> 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.

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.
  
> 
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2rs
>