Re: [Ibnemo] [Sdn] Defining a Common Model for intent

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

Diego, not sure I understand what you are trying to say, but I think my conclusion is
that w.r.t. aspects of roles, we agree that

- The various roles will have different sets of functions at their disposal
- Access to those function is controlled via an RBAC system which takes these roles into account

I think we also agree (and did express so in our postings) that the roles should not be
hard-coded into the system, and that the we should be able to dynamically define them.

I still have concerns about the term "view". I think we agree that each role has its own
set of function at its disposal. The exact set of such function would also be better dynamic and
not be hard-coded.

Are we in sync now?

Bert

On 22/06/15 09:29, DIEGO LOPEZ GARCIA wrote:
> Hi Bert,
>
> Reviewing my pending e-mail I have noticed I did not reply to this. The discussion has been ongoing and may be I come a little 
> late to this, but just let me note I was trying to highlight that when talking about roles we were talking about two different 
> aspects (access control and functional) and that I did not think it was a good idea to predefine them in any case, but to make the 
> language we used and its underlying formalism support those two aspects.
>
> If the common use of the term role is essentially associated with access control I agree is wiser to restrict it to that 
> environment. For the other aspect I'd prefer to use the term "view", but again if there is another term in widest use I'd be happy 
> to endorse it. But, let me insist, let's define mechanisms for supporting them, and not go and predefine them.
>
> Be goode,
>
> On 16 Jun 2015, at 14:15 , Bert Wijnen (IETF) <[e-mail] <mailto:[e-mail]>> wrote:
>
>> Hi Diego.
>>
>> So I wonder why we try to define two TYPES of roles. What you call "views" below or what I call "sets of intent expressions"
>> are probably the same. They indeed consist of sets of objects and actions which can be used. But I do not call them roles.
>> At lest, that triggers something in my brain that gets me confused.
>>
>> Why would we confuse anyone by using terms like "functional roles" and "access roles".
>>
>> As I have stated a few times. I think:
>> - people or applications act in a certain role (end-user, network architect, operator, trouble shooter)
>> - they can use expressions of intent. Based on the role they assume/play, they can use a set
>>   of (dynamically defined, fine by me, actually best indeed) they have a set of objects that they can
>>   specify intention for/with.
>> - Based on their role they get access (are allowed to) use such objects in their intent expressions.
>>   The access control for that is (in my view) called or based on an RBAC system/mechanism.
>>   So if we have objects like "link", "node', "router", "security-mechanism"
>>   I would think that someone in the end-user role would not be allowed to express intent
>>   about routers or security mechanism, whereas an operator probably would
>>   So if a user or program in the end-user role, tries to express intent for a router,
>>   the access control system would deny that based on the role (so RBAC).
>>   If someone in an operator role tries to express intent for a router, then the access control
>>   system would allow that based on the role (again, RBAC).
>>
>> I think we should use "roles" only for "functions" like end-user, network architect, operator,
>> trouble shooter... there may be a few more. Again we would allow to define them dynamically
>> so we can add roles if needed easily. I can see that in ICIM we define an abstract class of Role
>> from which we derive specific classes like EndUser, Operator, NetworkArchitect.
>> I can see that in ICIM we define a class User, which gets a reference to one or more
>> specific roles, which then identifies that user to be allowed to play in that role.
>>
>> If you want to use the word "views" for "sets of intent expressions", then fine.
>> I would strongly suggest not to use "functional roles". As you can already see from our discussions
>> here, we have a lot of confusion and misunderstanding. How would people new to our ICIM
>> understand the differenes. Would they not get confused too quickly?
>>
>> I am not sure "views" is the best term for it either .
>> "set of intent expressions" also is not the ideal term.
>> If we could agree on an easy to understand term for that concept, that would be great.
>>
>> Some thoughts/ideas for that term/concept:
>> -  IntentElements
>> - IntentTargets
>> - IntentAttributes
>>
>> So one would have an IntentElement that is composed of targets and attributes
>> I could think of roles having access/no-access to specific targets
>> I could think of roles having access/no-access to specific attributes of specific targets
>> And since an IntentElement is composed of targets and attributes, that is a set of
>> targets and attributes that allows a defined set if "intent-expressions" So one could
>> give access maybe at that level of IntentElement, which would mean the role is
>> allowed to express intent in terms of wanted attributes (states?) on the set of targets,
>> all defined in the IntentElement.
>>
>> Just thinking aloud to see/hear if we are converting on a common way of thinking about this.
>>
>> Bert
>>
>>
>>
>> On 16/06/15 12:21, DIEGO LOPEZ GARCIA wrote:
>>> Hi Bert,
>>>
>>> I am trying to consistently refer to functional roles as "network views" (in the same way SQL defines views for databases), so 
>>> we keep the term "role" for identifying the access control applicable to a certain user, very much in the RBAC approach you 
>>> mention. Let me try to rephrase it again so we can find some common ground on this:
>>>
>>> 1) Views (functional roles) define how a certain user can express intent, by means of identifying the network objects and 
>>> operations the user can interact with
>>>
>>> 2) Roles (access roles) define which of the view objects and actions a user can invoke by applying access control rules on those 
>>> objects and actions.
>>>
>>> Be goode,
>>>
>>> On 16 Jun 2015, at 07:12 , Bert Wijnen (IETF) <[e-mail] <mailto:[e-mail]> <mailto:[e-mail]>> wrote:
>>>
>>>> Sorry, but I suspect I am getting confused again.
>>>>
>>>> Roles are roles in my view. And based on your role, you get access to ceratin things
>>>> (types of intent expressions you can tell to the system).
>>>> The access control to the various "intent expressions" will be based on a role.
>>>> And so you have RBAC. Or am I still confused here?
>>>>
>>>> Bert
>>>>
>>>>
>>>>
>>>> On 16/06/15 04:40, zhangyali (D) wrote:
>>>>>
>>>>> Hi, Diego,
>>>>>
>>>>> Definitely agree with you. Ore-defining general roles is difficult and unreasonable because of the diversity of systems and 
>>>>> variability of dividing perspective. However, pre-defining some typical roles that consist with most network system will be 
>>>>> helpful for us to analyze intent common information model.
>>>>>
>>>>> As you have explained the difference of functional roles and access roles, I think they are two dimensions of roles, that is, 
>>>>> access roles defines the scope of functional roles. But I have a doubt is that access roles just define scope of network 
>>>>> abstraction who would not express intent. In ICIM (Intent Common Information Model), user own one or more roles and express 
>>>>> intent, so user is the combination of functional roles, do you agree that?
>>>>>
>>>>> Best,
>>>>>
>>>>> Yali
>>>>>
>>>>> *发件人:*DIEGO LOPEZ GARCIA [mailto:[e-mail]]
>>>>> *发送时间:*2015年6月14日18:41
>>>>> *收件人:*zhangyali (D)
>>>>> *抄送:*Susan Hares; [e-mail] <mailto:[e-mail]> <mailto:[e-mail]>; Dave Hood; [e-mail] 
>>>>> <mailto:[e-mail]> <mailto:[e-mail]>
>>>>> *主题:*Re: [Ibnemo] [Sdn] Defining a Common Model for intent
>>>>>
>>>>> Hi Yali,
>>>>>
>>>>> Defining some typical roles and their pre-defined views (in terms of actions that are available to them) makes sense to me. 
>>>>> What I'd like to avoid is to freeze that set of predefined roles as the only ones suitable to be used from the functional 
>>>>> point of view.
>>>>>
>>>>> Be goode,
>>>>>
>>>>> On 11 Jun 2015, at 04:28 , zhangyali (D) <[e-mail] <mailto:[e-mail]> 
>>>>> <mailto:[e-mail]> <mailto:[e-mail]>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> Hi Diego,
>>>>>
>>>>> Agree with you. We do not need to predefine roles in a system because of the diversity of systems and roles. And if a user 
>>>>> could tie multiply roles, it needs a rule to restrict the combination.
>>>>>
>>>>> But when we consider a common intent model, maybe we can try to define some typical roles in network system and analyze the 
>>>>> real intent of each role. For example, Pedro has provided some typical roles, such as, end-user, service provider, network 
>>>>> architecture, network operator, etc. Do you think this way make sense?
>>>>>
>>>>> Best,
>>>>>
>>>>> Yali
>>>>>
>>>>> *发件人:*DIEGO LOPEZ GARCIA [mailto:[e-mail]]
>>>>> *发送时间:*2015年6月11日0:49
>>>>> *收件人:*zhangyali (D)
>>>>> *抄送:*Susan Hares; [e-mail] <mailto:[e-mail]> <mailto:[e-mail]> <mailto:[e-mail]>; Dave Hood; [e-mail] 
>>>>> <mailto:[e-mail]> <mailto:[e-mail]> <mailto:[e-mail]>
>>>>> *主题:*Re: [Ibnemo] [Sdn] Defining a Common Model for intent
>>>>>
>>>>> Hi Yali,
>>>>>
>>>>> Nothing to excuse about. We are discussing here to understand one another.
>>>>>
>>>>> I don't think we should predefine the roles by any means, just provide support in the language to define the, What I refer to 
>>>>> when talking about compositional semantics was about defining how the views (available objects or invariants as Pedro says) or 
>>>>> permissions (operations allowed) for a user can be built by combining the different roles a user can have. We'd need to define 
>>>>> precedence rules (or a similar mechanism) to solve conflicts and avoid inconsistencies, which may become a source of serious 
>>>>> security breaches.
>>>>>
>>>>> Be goode,
>>>>>
>>>>> On 10 Jun 2015, at 04:17 , zhangyali (D) <[e-mail] <mailto:[e-mail]> 
>>>>> <mailto:[e-mail]> <mailto:[e-mail]>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Hi Diego,
>>>>>
>>>>> Sorry for mistake your idea, and thanks for giving me a clarification.  I do think these mapping of roles are important in 
>>>>> designing intent modeling.
>>>>>
>>>>> For you said that “we should a clear role compositional semantics”, do you have some consideration about what roles we should 
>>>>> have or the principle of classification?
>>>>>
>>>>> Best,
>>>>>
>>>>> Yali
>>>>>
>>>>> *发件人:*DIEGO LOPEZ GARCIA [mailto:[e-mail]]
>>>>> *发送时 间:*2015年6月10日5:33
>>>>> *收件人:*zhangyali (D)
>>>>> *抄送:*Susan Hares;[e-mail] <mailto:[e-mail]> <mailto:[e-mail]> <mailto:[e-mail]>; Dave Hood;[e-mail] 
>>>>> <mailto:[e-mail]> <mailto:[e-mail]> <mailto:[e-mail]>
>>>>> *主题:*Re: [Ibnemo] [Sdn] Defining a Common Model for intent
>>>>>
>>>>> Hi Yali,
>>>>>
>>>>> I'd not say there are two classifications of roles, but two mapping of roles onto the intended modeling language. One related 
>>>>> to the abstraction available to each role, and the other in terms of a security model that identifies which operations a role 
>>>>> can invoke.
>>>>>
>>>>> And yes, roles define a different dimension than users. A role, for sure, can be assigned to several users. And a user can 
>>>>> have several roles, though in that case we should a clear role compositional semantics.
>>>>>
>>>>> Be goode,
>>>>>
>>>>> On 9 Jun 2015, at 04:03 , zhangyali (D) <[e-mail] <mailto:[e-mail]> 
>>>>> <mailto:[e-mail]> <mailto:[e-mail]>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Hi Diego,
>>>>>
>>>>> Thanks for your consideration about the concept of role. From my understanding about your type of role (please point it out if 
>>>>> my understanding is not right), you think there are two classification methods of roles overall. One method is distinguish 
>>>>> roles depending on their operation scope, which focus on which roles are restricted to do some specific operations. Another 
>>>>> method for distinguish roles by network abstraction model layer, and in any abstraction model, user could express specific intent.
>>>>>
>>>>> In my opinion, these two methods are important to understand the meaning of roles. The constraint of intent content is related 
>>>>> with user’s roles. For example, database in the whole system could not be deleted by non-administrators. So 
>>>>> non-administrators’intent could not express the intent of deleting system. So users’role will constraint users’intent.
>>>>>
>>>>> In one network abstraction view, users roles could express their intent which depend on this abstraction view. While in some 
>>>>> cases, one user may contain several roles, so one user can express various view of intent. Do you have any comments about this?
>>>>>
>>>>> Best,
>>>>>
>>>>> Yali
>>>>>
>>>>> *发件人:*DIEGO LOPEZ GARCIA [mailto:[e-mail]]
>>>>> *发送时间:*2015年6月7日1:41
>>>>> *收件人:*Susan Hares
>>>>> *抄送:*[e-mail] <mailto:[e-mail]> <mailto:[e-mail]> <mailto:[e-mail]>; Dave Hood;[e-mail] 
>>>>> <mailto:[e-mail]> <mailto:[e-mail]> <mailto:[e-mail]>
>>>>> *主题:*Re: [Ibnemo] [Sdn] Defining a Common Model for intent
>>>>>
>>>>> Hi Sue,
>>>>>
>>>>> I tend to agree with your idea of roles, though I'd say that in the concept of role we are discussing here I see two aspects 
>>>>> that could (should?) be addressed separately.
>>>>>
>>>>> On the one hand, we have the role as a security concept, defining what a particular user is allowed to do or not do, and 
>>>>> therefore RBAC would become the natural solution for the security model to be applied to intent expressions. The language 
>>>>> should support mechanisms to define such roles and to associate these roles to users and to intent expressions by identifying 
>>>>> the objects, results or conditions that can be invoked in a expression by a certain role.
>>>>>
>>>>> On the other, we have role as modeling element: depending on the role they have, users would be able to see a different 
>>>>> network model, and to employ different intent expressions. This has to do with the particular network abstraction being 
>>>>> accessible to each role, and would require the modeling language to support the definition of "abstraction views" and 
>>>>> associating them with roles.
>>>>>
>>>>> I hope it is clear to all that in both cases the ability to make specific expressions for a certain role is limited, though 
>>>>> limitations are enforced at different points in the processing of the expressions, and they imply different requirements on 
>>>>> the modeling language and the platform(s) supporting it. And, as far as I can tell, supporting both would be highly desirable...
>>>>>
>>>>> Be goode,
>>>>>
>>>>> On 5 Jun 2015, at 19:41 , Susan Hares <[e-mail] <mailto:[e-mail]> <mailto:[e-mail]> 
>>>>> <mailto:[e-mail]>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Fengkai:
>>>>>
>>>>> The key point about roles is where do they fit within the network-SQL Diego talks about.  The basic concepts from 
>>>>> draft-xia-ibnemo-icim-00 make sense to me as part of the SQL
>>>>>
>>>>> Usersà(have) intentà(expressed) in context
>>>>>
>>>>> Intent (is made of) ==  object (constraint in node, connection, flow ), results (constraint in expect/avoid), operation 
>>>>> (constraint, in condition and action)
>>>>>
>>>>> If Roles are a type of intent, then there must be a qualifier on our intent definition above).
>>>>>
>>>>> If role are constraints that impact object, result, and operation, then we can model roles by simply indicating what 
>>>>> constraint the role plays.  In Nemo, we create a model that provides a model for network objects (nodes, connection, and data 
>>>>> flows/action.  If a role forms a grouping of constraints (or class), you can translate roles to a set of pre-defined 
>>>>> properties that can be associated with a pre-defined type of objects (Node, link, and dataflow/action), or results 
>>>>> (Expect/Avoid p2pconnect or mp2mpconnect), or operations (Flows of 1 Gbps).
>>>>>
>>>>> What does this mean for the user?  The network SQL sets up libraries to define roles because it is simply constraints on the 
>>>>> components of intent.
>>>>>
>>>>> What do you think of my idea of roles? I can give this as business (non-network, or Provider business), or as a end-user role.
>>>>>
>>>>> Sue
>>>>>
>>>>> *From:*Lifengkai (Fengkai) [mailto:[e-mail]]
>>>>> *Sent:*Thursday, June 04, 2015 8:48 PM
>>>>> *To:*Susan Hares; 'Dave Hood';[e-mail] <mailto:[e-mail]> <mailto:[e-mail]> <mailto:[e-mail]>
>>>>> *Cc:*[e-mail] <mailto:[e-mail]> <mailto:[e-mail]> <mailto:[e-mail]>
>>>>> *Subject:*RE: [Ibnemo] [Sdn] Defining a Common Model for intent
>>>>>
>>>>> Sue and all,
>>>>>
>>>>> Yes, they are concepts with roles taken into consideration.  Here a little further explanation:
>>>>>
>>>>> I think grouping of roles by level is just one way, but not should be, and the key point here is roles. We are trying to 
>>>>> define intent with the role classifications (the other thread in this mail list).
>>>>>
>>>>> For the accurate intent for each categories of different networks users, theirs roles appears fundamentally important and are 
>>>>> the basis for the definition.
>>>>>
>>>>> I think role identification and distinguishing should be the potential work.
>>>>>
>>>>> Sue, any thoughts about this potential work? And how about others?
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Fengkai
>>>>>
>>>>> *From:*Susan Hares [mailto:[e-mail]]
>>>>> *Sent:*Friday, June 05, 2015 2:35 AM
>>>>> *To:*Lifengkai (Fengkai); 'Dave Hood';[e-mail] <mailto:[e-mail]> <mailto:[e-mail]> <mailto:[e-mail]>
>>>>> *Cc:*[e-mail] <mailto:[e-mail]> <mailto:[e-mail]> <mailto:[e-mail]>
>>>>> *Subject:*RE: [Ibnemo] [Sdn] Defining a Common Model for intent
>>>>>
>>>>> Fengkai and all:
>>>>>
>>>>> I agree with Yali that context is often omitted.   Thank you for filling in these business roles to the 2 site example.  In 
>>>>> all of these, I believe we have grouping of roles by level under the users intent
>>>>>
>>>>> HQ manager userànetwork manager(s)àindividual user(s)
>>>>>
>>>>> It appears that at each level the intent is related, but at each level the intent’s (object, result and constraint) is refined 
>>>>> into a different concept due to different roles.  Is this what it appears to you?
>>>>>
>>>>> Sue
>>>>>
>>>>> *From:*Ibnemo [mailto:[e-mail]]*On Behalf Of*Lifengkai (Fengkai)
>>>>> *Sent:*Thursday, June 04, 2015 12:42 AM
>>>>> *To:*Susan Hares; 'Dave Hood';[e-mail] <mailto:[e-mail]> <mailto:[e-mail]> <mailto:[e-mail]>
>>>>> *Cc:*[e-mail] <mailto:[e-mail]> <mailto:[e-mail]> <mailto:[e-mail]>
>>>>> *Subject:*Re: [Ibnemo] [Sdn] Defining a Common Model for intent
>>>>>
>>>>> Hi Sue and all,
>>>>>
>>>>> For the example, I see Yali has given one in her email, just copying here:
>>>>>
>>>>> “For example, an end-user wants to make the communication between two sites is the minimum. For this intent, price is the 
>>>>> context. Though context is omitted usually, it is really an important factor to affect the decision.”
>>>>>
>>>>> I would like to add one more example for better understanding of the concept, and I would like to elaborate it from the point 
>>>>> of user’s roles.
>>>>>
>>>>> Enterprise A has one headquarter and three branches located separately, and the product department within enterprise A has one 
>>>>> sub-department in headquarter and each branch.
>>>>>
>>>>> Based on the product division, the product department manager wants:
>>>>>
>>>>> 1.sub-department in each branch can communicate with sub-department in headquarter
>>>>>
>>>>> 2.sub-department in each branch cannot communicate with each other
>>>>>
>>>>> 3.product department want to enjoy better quality of experience with a budget limit of $50,000
>>>>>
>>>>> Then for the “User-intent-context” format,
>>>>>
>>>>> ØUser, enterprise user with department manager role
>>>>>
>>>>> ØIntent, sub-department connection between headquarter and braches
>>>>>
>>>>> ØContext, better of quality of experience within the budget
>>>>>
>>>>> For the network manager of the enterprise A, based on the product department manager’s requirements, the network manager wants:
>>>>>
>>>>> 1.connects the product sub-departments via: a) full mesh topology with ACLs for communication constraints between subnets; 
>>>>> b)leased line between subnets.
>>>>>
>>>>> 2.SLA parameters configuration for guarantee the quality of experience
>>>>>
>>>>> Then for the “user-intent-context” format,
>>>>>
>>>>> ØUser, enterprise user with network manager role
>>>>>
>>>>> ØIntent, topology set up for communication connection between subnets
>>>>>
>>>>> ØContext, SLA parameters for quality of experience guaranteeing
>>>>>
>>>>> Here is the example that I proposed for the illustration, more specially with roles involved.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Fengkai
>>>>>
>>>>> *From:*Susan Hares [mailto:[e-mail]]
>>>>> *Sent:*Wednesday, June 03, 2015 7:09 AM
>>>>> *To:*Lifengkai (Fengkai); 'Dave Hood';[e-mail] <mailto:[e-mail]> <mailto:[e-mail]> <mailto:[e-mail]>
>>>>> *Cc:*[e-mail] <mailto:[e-mail]> <mailto:[e-mail]> <mailto:[e-mail]>
>>>>> *Subject:*RE: [Ibnemo] [Sdn] Defining a Common Model for intent
>>>>>
>>>>> Fengkai:
>>>>>
>>>>> In this you are talking about the difference between the IT and Non-IT person’s context of an intent within a role.  I believe 
>>>>> your examples show that
>>>>>
>>>>> Useràintentàcontext
>>>>>
>>>>> is very important as https://datatracker.ietf.org/doc/draft-xia-ibnemo-icim/states.   I am still struggling to understand how 
>>>>> the “fitting” works.  Can you provide additional examples?
>>>>>
>>>>> Sue
>>>>>
>>>>> *From:*Ibnemo [mailto:[e-mail]]*On Behalf Of*Lifengkai (Fengkai)
>>>>> *Sent:*Tuesday, June 02, 2015 3:47 AM
>>>>> *To:*Dave Hood; Susan Hares;[e-mail] <mailto:[e-mail]> <mailto:[e-mail]> <mailto:[e-mail]>
>>>>> *Cc:*[e-mail] <mailto:[e-mail]> <mailto:[e-mail]> <mailto:[e-mail]>
>>>>> *Subject:*Re: [Ibnemo] [Sdn] Defining a Common Model for intent
>>>>>
>>>>> Hi Dave and all,
>>>>>
>>>>> Thanks for proposing the two valuable intent use cases.
>>>>>
>>>>> For the use case 2, I agree that the IT employee needs to include the details of ports/protocols into his/her intent 
>>>>> descriptions, but those may not be in the intent context scope of a non-IT employee. Have a further consideration with this, 
>>>>> different users of the network have their own intent in a specific domain. Then the roles/actors of network users, such as end 
>>>>> users, application developers, tenant IT/network administrators, operator network administrators, are valuable to be 
>>>>> identified and distinguished, thus fitting the intent requirements of the network users with different roles.
>>>>>
>>>>> Any thoughts about this consideration?
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Fengkai
>>>>>
>>>>> *From:*sdn [mailto:[e-mail]]*On Behalf Of*Dave Hood
>>>>> *Sent:*Tuesday, June 02, 2015 1:38 AM
>>>>> *To:*Susan Hares;[e-mail] <mailto:[e-mail]> <mailto:[e-mail]> <mailto:[e-mail]>
>>>>> *Cc:*Zhoutianran; Xiayinben;[e-mail] <mailto:[e-mail]> <mailto:[e-mail]> <mailto:[e-mail]>
>>>>> *Subject:*Re: [Sdn] Defining a Common Model for intent
>>>>>
>>>>> An excerpt from an email I sent on the ONF NBI list, which may contain some useful thoughts:
>>>>>
>>>>> I have always had trouble understanding what an intent really is, so I am looking forward to making the concept more precise.
>>>>>
>>>>> When I click a link on a web page, I express an intent to invoke whatever that link offers. Completely below the surface is a 
>>>>> layer stack, on-demand session establishment, DNS look-ups, server load balancers, and any number of other technological 
>>>>> features that are of no interest to me. Why not use that as an example of intent?
>>>>>
>>>>> Better yet, we talk about negotiation and selection. Suppose I want to buy a widget. I probably already have some idea whether 
>>>>> I want to go to Amazon or EBay or somewhere else. Suppose it’s Amazon. I search Amazon’s catalog and receive an offer of 
>>>>> several widgets, some new, some used, some with a choice of colour or other pertinent features. If I see nothing I like, I may 
>>>>> open a new browser window and check out Best Buy or EBay (lots more hidden technology to make that happen!). Maybe I come back 
>>>>> to the Amazon page, having found nothing I liked better somewhere else. Now I accept one of the offered widgets and go through 
>>>>> the checkout process.
>>>>>
>>>>> Do we agree that this is a fairly pure expression of intent as conceptualized in the paper? (If not, let’s talk about making a 
>>>>> Skype call.)
>>>>>
>>>>> Ok, that’s my intent as an internet user. Let’s assume the network is all SDN of one kind or another. I invoke my intent 
>>>>> through a GUI onto software local to my PC, but I don’t think we can call the PC an SDN controller. It’s more an active 
>>>>> mediator, a client to an SDN. As far as the network is concerned, the client makes DNS queries and swaps opaque TCP packets 
>>>>> over a forwarding path that may already exist, or may need to be learned and set up on demand. This is about right, because 
>>>>> the session content may well be encrypted end to end, and rightly.
>>>>>
>>>>> To the SDN controller, my intent is satisfied by directing DNS queries to a known DNS server somewhere, and ensuring IP 
>>>>> connectivity for the subsequent session. Hmmm… what happened to our intent-based NBI? The SDN offered my PC a packet interface 
>>>>> with the properties of knowing how to recognize and route DNS queries specially, and general IP connectivity. My PC accepted 
>>>>> the service offer implicitly by offering traffic to the data-plane interface. The network could be performing associated 
>>>>> auxiliary services such as usage-based billing (think wireless roaming), so it’s more than just a dumb pipe.
>>>>>
>>>>> If this is not a legitimate example of intent, it would be good to write the white paper in such a way that clearly excludes 
>>>>> such cases.
>>>>>
>>>>> Use case 2: suppose I am a corporate IT employee, and suppose that my intent is to have an E-Line between two of my campi. I 
>>>>> necessarily care about ports and protocols; talk about intent being portable and protocol independent continues to confuse me 
>>>>> completely. How can I order an E-line without caring about such details? [Nor is this intent portable.]
>>>>>
>>>>> Obviously, an SDN controller is going to expose whatever actions and elements of information are germane to the service it 
>>>>> offers, and if ports and protocols are germane to the service, so be it.
>>>>>
>>>>> The SDN architecture, being recursive, models the north side of any controller as exposing an instance of an information 
>>>>> model, customized for the intended client/customer/app/user. That being the case, how do we distinguish an NBI API that 
>>>>> conveys intent (service: same thing?) from one that does not?
>>>>>
>>>>> I have recently come to the view that granularity is the criterion by which an intent or service invocation is distinguished. 
>>>>> Colloquially speaking, a service invocation is a single invocation across the API: give me E-Line. Now of course this turns 
>>>>> into constraint negotiation, offer and acceptance, but what happens across the API is effectively one transaction. In 
>>>>> contrast, what we might agree is **not** an intent or a service is the manipulation of a granular information model, the 
>>>>> explicit visibility of multiple objects, how they are interrelated, their attributes, and the like.
>>>>>
>>>>> ·Network as a single lump vs some non-trivial topology.
>>>>>
>>>>> ·Chauffeur vs driving a car. Legitimate reasons to choose one option or the other, but the level of granularity is quite 
>>>>> different. Shall we agree that driving is too granular to be considered intent?
>>>>>
>>>>> This idea of granularity and detailed operations on the components (which of course may be complex entities themselves, 
>>>>> virtualized into simple-appearing lumps) seems to me to capture the essence of what people are talking about when they say 
>>>>> intent or service. I am not comfortable with the way I am expressing it, so if this is a step in a productive direction, or 
>>>>> even if it’s not, I welcome suggestions to clarify the concept.
>>>>>
>>>>> Dave
>>>>>
>>>>> *From:*sdn [mailto:[e-mail]]*On Behalf Of*Susan Hares
>>>>> *Sent:*Saturday, May 30, 2015 1:02 PM
>>>>> *To:*[e-mail] <mailto:[e-mail]> <mailto:[e-mail]> <mailto:[e-mail]>
>>>>> *Cc:*'Zhoutianran'; 'Xiayinben';[e-mail] <mailto:[e-mail]> <mailto:[e-mail]> <mailto:[e-mail]>
>>>>> *Subject:*[Sdn] Defining a Common Model for intent
>>>>>
>>>>> On this mail list, there has been a discussion of two types of information for Intent and Nemo: 
>>>>> (http://www.ietf.org/mail-archive/web/sdn/current/msg00646.html) :
>>>>>
>>>>> 1)What information is needed to represent a service request,
>>>>>
>>>>> 2)How to represent and transport the information for a request.
>>>>>
>>>>> In order to define what information is needed to represent a 1) service request that signals Intent from an application to a 
>>>>> controller, it is important to define Intent, and provide a clear model of Intent. Also, in describing real use-cases it is 
>>>>> important that one uses the same definition and model for Intent in each use case.
>>>>>
>>>>> In the current forums examining Intent (ODL NIC, ODL Nemo, OF NBI and Keystone, OPNFV Movie, OpenStack) there is a realization 
>>>>> that Intent occurs at multiple layers.  The authors of draft-xia-ibnemo-icim have created a definition for intent and a 
>>>>> unified model for defining intent which can handle 1 or multiple layers. The model suggest that:
>>>>>
>>>>> 1)A user has a intent that is expressed in a context.
>>>>>
>>>>> 2)Intent (usually) involves an object with a result, and optionally includes operations toward that result.
>>>>>
>>>>> 3)Operations conditions perform actions within/modified by constraints.
>>>>>
>>>>> We believe this defines clearly what others are calling “pure intent” (objects + results) versus “constrained intent” (objects 
>>>>> + operations + constraints).   The draft can be found at: https://datatracker.ietf.org/doc/draft-xia-ibnemo-icim/.   The 
>>>>> authors are looking for feedback on the concepts in the draft.
>>>>>
>>>>> Sue Hares
>>>>>
>>>>> _______________________________________________
>>>>> Ibnemo mailing list
>>>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]> <mailto:[e-mail]>
>>>>> https://www.ietf.org/mailman/listinfo/ibnemo
>>>>>
>>>>> --
>>>>> "Esta vez no fallaremos, Doctor Infierno"
>>>>>
>>>>> Dr Diego R. Lopez
>>>>> Telefonica I+D
>>>>> http://people.tid.es/diego.lopez/
>>>>>
>>>>> e-mail:[e-mail] <mailto:[e-mail]>
>>>>> Tel:    [phone]
>>>>> Mobile: [phone]
>>>>> ----------------------------------
>>>>>
>>>>> ------------------------------------------------------------------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o 
>>>>> confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda 
>>>>> notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la 
>>>>> legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía 
>>>>> y proceda a su destrucción.
>>>>>
>>>>> The information contained in this transmission is privileged and confidential information intended only for the use of the 
>>>>> individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that 
>>>>> any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this 
>>>>> transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in 
>>>>> error and then delete it.
>>>>>
>>>>> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial 
>>>>> e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de 
>>>>> que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se 
>>>>> recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
>>>>>
>>>>> --
>>>>> "Esta vez no fallaremos, Doctor Infierno"
>>>>>
>>>>> Dr Diego R. Lopez
>>>>> Telefonica I+D
>>>>> http://people.tid.es/diego.lopez/
>>>>>
>>>>> e-mail:[e-mail] <mailto:[e-mail]>
>>>>> Tel:    [phone]
>>>>> Mobile: [phone]
>>>>> ----------------------------------
>>>>>
>>>>> ------------------------------------------------------------------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o 
>>>>> confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda 
>>>>> notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la 
>>>>> legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía 
>>>>> y proceda a su destrucción.
>>>>>
>>>>> The information contained in this transmission is privileged and confidential information intended only for the use of the 
>>>>> individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that 
>>>>> any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this 
>>>>> transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in 
>>>>> error and then delete it.
>>>>>
>>>>> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial 
>>>>> e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de 
>>>>> que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se 
>>>>> recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
>>>>>
>>>>> --
>>>>> "Esta vez no fallaremos, Doctor Infierno"
>>>>>
>>>>> Dr Diego R. Lopez
>>>>> Telefonica I+D
>>>>> http://people.tid.es/diego.lopez/
>>>>>
>>>>> e-mail:[e-mail] <mailto:[e-mail]>
>>>>> Tel:    [phone]
>>>>> Mobile: [phone]
>>>>> ----------------------------------
>>>>>
>>>>> ------------------------------------------------------------------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o 
>>>>> confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda 
>>>>> notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la 
>>>>> legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía 
>>>>> y proceda a su destrucción.
>>>>>
>>>>> The information contained in this transmission is privileged and confidential information intended only for the use of the 
>>>>> individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that 
>>>>> any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this 
>>>>> transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in 
>>>>> error and then delete it.
>>>>>
>>>>> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial 
>>>>> e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de 
>>>>> que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se 
>>>>> recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
>>>>>
>>>>> --
>>>>> "Esta vez no fallaremos, Doctor Infierno"
>>>>>
>>>>> Dr Diego R. Lopez
>>>>> Telefonica I+D
>>>>> http://people.tid.es/diego.lopez/
>>>>>
>>>>> e-mail: [e-mail] <mailto:[e-mail]>
>>>>> Tel:    [phone]
>>>>> Mobile: [phone]
>>>>> ----------------------------------
>>>>>
>>>>> ------------------------------------------------------------------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o 
>>>>> confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda 
>>>>> notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la 
>>>>> legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía 
>>>>> y proceda a su destrucción.
>>>>>
>>>>> The information contained in this transmission is privileged and confidential information intended only for the use of the 
>>>>> individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that 
>>>>> any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this 
>>>>> transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in 
>>>>> error and then delete it.
>>>>>
>>>>> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial 
>>>>> e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de 
>>>>> que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se 
>>>>> recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Ibnemo mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/ibnemo
>>>>
>>>
>>> --
>>> "Esta vez no fallaremos, Doctor Infierno"
>>>
>>> Dr Diego R. Lopez
>>> Telefonica I+D
>>> http://people.tid.es/diego.lopez/
>>>
>>> e-mail: [e-mail]
>>> Tel:    [phone]
>>> Mobile: [phone]
>>> ----------------------------------
>>>
>>>
>>> ------------------------------------------------------------------------------------------------------------------------------------
>>>
>>> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial 
>>> y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la 
>>> lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha 
>>> recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.
>>>
>>> The information contained in this transmission is privileged and confidential information intended only for the use of the 
>>> individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any 
>>> dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in 
>>> error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.
>>>
>>> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e 
>>> é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a 
>>> leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta 
>>> mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
>>
>
> --
> "Esta vez no fallaremos, Doctor Infierno"
>
> Dr Diego R. Lopez
> Telefonica I+D
> http://people.tid.es/diego.lopez/
>
> e-mail: [e-mail]
> Tel:    [phone]
> Mobile: [phone]
> ----------------------------------
>
>
> ------------------------------------------------------------------------------------------------------------------------------------
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y 
> es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la 
> lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha 
> recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.
>
> The information contained in this transmission is privileged and confidential information intended only for the use of the 
> individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any 
> dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in 
> error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é 
> para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a 
> leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta 
> mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição