Subject: [I2nsf] Benoit Claise's No Objection on charter-ietf-i2nsf-00-04: (with COMMENT)

From: "Benoit Claise" <[email-masked]>
Date: Thu, 03 Sep 2015 06:32:26 -0700

Benoit Claise has entered the following ballot position for
charter-ietf-i2nsf-00-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-i2nsf/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Worth a follow up, at least.

Disclaimer: I have not attended the BOF, neither followed the mailing
list, and not read any documents.

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

If I take this simple architecture:

		application
		    |
                controller
		|    |    |
              NSF   NSF  NSF
		|    |    |  |   |   |
                 Network

Is this your way to say that you want to standardize the north bound
interface of a controller and/or NSF?
I believe the charter should clearly mention which interface(s) I2NSF
wants to specify.
For my information, I guess that: 
1. the NSF south bound interfaces would remain proprietary
2. the NSF vendors will not open their full APIs
Am I right?

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

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

Can you provide an example of "controlling and monitoring".
Is this about: starting up, monitoring, and shutting down a virtualized
N(S)F?
Or more such as: this flow should be redirected to this IPS (a-la SFC)?
Or more such as: this traffic/flow should be inspected by IPS

Discussing with Kathleen, it seems all of them. It was not too clear to
me.

- 
A lot of architectural components for a charter: 
I2NSF Capability Layer, I2NSF Service Layer, Simple Service Layer
And you lost me with: 
    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.

This goes back to my previous point

- Let's talk about the chance of success of this potential WG. I'll trust
Kathleen's judgment here. However let me share my thoughts: With this
type of charter, the IETF moves out of its comfort zone, and enters the
territory where (opensource) code will prevail versus consensus-based
standards that take too long to be produced. So the message behind the
last paragraph is important.

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 3 Sep 2015 14:57:26 +0000

Benoit,

Replies to your comments are inserted below:

