From nobody Tue Aug 4 04:00:58 2015 Return-Path: X-Original-To: ibnemo@ietfa.amsl.com Delivered-To: ibnemo@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2910C1B37A6 for ; Tue, 4 Aug 2015 04:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.154 X-Spam-Level: X-Spam-Status: No, score=-95.154 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_21=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 qlWFBVgxIHwa for ; Tue, 4 Aug 2015 04:00:48 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 C2E2F1B37A2 for ; Tue, 4 Aug 2015 04:00:47 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.190.172; From: "Susan Hares" To: Date: Tue, 4 Aug 2015 07:00:25 -0400 Message-ID: <018101d0cea4$c49aebb0$4dd0c310$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0182_01D0CE83.3D93FA10" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdDOpLt4UV6LaXOWQKKjSC942dT1Yg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Ibnemo] Report on IB-Nemo meeting at IETF 93 on 7/23/2015 (20:00-21:15) X-BeenThere: ibnemo@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of Nemo, an intent-based North Bound \(NB\) interface consisting of an application protocol running over HTTP \(RESTful interfaces\) to exchange intent-based primitives between applications and meta-controllers controlling virtual network resources \(networks, storage, CPU\)." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 11:00:56 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0182_01D0CE83.3D93FA10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit We had a second lively discussion during IETF 93 on Thursday (7/23/2015) from 20:00-21:15. Attendees for Thursday meeting (7/23/2015) . Bert Wijnen's - Huawei / consultant . Pedro A. Aranda - Telefonica . Susan Hares - Huawei/consultant . Tianran Zhou - Huawei . Hannu Flinck - Nokia networks . Alexander Clemm - Cisco . Dan Romascanu - Avaya . Andy Veitch - Netcracker . Hesham Eibakouny - Huawei . Scott Bradner - Harvard University . Mehmet Ersue - Nokia Networks . Benoit Claise - Cisco . Bing Liu Huawei . Sheng Jian - Huawei . Michael Scharf - ALU . Sabine Ranriamasy - ALU . Michael Kloberdans [Cable Labs] . Anita - Comments on the presentation: 1) [slide 12] Arrows go from processing engine and are labeled "Network- Wide Data models". Should these arrows be single direction or dual headed? Sue's response: These arrows should be dual direction as the Nemo Language Processing element will both read and write the Yang data models. The network-wide yang data models will be created by other groups. 2) [slide 12] The Higher-level Intent blocks (in green on slide 12) could use Netconf. Sue's response: It is unclear how the IB-Nemo commands would be expressed in NETCONF. The use of NETCONF may require more operations than the IB-Nemo set. 3) [slide 12] Anita: Intent: Can those who wish to use Intent use Nemo? a) Concern: Does Nemo's intent have a different intent than other intents? Sue's response: Nemo's Intent is focused on a minimal set of commands. b) Concern: What is the canonical representation of Intent? Sue's response: The canonical representation of Intent is being discussed in many forums. I will provide a summary to the ibnemo mail list as a separate item. [Todo #1] 4) What is Service-based Intent? a) Sue's Response: Customer gets what he wants is the measure of intent. b) Anita: Network orders outside of the carrier could be done in Nemo and then it would break into the "box commands". Sue's response: We need more clarity on the "box commands from Anita. I am unclear if box commands means CLI commands or something else. I will query the list regarding Anita's question [Todo #2] 5) There are multiple the interactions between the publication and executive element? a) Where do we pay the complexity fee of translating the Nemo? Sue's Response: "The Nemo's language engine translates from Nemo language to IETF network-wide yang modules [see slide 12]. In the future, these IETF network-wide yang modules should have a clearly defined way to translate to device-specific yang modules. Without these IETF network-wide yang modules, the Nemo language engine translates Nemo commands to device-specific yang modules or device-specific commands. " 6) Are all policies expressed in this language? a) Sue's Response: As far as we know all policies are expressed. However, this is a good question to query to the ibnemo mail list. [To-do #3] 7) Security of what the user can do? How bad can the Intent-user screw up the network? [See slide 12] a) Sue's Response: The security of the transport of Nemo commands depends on the transport and the mutual identification of the Nemo interface in the Application 8) Access completeness of the Nemo interaction? a) Who is doing the Intent Interaction? b) Who is the actor? c) Is there compartmentalization of the work? Sue's response: The Intent interaction occurs between the application (APP, Nemo Web Gui, or Nemo script) in slide 12 and the Nemo Language Processing engine. The Intent actor is the application that sends the commands to the Nemo Language Engine. The Nemo Language Engine in turn interacts with the Yang Network-wide Data Models. The compartmentalization of the Nemo Work is to carefully define the language that sets-up and send the commands. 9) [Benoit Claise] Is IB-Nemo domain specific? (a) If it is outside the scope of IETF, leave it to the market to decide which open source initiative would be selected. (b) Configured service models are outside the scope of the IETF. (c) Use cases need to be stabilized - What is fast enough for the Intent? What exactly is happening in the use cases? Sub-Questions: a) Benoit: If it is outside the scope of the IETF; leave it to the market to decide which open source initiative would be selected. Sue's comment: The ibnemo effort desire to standardize Nemo - a simple language for Intent expression. There are 3 Open Daylight Models (ODL) that working on Intent based networking: . ODL Network Intent Composition (NIC) - which seeks to include all intent in a single interface (https://wiki.opendaylight.org/view/Network_Intent_Composition:Main), . ODL Nemo - which seeks to include the minimum set of Intent commands plus modeling commands in a language, and . Group-Based Policy - which is growing toward the Intent from the concept of contracts between end points. The open source market is moving with 3 different models, and it is not clear that any of these models fits all the sizes of Intent. Since ODL NIC seeks to have all Intent commands in an interface, and ODL Nemo seeks to have a minimal set within an interface, it is unlikely these two models will converge. [to-do #4] The IB-Nemo list will discuss the differences between the different open-source efforts. A summarization of this work will be posted as an FAQ on www.nemo-project.net. b) Benoit: Configured service models are outside the scope of the IETF. Sue's comment: It is unclear what Benoit Claise meant by configured service models, so we need to ask Benoit to define what he means by "configured service models." [todo #5] c) Use cases need to be stabilized i) What is fast enough for the Intent? ii) What exactly is happening? Sue's comment: The IBNemo list needs to work on the use cases. This should a strong forward focus for August and September. 10) Can Nemo do L3VPN from the LS3M? Sue's Comment: IB-Nemo could be used to establish a L3VPN connection, but the details of the additional models need to be worked out. IB-Nemo needs to prove that we can read service information from the network service models. [Todo #6] 11) Is IBNemo role based? Sue's Comment: The demonstration showed that the can be an Intent from the User level (see slide 12 and slide 15), and intent from the Operators (see slide 16). These are two different roles. Question: Does this make this role based? Sue's Comment: We have different sets of "intent expression commands" that can/will/may be used by actors in different roles (e.g. end-user, network architect, etc). 12) Why is this not just mininet expanded? Pedro Aranda's comments: . The IB-Nemo implementation shown is the implementation of a concept, not even a proof of concept. . We used mininet because we wanted to show the IB-Nemo work locally. If we had relied on someone providing the connectivity to a lab where we had an Open Daylight Controller which controlled a real infrastructure (with real network elements) we would not have been able to show a useful demo due to the poor quality WiFi service within the Prague Hotel. Sue's comment: . The source code for IB-Nemo in ODL is at: https://wiki.opendaylight.org/view/NEMO:Main. . The early demo code is there on top of the Helium release, but the IB-Nemo is targeted for the Beryllium release. 13) The use cases need addition work to provide a) Who is the actor? b) How does it work in a home network environment? c) How does it work with a service provider? d) Parental control application needs more Sue's Comment: We need to provide better use cases with these questions answered. We will solicit the ibnemo list for contributions. [Todo #7] 14) Need additional details on why the 80/20 rule is useful. These details should include: a) What is the long-term benefit for applications? b) Why does a more user-friendly interface help? c) What is the benefit for the service provider? Sue's comment: We need to enhance our use cases during August [Todo #6] 15) [From email by Dan Romascanu] "The technical question raised by Sue is whether NETCONF and/or RESTCONF are suitable for simpler possibly automated actions between applications and a network management systems that use declarative (intent-based) policy models, or we need something else? It certainly is worth a discussion IMO. Benoit's question response to these questions: . The question is where should this discussion happen? In SUPA? . And should the outcome of this discussion influence the SUPA results? . At the last [SUPA] BoF, I recall mentioning "I hope you don't want a new protocol?" Answer: "no" Sue's response: Intent-Based Nemo's (IB-Nemo) focus is on a minimal set of commands that can be passed over other transport protocols (E.g. http). The question "new protocol" implies a transport protocol and commands. IBnemo simply looks to pass a minimal set of commands to express Intent for most applications. IB-Nemo should discuss this differences between IB-Nemo and other protocols (RESTCONF, NETCONF, and SUPA). SUPA is focused on generic models and its charter (per Benoit) for ECA and Intent-based. In summarizing SUPA, Benoit considers the larger generic model for Intent-Based to be experimental. This may be because of large scope of a complete Intent interface. IB-Nemo does not look to be a "complete Intent interface" but an interface that express Intent for most applications. [Todo #8: Continue discussing on the ibnemo list the differences between NETCONF/RESTCONF and IB-Nemo.] Action items from Discussion: 1. Discuss the Canonical definition of Intent on the ibnemo list [from question 3] 2. Discuss what is Service-based Intent on the ibnemo list, and try to determine what "box commands" might be? [from question 4] 3. Discuss if all policies capable of being expressed by Nemo? [from question 6]. 4. The IB-Nemo list will discuss the differences between the different open-source efforts. A summarization of this work will be posted as an FAQ on www.nemo-project.net. [from question 9]. 5. Query Benoit Claise on his definition of configured service models [from question 9], and post a thread regarding this to the ibnemo list. 6. Provide an example of how IB-Nemo could be used to support L3VPN service model that L3SM is providing, and Discuss this on the ibnemo mail list. 7. Solicit the ibnemo for use cases with these questions answered. o Who is the actor? o How does it work in a home network environment? o How does it work with a service provider? o Parental control application needs more 8. Continue discussing on the IB-Nemo list the differences between NETCONF/RESTCONF and IB-Nemo, and the differences between SUPA and IB-Nemo. Additional action items suggested at IETF: . Get feedback from operator forms (NANOG, RIPE) via side-bar meetings or presentations, . Work with other ODL and ONF groups to create a clear definition of Intent, . Work with other ODL Intent groups to try to determine the position of each group, and . Determine steps we need to take for the BOF at IETF 94 (Yokohama). ------=_NextPart_000_0182_01D0CE83.3D93FA10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We had a second lively discussion during IETF 93 on = Thursday (7/23/2015) from 20:00-21:15. 

Attendees for Thursday meeting (7/23/2015) =

·         = Bert Wijnen’s  - Huawei / consultant =

·         = Pedro A. Aranda - =  Telefonica

·         = Susan Hares – = Huawei/consultant

·         = Tianran Zhou – Huawei

·         = Hannu Flinck – Nokia = networks

·         = Alexander Clemm – Cisco

·         = Dan Romascanu – Avaya

·         = Andy Veitch – Netcracker

·         = Hesham Eibakouny – Huawei

·         = Scott Bradner – Harvard University =

·         = Mehmet Ersue – Nokia = Networks

·         = Benoit Claise  - Cisco

·         = Bing Liu Huawei

·         = Sheng Jian – Huawei

·         = Michael Scharf – ALU

·         = Sabine Ranriamasy – ALU

·         = Michael Kloberdans [Cable Labs]

·         = Anita  -  

Comments on the presentation:

1)      = [slide 12] Arrows go from processing engine and are = labeled “Network- Wide Data models”.   Should = these arrows be single direction or dual headed? =

=  

Sue’s response: These arrows should be dual = direction as the Nemo Language Processing element will both read and = write the Yang data models.   The network-wide yang data = models will be created by other groups.

=  

2)      = [slide 12] The Higher-level Intent blocks (in green on = slide 12) could use Netconf.  

=  

= Sue’s = response:  It is unclear how the IB-Nemo commands would be = expressed in NETCONF.   The use of NETCONF may require more = operations than the IB-Nemo set.

=  

3)      = [slide 12] Anita: Intent: Can those who wish to use = Intent use Nemo?

a)      = Concern: Does Nemo’s intent have a different = intent than other intents?

 

Sue’s response: Nemo’s Intent is focused on = a minimal set of commands.

 

b)      = Concern: What is the canonical representation of = Intent?

   =

Sue’s = response:  The canonical representation of Intent is being = discussed in many forums. 

I will provide a summary = to the ibnemo mail list as a separate item.  [Todo #1] =

 

 

4)      = What is Service-based Intent?

a)      = Sue’s Response: Customer gets what he wants is the = measure of intent. 

 

b)      = Anita: Network orders outside of the carrier could be = done in Nemo and then it would break into the “box = commands”.

  =

Sue’s response:   We need more clarity = on the “box commands from Anita.  I am unclear if box = commands means CLI commands or something else.  I will query the = list regarding Anita’s question [Todo #2]

 

5)      = There are multiple the interactions between the = publication and executive element? 

a)      = Where do we pay the complexity fee of translating the = Nemo?

 

Sue’s Response: "The Nemo's language engine = translates from Nemo language to IETF network-wide yang modules [see = slide 12].   In the future, these IETF network-wide yang = modules should have a clearly defined way to translate to = device-specific yang modules.    Without these IETF = network-wide yang modules, the Nemo language engine translates Nemo = commands to device-specific yang modules or device-specific commands. = "

 

6)      = Are all policies expressed in this language? =

a)      = Sue’s Response:  As far as we know all = policies are expressed.  However, this is a good question to query = to the ibnemo mail list. 

[To-do #3]

=  

7)      = Security of what the user can do?  How bad can the = Intent-user screw up the network? [See slide 12] =

a)      = Sue’s  Response:  The security of the = transport of Nemo commands depends on the transport and the mutual = identification of the Nemo interface in the Application =

=  

8)      = Access completeness of the Nemo interaction? =

a)      = Who is doing the Intent Interaction? =

b)      = Who is the actor?

c)      = Is there compartmentalization of the = work?

 

Sue’s response: =

The Intent interaction = occurs between the application (APP, Nemo Web Gui, or Nemo script) in = slide 12 and the Nemo Language Processing engine.  The Intent actor = is the application that sends the commands to the Nemo Language = Engine.   The Nemo Language Engine in turn interacts with the = Yang Network-wide Data Models. 

 

The compartmentalization = of the Nemo Work is to carefully define the language that sets-up and = send the commands.

 

9)      = [Benoit Claise] Is IB-Nemo domain specific?  (a) If = it is outside the scope of IETF, leave it to the market to decide which = open source initiative would be selected.  (b) Configured service = models are outside the scope of the IETF.  (c) Use cases need to be = stabilized - What is fast enough for the Intent?  What exactly is = happening in the use cases?

 

Sub-Questions: =

 

a)      = Benoit:  If it is outside the scope of the IETF; = leave it to the market to decide which open source initiative would be = selected.

 

= Sue’s = comment:  The ibnemo effort desire to standardize Nemo - a simple = language for Intent expression.

=  

= There are 3 Open = Daylight Models (ODL) that working on Intent based networking: =

 

·         = ODL Network Intent Composition (NIC) -  which seeks = to include all intent in a single interface (https://wiki.opendaylight.org/view/Network_Intent_Composition:Main= ),

·         = ODL Nemo – which seeks to include the minimum set = of Intent commands plus modeling commands in a language, = and

·         = Group-Based Policy – which is growing toward the = Intent from the concept of contracts between end points.   =

 

The open source market = is moving with 3 different models, and it is not clear that any of these = models fits all the sizes of Intent.   Since ODL NIC seeks to = have all Intent commands in an interface, and ODL Nemo seeks to have a = minimal set within an interface, it is unlikely these two models will = converge.  

 

[to-do #4] The IB-Nemo = list will discuss the differences between the different open-source = efforts.  A summarization of this work will be posted as an FAQ on = www.nemo-project.net. =

 

b)      = Benoit: Configured service models are outside the scope = of the IETF.

 

Sue’s comment: It = is unclear what Benoit Claise meant by configured service models, so we = need to ask Benoit to define what he means by “configured service = models.”   [todo #5]

 

c)      = Use cases need to be stabilized

i)        = What is fast enough for the Intent? =

ii)      = What exactly is happening?

 

Sue’s = comment:  The IBNemo list needs to work on the use = cases.  This should a strong forward focus for August and = September.

 

10)   Can Nemo do L3VPN = from the LS3M?

=  

= Sue’s = Comment:  IB-Nemo could be used to establish a L3VPN connection, = but the details of the additional models need to be worked = out.   IB-Nemo needs to prove that we can read service = information from the network service models.  [Todo #6] =

=  

11)  Is IBNemo role based? =

=  

= Sue’s = Comment:  The demonstration showed that the can be an Intent from = the User level (see slide 12 and slide 15), and intent from the = Operators (see slide 16).   These are two different = roles. 

=  

= Question: Does = this make this role based?

=  

= Sue’s = Comment:  We have different sets of  “intent  = expression commands" that can/will/may be used by actors in different roles = (e.g. end-user, network architect, etc).

=  

12)  Why is this not just = mininet expanded?  

 

Pedro Aranda’s comments:

·         = The IB-Nemo implementation shown is the implementation = of a concept, not even a proof of concept.   =

·         = We used mininet because we wanted to show the IB-Nemo = work locally.  If we had relied on someone providing the = connectivity to a lab where we had an Open Daylight Controller which = controlled a real infrastructure (with real network elements) we would = not have been able to show a useful demo due to the poor quality WiFi = service within the Prague Hotel.

 

Sue’s comment:

·         = The source code for IB-Nemo in ODL is at: https://wiki.openda= ylight.org/view/NEMO:Main.

·         = The early demo code is there on top of the Helium = release, but the IB-Nemo is targeted for the Beryllium release.  =

 

13)  The use cases need = addition work to provide

a)      = Who is the actor?

b)      = How does it work in a home network environment? =

c)      = How does it work with a service = provider?

d)      = Parental control application needs more =

 

Sue’s Comment: = We need to provide better use cases with these questions answered.  = We will solicit the ibnemo list for contributions.  [Todo #7] =

 

14)  Need additional details = on why the 80/20 rule is useful.  These details should = include:

a)      = What is the long-term benefit for applications? =

b)      = Why does a more user-friendly interface help? =

c)      = What is the benefit for the service provider? =

Sue’s comment: We = need to enhance our use cases during August [Todo #6] =

15)  =  [From email by Dan Romascanu] =

“The technical = question raised by Sue is whether NETCONF and/or RESTCONF are suitable = for simpler possibly automated actions between applications and a = network management systems that use declarative (intent-based) policy = models, or we need something else?  It certainly is worth a = discussion IMO.

Benoit’s question = response to these questions: 

·         = The question is where should this discussion happen? In = SUPA?

·         = And should the outcome of this discussion influence the = SUPA results?

·         = At the last [SUPA] BoF, I recall mentioning "I hope = you don't want a new protocol?" Answer: "no"

Sue’s response:  Intent-Based Nemo’s = (IB-Nemo) focus is on a minimal set of commands that can be passed over = other transport protocols (E.g. http).    The question = “new protocol” implies a transport protocol and = commands.  IBnemo simply looks to pass a minimal set of commands to = express Intent for most applications.    IB-Nemo should = discuss this differences between IB-Nemo and other protocols (RESTCONF, = NETCONF, and SUPA).

SUPA is focused on = generic models and its charter (per Benoit) for ECA and = Intent-based.  In summarizing SUPA, Benoit considers the larger = generic model for Intent-Based to be experimental.   This may = be because of large scope of a complete Intent interface.   = IB-Nemo does not look to be a “complete Intent interface” = but an interface that express Intent for most applications. =

[Todo #8:  Continue = discussing on the ibnemo list the differences between NETCONF/RESTCONF = and IB-Nemo.]

 

Action items from Discussion: =

1.      = Discuss the Canonical definition of Intent on the ibnemo = list [from question 3] 

2.      = Discuss what is Service-based Intent on the ibnemo list, = and try to determine what “box commands” might be?  = [from question 4]

3.      = Discuss if all policies capable of being expressed by = Nemo? [from question 6].

4.      = The IB-Nemo list will discuss the differences between = the different open-source efforts.  A summarization of this work = will be posted as an FAQ on www.nemo-project.net.  = [from question 9].

5.      = Query Benoit Claise on his definition of configured = service models [from question 9], and post a thread regarding this to = the ibnemo list.

 

6.      = Provide an example of how IB-Nemo could be used to = support L3VPN service model that L3SM is providing, and Discuss this on = the ibnemo mail list.

 

7.      = Solicit the ibnemo for use cases with these questions = answered. 

o   Who is the actor? =

o   How does it work in a = home network environment?

o   How does it work with a = service provider?

o   Parental control = application needs more

=  

8.      = Continue discussing on the IB-Nemo list the differences = between NETCONF/RESTCONF and IB-Nemo, and the differences between SUPA = and IB-Nemo.

 

<= span style=3D'font-family:"Times New Roman","serif"'>Additional action = items suggested at IETF:

·         = Get feedback from operator forms (NANOG, RIPE) via = side-bar meetings or presentations,

·         = Work with other ODL and ONF groups to create a clear = definition of Intent,

·         = Work with other ODL Intent groups to try to determine = the position of each group, and

·         = Determine steps we need to take for the BOF at IETF 94 = (Yokohama).

 

------=_NextPart_000_0182_01D0CE83.3D93FA10-- From nobody Fri Aug 7 11:46:36 2015 Return-Path: X-Original-To: ibnemo@ietfa.amsl.com Delivered-To: ibnemo@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03CBF1B2B98; Fri, 7 Aug 2015 11:46:34 -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 OqGuaryM8iJq; Fri, 7 Aug 2015 11:46:31 -0700 (PDT) Received: from lb2-smtp-cloud3.xs4all.net (lb2-smtp-cloud3.xs4all.net [194.109.24.26]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 419381B2AFC; Fri, 7 Aug 2015 11:46:30 -0700 (PDT) Received: from Macintosh.fritz.box ([83.163.239.181]) by smtp-cloud3.xs4all.net with ESMTP id 1umN1r0023vXPcr01umPZd; Fri, 07 Aug 2015 20:46:29 +0200 Message-ID: <55C4FCFE.8070701@bwijnen.net> Date: Fri, 07 Aug 2015 20:46:22 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Benoit Claise , "supa@ietf.org" References: <55C4D6C1.5040504@cisco.com> In-Reply-To: <55C4D6C1.5040504@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "Eggert, Lars" , "ibnemo@ietf.org" Subject: Re: [Ibnemo] [Supa] SUPA charter proposal X-BeenThere: ibnemo@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of Nemo, an intent-based North Bound \(NB\) interface consisting of an application protocol running over HTTP \(RESTful interfaces\) to exchange intent-based primitives between applications and meta-controllers controlling virtual network resources \(networks, storage, CPU\)." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 18:46:34 -0000 Hi Benoit and others. So would this work prevent the formation of a WG that would do IBNEMO (Intent Based NEtwork MOdeling) work? I certainly hope not. In the charter you have: (iii) the working group will investigate the practically of building policy rules that declaratively specify what goals to achieve (this is often called "intent-based" policy) but not how to achieve those goals and may create a model accordingly. IBNEMO intends (no pun intended) to define/standardize a Intent expression language. The work you describe above can be input to the work IBNEMO wants to do. Bert On 07/08/15 18:03, Benoit Claise wrote: > Dear all, > > As promised in my last email ("SUPA: Situation Summary and Next Steps"), here is a proposed charter. > Thanks to Robert Sparks, Adrian Farrel, and Dan Romascanu. > > Hopefully, this new version will clarify the situation, and will be acceptable to everybody. > Please let us know. Note: I prefer to keep the edit token from now. > > Regards, Benoit (OPS AD) > > ============================================================== > > SUPA CHARTER PROPOSAL (2015-08-07) > > Policy is an important configurable component in the delivery of services and the operation of networks. Operators want and need > to be able to determine the policies that apply to their different customers and to the equipment that comprises their physical > and virtual networks. As policy spans such a wide range of services and device types, it will be helpful if there is a common way > of expressing and describing policies that is uniform and consistent in all environments. Such an approach will help to avoid > configuration errors that arise from confusion between different systems, will enable easy understanding of policies that apply in > different environments, will make the implementation of policy-based systems quicker and cheaper, and will facilitate the rapid > development of standards-based data models that include policy elements. > > SUPA (Simplified Use of Policy Abstractions) defines a model to interface with a network management function (within a controller, > an orchestrator, a network element) that takes high-level, possibly network-wide policies as input. SUPA will not define what the > function does with that input but anticipates that it will ultimately result in network configuration changes > > Practically, SUPA will define generic YANG data models to encode policy, which can point to device-, technology-, and > service-specific YANG models of other working groups. > > SUPA will be designed to work with device, protocol, network, and service data models. > > The SUPA working group will develop a model for expressing policy at different levels of abstraction.Specifically, three model > fragments are envisioned: (i) a generic model that defines concepts and vocabulary needed by policy management independent of the > form and content of the policy, (ii) a more specific model that refines the generic model to specify how to build policy rules of > the event-condition-action paradigm, and (iii) the working group will investigate the practically of building policy rules that > declaratively specify what goals to achieve (this is often called "intent-based" policy) but not how to achieve those goals and > may create a model accordingly. > > If the working group finds it necessary to work on an information model before the data model, to help provide guidance and derive > the data models, it might do so. The working group will decide later whether the information model needs to be published as an RFC. > > Out of scope of this working group is: > > -The specification of a new policy language. The YANG data models are to be used with protocols such as NETCONF/RESTCONF. > > -Design of protocol-specific policies and specific design for embedded policies in network elements (which are usually interpreted > in isolation, and often at timescales that require optimization for specific purposes). > > -Specific handling of policies (although the application document will provide some examples), and therefore the specification of > a policy engine that maps a specific policy instance to actual configuration snippets. > > List of work items: > > 1) A document that explains the scope of the policy-based management framework and how it relates to existing work of the IETF. > > 2) If the working group considers it necessary, an information model composed of policy concepts and vocabulary. > > 3) A set of YANG data models consisting of a base policy model for representing policy management concepts independent of the type > or structure of a policy, plus an extension for defining policy rules according to the event-condition-action paradigm. Another > extension for defining policy rules according to a declarative, or intent-based, paradigm, may be produced. These models will be > designed to be generic and extensible. > > 4) An applicability document providing a few examples that demonstrate how the generic policy models can be used to express > policies that are relevant for network operators. The examples may tie into configuration models or network service models > developed by other working groups. > > The working group will decide how the work items are best mapped into deliverables. > > This working group will be a success when the SUPA policy constructs are re-used in future IETF specifications (and, ideally, > specifications from other SDOs), in a manner that will save development time and avoid inconsistencies between data models > developed by different working groups. In the meantime, SUPA should not impede work in other working groups while waiting for SUPA > to produce its deliverables. > > The working group will communicate with other SDOs (MEF, TMF, ETSI) that are working on related issues. > > Milestones: > > TBD > > > > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa From nobody Sun Aug 9 13:30:16 2015 Return-Path: X-Original-To: ibnemo@ietfa.amsl.com Delivered-To: ibnemo@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A87D1B2B61; Sun, 9 Aug 2015 13:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.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, HTML_MESSAGE=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 RUzLvCxX69z5; Sun, 9 Aug 2015 13:30:09 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (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 6D73A1B2B5E; Sun, 9 Aug 2015 13:30:09 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so58201601igb.0; Sun, 09 Aug 2015 13:30:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bd0WL6dnUKYfUzBmZKyJGWZnT+MKRvlDEnfTCtMgSmk=; b=MB/fItpT8Ugk4GrYrzz5lONane1Nb4P1zq62eoWcVz51i9ypSq3R+rXxVyMXi1rDj4 A3yv9LiDO4nqeRa2g7gQMn25WwvMIcwcrcjENZ+tu9Lg/Jy5dIRexRhIGip4aiWnEV/x Sh4DRpCvYnK+I30hTFC66kgMOc0vbH7bEWTDQU8K/bkcYPhwSzLwtlQMdEzwlsZ3OXPz kpnSuw4LbEJMiqb78nBRP90LjZ5ZKrvY9iHljSPRPB5DrTH3w4KCem7+RgbHqD5LEH5k ri+nVYbmgit2ZKfulbLDMyi5YaFfgJReMDimj0/PY+1aDMnhiZVXByjqVr1ecX4b7kjW 4zMA== MIME-Version: 1.0 X-Received: by 10.50.78.98 with SMTP id a2mr4468171igx.87.1439152208859; Sun, 09 Aug 2015 13:30:08 -0700 (PDT) Received: by 10.79.110.79 with HTTP; Sun, 9 Aug 2015 13:30:08 -0700 (PDT) In-Reply-To: <023101d0d2b7$54dad4e0$fe907ea0$@olddog.co.uk> References: <55C4D6C1.5040504@cisco.com> <55C4FCFE.8070701@bwijnen.net> <023101d0d2b7$54dad4e0$fe907ea0$@olddog.co.uk> Date: Sun, 9 Aug 2015 13:30:08 -0700 Message-ID: From: John Strassner To: adrian@olddog.co.uk Content-Type: multipart/alternative; boundary=089e0122edba2fda35051ce6bcc1 Archived-At: Cc: "Eggert, Lars" , ibnemo@ietf.org, "supa@ietf.org" Subject: Re: [Ibnemo] [Supa] SUPA charter proposal X-BeenThere: ibnemo@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of Nemo, an intent-based North Bound \(NB\) interface consisting of an application protocol running over HTTP \(RESTful interfaces\) to exchange intent-based primitives between applications and meta-controllers controlling virtual network resources \(networks, storage, CPU\)." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2015 20:30:13 -0000 --089e0122edba2fda35051ce6bcc1 Content-Type: text/plain; charset=UTF-8 Hi Adrian, I also do not think that there is any overlap between what SUPA has defined and what NEMO has defined. SUPA provides a common model for expressing imperative (e.g., event-condition-action, or ECA) and declarative (e.g., goal-based, or "intent") policies. SUPA proposes that each of these representations are realized as separate models, but are related through their "common ancestry" (i.e., they were both derived from the same superstructure). This means that each can use the other. In addition, there are distinct differences between SUPA and NEMO: 1) SUPA defines NETCONF or RESTCONF as its protocol. Period. In contrast, NEMO wants to define a new protocol. 2) SUPA defines intent as declarative logic, and thus implements it using either propositional or first order logic (see section 3.2.4., Mathematical Logic Terminology, of draft-strassner-supa-generic- policy-info-model). In contrast, NEMO defines implements its intent policy using condition-action (imperative) logic. 3) SUPA is NOT working on a language. In contrast, NEMO is working on a language. regards, John On Sun, Aug 9, 2015 at 8:23 AM, Adrian Farrel wrote: > Hi Bert, > > I don't think you are reading the proposed charter for SUPA right if you > think > it precludes the formation of a working group for IBNEMO. Rather, the text > that > Benoit has published says that SUPA is not the working group that works on > IBNEMO. > > But maybe you are saying that the intent-based part of the SUAP charter > could be > lifted out and placed in an IBNEMO work effort. That might be reasonable. > > However, there is a separation between the use of existing data modeling > and > protocols (such as YANG with NETCONF) and the development of a new and > specialised modeling language and communication protocol. I believe that > this > charter text opens up the investigation of the practicalities of > intent-based > policy modeling in order to determine whether such things could be modeled > in > existing languages or whether new work is needed a priori. > > If, for example, it was possible to encode intent-based policy in YANG, > that > would not preclude IBNEMO inventing something different/better/worse. > > Now there it seems sensible that SUPA should bundle all of the thought > around > policy models in one place as a starting point. If it is later desirable to > split off the intent-based part (say after the initial investigation and > information models) that doesn't seem like a bad thing. > > Alternatively, if there is a strong pull to move all of the intent-based > work > out from day one, I will not be complaining. > > Cheers, > Adrian > > > -----Original Message----- > > From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Bert Wijnen > (IETF) > > Sent: 07 August 2015 19:46 > > To: Benoit Claise; supa@ietf.org > > Cc: Eggert, Lars; ibnemo@ietf.org > > Subject: Re: [Supa] SUPA charter proposal > > > > Hi Benoit and others. > > > > So would this work prevent the formation of a WG that would do IBNEMO > (Intent > > Based NEtwork MOdeling) > > work? I certainly hope not. In the charter you have: > > > > (iii) the working group will investigate the practically of > building > policy rules > > that declaratively > > specify what goals to achieve (this is often called > "intent-based" policy) but > > not how to achieve > > those goals and may create a model accordingly. > > > > > > IBNEMO intends (no pun intended) to define/standardize a Intent > expression > > language. > > The work you describe above can be input to the work IBNEMO wants to do. > > > > Bert > > > > On 07/08/15 18:03, Benoit Claise wrote: > > > Dear all, > > > > > > As promised in my last email ("SUPA: Situation Summary and Next > Steps"), > here > > is a proposed charter. > > > Thanks to Robert Sparks, Adrian Farrel, and Dan Romascanu. > > > > > > Hopefully, this new version will clarify the situation, and will be > acceptable to > > everybody. > > > Please let us know. Note: I prefer to keep the edit token from now. > > > > > > Regards, Benoit (OPS AD) > > > > > > > > ============================================================== > > > > > > SUPA CHARTER PROPOSAL (2015-08-07) > > > > > > Policy is an important configurable component in the delivery of > services > and > > the operation of networks. Operators want and need > > > to be able to determine the policies that apply to their different > customers > and > > to the equipment that comprises their physical > > > and virtual networks. As policy spans such a wide range of services and > device > > types, it will be helpful if there is a common way > > > of expressing and describing policies that is uniform and consistent > in all > > environments. Such an approach will help to avoid > > > configuration errors that arise from confusion between different > systems, > will > > enable easy understanding of policies that apply in > > > different environments, will make the implementation of policy-based > systems > > quicker and cheaper, and will facilitate the rapid > > > development of standards-based data models that include policy > elements. > > > > > > SUPA (Simplified Use of Policy Abstractions) defines a model to > interface > with a > > network management function (within a controller, > > > an orchestrator, a network element) that takes high-level, possibly > network- > > wide policies as input. SUPA will not define what the > > > function does with that input but anticipates that it will ultimately > result > in > > network configuration changes > > > > > > Practically, SUPA will define generic YANG data models to encode > policy, > which > > can point to device-, technology-, and > > > service-specific YANG models of other working groups. > > > > > > SUPA will be designed to work with device, protocol, network, and > service > data > > models. > > > > > > The SUPA working group will develop a model for expressing policy at > different > > levels of abstraction.Specifically, three model > > > fragments are envisioned: (i) a generic model that defines concepts and > > vocabulary needed by policy management independent of the > > > form and content of the policy, (ii) a more specific model that > refines the > > generic model to specify how to build policy rules of > > > the event-condition-action paradigm, and (iii) the working group will > investigate > > the practically of building policy rules that > > > declaratively specify what goals to achieve (this is often called > "intent-based" > > policy) but not how to achieve those goals and > > > may create a model accordingly. > > > > > > If the working group finds it necessary to work on an information model > before > > the data model, to help provide guidance and derive > > > the data models, it might do so. The working group will decide later > whether > > the information model needs to be published as an RFC. > > > > > > Out of scope of this working group is: > > > > > > -The specification of a new policy language. The YANG data models are > to be > > used with protocols such as NETCONF/RESTCONF. > > > > > > -Design of protocol-specific policies and specific design for embedded > policies in > > network elements (which are usually interpreted > > > in isolation, and often at timescales that require optimization for > specific > > purposes). > > > > > > -Specific handling of policies (although the application document will > provide > > some examples), and therefore the specification of > > > a policy engine that maps a specific policy instance to actual > configuration > > snippets. > > > > > > List of work items: > > > > > > 1) A document that explains the scope of the policy-based management > > framework and how it relates to existing work of the IETF. > > > > > > 2) If the working group considers it necessary, an information model > composed > > of policy concepts and vocabulary. > > > > > > 3) A set of YANG data models consisting of a base policy model for > representing > > policy management concepts independent of the type > > > or structure of a policy, plus an extension for defining policy rules > according to > > the event-condition-action paradigm. Another > > > extension for defining policy rules according to a declarative, or > intent-based, > > paradigm, may be produced. These models will be > > > designed to be generic and extensible. > > > > > > 4) An applicability document providing a few examples that demonstrate > how > > the generic policy models can be used to express > > > policies that are relevant for network operators. The examples may tie > into > > configuration models or network service models > > > developed by other working groups. > > > > > > The working group will decide how the work items are best mapped into > > deliverables. > > > > > > This working group will be a success when the SUPA policy constructs > are re- > > used in future IETF specifications (and, ideally, > > > specifications from other SDOs), in a manner that will save > development time > > and avoid inconsistencies between data models > > > developed by different working groups. In the meantime, SUPA should not > > impede work in other working groups while waiting for SUPA > > > to produce its deliverables. > > > > > > The working group will communicate with other SDOs (MEF, TMF, ETSI) > that are > > working on related issues. > > > > > > Milestones: > > > > > > TBD > > > > > > > > > > > > > > > _______________________________________________ > > > Supa mailing list > > > Supa@ietf.org > > > https://www.ietf.org/mailman/listinfo/supa > > > > _______________________________________________ > > Supa mailing list > > Supa@ietf.org > > https://www.ietf.org/mailman/listinfo/supa > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > -- regards, John --089e0122edba2fda35051ce6bcc1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Adrian,

