Subject: [I2nsf] i2nsf charter feedback

From: 🔓Dan Wing <[email-masked]>
Date: Mon, 3 Aug 2015 14:11:18 -0700

Based on https://sites.google.com/site/interface2nsf/home that I am looking at now, I have two questions,

1.  "The primary goal of I2NSF is to define an information model, a set of software interfaces and data models for controlling and monitoring aspects of physical and virtual NSFs."

Should that say "... and monitoring SECURITY aspects ...", as was in Strassner's http://www.ietf.org/mail-archive/web/i2nsf/current/msg00388.html?

Even with the edit to become "security aspects", I am uncomfortable where the line is drawn between a "security aspect" (in scope of i2nsf) and "other aspects" (out of scope of i2nsf).  For example, 'remediation' is mentioned at the end of the same paragraph, and remediation could involve sending a compromised host to a "remediation portal".  Would that steering of the user's traffic be a "security aspect" or an "other aspect", and does that answer depend on if the function is accomplished by reconfiguring network switches or if the function is internal to the NSF itself.

2. There are two places where IANA registry is mentioned, once in 'concrete work' and again in 'deliverables'.  The text differs.  Is this two registries, or one registry?  Can the charter text be clarified if these are two registries or one?

-d

---

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

Dan, 

Thank you very much for the comments. 

Can you check the latest version of the I2NSF charter and see if your concerns have been addressed? 

https://sites.google.com/site/interface2nsf/

Linda

-----Original Message-----
From: I2nsf [mailto:[email-masked]] On Behalf Of ??Dan Wing
Sent: Monday, August 03, 2015 4:11 PM
To: [email-masked]
Subject: [I2nsf] i2nsf charter feedback

-d

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

---

From: Daniel Migault <[email-masked]>
Date: Wed, 5 Aug 2015 20:37:15 +0000

Hi, 

My comments are based on the charter at: https://sites.google.com/site/interface2nsf/

Hope they help.

BR, 
Daniel

A) I agree that configuration should be out of scope. I would add the following text.

Controlling and monitoring [...] management entities. 
ADDED TEXT: Unlike configuration of NSF, I2NSF provides facilities to change and update the internal states of the NSF.
Since different security [...] 

B)
OLD CHARTER TEXT
"The I2NSF Capability Layer specifies how to control and monitor NSFs at a functional implementation level. I2NSF will standardize a set of interfaces by which a security controller can invoke, operate, and monitor NSFs."

I think we should clarify functional implementation level. My understanding is that the I2NSF Capability Layer should inform the tenants of the different available NSF as well as the various available associated options, profiles...

C)
OLD CHARTER TEXT
"The I2NSF Service Layer defines how clients' security policies may be expressed to a security controller that uses the capability layer to control and manage NSFs to implement these policies.  "

Maybe we could write:
"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 a capabilities provided by the I2NSF Capability Layer."

OLD CHARTER TEXT
"It also allows the client to monitor those policies. I2NSF will not specify how a security controller maps security service requests at the Service Layer to control and management actions at the Capability Layer, but the development of a Simple Service Layer model that is modeled as closely as possible on the Capability Layer is within 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 is not very clear to me what is in scope and is not. At least my understanding is:
I2NFS will not define how tenants' NSF requests at the Service Layer are declined in Capability Layer this is left to the controller which is implementation dependent.  Instead, I2NFS considers that tenants policies should be based on information provided by the Capability Layer. I2NSF will provide guidance based on a simple service to define a models that eases interactions between the Service Layer  and the Capability Layer.

---

From: 🔓Dan Wing <[email-masked]>
Date: Wed, 5 Aug 2015 18:02:40 -0700

> https://sites.google.com/site/interface2nsf/

1. No, it still says "controlling aspects" (second paragraph, first sentence).  It isn't clear what those aspects are.  The word 'aspects' only appears twice in the charter text.

2. Yes, the IANA stuff isn't duplicated now.  Thanks.