-----Original Message-----
From: I2nsf [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Thursday, September 03, 2015 8:32 AM
To: The IESG
Cc: [email-masked]
Subject: [I2nsf] Benoit Claise's No Objection on charter-ietf-i2nsf-00-04: (with COMMENT)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

Disclaimer: I have not attended the BOF, neither followed the mailing list, and not read any documents.

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

                application
                    |
                controller
                |    |    |
              NSF   NSF  NSF
                |    |    |  |   |   |
                 Network

Is this your way to say that you want to standardize the north bound interface of a controller and/or NSF?

[Linda] Only Simple "North Bound Interface" (I2NSF calls it Simple Service Layer) is included in the charter. "Simple" means that they can be directly translated to capability layer rules with simple mapping, e.g. Simple Service Layer command may not explicitly state which instantiations of NSF, may have customer ID that can be translated to some tags carried by packets.  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.

I believe the charter should clearly mention which interface(s) I2NSF wants to specify.
For my information, I guess that:
1. the NSF south bound interfaces would remain proprietary 2. the NSF vendors will not open their full APIs Am I right?

[Linda] the NSF vendors will need an adapter that translates what I2NSF specified to their own APIs. Here is an example, different NSF vendors translate the I2NSF defined interface to their specific ones.

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

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

Can you provide an example of "controlling and monitoring".
Is this about: starting up, monitoring, and shutting down a virtualized N(S)F?
[Linda] Control Example: Application gives positive session knowledge for white listing flows that are encrypted. This means FW, IPS etc can be programmed on what is  a trusted flow via I2NSF for a specific time period (e.g. during conference call).
Monitor Example: The NSF sends its statistics to Analytic tool to analyze new threats.

Or more such as: this flow should be redirected to this IPS (a-la SFC)?
[Linda] The NSFs includes the IPS. I2NSF is to dynamic sending new rules or new signature files to IPS.

Or more such as: this traffic/flow should be inspected by IPS
[Linda] I2NSF is to send different Signature Files for different Traffic/Flow at real time.

Discussing with Kathleen, it seems all of them. It was not too clear to me.

-
A lot of architectural components for a charter:
I2NSF Capability Layer, I2NSF Service Layer, Simple Service Layer And you lost me with:
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.

[Linda]The "Simple Service Layer" allow Client to send rules or signature file without specifying which instances of NSF.

- Let's talk about the chance of success of this potential WG. I'll trust Kathleen's judgment here. However let me share my thoughts: With this type of charter, the IETF moves out of its comfort zone, and enters the territory where (opensource) code will prevail versus consensus-based standards that take too long to be produced. So the message behind the last paragraph is important.

[Linda] I2NSF will focus on the concrete rules/signature files to NSFs, and hiding the NSF instantiations.

Linda

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

---

From: Benoit Claise <[email-masked]>
Date: Thu, 3 Sep 2015 18:24:01 +0200

On 03/09/2015 16:57, Linda Dunbar wrote:
> email addresses included in the To and CC lines. (Feel free to cut 
> this introductory paragraph, however.)
> [Linda] Only Simple "North Bound Interface"
[Benoit] North bound of what? NSF, controller, or both?
 From your last answer, I understand only the NSF North Bound Inteface.
Please make it clear in the charter text.
> (I2NSF calls it Simple Service Layer) is included in the charter. 
> “Simple” means that they can be directly translated to capability 
> layer rules with simple mapping, e.g. Simple Service Layer command may 
> not explicitly state which instantiations of NSF, may have customer ID 
> that can be translated to some tags carried by packets. 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.
> 1. the NSF south bound interfaces would remain proprietary 2. the NSF 
> vendors will not open their full APIs Am I right?
> [Linda] the NSF vendors will need an adapter that translates what 
> I2NSF specified to their own APIs. Here is an example, different NSF 
> vendors translate the I2NSF defined interface to their specific ones.
> - "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.".
> "I2NSF will focus on flow-based NSFs that provide treatment to 
> packets/flows, such as Intrusion Protection/Detection System 
> pattern matching and remediation."
> [Linda] Control Example: Application gives positive session knowledge 
> for white listing flows that are encrypted. This means FW, IPS etc can 
> be programmed on what is  a trusted flow via I2NSF for a specific time 
> period (e.g. during conference call).
[Benoit] So your answer is that the charter covers all 3 cases. It was 
not clear to me from the charter text.
> 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.
> [Linda]The “Simple Service Layer” allow Client to send rules or 
> signature file without specifying which instances of NSF.
[Benoit] It still doesn't help me with "Only the Simple Service Layer 
policies that are modeled as closely as possible on the Capability Layer 
are within the scope.", which appears to be an important sentence.
> - Let's talk about the chance of success of this potential WG. I'll 
> trust Kathleen's judgment here. However let me share my thoughts: With 
> this type of charter, the IETF moves out of its comfort zone, and 
> enters the territory where (opensource) code will prevail versus 
> consensus-based standards that take too long to be produced. So the 
> message behind the last paragraph is important.
Regards, Benoit
> [email-masked] <mailto:[email-masked]>

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 3 Sep 2015 16:42:53 +0000

Beniot:

Answers to your questions are inserted below:

From: Benoit Claise [mailto:[email-masked]]
Sent: Thursday, September 03, 2015 11:24 AM
To: Linda Dunbar; The IESG
Cc: [email-masked]
Subject: Re: [I2nsf] Benoit Claise's No Objection on charter-ietf-i2nsf-00-04: (with COMMENT)

-----Original Message-----
From: I2nsf [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Thursday, September 03, 2015 8:32 AM
To: The IESG
Cc: [email-masked]<mailto:[email-masked]>
Subject: [I2nsf] Benoit Claise's No Objection on charter-ietf-i2nsf-00-04: (with COMMENT)

                application
                    |
                controller
                |    |    |
              NSF   NSF  NSF
                |    |    |  |   |   |
                 Network

[Linda] It should be both because "Security controller" is a conceptual entity, meaning an entity to send implementable rules (capability layer) to the NSFs and their instantiations. There could be multiple "security controllers", each responsible for one type of NSF (i.e. managing the instances of the NSFs). Some NSFs can receive I2NSF commands directly (i.e. I2NSF is the North Bound to NSF; the "capability layer" commands), some NSFs (especially the instances) may need the "controller" to intercept the I2NSF commands (the "service layer commands that can be mapped to capability layer commands). As shown in the example below:

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

(I2NSF calls it Simple Service Layer) is included in the charter. "Simple" means that they can be directly translated to capability layer rules with simple mapping, e.g. Simple Service Layer command may not explicitly state which instantiations of NSF, may have customer ID that can be translated to some tags carried by packets. 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.

Or more such as: this traffic/flow should be inspected by IPS
[Linda] I2NSF is to send different Signature Files for different Traffic/Flow at real time.
[Benoit] So your answer is that the charter covers all 3 cases. It was not clear to me from the charter text.

[Linda] What do you mean by "3 cases"?  I2NSF is for clients to specify Rules (which include what signature file for what traffic).

-

[Linda]The "Simple Service Layer" allow Client to send rules or signature file without specifying which instances of NSF.
[Benoit] It still doesn't help me with "Only the Simple Service Layer policies that are modeled as closely as possible on the Capability Layer are within the scope.", which appears to be an important sentence.

[Linda] This sentence was proposed by Sam Hartman. To make sure that I2NSF doesn't go unbound, we put in explicit bullets for the "Simple Service Layer":

Since there could be many depths or types of Service Layer policies, the following bullets further clarify the scope of I2NSF:

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

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

*       The translation mechanism/methods from Service Layer policies to Capability layer commands 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 Working Group.

Linda

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 4 Sep 2015 11:01:06 -0400

Benoit,

Do you have any text suggestions or additional questions?

Thank you,
Kathleen

On Thu, Sep 3, 2015 at 12:42 PM, Linda Dunbar <[email-masked]>
wrote:

> *From:* Benoit Claise [mailto:[email-masked]]
> *Sent:* Thursday, September 03, 2015 11:24 AM
> *To:* Linda Dunbar; The IESG
> *Cc:* [email-masked]
> *Subject:* Re: [I2nsf] Benoit Claise's No Objection on
> charter-ietf-i2nsf-00-04: (with COMMENT)
>
>
>
> From: I2nsf [mailto:[email-masked] <[email-masked]>] On
> Behalf Of Benoit Claise
> [Linda] It should be both because “Security controller” is a conceptual
> entity, meaning an entity to send implementable rules (capability layer) to
> the NSFs and their instantiations. There could be multiple “security
> controllers”, each responsible for one type of NSF (i.e. managing the
> instances of the NSFs). Some NSFs can receive I2NSF commands directly (i.e.
> I2NSF is the North Bound to NSF; the “capability layer” commands), some
> NSFs (especially the instances) may need the “controller” to intercept the
> I2NSF commands (the “service layer commands that can be mapped to
> capability layer commands). As shown in the example below:
>
>
>
> (I2NSF calls it Simple Service Layer) is included in the charter. “Simple”
> means that they can be directly translated to capability layer rules with
> simple mapping, e.g. Simple Service Layer command may not explicitly state
> which instantiations of NSF, may have customer ID that can be translated to
> some tags carried by packets. 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.
>
>
>
>
>
> [Linda] the NSF vendors will need an adapter that translates what I2NSF
> specified to their own APIs. Here is an example, different NSF vendors
> translate the I2NSF defined interface to their specific ones.
>
>
>
>
>
>
>
>
>
> models for controlling and monitoring aspects of physical and virtual
> NSFs.".
>
>
>
> packets/flows, such as Intrusion Protection/Detection System (IPS/IDS), Web
> filtering, flow filtering, deep packet inspection, or pattern matching and
> remediation."
>
>
>
> [Linda] Control Example: Application gives positive session knowledge for
> white listing flows that are encrypted. This means FW, IPS etc can be
> programmed on what is  a trusted flow via I2NSF for a specific time period
> (e.g. during conference call).
>
> [Linda] What do you mean by “3 cases”?  I2NSF is for clients to specify
> Rules (which include what signature file for what traffic).
>
>
>
>
>
>
>
>
>
> o Only the Simple Service Layer policies that are modeled as closely as
> [Linda]The “Simple Service Layer” allow Client to send rules or signature
> file without specifying which instances of NSF.
>
> [Linda] This sentence was proposed by Sam Hartman. To make sure that I2NSF
> doesn’t go unbound, we put in explicit bullets for the “Simple Service
> Layer”:
>
>
>
> *Since there could be many depths or types of Service Layer policies, the
> following bullets further clarify the scope of I2NSF:*
>
> ·       *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.*
>
> ·       *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. *
>
> ·       *The translation mechanism/methods from Service Layer policies to
> Capability layer commands 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 Working Group.*
>
>
>
>
>
>
>
> Kathleen's judgment here. However let me share my thoughts: With this type
> of charter, the IETF moves out of its comfort zone, and enters the
> standards that take too long to be produced. So the message behind the last
> paragraph is important.
>
>
>
> [email-masked]

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 8 Sep 2015 11:48:39 -0400

Hi Benoit,

Do you have any text suggestions or additional questions?  I'd like to get
this wrapped up as soon as possible and onto the next review phase.

Thank you,
Kathleen

On Fri, Sep 4, 2015 at 11:01 AM, Kathleen Moriarty <
[email-masked]> wrote:

>> “Simple” means that they can be directly translated to capability layer
>> rules with simple mapping, e.g. Simple Service Layer command may not
>> explicitly state which instantiations of NSF, may have customer ID that can
>> be translated to some tags carried by packets. Such a Simple Service Layer
>> will enable a security controller to handle issues like multi-tenancy and
>> [Linda] This sentence was proposed by Sam Hartman. To make sure that
>> I2NSF doesn’t go unbound, we put in explicit bullets for the “Simple
>> Service Layer”:
>>
>>
>>
>> ·       *The translation mechanism/methods from Service Layer policies
>> to Capability layer commands 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 Working
>> Group.*
>>
>>
>>
>>
>>
>>
>>

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 8 Sep 2015 17:30:50 -0400

Hello,

Benoit and I just chatted and he has suggestions for a few changes int
he charter to further clarify scope.  I agree with the changes as the
more explicit text matches my previous understanding and may have been
reading the charter with that in mind.  The proposals are from the
discussions between Linda and Benoit.  I'd like to make sure they are
agreeable and will make the updates.

1. In the second paragraph of the charter, after the first sentence
some clarifying text would be added.

Change from:

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.

Change to:

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,
enabling clients to specify rulesets. 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.

2. The simple Service Layer describes this functionality from the text
in item 1.  Benoit found the expanded text n this to be helpful and I
agree with him on that point.  The proposed changes are to replace
"Simple" with "simple" and to further define this so we don't run into
trouble working on this after the WG is formed.  Change from:

    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.

Change to:

    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.  Simple Service
Layer policies can be directly translated to capability layer rules
with a direct mapping that might include a customer ID to be
translated to tags carried by packets, but might not specify the NSF.
This flexibility in the simple Service Layer enables a security
controller to handle issues like multi-tenancy and the choice between
available NSFs for a given policy.

3. Optional (I'm okay if this doesn't change since there is an option
to not publish this draft), but the change doesn't hurt as this could
be done through IANA or other means.  Change from:

    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.

Change to:

    o Specify the characteristics and behavior of NSFs to be using a
vendor-neutral
vocabulary without requiring the NSFs themselves to be standardized.

Please let me know if these changes are agreeable and I'll go ahead
and update the charter.

Thank you,
Kathleen

On Thu, Sep 3, 2015 at 12:42 PM, Linda Dunbar <[email-masked]> wrote:
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this
> I2NSF is the North Bound to NSF; the “capability layer” commands), some NSFs
> (especially the instances) may need the “controller” to intercept the I2NSF
> commands (the “service layer commands that can be mapped to capability layer
> commands). As shown in the example below:
>
>
>
> policies that are modeled as closely as possible on the Capability Layer are
> within the scope.", which appears to be an important sentence.
>
> Since there could be many depths or types of Service Layer policies, the
> following bullets further clarify the scope of I2NSF:
>
> ·       Only the Simple Service Layer policies that are modeled as closely
> as possible on the Capability Layer are within the scope.  Such a Simple
> ·       I2NSF will not specify abstract or sophisticated policies from
> Capability Layer is out of scope.
>
> ·       The translation mechanism/methods from Service Layer policies to
> Capability layer commands are out of scope for I2NSF.
>
> ·       However, I2NSF will provide a discussion forum for Informational
> Layer policies and formats may be translated to Capability Layer functions.
> Such documents would be pursued outside the Working Group.
>
>
>
>
>
>
>
> of charter, the IETF moves out of its comfort zone, and enters the territory
> where (opensource) code will prevail versus consensus-based standards that
> take too long to be produced. So the message behind the last paragraph is
> important.
>
>
>

-- 

Best regards,
Kathleen

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 8 Sep 2015 21:49:15 +0000

Kathleen and Benoit, 

Thank you very much for the suggested changes. The proposed changes for Bullet 1) are 2) below make the I2NSF charter more clear. 100% agree. 

