From nobody Mon Jun 1 00:15:59 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 320A41A8AA1 for ; Mon, 1 Jun 2015 00:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7OpEA_6Vr5k for ; Mon, 1 Jun 2015 00:15:56 -0700 (PDT) Received: from kaukau.ecs.vuw.ac.nz (kaukau.ecs.vuw.ac.nz [130.195.5.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E49CF1A8AA0 for ; Mon, 1 Jun 2015 00:15:55 -0700 (PDT) Received: from mail1.ecs.vuw.ac.nz (mail1.ecs.vuw.ac.nz [130.195.5.23]) by kaukau.ecs.vuw.ac.nz (8.15.1/8.13.3) with ESMTP id t517FqSe011363 for ; Mon, 1 Jun 2015 19:15:52 +1200 (NZST) Received: from winston-macbook.local (121-73-247-182.broadband.telstraclear.net [121.73.247.182]) (authenticated bits=0) by mail1.ecs.vuw.ac.nz (8.15.1/8.13.3) with ESMTPSA id t517FpZT005964 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 1 Jun 2015 19:15:52 +1200 (NZST) Message-ID: <556C06E5.60404@ecs.vuw.ac.nz> Date: Mon, 01 Jun 2015 19:16:53 +1200 From: Winston Seah User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: sdn@irtf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (kaukau.ecs.vuw.ac.nz [130.195.5.20]); Mon, 01 Jun 2015 19:15:53 +1200 (NZST) X-Scanned-By: MIMEDefang 2.75 on 130.195.5.20 Archived-At: Subject: [Sdn] Scholarships for the Master of Engineering (ME) in Software Defined Networking at Victoria University of Wellington, NZ X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 07:15:58 -0000 The School of Engineering and Computer Science is offering two full-time Master scholarships (domestic tuition fees plus a 1-year stipend of NZ$20,000) to excellent candidates to work on the following topics: i) "Performance Evaluation and Analytical Modelling of SDN and OpenFlow-based Networks and Systems". The successful candidate is expected to have a good foundation in theoretical performance analysis techniques, viz., queuing theory. Knowledge of common network simulation platforms (e.g. OmNet++, QualNet, etc) would be advantageous. He/she will also have the opportunity to spend time in Kyoto University, Japan, to work with world leading experts in performance analysis. ii) "Traffic classification in Enterprise Networks using Software Defined Networking". The successful candidate is expected to have a good fundamental knowledge of networking and strong hands-on skills required to validate his/her research results on a real network testbed. Knowledge of traffic classification techniques for supporting quality of service in the Internet would be given preferential consideration. Interested applicants, please contact Professor Winston Seah at winston.seah@ecs.vuw.ac.nz, attaching your transcripts, publications list, and CV. If you are suitable, you will then be provided with the information on how to apply for admission into our ME degree programme. -- Winston Seah, Dr.Eng., SMIEEE, MACM Professor of Network Engineering Postgraduate Research Coordinator School of Engineering and Computer Science Victoria University of Wellington P.O. Box 600, Wellington 6140, New Zealand URL: https://ecs.victoria.ac.nz/Main/WinstonSeah Email: Winston.Seah@ecs.vuw.ac.nz Phone: +64 4 463 5233 (ext: 8493) Fax: +64 4 463 5045 From nobody Mon Jun 1 10:38:11 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC6FD1B2FC4 for ; Mon, 1 Jun 2015 10:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtxeHxwK4GB0 for ; Mon, 1 Jun 2015 10:38:05 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E22121B2FCA for ; Mon, 1 Jun 2015 10:38:04 -0700 (PDT) X-AuditID: c6180641-f79086d000001909-1d-556c330a5509 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 08.CA.06409.A033C655; Mon, 1 Jun 2015 12:25:14 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0210.002; Mon, 1 Jun 2015 13:38:01 -0400 From: Dave Hood To: Susan Hares , "sdn@irtf.org" Thread-Topic: [Sdn] Defining a Common Model for intent Thread-Index: AdCbEy9UHkEQylvfQJyfdpRUZhhXPwBfgiUQ Date: Mon, 1 Jun 2015 17:37:59 +0000 Message-ID: <8D15A2BAF93E9C49AB037A0647E5FA643F8490D8@eusaamb105.ericsson.se> References: <00f301d09b13$79cc2410$6d646c30$@ndzh.com> In-Reply-To: <00f301d09b13$79cc2410$6d646c30$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_8D15A2BAF93E9C49AB037A0647E5FA643F8490D8eusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyuXRPuC6XcU6owdXVKhatNx8xWZxf8JzF 4s+bVywWP57eZbWYcHIBswOrR8uRt6weS5b8ZPKYvPEwm8fs19dZA1iiuGxSUnMyy1KL9O0S uDIalixlKpj3lrHixfmNjA2M+84ydjFyckgImEgcOvOJBcIWk7hwbz1bFyMXh5DAUUaJ9tlv GCGcZYwSHbtPgXWwCWhIPLk0mQnEFhFwkHjQs54ZxGYWKJU4cuUkK4gtLGAqsWfHOhaIGjOJ lRdXAPVyANlGEhtO2IOEWQRUJH6sm8AGYvMK+Eoc7tsINl4IqHz13k1gYzgFzCXO/28HsxmB jvt+ag0TxCpxiVtP5jNBHC0gsWTPeWYIW1Ti5eN/rBC2ksTH3/PZIerzJf4u+MQKsUtQ4uTM JywTGEVnIRk1C0nZLCRlEHEdiQW7P7FB2NoSyxa+Zoaxzxx4zIQsvoCRfRUjR2lxalluupHh JkZgLB6TYHPcwbjgk+UhRgEORiUeXgWf7FAh1sSy4srcQ4zSHCxK4rwXVUNChQTSE0tSs1NT C1KL4otKc1KLDzEycXBKNTCaOXTfatgQs732U9XD5+zFCwvOlp9YeFXFvYn13XJ+3+zqnvlx B4SOP1m9s9G+dMeOuRcb2xlmTvm4OsjsfZ5htvwbj3kbbj5+7PWIWWWTnfKihYdF/xTELH20 60RI7mmN/atmCP3+tjlCyIXr8YTHx1l0bU5WLJvBdfNJzL1nexmyufSdpGvmKLEUZyQaajEX FScCALciPzWmAgAA Archived-At: Cc: 'Zhoutianran' , 'Xiayinben' , "ibnemo@ietf.org" Subject: Re: [Sdn] Defining a Common Model for intent X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 17:38:10 -0000 --_000_8D15A2BAF93E9C49AB037A0647E5FA643F8490D8eusaamb105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 l= ooking forward to making the concept more precise. When I click a link on a web page, I express an intent to invoke whatever t= hat link offers. Completely below the surface is a layer stack, on-demand s= ession establishment, DNS look-ups, server load balancers, and any number o= f other technological features that are of no interest to me. Why not use t= hat 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 a= nd receive an offer of several widgets, some new, some used, some with a ch= oice 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, hav= ing found nothing I liked better somewhere else. Now I accept one of the of= fered widgets and go through the checkout process. Do we agree that this is a fairly pure expression of intent as conceptualiz= ed 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 S= DN of one kind or another. I invoke my intent through a GUI onto software l= ocal 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 conc= erned, the client makes DNS queries and swaps opaque TCP packets over a for= warding path that may already exist, or may need to be learned and set up o= n demand. This is about right, because the session content may well be encr= ypted 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 subsequen= t session. Hmmm... what happened to our intent-based NBI? The SDN offered m= y PC a packet interface with the properties of knowing how to recognize and= route DNS queries specially, and general IP connectivity. My PC accepted t= he service offer implicitly by offering traffic to the data-plane interface= . The network could be performing associated auxiliary services such as usa= ge-based billing (think wireless roaming), so it's more than just a dumb pi= pe. If this is not a legitimate example of intent, it would be good to write th= e 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 inten= t is to have an E-Line between two of my campi. I necessarily care about po= rts and protocols; talk about intent being portable and protocol independen= t continues to confuse me completely. How can I order an E-line without car= ing about such details? [Nor is this intent portable.] Obviously, an SDN controller is going to expose whatever actions and elemen= ts of information are germane to the service it offers, and if ports and pr= otocols are germane to the service, so be it. The SDN architecture, being recursive, models the north side of any control= ler as exposing an instance of an information model, customized for the int= ended 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 no= t? 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 contras= t, what we might agree is *not* an intent or a service is the manipulation = of a granular information model, the explicit visibility of multiple object= s, 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 opti= on 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 o= f course may be complex entities themselves, virtualized into simple-appear= ing lumps) seems to me to capture the essence of what people are talking ab= out 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:sdn-bounces@irtf.org] On Behalf Of Susan Hares Sent: Saturday, May 30, 2015 1:02 PM To: sdn@irtf.org Cc: 'Zhoutianran'; 'Xiayinben'; ibnemo@ietf.org 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/msg0= 0646.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 req= uest that signals Intent from an application to a controller, it is importa= nt to define Intent, and provide a clear model of Intent. Also, in describ= ing real use-cases it is important that one uses the same definition and mo= del for Intent in each use case. In the current forums examining Intent (ODL NIC, ODL Nemo, OF NBI and Keyst= one, OPNFV Movie, OpenStack) there is a realization that Intent occurs at m= ultiple layers. The authors of draft-xia-ibnemo-icim have created a defini= tion 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 i= ncludes operations toward that result. 3) Operations conditions perform actions within/modified by constraint= s. We believe this defines clearly what others are calling "pure intent" (obje= cts + results) versus "constrained intent" (objects + operations + constrai= nts). 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 --_000_8D15A2BAF93E9C49AB037A0647E5FA643F8490D8eusaamb105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

An excerpt from an e= mail 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 wha= tever that link offers. Completely below the surface is a layer stack, on-demand session establishment, DNS look-ups, server load ba= lancers, and any number of other technological features that are of no inte= rest 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 Amazo= n. 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 featu= res. 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 widg= ets and go through the checkout process.

 

Do we agree that this is a fairly pure expression of intent as conce= ptualized 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 t= he 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 th= e 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 s= waps opaque TCP packets over a forwarding path that may already exist, or may need to be learned and set up on demand. Th= is 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 queri= es 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 knowin= g how to recognize and route DNS queries specially, and general IP connecti= vity. My PC accepted the service offer implicitly by offering traffic to the data-plane interface. The network co= uld 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 w= rite 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 m= y 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 proto= col independent continues to confuse me completely. How can I order an E-li= ne 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 b= y 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 negotiati= on, offer and acceptance, but what happens across the API is effectively on= e 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 object= s, how they are interrelated, their attributes, and the like.

 

·       &= nbsp; Network as a= single lump vs some non-trivial topology.

 

·       &= nbsp; Chauffeur vs= driving a car. Legitimate reasons to choose one option or the other, but t= he 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 pe= ople are talking about when they say intent or service. I am not comfortabl= e with the way I am expressing it, so if this is a step in a productive dir= ection, or even if it’s not, I welcome suggestions to clarify the concept.

 

Dave

 

From: sdn [mai= lto:sdn-bounces@irtf.org] On Behalf Of Susan Hares
Sent: Saturday, May 30, 2015 1:02 PM
To: sdn@irtf.org
Cc: 'Zhoutianran'; 'Xiayinben'; ibnemo@ietf.org
Subject: [Sdn] Defining a Common Model for intent<= /p>

 

On this mail list, there has been a discussion of tw= o types of information for Intent and Nemo: (http://www.ietf.org/mail-archi= ve/web/sdn/current/msg00646.html) :

 

1)      What information is needed to represent a service r= equest,

2)      How to represent and transport the information for = a request.

 

In order to define what information is needed to rep= resent a 1) service request that signals Intent from an application to a co= ntroller, it is important to define Intent, and provide a clear model of In= tent.  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-ibnem= o-icim have created a definition for intent and a unified model for defining intent which can handle 1 or multiple lay= ers. The model suggest that:

1)&nbs= p;     A user has a int= ent that is expressed in a context.

2)&nbs= p;     Intent (usually) involves an object with a r= esult, and optionally includes operations toward that result.

3)&nbs= p;     Operations conditions perform actions within= /modified by constraints.

 

We believe this defines clearly what others are call= ing “pure intent” (objects + results) versus “constra= ined intent” (objects + operations + constraints).  &nbs= p;The draft can be found at:   https://datatracker.ietf.org/doc/draft-xi= a-ibnemo-icim/ .   The authors are looking for feedback on the concepts in the = draft.   

 

Sue Hares

--_000_8D15A2BAF93E9C49AB037A0647E5FA643F8490D8eusaamb105erics_-- From nobody Mon Jun 1 14:11:51 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE0B1B340E for ; Mon, 1 Jun 2015 14:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.454 X-Spam-Level: X-Spam-Status: No, score=-98.454 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQV3B3L301w6 for ; Mon, 1 Jun 2015 14:11:42 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA531B3185 for ; Mon, 1 Jun 2015 14:11:34 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.80.157; From: "Susan Hares" To: "'Dave Hood'" , References: <00f301d09b13$79cc2410$6d646c30$@ndzh.com> <8D15A2BAF93E9C49AB037A0647E5FA643F8490D8@eusaamb105.ericsson.se> In-Reply-To: <8D15A2BAF93E9C49AB037A0647E5FA643F8490D8@eusaamb105.ericsson.se> Date: Mon, 1 Jun 2015 17:11:32 -0400 Message-ID: <01f601d09caf$8980e4c0$9c82ae40$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01F7_01D09C8E.0273D8A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGjwAWNbhwtlPLyYWaj2K7LZAyOCALTOOmfndtChCA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Zhoutianran' , 'Xiayinben' , ibnemo@ietf.org Subject: Re: [Sdn] Defining a Common Model for intent X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 21:11:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01F7_01D09C8E.0273D8A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 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:sdn-bounces@irtf.org] On Behalf Of Dave Hood Sent: Monday, June 01, 2015 1:38 PM To: Susan Hares; sdn@irtf.org Cc: 'Zhoutianran'; 'Xiayinben'; ibnemo@ietf.org Subject: Re: [Sdn] Defining a Common Model for intent An excerpt from an email I sent on the ONF NBI list, which may contain some useful thoughts: I have always had trouble understanding what an intent really is, so I am looking forward to making the concept more precise. When I click a link on a web page, I express an intent to invoke whatever that link offers. Completely below the surface is a layer stack, on-demand session establishment, DNS look-ups, server load balancers, and any number of other technological features that are of no interest to me. Why not use that as an example of intent? Better yet, we talk about negotiation and selection. Suppose I want to buy a widget. I probably already have some idea whether I want to go to Amazon or EBay or somewhere else. Suppose it's Amazon. I search Amazon's catalog and receive an offer of several widgets, some new, some used, some with a choice of colour or other pertinent features. If I see nothing I like, I may open a new browser window and check out Best Buy or EBay (lots more hidden technology to make that happen!). Maybe I come back to the Amazon page, having found nothing I liked better somewhere else. Now I accept one of the offered widgets and go through the checkout process. Do we agree that this is a fairly pure expression of intent as conceptualized in the paper? (If not, let's talk about making a Skype call.) Ok, that's my intent as an internet user. Let's assume the network is all SDN of one kind or another. I invoke my intent through a GUI onto software local to my PC, but I don't think we can call the PC an SDN controller. It's more an active mediator, a client to an SDN. As far as the network is concerned, the client makes DNS queries and swaps opaque TCP packets over a forwarding path that may already exist, or may need to be learned and set up on demand. This is about right, because the session content may well be encrypted end to end, and rightly. To the SDN controller, my intent is satisfied by directing DNS queries to a known DNS server somewhere, and ensuring IP connectivity for the subsequent session. Hmmm. what happened to our intent-based NBI? The SDN offered my PC a packet interface with the properties of knowing how to recognize and route DNS queries specially, and general IP connectivity. My PC accepted the service offer implicitly by offering traffic to the data-plane interface. The network could be performing associated auxiliary services such as usage-based billing (think wireless roaming), so it's more than just a dumb pipe. If this is not a legitimate example of intent, it would be good to write the white paper in such a way that clearly excludes such cases. Use case 2: suppose I am a corporate IT employee, and suppose that my intent is to have an E-Line between two of my campi. I necessarily care about ports and protocols; talk about intent being portable and protocol independent continues to confuse me completely. How can I order an E-line without caring about such details? [Nor is this intent portable.] Obviously, an SDN controller is going to expose whatever actions and elements of information are germane to the service it offers, and if ports and protocols are germane to the service, so be it. The SDN architecture, being recursive, models the north side of any controller as exposing an instance of an information model, customized for the intended client/customer/app/user. That being the case, how do we distinguish an NBI API that conveys intent (service: same thing?) from one that does not? I have recently come to the view that granularity is the criterion by which an intent or service invocation is distinguished. Colloquially speaking, a service invocation is a single invocation across the API: give me E-Line. Now of course this turns into constraint negotiation, offer and acceptance, but what happens across the API is effectively one transaction. In contrast, what we might agree is *not* an intent or a service is the manipulation of a granular information model, the explicit visibility of multiple objects, how they are interrelated, their attributes, and the like. . Network as a single lump vs some non-trivial topology. . Chauffeur vs driving a car. Legitimate reasons to choose one option or the other, but the level of granularity is quite different. Shall we agree that driving is too granular to be considered intent? This idea of granularity and detailed operations on the components (which of course may be complex entities themselves, virtualized into simple-appearing lumps) seems to me to capture the essence of what people are talking about when they say intent or service. I am not comfortable with the way I am expressing it, so if this is a step in a productive direction, or even if it's not, I welcome suggestions to clarify the concept. Dave From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of Susan Hares Sent: Saturday, May 30, 2015 1:02 PM To: sdn@irtf.org Cc: 'Zhoutianran'; 'Xiayinben'; ibnemo@ietf.org 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 ------=_NextPart_000_01F7_01D09C8E.0273D8A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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  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:sdn-bounces@irtf.org] On Behalf Of Dave = Hood
Sent: Monday, June 01, 2015 1:38 PM
To: Susan = Hares; sdn@irtf.org
Cc: 'Zhoutianran'; 'Xiayinben'; = ibnemo@ietf.org
Subject: Re: [Sdn] Defining a Common Model for = intent

 

An excerpt from an email I sent on the ONF = NBI list, which may contain some useful = thoughts:

 

I have always had trouble understanding = what an intent really is, so I am looking forward to making the concept = more precise.

 

When I click a link on a web page, I = express an intent to invoke whatever that link offers. Completely below = the surface is a layer stack, on-demand session establishment, DNS = look-ups, server load balancers, and any number of other technological = features that are of no interest to me. Why not use that as an example = of intent?

 

Better yet, we talk about negotiation and = selection. Suppose I want to buy a widget. I probably already have some = idea whether I want to go to Amazon or EBay or somewhere else. Suppose = it’s Amazon. I search Amazon’s catalog and receive an offer = of several widgets, some new, some used, some with a choice of colour or = other pertinent features. If I see nothing I like, I may open a new = browser window and check out Best Buy or EBay (lots more hidden = technology to make that happen!). Maybe I come back to the Amazon page, = having found nothing I liked better somewhere else. Now I accept one of = the offered widgets and go through the checkout process. =

 

Do we agree that this is a fairly pure = expression of intent as conceptualized in the paper? (If not, = let’s talk about making a Skype call.)

 

Ok, that’s my intent as an internet = user. Let’s assume the network is all SDN of one kind or another. = I invoke my intent through a GUI onto software local to my PC, but I = don’t think we can call the PC an SDN controller. It’s more = an active mediator, a client to an SDN. As far as the network is = concerned, the client makes DNS queries and swaps opaque TCP packets = over a forwarding path that may already exist, or may need to be learned = and set up on demand. This is about right, because the session content = may well be encrypted end to end, and rightly.

 

To the SDN controller, my intent is = satisfied by directing DNS queries to a known DNS server somewhere, and = ensuring IP connectivity for the subsequent session. Hmmm… what = happened to our intent-based NBI? The SDN offered my PC a packet = interface with the properties of knowing how to recognize and route DNS = queries specially, and general IP connectivity. My PC accepted the = service offer implicitly by offering traffic to the data-plane = interface. The network could be performing associated auxiliary services = such as usage-based billing (think wireless roaming), so it’s more = than just a dumb pipe.

 

If this is not a legitimate example of = intent, it would be good to write the white paper in such a way that = clearly excludes such cases.

 

Use case 2: suppose I am a corporate IT = employee, and suppose that my intent is to have an E-Line between two of = my campi. I necessarily care about ports and protocols; talk about = intent being portable and protocol independent continues to confuse me = completely. How can I order an E-line without caring about such details? = [Nor is this intent portable.]

 

Obviously, an SDN controller is going to = expose whatever actions and elements of information are germane to the = service it offers, and if ports and protocols are germane to the = service, so be it.

 

The SDN architecture, being recursive, = models the north side of any controller as exposing an instance of an = information model, customized for the intended client/customer/app/user. = That being the case, how do we distinguish an NBI API that conveys = intent (service: same thing?) from one that does = not?

 

I have recently come to the view that = granularity is the criterion by which an intent or service invocation is = distinguished. Colloquially speaking, a service invocation is a single = invocation across the API: give me E-Line. Now of course this turns into = constraint negotiation, offer and acceptance, but what happens across = the API is effectively one transaction. In contrast, what we might agree = is *not* an intent or a service is the manipulation of a granular = information model, the explicit visibility of multiple objects, how they = are interrelated, their attributes, and the = like.

 

·         = Network as a single lump vs some = non-trivial topology.

 

·         = Chauffeur vs driving a car. Legitimate = reasons to choose one option or the other, but the level of granularity = is quite different. Shall we agree that driving is too granular to be = considered intent?

 

This idea of granularity and detailed = operations on the components (which of course may be complex entities = themselves, virtualized into simple-appearing lumps) seems to me to = capture the essence of what people are talking about when they say = intent or service. I am not comfortable with the way I am expressing it, = so if this is a step in a productive direction, or even if it’s = not, I welcome suggestions to clarify the = concept.

 

Dave

 

From:= = sdn [mailto:sdn-bounces@irtf.org] = On Behalf Of Susan Hares
Sent: Saturday, May 30, 2015 = 1:02 PM
To: sdn@irtf.org
Cc: = 'Zhoutianran'; 'Xiayinben'; ibnemo@ietf.org
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: (h= ttp://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

------=_NextPart_000_01F7_01D09C8E.0273D8A0-- From nobody Tue Jun 2 00:54:17 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8B11AD241 for ; Tue, 2 Jun 2015 00:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTVjZecV9ejQ for ; Tue, 2 Jun 2015 00:54:07 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 759EE1AD255 for ; Tue, 2 Jun 2015 00:54:06 -0700 (PDT) Received: from 172.24.2.119 (EHLO nkgeml401-hub.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CMG19125; Tue, 02 Jun 2015 15:53:46 +0800 (CST) Received: from NKGEML505-MBS.china.huawei.com ([169.254.2.71]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Tue, 2 Jun 2015 15:46:55 +0800 From: "Lifengkai (Fengkai)" To: Dave Hood , Susan Hares , "sdn@irtf.org" Thread-Topic: [Sdn] Defining a Common Model for intent Thread-Index: AdCbEy9UHkEQylvfQJyfdpRUZhhXPwBfgiUQAB27oPA= Date: Tue, 2 Jun 2015 07:46:55 +0000 Message-ID: <865C20BAAE8BBD4C89E7D6FE694F6B3B2D3CA540@nkgeml505-mbs.china.huawei.com> References: <00f301d09b13$79cc2410$6d646c30$@ndzh.com> <8D15A2BAF93E9C49AB037A0647E5FA643F8490D8@eusaamb105.ericsson.se> In-Reply-To: <8D15A2BAF93E9C49AB037A0647E5FA643F8490D8@eusaamb105.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.243] Content-Type: multipart/alternative; boundary="_000_865C20BAAE8BBD4C89E7D6FE694F6B3B2D3CA540nkgeml505mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Zhoutianran , Xiayinben , "ibnemo@ietf.org" Subject: Re: [Sdn] Defining a Common Model for intent X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 07:54:15 -0000 --_000_865C20BAAE8BBD4C89E7D6FE694F6B3B2D3CA540nkgeml505mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 detai= ls of ports/protocols into his/her intent descriptions, but those may not b= e in the intent context scope of a non-IT employee. Have a further consider= ation 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 fitt= ing the intent requirements of the network users with different roles. Any thoughts about this consideration? Best Regards, Fengkai From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of Dave Hood Sent: Tuesday, June 02, 2015 1:38 AM To: Susan Hares; sdn@irtf.org Cc: Zhoutianran; Xiayinben; ibnemo@ietf.org 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 l= ooking forward to making the concept more precise. When I click a link on a web page, I express an intent to invoke whatever t= hat link offers. Completely below the surface is a layer stack, on-demand s= ession establishment, DNS look-ups, server load balancers, and any number o= f other technological features that are of no interest to me. Why not use t= hat 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 a= nd receive an offer of several widgets, some new, some used, some with a ch= oice 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, hav= ing found nothing I liked better somewhere else. Now I accept one of the of= fered widgets and go through the checkout process. Do we agree that this is a fairly pure expression of intent as conceptualiz= ed 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 S= DN of one kind or another. I invoke my intent through a GUI onto software l= ocal 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 conc= erned, the client makes DNS queries and swaps opaque TCP packets over a for= warding path that may already exist, or may need to be learned and set up o= n demand. This is about right, because the session content may well be encr= ypted 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 subsequen= t session. Hmmm... what happened to our intent-based NBI? The SDN offered m= y PC a packet interface with the properties of knowing how to recognize and= route DNS queries specially, and general IP connectivity. My PC accepted t= he service offer implicitly by offering traffic to the data-plane interface= . The network could be performing associated auxiliary services such as usa= ge-based billing (think wireless roaming), so it's more than just a dumb pi= pe. If this is not a legitimate example of intent, it would be good to write th= e 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 inten= t is to have an E-Line between two of my campi. I necessarily care about po= rts and protocols; talk about intent being portable and protocol independen= t continues to confuse me completely. How can I order an E-line without car= ing about such details? [Nor is this intent portable.] Obviously, an SDN controller is going to expose whatever actions and elemen= ts of information are germane to the service it offers, and if ports and pr= otocols are germane to the service, so be it. The SDN architecture, being recursive, models the north side of any control= ler as exposing an instance of an information model, customized for the int= ended 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 no= t? 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 contras= t, what we might agree is *not* an intent or a service is the manipulation = of a granular information model, the explicit visibility of multiple object= s, 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 opti= on 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 o= f course may be complex entities themselves, virtualized into simple-appear= ing lumps) seems to me to capture the essence of what people are talking ab= out 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:sdn-bounces@irtf.org] On Behalf Of Susan Hares Sent: Saturday, May 30, 2015 1:02 PM To: sdn@irtf.org Cc: 'Zhoutianran'; 'Xiayinben'; ibnemo@ietf.org 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/msg0= 0646.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 req= uest that signals Intent from an application to a controller, it is importa= nt to define Intent, and provide a clear model of Intent. Also, in describ= ing real use-cases it is important that one uses the same definition and mo= del for Intent in each use case. In the current forums examining Intent (ODL NIC, ODL Nemo, OF NBI and Keyst= one, OPNFV Movie, OpenStack) there is a realization that Intent occurs at m= ultiple layers. The authors of draft-xia-ibnemo-icim have created a defini= tion 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 i= ncludes operations toward that result. 3) Operations conditions perform actions within/modified by constraint= s. We believe this defines clearly what others are calling "pure intent" (obje= cts + results) versus "constrained intent" (objects + operations + constrai= nts). 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 --_000_865C20BAAE8BBD4C89E7D6FE694F6B3B2D3CA540nkgeml505mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dave an= d all,

 = ;

Thanks for= proposing the two valuable intent use cases.

 = ;

For the us= e case 2, I agree that the IT employee needs to include the details of port= s/protocols into his/her intent descriptions, but those may not be in the intent context scope of a non-IT employee. Have a further co= nsideration 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 t= o be identified and distinguished, thus fitting the intent requirements of = the network users with different roles.

 = ;

Any thoughts about this con= sideration?

 

 

Best Regards,

Fengkai

 = ;

From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of Dave Hood
Sent: Tuesday, June 02, 2015 1:38 AM
To: Susan Hares; sdn@irtf.org
Cc: Zhoutianran; Xiayinben; ibnemo@ietf.org
Subject: Re: [Sdn] Defining a Common Model for intent

 

An ex= cerpt from an email I sent on the ONF NBI list, which may contain some usef= ul thoughts:

=  

I have always had trouble understanding what an int= ent 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 int= ent to invoke whatever that link offers. Completely below the surface is a layer stack, on-demand session establishment, DNS look-ups, s= erver load balancers, and any number of other technological features that a= re 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&= #8217;s Amazon. I search Amazon’s catalog and receive an offer of sev= eral widgets, some new, some used, some with a choice of colour or other pe= rtinent features. If I see nothing I like, I may open a new browser window and check out Best Buy or EBay (lots more hi= dden 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 t= he offered widgets and go through the checkout process.

 

Do we agree that this is a fairly pure expression o= f 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 th= ink we can call the PC an SDN controller. It’s more an active mediato= r, 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 se= t up on demand. This is about right, because the session content may well b= e encrypted end to end, and rightly.

 

To the SDN controller, my intent is satisfied by di= recting DNS queries to a known DNS server somewhere, and ensuring IP connectivity for the subsequent session. Hmmm… what happened to o= ur intent-based NBI? The SDN offered my PC a packet interface with the prop= erties of knowing how to recognize and route DNS queries specially, and gen= eral 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 dum= b pipe.

 

If this is not a legitimate example of intent, it w= ould 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, a= nd 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 wha= tever 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 n= orth side of any controller as exposing an instance of an information model, customized for the intended client/customer/app/user. That being th= e 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 i= s the criterion by which an intent or service invocation is distinguished. Colloquially speaking, a service invocation is a single inv= ocation across the API: give me E-Line. Now of course this turns into const= raint 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 th= e manipulation of a granular information model, the explicit visibility of = multiple objects, how they are interrelated, their attributes, and the like= .

 

·    &nbs= p;    Network as a single lump vs some non-trivial topology.=

 

·    &nbs= p;    Chauffeur vs driving a car. Legitimate reasons to choose one option or t= he other, but the level of granularity is quite different. Shall we agree that driving is too granular to be considered intent?<= /o:p>

 

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 essenc= e of what people are talking about when they say intent or service. I am no= t comfortable with the way I am expressing it, so if this is a step in a pr= oductive direction, or even if it’s not, I welcome suggestions to clarify the concept.

=  

Dave<= o:p>

=  

From: sdn [mailto:s= dn-bounces@irtf.org] On Behalf Of Susan Hares
Sent: Saturday, May 30, 2015 1:02 PM
To: sdn@irtf.org
Cc: 'Zhoutianran'; 'Xiayinben'; i= bnemo@ietf.org
Subject: [Sdn] Defining a Common Model for intent<= /p>

 

On this mail list, there has be= en a discussion of two types of information for Intent and Nemo: (http://= www.ietf.org/mail-archive/web/sdn/current/msg00646.html) :

 

1) &nbs= p;    What information is nee= ded to represent a service request,

2) &nbs= p;    How to represent and tr= ansport the information for a request.

 

In order to define what informa= tion is needed to represent a 1) service request that signals Intent from a= n application to a controller, it is important to define Intent, and provid= e a clear model of Intent.  Also, in describing real use-cases it is important that one uses the same definitio= n 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) th= ere is a realization that Intent occurs at multiple layers.  The autho= rs 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) involv= es an object with a result, and optionally includes operations toward that = result.

3)      Operations conditions p= erform actions within/modified by constraints.

 

We believe this defines clearly= what others are calling “pure intent” (objects + results) = versus “constrained intent” (objects + operations + con= straints).   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

--_000_865C20BAAE8BBD4C89E7D6FE694F6B3B2D3CA540nkgeml505mbschi_-- From nobody Tue Jun 2 06:26:26 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25531A890A for ; Tue, 2 Jun 2015 06:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJMTRLveSh_B for ; Tue, 2 Jun 2015 06:26:17 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC22A1A898A for ; Tue, 2 Jun 2015 06:26:16 -0700 (PDT) X-AuditID: c618062d-f79a96d000007fb1-b6-556d55a133cc Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 08.FA.32689.1A55D655; Tue, 2 Jun 2015 09:05:06 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0210.002; Tue, 2 Jun 2015 09:26:13 -0400 From: Dave Hood To: "Lifengkai (Fengkai)" , Susan Hares , "sdn@irtf.org" Thread-Topic: [Sdn] Defining a Common Model for intent Thread-Index: AdCbEy9UHkEQylvfQJyfdpRUZhhXPwBfgiUQAB27oPAAC6JcEA== Date: Tue, 2 Jun 2015 13:26:13 +0000 Message-ID: <8D15A2BAF93E9C49AB037A0647E5FA643F84AAA2@eusaamb105.ericsson.se> References: <00f301d09b13$79cc2410$6d646c30$@ndzh.com> <8D15A2BAF93E9C49AB037A0647E5FA643F8490D8@eusaamb105.ericsson.se> <865C20BAAE8BBD4C89E7D6FE694F6B3B2D3CA540@nkgeml505-mbs.china.huawei.com> In-Reply-To: <865C20BAAE8BBD4C89E7D6FE694F6B3B2D3CA540@nkgeml505-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_8D15A2BAF93E9C49AB037A0647E5FA643F84AAA2eusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyuXRPlO6i0NxQg0sPuS1abz5isti5/j6j xfkFz1ks/rx5xWLx4+ldVosJJxcwO7B5tBx5y+qxZMlPJo/JGw+zecx+fZ01gCWKyyYlNSez LLVI3y6BK+Pqn0ksBe+WMlUc37CetYFxZyNTFyMnh4SAicS5H3tYIGwxiQv31rN1MXJxCAkc ZZR4cfQgE4SzjFHi0+cbbCBVbAIaEk8uTQbrFhEokFhyaAE7iM0sUChx6HgTK4gtLGAqsWfH OhaIGjOJlRdXMHYxcgDZThKbL2WBmCwCKhItP0pBTF4BX4mWE5oQm44xSlzbNR2sk1MgTOLM 67dgNiPQbd9PrWGC2CQucevJfKj7BSSW7DnPDGGLSrx8/I8VwlaS+Ph7PjvIfGaBfIkZH3RA wrwCghInZz5hmcAoOgvJpFkIVbOQVEGU6Egs2P2JDcLWlli28DUzjH3mwGMmZPEFjOyrGDlK i1PLctONDDYxAuPxmASb7g7GPS8tDzEKcDAq8fAumJsTKsSaWFZcmXuIUZqDRUmc95thSKiQ QHpiSWp2ampBalF8UWlOavEhRiYOTqkGRtHn/jq7P3V435gQHqHdohoandVde+IEd8S2bbm7 586f2VK7Z0uH3/ynLO1zbnEt3BF8XMJ9XsXWaWdPvfMX/Xjpj+FzT86uVblVznmcjlm2lvuZ itWf1p+Nm2B1JsF/ZaueB4+6kNT3Bhk5DUf3d7cM/pgm/bCbvbS47aHvPcFlmpt/v5htosRS nJFoqMVcVJwIAOp1O0eoAgAA Archived-At: Cc: Zhoutianran , Xiayinben , "ibnemo@ietf.org" Subject: Re: [Sdn] Defining a Common Model for intent X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 13:26:24 -0000 --_000_8D15A2BAF93E9C49AB037A0647E5FA643F84AAA2eusaamb105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 o= f 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 ap= pears 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:lifengkai@huawei.com] Sent: Tuesday, June 02, 2015 12:47 AM To: Dave Hood; Susan Hares; sdn@irtf.org Cc: Zhoutianran; Xiayinben; ibnemo@ietf.org Subject: RE: [Sdn] Defining a Common Model for intent Hi Dave and all, Thanks for proposing the two valuable intent use cases. For the use case 2, I agree that the IT employee needs to include the detai= ls of ports/protocols into his/her intent descriptions, but those may not b= e in the intent context scope of a non-IT employee. Have a further consider= ation 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 fitt= ing the intent requirements of the network users with different roles. Any thoughts about this consideration? Best Regards, Fengkai From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of Dave Hood Sent: Tuesday, June 02, 2015 1:38 AM To: Susan Hares; sdn@irtf.org Cc: Zhoutianran; Xiayinben; ibnemo@ietf.org 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 l= ooking forward to making the concept more precise. When I click a link on a web page, I express an intent to invoke whatever t= hat link offers. Completely below the surface is a layer stack, on-demand s= ession establishment, DNS look-ups, server load balancers, and any number o= f other technological features that are of no interest to me. Why not use t= hat 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 a= nd receive an offer of several widgets, some new, some used, some with a ch= oice 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, hav= ing found nothing I liked better somewhere else. Now I accept one of the of= fered widgets and go through the checkout process. Do we agree that this is a fairly pure expression of intent as conceptualiz= ed 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 S= DN of one kind or another. I invoke my intent through a GUI onto software l= ocal 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 conc= erned, the client makes DNS queries and swaps opaque TCP packets over a for= warding path that may already exist, or may need to be learned and set up o= n demand. This is about right, because the session content may well be encr= ypted 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 subsequen= t session. Hmmm... what happened to our intent-based NBI? The SDN offered m= y PC a packet interface with the properties of knowing how to recognize and= route DNS queries specially, and general IP connectivity. My PC accepted t= he service offer implicitly by offering traffic to the data-plane interface= . The network could be performing associated auxiliary services such as usa= ge-based billing (think wireless roaming), so it's more than just a dumb pi= pe. If this is not a legitimate example of intent, it would be good to write th= e 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 inten= t is to have an E-Line between two of my campi. I necessarily care about po= rts and protocols; talk about intent being portable and protocol independen= t continues to confuse me completely. How can I order an E-line without car= ing about such details? [Nor is this intent portable.] Obviously, an SDN controller is going to expose whatever actions and elemen= ts of information are germane to the service it offers, and if ports and pr= otocols are germane to the service, so be it. The SDN architecture, being recursive, models the north side of any control= ler as exposing an instance of an information model, customized for the int= ended 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 no= t? 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 contras= t, what we might agree is *not* an intent or a service is the manipulation = of a granular information model, the explicit visibility of multiple object= s, 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 opti= on 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 o= f course may be complex entities themselves, virtualized into simple-appear= ing lumps) seems to me to capture the essence of what people are talking ab= out 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:sdn-bounces@irtf.org] On Behalf Of Susan Hares Sent: Saturday, May 30, 2015 1:02 PM To: sdn@irtf.org Cc: 'Zhoutianran'; 'Xiayinben'; ibnemo@ietf.org 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/msg0= 0646.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 req= uest that signals Intent from an application to a controller, it is importa= nt to define Intent, and provide a clear model of Intent. Also, in describ= ing real use-cases it is important that one uses the same definition and mo= del for Intent in each use case. In the current forums examining Intent (ODL NIC, ODL Nemo, OF NBI and Keyst= one, OPNFV Movie, OpenStack) there is a realization that Intent occurs at m= ultiple layers. The authors of draft-xia-ibnemo-icim have created a defini= tion 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 i= ncludes operations toward that result. 3) Operations conditions perform actions within/modified by constraint= s. We believe this defines clearly what others are calling "pure intent" (obje= cts + results) versus "constrained intent" (objects + operations + constrai= nts). 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 --_000_8D15A2BAF93E9C49AB037A0647E5FA643F84AAA2eusaamb105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree that the con= text 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 r= oot of my question from the beginning: how would we know what is *not* intent?

 

If I ask for some pa= rticular microscopically detailed configuration (a “how”), it&#= 8217;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 tel= l, we can say precisely what an intent is, and we can’t say what an i= ntent 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: Lifengka= i (Fengkai) [mailto:lifengkai@huawei.com]
Sent: Tuesday, June 02, 2015 12:47 AM
To: Dave Hood; Susan Hares; sdn@irtf.org
Cc: Zhoutianran; Xiayinben; ibnemo@ietf.org
Subject: RE: [Sdn] Defining a Common Model for intent

 

Any thoughts about this consideration?<= /o:p>

 

 

Best Regards,

Fengkai

From:<= /span> sdn [mailto:sdn-bounces@irtf.org] On Behalf Of Dave Hood
Sent: Tuesday, June 02, 2015 1:38 AM
To: Susan Hares; sdn@irtf.org Cc: Zhoutianran; Xiayinben; ibnem= o@ietf.org
Subject: Re: [Sdn] Defining a Common Model for intent

&nbs= p;

An excerpt from an email I sent on the ONF NBI list, which may conta= in some useful thoughts:

 

I have always had trouble understanding w= hat 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 expr= ess an intent to invoke whatever that link offers. Completely below the surface is a layer stack, on-demand session establishment, DNS l= ook-ups, server load balancers, and any number of other technological featu= res 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. S= uppose it’s Amazon. I search Amazon’s catalog and receive an of= fer of several widgets, some new, some used, some with a choice of colour o= r other pertinent features. If I see nothing I like, I may open a new browser window and check out Best Buy or EBay (lo= ts more hidden technology to make that happen!). Maybe I come back to the A= mazon page, having found nothing I liked better somewhere else. Now I accep= t one of the offered widgets and go through the checkout process.

 

Do we agree that this is a fairly pure ex= pression 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&#= 8217;t think we can call the PC an SDN controller. It’s more an activ= e mediator, a client to an SDN. As far as the network is concerned, the cli= ent makes DNS queries and swaps opaque TCP packets over a forwarding path that may already exist, or may need to be learned a= nd set up on demand. This is about right, because the session content may w= ell be encrypted end to end, and rightly.

 

To the SDN controller, my intent is satis= fied 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 speci= ally, and general IP connectivity. My PC accepted the service offer implicitly by offering traffic to the data-p= lane interface. The network could be performing associated auxiliary servic= es 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 in= tent, 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 e= mployee, 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 comp= letely. How can I order an E-line without caring about such details? [Nor i= s 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 se= rvice, so be it.

 

The SDN architecture, being recursive, mo= dels the north side of any controller as exposing an instance of an information model, customized for the intended client/customer/app/u= ser. That being the case, how do we distinguish an NBI API that conveys int= ent (service: same thing?) from one that does not?

 

I have recently come to the view that gra= nularity 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 co= nstraint 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 l= ike.

 

·         Network a= s a single lump vs some non-trivial topology.

 

·         Chauffeur= vs driving a car. Legitimate reasons to choose one option or the other, bu= t 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 ope= rations 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 inten= t or service. I am not comfortable with the way I am expressing it, so if t= his is a step in a productive direction, or even if it’s not, I welcome suggestions to clarify the concept.

 

Dave

 

From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of Susan Hares
Sent: Saturday, May 30, 2015 1:02 PM
To: sdn@irtf.org
Cc: 'Zhoutianran'; 'Xiayinben'; i= bnemo@ietf.org
Subject: [Sdn] Defining a Common Model for intent<= /p>

&nbs= p;

On this m= ail list, there has been a discussion of two types of information for Inten= t and Nemo: (http://www.ietf.org/mail-archive/web/sdn/current/msg00646.html= ) :

&nbs= p;

1)      What information is neede= d to represent a service request,

2)      How to represent and tran= sport the information for a request.

&nbs= p;

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 def= ine Intent, and provide a clear model of Intent.  Also, in describing real use-cases it is important that o= ne uses the same definition and model for Intent in each use case.  &n= bsp;

&nbs= p;

In the cu= rrent forums examining Intent (ODL NIC, ODL Nemo, OF NBI and Keystone, OPNF= V Movie, OpenStack) there is a realization that Intent occurs at multiple l= ayers.  The authors of draft-xia-ibnemo-icim have created a definition for intent and a unified model for defining inte= nt 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 re= sult.

3)      Operations conditions per= form actions within/modified by constraints.

&nbs= p;

We believ= e this defines clearly what others are calling “pure intent” (o= bjects + results) versus “constrained intent” (objects += ; operations + constraints).   The draft can be found at: &nb= sp; https://datatracker.ietf.org/doc/draft-xia-ibnemo-icim/ .   The authors are looking for feedback on the concepts in the = draft.   

&nbs= p;

Sue Hares=

--_000_8D15A2BAF93E9C49AB037A0647E5FA643F84AAA2eusaamb105erics_-- From nobody Tue Jun 2 09:08:10 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB25C1B2DB5; Tue, 2 Jun 2015 09:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNZ5xVqpFsX3; Tue, 2 Jun 2015 09:08:04 -0700 (PDT) Received: from p01c11o143.mxlogic.net (p01c11o143.mxlogic.net [208.65.144.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEA1F1B2E88; Tue, 2 Jun 2015 09:06:39 -0700 (PDT) Received: from unknown [76.164.174.81] by p01c11o143.mxlogic.net(mxl_mta-8.4.0-1) over TLS secured channel with SMTP id f84dd655.0.3003020.00-378.7967775.p01c11o143.mxlogic.net (envelope-from ); Tue, 02 Jun 2015 10:06:40 -0600 (MDT) X-MXL-Hash: 556dd49024e3b17a-360464faf32dd91db227142674d4e7e91de45e53 Received: from ex-mb3.corp.adtran.com ([fe80::60aa:f95:ad49:a0f1]) by ex-hc1.corp.adtran.com ([fe80::a43f:7ea6:7688:37b%13]) with mapi id 14.03.0224.002; Tue, 2 Jun 2015 11:06:11 -0500 From: STUART VENTERS To: "sdn@irtf.org" Thread-Topic: [Sdn] Defining a Common Model for intent Thread-Index: AdCbEy9UHkEQylvfQJyfdpRUZhhXPwBfgiUQAB27oPAAC6JcEAAEMVSg Date: Tue, 2 Jun 2015 16:06:11 +0000 Message-ID: <1220E2C537595D439C5D026E83751866C42AC2FF@ex-mb3.corp.adtran.com> References: <00f301d09b13$79cc2410$6d646c30$@ndzh.com> <8D15A2BAF93E9C49AB037A0647E5FA643F8490D8@eusaamb105.ericsson.se> <865C20BAAE8BBD4C89E7D6FE694F6B3B2D3CA540@nkgeml505-mbs.china.huawei.com> <8D15A2BAF93E9C49AB037A0647E5FA643F84AAA2@eusaamb105.ericsson.se> In-Reply-To: <8D15A2BAF93E9C49AB037A0647E5FA643F84AAA2@eusaamb105.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.118.25] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=efEpft0H c=1 sm=1 tr=0 a=0XgpNN2/4a34ymu16SVwsQ==] X-AnalysisOut: [:117 a=0XgpNN2/4a34ymu16SVwsQ==:17 a=0eaKXOXVzoQA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=xqWC_Br6kY4A:10 a=eJNrpio] X-AnalysisOut: [GAAAA:8 a=YlVTAMxIAAAA:8 a=XAFQembCKUMA:10 a=YlDpyLmHAAAA:] X-AnalysisOut: [8 a=48vgC7mUAAAA:8 a=i0EeH86SAAAA:8 a=bob5MaRvnGJjDM6x4s4A] X-AnalysisOut: [:9 a=lktqcNwG9F38ZHIp:21 a=Y9JoR-YIR5eRMVoo:21 a=wPNLvfGTe] X-AnalysisOut: [EIA:10 a=OHWWstZQRzQA:10] X-Spam: [F=0.5500000000; CM=0.500; MH=0.550(2015060215); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.81] Archived-At: Cc: 'Dave Hood' , "ibnemo@ietf.org" , "Lifengkai \(Fengkai\)" , Zhoutianran , Xiayinben , Susan Hares Subject: Re: [Sdn] Defining a Common Model for intent X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 16:08:08 -0000 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' ap= pears 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 recogn= ize. 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 pat= h 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 glob= al 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 re= finement. That said, the data model for intent might/should be different at each leve= l. Since each level is processing the same request at different levels of deta= il, it might be similar at each level. Perhaps the data model starts simple on top and gathers more and more detai= l as it gets lower ? Maybe like a tree with the root at the top and leaves at the forwarding eng= ines, except distributed. Perhaps a simple starting point near the top is a combination of entities, = endpoints, and connections. Regards, Stuart Venters From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of Dave Hood Sent: Tuesday, June 02, 2015 8:26 AM To: Lifengkai (Fengkai); Susan Hares; sdn@irtf.org Cc: Zhoutianran; Xiayinben; ibnemo@ietf.org 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 o= f 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.=20 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 ap= pears 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:lifengkai@huawei.com]=20 Sent: Tuesday, June 02, 2015 12:47 AM To: Dave Hood; Susan Hares; sdn@irtf.org Cc: Zhoutianran; Xiayinben; ibnemo@ietf.org Subject: RE: [Sdn] Defining a Common Model for intent Hi Dave and all, Thanks for proposing the two valuable intent use cases. For the use case 2, I agree that the IT employee needs to include the detai= ls of ports/protocols into his/her intent descriptions, but those may not b= e in the intent context scope of a non-IT employee. Have a further consider= ation 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 fitt= ing the intent requirements of the network users with different roles. Any thoughts about this consideration? Best Regards, Fengkai From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of Dave Hood Sent: Tuesday, June 02, 2015 1:38 AM To: Susan Hares; sdn@irtf.org Cc: Zhoutianran; Xiayinben; ibnemo@ietf.org 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 l= ooking forward to making the concept more precise. When I click a link on a web page, I express an intent to invoke whatever t= hat link offers. Completely below the surface is a layer stack, on-demand s= ession establishment, DNS look-ups, server load balancers, and any number o= f other technological features that are of no interest to me. Why not use t= hat 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 a= nd receive an offer of several widgets, some new, some used, some with a ch= oice 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, hav= ing found nothing I liked better somewhere else. Now I accept one of the of= fered widgets and go through the checkout process.=20 Do we agree that this is a fairly pure expression of intent as conceptualiz= ed 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 S= DN of one kind or another. I invoke my intent through a GUI onto software l= ocal 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 conc= erned, the client makes DNS queries and swaps opaque TCP packets over a for= warding path that may already exist, or may need to be learned and set up o= n demand. This is about right, because the session content may well be encr= ypted 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 subsequen= t 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 r= oute 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 th= e 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 inten= t is to have an E-Line between two of my campi. I necessarily care about po= rts and protocols; talk about intent being portable and protocol independen= t continues to confuse me completely. How can I order an E-line without car= ing about such details? [Nor is this intent portable.] Obviously, an SDN controller is going to expose whatever actions and elemen= ts of information are germane to the service it offers, and if ports and pr= otocols are germane to the service, so be it. The SDN architecture, being recursive, models the north side of any control= ler as exposing an instance of an information model, customized for the int= ended 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 no= t? 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 contras= t, what we might agree is *not* an intent or a service is the manipulation = of a granular information model, the explicit visibility of multiple object= s, how they are interrelated, their attributes, and the like. .=A0=A0=A0=A0=A0=A0=A0=A0 Network as a single lump vs some non-trivial topo= logy. .=A0=A0=A0=A0=A0=A0=A0=A0 Chauffeur vs driving a car. Legitimate reasons to= choose one option or the other, but the level of granularity is quite diff= erent. Shall we agree that driving is too granular to be considered intent? This idea of granularity and detailed operations on the components (which o= f course may be complex entities themselves, virtualized into simple-appear= ing lumps) seems to me to capture the essence of what people are talking ab= out 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:sdn-bounces@irtf.org] On Behalf Of Susan Hares Sent: Saturday, May 30, 2015 1:02 PM To: sdn@irtf.org Cc: 'Zhoutianran'; 'Xiayinben'; ibnemo@ietf.org 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/msg0= 0646.html) : 1)=A0=A0=A0=A0=A0 What information is needed to represent a service request= ,=20 2)=A0=A0=A0=A0=A0 How to represent and transport the information for a requ= est. In order to define what information is needed to represent a 1) service req= uest that signals Intent from an application to a controller, it is importa= nt to define Intent, and provide a clear model of Intent.=A0 Also, in descr= ibing real use-cases it is important that one uses the same definition and = model for Intent in each use case.=A0 =A0 In the current forums examining Intent (ODL NIC, ODL Nemo, OF NBI and Keyst= one, OPNFV Movie, OpenStack) there is a realization that Intent occurs at m= ultiple layers.=A0 The authors of draft-xia-ibnemo-icim have created a defi= nition for intent and a unified model for defining intent which can handle = 1 or multiple layers. The model suggest that: 1)=A0=A0=A0=A0=A0 A user has a intent that is expressed in a context. 2)=A0=A0=A0=A0=A0 Intent (usually) involves an object with a result, and op= tionally includes operations toward that result.=20 3)=A0=A0=A0=A0=A0 Operations conditions perform actions within/modified by = constraints.=20 We believe this defines clearly what others are calling "pure intent" (obje= cts + results) versus "constrained intent" (objects + operations + constrai= nts).=A0 =A0The draft can be found at: =A0=A0https://datatracker.ietf.org/d= oc/draft-xia-ibnemo-icim/ .=A0 =A0The authors are looking for feedback on t= he concepts in the draft.=A0 =A0 Sue Hares=20 From nobody Tue Jun 2 16:09:07 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC3461B31EC for ; Tue, 2 Jun 2015 16:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYW8NvITVXYp for ; Tue, 2 Jun 2015 16:08:59 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id DCB231B31EA for ; Tue, 2 Jun 2015 16:08:58 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.80.157; From: "Susan Hares" To: "'Lifengkai \(Fengkai\)'" , "'Dave Hood'" , References: <00f301d09b13$79cc2410$6d646c30$@ndzh.com> <8D15A2BAF93E9C49AB037A0647E5FA643F8490D8@eusaamb105.ericsson.se> <865C20BAAE8BBD4C89E7D6FE694F6B3B2D3CA540@nkgeml505-mbs.china.huawei.com> In-Reply-To: <865C20BAAE8BBD4C89E7D6FE694F6B3B2D3CA540@nkgeml505-mbs.china.huawei.com> Date: Tue, 2 Jun 2015 19:09:02 -0400 Message-ID: <017101d09d89$1d9ca570$58d5f050$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0172_01D09D67.96911FF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGjwAWNbhwtlPLyYWaj2K7LZAyOCALTOOmfAi4Fw8Sdy4d+AA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: ibnemo@ietf.org Subject: Re: [Sdn] [Ibnemo] Defining a Common Model for intent X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 23:09:04 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0172_01D09D67.96911FF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Fengkai: =20 In this you are talking about the difference between the IT and Non-IT person=92s context of an intent within a role. I believe your examples = show that=20 =20 User =E0 intent =E0 context=20 =20 is very important as https://datatracker.ietf.org/doc/draft-xia-ibnemo-icim/ states. I am = still struggling to understand how the =93fitting=94 works. Can you provide additional examples?=20 =20 Sue=20 =20 From: Ibnemo [mailto:ibnemo-bounces@ietf.org] On Behalf Of Lifengkai (Fengkai) Sent: Tuesday, June 02, 2015 3:47 AM To: Dave Hood; Susan Hares; sdn@irtf.org Cc: ibnemo@ietf.org Subject: Re: [Ibnemo] [Sdn] Defining a Common Model for intent =20 Hi Dave and all, =20 Thanks for proposing the two valuable intent use cases. =20 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. =20 Any thoughts about this consideration? =20 =20 Best Regards, Fengkai =20 From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of Dave Hood Sent: Tuesday, June 02, 2015 1:38 AM To: Susan Hares; sdn@irtf.org Cc: Zhoutianran; Xiayinben; ibnemo@ietf.org Subject: Re: [Sdn] Defining a Common Model for intent =20 An excerpt from an email I sent on the ONF NBI list, which may contain = some useful thoughts: =20 I have always had trouble understanding what an intent really is, so I = am looking forward to making the concept more precise. =20 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? =20 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=92s Amazon. I search Amazon=92s = 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.=20 =20 Do we agree that this is a fairly pure expression of intent as conceptualized in the paper? (If not, let=92s talk about making a Skype = call.) =20 Ok, that=92s my intent as an internet user. Let=92s 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=92t think we can call the PC an SDN = controller. It=92s 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. =20 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=85 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=92s more than just a = dumb pipe. =20 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. =20 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.] =20 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. =20 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? =20 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. =20 =B7 Network as a single lump vs some non-trivial topology. =20 =B7 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? =20 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=92s not, I welcome suggestions to clarify the concept. =20 Dave =20 From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of Susan Hares Sent: Saturday, May 30, 2015 1:02 PM To: sdn@irtf.org Cc: 'Zhoutianran'; 'Xiayinben'; ibnemo@ietf.org Subject: [Sdn] Defining a Common Model for intent =20 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) : =20 1) What information is needed to represent a service request,=20 2) How to represent and transport the information for a request. =20 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. =20 =20 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.=20 3) Operations conditions perform actions within/modified by constraints.=20 =20 We believe this defines clearly what others are calling =93pure = intent=94 (objects + results) versus =93constrained intent=94 (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. =20 =20 Sue Hares=20 ------=_NextPart_000_0172_01D09D67.96911FF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Fengkai:

 

In this you are talking = about the difference between the IT and Non-IT person’s context of = an intent within a role.=A0 I believe your examples show that =

 

User =E0 intent =E0 context

 

is very important as = =A0https://= datatracker.ietf.org/doc/draft-xia-ibnemo-icim/ states.=A0=A0 I am = still struggling to understand how the “fitting” works. = =A0Can you provide additional examples?

 

Sue =

 

From:= = Ibnemo [mailto:ibnemo-bounces@ietf.org] On Behalf Of Lifengkai = (Fengkai)
Sent: Tuesday, June 02, 2015 3:47 AM
To: = Dave Hood; Susan Hares; sdn@irtf.org
Cc: = ibnemo@ietf.org
Subject: Re: [Ibnemo] [Sdn] Defining a Common = Model for intent

 

Hi Dave and all,

 

Thanks for proposing the two valuable = intent use cases.

 

For the use case 2, I agree that the IT = employee needs to include the details of ports/protocols into his/her = intent descriptions, but those may not be in the intent context scope of = a non-IT employee. Have a further consideration with this, different = users of the network have their own intent in a specific domain. Then = the roles/actors of network users, such as end users, application = developers, tenant IT/network administrators, operator network = administrators, are valuable to be identified and distinguished, thus = fitting the intent requirements of the network users with different = roles.

 

Any thoughts about this = consideration?

 

 

Best Regards,

Fengkai

 

From: sdn [mailto:sdn-bounces@irtf.org] = On Behalf Of Dave Hood
Sent: Tuesday, June 02, 2015 = 1:38 AM
To: Susan Hares; sdn@irtf.org
Cc: Zhoutianran; = Xiayinben; ibnemo@ietf.org
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.

 

=B7  &nbs= p;      Network as a = single lump vs some non-trivial topology.

 

=B7  &nbs= p;      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<= /span>

 

From: sdn [mailto:sdn-bounces@irtf.org] = On Behalf Of Susan Hares
Sent: Saturday, May 30, 2015 = 1:02 PM
To: sdn@irtf.org
Cc: = 'Zhoutianran'; 'Xiayinben'; ibnemo@ietf.org
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: (h= ttp://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 =

------=_NextPart_000_0172_01D09D67.96911FF0-- From nobody Tue Jun 2 16:22:44 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE7F31A1A30 for ; Tue, 2 Jun 2015 16:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRsA2WWTx-xL for ; Tue, 2 Jun 2015 16:22:36 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6F37A1A1A16 for ; Tue, 2 Jun 2015 16:22:36 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.80.157; From: "Susan Hares" To: "'Dave Hood'" , "'Lifengkai \(Fengkai\)'" , References: <00f301d09b13$79cc2410$6d646c30$@ndzh.com> <8D15A2BAF93E9C49AB037A0647E5FA643F8490D8@eusaamb105.ericsson.se> <865C20BAAE8BBD4C89E7D6FE694F6B3B2D3CA540@nkgeml505-mbs.china.huawei.com> <8D15A2BAF93E9C49AB037A0647E5FA643F84AAA2@eusaamb105.ericsson.se> In-Reply-To: <8D15A2BAF93E9C49AB037A0647E5FA643F84AAA2@eusaamb105.ericsson.se> Date: Tue, 2 Jun 2015 19:22:34 -0400 Message-ID: <01ac01d09d8b$01ff54f0$05fdfed0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01AD_01D09D69.7AF15E70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGjwAWNbhwtlPLyYWaj2K7LZAyOCALTOOmfAi4Fw8QBCozw253DNMkA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Zhoutianran' , 'Xiayinben' , ibnemo@ietf.org Subject: Re: [Sdn] Defining a Common Model for intent X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 23:22:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01AD_01D09D69.7AF15E70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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:dave.hood@ericsson.com] Sent: Tuesday, June 02, 2015 9:26 AM To: Lifengkai (Fengkai); Susan Hares; sdn@irtf.org Cc: Zhoutianran; Xiayinben; ibnemo@ietf.org 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 From: Lifengkai (Fengkai) [mailto:lifengkai@huawei.com] Sent: Tuesday, June 02, 2015 12:47 AM To: Dave Hood; Susan Hares; sdn@irtf.org Cc: Zhoutianran; Xiayinben; ibnemo@ietf.org Subject: RE: [Sdn] Defining a Common Model for intent Hi Dave and all, Thanks for proposing the two valuable intent use cases. For the use case 2, I agree that the IT employee needs to include the details of ports/protocols into his/her intent descriptions, but those may not be in the intent context scope of a non-IT employee. Have a further consideration with this, different users of the network have their own intent in a specific domain. Then the roles/actors of network users, such as end users, application developers, tenant IT/network administrators, operator network administrators, are valuable to be identified and distinguished, thus fitting the intent requirements of the network users with different roles. Any thoughts about this consideration? Best Regards, Fengkai From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of Dave Hood Sent: Tuesday, June 02, 2015 1:38 AM To: Susan Hares; sdn@irtf.org Cc: Zhoutianran; Xiayinben; ibnemo@ietf.org Subject: Re: [Sdn] Defining a Common Model for intent An excerpt from an email I sent on the ONF NBI list, which may contain some useful thoughts: I have always had trouble understanding what an intent really is, so I am looking forward to making the concept more precise. When I click a link on a web page, I express an intent to invoke whatever that link offers. Completely below the surface is a layer stack, on-demand session establishment, DNS look-ups, server load balancers, and any number of other technological features that are of no interest to me. Why not use that as an example of intent? Better yet, we talk about negotiation and selection. Suppose I want to buy a widget. I probably already have some idea whether I want to go to Amazon or EBay or somewhere else. Suppose it's Amazon. I search Amazon's catalog and receive an offer of several widgets, some new, some used, some with a choice of colour or other pertinent features. If I see nothing I like, I may open a new browser window and check out Best Buy or EBay (lots more hidden technology to make that happen!). Maybe I come back to the Amazon page, having found nothing I liked better somewhere else. Now I accept one of the offered widgets and go through the checkout process. Do we agree that this is a fairly pure expression of intent as conceptualized in the paper? (If not, let's talk about making a Skype call.) Ok, that's my intent as an internet user. Let's assume the network is all SDN of one kind or another. I invoke my intent through a GUI onto software local to my PC, but I don't think we can call the PC an SDN controller. It's more an active mediator, a client to an SDN. As far as the network is concerned, the client makes DNS queries and swaps opaque TCP packets over a forwarding path that may already exist, or may need to be learned and set up on demand. This is about right, because the session content may well be encrypted end to end, and rightly. To the SDN controller, my intent is satisfied by directing DNS queries to a known DNS server somewhere, and ensuring IP connectivity for the subsequent session. Hmmm. what happened to our intent-based NBI? The SDN offered my PC a packet interface with the properties of knowing how to recognize and route DNS queries specially, and general IP connectivity. My PC accepted the service offer implicitly by offering traffic to the data-plane interface. The network could be performing associated auxiliary services such as usage-based billing (think wireless roaming), so it's more than just a dumb pipe. If this is not a legitimate example of intent, it would be good to write the white paper in such a way that clearly excludes such cases. Use case 2: suppose I am a corporate IT employee, and suppose that my intent is to have an E-Line between two of my campi. I necessarily care about ports and protocols; talk about intent being portable and protocol independent continues to confuse me completely. How can I order an E-line without caring about such details? [Nor is this intent portable.] Obviously, an SDN controller is going to expose whatever actions and elements of information are germane to the service it offers, and if ports and protocols are germane to the service, so be it. The SDN architecture, being recursive, models the north side of any controller as exposing an instance of an information model, customized for the intended client/customer/app/user. That being the case, how do we distinguish an NBI API that conveys intent (service: same thing?) from one that does not? I have recently come to the view that granularity is the criterion by which an intent or service invocation is distinguished. Colloquially speaking, a service invocation is a single invocation across the API: give me E-Line. Now of course this turns into constraint negotiation, offer and acceptance, but what happens across the API is effectively one transaction. In contrast, what we might agree is *not* an intent or a service is the manipulation of a granular information model, the explicit visibility of multiple objects, how they are interrelated, their attributes, and the like. . Network as a single lump vs some non-trivial topology. . Chauffeur vs driving a car. Legitimate reasons to choose one option or the other, but the level of granularity is quite different. Shall we agree that driving is too granular to be considered intent? This idea of granularity and detailed operations on the components (which of course may be complex entities themselves, virtualized into simple-appearing lumps) seems to me to capture the essence of what people are talking about when they say intent or service. I am not comfortable with the way I am expressing it, so if this is a step in a productive direction, or even if it's not, I welcome suggestions to clarify the concept. Dave From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of Susan Hares Sent: Saturday, May 30, 2015 1:02 PM To: sdn@irtf.org Cc: 'Zhoutianran'; 'Xiayinben'; ibnemo@ietf.org 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 ------=_NextPart_000_01AD_01D09D69.7AF15E70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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:dave.hood@ericsson.com]
Sent: Tuesday, June = 02, 2015 9:26 AM
To: Lifengkai (Fengkai); Susan Hares; = sdn@irtf.org
Cc: Zhoutianran; Xiayinben; = ibnemo@ietf.org
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

 

From:= = Lifengkai (Fengkai) [mailto:lifengkai@huawei.com] =
Sent: Tuesday, June 02, 2015 12:47 AM
To: Dave = Hood; Susan Hares; sdn@irtf.org
Cc: Zhoutianran; = Xiayinben; ibnemo@ietf.org
Subject: = RE: [Sdn] Defining a Common Model for = intent

 

Hi Dave and all,

 

Thanks for proposing the two valuable = intent use cases.

 

For the use case 2, I agree that the IT = employee needs to include the details of ports/protocols into his/her = intent descriptions, but those may not be in the intent context scope of = a non-IT employee. Have a further consideration with this, different = users of the network have their own intent in a specific domain. Then = the roles/actors of network users, such as end users, application = developers, tenant IT/network administrators, operator network = administrators, are valuable to be identified and distinguished, thus = fitting the intent requirements of the network users with different = roles.

 

Any thoughts about this = consideration?

 

 

Best Regards,

Fengkai

 

From: sdn [mailto:sdn-bounces@irtf.org] = On Behalf Of Dave Hood
Sent: Tuesday, June 02, 2015 = 1:38 AM
To: Susan Hares; sdn@irtf.org
Cc: Zhoutianran; = Xiayinben; ibnemo@ietf.org
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.

 

·  &nbs= p;      Network as a = single lump vs some non-trivial topology.

 

·  &nbs= p;      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<= /span>

 

From: sdn [mailto:sdn-bounces@irtf.org] = On Behalf Of Susan Hares
Sent: Saturday, May 30, 2015 = 1:02 PM
To: sdn@irtf.org
Cc: = 'Zhoutianran'; 'Xiayinben'; ibnemo@ietf.org
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: (h= ttp://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 =

------=_NextPart_000_01AD_01D09D69.7AF15E70-- From nobody Tue Jun 2 16:35:10 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543631B3208 for ; Tue, 2 Jun 2015 16:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.055 X-Spam-Level: X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hg_sSX0gF-w for ; Tue, 2 Jun 2015 16:35:06 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id C89CC1B3219 for ; Tue, 2 Jun 2015 16:35:04 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.80.157; From: "Susan Hares" To: "'STUART VENTERS'" , References: <00f301d09b13$79cc2410$6d646c30$@ndzh.com> <8D15A2BAF93E9C49AB037A0647E5FA643F8490D8@eusaamb105.ericsson.se> <865C20BAAE8BBD4C89E7D6FE694F6B3B2D3CA540@nkgeml505-mbs.china.huawei.com> <8D15A2BAF93E9C49AB037A0647E5FA643F84AAA2@eusaamb105.ericsson.se> <1220E2C537595D439C5D026E83751866C42AC2FF@ex-mb3.corp.adtran.com> In-Reply-To: <1220E2C537595D439C5D026E83751866C42AC2FF@ex-mb3.corp.adtran.com> Date: Tue, 2 Jun 2015 19:34:58 -0400 Message-ID: <01c601d09d8c$bd5f3520$381d9f60$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGjwAWNbhwtlPLyYWaj2K7LZAyOCALTOOmfAi4Fw8QBCozw2wFJpHEenbjr/5A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Zhoutianran' , 'Xiayinben' , 'Dave Hood' , "'Lifengkai \(Fengkai\)'" , ibnemo@ietf.org Subject: Re: [Sdn] Defining a Common Model for intent X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 23:35:09 -0000 Stuart:=20 In some ways, the policy continuum (Davy, Jenning, Strassner) suggest = the layer of models (as ISO did) of business, system, administrator, = device, and instance.=20 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.=20 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. =20 This is a fascinating part of the discussion - can you add more details = to your comments?=20 Sue=20 -----Original Message----- From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of STUART VENTERS Sent: Tuesday, June 02, 2015 12:06 PM To: sdn@irtf.org Cc: 'Dave Hood'; ibnemo@ietf.org; 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. 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 From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of Dave Hood Sent: Tuesday, June 02, 2015 8:26 AM To: Lifengkai (Fengkai); Susan Hares; sdn@irtf.org Cc: Zhoutianran; Xiayinben; ibnemo@ietf.org 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.=20 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:lifengkai@huawei.com] Sent: Tuesday, June 02, 2015 12:47 AM To: Dave Hood; Susan Hares; sdn@irtf.org Cc: Zhoutianran; Xiayinben; ibnemo@ietf.org Subject: RE: [Sdn] Defining a Common Model for intent Hi Dave and all, Thanks for proposing the two valuable intent use cases. For the use case 2, I agree that the IT employee needs to include the details of ports/protocols into his/her intent descriptions, but those = may not be in the intent context scope of a non-IT employee. Have a further consideration with this, different users of the network have their own intent in a specific domain. Then the roles/actors of network users, = such as end users, application developers, tenant IT/network administrators, operator network administrators, are valuable to be identified and distinguished, thus fitting the intent requirements of the network users with different roles. Any thoughts about this consideration? Best Regards, Fengkai From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of Dave Hood Sent: Tuesday, June 02, 2015 1:38 AM To: Susan Hares; sdn@irtf.org Cc: Zhoutianran; Xiayinben; ibnemo@ietf.org 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.=20 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. .=A0=A0=A0=A0=A0=A0=A0=A0 Network as a single lump vs some non-trivial = topology. .=A0=A0=A0=A0=A0=A0=A0=A0 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:sdn-bounces@irtf.org] On Behalf Of Susan Hares Sent: Saturday, May 30, 2015 1:02 PM To: sdn@irtf.org Cc: 'Zhoutianran'; 'Xiayinben'; ibnemo@ietf.org 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)=A0=A0=A0=A0=A0 What information is needed to represent a service = request, 2)=A0=A0=A0=A0=A0 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.=A0 = Also, in describing real use-cases it is important that one uses the same = definition and model for Intent in each use case.=A0 =A0 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.=A0 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)=A0=A0=A0=A0=A0 A user has a intent that is expressed in a context. 2)=A0=A0=A0=A0=A0 Intent (usually) involves an object with a result, and = optionally includes operations toward that result.=20 3)=A0=A0=A0=A0=A0 Operations conditions perform actions within/modified = by constraints.=20 We believe this defines clearly what others are calling "pure intent" (objects + results) versus "constrained intent" (objects + operations + constraints).=A0 =A0The draft can be found at: =A0=A0https://datatracker.ietf.org/doc/draft-xia-ibnemo-icim/ .=A0 = =A0The authors are looking for feedback on the concepts in the draft.=A0 =A0 Sue Hares=20 _______________________________________________ sdn mailing list sdn@irtf.org https://www.irtf.org/mailman/listinfo/sdn From nobody Tue Jun 2 23:34:56 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83BA1B35A7 for ; Tue, 2 Jun 2015 23:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eH1_9_V9XaH9 for ; Tue, 2 Jun 2015 23:34:51 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9A5D1B35A6 for ; Tue, 2 Jun 2015 23:34:50 -0700 (PDT) Received: from 172.24.2.119 (EHLO nkgeml404-hub.china.huawei.com) ([172.24.2.119]) by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued) with ESMTP id BGY32806; Wed, 03 Jun 2015 14:34:35 +0800 (CST) Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.152]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Wed, 3 Jun 2015 14:29:45 +0800 From: Zhoutianran To: Dave Hood , STUART VENTERS , "Natale, Bob" Thread-Topic: role based intent Thread-Index: AdCdxq4VFvGDpUDvRK6YJXpiQnECmw== Date: Wed, 3 Jun 2015 06:29:45 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.21] Content-Type: multipart/related; boundary="_004_BBA82579FD347748BEADC4C445EA0F2166BBFAC2nkgeml512mbxchi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.556E9FFD.0059, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.152, so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ab54cc4dbcc8ef1d067c6aa0908c6f2e Archived-At: Cc: "sdn@irtf.org" , "ibnemo@ietf.org" Subject: [Sdn] role based intent X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 06:34:53 -0000 --_004_BBA82579FD347748BEADC4C445EA0F2166BBFAC2nkgeml512mbxchi_ Content-Type: multipart/alternative; boundary="_000_BBA82579FD347748BEADC4C445EA0F2166BBFAC2nkgeml512mbxchi_" --_000_BBA82579FD347748BEADC4C445EA0F2166BBFAC2nkgeml512mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dave, Stuart, Bob and all, I found many problems raised in the mailing list are coursed by the layered= intent thinking. Maybe we are tainted by the ISO model:-) For the layered intent, intent is a spectrum, very abstract at the top laye= r, more network specific and less abstract when the layer goes down. The pr= oblem is that the boundary of intent and non intent is vague. Or there is n= o boundary between this two, since one's what may be another one's how. And= consequently, it looks like everything is intent and no clear intent defin= ition. The role based intent will provide only one intent layer. That is always th= e top layer abstraction for each role, as shown in the following figure. Th= e functions can be layered as the implementation of the intent layer. [cid:image003.jpg@01D09E09.BC337E90] With the role based intent, although the end user's intent is much abstract= ed then the network administrator's intent, they are not related each other= . I.e., the end user will not use the administrator's intent. And the admin= will not provide additional services/interfaces to the end user. The essential of layering is that the lower layer will provide interface to= the higher layer. In order to fit up layer requirements, the lower layer w= ill provide adequate interfaces/capabilities. That also means too much info= rmation for a dedicated up layer user/app. For role based intent, we can firstly indentify various roles (no need to b= e complete, but those with attention), and then figure out the intent of ea= ch role. In this way, intent can be clear defined. That will also keep the = intent of each role to a small set on what they really cares about, without= expending to support other one's intent. Best Regards, Terence --_000_BBA82579FD347748BEADC4C445EA0F2166BBFAC2nkgeml512mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dave, Stuart, Bob and all= ,

 

I found many problems raised= in the mailing list are coursed by the layered intent thinking. Maybe we a= re tainted by the ISO model:-)

 

For the layered intent, inte= nt is a spectrum, very abstract at the top layer, more network specific and= less abstract when the layer goes down. The problem is that the boundary o= f intent and non intent is vague. Or there is no boundary between this two, since one's what may be another one= 's how. And consequently, it looks like everything is intent and no clear i= ntent definition.

 

The role based intent will p= rovide only one intent layer. That is always the top layer abstra= ction for each role, as shown in the following figure. The function= s can be layered as the implementation of the intent layer.

With the role based intent, = although the end user's intent is much abstracted then the network administ= rator's intent, they are not related each other. I.e., the end user will no= t use the administrator's intent. And the admin will not provide additional services/interfaces to the end user.=

 

The essential of layering is= that the lower layer will provide interface to the higher layer. In order = to fit up layer requirements, the lower layer will provide adequate interfa= ces/capabilities. That also means too much information for a dedicated up layer user/app.

 

For role based intent, we ca= n firstly indentify various roles (no need to be complete, but those with a= ttention), and then figure out the intent of each role. In this way, intent= can be clear defined. That will also keep the intent of each role to a small set on what they really cares abou= t, without expending to support other one’s intent.=

 

 

Best Regards,

Terence

 

 

--_000_BBA82579FD347748BEADC4C445EA0F2166BBFAC2nkgeml512mbxchi_-- --_004_BBA82579FD347748BEADC4C445EA0F2166BBFAC2nkgeml512mbxchi_ Content-Type: image/jpeg; name="image003.jpg" Content-Description: image003.jpg Content-Disposition: inline; filename="image003.jpg"; size=9164; creation-date="Wed, 03 Jun 2015 06:29:45 GMT"; modification-date="Wed, 03 Jun 2015 06:29:45 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCACPAUoDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2aiii gDK1OCO61bT4J13xFZSUJOCQFwf1NTf2Hpn/AD5x/rTbv/kO6d/uTfyWtGgCh/Yemf8APnH+tH9h 6Z/z5x/rUfiLU5tH0K5v7eFJpYgu1HbAYlgOT261h3viXXLH7aWt9OcaTEkl8N7qZd2TiLPT5R1b qeOKAOg/sPTP+fOP9aP7D0z/AJ84/wBa5e48RXuky6ilrBJd3F1qxhhVlaQRgQI5+UcnoeBjqTVm 8v8AU7vTdD1KVrnTZXv4Yp7MfKGzJtO7jOCBwPfmhagzf/sPTP8Anzj/AFo/sPTP+fOP9av0UAZm iIsSXsSDEcd26ouchRgcCtOs7SPv6h/1+P8AyWtGgDHjsba91nUDcxCXyzGF3E/KNgPFWf7D0z/n zj/Wm2P/ACGNT/34/wD0AVo0AUP7D0z/AJ84/wBaP7D0z/nzj/Wqeq6rqFvrdnp9lFbsksMk80kx bKojICFA6k7uKwp/E+qXWjyPcw2scGqaZcXFm1tKxlh2pkb+2cMORjBGKAOp/sPTP+fOP9aP7D0z /nzj/WuYXxbqkWoW+n2elyXcNvHbrcOI2ZmLqpJDdFwDnnrg9K0LSOY+MmNjqF7cW0SyfbxNLvhV zjYiDoGHJOOgxnk07ah0Nf8AsPTP+fOP9aiu9F01LOZltEBEbEEZ44rUqC9/48Z/+uTfypAM0xi2 lWjMSzGBCSTkn5RViQ4jYj0NVtL/AOQTZ/8AXBP/AEEVZk/1Tf7poAx9K0jT5tIspZbVHd7eNmZi SSSoyTVv+w9M/wCfOP8AWnaL/wAgOw/69o//AEEVdoAof2Hpn/PnH+tH9h6Z/wA+cf61iXviXVLe 51No7azNtZ3MdpEXdgzyyCPazHoqDzOepOKrT6vqM97aWF95Md1Z6tBHK9o7eXKrxswGDyPcHPY9 6FqD0Ok/sPTP+fOP9aP7D0z/AJ84/wBa5zRvFOp6/LKj6bNbWNxDIYblFMZjwcDLt8pJ9QOCO9Wv B0t6lzqtjfvdLJBJGyW9zcfaGiRk4/e/xZIY47UAbP8AYemf8+cf61U1DTrOzNpNbQLFJ9riXcpI OC2CK2qztZ/1dp/1+Q/+hUAaNFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAGdd/wDId07/AHJv 5LWjVW80+G9aN5GlR4s7HilZCM9eQfaof7Gh/wCfu+/8C5P8aALVzawXtu1vcxLLE+NyOMg4OR+o qreaFpOoXsN7eadbz3MGPLleMFlwcj8jzR/Y0P8Az933/gXJ/jR/Y0P/AD933/gXJ/jQAt1oelX1 vNBdWEE0U8olkV0B3OABu+uABmq914U0C9t7e3udJtpIrVdsCFOIx7Vkz6fczeJntYNXv4IkgGxT OzK0mcnIzn7pHQirZha041L+0I0H/LeC7lkj/EZ3L+Ix70AdAiLGiogCqoAAHYU6suHTbS5iEsF/ eSxt0ZL1yD+Oak/saH/n7vv/AALk/wAaAE0j7+of9fj/AMlrRqvZ2UNjE0cO8hmLszuXZie5JqxQ BnWP/IY1P/fj/wDQBWjVGbSbea5e48y5ikkxv8qd0DYGBwDim/2ND/z933/gXJ/jQBba2ga6S6aJ TOiFFkxyFJBI+hwPyqjb+HNFtXunt9Ltomu1KTlYwN6nqD7HPSoLuDT7JlSbUL7zW+7El1Izt9FB yagGlX179ye80+I/xSXbvKR7Lnav45+lAF+bw9o9xeQXk2m273FsFEUhjGVC/d/Lt6U228M6JZ6i dRttNgiu2ZnMqLglm+8fqcmq2l6Wslq6y3+oyPDNJGXa7fLAMQCcEDpirv8AY0P/AD933/gXJ/jQ BoVBe/8AHjP/ANcm/lVb+xof+fu+/wDAuT/GkbRYHUq11fEEYI+1yc/rQBNpf/IJs/8Argn/AKCK syf6pv8AdNJFEkMKRRjaiKFUegHSnEAjB6GgCnov/IDsP+vaP/0EVdrNj0O2ijWOO4vURAFVRdyY AHQdad/Y0P8Az933/gXJ/jQBNJplhNFdQy2kLx3hzcKyAiU4Ay3rwAPwqG10LSrK2it7bT4IooZf OjVUA2yf3vrz1qG6srKyi824v71Fzgf6XISx9AM5J9hWVf2N7JZG4iur+xj3oEBunaVyWAGckhRz 05P0oA14/DWhxT3M6aVarJdqVnPlD94D1B+vf1qxpuk6fo8DQadZxWsbNuZY1xuPqfWo/wCxof8A n7vv/AuT/Gj+xof+fu+/8C5P8aANCs7Wf9Xaf9fkP/oVL/Y0P/P3ff8AgXJ/jQujWwljd5rqXy3D qsly7LkdDgnmgDQooooATIBAyMnoKWuV8UzzWms2t1AcSwaXfujYzhgIyP1FYusTa0+galbXOsTy /wDEvtr4SpCiNGS53qMD7uFz3I55o6AeiUV55e+I9Yj163tLLV7drYJAbeS4lRft4b7zYEZ39x8h XBrQtb7WpdUjlk1Rzb3GqXNiLcQIBGiiQqwOMlgUHJ4wenegDsJJY4U3yyLGuQNzHAyTgfrT6870 8lvhv5Umoy300V7Ckqy7d0DC4TKHAB9+eefSpoPEWqXfjiTS4dQZIZpLiDynEZeAohKuEC5AyMgs x3A9B2AO+orz6bxTrs2iXV9CRCbQw2VwWUKIp937+TJU4C/KAcEDJJBxU+m6nrmpf2TanWYwtzNc B7m08uYyRoqlRuKBc5JBIXH40LUDuqKKKACis46QCc/2jf8A/f8A/wDrUf2OP+gjf/8Af/8A+tQB o0Vnf2OP+gjf/wDf/wD+tR/Y4/6CN/8A9/8A/wCtQBo0Vnf2OP8AoI3/AP3/AP8A61H9jj/oI3// AH//APrUAUScag94B93UhGT7GIJ/Mit+uU/skyeH7u5S/vi3mSzKPP6lZCV7f7IrYTSlkRXXUr8q wBB8/t+VAEk2kW7ytPbs9pcNyZYDt3H/AGh0b8RTPtOpWXF1bi7iH/La2GHH1jP/ALKT9KX+xx/0 Eb//AL//AP1qQ6Sqgs2pX4A5JNx0/SgC1aX1rfIWtplk28MBwyn0IPIP1qxXLXFlZ306tZS6jfTx n5Z4rkxonsZB1HsM/Soz4e1pFb7Zq15qEDjBt4bjyXXn+8AN/p/DQBvz6tbRSmCEPdXA6wwDcV/3 j0X8SKj8jU73/j5nFlEf+WVud0h+rkcfgPxqjp9pp7gWlvf31tIg/wCPZ5PLcf8AAcc/UZq//Y4/ 6CN//wB//wD61AFm0sLWxDC3hVC3LP1Zvqx5P41YrO/scf8AQRv/APv/AP8A1qP7HH/QRv8A/v8A /wD1qAHadhLvUYvS43f99Ip/nmr9YMGkhdZu4/7QvxuiikB8/rywPb2FXf7HH/QRv/8Av/8A/WoA 0aKzv7HH/QRv/wDv/wD/AFqP7HH/AEEb/wD7/wD/ANagDRorO/scf9BG/wD+/wD/APWqpdwQWrrD /aGozXDjKQRTZdvf2HucCgDb6VnNqUt2xi0uNZcHDXL/AOqX6f3z7Dj3FUk8Oz3isdS1G9EbYxbR 3BKj/ebALH26exq6NGVQFXUL4ADAAnwB+lAE1rpscEv2iZ2ubojBmk6geijoo9h+Oaj1bLCziH/L S7j/APHct/7LSf2OP+gjf/8Af/8A+tVG70onVLCIahfkZkkP7/phcen+1QBv0Vnf2OP+gjf/APf/ AP8ArUf2OP8AoI3/AP3/AP8A61AGjRWd/Y4/6CN//wB//wD61H9jj/oI3/8A3/8A/rUAaNFZ39jj /oI3/wD3/wD/AK1H9jj/AKCN/wD9/wD/AOtQBoYorP8A7HH/AEEb/wD7/wD/ANaj+xx/0Eb/AP7/ AP8A9agDQwOOBx0oxWf/AGOP+gjf/wDf/wD+tR/Y4/6CN/8A9/8A/wCtQBoYHpRgZzis/wDscf8A QRv/APv/AP8A1qP7HH/QRv8A/v8A/wD1qALNlY29hA0Num1XkeRskkszEsxJPqTU+AO1Z/8AY4/6 CN//AN//AP61H9jj/oI3/wD3/wD/AK1AGjRWd/Y4/wCgjf8A/f8A/wDrVoAYAHXHrQAtFFFABRVa 6v7eyaNZmfdLnYqRs5OOvCgmof7YtP7l3/4Bzf8AxNAF+kZgilicADJqj/bFp/cu/wDwDm/+JrP1 3VWfSZm0+K8kuEUssQtJR5vBBXle4PHvigC/o0QOg2qOOJIQzD/eGT/Om6ZdRwaHA91KkSwr5Ts7 ADKkr/Sud0PXtTls1guYprGVhkJLZSs0CAABVVV5xjJLHqTxirelPpsF5dmdby6njnLpJNaSsVDA NkDbheS3QCgDX/tG5vONNtCyn/l4uMpH+A+835Ae9KNIWch9Sne9bOdjDbEPog4P/As07+2LT+5d /wDgHN/8TVi0vIL2IywMWUMVO5CpBHUEEAigCYAKoVQAAMADtS0UUAQXVnbXsfl3MKSqORuHIPqD 2P0qp9kv7LmyuvtEf/PC6JJH0k6/mDV25uYbOBp52KxrgEhSTycDgcnkiqv9sWn9y7/8A5v/AImg BItXg8xYbxHspmOAs/Csf9lvun88+1aFZ0mqWE0bRyw3MiMMMrWMpB/DbVDzIbXnTJ72AD/lhJZT SRH6DblfwOPagDQYbPEMbf8APW1Yf98sv/xVaFcPc6trE3iK2iaxvEtXDbrqO2kK24wNwB2gndtG MjIJPbFdT/bFp/cu/wDwDm/+JoAv1HPPFbQtNPIscajJZjgCsy719YgqWtneTSPwC1pKqJ7sdv8A IE1DDNaGZbm+a7urhTlc2UwjiP8Asrt4+pyfegC1597qXFqGtLY/8t5F/eOP9hT0+rflVu0sbeyR hCmGc5d2O5nPqxPJplvqVtdT+RGZRJtLhZIXjyAQCRuAz1H51aJwMmgBaKz01uykRZI/tLowBVlt JSCPUHbS/wBsWn9y7/8AAOb/AOJoAv1nsS/iFB2itGP/AH04/wDiKX+2LT+5d/8AgHN/8TVODU4R q13O8N4EaONI2+xy843E/wAPq1AG3RVD+2LT+5d/+Ac3/wATR/bFp/cu/wDwDm/+JoAv0VQ/ti0/ uXf/AIBzf/E0q6xZtIkZM6GRgimS2kQEnoMlQKAL1FFFABRRXPeJLyGy1nw/Nc3KW8P2uUO8kgRf 9RJjJPHWgDoaK4a48Y3J8aW9lZ3cUtjLcpbMmIx96PduX5t7dQd23b296bL4v1iPT751iie40iBk vflwpnMm1TyeF2AyH2YcijoB3dFcHZeIPEF5ZW0AvbNJrjURbLdDypjsMTOcrGxUMCvHPTGRRaeK 9ck8Sz2xW3kggmlga3MkSyMEUkMF3byzEA424w340Ad3uG7bkZxnFLXCeF9Tm1XxXaXNxq1pfyS6 Q8pS3QL9nLSRkoeTnHTnB4Oa7ugAooooAKKKKAM67/5Dunf7k38lpup+ItJ0aeKC/uxDLMpZECMx IBwThQeORTrv/kO6d/uTfyWszVNHutQ8YWtxHc3lnBFYurT2zKu5vMQhDkHsCfwo6gdGDkZFLXGb NXTV/sJsr4qNZ+1faQw8ryCvTOc9eNuKrWGiazapa3Nt9sjv7iG9SdppmZQckw5BJAwcYwKOlw8j s9Q1Gy0qze8v7mO2gT70kjYFVRNHDrMkxdVhntBJvY4HyMcnP0cVy3kLF4L1GGDQNZ+1zQ+UUnzK 7zmNgXXLHjJ5YYHNakmo4XSZJtJvhH5DrIskI/u48srn7xKggdMUdwN+w1C01S0W7sZ0uIHJCyIe DgkH9Qar6P0vv+vyT+lZ/gyWY6VNDPYXdm6XUzgXMWzcryMy45PYjNaGj9L7/r8k/pQBo0UUUAZ+ t/8AIN/7bw/+jVrQrP1v/kG/9t4f/Rq1oUAZlt4i0m81STTLe7El3EzK6BGwpXqN2MZH1rTrjbfw /qZ07xA6XV7FPdS3gt7UyKsR3E7HHGQT1zmq90usava3zxWGqWYkt7OJA7eXISsxMhXDcfKevegH od1VSXVLGDUINPkuo1u7gExQ7vmYAZJx6YBrkrzSLuzguLRLXUbjSI9SDtbwzMZHhMI4UltxUSnJ GfWprqQ22p+HjbaHqhjtyXkbyvMZEaN0VXbcSSCwzycCgDpNU1rTtFhSXUbpbdHOFJBOcdeB2HrV uKWOaJJYnWSN1DK6nIYHoQa53xDrGojTzBZaRqG+eaS3eZIBIYoxwZAued38P5npg7OkRww6PZw2 8EsEMcKJHFMMOigYAYetADJf+Q/a/wDXrN/6FFV2T/VN/umqUv8AyH7X/r1m/wDQ4quyf6pv900A VNF/5Adh/wBe0f8A6CKhvfEWk6fqMenXV2EupApWIIzHDEgHgHGSD19Km0X/AJAdh/17R/8AoIrJ k0e6ufG0999qvbW3S1twPJZQk7K8hKtkEnAI6Y+9R1DodHRXFWKawL2ysZbG+X7Hc3bTXDN+6dXE hjwd2W+8vbjFVLXQtbstKH2E363d1ov+kGW4ZibgFOAWOFfaXAIwOnpQM7XUNUsdKhWa/uordGYI pkbG5icAD1p97e22nWj3d3MsUMf3nP5D61xepQxL4Omt9M8PawHmmAjimQySKQVLN8zEqpxjrya6 K91OWfT5wmm6rGDAjh4I0Eo3EghQT99cZIx3GM0CRoadqVnq1ot3YXCzwsSAy9iDggg8gj0NQaz/ AKu0/wCvyH/0KqHg21urTSp1uYZ4xJdSSRG5AE7q2DukxxuJz+GKv6z/AKu0/wCvyH/0KgDRoooo AKhuba2uowl1BFMgOQsqBhn8amrk/G9i+pXehWaQ2kzSXcn7u8jLxHELnlQRn296AOlWytFdZEtY Q6qFVhGMgDoAfQVHaabbWT3ckYLNeTGWYuc7jgLj6AADFcnqHiCbw+l/pjXNraTQW1r9hgSMKrEk q+xTyVyPfFTNq2srrMk329DZx6wlh9l8heUZFOS3XILcduOc0+odDq4rO1gRY4baKNEbcqogAB9R jvR9mtvtJufIi8/G3zdg349M9a891DV77U/DeoTN4lEF0jb5rCGJA9mqzAHJ+8AB1Ldeo4q7c61c 2ct+1vfweWzWUb6p5SHajqczNgbT2xn5Rn0pAdtFa28DFoYIo2YkkogBJPWpa4e21nWL4Wlna6zH Ik2oy2yakluh8+JYS+5R93IYFcjjjpUR8UajHFo0l3qkMfmM0c8UMaGW4YTeWCEbkqQDnZyM56UA d7RRRQAUUUUAZWpzx2uq2FxNuWJVlUsELAEhcdB7GpP7e03/AJ+G/wC/T/4Vo0UAZ39vab/z8N/3 6f8Awo/t7Tf+fhv+/T/4Vo0UAZ39vab/AM/Df9+n/wAKo6xrmnNpzyJOS8LJMP3T/wALBj29Aa36 juIRcW0sLdJEKn8RigCl/b+mf8/Df9+n/wAKbobiWC6lUNskupGQspXIz15qfSJjcaTayMSXMShs /wB4DB/UGrlABRRUNzdQWcJmuJVjQHGT3PoB3PsKAKuucaWzYYhZYmO1SSAJFJOB7Cox4k0hpWiW 8BkTG5BGxK56ZGOKXN/qfTfYWp7kfvpB/wCyD9fpV22tYLOLyoIwi5ye5J9STyT7mgCp/b2m/wDP w3/fp/8ACj+3tN/5+G/79P8A4Vo0UAZ39vab/wA/Df8Afp/8KP7e03/n4b/v0/8AhWjRQBnf29pv /Pw3/fp/8KP7e03/AJ+G/wC/T/4Vo0UAZMN7Bfa7A9szOsdtKGPlsACWjxyR7H8q1JATGwHXBp1F AGJpes2EGk2cMsrpJHAispifIIUAjpVr+3tN/wCfhv8Av0/+FaNFAGa3iDS1Us1yVUDJJicAfpQP EGmMARckg8giJ+f0p+tuU0S8I6tEyD6nj+tXVUIgUdAMUAUP7e03/n4b/v0/+FH9vab/AM/Df9+n /wAK0aKAM7+3tN/5+G/79P8A4VVvtTtL5rSG2d5JPtUTYETDgNknpW3RQAUUUUAFIQCQSASOntS0 UANZEYgsqkjgEijYv90dc9O9OooAZ5ceWOxcvwxx1+tHloFKhF2kYIxxj0p9FADQiKFAVQF6ADpS eXHlTsXK/dOOn0p9FABRRRQBWSO8GzfcwthjvxCRuHYD5uP1z7UJHegR77mFsBt+ICNx7Y+bjH45 9qs0UAVhHe4XdcwkhCDiAjLdj97p7frR5d7j/j5hz5eP9Qfv/wB773T2/WpJ7mC2UNPPHEpOAZGC g/nUP9q6d/0ELX/v8v8AjQA5o70httzCCUAXMBOG7n73I9v1oeO9PmbLmFchdmYCdp75+bnP4Y96 b/aunf8AQQtf+/y/40f2rp3/AEELX/v8v+NAD2jvCX2XMSgsCmYSdo7g/Nz9eMe9BjvMnFzEB5gI /cnhP7v3uvv+lM/tXTv+gha/9/l/xo/tXTv+gha/9/l/xoAp6Ul2n2m38+ICC9fI8o8o2HA+91+b r+lX1jvAU3XMRAYlsQkZXsB83B9+fpXF6h4zh0fxItpJPbo14yu0iuGjdFDA7TnAYjaMEjBHpW5H eWmrIJb7VbMWzcrbQXKlWH+24PzfQYH1oAnF/f3EiQ6fJBdMhYTTeSVhHpg7jkj0GfcrUltpNxFO t1cXkd1chWHmyQ/dJ6bBuwoHcdT61YTUtLjRUjvbREUYCrKoAH507+1dO/6CFr/3+X/GgB3l3uB/ pMOfLx/qD9/+997p7frQY73Bxcwg+WAP3B4fufvdPb9ab/aunf8AQQtf+/y/40f2rp3/AEELX/v8 v+NADnjvSH2XMKkqNmYCdp7k/Nzn8Me9Dx3h8zZcwrkjZmEnaO+fm5z+GPepILmC5UtBPHKoOCY2 DAflUtAFdo7wlttzEAXBXMJOF7j73J9/0o8u83f8fEWPNzjyT9z+797r7/pViigCusd4Cu65iIDk tiEjK9h97g+/6UiR3g8vfcwtgtvxCRuHbHzcY/HPtVmoZ7y1tiBcXMURboJHC5/OgBix3oCbrmEk KQ+ICNx7EfNxj05z7UCO9wM3MJPlkH9weX7H73T2/Wm/2rp3/QQtf+/y/wCNH9q6d/0ELX/v8v8A jQA7y73B/wBJhz5YA/cH7/8Ae+909v1oaO9IfbcwglQFzAThu5Pzcg+nb1NN/tXTv+gha/8Af5f8 aP7V07/oIWv/AH+X/GgCnrSXTWwi+0RYnuIEQeSTt+cFs/NznHtV9o7wl9tzEAXBXMJOF7g/Nyff j6Vz2t64kerWEEE9tOkrl4j5q7UdVbO854XkH/gJHUit1dV0/aN2oWpOOSJV/wAaAJDHeZOLiLHm 5H7k/c/u/e6+/wClAjvMjNzER5hJ/cnlOy/e6+/6Uz+1dO/6CFr/AN/l/wAaP7V07/oIWv8A3+X/ ABoAekd4DHvuYmAY78Qkbh2A+bjH459qRI70CPfcwsQG34gI3Htj5uMfjn2pv9q6d/0ELX/v8v8A jTo9RsZpBHFeW7u3RVlUk/hmgAEd6Au65hJ2EHEBGW7H73T2/Wjy73H/AB8w58vH+oP3/wC997p7 frVmigCs0d6Q226hBKALmAnDdz97ke361OgcD52DH2GKdRQAUUUUAFFFFABRRRQAUUUUAFFFFAGZ fRpLrenLIiuNk3DDPZau/Y7X/n2i/wC+BVS7/wCQ7p3+5N/Ja0aAIfsdr/z7Rf8AfAo+x2v/AD7R f98CpqQ9KAKsSadMxSJbWRl6hQpIqX7Ha/8APtF/3wK8+0G2u9C8ER6xELKHcIWZ7ex2TLF5o8wy Nk7/AJc54HrWlJrl9qshXTNSkjt59YS3juI4QcQm33Nt3DH3gcNz+NOwPQ7AWtuBgQRD/gAqPybE ymLy7cyAZKbVzj1xXGTa1fRW1lBqWuzafAHu45NQWBN0rxybY1OVKglcngc44xTxdaDd+O7aK3e0 t72zlLTzldk91K0ZHljuVAOTnjIAHQ4QHYtbWa43QQDJwMoOTTvsdr/z7Rf98CuP8VaxoEjaBqb3 kQY3kckTuWGIgTuYKenbJxXaqwdQynKkZBHejoHUi+x2v/PtF/3wKPsdr/z7Rf8AfAqaigDMsY0i 1vUVjRUGyHhRjs1adZ1p/wAhzUf9yH+TVo0AFFFFABWYYYpfEcnmRo+LRMblBx87Vp1nJ/yMcv8A 15p/6G1AFv7Ha/8APtF/3wKPsdr/AM+0X/fAqaigCoi6dLIY41tXdeqqFJH4VL9jtf8An2i/74Fe f6VZX2leFdR1q0SzSXdOUeGxxcgC4Jbc+TvG0Hjb6elX7nxDealPc/2RqTC2fULSCGdIgwVHHzlc jn68jNAdTsfslt/z7xf98CmeTY+b5XlW/mEZ2bVzj1xXGT6zqFtBFa6hrc1nax31zBLqQhTeQgBj UkqVBOTzt52470XN3oN74v062Wa1jv7eSKae9kQRzTsUwka8ZO4EFh0AwOp4AOzeGxi2iSK3TccL uVRk+gp/2O1/59ov++BXGeMtW8N6hp8EExs3nvlligurqPC2yg7XcEjIII4A5Jx2ya7O1KG0hMUn mxmNdshOdwxwfxoAPsdr/wA+0X/fAqhq1tBGtmyQxqwvIuQgB+9WrWdrP+rtP+vyH/0KgDRooooA KKKKACiiigAooooAKKKKACiiigAooooAzL50j1vTi7qo2Tcscdlq99pt/wDnvH/32KJ7W3ulC3EE UwU5AkQNj86g/sjTP+gdaf8Afhf8KAJ/tNv/AM94/wDvsUfabf8A57x/99ioP7I0z/oHWn/fhf8A Cj+yNM/6B1p/34X/AAoAn+02/wDz3j/77FH2m3/57x/99ioP7I0z/oHWn/fhf8KP7I0z/oHWn/fh f8KAJ/tNv/z3j/77FH2m3/57x/8AfYqD+yNM/wCgdaf9+F/wo/sjTP8AoHWn/fhf8KAJ/tNv/wA9 4/8AvsUfabf/AJ7x/wDfYqD+yNM/6B1p/wB+F/wo/sjTP+gdaf8Afhf8KAJ/tNv/AM94/wDvsUfa bf8A57x/99ioP7I0z/oHWn/fhf8ACj+yNM/6B1p/34X/AAoAgsnSTW9RKOrDZDypz2atOooLW3tV K28EUIY5IjQLn8qloAKKKKACszzY4/Ecu+RVzZpjccfxtWnUE9laXTBri1hmKjAMkYbH50AO+02/ /PeP/vsUfabf/nvH/wB9ioP7I0z/AKB1p/34X/Cj+yNM/wCgdaf9+F/woAn+02//AD3j/wC+xR9p t/8AnvH/AN9ioP7I0z/oHWn/AH4X/Cj+yNM/6B1p/wB+F/woAn+02/8Az3j/AO+xR9pt/wDnvH/3 2Kg/sjTP+gdaf9+F/wAKP7I0z/oHWn/fhf8ACgCf7Tb/APPeP/vsUfabf/nvH/32Kg/sjTP+gdaf 9+F/wo/sjTP+gdaf9+F/woAn+02//PeP/vsVQ1eeF0tFWVGP2yLgMP71WP7I0z/oHWn/AH4X/CnR 6ZYQyLJFY2yOvIZYlBH44oAtUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB/9k= --_004_BBA82579FD347748BEADC4C445EA0F2166BBFAC2nkgeml512mbxchi_-- From nobody Wed Jun 3 02:47:43 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884A71A0078 for ; Wed, 3 Jun 2015 02:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXNY6sTOjmAQ for ; Wed, 3 Jun 2015 02:47:34 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [58.251.152.64]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8783C1A0022 for ; Wed, 3 Jun 2015 02:47:33 -0700 (PDT) Received: from 172.24.2.119 (EHLO nkgeml401-hub.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id COY07075; Wed, 03 Jun 2015 17:47:24 +0800 (CST) Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.152]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Wed, 3 Jun 2015 17:44:11 +0800 From: Zhoutianran To: STUART VENTERS , "sdn@irtf.org" Thread-Topic: [Sdn] Defining a Common Model for intent Thread-Index: AQHQnJG50WlY7ClbtUGoYewpxJwlHZ2YUVeAgABezYCAACyygIABp5jQ Date: Wed, 3 Jun 2015 09:44:10 +0000 Message-ID: References: <00f301d09b13$79cc2410$6d646c30$@ndzh.com> <8D15A2BAF93E9C49AB037A0647E5FA643F8490D8@eusaamb105.ericsson.se> <865C20BAAE8BBD4C89E7D6FE694F6B3B2D3CA540@nkgeml505-mbs.china.huawei.com> <8D15A2BAF93E9C49AB037A0647E5FA643F84AAA2@eusaamb105.ericsson.se> <1220E2C537595D439C5D026E83751866C42AC2FF@ex-mb3.corp.adtran.com> In-Reply-To: <1220E2C537595D439C5D026E83751866C42AC2FF@ex-mb3.corp.adtran.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.21] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "ibnemo@ietf.org" Subject: Re: [Sdn] Defining a Common Model for intent X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 09:47:41 -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 de= tailed description in my "role based intent" email. I think the essential of the role based intent is that there is only one in= tent layer which is always on the top. Intent is dedicated for correspondin= g roles. One role will not call other roles interfaces.=20 Then we can try to find way to express intent for various roles. Regards, Terence -----Original Message----- From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of STUART VENTERS Sent: Wednesday, June 03, 2015 12:06 AM To: sdn@irtf.org Cc: 'Dave Hood'; ibnemo@ietf.org; Lifengkai (Fengkai); Zhoutianran; Xiayinb= en; 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' ap= pears 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 recogn= ize. 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 produc= t 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 pat= h Adaptor: tailors the provisioning to a specific box Driver: pushes the provisioning into the forwarding tables Forwarding engin= e: 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 glob= al 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 re= finement. That said, the data model for intent might/should be different at each leve= l. Since each level is processing the same request at different levels of deta= il, it might be similar at each level. Perhaps the data model starts simple on top and gathers more and more detai= l as it gets lower ? Maybe like a tree with the root at the top and leaves at the forwarding eng= ines, except distributed. Perhaps a simple starting point near the top is a combination of entities, = endpoints, and connections. Regards, Stuart Venters From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of Dave Hood Sent: Tuesday, June 02, 2015 8:26 AM To: Lifengkai (Fengkai); Susan Hares; sdn@irtf.org Cc: Zhoutianran; Xiayinben; ibnemo@ietf.org 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 o= f 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.=20 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 ap= pears 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:lifengkai@huawei.com] Sent: Tuesday, June 02, 2015 12:47 AM To: Dave Hood; Susan Hares; sdn@irtf.org Cc: Zhoutianran; Xiayinben; ibnemo@ietf.org Subject: RE: [Sdn] Defining a Common Model for intent Hi Dave and all, Thanks for proposing the two valuable intent use cases. For the use case 2, I agree that the IT employee needs to include the detai= ls of ports/protocols into his/her intent descriptions, but those may not b= e in the intent context scope of a non-IT employee. Have a further consider= ation 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 fitt= ing the intent requirements of the network users with different roles. Any thoughts about this consideration? Best Regards, Fengkai From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of Dave Hood Sent: Tuesday, June 02, 2015 1:38 AM To: Susan Hares; sdn@irtf.org Cc: Zhoutianran; Xiayinben; ibnemo@ietf.org 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 l= ooking forward to making the concept more precise. When I click a link on a web page, I express an intent to invoke whatever t= hat link offers. Completely below the surface is a layer stack, on-demand s= ession establishment, DNS look-ups, server load balancers, and any number o= f other technological features that are of no interest to me. Why not use t= hat 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 a= nd receive an offer of several widgets, some new, some used, some with a ch= oice 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, hav= ing found nothing I liked better somewhere else. Now I accept one of the of= fered widgets and go through the checkout process.=20 Do we agree that this is a fairly pure expression of intent as conceptualiz= ed 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 S= DN of one kind or another. I invoke my intent through a GUI onto software l= ocal 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 conc= erned, the client makes DNS queries and swaps opaque TCP packets over a for= warding path that may already exist, or may need to be learned and set up o= n demand. This is about right, because the session content may well be encr= ypted 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 subsequen= t 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 r= oute 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 th= e 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 inten= t is to have an E-Line between two of my campi. I necessarily care about po= rts and protocols; talk about intent being portable and protocol independen= t continues to confuse me completely. How can I order an E-line without car= ing about such details? [Nor is this intent portable.] Obviously, an SDN controller is going to expose whatever actions and elemen= ts of information are germane to the service it offers, and if ports and pr= otocols are germane to the service, so be it. The SDN architecture, being recursive, models the north side of any control= ler as exposing an instance of an information model, customized for the int= ended 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 no= t? 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 contras= t, what we might agree is *not* an intent or a service is the manipulation = of a granular information model, the explicit visibility of multiple object= s, how they are interrelated, their attributes, and the like. .=A0=A0=A0=A0=A0=A0=A0=A0 Network as a single lump vs some non-trivial topo= logy. .=A0=A0=A0=A0=A0=A0=A0=A0 Chauffeur vs driving a car. Legitimate reasons to= choose one option or the other, but the level of granularity is quite diff= erent. Shall we agree that driving is too granular to be considered intent? This idea of granularity and detailed operations on the components (which o= f course may be complex entities themselves, virtualized into simple-appear= ing lumps) seems to me to capture the essence of what people are talking ab= out 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:sdn-bounces@irtf.org] On Behalf Of Susan Hares Sent: Saturday, May 30, 2015 1:02 PM To: sdn@irtf.org Cc: 'Zhoutianran'; 'Xiayinben'; ibnemo@ietf.org 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/msg0= 0646.html) : 1)=A0=A0=A0=A0=A0 What information is needed to represent a service request= , 2)=A0=A0=A0=A0=A0 How to represent and transport the information for a requ= est. In order to define what information is needed to represent a 1) service req= uest that signals Intent from an application to a controller, it is importa= nt to define Intent, and provide a clear model of Intent.=A0 Also, in descr= ibing real use-cases it is important that one uses the same definition and = model for Intent in each use case.=A0 =A0 In the current forums examining Intent (ODL NIC, ODL Nemo, OF NBI and Keyst= one, OPNFV Movie, OpenStack) there is a realization that Intent occurs at m= ultiple layers.=A0 The authors of draft-xia-ibnemo-icim have created a defi= nition for intent and a unified model for defining intent which can handle = 1 or multiple layers. The model suggest that: 1)=A0=A0=A0=A0=A0 A user has a intent that is expressed in a context. 2)=A0=A0=A0=A0=A0 Intent (usually) involves an object with a result, and op= tionally includes operations toward that result.=20 3)=A0=A0=A0=A0=A0 Operations conditions perform actions within/modified by = constraints.=20 We believe this defines clearly what others are calling "pure intent" (obje= cts + results) versus "constrained intent" (objects + operations + constrai= nts).=A0 =A0The draft can be found at: =A0=A0https://datatracker.ietf.org/d= oc/draft-xia-ibnemo-icim/ .=A0 =A0The authors are looking for feedback on t= he concepts in the draft.=A0 =A0 Sue Hares=20 _______________________________________________ sdn mailing list sdn@irtf.org https://www.irtf.org/mailman/listinfo/sdn From nobody Wed Jun 3 02:53:15 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28FD71A00AE for ; Wed, 3 Jun 2015 02:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPMim_0GyenK for ; Wed, 3 Jun 2015 02:53:07 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 674181A009B for ; Wed, 3 Jun 2015 02:53:06 -0700 (PDT) Received: from 172.24.2.119 (EHLO nkgeml403-hub.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CML07386; Wed, 03 Jun 2015 17:52:46 +0800 (CST) Received: from NKGEML505-MBS.china.huawei.com ([169.254.2.71]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Wed, 3 Jun 2015 17:39:26 +0800 From: "Lifengkai (Fengkai)" To: Dave Hood , Susan Hares , "sdn@irtf.org" Thread-Topic: [Sdn] Defining a Common Model for intent Thread-Index: AdCbEy9UHkEQylvfQJyfdpRUZhhXPwBfgiUQAB27oPAAC6JcEAApNsNQ Date: Wed, 3 Jun 2015 09:39:25 +0000 Message-ID: <865C20BAAE8BBD4C89E7D6FE694F6B3B2D3CD38F@nkgeml505-mbs.china.huawei.com> References: <00f301d09b13$79cc2410$6d646c30$@ndzh.com> <8D15A2BAF93E9C49AB037A0647E5FA643F8490D8@eusaamb105.ericsson.se> <865C20BAAE8BBD4C89E7D6FE694F6B3B2D3CA540@nkgeml505-mbs.china.huawei.com> <8D15A2BAF93E9C49AB037A0647E5FA643F84AAA2@eusaamb105.ericsson.se> In-Reply-To: <8D15A2BAF93E9C49AB037A0647E5FA643F84AAA2@eusaamb105.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.243] Content-Type: multipart/alternative; boundary="_000_865C20BAAE8BBD4C89E7D6FE694F6B3B2D3CD38Fnkgeml505mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Zhoutianran , Xiayinben , "ibnemo@ietf.org" Subject: Re: [Sdn] Defining a Common Model for intent X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 09:53:14 -0000 --_000_865C20BAAE8BBD4C89E7D6FE694F6B3B2D3CD38Fnkgeml505mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dave, I think I got the point that you concern. Continuing the consideration in m= y last email, the intent is specific to the network users with different ro= les. 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 ge= nerally defining what is or is not intent, unless the user role, from the u= ser perspective is taken into account. Best Regards, Fengkai From: Dave Hood [mailto:dave.hood@ericsson.com] Sent: Tuesday, June 02, 2015 9:26 PM To: Lifengkai (Fengkai); Susan Hares; sdn@irtf.org Cc: Zhoutianran; Xiayinben; ibnemo@ietf.org 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 o= f 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 ap= pears 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:lifengkai@huawei.com] Sent: Tuesday, June 02, 2015 12:47 AM To: Dave Hood; Susan Hares; sdn@irtf.org Cc: Zhoutianran; Xiayinben; ibnemo@ietf.org Subject: RE: [Sdn] Defining a Common Model for intent Hi Dave and all, Thanks for proposing the two valuable intent use cases. For the use case 2, I agree that the IT employee needs to include the detai= ls of ports/protocols into his/her intent descriptions, but those may not b= e in the intent context scope of a non-IT employee. Have a further consider= ation 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 fitt= ing the intent requirements of the network users with different roles. Any thoughts about this consideration? Best Regards, Fengkai From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of Dave Hood Sent: Tuesday, June 02, 2015 1:38 AM To: Susan Hares; sdn@irtf.org Cc: Zhoutianran; Xiayinben; ibnemo@ietf.org 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 l= ooking forward to making the concept more precise. When I click a link on a web page, I express an intent to invoke whatever t= hat link offers. Completely below the surface is a layer stack, on-demand s= ession establishment, DNS look-ups, server load balancers, and any number o= f other technological features that are of no interest to me. Why not use t= hat 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 a= nd receive an offer of several widgets, some new, some used, some with a ch= oice 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, hav= ing found nothing I liked better somewhere else. Now I accept one of the of= fered widgets and go through the checkout process. Do we agree that this is a fairly pure expression of intent as conceptualiz= ed 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 S= DN of one kind or another. I invoke my intent through a GUI onto software l= ocal 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 conc= erned, the client makes DNS queries and swaps opaque TCP packets over a for= warding path that may already exist, or may need to be learned and set up o= n demand. This is about right, because the session content may well be encr= ypted 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 subsequen= t session. Hmmm... what happened to our intent-based NBI? The SDN offered m= y PC a packet interface with the properties of knowing how to recognize and= route DNS queries specially, and general IP connectivity. My PC accepted t= he service offer implicitly by offering traffic to the data-plane interface= . The network could be performing associated auxiliary services such as usa= ge-based billing (think wireless roaming), so it's more than just a dumb pi= pe. If this is not a legitimate example of intent, it would be good to write th= e 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 inten= t is to have an E-Line between two of my campi. I necessarily care about po= rts and protocols; talk about intent being portable and protocol independen= t continues to confuse me completely. How can I order an E-line without car= ing about such details? [Nor is this intent portable.] Obviously, an SDN controller is going to expose whatever actions and elemen= ts of information are germane to the service it offers, and if ports and pr= otocols are germane to the service, so be it. The SDN architecture, being recursive, models the north side of any control= ler as exposing an instance of an information model, customized for the int= ended 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 no= t? 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 contras= t, what we might agree is *not* an intent or a service is the manipulation = of a granular information model, the explicit visibility of multiple object= s, 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 opti= on 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 o= f course may be complex entities themselves, virtualized into simple-appear= ing lumps) seems to me to capture the essence of what people are talking ab= out 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:sdn-bounces@irtf.org] On Behalf Of Susan Hares Sent: Saturday, May 30, 2015 1:02 PM To: sdn@irtf.org Cc: 'Zhoutianran'; 'Xiayinben'; ibnemo@ietf.org 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/msg0= 0646.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 req= uest that signals Intent from an application to a controller, it is importa= nt to define Intent, and provide a clear model of Intent. Also, in describ= ing real use-cases it is important that one uses the same definition and mo= del for Intent in each use case. In the current forums examining Intent (ODL NIC, ODL Nemo, OF NBI and Keyst= one, OPNFV Movie, OpenStack) there is a realization that Intent occurs at m= ultiple layers. The authors of draft-xia-ibnemo-icim have created a defini= tion 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 i= ncludes operations toward that result. 3) Operations conditions perform actions within/modified by constraint= s. We believe this defines clearly what others are calling "pure intent" (obje= cts + results) versus "constrained intent" (objects + operations + constrai= nts). 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 --_000_865C20BAAE8BBD4C89E7D6FE694F6B3B2D3CD38Fnkgeml505mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dave,

 = ;

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

With the n= etwork user roles in mind, I think we can properly define what is the inten= t 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 th= e user perspective is taken into account.

 

Best Regards,

Fengkai

 = ;

From: Dave Hood [mailto:dave.hood@ericsson.com]
Sent: Tuesday, June 02, 2015 9:26 PM
To: Lifengkai (Fengkai); Susan Hares; sdn@irtf.org
Cc: Zhoutianran; Xiayinben; ibnemo@ietf.org
Subject: RE: [Sdn] Defining a Common Model for intent

 

I agr= ee 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 “ho= w”), 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 p= orts, 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 m= arketing people?

=  

Dave<= o:p>

=  

From: Lifengkai (Fengkai) [mailto:lifengkai@huawei.com]
Sent: Tuesday, June 02, 2015 12:47 AM
To: Dave Hood; Susan Hares; sdn@irtf= .org
Cc: Zhoutianran; Xiayinben; ibnem= o@ietf.org
Subject: RE: [Sdn] Defining a Common Model for intent

 

Hi Dave an= d all,

 = ;

Thanks for= proposing the two valuable intent use cases.

 = ;

For the us= e case 2, I agree that the IT employee needs to include the details of port= s/protocols into his/her intent descriptions, but those may not be in the intent context scope of a non-IT employee. Have a further co= nsideration 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 t= o be identified and distinguished, thus fitting the intent requirements of = the network users with different roles.

 = ;

Any thoughts about this con= sideration?

 

 

Best Regards,

Fengkai

 = ;

From: sdn [mailto:sdn-bounces= @irtf.org] On Behalf Of Dave Hood
Sent: Tuesday, June 02, 2015 1:38 AM
To: Susan Hares; sdn@irtf.org Cc: Zhoutianran; Xiayinben; ibnem= o@ietf.org
Subject: Re: [Sdn] Defining a Common Model for intent

 

An ex= cerpt from an email I sent on the ONF NBI list, which may contain some usef= ul thoughts:

=  

I have always had trouble understanding what an int= ent 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 int= ent to invoke whatever that link offers. Completely below the surface is a layer stack, on-demand session establishment, DNS look-ups, s= erver load balancers, and any number of other technological features that a= re 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&= #8217;s Amazon. I search Amazon’s catalog and receive an offer of sev= eral widgets, some new, some used, some with a choice of colour or other pe= rtinent features. If I see nothing I like, I may open a new browser window and check out Best Buy or EBay (lots more hi= dden 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 t= he offered widgets and go through the checkout process.

 

Do we agree that this is a fairly pure expression o= f 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 th= ink we can call the PC an SDN controller. It’s more an active mediato= r, 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 se= t up on demand. This is about right, because the session content may well b= e encrypted end to end, and rightly.

 

To the SDN controller, my intent is satisfied by di= recting DNS queries to a known DNS server somewhere, and ensuring IP connectivity for the subsequent session. Hmmm… what happened to o= ur intent-based NBI? The SDN offered my PC a packet interface with the prop= erties of knowing how to recognize and route DNS queries specially, and gen= eral 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 dum= b pipe.

 

If this is not a legitimate example of intent, it w= ould 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, a= nd 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 wha= tever 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 n= orth side of any controller as exposing an instance of an information model, customized for the intended client/customer/app/user. That being th= e 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 i= s the criterion by which an intent or service invocation is distinguished. Colloquially speaking, a service invocation is a single inv= ocation across the API: give me E-Line. Now of course this turns into const= raint 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 th= e 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 l= ump 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 essenc= e of what people are talking about when they say intent or service. I am no= t comfortable with the way I am expressing it, so if this is a step in a pr= oductive direction, or even if it’s not, I welcome suggestions to clarify the concept.

=  

Dave<= o:p>

=  

From: sdn [mailto:s= dn-bounces@irtf.org] On Behalf Of Susan Hares
Sent: Saturday, May 30, 2015 1:02 PM
To: sdn@irtf.org
Cc: 'Zhoutianran'; 'Xiayinben'; i= bnemo@ietf.org
Subject: [Sdn] Defining a Common Model for intent<= /p>

 

On this mail list, there has be= en 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 servi= ce request,

2)      How to represent and transport the information = for a request.

 

In order to define what informa= tion is needed to represent a 1) service request that signals Intent from a= n application to a controller, it is important to define Intent, and provid= e a clear model of Intent.  Also, in describing real use-cases it is important that one uses the same definitio= n 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) th= ere is a realization that Intent occurs at multiple layers.  The autho= rs 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 resu= lt, and optionally includes operations toward that result.

3)      Operations conditions perform actions within/mo= dified by constraints.

 

We believe this defines clearly= what others are calling “pure intent” (objects + results) = versus “constrained intent” (objects + operations + con= straints).   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

--_000_865C20BAAE8BBD4C89E7D6FE694F6B3B2D3CD38Fnkgeml505mbschi_-- From nobody Wed Jun 3 06:03:37 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F96F1A8787 for ; Wed, 3 Jun 2015 06:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CD04ozX81j2w for ; Wed, 3 Jun 2015 06:03:24 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 469521A1EFD for ; Wed, 3 Jun 2015 06:03:24 -0700 (PDT) X-AuditID: c618062d-f79a96d000007fb1-5c-556ea1b514b3 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 90.1F.32689.5B1AE655; Wed, 3 Jun 2015 08:41:57 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0210.002; Wed, 3 Jun 2015 09:03:18 -0400 From: Dave Hood To: Zhoutianran , STUART VENTERS , "Natale, Bob" Thread-Topic: role based intent Thread-Index: AdCdxq4VFvGDpUDvRK6YJXpiQnECmwANkqOQ Date: Wed, 3 Jun 2015 13:03:16 +0000 Message-ID: <8D15A2BAF93E9C49AB037A0647E5FA643F84C6C3@eusaamb105.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/related; boundary="_004_8D15A2BAF93E9C49AB037A0647E5FA643F84C6C3eusaamb105erics_"; type="multipart/alternative" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIIsWRmVeSWpSXmKPExsUyuXRPrO7WhXmhBhu3GVq03nzEZNF48ASz xfkFz1ksmtu3s1pMOLmA2YHVY8XERjaPliNvWT2WLPnJ5DF542E2j7cNV9kDWKO4bFJSczLL Uov07RK4Mlqud7AX9F1jrGh4fpypgXHbEcYuRg4OCQETib/d/l2MnECmmMSFe+vZuhi5OIQE jjJKfP96hBXCWcYosfBoKxtIFZuAhsSTS5OZQGwRgUqJdxN7WUBsZgE3iYPPzzOC2MICchJz m5dB1chL7Lx8jBVkmYiAkcTBIyYgJouAisTaZ4YgFbwCvhIHV3eBTRESCJXYv3YjO4jNKRAm 8efwcrCJjEC3fT+1hglik7jErSfzmSBuFpF4ePE0G4QtKvHy8T9WCFtJYs7ra8wg5zMLdDNK 7G5ZwgixTFDi5MwnLBMYRWchmTULWd0sJHUQRfkSvce3sELYOhILdn9ig7C1JZYtfM0MY585 8JgJU1xXYvqEI1BxRYnZy18xQixbyigxd+JvRpihNxbNY4MpmtL9kH0BI+8qRo7S4tSy3HQj g02MwDRxTIJNdwfjnpeWhxgFOBiVeHgT1PNChVgTy4orcw8xSnOwKInzOkYBhQTSE0tSs1NT C1KL4otKc1KLDzEycXBKNTBKbnmUdyDlhMDZwue3eOW39lncfy7lVX7qVsOTjvf39v9Z9jzi YJepo/CMCfEsmcc3f/fivrZCU8U49NnHCce1rI6Zax35c8HIxfF4b8yf1m6/5YxFBqeDuo/N tBApWx+xv719HXPsntJoob1zJfyStnzsEzl0mdfV+vju31XJseZiq4tjnbcosRRnJBpqMRcV JwIAP22KpPQCAAA= Archived-At: Cc: "sdn@irtf.org" , "ibnemo@ietf.org" Subject: Re: [Sdn] role based intent X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 13:03:27 -0000 --_004_8D15A2BAF93E9C49AB037A0647E5FA643F84C6C3eusaamb105erics_ Content-Type: multipart/alternative; boundary="_000_8D15A2BAF93E9C49AB037A0647E5FA643F84C6C3eusaamb105erics_" --_000_8D15A2BAF93E9C49AB037A0647E5FA643F84C6C3eusaamb105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Layering is the right issue, but the point is a little different. We, who l= ook at the global scenario from the perspective of the gods, see that there= is a recursion of clients/servers or customers/providers or .... But from the perspective of any one of those interfaces, the other layers a= re completely invisible. So a given app can invoke intent against a given S= DN controller, but the controller doesn't know whether the app is just a mi= ddleman, and the app doesn't know whether the controller can satisfy its re= quirements directly or whether it is also just a middleman. You can have one intent layer, as long as you recognize that you are only s= eeing one slice of the world. If you insist on only one northernmost intent= layer in toto, you will have to go back to the "make money" intent of the = investors. And if we recognize that each interface stands on its own, then any service= invocation across that interface qualifies as an expression and satisfacti= on of intent by that particular invoker-provider pair. Dave From: Zhoutianran [mailto:zhoutianran@huawei.com] Sent: Tuesday, June 02, 2015 11:30 PM To: Dave Hood; STUART VENTERS; Natale, Bob Cc: ibnemo@ietf.org; sdn@irtf.org Subject: role based intent Hi Dave, Stuart, Bob and all, I found many problems raised in the mailing list are coursed by the layered= intent thinking. Maybe we are tainted by the ISO model:-) For the layered intent, intent is a spectrum, very abstract at the top laye= r, more network specific and less abstract when the layer goes down. The pr= oblem is that the boundary of intent and non intent is vague. Or there is n= o boundary between this two, since one's what may be another one's how. And= consequently, it looks like everything is intent and no clear intent defin= ition. The role based intent will provide only one intent layer. That is always th= e top layer abstraction for each role, as shown in the following figure. Th= e functions can be layered as the implementation of the intent layer. [cid:image001.jpg@01D09DC2.F851A1A0] With the role based intent, although the end user's intent is much abstract= ed then the network administrator's intent, they are not related each other= . I.e., the end user will not use the administrator's intent. And the admin= will not provide additional services/interfaces to the end user. The essential of layering is that the lower layer will provide interface to= the higher layer. In order to fit up layer requirements, the lower layer w= ill provide adequate interfaces/capabilities. That also means too much info= rmation for a dedicated up layer user/app. For role based intent, we can firstly indentify various roles (no need to b= e complete, but those with attention), and then figure out the intent of ea= ch role. In this way, intent can be clear defined. That will also keep the = intent of each role to a small set on what they really cares about, without= expending to support other one's intent. Best Regards, Terence --_000_8D15A2BAF93E9C49AB037A0647E5FA643F84C6C3eusaamb105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Layering is the righ= t issue, but the point is a little different. We, who look at the global sc= enario from the perspective of the gods, see that there is a recursion of clients/servers or customers/providers or ….<= /o:p>

 

But from the perspec= tive of any one of those interfaces, the other layers are completely invisi= ble. So a given app can invoke intent against a given SDN controller, but the controller doesn’t know whether the app is just = a middleman, and the app doesn’t know whether the controller can sati= sfy its requirements directly or whether it is also just a middleman.<= /o:p>

 

You can have one int= ent layer, as long as you recognize that you are only seeing one slice of t= he world. If you insist on only one northernmost intent layer in toto, you will have to go back to the “make money” in= tent of the investors.

 

And if we recognize = that each interface stands on its own, then any service invocation across t= hat interface qualifies as an expression and satisfaction of intent by that particular invoker-provider pair.

 

Dave

 

From: Zhoutianran [mailto:zhoutianran@huawei.com= ]
Sent: Tuesday, June 02, 2015 11:30 PM
To: Dave Hood; STUART VENTERS; Natale, Bob
Cc: ibnemo@ietf.org; sdn@irtf.org
Subject: role based intent

 =

Hi Dav= e, Stuart, Bob and all,

&= nbsp;

I foun= d many problems raised in the mailing list are coursed by the layered inten= t thinking. Maybe we are tainted by the ISO model:-)

&= nbsp;

For th= e layered intent, intent is a spectrum, very abstract at the top layer, mor= e network specific and less abstract when the layer goes down. The problem = is that the boundary of intent and non intent is vague. Or there is no boundary between this two, since one's wha= t may be another one's how. And consequently, it looks like everything is i= ntent and no clear intent definition.

&= nbsp;

The ro= le based intent will provide only one intent layer. That is always the top layer abs= traction for each role, as shown in the following figure. The funct= ions can be layered as the implementation of the intent layer.

With t= he role based intent, although the end user's intent is much abstracted the= n the network administrator's intent, they are not related each other. I.e.= , the end user will not use the administrator's intent. And the admin will not provide additional services/interfaces to t= he end user.

&= nbsp;

The es= sential of layering is that the lower layer will provide interface to the h= igher layer. In order to fit up layer requirements, the lower layer will pr= ovide adequate interfaces/capabilities. That also means too much information for a dedicated up laye= r user/app.

&= nbsp;

For ro= le based intent, we can firstly indentify various roles (no need to be comp= lete, but those with attention), and then figure out the intent of each rol= e. In this way, intent can be clear defined. That will also keep the intent of each role to a small set on wha= t they really cares about, without expending to support other one’s i= ntent.

&= nbsp;

&= nbsp;

Best R= egards,

Terenc= e

&= nbsp;

&= nbsp;

--_000_8D15A2BAF93E9C49AB037A0647E5FA643F84C6C3eusaamb105erics_-- --_004_8D15A2BAF93E9C49AB037A0647E5FA643F84C6C3eusaamb105erics_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=9164; creation-date="Wed, 03 Jun 2015 13:03:14 GMT"; modification-date="Wed, 03 Jun 2015 13:03:14 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCACPAUoDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2aiii gDK1OCO61bT4J13xFZSUJOCQFwf1NTf2Hpn/AD5x/rTbv/kO6d/uTfyWtGgCh/Yemf8APnH+tH9h 6Z/z5x/rUfiLU5tH0K5v7eFJpYgu1HbAYlgOT261h3viXXLH7aWt9OcaTEkl8N7qZd2TiLPT5R1b qeOKAOg/sPTP+fOP9aP7D0z/AJ84/wBa5e48RXuky6ilrBJd3F1qxhhVlaQRgQI5+UcnoeBjqTVm 8v8AU7vTdD1KVrnTZXv4Yp7MfKGzJtO7jOCBwPfmhagzf/sPTP8Anzj/AFo/sPTP+fOP9av0UAZm iIsSXsSDEcd26ouchRgcCtOs7SPv6h/1+P8AyWtGgDHjsba91nUDcxCXyzGF3E/KNgPFWf7D0z/n zj/Wm2P/ACGNT/34/wD0AVo0AUP7D0z/AJ84/wBaP7D0z/nzj/Wqeq6rqFvrdnp9lFbsksMk80kx bKojICFA6k7uKwp/E+qXWjyPcw2scGqaZcXFm1tKxlh2pkb+2cMORjBGKAOp/sPTP+fOP9aP7D0z /nzj/WuYXxbqkWoW+n2elyXcNvHbrcOI2ZmLqpJDdFwDnnrg9K0LSOY+MmNjqF7cW0SyfbxNLvhV zjYiDoGHJOOgxnk07ah0Nf8AsPTP+fOP9aiu9F01LOZltEBEbEEZ44rUqC9/48Z/+uTfypAM0xi2 lWjMSzGBCSTkn5RViQ4jYj0NVtL/AOQTZ/8AXBP/AEEVZk/1Tf7poAx9K0jT5tIspZbVHd7eNmZi SSSoyTVv+w9M/wCfOP8AWnaL/wAgOw/69o//AEEVdoAof2Hpn/PnH+tH9h6Z/wA+cf61iXviXVLe 51No7azNtZ3MdpEXdgzyyCPazHoqDzOepOKrT6vqM97aWF95Md1Z6tBHK9o7eXKrxswGDyPcHPY9 6FqD0Ok/sPTP+fOP9aP7D0z/AJ84/wBa5zRvFOp6/LKj6bNbWNxDIYblFMZjwcDLt8pJ9QOCO9Wv B0t6lzqtjfvdLJBJGyW9zcfaGiRk4/e/xZIY47UAbP8AYemf8+cf61U1DTrOzNpNbQLFJ9riXcpI OC2CK2qztZ/1dp/1+Q/+hUAaNFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAGdd/wDId07/AHJv 5LWjVW80+G9aN5GlR4s7HilZCM9eQfaof7Gh/wCfu+/8C5P8aALVzawXtu1vcxLLE+NyOMg4OR+o qreaFpOoXsN7eadbz3MGPLleMFlwcj8jzR/Y0P8Az933/gXJ/jR/Y0P/AD933/gXJ/jQAt1oelX1 vNBdWEE0U8olkV0B3OABu+uABmq914U0C9t7e3udJtpIrVdsCFOIx7Vkz6fczeJntYNXv4IkgGxT OzK0mcnIzn7pHQirZha041L+0I0H/LeC7lkj/EZ3L+Ix70AdAiLGiogCqoAAHYU6suHTbS5iEsF/ eSxt0ZL1yD+Oak/saH/n7vv/AALk/wAaAE0j7+of9fj/AMlrRqvZ2UNjE0cO8hmLszuXZie5JqxQ BnWP/IY1P/fj/wDQBWjVGbSbea5e48y5ikkxv8qd0DYGBwDim/2ND/z933/gXJ/jQBba2ga6S6aJ TOiFFkxyFJBI+hwPyqjb+HNFtXunt9Ltomu1KTlYwN6nqD7HPSoLuDT7JlSbUL7zW+7El1Izt9FB yagGlX179ye80+I/xSXbvKR7Lnav45+lAF+bw9o9xeQXk2m273FsFEUhjGVC/d/Lt6U228M6JZ6i dRttNgiu2ZnMqLglm+8fqcmq2l6Wslq6y3+oyPDNJGXa7fLAMQCcEDpirv8AY0P/AD933/gXJ/jQ BoVBe/8AHjP/ANcm/lVb+xof+fu+/wDAuT/GkbRYHUq11fEEYI+1yc/rQBNpf/IJs/8Argn/AKCK syf6pv8AdNJFEkMKRRjaiKFUegHSnEAjB6GgCnov/IDsP+vaP/0EVdrNj0O2ijWOO4vURAFVRdyY AHQdad/Y0P8Az933/gXJ/jQBNJplhNFdQy2kLx3hzcKyAiU4Ay3rwAPwqG10LSrK2it7bT4IooZf OjVUA2yf3vrz1qG6srKyi824v71Fzgf6XISx9AM5J9hWVf2N7JZG4iur+xj3oEBunaVyWAGckhRz 05P0oA14/DWhxT3M6aVarJdqVnPlD94D1B+vf1qxpuk6fo8DQadZxWsbNuZY1xuPqfWo/wCxof8A n7vv/AuT/Gj+xof+fu+/8C5P8aANCs7Wf9Xaf9fkP/oVL/Y0P/P3ff8AgXJ/jQujWwljd5rqXy3D qsly7LkdDgnmgDQooooATIBAyMnoKWuV8UzzWms2t1AcSwaXfujYzhgIyP1FYusTa0+galbXOsTy /wDEvtr4SpCiNGS53qMD7uFz3I55o6AeiUV55e+I9Yj163tLLV7drYJAbeS4lRft4b7zYEZ39x8h XBrQtb7WpdUjlk1Rzb3GqXNiLcQIBGiiQqwOMlgUHJ4wenegDsJJY4U3yyLGuQNzHAyTgfrT6870 8lvhv5Umoy300V7Ckqy7d0DC4TKHAB9+eefSpoPEWqXfjiTS4dQZIZpLiDynEZeAohKuEC5AyMgs x3A9B2AO+orz6bxTrs2iXV9CRCbQw2VwWUKIp937+TJU4C/KAcEDJJBxU+m6nrmpf2TanWYwtzNc B7m08uYyRoqlRuKBc5JBIXH40LUDuqKKKACis46QCc/2jf8A/f8A/wDrUf2OP+gjf/8Af/8A+tQB o0Vnf2OP+gjf/wDf/wD+tR/Y4/6CN/8A9/8A/wCtQBo0Vnf2OP8AoI3/AP3/AP8A61H9jj/oI3// AH//APrUAUScag94B93UhGT7GIJ/Mit+uU/skyeH7u5S/vi3mSzKPP6lZCV7f7IrYTSlkRXXUr8q wBB8/t+VAEk2kW7ytPbs9pcNyZYDt3H/AGh0b8RTPtOpWXF1bi7iH/La2GHH1jP/ALKT9KX+xx/0 Eb//AL//AP1qQ6Sqgs2pX4A5JNx0/SgC1aX1rfIWtplk28MBwyn0IPIP1qxXLXFlZ306tZS6jfTx n5Z4rkxonsZB1HsM/Soz4e1pFb7Zq15qEDjBt4bjyXXn+8AN/p/DQBvz6tbRSmCEPdXA6wwDcV/3 j0X8SKj8jU73/j5nFlEf+WVud0h+rkcfgPxqjp9pp7gWlvf31tIg/wCPZ5PLcf8AAcc/UZq//Y4/ 6CN//wB//wD61AFm0sLWxDC3hVC3LP1Zvqx5P41YrO/scf8AQRv/APv/AP8A1qP7HH/QRv8A/v8A /wD1qAHadhLvUYvS43f99Ip/nmr9YMGkhdZu4/7QvxuiikB8/rywPb2FXf7HH/QRv/8Av/8A/WoA 0aKzv7HH/QRv/wDv/wD/AFqP7HH/AEEb/wD7/wD/ANagDRorO/scf9BG/wD+/wD/APWqpdwQWrrD /aGozXDjKQRTZdvf2HucCgDb6VnNqUt2xi0uNZcHDXL/AOqX6f3z7Dj3FUk8Oz3isdS1G9EbYxbR 3BKj/ebALH26exq6NGVQFXUL4ADAAnwB+lAE1rpscEv2iZ2ubojBmk6geijoo9h+Oaj1bLCziH/L S7j/APHct/7LSf2OP+gjf/8Af/8A+tVG70onVLCIahfkZkkP7/phcen+1QBv0Vnf2OP+gjf/APf/ AP8ArUf2OP8AoI3/AP3/AP8A61AGjRWd/Y4/6CN//wB//wD61H9jj/oI3/8A3/8A/rUAaNFZ39jj /oI3/wD3/wD/AK1H9jj/AKCN/wD9/wD/AOtQBoYorP8A7HH/AEEb/wD7/wD/ANaj+xx/0Eb/AP7/ AP8A9agDQwOOBx0oxWf/AGOP+gjf/wDf/wD+tR/Y4/6CN/8A9/8A/wCtQBoYHpRgZzis/wDscf8A QRv/APv/AP8A1qP7HH/QRv8A/v8A/wD1qALNlY29hA0Num1XkeRskkszEsxJPqTU+AO1Z/8AY4/6 CN//AN//AP61H9jj/oI3/wD3/wD/AK1AGjRWd/Y4/wCgjf8A/f8A/wDrVoAYAHXHrQAtFFFABRVa 6v7eyaNZmfdLnYqRs5OOvCgmof7YtP7l3/4Bzf8AxNAF+kZgilicADJqj/bFp/cu/wDwDm/+JrP1 3VWfSZm0+K8kuEUssQtJR5vBBXle4PHvigC/o0QOg2qOOJIQzD/eGT/Om6ZdRwaHA91KkSwr5Ts7 ADKkr/Sud0PXtTls1guYprGVhkJLZSs0CAABVVV5xjJLHqTxirelPpsF5dmdby6njnLpJNaSsVDA NkDbheS3QCgDX/tG5vONNtCyn/l4uMpH+A+835Ae9KNIWch9Sne9bOdjDbEPog4P/As07+2LT+5d /wDgHN/8TVi0vIL2IywMWUMVO5CpBHUEEAigCYAKoVQAAMADtS0UUAQXVnbXsfl3MKSqORuHIPqD 2P0qp9kv7LmyuvtEf/PC6JJH0k6/mDV25uYbOBp52KxrgEhSTycDgcnkiqv9sWn9y7/8A5v/AImg BItXg8xYbxHspmOAs/Csf9lvun88+1aFZ0mqWE0bRyw3MiMMMrWMpB/DbVDzIbXnTJ72AD/lhJZT SRH6DblfwOPagDQYbPEMbf8APW1Yf98sv/xVaFcPc6trE3iK2iaxvEtXDbrqO2kK24wNwB2gndtG MjIJPbFdT/bFp/cu/wDwDm/+JoAv1HPPFbQtNPIscajJZjgCsy719YgqWtneTSPwC1pKqJ7sdv8A IE1DDNaGZbm+a7urhTlc2UwjiP8Asrt4+pyfegC1597qXFqGtLY/8t5F/eOP9hT0+rflVu0sbeyR hCmGc5d2O5nPqxPJplvqVtdT+RGZRJtLhZIXjyAQCRuAz1H51aJwMmgBaKz01uykRZI/tLowBVlt JSCPUHbS/wBsWn9y7/8AAOb/AOJoAv1nsS/iFB2itGP/AH04/wDiKX+2LT+5d/8AgHN/8TVODU4R q13O8N4EaONI2+xy843E/wAPq1AG3RVD+2LT+5d/+Ac3/wATR/bFp/cu/wDwDm/+JoAv0VQ/ti0/ uXf/AIBzf/E0q6xZtIkZM6GRgimS2kQEnoMlQKAL1FFFABRRXPeJLyGy1nw/Nc3KW8P2uUO8kgRf 9RJjJPHWgDoaK4a48Y3J8aW9lZ3cUtjLcpbMmIx96PduX5t7dQd23b296bL4v1iPT751iie40iBk vflwpnMm1TyeF2AyH2YcijoB3dFcHZeIPEF5ZW0AvbNJrjURbLdDypjsMTOcrGxUMCvHPTGRRaeK 9ck8Sz2xW3kggmlga3MkSyMEUkMF3byzEA424w340Ad3uG7bkZxnFLXCeF9Tm1XxXaXNxq1pfyS6 Q8pS3QL9nLSRkoeTnHTnB4Oa7ugAooooAKKKKAM67/5Dunf7k38lpup+ItJ0aeKC/uxDLMpZECMx IBwThQeORTrv/kO6d/uTfyWszVNHutQ8YWtxHc3lnBFYurT2zKu5vMQhDkHsCfwo6gdGDkZFLXGb NXTV/sJsr4qNZ+1faQw8ryCvTOc9eNuKrWGiazapa3Nt9sjv7iG9SdppmZQckw5BJAwcYwKOlw8j s9Q1Gy0qze8v7mO2gT70kjYFVRNHDrMkxdVhntBJvY4HyMcnP0cVy3kLF4L1GGDQNZ+1zQ+UUnzK 7zmNgXXLHjJ5YYHNakmo4XSZJtJvhH5DrIskI/u48srn7xKggdMUdwN+w1C01S0W7sZ0uIHJCyIe DgkH9Qar6P0vv+vyT+lZ/gyWY6VNDPYXdm6XUzgXMWzcryMy45PYjNaGj9L7/r8k/pQBo0UUUAZ+ t/8AIN/7bw/+jVrQrP1v/kG/9t4f/Rq1oUAZlt4i0m81STTLe7El3EzK6BGwpXqN2MZH1rTrjbfw /qZ07xA6XV7FPdS3gt7UyKsR3E7HHGQT1zmq90usava3zxWGqWYkt7OJA7eXISsxMhXDcfKevegH od1VSXVLGDUINPkuo1u7gExQ7vmYAZJx6YBrkrzSLuzguLRLXUbjSI9SDtbwzMZHhMI4UltxUSnJ GfWprqQ22p+HjbaHqhjtyXkbyvMZEaN0VXbcSSCwzycCgDpNU1rTtFhSXUbpbdHOFJBOcdeB2HrV uKWOaJJYnWSN1DK6nIYHoQa53xDrGojTzBZaRqG+eaS3eZIBIYoxwZAued38P5npg7OkRww6PZw2 8EsEMcKJHFMMOigYAYetADJf+Q/a/wDXrN/6FFV2T/VN/umqUv8AyH7X/r1m/wDQ4quyf6pv900A VNF/5Adh/wBe0f8A6CKhvfEWk6fqMenXV2EupApWIIzHDEgHgHGSD19Km0X/AJAdh/17R/8AoIrJ k0e6ufG0999qvbW3S1twPJZQk7K8hKtkEnAI6Y+9R1DodHRXFWKawL2ysZbG+X7Hc3bTXDN+6dXE hjwd2W+8vbjFVLXQtbstKH2E363d1ov+kGW4ZibgFOAWOFfaXAIwOnpQM7XUNUsdKhWa/uordGYI pkbG5icAD1p97e22nWj3d3MsUMf3nP5D61xepQxL4Omt9M8PawHmmAjimQySKQVLN8zEqpxjrya6 K91OWfT5wmm6rGDAjh4I0Eo3EghQT99cZIx3GM0CRoadqVnq1ot3YXCzwsSAy9iDggg8gj0NQaz/ AKu0/wCvyH/0KqHg21urTSp1uYZ4xJdSSRG5AE7q2DukxxuJz+GKv6z/AKu0/wCvyH/0KgDRoooo AKhuba2uowl1BFMgOQsqBhn8amrk/G9i+pXehWaQ2kzSXcn7u8jLxHELnlQRn296AOlWytFdZEtY Q6qFVhGMgDoAfQVHaabbWT3ckYLNeTGWYuc7jgLj6AADFcnqHiCbw+l/pjXNraTQW1r9hgSMKrEk q+xTyVyPfFTNq2srrMk329DZx6wlh9l8heUZFOS3XILcduOc0+odDq4rO1gRY4baKNEbcqogAB9R jvR9mtvtJufIi8/G3zdg349M9a891DV77U/DeoTN4lEF0jb5rCGJA9mqzAHJ+8AB1Ldeo4q7c61c 2ct+1vfweWzWUb6p5SHajqczNgbT2xn5Rn0pAdtFa28DFoYIo2YkkogBJPWpa4e21nWL4Wlna6zH Ik2oy2yakluh8+JYS+5R93IYFcjjjpUR8UajHFo0l3qkMfmM0c8UMaGW4YTeWCEbkqQDnZyM56UA d7RRRQAUUUUAZWpzx2uq2FxNuWJVlUsELAEhcdB7GpP7e03/AJ+G/wC/T/4Vo0UAZ39vab/z8N/3 6f8Awo/t7Tf+fhv+/T/4Vo0UAZ39vab/AM/Df9+n/wAKo6xrmnNpzyJOS8LJMP3T/wALBj29Aa36 juIRcW0sLdJEKn8RigCl/b+mf8/Df9+n/wAKbobiWC6lUNskupGQspXIz15qfSJjcaTayMSXMShs /wB4DB/UGrlABRRUNzdQWcJmuJVjQHGT3PoB3PsKAKuucaWzYYhZYmO1SSAJFJOB7Cox4k0hpWiW 8BkTG5BGxK56ZGOKXN/qfTfYWp7kfvpB/wCyD9fpV22tYLOLyoIwi5ye5J9STyT7mgCp/b2m/wDP w3/fp/8ACj+3tN/5+G/79P8A4Vo0UAZ39vab/wA/Df8Afp/8KP7e03/n4b/v0/8AhWjRQBnf29pv /Pw3/fp/8KP7e03/AJ+G/wC/T/4Vo0UAZMN7Bfa7A9szOsdtKGPlsACWjxyR7H8q1JATGwHXBp1F AGJpes2EGk2cMsrpJHAispifIIUAjpVr+3tN/wCfhv8Av0/+FaNFAGa3iDS1Us1yVUDJJicAfpQP EGmMARckg8giJ+f0p+tuU0S8I6tEyD6nj+tXVUIgUdAMUAUP7e03/n4b/v0/+FH9vab/AM/Df9+n /wAK0aKAM7+3tN/5+G/79P8A4VVvtTtL5rSG2d5JPtUTYETDgNknpW3RQAUUUUAFIQCQSASOntS0 UANZEYgsqkjgEijYv90dc9O9OooAZ5ceWOxcvwxx1+tHloFKhF2kYIxxj0p9FADQiKFAVQF6ADpS eXHlTsXK/dOOn0p9FABRRRQBWSO8GzfcwthjvxCRuHYD5uP1z7UJHegR77mFsBt+ICNx7Y+bjH45 9qs0UAVhHe4XdcwkhCDiAjLdj97p7frR5d7j/j5hz5eP9Qfv/wB773T2/WpJ7mC2UNPPHEpOAZGC g/nUP9q6d/0ELX/v8v8AjQA5o70httzCCUAXMBOG7n73I9v1oeO9PmbLmFchdmYCdp75+bnP4Y96 b/aunf8AQQtf+/y/40f2rp3/AEELX/v8v+NAD2jvCX2XMSgsCmYSdo7g/Nz9eMe9BjvMnFzEB5gI /cnhP7v3uvv+lM/tXTv+gha/9/l/xo/tXTv+gha/9/l/xoAp6Ul2n2m38+ICC9fI8o8o2HA+91+b r+lX1jvAU3XMRAYlsQkZXsB83B9+fpXF6h4zh0fxItpJPbo14yu0iuGjdFDA7TnAYjaMEjBHpW5H eWmrIJb7VbMWzcrbQXKlWH+24PzfQYH1oAnF/f3EiQ6fJBdMhYTTeSVhHpg7jkj0GfcrUltpNxFO t1cXkd1chWHmyQ/dJ6bBuwoHcdT61YTUtLjRUjvbREUYCrKoAH507+1dO/6CFr/3+X/GgB3l3uB/ pMOfLx/qD9/+997p7frQY73Bxcwg+WAP3B4fufvdPb9ab/aunf8AQQtf+/y/40f2rp3/AEELX/v8 v+NADnjvSH2XMKkqNmYCdp7k/Nzn8Me9Dx3h8zZcwrkjZmEnaO+fm5z+GPepILmC5UtBPHKoOCY2 DAflUtAFdo7wlttzEAXBXMJOF7j73J9/0o8u83f8fEWPNzjyT9z+797r7/pViigCusd4Cu65iIDk tiEjK9h97g+/6UiR3g8vfcwtgtvxCRuHbHzcY/HPtVmoZ7y1tiBcXMURboJHC5/OgBix3oCbrmEk KQ+ICNx7EfNxj05z7UCO9wM3MJPlkH9weX7H73T2/Wm/2rp3/QQtf+/y/wCNH9q6d/0ELX/v8v8A jQA7y73B/wBJhz5YA/cH7/8Ae+909v1oaO9IfbcwglQFzAThu5Pzcg+nb1NN/tXTv+gha/8Af5f8 aP7V07/oIWv/AH+X/GgCnrSXTWwi+0RYnuIEQeSTt+cFs/NznHtV9o7wl9tzEAXBXMJOF7g/Nyff j6Vz2t64kerWEEE9tOkrl4j5q7UdVbO854XkH/gJHUit1dV0/aN2oWpOOSJV/wAaAJDHeZOLiLHm 5H7k/c/u/e6+/wClAjvMjNzER5hJ/cnlOy/e6+/6Uz+1dO/6CFr/AN/l/wAaP7V07/oIWv8A3+X/ ABoAekd4DHvuYmAY78Qkbh2A+bjH459qRI70CPfcwsQG34gI3Htj5uMfjn2pv9q6d/0ELX/v8v8A jTo9RsZpBHFeW7u3RVlUk/hmgAEd6Au65hJ2EHEBGW7H73T2/Wjy73H/AB8w58vH+oP3/wC997p7 frVmigCs0d6Q226hBKALmAnDdz97ke361OgcD52DH2GKdRQAUUUUAFFFFABRRRQAUUUUAFFFFAGZ fRpLrenLIiuNk3DDPZau/Y7X/n2i/wC+BVS7/wCQ7p3+5N/Ja0aAIfsdr/z7Rf8AfAo+x2v/AD7R f98CpqQ9KAKsSadMxSJbWRl6hQpIqX7Ha/8APtF/3wK8+0G2u9C8ER6xELKHcIWZ7ex2TLF5o8wy Nk7/AJc54HrWlJrl9qshXTNSkjt59YS3juI4QcQm33Nt3DH3gcNz+NOwPQ7AWtuBgQRD/gAqPybE ymLy7cyAZKbVzj1xXGTa1fRW1lBqWuzafAHu45NQWBN0rxybY1OVKglcngc44xTxdaDd+O7aK3e0 t72zlLTzldk91K0ZHljuVAOTnjIAHQ4QHYtbWa43QQDJwMoOTTvsdr/z7Rf98CuP8VaxoEjaBqb3 kQY3kckTuWGIgTuYKenbJxXaqwdQynKkZBHejoHUi+x2v/PtF/3wKPsdr/z7Rf8AfAqaigDMsY0i 1vUVjRUGyHhRjs1adZ1p/wAhzUf9yH+TVo0AFFFFABWYYYpfEcnmRo+LRMblBx87Vp1nJ/yMcv8A 15p/6G1AFv7Ha/8APtF/3wKPsdr/AM+0X/fAqaigCoi6dLIY41tXdeqqFJH4VL9jtf8An2i/74Fe f6VZX2leFdR1q0SzSXdOUeGxxcgC4Jbc+TvG0Hjb6elX7nxDealPc/2RqTC2fULSCGdIgwVHHzlc jn68jNAdTsfslt/z7xf98CmeTY+b5XlW/mEZ2bVzj1xXGT6zqFtBFa6hrc1nax31zBLqQhTeQgBj UkqVBOTzt52470XN3oN74v062Wa1jv7eSKae9kQRzTsUwka8ZO4EFh0AwOp4AOzeGxi2iSK3TccL uVRk+gp/2O1/59ov++BXGeMtW8N6hp8EExs3nvlligurqPC2yg7XcEjIII4A5Jx2ya7O1KG0hMUn mxmNdshOdwxwfxoAPsdr/wA+0X/fAqhq1tBGtmyQxqwvIuQgB+9WrWdrP+rtP+vyH/0KgDRooooA KKKKACiiigAooooAKKKKACiiigAooooAzL50j1vTi7qo2Tcscdlq99pt/wDnvH/32KJ7W3ulC3EE UwU5AkQNj86g/sjTP+gdaf8Afhf8KAJ/tNv/AM94/wDvsUfabf8A57x/99ioP7I0z/oHWn/fhf8A Cj+yNM/6B1p/34X/AAoAn+02/wDz3j/77FH2m3/57x/99ioP7I0z/oHWn/fhf8KP7I0z/oHWn/fh f8KAJ/tNv/z3j/77FH2m3/57x/8AfYqD+yNM/wCgdaf9+F/wo/sjTP8AoHWn/fhf8KAJ/tNv/wA9 4/8AvsUfabf/AJ7x/wDfYqD+yNM/6B1p/wB+F/wo/sjTP+gdaf8Afhf8KAJ/tNv/AM94/wDvsUfa bf8A57x/99ioP7I0z/oHWn/fhf8ACj+yNM/6B1p/34X/AAoAgsnSTW9RKOrDZDypz2atOooLW3tV K28EUIY5IjQLn8qloAKKKKACszzY4/Ecu+RVzZpjccfxtWnUE9laXTBri1hmKjAMkYbH50AO+02/ /PeP/vsUfabf/nvH/wB9ioP7I0z/AKB1p/34X/Cj+yNM/wCgdaf9+F/woAn+02//AD3j/wC+xR9p t/8AnvH/AN9ioP7I0z/oHWn/AH4X/Cj+yNM/6B1p/wB+F/woAn+02/8Az3j/AO+xR9pt/wDnvH/3 2Kg/sjTP+gdaf9+F/wAKP7I0z/oHWn/fhf8ACgCf7Tb/APPeP/vsUfabf/nvH/32Kg/sjTP+gdaf 9+F/wo/sjTP+gdaf9+F/woAn+02//PeP/vsVQ1eeF0tFWVGP2yLgMP71WP7I0z/oHWn/AH4X/CnR 6ZYQyLJFY2yOvIZYlBH44oAtUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB/9k= --_004_8D15A2BAF93E9C49AB037A0647E5FA643F84C6C3eusaamb105erics_-- From nobody Wed Jun 3 08:53:49 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF8B1A90E6 for ; Wed, 3 Jun 2015 08:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.04 X-Spam-Level: **** X-Spam-Status: No, score=4.04 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROxup6QMNhCs for ; Wed, 3 Jun 2015 08:53:44 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [58.251.152.64]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E881A1A90EA for ; Wed, 3 Jun 2015 08:53:41 -0700 (PDT) Received: from 172.24.2.119 (EHLO nkgeml404-hub.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id COZ26008; Wed, 03 Jun 2015 23:53:12 +0800 (CST) Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.7]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Wed, 3 Jun 2015 23:53:02 +0800 From: Xiayinben To: Dave Hood , Zhoutianran , STUART VENTERS , "Natale, Bob" Thread-Topic: role based intent Thread-Index: AdCdxq4VFvGDpUDvRK6YJXpiQnECmwANkqOQAAXMRWA= Date: Wed, 3 Jun 2015 15:53:02 +0000 Message-ID: <5FD31D8EDBF4EC468B36D86F04FDB2E873828241@nkgeml507-mbs.china.huawei.com> References: <8D15A2BAF93E9C49AB037A0647E5FA643F84C6C3@eusaamb105.ericsson.se> In-Reply-To: <8D15A2BAF93E9C49AB037A0647E5FA643F84C6C3@eusaamb105.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.45.22.0] Content-Type: multipart/related; boundary="_004_5FD31D8EDBF4EC468B36D86F04FDB2E873828241nkgeml507mbschi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "sdn@irtf.org" , "ibnemo@ietf.org" Subject: [Sdn] =?gb2312?b?tPC4tDogcm9sZSBiYXNlZCBpbnRlbnQ=?= X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 15:53:47 -0000 --_004_5FD31D8EDBF4EC468B36D86F04FDB2E873828241nkgeml507mbschi_ Content-Type: multipart/alternative; boundary="_000_5FD31D8EDBF4EC468B36D86F04FDB2E873828241nkgeml507mbschi_" --_000_5FD31D8EDBF4EC468B36D86F04FDB2E873828241nkgeml507mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgRGF2ZSwNCg0KSSB0aGluayB0aGUgbWVhbmluZyBvZiChrm9uZSBpbnRlbnQgbGF5ZXKhryBp cyB0aGF0IGVhY2ggcm9sZSBoYXMgb25lIGludGVudCBsYXllciBidXQgbm90IGFsbCByb2xlcyBo YXZlIG9uZSBpbnRlbnQgbGF5ZXIuDQpBbmQgd2UgZG9uoa90IG5lZWQgY2FyZSBhYm91dCB0aGUg bGF5ZXIgcmVsYXRpb25zaGlwIGJldHdlZW4gZGlmZmVyZW50IHJvbGWhr3MgaW50ZW50LiBTbyAg aW4gZ2VuZXJhbCwgdGhlcmUgaXMgb25seSBvbmUgaW50ZW50IGxheWVyLg0KRG8geW91IHRoaW5r IHRoaXMgaXMgYWNjZXB0YWJsZT8NCg0KWWluYmVuDQoNCreivP7IyzogSWJuZW1vIFttYWlsdG86 aWJuZW1vLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gRGF2ZSBIb29kDQq3osvNyrG85DogMjAxNcTq NtTCM8jVIDIxOjAzDQrK1bz+yMs6IFpob3V0aWFucmFuOyBTVFVBUlQgVkVOVEVSUzsgTmF0YWxl LCBCb2INCrOty806IHNkbkBpcnRmLm9yZzsgaWJuZW1vQGlldGYub3JnDQrW98ziOiBSZTogW0li bmVtb10gcm9sZSBiYXNlZCBpbnRlbnQNCg0KTGF5ZXJpbmcgaXMgdGhlIHJpZ2h0IGlzc3VlLCBi dXQgdGhlIHBvaW50IGlzIGEgbGl0dGxlIGRpZmZlcmVudC4gV2UsIHdobyBsb29rIGF0IHRoZSBn bG9iYWwgc2NlbmFyaW8gZnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgdGhlIGdvZHMsIHNlZSB0aGF0 IHRoZXJlIGlzIGEgcmVjdXJzaW9uIG9mIGNsaWVudHMvc2VydmVycyBvciBjdXN0b21lcnMvcHJv dmlkZXJzIG9yIKGtLg0KDQpCdXQgZnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgYW55IG9uZSBvZiB0 aG9zZSBpbnRlcmZhY2VzLCB0aGUgb3RoZXIgbGF5ZXJzIGFyZSBjb21wbGV0ZWx5IGludmlzaWJs ZS4gU28gYSBnaXZlbiBhcHAgY2FuIGludm9rZSBpbnRlbnQgYWdhaW5zdCBhIGdpdmVuIFNETiBj b250cm9sbGVyLCBidXQgdGhlIGNvbnRyb2xsZXIgZG9lc26hr3Qga25vdyB3aGV0aGVyIHRoZSBh cHAgaXMganVzdCBhIG1pZGRsZW1hbiwgYW5kIHRoZSBhcHAgZG9lc26hr3Qga25vdyB3aGV0aGVy IHRoZSBjb250cm9sbGVyIGNhbiBzYXRpc2Z5IGl0cyByZXF1aXJlbWVudHMgZGlyZWN0bHkgb3Ig d2hldGhlciBpdCBpcyBhbHNvIGp1c3QgYSBtaWRkbGVtYW4uDQoNCllvdSBjYW4gaGF2ZSBvbmUg aW50ZW50IGxheWVyLCBhcyBsb25nIGFzIHlvdSByZWNvZ25pemUgdGhhdCB5b3UgYXJlIG9ubHkg c2VlaW5nIG9uZSBzbGljZSBvZiB0aGUgd29ybGQuIElmIHlvdSBpbnNpc3Qgb24gb25seSBvbmUg bm9ydGhlcm5tb3N0IGludGVudCBsYXllciBpbiB0b3RvLCB5b3Ugd2lsbCBoYXZlIHRvIGdvIGJh Y2sgdG8gdGhlIKGwbWFrZSBtb25leaGxIGludGVudCBvZiB0aGUgaW52ZXN0b3JzLg0KDQpBbmQg aWYgd2UgcmVjb2duaXplIHRoYXQgZWFjaCBpbnRlcmZhY2Ugc3RhbmRzIG9uIGl0cyBvd24sIHRo ZW4gYW55IHNlcnZpY2UgaW52b2NhdGlvbiBhY3Jvc3MgdGhhdCBpbnRlcmZhY2UgcXVhbGlmaWVz IGFzIGFuIGV4cHJlc3Npb24gYW5kIHNhdGlzZmFjdGlvbiBvZiBpbnRlbnQgYnkgdGhhdCBwYXJ0 aWN1bGFyIGludm9rZXItcHJvdmlkZXIgcGFpci4NCg0KRGF2ZQ0KDQpGcm9tOiBaaG91dGlhbnJh biBbbWFpbHRvOnpob3V0aWFucmFuQGh1YXdlaS5jb21dDQpTZW50OiBUdWVzZGF5LCBKdW5lIDAy LCAyMDE1IDExOjMwIFBNDQpUbzogRGF2ZSBIb29kOyBTVFVBUlQgVkVOVEVSUzsgTmF0YWxlLCBC b2INCkNjOiBpYm5lbW9AaWV0Zi5vcmc8bWFpbHRvOmlibmVtb0BpZXRmLm9yZz47IHNkbkBpcnRm Lm9yZzxtYWlsdG86c2RuQGlydGYub3JnPg0KU3ViamVjdDogcm9sZSBiYXNlZCBpbnRlbnQNCg0K DQpIaSBEYXZlLCBTdHVhcnQsIEJvYiBhbmQgYWxsLA0KDQoNCg0KSSBmb3VuZCBtYW55IHByb2Js ZW1zIHJhaXNlZCBpbiB0aGUgbWFpbGluZyBsaXN0IGFyZSBjb3Vyc2VkIGJ5IHRoZSBsYXllcmVk IGludGVudCB0aGlua2luZy4gTWF5YmUgd2UgYXJlIHRhaW50ZWQgYnkgdGhlIElTTyBtb2RlbDot KQ0KDQoNCg0KRm9yIHRoZSBsYXllcmVkIGludGVudCwgaW50ZW50IGlzIGEgc3BlY3RydW0sIHZl cnkgYWJzdHJhY3QgYXQgdGhlIHRvcCBsYXllciwgbW9yZSBuZXR3b3JrIHNwZWNpZmljIGFuZCBs ZXNzIGFic3RyYWN0IHdoZW4gdGhlIGxheWVyIGdvZXMgZG93bi4gVGhlIHByb2JsZW0gaXMgdGhh dCB0aGUgYm91bmRhcnkgb2YgaW50ZW50IGFuZCBub24gaW50ZW50IGlzIHZhZ3VlLiBPciB0aGVy ZSBpcyBubyBib3VuZGFyeSBiZXR3ZWVuIHRoaXMgdHdvLCBzaW5jZSBvbmUncyB3aGF0IG1heSBi ZSBhbm90aGVyIG9uZSdzIGhvdy4gQW5kIGNvbnNlcXVlbnRseSwgaXQgbG9va3MgbGlrZSBldmVy eXRoaW5nIGlzIGludGVudCBhbmQgbm8gY2xlYXIgaW50ZW50IGRlZmluaXRpb24uDQoNCg0KDQpU aGUgcm9sZSBiYXNlZCBpbnRlbnQgd2lsbCBwcm92aWRlIG9ubHkgb25lIGludGVudCBsYXllci4g VGhhdCBpcyBhbHdheXMgdGhlIHRvcCBsYXllciBhYnN0cmFjdGlvbiBmb3IgZWFjaCByb2xlLCBh cyBzaG93biBpbiB0aGUgZm9sbG93aW5nIGZpZ3VyZS4gVGhlIGZ1bmN0aW9ucyBjYW4gYmUgbGF5 ZXJlZCBhcyB0aGUgaW1wbGVtZW50YXRpb24gb2YgdGhlIGludGVudCBsYXllci4NCg0KW2NpZDpp bWFnZTAwMS5qcGdAMDFEMDlFNTcuRDkzN0NBQzBdDQoNCldpdGggdGhlIHJvbGUgYmFzZWQgaW50 ZW50LCBhbHRob3VnaCB0aGUgZW5kIHVzZXIncyBpbnRlbnQgaXMgbXVjaCBhYnN0cmFjdGVkIHRo ZW4gdGhlIG5ldHdvcmsgYWRtaW5pc3RyYXRvcidzIGludGVudCwgdGhleSBhcmUgbm90IHJlbGF0 ZWQgZWFjaCBvdGhlci4gSS5lLiwgdGhlIGVuZCB1c2VyIHdpbGwgbm90IHVzZSB0aGUgYWRtaW5p c3RyYXRvcidzIGludGVudC4gQW5kIHRoZSBhZG1pbiB3aWxsIG5vdCBwcm92aWRlIGFkZGl0aW9u YWwgc2VydmljZXMvaW50ZXJmYWNlcyB0byB0aGUgZW5kIHVzZXIuDQoNCg0KDQpUaGUgZXNzZW50 aWFsIG9mIGxheWVyaW5nIGlzIHRoYXQgdGhlIGxvd2VyIGxheWVyIHdpbGwgcHJvdmlkZSBpbnRl cmZhY2UgdG8gdGhlIGhpZ2hlciBsYXllci4gSW4gb3JkZXIgdG8gZml0IHVwIGxheWVyIHJlcXVp cmVtZW50cywgdGhlIGxvd2VyIGxheWVyIHdpbGwgcHJvdmlkZSBhZGVxdWF0ZSBpbnRlcmZhY2Vz L2NhcGFiaWxpdGllcy4gVGhhdCBhbHNvIG1lYW5zIHRvbyBtdWNoIGluZm9ybWF0aW9uIGZvciBh IGRlZGljYXRlZCB1cCBsYXllciB1c2VyL2FwcC4NCg0KDQoNCkZvciByb2xlIGJhc2VkIGludGVu dCwgd2UgY2FuIGZpcnN0bHkgaW5kZW50aWZ5IHZhcmlvdXMgcm9sZXMgKG5vIG5lZWQgdG8gYmUg Y29tcGxldGUsIGJ1dCB0aG9zZSB3aXRoIGF0dGVudGlvbiksIGFuZCB0aGVuIGZpZ3VyZSBvdXQg dGhlIGludGVudCBvZiBlYWNoIHJvbGUuIEluIHRoaXMgd2F5LCBpbnRlbnQgY2FuIGJlIGNsZWFy IGRlZmluZWQuIFRoYXQgd2lsbCBhbHNvIGtlZXAgdGhlIGludGVudCBvZiBlYWNoIHJvbGUgdG8g YSBzbWFsbCBzZXQgb24gd2hhdCB0aGV5IHJlYWxseSBjYXJlcyBhYm91dCwgd2l0aG91dCBleHBl bmRpbmcgdG8gc3VwcG9ydCBvdGhlciBvbmWhr3MgaW50ZW50Lg0KDQoNCg0KDQoNCkJlc3QgUmVn YXJkcywNCg0KVGVyZW5jZQ0KDQoNCg0KDQo= --_000_5FD31D8EDBF4EC468B36D86F04FDB2E873828241nkgeml507mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Dave= ,

&n= bsp;

I think= the meaning of =A1=AEone intent layer=A1=AF is that each role has one inte= nt layer but not all roles have one intent layer.

And we = don=A1=AFt need care about the layer relationship between different role=A1= =AFs intent. So  in general, there is only one intent layer.

Do you = think this is acceptable?

&n= bsp;

Yinben<= o:p>

&n= bsp;

=B7=A2=BC=FE=C8=CB: Ibnemo [mailto:ibnemo-bounces@ietf.org] =B4=FA= =B1=ED Dave Hood
=B7=A2= =CB=CD=CA=B1=BC=E4: 2015=C4=EA6=D4=C23=C8=D5 21:03
=CA=D5=BC=FE=C8=CB: Zhoutianran; STUART VENTERS; Natale, Bob
=B3=AD=CB=CD: sdn@irtf.org; ibnemo@ietf.org
=D6=F7=CC=E2: Re: [Ibnemo] role based intent

 

Layer= ing is the right issue, but the point is a little different. We, who look a= t the global scenario from the perspective of the gods, see that there is a recursion of clients/servers or customers/providers or =A1= =AD.

=  

But f= rom the perspective of any one of those interfaces, the other layers are co= mpletely invisible. So a given app can invoke intent against a given SDN controller, but the controller doesn=A1=AFt know whether the a= pp is just a middleman, and the app doesn=A1=AFt know whether the controlle= r can satisfy its requirements directly or whether it is also just a middle= man.

=  

You c= an have one intent layer, as long as you recognize that you are only seeing= one slice of the world. If you insist on only one northernmost intent layer in toto, you will have to go back to the =A1=B0make money=A1= =B1 intent of the investors.

=  

And i= f we recognize that each interface stands on its own, then any service invo= cation across that interface qualifies as an expression and satisfaction of intent by that particular invoker-provider pair.

=  

Dave<= o:p>

=  

 

Hi Dave, Stuart, Bob and all,

 

I found many problems raised in the mailing list are cour= sed by the layered intent thinking. Maybe we are tainted by the ISO model:-= )

 

For the layered intent, intent is a spectrum, very abstra= ct at the top layer, more network specific and less abstract when the layer= goes down. The problem is that the boundary of intent and non intent is vague. Or there is no boundary between this two, = since one's what may be another one's how. And consequently, it looks like = everything is intent and no clear intent definition.

 

The role based intent will provide only one intent layer. That is always the top layer abs= traction for each role, as shown in the following figure. The funct= ions can be layered as the implementation of the intent layer.

With the role based intent, although the end user's inten= t is much abstracted then the network administrator's intent, they are not = related each other. I.e., the end user will not use the administrator's intent. And the admin will not provide additional = services/interfaces to the end user.

 

The essential of layering is that the lower layer will pr= ovide interface to the higher layer. In order to fit up layer requirements,= the lower layer will provide adequate interfaces/capabilities. That also means too much information for a dedicated up laye= r user/app.

 

For role based intent, we can firstly indentify various r= oles (no need to be complete, but those with attention), and then figure ou= t the intent of each role. In this way, intent can be clear defined. That will also keep the intent of each role to a small s= et on what they really cares about, without expending to support other one= =A1=AFs intent.

 

 

Best Regards,

Terence

 

 

--_000_5FD31D8EDBF4EC468B36D86F04FDB2E873828241nkgeml507mbschi_-- --_004_5FD31D8EDBF4EC468B36D86F04FDB2E873828241nkgeml507mbschi_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=9164; creation-date="Wed, 03 Jun 2015 15:53:01 GMT"; modification-date="Wed, 03 Jun 2015 15:53:01 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCACPAUoDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2aiii gDK1OCO61bT4J13xFZSUJOCQFwf1NTf2Hpn/AD5x/rTbv/kO6d/uTfyWtGgCh/Yemf8APnH+tH9h 6Z/z5x/rUfiLU5tH0K5v7eFJpYgu1HbAYlgOT261h3viXXLH7aWt9OcaTEkl8N7qZd2TiLPT5R1b qeOKAOg/sPTP+fOP9aP7D0z/AJ84/wBa5e48RXuky6ilrBJd3F1qxhhVlaQRgQI5+UcnoeBjqTVm 8v8AU7vTdD1KVrnTZXv4Yp7MfKGzJtO7jOCBwPfmhagzf/sPTP8Anzj/AFo/sPTP+fOP9av0UAZm iIsSXsSDEcd26ouchRgcCtOs7SPv6h/1+P8AyWtGgDHjsba91nUDcxCXyzGF3E/KNgPFWf7D0z/n zj/Wm2P/ACGNT/34/wD0AVo0AUP7D0z/AJ84/wBaP7D0z/nzj/Wqeq6rqFvrdnp9lFbsksMk80kx bKojICFA6k7uKwp/E+qXWjyPcw2scGqaZcXFm1tKxlh2pkb+2cMORjBGKAOp/sPTP+fOP9aP7D0z /nzj/WuYXxbqkWoW+n2elyXcNvHbrcOI2ZmLqpJDdFwDnnrg9K0LSOY+MmNjqF7cW0SyfbxNLvhV zjYiDoGHJOOgxnk07ah0Nf8AsPTP+fOP9aiu9F01LOZltEBEbEEZ44rUqC9/48Z/+uTfypAM0xi2 lWjMSzGBCSTkn5RViQ4jYj0NVtL/AOQTZ/8AXBP/AEEVZk/1Tf7poAx9K0jT5tIspZbVHd7eNmZi SSSoyTVv+w9M/wCfOP8AWnaL/wAgOw/69o//AEEVdoAof2Hpn/PnH+tH9h6Z/wA+cf61iXviXVLe 51No7azNtZ3MdpEXdgzyyCPazHoqDzOepOKrT6vqM97aWF95Md1Z6tBHK9o7eXKrxswGDyPcHPY9 6FqD0Ok/sPTP+fOP9aP7D0z/AJ84/wBa5zRvFOp6/LKj6bNbWNxDIYblFMZjwcDLt8pJ9QOCO9Wv B0t6lzqtjfvdLJBJGyW9zcfaGiRk4/e/xZIY47UAbP8AYemf8+cf61U1DTrOzNpNbQLFJ9riXcpI OC2CK2qztZ/1dp/1+Q/+hUAaNFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAGdd/wDId07/AHJv 5LWjVW80+G9aN5GlR4s7HilZCM9eQfaof7Gh/wCfu+/8C5P8aALVzawXtu1vcxLLE+NyOMg4OR+o qreaFpOoXsN7eadbz3MGPLleMFlwcj8jzR/Y0P8Az933/gXJ/jR/Y0P/AD933/gXJ/jQAt1oelX1 vNBdWEE0U8olkV0B3OABu+uABmq914U0C9t7e3udJtpIrVdsCFOIx7Vkz6fczeJntYNXv4IkgGxT OzK0mcnIzn7pHQirZha041L+0I0H/LeC7lkj/EZ3L+Ix70AdAiLGiogCqoAAHYU6suHTbS5iEsF/ eSxt0ZL1yD+Oak/saH/n7vv/AALk/wAaAE0j7+of9fj/AMlrRqvZ2UNjE0cO8hmLszuXZie5JqxQ BnWP/IY1P/fj/wDQBWjVGbSbea5e48y5ikkxv8qd0DYGBwDim/2ND/z933/gXJ/jQBba2ga6S6aJ TOiFFkxyFJBI+hwPyqjb+HNFtXunt9Ltomu1KTlYwN6nqD7HPSoLuDT7JlSbUL7zW+7El1Izt9FB yagGlX179ye80+I/xSXbvKR7Lnav45+lAF+bw9o9xeQXk2m273FsFEUhjGVC/d/Lt6U228M6JZ6i dRttNgiu2ZnMqLglm+8fqcmq2l6Wslq6y3+oyPDNJGXa7fLAMQCcEDpirv8AY0P/AD933/gXJ/jQ BoVBe/8AHjP/ANcm/lVb+xof+fu+/wDAuT/GkbRYHUq11fEEYI+1yc/rQBNpf/IJs/8Argn/AKCK syf6pv8AdNJFEkMKRRjaiKFUegHSnEAjB6GgCnov/IDsP+vaP/0EVdrNj0O2ijWOO4vURAFVRdyY AHQdad/Y0P8Az933/gXJ/jQBNJplhNFdQy2kLx3hzcKyAiU4Ay3rwAPwqG10LSrK2it7bT4IooZf OjVUA2yf3vrz1qG6srKyi824v71Fzgf6XISx9AM5J9hWVf2N7JZG4iur+xj3oEBunaVyWAGckhRz 05P0oA14/DWhxT3M6aVarJdqVnPlD94D1B+vf1qxpuk6fo8DQadZxWsbNuZY1xuPqfWo/wCxof8A n7vv/AuT/Gj+xof+fu+/8C5P8aANCs7Wf9Xaf9fkP/oVL/Y0P/P3ff8AgXJ/jQujWwljd5rqXy3D qsly7LkdDgnmgDQooooATIBAyMnoKWuV8UzzWms2t1AcSwaXfujYzhgIyP1FYusTa0+galbXOsTy /wDEvtr4SpCiNGS53qMD7uFz3I55o6AeiUV55e+I9Yj163tLLV7drYJAbeS4lRft4b7zYEZ39x8h XBrQtb7WpdUjlk1Rzb3GqXNiLcQIBGiiQqwOMlgUHJ4wenegDsJJY4U3yyLGuQNzHAyTgfrT6870 8lvhv5Umoy300V7Ckqy7d0DC4TKHAB9+eefSpoPEWqXfjiTS4dQZIZpLiDynEZeAohKuEC5AyMgs x3A9B2AO+orz6bxTrs2iXV9CRCbQw2VwWUKIp937+TJU4C/KAcEDJJBxU+m6nrmpf2TanWYwtzNc B7m08uYyRoqlRuKBc5JBIXH40LUDuqKKKACis46QCc/2jf8A/f8A/wDrUf2OP+gjf/8Af/8A+tQB o0Vnf2OP+gjf/wDf/wD+tR/Y4/6CN/8A9/8A/wCtQBo0Vnf2OP8AoI3/AP3/AP8A61H9jj/oI3// AH//APrUAUScag94B93UhGT7GIJ/Mit+uU/skyeH7u5S/vi3mSzKPP6lZCV7f7IrYTSlkRXXUr8q wBB8/t+VAEk2kW7ytPbs9pcNyZYDt3H/AGh0b8RTPtOpWXF1bi7iH/La2GHH1jP/ALKT9KX+xx/0 Eb//AL//AP1qQ6Sqgs2pX4A5JNx0/SgC1aX1rfIWtplk28MBwyn0IPIP1qxXLXFlZ306tZS6jfTx n5Z4rkxonsZB1HsM/Soz4e1pFb7Zq15qEDjBt4bjyXXn+8AN/p/DQBvz6tbRSmCEPdXA6wwDcV/3 j0X8SKj8jU73/j5nFlEf+WVud0h+rkcfgPxqjp9pp7gWlvf31tIg/wCPZ5PLcf8AAcc/UZq//Y4/ 6CN//wB//wD61AFm0sLWxDC3hVC3LP1Zvqx5P41YrO/scf8AQRv/APv/AP8A1qP7HH/QRv8A/v8A /wD1qAHadhLvUYvS43f99Ip/nmr9YMGkhdZu4/7QvxuiikB8/rywPb2FXf7HH/QRv/8Av/8A/WoA 0aKzv7HH/QRv/wDv/wD/AFqP7HH/AEEb/wD7/wD/ANagDRorO/scf9BG/wD+/wD/APWqpdwQWrrD /aGozXDjKQRTZdvf2HucCgDb6VnNqUt2xi0uNZcHDXL/AOqX6f3z7Dj3FUk8Oz3isdS1G9EbYxbR 3BKj/ebALH26exq6NGVQFXUL4ADAAnwB+lAE1rpscEv2iZ2ubojBmk6geijoo9h+Oaj1bLCziH/L S7j/APHct/7LSf2OP+gjf/8Af/8A+tVG70onVLCIahfkZkkP7/phcen+1QBv0Vnf2OP+gjf/APf/ AP8ArUf2OP8AoI3/AP3/AP8A61AGjRWd/Y4/6CN//wB//wD61H9jj/oI3/8A3/8A/rUAaNFZ39jj /oI3/wD3/wD/AK1H9jj/AKCN/wD9/wD/AOtQBoYorP8A7HH/AEEb/wD7/wD/ANaj+xx/0Eb/AP7/ AP8A9agDQwOOBx0oxWf/AGOP+gjf/wDf/wD+tR/Y4/6CN/8A9/8A/wCtQBoYHpRgZzis/wDscf8A QRv/APv/AP8A1qP7HH/QRv8A/v8A/wD1qALNlY29hA0Num1XkeRskkszEsxJPqTU+AO1Z/8AY4/6 CN//AN//AP61H9jj/oI3/wD3/wD/AK1AGjRWd/Y4/wCgjf8A/f8A/wDrVoAYAHXHrQAtFFFABRVa 6v7eyaNZmfdLnYqRs5OOvCgmof7YtP7l3/4Bzf8AxNAF+kZgilicADJqj/bFp/cu/wDwDm/+JrP1 3VWfSZm0+K8kuEUssQtJR5vBBXle4PHvigC/o0QOg2qOOJIQzD/eGT/Om6ZdRwaHA91KkSwr5Ts7 ADKkr/Sud0PXtTls1guYprGVhkJLZSs0CAABVVV5xjJLHqTxirelPpsF5dmdby6njnLpJNaSsVDA NkDbheS3QCgDX/tG5vONNtCyn/l4uMpH+A+835Ae9KNIWch9Sne9bOdjDbEPog4P/As07+2LT+5d /wDgHN/8TVi0vIL2IywMWUMVO5CpBHUEEAigCYAKoVQAAMADtS0UUAQXVnbXsfl3MKSqORuHIPqD 2P0qp9kv7LmyuvtEf/PC6JJH0k6/mDV25uYbOBp52KxrgEhSTycDgcnkiqv9sWn9y7/8A5v/AImg BItXg8xYbxHspmOAs/Csf9lvun88+1aFZ0mqWE0bRyw3MiMMMrWMpB/DbVDzIbXnTJ72AD/lhJZT SRH6DblfwOPagDQYbPEMbf8APW1Yf98sv/xVaFcPc6trE3iK2iaxvEtXDbrqO2kK24wNwB2gndtG MjIJPbFdT/bFp/cu/wDwDm/+JoAv1HPPFbQtNPIscajJZjgCsy719YgqWtneTSPwC1pKqJ7sdv8A IE1DDNaGZbm+a7urhTlc2UwjiP8Asrt4+pyfegC1597qXFqGtLY/8t5F/eOP9hT0+rflVu0sbeyR hCmGc5d2O5nPqxPJplvqVtdT+RGZRJtLhZIXjyAQCRuAz1H51aJwMmgBaKz01uykRZI/tLowBVlt JSCPUHbS/wBsWn9y7/8AAOb/AOJoAv1nsS/iFB2itGP/AH04/wDiKX+2LT+5d/8AgHN/8TVODU4R q13O8N4EaONI2+xy843E/wAPq1AG3RVD+2LT+5d/+Ac3/wATR/bFp/cu/wDwDm/+JoAv0VQ/ti0/ uXf/AIBzf/E0q6xZtIkZM6GRgimS2kQEnoMlQKAL1FFFABRRXPeJLyGy1nw/Nc3KW8P2uUO8kgRf 9RJjJPHWgDoaK4a48Y3J8aW9lZ3cUtjLcpbMmIx96PduX5t7dQd23b296bL4v1iPT751iie40iBk vflwpnMm1TyeF2AyH2YcijoB3dFcHZeIPEF5ZW0AvbNJrjURbLdDypjsMTOcrGxUMCvHPTGRRaeK 9ck8Sz2xW3kggmlga3MkSyMEUkMF3byzEA424w340Ad3uG7bkZxnFLXCeF9Tm1XxXaXNxq1pfyS6 Q8pS3QL9nLSRkoeTnHTnB4Oa7ugAooooAKKKKAM67/5Dunf7k38lpup+ItJ0aeKC/uxDLMpZECMx IBwThQeORTrv/kO6d/uTfyWszVNHutQ8YWtxHc3lnBFYurT2zKu5vMQhDkHsCfwo6gdGDkZFLXGb NXTV/sJsr4qNZ+1faQw8ryCvTOc9eNuKrWGiazapa3Nt9sjv7iG9SdppmZQckw5BJAwcYwKOlw8j s9Q1Gy0qze8v7mO2gT70kjYFVRNHDrMkxdVhntBJvY4HyMcnP0cVy3kLF4L1GGDQNZ+1zQ+UUnzK 7zmNgXXLHjJ5YYHNakmo4XSZJtJvhH5DrIskI/u48srn7xKggdMUdwN+w1C01S0W7sZ0uIHJCyIe DgkH9Qar6P0vv+vyT+lZ/gyWY6VNDPYXdm6XUzgXMWzcryMy45PYjNaGj9L7/r8k/pQBo0UUUAZ+ t/8AIN/7bw/+jVrQrP1v/kG/9t4f/Rq1oUAZlt4i0m81STTLe7El3EzK6BGwpXqN2MZH1rTrjbfw /qZ07xA6XV7FPdS3gt7UyKsR3E7HHGQT1zmq90usava3zxWGqWYkt7OJA7eXISsxMhXDcfKevegH od1VSXVLGDUINPkuo1u7gExQ7vmYAZJx6YBrkrzSLuzguLRLXUbjSI9SDtbwzMZHhMI4UltxUSnJ GfWprqQ22p+HjbaHqhjtyXkbyvMZEaN0VXbcSSCwzycCgDpNU1rTtFhSXUbpbdHOFJBOcdeB2HrV uKWOaJJYnWSN1DK6nIYHoQa53xDrGojTzBZaRqG+eaS3eZIBIYoxwZAued38P5npg7OkRww6PZw2 8EsEMcKJHFMMOigYAYetADJf+Q/a/wDXrN/6FFV2T/VN/umqUv8AyH7X/r1m/wDQ4quyf6pv900A VNF/5Adh/wBe0f8A6CKhvfEWk6fqMenXV2EupApWIIzHDEgHgHGSD19Km0X/AJAdh/17R/8AoIrJ k0e6ufG0999qvbW3S1twPJZQk7K8hKtkEnAI6Y+9R1DodHRXFWKawL2ysZbG+X7Hc3bTXDN+6dXE hjwd2W+8vbjFVLXQtbstKH2E363d1ov+kGW4ZibgFOAWOFfaXAIwOnpQM7XUNUsdKhWa/uordGYI pkbG5icAD1p97e22nWj3d3MsUMf3nP5D61xepQxL4Omt9M8PawHmmAjimQySKQVLN8zEqpxjrya6 K91OWfT5wmm6rGDAjh4I0Eo3EghQT99cZIx3GM0CRoadqVnq1ot3YXCzwsSAy9iDggg8gj0NQaz/ AKu0/wCvyH/0KqHg21urTSp1uYZ4xJdSSRG5AE7q2DukxxuJz+GKv6z/AKu0/wCvyH/0KgDRoooo AKhuba2uowl1BFMgOQsqBhn8amrk/G9i+pXehWaQ2kzSXcn7u8jLxHELnlQRn296AOlWytFdZEtY Q6qFVhGMgDoAfQVHaabbWT3ckYLNeTGWYuc7jgLj6AADFcnqHiCbw+l/pjXNraTQW1r9hgSMKrEk q+xTyVyPfFTNq2srrMk329DZx6wlh9l8heUZFOS3XILcduOc0+odDq4rO1gRY4baKNEbcqogAB9R jvR9mtvtJufIi8/G3zdg349M9a891DV77U/DeoTN4lEF0jb5rCGJA9mqzAHJ+8AB1Ldeo4q7c61c 2ct+1vfweWzWUb6p5SHajqczNgbT2xn5Rn0pAdtFa28DFoYIo2YkkogBJPWpa4e21nWL4Wlna6zH Ik2oy2yakluh8+JYS+5R93IYFcjjjpUR8UajHFo0l3qkMfmM0c8UMaGW4YTeWCEbkqQDnZyM56UA d7RRRQAUUUUAZWpzx2uq2FxNuWJVlUsELAEhcdB7GpP7e03/AJ+G/wC/T/4Vo0UAZ39vab/z8N/3 6f8Awo/t7Tf+fhv+/T/4Vo0UAZ39vab/AM/Df9+n/wAKo6xrmnNpzyJOS8LJMP3T/wALBj29Aa36 juIRcW0sLdJEKn8RigCl/b+mf8/Df9+n/wAKbobiWC6lUNskupGQspXIz15qfSJjcaTayMSXMShs /wB4DB/UGrlABRRUNzdQWcJmuJVjQHGT3PoB3PsKAKuucaWzYYhZYmO1SSAJFJOB7Cox4k0hpWiW 8BkTG5BGxK56ZGOKXN/qfTfYWp7kfvpB/wCyD9fpV22tYLOLyoIwi5ye5J9STyT7mgCp/b2m/wDP w3/fp/8ACj+3tN/5+G/79P8A4Vo0UAZ39vab/wA/Df8Afp/8KP7e03/n4b/v0/8AhWjRQBnf29pv /Pw3/fp/8KP7e03/AJ+G/wC/T/4Vo0UAZMN7Bfa7A9szOsdtKGPlsACWjxyR7H8q1JATGwHXBp1F AGJpes2EGk2cMsrpJHAispifIIUAjpVr+3tN/wCfhv8Av0/+FaNFAGa3iDS1Us1yVUDJJicAfpQP EGmMARckg8giJ+f0p+tuU0S8I6tEyD6nj+tXVUIgUdAMUAUP7e03/n4b/v0/+FH9vab/AM/Df9+n /wAK0aKAM7+3tN/5+G/79P8A4VVvtTtL5rSG2d5JPtUTYETDgNknpW3RQAUUUUAFIQCQSASOntS0 UANZEYgsqkjgEijYv90dc9O9OooAZ5ceWOxcvwxx1+tHloFKhF2kYIxxj0p9FADQiKFAVQF6ADpS eXHlTsXK/dOOn0p9FABRRRQBWSO8GzfcwthjvxCRuHYD5uP1z7UJHegR77mFsBt+ICNx7Y+bjH45 9qs0UAVhHe4XdcwkhCDiAjLdj97p7frR5d7j/j5hz5eP9Qfv/wB773T2/WpJ7mC2UNPPHEpOAZGC g/nUP9q6d/0ELX/v8v8AjQA5o70httzCCUAXMBOG7n73I9v1oeO9PmbLmFchdmYCdp75+bnP4Y96 b/aunf8AQQtf+/y/40f2rp3/AEELX/v8v+NAD2jvCX2XMSgsCmYSdo7g/Nz9eMe9BjvMnFzEB5gI /cnhP7v3uvv+lM/tXTv+gha/9/l/xo/tXTv+gha/9/l/xoAp6Ul2n2m38+ICC9fI8o8o2HA+91+b r+lX1jvAU3XMRAYlsQkZXsB83B9+fpXF6h4zh0fxItpJPbo14yu0iuGjdFDA7TnAYjaMEjBHpW5H eWmrIJb7VbMWzcrbQXKlWH+24PzfQYH1oAnF/f3EiQ6fJBdMhYTTeSVhHpg7jkj0GfcrUltpNxFO t1cXkd1chWHmyQ/dJ6bBuwoHcdT61YTUtLjRUjvbREUYCrKoAH507+1dO/6CFr/3+X/GgB3l3uB/ pMOfLx/qD9/+997p7frQY73Bxcwg+WAP3B4fufvdPb9ab/aunf8AQQtf+/y/40f2rp3/AEELX/v8 v+NADnjvSH2XMKkqNmYCdp7k/Nzn8Me9Dx3h8zZcwrkjZmEnaO+fm5z+GPepILmC5UtBPHKoOCY2 DAflUtAFdo7wlttzEAXBXMJOF7j73J9/0o8u83f8fEWPNzjyT9z+797r7/pViigCusd4Cu65iIDk tiEjK9h97g+/6UiR3g8vfcwtgtvxCRuHbHzcY/HPtVmoZ7y1tiBcXMURboJHC5/OgBix3oCbrmEk KQ+ICNx7EfNxj05z7UCO9wM3MJPlkH9weX7H73T2/Wm/2rp3/QQtf+/y/wCNH9q6d/0ELX/v8v8A jQA7y73B/wBJhz5YA/cH7/8Ae+909v1oaO9IfbcwglQFzAThu5Pzcg+nb1NN/tXTv+gha/8Af5f8 aP7V07/oIWv/AH+X/GgCnrSXTWwi+0RYnuIEQeSTt+cFs/NznHtV9o7wl9tzEAXBXMJOF7g/Nyff j6Vz2t64kerWEEE9tOkrl4j5q7UdVbO854XkH/gJHUit1dV0/aN2oWpOOSJV/wAaAJDHeZOLiLHm 5H7k/c/u/e6+/wClAjvMjNzER5hJ/cnlOy/e6+/6Uz+1dO/6CFr/AN/l/wAaP7V07/oIWv8A3+X/ ABoAekd4DHvuYmAY78Qkbh2A+bjH459qRI70CPfcwsQG34gI3Htj5uMfjn2pv9q6d/0ELX/v8v8A jTo9RsZpBHFeW7u3RVlUk/hmgAEd6Au65hJ2EHEBGW7H73T2/Wjy73H/AB8w58vH+oP3/wC997p7 frVmigCs0d6Q226hBKALmAnDdz97ke361OgcD52DH2GKdRQAUUUUAFFFFABRRRQAUUUUAFFFFAGZ fRpLrenLIiuNk3DDPZau/Y7X/n2i/wC+BVS7/wCQ7p3+5N/Ja0aAIfsdr/z7Rf8AfAo+x2v/AD7R f98CpqQ9KAKsSadMxSJbWRl6hQpIqX7Ha/8APtF/3wK8+0G2u9C8ER6xELKHcIWZ7ex2TLF5o8wy Nk7/AJc54HrWlJrl9qshXTNSkjt59YS3juI4QcQm33Nt3DH3gcNz+NOwPQ7AWtuBgQRD/gAqPybE ymLy7cyAZKbVzj1xXGTa1fRW1lBqWuzafAHu45NQWBN0rxybY1OVKglcngc44xTxdaDd+O7aK3e0 t72zlLTzldk91K0ZHljuVAOTnjIAHQ4QHYtbWa43QQDJwMoOTTvsdr/z7Rf98CuP8VaxoEjaBqb3 kQY3kckTuWGIgTuYKenbJxXaqwdQynKkZBHejoHUi+x2v/PtF/3wKPsdr/z7Rf8AfAqaigDMsY0i 1vUVjRUGyHhRjs1adZ1p/wAhzUf9yH+TVo0AFFFFABWYYYpfEcnmRo+LRMblBx87Vp1nJ/yMcv8A 15p/6G1AFv7Ha/8APtF/3wKPsdr/AM+0X/fAqaigCoi6dLIY41tXdeqqFJH4VL9jtf8An2i/74Fe f6VZX2leFdR1q0SzSXdOUeGxxcgC4Jbc+TvG0Hjb6elX7nxDealPc/2RqTC2fULSCGdIgwVHHzlc jn68jNAdTsfslt/z7xf98CmeTY+b5XlW/mEZ2bVzj1xXGT6zqFtBFa6hrc1nax31zBLqQhTeQgBj UkqVBOTzt52470XN3oN74v062Wa1jv7eSKae9kQRzTsUwka8ZO4EFh0AwOp4AOzeGxi2iSK3TccL uVRk+gp/2O1/59ov++BXGeMtW8N6hp8EExs3nvlligurqPC2yg7XcEjIII4A5Jx2ya7O1KG0hMUn mxmNdshOdwxwfxoAPsdr/wA+0X/fAqhq1tBGtmyQxqwvIuQgB+9WrWdrP+rtP+vyH/0KgDRooooA KKKKACiiigAooooAKKKKACiiigAooooAzL50j1vTi7qo2Tcscdlq99pt/wDnvH/32KJ7W3ulC3EE UwU5AkQNj86g/sjTP+gdaf8Afhf8KAJ/tNv/AM94/wDvsUfabf8A57x/99ioP7I0z/oHWn/fhf8A Cj+yNM/6B1p/34X/AAoAn+02/wDz3j/77FH2m3/57x/99ioP7I0z/oHWn/fhf8KP7I0z/oHWn/fh f8KAJ/tNv/z3j/77FH2m3/57x/8AfYqD+yNM/wCgdaf9+F/wo/sjTP8AoHWn/fhf8KAJ/tNv/wA9 4/8AvsUfabf/AJ7x/wDfYqD+yNM/6B1p/wB+F/wo/sjTP+gdaf8Afhf8KAJ/tNv/AM94/wDvsUfa bf8A57x/99ioP7I0z/oHWn/fhf8ACj+yNM/6B1p/34X/AAoAgsnSTW9RKOrDZDypz2atOooLW3tV K28EUIY5IjQLn8qloAKKKKACszzY4/Ecu+RVzZpjccfxtWnUE9laXTBri1hmKjAMkYbH50AO+02/ /PeP/vsUfabf/nvH/wB9ioP7I0z/AKB1p/34X/Cj+yNM/wCgdaf9+F/woAn+02//AD3j/wC+xR9p t/8AnvH/AN9ioP7I0z/oHWn/AH4X/Cj+yNM/6B1p/wB+F/woAn+02/8Az3j/AO+xR9pt/wDnvH/3 2Kg/sjTP+gdaf9+F/wAKP7I0z/oHWn/fhf8ACgCf7Tb/APPeP/vsUfabf/nvH/32Kg/sjTP+gdaf 9+F/wo/sjTP+gdaf9+F/woAn+02//PeP/vsVQ1eeF0tFWVGP2yLgMP71WP7I0z/oHWn/AH4X/CnR 6ZYQyLJFY2yOvIZYlBH44oAtUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB/9k= --_004_5FD31D8EDBF4EC468B36D86F04FDB2E873828241nkgeml507mbschi_-- From nobody Wed Jun 3 08:59:42 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D092D1A911B for ; Wed, 3 Jun 2015 08:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRGVDjT84BXt for ; Wed, 3 Jun 2015 08:59:31 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97AD51A912B for ; Wed, 3 Jun 2015 08:59:31 -0700 (PDT) X-AuditID: c6180641-f79086d000001909-d1-556ebed4fe71 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id F4.61.06409.4DEBE655; Wed, 3 Jun 2015 10:46:12 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0210.002; Wed, 3 Jun 2015 11:59:25 -0400 From: Dave Hood To: Xiayinben , Zhoutianran , STUART VENTERS , "Natale, Bob" Thread-Topic: role based intent Thread-Index: AdCdxq4VFvGDpUDvRK6YJXpiQnECmwANkqOQAAXMRWAAAGlUUA== Date: Wed, 3 Jun 2015 15:59:24 +0000 Message-ID: <8D15A2BAF93E9C49AB037A0647E5FA643F84DBFC@eusaamb105.ericsson.se> References: <8D15A2BAF93E9C49AB037A0647E5FA643F84C6C3@eusaamb105.ericsson.se> <5FD31D8EDBF4EC468B36D86F04FDB2E873828241@nkgeml507-mbs.china.huawei.com> In-Reply-To: <5FD31D8EDBF4EC468B36D86F04FDB2E873828241@nkgeml507-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/related; boundary="_004_8D15A2BAF93E9C49AB037A0647E5FA643F84DBFCeusaamb105erics_"; type="multipart/alternative" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBIsWRmVeSWpSXmKPExsUyuXRPoO6VfXmhBsu/m1m03nzEZNF48ASz xfkFz1ksmtu3s1r8eHqX1WLCyQXMDmweKyY2snm0HHnL6rFkyU8mj8kbD7N5vG24yh7AGsVl k5Kak1mWWqRvl8CV0bJzMmvB3UlMFeua3jA1ML5vYOpi5OSQEDCRmLXvDzuELSZx4d56ti5G Lg4hgaOMEj8mrmWFcJYxSqzceZ4VpIpNQEPiyaXJTCAJEYHZjBJX9y1g6WLk4GAWcJNoPpMA UiMsICcxt3kZ2AYRAXmJnZePsULYThIXDy5kBilnEVCRaJjKARLmFfCVmNTYzAJiCwk8ZZSY PJkZxOYUCJOYfWUNG4jNCHTc91NrwEYyC4hL3HoyH+oBEYmHF0+zQdiiEi8f/2OFsJUkJi09 B3Y/s0A3o8T9d3tYIJYJSpyc+YRlAqPoLCSzZiGrm4WkDqIoX6L9zUYmCFtLYl7DbyhbUWJK 90N2CFtT4srkQ1C2tsSyha+ZIWxdiekTjsDVz17+ihFi2VJGiU0nvkMt0JFYuucNI7KhCxh5 VzFylBanluWmGxluYgQmjWMSbI47GBd8sjzEKMDBqMTDm6CeFyrEmlhWXJl7iFGag0VJnFfa DygkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBsevlubXdBfsaJx6ZOskqJyEzW25feOB1ttsX HpQJlx5XXOmvZFRc9vfOgy97ikNfSlb5GIaI9/5yPJwYxuYmv2t7QPGS5yJndY8HX528dz3b zlRO3k7uB2sXVh7PE1+heHmD5w7O404nti65tyNr8Y9vJgnRIsYTPuju8+6UMbl0ltPLeu6H LCWW4oxEQy3mouJEAJxhU637AgAA Archived-At: Cc: "sdn@irtf.org" , "ibnemo@ietf.org" Subject: Re: [Sdn] role based intent X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 15:59:34 -0000 --_004_8D15A2BAF93E9C49AB037A0647E5FA643F84DBFCeusaamb105erics_ Content-Type: multipart/alternative; boundary="_000_8D15A2BAF93E9C49AB037A0647E5FA643F84DBFCeusaamb105erics_" --_000_8D15A2BAF93E9C49AB037A0647E5FA643F84DBFCeusaamb105erics_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SSBkbyB0aGluayB0aGlzIGlzIGFjY2VwdGFibGUsIGJ1dCBpdCB0YWtlcyB1cyBiYWNrIHRvIHRo ZSBwb2ludCB0aGF0IGFueSBOQkkgY29udmV5cyBpbnRlbnQsIGZvciBpdHMgdXNlciBhbmQgaXRz IHByb3ZpZGVyIGluIGl0cyBjb250ZXh0LCB3aGljaCByZW5kZXJzIHRoZSBjb25jZXB0IG5vdCBw YXJ0aWN1bGFybHkgdXNlZnVsLiBJdCB3b3VsZCBiZSByZWFsbHkgaGVscGZ1bCB0byBzZWUgYSBj b25jcmV0ZSBleGFtcGxlIG9mIHNvbWV0aGluZyB0aGF0IHdlIGNhbiBhbGwgYWdyZWUgaXMgKm5v dCogaW50ZW50Lg0KDQpEYXZlDQoNCkZyb206IFhpYXlpbmJlbiBbbWFpbHRvOnhpYXlpbmJlbkBo dWF3ZWkuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBKdW5lIDAzLCAyMDE1IDg6NTMgQU0NClRvOiBE YXZlIEhvb2Q7IFpob3V0aWFucmFuOyBTVFVBUlQgVkVOVEVSUzsgTmF0YWxlLCBCb2INCkNjOiBz ZG5AaXJ0Zi5vcmc7IGlibmVtb0BpZXRmLm9yZw0KU3ViamVjdDogtPC4tDogcm9sZSBiYXNlZCBp bnRlbnQNCg0KSGkgRGF2ZSwNCg0KSSB0aGluayB0aGUgbWVhbmluZyBvZiChrm9uZSBpbnRlbnQg bGF5ZXKhryBpcyB0aGF0IGVhY2ggcm9sZSBoYXMgb25lIGludGVudCBsYXllciBidXQgbm90IGFs bCByb2xlcyBoYXZlIG9uZSBpbnRlbnQgbGF5ZXIuDQpBbmQgd2UgZG9uoa90IG5lZWQgY2FyZSBh Ym91dCB0aGUgbGF5ZXIgcmVsYXRpb25zaGlwIGJldHdlZW4gZGlmZmVyZW50IHJvbGWhr3MgaW50 ZW50LiBTbyAgaW4gZ2VuZXJhbCwgdGhlcmUgaXMgb25seSBvbmUgaW50ZW50IGxheWVyLg0KRG8g eW91IHRoaW5rIHRoaXMgaXMgYWNjZXB0YWJsZT8NCg0KWWluYmVuDQoNCreivP7IyzogSWJuZW1v IFttYWlsdG86aWJuZW1vLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gRGF2ZSBIb29kDQq3osvNyrG8 5DogMjAxNcTqNtTCM8jVIDIxOjAzDQrK1bz+yMs6IFpob3V0aWFucmFuOyBTVFVBUlQgVkVOVEVS UzsgTmF0YWxlLCBCb2INCrOty806IHNkbkBpcnRmLm9yZzxtYWlsdG86c2RuQGlydGYub3JnPjsg aWJuZW1vQGlldGYub3JnPG1haWx0bzppYm5lbW9AaWV0Zi5vcmc+DQrW98ziOiBSZTogW0libmVt b10gcm9sZSBiYXNlZCBpbnRlbnQNCg0KTGF5ZXJpbmcgaXMgdGhlIHJpZ2h0IGlzc3VlLCBidXQg dGhlIHBvaW50IGlzIGEgbGl0dGxlIGRpZmZlcmVudC4gV2UsIHdobyBsb29rIGF0IHRoZSBnbG9i YWwgc2NlbmFyaW8gZnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgdGhlIGdvZHMsIHNlZSB0aGF0IHRo ZXJlIGlzIGEgcmVjdXJzaW9uIG9mIGNsaWVudHMvc2VydmVycyBvciBjdXN0b21lcnMvcHJvdmlk ZXJzIG9yIKGtLg0KDQpCdXQgZnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgYW55IG9uZSBvZiB0aG9z ZSBpbnRlcmZhY2VzLCB0aGUgb3RoZXIgbGF5ZXJzIGFyZSBjb21wbGV0ZWx5IGludmlzaWJsZS4g U28gYSBnaXZlbiBhcHAgY2FuIGludm9rZSBpbnRlbnQgYWdhaW5zdCBhIGdpdmVuIFNETiBjb250 cm9sbGVyLCBidXQgdGhlIGNvbnRyb2xsZXIgZG9lc26hr3Qga25vdyB3aGV0aGVyIHRoZSBhcHAg aXMganVzdCBhIG1pZGRsZW1hbiwgYW5kIHRoZSBhcHAgZG9lc26hr3Qga25vdyB3aGV0aGVyIHRo ZSBjb250cm9sbGVyIGNhbiBzYXRpc2Z5IGl0cyByZXF1aXJlbWVudHMgZGlyZWN0bHkgb3Igd2hl dGhlciBpdCBpcyBhbHNvIGp1c3QgYSBtaWRkbGVtYW4uDQoNCllvdSBjYW4gaGF2ZSBvbmUgaW50 ZW50IGxheWVyLCBhcyBsb25nIGFzIHlvdSByZWNvZ25pemUgdGhhdCB5b3UgYXJlIG9ubHkgc2Vl aW5nIG9uZSBzbGljZSBvZiB0aGUgd29ybGQuIElmIHlvdSBpbnNpc3Qgb24gb25seSBvbmUgbm9y dGhlcm5tb3N0IGludGVudCBsYXllciBpbiB0b3RvLCB5b3Ugd2lsbCBoYXZlIHRvIGdvIGJhY2sg dG8gdGhlIKGwbWFrZSBtb25leaGxIGludGVudCBvZiB0aGUgaW52ZXN0b3JzLg0KDQpBbmQgaWYg d2UgcmVjb2duaXplIHRoYXQgZWFjaCBpbnRlcmZhY2Ugc3RhbmRzIG9uIGl0cyBvd24sIHRoZW4g YW55IHNlcnZpY2UgaW52b2NhdGlvbiBhY3Jvc3MgdGhhdCBpbnRlcmZhY2UgcXVhbGlmaWVzIGFz IGFuIGV4cHJlc3Npb24gYW5kIHNhdGlzZmFjdGlvbiBvZiBpbnRlbnQgYnkgdGhhdCBwYXJ0aWN1 bGFyIGludm9rZXItcHJvdmlkZXIgcGFpci4NCg0KRGF2ZQ0KDQpGcm9tOiBaaG91dGlhbnJhbiBb bWFpbHRvOnpob3V0aWFucmFuQGh1YXdlaS5jb21dDQpTZW50OiBUdWVzZGF5LCBKdW5lIDAyLCAy MDE1IDExOjMwIFBNDQpUbzogRGF2ZSBIb29kOyBTVFVBUlQgVkVOVEVSUzsgTmF0YWxlLCBCb2IN CkNjOiBpYm5lbW9AaWV0Zi5vcmc8bWFpbHRvOmlibmVtb0BpZXRmLm9yZz47IHNkbkBpcnRmLm9y ZzxtYWlsdG86c2RuQGlydGYub3JnPg0KU3ViamVjdDogcm9sZSBiYXNlZCBpbnRlbnQNCg0KDQpI aSBEYXZlLCBTdHVhcnQsIEJvYiBhbmQgYWxsLA0KDQoNCg0KSSBmb3VuZCBtYW55IHByb2JsZW1z IHJhaXNlZCBpbiB0aGUgbWFpbGluZyBsaXN0IGFyZSBjb3Vyc2VkIGJ5IHRoZSBsYXllcmVkIGlu dGVudCB0aGlua2luZy4gTWF5YmUgd2UgYXJlIHRhaW50ZWQgYnkgdGhlIElTTyBtb2RlbDotKQ0K DQoNCg0KRm9yIHRoZSBsYXllcmVkIGludGVudCwgaW50ZW50IGlzIGEgc3BlY3RydW0sIHZlcnkg YWJzdHJhY3QgYXQgdGhlIHRvcCBsYXllciwgbW9yZSBuZXR3b3JrIHNwZWNpZmljIGFuZCBsZXNz IGFic3RyYWN0IHdoZW4gdGhlIGxheWVyIGdvZXMgZG93bi4gVGhlIHByb2JsZW0gaXMgdGhhdCB0 aGUgYm91bmRhcnkgb2YgaW50ZW50IGFuZCBub24gaW50ZW50IGlzIHZhZ3VlLiBPciB0aGVyZSBp cyBubyBib3VuZGFyeSBiZXR3ZWVuIHRoaXMgdHdvLCBzaW5jZSBvbmUncyB3aGF0IG1heSBiZSBh bm90aGVyIG9uZSdzIGhvdy4gQW5kIGNvbnNlcXVlbnRseSwgaXQgbG9va3MgbGlrZSBldmVyeXRo aW5nIGlzIGludGVudCBhbmQgbm8gY2xlYXIgaW50ZW50IGRlZmluaXRpb24uDQoNCg0KDQpUaGUg cm9sZSBiYXNlZCBpbnRlbnQgd2lsbCBwcm92aWRlIG9ubHkgb25lIGludGVudCBsYXllci4gVGhh dCBpcyBhbHdheXMgdGhlIHRvcCBsYXllciBhYnN0cmFjdGlvbiBmb3IgZWFjaCByb2xlLCBhcyBz aG93biBpbiB0aGUgZm9sbG93aW5nIGZpZ3VyZS4gVGhlIGZ1bmN0aW9ucyBjYW4gYmUgbGF5ZXJl ZCBhcyB0aGUgaW1wbGVtZW50YXRpb24gb2YgdGhlIGludGVudCBsYXllci4NCg0KW2NpZDppbWFn ZTAwMS5qcGdAMDFEMDlEREIuOTU2NkRGMTBdDQoNCldpdGggdGhlIHJvbGUgYmFzZWQgaW50ZW50 LCBhbHRob3VnaCB0aGUgZW5kIHVzZXIncyBpbnRlbnQgaXMgbXVjaCBhYnN0cmFjdGVkIHRoZW4g dGhlIG5ldHdvcmsgYWRtaW5pc3RyYXRvcidzIGludGVudCwgdGhleSBhcmUgbm90IHJlbGF0ZWQg ZWFjaCBvdGhlci4gSS5lLiwgdGhlIGVuZCB1c2VyIHdpbGwgbm90IHVzZSB0aGUgYWRtaW5pc3Ry YXRvcidzIGludGVudC4gQW5kIHRoZSBhZG1pbiB3aWxsIG5vdCBwcm92aWRlIGFkZGl0aW9uYWwg c2VydmljZXMvaW50ZXJmYWNlcyB0byB0aGUgZW5kIHVzZXIuDQoNCg0KDQpUaGUgZXNzZW50aWFs IG9mIGxheWVyaW5nIGlzIHRoYXQgdGhlIGxvd2VyIGxheWVyIHdpbGwgcHJvdmlkZSBpbnRlcmZh Y2UgdG8gdGhlIGhpZ2hlciBsYXllci4gSW4gb3JkZXIgdG8gZml0IHVwIGxheWVyIHJlcXVpcmVt ZW50cywgdGhlIGxvd2VyIGxheWVyIHdpbGwgcHJvdmlkZSBhZGVxdWF0ZSBpbnRlcmZhY2VzL2Nh cGFiaWxpdGllcy4gVGhhdCBhbHNvIG1lYW5zIHRvbyBtdWNoIGluZm9ybWF0aW9uIGZvciBhIGRl ZGljYXRlZCB1cCBsYXllciB1c2VyL2FwcC4NCg0KDQoNCkZvciByb2xlIGJhc2VkIGludGVudCwg d2UgY2FuIGZpcnN0bHkgaW5kZW50aWZ5IHZhcmlvdXMgcm9sZXMgKG5vIG5lZWQgdG8gYmUgY29t cGxldGUsIGJ1dCB0aG9zZSB3aXRoIGF0dGVudGlvbiksIGFuZCB0aGVuIGZpZ3VyZSBvdXQgdGhl IGludGVudCBvZiBlYWNoIHJvbGUuIEluIHRoaXMgd2F5LCBpbnRlbnQgY2FuIGJlIGNsZWFyIGRl ZmluZWQuIFRoYXQgd2lsbCBhbHNvIGtlZXAgdGhlIGludGVudCBvZiBlYWNoIHJvbGUgdG8gYSBz bWFsbCBzZXQgb24gd2hhdCB0aGV5IHJlYWxseSBjYXJlcyBhYm91dCwgd2l0aG91dCBleHBlbmRp bmcgdG8gc3VwcG9ydCBvdGhlciBvbmWhr3MgaW50ZW50Lg0KDQoNCg0KDQoNCkJlc3QgUmVnYXJk cywNCg0KVGVyZW5jZQ0KDQoNCg0KDQo= --_000_8D15A2BAF93E9C49AB037A0647E5FA643F84DBFCeusaamb105erics_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

I do think this is a= cceptable, but it takes us back to the point that any NBI conveys intent, f= or its user and its provider in its context, which renders the concept not particularly useful. It would be really helpful to see a c= oncrete example of something that we can all agree is *not* intent.<= o:p>

 

Dave

 

From: Xiayinben [mailto:xiayinben@huawei.com]
Sent: Wednesday, June 03, 2015 8:53 AM
To: Dave Hood; Zhoutianran; STUART VENTERS; Natale, Bob
Cc: sdn@irtf.org; ibnemo@ietf.org
Subject: =B4=F0=B8=B4: role based intent

 =

Hi Dave,

 

I think the meaning of= =A1=AEone intent layer=A1=AF is that each role has one intent layer but no= t all roles have one intent layer.

And we don=A1=AFt need= care about the layer relationship between different role=A1=AFs intent. So=  in general, there is only one intent layer.

Do you think this is a= cceptable?

 

Yinben

 

=B7=A2=BC=FE=C8= =CB: Ibnemo [mailto:ibnemo-bounces@ietf.org= ] =B4=FA=B1=ED Dave Hood
=B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA6=D4=C23=C8=D5 21:03
=CA=D5=BC=FE=C8=CB: Zhoutianran; STUART = VENTERS; Natale, Bob
=B3=AD=CB=CD: sdn@irtf.org; ibnemo@ietf.org
=D6=F7=CC=E2: Re: [Ibnemo] role based in= tent

 =

Layering is the righ= t issue, but the point is a little different. We, who look at the global sc= enario from the perspective of the gods, see that there is a recursion of clients/servers or customers/providers or =A1=AD.

 

But from the perspec= tive of any one of those interfaces, the other layers are completely invisi= ble. So a given app can invoke intent against a given SDN controller, but the controller doesn=A1=AFt know whether the app is just a= middleman, and the app doesn=A1=AFt know whether the controller can satisf= y its requirements directly or whether it is also just a middleman.

 

You can have one int= ent layer, as long as you recognize that you are only seeing one slice of t= he world. If you insist on only one northernmost intent layer in toto, you will have to go back to the =A1=B0make money=A1=B1 inte= nt of the investors.

 

And if we recognize = that each interface stands on its own, then any service invocation across t= hat interface qualifies as an expression and satisfaction of intent by that particular invoker-provider pair.

 

Dave

 

From: Zhoutianran [mailto:zhoutianran@huawei.com]
Sent: Tuesday, June 02, 2015 11:30 PM
To: Dave Hood; STUART VENTERS; Natale, Bob
Cc: ibnemo@ietf.org; sdn@irtf.org
Subject: role based intent

 =

Hi Dave, Stuart, Bob and all,

 

I found many problems raised in the mailing list are coursed by the laye= red intent thinking. Maybe we are tainted by the ISO model:-)

 

For the layered intent, intent is a spectrum, very abstract at the top l= ayer, more network specific and less abstract when the layer goes down. The= problem is that the boundary of intent and non intent is vague. Or there is no boundary between this two, since one's wha= t may be another one's how. And consequently, it looks like everything is i= ntent and no clear intent definition.

 

The role based intent will provide only one intent layer. That is always the top layer abs= traction for each role, as shown in the following figure. The funct= ions can be layered as the implementation of the intent layer.

With the role based intent, although the end user's intent is much abstr= acted then the network administrator's intent, they are not related each ot= her. I.e., the end user will not use the administrator's intent. And the admin will not provide additional services/interfaces to t= he end user.

 

The essential of layering is that the lower layer will provide interface= to the higher layer. In order to fit up layer requirements, the lower laye= r will provide adequate interfaces/capabilities. That also means too much information for a dedicated up laye= r user/app.

 

For role based intent, we can firstly indentify various roles (no need t= o be complete, but those with attention), and then figure out the intent of= each role. In this way, intent can be clear defined. That will also keep the intent of each role to a small set on what they re= ally cares about, without expending to support other one=A1=AFs intent.

 

 

Best Regards,

Terence

 

 

--_000_8D15A2BAF93E9C49AB037A0647E5FA643F84DBFCeusaamb105erics_-- --_004_8D15A2BAF93E9C49AB037A0647E5FA643F84DBFCeusaamb105erics_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=9164; creation-date="Wed, 03 Jun 2015 15:59:24 GMT"; modification-date="Wed, 03 Jun 2015 15:59:24 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCACPAUoDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2aiii gDK1OCO61bT4J13xFZSUJOCQFwf1NTf2Hpn/AD5x/rTbv/kO6d/uTfyWtGgCh/Yemf8APnH+tH9h 6Z/z5x/rUfiLU5tH0K5v7eFJpYgu1HbAYlgOT261h3viXXLH7aWt9OcaTEkl8N7qZd2TiLPT5R1b qeOKAOg/sPTP+fOP9aP7D0z/AJ84/wBa5e48RXuky6ilrBJd3F1qxhhVlaQRgQI5+UcnoeBjqTVm 8v8AU7vTdD1KVrnTZXv4Yp7MfKGzJtO7jOCBwPfmhagzf/sPTP8Anzj/AFo/sPTP+fOP9av0UAZm iIsSXsSDEcd26ouchRgcCtOs7SPv6h/1+P8AyWtGgDHjsba91nUDcxCXyzGF3E/KNgPFWf7D0z/n zj/Wm2P/ACGNT/34/wD0AVo0AUP7D0z/AJ84/wBaP7D0z/nzj/Wqeq6rqFvrdnp9lFbsksMk80kx bKojICFA6k7uKwp/E+qXWjyPcw2scGqaZcXFm1tKxlh2pkb+2cMORjBGKAOp/sPTP+fOP9aP7D0z /nzj/WuYXxbqkWoW+n2elyXcNvHbrcOI2ZmLqpJDdFwDnnrg9K0LSOY+MmNjqF7cW0SyfbxNLvhV zjYiDoGHJOOgxnk07ah0Nf8AsPTP+fOP9aiu9F01LOZltEBEbEEZ44rUqC9/48Z/+uTfypAM0xi2 lWjMSzGBCSTkn5RViQ4jYj0NVtL/AOQTZ/8AXBP/AEEVZk/1Tf7poAx9K0jT5tIspZbVHd7eNmZi SSSoyTVv+w9M/wCfOP8AWnaL/wAgOw/69o//AEEVdoAof2Hpn/PnH+tH9h6Z/wA+cf61iXviXVLe 51No7azNtZ3MdpEXdgzyyCPazHoqDzOepOKrT6vqM97aWF95Md1Z6tBHK9o7eXKrxswGDyPcHPY9 6FqD0Ok/sPTP+fOP9aP7D0z/AJ84/wBa5zRvFOp6/LKj6bNbWNxDIYblFMZjwcDLt8pJ9QOCO9Wv B0t6lzqtjfvdLJBJGyW9zcfaGiRk4/e/xZIY47UAbP8AYemf8+cf61U1DTrOzNpNbQLFJ9riXcpI OC2CK2qztZ/1dp/1+Q/+hUAaNFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAGdd/wDId07/AHJv 5LWjVW80+G9aN5GlR4s7HilZCM9eQfaof7Gh/wCfu+/8C5P8aALVzawXtu1vcxLLE+NyOMg4OR+o qreaFpOoXsN7eadbz3MGPLleMFlwcj8jzR/Y0P8Az933/gXJ/jR/Y0P/AD933/gXJ/jQAt1oelX1 vNBdWEE0U8olkV0B3OABu+uABmq914U0C9t7e3udJtpIrVdsCFOIx7Vkz6fczeJntYNXv4IkgGxT OzK0mcnIzn7pHQirZha041L+0I0H/LeC7lkj/EZ3L+Ix70AdAiLGiogCqoAAHYU6suHTbS5iEsF/ eSxt0ZL1yD+Oak/saH/n7vv/AALk/wAaAE0j7+of9fj/AMlrRqvZ2UNjE0cO8hmLszuXZie5JqxQ BnWP/IY1P/fj/wDQBWjVGbSbea5e48y5ikkxv8qd0DYGBwDim/2ND/z933/gXJ/jQBba2ga6S6aJ TOiFFkxyFJBI+hwPyqjb+HNFtXunt9Ltomu1KTlYwN6nqD7HPSoLuDT7JlSbUL7zW+7El1Izt9FB yagGlX179ye80+I/xSXbvKR7Lnav45+lAF+bw9o9xeQXk2m273FsFEUhjGVC/d/Lt6U228M6JZ6i dRttNgiu2ZnMqLglm+8fqcmq2l6Wslq6y3+oyPDNJGXa7fLAMQCcEDpirv8AY0P/AD933/gXJ/jQ BoVBe/8AHjP/ANcm/lVb+xof+fu+/wDAuT/GkbRYHUq11fEEYI+1yc/rQBNpf/IJs/8Argn/AKCK syf6pv8AdNJFEkMKRRjaiKFUegHSnEAjB6GgCnov/IDsP+vaP/0EVdrNj0O2ijWOO4vURAFVRdyY AHQdad/Y0P8Az933/gXJ/jQBNJplhNFdQy2kLx3hzcKyAiU4Ay3rwAPwqG10LSrK2it7bT4IooZf OjVUA2yf3vrz1qG6srKyi824v71Fzgf6XISx9AM5J9hWVf2N7JZG4iur+xj3oEBunaVyWAGckhRz 05P0oA14/DWhxT3M6aVarJdqVnPlD94D1B+vf1qxpuk6fo8DQadZxWsbNuZY1xuPqfWo/wCxof8A n7vv/AuT/Gj+xof+fu+/8C5P8aANCs7Wf9Xaf9fkP/oVL/Y0P/P3ff8AgXJ/jQujWwljd5rqXy3D qsly7LkdDgnmgDQooooATIBAyMnoKWuV8UzzWms2t1AcSwaXfujYzhgIyP1FYusTa0+galbXOsTy /wDEvtr4SpCiNGS53qMD7uFz3I55o6AeiUV55e+I9Yj163tLLV7drYJAbeS4lRft4b7zYEZ39x8h XBrQtb7WpdUjlk1Rzb3GqXNiLcQIBGiiQqwOMlgUHJ4wenegDsJJY4U3yyLGuQNzHAyTgfrT6870 8lvhv5Umoy300V7Ckqy7d0DC4TKHAB9+eefSpoPEWqXfjiTS4dQZIZpLiDynEZeAohKuEC5AyMgs x3A9B2AO+orz6bxTrs2iXV9CRCbQw2VwWUKIp937+TJU4C/KAcEDJJBxU+m6nrmpf2TanWYwtzNc B7m08uYyRoqlRuKBc5JBIXH40LUDuqKKKACis46QCc/2jf8A/f8A/wDrUf2OP+gjf/8Af/8A+tQB o0Vnf2OP+gjf/wDf/wD+tR/Y4/6CN/8A9/8A/wCtQBo0Vnf2OP8AoI3/AP3/AP8A61H9jj/oI3// AH//APrUAUScag94B93UhGT7GIJ/Mit+uU/skyeH7u5S/vi3mSzKPP6lZCV7f7IrYTSlkRXXUr8q wBB8/t+VAEk2kW7ytPbs9pcNyZYDt3H/AGh0b8RTPtOpWXF1bi7iH/La2GHH1jP/ALKT9KX+xx/0 Eb//AL//AP1qQ6Sqgs2pX4A5JNx0/SgC1aX1rfIWtplk28MBwyn0IPIP1qxXLXFlZ306tZS6jfTx n5Z4rkxonsZB1HsM/Soz4e1pFb7Zq15qEDjBt4bjyXXn+8AN/p/DQBvz6tbRSmCEPdXA6wwDcV/3 j0X8SKj8jU73/j5nFlEf+WVud0h+rkcfgPxqjp9pp7gWlvf31tIg/wCPZ5PLcf8AAcc/UZq//Y4/ 6CN//wB//wD61AFm0sLWxDC3hVC3LP1Zvqx5P41YrO/scf8AQRv/APv/AP8A1qP7HH/QRv8A/v8A /wD1qAHadhLvUYvS43f99Ip/nmr9YMGkhdZu4/7QvxuiikB8/rywPb2FXf7HH/QRv/8Av/8A/WoA 0aKzv7HH/QRv/wDv/wD/AFqP7HH/AEEb/wD7/wD/ANagDRorO/scf9BG/wD+/wD/APWqpdwQWrrD /aGozXDjKQRTZdvf2HucCgDb6VnNqUt2xi0uNZcHDXL/AOqX6f3z7Dj3FUk8Oz3isdS1G9EbYxbR 3BKj/ebALH26exq6NGVQFXUL4ADAAnwB+lAE1rpscEv2iZ2ubojBmk6geijoo9h+Oaj1bLCziH/L S7j/APHct/7LSf2OP+gjf/8Af/8A+tVG70onVLCIahfkZkkP7/phcen+1QBv0Vnf2OP+gjf/APf/ AP8ArUf2OP8AoI3/AP3/AP8A61AGjRWd/Y4/6CN//wB//wD61H9jj/oI3/8A3/8A/rUAaNFZ39jj /oI3/wD3/wD/AK1H9jj/AKCN/wD9/wD/AOtQBoYorP8A7HH/AEEb/wD7/wD/ANaj+xx/0Eb/AP7/ AP8A9agDQwOOBx0oxWf/AGOP+gjf/wDf/wD+tR/Y4/6CN/8A9/8A/wCtQBoYHpRgZzis/wDscf8A QRv/APv/AP8A1qP7HH/QRv8A/v8A/wD1qALNlY29hA0Num1XkeRskkszEsxJPqTU+AO1Z/8AY4/6 CN//AN//AP61H9jj/oI3/wD3/wD/AK1AGjRWd/Y4/wCgjf8A/f8A/wDrVoAYAHXHrQAtFFFABRVa 6v7eyaNZmfdLnYqRs5OOvCgmof7YtP7l3/4Bzf8AxNAF+kZgilicADJqj/bFp/cu/wDwDm/+JrP1 3VWfSZm0+K8kuEUssQtJR5vBBXle4PHvigC/o0QOg2qOOJIQzD/eGT/Om6ZdRwaHA91KkSwr5Ts7 ADKkr/Sud0PXtTls1guYprGVhkJLZSs0CAABVVV5xjJLHqTxirelPpsF5dmdby6njnLpJNaSsVDA NkDbheS3QCgDX/tG5vONNtCyn/l4uMpH+A+835Ae9KNIWch9Sne9bOdjDbEPog4P/As07+2LT+5d /wDgHN/8TVi0vIL2IywMWUMVO5CpBHUEEAigCYAKoVQAAMADtS0UUAQXVnbXsfl3MKSqORuHIPqD 2P0qp9kv7LmyuvtEf/PC6JJH0k6/mDV25uYbOBp52KxrgEhSTycDgcnkiqv9sWn9y7/8A5v/AImg BItXg8xYbxHspmOAs/Csf9lvun88+1aFZ0mqWE0bRyw3MiMMMrWMpB/DbVDzIbXnTJ72AD/lhJZT SRH6DblfwOPagDQYbPEMbf8APW1Yf98sv/xVaFcPc6trE3iK2iaxvEtXDbrqO2kK24wNwB2gndtG MjIJPbFdT/bFp/cu/wDwDm/+JoAv1HPPFbQtNPIscajJZjgCsy719YgqWtneTSPwC1pKqJ7sdv8A IE1DDNaGZbm+a7urhTlc2UwjiP8Asrt4+pyfegC1597qXFqGtLY/8t5F/eOP9hT0+rflVu0sbeyR hCmGc5d2O5nPqxPJplvqVtdT+RGZRJtLhZIXjyAQCRuAz1H51aJwMmgBaKz01uykRZI/tLowBVlt JSCPUHbS/wBsWn9y7/8AAOb/AOJoAv1nsS/iFB2itGP/AH04/wDiKX+2LT+5d/8AgHN/8TVODU4R q13O8N4EaONI2+xy843E/wAPq1AG3RVD+2LT+5d/+Ac3/wATR/bFp/cu/wDwDm/+JoAv0VQ/ti0/ uXf/AIBzf/E0q6xZtIkZM6GRgimS2kQEnoMlQKAL1FFFABRRXPeJLyGy1nw/Nc3KW8P2uUO8kgRf 9RJjJPHWgDoaK4a48Y3J8aW9lZ3cUtjLcpbMmIx96PduX5t7dQd23b296bL4v1iPT751iie40iBk vflwpnMm1TyeF2AyH2YcijoB3dFcHZeIPEF5ZW0AvbNJrjURbLdDypjsMTOcrGxUMCvHPTGRRaeK 9ck8Sz2xW3kggmlga3MkSyMEUkMF3byzEA424w340Ad3uG7bkZxnFLXCeF9Tm1XxXaXNxq1pfyS6 Q8pS3QL9nLSRkoeTnHTnB4Oa7ugAooooAKKKKAM67/5Dunf7k38lpup+ItJ0aeKC/uxDLMpZECMx IBwThQeORTrv/kO6d/uTfyWszVNHutQ8YWtxHc3lnBFYurT2zKu5vMQhDkHsCfwo6gdGDkZFLXGb NXTV/sJsr4qNZ+1faQw8ryCvTOc9eNuKrWGiazapa3Nt9sjv7iG9SdppmZQckw5BJAwcYwKOlw8j s9Q1Gy0qze8v7mO2gT70kjYFVRNHDrMkxdVhntBJvY4HyMcnP0cVy3kLF4L1GGDQNZ+1zQ+UUnzK 7zmNgXXLHjJ5YYHNakmo4XSZJtJvhH5DrIskI/u48srn7xKggdMUdwN+w1C01S0W7sZ0uIHJCyIe DgkH9Qar6P0vv+vyT+lZ/gyWY6VNDPYXdm6XUzgXMWzcryMy45PYjNaGj9L7/r8k/pQBo0UUUAZ+ t/8AIN/7bw/+jVrQrP1v/kG/9t4f/Rq1oUAZlt4i0m81STTLe7El3EzK6BGwpXqN2MZH1rTrjbfw /qZ07xA6XV7FPdS3gt7UyKsR3E7HHGQT1zmq90usava3zxWGqWYkt7OJA7eXISsxMhXDcfKevegH od1VSXVLGDUINPkuo1u7gExQ7vmYAZJx6YBrkrzSLuzguLRLXUbjSI9SDtbwzMZHhMI4UltxUSnJ GfWprqQ22p+HjbaHqhjtyXkbyvMZEaN0VXbcSSCwzycCgDpNU1rTtFhSXUbpbdHOFJBOcdeB2HrV uKWOaJJYnWSN1DK6nIYHoQa53xDrGojTzBZaRqG+eaS3eZIBIYoxwZAued38P5npg7OkRww6PZw2 8EsEMcKJHFMMOigYAYetADJf+Q/a/wDXrN/6FFV2T/VN/umqUv8AyH7X/r1m/wDQ4quyf6pv900A VNF/5Adh/wBe0f8A6CKhvfEWk6fqMenXV2EupApWIIzHDEgHgHGSD19Km0X/AJAdh/17R/8AoIrJ k0e6ufG0999qvbW3S1twPJZQk7K8hKtkEnAI6Y+9R1DodHRXFWKawL2ysZbG+X7Hc3bTXDN+6dXE hjwd2W+8vbjFVLXQtbstKH2E363d1ov+kGW4ZibgFOAWOFfaXAIwOnpQM7XUNUsdKhWa/uordGYI pkbG5icAD1p97e22nWj3d3MsUMf3nP5D61xepQxL4Omt9M8PawHmmAjimQySKQVLN8zEqpxjrya6 K91OWfT5wmm6rGDAjh4I0Eo3EghQT99cZIx3GM0CRoadqVnq1ot3YXCzwsSAy9iDggg8gj0NQaz/ AKu0/wCvyH/0KqHg21urTSp1uYZ4xJdSSRG5AE7q2DukxxuJz+GKv6z/AKu0/wCvyH/0KgDRoooo AKhuba2uowl1BFMgOQsqBhn8amrk/G9i+pXehWaQ2kzSXcn7u8jLxHELnlQRn296AOlWytFdZEtY Q6qFVhGMgDoAfQVHaabbWT3ckYLNeTGWYuc7jgLj6AADFcnqHiCbw+l/pjXNraTQW1r9hgSMKrEk q+xTyVyPfFTNq2srrMk329DZx6wlh9l8heUZFOS3XILcduOc0+odDq4rO1gRY4baKNEbcqogAB9R jvR9mtvtJufIi8/G3zdg349M9a891DV77U/DeoTN4lEF0jb5rCGJA9mqzAHJ+8AB1Ldeo4q7c61c 2ct+1vfweWzWUb6p5SHajqczNgbT2xn5Rn0pAdtFa28DFoYIo2YkkogBJPWpa4e21nWL4Wlna6zH Ik2oy2yakluh8+JYS+5R93IYFcjjjpUR8UajHFo0l3qkMfmM0c8UMaGW4YTeWCEbkqQDnZyM56UA d7RRRQAUUUUAZWpzx2uq2FxNuWJVlUsELAEhcdB7GpP7e03/AJ+G/wC/T/4Vo0UAZ39vab/z8N/3 6f8Awo/t7Tf+fhv+/T/4Vo0UAZ39vab/AM/Df9+n/wAKo6xrmnNpzyJOS8LJMP3T/wALBj29Aa36 juIRcW0sLdJEKn8RigCl/b+mf8/Df9+n/wAKbobiWC6lUNskupGQspXIz15qfSJjcaTayMSXMShs /wB4DB/UGrlABRRUNzdQWcJmuJVjQHGT3PoB3PsKAKuucaWzYYhZYmO1SSAJFJOB7Cox4k0hpWiW 8BkTG5BGxK56ZGOKXN/qfTfYWp7kfvpB/wCyD9fpV22tYLOLyoIwi5ye5J9STyT7mgCp/b2m/wDP w3/fp/8ACj+3tN/5+G/79P8A4Vo0UAZ39vab/wA/Df8Afp/8KP7e03/n4b/v0/8AhWjRQBnf29pv /Pw3/fp/8KP7e03/AJ+G/wC/T/4Vo0UAZMN7Bfa7A9szOsdtKGPlsACWjxyR7H8q1JATGwHXBp1F AGJpes2EGk2cMsrpJHAispifIIUAjpVr+3tN/wCfhv8Av0/+FaNFAGa3iDS1Us1yVUDJJicAfpQP EGmMARckg8giJ+f0p+tuU0S8I6tEyD6nj+tXVUIgUdAMUAUP7e03/n4b/v0/+FH9vab/AM/Df9+n /wAK0aKAM7+3tN/5+G/79P8A4VVvtTtL5rSG2d5JPtUTYETDgNknpW3RQAUUUUAFIQCQSASOntS0 UANZEYgsqkjgEijYv90dc9O9OooAZ5ceWOxcvwxx1+tHloFKhF2kYIxxj0p9FADQiKFAVQF6ADpS eXHlTsXK/dOOn0p9FABRRRQBWSO8GzfcwthjvxCRuHYD5uP1z7UJHegR77mFsBt+ICNx7Y+bjH45 9qs0UAVhHe4XdcwkhCDiAjLdj97p7frR5d7j/j5hz5eP9Qfv/wB773T2/WpJ7mC2UNPPHEpOAZGC g/nUP9q6d/0ELX/v8v8AjQA5o70httzCCUAXMBOG7n73I9v1oeO9PmbLmFchdmYCdp75+bnP4Y96 b/aunf8AQQtf+/y/40f2rp3/AEELX/v8v+NAD2jvCX2XMSgsCmYSdo7g/Nz9eMe9BjvMnFzEB5gI /cnhP7v3uvv+lM/tXTv+gha/9/l/xo/tXTv+gha/9/l/xoAp6Ul2n2m38+ICC9fI8o8o2HA+91+b r+lX1jvAU3XMRAYlsQkZXsB83B9+fpXF6h4zh0fxItpJPbo14yu0iuGjdFDA7TnAYjaMEjBHpW5H eWmrIJb7VbMWzcrbQXKlWH+24PzfQYH1oAnF/f3EiQ6fJBdMhYTTeSVhHpg7jkj0GfcrUltpNxFO t1cXkd1chWHmyQ/dJ6bBuwoHcdT61YTUtLjRUjvbREUYCrKoAH507+1dO/6CFr/3+X/GgB3l3uB/ pMOfLx/qD9/+997p7frQY73Bxcwg+WAP3B4fufvdPb9ab/aunf8AQQtf+/y/40f2rp3/AEELX/v8 v+NADnjvSH2XMKkqNmYCdp7k/Nzn8Me9Dx3h8zZcwrkjZmEnaO+fm5z+GPepILmC5UtBPHKoOCY2 DAflUtAFdo7wlttzEAXBXMJOF7j73J9/0o8u83f8fEWPNzjyT9z+797r7/pViigCusd4Cu65iIDk tiEjK9h97g+/6UiR3g8vfcwtgtvxCRuHbHzcY/HPtVmoZ7y1tiBcXMURboJHC5/OgBix3oCbrmEk KQ+ICNx7EfNxj05z7UCO9wM3MJPlkH9weX7H73T2/Wm/2rp3/QQtf+/y/wCNH9q6d/0ELX/v8v8A jQA7y73B/wBJhz5YA/cH7/8Ae+909v1oaO9IfbcwglQFzAThu5Pzcg+nb1NN/tXTv+gha/8Af5f8 aP7V07/oIWv/AH+X/GgCnrSXTWwi+0RYnuIEQeSTt+cFs/NznHtV9o7wl9tzEAXBXMJOF7g/Nyff j6Vz2t64kerWEEE9tOkrl4j5q7UdVbO854XkH/gJHUit1dV0/aN2oWpOOSJV/wAaAJDHeZOLiLHm 5H7k/c/u/e6+/wClAjvMjNzER5hJ/cnlOy/e6+/6Uz+1dO/6CFr/AN/l/wAaP7V07/oIWv8A3+X/ ABoAekd4DHvuYmAY78Qkbh2A+bjH459qRI70CPfcwsQG34gI3Htj5uMfjn2pv9q6d/0ELX/v8v8A jTo9RsZpBHFeW7u3RVlUk/hmgAEd6Au65hJ2EHEBGW7H73T2/Wjy73H/AB8w58vH+oP3/wC997p7 frVmigCs0d6Q226hBKALmAnDdz97ke361OgcD52DH2GKdRQAUUUUAFFFFABRRRQAUUUUAFFFFAGZ fRpLrenLIiuNk3DDPZau/Y7X/n2i/wC+BVS7/wCQ7p3+5N/Ja0aAIfsdr/z7Rf8AfAo+x2v/AD7R f98CpqQ9KAKsSadMxSJbWRl6hQpIqX7Ha/8APtF/3wK8+0G2u9C8ER6xELKHcIWZ7ex2TLF5o8wy Nk7/AJc54HrWlJrl9qshXTNSkjt59YS3juI4QcQm33Nt3DH3gcNz+NOwPQ7AWtuBgQRD/gAqPybE ymLy7cyAZKbVzj1xXGTa1fRW1lBqWuzafAHu45NQWBN0rxybY1OVKglcngc44xTxdaDd+O7aK3e0 t72zlLTzldk91K0ZHljuVAOTnjIAHQ4QHYtbWa43QQDJwMoOTTvsdr/z7Rf98CuP8VaxoEjaBqb3 kQY3kckTuWGIgTuYKenbJxXaqwdQynKkZBHejoHUi+x2v/PtF/3wKPsdr/z7Rf8AfAqaigDMsY0i 1vUVjRUGyHhRjs1adZ1p/wAhzUf9yH+TVo0AFFFFABWYYYpfEcnmRo+LRMblBx87Vp1nJ/yMcv8A 15p/6G1AFv7Ha/8APtF/3wKPsdr/AM+0X/fAqaigCoi6dLIY41tXdeqqFJH4VL9jtf8An2i/74Fe f6VZX2leFdR1q0SzSXdOUeGxxcgC4Jbc+TvG0Hjb6elX7nxDealPc/2RqTC2fULSCGdIgwVHHzlc jn68jNAdTsfslt/z7xf98CmeTY+b5XlW/mEZ2bVzj1xXGT6zqFtBFa6hrc1nax31zBLqQhTeQgBj UkqVBOTzt52470XN3oN74v062Wa1jv7eSKae9kQRzTsUwka8ZO4EFh0AwOp4AOzeGxi2iSK3TccL uVRk+gp/2O1/59ov++BXGeMtW8N6hp8EExs3nvlligurqPC2yg7XcEjIII4A5Jx2ya7O1KG0hMUn mxmNdshOdwxwfxoAPsdr/wA+0X/fAqhq1tBGtmyQxqwvIuQgB+9WrWdrP+rtP+vyH/0KgDRooooA KKKKACiiigAooooAKKKKACiiigAooooAzL50j1vTi7qo2Tcscdlq99pt/wDnvH/32KJ7W3ulC3EE UwU5AkQNj86g/sjTP+gdaf8Afhf8KAJ/tNv/AM94/wDvsUfabf8A57x/99ioP7I0z/oHWn/fhf8A Cj+yNM/6B1p/34X/AAoAn+02/wDz3j/77FH2m3/57x/99ioP7I0z/oHWn/fhf8KP7I0z/oHWn/fh f8KAJ/tNv/z3j/77FH2m3/57x/8AfYqD+yNM/wCgdaf9+F/wo/sjTP8AoHWn/fhf8KAJ/tNv/wA9 4/8AvsUfabf/AJ7x/wDfYqD+yNM/6B1p/wB+F/wo/sjTP+gdaf8Afhf8KAJ/tNv/AM94/wDvsUfa bf8A57x/99ioP7I0z/oHWn/fhf8ACj+yNM/6B1p/34X/AAoAgsnSTW9RKOrDZDypz2atOooLW3tV K28EUIY5IjQLn8qloAKKKKACszzY4/Ecu+RVzZpjccfxtWnUE9laXTBri1hmKjAMkYbH50AO+02/ /PeP/vsUfabf/nvH/wB9ioP7I0z/AKB1p/34X/Cj+yNM/wCgdaf9+F/woAn+02//AD3j/wC+xR9p t/8AnvH/AN9ioP7I0z/oHWn/AH4X/Cj+yNM/6B1p/wB+F/woAn+02/8Az3j/AO+xR9pt/wDnvH/3 2Kg/sjTP+gdaf9+F/wAKP7I0z/oHWn/fhf8ACgCf7Tb/APPeP/vsUfabf/nvH/32Kg/sjTP+gdaf 9+F/wo/sjTP+gdaf9+F/woAn+02//PeP/vsVQ1eeF0tFWVGP2yLgMP71WP7I0z/oHWn/AH4X/CnR 6ZYQyLJFY2yOvIZYlBH44oAtUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB/9k= --_004_8D15A2BAF93E9C49AB037A0647E5FA643F84DBFCeusaamb105erics_-- From nobody Wed Jun 3 19:13:09 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E18921B31A5 for ; Wed, 3 Jun 2015 19:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.889 X-Spam-Level: X-Spam-Status: No, score=-101.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_DOS_OUTLOOK_TO_MX_IMAGE=0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkkG61NQazwD for ; Wed, 3 Jun 2015 19:13:05 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id F32A81B31A1 for ; Wed, 3 Jun 2015 19:13:04 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.80.157; From: "Susan Hares" To: "'Zhoutianran'" , "'Dave Hood'" , "'STUART VENTERS'" , "'Natale, Bob'" References: In-Reply-To: Date: Wed, 3 Jun 2015 22:12:42 -0400 Message-ID: <006301d09e6b$f1041410$d30c3c30$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0064_01D09E4A.69F3FAB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK4lThatEBSexjSTWCPbfPbfl8B25vLrDfA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: sdn@irtf.org, ibnemo@ietf.org Subject: Re: [Sdn] [Ibnemo] role based intent X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 02:13:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0064_01D09E4A.69F3FAB0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0065_01D09E4A.69F3FAB0" ------=_NextPart_001_0065_01D09E4A.69F3FAB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Tiaran/Terence: Very interesting concept. It is the grouping of roles that make the intent layer. We look to this grouping the top of very specific acyclic graphs of lower layer functions. This emergence of the intent out of the essence of being is a new thought. Your theoretical examples are very interesting - but can you give me an example. In another two field (organizational dynamics and general systems theory), you are talking about groupings of functions emerging as systems. Does this formal language John Strassner was suggesting something like this idea? This is really insightful concept. Can you give me an example? Sue From: Ibnemo [mailto:ibnemo-bounces@ietf.org] On Behalf Of Zhoutianran Sent: Wednesday, June 03, 2015 2:30 AM To: Dave Hood; STUART VENTERS; Natale, Bob Cc: sdn@irtf.org; ibnemo@ietf.org Subject: [Ibnemo] role based intent Hi Dave, Stuart, Bob and all, I found many problems raised in the mailing list are coursed by the layered intent thinking. Maybe we are tainted by the ISO model:-) For the layered intent, intent is a spectrum, very abstract at the top layer, more network specific and less abstract when the layer goes down. The problem is that the boundary of intent and non intent is vague. Or there is no boundary between this two, since one's what may be another one's how. And consequently, it looks like everything is intent and no clear intent definition. The role based intent will provide only one intent layer. That is always the top layer abstraction for each role, as shown in the following figure. The functions can be layered as the implementation of the intent layer. With the role based intent, although the end user's intent is much abstracted then the network administrator's intent, they are not related each other. I.e., the end user will not use the administrator's intent. And the admin will not provide additional services/interfaces to the end user. The essential of layering is that the lower layer will provide interface to the higher layer. In order to fit up layer requirements, the lower layer will provide adequate interfaces/capabilities. That also means too much information for a dedicated up layer user/app. For role based intent, we can firstly indentify various roles (no need to be complete, but those with attention), and then figure out the intent of each role. In this way, intent can be clear defined. That will also keep the intent of each role to a small set on what they really cares about, without expending to support other one's intent. Best Regards, Terence ------=_NextPart_001_0065_01D09E4A.69F3FAB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tiaran/Terence: =

 

Very = interesting concept.  It is the grouping of roles that make the = intent layer.  We look to this grouping the top of very specific = acyclic graphs of lower layer functions.  This emergence of the = intent out of the essence of being is a new thought.  Your = theoretical examples are very interesting – but can you give me an = example.

 

In = another two field (organizational dynamics and general systems theory), = you are talking about groupings of functions emerging as systems.  =  Does this  formal language John Strassner was suggesting = something like this idea?

 

This is = really insightful concept.  Can you give me  an example? =

 

Sue =

 

From:= = Ibnemo [mailto:ibnemo-bounces@ietf.org] On Behalf Of = Zhoutianran
Sent: Wednesday, June 03, 2015 2:30 = AM
To: Dave Hood; STUART VENTERS; Natale, Bob
Cc: = sdn@irtf.org; ibnemo@ietf.org
Subject: [Ibnemo] role based = intent

 

Hi Dave, = Stuart, Bob and all,

 

I found = many problems raised in the mailing list are coursed by the layered = intent thinking. Maybe we are tainted by the ISO = model:-)

 

For the = layered intent, intent is a spectrum, very abstract at the top layer, = more network specific and less abstract when the layer goes down. The = problem is that the boundary of intent and non intent is vague. Or there = is no boundary between this two, since one's what may be another one's = how. And consequently, it looks like everything is intent and no clear = intent definition.

 

The role = based intent will provide only one intent layer. That is = always the top layer abstraction for each role, as shown = in the following figure. The functions can be layered as the = implementation of the intent layer.

With the = role based intent, although the end user's intent is much abstracted = then the network administrator's intent, they are not related each = other. I.e., the end user will not use the administrator's intent. And = the admin will not provide additional services/interfaces to the end = user.

 

The = essential of layering is that the lower layer will provide interface to = the higher layer. In order to fit up layer requirements, the lower layer = will provide adequate interfaces/capabilities. That also means too much = information for a dedicated up layer = user/app.

 

For role = based intent, we can firstly indentify various roles (no need to be = complete, but those with attention), and then figure out the intent of = each role. In this way, intent can be clear defined. That will also keep = the intent of each role to a small set on what they really cares about, = without expending to support other one’s = intent.

 

 

Best = Regards,

Terence

 

 

------=_NextPart_001_0065_01D09E4A.69F3FAB0-- ------=_NextPart_000_0064_01D09E4A.69F3FAB0 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCACPAUoDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2aiii gDK1OCO61bT4J13xFZSUJOCQFwf1NTf2Hpn/AD5x/rTbv/kO6d/uTfyWtGgCh/Yemf8APnH+tH9h 6Z/z5x/rUfiLU5tH0K5v7eFJpYgu1HbAYlgOT261h3viXXLH7aWt9OcaTEkl8N7qZd2TiLPT5R1b qeOKAOg/sPTP+fOP9aP7D0z/AJ84/wBa5e48RXuky6ilrBJd3F1qxhhVlaQRgQI5+UcnoeBjqTVm 8v8AU7vTdD1KVrnTZXv4Yp7MfKGzJtO7jOCBwPfmhagzf/sPTP8Anzj/AFo/sPTP+fOP9av0UAZm iIsSXsSDEcd26ouchRgcCtOs7SPv6h/1+P8AyWtGgDHjsba91nUDcxCXyzGF3E/KNgPFWf7D0z/n zj/Wm2P/ACGNT/34/wD0AVo0AUP7D0z/AJ84/wBaP7D0z/nzj/Wqeq6rqFvrdnp9lFbsksMk80kx bKojICFA6k7uKwp/E+qXWjyPcw2scGqaZcXFm1tKxlh2pkb+2cMORjBGKAOp/sPTP+fOP9aP7D0z /nzj/WuYXxbqkWoW+n2elyXcNvHbrcOI2ZmLqpJDdFwDnnrg9K0LSOY+MmNjqF7cW0SyfbxNLvhV zjYiDoGHJOOgxnk07ah0Nf8AsPTP+fOP9aiu9F01LOZltEBEbEEZ44rUqC9/48Z/+uTfypAM0xi2 lWjMSzGBCSTkn5RViQ4jYj0NVtL/AOQTZ/8AXBP/AEEVZk/1Tf7poAx9K0jT5tIspZbVHd7eNmZi SSSoyTVv+w9M/wCfOP8AWnaL/wAgOw/69o//AEEVdoAof2Hpn/PnH+tH9h6Z/wA+cf61iXviXVLe 51No7azNtZ3MdpEXdgzyyCPazHoqDzOepOKrT6vqM97aWF95Md1Z6tBHK9o7eXKrxswGDyPcHPY9 6FqD0Ok/sPTP+fOP9aP7D0z/AJ84/wBa5zRvFOp6/LKj6bNbWNxDIYblFMZjwcDLt8pJ9QOCO9Wv B0t6lzqtjfvdLJBJGyW9zcfaGiRk4/e/xZIY47UAbP8AYemf8+cf61U1DTrOzNpNbQLFJ9riXcpI OC2CK2qztZ/1dp/1+Q/+hUAaNFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAGdd/wDId07/AHJv 5LWjVW80+G9aN5GlR4s7HilZCM9eQfaof7Gh/wCfu+/8C5P8aALVzawXtu1vcxLLE+NyOMg4OR+o qreaFpOoXsN7eadbz3MGPLleMFlwcj8jzR/Y0P8Az933/gXJ/jR/Y0P/AD933/gXJ/jQAt1oelX1 vNBdWEE0U8olkV0B3OABu+uABmq914U0C9t7e3udJtpIrVdsCFOIx7Vkz6fczeJntYNXv4IkgGxT OzK0mcnIzn7pHQirZha041L+0I0H/LeC7lkj/EZ3L+Ix70AdAiLGiogCqoAAHYU6suHTbS5iEsF/ eSxt0ZL1yD+Oak/saH/n7vv/AALk/wAaAE0j7+of9fj/AMlrRqvZ2UNjE0cO8hmLszuXZie5JqxQ BnWP/IY1P/fj/wDQBWjVGbSbea5e48y5ikkxv8qd0DYGBwDim/2ND/z933/gXJ/jQBba2ga6S6aJ TOiFFkxyFJBI+hwPyqjb+HNFtXunt9Ltomu1KTlYwN6nqD7HPSoLuDT7JlSbUL7zW+7El1Izt9FB yagGlX179ye80+I/xSXbvKR7Lnav45+lAF+bw9o9xeQXk2m273FsFEUhjGVC/d/Lt6U228M6JZ6i dRttNgiu2ZnMqLglm+8fqcmq2l6Wslq6y3+oyPDNJGXa7fLAMQCcEDpirv8AY0P/AD933/gXJ/jQ BoVBe/8AHjP/ANcm/lVb+xof+fu+/wDAuT/GkbRYHUq11fEEYI+1yc/rQBNpf/IJs/8Argn/AKCK syf6pv8AdNJFEkMKRRjaiKFUegHSnEAjB6GgCnov/IDsP+vaP/0EVdrNj0O2ijWOO4vURAFVRdyY AHQdad/Y0P8Az933/gXJ/jQBNJplhNFdQy2kLx3hzcKyAiU4Ay3rwAPwqG10LSrK2it7bT4IooZf OjVUA2yf3vrz1qG6srKyi824v71Fzgf6XISx9AM5J9hWVf2N7JZG4iur+xj3oEBunaVyWAGckhRz 05P0oA14/DWhxT3M6aVarJdqVnPlD94D1B+vf1qxpuk6fo8DQadZxWsbNuZY1xuPqfWo/wCxof8A n7vv/AuT/Gj+xof+fu+/8C5P8aANCs7Wf9Xaf9fkP/oVL/Y0P/P3ff8AgXJ/jQujWwljd5rqXy3D qsly7LkdDgnmgDQooooATIBAyMnoKWuV8UzzWms2t1AcSwaXfujYzhgIyP1FYusTa0+galbXOsTy /wDEvtr4SpCiNGS53qMD7uFz3I55o6AeiUV55e+I9Yj163tLLV7drYJAbeS4lRft4b7zYEZ39x8h XBrQtb7WpdUjlk1Rzb3GqXNiLcQIBGiiQqwOMlgUHJ4wenegDsJJY4U3yyLGuQNzHAyTgfrT6870 8lvhv5Umoy300V7Ckqy7d0DC4TKHAB9+eefSpoPEWqXfjiTS4dQZIZpLiDynEZeAohKuEC5AyMgs x3A9B2AO+orz6bxTrs2iXV9CRCbQw2VwWUKIp937+TJU4C/KAcEDJJBxU+m6nrmpf2TanWYwtzNc B7m08uYyRoqlRuKBc5JBIXH40LUDuqKKKACis46QCc/2jf8A/f8A/wDrUf2OP+gjf/8Af/8A+tQB o0Vnf2OP+gjf/wDf/wD+tR/Y4/6CN/8A9/8A/wCtQBo0Vnf2OP8AoI3/AP3/AP8A61H9jj/oI3// AH//APrUAUScag94B93UhGT7GIJ/Mit+uU/skyeH7u5S/vi3mSzKPP6lZCV7f7IrYTSlkRXXUr8q wBB8/t+VAEk2kW7ytPbs9pcNyZYDt3H/AGh0b8RTPtOpWXF1bi7iH/La2GHH1jP/ALKT9KX+xx/0 Eb//AL//AP1qQ6Sqgs2pX4A5JNx0/SgC1aX1rfIWtplk28MBwyn0IPIP1qxXLXFlZ306tZS6jfTx n5Z4rkxonsZB1HsM/Soz4e1pFb7Zq15qEDjBt4bjyXXn+8AN/p/DQBvz6tbRSmCEPdXA6wwDcV/3 j0X8SKj8jU73/j5nFlEf+WVud0h+rkcfgPxqjp9pp7gWlvf31tIg/wCPZ5PLcf8AAcc/UZq//Y4/ 6CN//wB//wD61AFm0sLWxDC3hVC3LP1Zvqx5P41YrO/scf8AQRv/APv/AP8A1qP7HH/QRv8A/v8A /wD1qAHadhLvUYvS43f99Ip/nmr9YMGkhdZu4/7QvxuiikB8/rywPb2FXf7HH/QRv/8Av/8A/WoA 0aKzv7HH/QRv/wDv/wD/AFqP7HH/AEEb/wD7/wD/ANagDRorO/scf9BG/wD+/wD/APWqpdwQWrrD /aGozXDjKQRTZdvf2HucCgDb6VnNqUt2xi0uNZcHDXL/AOqX6f3z7Dj3FUk8Oz3isdS1G9EbYxbR 3BKj/ebALH26exq6NGVQFXUL4ADAAnwB+lAE1rpscEv2iZ2ubojBmk6geijoo9h+Oaj1bLCziH/L S7j/APHct/7LSf2OP+gjf/8Af/8A+tVG70onVLCIahfkZkkP7/phcen+1QBv0Vnf2OP+gjf/APf/ AP8ArUf2OP8AoI3/AP3/AP8A61AGjRWd/Y4/6CN//wB//wD61H9jj/oI3/8A3/8A/rUAaNFZ39jj /oI3/wD3/wD/AK1H9jj/AKCN/wD9/wD/AOtQBoYorP8A7HH/AEEb/wD7/wD/ANaj+xx/0Eb/AP7/ AP8A9agDQwOOBx0oxWf/AGOP+gjf/wDf/wD+tR/Y4/6CN/8A9/8A/wCtQBoYHpRgZzis/wDscf8A QRv/APv/AP8A1qP7HH/QRv8A/v8A/wD1qALNlY29hA0Num1XkeRskkszEsxJPqTU+AO1Z/8AY4/6 CN//AN//AP61H9jj/oI3/wD3/wD/AK1AGjRWd/Y4/wCgjf8A/f8A/wDrVoAYAHXHrQAtFFFABRVa 6v7eyaNZmfdLnYqRs5OOvCgmof7YtP7l3/4Bzf8AxNAF+kZgilicADJqj/bFp/cu/wDwDm/+JrP1 3VWfSZm0+K8kuEUssQtJR5vBBXle4PHvigC/o0QOg2qOOJIQzD/eGT/Om6ZdRwaHA91KkSwr5Ts7 ADKkr/Sud0PXtTls1guYprGVhkJLZSs0CAABVVV5xjJLHqTxirelPpsF5dmdby6njnLpJNaSsVDA NkDbheS3QCgDX/tG5vONNtCyn/l4uMpH+A+835Ae9KNIWch9Sne9bOdjDbEPog4P/As07+2LT+5d /wDgHN/8TVi0vIL2IywMWUMVO5CpBHUEEAigCYAKoVQAAMADtS0UUAQXVnbXsfl3MKSqORuHIPqD 2P0qp9kv7LmyuvtEf/PC6JJH0k6/mDV25uYbOBp52KxrgEhSTycDgcnkiqv9sWn9y7/8A5v/AImg BItXg8xYbxHspmOAs/Csf9lvun88+1aFZ0mqWE0bRyw3MiMMMrWMpB/DbVDzIbXnTJ72AD/lhJZT SRH6DblfwOPagDQYbPEMbf8APW1Yf98sv/xVaFcPc6trE3iK2iaxvEtXDbrqO2kK24wNwB2gndtG MjIJPbFdT/bFp/cu/wDwDm/+JoAv1HPPFbQtNPIscajJZjgCsy719YgqWtneTSPwC1pKqJ7sdv8A IE1DDNaGZbm+a7urhTlc2UwjiP8Asrt4+pyfegC1597qXFqGtLY/8t5F/eOP9hT0+rflVu0sbeyR hCmGc5d2O5nPqxPJplvqVtdT+RGZRJtLhZIXjyAQCRuAz1H51aJwMmgBaKz01uykRZI/tLowBVlt JSCPUHbS/wBsWn9y7/8AAOb/AOJoAv1nsS/iFB2itGP/AH04/wDiKX+2LT+5d/8AgHN/8TVODU4R q13O8N4EaONI2+xy843E/wAPq1AG3RVD+2LT+5d/+Ac3/wATR/bFp/cu/wDwDm/+JoAv0VQ/ti0/ uXf/AIBzf/E0q6xZtIkZM6GRgimS2kQEnoMlQKAL1FFFABRRXPeJLyGy1nw/Nc3KW8P2uUO8kgRf 9RJjJPHWgDoaK4a48Y3J8aW9lZ3cUtjLcpbMmIx96PduX5t7dQd23b296bL4v1iPT751iie40iBk vflwpnMm1TyeF2AyH2YcijoB3dFcHZeIPEF5ZW0AvbNJrjURbLdDypjsMTOcrGxUMCvHPTGRRaeK 9ck8Sz2xW3kggmlga3MkSyMEUkMF3byzEA424w340Ad3uG7bkZxnFLXCeF9Tm1XxXaXNxq1pfyS6 Q8pS3QL9nLSRkoeTnHTnB4Oa7ugAooooAKKKKAM67/5Dunf7k38lpup+ItJ0aeKC/uxDLMpZECMx IBwThQeORTrv/kO6d/uTfyWszVNHutQ8YWtxHc3lnBFYurT2zKu5vMQhDkHsCfwo6gdGDkZFLXGb NXTV/sJsr4qNZ+1faQw8ryCvTOc9eNuKrWGiazapa3Nt9sjv7iG9SdppmZQckw5BJAwcYwKOlw8j s9Q1Gy0qze8v7mO2gT70kjYFVRNHDrMkxdVhntBJvY4HyMcnP0cVy3kLF4L1GGDQNZ+1zQ+UUnzK 7zmNgXXLHjJ5YYHNakmo4XSZJtJvhH5DrIskI/u48srn7xKggdMUdwN+w1C01S0W7sZ0uIHJCyIe DgkH9Qar6P0vv+vyT+lZ/gyWY6VNDPYXdm6XUzgXMWzcryMy45PYjNaGj9L7/r8k/pQBo0UUUAZ+ t/8AIN/7bw/+jVrQrP1v/kG/9t4f/Rq1oUAZlt4i0m81STTLe7El3EzK6BGwpXqN2MZH1rTrjbfw /qZ07xA6XV7FPdS3gt7UyKsR3E7HHGQT1zmq90usava3zxWGqWYkt7OJA7eXISsxMhXDcfKevegH od1VSXVLGDUINPkuo1u7gExQ7vmYAZJx6YBrkrzSLuzguLRLXUbjSI9SDtbwzMZHhMI4UltxUSnJ GfWprqQ22p+HjbaHqhjtyXkbyvMZEaN0VXbcSSCwzycCgDpNU1rTtFhSXUbpbdHOFJBOcdeB2HrV uKWOaJJYnWSN1DK6nIYHoQa53xDrGojTzBZaRqG+eaS3eZIBIYoxwZAued38P5npg7OkRww6PZw2 8EsEMcKJHFMMOigYAYetADJf+Q/a/wDXrN/6FFV2T/VN/umqUv8AyH7X/r1m/wDQ4quyf6pv900A VNF/5Adh/wBe0f8A6CKhvfEWk6fqMenXV2EupApWIIzHDEgHgHGSD19Km0X/AJAdh/17R/8AoIrJ k0e6ufG0999qvbW3S1twPJZQk7K8hKtkEnAI6Y+9R1DodHRXFWKawL2ysZbG+X7Hc3bTXDN+6dXE hjwd2W+8vbjFVLXQtbstKH2E363d1ov+kGW4ZibgFOAWOFfaXAIwOnpQM7XUNUsdKhWa/uordGYI pkbG5icAD1p97e22nWj3d3MsUMf3nP5D61xepQxL4Omt9M8PawHmmAjimQySKQVLN8zEqpxjrya6 K91OWfT5wmm6rGDAjh4I0Eo3EghQT99cZIx3GM0CRoadqVnq1ot3YXCzwsSAy9iDggg8gj0NQaz/ AKu0/wCvyH/0KqHg21urTSp1uYZ4xJdSSRG5AE7q2DukxxuJz+GKv6z/AKu0/wCvyH/0KgDRoooo AKhuba2uowl1BFMgOQsqBhn8amrk/G9i+pXehWaQ2kzSXcn7u8jLxHELnlQRn296AOlWytFdZEtY Q6qFVhGMgDoAfQVHaabbWT3ckYLNeTGWYuc7jgLj6AADFcnqHiCbw+l/pjXNraTQW1r9hgSMKrEk q+xTyVyPfFTNq2srrMk329DZx6wlh9l8heUZFOS3XILcduOc0+odDq4rO1gRY4baKNEbcqogAB9R jvR9mtvtJufIi8/G3zdg349M9a891DV77U/DeoTN4lEF0jb5rCGJA9mqzAHJ+8AB1Ldeo4q7c61c 2ct+1vfweWzWUb6p5SHajqczNgbT2xn5Rn0pAdtFa28DFoYIo2YkkogBJPWpa4e21nWL4Wlna6zH Ik2oy2yakluh8+JYS+5R93IYFcjjjpUR8UajHFo0l3qkMfmM0c8UMaGW4YTeWCEbkqQDnZyM56UA d7RRRQAUUUUAZWpzx2uq2FxNuWJVlUsELAEhcdB7GpP7e03/AJ+G/wC/T/4Vo0UAZ39vab/z8N/3 6f8Awo/t7Tf+fhv+/T/4Vo0UAZ39vab/AM/Df9+n/wAKo6xrmnNpzyJOS8LJMP3T/wALBj29Aa36 juIRcW0sLdJEKn8RigCl/b+mf8/Df9+n/wAKbobiWC6lUNskupGQspXIz15qfSJjcaTayMSXMShs /wB4DB/UGrlABRRUNzdQWcJmuJVjQHGT3PoB3PsKAKuucaWzYYhZYmO1SSAJFJOB7Cox4k0hpWiW 8BkTG5BGxK56ZGOKXN/qfTfYWp7kfvpB/wCyD9fpV22tYLOLyoIwi5ye5J9STyT7mgCp/b2m/wDP w3/fp/8ACj+3tN/5+G/79P8A4Vo0UAZ39vab/wA/Df8Afp/8KP7e03/n4b/v0/8AhWjRQBnf29pv /Pw3/fp/8KP7e03/AJ+G/wC/T/4Vo0UAZMN7Bfa7A9szOsdtKGPlsACWjxyR7H8q1JATGwHXBp1F AGJpes2EGk2cMsrpJHAispifIIUAjpVr+3tN/wCfhv8Av0/+FaNFAGa3iDS1Us1yVUDJJicAfpQP EGmMARckg8giJ+f0p+tuU0S8I6tEyD6nj+tXVUIgUdAMUAUP7e03/n4b/v0/+FH9vab/AM/Df9+n /wAK0aKAM7+3tN/5+G/79P8A4VVvtTtL5rSG2d5JPtUTYETDgNknpW3RQAUUUUAFIQCQSASOntS0 UANZEYgsqkjgEijYv90dc9O9OooAZ5ceWOxcvwxx1+tHloFKhF2kYIxxj0p9FADQiKFAVQF6ADpS eXHlTsXK/dOOn0p9FABRRRQBWSO8GzfcwthjvxCRuHYD5uP1z7UJHegR77mFsBt+ICNx7Y+bjH45 9qs0UAVhHe4XdcwkhCDiAjLdj97p7frR5d7j/j5hz5eP9Qfv/wB773T2/WpJ7mC2UNPPHEpOAZGC g/nUP9q6d/0ELX/v8v8AjQA5o70httzCCUAXMBOG7n73I9v1oeO9PmbLmFchdmYCdp75+bnP4Y96 b/aunf8AQQtf+/y/40f2rp3/AEELX/v8v+NAD2jvCX2XMSgsCmYSdo7g/Nz9eMe9BjvMnFzEB5gI /cnhP7v3uvv+lM/tXTv+gha/9/l/xo/tXTv+gha/9/l/xoAp6Ul2n2m38+ICC9fI8o8o2HA+91+b r+lX1jvAU3XMRAYlsQkZXsB83B9+fpXF6h4zh0fxItpJPbo14yu0iuGjdFDA7TnAYjaMEjBHpW5H eWmrIJb7VbMWzcrbQXKlWH+24PzfQYH1oAnF/f3EiQ6fJBdMhYTTeSVhHpg7jkj0GfcrUltpNxFO t1cXkd1chWHmyQ/dJ6bBuwoHcdT61YTUtLjRUjvbREUYCrKoAH507+1dO/6CFr/3+X/GgB3l3uB/ pMOfLx/qD9/+997p7frQY73Bxcwg+WAP3B4fufvdPb9ab/aunf8AQQtf+/y/40f2rp3/AEELX/v8 v+NADnjvSH2XMKkqNmYCdp7k/Nzn8Me9Dx3h8zZcwrkjZmEnaO+fm5z+GPepILmC5UtBPHKoOCY2 DAflUtAFdo7wlttzEAXBXMJOF7j73J9/0o8u83f8fEWPNzjyT9z+797r7/pViigCusd4Cu65iIDk tiEjK9h97g+/6UiR3g8vfcwtgtvxCRuHbHzcY/HPtVmoZ7y1tiBcXMURboJHC5/OgBix3oCbrmEk KQ+ICNx7EfNxj05z7UCO9wM3MJPlkH9weX7H73T2/Wm/2rp3/QQtf+/y/wCNH9q6d/0ELX/v8v8A jQA7y73B/wBJhz5YA/cH7/8Ae+909v1oaO9IfbcwglQFzAThu5Pzcg+nb1NN/tXTv+gha/8Af5f8 aP7V07/oIWv/AH+X/GgCnrSXTWwi+0RYnuIEQeSTt+cFs/NznHtV9o7wl9tzEAXBXMJOF7g/Nyff j6Vz2t64kerWEEE9tOkrl4j5q7UdVbO854XkH/gJHUit1dV0/aN2oWpOOSJV/wAaAJDHeZOLiLHm 5H7k/c/u/e6+/wClAjvMjNzER5hJ/cnlOy/e6+/6Uz+1dO/6CFr/AN/l/wAaP7V07/oIWv8A3+X/ ABoAekd4DHvuYmAY78Qkbh2A+bjH459qRI70CPfcwsQG34gI3Htj5uMfjn2pv9q6d/0ELX/v8v8A jTo9RsZpBHFeW7u3RVlUk/hmgAEd6Au65hJ2EHEBGW7H73T2/Wjy73H/AB8w58vH+oP3/wC997p7 frVmigCs0d6Q226hBKALmAnDdz97ke361OgcD52DH2GKdRQAUUUUAFFFFABRRRQAUUUUAFFFFAGZ fRpLrenLIiuNk3DDPZau/Y7X/n2i/wC+BVS7/wCQ7p3+5N/Ja0aAIfsdr/z7Rf8AfAo+x2v/AD7R f98CpqQ9KAKsSadMxSJbWRl6hQpIqX7Ha/8APtF/3wK8+0G2u9C8ER6xELKHcIWZ7ex2TLF5o8wy Nk7/AJc54HrWlJrl9qshXTNSkjt59YS3juI4QcQm33Nt3DH3gcNz+NOwPQ7AWtuBgQRD/gAqPybE ymLy7cyAZKbVzj1xXGTa1fRW1lBqWuzafAHu45NQWBN0rxybY1OVKglcngc44xTxdaDd+O7aK3e0 t72zlLTzldk91K0ZHljuVAOTnjIAHQ4QHYtbWa43QQDJwMoOTTvsdr/z7Rf98CuP8VaxoEjaBqb3 kQY3kckTuWGIgTuYKenbJxXaqwdQynKkZBHejoHUi+x2v/PtF/3wKPsdr/z7Rf8AfAqaigDMsY0i 1vUVjRUGyHhRjs1adZ1p/wAhzUf9yH+TVo0AFFFFABWYYYpfEcnmRo+LRMblBx87Vp1nJ/yMcv8A 15p/6G1AFv7Ha/8APtF/3wKPsdr/AM+0X/fAqaigCoi6dLIY41tXdeqqFJH4VL9jtf8An2i/74Fe f6VZX2leFdR1q0SzSXdOUeGxxcgC4Jbc+TvG0Hjb6elX7nxDealPc/2RqTC2fULSCGdIgwVHHzlc jn68jNAdTsfslt/z7xf98CmeTY+b5XlW/mEZ2bVzj1xXGT6zqFtBFa6hrc1nax31zBLqQhTeQgBj UkqVBOTzt52470XN3oN74v062Wa1jv7eSKae9kQRzTsUwka8ZO4EFh0AwOp4AOzeGxi2iSK3TccL uVRk+gp/2O1/59ov++BXGeMtW8N6hp8EExs3nvlligurqPC2yg7XcEjIII4A5Jx2ya7O1KG0hMUn mxmNdshOdwxwfxoAPsdr/wA+0X/fAqhq1tBGtmyQxqwvIuQgB+9WrWdrP+rtP+vyH/0KgDRooooA KKKKACiiigAooooAKKKKACiiigAooooAzL50j1vTi7qo2Tcscdlq99pt/wDnvH/32KJ7W3ulC3EE UwU5AkQNj86g/sjTP+gdaf8Afhf8KAJ/tNv/AM94/wDvsUfabf8A57x/99ioP7I0z/oHWn/fhf8A Cj+yNM/6B1p/34X/AAoAn+02/wDz3j/77FH2m3/57x/99ioP7I0z/oHWn/fhf8KP7I0z/oHWn/fh f8KAJ/tNv/z3j/77FH2m3/57x/8AfYqD+yNM/wCgdaf9+F/wo/sjTP8AoHWn/fhf8KAJ/tNv/wA9 4/8AvsUfabf/AJ7x/wDfYqD+yNM/6B1p/wB+F/wo/sjTP+gdaf8Afhf8KAJ/tNv/AM94/wDvsUfa bf8A57x/99ioP7I0z/oHWn/fhf8ACj+yNM/6B1p/34X/AAoAgsnSTW9RKOrDZDypz2atOooLW3tV K28EUIY5IjQLn8qloAKKKKACszzY4/Ecu+RVzZpjccfxtWnUE9laXTBri1hmKjAMkYbH50AO+02/ /PeP/vsUfabf/nvH/wB9ioP7I0z/AKB1p/34X/Cj+yNM/wCgdaf9+F/woAn+02//AD3j/wC+xR9p t/8AnvH/AN9ioP7I0z/oHWn/AH4X/Cj+yNM/6B1p/wB+F/woAn+02/8Az3j/AO+xR9pt/wDnvH/3 2Kg/sjTP+gdaf9+F/wAKP7I0z/oHWn/fhf8ACgCf7Tb/APPeP/vsUfabf/nvH/32Kg/sjTP+gdaf 9+F/wo/sjTP+gdaf9+F/woAn+02//PeP/vsVQ1eeF0tFWVGP2yLgMP71WP7I0z/oHWn/AH4X/CnR 6ZYQyLJFY2yOvIZYlBH44oAtUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB/9k= ------=_NextPart_000_0064_01D09E4A.69F3FAB0-- From nobody Wed Jun 3 20:42:30 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAB51B33F2 for ; Wed, 3 Jun 2015 20:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.74 X-Spam-Level: * X-Spam-Status: No, score=1.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qw0bh_sSzy-Z for ; Wed, 3 Jun 2015 20:42:26 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4B911B33D4 for ; Wed, 3 Jun 2015 20:42:11 -0700 (PDT) Received: from 172.24.2.119 (EHLO nkgeml401-hub.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CMN01384; Thu, 04 Jun 2015 11:41:56 +0800 (CST) Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.7]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Thu, 4 Jun 2015 11:41:45 +0800 From: Xiayinben To: Dave Hood , Zhoutianran , STUART VENTERS , "Natale, Bob" Thread-Topic: role based intent Thread-Index: AdCdxq4VFvGDpUDvRK6YJXpiQnECmwANkqOQAAXMRWAAAGlUUAAUcpRA Date: Thu, 4 Jun 2015 03:41:44 +0000 Message-ID: <5FD31D8EDBF4EC468B36D86F04FDB2E87382877B@nkgeml507-mbs.china.huawei.com> References: <8D15A2BAF93E9C49AB037A0647E5FA643F84C6C3@eusaamb105.ericsson.se> <5FD31D8EDBF4EC468B36D86F04FDB2E873828241@nkgeml507-mbs.china.huawei.com> <8D15A2BAF93E9C49AB037A0647E5FA643F84DBFC@eusaamb105.ericsson.se> In-Reply-To: <8D15A2BAF93E9C49AB037A0647E5FA643F84DBFC@eusaamb105.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.111.53.87] Content-Type: multipart/related; boundary="_004_5FD31D8EDBF4EC468B36D86F04FDB2E87382877Bnkgeml507mbschi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "sdn@irtf.org" , "ibnemo@ietf.org" Subject: [Sdn] =?gb2312?b?tPC4tDogcm9sZSBiYXNlZCBpbnRlbnQ=?= X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 03:42:29 -0000 --_004_5FD31D8EDBF4EC468B36D86F04FDB2E87382877Bnkgeml507mbschi_ Content-Type: multipart/alternative; boundary="_000_5FD31D8EDBF4EC468B36D86F04FDB2E87382877Bnkgeml507mbschi_" --_000_5FD31D8EDBF4EC468B36D86F04FDB2E87382877Bnkgeml507mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 T0suIElmIHlvdSBhZ3JlZSB0aGF0IGFuIGludGVudCBpcyByZWxhdGVkIHdpdGggc3BlY2lmaWMg dXNlcqGvcyByb2xlLCBzbyAqbm90KiBpbnRlbnQgaXMgYWxzbyByZWxhdGVkIHdpdGggdXNlci4g V2hhdCB0aGUgdXNlciBkb2VzbqGvdCBjYXJlIGlzIG5vdCBoaXMgaW50ZW50Lg0KRm9yIGV4YW1w bGUsIEJEIG9mIFNQoa9zIGludGVudCBpcyBwcm92aWRpbmcgaGlnaGVyIFNMQSBndWFyYW50ZWUg dG8gdXNlcqGvcyBmbG93IHRoYW4gYmFja2dyb3VuZCBmbG93LiBCdXQgdGhhdCBtb3ZpbmcgYmFj a2dyb3VuZCBmbG93IHRvIG90aGVyIHBhdGggb3IgYmxvY2tpbmcgYmFja2dyb3VuZCBmbG93IGFy ZSBub3QgQkShr3MgY29uY2Vybiwgc28gdGhpcyBpcyBub3QgQkShr3MgaW50ZW50Lg0KDQpBYm91 dCBOQkkgZGVzaWduLCBJIHRoaW5rIGFueSBzeXN0ZW0gaGFzIGl0cyBzcGVjaWZpYyB0YXJnZXQg dXNlcnMsIFNETiBjb250cm9sbGVyIGlzIG5vIGV4Y2VwdGlvbi4NClNvIHdoZW4gd2UgY2xhcmlm eSB0aGUgdGFyZ2V0IHVzZXIgb2YgU0ROIGNvbnRyb2xsZXIsIHdlIHdpbGwgYmUgYWJsZSB0byBj bGVhcmx5IGRlZmluZSB3aGF0IGlzIGludGVudCBpbnRlcmZhY2Ugb2YgU0ROIGNvbnRyb2xsZXIu DQpIb3BlIHRoaXMgaXMgdXNlZnVsLiA6KQ0KDQpZaW5iZW4NCg0Kt6K8/sjLOiBEYXZlIEhvb2Qg W21haWx0bzpkYXZlLmhvb2RAZXJpY3Nzb24uY29tXQ0Kt6LLzcqxvOQ6IDIwMTXE6jbUwjPI1SAy Mzo1OQ0KytW8/sjLOiBYaWF5aW5iZW47IFpob3V0aWFucmFuOyBTVFVBUlQgVkVOVEVSUzsgTmF0 YWxlLCBCb2INCrOty806IHNkbkBpcnRmLm9yZzsgaWJuZW1vQGlldGYub3JnDQrW98ziOiBSRTog cm9sZSBiYXNlZCBpbnRlbnQNCg0KSSBkbyB0aGluayB0aGlzIGlzIGFjY2VwdGFibGUsIGJ1dCBp dCB0YWtlcyB1cyBiYWNrIHRvIHRoZSBwb2ludCB0aGF0IGFueSBOQkkgY29udmV5cyBpbnRlbnQs IGZvciBpdHMgdXNlciBhbmQgaXRzIHByb3ZpZGVyIGluIGl0cyBjb250ZXh0LCB3aGljaCByZW5k ZXJzIHRoZSBjb25jZXB0IG5vdCBwYXJ0aWN1bGFybHkgdXNlZnVsLiBJdCB3b3VsZCBiZSByZWFs bHkgaGVscGZ1bCB0byBzZWUgYSBjb25jcmV0ZSBleGFtcGxlIG9mIHNvbWV0aGluZyB0aGF0IHdl IGNhbiBhbGwgYWdyZWUgaXMgKm5vdCogaW50ZW50Lg0KDQpEYXZlDQoNCkZyb206IFhpYXlpbmJl biBbbWFpbHRvOnhpYXlpbmJlbkBodWF3ZWkuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBKdW5lIDAz LCAyMDE1IDg6NTMgQU0NClRvOiBEYXZlIEhvb2Q7IFpob3V0aWFucmFuOyBTVFVBUlQgVkVOVEVS UzsgTmF0YWxlLCBCb2INCkNjOiBzZG5AaXJ0Zi5vcmc8bWFpbHRvOnNkbkBpcnRmLm9yZz47IGli bmVtb0BpZXRmLm9yZzxtYWlsdG86aWJuZW1vQGlldGYub3JnPg0KU3ViamVjdDogtPC4tDogcm9s ZSBiYXNlZCBpbnRlbnQNCg0KSGkgRGF2ZSwNCg0KSSB0aGluayB0aGUgbWVhbmluZyBvZiChrm9u ZSBpbnRlbnQgbGF5ZXKhryBpcyB0aGF0IGVhY2ggcm9sZSBoYXMgb25lIGludGVudCBsYXllciBi dXQgbm90IGFsbCByb2xlcyBoYXZlIG9uZSBpbnRlbnQgbGF5ZXIuDQpBbmQgd2UgZG9uoa90IG5l ZWQgY2FyZSBhYm91dCB0aGUgbGF5ZXIgcmVsYXRpb25zaGlwIGJldHdlZW4gZGlmZmVyZW50IHJv bGWhr3MgaW50ZW50LiBTbyAgaW4gZ2VuZXJhbCwgdGhlcmUgaXMgb25seSBvbmUgaW50ZW50IGxh eWVyLg0KRG8geW91IHRoaW5rIHRoaXMgaXMgYWNjZXB0YWJsZT8NCg0KWWluYmVuDQoNCreivP7I yzogSWJuZW1vIFttYWlsdG86aWJuZW1vLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gRGF2ZSBIb29k DQq3osvNyrG85DogMjAxNcTqNtTCM8jVIDIxOjAzDQrK1bz+yMs6IFpob3V0aWFucmFuOyBTVFVB UlQgVkVOVEVSUzsgTmF0YWxlLCBCb2INCrOty806IHNkbkBpcnRmLm9yZzxtYWlsdG86c2RuQGly dGYub3JnPjsgaWJuZW1vQGlldGYub3JnPG1haWx0bzppYm5lbW9AaWV0Zi5vcmc+DQrW98ziOiBS ZTogW0libmVtb10gcm9sZSBiYXNlZCBpbnRlbnQNCg0KTGF5ZXJpbmcgaXMgdGhlIHJpZ2h0IGlz c3VlLCBidXQgdGhlIHBvaW50IGlzIGEgbGl0dGxlIGRpZmZlcmVudC4gV2UsIHdobyBsb29rIGF0 IHRoZSBnbG9iYWwgc2NlbmFyaW8gZnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgdGhlIGdvZHMsIHNl ZSB0aGF0IHRoZXJlIGlzIGEgcmVjdXJzaW9uIG9mIGNsaWVudHMvc2VydmVycyBvciBjdXN0b21l cnMvcHJvdmlkZXJzIG9yIKGtLg0KDQpCdXQgZnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgYW55IG9u ZSBvZiB0aG9zZSBpbnRlcmZhY2VzLCB0aGUgb3RoZXIgbGF5ZXJzIGFyZSBjb21wbGV0ZWx5IGlu dmlzaWJsZS4gU28gYSBnaXZlbiBhcHAgY2FuIGludm9rZSBpbnRlbnQgYWdhaW5zdCBhIGdpdmVu IFNETiBjb250cm9sbGVyLCBidXQgdGhlIGNvbnRyb2xsZXIgZG9lc26hr3Qga25vdyB3aGV0aGVy IHRoZSBhcHAgaXMganVzdCBhIG1pZGRsZW1hbiwgYW5kIHRoZSBhcHAgZG9lc26hr3Qga25vdyB3 aGV0aGVyIHRoZSBjb250cm9sbGVyIGNhbiBzYXRpc2Z5IGl0cyByZXF1aXJlbWVudHMgZGlyZWN0 bHkgb3Igd2hldGhlciBpdCBpcyBhbHNvIGp1c3QgYSBtaWRkbGVtYW4uDQoNCllvdSBjYW4gaGF2 ZSBvbmUgaW50ZW50IGxheWVyLCBhcyBsb25nIGFzIHlvdSByZWNvZ25pemUgdGhhdCB5b3UgYXJl IG9ubHkgc2VlaW5nIG9uZSBzbGljZSBvZiB0aGUgd29ybGQuIElmIHlvdSBpbnNpc3Qgb24gb25s eSBvbmUgbm9ydGhlcm5tb3N0IGludGVudCBsYXllciBpbiB0b3RvLCB5b3Ugd2lsbCBoYXZlIHRv IGdvIGJhY2sgdG8gdGhlIKGwbWFrZSBtb25leaGxIGludGVudCBvZiB0aGUgaW52ZXN0b3JzLg0K DQpBbmQgaWYgd2UgcmVjb2duaXplIHRoYXQgZWFjaCBpbnRlcmZhY2Ugc3RhbmRzIG9uIGl0cyBv d24sIHRoZW4gYW55IHNlcnZpY2UgaW52b2NhdGlvbiBhY3Jvc3MgdGhhdCBpbnRlcmZhY2UgcXVh bGlmaWVzIGFzIGFuIGV4cHJlc3Npb24gYW5kIHNhdGlzZmFjdGlvbiBvZiBpbnRlbnQgYnkgdGhh dCBwYXJ0aWN1bGFyIGludm9rZXItcHJvdmlkZXIgcGFpci4NCg0KRGF2ZQ0KDQpGcm9tOiBaaG91 dGlhbnJhbiBbbWFpbHRvOnpob3V0aWFucmFuQGh1YXdlaS5jb21dDQpTZW50OiBUdWVzZGF5LCBK dW5lIDAyLCAyMDE1IDExOjMwIFBNDQpUbzogRGF2ZSBIb29kOyBTVFVBUlQgVkVOVEVSUzsgTmF0 YWxlLCBCb2INCkNjOiBpYm5lbW9AaWV0Zi5vcmc8bWFpbHRvOmlibmVtb0BpZXRmLm9yZz47IHNk bkBpcnRmLm9yZzxtYWlsdG86c2RuQGlydGYub3JnPg0KU3ViamVjdDogcm9sZSBiYXNlZCBpbnRl bnQNCg0KDQpIaSBEYXZlLCBTdHVhcnQsIEJvYiBhbmQgYWxsLA0KDQoNCg0KSSBmb3VuZCBtYW55 IHByb2JsZW1zIHJhaXNlZCBpbiB0aGUgbWFpbGluZyBsaXN0IGFyZSBjb3Vyc2VkIGJ5IHRoZSBs YXllcmVkIGludGVudCB0aGlua2luZy4gTWF5YmUgd2UgYXJlIHRhaW50ZWQgYnkgdGhlIElTTyBt b2RlbDotKQ0KDQoNCg0KRm9yIHRoZSBsYXllcmVkIGludGVudCwgaW50ZW50IGlzIGEgc3BlY3Ry dW0sIHZlcnkgYWJzdHJhY3QgYXQgdGhlIHRvcCBsYXllciwgbW9yZSBuZXR3b3JrIHNwZWNpZmlj IGFuZCBsZXNzIGFic3RyYWN0IHdoZW4gdGhlIGxheWVyIGdvZXMgZG93bi4gVGhlIHByb2JsZW0g aXMgdGhhdCB0aGUgYm91bmRhcnkgb2YgaW50ZW50IGFuZCBub24gaW50ZW50IGlzIHZhZ3VlLiBP ciB0aGVyZSBpcyBubyBib3VuZGFyeSBiZXR3ZWVuIHRoaXMgdHdvLCBzaW5jZSBvbmUncyB3aGF0 IG1heSBiZSBhbm90aGVyIG9uZSdzIGhvdy4gQW5kIGNvbnNlcXVlbnRseSwgaXQgbG9va3MgbGlr ZSBldmVyeXRoaW5nIGlzIGludGVudCBhbmQgbm8gY2xlYXIgaW50ZW50IGRlZmluaXRpb24uDQoN Cg0KDQpUaGUgcm9sZSBiYXNlZCBpbnRlbnQgd2lsbCBwcm92aWRlIG9ubHkgb25lIGludGVudCBs YXllci4gVGhhdCBpcyBhbHdheXMgdGhlIHRvcCBsYXllciBhYnN0cmFjdGlvbiBmb3IgZWFjaCBy b2xlLCBhcyBzaG93biBpbiB0aGUgZm9sbG93aW5nIGZpZ3VyZS4gVGhlIGZ1bmN0aW9ucyBjYW4g YmUgbGF5ZXJlZCBhcyB0aGUgaW1wbGVtZW50YXRpb24gb2YgdGhlIGludGVudCBsYXllci4NCg0K W2NpZDppbWFnZTAwMS5qcGdAMDFEMDlFQUIuNTJGQkUzMjBdDQoNCldpdGggdGhlIHJvbGUgYmFz ZWQgaW50ZW50LCBhbHRob3VnaCB0aGUgZW5kIHVzZXIncyBpbnRlbnQgaXMgbXVjaCBhYnN0cmFj dGVkIHRoZW4gdGhlIG5ldHdvcmsgYWRtaW5pc3RyYXRvcidzIGludGVudCwgdGhleSBhcmUgbm90 IHJlbGF0ZWQgZWFjaCBvdGhlci4gSS5lLiwgdGhlIGVuZCB1c2VyIHdpbGwgbm90IHVzZSB0aGUg YWRtaW5pc3RyYXRvcidzIGludGVudC4gQW5kIHRoZSBhZG1pbiB3aWxsIG5vdCBwcm92aWRlIGFk ZGl0aW9uYWwgc2VydmljZXMvaW50ZXJmYWNlcyB0byB0aGUgZW5kIHVzZXIuDQoNCg0KDQpUaGUg ZXNzZW50aWFsIG9mIGxheWVyaW5nIGlzIHRoYXQgdGhlIGxvd2VyIGxheWVyIHdpbGwgcHJvdmlk ZSBpbnRlcmZhY2UgdG8gdGhlIGhpZ2hlciBsYXllci4gSW4gb3JkZXIgdG8gZml0IHVwIGxheWVy IHJlcXVpcmVtZW50cywgdGhlIGxvd2VyIGxheWVyIHdpbGwgcHJvdmlkZSBhZGVxdWF0ZSBpbnRl cmZhY2VzL2NhcGFiaWxpdGllcy4gVGhhdCBhbHNvIG1lYW5zIHRvbyBtdWNoIGluZm9ybWF0aW9u IGZvciBhIGRlZGljYXRlZCB1cCBsYXllciB1c2VyL2FwcC4NCg0KDQoNCkZvciByb2xlIGJhc2Vk IGludGVudCwgd2UgY2FuIGZpcnN0bHkgaW5kZW50aWZ5IHZhcmlvdXMgcm9sZXMgKG5vIG5lZWQg dG8gYmUgY29tcGxldGUsIGJ1dCB0aG9zZSB3aXRoIGF0dGVudGlvbiksIGFuZCB0aGVuIGZpZ3Vy ZSBvdXQgdGhlIGludGVudCBvZiBlYWNoIHJvbGUuIEluIHRoaXMgd2F5LCBpbnRlbnQgY2FuIGJl IGNsZWFyIGRlZmluZWQuIFRoYXQgd2lsbCBhbHNvIGtlZXAgdGhlIGludGVudCBvZiBlYWNoIHJv bGUgdG8gYSBzbWFsbCBzZXQgb24gd2hhdCB0aGV5IHJlYWxseSBjYXJlcyBhYm91dCwgd2l0aG91 dCBleHBlbmRpbmcgdG8gc3VwcG9ydCBvdGhlciBvbmWhr3MgaW50ZW50Lg0KDQoNCg0KDQoNCkJl c3QgUmVnYXJkcywNCg0KVGVyZW5jZQ0KDQoNCg0KDQo= --_000_5FD31D8EDBF4EC468B36D86F04FDB2E87382877Bnkgeml507mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

OK. If = you agree that an intent is related with specific user=A1=AFs role, so *= not* intent is also related with user. What the user doesn=A1=AFt care = is not his intent.

For exa= mple, BD of SP=A1=AFs intent is providing higher SLA gu= arantee to user=A1=AFs flow than background flow. But that moving backgroun= d flow to other path or blocking background flow are not BD=A1=AFs concern,= so this is not BD=A1=AFs intent.

&n= bsp;

About N= BI design, I think any system has its spec= ific target users, SDN controller is no exception.

So when= we clarify the target user of SDN controller, we will be able to clearly d= efine what is intent interface of SDN controller.

Hope th= is is useful. J=

&n= bsp;

Yinben<= o:p>

&n= bsp;

=B7=A2=BC=FE=C8=CB: Dave Hood [mailto:dave.hood@ericsson.com]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2015=C4=EA6=D4=C23=C8=D5 23:59
=CA=D5=BC=FE=C8=CB: Xiayinben; Zhoutianran; STUART VENTERS; Natale, Bob
=B3=AD=CB=CD: sdn@irtf.org; ibnemo@ietf.org
=D6=F7=CC=E2: RE: role based intent

 

I do = think this is acceptable, but it takes us back to the point that any NBI co= nveys intent, for its user and its provider in its context, which renders the concept not particularly useful. It would be really help= ful to see a concrete example of something that we can all agree is *not= * intent.

=  

Dave<= o:p>

=  

From: Xiayinben [<= a href=3D"mailto:xiayinben@huawei.com">mailto:xiayinben@huawei.com]
Sent: Wednesday, June 03, 2015 8:53 AM
To: Dave Hood; Zhoutianran; STUART VENTERS; Natale, Bob
Cc: sdn@irtf.org; ibnemo@ietf.org
Subject: =B4=F0=B8=B4: role based intent

 

Hi Dave= ,

&n= bsp;

I think= the meaning of =A1=AEone intent layer=A1=AF is that each role has one inte= nt layer but not all roles have one intent layer.

And we = don=A1=AFt need care about the layer relationship between different role=A1= =AFs intent. So  in general, there is only one intent layer.

Do you = think this is acceptable?

&n= bsp;

Yinben<= o:p>

&n= bsp;

=B7=A2=BC=FE=C8=CB: Ibnemo [mailto:ibnemo-bounces@ietf.org] =B4=FA= =B1=ED Dave Hood
=B7=A2= =CB=CD=CA=B1=BC=E4: 2015=C4=EA6=D4=C23=C8=D5 21:03
=CA=D5=BC=FE=C8=CB: Zhoutianran; STUART VENTERS; Natale, Bob
=B3=AD=CB=CD: sdn@irtf.org; ibnemo@ietf.org =D6=F7=CC=E2: Re: [Ibnemo] role based intent

 

Layer= ing is the right issue, but the point is a little different. We, who look a= t the global scenario from the perspective of the gods, see that there is a recursion of clients/servers or customers/providers or =A1= =AD.

=  

But f= rom the perspective of any one of those interfaces, the other layers are co= mpletely invisible. So a given app can invoke intent against a given SDN controller, but the controller doesn=A1=AFt know whether the a= pp is just a middleman, and the app doesn=A1=AFt know whether the controlle= r can satisfy its requirements directly or whether it is also just a middle= man.

=  

You c= an have one intent layer, as long as you recognize that you are only seeing= one slice of the world. If you insist on only one northernmost intent layer in toto, you will have to go back to the =A1=B0make money=A1= =B1 intent of the investors.

=  

And i= f we recognize that each interface stands on its own, then any service invo= cation across that interface qualifies as an expression and satisfaction of intent by that particular invoker-provider pair.

=  

Dave<= o:p>

=  

 

Hi Dave, Stuart, Bob and all,

 

I found many problems raised in the mailing list are cour= sed by the layered intent thinking. Maybe we are tainted by the ISO model:-= )

 

For the layered intent, intent is a spectrum, very abstra= ct at the top layer, more network specific and less abstract when the layer= goes down. The problem is that the boundary of intent and non intent is vague. Or there is no boundary between this two, = since one's what may be another one's how. And consequently, it looks like = everything is intent and no clear intent definition.

 

The role based intent will provide only one intent layer. That is always the top layer abs= traction for each role, as shown in the following figure. The funct= ions can be layered as the implementation of the intent layer.

With the role based intent, although the end user's inten= t is much abstracted then the network administrator's intent, they are not = related each other. I.e., the end user will not use the administrator's intent. And the admin will not provide additional = services/interfaces to the end user.

 

The essential of layering is that the lower layer will pr= ovide interface to the higher layer. In order to fit up layer requirements,= the lower layer will provide adequate interfaces/capabilities. That also means too much information for a dedicated up laye= r user/app.

 

For role based intent, we can firstly indentify various r= oles (no need to be complete, but those with attention), and then figure ou= t the intent of each role. In this way, intent can be clear defined. That will also keep the intent of each role to a small s= et on what they really cares about, without expending to support other one= =A1=AFs intent.

 

 

Best Regards,

Terence

 

 

--_000_5FD31D8EDBF4EC468B36D86F04FDB2E87382877Bnkgeml507mbschi_-- --_004_5FD31D8EDBF4EC468B36D86F04FDB2E87382877Bnkgeml507mbschi_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=9164; creation-date="Thu, 04 Jun 2015 03:41:42 GMT"; modification-date="Thu, 04 Jun 2015 03:41:42 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCACPAUoDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2aiii gDK1OCO61bT4J13xFZSUJOCQFwf1NTf2Hpn/AD5x/rTbv/kO6d/uTfyWtGgCh/Yemf8APnH+tH9h 6Z/z5x/rUfiLU5tH0K5v7eFJpYgu1HbAYlgOT261h3viXXLH7aWt9OcaTEkl8N7qZd2TiLPT5R1b qeOKAOg/sPTP+fOP9aP7D0z/AJ84/wBa5e48RXuky6ilrBJd3F1qxhhVlaQRgQI5+UcnoeBjqTVm 8v8AU7vTdD1KVrnTZXv4Yp7MfKGzJtO7jOCBwPfmhagzf/sPTP8Anzj/AFo/sPTP+fOP9av0UAZm iIsSXsSDEcd26ouchRgcCtOs7SPv6h/1+P8AyWtGgDHjsba91nUDcxCXyzGF3E/KNgPFWf7D0z/n zj/Wm2P/ACGNT/34/wD0AVo0AUP7D0z/AJ84/wBaP7D0z/nzj/Wqeq6rqFvrdnp9lFbsksMk80kx bKojICFA6k7uKwp/E+qXWjyPcw2scGqaZcXFm1tKxlh2pkb+2cMORjBGKAOp/sPTP+fOP9aP7D0z /nzj/WuYXxbqkWoW+n2elyXcNvHbrcOI2ZmLqpJDdFwDnnrg9K0LSOY+MmNjqF7cW0SyfbxNLvhV zjYiDoGHJOOgxnk07ah0Nf8AsPTP+fOP9aiu9F01LOZltEBEbEEZ44rUqC9/48Z/+uTfypAM0xi2 lWjMSzGBCSTkn5RViQ4jYj0NVtL/AOQTZ/8AXBP/AEEVZk/1Tf7poAx9K0jT5tIspZbVHd7eNmZi SSSoyTVv+w9M/wCfOP8AWnaL/wAgOw/69o//AEEVdoAof2Hpn/PnH+tH9h6Z/wA+cf61iXviXVLe 51No7azNtZ3MdpEXdgzyyCPazHoqDzOepOKrT6vqM97aWF95Md1Z6tBHK9o7eXKrxswGDyPcHPY9 6FqD0Ok/sPTP+fOP9aP7D0z/AJ84/wBa5zRvFOp6/LKj6bNbWNxDIYblFMZjwcDLt8pJ9QOCO9Wv B0t6lzqtjfvdLJBJGyW9zcfaGiRk4/e/xZIY47UAbP8AYemf8+cf61U1DTrOzNpNbQLFJ9riXcpI OC2CK2qztZ/1dp/1+Q/+hUAaNFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAGdd/wDId07/AHJv 5LWjVW80+G9aN5GlR4s7HilZCM9eQfaof7Gh/wCfu+/8C5P8aALVzawXtu1vcxLLE+NyOMg4OR+o qreaFpOoXsN7eadbz3MGPLleMFlwcj8jzR/Y0P8Az933/gXJ/jR/Y0P/AD933/gXJ/jQAt1oelX1 vNBdWEE0U8olkV0B3OABu+uABmq914U0C9t7e3udJtpIrVdsCFOIx7Vkz6fczeJntYNXv4IkgGxT OzK0mcnIzn7pHQirZha041L+0I0H/LeC7lkj/EZ3L+Ix70AdAiLGiogCqoAAHYU6suHTbS5iEsF/ eSxt0ZL1yD+Oak/saH/n7vv/AALk/wAaAE0j7+of9fj/AMlrRqvZ2UNjE0cO8hmLszuXZie5JqxQ BnWP/IY1P/fj/wDQBWjVGbSbea5e48y5ikkxv8qd0DYGBwDim/2ND/z933/gXJ/jQBba2ga6S6aJ TOiFFkxyFJBI+hwPyqjb+HNFtXunt9Ltomu1KTlYwN6nqD7HPSoLuDT7JlSbUL7zW+7El1Izt9FB yagGlX179ye80+I/xSXbvKR7Lnav45+lAF+bw9o9xeQXk2m273FsFEUhjGVC/d/Lt6U228M6JZ6i dRttNgiu2ZnMqLglm+8fqcmq2l6Wslq6y3+oyPDNJGXa7fLAMQCcEDpirv8AY0P/AD933/gXJ/jQ BoVBe/8AHjP/ANcm/lVb+xof+fu+/wDAuT/GkbRYHUq11fEEYI+1yc/rQBNpf/IJs/8Argn/AKCK syf6pv8AdNJFEkMKRRjaiKFUegHSnEAjB6GgCnov/IDsP+vaP/0EVdrNj0O2ijWOO4vURAFVRdyY AHQdad/Y0P8Az933/gXJ/jQBNJplhNFdQy2kLx3hzcKyAiU4Ay3rwAPwqG10LSrK2it7bT4IooZf OjVUA2yf3vrz1qG6srKyi824v71Fzgf6XISx9AM5J9hWVf2N7JZG4iur+xj3oEBunaVyWAGckhRz 05P0oA14/DWhxT3M6aVarJdqVnPlD94D1B+vf1qxpuk6fo8DQadZxWsbNuZY1xuPqfWo/wCxof8A n7vv/AuT/Gj+xof+fu+/8C5P8aANCs7Wf9Xaf9fkP/oVL/Y0P/P3ff8AgXJ/jQujWwljd5rqXy3D qsly7LkdDgnmgDQooooATIBAyMnoKWuV8UzzWms2t1AcSwaXfujYzhgIyP1FYusTa0+galbXOsTy /wDEvtr4SpCiNGS53qMD7uFz3I55o6AeiUV55e+I9Yj163tLLV7drYJAbeS4lRft4b7zYEZ39x8h XBrQtb7WpdUjlk1Rzb3GqXNiLcQIBGiiQqwOMlgUHJ4wenegDsJJY4U3yyLGuQNzHAyTgfrT6870 8lvhv5Umoy300V7Ckqy7d0DC4TKHAB9+eefSpoPEWqXfjiTS4dQZIZpLiDynEZeAohKuEC5AyMgs x3A9B2AO+orz6bxTrs2iXV9CRCbQw2VwWUKIp937+TJU4C/KAcEDJJBxU+m6nrmpf2TanWYwtzNc B7m08uYyRoqlRuKBc5JBIXH40LUDuqKKKACis46QCc/2jf8A/f8A/wDrUf2OP+gjf/8Af/8A+tQB o0Vnf2OP+gjf/wDf/wD+tR/Y4/6CN/8A9/8A/wCtQBo0Vnf2OP8AoI3/AP3/AP8A61H9jj/oI3// AH//APrUAUScag94B93UhGT7GIJ/Mit+uU/skyeH7u5S/vi3mSzKPP6lZCV7f7IrYTSlkRXXUr8q wBB8/t+VAEk2kW7ytPbs9pcNyZYDt3H/AGh0b8RTPtOpWXF1bi7iH/La2GHH1jP/ALKT9KX+xx/0 Eb//AL//AP1qQ6Sqgs2pX4A5JNx0/SgC1aX1rfIWtplk28MBwyn0IPIP1qxXLXFlZ306tZS6jfTx n5Z4rkxonsZB1HsM/Soz4e1pFb7Zq15qEDjBt4bjyXXn+8AN/p/DQBvz6tbRSmCEPdXA6wwDcV/3 j0X8SKj8jU73/j5nFlEf+WVud0h+rkcfgPxqjp9pp7gWlvf31tIg/wCPZ5PLcf8AAcc/UZq//Y4/ 6CN//wB//wD61AFm0sLWxDC3hVC3LP1Zvqx5P41YrO/scf8AQRv/APv/AP8A1qP7HH/QRv8A/v8A /wD1qAHadhLvUYvS43f99Ip/nmr9YMGkhdZu4/7QvxuiikB8/rywPb2FXf7HH/QRv/8Av/8A/WoA 0aKzv7HH/QRv/wDv/wD/AFqP7HH/AEEb/wD7/wD/ANagDRorO/scf9BG/wD+/wD/APWqpdwQWrrD /aGozXDjKQRTZdvf2HucCgDb6VnNqUt2xi0uNZcHDXL/AOqX6f3z7Dj3FUk8Oz3isdS1G9EbYxbR 3BKj/ebALH26exq6NGVQFXUL4ADAAnwB+lAE1rpscEv2iZ2ubojBmk6geijoo9h+Oaj1bLCziH/L S7j/APHct/7LSf2OP+gjf/8Af/8A+tVG70onVLCIahfkZkkP7/phcen+1QBv0Vnf2OP+gjf/APf/ AP8ArUf2OP8AoI3/AP3/AP8A61AGjRWd/Y4/6CN//wB//wD61H9jj/oI3/8A3/8A/rUAaNFZ39jj /oI3/wD3/wD/AK1H9jj/AKCN/wD9/wD/AOtQBoYorP8A7HH/AEEb/wD7/wD/ANaj+xx/0Eb/AP7/ AP8A9agDQwOOBx0oxWf/AGOP+gjf/wDf/wD+tR/Y4/6CN/8A9/8A/wCtQBoYHpRgZzis/wDscf8A QRv/APv/AP8A1qP7HH/QRv8A/v8A/wD1qALNlY29hA0Num1XkeRskkszEsxJPqTU+AO1Z/8AY4/6 CN//AN//AP61H9jj/oI3/wD3/wD/AK1AGjRWd/Y4/wCgjf8A/f8A/wDrVoAYAHXHrQAtFFFABRVa 6v7eyaNZmfdLnYqRs5OOvCgmof7YtP7l3/4Bzf8AxNAF+kZgilicADJqj/bFp/cu/wDwDm/+JrP1 3VWfSZm0+K8kuEUssQtJR5vBBXle4PHvigC/o0QOg2qOOJIQzD/eGT/Om6ZdRwaHA91KkSwr5Ts7 ADKkr/Sud0PXtTls1guYprGVhkJLZSs0CAABVVV5xjJLHqTxirelPpsF5dmdby6njnLpJNaSsVDA NkDbheS3QCgDX/tG5vONNtCyn/l4uMpH+A+835Ae9KNIWch9Sne9bOdjDbEPog4P/As07+2LT+5d /wDgHN/8TVi0vIL2IywMWUMVO5CpBHUEEAigCYAKoVQAAMADtS0UUAQXVnbXsfl3MKSqORuHIPqD 2P0qp9kv7LmyuvtEf/PC6JJH0k6/mDV25uYbOBp52KxrgEhSTycDgcnkiqv9sWn9y7/8A5v/AImg BItXg8xYbxHspmOAs/Csf9lvun88+1aFZ0mqWE0bRyw3MiMMMrWMpB/DbVDzIbXnTJ72AD/lhJZT SRH6DblfwOPagDQYbPEMbf8APW1Yf98sv/xVaFcPc6trE3iK2iaxvEtXDbrqO2kK24wNwB2gndtG MjIJPbFdT/bFp/cu/wDwDm/+JoAv1HPPFbQtNPIscajJZjgCsy719YgqWtneTSPwC1pKqJ7sdv8A IE1DDNaGZbm+a7urhTlc2UwjiP8Asrt4+pyfegC1597qXFqGtLY/8t5F/eOP9hT0+rflVu0sbeyR hCmGc5d2O5nPqxPJplvqVtdT+RGZRJtLhZIXjyAQCRuAz1H51aJwMmgBaKz01uykRZI/tLowBVlt JSCPUHbS/wBsWn9y7/8AAOb/AOJoAv1nsS/iFB2itGP/AH04/wDiKX+2LT+5d/8AgHN/8TVODU4R q13O8N4EaONI2+xy843E/wAPq1AG3RVD+2LT+5d/+Ac3/wATR/bFp/cu/wDwDm/+JoAv0VQ/ti0/ uXf/AIBzf/E0q6xZtIkZM6GRgimS2kQEnoMlQKAL1FFFABRRXPeJLyGy1nw/Nc3KW8P2uUO8kgRf 9RJjJPHWgDoaK4a48Y3J8aW9lZ3cUtjLcpbMmIx96PduX5t7dQd23b296bL4v1iPT751iie40iBk vflwpnMm1TyeF2AyH2YcijoB3dFcHZeIPEF5ZW0AvbNJrjURbLdDypjsMTOcrGxUMCvHPTGRRaeK 9ck8Sz2xW3kggmlga3MkSyMEUkMF3byzEA424w340Ad3uG7bkZxnFLXCeF9Tm1XxXaXNxq1pfyS6 Q8pS3QL9nLSRkoeTnHTnB4Oa7ugAooooAKKKKAM67/5Dunf7k38lpup+ItJ0aeKC/uxDLMpZECMx IBwThQeORTrv/kO6d/uTfyWszVNHutQ8YWtxHc3lnBFYurT2zKu5vMQhDkHsCfwo6gdGDkZFLXGb NXTV/sJsr4qNZ+1faQw8ryCvTOc9eNuKrWGiazapa3Nt9sjv7iG9SdppmZQckw5BJAwcYwKOlw8j s9Q1Gy0qze8v7mO2gT70kjYFVRNHDrMkxdVhntBJvY4HyMcnP0cVy3kLF4L1GGDQNZ+1zQ+UUnzK 7zmNgXXLHjJ5YYHNakmo4XSZJtJvhH5DrIskI/u48srn7xKggdMUdwN+w1C01S0W7sZ0uIHJCyIe DgkH9Qar6P0vv+vyT+lZ/gyWY6VNDPYXdm6XUzgXMWzcryMy45PYjNaGj9L7/r8k/pQBo0UUUAZ+ t/8AIN/7bw/+jVrQrP1v/kG/9t4f/Rq1oUAZlt4i0m81STTLe7El3EzK6BGwpXqN2MZH1rTrjbfw /qZ07xA6XV7FPdS3gt7UyKsR3E7HHGQT1zmq90usava3zxWGqWYkt7OJA7eXISsxMhXDcfKevegH od1VSXVLGDUINPkuo1u7gExQ7vmYAZJx6YBrkrzSLuzguLRLXUbjSI9SDtbwzMZHhMI4UltxUSnJ GfWprqQ22p+HjbaHqhjtyXkbyvMZEaN0VXbcSSCwzycCgDpNU1rTtFhSXUbpbdHOFJBOcdeB2HrV uKWOaJJYnWSN1DK6nIYHoQa53xDrGojTzBZaRqG+eaS3eZIBIYoxwZAued38P5npg7OkRww6PZw2 8EsEMcKJHFMMOigYAYetADJf+Q/a/wDXrN/6FFV2T/VN/umqUv8AyH7X/r1m/wDQ4quyf6pv900A VNF/5Adh/wBe0f8A6CKhvfEWk6fqMenXV2EupApWIIzHDEgHgHGSD19Km0X/AJAdh/17R/8AoIrJ k0e6ufG0999qvbW3S1twPJZQk7K8hKtkEnAI6Y+9R1DodHRXFWKawL2ysZbG+X7Hc3bTXDN+6dXE hjwd2W+8vbjFVLXQtbstKH2E363d1ov+kGW4ZibgFOAWOFfaXAIwOnpQM7XUNUsdKhWa/uordGYI pkbG5icAD1p97e22nWj3d3MsUMf3nP5D61xepQxL4Omt9M8PawHmmAjimQySKQVLN8zEqpxjrya6 K91OWfT5wmm6rGDAjh4I0Eo3EghQT99cZIx3GM0CRoadqVnq1ot3YXCzwsSAy9iDggg8gj0NQaz/ AKu0/wCvyH/0KqHg21urTSp1uYZ4xJdSSRG5AE7q2DukxxuJz+GKv6z/AKu0/wCvyH/0KgDRoooo AKhuba2uowl1BFMgOQsqBhn8amrk/G9i+pXehWaQ2kzSXcn7u8jLxHELnlQRn296AOlWytFdZEtY Q6qFVhGMgDoAfQVHaabbWT3ckYLNeTGWYuc7jgLj6AADFcnqHiCbw+l/pjXNraTQW1r9hgSMKrEk q+xTyVyPfFTNq2srrMk329DZx6wlh9l8heUZFOS3XILcduOc0+odDq4rO1gRY4baKNEbcqogAB9R jvR9mtvtJufIi8/G3zdg349M9a891DV77U/DeoTN4lEF0jb5rCGJA9mqzAHJ+8AB1Ldeo4q7c61c 2ct+1vfweWzWUb6p5SHajqczNgbT2xn5Rn0pAdtFa28DFoYIo2YkkogBJPWpa4e21nWL4Wlna6zH Ik2oy2yakluh8+JYS+5R93IYFcjjjpUR8UajHFo0l3qkMfmM0c8UMaGW4YTeWCEbkqQDnZyM56UA d7RRRQAUUUUAZWpzx2uq2FxNuWJVlUsELAEhcdB7GpP7e03/AJ+G/wC/T/4Vo0UAZ39vab/z8N/3 6f8Awo/t7Tf+fhv+/T/4Vo0UAZ39vab/AM/Df9+n/wAKo6xrmnNpzyJOS8LJMP3T/wALBj29Aa36 juIRcW0sLdJEKn8RigCl/b+mf8/Df9+n/wAKbobiWC6lUNskupGQspXIz15qfSJjcaTayMSXMShs /wB4DB/UGrlABRRUNzdQWcJmuJVjQHGT3PoB3PsKAKuucaWzYYhZYmO1SSAJFJOB7Cox4k0hpWiW 8BkTG5BGxK56ZGOKXN/qfTfYWp7kfvpB/wCyD9fpV22tYLOLyoIwi5ye5J9STyT7mgCp/b2m/wDP w3/fp/8ACj+3tN/5+G/79P8A4Vo0UAZ39vab/wA/Df8Afp/8KP7e03/n4b/v0/8AhWjRQBnf29pv /Pw3/fp/8KP7e03/AJ+G/wC/T/4Vo0UAZMN7Bfa7A9szOsdtKGPlsACWjxyR7H8q1JATGwHXBp1F AGJpes2EGk2cMsrpJHAispifIIUAjpVr+3tN/wCfhv8Av0/+FaNFAGa3iDS1Us1yVUDJJicAfpQP EGmMARckg8giJ+f0p+tuU0S8I6tEyD6nj+tXVUIgUdAMUAUP7e03/n4b/v0/+FH9vab/AM/Df9+n /wAK0aKAM7+3tN/5+G/79P8A4VVvtTtL5rSG2d5JPtUTYETDgNknpW3RQAUUUUAFIQCQSASOntS0 UANZEYgsqkjgEijYv90dc9O9OooAZ5ceWOxcvwxx1+tHloFKhF2kYIxxj0p9FADQiKFAVQF6ADpS eXHlTsXK/dOOn0p9FABRRRQBWSO8GzfcwthjvxCRuHYD5uP1z7UJHegR77mFsBt+ICNx7Y+bjH45 9qs0UAVhHe4XdcwkhCDiAjLdj97p7frR5d7j/j5hz5eP9Qfv/wB773T2/WpJ7mC2UNPPHEpOAZGC g/nUP9q6d/0ELX/v8v8AjQA5o70httzCCUAXMBOG7n73I9v1oeO9PmbLmFchdmYCdp75+bnP4Y96 b/aunf8AQQtf+/y/40f2rp3/AEELX/v8v+NAD2jvCX2XMSgsCmYSdo7g/Nz9eMe9BjvMnFzEB5gI /cnhP7v3uvv+lM/tXTv+gha/9/l/xo/tXTv+gha/9/l/xoAp6Ul2n2m38+ICC9fI8o8o2HA+91+b r+lX1jvAU3XMRAYlsQkZXsB83B9+fpXF6h4zh0fxItpJPbo14yu0iuGjdFDA7TnAYjaMEjBHpW5H eWmrIJb7VbMWzcrbQXKlWH+24PzfQYH1oAnF/f3EiQ6fJBdMhYTTeSVhHpg7jkj0GfcrUltpNxFO t1cXkd1chWHmyQ/dJ6bBuwoHcdT61YTUtLjRUjvbREUYCrKoAH507+1dO/6CFr/3+X/GgB3l3uB/ pMOfLx/qD9/+997p7frQY73Bxcwg+WAP3B4fufvdPb9ab/aunf8AQQtf+/y/40f2rp3/AEELX/v8 v+NADnjvSH2XMKkqNmYCdp7k/Nzn8Me9Dx3h8zZcwrkjZmEnaO+fm5z+GPepILmC5UtBPHKoOCY2 DAflUtAFdo7wlttzEAXBXMJOF7j73J9/0o8u83f8fEWPNzjyT9z+797r7/pViigCusd4Cu65iIDk tiEjK9h97g+/6UiR3g8vfcwtgtvxCRuHbHzcY/HPtVmoZ7y1tiBcXMURboJHC5/OgBix3oCbrmEk KQ+ICNx7EfNxj05z7UCO9wM3MJPlkH9weX7H73T2/Wm/2rp3/QQtf+/y/wCNH9q6d/0ELX/v8v8A jQA7y73B/wBJhz5YA/cH7/8Ae+909v1oaO9IfbcwglQFzAThu5Pzcg+nb1NN/tXTv+gha/8Af5f8 aP7V07/oIWv/AH+X/GgCnrSXTWwi+0RYnuIEQeSTt+cFs/NznHtV9o7wl9tzEAXBXMJOF7g/Nyff j6Vz2t64kerWEEE9tOkrl4j5q7UdVbO854XkH/gJHUit1dV0/aN2oWpOOSJV/wAaAJDHeZOLiLHm 5H7k/c/u/e6+/wClAjvMjNzER5hJ/cnlOy/e6+/6Uz+1dO/6CFr/AN/l/wAaP7V07/oIWv8A3+X/ ABoAekd4DHvuYmAY78Qkbh2A+bjH459qRI70CPfcwsQG34gI3Htj5uMfjn2pv9q6d/0ELX/v8v8A jTo9RsZpBHFeW7u3RVlUk/hmgAEd6Au65hJ2EHEBGW7H73T2/Wjy73H/AB8w58vH+oP3/wC997p7 frVmigCs0d6Q226hBKALmAnDdz97ke361OgcD52DH2GKdRQAUUUUAFFFFABRRRQAUUUUAFFFFAGZ fRpLrenLIiuNk3DDPZau/Y7X/n2i/wC+BVS7/wCQ7p3+5N/Ja0aAIfsdr/z7Rf8AfAo+x2v/AD7R f98CpqQ9KAKsSadMxSJbWRl6hQpIqX7Ha/8APtF/3wK8+0G2u9C8ER6xELKHcIWZ7ex2TLF5o8wy Nk7/AJc54HrWlJrl9qshXTNSkjt59YS3juI4QcQm33Nt3DH3gcNz+NOwPQ7AWtuBgQRD/gAqPybE ymLy7cyAZKbVzj1xXGTa1fRW1lBqWuzafAHu45NQWBN0rxybY1OVKglcngc44xTxdaDd+O7aK3e0 t72zlLTzldk91K0ZHljuVAOTnjIAHQ4QHYtbWa43QQDJwMoOTTvsdr/z7Rf98CuP8VaxoEjaBqb3 kQY3kckTuWGIgTuYKenbJxXaqwdQynKkZBHejoHUi+x2v/PtF/3wKPsdr/z7Rf8AfAqaigDMsY0i 1vUVjRUGyHhRjs1adZ1p/wAhzUf9yH+TVo0AFFFFABWYYYpfEcnmRo+LRMblBx87Vp1nJ/yMcv8A 15p/6G1AFv7Ha/8APtF/3wKPsdr/AM+0X/fAqaigCoi6dLIY41tXdeqqFJH4VL9jtf8An2i/74Fe f6VZX2leFdR1q0SzSXdOUeGxxcgC4Jbc+TvG0Hjb6elX7nxDealPc/2RqTC2fULSCGdIgwVHHzlc jn68jNAdTsfslt/z7xf98CmeTY+b5XlW/mEZ2bVzj1xXGT6zqFtBFa6hrc1nax31zBLqQhTeQgBj UkqVBOTzt52470XN3oN74v062Wa1jv7eSKae9kQRzTsUwka8ZO4EFh0AwOp4AOzeGxi2iSK3TccL uVRk+gp/2O1/59ov++BXGeMtW8N6hp8EExs3nvlligurqPC2yg7XcEjIII4A5Jx2ya7O1KG0hMUn mxmNdshOdwxwfxoAPsdr/wA+0X/fAqhq1tBGtmyQxqwvIuQgB+9WrWdrP+rtP+vyH/0KgDRooooA KKKKACiiigAooooAKKKKACiiigAooooAzL50j1vTi7qo2Tcscdlq99pt/wDnvH/32KJ7W3ulC3EE UwU5AkQNj86g/sjTP+gdaf8Afhf8KAJ/tNv/AM94/wDvsUfabf8A57x/99ioP7I0z/oHWn/fhf8A Cj+yNM/6B1p/34X/AAoAn+02/wDz3j/77FH2m3/57x/99ioP7I0z/oHWn/fhf8KP7I0z/oHWn/fh f8KAJ/tNv/z3j/77FH2m3/57x/8AfYqD+yNM/wCgdaf9+F/wo/sjTP8AoHWn/fhf8KAJ/tNv/wA9 4/8AvsUfabf/AJ7x/wDfYqD+yNM/6B1p/wB+F/wo/sjTP+gdaf8Afhf8KAJ/tNv/AM94/wDvsUfa bf8A57x/99ioP7I0z/oHWn/fhf8ACj+yNM/6B1p/34X/AAoAgsnSTW9RKOrDZDypz2atOooLW3tV K28EUIY5IjQLn8qloAKKKKACszzY4/Ecu+RVzZpjccfxtWnUE9laXTBri1hmKjAMkYbH50AO+02/ /PeP/vsUfabf/nvH/wB9ioP7I0z/AKB1p/34X/Cj+yNM/wCgdaf9+F/woAn+02//AD3j/wC+xR9p t/8AnvH/AN9ioP7I0z/oHWn/AH4X/Cj+yNM/6B1p/wB+F/woAn+02/8Az3j/AO+xR9pt/wDnvH/3 2Kg/sjTP+gdaf9+F/wAKP7I0z/oHWn/fhf8ACgCf7Tb/APPeP/vsUfabf/nvH/32Kg/sjTP+gdaf 9+F/wo/sjTP+gdaf9+F/woAn+02//PeP/vsVQ1eeF0tFWVGP2yLgMP71WP7I0z/oHWn/AH4X/CnR 6ZYQyLJFY2yOvIZYlBH44oAtUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB/9k= --_004_5FD31D8EDBF4EC468B36D86F04FDB2E87382877Bnkgeml507mbschi_-- From nobody Thu Jun 4 05:38:53 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B47D1B32B0 for ; Thu, 4 Jun 2015 05:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.761 X-Spam-Level: X-Spam-Status: No, score=-1.761 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldZR5oaVKHz3 for ; Thu, 4 Jun 2015 05:38:48 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89D5F1B32AF for ; Thu, 4 Jun 2015 05:38:47 -0700 (PDT) Received: from 172.24.2.119 (EHLO nkgeml405-hub.china.huawei.com) ([172.24.2.119]) by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued) with ESMTP id BHF43695; Thu, 04 Jun 2015 20:38:28 +0800 (CST) Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.152]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Thu, 4 Jun 2015 20:26:32 +0800 From: Zhoutianran To: "Bert Wijnen (IETF)" , STUART VENTERS , "sdn@irtf.org" Thread-Topic: [Ibnemo] [Sdn] Defining a Common Model for intent Thread-Index: AQHQnJG50WlY7ClbtUGoYewpxJwlHZ2YUVeAgABezYCAACyygIABp5jQ//+5CQCAAguJpA== Date: Thu, 4 Jun 2015 12:26:32 +0000 Message-ID: References: <00f301d09b13$79cc2410$6d646c30$@ndzh.com> <8D15A2BAF93E9C49AB037A0647E5FA643F8490D8@eusaamb105.ericsson.se> <865C20BAAE8BBD4C89E7D6FE694F6B3B2D3CA540@nkgeml505-mbs.china.huawei.com> <8D15A2BAF93E9C49AB037A0647E5FA643F84AAA2@eusaamb105.ericsson.se> <1220E2C537595D439C5D026E83751866C42AC2FF@ex-mb3.corp.adtran.com> , <556EFC42.9040208@bwijnen.net> In-Reply-To: <556EFC42.9040208@bwijnen.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.46.202.101] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.557046CB.017E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.152, so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 5865f8c4dd16d9f34a15e117c0f78a80 Archived-At: Cc: "ibnemo@ietf.org" Subject: Re: [Sdn] [Ibnemo] Defining a Common Model for intent X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 12:38:52 -0000 SGkgQmVydCwNCg0KVGhhbmtzIGZvciB5b3UgY29tbWVudHMuIA0KSSBhZ3JlZSB3aXRoIHlvdSB0 aGF0IHdlJ2QgYmV0dGVyIGp1c3QgZm9jdXMgb24gdGhlIHRvcCBsYXllci4NCkJ1dCBJIGFtIHNv cnJ5LCB3aGF0IGRvIHlvdSBtZWFuIGluIHRoZSBsYXN0IHNlbnRlbmNlPw0KIkEgcm9sZSAtYmFz ZWQgaW50ZW50IG1vZGVsPyBJIGd1ZXNzIGl0IHdvdWxkIGp1c3QgYm9pbCBkb3duIGluIGRpZmZl cmVudCB0eXBlcyBvZiBpbnRlbnQgdGhhdCBmaXQgd2l0aCB0aGUgc3BlY2lmaWMgcm9sZSwgcmln aHQ/Ig0KQ291bGQgeW91IGdpdmUgbW9yZSBpbmZvcm1hdGlvbiBvbiB0aGlzPw0KDQpCZXN0LA0K VGVyZW5jZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+ yMs6IEJlcnQgV2lqbmVuIChJRVRGKSBbYndpZXRmQGJ3aWpuZW4ubmV0XQ0Kt6LLzcqxvOQ6IDIw MTXE6jbUwjPI1SAyMTowOA0KytW8/sjLOiBaaG91dGlhbnJhbjsgU1RVQVJUIFZFTlRFUlM7IHNk bkBpcnRmLm9yZw0Ks63LzTogaWJuZW1vQGlldGYub3JnDQrW98ziOiBSZTogW0libmVtb10gW1Nk bl0gRGVmaW5pbmcgYSBDb21tb24gTW9kZWwgZm9yIGludGVudA0KDQpIaSBhbGwsDQoNCkkgbGlr ZSB0aGUgaWRlYSBvZiAoYXQgbGVhc3QgZm9yIG5vdykgc3RpY2sgdG8gdGhlIHByb2JsZW0gb2Yg ImludGVudCIgZm9yIG9uZSBsYXllciAodGhlIHRvcCBsYXllcikuDQpMZXQgdXMgbm90IGJvaWwg dGhlIG9jZWFuIGFuZCB0cnkgdG8gZG8gZXZlcnl0aGluZyB0aGF0IGNvbWVzIHVwLiBJZiB3ZSBh cmUgc3VjY2Vzc2Z1bCBpbiBkb2luZw0KYSBtb2RlbCBmb3IgSUJORU1PIGZvciB0aGUgdG9wIGxh eWVyLCB3ZSBjYW4gdGhlbiBzZWUgaWYgd2Ugd2FudCB0byBnbyBhdCBtb3JlIGxheWVycy4NCg0K QSByb2xlIC1iYXNlZCBpbnRlbnQgbW9kZWw/IEkgZ3Vlc3MgaXQgd291bGQganVzdCBib2lsIGRv d24gaW4gZGlmZmVyZW50IHR5cGVzIG9mIGludGVudCB0aGF0DQpmaXQgd2l0aCB0aGUgc3BlY2lm aWMgcm9sZSwgcmlnaHQ/DQoNCkJlcnQNCg0KDQpPbiAwMy8wNi8xNSAxMTo0NCwgWmhvdXRpYW5y YW4gd3JvdGU6DQo+IEhpIFN0dWFydCwNCj4NCj4gVGhhbmtzIGZvciB0aGlzIGRlZXAgdGhpbmtp bmcgd2l0aCBhIHNldCBvZiBleGFtcGxlcy4gSXQncyByZWFsbHkgaW1wb3J0YW50IHRvIGNsYXJp ZnkgdGhpcyBmdXp6eSBpbnRlbnQuDQo+IEkgdGhpbmsgYWxsIHRoZSBjb25jZXJuIGFuZCB1bmNl cnRhaW50eSBpcyBiZWNhdXNlIG9mIHRoZSBsYXllcmVkIHRoaW5raW5nLiBXZSB0aGluayBpbnRl bnQgaXMgYSByZWxhdGl2ZWx5IGhpZ2hlciBsZXZlbCBuZXN0ZWQuDQo+IFdoYXQgaWYgd2UgdGhp bmsgYWJvdXQgaW50ZW50IHdpdGggZGlmZmVybmV0IHJvbGVzPyBKdXN0IGxpa2UgYSByZWxhdGl2 ZSBkZXRhaWxlZCBkZXNjcmlwdGlvbiBpbiBteSAicm9sZSBiYXNlZCBpbnRlbnQiIGVtYWlsLg0K PiBJIHRoaW5rIHRoZSBlc3NlbnRpYWwgb2YgdGhlIHJvbGUgYmFzZWQgaW50ZW50IGlzIHRoYXQg dGhlcmUgaXMgb25seSBvbmUgaW50ZW50IGxheWVyIHdoaWNoIGlzIGFsd2F5cyBvbiB0aGUgdG9w LiBJbnRlbnQgaXMgZGVkaWNhdGVkIGZvciBjb3JyZXNwb25kaW5nIHJvbGVzLiBPbmUgcm9sZSB3 aWxsIG5vdCBjYWxsIG90aGVyIHJvbGVzIGludGVyZmFjZXMuDQo+IFRoZW4gd2UgY2FuIHRyeSB0 byBmaW5kIHdheSB0byBleHByZXNzIGludGVudCBmb3IgdmFyaW91cyByb2xlcy4NCj4NCj4NCj4g UmVnYXJkcywNCj4gVGVyZW5jZQ0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBzZG4gW21haWx0bzpzZG4tYm91bmNlc0BpcnRmLm9yZ10gT24gQmVoYWxmIE9mIFNUVUFS VCBWRU5URVJTDQo+IFNlbnQ6IFdlZG5lc2RheSwgSnVuZSAwMywgMjAxNSAxMjowNiBBTQ0KPiBU bzogc2RuQGlydGYub3JnDQo+IENjOiAnRGF2ZSBIb29kJzsgaWJuZW1vQGlldGYub3JnOyBMaWZl bmdrYWkgKEZlbmdrYWkpOyBaaG91dGlhbnJhbjsgWGlheWluYmVuOyBTdXNhbiBIYXJlcw0KPiBT dWJqZWN0OiBSZTogW1Nkbl0gRGVmaW5pbmcgYSBDb21tb24gTW9kZWwgZm9yIGludGVudA0KPg0K Pg0KPg0KPiBJIGhhdmUgMiBjZW50cyB0byBjb250cmlidXRlIGZvciB0aGlzIGZ1enp5IGludGVu dCB3b3JkIGFuZCByZXN1bHRpbmcgZGF0YSBtb2RlbC4NCj4gUGVyaGFwcyAnaW50ZW50JyAgaXMg anVzdCBhIHJlbGF0aXZlbHkgaGlnaCBsZXZlbCBzZXJ2aWNlIHJlcXVlc3QuDQo+IFRoZSBwcm9i bGVtIHdpdGggdGhpcyBkZWZpbml0aW9uIGlzIHdoYXQgaXMgdGhhdCAncmVsYXRpdmVseSBoaWdo IGxldmVsJyBhcHBlYXJzIHRvIGRlcGVuZCBvbiB5b3VyIHBvaW50IG9mIHZpZXcuDQo+DQo+IFRv IGhlbHAgdGhpbmsgYWJvdXQgaXQsIGhlcmUncyBhIGxvbmcgY2hhaW4gb2YgY29tbWFuZCBmb3Ig dGhlIHNhbWUgYWN0aW9uLg0KPiBJdCBpcyBsb25nIGZvciBmdW4gYW5kIHNvIHRoYXQgYW55Ym9k eSBjYW4gZmluZCBwYXJ0IG9mIGl0IHRoYXQgdGhleSByZWNvZ25pemUuDQo+DQo+DQo+IENoYWlu IG9mIGNvbW1hbmQ6DQo+DQo+IEludmVzdG9yIHNheXM6IG1ha2UgbW9uZXkNCj4gQ0VPIHNheXM6 IG1ha2UgdGhlIG5ldHdvcmsgd29yaw0KPiBDSU8gc2F5czogZ2l2ZSBtZSBiYW5kd2lkdGhzIGJl dHdlZW4gc2l0ZXMgQSwgQiwgYW5kIEMgTmV0IGVuZ2luZWVyIHNheXM6IEkgbmVlZCB0aGVzZSBl dmMncyB0byB0aGVzZSBlbmRwb2ludHMgUHVyY2hhc2luZyBhZ2VudDogU2F5cyB1c2UgdGhpcyBw cm9kdWN0IGZyb20gdGhpcyB2ZW5kb3IgU2FsZXMgUGVyc29uIHNheXM6IEhlcmUgaXMgdGhlIHBy aWNlIGFuZCBwcmlvcml0eQ0KPiBQYXJ0aXRpb25lcjogZGl2aWRlcyB0aGUgZW5kIHRvIGVuZCBj aXJjdWl0IGFtb25nIGFkbWluaXN0cmF0aXZlIGRvbWFpbnMNCj4gUGxhbm5lcjogcGlja3MgdGhl IG5lY2Vzc2FyeSByZXNvdXJjZXMgdG8gdXNlLCBtYWtlcyB0aGUgdHJ1Y2sgcm9sbHMgaGFwcGVu DQo+IEFsbG9jYXRvcjogYWxsb2NhdGVzIHRoZSBuZWNlc3NhcnkgYmFuZHdpZHRoDQo+IFByb3Zp c2lvbmVyOiBkZWNpZGVzIHdoYXQgcHJvdmlzaW9uaW5nIGlzIG5lY2Vzc2FyeSBpbiBlYWNoIHBh cnQgb2YgdGhlIHBhdGgNCj4gQWRhcHRvcjogdGFpbG9ycyB0aGUgcHJvdmlzaW9uaW5nIHRvIGEg c3BlY2lmaWMgYm94DQo+IERyaXZlcjogcHVzaGVzIHRoZSBwcm92aXNpb25pbmcgaW50byB0aGUg Zm9yd2FyZGluZyB0YWJsZXMgRm9yd2FyZGluZyBlbmdpbmU6IGZvcndhcmRzIGFjY29yZGluZyB0 byB0aGUgdGFibGVzDQo+DQo+IFRoZSBJbnZlc3RvcidzIHN0YXRlbWVudCBhdCB0aGUgdG9wIGlz IGNsZWFybHkgd2hhdCBhbmQgbm90IGhvdy4NCj4gVGhlIGZvcndhcmRpbmcgZW5naW5lJ3Mgb3Bl cmF0aW9ucyBoYXZlIGEgbG90IG9mIGhvdywgYnV0IG1heWJlIGxpdHRsZSBnbG9iYWwgdmlldyBv ZiB3aGF0IHdlIGFyZSBkb2luZyBvdmVyYWxsLg0KPg0KPiBJZiB3ZSBzYXkgdGhhdCB0aGUgdG9w IGlzIGludGVudCBhbmQgdGhlIGJvdHRvbSBpcyBhIGlzIHNlcnZpY2UgcmVxdWVzdCwNCj4gICAg d2hvJ3MgdG8gc2F5IHdoZXJlIGludGVudCBzdG9wcyBhbmQgc2VydmljZSByZXF1ZXN0cyBzdGFy dD8NCj4NCj4gUGVyaGFwcyAgJ2ludGVudCcgbWVhbnMgYSBzZXJ2aWNlIHJlcXVlc3QgY29taW5n IGZyb20gYSBoaWdoZXIgbGF5ZXIgZm9yIHJlZmluZW1lbnQuDQo+DQo+IFRoYXQgc2FpZCwgdGhl IGRhdGEgbW9kZWwgZm9yIGludGVudCBtaWdodC9zaG91bGQgYmUgZGlmZmVyZW50IGF0IGVhY2gg bGV2ZWwuDQo+IFNpbmNlIGVhY2ggbGV2ZWwgaXMgcHJvY2Vzc2luZyB0aGUgc2FtZSByZXF1ZXN0 IGF0IGRpZmZlcmVudCBsZXZlbHMgb2YgZGV0YWlsLCBpdCBtaWdodCBiZSBzaW1pbGFyIGF0IGVh Y2ggbGV2ZWwuDQo+IFBlcmhhcHMgdGhlIGRhdGEgbW9kZWwgc3RhcnRzIHNpbXBsZSBvbiB0b3Ag YW5kIGdhdGhlcnMgbW9yZSBhbmQgbW9yZSBkZXRhaWwgYXMgaXQgZ2V0cyBsb3dlciA/DQo+IE1h eWJlIGxpa2UgYSB0cmVlIHdpdGggdGhlIHJvb3QgYXQgdGhlIHRvcCBhbmQgbGVhdmVzIGF0IHRo ZSBmb3J3YXJkaW5nIGVuZ2luZXMsIGV4Y2VwdCBkaXN0cmlidXRlZC4NCj4NCj4gUGVyaGFwcyBh IHNpbXBsZSBzdGFydGluZyBwb2ludCBuZWFyIHRoZSB0b3AgaXMgYSBjb21iaW5hdGlvbiBvZiBl bnRpdGllcywgZW5kcG9pbnRzLCBhbmQgY29ubmVjdGlvbnMuDQo+DQo+DQo+IFJlZ2FyZHMsDQo+ DQo+IFN0dWFydCBWZW50ZXJzDQo+DQo+DQo+DQo+DQo+DQo+DQo+DQo+IEZyb206IHNkbiBbbWFp bHRvOnNkbi1ib3VuY2VzQGlydGYub3JnXSBPbiBCZWhhbGYgT2YgRGF2ZSBIb29kDQo+IFNlbnQ6 IFR1ZXNkYXksIEp1bmUgMDIsIDIwMTUgODoyNiBBTQ0KPiBUbzogTGlmZW5na2FpIChGZW5na2Fp KTsgU3VzYW4gSGFyZXM7IHNkbkBpcnRmLm9yZw0KPiBDYzogWmhvdXRpYW5yYW47IFhpYXlpbmJl bjsgaWJuZW1vQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbU2RuXSBEZWZpbmluZyBhIENvbW1v biBNb2RlbCBmb3IgaW50ZW50DQo+DQo+IEkgYWdyZWUgdGhhdCB0aGUgY29udGV4dCBtYXR0ZXJz LCBGZW5na2FpIChhbmQgU3VzYW4gaW4gZWFybGllciByZXNwb25zZSkuIFdoYXQgdGhlIEktRCBh cHBlYXJzIHRvIGJlIHNheWluZyBpcyB0aGF0IGFueSBpbnRlcmFjdGlvbiBhY3Jvc3MgYW4gTkJJ IGlzIGludGVudDogb3RoZXJ3aXNlIHRoZSBhcHAvdGVuYW50L2N1c3RvbWVyIHdvdWxkbid0IGRv IGl0LiBUaGF0J3MgdGhlIHJvb3Qgb2YgbXkgcXVlc3Rpb24gZnJvbSB0aGUgYmVnaW5uaW5nOiBo b3cgd291bGQgd2Uga25vdyB3aGF0IGlzICpub3QqIGludGVudD8NCj4NCj4gSWYgSSBhc2sgZm9y IHNvbWUgcGFydGljdWxhciBtaWNyb3Njb3BpY2FsbHkgZGV0YWlsZWQgY29uZmlndXJhdGlvbiAo YSAiaG93IiksIGl0J3MgYmVjYXVzZSBJIGNhcmUsIGZvciBzb21lIHJlYXNvbiwgYWJvdXQgdGhh dCBsZXZlbCBvZiBkZXRhaWwuIEl0IGlzIGluIGZhY3QgcGFydCBvZiBteSBpbnRlbnQuDQo+DQo+ IEluIG15IElUIGV4YW1wbGUsIEkgYXJndWUgdGhhdCBpbnRlbnQgbmVlZCBub3QgYmUgaW5kZXBl bmRlbnQgb2YgcHJvdG9jb2xzIGFuZCBwb3J0cywgYW5kIHRoYXQgaXQgbmVlZCBub3QgYmUgcG9y dGFibGUuIFlvdXIgcmVzcG9uc2UgYWJvdXQgY29udGV4dCBhcHBlYXJzIHRvIGFncmVlLg0KPg0K PiBTbyBhcyBiZXN0IEkgY2FuIHRlbGwsIHdlIGNhbiBzYXkgcHJlY2lzZWx5IHdoYXQgYW4gaW50 ZW50IGlzLCBhbmQgd2UgY2FuJ3Qgc2F5IHdoYXQgYW4gaW50ZW50IGlzIG5vdC4gSWYgaW50ZW50 IGlzIGp1c3QgdGhlIGxhdGVzdCBidXp6d29yZCwgd2hpY2ggaXQgY2VydGFpbmx5IGFwcGVhcnMg dG8gYmUsIGNhbiB3ZSBqdXN0IHNheSBzbyBhbmQgbGVhdmUgaXQgdG8gdGhlIG1hcmtldGluZyBw ZW9wbGU/DQo+DQo+IERhdmUNCj4NCj4gRnJvbTogTGlmZW5na2FpIChGZW5na2FpKSBbbWFpbHRv OmxpZmVuZ2thaUBodWF3ZWkuY29tXQ0KPiBTZW50OiBUdWVzZGF5LCBKdW5lIDAyLCAyMDE1IDEy OjQ3IEFNDQo+IFRvOiBEYXZlIEhvb2Q7IFN1c2FuIEhhcmVzOyBzZG5AaXJ0Zi5vcmcNCj4gQ2M6 IFpob3V0aWFucmFuOyBYaWF5aW5iZW47IGlibmVtb0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTog W1Nkbl0gRGVmaW5pbmcgYSBDb21tb24gTW9kZWwgZm9yIGludGVudA0KPg0KPiBIaSBEYXZlIGFu ZCBhbGwsDQo+DQo+IFRoYW5rcyBmb3IgcHJvcG9zaW5nIHRoZSB0d28gdmFsdWFibGUgaW50ZW50 IHVzZSBjYXNlcy4NCj4NCj4gRm9yIHRoZSB1c2UgY2FzZSAyLCBJIGFncmVlIHRoYXQgdGhlIElU IGVtcGxveWVlIG5lZWRzIHRvIGluY2x1ZGUgdGhlIGRldGFpbHMgb2YgcG9ydHMvcHJvdG9jb2xz IGludG8gaGlzL2hlciBpbnRlbnQgZGVzY3JpcHRpb25zLCBidXQgdGhvc2UgbWF5IG5vdCBiZSBp biB0aGUgaW50ZW50IGNvbnRleHQgc2NvcGUgb2YgYSBub24tSVQgZW1wbG95ZWUuIEhhdmUgYSBm dXJ0aGVyIGNvbnNpZGVyYXRpb24gd2l0aCB0aGlzLCBkaWZmZXJlbnQgdXNlcnMgb2YgdGhlIG5l dHdvcmsgaGF2ZSB0aGVpciBvd24gaW50ZW50IGluIGEgc3BlY2lmaWMgZG9tYWluLiBUaGVuIHRo ZSByb2xlcy9hY3RvcnMgb2YgbmV0d29yayB1c2Vycywgc3VjaCBhcyBlbmQgdXNlcnMsIGFwcGxp Y2F0aW9uIGRldmVsb3BlcnMsIHRlbmFudCBJVC9uZXR3b3JrIGFkbWluaXN0cmF0b3JzLCBvcGVy YXRvciBuZXR3b3JrIGFkbWluaXN0cmF0b3JzLCBhcmUgdmFsdWFibGUgdG8gYmUgaWRlbnRpZmll ZCBhbmQgZGlzdGluZ3Vpc2hlZCwgdGh1cyBmaXR0aW5nIHRoZSBpbnRlbnQgcmVxdWlyZW1lbnRz IG9mIHRoZSBuZXR3b3JrIHVzZXJzIHdpdGggZGlmZmVyZW50IHJvbGVzLg0KPg0KPiBBbnkgdGhv dWdodHMgYWJvdXQgdGhpcyBjb25zaWRlcmF0aW9uPw0KPg0KPg0KPiBCZXN0IFJlZ2FyZHMsDQo+ IEZlbmdrYWkNCj4NCj4gRnJvbTogc2RuIFttYWlsdG86c2RuLWJvdW5jZXNAaXJ0Zi5vcmddIE9u IEJlaGFsZiBPZiBEYXZlIEhvb2QNCj4gU2VudDogVHVlc2RheSwgSnVuZSAwMiwgMjAxNSAxOjM4 IEFNDQo+IFRvOiBTdXNhbiBIYXJlczsgc2RuQGlydGYub3JnDQo+IENjOiBaaG91dGlhbnJhbjsg WGlheWluYmVuOyBpYm5lbW9AaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtTZG5dIERlZmluaW5n IGEgQ29tbW9uIE1vZGVsIGZvciBpbnRlbnQNCj4NCj4gQW4gZXhjZXJwdCBmcm9tIGFuIGVtYWls IEkgc2VudCBvbiB0aGUgT05GIE5CSSBsaXN0LCB3aGljaCBtYXkgY29udGFpbiBzb21lIHVzZWZ1 bCB0aG91Z2h0czoNCj4NCj4gSSBoYXZlIGFsd2F5cyBoYWQgdHJvdWJsZSB1bmRlcnN0YW5kaW5n IHdoYXQgYW4gaW50ZW50IHJlYWxseSBpcywgc28gSSBhbSBsb29raW5nIGZvcndhcmQgdG8gbWFr aW5nIHRoZSBjb25jZXB0IG1vcmUgcHJlY2lzZS4NCj4NCj4gV2hlbiBJIGNsaWNrIGEgbGluayBv biBhIHdlYiBwYWdlLCBJIGV4cHJlc3MgYW4gaW50ZW50IHRvIGludm9rZSB3aGF0ZXZlciB0aGF0 IGxpbmsgb2ZmZXJzLiBDb21wbGV0ZWx5IGJlbG93IHRoZSBzdXJmYWNlIGlzIGEgbGF5ZXIgc3Rh Y2ssIG9uLWRlbWFuZCBzZXNzaW9uIGVzdGFibGlzaG1lbnQsIEROUyBsb29rLXVwcywgc2VydmVy IGxvYWQgYmFsYW5jZXJzLCBhbmQgYW55IG51bWJlciBvZiBvdGhlciB0ZWNobm9sb2dpY2FsIGZl YXR1cmVzIHRoYXQgYXJlIG9mIG5vIGludGVyZXN0IHRvIG1lLiBXaHkgbm90IHVzZSB0aGF0IGFz IGFuIGV4YW1wbGUgb2YgaW50ZW50Pw0KPg0KPiBCZXR0ZXIgeWV0LCB3ZSB0YWxrIGFib3V0IG5l Z290aWF0aW9uIGFuZCBzZWxlY3Rpb24uIFN1cHBvc2UgSSB3YW50IHRvIGJ1eSBhIHdpZGdldC4g SSBwcm9iYWJseSBhbHJlYWR5IGhhdmUgc29tZSBpZGVhIHdoZXRoZXIgSSB3YW50IHRvIGdvIHRv IEFtYXpvbiBvciBFQmF5IG9yIHNvbWV3aGVyZSBlbHNlLiBTdXBwb3NlIGl0J3MgQW1hem9uLiBJ IHNlYXJjaCBBbWF6b24ncyBjYXRhbG9nIGFuZCByZWNlaXZlIGFuIG9mZmVyIG9mIHNldmVyYWwg d2lkZ2V0cywgc29tZSBuZXcsIHNvbWUgdXNlZCwgc29tZSB3aXRoIGEgY2hvaWNlIG9mIGNvbG91 ciBvciBvdGhlciBwZXJ0aW5lbnQgZmVhdHVyZXMuIElmIEkgc2VlIG5vdGhpbmcgSSBsaWtlLCBJ IG1heSBvcGVuIGEgbmV3IGJyb3dzZXIgd2luZG93IGFuZCBjaGVjayBvdXQgQmVzdCBCdXkgb3Ig RUJheSAobG90cyBtb3JlIGhpZGRlbiB0ZWNobm9sb2d5IHRvIG1ha2UgdGhhdCBoYXBwZW4hKS4g TWF5YmUgSSBjb21lIGJhY2sgdG8gdGhlIEFtYXpvbiBwYWdlLCBoYXZpbmcgZm91bmQgbm90aGlu ZyBJIGxpa2VkIGJldHRlciBzb21ld2hlcmUgZWxzZS4gTm93IEkgYWNjZXB0IG9uZSBvZiB0aGUg b2ZmZXJlZCB3aWRnZXRzIGFuZCBnbyB0aHJvdWdoIHRoZSBjaGVja291dCBwcm9jZXNzLg0KPg0K PiBEbyB3ZSBhZ3JlZSB0aGF0IHRoaXMgaXMgYSBmYWlybHkgcHVyZSBleHByZXNzaW9uIG9mIGlu dGVudCBhcyBjb25jZXB0dWFsaXplZCBpbiB0aGUgcGFwZXI/IChJZiBub3QsIGxldCdzIHRhbGsg YWJvdXQgbWFraW5nIGEgU2t5cGUgY2FsbC4pDQo+DQo+IE9rLCB0aGF0J3MgbXkgaW50ZW50IGFz IGFuIGludGVybmV0IHVzZXIuIExldCdzIGFzc3VtZSB0aGUgbmV0d29yayBpcyBhbGwgU0ROIG9m IG9uZSBraW5kIG9yIGFub3RoZXIuIEkgaW52b2tlIG15IGludGVudCB0aHJvdWdoIGEgR1VJIG9u dG8gc29mdHdhcmUgbG9jYWwgdG8gbXkgUEMsIGJ1dCBJIGRvbid0IHRoaW5rIHdlIGNhbiBjYWxs IHRoZSBQQyBhbiBTRE4gY29udHJvbGxlci4gSXQncyBtb3JlIGFuIGFjdGl2ZSBtZWRpYXRvciwg YSBjbGllbnQgdG8gYW4gU0ROLiBBcyBmYXIgYXMgdGhlIG5ldHdvcmsgaXMgY29uY2VybmVkLCB0 aGUgY2xpZW50IG1ha2VzIEROUyBxdWVyaWVzIGFuZCBzd2FwcyBvcGFxdWUgVENQIHBhY2tldHMg b3ZlciBhIGZvcndhcmRpbmcgcGF0aCB0aGF0IG1heSBhbHJlYWR5IGV4aXN0LCBvciBtYXkgbmVl ZCB0byBiZSBsZWFybmVkIGFuZCBzZXQgdXAgb24gZGVtYW5kLiBUaGlzIGlzIGFib3V0IHJpZ2h0 LCBiZWNhdXNlIHRoZSBzZXNzaW9uIGNvbnRlbnQgbWF5IHdlbGwgYmUgZW5jcnlwdGVkIGVuZCB0 byBlbmQsIGFuZCByaWdodGx5Lg0KPg0KPiBUbyB0aGUgU0ROIGNvbnRyb2xsZXIsIG15IGludGVu dCBpcyBzYXRpc2ZpZWQgYnkgZGlyZWN0aW5nIEROUyBxdWVyaWVzIHRvIGEga25vd24gRE5TIHNl cnZlciBzb21ld2hlcmUsIGFuZCBlbnN1cmluZyBJUCBjb25uZWN0aXZpdHkgZm9yIHRoZSBzdWJz ZXF1ZW50IHNlc3Npb24uIEhtbW0uIHdoYXQgaGFwcGVuZWQgdG8gb3VyIGludGVudC1iYXNlZCBO Qkk/IFRoZSBTRE4gb2ZmZXJlZCBteSBQQyBhIHBhY2tldCBpbnRlcmZhY2Ugd2l0aCB0aGUgcHJv cGVydGllcyBvZiBrbm93aW5nIGhvdyB0byByZWNvZ25pemUgYW5kIHJvdXRlIEROUyBxdWVyaWVz IHNwZWNpYWxseSwgYW5kIGdlbmVyYWwgSVAgY29ubmVjdGl2aXR5LiBNeSBQQyBhY2NlcHRlZCB0 aGUgc2VydmljZSBvZmZlciBpbXBsaWNpdGx5IGJ5IG9mZmVyaW5nIHRyYWZmaWMgdG8gdGhlIGRh dGEtcGxhbmUgaW50ZXJmYWNlLiBUaGUgbmV0d29yayBjb3VsZCBiZSBwZXJmb3JtaW5nIGFzc29j aWF0ZWQgYXV4aWxpYXJ5IHNlcnZpY2VzIHN1Y2ggYXMgdXNhZ2UtYmFzZWQgYmlsbGluZyAodGhp bmsgd2lyZWxlc3Mgcm9hbWluZyksIHNvIGl0J3MgbW9yZSB0aGFuIGp1c3QgYSBkdW1iIHBpcGUu DQo+DQo+IElmIHRoaXMgaXMgbm90IGEgbGVnaXRpbWF0ZSBleGFtcGxlIG9mIGludGVudCwgaXQg d291bGQgYmUgZ29vZCB0byB3cml0ZSB0aGUgd2hpdGUgcGFwZXIgaW4gc3VjaCBhIHdheSB0aGF0 IGNsZWFybHkgZXhjbHVkZXMgc3VjaCBjYXNlcy4NCj4NCj4gVXNlIGNhc2UgMjogc3VwcG9zZSBJ IGFtIGEgY29ycG9yYXRlIElUIGVtcGxveWVlLCBhbmQgc3VwcG9zZSB0aGF0IG15IGludGVudCBp cyB0byBoYXZlIGFuIEUtTGluZSBiZXR3ZWVuIHR3byBvZiBteSBjYW1waS4gSSBuZWNlc3Nhcmls eSBjYXJlIGFib3V0IHBvcnRzIGFuZCBwcm90b2NvbHM7IHRhbGsgYWJvdXQgaW50ZW50IGJlaW5n IHBvcnRhYmxlIGFuZCBwcm90b2NvbCBpbmRlcGVuZGVudCBjb250aW51ZXMgdG8gY29uZnVzZSBt ZSBjb21wbGV0ZWx5LiBIb3cgY2FuIEkgb3JkZXIgYW4gRS1saW5lIHdpdGhvdXQgY2FyaW5nIGFi b3V0IHN1Y2ggZGV0YWlscz8gW05vciBpcyB0aGlzIGludGVudCBwb3J0YWJsZS5dDQo+DQo+IE9i dmlvdXNseSwgYW4gU0ROIGNvbnRyb2xsZXIgaXMgZ29pbmcgdG8gZXhwb3NlIHdoYXRldmVyIGFj dGlvbnMgYW5kIGVsZW1lbnRzIG9mIGluZm9ybWF0aW9uIGFyZSBnZXJtYW5lIHRvIHRoZSBzZXJ2 aWNlIGl0IG9mZmVycywgYW5kIGlmIHBvcnRzIGFuZCBwcm90b2NvbHMgYXJlIGdlcm1hbmUgdG8g dGhlIHNlcnZpY2UsIHNvIGJlIGl0Lg0KPg0KPiBUaGUgU0ROIGFyY2hpdGVjdHVyZSwgYmVpbmcg cmVjdXJzaXZlLCBtb2RlbHMgdGhlIG5vcnRoIHNpZGUgb2YgYW55IGNvbnRyb2xsZXIgYXMgZXhw b3NpbmcgYW4gaW5zdGFuY2Ugb2YgYW4gaW5mb3JtYXRpb24gbW9kZWwsIGN1c3RvbWl6ZWQgZm9y IHRoZSBpbnRlbmRlZCBjbGllbnQvY3VzdG9tZXIvYXBwL3VzZXIuIFRoYXQgYmVpbmcgdGhlIGNh c2UsIGhvdyBkbyB3ZSBkaXN0aW5ndWlzaCBhbiBOQkkgQVBJIHRoYXQgY29udmV5cyBpbnRlbnQg KHNlcnZpY2U6IHNhbWUgdGhpbmc/KSBmcm9tIG9uZSB0aGF0IGRvZXMgbm90Pw0KPg0KPiBJIGhh dmUgcmVjZW50bHkgY29tZSB0byB0aGUgdmlldyB0aGF0IGdyYW51bGFyaXR5IGlzIHRoZSBjcml0 ZXJpb24gYnkgd2hpY2ggYW4gaW50ZW50IG9yIHNlcnZpY2UgaW52b2NhdGlvbiBpcyBkaXN0aW5n dWlzaGVkLiBDb2xsb3F1aWFsbHkgc3BlYWtpbmcsIGEgc2VydmljZSBpbnZvY2F0aW9uIGlzIGEg c2luZ2xlIGludm9jYXRpb24gYWNyb3NzIHRoZSBBUEk6IGdpdmUgbWUgRS1MaW5lLiBOb3cgb2Yg Y291cnNlIHRoaXMgdHVybnMgaW50byBjb25zdHJhaW50IG5lZ290aWF0aW9uLCBvZmZlciBhbmQg YWNjZXB0YW5jZSwgYnV0IHdoYXQgaGFwcGVucyBhY3Jvc3MgdGhlIEFQSSBpcyBlZmZlY3RpdmVs eSBvbmUgdHJhbnNhY3Rpb24uIEluIGNvbnRyYXN0LCB3aGF0IHdlIG1pZ2h0IGFncmVlIGlzICpu b3QqIGFuIGludGVudCBvciBhIHNlcnZpY2UgaXMgdGhlIG1hbmlwdWxhdGlvbiBvZiBhIGdyYW51 bGFyIGluZm9ybWF0aW9uIG1vZGVsLCB0aGUgZXhwbGljaXQgdmlzaWJpbGl0eSBvZiBtdWx0aXBs ZSBvYmplY3RzLCBob3cgdGhleSBhcmUgaW50ZXJyZWxhdGVkLCB0aGVpciBhdHRyaWJ1dGVzLCBh bmQgdGhlIGxpa2UuDQo+DQo+IC4gICAgICAgICBOZXR3b3JrIGFzIGEgc2luZ2xlIGx1bXAgdnMg c29tZSBub24tdHJpdmlhbCB0b3BvbG9neS4NCj4NCj4gLiAgICAgICAgIENoYXVmZmV1ciB2cyBk cml2aW5nIGEgY2FyLiBMZWdpdGltYXRlIHJlYXNvbnMgdG8gY2hvb3NlIG9uZSBvcHRpb24gb3Ig dGhlIG90aGVyLCBidXQgdGhlIGxldmVsIG9mIGdyYW51bGFyaXR5IGlzIHF1aXRlIGRpZmZlcmVu dC4gU2hhbGwgd2UgYWdyZWUgdGhhdCBkcml2aW5nIGlzIHRvbyBncmFudWxhciB0byBiZSBjb25z aWRlcmVkIGludGVudD8NCj4NCj4gVGhpcyBpZGVhIG9mIGdyYW51bGFyaXR5IGFuZCBkZXRhaWxl ZCBvcGVyYXRpb25zIG9uIHRoZSBjb21wb25lbnRzICh3aGljaCBvZiBjb3Vyc2UgbWF5IGJlIGNv bXBsZXggZW50aXRpZXMgdGhlbXNlbHZlcywgdmlydHVhbGl6ZWQgaW50byBzaW1wbGUtYXBwZWFy aW5nIGx1bXBzKSBzZWVtcyB0byBtZSB0byBjYXB0dXJlIHRoZSBlc3NlbmNlIG9mIHdoYXQgcGVv cGxlIGFyZSB0YWxraW5nIGFib3V0IHdoZW4gdGhleSBzYXkgaW50ZW50IG9yIHNlcnZpY2UuIEkg YW0gbm90IGNvbWZvcnRhYmxlIHdpdGggdGhlIHdheSBJIGFtIGV4cHJlc3NpbmcgaXQsIHNvIGlm IHRoaXMgaXMgYSBzdGVwIGluIGEgcHJvZHVjdGl2ZSBkaXJlY3Rpb24sIG9yIGV2ZW4gaWYgaXQn cyBub3QsIEkgd2VsY29tZSBzdWdnZXN0aW9ucyB0byBjbGFyaWZ5IHRoZSBjb25jZXB0Lg0KPg0K PiBEYXZlDQo+DQo+IEZyb206IHNkbiBbbWFpbHRvOnNkbi1ib3VuY2VzQGlydGYub3JnXSBPbiBC ZWhhbGYgT2YgU3VzYW4gSGFyZXMNCj4gU2VudDogU2F0dXJkYXksIE1heSAzMCwgMjAxNSAxOjAy IFBNDQo+IFRvOiBzZG5AaXJ0Zi5vcmcNCj4gQ2M6ICdaaG91dGlhbnJhbic7ICdYaWF5aW5iZW4n OyBpYm5lbW9AaWV0Zi5vcmcNCj4gU3ViamVjdDogW1Nkbl0gRGVmaW5pbmcgYSBDb21tb24gTW9k ZWwgZm9yIGludGVudA0KPg0KPiBPbiB0aGlzIG1haWwgbGlzdCwgdGhlcmUgaGFzIGJlZW4gYSBk aXNjdXNzaW9uIG9mIHR3byB0eXBlcyBvZiBpbmZvcm1hdGlvbiBmb3IgSW50ZW50IGFuZCBOZW1v OiAoaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Nkbi9jdXJyZW50L21zZzAw NjQ2Lmh0bWwpIDoNCj4NCj4gMSkgICAgICBXaGF0IGluZm9ybWF0aW9uIGlzIG5lZWRlZCB0byBy ZXByZXNlbnQgYSBzZXJ2aWNlIHJlcXVlc3QsDQo+IDIpICAgICAgSG93IHRvIHJlcHJlc2VudCBh bmQgdHJhbnNwb3J0IHRoZSBpbmZvcm1hdGlvbiBmb3IgYSByZXF1ZXN0Lg0KPg0KPiBJbiBvcmRl ciB0byBkZWZpbmUgd2hhdCBpbmZvcm1hdGlvbiBpcyBuZWVkZWQgdG8gcmVwcmVzZW50IGEgMSkg c2VydmljZSByZXF1ZXN0IHRoYXQgc2lnbmFscyBJbnRlbnQgZnJvbSBhbiBhcHBsaWNhdGlvbiB0 byBhIGNvbnRyb2xsZXIsIGl0IGlzIGltcG9ydGFudCB0byBkZWZpbmUgSW50ZW50LCBhbmQgcHJv dmlkZSBhIGNsZWFyIG1vZGVsIG9mIEludGVudC4gIEFsc28sIGluIGRlc2NyaWJpbmcgcmVhbCB1 c2UtY2FzZXMgaXQgaXMgaW1wb3J0YW50IHRoYXQgb25lIHVzZXMgdGhlIHNhbWUgZGVmaW5pdGlv biBhbmQgbW9kZWwgZm9yIEludGVudCBpbiBlYWNoIHVzZSBjYXNlLg0KPg0KPiBJbiB0aGUgY3Vy cmVudCBmb3J1bXMgZXhhbWluaW5nIEludGVudCAoT0RMIE5JQywgT0RMIE5lbW8sIE9GIE5CSSBh bmQgS2V5c3RvbmUsIE9QTkZWIE1vdmllLCBPcGVuU3RhY2spIHRoZXJlIGlzIGEgcmVhbGl6YXRp b24gdGhhdCBJbnRlbnQgb2NjdXJzIGF0IG11bHRpcGxlIGxheWVycy4gIFRoZSBhdXRob3JzIG9m IGRyYWZ0LXhpYS1pYm5lbW8taWNpbSBoYXZlIGNyZWF0ZWQgYSBkZWZpbml0aW9uIGZvciBpbnRl bnQgYW5kIGEgdW5pZmllZCBtb2RlbCBmb3IgZGVmaW5pbmcgaW50ZW50IHdoaWNoIGNhbiBoYW5k bGUgMSBvciBtdWx0aXBsZSBsYXllcnMuIFRoZSBtb2RlbCBzdWdnZXN0IHRoYXQ6DQo+IDEpICAg ICAgQSB1c2VyIGhhcyBhIGludGVudCB0aGF0IGlzIGV4cHJlc3NlZCBpbiBhIGNvbnRleHQuDQo+ IDIpICAgICAgSW50ZW50ICh1c3VhbGx5KSBpbnZvbHZlcyBhbiBvYmplY3Qgd2l0aCBhIHJlc3Vs dCwgYW5kIG9wdGlvbmFsbHkgaW5jbHVkZXMgb3BlcmF0aW9ucyB0b3dhcmQgdGhhdCByZXN1bHQu DQo+IDMpICAgICAgT3BlcmF0aW9ucyBjb25kaXRpb25zIHBlcmZvcm0gYWN0aW9ucyB3aXRoaW4v bW9kaWZpZWQgYnkgY29uc3RyYWludHMuDQo+DQo+IFdlIGJlbGlldmUgdGhpcyBkZWZpbmVzIGNs ZWFybHkgd2hhdCBvdGhlcnMgYXJlIGNhbGxpbmcgInB1cmUgaW50ZW50IiAob2JqZWN0cyArIHJl c3VsdHMpIHZlcnN1cyAiY29uc3RyYWluZWQgaW50ZW50IiAob2JqZWN0cyArIG9wZXJhdGlvbnMg KyBjb25zdHJhaW50cykuICAgVGhlIGRyYWZ0IGNhbiBiZSBmb3VuZCBhdDogICBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC14aWEtaWJuZW1vLWljaW0vIC4gICBUaGUgYXV0 aG9ycyBhcmUgbG9va2luZyBmb3IgZmVlZGJhY2sgb24gdGhlIGNvbmNlcHRzIGluIHRoZSBkcmFm dC4NCj4NCj4gU3VlIEhhcmVzDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IHNkbiBtYWlsaW5nIGxpc3QNCj4gc2RuQGlydGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlydGYub3JnL21haWxtYW4vbGlzdGluZm8vc2RuDQo+DQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IElibmVtbyBtYWlsaW5nIGxp c3QNCj4gSWJuZW1vQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaWJuZW1vDQo+ From nobody Thu Jun 4 08:13:18 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340881A8925 for ; Thu, 4 Jun 2015 08:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.605 X-Spam-Level: X-Spam-Status: No, score=-96.605 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEMa54Wv7bbw for ; Thu, 4 Jun 2015 08:13:13 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id D973D1A8923 for ; Thu, 4 Jun 2015 08:13:12 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.80.157; From: "Susan Hares" To: "'Zhoutianran'" , "'Bert Wijnen \(IETF\)'" , "'STUART VENTERS'" , References: <00f301d09b13$79cc2410$6d646c30$@ndzh.com> <8D15A2BAF93E9C49AB037A0647E5FA643F8490D8@eusaamb105.ericsson.se> <865C20BAAE8BBD4C89E7D6FE694F6B3B2D3CA540@nkgeml505-mbs.china.huawei.com> <8D15A2BAF93E9C49AB037A0647E5FA643F84AAA2@eusaamb105.ericsson.se> <1220E2C537595D439C5D026E83751866C42AC2FF@ex-mb3.corp.adtran.com> , <556EFC42.9040208@bwijnen.net> In-Reply-To: Date: Thu, 4 Jun 2015 11:13:09 -0400 Message-ID: <001201d09ed8$f7c6f480$e754dd80$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGjwAWNbhwtlPLyYWaj2K7LZAyOCALTOOmfAi4Fw8QBCozw2wFJpHEeAtftGdUDX4EdNAL46qhHnXIDTCA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: ibnemo@ietf.org Subject: Re: [Sdn] [Ibnemo] Defining a Common Model for intent X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 15:13:16 -0000 Bert and Tianran:=20 If you link intent to role, I believe your diagram is:=20 User --> intent --> role --> context=20 I think role takes on an aspect of context. What do you think?=20 Sue=20 -----Original Message----- From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of Zhoutianran Sent: Thursday, June 04, 2015 8:27 AM To: Bert Wijnen (IETF); STUART VENTERS; sdn@irtf.org Cc: ibnemo@ietf.org Subject: Re: [Sdn] [Ibnemo] Defining a Common Model for intent Hi Bert, Thanks for you comments.=20 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 ________________________________________ =B7=A2=BC=FE=C8=CB: Bert Wijnen (IETF) [bwietf@bwijnen.net] =B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA6=D4=C23=C8=D5 21:08 =CA=D5=BC=FE=C8=CB: Zhoutianran; STUART VENTERS; sdn@irtf.org =B3=AD=CB=CD: ibnemo@ietf.org =D6=F7=CC=E2: Re: [Ibnemo] [Sdn] Defining a Common Model for intent 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: > 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:sdn-bounces@irtf.org] On Behalf Of STUART VENTERS > Sent: Wednesday, June 03, 2015 12:06 AM > To: sdn@irtf.org > Cc: 'Dave Hood'; ibnemo@ietf.org; Lifengkai (Fengkai); Zhoutianran;=20 > 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=20 > 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=20 > domains > Planner: picks the necessary resources to use, makes the truck rolls=20 > happen > Allocator: allocates the necessary bandwidth > Provisioner: decides what provisioning is necessary in each part of=20 > the path > Adaptor: tailors the provisioning to a specific box > Driver: pushes the provisioning into the forwarding tables Forwarding=20 > 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 > > > > > > > > From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of Dave Hood > Sent: Tuesday, June 02, 2015 8:26 AM > To: Lifengkai (Fengkai); Susan Hares; sdn@irtf.org > Cc: Zhoutianran; Xiayinben; ibnemo@ietf.org > 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 > > From: Lifengkai (Fengkai) [mailto:lifengkai@huawei.com] > Sent: Tuesday, June 02, 2015 12:47 AM > To: Dave Hood; Susan Hares; sdn@irtf.org > Cc: Zhoutianran; Xiayinben; ibnemo@ietf.org > Subject: RE: [Sdn] Defining a Common Model for intent > > Hi Dave and all, > > Thanks for proposing the two valuable intent use cases. > > For the use case 2, I agree that the IT employee needs to include the details of ports/protocols into his/her intent descriptions, but those = may not be in the intent context scope of a non-IT employee. Have a further consideration with this, different users of the network have their own intent in a specific domain. Then the roles/actors of network users, = such as end users, application developers, tenant IT/network administrators, operator network administrators, are valuable to be identified and distinguished, thus fitting the intent requirements of the network users with different roles. > > Any thoughts about this consideration? > > > Best Regards, > Fengkai > > From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of Dave Hood > Sent: Tuesday, June 02, 2015 1:38 AM > To: Susan Hares; sdn@irtf.org > Cc: Zhoutianran; Xiayinben; ibnemo@ietf.org > 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=20 > conceptualized in the paper? (If not, let's talk about making a Skype=20 > 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=20 > intent is to have an E-Line between two of my campi. I necessarily=20 > care about ports and protocols; talk about intent being portable and=20 > protocol independent continues to confuse me completely. How can I=20 > 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:sdn-bounces@irtf.org] On Behalf Of Susan Hares > Sent: Saturday, May 30, 2015 1:02 PM > To: sdn@irtf.org > Cc: 'Zhoutianran'; 'Xiayinben'; ibnemo@ietf.org > 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 > > _______________________________________________ > sdn mailing list > sdn@irtf.org > https://www.irtf.org/mailman/listinfo/sdn > > _______________________________________________ > Ibnemo mailing list > Ibnemo@ietf.org > https://www.ietf.org/mailman/listinfo/ibnemo > _______________________________________________ sdn mailing list sdn@irtf.org https://www.irtf.org/mailman/listinfo/sdn From nobody Thu Jun 4 23:03:03 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04FC41B2C4A for ; Thu, 4 Jun 2015 23:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoHi2FimVzIF for ; Thu, 4 Jun 2015 23:02:57 -0700 (PDT) Received: from smtpjc.telefonica.com (smtpjc.telefonica.com [81.47.204.76]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B32241B2C44 for ; Thu, 4 Jun 2015 23:02:56 -0700 (PDT) Received: from smtpjc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D1E742F020A; Fri, 5 Jun 2015 08:02:53 +0200 (CEST) Received-SPF: PermError (tgtimjc803.telefonica.com: domain of pedroa.aranda@telefonica.com uses mechanism not recognized by this client) identity=MAILFROM; client-ip=10.92.4.9; envelope-from=pedroa.aranda@telefonica.com; helo=ESTGVMSP103.EUROPE.telefonica.corp) Received: from ESTGVMSP103.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtpjc.telefonica.com (Postfix) with ESMTPS id B7BB72F01FF; Fri, 5 Jun 2015 08:02:53 +0200 (CEST) Received: from emea01-db3-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.92.6.50) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 5 Jun 2015 08:02:52 +0200 Received: from DB4PR06MB0639.eurprd06.prod.outlook.com (25.161.13.145) by DB4PR06MB0637.eurprd06.prod.outlook.com (25.161.13.143) with Microsoft SMTP Server (TLS) id 15.1.172.22; Fri, 5 Jun 2015 06:02:51 +0000 Received: from DB4PR06MB0639.eurprd06.prod.outlook.com ([25.161.13.145]) by DB4PR06MB0639.eurprd06.prod.outlook.com ([25.161.13.145]) with mapi id 15.01.0172.012; Fri, 5 Jun 2015 06:02:51 +0000 From: PEDRO ANDRES ARANDA GUTIERREZ To: Susan Hares , 'Zhoutianran' , "'Bert Wijnen (IETF)'" , 'STUART VENTERS' , "sdn@irtf.org" Thread-Topic: [Ibnemo] [Sdn] Defining a Common Model for intent Thread-Index: AQHQntkT/YWV5eh9PkmCZ0MCtEUxd52djjqA Date: Fri, 5 Jun 2015 06:02:51 +0000 Message-ID: References: <00f301d09b13$79cc2410$6d646c30$@ndzh.com> <8D15A2BAF93E9C49AB037A0647E5FA643F8490D8@eusaamb105.ericsson.se> <865C20BAAE8BBD4C89E7D6FE694F6B3B2D3CA540@nkgeml505-mbs.china.huawei.com> <8D15A2BAF93E9C49AB037A0647E5FA643F84AAA2@eusaamb105.ericsson.se> <1220E2C537595D439C5D026E83751866C42AC2FF@ex-mb3.corp.adtran.com> <556EFC42.9040208@bwijnen.net> <001201d09ed8$f7c6f480$e754dd80$@ndzh.com> In-Reply-To: <001201d09ed8$f7c6f480$e754dd80$@ndzh.com> Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.1.150515 authentication-results: ndzh.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [195.235.92.36] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB0637; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:DB4PR06MB0637; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0637; x-forefront-prvs: 05986C03E0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(76104003)(13464003)(52604005)(85664002)(53754006)(51704005)(377454003)(479174004)(4001350100001)(76176999)(19580395003)(50986999)(19580405001)(93886004)(92566002)(5002640100001)(36756003)(5001770100001)(66066001)(2950100001)(2900100001)(15975445007)(102836002)(62966003)(77156002)(40100003)(189998001)(106116001)(5001960100002)(46102003)(551934003)(575784001)(2501003)(87936001)(2656002)(86362001)(83506001)(122556002)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0637; H:DB4PR06MB0639.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-ID: <3F422386EC0C7F4A9AD6852977A846E1@eurprd06.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2015 06:02:51.5311 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0637 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: Cc: "ibnemo@ietf.org" Subject: Re: [Sdn] [Ibnemo] Defining a Common Model for intent X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 06:03:03 -0000 SGkgU3VlLA0KDQpHb2luZyBiYWNrIHRvIHRoZSBCR1AtNCBleGFtcGxlIGFuZCBzdGF5aW5nIGF0 IHRoZSByb2xlIGxldmVsLCBkb2VzIHRoaXMNCmNoYWluIHJlYWxseSBzdGFuZD8gSSBtZWFuLCB0 aGVyZSBhcmUgdGhpbmdzIGEgdXNlciB3aWxsIG5ldmVyIGJlIGFibGUgdG8NCmRvIGRlcGVuZGlu ZyBvbiAoaGVyfGhpcykgcm9sZS4gU28sIHdpbGwgcz9oZSBldmVyIGJlIGFibGUgdG8gZXhwcmVz cyBhbg0KaW50ZW50IGZvciBzb21ldGhpbmcgcz9oZSBjYW5ub3QgY29udHJvbD8NCg0KSnVzdCBh IGJpdCBvZiBwaGlsb3NvcGh5IEkgZmVhciA6LSkNCg0KL1BBDQoNCi0tLQ0KRHIuIFBlZHJvIEEu IEFyYW5kYSBHdXRpw6lycmV6DQoNClRlY2hub2xvZ3kgRXhwbG9yYXRpb24gLQ0KTmV0d29yayBJ bm5vdmF0aW9uICYgVmlydHVhbGlzYXRpb24NCmVtYWlsOiBwZWRyb2EgZDB0IGFyYW5kYSBBdCB0 ZWxlZm9uaWNhIGQwdCBjb20NClRlbGVmw7NuaWNhLCBJbnZlc3RpZ2FjacOzbiB5IERlc2Fycm9s bG8NCkMvIEQuIFJhbcOzbiBkZSBsYSBDcnV6LDg0DQoyODAwNiBNYWRyaWQsIFNwYWluDQoNCkZy YWdlbiBzaW5kIG5pY2h0IGRhLCB1bSBiZWFudHdvcnRldCB6dSB3ZXJkZW4uDQpGcmFnZW4gc2lu ZCBkYSwgdW0gZ2VzdGVsbHQgenUgd2VyZGVuLg0KR2VvcmcgS3JlaXNsZXINCg0KDQoNCg0KRWwg MDQvMDYvMTUgMTc6MTMsICJTdXNhbiBIYXJlcyIgPHNoYXJlc0BuZHpoLmNvbT4gZXNjcmliacOz Og0KDQo+QmVydCBhbmQgVGlhbnJhbjoNCj4NCj5JZiB5b3UgbGluayBpbnRlbnQgdG8gcm9sZSwg SSBiZWxpZXZlIHlvdXIgZGlhZ3JhbSBpczoNCj4NCj5Vc2VyIC0tPiBpbnRlbnQgLS0+IHJvbGUg LS0+IGNvbnRleHQNCj4NCj5JIHRoaW5rIHJvbGUgdGFrZXMgb24gYW4gYXNwZWN0IG9mIGNvbnRl eHQuICAgV2hhdCBkbyB5b3UgdGhpbms/DQo+DQo+U3VlDQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj5Gcm9tOiBzZG4gW21haWx0bzpzZG4tYm91bmNlc0BpcnRmLm9yZ10gT24gQmVo YWxmIE9mIFpob3V0aWFucmFuDQo+U2VudDogVGh1cnNkYXksIEp1bmUgMDQsIDIwMTUgODoyNyBB TQ0KPlRvOiBCZXJ0IFdpam5lbiAoSUVURik7IFNUVUFSVCBWRU5URVJTOyBzZG5AaXJ0Zi5vcmcN Cj5DYzogaWJuZW1vQGlldGYub3JnDQo+U3ViamVjdDogUmU6IFtTZG5dIFtJYm5lbW9dIERlZmlu aW5nIGEgQ29tbW9uIE1vZGVsIGZvciBpbnRlbnQNCj4NCj5IaSBCZXJ0LA0KPg0KPlRoYW5rcyBm b3IgeW91IGNvbW1lbnRzLg0KPkkgYWdyZWUgd2l0aCB5b3UgdGhhdCB3ZSdkIGJldHRlciBqdXN0 IGZvY3VzIG9uIHRoZSB0b3AgbGF5ZXIuDQo+QnV0IEkgYW0gc29ycnksIHdoYXQgZG8geW91IG1l YW4gaW4gdGhlIGxhc3Qgc2VudGVuY2U/DQo+IkEgcm9sZSAtYmFzZWQgaW50ZW50IG1vZGVsPyBJ IGd1ZXNzIGl0IHdvdWxkIGp1c3QgYm9pbCBkb3duIGluIGRpZmZlcmVudA0KPnR5cGVzIG9mIGlu dGVudCB0aGF0IGZpdCB3aXRoIHRoZSBzcGVjaWZpYyByb2xlLCByaWdodD8iDQo+Q291bGQgeW91 IGdpdmUgbW9yZSBpbmZvcm1hdGlvbiBvbiB0aGlzPw0KPg0KPkJlc3QsDQo+VGVyZW5jZQ0KPg0K Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj7lj5Hku7bkuro6IEJl cnQgV2lqbmVuIChJRVRGKSBbYndpZXRmQGJ3aWpuZW4ubmV0XQ0KPuWPkemAgeaXtumXtDogMjAx NeW5tDbmnIgz5pelIDIxOjA4DQo+5pS25Lu25Lq6OiBaaG91dGlhbnJhbjsgU1RVQVJUIFZFTlRF UlM7IHNkbkBpcnRmLm9yZw0KPuaKhOmAgTogaWJuZW1vQGlldGYub3JnDQo+5Li76aKYOiBSZTog W0libmVtb10gW1Nkbl0gRGVmaW5pbmcgYSBDb21tb24gTW9kZWwgZm9yIGludGVudA0KPg0KPkhp IGFsbCwNCj4NCj5JIGxpa2UgdGhlIGlkZWEgb2YgKGF0IGxlYXN0IGZvciBub3cpIHN0aWNrIHRv IHRoZSBwcm9ibGVtIG9mICJpbnRlbnQiIGZvcg0KPm9uZSBsYXllciAodGhlIHRvcCBsYXllciku DQo+TGV0IHVzIG5vdCBib2lsIHRoZSBvY2VhbiBhbmQgdHJ5IHRvIGRvIGV2ZXJ5dGhpbmcgdGhh dCBjb21lcyB1cC4gSWYgd2UNCj5hcmUNCj5zdWNjZXNzZnVsIGluIGRvaW5nIGEgbW9kZWwgZm9y IElCTkVNTyBmb3IgdGhlIHRvcCBsYXllciwgd2UgY2FuIHRoZW4gc2VlDQo+aWYNCj53ZSB3YW50 IHRvIGdvIGF0IG1vcmUgbGF5ZXJzLg0KPg0KPkEgcm9sZSAtYmFzZWQgaW50ZW50IG1vZGVsPyBJ IGd1ZXNzIGl0IHdvdWxkIGp1c3QgYm9pbCBkb3duIGluIGRpZmZlcmVudA0KPnR5cGVzIG9mIGlu dGVudCB0aGF0IGZpdCB3aXRoIHRoZSBzcGVjaWZpYyByb2xlLCByaWdodD8NCj4NCj5CZXJ0DQo+ DQo+DQo+T24gMDMvMDYvMTUgMTE6NDQsIFpob3V0aWFucmFuIHdyb3RlOg0KPj4gSGkgU3R1YXJ0 LA0KPj4NCj4+IFRoYW5rcyBmb3IgdGhpcyBkZWVwIHRoaW5raW5nIHdpdGggYSBzZXQgb2YgZXhh bXBsZXMuIEl0J3MgcmVhbGx5DQo+aW1wb3J0YW50IHRvIGNsYXJpZnkgdGhpcyBmdXp6eSBpbnRl bnQuDQo+PiBJIHRoaW5rIGFsbCB0aGUgY29uY2VybiBhbmQgdW5jZXJ0YWludHkgaXMgYmVjYXVz ZSBvZiB0aGUgbGF5ZXJlZA0KPnRoaW5raW5nLiBXZSB0aGluayBpbnRlbnQgaXMgYSByZWxhdGl2 ZWx5IGhpZ2hlciBsZXZlbCBuZXN0ZWQuDQo+PiBXaGF0IGlmIHdlIHRoaW5rIGFib3V0IGludGVu dCB3aXRoIGRpZmZlcm5ldCByb2xlcz8gSnVzdCBsaWtlIGEgcmVsYXRpdmUNCj5kZXRhaWxlZCBk ZXNjcmlwdGlvbiBpbiBteSAicm9sZSBiYXNlZCBpbnRlbnQiIGVtYWlsLg0KPj4gSSB0aGluayB0 aGUgZXNzZW50aWFsIG9mIHRoZSByb2xlIGJhc2VkIGludGVudCBpcyB0aGF0IHRoZXJlIGlzIG9u bHkgb25lDQo+aW50ZW50IGxheWVyIHdoaWNoIGlzIGFsd2F5cyBvbiB0aGUgdG9wLiBJbnRlbnQg aXMgZGVkaWNhdGVkIGZvcg0KPmNvcnJlc3BvbmRpbmcgcm9sZXMuIE9uZSByb2xlIHdpbGwgbm90 IGNhbGwgb3RoZXIgcm9sZXMgaW50ZXJmYWNlcy4NCj4+IFRoZW4gd2UgY2FuIHRyeSB0byBmaW5k IHdheSB0byBleHByZXNzIGludGVudCBmb3IgdmFyaW91cyByb2xlcy4NCj4+DQo+Pg0KPj4gUmVn YXJkcywNCj4+IFRlcmVuY2UNCj4+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4g RnJvbTogc2RuIFttYWlsdG86c2RuLWJvdW5jZXNAaXJ0Zi5vcmddIE9uIEJlaGFsZiBPZiBTVFVB UlQgVkVOVEVSUw0KPj4gU2VudDogV2VkbmVzZGF5LCBKdW5lIDAzLCAyMDE1IDEyOjA2IEFNDQo+ PiBUbzogc2RuQGlydGYub3JnDQo+PiBDYzogJ0RhdmUgSG9vZCc7IGlibmVtb0BpZXRmLm9yZzsg TGlmZW5na2FpIChGZW5na2FpKTsgWmhvdXRpYW5yYW47DQo+PiBYaWF5aW5iZW47IFN1c2FuIEhh cmVzDQo+PiBTdWJqZWN0OiBSZTogW1Nkbl0gRGVmaW5pbmcgYSBDb21tb24gTW9kZWwgZm9yIGlu dGVudA0KPj4NCj4+DQo+Pg0KPj4gSSBoYXZlIDIgY2VudHMgdG8gY29udHJpYnV0ZSBmb3IgdGhp cyBmdXp6eSBpbnRlbnQgd29yZCBhbmQgcmVzdWx0aW5nDQo+PmRhdGENCj5tb2RlbC4NCj4+IFBl cmhhcHMgJ2ludGVudCcgIGlzIGp1c3QgYSByZWxhdGl2ZWx5IGhpZ2ggbGV2ZWwgc2VydmljZSBy ZXF1ZXN0Lg0KPj4gVGhlIHByb2JsZW0gd2l0aCB0aGlzIGRlZmluaXRpb24gaXMgd2hhdCBpcyB0 aGF0ICdyZWxhdGl2ZWx5IGhpZ2ggbGV2ZWwnDQo+YXBwZWFycyB0byBkZXBlbmQgb24geW91ciBw b2ludCBvZiB2aWV3Lg0KPj4NCj4+IFRvIGhlbHAgdGhpbmsgYWJvdXQgaXQsIGhlcmUncyBhIGxv bmcgY2hhaW4gb2YgY29tbWFuZCBmb3IgdGhlIHNhbWUNCj5hY3Rpb24uDQo+PiBJdCBpcyBsb25n IGZvciBmdW4gYW5kIHNvIHRoYXQgYW55Ym9keSBjYW4gZmluZCBwYXJ0IG9mIGl0IHRoYXQgdGhl eQ0KPnJlY29nbml6ZS4NCj4+DQo+Pg0KPj4gQ2hhaW4gb2YgY29tbWFuZDoNCj4+DQo+PiBJbnZl c3RvciBzYXlzOiBtYWtlIG1vbmV5DQo+PiBDRU8gc2F5czogbWFrZSB0aGUgbmV0d29yayB3b3Jr DQo+PiBDSU8gc2F5czogZ2l2ZSBtZSBiYW5kd2lkdGhzIGJldHdlZW4gc2l0ZXMgQSwgQiwgYW5k IEMgTmV0IGVuZ2luZWVyDQo+PiBzYXlzOiBJIG5lZWQgdGhlc2UgZXZjJ3MgdG8gdGhlc2UgZW5k cG9pbnRzIFB1cmNoYXNpbmcgYWdlbnQ6IFNheXMgdXNlDQo+PiB0aGlzIHByb2R1Y3QgZnJvbSB0 aGlzIHZlbmRvciBTYWxlcyBQZXJzb24gc2F5czogSGVyZSBpcyB0aGUgcHJpY2UgYW5kDQo+PiBw cmlvcml0eQ0KPj4gUGFydGl0aW9uZXI6IGRpdmlkZXMgdGhlIGVuZCB0byBlbmQgY2lyY3VpdCBh bW9uZyBhZG1pbmlzdHJhdGl2ZQ0KPj4gZG9tYWlucw0KPj4gUGxhbm5lcjogcGlja3MgdGhlIG5l Y2Vzc2FyeSByZXNvdXJjZXMgdG8gdXNlLCBtYWtlcyB0aGUgdHJ1Y2sgcm9sbHMNCj4+IGhhcHBl bg0KPj4gQWxsb2NhdG9yOiBhbGxvY2F0ZXMgdGhlIG5lY2Vzc2FyeSBiYW5kd2lkdGgNCj4+IFBy b3Zpc2lvbmVyOiBkZWNpZGVzIHdoYXQgcHJvdmlzaW9uaW5nIGlzIG5lY2Vzc2FyeSBpbiBlYWNo IHBhcnQgb2YNCj4+IHRoZSBwYXRoDQo+PiBBZGFwdG9yOiB0YWlsb3JzIHRoZSBwcm92aXNpb25p bmcgdG8gYSBzcGVjaWZpYyBib3gNCj4+IERyaXZlcjogcHVzaGVzIHRoZSBwcm92aXNpb25pbmcg aW50byB0aGUgZm9yd2FyZGluZyB0YWJsZXMgRm9yd2FyZGluZw0KPj4gZW5naW5lOiBmb3J3YXJk cyBhY2NvcmRpbmcgdG8gdGhlIHRhYmxlcw0KPj4NCj4+IFRoZSBJbnZlc3RvcidzIHN0YXRlbWVu dCBhdCB0aGUgdG9wIGlzIGNsZWFybHkgd2hhdCBhbmQgbm90IGhvdy4NCj4+IFRoZSBmb3J3YXJk aW5nIGVuZ2luZSdzIG9wZXJhdGlvbnMgaGF2ZSBhIGxvdCBvZiBob3csIGJ1dCBtYXliZSBsaXR0 bGUNCj5nbG9iYWwgdmlldyBvZiB3aGF0IHdlIGFyZSBkb2luZyBvdmVyYWxsLg0KPj4NCj4+IElm IHdlIHNheSB0aGF0IHRoZSB0b3AgaXMgaW50ZW50IGFuZCB0aGUgYm90dG9tIGlzIGEgaXMgc2Vy dmljZSByZXF1ZXN0LA0KPj4gICAgd2hvJ3MgdG8gc2F5IHdoZXJlIGludGVudCBzdG9wcyBhbmQg c2VydmljZSByZXF1ZXN0cyBzdGFydD8NCj4+DQo+PiBQZXJoYXBzICAnaW50ZW50JyBtZWFucyBh IHNlcnZpY2UgcmVxdWVzdCBjb21pbmcgZnJvbSBhIGhpZ2hlciBsYXllciBmb3INCj5yZWZpbmVt ZW50Lg0KPj4NCj4+IFRoYXQgc2FpZCwgdGhlIGRhdGEgbW9kZWwgZm9yIGludGVudCBtaWdodC9z aG91bGQgYmUgZGlmZmVyZW50IGF0IGVhY2gNCj5sZXZlbC4NCj4+IFNpbmNlIGVhY2ggbGV2ZWwg aXMgcHJvY2Vzc2luZyB0aGUgc2FtZSByZXF1ZXN0IGF0IGRpZmZlcmVudCBsZXZlbHMgb2YNCj5k ZXRhaWwsIGl0IG1pZ2h0IGJlIHNpbWlsYXIgYXQgZWFjaCBsZXZlbC4NCj4+IFBlcmhhcHMgdGhl IGRhdGEgbW9kZWwgc3RhcnRzIHNpbXBsZSBvbiB0b3AgYW5kIGdhdGhlcnMgbW9yZSBhbmQgbW9y ZQ0KPmRldGFpbCBhcyBpdCBnZXRzIGxvd2VyID8NCj4+IE1heWJlIGxpa2UgYSB0cmVlIHdpdGgg dGhlIHJvb3QgYXQgdGhlIHRvcCBhbmQgbGVhdmVzIGF0IHRoZSBmb3J3YXJkaW5nDQo+ZW5naW5l cywgZXhjZXB0IGRpc3RyaWJ1dGVkLg0KPj4NCj4+IFBlcmhhcHMgYSBzaW1wbGUgc3RhcnRpbmcg cG9pbnQgbmVhciB0aGUgdG9wIGlzIGEgY29tYmluYXRpb24gb2YNCj4+ZW50aXRpZXMsDQo+ZW5k cG9pbnRzLCBhbmQgY29ubmVjdGlvbnMuDQo+Pg0KPj4NCj4+IFJlZ2FyZHMsDQo+Pg0KPj4gU3R1 YXJ0IFZlbnRlcnMNCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+PiBGcm9tOiBzZG4gW21h aWx0bzpzZG4tYm91bmNlc0BpcnRmLm9yZ10gT24gQmVoYWxmIE9mIERhdmUgSG9vZA0KPj4gU2Vu dDogVHVlc2RheSwgSnVuZSAwMiwgMjAxNSA4OjI2IEFNDQo+PiBUbzogTGlmZW5na2FpIChGZW5n a2FpKTsgU3VzYW4gSGFyZXM7IHNkbkBpcnRmLm9yZw0KPj4gQ2M6IFpob3V0aWFucmFuOyBYaWF5 aW5iZW47IGlibmVtb0BpZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFtTZG5dIERlZmluaW5nIGEg Q29tbW9uIE1vZGVsIGZvciBpbnRlbnQNCj4+DQo+PiBJIGFncmVlIHRoYXQgdGhlIGNvbnRleHQg bWF0dGVycywgRmVuZ2thaSAoYW5kIFN1c2FuIGluIGVhcmxpZXINCj4+cmVzcG9uc2UpLg0KPldo YXQgdGhlIEktRCBhcHBlYXJzIHRvIGJlIHNheWluZyBpcyB0aGF0IGFueSBpbnRlcmFjdGlvbiBh Y3Jvc3MgYW4gTkJJIGlzDQo+aW50ZW50OiBvdGhlcndpc2UgdGhlIGFwcC90ZW5hbnQvY3VzdG9t ZXIgd291bGRuJ3QgZG8gaXQuIFRoYXQncyB0aGUgcm9vdA0KPm9mDQo+bXkgcXVlc3Rpb24gZnJv bSB0aGUgYmVnaW5uaW5nOiBob3cgd291bGQgd2Uga25vdyB3aGF0IGlzICpub3QqIGludGVudD8N Cj4+DQo+PiBJZiBJIGFzayBmb3Igc29tZSBwYXJ0aWN1bGFyIG1pY3Jvc2NvcGljYWxseSBkZXRh aWxlZCBjb25maWd1cmF0aW9uIChhDQo+ImhvdyIpLCBpdCdzIGJlY2F1c2UgSSBjYXJlLCBmb3Ig c29tZSByZWFzb24sIGFib3V0IHRoYXQgbGV2ZWwgb2YgZGV0YWlsLg0KPkl0DQo+aXMgaW4gZmFj dCBwYXJ0IG9mIG15IGludGVudC4NCj4+DQo+PiBJbiBteSBJVCBleGFtcGxlLCBJIGFyZ3VlIHRo YXQgaW50ZW50IG5lZWQgbm90IGJlIGluZGVwZW5kZW50IG9mDQo+PnByb3RvY29scw0KPmFuZCBw b3J0cywgYW5kIHRoYXQgaXQgbmVlZCBub3QgYmUgcG9ydGFibGUuIFlvdXIgcmVzcG9uc2UgYWJv dXQgY29udGV4dA0KPmFwcGVhcnMgdG8gYWdyZWUuDQo+Pg0KPj4gU28gYXMgYmVzdCBJIGNhbiB0 ZWxsLCB3ZSBjYW4gc2F5IHByZWNpc2VseSB3aGF0IGFuIGludGVudCBpcywgYW5kIHdlDQo+Y2Fu J3Qgc2F5IHdoYXQgYW4gaW50ZW50IGlzIG5vdC4gSWYgaW50ZW50IGlzIGp1c3QgdGhlIGxhdGVz dCBidXp6d29yZCwNCj53aGljaCBpdCBjZXJ0YWlubHkgYXBwZWFycyB0byBiZSwgY2FuIHdlIGp1 c3Qgc2F5IHNvIGFuZCBsZWF2ZSBpdCB0byB0aGUNCj5tYXJrZXRpbmcgcGVvcGxlPw0KPj4NCj4+ IERhdmUNCj4+DQo+PiBGcm9tOiBMaWZlbmdrYWkgKEZlbmdrYWkpIFttYWlsdG86bGlmZW5na2Fp QGh1YXdlaS5jb21dDQo+PiBTZW50OiBUdWVzZGF5LCBKdW5lIDAyLCAyMDE1IDEyOjQ3IEFNDQo+ PiBUbzogRGF2ZSBIb29kOyBTdXNhbiBIYXJlczsgc2RuQGlydGYub3JnDQo+PiBDYzogWmhvdXRp YW5yYW47IFhpYXlpbmJlbjsgaWJuZW1vQGlldGYub3JnDQo+PiBTdWJqZWN0OiBSRTogW1Nkbl0g RGVmaW5pbmcgYSBDb21tb24gTW9kZWwgZm9yIGludGVudA0KPj4NCj4+IEhpIERhdmUgYW5kIGFs bCwNCj4+DQo+PiBUaGFua3MgZm9yIHByb3Bvc2luZyB0aGUgdHdvIHZhbHVhYmxlIGludGVudCB1 c2UgY2FzZXMuDQo+Pg0KPj4gRm9yIHRoZSB1c2UgY2FzZSAyLCBJIGFncmVlIHRoYXQgdGhlIElU IGVtcGxveWVlIG5lZWRzIHRvIGluY2x1ZGUgdGhlDQo+ZGV0YWlscyBvZiBwb3J0cy9wcm90b2Nv bHMgaW50byBoaXMvaGVyIGludGVudCBkZXNjcmlwdGlvbnMsIGJ1dCB0aG9zZSBtYXkNCj5ub3Qg YmUgaW4gdGhlIGludGVudCBjb250ZXh0IHNjb3BlIG9mIGEgbm9uLUlUIGVtcGxveWVlLiBIYXZl IGEgZnVydGhlcg0KPmNvbnNpZGVyYXRpb24gd2l0aCB0aGlzLCBkaWZmZXJlbnQgdXNlcnMgb2Yg dGhlIG5ldHdvcmsgaGF2ZSB0aGVpciBvd24NCj5pbnRlbnQgaW4gYSBzcGVjaWZpYyBkb21haW4u IFRoZW4gdGhlIHJvbGVzL2FjdG9ycyBvZiBuZXR3b3JrIHVzZXJzLCBzdWNoDQo+YXMNCj5lbmQg dXNlcnMsIGFwcGxpY2F0aW9uIGRldmVsb3BlcnMsIHRlbmFudCBJVC9uZXR3b3JrIGFkbWluaXN0 cmF0b3JzLA0KPm9wZXJhdG9yIG5ldHdvcmsgYWRtaW5pc3RyYXRvcnMsIGFyZSB2YWx1YWJsZSB0 byBiZSBpZGVudGlmaWVkIGFuZA0KPmRpc3Rpbmd1aXNoZWQsIHRodXMgZml0dGluZyB0aGUgaW50 ZW50IHJlcXVpcmVtZW50cyBvZiB0aGUgbmV0d29yayB1c2Vycw0KPndpdGggZGlmZmVyZW50IHJv bGVzLg0KPj4NCj4+IEFueSB0aG91Z2h0cyBhYm91dCB0aGlzIGNvbnNpZGVyYXRpb24/DQo+Pg0K Pj4NCj4+IEJlc3QgUmVnYXJkcywNCj4+IEZlbmdrYWkNCj4+DQo+PiBGcm9tOiBzZG4gW21haWx0 bzpzZG4tYm91bmNlc0BpcnRmLm9yZ10gT24gQmVoYWxmIE9mIERhdmUgSG9vZA0KPj4gU2VudDog VHVlc2RheSwgSnVuZSAwMiwgMjAxNSAxOjM4IEFNDQo+PiBUbzogU3VzYW4gSGFyZXM7IHNkbkBp cnRmLm9yZw0KPj4gQ2M6IFpob3V0aWFucmFuOyBYaWF5aW5iZW47IGlibmVtb0BpZXRmLm9yZw0K Pj4gU3ViamVjdDogUmU6IFtTZG5dIERlZmluaW5nIGEgQ29tbW9uIE1vZGVsIGZvciBpbnRlbnQN Cj4+DQo+PiBBbiBleGNlcnB0IGZyb20gYW4gZW1haWwgSSBzZW50IG9uIHRoZSBPTkYgTkJJIGxp c3QsIHdoaWNoIG1heSBjb250YWluDQo+c29tZSB1c2VmdWwgdGhvdWdodHM6DQo+Pg0KPj4gSSBo YXZlIGFsd2F5cyBoYWQgdHJvdWJsZSB1bmRlcnN0YW5kaW5nIHdoYXQgYW4gaW50ZW50IHJlYWxs eSBpcywgc28gSQ0KPj5hbQ0KPmxvb2tpbmcgZm9yd2FyZCB0byBtYWtpbmcgdGhlIGNvbmNlcHQg bW9yZSBwcmVjaXNlLg0KPj4NCj4+IFdoZW4gSSBjbGljayBhIGxpbmsgb24gYSB3ZWIgcGFnZSwg SSBleHByZXNzIGFuIGludGVudCB0byBpbnZva2UNCj4+d2hhdGV2ZXINCj50aGF0IGxpbmsgb2Zm ZXJzLiBDb21wbGV0ZWx5IGJlbG93IHRoZSBzdXJmYWNlIGlzIGEgbGF5ZXIgc3RhY2ssIG9uLWRl bWFuZA0KPnNlc3Npb24gZXN0YWJsaXNobWVudCwgRE5TIGxvb2stdXBzLCBzZXJ2ZXIgbG9hZCBi YWxhbmNlcnMsIGFuZCBhbnkgbnVtYmVyDQo+b2Ygb3RoZXIgdGVjaG5vbG9naWNhbCBmZWF0dXJl cyB0aGF0IGFyZSBvZiBubyBpbnRlcmVzdCB0byBtZS4gV2h5IG5vdCB1c2UNCj50aGF0IGFzIGFu IGV4YW1wbGUgb2YgaW50ZW50Pw0KPj4NCj4+IEJldHRlciB5ZXQsIHdlIHRhbGsgYWJvdXQgbmVn b3RpYXRpb24gYW5kIHNlbGVjdGlvbi4gU3VwcG9zZSBJIHdhbnQgdG8NCj4+YnV5DQo+YSB3aWRn ZXQuIEkgcHJvYmFibHkgYWxyZWFkeSBoYXZlIHNvbWUgaWRlYSB3aGV0aGVyIEkgd2FudCB0byBn byB0byBBbWF6b24NCj5vciBFQmF5IG9yIHNvbWV3aGVyZSBlbHNlLiBTdXBwb3NlIGl0J3MgQW1h em9uLiBJIHNlYXJjaCBBbWF6b24ncyBjYXRhbG9nDQo+YW5kIHJlY2VpdmUgYW4gb2ZmZXIgb2Yg c2V2ZXJhbCB3aWRnZXRzLCBzb21lIG5ldywgc29tZSB1c2VkLCBzb21lIHdpdGggYQ0KPmNob2lj ZSBvZiBjb2xvdXIgb3Igb3RoZXIgcGVydGluZW50IGZlYXR1cmVzLiBJZiBJIHNlZSBub3RoaW5n IEkgbGlrZSwgSQ0KPm1heQ0KPm9wZW4gYSBuZXcgYnJvd3NlciB3aW5kb3cgYW5kIGNoZWNrIG91 dCBCZXN0IEJ1eSBvciBFQmF5IChsb3RzIG1vcmUgaGlkZGVuDQo+dGVjaG5vbG9neSB0byBtYWtl IHRoYXQgaGFwcGVuISkuIE1heWJlIEkgY29tZSBiYWNrIHRvIHRoZSBBbWF6b24gcGFnZSwNCj5o YXZpbmcgZm91bmQgbm90aGluZyBJIGxpa2VkIGJldHRlciBzb21ld2hlcmUgZWxzZS4gTm93IEkg YWNjZXB0IG9uZSBvZg0KPnRoZQ0KPm9mZmVyZWQgd2lkZ2V0cyBhbmQgZ28gdGhyb3VnaCB0aGUg Y2hlY2tvdXQgcHJvY2Vzcy4NCj4+DQo+PiBEbyB3ZSBhZ3JlZSB0aGF0IHRoaXMgaXMgYSBmYWly bHkgcHVyZSBleHByZXNzaW9uIG9mIGludGVudCBhcw0KPj4gY29uY2VwdHVhbGl6ZWQgaW4gdGhl IHBhcGVyPyAoSWYgbm90LCBsZXQncyB0YWxrIGFib3V0IG1ha2luZyBhIFNreXBlDQo+PiBjYWxs LikNCj4+DQo+PiBPaywgdGhhdCdzIG15IGludGVudCBhcyBhbiBpbnRlcm5ldCB1c2VyLiBMZXQn cyBhc3N1bWUgdGhlIG5ldHdvcmsgaXMNCj4+YWxsDQo+U0ROIG9mIG9uZSBraW5kIG9yIGFub3Ro ZXIuIEkgaW52b2tlIG15IGludGVudCB0aHJvdWdoIGEgR1VJIG9udG8gc29mdHdhcmUNCj5sb2Nh bCB0byBteSBQQywgYnV0IEkgZG9uJ3QgdGhpbmsgd2UgY2FuIGNhbGwgdGhlIFBDIGFuIFNETiBj b250cm9sbGVyLg0KPkl0J3MNCj5tb3JlIGFuIGFjdGl2ZSBtZWRpYXRvciwgYSBjbGllbnQgdG8g YW4gU0ROLiBBcyBmYXIgYXMgdGhlIG5ldHdvcmsgaXMNCj5jb25jZXJuZWQsIHRoZSBjbGllbnQg bWFrZXMgRE5TIHF1ZXJpZXMgYW5kIHN3YXBzIG9wYXF1ZSBUQ1AgcGFja2V0cyBvdmVyDQo+YQ0K PmZvcndhcmRpbmcgcGF0aCB0aGF0IG1heSBhbHJlYWR5IGV4aXN0LCBvciBtYXkgbmVlZCB0byBi ZSBsZWFybmVkIGFuZCBzZXQNCj51cA0KPm9uIGRlbWFuZC4gVGhpcyBpcyBhYm91dCByaWdodCwg YmVjYXVzZSB0aGUgc2Vzc2lvbiBjb250ZW50IG1heSB3ZWxsIGJlDQo+ZW5jcnlwdGVkIGVuZCB0 byBlbmQsIGFuZCByaWdodGx5Lg0KPj4NCj4+IFRvIHRoZSBTRE4gY29udHJvbGxlciwgbXkgaW50 ZW50IGlzIHNhdGlzZmllZCBieSBkaXJlY3RpbmcgRE5TIHF1ZXJpZXMNCj4+dG8NCj5hIGtub3du IEROUyBzZXJ2ZXIgc29tZXdoZXJlLCBhbmQgZW5zdXJpbmcgSVAgY29ubmVjdGl2aXR5IGZvciB0 aGUNCj5zdWJzZXF1ZW50IHNlc3Npb24uIEhtbW0uIHdoYXQgaGFwcGVuZWQgdG8gb3VyIGludGVu dC1iYXNlZCBOQkk/IFRoZSBTRE4NCj5vZmZlcmVkIG15IFBDIGEgcGFja2V0IGludGVyZmFjZSB3 aXRoIHRoZSBwcm9wZXJ0aWVzIG9mIGtub3dpbmcgaG93IHRvDQo+cmVjb2duaXplIGFuZCByb3V0 ZSBETlMgcXVlcmllcyBzcGVjaWFsbHksIGFuZCBnZW5lcmFsIElQIGNvbm5lY3Rpdml0eS4gTXkN Cj5QQyBhY2NlcHRlZCB0aGUgc2VydmljZSBvZmZlciBpbXBsaWNpdGx5IGJ5IG9mZmVyaW5nIHRy YWZmaWMgdG8gdGhlDQo+ZGF0YS1wbGFuZSBpbnRlcmZhY2UuIFRoZSBuZXR3b3JrIGNvdWxkIGJl IHBlcmZvcm1pbmcgYXNzb2NpYXRlZCBhdXhpbGlhcnkNCj5zZXJ2aWNlcyBzdWNoIGFzIHVzYWdl LWJhc2VkIGJpbGxpbmcgKHRoaW5rIHdpcmVsZXNzIHJvYW1pbmcpLCBzbyBpdCdzDQo+bW9yZQ0K PnRoYW4ganVzdCBhIGR1bWIgcGlwZS4NCj4+DQo+PiBJZiB0aGlzIGlzIG5vdCBhIGxlZ2l0aW1h dGUgZXhhbXBsZSBvZiBpbnRlbnQsIGl0IHdvdWxkIGJlIGdvb2QgdG8gd3JpdGUNCj50aGUgd2hp dGUgcGFwZXIgaW4gc3VjaCBhIHdheSB0aGF0IGNsZWFybHkgZXhjbHVkZXMgc3VjaCBjYXNlcy4N Cj4+DQo+PiBVc2UgY2FzZSAyOiBzdXBwb3NlIEkgYW0gYSBjb3Jwb3JhdGUgSVQgZW1wbG95ZWUs IGFuZCBzdXBwb3NlIHRoYXQgbXkNCj4+IGludGVudCBpcyB0byBoYXZlIGFuIEUtTGluZSBiZXR3 ZWVuIHR3byBvZiBteSBjYW1waS4gSSBuZWNlc3NhcmlseQ0KPj4gY2FyZSBhYm91dCBwb3J0cyBh bmQgcHJvdG9jb2xzOyB0YWxrIGFib3V0IGludGVudCBiZWluZyBwb3J0YWJsZSBhbmQNCj4+IHBy b3RvY29sIGluZGVwZW5kZW50IGNvbnRpbnVlcyB0byBjb25mdXNlIG1lIGNvbXBsZXRlbHkuIEhv dyBjYW4gSQ0KPj4gb3JkZXIgYW4gRS1saW5lIHdpdGhvdXQgY2FyaW5nIGFib3V0IHN1Y2ggZGV0 YWlscz8gW05vciBpcyB0aGlzIGludGVudA0KPj4gcG9ydGFibGUuXQ0KPj4NCj4+IE9idmlvdXNs eSwgYW4gU0ROIGNvbnRyb2xsZXIgaXMgZ29pbmcgdG8gZXhwb3NlIHdoYXRldmVyIGFjdGlvbnMg YW5kDQo+ZWxlbWVudHMgb2YgaW5mb3JtYXRpb24gYXJlIGdlcm1hbmUgdG8gdGhlIHNlcnZpY2Ug aXQgb2ZmZXJzLCBhbmQgaWYgcG9ydHMNCj5hbmQgcHJvdG9jb2xzIGFyZSBnZXJtYW5lIHRvIHRo ZSBzZXJ2aWNlLCBzbyBiZSBpdC4NCj4+DQo+PiBUaGUgU0ROIGFyY2hpdGVjdHVyZSwgYmVpbmcg cmVjdXJzaXZlLCBtb2RlbHMgdGhlIG5vcnRoIHNpZGUgb2YgYW55DQo+Y29udHJvbGxlciBhcyBl eHBvc2luZyBhbiBpbnN0YW5jZSBvZiBhbiBpbmZvcm1hdGlvbiBtb2RlbCwgY3VzdG9taXplZCBm b3INCj50aGUgaW50ZW5kZWQgY2xpZW50L2N1c3RvbWVyL2FwcC91c2VyLiBUaGF0IGJlaW5nIHRo ZSBjYXNlLCBob3cgZG8gd2UNCj5kaXN0aW5ndWlzaCBhbiBOQkkgQVBJIHRoYXQgY29udmV5cyBp bnRlbnQgKHNlcnZpY2U6IHNhbWUgdGhpbmc/KSBmcm9tIG9uZQ0KPnRoYXQgZG9lcyBub3Q/DQo+ Pg0KPj4gSSBoYXZlIHJlY2VudGx5IGNvbWUgdG8gdGhlIHZpZXcgdGhhdCBncmFudWxhcml0eSBp cyB0aGUgY3JpdGVyaW9uIGJ5DQo+d2hpY2ggYW4gaW50ZW50IG9yIHNlcnZpY2UgaW52b2NhdGlv biBpcyBkaXN0aW5ndWlzaGVkLiBDb2xsb3F1aWFsbHkNCj5zcGVha2luZywgYSBzZXJ2aWNlIGlu dm9jYXRpb24gaXMgYSBzaW5nbGUgaW52b2NhdGlvbiBhY3Jvc3MgdGhlIEFQSTogZ2l2ZQ0KPm1l IEUtTGluZS4gTm93IG9mIGNvdXJzZSB0aGlzIHR1cm5zIGludG8gY29uc3RyYWludCBuZWdvdGlh dGlvbiwgb2ZmZXIgYW5kDQo+YWNjZXB0YW5jZSwgYnV0IHdoYXQgaGFwcGVucyBhY3Jvc3MgdGhl IEFQSSBpcyBlZmZlY3RpdmVseSBvbmUNCj50cmFuc2FjdGlvbi4NCj5JbiBjb250cmFzdCwgd2hh dCB3ZSBtaWdodCBhZ3JlZSBpcyAqbm90KiBhbiBpbnRlbnQgb3IgYSBzZXJ2aWNlIGlzIHRoZQ0K Pm1hbmlwdWxhdGlvbiBvZiBhIGdyYW51bGFyIGluZm9ybWF0aW9uIG1vZGVsLCB0aGUgZXhwbGlj aXQgdmlzaWJpbGl0eSBvZg0KPm11bHRpcGxlIG9iamVjdHMsIGhvdyB0aGV5IGFyZSBpbnRlcnJl bGF0ZWQsIHRoZWlyIGF0dHJpYnV0ZXMsIGFuZCB0aGUNCj5saWtlLg0KPj4NCj4+IC4gICAgICAg ICBOZXR3b3JrIGFzIGEgc2luZ2xlIGx1bXAgdnMgc29tZSBub24tdHJpdmlhbCB0b3BvbG9neS4N Cj4+DQo+PiAuICAgICAgICAgQ2hhdWZmZXVyIHZzIGRyaXZpbmcgYSBjYXIuIExlZ2l0aW1hdGUg cmVhc29ucyB0byBjaG9vc2Ugb25lDQo+b3B0aW9uIG9yIHRoZSBvdGhlciwgYnV0IHRoZSBsZXZl bCBvZiBncmFudWxhcml0eSBpcyBxdWl0ZSBkaWZmZXJlbnQuDQo+U2hhbGwNCj53ZSBhZ3JlZSB0 aGF0IGRyaXZpbmcgaXMgdG9vIGdyYW51bGFyIHRvIGJlIGNvbnNpZGVyZWQgaW50ZW50Pw0KPj4N Cj4+IFRoaXMgaWRlYSBvZiBncmFudWxhcml0eSBhbmQgZGV0YWlsZWQgb3BlcmF0aW9ucyBvbiB0 aGUgY29tcG9uZW50cw0KPj4od2hpY2gNCj5vZiBjb3Vyc2UgbWF5IGJlIGNvbXBsZXggZW50aXRp ZXMgdGhlbXNlbHZlcywgdmlydHVhbGl6ZWQgaW50bw0KPnNpbXBsZS1hcHBlYXJpbmcgbHVtcHMp IHNlZW1zIHRvIG1lIHRvIGNhcHR1cmUgdGhlIGVzc2VuY2Ugb2Ygd2hhdCBwZW9wbGUNCj5hcmUg dGFsa2luZyBhYm91dCB3aGVuIHRoZXkgc2F5IGludGVudCBvciBzZXJ2aWNlLiBJIGFtIG5vdCBj b21mb3J0YWJsZQ0KPndpdGgNCj50aGUgd2F5IEkgYW0gZXhwcmVzc2luZyBpdCwgc28gaWYgdGhp cyBpcyBhIHN0ZXAgaW4gYSBwcm9kdWN0aXZlDQo+ZGlyZWN0aW9uLA0KPm9yIGV2ZW4gaWYgaXQn cyBub3QsIEkgd2VsY29tZSBzdWdnZXN0aW9ucyB0byBjbGFyaWZ5IHRoZSBjb25jZXB0Lg0KPj4N Cj4+IERhdmUNCj4+DQo+PiBGcm9tOiBzZG4gW21haWx0bzpzZG4tYm91bmNlc0BpcnRmLm9yZ10g T24gQmVoYWxmIE9mIFN1c2FuIEhhcmVzDQo+PiBTZW50OiBTYXR1cmRheSwgTWF5IDMwLCAyMDE1 IDE6MDIgUE0NCj4+IFRvOiBzZG5AaXJ0Zi5vcmcNCj4+IENjOiAnWmhvdXRpYW5yYW4nOyAnWGlh eWluYmVuJzsgaWJuZW1vQGlldGYub3JnDQo+PiBTdWJqZWN0OiBbU2RuXSBEZWZpbmluZyBhIENv bW1vbiBNb2RlbCBmb3IgaW50ZW50DQo+Pg0KPj4gT24gdGhpcyBtYWlsIGxpc3QsIHRoZXJlIGhh cyBiZWVuIGEgZGlzY3Vzc2lvbiBvZiB0d28gdHlwZXMgb2YNCj4+aW5mb3JtYXRpb24NCj5mb3Ig SW50ZW50IGFuZCBOZW1vOg0KPihodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv c2RuL2N1cnJlbnQvbXNnMDA2NDYuaHRtbCkgOg0KPj4NCj4+IDEpICAgICAgV2hhdCBpbmZvcm1h dGlvbiBpcyBuZWVkZWQgdG8gcmVwcmVzZW50IGEgc2VydmljZSByZXF1ZXN0LA0KPj4gMikgICAg ICBIb3cgdG8gcmVwcmVzZW50IGFuZCB0cmFuc3BvcnQgdGhlIGluZm9ybWF0aW9uIGZvciBhIHJl cXVlc3QuDQo+Pg0KPj4gSW4gb3JkZXIgdG8gZGVmaW5lIHdoYXQgaW5mb3JtYXRpb24gaXMgbmVl ZGVkIHRvIHJlcHJlc2VudCBhIDEpIHNlcnZpY2UNCj5yZXF1ZXN0IHRoYXQgc2lnbmFscyBJbnRl bnQgZnJvbSBhbiBhcHBsaWNhdGlvbiB0byBhIGNvbnRyb2xsZXIsIGl0IGlzDQo+aW1wb3J0YW50 IHRvIGRlZmluZSBJbnRlbnQsIGFuZCBwcm92aWRlIGEgY2xlYXIgbW9kZWwgb2YgSW50ZW50LiAg QWxzbywgaW4NCj5kZXNjcmliaW5nIHJlYWwgdXNlLWNhc2VzIGl0IGlzIGltcG9ydGFudCB0aGF0 IG9uZSB1c2VzIHRoZSBzYW1lDQo+ZGVmaW5pdGlvbg0KPmFuZCBtb2RlbCBmb3IgSW50ZW50IGlu IGVhY2ggdXNlIGNhc2UuDQo+Pg0KPj4gSW4gdGhlIGN1cnJlbnQgZm9ydW1zIGV4YW1pbmluZyBJ bnRlbnQgKE9ETCBOSUMsIE9ETCBOZW1vLCBPRiBOQkkgYW5kDQo+S2V5c3RvbmUsIE9QTkZWIE1v dmllLCBPcGVuU3RhY2spIHRoZXJlIGlzIGEgcmVhbGl6YXRpb24gdGhhdCBJbnRlbnQNCj5vY2N1 cnMNCj5hdCBtdWx0aXBsZSBsYXllcnMuICBUaGUgYXV0aG9ycyBvZiBkcmFmdC14aWEtaWJuZW1v LWljaW0gaGF2ZSBjcmVhdGVkIGENCj5kZWZpbml0aW9uIGZvciBpbnRlbnQgYW5kIGEgdW5pZmll ZCBtb2RlbCBmb3IgZGVmaW5pbmcgaW50ZW50IHdoaWNoIGNhbg0KPmhhbmRsZSAxIG9yIG11bHRp cGxlIGxheWVycy4gVGhlIG1vZGVsIHN1Z2dlc3QgdGhhdDoNCj4+IDEpICAgICAgQSB1c2VyIGhh cyBhIGludGVudCB0aGF0IGlzIGV4cHJlc3NlZCBpbiBhIGNvbnRleHQuDQo+PiAyKSAgICAgIElu dGVudCAodXN1YWxseSkgaW52b2x2ZXMgYW4gb2JqZWN0IHdpdGggYSByZXN1bHQsIGFuZA0KPj5v cHRpb25hbGx5DQo+aW5jbHVkZXMgb3BlcmF0aW9ucyB0b3dhcmQgdGhhdCByZXN1bHQuDQo+PiAz KSAgICAgIE9wZXJhdGlvbnMgY29uZGl0aW9ucyBwZXJmb3JtIGFjdGlvbnMgd2l0aGluL21vZGlm aWVkIGJ5DQo+Y29uc3RyYWludHMuDQo+Pg0KPj4gV2UgYmVsaWV2ZSB0aGlzIGRlZmluZXMgY2xl YXJseSB3aGF0IG90aGVycyBhcmUgY2FsbGluZyAicHVyZSBpbnRlbnQiDQo+KG9iamVjdHMgKyBy ZXN1bHRzKSB2ZXJzdXMgImNvbnN0cmFpbmVkIGludGVudCIgKG9iamVjdHMgKyBvcGVyYXRpb25z ICsNCj5jb25zdHJhaW50cykuICAgVGhlIGRyYWZ0IGNhbiBiZSBmb3VuZCBhdDoNCj5odHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC14aWEtaWJuZW1vLWljaW0vIC4gICBUaGUg YXV0aG9ycw0KPmFyZQ0KPmxvb2tpbmcgZm9yIGZlZWRiYWNrIG9uIHRoZSBjb25jZXB0cyBpbiB0 aGUgZHJhZnQuDQo+Pg0KPj4gU3VlIEhhcmVzDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IHNkbiBtYWlsaW5nIGxpc3QNCj4+IHNkbkBp cnRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaXJ0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZG4NCj4+ DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4g SWJuZW1vIG1haWxpbmcgbGlzdA0KPj4gSWJuZW1vQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2libmVtbw0KPj4NCj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnNkbiBtYWlsaW5nIGxpc3QNCj5zZG5AaXJ0 Zi5vcmcNCj5odHRwczovL3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nkbg0KPg0KPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+SWJuZW1vIG1h aWxpbmcgbGlzdA0KPklibmVtb0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaWJuZW1vDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cg0KRXN0ZSBtZW5zYWplIHkgc3VzIGFkanVudG9zIHNlIGRpcmlnZW4gZXhjbHVzaXZhbWVudGUg YSBzdSBkZXN0aW5hdGFyaW8sIHB1ZWRlIGNvbnRlbmVyIGluZm9ybWFjacOzbiBwcml2aWxlZ2lh ZGEgbyBjb25maWRlbmNpYWwgeSBlcyBwYXJhIHVzbyBleGNsdXNpdm8gZGUgbGEgcGVyc29uYSBv IGVudGlkYWQgZGUgZGVzdGluby4gU2kgbm8gZXMgdXN0ZWQuIGVsIGRlc3RpbmF0YXJpbyBpbmRp Y2FkbywgcXVlZGEgbm90aWZpY2FkbyBkZSBxdWUgbGEgbGVjdHVyYSwgdXRpbGl6YWNpw7NuLCBk aXZ1bGdhY2nDs24geS9vIGNvcGlhIHNpbiBhdXRvcml6YWNpw7NuIHB1ZWRlIGVzdGFyIHByb2hp YmlkYSBlbiB2aXJ0dWQgZGUgbGEgbGVnaXNsYWNpw7NuIHZpZ2VudGUuIFNpIGhhIHJlY2liaWRv IGVzdGUgbWVuc2FqZSBwb3IgZXJyb3IsIGxlIHJvZ2Ftb3MgcXVlIG5vcyBsbyBjb211bmlxdWUg aW5tZWRpYXRhbWVudGUgcG9yIGVzdGEgbWlzbWEgdsOtYSB5IHByb2NlZGEgYSBzdSBkZXN0cnVj Y2nDs24uDQoNClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyB0cmFuc21pc3Npb24g aXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGludGVuZGVkIG9ubHkg Zm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IG5hbWVkIGFib3ZlLiBJZiB0 aGUgcmVhZGVyIG9mIHRoaXMgbWVzc2FnZSBpcyBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwg eW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0 aW9uIG9yIGNvcHlpbmcgb2YgdGhpcyBjb21tdW5pY2F0aW9uIGlzIHN0cmljdGx5IHByb2hpYml0 ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBkbyBu b3QgcmVhZCBpdC4gUGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgdGhhdCB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IgYW5kIHRoZW4gZGVs ZXRlIGl0Lg0KDQpFc3RhIG1lbnNhZ2VtIGUgc2V1cyBhbmV4b3Mgc2UgZGlyaWdlbSBleGNsdXNp dmFtZW50ZSBhbyBzZXUgZGVzdGluYXTDoXJpbywgcG9kZSBjb250ZXIgaW5mb3JtYcOnw6NvIHBy aXZpbGVnaWFkYSBvdSBjb25maWRlbmNpYWwgZSDDqSBwYXJhIHVzbyBleGNsdXNpdm8gZGEgcGVz c29hIG91IGVudGlkYWRlIGRlIGRlc3Rpbm8uIFNlIG7Do28gw6kgdm9zc2Egc2VuaG9yaWEgbyBk ZXN0aW5hdMOhcmlvIGluZGljYWRvLCBmaWNhIG5vdGlmaWNhZG8gZGUgcXVlIGEgbGVpdHVyYSwg dXRpbGl6YcOnw6NvLCBkaXZ1bGdhw6fDo28gZS9vdSBjw7NwaWEgc2VtIGF1dG9yaXphw6fDo28g cG9kZSBlc3RhciBwcm9pYmlkYSBlbSB2aXJ0dWRlIGRhIGxlZ2lzbGHDp8OjbyB2aWdlbnRlLiBT ZSByZWNlYmV1IGVzdGEgbWVuc2FnZW0gcG9yIGVycm8sIHJvZ2Ftb3MtbGhlIHF1ZSBub3MgbyBj b211bmlxdWUgaW1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtZXNtYSB2aWEgZSBwcm9jZWRhIGEgc3Vh IGRlc3RydWnDp8Ojbw0K From nobody Thu Jun 4 23:46:06 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979091A1A54 for ; Thu, 4 Jun 2015 23:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.761 X-Spam-Level: X-Spam-Status: No, score=-1.761 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DABAH-B2uel for ; Thu, 4 Jun 2015 23:46:01 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C54251A0387 for ; Thu, 4 Jun 2015 23:46:00 -0700 (PDT) Received: from 172.24.2.119 (EHLO nkgeml406-hub.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CMP26103; Fri, 05 Jun 2015 14:45:32 +0800 (CST) Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.152]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Fri, 5 Jun 2015 14:41:53 +0800 From: Zhoutianran To: "Bert Wijnen (IETF)" , STUART VENTERS , "sdn@irtf.org" Thread-Topic: [Ibnemo] [Sdn] Defining a Common Model for intent Thread-Index: AQHQnJG50WlY7ClbtUGoYewpxJwlHZ2YUVeAgABezYCAACyygIABp5jQ//+5CQCAAguJpP//r62AgAGClnA= Date: Fri, 5 Jun 2015 06:41:52 +0000 Message-ID: References: <00f301d09b13$79cc2410$6d646c30$@ndzh.com> <8D15A2BAF93E9C49AB037A0647E5FA643F8490D8@eusaamb105.ericsson.se> <865C20BAAE8BBD4C89E7D6FE694F6B3B2D3CA540@nkgeml505-mbs.china.huawei.com> <8D15A2BAF93E9C49AB037A0647E5FA643F84AAA2@eusaamb105.ericsson.se> <1220E2C537595D439C5D026E83751866C42AC2FF@ex-mb3.corp.adtran.com> , <556EFC42.9040208@bwijnen.net> <5570700D.7000604@bwijnen.net> In-Reply-To: <5570700D.7000604@bwijnen.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.21] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "ibnemo@ietf.org" Subject: Re: [Sdn] [Ibnemo] Defining a Common Model for intent X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 06:46:05 -0000 VGhhbmtzIEJlcnQgZm9yIHlvdXIgY2xhcmlmaWNhdGlvbi4NCg0KVGhhdCdzIGFub3RoZXIgZ29v ZCBkZXNjcmlwdGlvbiBvbiB0aGUgcm9sZSBiYXNlZCBpbnRlbnQgSSB0aGluay4NCg0KDQpUZXJl bmNlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBCZXJ0IFdpam5lbiAoSUVU RikgW21haWx0bzpid2lldGZAYndpam5lbi5uZXRdIA0KU2VudDogVGh1cnNkYXksIEp1bmUgMDQs IDIwMTUgMTE6MzUgUE0NClRvOiBaaG91dGlhbnJhbjsgU1RVQVJUIFZFTlRFUlM7IHNkbkBpcnRm Lm9yZw0KQ2M6IGlibmVtb0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtJYm5lbW9dIFtTZG5dIERl ZmluaW5nIGEgQ29tbW9uIE1vZGVsIGZvciBpbnRlbnQNCg0KT24gMDQvMDYvMTUgMTQ6MjYsIFpo b3V0aWFucmFuIHdyb3RlOg0KPiBIaSBCZXJ0LA0KPg0KPiBUaGFua3MgZm9yIHlvdSBjb21tZW50 cy4NCj4gSSBhZ3JlZSB3aXRoIHlvdSB0aGF0IHdlJ2QgYmV0dGVyIGp1c3QgZm9jdXMgb24gdGhl IHRvcCBsYXllci4NCj4gQnV0IEkgYW0gc29ycnksIHdoYXQgZG8geW91IG1lYW4gaW4gdGhlIGxh c3Qgc2VudGVuY2U/DQo+ICJBIHJvbGUgLWJhc2VkIGludGVudCBtb2RlbD8gSSBndWVzcyBpdCB3 b3VsZCBqdXN0IGJvaWwgZG93biBpbiBkaWZmZXJlbnQgdHlwZXMgb2YgaW50ZW50IHRoYXQgZml0 IHdpdGggdGhlIHNwZWNpZmljIHJvbGUsIHJpZ2h0PyINCj4gQ291bGQgeW91IGdpdmUgbW9yZSBp bmZvcm1hdGlvbiBvbiB0aGlzPw0KDQpTb3JyeSBmb3Igbm90IGJlaW5nIGNsZWFyLA0KDQpteSB0 aGlua2luZyBoZXJlIGlzIHRoYXQNCi0gaW50ZW50IG1vZGVsIGlzIGJhc2ljYWxseSB0aGUgc2Ft ZSBmb3IgYW55b25lLg0KLSBidXQgYmFzZWQgb24geW91ciByb2xlLCB5b3UgZXhwcmVzcyB5b3Vy IGludGVudCB3aXRoIGRpZmZlcmVudCAocm9sZSBzcGVjaWZpYykNCiAgICBzdGF0ZW1lbnRzLiBU aGF0IHBvc3NpYmx5IG1lYW5zIHlvdSB1c2Ugc2ltaWxhciBsYW5ndWFnZSAoSURMKSBidXQgeW91 IHVzZQ0KICAgIGRpZmZlcmVudCBvYmplY3RzIChkYXRhKSB0byBleHByZXNzIGl0DQoNClNvIGEg Y3VzdG9tZXIvZW5kLXVzZXIgc2F5cw0KICAgSSB3YW50IGEgbGluayBiZXR3ZWVuIGxvY2F0aW9u IEEgYW5kIEIsIGkuZS4gbXkgaW50ZW50IGlzIHRvIHVzZSBhIGNvbm5lY3Rpb24gYmV0d2VlbiBB ICYgQg0KICAgYW5kIEkgd2FudCAxR0Igd2l0aCBsb3cgZGVsYXkNClRoZSBzZXJ2aWNlIHByb3Zp ZGVyIHdobyBuZWVkcyB0byBpbXBsZW1lbnQgdGhpcyBzYXlzIHRoaW5ncyBsaWtlDQogICBDcmVh dGUgIGEgcGh5c2ljYWwgbGluayBiZXR3ZWVuIEEmQg0KICAgb3IgY3JlYXRlIGEgbG9naWNhbCBs aW5rIGJldHdlZW4gQSZCIHdpdGggZ3VhcmFudGVlZCAxR0IgY2FwYWNpdHkNCg0KU28gdGhlIGN1 c3RvbWVyL2VuZC11c2VyIGRvZXMgbm90IGNhcmUgYWJvdXQgcGh5c2ljYWwgb3IgbG9naWNhbCBv ciB3aGF0ZXZlci4NCk1heWJlIGhlL3NoZSBkb2VzIG5vdCBldmVuIHdhbnQgdG8ga25vdy4NCg0K QnV0IHRoZSBzZXJ2aWNlIHByb3ZpZGVyIG9mIGNvdXJzZSBuZWVkcyB0byBleHByZXNzIGludGVu dCBhYm91dCBwaHlzaWNhbCBvciBsb2dpY2FsDQoNCkRvZXMgdGhhdCBoZWxwPw0KDQpCZXJ0DQoN Cj4gQmVzdCwNCj4gVGVyZW5jZQ0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ILeivP7IyzogQmVydCBXaWpuZW4gKElFVEYpIFtid2lldGZAYndpam5lbi5u ZXRdDQo+ILeiy83KsbzkOiAyMDE1xOo21MIzyNUgMjE6MDgNCj4gytW8/sjLOiBaaG91dGlhbnJh bjsgU1RVQVJUIFZFTlRFUlM7IHNkbkBpcnRmLm9yZw0KPiCzrcvNOiBpYm5lbW9AaWV0Zi5vcmcN Cj4g1vfM4jogUmU6IFtJYm5lbW9dIFtTZG5dIERlZmluaW5nIGEgQ29tbW9uIE1vZGVsIGZvciBp bnRlbnQNCj4NCj4gSGkgYWxsLA0KPg0KPiBJIGxpa2UgdGhlIGlkZWEgb2YgKGF0IGxlYXN0IGZv ciBub3cpIHN0aWNrIHRvIHRoZSBwcm9ibGVtIG9mICJpbnRlbnQiIGZvciBvbmUgbGF5ZXIgKHRo ZSB0b3AgbGF5ZXIpLg0KPiBMZXQgdXMgbm90IGJvaWwgdGhlIG9jZWFuIGFuZCB0cnkgdG8gZG8g ZXZlcnl0aGluZyB0aGF0IGNvbWVzIHVwLiBJZiANCj4gd2UgYXJlIHN1Y2Nlc3NmdWwgaW4gZG9p bmcgYSBtb2RlbCBmb3IgSUJORU1PIGZvciB0aGUgdG9wIGxheWVyLCB3ZSBjYW4gdGhlbiBzZWUg aWYgd2Ugd2FudCB0byBnbyBhdCBtb3JlIGxheWVycy4NCj4NCj4gQSByb2xlIC1iYXNlZCBpbnRl bnQgbW9kZWw/IEkgZ3Vlc3MgaXQgd291bGQganVzdCBib2lsIGRvd24gaW4gDQo+IGRpZmZlcmVu dCB0eXBlcyBvZiBpbnRlbnQgdGhhdCBmaXQgd2l0aCB0aGUgc3BlY2lmaWMgcm9sZSwgcmlnaHQ/ DQo+DQo+IEJlcnQNCj4NCj4NCj4gT24gMDMvMDYvMTUgMTE6NDQsIFpob3V0aWFucmFuIHdyb3Rl Og0KPj4gSGkgU3R1YXJ0LA0KPj4NCj4+IFRoYW5rcyBmb3IgdGhpcyBkZWVwIHRoaW5raW5nIHdp dGggYSBzZXQgb2YgZXhhbXBsZXMuIEl0J3MgcmVhbGx5IGltcG9ydGFudCB0byBjbGFyaWZ5IHRo aXMgZnV6enkgaW50ZW50Lg0KPj4gSSB0aGluayBhbGwgdGhlIGNvbmNlcm4gYW5kIHVuY2VydGFp bnR5IGlzIGJlY2F1c2Ugb2YgdGhlIGxheWVyZWQgdGhpbmtpbmcuIFdlIHRoaW5rIGludGVudCBp cyBhIHJlbGF0aXZlbHkgaGlnaGVyIGxldmVsIG5lc3RlZC4NCj4+IFdoYXQgaWYgd2UgdGhpbmsg YWJvdXQgaW50ZW50IHdpdGggZGlmZmVybmV0IHJvbGVzPyBKdXN0IGxpa2UgYSByZWxhdGl2ZSBk ZXRhaWxlZCBkZXNjcmlwdGlvbiBpbiBteSAicm9sZSBiYXNlZCBpbnRlbnQiIGVtYWlsLg0KPj4g SSB0aGluayB0aGUgZXNzZW50aWFsIG9mIHRoZSByb2xlIGJhc2VkIGludGVudCBpcyB0aGF0IHRo ZXJlIGlzIG9ubHkgb25lIGludGVudCBsYXllciB3aGljaCBpcyBhbHdheXMgb24gdGhlIHRvcC4g SW50ZW50IGlzIGRlZGljYXRlZCBmb3IgY29ycmVzcG9uZGluZyByb2xlcy4gT25lIHJvbGUgd2ls bCBub3QgY2FsbCBvdGhlciByb2xlcyBpbnRlcmZhY2VzLg0KPj4gVGhlbiB3ZSBjYW4gdHJ5IHRv IGZpbmQgd2F5IHRvIGV4cHJlc3MgaW50ZW50IGZvciB2YXJpb3VzIHJvbGVzLg0KPj4NCj4+DQo+ PiBSZWdhcmRzLA0KPj4gVGVyZW5jZQ0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+PiBGcm9tOiBzZG4gW21haWx0bzpzZG4tYm91bmNlc0BpcnRmLm9yZ10gT24gQmVoYWxmIE9m IFNUVUFSVCBWRU5URVJTDQo+PiBTZW50OiBXZWRuZXNkYXksIEp1bmUgMDMsIDIwMTUgMTI6MDYg QU0NCj4+IFRvOiBzZG5AaXJ0Zi5vcmcNCj4+IENjOiAnRGF2ZSBIb29kJzsgaWJuZW1vQGlldGYu b3JnOyBMaWZlbmdrYWkgKEZlbmdrYWkpOyBaaG91dGlhbnJhbjsgDQo+PiBYaWF5aW5iZW47IFN1 c2FuIEhhcmVzDQo+PiBTdWJqZWN0OiBSZTogW1Nkbl0gRGVmaW5pbmcgYSBDb21tb24gTW9kZWwg Zm9yIGludGVudA0KPj4NCj4+DQo+Pg0KPj4gSSBoYXZlIDIgY2VudHMgdG8gY29udHJpYnV0ZSBm b3IgdGhpcyBmdXp6eSBpbnRlbnQgd29yZCBhbmQgcmVzdWx0aW5nIGRhdGEgbW9kZWwuDQo+PiBQ ZXJoYXBzICdpbnRlbnQnICBpcyBqdXN0IGEgcmVsYXRpdmVseSBoaWdoIGxldmVsIHNlcnZpY2Ug cmVxdWVzdC4NCj4+IFRoZSBwcm9ibGVtIHdpdGggdGhpcyBkZWZpbml0aW9uIGlzIHdoYXQgaXMg dGhhdCAncmVsYXRpdmVseSBoaWdoIGxldmVsJyBhcHBlYXJzIHRvIGRlcGVuZCBvbiB5b3VyIHBv aW50IG9mIHZpZXcuDQo+Pg0KPj4gVG8gaGVscCB0aGluayBhYm91dCBpdCwgaGVyZSdzIGEgbG9u ZyBjaGFpbiBvZiBjb21tYW5kIGZvciB0aGUgc2FtZSBhY3Rpb24uDQo+PiBJdCBpcyBsb25nIGZv ciBmdW4gYW5kIHNvIHRoYXQgYW55Ym9keSBjYW4gZmluZCBwYXJ0IG9mIGl0IHRoYXQgdGhleSBy ZWNvZ25pemUuDQo+Pg0KPj4NCj4+IENoYWluIG9mIGNvbW1hbmQ6DQo+Pg0KPj4gSW52ZXN0b3Ig c2F5czogbWFrZSBtb25leQ0KPj4gQ0VPIHNheXM6IG1ha2UgdGhlIG5ldHdvcmsgd29yaw0KPj4g Q0lPIHNheXM6IGdpdmUgbWUgYmFuZHdpZHRocyBiZXR3ZWVuIHNpdGVzIEEsIEIsIGFuZCBDIE5l dCBlbmdpbmVlciANCj4+IHNheXM6IEkgbmVlZCB0aGVzZSBldmMncyB0byB0aGVzZSBlbmRwb2lu dHMgUHVyY2hhc2luZyBhZ2VudDogU2F5cyANCj4+IHVzZSB0aGlzIHByb2R1Y3QgZnJvbSB0aGlz IHZlbmRvciBTYWxlcyBQZXJzb24gc2F5czogSGVyZSBpcyB0aGUgDQo+PiBwcmljZSBhbmQgcHJp b3JpdHkNCj4+IFBhcnRpdGlvbmVyOiBkaXZpZGVzIHRoZSBlbmQgdG8gZW5kIGNpcmN1aXQgYW1v bmcgYWRtaW5pc3RyYXRpdmUgDQo+PiBkb21haW5zDQo+PiBQbGFubmVyOiBwaWNrcyB0aGUgbmVj ZXNzYXJ5IHJlc291cmNlcyB0byB1c2UsIG1ha2VzIHRoZSB0cnVjayByb2xscyANCj4+IGhhcHBl bg0KPj4gQWxsb2NhdG9yOiBhbGxvY2F0ZXMgdGhlIG5lY2Vzc2FyeSBiYW5kd2lkdGgNCj4+IFBy b3Zpc2lvbmVyOiBkZWNpZGVzIHdoYXQgcHJvdmlzaW9uaW5nIGlzIG5lY2Vzc2FyeSBpbiBlYWNo IHBhcnQgb2YgDQo+PiB0aGUgcGF0aA0KPj4gQWRhcHRvcjogdGFpbG9ycyB0aGUgcHJvdmlzaW9u aW5nIHRvIGEgc3BlY2lmaWMgYm94DQo+PiBEcml2ZXI6IHB1c2hlcyB0aGUgcHJvdmlzaW9uaW5n IGludG8gdGhlIGZvcndhcmRpbmcgdGFibGVzIEZvcndhcmRpbmcgDQo+PiBlbmdpbmU6IGZvcndh cmRzIGFjY29yZGluZyB0byB0aGUgdGFibGVzDQo+Pg0KPj4gVGhlIEludmVzdG9yJ3Mgc3RhdGVt ZW50IGF0IHRoZSB0b3AgaXMgY2xlYXJseSB3aGF0IGFuZCBub3QgaG93Lg0KPj4gVGhlIGZvcndh cmRpbmcgZW5naW5lJ3Mgb3BlcmF0aW9ucyBoYXZlIGEgbG90IG9mIGhvdywgYnV0IG1heWJlIGxp dHRsZSBnbG9iYWwgdmlldyBvZiB3aGF0IHdlIGFyZSBkb2luZyBvdmVyYWxsLg0KPj4NCj4+IElm IHdlIHNheSB0aGF0IHRoZSB0b3AgaXMgaW50ZW50IGFuZCB0aGUgYm90dG9tIGlzIGEgaXMgc2Vy dmljZSByZXF1ZXN0LA0KPj4gICAgIHdobydzIHRvIHNheSB3aGVyZSBpbnRlbnQgc3RvcHMgYW5k IHNlcnZpY2UgcmVxdWVzdHMgc3RhcnQ/DQo+Pg0KPj4gUGVyaGFwcyAgJ2ludGVudCcgbWVhbnMg YSBzZXJ2aWNlIHJlcXVlc3QgY29taW5nIGZyb20gYSBoaWdoZXIgbGF5ZXIgZm9yIHJlZmluZW1l bnQuDQo+Pg0KPj4gVGhhdCBzYWlkLCB0aGUgZGF0YSBtb2RlbCBmb3IgaW50ZW50IG1pZ2h0L3No b3VsZCBiZSBkaWZmZXJlbnQgYXQgZWFjaCBsZXZlbC4NCj4+IFNpbmNlIGVhY2ggbGV2ZWwgaXMg cHJvY2Vzc2luZyB0aGUgc2FtZSByZXF1ZXN0IGF0IGRpZmZlcmVudCBsZXZlbHMgb2YgZGV0YWls LCBpdCBtaWdodCBiZSBzaW1pbGFyIGF0IGVhY2ggbGV2ZWwuDQo+PiBQZXJoYXBzIHRoZSBkYXRh IG1vZGVsIHN0YXJ0cyBzaW1wbGUgb24gdG9wIGFuZCBnYXRoZXJzIG1vcmUgYW5kIG1vcmUgZGV0 YWlsIGFzIGl0IGdldHMgbG93ZXIgPw0KPj4gTWF5YmUgbGlrZSBhIHRyZWUgd2l0aCB0aGUgcm9v dCBhdCB0aGUgdG9wIGFuZCBsZWF2ZXMgYXQgdGhlIGZvcndhcmRpbmcgZW5naW5lcywgZXhjZXB0 IGRpc3RyaWJ1dGVkLg0KPj4NCj4+IFBlcmhhcHMgYSBzaW1wbGUgc3RhcnRpbmcgcG9pbnQgbmVh ciB0aGUgdG9wIGlzIGEgY29tYmluYXRpb24gb2YgZW50aXRpZXMsIGVuZHBvaW50cywgYW5kIGNv bm5lY3Rpb25zLg0KPj4NCj4+DQo+PiBSZWdhcmRzLA0KPj4NCj4+IFN0dWFydCBWZW50ZXJzDQo+ Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4gRnJvbTogc2RuIFttYWlsdG86c2RuLWJvdW5j ZXNAaXJ0Zi5vcmddIE9uIEJlaGFsZiBPZiBEYXZlIEhvb2QNCj4+IFNlbnQ6IFR1ZXNkYXksIEp1 bmUgMDIsIDIwMTUgODoyNiBBTQ0KPj4gVG86IExpZmVuZ2thaSAoRmVuZ2thaSk7IFN1c2FuIEhh cmVzOyBzZG5AaXJ0Zi5vcmcNCj4+IENjOiBaaG91dGlhbnJhbjsgWGlheWluYmVuOyBpYm5lbW9A aWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbU2RuXSBEZWZpbmluZyBhIENvbW1vbiBNb2RlbCBm b3IgaW50ZW50DQo+Pg0KPj4gSSBhZ3JlZSB0aGF0IHRoZSBjb250ZXh0IG1hdHRlcnMsIEZlbmdr YWkgKGFuZCBTdXNhbiBpbiBlYXJsaWVyIHJlc3BvbnNlKS4gV2hhdCB0aGUgSS1EIGFwcGVhcnMg dG8gYmUgc2F5aW5nIGlzIHRoYXQgYW55IGludGVyYWN0aW9uIGFjcm9zcyBhbiBOQkkgaXMgaW50 ZW50OiBvdGhlcndpc2UgdGhlIGFwcC90ZW5hbnQvY3VzdG9tZXIgd291bGRuJ3QgZG8gaXQuIFRo YXQncyB0aGUgcm9vdCBvZiBteSBxdWVzdGlvbiBmcm9tIHRoZSBiZWdpbm5pbmc6IGhvdyB3b3Vs ZCB3ZSBrbm93IHdoYXQgaXMgKm5vdCogaW50ZW50Pw0KPj4NCj4+IElmIEkgYXNrIGZvciBzb21l IHBhcnRpY3VsYXIgbWljcm9zY29waWNhbGx5IGRldGFpbGVkIGNvbmZpZ3VyYXRpb24gKGEgImhv dyIpLCBpdCdzIGJlY2F1c2UgSSBjYXJlLCBmb3Igc29tZSByZWFzb24sIGFib3V0IHRoYXQgbGV2 ZWwgb2YgZGV0YWlsLiBJdCBpcyBpbiBmYWN0IHBhcnQgb2YgbXkgaW50ZW50Lg0KPj4NCj4+IElu IG15IElUIGV4YW1wbGUsIEkgYXJndWUgdGhhdCBpbnRlbnQgbmVlZCBub3QgYmUgaW5kZXBlbmRl bnQgb2YgcHJvdG9jb2xzIGFuZCBwb3J0cywgYW5kIHRoYXQgaXQgbmVlZCBub3QgYmUgcG9ydGFi bGUuIFlvdXIgcmVzcG9uc2UgYWJvdXQgY29udGV4dCBhcHBlYXJzIHRvIGFncmVlLg0KPj4NCj4+ IFNvIGFzIGJlc3QgSSBjYW4gdGVsbCwgd2UgY2FuIHNheSBwcmVjaXNlbHkgd2hhdCBhbiBpbnRl bnQgaXMsIGFuZCB3ZSBjYW4ndCBzYXkgd2hhdCBhbiBpbnRlbnQgaXMgbm90LiBJZiBpbnRlbnQg aXMganVzdCB0aGUgbGF0ZXN0IGJ1enp3b3JkLCB3aGljaCBpdCBjZXJ0YWlubHkgYXBwZWFycyB0 byBiZSwgY2FuIHdlIGp1c3Qgc2F5IHNvIGFuZCBsZWF2ZSBpdCB0byB0aGUgbWFya2V0aW5nIHBl b3BsZT8NCj4+DQo+PiBEYXZlDQo+Pg0KPj4gRnJvbTogTGlmZW5na2FpIChGZW5na2FpKSBbbWFp bHRvOmxpZmVuZ2thaUBodWF3ZWkuY29tXQ0KPj4gU2VudDogVHVlc2RheSwgSnVuZSAwMiwgMjAx NSAxMjo0NyBBTQ0KPj4gVG86IERhdmUgSG9vZDsgU3VzYW4gSGFyZXM7IHNkbkBpcnRmLm9yZw0K Pj4gQ2M6IFpob3V0aWFucmFuOyBYaWF5aW5iZW47IGlibmVtb0BpZXRmLm9yZw0KPj4gU3ViamVj dDogUkU6IFtTZG5dIERlZmluaW5nIGEgQ29tbW9uIE1vZGVsIGZvciBpbnRlbnQNCj4+DQo+PiBI aSBEYXZlIGFuZCBhbGwsDQo+Pg0KPj4gVGhhbmtzIGZvciBwcm9wb3NpbmcgdGhlIHR3byB2YWx1 YWJsZSBpbnRlbnQgdXNlIGNhc2VzLg0KPj4NCj4+IEZvciB0aGUgdXNlIGNhc2UgMiwgSSBhZ3Jl ZSB0aGF0IHRoZSBJVCBlbXBsb3llZSBuZWVkcyB0byBpbmNsdWRlIHRoZSBkZXRhaWxzIG9mIHBv cnRzL3Byb3RvY29scyBpbnRvIGhpcy9oZXIgaW50ZW50IGRlc2NyaXB0aW9ucywgYnV0IHRob3Nl IG1heSBub3QgYmUgaW4gdGhlIGludGVudCBjb250ZXh0IHNjb3BlIG9mIGEgbm9uLUlUIGVtcGxv eWVlLiBIYXZlIGEgZnVydGhlciBjb25zaWRlcmF0aW9uIHdpdGggdGhpcywgZGlmZmVyZW50IHVz ZXJzIG9mIHRoZSBuZXR3b3JrIGhhdmUgdGhlaXIgb3duIGludGVudCBpbiBhIHNwZWNpZmljIGRv bWFpbi4gVGhlbiB0aGUgcm9sZXMvYWN0b3JzIG9mIG5ldHdvcmsgdXNlcnMsIHN1Y2ggYXMgZW5k IHVzZXJzLCBhcHBsaWNhdGlvbiBkZXZlbG9wZXJzLCB0ZW5hbnQgSVQvbmV0d29yayBhZG1pbmlz dHJhdG9ycywgb3BlcmF0b3IgbmV0d29yayBhZG1pbmlzdHJhdG9ycywgYXJlIHZhbHVhYmxlIHRv IGJlIGlkZW50aWZpZWQgYW5kIGRpc3Rpbmd1aXNoZWQsIHRodXMgZml0dGluZyB0aGUgaW50ZW50 IHJlcXVpcmVtZW50cyBvZiB0aGUgbmV0d29yayB1c2VycyB3aXRoIGRpZmZlcmVudCByb2xlcy4N Cj4+DQo+PiBBbnkgdGhvdWdodHMgYWJvdXQgdGhpcyBjb25zaWRlcmF0aW9uPw0KPj4NCj4+DQo+ PiBCZXN0IFJlZ2FyZHMsDQo+PiBGZW5na2FpDQo+Pg0KPj4gRnJvbTogc2RuIFttYWlsdG86c2Ru LWJvdW5jZXNAaXJ0Zi5vcmddIE9uIEJlaGFsZiBPZiBEYXZlIEhvb2QNCj4+IFNlbnQ6IFR1ZXNk YXksIEp1bmUgMDIsIDIwMTUgMTozOCBBTQ0KPj4gVG86IFN1c2FuIEhhcmVzOyBzZG5AaXJ0Zi5v cmcNCj4+IENjOiBaaG91dGlhbnJhbjsgWGlheWluYmVuOyBpYm5lbW9AaWV0Zi5vcmcNCj4+IFN1 YmplY3Q6IFJlOiBbU2RuXSBEZWZpbmluZyBhIENvbW1vbiBNb2RlbCBmb3IgaW50ZW50DQo+Pg0K Pj4gQW4gZXhjZXJwdCBmcm9tIGFuIGVtYWlsIEkgc2VudCBvbiB0aGUgT05GIE5CSSBsaXN0LCB3 aGljaCBtYXkgY29udGFpbiBzb21lIHVzZWZ1bCB0aG91Z2h0czoNCj4+DQo+PiBJIGhhdmUgYWx3 YXlzIGhhZCB0cm91YmxlIHVuZGVyc3RhbmRpbmcgd2hhdCBhbiBpbnRlbnQgcmVhbGx5IGlzLCBz byBJIGFtIGxvb2tpbmcgZm9yd2FyZCB0byBtYWtpbmcgdGhlIGNvbmNlcHQgbW9yZSBwcmVjaXNl Lg0KPj4NCj4+IFdoZW4gSSBjbGljayBhIGxpbmsgb24gYSB3ZWIgcGFnZSwgSSBleHByZXNzIGFu IGludGVudCB0byBpbnZva2Ugd2hhdGV2ZXIgdGhhdCBsaW5rIG9mZmVycy4gQ29tcGxldGVseSBi ZWxvdyB0aGUgc3VyZmFjZSBpcyBhIGxheWVyIHN0YWNrLCBvbi1kZW1hbmQgc2Vzc2lvbiBlc3Rh Ymxpc2htZW50LCBETlMgbG9vay11cHMsIHNlcnZlciBsb2FkIGJhbGFuY2VycywgYW5kIGFueSBu dW1iZXIgb2Ygb3RoZXIgdGVjaG5vbG9naWNhbCBmZWF0dXJlcyB0aGF0IGFyZSBvZiBubyBpbnRl cmVzdCB0byBtZS4gV2h5IG5vdCB1c2UgdGhhdCBhcyBhbiBleGFtcGxlIG9mIGludGVudD8NCj4+ DQo+PiBCZXR0ZXIgeWV0LCB3ZSB0YWxrIGFib3V0IG5lZ290aWF0aW9uIGFuZCBzZWxlY3Rpb24u IFN1cHBvc2UgSSB3YW50IHRvIGJ1eSBhIHdpZGdldC4gSSBwcm9iYWJseSBhbHJlYWR5IGhhdmUg c29tZSBpZGVhIHdoZXRoZXIgSSB3YW50IHRvIGdvIHRvIEFtYXpvbiBvciBFQmF5IG9yIHNvbWV3 aGVyZSBlbHNlLiBTdXBwb3NlIGl0J3MgQW1hem9uLiBJIHNlYXJjaCBBbWF6b24ncyBjYXRhbG9n IGFuZCByZWNlaXZlIGFuIG9mZmVyIG9mIHNldmVyYWwgd2lkZ2V0cywgc29tZSBuZXcsIHNvbWUg dXNlZCwgc29tZSB3aXRoIGEgY2hvaWNlIG9mIGNvbG91ciBvciBvdGhlciBwZXJ0aW5lbnQgZmVh dHVyZXMuIElmIEkgc2VlIG5vdGhpbmcgSSBsaWtlLCBJIG1heSBvcGVuIGEgbmV3IGJyb3dzZXIg d2luZG93IGFuZCBjaGVjayBvdXQgQmVzdCBCdXkgb3IgRUJheSAobG90cyBtb3JlIGhpZGRlbiB0 ZWNobm9sb2d5IHRvIG1ha2UgdGhhdCBoYXBwZW4hKS4gTWF5YmUgSSBjb21lIGJhY2sgdG8gdGhl IEFtYXpvbiBwYWdlLCBoYXZpbmcgZm91bmQgbm90aGluZyBJIGxpa2VkIGJldHRlciBzb21ld2hl cmUgZWxzZS4gTm93IEkgYWNjZXB0IG9uZSBvZiB0aGUgb2ZmZXJlZCB3aWRnZXRzIGFuZCBnbyB0 aHJvdWdoIHRoZSBjaGVja291dCBwcm9jZXNzLg0KPj4NCj4+IERvIHdlIGFncmVlIHRoYXQgdGhp cyBpcyBhIGZhaXJseSBwdXJlIGV4cHJlc3Npb24gb2YgaW50ZW50IGFzIA0KPj4gY29uY2VwdHVh bGl6ZWQgaW4gdGhlIHBhcGVyPyAoSWYgbm90LCBsZXQncyB0YWxrIGFib3V0IG1ha2luZyBhIFNr eXBlIA0KPj4gY2FsbC4pDQo+Pg0KPj4gT2ssIHRoYXQncyBteSBpbnRlbnQgYXMgYW4gaW50ZXJu ZXQgdXNlci4gTGV0J3MgYXNzdW1lIHRoZSBuZXR3b3JrIGlzIGFsbCBTRE4gb2Ygb25lIGtpbmQg b3IgYW5vdGhlci4gSSBpbnZva2UgbXkgaW50ZW50IHRocm91Z2ggYSBHVUkgb250byBzb2Z0d2Fy ZSBsb2NhbCB0byBteSBQQywgYnV0IEkgZG9uJ3QgdGhpbmsgd2UgY2FuIGNhbGwgdGhlIFBDIGFu IFNETiBjb250cm9sbGVyLiBJdCdzIG1vcmUgYW4gYWN0aXZlIG1lZGlhdG9yLCBhIGNsaWVudCB0 byBhbiBTRE4uIEFzIGZhciBhcyB0aGUgbmV0d29yayBpcyBjb25jZXJuZWQsIHRoZSBjbGllbnQg bWFrZXMgRE5TIHF1ZXJpZXMgYW5kIHN3YXBzIG9wYXF1ZSBUQ1AgcGFja2V0cyBvdmVyIGEgZm9y d2FyZGluZyBwYXRoIHRoYXQgbWF5IGFscmVhZHkgZXhpc3QsIG9yIG1heSBuZWVkIHRvIGJlIGxl YXJuZWQgYW5kIHNldCB1cCBvbiBkZW1hbmQuIFRoaXMgaXMgYWJvdXQgcmlnaHQsIGJlY2F1c2Ug dGhlIHNlc3Npb24gY29udGVudCBtYXkgd2VsbCBiZSBlbmNyeXB0ZWQgZW5kIHRvIGVuZCwgYW5k IHJpZ2h0bHkuDQo+Pg0KPj4gVG8gdGhlIFNETiBjb250cm9sbGVyLCBteSBpbnRlbnQgaXMgc2F0 aXNmaWVkIGJ5IGRpcmVjdGluZyBETlMgcXVlcmllcyB0byBhIGtub3duIEROUyBzZXJ2ZXIgc29t ZXdoZXJlLCBhbmQgZW5zdXJpbmcgSVAgY29ubmVjdGl2aXR5IGZvciB0aGUgc3Vic2VxdWVudCBz ZXNzaW9uLiBIbW1tLiB3aGF0IGhhcHBlbmVkIHRvIG91ciBpbnRlbnQtYmFzZWQgTkJJPyBUaGUg U0ROIG9mZmVyZWQgbXkgUEMgYSBwYWNrZXQgaW50ZXJmYWNlIHdpdGggdGhlIHByb3BlcnRpZXMg b2Yga25vd2luZyBob3cgdG8gcmVjb2duaXplIGFuZCByb3V0ZSBETlMgcXVlcmllcyBzcGVjaWFs bHksIGFuZCBnZW5lcmFsIElQIGNvbm5lY3Rpdml0eS4gTXkgUEMgYWNjZXB0ZWQgdGhlIHNlcnZp Y2Ugb2ZmZXIgaW1wbGljaXRseSBieSBvZmZlcmluZyB0cmFmZmljIHRvIHRoZSBkYXRhLXBsYW5l IGludGVyZmFjZS4gVGhlIG5ldHdvcmsgY291bGQgYmUgcGVyZm9ybWluZyBhc3NvY2lhdGVkIGF1 eGlsaWFyeSBzZXJ2aWNlcyBzdWNoIGFzIHVzYWdlLWJhc2VkIGJpbGxpbmcgKHRoaW5rIHdpcmVs ZXNzIHJvYW1pbmcpLCBzbyBpdCdzIG1vcmUgdGhhbiBqdXN0IGEgZHVtYiBwaXBlLg0KPj4NCj4+ IElmIHRoaXMgaXMgbm90IGEgbGVnaXRpbWF0ZSBleGFtcGxlIG9mIGludGVudCwgaXQgd291bGQg YmUgZ29vZCB0byB3cml0ZSB0aGUgd2hpdGUgcGFwZXIgaW4gc3VjaCBhIHdheSB0aGF0IGNsZWFy bHkgZXhjbHVkZXMgc3VjaCBjYXNlcy4NCj4+DQo+PiBVc2UgY2FzZSAyOiBzdXBwb3NlIEkgYW0g YSBjb3Jwb3JhdGUgSVQgZW1wbG95ZWUsIGFuZCBzdXBwb3NlIHRoYXQgbXkgDQo+PiBpbnRlbnQg aXMgdG8gaGF2ZSBhbiBFLUxpbmUgYmV0d2VlbiB0d28gb2YgbXkgY2FtcGkuIEkgbmVjZXNzYXJp bHkgDQo+PiBjYXJlIGFib3V0IHBvcnRzIGFuZCBwcm90b2NvbHM7IHRhbGsgYWJvdXQgaW50ZW50 IGJlaW5nIHBvcnRhYmxlIGFuZCANCj4+IHByb3RvY29sIGluZGVwZW5kZW50IGNvbnRpbnVlcyB0 byBjb25mdXNlIG1lIGNvbXBsZXRlbHkuIEhvdyBjYW4gSSANCj4+IG9yZGVyIGFuIEUtbGluZSB3 aXRob3V0IGNhcmluZyBhYm91dCBzdWNoIGRldGFpbHM/IFtOb3IgaXMgdGhpcyANCj4+IGludGVu dCBwb3J0YWJsZS5dDQo+Pg0KPj4gT2J2aW91c2x5LCBhbiBTRE4gY29udHJvbGxlciBpcyBnb2lu ZyB0byBleHBvc2Ugd2hhdGV2ZXIgYWN0aW9ucyBhbmQgZWxlbWVudHMgb2YgaW5mb3JtYXRpb24g YXJlIGdlcm1hbmUgdG8gdGhlIHNlcnZpY2UgaXQgb2ZmZXJzLCBhbmQgaWYgcG9ydHMgYW5kIHBy b3RvY29scyBhcmUgZ2VybWFuZSB0byB0aGUgc2VydmljZSwgc28gYmUgaXQuDQo+Pg0KPj4gVGhl IFNETiBhcmNoaXRlY3R1cmUsIGJlaW5nIHJlY3Vyc2l2ZSwgbW9kZWxzIHRoZSBub3J0aCBzaWRl IG9mIGFueSBjb250cm9sbGVyIGFzIGV4cG9zaW5nIGFuIGluc3RhbmNlIG9mIGFuIGluZm9ybWF0 aW9uIG1vZGVsLCBjdXN0b21pemVkIGZvciB0aGUgaW50ZW5kZWQgY2xpZW50L2N1c3RvbWVyL2Fw cC91c2VyLiBUaGF0IGJlaW5nIHRoZSBjYXNlLCBob3cgZG8gd2UgZGlzdGluZ3Vpc2ggYW4gTkJJ IEFQSSB0aGF0IGNvbnZleXMgaW50ZW50IChzZXJ2aWNlOiBzYW1lIHRoaW5nPykgZnJvbSBvbmUg dGhhdCBkb2VzIG5vdD8NCj4+DQo+PiBJIGhhdmUgcmVjZW50bHkgY29tZSB0byB0aGUgdmlldyB0 aGF0IGdyYW51bGFyaXR5IGlzIHRoZSBjcml0ZXJpb24gYnkgd2hpY2ggYW4gaW50ZW50IG9yIHNl cnZpY2UgaW52b2NhdGlvbiBpcyBkaXN0aW5ndWlzaGVkLiBDb2xsb3F1aWFsbHkgc3BlYWtpbmcs IGEgc2VydmljZSBpbnZvY2F0aW9uIGlzIGEgc2luZ2xlIGludm9jYXRpb24gYWNyb3NzIHRoZSBB UEk6IGdpdmUgbWUgRS1MaW5lLiBOb3cgb2YgY291cnNlIHRoaXMgdHVybnMgaW50byBjb25zdHJh aW50IG5lZ290aWF0aW9uLCBvZmZlciBhbmQgYWNjZXB0YW5jZSwgYnV0IHdoYXQgaGFwcGVucyBh Y3Jvc3MgdGhlIEFQSSBpcyBlZmZlY3RpdmVseSBvbmUgdHJhbnNhY3Rpb24uIEluIGNvbnRyYXN0 LCB3aGF0IHdlIG1pZ2h0IGFncmVlIGlzICpub3QqIGFuIGludGVudCBvciBhIHNlcnZpY2UgaXMg dGhlIG1hbmlwdWxhdGlvbiBvZiBhIGdyYW51bGFyIGluZm9ybWF0aW9uIG1vZGVsLCB0aGUgZXhw bGljaXQgdmlzaWJpbGl0eSBvZiBtdWx0aXBsZSBvYmplY3RzLCBob3cgdGhleSBhcmUgaW50ZXJy ZWxhdGVkLCB0aGVpciBhdHRyaWJ1dGVzLCBhbmQgdGhlIGxpa2UuDQo+Pg0KPj4gLiAgICAgICAg IE5ldHdvcmsgYXMgYSBzaW5nbGUgbHVtcCB2cyBzb21lIG5vbi10cml2aWFsIHRvcG9sb2d5Lg0K Pj4NCj4+IC4gICAgICAgICBDaGF1ZmZldXIgdnMgZHJpdmluZyBhIGNhci4gTGVnaXRpbWF0ZSBy ZWFzb25zIHRvIGNob29zZSBvbmUgb3B0aW9uIG9yIHRoZSBvdGhlciwgYnV0IHRoZSBsZXZlbCBv ZiBncmFudWxhcml0eSBpcyBxdWl0ZSBkaWZmZXJlbnQuIFNoYWxsIHdlIGFncmVlIHRoYXQgZHJp dmluZyBpcyB0b28gZ3JhbnVsYXIgdG8gYmUgY29uc2lkZXJlZCBpbnRlbnQ/DQo+Pg0KPj4gVGhp cyBpZGVhIG9mIGdyYW51bGFyaXR5IGFuZCBkZXRhaWxlZCBvcGVyYXRpb25zIG9uIHRoZSBjb21w b25lbnRzICh3aGljaCBvZiBjb3Vyc2UgbWF5IGJlIGNvbXBsZXggZW50aXRpZXMgdGhlbXNlbHZl cywgdmlydHVhbGl6ZWQgaW50byBzaW1wbGUtYXBwZWFyaW5nIGx1bXBzKSBzZWVtcyB0byBtZSB0 byBjYXB0dXJlIHRoZSBlc3NlbmNlIG9mIHdoYXQgcGVvcGxlIGFyZSB0YWxraW5nIGFib3V0IHdo ZW4gdGhleSBzYXkgaW50ZW50IG9yIHNlcnZpY2UuIEkgYW0gbm90IGNvbWZvcnRhYmxlIHdpdGgg dGhlIHdheSBJIGFtIGV4cHJlc3NpbmcgaXQsIHNvIGlmIHRoaXMgaXMgYSBzdGVwIGluIGEgcHJv ZHVjdGl2ZSBkaXJlY3Rpb24sIG9yIGV2ZW4gaWYgaXQncyBub3QsIEkgd2VsY29tZSBzdWdnZXN0 aW9ucyB0byBjbGFyaWZ5IHRoZSBjb25jZXB0Lg0KPj4NCj4+IERhdmUNCj4+DQo+PiBGcm9tOiBz ZG4gW21haWx0bzpzZG4tYm91bmNlc0BpcnRmLm9yZ10gT24gQmVoYWxmIE9mIFN1c2FuIEhhcmVz DQo+PiBTZW50OiBTYXR1cmRheSwgTWF5IDMwLCAyMDE1IDE6MDIgUE0NCj4+IFRvOiBzZG5AaXJ0 Zi5vcmcNCj4+IENjOiAnWmhvdXRpYW5yYW4nOyAnWGlheWluYmVuJzsgaWJuZW1vQGlldGYub3Jn DQo+PiBTdWJqZWN0OiBbU2RuXSBEZWZpbmluZyBhIENvbW1vbiBNb2RlbCBmb3IgaW50ZW50DQo+ Pg0KPj4gT24gdGhpcyBtYWlsIGxpc3QsIHRoZXJlIGhhcyBiZWVuIGEgZGlzY3Vzc2lvbiBvZiB0 d28gdHlwZXMgb2YgaW5mb3JtYXRpb24gZm9yIEludGVudCBhbmQgTmVtbzogKGh0dHA6Ly93d3cu aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zZG4vY3VycmVudC9tc2cwMDY0Ni5odG1sKSA6DQo+ Pg0KPj4gMSkgICAgICBXaGF0IGluZm9ybWF0aW9uIGlzIG5lZWRlZCB0byByZXByZXNlbnQgYSBz ZXJ2aWNlIHJlcXVlc3QsDQo+PiAyKSAgICAgIEhvdyB0byByZXByZXNlbnQgYW5kIHRyYW5zcG9y dCB0aGUgaW5mb3JtYXRpb24gZm9yIGEgcmVxdWVzdC4NCj4+DQo+PiBJbiBvcmRlciB0byBkZWZp bmUgd2hhdCBpbmZvcm1hdGlvbiBpcyBuZWVkZWQgdG8gcmVwcmVzZW50IGEgMSkgc2VydmljZSBy ZXF1ZXN0IHRoYXQgc2lnbmFscyBJbnRlbnQgZnJvbSBhbiBhcHBsaWNhdGlvbiB0byBhIGNvbnRy b2xsZXIsIGl0IGlzIGltcG9ydGFudCB0byBkZWZpbmUgSW50ZW50LCBhbmQgcHJvdmlkZSBhIGNs ZWFyIG1vZGVsIG9mIEludGVudC4gIEFsc28sIGluIGRlc2NyaWJpbmcgcmVhbCB1c2UtY2FzZXMg aXQgaXMgaW1wb3J0YW50IHRoYXQgb25lIHVzZXMgdGhlIHNhbWUgZGVmaW5pdGlvbiBhbmQgbW9k ZWwgZm9yIEludGVudCBpbiBlYWNoIHVzZSBjYXNlLg0KPj4NCj4+IEluIHRoZSBjdXJyZW50IGZv cnVtcyBleGFtaW5pbmcgSW50ZW50IChPREwgTklDLCBPREwgTmVtbywgT0YgTkJJIGFuZCBLZXlz dG9uZSwgT1BORlYgTW92aWUsIE9wZW5TdGFjaykgdGhlcmUgaXMgYSByZWFsaXphdGlvbiB0aGF0 IEludGVudCBvY2N1cnMgYXQgbXVsdGlwbGUgbGF5ZXJzLiAgVGhlIGF1dGhvcnMgb2YgZHJhZnQt eGlhLWlibmVtby1pY2ltIGhhdmUgY3JlYXRlZCBhIGRlZmluaXRpb24gZm9yIGludGVudCBhbmQg YSB1bmlmaWVkIG1vZGVsIGZvciBkZWZpbmluZyBpbnRlbnQgd2hpY2ggY2FuIGhhbmRsZSAxIG9y IG11bHRpcGxlIGxheWVycy4gVGhlIG1vZGVsIHN1Z2dlc3QgdGhhdDoNCj4+IDEpICAgICAgQSB1 c2VyIGhhcyBhIGludGVudCB0aGF0IGlzIGV4cHJlc3NlZCBpbiBhIGNvbnRleHQuDQo+PiAyKSAg ICAgIEludGVudCAodXN1YWxseSkgaW52b2x2ZXMgYW4gb2JqZWN0IHdpdGggYSByZXN1bHQsIGFu ZCBvcHRpb25hbGx5IGluY2x1ZGVzIG9wZXJhdGlvbnMgdG93YXJkIHRoYXQgcmVzdWx0Lg0KPj4g MykgICAgICBPcGVyYXRpb25zIGNvbmRpdGlvbnMgcGVyZm9ybSBhY3Rpb25zIHdpdGhpbi9tb2Rp ZmllZCBieSBjb25zdHJhaW50cy4NCj4+DQo+PiBXZSBiZWxpZXZlIHRoaXMgZGVmaW5lcyBjbGVh cmx5IHdoYXQgb3RoZXJzIGFyZSBjYWxsaW5nICJwdXJlIGludGVudCIgKG9iamVjdHMgKyByZXN1 bHRzKSB2ZXJzdXMgImNvbnN0cmFpbmVkIGludGVudCIgKG9iamVjdHMgKyBvcGVyYXRpb25zICsg Y29uc3RyYWludHMpLiAgIFRoZSBkcmFmdCBjYW4gYmUgZm91bmQgYXQ6ICAgaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQteGlhLWlibmVtby1pY2ltLyAuICAgVGhlIGF1dGhv cnMgYXJlIGxvb2tpbmcgZm9yIGZlZWRiYWNrIG9uIHRoZSBjb25jZXB0cyBpbiB0aGUgZHJhZnQu DQo+Pg0KPj4gU3VlIEhhcmVzDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+IHNkbiBtYWlsaW5nIGxpc3QNCj4+IHNkbkBpcnRmLm9yZw0K Pj4gaHR0cHM6Ly93d3cuaXJ0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZG4NCj4+DQo+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gSWJuZW1vIG1h aWxpbmcgbGlzdA0KPj4gSWJuZW1vQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2libmVtbw0KPiA+DQoNCg== From nobody Fri Jun 5 06:17:58 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D951B1B2F50 for ; Fri, 5 Jun 2015 06:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.078 X-Spam-Level: ** X-Spam-Status: No, score=2.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDZJdtvyvgTg for ; Fri, 5 Jun 2015 06:17:53 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2EB71B2F4F for ; Fri, 5 Jun 2015 06:17:40 -0700 (PDT) Received: from 172.24.2.119 (EHLO nkgeml406-hub.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CMP67597; Fri, 05 Jun 2015 21:17:27 +0800 (CST) Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.7]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Fri, 5 Jun 2015 21:17:19 +0800 From: Xiayinben To: "Bert Wijnen (IETF)" , Zhoutianran , STUART VENTERS , "sdn@irtf.org" Thread-Topic: [Ibnemo] [Sdn] Defining a Common Model for intent Thread-Index: AQHQnJG6C7g/F5gbTkG+uAbOWTIbsZ2YUVeAgABezYCAACyygIABJ5gAgAA5CQCAAYaqAIAANIyAgAHmgMA= Date: Fri, 5 Jun 2015 13:17:18 +0000 Message-ID: <5FD31D8EDBF4EC468B36D86F04FDB2E873829CE4@nkgeml507-mbs.china.huawei.com> References: <00f301d09b13$79cc2410$6d646c30$@ndzh.com> <8D15A2BAF93E9C49AB037A0647E5FA643F8490D8@eusaamb105.ericsson.se> <865C20BAAE8BBD4C89E7D6FE694F6B3B2D3CA540@nkgeml505-mbs.china.huawei.com> <8D15A2BAF93E9C49AB037A0647E5FA643F84AAA2@eusaamb105.ericsson.se> <1220E2C537595D439C5D026E83751866C42AC2FF@ex-mb3.corp.adtran.com> , <556EFC42.9040208@bwijnen.net> <5570700D.7000604@bwijnen.net> In-Reply-To: <5570700D.7000604@bwijnen.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.17.47] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "ibnemo@ietf.org" Subject: [Sdn] =?gb2312?b?tPC4tDogW0libmVtb10gIERlZmluaW5nIGEgQ29tbW9uIE1v?= =?gb2312?b?ZGVsIGZvciBpbnRlbnQ=?= X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 13:17:57 -0000 QmVydCwNCg0KVGhhdCBpcyBleGFjdGx5IHNhbWUgYXMgd2hhdCBJIHVuZGVyc3RhbmQuDQpJIGhv cGUgd2UgY291bGQgZ2l2ZSBhIGNvbW1vbiBpbnRlbnQgaW5mb3JtYXRpb24gbW9kZWwgZm9yIGdl bmVyYWwgaW50ZW50IGNvbXBvbmVudHMgYW5kIHRoZWlyIHJlbGF0aW9uc2hpcC4NClRoZW4gd2Ug Y291bGQgZGVmaW5lIGEgc2V0IG9mIGludGVudCBjb250ZW50IGJhc2VkIG9uIHNvbWUgcm9sZXMg YXMgeW91IG1lbnRpb25lZCBpbiBsYXN0IG1haWwuDQoNCllpbmJlbg0KDQotLS0tLdPKvP7Urbz+ LS0tLS0NCreivP7IyzogSWJuZW1vIFttYWlsdG86aWJuZW1vLWJvdW5jZXNAaWV0Zi5vcmddILT6 se0gQmVydCBXaWpuZW4gKElFVEYpDQq3osvNyrG85DogMjAxNcTqNtTCNMjVIDIzOjM1DQrK1bz+ yMs6IFpob3V0aWFucmFuOyBTVFVBUlQgVkVOVEVSUzsgc2RuQGlydGYub3JnDQqzrcvNOiBpYm5l bW9AaWV0Zi5vcmcNCtb3zOI6IFJlOiBbSWJuZW1vXSBbU2RuXSBEZWZpbmluZyBhIENvbW1vbiBN b2RlbCBmb3IgaW50ZW50DQoNCk9uIDA0LzA2LzE1IDE0OjI2LCBaaG91dGlhbnJhbiB3cm90ZToN Cj4gSGkgQmVydCwNCj4NCj4gVGhhbmtzIGZvciB5b3UgY29tbWVudHMuDQo+IEkgYWdyZWUgd2l0 aCB5b3UgdGhhdCB3ZSdkIGJldHRlciBqdXN0IGZvY3VzIG9uIHRoZSB0b3AgbGF5ZXIuDQo+IEJ1 dCBJIGFtIHNvcnJ5LCB3aGF0IGRvIHlvdSBtZWFuIGluIHRoZSBsYXN0IHNlbnRlbmNlPw0KPiAi QSByb2xlIC1iYXNlZCBpbnRlbnQgbW9kZWw/IEkgZ3Vlc3MgaXQgd291bGQganVzdCBib2lsIGRv d24gaW4gZGlmZmVyZW50IHR5cGVzIG9mIGludGVudCB0aGF0IGZpdCB3aXRoIHRoZSBzcGVjaWZp YyByb2xlLCByaWdodD8iDQo+IENvdWxkIHlvdSBnaXZlIG1vcmUgaW5mb3JtYXRpb24gb24gdGhp cz8NCg0KU29ycnkgZm9yIG5vdCBiZWluZyBjbGVhciwNCg0KbXkgdGhpbmtpbmcgaGVyZSBpcyB0 aGF0DQotIGludGVudCBtb2RlbCBpcyBiYXNpY2FsbHkgdGhlIHNhbWUgZm9yIGFueW9uZS4NCi0g YnV0IGJhc2VkIG9uIHlvdXIgcm9sZSwgeW91IGV4cHJlc3MgeW91ciBpbnRlbnQgd2l0aCBkaWZm ZXJlbnQgKHJvbGUgc3BlY2lmaWMpDQogICAgc3RhdGVtZW50cy4gVGhhdCBwb3NzaWJseSBtZWFu cyB5b3UgdXNlIHNpbWlsYXIgbGFuZ3VhZ2UgKElETCkgYnV0IHlvdSB1c2UNCiAgICBkaWZmZXJl bnQgb2JqZWN0cyAoZGF0YSkgdG8gZXhwcmVzcyBpdA0KDQpTbyBhIGN1c3RvbWVyL2VuZC11c2Vy IHNheXMNCiAgIEkgd2FudCBhIGxpbmsgYmV0d2VlbiBsb2NhdGlvbiBBIGFuZCBCLCBpLmUuIG15 IGludGVudCBpcyB0byB1c2UgYSBjb25uZWN0aW9uIGJldHdlZW4gQSAmIEINCiAgIGFuZCBJIHdh bnQgMUdCIHdpdGggbG93IGRlbGF5DQpUaGUgc2VydmljZSBwcm92aWRlciB3aG8gbmVlZHMgdG8g aW1wbGVtZW50IHRoaXMgc2F5cyB0aGluZ3MgbGlrZQ0KICAgQ3JlYXRlICBhIHBoeXNpY2FsIGxp bmsgYmV0d2VlbiBBJkINCiAgIG9yIGNyZWF0ZSBhIGxvZ2ljYWwgbGluayBiZXR3ZWVuIEEmQiB3 aXRoIGd1YXJhbnRlZWQgMUdCIGNhcGFjaXR5DQoNClNvIHRoZSBjdXN0b21lci9lbmQtdXNlciBk b2VzIG5vdCBjYXJlIGFib3V0IHBoeXNpY2FsIG9yIGxvZ2ljYWwgb3Igd2hhdGV2ZXIuDQpNYXli ZSBoZS9zaGUgZG9lcyBub3QgZXZlbiB3YW50IHRvIGtub3cuDQoNCkJ1dCB0aGUgc2VydmljZSBw cm92aWRlciBvZiBjb3Vyc2UgbmVlZHMgdG8gZXhwcmVzcyBpbnRlbnQgYWJvdXQgcGh5c2ljYWwg b3IgbG9naWNhbA0KDQpEb2VzIHRoYXQgaGVscD8NCg0KQmVydA0KDQo+IEJlc3QsDQo+IFRlcmVu Y2UNCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiC3orz+ yMs6IEJlcnQgV2lqbmVuIChJRVRGKSBbYndpZXRmQGJ3aWpuZW4ubmV0XQ0KPiC3osvNyrG85Dog MjAxNcTqNtTCM8jVIDIxOjA4DQo+IMrVvP7IyzogWmhvdXRpYW5yYW47IFNUVUFSVCBWRU5URVJT OyBzZG5AaXJ0Zi5vcmcNCj4gs63LzTogaWJuZW1vQGlldGYub3JnDQo+INb3zOI6IFJlOiBbSWJu ZW1vXSBbU2RuXSBEZWZpbmluZyBhIENvbW1vbiBNb2RlbCBmb3IgaW50ZW50DQo+DQo+IEhpIGFs bCwNCj4NCj4gSSBsaWtlIHRoZSBpZGVhIG9mIChhdCBsZWFzdCBmb3Igbm93KSBzdGljayB0byB0 aGUgcHJvYmxlbSBvZiAiaW50ZW50IiBmb3Igb25lIGxheWVyICh0aGUgdG9wIGxheWVyKS4NCj4g TGV0IHVzIG5vdCBib2lsIHRoZSBvY2VhbiBhbmQgdHJ5IHRvIGRvIGV2ZXJ5dGhpbmcgdGhhdCBj b21lcyB1cC4gSWYgDQo+IHdlIGFyZSBzdWNjZXNzZnVsIGluIGRvaW5nIGEgbW9kZWwgZm9yIElC TkVNTyBmb3IgdGhlIHRvcCBsYXllciwgd2UgY2FuIHRoZW4gc2VlIGlmIHdlIHdhbnQgdG8gZ28g YXQgbW9yZSBsYXllcnMuDQo+DQo+IEEgcm9sZSAtYmFzZWQgaW50ZW50IG1vZGVsPyBJIGd1ZXNz IGl0IHdvdWxkIGp1c3QgYm9pbCBkb3duIGluIA0KPiBkaWZmZXJlbnQgdHlwZXMgb2YgaW50ZW50 IHRoYXQgZml0IHdpdGggdGhlIHNwZWNpZmljIHJvbGUsIHJpZ2h0Pw0KPg0KPiBCZXJ0DQo+DQo+ DQo+IE9uIDAzLzA2LzE1IDExOjQ0LCBaaG91dGlhbnJhbiB3cm90ZToNCj4+IEhpIFN0dWFydCwN Cj4+DQo+PiBUaGFua3MgZm9yIHRoaXMgZGVlcCB0aGlua2luZyB3aXRoIGEgc2V0IG9mIGV4YW1w bGVzLiBJdCdzIHJlYWxseSBpbXBvcnRhbnQgdG8gY2xhcmlmeSB0aGlzIGZ1enp5IGludGVudC4N Cj4+IEkgdGhpbmsgYWxsIHRoZSBjb25jZXJuIGFuZCB1bmNlcnRhaW50eSBpcyBiZWNhdXNlIG9m IHRoZSBsYXllcmVkIHRoaW5raW5nLiBXZSB0aGluayBpbnRlbnQgaXMgYSByZWxhdGl2ZWx5IGhp Z2hlciBsZXZlbCBuZXN0ZWQuDQo+PiBXaGF0IGlmIHdlIHRoaW5rIGFib3V0IGludGVudCB3aXRo IGRpZmZlcm5ldCByb2xlcz8gSnVzdCBsaWtlIGEgcmVsYXRpdmUgZGV0YWlsZWQgZGVzY3JpcHRp b24gaW4gbXkgInJvbGUgYmFzZWQgaW50ZW50IiBlbWFpbC4NCj4+IEkgdGhpbmsgdGhlIGVzc2Vu dGlhbCBvZiB0aGUgcm9sZSBiYXNlZCBpbnRlbnQgaXMgdGhhdCB0aGVyZSBpcyBvbmx5IG9uZSBp bnRlbnQgbGF5ZXIgd2hpY2ggaXMgYWx3YXlzIG9uIHRoZSB0b3AuIEludGVudCBpcyBkZWRpY2F0 ZWQgZm9yIGNvcnJlc3BvbmRpbmcgcm9sZXMuIE9uZSByb2xlIHdpbGwgbm90IGNhbGwgb3RoZXIg cm9sZXMgaW50ZXJmYWNlcy4NCj4+IFRoZW4gd2UgY2FuIHRyeSB0byBmaW5kIHdheSB0byBleHBy ZXNzIGludGVudCBmb3IgdmFyaW91cyByb2xlcy4NCj4+DQo+Pg0KPj4gUmVnYXJkcywNCj4+IFRl cmVuY2UNCj4+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogc2RuIFtt YWlsdG86c2RuLWJvdW5jZXNAaXJ0Zi5vcmddIE9uIEJlaGFsZiBPZiBTVFVBUlQgVkVOVEVSUw0K Pj4gU2VudDogV2VkbmVzZGF5LCBKdW5lIDAzLCAyMDE1IDEyOjA2IEFNDQo+PiBUbzogc2RuQGly dGYub3JnDQo+PiBDYzogJ0RhdmUgSG9vZCc7IGlibmVtb0BpZXRmLm9yZzsgTGlmZW5na2FpIChG ZW5na2FpKTsgWmhvdXRpYW5yYW47IA0KPj4gWGlheWluYmVuOyBTdXNhbiBIYXJlcw0KPj4gU3Vi amVjdDogUmU6IFtTZG5dIERlZmluaW5nIGEgQ29tbW9uIE1vZGVsIGZvciBpbnRlbnQNCj4+DQo+ Pg0KPj4NCj4+IEkgaGF2ZSAyIGNlbnRzIHRvIGNvbnRyaWJ1dGUgZm9yIHRoaXMgZnV6enkgaW50 ZW50IHdvcmQgYW5kIHJlc3VsdGluZyBkYXRhIG1vZGVsLg0KPj4gUGVyaGFwcyAnaW50ZW50JyAg aXMganVzdCBhIHJlbGF0aXZlbHkgaGlnaCBsZXZlbCBzZXJ2aWNlIHJlcXVlc3QuDQo+PiBUaGUg cHJvYmxlbSB3aXRoIHRoaXMgZGVmaW5pdGlvbiBpcyB3aGF0IGlzIHRoYXQgJ3JlbGF0aXZlbHkg aGlnaCBsZXZlbCcgYXBwZWFycyB0byBkZXBlbmQgb24geW91ciBwb2ludCBvZiB2aWV3Lg0KPj4N Cj4+IFRvIGhlbHAgdGhpbmsgYWJvdXQgaXQsIGhlcmUncyBhIGxvbmcgY2hhaW4gb2YgY29tbWFu ZCBmb3IgdGhlIHNhbWUgYWN0aW9uLg0KPj4gSXQgaXMgbG9uZyBmb3IgZnVuIGFuZCBzbyB0aGF0 IGFueWJvZHkgY2FuIGZpbmQgcGFydCBvZiBpdCB0aGF0IHRoZXkgcmVjb2duaXplLg0KPj4NCj4+ DQo+PiBDaGFpbiBvZiBjb21tYW5kOg0KPj4NCj4+IEludmVzdG9yIHNheXM6IG1ha2UgbW9uZXkN Cj4+IENFTyBzYXlzOiBtYWtlIHRoZSBuZXR3b3JrIHdvcmsNCj4+IENJTyBzYXlzOiBnaXZlIG1l IGJhbmR3aWR0aHMgYmV0d2VlbiBzaXRlcyBBLCBCLCBhbmQgQyBOZXQgZW5naW5lZXIgDQo+PiBz YXlzOiBJIG5lZWQgdGhlc2UgZXZjJ3MgdG8gdGhlc2UgZW5kcG9pbnRzIFB1cmNoYXNpbmcgYWdl bnQ6IFNheXMgDQo+PiB1c2UgdGhpcyBwcm9kdWN0IGZyb20gdGhpcyB2ZW5kb3IgU2FsZXMgUGVy c29uIHNheXM6IEhlcmUgaXMgdGhlIA0KPj4gcHJpY2UgYW5kIHByaW9yaXR5DQo+PiBQYXJ0aXRp b25lcjogZGl2aWRlcyB0aGUgZW5kIHRvIGVuZCBjaXJjdWl0IGFtb25nIGFkbWluaXN0cmF0aXZl IA0KPj4gZG9tYWlucw0KPj4gUGxhbm5lcjogcGlja3MgdGhlIG5lY2Vzc2FyeSByZXNvdXJjZXMg dG8gdXNlLCBtYWtlcyB0aGUgdHJ1Y2sgcm9sbHMgDQo+PiBoYXBwZW4NCj4+IEFsbG9jYXRvcjog YWxsb2NhdGVzIHRoZSBuZWNlc3NhcnkgYmFuZHdpZHRoDQo+PiBQcm92aXNpb25lcjogZGVjaWRl cyB3aGF0IHByb3Zpc2lvbmluZyBpcyBuZWNlc3NhcnkgaW4gZWFjaCBwYXJ0IG9mIA0KPj4gdGhl IHBhdGgNCj4+IEFkYXB0b3I6IHRhaWxvcnMgdGhlIHByb3Zpc2lvbmluZyB0byBhIHNwZWNpZmlj IGJveA0KPj4gRHJpdmVyOiBwdXNoZXMgdGhlIHByb3Zpc2lvbmluZyBpbnRvIHRoZSBmb3J3YXJk aW5nIHRhYmxlcyBGb3J3YXJkaW5nIA0KPj4gZW5naW5lOiBmb3J3YXJkcyBhY2NvcmRpbmcgdG8g dGhlIHRhYmxlcw0KPj4NCj4+IFRoZSBJbnZlc3RvcidzIHN0YXRlbWVudCBhdCB0aGUgdG9wIGlz IGNsZWFybHkgd2hhdCBhbmQgbm90IGhvdy4NCj4+IFRoZSBmb3J3YXJkaW5nIGVuZ2luZSdzIG9w ZXJhdGlvbnMgaGF2ZSBhIGxvdCBvZiBob3csIGJ1dCBtYXliZSBsaXR0bGUgZ2xvYmFsIHZpZXcg b2Ygd2hhdCB3ZSBhcmUgZG9pbmcgb3ZlcmFsbC4NCj4+DQo+PiBJZiB3ZSBzYXkgdGhhdCB0aGUg dG9wIGlzIGludGVudCBhbmQgdGhlIGJvdHRvbSBpcyBhIGlzIHNlcnZpY2UgcmVxdWVzdCwNCj4+ ICAgICB3aG8ncyB0byBzYXkgd2hlcmUgaW50ZW50IHN0b3BzIGFuZCBzZXJ2aWNlIHJlcXVlc3Rz IHN0YXJ0Pw0KPj4NCj4+IFBlcmhhcHMgICdpbnRlbnQnIG1lYW5zIGEgc2VydmljZSByZXF1ZXN0 IGNvbWluZyBmcm9tIGEgaGlnaGVyIGxheWVyIGZvciByZWZpbmVtZW50Lg0KPj4NCj4+IFRoYXQg c2FpZCwgdGhlIGRhdGEgbW9kZWwgZm9yIGludGVudCBtaWdodC9zaG91bGQgYmUgZGlmZmVyZW50 IGF0IGVhY2ggbGV2ZWwuDQo+PiBTaW5jZSBlYWNoIGxldmVsIGlzIHByb2Nlc3NpbmcgdGhlIHNh bWUgcmVxdWVzdCBhdCBkaWZmZXJlbnQgbGV2ZWxzIG9mIGRldGFpbCwgaXQgbWlnaHQgYmUgc2lt aWxhciBhdCBlYWNoIGxldmVsLg0KPj4gUGVyaGFwcyB0aGUgZGF0YSBtb2RlbCBzdGFydHMgc2lt cGxlIG9uIHRvcCBhbmQgZ2F0aGVycyBtb3JlIGFuZCBtb3JlIGRldGFpbCBhcyBpdCBnZXRzIGxv d2VyID8NCj4+IE1heWJlIGxpa2UgYSB0cmVlIHdpdGggdGhlIHJvb3QgYXQgdGhlIHRvcCBhbmQg bGVhdmVzIGF0IHRoZSBmb3J3YXJkaW5nIGVuZ2luZXMsIGV4Y2VwdCBkaXN0cmlidXRlZC4NCj4+ DQo+PiBQZXJoYXBzIGEgc2ltcGxlIHN0YXJ0aW5nIHBvaW50IG5lYXIgdGhlIHRvcCBpcyBhIGNv bWJpbmF0aW9uIG9mIGVudGl0aWVzLCBlbmRwb2ludHMsIGFuZCBjb25uZWN0aW9ucy4NCj4+DQo+ Pg0KPj4gUmVnYXJkcywNCj4+DQo+PiBTdHVhcnQgVmVudGVycw0KPj4NCj4+DQo+Pg0KPj4NCj4+ DQo+Pg0KPj4NCj4+IEZyb206IHNkbiBbbWFpbHRvOnNkbi1ib3VuY2VzQGlydGYub3JnXSBPbiBC ZWhhbGYgT2YgRGF2ZSBIb29kDQo+PiBTZW50OiBUdWVzZGF5LCBKdW5lIDAyLCAyMDE1IDg6MjYg QU0NCj4+IFRvOiBMaWZlbmdrYWkgKEZlbmdrYWkpOyBTdXNhbiBIYXJlczsgc2RuQGlydGYub3Jn DQo+PiBDYzogWmhvdXRpYW5yYW47IFhpYXlpbmJlbjsgaWJuZW1vQGlldGYub3JnDQo+PiBTdWJq ZWN0OiBSZTogW1Nkbl0gRGVmaW5pbmcgYSBDb21tb24gTW9kZWwgZm9yIGludGVudA0KPj4NCj4+ IEkgYWdyZWUgdGhhdCB0aGUgY29udGV4dCBtYXR0ZXJzLCBGZW5na2FpIChhbmQgU3VzYW4gaW4g ZWFybGllciByZXNwb25zZSkuIFdoYXQgdGhlIEktRCBhcHBlYXJzIHRvIGJlIHNheWluZyBpcyB0 aGF0IGFueSBpbnRlcmFjdGlvbiBhY3Jvc3MgYW4gTkJJIGlzIGludGVudDogb3RoZXJ3aXNlIHRo ZSBhcHAvdGVuYW50L2N1c3RvbWVyIHdvdWxkbid0IGRvIGl0LiBUaGF0J3MgdGhlIHJvb3Qgb2Yg bXkgcXVlc3Rpb24gZnJvbSB0aGUgYmVnaW5uaW5nOiBob3cgd291bGQgd2Uga25vdyB3aGF0IGlz ICpub3QqIGludGVudD8NCj4+DQo+PiBJZiBJIGFzayBmb3Igc29tZSBwYXJ0aWN1bGFyIG1pY3Jv c2NvcGljYWxseSBkZXRhaWxlZCBjb25maWd1cmF0aW9uIChhICJob3ciKSwgaXQncyBiZWNhdXNl IEkgY2FyZSwgZm9yIHNvbWUgcmVhc29uLCBhYm91dCB0aGF0IGxldmVsIG9mIGRldGFpbC4gSXQg aXMgaW4gZmFjdCBwYXJ0IG9mIG15IGludGVudC4NCj4+DQo+PiBJbiBteSBJVCBleGFtcGxlLCBJ IGFyZ3VlIHRoYXQgaW50ZW50IG5lZWQgbm90IGJlIGluZGVwZW5kZW50IG9mIHByb3RvY29scyBh bmQgcG9ydHMsIGFuZCB0aGF0IGl0IG5lZWQgbm90IGJlIHBvcnRhYmxlLiBZb3VyIHJlc3BvbnNl IGFib3V0IGNvbnRleHQgYXBwZWFycyB0byBhZ3JlZS4NCj4+DQo+PiBTbyBhcyBiZXN0IEkgY2Fu IHRlbGwsIHdlIGNhbiBzYXkgcHJlY2lzZWx5IHdoYXQgYW4gaW50ZW50IGlzLCBhbmQgd2UgY2Fu J3Qgc2F5IHdoYXQgYW4gaW50ZW50IGlzIG5vdC4gSWYgaW50ZW50IGlzIGp1c3QgdGhlIGxhdGVz dCBidXp6d29yZCwgd2hpY2ggaXQgY2VydGFpbmx5IGFwcGVhcnMgdG8gYmUsIGNhbiB3ZSBqdXN0 IHNheSBzbyBhbmQgbGVhdmUgaXQgdG8gdGhlIG1hcmtldGluZyBwZW9wbGU/DQo+Pg0KPj4gRGF2 ZQ0KPj4NCj4+IEZyb206IExpZmVuZ2thaSAoRmVuZ2thaSkgW21haWx0bzpsaWZlbmdrYWlAaHVh d2VpLmNvbV0NCj4+IFNlbnQ6IFR1ZXNkYXksIEp1bmUgMDIsIDIwMTUgMTI6NDcgQU0NCj4+IFRv OiBEYXZlIEhvb2Q7IFN1c2FuIEhhcmVzOyBzZG5AaXJ0Zi5vcmcNCj4+IENjOiBaaG91dGlhbnJh bjsgWGlheWluYmVuOyBpYm5lbW9AaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJFOiBbU2RuXSBEZWZp bmluZyBhIENvbW1vbiBNb2RlbCBmb3IgaW50ZW50DQo+Pg0KPj4gSGkgRGF2ZSBhbmQgYWxsLA0K Pj4NCj4+IFRoYW5rcyBmb3IgcHJvcG9zaW5nIHRoZSB0d28gdmFsdWFibGUgaW50ZW50IHVzZSBj YXNlcy4NCj4+DQo+PiBGb3IgdGhlIHVzZSBjYXNlIDIsIEkgYWdyZWUgdGhhdCB0aGUgSVQgZW1w bG95ZWUgbmVlZHMgdG8gaW5jbHVkZSB0aGUgZGV0YWlscyBvZiBwb3J0cy9wcm90b2NvbHMgaW50 byBoaXMvaGVyIGludGVudCBkZXNjcmlwdGlvbnMsIGJ1dCB0aG9zZSBtYXkgbm90IGJlIGluIHRo ZSBpbnRlbnQgY29udGV4dCBzY29wZSBvZiBhIG5vbi1JVCBlbXBsb3llZS4gSGF2ZSBhIGZ1cnRo ZXIgY29uc2lkZXJhdGlvbiB3aXRoIHRoaXMsIGRpZmZlcmVudCB1c2VycyBvZiB0aGUgbmV0d29y ayBoYXZlIHRoZWlyIG93biBpbnRlbnQgaW4gYSBzcGVjaWZpYyBkb21haW4uIFRoZW4gdGhlIHJv bGVzL2FjdG9ycyBvZiBuZXR3b3JrIHVzZXJzLCBzdWNoIGFzIGVuZCB1c2VycywgYXBwbGljYXRp b24gZGV2ZWxvcGVycywgdGVuYW50IElUL25ldHdvcmsgYWRtaW5pc3RyYXRvcnMsIG9wZXJhdG9y IG5ldHdvcmsgYWRtaW5pc3RyYXRvcnMsIGFyZSB2YWx1YWJsZSB0byBiZSBpZGVudGlmaWVkIGFu ZCBkaXN0aW5ndWlzaGVkLCB0aHVzIGZpdHRpbmcgdGhlIGludGVudCByZXF1aXJlbWVudHMgb2Yg dGhlIG5ldHdvcmsgdXNlcnMgd2l0aCBkaWZmZXJlbnQgcm9sZXMuDQo+Pg0KPj4gQW55IHRob3Vn aHRzIGFib3V0IHRoaXMgY29uc2lkZXJhdGlvbj8NCj4+DQo+Pg0KPj4gQmVzdCBSZWdhcmRzLA0K Pj4gRmVuZ2thaQ0KPj4NCj4+IEZyb206IHNkbiBbbWFpbHRvOnNkbi1ib3VuY2VzQGlydGYub3Jn XSBPbiBCZWhhbGYgT2YgRGF2ZSBIb29kDQo+PiBTZW50OiBUdWVzZGF5LCBKdW5lIDAyLCAyMDE1 IDE6MzggQU0NCj4+IFRvOiBTdXNhbiBIYXJlczsgc2RuQGlydGYub3JnDQo+PiBDYzogWmhvdXRp YW5yYW47IFhpYXlpbmJlbjsgaWJuZW1vQGlldGYub3JnDQo+PiBTdWJqZWN0OiBSZTogW1Nkbl0g RGVmaW5pbmcgYSBDb21tb24gTW9kZWwgZm9yIGludGVudA0KPj4NCj4+IEFuIGV4Y2VycHQgZnJv bSBhbiBlbWFpbCBJIHNlbnQgb24gdGhlIE9ORiBOQkkgbGlzdCwgd2hpY2ggbWF5IGNvbnRhaW4g c29tZSB1c2VmdWwgdGhvdWdodHM6DQo+Pg0KPj4gSSBoYXZlIGFsd2F5cyBoYWQgdHJvdWJsZSB1 bmRlcnN0YW5kaW5nIHdoYXQgYW4gaW50ZW50IHJlYWxseSBpcywgc28gSSBhbSBsb29raW5nIGZv cndhcmQgdG8gbWFraW5nIHRoZSBjb25jZXB0IG1vcmUgcHJlY2lzZS4NCj4+DQo+PiBXaGVuIEkg Y2xpY2sgYSBsaW5rIG9uIGEgd2ViIHBhZ2UsIEkgZXhwcmVzcyBhbiBpbnRlbnQgdG8gaW52b2tl IHdoYXRldmVyIHRoYXQgbGluayBvZmZlcnMuIENvbXBsZXRlbHkgYmVsb3cgdGhlIHN1cmZhY2Ug aXMgYSBsYXllciBzdGFjaywgb24tZGVtYW5kIHNlc3Npb24gZXN0YWJsaXNobWVudCwgRE5TIGxv b2stdXBzLCBzZXJ2ZXIgbG9hZCBiYWxhbmNlcnMsIGFuZCBhbnkgbnVtYmVyIG9mIG90aGVyIHRl Y2hub2xvZ2ljYWwgZmVhdHVyZXMgdGhhdCBhcmUgb2Ygbm8gaW50ZXJlc3QgdG8gbWUuIFdoeSBu b3QgdXNlIHRoYXQgYXMgYW4gZXhhbXBsZSBvZiBpbnRlbnQ/DQo+Pg0KPj4gQmV0dGVyIHlldCwg d2UgdGFsayBhYm91dCBuZWdvdGlhdGlvbiBhbmQgc2VsZWN0aW9uLiBTdXBwb3NlIEkgd2FudCB0 byBidXkgYSB3aWRnZXQuIEkgcHJvYmFibHkgYWxyZWFkeSBoYXZlIHNvbWUgaWRlYSB3aGV0aGVy IEkgd2FudCB0byBnbyB0byBBbWF6b24gb3IgRUJheSBvciBzb21ld2hlcmUgZWxzZS4gU3VwcG9z ZSBpdCdzIEFtYXpvbi4gSSBzZWFyY2ggQW1hem9uJ3MgY2F0YWxvZyBhbmQgcmVjZWl2ZSBhbiBv ZmZlciBvZiBzZXZlcmFsIHdpZGdldHMsIHNvbWUgbmV3LCBzb21lIHVzZWQsIHNvbWUgd2l0aCBh IGNob2ljZSBvZiBjb2xvdXIgb3Igb3RoZXIgcGVydGluZW50IGZlYXR1cmVzLiBJZiBJIHNlZSBu b3RoaW5nIEkgbGlrZSwgSSBtYXkgb3BlbiBhIG5ldyBicm93c2VyIHdpbmRvdyBhbmQgY2hlY2sg b3V0IEJlc3QgQnV5IG9yIEVCYXkgKGxvdHMgbW9yZSBoaWRkZW4gdGVjaG5vbG9neSB0byBtYWtl IHRoYXQgaGFwcGVuISkuIE1heWJlIEkgY29tZSBiYWNrIHRvIHRoZSBBbWF6b24gcGFnZSwgaGF2 aW5nIGZvdW5kIG5vdGhpbmcgSSBsaWtlZCBiZXR0ZXIgc29tZXdoZXJlIGVsc2UuIE5vdyBJIGFj Y2VwdCBvbmUgb2YgdGhlIG9mZmVyZWQgd2lkZ2V0cyBhbmQgZ28gdGhyb3VnaCB0aGUgY2hlY2tv dXQgcHJvY2Vzcy4NCj4+DQo+PiBEbyB3ZSBhZ3JlZSB0aGF0IHRoaXMgaXMgYSBmYWlybHkgcHVy ZSBleHByZXNzaW9uIG9mIGludGVudCBhcyANCj4+IGNvbmNlcHR1YWxpemVkIGluIHRoZSBwYXBl cj8gKElmIG5vdCwgbGV0J3MgdGFsayBhYm91dCBtYWtpbmcgYSBTa3lwZSANCj4+IGNhbGwuKQ0K Pj4NCj4+IE9rLCB0aGF0J3MgbXkgaW50ZW50IGFzIGFuIGludGVybmV0IHVzZXIuIExldCdzIGFz c3VtZSB0aGUgbmV0d29yayBpcyBhbGwgU0ROIG9mIG9uZSBraW5kIG9yIGFub3RoZXIuIEkgaW52 b2tlIG15IGludGVudCB0aHJvdWdoIGEgR1VJIG9udG8gc29mdHdhcmUgbG9jYWwgdG8gbXkgUEMs IGJ1dCBJIGRvbid0IHRoaW5rIHdlIGNhbiBjYWxsIHRoZSBQQyBhbiBTRE4gY29udHJvbGxlci4g SXQncyBtb3JlIGFuIGFjdGl2ZSBtZWRpYXRvciwgYSBjbGllbnQgdG8gYW4gU0ROLiBBcyBmYXIg YXMgdGhlIG5ldHdvcmsgaXMgY29uY2VybmVkLCB0aGUgY2xpZW50IG1ha2VzIEROUyBxdWVyaWVz IGFuZCBzd2FwcyBvcGFxdWUgVENQIHBhY2tldHMgb3ZlciBhIGZvcndhcmRpbmcgcGF0aCB0aGF0 IG1heSBhbHJlYWR5IGV4aXN0LCBvciBtYXkgbmVlZCB0byBiZSBsZWFybmVkIGFuZCBzZXQgdXAg b24gZGVtYW5kLiBUaGlzIGlzIGFib3V0IHJpZ2h0LCBiZWNhdXNlIHRoZSBzZXNzaW9uIGNvbnRl bnQgbWF5IHdlbGwgYmUgZW5jcnlwdGVkIGVuZCB0byBlbmQsIGFuZCByaWdodGx5Lg0KPj4NCj4+ IFRvIHRoZSBTRE4gY29udHJvbGxlciwgbXkgaW50ZW50IGlzIHNhdGlzZmllZCBieSBkaXJlY3Rp bmcgRE5TIHF1ZXJpZXMgdG8gYSBrbm93biBETlMgc2VydmVyIHNvbWV3aGVyZSwgYW5kIGVuc3Vy aW5nIElQIGNvbm5lY3Rpdml0eSBmb3IgdGhlIHN1YnNlcXVlbnQgc2Vzc2lvbi4gSG1tbS4gd2hh dCBoYXBwZW5lZCB0byBvdXIgaW50ZW50LWJhc2VkIE5CST8gVGhlIFNETiBvZmZlcmVkIG15IFBD IGEgcGFja2V0IGludGVyZmFjZSB3aXRoIHRoZSBwcm9wZXJ0aWVzIG9mIGtub3dpbmcgaG93IHRv IHJlY29nbml6ZSBhbmQgcm91dGUgRE5TIHF1ZXJpZXMgc3BlY2lhbGx5LCBhbmQgZ2VuZXJhbCBJ UCBjb25uZWN0aXZpdHkuIE15IFBDIGFjY2VwdGVkIHRoZSBzZXJ2aWNlIG9mZmVyIGltcGxpY2l0 bHkgYnkgb2ZmZXJpbmcgdHJhZmZpYyB0byB0aGUgZGF0YS1wbGFuZSBpbnRlcmZhY2UuIFRoZSBu ZXR3b3JrIGNvdWxkIGJlIHBlcmZvcm1pbmcgYXNzb2NpYXRlZCBhdXhpbGlhcnkgc2VydmljZXMg c3VjaCBhcyB1c2FnZS1iYXNlZCBiaWxsaW5nICh0aGluayB3aXJlbGVzcyByb2FtaW5nKSwgc28g aXQncyBtb3JlIHRoYW4ganVzdCBhIGR1bWIgcGlwZS4NCj4+DQo+PiBJZiB0aGlzIGlzIG5vdCBh IGxlZ2l0aW1hdGUgZXhhbXBsZSBvZiBpbnRlbnQsIGl0IHdvdWxkIGJlIGdvb2QgdG8gd3JpdGUg dGhlIHdoaXRlIHBhcGVyIGluIHN1Y2ggYSB3YXkgdGhhdCBjbGVhcmx5IGV4Y2x1ZGVzIHN1Y2gg Y2FzZXMuDQo+Pg0KPj4gVXNlIGNhc2UgMjogc3VwcG9zZSBJIGFtIGEgY29ycG9yYXRlIElUIGVt cGxveWVlLCBhbmQgc3VwcG9zZSB0aGF0IG15IA0KPj4gaW50ZW50IGlzIHRvIGhhdmUgYW4gRS1M aW5lIGJldHdlZW4gdHdvIG9mIG15IGNhbXBpLiBJIG5lY2Vzc2FyaWx5IA0KPj4gY2FyZSBhYm91 dCBwb3J0cyBhbmQgcHJvdG9jb2xzOyB0YWxrIGFib3V0IGludGVudCBiZWluZyBwb3J0YWJsZSBh bmQgDQo+PiBwcm90b2NvbCBpbmRlcGVuZGVudCBjb250aW51ZXMgdG8gY29uZnVzZSBtZSBjb21w bGV0ZWx5LiBIb3cgY2FuIEkgDQo+PiBvcmRlciBhbiBFLWxpbmUgd2l0aG91dCBjYXJpbmcgYWJv dXQgc3VjaCBkZXRhaWxzPyBbTm9yIGlzIHRoaXMgDQo+PiBpbnRlbnQgcG9ydGFibGUuXQ0KPj4N Cj4+IE9idmlvdXNseSwgYW4gU0ROIGNvbnRyb2xsZXIgaXMgZ29pbmcgdG8gZXhwb3NlIHdoYXRl dmVyIGFjdGlvbnMgYW5kIGVsZW1lbnRzIG9mIGluZm9ybWF0aW9uIGFyZSBnZXJtYW5lIHRvIHRo ZSBzZXJ2aWNlIGl0IG9mZmVycywgYW5kIGlmIHBvcnRzIGFuZCBwcm90b2NvbHMgYXJlIGdlcm1h bmUgdG8gdGhlIHNlcnZpY2UsIHNvIGJlIGl0Lg0KPj4NCj4+IFRoZSBTRE4gYXJjaGl0ZWN0dXJl LCBiZWluZyByZWN1cnNpdmUsIG1vZGVscyB0aGUgbm9ydGggc2lkZSBvZiBhbnkgY29udHJvbGxl ciBhcyBleHBvc2luZyBhbiBpbnN0YW5jZSBvZiBhbiBpbmZvcm1hdGlvbiBtb2RlbCwgY3VzdG9t aXplZCBmb3IgdGhlIGludGVuZGVkIGNsaWVudC9jdXN0b21lci9hcHAvdXNlci4gVGhhdCBiZWlu ZyB0aGUgY2FzZSwgaG93IGRvIHdlIGRpc3Rpbmd1aXNoIGFuIE5CSSBBUEkgdGhhdCBjb252ZXlz IGludGVudCAoc2VydmljZTogc2FtZSB0aGluZz8pIGZyb20gb25lIHRoYXQgZG9lcyBub3Q/DQo+ Pg0KPj4gSSBoYXZlIHJlY2VudGx5IGNvbWUgdG8gdGhlIHZpZXcgdGhhdCBncmFudWxhcml0eSBp cyB0aGUgY3JpdGVyaW9uIGJ5IHdoaWNoIGFuIGludGVudCBvciBzZXJ2aWNlIGludm9jYXRpb24g aXMgZGlzdGluZ3Vpc2hlZC4gQ29sbG9xdWlhbGx5IHNwZWFraW5nLCBhIHNlcnZpY2UgaW52b2Nh dGlvbiBpcyBhIHNpbmdsZSBpbnZvY2F0aW9uIGFjcm9zcyB0aGUgQVBJOiBnaXZlIG1lIEUtTGlu ZS4gTm93IG9mIGNvdXJzZSB0aGlzIHR1cm5zIGludG8gY29uc3RyYWludCBuZWdvdGlhdGlvbiwg b2ZmZXIgYW5kIGFjY2VwdGFuY2UsIGJ1dCB3aGF0IGhhcHBlbnMgYWNyb3NzIHRoZSBBUEkgaXMg ZWZmZWN0aXZlbHkgb25lIHRyYW5zYWN0aW9uLiBJbiBjb250cmFzdCwgd2hhdCB3ZSBtaWdodCBh Z3JlZSBpcyAqbm90KiBhbiBpbnRlbnQgb3IgYSBzZXJ2aWNlIGlzIHRoZSBtYW5pcHVsYXRpb24g b2YgYSBncmFudWxhciBpbmZvcm1hdGlvbiBtb2RlbCwgdGhlIGV4cGxpY2l0IHZpc2liaWxpdHkg b2YgbXVsdGlwbGUgb2JqZWN0cywgaG93IHRoZXkgYXJlIGludGVycmVsYXRlZCwgdGhlaXIgYXR0 cmlidXRlcywgYW5kIHRoZSBsaWtlLg0KPj4NCj4+IC4gICAgICAgICBOZXR3b3JrIGFzIGEgc2lu Z2xlIGx1bXAgdnMgc29tZSBub24tdHJpdmlhbCB0b3BvbG9neS4NCj4+DQo+PiAuICAgICAgICAg Q2hhdWZmZXVyIHZzIGRyaXZpbmcgYSBjYXIuIExlZ2l0aW1hdGUgcmVhc29ucyB0byBjaG9vc2Ug b25lIG9wdGlvbiBvciB0aGUgb3RoZXIsIGJ1dCB0aGUgbGV2ZWwgb2YgZ3JhbnVsYXJpdHkgaXMg cXVpdGUgZGlmZmVyZW50LiBTaGFsbCB3ZSBhZ3JlZSB0aGF0IGRyaXZpbmcgaXMgdG9vIGdyYW51 bGFyIHRvIGJlIGNvbnNpZGVyZWQgaW50ZW50Pw0KPj4NCj4+IFRoaXMgaWRlYSBvZiBncmFudWxh cml0eSBhbmQgZGV0YWlsZWQgb3BlcmF0aW9ucyBvbiB0aGUgY29tcG9uZW50cyAod2hpY2ggb2Yg Y291cnNlIG1heSBiZSBjb21wbGV4IGVudGl0aWVzIHRoZW1zZWx2ZXMsIHZpcnR1YWxpemVkIGlu dG8gc2ltcGxlLWFwcGVhcmluZyBsdW1wcykgc2VlbXMgdG8gbWUgdG8gY2FwdHVyZSB0aGUgZXNz ZW5jZSBvZiB3aGF0IHBlb3BsZSBhcmUgdGFsa2luZyBhYm91dCB3aGVuIHRoZXkgc2F5IGludGVu dCBvciBzZXJ2aWNlLiBJIGFtIG5vdCBjb21mb3J0YWJsZSB3aXRoIHRoZSB3YXkgSSBhbSBleHBy ZXNzaW5nIGl0LCBzbyBpZiB0aGlzIGlzIGEgc3RlcCBpbiBhIHByb2R1Y3RpdmUgZGlyZWN0aW9u LCBvciBldmVuIGlmIGl0J3Mgbm90LCBJIHdlbGNvbWUgc3VnZ2VzdGlvbnMgdG8gY2xhcmlmeSB0 aGUgY29uY2VwdC4NCj4+DQo+PiBEYXZlDQo+Pg0KPj4gRnJvbTogc2RuIFttYWlsdG86c2RuLWJv dW5jZXNAaXJ0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdXNhbiBIYXJlcw0KPj4gU2VudDogU2F0dXJk YXksIE1heSAzMCwgMjAxNSAxOjAyIFBNDQo+PiBUbzogc2RuQGlydGYub3JnDQo+PiBDYzogJ1po b3V0aWFucmFuJzsgJ1hpYXlpbmJlbic7IGlibmVtb0BpZXRmLm9yZw0KPj4gU3ViamVjdDogW1Nk bl0gRGVmaW5pbmcgYSBDb21tb24gTW9kZWwgZm9yIGludGVudA0KPj4NCj4+IE9uIHRoaXMgbWFp bCBsaXN0LCB0aGVyZSBoYXMgYmVlbiBhIGRpc2N1c3Npb24gb2YgdHdvIHR5cGVzIG9mIGluZm9y bWF0aW9uIGZvciBJbnRlbnQgYW5kIE5lbW86IChodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJj aGl2ZS93ZWIvc2RuL2N1cnJlbnQvbXNnMDA2NDYuaHRtbCkgOg0KPj4NCj4+IDEpICAgICAgV2hh dCBpbmZvcm1hdGlvbiBpcyBuZWVkZWQgdG8gcmVwcmVzZW50IGEgc2VydmljZSByZXF1ZXN0LA0K Pj4gMikgICAgICBIb3cgdG8gcmVwcmVzZW50IGFuZCB0cmFuc3BvcnQgdGhlIGluZm9ybWF0aW9u IGZvciBhIHJlcXVlc3QuDQo+Pg0KPj4gSW4gb3JkZXIgdG8gZGVmaW5lIHdoYXQgaW5mb3JtYXRp b24gaXMgbmVlZGVkIHRvIHJlcHJlc2VudCBhIDEpIHNlcnZpY2UgcmVxdWVzdCB0aGF0IHNpZ25h bHMgSW50ZW50IGZyb20gYW4gYXBwbGljYXRpb24gdG8gYSBjb250cm9sbGVyLCBpdCBpcyBpbXBv cnRhbnQgdG8gZGVmaW5lIEludGVudCwgYW5kIHByb3ZpZGUgYSBjbGVhciBtb2RlbCBvZiBJbnRl bnQuICBBbHNvLCBpbiBkZXNjcmliaW5nIHJlYWwgdXNlLWNhc2VzIGl0IGlzIGltcG9ydGFudCB0 aGF0IG9uZSB1c2VzIHRoZSBzYW1lIGRlZmluaXRpb24gYW5kIG1vZGVsIGZvciBJbnRlbnQgaW4g ZWFjaCB1c2UgY2FzZS4NCj4+DQo+PiBJbiB0aGUgY3VycmVudCBmb3J1bXMgZXhhbWluaW5nIElu dGVudCAoT0RMIE5JQywgT0RMIE5lbW8sIE9GIE5CSSBhbmQgS2V5c3RvbmUsIE9QTkZWIE1vdmll LCBPcGVuU3RhY2spIHRoZXJlIGlzIGEgcmVhbGl6YXRpb24gdGhhdCBJbnRlbnQgb2NjdXJzIGF0 IG11bHRpcGxlIGxheWVycy4gIFRoZSBhdXRob3JzIG9mIGRyYWZ0LXhpYS1pYm5lbW8taWNpbSBo YXZlIGNyZWF0ZWQgYSBkZWZpbml0aW9uIGZvciBpbnRlbnQgYW5kIGEgdW5pZmllZCBtb2RlbCBm b3IgZGVmaW5pbmcgaW50ZW50IHdoaWNoIGNhbiBoYW5kbGUgMSBvciBtdWx0aXBsZSBsYXllcnMu IFRoZSBtb2RlbCBzdWdnZXN0IHRoYXQ6DQo+PiAxKSAgICAgIEEgdXNlciBoYXMgYSBpbnRlbnQg dGhhdCBpcyBleHByZXNzZWQgaW4gYSBjb250ZXh0Lg0KPj4gMikgICAgICBJbnRlbnQgKHVzdWFs bHkpIGludm9sdmVzIGFuIG9iamVjdCB3aXRoIGEgcmVzdWx0LCBhbmQgb3B0aW9uYWxseSBpbmNs dWRlcyBvcGVyYXRpb25zIHRvd2FyZCB0aGF0IHJlc3VsdC4NCj4+IDMpICAgICAgT3BlcmF0aW9u cyBjb25kaXRpb25zIHBlcmZvcm0gYWN0aW9ucyB3aXRoaW4vbW9kaWZpZWQgYnkgY29uc3RyYWlu dHMuDQo+Pg0KPj4gV2UgYmVsaWV2ZSB0aGlzIGRlZmluZXMgY2xlYXJseSB3aGF0IG90aGVycyBh cmUgY2FsbGluZyAicHVyZSBpbnRlbnQiIChvYmplY3RzICsgcmVzdWx0cykgdmVyc3VzICJjb25z dHJhaW5lZCBpbnRlbnQiIChvYmplY3RzICsgb3BlcmF0aW9ucyArIGNvbnN0cmFpbnRzKS4gICBU aGUgZHJhZnQgY2FuIGJlIGZvdW5kIGF0OiAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LXhpYS1pYm5lbW8taWNpbS8gLiAgIFRoZSBhdXRob3JzIGFyZSBsb29raW5nIGZv ciBmZWVkYmFjayBvbiB0aGUgY29uY2VwdHMgaW4gdGhlIGRyYWZ0Lg0KPj4NCj4+IFN1ZSBIYXJl cw0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+PiBzZG4gbWFpbGluZyBsaXN0DQo+PiBzZG5AaXJ0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3Lmly dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2RuDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IElibmVtbyBtYWlsaW5nIGxpc3QNCj4+IEli bmVtb0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p Ym5lbW8NCj4gPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KSWJuZW1vIG1haWxpbmcgbGlzdA0KSWJuZW1vQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2libmVtbw0K From nobody Fri Jun 5 06:24:29 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 726F61B2F65 for ; Fri, 5 Jun 2015 06:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.078 X-Spam-Level: ** X-Spam-Status: No, score=2.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcoJ0crFWUZG for ; Fri, 5 Jun 2015 06:24:25 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36E901B2F59 for ; Fri, 5 Jun 2015 06:24:24 -0700 (PDT) Received: from 172.24.2.119 (EHLO nkgeml407-hub.china.huawei.com) ([172.24.2.119]) by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued) with ESMTP id BHG72796; Fri, 05 Jun 2015 21:23:34 +0800 (CST) Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.7]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Fri, 5 Jun 2015 21:10:48 +0800 From: Xiayinben To: "Bert Wijnen (IETF)" , Susan Hares , Zhoutianran , "'STUART VENTERS'" , "sdn@irtf.org" Thread-Topic: [Ibnemo] [Sdn] Defining a Common Model for intent Thread-Index: AQHQntutwWynsS9XIkKuNMawHCQ8xZ2d1Kog Date: Fri, 5 Jun 2015 13:10:47 +0000 Message-ID: <5FD31D8EDBF4EC468B36D86F04FDB2E873829CC6@nkgeml507-mbs.china.huawei.com> References: <00f301d09b13$79cc2410$6d646c30$@ndzh.com> <8D15A2BAF93E9C49AB037A0647E5FA643F8490D8@eusaamb105.ericsson.se> <865C20BAAE8BBD4C89E7D6FE694F6B3B2D3CA540@nkgeml505-mbs.china.huawei.com> <8D15A2BAF93E9C49AB037A0647E5FA643F84AAA2@eusaamb105.ericsson.se> <1220E2C537595D439C5D026E83751866C42AC2FF@ex-mb3.corp.adtran.com> , <556EFC42.9040208@bwijnen.net> <001201d09ed8$f7c6f480$e754dd80$@ndzh.com> <55706F7C.9080300@bwijnen.net> In-Reply-To: <55706F7C.9080300@bwijnen.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.17.47] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.5571A2D7.0139, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.6.7, so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 0eefa8240632f619feed8d2ee2e36703 Archived-At: Cc: "ibnemo@ietf.org" Subject: [Sdn] =?gb2312?b?tPC4tDogW0libmVtb10gICAgRGVmaW5pbmcgYSBDb21tb24g?= =?gb2312?b?TW9kZWwgZm9yIGludGVudA==?= X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 13:24:28 -0000 SW4gbXkgdW5kZXJzdGFuZGluZzoNClVzZXIgZXhwcmVzc2VzL293bnMgYSBzZXQgb2Ygc3BlY2lm aWMgaW50ZW50IGluc3RhbmNlczsNClJvbGUgZGVjaWRlcyBpbnRlbnQgc2NvcGUgYW5kIGNvbnRl bnQgd2hpY2ggaXMgY2FyZWQgYnkgdGhlIHJvbGU7DQpVc2VyIGNhbiBoYXZlIG9uZSBvciBtb3Jl IHJvbGVzLg0KRG8geW91IHRoaW5rIHRoaXMgbWFrZSBzZW5zZT8NCg0KWWluYmVuDQoNCi0tLS0t 08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBJYm5lbW8gW21haWx0bzppYm5lbW8tYm91bmNlc0BpZXRm Lm9yZ10gtPqx7SBCZXJ0IFdpam5lbiAoSUVURikNCreiy83KsbzkOiAyMDE1xOo21MI0yNUgMjM6 MzINCsrVvP7IyzogU3VzYW4gSGFyZXM7IFpob3V0aWFucmFuOyAnU1RVQVJUIFZFTlRFUlMnOyBz ZG5AaXJ0Zi5vcmcNCrOty806IGlibmVtb0BpZXRmLm9yZw0K1vfM4jogUmU6IFtJYm5lbW9dIFtT ZG5dIERlZmluaW5nIGEgQ29tbW9uIE1vZGVsIGZvciBpbnRlbnQNCg0KT24gMDQvMDYvMTUgMTc6 MTMsIFN1c2FuIEhhcmVzIHdyb3RlOg0KPiBCZXJ0IGFuZCBUaWFucmFuOg0KPg0KPiBJZiB5b3Ug bGluayBpbnRlbnQgdG8gcm9sZSwgSSBiZWxpZXZlIHlvdXIgZGlhZ3JhbSBpczoNCj4NCj4gVXNl ciAtLT4gaW50ZW50IC0tPiByb2xlIC0tPiBjb250ZXh0DQoNCkNvdWxkIGJlLCBidXQgaXMgInVz ZXIiIG5vdCBhIHJvbGUuDQpJIHNlZSByb2xlcyBhczoNCi0gdXNlci9lbmQtdXNlciBvciBjdXN0 b21lcg0KLSBzZXJ2aWNlIHByb3ZpZGVyDQotIG5ldHdvcmsgYWNoaXRlY3QNCi0gbmV0d29yayBv cGVyYXRvcg0KLSBtYXliZSBhbHNvIHRyb3VibGUtc2hvb3Rlcg0KDQpJcyB0aGF0IG5vdCB0aGUg aWRlYS8NCg0KQmVydA0KcC5zLiB3aHkgaXMgdGhpcyBjb3BpZWQgdG8gMiBtYWlsaW5nIGxpc3Rz LCBzZG4gYW5kIGlibmVtbz8NCkkgdGhvdWdodCB0aGF0IHRoZSBpbnRlbnQtbW9kZWxsaW5nIHdv cmsgaXMgaW4gaWJuZW1vLCBpZiBzbywgdGhlbiBTRE4gUkcgcGVvcGxlIHdobyBhcmUgaW50ZXJl c3RlZCBzaG91bGQgY29tZSBvdmVydGhlcmUuDQpOb3cgaWYgd2Ugd2VyZSB0YWxraW5nIFNETiBz cGVjaWZpYyBpbnRlbnQgbW9kZWxsaW5nLCB0aGVuIG1heWJlIGl0IGlzIE9LLCBCdXQgSSB0aG91 Z2h0IHdlIGFyZSBkaXNjdXNzaW5nIGdlbmVyaWMgaW50ZW50IG1vZGVsbGluZywgbm8/DQoNCkJl cnQNCj4gSSB0aGluayByb2xlIHRha2VzIG9uIGFuIGFzcGVjdCBvZiBjb250ZXh0LiAgIFdoYXQg ZG8geW91IHRoaW5rPw0KPg0KPiBTdWUNCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogc2RuIFttYWlsdG86c2RuLWJvdW5jZXNAaXJ0Zi5vcmddIE9uIEJlaGFsZiBPZiBa aG91dGlhbnJhbg0KPiBTZW50OiBUaHVyc2RheSwgSnVuZSAwNCwgMjAxNSA4OjI3IEFNDQo+IFRv OiBCZXJ0IFdpam5lbiAoSUVURik7IFNUVUFSVCBWRU5URVJTOyBzZG5AaXJ0Zi5vcmcNCj4gQ2M6 IGlibmVtb0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW1Nkbl0gW0libmVtb10gRGVmaW5pbmcg YSBDb21tb24gTW9kZWwgZm9yIGludGVudA0KPg0KPiBIaSBCZXJ0LA0KPg0KPiBUaGFua3MgZm9y IHlvdSBjb21tZW50cy4NCj4gSSBhZ3JlZSB3aXRoIHlvdSB0aGF0IHdlJ2QgYmV0dGVyIGp1c3Qg Zm9jdXMgb24gdGhlIHRvcCBsYXllci4NCj4gQnV0IEkgYW0gc29ycnksIHdoYXQgZG8geW91IG1l YW4gaW4gdGhlIGxhc3Qgc2VudGVuY2U/DQo+ICJBIHJvbGUgLWJhc2VkIGludGVudCBtb2RlbD8g SSBndWVzcyBpdCB3b3VsZCBqdXN0IGJvaWwgZG93biBpbiANCj4gZGlmZmVyZW50IHR5cGVzIG9m IGludGVudCB0aGF0IGZpdCB3aXRoIHRoZSBzcGVjaWZpYyByb2xlLCByaWdodD8iDQo+IENvdWxk IHlvdSBnaXZlIG1vcmUgaW5mb3JtYXRpb24gb24gdGhpcz8NCj4NCj4gQmVzdCwNCj4gVGVyZW5j ZQ0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ILeivP7I yzogQmVydCBXaWpuZW4gKElFVEYpIFtid2lldGZAYndpam5lbi5uZXRdDQo+ILeiy83KsbzkOiAy MDE1xOo21MIzyNUgMjE6MDgNCj4gytW8/sjLOiBaaG91dGlhbnJhbjsgU1RVQVJUIFZFTlRFUlM7 IHNkbkBpcnRmLm9yZw0KPiCzrcvNOiBpYm5lbW9AaWV0Zi5vcmcNCj4g1vfM4jogUmU6IFtJYm5l bW9dIFtTZG5dIERlZmluaW5nIGEgQ29tbW9uIE1vZGVsIGZvciBpbnRlbnQNCj4NCj4gSGkgYWxs LA0KPg0KPiBJIGxpa2UgdGhlIGlkZWEgb2YgKGF0IGxlYXN0IGZvciBub3cpIHN0aWNrIHRvIHRo ZSBwcm9ibGVtIG9mICJpbnRlbnQiIA0KPiBmb3Igb25lIGxheWVyICh0aGUgdG9wIGxheWVyKS4N Cj4gTGV0IHVzIG5vdCBib2lsIHRoZSBvY2VhbiBhbmQgdHJ5IHRvIGRvIGV2ZXJ5dGhpbmcgdGhh dCBjb21lcyB1cC4gSWYgDQo+IHdlIGFyZSBzdWNjZXNzZnVsIGluIGRvaW5nIGEgbW9kZWwgZm9y IElCTkVNTyBmb3IgdGhlIHRvcCBsYXllciwgd2UgDQo+IGNhbiB0aGVuIHNlZSBpZiB3ZSB3YW50 IHRvIGdvIGF0IG1vcmUgbGF5ZXJzLg0KPg0KPiBBIHJvbGUgLWJhc2VkIGludGVudCBtb2RlbD8g SSBndWVzcyBpdCB3b3VsZCBqdXN0IGJvaWwgZG93biBpbiANCj4gZGlmZmVyZW50IHR5cGVzIG9m IGludGVudCB0aGF0IGZpdCB3aXRoIHRoZSBzcGVjaWZpYyByb2xlLCByaWdodD8NCj4NCj4gQmVy dA0KPg0KPg0KPiBPbiAwMy8wNi8xNSAxMTo0NCwgWmhvdXRpYW5yYW4gd3JvdGU6DQo+PiBIaSBT dHVhcnQsDQo+Pg0KPj4gVGhhbmtzIGZvciB0aGlzIGRlZXAgdGhpbmtpbmcgd2l0aCBhIHNldCBv ZiBleGFtcGxlcy4gSXQncyByZWFsbHkNCj4gaW1wb3J0YW50IHRvIGNsYXJpZnkgdGhpcyBmdXp6 eSBpbnRlbnQuDQo+PiBJIHRoaW5rIGFsbCB0aGUgY29uY2VybiBhbmQgdW5jZXJ0YWludHkgaXMg YmVjYXVzZSBvZiB0aGUgbGF5ZXJlZA0KPiB0aGlua2luZy4gV2UgdGhpbmsgaW50ZW50IGlzIGEg cmVsYXRpdmVseSBoaWdoZXIgbGV2ZWwgbmVzdGVkLg0KPj4gV2hhdCBpZiB3ZSB0aGluayBhYm91 dCBpbnRlbnQgd2l0aCBkaWZmZXJuZXQgcm9sZXM/IEp1c3QgbGlrZSBhIA0KPj4gcmVsYXRpdmUN Cj4gZGV0YWlsZWQgZGVzY3JpcHRpb24gaW4gbXkgInJvbGUgYmFzZWQgaW50ZW50IiBlbWFpbC4N Cj4+IEkgdGhpbmsgdGhlIGVzc2VudGlhbCBvZiB0aGUgcm9sZSBiYXNlZCBpbnRlbnQgaXMgdGhh dCB0aGVyZSBpcyBvbmx5IA0KPj4gb25lDQo+IGludGVudCBsYXllciB3aGljaCBpcyBhbHdheXMg b24gdGhlIHRvcC4gSW50ZW50IGlzIGRlZGljYXRlZCBmb3IgDQo+IGNvcnJlc3BvbmRpbmcgcm9s ZXMuIE9uZSByb2xlIHdpbGwgbm90IGNhbGwgb3RoZXIgcm9sZXMgaW50ZXJmYWNlcy4NCj4+IFRo ZW4gd2UgY2FuIHRyeSB0byBmaW5kIHdheSB0byBleHByZXNzIGludGVudCBmb3IgdmFyaW91cyBy b2xlcy4NCj4+DQo+Pg0KPj4gUmVnYXJkcywNCj4+IFRlcmVuY2UNCj4+DQo+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogc2RuIFttYWlsdG86c2RuLWJvdW5jZXNAaXJ0Zi5v cmddIE9uIEJlaGFsZiBPZiBTVFVBUlQgVkVOVEVSUw0KPj4gU2VudDogV2VkbmVzZGF5LCBKdW5l IDAzLCAyMDE1IDEyOjA2IEFNDQo+PiBUbzogc2RuQGlydGYub3JnDQo+PiBDYzogJ0RhdmUgSG9v ZCc7IGlibmVtb0BpZXRmLm9yZzsgTGlmZW5na2FpIChGZW5na2FpKTsgWmhvdXRpYW5yYW47IA0K Pj4gWGlheWluYmVuOyBTdXNhbiBIYXJlcw0KPj4gU3ViamVjdDogUmU6IFtTZG5dIERlZmluaW5n IGEgQ29tbW9uIE1vZGVsIGZvciBpbnRlbnQNCj4+DQo+Pg0KPj4NCj4+IEkgaGF2ZSAyIGNlbnRz IHRvIGNvbnRyaWJ1dGUgZm9yIHRoaXMgZnV6enkgaW50ZW50IHdvcmQgYW5kIHJlc3VsdGluZyAN Cj4+IGRhdGENCj4gbW9kZWwuDQo+PiBQZXJoYXBzICdpbnRlbnQnICBpcyBqdXN0IGEgcmVsYXRp dmVseSBoaWdoIGxldmVsIHNlcnZpY2UgcmVxdWVzdC4NCj4+IFRoZSBwcm9ibGVtIHdpdGggdGhp cyBkZWZpbml0aW9uIGlzIHdoYXQgaXMgdGhhdCAncmVsYXRpdmVseSBoaWdoIGxldmVsJw0KPiBh cHBlYXJzIHRvIGRlcGVuZCBvbiB5b3VyIHBvaW50IG9mIHZpZXcuDQo+PiBUbyBoZWxwIHRoaW5r IGFib3V0IGl0LCBoZXJlJ3MgYSBsb25nIGNoYWluIG9mIGNvbW1hbmQgZm9yIHRoZSBzYW1lDQo+ IGFjdGlvbi4NCj4+IEl0IGlzIGxvbmcgZm9yIGZ1biBhbmQgc28gdGhhdCBhbnlib2R5IGNhbiBm aW5kIHBhcnQgb2YgaXQgdGhhdCB0aGV5DQo+IHJlY29nbml6ZS4NCj4+DQo+PiBDaGFpbiBvZiBj b21tYW5kOg0KPj4NCj4+IEludmVzdG9yIHNheXM6IG1ha2UgbW9uZXkNCj4+IENFTyBzYXlzOiBt YWtlIHRoZSBuZXR3b3JrIHdvcmsNCj4+IENJTyBzYXlzOiBnaXZlIG1lIGJhbmR3aWR0aHMgYmV0 d2VlbiBzaXRlcyBBLCBCLCBhbmQgQyBOZXQgZW5naW5lZXINCj4+IHNheXM6IEkgbmVlZCB0aGVz ZSBldmMncyB0byB0aGVzZSBlbmRwb2ludHMgUHVyY2hhc2luZyBhZ2VudDogU2F5cyANCj4+IHVz ZSB0aGlzIHByb2R1Y3QgZnJvbSB0aGlzIHZlbmRvciBTYWxlcyBQZXJzb24gc2F5czogSGVyZSBp cyB0aGUgDQo+PiBwcmljZSBhbmQgcHJpb3JpdHkNCj4+IFBhcnRpdGlvbmVyOiBkaXZpZGVzIHRo ZSBlbmQgdG8gZW5kIGNpcmN1aXQgYW1vbmcgYWRtaW5pc3RyYXRpdmUgDQo+PiBkb21haW5zDQo+ PiBQbGFubmVyOiBwaWNrcyB0aGUgbmVjZXNzYXJ5IHJlc291cmNlcyB0byB1c2UsIG1ha2VzIHRo ZSB0cnVjayByb2xscyANCj4+IGhhcHBlbg0KPj4gQWxsb2NhdG9yOiBhbGxvY2F0ZXMgdGhlIG5l Y2Vzc2FyeSBiYW5kd2lkdGgNCj4+IFByb3Zpc2lvbmVyOiBkZWNpZGVzIHdoYXQgcHJvdmlzaW9u aW5nIGlzIG5lY2Vzc2FyeSBpbiBlYWNoIHBhcnQgb2YgDQo+PiB0aGUgcGF0aA0KPj4gQWRhcHRv cjogdGFpbG9ycyB0aGUgcHJvdmlzaW9uaW5nIHRvIGEgc3BlY2lmaWMgYm94DQo+PiBEcml2ZXI6 IHB1c2hlcyB0aGUgcHJvdmlzaW9uaW5nIGludG8gdGhlIGZvcndhcmRpbmcgdGFibGVzIEZvcndh cmRpbmcNCj4+IGVuZ2luZTogZm9yd2FyZHMgYWNjb3JkaW5nIHRvIHRoZSB0YWJsZXMNCj4+DQo+ PiBUaGUgSW52ZXN0b3IncyBzdGF0ZW1lbnQgYXQgdGhlIHRvcCBpcyBjbGVhcmx5IHdoYXQgYW5k IG5vdCBob3cuDQo+PiBUaGUgZm9yd2FyZGluZyBlbmdpbmUncyBvcGVyYXRpb25zIGhhdmUgYSBs b3Qgb2YgaG93LCBidXQgbWF5YmUgDQo+PiBsaXR0bGUNCj4gZ2xvYmFsIHZpZXcgb2Ygd2hhdCB3 ZSBhcmUgZG9pbmcgb3ZlcmFsbC4NCj4+IElmIHdlIHNheSB0aGF0IHRoZSB0b3AgaXMgaW50ZW50 IGFuZCB0aGUgYm90dG9tIGlzIGEgaXMgc2VydmljZSByZXF1ZXN0LA0KPj4gICAgIHdobydzIHRv IHNheSB3aGVyZSBpbnRlbnQgc3RvcHMgYW5kIHNlcnZpY2UgcmVxdWVzdHMgc3RhcnQ/DQo+Pg0K Pj4gUGVyaGFwcyAgJ2ludGVudCcgbWVhbnMgYSBzZXJ2aWNlIHJlcXVlc3QgY29taW5nIGZyb20g YSBoaWdoZXIgbGF5ZXIgDQo+PiBmb3INCj4gcmVmaW5lbWVudC4NCj4+IFRoYXQgc2FpZCwgdGhl IGRhdGEgbW9kZWwgZm9yIGludGVudCBtaWdodC9zaG91bGQgYmUgZGlmZmVyZW50IGF0IA0KPj4g ZWFjaA0KPiBsZXZlbC4NCj4+IFNpbmNlIGVhY2ggbGV2ZWwgaXMgcHJvY2Vzc2luZyB0aGUgc2Ft ZSByZXF1ZXN0IGF0IGRpZmZlcmVudCBsZXZlbHMgDQo+PiBvZg0KPiBkZXRhaWwsIGl0IG1pZ2h0 IGJlIHNpbWlsYXIgYXQgZWFjaCBsZXZlbC4NCj4+IFBlcmhhcHMgdGhlIGRhdGEgbW9kZWwgc3Rh cnRzIHNpbXBsZSBvbiB0b3AgYW5kIGdhdGhlcnMgbW9yZSBhbmQgbW9yZQ0KPiBkZXRhaWwgYXMg aXQgZ2V0cyBsb3dlciA/DQo+PiBNYXliZSBsaWtlIGEgdHJlZSB3aXRoIHRoZSByb290IGF0IHRo ZSB0b3AgYW5kIGxlYXZlcyBhdCB0aGUgDQo+PiBmb3J3YXJkaW5nDQo+IGVuZ2luZXMsIGV4Y2Vw dCBkaXN0cmlidXRlZC4NCj4+IFBlcmhhcHMgYSBzaW1wbGUgc3RhcnRpbmcgcG9pbnQgbmVhciB0 aGUgdG9wIGlzIGEgY29tYmluYXRpb24gb2YgDQo+PiBlbnRpdGllcywNCj4gZW5kcG9pbnRzLCBh bmQgY29ubmVjdGlvbnMuDQo+Pg0KPj4gUmVnYXJkcywNCj4+DQo+PiBTdHVhcnQgVmVudGVycw0K Pj4NCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+IEZyb206IHNkbiBbbWFpbHRvOnNkbi1ib3Vu Y2VzQGlydGYub3JnXSBPbiBCZWhhbGYgT2YgRGF2ZSBIb29kDQo+PiBTZW50OiBUdWVzZGF5LCBK dW5lIDAyLCAyMDE1IDg6MjYgQU0NCj4+IFRvOiBMaWZlbmdrYWkgKEZlbmdrYWkpOyBTdXNhbiBI YXJlczsgc2RuQGlydGYub3JnDQo+PiBDYzogWmhvdXRpYW5yYW47IFhpYXlpbmJlbjsgaWJuZW1v QGlldGYub3JnDQo+PiBTdWJqZWN0OiBSZTogW1Nkbl0gRGVmaW5pbmcgYSBDb21tb24gTW9kZWwg Zm9yIGludGVudA0KPj4NCj4+IEkgYWdyZWUgdGhhdCB0aGUgY29udGV4dCBtYXR0ZXJzLCBGZW5n a2FpIChhbmQgU3VzYW4gaW4gZWFybGllciByZXNwb25zZSkuDQo+IFdoYXQgdGhlIEktRCBhcHBl YXJzIHRvIGJlIHNheWluZyBpcyB0aGF0IGFueSBpbnRlcmFjdGlvbiBhY3Jvc3MgYW4gDQo+IE5C SSBpcw0KPiBpbnRlbnQ6IG90aGVyd2lzZSB0aGUgYXBwL3RlbmFudC9jdXN0b21lciB3b3VsZG4n dCBkbyBpdC4gVGhhdCdzIHRoZSANCj4gcm9vdCBvZiBteSBxdWVzdGlvbiBmcm9tIHRoZSBiZWdp bm5pbmc6IGhvdyB3b3VsZCB3ZSBrbm93IHdoYXQgaXMgKm5vdCogaW50ZW50Pw0KPj4gSWYgSSBh c2sgZm9yIHNvbWUgcGFydGljdWxhciBtaWNyb3Njb3BpY2FsbHkgZGV0YWlsZWQgY29uZmlndXJh dGlvbiANCj4+IChhDQo+ICJob3ciKSwgaXQncyBiZWNhdXNlIEkgY2FyZSwgZm9yIHNvbWUgcmVh c29uLCBhYm91dCB0aGF0IGxldmVsIG9mIA0KPiBkZXRhaWwuIEl0IGlzIGluIGZhY3QgcGFydCBv ZiBteSBpbnRlbnQuDQo+PiBJbiBteSBJVCBleGFtcGxlLCBJIGFyZ3VlIHRoYXQgaW50ZW50IG5l ZWQgbm90IGJlIGluZGVwZW5kZW50IG9mIA0KPj4gcHJvdG9jb2xzDQo+IGFuZCBwb3J0cywgYW5k IHRoYXQgaXQgbmVlZCBub3QgYmUgcG9ydGFibGUuIFlvdXIgcmVzcG9uc2UgYWJvdXQgDQo+IGNv bnRleHQgYXBwZWFycyB0byBhZ3JlZS4NCj4+IFNvIGFzIGJlc3QgSSBjYW4gdGVsbCwgd2UgY2Fu IHNheSBwcmVjaXNlbHkgd2hhdCBhbiBpbnRlbnQgaXMsIGFuZCB3ZQ0KPiBjYW4ndCBzYXkgd2hh dCBhbiBpbnRlbnQgaXMgbm90LiBJZiBpbnRlbnQgaXMganVzdCB0aGUgbGF0ZXN0IA0KPiBidXp6 d29yZCwgd2hpY2ggaXQgY2VydGFpbmx5IGFwcGVhcnMgdG8gYmUsIGNhbiB3ZSBqdXN0IHNheSBz byBhbmQgDQo+IGxlYXZlIGl0IHRvIHRoZSBtYXJrZXRpbmcgcGVvcGxlPw0KPj4gRGF2ZQ0KPj4N Cj4+IEZyb206IExpZmVuZ2thaSAoRmVuZ2thaSkgW21haWx0bzpsaWZlbmdrYWlAaHVhd2VpLmNv bV0NCj4+IFNlbnQ6IFR1ZXNkYXksIEp1bmUgMDIsIDIwMTUgMTI6NDcgQU0NCj4+IFRvOiBEYXZl IEhvb2Q7IFN1c2FuIEhhcmVzOyBzZG5AaXJ0Zi5vcmcNCj4+IENjOiBaaG91dGlhbnJhbjsgWGlh eWluYmVuOyBpYm5lbW9AaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJFOiBbU2RuXSBEZWZpbmluZyBh IENvbW1vbiBNb2RlbCBmb3IgaW50ZW50DQo+Pg0KPj4gSGkgRGF2ZSBhbmQgYWxsLA0KPj4NCj4+ IFRoYW5rcyBmb3IgcHJvcG9zaW5nIHRoZSB0d28gdmFsdWFibGUgaW50ZW50IHVzZSBjYXNlcy4N Cj4+DQo+PiBGb3IgdGhlIHVzZSBjYXNlIDIsIEkgYWdyZWUgdGhhdCB0aGUgSVQgZW1wbG95ZWUg bmVlZHMgdG8gaW5jbHVkZSB0aGUNCj4gZGV0YWlscyBvZiBwb3J0cy9wcm90b2NvbHMgaW50byBo aXMvaGVyIGludGVudCBkZXNjcmlwdGlvbnMsIGJ1dCB0aG9zZSANCj4gbWF5IG5vdCBiZSBpbiB0 aGUgaW50ZW50IGNvbnRleHQgc2NvcGUgb2YgYSBub24tSVQgZW1wbG95ZWUuIEhhdmUgYSANCj4g ZnVydGhlciBjb25zaWRlcmF0aW9uIHdpdGggdGhpcywgZGlmZmVyZW50IHVzZXJzIG9mIHRoZSBu ZXR3b3JrIGhhdmUgDQo+IHRoZWlyIG93biBpbnRlbnQgaW4gYSBzcGVjaWZpYyBkb21haW4uIFRo ZW4gdGhlIHJvbGVzL2FjdG9ycyBvZiANCj4gbmV0d29yayB1c2Vycywgc3VjaCBhcyBlbmQgdXNl cnMsIGFwcGxpY2F0aW9uIGRldmVsb3BlcnMsIHRlbmFudCANCj4gSVQvbmV0d29yayBhZG1pbmlz dHJhdG9ycywgb3BlcmF0b3IgbmV0d29yayBhZG1pbmlzdHJhdG9ycywgYXJlIA0KPiB2YWx1YWJs ZSB0byBiZSBpZGVudGlmaWVkIGFuZCBkaXN0aW5ndWlzaGVkLCB0aHVzIGZpdHRpbmcgdGhlIGlu dGVudCANCj4gcmVxdWlyZW1lbnRzIG9mIHRoZSBuZXR3b3JrIHVzZXJzIHdpdGggZGlmZmVyZW50 IHJvbGVzLg0KPj4gQW55IHRob3VnaHRzIGFib3V0IHRoaXMgY29uc2lkZXJhdGlvbj8NCj4+DQo+ Pg0KPj4gQmVzdCBSZWdhcmRzLA0KPj4gRmVuZ2thaQ0KPj4NCj4+IEZyb206IHNkbiBbbWFpbHRv OnNkbi1ib3VuY2VzQGlydGYub3JnXSBPbiBCZWhhbGYgT2YgRGF2ZSBIb29kDQo+PiBTZW50OiBU dWVzZGF5LCBKdW5lIDAyLCAyMDE1IDE6MzggQU0NCj4+IFRvOiBTdXNhbiBIYXJlczsgc2RuQGly dGYub3JnDQo+PiBDYzogWmhvdXRpYW5yYW47IFhpYXlpbmJlbjsgaWJuZW1vQGlldGYub3JnDQo+ PiBTdWJqZWN0OiBSZTogW1Nkbl0gRGVmaW5pbmcgYSBDb21tb24gTW9kZWwgZm9yIGludGVudA0K Pj4NCj4+IEFuIGV4Y2VycHQgZnJvbSBhbiBlbWFpbCBJIHNlbnQgb24gdGhlIE9ORiBOQkkgbGlz dCwgd2hpY2ggbWF5IA0KPj4gY29udGFpbg0KPiBzb21lIHVzZWZ1bCB0aG91Z2h0czoNCj4+IEkg aGF2ZSBhbHdheXMgaGFkIHRyb3VibGUgdW5kZXJzdGFuZGluZyB3aGF0IGFuIGludGVudCByZWFs bHkgaXMsIHNvIA0KPj4gSSBhbQ0KPiBsb29raW5nIGZvcndhcmQgdG8gbWFraW5nIHRoZSBjb25j ZXB0IG1vcmUgcHJlY2lzZS4NCj4+IFdoZW4gSSBjbGljayBhIGxpbmsgb24gYSB3ZWIgcGFnZSwg SSBleHByZXNzIGFuIGludGVudCB0byBpbnZva2UgDQo+PiB3aGF0ZXZlcg0KPiB0aGF0IGxpbmsg b2ZmZXJzLiBDb21wbGV0ZWx5IGJlbG93IHRoZSBzdXJmYWNlIGlzIGEgbGF5ZXIgc3RhY2ssIA0K PiBvbi1kZW1hbmQgc2Vzc2lvbiBlc3RhYmxpc2htZW50LCBETlMgbG9vay11cHMsIHNlcnZlciBs b2FkIGJhbGFuY2VycywgDQo+IGFuZCBhbnkgbnVtYmVyIG9mIG90aGVyIHRlY2hub2xvZ2ljYWwg ZmVhdHVyZXMgdGhhdCBhcmUgb2Ygbm8gaW50ZXJlc3QgDQo+IHRvIG1lLiBXaHkgbm90IHVzZSB0 aGF0IGFzIGFuIGV4YW1wbGUgb2YgaW50ZW50Pw0KPj4gQmV0dGVyIHlldCwgd2UgdGFsayBhYm91 dCBuZWdvdGlhdGlvbiBhbmQgc2VsZWN0aW9uLiBTdXBwb3NlIEkgd2FudCANCj4+IHRvIGJ1eQ0K PiBhIHdpZGdldC4gSSBwcm9iYWJseSBhbHJlYWR5IGhhdmUgc29tZSBpZGVhIHdoZXRoZXIgSSB3 YW50IHRvIGdvIHRvIA0KPiBBbWF6b24gb3IgRUJheSBvciBzb21ld2hlcmUgZWxzZS4gU3VwcG9z ZSBpdCdzIEFtYXpvbi4gSSBzZWFyY2ggDQo+IEFtYXpvbidzIGNhdGFsb2cgYW5kIHJlY2VpdmUg YW4gb2ZmZXIgb2Ygc2V2ZXJhbCB3aWRnZXRzLCBzb21lIG5ldywgDQo+IHNvbWUgdXNlZCwgc29t ZSB3aXRoIGEgY2hvaWNlIG9mIGNvbG91ciBvciBvdGhlciBwZXJ0aW5lbnQgZmVhdHVyZXMuIA0K PiBJZiBJIHNlZSBub3RoaW5nIEkgbGlrZSwgSSBtYXkgb3BlbiBhIG5ldyBicm93c2VyIHdpbmRv dyBhbmQgY2hlY2sgb3V0IA0KPiBCZXN0IEJ1eSBvciBFQmF5IChsb3RzIG1vcmUgaGlkZGVuIHRl Y2hub2xvZ3kgdG8gbWFrZSB0aGF0IGhhcHBlbiEpLiANCj4gTWF5YmUgSSBjb21lIGJhY2sgdG8g dGhlIEFtYXpvbiBwYWdlLCBoYXZpbmcgZm91bmQgbm90aGluZyBJIGxpa2VkIA0KPiBiZXR0ZXIg c29tZXdoZXJlIGVsc2UuIE5vdyBJIGFjY2VwdCBvbmUgb2YgdGhlIG9mZmVyZWQgd2lkZ2V0cyBh bmQgZ28gdGhyb3VnaCB0aGUgY2hlY2tvdXQgcHJvY2Vzcy4NCj4+IERvIHdlIGFncmVlIHRoYXQg dGhpcyBpcyBhIGZhaXJseSBwdXJlIGV4cHJlc3Npb24gb2YgaW50ZW50IGFzIA0KPj4gY29uY2Vw dHVhbGl6ZWQgaW4gdGhlIHBhcGVyPyAoSWYgbm90LCBsZXQncyB0YWxrIGFib3V0IG1ha2luZyBh IFNreXBlDQo+PiBjYWxsLikNCj4+DQo+PiBPaywgdGhhdCdzIG15IGludGVudCBhcyBhbiBpbnRl cm5ldCB1c2VyLiBMZXQncyBhc3N1bWUgdGhlIG5ldHdvcmsgaXMgDQo+PiBhbGwNCj4gU0ROIG9m IG9uZSBraW5kIG9yIGFub3RoZXIuIEkgaW52b2tlIG15IGludGVudCB0aHJvdWdoIGEgR1VJIG9u dG8gDQo+IHNvZnR3YXJlIGxvY2FsIHRvIG15IFBDLCBidXQgSSBkb24ndCB0aGluayB3ZSBjYW4g Y2FsbCB0aGUgUEMgYW4gU0ROIA0KPiBjb250cm9sbGVyLiBJdCdzIG1vcmUgYW4gYWN0aXZlIG1l ZGlhdG9yLCBhIGNsaWVudCB0byBhbiBTRE4uIEFzIGZhciANCj4gYXMgdGhlIG5ldHdvcmsgaXMg Y29uY2VybmVkLCB0aGUgY2xpZW50IG1ha2VzIEROUyBxdWVyaWVzIGFuZCBzd2FwcyANCj4gb3Bh cXVlIFRDUCBwYWNrZXRzIG92ZXIgYSBmb3J3YXJkaW5nIHBhdGggdGhhdCBtYXkgYWxyZWFkeSBl eGlzdCwgb3IgDQo+IG1heSBuZWVkIHRvIGJlIGxlYXJuZWQgYW5kIHNldCB1cCBvbiBkZW1hbmQu IFRoaXMgaXMgYWJvdXQgcmlnaHQsIA0KPiBiZWNhdXNlIHRoZSBzZXNzaW9uIGNvbnRlbnQgbWF5 IHdlbGwgYmUgZW5jcnlwdGVkIGVuZCB0byBlbmQsIGFuZCByaWdodGx5Lg0KPj4gVG8gdGhlIFNE TiBjb250cm9sbGVyLCBteSBpbnRlbnQgaXMgc2F0aXNmaWVkIGJ5IGRpcmVjdGluZyBETlMgDQo+ PiBxdWVyaWVzIHRvDQo+IGEga25vd24gRE5TIHNlcnZlciBzb21ld2hlcmUsIGFuZCBlbnN1cmlu ZyBJUCBjb25uZWN0aXZpdHkgZm9yIHRoZSANCj4gc3Vic2VxdWVudCBzZXNzaW9uLiBIbW1tLiB3 aGF0IGhhcHBlbmVkIHRvIG91ciBpbnRlbnQtYmFzZWQgTkJJPyBUaGUgDQo+IFNETiBvZmZlcmVk IG15IFBDIGEgcGFja2V0IGludGVyZmFjZSB3aXRoIHRoZSBwcm9wZXJ0aWVzIG9mIGtub3dpbmcg DQo+IGhvdyB0byByZWNvZ25pemUgYW5kIHJvdXRlIEROUyBxdWVyaWVzIHNwZWNpYWxseSwgYW5k IGdlbmVyYWwgSVAgDQo+IGNvbm5lY3Rpdml0eS4gTXkgUEMgYWNjZXB0ZWQgdGhlIHNlcnZpY2Ug b2ZmZXIgaW1wbGljaXRseSBieSBvZmZlcmluZyANCj4gdHJhZmZpYyB0byB0aGUgZGF0YS1wbGFu ZSBpbnRlcmZhY2UuIFRoZSBuZXR3b3JrIGNvdWxkIGJlIHBlcmZvcm1pbmcgDQo+IGFzc29jaWF0 ZWQgYXV4aWxpYXJ5IHNlcnZpY2VzIHN1Y2ggYXMgdXNhZ2UtYmFzZWQgYmlsbGluZyAodGhpbmsg DQo+IHdpcmVsZXNzIHJvYW1pbmcpLCBzbyBpdCdzIG1vcmUgdGhhbiBqdXN0IGEgZHVtYiBwaXBl Lg0KPj4gSWYgdGhpcyBpcyBub3QgYSBsZWdpdGltYXRlIGV4YW1wbGUgb2YgaW50ZW50LCBpdCB3 b3VsZCBiZSBnb29kIHRvIA0KPj4gd3JpdGUNCj4gdGhlIHdoaXRlIHBhcGVyIGluIHN1Y2ggYSB3 YXkgdGhhdCBjbGVhcmx5IGV4Y2x1ZGVzIHN1Y2ggY2FzZXMuDQo+PiBVc2UgY2FzZSAyOiBzdXBw b3NlIEkgYW0gYSBjb3Jwb3JhdGUgSVQgZW1wbG95ZWUsIGFuZCBzdXBwb3NlIHRoYXQgbXkgDQo+ PiBpbnRlbnQgaXMgdG8gaGF2ZSBhbiBFLUxpbmUgYmV0d2VlbiB0d28gb2YgbXkgY2FtcGkuIEkg bmVjZXNzYXJpbHkgDQo+PiBjYXJlIGFib3V0IHBvcnRzIGFuZCBwcm90b2NvbHM7IHRhbGsgYWJv dXQgaW50ZW50IGJlaW5nIHBvcnRhYmxlIGFuZCANCj4+IHByb3RvY29sIGluZGVwZW5kZW50IGNv bnRpbnVlcyB0byBjb25mdXNlIG1lIGNvbXBsZXRlbHkuIEhvdyBjYW4gSSANCj4+IG9yZGVyIGFu IEUtbGluZSB3aXRob3V0IGNhcmluZyBhYm91dCBzdWNoIGRldGFpbHM/IFtOb3IgaXMgdGhpcyAN Cj4+IGludGVudCBwb3J0YWJsZS5dDQo+Pg0KPj4gT2J2aW91c2x5LCBhbiBTRE4gY29udHJvbGxl ciBpcyBnb2luZyB0byBleHBvc2Ugd2hhdGV2ZXIgYWN0aW9ucyBhbmQNCj4gZWxlbWVudHMgb2Yg aW5mb3JtYXRpb24gYXJlIGdlcm1hbmUgdG8gdGhlIHNlcnZpY2UgaXQgb2ZmZXJzLCBhbmQgaWYg DQo+IHBvcnRzIGFuZCBwcm90b2NvbHMgYXJlIGdlcm1hbmUgdG8gdGhlIHNlcnZpY2UsIHNvIGJl IGl0Lg0KPj4gVGhlIFNETiBhcmNoaXRlY3R1cmUsIGJlaW5nIHJlY3Vyc2l2ZSwgbW9kZWxzIHRo ZSBub3J0aCBzaWRlIG9mIGFueQ0KPiBjb250cm9sbGVyIGFzIGV4cG9zaW5nIGFuIGluc3RhbmNl IG9mIGFuIGluZm9ybWF0aW9uIG1vZGVsLCBjdXN0b21pemVkIA0KPiBmb3IgdGhlIGludGVuZGVk IGNsaWVudC9jdXN0b21lci9hcHAvdXNlci4gVGhhdCBiZWluZyB0aGUgY2FzZSwgaG93IGRvIA0K PiB3ZSBkaXN0aW5ndWlzaCBhbiBOQkkgQVBJIHRoYXQgY29udmV5cyBpbnRlbnQgKHNlcnZpY2U6 IHNhbWUgdGhpbmc/KSANCj4gZnJvbSBvbmUgdGhhdCBkb2VzIG5vdD8NCj4+IEkgaGF2ZSByZWNl bnRseSBjb21lIHRvIHRoZSB2aWV3IHRoYXQgZ3JhbnVsYXJpdHkgaXMgdGhlIGNyaXRlcmlvbiBi eQ0KPiB3aGljaCBhbiBpbnRlbnQgb3Igc2VydmljZSBpbnZvY2F0aW9uIGlzIGRpc3Rpbmd1aXNo ZWQuIENvbGxvcXVpYWxseSANCj4gc3BlYWtpbmcsIGEgc2VydmljZSBpbnZvY2F0aW9uIGlzIGEg c2luZ2xlIGludm9jYXRpb24gYWNyb3NzIHRoZSBBUEk6IA0KPiBnaXZlIG1lIEUtTGluZS4gTm93 IG9mIGNvdXJzZSB0aGlzIHR1cm5zIGludG8gY29uc3RyYWludCBuZWdvdGlhdGlvbiwgDQo+IG9m ZmVyIGFuZCBhY2NlcHRhbmNlLCBidXQgd2hhdCBoYXBwZW5zIGFjcm9zcyB0aGUgQVBJIGlzIGVm ZmVjdGl2ZWx5IG9uZSB0cmFuc2FjdGlvbi4NCj4gSW4gY29udHJhc3QsIHdoYXQgd2UgbWlnaHQg YWdyZWUgaXMgKm5vdCogYW4gaW50ZW50IG9yIGEgc2VydmljZSBpcyANCj4gdGhlIG1hbmlwdWxh dGlvbiBvZiBhIGdyYW51bGFyIGluZm9ybWF0aW9uIG1vZGVsLCB0aGUgZXhwbGljaXQgDQo+IHZp c2liaWxpdHkgb2YgbXVsdGlwbGUgb2JqZWN0cywgaG93IHRoZXkgYXJlIGludGVycmVsYXRlZCwg dGhlaXIgYXR0cmlidXRlcywgYW5kIHRoZSBsaWtlLg0KPj4gLiAgICAgICAgIE5ldHdvcmsgYXMg YSBzaW5nbGUgbHVtcCB2cyBzb21lIG5vbi10cml2aWFsIHRvcG9sb2d5Lg0KPj4NCj4+IC4gICAg ICAgICBDaGF1ZmZldXIgdnMgZHJpdmluZyBhIGNhci4gTGVnaXRpbWF0ZSByZWFzb25zIHRvIGNo b29zZSBvbmUNCj4gb3B0aW9uIG9yIHRoZSBvdGhlciwgYnV0IHRoZSBsZXZlbCBvZiBncmFudWxh cml0eSBpcyBxdWl0ZSBkaWZmZXJlbnQuIA0KPiBTaGFsbCB3ZSBhZ3JlZSB0aGF0IGRyaXZpbmcg aXMgdG9vIGdyYW51bGFyIHRvIGJlIGNvbnNpZGVyZWQgaW50ZW50Pw0KPj4gVGhpcyBpZGVhIG9m IGdyYW51bGFyaXR5IGFuZCBkZXRhaWxlZCBvcGVyYXRpb25zIG9uIHRoZSBjb21wb25lbnRzIA0K Pj4gKHdoaWNoDQo+IG9mIGNvdXJzZSBtYXkgYmUgY29tcGxleCBlbnRpdGllcyB0aGVtc2VsdmVz LCB2aXJ0dWFsaXplZCBpbnRvIA0KPiBzaW1wbGUtYXBwZWFyaW5nIGx1bXBzKSBzZWVtcyB0byBt ZSB0byBjYXB0dXJlIHRoZSBlc3NlbmNlIG9mIHdoYXQgDQo+IHBlb3BsZSBhcmUgdGFsa2luZyBh Ym91dCB3aGVuIHRoZXkgc2F5IGludGVudCBvciBzZXJ2aWNlLiBJIGFtIG5vdCANCj4gY29tZm9y dGFibGUgd2l0aCB0aGUgd2F5IEkgYW0gZXhwcmVzc2luZyBpdCwgc28gaWYgdGhpcyBpcyBhIHN0 ZXAgaW4gYSANCj4gcHJvZHVjdGl2ZSBkaXJlY3Rpb24sIG9yIGV2ZW4gaWYgaXQncyBub3QsIEkg d2VsY29tZSBzdWdnZXN0aW9ucyB0byBjbGFyaWZ5IHRoZSBjb25jZXB0Lg0KPj4gRGF2ZQ0KPj4N Cj4+IEZyb206IHNkbiBbbWFpbHRvOnNkbi1ib3VuY2VzQGlydGYub3JnXSBPbiBCZWhhbGYgT2Yg U3VzYW4gSGFyZXMNCj4+IFNlbnQ6IFNhdHVyZGF5LCBNYXkgMzAsIDIwMTUgMTowMiBQTQ0KPj4g VG86IHNkbkBpcnRmLm9yZw0KPj4gQ2M6ICdaaG91dGlhbnJhbic7ICdYaWF5aW5iZW4nOyBpYm5l bW9AaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFtTZG5dIERlZmluaW5nIGEgQ29tbW9uIE1vZGVsIGZv ciBpbnRlbnQNCj4+DQo+PiBPbiB0aGlzIG1haWwgbGlzdCwgdGhlcmUgaGFzIGJlZW4gYSBkaXNj dXNzaW9uIG9mIHR3byB0eXBlcyBvZiANCj4+IGluZm9ybWF0aW9uDQo+IGZvciBJbnRlbnQgYW5k IE5lbW86DQo+IChodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2RuL2N1cnJl bnQvbXNnMDA2NDYuaHRtbCkgOg0KPj4gMSkgICAgICBXaGF0IGluZm9ybWF0aW9uIGlzIG5lZWRl ZCB0byByZXByZXNlbnQgYSBzZXJ2aWNlIHJlcXVlc3QsDQo+PiAyKSAgICAgIEhvdyB0byByZXBy ZXNlbnQgYW5kIHRyYW5zcG9ydCB0aGUgaW5mb3JtYXRpb24gZm9yIGEgcmVxdWVzdC4NCj4+DQo+ PiBJbiBvcmRlciB0byBkZWZpbmUgd2hhdCBpbmZvcm1hdGlvbiBpcyBuZWVkZWQgdG8gcmVwcmVz ZW50IGEgMSkgDQo+PiBzZXJ2aWNlDQo+IHJlcXVlc3QgdGhhdCBzaWduYWxzIEludGVudCBmcm9t IGFuIGFwcGxpY2F0aW9uIHRvIGEgY29udHJvbGxlciwgaXQgaXMgDQo+IGltcG9ydGFudCB0byBk ZWZpbmUgSW50ZW50LCBhbmQgcHJvdmlkZSBhIGNsZWFyIG1vZGVsIG9mIEludGVudC4gIA0KPiBB bHNvLCBpbiBkZXNjcmliaW5nIHJlYWwgdXNlLWNhc2VzIGl0IGlzIGltcG9ydGFudCB0aGF0IG9u ZSB1c2VzIHRoZSANCj4gc2FtZSBkZWZpbml0aW9uIGFuZCBtb2RlbCBmb3IgSW50ZW50IGluIGVh Y2ggdXNlIGNhc2UuDQo+PiBJbiB0aGUgY3VycmVudCBmb3J1bXMgZXhhbWluaW5nIEludGVudCAo T0RMIE5JQywgT0RMIE5lbW8sIE9GIE5CSSBhbmQNCj4gS2V5c3RvbmUsIE9QTkZWIE1vdmllLCBP cGVuU3RhY2spIHRoZXJlIGlzIGEgcmVhbGl6YXRpb24gdGhhdCBJbnRlbnQgDQo+IG9jY3VycyBh dCBtdWx0aXBsZSBsYXllcnMuICBUaGUgYXV0aG9ycyBvZiBkcmFmdC14aWEtaWJuZW1vLWljaW0g aGF2ZSANCj4gY3JlYXRlZCBhIGRlZmluaXRpb24gZm9yIGludGVudCBhbmQgYSB1bmlmaWVkIG1v ZGVsIGZvciBkZWZpbmluZyANCj4gaW50ZW50IHdoaWNoIGNhbiBoYW5kbGUgMSBvciBtdWx0aXBs ZSBsYXllcnMuIFRoZSBtb2RlbCBzdWdnZXN0IHRoYXQ6DQo+PiAxKSAgICAgIEEgdXNlciBoYXMg YSBpbnRlbnQgdGhhdCBpcyBleHByZXNzZWQgaW4gYSBjb250ZXh0Lg0KPj4gMikgICAgICBJbnRl bnQgKHVzdWFsbHkpIGludm9sdmVzIGFuIG9iamVjdCB3aXRoIGEgcmVzdWx0LCBhbmQgb3B0aW9u YWxseQ0KPiBpbmNsdWRlcyBvcGVyYXRpb25zIHRvd2FyZCB0aGF0IHJlc3VsdC4NCj4+IDMpICAg ICAgT3BlcmF0aW9ucyBjb25kaXRpb25zIHBlcmZvcm0gYWN0aW9ucyB3aXRoaW4vbW9kaWZpZWQg YnkNCj4gY29uc3RyYWludHMuDQo+PiBXZSBiZWxpZXZlIHRoaXMgZGVmaW5lcyBjbGVhcmx5IHdo YXQgb3RoZXJzIGFyZSBjYWxsaW5nICJwdXJlIGludGVudCINCj4gKG9iamVjdHMgKyByZXN1bHRz KSB2ZXJzdXMgImNvbnN0cmFpbmVkIGludGVudCIgKG9iamVjdHMgKyBvcGVyYXRpb25zICsNCj4g Y29uc3RyYWludHMpLiAgIFRoZSBkcmFmdCBjYW4gYmUgZm91bmQgYXQ6DQo+IGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXhpYS1pYm5lbW8taWNpbS8gLiAgIFRoZSBhdXRo b3JzIGFyZQ0KPiBsb29raW5nIGZvciBmZWVkYmFjayBvbiB0aGUgY29uY2VwdHMgaW4gdGhlIGRy YWZ0Lg0KPj4gU3VlIEhhcmVzDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+IHNkbiBtYWlsaW5nIGxpc3QNCj4+IHNkbkBpcnRmLm9yZw0K Pj4gaHR0cHM6Ly93d3cuaXJ0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZG4NCj4+DQo+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gSWJuZW1vIG1h aWxpbmcgbGlzdA0KPj4gSWJuZW1vQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2libmVtbw0KPj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gc2RuIG1haWxpbmcgbGlzdA0KPiBzZG5AaXJ0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaXJ0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZG4NCj4NCj4NCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklibmVtbyBtYWls aW5nIGxpc3QNCklibmVtb0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9pYm5lbW8NCg== From nobody Fri Jun 5 12:08:06 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64A551A6FF2 for ; Fri, 5 Jun 2015 12:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.455 X-Spam-Level: X-Spam-Status: No, score=-98.455 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, J_CHICKENPOX_12=0.6, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fyz7k207_7TT for ; Fri, 5 Jun 2015 12:08:00 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id EA9341A6FFF for ; Fri, 5 Jun 2015 12:07:59 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.80.157; From: "Susan Hares" To: "'PEDRO ANDRES ARANDA GUTIERREZ'" , "'Zhoutianran'" , "'Bert Wijnen \(IETF\)'" , "'STUART VENTERS'" , References: <00f301d09b13$79cc2410$6d646c30$@ndzh.com> <8D15A2BAF93E9C49AB037A0647E5FA643F8490D8@eusaamb105.ericsson.se> <865C20BAAE8BBD4C89E7D6FE694F6B3B2D3CA540@nkgeml505-mbs.china.huawei.com> <8D15A2BAF93E9C49AB037A0647E5FA643F84AAA2@eusaamb105.ericsson.se> <1220E2C537595D439C5D026E83751866C42AC2FF@ex-mb3.corp.adtran.com> <556EFC42.9040208@bwijnen.net> <001201d09ed8$f7c6f480$e754dd80$@ndzh.com> In-Reply-To: Date: Fri, 5 Jun 2015 15:08:01 -0400 Message-ID: <032001d09fc2$f1bc84c0$d5358e40$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGjwAWNbhwtlPLyYWaj2K7LZAyOCALTOOmfAi4Fw8QBCozw2wFJpHEeAtftGdUDX4EdNAL46qhHAnWQGywB1uShg51RczrA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: ibnemo@ietf.org Subject: Re: [Sdn] [Ibnemo] Defining a Common Model for intent X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 19:08:03 -0000 Pedro:=20 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. =20 Intent =3D=3D: object (constraint), result (constraint), constraint = (constraint).=20 Where the role's constraint actually impacts what possible objects, = results or constraints an intent has.=20 Sue=20 -----Original Message----- From: PEDRO ANDRES ARANDA GUTIERREZ = [mailto:pedroa.aranda@telefonica.com]=20 Sent: Friday, June 05, 2015 2:03 AM To: Susan Hares; 'Zhoutianran'; 'Bert Wijnen (IETF)'; 'STUART VENTERS'; = sdn@irtf.org Cc: ibnemo@ietf.org 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? Just a bit of philosophy I fear :-) /PA --- Dr. Pedro A. Aranda Guti=C3=A9rrez Technology Exploration - Network Innovation & Virtualisation email: pedroa d0t aranda At telefonica d0t com Telef=C3=B3nica, = Investigaci=C3=B3n y Desarrollo C/ D. Ram=C3=B3n 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" escribi=C3=B3: >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:sdn-bounces@irtf.org] On Behalf Of Zhoutianran >Sent: Thursday, June 04, 2015 8:27 AM >To: Bert Wijnen (IETF); STUART VENTERS; sdn@irtf.org >Cc: ibnemo@ietf.org >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=20 >different types of intent that fit with the specific role, right?" >Could you give more information on this? > >Best, >Terence > >________________________________________ >=E5=8F=91=E4=BB=B6=E4=BA=BA: Bert Wijnen (IETF) [bwietf@bwijnen.net] >=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2015=E5=B9=B46=E6=9C=883=E6=97=A5 = 21:08 >=E6=94=B6=E4=BB=B6=E4=BA=BA: Zhoutianran; STUART VENTERS; sdn@irtf.org >=E6=8A=84=E9=80=81: ibnemo@ietf.org >=E4=B8=BB=E9=A2=98: Re: [Ibnemo] [Sdn] Defining a Common Model for = intent > >Hi all, > >I like the idea of (at least for now) stick to the problem of "intent"=20 >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=20 >then see if we want to go at more layers. > >A role -based intent model? I guess it would just boil down in=20 >different types of intent that fit with the specific role, right? > >Bert > > >On 03/06/15 11:44, Zhoutianran wrote: >> 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=20 >> relative >detailed description in my "role based intent" email. >> I think the essential of the role based intent is that there is only=20 >> one >intent layer which is always on the top. Intent is dedicated for=20 >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:sdn-bounces@irtf.org] On Behalf Of STUART VENTERS >> Sent: Wednesday, June 03, 2015 12:06 AM >> To: sdn@irtf.org >> Cc: 'Dave Hood'; ibnemo@ietf.org; Lifengkai (Fengkai); Zhoutianran;=20 >> 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=20 >> use this product from this vendor Sales Person says: Here is the=20 >> price and priority >> Partitioner: divides the end to end circuit among administrative=20 >> domains >> Planner: picks the necessary resources to use, makes the truck rolls=20 >> happen >> Allocator: allocates the necessary bandwidth >> Provisioner: decides what provisioning is necessary in each part of=20 >> 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=20 >> 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=20 >> for >refinement. >> >> That said, the data model for intent might/should be different at=20 >> each >level. >> Since each level is processing the same request at different levels=20 >> 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=20 >> forwarding >engines, except distributed. >> >> Perhaps a simple starting point near the top is a combination of=20 >>entities, >endpoints, and connections. >> >> >> Regards, >> >> Stuart Venters >> >> >> >> >> >> >> >> From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of Dave Hood >> Sent: Tuesday, June 02, 2015 8:26 AM >> To: Lifengkai (Fengkai); Susan Hares; sdn@irtf.org >> Cc: Zhoutianran; Xiayinben; ibnemo@ietf.org >> Subject: Re: [Sdn] Defining a Common Model for intent >> >> I agree that the context matters, Fengkai (and Susan in earlier=20 >>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=20 >root of my question from the beginning: how would we know what is *not* = >intent? >> >> If I ask for some particular microscopically detailed configuration=20 >> (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=20 >>protocols >and ports, and that it need not be portable. Your response about=20 >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=20 >the marketing people? >> >> Dave >> >> From: Lifengkai (Fengkai) [mailto:lifengkai@huawei.com] >> Sent: Tuesday, June 02, 2015 12:47 AM >> To: Dave Hood; Susan Hares; sdn@irtf.org >> Cc: Zhoutianran; Xiayinben; ibnemo@ietf.org >> Subject: RE: [Sdn] Defining a Common Model for intent >> >> Hi Dave and all, >> >> Thanks for proposing the two valuable intent use cases. >> >> For the use case 2, I agree that the IT employee needs to include the >details of ports/protocols into his/her intent descriptions, but those=20 >may not be in the intent context scope of a non-IT employee. Have a=20 >further consideration with this, different users of the network have=20 >their own intent in a specific domain. Then the roles/actors of network = >users, such as end users, application developers, tenant IT/network=20 >administrators, operator network administrators, are valuable to be=20 >identified and distinguished, thus fitting the intent requirements of=20 >the network users with different roles. >> >> Any thoughts about this consideration? >> >> >> Best Regards, >> Fengkai >> >> From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of Dave Hood >> Sent: Tuesday, June 02, 2015 1:38 AM >> To: Susan Hares; sdn@irtf.org >> Cc: Zhoutianran; Xiayinben; ibnemo@ietf.org >> Subject: Re: [Sdn] Defining a Common Model for intent >> >> An excerpt from an email I sent on the ONF NBI list, which may=20 >> contain >some useful thoughts: >> >> I have always had trouble understanding what an intent really is, so=20 >>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=20 >>whatever >that link offers. Completely below the surface is a layer stack,=20 >on-demand session establishment, DNS look-ups, server load balancers,=20 >and any number of other technological features that are of no interest=20 >to me. Why not use that as an example of intent? >> >> Better yet, we talk about negotiation and selection. Suppose I want=20 >>to buy >a widget. I probably already have some idea whether I want to go to=20 >Amazon or EBay or somewhere else. Suppose it's Amazon. I search=20 >Amazon's catalog and receive an offer of several widgets, some new,=20 >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=20 >Best Buy or EBay (lots more hidden technology to make that happen!).=20 >Maybe I come back to the Amazon page, having found nothing I liked=20 >better somewhere else. Now I accept one of the offered widgets and go=20 >through the checkout process. >> >> Do we agree that this is a fairly pure expression of intent as=20 >> 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=20 >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=20 >concerned, the client makes DNS queries and swaps opaque TCP packets=20 >over a forwarding path that may already exist, or may need to be=20 >learned and set up on demand. This is about right, because the session=20 >content may well be encrypted end to end, and rightly. >> >> To the SDN controller, my intent is satisfied by directing DNS=20 >>queries to >a known DNS server somewhere, and ensuring IP connectivity for the=20 >subsequent session. Hmmm. what happened to our intent-based NBI? The=20 >SDN offered my PC a packet interface with the properties of knowing how = >to recognize and route DNS queries specially, and general IP=20 >connectivity. My PC accepted the service offer implicitly by offering=20 >traffic to the data-plane interface. The network could be performing=20 >associated auxiliary services such as usage-based billing (think=20 >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=20 >> 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=20 >> care about ports and protocols; talk about intent being portable and=20 >> protocol independent continues to confuse me completely. How can I=20 >> order an E-line without caring about such details? [Nor is this=20 >> 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=20 >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=20 >for the intended client/customer/app/user. That being the case, how do=20 >we distinguish an NBI API that conveys intent (service: same thing?)=20 >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=20 >speaking, a service invocation is a single invocation across the API:=20 >give me E-Line. Now of course this turns into constraint negotiation,=20 >offer and acceptance, but what happens across the API is effectively=20 >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=20 >of multiple objects, how they are interrelated, their attributes, and=20 >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=20 >>(which >of course may be complex entities themselves, virtualized into=20 >simple-appearing lumps) seems to me to capture the essence of what=20 >people are talking about when they say intent or service. I am not=20 >comfortable with the way I am expressing it, so if this is a step in a=20 >productive direction, or even if it's not, I welcome suggestions to=20 >clarify the concept. >> >> Dave >> >> From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of Susan Hares >> Sent: Saturday, May 30, 2015 1:02 PM >> To: sdn@irtf.org >> Cc: 'Zhoutianran'; 'Xiayinben'; ibnemo@ietf.org >> Subject: [Sdn] Defining a Common Model for intent >> >> On this mail list, there has been a discussion of two types of=20 >>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)=20 >> service >request that signals Intent from an application to a controller, it is=20 >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=20 >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=20 >occurs at multiple layers. The authors of draft-xia-ibnemo-icim have=20 >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 >> >> _______________________________________________ >> sdn mailing list >> sdn@irtf.org >> https://www.irtf.org/mailman/listinfo/sdn >> >> _______________________________________________ >> Ibnemo mailing list >> Ibnemo@ietf.org >> https://www.ietf.org/mailman/listinfo/ibnemo >> >_______________________________________________ >sdn mailing list >sdn@irtf.org >https://www.irtf.org/mailman/listinfo/sdn > >_______________________________________________ >Ibnemo mailing list >Ibnemo@ietf.org >https://www.ietf.org/mailman/listinfo/ibnemo ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, = puede contener informaci=C3=B3n 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=C3=B3n, divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3n puede = estar prohibida en virtud de la legislaci=C3=B3n vigente. Si ha recibido = este mensaje por error, le rogamos que nos lo comunique inmediatamente = por esta misma v=C3=ADa y proceda a su destrucci=C3=B3n. 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=C3=A1rio, pode conter informa=C3=A7=C3=A3o privilegiada ou = confidencial e =C3=A9 para uso exclusivo da pessoa ou entidade de = destino. Se n=C3=A3o =C3=A9 vossa senhoria o destinat=C3=A1rio indicado, = fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, = divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem autoriza=C3=A7=C3=A3o pode = estar proibida em virtude da legisla=C3=A7=C3=A3o vigente. Se recebeu = esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente = por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o From nobody Fri Jun 5 12:50:48 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A30551A886F for ; Fri, 5 Jun 2015 12:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.605 X-Spam-Level: X-Spam-Status: No, score=-96.605 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gy9n28Pi57dH for ; Fri, 5 Jun 2015 12:50:43 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id F37161A8902 for ; Fri, 5 Jun 2015 12:50:42 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.80.157; From: "Susan Hares" To: "'Zhoutianran'" , "'Bert Wijnen \(IETF\)'" , "'STUART VENTERS'" , References: <00f301d09b13$79cc2410$6d646c30$@ndzh.com> <8D15A2BAF93E9C49AB037A0647E5FA643F8490D8@eusaamb105.ericsson.se> <865C20BAAE8BBD4C89E7D6FE694F6B3B2D3CA540@nkgeml505-mbs.china.huawei.com> <8D15A2BAF93E9C49AB037A0647E5FA643F84AAA2@eusaamb105.ericsson.se> <1220E2C537595D439C5D026E83751866C42AC2FF@ex-mb3.corp.adtran.com> , <556EFC42.9040208@bwijnen.net> <5570700D.7000604@bwijnen.net> In-Reply-To: Date: Fri, 5 Jun 2015 15:50:45 -0400 Message-ID: <036701d09fc8$ea231e30$be695a90$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGjwAWNbhwtlPLyYWaj2K7LZAyOCALTOOmfAi4Fw8QBCozw2wFJpHEeAtftGdUDX4EdNAL46qhHAw8/V8UCswExAp1F0HXA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: ibnemo@ietf.org Subject: Re: [Sdn] [Ibnemo] Defining a Common Model for intent X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 19:50:46 -0000 Bert and Tianran: I believe that you are stating regarding the definition:=20 Intent =3D=3D (defines) object, result, constraint=20 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=20 -----Original Message----- From: Ibnemo [mailto:ibnemo-bounces@ietf.org] On Behalf Of Zhoutianran Sent: Friday, June 05, 2015 2:42 AM To: Bert Wijnen (IETF); STUART VENTERS; sdn@irtf.org Cc: ibnemo@ietf.org Subject: Re: [Ibnemo] [Sdn] Defining a Common Model for intent 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:bwietf@bwijnen.net] Sent: Thursday, June 04, 2015 11:35 PM To: Zhoutianran; STUART VENTERS; sdn@irtf.org Cc: ibnemo@ietf.org Subject: Re: [Ibnemo] [Sdn] Defining a Common Model for intent On 04/06/15 14:26, Zhoutianran wrote: > 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? 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 > Best, > Terence > > ________________________________________ > =B7=A2=BC=FE=C8=CB: Bert Wijnen (IETF) [bwietf@bwijnen.net] > =B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA6=D4=C23=C8=D5 21:08 > =CA=D5=BC=FE=C8=CB: Zhoutianran; STUART VENTERS; sdn@irtf.org > =B3=AD=CB=CD: ibnemo@ietf.org > =D6=F7=CC=E2: Re: [Ibnemo] [Sdn] Defining a Common Model for intent > > 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=20 > 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=20 > different types of intent that fit with the specific role, right? > > Bert > > > On 03/06/15 11:44, Zhoutianran wrote: >> 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:sdn-bounces@irtf.org] On Behalf Of STUART VENTERS >> Sent: Wednesday, June 03, 2015 12:06 AM >> To: sdn@irtf.org >> Cc: 'Dave Hood'; ibnemo@ietf.org; Lifengkai (Fengkai); Zhoutianran;=20 >> 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=20 >> use this product from this vendor Sales Person says: Here is the=20 >> price and priority >> Partitioner: divides the end to end circuit among administrative=20 >> domains >> Planner: picks the necessary resources to use, makes the truck rolls=20 >> happen >> Allocator: allocates the necessary bandwidth >> Provisioner: decides what provisioning is necessary in each part of=20 >> 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 >> >> >> >> >> >> >> >> From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of Dave Hood >> Sent: Tuesday, June 02, 2015 8:26 AM >> To: Lifengkai (Fengkai); Susan Hares; sdn@irtf.org >> Cc: Zhoutianran; Xiayinben; ibnemo@ietf.org >> 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 >> >> From: Lifengkai (Fengkai) [mailto:lifengkai@huawei.com] >> Sent: Tuesday, June 02, 2015 12:47 AM >> To: Dave Hood; Susan Hares; sdn@irtf.org >> Cc: Zhoutianran; Xiayinben; ibnemo@ietf.org >> Subject: RE: [Sdn] Defining a Common Model for intent >> >> Hi Dave and all, >> >> Thanks for proposing the two valuable intent use cases. >> >> For the use case 2, I agree that the IT employee needs to include the details of ports/protocols into his/her intent descriptions, but those = may not be in the intent context scope of a non-IT employee. Have a further consideration with this, different users of the network have their own intent in a specific domain. Then the roles/actors of network users, = such as end users, application developers, tenant IT/network administrators, operator network administrators, are valuable to be identified and distinguished, thus fitting the intent requirements of the network users with different roles. >> >> Any thoughts about this consideration? >> >> >> Best Regards, >> Fengkai >> >> From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of Dave Hood >> Sent: Tuesday, June 02, 2015 1:38 AM >> To: Susan Hares; sdn@irtf.org >> Cc: Zhoutianran; Xiayinben; ibnemo@ietf.org >> 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=20 >> 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=20 >> care about ports and protocols; talk about intent being portable and=20 >> protocol independent continues to confuse me completely. How can I=20 >> order an E-line without caring about such details? [Nor is this=20 >> 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:sdn-bounces@irtf.org] On Behalf Of Susan Hares >> Sent: Saturday, May 30, 2015 1:02 PM >> To: sdn@irtf.org >> Cc: 'Zhoutianran'; 'Xiayinben'; ibnemo@ietf.org >> 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 >> >> _______________________________________________ >> sdn mailing list >> sdn@irtf.org >> https://www.irtf.org/mailman/listinfo/sdn >> >> _______________________________________________ >> Ibnemo mailing list >> Ibnemo@ietf.org >> https://www.ietf.org/mailman/listinfo/ibnemo > > _______________________________________________ Ibnemo mailing list Ibnemo@ietf.org https://www.ietf.org/mailman/listinfo/ibnemo From nobody Fri Jun 5 12:54:10 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0949E1A8903 for ; Fri, 5 Jun 2015 12:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.766 X-Spam-Level: X-Spam-Status: No, score=-92.766 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, DOS_OUTLOOK_TO_MX=2.845, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnifhFVzO6DS for ; Fri, 5 Jun 2015 12:54:06 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id C49851A890A for ; Fri, 5 Jun 2015 12:54:05 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.80.157; From: "Susan Hares" To: "'Xiayinben'" , "'Bert Wijnen \(IETF\)'" , "'Zhoutianran'" , "'STUART VENTERS'" , References: <00f301d09b13$79cc2410$6d646c30$@ndzh.com> <8D15A2BAF93E9C49AB037A0647E5FA643F8490D8@eusaamb105.ericsson.se> <865C20BAAE8BBD4C89E7D6FE694F6B3B2D3CA540@nkgeml505-mbs.china.huawei.com> <8D15A2BAF93E9C49AB037A0647E5FA643F84AAA2@eusaamb105.ericsson.se> <1220E2C537595D439C5D026E83751866C42AC2FF@ex-mb3.corp.adtran.com> , <556EFC42.9040208@bwijnen.net> <001201d09ed8$f7c6f480$e754dd80$@ndzh.com> <55706F7C.9080300@bwijnen.net> <5FD31D8EDBF4EC468B36D86F04FDB2E873829CC6@nkgeml507-mbs.china.huawei.com> In-Reply-To: <5FD31D8EDBF4EC468B36D86F04FDB2E873829CC6@nkgeml507-mbs.china.huawei.com> Date: Fri, 5 Jun 2015 15:54:06 -0400 Message-ID: <037601d09fc9$61971ac0$24c55040$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGjwAWNbhwtlPLyYWaj2K7LZAyOCALTOOmfAi4Fw8QBCozw2wFJpHEeAtftGdUDX4EdNAL46qhHAnWQGywB6AaNCAKeoBgGnTwCTgA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: ibnemo@ietf.org Subject: Re: [Sdn] =?gb2312?b?W0libmVtb10gtPC4tDogICAgIERlZmluaW5nIGEgQ29tbW9u?= =?gb2312?b?IE1vZGVsIGZvciBpbnRlbnQ=?= X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 19:54:09 -0000 Yinben:=20 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.=20 Sue=20 -----Original Message----- From: Ibnemo [mailto:ibnemo-bounces@ietf.org] On Behalf Of Xiayinben Sent: Friday, June 05, 2015 9:11 AM To: Bert Wijnen (IETF); Susan Hares; Zhoutianran; 'STUART VENTERS'; sdn@irtf.org Cc: ibnemo@ietf.org Subject: [Ibnemo] =B4=F0=B8=B4: [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 -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: Ibnemo [mailto:ibnemo-bounces@ietf.org] =B4=FA=B1=ED = Bert Wijnen (IETF) =B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA6=D4=C24=C8=D5 23:32 =CA=D5=BC=FE=C8=CB: Susan Hares; Zhoutianran; 'STUART VENTERS'; = sdn@irtf.org =B3=AD=CB=CD: ibnemo@ietf.org =D6=F7=CC=E2: Re: [Ibnemo] [Sdn] Defining a Common Model for intent On 04/06/15 17:13, Susan Hares wrote: > Bert and Tianran: > > If you link intent to role, I believe your diagram is: > > 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 > I think role takes on an aspect of context. What do you think? > > Sue > > -----Original Message----- > From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of Zhoutianran > Sent: Thursday, June 04, 2015 8:27 AM > To: Bert Wijnen (IETF); STUART VENTERS; sdn@irtf.org > Cc: ibnemo@ietf.org > 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=20 > different types of intent that fit with the specific role, right?" > Could you give more information on this? > > Best, > Terence > > ________________________________________ > =B7=A2=BC=FE=C8=CB: Bert Wijnen (IETF) [bwietf@bwijnen.net] > =B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA6=D4=C23=C8=D5 21:08 > =CA=D5=BC=FE=C8=CB: Zhoutianran; STUART VENTERS; sdn@irtf.org > =B3=AD=CB=CD: ibnemo@ietf.org > =D6=F7=CC=E2: Re: [Ibnemo] [Sdn] Defining a Common Model for intent > > 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=20 > we are successful in doing a model for IBNEMO for the top layer, we=20 > can then see if we want to go at more layers. > > A role -based intent model? I guess it would just boil down in=20 > different types of intent that fit with the specific role, right? > > Bert > > > On 03/06/15 11:44, Zhoutianran wrote: >> 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=20 >> relative > detailed description in my "role based intent" email. >> I think the essential of the role based intent is that there is only=20 >> one > intent layer which is always on the top. Intent is dedicated for=20 > 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:sdn-bounces@irtf.org] On Behalf Of STUART VENTERS >> Sent: Wednesday, June 03, 2015 12:06 AM >> To: sdn@irtf.org >> Cc: 'Dave Hood'; ibnemo@ietf.org; Lifengkai (Fengkai); Zhoutianran;=20 >> 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=20 >> use this product from this vendor Sales Person says: Here is the=20 >> price and priority >> Partitioner: divides the end to end circuit among administrative=20 >> domains >> Planner: picks the necessary resources to use, makes the truck rolls=20 >> happen >> Allocator: allocates the necessary bandwidth >> Provisioner: decides what provisioning is necessary in each part of=20 >> 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=20 >> 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=20 >> for > refinement. >> That said, the data model for intent might/should be different at=20 >> each > level. >> Since each level is processing the same request at different levels=20 >> 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=20 >> forwarding > engines, except distributed. >> Perhaps a simple starting point near the top is a combination of=20 >> entities, > endpoints, and connections. >> >> Regards, >> >> Stuart Venters >> >> >> >> >> >> >> >> From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of Dave Hood >> Sent: Tuesday, June 02, 2015 8:26 AM >> To: Lifengkai (Fengkai); Susan Hares; sdn@irtf.org >> Cc: Zhoutianran; Xiayinben; ibnemo@ietf.org >> 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=20 > NBI is > intent: otherwise the app/tenant/customer wouldn't do it. That's the=20 > root of my question from the beginning: how would we know what is = *not* intent? >> If I ask for some particular microscopically detailed configuration=20 >> (a > "how"), it's because I care, for some reason, about that level of=20 > detail. It is in fact part of my intent. >> In my IT example, I argue that intent need not be independent of=20 >> protocols > and ports, and that it need not be portable. Your response about=20 > 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=20 > buzzword, which it certainly appears to be, can we just say so and=20 > leave it to the marketing people? >> Dave >> >> From: Lifengkai (Fengkai) [mailto:lifengkai@huawei.com] >> Sent: Tuesday, June 02, 2015 12:47 AM >> To: Dave Hood; Susan Hares; sdn@irtf.org >> Cc: Zhoutianran; Xiayinben; ibnemo@ietf.org >> Subject: RE: [Sdn] Defining a Common Model for intent >> >> Hi Dave and all, >> >> Thanks for proposing the two valuable intent use cases. >> >> For the use case 2, I agree that the IT employee needs to include the > details of ports/protocols into his/her intent descriptions, but those = > may not be in the intent context scope of a non-IT employee. Have a=20 > further consideration with this, different users of the network have=20 > their own intent in a specific domain. Then the roles/actors of=20 > network users, such as end users, application developers, tenant=20 > IT/network administrators, operator network administrators, are=20 > valuable to be identified and distinguished, thus fitting the intent=20 > requirements of the network users with different roles. >> Any thoughts about this consideration? >> >> >> Best Regards, >> Fengkai >> >> From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of Dave Hood >> Sent: Tuesday, June 02, 2015 1:38 AM >> To: Susan Hares; sdn@irtf.org >> Cc: Zhoutianran; Xiayinben; ibnemo@ietf.org >> Subject: Re: [Sdn] Defining a Common Model for intent >> >> An excerpt from an email I sent on the ONF NBI list, which may=20 >> contain > some useful thoughts: >> I have always had trouble understanding what an intent really is, so=20 >> 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=20 >> whatever > that link offers. Completely below the surface is a layer stack,=20 > on-demand session establishment, DNS look-ups, server load balancers,=20 > 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=20 >> to buy > a widget. I probably already have some idea whether I want to go to=20 > Amazon or EBay or somewhere else. Suppose it's Amazon. I search=20 > Amazon's catalog and receive an offer of several widgets, some new,=20 > 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=20 > 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=20 >> 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=20 > software local to my PC, but I don't think we can call the PC an SDN=20 > controller. It's more an active mediator, a client to an SDN. As far=20 > as the network is concerned, the client makes DNS queries and swaps=20 > opaque TCP packets over a forwarding path that may already exist, or=20 > may need to be learned and set up on demand. This is about right,=20 > because the session content may well be encrypted end to end, and = rightly. >> To the SDN controller, my intent is satisfied by directing DNS=20 >> queries to > a known DNS server somewhere, and ensuring IP connectivity for the=20 > subsequent session. Hmmm. what happened to our intent-based NBI? The=20 > SDN offered my PC a packet interface with the properties of knowing=20 > how to recognize and route DNS queries specially, and general IP=20 > connectivity. My PC accepted the service offer implicitly by offering=20 > traffic to the data-plane interface. The network could be performing=20 > associated auxiliary services such as usage-based billing (think=20 > 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=20 >> 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=20 >> care about ports and protocols; talk about intent being portable and=20 >> protocol independent continues to confuse me completely. How can I=20 >> order an E-line without caring about such details? [Nor is this=20 >> 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=20 > 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?)=20 > 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=20 > speaking, a service invocation is a single invocation across the API: > give me E-Line. Now of course this turns into constraint negotiation,=20 > 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=20 > the manipulation of a granular information model, the explicit=20 > 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.=20 > Shall we agree that driving is too granular to be considered intent? >> This idea of granularity and detailed operations on the components=20 >> (which > of course may be complex entities themselves, virtualized into=20 > simple-appearing lumps) seems to me to capture the essence of what=20 > people are talking about when they say intent or service. I am not=20 > 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:sdn-bounces@irtf.org] On Behalf Of Susan Hares >> Sent: Saturday, May 30, 2015 1:02 PM >> To: sdn@irtf.org >> Cc: 'Zhoutianran'; 'Xiayinben'; ibnemo@ietf.org >> Subject: [Sdn] Defining a Common Model for intent >> >> On this mail list, there has been a discussion of two types of=20 >> 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)=20 >> 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=20 > 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=20 > occurs at multiple layers. The authors of draft-xia-ibnemo-icim have=20 > created a definition for intent and a unified model for defining=20 > 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 >> >> _______________________________________________ >> sdn mailing list >> sdn@irtf.org >> https://www.irtf.org/mailman/listinfo/sdn >> >> _______________________________________________ >> Ibnemo mailing list >> Ibnemo@ietf.org >> https://www.ietf.org/mailman/listinfo/ibnemo >> > _______________________________________________ > sdn mailing list > sdn@irtf.org > https://www.irtf.org/mailman/listinfo/sdn > > _______________________________________________ Ibnemo mailing list Ibnemo@ietf.org https://www.ietf.org/mailman/listinfo/ibnemo _______________________________________________ Ibnemo mailing list Ibnemo@ietf.org https://www.ietf.org/mailman/listinfo/ibnemo From nobody Mon Jun 8 02:47:11 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2291B2E2B for ; Mon, 8 Jun 2015 02:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.139 X-Spam-Level: * X-Spam-Status: No, score=1.139 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l60CSnOJzfvL for ; Mon, 8 Jun 2015 02:47:05 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [58.251.152.64]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D96641B2E0B for ; Mon, 8 Jun 2015 02:47:03 -0700 (PDT) Received: from 172.24.2.119 (EHLO nkgeml403-hub.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CPF25841; Mon, 08 Jun 2015 17:46:20 +0800 (CST) Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.152]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Mon, 8 Jun 2015 17:46:15 +0800 From: Zhoutianran To: "Bert Wijnen (IETF)" , Susan Hares , "'STUART VENTERS'" , "sdn@irtf.org" Thread-Topic: [Sdn] [Ibnemo] Defining a Common Model for intent Thread-Index: AQHQntj52clzMhtkW0CvceozlByThZ2b83IAgAZsKWA= Date: Mon, 8 Jun 2015 09:46:15 +0000 Message-ID: References: <00f301d09b13$79cc2410$6d646c30$@ndzh.com> <8D15A2BAF93E9C49AB037A0647E5FA643F8490D8@eusaamb105.ericsson.se> <865C20BAAE8BBD4C89E7D6FE694F6B3B2D3CA540@nkgeml505-mbs.china.huawei.com> <8D15A2BAF93E9C49AB037A0647E5FA643F84AAA2@eusaamb105.ericsson.se> <1220E2C537595D439C5D026E83751866C42AC2FF@ex-mb3.corp.adtran.com> , <556EFC42.9040208@bwijnen.net> <001201d09ed8$f7c6f480$e754dd80$@ndzh.com> <55706F7C.9080300@bwijnen.net> In-Reply-To: <55706F7C.9080300@bwijnen.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.21] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "ibnemo@ietf.org" Subject: Re: [Sdn] [Ibnemo] Defining a Common Model for intent X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 09:47:09 -0000 SGkgQmVydCwNCg0KWW91IHJhaXNlZCBhIHZlcnkgaW50ZXJlc3RpbmcgdG9waWMgb24gdGhlIHVz ZXIgYW5kIHJvbGUuDQpJIHRoaW5rIHRoZSByb2xlIGdyb3VwcyBhIHNldCBvZiBpbnRlbnQuIEFu ZCB0aGUgdXNlciBpcyB0aGUgZXhhY3Qgb25lIHRvIHVzZSB0aGUgaW50ZW50LiBPbmUgdXNlciBj b3VsZCB0YWtlIHNldmVyYWwgcm9sZXMuDQpBIHF1aWNrIGV4YW1wbGUgaW4gcmVhbCB3b3JsZCwg b25lIHBlcnNvbihqdXN0IGxpa2UgbWUpIGNvdWxkIGJlIGEgZmF0aGVyKG9uZSByb2xlKSBhbmQg YSBwcm9ncmFtbWVyKGFub3RoZXIgcm9sZSkuDQoNCg0KQmVzdCwNClRlcmVuY2UNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJlcnQgV2lqbmVuIChJRVRGKSBbbWFpbHRvOmJ3 aWV0ZkBid2lqbmVuLm5ldF0gDQpTZW50OiBUaHVyc2RheSwgSnVuZSAwNCwgMjAxNSAxMTozMiBQ TQ0KVG86IFN1c2FuIEhhcmVzOyBaaG91dGlhbnJhbjsgJ1NUVUFSVCBWRU5URVJTJzsgc2RuQGly dGYub3JnDQpDYzogaWJuZW1vQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1Nkbl0gW0libmVtb10g RGVmaW5pbmcgYSBDb21tb24gTW9kZWwgZm9yIGludGVudA0KDQpPbiAwNC8wNi8xNSAxNzoxMywg U3VzYW4gSGFyZXMgd3JvdGU6DQo+IEJlcnQgYW5kIFRpYW5yYW46DQo+DQo+IElmIHlvdSBsaW5r IGludGVudCB0byByb2xlLCBJIGJlbGlldmUgeW91ciBkaWFncmFtIGlzOg0KPg0KPiBVc2VyIC0t PiBpbnRlbnQgLS0+IHJvbGUgLS0+IGNvbnRleHQNCg0KQ291bGQgYmUsIGJ1dCBpcyAidXNlciIg bm90IGEgcm9sZS4NCkkgc2VlIHJvbGVzIGFzOg0KLSB1c2VyL2VuZC11c2VyIG9yIGN1c3RvbWVy DQotIHNlcnZpY2UgcHJvdmlkZXINCi0gbmV0d29yayBhY2hpdGVjdA0KLSBuZXR3b3JrIG9wZXJh dG9yDQotIG1heWJlIGFsc28gdHJvdWJsZS1zaG9vdGVyDQoNCklzIHRoYXQgbm90IHRoZSBpZGVh Lw0KDQpCZXJ0DQpwLnMuIHdoeSBpcyB0aGlzIGNvcGllZCB0byAyIG1haWxpbmcgbGlzdHMsIHNk biBhbmQgaWJuZW1vPw0KSSB0aG91Z2h0IHRoYXQgdGhlIGludGVudC1tb2RlbGxpbmcgd29yayBp cyBpbiBpYm5lbW8sIGlmIHNvLCB0aGVuIFNETiBSRyBwZW9wbGUgd2hvIGFyZSBpbnRlcmVzdGVk IHNob3VsZCBjb21lIG92ZXJ0aGVyZS4NCk5vdyBpZiB3ZSB3ZXJlIHRhbGtpbmcgU0ROIHNwZWNp ZmljIGludGVudCBtb2RlbGxpbmcsIHRoZW4gbWF5YmUgaXQgaXMgT0ssIEJ1dCBJIHRob3VnaHQg d2UgYXJlIGRpc2N1c3NpbmcgZ2VuZXJpYyBpbnRlbnQgbW9kZWxsaW5nLCBubz8NCg0KQmVydA0K PiBJIHRoaW5rIHJvbGUgdGFrZXMgb24gYW4gYXNwZWN0IG9mIGNvbnRleHQuICAgV2hhdCBkbyB5 b3UgdGhpbms/DQo+DQo+IFN1ZQ0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBzZG4gW21haWx0bzpzZG4tYm91bmNlc0BpcnRmLm9yZ10gT24gQmVoYWxmIE9mIFpob3V0 aWFucmFuDQo+IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDA0LCAyMDE1IDg6MjcgQU0NCj4gVG86IEJl cnQgV2lqbmVuIChJRVRGKTsgU1RVQVJUIFZFTlRFUlM7IHNkbkBpcnRmLm9yZw0KPiBDYzogaWJu ZW1vQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbU2RuXSBbSWJuZW1vXSBEZWZpbmluZyBhIENv bW1vbiBNb2RlbCBmb3IgaW50ZW50DQo+DQo+IEhpIEJlcnQsDQo+DQo+IFRoYW5rcyBmb3IgeW91 IGNvbW1lbnRzLg0KPiBJIGFncmVlIHdpdGggeW91IHRoYXQgd2UnZCBiZXR0ZXIganVzdCBmb2N1 cyBvbiB0aGUgdG9wIGxheWVyLg0KPiBCdXQgSSBhbSBzb3JyeSwgd2hhdCBkbyB5b3UgbWVhbiBp biB0aGUgbGFzdCBzZW50ZW5jZT8NCj4gIkEgcm9sZSAtYmFzZWQgaW50ZW50IG1vZGVsPyBJIGd1 ZXNzIGl0IHdvdWxkIGp1c3QgYm9pbCBkb3duIGluIA0KPiBkaWZmZXJlbnQgdHlwZXMgb2YgaW50 ZW50IHRoYXQgZml0IHdpdGggdGhlIHNwZWNpZmljIHJvbGUsIHJpZ2h0PyINCj4gQ291bGQgeW91 IGdpdmUgbW9yZSBpbmZvcm1hdGlvbiBvbiB0aGlzPw0KPg0KPiBCZXN0LA0KPiBUZXJlbmNlDQo+ DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gt6K8/sjLOiBC ZXJ0IFdpam5lbiAoSUVURikgW2J3aWV0ZkBid2lqbmVuLm5ldF0NCj4gt6LLzcqxvOQ6IDIwMTXE 6jbUwjPI1SAyMTowOA0KPiDK1bz+yMs6IFpob3V0aWFucmFuOyBTVFVBUlQgVkVOVEVSUzsgc2Ru QGlydGYub3JnDQo+ILOty806IGlibmVtb0BpZXRmLm9yZw0KPiDW98ziOiBSZTogW0libmVtb10g W1Nkbl0gRGVmaW5pbmcgYSBDb21tb24gTW9kZWwgZm9yIGludGVudA0KPg0KPiBIaSBhbGwsDQo+ DQo+IEkgbGlrZSB0aGUgaWRlYSBvZiAoYXQgbGVhc3QgZm9yIG5vdykgc3RpY2sgdG8gdGhlIHBy b2JsZW0gb2YgImludGVudCIgDQo+IGZvciBvbmUgbGF5ZXIgKHRoZSB0b3AgbGF5ZXIpLg0KPiBM ZXQgdXMgbm90IGJvaWwgdGhlIG9jZWFuIGFuZCB0cnkgdG8gZG8gZXZlcnl0aGluZyB0aGF0IGNv bWVzIHVwLiBJZiANCj4gd2UgYXJlIHN1Y2Nlc3NmdWwgaW4gZG9pbmcgYSBtb2RlbCBmb3IgSUJO RU1PIGZvciB0aGUgdG9wIGxheWVyLCB3ZSANCj4gY2FuIHRoZW4gc2VlIGlmIHdlIHdhbnQgdG8g Z28gYXQgbW9yZSBsYXllcnMuDQo+DQo+IEEgcm9sZSAtYmFzZWQgaW50ZW50IG1vZGVsPyBJIGd1 ZXNzIGl0IHdvdWxkIGp1c3QgYm9pbCBkb3duIGluIA0KPiBkaWZmZXJlbnQgdHlwZXMgb2YgaW50 ZW50IHRoYXQgZml0IHdpdGggdGhlIHNwZWNpZmljIHJvbGUsIHJpZ2h0Pw0KPg0KPiBCZXJ0DQo+ DQo+DQo+IE9uIDAzLzA2LzE1IDExOjQ0LCBaaG91dGlhbnJhbiB3cm90ZToNCj4+IEhpIFN0dWFy dCwNCj4+DQo+PiBUaGFua3MgZm9yIHRoaXMgZGVlcCB0aGlua2luZyB3aXRoIGEgc2V0IG9mIGV4 YW1wbGVzLiBJdCdzIHJlYWxseQ0KPiBpbXBvcnRhbnQgdG8gY2xhcmlmeSB0aGlzIGZ1enp5IGlu dGVudC4NCj4+IEkgdGhpbmsgYWxsIHRoZSBjb25jZXJuIGFuZCB1bmNlcnRhaW50eSBpcyBiZWNh dXNlIG9mIHRoZSBsYXllcmVkDQo+IHRoaW5raW5nLiBXZSB0aGluayBpbnRlbnQgaXMgYSByZWxh dGl2ZWx5IGhpZ2hlciBsZXZlbCBuZXN0ZWQuDQo+PiBXaGF0IGlmIHdlIHRoaW5rIGFib3V0IGlu dGVudCB3aXRoIGRpZmZlcm5ldCByb2xlcz8gSnVzdCBsaWtlIGEgDQo+PiByZWxhdGl2ZQ0KPiBk ZXRhaWxlZCBkZXNjcmlwdGlvbiBpbiBteSAicm9sZSBiYXNlZCBpbnRlbnQiIGVtYWlsLg0KPj4g SSB0aGluayB0aGUgZXNzZW50aWFsIG9mIHRoZSByb2xlIGJhc2VkIGludGVudCBpcyB0aGF0IHRo ZXJlIGlzIG9ubHkgDQo+PiBvbmUNCj4gaW50ZW50IGxheWVyIHdoaWNoIGlzIGFsd2F5cyBvbiB0 aGUgdG9wLiBJbnRlbnQgaXMgZGVkaWNhdGVkIGZvciANCj4gY29ycmVzcG9uZGluZyByb2xlcy4g T25lIHJvbGUgd2lsbCBub3QgY2FsbCBvdGhlciByb2xlcyBpbnRlcmZhY2VzLg0KPj4gVGhlbiB3 ZSBjYW4gdHJ5IHRvIGZpbmQgd2F5IHRvIGV4cHJlc3MgaW50ZW50IGZvciB2YXJpb3VzIHJvbGVz Lg0KPj4NCj4+DQo+PiBSZWdhcmRzLA0KPj4gVGVyZW5jZQ0KPj4NCj4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBzZG4gW21haWx0bzpzZG4tYm91bmNlc0BpcnRmLm9yZ10g T24gQmVoYWxmIE9mIFNUVUFSVCBWRU5URVJTDQo+PiBTZW50OiBXZWRuZXNkYXksIEp1bmUgMDMs IDIwMTUgMTI6MDYgQU0NCj4+IFRvOiBzZG5AaXJ0Zi5vcmcNCj4+IENjOiAnRGF2ZSBIb29kJzsg aWJuZW1vQGlldGYub3JnOyBMaWZlbmdrYWkgKEZlbmdrYWkpOyBaaG91dGlhbnJhbjsgDQo+PiBY aWF5aW5iZW47IFN1c2FuIEhhcmVzDQo+PiBTdWJqZWN0OiBSZTogW1Nkbl0gRGVmaW5pbmcgYSBD b21tb24gTW9kZWwgZm9yIGludGVudA0KPj4NCj4+DQo+Pg0KPj4gSSBoYXZlIDIgY2VudHMgdG8g Y29udHJpYnV0ZSBmb3IgdGhpcyBmdXp6eSBpbnRlbnQgd29yZCBhbmQgcmVzdWx0aW5nIA0KPj4g ZGF0YQ0KPiBtb2RlbC4NCj4+IFBlcmhhcHMgJ2ludGVudCcgIGlzIGp1c3QgYSByZWxhdGl2ZWx5 IGhpZ2ggbGV2ZWwgc2VydmljZSByZXF1ZXN0Lg0KPj4gVGhlIHByb2JsZW0gd2l0aCB0aGlzIGRl ZmluaXRpb24gaXMgd2hhdCBpcyB0aGF0ICdyZWxhdGl2ZWx5IGhpZ2ggbGV2ZWwnDQo+IGFwcGVh cnMgdG8gZGVwZW5kIG9uIHlvdXIgcG9pbnQgb2Ygdmlldy4NCj4+IFRvIGhlbHAgdGhpbmsgYWJv dXQgaXQsIGhlcmUncyBhIGxvbmcgY2hhaW4gb2YgY29tbWFuZCBmb3IgdGhlIHNhbWUNCj4gYWN0 aW9uLg0KPj4gSXQgaXMgbG9uZyBmb3IgZnVuIGFuZCBzbyB0aGF0IGFueWJvZHkgY2FuIGZpbmQg cGFydCBvZiBpdCB0aGF0IHRoZXkNCj4gcmVjb2duaXplLg0KPj4NCj4+IENoYWluIG9mIGNvbW1h bmQ6DQo+Pg0KPj4gSW52ZXN0b3Igc2F5czogbWFrZSBtb25leQ0KPj4gQ0VPIHNheXM6IG1ha2Ug dGhlIG5ldHdvcmsgd29yaw0KPj4gQ0lPIHNheXM6IGdpdmUgbWUgYmFuZHdpZHRocyBiZXR3ZWVu IHNpdGVzIEEsIEIsIGFuZCBDIE5ldCBlbmdpbmVlcg0KPj4gc2F5czogSSBuZWVkIHRoZXNlIGV2 YydzIHRvIHRoZXNlIGVuZHBvaW50cyBQdXJjaGFzaW5nIGFnZW50OiBTYXlzIA0KPj4gdXNlIHRo aXMgcHJvZHVjdCBmcm9tIHRoaXMgdmVuZG9yIFNhbGVzIFBlcnNvbiBzYXlzOiBIZXJlIGlzIHRo ZSANCj4+IHByaWNlIGFuZCBwcmlvcml0eQ0KPj4gUGFydGl0aW9uZXI6IGRpdmlkZXMgdGhlIGVu ZCB0byBlbmQgY2lyY3VpdCBhbW9uZyBhZG1pbmlzdHJhdGl2ZSANCj4+IGRvbWFpbnMNCj4+IFBs YW5uZXI6IHBpY2tzIHRoZSBuZWNlc3NhcnkgcmVzb3VyY2VzIHRvIHVzZSwgbWFrZXMgdGhlIHRy dWNrIHJvbGxzIA0KPj4gaGFwcGVuDQo+PiBBbGxvY2F0b3I6IGFsbG9jYXRlcyB0aGUgbmVjZXNz YXJ5IGJhbmR3aWR0aA0KPj4gUHJvdmlzaW9uZXI6IGRlY2lkZXMgd2hhdCBwcm92aXNpb25pbmcg aXMgbmVjZXNzYXJ5IGluIGVhY2ggcGFydCBvZiANCj4+IHRoZSBwYXRoDQo+PiBBZGFwdG9yOiB0 YWlsb3JzIHRoZSBwcm92aXNpb25pbmcgdG8gYSBzcGVjaWZpYyBib3gNCj4+IERyaXZlcjogcHVz aGVzIHRoZSBwcm92aXNpb25pbmcgaW50byB0aGUgZm9yd2FyZGluZyB0YWJsZXMgRm9yd2FyZGlu Zw0KPj4gZW5naW5lOiBmb3J3YXJkcyBhY2NvcmRpbmcgdG8gdGhlIHRhYmxlcw0KPj4NCj4+IFRo ZSBJbnZlc3RvcidzIHN0YXRlbWVudCBhdCB0aGUgdG9wIGlzIGNsZWFybHkgd2hhdCBhbmQgbm90 IGhvdy4NCj4+IFRoZSBmb3J3YXJkaW5nIGVuZ2luZSdzIG9wZXJhdGlvbnMgaGF2ZSBhIGxvdCBv ZiBob3csIGJ1dCBtYXliZSANCj4+IGxpdHRsZQ0KPiBnbG9iYWwgdmlldyBvZiB3aGF0IHdlIGFy ZSBkb2luZyBvdmVyYWxsLg0KPj4gSWYgd2Ugc2F5IHRoYXQgdGhlIHRvcCBpcyBpbnRlbnQgYW5k IHRoZSBib3R0b20gaXMgYSBpcyBzZXJ2aWNlIHJlcXVlc3QsDQo+PiAgICAgd2hvJ3MgdG8gc2F5 IHdoZXJlIGludGVudCBzdG9wcyBhbmQgc2VydmljZSByZXF1ZXN0cyBzdGFydD8NCj4+DQo+PiBQ ZXJoYXBzICAnaW50ZW50JyBtZWFucyBhIHNlcnZpY2UgcmVxdWVzdCBjb21pbmcgZnJvbSBhIGhp Z2hlciBsYXllciANCj4+IGZvcg0KPiByZWZpbmVtZW50Lg0KPj4gVGhhdCBzYWlkLCB0aGUgZGF0 YSBtb2RlbCBmb3IgaW50ZW50IG1pZ2h0L3Nob3VsZCBiZSBkaWZmZXJlbnQgYXQgDQo+PiBlYWNo DQo+IGxldmVsLg0KPj4gU2luY2UgZWFjaCBsZXZlbCBpcyBwcm9jZXNzaW5nIHRoZSBzYW1lIHJl cXVlc3QgYXQgZGlmZmVyZW50IGxldmVscyANCj4+IG9mDQo+IGRldGFpbCwgaXQgbWlnaHQgYmUg c2ltaWxhciBhdCBlYWNoIGxldmVsLg0KPj4gUGVyaGFwcyB0aGUgZGF0YSBtb2RlbCBzdGFydHMg c2ltcGxlIG9uIHRvcCBhbmQgZ2F0aGVycyBtb3JlIGFuZCBtb3JlDQo+IGRldGFpbCBhcyBpdCBn ZXRzIGxvd2VyID8NCj4+IE1heWJlIGxpa2UgYSB0cmVlIHdpdGggdGhlIHJvb3QgYXQgdGhlIHRv cCBhbmQgbGVhdmVzIGF0IHRoZSANCj4+IGZvcndhcmRpbmcNCj4gZW5naW5lcywgZXhjZXB0IGRp c3RyaWJ1dGVkLg0KPj4gUGVyaGFwcyBhIHNpbXBsZSBzdGFydGluZyBwb2ludCBuZWFyIHRoZSB0 b3AgaXMgYSBjb21iaW5hdGlvbiBvZiANCj4+IGVudGl0aWVzLA0KPiBlbmRwb2ludHMsIGFuZCBj b25uZWN0aW9ucy4NCj4+DQo+PiBSZWdhcmRzLA0KPj4NCj4+IFN0dWFydCBWZW50ZXJzDQo+Pg0K Pj4NCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4gRnJvbTogc2RuIFttYWlsdG86c2RuLWJvdW5jZXNA aXJ0Zi5vcmddIE9uIEJlaGFsZiBPZiBEYXZlIEhvb2QNCj4+IFNlbnQ6IFR1ZXNkYXksIEp1bmUg MDIsIDIwMTUgODoyNiBBTQ0KPj4gVG86IExpZmVuZ2thaSAoRmVuZ2thaSk7IFN1c2FuIEhhcmVz OyBzZG5AaXJ0Zi5vcmcNCj4+IENjOiBaaG91dGlhbnJhbjsgWGlheWluYmVuOyBpYm5lbW9AaWV0 Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbU2RuXSBEZWZpbmluZyBhIENvbW1vbiBNb2RlbCBmb3Ig aW50ZW50DQo+Pg0KPj4gSSBhZ3JlZSB0aGF0IHRoZSBjb250ZXh0IG1hdHRlcnMsIEZlbmdrYWkg KGFuZCBTdXNhbiBpbiBlYXJsaWVyIHJlc3BvbnNlKS4NCj4gV2hhdCB0aGUgSS1EIGFwcGVhcnMg dG8gYmUgc2F5aW5nIGlzIHRoYXQgYW55IGludGVyYWN0aW9uIGFjcm9zcyBhbiANCj4gTkJJIGlz DQo+IGludGVudDogb3RoZXJ3aXNlIHRoZSBhcHAvdGVuYW50L2N1c3RvbWVyIHdvdWxkbid0IGRv IGl0LiBUaGF0J3MgdGhlIA0KPiByb290IG9mIG15IHF1ZXN0aW9uIGZyb20gdGhlIGJlZ2lubmlu ZzogaG93IHdvdWxkIHdlIGtub3cgd2hhdCBpcyAqbm90KiBpbnRlbnQ/DQo+PiBJZiBJIGFzayBm b3Igc29tZSBwYXJ0aWN1bGFyIG1pY3Jvc2NvcGljYWxseSBkZXRhaWxlZCBjb25maWd1cmF0aW9u IA0KPj4gKGENCj4gImhvdyIpLCBpdCdzIGJlY2F1c2UgSSBjYXJlLCBmb3Igc29tZSByZWFzb24s IGFib3V0IHRoYXQgbGV2ZWwgb2YgDQo+IGRldGFpbC4gSXQgaXMgaW4gZmFjdCBwYXJ0IG9mIG15 IGludGVudC4NCj4+IEluIG15IElUIGV4YW1wbGUsIEkgYXJndWUgdGhhdCBpbnRlbnQgbmVlZCBu b3QgYmUgaW5kZXBlbmRlbnQgb2YgDQo+PiBwcm90b2NvbHMNCj4gYW5kIHBvcnRzLCBhbmQgdGhh dCBpdCBuZWVkIG5vdCBiZSBwb3J0YWJsZS4gWW91ciByZXNwb25zZSBhYm91dCANCj4gY29udGV4 dCBhcHBlYXJzIHRvIGFncmVlLg0KPj4gU28gYXMgYmVzdCBJIGNhbiB0ZWxsLCB3ZSBjYW4gc2F5 IHByZWNpc2VseSB3aGF0IGFuIGludGVudCBpcywgYW5kIHdlDQo+IGNhbid0IHNheSB3aGF0IGFu IGludGVudCBpcyBub3QuIElmIGludGVudCBpcyBqdXN0IHRoZSBsYXRlc3QgDQo+IGJ1enp3b3Jk LCB3aGljaCBpdCBjZXJ0YWlubHkgYXBwZWFycyB0byBiZSwgY2FuIHdlIGp1c3Qgc2F5IHNvIGFu ZCANCj4gbGVhdmUgaXQgdG8gdGhlIG1hcmtldGluZyBwZW9wbGU/DQo+PiBEYXZlDQo+Pg0KPj4g RnJvbTogTGlmZW5na2FpIChGZW5na2FpKSBbbWFpbHRvOmxpZmVuZ2thaUBodWF3ZWkuY29tXQ0K Pj4gU2VudDogVHVlc2RheSwgSnVuZSAwMiwgMjAxNSAxMjo0NyBBTQ0KPj4gVG86IERhdmUgSG9v ZDsgU3VzYW4gSGFyZXM7IHNkbkBpcnRmLm9yZw0KPj4gQ2M6IFpob3V0aWFucmFuOyBYaWF5aW5i ZW47IGlibmVtb0BpZXRmLm9yZw0KPj4gU3ViamVjdDogUkU6IFtTZG5dIERlZmluaW5nIGEgQ29t bW9uIE1vZGVsIGZvciBpbnRlbnQNCj4+DQo+PiBIaSBEYXZlIGFuZCBhbGwsDQo+Pg0KPj4gVGhh bmtzIGZvciBwcm9wb3NpbmcgdGhlIHR3byB2YWx1YWJsZSBpbnRlbnQgdXNlIGNhc2VzLg0KPj4N Cj4+IEZvciB0aGUgdXNlIGNhc2UgMiwgSSBhZ3JlZSB0aGF0IHRoZSBJVCBlbXBsb3llZSBuZWVk cyB0byBpbmNsdWRlIHRoZQ0KPiBkZXRhaWxzIG9mIHBvcnRzL3Byb3RvY29scyBpbnRvIGhpcy9o ZXIgaW50ZW50IGRlc2NyaXB0aW9ucywgYnV0IHRob3NlIA0KPiBtYXkgbm90IGJlIGluIHRoZSBp bnRlbnQgY29udGV4dCBzY29wZSBvZiBhIG5vbi1JVCBlbXBsb3llZS4gSGF2ZSBhIA0KPiBmdXJ0 aGVyIGNvbnNpZGVyYXRpb24gd2l0aCB0aGlzLCBkaWZmZXJlbnQgdXNlcnMgb2YgdGhlIG5ldHdv cmsgaGF2ZSANCj4gdGhlaXIgb3duIGludGVudCBpbiBhIHNwZWNpZmljIGRvbWFpbi4gVGhlbiB0 aGUgcm9sZXMvYWN0b3JzIG9mIA0KPiBuZXR3b3JrIHVzZXJzLCBzdWNoIGFzIGVuZCB1c2Vycywg YXBwbGljYXRpb24gZGV2ZWxvcGVycywgdGVuYW50IA0KPiBJVC9uZXR3b3JrIGFkbWluaXN0cmF0 b3JzLCBvcGVyYXRvciBuZXR3b3JrIGFkbWluaXN0cmF0b3JzLCBhcmUgDQo+IHZhbHVhYmxlIHRv IGJlIGlkZW50aWZpZWQgYW5kIGRpc3Rpbmd1aXNoZWQsIHRodXMgZml0dGluZyB0aGUgaW50ZW50 IA0KPiByZXF1aXJlbWVudHMgb2YgdGhlIG5ldHdvcmsgdXNlcnMgd2l0aCBkaWZmZXJlbnQgcm9s ZXMuDQo+PiBBbnkgdGhvdWdodHMgYWJvdXQgdGhpcyBjb25zaWRlcmF0aW9uPw0KPj4NCj4+DQo+ PiBCZXN0IFJlZ2FyZHMsDQo+PiBGZW5na2FpDQo+Pg0KPj4gRnJvbTogc2RuIFttYWlsdG86c2Ru LWJvdW5jZXNAaXJ0Zi5vcmddIE9uIEJlaGFsZiBPZiBEYXZlIEhvb2QNCj4+IFNlbnQ6IFR1ZXNk YXksIEp1bmUgMDIsIDIwMTUgMTozOCBBTQ0KPj4gVG86IFN1c2FuIEhhcmVzOyBzZG5AaXJ0Zi5v cmcNCj4+IENjOiBaaG91dGlhbnJhbjsgWGlheWluYmVuOyBpYm5lbW9AaWV0Zi5vcmcNCj4+IFN1 YmplY3Q6IFJlOiBbU2RuXSBEZWZpbmluZyBhIENvbW1vbiBNb2RlbCBmb3IgaW50ZW50DQo+Pg0K Pj4gQW4gZXhjZXJwdCBmcm9tIGFuIGVtYWlsIEkgc2VudCBvbiB0aGUgT05GIE5CSSBsaXN0LCB3 aGljaCBtYXkgDQo+PiBjb250YWluDQo+IHNvbWUgdXNlZnVsIHRob3VnaHRzOg0KPj4gSSBoYXZl IGFsd2F5cyBoYWQgdHJvdWJsZSB1bmRlcnN0YW5kaW5nIHdoYXQgYW4gaW50ZW50IHJlYWxseSBp cywgc28gDQo+PiBJIGFtDQo+IGxvb2tpbmcgZm9yd2FyZCB0byBtYWtpbmcgdGhlIGNvbmNlcHQg bW9yZSBwcmVjaXNlLg0KPj4gV2hlbiBJIGNsaWNrIGEgbGluayBvbiBhIHdlYiBwYWdlLCBJIGV4 cHJlc3MgYW4gaW50ZW50IHRvIGludm9rZSANCj4+IHdoYXRldmVyDQo+IHRoYXQgbGluayBvZmZl cnMuIENvbXBsZXRlbHkgYmVsb3cgdGhlIHN1cmZhY2UgaXMgYSBsYXllciBzdGFjaywgDQo+IG9u LWRlbWFuZCBzZXNzaW9uIGVzdGFibGlzaG1lbnQsIEROUyBsb29rLXVwcywgc2VydmVyIGxvYWQg YmFsYW5jZXJzLCANCj4gYW5kIGFueSBudW1iZXIgb2Ygb3RoZXIgdGVjaG5vbG9naWNhbCBmZWF0 dXJlcyB0aGF0IGFyZSBvZiBubyBpbnRlcmVzdCANCj4gdG8gbWUuIFdoeSBub3QgdXNlIHRoYXQg YXMgYW4gZXhhbXBsZSBvZiBpbnRlbnQ/DQo+PiBCZXR0ZXIgeWV0LCB3ZSB0YWxrIGFib3V0IG5l Z290aWF0aW9uIGFuZCBzZWxlY3Rpb24uIFN1cHBvc2UgSSB3YW50IA0KPj4gdG8gYnV5DQo+IGEg d2lkZ2V0LiBJIHByb2JhYmx5IGFscmVhZHkgaGF2ZSBzb21lIGlkZWEgd2hldGhlciBJIHdhbnQg dG8gZ28gdG8gDQo+IEFtYXpvbiBvciBFQmF5IG9yIHNvbWV3aGVyZSBlbHNlLiBTdXBwb3NlIGl0 J3MgQW1hem9uLiBJIHNlYXJjaCANCj4gQW1hem9uJ3MgY2F0YWxvZyBhbmQgcmVjZWl2ZSBhbiBv ZmZlciBvZiBzZXZlcmFsIHdpZGdldHMsIHNvbWUgbmV3LCANCj4gc29tZSB1c2VkLCBzb21lIHdp dGggYSBjaG9pY2Ugb2YgY29sb3VyIG9yIG90aGVyIHBlcnRpbmVudCBmZWF0dXJlcy4gDQo+IElm IEkgc2VlIG5vdGhpbmcgSSBsaWtlLCBJIG1heSBvcGVuIGEgbmV3IGJyb3dzZXIgd2luZG93IGFu ZCBjaGVjayBvdXQgDQo+IEJlc3QgQnV5IG9yIEVCYXkgKGxvdHMgbW9yZSBoaWRkZW4gdGVjaG5v bG9neSB0byBtYWtlIHRoYXQgaGFwcGVuISkuIA0KPiBNYXliZSBJIGNvbWUgYmFjayB0byB0aGUg QW1hem9uIHBhZ2UsIGhhdmluZyBmb3VuZCBub3RoaW5nIEkgbGlrZWQgDQo+IGJldHRlciBzb21l d2hlcmUgZWxzZS4gTm93IEkgYWNjZXB0IG9uZSBvZiB0aGUgb2ZmZXJlZCB3aWRnZXRzIGFuZCBn byB0aHJvdWdoIHRoZSBjaGVja291dCBwcm9jZXNzLg0KPj4gRG8gd2UgYWdyZWUgdGhhdCB0aGlz IGlzIGEgZmFpcmx5IHB1cmUgZXhwcmVzc2lvbiBvZiBpbnRlbnQgYXMgDQo+PiBjb25jZXB0dWFs aXplZCBpbiB0aGUgcGFwZXI/IChJZiBub3QsIGxldCdzIHRhbGsgYWJvdXQgbWFraW5nIGEgU2t5 cGUNCj4+IGNhbGwuKQ0KPj4NCj4+IE9rLCB0aGF0J3MgbXkgaW50ZW50IGFzIGFuIGludGVybmV0 IHVzZXIuIExldCdzIGFzc3VtZSB0aGUgbmV0d29yayBpcyANCj4+IGFsbA0KPiBTRE4gb2Ygb25l IGtpbmQgb3IgYW5vdGhlci4gSSBpbnZva2UgbXkgaW50ZW50IHRocm91Z2ggYSBHVUkgb250byAN Cj4gc29mdHdhcmUgbG9jYWwgdG8gbXkgUEMsIGJ1dCBJIGRvbid0IHRoaW5rIHdlIGNhbiBjYWxs IHRoZSBQQyBhbiBTRE4gDQo+IGNvbnRyb2xsZXIuIEl0J3MgbW9yZSBhbiBhY3RpdmUgbWVkaWF0 b3IsIGEgY2xpZW50IHRvIGFuIFNETi4gQXMgZmFyIA0KPiBhcyB0aGUgbmV0d29yayBpcyBjb25j ZXJuZWQsIHRoZSBjbGllbnQgbWFrZXMgRE5TIHF1ZXJpZXMgYW5kIHN3YXBzIA0KPiBvcGFxdWUg VENQIHBhY2tldHMgb3ZlciBhIGZvcndhcmRpbmcgcGF0aCB0aGF0IG1heSBhbHJlYWR5IGV4aXN0 LCBvciANCj4gbWF5IG5lZWQgdG8gYmUgbGVhcm5lZCBhbmQgc2V0IHVwIG9uIGRlbWFuZC4gVGhp cyBpcyBhYm91dCByaWdodCwgDQo+IGJlY2F1c2UgdGhlIHNlc3Npb24gY29udGVudCBtYXkgd2Vs bCBiZSBlbmNyeXB0ZWQgZW5kIHRvIGVuZCwgYW5kIHJpZ2h0bHkuDQo+PiBUbyB0aGUgU0ROIGNv bnRyb2xsZXIsIG15IGludGVudCBpcyBzYXRpc2ZpZWQgYnkgZGlyZWN0aW5nIEROUyANCj4+IHF1 ZXJpZXMgdG8NCj4gYSBrbm93biBETlMgc2VydmVyIHNvbWV3aGVyZSwgYW5kIGVuc3VyaW5nIElQ IGNvbm5lY3Rpdml0eSBmb3IgdGhlIA0KPiBzdWJzZXF1ZW50IHNlc3Npb24uIEhtbW0uIHdoYXQg aGFwcGVuZWQgdG8gb3VyIGludGVudC1iYXNlZCBOQkk/IFRoZSANCj4gU0ROIG9mZmVyZWQgbXkg UEMgYSBwYWNrZXQgaW50ZXJmYWNlIHdpdGggdGhlIHByb3BlcnRpZXMgb2Yga25vd2luZyANCj4g aG93IHRvIHJlY29nbml6ZSBhbmQgcm91dGUgRE5TIHF1ZXJpZXMgc3BlY2lhbGx5LCBhbmQgZ2Vu ZXJhbCBJUCANCj4gY29ubmVjdGl2aXR5LiBNeSBQQyBhY2NlcHRlZCB0aGUgc2VydmljZSBvZmZl ciBpbXBsaWNpdGx5IGJ5IG9mZmVyaW5nIA0KPiB0cmFmZmljIHRvIHRoZSBkYXRhLXBsYW5lIGlu dGVyZmFjZS4gVGhlIG5ldHdvcmsgY291bGQgYmUgcGVyZm9ybWluZyANCj4gYXNzb2NpYXRlZCBh dXhpbGlhcnkgc2VydmljZXMgc3VjaCBhcyB1c2FnZS1iYXNlZCBiaWxsaW5nICh0aGluayANCj4g d2lyZWxlc3Mgcm9hbWluZyksIHNvIGl0J3MgbW9yZSB0aGFuIGp1c3QgYSBkdW1iIHBpcGUuDQo+ PiBJZiB0aGlzIGlzIG5vdCBhIGxlZ2l0aW1hdGUgZXhhbXBsZSBvZiBpbnRlbnQsIGl0IHdvdWxk IGJlIGdvb2QgdG8gDQo+PiB3cml0ZQ0KPiB0aGUgd2hpdGUgcGFwZXIgaW4gc3VjaCBhIHdheSB0 aGF0IGNsZWFybHkgZXhjbHVkZXMgc3VjaCBjYXNlcy4NCj4+IFVzZSBjYXNlIDI6IHN1cHBvc2Ug SSBhbSBhIGNvcnBvcmF0ZSBJVCBlbXBsb3llZSwgYW5kIHN1cHBvc2UgdGhhdCBteSANCj4+IGlu dGVudCBpcyB0byBoYXZlIGFuIEUtTGluZSBiZXR3ZWVuIHR3byBvZiBteSBjYW1waS4gSSBuZWNl c3NhcmlseSANCj4+IGNhcmUgYWJvdXQgcG9ydHMgYW5kIHByb3RvY29sczsgdGFsayBhYm91dCBp bnRlbnQgYmVpbmcgcG9ydGFibGUgYW5kIA0KPj4gcHJvdG9jb2wgaW5kZXBlbmRlbnQgY29udGlu dWVzIHRvIGNvbmZ1c2UgbWUgY29tcGxldGVseS4gSG93IGNhbiBJIA0KPj4gb3JkZXIgYW4gRS1s aW5lIHdpdGhvdXQgY2FyaW5nIGFib3V0IHN1Y2ggZGV0YWlscz8gW05vciBpcyB0aGlzIA0KPj4g aW50ZW50IHBvcnRhYmxlLl0NCj4+DQo+PiBPYnZpb3VzbHksIGFuIFNETiBjb250cm9sbGVyIGlz IGdvaW5nIHRvIGV4cG9zZSB3aGF0ZXZlciBhY3Rpb25zIGFuZA0KPiBlbGVtZW50cyBvZiBpbmZv cm1hdGlvbiBhcmUgZ2VybWFuZSB0byB0aGUgc2VydmljZSBpdCBvZmZlcnMsIGFuZCBpZiANCj4g cG9ydHMgYW5kIHByb3RvY29scyBhcmUgZ2VybWFuZSB0byB0aGUgc2VydmljZSwgc28gYmUgaXQu DQo+PiBUaGUgU0ROIGFyY2hpdGVjdHVyZSwgYmVpbmcgcmVjdXJzaXZlLCBtb2RlbHMgdGhlIG5v cnRoIHNpZGUgb2YgYW55DQo+IGNvbnRyb2xsZXIgYXMgZXhwb3NpbmcgYW4gaW5zdGFuY2Ugb2Yg YW4gaW5mb3JtYXRpb24gbW9kZWwsIGN1c3RvbWl6ZWQgDQo+IGZvciB0aGUgaW50ZW5kZWQgY2xp ZW50L2N1c3RvbWVyL2FwcC91c2VyLiBUaGF0IGJlaW5nIHRoZSBjYXNlLCBob3cgZG8gDQo+IHdl IGRpc3Rpbmd1aXNoIGFuIE5CSSBBUEkgdGhhdCBjb252ZXlzIGludGVudCAoc2VydmljZTogc2Ft ZSB0aGluZz8pIA0KPiBmcm9tIG9uZSB0aGF0IGRvZXMgbm90Pw0KPj4gSSBoYXZlIHJlY2VudGx5 IGNvbWUgdG8gdGhlIHZpZXcgdGhhdCBncmFudWxhcml0eSBpcyB0aGUgY3JpdGVyaW9uIGJ5DQo+ IHdoaWNoIGFuIGludGVudCBvciBzZXJ2aWNlIGludm9jYXRpb24gaXMgZGlzdGluZ3Vpc2hlZC4g Q29sbG9xdWlhbGx5IA0KPiBzcGVha2luZywgYSBzZXJ2aWNlIGludm9jYXRpb24gaXMgYSBzaW5n bGUgaW52b2NhdGlvbiBhY3Jvc3MgdGhlIEFQSTogDQo+IGdpdmUgbWUgRS1MaW5lLiBOb3cgb2Yg Y291cnNlIHRoaXMgdHVybnMgaW50byBjb25zdHJhaW50IG5lZ290aWF0aW9uLCANCj4gb2ZmZXIg YW5kIGFjY2VwdGFuY2UsIGJ1dCB3aGF0IGhhcHBlbnMgYWNyb3NzIHRoZSBBUEkgaXMgZWZmZWN0 aXZlbHkgb25lIHRyYW5zYWN0aW9uLg0KPiBJbiBjb250cmFzdCwgd2hhdCB3ZSBtaWdodCBhZ3Jl ZSBpcyAqbm90KiBhbiBpbnRlbnQgb3IgYSBzZXJ2aWNlIGlzIA0KPiB0aGUgbWFuaXB1bGF0aW9u IG9mIGEgZ3JhbnVsYXIgaW5mb3JtYXRpb24gbW9kZWwsIHRoZSBleHBsaWNpdCANCj4gdmlzaWJp bGl0eSBvZiBtdWx0aXBsZSBvYmplY3RzLCBob3cgdGhleSBhcmUgaW50ZXJyZWxhdGVkLCB0aGVp ciBhdHRyaWJ1dGVzLCBhbmQgdGhlIGxpa2UuDQo+PiAuICAgICAgICAgTmV0d29yayBhcyBhIHNp bmdsZSBsdW1wIHZzIHNvbWUgbm9uLXRyaXZpYWwgdG9wb2xvZ3kuDQo+Pg0KPj4gLiAgICAgICAg IENoYXVmZmV1ciB2cyBkcml2aW5nIGEgY2FyLiBMZWdpdGltYXRlIHJlYXNvbnMgdG8gY2hvb3Nl IG9uZQ0KPiBvcHRpb24gb3IgdGhlIG90aGVyLCBidXQgdGhlIGxldmVsIG9mIGdyYW51bGFyaXR5 IGlzIHF1aXRlIGRpZmZlcmVudC4gDQo+IFNoYWxsIHdlIGFncmVlIHRoYXQgZHJpdmluZyBpcyB0 b28gZ3JhbnVsYXIgdG8gYmUgY29uc2lkZXJlZCBpbnRlbnQ/DQo+PiBUaGlzIGlkZWEgb2YgZ3Jh bnVsYXJpdHkgYW5kIGRldGFpbGVkIG9wZXJhdGlvbnMgb24gdGhlIGNvbXBvbmVudHMgDQo+PiAo d2hpY2gNCj4gb2YgY291cnNlIG1heSBiZSBjb21wbGV4IGVudGl0aWVzIHRoZW1zZWx2ZXMsIHZp cnR1YWxpemVkIGludG8gDQo+IHNpbXBsZS1hcHBlYXJpbmcgbHVtcHMpIHNlZW1zIHRvIG1lIHRv IGNhcHR1cmUgdGhlIGVzc2VuY2Ugb2Ygd2hhdCANCj4gcGVvcGxlIGFyZSB0YWxraW5nIGFib3V0 IHdoZW4gdGhleSBzYXkgaW50ZW50IG9yIHNlcnZpY2UuIEkgYW0gbm90IA0KPiBjb21mb3J0YWJs ZSB3aXRoIHRoZSB3YXkgSSBhbSBleHByZXNzaW5nIGl0LCBzbyBpZiB0aGlzIGlzIGEgc3RlcCBp biBhIA0KPiBwcm9kdWN0aXZlIGRpcmVjdGlvbiwgb3IgZXZlbiBpZiBpdCdzIG5vdCwgSSB3ZWxj b21lIHN1Z2dlc3Rpb25zIHRvIGNsYXJpZnkgdGhlIGNvbmNlcHQuDQo+PiBEYXZlDQo+Pg0KPj4g RnJvbTogc2RuIFttYWlsdG86c2RuLWJvdW5jZXNAaXJ0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdXNh biBIYXJlcw0KPj4gU2VudDogU2F0dXJkYXksIE1heSAzMCwgMjAxNSAxOjAyIFBNDQo+PiBUbzog c2RuQGlydGYub3JnDQo+PiBDYzogJ1pob3V0aWFucmFuJzsgJ1hpYXlpbmJlbic7IGlibmVtb0Bp ZXRmLm9yZw0KPj4gU3ViamVjdDogW1Nkbl0gRGVmaW5pbmcgYSBDb21tb24gTW9kZWwgZm9yIGlu dGVudA0KPj4NCj4+IE9uIHRoaXMgbWFpbCBsaXN0LCB0aGVyZSBoYXMgYmVlbiBhIGRpc2N1c3Np b24gb2YgdHdvIHR5cGVzIG9mIA0KPj4gaW5mb3JtYXRpb24NCj4gZm9yIEludGVudCBhbmQgTmVt bzoNCj4gKGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zZG4vY3VycmVudC9t c2cwMDY0Ni5odG1sKSA6DQo+PiAxKSAgICAgIFdoYXQgaW5mb3JtYXRpb24gaXMgbmVlZGVkIHRv IHJlcHJlc2VudCBhIHNlcnZpY2UgcmVxdWVzdCwNCj4+IDIpICAgICAgSG93IHRvIHJlcHJlc2Vu dCBhbmQgdHJhbnNwb3J0IHRoZSBpbmZvcm1hdGlvbiBmb3IgYSByZXF1ZXN0Lg0KPj4NCj4+IElu IG9yZGVyIHRvIGRlZmluZSB3aGF0IGluZm9ybWF0aW9uIGlzIG5lZWRlZCB0byByZXByZXNlbnQg YSAxKSANCj4+IHNlcnZpY2UNCj4gcmVxdWVzdCB0aGF0IHNpZ25hbHMgSW50ZW50IGZyb20gYW4g YXBwbGljYXRpb24gdG8gYSBjb250cm9sbGVyLCBpdCBpcyANCj4gaW1wb3J0YW50IHRvIGRlZmlu ZSBJbnRlbnQsIGFuZCBwcm92aWRlIGEgY2xlYXIgbW9kZWwgb2YgSW50ZW50LiAgDQo+IEFsc28s IGluIGRlc2NyaWJpbmcgcmVhbCB1c2UtY2FzZXMgaXQgaXMgaW1wb3J0YW50IHRoYXQgb25lIHVz ZXMgdGhlIA0KPiBzYW1lIGRlZmluaXRpb24gYW5kIG1vZGVsIGZvciBJbnRlbnQgaW4gZWFjaCB1 c2UgY2FzZS4NCj4+IEluIHRoZSBjdXJyZW50IGZvcnVtcyBleGFtaW5pbmcgSW50ZW50IChPREwg TklDLCBPREwgTmVtbywgT0YgTkJJIGFuZA0KPiBLZXlzdG9uZSwgT1BORlYgTW92aWUsIE9wZW5T dGFjaykgdGhlcmUgaXMgYSByZWFsaXphdGlvbiB0aGF0IEludGVudCANCj4gb2NjdXJzIGF0IG11 bHRpcGxlIGxheWVycy4gIFRoZSBhdXRob3JzIG9mIGRyYWZ0LXhpYS1pYm5lbW8taWNpbSBoYXZl IA0KPiBjcmVhdGVkIGEgZGVmaW5pdGlvbiBmb3IgaW50ZW50IGFuZCBhIHVuaWZpZWQgbW9kZWwg Zm9yIGRlZmluaW5nIA0KPiBpbnRlbnQgd2hpY2ggY2FuIGhhbmRsZSAxIG9yIG11bHRpcGxlIGxh eWVycy4gVGhlIG1vZGVsIHN1Z2dlc3QgdGhhdDoNCj4+IDEpICAgICAgQSB1c2VyIGhhcyBhIGlu dGVudCB0aGF0IGlzIGV4cHJlc3NlZCBpbiBhIGNvbnRleHQuDQo+PiAyKSAgICAgIEludGVudCAo dXN1YWxseSkgaW52b2x2ZXMgYW4gb2JqZWN0IHdpdGggYSByZXN1bHQsIGFuZCBvcHRpb25hbGx5 DQo+IGluY2x1ZGVzIG9wZXJhdGlvbnMgdG93YXJkIHRoYXQgcmVzdWx0Lg0KPj4gMykgICAgICBP cGVyYXRpb25zIGNvbmRpdGlvbnMgcGVyZm9ybSBhY3Rpb25zIHdpdGhpbi9tb2RpZmllZCBieQ0K PiBjb25zdHJhaW50cy4NCj4+IFdlIGJlbGlldmUgdGhpcyBkZWZpbmVzIGNsZWFybHkgd2hhdCBv dGhlcnMgYXJlIGNhbGxpbmcgInB1cmUgaW50ZW50Ig0KPiAob2JqZWN0cyArIHJlc3VsdHMpIHZl cnN1cyAiY29uc3RyYWluZWQgaW50ZW50IiAob2JqZWN0cyArIG9wZXJhdGlvbnMgKw0KPiBjb25z dHJhaW50cykuICAgVGhlIGRyYWZ0IGNhbiBiZSBmb3VuZCBhdDoNCj4gaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQteGlhLWlibmVtby1pY2ltLyAuICAgVGhlIGF1dGhvcnMg YXJlDQo+IGxvb2tpbmcgZm9yIGZlZWRiYWNrIG9uIHRoZSBjb25jZXB0cyBpbiB0aGUgZHJhZnQu DQo+PiBTdWUgSGFyZXMNCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4gc2RuIG1haWxpbmcgbGlzdA0KPj4gc2RuQGlydGYub3JnDQo+PiBo dHRwczovL3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nkbg0KPj4NCj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBJYm5lbW8gbWFpbGlu ZyBsaXN0DQo+PiBJYm5lbW9AaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaWJuZW1vDQo+Pg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBzZG4gbWFpbGluZyBsaXN0DQo+IHNkbkBpcnRmLm9yZw0KPiBo dHRwczovL3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nkbg0KPg0KPg0KDQo= From nobody Mon Jun 8 07:22:16 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 621F81A88E6; Mon, 8 Jun 2015 07:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUqENU7Ol9uD; Mon, 8 Jun 2015 07:22:07 -0700 (PDT) Received: from p01c11o147.mxlogic.net (p01c11o147.mxlogic.net [208.65.144.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 147271A88E3; Mon, 8 Jun 2015 07:22:04 -0700 (PDT) Received: from unknown [76.164.174.83] (EHLO ex-hc2.corp.adtran.com) by p01c11o147.mxlogic.net(mxl_mta-8.4.0-1) over TLS secured channel with ESMTP id 605a5755.0.754326.00-316.1941516.p01c11o147.mxlogic.net (envelope-from ); Mon, 08 Jun 2015 08:22:06 -0600 (MDT) X-MXL-Hash: 5575a50e5b76db12-3168859487156a0f0fa3642b9aa4e7f970d20934 Received: from ex-mb3.corp.adtran.com ([fe80::60aa:f95:ad49:a0f1]) by ex-hc2.corp.adtran.com ([fe80::a019:449b:3f62:28e5%10]) with mapi id 14.03.0224.002; Mon, 8 Jun 2015 09:21:57 -0500 From: STUART VENTERS To: "sdn@irtf.org" Thread-Topic: [Sdn] [Ibnemo] Defining a Common Model for intent Thread-Index: AQHQntj4UU8jTLc+7kqTKQM5UVJe552czWAAgAXoq4D///HXgA== Date: Mon, 8 Jun 2015 14:21:57 +0000 Message-ID: <1220E2C537595D439C5D026E83751866C42ACD09@ex-mb3.corp.adtran.com> References: <00f301d09b13$79cc2410$6d646c30$@ndzh.com> <8D15A2BAF93E9C49AB037A0647E5FA643F8490D8@eusaamb105.ericsson.se> <865C20BAAE8BBD4C89E7D6FE694F6B3B2D3CA540@nkgeml505-mbs.china.huawei.com> <8D15A2BAF93E9C49AB037A0647E5FA643F84AAA2@eusaamb105.ericsson.se> <1220E2C537595D439C5D026E83751866C42AC2FF@ex-mb3.corp.adtran.com> , <556EFC42.9040208@bwijnen.net> <001201d09ed8$f7c6f480$e754dd80$@ndzh.com> <55706F7C.9080300@bwijnen.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.118.25] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=a+Ek9CiF c=1 sm=1 tr=0 a=5zDNsY1we+1mvVcp/5+1jQ==] X-AnalysisOut: [:117 a=5zDNsY1we+1mvVcp/5+1jQ==:17 a=0eaKXOXVzoQA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=eJNrpio] X-AnalysisOut: [GAAAA:8 a=YlVTAMxIAAAA:8 a=XAFQembCKUMA:10 a=tZfl30OWP9BWp] X-AnalysisOut: [JC_BA8A:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2015060813); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.83] Archived-At: Cc: 'Zhoutianran' , "ibnemo@ietf.org" , Susan Hares , "Bert Wijnen \(IETF\)" Subject: Re: [Sdn] [Ibnemo] Defining a Common Model for intent X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 14:22:14 -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 provi= der. 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 ne= twork is aware of, addressing, special things like nat or firewall, etc) WHERE the service should appear. (physical location of the endpoints, ma= ybe logical circuit ID's) WHEN the service should work. (Install date, maybe the 100Gig for backup= s 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 ser= vice 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 i= nteresting questions in the who, what, where, when area. I wonder if this is where this intent stuff should head? -Stuart From nobody Mon Jun 8 16:25:56 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B3E1ACD70 for ; Mon, 8 Jun 2015 16:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.005 X-Spam-Level: X-Spam-Status: No, score=-96.005 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, J_CHICKENPOX_64=0.6, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x48jSW_NsJ8G for ; Mon, 8 Jun 2015 16:25:51 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id B2FA11ACD69 for ; Mon, 8 Jun 2015 16:25:50 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.82.115; From: "Susan Hares" To: "'Zhoutianran'" , "'Bert Wijnen \(IETF\)'" , "'STUART VENTERS'" , References: <00f301d09b13$79cc2410$6d646c30$@ndzh.com> <8D15A2BAF93E9C49AB037A0647E5FA643F8490D8@eusaamb105.ericsson.se> <865C20BAAE8BBD4C89E7D6FE694F6B3B2D3CA540@nkgeml505-mbs.china.huawei.com> <8D15A2BAF93E9C49AB037A0647E5FA643F84AAA2@eusaamb105.ericsson.se> <1220E2C537595D439C5D026E83751866C42AC2FF@ex-mb3.corp.adtran.com> , <556EFC42.9040208@bwijnen.net> <001201d09ed8$f7c6f480$e754dd80$@ndzh.com> <55706F7C.9080300@bwijnen.net> In-Reply-To: Date: Mon, 8 Jun 2015 19:25:26 -0400 Message-ID: <00be01d0a242$671cdb30$35569190$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGjwAWNbhwtlPLyYWaj2K7LZAyOCALTOOmfAi4Fw8QBCozw2wFJpHEeAtftGdUDX4EdNAL46qhHAnWQGywB6AaNCAFsaxDinUqFuVA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: ibnemo@ietf.org Subject: Re: [Sdn] [Ibnemo] Defining a Common Model for intent X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 23:25:54 -0000 Tianran/Terence and Bert;=20 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).=20 - user/end-user or customer - service provider - network architect - network operator - maybe also trouble-shooter Sue=20 -----Original Message----- From: Ibnemo [mailto:ibnemo-bounces@ietf.org] On Behalf Of Zhoutianran Sent: Monday, June 08, 2015 5:46 AM To: Bert Wijnen (IETF); Susan Hares; 'STUART VENTERS'; sdn@irtf.org Cc: ibnemo@ietf.org 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:bwietf@bwijnen.net] Sent: Thursday, June 04, 2015 11:32 PM To: Susan Hares; Zhoutianran; 'STUART VENTERS'; sdn@irtf.org Cc: ibnemo@ietf.org Subject: Re: [Sdn] [Ibnemo] Defining a Common Model for intent On 04/06/15 17:13, Susan Hares wrote: > Bert and Tianran: > > If you link intent to role, I believe your diagram is: > > 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 > I think role takes on an aspect of context. What do you think? > > Sue > > -----Original Message----- > From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of Zhoutianran > Sent: Thursday, June 04, 2015 8:27 AM > To: Bert Wijnen (IETF); STUART VENTERS; sdn@irtf.org > Cc: ibnemo@ietf.org > 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=20 > different types of intent that fit with the specific role, right?" > Could you give more information on this? > > Best, > Terence > > ________________________________________ > =B7=A2=BC=FE=C8=CB: Bert Wijnen (IETF) [bwietf@bwijnen.net] > =B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA6=D4=C23=C8=D5 21:08 > =CA=D5=BC=FE=C8=CB: Zhoutianran; STUART VENTERS; sdn@irtf.org > =B3=AD=CB=CD: ibnemo@ietf.org > =D6=F7=CC=E2: Re: [Ibnemo] [Sdn] Defining a Common Model for intent > > 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=20 > we are successful in doing a model for IBNEMO for the top layer, we=20 > can then see if we want to go at more layers. > > A role -based intent model? I guess it would just boil down in=20 > different types of intent that fit with the specific role, right? > > Bert > > > On 03/06/15 11:44, Zhoutianran wrote: >> 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=20 >> relative > detailed description in my "role based intent" email. >> I think the essential of the role based intent is that there is only=20 >> one > intent layer which is always on the top. Intent is dedicated for=20 > 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:sdn-bounces@irtf.org] On Behalf Of STUART VENTERS >> Sent: Wednesday, June 03, 2015 12:06 AM >> To: sdn@irtf.org >> Cc: 'Dave Hood'; ibnemo@ietf.org; Lifengkai (Fengkai); Zhoutianran;=20 >> 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=20 >> use this product from this vendor Sales Person says: Here is the=20 >> price and priority >> Partitioner: divides the end to end circuit among administrative=20 >> domains >> Planner: picks the necessary resources to use, makes the truck rolls=20 >> happen >> Allocator: allocates the necessary bandwidth >> Provisioner: decides what provisioning is necessary in each part of=20 >> 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=20 >> 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=20 >> for > refinement. >> That said, the data model for intent might/should be different at=20 >> each > level. >> Since each level is processing the same request at different levels=20 >> 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=20 >> forwarding > engines, except distributed. >> Perhaps a simple starting point near the top is a combination of=20 >> entities, > endpoints, and connections. >> >> Regards, >> >> Stuart Venters >> >> >> >> >> >> >> >> From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of Dave Hood >> Sent: Tuesday, June 02, 2015 8:26 AM >> To: Lifengkai (Fengkai); Susan Hares; sdn@irtf.org >> Cc: Zhoutianran; Xiayinben; ibnemo@ietf.org >> 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=20 > NBI is > intent: otherwise the app/tenant/customer wouldn't do it. That's the=20 > root of my question from the beginning: how would we know what is = *not* intent? >> If I ask for some particular microscopically detailed configuration=20 >> (a > "how"), it's because I care, for some reason, about that level of=20 > detail. It is in fact part of my intent. >> In my IT example, I argue that intent need not be independent of=20 >> protocols > and ports, and that it need not be portable. Your response about=20 > 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=20 > buzzword, which it certainly appears to be, can we just say so and=20 > leave it to the marketing people? >> Dave >> >> From: Lifengkai (Fengkai) [mailto:lifengkai@huawei.com] >> Sent: Tuesday, June 02, 2015 12:47 AM >> To: Dave Hood; Susan Hares; sdn@irtf.org >> Cc: Zhoutianran; Xiayinben; ibnemo@ietf.org >> Subject: RE: [Sdn] Defining a Common Model for intent >> >> Hi Dave and all, >> >> Thanks for proposing the two valuable intent use cases. >> >> For the use case 2, I agree that the IT employee needs to include the > details of ports/protocols into his/her intent descriptions, but those = > may not be in the intent context scope of a non-IT employee. Have a=20 > further consideration with this, different users of the network have=20 > their own intent in a specific domain. Then the roles/actors of=20 > network users, such as end users, application developers, tenant=20 > IT/network administrators, operator network administrators, are=20 > valuable to be identified and distinguished, thus fitting the intent=20 > requirements of the network users with different roles. >> Any thoughts about this consideration? >> >> >> Best Regards, >> Fengkai >> >> From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of Dave Hood >> Sent: Tuesday, June 02, 2015 1:38 AM >> To: Susan Hares; sdn@irtf.org >> Cc: Zhoutianran; Xiayinben; ibnemo@ietf.org >> Subject: Re: [Sdn] Defining a Common Model for intent >> >> An excerpt from an email I sent on the ONF NBI list, which may=20 >> contain > some useful thoughts: >> I have always had trouble understanding what an intent really is, so=20 >> 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=20 >> whatever > that link offers. Completely below the surface is a layer stack,=20 > on-demand session establishment, DNS look-ups, server load balancers,=20 > 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=20 >> to buy > a widget. I probably already have some idea whether I want to go to=20 > Amazon or EBay or somewhere else. Suppose it's Amazon. I search=20 > Amazon's catalog and receive an offer of several widgets, some new,=20 > 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=20 > 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=20 >> 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=20 > software local to my PC, but I don't think we can call the PC an SDN=20 > controller. It's more an active mediator, a client to an SDN. As far=20 > as the network is concerned, the client makes DNS queries and swaps=20 > opaque TCP packets over a forwarding path that may already exist, or=20 > may need to be learned and set up on demand. This is about right,=20 > because the session content may well be encrypted end to end, and = rightly. >> To the SDN controller, my intent is satisfied by directing DNS=20 >> queries to > a known DNS server somewhere, and ensuring IP connectivity for the=20 > subsequent session. Hmmm. what happened to our intent-based NBI? The=20 > SDN offered my PC a packet interface with the properties of knowing=20 > how to recognize and route DNS queries specially, and general IP=20 > connectivity. My PC accepted the service offer implicitly by offering=20 > traffic to the data-plane interface. The network could be performing=20 > associated auxiliary services such as usage-based billing (think=20 > 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=20 >> 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=20 >> care about ports and protocols; talk about intent being portable and=20 >> protocol independent continues to confuse me completely. How can I=20 >> order an E-line without caring about such details? [Nor is this=20 >> 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=20 > 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?)=20 > 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=20 > speaking, a service invocation is a single invocation across the API: > give me E-Line. Now of course this turns into constraint negotiation,=20 > 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=20 > the manipulation of a granular information model, the explicit=20 > 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.=20 > Shall we agree that driving is too granular to be considered intent? >> This idea of granularity and detailed operations on the components=20 >> (which > of course may be complex entities themselves, virtualized into=20 > simple-appearing lumps) seems to me to capture the essence of what=20 > people are talking about when they say intent or service. I am not=20 > 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:sdn-bounces@irtf.org] On Behalf Of Susan Hares >> Sent: Saturday, May 30, 2015 1:02 PM >> To: sdn@irtf.org >> Cc: 'Zhoutianran'; 'Xiayinben'; ibnemo@ietf.org >> Subject: [Sdn] Defining a Common Model for intent >> >> On this mail list, there has been a discussion of two types of=20 >> 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)=20 >> 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=20 > 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=20 > occurs at multiple layers. The authors of draft-xia-ibnemo-icim have=20 > created a definition for intent and a unified model for defining=20 > 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 >> >> _______________________________________________ >> sdn mailing list >> sdn@irtf.org >> https://www.irtf.org/mailman/listinfo/sdn >> >> _______________________________________________ >> Ibnemo mailing list >> Ibnemo@ietf.org >> https://www.ietf.org/mailman/listinfo/ibnemo >> > _______________________________________________ > sdn mailing list > sdn@irtf.org > https://www.irtf.org/mailman/listinfo/sdn > > _______________________________________________ Ibnemo mailing list Ibnemo@ietf.org https://www.ietf.org/mailman/listinfo/ibnemo From nobody Mon Jun 8 16:32:05 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1F41ACD8D for ; Mon, 8 Jun 2015 16:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.156 X-Spam-Level: X-Spam-Status: No, score=-97.156 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STgITVGAEUUy for ; Mon, 8 Jun 2015 16:32:03 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 073C31ACD81 for ; Mon, 8 Jun 2015 16:32:02 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.82.115; From: "Susan Hares" To: "'STUART VENTERS'" , References: <00f301d09b13$79cc2410$6d646c30$@ndzh.com> <8D15A2BAF93E9C49AB037A0647E5FA643F8490D8@eusaamb105.ericsson.se> <865C20BAAE8BBD4C89E7D6FE694F6B3B2D3CA540@nkgeml505-mbs.china.huawei.com> <8D15A2BAF93E9C49AB037A0647E5FA643F84AAA2@eusaamb105.ericsson.se> <1220E2C537595D439C5D026E83751866C42AC2FF@ex-mb3.corp.adtran.com> , <556EFC42.9040208@bwijnen.net> <001201d09ed8$f7c6f480$e754dd80$@ndzh.com> <55706F7C.9080300@bwijnen.net> <1220E2C537595D439C5D026E83751866C42ACD09@ex-mb3.corp.adtran.com> In-Reply-To: <1220E2C537595D439C5D026E83751866C42ACD09@ex-mb3.corp.adtran.com> Date: Mon, 8 Jun 2015 19:31:44 -0400 Message-ID: <00ea01d0a243$4882bae0$d98830a0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGjwAWNbhwtlPLyYWaj2K7LZAyOCALTOOmfAi4Fw8QBCozw2wFJpHEeAtftGdUDX4EdNAL46qhHAnWQGywB6AaNCAFsaxDiAnunU7+dNqnSUA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Zhoutianran' , ibnemo@ietf.org, "'Bert Wijnen \(IETF\)'" Subject: Re: [Sdn] [Ibnemo] Defining a Common Model for intent X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 23:32:04 -0000 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:sdn-bounces@irtf.org] On Behalf Of STUART VENTERS Sent: Monday, June 08, 2015 10:22 AM To: sdn@irtf.org Cc: 'Zhoutianran'; ibnemo@ietf.org; Susan Hares; Bert Wijnen (IETF) Subject: Re: [Sdn] [Ibnemo] Defining a Common Model for intent 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 _______________________________________________ sdn mailing list sdn@irtf.org https://www.irtf.org/mailman/listinfo/sdn From nobody Mon Jun 15 06:43:23 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B52D1A7009 for ; Mon, 15 Jun 2015 06:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.44 X-Spam-Level: X-Spam-Status: No, score=0.44 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eg-I5lRSsNsV for ; Mon, 15 Jun 2015 06:43:19 -0700 (PDT) Received: from mx2.eict.de (mx2.eict.de [212.91.241.168]) by ietfa.amsl.com (Postfix) with ESMTP id 99CD41A7001 for ; Mon, 15 Jun 2015 06:42:43 -0700 (PDT) Received: by mx2.eict.de (Postfix, from userid 481) id 613911FF44; Mon, 15 Jun 2015 15:42:42 +0200 (CEST) Received: from mail.eict.de (mx1 [172.16.6.1]) by mx2.eict.de (Postfix) with ESMTP id 0AED81FF44 for ; Mon, 15 Jun 2015 15:42:42 +0200 (CEST) Received: from sbs2008.eict.local (sbs2008.intern.eict.de [192.168.2.11]) by mail.eict.de (Postfix) with ESMTP id CB7F3378269 for ; Mon, 15 Jun 2015 15:42:41 +0200 (CEST) Received: from SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298]) by SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298%13]) with mapi; Mon, 15 Jun 2015 15:41:26 +0200 From: Kostas Pentikousis To: SDN IRTF list Date: Mon, 15 Jun 2015 15:41:24 +0200 Thread-Topic: EWSDN 2015: Paper submission due 17 June 2015 Thread-Index: AdCncPjoh9I95+FaS8yLJF2xj5ZT1Q== Message-ID: <0C7EDCF89AB9E2478B5D010026CFF4AEB5AB9050EF@SBS2008.eict.local> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Sdn] EWSDN 2015: Paper submission due 17 June 2015 X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 13:43:21 -0000 A kind reminder to all planning to submit a full paper to EWSDN this year: = only two (2) days left! See www.ewsdn.org for more details. For those interested to demonstrate their recent work, the poster and demo = paper deadline is a bit less than a month away: 12 July 2015.=20 Best regards, Kostas From nobody Mon Jun 15 07:14:38 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E95B71B2D8D for ; Mon, 15 Jun 2015 07:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qPBG186DEfd for ; Mon, 15 Jun 2015 07:14:33 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D5251B2D84 for ; Mon, 15 Jun 2015 07:14:19 -0700 (PDT) X-AuditID: c6180641-f79086d000001909-79-557e7794ea6a Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 8A.4D.06409.4977E755; Mon, 15 Jun 2015 08:58:28 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0210.002; Mon, 15 Jun 2015 10:14:16 -0400 From: Meral Shirazipour To: SDN IRTF list Thread-Topic: fyi Call for papers ICNC 2016 Optical and Grid Computing Symposium, Kauai, Hawaii, USA, Feb. 15-18, 2016 [submission: July 5, 2015] Thread-Index: AdCndWZtroVdau/nRw+RDPo/Lxo2rA== Date: Mon, 15 Jun 2015 14:14:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_ABCAA4EF18F17B4FB619EA93DEF7939A3348D299eusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyuXSPn+6U8rpQgxs3xC3OL3jO4sDoMXnj YbYAxigum5TUnMyy1CJ9uwSujC9nHjEWXMuteNH0jL2B8Xd8FyMnh4SAicSZZ/9ZIWwxiQv3 1rN1MXJxCAkcZZT4f+gHlLOcUWLyxSlgVWwCFhLbfz8Hs0UEFCSOPH/HCFIkLNDHKPHj20YW EEdEYDKjxKybrSwQVXoSP86tZAexWQRUJVqefWQCsXkFfCUaLreDTWIE2v391BqwOLOAuMSt J/OZIG4SkFiy5zwzhC0q8fLxP6hblSQ+/p7PDlGfLzFt/RWomYISJ2c+YZnAKDQLyahZSMpm ISmDiOtILNj9iQ3C1pZYtvA1M4x95sBjJmTxBYzsqxg5SotTy3LTjQw3MQLD/5gEm+MOxgWf LA8xCnAwKvHwKhysDRViTSwrrsw9xCjNwaIkzivtlxcqJJCeWJKanZpakFoUX1Sak1p8iJGJ g1OqgTGx7aicSoYp/37Go76d4of/Pb3mMdPL8KXg0u77H1YmfXbVu1NaXjntT0dEZmrzXmWR /z+e2/Hmt5y0Y1zNprpCld076aKClmpv4eIZuhv1HzMmNyhsNxWzNuOSP3wzv1/u9vkDrM8y WZPKFZkLrmhss+szFIn/0Pjx0OT/zwvtv148xBOur8RSnJFoqMVcVJwIAHpPh7JgAgAA Archived-At: Subject: [Sdn] fyi Call for papers ICNC 2016 Optical and Grid Computing Symposium, Kauai, Hawaii, USA, Feb. 15-18, 2016 [submission: July 5, 2015] X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 14:14:36 -0000 --_000_ABCAA4EF18F17B4FB619EA93DEF7939A3348D299eusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, FYI CFP below. Best regards, Meral Call for papers ICNC 2016 Optical and Grid Computing Symposium, Kauai, Hawa= ii, USA, Feb. 15-18, 2016 http://www.conf-icnc.org/2016 Scope =3D=3D=3D=3D=3D The Optical and Grid Computing Symposium will focus on state-of-the-art res= earch topics related to all aspects of optical communications, networking, = experiments, demonstrations, field trials, and applications in support of g= rid/cloud computing. To ensure a complete coverage of the advances in optic= al communication and networking related technologies, the Optical and Grid = Computing Symposium aims at presenting original contributions in, but not l= imited to the following topical areas: -) Optical network architectures -) Transparent and Translucent optical networks -) Elastic/flexible-grid optical networks -) Multi-layer and Multi-domain optical networks -) Optical access networks -) Convergence of optical and wireless networks -) Optical networks to support cloud and grid computing -) Optical network design and reconfiguration -) Optical network control and management -) Software defined optical networks -) Optical network virtualization -) Routing and spectrum assignment -) Protection and restoration -) Traffic grooming and traffic engineering in optical networks -) Impact of the physical-layer impairments on optical network design and t= raffic engineering -) IP-WDM integration -) Multicasting in optical networks -) Optical network security -) Optical switching technologies, devices, and architectures -) Multi-granularity switching -) Field trials, new applications and experiments -) Energy-efficient/green optical networks and systems -) Techno-economic analysis Authors of a number of selected papers will be invited to submit Special Is= sue of the Springer Photonic Network Communications journal. Important Dates: -) Paper submission: July 5, 2015 -) Paper Acceptance: Sept. 20, 2015 -) Camera-ready paper: Oct. 20, 2015 Submission Guidelines =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Please follow the author instructions at http://www.conf-icnc.org/2016/ Direct paper submission weblink can be found at http://edas.info/N19647 Confirmed Invited Speakers =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Prof. Vincent Chan, MIT, USA Prof. Ahmed Kamal, Iowa State University, USA Prof. Rod Tucker, The University of Melbourne Symposium Co-chairs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Paolo Monti School of Information and Communication Technology KTH Royal Institute of Technology Sweden Email: pmonti@kth.se Zuqing Zhu School of Information Science and Technology University of Science and Technology of China China Email: zqzhu@ieee.org --_000_ABCAA4EF18F17B4FB619EA93DEF7939A3348D299eusaamb107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

  FYI CFP below.

 

Best regards,

Meral

 

 

Call for papers ICNC 2016 Optical and Grid Comput= ing Symposium, Kauai, Hawaii, USA, Feb. 15-18, 2016

 

http://= www.conf-icnc.org/2016

 

Scope

=3D=3D=3D=3D=3D

The Optical and Grid Computing Symposium will foc= us on state-of-the-art research topics related to all aspects of optical co= mmunications, networking, experiments, demonstrations, field trials, and ap= plications in support of grid/cloud computing. To ensure a complete coverage of the advances in optical commun= ication and networking related technologies, the Optical and Grid Computing= Symposium aims at presenting original contributions in, but not limited to= the following topical areas:

 

-) Optical network architectures

 

-) Transparent and Translucent optical networks

 

-) Elastic/flexible-grid optical networks

 

-) Multi-layer and Multi-domain optical networks<= o:p>

 

-) Optical access networks

 

-) Convergence of optical and wireless networks

 

-) Optical networks to support cloud and grid com= puting

 

-) Optical network design and reconfiguration

 

-) Optical network control and management

 

-) Software defined optical networks

 

-) Optical network virtualization

 

-) Routing and spectrum assignment

 

-) Protection and restoration

 

-) Traffic grooming and traffic engineering in op= tical networks

 

-) Impact of the physical-layer impairments on op= tical network design and traffic engineering

 

-) IP-WDM integration

 

-) Multicasting in optical networks

 

-) Optical network security

 

-) Optical switching technologies, devices, and a= rchitectures

 

-) Multi-granularity switching

 

-) Field trials, new applications and experiments=

 

-) Energy-efficient/green optical networks and sy= stems

 

-) Techno-economic analysis

 

 

 

Authors of a number of selected papers will be in= vited to submit Special Issue of the Springer Photonic Network Communicatio= ns journal.

 

Important Dates:

 

-) Paper submission: July 5, 2015

 

-) Paper Acceptance: Sept. 20, 2015

 

-) Camera-ready paper: Oct. 20, 2015

 

 

 

Submission Guidelines

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

 

 

 

Please follow the author instructions at http://w= ww.conf-icnc.org/2016/

 

Direct paper submission weblink can be found at h= ttp://edas.info/N19647

 

 

 

Confirmed Invited Speakers

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

Prof. Vincent Chan, MIT, USA

Prof. Ahmed Kamal, Iowa State University, USA

Prof. Rod Tucker, The University of Melbourne

 

Symposium Co-chairs

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

Paolo Monti

 

School of Information and Communication Technolog= y

 

KTH Royal Institute of Technology

 

Sweden

 

Email: pmonti@kth.se<mail= to:pmonti@kth.se>

 

 

 

Zuqing Zhu=

 

School of Information Science and Technology=

 

University of Science and Technology of China

 

China

 

Email: zqzhu@ieee.org<mailto:zqzhu@ieee.org>= ;

 

--_000_ABCAA4EF18F17B4FB619EA93DEF7939A3348D299eusaamb107erics_-- From nobody Tue Jun 16 09:42:31 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95CEC1A8BB7 for ; Tue, 16 Jun 2015 09:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rXeAdcxuCjq for ; Tue, 16 Jun 2015 09:42:28 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4B0E1A896D for ; Tue, 16 Jun 2015 09:42:27 -0700 (PDT) Received: by oiha141 with SMTP id a141so15558443oih.0 for ; Tue, 16 Jun 2015 09:42:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=wf/wS7rNYEh4JvVthOrtNldRw16YH4xzn0rJlFlER28=; b=DbMRvLB2qJSBniezGu+poBMa0sr2i4xLI3jlFD9c5OguvwxZzaEYXfUnmfp+mFiO1m NiVKMfjLTPi/z+XUex3EWSqC6bijqMRZk3eA8NJ2mFgEcXnzNxpAKCWBIexBNoJcUG3O hJ1bKk5Ro8kgPQtASZG802CtLgrvCk2o10Zdwep78xtM1bplegCz8O3UmOyV3t3hvpex TM/bObi+iGqYnM2BxcPLQxW+iY0ZG8uG5grqljKsOeRpen6Eyrv+cE2p5HPzDU+3ee6K aLocB8RNZbCHOkB6FJ98waSyQQQcCxuSJHioPUYgGv9zeSmojt8MeSFSIDr5COQIxJzm 1pJg== X-Received: by 10.182.106.12 with SMTP id gq12mr984584obb.74.1434472947209; Tue, 16 Jun 2015 09:42:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.211.145 with HTTP; Tue, 16 Jun 2015 09:42:06 -0700 (PDT) From: Christian Esteve Rothenberg Date: Tue, 16 Jun 2015 13:42:06 -0300 Message-ID: To: SDN IRTF list Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Sdn] CFP (extended DL: June 30) :: SDWN 2015: 2nd International Conference on Software Defined and Virtualized Future Wireless Networks X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 16:42:30 -0000 Apologies for any duplicates. --Christian ### SDWN15 :: CALL FOR PAPERS ### SDWN 2015: 2nd International Conference on Software Defined and Virtualized Future Wireless Networks Oct 26-27, 2015. Rome, Italy Co-located with the IOT360 Summit. Endorsed by the European Alliance for Innovation (EAI). http://iot-360.eu/2015/ Paper Submission Deadline: June 30, 2015 ** Included in the Springer-LNICST and other indexing services ** http://sdnforwireless.org/2015/ SCOPE =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D While the past few decades have witnessed the rapid growth in mobile and wireless networks, numerous problems and challenges become increasingly serious, such as heterogeneous wireless networks, spectrum scarcity, smooth evolving and fast deployment, technologies innovations, QoS and QoE support, etc. Traditional mobile and wireless network technologies can hardly overcome these challenges. Software-Defined Networking (SDN), an innovative paradigm, has become one of the hottest topics in wired and wireless networking. SDN advocates an effective separation of control plane and data planes, providing new abstractions to both planes exposed through programmatic interfaces. However, many challenges towards the realization of Software-Defined Wireless Networks (SDWN) are still open, including the end-to-end architecture, design and implementation of programmable and virtualized wireless technologies, software defining strategies, etc. At the same time, cloud computing and network virtualization are considered as a promising way that benefits future wireless networks, such as using the cloud computing resource pool providing powerful computing capability to implement the baseband data processing of wireless communication. However, how to design, customize, and utilize the virtualization and cloud computing technologies targeted for the wireless networks are still open problems. Against this background, Software-Defined and Virtualized Future Wireless Network is a new conference that aims to explore the new design space, the new challenges and solutions, as well as new applications and services of software-defined virtualized future mobile and wireless networks. The goal of the conference is to solicit original and inspiring research contributions from technology experts, designers, researchers, and architects in academia and industry. Bringing together practitioners and researchers to share knowledge, experiences, and best practices. TOPICS =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Topics of interests include, but are not limited to: * New end-to-end mobile and wireless network architecture based on SDWN, cloud computing, and virtualization technologies * Cloud computing and network virtualization technologies for RAN, backhaul and core networks * Software-defined and abstracting strategies for network function and air interface technologies in future wireless networks, including 5G * Integration of SDNs with access networks and Evolved Packet Core, including support for services such as handover * Network Functions Virtualisation (NFV) & SDN applications and use cases * QoS/E and traffic-awareness in SDWN * Network management, monitoring and security as northbound APIs inSDWN * Dynamic resource allocation in future wireless networks * Immersive collaborative future wireless media * Network evaluations and testbeds PUBLICATION =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Papers will be published by Springer, LNICST. The proceedings are also submitted for inclusion to the leading indexing services: DBLP, Google Scholar, Thomson Scientific ISI Proceedings, EI Elsevier Engineering Index, CrossRef, Scopus, as well as ICST's own EU Digital Library (EUDL). Selected papers will be published also in the EAI Endorsed Transactions on Cloud Systems. Highlights * The event is endorsed by the European Alliance for Innovation, a leading community-based organization devoted to the advancement of innovation in the field of ICT and will be co-located with the IOT360 Summit; * Participation in this event will give attendees the unique opportunity to be exposed to all technical scientific aspects of IoT related topic areas at co-located conferences, as well as be able to have full access to the IoT marketplace and business aspects in practice at the IOT 360 Summit. * All accepted papers will be published by Springer and made available through SpringerLink Digital Library, one of the world's largest scientific libraries. Best papers will be invited to publish also in the EAI Endorsed Transactions on Cloud Systems. PAPER SUBMISSION =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Authors are invited to submit technical papers presenting original, unpublished research, not currently under review elsewhere. All submissions should be written in English with a maximum length of 8 pages, including all figures, tables, and references, in the PDF format. Paper submissions must follow the SPRINGER formatting guidelines. Please refer to the Author's kit section for formatting and templates (http://sdnforwireless.org/2015/show/authors-kit). IMPORTANT DATES =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Submission deadline (extended!): June 30, 2015 Author notification: July 25, 2015 Camera-ready deadline: August 25, 2015 Start of Conference: October 26, 2015 STEERING AND ORGANIZING COMMITTEE =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Steering Committee Chair: Imrich Chlamtac, Create-Net, Italy General Chair: Bruno Astuto, GE Global Research Center , Brazil Technical Program Chair: Christian Esteve Rothenberg, UNICAMP, Brazil Publicity Chair: Mateus Silva Santos, UNICAMP, Brazil Conference Manager: Kristina Lukacova, European Alliance for Innovation, Slovakia PROGRAM COMMITTEE (confirmed so far) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Athanasios V. Vasilakos, University of Western Macedonia, Greece Giancarlo Fortino, University of Calabria, Italy Giuseppe Carella, TU Berlin, Germany Hui Ni, Huawei, USA Jose F. de Rezende, UFRJ, Brazil Junaid Qadir, National NUST, Pakistan Luis M. Contreras, Telef=C3=B3nica I+D, Spain Mateus Silva Santos, Ericsson Research, Brazil Miguel Elias M. Campista, UFRJ, Brazil Roberto Riggio, Create-Net, Italy Thomas Magedanz, Fraunhofer FOKUS, Germany Wolfgang Kellerer, TU M=C3=BCnchen, Germany Xiaobo Long, Goldman Sachs, USA Xin Wu, Big Switch, USA From nobody Wed Jun 17 14:39:54 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A925C1A0217 for ; Wed, 17 Jun 2015 14:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRn4sditAFk1 for ; Wed, 17 Jun 2015 14:39:51 -0700 (PDT) Received: from ignavia.lancs.ac.uk (ignavia.lancs.ac.uk [148.88.25.16]) by ietfa.amsl.com (Postfix) with ESMTP id 1AFFC1A039F for ; Wed, 17 Jun 2015 14:39:50 -0700 (PDT) Received: from ex-0-ht0.lancs.ac.uk ([10.42.18.47] helo=EX-0-HT0.lancs.local) by ignavia.lancs.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1Z5L3l-0005Js-N7; Wed, 17 Jun 2015 22:39:49 +0100 Received: from EX-0-MB2.lancs.local ([fe80::9d98:936b:54d1:c531]) by EX-0-HT0.lancs.local ([fe80::7d10:114a:53b0:7f2f%12]) with mapi id 14.03.0224.002; Wed, 17 Jun 2015 22:39:49 +0100 From: "King, Daniel" To: "sdn@irtf.org" Thread-Topic: SDNRG CFP for IETF 93 Thread-Index: AdCpRScOgMogZWciQYS4VFMZzqg4fQ== Date: Wed, 17 Jun 2015 21:39:48 +0000 Message-ID: <65174429B5AF4C45BD0798810EC48E0A3242F4CF@EX-0-MB2.lancs.local> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [88.97.23.122] x-iss-local-domain: 1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "dmm@1-4-5.net" Subject: [Sdn] SDNRG CFP for IETF 93 X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2015 21:39:52 -0000 Hi All, =0A= =0A= SDNRG at IETF 93 Call for Presentations=0A= IETF 93 (July 19-24)=0A= Prague, Czech Republic=0A= ---------------------------------------=0A= The Software Defined Networking Research Group (SDNRG) will hold its next m= eeting in conjunction with IETF 93 (July 19-24). The SDNRG Program Committ= ee is now seeking proposals for presentations for the IRTF SDNRG agenda.=0A= =0A= Presentations highlighting current research in SDN and its applications are= encouraged. Areas of interest include (but are not limited to):=0A= =0A= o Classification of SDN models, including Definitions, =0A= Taxonomies=0A= o SDN model scalability and applicability=0A= o Multi-layer programability and feedback control systems=0A= o System Complexity=0A= o Network description languages, abstractions, interfaces and=0A= compilers including methods and mechanisms for (on-line)=0A= verification of correct operation of network/node function. =0A= o Methods for increasing the data-awareness of the network=0A= =0A= The SDNRG is also requesting discussions related to securing Software Defin= ed Networks, areas of interest include (but are not limited to):=0A= =0A= o Trust models=0A= o Protecting and securing the SDN controllers=0A= o Robust policy frameworks=0A= o Forensics and remedial responses =0A= =0A= Key Dates for SDNRG 93=0A= =0A= SDN Research Group Meeting Date/Time/Location is to be determined. =0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=0A= CFP Opens immediately for SDNRG 93.=0A= CFP Deadline #1: Presentation Proposal (Abstracts) Due 8 July.=0A= CFP Deadline #2: Presentation Slides Due 19 July (or slightly earlier if an= SDNRG Monday (20th) meeting.=0A= =0A= BR, Dan & dmm=0A= From nobody Sat Jun 20 12:51:43 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD5281A9148 for ; Sat, 20 Jun 2015 12:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81KF39dkF3bC for ; Sat, 20 Jun 2015 12:51:41 -0700 (PDT) Received: from ignavia.lancs.ac.uk (ignavia.lancs.ac.uk [148.88.25.16]) by ietfa.amsl.com (Postfix) with ESMTP id 227DB1A9145 for ; Sat, 20 Jun 2015 12:51:41 -0700 (PDT) Received: from ex-1-ht0.lancs.ac.uk ([10.42.18.57] helo=EX-1-HT0.lancs.local) by ignavia.lancs.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1Z6Onj-0003D3-SV; Sat, 20 Jun 2015 20:51:39 +0100 Received: from EX-0-MB2.lancs.local ([fe80::9d98:936b:54d1:c531]) by EX-1-HT0.lancs.local ([fe80::d9e8:ad10:d075:a6b6%12]) with mapi id 14.03.0224.002; Sat, 20 Jun 2015 20:51:38 +0100 From: "King, Daniel" To: "sdn@irtf.org" Thread-Topic: SDNRG CFP for IETF 93 Thread-Index: AdCpRScOgMogZWciQYS4VFMZzqg4fQCTEpSQ Date: Sat, 20 Jun 2015 19:51:38 +0000 Message-ID: <65174429B5AF4C45BD0798810EC48E0A3242FDE9@EX-0-MB2.lancs.local> References: <65174429B5AF4C45BD0798810EC48E0A3242F4CF@EX-0-MB2.lancs.local> In-Reply-To: <65174429B5AF4C45BD0798810EC48E0A3242F4CF@EX-0-MB2.lancs.local> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [88.97.23.122] x-iss-local-domain: 1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "dmm@1-4-5.net" Subject: Re: [Sdn] SDNRG CFP for IETF 93 X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2015 19:51:43 -0000 Quick update. The IETF 93 preliminary agenda has been posted. For those born before 1980 - https://datatracker.ietf.org/meeting/93/agenda= .txt Born after 1980 - https://datatracker.ietf.org/meeting/93/agenda.html The SDN RG is tentatively scheduled for: Wednesday, July 22, 2015 (CEST) 9:00-11:30 Morning session I Congress Hall II The final agenda will be published on Friday, June 26th, 2015. =20 BR, Dan.=20 -----Original Message----- From: King, Daniel=20 Sent: 17 June 2015 22:40 To: sdn@irtf.org Cc: dmm@1-4-5.net Subject: SDNRG CFP for IETF 93 Hi All,=20 SDNRG at IETF 93 Call for Presentations IETF 93 (July 19-24) Prague, Czech Republic --------------------------------------- The Software Defined Networking Research Group (SDNRG) will hold its next m= eeting in conjunction with IETF 93 (July 19-24). The SDNRG Program Committ= ee is now seeking proposals for presentations for the IRTF SDNRG agenda. Presentations highlighting current research in SDN and its applications are= encouraged. Areas of interest include (but are not limited to): o Classification of SDN models, including Definitions, =20 Taxonomies o SDN model scalability and applicability o Multi-layer programability an= d feedback control systems o System Complexity o Network description lang= uages, abstractions, interfaces and compilers including methods and mechanisms for (on-line) verification of correct operation of network/node function.=20 o Methods for increasing the data-awareness of the network The SDNRG is also requesting discussions related to securing Software Defin= ed Networks, areas of interest include (but are not limited to): o Trust models o Protecting and securing the SDN controllers o Robust policy frameworks = o Forensics and remedial responses =20 Key Dates for SDNRG 93 SDN Research Group Meeting Date/Time/Location is to be determined.=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D CFP Opens immediately for SDNRG 93. CFP Deadline #1: Presentation Proposal (Abstracts) Due 8 July. CFP Deadline #2: Presentation Slides Due 19 July (or slightly earlier if an= SDNRG Monday (20th) meeting. BR, Dan & dmm From nobody Sat Jun 20 12:58:26 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79C6B1A9172 for ; Sat, 20 Jun 2015 12:58:25 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains application/ms-tnef, .tnef, winmail.dat X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTdQ4jjdUhBx for ; Sat, 20 Jun 2015 12:58:24 -0700 (PDT) Received: from ignavia.lancs.ac.uk (ignavia.lancs.ac.uk [148.88.25.16]) by ietfa.amsl.com (Postfix) with ESMTP id 042E81A9170 for ; Sat, 20 Jun 2015 12:58:24 -0700 (PDT) Received: from ex-0-ht0.lancs.ac.uk ([10.42.18.47] helo=EX-0-HT0.lancs.local) by ignavia.lancs.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1Z6OuF-0003sW-BK for sdn@irtf.org; Sat, 20 Jun 2015 20:58:23 +0100 Received: from EX-0-MB2.lancs.local ([fe80::9d98:936b:54d1:c531]) by EX-0-HT0.lancs.local ([fe80::7d10:114a:53b0:7f2f%12]) with mapi id 14.03.0224.002; Sat, 20 Jun 2015 20:58:23 +0100 Content-Type: multipart/mixed; boundary="_000_65174429B5AF4C45BD0798810EC48E0A3242FDFDEX0MB2lancsloca_" From: "King, Daniel" To: "'sdn@irtf.org'" Thread-Topic: IETF 93 - Tutorial for SDN OpenFlow and ForCES Thread-Index: AdCrkp9Mak8RNrERQiWQPaEzD5iqSQ== Date: Sat, 20 Jun 2015 19:58:21 +0000 Message-ID: <65174429B5AF4C45BD0798810EC48E0A3242FDFD@EX-0-MB2.lancs.local> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: <65174429B5AF4C45BD0798810EC48E0A3242FDFD@EX-0-MB2.lancs.local> x-originating-ip: [88.97.23.122] x-iss-local-domain: 1 MIME-Version: 1.0 Archived-At: Subject: [Sdn] IETF 93 - Tutorial for SDN OpenFlow and ForCES X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2015 19:58:25 -0000 --_000_65174429B5AF4C45BD0798810EC48E0A3242FDFDEX0MB2lancsloca_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, There will be a "Tutorial for SDN OpenFlow and ForCES" at IETF 93 on Sunday= , July 19, 2015. The tutorial info page is at ietf.org/meeting/93/tutorial= s/sdn.html. >> Presented by: Yaakov Stein and Evangelos Haleplidis Day: Sunday, July 19, 2015 Time: 15:00-17:00 Room: TBD Description: 1. The ideas behind the recent awaking of SDN 2. How an SDN is different from a conventional (routed) network 3. The components and interfaces of an SDN (SDN (whitebox) switch, SDN cont= roller, SBI, NBI) 4. NFV 5. The southbound interfaces (OpenFlow, ForCES, ...) 5.1 Zoom in on OpenFlow 5.2 Zoom in on ForCES << Check the Tutorial link for room assignment closer to the session. BR, Dan. --_000_65174429B5AF4C45BD0798810EC48E0A3242FDFDEX0MB2lancsloca_ Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 Content-Type: application/ms-tnef; name="winmail.dat" eJ8+IvsRAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEJgAEAIQAAADI2RTQ5OUEy RUIwNjZCNENBMjMyRTIwQkE0OUVDQkFFAGEHAQ2ABAACAAAAAgACAAEFgAMADgAAAN8HBgAUABMA OgAVAAYAaAEBIIADAA4AAADfBwYAFAATADoAFQAGAGgBAQiABwAYAAAASVBNLk1pY3Jvc29mdCBN YWlsLk5vdGUAMQgBBIABAC8AAABJRVRGIDkzIC0gVHV0b3JpYWwgZm9yIFNETiBPcGVuRmxvdyBh bmQgRm9yQ0VTAKAOAQOQBgBUGAAAOwAAAAIBfwABAAAAQAAAADw2NTE3NDQyOUI1QUY0QzQ1QkQw Nzk4ODEwRUM0OEUwQTMyNDJGREZEQEVYLTAtTUIyLmxhbmNzLmxvY2FsPgACARMQAQAAAKAOAAA8 aHRtbCB4bWxuczp2PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOnZtbCIgeG1sbnM6bz0idXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4bWxuczp3PSJ1cm46c2NoZW1h cy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNy b3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9U Ui9SRUMtaHRtbDQwIj48aGVhZD48TUVUQSBIVFRQLUVRVUlWPSJDb250ZW50LVR5cGUiIENPTlRF TlQ9InRleHQvaHRtbDsgY2hhcnNldD11cy1hc2NpaSI+PG1ldGEgbmFtZT1HZW5lcmF0b3IgY29u dGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8q IFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNv Tm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1H QiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQ0E+SGkgQWxsLCA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQ0E+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUNBPlRoZXJl IHdpbGwgYmUgYSAmIzgyMjA7VHV0b3JpYWwgZm9yIFNETiBPcGVuRmxvdyBhbmQgRm9yQ0VTJiM4 MjIxOyBhdCBJRVRGIDkzIG9uIFN1bmRheSwgSnVseSAxOSwgMjAxNS4gVGhlIHR1dG9yaWFsIGlu Zm8gcGFnZSBpcyBhdCAmbmJzcDs8YSBocmVmPSJodHRwOi8vaWV0Zi5vcmcvbWVldGluZy85My90 dXRvcmlhbHMvc2RuLmh0bWwiPmlldGYub3JnL21lZXRpbmcvOTMvdHV0b3JpYWxzL3Nkbi5odG1s PC9hPi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9 RU4tQ0E+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBsYW5nPUVOLUNBPiZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUNBPlByZXNlbnRlZCBieTogWWFha292IFN0ZWluIGFu ZCBFdmFuZ2Vsb3MgSGFsZXBsaWRpczxicj5EYXk6IFN1bmRheSwgSnVseSAxOSwgMjAxNTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1DQT5UaW1l OiAxNTowMC0xNzowMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gbGFuZz1FTi1DQT5Sb29tOiBUQkQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIGxhbmc9RU4tQ0E+RGVzY3JpcHRpb246PG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUNBPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1DQT4xLiBUaGUgaWRlYXMg YmVoaW5kIHRoZSByZWNlbnQgYXdha2luZyBvZiBTRE48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQ0E+Mi4gSG93IGFuIFNETiBpcyBkaWZmZXJl bnQgZnJvbSBhIGNvbnZlbnRpb25hbCAocm91dGVkKSBuZXR3b3JrPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUNBPjMuIFRoZSBjb21wb25lbnRz IGFuZCBpbnRlcmZhY2VzIG9mIGFuIFNETiAoU0ROICh3aGl0ZWJveCkgc3dpdGNoLCBTRE4gY29u dHJvbGxlciwgU0JJLCBOQkkpPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBsYW5nPUVOLUNBPjQuIE5GVjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1DQT41LiBUaGUgc291dGhib3VuZCBpbnRlcmZhY2VzIChP cGVuRmxvdywgRm9yQ0VTLCAuLi4pPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBsYW5nPUVOLUNBPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA1LjEgWm9vbSBp biBvbiBPcGVuRmxvdzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gbGFuZz1FTi1DQT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgNS4yIFpvb20gaW4gb24gRm9y Q0VTPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVO LUNBPiZsdDsmbHQ7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBsYW5nPUVOLUNBPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1DQT5DaGVjayB0aGUgVHV0b3JpYWwgbGluayBmb3Igcm9v bSBhc3NpZ25tZW50IGNsb3NlciB0byB0aGUgc2Vzc2lvbi4gPG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUNBPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1DQT5CUiwgRGFuLiA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9ib2R5PjwvaHRtbD4fAEIAAQAAABoAAABLAGkAbgBn ACwAIABEAGEAbgBpAGUAbAAAAAAAHwBlAAEAAAAuAAAAZAAuAGsAaQBuAGcAQABsAGEAbgBjAGEA cwB0AGUAcgAuAGEAYwAuAHUAawAAAAAAHwBkAAEAAAAKAAAAUwBNAFQAUAAAAAAAAgFBAAEAAABq AAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAACASwBpAG4AZwAsACAARABhAG4AaQBlAGwAAABTAE0A VABQAAAAZAAuAGsAaQBuAGcAQABsAGEAbgBjAGEAcwB0AGUAcgAuAGEAYwAuAHUAawAAAAAAHwAC XQEAAAAuAAAAZAAuAGsAaQBuAGcAQABsAGEAbgBjAGEAcwB0AGUAcgAuAGEAYwAuAHUAawAAAAAA HwDlXwEAAAAEAAAAIAAAAB8AGgwBAAAAGgAAAEsAaQBuAGcALAAgAEQAYQBuAGkAZQBsAAAAAAAf AB8MAQAAAC4AAABkAC4AawBpAG4AZwBAAGwAYQBuAGMAYQBzAHQAZQByAC4AYQBjAC4AdQBrAAAA AAAfAB4MAQAAAAoAAABTAE0AVABQAAAAAAACARkMAQAAAGoAAAAAAAAAgSsfpL6jEBmdbgDdAQ9U AgAAAIBLAGkAbgBnACwAIABEAGEAbgBpAGUAbAAAAFMATQBUAFAAAABkAC4AawBpAG4AZwBAAGwA YQBuAGMAYQBzAHQAZQByAC4AYQBjAC4AdQBrAAAAAAAfAAFdAQAAAC4AAABkAC4AawBpAG4AZwBA AGwAYQBuAGMAYQBzAHQAZQByAC4AYQBjAC4AdQBrAAAAAAAfAPg/AQAAABoAAABLAGkAbgBnACwA IABEAGEAbgBpAGUAbAAAAAAAHwAjQAEAAAAuAAAAZAAuAGsAaQBuAGcAQABsAGEAbgBjAGEAcwB0 AGUAcgAuAGEAYwAuAHUAawAAAAAAHwAiQAEAAAAKAAAAUwBNAFQAUAAAAAAAAgH5PwEAAABqAAAA AAAAAIErH6S+oxAZnW4A3QEPVAIAAACASwBpAG4AZwAsACAARABhAG4AaQBlAGwAAABTAE0AVABQ AAAAZAAuAGsAaQBuAGcAQABsAGEAbgBjAGEAcwB0AGUAcgAuAGEAYwAuAHUAawAAAAAAHwAJXQEA AAAuAAAAZAAuAGsAaQBuAGcAQABsAGEAbgBjAGEAcwB0AGUAcgAuAGEAYwAuAHUAawAAAAAACwBA OgEAAAAfABoAAQAAABIAAABJAFAATQAuAE4AbwB0AGUAAAAAAAMA8T8JBAAACwBAOgEAAAADAP0/ 5AQAAAIBCzABAAAAEAAAACbkmaLrBmtMojLiC6Sey64DABcAAQAAAEAAOQCA7Eh1k6vQAUAACDAe hZR1k6vQAQsAKQAAAAAACwAjAAAAAAAfAACAhgMCAAAAAADAAAAAAAAARgEAAAAeAAAAYQBjAGMA ZQBwAHQAbABhAG4AZwB1AGEAZwBlAAAAAAABAAAAGgAAAGUAbgAtAEcAQgAsACAAZQBuAC0AVQBT AAAAAAALAACACCAGAAAAAADAAAAAAAAARgAAAAAGhQAAAAAAAB8ANwABAAAAXgAAAEkARQBUAEYA IAA5ADMAIAAtACAAVAB1AHQAbwByAGkAYQBsACAAZgBvAHIAIABTAEQATgAgAE8AcABlAG4ARgBs AG8AdwAgAGEAbgBkACAARgBvAHIAQwBFAFMAAAAAAB8APQABAAAAAgAAAAAAAAADADYAAAAAAAIB cQABAAAAFgAAAAHQq5KfTGpPETaxEUIlkD2hMw+YqkkAAB8AcAABAAAAXgAAAEkARQBUAEYAIAA5 ADMAIAAtACAAVAB1AHQAbwByAGkAYQBsACAAZgBvAHIAIABTAEQATgAgAE8AcABlAG4ARgBsAG8A dwAgAGEAbgBkACAARgBvAHIAQwBFAFMAAAAAAB8ANRABAAAAgAAAADwANgA1ADEANwA0ADQAMgA5 AEIANQBBAEYANABDADQANQBCAEQAMAA3ADkAOAA4ADEAMABFAEMANAA4AEUAMABBADMAMgA0ADIA RgBEAEYARABAAEUAWAAtADAALQBNAEIAMgAuAGwAYQBuAGMAcwAuAGwAbwBjAGEAbAA+AAAAAwDe P59OAAALAACACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMAAIAIIAYAAAAAAMAAAAAAAABG AAAAAAGFAAAAAAAAAwCAEP////9AAAcwbvR3dZOr0AELAAIAAQAAAAMAJgAAAAAAAgFHAAEAAAA7 AAAAYz1HQjthPSA7cD1MYW5jYXN0ZXIgVW5pdmVyO2w9RVgtMC1NQjItMTUwNjIwMTk1ODIxWi02 MjEzOAAAAgEQMAEAAABGAAAAAAAAAORW9aV8zwZCpU32TjBC9i8HABfTwcbwqapOvGjDDjvY+7oA AATA93UAABMtdg+zRKhDucjAQoV64AgAMi+EjEUAAAAAHwD6PwEAAAAaAAAASwBpAG4AZwAsACAA RABhAG4AaQBlAGwAAAAAAAMAAlkAABYAAwAJWQIAAAADAACACCAGAAAAAADAAAAAAAAARgAAAAAQ hQAAAAAAAAMAAIAIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAACwAAgAggBgAAAAAAwAAAAAAA AEYAAAAAgoUAAAAAAAALAACACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAEAAAIAIIAYAAAAA AMAAAAAAAABGAAAAAL+FAADgLfd1k6vQAQMAAIAIIAYAAAAAAMAAAAAAAABGAAAAAOuFAAAJCAAA AwANNP0/AAAfAACAhgMCAAAAAADAAAAAAAAARgEAAAAgAAAAeAAtAG0AcwAtAGgAYQBzAC0AYQB0 AHQAYQBjAGgAAAABAAAAAgAAAAAAAAAfAACAhgMCAAAAAADAAAAAAAAARgEAAAAiAAAAeAAtAG8A cgBpAGcAaQBuAGEAdABpAG4AZwAtAGkAcAAAAAAAAQAAAB4AAABbADgAOAAuADkANwAuADIAMwAu ADEAMgAyAF0AAAAAAB8AAICGAwIAAAAAAMAAAAAAAABGAQAAACYAAAB4AC0AaQBzAHMALQBsAG8A YwBhAGwALQBkAG8AbQBhAGkAbgAAAAAAAQAAAAQAAAAxAAAAL0M= --_000_65174429B5AF4C45BD0798810EC48E0A3242FDFDEX0MB2lancsloca_-- From nobody Mon Jun 22 04:09:09 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89CE71B2F73 for ; Mon, 22 Jun 2015 04:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5oTLKcvTcyo for ; Mon, 22 Jun 2015 04:09:06 -0700 (PDT) Received: from mx4.qub.ac.uk (mx6.qub.ac.uk [143.117.16.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1B3E1B2F72 for ; Mon, 22 Jun 2015 04:09:03 -0700 (PDT) Received: from ex2k10-365a.ads.qub.ac.uk ([143.117.16.107] helo=owa.qub.ac.uk) by mx4.qub.ac.uk with esmtp (Exim 4.80.1) (envelope-from ) id 1Z6zb4-0002NE-0W for sdn@irtf.org; Mon, 22 Jun 2015 12:09:02 +0100 Received: from EX2K10-MBX8.ads.qub.ac.uk ([fe80::11ff:46e3:6a46:c5ed]) by EX2K10-365A.ads.qub.ac.uk ([2002:8f75:106b::8f75:106b]) with mapi id 14.03.0224.002; Mon, 22 Jun 2015 12:09:02 +0100 From: Sandra Scott-Hayward To: "sdn@irtf.org" Thread-Topic: SDNRG CFP IETF 93 - Protect and Secure SDN Controllers Thread-Index: AdCs20h5QV8lahrER5CmZFXvKAlBmQ== Date: Mon, 22 Jun 2015 11:09:01 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [143.117.16.67] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Sdn] SDNRG CFP IETF 93 - Protect and Secure SDN Controllers X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 11:09:08 -0000 Hi Dan, I haven't previously been involved in an IETF meeting although I've been fo= llowing SDNRG for the past couple of years. I won't be able to attend the m= eeting in Prague. Do you facilitate webex presentations?=20 If so, I would be interested in presenting/joining in the discussion regard= ing "Protection and Security of SDN Controllers". I recently published a pa= per on this topic at IEEE NetSoft 2015. Please let me know if this is possible and/or of interest to the community. Thank you very much. Kind Regards, Sandra Scott-Hayward Queen's University Belfast -----Original Message----- From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of sdn-request@irtf.org Sent: 18 June 2015 20:00 To: sdn@irtf.org Subject: sdn Digest, Vol 37, Issue 23 Send sdn mailing list submissions to sdn@irtf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.irtf.org/mailman/listinfo/sdn or, via email, send a message with subject or body 'help' to sdn-request@irtf.org You can reach the person managing the list at sdn-owner@irtf.org When replying, please edit your Subject line so it is more specific than "R= e: Contents of sdn digest..." Today's Topics: 1. SDNRG CFP for IETF 93 (King, Daniel) ---------------------------------------------------------------------- Message: 1 Date: Wed, 17 Jun 2015 21:39:48 +0000 From: "King, Daniel" To: "sdn@irtf.org" Cc: "dmm@1-4-5.net" Subject: [Sdn] SDNRG CFP for IETF 93 Message-ID: <65174429B5AF4C45BD0798810EC48E0A3242F4CF@EX-0-MB2.lancs.local> Content-Type: text/plain; charset=3D"us-ascii" Hi All,=20 SDNRG at IETF 93 Call for Presentations IETF 93 (July 19-24) Prague, Czech Republic --------------------------------------- The Software Defined Networking Research Group (SDNRG) will hold its next m= eeting in conjunction with IETF 93 (July 19-24). The SDNRG Program Committ= ee is now seeking proposals for presentations for the IRTF SDNRG agenda. Presentations highlighting current research in SDN and its applications are= encouraged. Areas of interest include (but are not limited to): o Classification of SDN models, including Definitions, =20 Taxonomies o SDN model scalability and applicability o Multi-layer programability an= d feedback control systems o System Complexity o Network description lang= uages, abstractions, interfaces and compilers including methods and mechanisms for (on-line) verification of correct operation of network/node function.=20 o Methods for increasing the data-awareness of the network The SDNRG is also requesting discussions related to securing Software Defin= ed Networks, areas of interest include (but are not limited to): o Trust models o Protecting and securing the SDN controllers o Robust policy frameworks = o Forensics and remedial responses =20 Key Dates for SDNRG 93 SDN Research Group Meeting Date/Time/Location is to be determined.=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D CFP Opens immediately for SDNRG 93. CFP Deadline #1: Presentation Proposal (Abstracts) Due 8 July. CFP Deadline #2: Presentation Slides Due 19 July (or slightly earlier if an= SDNRG Monday (20th) meeting. BR, Dan & dmm ------------------------------ Subject: Digest Footer _______________________________________________ sdn mailing list sdn@irtf.org https://www.irtf.org/mailman/listinfo/sdn ------------------------------ End of sdn Digest, Vol 37, Issue 23 *********************************** From nobody Mon Jun 22 04:22:30 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E36F81B2F78 for ; Mon, 22 Jun 2015 04:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sp4cfCUSt7r1 for ; Mon, 22 Jun 2015 04:22:28 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A556E1ACE99 for ; Mon, 22 Jun 2015 04:22:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXU73618; Mon, 22 Jun 2015 11:22:26 +0000 (GMT) Received: from LHREML504-MBS.china.huawei.com ([10.125.30.107]) by lhreml403-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Mon, 22 Jun 2015 12:22:23 +0100 From: Hosnieh Rafiee To: "sdn@irtf.org" Thread-Topic: SDN secure authentication Thread-Index: AdCs3bQ46xuE7rOQRI2loRecCV8a1Q== Date: Mon, 22 Jun 2015 11:22:22 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A701550E9F@lhreml504-mbs> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.212] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Sdn] SDN secure authentication X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 11:22:29 -0000 Hi All, If the time allows and there is any free slot, I would like to discuss abou= t a secure authentication model for SDN solution (an adaptable PKI model fo= r TLS based authentication) with combination to an authorization model whic= h supports isolation and allow different access controls.=20 Thanks, Best, Hosnieh From nobody Wed Jun 24 05:37:40 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 629D61A8A76 for ; Wed, 24 Jun 2015 05:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d_LhNHYaRs2Z for ; Wed, 24 Jun 2015 05:37:35 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C7741A1B8C for ; Wed, 24 Jun 2015 05:37:34 -0700 (PDT) Received: from 172.24.2.119 (EHLO nkgeml407-hub.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CNO68381; Wed, 24 Jun 2015 20:37:24 +0800 (CST) Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.89]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Wed, 24 Jun 2015 20:37:17 +0800 From: "Songhaibin (A)" To: "sdn@irtf.org" Thread-Topic: Re: [Sdn] SDNRG CFP for IETF 93 Thread-Index: AdCueab47QKGxkTWRV6wPscpXhvrUw== Date: Wed, 24 Jun 2015 12:37:16 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.65.84] Content-Type: multipart/alternative; boundary="_000_E33E01DFD5BEA24B9F3F18671078951F652B0A10nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "d.king@lancaster.ac.uk" Subject: Re: [Sdn] SDNRG CFP for IETF 93 X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 12:37:38 -0000 --_000_E33E01DFD5BEA24B9F3F18671078951F652B0A10nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Daniel, If time allows, I would also like to present a general threat analysis topi= c to SDN. BR, -Haibin --_000_E33E01DFD5BEA24B9F3F18671078951F652B0A10nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Daniel,

 

If time allows, I would also li= ke to present a general threat analysis topic to SDN.

 

BR,

-Haibin

--_000_E33E01DFD5BEA24B9F3F18671078951F652B0A10nkgeml501mbschi_-- From nobody Wed Jun 24 08:12:14 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 891091A88DC for ; Wed, 24 Jun 2015 08:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJe9ignG_KKs for ; Wed, 24 Jun 2015 08:12:11 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1AD11A6EED for ; Wed, 24 Jun 2015 08:12:11 -0700 (PDT) Received: by oigx81 with SMTP id x81so31976036oig.1 for ; Wed, 24 Jun 2015 08:12:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=BaHUThPwBVLfwvoWidpkE8uzqq5FSf6nYjYaP4mPL64=; b=TbOsMMCcpKN87B5HBRCmGP3kdAyfUPL5J88KmzPPRedkT9lVz5cN9nff2ifKEtTazj UbfhGoXSGByuoC0y7bgWZOwIefA6Ny0rn1xAWNM5lhfVo3hxSeyGx7xC1laQme/Xgjxw 26i2lgWYv+DGs6ZmDtFLFdUOE2IqOE4R8ThC3GiZiyrmdubZnLlFWOtXd35hejcZc0xP RByCDj1t4f/S6Ahoq4+yYZzRJgphkSK72PjCaQ6ASkKpw4PI0R4FO5Ay1p+PFqEN7iIH MZL3D1SEzfkAu+rSYaXzLvuduwNUMgsIksJc2stSh0brly4HVjxc+hzVj6BdhDoKzEeO v+mg== MIME-Version: 1.0 X-Received: by 10.60.37.73 with SMTP id w9mr34957159oej.49.1435158731244; Wed, 24 Jun 2015 08:12:11 -0700 (PDT) Sender: rodrigoruasoliveira@gmail.com Received: by 10.202.224.137 with HTTP; Wed, 24 Jun 2015 08:12:11 -0700 (PDT) Received: by 10.202.224.137 with HTTP; Wed, 24 Jun 2015 08:12:11 -0700 (PDT) In-Reply-To: References: Date: Wed, 24 Jun 2015 12:12:11 -0300 X-Google-Sender-Auth: 7jhVVKLgqlatCOEFalrwCpEbVes Message-ID: From: Rodrigo Ruas Oliveira To: "Songhaibin (A)" Content-Type: multipart/alternative; boundary=089e013cc2d65f49ce051944ee7c Archived-At: Cc: "d.king@lancaster.ac.uk" , sdn@irtf.org Subject: Re: [Sdn] SDNRG CFP for IETF 93 X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 15:12:13 -0000 --089e013cc2d65f49ce051944ee7c Content-Type: text/plain; charset=UTF-8 Is it possible to participate online (ie. watch/hear and post questions)? I am very interested in this topic. Em 24/06/2015 09:37, "Songhaibin (A)" escreveu: > Hi Daniel, > > > > If time allows, I would also like to present a general threat analysis > topic to SDN. > > > > BR, > > -Haibin > > _______________________________________________ > sdn mailing list > sdn@irtf.org > https://www.irtf.org/mailman/listinfo/sdn > > --089e013cc2d65f49ce051944ee7c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Is it possible to participate online (ie. watch/hear and pos= t questions)? I am very interested in this topic.

Em 24/06/2015 09:37, "Songhaibin (A)" = <haibin.song@huawei.com>= ; escreveu:

Hi Daniel,=

=C2=A0

If time allows, I would also li= ke to present a general threat analysis topic to SDN.<= /p>

=C2=A0

BR,

-Haibin


_______________________________________________
sdn mailing list
sdn@irtf.org
https://www.irtf.org/mailman/listinfo/sdn

--089e013cc2d65f49ce051944ee7c-- From nobody Wed Jun 24 16:46:57 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEBFB1AD333 for ; Wed, 24 Jun 2015 16:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 372FnPaKujoq for ; Wed, 24 Jun 2015 16:46:55 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F39C1AD2F6 for ; Wed, 24 Jun 2015 16:46:55 -0700 (PDT) Received: by wguu7 with SMTP id u7so48623518wgu.3 for ; Wed, 24 Jun 2015 16:46:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=hYo6MdRSUEScU+aSHswarPmI+EjUncKRVTUIV/0g24s=; b=ZWn65xaEK41kHfbLMgWVBj/O2+YAm3E5fyp7kauB+v7jVTXctm+EL+fYGUPbOUjkUe VlhXk3GWIycV9WIm4OxrOjsE0TFW+mKAEKkuj0ED4aheddj2l0v+cLP4J26Z6gKQDF4V PUelVLn9oYWCtS6SOnARYzfzD8csHEwaHeFdiiIzDcqGnYADX1bSPn2S4ZRKboVQ6zkI MTSczMUD5YoRN5hDJWO9LLzcJhBov5rZFJ6zHQLhQOekrJIwXyoErB2ss8sbIYXlgRzl XeyaJa+dHcI1afnFvAHZtjxPAW/EXcQaP9g6ZPciVvITcXO3jQ2V6k2qr0wvbT6qbVNf 6akA== MIME-Version: 1.0 X-Received: by 10.180.218.195 with SMTP id pi3mr456699wic.71.1435189613922; Wed, 24 Jun 2015 16:46:53 -0700 (PDT) Sender: ghanwani@gmail.com Received: by 10.27.12.35 with HTTP; Wed, 24 Jun 2015 16:46:53 -0700 (PDT) In-Reply-To: <65174429B5AF4C45BD0798810EC48E0A3242FDFD@EX-0-MB2.lancs.local> References: <65174429B5AF4C45BD0798810EC48E0A3242FDFD@EX-0-MB2.lancs.local> Date: Wed, 24 Jun 2015 16:46:53 -0700 X-Google-Sender-Auth: sKXripoLMUtc2ACNz9h2_SDiPn4 Message-ID: From: Anoop Ghanwani To: "King, Daniel" Content-Type: multipart/alternative; boundary=001a1134ce041f8e6e05194c1fbb Archived-At: Cc: "sdn@irtf.org" Subject: Re: [Sdn] IETF 93 - Tutorial for SDN OpenFlow and ForCES X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 23:46:57 -0000 --001a1134ce041f8e6e05194c1fbb Content-Type: text/plain; charset=UTF-8 Where does I2RS fit in within this framework? Is it not considered SDN? Anoop On Sat, Jun 20, 2015 at 12:58 PM, King, Daniel wrote: > Hi All, > > There will be a "Tutorial for SDN OpenFlow and ForCES" at IETF 93 on > Sunday, July 19, 2015. The tutorial info page is at > ietf.org/meeting/93/tutorials/sdn.html< > http://ietf.org/meeting/93/tutorials/sdn.html>. > > >> > Presented by: Yaakov Stein and Evangelos Haleplidis > Day: Sunday, July 19, 2015 > Time: 15:00-17:00 > Room: TBD > Description: > > 1. The ideas behind the recent awaking of SDN > 2. How an SDN is different from a conventional (routed) network > 3. The components and interfaces of an SDN (SDN (whitebox) switch, SDN > controller, SBI, NBI) > 4. NFV > 5. The southbound interfaces (OpenFlow, ForCES, ...) > 5.1 Zoom in on OpenFlow > 5.2 Zoom in on ForCES > << > > Check the Tutorial link for room assignment closer to the session. > > BR, Dan. > > _______________________________________________ > sdn mailing list > sdn@irtf.org > https://www.irtf.org/mailman/listinfo/sdn > > --001a1134ce041f8e6e05194c1fbb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Where does I2RS fit in within this framework?=C2=A0 Is it = not considered SDN?

Anoop

On Sat, Jun 20, 2015 at 12:58 PM, Ki= ng, Daniel <d.king@lancaster.ac.uk> wrote:
Hi All,

There will be a "Tutorial for SDN OpenFlow and ForCES" at IETF 93= on Sunday, July 19, 2015. The tutorial info page is at=C2=A0 ietf.org/meeting/93/tutorials/sdn.html<ht= tp://ietf.org/meeting/93/tutorials/sdn.html>.

>>
Presented by: Yaakov Stein and Evangelos Haleplidis
Day: Sunday, July 19, 2015
Time: 15:00-17:00
Room: TBD
Description:

1. The ideas behind the recent awaking of SDN
2. How an SDN is different from a conventional (routed) network
3. The components and interfaces of an SDN (SDN (whitebox) switch, SDN cont= roller, SBI, NBI)
4. NFV
5. The southbound interfaces (OpenFlow, ForCES, ...)
=C2=A0 =C2=A0 =C2=A05.1 Zoom in on OpenFlow
=C2=A0 =C2=A0 =C2=A05.2 Zoom in on ForCES
<<

Check the Tutorial link for room assignment closer to the session.

BR, Dan.

_______________________________________________
sdn mailing list
sdn@irtf.org
https://www.irtf.org/mailman/listinfo/sdn


--001a1134ce041f8e6e05194c1fbb-- From nobody Thu Jun 25 06:41:43 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA331A8894 for ; Thu, 25 Jun 2015 06:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.483 X-Spam-Level: X-Spam-Status: No, score=0.483 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RELAY_IS_203=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfVtCdBZ1rmk for ; Thu, 25 Jun 2015 06:41:39 -0700 (PDT) Received: from GWS06.hcl.com (gws06.hcl.com [203.105.185.25]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1BCD1A884B for ; Thu, 25 Jun 2015 06:41:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,677,1427740200"; d="scan'208";a="149459206" Received: from unknown (HELO NDA-CORP-HT03.CORP.HCL.IN) ([10.248.64.35]) by GWS06.hcl.com with ESMTP/TLS/AES128-SHA; 25 Jun 2015 19:11:33 +0530 Received: from NDA-HCLT-CSHT06.HCLT.CORP.HCL.IN (10.98.132.31) by NDA-CORP-HT03.CORP.HCL.IN (10.248.64.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 25 Jun 2015 19:11:33 +0530 Received: from NDA-HCLT-MBS05.HCLT.CORP.HCL.IN ([10.98.132.20]) by NDA-HCLT-CSHT06.HCLT.CORP.HCL.IN ([10.98.132.31]) with mapi id 14.03.0123.003; Thu, 25 Jun 2015 19:11:32 +0530 From: "Saurabh Chattopadhyay - ERS, HCL Tech" To: "sdn@irtf.org" Thread-Topic: SDNRG CFP for IETF 93 Thread-Index: AdCpRScOgMogZWciQYS4VFMZzqg4fQGBgJ0A Date: Thu, 25 Jun 2015 13:41:33 +0000 Message-ID: <0485B327B8B60746B28858F5E20781F6658E7027@NDA-HCLT-MBS05.hclt.corp.hcl.in> References: <65174429B5AF4C45BD0798810EC48E0A3242F4CF@EX-0-MB2.lancs.local> In-Reply-To: <65174429B5AF4C45BD0798810EC48E0A3242F4CF@EX-0-MB2.lancs.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.96.4.252] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "King, Daniel" , "Kaushik Datta - ERS, HCL Tech" Subject: Re: [Sdn] SDNRG CFP for IETF 93 X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 13:41:42 -0000 Hi Daniel, If time allows, we would like to present an analysis on SDN Trust Models an= d possible implementation methodologies. We submitted a draft (https://tool= s.ietf.org/html/draft-chattopadhyay-sdnrg-multi-party-sdn-trust-00) on this= few months back, and will look forward to discuss this further in the RG. = Regards, Saurabh ::DISCLAIMER:: ---------------------------------------------------------------------------= ------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and inte= nded for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as informa= tion could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in trans= mission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability = on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the = author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, disse= mination, copying, disclosure, modification, distribution and / or publication of this message without the prior written= consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please= delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses = and other defects. ---------------------------------------------------------------------------= ------------------------------------------------------------------------- From nobody Fri Jun 26 01:32:56 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FEC81A0158 for ; Fri, 26 Jun 2015 01:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDLEjZQZYxXm for ; Fri, 26 Jun 2015 01:32:53 -0700 (PDT) Received: from ignavia.lancs.ac.uk (ignavia.lancs.ac.uk [148.88.25.16]) by ietfa.amsl.com (Postfix) with ESMTP id 9F69F1A0100 for ; Fri, 26 Jun 2015 01:32:53 -0700 (PDT) Received: from ex-1-ht0.lancs.ac.uk ([10.42.18.57] helo=EX-1-HT0.lancs.local) by ignavia.lancs.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1Z8P48-0000xs-Ea; Fri, 26 Jun 2015 09:32:52 +0100 Received: from EX-0-MB2.lancs.local ([fe80::9d98:936b:54d1:c531]) by EX-1-HT0.lancs.local ([fe80::d9e8:ad10:d075:a6b6%12]) with mapi id 14.03.0224.002; Fri, 26 Jun 2015 09:32:52 +0100 From: "King, Daniel" To: Sandra Scott-Hayward Thread-Topic: SDNRG CFP IETF 93 - Protect and Secure SDN Controllers Thread-Index: AdCs20h5QV8lahrER5CmZFXvKAlBmQDDzCyw Date: Fri, 26 Jun 2015 08:32:51 +0000 Message-ID: <65174429B5AF4C45BD0798810EC48E0A32432709@EX-0-MB2.lancs.local> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [88.97.23.122] x-iss-local-domain: 1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sdn@irtf.org" Subject: Re: [Sdn] SDNRG CFP IETF 93 - Protect and Secure SDN Controllers X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 08:32:55 -0000 Hi Sandra,=20 We have had limited success in the past with remote presentations. Let me i= nvestigate further and see what options we have.=20 BR, Dan.=20 -----Original Message----- From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of Sandra Scott-Hayward Sent: 22 June 2015 12:09 To: sdn@irtf.org Subject: Re: [Sdn] SDNRG CFP IETF 93 - Protect and Secure SDN Controllers Hi Dan, I haven't previously been involved in an IETF meeting although I've been fo= llowing SDNRG for the past couple of years. I won't be able to attend the m= eeting in Prague. Do you facilitate webex presentations?=20 If so, I would be interested in presenting/joining in the discussion regard= ing "Protection and Security of SDN Controllers". I recently published a pa= per on this topic at IEEE NetSoft 2015. Please let me know if this is possible and/or of interest to the community. Thank you very much. Kind Regards, Sandra Scott-Hayward Queen's University Belfast -----Original Message----- From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of sdn-request@irtf.org Sent: 18 June 2015 20:00 To: sdn@irtf.org Subject: sdn Digest, Vol 37, Issue 23 Send sdn mailing list submissions to sdn@irtf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.irtf.org/mailman/listinfo/sdn or, via email, send a message with subject or body 'help' to sdn-request@irtf.org You can reach the person managing the list at sdn-owner@irtf.org When replying, please edit your Subject line so it is more specific than "R= e: Contents of sdn digest..." Today's Topics: 1. SDNRG CFP for IETF 93 (King, Daniel) ---------------------------------------------------------------------- Message: 1 Date: Wed, 17 Jun 2015 21:39:48 +0000 From: "King, Daniel" To: "sdn@irtf.org" Cc: "dmm@1-4-5.net" Subject: [Sdn] SDNRG CFP for IETF 93 Message-ID: <65174429B5AF4C45BD0798810EC48E0A3242F4CF@EX-0-MB2.lancs.local> Content-Type: text/plain; charset=3D"us-ascii" Hi All,=20 SDNRG at IETF 93 Call for Presentations IETF 93 (July 19-24) Prague, Czech Republic --------------------------------------- The Software Defined Networking Research Group (SDNRG) will hold its next m= eeting in conjunction with IETF 93 (July 19-24). The SDNRG Program Committ= ee is now seeking proposals for presentations for the IRTF SDNRG agenda. Presentations highlighting current research in SDN and its applications are= encouraged. Areas of interest include (but are not limited to): o Classification of SDN models, including Definitions, =20 Taxonomies o SDN model scalability and applicability o Multi-layer programability an= d feedback control systems o System Complexity o Network description lang= uages, abstractions, interfaces and compilers including methods and mechanisms for (on-line) verification of correct operation of network/node function.=20 o Methods for increasing the data-awareness of the network The SDNRG is also requesting discussions related to securing Software Defin= ed Networks, areas of interest include (but are not limited to): o Trust models o Protecting and securing the SDN controllers o Robust policy frameworks = o Forensics and remedial responses =20 Key Dates for SDNRG 93 SDN Research Group Meeting Date/Time/Location is to be determined.=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D CFP Opens immediately for SDNRG 93. CFP Deadline #1: Presentation Proposal (Abstracts) Due 8 July. CFP Deadline #2: Presentation Slides Due 19 July (or slightly earlier if an= SDNRG Monday (20th) meeting. BR, Dan & dmm ------------------------------ Subject: Digest Footer _______________________________________________ sdn mailing list sdn@irtf.org https://www.irtf.org/mailman/listinfo/sdn ------------------------------ End of sdn Digest, Vol 37, Issue 23 *********************************** _______________________________________________ sdn mailing list sdn@irtf.org https://www.irtf.org/mailman/listinfo/sdn From nobody Fri Jun 26 01:38:06 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E8D1A01FC for ; Fri, 26 Jun 2015 01:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IG1SP31yB7Dt for ; Fri, 26 Jun 2015 01:38:04 -0700 (PDT) Received: from sideburn.lancs.ac.uk (sideburn.lancs.ac.uk [148.88.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id D85C41A01BA for ; Fri, 26 Jun 2015 01:38:03 -0700 (PDT) Received: from ex-1-ht0.lancs.ac.uk ([10.42.18.57] helo=EX-1-HT0.lancs.local) by sideburn.lancs.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1Z8P93-0004uG-Lx; Fri, 26 Jun 2015 09:37:57 +0100 Received: from EX-0-MB2.lancs.local ([fe80::9d98:936b:54d1:c531]) by EX-1-HT0.lancs.local ([fe80::d9e8:ad10:d075:a6b6%12]) with mapi id 14.03.0224.002; Fri, 26 Jun 2015 09:37:57 +0100 From: "King, Daniel" To: Rodrigo Ruas Oliveira , "Songhaibin (A)" Thread-Topic: [Sdn] SDNRG CFP for IETF 93 Thread-Index: AdCueab47QKGxkTWRV6wPscpXhvrUwADhwWAAFjKP6A= Date: Fri, 26 Jun 2015 08:37:57 +0000 Message-ID: <65174429B5AF4C45BD0798810EC48E0A3243272C@EX-0-MB2.lancs.local> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [88.97.23.122] x-iss-local-domain: 1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "sdn@irtf.org" Subject: Re: [Sdn] SDNRG CFP for IETF 93 X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 08:38:05 -0000 SGkgUm9kcmlnbywgDQoNClllcyBpbmRlZWQuIEEgZmV3IHJlbW90ZSBwYXJ0aWNpcGF0aW9uIG1l Y2hhbmlzbXMgZXhpc3Q6DQoNCi0gSmFiYmVyICh5b3UgY2FuIHBvc2UgcXVlc3Rpb25zIGFuZCB0 aGVzZSB3aWxsIGJlIHJlZmxlY3RlZCBhdCB0aGUgbWljKQ0KLSBMaXZlIGF1ZGlvIHN0ZWFtIChw YXNzaXZlKQ0KLSBMaXZlIHZpZGVvL2F1ZGlvIChNZWV0ZWNobykNCg0KVGhlIHJlbW90ZSBwYXJ0 aWNpcGF0aW9uIHBhZ2UgZm9yIElFVEYgOTMgaXMgbm90IG9ubGluZSB5ZXQsIGJ1dCB5b3UgY2Fu IHNlZSB0aGUgcGFnZSBmb3IgSUVURiA5MiBoZXJlOg0KDQpodHRwOi8vd3d3LmlldGYub3JnL21l ZXRpbmcvOTIvcmVtb3RlLXBhcnRpY2lwYXRpb24uaHRtbA0KDQpCUiwgRGFuLiANCg0KRnJvbTog cm9kcmlnb3J1YXNvbGl2ZWlyYUBnbWFpbC5jb20gW21haWx0bzpyb2RyaWdvcnVhc29saXZlaXJh QGdtYWlsLmNvbV0gT24gQmVoYWxmIE9mIFJvZHJpZ28gUnVhcyBPbGl2ZWlyYQ0KU2VudDogMjQg SnVuZSAyMDE1IDE2OjEyDQpUbzogU29uZ2hhaWJpbiAoQSkNCkNjOiBLaW5nLCBEYW5pZWw7IHNk bkBpcnRmLm9yZw0KU3ViamVjdDogUmU6IFtTZG5dIFNETlJHIENGUCBmb3IgSUVURiA5Mw0KDQpJ cyBpdCBwb3NzaWJsZSB0byBwYXJ0aWNpcGF0ZSBvbmxpbmUgKGllLiB3YXRjaC9oZWFyIGFuZCBw b3N0IHF1ZXN0aW9ucyk/IEkgYW0gdmVyeSBpbnRlcmVzdGVkIGluIHRoaXMgdG9waWMuDQpFbSAy NC8wNi8yMDE1IDA5OjM3LCAiU29uZ2hhaWJpbiAoQSkiIDxoYWliaW4uc29uZ0BodWF3ZWkuY29t PiBlc2NyZXZldToNCkhpIERhbmllbCwNCsKgDQpJZiB0aW1lIGFsbG93cywgSSB3b3VsZCBhbHNv IGxpa2UgdG8gcHJlc2VudCBhIGdlbmVyYWwgdGhyZWF0IGFuYWx5c2lzIHRvcGljIHRvIFNETi4N CsKgDQpCUiwNCi1IYWliaW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCnNkbiBtYWlsaW5nIGxpc3QNCnNkbkBpcnRmLm9yZw0KaHR0cHM6Ly93d3cu aXJ0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZG4NCg== From nobody Fri Jun 26 01:42:01 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136B01A0250 for ; Fri, 26 Jun 2015 01:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pS8zkHgFth6J for ; Fri, 26 Jun 2015 01:41:59 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14CCE1A024E for ; Fri, 26 Jun 2015 01:41:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUK16820; Fri, 26 Jun 2015 08:41:51 +0000 (GMT) Received: from LHREML504-MBS.china.huawei.com ([10.125.30.107]) by lhreml404-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Fri, 26 Jun 2015 09:41:45 +0100 From: Hosnieh Rafiee To: "King, Daniel" Thread-Topic: SDNRG CFP IETF 93 - Protect and Secure SDN Controllers Thread-Index: AdCs20h5QV8lahrER5CmZFXvKAlBmQDDzCywAAAghYA= Date: Fri, 26 Jun 2015 08:41:44 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A701551F20@lhreml504-mbs> References: <65174429B5AF4C45BD0798810EC48E0A32432709@EX-0-MB2.lancs.local> In-Reply-To: <65174429B5AF4C45BD0798810EC48E0A32432709@EX-0-MB2.lancs.local> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.212] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "sdn@irtf.org" Subject: Re: [Sdn] SDNRG CFP IETF 93 - Protect and Secure SDN Controllers X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 08:42:01 -0000 HI Daniel,=20 I think I started new threat to ask for presentation. I followed the discus= sion on mailinglist but have never attended. If the time allows would it be= possible to consider my presentation regarding authentication and high lev= el authorization model for SDN solutions. I will submit a draft either toda= y or tomorrow. Thank you, Best, Hosnieh > -----Original Message----- > From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of sdn- > request@irtf.org > Sent: 18 June 2015 20:00 > To: sdn@irtf.org > Subject: sdn Digest, Vol 37, Issue 23 >=20 > Send sdn mailing list submissions to > sdn@irtf.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > https://www.irtf.org/mailman/listinfo/sdn > or, via email, send a message with subject or body 'help' to > sdn-request@irtf.org >=20 > You can reach the person managing the list at > sdn-owner@irtf.org >=20 > When replying, please edit your Subject line so it is more specific > than "Re: Contents of sdn digest..." >=20 >=20 > Today's Topics: >=20 > 1. SDNRG CFP for IETF 93 (King, Daniel) >=20 >=20 > ---------------------------------------------------------------------- >=20 > Message: 1 > Date: Wed, 17 Jun 2015 21:39:48 +0000 > From: "King, Daniel" > To: "sdn@irtf.org" > Cc: "dmm@1-4-5.net" > Subject: [Sdn] SDNRG CFP for IETF 93 > Message-ID: > <65174429B5AF4C45BD0798810EC48E0A3242F4CF@EX-0-MB2.lancs.local> > Content-Type: text/plain; charset=3D"us-ascii" >=20 > Hi All, >=20 > SDNRG at IETF 93 Call for Presentations > IETF 93 (July 19-24) > Prague, Czech Republic > --------------------------------------- > The Software Defined Networking Research Group (SDNRG) will hold its > next meeting in conjunction with IETF 93 (July 19-24). The SDNRG > Program Committee is now seeking proposals for presentations for the > IRTF SDNRG agenda. >=20 > Presentations highlighting current research in SDN and its applications > are encouraged. Areas of interest include (but are not limited to): >=20 > o Classification of SDN models, including Definitions, > Taxonomies > o SDN model scalability and applicability o Multi-layer > programability and feedback control systems o System Complexity o > Network description languages, abstractions, interfaces and > compilers including methods and mechanisms for (on-line) > verification of correct operation of network/node function. > o Methods for increasing the data-awareness of the network >=20 > The SDNRG is also requesting discussions related to securing Software > Defined Networks, areas of interest include (but are not limited to): >=20 > o Trust models > o Protecting and securing the SDN controllers o Robust policy > frameworks o Forensics and remedial responses >=20 > Key Dates for SDNRG 93 >=20 > SDN Research Group Meeting Date/Time/Location is to be determined. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > CFP Opens immediately for SDNRG 93. > CFP Deadline #1: Presentation Proposal (Abstracts) Due 8 July. > CFP Deadline #2: Presentation Slides Due 19 July (or slightly earlier > if an SDNRG Monday (20th) meeting. >=20 > BR, Dan & dmm >=20 >=20 >=20 > ------------------------------ >=20 > Subject: Digest Footer >=20 > _______________________________________________ > sdn mailing list > sdn@irtf.org > https://www.irtf.org/mailman/listinfo/sdn >=20 >=20 > ------------------------------ >=20 > End of sdn Digest, Vol 37, Issue 23 > *********************************** >=20 > _______________________________________________ > sdn mailing list > sdn@irtf.org > https://www.irtf.org/mailman/listinfo/sdn >=20 > _______________________________________________ > sdn mailing list > sdn@irtf.org > https://www.irtf.org/mailman/listinfo/sdn From nobody Fri Jun 26 01:50:03 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F36A1A0451 for ; Fri, 26 Jun 2015 01:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxHGPEprIfMp for ; Fri, 26 Jun 2015 01:49:59 -0700 (PDT) Received: from sideburn.lancs.ac.uk (sideburn.lancs.ac.uk [148.88.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 597141A044F for ; Fri, 26 Jun 2015 01:49:59 -0700 (PDT) Received: from ex-1-ht0.lancs.ac.uk ([10.42.18.57] helo=EX-1-HT0.lancs.local) by sideburn.lancs.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1Z8PKg-0000QY-NF; Fri, 26 Jun 2015 09:49:58 +0100 Received: from EX-0-MB2.lancs.local ([fe80::9d98:936b:54d1:c531]) by EX-1-HT0.lancs.local ([fe80::d9e8:ad10:d075:a6b6%12]) with mapi id 14.03.0224.002; Fri, 26 Jun 2015 09:49:58 +0100 From: "King, Daniel" To: Hosnieh Rafiee Thread-Topic: SDNRG CFP IETF 93 - Protect and Secure SDN Controllers Thread-Index: AdCs20h5QV8lahrER5CmZFXvKAlBmQDDzCywAAAghYAAAEGjUA== Date: Fri, 26 Jun 2015 08:49:58 +0000 Message-ID: <65174429B5AF4C45BD0798810EC48E0A3243277F@EX-0-MB2.lancs.local> References: <65174429B5AF4C45BD0798810EC48E0A32432709@EX-0-MB2.lancs.local> <814D0BFB77D95844A01CA29B44CBF8A701551F20@lhreml504-mbs> In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A701551F20@lhreml504-mbs> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [88.97.23.122] x-iss-local-domain: 1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sdn@irtf.org" Subject: Re: [Sdn] SDNRG CFP IETF 93 - Protect and Secure SDN Controllers X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 08:50:01 -0000 Hi Hosnieh,=20 Please be aware that we do not typically expect an I-D to discuss/present a= t a SDN RG session. In fact we love to discuss the research/challenges firs= t then we can investigate further via an I-D (if warranted). We may also fi= nd an I-D would be better suited to an IETF WG depending on the scope and p= roblem space. Either way, your request is queued and we plan to publish a = draft agenda soon.=20 BR, Dan.=20 -----Original Message----- From: Hosnieh Rafiee [mailto:hosnieh.rafiee@huawei.com]=20 Sent: 26 June 2015 09:42 To: King, Daniel Cc: sdn@irtf.org Subject: RE: SDNRG CFP IETF 93 - Protect and Secure SDN Controllers HI Daniel,=20 I think I started new threat to ask for presentation. I followed the discus= sion on mailinglist but have never attended. If the time allows would it be= possible to consider my presentation regarding authentication and high lev= el authorization model for SDN solutions. I will submit a draft either toda= y or tomorrow. Thank you, Best, Hosnieh > -----Original Message----- > From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of sdn-=20 > request@irtf.org > Sent: 18 June 2015 20:00 > To: sdn@irtf.org > Subject: sdn Digest, Vol 37, Issue 23 >=20 > Send sdn mailing list submissions to > sdn@irtf.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > https://www.irtf.org/mailman/listinfo/sdn > or, via email, send a message with subject or body 'help' to > sdn-request@irtf.org >=20 > You can reach the person managing the list at > sdn-owner@irtf.org >=20 > When replying, please edit your Subject line so it is more specific=20 > than "Re: Contents of sdn digest..." >=20 >=20 > Today's Topics: >=20 > 1. SDNRG CFP for IETF 93 (King, Daniel) >=20 >=20 > ---------------------------------------------------------------------- >=20 > Message: 1 > Date: Wed, 17 Jun 2015 21:39:48 +0000 > From: "King, Daniel" > To: "sdn@irtf.org" > Cc: "dmm@1-4-5.net" > Subject: [Sdn] SDNRG CFP for IETF 93 > Message-ID: > <65174429B5AF4C45BD0798810EC48E0A3242F4CF@EX-0-MB2.lancs.local> > Content-Type: text/plain; charset=3D"us-ascii" >=20 > Hi All, >=20 > SDNRG at IETF 93 Call for Presentations IETF 93 (July 19-24) Prague,=20 > Czech Republic > --------------------------------------- > The Software Defined Networking Research Group (SDNRG) will hold its=20 > next meeting in conjunction with IETF 93 (July 19-24). The SDNRG=20 > Program Committee is now seeking proposals for presentations for the=20 > IRTF SDNRG agenda. >=20 > Presentations highlighting current research in SDN and its=20 > applications are encouraged. Areas of interest include (but are not limit= ed to): >=20 > o Classification of SDN models, including Definitions, > Taxonomies > o SDN model scalability and applicability o Multi-layer=20 > programability and feedback control systems o System Complexity o=20 > Network description languages, abstractions, interfaces and > compilers including methods and mechanisms for (on-line) > verification of correct operation of network/node function. > o Methods for increasing the data-awareness of the network >=20 > The SDNRG is also requesting discussions related to securing Software=20 > Defined Networks, areas of interest include (but are not limited to): >=20 > o Trust models > o Protecting and securing the SDN controllers o Robust policy=20 > frameworks o Forensics and remedial responses >=20 > Key Dates for SDNRG 93 >=20 > SDN Research Group Meeting Date/Time/Location is to be determined. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > CFP Opens immediately for SDNRG 93. > CFP Deadline #1: Presentation Proposal (Abstracts) Due 8 July. > CFP Deadline #2: Presentation Slides Due 19 July (or slightly earlier=20 > if an SDNRG Monday (20th) meeting. >=20 > BR, Dan & dmm >=20 >=20 >=20 > ------------------------------ >=20 > Subject: Digest Footer >=20 > _______________________________________________ > sdn mailing list > sdn@irtf.org > https://www.irtf.org/mailman/listinfo/sdn >=20 >=20 > ------------------------------ >=20 > End of sdn Digest, Vol 37, Issue 23 > *********************************** >=20 > _______________________________________________ > sdn mailing list > sdn@irtf.org > https://www.irtf.org/mailman/listinfo/sdn >=20 > _______________________________________________ > sdn mailing list > sdn@irtf.org > https://www.irtf.org/mailman/listinfo/sdn From nobody Fri Jun 26 01:52:52 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D976F1A19EC for ; Fri, 26 Jun 2015 01:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRxc8l7aoz-X for ; Fri, 26 Jun 2015 01:52:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 518421A09C9 for ; Fri, 26 Jun 2015 01:52:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUK18165; Fri, 26 Jun 2015 08:52:43 +0000 (GMT) Received: from LHREML504-MBS.china.huawei.com ([10.125.30.107]) by lhreml402-hub.china.huawei.com ([10.201.5.241]) with mapi id 14.03.0158.001; Fri, 26 Jun 2015 09:52:39 +0100 From: Hosnieh Rafiee To: "King, Daniel" Thread-Topic: SDNRG CFP IETF 93 - Protect and Secure SDN Controllers Thread-Index: AdCs20h5QV8lahrER5CmZFXvKAlBmQDDzCywAAAghYAAAEGjUAAAS7oQ Date: Fri, 26 Jun 2015 08:52:38 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A701551F49@lhreml504-mbs> References: <65174429B5AF4C45BD0798810EC48E0A32432709@EX-0-MB2.lancs.local> <814D0BFB77D95844A01CA29B44CBF8A701551F20@lhreml504-mbs> <65174429B5AF4C45BD0798810EC48E0A3243277F@EX-0-MB2.lancs.local> In-Reply-To: <65174429B5AF4C45BD0798810EC48E0A3243277F@EX-0-MB2.lancs.local> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.212] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "sdn@irtf.org" Subject: Re: [Sdn] SDNRG CFP IETF 93 - Protect and Secure SDN Controllers X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 08:52:50 -0000 Hi Daniel, Thanks, ah ok, I got it.=20 Thanks, Best, Hosnieh > -----Original Message----- > From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of King, Daniel > Sent: Friday, June 26, 2015 10:50 AM > To: Hosnieh Rafiee > Cc: sdn@irtf.org > Subject: Re: [Sdn] SDNRG CFP IETF 93 - Protect and Secure SDN > Controllers >=20 > Hi Hosnieh, >=20 > Please be aware that we do not typically expect an I-D to > discuss/present at a SDN RG session. In fact we love to discuss the > research/challenges first then we can investigate further via an I-D > (if warranted). We may also find an I-D would be better suited to an > IETF WG depending on the scope and problem space. Either way, your > request is queued and we plan to publish a draft agenda soon. >=20 > BR, Dan. >=20 > -----Original Message----- > From: Hosnieh Rafiee [mailto:hosnieh.rafiee@huawei.com] > Sent: 26 June 2015 09:42 > To: King, Daniel > Cc: sdn@irtf.org > Subject: RE: SDNRG CFP IETF 93 - Protect and Secure SDN Controllers >=20 > HI Daniel, >=20 > I think I started new threat to ask for presentation. I followed the > discussion on mailinglist but have never attended. If the time allows > would it be possible to consider my presentation regarding > authentication and high level authorization model for SDN solutions. I > will submit a draft either today or tomorrow. >=20 > Thank you, > Best, > Hosnieh > > -----Original Message----- > > From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of sdn- > > request@irtf.org > > Sent: 18 June 2015 20:00 > > To: sdn@irtf.org > > Subject: sdn Digest, Vol 37, Issue 23 > > > > Send sdn mailing list submissions to > > sdn@irtf.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://www.irtf.org/mailman/listinfo/sdn > > or, via email, send a message with subject or body 'help' to > > sdn-request@irtf.org > > > > You can reach the person managing the list at > > sdn-owner@irtf.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of sdn digest..." > > > > > > Today's Topics: > > > > 1. SDNRG CFP for IETF 93 (King, Daniel) > > > > > > --------------------------------------------------------------------- > - > > > > Message: 1 > > Date: Wed, 17 Jun 2015 21:39:48 +0000 > > From: "King, Daniel" > > To: "sdn@irtf.org" > > Cc: "dmm@1-4-5.net" > > Subject: [Sdn] SDNRG CFP for IETF 93 > > Message-ID: > > <65174429B5AF4C45BD0798810EC48E0A3242F4CF@EX-0-MB2.lancs.local> > > Content-Type: text/plain; charset=3D"us-ascii" > > > > Hi All, > > > > SDNRG at IETF 93 Call for Presentations IETF 93 (July 19-24) Prague, > > Czech Republic > > --------------------------------------- > > The Software Defined Networking Research Group (SDNRG) will hold its > > next meeting in conjunction with IETF 93 (July 19-24). The SDNRG > > Program Committee is now seeking proposals for presentations for the > > IRTF SDNRG agenda. > > > > Presentations highlighting current research in SDN and its > > applications are encouraged. Areas of interest include (but are not > limited to): > > > > o Classification of SDN models, including Definitions, > > Taxonomies > > o SDN model scalability and applicability o Multi-layer > > programability and feedback control systems o System Complexity o > > Network description languages, abstractions, interfaces and > > compilers including methods and mechanisms for (on-line) > > verification of correct operation of network/node function. > > o Methods for increasing the data-awareness of the network > > > > The SDNRG is also requesting discussions related to securing Software > > Defined Networks, areas of interest include (but are not limited to): > > > > o Trust models > > o Protecting and securing the SDN controllers o Robust policy > > frameworks o Forensics and remedial responses > > > > Key Dates for SDNRG 93 > > > > SDN Research Group Meeting Date/Time/Location is to be determined. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > CFP Opens immediately for SDNRG 93. > > CFP Deadline #1: Presentation Proposal (Abstracts) Due 8 July. > > CFP Deadline #2: Presentation Slides Due 19 July (or slightly earlier > > if an SDNRG Monday (20th) meeting. > > > > BR, Dan & dmm > > > > > > > > ------------------------------ > > > > Subject: Digest Footer > > > > _______________________________________________ > > sdn mailing list > > sdn@irtf.org > > https://www.irtf.org/mailman/listinfo/sdn > > > > > > ------------------------------ > > > > End of sdn Digest, Vol 37, Issue 23 > > *********************************** > > > > _______________________________________________ > > sdn mailing list > > sdn@irtf.org > > https://www.irtf.org/mailman/listinfo/sdn > > > > _______________________________________________ > > sdn mailing list > > sdn@irtf.org > > https://www.irtf.org/mailman/listinfo/sdn >=20 > _______________________________________________ > sdn mailing list > sdn@irtf.org > https://www.irtf.org/mailman/listinfo/sdn From nobody Fri Jun 26 01:59:58 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A20181A1A68 for ; Fri, 26 Jun 2015 01:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyjyroIyoYGS for ; Fri, 26 Jun 2015 01:59:55 -0700 (PDT) Received: from sideburn.lancs.ac.uk (sideburn.lancs.ac.uk [148.88.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id B0EF11A1A3D for ; Fri, 26 Jun 2015 01:59:54 -0700 (PDT) Received: from ex-0-ht0.lancs.ac.uk ([10.42.18.47] helo=EX-0-HT0.lancs.local) by sideburn.lancs.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1Z8PUH-00030C-QI; Fri, 26 Jun 2015 09:59:53 +0100 Received: from EX-0-MB2.lancs.local ([fe80::9d98:936b:54d1:c531]) by EX-0-HT0.lancs.local ([fe80::7d10:114a:53b0:7f2f%12]) with mapi id 14.03.0224.002; Fri, 26 Jun 2015 09:59:53 +0100 From: "King, Daniel" To: Anoop Ghanwani Thread-Topic: [Sdn] IETF 93 - Tutorial for SDN OpenFlow and ForCES Thread-Index: AdCrkp9Mak8RNrERQiWQPaEzD5iqSQDPQreAAEcLAjA= Date: Fri, 26 Jun 2015 08:59:53 +0000 Message-ID: <65174429B5AF4C45BD0798810EC48E0A324327A8@EX-0-MB2.lancs.local> References: <65174429B5AF4C45BD0798810EC48E0A3242FDFD@EX-0-MB2.lancs.local> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [88.97.23.122] x-iss-local-domain: 1 Content-Type: multipart/alternative; boundary="_000_65174429B5AF4C45BD0798810EC48E0A324327A8EX0MB2lancsloca_" MIME-Version: 1.0 Archived-At: Cc: "sdn@irtf.org" Subject: Re: [Sdn] IETF 93 - Tutorial for SDN OpenFlow and ForCES X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 08:59:56 -0000 --_000_65174429B5AF4C45BD0798810EC48E0A324327A8EX0MB2lancsloca_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5vb3AsDQoNCkRlcGVuZHMsIHdoaWNoIFNETiBmcmFtZXdvcmsgZG8gd2Ugd2FudCB0byBk aXNjdXNzLiDimLoNCg0KUGVyc29uYWxseSwgSSBkbyBzZWUgSTJSUyBhcyBtZXRob2Qgb2YgcHJv Z3JhbW1hdGljIGNvbnRyb2wgIChyZWFkIGFuZCB3cml0ZSkgb2Ygcm91dGluZyBzdGF0ZSBhbmQg aW50ZW50LiBUaGlzIGNlcnRhaW5seSBzb3VuZHMgbGlrZSBTRE4gY2FwYWJpbGl0eSB0byBtZS4g VG8gYmUgZmFpciB0byB0aGUgb3JnYW5pemVycywgMmhycyBpcyBhIGxpbWl0ZWQgd2luZG93IGZv ciBhbiBTRE4gdHV0b3JpYWwgYW5kIHRoZXJlZm9yZSBpdCBpcyBub3QgdW5yZWFzb25hYmxlIHRv IGNvbnN0cmFpbiB0aGUgZGlzY3Vzc2lvbiB0byBvbmx5IHR3byBzb3V0aGJvdW5kIHByb3RvY29s cy4NCg0KQlIsIERhbi4NCg0KRnJvbTogZ2hhbndhbmlAZ21haWwuY29tIFttYWlsdG86Z2hhbndh bmlAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgQW5vb3AgR2hhbndhbmkNClNlbnQ6IDI1IEp1bmUg MjAxNSAwMDo0Nw0KVG86IEtpbmcsIERhbmllbA0KQ2M6IHNkbkBpcnRmLm9yZw0KU3ViamVjdDog UmU6IFtTZG5dIElFVEYgOTMgLSBUdXRvcmlhbCBmb3IgU0ROIE9wZW5GbG93IGFuZCBGb3JDRVMN Cg0KV2hlcmUgZG9lcyBJMlJTIGZpdCBpbiB3aXRoaW4gdGhpcyBmcmFtZXdvcms/ICBJcyBpdCBu b3QgY29uc2lkZXJlZCBTRE4/DQoNCkFub29wDQoNCk9uIFNhdCwgSnVuIDIwLCAyMDE1IGF0IDEy OjU4IFBNLCBLaW5nLCBEYW5pZWwgPGQua2luZ0BsYW5jYXN0ZXIuYWMudWs8bWFpbHRvOmQua2lu Z0BsYW5jYXN0ZXIuYWMudWs+PiB3cm90ZToNCkhpIEFsbCwNCg0KVGhlcmUgd2lsbCBiZSBhICJU dXRvcmlhbCBmb3IgU0ROIE9wZW5GbG93IGFuZCBGb3JDRVMiIGF0IElFVEYgOTMgb24gU3VuZGF5 LCBKdWx5IDE5LCAyMDE1LiBUaGUgdHV0b3JpYWwgaW5mbyBwYWdlIGlzIGF0ICBpZXRmLm9yZy9t ZWV0aW5nLzkzL3R1dG9yaWFscy9zZG4uaHRtbDxodHRwOi8vaWV0Zi5vcmcvbWVldGluZy85My90 dXRvcmlhbHMvc2RuLmh0bWw+PGh0dHA6Ly9pZXRmLm9yZy9tZWV0aW5nLzkzL3R1dG9yaWFscy9z ZG4uaHRtbD4uDQoNCj4+DQpQcmVzZW50ZWQgYnk6IFlhYWtvdiBTdGVpbiBhbmQgRXZhbmdlbG9z IEhhbGVwbGlkaXMNCkRheTogU3VuZGF5LCBKdWx5IDE5LCAyMDE1DQpUaW1lOiAxNTowMC0xNzow MA0KUm9vbTogVEJEDQpEZXNjcmlwdGlvbjoNCg0KMS4gVGhlIGlkZWFzIGJlaGluZCB0aGUgcmVj ZW50IGF3YWtpbmcgb2YgU0RODQoyLiBIb3cgYW4gU0ROIGlzIGRpZmZlcmVudCBmcm9tIGEgY29u dmVudGlvbmFsIChyb3V0ZWQpIG5ldHdvcmsNCjMuIFRoZSBjb21wb25lbnRzIGFuZCBpbnRlcmZh Y2VzIG9mIGFuIFNETiAoU0ROICh3aGl0ZWJveCkgc3dpdGNoLCBTRE4gY29udHJvbGxlciwgU0JJ LCBOQkkpDQo0LiBORlYNCjUuIFRoZSBzb3V0aGJvdW5kIGludGVyZmFjZXMgKE9wZW5GbG93LCBG b3JDRVMsIC4uLikNCiAgICAgNS4xIFpvb20gaW4gb24gT3BlbkZsb3cNCiAgICAgNS4yIFpvb20g aW4gb24gRm9yQ0VTDQo8PA0KDQpDaGVjayB0aGUgVHV0b3JpYWwgbGluayBmb3Igcm9vbSBhc3Np Z25tZW50IGNsb3NlciB0byB0aGUgc2Vzc2lvbi4NCg0KQlIsIERhbi4NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNkbiBtYWlsaW5nIGxpc3QNCnNk bkBpcnRmLm9yZzxtYWlsdG86c2RuQGlydGYub3JnPg0KaHR0cHM6Ly93d3cuaXJ0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZG4NCg0K --_000_65174429B5AF4C45BD0798810EC48E0A324327A8EX0MB2lancsloca_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h cmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPkhpIEFub29wLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5EZXBlbmRzLCB3aGljaCBTRE4gZnJhbWV3b3JrIGRvIHdlIHdhbnQgdG8gZGlz Y3Vzcy4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpX aW5nZGluZ3M7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Sjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5QZXJzb25hbGx5LCBJ IGRvIHNlZSBJMlJTIGFzIG1ldGhvZCBvZiBwcm9ncmFtbWF0aWMgY29udHJvbCZuYnNwOyAocmVh ZCBhbmQgd3JpdGUpIG9mIHJvdXRpbmcgc3RhdGUgYW5kIGludGVudC4gVGhpcyBjZXJ0YWlubHkg c291bmRzIGxpa2UNCiBTRE4gY2FwYWJpbGl0eSB0byBtZS4gVG8gYmUgZmFpciB0byB0aGUgb3Jn YW5pemVycywgMmhycyBpcyBhIGxpbWl0ZWQgd2luZG93IGZvciBhbiBTRE4gdHV0b3JpYWwgYW5k IHRoZXJlZm9yZSBpdCBpcyBub3QgdW5yZWFzb25hYmxlIHRvIGNvbnN0cmFpbiB0aGUgZGlzY3Vz c2lvbiB0byBvbmx5IHR3byBzb3V0aGJvdW5kIHByb3RvY29scy4NCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QlIsIERhbi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+IGdoYW53YW5pQGdtYWlsLmNvbSBbbWFpbHRvOmdoYW53YW5pQGdtYWlsLmNv bV0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QW5vb3AgR2hhbndhbmk8YnI+DQo8Yj5TZW50OjwvYj4g MjUgSnVuZSAyMDE1IDAwOjQ3PGJyPg0KPGI+VG86PC9iPiBLaW5nLCBEYW5pZWw8YnI+DQo8Yj5D Yzo8L2I+IHNkbkBpcnRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1Nkbl0gSUVURiA5 MyAtIFR1dG9yaWFsIGZvciBTRE4gT3BlbkZsb3cgYW5kIEZvckNFUzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoZXJlIGRvZXMgSTJSUyBmaXQgaW4gd2l0aGluIHRoaXMg ZnJhbWV3b3JrPyZuYnNwOyBJcyBpdCBub3QgY29uc2lkZXJlZCBTRE4/PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Bbm9vcDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTYXQsIEp1biAyMCwgMjAxNSBh dCAxMjo1OCBQTSwgS2luZywgRGFuaWVsICZsdDs8YSBocmVmPSJtYWlsdG86ZC5raW5nQGxhbmNh c3Rlci5hYy51ayIgdGFyZ2V0PSJfYmxhbmsiPmQua2luZ0BsYW5jYXN0ZXIuYWMudWs8L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkhpIEFsbCw8YnI+DQo8YnI+DQpUaGVyZSB3 aWxsIGJlIGEgJnF1b3Q7VHV0b3JpYWwgZm9yIFNETiBPcGVuRmxvdyBhbmQgRm9yQ0VTJnF1b3Q7 IGF0IElFVEYgOTMgb24gU3VuZGF5LCBKdWx5IDE5LCAyMDE1LiBUaGUgdHV0b3JpYWwgaW5mbyBw YWdlIGlzIGF0Jm5ic3A7DQo8YSBocmVmPSJodHRwOi8vaWV0Zi5vcmcvbWVldGluZy85My90dXRv cmlhbHMvc2RuLmh0bWwiIHRhcmdldD0iX2JsYW5rIj5pZXRmLm9yZy9tZWV0aW5nLzkzL3R1dG9y aWFscy9zZG4uaHRtbDwvYT4mbHQ7PGEgaHJlZj0iaHR0cDovL2lldGYub3JnL21lZXRpbmcvOTMv dHV0b3JpYWxzL3Nkbi5odG1sIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2lldGYub3JnL21lZXRp bmcvOTMvdHV0b3JpYWxzL3Nkbi5odG1sPC9hPiZndDsuPGJyPg0KPGJyPg0KJmd0OyZndDs8YnI+ DQpQcmVzZW50ZWQgYnk6IFlhYWtvdiBTdGVpbiBhbmQgRXZhbmdlbG9zIEhhbGVwbGlkaXM8YnI+ DQpEYXk6IFN1bmRheSwgSnVseSAxOSwgMjAxNTxicj4NClRpbWU6IDE1OjAwLTE3OjAwPGJyPg0K Um9vbTogVEJEPGJyPg0KRGVzY3JpcHRpb246PGJyPg0KPGJyPg0KMS4gVGhlIGlkZWFzIGJlaGlu ZCB0aGUgcmVjZW50IGF3YWtpbmcgb2YgU0ROPGJyPg0KMi4gSG93IGFuIFNETiBpcyBkaWZmZXJl bnQgZnJvbSBhIGNvbnZlbnRpb25hbCAocm91dGVkKSBuZXR3b3JrPGJyPg0KMy4gVGhlIGNvbXBv bmVudHMgYW5kIGludGVyZmFjZXMgb2YgYW4gU0ROIChTRE4gKHdoaXRlYm94KSBzd2l0Y2gsIFNE TiBjb250cm9sbGVyLCBTQkksIE5CSSk8YnI+DQo0LiBORlY8YnI+DQo1LiBUaGUgc291dGhib3Vu ZCBpbnRlcmZhY2VzIChPcGVuRmxvdywgRm9yQ0VTLCAuLi4pPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDs1LjEgWm9vbSBpbiBvbiBPcGVuRmxvdzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7NS4y IFpvb20gaW4gb24gRm9yQ0VTPGJyPg0KJmx0OyZsdDs8YnI+DQo8YnI+DQpDaGVjayB0aGUgVHV0 b3JpYWwgbGluayBmb3Igcm9vbSBhc3NpZ25tZW50IGNsb3NlciB0byB0aGUgc2Vzc2lvbi48YnI+ DQo8YnI+DQpCUiwgRGFuLjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0Kc2RuIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzpzZG5AaXJ0Zi5vcmciPnNkbkBpcnRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczov L3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NkbiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlydGYub3JnL21haWxtYW4vbGlzdGluZm8vc2RuPC9hPjxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_65174429B5AF4C45BD0798810EC48E0A324327A8EX0MB2lancsloca_-- From nobody Fri Jun 26 02:09:40 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCAD1A1A9B for ; Fri, 26 Jun 2015 02:09:38 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains application/ms-tnef, .tnef, winmail.dat X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zP6OypA5d90T for ; Fri, 26 Jun 2015 02:09:37 -0700 (PDT) Received: from ignavia.lancs.ac.uk (ignavia.lancs.ac.uk [148.88.25.16]) by ietfa.amsl.com (Postfix) with ESMTP id A44391A1A96 for ; Fri, 26 Jun 2015 02:09:36 -0700 (PDT) Received: from ex-0-ht0.lancs.ac.uk ([10.42.18.47] helo=EX-0-HT0.lancs.local) by ignavia.lancs.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1Z8Pde-0001cr-TP for sdn@irtf.org; Fri, 26 Jun 2015 10:09:34 +0100 Received: from EX-0-MB2.lancs.local ([fe80::9d98:936b:54d1:c531]) by EX-0-HT0.lancs.local ([fe80::7d10:114a:53b0:7f2f%12]) with mapi id 14.03.0224.002; Fri, 26 Jun 2015 10:09:34 +0100 Content-Type: multipart/mixed; boundary="_000_65174429B5AF4C45BD0798810EC48E0A324327DCEX0MB2lancsloca_" From: "King, Daniel" To: "'sdn@irtf.org'" Thread-Topic: Prague IETF Guest Day Thread-Index: AdCv78nnWtFDfmFlQweMoK2OrCNc1Q== Date: Fri, 26 Jun 2015 09:09:33 +0000 Message-ID: <65174429B5AF4C45BD0798810EC48E0A324327DC@EX-0-MB2.lancs.local> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: <65174429B5AF4C45BD0798810EC48E0A324327DC@EX-0-MB2.lancs.local> x-originating-ip: [88.97.23.122] x-iss-local-domain: 1 MIME-Version: 1.0 Archived-At: Subject: [Sdn] FW: Prague IETF Guest Day X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 09:09:38 -0000 --_000_65174429B5AF4C45BD0798810EC48E0A324327DCEX0MB2lancsloca_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All,=20 Please note the Complimentary one-day Guest Pass (Tuesday, July 21 ) for st= udents, instructors and members of Internet Society Chapters. Also, Full-time students can attend the entire week for $150 USD (with on-s= ite proof of ID). BR, Dan.=20 -----Original Message----- From: irsg [mailto:irsg-bounces@irtf.org] On Behalf Of Eggert, Lars Sent: 24 June 2015 17:35 To: irtf-announce@irtf.org; irtf-discuss@irtf.org Subject: [irsg] Prague IETF Guest Day IETF Guest Day To: University Professors, Students and Local ISOC Chapter Members Join the Internet's Leading Engineers in Prague! Experience first hand the = Internet standards process and meet the world's leading Internet engineers,= developers and researchers. We expect 1,200 attendees from more than 60 co= untries. The Internet Engineering Task Force (IETF) will convene July 19 - 24 for IE= TF 93 at the Prague Hilton and you are invited! The IETF is the premiere international open-standards community and is resp= onsible for many of the Internet's most important standards, including TCP/= IP, e-mail, instant messaging, VoIP, 3G and IPv6. Its work is concerned wi= th the evolution of the Internet's architecture and its smooth operation. = To learn more see: The IETF is unique from other standards groups in that it is a volunteer or= ganization, lead by individuals, not governments or corporations. The IETF= 's processes are open to all and decisions are made on the basis of "rough = consensus and running code." If you are doing research in networking or c= ommunications, this is one event you don't want to miss. The IETF meets three times a year face-to-face to progress its work of Inte= rnet Standards development for the betterment of the Internet and people wo= rldwide. Tuesday, July 21 is IETF 93 Guest Day when students, instructors and membe= rs of Internet Society Chapters can receive a complimentary one-day Guest P= ass to the IETF 93 Meeting. Guests shall check in at the Registration Tabl= e for their name tags and meeting schedules. Guests have an opportunity to attend some of the 30 plus Working Group sess= ions being held that day. The Agenda will be available here - Note: You may also attend Newcomer Training that is scheduled for Sunday 1= 9 July at the Prague Hilton beginning at 1:00 PM. See: Interested local ISOC Chapter members, Students and Instructors must: 1. Register online at but do not pay. 2. Send an email to iad at ietf.org, subject: Guest Pass, indicating an ISO= C Chapter member, student or instructor, provide Registration ID and reques= t a one-day Guest Pass. 3. Pick up a Guest Pass on Sunday or Tuesday. The IETF welcomes your interest in its work and looks forward to the day wh= en you will participate in this volunteer endeavor. Ray Pelletier IETF Administrative Director --_000_65174429B5AF4C45BD0798810EC48E0A324327DCEX0MB2lancsloca_ Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 Content-Type: application/ms-tnef; name="winmail.dat" eJ8+In8GAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEJgAEAIQAAADA1RUIxN0ZD MUQ2QzA0NDdBRUI2MjJFRDdGREVDQTEwAHAHAQ2ABAACAAAAAgACAAEFgAMADgAAAN8HBgAaAAkA CQAhAAUAPgEBIIADAA4AAADfBwYAGgAJAAkAIQAFAD4BAQiABwAYAAAASVBNLk1pY3Jvc29mdCBN YWlsLk5vdGUAMQgBBIABABoAAABGVzogUHJhZ3VlIElFVEYgR3Vlc3QgRGF5AAkIAQOQBgDoEQAA PgAAAAIBfwABAAAAQAAAADw2NTE3NDQyOUI1QUY0QzQ1QkQwNzk4ODEwRUM0OEUwQTMyNDMyN0RD QEVYLTAtTUIyLmxhbmNzLmxvY2FsPgALAB8OAQAAAAIBCRABAAAAQwgAAD8IAAAYDgAATFpGdf0t KPphAApmYmlkBAAAY2PAcGcxMjUyAP4DQ/B0ZXh0AfcCpAPjAgAEY2gKwHNldDAg7wdtAoMAUBFN MgqABrQCgJZ9CoAIyDsJYjE5DsC/CcMWcgoyFnECgBViKgmwcwnwBJBhdAWyDlADYHOibwGAIEV4 EcFuGDBdBlJ2BJAXtgIQcgDAdH0IUG4aMRAgBcAFoBtkZJogA1IgECIXslx2CJDkd2sLgGQ1HVME 8AdADRdwMApxF/Jia21rBnMBkAAgIEJNX0LgRUdJTn0K/AHxC/EAIEhpIEFsbCy1AzBsC4BlCoEi NFAecGJhEgAgbm8QIBzAaHsZ4AhQbQtQB3ECMArAeUIgAiBlLWRhJMBHMwpQH2AgUCMwBCAoVEcl cSUhIgBKdWwkwDK4MSApHHAFsR9gdQEAHQIwcyIAC4AfYHJ1Y/8YkQQgAHAcYAeABtAEkAQgeRkw IEkCMASREhAGAG/qYwiQdCTAQxHQBTApcV4uIiwh0BkgIgBGJsBs/C10B3EnhxvQA5EYgBAglykB I8IkcWkJcCB3CeAiaydDJDE1EjBVU95EJgAD8CPAJNEtAJAjkU5wA2ApsSmyRCkrfUKqUiIARABw LiIdLTRyek8FEGcLgAdABdAHkHOuYRgwNHMiJUYDYTooIHER8GcgWwDAAxAYkDpFNuItBuB1bmMH kEALLxAAMC4FsGddIE+pA6BCZRHQbCnATynA3EVnGDAAICIATBHhIiXnBmACMDbAMjQmoRhQJvCC MC/wIDE3OjMd4N0iNFQ3kDbRADAtAHAjcJs4Ijh3Oz1EDeFjdQQQYzh3OrZ1YmoFkDtRW2s24jkA UBhwZwpQKdBF7FRGJVUzQHkiLEIPIln/PRIwIAMAGjExASTAQZAZMLc1YSixIgBTLXYo8kwqgOE1 IUlTT0Mq5jVBKVO5IixKbwuAI7Mp5icEIP5MIyAN4BnAGWAZwCJBKXLrSrFBlCEZYXAGcQnwOED/ HHA24QVAGaEuhCnnH2EdwH8LEQQgMVE4QSjWKkEjwnf5BbBsZEuhIxFMAynnCfD/THUiAAEAGjAJ AE3BKNQJcM8SAArAEcArQiBXLsFNsfsokDxALAHQEjAuNAngBCDfHIMEYC8hI8ADkTYSMAWg7zgg KGAIkCtuVE8aTFZMErZUIzAvgEYFsE4hKEPCfycwA/Ah4BvUO9EmsxZwIM4tO3InUkPDOTMuISOz 30GVIaA3cS4RKQF5CGAo4O8vIQuAHWAcQSFZL0H0BAB/I7MxUClACJFhAioCGIBpPwIgNSFUUTDh T+cFoG1t3zggRkIo8mMRVPFwAiAAkP8CYE4xBbEDgSTBKcBK7QRgfyWRB3BnIAAgAHBPuSgSYwMK QEwDVENQL0lQ/yIAJQA3QigUahIHgTWBTBHJIgBWb2viM0co42vg/HY2M3Ap0C3BUcEvgGMRvxvh OEAqIRxgMIMuo3YG8P51ZIJoPyjRVUExESiQCHD3GeBmgy3BcwRgI4AwsU3Bf2RzbuE9EFIyBKFX sxIAZRI6IiU8aAJAcHM6aC8vd3dgLiqhOLMvHRhQd2XhK0J24G1sPvdhr2K3ZiFxQdEcg3RBG7H/ T9gJwAhgdxBM4lgBaZFpkX0o0SBxEinxG7E40QBwac56ZHMiAFJCIGIkwB2xe0XwDdB1B0AoASNx fHBv3RoxbiRiKZEbwnJp0WRz/1WREkBilUuhUHUHkWDiZPL/HMB1UAdAAyAo8gWBBACCct9g0wDA AQAk0SOzYiMwYxH1KbEifJFnMLAb4RIAAIB/P2BUpDggAwBMIQWgAQAu3iJFsCnQKcBgpmRKoTcQ /1T2TOIqMW9STBKBw2YDHlD/gmMiACPAYxGHQjvRVBFqIdNgooqwbicFQHdqEoTB/2OwBBBZH0Hl UTJjIgnRHMD7B3N90HlVIRxwANAlABiQ/i2TQoSyMVEJwQQRc9JvU/8pu0/nVAUkYidDhtMSEBuh /5czca0o403AVFBngVHDA/D/iZFErSY+YwJelkQXL0Aj0P8DoCefKK8pvyrJLeMJcDhA/0XxfcFl 4SQ/JUuEwUrjXqX/NVASEEwRbuElY3PxOXFc4Z0j0GNvgS4SI7NSZTTwf59hZHNbgWd2I8EvECNg YfstMQGQZ1DYTBIE8CPQgFC/HnArbqcVEdCjInGBcGnSv2YkhMIuRBkgLTFxpTMSMOsLUIiBV4wV R3ySdhEEEP+Fw6BwTBIj0FHwfRQlIYK1vkEYMSUgXKSgcJ/wdjdR/6nDVWEZ4F4AdtclIAGQqTGv qBAEkHeYq5UvXuAvNZG3UAF4zyJhTiOBRaFZYLH/AMBmYSxxLiYHwXhjEkAYcP8LgEwSfSRz8awl HGEFsUCQ/1ABXbMms18fYCKgcDTxiSPJv4ExOlaRUE0zcAZg/3ZPd1y4GZ6wGJEHMXi/Q4P/oQIl gRxRCQBIP6BFRy2g8L+fZyIlZhAfYMJmIiUxM3D7qOR+Ym4iMr9ywuPDT7go9x2xEDDFi2JxQIqh gLMKsPuzsCIsMsISoBEDkaBQN1H/hLIHMNMBaZF3tSIAiHBAtf8laJ8iDeCNIsFCA6DH3wSQ/9TR nrSBsp9IIgAxUYAxqM1/MeBUpXrxJZF90KRfK24z/TNwUA5QL4Cx0X3QJWlgMb++lQWxm+WQP0Hl L1BseGL/BCBgodkCxuRM4pTXoAIJAP5vH1AnQo9wCyCldiUinlP/YKJcswqxLRAqkAqwI5FKs79j EX34VvKuEAWwK31SJTE+UFQwHnAtEASQQ1pBZO9jsAMAqSSjIUQvEZ+iIiUDFULucAAfAEIAAQAA ABoAAABLAGkAbgBnACwAIABEAGEAbgBpAGUAbAAAAAAAHwBlAAEAAAAuAAAAZAAuAGsAaQBuAGcA QABsAGEAbgBjAGEAcwB0AGUAcgAuAGEAYwAuAHUAawAAAAAAHwBkAAEAAAAKAAAAUwBNAFQAUAAA AAAAAgFBAAEAAABqAAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAACASwBpAG4AZwAsACAARABhAG4A aQBlAGwAAABTAE0AVABQAAAAZAAuAGsAaQBuAGcAQABsAGEAbgBjAGEAcwB0AGUAcgAuAGEAYwAu AHUAawAAAAAAHwACXQEAAAAuAAAAZAAuAGsAaQBuAGcAQABsAGEAbgBjAGEAcwB0AGUAcgAuAGEA YwAuAHUAawAAAAAAHwDlXwEAAAAEAAAAIAAAAB8AGgwBAAAAGgAAAEsAaQBuAGcALAAgAEQAYQBu AGkAZQBsAAAAAAAfAB8MAQAAAC4AAABkAC4AawBpAG4AZwBAAGwAYQBuAGMAYQBzAHQAZQByAC4A YQBjAC4AdQBrAAAAAAAfAB4MAQAAAAoAAABTAE0AVABQAAAAAAACARkMAQAAAGoAAAAAAAAAgSsf pL6jEBmdbgDdAQ9UAgAAAIBLAGkAbgBnACwAIABEAGEAbgBpAGUAbAAAAFMATQBUAFAAAABkAC4A awBpAG4AZwBAAGwAYQBuAGMAYQBzAHQAZQByAC4AYQBjAC4AdQBrAAAAAAAfAAFdAQAAAC4AAABk AC4AawBpAG4AZwBAAGwAYQBuAGMAYQBzAHQAZQByAC4AYQBjAC4AdQBrAAAAAAAfAPg/AQAAABoA AABLAGkAbgBnACwAIABEAGEAbgBpAGUAbAAAAAAAHwAjQAEAAAAuAAAAZAAuAGsAaQBuAGcAQABs AGEAbgBjAGEAcwB0AGUAcgAuAGEAYwAuAHUAawAAAAAAHwAiQAEAAAAKAAAAUwBNAFQAUAAAAAAA AgH5PwEAAABqAAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAACASwBpAG4AZwAsACAARABhAG4AaQBl AGwAAABTAE0AVABQAAAAZAAuAGsAaQBuAGcAQABsAGEAbgBjAGEAcwB0AGUAcgAuAGEAYwAuAHUA awAAAAAAHwAJXQEAAAAuAAAAZAAuAGsAaQBuAGcAQABsAGEAbgBjAGEAcwB0AGUAcgAuAGEAYwAu AHUAawAAAAAACwBAOgEAAAAfABoAAQAAABIAAABJAFAATQAuAE4AbwB0AGUAAAAAAAMA8T8JBAAA CwBAOgEAAAADAP0/5AQAAAIBCzABAAAAEAAAAAXrF/wdbARHrrYi7X/eyhADABcAAQAAAEAAOQCA BN7Q76/QAUAACDCdATPR76/QAQsAKQAAAAAACwAjAAAAAAAfAACAhgMCAAAAAADAAAAAAAAARgEA AAAeAAAAYQBjAGMAZQBwAHQAbABhAG4AZwB1AGEAZwBlAAAAAAABAAAAGgAAAGUAbgAtAEcAQgAs ACAAZQBuAC0AVQBTAAAAAAALAACACCAGAAAAAADAAAAAAAAARgAAAAAGhQAAAAAAAB8ANwABAAAA NAAAAEYAVwA6ACAAUAByAGEAZwB1AGUAIABJAEUAVABGACAARwB1AGUAcwB0ACAARABhAHkAAAAf AD0AAQAAAAoAAABGAFcAOgAgAAAAAAADADYAAAAAAAMALgAAAAAAAgFxAAEAAAAWAAAAAdCv78nn WtFDfmFlQweMoK2OrCNc1QAAHwBwAAEAAAAsAAAAUAByAGEAZwB1AGUAIABJAEUAVABGACAARwB1 AGUAcwB0ACAARABhAHkAAAAfADUQAQAAAIAAAAA8ADYANQAxADcANAA0ADIAOQBCADUAQQBGADQA QwA0ADUAQgBEADAANwA5ADgAOAAxADAARQBDADQAOABFADAAQQAzADIANAAzADIANwBEAEMAQABF AFgALQAwAC0ATQBCADIALgBsAGEAbgBjAHMALgBsAG8AYwBhAGwAPgAAAAMA3j+fTgAACwAAgAgg BgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAACACCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAA AAMAgBD/////QAAHMH32H9Hvr9ABCwACAAEAAAADACYAAAAAAAsAKwAAAAAAAgFHAAEAAAA7AAAA Yz1HQjthPSA7cD1MYW5jYXN0ZXIgVW5pdmVyO2w9RVgtMC1NQjItMTUwNjI2MDkwOTMzWi02OTE2 NwAAAgEQMAEAAABGAAAAAAAAAORW9aV8zwZCpU32TjBC9i8HABfTwcbwqapOvGjDDjvY+7oAAATA 93UAABMtdg+zRKhDucjAQoV64AgAMi+EjGsAAAAAHwD6PwEAAAAaAAAASwBpAG4AZwAsACAARABh AG4AaQBlAGwAAAAAAAMACVkBAAAAAwAAgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAACA CCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAAsAAIAIIAYAAAAAAMAAAAAAAABGAAAAAIKFAAAA AAAACwAAgAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAAfAACACCAGAAAAAADAAAAAAAAARgAA AADYhQAAAQAAABIAAABJAFAATQAuAE4AbwB0AGUAAAAAAEAAAIAIIAYAAAAAAMAAAAAAAABGAAAA AL+FAADwEpvR76/QAQMAAIAIIAYAAAAAAMAAAAAAAABGAAAAAOuFAAAJCAAAAwANNP0/AAAfAACA hgMCAAAAAADAAAAAAAAARgEAAAAgAAAAeAAtAG0AcwAtAGgAYQBzAC0AYQB0AHQAYQBjAGgAAAAB AAAAAgAAAAAAAAAfAACAhgMCAAAAAADAAAAAAAAARgEAAAAiAAAAeAAtAG8AcgBpAGcAaQBuAGEA dABpAG4AZwAtAGkAcAAAAAAAAQAAAB4AAABbADgAOAAuADkANwAuADIAMwAuADEAMgAyAF0AAAAA AB8AAICGAwIAAAAAAMAAAAAAAABGAQAAACYAAAB4AC0AaQBzAHMALQBsAG8AYwBhAGwALQBkAG8A bQBhAGkAbgAAAAAAAQAAAAQAAAAxAAAAcWE= --_000_65174429B5AF4C45BD0798810EC48E0A324327DCEX0MB2lancsloca_-- From nobody Fri Jun 26 12:58:08 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3961B30C9 for ; Fri, 26 Jun 2015 12:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BFRRYp9qz9y for ; Fri, 26 Jun 2015 12:58:06 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A3571B304F for ; Fri, 26 Jun 2015 12:58:06 -0700 (PDT) Received: by wicnd19 with SMTP id nd19so26078831wic.1 for ; Fri, 26 Jun 2015 12:58:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:thread-index:content-language; bh=qKRkwV6SnEWC3xcbc15d47QdHd3xLAq5ACv0WtTQh+A=; b=cbga/sTTS2wVYiSGtDQbdVQ1f12qjC5/LFAeQg9jSyTwgI7DZqOGRrK1ecb7kaDFaK hJDlf4PUty/9ufmbZ+hbn8U2uVDIeD+DvHF2jufuV71aFJYqyb86Qax+p6pHU4iFYfZ/ YuX0ollAj7kuq2LSK9gzAW41QVT63IfO3IA9+CkuQXA3iBxDEZFaX8GSiZETJaRCkVyG RMpbnhlM++f3xMVQv6jzYDNry0ceqnXrQHFNLpqThEmv2uBbmipDdDr24JJScwzQaj4k lQ9zlokvWQbGnIRqB55BzO+equR0RdOtk8t7W+JI1xOCPVqqN8sn/TyF3qsXtlPmCAgL cEJA== X-Received: by 10.194.246.105 with SMTP id xv9mr5768822wjc.135.1435348684789; Fri, 26 Jun 2015 12:58:04 -0700 (PDT) Received: from EhalepXPS (ppp079166136100.access.hol.gr. [79.166.136.100]) by mx.google.com with ESMTPSA id ym2sm51815471wjc.44.2015.06.26.12.58.02 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 26 Jun 2015 12:58:03 -0700 (PDT) From: "Haleplidis Evangelos" To: "'King, Daniel'" , "'Anoop Ghanwani'" References: <65174429B5AF4C45BD0798810EC48E0A3242FDFD@EX-0-MB2.lancs.local> <65174429B5AF4C45BD0798810EC48E0A324327A8@EX-0-MB2.lancs.local> In-Reply-To: <65174429B5AF4C45BD0798810EC48E0A324327A8@EX-0-MB2.lancs.local> Date: Fri, 26 Jun 2015 22:58:05 +0300 Message-ID: <000301d0b04a$6c080dc0$44182940$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01D0B063.915545C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdCrkp9Mak8RNrERQiWQPaEzD5iqSQDPQreAAEcLAjAAF4ueIA== Content-Language: el Archived-At: Cc: sdn@irtf.org Subject: Re: [Sdn] IETF 93 - Tutorial for SDN OpenFlow and ForCES X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 19:58:08 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0004_01D0B063.915545C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Greetings Daniel and Annop, =20 That=E2=80=99s exactly the reason for the focus of the tutorial. We = simply don=E2=80=99t have enough time, it=E2=80=99s a lot of material to = cover. This topic could certainly cover a multi-day tutorial. Anoop, in regards to I2RS, you can also check out RFC7426 = (https://tools.ietf.org/html/rfc7426) for an example of how I2RS fits in = the SDN framework. =20 Regards, Evangelos. =20 From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of King, Daniel Sent: Friday, June 26, 2015 12:00 PM To: Anoop Ghanwani Cc: sdn@irtf.org Subject: Re: [Sdn] IETF 93 - Tutorial for SDN OpenFlow and ForCES =20 Hi Anoop,=20 =20 Depends, which SDN framework do we want to discuss. J =20 Personally, I do see I2RS as method of programmatic control (read and = write) of routing state and intent. This certainly sounds like SDN = capability to me. To be fair to the organizers, 2hrs is a limited window = for an SDN tutorial and therefore it is not unreasonable to constrain = the discussion to only two southbound protocols.=20 =20 BR, Dan.=20 =20 From: ghanwani@gmail.com [mailto:ghanwani@gmail.com] On Behalf Of Anoop = Ghanwani Sent: 25 June 2015 00:47 To: King, Daniel Cc: sdn@irtf.org Subject: Re: [Sdn] IETF 93 - Tutorial for SDN OpenFlow and ForCES =20 Where does I2RS fit in within this framework? Is it not considered SDN? =20 Anoop =20 On Sat, Jun 20, 2015 at 12:58 PM, King, Daniel = wrote: Hi All, There will be a "Tutorial for SDN OpenFlow and ForCES" at IETF 93 on = Sunday, July 19, 2015. The tutorial info page is at = ietf.org/meeting/93/tutorials/sdn.html. >> Presented by: Yaakov Stein and Evangelos Haleplidis Day: Sunday, July 19, 2015 Time: 15:00-17:00 Room: TBD Description: 1. The ideas behind the recent awaking of SDN 2. How an SDN is different from a conventional (routed) network 3. The components and interfaces of an SDN (SDN (whitebox) switch, SDN = controller, SBI, NBI) 4. NFV 5. The southbound interfaces (OpenFlow, ForCES, ...) 5.1 Zoom in on OpenFlow 5.2 Zoom in on ForCES << Check the Tutorial link for room assignment closer to the session. BR, Dan. _______________________________________________ sdn mailing list sdn@irtf.org https://www.irtf.org/mailman/listinfo/sdn =20 ------=_NextPart_000_0004_01D0B063.915545C0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Greetings Daniel and Annop,

 

That=E2=80=99s exactly the reason for the focus of the tutorial. We = simply don=E2=80=99t have enough time, it=E2=80=99s a lot of material to = cover. This topic could certainly cover a multi-day = tutorial.

Anoop, in regards to I2RS, you can also check out RFC7426 (https://tools.ietf.org/html/= rfc7426) for an example of how I2RS fits in the SDN = framework.

 

Regards,

Evangelos.

 

From:= sdn = [mailto:sdn-bounces@irtf.org] On Behalf Of King, = Daniel
Sent: Friday, June 26, 2015 12:00 PM
To: = Anoop Ghanwani
Cc: sdn@irtf.org
Subject: Re: [Sdn] = IETF 93 - Tutorial for SDN OpenFlow and = ForCES

 

Hi Anoop,

 

Depends, which SDN framework do we want to discuss. J

 

Personally, I do see I2RS as method of programmatic control  = (read and write) of routing state and intent. This certainly sounds like = SDN capability to me. To be fair to the organizers, 2hrs is a limited = window for an SDN tutorial and therefore it is not unreasonable to = constrain the discussion to only two southbound protocols. =

 

BR, Dan.

 

From: ghanwani@gmail.com [mailto:ghanwani@gmail.com] On = Behalf Of Anoop Ghanwani
Sent: 25 June 2015 = 00:47
To: King, Daniel
Cc: sdn@irtf.org
Subject: Re: = [Sdn] IETF 93 - Tutorial for SDN OpenFlow and = ForCES

 

Where does I2RS fit in within this framework?  Is it = not considered SDN?

 

Anoop

 

On Sat, Jun 20, 2015 at 12:58 PM, = King, Daniel <d.king@lancaster.ac.uk> = wrote:

Hi All,

There will be a "Tutorial for SDN = OpenFlow and ForCES" at IETF 93 on Sunday, July 19, 2015. The = tutorial info page is at  ietf.org/meeting/93/tutorials/sdn.html<http://ietf.org/meeting/93/tutorials/sdn.html>.<= br>
>>
Presented by: Yaakov Stein and Evangelos = Haleplidis
Day: Sunday, July 19, 2015
Time: 15:00-17:00
Room: = TBD
Description:

1. The ideas behind the recent awaking of = SDN
2. How an SDN is different from a conventional (routed) = network
3. The components and interfaces of an SDN (SDN (whitebox) = switch, SDN controller, SBI, NBI)
4. NFV
5. The southbound = interfaces (OpenFlow, ForCES, ...)
     5.1 Zoom in on = OpenFlow
     5.2 Zoom in on = ForCES
<<

Check the Tutorial link for room assignment = closer to the session.

BR, = Dan.

_______________________________________________
sdn = mailing list
sdn@irtf.org
https://www.irtf.org/mailman/listinfo/sdn

 

------=_NextPart_000_0004_01D0B063.915545C0-- From nobody Mon Jun 29 09:25:37 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49AC21AD063 for ; Mon, 29 Jun 2015 09:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.622 X-Spam-Level: X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsjmiJQuUCXv for ; Mon, 29 Jun 2015 09:25:34 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62D6A1AD06E for ; Mon, 29 Jun 2015 09:25:34 -0700 (PDT) Received: by obzt3 with SMTP id t3so17137570obz.3 for ; Mon, 29 Jun 2015 09:25:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=VgFM2Q6pEyWcVBgoJ4NMjD0tXKK2bEoT1sjtzMQEvgM=; b=bd367wplJ7Kzf0es396aDxSPgv+Wh12OQio112Lmpv3cFEqRtIRZ9cPrmET56KPerC SwDmXtIOpAM/6T4YnLSdGV1ayHGraWf+CtKBpXsISJDLOpfN9req2GLHhFURMNT5L+9i kBK9bhsxhgMHXO1e+tsB7BVTDsgJX4P9muAdyNEsYJx/MA3Av7pPSOiedECsvUsCh6cC 6WxiCQaH8RIb0rf0YyzSyVzIBorpFhZoMRFXYe8OjFn8fQN1yvyZiEeHVK38Oh8MVQgm M3mPuGYVKo4rX237xRVpsJXJTKVi2Fr+sDY7sIY23hJ/wYXfXTNAvfwSC04yfIt3eyLw N+2Q== X-Received: by 10.202.194.9 with SMTP id s9mr14392299oif.39.1435595133876; Mon, 29 Jun 2015 09:25:33 -0700 (PDT) MIME-Version: 1.0 Sender: rodrigoruasoliveira@gmail.com Received: by 10.202.224.137 with HTTP; Mon, 29 Jun 2015 09:25:14 -0700 (PDT) In-Reply-To: <65174429B5AF4C45BD0798810EC48E0A3243272C@EX-0-MB2.lancs.local> References: <65174429B5AF4C45BD0798810EC48E0A3243272C@EX-0-MB2.lancs.local> From: Rodrigo Ruas Oliveira Date: Mon, 29 Jun 2015 13:25:14 -0300 X-Google-Sender-Auth: 6vhpS-6MwFRKoPnHESn4ILRL9Yk Message-ID: To: "King, Daniel" Content-Type: multipart/alternative; boundary=001a113dc334feff960519aa8974 Archived-At: Cc: "Songhaibin \(A\)" , "sdn@irtf.org" Subject: Re: [Sdn] SDNRG CFP for IETF 93 X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 16:25:36 -0000 --001a113dc334feff960519aa8974 Content-Type: text/plain; charset=UTF-8 Hi, Daniel, Thank you. I am eager to participate. It seam we are going to create a local hub here at my University. Best, Rodrigo. 2015-06-26 5:37 GMT-03:00 King, Daniel : > Hi Rodrigo, > > Yes indeed. A few remote participation mechanisms exist: > > - Jabber (you can pose questions and these will be reflected at the mic) > - Live audio steam (passive) > - Live video/audio (Meetecho) > > The remote participation page for IETF 93 is not online yet, but you can > see the page for IETF 92 here: > > http://www.ietf.org/meeting/92/remote-participation.html > > BR, Dan. > > From: rodrigoruasoliveira@gmail.com [mailto:rodrigoruasoliveira@gmail.com] > On Behalf Of Rodrigo Ruas Oliveira > Sent: 24 June 2015 16:12 > To: Songhaibin (A) > Cc: King, Daniel; sdn@irtf.org > Subject: Re: [Sdn] SDNRG CFP for IETF 93 > > Is it possible to participate online (ie. watch/hear and post questions)? > I am very interested in this topic. > Em 24/06/2015 09:37, "Songhaibin (A)" escreveu: > Hi Daniel, > > If time allows, I would also like to present a general threat analysis > topic to SDN. > > BR, > -Haibin > > _______________________________________________ > sdn mailing list > sdn@irtf.org > https://www.irtf.org/mailman/listinfo/sdn > --001a113dc334feff960519aa8974 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Daniel,

Thank you. I am eager= to participate. It seam we are going to create a local hub here at my Univ= ersity.

Best,
Rodrigo.
<= div class=3D"gmail_extra">
2015-06-26 5:37 GM= T-03:00 King, Daniel <d.king@lancaster.ac.uk>:
Hi Rodrigo,

Yes indeed. A few remote participation mechanisms exist:

- Jabber (you can pose questions and these will be reflected at the mic) - Live audio steam (passive)
- Live video/audio (Meetecho)

The remote participation page for IETF 93 is not online yet, but you can se= e the page for IETF 92 here:

http://www.ietf.org/meeting/92/remote-partic= ipation.html

BR, Dan.

From: rodrigoruasoliveira@= gmail.com [mailto:rodr= igoruasoliveira@gmail.com] On Behalf Of Rodrigo Ruas Oliveira
Sent: 24 June 2015 16:12
To: Songhaibin (A)
Cc: King, Daniel; sdn@irtf.org
Subject: Re: [Sdn] SDNRG CFP for IETF 93

Is it possible to participat= e online (ie. watch/hear and post questions)? I am very interested in this = topic.
Em 24/06/2015 09:37, "Songhaibin (A)" <haibin.song@huawei.com> escreveu:
Hi Daniel,
=C2=A0
If time allows, I would also like to present a general threat analysis topi= c to SDN.
=C2=A0
BR,
-Haibin

_______________________________________________
sdn mailing list
sdn@irtf.org
https://www.irtf.org/mailman/listinfo/sdn

--001a113dc334feff960519aa8974-- From nobody Tue Jun 30 01:09:22 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5B81A1A6C for ; Tue, 30 Jun 2015 01:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.5 X-Spam-Level: *** X-Spam-Status: No, score=3.5 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, CHARSET_FARAWAY_HEADER=3.2, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUoZ7D4h-DVG for ; Tue, 30 Jun 2015 01:09:18 -0700 (PDT) Received: from SNT004-OMC4S29.hotmail.com (snt004-omc4s29.hotmail.com [65.55.90.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF48B1A1A60 for ; Tue, 30 Jun 2015 01:09:10 -0700 (PDT) Received: from SNT148-W84 ([65.55.90.199]) by SNT004-OMC4S29.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 30 Jun 2015 01:09:09 -0700 X-TMN: [frgBeewy2xJR/QcZFI4s7QM3frDZFlfZ5++ExvdyuHU=] X-Originating-Email: [gurong_cmcc@outlook.com] Message-ID: Content-Type: multipart/alternative; boundary="_239cb768-1943-4d03-b9e8-b3ea95c496d8_" From: =?gb2312?B?ucvI1g==?= To: "sdn@irtf.org" Date: Tue, 30 Jun 2015 08:09:09 +0000 Importance: Normal In-Reply-To: <20150630075248.19265.61023.idtracker@ietfa.amsl.com> References: <20150630075248.19265.61023.idtracker@ietfa.amsl.com> MIME-Version: 1.0 X-OriginalArrivalTime: 30 Jun 2015 08:09:09.0896 (UTC) FILETIME=[0AFB3880:01D0B30C] Archived-At: Subject: [Sdn] Solit comments for our new draft of draft-gu-sdnrg-problem-statement-of-sdn-nfv-in-dc-00.txt X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 08:09:20 -0000 --_239cb768-1943-4d03-b9e8-b3ea95c496d8_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIGRlYXIgYWxsLldlIGhhdmUganVzdCBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQgYWJvdXQgdGhl IHByb2JsZW1zIHdlIGZvdW5kIGluIHRoZSBTRE4gYW5kIE5GViBjby1kZXBsb3ltZW50IGluIGNs b3VkIGRhdGFjZW50ZXJzLiAiZHJhZnQtZ3Utc2RucmctcHJvYmxlbS1zdGF0ZW1lbnQtb2Ytc2Ru LW5mdi1pbi1kYy0wMCIuDQpJbiB0aGlzIGRyYWZ0LCB3ZSBpbnRyb2R1Y2UgdGhlIGNvLWRlcGxv eW1lbnQgdXNlY2FzZSBvZiBTRE4gYW5kIE5GViB0ZWNobm9sb2d5IGluIG91ciBjbG91ZCBkYXRh Y2VudGVycyB3aGljaCBzaG93cyBkaXN0aW5jdCBhZHZhbnRhZ2VzLiBBbmQgYSByZXNvbHV0aW9u IHRlc3QgYWJvdXQgdGhlIFNETiBhbmQgTkZWIGNvLWRlcGxveW1lbnQgaXMgcHJlc2VudGVkIHdp dGgga2V5IHByb2JsZW1zIG9uIG5ldHdvcmsgYXJjaGl0ZWN0dXJlLCB2aXJ0dWFsaXplZCBwbGF0 Zm9ybSwgc3RhbmRhcmQgaW50ZXJmYWNlcyBhbmQgc28gb24gdG8gYmUgZGlzY3Vzc2VkLiANCldl IGhvcGUgd2UgY2FuIHNoYXJlIG91ciB0cmFpbCBwcmFjdGljZSB3aXRoIHlvdSBhbmQgc2VhcmNo IGZvciBhZHZpY2VzIGluIG9yZGVyIHRvIGltcHJvdmUgdGhlIHRyYWlsLkFueSBjb21tZW50cywg c3VnZ2VzdGlvbnMgYW5kIGRpc2N1c3Npb25zIGFyZSB3YXJtbHkgd2VsY29tZWQuVGhhbmsgeW91 LiBBbmQgZmVlbCBmcmVlIHRvIGNvbm5lY3QgbWUuIFRoZSBpbmZvcm1hdGlvbiBvZiB0aGUgZHJh ZnQgaXOjuk5hbWU6CSBkcmFmdC1ndS1zZG5yZy1wcm9ibGVtLXN0YXRlbWVudC1vZi1zZG4tbmZ2 LWluLWRjUmV2aXNpb246CTAwVGl0bGU6CSBQcm9ibGVtIHN0YXRlbWVudCBvZiBTRE4gYW5kIE5G ViBjby1kZXBsb3ltZW50IGluIGNsb3VkIGRhdGFjZW50ZXJzRG9jdW1lbnQgZGF0ZToJMjAxNS0w Ni0zMEdyb3VwOgkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uUGFnZXM6CSA3VVJMOiBodHRwczovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZ3Utc2RucmctcHJvYmxlbS1zdGF0ZW1l bnQtb2Ytc2RuLW5mdi1pbi1kYy0wMC50eHRTdGF0dXM6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWd1LXNkbnJnLXByb2JsZW0tc3RhdGVtZW50LW9mLXNkbi1uZnYtaW4t ZGMvSHRtbGl6ZWQ6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ndS1zZG5yZy1w cm9ibGVtLXN0YXRlbWVudC1vZi1zZG4tbmZ2LWluLWRjLTAwDQpCZXN0IHJlZ2FyZHMgZnJvbSBS b25nIEd1Lmd1cm9uZ19jbWNjQG91dGxvb2suY29tZ3Vyb25nQGNoaW5hbW9iaWxlLmNvbS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gRnJvbTog aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+IFRvOiBndXJvbmdfY21jY0BvdXRsb29rLmNvbTsg bGljaGVueWpAY2hpbmFtb2JpbGUuY29tOyBsaWNoZW55akBjaGluYW1vYmlsZS5jb207IGd1cm9u Z19jbWNjQG91dGxvb2suY29tDQo+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtZ3Utc2RucmctcHJvYmxlbS1zdGF0ZW1lbnQtb2Ytc2RuLW5mdi1pbi1kYy0wMC50 eHQNCj4gRGF0ZTogVHVlLCAzMCBKdW4gMjAxNSAwMDo1Mjo0OCAtMDcwMA0KPiANCj4gDQo+IEEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1ndS1zZG5yZy1wcm9ibGVtLXN0YXRlbWVudC1vZi1z ZG4tbmZ2LWluLWRjLTAwLnR4dA0KPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5 IFJvbmcgR3UgYW5kIHBvc3RlZCB0byB0aGUNCj4gSUVURiByZXBvc2l0b3J5Lg0KPiANCj4gTmFt ZToJCWRyYWZ0LWd1LXNkbnJnLXByb2JsZW0tc3RhdGVtZW50LW9mLXNkbi1uZnYtaW4tZGMNCj4g UmV2aXNpb246CTAwDQo+IFRpdGxlOgkJUHJvYmxlbSBzdGF0ZW1lbnQgb2YgU0ROIGFuZCBORlYg Y28tZGVwbG95bWVudCBpbiBjbG91ZCBkYXRhY2VudGVycw0KPiBEb2N1bWVudCBkYXRlOgkyMDE1 LTA2LTMwDQo+IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+IFBhZ2VzOgkJNw0KPiBV Ukw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWd1LXNkbnJnLXByb2JsZW0tc3RhdGVtZW50LW9mLXNkbi1uZnYtaW4tZGMtMDAudHh0DQo+IFN0 YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1ndS1z ZG5yZy1wcm9ibGVtLXN0YXRlbWVudC1vZi1zZG4tbmZ2LWluLWRjLw0KPiBIdG1saXplZDogICAg ICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWd1LXNkbnJnLXByb2JsZW0tc3Rh dGVtZW50LW9mLXNkbi1uZnYtaW4tZGMtMDANCj4gDQo+IA0KPiBBYnN0cmFjdDoNCj4gICAgV2l0 aCB0aGUgZGV2ZWxvcG1lbnQgb2YgY2xvdWQgY29tcHV0aW5nIHRlY2hub2xvZ3ksIGNsb3VkIGRh dGFjZW50ZXJzDQo+ICAgIGhhdmUgYmVlbiBpbmZsdWVuY2VkLiAgQ28tZGVwbG95bWVudCBvZiBT RE4gYW5kIE5GViB0ZWNobm9sb2d5IHNob3dzDQo+ICAgIGl0cyBkaXN0aW5jdCBhZHZhbnRhZ2Vz IG9mIHZpdGFsaXppbmcgbmV0d29yayByZXNvdXJjZXMgaW4gcHJvdmlkaW5nDQo+ICAgIFZQQyBz ZXJ2aWNlcyBhbmQgU0ZDIHNlcnZpY2VzLkluIG9yZGVyIHRvIGRlcGxveSBTRE4gYW5kIE5GViBp biBjbG91ZA0KPiAgICBkYXRhY2VudGVycywgYSByZXNvbHV0aW9uIHRlc3QgaGFzIGJlZW4gY29u ZHVjdGVkLiAgQWNjb3JkaW5nIHRvIHRoZQ0KPiAgICByZXNvbHV0aW9uIHRlc3QsIFNETiBhbmQg TkZWIHRlY2hub2xvZ3kgaGFzIGJlZW4gbWF0dXJlIGFscmVhZHkgZm9yDQo+ICAgIHRoZSBjb21t ZXJjaWFsIGRlcGxveW1lbnQgaW4gb3BlcmF0b3JzJyBuZXR3b3JrLiAgSG93ZXZlciwgdGhlcmUg YXJlDQo+ICAgIHNvbWUga2V5IHByb2JsZW1zIG9uIG5ldHdvcmsgYXJjaGl0ZWN0dXJlLCB2aXJ0 dWFsaXplZCBwbGF0Zm9ybSwNCj4gICAgc3RhbmRhcmQgaW50ZXJmYWNlcyBhbmQgc28gb24gdG8g YmUgd29ya2luZyBvdXQgaW4gcHJhY3RpY2FsDQo+ICAgIHByYWN0aWNlLg0KPiANCj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIA0KPiANCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRh a2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4gdW50 aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5p ZXRmLm9yZy4NCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+IA0KIAkJIAkgICAJCSAg --_239cb768-1943-4d03-b9e8-b3ea95c496d8_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxzdHlsZT48IS0tDQouaG1tZXNzYWdlIFANCnsNCm1hcmdpbjowcHg7 DQpwYWRkaW5nOjBweA0KfQ0KYm9keS5obW1lc3NhZ2UNCnsNCmZvbnQtc2l6ZTogMTJwdDsNCmZv bnQtZmFtaWx5Os6iyO3RxbraDQp9DQotLT48L3N0eWxlPjwvaGVhZD4NCjxib2R5IGNsYXNzPSdo bW1lc3NhZ2UnPjxkaXYgZGlyPSdsdHInPjxkaXY+PGRpdiBjbGFzcz0iZWN4Q2xlYXJCb3RoIiBz dHlsZT0iY29sb3I6IHJnYig2OCwgNjgsIDY4KTsgZm9udC1mYW1pbHk6ICdNaWNyb3NvZnQgWWFI ZWkgVUknLCAnTWljcm9zb2Z0IFlhSGVpJywgy87M5SwgQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9u dC1zaXplOiAxNXB4OyBsaW5lLWhlaWdodDogMjFweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1 NSwgMjU1LCAyNTUpOyI+SGksIGRlYXIgYWxsLjwvZGl2PjxkaXYgY2xhc3M9ImVjeENsZWFyQm90 aCIgc3R5bGU9ImNvbG9yOiByZ2IoNjgsIDY4LCA2OCk7IGZvbnQtZmFtaWx5OiAnTWljcm9zb2Z0 IFlhSGVpIFVJJywgJ01pY3Jvc29mdCBZYUhlaScsIMvOzOUsIENhbGlicmksIHNhbnMtc2VyaWY7 IGZvbnQtc2l6ZTogMTVweDsgbGluZS1oZWlnaHQ6IDIxcHg7IGJhY2tncm91bmQtY29sb3I6IHJn YigyNTUsIDI1NSwgMjU1KTsiPldlIGhhdmUganVzdCBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQgYWJv dXQgdGhlIHByb2JsZW1zIHdlIGZvdW5kIGluIHRoZSBTRE4gYW5kIE5GViBjby1kZXBsb3ltZW50 IGluIGNsb3VkIGRhdGFjZW50ZXJzLiAiPHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7 IGZvbnQtZmFtaWx5OiDOosjt0cW62iwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNnB4OyBsaW5l LWhlaWdodDogbm9ybWFsOyI+ZHJhZnQtZ3Utc2RucmctcHJvYmxlbS1zdGF0ZW1lbnQtb2Ytc2Ru LW5mdi1pbi1kYy0wMDwvc3Bhbj4iLjwvZGl2PjxkaXYgY2xhc3M9ImVjeENsZWFyQm90aCIgc3R5 bGU9ImNvbG9yOiByZ2IoNjgsIDY4LCA2OCk7IGZvbnQtZmFtaWx5OiAnTWljcm9zb2Z0IFlhSGVp IFVJJywgJ01pY3Jvc29mdCBZYUhlaScsIMvOzOUsIENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQt c2l6ZTogMTVweDsgbGluZS1oZWlnaHQ6IDIxcHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUs IDI1NSwgMjU1KTsiPjxicj48L2Rpdj48ZGl2IGNsYXNzPSJlY3hDbGVhckJvdGgiIHN0eWxlPSJj b2xvcjogcmdiKDY4LCA2OCwgNjgpOyBmb250LWZhbWlseTogJ01pY3Jvc29mdCBZYUhlaSBVSScs ICdNaWNyb3NvZnQgWWFIZWknLCDLzszlLCBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6 IDE1cHg7IGxpbmUtaGVpZ2h0OiAyMXB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUs IDI1NSk7Ij48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IM6i yO3RxbraLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE2cHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7 Ij5JbiB0aGlzIGRyYWZ0LCB3ZSBpbnRyb2R1Y2UgdGhlIGNvLWRlcGxveW1lbnQgdXNlY2FzZSBv ZiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IM6iyO3RxbraLCBzYW5zLXNl cmlmOyBmb250LXNpemU6IDEycHQ7Ij5TRE4gYW5kIE5GViB0ZWNobm9sb2d5IGluIG91ciBjbG91 ZCBkYXRhY2VudGVycyB3aGljaCBzaG93cyZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6IM6iyO3RxbraLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7Ij5kaXN0aW5jdCBh ZHZhbnRhZ2VzLiBBbmQgYSByZXNvbHV0aW9uIHRlc3QgYWJvdXQgdGhlIFNETiBhbmQgTkZWIGNv LWRlcGxveW1lbnQgaXMgcHJlc2VudGVkIHdpdGgga2V5IHByb2JsZW1zIG9uJm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogzqLI7dHFutosIHNhbnMtc2VyaWY7IGZvbnQtc2l6 ZTogMTJwdDsiPm5ldHdvcmsgYXJjaGl0ZWN0dXJlLCB2aXJ0dWFsaXplZCBwbGF0Zm9ybSwmbmJz cDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiDOosjt0cW62iwgc2Fucy1zZXJpZjsg Zm9udC1zaXplOiAxMnB0OyI+c3RhbmRhcmQgaW50ZXJmYWNlcyBhbmQgc28gb24gdG8gYmUgZGlz Y3Vzc2VkLiZuYnNwOzwvc3Bhbj48L2Rpdj48ZGl2IGNsYXNzPSJlY3hDbGVhckJvdGgiIHN0eWxl PSJjb2xvcjogcmdiKDY4LCA2OCwgNjgpOyBmb250LWZhbWlseTogJ01pY3Jvc29mdCBZYUhlaSBV SScsICdNaWNyb3NvZnQgWWFIZWknLCDLzszlLCBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNp emU6IDE1cHg7IGxpbmUtaGVpZ2h0OiAyMXB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAy NTUsIDI1NSk7Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IM6iyO3RxbraLCBzYW5zLXNlcmlm OyBmb250LXNpemU6IDEycHQ7Ij48YnI+PC9zcGFuPjwvZGl2PjxkaXYgY2xhc3M9ImVjeENsZWFy Qm90aCIgc3R5bGU9ImNvbG9yOiByZ2IoNjgsIDY4LCA2OCk7IGZvbnQtZmFtaWx5OiAnTWljcm9z b2Z0IFlhSGVpIFVJJywgJ01pY3Jvc29mdCBZYUhlaScsIMvOzOUsIENhbGlicmksIHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZTogMTVweDsgbGluZS1oZWlnaHQ6IDIxcHg7IGJhY2tncm91bmQtY29sb3I6 IHJnYigyNTUsIDI1NSwgMjU1KTsiPldlIGhvcGUgd2UgY2FuIHNoYXJlIG91ciB0cmFpbCBwcmFj dGljZSB3aXRoIHlvdSBhbmQgc2VhcmNoIGZvciBhZHZpY2VzIGluIG9yZGVyIHRvIGltcHJvdmUg dGhlIHRyYWlsLjwvZGl2PjxkaXYgY2xhc3M9ImVjeENsZWFyQm90aCIgc3R5bGU9ImNvbG9yOiBy Z2IoNjgsIDY4LCA2OCk7IGZvbnQtZmFtaWx5OiAnTWljcm9zb2Z0IFlhSGVpIFVJJywgJ01pY3Jv c29mdCBZYUhlaScsIMvOzOUsIENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTVweDsg bGluZS1oZWlnaHQ6IDIxcHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsi PkFueSBjb21tZW50cywgc3VnZ2VzdGlvbnMgYW5kIGRpc2N1c3Npb25zIGFyZSB3YXJtbHkgd2Vs Y29tZWQuPC9kaXY+PGRpdiBjbGFzcz0iZWN4cmVhZE1zZ0JvZHkiIHN0eWxlPSJjb2xvcjogcmdi KDY4LCA2OCwgNjgpOyBmb250LWZhbWlseTogJ01pY3Jvc29mdCBZYUhlaSBVSScsICdNaWNyb3Nv ZnQgWWFIZWknLCDLzszlLCBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7IGxp bmUtaGVpZ2h0OiAyMXB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij48 ZGl2IGlkPSJlY3hib2R5cmVhZE1lc3NhZ2VQYXJ0Qm9keUNvbnRyb2wxMjNmIiBjbGFzcz0iZWN4 RXh0ZXJuYWxDbGFzcyBlY3hNc2dCb2R5Q29udGFpbmVyIj48ZGl2IGRpcj0ibHRyIj48cCBjbGFz cz0iZWN4TXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdDsiPjxzcGFuIGxh bmc9IkVOLVVTIj5UaGFuayB5b3UuIEFuZCBmZWVsIGZyZWUgdG8gY29ubmVjdCBtZS48L3NwYW4+ PC9wPjxwIGNsYXNzPSJlY3hNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMHB0 OyI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48L3A+PHAgY2xhc3M9ImVjeE1zb1Bs YWluVGV4dCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwcHQ7Ij48c3BhbiBsYW5nPSJFTi1VUyI+ VGhlIGluZm9ybWF0aW9uIG9mIHRoZSBkcmFmdCBpc6O6PC9zcGFuPjwvcD48cCBjbGFzcz0iZWN4 TXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdDsiPjxzcGFuIGxhbmc9IkVO LVVTIj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IM6iyO3R xbraLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE2cHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7Ij5O YW1lOgkgZHJhZnQtZ3Utc2RucmctcHJvYmxlbS1zdGF0ZW1lbnQtb2Ytc2RuLW5mdi1pbi1kYzwv c3Bhbj48YnIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiDOosjt0cW6 2iwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNnB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyI+PHNw YW4gc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiDOosjt0cW62iwgc2Fu cy1zZXJpZjsgZm9udC1zaXplOiAxNnB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyI+UmV2aXNpb246 CTAwPC9zcGFuPjxiciBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IM6i yO3RxbraLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE2cHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7 Ij48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IM6iyO3Rxbra LCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE2cHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7Ij5UaXRs ZToJIFByb2JsZW0gc3RhdGVtZW50IG9mIFNETiBhbmQgTkZWIGNvLWRlcGxveW1lbnQgaW4gY2xv dWQgZGF0YWNlbnRlcnM8L3NwYW4+PGJyIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LWZhbWlseTogzqLI7dHFutosIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTZweDsgbGluZS1oZWln aHQ6IG5vcm1hbDsiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWls eTogzqLI7dHFutosIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTZweDsgbGluZS1oZWlnaHQ6IG5v cm1hbDsiPkRvY3VtZW50IGRhdGU6CTIwMTUtMDYtMzA8L3NwYW4+PGJyIHN0eWxlPSJjb2xvcjog cmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogzqLI7dHFutosIHNhbnMtc2VyaWY7IGZvbnQtc2l6 ZTogMTZweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDAs IDAsIDApOyBmb250LWZhbWlseTogzqLI7dHFutosIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTZw eDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsiPkdyb3VwOgkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uPC9z cGFuPjxiciBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IM6iyO3Rxbra LCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE2cHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7Ij48c3Bh biBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IM6iyO3RxbraLCBzYW5z LXNlcmlmOyBmb250LXNpemU6IDE2cHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7Ij5QYWdlczoJIDc8 L3NwYW4+PGJyIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogzqLI7dHF utosIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTZweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsiPjxz cGFuIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogzqLI7dHFutosIHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTZweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsiPlVSTDogaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWd1LXNkbnJnLXByb2JsZW0t c3RhdGVtZW50LW9mLXNkbi1uZnYtaW4tZGMtMDAudHh0PC9zcGFuPjxiciBzdHlsZT0iY29sb3I6 IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IM6iyO3RxbraLCBzYW5zLXNlcmlmOyBmb250LXNp emU6IDE2cHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7Ij48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigw LCAwLCAwKTsgZm9udC1mYW1pbHk6IM6iyO3RxbraLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE2 cHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7Ij5TdGF0dXM6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWd1LXNkbnJnLXByb2JsZW0tc3RhdGVtZW50LW9mLXNkbi1uZnYtaW4t ZGMvPC9zcGFuPjxiciBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IM6i yO3RxbraLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE2cHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7 Ij48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IM6iyO3Rxbra LCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE2cHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7Ij5IdG1s aXplZDogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWd1LXNkbnJnLXByb2JsZW0t c3RhdGVtZW50LW9mLXNkbi1uZnYtaW4tZGMtMDA8L3NwYW4+PC9zcGFuPjwvcD48cCBjbGFzcz0i ZWN4TXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdDsiPjxicj48L3A+PHAg Y2xhc3M9ImVjeE1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwcHQ7Ij48c3Bh biBsYW5nPSJFTi1VUyI+QmVzdCByZWdhcmRzIGZyb20gUm9uZyBHdS48L3NwYW4+PC9wPjxmb250 IGNvbG9yPSIjMDA2OGNmIiBzdHlsZT0iZm9udC13ZWlnaHQ6IGluaGVyaXQ7IGNvbG9yOiByZ2Io MCwgMTA0LCAyMDcpOyBjdXJzb3I6IHBvaW50ZXI7IGxpbmUtaGVpZ2h0OiBub3JtYWw7Ij48YSBo cmVmPSJtYWlsdG86Z3Vyb25nX2NtY2NAY2hpbmFtb2JpbGUuY29tIiBzdHlsZT0iZm9udC13ZWln aHQ6IGluaGVyaXQ7IGNvbG9yOiByZ2IoMCwgMTA0LCAyMDcpOyBjdXJzb3I6IHBvaW50ZXI7Ij5n dXJvbmdfY21jY0A8L2E+b3V0bG9vay5jb208L2ZvbnQ+PC9kaXY+PGRpdiBkaXI9Imx0ciI+PGZv bnQgY29sb3I9IiMwMDY4Y2YiIHN0eWxlPSJmb250LXdlaWdodDogaW5oZXJpdDsgY29sb3I6IHJn YigwLCAxMDQsIDIwNyk7IGN1cnNvcjogcG9pbnRlcjsgbGluZS1oZWlnaHQ6IG5vcm1hbDsiPmd1 cm9uZ0BjaGluYW1vYmlsZS5jb208L2ZvbnQ+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PGRpdiBj bGFzcz0icm1Ub3BTcGFjZXIgcm1Ub3AiIHN0eWxlPSJsaW5lLWhlaWdodDogMTlweDsgcG9zaXRp b246IHJlbGF0aXZlOyBwYWRkaW5nOiA1cHggMHB4IDBweDsgei1pbmRleDogMDsgbWFyZ2luLXJp Z2h0OiAwcHg7IG9wYWNpdHk6IDA7IGNvbG9yOiByZ2IoNjgsIDY4LCA2OCk7IGZvbnQtZmFtaWx5 OiAnTWljcm9zb2Z0IFlhaGVpIFVJJywgJ01pY3Jvc29mdCBZYWhlaScsIFZlcmRhbmEsIFNpbXN1 biwgJ1NlZ29lIFVJJywgJ1NlZ29lIFVJIFdlYiBSZWd1bGFyJywgJ1NlZ29lIFVJIFN5bWJvbCcs ICdIZWx2ZXRpY2EgTmV1ZScsICdCQkFscGhhIFNhbnMnLCAnUzYwIFNhbnMnLCBBcmlhbCwgc2Fu cy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUs IDI1NSk7Ij48ZGl2IGNsYXNzPSJybUJ1dHRvbnMiIHN0eWxlPSJmbG9hdDogcmlnaHQ7IHdoaXRl LXNwYWNlOiBub3dyYXA7IG1hcmdpbi10b3A6IDhweDsgbWFyZ2luLXJpZ2h0OiAwcHg7Ij48c3Bh biBjbGFzcz0icm1QcmV2IiBzdHlsZT0iZGlzcGxheTogaW5saW5lLWJsb2NrOyB2ZXJ0aWNhbC1h bGlnbjogbWlkZGxlOyBwYWRkaW5nOiAwcHggM3B4OyI+PGltZyBzcmM9Imh0dHBzOi8vc250MTQ4 Lm1haWwubGl2ZS5jb20vb2wvY2xlYXIuZ2lmIiBjbGFzcz0iaV9ybV9wIiBzdHlsZT0id2lkdGg6 IDE2cHg7IGhlaWdodDogMTZweDsgYmFja2dyb3VuZC1pbWFnZTogdXJsKGh0dHBzOi8vYS5nZngu bXMvc3RyaXBfbWV0cm83LnBuZyk7IGJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyBiYWNr Z3JvdW5kLWF0dGFjaG1lbnQ6IHNjcm9sbDsgb3ZlcmZsb3c6IGhpZGRlbjsgYmFja2dyb3VuZC1w b3NpdGlvbjogLTc5cHggLTEyNnB4OyBiYWNrZ3JvdW5kLXJlcGVhdDogbm8tcmVwZWF0IG5vLXJl cGVhdDsiPjwvc3Bhbj48c3BhbiBjbGFzcz0icm1OZXh0IiBzdHlsZT0iZGlzcGxheTogaW5saW5l LWJsb2NrOyB2ZXJ0aWNhbC1hbGlnbjogbWlkZGxlOyBwYWRkaW5nOiAwcHggM3B4OyI+PGltZyBz cmM9Imh0dHBzOi8vc250MTQ4Lm1haWwubGl2ZS5jb20vb2wvY2xlYXIuZ2lmIiBjbGFzcz0iaV9y bV9uIiBzdHlsZT0id2lkdGg6IDE2cHg7IGhlaWdodDogMTZweDsgYmFja2dyb3VuZC1pbWFnZTog dXJsKGh0dHBzOi8vYS5nZngubXMvc3RyaXBfbWV0cm83LnBuZyk7IGJhY2tncm91bmQtY29sb3I6 IHRyYW5zcGFyZW50OyBiYWNrZ3JvdW5kLWF0dGFjaG1lbnQ6IHNjcm9sbDsgb3ZlcmZsb3c6IGhp ZGRlbjsgYmFja2dyb3VuZC1wb3NpdGlvbjogLTc5cHggLTE2MHB4OyBiYWNrZ3JvdW5kLXJlcGVh dDogbm8tcmVwZWF0IG5vLXJlcGVhdDsiPjwvc3Bhbj48c3BhbiBjbGFzcz0icm1GdWxsICIgc3R5 bGU9ImRpc3BsYXk6IGlubGluZS1ibG9jazsgdmVydGljYWwtYWxpZ246IG1pZGRsZTsgcGFkZGlu ZzogMHB4IDBweCAwcHggNnB4OyI+PGltZyBzcmM9Imh0dHBzOi8vc250MTQ4Lm1haWwubGl2ZS5j b20vb2wvY2xlYXIuZ2lmIiBjbGFzcz0iaV9yX2Z2IiBzdHlsZT0id2lkdGg6IDE2cHg7IGhlaWdo dDogMTZweDsgYmFja2dyb3VuZC1pbWFnZTogdXJsKGh0dHBzOi8vYS5nZngubXMvc3RyaXBfbWV0 cm83LnBuZyk7IGJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyBiYWNrZ3JvdW5kLWF0dGFj aG1lbnQ6IHNjcm9sbDsgb3ZlcmZsb3c6IGhpZGRlbjsgYmFja2dyb3VuZC1wb3NpdGlvbjogLTg2 cHggLTU3cHg7IGJhY2tncm91bmQtcmVwZWF0OiBuby1yZXBlYXQgbm8tcmVwZWF0OyI+PC9zcGFu PjxzcGFuIGNsYXNzPSJybUNsb3NlICIgc3R5bGU9ImRpc3BsYXk6IGlubGluZS1ibG9jazsgdmVy dGljYWwtYWxpZ246IG1pZGRsZTsgcGFkZGluZzogMHB4IDBweCAwcHggNnB4OyI+PGltZyBzcmM9 Imh0dHBzOi8vc250MTQ4Lm1haWwubGl2ZS5jb20vb2wvY2xlYXIuZ2lmIiBjbGFzcz0iZ19jbG9z ZSIgc3R5bGU9IndpZHRoOiAxMXB4OyBoZWlnaHQ6IDExcHg7IGJhY2tncm91bmQtaW1hZ2U6IHVy bChodHRwczovL2EuZ2Z4Lm1zL3N0cmlwX21ldHJvNy5wbmcpOyBiYWNrZ3JvdW5kLWNvbG9yOiB0 cmFuc3BhcmVudDsgYmFja2dyb3VuZC1hdHRhY2htZW50OiBzY3JvbGw7IG92ZXJmbG93OiBoaWRk ZW47IGJhY2tncm91bmQtcG9zaXRpb246IC04NnB4IC0xcHg7IGJhY2tncm91bmQtcmVwZWF0OiBu by1yZXBlYXQgbm8tcmVwZWF0OyI+PC9zcGFuPjwvZGl2PjwvZGl2Pi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+PGRpdj4mZ3Q7IEZyb206IGlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxicj4mZ3Q7IFRvOiBndXJvbmdfY21jY0BvdXRsb29rLmNv bTsgbGljaGVueWpAY2hpbmFtb2JpbGUuY29tOyBsaWNoZW55akBjaGluYW1vYmlsZS5jb207IGd1 cm9uZ19jbWNjQG91dGxvb2suY29tPGJyPiZndDsgU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1ndS1zZG5yZy1wcm9ibGVtLXN0YXRlbWVudC1vZi1zZG4tbmZ2LWlu LWRjLTAwLnR4dDxicj4mZ3Q7IERhdGU6IFR1ZSwgMzAgSnVuIDIwMTUgMDA6NTI6NDggLTA3MDA8 YnI+Jmd0OyA8YnI+Jmd0OyA8YnI+Jmd0OyBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZ3Ut c2RucmctcHJvYmxlbS1zdGF0ZW1lbnQtb2Ytc2RuLW5mdi1pbi1kYy0wMC50eHQ8YnI+Jmd0OyBo YXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFJvbmcgR3UgYW5kIHBvc3RlZCB0byB0 aGU8YnI+Jmd0OyBJRVRGIHJlcG9zaXRvcnkuPGJyPiZndDsgPGJyPiZndDsgTmFtZToJCWRyYWZ0 LWd1LXNkbnJnLXByb2JsZW0tc3RhdGVtZW50LW9mLXNkbi1uZnYtaW4tZGM8YnI+Jmd0OyBSZXZp c2lvbjoJMDA8YnI+Jmd0OyBUaXRsZToJCVByb2JsZW0gc3RhdGVtZW50IG9mIFNETiBhbmQgTkZW IGNvLWRlcGxveW1lbnQgaW4gY2xvdWQgZGF0YWNlbnRlcnM8YnI+Jmd0OyBEb2N1bWVudCBkYXRl OgkyMDE1LTA2LTMwPGJyPiZndDsgR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb248YnI+Jmd0 OyBQYWdlczoJCTc8YnI+Jmd0OyBVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWd1LXNkbnJnLXByb2JsZW0tc3RhdGVtZW50LW9mLXNkbi1u ZnYtaW4tZGMtMDAudHh0PGJyPiZndDsgU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWd1LXNkbnJnLXByb2JsZW0tc3RhdGVtZW50LW9mLXNkbi1u ZnYtaW4tZGMvPGJyPiZndDsgSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1ndS1zZG5yZy1wcm9ibGVtLXN0YXRlbWVudC1vZi1zZG4tbmZ2LWluLWRjLTAw PGJyPiZndDsgPGJyPiZndDsgPGJyPiZndDsgQWJzdHJhY3Q6PGJyPiZndDsgICAgV2l0aCB0aGUg ZGV2ZWxvcG1lbnQgb2YgY2xvdWQgY29tcHV0aW5nIHRlY2hub2xvZ3ksIGNsb3VkIGRhdGFjZW50 ZXJzPGJyPiZndDsgICAgaGF2ZSBiZWVuIGluZmx1ZW5jZWQuICBDby1kZXBsb3ltZW50IG9mIFNE TiBhbmQgTkZWIHRlY2hub2xvZ3kgc2hvd3M8YnI+Jmd0OyAgICBpdHMgZGlzdGluY3QgYWR2YW50 YWdlcyBvZiB2aXRhbGl6aW5nIG5ldHdvcmsgcmVzb3VyY2VzIGluIHByb3ZpZGluZzxicj4mZ3Q7 ICAgIFZQQyBzZXJ2aWNlcyBhbmQgU0ZDIHNlcnZpY2VzLkluIG9yZGVyIHRvIGRlcGxveSBTRE4g YW5kIE5GViBpbiBjbG91ZDxicj4mZ3Q7ICAgIGRhdGFjZW50ZXJzLCBhIHJlc29sdXRpb24gdGVz dCBoYXMgYmVlbiBjb25kdWN0ZWQuICBBY2NvcmRpbmcgdG8gdGhlPGJyPiZndDsgICAgcmVzb2x1 dGlvbiB0ZXN0LCBTRE4gYW5kIE5GViB0ZWNobm9sb2d5IGhhcyBiZWVuIG1hdHVyZSBhbHJlYWR5 IGZvcjxicj4mZ3Q7ICAgIHRoZSBjb21tZXJjaWFsIGRlcGxveW1lbnQgaW4gb3BlcmF0b3JzJyBu ZXR3b3JrLiAgSG93ZXZlciwgdGhlcmUgYXJlPGJyPiZndDsgICAgc29tZSBrZXkgcHJvYmxlbXMg b24gbmV0d29yayBhcmNoaXRlY3R1cmUsIHZpcnR1YWxpemVkIHBsYXRmb3JtLDxicj4mZ3Q7ICAg IHN0YW5kYXJkIGludGVyZmFjZXMgYW5kIHNvIG9uIHRvIGJlIHdvcmtpbmcgb3V0IGluIHByYWN0 aWNhbDxicj4mZ3Q7ICAgIHByYWN0aWNlLjxicj4mZ3Q7IDxicj4mZ3Q7ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8YnI+Jmd0OyA8YnI+Jmd0OyA8YnI+Jmd0OyBQbGVhc2Ugbm90ZSB0aGF0IGl0 IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9u PGJyPiZndDsgdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJs ZSBhdCB0b29scy5pZXRmLm9yZy48YnI+Jmd0OyA8YnI+Jmd0OyBUaGUgSUVURiBTZWNyZXRhcmlh dDxicj4mZ3Q7IDxicj48L2Rpdj4gCQkgCSAgIAkJICA8L2Rpdj48L2JvZHk+DQo8L2h0bWw+ --_239cb768-1943-4d03-b9e8-b3ea95c496d8_-- From nobody Tue Jun 30 06:07:19 2015 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0B911A9119 for ; Tue, 30 Jun 2015 06:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.732 X-Spam-Level: X-Spam-Status: No, score=0.732 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jA1mY77G4bs for ; Tue, 30 Jun 2015 06:07:14 -0700 (PDT) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4FAB1A8AA4 for ; Tue, 30 Jun 2015 06:07:13 -0700 (PDT) Received: by wiwl6 with SMTP id l6so131545018wiw.0 for ; Tue, 30 Jun 2015 06:07:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rst+8v7OC9VRXgCGiewdobnp0lf+vS9md2XU/XQ+D44=; b=lQtuWeG+9SRaZbi9mI9FJcZJSrTtHm7wWyN93XZ+iY9LZpsr2X+BwEIV5zk1mhRYrK akEoIzB14uh5MgXdEv/rmHeZSZfi4wQpi0A4d5QYhI3QSRpIDQ8YqfBi5xgnXiEa3BHy AsyoK5Lsrcu4HKKnm0/6DHB+DX6OKWJpI+RFoTgXIGOoyMtT70nPJ0aQgRfzwWFkQ+iQ phgNLrAPN228MHuXudlVW21yqcHPr6JfLDj9VVupd7iEKjMKPkrSDjdJ0M5Ib9CHgNsu zBAOeuBlLBHi1AaQwfMlPB1MBN0+wopw3YLN2oXLWuVeoDzEi5LRjQQIS6J/YwWQXfCt MPPg== X-Gm-Message-State: ALoCoQlXS3nv3oev72fDVm9QKAia+CNuKg538wGO/OArr63uvXbPg85yYdKLqzCXGrAltXoGwzSx MIME-Version: 1.0 X-Received: by 10.194.187.51 with SMTP id fp19mr36422279wjc.67.1435669632457; Tue, 30 Jun 2015 06:07:12 -0700 (PDT) Received: by 10.28.131.202 with HTTP; Tue, 30 Jun 2015 06:07:12 -0700 (PDT) In-Reply-To: <65174429B5AF4C45BD0798810EC48E0A3242FDE9@EX-0-MB2.lancs.local> References: <65174429B5AF4C45BD0798810EC48E0A3242F4CF@EX-0-MB2.lancs.local> <65174429B5AF4C45BD0798810EC48E0A3242FDE9@EX-0-MB2.lancs.local> Date: Tue, 30 Jun 2015 15:07:12 +0200 Message-ID: From: Gino Carrozzo To: "King, Daniel" Content-Type: multipart/alternative; boundary=047d7bb03dce7535b10519bbe288 Archived-At: Cc: "dmm@1-4-5.net" , Konstantinos Pentikousis , "sdn@irtf.org" Subject: Re: [Sdn] SDNRG CFP for IETF 93 X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 13:07:17 -0000 --047d7bb03dce7535b10519bbe288 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Daniel if time allows we also would like to request a slot in the upcoming SDNRG meeting in Prague with a talk on Title:=E2=80=9DFramework for large scale-SDN experiments via Software Defin= ed Federated Infrastructures=E2=80=9D Authors: G. Carrozzo (Nextworks), K. Pentikousis (EICT) Presenter: K. Pentikousis Abstract Network programmability via Software Defined Networking (SDN) tools and dynamic on-demand network service provisioning are key ingredients of the future Internet architecture. Testing of these innovative solutions for network control calls for experimentation using large-scale testbeds in order to emulate near real-world testing conditions and allow for the wider technical and industrial impact. Significant efforts by several projects in Europe, Asia and the US have been made over the last years to create experimental research infrastructures that are reusable and can incorporate the latest network technologies as they emerge. The FELIX project [1] is part of this international research experimentation infrastructure strategy (in Europe under the Future Internet Research Experimentation =E2=80=93 FIR= E =E2=80=93 framework), with a special focus on using SDN and the Network Service Interface (NSI) standard for dynamic transit network connectivity. FELIX facilitates the federation and integration of different network and computing resources controlled via SDN and NSI/BoD in a multi-domain heterogeneous environment across, initially spanning Europe and Japan. To achieve this, FELIX designed and implements a common control framework where users can request, monitor and manage a slice provisioned over distributed and distant SDN experimental facilities. FELIX orchestration and resource management software is currently deployed in a number of interconnected SDN island across Europe and Japan. The FELIX framework uses a combination of recursive and policy-based hierarchical configurations for orchestration, request delegation and inter-domain dependency management. Resource orchestrating entities are responsible for the synchronization of resources available in particular administrative domains. This talk will provide a brief overview of the research activities in the FELIX project. [1] FELIX Project website: http://www.ict-felix.eu We think the topic could be of interest for the SDNRG community discussion. Best regards Gino On 20 June 2015 at 21:51, King, Daniel wrote: > Quick update. The IETF 93 preliminary agenda has been posted. > > For those born before 1980 - > https://datatracker.ietf.org/meeting/93/agenda.txt > Born after 1980 - https://datatracker.ietf.org/meeting/93/agenda.html > > The SDN RG is tentatively scheduled for: > > Wednesday, July 22, 2015 (CEST) > 9:00-11:30 Morning session I > Congress Hall II > > The final agenda will be published on Friday, June 26th, 2015. > > BR, Dan. > > -----Original Message----- > From: King, Daniel > Sent: 17 June 2015 22:40 > To: sdn@irtf.org > Cc: dmm@1-4-5.net > Subject: SDNRG CFP for IETF 93 > > Hi All, > > SDNRG at IETF 93 Call for Presentations > IETF 93 (July 19-24) > Prague, Czech Republic > --------------------------------------- > The Software Defined Networking Research Group (SDNRG) will hold its next > meeting in conjunction with IETF 93 (July 19-24). The SDNRG Program > Committee is now seeking proposals for presentations for the IRTF SDNRG > agenda. > > Presentations highlighting current research in SDN and its applications > are encouraged. Areas of interest include (but are not limited to): > > o Classification of SDN models, including Definitions, > Taxonomies > o SDN model scalability and applicability o Multi-layer programability > and feedback control systems o System Complexity o Network description > languages, abstractions, interfaces and > compilers including methods and mechanisms for (on-line) > verification of correct operation of network/node function. > o Methods for increasing the data-awareness of the network > > The SDNRG is also requesting discussions related to securing Software > Defined Networks, areas of interest include (but are not limited to): > > o Trust models > o Protecting and securing the SDN controllers o Robust policy > frameworks o Forensics and remedial responses > > Key Dates for SDNRG 93 > > SDN Research Group Meeting Date/Time/Location is to be determined. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > CFP Opens immediately for SDNRG 93. > CFP Deadline #1: Presentation Proposal (Abstracts) Due 8 July. > CFP Deadline #2: Presentation Slides Due 19 July (or slightly earlier if > an SDNRG Monday (20th) meeting. > > BR, Dan & dmm > > _______________________________________________ > sdn mailing list > sdn@irtf.org > https://www.irtf.org/mailman/listinfo/sdn > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr. Gino Carrozzo Deputy Head of R&D mobile : +39 348 7610 081 landline : +39 050 3871 679 fax : +39 050 3871 601 e-mail : g.carrozzo@nextworks.it web : www.nextworks.it address : Nextworks s.r.l. via Livornese, 1027 56122 S.Piero a Grado, Pisa, ITALY =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --047d7bb03dce7535b10519bbe288 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Daniel

if time allows we also would = like to request a slot in the upcoming SDNRG meeting in Prague with a talk = on=C2=A0

Title:=E2=80=9DFramework for large s= cale-SDN experiments via Software Defined Federated Infrastructures=E2=80= =9D
Authors: G. Carrozzo (Nextworks), K. Pentikousis (EICT)= =C2=A0
Presenter: K. Pentikousis=C2=A0

Abstract
Network programmability via Software Defined Net= working (SDN) tools and dynamic on-demand network service provisioning are = key ingredients of the future Internet architecture. Testing of these innov= ative solutions for network control calls for experimentation using large-s= cale testbeds in order to emulate near real-world testing conditions and al= low for the wider technical and industrial impact. Significant efforts by s= everal projects in Europe, Asia and the US have been made over the last yea= rs to create experimental research infrastructures that are reusable and ca= n incorporate the latest network technologies as they emerge. The FELIX pro= ject [1] is part of this international research experimentation infrastruct= ure strategy (in Europe under the Future Internet Research Experimentation = =E2=80=93 FIRE =E2=80=93 framework), with a special focus on using SDN and = the Network Service Interface (NSI) standard for dynamic transit network co= nnectivity. FELIX facilitates the federation and integration of different n= etwork and computing resources controlled via SDN and NSI/BoD in a multi-do= main heterogeneous environment across, initially spanning Europe and Japan.= To achieve this, FELIX designed and implements a common control framework = where users can request, monitor and manage a slice provisioned over distri= buted and distant SDN experimental facilities. FELIX orchestration and reso= urce management software is currently deployed in a number of interconnecte= d SDN island across Europe and Japan. The FELIX framework uses a combinatio= n of recursive and policy-based hierarchical configurations for orchestrati= on, request delegation and inter-domain dependency management. Resource orc= hestrating entities are responsible for the synchronization of resources av= ailable in particular administrative domains. This talk will provide a brie= f overview of the research activities in the FELIX project.

<= /div>

[1] =C2=A0 =C2=A0FELIX Project website: http://www.ict-felix.eu

<= /div>

We think the topic could be of interest for the SD= NRG community discussion.

Best regards
G= ino

On= 20 June 2015 at 21:51, King, Daniel <d.king@lancaster.ac.uk><= /span> wrote:
Quick update. The IETF 93 p= reliminary agenda has been posted.

For those born before 1980 - https://datatracker.i= etf.org/meeting/93/agenda.txt
Born after 1980 - https://datatracker.ietf.org/me= eting/93/agenda.html

The SDN RG is tentatively scheduled=C2=A0 for:

Wednesday, July 22, 2015 (CEST)
9:00-11:30 Morning session I
Congress Hall II

The final agenda will be published on Friday, June 26th, 2015.

BR, Dan.

-----Original Message-----
From: King, Daniel
Sent: 17 June 2015 22:40
To: sdn@irtf.org
Cc: dmm@1-4-5.net
Subject: SDNRG CFP for IETF 93

Hi All,

SDNRG at IETF 93 Call for Presentations
IETF 93 (July 19-24)
Prague, Czech Republic
---------------------------------------
The Software Defined Networking Research Group (SDNRG) will hold its next m= eeting in conjunction with IETF 93 (July 19-24).=C2=A0 The SDNRG Program Co= mmittee is now seeking proposals for presentations for the IRTF SDNRG agend= a.

Presentations highlighting current research in SDN and its applications are= encouraged. Areas of interest include (but are not limited to):

=C2=A0o Classification of SDN models, including Definitions,
=C2=A0 =C2=A0Taxonomies
=C2=A0o SDN model scalability and applicability=C2=A0 o Multi-layer program= ability and feedback control systems=C2=A0 o System Complexity=C2=A0 o Netw= ork description languages, abstractions, interfaces and
=C2=A0 =C2=A0compilers including methods and mechanisms for (on-line)
=C2=A0 =C2=A0verification of correct operation of network/node function. =C2=A0o Methods for increasing the data-awareness of the network

The SDNRG is also requesting discussions related to securing Software Defin= ed Networks, areas of interest include (but are not limited to):

=C2=A0o Trust models
=C2=A0o Protecting and securing the SDN controllers=C2=A0 o Robust policy f= rameworks=C2=A0 o Forensics and remedial responses

Key Dates for SDNRG 93

SDN Research Group Meeting Date/Time/Location is to be determined.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
CFP Opens immediately for SDNRG 93.
CFP Deadline #1: Presentation Proposal (Abstracts) Due 8 July.
CFP Deadline #2: Presentation Slides Due 19 July (or slightly earlier if an= SDNRG Monday (20th) meeting.

BR, Dan & dmm

_______________________________________________
sdn mailing list
sdn@irtf.org
https://www.irtf.org/mailman/listinfo/sdn



--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0 Dr. Gino = Carrozzo
=C2= =A0 Deputy Head of R&D

=C2=A0 mobile =C2=A0 =C2=A0: +39 348 7610 081
=C2=A0 landline =C2=A0: +39 050 3871 67= 9 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 fax =C2=A0 =C2=A0= =C2=A0 =C2=A0 : +39 050 3871 601 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0
=C2=A0 e-mail =C2=A0 =C2=A0: g.carrozzo@nextworks.it =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0=C2=A0
=C2=A0 web =C2=A0 =C2=A0 =C2=A0 : www.nextworks.it =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0=C2=A0
=C2=A0 address =C2=A0 : Nextworks s.r.l.
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 via Livornese, 1027 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 56122 S.Piero a Grado, Pisa, ITALY = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0
=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
--047d7bb03dce7535b10519bbe288--