Subject: Re: [I2nsf] Revised I2NSF charter with "Simple Service Layer" included in the scope

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 5 Aug 2015 13:03:17 +0100

Hi Linda,

I want to suggest some edits to the charter text. Using change markers is
somewhat hard in a text email, but I have done my best.

OLD
Network Security Function (NSF) is to ensure integrity, confidentiality and
availability of network communications, to detect unwanted activity, and to
block it or at least mitigate its effects.
NEW
A Network Security Function (NSF) is a function used to ensure integrity,
confidentiality, and availability of network communications, to detect unwanted
network activity, and to block or at least the mitigate effects of unwanted
activity.
END

NSFs are provided and consumed in increasingly diverse environments. Users of
NSFs could consume network security services hosted by one or more providers,
which may be their own enterprise, service providers, or a combination of both. 

OLD
Likewise, service providers of NSFs may offer their customers network security
services that consist of multiple security products and/or functions from
different vendors.
NEW
Similarly, service providers may offer their customers network security services
that consist of multiple security products and/or functions from different
vendors.
END

NSFs may be provided by physical and/or virtualized infrastructure. 

OLD
Without standard interfaces to control and monitor the behavior of NSFs, it has
become virtually impossible for security service providers to automate service
offerings that utilize different security functions from multiple vendors.
NEW
Without standard interfaces to control and monitor the behavior of NSFs, it has
become virtually impossible for providers of security services to automate
service offerings that utilize different security functions from multiple
vendors.
END

OLD
The primary goal of I2NSF is to define an information model, a set of software
interfaces and data models for controlling and monitoring aspects of physical
and virtual NSFs.
COMMENT
I suggest we adopt the language used in existing charters to discuss information
models so that the WG is not obliged to produce an information model, but can do
if it considers it necessary.
NEW
The goal of I2NSF is to define a set of software interfaces and data models for
controlling and monitoring aspects of physical and virtual NSFs. If the working
group finds it necessary to work on an information model before the data models,
to help provide guidance and derive the data models, it may do so. The working
group will decide later whether the information model needs to be published as
an RFC.
END

Other aspects of NSFs, such as device or network provisioning and configuration,
are out of scope. 

INSERT
<paragraph break>
END

Controlling and monitoring of NSFs should include the ability to specify, query,
monitor, and control the NSFs by one or more management entities. Since
different security vendors support different features and functions on their
devices, I2NSF will focus on flow-based NSFs that provide treatment to
packets/flows, such as IPS/IDS

COMMENT
need to expand "IPS/IDS"
END

, Web filtering, flow filtering, deep packet inspection, or pattern matching and
remediation. 

OLD
There are two layers of interfaces envisioned in the I2NSF approach:
NEW
I2NSF will specify interfaces at two functional levels for the control and
monitoring of network security functions:
END

OLD
• The I2NSF Capability Layer specifies how to control and monitor NSFs at a
functional implementation level. That is, I2NSF will standardize a set of
interfaces by which a security controller can control and manage NSFs may be
invoked, operated, and monitored. (I2NSF will not at this stage specify how to
derive control and monitoring capabilities from higher level security policies
for the Capability Layer.)
COMMENT
Text about operation of the security controller to produce capabilities for the
Capability Layer moved to next bullet.
NEW
• The I2NSF Capability Layer specifies how to control and monitor NSFs at a
functional implementation level. I2NSF will standardize a set of interfaces by
which a security controller can invoke, operate, and monitor NSFs. 
END