For the suggested change for Bullet 3), I have some questions inserted below: 

-----Original Message-----
From: Kathleen Moriarty [mailto:[email-masked]] 
Sent: Tuesday, September 08, 2015 4:31 PM
To: Linda Dunbar
Cc: Benoit Claise; The IESG; [email-masked]
Subject: Re: [I2nsf] Benoit Claise's No Objection on charter-ietf-i2nsf-00-04: (with COMMENT)

Hello,

Benoit and I just chatted and he has suggestions for a few changes int he charter to further clarify scope.  I agree with the changes as the more explicit text matches my previous understanding and may have been reading the charter with that in mind.  The proposals are from the discussions between Linda and Benoit.  I'd like to make sure they are agreeable and will make the updates.

1. In the second paragraph of the charter, after the first sentence some clarifying text would be added.

Change from:

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.

Change to:

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, enabling clients to specify rulesets. 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.

2. The simple Service Layer describes this functionality from the text in item 1.  Benoit found the expanded text n this to be helpful and I agree with him on that point.  The proposed changes are to replace "Simple" with "simple" and to further define this so we don't run into trouble working on this after the WG is formed.  Change from:

Change to:

    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.  Simple Service Layer policies can be directly translated to capability layer rules with a direct mapping that might include a customer ID to be translated to tags carried by packets, but might not specify the NSF.
