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

From: Dave Hood <[email-masked]>
Date: Mon, 1 Jun 2015 17:37:59 +0000

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:[email-masked]] On Behalf Of Susan Hares
Sent: Saturday, May 30, 2015 1:02 PM
To: [email-masked]
Cc: 'Zhoutianran'; 'Xiayinben'; [email-masked]
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

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 1 Jun 2015 17:11:32 -0400

Dave:

Thank you for the write-up with so many interesting thoughts.  Your messages
helps bringh up two interesting cases. 

On Case 1: 

In all of these, the user who has "pure intent" exists within a context.  In
the web page, it is the web pages context for the user that can be Best Buy
or Amazon.   The document
<https://datatracker.ietf.org/doc/draft-xia-ibnemo-icim/>
draft-xia-ibnemo-icim-00
(https://datatracker.ietf.org/doc/draft-xia-ibnemo-icim/) points this out. 

On your Case 2: with E-Line between two campi.  Your intent is E-line
connect.  Actually the intent is a connection of between two campi that
carries flows of data   The context is E-line and whatever that means.  

To be practical L3VPN, L2VPN, EVPN are simply contexts for specific types of
network-wide connections.  The IETF L3SM is creating a model for such
network-wide services. 

Sue Hares 

From: sdn [mailto:[email-masked]] On Behalf Of Dave Hood
Sent: Monday, June 01, 2015 1:38 PM
To: Susan Hares; [email-masked]
Cc: 'Zhoutianran'; 'Xiayinben'; [email-masked]
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

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) :

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:

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

---

From: "Lifengkai (Fengkai)" <[email-masked]>
Date: Tue, 2 Jun 2015 07:46:55 +0000

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:[email-masked]] On Behalf Of Dave Hood
Sent: Tuesday, June 02, 2015 1:38 AM
To: Susan Hares; [email-masked]
Cc: Zhoutianran; Xiayinben; [email-masked]
Subject: Re: [Sdn] Defining a Common Model for intent

Dave

From: sdn [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Saturday, May 30, 2015 1:02 PM
To: [email-masked]<mailto:[email-masked]>
Cc: 'Zhoutianran'; 'Xiayinben'; [email-masked]<mailto:[email-masked]>
Subject: [Sdn] Defining a Common Model for intent

Sue Hares

---

From: Dave Hood <[email-masked]>
Date: Tue, 2 Jun 2015 13:26:13 +0000

I agree that the context matters, Fengkai (and Susan in earlier response). What the I-D appears to be saying is that any interaction across an NBI is intent: otherwise the app/tenant/customer wouldn't do it. That's the root of my question from the beginning: how would we know what is *not* intent?

If I ask for some particular microscopically detailed configuration (a "how"), it's because I care, for some reason, about that level of detail. It is in fact part of my intent.

In my IT example, I argue that intent need not be independent of protocols and ports, and that it need not be portable. Your response about context appears to agree.

So as best I can tell, we can say precisely what an intent is, and we can't say what an intent is not. If intent is just the latest buzzword, which it certainly appears to be, can we just say so and leave it to the marketing people?

Dave

From: Lifengkai (Fengkai) [mailto:[email-masked]]
Sent: Tuesday, June 02, 2015 12:47 AM
To: Dave Hood; Susan Hares; [email-masked]
Cc: Zhoutianran; Xiayinben; [email-masked]
Subject: RE: [Sdn] Defining a Common Model for intent

Hi Dave and all,

Best Regards,
Fengkai

From: sdn [mailto:[email-masked]] On Behalf Of Dave Hood
Sent: Tuesday, June 02, 2015 1:38 AM
To: Susan Hares; [email-masked]<mailto:[email-masked]>
Cc: Zhoutianran; Xiayinben; [email-masked]<mailto:[email-masked]>
Subject: Re: [Sdn] Defining a Common Model for intent

Dave

Sue Hares

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 2 Jun 2015 19:09:02 -0400

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:[email-masked]] On Behalf Of Lifengkai
(Fengkai)
Sent: Tuesday, June 02, 2015 3:47 AM
To: Dave Hood; Susan Hares; [email-masked]
Cc: [email-masked]
Subject: Re: [Ibnemo] [Sdn] Defining a Common Model for intent

Hi Dave and all,

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.

 

Best Regards,

Fengkai

EBay or somewhere else. Suppose it’s Amazon. I search Amazon’s catalog and

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.

·         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?

it’s not, I welcome suggestions to clarify the concept.

Dave

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

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 2 Jun 2015 19:22:34 -0400

Dave:

Thank you for restating your excellent question.  "How do we know
[something] is not intent?"  

Let me start an assertion that Intent is declarative policy applied to a
context.  If you accept this assertion, 

Then:

1)      You can tell if the policy is prescriptive rather than
declarative/intent, 

2)      You can tell whether a declarative policy is presented with a
context. 

An example of declarative policy is, connect London and New York with 1 Gbps
data flow between.  How, when, where and why with what - is left up to the
fulfillment of the intent.  The context is networking and business offices.

Do you think I'm on the right track? 

Sue 

From: Dave Hood [mailto:[email-masked]] 
Sent: Tuesday, June 02, 2015 9:26 AM
To: Lifengkai (Fengkai); Susan Hares; [email-masked]
Cc: Zhoutianran; Xiayinben; [email-masked]
Subject: RE: [Sdn] Defining a Common Model for intent

I agree that the context matters, Fengkai (and Susan in earlier response).
What the I-D appears to be saying is that any interaction across an NBI is
intent: otherwise the app/tenant/customer wouldn't do it. That's the root of
my question from the beginning: how would we know what is *not* intent?

If I ask for some particular microscopically detailed configuration (a
"how"), it's because I care, for some reason, about that level of detail. It
is in fact part of my intent. 

In my IT example, I argue that intent need not be independent of protocols
and ports, and that it need not be portable. Your response about context
appears to agree.

So as best I can tell, we can say precisely what an intent is, and we can't
say what an intent is not. If intent is just the latest buzzword, which it
certainly appears to be, can we just say so and leave it to the marketing
people?

Dave

Hi Dave and all,

 

Best Regards,

Fengkai

Dave

Sue Hares

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 2 Jun 2015 19:34:58 -0400

Stuart: 

In some ways, the policy continuum (Davy, Jenning, Strassner) suggest the
layer of models (as ISO did) of business, system, administrator,  device,
and instance. 

I agree with you theoretically that "data model for intent might/should be
different at each level".  There is code-evidence that backs up your point.
The flexibility the Nemo early proof-of-concept demo is enhanced by the
ability to allow a data model to be pass to the controller.  The user really
just needs to signal "intent" and the model passes the context.   Nemo uses
a simple combination of entities, endpoints and connections. 

If we expanded this from the top-down, then the data model would have the
simple context of the user.  As it goes down, the model would get augment
with the context of each layer.  Much like the tree with roots at the top.  

This is a fascinating part of the discussion - can you add more details to
your comments? 

Sue 
-----Original Message-----
From: sdn [mailto:[email-masked]] On Behalf Of STUART VENTERS
Sent: Tuesday, June 02, 2015 12:06 PM
To: [email-masked]
Cc: 'Dave Hood'; [email-masked]; Lifengkai (Fengkai); Zhoutianran;
Xiayinben; Susan Hares

I have 2 cents to contribute for this fuzzy intent word and resulting data
model.
Perhaps 'intent'  is just a relatively high level service request.
The problem with this definition is what is that 'relatively high level'
appears to depend on your point of view.

To help think about it, here's a long chain of command for the same action.
It is long for fun and so that anybody can find part of it that they
recognize.

Chain of command:

Investor says: make money
CEO says: make the network work
CIO says: give me bandwidths between sites A, B, and C Net engineer says: I
need these evc's to these endpoints Purchasing agent: Says use this product
from this vendor Sales Person says: Here is the price and priority
Partitioner: divides the end to end circuit among administrative domains
Planner: picks the necessary resources to use, makes the truck rolls happen
Allocator: allocates the necessary bandwidth
Provisioner: decides what provisioning is necessary in each part of the path
Adaptor: tailors the provisioning to a specific box
Driver: pushes the provisioning into the forwarding tables Forwarding
engine: forwards according to the tables

The Investor's statement at the top is clearly what and not how.
The forwarding engine's operations have a lot of how, but maybe little
global view of what we are doing overall.

If we say that the top is intent and the bottom is a is service request,
  who's to say where intent stops and service requests start?

Perhaps  'intent' means a service request coming from a higher layer for
refinement.

That said, the data model for intent might/should be different at each
level.
Since each level is processing the same request at different levels of
detail, it might be similar at each level.
Perhaps the data model starts simple on top and gathers more and more detail
as it gets lower ?
Maybe like a tree with the root at the top and leaves at the forwarding
engines, except distributed.

Perhaps a simple starting point near the top is a combination of entities,
endpoints, and connections.

Regards,

Stuart Venters

Sent: Tuesday, June 02, 2015 8:26 AM

Dave

Hi Dave and all,

Best Regards,
Fengkai

Dave

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 

_______________________________________________
sdn mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/sdn

---

From: Dave Hood <[email-masked]>
Date: Tue, 2 Jun 2015 23:48:11 +0000

Sorry, Sue, but IMO this just introduces new undefined terms:

Declarative - your example looks like an imperative to me. How do I know what is *not* a declarative? X = y + z? Declarative or imperative? I'm not playing games here, I really don't understand how we would distinguish.

Policy - In the SDN architecture, we define pretty clearly what we mean by policy. It is a constraint imposed by a manager that governs the behaviour of a tenant/client/app. But it's not clear what the meaning would be in the present context.

I wonder whether the context you mention (of which I have also not seen a clear definition) is subsumed in the API offered to the tenant/client/app. If I expose a catalog of services at an interface, each service possibly with some options, then have I defined a context for the user of that API? That seems to me to make sense, but is again subject to the observation that any and all APIs expose some subset of the universe, so it isn't apparent what is *not* a context.

Good conversation, please continue. I hope we will all learn something by pushing on these ideas.

Dave

From: Susan Hares [mailto:[email-masked]]
Sent: Tuesday, June 02, 2015 4:23 PM
To: Dave Hood; 'Lifengkai (Fengkai)'; [email-masked]
Cc: 'Zhoutianran'; 'Xiayinben'; [email-masked]
Subject: RE: [Sdn] Defining a Common Model for intent

Dave:

Thank you for restating your excellent question.  "How do we know [something] is not intent?"

Let me start an assertion that Intent is declarative policy applied to a context.  If you accept this assertion,
Then:

1)      You can tell if the policy is prescriptive rather than declarative/intent,

2)      You can tell whether a declarative policy is presented with a context.

An example of declarative policy is, connect London and New York with 1 Gbps data flow between.  How, when, where and why with what - is left up to the fulfillment of the intent.  The context is networking and business offices.

Sue
To: Lifengkai (Fengkai); Susan Hares; [email-masked]<mailto:[email-masked]>

Dave

To: Dave Hood; Susan Hares; [email-masked]<mailto:[email-masked]>

Hi Dave and all,

Best Regards,
Fengkai

Dave

Sue Hares

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 2 Jun 2015 20:15:03 -0400

Dave:  

Thanks for the critique - I really appreciate you refining my concepts.   My
ideas arose out of an informal discussion with Kareeti Kompella at IPOP 2015
on Nemo Intent vs. Juniper's Declarative policy.  However, let me sharpen my
pencil and go back to the Stanford formal papers and other to work the proof
forward.   

Sue 

From: Ibnemo [mailto:[email-masked]] On Behalf Of Dave Hood
Sent: Tuesday, June 02, 2015 7:48 PM
To: Susan Hares; 'Lifengkai (Fengkai)'; [email-masked]
Cc: [email-masked]
Subject: Re: [Ibnemo] [Sdn] Defining a Common Model for intent

Declarative - your example looks like an imperative to me. How do I know
what is *not* a declarative? X = y + z? Declarative or imperative? I'm not
playing games here, I really don't understand how we would distinguish. 

Policy - In the SDN architecture, we define pretty clearly what we mean by
policy. It is a constraint imposed by a manager that governs the behaviour
of a tenant/client/app. But it's not clear what the meaning would be in the
present context.

I wonder whether the context you mention (of which I have also not seen a
clear definition) is subsumed in the API offered to the tenant/client/app.
If I expose a catalog of services at an interface, each service possibly
with some options, then have I defined a context for the user of that API?
That seems to me to make sense, but is again subject to the observation that
any and all APIs expose some subset of the universe, so it isn't apparent
what is *not* a context.

Good conversation, please continue. I hope we will all learn something by
pushing on these ideas.

Dave

Dave:

Then:

 

Sue 

Dave

