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

["Bert Wijnen (IETF)" <[e-mail]>]

thanks John. I hope this helps us.
I think what you say aligns with what I have sated on this list too, although I used quite different words.
And certainly I did not embark on the polciy continuum at all.

Bert


On 19/06/15 02:23, John Strassner wrote:
>
> 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).
>
> 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.
>
> 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.
>
> *_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
>
> *_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.
>
> *_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.
>
> 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:
>
>    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:
>
> 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.
>
> 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.
>
> *_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).
>
> 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.
>
> 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.
>
> *_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, ...).
>
> *_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.
>
> 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.
>
> *_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.
>
> 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).
>
> 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]>_*
>
>
>
> _______________________________________________
> Ibnemo mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ibnemo