Hi Mirja, On Fri, Aug 19, 2016 at 2:54 PM, Mirja Kuehlewind (IETF) < [email protected]> wrote:
> 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. It needs to progress on its own. Thanks, Alia > 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
