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

Dale Worley <worley@ariadne.com> Mon, 24 April 2017 02:04 UTC

Return-Path: <worley@ariadne.com>
X-Original-To: ietf@ietf.org
Delivered-To: ietf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8751A127071; Sun, 23 Apr 2017 19:04:30 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Dale Worley <worley@ariadne.com>
To: gen-art@ietf.org
Cc: i2nsf@ietf.org, ietf@ietf.org, draft-ietf-i2nsf-problem-and-use-cases.all@ietf.org
Subject: Genart telechat review of draft-ietf-i2nsf-problem-and-use-cases-12
X-Test-IDTracker: no
X-IETF-IDTracker: 6.50.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149299947052.25893.14183369388246516074@ietfa.amsl.com>
Date: Sun, 23 Apr 2017 19:04:30 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/9bcMN-n07ZKzFAlD_ZougvIupCU>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Apr 2017 02:04:31 -0000

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]