Re: [I2nsf] updates on the capability models

[John Strassner]

Hi Linda,

Please see inline.

Regards,
John

From: Linda Dunbar
Sent: Wednesday, January 03, 2018 10:27 AM
To: John Strassner ; Aldo Basile 
; John Strassner 
Cc: i2nsf@ietf.org
Subject: RE: [I2nsf] updates on the capability models

John,

Thank you very much for the detailed explanation. Took me awhile to carefully 
reading through your writing. Felt like reading a college class assignment.

Sorry, I wrote this on the plane trip to Shenzhen. I am a tenured professor, 
but that was not my intent. ☺


Are you going to update the capability draft accordingly?

I will wait for feedback from at least the Capability draft co-authors, and 
then lead the editing of this draft.


You stated to have separate “I2NSFSecurityPolicyRule and I2NSFDecoratorRule”. 
Do users (e.g. Controller or Admin who issue the policy rules) have to be aware 
which one to use?

NO!
The power of the decorator pattern is to provide a single interface to the 
“base class” (in this case, I2NSFSecurityPolicyRule). The client is blissfully 
unaware of whether additional objects wrap the base class. :-)


Are the “event”, “condition” and “action” part of I2NSFPolicyComponent?

YES! Remember, an I2NSFPolicyRule aggregates an event clause, a condition 
clause, and an action clause. Conceptually, think of an I2NSFPolicyRule as 
aggregating one or more I2NSFPolicyComponents.


What are the examples of sibling class to I2NSFEvent, I2NSFCondition, and 
I2NSFAction?  Can you add the examples to the updated draft? To make it easier 
for people to comprehend.

Any object that is a part of an I2NSFPolicyRule (except for I2NSFMetadata) can 
be a PolicyComponent (i.e., a sibling class). For example, take a look at 
Figure 13 of the SUPA draft. Event, Condition, and Action are the fundamental 
components of an ECA policy rule, but each of these can be optionally 
constructed from other objects. For example, a Boolean clause takes the form of 
{variable, operator, value} (e.g., numAlarms > 5). One could either use an 
atomic Event (or Condition in this example), or use individual objects (e.g., a 
PolicyVariable, a PolicyOperator, and a PolicyValue) to make up the Boolean 
clause.

I will add examples to the draft.


Can you also add some examples of “I2NSFMetadata class” in the updated draft?

Sure


Thank you very much.

Linda

From: John Strassner
Sent: Wednesday, January 03, 2018 9:11 AM
To: Linda Dunbar >; 
Aldo Basile >; John 
Strassner >; 
John Strassner >
Cc: i2nsf@ietf.org
Subject: RE: [I2nsf] updates on the capability models

Sorry for the delay in replying.

First, Aldo is correct – the decorator pattern is used to both increase
extensibility and to avoid object explosion (by having to enumerate each
different function as a separate object).

Second, I wouldn’t call the NSF-facing model a “superset” of the capability
model. Every concept that is in the NSF-facing model SHOULD be derived from
the Capability model (if that isn’t possible, then we need to extend the
Capability model). This is very important – if this is not true, then other
data models that are NOT YANG models will not be interoperable with our
YANG data model. Note that this doesn’t mean that a data model just selects
objects from the info model! Rather, it selects **concepts**, and then
refines those concepts. For example, if the info model defines the concept
of an operator, then a data model is free to define new types of operators.
In this example, if the operator was a class, the new operator types would
be subclasses of the operator class.

Now suppose that the info model did not define an operator class. Clearly,
imperative policy rules need operators. The data model would have to define
an operator class – but where would it define it from? Let’s say it chooses
to define it from I2NSFPolicy (an obviously bad choice). If another data
model (say, one using relational calculus) defines an operator from a
different class (say, metadata, an equally bad choice), now you have different
semantics attached to the notion of an operator, since they are subclassed
from different places. Say goodbye to interoperability.

The above simple example is one reason why the different data models need to
be properly derived from the info model.