This flexibility in the simple Service Layer enables a security controller to handle issues like multi-tenancy and the choice between available NSFs for a given policy.

3. Optional (I'm okay if this doesn't change since there is an option to not publish this draft), but the change doesn't hurt as this could be done through IANA or other means.  Change from:

    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.

Change to:

    o Specify the characteristics and behavior of NSFs to be using a vendor-neutral vocabulary without requiring the NSFs themselves to be standardized.

[Linda] The purpose of specifying the "characteristics and behavior" is for "security controller" or "manager" to have a common base to choose the appropriate NSFs (by different vendors) that can fulfill the requests requested by clients. The original text suggests that those characteristics are registered at a place (IANA is one place). Is the intent of the new text to leave it open on where to register those characteristics? 

Thank you, 

Linda

Please let me know if these changes are agreeable and I'll go ahead and update the charter.

Thank you,
Kathleen

On Thu, Sep 3, 2015 at 12:42 PM, Linda Dunbar <[email-masked]> wrote:
> [Linda] It should be both because “Security controller” is a 
> conceptual entity, meaning an entity to send implementable rules 
> (capability layer) to the NSFs and their instantiations. There could 
> be multiple “security controllers”, each responsible for one type of 
> NSF (i.e. managing the instances of the NSFs). Some NSFs can receive I2NSF commands directly (i.e.
> I2NSF is the North Bound to NSF; the “capability layer” commands), 
> some NSFs (especially the instances) may need the “controller” to 
> intercept the I2NSF commands (the “service layer commands that can be 
> mapped to capability layer commands). As shown in the example below:
>
>
>
> means that they can be directly translated to capability layer rules 
> with simple mapping, e.g. Simple Service Layer command may not 
> explicitly state which instantiations of NSF, may have customer ID 
> [Linda] What do you mean by “3 cases”?  I2NSF is for clients to 
> specify Rules (which include what signature file for what traffic).
>
>
>
>
>
>
>
>
>
> issues like multi-tenancy and the choice between available NSFs for a given policy.
>
>
>
> policies that are modeled as closely as possible on the Capability 
> Layer are within the scope.", which appears to be an important sentence.
>
> Since there could be many depths or types of Service Layer policies, 
> the following bullets further clarify the scope of I2NSF:
>
> issues like multi-tenancy and the choice between available NSFs for a given policy.
>
> drafts on data models, APIs, etc. that demonstrate how more complex 
> Service Layer policies and formats may be translated to Capability Layer functions.

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 8 Sep 2015 17:58:32 -0400

Hi Linda,

Thank you for the quick response.  I'll just respond to your one
question below and perhaps you have alternate wording to suggest.

> [Linda] The purpose of specifying the "characteristics and behavior" is for "security controller" or "manager" to have a common base to choose the appropriate NSFs (by different vendors) that can f…

We could leave this as-is, but the main point of the change was to not
specify IANA.  The sentence was awkward once that was removed, so I
may have altered it too much.  It's fine for I2NSF to use IANA, but
it's also fine if they chose other options, as such it may be better
to leave that out of the charter.  But there is flexibility on this
one.

Thank you,
Kathleen

-- 

Best regards,
Kathleen

---

From: "Zarny, Myo" <[email-masked]>
Date: Tue, 8 Sep 2015 18:23:46 -0400

I’m not clear on #2. Please see in line.

Myo

-----Original Message-----
From: I2nsf [mailto:[email-masked]] On Behalf Of Kathleen Moriarty
Sent: 8 September 2015 5:31 PM
To: Linda Dunbar
Cc: Benoit Claise; [email-masked]; The IESG
Subject: Re: [I2nsf] Benoit Claise's No Objection on charter-ietf-i2nsf-00-04: (with COMMENT)

Hello,

Change from:

Change to:

Change to:

MZ:  I think the last sentence is redundant!? I don’t get the first sentence either. Would something like below work?

