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

From: "Mirja Kuehlewind" <[email-masked]>
Date: Wed, 17 Aug 2016 01:37:27 -0700

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.

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.

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 requiremnet doc?

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?

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 17 Aug 2016 20:15:58 -0400

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-masked]] On Behalf Of Mirja Kuehlewind
Sent: Wednesday, August 17, 2016 4:37 AM
To: The IESG
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [i2rs] Mirja Kühlewind's No Objection on draft-ietf-i2rs-protocol-security-requirements-06: (with COMMENT)

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

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

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Fri, 19 Aug 2016 19:30:12 +0200

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-masked]>:
> 
> Mirja: 
> 

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

Okay. I would still recommend to spell this simply out in the draft instead of just giving the reference.

> 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 al…

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.

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 19 Aug 2016 14:15:45 -0400

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-masked]] 
Sent: Friday, August 19, 2016 1:30 PM
To: Susan Hares
Cc: The IESG; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [i2rs] Mirja Kühlewind's No Objection on draft-ietf-i2rs-protocol-security-requirements-06: (with COMMENT)

Hi Sue,

Mirja

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

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

> 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-masked]

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 19 Aug 2016 14:17:45 -0400

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:[email-masked]] 
Sent: Friday, August 19, 2016 1:30 PM
To: Susan Hares
Cc: The IESG; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [i2rs] Mirja Kühlewind's No Objection on draft-ietf-i2rs-protocol-security-requirements-06: (with COMMENT)

Hi Sue,

Mirja

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Fri, 19 Aug 2016 20:54:45 +0200

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-masked]>:
> 
> Mirja: 
>

---

From: Alia Atlas <[email-masked]>
Date: Fri, 19 Aug 2016 16:02:37 -0400

Hi Mirja,
On Fri, Aug 19, 2016 at 2:54 PM, Mirja Kuehlewind (IETF) <
[email-masked]> wrote:

> 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

> > Thank you for your reply.  I have removed the text regarding RFC4949.  I
> believe version-08.txt resolves these comments.
> >
> > Sue
> >
> > Cc: The IESG; [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> > Subject: Re: [i2rs] Mirja Kühlewind's No Objection on
> draft-ietf-i2rs-protocol-security-requirements-06: (with COMMENT)
> >
> > Hi Sue,
> >
> >> 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
> >>
> >> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> >> Subject: [i2rs] Mirja Kühlewind's No Objection on
> draft-ietf-i2rs-protocol-security-requirements-06: (with COMMENT)
> >>
> >>> 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).
> >
> the properties here in this sentence. Also, to be honstest I not sure what
> this sentence tells me at all.
> >>> 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.
> >
> 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.
> >>> If the IESG wishes, after we have completed this work, we can compile
> these requirements into a single document.
> >> Thanks that's very useful background information. However, even though
> I’m happy to hear that this process worked well, the question for
> >> 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.
> >
> > 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.
> >>> 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:
> >> 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.