Kathleen: Thank you for these comments. I will work on a revision of the document to address these points. I hope to have the new draft on Monday.
Sue Hares -----Original Message----- From: I2nsf [mailto:[email protected]] On Behalf Of Kathleen Moriarty Sent: Friday, February 17, 2017 10:08 PM To: [email protected] Subject: [I2nsf] AD review of draft-ietf-i2nsf-problem-and-use-cases Hello, Thank you for your work on this draft. I can see that a lot effort has gone into it from the beginning of the I2 NSF work. I have some recommendations for changes before starting IETF last call. I hope you find these comments helpful to improve the document. Section 3.1.9: Are there more details on the security requirements around #3: 3. Automated Key management must support both symmetric keys and group keys via the service provided by items 1 and 2. Section 3.2: The work in DOTS is limited to DDoS and not all attack types and the following text reads as if it were all attack types: "o Which critical communications are to be preserved during critical events (DOTS working group is standardizing), o Which hosts are to continue service even during severe security attacks (DOTS working group is standardizing)," Once I reached section 3.2.2, the bulleted section felt redundant. I don't think the text was explicitly stated elsewhere, but the positive direction of the same material is expressed and that should be enough IMO. This is just an opinion to consider if you'd like to tighten up the document a bit. The last paragraph of 3.2.2 could be argued as a selling point to differentiate between another firewall vendor. Object oriented configuration tools were my personal favorite. This was provided through an interface that would generate the configs to push out to multiple firewalls. It can be a selling point to be different. You may be better off dropping this claim. Section 3.2: Is efficiency the word you intended in the following sentence or was it some other property? The customer also lacks the ability to perform "what-if" scenarios to assess the efficiency of the delivered security service. Section 3.2.3: Could you break the last sentence into 2? And do you mean efficiency or something else? It is the objective of the I2NSF work to provide a standard way to get security service assurance of a customers specific security policies which provides enough information for customers to perform "what-if" scenarios to assess efficiency of delivered security services. Section 3.3 also feels repetitive. Reducing text in the earlier section will help to resolve this issue. Section 4.2: The begininning of this screams of censorship. Although your intended use case is innocent enough with parental controls, there is lots of opportunity for abuse expanding to other types of censorship we don't typically support in protocols. I recommend reducing this to the threat management descriptions. OLD: Residential: service requests for parental control, content management, and threat management. Parental control requests may include identity based filters for web content or usage. Content management may include identifying and blocking malicious activities from web contents, mail, or files downloaded. Threat management may include identifying and blocking botnets or malware. NEW: Residential: service requests for threat management. Threat content management may include identifying and blocking malicious activities from web contents, mail, or files downloaded. Threat management may also include identifying and blocking botnets or malware. Enterprise section: I recommend that you also tighten up this language so it is not about content censorship in any way. access to (or isolation from) various web sites or social media applications Section 4.3.2: I'm having a little trouble with the following sentence and think the point is made in the previous 2 sentences, so I think it is safe to drop: Without automation, it is virtually impossible for clients to dynamically specify their desired rules for their traffic. Then the following sentence is more of a requirement, but is in the use case section, so should it be written a little differently? Another feature that aids automation of firewalls that must be covered in automation is dynamic key management. Section 4.3.4: I wouldn't refer to DLP as a 'new' class of service. Nits: General - check acronyms to just expand on first use. I think there are a few cases where acronyms are redefined multiple times in the document. Section 3.1.1 s/IP-sec gateways/ IPsec gateways/ Last sentence in this section could be written more clearly, I get what it is saying, but it could be improved: 'There exist various network security monitoring vendor-specific interfaces for forensics and troubleshooting.' Section 3.1.9 s/IPSec/IPsec/ Section 3.4: Last line s/raise raise/raise/ Section 3.5: s/standrd/standard/ Section 4.3.2 I think this is the first place I saw FWs in the docuemnt. It's easy enough to just spell it out, so please do! -- Best regards, Kathleen _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
