Subject: [I2nsf] WG last call and shepherd review of draft-ietf-i2nsf-framework-05

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 16 Jun 2017 01:24:47 +0100

Hi,

To add to the reviews you've already had, here are my comments.

Thanks for the work,
Adrian

===

Abstract
s/in which/to which/

---

Introduction
Expand NSF on first use

---

I think your use of RFC 2119 language is not appropriate in this 
document. I suggest making everything normal lowercase English and
deleting the two paragraphs at the top of Section 2.

---

BSS, CDN, ICN, and OSS are not used in the document and can be removed
from section 2.1.

---

In 2.2, the term used in 
is "I2NSF Consumer"

I suggest you write 
   Consumer: Equivalent to "I2NSF Consumer"

---

3.1 has...

   The Consumer-Facing Interface is used to enable different users of a
   given I2NSF system to define, manage, and monitor security policies
   for specific flows within an administrative domain.  In today's
   world, where everything is connected, preventing unwanted traffic has
   become a key challenge.  More and more networks are implemented as a
   form of overlay network, with their paths or links among nodes being
   provided by other networks (a.k.a. underlay networks).

   The overlay network's own security solutions cannot prevent various
   attacks from saturating the access links to the overlay network
   nodes, which may cause various components of one or more overlay
   nodes (e.g., CPU or link bandwidth) to become overloaded, and unable
   to handle their own legitimate traffic.  An I2NSF system can be used
   by overlay networks to request certain flow-based security rules to
   be enforced by underlay networks.  This operates in a similar manner
   to how traditional networks use firewalls or IPS devices to enforce
   traffic rules.  The I2NSF system can reduce, or even eliminate,
   unwanted traffic, which prevents unwanted traffic from consuming
   critical node resources.  The same approach can be used by enterprise
   networks to request their specific flow security policies to be
   enforced by the provider network that interconnects their users.  The
   location and implementation of I2NSF policies are irrelevant to the
   consumer of I2NSF policies.

This nearly all seems like marketing talk to me. It probably isn't 
untrue, but it seems out of place in the section that is supposed to
talk about the Consumer-Facing Interface.

I think you could reduce to...

   The Consumer-Facing Interface is used to enable different users of a
   given I2NSF system to define, manage, and monitor security policies
   for specific flows within an administrative domain.  The location and
   implementation of I2NSF policies are irrelevant to the consumer of 
   I2NSF policies.

If you wanted to merge the rest of the material in to Section 1, that 
would be OK, but equally, you could decide that Section 1 already says 
enough and just delete the surplus text.

---

I'm struggling a little with ....

3.3.  Registration Interface

   NSFs provided by different vendors may have different capabilities.
   In order to automate the process of utilizing multiple types of
   security functions provided by different vendors, it is necessary to
   have an interface for vendors to define the capabilities of their
   NSFs.  This Interface Group is called the Registration Interface
   Group.

   An NSF's capabilities can either be pre-configured or retrieved
   dynamically through the Registration Interface Group.  If a new
   function that is exposed to the consumer is added to an NSF, then
   those capabilities SHOULD be notified to security controllers via the
   Registration Interface Group.

There is definitely an ambiguity about this. Is the section talking 
about the "Registration Interface Group"? What are the component 
interfaces in this group?

---

6.1.  Network Connecting I2NSF Users and I2NSF Controller

   [TBD: should we add the Remote Attestation to this section?]

I think you have added remote attestation and can remove this note.

---

6.2

   The network connection between the Security Controller and NSFs can
   rely either on:

Should you be making clear that in the open environment anything from a
few up to all of the NSFs can be hosted in external administrative 
domains.  Thus "closed" is very tightly defined, and "open" is anything
that is not completely closed.

---

I can't help thinking that section 9.2 is way too detailed for this
document. I don't think there is anything wrong in what it says, but it
looks more like an information model for a specific capability exchange
than something that belongs in a general framework.

Can you see whether there is a different document that this belongs in?