I also do not thi= nk that there is any overlap between what SUPA has defined
and wh= at NEMO has defined. SUPA provides a common model for
expressing = imperative (e.g., event-condition-action, or ECA) and declarative
(e.g., goal-based, or "intent") policies. SUPA proposes that eac= h of these
representations are realized as separate models, but a= re related through
their "common ancestry" (i.e., they = were both derived from the same
superstructure). This means that = each can use the other.

In addition, there are dis= tinct differences between SUPA and NEMO:

=C2=A0 1)= SUPA defines NETCONF or RESTCONF as its protocol. Period. In
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 contrast, NEMO wants to define a new protocol.<= /div>
=C2=A0 2) SUPA defines intent as declarative logic, and thus impl= ements it
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 using either proposition= al or first order logic (see section 3.2.4.,
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Mathematical Logic Terminology, of draft-strassner-supa-generi= c-
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 policy-info-model). In contrast= , NEMO defines implements its
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inte= nt policy using condition-action (imperative) logic.
=C2=A03) SUP= A is NOT working on a language. In contrast, NEMO is working
=C2= =A0=C2=A0=C2=A0=C2=A0 on a language.
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0

regards,
John

On Sun, Aug 9, 2015 at 8:23= AM, Adrian Farrel <adrian@olddog.co.uk> wrote:
Hi Bert,

I don't think you are reading the proposed charter for SUPA right if yo= u think
it precludes the formation of a working group for IBNEMO. Rather, the text = that
Benoit has published says that SUPA is not the working group that works on<= br> IBNEMO.

But maybe you are saying that the intent-based part of the SUAP charter cou= ld be
lifted out and placed in an IBNEMO work effort. That might be reasonable.
However, there is a separation between the use of existing data modeling an= d
protocols (such as YANG with NETCONF) and the development of a new and
specialised modeling language and communication protocol. I believe that th= is
charter text opens up the investigation of the practicalities of intent-bas= ed
policy modeling in order to determine whether such things could be modeled = in
existing languages or whether new work is needed a priori.

If, for example, it was possible to encode intent-based policy in YANG, tha= t
would not preclude IBNEMO inventing something different/better/worse.

Now there it seems sensible that SUPA should bundle all of the thought arou= nd
policy models in one place as a starting point. If it is later desirable to=
split off the intent-based part (say after the initial investigation and information models) that doesn't seem like a bad thing.

Alternatively, if there is a strong pull to move all of the intent-based wo= rk
out from day one, I will not be complaining.

Cheers,
Adrian

> -----Original Message-----
> From: Supa [mailto:supa-bounc= es@ietf.org] On Behalf Of Bert Wijnen (IETF)
> Sent: 07 August 2015 19:46
> To: Benoit Claise; supa@ietf.org<= br> > Cc: Eggert, Lars; ibnemo@ietf.org
> Subject: Re: [Supa] SUPA charter proposal
>
> Hi Benoit and others.
>
> So would this work prevent the formation of a WG that would do IBNEMO = (Intent
> Based NEtwork MOdeling)
> work? I certainly hope not. In the charter you have:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 (iii) the working group will investigate th= e practically of building
policy rules
> that declaratively
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 specify what goals to = achieve (this is often called
"intent-based" policy) but
> not how to achieve
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 those goals and may cr= eate a model accordingly.
>
>
> IBNEMO intends (no pun intended) to define/standardize a Intent expres= sion
> language.
> The work you describe above can be input to the work IBNEMO wants to d= o.
>
> Bert
>
> On 07/08/15 18:03, Benoit Claise wrote:
> > Dear all,
> >
> > As promised in my last email ("SUPA: Situation Summary and N= ext Steps"),
here
> is a proposed charter.
> > Thanks to Robert Sparks, Adrian Farrel, and Dan Romascanu.
> >
> > Hopefully, this new version will clarify the situation, and will = be
acceptable to
> everybody.
> > Please let us know. Note: I prefer to keep the edit token from no= w.
> >
> > Regards, Benoit (OPS AD)
> >
> >
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >
> > SUPA CHARTER PROPOSAL (2015-08-07)
> >
> > Policy is an important configurable component in the delivery of = services
and
> the operation of networks. Operators want and need
> > to be able to determine the policies that apply to their differen= t customers
and
> to the equipment that comprises their physical
> > and virtual networks. As policy spans such a wide range of servic= es and
device
> types, it will be helpful if there is a common way
> > of expressing and describing policies that is uniform and consist= ent in all
> environments. Such an approach will help to avoid
> > configuration errors that arise from confusion between different = systems,
will
> enable easy understanding of policies that apply in
> > different environments, will make the implementation of policy-ba= sed systems
> quicker and cheaper, and will facilitate the rapid
> > development of standards-based data models that include policy el= ements.
> >
> > SUPA (Simplified Use of Policy Abstractions) defines a model to i= nterface
with a
> network management function (within a controller,
> > an orchestrator, a network element) that takes high-level, possib= ly network-
> wide policies as input. SUPA will not define what the
> > function does with that input but anticipates that it will ultima= tely result
in
> network configuration changes
> >
> > Practically, SUPA will define generic YANG data models to encode = policy,
which
> can point to device-, technology-, and
> > service-specific YANG models of other working groups.
> >
> > SUPA will be designed to work with device, protocol, network, and= service
data
> models.
> >
> > The SUPA working group will develop a model for expressing policy= at
different
> levels of abstraction.Specifically, three model
> > fragments are envisioned: (i) a generic model that defines concep= ts and
> vocabulary needed by policy management independent of the
> > form and content of the policy, (ii) a more specific model that r= efines the
> generic model to specify how to build policy rules of
> > the event-condition-action paradigm, and (iii) the working group = will
investigate
> the practically of building policy rules that
> > declaratively specify what goals to achieve (this is often called=
"intent-based"
> policy) but not how to achieve those goals and
> > may create a model accordingly.
> >
> > If the working group finds it necessary to work on an information= model
before
> the data model, to help provide guidance and derive
> > the data models, it might do so. The working group will decide la= ter whether
> the information model needs to be published as an RFC.
> >
> > Out of scope of this working group is:
> >
> > -The specification of a new policy language. The YANG data models= are to be
> used with protocols such as NETCONF/RESTCONF.
> >
> > -Design of protocol-specific policies and specific design for emb= edded
policies in
> network elements (which are usually interpreted
> > in isolation, and often at timescales that require optimization f= or specific
> purposes).
> >
> > -Specific handling of policies (although the application document= will
provide
> some examples), and therefore the specification of
> > a policy engine that maps a specific policy instance to actual co= nfiguration
> snippets.
> >
> > List of work items:
> >
> > 1) A document that explains the scope of the policy-based managem= ent
> framework and how it relates to existing work of the IETF.
> >
> > 2) If the working group considers it necessary, an information mo= del
composed
> of policy concepts and vocabulary.
> >
> > 3) A set of YANG data models consisting of a base policy model fo= r
representing
> policy management concepts independent of the type
> > or structure of a policy, plus an extension for defining policy r= ules
according to
> the event-condition-action paradigm. Another
> > extension for defining policy rules according to a declarative, o= r
intent-based,
> paradigm, may be produced. These models will be
> > designed to be generic and extensible.
> >
> > 4) An applicability document providing a few examples that demons= trate how
> the generic policy models can be used to express
> > policies that are relevant for network operators. The examples ma= y tie into
> configuration models or network service models
> > developed by other working groups.
> >
> > The working group will decide how the work items are best mapped = into
> deliverables.
> >
> > This working group will be a success when the SUPA policy constru= cts are re-
> used in future IETF specifications (and, ideally,
> > specifications from other SDOs), in a manner that will save devel= opment time
> and avoid inconsistencies between data models
> > developed by different working groups. In the meantime, SUPA shou= ld not
> impede work in other working groups while waiting for SUPA
> > to produce its deliverables.
> >
> > The working group will communicate with other SDOs (MEF, TMF, ETS= I) that are
> working on related issues.
> >
> > Milestones:
> >
> > TBD
> >
> >
> >
> >
> > _______________________________________________
> > Supa mailing list
> > Supa@ietf.org
> > https://www.ietf.org/mailman/listinfo/supa >
> _______________________________________________
> Supa mailing list
> Supa@ietf.org
> https://www.ietf.org/mailman/listinfo/supa

_______________________________________________
Supa mailing list
Supa@ietf.org
https://www.ietf.org/mailman/listinfo/supa



--
regards,
John
--089e0122edba2fda35051ce6bcc1-- From nobody Sun Aug 9 13:42:41 2015 Return-Path: X-Original-To: ibnemo@ietfa.amsl.com Delivered-To: ibnemo@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C3F1B2F2E; Sun, 9 Aug 2015 13:42:38 -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 R7_1f9Mfm20g; Sun, 9 Aug 2015 13:42:35 -0700 (PDT) Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80E971B2F24; Sun, 9 Aug 2015 13:42:33 -0700 (PDT) Received: from Macintosh.fritz.box ([83.163.239.181]) by smtp-cloud6.xs4all.net with ESMTP id 2kiS1r00R3vXPcr01kiU5w; Sun, 09 Aug 2015 22:42:31 +0200 Message-ID: <55C7BB32.30504@bwijnen.net> Date: Sun, 09 Aug 2015 22:42:26 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, 'Benoit Claise' , supa@ietf.org References: <55C4D6C1.5040504@cisco.com> <55C4FCFE.8070701@bwijnen.net> <023101d0d2b7$54dad4e0$fe907ea0$@olddog.co.uk> In-Reply-To: <023101d0d2b7$54dad4e0$fe907ea0$@olddog.co.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "'Eggert, Lars'" , ibnemo@ietf.org Subject: Re: [Ibnemo] [Supa] SUPA charter proposal X-BeenThere: ibnemo@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of Nemo, an intent-based North Bound \(NB\) interface consisting of an application protocol running over HTTP \(RESTful interfaces\) to exchange intent-based primitives between applications and meta-controllers controlling virtual network resources \(networks, storage, CPU\)." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2015 20:42:38 -0000 Hi Adrian, inline On 09/08/15 17:23, Adrian Farrel wrote: > Hi Bert, > > I don't think you are reading the proposed charter for SUPA right if you think > it precludes the formation of a working group for IBNEMO. Rather, the text that > Benoit has published says that SUPA is not the working group that works on > IBNEMO. OK, that was certainly not so clear to me. Thanks for clarifying this. I am still abit worried about the text: (iii) the working group will investigate the practically of building policy rules that declaratively specify what goals to achieve (this is often called "intent-based" policy) but not how to achieve those goals and may create a model accordingly. So what does that last piece of the sentence "and may create a model accordingly" mean then? > But maybe you are saying that the intent-based part of the SUAP charter could be > lifted out and placed in an IBNEMO work effort. That might be reasonable. I think that makes sense to me too. But maybe we need more discussion on this. In fact, Intent Based Network Modeling has already quite some traction (including code) in Open Daylight projects. So they are quite active already in that space. Standardizing a language to express intent seems something that a WG in IETF could very well work on, actually pretty soon. AS we discussued in our barbof in Prague. > However, there is a separation between the use of existing data modeling and > protocols (such as YANG with NETCONF) and the development of a new and > specialised modeling language and communication protocol. I believe that this > charter text opens up the investigation of the practicalities of intent-based > policy modeling in order to determine whether such things could be modeled in > existing languages or whether new work is needed a priori. In fact, in IBNEMO we realize that we need to use (or define maybe) some YANG data models that would allow us to translate "intent expressions" into actual network-wide, conroller-wide or device-specific data models. We would use any existing data models if at laa possibl. But we do need some data models in order to prove that our expression language can work and be implemented in interoperable code. > > If, for example, it was possible to encode intent-based policy in YANG, that > would not preclude IBNEMO inventing something different/better/worse. RIght, but my personal preference would be to try and see if we can use existing YANG data models > Now there it seems sensible that SUPA should bundle all of the thought around > policy models in one place as a starting point. If it is later desirable to > split off the intent-based part (say after the initial investigation and > information models) that doesn't seem like a bad thing. Could be I guess > Alternatively, if there is a strong pull to move all of the intent-based work > out from day one, I will not be complaining. And I think some of that work has already started, although still at an indiviadual-draft level. Bert > Cheers, > Adrian > >> -----Original Message----- >> From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Bert Wijnen (IETF) >> Sent: 07 August 2015 19:46 >> To: Benoit Claise; supa@ietf.org >> Cc: Eggert, Lars; ibnemo@ietf.org >> Subject: Re: [Supa] SUPA charter proposal >> >> Hi Benoit and others. >> >> So would this work prevent the formation of a WG that would do IBNEMO (Intent >> Based NEtwork MOdeling) >> work? I certainly hope not. In the charter you have: >> >> (iii) the working group will investigate the practically of building > policy rules >> that declaratively >> specify what goals to achieve (this is often called > "intent-based" policy) but >> not how to achieve >> those goals and may create a model accordingly. >> >> >> IBNEMO intends (no pun intended) to define/standardize a Intent expression >> language. >> The work you describe above can be input to the work IBNEMO wants to do. >> >> Bert >> >> On 07/08/15 18:03, Benoit Claise wrote: >>> Dear all, >>> >>> As promised in my last email ("SUPA: Situation Summary and Next Steps"), > here >> is a proposed charter. >>> Thanks to Robert Sparks, Adrian Farrel, and Dan Romascanu. >>> >>> Hopefully, this new version will clarify the situation, and will be > acceptable to >> everybody. >>> Please let us know. Note: I prefer to keep the edit token from now. >>> >>> Regards, Benoit (OPS AD) >>> >>> >> ============================================================== >>> SUPA CHARTER PROPOSAL (2015-08-07) >>> >>> Policy is an important configurable component in the delivery of services > and >> the operation of networks. Operators want and need >>> to be able to determine the policies that apply to their different customers > and >> to the equipment that comprises their physical >>> and virtual networks. As policy spans such a wide range of services and > device >> types, it will be helpful if there is a common way >>> of expressing and describing policies that is uniform and consistent in all >> environments. Such an approach will help to avoid >>> configuration errors that arise from confusion between different systems, > will >> enable easy understanding of policies that apply in >>> different environments, will make the implementation of policy-based systems >> quicker and cheaper, and will facilitate the rapid >>> development of standards-based data models that include policy elements. >>> >>> SUPA (Simplified Use of Policy Abstractions) defines a model to interface > with a >> network management function (within a controller, >>> an orchestrator, a network element) that takes high-level, possibly network- >> wide policies as input. SUPA will not define what the >>> function does with that input but anticipates that it will ultimately result > in >> network configuration changes >>> Practically, SUPA will define generic YANG data models to encode policy, > which >> can point to device-, technology-, and >>> service-specific YANG models of other working groups. >>> >>> SUPA will be designed to work with device, protocol, network, and service > data >> models. >>> The SUPA working group will develop a model for expressing policy at > different >> levels of abstraction.Specifically, three model >>> fragments are envisioned: (i) a generic model that defines concepts and >> vocabulary needed by policy management independent of the >>> form and content of the policy, (ii) a more specific model that refines the >> generic model to specify how to build policy rules of >>> the event-condition-action paradigm, and (iii) the working group will > investigate >> the practically of building policy rules that >>> declaratively specify what goals to achieve (this is often called > "intent-based" >> policy) but not how to achieve those goals and >>> may create a model accordingly. >>> >>> If the working group finds it necessary to work on an information model > before >> the data model, to help provide guidance and derive >>> the data models, it might do so. The working group will decide later whether >> the information model needs to be published as an RFC. >>> Out of scope of this working group is: >>> >>> -The specification of a new policy language. The YANG data models are to be >> used with protocols such as NETCONF/RESTCONF. >>> -Design of protocol-specific policies and specific design for embedded > policies in >> network elements (which are usually interpreted >>> in isolation, and often at timescales that require optimization for specific >> purposes). >>> -Specific handling of policies (although the application document will > provide >> some examples), and therefore the specification of >>> a policy engine that maps a specific policy instance to actual configuration >> snippets. >>> List of work items: >>> >>> 1) A document that explains the scope of the policy-based management >> framework and how it relates to existing work of the IETF. >>> 2) If the working group considers it necessary, an information model > composed >> of policy concepts and vocabulary. >>> 3) A set of YANG data models consisting of a base policy model for > representing >> policy management concepts independent of the type >>> or structure of a policy, plus an extension for defining policy rules > according to >> the event-condition-action paradigm. Another >>> extension for defining policy rules according to a declarative, or > intent-based, >> paradigm, may be produced. These models will be >>> designed to be generic and extensible. >>> >>> 4) An applicability document providing a few examples that demonstrate how >> the generic policy models can be used to express >>> policies that are relevant for network operators. The examples may tie into >> configuration models or network service models >>> developed by other working groups. >>> >>> The working group will decide how the work items are best mapped into >> deliverables. >>> This working group will be a success when the SUPA policy constructs are re- >> used in future IETF specifications (and, ideally, >>> specifications from other SDOs), in a manner that will save development time >> and avoid inconsistencies between data models >>> developed by different working groups. In the meantime, SUPA should not >> impede work in other working groups while waiting for SUPA >>> to produce its deliverables. >>> >>> The working group will communicate with other SDOs (MEF, TMF, ETSI) that are >> working on related issues. >>> Milestones: >>> >>> TBD >>> >>> >>> >>> >>> _______________________________________________ >>> Supa mailing list >>> Supa@ietf.org >>> https://www.ietf.org/mailman/listinfo/supa >> _______________________________________________ >> Supa mailing list >> Supa@ietf.org >> https://www.ietf.org/mailman/listinfo/supa > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > From nobody Sun Aug 9 14:24:00 2015 Return-Path: X-Original-To: ibnemo@ietfa.amsl.com Delivered-To: ibnemo@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5924B1A0419; Sun, 9 Aug 2015 14:23:58 -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 wwWUphPHl_t8; Sun, 9 Aug 2015 14:23:55 -0700 (PDT) Received: from lb2-smtp-cloud6.xs4all.net (lb2-smtp-cloud6.xs4all.net [194.109.24.28]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E76A81A03A6; Sun, 9 Aug 2015 14:23:54 -0700 (PDT) Received: from Macintosh.fritz.box ([83.163.239.181]) by smtp-cloud6.xs4all.net with ESMTP id 2lPq1r00A3vXPcr01lPr98; Sun, 09 Aug 2015 23:23:53 +0200 Message-ID: <55C7C4E6.9020003@bwijnen.net> Date: Sun, 09 Aug 2015 23:23:50 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: John Strassner , adrian@olddog.co.uk References: <55C4D6C1.5040504@cisco.com> <55C4FCFE.8070701@bwijnen.net> <023101d0d2b7$54dad4e0$fe907ea0$@olddog.co.uk> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "Eggert, Lars" , ibnemo@ietf.org, "supa@ietf.org" Subject: Re: [Ibnemo] [Supa] SUPA charter proposal X-BeenThere: ibnemo@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of Nemo, an intent-based North Bound \(NB\) interface consisting of an application protocol running over HTTP \(RESTful interfaces\) to exchange intent-based primitives between applications and meta-controllers controlling virtual network resources \(networks, storage, CPU\)." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2015 21:23:58 -0000 John, Inline, On 09/08/15 22:30, John Strassner wrote: > Hi Adrian, > > I also do not think that there is any overlap between what SUPA has defined > and what NEMO has defined. SUPA provides a common model for > expressing imperative (e.g., event-condition-action, or ECA) and declarative > (e.g., goal-based, or "intent") policies. SUPA proposes that each of these > representations are realized as separate models, but are related through > their "common ancestry" (i.e., they were both derived from the same > superstructure). This means that each can use the other. > OK, that sounds good to me. > In addition, there are distinct differences between SUPA and NEMO: > > 1) SUPA defines NETCONF or RESTCONF as its protocol. Period. In > contrast, NEMO wants to define a new protocol. I do not know what makes you say so. I think we have left it open sofar as to whether we want/need a new protocol or not. Preferably we can use Netconf/Restconf. But I think that is all still open to discussion. > 2) SUPA defines intent as declarative logic, and thus implements it > using either propositional or first order logic (see section 3.2.4., > Mathematical Logic Terminology, of draft-strassner-supa-generic- > policy-info-model). In contrast, NEMO defines implements its > intent policy using condition-action (imperative) logic. Again I do not understand why you think so. I have not seen any ECA stuff in IBNEMO yet. But then, maybe you can point me to it if you have. > 3) SUPA is NOT working on a language. In contrast, NEMO is working > on a language. Yep, we would like to work on an "intent expression language" in IBNEMO. Bert > > regards, > John > > On Sun, Aug 9, 2015 at 8:23 AM, Adrian Farrel > wrote: > > Hi Bert, > > I don't think you are reading the proposed charter for SUPA right if you think > it precludes the formation of a working group for IBNEMO. Rather, the text that > Benoit has published says that SUPA is not the working group that works on > IBNEMO. > > But maybe you are saying that the intent-based part of the SUAP charter could be > lifted out and placed in an IBNEMO work effort. That might be reasonable. > > However, there is a separation between the use of existing data modeling and > protocols (such as YANG with NETCONF) and the development of a new and > specialised modeling language and communication protocol. I believe that this > charter text opens up the investigation of the practicalities of intent-based > policy modeling in order to determine whether such things could be modeled in > existing languages or whether new work is needed a priori. > > If, for example, it was possible to encode intent-based policy in YANG, that > would not preclude IBNEMO inventing something different/better/worse. > > Now there it seems sensible that SUPA should bundle all of the thought around > policy models in one place as a starting point. If it is later desirable to > split off the intent-based part (say after the initial investigation and > information models) that doesn't seem like a bad thing. > > Alternatively, if there is a strong pull to move all of the intent-based work > out from day one, I will not be complaining. > > Cheers, > Adrian > > > -----Original Message----- > > From: Supa [mailto:supa-bounces@ietf.org ] On Behalf Of Bert Wijnen (IETF) > > Sent: 07 August 2015 19:46 > > To: Benoit Claise; supa@ietf.org > > Cc: Eggert, Lars; ibnemo@ietf.org > > Subject: Re: [Supa] SUPA charter proposal > > > > Hi Benoit and others. > > > > So would this work prevent the formation of a WG that would do IBNEMO (Intent > > Based NEtwork MOdeling) > > work? I certainly hope not. In the charter you have: > > > > (iii) the working group will investigate the practically of building > policy rules > > that declaratively > > specify what goals to achieve (this is often called > "intent-based" policy) but > > not how to achieve > > those goals and may create a model accordingly. > > > > > > IBNEMO intends (no pun intended) to define/standardize a Intent expression > > language. > > The work you describe above can be input to the work IBNEMO wants to do. > > > > Bert > > > > On 07/08/15 18:03, Benoit Claise wrote: > > > Dear all, > > > > > > As promised in my last email ("SUPA: Situation Summary and Next Steps"), > here > > is a proposed charter. > > > Thanks to Robert Sparks, Adrian Farrel, and Dan Romascanu. > > > > > > Hopefully, this new version will clarify the situation, and will be > acceptable to > > everybody. > > > Please let us know. Note: I prefer to keep the edit token from now. > > > > > > Regards, Benoit (OPS AD) > > > > > > > > ============================================================== > > > > > > SUPA CHARTER PROPOSAL (2015-08-07) > > > > > > Policy is an important configurable component in the delivery of services > and > > the operation of networks. Operators want and need > > > to be able to determine the policies that apply to their different customers > and > > to the equipment that comprises their physical > > > and virtual networks. As policy spans such a wide range of services and > device > > types, it will be helpful if there is a common way > > > of expressing and describing policies that is uniform and consistent in all > > environments. Such an approach will help to avoid > > > configuration errors that arise from confusion between different systems, > will > > enable easy understanding of policies that apply in > > > different environments, will make the implementation of policy-based systems > > quicker and cheaper, and will facilitate the rapid > > > development of standards-based data models that include policy elements. > > > > > > SUPA (Simplified Use of Policy Abstractions) defines a model to interface > with a > > network management function (within a controller, > > > an orchestrator, a network element) that takes high-level, possibly network- > > wide policies as input. SUPA will not define what the > > > function does with that input but anticipates that it will ultimately result > in > > network configuration changes > > > > > > Practically, SUPA will define generic YANG data models to encode policy, > which > > can point to device-, technology-, and > > > service-specific YANG models of other working groups. > > > > > > SUPA will be designed to work with device, protocol, network, and service > data > > models. > > > > > > The SUPA working group will develop a model for expressing policy at > different > > levels of abstraction.Specifically, three model > > > fragments are envisioned: (i) a generic model that defines concepts and > > vocabulary needed by policy management independent of the > > > form and content of the policy, (ii) a more specific model that refines the > > generic model to specify how to build policy rules of > > > the event-condition-action paradigm, and (iii) the working group will > investigate > > the practically of building policy rules that > > > declaratively specify what goals to achieve (this is often called > "intent-based" > > policy) but not how to achieve those goals and > > > may create a model accordingly. > > > > > > If the working group finds it necessary to work on an information model > before > > the data model, to help provide guidance and derive > > > the data models, it might do so. The working group will decide later whether > > the information model needs to be published as an RFC. > > > > > > Out of scope of this working group is: > > > > > > -The specification of a new policy language. The YANG data models are to be > > used with protocols such as NETCONF/RESTCONF. > > > > > > -Design of protocol-specific policies and specific design for embedded > policies in > > network elements (which are usually interpreted > > > in isolation, and often at timescales that require optimization for specific > > purposes). > > > > > > -Specific handling of policies (although the application document will > provide > > some examples), and therefore the specification of > > > a policy engine that maps a specific policy instance to actual configuration > > snippets. > > > > > > List of work items: > > > > > > 1) A document that explains the scope of the policy-based management > > framework and how it relates to existing work of the IETF. > > > > > > 2) If the working group considers it necessary, an information model > composed > > of policy concepts and vocabulary. > > > > > > 3) A set of YANG data models consisting of a base policy model for > representing > > policy management concepts independent of the type > > > or structure of a policy, plus an extension for defining policy rules > according to > > the event-condition-action paradigm. Another > > > extension for defining policy rules according to a declarative, or > intent-based, > > paradigm, may be produced. These models will be > > > designed to be generic and extensible. > > > > > > 4) An applicability document providing a few examples that demonstrate how > > the generic policy models can be used to express > > > policies that are relevant for network operators. The examples may tie into > > configuration models or network service models > > > developed by other working groups. > > > > > > The working group will decide how the work items are best mapped into > > deliverables. > > > > > > This working group will be a success when the SUPA policy constructs are re- > > used in future IETF specifications (and, ideally, > > > specifications from other SDOs), in a manner that will save development time > > and avoid inconsistencies between data models > > > developed by different working groups. In the meantime, SUPA should not > > impede work in other working groups while waiting for SUPA > > > to produce its deliverables. > > > > > > The working group will communicate with other SDOs (MEF, TMF, ETSI) that are > > working on related issues. > > > > > > Milestones: > > > > > > TBD > > > > > > > > > > > > > > > _______________________________________________ > > > Supa mailing list > > > Supa@ietf.org > > > https://www.ietf.org/mailman/listinfo/supa > > > > _______________________________________________ > > Supa mailing list > > Supa@ietf.org > > https://www.ietf.org/mailman/listinfo/supa > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > > > > > -- > regards, > John > > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa From nobody Sun Aug 9 14:59:29 2015 Return-Path: X-Original-To: ibnemo@ietfa.amsl.com Delivered-To: ibnemo@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F9C1A6F3C; Sun, 9 Aug 2015 14:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.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, HTML_MESSAGE=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 hYFPhIpR7cEn; Sun, 9 Aug 2015 14:59:22 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001: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 2899C1A6F3B; Sun, 9 Aug 2015 14:59:22 -0700 (PDT) Received: by igr7 with SMTP id 7so59107338igr.0; Sun, 09 Aug 2015 14:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=n03qoiWj0UZ9rlkZKvg8pM80YlW16XVxUBg9Y2QnU70=; b=0X9vDL4A1KLS9T+1KYwX5DwPn4qvt8TdcxAVhQCp5Nn+JjV75vP7L8Kbci+gVC8QRp u+DBEji02m8FxJGclPUCJeuq+4tX6UrUeArmd/XgzT8doxosINqCfadiEC7tipKta1Hn q8eWkDPYfpaRshfNdpn7SR4E/SqQ+PuvAI1OMn5F9RFpv5McO1hkSSgggIcEH5sd7Xdc PaBkyDUNE4GjG6oB1zp8435Iji7Qbuzebay8jUgh9GX+LAzbAsuK6smmWlVNJj1jKt/t XkvRxqLfViUTzTQG8I5pzyKvQMOVVPjkl77K0QHgTRKZboWt+d6p1ByzVL/8t/lbqP9r xsOw== MIME-Version: 1.0 X-Received: by 10.50.70.34 with SMTP id j2mr9007886igu.54.1439157561551; Sun, 09 Aug 2015 14:59:21 -0700 (PDT) Received: by 10.79.110.79 with HTTP; Sun, 9 Aug 2015 14:59:21 -0700 (PDT) In-Reply-To: <55C7C4E6.9020003@bwijnen.net> References: <55C4D6C1.5040504@cisco.com> <55C4FCFE.8070701@bwijnen.net> <023101d0d2b7$54dad4e0$fe907ea0$@olddog.co.uk> <55C7C4E6.9020003@bwijnen.net> Date: Sun, 9 Aug 2015 14:59:21 -0700 Message-ID: From: John Strassner To: "Bert Wijnen (IETF)" Content-Type: multipart/alternative; boundary=047d7b3a9be63b722c051ce7fbdc Archived-At: Cc: Adrian Farrel , "Eggert, Lars" , ibnemo@ietf.org, "supa@ietf.org" Subject: Re: [Ibnemo] [Supa] SUPA charter proposal X-BeenThere: ibnemo@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of Nemo, an intent-based North Bound \(NB\) interface consisting of an application protocol running over HTTP \(RESTful interfaces\) to exchange intent-based primitives between applications and meta-controllers controlling virtual network resources \(networks, storage, CPU\)." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2015 21:59:27 -0000 --047d7b3a9be63b722c051ce7fbdc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bert, please see inline. In addition, there are distinct differences between SUPA and NEMO: >> 1) SUPA defines NETCONF or RESTCONF as its protocol. Period. >> In contrast, NEMO wants to define a new protocol. > I do not know what makes you say so. > I think we have left it open sofar as to whether we want/need a new > protocol or not. > Preferably we can use Netconf/Restconf. But I think that is all still > open to discussion. What makes me say so is a combination of 1) listening to previous NEMO presentations in other fora 2) various sentences in the IBNEMO Bar BoF presentation (e.g., "Question: scripts over http workable, Not sure RESTCONF rpc + pub.sub level needed", 3) Statements such as "Synergistic means that sum of Intent Based NEMO protocol + NETCONF + RESTCONF + I2RS +PCE is more than any of the parts alone" and "creating protocol with minimal operations for to express intent from the application to the network"= . both from draft-hares-ibnemo-overview-01 4) a mail from Sue on 7/17 to the NEMO and SUPA lists, that said "IBNemo=E2=80=99s 15 specific commands are better than NETCONF or RESTCONF commands" I can give you many more examples... >> 2) SUPA defines intent as declarative logic, and thus implements >> it using either propositional or first order logic (see section 3.2.4., >> Mathematical Logic Terminology, of draft-strassner-supa-generic- >> policy-info-model). In contrast, NEMO defines implements its >> intent policy using condition-action (imperative) logic. > Again I do not understand why you think so. > I have not seen any ECA stuff in IBNEMO yet. > But then, maybe you can point me to it if you have. I said "condition-action", NOT ECA. Please look at draft-xia-sdnrg-nemo-language-02, which says: "All the policies follow the same pattern "when , to execute , with ", and can be applied to any entity." On Sun, Aug 9, 2015 at 2:23 PM, Bert Wijnen (IETF) wrote: > John, Inline, > > On 09/08/15 22:30, John Strassner wrote: > >> Hi Adrian, >> >> I also do not think that there is any overlap between what SUPA has >> defined >> and what NEMO has defined. SUPA provides a common model for >> expressing imperative (e.g., event-condition-action, or ECA) and >> declarative >> (e.g., goal-based, or "intent") policies. SUPA proposes that each of the= se >> representations are realized as separate models, but are related through >> their "common ancestry" (i.e., they were both derived from the same >> superstructure). This means that each can use the other. >> >> OK, that sounds good to me. > > In addition, there are distinct differences between SUPA and NEMO: >> >> 1) SUPA defines NETCONF or RESTCONF as its protocol. Period. In >> contrast, NEMO wants to define a new protocol. >> > I do not know what makes you say so. > I think we have left it open sofar as to whether we want/need a new > protocol or not. > Preferably we can use Netconf/Restconf. But I think that is all still ope= n > to discussion. > >> 2) SUPA defines intent as declarative logic, and thus implements it >> using either propositional or first order logic (see section 3.2.4= ., >> Mathematical Logic Terminology, of draft-strassner-supa-generic- >> policy-info-model). In contrast, NEMO defines implements its >> intent policy using condition-action (imperative) logic. >> > Again I do not understand why you think so. > I have not seen any ECA stuff in IBNEMO yet. > But then, maybe you can point me to it if you have. > >> 3) SUPA is NOT working on a language. In contrast, NEMO is working >> on a language. >> > Yep, we would like to work on an "intent expression language" in IBNEMO. > > Bert > >> >> regards, >> John >> >> On Sun, Aug 9, 2015 at 8:23 AM, Adrian Farrel > > wrote: >> >> Hi Bert, >> >> I don't think you are reading the proposed charter for SUPA right if >> you think >> it precludes the formation of a working group for IBNEMO. Rather, th= e >> text that >> Benoit has published says that SUPA is not the working group that >> works on >> IBNEMO. >> >> But maybe you are saying that the intent-based part of the SUAP >> charter could be >> lifted out and placed in an IBNEMO work effort. That might be >> reasonable. >> >> However, there is a separation between the use of existing data >> modeling and >> protocols (such as YANG with NETCONF) and the development of a new a= nd >> specialised modeling language and communication protocol. I believe >> that this >> charter text opens up the investigation of the practicalities of >> intent-based >> policy modeling in order to determine whether such things could be >> modeled in >> existing languages or whether new work is needed a priori. >> >> If, for example, it was possible to encode intent-based policy in >> YANG, that >> would not preclude IBNEMO inventing something different/better/worse= . >> >> Now there it seems sensible that SUPA should bundle all of the >> thought around >> policy models in one place as a starting point. If it is later >> desirable to >> split off the intent-based part (say after the initial investigation >> and >> information models) that doesn't seem like a bad thing. >> >> Alternatively, if there is a strong pull to move all of the >> intent-based work >> out from day one, I will not be complaining. >> >> Cheers, >> Adrian >> >> > -----Original Message----- >> > From: Supa [mailto:supa-bounces@ietf.org > supa-bounces@ietf.org>] On Behalf Of Bert Wijnen (IETF) >> > Sent: 07 August 2015 19:46 >> > To: Benoit Claise; supa@ietf.org >> > Cc: Eggert, Lars; ibnemo@ietf.org >> > Subject: Re: [Supa] SUPA charter proposal >> > >> > Hi Benoit and others. >> > >> > So would this work prevent the formation of a WG that would do >> IBNEMO (Intent >> > Based NEtwork MOdeling) >> > work? I certainly hope not. In the charter you have: >> > >> > (iii) the working group will investigate the practically of >> building >> policy rules >> > that declaratively >> > specify what goals to achieve (this is often called >> "intent-based" policy) but >> > not how to achieve >> > those goals and may create a model accordingly. >> > >> > >> > IBNEMO intends (no pun intended) to define/standardize a Intent >> expression >> > language. >> > The work you describe above can be input to the work IBNEMO wants >> to do. >> > >> > Bert >> > >> > On 07/08/15 18:03, Benoit Claise wrote: >> > > Dear all, >> > > >> > > As promised in my last email ("SUPA: Situation Summary and Next >> Steps"), >> here >> > is a proposed charter. >> > > Thanks to Robert Sparks, Adrian Farrel, and Dan Romascanu. >> > > >> > > Hopefully, this new version will clarify the situation, and will >> be >> acceptable to >> > everybody. >> > > Please let us know. Note: I prefer to keep the edit token from >> now. >> > > >> > > Regards, Benoit (OPS AD) >> > > >> > > >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > > >> > > SUPA CHARTER PROPOSAL (2015-08-07) >> > > >> > > Policy is an important configurable component in the delivery of >> services >> and >> > the operation of networks. Operators want and need >> > > to be able to determine the policies that apply to their >> different customers >> and >> > to the equipment that comprises their physical >> > > and virtual networks. As policy spans such a wide range of >> services and >> device >> > types, it will be helpful if there is a common way >> > > of expressing and describing policies that is uniform and >> consistent in all >> > environments. Such an approach will help to avoid >> > > configuration errors that arise from confusion between different >> systems, >> will >> > enable easy understanding of policies that apply in >> > > different environments, will make the implementation of >> policy-based systems >> > quicker and cheaper, and will facilitate the rapid >> > > development of standards-based data models that include policy >> elements. >> > > >> > > SUPA (Simplified Use of Policy Abstractions) defines a model to >> interface >> with a >> > network management function (within a controller, >> > > an orchestrator, a network element) that takes high-level, >> possibly network- >> > wide policies as input. SUPA will not define what the >> > > function does with that input but anticipates that it will >> ultimately result >> in >> > network configuration changes >> > > >> > > Practically, SUPA will define generic YANG data models to encode >> policy, >> which >> > can point to device-, technology-, and >> > > service-specific YANG models of other working groups. >> > > >> > > SUPA will be designed to work with device, protocol, network, an= d >> service >> data >> > models. >> > > >> > > The SUPA working group will develop a model for expressing polic= y >> at >> different >> > levels of abstraction.Specifically, three model >> > > fragments are envisioned: (i) a generic model that defines >> concepts and >> > vocabulary needed by policy management independent of the >> > > form and content of the policy, (ii) a more specific model that >> refines the >> > generic model to specify how to build policy rules of >> > > the event-condition-action paradigm, and (iii) the working group >> will >> investigate >> > the practically of building policy rules that >> > > declaratively specify what goals to achieve (this is often calle= d >> "intent-based" >> > policy) but not how to achieve those goals and >> > > may create a model accordingly. >> > > >> > > If the working group finds it necessary to work on an informatio= n >> model >> before >> > the data model, to help provide guidance and derive >> > > the data models, it might do so. The working group will decide >> later whether >> > the information model needs to be published as an RFC. >> > > >> > > Out of scope of this working group is: >> > > >> > > -The specification of a new policy language. The YANG data model= s >> are to be >> > used with protocols such as NETCONF/RESTCONF. >> > > >> > > -Design of protocol-specific policies and specific design for >> embedded >> policies in >> > network elements (which are usually interpreted >> > > in isolation, and often at timescales that require optimization >> for specific >> > purposes). >> > > >> > > -Specific handling of policies (although the application documen= t >> will >> provide >> > some examples), and therefore the specification of >> > > a policy engine that maps a specific policy instance to actual >> configuration >> > snippets. >> > > >> > > List of work items: >> > > >> > > 1) A document that explains the scope of the policy-based >> management >> > framework and how it relates to existing work of the IETF. >> > > >> > > 2) If the working group considers it necessary, an information >> model >> composed >> > of policy concepts and vocabulary. >> > > >> > > 3) A set of YANG data models consisting of a base policy model f= or >> representing >> > policy management concepts independent of the type >> > > or structure of a policy, plus an extension for defining policy >> rules >> according to >> > the event-condition-action paradigm. Another >> > > extension for defining policy rules according to a declarative, = or >> intent-based, >> > paradigm, may be produced. These models will be >> > > designed to be generic and extensible. >> > > >> > > 4) An applicability document providing a few examples that >> demonstrate how >> > the generic policy models can be used to express >> > > policies that are relevant for network operators. The examples >> may tie into >> > configuration models or network service models >> > > developed by other working groups. >> > > >> > > The working group will decide how the work items are best mapped >> into >> > deliverables. >> > > >> > > This working group will be a success when the SUPA policy >> constructs are re- >> > used in future IETF specifications (and, ideally, >> > > specifications from other SDOs), in a manner that will save >> development time >> > and avoid inconsistencies between data models >> > > developed by different working groups. In the meantime, SUPA >> should not >> > impede work in other working groups while waiting for SUPA >> > > to produce its deliverables. >> > > >> > > The working group will communicate with other SDOs (MEF, TMF, >> ETSI) that are >> > working on related issues. >> > > >> > > Milestones: >> > > >> > > TBD >> > > >> > > >> > > >> > > >> > > _______________________________________________ >> > > Supa mailing list >> > > Supa@ietf.org >> > > https://www.ietf.org/mailman/listinfo/supa >> > >> > _______________________________________________ >> > Supa mailing list >> > Supa@ietf.org >> > https://www.ietf.org/mailman/listinfo/supa >> >> _______________________________________________ >> Supa mailing list >> Supa@ietf.org >> https://www.ietf.org/mailman/listinfo/supa >> >> >> >> >> -- >> regards, >> John >> >> >> _______________________________________________ >> Supa mailing list >> Supa@ietf.org >> https://www.ietf.org/mailman/listinfo/supa >> > > --=20 regards, John --047d7b3a9be63b722c051ce7fbdc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Bert,

