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 protected]] Sent: Wednesday, August 17, 2016 10:45 PM To: The IESG Cc: [email protected]; Jeffrey Haas; [email protected]; [email protected]; [email protected] 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 _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