OLD
• The I2NSF Service Layer defines how clients’ security policies may be
expressed and monitored to a security controller that uses the capability layer
to control and manage NSFs to implement these policies.  Describing a simple
service layer modeled as closely as possible on the capability layer is within
scope.  With this simple service layers, security controllers might handle
issues like multi-tenancy concerns, and choosing which of the available NSFs to
use for a given policy.  Expressing policies in ways other than the model used
by the capability layer is out of scope.  However, I2NSF will provide a forum
for Informational drafts on data models, APIs, etc. that demonstrate how more
complex service layer policies and policies in other formats may be translated
to Capability Layer functions.
NEW
• The I2NSF Service Layer defines how clients’ security policies may be
expressed a security controller that uses the capability layer to control and
manage NSFs to implement these policies.  It also allows the client to monitor
those policies. I2NSF will not specify how a security controller maps security
service requests at the Service Layer to control and management actions at the
Capability Layer, but the development of a Simple Service Layer model that is
modelled as closely as possible on the Capability Layer is within scope.  Such a
Simple Service Layer will enable a security controllers to handle issues like
multi-tenancy and the choice between available NSFs for a given policy.
Expressing policies in ways other than the model used by the Capability Layer is
out of scope, however I2NSF will provide a forum for Informational drafts on
data models, APIs, etc. that demonstrate how more complex Service Layer policies
and formats may be translated to Capability Layer functions.
END

COMMENT
The following list of tasks duplicates the deliverables. Merge the content and
include it below.
DELETE
The concrete work at the I2NSF Capability Layer includes development of

• An information model that defines concepts required for standardizing the
control and monitoring of NSFs.
• A set of YANG data models, derived from the above information model.
• The capability registry (IANA) that enables the characteristics and behavior
of NSFs to be specified using a vendor-neutral vocabulary without requiring the
NSFs themselves to be standardized. The registry enables various mechanisms,
including policy rules, to be used to match monitor and control functions to the
needs of an application and/or environment.
• Examining the existing secure communication mechanisms to identify the
appropriate ones for carrying the controlling and monitoring information between
the NSFs and their management entity (or entities).

OLD
Standard interfaces for monitoring and controlling the behavior of NSFs are
essential building blocks for Security Service Providers to automate the use of
different NSFs from multiple vendors by their Security management entities. This
work will leverage the existing protocols and data models defined by I2RS,
Netconf, and NETMOD. If extensions to these protocols are needed, requirements
will be developed by this WG, and the extensions will be developed in
cooperation with the WGs responsible for the protocols.
NEW
Standard interfaces for monitoring and controlling the behavior of NSFs are
essential building blocks for providers of security service to automate the use
of different NSFs from multiple vendors. This work will leverage the existing
protocols and data models defined by the I2RS, NETCONF, and NETMOD working
groups. If extensions to these protocols or data models are needed, requirements
will be developed by this WG, and the extensions will be developed in
cooperation with the WGs responsible for the protocols.
END

The I2NSF WG’s deliverables include:

OLD
- Use cases, problem statement, gap analysis document [The WG will decide if to
proceed as RFC].
- Framework Document, presenting an overview of the use of NSFs and the purpose
of the models developed by the WG [The WG will decide if to proceed as RFC].
- A single, unified, Information Model for controlling and monitoring flow-based
NSFs.
- Corresponding YANG Data Models derived from the above Information Model.
- IANA registry consideration for flow-based NSFs controlling and monitoring
capabilities.[maybe merged into data models]
NEW
- A single document covering use cases, problem statement, and gap analysis
document. This document will initially be produced for reference as a living
list to track and record discussions: the WG may decide to not publish this
document as an RFC.
- A framework document, presenting an overview of the use of NSFs and the
purpose of the models developed by the WG. This document will also be a
reference text to guide the main work and the WG may decide to not publish this
document as an RFC.
- If the working group considers it necessary, a single, unified, Information
Model to describe the control and monitoring of flow-based NSFs.
- YANG data models for the control and monitoring of NSFs.
- Requests to the IANA for the creation of a registry that enables the
characteristics and behavior of NSFs to be specified using a vendor-neutral
vocabulary without requiring the NSFs themselves to be standardized. The
registry enables various mechanisms, including policy rules, to be used to match
monitor and control functions to the needs of an application and/or environment.
- An examination of existing secure communication mechanisms to identify the
appropriate ones for carrying the controlling and monitoring information between
the NSFs and their management entities. This document may also be produced as a
working document that is not published as an RFC.
END