Your third question (about the long list of attributes) is subject to opinion.
I personally dislike classes with long list of attributes. Such a design begs
the question, “is this attribute really **only** applicable to this one class?”
For example, take an address. It is common to have separate classes for IPv4
and IPv6, since the structure of the address is fundamentally different. Of
course, MAC addresses are different from both, 

Re: [I2nsf] updates on the capability models

[Linda Dunbar]

John,

Thank you very much for the detailed explanation. Took me awhile to carefully 
reading through your writing. Felt like reading a college class assignment. Are 
you going to update the capability draft accordingly?

You stated to have separate “I2NSFSecurityPolicyRule and I2NSFDecoratorRule”. 
Do users (e.g. Controller or Admin who issue the policy rules) have to be aware 
which one to use?

Are the “event”, “condition” and “action” part of I2NSFPolicyComponent? What 
are the examples of sibling class to I2NSFEvent, I2NSFCondition, and 
I2NSFAction?  Can you add the examples to the updated draft? To make it easier 
for people to comprehend.

Can you also add some examples of “I2NSFMetadata class” in the updated draft?

Thank you very much.

Linda

From: John Strassner
Sent: Wednesday, January 03, 2018 9:11 AM
To: Linda Dunbar ; Aldo Basile 
; John Strassner ; John 
Strassner 
Cc: i2nsf@ietf.org
Subject: RE: [I2nsf] updates on the capability models

Sorry for the delay in replying.

First, Aldo is correct – the decorator pattern is used to both increase
extensibility and to avoid object explosion (by having to enumerate each
different function as a separate object).

Second, I wouldn’t call the NSF-facing model a “superset” of the capability
model. Every concept that is in the NSF-facing model SHOULD be derived from
the Capability model (if that isn’t possible, then we need to extend the
Capability model). This is very important – if this is not true, then other
data models that are NOT YANG models will not be interoperable with our
YANG data model. Note that this doesn’t mean that a data model just selects
objects from the info model! Rather, it selects **concepts**, and then
refines those concepts. For example, if the info model defines the concept
of an operator, then a data model is free to define new types of operators.
In this example, if the operator was a class, the new operator types would
be subclasses of the operator class.

Now suppose that the info model did not define an operator class. Clearly,
imperative policy rules need operators. The data model would have to define
an operator class – but where would it define it from? Let’s say it chooses
to define it from I2NSFPolicy (an obviously bad choice). If another data
model (say, one using relational calculus) defines an operator from a
different class (say, metadata, an equally bad choice), now you have different
semantics attached to the notion of an operator, since they are subclassed
from different places. Say goodbye to interoperability.

The above simple example is one reason why the different data models need to
be properly derived from the info model.

Your third question (about the long list of attributes) is subject to opinion.
I personally dislike classes with long list of attributes. Such a design begs
the question, “is this attribute really **only** applicable to this one class?”
For example, take an address. It is common to have separate classes for IPv4
and IPv6, since the structure of the address is fundamentally different. Of
course, MAC addresses are different from both, so as a simple example, instead
of listing a set of attributes that partially describe any one of these 3 types
of addresses, why not have a NetworkAddress class, with 3 subclasses? This
enables us to properly describe the semantics of the components of an address,
as well as relate other entities (e.g., a DHCP server) to those types of
addresses that need it.


While on vacation and travel, I received some private notes about parts of
the model. The rest of this note will answer these and comment on the PDF
that was provided.


There seems to be some confusion about the structure of the information
model. This note will first clarify the structure of the information model,
and then elaborate on the questions raised below.

Refer to figure 2 in draft-xibassnez. This defines the inheritance
relationships between I2NSFPolicyRule and I2NSFPolicyComponent, and
is shown below in more complete detail (sorry for the confusion).


***
* ETERNAL INFO MODEL  *
* *
*  ++0..11..n+--+ *
*  ||/ \\|  | *
*  | PolicyRule + A -+ PolicyComponent  | *
*  ||\ /  HasPolicyComponent/|  | *
*  +--+-+++-+ *
*/ \ / \  *
* I   I   *
**I***I
   I   I
   I