Only the simplest Service Layer policies modeled as closely to the Capability Layer functions are within scope. A simple Service Layer may enable security controllers to handle such issues as multi-tenancy, policy-based NSF selection, etc. Simple Service Layer policies may be translated to Capability Layer rules, for example, by employing a mapping service that translates Service Layer “Customer IDs” to Capability Layer packet-level “tags”.

I still find the first sentence [deliberately] vague.

Change to:

    o Specify the characteristics and behavior of NSFs to be using to use a vendor-neutral vocabulary without requiring the NSFs themselves to be standardized.

Thank you,
Kathleen

--

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 8 Sep 2015 18:28:22 -0400

Thank you, I actual just noticed that I had neglected to remove a
sentence and was changing it to the included text.

On Tue, Sep 8, 2015 at 6:23 PM, Zarny, Myo <[email-masked]> wrote:
> Benoit and I just chatted and he has suggestions for a few changes int he
> charter to further clarify scope.  I agree with the changes as the more
> explicit text matches my previous understanding and may have been reading
> the charter with that in mind.  The proposals are from the discussions
> between Linda and Benoit.  I'd like to make sure they are agreeable and will
> make the updates.
>
> 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.
>
> Change to:
>
> 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,
> enabling clients to specify rulesets. 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.
>
>
> 2. The simple Service Layer describes this functionality from the text in
> item 1.  Benoit found the expanded text n this to be helpful and I agree
> with him on that point.  The proposed changes are to replace "Simple" with
> "simple" and to further define this so we don't run into trouble working on
> this after the WG is formed.  Change from:
>
> possible on the Capability Layer are within the scope.  Such a simple
> Simple Service Layer policies can be directly translated to capability layer
> rules with a direct mapping that might include a customer ID to be
> This flexibility in the simple Service Layer enables a security controller
> to handle issues like multi-tenancy and the choice between available NSFs
> for a given policy.
>
> Only the simplest Service Layer policies modeled as closely to the
> Capability Layer functions are within scope. A simple Service Layer may
> enable security controllers to handle such issues as multi-tenancy,
> policy-based NSF selection, etc. Simple Service Layer policies may be
> translated to Capability Layer rules, for example, by employing a mapping
> service that translates Service Layer “Customer IDs” to Capability Layer
> packet-level “tags”.

    o Only the simple Service Layer policies that are modeled as
closely as possible on the Capability Layer are within the scope.
Simple Service Layer policies can be directly translated to capability
layer rules with a direct mapping that might include a customer ID to
be translated to tags carried by packets, but might not specify the
NSF.  This flexibility in the simple Service Layer enables a security
controller to handle issues like multi-tenancy and the choice between
available NSFs for a given policy.

I think this version may be a bit more clear to address Benoit's concern.

Thanks for spotting the other editorial issue.  I think Linda is
looking at alternate wording, so I'll hold off on that one.

Best regards,
Kathleen

> 3. Optional (I'm okay if this doesn't change since there is an option to not
> publish this draft), but the change doesn't hurt as this could be done
> through IANA or other means.  Change from:
>
>     o Specify the characteristics and behavior of NSFs to use a
> vendor-neutral vocabulary without requiring the NSFs themselves to be
> standardized.
>
>
>
>

-- 

Best regards,
Kathleen

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 9 Sep 2015 17:10:42 +0000

Kathleen, 

For the Bullet 3), how about the text:

- Specify 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, so that "security controller" or "manager" have a common base to choose the appropriate NSFs (by different vendors) that can fulfill the requests requested by clients.

Linda

-----Original Message-----
> [Linda] The purpose of specifying the "characteristics and behavior" is for "security controller" or "manager" to have a common base to choose the appropriate NSFs (by different vendors) that can f…

We could leave this as-is, but the main point of the change was to not specify IANA.  The sentence was awkward once that was removed, so I may have altered it too much.  It's fine for I2NSF to use IANA, but it's also fine if they chose other options, as such it may be better to leave that out of the charter.  But there is flexibility on this one.

Thank you,
Kathleen

>>       + - - - - - - - - - - - - - - - +  + - - - - - - - - - - - - - 
>> -
>> - +
>>
>> for white listing flows that are encrypted. This means FW, IPS etc 
>> can be programmed on what is  a trusted flow via I2NSF for a specific 
>> time period (e.g. during conference call).
>>
>> [Benoit] So your answer is that the charter covers all 3 cases. It 
>> was not clear to me from the charter text.
>>
>>
>>
>> trust Kathleen's judgment here. However let me share my thoughts: 
>> With this type of charter, the IETF moves out of its comfort zone, 
>> and enters the territory where (opensource) code will prevail versus 

-- 

Best regards,
Kathleen

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 9 Sep 2015 17:18:57 +0000

Kathleen and Myo, 

The version Kathleen suggested for Bullet 2) is good to me.  

Thank you very much. 

Linda

-----Original Message-----
From: Kathleen Moriarty [mailto:[email-masked]] 
Sent: Tuesday, September 08, 2015 5:28 PM
To: Zarny, Myo
Cc: Linda Dunbar; Benoit Claise; [email-masked]; The IESG
Subject: Re: [I2nsf] Benoit Claise's No Objection on charter-ietf-i2nsf-00-04: (with COMMENT)

Thank you, I actual just noticed that I had neglected to remove a sentence and was changing it to the included text.

On Tue, Sep 8, 2015 at 6:23 PM, Zarny, Myo <[email-masked]> wrote:
> The goal of I2NSF is to define a set of software interfaces and data 
> 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.
>
> Change to:
>
> The goal of I2NSF is to define a set of software interfaces and data 
> NSFs, enabling clients to specify rulesets. If the working group finds 
> it necessary to work on an information model before the data models, 
>     o Only the Simple Service Layer policies that are modeled as 
> 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.
>
> Change to:
>
> 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.
> be translated to tags carried by packets, but might not specify the NSF.
> MZ:  I think the last sentence is redundant!? I don’t get the first 
> sentence either. Would something like below work?
>
> Capability Layer functions are within scope. A simple Service Layer 
> may enable security controllers to handle such issues as 
> multi-tenancy, policy-based NSF selection, etc. Simple Service Layer 
> policies may be translated to Capability Layer rules, for example, by 
> employing a mapping service that translates Service Layer “Customer 
> IDs” to Capability Layer packet-level “tags”.

    o Only the simple Service Layer policies that are modeled as closely as possible on the Capability Layer are within the scope.
Simple Service Layer policies can be directly translated to capability layer rules with a direct mapping that might include a customer ID to be translated to tags carried by packets, but might not specify the NSF.  This flexibility in the simple Service Layer enables a security controller to handle issues like multi-tenancy and the choice between available NSFs for a given policy.

Thanks for spotting the other editorial issue.  I think Linda is looking at alternate wording, so I'll hold off on that one.

Best regards,
Kathleen

>     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.
>
> Change to:
>

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 9 Sep 2015 13:38:54 -0400

Hi Linda,

That's fine.  I was trying to remove registry as well so the group has
that as an option, but is not locked into it.  I would suggest:

Enable the characteristics and behavior of NSFs to be specified using
a vendor-neutral vocabulary without requiring the NSFs themselves to
be standardized, so that "security controller" or "manager" have a
common base to choose the appropriate NSFs (by different vendors) that
can fulfill the requests requested by clients.

Is that okay or is registry very important to the WG?  This is just so
you don't get locked into that method, even though it is likely what
will be done.

Thank you,
Kathleen

-- 

Best regards,
Kathleen

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 9 Sep 2015 18:03:51 +0000

Kathleen, 

What you suggest is good. 

Thank you, 

Linda

-----Original Message-----
From: I2nsf [mailto:[email-masked]] On Behalf Of Kathleen Moriarty
Sent: Wednesday, September 09, 2015 12:39 PM
To: Linda Dunbar
Cc: Benoit Claise; [email-masked]; The IESG
Subject: Re: [I2nsf] Benoit Claise's No Objection on charter-ietf-i2nsf-00-04: (with COMMENT)

Hi Linda,

That's fine.  I was trying to remove registry as well so the group has that as an option, but is not locked into it.  I would suggest:

Enable the characteristics and behavior of NSFs to be specified using a vendor-neutral vocabulary without requiring the NSFs themselves to be standardized, so that "security controller" or "manager" have a common base to choose the appropriate NSFs (by different vendors) that can fulfill the requests requested by clients.

Is that okay or is registry very important to the WG?  This is just so you don't get locked into that method, even though it is likely what will be done.

Thank you,
Kathleen

On Wed, Sep 9, 2015 at 1:10 PM, Linda Dunbar <[email-masked]> wrote:
>>> When responding, please keep the subject line intact and reply to 
>>> all email addresses included in the To and CC lines. (Feel free to 
>>> cut this introductory paragraph, however.)
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> -
>>>
>>> COMMENT:
>>>
>>> --------------------------------------------------------------------
>>> -
>>> -
>>>
>>>
>>>
>>> Disclaimer: I have not attended the BOF, neither followed the 
>>> mailing list, and not read any documents.
>>>
>>>
>>>
>>> intercept the I2NSF commands (the “service layer commands that can 
>>> be mapped to capability layer commands). As shown in the example below:
>>>
>>>
>>>
>>> that can be translated to some tags carried by packets. Such a 
>>> 1. the NSF south bound interfaces would remain proprietary 2. the 
>>> NSF vendors will not open their full APIs Am I right?
>>>
>>>
>>>
>>> [Linda] Control Example: Application gives positive session 
>>> knowledge for white listing flows that are encrypted. This means FW, 
>>> IPS etc can be programmed on what is  a trusted flow via I2NSF for a 
>>> specific time period (e.g. during conference call).
>>>
>>> [Benoit] It still doesn't help me with "Only the Simple Service 
>>> Layer policies that are modeled as closely as possible on the 
>>> Capability Layer are within the scope.", which appears to be an important sentence.
>>>
>>> clients. Expressing policies in ways other than the model used by 
>>> the Capability Layer is out of scope.
>>>

-- 

Best regards,
Kathleen