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:i...@kuehlewind.net] Sent: Friday, August 19, 2016 1:30 PM To: Susan Hares Cc: The IESG; jh...@pfrc.org; i2rs@ietf.org; i2rs-cha...@ietf.org; draft-ietf-i2rs-protocol-security-requireme...@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 <sha...@ndzh.com>: > > 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-boun...@ietf.org] On Behalf Of Mirja Kuehlewind > Sent: Wednesday, August 17, 2016 4:37 AM > To: The IESG > Cc: jh...@pfrc.org; i2rs@ietf.org; i2rs-cha...@ietf.org; > draft-ietf-i2rs-protocol-security-requireme...@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 > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
