Subject: [i2rs] Ben Campbell's No Objection on draft-ietf-i2rs-protocol-security-requirements-08: (with COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Wed, 17 Aug 2016 19:45:04 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-i2rs-protocol-security-requirements-08: 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:
----------------------------------------------------------------------

Version 8 resolved my discuss point for section 3.4. Thanks!

I don't think it resolved my discuss point for 3.2. I'm clearing anyway,
because I think my point has been made. I would prefer the language to
say that anything not explicitly marked as non-confidential in the
relevant data model MUST be sent over a protected transport. But I will
leave it to the authors to do the right thing.

I will leave my non-discuss comments below for reference. I think version
8 resolves at least some of them. Any remaining are up to you; none of
them are show stoppers.

-2.1: I am on the fence about other's comments about copying definitions
here--but if you do copy them here, it seems strange to not mention
"client" or "agent".

I agree with Alissa about equating privacy and confidentiality.

-3.1,: 
I’m confused by the first paragraph. I don’t find strings of the form of
SEC-REQ-XX in 7921. I think _this_ doc sets these requirements, right?

It’s not clear to me how 5 and 6 differ. Is it just a matter of the
additional “before establishing a connection” part in 6?

-3.4: Isn't 15 simply a restatement of the third item under 14?

3.5: The  MAYs in 19 and 20 seem like statements of fact. (That is, do
they simply recognize reality, or to they  grant permission?)

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 17 Aug 2016 22:54:37 -0400

Ben: 

I'd be glad to take any further suggestions on section 3.2 that improves it for you.  Does modifying this section from 

Old/
A non-secure transport can be used for publishing telemetry data 
or other operational state that was specifically indicated to
non-confidential in the data model in the Yang syntax.  
/

New/
A non-secure transport can be used for publishing telemetry data 
or other operational state that was specifically indicated to
non-confidential in the data model in the Yang syntax.  
Anything not specifically marked as "non-confidential" MUST 
be transmitted over a secure transport connection.
/

Help your concerns on version 3.2? 

Sue 

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Wednesday, August 17, 2016 10:45 PM
To: The IESG
Cc: [email-masked]; Jeffrey Haas; [email-masked]; [email-masked]; [email-masked]
Subject: Ben Campbell's No Objection on draft-ietf-i2rs-protocol-security-requirements-08: (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.)

I don't think it resolved my discuss point for 3.2. I'm clearing anyway, because I think my point has been made. I would prefer the language to say that anything not explicitly marked as non-confidential in the relevant data model MUST be sent over a protected transport. But I will leave it to the authors to do the right thing.

I will leave my non-discuss comments below for reference. I think version
8 resolves at least some of them. Any remaining are up to you; none of them are show stoppers.

> -2.1: I am on the fence about other's comments about copying definitions here--but if you do copy them here, it seems strange to not mention "client" or "agent".

[Sue] Removed definitions. 

> I agree with Alissa about equating privacy and confidentiality.
[Sue]: Removed definition with this text. 

-3.1,: 
>? I’m confused by the first paragraph. I don’t find strings of the form of SEC-REQ-XX in 7921. I think _this_ doc sets these requirements, right?

This document restates the concepts in RFC7921, and adds specific numbers.  The restatement in this form allows requirements to be checked against the developed protocol. 

> It’s not clear to me how 5 and 6 differ. Is it just a matter of the additional “before establishing a connection” part in 6?

Version 08 has these two merged. 

> -3.4: Isn't 15 simply a restatement of the third item under 14?

Changed this text.  Please review the new 13 and 14. 

3.5: The  MAYs in 19 and 20 seem like statements of fact. (That is, do they simply recognize reality, or to they  grant permission?)

They provide a list of approved examples so that the NETCONF/RESTCONF can review these examples.  These examples will help the NETCONF/RESTCONF in their design discussions. 

Sue

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 17 Aug 2016 21:59:16 -0500

Yes, that would address my concern, especially if you think implementers 
will pay attention :-)

There may be interaction with the SHOULD in the previous paragraph, but 
I will leave the word-smithing to you.

Thanks!

Ben.

On 17 Aug 2016, at 21:54, Susan Hares wrote:

> Ben:
>
> I'd be glad to take any further suggestions on section 3.2 that 
> improves it for you.  Does modifying this section from
>
> Old/
> Cc: [email-masked]; Jeffrey 
> Haas; [email-masked]; [email-masked]; [email-masked]
> Subject: Ben Campbell's No Objection on 
> draft-ietf-i2rs-protocol-security-requirements-08: (with COMMENT)
>
> 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
> I don't think it resolved my discuss point for 3.2. I'm clearing 
> anyway, because I think my point has been made. I would prefer the 
> language to say that anything not explicitly marked as 
> non-confidential in the relevant data model MUST be sent over a 
> protected transport. But I will leave it to the authors to do the 
> right thing.
>
>> -2.1: I am on the fence about other's comments about copying 
>> definitions here--but if you do copy them here, it seems strange to 
>> not mention "client" or "agent".
>
>> ? I’m confused by the first paragraph. I don’t find strings of 
>> the form of SEC-REQ-XX in 7921. I think _this_ doc sets these 
>> requirements, right?
>
> This document restates the concepts in RFC7921, and adds specific 
> numbers.  The restatement in this form allows requirements to be 
> checked against the developed protocol.
>
>
> They provide a list of approved examples so that the NETCONF/RESTCONF 
> can review these examples.  These examples will help the 
> NETCONF/RESTCONF in their design discussions.
>
> Sue