Subject: Re: [I2nsf] [I2NSF] Two levels of I2NSF interface:

From: "Susan Hares" <[email-masked]>
Date: Tue, 3 Feb 2015 05:23:57 -0500

Bob: 

Young Lee presented the Stratum in one of his Cross-Stratum drafts about 4
years ago.  You might want to search the expired draft list. 

Sue 

From: I2nsf [mailto:[email-masked]] On Behalf Of Natale, Bob
Sent: Monday, January 26, 2015 1:49 PM
To: Linda Dunbar
Cc: [email-masked]
Subject: Re: [I2nsf] [I2NSF] Two levels of I2NSF interface:

Hi Linda,

Just to be clear, I was only recommending labels for the two interface types
in my previous message . nothing more.

However, using O&M as an example domain (can be easily mapped to the
security domain), a "service interface" might support a (fabricated here)
request to "Instantiate service chain <x>" coming from an OSS/BSS
application into the "Management Sub-Stratum" interface in the diagram
below, and that in turn (and possibly via interfaces with the "Policy
Sub-Stratum") communicating  (perhaps iteratively) with the "capability
interface" in the "Control Sub-Stratum" to for OAM-level actions such as
provision resources, activate connections, launch monitoring, etc., and
report status back up through the "Management Sub-Stratum".

[Note: I owe credit for the "sub-stratum" construct and terminology to
someone else, but I could not find the source expeditiously at this time.]

Avanti,

BobN

From: Linda Dunbar [mailto:[email-masked]] 
Sent: Monday, January 26, 2015 1:20 PM
To: Natale, Bob
Cc: [email-masked]
Subject: RE: [I2NSF] Two levels of I2NSF interface:

Bob, 

Can you give some examples of your "Service Interface"? 

And some examples of "Capability Interface"? 

Thanks, Linda 

From: Natale, Bob [mailto:[email-masked]] 
Sent: Monday, January 26, 2015 11:50 AM
To: Linda Dunbar
Cc: [email-masked]
Subject: RE: [I2NSF] Two levels of I2NSF interface:

Hi Linda,

I have employed the distinction between these two different types of
interfaces in related work, but recommend using "Service Interface" and
"Capability Interface", respectively.

("Service Oriented" carries implications that might or might not be
applicable in any given case.)

Avanti,

BobN

From: I2nsf [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Monday, January 26, 2015 12:34 PM
To: Xialiang (Frank); [email-masked]
Cc: Romascanu, Dan (Dan); Joseph Salowey; John Strassner
Subject: Re: [I2nsf] [I2NSF] Two levels of I2NSF interface:

Frank, 

Thank you very much for proposing the two levels. It definitely more clear
to have two different types of interfaces for the I2NSF consolidated use
case: 

Maybe "Functional Oriented Interface" should be more like "Match & Action"
style, whereas the "Service Oriented Interface" can be the NIST endorsed
Role Based Access Control style. 

Any other opinions? 

Linda

From: Xialiang (Frank) 
Sent: Monday, January 26, 2015 1:24 AM
To: [email-masked]
Cc: Romascanu, Dan (Dan); Joseph Salowey; John Strassner; Linda Dunbar
Subject: [I2NSF] Two levels of I2NSF interface:

Hi all,

When we discuss the scope of I2NSF, we need to identify the new interface to
support and design. By my understanding, there are two levels of interface
we need to consider, actually:

1.       NBI of Adaptor (or Controller): it's a more service-oriented
interface between I2NSF clients and I2NSF adaptor. Its main objective is to
unify the communication channel and the security service request information
model the various high-level application (e.g., openstack, various BSS/OSS,
etc), and decouple the various kind of security device and specific security
functions of them. The intent-driven information model approach derived from
RBAC model maybe a feasible way;

2.       NBI of security devices (e.g., FW, IPS, etc): it's a more
function-oriented interface between I2NSF clients/I2NSF adaptors with
specific security devices. It's used for decoupling the variable security
services by the high level application and focusing on the unified interface
and security functions information model provided by the variable security
devices.

So, my questions are: How we consider these two levels of interface? Should
they all be in scope of I2NSF work?

Glad to get your experts thought and suggestions, thanks!

B.R.

Frank

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 3 Feb 2015 05:36:05 -0500

John:

Intent-Based Nemo
(http://tools.ietf.org/html/draft-xia-sdnrg-nemo-language-01   is a DSL for
virtual networks.  I think it does the following for virtual networks at the
application layer and policy controls the data flows and the actions applied
to the data flows.  I will post a separate thread with the Intent-Based
Nemo.  More documentation is at www.nemo-project.net.  Demo code was shown
at IETF91 and an OPNFV project is underway.
(https://wiki.opnfv.org/requirements_projects/nemo) 

  In looking at the examples, I think it does what you proposed that is
RBAC-enabled: 

1)       Roles are defined - that can define, instantiate, execute process a
service chain,

2)       Roles  have been defined for the virtual network, 

3)       Capabilities for network flows, direction to devices (E.g. Security
devices), and actions on the data have been defined,

4)       It is intent-based and prescriptive.  The logical application
virtual topology is described.  The network then decides how to implement
it. 