OLD
The WG may additionally choose to develop additional documents to describe
requirements for extensions (if any) to existing protocols used by the WG, and
how the data models are used to monitor and control flow-based NSFs, and to
describe how to use I2RS, Netconf, and NETMOD to carry the content of the data
models.
NEW
The WG may additionally choose to develop documents to describe requirements for
extensions (if any) to existing protocols used by the WG, to explain how the
data models are used to monitor and control flow-based NSFs, and to describe how
to use I2RS and NETCONF to carry the content of the data models. These documents
may be published as Informational RFCs of may be working documents that are
discarded once they have triggered the necessary work.
END

DELETE
[The WG may decide that the Use cases, Framework, and gap analysis are simply
reference documents during the lifetime of the WG and not to be published as an
RFC.]
END

OLD
The WG will work closely with I2RS, Netconf and Netmod WGs. The WG will
communicate with external SDOs like ETSI NFV and will encourage open source code
development related to the WG scope in organizations like ONF, OpenStack, ODL,
and OPNFV.
NEW
The WG will work closely with the I2RS, NETCONF, and NETMOD WGs. The WG will
communicate with external SDOs like ETSI NFV and will encourage open source code
development related to the WG scope in organizations like ONF, OpenStack, ODL,
and OPNFV.
END

COMMENT
These milestones are ambiguous. Do we mean:
- someone writes a document
- the WG adopts a document
- the WG males a publication request
- the RFC is published?
I think all that is needed is to add the clarity.
END

Suggested Milestones

  - Use Cases, problem statement, and gap analysis Document:  Charter time + 1
month
  - Framework: Charter time + 4 months to WG Document
  - Requirements for extensions to protocols:  Charter time + 8 months to WG
document
  - Info model: Charter time + 8 months to WG Document
  - IANA registry consideration + 12 months to WG Document
  - All Early Drafts to IESG: 18 months

[decision point – +10 months]  

  - Data Models: Charter + 9 Months to WG Document
  - Applicability Statements: 10 months to WG Document
  - Data Models and Applicability Statements to IESG  - 18 months

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 5 Aug 2015 17:08:57 +0000

Adrian, 

Thank you very much for the suggestions. All of them are great suggestions

I have some questions/comments inserted below. The clean version is updated in the i2nsf wiki: https://sites.google.com/site/interface2nsf/

Thanks, 
Linda

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Wednesday, August 05, 2015 7:03 AM
To: Linda Dunbar; [email-masked]; 'Kathleen Moriarty'
Cc: 'Romascanu, Dan (Dan)'; [email-masked]
Subject: RE: [I2nsf] Revised I2NSF charter with "Simple Service Layer" included in the scope

Hi Linda,

I want to suggest some edits to the charter text. Using change markers is somewhat hard in a text email, but I have done my best.

OLD
Network Security Function (NSF) is to ensure integrity, confidentiality and availability of network communications, to detect unwanted activity, and to block it or at least mitigate its effects.
NEW
A Network Security Function (NSF) is a function used to ensure integrity, confidentiality, and availability of network communications, to detect unwanted network activity, and to block or at least the mitigate effects of unwanted activity.
END

[Linda] That is very good suggestion. 

NSFs are provided and consumed in increasingly diverse environments. Users of NSFs could consume network security services hosted by one or more providers, which may be their own enterprise, service providers, or a combination of both. 

OLD
Likewise, service providers of NSFs may offer their customers network security services that consist of multiple security products and/or functions from different vendors.
NEW
Similarly, service providers may offer their customers network security services that consist of multiple security products and/or functions from different vendors.
END

[Linda] Instead of saying "The "network security services that consist of", can we say "The network security services that are enforced by multiple security products and/or functions from different vendors"? 

OLD
Without standard interfaces to control and monitor the behavior of NSFs, it has become virtually impossible for security service providers to automate service offerings that utilize different security functions from multiple vendors.
NEW
Without standard interfaces to control and monitor the behavior of NSFs, it has become virtually impossible for providers of security services to automate service offerings that utilize different security functions from multiple vendors.
END
[Linda] that is good with me. 