please see inline.

In addition, there are distinct differences between S= UPA and NEMO:

>>=C2=A0 1) SUPA defines NETCONF or RESTCONF as= its protocol. Period.
>>=C2=A0 In contrast, NEMO wants to define = a new protocol.

> I do not know what makes you say so.
= > I think we have left it open sofar as to whether we want/need a new
> protocol or not.
> Preferably we can use Netconf/Restc= onf. But I think that is all still
>=C2=A0open to discussion.<= /div>

<jcs>
What makes me say so is a co= mbination of
=C2=A0 1)=C2=A0listening to previous NEMO presentati= ons in other fora
=C2=A0 2) various sentences in the IBNEMO Bar B= oF presentation
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (e.g., "Question: sc= ripts over http workable, Not sure
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 RESTCONF rpc + pub.sub level needed",
=C2=A0=C2=A03) = Statements such as "Synergistic means that sum of Intent Based
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 NEMO protocol + NETCONF + RESTCONF + I2RS= +PCE is more
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 than any of the part= s alone" and "creating protocol with minimal
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 operations for to express intent from the application= to the network".
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 both from d= raft-hares-ibnemo-overview-01
=C2=A0 4) a mail from Sue on 7/17 t= o the NEMO and SUPA lists, that said
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 "IBNemo=E2=80=99s 15 specific comm= ands are better than NETCONF
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 or RESTCONF commands"
I can give you many more examples...
</jcs>

>> 2) SUPA defines int= ent as declarative logic, and thus implements
>>=C2=A0it using eit= her propositional or first order logic (see section 3.2.4.,
>>=C2= =A0Mathematical Logic Terminology, of draft-strassner-supa-generic-
>= >=C2=A0policy-info-model). In contrast, NEMO defines implements its
&= gt;> intent policy using condition-action (imperative) logic.
=
> Again I do not understand why you think so.
> I = have not seen any ECA stuff in IBNEMO yet.
> But then, maybe you can= point me to it if you have.

<jcs>
I said "condition-action", NOT ECA.
Please look at dra= ft-xia-sdnrg-nemo-language-02, which says:
"All the policies= follow the same pattern "when <condition>, to
execut= e <action>, with <constraint>", and can be applied to any = entity."
</jcs>

On Sun, Aug 9, 2015 at 2:23 PM, Bert Wij= nen (IETF) <bwietf@bwijnen.net> wrote:
John, Inline,

On 09/08/15 22:30, John Strassner wrote:
Hi Adrian,

I also do not think that there is any overlap between what SUPA has defined=
and what NEMO has defined. SUPA provides a common model for
expressing imperative (e.g., event-condition-action, or ECA) and declarativ= e
(e.g., goal-based, or "intent") policies. SUPA proposes that each= of these
representations are realized as separate models, but are related through their "common ancestry" (i.e., they were both derived from the sa= me
superstructure). This means that each can use the other.

OK, that sounds good to me.

In addition, there are distinct differences between SUPA and NEMO:

=C2=A0 1) SUPA defines NETCONF or RESTCONF as its protocol. Period. In
=C2=A0 =C2=A0 =C2=A0 contrast, NEMO wants to define a new protocol.
I do not know what makes you say so.
I think we have left it open sofar as to whether we want/need a new protoco= l or not.
Preferably we can use Netconf/Restconf. But I think that is all still open = to discussion.
=C2=A0 2) SUPA defines intent as declarative logic, and thus implements it<= br> =C2=A0 =C2=A0 =C2=A0 using either propositional or first order logic (see s= ection 3.2.4.,
=C2=A0 =C2=A0 =C2=A0 Mathematical Logic Terminology, of draft-strassner-sup= a-generic-
=C2=A0 =C2=A0 =C2=A0 policy-info-model). In contrast, NEMO defines implemen= ts its
=C2=A0 =C2=A0 =C2=A0 intent policy using condition-action (imperative) logi= c.
Again I do not understand why you think so.
I have not seen any ECA stuff in IBNEMO yet.
But then, maybe you can point me to it if you have.
=C2=A03) SUPA is NOT working on a language. In contrast, NEMO is working =C2=A0 =C2=A0 =C2=A0on a language.
Yep, we would like to work on an "intent expression language" in = IBNEMO.

Bert

regards,
John

On Sun, Aug 9, 2015 at 8:23 AM, Adrian Farrel <adrian@olddog.co.uk <mailto:adrian@olddog.co.uk&g= t;> wrote:

=C2=A0 =C2=A0 Hi Bert,

=C2=A0 =C2=A0 I don't think you are reading the proposed charter for SU= PA right if you think
=C2=A0 =C2=A0 it precludes the formation of a working group for IBNEMO. Rat= her, the text that
=C2=A0 =C2=A0 Benoit has published says that SUPA is not the working group = that works on
=C2=A0 =C2=A0 IBNEMO.

=C2=A0 =C2=A0 But maybe you are saying that the intent-based part of the SU= AP charter could be
=C2=A0 =C2=A0 lifted out and placed in an IBNEMO work effort. That might be= reasonable.

=C2=A0 =C2=A0 However, there is a separation between the use of existing da= ta modeling and
=C2=A0 =C2=A0 protocols (such as YANG with NETCONF) and the development of = a new and
=C2=A0 =C2=A0 specialised modeling language and communication protocol. I b= elieve that this
=C2=A0 =C2=A0 charter text opens up the investigation of the practicalities= of intent-based
=C2=A0 =C2=A0 policy modeling in order to determine whether such things cou= ld be modeled in
=C2=A0 =C2=A0 existing languages or whether new work is needed a priori.
=C2=A0 =C2=A0 If, for example, it was possible to encode intent-based polic= y in YANG, that
=C2=A0 =C2=A0 would not preclude IBNEMO inventing something different/bette= r/worse.

=C2=A0 =C2=A0 Now there it seems sensible that SUPA should bundle all of th= e thought around
=C2=A0 =C2=A0 policy models in one place as a starting point. If it is late= r desirable to
=C2=A0 =C2=A0 split off the intent-based part (say after the initial invest= igation and
=C2=A0 =C2=A0 information models) that doesn't seem like a bad thing.
=C2=A0 =C2=A0 Alternatively, if there is a strong pull to move all of the i= ntent-based work
=C2=A0 =C2=A0 out from day one, I will not be complaining.

=C2=A0 =C2=A0 Cheers,
=C2=A0 =C2=A0 Adrian

=C2=A0 =C2=A0 > -----Original Message-----
=C2=A0 =C2=A0 > From: Supa [mailto:supa-bounces@ietf.org <mailto:supa-bounces@ietf.org>] O= n Behalf Of Bert Wijnen (IETF)
=C2=A0 =C2=A0 > Sent: 07 August 2015 19:46
=C2=A0 =C2=A0 > To: Benoit Claise; supa@ietf.org <mailto:supa@ietf.org>
=C2=A0 =C2=A0 > Cc: Eggert, Lars; ibnemo@ietf.org <mailto:ibnemo@ietf.org>
=C2=A0 =C2=A0 > Subject: Re: [Supa] SUPA charter proposal
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Hi Benoit and others.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > So would this work prevent the formation of a WG that wo= uld do IBNEMO (Intent
=C2=A0 =C2=A0 > Based NEtwork MOdeling)
=C2=A0 =C2=A0 > work? I certainly hope not. In the charter you have:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 (iii) the working group will = investigate the practically of building
=C2=A0 =C2=A0 policy rules
=C2=A0 =C2=A0 > that declaratively
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 specify = what goals to achieve (this is often called
=C2=A0 =C2=A0 "intent-based" policy) but
=C2=A0 =C2=A0 > not how to achieve
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 those go= als and may create a model accordingly.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > IBNEMO intends (no pun intended) to define/standardize a= Intent expression
=C2=A0 =C2=A0 > language.
=C2=A0 =C2=A0 > The work you describe above can be input to the work IBN= EMO wants to do.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Bert
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > On 07/08/15 18:03, Benoit Claise wrote:
=C2=A0 =C2=A0 > > Dear all,
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > As promised in my last email ("SUPA: Situation= Summary and Next Steps"),
=C2=A0 =C2=A0 here
=C2=A0 =C2=A0 > is a proposed charter.
=C2=A0 =C2=A0 > > Thanks to Robert Sparks, Adrian Farrel, and Dan Rom= ascanu.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > Hopefully, this new version will clarify the situat= ion, and will be
=C2=A0 =C2=A0 acceptable to
=C2=A0 =C2=A0 > everybody.
=C2=A0 =C2=A0 > > Please let us know. Note: I prefer to keep the edit= token from now.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > Regards, Benoit (OPS AD)
=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
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > SUPA CHARTER PROPOSAL (2015-08-07)
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > Policy is an important configurable component in th= e delivery of services
=C2=A0 =C2=A0 and
=C2=A0 =C2=A0 > the operation of networks. Operators want and need
=C2=A0 =C2=A0 > > to be able to determine the policies that apply to = their different customers
=C2=A0 =C2=A0 and
=C2=A0 =C2=A0 > to the equipment that comprises their physical
=C2=A0 =C2=A0 > > and virtual networks. As policy spans such a wide r= ange of services and
=C2=A0 =C2=A0 device
=C2=A0 =C2=A0 > types, it will be helpful if there is a common way
=C2=A0 =C2=A0 > > of expressing and describing policies that is unifo= rm and consistent in all
=C2=A0 =C2=A0 > environments. Such an approach will help to avoid
=C2=A0 =C2=A0 > > configuration errors that arise from confusion betw= een different systems,
=C2=A0 =C2=A0 will
=C2=A0 =C2=A0 > enable easy understanding of policies that apply in
=C2=A0 =C2=A0 > > different environments, will make the implementatio= n of policy-based systems
=C2=A0 =C2=A0 > quicker and cheaper, and will facilitate the rapid
=C2=A0 =C2=A0 > > development of standards-based data models that inc= lude policy elements.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > SUPA (Simplified Use of Policy Abstractions) define= s a model to interface
=C2=A0 =C2=A0 with a
=C2=A0 =C2=A0 > network management function (within a controller,
=C2=A0 =C2=A0 > > an orchestrator, a network element) that takes high= -level, possibly network-
=C2=A0 =C2=A0 > wide policies as input. SUPA will not define what the =C2=A0 =C2=A0 > > function does with that input but anticipates that = it will ultimately result
=C2=A0 =C2=A0 in
=C2=A0 =C2=A0 > network configuration changes
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > Practically, SUPA will define generic YANG data mod= els to encode policy,
=C2=A0 =C2=A0 which
=C2=A0 =C2=A0 > can point to device-, technology-, and
=C2=A0 =C2=A0 > > service-specific YANG models of other working group= s.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > SUPA will be designed to work with device, protocol= , network, and service
=C2=A0 =C2=A0 data
=C2=A0 =C2=A0 > models.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > The SUPA working group will develop a model for exp= ressing policy at
=C2=A0 =C2=A0 different
=C2=A0 =C2=A0 > levels of abstraction.Specifically, three model
=C2=A0 =C2=A0 > > fragments are envisioned: (i) a generic model that = defines concepts and
=C2=A0 =C2=A0 > vocabulary needed by policy management independent of th= e
=C2=A0 =C2=A0 > > form and content of the policy, (ii) a more specifi= c model that refines the
=C2=A0 =C2=A0 > generic model to specify how to build policy rules of =C2=A0 =C2=A0 > > the event-condition-action paradigm, and (iii) the = working group will
=C2=A0 =C2=A0 investigate
=C2=A0 =C2=A0 > the practically of building policy rules that
=C2=A0 =C2=A0 > > declaratively specify what goals to achieve (this i= s often called
=C2=A0 =C2=A0 "intent-based"
=C2=A0 =C2=A0 > policy) but not how to achieve those goals and
=C2=A0 =C2=A0 > > may create a model accordingly.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > If the working group finds it necessary to work on = an information model
=C2=A0 =C2=A0 before
=C2=A0 =C2=A0 > the data model, to help provide guidance and derive
=C2=A0 =C2=A0 > > the data models, it might do so. The working group = will decide later whether
=C2=A0 =C2=A0 > the information model needs to be published as an RFC. =C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > Out of scope of this working group is:
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > -The specification of a new policy language. The YA= NG data models are to be
=C2=A0 =C2=A0 > used with protocols such as NETCONF/RESTCONF.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > -Design of protocol-specific policies and specific = design for embedded
=C2=A0 =C2=A0 policies in
=C2=A0 =C2=A0 > network elements (which are usually interpreted
=C2=A0 =C2=A0 > > in isolation, and often at timescales that require = optimization for specific
=C2=A0 =C2=A0 > purposes).
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > -Specific handling of policies (although the applic= ation document will
=C2=A0 =C2=A0 provide
=C2=A0 =C2=A0 > some examples), and therefore the specification of
=C2=A0 =C2=A0 > > a policy engine that maps a specific policy instanc= e to actual configuration
=C2=A0 =C2=A0 > snippets.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > List of work items:
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > 1) A document that explains the scope of the policy= -based management
=C2=A0 =C2=A0 > framework and how it relates to existing work of the IET= F.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > 2) If the working group considers it necessary, an = information model
=C2=A0 =C2=A0 composed
=C2=A0 =C2=A0 > of policy concepts and vocabulary.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > 3) A set of YANG data models consisting of a base p= olicy model for
=C2=A0 =C2=A0 representing
=C2=A0 =C2=A0 > policy management concepts independent of the type
=C2=A0 =C2=A0 > > or structure of a policy, plus an extension for def= ining policy rules
=C2=A0 =C2=A0 according to
=C2=A0 =C2=A0 > the event-condition-action paradigm. Another
=C2=A0 =C2=A0 > > extension for defining policy rules according to a = declarative, or
=C2=A0 =C2=A0 intent-based,
=C2=A0 =C2=A0 > paradigm, may be produced. These models will be
=C2=A0 =C2=A0 > > designed to be generic and extensible.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > 4) An applicability document providing a few exampl= es that demonstrate how
=C2=A0 =C2=A0 > the generic policy models can be used to express
=C2=A0 =C2=A0 > > policies that are relevant for network operators. T= he examples may tie into
=C2=A0 =C2=A0 > configuration models or network service models
=C2=A0 =C2=A0 > > developed by other working groups.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > The working group will decide how the work items ar= e best mapped into
=C2=A0 =C2=A0 > deliverables.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > This working group will be a success when the SUPA = policy constructs are re-
=C2=A0 =C2=A0 > used in future IETF specifications (and, ideally,
=C2=A0 =C2=A0 > > specifications from other SDOs), in a manner that w= ill save development time
=C2=A0 =C2=A0 > and avoid inconsistencies between data models
=C2=A0 =C2=A0 > > developed by different working groups. In the meant= ime, SUPA should not
=C2=A0 =C2=A0 > impede work in other working groups while waiting for SU= PA
=C2=A0 =C2=A0 > > to produce its deliverables.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > The working group will communicate with other SDOs = (MEF, TMF, ETSI) that are
=C2=A0 =C2=A0 > working on related issues.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > Milestones:
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > TBD
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > _______________________________________________
=C2=A0 =C2=A0 > > Supa mailing list
=C2=A0 =C2=A0 > > = Supa@ietf.org <mailto:Supa@ietf.org>
=C2=A0 =C2=A0 > > https://www.ietf.org/mailman/listi= nfo/supa
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > _______________________________________________
=C2=A0 =C2=A0 > Supa mailing list
=C2=A0 =C2=A0 > Supa@= ietf.org <mailto:= Supa@ietf.org>
=C2=A0 =C2=A0 > https://www.ietf.org/mailman/listinfo/s= upa

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 Supa mailing list
=C2=A0 =C2=A0 Supa@ietf.= org <mailto:Supa@= ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/supa




--
regards,
John


_______________________________________________
Supa mailing list
Supa@ietf.org
https://www.ietf.org/mailman/listinfo/supa




--
regards,
John
--047d7b3a9be63b722c051ce7fbdc-- From nobody Mon Aug 10 15:17:01 2015 Return-Path: X-Original-To: ibnemo@ietfa.amsl.com Delivered-To: ibnemo@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8210B1A1B59; Mon, 10 Aug 2015 15:16:59 -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 xPV2zrJiRZ5T; Mon, 10 Aug 2015 15:16:54 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 1F1021A1B1E; Mon, 10 Aug 2015 15:16:53 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.35.59; From: "Susan Hares" To: "'John Strassner'" , "'Bert Wijnen \(IETF\)'" References: <55C4D6C1.5040504@cisco.com> <55C4FCFE.8070701@bwijnen.net> <023101d0d2b7$54dad4e0$fe907ea0$@olddog.co.uk> <55C7C4E6.9020003@bwijnen.net> In-Reply-To: Date: Mon, 10 Aug 2015 18:16:49 -0400 Message-ID: <000801d0d3ba$42fb07f0$c8f117d0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01D0D398.BBEF8270" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIGDj3FnqOFLnABOhC256xK4GCt4gLk/N/WATitRZACY7y84wGAa09GArBQ5gKdRcABEA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Adrian Farrel' , "'Eggert, Lars'" , ibnemo@ietf.org, supa@ietf.org Subject: Re: [Ibnemo] [Supa] SUPA charter proposal X-BeenThere: ibnemo@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of Nemo, an intent-based North Bound \(NB\) interface consisting of an application protocol running over HTTP \(RESTful interfaces\) to exchange intent-based primitives between applications and meta-controllers controlling virtual network resources \(networks, storage, CPU\)." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 22:16:59 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0009_01D0D398.BBEF8270 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable John:=20 =20 To respond to the following part of your discussion with Bert:=20 =20 What makes me say so is a combination of 1) listening to previous NEMO presentations in other forum=20 =20 I=E2=80=99m glad you=E2=80=99ve listen to Nemo presentations at other = forums =20 =20 2) various sentences in the IBNEMO Bar BoF presentation (e.g., "Question: scripts over http workable, Not sure RESTCONF rpc + pub.sub level needed", =20 It is this statement that Bert is alluding to. We are open to using a = transport mechanism from http, or RESTCONF with various forms to carry = the Nemo commands. =20 =20 =20 3) Statements such as "Synergistic means that sum of Intent Based NEMO protocol + NETCONF + RESTCONF + I2RS +PCE is more than any of the parts alone" and "creating protocol with minimal operations for to express intent from the application to the = network". both from draft-hares-ibnemo-overview-01 =20 : The key point here is the Nemo commands (connection, plus = language commands enable the user to ask for connection with easy human = language for the end-user.=20 =20 =20 4) a mail from Sue on 7/17 to the NEMO and SUPA lists, that said "IBNemo=E2=80=99s 15 specific commands are better than NETCONF=20 or RESTCONF commands" I can give you many more examples... =20 The reason these 15 commands are better is that these commands are = targeted the end-user for network-wide commands. The Netconf/restconf = commands are focused at the device level. =20 =20 =20 =20 =20 =20 From: Ibnemo [mailto:ibnemo-bounces@ietf.org] On Behalf Of John = Strassner Sent: Sunday, August 09, 2015 5:59 PM To: Bert Wijnen (IETF) Cc: Adrian Farrel; Eggert, Lars; ibnemo@ietf.org; supa@ietf.org Subject: Re: [Ibnemo] [Supa] SUPA charter proposal =20 Bert, =20 please see inline. =20 In addition, there are distinct differences between SUPA and NEMO: >> 1) SUPA defines NETCONF or RESTCONF as its protocol. Period. >> In contrast, NEMO wants to define a new protocol. > I do not know what makes you say so. > I think we have left it open sofar as to whether we want/need a new > protocol or not. > Preferably we can use Netconf/Restconf. But I think that is all still > open to discussion. =20 What makes me say so is a combination of 1) listening to previous NEMO presentations in other fora 2) various sentences in the IBNEMO Bar BoF presentation (e.g., "Question: scripts over http workable, Not sure RESTCONF rpc + pub.sub level needed", 3) Statements such as "Synergistic means that sum of Intent Based NEMO protocol + NETCONF + RESTCONF + I2RS +PCE is more than any of the parts alone" and "creating protocol with minimal operations for to express intent from the application to the = network". both from draft-hares-ibnemo-overview-01 4) a mail from Sue on 7/17 to the NEMO and SUPA lists, that said "IBNemo=E2=80=99s 15 specific commands are better than NETCONF=20 or RESTCONF commands" I can give you many more examples... =20 >> 2) SUPA defines intent as declarative logic, and thus implements >> it using either propositional or first order logic (see section = 3.2.4., >> Mathematical Logic Terminology, of draft-strassner-supa-generic- >> policy-info-model). In contrast, NEMO defines implements its >> intent policy using condition-action (imperative) logic. =20 > Again I do not understand why you think so. > I have not seen any ECA stuff in IBNEMO yet. > But then, maybe you can point me to it if you have. =20 I said "condition-action", NOT ECA. Please look at draft-xia-sdnrg-nemo-language-02, which says: "All the policies follow the same pattern "when , to=20 execute , with ", and can be applied to any entity." =20 On Sun, Aug 9, 2015 at 2:23 PM, Bert Wijnen (IETF) = wrote: John, Inline, On 09/08/15 22:30, John Strassner wrote: Hi Adrian, I also do not think that there is any overlap between what SUPA has = defined and what NEMO has defined. SUPA provides a common model for expressing imperative (e.g., event-condition-action, or ECA) and = declarative (e.g., goal-based, or "intent") policies. SUPA proposes that each of = these representations are realized as separate models, but are related through their "common ancestry" (i.e., they were both derived from the same superstructure). This means that each can use the other. OK, that sounds good to me. In addition, there are distinct differences between SUPA and NEMO: 1) SUPA defines NETCONF or RESTCONF as its protocol. Period. In contrast, NEMO wants to define a new protocol. I do not know what makes you say so. I think we have left it open sofar as to whether we want/need a new = protocol or not. Preferably we can use Netconf/Restconf. But I think that is all still = open to discussion. 2) SUPA defines intent as declarative logic, and thus implements it using either propositional or first order logic (see section = 3.2.4., Mathematical Logic Terminology, of draft-strassner-supa-generic- policy-info-model). In contrast, NEMO defines implements its intent policy using condition-action (imperative) logic. Again I do not understand why you think so. I have not seen any ECA stuff in IBNEMO yet. But then, maybe you can point me to it if you have. 3) SUPA is NOT working on a language. In contrast, NEMO is working on a language. Yep, we would like to work on an "intent expression language" in IBNEMO. Bert regards, John On Sun, Aug 9, 2015 at 8:23 AM, Adrian Farrel > wrote: Hi Bert, I don't think you are reading the proposed charter for SUPA right if = you think it precludes the formation of a working group for IBNEMO. Rather, = the text that Benoit has published says that SUPA is not the working group that = works on IBNEMO. But maybe you are saying that the intent-based part of the SUAP = charter could be lifted out and placed in an IBNEMO work effort. That might be = reasonable. However, there is a separation between the use of existing data = modeling and protocols (such as YANG with NETCONF) and the development of a new = and specialised modeling language and communication protocol. I believe = that this charter text opens up the investigation of the practicalities of = intent-based policy modeling in order to determine whether such things could be = modeled in existing languages or whether new work is needed a priori. If, for example, it was possible to encode intent-based policy in = YANG, that would not preclude IBNEMO inventing something = different/better/worse. Now there it seems sensible that SUPA should bundle all of the = thought around policy models in one place as a starting point. If it is later = desirable to split off the intent-based part (say after the initial investigation = and information models) that doesn't seem like a bad thing. Alternatively, if there is a strong pull to move all of the = intent-based work out from day one, I will not be complaining. Cheers, Adrian > -----Original Message----- > From: Supa [mailto:supa-bounces@ietf.org = ] On Behalf Of Bert Wijnen (IETF) > Sent: 07 August 2015 19:46 > To: Benoit Claise; supa@ietf.org > Cc: Eggert, Lars; ibnemo@ietf.org > Subject: Re: [Supa] SUPA charter proposal > > Hi Benoit and others. > > So would this work prevent the formation of a WG that would do = IBNEMO (Intent > Based NEtwork MOdeling) > work? I certainly hope not. In the charter you have: > > (iii) the working group will investigate the practically of = building policy rules > that declaratively > specify what goals to achieve (this is often called "intent-based" policy) but > not how to achieve > those goals and may create a model accordingly. > > > IBNEMO intends (no pun intended) to define/standardize a Intent = expression > language. > The work you describe above can be input to the work IBNEMO wants = to do. > > Bert > > On 07/08/15 18:03, Benoit Claise wrote: > > Dear all, > > > > As promised in my last email ("SUPA: Situation Summary and Next = Steps"), here > is a proposed charter. > > Thanks to Robert Sparks, Adrian Farrel, and Dan Romascanu. > > > > Hopefully, this new version will clarify the situation, and will = be acceptable to > everybody. > > Please let us know. Note: I prefer to keep the edit token from = now. > > > > Regards, Benoit (OPS AD) > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > SUPA CHARTER PROPOSAL (2015-08-07) > > > > Policy is an important configurable component in the delivery of = services and > the operation of networks. Operators want and need > > to be able to determine the policies that apply to their = different customers and > to the equipment that comprises their physical > > and virtual networks. As policy spans such a wide range of = services and device > types, it will be helpful if there is a common way > > of expressing and describing policies that is uniform and = consistent in all > environments. Such an approach will help to avoid > > configuration errors that arise from confusion between different = systems, will > enable easy understanding of policies that apply in > > different environments, will make the implementation of = policy-based systems > quicker and cheaper, and will facilitate the rapid > > development of standards-based data models that include policy = elements. > > > > SUPA (Simplified Use of Policy Abstractions) defines a model to = interface with a > network management function (within a controller, > > an orchestrator, a network element) that takes high-level, = possibly network- > wide policies as input. SUPA will not define what the > > function does with that input but anticipates that it will = ultimately result in > network configuration changes > > > > Practically, SUPA will define generic YANG data models to encode = policy, which > can point to device-, technology-, and > > service-specific YANG models of other working groups. > > > > SUPA will be designed to work with device, protocol, network, = and service data > models. > > > > The SUPA working group will develop a model for expressing = policy at different > levels of abstraction.Specifically, three model > > fragments are envisioned: (i) a generic model that defines = concepts and > vocabulary needed by policy management independent of the > > form and content of the policy, (ii) a more specific model that = refines the > generic model to specify how to build policy rules of > > the event-condition-action paradigm, and (iii) the working group = will investigate > the practically of building policy rules that > > declaratively specify what goals to achieve (this is often = called "intent-based" > policy) but not how to achieve those goals and > > may create a model accordingly. > > > > If the working group finds it necessary to work on an = information model before > the data model, to help provide guidance and derive > > the data models, it might do so. The working group will decide = later whether > the information model needs to be published as an RFC. > > > > Out of scope of this working group is: > > > > -The specification of a new policy language. The YANG data = models are to be > used with protocols such as NETCONF/RESTCONF. > > > > -Design of protocol-specific policies and specific design for = embedded policies in > network elements (which are usually interpreted > > in isolation, and often at timescales that require optimization = for specific > purposes). > > > > -Specific handling of policies (although the application = document will provide > some examples), and therefore the specification of > > a policy engine that maps a specific policy instance to actual = configuration > snippets. > > > > List of work items: > > > > 1) A document that explains the scope of the policy-based = management > framework and how it relates to existing work of the IETF. > > > > 2) If the working group considers it necessary, an information = model composed > of policy concepts and vocabulary. > > > > 3) A set of YANG data models consisting of a base policy model = for representing > policy management concepts independent of the type > > or structure of a policy, plus an extension for defining policy = rules according to > the event-condition-action paradigm. Another > > extension for defining policy rules according to a declarative, = or intent-based, > paradigm, may be produced. These models will be > > designed to be generic and extensible. > > > > 4) An applicability document providing a few examples that = demonstrate how > the generic policy models can be used to express > > policies that are relevant for network operators. The examples = may tie into > configuration models or network service models > > developed by other working groups. > > > > The working group will decide how the work items are best mapped = into > deliverables. > > > > This working group will be a success when the SUPA policy = constructs are re- > used in future IETF specifications (and, ideally, > > specifications from other SDOs), in a manner that will save = development time > and avoid inconsistencies between data models > > developed by different working groups. In the meantime, SUPA = should not > impede work in other working groups while waiting for SUPA > > to produce its deliverables. > > > > The working group will communicate with other SDOs (MEF, TMF, = ETSI) that are > working on related issues. > > > > Milestones: > > > > TBD > > > > > > > > > > _______________________________________________ > > Supa mailing list > > Supa@ietf.org > > https://www.ietf.org/mailman/listinfo/supa > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa _______________________________________________ Supa mailing list Supa@ietf.org https://www.ietf.org/mailman/listinfo/supa --=20 regards, John _______________________________________________ Supa mailing list Supa@ietf.org https://www.ietf.org/mailman/listinfo/supa =20 --=20 regards, John ------=_NextPart_000_0009_01D0D398.BBEF8270 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

John:

 

To respond to the following part of your discussion with Bert: =

 

<jcs>

What = makes me say so is a combination of

1)      = listening to previous NEMO presentations in = other forum

<sue> =

I=E2=80=99m glad you=E2=80=99ve = listen to Nemo presentations at other forums

</sue>

 

  2) = various sentences in the IBNEMO Bar BoF = presentation
      (e.g., "Question: = scripts over http workable, Not sure

       RESTCONF rpc + = pub.sub level needed",

<sue>

It is = this statement that Bert is alluding to.=C2=A0 We are open to using a = transport mechanism from http, or RESTCONF with various forms to carry = the Nemo commands. =C2=A0

</sue>

 

  3) Statements such as "Synergistic = means that sum of Intent Based

      NEMO protocol + NETCONF = + RESTCONF + I2RS +PCE is more

      than any of the parts = alone" and "creating protocol with minimal

      operations for to = express intent from the application to the = network".

      both from = draft-hares-ibnemo-overview-01

 

<sue>: = The key point here is the Nemo commands (connection, plus language = commands enable the user to ask for connection with easy human language = for the end-user.

</sue> =

 

  4) a mail from Sue on 7/17 to the NEMO and SUPA = lists, that said

      "IBNemo=E2=80=99s 15 specific commands are better than NETCONF =

        or RESTCONF = commands"

I can give you many more examples...

 

<sue> The reason these 15 commands are better is that these = commands are targeted the end-user for network-wide commands. =C2=A0The = Netconf/restconf commands are focused at the device level. = =C2=A0

</sue>

</jcs>

 

 

 

 

From:= = Ibnemo [mailto:ibnemo-bounces@ietf.org] On Behalf Of John = Strassner
Sent: Sunday, August 09, 2015 5:59 PM
To: = Bert Wijnen (IETF)
Cc: Adrian Farrel; Eggert, Lars; = ibnemo@ietf.org; supa@ietf.org
Subject: Re: [Ibnemo] [Supa] = SUPA charter proposal

 

Bert,

 

please see inline.

 

In addition, there are distinct differences between = SUPA and NEMO:

>>  1) SUPA defines NETCONF or RESTCONF = as its protocol. Period.
>>  In contrast, NEMO wants to = define a new protocol.


> I do not know what makes you say so.
> = I think we have left it open sofar as to whether we want/need a = new

> protocol or = not.
> Preferably we can use Netconf/Restconf. But I think that is = all still

> open = to discussion.

 

<jcs>

What makes me say so is a combination = of

  = 1) listening to previous NEMO presentations in other = fora

  2) various = sentences in the IBNEMO Bar BoF = presentation
      (e.g., "Question: = scripts over http workable, Not sure

       RESTCONF rpc + = pub.sub level needed",

  3) Statements such as "Synergistic = means that sum of Intent Based

      NEMO protocol + NETCONF = + RESTCONF + I2RS +PCE is more

      than any of the parts = alone" and "creating protocol with = minimal

      operations for to = express intent from the application to the = network".

      both from = draft-hares-ibnemo-overview-01

  4) a mail from Sue on 7/17 to the NEMO and SUPA = lists, that said

      "IBNemo=E2=80=99s 15 specific commands are better than NETCONF =

        or RESTCONF = commands"

I can give you many more examples...

</jcs>

 

>> 2) SUPA defines intent as declarative logic, = and thus implements
>> it using either propositional or = first order logic (see section 3.2.4.,
>> Mathematical = Logic Terminology, of = draft-strassner-supa-generic-
>> policy-info-model). In = contrast, NEMO defines implements its
>> intent policy using = condition-action (imperative) logic.

 

> Again I do not understand why you think = so.
> I have not seen any ECA stuff in IBNEMO yet.
> But = then, maybe you can point me to it if you = have.

 

<jcs>

I said "condition-action", NOT = ECA.

Please look at = draft-xia-sdnrg-nemo-language-02, which = says:

"All the = policies follow the same pattern "when <condition>, to =

execute <action>, = with <constraint>", and can be applied to any = entity."