5)       One or more roles execute. 

The reason why this is interesting is that there is running demo code (see
the flash of the demos from IETF 91), and the OPNFV project is there.  

Please let me know if you think it is a DSL that is "RBAC-enabled." 

Sue Hares 

------------------

Continuing your example, if we had a policy rule DSL that was
"RBAC-enabled", then:

.         Roles that can define, instantiate, execute, etc. the service
chain are defined

.         Roles representing various actors that have appropriate
permissions are defined

.         Capabilities are represented as managed objects that have their
own permissions

.         The beauty of the policy language would then be to tie the various
parts of your example together (either imperatively or declaratively,
depending on the nature of the policy language):

o   Service interface == request from authorized Role

o   Policy engine translates to set of protected objects for the service
chain

o   Policy engine looks for Roles that have appropriate permissions to
operate on those protected objects

o   Policy engine issues commands that tell one or more Roles to take the
OAM actions that they are authorized to execute

Is this more or less what you were talking about Bob?

From: I2nsf [mailto:[email-masked]] On Behalf Of John Strassner
Sent: Monday, January 26, 2015 6:51 PM
To: Natale, Bob; Linda Dunbar; John Strassner
Cc: [email-masked]
Subject: Re: [I2nsf] [I2NSF] Two levels of I2NSF interface:

Hi Bob,

Continuing your example, if we had a policy rule DSL that was
"RBAC-enabled", then:

.         Roles that can define, instantiate, execute, etc. the service
chain are defined

.         Roles representing various actors that have appropriate
permissions are defined

.         Capabilities are represented as managed objects that have their
own permissions

.         The beauty of the policy language would then be to tie the various
parts of your example together (either imperatively or declaratively,
depending on the nature of the policy language):

o   Service interface == request from authorized Role

o   Policy engine translates to set of protected objects for the service
chain

o   Policy engine looks for Roles that have appropriate permissions to
operate on those protected objects

o   Policy engine issues commands that tell one or more Roles to take the
OAM actions that they are authorized to execute

Is this more or less what you were talking about Bob?

regards,

John

Dr. John Strassner, Ph.D.

CTO, Software Laboratory, CRD

logo.gif

Futurewei Technologies

US R&D Center

2330 Central Expressway
Building A, office A2-2143

Santa Clara, California   95050

  Office:  +1.408.330.4923

  Email:   [email-masked]

From: I2nsf [mailto:[email-masked]] On Behalf Of Natale, Bob
Sent: Monday, January 26, 2015 10:49 AM
To: Linda Dunbar
Cc: [email-masked]
Subject: Re: [I2nsf] [I2NSF] Two levels of I2NSF interface:

Hi Linda,

 

Avanti,

BobN

Bob, 

Thanks, Linda 

Hi Linda,

Avanti,

BobN

Frank, 

 

Any other opinions? 

Linda

From: Xialiang (Frank) 

Hi all,

B.R.

Frank

---

