Dale: Thank you for taking the time do a second careful review. I can only wish I such an excellent review of documents I am an editor on. Version 14 addresses all of your comments. Sue -----Original Message----- From: I2nsf [mailto:i2nsf-bounces@xxxxxxxx] On Behalf Of Dale Worley Sent: Sunday, April 23, 2017 10:05 PM To: gen-art@xxxxxxxx Cc: i2nsf@xxxxxxxx; ietf@xxxxxxxx; draft-ietf-i2nsf-problem-and-use-cases.all@xxxxxxxx Subject: [I2nsf] Genart telechat review of draft-ietf-i2nsf-problem-and-use-cases-12 Reviewer: Dale Worley Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-i2nsf-problem-and-use-cases-12 Reviewer: Dale R. Worley Review Date: 2017-04-23 IETF LC End Date: 2017-03-22 IESG Telechat date: 2017-04-27 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. All of these nits are editorial. 3.1.1. Diverse Types of Security Functions Security gateways and VPN concentrators: Examples of these functions are; IPsec gateways, Secure VPN concentrators that handle bridging secure VPNs, and secure VPN controllers for data flows. Unless "Secure VPN" is a name in itself, "secure" shouldn't be capitalized. (Between -11 and -12, one instance of this was fixed, but the other one remains.) Changed in version 14. 3.1.2. Diverse Interfaces to Control and Monitor NSFs A challenge for monitoring prior to mitigation of a security intrusion is that an NSF cannot monitor what it cannot view. Therefore, enabling a security function to mitigate an intrusion (e.g., firewall [I-D.ietf-opsawg-firewalls]) does not mean that a network is protected if there is no monitoring feedback. As such, it is necessary to have a mechanism to monitor and provide execution status of NSFs to security and compliance management tools. There exist various network security monitoring vendor-specific interfaces for forensics and troubleshooting, but an industry standard interface could provide monitoring across a variety of NSFs. This paragraph still seems to have problems. What the second sentence seems to mean (though it doesn't say it) is that if you enable a security function, you don't *know* that the network is protected if you don't have any monitoring feedback. (The sentence is stated in terms of whether the network *is* protected, which it might well be, even if you don't have monitoring.) It seems that you need to replace "does not mean that a network is protected" with something that is more literally correct. The third sentence is constructed "... to have a mechanism to monitor and provide execution status of NSFs to ...". There's an awkwardness that "monitor" isn't connected to "security and compliance management tools", whereas "provide ... status ... to" *is* connected; there's a problem that the "monitor" and "provide" are written as if they're parallel, but they're not. I think the wording is less confusing this way: As such, it is necessary to have a mechanism to monitor NSFs and provide their execution status to security and compliance management tools. -- There exist various network security monitoring vendor-specific interfaces for forensics and troubleshooting, but an industry standard interface could provide monitoring across a variety of NSFs. I think it's easier to read "vendor-specific network security monitoring interfaces". Sue: Dale I rewrote the whole paragraph in version 14. New/ A challenge for monitoring prior to mitigation of a security intrusion is that an NSF cannot monitor what it cannot view. For example, enabling a security function to mitigate an intrusion (e.g., firewall <xref target="I-D.ietf-opsawg-firewalls"></xref>) must include a mechanism to provide monitoring feedback in order to determine the intrusion has been stopped. Therefore, it is necessary to have a mechanism to monitor and provide execution status of NSFs to security and compliance management tools. There exist such mechanisms in vendor-specific network security interfaces for forensics and troubleshooting, but an industry standard interface could provide monitoring across a variety of NSFs./ 3.1.4. More Demand to Control NSFs Dynamically The Security Service Providers ... The capitalization of "security service providers" is inconsistent. Some times all three words are capitalized (in 3.1.2, 3.1.4, and 4), and some times they're not (two places in 3). Sue: Thank you for catching this. I moved all of these words to small case except in titles. 3.2.2. Today's Control Requests are Vendor Specific Managing by scripts de-jour: The current practices rely upon the use of scripts that generate other scripts which automatically run to upload or download configuration changes, log information and other things. These scripts have to be adjusted each time an implementation from a different vendor technology is enabled by a provider side. What is "a provider side"? I suspect it means "the provider side of an XXX", but I'm not familiar enough with the subject to know what XXX is. Sue: Old/provider side/New/Provide/ [END] _______________________________________________ I2nsf mailing list I2nsf@xxxxxxxx https://www.ietf.org/mailman/listinfo/i2nsf