One other thing I just noticed, "one or more management entities."  Is i2nsf going to solve the database update and synchronization problem?  This seems complicated.  That is, does i2nsf need to support multiple management entities controlling a NSF, and does i2nsf need to tell those other management entities of changes done by another entity?

-d

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 13 Aug 2015 15:50:23 +0000

Dan, 

Sorry for the late response, I just came back from a 2-week vacation. 

Reply to your comments are inserted below:

-----Original Message-----
From: I2nsf [mailto:[email-masked]] On Behalf Of ??Dan Wing
Sent: Wednesday, August 05, 2015 8:03 PM
To: Linda Dunbar
Cc: [email-masked]
Subject: Re: [I2nsf] i2nsf charter feedback

[Linda] "Controlling aspects" is referring to "rules to be enforced for traffic traversed through the NSFs". It is emphasized here to differentiate from "device level configuration", such as the device's own network addresses, timer, ports, etc. 

[Linda] No, "Database update and synchronization" is definitely out of I2NSF scope. 
"one or more management entities" is referring to that I2NSF agent CAN get rule requests more than one entities (or I2NSF clients). 

Let me know if you have more questions. 

-d

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 13 Aug 2015 16:47:51 +0000

Daniel,

Thank you very much for the suggested charter text.
Some questions and comments are inserted below:

-----Original Message-----
From: Daniel Migault [mailto:[email-masked]]
Sent: Wednesday, August 05, 2015 3:37 PM
To: Linda Dunbar; [email-masked]; [email-masked]
Subject: RE: [I2nsf] i2nsf charter feedback

Hi,

Hope they help.

BR,
Daniel

[Linda] The last sentence of the current charter already has the sentence: " Other aspects of NSFs, such as device or network provisioning and configuration, are out of scope." Do you think it is enough? I am hesitated to put "Internal States of the NSF" in the charter, because there could be many types of interpretations depending on the background of readers, e.g. "Internal NSF memory states, Internal NSF ports states", etc. "Controlling aspects" is referring to "rules to be enforced for traffic traversed through the NSFs".

B)
OLD CHARTER TEXT

I think we should clarify functional implementation level. My understanding is that the I2NSF Capability Layer should inform the tenants of the different available NSF as well as the various available associated options, profiles...
[Linda] The sentence "functional implementation" is the result of many rounds of debate. It is trying to emphasizing that the rules (for control and monitor) to NSFs have to be implementable by most NSFs.

C)
OLD CHARTER TEXT

Maybe we could write:

[Linda] This suggestion is OK with me. I will ask Adrian since the wording was proposed by him.

OLD CHARTER TEXT

This is not very clear to me what is in scope and is not.

[Linda] The statement is to say that
-       the translation mechanism/methods from Service Layer policies to Capability layer comments is out of I2NSF scope, and
-       I2NSF will not specify abstract or sophisticated policies from clients. Only simple service layer policies that model the "capability layer" commands are in the scope of I2NSF.
-

At least my understanding is:
I2NFS will not define how tenants' NSF requests at the Service Layer are declined in

[Linda] "declined"???
 Capability Layer this is left to the controller which is implementation dependent.  Instead, I2NFS considers that tenants policies should be based on information provided by the Capability Layer. I2NSF will provide guidance based on a simple service to define a models that eases interactions between the Service Layer  and the Capability Layer.

[Linda] hope my explanation helps. Please let me know if you have more questions.

Thanks, Linda

---

From: 🔓Dan Wing <[email-masked]>
Date: Fri, 14 Aug 2015 10:36:23 -0700

On 13-Aug-2015 08:50 am, Linda Dunbar <[email-masked]> wrote:
> [Linda] "Controlling aspects" is referring to "rules to be enforced for traffic traversed through the NSFs".
> It is emphasized here to differentiate from "device level configuration", such as the device's own network addresses, timer, ports, etc. 

Yes, I agree the last sentence in that paragraph which says:
  "Other aspects of NSFs, such as device or network provisioning and configuration, are out of scope."