</jcs>

 

On Sun, = Aug 9, 2015 at 2:23 PM, Bert Wijnen (IETF) <bwietf@bwijnen.net> wrote:

John, Inline,

On 09/08/15 22:30, John Strassner = wrote:

Hi Adrian,

I also do not think = that there is any overlap between what SUPA has defined
and what NEMO = has defined. SUPA provides a common model for
expressing imperative = (e.g., event-condition-action, or ECA) and declarative
(e.g., = goal-based, or "intent") policies. SUPA proposes that each of = these
representations are realized as separate models, but are = related through
their "common ancestry" (i.e., they were = both derived from the same
superstructure). This means that each can = use the other.

OK, that sounds good to = me.

In addition, there are distinct = differences between SUPA and NEMO:

  1) SUPA defines NETCONF = or RESTCONF as its protocol. Period. In
      = contrast, NEMO wants to define a new protocol.

I do not know what makes you say so.
I think we = have left it open sofar as to whether we want/need a new protocol or = not.
Preferably we can use Netconf/Restconf. But I think that is all = still open to discussion.

  2) = SUPA defines intent as declarative logic, and thus implements = it
      using either propositional or first order = logic (see section 3.2.4.,
      Mathematical Logic = Terminology, of draft-strassner-supa-generic-
      = policy-info-model). In contrast, NEMO defines implements its
  =     intent policy using condition-action (imperative) = logic.

Again I do not understand why = you think so.
I have not seen any ECA stuff in IBNEMO yet.
But = then, maybe you can point me to it if you have.

 3) SUPA is NOT working on a language. In = contrast, NEMO is working
     on a = language.

Yep, we would like to work = on an "intent expression language" in = IBNEMO.

Bert


regards,
John

On Sun, Aug 9, 2015 at = 8:23 AM, Adrian Farrel <adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>> wrote:

  =   Hi Bert,

    I don't think you are reading the = proposed charter for SUPA right if you think
    it = precludes the formation of a working group for IBNEMO. Rather, the text = that
    Benoit has published says that SUPA is not the = working group that works on
    IBNEMO.

  =   But maybe you are saying that the intent-based part of the SUAP = charter could be
    lifted out and placed in an IBNEMO = work effort. That might be reasonable.

    However, = there is a separation between the use of existing data modeling = and
    protocols (such as YANG with NETCONF) and the = development of a new and
    specialised modeling language = and communication protocol. I believe that this
    charter = text opens up the investigation of the practicalities of = intent-based
    policy modeling in order to determine = whether such things could be modeled in
    existing = languages or whether new work is needed a priori.

    = If, for example, it was possible to encode intent-based policy in YANG, = that
    would not preclude IBNEMO inventing something = different/better/worse.

    Now there it seems sensible = that SUPA should bundle all of the thought around
    = policy models in one place as a starting point. If it is later desirable = to
    split off the intent-based part (say after the = initial investigation and
    information models) that = doesn't seem like a bad thing.

    Alternatively, if = there is a strong pull to move all of the intent-based work
  =   out from day one, I will not be complaining.

    = Cheers,
    Adrian

    > -----Original = Message-----
    > From: Supa [mailto:supa-bounces@ietf.org <mailto:supa-bounces@ietf.org>] On Behalf Of Bert = Wijnen (IETF)
    > Sent: 07 August 2015 19:46
  =   > To: Benoit Claise; supa@ietf.org <mailto:supa@ietf.org>
    > Cc: = Eggert, Lars; ibnemo@ietf.org <mailto:ibnemo@ietf.org>
    > Subject: = Re: [Supa] SUPA charter proposal
    >
    = > Hi Benoit and others.
    >
    > = So would this work prevent the formation of a WG that would do IBNEMO = (Intent
    > Based NEtwork MOdeling)
    = > work? I certainly hope not. In the charter you have:
  =   >
    >        (iii) the = working group will investigate the practically of building
  =   policy rules
    > that declaratively
  =   >              specify what = goals to achieve (this is often called
    = "intent-based" policy) but
    > not how to = achieve
    >            =   those goals and may create a model accordingly.
    = >
    >
    > IBNEMO intends (no pun = intended) to define/standardize a Intent expression
    = > language.
    > The work you describe above can be = input to the work IBNEMO wants to do.
    >
  =   > Bert
    >
    > On 07/08/15 = 18:03, Benoit Claise wrote:
    > > Dear = all,
    > >
    > > As promised = in my last email ("SUPA: Situation Summary and Next = Steps"),
    here
    > is a proposed = charter.
    > > Thanks to Robert Sparks, Adrian = Farrel, and Dan Romascanu.
    > >
    = > > Hopefully, this new version will clarify the situation, and = will be
    acceptable to
    > = everybody.
    > > Please let us know. Note: I prefer = to keep the edit token from now.
    > >
  =   > > Regards, Benoit (OPS AD)
    > = >
    > >
    > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    > = >
    > > SUPA CHARTER PROPOSAL = (2015-08-07)
    > >
    > > = Policy is an important configurable component in the delivery of = services
    and
    > the operation of = networks. Operators want and need
    > > to be able = to determine the policies that apply to their different = customers
    and
    > to the equipment = that comprises their physical
    > > and virtual = networks. As policy spans such a wide range of services and
  =   device
    > types, it will be helpful if there = is a common way
    > > of expressing and describing = policies that is uniform and consistent in all
    > = environments. Such an approach will help to avoid
    > = > configuration errors that arise from confusion between different = systems,
    will
    > enable easy = understanding of policies that apply in
    > > = different environments, will make the implementation of policy-based = systems
    > quicker and cheaper, and will facilitate = the rapid
    > > development of standards-based data = models that include policy elements.
    > = >
    > > SUPA (Simplified Use of Policy = Abstractions) defines a model to interface
    with = a
    > network management function (within a = controller,
    > > an orchestrator, a network = element) that takes high-level, possibly network-
    > = wide policies as input. SUPA will not define what the
    = > > function does with that input but anticipates that it will = ultimately result
    in
    > network = configuration changes
    > >
    > = > Practically, SUPA will define generic YANG data models to encode = policy,
    which
    > can point to = device-, technology-, and
    > > service-specific = YANG models of other working groups.
    > = >
    > > SUPA will be designed to work with = device, protocol, network, and service
    data
  =   > models.
    > >
    > = > The SUPA working group will develop a model for expressing policy = at
    different
    > levels of = abstraction.Specifically, three model
    > > = fragments are envisioned: (i) a generic model that defines concepts = and
    > vocabulary needed by policy management = independent of the
    > > form and content of the = policy, (ii) a more specific model that refines the
    = > generic model to specify how to build policy rules of
  =   > > the event-condition-action paradigm, and (iii) the = working group will
    investigate
    > = the practically of building policy rules that
    > > = declaratively specify what goals to achieve (this is often = called
    "intent-based"
    > = policy) but not how to achieve those goals and
    > = > may create a model accordingly.
    > = >
    > > If the working group finds it necessary = to work on an information model
    before
    = > the data model, to help provide guidance and derive
  =   > > the data models, it might do so. The working group will = decide later whether
    > the information model needs = to be published as an RFC.
    > >
    = > > Out of scope of this working group is:
    > = >
    > > -The specification of a new policy = language. The YANG data models are to be
    > used with = protocols such as NETCONF/RESTCONF.
    > >
  =   > > -Design of protocol-specific policies and specific = design for embedded
    policies in
    > = network elements (which are usually interpreted
    > = > in isolation, and often at timescales that require optimization for = specific
    > purposes).
    > = >
    > > -Specific handling of policies (although = the application document will
    provide
    = > some examples), and therefore the specification of
    = > > a policy engine that maps a specific policy instance to actual = configuration
    > snippets.
    > = >
    > > List of work items:
    = > >
    > > 1) A document that explains the = scope of the policy-based management
    > framework and = how it relates to existing work of the IETF.
    > = >
    > > 2) If the working group considers it = necessary, an information model
    composed
  =   > of policy concepts and vocabulary.
    > = >
    > > 3) A set of YANG data models consisting = of a base policy model for
    representing
  =   > policy management concepts independent of the type
  =   > > or structure of a policy, plus an extension for = defining policy rules
    according to
    = > the event-condition-action paradigm. Another
    > = > extension for defining policy rules according to a declarative, = or
    intent-based,
    > paradigm, may be = produced. These models will be
    > > designed to be = generic and extensible.
    > >
    > = > 4) An applicability document providing a few examples that = demonstrate how
    > the generic policy models can be = used to express
    > > policies that are relevant = for network operators. The examples may tie into
    > = configuration models or network service models
    > = > developed by other working groups.
    > = >
    > > The working group will decide how the = work items are best mapped into
    > = deliverables.
    > >
    > > This = working group will be a success when the SUPA policy constructs are = re-
    > used in future IETF specifications (and, = ideally,
    > > specifications from other SDOs), in = a manner that will save development time
    > and avoid = inconsistencies between data models
    > > developed = by different working groups. In the meantime, SUPA should not
  =   > impede work in other working groups while waiting for = SUPA
    > > to produce its deliverables.
  =   > >
    > > The working group will = communicate with other SDOs (MEF, TMF, ETSI) that are
    = > working on related issues.
    > >
  =   > > Milestones:
    > >
    = > > TBD
    > >
    > = >
    > >
    > >
  =   > > = _______________________________________________
    > = > Supa mailing list
    > > Supa@ietf.org = <mailto:Supa@ietf.org>
    > > https://www.ietf.org/mailman/listinfo/supa
 = ;   >
    > = _______________________________________________
    > = Supa mailing list
    > Supa@ietf.org <mailto:Supa@ietf.org>
    > https://www.ietf.org/mailman/listinfo/supa

&= nbsp;   _______________________________________________
  =   Supa mailing list
    Supa@ietf.org = <mailto:Supa@ietf.org>
    https://www.ietf.org/mailman/listinfo/supa

<= br>

-- =
regards,
John


_______________________________________________
= Supa mailing list
Supa@ietf.org
https://www.ietf.org/mailman/listinfo/supa

 




--

regards,

John

------=_NextPart_000_0009_01D0D398.BBEF8270-- From nobody Wed Aug 12 13:20:56 2015 Return-Path: X-Original-To: ibnemo@ietfa.amsl.com Delivered-To: ibnemo@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA9B41A90DE; Wed, 12 Aug 2015 13:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.919 X-Spam-Level: X-Spam-Status: No, score=-12.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 eIssqn5vPNcA; Wed, 12 Aug 2015 13:20:50 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 826511A90AB; Wed, 12 Aug 2015 13:20:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8469; q=dns/txt; s=iport; t=1439410849; x=1440620449; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=uTOuiZm4hzYsbaa8PxID1YaIejOC56/XkbhB3HDSEfw=; b=K6wwIMNolSTSv6VTCU6W6FmoLxYbXcl61g0EwVL5NRKrFhPMcGpCOidz Llp8wmCaVcpUskRSyCbf16DOt6vNQkoghMNFB33LDOBnKcCnjt99U4D6x 0aKdHO6AyTyRFnEAroKl0RjBQoj8BieIbYBD4JStKg9M/XAU/SNV+n8eo E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CHBgCQqctV/xbLJq1dL4NAab9pCoV5AoIbAQEBAQEBgQuEIwEBAQQBAQE1NgoBDAQLEQQBAQEJFggHCQMCAQIBFR8JCAYBDAYCAQGIKg3QZgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEilCBA4QmEQEeMwcGhCYBBJUTh3CEfIFKhCeCd5EpJoN/PDOBDoE+AQEB X-IronPort-AV: E=Sophos;i="5.15,663,1432598400"; d="scan'208";a="602160099" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Aug 2015 20:20:47 +0000 Received: from [10.61.220.246] ([10.61.220.246]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t7CKKi5T006938; Wed, 12 Aug 2015 20:20:45 GMT To: adrian@olddog.co.uk, "'Bert Wijnen (IETF)'" , supa@ietf.org References: <55C4D6C1.5040504@cisco.com> <55C4FCFE.8070701@bwijnen.net> <023101d0d2b7$54dad4e0$fe907ea0$@olddog.co.uk> From: Benoit Claise Message-ID: <55CB609C.8040406@cisco.com> Date: Wed, 12 Aug 2015 17:05:00 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <023101d0d2b7$54dad4e0$fe907ea0$@olddog.co.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "'Eggert, Lars'" , ibnemo@ietf.org Subject: Re: [Ibnemo] [Supa] SUPA charter proposal X-BeenThere: ibnemo@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of Nemo, an intent-based North Bound \(NB\) interface consisting of an application protocol running over HTTP \(RESTful interfaces\) to exchange intent-based primitives between applications and meta-controllers controlling virtual network resources \(networks, storage, CPU\)." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 20:20:54 -0000 +1 to what Adrian wrote. Regards, B. > Hi Bert, > > I don't think you are reading the proposed charter for SUPA right if you think > it precludes the formation of a working group for IBNEMO. Rather, the text that > Benoit has published says that SUPA is not the working group that works on > IBNEMO. > > But maybe you are saying that the intent-based part of the SUAP charter could be > lifted out and placed in an IBNEMO work effort. That might be reasonable. > > However, there is a separation between the use of existing data modeling and > protocols (such as YANG with NETCONF) and the development of a new and > specialised modeling language and communication protocol. I believe that this > charter text opens up the investigation of the practicalities of intent-based > policy modeling in order to determine whether such things could be modeled in > existing languages or whether new work is needed a priori. > > If, for example, it was possible to encode intent-based policy in YANG, that > would not preclude IBNEMO inventing something different/better/worse. > > Now there it seems sensible that SUPA should bundle all of the thought around > policy models in one place as a starting point. If it is later desirable to > split off the intent-based part (say after the initial investigation and > information models) that doesn't seem like a bad thing. > > Alternatively, if there is a strong pull to move all of the intent-based work > out from day one, I will not be complaining. > > Cheers, > Adrian > >> -----Original Message----- >> From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Bert Wijnen (IETF) >> Sent: 07 August 2015 19:46 >> To: Benoit Claise; supa@ietf.org >> Cc: Eggert, Lars; ibnemo@ietf.org >> Subject: Re: [Supa] SUPA charter proposal >> >> Hi Benoit and others. >> >> So would this work prevent the formation of a WG that would do IBNEMO (Intent >> Based NEtwork MOdeling) >> work? I certainly hope not. In the charter you have: >> >> (iii) the working group will investigate the practically of building > policy rules >> that declaratively >> specify what goals to achieve (this is often called > "intent-based" policy) but >> not how to achieve >> those goals and may create a model accordingly. >> >> >> IBNEMO intends (no pun intended) to define/standardize a Intent expression >> language. >> The work you describe above can be input to the work IBNEMO wants to do. >> >> Bert >> >> On 07/08/15 18:03, Benoit Claise wrote: >>> Dear all, >>> >>> As promised in my last email ("SUPA: Situation Summary and Next Steps"), > here >> is a proposed charter. >>> Thanks to Robert Sparks, Adrian Farrel, and Dan Romascanu. >>> >>> Hopefully, this new version will clarify the situation, and will be > acceptable to >> everybody. >>> Please let us know. Note: I prefer to keep the edit token from now. >>> >>> Regards, Benoit (OPS AD) >>> >>> >> ============================================================== >>> SUPA CHARTER PROPOSAL (2015-08-07) >>> >>> Policy is an important configurable component in the delivery of services > and >> the operation of networks. Operators want and need >>> to be able to determine the policies that apply to their different customers > and >> to the equipment that comprises their physical >>> and virtual networks. As policy spans such a wide range of services and > device >> types, it will be helpful if there is a common way >>> of expressing and describing policies that is uniform and consistent in all >> environments. Such an approach will help to avoid >>> configuration errors that arise from confusion between different systems, > will >> enable easy understanding of policies that apply in >>> different environments, will make the implementation of policy-based systems >> quicker and cheaper, and will facilitate the rapid >>> development of standards-based data models that include policy elements. >>> >>> SUPA (Simplified Use of Policy Abstractions) defines a model to interface > with a >> network management function (within a controller, >>> an orchestrator, a network element) that takes high-level, possibly network- >> wide policies as input. SUPA will not define what the >>> function does with that input but anticipates that it will ultimately result > in >> network configuration changes >>> Practically, SUPA will define generic YANG data models to encode policy, > which >> can point to device-, technology-, and >>> service-specific YANG models of other working groups. >>> >>> SUPA will be designed to work with device, protocol, network, and service > data >> models. >>> The SUPA working group will develop a model for expressing policy at > different >> levels of abstraction.Specifically, three model >>> fragments are envisioned: (i) a generic model that defines concepts and >> vocabulary needed by policy management independent of the >>> form and content of the policy, (ii) a more specific model that refines the >> generic model to specify how to build policy rules of >>> the event-condition-action paradigm, and (iii) the working group will > investigate >> the practically of building policy rules that >>> declaratively specify what goals to achieve (this is often called > "intent-based" >> policy) but not how to achieve those goals and >>> may create a model accordingly. >>> >>> If the working group finds it necessary to work on an information model > before >> the data model, to help provide guidance and derive >>> the data models, it might do so. The working group will decide later whether >> the information model needs to be published as an RFC. >>> Out of scope of this working group is: >>> >>> -The specification of a new policy language. The YANG data models are to be >> used with protocols such as NETCONF/RESTCONF. >>> -Design of protocol-specific policies and specific design for embedded > policies in >> network elements (which are usually interpreted >>> in isolation, and often at timescales that require optimization for specific >> purposes). >>> -Specific handling of policies (although the application document will > provide >> some examples), and therefore the specification of >>> a policy engine that maps a specific policy instance to actual configuration >> snippets. >>> List of work items: >>> >>> 1) A document that explains the scope of the policy-based management >> framework and how it relates to existing work of the IETF. >>> 2) If the working group considers it necessary, an information model > composed >> of policy concepts and vocabulary. >>> 3) A set of YANG data models consisting of a base policy model for > representing >> policy management concepts independent of the type >>> or structure of a policy, plus an extension for defining policy rules > according to >> the event-condition-action paradigm. Another >>> extension for defining policy rules according to a declarative, or > intent-based, >> paradigm, may be produced. These models will be >>> designed to be generic and extensible. >>> >>> 4) An applicability document providing a few examples that demonstrate how >> the generic policy models can be used to express >>> policies that are relevant for network operators. The examples may tie into >> configuration models or network service models >>> developed by other working groups. >>> >>> The working group will decide how the work items are best mapped into >> deliverables. >>> This working group will be a success when the SUPA policy constructs are re- >> used in future IETF specifications (and, ideally, >>> specifications from other SDOs), in a manner that will save development time >> and avoid inconsistencies between data models >>> developed by different working groups. In the meantime, SUPA should not >> impede work in other working groups while waiting for SUPA >>> to produce its deliverables. >>> >>> The working group will communicate with other SDOs (MEF, TMF, ETSI) that are >> working on related issues. >>> Milestones: >>> >>> TBD >>> >>> >>> >>> >>> _______________________________________________ >>> Supa mailing list >>> Supa@ietf.org >>> https://www.ietf.org/mailman/listinfo/supa >> _______________________________________________ >> Supa mailing list >> Supa@ietf.org >> https://www.ietf.org/mailman/listinfo/supa > . > From nobody Wed Aug 12 13:21:29 2015 Return-Path: X-Original-To: ibnemo@ietfa.amsl.com Delivered-To: ibnemo@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA7441A90AB; Wed, 12 Aug 2015 13:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.918 X-Spam-Level: X-Spam-Status: No, score=-12.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 s-9kN72hrhZD; Wed, 12 Aug 2015 13:21:07 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EC4F1AC41C; Wed, 12 Aug 2015 13:21:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=53539; q=dns/txt; s=iport; t=1439410866; x=1440620466; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=Q3SspHP30mPAWcwmAzi9PdjlEZ/RT5k5zF4QHP0ME6U=; b=QSJVtauuK/Cm6AY5phTDaT/ffKmoI6TdfbilJtmsiSEyE32V4rOrzrQM buEAAHVxBrrOZOOZvdnSbeNUNHg266RanU5pNUlzCVFaMDGMYnynGcWyp +zwsn0dIgRvFO/SiCRRXuFN5W0nq/5TrtryHrxBLv8MLB24mqZ9GG1m0j 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0COBgCHqstV/xbLJq1dL4IfgSFpv1EZAQmFeQKCCxABAQEBAQEBgQqEIwEBAQQBAQEqQQoBDAQLEQQBAQEJFgEBBgcJAwIBAgEVHwkIBgEMBgIBAYgqDdBkAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSKUIEDhCYRAVEHBoQmAQSSC4MIh3CEfIFKhCeCd5EpJoN/PDOBDoE+AQEB X-IronPort-AV: E=Sophos;i="5.15,663,1432598400"; d="scan'208,217";a="626791583" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 12 Aug 2015 20:20:50 +0000 Received: from [10.61.220.246] ([10.61.220.246]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t7CKKlfs012171; Wed, 12 Aug 2015 20:20:48 GMT To: "Bert Wijnen (IETF)" , adrian@olddog.co.uk, supa@ietf.org References: <55C4D6C1.5040504@cisco.com> <55C4FCFE.8070701@bwijnen.net> <023101d0d2b7$54dad4e0$fe907ea0$@olddog.co.uk> <55C7BB32.30504@bwijnen.net> From: Benoit Claise Message-ID: <55CB60A3.4060004@cisco.com> Date: Wed, 12 Aug 2015 17:05:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <55C7BB32.30504@bwijnen.net> Content-Type: multipart/alternative; boundary="------------080509030504060703000408" Archived-At: Cc: "'Eggert, Lars'" , ibnemo@ietf.org Subject: Re: [Ibnemo] [Supa] SUPA charter proposal X-BeenThere: ibnemo@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of Nemo, an intent-based North Bound \(NB\) interface consisting of an application protocol running over HTTP \(RESTful interfaces\) to exchange intent-based primitives between applications and meta-controllers controlling virtual network resources \(networks, storage, CPU\)." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 20:21:15 -0000 This is a multi-part message in MIME format. --------------080509030504060703000408 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Bert, all, In-line. > Hi Adrian, inline > > On 09/08/15 17:23, Adrian Farrel wrote: >> Hi Bert, >> >> I don't think you are reading the proposed charter for SUPA right if >> you think >> it precludes the formation of a working group for IBNEMO. Rather, the >> text that >> Benoit has published says that SUPA is not the working group that >> works on >> IBNEMO. > OK, that was certainly not so clear to me. See in the charter " Out of scope of this working group is: The specification of a new policy language" > Thanks for clarifying this. I am still abit worried about > the text: > > (iii) the working group will investigate the > practically of > building policy rules that declaratively specify what goals to > achieve > (this is often called "intent-based" policy) but not how to > achieve > those goals and may create a model accordingly. > > So what does that last piece of the sentence "and may create a model > accordingly" mean then? "will investigate" and "may create a model accordingly" are carefully written to stress the experimental aspect of the intent-based. See my previous email "SUPA: Situation Summary and Next Steps" >> But maybe you are saying that the intent-based part of the SUAP >> charter could be >> lifted out and placed in an IBNEMO work effort. That might be >> reasonable. > I think that makes sense to me too. But maybe we need more discussion > on this. > In fact, Intent Based Network Modeling has already quite some traction > (including code) in > Open Daylight projects. So they are quite active already in that space. > Standardizing a language to express intent seems something that a WG > in IETF could very well > work on, actually pretty soon. AS we discussued in our barbof in Prague. I shared my views on IB-NEMO during the barbof... Regards, Benoit >> However, there is a separation between the use of existing data >> modeling and >> protocols (such as YANG with NETCONF) and the development of a new and >> specialised modeling language and communication protocol. I believe >> that this >> charter text opens up the investigation of the practicalities of >> intent-based >> policy modeling in order to determine whether such things could be >> modeled in >> existing languages or whether new work is needed a priori. > In fact, in IBNEMO we realize that we need to use (or define maybe) > some YANG data models > that would allow us to translate "intent expressions" into actual > network-wide, conroller-wide > or device-specific data models. We would use any existing data models > if at laa possibl. > But we do need some data models in order to prove that our expression > language can work and > be implemented in interoperable code. >> >> If, for example, it was possible to encode intent-based policy in >> YANG, that >> would not preclude IBNEMO inventing something different/better/worse. > RIght, but my personal preference would be to try and see if we can > use existing YANG data models >> Now there it seems sensible that SUPA should bundle all of the >> thought around >> policy models in one place as a starting point. If it is later >> desirable to >> split off the intent-based part (say after the initial investigation and >> information models) that doesn't seem like a bad thing. > Could be I guess >> Alternatively, if there is a strong pull to move all of the >> intent-based work >> out from day one, I will not be complaining. > And I think some of that work has already started, although still at > an indiviadual-draft level. > > Bert >> Cheers, >> Adrian >> >>> -----Original Message----- >>> From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Bert Wijnen >>> (IETF) >>> Sent: 07 August 2015 19:46 >>> To: Benoit Claise; supa@ietf.org >>> Cc: Eggert, Lars; ibnemo@ietf.org >>> Subject: Re: [Supa] SUPA charter proposal >>> >>> Hi Benoit and others. >>> >>> So would this work prevent the formation of a WG that would do >>> IBNEMO (Intent >>> Based NEtwork MOdeling) >>> work? I certainly hope not. In the charter you have: >>> >>> (iii) the working group will investigate the practically of >>> building >> policy rules >>> that declaratively >>> specify what goals to achieve (this is often called >> "intent-based" policy) but >>> not how to achieve >>> those goals and may create a model accordingly. >>> >>> >>> IBNEMO intends (no pun intended) to define/standardize a Intent >>> expression >>> language. >>> The work you describe above can be input to the work IBNEMO wants to >>> do. >>> >>> Bert >>> >>> On 07/08/15 18:03, Benoit Claise wrote: >>>> Dear all, >>>> >>>> As promised in my last email ("SUPA: Situation Summary and Next >>>> Steps"), >> here >>> is a proposed charter. >>>> Thanks to Robert Sparks, Adrian Farrel, and Dan Romascanu. >>>> >>>> Hopefully, this new version will clarify the situation, and will be >> acceptable to >>> everybody. >>>> Please let us know. Note: I prefer to keep the edit token from now. >>>> >>>> Regards, Benoit (OPS AD) >>>> >>>> >>> ============================================================== >>>> SUPA CHARTER PROPOSAL (2015-08-07) >>>> >>>> Policy is an important configurable component in the delivery of >>>> services >> and >>> the operation of networks. Operators want and need >>>> to be able to determine the policies that apply to their different >>>> customers >> and >>> to the equipment that comprises their physical >>>> and virtual networks. As policy spans such a wide range of services >>>> and >> device >>> types, it will be helpful if there is a common way >>>> of expressing and describing policies that is uniform and >>>> consistent in all >>> environments. Such an approach will help to avoid >>>> configuration errors that arise from confusion between different >>>> systems, >> will >>> enable easy understanding of policies that apply in >>>> different environments, will make the implementation of >>>> policy-based systems >>> quicker and cheaper, and will facilitate the rapid >>>> development of standards-based data models that include policy >>>> elements. >>>> >>>> SUPA (Simplified Use of Policy Abstractions) defines a model to >>>> interface >> with a >>> network management function (within a controller, >>>> an orchestrator, a network element) that takes high-level, possibly >>>> network- >>> wide policies as input. SUPA will not define what the >>>> function does with that input but anticipates that it will >>>> ultimately result >> in >>> network configuration changes >>>> Practically, SUPA will define generic YANG data models to encode >>>> policy, >> which >>> can point to device-, technology-, and >>>> service-specific YANG models of other working groups. >>>> >>>> SUPA will be designed to work with device, protocol, network, and >>>> service >> data >>> models. >>>> The SUPA working group will develop a model for expressing policy at >> different >>> levels of abstraction.Specifically, three model >>>> fragments are envisioned: (i) a generic model that defines concepts >>>> and >>> vocabulary needed by policy management independent of the >>>> form and content of the policy, (ii) a more specific model that >>>> refines the >>> generic model to specify how to build policy rules of >>>> the event-condition-action paradigm, and (iii) the working group will >> investigate >>> the practically of building policy rules that >>>> declaratively specify what goals to achieve (this is often called >> "intent-based" >>> policy) but not how to achieve those goals and >>>> may create a model accordingly. >>>> >>>> If the working group finds it necessary to work on an information >>>> model >> before >>> the data model, to help provide guidance and derive >>>> the data models, it might do so. The working group will decide >>>> later whether >>> the information model needs to be published as an RFC. >>>> Out of scope of this working group is: >>>> >>>> -The specification of a new policy language. The YANG data models >>>> are to be >>> used with protocols such as NETCONF/RESTCONF. >>>> -Design of protocol-specific policies and specific design for embedded >> policies in >>> network elements (which are usually interpreted >>>> in isolation, and often at timescales that require optimization for >>>> specific >>> purposes). >>>> -Specific handling of policies (although the application document will >> provide >>> some examples), and therefore the specification of >>>> a policy engine that maps a specific policy instance to actual >>>> configuration >>> snippets. >>>> List of work items: >>>> >>>> 1) A document that explains the scope of the policy-based management >>> framework and how it relates to existing work of the IETF. >>>> 2) If the working group considers it necessary, an information model >> composed >>> of policy concepts and vocabulary. >>>> 3) A set of YANG data models consisting of a base policy model for >> representing >>> policy management concepts independent of the type >>>> or structure of a policy, plus an extension for defining policy rules >> according to >>> the event-condition-action paradigm. Another >>>> extension for defining policy rules according to a declarative, or >> intent-based, >>> paradigm, may be produced. These models will be >>>> designed to be generic and extensible. >>>> >>>> 4) An applicability document providing a few examples that >>>> demonstrate how >>> the generic policy models can be used to express >>>> policies that are relevant for network operators. The examples may >>>> tie into >>> configuration models or network service models >>>> developed by other working groups. >>>> >>>> The working group will decide how the work items are best mapped into >>> deliverables. >>>> This working group will be a success when the SUPA policy >>>> constructs are re- >>> used in future IETF specifications (and, ideally, >>>> specifications from other SDOs), in a manner that will save >>>> development time >>> and avoid inconsistencies between data models >>>> developed by different working groups. In the meantime, SUPA should >>>> not >>> impede work in other working groups while waiting for SUPA >>>> to produce its deliverables. >>>> >>>> The working group will communicate with other SDOs (MEF, TMF, ETSI) >>>> that are >>> working on related issues. >>>> Milestones: >>>> >>>> TBD >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Supa mailing list >>>> Supa@ietf.org >>>> https://www.ietf.org/mailman/listinfo/supa >>> _______________________________________________ >>> Supa mailing list >>> Supa@ietf.org >>> https://www.ietf.org/mailman/listinfo/supa >> _______________________________________________ >> Supa mailing list >> Supa@ietf.org >> https://www.ietf.org/mailman/listinfo/supa >> > > . > --------------080509030504060703000408 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Bert, all,

In-line.
Hi Adrian, inline

On 09/08/15 17:23, Adrian Farrel wrote:
Hi Bert,

I don't think you are reading the proposed charter for SUPA right if you think
it precludes the formation of a working group for IBNEMO. Rather, the text that
Benoit has published says that SUPA is not the working group that works on
IBNEMO.
OK, that was certainly not so clear to me.
See in the charter " Out of scope of this working group is:   The specification of a new policy language"
Thanks for clarifying this. I am still abit worried about
the text:

               (iii) the working group will investigate the practically of
        building policy rules that declaratively specify what goals to achieve
        (this is often called "intent-based" policy) but not how to achieve
        those goals and may create a model accordingly.

So what does that last piece of the sentence "and may create a model accordingly" mean then?
"will investigate" and "may create a model accordingly" are carefully written to stress the experimental aspect of the intent-based. See my previous email "SUPA: Situation Summary and Next Steps"
But maybe you are saying that the intent-based part of the SUAP charter could be
lifted out and placed in an IBNEMO work effort. That might be reasonable.
I think that makes sense to me too. But maybe we need more discussion on this.
In fact, Intent Based Network Modeling has already quite some traction (including code) in
Open Daylight projects. So they are quite active already in that space.
Standardizing a language to express intent seems something that a WG in IETF could very well
work on, actually pretty soon.  AS we discussued in our barbof in Prague.
I shared my views on IB-NEMO during the barbof...

Regards, Benoit
However, there is a separation between the use of existing data modeling and
protocols (such as YANG with NETCONF) and the development of a new and
specialised modeling language and communication protocol. I believe that this
charter text opens up the investigation of the practicalities of intent-based
policy modeling in order to determine whether such things could be modeled in
existing languages or whether new work is needed a priori.
In fact, in IBNEMO we realize that we need to use (or define maybe) some YANG data models
that would allow us to translate "intent expressions" into actual network-wide, conroller-wide
or device-specific data models. We would use any existing data models if at laa possibl.
But we do need some data models in order to prove that our expression language can work and
be implemented in interoperable code.

If, for example, it was possible to encode intent-based policy in YANG, that
would not preclude IBNEMO inventing something different/better/worse.
RIght, but my personal preference would be to try and see if we can use existing YANG data models
Now there it seems sensible that SUPA should bundle all of the thought around
policy models in one place as a starting point. If it is later desirable to
split off the intent-based part (say after the initial investigation and
information models) that doesn't seem like a bad thing.
Could be I guess
Alternatively, if there is a strong pull to move all of the intent-based work
out from day one, I will not be complaining.
And I think some of that work has already started, although still at an indiviadual-draft level.

Bert
Cheers,
Adrian

-----Original Message-----
From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Bert Wijnen (IETF)
Sent: 07 August 2015 19:46
To: Benoit Claise; supa@ietf.org
Cc: Eggert, Lars; ibnemo@ietf.org
Subject: Re: [Supa] SUPA charter proposal

Hi Benoit and others.

So would this work prevent the formation of a WG that would do IBNEMO (Intent
Based NEtwork MOdeling)
work? I certainly hope not. In the charter you have:

        (iii) the working group will investigate the practically of building
policy rules
that declaratively
              specify what goals to achieve (this is often called
"intent-based" policy) but
not how to achieve
              those goals and may create a model accordingly.


IBNEMO intends (no pun intended) to define/standardize a Intent expression
language.
The work you describe above can be input to the work IBNEMO wants to do.

Bert

On 07/08/15 18:03, Benoit Claise wrote:
Dear all,

As promised in my last email ("SUPA: Situation Summary and Next Steps"),
here
is a proposed charter.
Thanks to Robert Sparks, Adrian Farrel, and Dan Romascanu.

Hopefully, this new version will clarify the situation, and will be
acceptable to
everybody.
Please let us know. Note: I prefer to keep the edit token from now.

Regards, Benoit (OPS AD)


==============================================================
SUPA CHARTER PROPOSAL (2015-08-07)

Policy is an important configurable component in the delivery of services
and
the operation of networks. Operators want and need
to be able to determine the policies that apply to their different customers
and
to the equipment that comprises their physical
and virtual networks. As policy spans such a wide range of services and
device
types, it will be helpful if there is a common way
of expressing and describing policies that is uniform and consistent in all
environments. Such an approach will help to avoid
configuration errors that arise from confusion between different systems,
will
enable easy understanding of policies that apply in
different environments, will make the implementation of policy-based systems
quicker and cheaper, and will facilitate the rapid
development of standards-based data models that include policy elements.

SUPA (Simplified Use of Policy Abstractions) defines a model to interface
with a
network management function (within a controller,
an orchestrator, a network element) that takes high-level, possibly network-
wide policies as input. SUPA will not define what the
function does with that input but anticipates that it will ultimately result
in
network configuration changes
Practically, SUPA will define generic YANG data models to encode policy,
which
can point to device-, technology-, and
service-specific YANG models of other working groups.

SUPA will be designed to work with device, protocol, network, and service
data
models.
The SUPA working group will develop a model for expressing policy at
different
levels of abstraction.Specifically, three model
fragments are envisioned: (i) a generic model that defines concepts and
vocabulary needed by policy management independent of the
form and content of the policy, (ii) a more specific model that refines the
generic model to specify how to build policy rules of
the event-condition-action paradigm, and (iii) the working group will
investigate
the practically of building policy rules that
declaratively specify what goals to achieve (this is often called
"intent-based"
policy) but not how to achieve those goals and
may create a model accordingly.

If the working group finds it necessary to work on an information model
before
the data model, to help provide guidance and derive
the data models, it might do so. The working group will decide later whether
the information model needs to be published as an RFC.
Out of scope of this working group is:

-The specification of a new policy language. The YANG data models are to be
used with protocols such as NETCONF/RESTCONF.
-Design of protocol-specific policies and specific design for embedded
policies in
network elements (which are usually interpreted
in isolation, and often at timescales that require optimization for specific
purposes).
-Specific handling of policies (although the application document will
provide
some examples), and therefore the specification of
a policy engine that maps a specific policy instance to actual configuration
snippets.
List of work items:

1) A document that explains the scope of the policy-based management
framework and how it relates to existing work of the IETF.
2) If the working group considers it necessary, an information model
composed
of policy concepts and vocabulary.
3) A set of YANG data models consisting of a base policy model for
representing
policy management concepts independent of the type
or structure of a policy, plus an extension for defining policy rules
according to
the event-condition-action paradigm. Another
extension for defining policy rules according to a declarative, or
intent-based,
paradigm, may be produced. These models will be
designed to be generic and extensible.