[I2nsf] I-D Action: draft-ietf-i2nsf-terminology-05.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Interface to Network Security Functions WG of 
the IETF.

Title   : Interface to Network Security Functions (I2NSF) 
Terminology
Authors : Susan Hares
  John Strassner
  Diego R. Lopez
  Liang Xia
  Henk Birkholz
Filename: draft-ietf-i2nsf-terminology-05.txt
Pages   : 13
Date: 2018-01-03

Abstract:
   This document defines a set of terms that are used for the Interface
   to Network Security Functions (I2NSF) effort.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-terminology/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-i2nsf-terminology-05
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-terminology-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-terminology-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

Re: [I2nsf] updates on the capability models

[John Strassner]

Sorry for the delay in replying.

First, Aldo is correct – the decorator pattern is used to both increase
extensibility and to avoid object explosion (by having to enumerate each
different function as a separate object).

Second, I wouldn’t call the NSF-facing model a “superset” of the capability
model. Every concept that is in the NSF-facing model SHOULD be derived from
the Capability model (if that isn’t possible, then we need to extend the
Capability model). This is very important – if this is not true, then other
data models that are NOT YANG models will not be interoperable with our
YANG data model. Note that this doesn’t mean that a data model just selects
objects from the info model! Rather, it selects **concepts**, and then
refines those concepts. For example, if the info model defines the concept
of an operator, then a data model is free to define new types of operators.
In this example, if the operator was a class, the new operator types would
be subclasses of the operator class.

Now suppose that the info model did not define an operator class. Clearly,
imperative policy rules need operators. The data model would have to define
an operator class – but where would it define it from? Let’s say it chooses
to define it from I2NSFPolicy (an obviously bad choice). If another data
model (say, one using relational calculus) defines an operator from a
different class (say, metadata, an equally bad choice), now you have different
semantics attached to the notion of an operator, since they are subclassed
from different places. Say goodbye to interoperability.

The above simple example is one reason why the different data models need to
be properly derived from the info model.

Your third question (about the long list of attributes) is subject to opinion.
I personally dislike classes with long list of attributes. Such a design begs
the question, “is this attribute really **only** applicable to this one class?”
For example, take an address. It is common to have separate classes for IPv4
and IPv6, since the structure of the address is fundamentally different. Of
course, MAC addresses are different from both, so as a simple example, instead
of listing a set of attributes that partially describe any one of these 3 types
of addresses, why not have a NetworkAddress class, with 3 subclasses? This
enables us to properly describe the semantics of the components of an address,
as well as relate other entities (e.g., a DHCP server) to those types of
addresses that need it.


While on vacation and travel, I received some private notes about parts of
the model. The rest of this note will answer these and comment on the PDF
that was provided.


There seems to be some confusion about the structure of the information
model. This note will first clarify the structure of the information model,
and then elaborate on the questions raised below.

Refer to figure 2 in draft-xibassnez. This defines the inheritance
relationships between I2NSFPolicyRule and I2NSFPolicyComponent, and
is shown below in more complete detail (sorry for the confusion).


***
* ETERNAL INFO MODEL  *
* *
*  ++0..11..n+--+ *
*  ||/ \\|  | *
*  | PolicyRule + A -+ PolicyComponent  | *
*  ||\ /  HasPolicyComponent/|  | *
*  +--+-+++-+ *
*/ \ / \  *
* I   I   *
**I***I
   I   I
   I   I
 ++++--+---+
 | I2NSFPolicyRule || I2NSFPolicyComponent |
 ++++--+---+
   I   I
   I   I
+--++  +---+---+-+
|I2NSFSecurityPolicyRule|  I   I I
+---+  I   I I
   I   I I
 +-+-+   +-+-+ +-+-+
 |I2NSFPolicy|   |I2NSFPolicy| |I2NSFPolicy|
 |   Event   |   | Condition | |  Action   |
 +---+   +---+ +---+

A new class, called I2NSFPolicy, is defined to separate the notion of
SecurityPolicyRules from other types of PolicyRules. This enables us to
define (for example) management policy rules as a sibling to