declares what aspects are out of scope.

But the charter text does not identify which aspects are *in scope*.

> "one or more management entities" is referring to that I2NSF agent CAN get rule requests more than one entities (or I2NSF clients). 

Can the charter make that clearer, please?

-d

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 15 Aug 2015 18:55:39 +0100

Hi Daniel, Linda,

>> C)
>> OLD CHARTER TEXT
>> "The I2NSF Service Layer defines how clients' security policies may be 
>> expressed to a security controller that uses the capability layer to control
>> and manage NSFs to implement these policies.  "
>>
>> Maybe we could write:
>> "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 a capabilities provided by the I2NSF Capability
>> Layer."
>

Thanks for checking.
Daniel's proposal works for me.
 
Cheers,
Adrian

---

From: Daniel Migault <[email-masked]>
Date: Sun, 16 Aug 2015 14:02:55 -0400

Hi Linda,

Thanks for the response and clarification. Please see my comments in line.

BR,
Daniel

On Thu, Aug 13, 2015 at 12:47 PM, Linda Dunbar <[email-masked]>
wrote:

> From: Daniel Migault [mailto:[email-masked]
> <[email-masked]>]
> My comments are based on the charter at:
> ADDED TEXT: Unlike configuration of NSF, I2NSF provides facilities to
> change and update the internal states of the NSF.
> [Linda] The last sentence of the current charter already has the sentence:
> " *Other aspects of NSFs, such as device or network provisioning and
> configuration, are out of scope.**”* Do you think it is enough? I am
> hesitated to put “Internal States of the NSF” in the charter, because there
> could be many types of interpretations depending on the background of
> readers, e.g. “Internal NSF memory states, Internal NSF ports states”, etc.
> "Controlling aspects" is referring to "rules to be enforced for traffic
> traversed through the NSFs".
>
>
[Daniel] I have no strong opinion. If it does not clarify things, then we
could leave it.

>
> B)
> OLD CHARTER TEXT
> "The I2NSF Capability Layer specifies how to control and monitor NSFs at a
> functional implementation level. I2NSF will standardize a set of interfaces
> by which a security controller can invoke, operate, and monitor NSFs."
>
> I think we should clarify functional implementation level. My
> understanding is that the I2NSF Capability Layer should inform the tenants
> of the different available NSF as well as the various available associated
> options, profiles...
> [Linda] The sentence “*functional **implementation*” is the result of
> many rounds of debate. It is trying to emphasizing that the rules (for
> control and monitor) to NSFs have to be implementable by most NSFs.
>

[Daniel] I find you sentence very clear. I think it would nice to add it in
the charter to clarify what functional implementation means.

> expressed to a security controller that uses the capability layer to
> control and manage NSFs to implement these policies.  "
>
> Maybe we could write:
> "It also allows the client to monitor those policies. I2NSF will not
> specify how a security controller maps security service requests at the
> Service Layer to control and management actions at the Capability Layer,
>

[Daniel] Maybe having two sentences. One for what is not in scope and
another sentecne for what is in scope would be helpful. This shoudl be one
sentence. The next one shoudl define what is in scope. Th ebullet you
propose where much clearer to me.

but the development of a Simple Service Layer model that is modeled as
> closely as possible on the Capability Layer is within 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"
>
>    - the translation mechanism/methods from Service Layer policies to
>    Capability layer comments is out of I2NSF scope, and
>    - I2NSF will not specify abstract or sophisticated policies from
>    clients. Only simple service layer policies that model the “capability
>    layer” commands are in the scope of I2NSF.
>    -
>
>
>
At least my understanding is:
> [Linda] “declined”???
[Daniel] I think I meant defined. bu the bullets were clear.

Capability Layer this is left to the controller which is implementation
> dependent.  Instead, I2NFS considers that tenants policies should be based
> on information provided by the Capability Layer. I2NSF will provide
> guidance based on a simple service to define a models that eases
> interactions between the Service Layer  and the Capability Layer.
>
>

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 17 Aug 2015 16:56:21 +0000