4) An applicability document providing a few examples that demonstrate how
the generic policy models can be used to express
policies that are relevant for network operators. The examples may tie into
configuration models or network service models
developed by other working groups.

The working group will decide how the work items are best mapped into
deliverables.
This working group will be a success when the SUPA policy constructs are re-
used in future IETF specifications (and, ideally,
specifications from other SDOs), in a manner that will save development time
and avoid inconsistencies between data models
developed by different working groups. In the meantime, SUPA should not
impede work in other working groups while waiting for SUPA
to produce its deliverables.

The working group will communicate with other SDOs (MEF, TMF, ETSI) that are
working on related issues.
Milestones:

TBD




_______________________________________________
Supa mailing list
Supa@ietf.org
https://www.ietf.org/mailman/listinfo/supa
_______________________________________________
Supa mailing list
Supa@ietf.org
https://www.ietf.org/mailman/listinfo/supa
_______________________________________________
Supa mailing list
Supa@ietf.org
https://www.ietf.org/mailman/listinfo/supa


.


--------------080509030504060703000408-- From nobody Wed Aug 12 13:38:33 2015 Return-Path: X-Original-To: ibnemo@ietfa.amsl.com Delivered-To: ibnemo@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F251ACD9D; Wed, 12 Aug 2015 13:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_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 hspv90qQtjMA; Wed, 12 Aug 2015 13:38:27 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0629.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:629]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCFB91ACD9C; Wed, 12 Aug 2015 13:38:26 -0700 (PDT) Received: from CY1PR09MB0922.namprd09.prod.outlook.com (10.163.89.140) by CY1PR09MB0922.namprd09.prod.outlook.com (10.163.89.140) with Microsoft SMTP Server (TLS) id 15.1.231.21; Wed, 12 Aug 2015 20:38:06 +0000 Received: from CY1PR09MB0922.namprd09.prod.outlook.com ([10.163.89.140]) by CY1PR09MB0922.namprd09.prod.outlook.com ([10.163.89.140]) with mapi id 15.01.0231.021; Wed, 12 Aug 2015 20:38:06 +0000 From: "Natale, Bob" To: Benoit Claise , "adrian@olddog.co.uk" , "'Bert Wijnen (IETF)'" , "supa@ietf.org" Thread-Topic: [Supa] SUPA charter proposal Thread-Index: AQHQ1TxmI7+foo+wEkiAc/waHC23UJ4I0R9w Date: Wed, 12 Aug 2015 20:38:06 +0000 Message-ID: References: <55C4D6C1.5040504@cisco.com> <55C4FCFE.8070701@bwijnen.net> <023101d0d2b7$54dad4e0$fe907ea0$@olddog.co.uk> <55CB609C.8040406@cisco.com> In-Reply-To: <55CB609C.8040406@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=RNATALE@mitre.org; x-originating-ip: [192.80.55.87] x-microsoft-exchange-diagnostics: 1; CY1PR09MB0922; 5:TzoFi/Yy61Jnt4RmTTwJITtZnWV+uxO1iYtLtPtAgAeji/mRZNXfcOeT7iG+6bfeP0LTSAD2XYSwZug1u8579vBDxwE/2hLaZ8cz6opGYAB+aey6CciJEhQxBp2dmovgoctMwbXaW5kLgVDfqvj/3A==; 24:LYUeSwN2DoO/edSuqeeahD3D+QUoW0J2y1P1rSOj0MesX++JlvKH7w3NwiqGS+sBooJzvgWEemx9gSEQQ0uSQ3w0S1k3xOQqJ6D/J67nS20=; 20:eXEmPt5aeNwAbLl/uUZVIZl829g+IL0QPADOztj2xoa+PKrD8iZ8w335RvIo+N84IxtGIu9Xwu4NsDjlWl6ikA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0922; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CY1PR09MB0922; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0922; x-forefront-prvs: 0666E15D35 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(13464003)(24454002)(479174004)(55674003)(199003)(189002)(377424004)(377454003)(97736004)(77156002)(62966003)(5001830100001)(74316001)(81156007)(561944003)(40100003)(33656002)(5002640100001)(122556002)(64706001)(2900100001)(92566002)(4001540100001)(101416001)(66066001)(76576001)(10400500002)(5003600100002)(5001860100001)(19580405001)(5001770100001)(2950100001)(77096005)(102836002)(19580395003)(68736005)(15975445007)(50986999)(5001960100002)(99286002)(86362001)(106116001)(105586002)(189998001)(93886004)(2501003)(76176999)(54356999)(2656002)(106356001)(46102003)(87936001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR09MB0922; H:CY1PR09MB0922.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: mitre.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: mitre.org X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Aug 2015 20:38:06.2094 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0922 Archived-At: Cc: "'Eggert, Lars'" , "ibnemo@ietf.org" Subject: Re: [Ibnemo] [Supa] SUPA charter proposal X-BeenThere: ibnemo@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of Nemo, an intent-based North Bound \(NB\) interface consisting of an application protocol running over HTTP \(RESTful interfaces\) to exchange intent-based primitives between applications and meta-controllers controlling virtual network resources \(networks, storage, CPU\)." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 20:38:30 -0000 +1 from me on this point from Adrian's message below* in particular: "SUPA = should bundle all of the thought around policy models in one place as a sta= rting point". Fragmentation of PBNM solutions has resulted from the lack of standardizati= on in the face of significant need ... the need is only growing as the requ= irements intended to be satisfied by the emerging technologies supporting n= etwork services virtualization (among many other drivers) raise the urgency= of governed automation ... this is an opportunity for the IETF to restart = in this challenging area (PBNM) and SUPA is a promising locus for the start= ing point (IMHO). [* - Taken a little out of context, it's true ... but only a little. :)] Avanti, BobN -----Original Message----- From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Benoit Claise Sent: Wednesday, August 12, 2015 11:05 AM To: adrian@olddog.co.uk; 'Bert Wijnen (IETF)' ; supa@ie= tf.org Cc: 'Eggert, Lars' ; ibnemo@ietf.org Subject: Re: [Supa] SUPA charter proposal +1 to what Adrian wrote. Regards, B. > Hi Bert, > > I don't think you are reading the proposed charter for SUPA right if=20 > you think it precludes the formation of a working group for IBNEMO.=20 > Rather, the text that Benoit has published says that SUPA is not the=20 > working group that works on IBNEMO. > > But maybe you are saying that the intent-based part of the SUAP=20 > charter could be lifted out and placed in an IBNEMO work effort. That mig= ht be reasonable. > > However, there is a separation between the use of existing data=20 > modeling and protocols (such as YANG with NETCONF) and the development=20 > of a new and specialised modeling language and communication protocol.=20 > I believe that this charter text opens up the investigation of the=20 > practicalities of intent-based policy modeling in order to determine=20 > whether such things could be modeled in existing languages or whether new= work is needed a priori. > > If, for example, it was possible to encode intent-based policy in=20 > YANG, that would not preclude IBNEMO inventing something different/better= /worse. > > Now there it seems sensible that SUPA should bundle all of the thought=20 > around policy models in one place as a starting point. If it is later=20 > desirable to split off the intent-based part (say after the initial=20 > investigation and information models) that doesn't seem like a bad thing. > > Alternatively, if there is a strong pull to move all of the=20 > intent-based work out from day one, I will not be complaining. > > Cheers, > Adrian > >> -----Original Message----- >> From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Bert Wijnen=20 >> (IETF) >> Sent: 07 August 2015 19:46 >> To: Benoit Claise; supa@ietf.org >> Cc: Eggert, Lars; ibnemo@ietf.org >> Subject: Re: [Supa] SUPA charter proposal >> >> Hi Benoit and others. >> >> So would this work prevent the formation of a WG that would do IBNEMO=20 >> (Intent Based NEtwork MOdeling) work? I certainly hope not. In the=20 >> charter you have: >> >> (iii) the working group will investigate the practically of=20 >> building > policy rules >> that declaratively >> specify what goals to achieve (this is often called > "intent-based" policy) but >> not how to achieve >> those goals and may create a model accordingly. >> >> >> IBNEMO intends (no pun intended) to define/standardize a Intent=20 >> expression language. >> The work you describe above can be input to the work IBNEMO wants to do. >> >> Bert >> >> On 07/08/15 18:03, Benoit Claise wrote: >>> Dear all, >>> >>> As promised in my last email ("SUPA: Situation Summary and Next=20 >>> Steps"), > here >> is a proposed charter. >>> Thanks to Robert Sparks, Adrian Farrel, and Dan Romascanu. >>> >>> Hopefully, this new version will clarify the situation, and will be > acceptable to >> everybody. >>> Please let us know. Note: I prefer to keep the edit token from now. >>> >>> Regards, Benoit (OPS AD) >>> >>> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> SUPA CHARTER PROPOSAL (2015-08-07) >>> >>> Policy is an important configurable component in the delivery of=20 >>> services > and >> the operation of networks. Operators want and need >>> to be able to determine the policies that apply to their different=20 >>> customers > and >> to the equipment that comprises their physical >>> and virtual networks. As policy spans such a wide range of services=20 >>> and > device >> types, it will be helpful if there is a common way >>> of expressing and describing policies that is uniform and consistent=20 >>> in all >> environments. Such an approach will help to avoid >>> configuration errors that arise from confusion between different=20 >>> systems, > will >> enable easy understanding of policies that apply in >>> different environments, will make the implementation of policy-based=20 >>> systems >> quicker and cheaper, and will facilitate the rapid >>> development of standards-based data models that include policy elements= . >>> >>> SUPA (Simplified Use of Policy Abstractions) defines a model to=20 >>> interface > with a >> network management function (within a controller, >>> an orchestrator, a network element) that takes high-level, possibly=20 >>> network- >> wide policies as input. SUPA will not define what the >>> function does with that input but anticipates that it will=20 >>> ultimately result > in >> network configuration changes >>> Practically, SUPA will define generic YANG data models to encode=20 >>> policy, > which >> can point to device-, technology-, and >>> service-specific YANG models of other working groups. >>> >>> SUPA will be designed to work with device, protocol, network, and=20 >>> service > data >> models. >>> The SUPA working group will develop a model for expressing policy at > different >> levels of abstraction.Specifically, three model >>> fragments are envisioned: (i) a generic model that defines concepts=20 >>> and >> vocabulary needed by policy management independent of the >>> form and content of the policy, (ii) a more specific model that=20 >>> refines the >> generic model to specify how to build policy rules of >>> the event-condition-action paradigm, and (iii) the working group=20 >>> will > investigate >> the practically of building policy rules that >>> declaratively specify what goals to achieve (this is often called > "intent-based" >> policy) but not how to achieve those goals and >>> may create a model accordingly. >>> >>> If the working group finds it necessary to work on an information=20 >>> model > before >> the data model, to help provide guidance and derive >>> the data models, it might do so. The working group will decide later=20 >>> whether >> the information model needs to be published as an RFC. >>> Out of scope of this working group is: >>> >>> -The specification of a new policy language. The YANG data models=20 >>> are to be >> used with protocols such as NETCONF/RESTCONF. >>> -Design of protocol-specific policies and specific design for=20 >>> embedded > policies in >> network elements (which are usually interpreted >>> in isolation, and often at timescales that require optimization for=20 >>> specific >> purposes). >>> -Specific handling of policies (although the application document=20 >>> will > provide >> some examples), and therefore the specification of >>> a policy engine that maps a specific policy instance to actual=20 >>> configuration >> snippets. >>> List of work items: >>> >>> 1) A document that explains the scope of the policy-based management >> framework and how it relates to existing work of the IETF. >>> 2) If the working group considers it necessary, an information model > composed >> of policy concepts and vocabulary. >>> 3) A set of YANG data models consisting of a base policy model for > representing >> policy management concepts independent of the type >>> or structure of a policy, plus an extension for defining policy=20 >>> rules > according to >> the event-condition-action paradigm. Another >>> extension for defining policy rules according to a declarative, or > intent-based, >> paradigm, may be produced. These models will be >>> designed to be generic and extensible. >>> >>> 4) An applicability document providing a few examples that=20 >>> demonstrate how >> the generic policy models can be used to express >>> policies that are relevant for network operators. The examples may=20 >>> tie into >> configuration models or network service models >>> developed by other working groups. >>> >>> The working group will decide how the work items are best mapped=20 >>> into >> deliverables. >>> This working group will be a success when the SUPA policy constructs=20 >>> are re- >> used in future IETF specifications (and, ideally, >>> specifications from other SDOs), in a manner that will save=20 >>> development time >> and avoid inconsistencies between data models >>> developed by different working groups. In the meantime, SUPA should=20 >>> not >> impede work in other working groups while waiting for SUPA >>> to produce its deliverables. >>> >>> The working group will communicate with other SDOs (MEF, TMF, ETSI)=20 >>> that are >> working on related issues. >>> Milestones: >>> >>> TBD >>> >>> >>> >>> >>> _______________________________________________ >>> Supa mailing list >>> Supa@ietf.org >>> https://www.ietf.org/mailman/listinfo/supa >> _______________________________________________ >> Supa mailing list >> Supa@ietf.org >> https://www.ietf.org/mailman/listinfo/supa > . > _______________________________________________ Supa mailing list Supa@ietf.org https://www.ietf.org/mailman/listinfo/supa From nobody Wed Aug 12 14:36:01 2015 Return-Path: X-Original-To: ibnemo@ietfa.amsl.com Delivered-To: ibnemo@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1FD61ACE18; Wed, 12 Aug 2015 14:35:58 -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 jfVvaKWXVK5I; Wed, 12 Aug 2015 14:35:52 -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 CAB9B1ACE1A; Wed, 12 Aug 2015 14:35:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWE42302; Wed, 12 Aug 2015 21:35:48 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.218.25.35) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 12 Aug 2015 22:35:47 +0100 Received: from SJCEML703-CHM.china.huawei.com ([169.254.5.51]) by SJCEML702-CHM.china.huawei.com ([169.254.4.184]) with mapi id 14.03.0235.001; Wed, 12 Aug 2015 14:35:41 -0700 From: John Strassner To: Susan Hares , "'John Strassner'" , "'Bert Wijnen (IETF)'" Thread-Topic: [Supa] [Ibnemo] SUPA charter proposal Thread-Index: AQHQ07pQMEIVSerHeU6KkRv6MCfmK54I5gqg Date: Wed, 12 Aug 2015 21:35:40 +0000 Message-ID: References: <55C4D6C1.5040504@cisco.com> <55C4FCFE.8070701@bwijnen.net> <023101d0d2b7$54dad4e0$fe907ea0$@olddog.co.uk> <55C7C4E6.9020003@bwijnen.net> <000801d0d3ba$42fb07f0$c8f117d0$@ndzh.com> In-Reply-To: <000801d0d3ba$42fb07f0$c8f117d0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.34.129] Content-Type: multipart/alternative; boundary="_000_B818037A70EDCC4A86113DA25EC020982012EBB0SJCEML703CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: 'Adrian Farrel' , "'Eggert, Lars'" , "ibnemo@ietf.org" , "supa@ietf.org" Subject: Re: [Ibnemo] [Supa] SUPA charter proposal X-BeenThere: ibnemo@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of Nemo, an intent-based North Bound \(NB\) interface consisting of an application protocol running over HTTP \(RESTful interfaces\) to exchange intent-based primitives between applications and meta-controllers controlling virtual network resources \(networks, storage, CPU\)." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 21:35:58 -0000 --_000_B818037A70EDCC4A86113DA25EC020982012EBB0SJCEML703CHMchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TGV0J3MgYWdyZWUgdG8gZGlzYWdyZWUuIFJFU1QgZGVmaW5lcyBGT1VSIGNvbW1hbmRzIGFuZCBh IHBhcnRpY3VsYXIgYXJjaGl0ZWN0dXJhbCBhcHByb2FjaDsgSSBzZWUgTkVNTyByZWRlZmluaW5n IGJvdGggYXNwZWN0cyBvZiB0aGlzLg0KDQpGcm9tOiBTdXBhIFttYWlsdG86c3VwYS1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU3VzYW4gSGFyZXMNClNlbnQ6IE1vbmRheSwgQXVndXN0 IDEwLCAyMDE1IDM6MTcgUE0NClRvOiAnSm9obiBTdHJhc3NuZXInOyAnQmVydCBXaWpuZW4gKElF VEYpJw0KQ2M6ICdBZHJpYW4gRmFycmVsJzsgJ0VnZ2VydCwgTGFycyc7IGlibmVtb0BpZXRmLm9y Zzsgc3VwYUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtTdXBhXSBbSWJuZW1vXSBTVVBBIGNoYXJ0 ZXIgcHJvcG9zYWwNCg0KSm9objoNCg0KVG8gcmVzcG9uZCB0byB0aGUgZm9sbG93aW5nIHBhcnQg b2YgeW91ciBkaXNjdXNzaW9uIHdpdGggQmVydDoNCg0KPGpjcz4NCldoYXQgbWFrZXMgbWUgc2F5 IHNvIGlzIGEgY29tYmluYXRpb24gb2YNCg0KMSkgICAgICBsaXN0ZW5pbmcgdG8gcHJldmlvdXMg TkVNTyBwcmVzZW50YXRpb25zIGluIG90aGVyIGZvcnVtDQo8c3VlPg0KSeKAmW0gZ2xhZCB5b3Xi gJl2ZSBsaXN0ZW4gdG8gTmVtbyBwcmVzZW50YXRpb25zIGF0IG90aGVyIGZvcnVtcw0KPC9zdWU+ DQoNCiAgMikgdmFyaW91cyBzZW50ZW5jZXMgaW4gdGhlIElCTkVNTyBCYXIgQm9GIHByZXNlbnRh dGlvbg0KICAgICAgKGUuZy4sICJRdWVzdGlvbjogc2NyaXB0cyBvdmVyIGh0dHAgd29ya2FibGUs IE5vdCBzdXJlDQogICAgICAgUkVTVENPTkYgcnBjICsgcHViLnN1YiBsZXZlbCBuZWVkZWQiLA0K PHN1ZT4NCkl0IGlzIHRoaXMgc3RhdGVtZW50IHRoYXQgQmVydCBpcyBhbGx1ZGluZyB0by4gIFdl IGFyZSBvcGVuIHRvIHVzaW5nIGEgdHJhbnNwb3J0IG1lY2hhbmlzbSBmcm9tIGh0dHAsIG9yIFJF U1RDT05GIHdpdGggdmFyaW91cyBmb3JtcyB0byBjYXJyeSB0aGUgTmVtbyBjb21tYW5kcy4NCjwv c3VlPg0KDQogIDMpIFN0YXRlbWVudHMgc3VjaCBhcyAiU3luZXJnaXN0aWMgbWVhbnMgdGhhdCBz dW0gb2YgSW50ZW50IEJhc2VkDQogICAgICBORU1PIHByb3RvY29sICsgTkVUQ09ORiArIFJFU1RD T05GICsgSTJSUyArUENFIGlzIG1vcmUNCiAgICAgIHRoYW4gYW55IG9mIHRoZSBwYXJ0cyBhbG9u ZSIgYW5kICJjcmVhdGluZyBwcm90b2NvbCB3aXRoIG1pbmltYWwNCiAgICAgIG9wZXJhdGlvbnMg Zm9yIHRvIGV4cHJlc3MgaW50ZW50IGZyb20gdGhlIGFwcGxpY2F0aW9uIHRvIHRoZSBuZXR3b3Jr Ii4NCiAgICAgIGJvdGggZnJvbSBkcmFmdC1oYXJlcy1pYm5lbW8tb3ZlcnZpZXctMDENCg0KPHN1 ZT46IFRoZSBrZXkgcG9pbnQgaGVyZSBpcyB0aGUgTmVtbyBjb21tYW5kcyAoY29ubmVjdGlvbiwg cGx1cyBsYW5ndWFnZSBjb21tYW5kcyBlbmFibGUgdGhlIHVzZXIgdG8gYXNrIGZvciBjb25uZWN0 aW9uIHdpdGggZWFzeSBodW1hbiBsYW5ndWFnZSBmb3IgdGhlIGVuZC11c2VyLg0KPC9zdWU+DQoN CiAgNCkgYSBtYWlsIGZyb20gU3VlIG9uIDcvMTcgdG8gdGhlIE5FTU8gYW5kIFNVUEEgbGlzdHMs IHRoYXQgc2FpZA0KICAgICAgIklCTmVtb+KAmXMgMTUgc3BlY2lmaWMgY29tbWFuZHMgYXJlIGJl dHRlciB0aGFuIE5FVENPTkYNCiAgICAgICAgb3IgUkVTVENPTkYgY29tbWFuZHMiDQpJIGNhbiBn aXZlIHlvdSBtYW55IG1vcmUgZXhhbXBsZXMuLi4NCg0KPHN1ZT4gVGhlIHJlYXNvbiB0aGVzZSAx NSBjb21tYW5kcyBhcmUgYmV0dGVyIGlzIHRoYXQgdGhlc2UgY29tbWFuZHMgYXJlIHRhcmdldGVk IHRoZSBlbmQtdXNlciBmb3IgbmV0d29yay13aWRlIGNvbW1hbmRzLiAgVGhlIE5ldGNvbmYvcmVz dGNvbmYgY29tbWFuZHMgYXJlIGZvY3VzZWQgYXQgdGhlIGRldmljZSBsZXZlbC4NCjwvc3VlPg0K PC9qY3M+DQoNCg0KDQoNCkZyb206IElibmVtbyBbbWFpbHRvOmlibmVtby1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgSm9obiBTdHJhc3NuZXINClNlbnQ6IFN1bmRheSwgQXVndXN0IDA5 LCAyMDE1IDU6NTkgUE0NClRvOiBCZXJ0IFdpam5lbiAoSUVURikNCkNjOiBBZHJpYW4gRmFycmVs OyBFZ2dlcnQsIExhcnM7IGlibmVtb0BpZXRmLm9yZzsgc3VwYUBpZXRmLm9yZw0KU3ViamVjdDog UmU6IFtJYm5lbW9dIFtTdXBhXSBTVVBBIGNoYXJ0ZXIgcHJvcG9zYWwNCg0KQmVydCwNCg0KcGxl YXNlIHNlZSBpbmxpbmUuDQoNCkluIGFkZGl0aW9uLCB0aGVyZSBhcmUgZGlzdGluY3QgZGlmZmVy ZW5jZXMgYmV0d2VlbiBTVVBBIGFuZCBORU1POg0KDQo+PiAgMSkgU1VQQSBkZWZpbmVzIE5FVENP TkYgb3IgUkVTVENPTkYgYXMgaXRzIHByb3RvY29sLiBQZXJpb2QuDQo+PiAgSW4gY29udHJhc3Qs IE5FTU8gd2FudHMgdG8gZGVmaW5lIGEgbmV3IHByb3RvY29sLg0KDQo+IEkgZG8gbm90IGtub3cg d2hhdCBtYWtlcyB5b3Ugc2F5IHNvLg0KPiBJIHRoaW5rIHdlIGhhdmUgbGVmdCBpdCBvcGVuIHNv ZmFyIGFzIHRvIHdoZXRoZXIgd2Ugd2FudC9uZWVkIGEgbmV3DQo+IHByb3RvY29sIG9yIG5vdC4N Cj4gUHJlZmVyYWJseSB3ZSBjYW4gdXNlIE5ldGNvbmYvUmVzdGNvbmYuIEJ1dCBJIHRoaW5rIHRo YXQgaXMgYWxsIHN0aWxsDQo+IG9wZW4gdG8gZGlzY3Vzc2lvbi4NCg0KPGpjcz4NCldoYXQgbWFr ZXMgbWUgc2F5IHNvIGlzIGEgY29tYmluYXRpb24gb2YNCiAgMSkgbGlzdGVuaW5nIHRvIHByZXZp b3VzIE5FTU8gcHJlc2VudGF0aW9ucyBpbiBvdGhlciBmb3JhDQogIDIpIHZhcmlvdXMgc2VudGVu Y2VzIGluIHRoZSBJQk5FTU8gQmFyIEJvRiBwcmVzZW50YXRpb24NCiAgICAgIChlLmcuLCAiUXVl c3Rpb246IHNjcmlwdHMgb3ZlciBodHRwIHdvcmthYmxlLCBOb3Qgc3VyZQ0KICAgICAgIFJFU1RD T05GIHJwYyArIHB1Yi5zdWIgbGV2ZWwgbmVlZGVkIiwNCiAgMykgU3RhdGVtZW50cyBzdWNoIGFz ICJTeW5lcmdpc3RpYyBtZWFucyB0aGF0IHN1bSBvZiBJbnRlbnQgQmFzZWQNCiAgICAgIE5FTU8g cHJvdG9jb2wgKyBORVRDT05GICsgUkVTVENPTkYgKyBJMlJTICtQQ0UgaXMgbW9yZQ0KICAgICAg dGhhbiBhbnkgb2YgdGhlIHBhcnRzIGFsb25lIiBhbmQgImNyZWF0aW5nIHByb3RvY29sIHdpdGgg bWluaW1hbA0KICAgICAgb3BlcmF0aW9ucyBmb3IgdG8gZXhwcmVzcyBpbnRlbnQgZnJvbSB0aGUg YXBwbGljYXRpb24gdG8gdGhlIG5ldHdvcmsiLg0KICAgICAgYm90aCBmcm9tIGRyYWZ0LWhhcmVz LWlibmVtby1vdmVydmlldy0wMQ0KICA0KSBhIG1haWwgZnJvbSBTdWUgb24gNy8xNyB0byB0aGUg TkVNTyBhbmQgU1VQQSBsaXN0cywgdGhhdCBzYWlkDQogICAgICAiSUJOZW1v4oCZcyAxNSBzcGVj aWZpYyBjb21tYW5kcyBhcmUgYmV0dGVyIHRoYW4gTkVUQ09ORg0KICAgICAgICBvciBSRVNUQ09O RiBjb21tYW5kcyINCkkgY2FuIGdpdmUgeW91IG1hbnkgbW9yZSBleGFtcGxlcy4uLg0KPC9qY3M+ DQoNCj4+IDIpIFNVUEEgZGVmaW5lcyBpbnRlbnQgYXMgZGVjbGFyYXRpdmUgbG9naWMsIGFuZCB0 aHVzIGltcGxlbWVudHMNCj4+IGl0IHVzaW5nIGVpdGhlciBwcm9wb3NpdGlvbmFsIG9yIGZpcnN0 IG9yZGVyIGxvZ2ljIChzZWUgc2VjdGlvbiAzLjIuNC4sDQo+PiBNYXRoZW1hdGljYWwgTG9naWMg VGVybWlub2xvZ3ksIG9mIGRyYWZ0LXN0cmFzc25lci1zdXBhLWdlbmVyaWMtDQo+PiBwb2xpY3kt aW5mby1tb2RlbCkuIEluIGNvbnRyYXN0LCBORU1PIGRlZmluZXMgaW1wbGVtZW50cyBpdHMNCj4+ IGludGVudCBwb2xpY3kgdXNpbmcgY29uZGl0aW9uLWFjdGlvbiAoaW1wZXJhdGl2ZSkgbG9naWMu DQoNCj4gQWdhaW4gSSBkbyBub3QgdW5kZXJzdGFuZCB3aHkgeW91IHRoaW5rIHNvLg0KPiBJIGhh dmUgbm90IHNlZW4gYW55IEVDQSBzdHVmZiBpbiBJQk5FTU8geWV0Lg0KPiBCdXQgdGhlbiwgbWF5 YmUgeW91IGNhbiBwb2ludCBtZSB0byBpdCBpZiB5b3UgaGF2ZS4NCg0KPGpjcz4NCkkgc2FpZCAi Y29uZGl0aW9uLWFjdGlvbiIsIE5PVCBFQ0EuDQpQbGVhc2UgbG9vayBhdCBkcmFmdC14aWEtc2Ru cmctbmVtby1sYW5ndWFnZS0wMiwgd2hpY2ggc2F5czoNCiJBbGwgdGhlIHBvbGljaWVzIGZvbGxv dyB0aGUgc2FtZSBwYXR0ZXJuICJ3aGVuIDxjb25kaXRpb24+LCB0bw0KZXhlY3V0ZSA8YWN0aW9u Piwgd2l0aCA8Y29uc3RyYWludD4iLCBhbmQgY2FuIGJlIGFwcGxpZWQgdG8gYW55IGVudGl0eS4i DQo8L2pjcz4NCg0KT24gU3VuLCBBdWcgOSwgMjAxNSBhdCAyOjIzIFBNLCBCZXJ0IFdpam5lbiAo SUVURikgPGJ3aWV0ZkBid2lqbmVuLm5ldDxtYWlsdG86YndpZXRmQGJ3aWpuZW4ubmV0Pj4gd3Jv dGU6DQpKb2huLCBJbmxpbmUsDQoNCk9uIDA5LzA4LzE1IDIyOjMwLCBKb2huIFN0cmFzc25lciB3 cm90ZToNCkhpIEFkcmlhbiwNCg0KSSBhbHNvIGRvIG5vdCB0aGluayB0aGF0IHRoZXJlIGlzIGFu eSBvdmVybGFwIGJldHdlZW4gd2hhdCBTVVBBIGhhcyBkZWZpbmVkDQphbmQgd2hhdCBORU1PIGhh cyBkZWZpbmVkLiBTVVBBIHByb3ZpZGVzIGEgY29tbW9uIG1vZGVsIGZvcg0KZXhwcmVzc2luZyBp bXBlcmF0aXZlIChlLmcuLCBldmVudC1jb25kaXRpb24tYWN0aW9uLCBvciBFQ0EpIGFuZCBkZWNs YXJhdGl2ZQ0KKGUuZy4sIGdvYWwtYmFzZWQsIG9yICJpbnRlbnQiKSBwb2xpY2llcy4gU1VQQSBw cm9wb3NlcyB0aGF0IGVhY2ggb2YgdGhlc2UNCnJlcHJlc2VudGF0aW9ucyBhcmUgcmVhbGl6ZWQg YXMgc2VwYXJhdGUgbW9kZWxzLCBidXQgYXJlIHJlbGF0ZWQgdGhyb3VnaA0KdGhlaXIgImNvbW1v biBhbmNlc3RyeSIgKGkuZS4sIHRoZXkgd2VyZSBib3RoIGRlcml2ZWQgZnJvbSB0aGUgc2FtZQ0K c3VwZXJzdHJ1Y3R1cmUpLiBUaGlzIG1lYW5zIHRoYXQgZWFjaCBjYW4gdXNlIHRoZSBvdGhlci4N Ck9LLCB0aGF0IHNvdW5kcyBnb29kIHRvIG1lLg0KSW4gYWRkaXRpb24sIHRoZXJlIGFyZSBkaXN0 aW5jdCBkaWZmZXJlbmNlcyBiZXR3ZWVuIFNVUEEgYW5kIE5FTU86DQoNCiAgMSkgU1VQQSBkZWZp bmVzIE5FVENPTkYgb3IgUkVTVENPTkYgYXMgaXRzIHByb3RvY29sLiBQZXJpb2QuIEluDQogICAg ICBjb250cmFzdCwgTkVNTyB3YW50cyB0byBkZWZpbmUgYSBuZXcgcHJvdG9jb2wuDQpJIGRvIG5v dCBrbm93IHdoYXQgbWFrZXMgeW91IHNheSBzby4NCkkgdGhpbmsgd2UgaGF2ZSBsZWZ0IGl0IG9w ZW4gc29mYXIgYXMgdG8gd2hldGhlciB3ZSB3YW50L25lZWQgYSBuZXcgcHJvdG9jb2wgb3Igbm90 Lg0KUHJlZmVyYWJseSB3ZSBjYW4gdXNlIE5ldGNvbmYvUmVzdGNvbmYuIEJ1dCBJIHRoaW5rIHRo YXQgaXMgYWxsIHN0aWxsIG9wZW4gdG8gZGlzY3Vzc2lvbi4NCiAgMikgU1VQQSBkZWZpbmVzIGlu dGVudCBhcyBkZWNsYXJhdGl2ZSBsb2dpYywgYW5kIHRodXMgaW1wbGVtZW50cyBpdA0KICAgICAg dXNpbmcgZWl0aGVyIHByb3Bvc2l0aW9uYWwgb3IgZmlyc3Qgb3JkZXIgbG9naWMgKHNlZSBzZWN0 aW9uIDMuMi40LiwNCiAgICAgIE1hdGhlbWF0aWNhbCBMb2dpYyBUZXJtaW5vbG9neSwgb2YgZHJh ZnQtc3RyYXNzbmVyLXN1cGEtZ2VuZXJpYy0NCiAgICAgIHBvbGljeS1pbmZvLW1vZGVsKS4gSW4g Y29udHJhc3QsIE5FTU8gZGVmaW5lcyBpbXBsZW1lbnRzIGl0cw0KICAgICAgaW50ZW50IHBvbGlj eSB1c2luZyBjb25kaXRpb24tYWN0aW9uIChpbXBlcmF0aXZlKSBsb2dpYy4NCkFnYWluIEkgZG8g bm90IHVuZGVyc3RhbmQgd2h5IHlvdSB0aGluayBzby4NCkkgaGF2ZSBub3Qgc2VlbiBhbnkgRUNB IHN0dWZmIGluIElCTkVNTyB5ZXQuDQpCdXQgdGhlbiwgbWF5YmUgeW91IGNhbiBwb2ludCBtZSB0 byBpdCBpZiB5b3UgaGF2ZS4NCiAzKSBTVVBBIGlzIE5PVCB3b3JraW5nIG9uIGEgbGFuZ3VhZ2Uu IEluIGNvbnRyYXN0LCBORU1PIGlzIHdvcmtpbmcNCiAgICAgb24gYSBsYW5ndWFnZS4NClllcCwg d2Ugd291bGQgbGlrZSB0byB3b3JrIG9uIGFuICJpbnRlbnQgZXhwcmVzc2lvbiBsYW5ndWFnZSIg aW4gSUJORU1PLg0KDQpCZXJ0DQoNCnJlZ2FyZHMsDQpKb2huDQoNCk9uIFN1biwgQXVnIDksIDIw MTUgYXQgODoyMyBBTSwgQWRyaWFuIEZhcnJlbCA8YWRyaWFuQG9sZGRvZy5jby51azxtYWlsdG86 YWRyaWFuQG9sZGRvZy5jby51az4gPG1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrPG1haWx0bzph ZHJpYW5Ab2xkZG9nLmNvLnVrPj4+IHdyb3RlOg0KDQogICAgSGkgQmVydCwNCg0KICAgIEkgZG9u J3QgdGhpbmsgeW91IGFyZSByZWFkaW5nIHRoZSBwcm9wb3NlZCBjaGFydGVyIGZvciBTVVBBIHJp Z2h0IGlmIHlvdSB0aGluaw0KICAgIGl0IHByZWNsdWRlcyB0aGUgZm9ybWF0aW9uIG9mIGEgd29y a2luZyBncm91cCBmb3IgSUJORU1PLiBSYXRoZXIsIHRoZSB0ZXh0IHRoYXQNCiAgICBCZW5vaXQg aGFzIHB1Ymxpc2hlZCBzYXlzIHRoYXQgU1VQQSBpcyBub3QgdGhlIHdvcmtpbmcgZ3JvdXAgdGhh dCB3b3JrcyBvbg0KICAgIElCTkVNTy4NCg0KICAgIEJ1dCBtYXliZSB5b3UgYXJlIHNheWluZyB0 aGF0IHRoZSBpbnRlbnQtYmFzZWQgcGFydCBvZiB0aGUgU1VBUCBjaGFydGVyIGNvdWxkIGJlDQog ICAgbGlmdGVkIG91dCBhbmQgcGxhY2VkIGluIGFuIElCTkVNTyB3b3JrIGVmZm9ydC4gVGhhdCBt aWdodCBiZSByZWFzb25hYmxlLg0KDQogICAgSG93ZXZlciwgdGhlcmUgaXMgYSBzZXBhcmF0aW9u IGJldHdlZW4gdGhlIHVzZSBvZiBleGlzdGluZyBkYXRhIG1vZGVsaW5nIGFuZA0KICAgIHByb3Rv Y29scyAoc3VjaCBhcyBZQU5HIHdpdGggTkVUQ09ORikgYW5kIHRoZSBkZXZlbG9wbWVudCBvZiBh IG5ldyBhbmQNCiAgICBzcGVjaWFsaXNlZCBtb2RlbGluZyBsYW5ndWFnZSBhbmQgY29tbXVuaWNh dGlvbiBwcm90b2NvbC4gSSBiZWxpZXZlIHRoYXQgdGhpcw0KICAgIGNoYXJ0ZXIgdGV4dCBvcGVu cyB1cCB0aGUgaW52ZXN0aWdhdGlvbiBvZiB0aGUgcHJhY3RpY2FsaXRpZXMgb2YgaW50ZW50LWJh c2VkDQogICAgcG9saWN5IG1vZGVsaW5nIGluIG9yZGVyIHRvIGRldGVybWluZSB3aGV0aGVyIHN1 Y2ggdGhpbmdzIGNvdWxkIGJlIG1vZGVsZWQgaW4NCiAgICBleGlzdGluZyBsYW5ndWFnZXMgb3Ig d2hldGhlciBuZXcgd29yayBpcyBuZWVkZWQgYSBwcmlvcmkuDQoNCiAgICBJZiwgZm9yIGV4YW1w bGUsIGl0IHdhcyBwb3NzaWJsZSB0byBlbmNvZGUgaW50ZW50LWJhc2VkIHBvbGljeSBpbiBZQU5H LCB0aGF0DQogICAgd291bGQgbm90IHByZWNsdWRlIElCTkVNTyBpbnZlbnRpbmcgc29tZXRoaW5n IGRpZmZlcmVudC9iZXR0ZXIvd29yc2UuDQoNCiAgICBOb3cgdGhlcmUgaXQgc2VlbXMgc2Vuc2li bGUgdGhhdCBTVVBBIHNob3VsZCBidW5kbGUgYWxsIG9mIHRoZSB0aG91Z2h0IGFyb3VuZA0KICAg IHBvbGljeSBtb2RlbHMgaW4gb25lIHBsYWNlIGFzIGEgc3RhcnRpbmcgcG9pbnQuIElmIGl0IGlz IGxhdGVyIGRlc2lyYWJsZSB0bw0KICAgIHNwbGl0IG9mZiB0aGUgaW50ZW50LWJhc2VkIHBhcnQg KHNheSBhZnRlciB0aGUgaW5pdGlhbCBpbnZlc3RpZ2F0aW9uIGFuZA0KICAgIGluZm9ybWF0aW9u IG1vZGVscykgdGhhdCBkb2Vzbid0IHNlZW0gbGlrZSBhIGJhZCB0aGluZy4NCg0KICAgIEFsdGVy bmF0aXZlbHksIGlmIHRoZXJlIGlzIGEgc3Ryb25nIHB1bGwgdG8gbW92ZSBhbGwgb2YgdGhlIGlu dGVudC1iYXNlZCB3b3JrDQogICAgb3V0IGZyb20gZGF5IG9uZSwgSSB3aWxsIG5vdCBiZSBjb21w bGFpbmluZy4NCg0KICAgIENoZWVycywNCiAgICBBZHJpYW4NCg0KICAgID4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCiAgICA+IEZyb206IFN1cGEgW21haWx0bzpzdXBhLWJvdW5jZXNAaWV0 Zi5vcmc8bWFpbHRvOnN1cGEtYm91bmNlc0BpZXRmLm9yZz4gPG1haWx0bzpzdXBhLWJvdW5jZXNA aWV0Zi5vcmc8bWFpbHRvOnN1cGEtYm91bmNlc0BpZXRmLm9yZz4+XSBPbiBCZWhhbGYgT2YgQmVy dCBXaWpuZW4gKElFVEYpDQogICAgPiBTZW50OiAwNyBBdWd1c3QgMjAxNSAxOTo0Ng0KICAgID4g VG86IEJlbm9pdCBDbGFpc2U7IHN1cGFAaWV0Zi5vcmc8bWFpbHRvOnN1cGFAaWV0Zi5vcmc+IDxt YWlsdG86c3VwYUBpZXRmLm9yZzxtYWlsdG86c3VwYUBpZXRmLm9yZz4+DQogICAgPiBDYzogRWdn ZXJ0LCBMYXJzOyBpYm5lbW9AaWV0Zi5vcmc8bWFpbHRvOmlibmVtb0BpZXRmLm9yZz4gPG1haWx0 bzppYm5lbW9AaWV0Zi5vcmc8bWFpbHRvOmlibmVtb0BpZXRmLm9yZz4+DQogICAgPiBTdWJqZWN0 OiBSZTogW1N1cGFdIFNVUEEgY2hhcnRlciBwcm9wb3NhbA0KICAgID4NCiAgICA+IEhpIEJlbm9p dCBhbmQgb3RoZXJzLg0KICAgID4NCiAgICA+IFNvIHdvdWxkIHRoaXMgd29yayBwcmV2ZW50IHRo ZSBmb3JtYXRpb24gb2YgYSBXRyB0aGF0IHdvdWxkIGRvIElCTkVNTyAoSW50ZW50DQogICAgPiBC YXNlZCBORXR3b3JrIE1PZGVsaW5nKQ0KICAgID4gd29yaz8gSSBjZXJ0YWlubHkgaG9wZSBub3Qu IEluIHRoZSBjaGFydGVyIHlvdSBoYXZlOg0KICAgID4NCiAgICA+ICAgICAgICAoaWlpKSB0aGUg d29ya2luZyBncm91cCB3aWxsIGludmVzdGlnYXRlIHRoZSBwcmFjdGljYWxseSBvZiBidWlsZGlu Zw0KICAgIHBvbGljeSBydWxlcw0KICAgID4gdGhhdCBkZWNsYXJhdGl2ZWx5DQogICAgPiAgICAg ICAgICAgICAgc3BlY2lmeSB3aGF0IGdvYWxzIHRvIGFjaGlldmUgKHRoaXMgaXMgb2Z0ZW4gY2Fs bGVkDQogICAgImludGVudC1iYXNlZCIgcG9saWN5KSBidXQNCiAgICA+IG5vdCBob3cgdG8gYWNo aWV2ZQ0KICAgID4gICAgICAgICAgICAgIHRob3NlIGdvYWxzIGFuZCBtYXkgY3JlYXRlIGEgbW9k ZWwgYWNjb3JkaW5nbHkuDQogICAgPg0KICAgID4NCiAgICA+IElCTkVNTyBpbnRlbmRzIChubyBw dW4gaW50ZW5kZWQpIHRvIGRlZmluZS9zdGFuZGFyZGl6ZSBhIEludGVudCBleHByZXNzaW9uDQog ICAgPiBsYW5ndWFnZS4NCiAgICA+IFRoZSB3b3JrIHlvdSBkZXNjcmliZSBhYm92ZSBjYW4gYmUg aW5wdXQgdG8gdGhlIHdvcmsgSUJORU1PIHdhbnRzIHRvIGRvLg0KICAgID4NCiAgICA+IEJlcnQN CiAgICA+DQogICAgPiBPbiAwNy8wOC8xNSAxODowMywgQmVub2l0IENsYWlzZSB3cm90ZToNCiAg ICA+ID4gRGVhciBhbGwsDQogICAgPiA+DQogICAgPiA+IEFzIHByb21pc2VkIGluIG15IGxhc3Qg ZW1haWwgKCJTVVBBOiBTaXR1YXRpb24gU3VtbWFyeSBhbmQgTmV4dCBTdGVwcyIpLA0KICAgIGhl cmUNCiAgICA+IGlzIGEgcHJvcG9zZWQgY2hhcnRlci4NCiAgICA+ID4gVGhhbmtzIHRvIFJvYmVy dCBTcGFya3MsIEFkcmlhbiBGYXJyZWwsIGFuZCBEYW4gUm9tYXNjYW51Lg0KICAgID4gPg0KICAg ID4gPiBIb3BlZnVsbHksIHRoaXMgbmV3IHZlcnNpb24gd2lsbCBjbGFyaWZ5IHRoZSBzaXR1YXRp b24sIGFuZCB3aWxsIGJlDQogICAgYWNjZXB0YWJsZSB0bw0KICAgID4gZXZlcnlib2R5Lg0KICAg ID4gPiBQbGVhc2UgbGV0IHVzIGtub3cuIE5vdGU6IEkgcHJlZmVyIHRvIGtlZXAgdGhlIGVkaXQg dG9rZW4gZnJvbSBub3cuDQogICAgPiA+DQogICAgPiA+IFJlZ2FyZHMsIEJlbm9pdCAoT1BTIEFE KQ0KICAgID4gPg0KICAgID4gPg0KICAgID4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiAgICA+ID4NCiAgICA+ID4gU1VQQSBD SEFSVEVSIFBST1BPU0FMICgyMDE1LTA4LTA3KQ0KICAgID4gPg0KICAgID4gPiBQb2xpY3kgaXMg YW4gaW1wb3J0YW50IGNvbmZpZ3VyYWJsZSBjb21wb25lbnQgaW4gdGhlIGRlbGl2ZXJ5IG9mIHNl cnZpY2VzDQogICAgYW5kDQogICAgPiB0aGUgb3BlcmF0aW9uIG9mIG5ldHdvcmtzLiBPcGVyYXRv cnMgd2FudCBhbmQgbmVlZA0KICAgID4gPiB0byBiZSBhYmxlIHRvIGRldGVybWluZSB0aGUgcG9s aWNpZXMgdGhhdCBhcHBseSB0byB0aGVpciBkaWZmZXJlbnQgY3VzdG9tZXJzDQogICAgYW5kDQog ICAgPiB0byB0aGUgZXF1aXBtZW50IHRoYXQgY29tcHJpc2VzIHRoZWlyIHBoeXNpY2FsDQogICAg PiA+IGFuZCB2aXJ0dWFsIG5ldHdvcmtzLiBBcyBwb2xpY3kgc3BhbnMgc3VjaCBhIHdpZGUgcmFu Z2Ugb2Ygc2VydmljZXMgYW5kDQogICAgZGV2aWNlDQogICAgPiB0eXBlcywgaXQgd2lsbCBiZSBo ZWxwZnVsIGlmIHRoZXJlIGlzIGEgY29tbW9uIHdheQ0KICAgID4gPiBvZiBleHByZXNzaW5nIGFu ZCBkZXNjcmliaW5nIHBvbGljaWVzIHRoYXQgaXMgdW5pZm9ybSBhbmQgY29uc2lzdGVudCBpbiBh bGwNCiAgICA+IGVudmlyb25tZW50cy4gU3VjaCBhbiBhcHByb2FjaCB3aWxsIGhlbHAgdG8gYXZv aWQNCiAgICA+ID4gY29uZmlndXJhdGlvbiBlcnJvcnMgdGhhdCBhcmlzZSBmcm9tIGNvbmZ1c2lv biBiZXR3ZWVuIGRpZmZlcmVudCBzeXN0ZW1zLA0KICAgIHdpbGwNCiAgICA+IGVuYWJsZSBlYXN5 IHVuZGVyc3RhbmRpbmcgb2YgcG9saWNpZXMgdGhhdCBhcHBseSBpbg0KICAgID4gPiBkaWZmZXJl bnQgZW52aXJvbm1lbnRzLCB3aWxsIG1ha2UgdGhlIGltcGxlbWVudGF0aW9uIG9mIHBvbGljeS1i YXNlZCBzeXN0ZW1zDQogICAgPiBxdWlja2VyIGFuZCBjaGVhcGVyLCBhbmQgd2lsbCBmYWNpbGl0 YXRlIHRoZSByYXBpZA0KICAgID4gPiBkZXZlbG9wbWVudCBvZiBzdGFuZGFyZHMtYmFzZWQgZGF0 YSBtb2RlbHMgdGhhdCBpbmNsdWRlIHBvbGljeSBlbGVtZW50cy4NCiAgICA+ID4NCiAgICA+ID4g U1VQQSAoU2ltcGxpZmllZCBVc2Ugb2YgUG9saWN5IEFic3RyYWN0aW9ucykgZGVmaW5lcyBhIG1v ZGVsIHRvIGludGVyZmFjZQ0KICAgIHdpdGggYQ0KICAgID4gbmV0d29yayBtYW5hZ2VtZW50IGZ1 bmN0aW9uICh3aXRoaW4gYSBjb250cm9sbGVyLA0KICAgID4gPiBhbiBvcmNoZXN0cmF0b3IsIGEg bmV0d29yayBlbGVtZW50KSB0aGF0IHRha2VzIGhpZ2gtbGV2ZWwsIHBvc3NpYmx5IG5ldHdvcmst DQogICAgPiB3aWRlIHBvbGljaWVzIGFzIGlucHV0LiBTVVBBIHdpbGwgbm90IGRlZmluZSB3aGF0 IHRoZQ0KICAgID4gPiBmdW5jdGlvbiBkb2VzIHdpdGggdGhhdCBpbnB1dCBidXQgYW50aWNpcGF0 ZXMgdGhhdCBpdCB3aWxsIHVsdGltYXRlbHkgcmVzdWx0DQogICAgaW4NCiAgICA+IG5ldHdvcmsg Y29uZmlndXJhdGlvbiBjaGFuZ2VzDQogICAgPiA+DQogICAgPiA+IFByYWN0aWNhbGx5LCBTVVBB IHdpbGwgZGVmaW5lIGdlbmVyaWMgWUFORyBkYXRhIG1vZGVscyB0byBlbmNvZGUgcG9saWN5LA0K ICAgIHdoaWNoDQogICAgPiBjYW4gcG9pbnQgdG8gZGV2aWNlLSwgdGVjaG5vbG9neS0sIGFuZA0K ICAgID4gPiBzZXJ2aWNlLXNwZWNpZmljIFlBTkcgbW9kZWxzIG9mIG90aGVyIHdvcmtpbmcgZ3Jv dXBzLg0KICAgID4gPg0KICAgID4gPiBTVVBBIHdpbGwgYmUgZGVzaWduZWQgdG8gd29yayB3aXRo IGRldmljZSwgcHJvdG9jb2wsIG5ldHdvcmssIGFuZCBzZXJ2aWNlDQogICAgZGF0YQ0KICAgID4g bW9kZWxzLg0KICAgID4gPg0KICAgID4gPiBUaGUgU1VQQSB3b3JraW5nIGdyb3VwIHdpbGwgZGV2 ZWxvcCBhIG1vZGVsIGZvciBleHByZXNzaW5nIHBvbGljeSBhdA0KICAgIGRpZmZlcmVudA0KICAg ID4gbGV2ZWxzIG9mIGFic3RyYWN0aW9uLlNwZWNpZmljYWxseSwgdGhyZWUgbW9kZWwNCiAgICA+ ID4gZnJhZ21lbnRzIGFyZSBlbnZpc2lvbmVkOiAoaSkgYSBnZW5lcmljIG1vZGVsIHRoYXQgZGVm aW5lcyBjb25jZXB0cyBhbmQNCiAgICA+IHZvY2FidWxhcnkgbmVlZGVkIGJ5IHBvbGljeSBtYW5h Z2VtZW50IGluZGVwZW5kZW50IG9mIHRoZQ0KICAgID4gPiBmb3JtIGFuZCBjb250ZW50IG9mIHRo ZSBwb2xpY3ksIChpaSkgYSBtb3JlIHNwZWNpZmljIG1vZGVsIHRoYXQgcmVmaW5lcyB0aGUNCiAg ICA+IGdlbmVyaWMgbW9kZWwgdG8gc3BlY2lmeSBob3cgdG8gYnVpbGQgcG9saWN5IHJ1bGVzIG9m DQogICAgPiA+IHRoZSBldmVudC1jb25kaXRpb24tYWN0aW9uIHBhcmFkaWdtLCBhbmQgKGlpaSkg dGhlIHdvcmtpbmcgZ3JvdXAgd2lsbA0KICAgIGludmVzdGlnYXRlDQogICAgPiB0aGUgcHJhY3Rp Y2FsbHkgb2YgYnVpbGRpbmcgcG9saWN5IHJ1bGVzIHRoYXQNCiAgICA+ID4gZGVjbGFyYXRpdmVs eSBzcGVjaWZ5IHdoYXQgZ29hbHMgdG8gYWNoaWV2ZSAodGhpcyBpcyBvZnRlbiBjYWxsZWQNCiAg ICAiaW50ZW50LWJhc2VkIg0KICAgID4gcG9saWN5KSBidXQgbm90IGhvdyB0byBhY2hpZXZlIHRo b3NlIGdvYWxzIGFuZA0KICAgID4gPiBtYXkgY3JlYXRlIGEgbW9kZWwgYWNjb3JkaW5nbHkuDQog ICAgPiA+DQogICAgPiA+IElmIHRoZSB3b3JraW5nIGdyb3VwIGZpbmRzIGl0IG5lY2Vzc2FyeSB0 byB3b3JrIG9uIGFuIGluZm9ybWF0aW9uIG1vZGVsDQogICAgYmVmb3JlDQogICAgPiB0aGUgZGF0 YSBtb2RlbCwgdG8gaGVscCBwcm92aWRlIGd1aWRhbmNlIGFuZCBkZXJpdmUNCiAgICA+ID4gdGhl IGRhdGEgbW9kZWxzLCBpdCBtaWdodCBkbyBzby4gVGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBkZWNp ZGUgbGF0ZXIgd2hldGhlcg0KICAgID4gdGhlIGluZm9ybWF0aW9uIG1vZGVsIG5lZWRzIHRvIGJl IHB1Ymxpc2hlZCBhcyBhbiBSRkMuDQogICAgPiA+DQogICAgPiA+IE91dCBvZiBzY29wZSBvZiB0 aGlzIHdvcmtpbmcgZ3JvdXAgaXM6DQogICAgPiA+DQogICAgPiA+IC1UaGUgc3BlY2lmaWNhdGlv biBvZiBhIG5ldyBwb2xpY3kgbGFuZ3VhZ2UuIFRoZSBZQU5HIGRhdGEgbW9kZWxzIGFyZSB0byBi ZQ0KICAgID4gdXNlZCB3aXRoIHByb3RvY29scyBzdWNoIGFzIE5FVENPTkYvUkVTVENPTkYuDQog ICAgPiA+DQogICAgPiA+IC1EZXNpZ24gb2YgcHJvdG9jb2wtc3BlY2lmaWMgcG9saWNpZXMgYW5k IHNwZWNpZmljIGRlc2lnbiBmb3IgZW1iZWRkZWQNCiAgICBwb2xpY2llcyBpbg0KICAgID4gbmV0 d29yayBlbGVtZW50cyAod2hpY2ggYXJlIHVzdWFsbHkgaW50ZXJwcmV0ZWQNCiAgICA+ID4gaW4g aXNvbGF0aW9uLCBhbmQgb2Z0ZW4gYXQgdGltZXNjYWxlcyB0aGF0IHJlcXVpcmUgb3B0aW1pemF0 aW9uIGZvciBzcGVjaWZpYw0KICAgID4gcHVycG9zZXMpLg0KICAgID4gPg0KICAgID4gPiAtU3Bl Y2lmaWMgaGFuZGxpbmcgb2YgcG9saWNpZXMgKGFsdGhvdWdoIHRoZSBhcHBsaWNhdGlvbiBkb2N1 bWVudCB3aWxsDQogICAgcHJvdmlkZQ0KICAgID4gc29tZSBleGFtcGxlcyksIGFuZCB0aGVyZWZv cmUgdGhlIHNwZWNpZmljYXRpb24gb2YNCiAgICA+ID4gYSBwb2xpY3kgZW5naW5lIHRoYXQgbWFw cyBhIHNwZWNpZmljIHBvbGljeSBpbnN0YW5jZSB0byBhY3R1YWwgY29uZmlndXJhdGlvbg0KICAg ID4gc25pcHBldHMuDQogICAgPiA+DQogICAgPiA+IExpc3Qgb2Ygd29yayBpdGVtczoNCiAgICA+ ID4NCiAgICA+ID4gMSkgQSBkb2N1bWVudCB0aGF0IGV4cGxhaW5zIHRoZSBzY29wZSBvZiB0aGUg cG9saWN5LWJhc2VkIG1hbmFnZW1lbnQNCiAgICA+IGZyYW1ld29yayBhbmQgaG93IGl0IHJlbGF0 ZXMgdG8gZXhpc3Rpbmcgd29yayBvZiB0aGUgSUVURi4NCiAgICA+ID4NCiAgICA+ID4gMikgSWYg dGhlIHdvcmtpbmcgZ3JvdXAgY29uc2lkZXJzIGl0IG5lY2Vzc2FyeSwgYW4gaW5mb3JtYXRpb24g bW9kZWwNCiAgICBjb21wb3NlZA0KICAgID4gb2YgcG9saWN5IGNvbmNlcHRzIGFuZCB2b2NhYnVs YXJ5Lg0KICAgID4gPg0KICAgID4gPiAzKSBBIHNldCBvZiBZQU5HIGRhdGEgbW9kZWxzIGNvbnNp c3Rpbmcgb2YgYSBiYXNlIHBvbGljeSBtb2RlbCBmb3INCiAgICByZXByZXNlbnRpbmcNCiAgICA+ IHBvbGljeSBtYW5hZ2VtZW50IGNvbmNlcHRzIGluZGVwZW5kZW50IG9mIHRoZSB0eXBlDQogICAg PiA+IG9yIHN0cnVjdHVyZSBvZiBhIHBvbGljeSwgcGx1cyBhbiBleHRlbnNpb24gZm9yIGRlZmlu aW5nIHBvbGljeSBydWxlcw0KICAgIGFjY29yZGluZyB0bw0KICAgID4gdGhlIGV2ZW50LWNvbmRp dGlvbi1hY3Rpb24gcGFyYWRpZ20uIEFub3RoZXINCiAgICA+ID4gZXh0ZW5zaW9uIGZvciBkZWZp bmluZyBwb2xpY3kgcnVsZXMgYWNjb3JkaW5nIHRvIGEgZGVjbGFyYXRpdmUsIG9yDQogICAgaW50 ZW50LWJhc2VkLA0KICAgID4gcGFyYWRpZ20sIG1heSBiZSBwcm9kdWNlZC4gVGhlc2UgbW9kZWxz IHdpbGwgYmUNCiAgICA+ID4gZGVzaWduZWQgdG8gYmUgZ2VuZXJpYyBhbmQgZXh0ZW5zaWJsZS4N CiAgICA+ID4NCiAgICA+ID4gNCkgQW4gYXBwbGljYWJpbGl0eSBkb2N1bWVudCBwcm92aWRpbmcg YSBmZXcgZXhhbXBsZXMgdGhhdCBkZW1vbnN0cmF0ZSBob3cNCiAgICA+IHRoZSBnZW5lcmljIHBv bGljeSBtb2RlbHMgY2FuIGJlIHVzZWQgdG8gZXhwcmVzcw0KICAgID4gPiBwb2xpY2llcyB0aGF0 IGFyZSByZWxldmFudCBmb3IgbmV0d29yayBvcGVyYXRvcnMuIFRoZSBleGFtcGxlcyBtYXkgdGll IGludG8NCiAgICA+IGNvbmZpZ3VyYXRpb24gbW9kZWxzIG9yIG5ldHdvcmsgc2VydmljZSBtb2Rl bHMNCiAgICA+ID4gZGV2ZWxvcGVkIGJ5IG90aGVyIHdvcmtpbmcgZ3JvdXBzLg0KICAgID4gPg0K ICAgID4gPiBUaGUgd29ya2luZyBncm91cCB3aWxsIGRlY2lkZSBob3cgdGhlIHdvcmsgaXRlbXMg YXJlIGJlc3QgbWFwcGVkIGludG8NCiAgICA+IGRlbGl2ZXJhYmxlcy4NCiAgICA+ID4NCiAgICA+ ID4gVGhpcyB3b3JraW5nIGdyb3VwIHdpbGwgYmUgYSBzdWNjZXNzIHdoZW4gdGhlIFNVUEEgcG9s aWN5IGNvbnN0cnVjdHMgYXJlIHJlLQ0KICAgID4gdXNlZCBpbiBmdXR1cmUgSUVURiBzcGVjaWZp Y2F0aW9ucyAoYW5kLCBpZGVhbGx5LA0KICAgID4gPiBzcGVjaWZpY2F0aW9ucyBmcm9tIG90aGVy IFNET3MpLCBpbiBhIG1hbm5lciB0aGF0IHdpbGwgc2F2ZSBkZXZlbG9wbWVudCB0aW1lDQogICAg PiBhbmQgYXZvaWQgaW5jb25zaXN0ZW5jaWVzIGJldHdlZW4gZGF0YSBtb2RlbHMNCiAgICA+ID4g ZGV2ZWxvcGVkIGJ5IGRpZmZlcmVudCB3b3JraW5nIGdyb3Vwcy4gSW4gdGhlIG1lYW50aW1lLCBT VVBBIHNob3VsZCBub3QNCiAgICA+IGltcGVkZSB3b3JrIGluIG90aGVyIHdvcmtpbmcgZ3JvdXBz IHdoaWxlIHdhaXRpbmcgZm9yIFNVUEENCiAgICA+ID4gdG8gcHJvZHVjZSBpdHMgZGVsaXZlcmFi bGVzLg0KICAgID4gPg0KICAgID4gPiBUaGUgd29ya2luZyBncm91cCB3aWxsIGNvbW11bmljYXRl IHdpdGggb3RoZXIgU0RPcyAoTUVGLCBUTUYsIEVUU0kpIHRoYXQgYXJlDQogICAgPiB3b3JraW5n IG9uIHJlbGF0ZWQgaXNzdWVzLg0KICAgID4gPg0KICAgID4gPiBNaWxlc3RvbmVzOg0KICAgID4g Pg0KICAgID4gPiBUQkQNCiAgICA+ID4NCiAgICA+ID4NCiAgICA+ID4NCiAgICA+ID4NCiAgICA+ ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+ ID4gU3VwYSBtYWlsaW5nIGxpc3QNCiAgICA+ID4gU3VwYUBpZXRmLm9yZzxtYWlsdG86U3VwYUBp ZXRmLm9yZz4gPG1haWx0bzpTdXBhQGlldGYub3JnPG1haWx0bzpTdXBhQGlldGYub3JnPj4NCiAg ICA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdXBhDQogICAgPg0K ICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAg ICA+IFN1cGEgbWFpbGluZyBsaXN0DQogICAgPiBTdXBhQGlldGYub3JnPG1haWx0bzpTdXBhQGll dGYub3JnPiA8bWFpbHRvOlN1cGFAaWV0Zi5vcmc8bWFpbHRvOlN1cGFAaWV0Zi5vcmc+Pg0KICAg ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdXBhDQoNCiAgICBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIFN1cGEgbWFp bGluZyBsaXN0DQogICAgU3VwYUBpZXRmLm9yZzxtYWlsdG86U3VwYUBpZXRmLm9yZz4gPG1haWx0 bzpTdXBhQGlldGYub3JnPG1haWx0bzpTdXBhQGlldGYub3JnPj4NCiAgICBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N1cGENCg0KDQoNCg0KLS0NCnJlZ2FyZHMsDQpKb2hu DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClN1 cGEgbWFpbGluZyBsaXN0DQpTdXBhQGlldGYub3JnPG1haWx0bzpTdXBhQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdXBhDQoNCg0KDQoNCi0tDQpyZWdh cmRzLA0KSm9obg0K --_000_B818037A70EDCC4A86113DA25EC020982012EBB0SJCEML703CHMchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl Pg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIg MTEgNiA0IDMgNSA0IDQgMiA0O30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJh Z3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1l OmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K c3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30NCiAv KiBMaXN0IERlZmluaXRpb25zICovDQogQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NjQ4MjQzNDM3 Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNTU0Njkw ODc2IC0xNjY2NTI1NjA2IDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4 NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28t bGV2ZWwtdGV4dDoiJTFcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjI0LjBwdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFs cGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDo2MC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OnJpZ2h0Ow0KCW1hcmdpbi1sZWZ0Ojk2LjBwdDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxp c3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxMzIuMHB0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEt bG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjE2OC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30N CkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJp Z2h0Ow0KCW1hcmdpbi1sZWZ0OjIwNC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0 IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjQwLjBwdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxv d2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgltYXJnaW4tbGVmdDoyNzYuMHB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpA bGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdo dDsNCgltYXJnaW4tbGVmdDozMTIuMHB0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXtt YXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT4NCjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KIDxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCiAgPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQogPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+TGV0J3MgYWdyZWUgdG8gZGlzYWdyZWUu IFJFU1QgZGVmaW5lcyBGT1VSIGNvbW1hbmRzIGFuZCBhIHBhcnRpY3VsYXIgYXJjaGl0ZWN0dXJh bCBhcHByb2FjaDsgSSBzZWUgTkVNTyByZWRlZmluaW5nIGJvdGggYXNwZWN0cyBvZiB0aGlzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4gU3VwYSBbbWFpbHRvOnN1cGEtYm91bmNlc0BpZXRmLm9yZ10N CjxiPk9uIEJlaGFsZiBPZiA8L2I+U3VzYW4gSGFyZXM8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5 LCBBdWd1c3QgMTAsIDIwMTUgMzoxNyBQTTxicj4NCjxiPlRvOjwvYj4gJ0pvaG4gU3RyYXNzbmVy JzsgJ0JlcnQgV2lqbmVuIChJRVRGKSc8YnI+DQo8Yj5DYzo8L2I+ICdBZHJpYW4gRmFycmVsJzsg J0VnZ2VydCwgTGFycyc7IGlibmVtb0BpZXRmLm9yZzsgc3VwYUBpZXRmLm9yZzxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW1N1cGFdIFtJYm5lbW9dIFNVUEEgY2hhcnRlciBwcm9wb3NhbDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPkpvaG46DQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5UbyBy ZXNwb25kIHRvIHRoZSBmb2xsb3dpbmcgcGFydCBvZiB5b3VyIGRpc2N1c3Npb24gd2l0aCBCZXJ0 Og0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmx0O2pjcyZndDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXQgbWFrZXMgbWUgc2F5IHNvIGlzIGEgY29tYmluYXRp b24gb2Y8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MjQuMHB0O3RleHQtaW5kZW50Oi0uMjVpbjsNCm1zby1saXN0OmwwIGxldmVs MSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25v cmUiPjEpPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd Pmxpc3RlbmluZyB0byBwcmV2aW91cyBORU1PIHByZXNlbnRhdGlvbnMgaW4gb3RoZXIgZm9ydW0g PG86cD4NCjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZsdDtzdWUmZ3Q7IDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKAmW0gZ2xhZCB5b3XigJl2ZSBsaXN0 ZW4gdG8gTmVtbyBwcmVzZW50YXRpb25zIGF0IG90aGVyIGZvcnVtczxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmx0Oy9zdWUmZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsgMikgdmFyaW91cyBzZW50ZW5jZXMgaW4gdGhlIElCTkVNTyBCYXIgQm9GIHByZXNl bnRhdGlvbjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAoZS5nLiwgJnF1b3Q7 UXVlc3Rpb246IHNjcmlwdHMgb3ZlciBodHRwIHdvcmthYmxlLCBOb3Qgc3VyZTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFJFU1RDT05GIHJwYyAmIzQzOyBwdWIuc3ViIGxldmVsIG5lZWRlZCZxdW90Oyw8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZsdDtzdWUmZ3Q7IDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgaXMgdGhpcyBzdGF0ZW1lbnQgdGhhdCBCZXJ0 IGlzIGFsbHVkaW5nIHRvLiZuYnNwOyBXZSBhcmUgb3BlbiB0byB1c2luZyBhIHRyYW5zcG9ydCBt ZWNoYW5pc20gZnJvbSBodHRwLCBvciBSRVNUQ09ORiB3aXRoIHZhcmlvdXMgZm9ybXMgdG8gY2Fy cnkgdGhlIE5lbW8gY29tbWFuZHMuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jmx0Oy9zdWUmZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJz cDszKSBTdGF0ZW1lbnRzIHN1Y2ggYXMgJnF1b3Q7U3luZXJnaXN0aWMgbWVhbnMgdGhhdCBzdW0g b2YgSW50ZW50IEJhc2VkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTkVNTyBwcm90b2NvbCAmIzQzOyBORVRDT05GICYj NDM7IFJFU1RDT05GICYjNDM7IEkyUlMgJiM0MztQQ0UgaXMgbW9yZTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoYW4g YW55IG9mIHRoZSBwYXJ0cyBhbG9uZSZxdW90OyBhbmQgJnF1b3Q7Y3JlYXRpbmcgcHJvdG9jb2wg d2l0aCBtaW5pbWFsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb3BlcmF0aW9ucyBmb3IgdG8gZXhwcmVzcyBpbnRlbnQg ZnJvbSB0aGUgYXBwbGljYXRpb24gdG8gdGhlIG5ldHdvcmsmcXVvdDsuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYm90 aCBmcm9tIGRyYWZ0LWhhcmVzLWlibmVtby1vdmVydmlldy0wMTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbHQ7c3VlJmd0OzogVGhlIGtleSBwb2ludCBoZXJlIGlzIHRoZSBOZW1vIGNvbW1hbmRz IChjb25uZWN0aW9uLCBwbHVzIGxhbmd1YWdlIGNvbW1hbmRzIGVuYWJsZSB0aGUgdXNlciB0byBh c2sgZm9yIGNvbm5lY3Rpb24gd2l0aCBlYXN5IGh1bWFuIGxhbmd1YWdlIGZvciB0aGUgZW5kLXVz ZXIuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZsdDsvc3VlJmd0OyA8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IDQpIGEgbWFpbCBmcm9tIFN1ZSBvbiA3LzE3 IHRvIHRoZSBORU1PIGFuZCBTVVBBIGxpc3RzLCB0aGF0IHNhaWQ8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDs8 c3BhbiBzdHlsZT0iZm9udC1zaXplOg0KMTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JQk5lbW/igJlzIDE1 IHNwZWNpZmljIGNvbW1hbmRzIGFyZSBiZXR0ZXIgdGhhbiBORVRDT05GDQo8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7DQpjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgb3IgUkVTVENPTkYgY29tbWFuZHMmcXVvdDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzIy MjIyMiI+SSBjYW4gZ2l2ZSB5b3UgbWFueSBtb3JlIGV4YW1wbGVzLi4uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsN CmNvbG9yOiMyMjIyMjIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMjIyMjIyIj4mbHQ7 c3VlJmd0OyBUaGUgcmVhc29uIHRoZXNlIDE1IGNvbW1hbmRzIGFyZSBiZXR0ZXIgaXMgdGhhdCB0 aGVzZSBjb21tYW5kcyBhcmUgdGFyZ2V0ZWQgdGhlIGVuZC11c2VyIGZvciBuZXR3b3JrLXdpZGUg Y29tbWFuZHMuICZuYnNwO1RoZSBOZXRjb25mL3Jlc3Rjb25mIGNvbW1hbmRzIGFyZQ0KIGZvY3Vz ZWQgYXQgdGhlIGRldmljZSBsZXZlbC4gJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMyMjIy MjIiPiZsdDsvc3VlJmd0Ow0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jmx0Oy9qY3MmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+IElibmVtbyBbbWFpbHRvOmlibmVtby1ib3VuY2VzQGlldGYub3JnXQ0KPGI+ T24gQmVoYWxmIE9mIDwvYj5Kb2huIFN0cmFzc25lcjxicj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXks IEF1Z3VzdCAwOSwgMjAxNSA1OjU5IFBNPGJyPg0KPGI+VG86PC9iPiBCZXJ0IFdpam5lbiAoSUVU Rik8YnI+DQo8Yj5DYzo8L2I+IEFkcmlhbiBGYXJyZWw7IEVnZ2VydCwgTGFyczsgaWJuZW1vQGll dGYub3JnOyBzdXBhQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbSWJuZW1vXSBb U3VwYV0gU1VQQSBjaGFydGVyIHByb3Bvc2FsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkJlcnQsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPnBsZWFzZSBzZWUgaW5saW5lLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBhZGRpdGlvbiwgdGhlcmUgYXJl IGRpc3RpbmN0IGRpZmZlcmVuY2VzIGJldHdlZW4gU1VQQSBhbmQgTkVNTzo8YnI+DQo8YnI+DQom Z3Q7Jmd0OyZuYnNwOyAxKSBTVVBBIGRlZmluZXMgTkVUQ09ORiBvciBSRVNUQ09ORiBhcyBpdHMg cHJvdG9jb2wuIFBlcmlvZC48YnI+DQomZ3Q7Jmd0OyZuYnNwOyBJbiBjb250cmFzdCwgTkVNTyB3 YW50cyB0byBkZWZpbmUgYSBuZXcgcHJvdG9jb2wuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQomZ3Q7IEkgZG8gbm90IGtub3cgd2hhdCBt YWtlcyB5b3Ugc2F5IHNvLjxicj4NCiZndDsgSSB0aGluayB3ZSBoYXZlIGxlZnQgaXQgb3BlbiBz b2ZhciBhcyB0byB3aGV0aGVyIHdlIHdhbnQvbmVlZCBhIG5ldzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBwcm90b2NvbCBvciBub3QuPGJy Pg0KJmd0OyBQcmVmZXJhYmx5IHdlIGNhbiB1c2UgTmV0Y29uZi9SZXN0Y29uZi4gQnV0IEkgdGhp bmsgdGhhdCBpcyBhbGwgc3RpbGw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZndDsmbmJzcDtvcGVuIHRvIGRpc2N1c3Npb24uPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZsdDtqY3MmZ3Q7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IG1h a2VzIG1lIHNheSBzbyBpcyBhIGNvbWJpbmF0aW9uIG9mPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgMSkmbmJzcDtsaXN0ZW5pbmcgdG8g cHJldmlvdXMgTkVNTyBwcmVzZW50YXRpb25zIGluIG90aGVyIGZvcmE8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAyKSB2YXJpb3VzIHNl bnRlbmNlcyBpbiB0aGUgSUJORU1PIEJhciBCb0YgcHJlc2VudGF0aW9uPGJyPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IChlLmcuLCAmcXVvdDtRdWVzdGlvbjogc2NyaXB0cyBvdmVy IGh0dHAgd29ya2FibGUsIE5vdCBzdXJlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg UkVTVENPTkYgcnBjICYjNDM7IHB1Yi5zdWIgbGV2ZWwgbmVlZGVkJnF1b3Q7LDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Mykg U3RhdGVtZW50cyBzdWNoIGFzICZxdW90O1N5bmVyZ2lzdGljIG1lYW5zIHRoYXQgc3VtIG9mIElu dGVudCBCYXNlZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5FTU8gcHJvdG9jb2wgJiM0Mzsg TkVUQ09ORiAmIzQzOyBSRVNUQ09ORiAmIzQzOyBJMlJTICYjNDM7UENFIGlzIG1vcmU8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB0aGFuIGFueSBvZiB0aGUgcGFydHMgYWxvbmUmcXVvdDsgYW5k ICZxdW90O2NyZWF0aW5nIHByb3RvY29sIHdpdGggbWluaW1hbDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IG9wZXJhdGlvbnMgZm9yIHRvIGV4cHJlc3MgaW50ZW50IGZyb20gdGhlIGFwcGxpY2F0 aW9uIHRvIHRoZSBuZXR3b3JrJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJvdGgg ZnJvbSBkcmFmdC1oYXJlcy1pYm5lbW8tb3ZlcnZpZXctMDE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyA0KSBhIG1haWwgZnJvbSBTdWUg b24gNy8xNyB0byB0aGUgTkVNTyBhbmQgU1VQQSBsaXN0cywgdGhhdCBzYWlkPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJnF1b3Q7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToNCjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+SUJOZW1v4oCZcyAxNSBzcGVjaWZpYyBjb21tYW5kcyBhcmUgYmV0dGVyIHRoYW4g TkVUQ09ORg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9yIFJFU1RDT05GIGNv bW1hbmRzJnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMyMjIyMjIi PkkgY2FuIGdpdmUgeW91IG1hbnkgbW9yZSBleGFtcGxlcy4uLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZsdDsvamNzJmd0OzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0 OyAyKSBTVVBBIGRlZmluZXMgaW50ZW50IGFzIGRlY2xhcmF0aXZlIGxvZ2ljLCBhbmQgdGh1cyBp bXBsZW1lbnRzPGJyPg0KJmd0OyZndDsmbmJzcDtpdCB1c2luZyBlaXRoZXIgcHJvcG9zaXRpb25h bCBvciBmaXJzdCBvcmRlciBsb2dpYyAoc2VlIHNlY3Rpb24gMy4yLjQuLDxicj4NCiZndDsmZ3Q7 Jm5ic3A7TWF0aGVtYXRpY2FsIExvZ2ljIFRlcm1pbm9sb2d5LCBvZiBkcmFmdC1zdHJhc3NuZXIt c3VwYS1nZW5lcmljLTxicj4NCiZndDsmZ3Q7Jm5ic3A7cG9saWN5LWluZm8tbW9kZWwpLiBJbiBj b250cmFzdCwgTkVNTyBkZWZpbmVzIGltcGxlbWVudHMgaXRzPGJyPg0KJmd0OyZndDsgaW50ZW50 IHBvbGljeSB1c2luZyBjb25kaXRpb24tYWN0aW9uIChpbXBlcmF0aXZlKSBsb2dpYy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBBZ2Fp biBJIGRvIG5vdCB1bmRlcnN0YW5kIHdoeSB5b3UgdGhpbmsgc28uPGJyPg0KJmd0OyBJIGhhdmUg bm90IHNlZW4gYW55IEVDQSBzdHVmZiBpbiBJQk5FTU8geWV0Ljxicj4NCiZndDsgQnV0IHRoZW4s IG1heWJlIHlvdSBjYW4gcG9pbnQgbWUgdG8gaXQgaWYgeW91IGhhdmUuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZsdDtqY3MmZ3Q7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHNhaWQgJnF1 b3Q7Y29uZGl0aW9uLWFjdGlvbiZxdW90OywgTk9UIEVDQS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSBsb29rIGF0IGRyYWZ0LXhpYS1z ZG5yZy1uZW1vLWxhbmd1YWdlLTAyLCB3aGljaCBzYXlzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7QWxsIHRoZSBwb2xpY2llcyBmb2xs b3cgdGhlIHNhbWUgcGF0dGVybiAmcXVvdDt3aGVuICZsdDtjb25kaXRpb24mZ3Q7LCB0bw0KPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5leGVjdXRl ICZsdDthY3Rpb24mZ3Q7LCB3aXRoICZsdDtjb25zdHJhaW50Jmd0OyZxdW90OywgYW5kIGNhbiBi ZSBhcHBsaWVkIHRvIGFueSBlbnRpdHkuJnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7L2pjcyZndDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU3VuLCBBdWcgOSwgMjAxNSBh dCAyOjIzIFBNLCBCZXJ0IFdpam5lbiAoSUVURikgJmx0OzxhIGhyZWY9Im1haWx0bzpid2lldGZA Yndpam5lbi5uZXQiIHRhcmdldD0iX2JsYW5rIj5id2lldGZAYndpam5lbi5uZXQ8L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpvaG4sIElubGluZSw8 YnI+DQo8YnI+DQpPbiAwOS8wOC8xNSAyMjozMCwgSm9obiBTdHJhc3NuZXIgd3JvdGU6PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPkhpIEFkcmlhbiw8YnI+DQo8YnI+DQpJIGFsc28gZG8gbm90IHRoaW5rIHRoYXQgdGhlcmUg aXMgYW55IG92ZXJsYXAgYmV0d2VlbiB3aGF0IFNVUEEgaGFzIGRlZmluZWQ8YnI+DQphbmQgd2hh dCBORU1PIGhhcyBkZWZpbmVkLiBTVVBBIHByb3ZpZGVzIGEgY29tbW9uIG1vZGVsIGZvcjxicj4N CmV4cHJlc3NpbmcgaW1wZXJhdGl2ZSAoZS5nLiwgZXZlbnQtY29uZGl0aW9uLWFjdGlvbiwgb3Ig RUNBKSBhbmQgZGVjbGFyYXRpdmU8YnI+DQooZS5nLiwgZ29hbC1iYXNlZCwgb3IgJnF1b3Q7aW50 ZW50JnF1b3Q7KSBwb2xpY2llcy4gU1VQQSBwcm9wb3NlcyB0aGF0IGVhY2ggb2YgdGhlc2U8YnI+ DQpyZXByZXNlbnRhdGlvbnMgYXJlIHJlYWxpemVkIGFzIHNlcGFyYXRlIG1vZGVscywgYnV0IGFy ZSByZWxhdGVkIHRocm91Z2g8YnI+DQp0aGVpciAmcXVvdDtjb21tb24gYW5jZXN0cnkmcXVvdDsg KGkuZS4sIHRoZXkgd2VyZSBib3RoIGRlcml2ZWQgZnJvbSB0aGUgc2FtZTxicj4NCnN1cGVyc3Ry dWN0dXJlKS4gVGhpcyBtZWFucyB0aGF0IGVhY2ggY2FuIHVzZSB0aGUgb3RoZXIuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi Pk9LLCB0aGF0IHNvdW5kcyBnb29kIHRvIG1lLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SW4gYWRkaXRpb24sIHRoZXJlIGFyZSBkaXN0aW5jdCBkaWZmZXJlbmNlcyBiZXR3 ZWVuIFNVUEEgYW5kIE5FTU86PGJyPg0KPGJyPg0KJm5ic3A7IDEpIFNVUEEgZGVmaW5lcyBORVRD T05GIG9yIFJFU1RDT05GIGFzIGl0cyBwcm90b2NvbC4gUGVyaW9kLiBJbjxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7IGNvbnRyYXN0LCBORU1PIHdhbnRzIHRvIGRlZmluZSBhIG5ldyBwcm90b2Nv bC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG8gbm90IGtub3cgd2hh dCBtYWtlcyB5b3Ugc2F5IHNvLjxicj4NCkkgdGhpbmsgd2UgaGF2ZSBsZWZ0IGl0IG9wZW4gc29m YXIgYXMgdG8gd2hldGhlciB3ZSB3YW50L25lZWQgYSBuZXcgcHJvdG9jb2wgb3Igbm90Ljxicj4N ClByZWZlcmFibHkgd2UgY2FuIHVzZSBOZXRjb25mL1Jlc3Rjb25mLiBCdXQgSSB0aGluayB0aGF0 IGlzIGFsbCBzdGlsbCBvcGVuIHRvIGRpc2N1c3Npb24uPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsgMikgU1VQQSBkZWZpbmVzIGludGVudCBhcyBkZWNsYXJhdGl2 ZSBsb2dpYywgYW5kIHRodXMgaW1wbGVtZW50cyBpdDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 IHVzaW5nIGVpdGhlciBwcm9wb3NpdGlvbmFsIG9yIGZpcnN0IG9yZGVyIGxvZ2ljIChzZWUgc2Vj dGlvbiAzLjIuNC4sPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgTWF0aGVtYXRpY2FsIExvZ2lj IFRlcm1pbm9sb2d5LCBvZiBkcmFmdC1zdHJhc3NuZXItc3VwYS1nZW5lcmljLTxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7IHBvbGljeS1pbmZvLW1vZGVsKS4gSW4gY29udHJhc3QsIE5FTU8gZGVm aW5lcyBpbXBsZW1lbnRzIGl0czxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGludGVudCBwb2xp Y3kgdXNpbmcgY29uZGl0aW9uLWFjdGlvbiAoaW1wZXJhdGl2ZSkgbG9naWMuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZ2FpbiBJIGRvIG5vdCB1bmRlcnN0YW5kIHdoeSB5 b3UgdGhpbmsgc28uPGJyPg0KSSBoYXZlIG5vdCBzZWVuIGFueSBFQ0Egc3R1ZmYgaW4gSUJORU1P IHlldC48YnI+DQpCdXQgdGhlbiwgbWF5YmUgeW91IGNhbiBwb2ludCBtZSB0byBpdCBpZiB5b3Ug aGF2ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzMpIFNVUEEg aXMgTk9UIHdvcmtpbmcgb24gYSBsYW5ndWFnZS4gSW4gY29udHJhc3QsIE5FTU8gaXMgd29ya2lu Zzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7b24gYSBsYW5ndWFnZS48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcCwgd2Ugd291bGQgbGlrZSB0byB3b3JrIG9uIGFuICZx dW90O2ludGVudCBleHByZXNzaW9uIGxhbmd1YWdlJnF1b3Q7IGluIElCTkVNTy48YnI+DQo8YnI+ DQpCZXJ0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpyZWdhcmRz LDxicj4NCkpvaG48YnI+DQo8YnI+DQpPbiBTdW4sIEF1ZyA5LCAyMDE1IGF0IDg6MjMgQU0sIEFk cmlhbiBGYXJyZWwgJmx0OzxhIGhyZWY9Im1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrIiB0YXJn ZXQ9Il9ibGFuayI+YWRyaWFuQG9sZGRvZy5jby51azwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJt YWlsdG86YWRyaWFuQG9sZGRvZy5jby51ayIgdGFyZ2V0PSJfYmxhbmsiPmFkcmlhbkBvbGRkb2cu Y28udWs8L2E+Jmd0OyZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBIaSBCZXJ0 LDxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgSSBkb24ndCB0aGluayB5b3UgYXJlIHJlYWRpbmcg dGhlIHByb3Bvc2VkIGNoYXJ0ZXIgZm9yIFNVUEEgcmlnaHQgaWYgeW91IHRoaW5rPGJyPg0KJm5i c3A7ICZuYnNwOyBpdCBwcmVjbHVkZXMgdGhlIGZvcm1hdGlvbiBvZiBhIHdvcmtpbmcgZ3JvdXAg Zm9yIElCTkVNTy4gUmF0aGVyLCB0aGUgdGV4dCB0aGF0PGJyPg0KJm5ic3A7ICZuYnNwOyBCZW5v aXQgaGFzIHB1Ymxpc2hlZCBzYXlzIHRoYXQgU1VQQSBpcyBub3QgdGhlIHdvcmtpbmcgZ3JvdXAg dGhhdCB3b3JrcyBvbjxicj4NCiZuYnNwOyAmbmJzcDsgSUJORU1PLjxicj4NCjxicj4NCiZuYnNw OyAmbmJzcDsgQnV0IG1heWJlIHlvdSBhcmUgc2F5aW5nIHRoYXQgdGhlIGludGVudC1iYXNlZCBw YXJ0IG9mIHRoZSBTVUFQIGNoYXJ0ZXIgY291bGQgYmU8YnI+DQombmJzcDsgJm5ic3A7IGxpZnRl ZCBvdXQgYW5kIHBsYWNlZCBpbiBhbiBJQk5FTU8gd29yayBlZmZvcnQuIFRoYXQgbWlnaHQgYmUg cmVhc29uYWJsZS48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IEhvd2V2ZXIsIHRoZXJlIGlzIGEg c2VwYXJhdGlvbiBiZXR3ZWVuIHRoZSB1c2Ugb2YgZXhpc3RpbmcgZGF0YSBtb2RlbGluZyBhbmQ8 YnI+DQombmJzcDsgJm5ic3A7IHByb3RvY29scyAoc3VjaCBhcyBZQU5HIHdpdGggTkVUQ09ORikg YW5kIHRoZSBkZXZlbG9wbWVudCBvZiBhIG5ldyBhbmQ8YnI+DQombmJzcDsgJm5ic3A7IHNwZWNp YWxpc2VkIG1vZGVsaW5nIGxhbmd1YWdlIGFuZCBjb21tdW5pY2F0aW9uIHByb3RvY29sLiBJIGJl bGlldmUgdGhhdCB0aGlzPGJyPg0KJm5ic3A7ICZuYnNwOyBjaGFydGVyIHRleHQgb3BlbnMgdXAg dGhlIGludmVzdGlnYXRpb24gb2YgdGhlIHByYWN0aWNhbGl0aWVzIG9mIGludGVudC1iYXNlZDxi cj4NCiZuYnNwOyAmbmJzcDsgcG9saWN5IG1vZGVsaW5nIGluIG9yZGVyIHRvIGRldGVybWluZSB3 aGV0aGVyIHN1Y2ggdGhpbmdzIGNvdWxkIGJlIG1vZGVsZWQgaW48YnI+DQombmJzcDsgJm5ic3A7 IGV4aXN0aW5nIGxhbmd1YWdlcyBvciB3aGV0aGVyIG5ldyB3b3JrIGlzIG5lZWRlZCBhIHByaW9y aS48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IElmLCBmb3IgZXhhbXBsZSwgaXQgd2FzIHBvc3Np YmxlIHRvIGVuY29kZSBpbnRlbnQtYmFzZWQgcG9saWN5IGluIFlBTkcsIHRoYXQ8YnI+DQombmJz cDsgJm5ic3A7IHdvdWxkIG5vdCBwcmVjbHVkZSBJQk5FTU8gaW52ZW50aW5nIHNvbWV0aGluZyBk aWZmZXJlbnQvYmV0dGVyL3dvcnNlLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgTm93IHRoZXJl IGl0IHNlZW1zIHNlbnNpYmxlIHRoYXQgU1VQQSBzaG91bGQgYnVuZGxlIGFsbCBvZiB0aGUgdGhv dWdodCBhcm91bmQ8YnI+DQombmJzcDsgJm5ic3A7IHBvbGljeSBtb2RlbHMgaW4gb25lIHBsYWNl IGFzIGEgc3RhcnRpbmcgcG9pbnQuIElmIGl0IGlzIGxhdGVyIGRlc2lyYWJsZSB0bzxicj4NCiZu YnNwOyAmbmJzcDsgc3BsaXQgb2ZmIHRoZSBpbnRlbnQtYmFzZWQgcGFydCAoc2F5IGFmdGVyIHRo ZSBpbml0aWFsIGludmVzdGlnYXRpb24gYW5kPGJyPg0KJm5ic3A7ICZuYnNwOyBpbmZvcm1hdGlv biBtb2RlbHMpIHRoYXQgZG9lc24ndCBzZWVtIGxpa2UgYSBiYWQgdGhpbmcuPGJyPg0KPGJyPg0K Jm5ic3A7ICZuYnNwOyBBbHRlcm5hdGl2ZWx5LCBpZiB0aGVyZSBpcyBhIHN0cm9uZyBwdWxsIHRv IG1vdmUgYWxsIG9mIHRoZSBpbnRlbnQtYmFzZWQgd29yazxicj4NCiZuYnNwOyAmbmJzcDsgb3V0 IGZyb20gZGF5IG9uZSwgSSB3aWxsIG5vdCBiZSBjb21wbGFpbmluZy48YnI+DQo8YnI+DQombmJz cDsgJm5ic3A7IENoZWVycyw8YnI+DQombmJzcDsgJm5ic3A7IEFkcmlhbjxicj4NCjxicj4NCiZu YnNwOyAmbmJzcDsgJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZuYnNwOyAm bmJzcDsgJmd0OyBGcm9tOiBTdXBhIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnN1cGEtYm91bmNl c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnN1cGEtYm91bmNlc0BpZXRmLm9yZzwvYT4gJmx0 O21haWx0bzo8YSBocmVmPSJtYWlsdG86c3VwYS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+c3VwYS1ib3VuY2VzQGlldGYub3JnPC9hPiZndDtdIE9uIEJlaGFsZiBPZiBCZXJ0IFdp am5lbiAoSUVURik8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgU2VudDogMDcgQXVndXN0IDIwMTUg MTk6NDY8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgVG86IEJlbm9pdCBDbGFpc2U7IDxhIGhyZWY9 Im1haWx0bzpzdXBhQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3VwYUBpZXRmLm9yZzwvYT4g Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86c3VwYUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PnN1cGFAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBDYzogRWdnZXJ0 LCBMYXJzOyA8YSBocmVmPSJtYWlsdG86aWJuZW1vQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ aWJuZW1vQGlldGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzppYm5lbW9AaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pYm5lbW9AaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZuYnNw OyAmbmJzcDsgJmd0OyBTdWJqZWN0OiBSZTogW1N1cGFdIFNVUEEgY2hhcnRlciBwcm9wb3NhbDxi cj4NCiZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBIaSBCZW5vaXQg YW5kIG90aGVycy48YnI+DQombmJzcDsgJm5ic3A7ICZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZn dDsgU28gd291bGQgdGhpcyB3b3JrIHByZXZlbnQgdGhlIGZvcm1hdGlvbiBvZiBhIFdHIHRoYXQg d291bGQgZG8gSUJORU1PIChJbnRlbnQ8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgQmFzZWQgTkV0 d29yayBNT2RlbGluZyk8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgd29yaz8gSSBjZXJ0YWlubHkg aG9wZSBub3QuIEluIHRoZSBjaGFydGVyIHlvdSBoYXZlOjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0 Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAoaWlp KSB0aGUgd29ya2luZyBncm91cCB3aWxsIGludmVzdGlnYXRlIHRoZSBwcmFjdGljYWxseSBvZiBi dWlsZGluZzxicj4NCiZuYnNwOyAmbmJzcDsgcG9saWN5IHJ1bGVzPGJyPg0KJm5ic3A7ICZuYnNw OyAmZ3Q7IHRoYXQgZGVjbGFyYXRpdmVseTxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBzcGVjaWZ5IHdoYXQgZ29h bHMgdG8gYWNoaWV2ZSAodGhpcyBpcyBvZnRlbiBjYWxsZWQ8YnI+DQombmJzcDsgJm5ic3A7ICZx dW90O2ludGVudC1iYXNlZCZxdW90OyBwb2xpY3kpIGJ1dDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0 OyBub3QgaG93IHRvIGFjaGlldmU8YnI+DQombmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhvc2UgZ29hbHMgYW5kIG1heSBj cmVhdGUgYSBtb2RlbCBhY2NvcmRpbmdseS48YnI+DQombmJzcDsgJm5ic3A7ICZndDs8YnI+DQom bmJzcDsgJm5ic3A7ICZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgSUJORU1PIGludGVuZHMg KG5vIHB1biBpbnRlbmRlZCkgdG8gZGVmaW5lL3N0YW5kYXJkaXplIGEgSW50ZW50IGV4cHJlc3Np b248YnI+DQombmJzcDsgJm5ic3A7ICZndDsgbGFuZ3VhZ2UuPGJyPg0KJm5ic3A7ICZuYnNwOyAm Z3Q7IFRoZSB3b3JrIHlvdSBkZXNjcmliZSBhYm92ZSBjYW4gYmUgaW5wdXQgdG8gdGhlIHdvcmsg SUJORU1PIHdhbnRzIHRvIGRvLjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZuYnNwOyAm bmJzcDsgJmd0OyBCZXJ0PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNw OyAmZ3Q7IE9uIDA3LzA4LzE1IDE4OjAzLCBCZW5vaXQgQ2xhaXNlIHdyb3RlOjxicj4NCiZuYnNw OyAmbmJzcDsgJmd0OyAmZ3Q7IERlYXIgYWxsLDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7 PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDsgQXMgcHJvbWlzZWQgaW4gbXkgbGFzdCBlbWFp bCAoJnF1b3Q7U1VQQTogU2l0dWF0aW9uIFN1bW1hcnkgYW5kIE5leHQgU3RlcHMmcXVvdDspLDxi cj4NCiZuYnNwOyAmbmJzcDsgaGVyZTxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBpcyBhIHByb3Bv c2VkIGNoYXJ0ZXIuPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDsgVGhhbmtzIHRvIFJvYmVy dCBTcGFya3MsIEFkcmlhbiBGYXJyZWwsIGFuZCBEYW4gUm9tYXNjYW51Ljxicj4NCiZuYnNwOyAm bmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDsgSG9wZWZ1bGx5LCB0 aGlzIG5ldyB2ZXJzaW9uIHdpbGwgY2xhcmlmeSB0aGUgc2l0dWF0aW9uLCBhbmQgd2lsbCBiZTxi cj4NCiZuYnNwOyAmbmJzcDsgYWNjZXB0YWJsZSB0bzxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBl dmVyeWJvZHkuPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDsgUGxlYXNlIGxldCB1cyBrbm93 LiBOb3RlOiBJIHByZWZlciB0byBrZWVwIHRoZSBlZGl0IHRva2VuIGZyb20gbm93Ljxicj4NCiZu YnNwOyAmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDsgUmVnYXJk cywgQmVub2l0IChPUFMgQUQpPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDs8YnI+DQombmJz cDsgJm5ic3A7ICZndDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyA9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4NCiZu YnNwOyAmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDsgU1VQQSBD SEFSVEVSIFBST1BPU0FMICgyMDE1LTA4LTA3KTxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7 PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDsgUG9saWN5IGlzIGFuIGltcG9ydGFudCBjb25m aWd1cmFibGUgY29tcG9uZW50IGluIHRoZSBkZWxpdmVyeSBvZiBzZXJ2aWNlczxicj4NCiZuYnNw OyAmbmJzcDsgYW5kPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IHRoZSBvcGVyYXRpb24gb2YgbmV0 d29ya3MuIE9wZXJhdG9ycyB3YW50IGFuZCBuZWVkPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZn dDsgdG8gYmUgYWJsZSB0byBkZXRlcm1pbmUgdGhlIHBvbGljaWVzIHRoYXQgYXBwbHkgdG8gdGhl aXIgZGlmZmVyZW50IGN1c3RvbWVyczxicj4NCiZuYnNwOyAmbmJzcDsgYW5kPGJyPg0KJm5ic3A7 ICZuYnNwOyAmZ3Q7IHRvIHRoZSBlcXVpcG1lbnQgdGhhdCBjb21wcmlzZXMgdGhlaXIgcGh5c2lj YWw8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgJmd0OyBhbmQgdmlydHVhbCBuZXR3b3Jrcy4gQXMg cG9saWN5IHNwYW5zIHN1Y2ggYSB3aWRlIHJhbmdlIG9mIHNlcnZpY2VzIGFuZDxicj4NCiZuYnNw OyAmbmJzcDsgZGV2aWNlPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IHR5cGVzLCBpdCB3aWxsIGJl IGhlbHBmdWwgaWYgdGhlcmUgaXMgYSBjb21tb24gd2F5PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7 ICZndDsgb2YgZXhwcmVzc2luZyBhbmQgZGVzY3JpYmluZyBwb2xpY2llcyB0aGF0IGlzIHVuaWZv cm0gYW5kIGNvbnNpc3RlbnQgaW4gYWxsPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IGVudmlyb25t ZW50cy4gU3VjaCBhbiBhcHByb2FjaCB3aWxsIGhlbHAgdG8gYXZvaWQ8YnI+DQombmJzcDsgJm5i c3A7ICZndDsgJmd0OyBjb25maWd1cmF0aW9uIGVycm9ycyB0aGF0IGFyaXNlIGZyb20gY29uZnVz aW9uIGJldHdlZW4gZGlmZmVyZW50IHN5c3RlbXMsPGJyPg0KJm5ic3A7ICZuYnNwOyB3aWxsPGJy Pg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IGVuYWJsZSBlYXN5IHVuZGVyc3RhbmRpbmcgb2YgcG9saWNp ZXMgdGhhdCBhcHBseSBpbjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7IGRpZmZlcmVudCBl bnZpcm9ubWVudHMsIHdpbGwgbWFrZSB0aGUgaW1wbGVtZW50YXRpb24gb2YgcG9saWN5LWJhc2Vk IHN5c3RlbXM8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgcXVpY2tlciBhbmQgY2hlYXBlciwgYW5k IHdpbGwgZmFjaWxpdGF0ZSB0aGUgcmFwaWQ8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgJmd0OyBk ZXZlbG9wbWVudCBvZiBzdGFuZGFyZHMtYmFzZWQgZGF0YSBtb2RlbHMgdGhhdCBpbmNsdWRlIHBv bGljeSBlbGVtZW50cy48YnI+DQombmJzcDsgJm5ic3A7ICZndDsgJmd0Ozxicj4NCiZuYnNwOyAm bmJzcDsgJmd0OyAmZ3Q7IFNVUEEgKFNpbXBsaWZpZWQgVXNlIG9mIFBvbGljeSBBYnN0cmFjdGlv bnMpIGRlZmluZXMgYSBtb2RlbCB0byBpbnRlcmZhY2U8YnI+DQombmJzcDsgJm5ic3A7IHdpdGgg YTxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBuZXR3b3JrIG1hbmFnZW1lbnQgZnVuY3Rpb24gKHdp dGhpbiBhIGNvbnRyb2xsZXIsPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDsgYW4gb3JjaGVz dHJhdG9yLCBhIG5ldHdvcmsgZWxlbWVudCkgdGhhdCB0YWtlcyBoaWdoLWxldmVsLCBwb3NzaWJs eSBuZXR3b3JrLTxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyB3aWRlIHBvbGljaWVzIGFzIGlucHV0 LiBTVVBBIHdpbGwgbm90IGRlZmluZSB3aGF0IHRoZTxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAm Z3Q7IGZ1bmN0aW9uIGRvZXMgd2l0aCB0aGF0IGlucHV0IGJ1dCBhbnRpY2lwYXRlcyB0aGF0IGl0 IHdpbGwgdWx0aW1hdGVseSByZXN1bHQ8YnI+DQombmJzcDsgJm5ic3A7IGluPGJyPg0KJm5ic3A7 ICZuYnNwOyAmZ3Q7IG5ldHdvcmsgY29uZmlndXJhdGlvbiBjaGFuZ2VzPGJyPg0KJm5ic3A7ICZu YnNwOyAmZ3Q7ICZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgJmd0OyBQcmFjdGljYWxseSwg U1VQQSB3aWxsIGRlZmluZSBnZW5lcmljIFlBTkcgZGF0YSBtb2RlbHMgdG8gZW5jb2RlIHBvbGlj eSw8YnI+DQombmJzcDsgJm5ic3A7IHdoaWNoPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IGNhbiBw b2ludCB0byBkZXZpY2UtLCB0ZWNobm9sb2d5LSwgYW5kPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7 ICZndDsgc2VydmljZS1zcGVjaWZpYyBZQU5HIG1vZGVscyBvZiBvdGhlciB3b3JraW5nIGdyb3Vw cy48YnI+DQombmJzcDsgJm5ic3A7ICZndDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAm Z3Q7IFNVUEEgd2lsbCBiZSBkZXNpZ25lZCB0byB3b3JrIHdpdGggZGV2aWNlLCBwcm90b2NvbCwg bmV0d29yaywgYW5kIHNlcnZpY2U8YnI+DQombmJzcDsgJm5ic3A7IGRhdGE8YnI+DQombmJzcDsg Jm5ic3A7ICZndDsgbW9kZWxzLjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJm5i c3A7ICZuYnNwOyAmZ3Q7ICZndDsgVGhlIFNVUEEgd29ya2luZyBncm91cCB3aWxsIGRldmVsb3Ag YSBtb2RlbCBmb3IgZXhwcmVzc2luZyBwb2xpY3kgYXQ8YnI+DQombmJzcDsgJm5ic3A7IGRpZmZl cmVudDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBsZXZlbHMgb2YgYWJzdHJhY3Rpb24uU3BlY2lm aWNhbGx5LCB0aHJlZSBtb2RlbDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7IGZyYWdtZW50 cyBhcmUgZW52aXNpb25lZDogKGkpIGEgZ2VuZXJpYyBtb2RlbCB0aGF0IGRlZmluZXMgY29uY2Vw dHMgYW5kPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IHZvY2FidWxhcnkgbmVlZGVkIGJ5IHBvbGlj eSBtYW5hZ2VtZW50IGluZGVwZW5kZW50IG9mIHRoZTxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAm Z3Q7IGZvcm0gYW5kIGNvbnRlbnQgb2YgdGhlIHBvbGljeSwgKGlpKSBhIG1vcmUgc3BlY2lmaWMg bW9kZWwgdGhhdCByZWZpbmVzIHRoZTxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBnZW5lcmljIG1v ZGVsIHRvIHNwZWNpZnkgaG93IHRvIGJ1aWxkIHBvbGljeSBydWxlcyBvZjxicj4NCiZuYnNwOyAm bmJzcDsgJmd0OyAmZ3Q7IHRoZSBldmVudC1jb25kaXRpb24tYWN0aW9uIHBhcmFkaWdtLCBhbmQg KGlpaSkgdGhlIHdvcmtpbmcgZ3JvdXAgd2lsbDxicj4NCiZuYnNwOyAmbmJzcDsgaW52ZXN0aWdh dGU8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgdGhlIHByYWN0aWNhbGx5IG9mIGJ1aWxkaW5nIHBv bGljeSBydWxlcyB0aGF0PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDsgZGVjbGFyYXRpdmVs eSBzcGVjaWZ5IHdoYXQgZ29hbHMgdG8gYWNoaWV2ZSAodGhpcyBpcyBvZnRlbiBjYWxsZWQ8YnI+ DQombmJzcDsgJm5ic3A7ICZxdW90O2ludGVudC1iYXNlZCZxdW90Ozxicj4NCiZuYnNwOyAmbmJz cDsgJmd0OyBwb2xpY3kpIGJ1dCBub3QgaG93IHRvIGFjaGlldmUgdGhvc2UgZ29hbHMgYW5kPGJy Pg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDsgbWF5IGNyZWF0ZSBhIG1vZGVsIGFjY29yZGluZ2x5 Ljxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZn dDsgSWYgdGhlIHdvcmtpbmcgZ3JvdXAgZmluZHMgaXQgbmVjZXNzYXJ5IHRvIHdvcmsgb24gYW4g aW5mb3JtYXRpb24gbW9kZWw8YnI+DQombmJzcDsgJm5ic3A7IGJlZm9yZTxicj4NCiZuYnNwOyAm bmJzcDsgJmd0OyB0aGUgZGF0YSBtb2RlbCwgdG8gaGVscCBwcm92aWRlIGd1aWRhbmNlIGFuZCBk ZXJpdmU8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgJmd0OyB0aGUgZGF0YSBtb2RlbHMsIGl0IG1p Z2h0IGRvIHNvLiBUaGUgd29ya2luZyBncm91cCB3aWxsIGRlY2lkZSBsYXRlciB3aGV0aGVyPGJy Pg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IHRoZSBpbmZvcm1hdGlvbiBtb2RlbCBuZWVkcyB0byBiZSBw dWJsaXNoZWQgYXMgYW4gUkZDLjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJm5i c3A7ICZuYnNwOyAmZ3Q7ICZndDsgT3V0IG9mIHNjb3BlIG9mIHRoaXMgd29ya2luZyBncm91cCBp czo8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAm Z3Q7IC1UaGUgc3BlY2lmaWNhdGlvbiBvZiBhIG5ldyBwb2xpY3kgbGFuZ3VhZ2UuIFRoZSBZQU5H IGRhdGEgbW9kZWxzIGFyZSB0byBiZTxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyB1c2VkIHdpdGgg cHJvdG9jb2xzIHN1Y2ggYXMgTkVUQ09ORi9SRVNUQ09ORi48YnI+DQombmJzcDsgJm5ic3A7ICZn dDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7IC1EZXNpZ24gb2YgcHJvdG9jb2wt c3BlY2lmaWMgcG9saWNpZXMgYW5kIHNwZWNpZmljIGRlc2lnbiBmb3IgZW1iZWRkZWQ8YnI+DQom bmJzcDsgJm5ic3A7IHBvbGljaWVzIGluPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IG5ldHdvcmsg ZWxlbWVudHMgKHdoaWNoIGFyZSB1c3VhbGx5IGludGVycHJldGVkPGJyPg0KJm5ic3A7ICZuYnNw OyAmZ3Q7ICZndDsgaW4gaXNvbGF0aW9uLCBhbmQgb2Z0ZW4gYXQgdGltZXNjYWxlcyB0aGF0IHJl cXVpcmUgb3B0aW1pemF0aW9uIGZvciBzcGVjaWZpYzxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBw dXJwb3NlcykuPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDs8YnI+DQombmJzcDsgJm5ic3A7 ICZndDsgJmd0OyAtU3BlY2lmaWMgaGFuZGxpbmcgb2YgcG9saWNpZXMgKGFsdGhvdWdoIHRoZSBh cHBsaWNhdGlvbiBkb2N1bWVudCB3aWxsPGJyPg0KJm5ic3A7ICZuYnNwOyBwcm92aWRlPGJyPg0K Jm5ic3A7ICZuYnNwOyAmZ3Q7IHNvbWUgZXhhbXBsZXMpLCBhbmQgdGhlcmVmb3JlIHRoZSBzcGVj aWZpY2F0aW9uIG9mPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDsgYSBwb2xpY3kgZW5naW5l IHRoYXQgbWFwcyBhIHNwZWNpZmljIHBvbGljeSBpbnN0YW5jZSB0byBhY3R1YWwgY29uZmlndXJh dGlvbjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBzbmlwcGV0cy48YnI+DQombmJzcDsgJm5ic3A7 ICZndDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7IExpc3Qgb2Ygd29yayBpdGVt czo8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAm Z3Q7IDEpIEEgZG9jdW1lbnQgdGhhdCBleHBsYWlucyB0aGUgc2NvcGUgb2YgdGhlIHBvbGljeS1i YXNlZCBtYW5hZ2VtZW50PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IGZyYW1ld29yayBhbmQgaG93 IGl0IHJlbGF0ZXMgdG8gZXhpc3Rpbmcgd29yayBvZiB0aGUgSUVURi48YnI+DQombmJzcDsgJm5i c3A7ICZndDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7IDIpIElmIHRoZSB3b3Jr aW5nIGdyb3VwIGNvbnNpZGVycyBpdCBuZWNlc3NhcnksIGFuIGluZm9ybWF0aW9uIG1vZGVsPGJy Pg0KJm5ic3A7ICZuYnNwOyBjb21wb3NlZDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBvZiBwb2xp Y3kgY29uY2VwdHMgYW5kIHZvY2FidWxhcnkuPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDs8 YnI+DQombmJzcDsgJm5ic3A7ICZndDsgJmd0OyAzKSBBIHNldCBvZiBZQU5HIGRhdGEgbW9kZWxz IGNvbnNpc3Rpbmcgb2YgYSBiYXNlIHBvbGljeSBtb2RlbCBmb3I8YnI+DQombmJzcDsgJm5ic3A7 IHJlcHJlc2VudGluZzxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBwb2xpY3kgbWFuYWdlbWVudCBj b25jZXB0cyBpbmRlcGVuZGVudCBvZiB0aGUgdHlwZTxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAm Z3Q7IG9yIHN0cnVjdHVyZSBvZiBhIHBvbGljeSwgcGx1cyBhbiBleHRlbnNpb24gZm9yIGRlZmlu aW5nIHBvbGljeSBydWxlczxicj4NCiZuYnNwOyAmbmJzcDsgYWNjb3JkaW5nIHRvPGJyPg0KJm5i c3A7ICZuYnNwOyAmZ3Q7IHRoZSBldmVudC1jb25kaXRpb24tYWN0aW9uIHBhcmFkaWdtLiBBbm90 aGVyPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDsgZXh0ZW5zaW9uIGZvciBkZWZpbmluZyBw b2xpY3kgcnVsZXMgYWNjb3JkaW5nIHRvIGEgZGVjbGFyYXRpdmUsIG9yPGJyPg0KJm5ic3A7ICZu YnNwOyBpbnRlbnQtYmFzZWQsPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IHBhcmFkaWdtLCBtYXkg YmUgcHJvZHVjZWQuIFRoZXNlIG1vZGVscyB3aWxsIGJlPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7 ICZndDsgZGVzaWduZWQgdG8gYmUgZ2VuZXJpYyBhbmQgZXh0ZW5zaWJsZS48YnI+DQombmJzcDsg Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7IDQpIEFuIGFwcGxp Y2FiaWxpdHkgZG9jdW1lbnQgcHJvdmlkaW5nIGEgZmV3IGV4YW1wbGVzIHRoYXQgZGVtb25zdHJh dGUgaG93PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IHRoZSBnZW5lcmljIHBvbGljeSBtb2RlbHMg Y2FuIGJlIHVzZWQgdG8gZXhwcmVzczxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7IHBvbGlj aWVzIHRoYXQgYXJlIHJlbGV2YW50IGZvciBuZXR3b3JrIG9wZXJhdG9ycy4gVGhlIGV4YW1wbGVz IG1heSB0aWUgaW50bzxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBjb25maWd1cmF0aW9uIG1vZGVs cyBvciBuZXR3b3JrIHNlcnZpY2UgbW9kZWxzPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDsg ZGV2ZWxvcGVkIGJ5IG90aGVyIHdvcmtpbmcgZ3JvdXBzLjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0 OyAmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDsgVGhlIHdvcmtpbmcgZ3JvdXAgd2ls bCBkZWNpZGUgaG93IHRoZSB3b3JrIGl0ZW1zIGFyZSBiZXN0IG1hcHBlZCBpbnRvPGJyPg0KJm5i c3A7ICZuYnNwOyAmZ3Q7IGRlbGl2ZXJhYmxlcy48YnI+DQombmJzcDsgJm5ic3A7ICZndDsgJmd0 Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7IFRoaXMgd29ya2luZyBncm91cCB3aWxsIGJl IGEgc3VjY2VzcyB3aGVuIHRoZSBTVVBBIHBvbGljeSBjb25zdHJ1Y3RzIGFyZSByZS08YnI+DQom bmJzcDsgJm5ic3A7ICZndDsgdXNlZCBpbiBmdXR1cmUgSUVURiBzcGVjaWZpY2F0aW9ucyAoYW5k LCBpZGVhbGx5LDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7IHNwZWNpZmljYXRpb25zIGZy b20gb3RoZXIgU0RPcyksIGluIGEgbWFubmVyIHRoYXQgd2lsbCBzYXZlIGRldmVsb3BtZW50IHRp bWU8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgYW5kIGF2b2lkIGluY29uc2lzdGVuY2llcyBiZXR3 ZWVuIGRhdGEgbW9kZWxzPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDsgZGV2ZWxvcGVkIGJ5 IGRpZmZlcmVudCB3b3JraW5nIGdyb3Vwcy4gSW4gdGhlIG1lYW50aW1lLCBTVVBBIHNob3VsZCBu b3Q8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgaW1wZWRlIHdvcmsgaW4gb3RoZXIgd29ya2luZyBn cm91cHMgd2hpbGUgd2FpdGluZyBmb3IgU1VQQTxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7 IHRvIHByb2R1Y2UgaXRzIGRlbGl2ZXJhYmxlcy48YnI+DQombmJzcDsgJm5ic3A7ICZndDsgJmd0 Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7IFRoZSB3b3JraW5nIGdyb3VwIHdpbGwgY29t bXVuaWNhdGUgd2l0aCBvdGhlciBTRE9zIChNRUYsIFRNRiwgRVRTSSkgdGhhdCBhcmU8YnI+DQom bmJzcDsgJm5ic3A7ICZndDsgd29ya2luZyBvbiByZWxhdGVkIGlzc3Vlcy48YnI+DQombmJzcDsg Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7IE1pbGVzdG9uZXM6 PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgJmd0 OyBUQkQ8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0 OyAmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZn dDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDsg U3VwYSBtYWlsaW5nIGxpc3Q8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgJmd0OyA8YSBocmVmPSJt YWlsdG86U3VwYUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlN1cGFAaWV0Zi5vcmc8L2E+ICZs dDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOlN1cGFAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5T dXBhQGlldGYub3JnPC9hPiZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgJmd0OyA8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N1cGEiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N1cGE8L2E+PGJyPg0K Jm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7 IFN1cGEgbWFpbGluZyBsaXN0PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IDxhIGhyZWY9Im1haWx0 bzpTdXBhQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+U3VwYUBpZXRmLm9yZzwvYT4gJmx0O21h aWx0bzo8YSBocmVmPSJtYWlsdG86U3VwYUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlN1cGFA aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyA8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N1cGEiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N1cGE8L2E+PGJyPg0KPGJyPg0KJm5i c3A7ICZuYnNwOyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCiZuYnNwOyAmbmJzcDsgU3VwYSBtYWlsaW5nIGxpc3Q8YnI+DQombmJzcDsgJm5ic3A7 IDxhIGhyZWY9Im1haWx0bzpTdXBhQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+U3VwYUBpZXRm Lm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86U3VwYUBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPlN1cGFAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdXBhIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdXBhPC9hPjxicj4N Cjxicj4NCjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQo8c3Bh biBjbGFzcz0iaG9lbnpiIj4tLSA8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+cmVn YXJkcyw8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+Sm9objwvc3Bhbj48YnI+DQo8 YnI+DQo8YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj5T dXBhIG1haWxpbmcgbGlzdDwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj48YSBocmVm PSJtYWlsdG86U3VwYUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlN1cGFAaWV0Zi5vcmc8L2E+ PC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc3VwYSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3VwYTwvYT48L3NwYW4+PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxicj4NCi0t IDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5yZWdh cmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Sm9objxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_B818037A70EDCC4A86113DA25EC020982012EBB0SJCEML703CHMchi_-- From nobody Thu Aug 13 00:54:58 2015 Return-Path: X-Original-To: ibnemo@ietfa.amsl.com Delivered-To: ibnemo@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA9A1ACDE6 for ; Wed, 12 Aug 2015 14:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 o4mzoj7GaClg for ; Wed, 12 Aug 2015 14:02:33 -0700 (PDT) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) (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 563431ACDE5 for ; Wed, 12 Aug 2015 14:02:32 -0700 (PDT) Received: by lbcbn3 with SMTP id bn3so16475733lbc.2 for ; Wed, 12 Aug 2015 14:02:30 -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=18ZZf1Pth3tKC4hKJuin0TcrQ1FkgDBjUyB5HeKkZMo=; b=A8U3lFc6OkFiUDPwPET+Qf/veI8w+6b2mII3LMaoIKALHcrRZSj6T0orTMtprgSihK FFgtHoln7/8Bw+sDejWNyzpcO53pi4Eaqthw5RczjLF6sUoHUNA+VVTtwxZZpVO1F3YQ ykfDLX79hp/vfbYHy88x1+n/QCuUhgP4hAjN0SKEbrgtc1TWXt9RrBfYO1VE3qbzNbUb Ro7A5zn752LTJ49u5f1r2lJantYZbbURsg84A2umH7HHveiFOTi1VQRqvTtLyU2bvokr 7lf395BQ0UvJ7+MrXEalVpPVoAwQpnmhfd4SUpbvBHM4nG14JG8l8eq2xbwJqE5Tfa8m dDIA== X-Gm-Message-State: ALoCoQmFpCEFnbII6Pt/CWMNtC08ll+xmI6ZCfmqTiv2XGF1BcYbkIfWP/XPtGgv4FJPnrdXph1p MIME-Version: 1.0 X-Received: by 10.112.160.42 with SMTP id xh10mr33539149lbb.88.1439413350830; Wed, 12 Aug 2015 14:02:30 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 12 Aug 2015 14:02:30 -0700 (PDT) In-Reply-To: References: <55C4D6C1.5040504@cisco.com> <55C4FCFE.8070701@bwijnen.net> <023101d0d2b7$54dad4e0$fe907ea0$@olddog.co.uk> <55CB609C.8040406@cisco.com> Date: Wed, 12 Aug 2015 14:02:30 -0700 Message-ID: From: Andy Bierman To: "Natale, Bob" Content-Type: multipart/alternative; boundary=001a11c34238762ed5051d238920 Archived-At: X-Mailman-Approved-At: Thu, 13 Aug 2015 00:54:57 -0700 Cc: "ibnemo@ietf.org" , "Eggert, Lars" , "adrian@olddog.co.uk" , "supa@ietf.org" Subject: Re: [Ibnemo] [Supa] SUPA charter proposal X-BeenThere: ibnemo@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of Nemo, an intent-based North Bound \(NB\) interface consisting of an application protocol running over HTTP \(RESTful interfaces\) to exchange intent-based primitives between applications and meta-controllers controlling virtual network resources \(networks, storage, CPU\)." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 21:02:37 -0000 --001a11c34238762ed5051d238920 Content-Type: text/plain; charset=UTF-8 On Wed, Aug 12, 2015 at 1:38 PM, Natale, Bob wrote: > +1 from me on this point from Adrian's message below* in particular: "SUPA > should bundle all of the thought around policy models in one place as a > starting point". > > Fragmentation of PBNM solutions has resulted from the lack of > standardization in the face of significant need ... the need is only > growing as the requirements intended to be satisfied by the emerging > technologies supporting network services virtualization (among many other > drivers) raise the urgency of governed automation ... this is an > opportunity for the IETF to restart in this challenging area (PBNM) and > SUPA is a promising locus for the starting point (IMHO). > > [* - Taken a little out of context, it's true ... but only a little. :)] > > IMO, the significant component here is network-level NM. This is new territory for the IETF. As we dig into "framework issues" there are some common components that keep coming up: - topology database (query by attribute) - AAA (identity and authorization, logging) - inventory/capabilities The need for cross-WG and cross-area coordination has never been greater. Whether it's I2RS or PBNM or anything at the network level, there are common problems dealing with NEs that must be solved. Let's make sure the foundation gets built before the roof. Avanti, > BobN > Andy > > -----Original Message----- > From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Benoit Claise > Sent: Wednesday, August 12, 2015 11:05 AM > To: adrian@olddog.co.uk; 'Bert Wijnen (IETF)' ; > supa@ietf.org > Cc: 'Eggert, Lars' ; ibnemo@ietf.org > Subject: Re: [Supa] SUPA charter proposal > > +1 to what Adrian wrote. > > Regards, B. > > Hi Bert, > > > > I don't think you are reading the proposed charter for SUPA right if > > you think it precludes the formation of a working group for IBNEMO. > > Rather, the text that Benoit has published says that SUPA is not the > > working group that works on IBNEMO. > > > > But maybe you are saying that the intent-based part of the SUAP > > charter could be lifted out and placed in an IBNEMO work effort. That > might be reasonable. > > > > However, there is a separation between the use of existing data > > modeling and protocols (such as YANG with NETCONF) and the development > > of a new and specialised modeling language and communication protocol. > > I believe that this charter text opens up the investigation of the > > practicalities of intent-based policy modeling in order to determine > > whether such things could be modeled in existing languages or whether > new work is needed a priori. > > > > If, for example, it was possible to encode intent-based policy in > > YANG, that would not preclude IBNEMO inventing something > different/better/worse. > > > > Now there it seems sensible that SUPA should bundle all of the thought > > around policy models in one place as a starting point. If it is later > > desirable to split off the intent-based part (say after the initial > > investigation and information models) that doesn't seem like a bad thing. > > > > Alternatively, if there is a strong pull to move all of the > > intent-based work out from day one, I will not be complaining. > > > > Cheers, > > Adrian > > > >> -----Original Message----- > >> From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Bert Wijnen > >> (IETF) > >> Sent: 07 August 2015 19:46 > >> To: Benoit Claise; supa@ietf.org > >> Cc: Eggert, Lars; ibnemo@ietf.org > >> Subject: Re: [Supa] SUPA charter proposal > >> > >> Hi Benoit and others. > >> > >> So would this work prevent the formation of a WG that would do IBNEMO > >> (Intent Based NEtwork MOdeling) work? I certainly hope not. In the > >> charter you have: > >> > >> (iii) the working group will investigate the practically of > >> building > > policy rules > >> that declaratively > >> specify what goals to achieve (this is often called > > "intent-based" policy) but > >> not how to achieve > >> those goals and may create a model accordingly. > >> > >> > >> IBNEMO intends (no pun intended) to define/standardize a Intent > >> expression language. > >> The work you describe above can be input to the work IBNEMO wants to do. > >> > >> Bert > >> > >> On 07/08/15 18:03, Benoit Claise wrote: > >>> Dear all, > >>> > >>> As promised in my last email ("SUPA: Situation Summary and Next > >>> Steps"), > > here > >> is a proposed charter. > >>> Thanks to Robert Sparks, Adrian Farrel, and Dan Romascanu. > >>> > >>> Hopefully, this new version will clarify the situation, and will be > > acceptable to > >> everybody. > >>> Please let us know. Note: I prefer to keep the edit token from now. > >>> > >>> Regards, Benoit (OPS AD) > >>> > >>> > >> ============================================================== > >>> SUPA CHARTER PROPOSAL (2015-08-07) > >>> > >>> Policy is an important configurable component in the delivery of > >>> services > > and > >> the operation of networks. Operators want and need > >>> to be able to determine the policies that apply to their different > >>> customers > > and > >> to the equipment that comprises their physical > >>> and virtual networks. As policy spans such a wide range of services > >>> and > > device > >> types, it will be helpful if there is a common way > >>> of expressing and describing policies that is uniform and consistent > >>> in all > >> environments. Such an approach will help to avoid > >>> configuration errors that arise from confusion between different > >>> systems, > > will > >> enable easy understanding of policies that apply in > >>> different environments, will make the implementation of policy-based > >>> systems > >> quicker and cheaper, and will facilitate the rapid > >>> development of standards-based data models that include policy > elements. > >>> > >>> SUPA (Simplified Use of Policy Abstractions) defines a model to > >>> interface > > with a > >> network management function (within a controller, > >>> an orchestrator, a network element) that takes high-level, possibly > >>> network- > >> wide policies as input. SUPA will not define what the > >>> function does with that input but anticipates that it will > >>> ultimately result > > in > >> network configuration changes > >>> Practically, SUPA will define generic YANG data models to encode > >>> policy, > > which > >> can point to device-, technology-, and > >>> service-specific YANG models of other working groups. > >>> > >>> SUPA will be designed to work with device, protocol, network, and > >>> service > > data > >> models. > >>> The SUPA working group will develop a model for expressing policy at > > different > >> levels of abstraction.Specifically, three model > >>> fragments are envisioned: (i) a generic model that defines concepts > >>> and > >> vocabulary needed by policy management independent of the > >>> form and content of the policy, (ii) a more specific model that > >>> refines the > >> generic model to specify how to build policy rules of > >>> the event-condition-action paradigm, and (iii) the working group > >>> will > > investigate > >> the practically of building policy rules that > >>> declaratively specify what goals to achieve (this is often called > > "intent-based" > >> policy) but not how to achieve those goals and > >>> may create a model accordingly. > >>> > >>> If the working group finds it necessary to work on an information > >>> model > > before > >> the data model, to help provide guidance and derive > >>> the data models, it might do so. The working group will decide later > >>> whether > >> the information model needs to be published as an RFC. > >>> Out of scope of this working group is: > >>> > >>> -The specification of a new policy language. The YANG data models > >>> are to be > >> used with protocols such as NETCONF/RESTCONF. > >>> -Design of protocol-specific policies and specific design for > >>> embedded > > policies in > >> network elements (which are usually interpreted > >>> in isolation, and often at timescales that require optimization for > >>> specific > >> purposes). > >>> -Specific handling of policies (although the application document > >>> will > > provide > >> some examples), and therefore the specification of > >>> a policy engine that maps a specific policy instance to actual > >>> configuration > >> snippets. > >>> List of work items: > >>> > >>> 1) A document that explains the scope of the policy-based management > >> framework and how it relates to existing work of the IETF. > >>> 2) If the working group considers it necessary, an information model > > composed > >> of policy concepts and vocabulary. > >>> 3) A set of YANG data models consisting of a base policy model for > > representing > >> policy management concepts independent of the type > >>> or structure of a policy, plus an extension for defining policy > >>> rules > > according to > >> the event-condition-action paradigm. Another > >>> extension for defining policy rules according to a declarative, or > > intent-based, > >> paradigm, may be produced. These models will be > >>> designed to be generic and extensible. > >>> > >>> 4) An applicability document providing a few examples that > >>> demonstrate how > >> the generic policy models can be used to express > >>> policies that are relevant for network operators. The examples may > >>> tie into > >> configuration models or network service models > >>> developed by other working groups. > >>> > >>> The working group will decide how the work items are best mapped > >>> into > >> deliverables. > >>> This working group will be a success when the SUPA policy constructs > >>> are re- > >> used in future IETF specifications (and, ideally, > >>> specifications from other SDOs), in a manner that will save > >>> development time > >> and avoid inconsistencies between data models > >>> developed by different working groups. In the meantime, SUPA should > >>> not > >> impede work in other working groups while waiting for SUPA > >>> to produce its deliverables. > >>> > >>> The working group will communicate with other SDOs (MEF, TMF, ETSI) > >>> that are > >> working on related issues. > >>> Milestones: > >>> > >>> TBD > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Supa mailing list > >>> Supa@ietf.org > >>> https://www.ietf.org/mailman/listinfo/supa > >> _______________________________________________ > >> Supa mailing list > >> Supa@ietf.org > >> https://www.ietf.org/mailman/listinfo/supa > > . > > > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > --001a11c34238762ed5051d238920 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Aug 12, 2015 at 1:38 PM, Natale, Bob <RNATALE@mitre.org>= ; wrote:
+1 from me on this point = from Adrian's message below* in particular: "SUPA should bundle al= l of the thought around policy models in one place as a starting point"= ;.