OLD
The primary goal of I2NSF is to define an information model, a set of software interfaces and data models for controlling and monitoring aspects of physical and virtual NSFs.
COMMENT
I suggest we adopt the language used in existing charters to discuss information models so that the WG is not obliged to produce an information model, but can do if it considers it necessary.
NEW
The goal of I2NSF is to define a set of software interfaces and data models for controlling and monitoring aspects of physical and virtual NSFs. If the working group finds it necessary to work on an information model before the data models, to help provide guidance and derive the data models, it may do so. The working group will decide later whether the information model needs to be published as an RFC.
END

[Linda] good suggestion. 

Other aspects of NSFs, such as device or network provisioning and configuration, are out of scope. 

INSERT
<paragraph break>
END

Controlling and monitoring of NSFs should include the ability to specify, query, monitor, and control the NSFs by one or more management entities. Since different security vendors support different features and functions on their devices, I2NSF will focus on flow-based NSFs that provide treatment to packets/flows, such as IPS/IDS

COMMENT
need to expand "IPS/IDS"
END

, Web filtering, flow filtering, deep packet inspection, or pattern matching and remediation. 

OLD
There are two layers of interfaces envisioned in the I2NSF approach:
NEW
I2NSF will specify interfaces at two functional levels for the control and monitoring of network security functions:
END
[Linda] agree. 

OLD
. The I2NSF Capability Layer specifies how to control and monitor NSFs at a functional implementation level. That is, I2NSF will standardize a set of interfaces by which a security controller can control and manage NSFs may be invoked, operated, and monitored. (I2NSF will not at this stage specify how to derive control and monitoring capabilities from higher level security policies for the Capability Layer.) COMMENT Text about operation of the security controller to produce capabilities for the Capability Layer moved to next bullet.
NEW
. The I2NSF Capability Layer specifies how to control and monitor NSFs at a functional implementation level. I2NSF will standardize a set of interfaces by which a security controller can invoke, operate, and monitor NSFs. 
END

[Linda] so we don't need to emphasize that "(I2NSF will not at this stage specify how to derive control and monitoring capabilities from higher level security policies for the Capability Layer)"?

OLD
. The I2NSF Service Layer defines how clients' security policies may be expressed and monitored to a security controller that uses the capability layer to control and manage NSFs to implement these policies.  Describing a simple service layer modeled as closely as possible on the capability layer is within scope.  With this simple service layers, security controllers might handle issues like multi-tenancy concerns, and choosing which of the available NSFs to use for a given policy.  Expressing policies in ways other than the model used by the capability layer is out of scope.  However, I2NSF will provide a forum for Informational drafts on data models, APIs, etc. that demonstrate how more complex service layer policies and policies in other formats may be translated to Capability Layer functions.
NEW
. The I2NSF Service Layer defines how clients' security policies may be expressed a security controller that uses the capability layer to control and manage NSFs to implement these policies.  It also allows the client to monitor those policies. I2NSF will not specify how a security controller maps security service requests at the Service Layer to control and management actions at the Capability Layer, but the development of a Simple Service Layer model that is modelled as closely as possible on the Capability Layer is within scope.  Such a Simple Service Layer will enable a security controllers to handle issues like multi-tenancy and the choice between available NSFs for a given policy.
Expressing policies in ways other than the model used by the Capability Layer is out of scope, however I2NSF will provide a forum for Informational drafts on data models, APIs, etc. that demonstrate how more complex Service Layer policies and formats may be translated to Capability Layer functions.
END

[Linda] do you mean " The I2NSF Service Layer defines how clients' security policies may be expressed" to "a security controller"? 

COMMENT
The following list of tasks duplicates the deliverables. Merge the content and include it below.
DELETE
The concrete work at the I2NSF Capability Layer includes development of

. An information model that defines concepts required for standardizing the control and monitoring of NSFs.
. A set of YANG data models, derived from the above information model.
. The capability registry (IANA) that enables the characteristics and behavior of NSFs to be specified using a vendor-neutral vocabulary without requiring the NSFs themselves to be standardized. The registry enables various mechanisms, including policy rules, to be used to match monitor and control functions to the needs of an application and/or environment.
. Examining the existing secure communication mechanisms to identify the appropriate ones for carrying the controlling and monitoring information between the NSFs and their management entity (or entities).

[Linda] do you mean deleting all the bullets above?

OLD
Standard interfaces for monitoring and controlling the behavior of NSFs are essential building blocks for Security Service Providers to automate the use of different NSFs from multiple vendors by their Security management entities. This work will leverage the existing protocols and data models defined by I2RS, Netconf, and NETMOD. If extensions to these protocols are needed, requirements will be developed by this WG, and the extensions will be developed in cooperation with the WGs responsible for the protocols.
NEW
Standard interfaces for monitoring and controlling the behavior of NSFs are essential building blocks for providers of security service to automate the use of different NSFs from multiple vendors. This work will leverage the existing protocols and data models defined by the I2RS, NETCONF, and NETMOD working groups. If extensions to these protocols or data models are needed, requirements will be developed by this WG, and the extensions will be developed in cooperation with the WGs responsible for the protocols.
END

The I2NSF WG's deliverables include:

OLD
- Use cases, problem statement, gap analysis document [The WG will decide if to proceed as RFC].
- Framework Document, presenting an overview of the use of NSFs and the purpose of the models developed by the WG [The WG will decide if to proceed as RFC].
- A single, unified, Information Model for controlling and monitoring flow-based NSFs.
- Corresponding YANG Data Models derived from the above Information Model.
- IANA registry consideration for flow-based NSFs controlling and monitoring capabilities.[maybe merged into data models] NEW
- A single document covering use cases, problem statement, and gap analysis document. This document will initially be produced for reference as a living list to track and record discussions: the WG may decide to not publish this document as an RFC.

[Linda] Is it important to be "one single document" to cover the 3 existing drafts (use cases, problem statement, and gap analysis)? 

- A framework document, presenting an overview of the use of NSFs and the purpose of the models developed by the WG. This document will also be a reference text to guide the main work and the WG may decide to not publish this document as an RFC.
- If the working group considers it necessary, a single, unified, Information Model to describe the control and monitoring of flow-based NSFs.
- YANG data models for the control and monitoring of NSFs.
- Requests to the IANA for the creation of a registry that enables the characteristics and behavior of NSFs to be specified using a vendor-neutral vocabulary without requiring the NSFs themselves to be standardized. The registry enables various mechanisms, including policy rules, to be used to match monitor and control functions to the needs of an application and/or environment.
- An examination of existing secure communication mechanisms to identify the appropriate ones for carrying the controlling and monitoring information between the NSFs and their management entities. This document may also be produced as a working document that is not published as an RFC.
END

OLD
The WG may additionally choose to develop additional documents to describe requirements for extensions (if any) to existing protocols used by the WG, and how the data models are used to monitor and control flow-based NSFs, and to describe how to use I2RS, Netconf, and NETMOD to carry the content of the data models.
NEW
The WG may additionally choose to develop documents to describe requirements for extensions (if any) to existing protocols used by the WG, to explain how the data models are used to monitor and control flow-based NSFs, and to describe how to use I2RS and NETCONF to carry the content of the data models. These documents may be published as Informational RFCs of may be working documents that are discarded once they have triggered the necessary work.
END

DELETE
[The WG may decide that the Use cases, Framework, and gap analysis are simply reference documents during the lifetime of the WG and not to be published as an RFC.] END

OLD
The WG will work closely with I2RS, Netconf and Netmod WGs. The WG will communicate with external SDOs like ETSI NFV and will encourage open source code development related to the WG scope in organizations like ONF, OpenStack, ODL, and OPNFV.
NEW
The WG will work closely with the I2RS, NETCONF, and NETMOD WGs. The WG will communicate with external SDOs like ETSI NFV and will encourage open source code development related to the WG scope in organizations like ONF, OpenStack, ODL, and OPNFV.
END

COMMENT

Suggested Milestones

  - Use Cases, problem statement, and gap analysis Document:  Charter time + 1 month
  - Framework: Charter time + 4 months to WG Document
  - Requirements for extensions to protocols:  Charter time + 8 months to WG document
  - Info model: Charter time + 8 months to WG Document
  - IANA registry consideration + 12 months to WG Document
  - All Early Drafts to IESG: 18 months

[decision point - +10 months]