From: John Strassner <[email-masked]>
Date: Tue, 3 Feb 2015 19:28:42 +0000

Sue:

I briefly scanned your intent-based NEMO draft. I note the following:

*         The English in the draft needs a lot of improvement

*         The grammar snippets are incomplete and have typos

*         The grammar seems to be more conceptual in what it is trying to do as opposed to being a literal grammar that could generate a working parser

I think it is a DSL, though I was envisioning a language with more "syntactic sugar". For example,

Regarding your statements:

1)       Roles are defined - that can define, instantiate, execute process a service chain,
<js> The draft does not contain the word Role, so I don't understand why you think that NEMO defines roles. </js>

2)       Roles  have been defined for the virtual network,
<js> Where in the draft is this? </js>

3)       Capabilities for network flows, direction to devices (E.g. Security devices), and actions on the data have been defined,
<js> The capabilities that Bob and I were talking about seem to be very different than the capabilities that are described in the draft. For example, you differentiate between 3 types of nodes (forwarding, processing, and logical), but none of these allow me to say that this is a "firewall". Being limited to specifying pairs for an action is probably not sufficient for most applications, and certainly not for I2NFS.

4)       It is intent-based and prescriptive.  The logical application virtual topology is described.  The network then decides how to implement it.
<js> Perhaps, for some simple examples, but not in general for applications that want to use RBAC, ABAC, or PBAC. There are also some problems in the definitions themselves (see below).

5)       One or more roles execute.
<js> Where, exactly, are roles defined? </js>

Regarding the question of whether NEMO is "intent-based", let's look at one of your example policies:

Policy "policy-1"
ApplyTo "flow-1"
Priority 100
Condition ("time">"18:00") || ("time"<"21:00")
Action "gothrough" : List( "switch-1" , "switch-2");

First, why would a policy object "know" where it should be applied? I would think that there would be a relationship between the Policy object and the target of the policy.

Second, shouldn't the logical OR be a logical AND?

Third, this is really just a set of low-level configuration commands that are masquerading as properties of an object. This doesn't make it wrong, but it also doesn't make it "intent-based".

Until I understand how you define Roles, it is certainly not RBAC-enabled. It also does not appear to be ABAC or PBAC compliant.

I'm not saying that it isn't useful, I just don't see an immediate fit between this work and I2NFS.

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

From: Susan Hares [mailto:[email-masked]]
Sent: Tuesday, February 03, 2015 2:36 AM
To: John Strassner; 'Natale, Bob'; Linda Dunbar
Cc: [email-masked]
Subject: RE: [I2nsf] [I2NSF] Two levels of I2NSF interface:

John:

Intent-Based Nemo (http://tools.ietf.org/html/draft-xia-sdnrg-nemo-language-01   is a DSL for virtual networks.  I think it does the following for virtual networks at the application layer and policy controls the data flows and the actions applied to the data flows.  I will post a separate thread with the Intent-Based Nemo.  More documentation is at www.nemo-project.net<http://www.nemo-project.net>.  Demo code was shown at IETF91 and an OPNFV project is underway.  (https://wiki.opnfv.org/requirements_projects/nemo)

  In looking at the examples, I think it does what you proposed that is RBAC-enabled:

6)       Roles are defined - that can define, instantiate, execute process a service chain,

7)       Roles  have been defined for the virtual network,

8)       Capabilities for network flows, direction to devices (E.g. Security devices), and actions on the data have been defined,

9)       It is intent-based and prescriptive.  The logical application virtual topology is described.  The network then decides how to implement it.

10)   One or more roles execute.

The reason why this is interesting is that there is running demo code (see the flash of the demos from IETF 91), and the OPNFV project is there.

Sue Hares

------------------

Continuing your example, if we had a policy rule DSL that was "RBAC-enabled", then:

*         Roles that can define, instantiate, execute, etc. the service chain are defined

*         Roles representing various actors that have appropriate permissions are defined

*         Capabilities are represented as managed objects that have their own permissions

*         The beauty of the policy language would then be to tie the various parts of your example together (either imperatively or declaratively, depending on the nature of the policy language):