Hi Dave and all,

 

Best Regards,

Fengkai

Dave

Sue Hares

---

From: "Lifengkai (Fengkai)" <[email-masked]>
Date: Wed, 3 Jun 2015 09:39:25 +0000

Hi Dave,

I think I got the point that you concern. Continuing the consideration in my last email, the intent is specific to the network users with different roles.
With the network user roles in mind, I think we can properly define what is the intent or what is not intent for the specified users. But we cannot generally defining what is or is not intent, unless the user role, from the user perspective is taken into account.

Best Regards,
Fengkai

Sent: Tuesday, June 02, 2015 9:26 PM

Dave

Hi Dave and all,

Best Regards,
Fengkai

Dave

Sue Hares

---

From: Zhoutianran <[email-masked]>
Date: Wed, 3 Jun 2015 09:44:10 +0000

Hi Stuart,

Thanks for this deep thinking with a set of examples. It's really important to clarify this fuzzy intent.
I think all the concern and uncertainty is because of the layered thinking. We think intent is a relatively higher level nested.
What if we think about intent with differnet roles? Just like a relative detailed description in my "role based intent" email.
I think the essential of the role based intent is that there is only one intent layer which is always on the top. Intent is dedicated for corresponding roles. One role will not call other roles interfaces. 
Then we can try to find way to express intent for various roles.

Regards,
Terence

-----Original Message-----
From: sdn [mailto:[email-masked]] On Behalf Of STUART VENTERS
Sent: Wednesday, June 03, 2015 12:06 AM
To: [email-masked]
Cc: 'Dave Hood'; [email-masked]; Lifengkai (Fengkai); Zhoutianran; Xiayinben; Susan Hares
Subject: Re: [Sdn] Defining a Common Model for intent

I have 2 cents to contribute for this fuzzy intent word and resulting data model.
Perhaps 'intent'  is just a relatively high level service request.
The problem with this definition is what is that 'relatively high level' appears to depend on your point of view.

To help think about it, here's a long chain of command for the same action.
It is long for fun and so that anybody can find part of it that they recognize.

Chain of command:

Investor says: make money
CEO says: make the network work
CIO says: give me bandwidths between sites A, B, and C Net engineer says: I need these evc's to these endpoints Purchasing agent: Says use this product from this vendor Sales Person says: Here is the price and priority
Partitioner: divides the end to end circuit among administrative domains
Planner: picks the necessary resources to use, makes the truck rolls happen
Allocator: allocates the necessary bandwidth
Provisioner: decides what provisioning is necessary in each part of the path
Adaptor: tailors the provisioning to a specific box
Driver: pushes the provisioning into the forwarding tables Forwarding engine: forwards according to the tables

The Investor's statement at the top is clearly what and not how.
The forwarding engine's operations have a lot of how, but maybe little global view of what we are doing overall.

Perhaps  'intent' means a service request coming from a higher layer for refinement.

That said, the data model for intent might/should be different at each level.
Since each level is processing the same request at different levels of detail, it might be similar at each level.
Perhaps the data model starts simple on top and gathers more and more detail as it gets lower ?
Maybe like a tree with the root at the top and leaves at the forwarding engines, except distributed.

Perhaps a simple starting point near the top is a combination of entities, endpoints, and connections.

Regards,

Stuart Venters

Dave

Hi Dave and all,

Best Regards,
Fengkai

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.

.         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?

Dave

Sue Hares

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Wed, 03 Jun 2015 15:08:18 +0200

Hi all,

I like the idea of (at least for now) stick to the problem of "intent" for one layer (the top layer).
Let us not boil the ocean and try to do everything that comes up. If we are successful in doing
a model for IBNEMO for the top layer, we can then see if we want to go at more layers.

A role -based intent model? I guess it would just boil down in different types of intent that
fit with the specific role, right?

Bert

On 03/06/15 11:44, Zhoutianran wrote:
> Ibnemo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ibnemo
>

---

From: STUART VENTERS <[email-masked]>
Date: Tue, 2 Jun 2015 16:06:11 +0000

Chain of command:

Investor says: make money
CEO says: make the network work
CIO says: give me bandwidths between sites A, B, and C
Net engineer says: I need these evc's to these endpoints
Purchasing agent: Says use this product from this vendor
Sales Person says: Here is the price and priority
Partitioner: divides the end to end circuit among administrative domains
Planner: picks the necessary resources to use, makes the truck rolls happen
Allocator: allocates the necessary bandwidth
Provisioner: decides what provisioning is necessary in each part of the path
Adaptor: tailors the provisioning to a specific box
Driver: pushes the provisioning into the forwarding tables
Forwarding engine: forwards according to the tables

Regards,

Stuart Venters

Dave

Hi Dave and all,

Best Regards,
Fengkai

Dave

Sue Hares

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 3 Jun 2015 22:22:22 -0400

Fengkai: 

I think it is key that you say “intent is specific to network users with
different roles.”  It is the definition of different roles that
Tianran/Terence grouped his intent chains on (intent top-function lower
layers).  Which is the best description of role? 

user + role à intent à context      Or 

 user à intent à context + role 

Sue 

From: Ibnemo [mailto:[email-masked]] On Behalf Of Lifengkai
(Fengkai)
Sent: Wednesday, June 03, 2015 5:39 AM
To: Dave Hood; Susan Hares; [email-masked]
Cc: [email-masked]
Subject: Re: [Ibnemo] [Sdn] Defining a Common Model for intent

Hi Dave,

I think I got the point that you concern. Continuing the consideration in my
last email, the intent is specific to the network users with different
roles. 

With the network user roles in mind, I think we can properly define what is
the intent or what is not intent for the specified users. But we cannot
generally defining what is or is not intent, unless the user role, from the
user perspective is taken into account.

Best Regards,

Fengkai

I agree that the context matters, Fengkai (and Susan in earlier response).
What the I-D appears to be saying is that any interaction across an NBI is
intent: otherwise the app/tenant/customer wouldn’t do it. That’s the root of
my question from the beginning: how would we know what is *not* intent?

If I ask for some particular microscopically detailed configuration (a
“how”), it’s because I care, for some reason, about that level of detail. It
is in fact part of my intent. 

So as best I can tell, we can say precisely what an intent is, and we can’t
say what an intent is not. If intent is just the latest buzzword, which it
certainly appears to be, can we just say so and leave it to the marketing
people?

Dave

Hi Dave and all,

 

Best Regards,

Fengkai

Dave

Sue Hares

---

From: "Lifengkai (Fengkai)" <[email-masked]>
Date: Thu, 4 Jun 2015 04:41:45 +0000

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:[email-masked]]
Sent: Wednesday, June 03, 2015 7:09 AM
To: Lifengkai (Fengkai); 'Dave Hood'; [email-masked]
Cc: [email-masked]
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:[email-masked]] On Behalf Of Lifengkai (Fengkai)
Sent: Tuesday, June 02, 2015 3:47 AM
To: Dave Hood; Susan Hares; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Ibnemo] [Sdn] Defining a Common Model for intent

Hi Dave and all,

Best Regards,
Fengkai

Dave

Sue Hares

---

From: Zhoutianran <[email-masked]>
Date: Thu, 4 Jun 2015 12:26:32 +0000

Hi Bert,

Thanks for you comments. 
I agree with you that we'd better just focus on the top layer.
But I am sorry, what do you mean in the last sentence?
"A role -based intent model? I guess it would just boil down in different types of intent that fit with the specific role, right?"
Could you give more information on this?

Best,
Terence

________________________________________
发件人: Bert Wijnen (IETF) [[email-masked]]
发送时间: 2015年6月3日 21:08
收件人: Zhoutianran; STUART VENTERS; [email-masked]
抄送: [email-masked]
主题: Re: [Ibnemo] [Sdn] Defining a Common Model for intent

Hi all,

Bert

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 4 Jun 2015 11:13:09 -0400

Bert and Tianran: 

If you link intent to role, I believe your diagram is: 

User --> intent --> role --> context 

I think role takes on an aspect of context.   What do you think? 

Sue 

-----Original Message-----
From: sdn [mailto:[email-masked]] On Behalf Of Zhoutianran
Sent: Thursday, June 04, 2015 8:27 AM
To: Bert Wijnen (IETF); STUART VENTERS; [email-masked]
Cc: [email-masked]
Subject: Re: [Sdn] [Ibnemo] Defining a Common Model for intent

Hi Bert,

Thanks for you comments. 
I agree with you that we'd better just focus on the top layer.
But I am sorry, what do you mean in the last sentence?
"A role -based intent model? I guess it would just boil down in different
types of intent that fit with the specific role, right?"
Could you give more information on this?

Best,
Terence

Hi all,

I like the idea of (at least for now) stick to the problem of "intent" for
one layer (the top layer).
Let us not boil the ocean and try to do everything that comes up. If we are
successful in doing a model for IBNEMO for the top layer, we can then see if
we want to go at more layers.

A role -based intent model? I guess it would just boil down in different
types of intent that fit with the specific role, right?

Bert

On 03/06/15 11:44, Zhoutianran wrote:
> I think all the concern and uncertainty is because of the layered
thinking. We think intent is a relatively higher level nested.
> What if we think about intent with differnet roles? Just like a relative
detailed description in my "role based intent" email.
> I think the essential of the role based intent is that there is only one
intent layer which is always on the top. Intent is dedicated for
corresponding roles. One role will not call other roles interfaces.
model.
recognize.
> CIO says: give me bandwidths between sites A, B, and C Net engineer 
> says: I need these evc's to these endpoints Purchasing agent: Says use 
> this product from this vendor Sales Person says: Here is the price and 
> priority
refinement.
level.
>
> So as best I can tell, we can say precisely what an intent is, and we
can't say what an intent is not. If intent is just the latest buzzword,
which it certainly appears to be, can we just say so and leave it to the
marketing people?
>
> 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.
>
> 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.]
>
>
> 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.
>
> 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.
for Intent and Nemo:
constraints.

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Thu, 04 Jun 2015 17:32:12 +0200

> User --> intent --> role --> context

Could be, but is "user" not a role.
I see roles as:
- user/end-user or customer
- service provider
- network achitect
- network operator
- maybe also trouble-shooter

Is that not the idea/

Bert
p.s. why is this copied to 2 mailing lists, sdn and ibnemo?
I thought that the intent-modelling work is in ibnemo, if so, then SDN RG people
who are interested should come overthere.
Now if we were talking SDN specific intent modelling, then maybe it is OK,
But I thought we are discussing generic intent modelling, no?

Bert

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Thu, 04 Jun 2015 17:34:37 +0200

> Could you give more information on this?

Sorry for not being clear,

my thinking here is that
- intent model is basically the same for anyone.
- but based on your role, you express your intent with different (role specific)
    statements. That possibly means you use similar language (IDL) but you use
    different objects (data) to express it

So a customer/end-user says
   I want a link between location A and B, i.e. my intent is to use a connection between A & B
   and I want 1GB with low delay
The service provider who needs to implement this says things like
   Create  a physical link between A&B
   or create a logical link between A&B with guaranteed 1GB capacity

So the customer/end-user does not care about physical or logical or whatever.
Maybe he/she does not even want to know.

But the service provider of course needs to express intent about physical or logical

Does that help?

Bert

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 4 Jun 2015 12:54:23 -0400

Bert: 

[taking [email-masked] off per your comment]. 

Are you looking for intent operatives which are "pure intent" (same for all
contexts) to be applied in a context specific language that fits a
context-specific role.   If so, I see that roles as a part of context.   ONS
NBI/Keystone is arguing for a pure intent.  The problem is when I separate
pure intent from impure intent - I find we are left with few primitives.  If
you are arguing for pure intent, can you give me one of your examples for
pure intent? 

Sue 

-----Original Message-----
From: Ibnemo [mailto:[email-masked]] On Behalf Of Bert Wijnen
(IETF)
Sent: Thursday, June 04, 2015 11:35 AM
To: Zhoutianran; STUART VENTERS; [email-masked]
Cc: [email-masked]
Subject: Re: [Ibnemo] [Sdn] Defining a Common Model for intent

my thinking here is that
- intent model is basically the same for anyone.
- but based on your role, you express your intent with different (role
specific)
    statements. That possibly means you use similar language (IDL) but you
use
    different objects (data) to express it

   I want a link between location A and B, i.e. my intent is to use a
connection between A & B

So the customer/end-user does not care about physical or logical or
whatever.
Maybe he/she does not even want to know.

But the service provider of course needs to express intent about physical or
logical

Does that help?

Bert

> Let us not boil the ocean and try to do everything that comes up. If 
> we are successful in doing a model for IBNEMO for the top layer, we can
then see if we want to go at more layers.
>
> A role -based intent model? I guess it would just boil down in 
> different types of intent that fit with the specific role, right?
>
> Bert
>
>
recognize.
>> says: I need these evc's to these endpoints Purchasing agent: Says 
>> use this product from this vendor Sales Person says: Here is the 
>> price and priority
refinement.
level.
>> I agree that the context matters, Fengkai (and Susan in earlier
response). What the I-D appears to be saying is that any interaction across
an NBI is intent: otherwise the app/tenant/customer wouldn't do it. That's
the root of my question from the beginning: how would we know what is *not*
intent?
>>
>> In my IT example, I argue that intent need not be independent of
protocols and ports, and that it need not be portable. Your response about
context appears to agree.
>>
>> 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.
>> order an E-line without caring about such details? [Nor is this 
>> intent portable.]
>>
>> On this mail list, there has been a discussion of two types of
information for Intent and Nemo:
constraints.

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 4 Jun 2015 14:34:30 -0400

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:[email-masked]] On Behalf Of Lifengkai
(Fengkai)
Sent: Thursday, June 04, 2015 12:42 AM
To: Susan Hares; 'Dave Hood'; [email-masked]
Cc: [email-masked]
Subject: Re: [Ibnemo] [Sdn] Defining a Common Model for intent

Hi Sue and all,

“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.

1.     sub-department in each branch can communicate with sub-department in
headquarter

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.

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

Fengkai:

User à intent à context 

is very important as

Sue 

Hi Dave and all,

 

Best Regards,

Fengkai

Dave

Sue Hares

---

From: "Lifengkai (Fengkai)" <[email-masked]>
Date: Fri, 5 Jun 2015 00:48:18 +0000

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:[email-masked]]
Sent: Friday, June 05, 2015 2:35 AM
To: Lifengkai (Fengkai); 'Dave Hood'; [email-masked]
Cc: [email-masked]
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

To: Susan Hares; 'Dave Hood'; [email-masked]<mailto:[email-masked]>

Hi Sue and all,

>  User, enterprise user with department manager role
>  Intent, sub-department connection between headquarter and braches
>  Context, better of quality of experience within the budget

>  User, enterprise user with network manager role
>  Intent, topology set up for communication connection between subnets
>  Context, SLA parameters for quality of experience guaranteeing

Thanks.

Best Regards,
Fengkai

To: Lifengkai (Fengkai); 'Dave Hood'; [email-masked]<mailto:[email-masked]>

Fengkai:

Sue

Hi Dave and all,

Best Regards,
Fengkai

Dave

Sue Hares

---

From: PEDRO ANDRES ARANDA GUTIERREZ <[email-masked]>
Date: Fri, 5 Jun 2015 06:02:51 +0000

Hi Sue,

Going back to the BGP-4 example and staying at the role level, does this
chain really stand? I mean, there are things a user will never be able to
do depending on (her|his) role. So, will s?he ever be able to express an
intent for something s?he cannot control?

Just a bit of philosophy I fear :-)

/PA

---
Dr. Pedro A. Aranda Gutiérrez

Technology Exploration -
Network Innovation & Virtualisation
email: pedroa d0t aranda At telefonica d0t com
Telefónica, Investigación y Desarrollo
C/ D. Ramón de la Cruz,84
28006 Madrid, Spain

Fragen sind nicht da, um beantwortet zu werden.
Fragen sind da, um gestellt zu werden.
Georg Kreisler

El 04/06/15 17:13, "Susan Hares" <[email-masked]> escribió:

>>response).
>>protocols
>>buy
>are

________________________________

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

---

From: Zhoutianran <[email-masked]>
Date: Fri, 5 Jun 2015 06:41:52 +0000

Thanks Bert for your clarification.

That's another good description on the role based intent I think.

Terence

-----Original Message-----
From: Bert Wijnen (IETF) [mailto:[email-masked]] 
Sent: Thursday, June 04, 2015 11:35 PM
To: Zhoutianran; STUART VENTERS; [email-masked]
Cc: [email-masked]
Subject: Re: [Ibnemo] [Sdn] Defining a Common Model for intent

my thinking here is that

Does that help?

Bert

> we are successful in doing a model for IBNEMO for the top layer, we can then see if we want to go at more layers.
>

---

From: Xiayinben <[email-masked]>
Date: Fri, 5 Jun 2015 13:10:47 +0000

In my understanding:
User expresses/owns a set of specific intent instances;
Role decides intent scope and content which is cared by the role;
User can have one or more roles.
Do you think this make sense?

Yinben

-----邮件原件-----
发件人: Ibnemo [mailto:[email-masked]] 代表 Bert Wijnen (IETF)
发送时间: 2015年6月4日 23:32
收件人: Susan Hares; Zhoutianran; 'STUART VENTERS'; [email-masked]
抄送: [email-masked]
主题: Re: [Ibnemo] [Sdn] Defining a Common Model for intent

Is that not the idea/

Bert
p.s. why is this copied to 2 mailing lists, sdn and ibnemo?
I thought that the intent-modelling work is in ibnemo, if so, then SDN RG people who are interested should come overthere.
Now if we were talking SDN specific intent modelling, then maybe it is OK, But I thought we are discussing generic intent modelling, no?

Bert
> "A role -based intent model? I guess it would just boil down in 
> different types of intent that fit with the specific role, right?"
> we are successful in doing a model for IBNEMO for the top layer, we 
> can then see if we want to go at more layers.
>
> intent: otherwise the app/tenant/customer wouldn't do it. That's the 
> root of my question from the beginning: how would we know what is *not* intent?
> "how"), it's because I care, for some reason, about that level of 
> detail. It is in fact part of my intent.
> and ports, and that it need not be portable. Your response about 
> can't say what an intent is not. If intent is just the latest 
> buzzword, which it certainly appears to be, can we just say so and 
> leave it to the marketing people?
>> Dave
>>
> 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.
>> An excerpt from an email I sent on the ONF NBI list, which may 
>> contain
> some useful thoughts:
> 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?
> 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.
> 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.
> 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.
> elements of information are germane to the service it offers, and if 
> ports and protocols are germane to the service, so be it.
> 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?
> 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.
> option or the other, but the level of granularity is quite different. 
> Shall we agree that driving is too granular to be considered intent?
> 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
>>
> 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.
> 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:

---

From: Xiayinben <[email-masked]>
Date: Fri, 5 Jun 2015 13:17:18 +0000

Bert,

That is exactly same as what I understand.
I hope we could give a common intent information model for general intent components and their relationship.
Then we could define a set of intent content based on some roles as you mentioned in last mail.

Yinben

-----邮件原件-----
发件人: Ibnemo [mailto:[email-masked]] 代表 Bert Wijnen (IETF)
发送时间: 2015年6月4日 23:35
收件人: Zhoutianran; STUART VENTERS; [email-masked]
抄送: [email-masked]
主题: Re: [Ibnemo] [Sdn] Defining a Common Model for intent

my thinking here is that

Does that help?

Bert

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 5 Jun 2015 13:41:40 -0400

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:[email-masked]] 
Sent: Thursday, June 04, 2015 8:48 PM
To: Susan Hares; 'Dave Hood'; [email-masked]
Cc: [email-masked]
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.

 

Thanks.

Best Regards,

Fengkai

Fengkai and all: 

Sue 

Hi Sue and all,

Thanks.

Best Regards,

Fengkai

Fengkai:

User à intent à context 

is very important as

Sue 

Hi Dave and all,

 

Best Regards,

Fengkai

Dave

Sue Hares

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 5 Jun 2015 15:08:01 -0400

Pedro: 

I think you are right and I am wrong in this chain.  After your posts I think that role is really a constraint of intent.    

Intent ==: object (constraint), result (constraint), constraint (constraint). 

 Where the role's constraint actually impacts what possible objects, results or constraints an intent has. 

Sue 

-----Original Message-----
From: PEDRO ANDRES ARANDA GUTIERREZ [mailto:[email-masked]] 
Sent: Friday, June 05, 2015 2:03 AM
To: Susan Hares; 'Zhoutianran'; 'Bert Wijnen (IETF)'; 'STUART VENTERS'; [email-masked]
Cc: [email-masked]
Subject: Re: [Ibnemo] [Sdn] Defining a Common Model for intent

Hi Sue,

Going back to the BGP-4 example and staying at the role level, does this chain really stand? I mean, there are things a user will never be able to do depending on (her|his) role. So, will s?he ever be able to express an intent for something s?he cannot control?

/PA

---

Technology Exploration -
Network Innovation & Virtualisation
email: pedroa d0t aranda At telefonica d0t com Telefónica, Investigación y Desarrollo C/ D. Ramón de la Cruz,84
28006 Madrid, Spain

El 04/06/15 17:13, "Susan Hares" <[email-masked]> escribió:

>Let us not boil the ocean and try to do everything that comes up. If we 
>are successful in doing a model for IBNEMO for the top layer, we can 
>which it certainly appears to be, can we just say so and leave it to 
>the marketing people?
>>
>> Dave
>>
>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.
>>
>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 
>software local to my PC, but I don't think we can call the PC an SDN controller.
>It's
>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.
>>
>SDN offered my PC a packet interface with the properties of knowing how 
>to recognize and route DNS queries specially, and general IP 
>manipulation of a granular information model, the explicit visibility 
>of multiple objects, how they are interrelated, their attributes, and 
>the like.
>>
>Shall
>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.
>>
>created a definition for intent and a unified model for defining intent 
>which can handle 1 or multiple layers. The model suggest that:

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 5 Jun 2015 15:50:45 -0400

Bert and Tianran:

I believe that you are stating regarding the definition: 

Intent == (defines)  object, result, constraint 

An IDL (intent description Langague) would be a common way to express the
object, result, and constraints.  If you use roles, I suggest that roles
provide a grouping of objects, results, and constraints.   Do you agree? 

Sue 
-----Original Message-----
From: Ibnemo [mailto:[email-masked]] On Behalf Of Zhoutianran
Sent: Friday, June 05, 2015 2:42 AM
To: Bert Wijnen (IETF); STUART VENTERS; [email-masked]
Cc: [email-masked]
Subject: Re: [Ibnemo] [Sdn] Defining a Common Model for intent

Terence

-----Original Message-----
From: Bert Wijnen (IETF) [mailto:[email-masked]]
Sent: Thursday, June 04, 2015 11:35 PM
To: Zhoutianran; STUART VENTERS; [email-masked]
Cc: [email-masked]
Subject: Re: [Ibnemo] [Sdn] Defining a Common Model for intent

my thinking here is that

Does that help?

Bert

recognize.
refinement.
level.
constraints.

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 5 Jun 2015 15:54:06 -0400

Yinben: 

Hopefully, my previous post will indicate +1 on your opinion.  Role decides
the scope/constraints and content.  It will make intent easier to implement.
A DataBase application will have a scope/constraint for its intent, and a
common language (Intent Data Language) to express it. 

Sue 

-----Original Message-----
From: Ibnemo [mailto:[email-masked]] On Behalf Of Xiayinben
Sent: Friday, June 05, 2015 9:11 AM
To: Bert Wijnen (IETF); Susan Hares; Zhoutianran; 'STUART VENTERS';
[email-masked]
Cc: [email-masked]
Subject: [Ibnemo] 答复: [Sdn] Defining a Common Model for intent

In my understanding:
User expresses/owns a set of specific intent instances; Role decides intent
scope and content which is cared by the role; User can have one or more
roles.
Do you think this make sense?

Yinben

-----邮件原件-----
发件人: Ibnemo [mailto:[email-masked]] 代表 Bert Wijnen (IETF)
发送时间: 2015年6月4日 23:32
收件人: Susan Hares; Zhoutianran; 'STUART VENTERS'; [email-masked]
抄送: [email-masked]
主题: Re: [Ibnemo] [Sdn] Defining a Common Model for intent

Is that not the idea/

Bert
p.s. why is this copied to 2 mailing lists, sdn and ibnemo?
I thought that the intent-modelling work is in ibnemo, if so, then SDN RG
people who are interested should come overthere.
Now if we were talking SDN specific intent modelling, then maybe it is OK,
But I thought we are discussing generic intent modelling, no?

Bert
response).
are

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Sat, 6 Jun 2015 17:41:02 +0000

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 <[email-masked]<mailto:[email-masked]>> 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

Sue and all,

Thanks.

Best Regards,
Fengkai

Fengkai and all:

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

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.

>  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

Thanks.

Best Regards,
Fengkai

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

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

Hi Dave and all,

Best Regards,
Fengkai

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.

•         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

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
[email-masked]<mailto:[email-masked]>
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: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

---

From: Zhoutianran <[email-masked]>
Date: Mon, 8 Jun 2015 09:46:15 +0000

Hi Bert,

You raised a very interesting topic on the user and role.
I think the role groups a set of intent. And the user is the exact one to use the intent. One user could take several roles.
A quick example in real world, one person(just like me) could be a father(one role) and a programmer(another role).

Best,
Terence

-----Original Message-----
From: Bert Wijnen (IETF) [mailto:[email-masked]] 
Sent: Thursday, June 04, 2015 11:32 PM
To: Susan Hares; Zhoutianran; 'STUART VENTERS'; [email-masked]
Cc: [email-masked]
Subject: Re: [Sdn] [Ibnemo] Defining a Common Model for intent

Is that not the idea/

Bert

Bert

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 8 Jun 2015 08:27:41 -0400

Diego: 

You are clear in your description of the two cases:  Security roles and
modeling role for abstraction of topology.  I agree both are needed, and it
is important to be concerned about both. 

Sue 

From: DIEGO LOPEZ GARCIA [mailto:[email-masked]] 
Sent: Saturday, June 06, 2015 1:41 PM
To: Susan Hares
Cc: Lifengkai (Fengkai); Dave Hood; [email-masked]; [email-masked]
Subject: 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 <[email-masked]> wrote:

Fengkai:

 

Sue

From: Lifengkai (Fengkai) [ <mailto:[email-masked]>
mailto:[email-masked]] 
Sent: Thursday, June 04, 2015 8:48 PM
To: Susan Hares; 'Dave Hood';  <mailto:[email-masked]> [email-masked]
Cc:  <mailto:[email-masked]> [email-masked]
Subject: RE: [Ibnemo] [Sdn] Defining a Common Model for intent

Sue and all,

Thanks.

Best Regards,

Fengkai

From: Susan Hares [ <mailto:[email-masked]> mailto:[email-masked]] 
Sent: Friday, June 05, 2015 2:35 AM
To: Lifengkai (Fengkai); 'Dave Hood';  <mailto:[email-masked]> [email-masked]
Cc:  <mailto:[email-masked]> [email-masked]
Subject: RE: [Ibnemo] [Sdn] Defining a Common Model for intent

Fengkai and all:

Sue

From: Ibnemo [ <mailto:[email-masked]>
mailto:[email-masked]] On Behalf Of Lifengkai (Fengkai)
Sent: Thursday, June 04, 2015 12:42 AM
To: Susan Hares; 'Dave Hood';  <mailto:[email-masked]> [email-masked]
Cc:  <mailto:[email-masked]> [email-masked]
Subject: Re: [Ibnemo] [Sdn] Defining a Common Model for intent

Hi Sue and all,

Thanks.

Best Regards,

Fengkai

From: Susan Hares [ <mailto:[email-masked]> mailto:[email-masked]] 
Sent: Wednesday, June 03, 2015 7:09 AM
To: Lifengkai (Fengkai); 'Dave Hood';  <mailto:[email-masked]> [email-masked]
Cc:  <mailto:[email-masked]> [email-masked]
Subject: RE: [Ibnemo] [Sdn] Defining a Common Model for intent

Fengkai:

User à intent à context

is very important as

Sue

From: Ibnemo [ <mailto:[email-masked]>
mailto:[email-masked]] On Behalf Of Lifengkai (Fengkai)
Sent: Tuesday, June 02, 2015 3:47 AM
To: Dave Hood; Susan Hares;  <mailto:[email-masked]> [email-masked]
Cc:  <mailto:[email-masked]> [email-masked]
Subject: Re: [Ibnemo] [Sdn] Defining a Common Model for intent

Hi Dave and all,

 

Best Regards,

Fengkai

From: sdn [ <mailto:[email-masked]> mailto:[email-masked]] On
Behalf Of Dave Hood
Sent: Tuesday, June 02, 2015 1:38 AM
To: Susan Hares;  <mailto:[email-masked]> [email-masked]
Cc: Zhoutianran; Xiayinben;  <mailto:[email-masked]> [email-masked]
Subject: Re: [Sdn] Defining a Common Model for intent

Dave

From: sdn [ <mailto:[email-masked]> mailto:[email-masked]] On
Behalf Of Susan Hares
Sent: Saturday, May 30, 2015 1:02 PM
To:  <mailto:[email-masked]> [email-masked]
Cc: 'Zhoutianran'; 'Xiayinben';  <mailto:[email-masked]> [email-masked]
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>
http://www.ietf.org/mail-archive/web/sdn/current/msg00646.html) :

Sue Hares

_______________________________________________
Ibnemo mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/ibnemo>
https://www.ietf.org/mailman/listinfo/ibnemo

Dr Diego R. Lopez
Telefonica I+D

 

  _____  

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

---

From: STUART VENTERS <[email-masked]>
Date: Mon, 8 Jun 2015 14:21:57 +0000

All,

Over the weekend I figured out what is bugging me about the word intent.

Thinking about the interface (role?) between the customer and service provider.
To provision a service, the provider needs to know the following:
   WHO the customer is. (the billing and technical contact info, perhaps a PO number, and if the customer is a residence or business)
   WHAT sort of service.  (the speeds and feeds, what packet headers the network is aware of, addressing, special things like nat or firewall,  etc)
   WHERE the service should appear. (physical location of the endpoints, maybe logical circuit ID's)
   WHEN the service should work. (Install date, maybe the 100Gig for backups only works at night?)

Conspicuously missing is the following  question:
   WHY the customer wants the service. (Perhaps the provider could provide a better service if he knew this?)

To me, the word 'intent' focuses one to think about WHY.
Saying that the service is provisioned based on intent, implys that the service provider can figure out what to do from mostly the WHY question.
This seems misleading.

That said, to figure out how to specify a service, there are all sorts of interesting questions in the who, what, where, when area.
I wonder if this is where this intent stuff should head?

-Stuart

---

From: "Natale, Bob" <[email-masked]>
Date: Mon, 8 Jun 2015 16:30:17 +0000

Apologies to those on the lists who have already seen the attached (Dave Lenrow's introductory presentation to the 2015 Intent Based Network Summit), but I thought that it might be useful for those who haven't.

Avanti,
BobN

-----Original Message-----
From: Ibnemo [mailto:[email-masked]] On Behalf Of STUART VENTERS
Sent: Monday, June 08, 2015 10:22 AM
To: [email-masked]
Cc: [email-masked]; Susan Hares
Subject: Re: [Ibnemo] [Sdn] Defining a Common Model for intent

All,

-Stuart

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 8 Jun 2015 19:25:26 -0400

Tianran/Terence and Bert; 

The use of role-based to allow one entity (human or silicon) to take on
multiple roles is RBAC.   These roles are only some of the roles - but they
are abstract roles.  Another role is a Service provider who is provider's
provider as I've used in my example.   Another might be a EVPN provider
(services). 

- network architect

Sue 
-----Original Message-----
From: Ibnemo [mailto:[email-masked]] On Behalf Of Zhoutianran
Sent: Monday, June 08, 2015 5:46 AM
To: Bert Wijnen (IETF); Susan Hares; 'STUART VENTERS'; [email-masked]
Cc: [email-masked]
Subject: Re: [Ibnemo] [Sdn] Defining a Common Model for intent

Hi Bert,

You raised a very interesting topic on the user and role.
I think the role groups a set of intent. And the user is the exact one to
use the intent. One user could take several roles.
A quick example in real world, one person(just like me) could be a
father(one role) and a programmer(another role).

Best,
Terence

-----Original Message-----
From: Bert Wijnen (IETF) [mailto:[email-masked]]
Sent: Thursday, June 04, 2015 11:32 PM
To: Susan Hares; Zhoutianran; 'STUART VENTERS'; [email-masked]
Cc: [email-masked]
Subject: Re: [Sdn] [Ibnemo] Defining a Common Model for intent

Is that not the idea/

Bert

Bert
response).
are

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 8 Jun 2015 19:31:44 -0400

Stuart: 

High What and high level Why are  intent issues.  The rest (who, what,
where, when) is the context.  The question is how do we tease a part the
"pure" intent versus the context and constraint.  Can you look at this
example: 

Intent: [What] Connect my remote offices to my corporate headquarters [why]
to get Big Data input from remote offices, and results back to offices. 

Why seems to be the constraint in this description.   Is this what you were
thinking about? 

Sue 

-----Original Message-----
From: sdn [mailto:[email-masked]] On Behalf Of STUART VENTERS
Sent: Monday, June 08, 2015 10:22 AM
To: [email-masked]
Cc: 'Zhoutianran'; [email-masked]; Susan Hares; Bert Wijnen (IETF)
Subject: Re: [Sdn] [Ibnemo] Defining a Common Model for intent

All,

Thinking about the interface (role?) between the customer and service
provider.
To provision a service, the provider needs to know the following:
   WHO the customer is. (the billing and technical contact info, perhaps a
PO number, and if the customer is a residence or business)
   WHAT sort of service.  (the speeds and feeds, what packet headers the
network is aware of, addressing, special things like nat or firewall,  etc)
   WHERE the service should appear. (physical location of the endpoints,
maybe logical circuit ID's)
   WHEN the service should work. (Install date, maybe the 100Gig for backups
only works at night?)

Conspicuously missing is the following  question:
   WHY the customer wants the service. (Perhaps the provider could provide a
better service if he knew this?)

To me, the word 'intent' focuses one to think about WHY.
Saying that the service is provisioned based on intent, implys that the
service provider can figure out what to do from mostly the WHY question.
This seems misleading.

That said, to figure out how to specify a service, there are all sorts of
interesting questions in the who, what, where, when area.
I wonder if this is where this intent stuff should head?

-Stuart

---

From: "zhangyali (D)" <[email-masked]>
Date: Tue, 9 Jun 2015 03:03:55 +0000

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:[email-masked]]
发送时间: 2015年6月7日 1:41
收件人: Susan Hares
抄送: [email-masked]; Dave Hood; [email-masked]
主题: Re: [Ibnemo] [Sdn] Defining a Common Model for intent

Hi Sue,

Be goode,

Fengkai:

Sue

Sue and all,

Thanks.

Best Regards,
Fengkai

Fengkai and all:

Sue

Hi Sue and all,

Thanks.

Best Regards,
Fengkai

Fengkai:

Sue

Hi Dave and all,

Best Regards,
Fengkai

Dave

Sue Hares

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]<mailto:[email-masked]>
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Tue, 9 Jun 2015 21:33:26 +0000

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) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Diego,

Best,
Yali
发件人: DIEGO LOPEZ GARCIA [mailto:[email-masked]]
发送时间: 2015年6月7日 1:41
收件人: Susan Hares
抄送: [email-masked]<mailto:[email-masked]>; Dave Hood; [email-masked]<mailto:[email-masked]>
主题: Re: [Ibnemo] [Sdn] Defining a Common Model for intent

Hi Sue,

Be goode,

Fengkai:

Sue

Sue and all,

Thanks.

Best Regards,
Fengkai

Fengkai and all:

Sue

Hi Sue and all,

Thanks.

Best Regards,
Fengkai

Fengkai:

Sue

Hi Dave and all,

Best Regards,
Fengkai

Dave

Sue Hares

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

---

From: "zhangyali (D)" <[email-masked]>
Date: Wed, 10 Jun 2015 03:17:49 +0000

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:[email-masked]]
发送时间: 2015年6月10日 5:33
收件人: zhangyali (D)
抄送: Susan Hares; [email-masked]; Dave Hood; [email-masked]
主题: Re: [Ibnemo] [Sdn] Defining a Common Model for intent

Hi Yali,

Be goode,

Hi Diego,

Best,
Yali

Hi Sue,

Be goode,

Fengkai:

Sue

Sue and all,

Thanks.

Best Regards,
Fengkai

Fengkai and all:

Sue

Hi Sue and all,

Thanks.

Best Regards,
Fengkai

Fengkai:

Sue

Hi Dave and all,

Best Regards,
Fengkai

Dave

Sue Hares

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

---

From: PEDRO ANDRES ARANDA GUTIERREZ <[email-masked]>
Date: Wed, 10 Jun 2015 05:53:34 +0000

Hi,

So now, we have three ‘dimensions’ we can analyse separately, one is the infrastructure intent (from boxes to functional units to composed functional units), the other is roles and the third is the security dimension. Shouldn’t we start looking at the invariants for each of them?

Best, /PA

De: "zhangyali (D)" <[email-masked]<mailto:[email-masked]>>
Fecha: miércoles, 10 de junio de 2015 05:17
Para: DIEGO LOPEZ GARCIA <[email-masked]<mailto:[email-masked]>>
CC: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Dave Hood <[email-masked]<mailto:[email-masked]>>, Sue Hares <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Asunto: [Ibnemo] 答复: [Sdn] Defining a Common Model for intent

Hi Diego,

Best,
Yali

发件人: DIEGO LOPEZ GARCIA [mailto:[email-masked]]
发送时间: 2015年6月10日 5:33
收件人: zhangyali (D)
抄送: Susan Hares; [email-masked]<mailto:[email-masked]>; Dave Hood; [email-masked]<mailto:[email-masked]>
主题: Re: [Ibnemo] [Sdn] Defining a Common Model for intent

Hi Yali,

Be goode,

Hi Diego,

Best,
Yali

Hi Sue,

Be goode,

Fengkai:

Sue

Sue and all,

Thanks.

Best Regards,
Fengkai

Fengkai and all:

Sue

Hi Sue and all,

Thanks.

Best Regards,
Fengkai

Fengkai:

Sue

Hi Dave and all,

Best Regards,
Fengkai

·         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?

Dave

Sue Hares

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

---

Technology Exploration -

---

From: Zhoutianran <[email-masked]>
Date: Wed, 10 Jun 2015 09:57:54 +0000

Hi Pedro,

I think it’s time for us to go deeper. But what do you mean by “the invariants for each of them”?
My suggestion is to work on a concrete role example for intent. We can see how this intent maps/related to the infrastructure.
The security dimension identifies when(condition/scenario) a role can invoke which operations.

Best,
Terence

From: Ibnemo [mailto:[email-masked]] On Behalf Of PEDRO ANDRES ARANDA GUTIERREZ
Sent: Wednesday, June 10, 2015 1:54 PM
To: zhangyali (D); DIEGO LOPEZ GARCIA
Cc: [email-masked]; Dave Hood; Susan Hares; [email-masked]
Subject: Re: [Ibnemo] 答复: [Sdn] Defining a Common Model for intent

Hi,

Best, /PA

Hi Diego,

Best,
Yali

Hi Yali,

Be goode,

Hi Diego,

Best,
Yali

Hi Sue,

Be goode,

Fengkai:

Sue

Sue and all,

Thanks.

Best Regards,
Fengkai

Fengkai and all:

Sue

Hi Sue and all,

Thanks.

Best Regards,
Fengkai

Fengkai:

Sue

Hi Dave and all,

Best Regards,
Fengkai

Dave

Sue Hares

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

---

Technology Exploration -

---

From: PEDRO ANDRES ARANDA GUTIERREZ <[email-masked]>
Date: Wed, 10 Jun 2015 10:52:14 +0000

Hi Tianran,

Just to make a first try the “infrastructure intent”:

Invariant: we have a few atomic Node types and composes Node types built from atomic Nodes and/or other complex Nodes.

Example: <Autonomous system>
(upper layer) AS is composed of network realms (areas or levels) interconnected by Links
(next layer down) network realm is composed of routers interconnected by Links

The connection with role based intent here comes in the following example: management deciding how to peer with other Ases (I’m provider, client or peer), AS admin deciding to load balance among links to a given provider.

Other example: <use case in the ODL project>
(upper layer) virtual data center is composed of composed node types like exterior zone, interior zone, DMZ
(next layer below) DMZ has a firewall at its interface to the exterior zone, a layer 2 switch to connect devices installed in it and a connection to a protected area, exterior zone has a router to connect to external networks, a layer 2 switch to connect devices in it and a connection to a DMZ or an interior zone, interior zone has the same structure than the DMZ
(lowest layer) A router isolates layer 2 domains and optionally advertises IP prefixes, a (stealth) firewall lets ARP packets pass through it and applies filtering rules to  IP packets

OK and here we see that the firewall is the obvious ‘connecting' point between the infrastructure intent and the security intent: the infrastructure says we have a box, well actually a Node, of type firewall and the security says: ‘stealth’ means 'pass ARP packets transparently and filter IP packets following specific rules’. Other less obvious points exist like possible access-lists in routers to mention an example.

Is this a good starting point?

Best, /PA

De: Zhoutianran <[email-masked]<mailto:[email-masked]>>
Fecha: miércoles, 10 de junio de 2015 11:57
Para: PEDRO ANDRES ARANDA GUTIERREZ <[email-masked]<mailto:[email-masked]>>, "zhangyali (D)" <[email-masked]<mailto:[email-masked]>>, DIEGO LOPEZ GARCIA <[email-masked]<mailto:[email-masked]>>
CC: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Dave Hood <[email-masked]<mailto:[email-masked]>>, Sue Hares <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Asunto: RE: [Ibnemo] 答复: [Sdn] Defining a Common Model for intent

Hi Pedro,

Best,
Terence

Cc: [email-masked]<mailto:[email-masked]>; Dave Hood; Susan Hares; [email-masked]<mailto:[email-masked]>

Hi,

Best, /PA

Hi Diego,

Best,
Yali

Hi Yali,

Be goode,

Hi Diego,

Best,
Yali

Hi Sue,

Be goode,

Fengkai:

Sue

Sue and all,

Thanks.

Best Regards,
Fengkai

Fengkai and all:

Sue

Hi Sue and all,

Thanks.

Best Regards,
Fengkai

Fengkai:

Sue

Hi Dave and all,

Best Regards,
Fengkai

Dave

Sue Hares

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

---

Technology Exploration -

---

Technology Exploration -

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Wed, 10 Jun 2015 16:48:51 +0000

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) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Diego,

Best,
Yali

Hi Yali,

Be goode,

Hi Diego,

Best,
Yali

Hi Sue,

Be goode,

Fengkai:

Sue

Sue and all,

Thanks.

Best Regards,
Fengkai

Fengkai and all:

Sue

Hi Sue and all,

Thanks.

Best Regards,
Fengkai

Fengkai:

Sue

Hi Dave and all,

Best Regards,
Fengkai

Dave

Sue Hares

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

---

From: "zhangyali (D)" <[email-masked]>
Date: Thu, 11 Jun 2015 02:28:52 +0000

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

发送时间: 2015年6月11日 0:49

Hi Yali,

Be goode,

Hi Diego,

Best,
Yali

Hi Yali,

Be goode,

Hi Diego,

Best,
Yali

Hi Sue,

Be goode,

Fengkai:

Sue

Sue and all,

Thanks.

Best Regards,
Fengkai

Fengkai and all:

Sue

Hi Sue and all,

Thanks.

Best Regards,
Fengkai

Fengkai:

Sue

Hi Dave and all,

Best Regards,
Fengkai

Dave

Sue Hares

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

---

From: "zhangyali (D)" <[email-masked]>
Date: Thu, 11 Jun 2015 02:46:24 +0000

Sorry for making a mistake, let me correct it. These typical roles are provided by Bert. Fingers do not act in concert with mind…

发件人: zhangyali (D)
发送时间: 2015年6月11日 10:29
收件人: 'DIEGO LOPEZ GARCIA'
抄送: Susan Hares; [email-masked]; Dave Hood; [email-masked]
主题: 答复: [Ibnemo] [Sdn] Defining a Common Model for intent

Hi Diego,

Best,
Yali

Hi Yali,

Be goode,

Hi Diego,

Best,
Yali

Hi Yali,

Be goode,

Hi Diego,

Best,
Yali

Hi Sue,

Be goode,

Fengkai:

Sue

Sue and all,

Thanks.

Best Regards,
Fengkai

Fengkai and all:

Sue

Hi Sue and all,

Thanks.

Best Regards,
Fengkai

Fengkai:

Sue

Hi Dave and all,

Best Regards,
Fengkai

Dave

Sue Hares

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

---

From: Zhoutianran <[email-masked]>
Date: Thu, 11 Jun 2015 07:48:06 +0000

Hi Pedro,

These examples are good starting point.
But I think the security you mentioned in the example is different from what Diego mentioned in other email.
I guess the security dimension Diego metioned is something like the Role Based Access Control.
That means, IMHO, a user can have the accessable/usable intent based on his role.
In your second example, the security is the more about function in firewall or router, like ACL.

Terence
From: PEDRO ANDRES ARANDA GUTIERREZ [mailto:[email-masked]]
Sent: Wednesday, June 10, 2015 6:52 PM
To: Zhoutianran; zhangyali (D); DIEGO LOPEZ GARCIA
Cc: [email-masked]; Dave Hood; Susan Hares; [email-masked]
Subject: Re: [Ibnemo] 答复: [Sdn] Defining a Common Model for intent

Hi Tianran,

Best, /PA

Hi Pedro,

Best,
Terence

Hi,

Best, /PA

Hi Diego,

Best,
Yali

Hi Yali,

Be goode,

Hi Diego,

Best,
Yali

Hi Sue,

Be goode,

Fengkai:

Sue

Sue and all,

Thanks.

Best Regards,
Fengkai

Fengkai and all:

Sue

Hi Sue and all,

Thanks.

Best Regards,
Fengkai

Fengkai:

Sue

Hi Dave and all,

Best Regards,
Fengkai

Dave

Sue Hares

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

---

Technology Exploration -

---

Technology Exploration -

---

From: PEDRO ANDRES ARANDA GUTIERREZ <[email-masked]>
Date: Thu, 11 Jun 2015 08:35:51 +0000

Hi Tianran,

Let Diego clarify, I might be introducing noise here. So I’d like to start exploring the infrastructure vs. Role intent ‘plane’.

Best, /PA
De: Zhoutianran <[email-masked]<mailto:[email-masked]>>
Fecha: jueves, 11 de junio de 2015 09:48
Para: PEDRO ANDRES ARANDA GUTIERREZ <[email-masked]<mailto:[email-masked]>>, "zhangyali (D)" <[email-masked]<mailto:[email-masked]>>, DIEGO LOPEZ GARCIA <[email-masked]<mailto:[email-masked]>>
CC: Sue Hares <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Asunto: RE: [Ibnemo] RE: [Sdn] Defining a Common Model for intent

Hi Pedro,

Terence

---

Technology Exploration -

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Sun, 14 Jun 2015 10:41:19 +0000

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) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Diego,

Best,
Yali

Hi Yali,

Be goode,

Hi Diego,

Best,
Yali

Hi Yali,

Be goode,

Hi Diego,

Best,
Yali

Hi Sue,

Be goode,

Fengkai:

Sue

Sue and all,

Thanks.

Best Regards,
Fengkai

Fengkai and all:

Sue

Hi Sue and all,

Thanks.

Best Regards,
Fengkai

Fengkai:

Sue

Hi Dave and all,

Best Regards,
Fengkai

Dave

Sue Hares

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Sun, 14 Jun 2015 10:47:02 +0000

Hi,

May be we should start using different words for both meanings of "role", focused on the different mechanisms that would define them.

Functional roles would consist of the set of actions (functionality) available, according to the view that role has via the network abstraction available to it.

Access roles would consist of the the set of objects and actions that are available to that role when the security policies are applied, typically by means of RBAC.

Thinking about it, access role permissions should be applied on the objects and actions available to the functional roles the user has, so we are not talking about independent dimensions here, but of an ordered composition of the different kind of roles.

Be goode,

On 11 Jun 2015, at 10:35 , PEDRO ANDRES ARANDA GUTIERREZ <[email-masked]<mailto:[email-masked]>> wrote:

Hi Tianran,

Best, /PA

Hi Pedro,

Terence

---

Technology Exploration -

Dr Diego R. Lopez
Telefonica I+D

---

From: "zhangyali (D)" <[email-masked]>
Date: Tue, 16 Jun 2015 02:40:51 +0000

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
发送时间: 2015年6月14日 18:41

Hi Yali,

Be goode,

Hi Diego,

Best,
Yali

Hi Yali,

Be goode,

Hi Diego,

Best,
Yali

Hi Yali,

Be goode,

Hi Diego,

Best,
Yali

Hi Sue,

Be goode,

Fengkai:

Sue

Sue and all,

Thanks.

Best Regards,
Fengkai

Fengkai and all:

Sue

Hi Sue and all,

Thanks.

Best Regards,
Fengkai

Fengkai:

Sue

Hi Dave and all,

Best Regards,
Fengkai

Dave

Sue Hares

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 16 Jun 2015 08:12:18 +0200

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:[email-masked]]
> *发送时间:*2015年6月14日18:41
> *收件人:*zhangyali (D)
> *抄送:*Susan Hares; [email-masked]; Dave Hood; [email-masked]
> *主题:*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) <[email-masked] <mailto:[email-masked]>> 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:[email-masked]]
> *发送时间:*2015年6月11日0:49
> *收件人:*zhangyali (D)
> *抄送:*Susan Hares; [email-masked] <mailto:[email-masked]>; Dave Hood; [email-masked] <mailto:[email-masked]>
> *主题:*Re: [Ibnemo] [Sdn] Defining a Common Model for intent
>
> Hi Yali,
>
> 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) <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>
>
> Hi Diego,
>
> *发件人:*DIEGO LOPEZ GARCIA [mailto:[email-masked]]
> *发送时 间:*2015年6月10日5:33
> *收件人:*zhangyali (D)
> *抄送:*Susan Hares;[email-masked] <mailto:[email-masked]>; Dave Hood;[email-masked] <mailto:[email-masked]>
> *主题:*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) <[email-masked] <mailto:[email-masked]>> 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:[email-masked]]
> *发送时间:*2015年6月7日1:41
> *收件人:*Susan Hares
> *抄送:[email-masked] <mailto:[email-masked]>; Dave Hood;[email-masked] <mailto:[email-masked]>
> *主题:*Re: [Ibnemo] [Sdn] Defining a Common Model for intent
>
> Hi Sue,
>
> 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 <[email-masked] <mailto:[email-masked]>> 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
>
> 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 
> *From:*Lifengkai (Fengkai) [mailto:[email-masked]]
> *Sent:*Thursday, June 04, 2015 8:48 PM
> *To:*Susan Hares; 'Dave Hood';[email-masked] <mailto:[email-masked]>
> *Cc:[email-masked] <mailto:[email-masked]>
> *Subject:*RE: [Ibnemo] [Sdn] Defining a Common Model for intent
>
> Sue and all,
>
> 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).
>
> *From:*Susan Hares [mailto:[email-masked]]
> *Sent:*Friday, June 05, 2015 2:35 AM
> *To:*Lifengkai (Fengkai); 'Dave Hood';[email-masked] <mailto:[email-masked]>
> *Cc:[email-masked] <mailto:[email-masked]>
> *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:[email-masked]]*On Behalf Of*Lifengkai (Fengkai)
> *Sent:*Thursday, June 04, 2015 12:42 AM
> *To:*Susan Hares; 'Dave Hood';[email-masked] <mailto:[email-masked]>
> *Cc:[email-masked] <mailto:[email-masked]>
> *Subject:*Re: [Ibnemo] [Sdn] Defining a Common Model for intent
>
> Hi Sue and all,
>
> “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.”
>
> 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.
>
> 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
>
> ØUser, enterprise user with department manager role
>
> ØIntent, sub-department connection between headquarter and braches
>
> ØContext, better of quality of experience within the budget
>
> 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
>
> ØUser, enterprise user with network manager role
>
> ØIntent, topology set up for communication connection between subnets
>
> ØContext, SLA parameters for quality of experience guaranteeing
>
> *From:*Susan Hares [mailto:[email-masked]]
> *Sent:*Wednesday, June 03, 2015 7:09 AM
> *To:*Lifengkai (Fengkai); 'Dave Hood';[email-masked] <mailto:[email-masked]>
> *Cc:[email-masked] <mailto:[email-masked]>
> *Subject:*RE: [Ibnemo] [Sdn] Defining a Common Model for intent
>
> Fengkai:
>
> 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:[email-masked]]*On Behalf Of*Lifengkai (Fengkai)
> *Sent:*Tuesday, June 02, 2015 3:47 AM
> *To:*Dave Hood; Susan Hares;[email-masked] <mailto:[email-masked]>
> *Cc:[email-masked] <mailto:[email-masked]>
> *Subject:*Re: [Ibnemo] [Sdn] Defining a Common Model for intent
>
> Hi Dave and all,
>
> 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.
>
> *From:*sdn [mailto:[email-masked]]*On Behalf Of*Dave Hood
> *Sent:*Tuesday, June 02, 2015 1:38 AM
> *To:*Susan Hares;[email-masked] <mailto:[email-masked]>
> *Cc:*Zhoutianran; Xiayinben;[email-masked] <mailto:[email-masked]>
> *Subject:*Re: [Sdn] Defining a Common Model for intent
>
> 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.
>
> 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.
>
> 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 
> ·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:[email-masked]]*On Behalf Of*Susan Hares
> *Sent:*Saturday, May 30, 2015 1:02 PM
> *To:[email-masked] <mailto:[email-masked]>
> *Cc:*'Zhoutianran'; 'Xiayinben';[email-masked] <mailto:[email-masked]>
> *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: 
> 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 
> [email-masked] <mailto:[email-masked]>
> e-mail:[email-masked] <mailto:[email-masked]>
> Tel:    +34 913 129 041
> Mobile: +34 682 051 091
> ------------------------------------------------------------------------------------------------------------------------------------
>
>
> 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
>
> --
> e-mail:[email-masked] <mailto:[email-masked]>
> Tel:    +34 913 129 041
> Mobile: +34 682 051 091
> ------------------------------------------------------------------------------------------------------------------------------------
>
>
> 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
>
> --
> e-mail:[email-masked] <mailto:[email-masked]>
> Tel:    +34 913 129 041
> Mobile: +34 682 051 091
> ------------------------------------------------------------------------------------------------------------------------------------
>
>
> 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
>
> --
> e-mail: [email-masked] <mailto:[email-masked]>
> Tel:    +34 913 129 041
> Mobile: +34 682 051 091
> ------------------------------------------------------------------------------------------------------------------------------------
>
>
> 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
>
>
>

---

From: "zhangyali (D)" <[email-masked]>
Date: Tue, 16 Jun 2015 07:49:04 +0000

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.

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:[email-masked]]

发送时间: 2015年6月16日 14:12

收件人: zhangyali (D); DIEGO LOPEZ GARCIA

抄送: [email-masked]; Dave Hood; Susan Hares; [email-masked]

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

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).

Bert

On 16/06/15 04:40, zhangyali (D) wrote:

> 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?

> 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.

> 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?

> *抄送:*Susan Hares; [email-masked] <mailto:[email-masked]>; Dave Hood;

> [email-masked] <mailto:[email-masked]>

> 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.

> 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?

> *抄送:*Susan Hares;[email-masked] <mailto:[email-masked]>; Dave

> Hood;[email-masked] <mailto:[email-masked]>

> 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.

> 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?

> *抄送:[email-masked] <mailto:[email-masked]>; Dave Hood;[email-masked]

> <mailto:[email-masked]>

> 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...

> The key point about roles is where do they fit within the network-SQL

> Diego talks about.  The basic concepts from

> Intent (is made of) ==  object (constraint in node, connection, flow

> ), results (constraint in expect/avoid), operation (constraint, in

> condition and action)

> 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.

> *Sent:*Thursday, June 04, 2015 8:48 PM *To:*Susan Hares; 'Dave

> Hood';[email-masked] <mailto:[email-masked]> *Cc:[email-masked]

> <mailto:[email-masked]>

> 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.

> *From:*Susan Hares [mailto:[email-masked]] *Sent:*Friday, June 05,

> 2015 2:35 AM *To:*Lifengkai (Fengkai); 'Dave Hood';[email-masked]

> <mailto:[email-masked]> *Cc:[email-masked] <mailto:[email-masked]>

> these, I believe we have grouping of roles by level under the users

> intent

> 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?

> *From:*Ibnemo [mailto:[email-masked]]*On Behalf Of*Lifengkai

> (Fengkai) *Sent:*Thursday, June 04, 2015 12:42 AM *To:*Susan Hares;

> 'Dave Hood';[email-masked] <mailto:[email-masked]> *Cc:[email-masked]

> <mailto:[email-masked]>

> 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.

> 1.sub-department in each branch can communicate with sub-department in

> 3.product department want to enjoy better quality of experience with a

> 1.connects the product sub-departments via: a) full mesh topology with

> ACLs for communication constraints between subnets; b)leased line between subnets.

> *From:*Susan Hares [mailto:[email-masked]] *Sent:*Wednesday, June 03,

> 2015 7:09 AM *To:*Lifengkai (Fengkai); 'Dave Hood';[email-masked]

> <mailto:[email-masked]> *Cc:[email-masked] <mailto:[email-masked]>

> person’s context of an intent within a role.  I believe your examples

> show that

> *From:*Ibnemo [mailto:[email-masked]]*On Behalf Of*Lifengkai

> (Fengkai) *Sent:*Tuesday, June 02, 2015 3:47 AM *To:*Dave Hood; Susan

> Hares;[email-masked] <mailto:[email-masked]> *Cc:[email-masked]

> <mailto:[email-masked]>

> 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.

> *Sent:*Tuesday, June 02, 2015 1:38 AM *To:*Susan Hares;[email-masked]

> <mailto:[email-masked]> *Cc:*Zhoutianran; Xiayinben;[email-masked]

> <mailto:[email-masked]>

> 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?

> 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.

> 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

> 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.

> elements of information are germane to the service it offers, and if ports and protocols are germane to the service, so be it.

> we distinguish an NBI API that conveys intent

> 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.

> ·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

> 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.

> *Sent:*Saturday, May 30, 2015 1:02 PM *To:[email-masked]

> <mailto:[email-masked]> *Cc:*'Zhoutianran'; 'Xiayinben';[email-masked]

> <mailto:[email-masked]> *Subject:*[Sdn] Defining a Common Model for

> intent

> 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.

> 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:

> ----------------------------------------------------------------------

> --------------------------------------------------------------

> 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.

> 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

> ----------------------------------------------------------------------

> --------------------------------------------------------------

> 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.

> 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

> ----------------------------------------------------------------------

> --------------------------------------------------------------

> 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.

> 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

> ----------------------------------------------------------------------

> --------------------------------------------------------------

> 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.