Fragmentation of PBNM solutions has resulted from the lack of standardizati= on in the face of significant need ... the need is only growing as the requ= irements intended to be satisfied by the emerging technologies supporting n= etwork services virtualization (among many other drivers) raise the urgency= of governed automation ... this is an opportunity for the IETF to restart = in this challenging area (PBNM) and SUPA is a promising locus for the start= ing point (IMHO).

[* - Taken a little out of context, it's true ... but only a little. :)= ]


IMO, the significant component here is= network-level NM.
This is new territory for the IETF.=C2=A0 As w= e dig into "framework issues"
there are some common com= ponents that keep coming up:

=C2=A0 =C2=A0- topolo= gy database (query by attribute)
=C2=A0 =C2=A0- AAA (identity and= authorization, logging)
=C2=A0 =C2=A0- inventory/capabilities

The need for cross-WG and cross-area coordinati= on has never been greater.=C2=A0

Whether it&= #39;s I2RS or PBNM or anything at the network level,
there are co= mmon problems dealing with NEs that must
be solved.=C2=A0 Let'= ;s make sure the foundation gets built before
the roof.




Avanti,
BobN

Andy
=C2=A0

-----Original Message-----
From: Supa [mailto:supa-bounces@ie= tf.org] On Behalf Of Benoit Claise
Sent: Wednesday, August 12, 2015 11:05 AM
To: adrian@olddog.co.uk; 'Be= rt Wijnen (IETF)' <bwietf@bwij= nen.net>; supa@ietf.org
Cc: 'Eggert, Lars' <lars@neta= pp.com>; ibnemo@ietf.org
Subject: Re: [Supa] SUPA charter proposal

+1 to what Adrian wrote.

Regards, B.
> Hi Bert,
>
> I don't think you are reading the proposed charter for SUPA right = if
> you think it precludes the formation of a working group for IBNEMO. > Rather, the text that Benoit has published says that SUPA is not the > working group that works on IBNEMO.
>
> But maybe you are saying that the intent-based part of the SUAP
> charter could be lifted out and placed in an IBNEMO work effort. That = might be reasonable.
>
> However, there is a separation between the use of existing data
> modeling and protocols (such as YANG with NETCONF) and the development=
> of a new and specialised modeling language and communication protocol.=
> I believe that this charter text opens up the investigation of the
> practicalities of intent-based policy modeling in order to determine > whether such things could be modeled in existing languages or whether = new work is needed a priori.
>
> If, for example, it was possible to encode intent-based policy in
> YANG, that would not preclude IBNEMO inventing something different/bet= ter/worse.
>
> Now there it seems sensible that SUPA should bundle all of the thought=
> around policy models in one place as a starting point. If it is later<= br> > desirable to split off the intent-based part (say after the initial > investigation and information models) that doesn't seem like a bad= thing.
>
> Alternatively, if there is a strong pull to move all of the
> intent-based work out from day one, I will not be complaining.
>
> Cheers,
> Adrian
>
>> -----Original Message-----
>> From: Supa [mailto:supa-b= ounces@ietf.org] On Behalf Of Bert Wijnen
>> (IETF)
>> Sent: 07 August 2015 19:46
>> To: Benoit Claise; supa@ietf.org<= /a>
>> Cc: Eggert, Lars; ibnemo@ietf.o= rg
>> Subject: Re: [Supa] SUPA charter proposal
>>
>> Hi Benoit and others.
>>
>> So would this work prevent the formation of a WG that would do IBN= EMO
>> (Intent Based NEtwork MOdeling) work? I certainly hope not. In the=
>> charter you have:
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(iii) the working group will inve= stigate the practically of
>> building
> policy rules
>> that declaratively
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0specify what= goals to achieve (this is often called
> "intent-based" policy) but
>> not how to achieve
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0those goals = and may create a model accordingly.
>>
>>
>> IBNEMO intends (no pun intended) to define/standardize a Intent >> expression language.
>> The work you describe above can be input to the work IBNEMO wants = to do.
>>
>> Bert
>>
>> On 07/08/15 18:03, Benoit Claise wrote:
>>> Dear all,
>>>
>>> As promised in my last email ("SUPA: Situation Summary an= d Next
>>> Steps"),
> here
>> is a proposed charter.
>>> Thanks to Robert Sparks, Adrian Farrel, and Dan Romascanu.
>>>
>>> Hopefully, this new version will clarify the situation, and wi= ll be
> acceptable to
>> everybody.
>>> Please let us know. Note: I prefer to keep the edit token from= now.
>>>
>>> Regards, Benoit (OPS AD)
>>>
>>>
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>> SUPA CHARTER PROPOSAL (2015-08-07)
>>>
>>> Policy is an important configurable component in the delivery = of
>>> services
> and
>> the operation of networks. Operators want and need
>>> to be able to determine the policies that apply to their diffe= rent
>>> customers
> and
>> to the equipment that comprises their physical
>>> and virtual networks. As policy spans such a wide range of ser= vices
>>> and
> device
>> types, it will be helpful if there is a common way
>>> of expressing and describing policies that is uniform and cons= istent
>>> in all
>> environments. Such an approach will help to avoid
>>> configuration errors that arise from confusion between differe= nt
>>> systems,
> will
>> enable easy understanding of policies that apply in
>>> different environments, will make the implementation of policy= -based
>>> systems
>> quicker and cheaper, and will facilitate the rapid
>>> development of standards-based data models that include policy= elements.
>>>
>>> SUPA (Simplified Use of Policy Abstractions) defines a model t= o
>>> interface
> with a
>> network management function (within a controller,
>>> an orchestrator, a network element) that takes high-level, pos= sibly
>>> network-
>> wide policies as input. SUPA will not define what the
>>> function does with that input but anticipates that it will
>>> ultimately result
> in
>> network configuration changes
>>> Practically, SUPA will define generic YANG data models to enco= de
>>> policy,
> which
>> can point to device-, technology-, and
>>> service-specific YANG models of other working groups.
>>>
>>> SUPA will be designed to work with device, protocol, network, = and
>>> service
> data
>> models.
>>> The SUPA working group will develop a model for expressing pol= icy at
> different
>> levels of abstraction.Specifically, three model
>>> fragments are envisioned: (i) a generic model that defines con= cepts
>>> and
>> vocabulary needed by policy management independent of the
>>> form and content of the policy, (ii) a more specific model tha= t
>>> refines the
>> generic model to specify how to build policy rules of
>>> the event-condition-action paradigm, and (iii) the working gro= up
>>> will
> investigate
>> the practically of building policy rules that
>>> declaratively specify what goals to achieve (this is often cal= led
> "intent-based"
>> policy) but not how to achieve those goals and
>>> may create a model accordingly.
>>>
>>> If the working group finds it necessary to work on an informat= ion
>>> model
> before
>> the data model, to help provide guidance and derive
>>> the data models, it might do so. The working group will decide= later
>>> whether
>> the information model needs to be published as an RFC.
>>> Out of scope of this working group is:
>>>
>>> -The specification of a new policy language. The YANG data mod= els
>>> are to be
>> used with protocols such as NETCONF/RESTCONF.
>>> -Design of protocol-specific policies and specific design for<= br> >>> embedded
> policies in
>> network elements (which are usually interpreted
>>> in isolation, and often at timescales that require optimizatio= n for
>>> specific
>> purposes).
>>> -Specific handling of policies (although the application docum= ent
>>> will
> provide
>> some examples), and therefore the specification of
>>> a policy engine that maps a specific policy instance to actual=
>>> configuration
>> snippets.
>>> List of work items:
>>>
>>> 1) A document that explains the scope of the policy-based mana= gement
>> framework and how it relates to existing work of the IETF.
>>> 2) If the working group considers it necessary, an information= model
> composed
>> of policy concepts and vocabulary.
>>> 3) A set of YANG data models consisting of a base policy model= for
> representing
>> policy management concepts independent of the type
>>> or structure of a policy, plus an extension for defining polic= y
>>> rules
> according to
>> the event-condition-action paradigm. Another
>>> extension for defining policy rules according to a declarative= , or
> intent-based,
>> paradigm, may be produced. These models will be
>>> designed to be generic and extensible.
>>>
>>> 4) An applicability document providing a few examples that
>>> demonstrate how
>> the generic policy models can be used to express
>>> policies that are relevant for network operators. The examples= may
>>> tie into
>> configuration models or network service models
>>> developed by other working groups.
>>>
>>> The working group will decide how the work items are best mapp= ed
>>> into
>> deliverables.
>>> This working group will be a success when the SUPA policy cons= tructs
>>> are re-
>> used in future IETF specifications (and, ideally,
>>> specifications from other SDOs), in a manner that will save >>> development time
>> and avoid inconsistencies between data models
>>> developed by different working groups. In the meantime, SUPA s= hould
>>> not
>> impede work in other working groups while waiting for SUPA
>>> to produce its deliverables.
>>>
>>> The working group will communicate with other SDOs (MEF, TMF, = ETSI)
>>> that are
>> working on related issues.
>>> Milestones:
>>>
>>> TBD
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Supa mailing list
>>> Supa@ietf.org
>>> https://www.ietf.org/mailman/listinfo/supa
>> _______________________________________________
>> Supa mailing list
>> Supa@ietf.org
>> https://www.ietf.org/mailman/listinfo/supa > .
>