Dan,

Thanks for your comments. I have updated the charter per your suggestions, and posted to the I2NSF Wiki page: https://sites.google.com/site/interface2nsf/home?pli=1

The charter changes are reiterated below to make it easier for your review:

Linda

-----Original Message-----
From: 🔓Dan Wing [mailto:[email-masked]]
Sent: Friday, August 14, 2015 12:36 PM

[Linda] Thanks. I modified the text just to elaborate the meaning of "controlling and monitoring aspects":

      Controlling and monitoring aspects of NSFs include the ability to specify rules, query, and monitor to NSFs by one or more management entities.

      Added a new paragraph to emphasize what is in the scope:
            •   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 comments are out of I2NSF scope.
            •   However I2NSF will provide a forum for Informational drafts on data models, APIs, etc. that demonstrate how more complex Service Layer policies and formats may be translated to Capability Layer functions.

[Linda] OK. Added the following sentence:

      Note: the Database update and synchronization among multiple management entities are out of I2NSF scope

Please let me know if you have further questions or suggestions.

Linda

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 17 Aug 2015 16:56:55 +0000

Daniel,

Thanks for the feedback.

I made the changers per your request to the Wiki: https://sites.google.com/site/interface2nsf/home?pli=1

The changes are also reiterated below, just to make it easier for your review.

Linda

From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniel Migault
Sent: Sunday, August 16, 2015 1:03 PM

B)
OLD CHARTER TEXT

I think we should clarify functional implementation level. My understanding is that the I2NSF Capability Layer should inform the tenants of the different available NSF as well as the various available associated options, profiles...
[Linda] The sentence “functional implementation” is the result of many rounds of debate. It is trying to emphasizing that the rules (for control and monitor) to NSFs have to be implementable by most NSFs.

[Daniel] I find you sentence very clear. I think it would nice to add it in the charter to clarify what functional implementation means.

[Linda] Good suggestion. I added the following:

 The term “Functional Implementation” is used to emphasize that the rules (for control and monitor) of NSFs have to be implementable by most NSFs.

C)
OLD CHARTER TEXT

Maybe we could write:

[Linda] Changed the text per your suggestion. Thank you.
“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.”

OLD CHARTER TEXT
"It also allows the client to monitor those policies. I2NSF will not specify how a security controller maps security service requests at the Service Layer to control and management actions at the Capability Layer,

[Daniel] Maybe having two sentences. One for what is not in scope and another sentecne for what is in scope would be helpful. This shoudl be one sentence. The next one shoudl define what is in scope. Th ebullet you propose where much clearer to me.
but the development of a Simple Service Layer model that is modeled as closely as possible on the Capability Layer is within 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 statement is to say that
·       the translation mechanism/methods from Service Layer policies to Capability layer comments is out of I2NSF scope, and
·       I2NSF will not specify abstract or sophisticated policies from clients. Only simple service layer policies that model the “capability layer” commands are in the scope of I2NSF.
·

[Linda] Thanks. I changed the text to the bullet format. See below:

Since there could be many depths or types of Service Layer policies, to make I2NSF charter more focused, 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 comments are out of I2NSF scope.

·       However I2NSF will provide a forum for Informational drafts on data models, APIs, etc. that demonstrate how more complex Service Layer policies and formats may be translated to Capability Layer functions.

Thanks, Linda

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

---

From: 🔓Dan Wing <[email-masked]>
Date: Mon, 17 Aug 2015 22:32:43 -0400

Thanks.
-d

On 17-Aug-2015 12:56 pm, Linda Dunbar <[email-masked]> wrote: 
> Dan,
>  
> Thanks for your comments. I have updated the charter per your suggestions, and posted to the I2NSF Wiki page: https://sites.google.com/site/interface2nsf/home?pli=1 <https://sites.google.com/site/interface2nsf/home?pli=1>
>  
>  
> From: 🔓Dan Wing [mailto:[email-masked] <mailto:[email-masked]>]