Subject: [I2nsf] Consensus call on I2NSF Charter

From: Joseph Salowey <[email-masked]>
Date: Tue, 25 Aug 2015 22:44:03 -0700

Thanks to everyone who has contributed towards developing the charter.  I
believe we are close to consensus so this is a consensus call for the I2NSF
charter.   The charter text is located at
https://sites.google.com/site/interface2nsf/home.  Please send comments on
this charter to the I2NSF list by September 2, 2015.

Thank you,

Joe

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 26 Aug 2015 15:28:45 -0400

I have a few editorial changes in the following text that does not
change the meaning of the charter text:

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. 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.  Similarly, service providers may offer their customers
network security services that are enforced by multiple security
products and/or functions from different vendors. NSFs may be provided
by physical and/or virtualized infrastructure. 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.

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.
Other aspects of NSFs, such as device or network provisioning and
configuration, are out of scope.

Controlling and monitoring aspects of NSFs include the ability to
specify rules (by a single controller at the first phase), query, and
monitor NSFs by one or more management entities.  The initial phase of
I2NSF will only consider one single controller that can specify or
change rules to NSFs because multi-headed control requires the
coordination to avoid potential conflict of rules. The NSFs can be
monitored by multiple entities, but the database update and
synchronization among multiple management entities are out of scope
for I2NSF. As there are many different security vendors supporting
different features and functions on their devices, I2NSF will focus on
flow-based NSFs that provide treatment to packets/flows, such as
Intrusion Protection/Detection System (IPS/IDS), Web filtering, flow
filtering, deep packet inspection, or pattern matching and
remediation.

I2NSF will specify interfaces at two functional levels for the control
and monitoring of network security functions:

The I2NSF Capability Layer specifies how to control and monitor NSFs
at a functional implementation level.  The term “Functional
Implementation” is used to emphasize that the rules (for control and
monitor) of NSFs have to be implementable by most NSFs. I2NSF will
standardize a set of interfaces by which a security controller can
invoke, operate, and monitor NSFs.

The I2NSF Service Layer defines how clients’ security policies may be
expressed to a security controller. The controller implements its
policies according to the various capabilities provided by the I2NSF
capability Layer.  The I2NSF Service Layer also allows the client to
monitor the client specific policies.

Since there could be many depths or types of Service Layer policies,
the following bullets further clarify the scope of I2NSF:
    o Only the Simple Service Layer policies that are modeled as
closely as possible on the Capability Layer are within the scope.
Such a Simple Service Layer will enable a security controller to
handle issues like multi-tenancy and the choice between available NSFs
for a given policy.
    o I2NSF will not specify abstract or sophisticated policies from
clients. Expressing policies in ways other than the model used by the
Capability Layer is out of scope.
    o The translation mechanism/methods from Service Layer policies to
Capability layer comments are out of scope for I2NSF.
However, I2NSF will provide a discussion 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.  Such documents would be pursued outside the WG.

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.

The I2NSF WG’s deliverables include:

    o 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.
    o 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.
    o If the working group considers it necessary, a single, unified,
Information Model to describe the control and monitoring of flow-based
NSFs.
    o YANG data models for the control and monitoring of NSFs.
    o 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.

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.

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.

On Wed, Aug 26, 2015 at 1:44 AM, Joseph Salowey <[email-masked]> wrote:
> _______________________________________________
> I2nsf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2nsf
>

-- 

Best regards,
Kathleen

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 26 Aug 2015 21:38:12 +0000

Kathleen, 

Thank you very much for the editorial changes. The charter description on the I2NSF Wiki has been updated to reflect your suggested changes: https://sites.google.com/site/interface2nsf/home

Linda

-----Original Message-----
From: I2nsf [mailto:[email-masked]] On Behalf Of Kathleen Moriarty
Sent: Wednesday, August 26, 2015 2:29 PM
To: Joseph Salowey
Cc: [email-masked]
Subject: Re: [I2nsf] Consensus call on I2NSF Charter

I have a few editorial changes in the following text that does not change the meaning of the charter text:

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. 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.  Similarly, service providers may offer their customers network security services that are enforced by multiple security products and/or functions from different vendors. NSFs may be provided by physical and/or virtualized infrastructure. 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.

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.
Other aspects of NSFs, such as device or network provisioning and configuration, are out of scope.

Controlling and monitoring aspects of NSFs include the ability to specify rules (by a single controller at the first phase), query, and monitor NSFs by one or more management entities.  The initial phase of I2NSF will only consider one single controller that can specify or change rules to NSFs because multi-headed control requires the coordination to avoid potential conflict of rules. The NSFs can be monitored by multiple entities, but the database update and synchronization among multiple management entities are out of scope for I2NSF. As there are many different security vendors supporting different features and functions on their devices, I2NSF will focus on flow-based NSFs that provide treatment to packets/flows, such as Intrusion Protection/Detection System (IPS/IDS), Web filtering, flow filtering, deep packet inspection, or pattern matching and remediation.

I2NSF will specify interfaces at two functional levels for the control and monitoring of network security functions:

The I2NSF Capability Layer specifies how to control and monitor NSFs at a functional implementation level.  The term “Functional Implementation” is used to emphasize that the rules (for control and
monitor) of NSFs have to be implementable by most NSFs. I2NSF will standardize a set of interfaces by which a security controller can invoke, operate, and monitor NSFs.

The I2NSF Service Layer defines how clients’ security policies may be expressed to a security controller. The controller implements its policies according to the various capabilities provided by the I2NSF capability Layer.  The I2NSF Service Layer also allows the client to monitor the client specific policies.

Since there could be many depths or types of Service Layer policies, the following bullets further clarify the scope of I2NSF:
    o Only the Simple Service Layer policies that are modeled as closely as possible on the Capability Layer are within the scope.
Such a Simple Service Layer will enable a security controller to handle issues like multi-tenancy and the choice between available NSFs for a given policy.
    o I2NSF will not specify abstract or sophisticated policies from clients. Expressing policies in ways other than the model used by the Capability Layer is out of scope.
    o The translation mechanism/methods from Service Layer policies to Capability layer comments are out of scope for I2NSF.
However, I2NSF will provide a discussion 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.  Such documents would be pursued outside the WG.

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.

    o 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.
    o 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.
    o If the working group considers it necessary, a single, unified, Information Model to describe the control and monitoring of flow-based NSFs.
    o YANG data models for the control and monitoring of NSFs.
    o 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.

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.

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.

On Wed, Aug 26, 2015 at 1:44 AM, Joseph Salowey <[email-masked]> wrote:
> Thanks to everyone who has contributed towards developing the charter.  
> I believe we are close to consensus so this is a consensus call for the I2NSF
> https://sites.google.com/site/interface2nsf/home.  Please send 
> comments on this charter to the I2NSF list by September 2, 2015.
>
> Thank you,
>
> Joe
>

-- 

Best regards,
Kathleen

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 26 Aug 2015 18:46:19 -0400

Apologies for joining the discussion late - just got back from PTO. In 
any case, please find some additional comments on the proposed charter 
below (some more substantial than others):

- The first paragraph starts out by defining what an NSF is, and we can 
argue about some of the points in there for various security functions 
(e.g. I may want to detect normal network behavior to establish a 
baseline, which does not seem to be covered by the current definition). 
I don't think that will be a productive discussion though, nor is it 
necessary. Instead, I'd suggest we are not overly prescriptive, but 
rather view these as possible NSF features, and supplement them with 
some actual product examples (e.g. FW, NGFW, IPS, etc.). Similarly, 
since we limit our scope to "flow-based NSFs", we may want to make that 
clear here. An example of a security function that would *not* be in 
scope may be helpful too.

- The third paragraph says that "The NSFs can be monitored by multiple 
entities..."; does this imply a 1:N (direct) monitoring relationship ? 
If so, that seems to get to a design decision that may be premature.

- The charter seems to operate with the notion of a "security 
controller" that interacts with the "NSF". If I understand correctly, 
the security controller implements the "Service Layer" and the NSF 
implements the "Capability Layer". Furthermore, we have "clients" that 
interact with the security controller to implement policies (by 
leveraging the service layer). If so, it would be good to clarify this 
taxonomy earlier in the charter. If not, then I probably need some 
clarifications in the text.

- In the definition of the "Capability Layer", there is a statement 
about "rules...of NSFs have to be implementable by most NSFs". Do you 
mean all NSFs or NSFs of a given type (I assume we have different types 
of NSFs) ?

- Policies are labeled as "simple" or "abstract or sophisticated" 
without further definition; I'm not sure where we draw that line or how 
to do that in the charter; maybe clarifying that part needs to be a 
deliverable ?

- A number of deliverables may not be published as an RFC; why not (they 
seem to set the stage for several other deliverables and hence are 
relevant for consumers of the information and data models later on) ?

- The part about I2NSF providing a "discussion forum for Informational 
drafts on.....[more complex Service Layer policies]..." is confusing to 
me. The work seems to be pursued outside the WG, so there are no 
deliverables and presumably no agenda time will be allocated either. 
It's also not clear to me that we can/should state that such documents 
would be Informational. We may decide that we need some procedures for 
how to define such documents, have designated experts, a directorate, 
etc. to review them etc. I'm guessing this is all a bit premature 
though, but again, we may want to note that as an issue in the charter 
that the WG needs to resolve at some point.

Nits:
- first paragraph:
s/the mitigate/mitigate the/

- second last paragraph:
s/RFCs of/RFCs or

Thanks

-- Flemming

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 26 Aug 2015 23:31:14 +0000

Flemming,

Thank you very much for the detailed comments. Thank you for catching those typos (corrected on the I2NSF wiki now). We really need the fresh set of eyes to look at it.

You stated:
- The third paragraph says that "The NSFs can be monitored by multiple entities..."; does this imply a 1:N (direct) monitoring relationship ?
If so, that seems to get to a design decision that may be premature.

[Linda] The intent is to describe a scenario that a NSF may send different outputs to different entities.  For example, some statistics report to “Analytics system”, “rule query” to management entity. Can you suggest a better wording for this?

Other Replies are inserted below:

-----Original Message-----
From: Flemming Andreasen [mailto:[email-masked]]
Sent: Wednesday, August 26, 2015 5:46 PM
To: Linda Dunbar; Kathleen Moriarty; Joseph Salowey
Cc: [email-masked]
Subject: Re: [I2nsf] Consensus call on I2NSF Charter

Apologies for joining the discussion late - just got back from PTO. In any case, please find some additional comments on the proposed charter below (some more substantial than others):

- The first paragraph starts out by defining what an NSF is, and we can argue about some of the points in there for various security functions (e.g. I may want to detect normal network behavior to establish a baseline, which does not seem to be covered by the current definition).
[Linda] Over the course of I2NSF (about a year),  we have gone through a long debate on what NSFs should be considered by IETF I2NSF. As the result of the long debate, we use the definition to classify a set of functions to be considered for IETF I2NSF (then further narrowing down to Flow-based NSFs).
The function you described, i.e. detecting normal network behavior to establish a baseline is not in the scope of I2NSF, even though this function can also be "provided and consumed in increasingly diverse environments".

I don't think that will be a productive discussion though, nor is it necessary. Instead, I'd suggest we are not overly prescriptive, but rather view these as possible NSF features, and supplement them with some actual product examples (e.g. FW, NGFW, IPS, etc.). Similarly, since we limit our scope to "flow-based NSFs", we may want to make that clear here. An example of a security function that would *not* be in scope may be helpful too.

[Linda] All the NSFs in I2NSF context are “features”, whose form factor can be provided physical box or virtualized format. Some form factors, i.e. devices or VM, can provide multiple “functions”.   Do you think the sentences in the third paragraph is good enough to describe what you want?

      “I2NSF will focus on flow-based NSFs that provide treatment to packets/flows, such as Intrusion Protection/Detection System (IPS/IDS), Web filtering, flow filtering, deep packet inspection, or pattern matching and remediation.”

- The charter seems to operate with the notion of a "security controller" that interacts with the "NSF". If I understand correctly, the security controller implements the "Service Layer" and the NSF implements the "Capability Layer". Furthermore, we have "clients" that interact with the security controller to implement policies (by leveraging the service layer). If so, it would be good to clarify this taxonomy earlier in the charter. If not, then I probably need some clarifications in the text.

[Linda] “Security controller” is a conceptual entity, meaning an entity to send implementable rules (capability layer) to the NSFs. There could be multiple of them, each responsible for one type of NSF (i.e. managing the instances of the NSFs).
I2NSF includes “Simple Service Layer” that models closely to the “Capability Layer”. For example: client can specify the rules without specify which instances of the NSF. The “Controller” manage the instances, as described by The figure in I2NSF Framework document:

 + - - - - - - - - - - - - - - - +  + - - - - - - - - - - - - - - - +
 |  NSF-A  +--------------+      |  |  NSF-B  +--------------+      |
 |         |    Controller|      |  |         |    Controller|      |
 |         +--------------+      |  |         +--------------+      |
 | + - - - - - - - - - - - - - + |  | + - - - - - - - - - - - - - + |
 | |+---------+     +---------+| |  | |+---------+     +---------+| |
 | || NSF-A#1 | ... |  NSF-A#n|| |  | ||  NSF-B#1| ... |  NSF-B#m|| |
 | |+---------+     +---------+| |  | |+---------+     +---------+| |
 | |         NSF-A cluster     | |  | |          NSF-B cluster    | |
 | + - - - - - - - - - - - - - + |  | + - - - - - - - - - - - - - + |
 + - - - - - - - - - - - - - - - +  + - - - - - - - - - - - - - - - +

- In the definition of the "Capability Layer", there is a statement about "rules...of NSFs have to be implementable by most NSFs". Do you mean all NSFs or NSFs of a given type (I assume we have different types of NSFs) ?
[Linda] yes.

- Policies are labeled as "simple" or "abstract or sophisticated"
without further definition; I'm not sure where we draw that line or how to do that in the charter; maybe clarifying that part needs to be a deliverable ?
[Linda] “simple” means that they can be directly translated to capability layer rules with simple mapping, e.g. without explicit stating which instantiation, may have customer ID that can be translated to some tags carried by packets

- A number of deliverables may not be published as an RFC; why not (they seem to set the stage for several other deliverables and hence are relevant for consumers of the information and data models later on) ?

[Linda] The WG group may decide to publish them as RFC or not later. But the charter doesn’t specify which way. That is how IESG wanted.

- The part about I2NSF providing a "discussion forum for Informational drafts on.....[more complex Service Layer policies]..." is confusing to me. The work seems to be pursued outside the WG, so there are no deliverables and presumably no agenda time will be allocated either.
[Linda] this is to address the information documents that describe the I2NSF demo, open source or interoperability initiatives that are conducted outside the WG. E.g https://datatracker.ietf.org/doc/draft-xie-i2nsf-demo-outline-design/

It's also not clear to me that we can/should state that such documents would be Informational. We may decide that we need some procedures for how to define such documents, have designated experts, a directorate, etc. to review them etc. I'm guessing this is all a bit premature though, but again, we may want to note that as an issue in the charter that the WG needs to resolve at some point.

[Linda] Agree with you. I will see how AD wants to address this suggestion .

Nits:
- first paragraph:

- second last paragraph:
s/RFCs of/RFCs or

[Linda] Thank you for the catch. They are corrected on the I2NSF wiki now.

Thanks

-- Flemming

On 8/26/15 5:38 PM, Linda Dunbar wrote:
> Kathleen,
>
> Thank you very much for the editorial changes. The charter description
> on the I2NSF Wiki has been updated to reflect your suggested changes:
> https://sites.google.com/site/interface2nsf/home
>
>
> Linda
>
>
> Cc: [email-masked]<mailto:[email-masked]>
> On Wed, Aug 26, 2015 at 1:44 AM, Joseph Salowey <[email-masked]<mailto:[email-masked]>> wrote:
>> [email-masked]<mailto:[email-masked]>

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 26 Aug 2015 19:34:57 -0400

Thanks for the additional comments.  I have some comments inline.

Sent from my iPhone

> On Aug 26, 2015, at 6:46 PM, Flemming Andreasen <[email-masked]> wrote:
> 
> - The first paragraph starts out by defining what an NSF is, and we can argue about some of the points in there for various security functions (e.g. I may want to detect normal network behavior to establish a baseline, which does not seem to be covered by the current definition). I don't think that will be a productive discussion though, nor is it necessary. Instead, I'd suggest we are not overly prescriptive, but rather view these as possible NSF features, and supplement them with some actual product examples (e.g. FW, NGFW, IPS, etc.). Similarly, since we limit our scope to "flow-based NSFs", we may want to make that clear here. An example of a security function that would *not* be in scope may be helpful too.

I believe these points are well covered in the full charter already.  If you have text that you think clarifies these points without restating them, that would be helpful.

> 
> - The third paragraph says that "The NSFs can be monitored by multiple entities..."; does this imply a 1:N (direct) monitoring relationship ? If so, that seems to get to a design decision that may be premature.

I think we should leave that alone and don't think it necessarily implies a 1:N relationship.
> - The charter seems to operate with the notion of a "security controller" that interacts with the "NSF". If I understand correctly, the security controller implements the "Service Layer" and the NS…

What specific text would you propose?  I think the point is already clear, but if you have proposed text, that may be more helpful to see your point clearly.
> - In the definition of the "Capability Layer", there is a statement about "rules...of NSFs have to be implementable by most NSFs". Do you mean all NSFs or NSFs of a given type (I assume we have dif…

There is already a list of possible NSF device types in the charter.  Is additional text needed to make this point more clear?  I read it as pretty clear already, but seeing a proposal might help.
> 
> - Policies are labeled as "simple" or "abstract or sophisticated" without further definition; I'm not sure where we draw that line or how to do that in the charter; maybe clarifying that part needs to be a deliverable ?

I think that's too much detail for an already very detailed charter.
> - A number of deliverables may not be published as an RFC; why not (they seem to set the stage for several other deliverables and hence are relevant for consumers of the information and data models…

This is a decision the WG can make and is typical for IETF WGs to revisit these decisions.  If you'd like them published, please make that known when this assessment is made.

> - The part about I2NSF providing a "discussion forum for Informational drafts on.....[more complex Service Layer policies]..." is confusing to me. The work seems to be pursued outside the WG, so there are no deliverables and presumably no agenda time will be allocated either. It's also not clear to me that we can/should state that such documents would be Informational. We may decide that we need some procedures for how to define such documents, have designated experts, a directorate, etc. to review them etc. I'm guessing this is all a bit premature though, but again, we may want to note that as an issue in the charter that the WG needs to resolve at some point.

This leaves open some leeway to avoid the need to re charter if work fits into the existing charter, but is not an existing milestone.  This can be decided with the area director without lots of extra process.
> s/the mitigate/mitigate the/

Thank you for the detailed review.
Kathleen

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 26 Aug 2015 22:00:32 -0400

On 8/26/15 7:31 PM, Linda Dunbar wrote:
> Flemming,
> Thank you very much for the detailed comments. Thank you for catching 
> those typos (corrected on the I2NSF wiki now). We really need the 
> fresh set of eyes to look at it.
> You stated:
> [Linda] The intent is to describe a scenario that a NSF may send 
> different outputs to different entities. For example, some statistics 
> report to “Analytics system”, “rule query” to management entity. Can 
> you suggest a better wording for this?
I see. I'm not sure I would get into that level of detail in the 
charter, but since you introduce the notion of "features and functions", 
you could for example say

"The NSFs may contain a multitude of features and functions, each of 
which can be monitored by a different entity"

or something like that.

> - The first paragraph starts out by defining what an NSF is, and we 
> can argue about some of the points in there for various security 
> functions (e.g. I may want to detect normal network behavior to 
> establish a baseline, which does not seem to be covered by the current 
> definition).
> [Linda] Over the course of I2NSF (about a year), we have gone through 
> a long debate on what NSFs should be considered by IETF I2NSF. As the 
> result of the long debate, we use the definition to classify a set of 
> functions to be considered for IETF I2NSF (then further narrowing down 
> to Flow-based NSFs).
> The function you described, i.e. detecting normal network behavior to 
> establish a baseline is not in the scope of I2NSF, even though this 
> function can also be "provided and consumed in increasingly diverse 
> environments".
Ok - the part about "detect unwanted network activity" is fairly broad 
though, and I'm not sure how you detect unwanted activity without 
looking at all activity (which is what triggered my original question).

> since we limit our scope to "flow-based NSFs", we may want to make 
> that clear here. An example of a security function that would *not* be 
> in scope may be helpful too.
> [Linda] All the NSFs in I2NSF context are “features”, whose form 
> factor can be provided physical box or virtualized format. Some form 
> factors, i.e. devices or VM, can provide multiple “functions”. Do you 
> think the sentences in the third paragraph is good enough to describe 
> what you want?
> /“//I2NSF will focus on flow-based NSFs that provide treatment to 
> packets/flows, such as Intrusion Protection/Detection System 
> (IPS/IDS), Web filtering, flow filtering, deep packet inspection, or 
> pattern matching and remediation.//”///
The examples here are clear; I'm less clear on what else might be in 
scope. For example, would a DDoS detection and mitigation system be in 
scope (keeping in mind it may use a combination of packet inspection and 
telemetry-based detection and mitigation and that establishing a 
"normal" baseline is often part of the operation) ?

> [Linda] “Security controller” is a conceptual entity, meaning an 
> entity to send implementable rules (capability layer) to the NSFs. 
> There could be multiple of them, each responsible for one type of NSF 
> (i.e. managing the instances of the NSFs).
> I2NSF includes “Simple Service Layer” that models closely to the 
> “Capability Layer”. For example: client can specify the rules without 
> specify which instances of the NSF. The “Controller” manage the 
> instances, as described by The figure in I2NSF Framework document:
Ok - this basic framework seems to be foundational to the structure of 
the work the group is doing. If so, I think it would be helpful to 
outline it (verbally) in the charter.

> mean all NSFs or NSFs of a given type (I assume we have different 
> types of NSFs) ?
> [Linda] yes.
> without further definition; I'm not sure where we draw that line or 
> how to do that in the charter; maybe clarifying that part needs to be 
> a deliverable ?
> [Linda] “simple” means that they can be directly translated to 
> capability layer rules with simple mapping, e.g. without explicit 
> stating which instantiation, may have customer ID that can be 
> translated to some tags carried by packets
Ok - if that's the definition we want to use, can we clarify it in the 
charter ?

> - A number of deliverables may not be published as an RFC; why not 
> (they seem to set the stage for several other deliverables and hence 
> are relevant for consumers of the information and data models later on) ?
> [Linda] The WG group may decide to publish them as RFC or not later. 
> But the charter doesn’t specify which way. That is how IESG wanted.
Ok.
> drafts on.....[more complex Service Layer policies]..." is confusing 
> to me. The work seems to be pursued outside the WG, so there are no 
> [Linda] this is to address the information documents that describe the 
> I2NSF demo, open source or interoperability initiatives that are 
> conducted outside the WG. E.g 
> _https://datatracker.ietf.org/doc/draft-xie-i2nsf-demo-outline-design/_
Ok - thanks for the pointer, however from a WG point of view, I'm not 
clear on what it means to have a discussion forum and what, if anything, 
the WG will do with it (e.g. discuss such drafts as part of meetings, 
etc) ?

> [Linda] Agree with you. I will see how AD wants to address this 
Ok
> [Linda] Thank you for the catch. They are corrected on the I2NSF wiki 
Thanks for the quick response and updates.

-- Flemming

> > Cc:[email-masked] <mailto:[email-masked]>
> > A Network Security Function (NSF) is a function used to ensure integrity, confidentiality, and availability of network 
> > 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.
> > Controlling and monitoring aspects of NSFs include the ability to specify rules (by a single controller at the first 
> phase), query, and monitor NSFs by one or more management entities.  
> The initial phase of I2NSF will only consider one single controller 
> that can specify or change rules to NSFs because multi-headed control 
> requires the coordination to avoid potential conflict of rules. The 
> NSFs can be monitored by multiple entities, but the database update 
> and synchronization among multiple management entities are out of 
> scope for I2NSF. As there are many different security vendors 
> supporting different features and functions on their devices, I2NSF 
> will focus on flow-based NSFs that provide treatment to packets/flows, 
> such as Intrusion Protection/Detection System (IPS/IDS), Web 
> filtering, flow filtering, deep packet inspection, or pattern matching 
> and remediation.
> >
> > monitor) of NSFs have to be implementable by most NSFs. I2NSF will standardize a set of interfaces by which a security 
> controller can invoke, operate, and monitor NSFs.
> >
> > The I2NSF Service Layer defines how clients’ security policies may be expressed to a security controller. The 
> controller implements its policies according to the various 
> capabilities provided by the I2NSF capability Layer.  The I2NSF 
> Service Layer also allows the client to monitor the client specific 
> policies.
> >
> >      o I2NSF will not specify abstract or sophisticated policies from clients. Expressing policies in ways 
> other than the model used by the Capability Layer is out of scope.
> > However, I2NSF will provide a discussion 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. Such documents would be pursued outside 
> the WG.
> >
> > 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.
> >
> >      o 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.
> >      o 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.
> >      o 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.
> >
> > 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.
> >
> > 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.
> >
> >
> > On Wed, Aug 26, 2015 at 1:44 AM, Joseph Salowey <[email-masked] <mailto:[email-masked]>> wrote:
> >>[email-masked] <mailto:[email-masked]>

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 26 Aug 2015 22:22:39 -0400

> I believe these points are well covered in the full charter already.  If you have text that you think clarifies these points without restating them, that would be helpful.
I don't - I have trouble determining where to draw the line between 
security functions in scope and out of scope and was hoping for further 
clarification to help with that.
> What specific text would you propose?  I think the point is already clear, but if you have proposed text, that may be more helpful to see your point clearly.
Assuming the above understanding is correct, then something along the 
lines of:

In I2NSF, a client that wants to provision security policies to NSFs 
does so by interacting with a security controller. The client leverages 
the I2NSF Service Layer interface to the security controller, which in 
turn interacts with one or more NSFs through the I2NSF Capability Layer 
interface.

> There is already a list of possible NSF device types in the charter.  Is additional text needed to make this point more clear?  I read it as pretty clear already, but seeing a proposal might help.
Assuming it applies to given type of NSF, then I would simply qualify it 
that way, so it becomes:

"rules...of NSFs have to be implementable by most NSFs of a given type" 
- not a big deal though.

> I think that's too much detail for an already very detailed charter.
Agreed, so I would suggest it becomes one of the tasks of the WGs to 
define that.
Ok.
Ok.
> Thank you for the detailed review.

Thanks for the quick response.

-- Flemming

> .

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 26 Aug 2015 22:33:08 -0400

Hi Flemming,

Thanks for the quick responses so we can resolve this quickly.

Sent from my iPhone

> On Aug 26, 2015, at 10:22 PM, Flemming Andreasen <[email-masked]> wrote:
> 
> 
> 
> I don't - I have trouble determining where to draw the line between security functions in scope and out of scope and was hoping for further clarification to help with that.

Ah, I believe this has been discussed and Linda can summarize.

> Assuming the above understanding is correct, then something along the lines of:
> 
> In I2NSF, a client that wants to provision security policies to NSFs does so by interacting with a security controller. The client leverages the I2NSF Service Layer interface to the security controller, which in turn interacts with one or more NSFs through the I2NSF Capability Layer interface.
> 
> 

This is a bit too detailed for the charter in my opinion.  Of others think this is helpful, please speak up.  This should be clear in the framework draft though.

Thanks for proposed text.

> Assuming it applies to given type of NSF, then I would simply qualify it that way, so it becomes:
> 
> "rules...of NSFs have to be implementable by most NSFs of a given type" - not a big deal though.

Ok, since this isn't a big deal, let's leave it as-is.
> Agreed, so I would suggest it becomes one of the tasks of the WGs to define that.

Ok, we're good here.

Thanks,
Kathleen

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 27 Aug 2015 08:26:55 -0400

> This is a bit too detailed for the charter in my opinion.  Of others think this is helpful, please speak up.  This should be clear in the framework draft though.
The framework draft is an individual draft that may or may not be 
adopted by the WG in its current form. If the above baseline is assumed 
by I2NSF, then I think it would be useful to capture that as part of the 
charter. If the baseline requires further WG discussion, then obviously 
we should not put it in the charter at this point.

Thanks

-- Flemming

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 27 Aug 2015 16:29:44 +0000

Flemming,

I have updated the Q&A on the I2NSF Wiki to clarify the questions you have:  https://sites.google.com/site/interface2nsf/i2nsf-q-a/i2nsfqa

Hope it helps. Please let me know if you have more questions or suggestions for I2NSF charter.

Thanks,
Linda
From: Flemming Andreasen [mailto:[email-masked]]
Sent: Wednesday, August 26, 2015 9:01 PM
To: Linda Dunbar; Kathleen Moriarty; Joseph Salowey
Cc: [email-masked]
Subject: Re: [I2nsf] Consensus call on I2NSF Charter

You stated:

I see. I'm not sure I would get into that level of detail in the charter, but since you introduce the notion of "features and functions", you could for example say

"The NSFs may contain a multitude of features and functions, each of which can be monitored by a different entity"

or something like that.

-----Original Message-----
From: Flemming Andreasen [mailto:[email-masked]]
Sent: Wednesday, August 26, 2015 5:46 PM
To: Linda Dunbar; Kathleen Moriarty; Joseph Salowey
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [I2nsf] Consensus call on I2NSF Charter

Ok - the part about "detect unwanted network activity" is fairly broad though, and I'm not sure how you detect unwanted activity without looking at all activity (which is what triggered my original question).

The examples here are clear; I'm less clear on what else might be in scope. For example, would a DDoS detection and mitigation system be in scope (keeping in mind it may use a combination of packet inspection and telemetry-based detection and mitigation and that establishing a "normal" baseline is often part of the operation) ?

Ok - this basic framework seems to be foundational to the structure of the work the group is doing. If so, I think it would be helpful to outline it (verbally) in the charter.

Ok - if that's the definition we want to use, can we clarify it in the charter ?

Ok.

Ok - thanks for the pointer, however from a WG point of view, I'm not clear on what it means to have a discussion forum and what, if anything, the WG will do with it (e.g. discuss such drafts as part of meetings, etc) ?

Nits:
- first paragraph:

- second last paragraph:
s/RFCs of/RFCs or

-- Flemming

Thanks

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 27 Aug 2015 15:52:42 -0400

Thanks Linda

Taking a quick look at the Wiki:
- I noticed that your definition of an NSF explicitly prohibits any 
packet modification such as NAT or MAC rewrite; this will exclude a 
large portion of current NSFs (e.g. it's commonly used by FWs and ADCs) 
- is that intentional ?

- You mention that "logging" is out of scope, yet in other places you 
refer to reporting, analytics, etc., and the charter talks about 
monitoring. Can you clarify ?

Also, a couple of my questions below still seem to be open, but there is 
a parallel exchange with Kathleen on some of those, so maybe we can 
resolve them there.

Cheers

-- Flemming

On 8/27/15 12:29 PM, Linda Dunbar wrote:
>
> Flemming,
>
> I have updated the Q&A on the I2NSF Wiki to clarify the questions you 
> have: https://sites.google.com/site/interface2nsf/i2nsf-q-a/i2nsfqa
>
> *From:*Flemming Andreasen [mailto:[email-masked]]
> *Sent:* Wednesday, August 26, 2015 9:01 PM
> *To:* Linda Dunbar; Kathleen Moriarty; Joseph Salowey
> *Cc:* [email-masked]
> *Subject:* Re: [I2nsf] Consensus call on I2NSF Charter
>
>     Thank you very much for the detailed comments. Thank you for
>     catching those typos (corrected on the I2NSF wiki now). We really
>     need the fresh set of eyes to look at it.
>
>     You stated:
>
>     - The third paragraph says that "The NSFs can be monitored by
>     multiple entities..."; does this imply a 1:N (direct) monitoring
>     relationship ?
>
>     different outputs to different entities. For example, some
>     statistics report to “Analytics system”, “rule query” to
>     management entity. Can you suggest a better wording for this?
>
> charter, but since you introduce the notion of "features and 
> functions", you could for example say
>
> Cc: [email-masked] <mailto:[email-masked]>
> /“I2NSF will focus on flow-based NSFs that provide treatment to 
> pattern matching and remediation.” /
>
> scope (keeping in mind it may use a combination of packet inspection 
> and telemetry-based detection and mitigation and that establishing a 
> https://datatracker.ietf.org/doc/draft-xie-i2nsf-demo-outline-design/
>
> clear on what it means to have a discussion forum and what, if 
> anything, the WG will do with it (e.g. discuss such drafts as part of 
> meetings, etc) ?
>
>
> <https://sites.google.com/site/interface2nsf/home>
>
> >
>
> >
>
> > Linda
>
> >
>
> >
>
> > From: I2nsf [mailto:[email-masked]] On Behalf Of Kathleen
>
> > Moriarty
>
> filtering, deep packet inspection, or pattern matching and remediation.
>
> >
>
> > I2NSF will specify interfaces at two functional levels for the control and 
> monitoring of network security functions:
>
> >
>
> > Since there could be many depths or types of Service Layer policies, the 
> following bullets further clarify the scope of I2NSF:
>
> >      o Only the Simple Service Layer policies that are modeled as closely as 
> possible on the Capability Layer are within the scope.
>
> > Such a Simple Service Layer will enable a security controller to handle 
> issues like multi-tenancy and the choice between available NSFs for a 
> given policy.
>
> >      o 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.
>
> >      o Requests to the IANA for the creation of a registry that enables the 
> characteristics and behavior of NSFs to be specified using a 
> > 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.
>
> >
>
> > 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.
>
> >
>
> >
>
> <https://sites.google.com/site/interface2nsf/home>. Please send
>
> <https://www.ietf.org/mailman/listinfo/i2nsf>
>
> >>
>
> >
>
> >
>

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 27 Aug 2015 20:27:10 +0000

Flemming,

Comments are inserted below:

From: Flemming Andreasen [mailto:[email-masked]]
Sent: Thursday, August 27, 2015 2:53 PM
To: Linda Dunbar; Kathleen Moriarty; Joseph Salowey
Cc: [email-masked]
Subject: Re: Further clarification and explanations to I2NSF charter has been added to the I2NSF Wiki Q&A (was RE: [I2nsf] Consensus call on I2NSF Charter

Thanks Linda

Taking a quick look at the Wiki:
- I noticed that your definition of an NSF explicitly prohibits any packet modification such as NAT or MAC rewrite; this will exclude a large portion of current NSFs (e.g. it's commonly used by FWs and ADCs) - is that intentional ?

[Linda] This is not my intention. I don’t remember who put the last clause in (i.e. without modification to the packet due to the inspection process (MAC rewrites, TTL decrement action; even NAT would be outside the inspection process).. I can pull the mailing list if it ok to remove the last clause.

- You mention that "logging" is out of scope, yet in other places you refer to reporting, analytics, etc., and the charter talks about monitoring. Can you clarify ?
[Linda] Yes, “logging” is referring to analytics, such algorithms, benchmark, etc.

Also, a couple of my questions below still seem to be open, but there is a parallel exchange with Kathleen on some of those, so maybe we can resolve them there.
[Linda] do you mean the questions like “why framework, use cases may not be published as RFCs”? Can you help me out with the questions?

Cheers

-- Flemming

Thanks,
Linda

You stated:

or something like that.

-----Original Message-----
From: Flemming Andreasen [mailto:[email-masked]]
Sent: Wednesday, August 26, 2015 5:46 PM
To: Linda Dunbar; Kathleen Moriarty; Joseph Salowey
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [I2nsf] Consensus call on I2NSF Charter

Ok.

Nits:
- first paragraph:

- second last paragraph:
s/RFCs of/RFCs or

-- Flemming

Thanks

-- Flemming

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 27 Aug 2015 20:42:44 +0000

Over the course of I2NSF process, many people have asked very good questions about various aspects of I2NSF on the mailing list, and many people have given good answers to the questions. Those good questions and answers have been captured in I2NSF Q&A Wiki: https://sites.google.com/site/interface2nsf/i2nsf-q-a/i2nsfqa

Does anyone remember why we had this clause for  the examples of NSFs

Flow-based security also means that packets are inspected in the order they are received, and without modification to the packet due to the inspection process (MAC rewrites, TTL decrement action; even NAT would be outside the inspection process).

Maybe the phrase “without …” should actually be “with some NSFs making modification to the packets due to ..”?  (the latest Wiki has removed the last clause).

Linda

From: Linda Dunbar
Sent: Thursday, August 27, 2015 3:27 PM
To: 'Flemming Andreasen'; Kathleen Moriarty; Joseph Salowey
Cc: [email-masked]
Subject: RE: Further clarification and explanations to I2NSF charter has been added to the I2NSF Wiki Q&A (was RE: [I2nsf] Consensus call on I2NSF Charter

Flemming,

Thanks Linda

Cheers

-- Flemming

Thanks,
Linda

You stated:

or something like that.

-----Original Message-----
From: Flemming Andreasen [mailto:[email-masked]]
Sent: Wednesday, August 26, 2015 5:46 PM
To: Linda Dunbar; Kathleen Moriarty; Joseph Salowey
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [I2nsf] Consensus call on I2NSF Charter

Ok.

Nits:
- first paragraph:

- second last paragraph:
s/RFCs of/RFCs or

-- Flemming

Thanks

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 27 Aug 2015 18:13:25 -0400

On 8/27/15 4:27 PM, Linda Dunbar wrote:
> *Sent:* Thursday, August 27, 2015 2:53 PM
> *Subject:* Re: Further clarification and explanations to I2NSF charter 
> has been added to the I2NSF Wiki Q&A (was RE: [I2nsf] Consensus call 
> on I2NSF Charter
>
> Thanks Linda
>
> large portion of current NSFs (e.g. it's commonly used by FWs and 
> ADCs) - is that intentional ?
>
> [Linda] This is not my intention. I don’t remember who put the last 
> clause in (i.e. without modification to the packet due to the 
> inspection process (MAC rewrites, TTL decrement action; even NAT would 
> be outside the inspection process).. I can pull the mailing list if it 
> ok to remove the last clause.
>
>
>
Ok - we should probably change the Q&A on logging then.

> Also, a couple of my questions below still seem to be open, but there 
> is a parallel exchange with Kathleen on some of those, so maybe we can 
> resolve them there.
>
> [Linda] do you mean the questions like “why framework, use cases may 
> not be published as RFCs”? Can you help me out with the questions?
>
>
I believe Kathleen clarified the RFC publication part.

The main one I'm still not clear on is the types of NSFs that are in/out 
of scope. Providing an exact definition of those is not easy though, 
since the lines are often blurred (per my DDoS example in the e-mail 
below). What may work better is simply listing the ones that are 
explicitly known to be in scope (which the current charter text 
essentially does), but leave it open for further WG discussion as to 
what other ones (if any) may be in scope as well (perhaps with a phased 
approach with additional milestones added for those later on).

The other ones were mainly around calling out the basic framework 
(client/security controller/NSF and the layers between them) as part of 
the charter and clarification of simple vs abstract/sophisticated 
policies. With the current charter text, they are both open to 
interpretation (and hence further debate and subsequent speficiation) 
IMO, but maybe that's not a bad thing and the WG should indeed spend 
more time on that once it's formed ?

Thanks

-- Flemming

>     I have updated the Q&A on the I2NSF Wiki to clarify the questions
>     you have:
>     https://sites.google.com/site/interface2nsf/i2nsf-q-a/i2nsfqa
>
>     *Cc:* [email-masked] <mailto:[email-masked]>
>         catching those typos (corrected on the I2NSF wiki now). We
>         really need the fresh set of eyes to look at it.
>
>         You stated:
>
>         multiple entities..."; does this imply a 1:N (direct)
>         monitoring relationship ?
>
>         [Linda] The intent is to describe a scenario that a NSF may
>         send different outputs to different entities. For example,
>         some statistics report to “Analytics system”, “rule query” to
>     "The NSFs may contain a multitude of features and functions, each
>     of which can be monitored by a different entity"
>
>     or something like that.
>
>
>
>
>     Apologies for joining the discussion late - just got back from
>     PTO. In any case, please find some additional comments on the
>     proposed charter below (some more substantial than others):
>
>     - The first paragraph starts out by defining what an NSF is, and
>     we can argue about some of the points in there for various
>     security functions (e.g. I may want to detect normal network
>     behavior to establish a baseline, which does not seem to be
>     covered by the current definition).
>
>     [Linda] Over the course of I2NSF (about a year), we have gone
>     through a long debate on what NSFs should be considered by IETF
>     I2NSF. As the result of the long debate, we use the definition to
>     classify a set of functions to be considered for IETF I2NSF (then
>     further narrowing down to Flow-based NSFs).
>
>     The function you described, i.e. detecting normal network behavior
>     to establish a baseline is not in the scope of I2NSF, even though
>     this function can also be "provided and consumed in increasingly
>     diverse environments".
>
>     Ok - the part about "detect unwanted network activity" is fairly
>     broad though, and I'm not sure how you detect unwanted activity
>     without looking at all activity (which is what triggered my
>     original question).
>
>
>
>     I don't think that will be a productive discussion though, nor is
>     it necessary. Instead, I'd suggest we are not overly prescriptive,
>     but rather view these as possible NSF features, and supplement
>     them with some actual product examples (e.g. FW, NGFW, IPS, etc.).
>     Similarly, since we limit our scope to "flow-based NSFs", we may
>     want to make that clear here. An example of a security function
>     that would *not* be in scope may be helpful too.
>
>     factor can be provided physical box or virtualized format. Some
>     form factors, i.e. devices or VM, can provide multiple
>     “functions”. Do you think the sentences in the third paragraph is
>     good enough to describe what you want?
>
>     (IPS/IDS), Web filtering, flow filtering, deep packet inspection,
>     or pattern matching and remediation.” /
>
>     The examples here are clear; I'm less clear on what else might be
>     in scope. For example, would a DDoS detection and mitigation
>     system be in scope (keeping in mind it may use a combination of
>     packet inspection and telemetry-based detection and mitigation and
>     that establishing a "normal" baseline is often part of the
>     operation) ?
>
>
>
>     controller" that interacts with the "NSF". If I understand
>     correctly, the security controller implements the "Service Layer"
>     and the NSF implements the "Capability Layer". Furthermore, we
>     have "clients" that interact with the security controller to
>     implement policies (by leveraging the service layer). If so, it
>     would be good to clarify this taxonomy earlier in the charter. If
>     not, then I probably need some clarifications in the text.
>
>     There could be multiple of them, each responsible for one type of
>     NSF (i.e. managing the instances of the NSFs).
>
>     “Capability Layer”. For example: client can specify the rules
>     without specify which instances of the NSF. The “Controller”
>     manage the instances, as described by The figure in I2NSF
>     Framework document:
>
>     Ok - this basic framework seems to be foundational to the
>     structure of the work the group is doing. If so, I think it would
>     be helpful to outline it (verbally) in the charter.
>
>
>
>     - In the definition of the "Capability Layer", there is a
>     statement about "rules...of NSFs have to be implementable by most
>     NSFs". Do you mean all NSFs or NSFs of a given type (I assume we
>     have different types of NSFs) ?
>
>     [Linda] yes.
>
>     without further definition; I'm not sure where we draw that line
>     or how to do that in the charter; maybe clarifying that part needs
>     to be a deliverable ?
>
>     (they seem to set the stage for several other deliverables and
>     hence are relevant for consumers of the information and data
>     models later on) ?
>
>     [Linda] The WG group may decide to publish them as RFC or not
>     later. But the charter doesn’t specify which way. That is how IESG
>     wanted.
>
>     Ok.
>
>
>     - The part about I2NSF providing a "discussion forum for
>     Informational drafts on.....[more complex Service Layer
>     policies]..." is confusing to me. The work seems to be pursued
>     outside the WG, so there are no deliverables and presumably no
>     agenda time will be allocated either.
>
>     [Linda] this is to address the information documents that describe
>     the I2NSF demo, open source or interoperability initiatives that
>     are conducted outside the WG. E.g
>     Ok - thanks for the pointer, however from a WG point of view, I'm
>     not clear on what it means to have a discussion forum and what, if
>     anything, the WG will do with it (e.g. discuss such drafts as part
>     of meetings, etc) ?
>
>
>
>     It's also not clear to me that we can/should state that such
>     documents would be Informational. We may decide that we need some
>     procedures for how to define such documents, have designated
>     experts, a directorate, etc. to review them etc. I'm guessing this
>     is all a bit premature though, but again, we may want to note that
>     as an issue in the charter that the WG needs to resolve at some point.
>
>     communications, to detect unwanted network activity, and to block
>     or at least the mitigate effects of unwanted activity. 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.  Similarly, service providers
>     may offer their customers network security services that are
>     enforced by multiple security products and/or functions from
>     different vendors. NSFs may be provided by physical and/or
>     virtualized infrastructure. 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.
>
>     >
>
>     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.
>
>     specify rules (by a single controller at the first phase), query,
>     and monitor NSFs by one or more management entities.  The initial
>     phase of I2NSF will only consider one single controller that can
>     specify or change rules to NSFs because multi-headed control
>     requires the coordination to avoid potential conflict of rules.
>     The NSFs can be monitored by multiple entities, but the database
>     update and synchronization among multiple management entities are
>     out of scope for I2NSF. As there are many different security
>     vendors supporting different features and functions on their
>     devices, I2NSF will focus on flow-based NSFs that provide
>     treatment to packets/flows, such as Intrusion Protection/Detection
>     System (IPS/IDS), Web filtering, flow filtering, deep packet
>     inspection, or pattern matching and remediation.
>
>     >
>
>     > monitor) of NSFs have to be implementable by most NSFs. I2NSF
>     will standardize a set of interfaces by which a security
>     policies according to the various capabilities provided by the
>     I2NSF capability Layer.  The I2NSF Service Layer also allows the
>     client to monitor the client specific policies.
>
>     >
>
>     handle issues like multi-tenancy and the choice between available
>     NSFs for a given policy.
>
>     clients. Expressing policies in ways other than the model used by
>     the Capability Layer is out of scope.
>
>     drafts on data models, APIs, etc. that demonstrate how more
>     complex Service Layer policies and formats may be translated to
>     Capability Layer functions.  Such documents would be pursued
>     outside the WG.
>
>     >
>
>     > 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
>     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.
>
>     >
>
>     reference as a living list to track and record discussions: the WG
>     may decide to not publish this document as an RFC.
>
>     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.
>
>     Information Model to describe the control and monitoring of
>     flow-based NSFs.
>
>     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.
>
>     >
>
>     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

---

From: Tobias Gondrom <[email-masked]>
Date: Sun, 30 Aug 2015 19:24:00 +0200

I agree.
Some comments inline.
Best, Tobias

> This is a bit too detailed for the charter in my opinion.  Of others think this is helpful, please speak up.  This should be clear in the framework draft though.

I agree that this does not need to go into the charter. It should be 
discussed in a draft.

> Ok, since this isn't a big deal, let's leave it as-is.

Yes, just leave as-is.

>> Agreed, so I would suggest it becomes one of the tasks of the WGs to define that.

Agree.

Best regards and looking forward to I2NSF.

Tobias