_______________________________________________
Supa mailing list
Supa@ietf.org
https://www.ietf.org/mailman/listinfo/supa

_______________________________________________
Supa mailing list
Supa@ietf.org
https://www.ietf.org/mailman/listinfo/supa

--001a11c34238762ed5051d238920-- From nobody Thu Aug 13 00:55:11 2015 Return-Path: X-Original-To: ibnemo@ietfa.amsl.com Delivered-To: ibnemo@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5621ACD3F; Sun, 9 Aug 2015 08:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.701 X-Spam-Level: X-Spam-Status: No, score=-100.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 yuO81M4rUzZW; Sun, 9 Aug 2015 08:23:27 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25EEC1ACCFF; Sun, 9 Aug 2015 08:23:26 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t79FNMS5016469; Sun, 9 Aug 2015 16:23:22 +0100 Received: from 950129200 (79.135.99.37.dsl.gradwelldsl.co.uk [79.135.99.37] (may be forged)) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t79FNLSu016459 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 9 Aug 2015 16:23:21 +0100 From: "Adrian Farrel" To: "'Bert Wijnen \(IETF\)'" , "'Benoit Claise'" , References: <55C4D6C1.5040504@cisco.com> <55C4FCFE.8070701@bwijnen.net> In-Reply-To: <55C4FCFE.8070701@bwijnen.net> Date: Sun, 9 Aug 2015 16:23:22 +0100 Message-ID: <023101d0d2b7$54dad4e0$fe907ea0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIGDj3FnqOFLnABOhC256xK4GCt4gLk/N/WnYInRHA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-8.0.0.1202-21736.000 X-TM-AS-Result: No--41.105-10.0-31-10 X-imss-scan-details: No--41.105-10.0-31-10 X-TMASE-MatchedRID: 8HTFlOrbAtFqJ1y0VLNhDhfY306nA3bo3vw1aViiOStF+YXPIqAdvgwz pJH2EUIxyEaIaV9pDRx7fWQyyQ7Sr9h8848Kmd8CsyNb+yeIRArDHSNFHFxB81yzCdM9a+X535d D76rzBfdxoubsTd+Wmr91i/pszylKq87gT7hcKkKVSBCoZUyqbEViEkleYcYvehnlgrviZRDC5q eIz1BfLXLR6g9sJbl/aqmzuJ5+/UX1Ht3BefL9t8WUKBjERoYTttKJDdalq/WGamsjhYpC2S+Rl KpTJ8VeZTqkTWkX/t0xUzoUIepvu4Dg4EsX82OcmlaAItiONP1F0vHVf0FWQM2r9z7B+jUR78mn g1Xqld+UYPmtQW7/Be3eUWy6Operw+ugPgIrDd1hHpATwph+yDoSfZud5+Gg6h3Xfd5VY/ghUoj ydQDQcJyujnvWzBE43nAtXqzB0JEReJdaDf25jhcqpH7D1rtQmdrHMkUHHq+VEMx1gSjhQGlc6Z 4uvXD0OsNfUzzLYoCvxSlbcA6wU8xx7KSxS0IXa0aUozXm0DbQAMcwVYPxQ8eQfu6iwSfsFnrzJ SdcWB/60MKu8JffAb1dT2vyRTj9ZNd6b+A+51oKYSf7LxJrxjTbofuc5kuvpzM0YVFmq6ZqvagD uCl+7a5JjIv8jAPrdu4LsptAUomEdHBh//D9D3BRIrj8R47F6Jj6zYvfFASctWHPLT5FfYThNus NaFryGef01jTWdOny8CgcvMUqj97dkvf0Tf5WqeBupNgLgYcrHkgIan9a0b8OwDt1RiPOwOWnbw sz43KPWZvDr+0qazwxeGjpS2MHSpebgw+pOvaeAiCmPx4NwLTrdaH1ZWqCpvI8UZOf47jUZxEAl FPo846HM5rqDwqtlExlQIQeRG0= Archived-At: X-Mailman-Approved-At: Thu, 13 Aug 2015 00:55:07 -0700 Cc: "'Eggert, Lars'" , ibnemo@ietf.org Subject: Re: [Ibnemo] [Supa] SUPA charter proposal X-BeenThere: ibnemo@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "Discussion of Nemo, an intent-based North Bound \(NB\) interface consisting of an application protocol running over HTTP \(RESTful interfaces\) to exchange intent-based primitives between applications and meta-controllers controlling virtual network resources \(networks, storage, CPU\)." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2015 15:23:29 -0000 Hi Bert, I don't think you are reading the proposed charter for SUPA right if you think it precludes the formation of a working group for IBNEMO. Rather, the text that Benoit has published says that SUPA is not the working group that works on IBNEMO. But maybe you are saying that the intent-based part of the SUAP charter could be lifted out and placed in an IBNEMO work effort. That might be reasonable. However, there is a separation between the use of existing data modeling and protocols (such as YANG with NETCONF) and the development of a new and specialised modeling language and communication protocol. I believe that this charter text opens up the investigation of the practicalities of intent-based policy modeling in order to determine whether such things could be modeled in existing languages or whether new work is needed a priori. If, for example, it was possible to encode intent-based policy in YANG, that would not preclude IBNEMO inventing something different/better/worse. Now there it seems sensible that SUPA should bundle all of the thought around policy models in one place as a starting point. If it is later desirable to split off the intent-based part (say after the initial investigation and information models) that doesn't seem like a bad thing. Alternatively, if there is a strong pull to move all of the intent-based work out from day one, I will not be complaining. Cheers, Adrian > -----Original Message----- > From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Bert Wijnen (IETF) > Sent: 07 August 2015 19:46 > To: Benoit Claise; supa@ietf.org > Cc: Eggert, Lars; ibnemo@ietf.org > Subject: Re: [Supa] SUPA charter proposal > > Hi Benoit and others. > > So would this work prevent the formation of a WG that would do IBNEMO (Intent > Based NEtwork MOdeling) > work? I certainly hope not. In the charter you have: > > (iii) the working group will investigate the practically of building policy rules > that declaratively > specify what goals to achieve (this is often called "intent-based" policy) but > not how to achieve > those goals and may create a model accordingly. > > > IBNEMO intends (no pun intended) to define/standardize a Intent expression > language. > The work you describe above can be input to the work IBNEMO wants to do. > > Bert > > On 07/08/15 18:03, Benoit Claise wrote: > > Dear all, > > > > As promised in my last email ("SUPA: Situation Summary and Next Steps"), here > is a proposed charter. > > Thanks to Robert Sparks, Adrian Farrel, and Dan Romascanu. > > > > Hopefully, this new version will clarify the situation, and will be acceptable to > everybody. > > Please let us know. Note: I prefer to keep the edit token from now. > > > > Regards, Benoit (OPS AD) > > > > > ============================================================== > > > > SUPA CHARTER PROPOSAL (2015-08-07) > > > > Policy is an important configurable component in the delivery of services and > the operation of networks. Operators want and need > > to be able to determine the policies that apply to their different customers and > to the equipment that comprises their physical > > and virtual networks. As policy spans such a wide range of services and device > types, it will be helpful if there is a common way > > of expressing and describing policies that is uniform and consistent in all > environments. Such an approach will help to avoid > > configuration errors that arise from confusion between different systems, will > enable easy understanding of policies that apply in > > different environments, will make the implementation of policy-based systems > quicker and cheaper, and will facilitate the rapid > > development of standards-based data models that include policy elements. > > > > SUPA (Simplified Use of Policy Abstractions) defines a model to interface with a > network management function (within a controller, > > an orchestrator, a network element) that takes high-level, possibly network- > wide policies as input. SUPA will not define what the > > function does with that input but anticipates that it will ultimately result in > network configuration changes > > > > Practically, SUPA will define generic YANG data models to encode policy, which > can point to device-, technology-, and > > service-specific YANG models of other working groups. > > > > SUPA will be designed to work with device, protocol, network, and service data > models. > > > > The SUPA working group will develop a model for expressing policy at different > levels of abstraction.Specifically, three model > > fragments are envisioned: (i) a generic model that defines concepts and > vocabulary needed by policy management independent of the > > form and content of the policy, (ii) a more specific model that refines the > generic model to specify how to build policy rules of > > the event-condition-action paradigm, and (iii) the working group will investigate > the practically of building policy rules that > > declaratively specify what goals to achieve (this is often called "intent-based" > policy) but not how to achieve those goals and > > may create a model accordingly. > > > > If the working group finds it necessary to work on an information model before > the data model, to help provide guidance and derive > > the data models, it might do so. The working group will decide later whether > the information model needs to be published as an RFC. > > > > Out of scope of this working group is: > > > > -The specification of a new policy language. The YANG data models are to be > used with protocols such as NETCONF/RESTCONF. > > > > -Design of protocol-specific policies and specific design for embedded policies in > network elements (which are usually interpreted > > in isolation, and often at timescales that require optimization for specific > purposes). > > > > -Specific handling of policies (although the application document will provide > some examples), and therefore the specification of > > a policy engine that maps a specific policy instance to actual configuration > snippets. > > > > List of work items: > > > > 1) A document that explains the scope of the policy-based management > framework and how it relates to existing work of the IETF. > > > > 2) If the working group considers it necessary, an information model composed > of policy concepts and vocabulary. > > > > 3) A set of YANG data models consisting of a base policy model for representing > policy management concepts independent of the type > > or structure of a policy, plus an extension for defining policy rules according to > the event-condition-action paradigm. Another > > extension for defining policy rules according to a declarative, or intent-based, > paradigm, may be produced. These models will be > > designed to be generic and extensible. > > > > 4) An applicability document providing a few examples that demonstrate how > the generic policy models can be used to express > > policies that are relevant for network operators. The examples may tie into > configuration models or network service models > > developed by other working groups. > > > > The working group will decide how the work items are best mapped into > deliverables. > > > > This working group will be a success when the SUPA policy constructs are re- > used in future IETF specifications (and, ideally, > > specifications from other SDOs), in a manner that will save development time > and avoid inconsistencies between data models > > developed by different working groups. In the meantime, SUPA should not > impede work in other working groups while waiting for SUPA > > to produce its deliverables. > > > > The working group will communicate with other SDOs (MEF, TMF, ETSI) that are > working on related issues. > > > > Milestones: > > > > TBD > > > > > > > > > > _______________________________________________ > > Supa mailing list > > Supa@ietf.org > > https://www.ietf.org/mailman/listinfo/supa > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa