Re: [Ibnemo] Clearing up some misconceptions, part 1: Technical Questions

[Zhoutianran <[e-mail]>]

Hi John,

Thank you very much for your comments.
You did a great job. That really helps to clarify some concepts.
Please see my reply in line below.
Look forward to the part 2 :)

Best,
Tianran

From: Ibnemo [mailto:[e-mail]] On Behalf Of John Strassner
Sent: Friday, June 19, 2015 8:23 AM
To: [e-mail]
Subject: [Ibnemo] Clearing up some misconceptions, part 1: Technical Questions

Hi all,

I was asked to look at this thread. So I spent the last three days reading every message in the archive between 22/01/2015 and 16/06/2015 (197 messages). Rather than issue 100 or so replies, I thought I would condense my feedback into a series of emails that had specific groups of topics. This is email #1.

There are a number of serious misconceptions that, when fixed, will hopefully allow faster progress to be made. The short summary of these is as follows:

1. Roles.
Roles have been formally designed since at least 1997 (Dirk Bäumer, Dirk Riehle, Wolf Siberski, and Martina Wulf, "The Role Object Pattern", PLoP).
Roles are succinctly defined as objects that represent one or more responsibilities of another entity. Period. They do not "select" things, grant special powers, or cook lunch. They simply represent the responsibilities of one or more actors or objects. (As an aside, this is why the NIST RBAC standard defines users, roles, permissions, operations, and objects as five different types of entities).

Still don't believe me? From INCITS 359, the NIST RBAC standard:
   "Role - A role is a job function within the context of an
    organization with some associated semantics regarding
    the authority and responsibility conferred on the user
    assigned to the role."

This list talks of the roles played by an actor, such as a Customer vs. a NetworkAdmin. The "role" did not grant the NetworkAdmin the power to reconfigure a router interface. The role simply identified this as a responsibility of a person or group playing this role; it is up to that entity and the management system to implement and enforce the reconfiguration.

There are a number of software design patterns that use roles for great value. The policy servers that I have built in the last 15 years have all used the role-object pattern; in fact, I have invented some new role-based patterns. The advantage of roles are many, but a role has nothing to do with intent (see 4 below).

[T]: I agree that “role represents the responsibilities of actors”. We use the role to indentify a set of actors with similar behavior. And then we are going to define a set of intent from the perspective of actors with certain role. That’s the relationship between the role and intent. For example, there may be a role “network admin”. We  want to find out what a network admin want. That’s the set of intent by the network admin’s role.

[T]: I agree that “it is up to that entity and the management system to implement and enforce the reconfiguration”. I have more interest on intent expression, that is the intent based model and NBI. How to implement intent is an open issue.

Some people have said that "one role will not call other roles". This is incorrect. The literature (and especially NIST) talks about hierarchical roles (that is level 2 of the NIST RBAC spec, by the way). Of course roles can interact with other roles - that is why they are full-fledged objects.
[T]: I agree that roles can interact with other roles. I do not know where you find the words “one role will not call other roles”, but I think it has context. In a layered system, upper layer always call lower layer for implementations. But role do not have a relationship with a layer. This implies one role’s intent is not implemented by other roles. For example, an end user have a higher level abstraction then network admin. But the inter actions between this two are peer to peer.

Finally, some people have talked about layers of roles. I agree with Bert, intent should be at the "top layer". Roles do not have a relationship with a layer.
[T]: Here, I agree with Bert and you too.

2. Context.
Context is a set of information and data that MAY affect the outcome of an event, but more importantly, is a definition of the environment in which something is happening, has happened, or will happen. Context is used to understand what is, has, or will happen. Therefore, context can NOT be intent. Context can influence intent, but only if the system allows it.

For example, my intent is to cross the road. The context is that cars are driving at 60 miles per hours on the road. Context is NOT a parameter to my intent in this example; if I am foolish enough to play Frogger with real cars, I deserve what I get. However, the context COULD influence me to wait for a better chance to cross the road, or take a taxi, or do any number of things. My intent has not changed because of context; however, my intent could be influenced by context if I choose to let it.

This applies at lower levels as well. My intent is to have Gold service. My context is that I am directly connected through a switch with one hardware queue. In this case, Gold == Silver == Bronze, because with one hardware queue, it doesn't matter what I **want**, I am only going to get what the hardware is capable of delivering.

I would encourage you all to read some of the DEN-ng papers on context-aware policies (also available in TMF ZOOM). In this approach:
    context selects a working-set of policy rules
    the working set of policy rules collectively define the behavior of the system being managed
    feedback from system state and monitored data may change the context,
     which then changes the working-set of policy rules, so the system
     adapts in a closed-loop manner

[T]: Agree all your comments on “context”. That’s also my perspective.

3. "Equations".
Something of the form A -> B is NOT an equation. Formally, an equation is a statement that the values of two mathematical expressions are equal. I have no idea how to interpret '->'; I have seen some people use this to mean implies (material implication), but typically in logic, one would use the unicode U+21D2 to represent this. Please use "formula" instead of "equation", and please define the symbology that you are using.

[T]: I do not know the “Equation”. No comments.

4. Intent "Equations"
The following is wrong:  User -> intent -> context

Context is NEVER determined by intent; that is in fact exactly backwards!

A more correct version is:
    A user, playing a particular Role in a given context, expresses intent.
   The intent is independent of the role and context.
   However, both may affect how the management system implements this.

[T]:As in the ICIM document, the “equation” is expressed as follows in the UML semantics. “-->” is the association relationship.
Very similar to your expression I think, “a user has a intent in a given context”.
+------+  has    +--------+  in    +---------+
| user +-------->+ intent +------->+ context |
+------+         +--------+        +---------+

By the way, the equation user -> intent-> role -> context is WORSE! What does a role have to do with context? My Customer Role doesn't care if it is WiFi or Intranet or cellular, or what time of the day it is. However, context can affect what can be accomplished:
[T]: If we takes role in account, the relationship would be as follows, which means:”a user playing some roles has as intent in a given context”. And whether your mentioned actor equals to the user? If so I am more clear.
+------+
| role |
+--^---+
   | takes
   |
+--+---+  has    +--------+  in    +---------+
| user +-------->+ intent +------->+ context |
+------+         +--------+        +---------+

   My intent: access my code server
   Business rule: only allow code access through an intranet connection
   Context: authenticated in an L3VPN
   My result:  DENIED

Why? Because my particular context violated a business rule. My intent did NOT change. My role did NOT change. The same result would have happened for different roles and contexts.


5. Intent and Role
Some people have said that intent should be classified by a user's role or set or roles. This doesn't make sense to me.

Roles do not "classify" anything. Roles separate one object with multiple responsibilities into a set of objects, where each Role object defines a particular responsibility. This provides system adaptability. For example, a customer that withdraws and deposits money should be separated into two roles (e.g., what if the customer is a bank employee? :-) ). The customer DID NOT CHANGE in this example. If you don't use roles and still want to obey separation of duty, then artificially splitting the same customer into two objects creates a long list of problems (e.g., separate objects imply separate identities) and still didn't solve the original problem.

Some people have talked about "role-based intent". This doesn't make sense to me.
In the previous paragraphs, I already argued that role and intent MUST be orthogonal. In particular, the following drawing does not make sense to me:

[T]: I do not see why “role and intent must be orthogonal”. My intention is to use the role to indentify a set of actors with similar behavior. And then define a set of intent from the perspective of actors with certain role. The following figure is to explain that intent is not bound to a certain layer.

