[Ibnemo] 答复: 答复: 答复: [Sdn] Defining a Common Model for intent

["zhangyali (D)" <[e-mail]>]

Hi Bert,

I always agree with you about your roles list and I do agree that they are the typical roles in network system. 

As the picture in last mail, I think the access scope of roles defined in RBAC may be larger than the functions could be used to express intent for that roles. 

For example, a network operator could take use of detailed configurations to fulfill the connectivity of two routers. These configuration functions belong to the access scope of this role. But it is ok for this role to express a intent about a connection between these two routers and may assign corresponding technology.

So, in my opinion, access authority give scope of available objects and actions, but some of these access may not be cared about for a user, so these access (low level) will not be used to express intent.

And sorry for confusing you for using "intent role". In fact, the real meaning of mine is these high level functions will be used to express intent which are different with high level operations.

Best,
Yali

-----邮件原件-----
发件人: Bert Wijnen (IETF) [mailto:[e-mail]] 
发送时间: 2015年6月16日 16:51
收件人: zhangyali (D); DIEGO LOPEZ GARCIA
抄送: [e-mail]; Dave Hood; Susan Hares; [e-mail]
主题: Re: 答复: [Ibnemo] 答复: [Sdn] Defining a Common Model for intent

Yali,
Let me try to restate/explain my views again.
As I said, it may be just me. Or maybe my background that I have in areas of RBAC and such things.

Earlier in this thread I have stated:

    I see roles as:
    - user/end-user or customer
    - service provider
    - network achitect
    - network operator
    - maybe also trouble-shooter

I think you had stated that you sort of liked that list. Maybe I misunderstood.

I think I have also stated that, based on your roles you can express diffeent types of intent or express intent on different types of objects.

So a person/application in an end-user role can express intent aka:
- I want a link of 1Gbps from A to B
- I want a set of load balanced links from A to B
- Want a link from A to B with a backup in case something happens Such a person/app cannot express roles aka:
- I want a to reserve 1GBPs bandwidth on routers R1, R3 and R4
- I want the link from A to B to be setup between IP address A1 and IP address B1 The latter type of expression of intent are typically for persons in the role of network architect or network operator.
So based on your role, you get access to the set of "intent expressions" that belong to your role.
That access is based on a system that uses RBAC (I would think).

"intent role" seems a weird concept to me. If you/others think that it exists, then I am probably still very much confused.

Bert

On 16/06/15 09:49, zhangyali (D) wrote:
>
> Hi Bert,
>
> Sorry for not expressing my meaning explicitly. According to my 
> understanding (have not confirmed with Diego), the relationship between access roles and intent roles can be show below.
>
> 图片1.png
>
> Access role restrict the scope of available objects and actions, and 
> according to different network abstraction views, access role could express result/actions in high level. This high level part will be our intent role.
>
> That is just my understanding, please point it out if it is wrong.
>
> Best,
>
> Yali
>
> -----邮件原件-----
>
> 发件人: Bert Wijnen (IETF) [mailto:[e-mail]]
>
> 发送时间: 2015年6月16日14:12
>
> 收件人: zhangyali (D); DIEGO LOPEZ GARCIA
>
> 抄送: [e-mail]; Dave Hood; Susan Hares; [e-mail]
>
> 主题: Re: [Ibnemo] 答复: [Sdn] Defining a Common Model for intent
>
> 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]; Dave Hood; [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]>> 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]>; Dave Hood;
>
> > [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]>> 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]>; Dave
>
> > Hood;[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]>> 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]>; Dave Hood;[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]>> 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]> *Cc:*[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]> *Cc:*[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]> *Cc:*[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]> *Cc:*[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]> *Cc:*[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]> *Cc:*Zhoutianran; Xiayinben;[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]> *Cc:*'Zhoutianran'; 
> > 'Xiayinben';[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]>
>
> > 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
>