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 <[email protected]>; Aldo Basile <[email protected]>; John Strassner <[email protected]>; John Strassner <[email protected]> Cc: [email protected] 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..1 1..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 I2NSFSecurityPolicyRule in the future. Similarly, a new class, called I2NSFPolicyComponent, is used to separate events, conditions, and actions from other types of policy components. This is important, since in imperative policies, events, conditions, and actions act together. The multiplicity of the HasPolicyComponent aggregation is 0..1 – 1..n. This means that a PolicyRule MUST have at least one PolicyComponent, and a PolicyComponent may be aggregated by 0 or 1 PolicyRules. Note that there is also an aggregation between PolicyRule and Metadata in the external info model, and that I2NSFPoliyMetadata inherits from the Metadata class in the external info model. Note especially that I2NSFPolicyEvent, I2NSFPolicyCondition, and I2NSFPolicyAction are NOT subclassed from I2NSFPolicyMetadata. This is because these objects are mandatory concepts that make up an I2NSF Policy Rule. In contrast, I2NSF metadata is ALWAYS optional, and is used to describe and/or prescribe an I2NSF object. Given the above, let’s define some important concepts in the Capability Information model. Figure 3 in draft-xibassnez The problem with Figure 3 is that it is fundamentally fragile. It uses inheritance to define new types of SecurityPolicyRules. This approach has two problems: 1) It makes each subclass separate, and 2) It is not extensible The first problem is that each function is in effect a new subclass. If you want to have authentication and authorization, you need two separate policy rules. The second problem is that each new function requires a new subclass. It is impossible to think of all types of policy rules beforehand, and even if this was feasible, this would mean that most applications would not be using the majority of subclasses. The decorator pattern solves both of these problems. The decorator pattern enables a base object to be “wrapped” by zero or more decorator objects. So an I2NSFSecurityPolicyRule could be the base object, and the 6 subclasses shown in Figure 3 could each be decorator classes. The point is that the base object is not affected by new decorator subclasses; it can choose to aggregate them or not. More importantly, the client of the model is not affected, since all it sees is the base object’s class. The class design is simple: I2NSFPolicyRule is a subclass of the external information model. I2NSFSecurityPolicyRule and I2NSFDecoratorRule are both subclasses of I2NSFPolicyRule. There is an aggregation between I2NSFSecurityPolicyRule and I2NSFPolicyRule. The 6 subclasses of SecurityECAPolicyRule in Figure 3 are moved to subclass from I2NSFDecoratorRule. Figure 4 of draft-xibassnez The top of this figure is shown in the first Figure on this page. That is, the Event, Condition, and Action classes in Figure 4 become I2NSFEvent, I2NSFCondition, and I2NSFAction, and all inherit from the I2NSFPolicyComponent class. The reason for defining I2NSFPolicyComponent is to provide a common control point for the different components of an I2NSF Policy Rule. For example, we can now define a decorator pattern by adding a sibling class to I2NSFEvent, I2NSFCondition, and I2NSFAction. This fourth class, called I2NSFComponentDecorator, enables the **same** decorator pattern to be used for events, conditions, and actions (this is the mark of a good design pattern!). We do this by defining an aggregation between the I2NSFComponentDecorator and I2NSFPolicyComponent classes. This now lets us the 4 event subclasses from Figure 4 to inherit from I2NSFComponentDecorator. Figures 5 and 6 of draft-xibassnez Similarly, the 6 condition subclasses in Figure 5, and the 3 Action subclasses In Figure 6, can also inherit from I2NSFComponentDecorator. Figures 7-9 of draft-xibassnez A Capability is a type of Metadata. We will insert a new class, called I2NSFMetadata, as the superclass of the SecurityCapability class in Figure 7. The superclass of I2NSFMetadata will be an appropriate class from the external Info model. We can again use the decorator pattern to enable different security capabilities to decorate our base I2NSFMetadata class. This enables us to reuse the aggregation between the external info model’s policy rule class and the external info model’s metadata class. More importantly, we can now treat security capabilities in a consistent manner with other types of metadata. All that is needed is to once again define a decorator class (let’s call it I2NSFMetadataDecorator), and define an aggregation between it and I2NSFMetadata. Both the ContentSecurityCapability and AttackMitigationCapability class hierarchies are moved under the I2NSFMetadataDecorator class (i.e., the SecurityCapability class is the base class that is decorated). New Concepts from the PDF File Packets and Protocols I don’t like Packets being defined as a type of metadata. The reasoning is Similar as that for not subclassing events, conditions, and actions from metadata. This also applies to Protocols. StateInfo This is harder. One could argue that state information describes (and prescribes) the behavior of an object. One could also argue that state is very important (note that state is handled separately in YANG), and as such, should be its own distinct object. I typically model state as a separate object, because it simplifies the understanding of behavioral specifications (e.g., a state could be a set of attributes that need to be manipulated Together). We should talk more about this before making a decision. ConditionTarget In the SUPA and MEF work, we defined a separate class called PolicyTarget. The semantics of this date back to DEN-ng (defined in 2000), and build on Sloman’s work in the late 90s, and are well established. It simplifies understanding what a Policy Rule is working on and affecting – this is especially true for imperative policies. I would recommend keeping this approach and removing ConditionTarget. If we do this, then PolicyTarget should inherit from the I2NSFPolicyRule Class. A possibly mitigating factor is the presence of the 2 associations (called decidesBased and appliesOn in the PDF). I’m not sure what the purpose of these associations are, so this may change the reasoning I gave. Operation and OperationSet The SUPA work defined a class called PolicyTerm (which is a type of policy component decorator). PolicyTerm then defined three subclasses, called PolicyVariable, PolicyOperator, and PolicyValue. The advantage of this approach is that the information model can itself be used to define a canonical type of expression in the form of a tuple: {variable, operator, value} The disadvantage is more objects. However, in SUPA, as well as in the MEF and DEN-ng efforts, the goal was model-driven engineering (i.e., the model was both the design and the implementation). As such, reuse was very important. Since Events MUST have a type of operator (in order to form a Boolean Clause), and since Actions MAY need operators, it seems appropriate to generalize the notion of an operation, but make it accessible for events, conditions, and actions. Hence, more discussion is needed here. ResolutionStrategy I agree that this is a class. However, I would subclass it from I2NSFMetadata, not from SecurityCapability. This is because the ResolutionStrategy is optional, and because it is used to prescribe The behavior of the Policy Rule. ClauseEvaluation Sorry, I don’t understand what this is. SecurityTemplate This is a good idea! SecurityCapability, DescribedBySecurityCapabilityDetail, NSF I would change this design. An NSF MAY be described by 0 or more SecurityCapabilities. Hence, there should be an aggregation from NSF to SecurityCapability. Since there can be many types of NSF that have many different types of SecurityCapabilities, DescribedBySecurityCapabilityDetail should be an association class. This yields the following design: +-----+0..n 0..n+--------------------+ | |/ \ HasSecurityCapability | | | NSF | A ----------+----------------+ SecurityCapability | | |\ / ^ | | +-----+ | +--------------------+ | +-------------+---------------+ | HasSecurityCapabilityDetail | + ----------------------------+ This enables the HasSecurityCapabilityDetail association class to either be the target of a Policy Rule (to define which SecurityCapabilities of this NSF are visible and can be used – in other words, the Policy pattern) and/or be associated with a SecurityTemplate. Best regards, John From: John Strassner [mailto:[email protected]] Sent: Tuesday, January 02, 2018 10:11 AM To: John Strassner <[email protected]<mailto:[email protected]>> Subject: Fwd: [I2nsf] updates on the capability models ---------- Forwarded message ---------- From: Cataldo Basile <[email protected]<mailto:[email protected]>> Date: Mon, Dec 4, 2017 at 1:50 AM Subject: Re: [I2nsf] updates on the capability models To: Linda Dunbar <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Dear Linda, I may be wrong, but I remember that we discussed a change in the capability model to avoid sub-classing as a way to obtain different types of conditions, action, events, etc. The new model, now under John's review, implements the decorator pattern, thus avoid sub-classing as conditions, action, events become instances (that can be easily generated, and also used dynamically at run-time and many other advantages). Then, the NSF facing data model will probably be a superset of the capability model, obtained by extending it with concepts that are specific of NSF facing interface. After having restructured the capability model we can discuss how this impacts the NSF facing data model. Regards, Aldo On 30/11/2017 23:30, Linda Dunbar wrote: Aldo, Thank you very much for the update. By the way, the version on data tracker is still 00, so your update should be 01. During our side meeting in Singapore among IM/DM authors, you stated that you don't like explicit listing of the needed attributes for capability, e.g. the line by line list of all the IP addresses format and you volunteered to restructure the NSF facing data model so that it can be easily extended. Once you prepare the preliminary NSF facing data model structure, the NSF facing data model authors can regroup the attributes accordingly. How does the tree structure in the *pdf file you sent last Friday eliminate explicit listing of all the needed attributes for "Condition" on IP addresses? Thank you very much. Linda -----Original Message----- From: Aldo Basile [mailto:[email protected]<mailto:[email protected]>] Sent: Thursday, November 30, 2017 4:12 AM To: Linda Dunbar <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: updates on the capability models Dear Linda, all, short update on the capability information model (IM) and data model (DM) task defined during the Wednesday meeting. I have prepared a DM that derives from the capability IM model presented by John that uses the policy and decorator patterns. This model really improves on the one I circulated last Friday. Despite the patterns, the model is not complicated. In the meantime, John is validating it, both formally and semantically. When it will pass John's validation I'll write the corresponding YANG Data model. I also prepared an informal instance of the model that I circulated in the draft-xibassnez-i2nsf-capability-02 group. This will also be checked after John's validation, aligned with YANG DM (and written in XML, I guess). I'll also provide guidelines to expand the DM instance with all the data that are currently part of the draft-hares-i2nsf-capability-data-model-05 (IMO, it will be a minor rearrangement). When DM and instance will be ready, we'll ask the WG (in particular the other authors of IMs and DMs) to verify if they agree on the proposed DM and process the proposed modifications. Furthermore, I just asked Arnaud Taddei from Symantec to share with us the additional requirements from a multi-domain-of-administration scenario he was mentioning during the I2NSF plenary. I'll process these data and share with you my findings and potential improvements to the I2NSF capability IM and DMs. Finally, the new IM and DM implies changes to the capability IM in draft-xibassnez-i2nsf-capability-02, we'll also align the document to the changes. Regards, Aldo _______________________________________________ I2nsf mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/i2nsf _______________________________________________ I2nsf mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/i2nsf -- regards, John
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
