Subject: Genart telechat review of draft-ietf-i2nsf-problem-and-use-cases-12

From: Dale Worley <[email-masked]>
Date: Sun, 23 Apr 2017 19:04:30 -0700

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

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

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

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.

[END]

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 25 Apr 2017 10:11:31 -0400

Dale: 

Thank you for the second review.  I'll address these issues along with
others later today. 

Sue Hares  

-----Original Message-----
From: I2nsf [mailto:[email-masked]] On Behalf Of Dale Worley
Sent: Sunday, April 23, 2017 10:05 PM
To: [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: [I2nsf] Genart telechat review of
draft-ietf-i2nsf-problem-and-use-cases-12

Reviewer: Dale Worley

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.

Summary:

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

   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:

--

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

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

   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.

[END]

_______________________________________________
I2nsf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i2nsf

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 27 Apr 2017 08:46:06 -0400

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:[email-masked]] On Behalf Of Dale Worley
Sent: Sunday, April 23, 2017 10:05 PM
To: [email-masked]
Cc: [email-masked]; [email-masked];

Reviewer: Dale Worley

Summary:

Changed in version 14.  

--

   There

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

Sue: Thank you for catching this.  I moved all of these words to small case
except in titles. 

Sue:
Old/provider side/New/Provide/ 

[END]

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 27 Apr 2017 11:34:34 -0400

> Sue:  Dale I rewrote the whole paragraph in version 14. 

When I read the new paragraph, I get a slightly different impression
than I did from the old paragraph (which is likely something you
indend), viz., that it's about what could be called "the mitigation
action lifecycle", the entire process from identification of the problem
to verification that it has been mitigated, rather than just the
*action* of mitigating the traffic problem.  Within that broader
context, the importance of monitoring is obvious.

> Sue: Thank you for catching this.  I moved all of these words to small case

I overlooked (ugh) that there's an instance in section 2:

   Security Service Provider:    A provider of security services to the
      customers (end-users or enterprises) using NSF equipment purchased
      from vendors or created by the service provider.

It turns out that there are only 2 multi-word terms defined in section
2 where the later words aren't acronyms, which are the terms whose
capitalization should be consistent.  The other one is:

   Bespoke security management:   Security management which is made to
      fit a particular customer.

Dale