o   Policy engine translates to set of protected objects for the service chain

o   Policy engine looks for Roles that have appropriate permissions to operate on those protected objects

o   Policy engine issues commands that tell one or more Roles to take the OAM actions that they are authorized to execute

Hi Bob,

Continuing your example, if we had a policy rule DSL that was "RBAC-enabled", then:

*         Roles that can define, instantiate, execute, etc. the service chain are defined

*         Roles representing various actors that have appropriate permissions are defined

*         Capabilities are represented as managed objects that have their own permissions

*         The beauty of the policy language would then be to tie the various parts of your example together (either imperatively or declaratively, depending on the nature of the policy language):

o   Policy engine translates to set of protected objects for the service chain

o   Policy engine looks for Roles that have appropriate permissions to operate on those protected objects

o   Policy engine issues commands that tell one or more Roles to take the OAM actions that they are authorized to execute

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923
  Email:   [email-masked]<mailto:[email-masked]>

From: I2nsf [mailto:[email-masked]] On Behalf Of Natale, Bob
Sent: Monday, January 26, 2015 10:49 AM
To: Linda Dunbar
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [I2nsf] [I2NSF] Two levels of I2NSF interface:

Hi Linda,

Just to be clear, I was only recommending labels for the two interface types in my previous message ... nothing more.

However, using O&M as an example domain (can be easily mapped to the security domain), a "service interface" might support a (fabricated here) request to "Instantiate service chain <x>" coming from an OSS/BSS application into the "Management Sub-Stratum" interface in the diagram below, and that in turn (and possibly via interfaces with the "Policy Sub-Stratum") communicating  (perhaps iteratively) with the "capability interface" in the "Control Sub-Stratum" to for OAM-level actions such as  provision resources, activate connections, launch monitoring, etc., and report status back up through the "Management Sub-Stratum".

[Note: I owe credit for the "sub-stratum" construct and terminology to someone else, but I could not find the source expeditiously at this time.]

Avanti,
BobN

From: Linda Dunbar [mailto:[email-masked]]
Sent: Monday, January 26, 2015 1:20 PM
To: Natale, Bob
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [I2NSF] Two levels of I2NSF interface:

Bob,

Thanks, Linda

From: Natale, Bob [mailto:[email-masked]]
Sent: Monday, January 26, 2015 11:50 AM
To: Linda Dunbar
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [I2NSF] Two levels of I2NSF interface:

Hi Linda,

I have employed the distinction between these two different types of interfaces in related work, but recommend using "Service Interface" and "Capability Interface", respectively.

("Service Oriented" carries implications that might or might not be applicable in any given case.)

Avanti,
BobN

To: Xialiang (Frank); [email-masked]<mailto:[email-masked]>

Frank,

Thank you very much for proposing the two levels. It definitely more clear to have two different types of interfaces for the I2NSF consolidated use case:

Maybe "Functional Oriented Interface" should be more like "Match & Action" style, whereas the "Service Oriented Interface" can be the NIST endorsed Role Based Access Control style.

Any other opinions?

Linda

From: Xialiang (Frank)
Sent: Monday, January 26, 2015 1:24 AM
To: [email-masked]<mailto:[email-masked]>
Cc: Romascanu, Dan (Dan); Joseph Salowey; John Strassner; Linda Dunbar
Subject: [I2NSF] Two levels of I2NSF interface:

Hi all,
When we discuss the scope of I2NSF, we need to identify the new interface to support and design. By my understanding, there are two levels of interface we need to consider, actually:

1.       NBI of Adaptor (or Controller): it's a more service-oriented interface between I2NSF clients and I2NSF adaptor. Its main objective is to unify the communication channel and the security service request information model the various high-level application (e.g., openstack, various BSS/OSS, etc), and decouple the various kind of security device and specific security functions of them. The intent-driven information model approach derived from RBAC model maybe a feasible way;

2.       NBI of security devices (e.g., FW, IPS, etc): it's a more function-oriented interface between I2NSF clients/I2NSF adaptors with specific security devices. It's used for decoupling the variable security services by the high level application and focusing on the unified interface and security functions information model provided by the variable security devices.

