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 <[email protected]>: > > 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:[email protected]] > Sent: Friday, August 19, 2016 1:30 PM > To: Susan Hares > Cc: The IESG; [email protected]; [email protected]; [email protected]; > [email protected] > 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 <[email protected]>: >> >> 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. > >> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/i2rs >> > > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