> 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

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 16 Jun 2015 10:51:08 +0200

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:

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.
>
> 发送时间: 2015年6月16日14:12
> > 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
>
> >
>
> > 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,
>
> >
>
> > (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,
>
> >
>
> > 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.
>
> >
>
> > 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.
>
> >
>
> > 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.
>
> >
>
> > 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
>
> >
>
> > 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.
>
> >
>
> > 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.
>
> >
>
> > 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,
>
> >
>
> > 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.
>
> > Then for the“User-intent-context”format,
>
> >
>
> > Then for the“user-intent-context”format,
>
> >
>
> >“fitting”works.  Can you provide additional examples?
>
> >
>
> > Sue
>
> >
>
> > 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 
> > 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?
>
> >
>
> > 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 
> > 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.
>
> >
>
> > subsequent session. Hmmm…what happened to our intent-based NBI? The
>
> > 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.
>
> >
>
> > 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.
>
> >
>
> > 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
>
> >
>
> > 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.
>
> >
>
> > occurs at multiple layers.  The authors of draft-xia-ibnemo-icim have created a definition for intent and a unified model for defining 
> > We believe this defines clearly what others are calling “pure intent”(objects + results) versus “constrained intent”(objects +
>
> > 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.
>
> >
>
> > 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.
>
> >
>
> > para uso exclusivo da pessoa ou entidade de destino. Se não évossa
>
> > 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.
>
> >
>
> > 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.
>
> >
>
> > para uso exclusivo da pessoa ou entidade de destino. Se não évossa
>
> > 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.
>
> >
>
> > 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.
>
> >
>
> > para uso exclusivo da pessoa ou entidade de destino. Se não évossa
>
> > 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.
>
> >
>
> > 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.
>
> >
>
> > para uso exclusivo da pessoa ou entidade de destino. Se não évossa
>

---

From: PEDRO ANDRES ARANDA GUTIERREZ <[email-masked]>
Date: Tue, 16 Jun 2015 09:16:39 +0000

Answers inline...

---

Technology Exploration -

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

That is also my understanding

>That access is based on a system that uses RBAC (I would think).

Yes, but that is just one of the dimensions of intent.

Then I also think there is a second dimension of intent that will simplify
many things and that is what I call infrastructure intent:

Based on the ‘a router is a router is a router’ principle, there are
invariants in network boxes (router, switch, etc.). And on top of this, we
can also identify network blocks that can be composed of network boxes.
And composing network blocks, we can create networks.

This infrastructure intent, will most probably bed used directly by
network architects and indirectly by other roles.

And then there is also a third dimension regarding security invariants.

>> Sorry for not expressing my meaning explicitly. According to my
>>understanding (have not confirmed with Diego), the relationship
>> Access role restrict the scope of available objects and actions, and
>>according to different network abstraction views, access role
>> 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).
>>
>> > 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.
>>
>> >
>>
>> > access roles just define scope of network abstraction who would not
>>express intent. In ICIM (Intent Common Information Model), user own one
>>or
>> > 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
>> > of the diversity of systems and roles. And if a user could tie
>>multiply roles, it needs a rule to restrict the combination.
>>
>> >
>>
>> > 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
>>
>> >
>>
>> > (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,
>>
>> >
>>
>> > roles onto the intended modeling language. One related to the
>>abstraction available to each role, and the other in terms of a security
>>model
>> > 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,
>>
>> >
>>
>> > 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
>> > user’s roles. For example, database in the whole system could not be
>>deleted by non-administrators. So non-administrators’intent could
>> > 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 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.
>>
>> >
>>
>> > to employ different intent expressions. This has to do with the
>>particular network abstraction being accessible to each role, and would
>> > are enforced at different points in the processing of the
>>expressions, and they imply different requirements on the modeling
>>language and the
>> > 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
>> > 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).
>>
>> >
>>
>> > and the key point here is roles. We are trying to define intent with
>>the role classifications (the other thread in this mail list).
>>
>> >
>>
>> > 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
>>
>> > 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
>>
>> >
>>
>> >“For example, an end-user wants to make the communication between two
>>sites is the minimum. For this intent, price is the context.
>>
>> > separately, and the product department within enterprise A has one
>> > For the network manager of the enterprise A, based on the product
>>department manager’s requirements, the network manager wants:
>>
>> >
>>
>>https://datatracker.ietf.org/doc/draft-xia-ibnemo-icim/states. I am
>>still struggling to understand how the
>>
>>IT/network
>>identified and distinguished, thus fitting the intent
>>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.
>>
>> >
>>
>> > stack, on-demand session establishment, DNS look-ups, server load
>>balancers, and any number of other technological features that are of no
>>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
>>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.
>>
>> >
>>
>>traffic to
>> the data-plane interface. The network could be performing associated
>>auxiliary services such as usage-based billing (think
>>which an intent or service invocation is distinguished.
>>
>> > 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
>> > or the other, but the level of granularity is quite different. Shall
>> > 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
>> > 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
>>
>> > 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
>> > 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
>> > 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
>> > 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
>> > 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
>> > 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
>><mailto:[email-masked]>
>>
>> > Tel:    +34 913 129 041
>>
>> > Mobile: +34 682 051 091
>>
>> > 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
>> > 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

---

From: "zhangyali (D)" <[email-masked]>
Date: Tue, 16 Jun 2015 09:51:27 +0000

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:[email-masked]] 
发送时间: 2015年6月16日 16:51
收件人: zhangyali (D); DIEGO LOPEZ GARCIA
抄送: [email-masked]; Dave Hood; Susan Hares; [email-masked]
主题: 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.

    I see roles as:

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:
> understanding (have not confirmed with Diego), the relationship between access roles and intent roles can be show below.
>
> 图片1.png
>
> according to different network abstraction views, access role could express result/actions in high level. This high level part will be our intent role.
>
> ceratin things (types of intent expressions you can tell to the system).
>
> > express intent. In ICIM (Intent Common Information Model), user own 
> > one or
> > different roles a user can have. We'd need to define precedence 
> > rules (or a
> > abstraction available to each role, and the other in terms of a 
> > security model
> > on their operation scope, which focus on which roles are restricted 
> > to do some
> abstraction model layer, and in any abstraction model, user could express specific intent.
>
> >
>
> > one user may contain several roles, so one user can express various 
> > view of
> > 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
> > dataflow/action), or results (Expect/Avoid p2pconnect or 
> > mp2mpconnect), or
> identified and distinguished, thus fitting the intent requirements of the network users with different roles.
>
> >
>
> > 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.
>
> >
>
> > may
> the session content may well be encrypted end to end, and rightly.
>
> >
>
> > connectivity. My PC accepted the service offer implicitly by 
> > offering traffic to
> auxiliary services such as usage-based billing (think wireless roaming), so it’s more than just a dumb pipe.
>
> >
>
> > model of Intent. Also, in describing real use-cases it is important 
> > that one
> > occurs at multiple layers.  The authors of draft-xia-ibnemo-icim 
> > have created a definition for intent and a unified model for 
> > defining
> mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.
>
> >
>
> 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.
>
> >
>
> mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.
>
> >
>
> 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.
>
> >
>
> mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.
>
> >
>
> 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.
>
> >
>
> mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.
>
> >
>
> 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.
>
> >
>

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 16 Jun 2015 11:58:44 +0200

Inline

> That is also my understanding
Good. we're in sync here then
> network architects and indirectly by other roles.
So are we saying the same but in different words?
When you say "dimensions of intent", do you think that matches (or is similar to) my
"sets of intent expressions"?
> And then there is also a third dimension regarding security invariants.
Yes, there is a set of intention expressions aka:
- I want my link from A to B encrypted with the most recent/most secure encryption mechanisms".
A person in the "user" role might make such an expression:
- I want the link from A to B to be encrypted using security mechanism SHA-1
That might expressed by  an architect or operator.

But still, there will be some RBAC system that decides if an end user can or cannot
express an intent at the specific mechanism level (e.g. SHA-1) , and that role probably
should not be allowed to such a specific expression of intent (however this touches
on policy applied to the underlying system I guess).

Bert

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Tue, 16 Jun 2015 10:21:40 +0000

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) <[email-masked]<mailto:[email-masked]>> wrote:

Bert

Hi, Diego,

Best,

Yali

*发件人:*DIEGO LOPEZ GARCIA [mailto:[email-masked]]
*发送时间:*2015年6月14日18:41
*收件人:*zhangyali (D)
*抄送:*Susan Hares; [email-masked]<mailto:[email-masked]>; Dave Hood; [email-masked]<mailto:[email-masked]>
*主题:*Re: [Ibnemo] [Sdn] Defining a Common Model for intent

Hi Yali,

Be goode,

On 11 Jun 2015, at 04:28 , zhangyali (D) <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>> wrote:

Hi Diego,

Best,

Yali