So, my questions are: How we consider these two levels of interface? Should they all be in scope of I2NSF work?
Glad to get your experts thought and suggestions, thanks!

B.R.
Frank

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 3 Feb 2015 19:00:20 -0500

John: 

You are correct.  The drafts badly need a revision. That was my plan for
last night and today.  However, your email messages were delightful and I
did not resist the intellectual fun to try to speak in ACL/RBAC language.
Of course you are the expert in this work. 

Intent based DSL  focus on the 80/20 rule of applications - 80% of the
applications often use 20% of the functional of an interface. It is meant to
be a "mini-me" with DSL. 

Nemo is an Intent-based DSL that expresses a logical set of roles virtual
networks. See Node, link, flow, "Policy" and "Flow".   The associated
policies permit or deny roles for this logical application layer network. 

This is ***not*** a security RBAC or a FW RBAC or a DDoS RBAC.  

We started with the network.  My message suggested that you could create a
similar function for the I2NSF logical world.  The Property key word can set
attributes on virtual components.  The policy command can test these
attributes on nodes, link, flows  and take actions based on the attributes. 

How would you class this type of policy for virtual networks?  RBAC, ABAC,
PBAC.  

<node_cu> := Node <node_id> Type <node_type> LogicNW <node_id>      

                        [Property {<property_name>: <value>}]; 

<link_cu> := Link <link_id>  EndNodes <node_type> : <node_id>, <node_type> :
<node_id>

                        [Property{<property_name>: <value>}];

<flow_cu> := Flow <flow_id>    Match  {<property_name>: <value> 

                | Range (<value>, <value>)  | List ({<value>})}

<policy_cu> := Policy <policy_id> ApplyTo <entity_type> : <entity_id>    

            Priority  <integer> [Condition   {<expression>}]
Action                   {<action_type> : {<value>}};

A "No" in front of each of these commands deletes these commands.  An
example of this is: 

<node_del> := NoNode  <node_id>;        

I am Grateful for your insights!

Sue 

From: John Strassner [mailto:[email-masked]] 
Sent: Tuesday, February 03, 2015 2:29 PM
To: Susan Hares; 'Natale, Bob'; John Strassner; Linda Dunbar
Cc: [email-masked]
Subject: RE: [I2nsf] [I2NSF] Two levels of I2NSF interface:

Sue:

.         The English in the draft needs a lot of improvement

.         The grammar snippets are incomplete and have typos

.         The grammar seems to be more conceptual in what it is trying to do
as opposed to being a literal grammar that could generate a working parser

I think it is a DSL, though I was envisioning a language with more
"syntactic sugar". For example, 

1)       Roles are defined - that can define, instantiate, execute process a
service chain,
<js> The draft does not contain the word Role, so I don't understand why you
think that NEMO defines roles. </js>

<skh> This document is written for virtual networks.  It is not a security.
If you feel my definition above does not cover RBACs, then help me define a
term we can use to talk about it.  

IMHO vNSF = Virtual Networks + vSecurity-Device.  Am I right or wrong.  

</skh> 

<skh> see above in introduction.  Role is a logical network role for a node
and not a security role. I simply suggested you could create a similar
function for security.    I2NSF = vNetwork +vSecurity.  

3)       Capabilities for network flows, direction to devices (E.g. Security
devices), and actions on the data have been defined, 
<js> The capabilities that Bob and I were talking about seem to be very
different than the capabilities that are described in the draft. For
example, you differentiate between 3 types of nodes (forwarding, processing,
and logical), but none of these allow me to say that this is a "firewall".
Being limited to specifying pairs for an action is probably not sufficient
for most applications, and certainly not for I2NFS.

          <skh> You are 100% correct. This the base virtual network, and it
is not limited to pairs.  I suggest you can create something with 

4)       It is intent-based and prescriptive.  The logical application
virtual topology is described.  The network then decides how to implement
it. 
<js> Perhaps, for some simple examples, but not in general for applications
that want to use RBAC, ABAC, or PBAC. There are also some problems in the
definitions themselves (see below).

<b> 

Regarding the question of whether NEMO is "intent-based", let's look at one
of your example policies:

Policy "policy-1"

ApplyTo "flow-1"

Priority 100

First, why would a policy object "know" where it should be applied? I would
think that there would be a relationship between the Policy object and the
target of the policy.

<skh> The target of the policy in the above is a data flow (see applyTo).
See the original put. 

<skh> AND - Thank you for the correction. 

Third, this is really just a set of low-level configuration commands that
are masquerading as properties of an object. This doesn't make it wrong, but
it also doesn't make it "intent-based".

<skh> These are not physical nodes, these are nodes at the application layer
which create a network. 

The application says create these application to application connectivity -
through whatever means "mr-network" so I can have this data flow.   The
intent is a virtual network, and the Policy is on the data flow between
networks. 

[ACL, RBAC, ABAC - PBAC] 

Until I understand how you define Roles, it is certainly not RBAC-enabled.
It also does not appear to be ABAC or PBAC compliant.

<skh>  John - I really need your insights to help sort this out.  Please let
me know what references I should read or how to frame the discussion. 

I'm not saying that it isn't useful, I just don't see an immediate fit
between this work and I2NFS.

<skh> 

regards,

John

logo.gif

Futurewei Technologies

US R&D Center

2330 Central Expressway

  Office:  +1.408.330.4923

 

John:

Intent-Based Nemo

6)       Roles are defined - that can define, instantiate, execute process a
service chain,

8)       Capabilities for network flows, direction to devices (E.g. Security
devices), and actions on the data have been defined,

9)       It is intent-based and prescriptive.  The logical application
virtual topology is described.  The network then decides how to implement
it. 

Sue Hares 

------------------

 

Hi Bob,

 

regards,

John

logo.gif

Futurewei Technologies

US R&D Center

2330 Central Expressway

  Office:  +1.408.330.4923

 

Hi Linda,

 

Avanti,

BobN

Bob, 

Thanks, Linda 

Hi Linda,

Avanti,

BobN

Frank, 

 

Any other opinions? 

Linda

From: Xialiang (Frank) 

Hi all,

B.R.

Frank

---

From: John Strassner <[email-masked]>
Date: Wed, 4 Feb 2015 21:57:42 +0000

Please see inline. Look for <js2>..</js2>

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

From: Susan Hares [mailto:[email-masked]]
Sent: Tuesday, February 03, 2015 4:00 PM
To: John Strassner; 'Natale, Bob'; Linda Dunbar
Cc: [email-masked]
Subject: RE: [I2nsf] [I2NSF] Two levels of I2NSF interface:

John:

You are correct.  The drafts badly need a revision. That was my plan for last night and today.  However, your email messages were delightful and I did not resist the intellectual fun to try to speak in ACL/RBAC language.  Of course you are the expert in this work.

Intent based DSL  focus on the 80/20 rule of applications - 80% of the applications often use 20% of the functional of an interface. It is meant to be a "mini-me" with DSL.

Nemo is an Intent-based DSL that expresses a logical set of roles virtual networks. See Node, link, flow, "Policy" and "Flow".
<js2>
What, exactly, is "intent-based" here?
</js2>

The associated policies permit or deny roles for this logical application layer network.
<js2>
No they don't, since Roles do not exist as a managed object!
</js2>

This is ***not*** a security RBAC or a FW RBAC or a DDoS RBAC.
<js2>
I have no idea what any of these terms are...
</js2>

We started with the network.  My message suggested that you could create a similar function for the I2NSF logical world. .
<js2>
Your message was "I think it does what you proposed that is RBAC-enabled". I disagreed, and still do.
</js2>

 The Property key word can set attributes on virtual components.  The policy command can test these attributes on nodes, link, flows  and take actions based on the attributes. .
<js2>
Admittedly, setting properties on an object is much better than having a control structure that does the same thing. I'm not sure that this is sufficient to call it "declarative" or "intent-based". However, what I am sure of is that this approach requires a rich model underneath. NEMO has a very thin model, and in particular, key concepts required for RBAC, ABAC, and PBAC are NOT defined.
</js2>

How would you class this type of policy for virtual networks?  RBAC, ABAC, PBAC.
<js2>
See above. This type of policy has no relation to RBAC, ABAC, or PBAC
</js2>

<node_cu> := Node <node_id> Type <node_type> LogicNW <node_id>
                        [Property {<property_name>: <value>}];
<link_cu> := Link <link_id>  EndNodes <node_type> : <node_id>, <node_type> : <node_id>
                        [Property{<property_name>: <value>}];
<flow_cu> := Flow <flow_id>    Match  {<property_name>: <value>
                | Range (<value>, <value>)  | List ({<value>})}
<policy_cu> := Policy <policy_id> ApplyTo <entity_type> : <entity_id>
            Priority  <integer> [Condition   {<expression>}]                                                                         Action                   {<action_type> : {<value>}};
A "No" in front of each of these commands deletes these commands.  An example of this is:
<node_del> := NoNode  <node_id>;

Sue

Sue:

1)       Roles are defined - that can define, instantiate, execute process a service chain,
<js> The draft does not contain the word Role, so I don't understand why you think that NEMO defines roles. </js>
<skh> This document is written for virtual networks.  It is not a security.  If you feel my definition above does not cover RBACs, then help me define a term we can use to talk about it.
IMHO vNSF = Virtual Networks + vSecurity-Device.  Am I right or wrong.
</skh>
<js2>
First, taking a language and then saying "gee, it can be reused for a different domain" doesn't typically work. If you want to EXTEND NEMO to cover security functions, you need to ADD security concepts as objects.
Second, NSF is not just about virtual security functions.
Third, I don't agree with your vNSF definition - security must be a part of the virtual network, not added on.
</js2>

2)       Roles  have been defined for the virtual network,
<js> Where in the draft is this? </js>
<skh> see above in introduction.  Role is a logical network role for a node and not a security role. I simply suggested you could create a similar function for security.    I2NSF = vNetwork +vSecurity.
<js2>
See above. They need to exist as first class objects. Also, I2NSF != vN + vSec
</js2>

3)       Capabilities for network flows, direction to devices (E.g. Security devices), and actions on the data have been defined,
<js> The capabilities that Bob and I were talking about seem to be very different than the capabilities that are described in the draft. For example, you differentiate between 3 types of nodes (forwarding, processing, and logical), but none of these allow me to say that this is a "firewall". Being limited to specifying pairs for an action is probably not sufficient for most applications, and certainly not for I2NFS.
          <skh> You are 100% correct. This the base virtual network, and it is not limited to pairs.  I suggest you can create something with

Policy "policy-1"
ApplyTo "flow-1"
Priority 100

<skh> The target of the policy in the above is a data flow (see applyTo).  See the original put.
<js2>
That was exactly my point! How does the Policy know what its Target is?
</js2>

Third, this is really just a set of low-level configuration commands that are masquerading as properties of an object. This doesn't make it wrong, but it also doesn't make it "intent-based".
<skh> These are not physical nodes, these are nodes at the application layer which create a network.
The application says create these application to application connectivity - through whatever means "mr-network" so I can have this data flow.   The intent is a virtual network, and the Policy is on the data flow between networks.
<js2>
So what? That does NOT make them Roles, nor does it make it intent-based.
</js2>

[ACL, RBAC, ABAC - PBAC]
Until I understand how you define Roles, it is certainly not RBAC-enabled. It also does not appear to be ABAC or PBAC compliant.
<skh>  John - I really need your insights to help sort this out.  Please let me know what references I should read or how to frame the discussion.

<js2>
You should start by reading the NIST RBAC specification, although this site also has references to ABAC and PBAC

    http://csrc.nist.gov/groups/SNS/rbac/

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

John:

Sue Hares

------------------

Hi Bob,

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

Hi Linda,

Avanti,
BobN

Bob,

Thanks, Linda

Hi Linda,

Avanti,
BobN

Frank,

Any other opinions?

Linda

From: Xialiang (Frank)

Hi all,

B.R.
Frank