[http://www.ietf.org/mail-archive/web/ibnemo/current/jpgeskUTBKFLr.jpg]

First, if the roles actually did map to these functions in this way, you would have a very difficult role-engineering problem. Second, the collection of roles in a particular layer serves no purpose other than to categorize those roles. I would hope that intent doesn't care about categorization.

The only case that I can think of where this MAY make some sense is talking about a specific set of Roles (e.g., EndUser vs. NetworkAdmin) and how the intent of the former is conveyed to the latter, so that the latter can act on it. But this is conflating roles (which are about responsibility) with intent (which is about being determines to do something, and focusing on doing that something).

6. Intent and Constraints.
Some people have said that the components of an intent are objects, results, and constraints. I disagree.

Constraints are inputs to an intent. The actor issuing the intent can choose to ignore the constraints (my Frogger or code server download examples) at their own risk - the ultimate mediator is the management system.

Object is too broad a term - it could be an input and/or an output.
[T]: How about intent target?

I also don't understand why a result is part of an intent. An intent is expressing a focused desire to do something independent of whether that results in anything. Perhaps this is just linguistic confusion, but if you want to build a quality language and a quality information model, then formalisms are your friend.

[T]: The result used here is not the final result, but the intended result, i.e. your “desire”. Could you please give more hint on how formalisms can help here?


7. Intent: pure, impure, and other variations.
This just cannot work; that's what we concluded when writing the ONF NBI white paper. If you go down this path, then  everything is intent (pure + impure = 1), and that is not useful. People like to use IP addresses and port numbers and router IDs and ... get over it! Please! These are all elements of prescription. Look at Dave Lenrow's slides (similar slides also appeared at OpenStack in Vancouver last month). There is absolutely no difference between specifying a port number or IP Address for a flow as there is in specifying "Ibuprofen" to solve a headache (when perhaps the headache was caused by something very different than Ibuprofen won't fix).

[T]: The intent expresses what a network service consumer (e.g., application, operator) requires from the network but it does not **completely** specify or constrain how that service may or should be delivered by the network. So imho, compared to the complete “how” which is not intent, “what” plus some “how” could be an impure intent.

Constraints are an important part of policy-based management. Constraints do not have to be included, but most real-world examples are filled with constraints, so the ability to represent them is critical.
[T]: Agreed.

Intent should always have the ability to have constraints and context added to it. While both are independent of intent, both MAY restrict the results obtained from the intent request.
[T]: To me, it’s about information organization. We can discuss whether context and constraint should be in  intent. Right now, in the ICIM document, context is outside the intent expression.

8. Intent and Declarative Interfaces.
Intent (or goal-driven) policy interfaces are NOT NEW. Jeff Kephart and I gave a tutorial at NOMS 2006 on policy management, and covered goal-based policies (and how they are different from other types of policies). This built on about a decade of previous work. This is one of the reasons why OpenStack Congress uses Datalog (well technically, we've extended the Datalog syntax a bit), because it is purely declarative, and mathematically formal. This latter gives very nice properties (order of Datalog statements do NOT matter, I can guarantee that ANY query is computable if it follows some simple rules, ...).

[T]: I do not quite understand the logic here. You did not give the relationship between intent and declarative. Do you mean Congress use datalog, so it is intent based?
FYI, Congress uses datalog to query tables, and the information include ip address, id and many other details, which you may think are not intent.

9. Policy Continuum.
I do not understand how people can say that the Policy Continuum has anything to do with layers. If you don't believe Bob, then please listen to me as the inventor of the concept:
   a) the paper cited (there are many more) does NOT EVEN MENTION the word Layer
   b) if it was a layered system, I would have called it LAYERED Policies or Policy LAYERS.
   c) the definition of a continuum is a **continuous sequence** in which adjacent elements are not noticeably different from each other, but the extremes of the continuum are very different from each other. It has NOTHING to do with layers.

[T]: Do you mean policy is layered, but policy continuum is not layered? I am still confused.

The Policy Continuum was invented because policy has many different actors that want to use it. Defining SLAs is defining policy. Defining when the drop probability of a packet in a particular queue should be increased or decreased is policy. Many things between these extrema are policy. More importantly, different actors need to work together to implement E2E policy. However, each actor speaks their own language, and has their own set of concepts and terminologies. Trying to get this to change is a waste of time. Hence, the policy continuum embraced this diversity, and said (as Bob did) that the real problem is the nature and number of translations that are required.

The policy continuum defines the contexts for different roles in the system. If you don't want to use roles, the policy continuum defines context for all policies, whether they are intent-based or not. The key point of the policy continuum is that it defines different actors for different policies, and mandates a translation between these continuum levels. This is the exact problem that provides difficulty for people dealing with intent - they don't know how to translate a high-level, technology-independent description of intent into anything specific.

[T] Sounds interesting. Can I say policy continuum designed a framework and mechnism to implement policy translation from top down? I am interested about intent expression and capturing specific intent from different roles.

10. REST.
REST is NOT a protocol, please stop calling it a protocol.

11. Intent being expressed by different Roles (Actors).
This gets VERY hard. I've graduated three Ph.D. students who did work on policy management (all used the policy continuum, all used an information model, 2 used DSLs). Unless you have a very RICH information model, this is impossible to do. You likely also need an ontology to formally define the semantics and meaning of different information model objects.

Example: A Router says "forward" and "drop", a firewall says "accept" and "reject". How does the machine know which verb to use when traffic goes through both? This is a trivial problem compared to different actors that can use the same language with different data objects. I would strongly suggest that you first focus on one Role.

[T]: Yes. Our methodology it to focus on roles one by one.

Note that this is compounded by your very lightweight model. For example, a node can be anything from a sub-network to a port on a device. I don't see how that is helpful, especially in constructing a DSL. But that is a longer discussion.

12. Formalisms.
This project confuses me - there seems to be a tendency to avoid the use of formalisms, even though two very specific formalisms (info model and DSL) are being proposed. I think that part of the confusion over the 100+ email discussions on intent derives from this lack of formalism. For example, you need to define what intent is, and what it isn't, precisely. Having "impure" intent, or intent with this set of conditions vs. that set of conditions, or intent on a Sunday, is the path to madness. Impure intent is, by definition, not formally expressible (unless you count intensional definitions as a type of formalism).

[T]: What kind of formalism do you think we need? Take the example, how to dedine "what intent is" formally? I think it may be great if you would like to help us for the formalism.

regards,
John

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:   [e-mail]<mailto:[e-mail]>