*发件人:*DIEGO LOPEZ GARCIA [mailto:[email-masked]]
*发送时间:*2015年6月11日0:49
*收件人:*zhangyali (D)
*抄送:*Susan Hares; [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>; Dave Hood; [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
*主题:*Re: [Ibnemo] [Sdn] Defining a Common Model for intent

Hi Yali,

Be goode,

On 10 Jun 2015, at 04:17 , zhangyali (D) <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>> wrote:

Hi Diego,

Best,

Yali

*发件人:*DIEGO LOPEZ GARCIA [mailto:[email-masked]]
*发送时 间:*2015年6月10日5:33
*收件人:*zhangyali (D)
*抄送:*Susan Hares;[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>; Dave Hood;[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
*主题:*Re: [Ibnemo] [Sdn] Defining a Common Model for intent

Hi Yali,

Be goode,

On 9 Jun 2015, at 04:03 , zhangyali (D) <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>> wrote:

Hi Diego,

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.

Best,

Yali

*发件人:*DIEGO LOPEZ GARCIA [mailto:[email-masked]]
*发送时间:*2015年6月7日1:41
*收件人:*Susan Hares
*抄送:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>; Dave Hood;[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
*主题:*Re: [Ibnemo] [Sdn] Defining a Common Model for intent

Hi Sue,

Be goode,

On 5 Jun 2015, at 19:41 , Susan Hares <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>> wrote:

Fengkai:

Sue

*From:*Lifengkai (Fengkai) [mailto:[email-masked]]
*Sent:*Thursday, June 04, 2015 8:48 PM
*To:*Susan Hares; 'Dave Hood';[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
*Cc:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
*Subject:*RE: [Ibnemo] [Sdn] Defining a Common Model for intent

Sue and all,

Thanks.

Best Regards,

Fengkai

*From:*Susan Hares [mailto:[email-masked]]
*Sent:*Friday, June 05, 2015 2:35 AM
*To:*Lifengkai (Fengkai); 'Dave Hood';[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
*Cc:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
*Subject:*RE: [Ibnemo] [Sdn] Defining a Common Model for intent

Fengkai and all:

Sue

*From:*Ibnemo [mailto:[email-masked]]*On Behalf Of*Lifengkai (Fengkai)
*Sent:*Thursday, June 04, 2015 12:42 AM
*To:*Susan Hares; 'Dave Hood';[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
*Cc:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
*Subject:*Re: [Ibnemo] [Sdn] Defining a Common Model for intent

Hi Sue and all,

1.connects the product sub-departments via: a) full mesh topology with ACLs for communication constraints between subnets; b)leased line between subnets.

Thanks.

Best Regards,

Fengkai

*From:*Susan Hares [mailto:[email-masked]]
*Sent:*Wednesday, June 03, 2015 7:09 AM
*To:*Lifengkai (Fengkai); 'Dave Hood';[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
*Cc:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
*Subject:*RE: [Ibnemo] [Sdn] Defining a Common Model for intent

Fengkai:

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:[email-masked]]*On Behalf Of*Lifengkai (Fengkai)
*Sent:*Tuesday, June 02, 2015 3:47 AM
*To:*Dave Hood; Susan Hares;[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
*Cc:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
*Subject:*Re: [Ibnemo] [Sdn] Defining a Common Model for intent

Hi Dave and all,

Best Regards,

Fengkai

*From:*sdn [mailto:[email-masked]]*On Behalf Of*Dave Hood
*Sent:*Tuesday, June 02, 2015 1:38 AM
*To:*Susan Hares;[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
*Cc:*Zhoutianran; Xiayinben;[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
*Subject:*Re: [Sdn] Defining a Common Model for intent

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.

·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?

Dave

*From:*sdn [mailto:[email-masked]]*On Behalf Of*Susan Hares
*Sent:*Saturday, May 30, 2015 1:02 PM
*To:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
*Cc:*'Zhoutianran'; 'Xiayinben';[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
*Subject:*[Sdn] Defining a Common Model for intent

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
[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ibnemo

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Tue, 16 Jun 2015 10:24:58 +0000

Hi,

Just let me remark we should not pre-define once and forever the views and roles for expressing intent, but define mechanisms for expressing those views and roles, and for combining them when a certain user happens to have several of them available. It would be interesting to have some predefined ones indeed, but hardwiring them would be a great mistake.

Be goode,

On 16 Jun 2015, at 10:58 , Bert Wijnen (IETF) <[email-masked]<mailto:[email-masked]>> wrote:

Inline

---

Technology Exploration -

El 16/06/15 10:51, "Bert Wijnen (IETF)" <[email-masked]<mailto:[email-masked]>> escribió:

Yali,

   I see roles as:

I think you had stated that you sort of liked that list. Maybe I
misunderstood.
That is also my understanding
Good. we're in sync here then
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).
Yes, but that is just one of the dimensions of intent.

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

Bert

图片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.

Best,

Yali

-----邮件原件-----

发送时间: 2015年6月16日14:12

抄送: [email-masked]<mailto:[email-masked]>; Dave Hood; Susan Hares; [email-masked]<mailto:[email-masked]>

The access control to the various "intent expressions" will be based on
a role.

Bert

Hi, Diego,

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

Be goode,
On 11 Jun 2015, at 04:28 , zhangyali (D) <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>> wrote:

Hi Diego,

Best,
Yali
*发件人:*DIEGO LOPEZ GARCIA [mailto:[email-masked]]
*发送时间:*2015年6月11日0:49
*收件人:*zhangyali (D)
*抄送:*Susan Hares; [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>; Dave Hood;
[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
*主题:*Re: [Ibnemo] [Sdn] Defining a Common Model for intent
Hi Yali,
Nothing to excuse about. We are discussing here to understand one
another.

Be goode,
On 10 Jun 2015, at 04:17 , zhangyali (D) <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>> 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:[email-masked]]
*发送时 间:*2015年6月10日5:33
*收件人:*zhangyali (D)
*抄送:*Susan Hares;[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>; Dave
Hood;[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
*主题:*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.

Be goode,
On 9 Jun 2015, at 04:03 , zhangyali (D) <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>> wrote:

Hi Diego,

not express the intent of deleting system. So users’role will
constraint users’intent.

Best,
Yali
*发件人:*DIEGO LOPEZ GARCIA [mailto:[email-masked]]
*发送时间:*2015年6月7日1:41
*收件人:*Susan Hares
*抄送:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>; Dave Hood;[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>
*主题:*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 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 <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>> 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).

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.

Sue
*From:*Lifengkai (Fengkai) [mailto:[email-masked]]
*Sent:*Thursday, June 04, 2015 8:48 PM *To:*Susan Hares; 'Dave
Hood';[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> *Cc:[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>
*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:

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:[email-masked]] *Sent:*Friday, June 05,
2015 2:35 AM *To:*Lifengkai (Fengkai); 'Dave Hood';[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]> *Cc:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
*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

Sue
*From:*Ibnemo [mailto:[email-masked]]*On Behalf Of*Lifengkai
(Fengkai) *Sent:*Thursday, June 04, 2015 12:42 AM *To:*Susan Hares;
'Dave Hood';[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> *Cc:[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>
*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:

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.

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:[email-masked]] *Sent:*Wednesday, June 03,
2015 7:09 AM *To:*Lifengkai (Fengkai); 'Dave Hood';[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]> *Cc:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
*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

Hares;[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> *Cc:[email-masked]<mailto:[email-masked]>

Any thoughts about this consideration?
Best Regards,
Fengkai
*From:*sdn [mailto:[email-masked]]*On Behalf Of*Dave Hood
*Sent:*Tuesday, June 02, 2015 1:38 AM *To:*Susan Hares;[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]> *Cc:*Zhoutianran; Xiayinben;[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>
*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:

better somewhere else. Now I accept one of the offered widgets and go
through the checkout process.

productive direction, or even if it’s not, I welcome suggestions to
clarify the concept.

Dave
*From:*sdn [mailto:[email-masked]]*On Behalf Of*Susan Hares
*Sent:*Saturday, May 30, 2015 1:02 PM *To:[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]> *Cc:*'Zhoutianran'; 'Xiayinben';[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]> *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:

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.

e-mail:[email-masked]

Tel:    +34 913 129 041
Mobile: +34 682 051 091

e-mail:[email-masked]

Tel:    +34 913 129 041
Mobile: +34 682 051 091

e-mail:[email-masked]

Tel:    +34 913 129 041
Mobile: +34 682 051 091

Tel:    +34 913 129 041
Mobile: +34 682 051 091

Dr Diego R. Lopez
Telefonica I+D

---

From: PEDRO ANDRES ARANDA GUTIERREZ <[email-masked]>
Date: Tue, 16 Jun 2015 11:11:46 +0000

Completely agree. I might be overusing the infrastructure example. But it’s just that: an example. I’m more interested in nailing down the different “dimensions” than things that are inside one of those dimensions. I use the term dimension, because IMHO the different sets (as Bert calls them) are orthogonal in that using something in one set doesn’t preclude anything for the other sets.

Best, /PA

PS: And yes, I’m interesting in the network-near set or dimension because there are a couple of nice characteristics there (recursion to mention one) which cold make our lives a lot easier.
De: DIEGO LOPEZ GARCIA <[email-masked]<mailto:[email-masked]>>
Fecha: martes, 16 de junio de 2015 12:24
Para: "Bert Wijnen (IETF)" <[email-masked]<mailto:[email-masked]>>
CC: PEDRO ANDRES ARANDA GUTIERREZ <[email-masked]<mailto:[email-masked]>>, "zhangyali (D)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Dave Hood <[email-masked]<mailto:[email-masked]>>, Sue Hares <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Asunto: Re: [Ibnemo] 答复: 答复: [Sdn] Defining a Common Model for intent

Hi,

Be goode,

Inline

---

Technology Exploration -

Yali,

   I see roles as:

Bert

Bert

图片1.png

Best,

Yali

-----邮件原件-----

发送时间: 2015年6月16日14:12

Bert

Hi, Diego,

Best,
Yali

Be goode,

Hi Diego,

Best,
Yali

Be goode,

Hi Diego,

Best,
Yali

Be goode,

Hi Diego,

Best,
Yali

Be goode,

Fengkai:

Sue

Sue

Thanks.
Best Regards,
Fengkai

Dave

e-mail:[email-masked]<mailto:[email-masked]>

Tel:    +34 913 129 041
Mobile: +34 682 051 091

e-mail:[email-masked]<mailto:[email-masked]>

Tel:    +34 913 129 041
Mobile: +34 682 051 091

e-mail:[email-masked]<mailto:[email-masked]>

Tel:    +34 913 129 041
Mobile: +34 682 051 091

Tel:    +34 913 129 041
Mobile: +34 682 051 091

Dr Diego R. Lopez
Telefonica I+D

---

Technology Exploration -

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 16 Jun 2015 14:15:09 +0200

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:
>
> On 16 Jun 2015, at 07:12 , Bert Wijnen (IETF) <[email-masked] <mailto:[email-masked]>> wrote:
>
>>> On 11 Jun 2015, at 04:28 , zhangyali (D) <[email-masked] <mailto:[email-masked]> 
>>> *抄送:*Susan Hares; [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>; Dave Hood; [email-masked] 
>>> <mailto:[email-masked]> <mailto:[email-masked]>
>>> 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 
>>> On 10 Jun 2015, at 04:17 , zhangyali (D) <[email-masked] <mailto:[email-masked]> 
>>> *抄送:*Susan Hares;[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>; Dave Hood;[email-masked] <mailto:[email-masked]> 
>>> <mailto:[email-masked]>
>>> On 9 Jun 2015, at 04:03 , zhangyali (D) <[email-masked] <mailto:[email-masked]> 
>>> 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 
>>> *抄送:[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>; Dave Hood;[email-masked] <mailto:[email-masked]> 
>>> <mailto:[email-masked]>
>>> 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.
>>>
>>> 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.
>>>
>>> On 5 Jun 2015, at 19:41 , Susan Hares <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>> Fengkai:
>>>
>>> *To:*Susan Hares; 'Dave Hood';[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>> *Cc:[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>> *To:*Lifengkai (Fengkai); 'Dave Hood';[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>> *Cc:[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>> 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
>>>
>>> *To:*Susan Hares; 'Dave Hood';[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>> *Cc:[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>> “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.”
>>>
>>> *To:*Lifengkai (Fengkai); 'Dave Hood';[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>> *Cc:[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>> 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
>>>
>>> *To:*Dave Hood; Susan Hares;[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>> *Cc:[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>> 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.
>>>
>>> *To:*Susan Hares;[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>> *Cc:*Zhoutianran; Xiayinben;[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>> 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?
>>>
>>> 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.
>>>
>>> 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 
>>> 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.
>>>
>>> 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 
>>> 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
>>>
>>> *To:[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>> *Cc:*'Zhoutianran'; 'Xiayinben';[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>> operations + constraints).   The draft can be found at: https://datatracker.ietf.org/doc/draft-xia-ibnemo-icim/.   The authors 
>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>> 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 
>>> 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 
>>> 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 
>>> 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 
>>> 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 
>>> 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 
>>> 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 
>>> 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

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Mon, 22 Jun 2015 07:29:06 +0000

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) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Diego.

Bert

Be goode,

On 16 Jun 2015, at 07:12 , Bert Wijnen (IETF) <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>> wrote:

Bert

Hi, Diego,

Best,

Yali

Hi Yali,

Be goode,

On 11 Jun 2015, at 04:28 , zhangyali (D) <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>> wrote:

Hi Diego,

Best,

Yali

*发件人:*DIEGO LOPEZ GARCIA [mailto:[email-masked]]
*发送时间:*2015年6月11日0:49
*收件人:*zhangyali (D)
*抄送:*Susan Hares; [email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>; Dave Hood; [email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
*主题:*Re: [Ibnemo] [Sdn] Defining a Common Model for intent

Hi Yali,

Be goode,

On 10 Jun 2015, at 04:17 , zhangyali (D) <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>> wrote:

Hi Diego,

Best,

Yali

*发件人:*DIEGO LOPEZ GARCIA [mailto:[email-masked]]
*发送时 间:*2015年6月10日5:33
*收件人:*zhangyali (D)
*抄送:*Susan Hares;[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>; Dave Hood;[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
*主题:*Re: [Ibnemo] [Sdn] Defining a Common Model for intent

Hi Yali,

Be goode,

On 9 Jun 2015, at 04:03 , zhangyali (D) <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>> wrote:

Hi Diego,

Best,

Yali

*发件人:*DIEGO LOPEZ GARCIA [mailto:[email-masked]]
*发送时间:*2015年6月7日1:41
*收件人:*Susan Hares
*抄送:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>; Dave Hood;[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
*主题:*Re: [Ibnemo] [Sdn] Defining a Common Model for intent

Hi Sue,

Be goode,

On 5 Jun 2015, at 19:41 , Susan Hares <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>> wrote:

Fengkai:

Sue

*From:*Lifengkai (Fengkai) [mailto:[email-masked]]
*Sent:*Thursday, June 04, 2015 8:48 PM
*To:*Susan Hares; 'Dave Hood';[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
*Cc:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
*Subject:*RE: [Ibnemo] [Sdn] Defining a Common Model for intent

Sue and all,

Thanks.

Best Regards,

Fengkai

*From:*Susan Hares [mailto:[email-masked]]
*Sent:*Friday, June 05, 2015 2:35 AM
*To:*Lifengkai (Fengkai); 'Dave Hood';[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
*Cc:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
*Subject:*RE: [Ibnemo] [Sdn] Defining a Common Model for intent

Fengkai and all:

Sue

*From:*Ibnemo [mailto:[email-masked]]*On Behalf Of*Lifengkai (Fengkai)
*Sent:*Thursday, June 04, 2015 12:42 AM
*To:*Susan Hares; 'Dave Hood';[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
*Cc:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
*Subject:*Re: [Ibnemo] [Sdn] Defining a Common Model for intent

Hi Sue and all,

Thanks.

Best Regards,

Fengkai

*From:*Susan Hares [mailto:[email-masked]]
*Sent:*Wednesday, June 03, 2015 7:09 AM
*To:*Lifengkai (Fengkai); 'Dave Hood';[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
*Cc:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
*Subject:*RE: [Ibnemo] [Sdn] Defining a Common Model for intent

Fengkai:

Useràintentàcontext

Sue

*From:*Ibnemo [mailto:[email-masked]]*On Behalf Of*Lifengkai (Fengkai)
*Sent:*Tuesday, June 02, 2015 3:47 AM
*To:*Dave Hood; Susan Hares;[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
*Cc:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
*Subject:*Re: [Ibnemo] [Sdn] Defining a Common Model for intent

Hi Dave and all,

Best Regards,

Fengkai

*From:*sdn [mailto:[email-masked]]*On Behalf Of*Dave Hood
*Sent:*Tuesday, June 02, 2015 1:38 AM
*To:*Susan Hares;[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
*Cc:*Zhoutianran; Xiayinben;[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
*Subject:*Re: [Sdn] Defining a Common Model for intent

Dave

*From:*sdn [mailto:[email-masked]]*On Behalf Of*Susan Hares
*Sent:*Saturday, May 30, 2015 1:02 PM
*To:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
*Cc:*'Zhoutianran'; 'Xiayinben';[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
*Subject:*[Sdn] Defining a Common Model for intent

Sue Hares

_______________________________________________
Ibnemo mailing list
[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ibnemo

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 23 Jun 2015 08:38:42 +0200

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) <[email-masked] <mailto:[email-masked]>> wrote:
>
>> Hi Diego.
>>
>>> 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:
>>>
>>> On 16 Jun 2015, at 07:12 , Bert Wijnen (IETF) <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>
>>>>> 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,
>>>>>
>>>>> <mailto:[email-masked]> <mailto:[email-masked]>> 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 
>>>>> *抄送:*Susan Hares; [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>; Dave Hood; [email-masked] 
>>>>> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
>>>>> <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Hi Diego,
>>>>>
>>>>> *抄送:*Susan Hares;[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>; Dave Hood;[email-masked] 
>>>>> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
>>>>> 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,
>>>>>
>>>>> <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Hi Diego,
>>>>>
>>>>> 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.
>>>>>
>>>>> *抄送:[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>; Dave Hood;[email-masked] 
>>>>> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
>>>>> 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.
>>>>>
>>>>> 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 <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> 
>>>>> 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).
>>>>>
>>>>> *To:*Susan Hares; 'Dave Hood';[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
>>>>> *Cc:[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
>>>>> 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).
>>>>>
>>>>> *To:*Lifengkai (Fengkai); 'Dave Hood';[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
>>>>> *Cc:[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
>>>>> 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
>>>>>
>>>>> *To:*Susan Hares; 'Dave Hood';[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
>>>>> *Cc:[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
>>>>> *To:*Lifengkai (Fengkai); 'Dave Hood';[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
>>>>> *Cc:[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
>>>>> *To:*Dave Hood; Susan Hares;[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
>>>>> *Cc:[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
>>>>> users, application developers, tenant IT/network administrators, operator network administrators, are valuable to be 
>>>>> *To:*Susan Hares;[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
>>>>> *Cc:*Zhoutianran; Xiayinben;[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
>>>>> 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.
>>>>>
>>>>> 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 
>>>>> 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 
>>>>> 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?
>>>>>
>>>>> 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.
>>>>>
>>>>> 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
>>>>>
>>>>> *To:[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
>>>>> *Cc:*'Zhoutianran'; 'Xiayinben';[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
>>>>> 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:
>>>>>
>>>>> 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
>>>>>
>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
>>>>> 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.
>>>>>
>>>>> 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
>>>>>
>>>>> --
>>>>> 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.
>>>>>
>>>>> 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
>>>>>
>>>>> --
>>>>> 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.
>>>>>
>>>>> 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
>>>>>
>>>>> --
>>>>> 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.
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>>