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

["Susan Hares" <[e-mail]>]

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

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

[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