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:[email protected]] On Behalf Of Mirja Kuehlewind Sent: Wednesday, August 17, 2016 4:37 AM To: The IESG Cc: [email protected]; [email protected]; [email protected]; [email protected] 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 [email protected] https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
