From nobody Fri Jul 1 08:37:35 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8560912D743 for ; Fri, 1 Jul 2016 08:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 fhW1GdXsIbrT for ; Fri, 1 Jul 2016 08:37:24 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 4106212D746 for ; Fri, 1 Jul 2016 08:37:10 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 1E8E0BB798415; Fri, 1 Jul 2016 15:37:05 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u61Fb7Tm008523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Jul 2016 15:37:08 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u61FZpbG001477 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Jul 2016 17:37:07 +0200 Received: from [172.27.205.111] (135.239.27.40) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 1 Jul 2016 17:36:15 +0200 To: "anima-chairs@tools.ietf.org" , "anima@ietf.org" References: <5D36713D8A4E7348A7E10DF7437A4B927CA89427@NKGEML515-MBX.china.huawei.com> From: Laurent Ciavaglia Organization: Nokia Bell Labs Message-ID: Date: Fri, 1 Jul 2016 17:36:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B927CA89427@NKGEML515-MBX.china.huawei.com> Content-Type: multipart/alternative; boundary="------------2C303D9FA34A8F240DF70DDA" X-Originating-IP: [135.239.27.40] Archived-At: Subject: Re: [Anima] Call for agenda ANIMA @ IETF 96, Berlin, Germany X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 15:37:27 -0000 --------------2C303D9FA34A8F240DF70DDA Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Dear Sheng and Toerless, ANIMA WG, We kindly ask for the following time slots: _Slot #1_ -Name of time slot: Autonomic Functions Coordination By The Example. -Name of draft(s): draft-ciavaglia-anima-coordination-01, draft-peloso-anima-autonomic-function-01 -Time requested: minimum 20 minutes (we need to run through the example to make the demonstration useful) -Presenter name(s): Laurent Ciavaglia, Pierre Peloso. -Brief description of what issues need discussing and what you hope to accomplish by presenting (please focus on open issues, rather than a status update): The presentation will show how AF interactions (e.g. conflicts) are identified and resolved with concrete examples, mapped to the ANIMA components and outline new requirements. The goal is to expose the importance of coordination as a special role ASA and the need to define the appropriate mechanism/specifications to support it efficiently in the ANIMA framework. _Slot #2_ -Name of time slot: Autonomic Functions Life-cycle and Management. -Name of draft(s): draft-peloso-anima-autonomic-function-01 -Time requested: 15 minutes -Presenter name(s): Laurent Ciavaglia, Pierre Peloso. -Brief description of what issues need discussing and what you hope to accomplish by presenting (please focus on open issues, rather than a status update): The presentation proposes a life-cycle for autonomic functions and describes what common management components are needed to support the deployment and operation of autonomic functions in the ANIMA framework, and how they could be mapped wrt. the ANI. _Slot #3_ -Name of time slot: ANIMA Intent Policy. -Name of draft(s): draft-du-anima-an-intent-03 -Time requested: 10 minutes (+enough time to discuss with the WG about way forward) -Presenter name(s): One of the I-D authors. -Brief description of what issues need discussing and what you hope to accomplish by presenting (please focus on open issues, rather than a status update): Update on the definition and use of Intent in the ANIMA framework and discuss way forward. Thanks, best regards, Laurent. On 28/06/2016 16:35, Sheng Jiang wrote: > Hi, all anima, > > We have requested two sessions of 2 hour + 2 hour for the ANIMA WG meeting for IETF-96 (Berlin, Germany) and are starting to collect agenda items for these sessions. Same with previous IETF meetings, we do not reserve the second session for non-charter work items. It says the charter work item would have priority. We will only discuss non-charter work items till we finish charter work items. However, we do have a longer second session. So, hopefully, we could have more time for discussion of non-charter work items. The priority among these non-charter work items would be: these that have active discussion in mail list, > then these have submitted drafts, and topics without drafts. > > Please send us (anima-chairs at tools.ietf.org) requests for sessions by March 3rd, Thursday (IETF requests the preliminary agenda by July 6th, Wednesday) and include: > Name of time slot: > Name of draft(s): > Time requested: > Presenter name(s): > Brief description of what issues need discussing and what you hope to > accomplish by presenting (please focus on open issues, rather than a > status update): > > More details about the IETF 96, Berlin, Germany can be found at: > http://www.ietf.org/meeting/96/index.html > > Again, presenters and draft authors please invoke active discussions in > the ANIMA list. We have very limited time for each topic in the > face-to-face meeting. Mail list is a very good place to discuss and reach > consensus on technical issues. > > Best regards, > > Toerless & Sheng > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > --------------2C303D9FA34A8F240DF70DDA Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit Dear Sheng and Toerless, ANIMA WG,

We kindly ask for the following time slots:

Slot #1
    -Name of time slot: Autonomic Functions Coordination By The Example.
    -Name of draft(s): draft-ciavaglia-anima-coordination-01, draft-peloso-anima-autonomic-function-01
    -Time requested: minimum 20 minutes (we need to run through the example to make the demonstration useful)
    -Presenter name(s): Laurent Ciavaglia, Pierre Peloso.
    -Brief description of what issues need discussing and what you hope to
    accomplish by presenting (please focus on open issues, rather than a
    status update): The presentation will show how AF interactions (e.g. conflicts) are identified and resolved with concrete examples, mapped to the ANIMA components and outline new requirements. The goal is to expose the importance of coordination as a special role ASA and the need to define the appropriate mechanism/specifications to support it efficiently in the ANIMA framework.


Slot #2
    -Name of time slot: Autonomic Functions Life-cycle and Management.
    -Name of draft(s): draft-peloso-anima-autonomic-function-01
    -Time requested: 15 minutes
    -Presenter name(s): Laurent Ciavaglia, Pierre Peloso.
    -Brief description of what issues need discussing and what you hope to
    accomplish by presenting (please focus on open issues, rather than a
    status update): The presentation proposes a life-cycle for autonomic functions and describes what common management components are needed to support the deployment and operation of autonomic functions in the ANIMA framework, and how they could be mapped wrt. the ANI.


Slot #3
    -Name of time slot: ANIMA Intent Policy.
    -Name of draft(s): draft-du-anima-an-intent-03
    -Time requested: 10 minutes (+enough time to discuss with the WG about way forward)
    -Presenter name(s): One of the I-D authors.
    -Brief description of what issues need discussing and what you hope to
    accomplish by presenting (please focus on open issues, rather than a
    status update): Update on the definition and use of Intent in the ANIMA framework and discuss way forward.


Thanks, best regards, Laurent.


On 28/06/2016 16:35, Sheng Jiang wrote:
Hi, all anima,

We have requested two sessions of 2 hour + 2 hour for the ANIMA WG meeting for IETF-96 (Berlin, Germany) and are starting to collect agenda items for these sessions. Same with previous IETF meetings, we do not reserve the second session for non-charter work items. It says the charter work item would have priority. We will only discuss non-charter work items till we finish charter work items. However, we do have a longer second session. So, hopefully, we could have more time for discussion of non-charter work items. The priority among these non-charter work items would be: these that have active discussion in mail list,
then these have submitted drafts, and topics without drafts.

Please send us (anima-chairs at tools.ietf.org) requests for sessions by March 3rd, Thursday (IETF requests the preliminary agenda by July 6th, Wednesday) and include:
Name of time slot:
Name of draft(s):
Time requested:
Presenter name(s):
Brief description of what issues need discussing and what you hope to
accomplish by presenting (please focus on open issues, rather than a
status update):

More details about the IETF 96, Berlin, Germany can be found at:
http://www.ietf.org/meeting/96/index.html

Again, presenters and draft authors please invoke active discussions in
the ANIMA list. We have very limited time for each topic in the
face-to-face meeting. Mail list is a very good place to discuss and reach
consensus on technical issues.

Best regards,

Toerless & Sheng
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
--------------2C303D9FA34A8F240DF70DDA-- From nobody Fri Jul 1 08:51:18 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A897412D0E8; Fri, 1 Jul 2016 08:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 nIsET8qgnYSB; Fri, 1 Jul 2016 08:51:14 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 35FCD12B034; Fri, 1 Jul 2016 08:51:13 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 4814970B2E64B; Fri, 1 Jul 2016 15:51:08 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u61FpBGX001205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Jul 2016 15:51:11 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u61FnvXE022797 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Jul 2016 17:51:10 +0200 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.32]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Fri, 1 Jul 2016 17:50:32 +0200 From: "Peloso, Pierre (Nokia - FR)" To: "Michael Behringer (mbehring)" , Brian E Carpenter , Sheng Jiang , "anima@ietf.org" , "draft-ietf-anima-grasp.all@ietf.org" Thread-Topic: [Anima] Review of ANIMA GRASP Thread-Index: AdHOAKVW9zaHlVYpQ3uXL2ArHwfX1wAsG4IAANFcArAANXv/0AAze/lg Date: Fri, 1 Jul 2016 15:50:32 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Review of ANIMA GRASP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 15:51:16 -0000 SGkgQnJpYW4sIFNoZW5nLCBNaWNoYWVsIGFuZCBhbGwsDQoNClBsZWFzZSBzZWUgYWRkaXRpb25h bCBjb21tZW50cyBpbi1saW5lLA0KTm90aW5nIHRoYXQgdGhlcmUgYXJlIHR3byBwb2ludHMgYW1v bmcgbXkgZm9sbG93aW5nIGNvbW1lbnRzIHdoaWNoIGFyZSBsaW5rZWQgdG8gZGlzY3Vzc2lvbnMg aGVsZCBhdCB0aGUgd29ya3Nob3Agb24gQU4gd2UgaGFkIGluIEF0aGVucy4NCg0KVGhhbmtzIGZv ciB0aGVzZSBkaXNjdXNzaW9ucywNCg0KUGllcnJlDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2lu ZS0tLS0tDQo+IERlwqA6IEFuaW1hIFttYWlsdG86YW5pbWEtYm91bmNlc0BpZXRmLm9yZ10gRGUg bGEgcGFydCBkZSBNaWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpDQo+IEVudm95w6nCoDogbWVy Y3JlZGkgMjkganVpbiAyMDE2IDE3OjAxDQo+IMOAwqA6IEJyaWFuIEUgQ2FycGVudGVyOyBTaGVu ZyBKaWFuZzsgYW5pbWFAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtYW5pbWEtDQo+IGdyYXNwLmFsbEBp ZXRmLm9yZw0KPiBPYmpldMKgOiBSZTogW0FuaW1hXSBSZXZpZXcgb2YgQU5JTUEgR1JBU1ANCj4g DQo+ID4gPiBCZWZvcmUgaW50byBkZXRhaWxzLCBpbiBnZW5lcmFsIHRoZSBjdXJyZW50IHRleHQg c3RpbGwgaGF2ZSByb29tIHRvDQo+ID4gPiBpbXByb3ZlDQo+ID4gcmVnYXJkaW5nIHRvIGNsZWFy bHkgZGlzdGluZ3Vpc2ggdGhlIHRhcmdldCwgcm9sZSBhbmQgcmVzcG9uc2liaWxpdHkNCj4gPiBv ZiBHUkFTUCwgQVNBcyBhbmQgYXV0b25vbWljIG5ldHdvcmsgYXMgYSB3aG9sZS4NCj4gPg0KPiA+ IFllcywgYWx0aG91Z2ggb2YgY291cnNlIHNvbWUgb2YgdGhhdCBtYXRlcmlhbCBpbnRlcnNlY3Rz IHdpdGggdGhlDQo+ID4gUmVmZXJlbmNlIE1vZGVsIGRvY3VtZW50LiBJIHRoaW5rIHdlIGFsc28g bmVlZCBzb21lIGRlZXAgcmV2aWV3cyBvZg0KPiA+IHRoZSBSZWZlcmVuY2UgTW9kZWwgdG8gZ2V0 IHRoaXMgYXNwZWN0IGNvcnJlY3QuDQo+IA0KPiBZZXMsIHRoZSByZWZlcmVuY2UgbW9kZWwgc2hv dWxkIGdpdmUgdGhlIGdlbmVyYWwgb3ZlcnZpZXcsIHNvIHRoaXMgZGlzY3Vzc2lvbiBzaG91bGQN Cj4gdG8gYSBsYXJnZSBleHRlbnQgZ28gdGhlcmUuDQpTZWVtcyBmYWlyIHRvIG1lIHRvIGhhdmUg c29tZSBtb3JlIG9mIHRoZXNlIGluIHRoZSByZWZlcmVuY2UgbW9kZWwuDQpJbnNpZGUgZHJhZnQt cGVsb3NvLWFuaW1hLWF1dG9ub21pYy1mdW5jdGlvbiwgdGhlcmUgaXMgdGV4dCBvbiB0aGUgcm9s ZSBvZiBBU0EgYW5kIHRoZWlyIG1hbmFnZW1lbnQuDQpXaHkgbm90IGJ1aWxkaW5nIHVwb24gaXQg Pw0KDQo+IA0KPiBIYXZpbmcgc2FpZCB0aGlzLCB3ZSBoYXZlbid0IHNlZW4gbWFueSBjb21tZW50 cyBvbiB0aGF0IHBhcnQgb2YgdGhlIHJlZmVyZW5jZSBtb2RlbCwNCj4gYW5kIHNvbWUgcmV2aWV3 cyB3b3VsZCByZWFsbHkgYmUgaGVscGZ1bC4gVGhpcyBpcyBpbiBwYXJ0aWN1bGFyIHNlY3Rpb24g NSwgaWYgc29tZW9uZQ0KPiB3YW50cyB0byBkaXZlIHN0cmFpZ2h0IGludG8gdGhhdCBwYXJ0Lg0K PiANCj4gPiA+IFRoaXJkIHBhcmFncmFwaCBvZiBTZWN0aW9uIDEsIOKAnE5lZ290aWF0aW9uIGlz IOKApiBiZXR3ZWVuIHRoZQ0KPiA+ID4gbmVnb3RpYXRpbmcNCj4gPiBkZXZpY2Vz4oCdLiAgSXMg aXQgcG9zc2libGUgdG8gbmVnb3RpYXRlIGJldHdlZW4gQVNBcyBvciBpbnN0YW5jZXMgaW4gYQ0K PiA+IHNhbWUgZGV2aWNlPw0KPiA+DQo+ID4gSSBjYW4gYW5zd2VyIGZvciBteSBwcm90b3R5cGUg Y29kZTogeWVzLiBJIGNhbiBzaG93IHlvdSB0aGlzIGluDQo+ID4gQmVybGluOiB0aHJlZSBBU0Fz IG5lZ290aWF0aW5nIHNpbXVsdGFuZW91c2x5IGluIG15IGxhcHRvcCwgd2l0aCB0aHJlZQ0KPiA+ IGluc3RhbmNlcyBvZiBHUkFTUCBydW5uaW5nIGluIGZhY3QuIChUaGFua3MgdG8gVG9lcmxlc3M7 IHRoaXMgd29ya3MNCj4gPiBiZWNhdXNlIGhlIHBlcnN1YWRlZCB1cyB0byBjaGFuZ2UgdG8gYSBz ZXBhcmF0ZSBUQ1AgcG9ydCBmb3IgZWFjaA0KPiA+IGluc3RhbmNlLikNCj4gDQo+IC4uLiBhbmQg aXQgTVVTVCBiZSBwb3NzaWJsZS4gV2UndmUganVzdCBoYWQgdGhlIHdvcmtzaG9wIG9uIEFOIGlu IEF0aGVucywgYW5kIG9uZSBiaWcNCj4gZGlzY3Vzc2lvbiBwb2ludCB3YXMgdGhlIGNvb3JkaW5h dGlvbiBmdW5jdGlvbi4gV2hpbGUgd2UgaGF2ZW4ndCBjb25jbHVkZWQgd2hldGhlcg0KPiB0aGlz IGNvb3JkaW5hdGlvbiBmdW5jdGlvbiBpcyBpdHNlbGYgYW4gQVNBIG9yIHBhcnQgb2YgdGhlIGlu ZnJhc3RydWN0dXJlLCB3ZSBkbyBOT1QNCj4gd2FudCB0byBtYWtlIGl0IHRlY2huaWNhbGx5IGlt cG9zc2libGUgZm9yIGEgY29vcmRpbmF0aW9uIGZ1bmN0aW9uIHRvIGJlIGFuIEFTQS4gVGhpcw0K PiBpcyBhIGdvb2QgZXhhbXBsZSBvZiB0d28gQVNBcyBvbiB0aGUgc2FtZSBkZXZpY2UgaGF2aW5n IHRvIGNvbW11bmljYXRlLg0KQXQgdGhpcyBwb2ludCAyIGNvbW1lbnRzOg0KICAgMSAtIFRoZXJl IG1heSBkZWZpbml0ZWx5IGJlIHR3byBkaWZmZXJlbnQgQVNBcyB3aWxsaW5nIHRvIG1vZGlmeSB0 aGUgc2FtZSBkZXZpY2UgcGFyYW1ldGVyLi4uDQogICAyIC0gTWljaGFlbCBpcyBkZWFsaW5nIGhl cmUgd2l0aCB0aGUgcm9sZSBvZiBjb29yZGluYXRpb24gZnVuY3Rpb24gd2l0aCByZWdhcmRzIHRv IEdSQVNQOiBEdXJpbmcgdGhlIFdTIGRpc2N1c3Npb25zLCAgdGhlcmUgd2FzIGEgc29ydCBvZiBz b2Z0LWFncmVlbWVudCB0aGF0OiANCiAgICAgICAgICAgLSBjb29yZGluYXRpb24gZnVuY3Rpb24g Y2FuIGJlIGRpc3RyaWJ1dGVkLA0KICAgICAgICAgICAtIGNvb3JkaW5hdGlvbiBmdW5jdGlvbiBp bnN0YW5jZXMgc2hvdWxkIGNvbnRhaW4gYSBHUkFTUCBjbGllbnQsDQogICAgICAgICAgIC0gaXQg d2FzIG5vdCBjbGVhciB5ZXQgd2hldGhlciBjb29yZGluYXRpb24gd291bGQgYmUgY29tcGxldGVs eSBleHRlcm5hbCB0byBBTkkgKGxpa2UgQVNBIHNpdHRpbmcgb24gdG9wIG9mIEFOSSksIG9yIHdv dWxkIGhhdmUgc29tZSBwaWVjZXMgZW1iZWRkZWQgaW4gQU5JLg0KQ291bGQgd2UgZ2V0IGZlZWQt YmFjayBmcm9tIHRoZSBXRyB0aGVyZSAod2hldGhlciB0aGUgaHlwb3RoZXNpcyBzdGF0ZWQgYWJv dmUgYXJlIGFjY2VwdGFibGUsIGFuZCB3aGV0aGVyIHRoZXkgbWF5IHByZXZlbnQgc29tZXRoaW5n IGZyb20gd29ya2luZywgYXJlIGluY29tcGF0aWJsZSB3aXRoIHNvbWV0aGluZykuDQoNCkEgcmVs YXRlZCBwb2ludCBpcyB0aGUgZm9sbG93aW5nIG5hbWluZyBxdWVzdGlvbjoNClNoYWxsIGNvb3Jk aW5hdGlvbiBmdW5jdGlvbiBpbnN0YW5jZXMgYmUgY2F0ZWdvcml6ZWQgYXMgQVNBIG9yIHNoYWxs IHRoZXkgYmVsb25nIHRvIGEgZGlmZmVyZW50IGNhdGVnb3J5ID8NCk9mIGNvdXJzZSB0aGlzIGRp ZmZlcmVudCBjYXRlZ29yeSBpcyBleHBlY3RlZCB0byBiZSBHUkFTUCBDbGllbnRzLg0KSSBwZXJz b25hbGx5IGNvbnNpZGVyIGEgZGlmZmVyZW50IG5hbWluZyB3b3VsZCBlYXNlIHRoZSB1bmRlcnN0 YW5kaW5nLCBmb3IgMiByZWFzb25zOg0KICAtIEFTQSBpbnN0YW5jZXMgYXJlIHBpZWNlcyBvZiBh biBhdXRvbm9taWMgZnVuY3Rpb24sIHdoaWxlIGNvb3JkaW5hdGlvbiBpcyBhIHV0aWxpdHkgd2hp Y2ggcGFydGljaXBhdGVzIGluIG1hbmFnaW5nIGF1dG9ub21pYyBmdW5jdGlvbnMuDQogIC0gQVNB IGluc3RhbmNlcyBkdXRpZXMgYXJlIGRpZmZlcmVudCB0aGF0IENvb3JkaW5hdGlvbiBpbnN0YW5j ZXMgZHV0aWVzLCBlLmcuDQogICAgICAgICAgIDEuIEFuIEFTQSBJbnN0YW5jZSBwYXJ0IG9mIGFu IEF1dG9ub21pYyBmdW5jdGlvbiBpcyBtZWFudCB0byBzZWxmLWRlc2NyaWJlIGl0c2VsZiBmb3Ig Y29vcmRpbmF0aW9uIHRvIGhhcHBlbiwgYW5kIHNob3VsZCB0aGVuIGNvbXBseSB0byByZXF1aXJl bWVudHMsIHdoaWxlIGNvb3JkaW5hdGlvbiBmdW5jdGlvbiBpbnN0YW5jZXMgaGF2ZSBkaWZmZXJl bnQgcmVxdWlyZW1lbnRzLg0KICAgICAgICAgICAyLiBBIGNvb3JkaW5hdGlvbiBmdW5jdGlvbiBp bnN0YW5jZSBtYXkgc2VuZCBpbXBlcmF0aXZlIGNvbW1hbmQgdG8gQXV0b25vbWljIEZ1bmN0aW9u cyAoaS5lLiBBU0EgSW5zdGFuY2VzKSwgd2hpbGUgYW4gQXV0b25vbWljIEZ1bmN0aW9uIGlzIGNl cnRhaW5seSBub3QgZW50aXRsZWQgc3VjaCBwZXJtaXNzaW9ucyBvdmVyIG90aGVyIEF1dG9ub21p YyBGdW5jdGlvbnMuDQpEdXJpbmcgQXRoZW5zIFdTLCBNaWNoYWVsIG5hbWVkIHRoaXMgY2F0ZWdv cnkgIm1hbmFnZW1lbnQgYmxvYnMiLCB3aGF0IHdvdWxkIGJlIG5hbWluZyB0aGF0IGNvdWxkIGJl IGFncmVlZCBvbj8NCj4gDQo+ID4gKEkgdGhpbmsgdGhlICdpbmZyYXN0cnVjdHVyZSBBU0FzJyBz dWNoIGFzIGJvb3RzdHJhcCBhbmQgQUNQLWZvcm1hdGlvbg0KPiA+IG1pZ2h0IGhhdmUgc29tZSBz cGVjaWFsIHRlY2huaWNhbCByZXF1aXJlbWVudHMsIGJ1dCB0aGV5IHNob3VsZCBiZSBvdXQNCj4g PiBvZiBzY29wZQ0KPiA+IGhlcmUuKQ0KPiANCj4gV2h5PyAoYWdyZWUgaXQncyBvdXQgb2Ygc2Nv cGUgZm9yIEdSQVNQLCBidXQgZm9yIG15IHVuZGVyc3RhbmRpbmcpLiBUbyBtZSwgYm9vdHN0cmFw DQo+IGZ1bmN0aW9uIGlzIGp1c3QgYW5vdGhlciBhdXRvbm9taWMgZnVuY3Rpb24sIGNvbnNpc3Rp bmcgb2YgYSByZWdpc3RyYXIgQVNBLCBhIHByb3h5DQo+IEFTQSBhbmQgYSBuZXdfbm9kZSBBU0Eu IFdoeSB3b3VsZCB0aGF0IGJlIGRpZmZlcmVudCB0byBhbnkgb3RoZXIgQVNBPyAoQXBhcnQgZnJv bSB0aGUNCj4gZmFjdCB0aGF0IHdlIG1heSBkZWNsYXJlIHRoZSBwcm94eSBBU0EgYW5kIG5ld19k ZXZpY2UgQVNBIGZvciBleGFtcGxlIG1hbmRhdG9yeSB0bw0KPiBpbXBsZW1lbnQuDQo+IA0KPiA+ ID4gRmlyc3QgcGFyYWdyYXBoIG9mIFNlY3Rpb24gMiwgaXMgaXQgbXVsdGlwbGUgQVNBcyBtaWdo dCBtYW5hZ2UgYQ0KPiA+ID4gc2FtZQ0KPiA+IHRlY2huaWNhbCBvYmplY3RpdmU/IElmIHllcywg aXQgc2hvdWxkIGFsc28gYmUgbWVudGlvbmVkLg0KPiA+DQo+ID4gT0sgKG9mIGNvdXJzZSB0aGlz IHJhaXNlcyB0aGUgY29vcmRpbmF0aW9uIGlzc3VlLCBidXQgdGhhdCBpcyBvdXQgb2YNCj4gPiBz Y29wZSBoZXJlKS4NCj4gDQo+IEFncmVlIHRoZXkgc2hvdWxkIGJlIGFibGUgdG8sIGFuZCBhZ3Jl ZSBuZWVkcyB0byBiZSBtZW50aW9uZWQuIFRoZSBjb29yZGluYXRpb24gaXMNCj4gb25lIHdheSB0 byBjb3BlIHdpdGggdGhhdCBpc3N1ZS4NCj4gDQo+ID4gPiBEMyBpbiBTZWN0aW9uIDIuMSwg4oCc V2hlbiBhbiBBU0Egc3RhcnRzIHVwLCBpdCBtdXN0IHJlcXVpcmUgbm8NCj4gPiA+IGluZm9ybWF0 aW9uDQo+ID4gYWJvdXQgYW55IHBlZXJzIGluIG9yZGVyIHRvIGRpc2NvdmVyIHRoZW0u4oCdIEl0 IGlzIHdvcnRoIHRvIGNsYXJpZnkgdGhlDQo+ID4gYW5vdGhlcg0KPiA+IHNpZGU6IGlmIHRoZXJl IGFyZSBleGlzdGluZyBpbmZvcm1hdGlvbiwgQVNBIG1heSB1c2UgaXQuDQo+ID4NCj4gPiBBcmUg eW91IHN1cmU/IEkgdGhpbmsgYW55IGRpc2NvdmVyeSByZXN1bHRzIG9idGFpbmVkIGJlZm9yZSBh IGNyYXNoDQo+ID4gc2hvdWxkIGJlIGZsdXNoZWQsIGZvciBleGFtcGxlLiBNYXliZSB0aGUgcG9p bnQgaXMgdGhhdCB3ZSByZXF1aXJlIG5vDQo+ID4gKmNvbmZpZ3VyZWQqIGluZm9ybWF0aW9uIGlu IGFuIGF1dG9ub21pYyBuZXR3b3JrLg0KPiANCj4gQ29uZmlndXJhdGlvbiAob3IgTkVUQ09ORiwg ZXRjKSBjYW4gb3ZlcnJpZGUgYW4gYXV0b25vbWljIGJlaGF2aW91ci4gV2hlcmUgaXQgZXhpc3Rz LA0KPiBpdCBNVVNUIGJlIHJlc3BlY3RlZC4gUkZDNzU3NSBleHBsYWlucyB0aGF0LiBTbyBTaGVu ZyBpcyByaWdodCB0aGF0IHdlIG5lZWQgdG8gdGhpbmsNCj4gYWJvdXQgdGhpcy4gQnV0Li4uLiBJ ZiB0aGVyZSBpcyBjb25maWd1cmF0aW9uIHRoYXQgY29uZmxpY3RzLCBpdCdzIG5vdCBvcHRpb25h bCwgc28gSQ0KPiBoYXZlIGFuIGlzc3VlIHdpdGggdGhlICJtYXkiLi4uDQo+IA0KPiBJIHN1Z2dl c3QgdGhlIGN1cnJlbnQgdGV4dCBhbGxvd3MgYWxsIG9mIHRoZSBhYm92ZSwgYW5kIEkgd291bGQg anVzdCBsZWF2ZSBpdCBhcyBpcy4NCj4gDQo+ID4gPg0KPiA+ID4gRDQgaW4gU2VjdGlvbiAyLjEs IOKAnHNvIGRpc2NvdmVyeSBuZWVkcyB0byBiZSByZXBlYXRlZCB0byBmaW5kDQo+ID4gPiBjb3Vu dGVycGFydHMNCj4gPiBmb3IgZWFjaCBvYmplY3RpdmUu4oCdIFRoZSB3b3JkIOKAnHJlcGVhdOKA nSBtYXkgaW1wbHkgdGhlIGxpbmVhciB0aW1lIG9yZGVyLg0KPiA+IE1heWJlIHJlcGxhY2VkIGJ5 IOKAnHNlcGFyYXRlZOKAnSwg4oCcc3BsaXR0ZWTigJ0/DQo+IA0KPiBUbyBtZSAicmVwZWF0ZWQi IGlzIGNsZWFyZXIuDQo+IA0KPiA+ID4gTjUgaW4gU2VjdGlvbiAyLjIsIOKAnHRoZSBwcm90b2Nv bCDigKYgbXVzdCBiZSBjYXBhYmxlIG9mIHJ1bm5pbmcgaW4gYW55DQo+ID4gPiBkZXZpY2UNCj4g PiB0aGF0IHdvdWxkIG90aGVyd2lzZSBuZWVkIGh1bWFuIGludGVydmVudGlvbi7igJ0gVGhpcyBs b29rcyBsaWtlIHRvbw0KPiA+IHN0cm9uZyBmb3IgbWUgd2l0aCB0aGUgd29yZCDigJxtdXN04oCd IGFuZCDigJxhbnnigJ0sIHVubGVzcyB3ZSBhcmUgdGFsa2luZw0KPiA+IGFib3V0IGZ1bGwgYXV0 b25vbWljIG5ldHdvcmssIHdoaWNoIGV4Y2x1ZGUgYW55IGh1bWFuIGludGVydmVudGlvbiwNCj4g PiBhbHRob3VnaCBpdCBtYXkgYmUgb3VyIHVsdGltYXRlIGdvYWwuIFRoZSBzYW1lIHdpdGggTjYs IHRoZSB3b3JkDQo+ID4g4oCcbXVzdOKAnSBhbmQg4oCcYW554oCdIG1heSBiZSB0b28gc3Ryb25n Lg0KPiA+DQo+ID4gSSB0aGluayB0aGF0J3MgcHJvYmFibHkgdHJ1ZTsgd2UgbmVlZCB0byBtYWtl IHRoaXMgdGV4dCBtb3JlIGxvZ2ljYWwuDQo+ID4gQWN0dWFsbHkgdGhlcmUgaXMgYW4gaW50ZXJh Y3Rpb24gaGVyZSB3aXRoIHRoZSByZWZlcmVuY2UgbW9kZWwsIHdoaWNoDQo+ID4gc2hvdWxkIGRp c2N1c3MgY29uc3RyYWluZWQgdnMgdW5jb25zdHJhaW5lZCBub2Rlcy4NCj4gDQo+IEluIHRoZSBy ZWZlcmVuY2UgbW9kZWwgd2UgZGVjbGFyZSBjb25zdHJhaW5lZCBkZXZpY2VzIG91dCBvZiBzY29w ZSBmb3Igbm93LiBJIHRob3VnaHQNCj4gd2UgaGFkIGRlY2lkZWQgb24gdGhhdD8NCj4gDQo+IEhv d2V2ZXIsIHRoaXMgaXMgYSBkZXNpZ24gZ29hbCwgbm90IGEgcHJvdG9jb2wgcmVxdWlyZW1lbnQs IGFzIEkgcmVhZCBpdC4gU28gdGhlDQo+ICJtdXN0IiBpcyBsb3dlcmNhc2UsIGFuZCBpdCdzIG1l YW50IGZvciB0aGUgcHJvdG9jb2wgZGVzaWduZXJzIHJhdGhlciB0aGFuDQo+IGltcGxlbWVudG9y cz8gSW4gYW55IGNhc2UsIGl0J3Mgbm90IGFuIHVwcGVyY2FzZSAiTVVTVCIsIHNvIEkgdGhpbmsg dW5jcml0aWNhbC4NCj4gDQo+ID4gPiBONyBpbiBTZWN0aW9uIDIuMiwgaWYgYSBkZXBlbmRlbmN5 IGNoYWluIGJlY29tZSB0b28gbG9uZywgaXQgbWF5DQo+ID4gPiBzbG93IGRvd24NCj4gPiB0aGUg ZGVjaXNpb24gdG9vIG11Y2guIElmIHNvLCB0aGUgcGVyZm9ybWFuY2Ugb2YgdGhlIHRvdGFsIEFO IG1heSBhbHNvDQo+ID4gYmUgZGFtYWdlZC4gU28sIEkgZ3Vlc3MgYSBtZWNoYW5pc20gdG8gYXZv aWQgdGhlIGxvbmctY2hhaW4gb2YNCj4gPiBkZXBlbmRlbmNpZXMgaXMgYWxzbyBuZWVkZWQuIEhv d2V2ZXIsIHdoZXRoZXIgaXQgaXMgbWF0dGVyIGZvciBBU0FzIG9yDQo+ID4gR1JBU1AsIEkgYW0g bm90IHN1cmUuDQo+ID4NCj4gPiBJIGRvbid0IHRoaW5rIHRoZSBwcm90b2NvbCBpdHNlbGYgY2Fu IGhlbHAgd2l0aCB0aGlzLg0KPiANCj4gV2h5IG5vdD8gV2UgY291bGQgZGVmaW5lIGEgIm1heCBk ZXBlbmRlbmN5IGNvdW50Ij8gIEEgYml0IGxpa2UgbWF4aW11bSByZWN1cnNpb24NCj4gZGVwdGgu ICAoTm90IGFyZ3VpbmcgZm9yLCBqdXN0IHRyeWluZyB0byB1bmRlcnN0YW5kIHlvdXIgc3RhdGVt ZW50LCBCcmlhbi4pDQo+IA0KPiA+ID4g4oCcT2JqZWN0aXZl4oCdIGluIFNlY3Rpb24gMy4xLCB0 aGlyZCBwYXJhZ3JhcGgsIOKAnFRoYXQgbm9kZSBpcyBnZW5lcmFsbHkNCj4gPiBleHBlY3RlZCB0 byBjb250YWluIGFuIEFTQSB3aGljaCBtYXkgaXRzZWxmIG1hbmFnZSBvdGhlciBub2Rlcy7igJ0g SW4gbXkNCj4gPiB1bmRlcnN0YW5kaW5nLCBhbiBBU0EgY291bGQgb25seSBtYW5hZ2UgbG9jYWwg bm9kZXMgYWx0aG91Z2ggaXQgbWF5DQo+ID4gaW5mbHVlbmNlIG90aGVyIG5vZGVzIGJ5IG5lZ290 aWF0aW5nIHdpdGggdGhlIHBlZXIgQVNBcyBvbiB0aGVtLg0KPiANCj4gTm8sIEkgZG9uJ3QgdGhp bmsgc28uIEZvciBhIGxvbmcgdGltZSB3ZSdsbCBoYXZlIG5ldHdvcmtzIHdoZXJlIG5vdCBhbGwg bm9kZXMgYXJlDQo+IGF1dG9ub21pYy4gSSB0aGluayBpdCBpcyBsaWtlbHkgdGhhdCB3ZSBoYXZl IEFTQXMgdGhhdCBhbHNvICJtYW5hZ2UiIG90aGVyLCBub24tDQo+IGF1dG9ub21pYyBub2Rlcy4g Tm93LCB5b3UgY291bGQgYXJndWUsIHRoYXQgaXMgb3V0IG9mIHNjb3BlIGZvciBHUkFTUCBhbmQg dGhhdCdzDQo+IHByb2JhYmx5IHRydWUuIEJ1dCB3ZSBzaG91bGRuJ3QgZm9yZ2V0IHRoaXMgbW9k ZWwuDQpGcm9tIGEgZGVwbG95bWVudCBwb2ludCBvZiB2aWV3LCB0aGVyZSBhcmUgcGxlbnR5IG9m IGRpZmZlcmVudCB3YXlzIG9mIGxpbmtpbmcgYW4gQVNBIGluc3RhbmNlIHdpdGggYSBkZXZpY2Ug aW5zdGFuY2UsIHRoZSBBU0EgaW5zdGFuY2UgY2FuIGJlIGluc2lkZSB0aGUgZGV2aWNlIE9TLCBi dXQgY2FuIGJlIGhvc3RlZCBvbiBhIHJlbW90ZSBob3N0IGFuZCBpbnRlcmFjdCB3aXRoIHRoZSBk ZXZpY2UgdGhyb3VnaCBPcGVuRmxvdywgU05NUCwgQ0xJIC4uLiBUaGUgY29uc3RyYWludHMgbWF5 IGNvbWUgZnJvbSB0aGUgQVNBIGNvZGUgb3IgZnJvbSB0aGUgZGV2aWNlIGNhcGFjaXRpZXMsIGhl bmNlIEkgZGVmaW5pdGVseSBhZ3JlZSB3aXRoIE1pY2hhZWwgb24gdGhhdC4gDQoNCj4gPiA+IOKA nE9yZ2FuaXppbmcgb2Ygc3luY2hyb25pemF0aW9uIG9yIG5lZ290aWF0aW9uIGNvbnRlbnTigJ0g YnVsbGV0IHBvaW50DQo+ID4gPiBpbg0KPiA+IFNlY3Rpb24gMy4yLiBJIGJlbGlldmUgdGhpcyBw b2ludCBzaG91bGQgYmUgcmV3cml0dGVuIGFzIGENCj4gPiByZWNvbW1lbmRhdGlvbiBmb3IgQVNB LiBHUkFTUCBpcyBhIGdlbmVyaWMgcGxhdGZvcm0uIENvbnNlcXVlbnRseSwgaXQNCj4gPiBpcyBp bmRlcGVuZGVudCBmcm9tIGNvbnRlbnQgb3JnYW5pemluZy4NCj4gPg0KPiA+IENvcnJlY3QuIEZy b20gdGhlIHdvcmsgSSd2ZSBkb25lIG9uIHRoZSByZWZlcmVuY2UgbW9kZWwgYW5kIHRoZSBHUkFT UA0KPiA+IEFQSSwgSSB0aGluayB3ZSB3aWxsIG5lZWQgYSBkb2N1bWVudCBhbGwgYWJvdXQgQVNB cyBhbmQgaG93IHRoZXkgYXJlDQo+ID4gb3JnYW5pemVkLg0KPiANCj4gQWdyZWUuIFRoaXMgc2hv dWxkIHByb2JhYmx5IGJlIGFub3RoZXIgc2VjdGlvbiBpbiB0aGUgcmVmZXJlbmNlIG1vZGVsLiAg QW55IHZvbHVudGVlcg0KPiBmb3Igc29tZSB0ZXh0Pw0KU29tZSBzaG9ydCB0ZXh0IGZvciB0aGUg cmVmZXJlbmNlIG1vZGVsIGlzIG9uIG15IHdvcmsgdGFibGUuDQpBIGZ1bGwgZG9jdW1lbnQgYWJv dXQgQVNBIGFuZCBob3cgdGhlcmUgbWFuYWdlbWVudCBhbHJlYWR5IGV4aXN0cywgdGhlIHdvcmsg aXMgbm90IGNvbXBsZXRlLCBidXQgdGhlcmUgaXMgYWxyZWFkeSBhIGJ1bmNoIG9mIG1hdGVyaWFs IHRoZXJlOiBkcmFmdC1wZWxvc28tYW5pbWEtYXV0b25vbWljLWZ1bmN0aW9uLTAxLCBzbyBtYXli ZSBub3Qgd29ydGggc3RhcnRpbmcgZnJvbSBzY3JhdGNoIGEgbmV3IGRvYyB3aHkgbm90IGJ1aWxk aW5nIHVwb24gaXQ/DQoNCkFkZGl0aW9uYWxseSwgdGhpcyBkb2N1bWVudCBhbmQgdGhlIHByZXNl bnRhdGlvbnMgb2YgaXQgbWFkZSBib3RoIGluIFlva29oYW1hIGFuZCBCdWVub3MgQWVyZXMgZXhw bGljaXQgdGhlIG5lZWRzIGFuZCB0aGUgZmllbGRzIHJlcXVpcmVkIGZvciBBU0Egc2VsZi1kZXNj cmlwdGlvbiAoZS5nLiBvbiBzdGFydHVwKSAoc2VlIHNlY3Rpb24gNikuDQpEdXJpbmcgQXRoZW5z IFdTLCB0aGVyZSB3YXMgYSBzb2Z0IGNvbnNlbnN1cyBvbiB1c2luZyB0aGUgR1JBU1AgZGlzY292 ZXJ5IG1lc3NhZ2UgdG8gZGlzY2xvc2UgdGhlIEFTQXMgc2VsZi1kZXNjcmlwdGlvbi4gQSBzdGls bCBwZW5kaW5nIHF1ZXN0aW9uIGlzIHdoZXRoZXIsIHdlIHNob3VsZCBlbWJlZCB0aGUgZnVsbCBz ZWxmLWRlc2NyaXB0aW9uIGluIGEgc2luZ2xlIG9iamVjdGl2ZSwgb3Igc2hvdWxkIHdlIHNwbGl0 IGVhY2ggc2VjdGlvbiBpbiBhIGRpZmZlcmVudCBvYmplY3RpdmVzIGFzIHRoZSBvYmplY3RpdmUg bW9kaWZpZXJzIHNob3VsZCBiZSBkaWZmZXJlbnQgZGVwZW5kaW5nIHdoZXRoZXIgdGhlIHBhcnQg b2YgdGhlIHNlbGYgZGVzY3JpcHRpb24gZGlzY2xvc2VzIG1ldHJpY3Mgb3IgcGFyYW1ldGVycy4N CkNvdWxkIHRoZXJlIGJlIHNvbWUgYWRkaXRpb25hbCBmZWVkLWJhY2s/IFNob3VsZCBJIGNsYXJp ZnkgdGhlIHF1ZXN0aW9uIGZpcnN0Pw0KPiA+ID4NCj4gPiA+IOKAnFNlbGYtYXdhcmUgbmV0d29y ayBkZXZpY2XigJ0gYnVsbGV0IHBvaW50IGluIFNlY3Rpb24gMy4yLCBsYXN0DQo+ID4gPiBzZW50 ZW5jZSDigJxBDQo+ID4gZGV2aWNlIGhhcyBubyBwcmUtY29uZmlndXJhdGlvbiBmb3IgdGhlIHBh cnRpY3VsYXIgbmV0d29yayBpbiB3aGljaCBpdA0KPiA+IGlzIGluc3RhbGxlZC7igJ0gSSBhbSBu b3Qgc3VyZSB0aGUgcHVycG9zZSBvZiB0aGlzIHNlbnRlbmNlIGFsdGhvdWdoIGl0DQo+ID4gbG9v a3MgbGlrZSBhIHJlcXVpcmVtZW50LiBJZiBzbywgaXQgaXMgdG9vIHN0cm9uZy4gSSB0aGluayBh IOKAnG1heeKAnSBzaG91bGQgYmUgYWRkZWQuDQo+ID4NCj4gPiBJIHdvbmRlciB3aGV0aGVyIHRo aXMgd2hvbGUgcGFyYWdyYXBoIGV2ZW4gYmVsb25ncyBpbiB0aGlzIGRvY3VtZW50Lg0KPiA+IEl0 IHNlZW1zIGxpa2UgYW4gZXh0cmFjdCBmcm9tIHRoZSByZWZlcmVuY2UgbW9kZWwuDQo+IA0KPiBB Z3JlZWQuDQo+IA0KPiA+ID4NCj4gPiA+IFNlY3Rpb24gMy4zLCBtb3JlIGRlc2NyaXB0aW9uIG1h eSBiZSBhZGRlZCByZWdhcmRpbmcgdG8gdXNlIEdSQVNQIHRvDQo+ID4gc2lnbmFsIGJldHdlZW4g dHdvIEF1dG9ub21pYyBuZXR3b3Jrcy9kb21haW5zLg0KPiA+DQo+ID4gQWdyZWVkLCBidXQgYXQg dGhlIG1vbWVudCBJJ20gbm90IHN1cmUgd2hhdCB0byBzYXkuDQo+IA0KPiBJIHN1Z2dlc3QsIGZv ciB0aGlzIHZlcnNpb24gb2YgQU5JTUEsIHdlIHJlc3RyaWN0IG91cnNlbHZlcyB0byBzaW5nbGUt ZG9tYWluIG9ubHkuDQo+IE11bHRpLWRvbWFpbiB3aWxsIHJhaXNlIG1hbnkgb3RoZXIgcXVlc3Rp b25zLiBUaGUgY3VycmVudCByZWZlcmVuY2UgbW9kZWwgaGFzICJjcm9zcw0KPiBkb21haW4iICg2 LjUpIGxhYmVsbGVkIGFzIG91dCBvZiBzY29wZS4gU28sIEkgdGhpbmssIG5vdGhpbmcgbmVlZGVk IGluIEdSQVNQIHJpZ2h0DQo+IG5vdy4NCj4gDQo+ID4gPiBJbiBzZWN0aW9uIDMuMywg4oCcRGlz Y292ZXJ5IFByb2NlZHVyZXPigJ0sIOKAnHRoZSBkZXZpY2UgTUFZIHJlc3BvbmQgdG8NCj4gPiA+ IHRoZQ0KPiA+IGxpbmstbG9jYWwgbXVsdGljYXN04oCdLiBXaHkg4oCcTUFZ4oCdPyBBcyBhbiBp bXBvcnRhbnQgYmVoYXZpb3IgZm9yDQo+ID4gc3VjY2Vzc2Z1bCBkaXNjb3ZlcnksIEkgdGhpbmsg aXQgc2hvdWxkIGJlIOKAnFNIT1VMROKAnS4NCj4gPg0KPiA+IEdvb2QgcXVlc3Rpb24uIEFjdHVh bGx5IHRoaXMgaXMgYSB2ZXJ5IG9sZCBNQVkgLSBpdCBpcyBwcmVzZW50IGluDQo+ID4gc2VjdGlv biA1LjIuMiBvZiBkcmFmdC1jYXJwZW50ZXItYW5pbWEtZ2RuLXByb3RvY29sLTAwLCBpbiBzbGln aHRseSBkaWZmZXJlbnQNCj4gd29yZGluZy4NCj4gPiBJIGhhdmUgYWx3YXlzIGFzc3VtZWQgdGhh dCBpdCB3YXMgYmVjYXVzZSBhbiBBU0EgbWlnaHQgd2lzaCB0byBoaWRlDQo+ID4gZm9yIHNvbWUg dGltZSAoZm9yIGV4YW1wbGUsIGlmIGl0IGhhcyBubyBmcmVlIHJlc291cmNlcyB0byBvZmZlciwN Cj4gPiB0aGVyZSBpcyBubyBwb2ludCBpbiBiZWluZyBkaXNjb3ZlcmVkKS4gTWF5YmUgd2UgY291 bGQgc2F5ICJTSE9VTEQNCj4gPiByZXNwb25kIHVubGVzcyB0ZW1wb3JhcmlseSB1bmF2YWlsYWJs ZSIsIG9yIHNvbWV0aGluZyBsaWtlIHRoYXQ/DQo+IA0KPiBIbW1tbS4uLiBJIHRoaW5rIGlmIGFu IEFTQSBjYW4ndCBwcm9jZXNzIGEgcmVxdWVzdCwgaXQgc2hvdWxkIHNlbmQgYmFjayBhbiBhY2Nv cmRpbmcNCj4gZXJyb3IgbWVzc2FnZSByYXRoZXIgdGhhbiBiZSBzaWxlbnQuIEkgY2FuJ3QgYXJn dWUgcHJlY2lzZWx5IHdoeSwgYnV0IG15IGZlZWxpbmcgaXMNCj4gdGhhdCAiaGlkaW5nIiBtYXkg Y2F1c2UgYWxsIHNvcnRzIG9mIHN1YnNlcXVlbnQgaXNzdWVzLiBJIHdvdWxkIGhhdmUgd3JpdHRl biAiTVVTVCINCj4gcmVzcG9uZCBldmVuLiBBdCBsZWFzdCBpbiB0aGUgc2luZ2xlLWRvbWFpbiBj YXNlLiBXaHkgd291bGQgaXQgd2FudCB0byBoaWRlPyE/DQo+IA0KPiA+ID4gSW4gbXVsdGlwbGUg aW50ZXJmYWNlcyBzY2VuYXJpb3MsIOKAnGl0IE1VU1QgcmVsYXkgdGhlIHF1ZXJ5IGJ5DQo+ID4g PiByZS1pc3N1aW5nIGENCj4gPiBEaXNjb3ZlcnkgbWVzc2FnZSBhcyBhIGxpbmstbG9jYWwgbXVs dGljYXN0IG9uIGl0cyBvdGhlciBpbnRlcmZhY2VzLuKAnQ0KPiA+IEkgZG8gTk9UIHRoaW5rIOKA nE1VU1TigJ0gaXMgcmlnaHQgaGVyZS4gSXQgbWVhbnMgYW4gb2JqZWN0aXZlIHRoYXQgZG9lcw0K PiA+IG5vdCBzdXBwb3J0IGJ5IGFueSBkZXZpY2VzIG9yIG9ubHkgc3VwcG9ydCBieSBhIGZldyBk ZXZpY2VzIHdvdWxkDQo+ID4gY2VydGFpbmx5IGNhdXNlIGEgc2lnbmFsIHN0b3JtLiBJIHN1Z2dl c3QgdG8gc29mdCB0aGlzIHRvIOKAnFNIT1VMROKAnSBhbmQgbWFrZSBpdA0KPiBjaGFuZ2VhYmxl IGJ5IGludGVudC4NCj4gPg0KPiA+IFdoeSB3b3VsZCBpdCBjYXVzZSBhIHN0b3JtPyBUaGVyZSBh cmUgdmFyaW91cyBtZWNoYW5pc21zIHRvIHByZXZlbnQNCj4gPiB0aGF0LiBJIGRvbid0IHRoaW5r IHRoZXJlIGlzIGFueSBkaXNjb3ZlcnkgbWVjaGFuaXNtIHBvc3NpYmxlIHdpdGhvdXQNCj4gPiBy ZWxheWluZyBkaXNjb3ZlcnkuIFNvIEkgdGhpbmsgYWxsIG11bHRpLWludGVyZmFjZSBub2RlcyBN VVNUIHJlbGF5IGJ5IGRlZmF1bHQuDQo+ID4NCj4gPiBZb3UgYXJlIGNvcnJlY3QsIHRoZXJlIG1p Z2h0IGJlIG9iamVjdGl2ZXMgd2hpY2ggYXJlIG9ubHkgdXNlZnVsIGlmDQo+ID4gb24tbGluaywg c28gYmVpbmcgYWJsZSB0byByZXN0cmljdCBkaXNjb3ZlcnkgdG8gb24tbGluayB3b3VsZCBiZSB2 YWx1YWJsZSBpbiB0aGF0DQo+IGNhc2UuDQo+IA0KPiBBZ3JlZSB1cCB0byBoZXJlLg0KPiANCj4g PiBUaGF0IGRvZXMgc2VlbSBsaWtlIEludGVudC4NCj4gDQo+IE5vdCBzdXJlIEkgYWdyZWUgaGVy ZS4gV2h5IEludGVudD8gV2hhdCB3b3VsZCBzdWNoIGFuIEludGVudCBsb29rIGxpa2U/IERvIHlv dSBoYXZlDQo+IGFuIGV4YW1wbGUgaW4gbWluZD8NCj4gDQo+ID4gPiBTZWN0aW9uIDMuMy40LjEs IEkgYW0gbm90IHN1cmUgd2hldGhlciB0aGUgUmFwaWQgbW9kZSBpcyBvbmx5IHVzZWQNCj4gPiA+ IG9uLWxpbmsNCj4gPiBvciBub3QsIGluIGFub3RoZXIgd29yZC4gVGhlIGRpc2NvdmVyeSBtZXNz YWdlIHdpdGggYSBuZWdvdGlhdGlvbg0KPiA+IG9iamVjdGl2ZSBvcHRpb24gc2hvdWxkIG9yIHNo b3VsZCBub3QgYmUgcmVsYXllZC4gRWl0aGVyIHdheSwgaXQNCj4gPiBzaG91bGQgYmUgY2xhcmlm aWVkIGZ1cnRoZXIuDQo+ID4NCj4gPiBJIGhhdmUgbm8gcmVhbCBvcGluaW9uIGFib3V0IHRoYXQu IFRvIGJlIGhvbmVzdCBJIGFtIG5vdCBjb252aW5jZWQgYnkNCj4gPiB0aGUgYXJndW1lbnQgZm9y IFJhcGlkIG1vZGUuIEl0IHNlZW1zIGxpa2UgY29tcGxleGl0eSBmb3IgcXVpdGUgYQ0KPiA+IHNt YWxsIGdhaW4sIHNpbmNlIGRpc2NvdmVyeSByZXN1bHRzIHdpbGwgbm9ybWFsbHkgYmUgY2FjaGVk LiBMZXQncyBkaXNjdXNzLi4uDQo+IA0KPiBNeSBmZWVsaW5nIGFzIHdlbGwuDQo+IA0KPiA+ID4g VGhlIHNhbWUgcGFyYWdyYXBoLCDigJxzeW5jaHJvbml6YXRpb24gb2JqZWN0aXZlcyB0aGF0IGFy ZSBmbG9vZGVkDQo+ID4gPiBTSE9VTEQNCj4gPiBOT1QgY29udGFpbiB1bmVuY3J5cHRlZCBzZW5z aXRpdmUgaW5mb3JtYXRpb24u4oCdIFRoZXJlIGlzIG5vdA0KPiA+IGRlZmluaXRpb24gb2Yg4oCc c2Vuc2l0aXZlIGluZm9ybWF0aW9u4oCdLiBUaGVyZWZvcmUsIHRoZSBtZWFuaW5nIG9mIHRoaXMN Cj4gPiBzZW50ZW5jZSBpcyBxdWVzdGlvbmFibHkuDQo+IA0KPiBSZWFsbHksIHRoaXMgaXMgYSBy ZWNvbW1lbmRhdGlvbiB0byB1c2VycyBvZiBHUkFTUCwgbm90IGZvciB0aGUgcHJvdG9jb2wuIEkg d29uZGVyDQo+IHdoZXRoZXIgdGhpcyBiZWxvbmdzIGhlcmUuLi4NCj4gDQo+ID4gPiBUaGUgc2Vj b25kIHBhcmFncmFwaCBvZiBzZWN0aW9uIDMuMy41LjIsIOKAnFRoaXMgcmFwaWQgc3luY2hyb25p emF0aW9uDQo+ID4gZnVuY3Rpb24gU0hPVUxEIGJlIGNvbmZpZ3VyZWQgb2ZmIGJ5IGRlZmF1bHQu 4oCdIFdoeSBvZmYgYnkgZGVmYXVsdD8NCj4gPiBNb3JlIGV4cGxhbmF0aW9uIGFyZSBuZWVkZWQg Zm9yIHRoaXMgZGVzaWduIGNob2ljZS4NCj4gPg0KPiA+IFRoYXQncyBiZWNhdXNlIGFsbCBub2Rl cyBpbiB0aGUgbmV0d29yayBuZWVkIHRvIGFncmVlIHdoZXRoZXIgUmFwaWQNCj4gPiBNb2RlIGlz IGluIHVzZSBvciBub3QsIEkgdGhpbmsuIEluIGFueSBjYXNlIHRoZSBmYWlsdXJlIG1vZGVzIGNv dWxkDQo+ID4gZ2V0IHF1aXRlIGNvbXBsaWNhdGVkIChpZiBvbmUgcGVlciByZXNwb25kcyB3aXRo IGp1c3QgYSBkaXNjb3ZlcnkNCj4gPiByZXNwb25zZSwgYW5kIGFub3RoZXIgb25lIHNldmVyYWwg aG9wcyBhd2F5IHJlc3BvbmRzIHdpdGggYQ0KPiA+IG5lZ290aWF0aW9uIHJlc3BvbnNlLCBidXQg dGhlIGluaXRpYXRvciBoYXMgYWxyZWFkeSBzdGFydGVkIG5lZ290aWF0aW5nIHdpdGggdGhlDQo+ IG5lYXJlc3QgbmVpZ2hib3IpLg0KPiANCj4gRmVlbGluZyAtIGtlZXAgaXQgc2ltcGxlLCBsZXQn cyBub3QgZG8gcmFwaWQgYXQgYWxsLiAgQnV0LCBuZWVkIHRvIHRoaW5rIG1vcmUuLi4NCj4gDQo+ IEknbSB0YWtpbmcgdGhlIHBvaW50cyByZWdhcmRpbmcgdGhlIHJlZmVyZW5jZSBtb2RlbCBvdXQs IGFuZCBhZGQgaXQgdG8gdGhhdCB3b3JrDQo+IHN0cmVhbS4NCj4gDQo+IFRoYW5rcyBCcmlhbiBh bmQgU2hlbmcgLSBnb29kIGRpc2N1c3Npb24hDQo+IE1pY2hhZWwNCj4gDQo+ID4gVGhhbmtzIGFn YWluLA0KPiA+ICAgIEJyaWFuDQo+ID4NCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBBbmltYSBtYWlsaW5nIGxpc3QNCj4g PiBBbmltYUBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vYW5pbWENCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gQW5pbWEgbWFpbGluZyBsaXN0DQo+IEFuaW1hQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWENCg== From nobody Sat Jul 2 00:50:14 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8AEF12B00E; Sat, 2 Jul 2016 00:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 4g_KthpfrKSM; Sat, 2 Jul 2016 00:50:09 -0700 (PDT) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (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 E61D712D0D8; Sat, 2 Jul 2016 00:50:08 -0700 (PDT) Received: by mail-wm0-x241.google.com with SMTP id a66so9986582wme.2; Sat, 02 Jul 2016 00:50:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=xy1kdTgVshDPSsxJ1uwYD1e/55ADlNlZpB2v+xlsR50=; b=m46vlsfTLzJF8ADZM1+6A7DAvfBkIYLAe0JHbyyJy+DDLwpZRt4YP7fDPJ1geZZ4jR eCf+HlFrtoSjt0vKPs3GIejKx8FozpC3naYqhgeHnrhW1AaqIgUlE1rEEpapU9AMyAl/ Qfu3g19QJ4bLWtOXbNF/9MqP6JwVYsAY1boc0/WGSpPWMqvmgcywm4j14Ewrmo+dd+qz 2rEKM6yrpVH961We3ILLnfRHFKMbkkmKCsQBHiyc1mIBg2E89O9bP0YSiiGrlja6Twk9 576OXgr3MDUiBLfY9n71IUtxx/FQwMSAibxfohTyGWo+R6gKbncHjnmCIiAoF/sSbC+L SCXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=xy1kdTgVshDPSsxJ1uwYD1e/55ADlNlZpB2v+xlsR50=; b=h/xuTeq/UqQRot0og2Qqa9GQ4JXkMkW1REG9AMasBmmQ+HTVLOVplJDrw3nto+tQEE JlAjT9+XKoL8bzvUU3ac8nmyUUv9VTejOx8+KnUVXpb8vw9IOvjTwWafwmvVd3XbH5A9 3PZ21ZTT3VCTCsz0if0jALSX2z1yJczwSKBwRQ6Px1qtGfHtgUkmWWxD/Ysfp0LgXBHD RuPgvRiT6EVipEy8T2BjUMeOqlrb7RG1nTjpTyEiVbPiFU3/6a5ywisHcDe1T+xTx2OK jZiAPZe4SDe2cc843shilhllbUVpGaEEhNZE7B2E3NjNejcQGiApSi8yH2lFiYL6UwsQ wF7Q== X-Gm-Message-State: ALyK8tI4vYlnZJeq8zZRGyiCYqu+Pc1TreBW8o19/32ejNlfrS8OqLC4P4/ZsNOj1LSuRw== X-Received: by 10.28.173.8 with SMTP id w8mr1840953wme.39.1467445807297; Sat, 02 Jul 2016 00:50:07 -0700 (PDT) Received: from [10.0.1.29] (cpc66883-mort6-2-0-cust696.19-2.cable.virginm.net. [92.233.126.185]) by smtp.gmail.com with ESMTPSA id dv8sm1632197wjd.49.2016.07.02.00.50.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 Jul 2016 00:50:06 -0700 (PDT) To: "Peloso, Pierre (Nokia - FR)" , "Michael Behringer (mbehring)" , Sheng Jiang , "anima@ietf.org" , "draft-ietf-anima-grasp.all@ietf.org" References: From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 2 Jul 2016 19:50:19 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] Review of ANIMA GRASP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2016 07:50:12 -0000 Pierre, Let me try to answer your points below. I have deleted a lot of text to m= ake the message short enough to read. Also, please note that my main concern = for now is to ensure that GRASP does everything we need; many aspects that ar= e specific to ASA design do not affect this. On 02/07/2016 03:50, Peloso, Pierre (Nokia - FR) wrote: =2E.. >> Yes, the reference model should give the general overview, so this dis= cussion should >> to a large extent go there. > Seems fair to me to have some more of these in the reference model. > Inside draft-peloso-anima-autonomic-function, there is text on the role= of ASA and their management. > Why not building upon it ? Certainly, but we need a common view and the reference model must not bec= ome too long and complex, or nobody will read it. So I still suspect we need = a separate document on ASA design. =2E.. >> ... and it MUST be possible. We've just had the workshop on AN in Athe= ns, and one big >> discussion point was the coordination function. While we haven't concl= uded whether >> this coordination function is itself an ASA or part of the infrastruct= ure, we do NOT >> want to make it technically impossible for a coordination function to = be an ASA. This >> is a good example of two ASAs on the same device having to communicate= =2E > At this point 2 comments: > 1 - There may definitely be two different ASAs willing to modify the= same device parameter... Yes, but a device parameter is not the same thing as a GRASP objective. I= have great difficulty with the thought of two ASAs *in the same device* that a= re both actively negotiating the same GRASP objective. If two ASAs modify the same underlying device parameter, that must of cou= rse be coordinated at device level. It seems like a quite traditional problem= needing a lock and/or a token. If two ASAs in *different* devices negotiate the same GRASP objective tha= t is of course absolutely normal and might not create any coordination issue, depending on the semantics of the objective. > 2 - Michael is dealing here with the role of coordination function w= ith regards to GRASP: During the WS discussions, there was a sort of sof= t-agreement that:=20 > - coordination function can be distributed, Of course (and that's the reason I recently became interested in distributed consensus algorithms). > - coordination function instances should contain a GRASP cli= ent, What's a GRASP client? We have initiators and responders in GRASP. You can think of the initiator as a client and the responder as a server, but any ASA can be both initiator and responder. > - it was not clear yet whether coordination would be complet= ely external to ANI (like ASA sitting on top of ANI), or would have some = pieces embedded in ANI. My opinion: the semantics of coordination are very dependent on the indiv= idual use case. So I am not sure what generic support we could provide, beyond basic GRASP. If you can specify the sort of interaction required between = two coordinators *in the general case* we can then see whether it needs any new GRASP message types. > Could we get feed-back from the WG there (whether the hypothesis stated= above are acceptable, and whether they may prevent something from workin= g, are incompatible with something). >=20 > A related point is the following naming question: > Shall coordination function instances be categorized as ASA or shall th= ey belong to a different category ? > Of course this different category is expected to be GRASP Clients. Again, "GRASP client" isn't defined. I'll assume "GRASP user". > I personally consider a different naming would ease the understanding, = for 2 reasons: > - ASA instances are pieces of an autonomic function, while coordinati= on is a utility which participates in managing autonomic functions. > - ASA instances duties are different that Coordination instances duti= es, e.g. > 1. An ASA Instance part of an Autonomic function is meant to= self-describe itself for coordination to happen, and should then comply = to requirements, while coordination function instances have different req= uirements. > 2. A coordination function instance may send imperative comm= and to Autonomic Functions (i.e. ASA Instances), while an Autonomic Funct= ion is certainly not entitled such permissions over other Autonomic Funct= ions. > During Athens WS, Michael named this category "management blobs", what = would be naming that could be agreed on? I can have no opinion about this until you can answer my question above about message types. If we can map the coordination interactions onto the existing GRASP interactions (discover, negotiate, synchronize, flood)= then I would suggest to minimize the terminology by calling them CASAs (Coordinating ASAs). If we need new GRASP messages, we can discuss. When considering this, remember that a GRASP Objective can have any data structure and any semantics that you want in its 'value' field. I am thinking about six ASAs each supporting its own objective: "leg", "tail", "trunk", "ear", "belly", "tusk"*. But they each also synch= ronize an objective called "coordinate_elephant" which is supported by a CASA. We define the semantics of "coordinate_elephant" so that each ASA obeys the instructions of the CASA. * https://en.wikipedia.org/wiki/Blind_men_and_an_elephant =2E.. >> No, I don't think so. For a long time we'll have networks where not al= l nodes are >> autonomic. I think it is likely that we have ASAs that also "manage" o= ther, non- >> autonomic nodes. Now, you could argue, that is out of scope for GRASP = and that's >> probably true. But we shouldn't forget this model. > From a deployment point of view, there are plenty of different ways of = linking an ASA instance with a device instance, the ASA instance can be i= nside the device OS, but can be hosted on a remote host and interact with= the device through OpenFlow, SNMP, CLI ... The constraints may come from= the ASA code or from the device capacities, hence I definitely agree wit= h Michael on that.=20 We all agree. The ASA uses the GRASP API for its autonomic interactions, = but how it actually manages its target device(s) is completely open. >=20 >>>> =E2=80=9COrganizing of synchronization or negotiation content=E2=80=9D= bullet point >>>> in >>> Section 3.2. I believe this point should be rewritten as a >>> recommendation for ASA. GRASP is a generic platform. Consequently, it= >>> is independent from content organizing. >>> >>> Correct. From the work I've done on the reference model and the GRASP= >>> API, I think we will need a document all about ASAs and how they are >>> organized. >> >> Agree. This should probably be another section in the reference model.= Any volunteer >> for some text? > Some short text for the reference model is on my work table. As I already said, I made some updates to the reference model on GitHub, but we are not done yet. > A full document about ASA and how there management already exists, the = work is not complete, but there is already a bunch of material there: dra= ft-peloso-anima-autonomic-function-01, so maybe not worth starting from s= cratch a new doc why not building upon it? >=20 > Additionally, this document and the presentations of it made both in Yo= kohama and Buenos Aeres explicit the needs and the fields required for AS= A self-description (e.g. on startup) (see section 6). I haven't looked at that for a while, but again I can see how we can map = that to a GRASP objective, for example if the ASA is called "abc" then its man= ifest could be a synchronization objective called "abc.manifest" or whatever co= nvention we choose. > During Athens WS, there was a soft consensus on using the GRASP discove= ry message to disclose the ASAs self-description.=20 That would be discover() followed by synchronize(). If you agree with the= "abc.manifest" convention we can write the code in Python tomorrow. > A still pending question is whether, we should embed the full self-desc= ription in a single objective, or should we split each section in a different objectives as the objective modifiers should be di= fferent depending whether the part of the self description discloses metrics or parameters. Again, that is only a matter of how we choose to define it. I don't see e= ither approach creating a technical diffculty. I think we'd need to play with s= ome real examples to discover the best approach. (And before we go too far, t= his seems like an area where we definitely need an information model.) > Could there be some additional feed-back? Should I clarify the question= first? A concrete example would be very helpful. I think I caught all your points, Pierre, please tell me if not. Regards Brian From nobody Tue Jul 5 17:59:11 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4D712D58C for ; Tue, 5 Jul 2016 17:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.561 X-Spam-Level: X-Spam-Status: No, score=-0.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_24_48=1.34, SPF_PASS=-0.001] autolearn=no autolearn_force=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 iAjsU40xrERY for ; Tue, 5 Jul 2016 17:59:08 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72C8E12B00C for ; Tue, 5 Jul 2016 17:58:59 -0700 (PDT) Received: from sandelman.ca (unknown [209.87.249.16]) by relay.sandelman.ca (Postfix) with ESMTPS id DC0B61F8FF; Wed, 6 Jul 2016 00:58:56 +0000 (UTC) Received: by sandelman.ca (Postfix, from userid 179) id 875516320B; Mon, 4 Jul 2016 15:47:21 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter In-reply-to: <0e01ea99-800f-7fcf-a3bb-ee8c08d8f550@gmail.com> References: <20160630230229.29590.10045.idtracker@ietfa.amsl.com> <0e01ea99-800f-7fcf-a3bb-ee8c08d8f550@gmail.com> Comments: In-reply-to Brian E Carpenter message dated "Fri, 01 Jul 2016 18:43:30 +1200." X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 04 Jul 2016 15:47:21 -0400 Message-ID: <25777.1467661641@dooku.sandelman.ca> Archived-At: Cc: anima@ietf.org Subject: Re: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-03.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 00:59:10 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> b. MUST: Performs DNS-based Service Discovery [RFC6763] over >> Multicast DNS [RFC6762] searching for the service >> "_bootstrapks._tcp.local.". > I missed the bit where we got consensus to only specify DNSSD for > discovery. My understanding was that since all ANs will contain the ANI > components, GRASP discovery was an equally valid option. This topic has come up repeatedly, and we have discussed it a lot. Maybe we need to do a full WG Consensus call about this? === We really like GRASP, and we want to use to find pieces of the bootstrap system. a) We believe that bootstrap will be used by many devices which do not have a full AN stack. And it could be that a line card that will have a full AN stack, doesn't even have a full AN stack when it boots up the first time. It might not even know that it will have a full AN stack until such time as it receives its first firmware update after/during NETCONF-style bootstrap. b) We believe that having a MTI that is already present in constrained devices that might never do a full AN is a win. c) From a long history of security standpoint, we believe that restricting GRASP to work within the secured ACP (only) will have significant attack surface advantages. While one could run a second GRASP instance that is disconnected from the first on the proxy node, it would have to get a number of configuration parameters via the secured GRASP side. The history of computing is replete with examples of priviledge escalation attacks from situations that were not originally envisioned. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- (Camping this week!) --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJXer1FAAoJEKD0KQ7Gj3P2dU8H/3Ad4OeAN88douHg9PeoJriS IjgI63QasPlDNBxOi5YKjxxV5Zl9zvLyL4UdxRQiIUmT1RcbMudskBqbzj6o6isu glM3net9jU5Ad/hFN7Nci+mhz5/qWGrA0g97zbeehd0OWe5RwGlCA3K7g/kzuZLU btXwNbrwGrZ44uQG8S3wh7LLcQuAG8pJ68SQH4Khm/WiffrGLK7YdeTlzAKcilTU etjgkD55SA44eJXnar+9WFQPMUFfKxprWbmpqxyPtERsO8QIldt8x60KokVrUhQM 6rw6mDZTdsyaTBMWnQg2/Cyv3HdW4kZRNZ1g3e6ez0cOYWzYX4+MEERq1Ql4ZZw= =8RG9 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 5 23:35:05 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E56F112D5F7 for ; Tue, 5 Jul 2016 23:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 GapWz9r9Ow3m for ; Tue, 5 Jul 2016 23:35:01 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 83C6712D58D for ; Tue, 5 Jul 2016 23:35:01 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id r201so179123119wme.1 for ; Tue, 05 Jul 2016 23:35:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Jx56JalKvNk/8fECA+nGLk9Z+6NpVU0cJ0kIx23gSAs=; b=k4Gpw31H60NR+9hLkdeNjQc7JUJTx/0PSqCsMiYjOoMEK757qtA7L2XFGn1q6fklHH PoYuGr8SE0zHOg62JRTDzON8JPmICo5y6SncX6rnLywyuCPYVVjDtYJbTf0e7w2h8Ipl VTBwBKufBJGyBCtTpLvGc57/9qtXTLsqtHNj2AcMg5kY1vRZdlWOXrHXc5fDthKGo2aJ ysk/S2hcqcdPyQZ5nNEqdr5g83DDX9/CocsMgr0P6waYEhy1Ybj7Y0/OFJ7X9d0nEOao Dl/XHnBLF8E0EcNFQRxoZI9sJG8Wys9JnRJLIBCc72H3tDqwsCzt9bV37go/vRT/CZ/p txqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=Jx56JalKvNk/8fECA+nGLk9Z+6NpVU0cJ0kIx23gSAs=; b=iFCeSQR8J7DPg9fWM+9buveygp+nnaecwzAWuvwgb2s8nWtVh4dTfx9nPBhjx7lN1S CKNxModU7RqTIK/J78OJXpbxNel1LjwX/wAjkL5e5tXf/IW46jR41LwpAT9611GP4Wpv +KInldBJgz2QS70Q2ZNF3w7RXW+sIeMSCKpm/SHk2d/nUhYxzJ3WbBSERzKfIcKmZgqF aO/02noxkhsQeShOb5GFUDB1AvdNAPXl9rL351WyOZgJBZ5RgALQ/SiWh1+X2qghOJQ1 TwI2fmYHNt5/Y3DiF6EItSTZ3vwB2MZhu/kD6e29jdx4haGpRtCfcxI7j4J+zUEg+/N7 kAoA== X-Gm-Message-State: ALyK8tIEO6l4ib50bZBVZjMSCtapqouGy+A+DYlQxzh3ljN8bL5EMI5Fv+8ystTs6dSIZg== X-Received: by 10.28.87.20 with SMTP id l20mr20733545wmb.1.1467786899691; Tue, 05 Jul 2016 23:34:59 -0700 (PDT) Received: from [10.0.1.29] (cpc66883-mort6-2-0-cust696.19-2.cable.virginm.net. [92.233.126.185]) by smtp.gmail.com with ESMTPSA id g4sm6467266wju.30.2016.07.05.23.34.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Jul 2016 23:34:59 -0700 (PDT) To: Michael Richardson References: <20160630230229.29590.10045.idtracker@ietfa.amsl.com> <0e01ea99-800f-7fcf-a3bb-ee8c08d8f550@gmail.com> <25777.1467661641@dooku.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 6 Jul 2016 18:35:05 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <25777.1467661641@dooku.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: anima@ietf.org Subject: Re: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-03.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 06:35:04 -0000 Hi Michael, On 05/07/2016 07:47, Michael Richardson wrote: > > Brian E Carpenter wrote: > >> b. MUST: Performs DNS-based Service Discovery [RFC6763] over > >> Multicast DNS [RFC6762] searching for the service > >> "_bootstrapks._tcp.local.". > > > I missed the bit where we got consensus to only specify DNSSD for > > discovery. My understanding was that since all ANs will contain the ANI > > components, GRASP discovery was an equally valid option. > > This topic has come up repeatedly, and we have discussed it a lot. > Maybe we need to do a full WG Consensus call about this? Well, let's see if we can work it out ... > > === > > We really like GRASP, and we want to use to find pieces of the bootstrap system. > > a) We believe that bootstrap will be used by many devices which do not have > a full AN stack. > And it could be that a line card that will have a full AN stack, doesn't > even have a full AN stack when it boots up the first time. It might not > even know that it will have a full AN stack until such time as it receives > its first firmware update after/during NETCONF-style bootstrap. Yes. So some careful phrasing about the default behaviour as well as the MTI is needed, in any case. > b) We believe that having a MTI that is already present in constrained > devices that might never do a full AN is a win. Certainly. I am not objecting to an MTI but the text I quoted excludes alternatives to the MTI. > c) From a long history of security standpoint, we believe that restricting > GRASP to work within the secured ACP (only) will have significant attack > surface advantages. While one could run a second GRASP instance that is > disconnected from the first on the proxy node, it would have to get a > number of configuration parameters via the secured GRASP side. We're only talking about discovery here. So I really don't understand that argument. GRASP discovery returns a transport locator (address, protocol, port). By definition GRASP is running insecurely pre-bootstrap - it isn't a question of an instance, it's actually a mode of operation. Once you've got the transport locator you can do whatever you need to with it. GRASP will refuse to perform any "real" operations (negotiation or synchronization) unless it's secured. I just don't see any security difference between mDNS or DNSSD for "_bootstrapks._tcp.local." and grasp.discover() for an objective called, for example, "_bootstrapks._tcp.local." > > The history of computing is replete with examples of priviledge escalation > attacks from situations that were not originally envisioned. Indeed. Exactly why GRASP says: The ACP, or in its absence the local PKI, sets the boundary within which nodes are trusted as GRASP peers. A GRASP implementation MUST refuse to execute any GRASP functions except discovery if there is neither an operational ACP nor an operational TLS environment. Regards Brian From nobody Fri Jul 8 01:23:11 2016 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6120712D0DD; Fri, 8 Jul 2016 01:23:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708082306.32042.75322.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 01:23:06 -0700 Archived-At: Cc: anima@ietf.org Subject: [Anima] I-D Action: draft-ietf-anima-prefix-management-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 08:23:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach of the IETF. Title : Autonomic IPv6 Edge Prefix Management in Large-scale Networks Authors : Sheng Jiang Zongpeng Du Brian Carpenter Qiong Sun Filename : draft-ietf-anima-prefix-management-01.txt Pages : 14 Date : 2016-07-08 Abstract: This document describes an autonomic solution for IPv6 prefix management at the edge of large-scale ISP networks. An important purpose of the document is to use it for validation of the design of various components of the autonomic networking infrastructure. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-prefix-management/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-anima-prefix-management-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-prefix-management-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 8 03:24:00 2016 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 729D512D52F; Fri, 8 Jul 2016 03:23:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708102355.32152.14658.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 03:23:55 -0700 Archived-At: Cc: anima@ietf.org Subject: [Anima] I-D Action: draft-ietf-anima-reference-model-02.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 10:23:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach of the IETF. Title : A Reference Model for Autonomic Networking Authors : Michael H. Behringer Brian Carpenter Toerless Eckert Laurent Ciavaglia Peloso Pierre Bing Liu Jeferson Campos Nobre John Strassner Filename : draft-ietf-anima-reference-model-02.txt Pages : 26 Date : 2016-07-08 Abstract: This document describes a reference model for Autonomic Networking. The goal is to define how the various elements in an autonomic context work together, to describe their interfaces and relations. While the document is written as generally as possible, the initial solutions are limited to the chartered scope of the WG. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-reference-model/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-anima-reference-model-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-reference-model-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 8 05:54:33 2016 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D22912D618; Fri, 8 Jul 2016 05:54:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708125429.32189.42590.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 05:54:29 -0700 Archived-At: Cc: anima@ietf.org Subject: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-03.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 12:54:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach of the IETF. Title : An Autonomic Control Plane Authors : Michael H. Behringer Toerless Eckert Steinthor Bjarnason Filename : draft-ietf-anima-autonomic-control-plane-03.txt Pages : 32 Date : 2016-07-08 Abstract: Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Control Plane should ideally be self-managing, and as independent as possible of configuration. This document defines an "Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out of band channel" for OAM communications over a network that is not configured, or mis-configured. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 8 05:59:38 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFEB512D0B2 for ; Fri, 8 Jul 2016 05:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 nm9n-I-GcrVH for ; Fri, 8 Jul 2016 05:59:35 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C18F12B012 for ; Fri, 8 Jul 2016 05:59:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3248; q=dns/txt; s=iport; t=1467982775; x=1469192375; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Xzw/3T2RT5XO7pk+3a/MKngJr2M1/M8bPeeotdUAOJM=; b=l/XmmjuMxy/4AAM3opS0bTgpO5jgzlhWoje3GX/KDpwLArOEYB13PR3m Bqq2uoPakjrYTZ4Umkd8BFFXWTCGE5WNOhvJt59HvdIVFu0Rv7vG8Kz/V EBwme8wzZ6OzEjZ1Uj9daCG3snHvuKThGCYfH2NWtJYRlsDLk6l4GQGqV 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B5AgByo39X/5ldJa1bgz5WfAa5DoF7I?= =?us-ascii?q?oV2AhyBETgUAQEBAQEBAWUcC4RMAQEFIxFDDgQCAQgRBAEBAwIjAwICAjAUAQY?= =?us-ascii?q?BAQUDAgQTCIgoDq4Lj0EBAQEBAQEBAQEBAQEBAQEBAQEBAQEcgQGFJoRNh0KCW?= =?us-ascii?q?gWOBIsQAYYLiDyBcU6ECoMuhTyQDQEeNoI8gTVuiDN/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,329,1464652800"; d="scan'208";a="295233695" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jul 2016 12:59:21 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u68CxLXY001638 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 8 Jul 2016 12:59:21 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 8 Jul 2016 07:59:20 -0500 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1210.000; Fri, 8 Jul 2016 07:59:20 -0500 From: "Michael Behringer (mbehring)" To: "anima@ietf.org" Thread-Topic: New Version Notification for draft-ietf-anima-autonomic-control-plane-03.txt Thread-Index: AQHR2RfeYiYE/7lid06W/SXLRjVlG6AOfaJQ Date: Fri, 8 Jul 2016 12:59:20 +0000 Message-ID: <5cf12152afbe49b4b020ad56f261a147@XCH-RCD-006.cisco.com> References: <20160708125429.32189.27110.idtracker@ietfa.amsl.com> In-Reply-To: <20160708125429.32189.27110.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.238.133] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Anima] FW: New Version Notification for draft-ietf-anima-autonomic-control-plane-03.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 12:59:37 -0000 QU5JTUEgV0csIA0KDQpIZXJlIGlzIHRoZSBsYXRlc3QgdmVyc2lvbiBvZiB0aGUgQUNQIGRyYWZ0 LCB3aXRoIHF1aXRlIGEgbG90IG9mIGNoYW5nZXMgYW5kIHVwZGF0ZXMuIA0KDQpBcyBkaXNjdXNz ZWQgc2luY2UgdGhlIGxhc3QgSUVURiwgd2Ugbm93IGFzc3VtZSB0aGF0IG5laWdoYm91ciBkaXNj b3ZlcnkgaXMgbm90IHdpdGggR1JBU1AsIGJ1dCBtRE5TLiANCg0KQWxzbywgdGhlIGNoYW5uZWwg c2VsZWN0aW9uIHByb2Nlc3MgaGFzIGNoYW5nZWQsIHNlZSBzZWN0aW9uIDUuNCBhbmQgNS41LiAN Cg0KTG90cyBvZiBlZGl0b3JpYWwgdXBkYXRlcyBhcyB3ZWxsLiBJdCdzIGNlcnRhaW5seSB3b3J0 aCBoYXZpbmcgYW5vdGhlciByZWFkIHRocm91Z2guIE5vdGUgdGhhdCB3ZSd2ZSBtZXJnZWQgdG8g bWFpbiBzZWN0aW9ucyBpbnRvIG9uZSAoNSksIHNvIHRoZXJlIHdpbGwgc3RpbGwgYmUgc29tZSBj bGVhbi11cCB0byBkbyBpbiB0ZXJtcyBvZiByZWFkYWJpbGl0eSwgZXRjLiANCg0KQ29tbWVudHMg d2VsY29tZSENCk1pY2hhZWwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmddDQo+IFNlbnQ6IDA4IEp1bHkgMjAxNiAxNDo1NA0KPiBUbzogTWljaGFlbCBCZWhyaW5nZXIg KG1iZWhyaW5nKSA8bWJlaHJpbmdAY2lzY28uY29tPjsgVG9lcmxlc3MgRWNrZXJ0DQo+IChlY2tl cnQpIDxlY2tlcnRAY2lzY28uY29tPjsgU3RlaW50aG9yIEJqYXJuYXNvbiA8c2JqYXJuYXNvbkBh cmJvci5uZXQ+DQo+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt aWV0Zi1hbmltYS1hdXRvbm9taWMtY29udHJvbC0NCj4gcGxhbmUtMDMudHh0DQo+IA0KPiANCj4g QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtYW5pbWEtYXV0b25vbWljLWNvbnRyb2wt cGxhbmUtMDMudHh0DQo+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTWljaGFl bCBILiBCZWhyaW5nZXIgYW5kIHBvc3RlZCB0byB0aGUNCj4gSUVURiByZXBvc2l0b3J5Lg0KPiAN Cj4gTmFtZToJCWRyYWZ0LWlldGYtYW5pbWEtYXV0b25vbWljLWNvbnRyb2wtcGxhbmUNCj4gUmV2 aXNpb246CTAzDQo+IFRpdGxlOgkJQW4gQXV0b25vbWljIENvbnRyb2wgUGxhbmUNCj4gRG9jdW1l bnQgZGF0ZToJMjAxNi0wNy0wOA0KPiBHcm91cDoJCWFuaW1hDQo+IFBhZ2VzOgkJMzINCj4gVVJM OiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1p ZXRmLWFuaW1hLWF1dG9ub21pYy0NCj4gY29udHJvbC1wbGFuZS0wMy50eHQNCj4gU3RhdHVzOiAg ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtYW5pbWEt YXV0b25vbWljLQ0KPiBjb250cm9sLXBsYW5lLw0KPiBIdG1saXplZDogICAgICAgaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYW5pbWEtYXV0b25vbWljLWNvbnRyb2wtDQo+ IHBsYW5lLTAzDQo+IERpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtaWV0Zi1hbmltYS1hdXRvbm9taWMtDQo+IGNvbnRyb2wtcGxhbmUtMDMNCj4g DQo+IEFic3RyYWN0Og0KPiAgICBBdXRvbm9taWMgZnVuY3Rpb25zIG5lZWQgYSBjb250cm9sIHBs YW5lIHRvIGNvbW11bmljYXRlLCB3aGljaA0KPiAgICBkZXBlbmRzIG9uIHNvbWUgYWRkcmVzc2lu ZyBhbmQgcm91dGluZy4gIFRoaXMgQXV0b25vbWljIENvbnRyb2wgUGxhbmUNCj4gICAgc2hvdWxk IGlkZWFsbHkgYmUgc2VsZi1tYW5hZ2luZywgYW5kIGFzIGluZGVwZW5kZW50IGFzIHBvc3NpYmxl IG9mDQo+ICAgIGNvbmZpZ3VyYXRpb24uICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYW4gIkF1dG9u b21pYyBDb250cm9sIFBsYW5lIiwNCj4gICAgd2l0aCB0aGUgcHJpbWFyeSB1c2UgYXMgYSBjb250 cm9sIHBsYW5lIGZvciBhdXRvbm9taWMgZnVuY3Rpb25zLiAgSXQNCj4gICAgYWxzbyBzZXJ2ZXMg YXMgYSAidmlydHVhbCBvdXQgb2YgYmFuZCBjaGFubmVsIiBmb3IgT0FNIGNvbW11bmljYXRpb25z DQo+ICAgIG92ZXIgYSBuZXR3b3JrIHRoYXQgaXMgbm90IGNvbmZpZ3VyZWQsIG9yIG1pcy1jb25m aWd1cmVkLg0KPiANCj4gDQo+IA0KPiANCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBh IGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KPiB1bnRpbCB0 aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYu b3JnLg0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Fri Jul 8 06:00:04 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECFC12D0B2 for ; Fri, 8 Jul 2016 06:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 M0rPa4XZRM1K for ; Fri, 8 Jul 2016 06:00:01 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA77B12B012 for ; Fri, 8 Jul 2016 06:00:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2854; q=dns/txt; s=iport; t=1467982801; x=1469192401; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=8IYb7vSPNteSGgDCIARqA8wZ6mFtpL9C1hQAToFrdRw=; b=ZOp3IVRcZwyzLjxiEKsGnvlZmbuwP5RAnazY20NH+Ul+qGw7bsDDnraT cCz0jb7g/UB0zsjn4BklrwjUwpYZh9C/DOhD5bL4nja1H+dvykvFHZE8g /vqoh2YhSzQbw48K3agbvuwITAe/2X8ZlyfeQBDgfJt8Y4u8JwMVe9E3c M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B6AgB6on9X/5RdJa1bgz5WfAaseYwVg?= =?us-ascii?q?XsihXYCHIEROBQBAQEBAQEBZRwLhEwBAQUjET4FDgQCAQgRBAEBAwIjAwICAh8?= =?us-ascii?q?RFAEGAQEFAwIEEwgTh3sDFw6uCYsPDYQmAQEBAQEBAQEBAQEBAQEBAQEBAQEBH?= =?us-ascii?q?IEBhSaETYJDgVorM4JHgloFjgSKXDQBhguGL4INgXFOhAqIaogah3MBHjaDcW4?= =?us-ascii?q?Bh21FfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,329,1464652800"; d="scan'208";a="294466575" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jul 2016 13:00:00 +0000 Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u68D00KU031221 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 8 Jul 2016 13:00:00 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 8 Jul 2016 07:59:59 -0500 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1210.000; Fri, 8 Jul 2016 07:59:59 -0500 From: "Michael Behringer (mbehring)" To: "anima@ietf.org" Thread-Topic: New Version Notification for draft-ietf-anima-reference-model-02.txt Thread-Index: AQHR2QLW8TuIkxv//keFqPJPvXItm6AOfxVQ Date: Fri, 8 Jul 2016 12:59:59 +0000 Message-ID: References: <20160708102355.32152.80915.idtracker@ietfa.amsl.com> In-Reply-To: <20160708102355.32152.80915.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.238.133] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Anima] FW: New Version Notification for draft-ietf-anima-reference-model-02.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 13:00:03 -0000 QU5JTUEgV0csIA0KDQpIZXJlIHRoZSBuZXcgdmVyc2lvbiBvZiB0aGUgcmVmZXJlbmNlIG1vZGVs LiBTZWUgY2hhbmdlIGxvZyBmb3IgZGV0YWlscy4gDQoNCk1pY2hhZWwNCg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0 bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+IFNlbnQ6IDA4IEp1bHkgMjAxNiAxMjoyNA0K PiBUbzogSmVmZXJzb24gQ2FtcG9zIE5vYnJlIDxqY25vYnJlQGluZi51ZnJncy5icj47IExhdXJl bnQgQ2lhdmFnbGlhDQo+IDxsYXVyZW50LmNpYXZhZ2xpYUBub2tpYS5jb20+OyBUb2VybGVzcyBF Y2tlcnQgKGVja2VydCkNCj4gPGVja2VydEBjaXNjby5jb20+OyBCcmlhbiBFLiBDYXJwZW50ZXIg PGJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbT47DQo+IE1pY2hhZWwgQmVocmluZ2VyIChtYmVo cmluZykgPG1iZWhyaW5nQGNpc2NvLmNvbT47IEJpbmcgTGl1DQo+IDxsZW8ubGl1YmluZ0BodWF3 ZWkuY29tPjsgQnJpYW4gQ2FycGVudGVyDQo+IDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+ OyBQZWxvc28gUGllcnJlIDxwaWVycmUucGVsb3NvQG5va2lhLmNvbT47DQo+IExhdXJlbnQgQ2lh dmFnbGlhIDxMYXVyZW50LkNpYXZhZ2xpYUBub2tpYS5jb20+OyBKb2huIFN0cmFzc25lcg0KPiA8 am9obi5zYy5zdHJhc3NuZXJAaHVhd2VpLmNvbT4NCj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLWFuaW1hLXJlZmVyZW5jZS1tb2RlbC0NCj4gMDIudHh0 DQo+IA0KPiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtYW5pbWEtcmVmZXJl bmNlLW1vZGVsLTAyLnR4dA0KPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IE1p Y2hhZWwgSC4gQmVocmluZ2VyIGFuZCBwb3N0ZWQgdG8gdGhlDQo+IElFVEYgcmVwb3NpdG9yeS4N Cj4gDQo+IE5hbWU6CQlkcmFmdC1pZXRmLWFuaW1hLXJlZmVyZW5jZS1tb2RlbA0KPiBSZXZpc2lv bjoJMDINCj4gVGl0bGU6CQlBIFJlZmVyZW5jZSBNb2RlbCBmb3IgQXV0b25vbWljIE5ldHdvcmtp bmcNCj4gRG9jdW1lbnQgZGF0ZToJMjAxNi0wNy0wOA0KPiBHcm91cDoJCWFuaW1hDQo+IFBhZ2Vz OgkJMjYNCj4gVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC1pZXRmLWFuaW1hLXJlZmVyZW5jZS0NCj4gbW9kZWwtMDIudHh0DQo+IFN0YXR1 czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWFu aW1hLXJlZmVyZW5jZS0NCj4gbW9kZWwvDQo+IEh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hbmltYS1yZWZlcmVuY2UtbW9kZWwtDQo+IDAyDQo+ IERpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt aWV0Zi1hbmltYS1yZWZlcmVuY2UtDQo+IG1vZGVsLTAyDQo+IA0KPiBBYnN0cmFjdDoNCj4gICAg VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSByZWZlcmVuY2UgbW9kZWwgZm9yIEF1dG9ub21pYyBO ZXR3b3JraW5nLg0KPiAgICBUaGUgZ29hbCBpcyB0byBkZWZpbmUgaG93IHRoZSB2YXJpb3VzIGVs ZW1lbnRzIGluIGFuIGF1dG9ub21pYw0KPiAgICBjb250ZXh0IHdvcmsgdG9nZXRoZXIsIHRvIGRl c2NyaWJlIHRoZWlyIGludGVyZmFjZXMgYW5kIHJlbGF0aW9ucy4NCj4gICAgV2hpbGUgdGhlIGRv Y3VtZW50IGlzIHdyaXR0ZW4gYXMgZ2VuZXJhbGx5IGFzIHBvc3NpYmxlLCB0aGUgaW5pdGlhbA0K PiAgICBzb2x1dGlvbnMgYXJlIGxpbWl0ZWQgdG8gdGhlIGNoYXJ0ZXJlZCBzY29wZSBvZiB0aGUg V0cuDQo+IA0KPiANCj4gDQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291 cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+IHVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcu DQo+IA0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Fri Jul 8 08:45:33 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3B312D759 for ; Fri, 8 Jul 2016 08:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 oQOpSxcBkLo1 for ; Fri, 8 Jul 2016 08:45:28 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 9CFC912D1DE for ; Fri, 8 Jul 2016 08:45:27 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 77565DB4E4F93 for ; Fri, 8 Jul 2016 15:45:22 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u68FjOoL010598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 8 Jul 2016 15:45:25 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u68FjFNl004648 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 8 Jul 2016 17:45:24 +0200 Received: from [172.27.205.129] (135.239.27.41) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 8 Jul 2016 17:45:24 +0200 References: <20160708153949.32209.45567.idtracker@ietfa.amsl.com> To: anima From: Laurent Ciavaglia Organization: Nokia Bell Labs X-Forwarded-Message-Id: <20160708153949.32209.45567.idtracker@ietfa.amsl.com> Message-ID: Date: Fri, 8 Jul 2016 17:45:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160708153949.32209.45567.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------D6DE5B302860E213AB00889F" X-Originating-IP: [135.239.27.41] Archived-At: Subject: [Anima] Fwd: New Version Notification for draft-du-anima-an-intent-04.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 15:45:32 -0000 --------------D6DE5B302860E213AB00889F Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Dear ANIMA WG, FYI: a new version of the I-D has been posted. The main update is the addition of a section on Intent Life Cycle based on the initial text provided by Michael Behringer (https://mailarchive.ietf.org/arch/msg/anima/rk2CgO62nmXFuKOBX-Gtb5v0p5E). Michael is now also co-author of the I-D. *We've asked the ANIMA WG chairs for a slot at IETF96/Berlin to present the updates on this draft and report on the discussion on Intent and way forward.** **Your comments are thus highly welcome before the meet**ing**.* Best regards, Laurent. -------- Forwarded Message -------- Subject: New Version Notification for draft-du-anima-an-intent-04.txt Date: Fri, 8 Jul 2016 08:39:49 -0700 From: internet-drafts@ietf.org To: Laurent Ciavaglia , Jeferson Campos Nobre , Michael Behringer , Sheng Jiang , Zongpeng Du , Michael H. Behringer , Laurent Ciavaglia A new version of I-D, draft-du-anima-an-intent-04.txt has been successfully submitted by Laurent Ciavaglia and posted to the IETF repository. Name: draft-du-anima-an-intent Revision: 04 Title: ANIMA Intent Policy and Format Document date: 2016-07-08 Group: Individual Submission Pages: 13 URL: https://www.ietf.org/internet-drafts/draft-du-anima-an-intent-04.txt Status: https://datatracker.ietf.org/doc/draft-du-anima-an-intent/ Htmlized: https://tools.ietf.org/html/draft-du-anima-an-intent-04 Diff: https://www.ietf.org/rfcdiff?url2=draft-du-anima-an-intent-04 Abstract: One of the goals of autonomic networking is to simplify the management of networks by human operators. Intent Based Networking (IBN) is a possible approach to realize this goal. With IBN, the operator indicates to the network what to do (i.e. her intent) and not how to do it. In the field of Policy Based Management (PBM), the concept of intent is called a declarative policy. This document proposes a refinement of the intent concept initially defined in [RFC7575] for autonomic networks by providing a more complete definition, a life-cycle, some use cases and a tentative format of the ANIMA Intent Policy. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- Laurent Ciavaglia Nokia, Bell Labs +33 160 402 636 route de Villejust - Nozay, France linkedin.com/in/laurent.ciavaglia --------------D6DE5B302860E213AB00889F Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit Dear ANIMA WG,

FYI: a new version of the I-D has been posted.

The main update is the addition of a section on Intent Life Cycle based on the initial text provided by Michael Behringer (https://mailarchive.ietf.org/arch/msg/anima/rk2CgO62nmXFuKOBX-Gtb5v0p5E).
Michael is now also co-author of the I-D.

We've asked the ANIMA WG chairs for a slot at IETF96/Berlin to present the updates on this draft and report on the discussion on Intent and way forward.
Your comments are thus highly welcome before the meeting.

Best regards, Laurent.


-------- Forwarded Message --------
Subject: New Version Notification for draft-du-anima-an-intent-04.txt
Date: Fri, 8 Jul 2016 08:39:49 -0700
From: internet-drafts@ietf.org
To: Laurent Ciavaglia <laurent.ciavaglia@alcatel-lucent.com>, Jeferson Campos Nobre <jcnobre@inf.ufrgs.br>, Michael Behringer <mbehring@cisco.com>, Sheng Jiang <jiangsheng@huawei.com>, Zongpeng Du <duzongpeng@huawei.com>, Michael H. Behringer <mbehring@cisco.com>, Laurent Ciavaglia <Laurent.Ciavaglia@alcatel-lucent.com> 


A new version of I-D, draft-du-anima-an-intent-04.txt
has been successfully submitted by Laurent Ciavaglia and posted to the
IETF repository.

Name:		draft-du-anima-an-intent
Revision:	04
Title:		ANIMA Intent Policy and Format
Document date:	2016-07-08
Group:		Individual Submission
Pages:		13
URL:            https://www.ietf.org/internet-drafts/draft-du-anima-an-intent-04.txt
Status:         https://datatracker.ietf.org/doc/draft-du-anima-an-intent/
Htmlized:       https://tools.ietf.org/html/draft-du-anima-an-intent-04
Diff:           https://www.ietf.org/rfcdiff?url2=draft-du-anima-an-intent-04

Abstract:
   One of the goals of autonomic networking is to simplify the
   management of networks by human operators.  Intent Based Networking
   (IBN) is a possible approach to realize this goal.  With IBN, the
   operator indicates to the network what to do (i.e. her intent) and
   not how to do it.  In the field of Policy Based Management (PBM), the
   concept of intent is called a declarative policy.  This document
   proposes a refinement of the intent concept initially defined in
   [RFC7575] for autonomic networks by providing a more complete
   definition, a life-cycle, some use cases and a tentative format of
   the ANIMA Intent Policy.

                                                                                  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--

Laurent Ciavaglia

Nokia, Bell Labs

 

+33 160 402 636

route de Villejust - Nozay, France

linkedin.com/in/laurent.ciavaglia

--------------D6DE5B302860E213AB00889F-- From nobody Fri Jul 8 10:25:06 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E1612D0BF for ; Fri, 8 Jul 2016 10:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 oXZVjHovZ-L4 for ; Fri, 8 Jul 2016 10:25:02 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1DC7127058 for ; Fri, 8 Jul 2016 10:25:01 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id n127so18502996wme.1 for ; Fri, 08 Jul 2016 10:25:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=gqP87XI2pjebwk2UIZhx0DHyTOwrKEcVRJdUKvdyDb4=; b=ZGuwz/I31R7yyMyWfAayaWFH3PFdZor+4xEV4SFCePv/Oyi7Z8a1VjCn3PXhVHhiID aZX2Pb/dt07KMYJtYV7g3rzE5pB6x+hPWxLrlHWiNMJioPqnvyYRN091yhg8MZ3MtGxE DD9d7SY0qigGP2J805YBW56uJwD8pbdKm1MT8XViq3X58K8RShPTFJNP1gH74XZ55hdV 8AD5fXcvRfAsWgBoa4gnY/zubIU8CQGBa8Cv+VgX5wjlYsDSWlBltB3m2UbHAB1dk6k+ 6a/s8fIj7PmPEKeQcgKo27ZC1Gkpm5aCS5fvQpMw1yNCx4yw72X99tn4er/Xzax4yXmX 4nyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=gqP87XI2pjebwk2UIZhx0DHyTOwrKEcVRJdUKvdyDb4=; b=OfOSjIcWTuaZ6Jp/nNfgyuJvCCPMl4s1H3C7Aoe3yakHjgp3AlDofENMiaTASCOrBa tJRSxNQJachLGA0Y6R3BzgRbhPbwOhbEPIlFcH3MiLULTiPbU9eKo/uMhZ4QZrQKek4O CeRiIKoAOY7WzQ+8qa8lm6Prc0quXQr0W1RBEWlGR+OIh5uoBCj+0ULS+rJZtsBRnSfy avxk+Kf/5zoL/tHql9o7ezWiczT2cOGpyRKP50YC9cUexR2ZcN4rKvV1ONXrO4YBZt/v 2o/auhgdst4ec7r3eZne5HTF25WqXKI6JFq9XDAKkGzDJdu5UzX3EMoATRSt0VTlPL40 NIJQ== X-Gm-Message-State: ALyK8tLNYahYaFCtpa0lZYAqckyX0VDquQlZQ18KGbU9hoEcNBwqg+ycm1M3GuIlwKTsLw== X-Received: by 10.194.176.132 with SMTP id ci4mr6400685wjc.138.1467998699742; Fri, 08 Jul 2016 10:24:59 -0700 (PDT) Received: from [10.0.1.29] (cpc66883-mort6-2-0-cust696.19-2.cable.virginm.net. [92.233.126.185]) by smtp.gmail.com with ESMTPSA id bp4sm4588145wjb.46.2016.07.08.10.24.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Jul 2016 10:24:58 -0700 (PDT) To: Anima WG References: <20160708125429.32189.27110.idtracker@ietfa.amsl.com> <5cf12152afbe49b4b020ad56f261a147@XCH-RCD-006.cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <0ed321f7-c708-e9d6-5ea8-42fc5f08faa0@gmail.com> Date: Sat, 9 Jul 2016 05:25:10 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <5cf12152afbe49b4b020ad56f261a147@XCH-RCD-006.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] FW: New Version Notification for draft-ietf-anima-autonomic-control-plane-03.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 17:25:05 -0000 Hi, I have one big issue with this version, and a few other comments below. > 5.2. Neighbor discovery via mDNS/DNS-SD > > Autonomic devices use DNS-SD/mDNS to discover the IPv6 link-local > address of autonomic neighbors across L2 adjacencies. The result is > stored in the AN Adjacency Table, see Section 5.1.2. Why? We have carefully designed GRASP discovery so that it could do this. While I understand that bootstrap wants to use mDNS/DNSSD to cover the case of non-AN devices, the ACP by definition is only active in AN devices which will all support GRASP by definition. There are two arguments hidden in the change log that seem spurious to me: > Bootstrap > protocol team decided to go with mDNS to discover bootstrap proxy, > and ACP should be consistent with this. Why? ACP should also be consistent with the rest of Anima. That's a magical argument, not a technical one. > ... b) Using GRASP both for the > insecure neighbor discovery and secure ACP operatations raises the > risk of introducing security issues through implementation issues/ > non-isolation between those two instances of GRASP. Firstly, as mentioned again below, there may indeed be no isolation because the implementation may use internal modes, not separate instances. But the argument is empty: the fact that discovery requests are public (unsecured link-local multicast) doesn't make GRASP itself vulnerable. Discovery responses can be secured by GRASP/TLS as soon as bootstrap has occurred. I think this is the completely wrong approach for Anima. (As I said in another message, making mDNS/DNSSD mandatory-to-implement for bootstrap is reasonable, but bootstrap needs to support GRASP discovery as well, to allow "100 pure Anima" deployments.) --- Other comments --- > An example: > > anima.acp+FD99:B02D:8EC3:0:200:0:6400:1@example.com > > The ACP address MUST be specified in its canonical form, as specified > in [RFC5952], to allow for easy textual comparisons. RFC5952 requires lower-case, so your example is wrong and should be anima.acp+fd99:b02d:8ec3:0:200:0:6400:1@example.com > 5.5.4. GRASP/TLS negotiation ... > TBD: The exact negotiation steps in GRASP to achieve this outcome. Right; the first thing is to define the format of the relevant GRASP objective, then I think the rest will follow very naturally. We should try to hold a side meeting about this in Berlin. > 5.5.5. ACP Security Profiles > > A baseline autonomic device MUST support IPsec and SHOULD support > GRASP/TLS It's the GRASP spec that says that a GRASP implementation MUST support TLS when there is no ACP. And every autonomic device MUST support GRASP. So I think this should say A baseline autonomic device MUST support IPsec and GRASP > ... and dTLS. A constrained autonomic device MUST support > dTLS. Hmm. I think we need to talk about dTLS. I find it hard to believe that a node incapable of supporting TLS will ever be an autonomic node. Also, if dTLS is a MUST for some nodes and a SHOULD for others, we don't have guaranteed connectivity. > Autonomic devices need to specify in documentation the set of secure > ACP mechanisms they suppport. That doesn't help anybody. Autonomic nodes need to interoperate in plug and play mode without any human needing to consult documentation or check consistency. Security has to deploy itself with no intervention. > 5.6. GRASP instance details > > Received GRASP packets are assigned to an instance of GRASP by the > context they are received on: > > o GRASP packets received on an ACP (virtual) interfaces are assigned > to the ACP instance of GRASP > > o GRASP packets received inside a TLS connection established for > GRASP/TLS ACP negotiation are assigned to a separate instance of > GRASP for that negotiation. Just to repeat what I said a while back, this might not be how it's implemented. There might equally be a single instance of GRASP in a node but with several modes (insecure/ACP/TLS) that apply to individual sessions. Sessions are distinguished explicitly in the GRASP protocol, as well as by port number. Even if the implementation chooses to launch separate instances of GRASP (rather than just a single multi-threaded instance) there have to be common data structures shared between them. > TBD: The Details of the GRASP objective/packet formats still need to > be defined. Eg: Need to define an allocation for the objective of > "Autonomic Node". Yes. And its primary application would be ACP neighbor discovery, which is why we don't need mDNS/DNSSD. Brian From nobody Fri Jul 8 13:08:21 2016 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8335612D863; Fri, 8 Jul 2016 13:08:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708200819.32156.97635.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 13:08:19 -0700 Archived-At: Cc: anima@ietf.org Subject: [Anima] I-D Action: draft-ietf-anima-stable-connectivity-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 20:08:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach of the IETF. Title : Using Autonomic Control Plane for Stable Connectivity of Network OAM Authors : Toerless Eckert Michael H. Behringer Filename : draft-ietf-anima-stable-connectivity-01.txt Pages : 16 Date : 2016-07-08 Abstract: OAM (Operations, Administration and Management) processes for data networks are often subject to the problem of circular dependencies when relying on network connectivity of the network to be managed for the OAM operations itself. Provisioning during device/network bring up tends to be far less easy to automate than service provisioning later on, changes in core network functions impacting reachability can not be automated either because of ongoing connectivity requirements for the OAM equipment itself, and widely used OAM protocols are not secure enough to be carried across the network without security concerns. This document describes how to integrate OAM processes with the autonomic control plane (ACP) in Autonomic Networks (AN). to provide stable and secure connectivity for those OAM processes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-stable-connectivity/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-anima-stable-connectivity-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-stable-connectivity-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 8 14:38:31 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A22412B018 for ; Fri, 8 Jul 2016 14:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 Z0EYTMJxMYMp for ; Fri, 8 Jul 2016 14:38:27 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B4B912D640 for ; Fri, 8 Jul 2016 14:38:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9092; q=dns/txt; s=iport; t=1468013906; x=1469223506; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=EUapHkqZtHbHxlBgZhrdUod8uccuLw8hDWZUYM0IvI4=; b=YlUUyYTmHi5CM4puTWYLKFG8y+A+uvKstKyI5xkHJgU+5Kx8tZUQtyy9 JuDhBYSzFOOdbwbpUAi1e/quQpFYHgjeuLpWEPBD0CeLF2/1CWIVqHG+7 RlibaP/2+xWGIf0zov6ECOoMfVrRKYHupCTHwhlzXiNZUwcTtdta2o9B8 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AyAgDPHIBX/4UNJK1cgz5WfLkXJIFWI?= =?us-ascii?q?oV2AoEoOBQBAQEBAQEBZSeETAEBBAEBASUTNAkCEAsYCSUPBRMnDxMbBYgICA6?= =?us-ascii?q?+HAEBAQEBAQEBAQEBAQEBAQEBAQEBARcFiXGBA4dtgi8FjniKHI5FCo8skA4eN?= =?us-ascii?q?oIJHBeBVRwyiTIBAQE?= X-IronPort-AV: E=Sophos;i="5.28,332,1464652800"; d="scan'208";a="123863773" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Jul 2016 21:38:25 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u68LcO5a008000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Jul 2016 21:38:24 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id u68LcNcS008217; Fri, 8 Jul 2016 14:38:23 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u68LcNu2008216; Fri, 8 Jul 2016 14:38:23 -0700 Date: Fri, 8 Jul 2016 14:38:23 -0700 From: Toerless Eckert To: Brian E Carpenter Message-ID: <20160708213823.GA15168@cisco.com> References: <20160708125429.32189.27110.idtracker@ietfa.amsl.com> <5cf12152afbe49b4b020ad56f261a147@XCH-RCD-006.cisco.com> <0ed321f7-c708-e9d6-5ea8-42fc5f08faa0@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0ed321f7-c708-e9d6-5ea8-42fc5f08faa0@gmail.com> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Anima WG Subject: Re: [Anima] FW: New Version Notification for draft-ietf-anima-autonomic-control-plane-03.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 21:38:30 -0000 Inline On Sat, Jul 09, 2016 at 05:25:10AM +1200, Brian E Carpenter wrote: > Hi, > > I have one big issue with this version, and a few other comments below. > > > 5.2. Neighbor discovery via mDNS/DNS-SD > > > > Autonomic devices use DNS-SD/mDNS to discover the IPv6 link-local > > address of autonomic neighbors across L2 adjacencies. The result is > > stored in the AN Adjacency Table, see Section 5.1.2. > > Why? We have carefully designed GRASP discovery so that it could do this. > While I understand that bootstrap wants to use mDNS/DNSSD to cover the case > of non-AN devices, the ACP by definition is only active in AN devices which > will all support GRASP by definition. > > There are two arguments hidden in the change log that seem spurious to me: > > > Bootstrap > > protocol team decided to go with mDNS to discover bootstrap proxy, > > and ACP should be consistent with this. > > Why? ACP should also be consistent with the rest of Anima. That's > a magical argument, not a technical one. > > > ... b) Using GRASP both for the > > insecure neighbor discovery and secure ACP operatations raises the > > risk of introducing security issues through implementation issues/ > > non-isolation between those two instances of GRASP. > > Firstly, as mentioned again below, there may indeed be no isolation > because the implementation may use internal modes, not separate > instances. But the argument is empty: the fact that discovery requests > are public (unsecured link-local multicast) doesn't make GRASP itself > vulnerable. Discovery responses can be secured by GRASP/TLS as soon > as bootstrap has occurred. > > I think this is the completely wrong approach for Anima. > (As I said in another message, making mDNS/DNSSD mandatory-to-implement > for bootstrap is reasonable, but bootstrap needs to support > GRASP discovery as well, to allow "100 pure Anima" deployments.) I hope that we have all the folks in Berlin in the room to get to better rough consensus on this. I was just writing into this version of the ACP draft what seemed to be best aligned with the choices the current bootstrap draft has made, but: a) I did vote for GRASP in the bootstrap meetings but was the only one. b) I always wanted to make sure that bootstrap can be adopted by non-anima solutions that wouldn't use ACP. mDNS might be an easier sell there. c) Interpreting your text above seems to point to the option that the bootstrap draft could say that bootstrap used for an anima solution must use Grasp, and used outside of an anima solution should support mDNS ... does that sound like a good compromise ? d) My preference of isolation is based on concepts i understand. I don't think that you need "separate protocols" for isolation. I understand how "instances" create very clear isolation independent of the protocol choosen. I am still not clear about your "mode" concept, hopefully i can "grasp" that in berlin. e) The more complex the protocol is, the more attack vector i fear (FUD) it may have. Even though the discovery needed for anima is simple, mDNS is quite feature rich, and if the argument is to share a pre-existing mDNS library, then that makes me worried (admittedly FUD!). Simple example: Alice wants to discover bootstrap proxy, Bob is bootstrap proxy, but Dos (3rd device on Lan), responds with misleading responses about Bobs services. How well would a randomn "pre-existing" mDNS library be able to ignore Dos. How well could we specify Grasp to do this. > > anima.acp+FD99:B02D:8EC3:0:200:0:6400:1@example.com > > > > The ACP address MUST be specified in its canonical form, as specified > > in [RFC5952], to allow for easy textual comparisons. > > RFC5952 requires lower-case, so your example is wrong and should be > anima.acp+fd99:b02d:8ec3:0:200:0:6400:1@example.com Haha. We did it again. Michael must also have looked at some Cisco IOS output. But you're now awarded the golden metal as the RFC5952 defender ;-) > > 5.5.5. ACP Security Profiles > > > > A baseline autonomic device MUST support IPsec and SHOULD support > > GRASP/TLS > > It's the GRASP spec that says that a GRASP implementation MUST > support TLS when there is no ACP. And every autonomic device > MUST support GRASP. So I think this should say > > A baseline autonomic device MUST support IPsec and GRASP So my thinking was: -> Negotiation of ACP between two neighbors: In many cases, devices will only support one security option. That makes the approach of simply probing the security option the most lightweight one. Thats why i wrote (already in the prior version of ACP draft), that ACP channel negotiation via TLS/GRASP was optional and primarily required when you need a more intelligent negotiation outcome than "probe channel options, each option has priority. Highest priority option that works wins". -> The main reason to make that negotiation optional is that we haven't yet brainstormed IMHO any interesting negotiation choices that are more complex, and unless we have those, we couldn't even define the GRASP messaging for the negotiation. Thats why i felt it was better to make it this way, so we could have any more intelligent ACP channel negotiation via GRASP done in a separate draft when we've gollected some more complex negotiation elements. I am not sure how soon we'd need those. I think we'd only need those when wee start seeing more complex security channel options with parameters to negotiate. > > ... and dTLS. A constrained autonomic device MUST support > > dTLS. > > Hmm. I think we need to talk about dTLS. I find it hard to believe > that a node incapable of supporting TLS will ever be an autonomic node. > Also, if dTLS is a MUST for some nodes and a SHOULD for others, > we don't have guaranteed connectivity. CoAP devices supposedly will not have dTLS because they do not need TCP. Carsten explained to me why they choose not to use TCP. The ACP text shuold have good explanations why we do IMHO not need any-to-eny connectivity. Aka: I will not connect a sensor to a service provider core-router. [ The port on that core router costs $50,000, you do not want to waste it on a $5 sensor]. Aka: its quite useful to consider protocol profiles and have devices support a subset of profiles that they need to talk to neighbors. Enterprise edge-switches would likely be the ones with both some "IoT" profile (dTLS) and some "basline" profile (TLS). > > Autonomic devices need to specify in documentation the set of secure > > ACP mechanisms they suppport. > > That doesn't help anybody. Autonomic nodes need to interoperate in > plug and play mode without any human needing to consult documentation > or check consistency. Security has to deploy itself with no intervention. See above on why i think that any-to-any connectivity isn't even a requirement. Yes, its a very nice vision, but when it comes at the cost of having to implement a "lowest-common-denominator" protocol stack thats undesired dead weight on many devices, then the vision becomes undesirable IMHO. > > 5.6. GRASP instance details > > > > Received GRASP packets are assigned to an instance of GRASP by the > > context they are received on: > > > > o GRASP packets received on an ACP (virtual) interfaces are assigned > > to the ACP instance of GRASP > > > > o GRASP packets received inside a TLS connection established for > > GRASP/TLS ACP negotiation are assigned to a separate instance of > > GRASP for that negotiation. > > Just to repeat what I said a while back, this might not be how it's > implemented. There might equally be a single instance of GRASP in a > node but with several modes (insecure/ACP/TLS) that apply to individual > sessions. Sessions are distinguished explicitly in the GRASP protocol, > as well as by port number. Even if the implementation chooses to > launch separate instances of GRASP (rather than just a single multi-threaded > instance) there have to be common data structures shared between them. For instances, i don't think that's true. Ideally, different instanes are different processes with totally independent data memory (code shared of course). I also don't see off the top of my head any savings through sharing data memory across the GRASP instances we're talking about. Cheers Toerless > > TBD: The Details of the GRASP objective/packet formats still need to > > be defined. Eg: Need to define an allocation for the objective of > > "Autonomic Node". > > Yes. And its primary application would be ACP neighbor discovery, which > is why we don't need mDNS/DNSSD. > > Brian > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- Toerless Eckert, eckert@cisco.com From nobody Sat Jul 9 00:19:30 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F086312D0B8 for ; Sat, 9 Jul 2016 00:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 xNPvIP3amq2F for ; Sat, 9 Jul 2016 00:19:26 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 9FC9E12B010 for ; Sat, 9 Jul 2016 00:19:25 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id f65so8561921wmi.0 for ; Sat, 09 Jul 2016 00:19:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=gfgOqvUga37G2OlAvpm0Y65pGeaZfbAP9b8igS8wNdk=; b=QVpk6n5XqeTB5twNbHiV5vsqdW5EjikVzMLE4zQyqSwjXEwCEHU4xbknLh1dFMJAN6 NtBW3n3R7njWXGP4lyTKC8Pu5eNXm8TSWPgA+onnX3OAw4Gkel58rSSMHcydAxPrP+xX uLhMXGjYNjs8/tLhve5hI0BD64IzXi8Yg5TGyxRY9wibTX72UdYZm9rWakaj74qqAWqk h7zlmpmd45d4sB6Lcl/IpWcXZUS1snDDaykJKfID7jzJe1Bs+jCCO8heftzxAGwd+B1t /sT75rlA2bUxQ2QYCuWRAeJJlNHrV6PPS4JIN/1oiO2g8vRf1tv+SGW8jYq6WCWNHYBE W18w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=gfgOqvUga37G2OlAvpm0Y65pGeaZfbAP9b8igS8wNdk=; b=HQsHiJwWlGHiR7aC3efRtKbSr9SUwvNecPit/lBu3edTqJIRdrpy5y2EgWsLQgOTA7 qMQy3fnQfYS5Xw9VBWn8zSZH70aaUGuX0Dq9PV0z1OVGD0CcDFgWUZwid1cNKzZywi+U A6MPfTVrlF8cC/7mGAJyY5UeAbfBKBVla2jH2uHWVqO44GNKuSrkV0yx+3klE9p37xo9 /PdRDYHIUXZZBXWD/FlQNNm46tFRYWGWrt3GLVi0SCmAWmwS1mg/hm5+4UcfJZsG0Kuf wAN3GbvUHX7CvOBS9XaZI3/fwjyvFGoZ+MFs8sh1jrlF0eDioYjWSfDs/jpHg9nuWAW0 D//A== X-Gm-Message-State: ALyK8tIMScboHN4NX/zSYiHCMt0IPhwLNKtZxM0Gu1HkLCSk/2uDca4nl/Tdo1VrY+vfLA== X-Received: by 10.28.193.14 with SMTP id r14mr2178855wmf.94.1468048763592; Sat, 09 Jul 2016 00:19:23 -0700 (PDT) Received: from [10.0.1.29] (cpc66883-mort6-2-0-cust696.19-2.cable.virginm.net. [92.233.126.185]) by smtp.gmail.com with ESMTPSA id b1sm6737240wjx.9.2016.07.09.00.19.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Jul 2016 00:19:22 -0700 (PDT) To: Toerless Eckert References: <20160708125429.32189.27110.idtracker@ietfa.amsl.com> <5cf12152afbe49b4b020ad56f261a147@XCH-RCD-006.cisco.com> <0ed321f7-c708-e9d6-5ea8-42fc5f08faa0@gmail.com> <20160708213823.GA15168@cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <017157ce-60a8-5732-b2fb-3d5836c7d00b@gmail.com> Date: Sat, 9 Jul 2016 19:19:36 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160708213823.GA15168@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima WG Subject: Re: [Anima] FW: New Version Notification for draft-ietf-anima-autonomic-control-plane-03.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2016 07:19:29 -0000 Hi Toerless, On 09/07/2016 09:38, Toerless Eckert wrote: > Inline > > On Sat, Jul 09, 2016 at 05:25:10AM +1200, Brian E Carpenter wrote: >> Hi, >> >> I have one big issue with this version, and a few other comments below. >> >>> 5.2. Neighbor discovery via mDNS/DNS-SD >>> >>> Autonomic devices use DNS-SD/mDNS to discover the IPv6 link-local >>> address of autonomic neighbors across L2 adjacencies. The result is >>> stored in the AN Adjacency Table, see Section 5.1.2. >> >> Why? We have carefully designed GRASP discovery so that it could do this. >> While I understand that bootstrap wants to use mDNS/DNSSD to cover the case >> of non-AN devices, the ACP by definition is only active in AN devices which >> will all support GRASP by definition. >> >> There are two arguments hidden in the change log that seem spurious to me: >> >>> Bootstrap >>> protocol team decided to go with mDNS to discover bootstrap proxy, >>> and ACP should be consistent with this. >> >> Why? ACP should also be consistent with the rest of Anima. That's >> a magical argument, not a technical one. >> >>> ... b) Using GRASP both for the >>> insecure neighbor discovery and secure ACP operatations raises the >>> risk of introducing security issues through implementation issues/ >>> non-isolation between those two instances of GRASP. >> >> Firstly, as mentioned again below, there may indeed be no isolation >> because the implementation may use internal modes, not separate >> instances. But the argument is empty: the fact that discovery requests >> are public (unsecured link-local multicast) doesn't make GRASP itself >> vulnerable. Discovery responses can be secured by GRASP/TLS as soon >> as bootstrap has occurred. >> >> I think this is the completely wrong approach for Anima. >> (As I said in another message, making mDNS/DNSSD mandatory-to-implement >> for bootstrap is reasonable, but bootstrap needs to support >> GRASP discovery as well, to allow "100 pure Anima" deployments.) > > I hope that we have all the folks in Berlin in the room to get to better rough > consensus on this. I was just writing into this version of the ACP draft what > seemed to be best aligned with the choices the current bootstrap draft has > made, but: > > a) I did vote for GRASP in the bootstrap meetings but was the only one. > b) I always wanted to make sure that bootstrap can be adopted by non-anima > solutions that wouldn't use ACP. mDNS might be an easier sell there. Yes, I agree with that. That's why I have no problem with mDNS/DNSSD being REQUIRED for bootstrap. But that does not exclude GRASP Discovery. > c) Interpreting your text above seems to point to the option that the > bootstrap draft could say that bootstrap used for an anima solution > must use Grasp, and used outside of an anima solution should support > mDNS ... does that sound like a good compromise ? I didn't try to write exact normative text yet, and the phrase "mandatory to implement" is actually ambiguous (does it mean "mandatory to write the code" or "mandatory to switch on"?). But I think I lean towards saying that any device that supports GRASP MUST use GRASP Discovery for bootstrap, and any device that doesn't support GRASP MUST use mDNS/DNSSD for bootstrap. Therefore proxies must respond to both, to allow mixed scenarios. I don't especially like this but I think it is realistic and doesn't add significantly to software footprints. Non-AN devices don't need any GRASP code and AN devices will have GRASP code anyway, and are very likely to have DNS code for other reasons. It also means that the "market" can naturally choose the best solution. > d) My preference of isolation is based on concepts i understand. I don't > think that you need "separate protocols" for isolation. I understand > how "instances" create very clear isolation independent of the protocol > choosen. I am still not clear about your "mode" concept, hopefully > i can "grasp" that in berlin. The issue with genuinely separate instances is that they turn out to need common data. In my Python-infected brain, they need to share things such as: ASA_registry (and its lock) objective_registry (and its lock) discovery_cache (and its lock) session_id_cache (and its lock) flood_cache (and its lock) FIFO queues for pending discovery operations To be clear: we need a node-wide ASA registry so that we can guarantee only one instance of a given ASA is active; we need a node-wide objective registry to guarantee that only one ASA is managing a given objective (or alternatively, to allow coordinated management by multiple ASAs); we need a node-wide session_ID cache to guarantee no clashes of session_IDs. Then it's much more efficient to share the discovery cache and queues and the flood cache. Given that amount of shared state, being hammered by separate threads for each active ASA plus some internal threads for the GRASP kernel itself, I can't visualize how to make separate instances provide genuine isolation. (Of course, you could run genuinely separate instances in one node but then each one would need its own IP address too.) (Full disclosure: I run tests with my prototype by invoking separate Python instances in one node, and they happily talk to each other even with the same IP address, but there's a little bit of fakery to prevent instance 1 discovering itself as well as discovering instances 2 and 3...) > e) The more complex the protocol is, the more attack vector i fear (FUD) it > may have. Even though the discovery needed for anima is simple, mDNS > is quite feature rich, and if the argument is to share a pre-existing > mDNS library, then that makes me worried (admittedly FUD!). Simple > example: Alice wants to discover bootstrap proxy, Bob is bootstrap proxy, > but Dos (3rd device on Lan), responds with misleading responses about > Bobs services. How well would a randomn "pre-existing" mDNS > library be able to ignore Dos. How well could we specify Grasp to > do this. I certainly can't answer for mDNS and probably nobody can answer yet for DNSSD. For GRASP, discovery *only* responds with a locator (address, protocol, port). If both Bob and Dos reply to GRASP discovery, Alice gets to choose. If she chooses Dos, we can't help her ;-). Regards Brian > >>> anima.acp+FD99:B02D:8EC3:0:200:0:6400:1@example.com >>> >>> The ACP address MUST be specified in its canonical form, as specified >>> in [RFC5952], to allow for easy textual comparisons. >> >> RFC5952 requires lower-case, so your example is wrong and should be >> anima.acp+fd99:b02d:8ec3:0:200:0:6400:1@example.com > > Haha. We did it again. Michael must also have looked at some Cisco IOS > output. But you're now awarded the golden metal as the RFC5952 defender ;-) > >>> 5.5.5. ACP Security Profiles >>> >>> A baseline autonomic device MUST support IPsec and SHOULD support >>> GRASP/TLS >> >> It's the GRASP spec that says that a GRASP implementation MUST >> support TLS when there is no ACP. And every autonomic device >> MUST support GRASP. So I think this should say >> >> A baseline autonomic device MUST support IPsec and GRASP > > So my thinking was: > > -> Negotiation of ACP between two neighbors: > In many cases, devices will only support one security option. > That makes the approach of simply probing the security option > the most lightweight one. Thats why i wrote (already in the prior > version of ACP draft), that ACP channel negotiation via TLS/GRASP > was optional and primarily required when you need a more intelligent > negotiation outcome than "probe channel options, each option has > priority. Highest priority option that works wins". > > -> The main reason to make that negotiation optional is that we > haven't yet brainstormed IMHO any interesting negotiation choices > that are more complex, and unless we have those, we couldn't even > define the GRASP messaging for the negotiation. Thats why i felt > it was better to make it this way, so we could have any more intelligent > ACP channel negotiation via GRASP done in a separate draft when we've > gollected some more complex negotiation elements. I am not sure > how soon we'd need those. I think we'd only need those when wee start > seeing more complex security channel options with parameters to > negotiate. > >>> ... and dTLS. A constrained autonomic device MUST support >>> dTLS. >> >> Hmm. I think we need to talk about dTLS. I find it hard to believe >> that a node incapable of supporting TLS will ever be an autonomic node. >> Also, if dTLS is a MUST for some nodes and a SHOULD for others, >> we don't have guaranteed connectivity. > > CoAP devices supposedly will not have dTLS because they do not need TCP. > Carsten explained to me why they choose not to use TCP. > > The ACP text shuold have good explanations why we do IMHO not need > any-to-eny connectivity. Aka: I will not connect a sensor to a > service provider core-router. [ The port on that core router costs > $50,000, you do not want to waste it on a $5 sensor]. Aka: its quite > useful to consider protocol profiles and have devices support a > subset of profiles that they need to talk to neighbors. Enterprise > edge-switches would likely be the ones with both some "IoT" profile > (dTLS) and some "basline" profile (TLS). > >>> Autonomic devices need to specify in documentation the set of secure >>> ACP mechanisms they suppport. >> >> That doesn't help anybody. Autonomic nodes need to interoperate in >> plug and play mode without any human needing to consult documentation >> or check consistency. Security has to deploy itself with no intervention. > > See above on why i think that any-to-any connectivity isn't even > a requirement. Yes, its a very nice vision, but when it comes at the > cost of having to implement a "lowest-common-denominator" protocol > stack thats undesired dead weight on many devices, then the vision > becomes undesirable IMHO. > >>> 5.6. GRASP instance details >>> >>> Received GRASP packets are assigned to an instance of GRASP by the >>> context they are received on: >>> >>> o GRASP packets received on an ACP (virtual) interfaces are assigned >>> to the ACP instance of GRASP >>> >>> o GRASP packets received inside a TLS connection established for >>> GRASP/TLS ACP negotiation are assigned to a separate instance of >>> GRASP for that negotiation. >> >> Just to repeat what I said a while back, this might not be how it's >> implemented. There might equally be a single instance of GRASP in a >> node but with several modes (insecure/ACP/TLS) that apply to individual >> sessions. Sessions are distinguished explicitly in the GRASP protocol, >> as well as by port number. Even if the implementation chooses to >> launch separate instances of GRASP (rather than just a single multi-threaded >> instance) there have to be common data structures shared between them. > > For instances, i don't think that's true. Ideally, different instanes > are different processes with totally independent data memory (code shared > of course). I also don't see off the top of my head any savings through > sharing data memory across the GRASP instances we're talking about. > > Cheers > Toerless > >>> TBD: The Details of the GRASP objective/packet formats still need to >>> be defined. Eg: Need to define an allocation for the objective of >>> "Autonomic Node". >> >> Yes. And its primary application would be ACP neighbor discovery, which >> is why we don't need mDNS/DNSSD. >> >> Brian >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > From nobody Sat Jul 9 03:38:28 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 835FC12D137 for ; Sat, 9 Jul 2016 03:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 6UdRAmRhaiUI for ; Sat, 9 Jul 2016 03:38:24 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 27A5512D13E for ; Sat, 9 Jul 2016 03:38:24 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id f65so12417802wmi.0 for ; Sat, 09 Jul 2016 03:38:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=BUppc6nyODkw7R5oTYCz4pTyh7GyluGXdoU0T/Kq9jA=; b=p9vYEOPsmXJcqMNzXCQOyGJ/CHN2eL7EpyHIrfAaHrnXLcaCK8T9kgByyrT60b5s/t 1SQg2OtR1qNsfY3d22vWCfUnCftq4xYI0i1LmYh6wRSO+8EXjHGJZewNnoVdcraq+RxR kLWzAYc/USsLZqAAeMuBngrMz+QljMUYtcnzQJOhuQshSfaALaZlgi2xcGitRDY6s8DO Xp83y33ck1F9d6tMa4kgFgMK6W3y/pk6RTC3WZd66f4q20QxFdu27euyrlJ8EE4QXLiy E5/Y3VIjOGxx1aw4qJyYOe5fk+wYVRU4S7wrjmlhiBWXdXwSOkqSIWMPICFiLouw7jtW 1GjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=BUppc6nyODkw7R5oTYCz4pTyh7GyluGXdoU0T/Kq9jA=; b=XmAYR7dG35+6ja66vH0g1JjOPQq09q87rjgR7mm00AbZVafcdQO+aXafnVfEZLWrzm 3tEvSFfaXQz22XwNdw7XiOnv3vW7zgE+6cRrSdUdTuZiVHTnZp0bAn5E4vPla0ioy0Z6 H5hEF99rEQObM9pP/r2ykT2/edBWTMKl/A+0pcdzjgINKn0TGBgv7P5xWXEj5kXABx0J wkJLpctgy74HHJwjc4h0fFxUSi3W+z0RxsKILOONOEmlyC6DeWkhhA/PvtMG9bZYK2U+ lD4hUxcZzjueJ7ZAm4PLMYOD+OxN4MWLO/icnqY13JNOYUGTE/ZnLMSx004LNS7iUOtW 9lMw== X-Gm-Message-State: ALyK8tL8U7MrGdFLLholXAz9rPmQiIXvI/6qOJ+iVgzjcGP9xTj+c2XTRnvt4ACAal1i3g== X-Received: by 10.28.128.15 with SMTP id b15mr611070wmd.100.1468060702423; Sat, 09 Jul 2016 03:38:22 -0700 (PDT) Received: from [10.0.1.29] (cpc66883-mort6-2-0-cust696.19-2.cable.virginm.net. [92.233.126.185]) by smtp.gmail.com with ESMTPSA id q203sm781100wmd.24.2016.07.09.03.38.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Jul 2016 03:38:21 -0700 (PDT) To: Laurent Ciavaglia , anima References: <20160708153949.32209.45567.idtracker@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <1fe314ad-d22f-1291-7e85-4e51ccd328a2@gmail.com> Date: Sat, 9 Jul 2016 22:38:35 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Fwd: New Version Notification for draft-du-anima-an-intent-04.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2016 10:38:26 -0000 Hi, Thanks for this. One point raises some questions in my mind: > 5. Intent splitting (on each node): Intent is split into sections, > one for the ANI itself, others for specific Autonomic Functions. > ASAs are notified if there is new Intent for them. Some intent > sections may not apply to a particular node. Now each component > of a node (ANI, all ASAs) know their respective Intent. I am wondering why, in this case, Intent would be broadcasted in a single operation as a single file. Why wouldn't we simply send out each section separately? Also, how is the relevance for each ASA known? And is that the correct granularity of the section? Maybe the granularity should be individual objectives, or certain groups of objectives? I think this needs more discussion. Regards Brian On 09/07/2016 03:45, Laurent Ciavaglia wrote: > Dear ANIMA WG, > > FYI: a new version of the I-D has been posted. > > The main update is the addition of a section on Intent Life Cycle based on the initial text provided by Michael Behringer > (https://mailarchive.ietf.org/arch/msg/anima/rk2CgO62nmXFuKOBX-Gtb5v0p5E). > Michael is now also co-author of the I-D. > > *We've asked the ANIMA WG chairs for a slot at IETF96/Berlin to present the updates on this draft and report on the discussion > on Intent and way forward.** > **Your comments are thus highly welcome before the meet**ing**.* > > Best regards, Laurent. > > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-du-anima-an-intent-04.txt > Date: Fri, 8 Jul 2016 08:39:49 -0700 > From: internet-drafts@ietf.org > To: Laurent Ciavaglia , Jeferson Campos Nobre , Michael > Behringer , Sheng Jiang , Zongpeng Du , Michael H. Behringer > , Laurent Ciavaglia > > > > A new version of I-D, draft-du-anima-an-intent-04.txt > has been successfully submitted by Laurent Ciavaglia and posted to the > IETF repository. > > Name: draft-du-anima-an-intent > Revision: 04 > Title: ANIMA Intent Policy and Format > Document date: 2016-07-08 > Group: Individual Submission > Pages: 13 > URL: https://www.ietf.org/internet-drafts/draft-du-anima-an-intent-04.txt > Status: https://datatracker.ietf.org/doc/draft-du-anima-an-intent/ > Htmlized: https://tools.ietf.org/html/draft-du-anima-an-intent-04 > Diff: https://www.ietf.org/rfcdiff?url2=draft-du-anima-an-intent-04 > > Abstract: > One of the goals of autonomic networking is to simplify the > management of networks by human operators. Intent Based Networking > (IBN) is a possible approach to realize this goal. With IBN, the > operator indicates to the network what to do (i.e. her intent) and > not how to do it. In the field of Policy Based Management (PBM), the > concept of intent is called a declarative policy. This document > proposes a refinement of the intent concept initially defined in > [RFC7575] for autonomic networks by providing a more complete > definition, a life-cycle, some use cases and a tentative format of > the ANIMA Intent Policy. > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Mon Jul 11 00:22:41 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C949512D0CA for ; Mon, 11 Jul 2016 00:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 384AG19Cuj6g for ; Mon, 11 Jul 2016 00:22:38 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C90BF12D0C9 for ; Mon, 11 Jul 2016 00:22:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5477; q=dns/txt; s=iport; t=1468221757; x=1469431357; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=NHib8HVLwqmuzgaTFHpq8bsN/GsAiXdMNFQTwU6kGlA=; b=ffix6yKQBKmVNYp1NPhBvPU3LcmXunl/iAfLKTUL+XHtxn+jlHAvWviQ Ll3/aeRK7L7ADF9fCGvLchX2DfW7xSocAYae8QVSWYQiJkyarc+yFvsJ9 qaic3i/PfeXH6GvYDiUwR319RcyfhEP61Xh9A6wR902LvcACfOEPpd+Q0 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BaAgDwSINX/49dJa1cgz5WfAa5EIF6I?= =?us-ascii?q?oV2AoElOBQBAQEBAQEBZSeEXAEBBAEBATg0CQcHBAIBCBEDAQEBAR4JBycLFAk?= =?us-ascii?q?IAgQBEggRiA8IDr5TAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIYng0qBA4QkAQEih?= =?us-ascii?q?VQFjgaLEgGGDIg+gXFOhAqIaoZaiTQBHjaCCRyBTG6HLAcIFx9/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,345,1464652800"; d="scan'208";a="128196110" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jul 2016 07:22:36 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u6B7MawT003439 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Jul 2016 07:22:36 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 11 Jul 2016 02:22:26 -0500 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1210.000; Mon, 11 Jul 2016 02:22:26 -0500 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , Laurent Ciavaglia , anima Thread-Topic: [Anima] Fwd: New Version Notification for draft-du-anima-an-intent-04.txt Thread-Index: AQHR2c4OMfwFdfpHP0SglLpeB3vZZKAS1JlQ Date: Mon, 11 Jul 2016 07:22:26 +0000 Message-ID: References: <20160708153949.32209.45567.idtracker@ietfa.amsl.com> <1fe314ad-d22f-1291-7e85-4e51ccd328a2@gmail.com> In-Reply-To: <1fe314ad-d22f-1291-7e85-4e51ccd328a2@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.238.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Fwd: New Version Notification for draft-du-anima-an-intent-04.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 07:22:40 -0000 > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E > Carpenter > Sent: 09 July 2016 12:39 > To: Laurent Ciavaglia ; anima > > Subject: Re: [Anima] Fwd: New Version Notification for draft-du-anima-an- > intent-04.txt >=20 > Hi, >=20 > Thanks for this. One point raises some questions in my mind: >=20 > > 5. Intent splitting (on each node): Intent is split into sections, > > one for the ANI itself, others for specific Autonomic Functions. > > ASAs are notified if there is new Intent for them. Some intent > > sections may not apply to a particular node. Now each component > > of a node (ANI, all ASAs) know their respective Intent. >=20 > I am wondering why, in this case, Intent would be broadcasted in a single > operation as a single file. Why wouldn't we simply send out each section > separately? Simplicity. We've discussed many ways of making Intent distribution more gr= anular, optimised, etc. My argument was and is: Let's start simple, and see= whether we actually need to make it more granular, optimised, etc. If Inte= nt is really a high level policy, it will change very infrequently, so I th= ink optimisations are not required. Having said this, we should have a "pla= n b" in case we find later that the simple method isn't good enough.=20 =20 > Also, how is the relevance for each ASA known?=20 My proposal: Intent comes in sections; those sections are labelled with the= name of the ASA / autonomic function they belong to. Also here, there are = many ways to do this, it's a simple proposal which could be optimised in ma= ny ways.=20 > And is that the correct > granularity of the section? Maybe the granularity should be individual > objectives, or certain groups of objectives? I think this needs more > discussion. On this one I agree!! We should have more discussions on that. Your point f= rom the other mail, that we should try implementing some ASAs would help un= derstand this better.=20 But: I suggest we make things more complicated only if we really can see wh= y the proposed approach wouldn't work.=20 Michael >=20 > Regards > Brian >=20 > On 09/07/2016 03:45, Laurent Ciavaglia wrote: > > Dear ANIMA WG, > > > > FYI: a new version of the I-D has been posted. > > > > The main update is the addition of a section on Intent Life Cycle > > based on the initial text provided by Michael Behringer > (https://mailarchive.ietf.org/arch/msg/anima/rk2CgO62nmXFuKOBX- > Gtb5v0p5E). > > Michael is now also co-author of the I-D. > > > > *We've asked the ANIMA WG chairs for a slot at IETF96/Berlin to > > present the updates on this draft and report on the discussion on > > Intent and way forward.** **Your comments are thus highly welcome > > before the meet**ing**.* > > > > Best regards, Laurent. > > > > > > -------- Forwarded Message -------- > > Subject: New Version Notification for draft-du-anima-an-intent-04.t= xt > > Date: Fri, 8 Jul 2016 08:39:49 -0700 > > From: internet-drafts@ietf.org > > To: Laurent Ciavaglia , Jefer= son > Campos Nobre , Michael > > Behringer , Sheng Jiang > , > > Zongpeng Du , Michael H. Behringer > > , Laurent Ciavaglia > > > > > > > > > > A new version of I-D, draft-du-anima-an-intent-04.txt has been > > successfully submitted by Laurent Ciavaglia and posted to the IETF > > repository. > > > > Name: draft-du-anima-an-intent > > Revision: 04 > > Title: ANIMA Intent Policy and Format > > Document date: 2016-07-08 > > Group: Individual Submission > > Pages: 13 > > URL: https://www.ietf.org/internet-drafts/draft-du-anima-an-= intent- > 04.txt > > Status: https://datatracker.ietf.org/doc/draft-du-anima-an-inte= nt/ > > Htmlized: https://tools.ietf.org/html/draft-du-anima-an-intent-04 > > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-du-anima-an-i= ntent-04 > > > > Abstract: > > One of the goals of autonomic networking is to simplify the > > management of networks by human operators. Intent Based Networking > > (IBN) is a possible approach to realize this goal. With IBN, the > > operator indicates to the network what to do (i.e. her intent) and > > not how to do it. In the field of Policy Based Management (PBM), th= e > > concept of intent is called a declarative policy. This document > > proposes a refinement of the intent concept initially defined in > > [RFC7575] for autonomic networks by providing a more complete > > definition, a life-cycle, some use cases and a tentative format of > > the ANIMA Intent Policy. > > > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at tools.i= etf.org. > > > > The IETF Secretariat > > > > > > > > > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Mon Jul 11 05:15:43 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D0B12D134 for ; Mon, 11 Jul 2016 05:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Xo11KYd15uPd for ; Mon, 11 Jul 2016 05:15:40 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (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 CF47A1288B8 for ; Mon, 11 Jul 2016 05:15:39 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id q132so70872387lfe.3 for ; Mon, 11 Jul 2016 05:15:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=OZ1ODu69eeFrLRXuFS1Qv1IbN1T/1AtTS3bbdxDn+rI=; b=KQQtPD8eZAqEdGIhF8eCIXo6t4LsIri3q/L8tqh8ZRFVbX5jvPyQgXb7c6ttwZvH8r Ea+55rhKblKa5VcdTqyObU3ddFiUYAvug287BybXNDG6hXpZ2kgIx2LMGbhaDApnqUAl x9lAccysgO0eJl5XUxhsG3QW71vMsfKm+jrmq8c2MOd2A+R29rhmYOLPZ2+XV6zLvKZC qwfQfllTVLZzj3Gvg5N1Hm9U/V6ue7kvUYfOl4204qSZJl216Ty1ZvRJRhFbNMmp8N5q aDjMLtVYVBKbDQcNq3jQhqqZQKHX6k3AxLUzjUtX6BYTglSahDEsuDw9v59PIGGD6Za5 1xtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=OZ1ODu69eeFrLRXuFS1Qv1IbN1T/1AtTS3bbdxDn+rI=; b=UVCOByQvCp7V1j+8BBsQ+0zyOBdTjRdkvkrFr5tPCW0rZzTxZHpvhcj2eOjVi68wzO 2ey0ZLZ8NS4g0gdpIP9vfWYpzknqdgXYtQNQyP4ywAV9Rsim9P29Va7VBPNemSB9mgeP Lc4dmMKtkBKrvvZzqr+QwEhdBJkav5Z8Zy+nAITT9tOonWD7i93dVkxdYzdvc5Y0mda8 HeDjpW7eD9XC9Qf162QAjgA2oKQoAwVHTqepx+gtMm/9+jNlM01GHyK90UjquOPANRCr MCM/KTYwSfIt+ftC8Km82IhKIfTytg+24uK2b9eH6l8v9Svk6ixwjzHMwiY0OqD1eeLV BZ7A== X-Gm-Message-State: ALyK8tKU6KQf5hbffNNp7KaOh8oXHvUWY27ZS/AlWGD73Y0cbNGm6Ypm8cOAwnc3FkvhmA== X-Received: by 10.25.201.85 with SMTP id z82mr2546741lff.104.1468239337962; Mon, 11 Jul 2016 05:15:37 -0700 (PDT) Received: from [10.0.1.29] (cpc66883-mort6-2-0-cust696.19-2.cable.virginm.net. [92.233.126.185]) by smtp.gmail.com with ESMTPSA id o184sm4072349lfb.19.2016.07.11.05.15.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Jul 2016 05:15:37 -0700 (PDT) To: "Michael Behringer (mbehring)" , Laurent Ciavaglia , anima References: <20160708153949.32209.45567.idtracker@ietfa.amsl.com> <1fe314ad-d22f-1291-7e85-4e51ccd328a2@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <54f47cc8-bd8b-3783-274a-86e98d9e49ea@gmail.com> Date: Tue, 12 Jul 2016 00:15:36 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Fwd: New Version Notification for draft-du-anima-an-intent-04.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 12:15:42 -0000 On 11/07/2016 19:22, Michael Behringer (mbehring) wrote: >> -----Original Message----- >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E >> Carpenter >> Sent: 09 July 2016 12:39 >> To: Laurent Ciavaglia ; anima >> >> Subject: Re: [Anima] Fwd: New Version Notification for draft-du-anima-an- >> intent-04.txt >> >> Hi, >> >> Thanks for this. One point raises some questions in my mind: >> >>> 5. Intent splitting (on each node): Intent is split into sections, >>> one for the ANI itself, others for specific Autonomic Functions. >>> ASAs are notified if there is new Intent for them. Some intent >>> sections may not apply to a particular node. Now each component >>> of a node (ANI, all ASAs) know their respective Intent. >> >> I am wondering why, in this case, Intent would be broadcasted in a single >> operation as a single file. Why wouldn't we simply send out each section >> separately? > > Simplicity. We've discussed many ways of making Intent distribution more granular, optimised, etc. My argument was and is: Let's start simple, and see whether we actually need to make it more granular, optimised, etc. If Intent is really a high level policy, it will change very infrequently, so I think optimisations are not required. Having said this, we should have a "plan b" in case we find later that the simple method isn't good enough. I'm all for simplicity. However, it might be that sending the sections separately would actually be simpler. I think we don't know yet. >> Also, how is the relevance for each ASA known? > > My proposal: Intent comes in sections; those sections are labelled with the name of the ASA / autonomic function they belong to. Also here, there are many ways to do this, it's a simple proposal which could be optimised in many ways. > >> And is that the correct >> granularity of the section? Maybe the granularity should be individual >> objectives, or certain groups of objectives? I think this needs more >> discussion. > > On this one I agree!! We should have more discussions on that. Your point from the other mail, that we should try implementing some ASAs would help understand this better. Yes. There's been an assumption, I think, that one "autonomic function" == one ASA. We need to be clear if that is an axiom, and we need to think about how ASAs are named, and if those names need to be registered somehow. > But: I suggest we make things more complicated only if we really can see why the proposed approach wouldn't work. Agreed. As far as I can see, if we naively assume that we use GRASP to distribute Intent, we can flood Intent as long as it fits in one packet; if that doesn't apply, we can synchronize it via GRASP/TCP. That seems OK for now. Since Intent is supposed to change rarely, we don't need to optimise performance. Regards Brian > > Michael > > >> >> Regards >> Brian >> >> On 09/07/2016 03:45, Laurent Ciavaglia wrote: >>> Dear ANIMA WG, >>> >>> FYI: a new version of the I-D has been posted. >>> >>> The main update is the addition of a section on Intent Life Cycle >>> based on the initial text provided by Michael Behringer >> (https://mailarchive.ietf.org/arch/msg/anima/rk2CgO62nmXFuKOBX- >> Gtb5v0p5E). >>> Michael is now also co-author of the I-D. >>> >>> *We've asked the ANIMA WG chairs for a slot at IETF96/Berlin to >>> present the updates on this draft and report on the discussion on >>> Intent and way forward.** **Your comments are thus highly welcome >>> before the meet**ing**.* >>> >>> Best regards, Laurent. >>> >>> >>> -------- Forwarded Message -------- >>> Subject: New Version Notification for draft-du-anima-an-intent-04.txt >>> Date: Fri, 8 Jul 2016 08:39:49 -0700 >>> From: internet-drafts@ietf.org >>> To: Laurent Ciavaglia , Jeferson >> Campos Nobre , Michael >>> Behringer , Sheng Jiang >> , >>> Zongpeng Du , Michael H. Behringer >>> , Laurent Ciavaglia >>> >>> >>> >>> >>> A new version of I-D, draft-du-anima-an-intent-04.txt has been >>> successfully submitted by Laurent Ciavaglia and posted to the IETF >>> repository. >>> >>> Name: draft-du-anima-an-intent >>> Revision: 04 >>> Title: ANIMA Intent Policy and Format >>> Document date: 2016-07-08 >>> Group: Individual Submission >>> Pages: 13 >>> URL: https://www.ietf.org/internet-drafts/draft-du-anima-an-intent- >> 04.txt >>> Status: https://datatracker.ietf.org/doc/draft-du-anima-an-intent/ >>> Htmlized: https://tools.ietf.org/html/draft-du-anima-an-intent-04 >>> Diff: https://www.ietf.org/rfcdiff?url2=draft-du-anima-an-intent-04 >>> >>> Abstract: >>> One of the goals of autonomic networking is to simplify the >>> management of networks by human operators. Intent Based Networking >>> (IBN) is a possible approach to realize this goal. With IBN, the >>> operator indicates to the network what to do (i.e. her intent) and >>> not how to do it. In the field of Policy Based Management (PBM), the >>> concept of intent is called a declarative policy. This document >>> proposes a refinement of the intent concept initially defined in >>> [RFC7575] for autonomic networks by providing a more complete >>> definition, a life-cycle, some use cases and a tentative format of >>> the ANIMA Intent Policy. >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima >>> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > From nobody Mon Jul 11 05:37:45 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06C4712D7B3 for ; Mon, 11 Jul 2016 05:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 9tOiu0rf1HJH for ; Mon, 11 Jul 2016 05:37:42 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 7A1A512D759 for ; Mon, 11 Jul 2016 05:37:42 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 06CA3B4EF6E9E; Mon, 11 Jul 2016 12:37:38 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u6BCbdwR011078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Jul 2016 12:37:40 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u6BCbdnb032643 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Jul 2016 14:37:39 +0200 Received: from [172.27.205.129] (135.239.27.40) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 11 Jul 2016 14:37:38 +0200 To: Brian E Carpenter , "Michael Behringer (mbehring)" , anima References: <20160708153949.32209.45567.idtracker@ietfa.amsl.com> <1fe314ad-d22f-1291-7e85-4e51ccd328a2@gmail.com> <54f47cc8-bd8b-3783-274a-86e98d9e49ea@gmail.com> From: Laurent Ciavaglia Organization: Nokia Bell Labs Message-ID: <4ce143d1-d623-702e-5926-1fbc174020ad@nokia-bell-labs.com> Date: Mon, 11 Jul 2016 14:37:37 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <54f47cc8-bd8b-3783-274a-86e98d9e49ea@gmail.com> Content-Type: multipart/alternative; boundary="------------4216BF61F0C0796AF02F90C3" X-Originating-IP: [135.239.27.40] Archived-At: Subject: Re: [Anima] Fwd: New Version Notification for draft-du-anima-an-intent-04.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 12:37:44 -0000 --------------4216BF61F0C0796AF02F90C3 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Hello, > Yes. There's been an assumption, I think, that one "autonomic function" == one ASA. > We need to be clear if that is an axiom, and we need to think about how ASAs are > named, and if those names need to be registered somehow. Mmmh... where does this assumption come from...? I think we've been quite clear the general case is one AF == multiple ASAs. An AF instantiated by (only) one ASA is a sub-case. Cf. figure 1 of the Reference model draft. Why would ASAs need a name? That ASA need an ID is ok, but machines don't care about having stuff referenced with names... and I don't think human operators will have to deal with ASAs (one of the goals of ANetworking), or at least not often enough to justify the use of a naming scheme. AFs could have names (and would actually need more than just name, e.g. version number, description of what it does, requires, etc.). Or am I completely overlooking something? Best regards, Laurent. --------------4216BF61F0C0796AF02F90C3 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Hello,

 
Yes. There's been an assumption, I think, that one "autonomic function" == one ASA.
We need to be clear if that is an axiom, and we need to think about how ASAs are
named, and if those names need to be registered somehow.

Mmmh... where does this assumption come from...?
I think we've been quite clear the general case is one AF == multiple ASAs. An AF instantiated by (only) one ASA is a sub-case. Cf. figure 1 of the Reference model draft.

Why would ASAs need a name? That ASA need an ID is ok, but machines don't care about having stuff referenced with names... and I don't think human operators will have to deal with ASAs (one of the goals of ANetworking), or at least not often enough to justify the use of a naming scheme.
AFs could have names (and would actually need more than just name, e.g. version number, description of what it does, requires, etc.).

Or am I completely overlooking something?

Best regards, Laurent.
--------------4216BF61F0C0796AF02F90C3-- From nobody Mon Jul 11 05:39:30 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B87C512DAD4 for ; Mon, 11 Jul 2016 05:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 jX5nSMwpuh20 for ; Mon, 11 Jul 2016 05:39:26 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71DBD12DAD3 for ; Mon, 11 Jul 2016 05:39:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10818; q=dns/txt; s=iport; t=1468240766; x=1469450366; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=atVScdRpF9uEh5gj4/RMyn7XAKXzXKM3r3dikhcHsTo=; b=itrqIY2R8PLoUDf9tf/a+dfCNiUxa21tS8nDw3hNnm8OV3ZE1Jm66gBw NQM0kXJ1xMJr7ElSOttHVWOu17Ga3d/yu/BhSUK/QsSFWv9LiOzArN37N kxxTmnaTmi04eWn9NYmCzA2cZWnPYtk8hQl1UrdJc/ykrakzatYrmqpJ7 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CTAgBdkoNX/4wNJK1cgz5WfAasfYwWg?= =?us-ascii?q?XoihXYCHIEMOBQBAQEBAQEBZSeEXAEBBAEBASEROgkHBwQCAQgRAwEBAQECAiM?= =?us-ascii?q?DAgICHwYLFAEICAIEAQkJCBGHfQMPCA6wRYo6DYQUAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBHIEBhSaDSoEDgkOBYQEBIhAhAoJHgloFjgaFL4UvNAGGDIYvgg+BcU6?= =?us-ascii?q?ECohqhlqBQYdzAR42ggkcgUxuAYd6BwgXH38BAQE?= X-IronPort-AV: E=Sophos;i="5.28,346,1464652800"; d="scan'208";a="295660250" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Jul 2016 12:39:25 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u6BCdPbL016211 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Jul 2016 12:39:25 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 11 Jul 2016 07:39:24 -0500 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1210.000; Mon, 11 Jul 2016 07:39:24 -0500 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , Laurent Ciavaglia , anima Thread-Topic: [Anima] Fwd: New Version Notification for draft-du-anima-an-intent-04.txt Thread-Index: AQHR2c4OMfwFdfpHP0SglLpeB3vZZKAS1JlQgACneAD//7F40A== Date: Mon, 11 Jul 2016 12:39:24 +0000 Message-ID: <374d2ce8aec64c8aa7b9124a7e1a2646@XCH-RCD-006.cisco.com> References: <20160708153949.32209.45567.idtracker@ietfa.amsl.com> <1fe314ad-d22f-1291-7e85-4e51ccd328a2@gmail.com> <54f47cc8-bd8b-3783-274a-86e98d9e49ea@gmail.com> In-Reply-To: <54f47cc8-bd8b-3783-274a-86e98d9e49ea@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.238.135] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Fwd: New Version Notification for draft-du-anima-an-intent-04.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 12:39:29 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBb bWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbV0NCj4gU2VudDogMTEgSnVseSAyMDE2 IDE0OjE2DQo+IFRvOiBNaWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpIDxtYmVocmluZ0BjaXNj by5jb20+OyBMYXVyZW50IENpYXZhZ2xpYQ0KPiA8TGF1cmVudC5DaWF2YWdsaWFAbm9raWEtYmVs bC1sYWJzLmNvbT47IGFuaW1hIDxhbmltYUBpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFtBbmlt YV0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWR1LWFuaW1hLWFuLQ0K PiBpbnRlbnQtMDQudHh0DQo+IA0KPiBPbiAxMS8wNy8yMDE2IDE5OjIyLCBNaWNoYWVsIEJlaHJp bmdlciAobWJlaHJpbmcpIHdyb3RlOg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiA+PiBGcm9tOiBBbmltYSBbbWFpbHRvOmFuaW1hLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBCcmlhbiBFDQo+ID4+IENhcnBlbnRlcg0KPiA+PiBTZW50OiAwOSBKdWx5IDIwMTYgMTI6 MzkNCj4gPj4gVG86IExhdXJlbnQgQ2lhdmFnbGlhIDxMYXVyZW50LkNpYXZhZ2xpYUBub2tpYS1i ZWxsLWxhYnMuY29tPjsgYW5pbWENCj4gPj4gPGFuaW1hQGlldGYub3JnPg0KPiA+PiBTdWJqZWN0 OiBSZTogW0FuaW1hXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gPj4gZHJh ZnQtZHUtYW5pbWEtYW4tIGludGVudC0wNC50eHQNCj4gPj4NCj4gPj4gSGksDQo+ID4+DQo+ID4+ IFRoYW5rcyBmb3IgdGhpcy4gT25lIHBvaW50IHJhaXNlcyBzb21lIHF1ZXN0aW9ucyBpbiBteSBt aW5kOg0KPiA+Pg0KPiA+Pj4gNS4gICBJbnRlbnQgc3BsaXR0aW5nIChvbiBlYWNoIG5vZGUpOiBJ bnRlbnQgaXMgc3BsaXQgaW50byBzZWN0aW9ucywNCj4gPj4+IG9uZSBmb3IgdGhlIEFOSSBpdHNl bGYsIG90aGVycyBmb3Igc3BlY2lmaWMgQXV0b25vbWljIEZ1bmN0aW9ucy4NCj4gPj4+IEFTQXMg YXJlIG5vdGlmaWVkIGlmIHRoZXJlIGlzIG5ldyBJbnRlbnQgZm9yIHRoZW0uICBTb21lIGludGVu dA0KPiA+Pj4gc2VjdGlvbnMgbWF5IG5vdCBhcHBseSB0byBhIHBhcnRpY3VsYXIgbm9kZS4gIE5v dyBlYWNoIGNvbXBvbmVudCBvZg0KPiA+Pj4gYSBub2RlIChBTkksIGFsbCBBU0FzKSBrbm93IHRo ZWlyIHJlc3BlY3RpdmUgSW50ZW50Lg0KPiA+Pg0KPiA+PiBJIGFtIHdvbmRlcmluZyB3aHksIGlu IHRoaXMgY2FzZSwgSW50ZW50IHdvdWxkIGJlIGJyb2FkY2FzdGVkIGluIGENCj4gPj4gc2luZ2xl IG9wZXJhdGlvbiBhcyBhIHNpbmdsZSBmaWxlLiBXaHkgd291bGRuJ3Qgd2Ugc2ltcGx5IHNlbmQg b3V0DQo+ID4+IGVhY2ggc2VjdGlvbiBzZXBhcmF0ZWx5Pw0KPiA+DQo+ID4gU2ltcGxpY2l0eS4g V2UndmUgZGlzY3Vzc2VkIG1hbnkgd2F5cyBvZiBtYWtpbmcgSW50ZW50IGRpc3RyaWJ1dGlvbiBt b3JlDQo+IGdyYW51bGFyLCBvcHRpbWlzZWQsIGV0Yy4gTXkgYXJndW1lbnQgd2FzIGFuZCBpczog TGV0J3Mgc3RhcnQgc2ltcGxlLCBhbmQgc2VlDQo+IHdoZXRoZXIgd2UgYWN0dWFsbHkgbmVlZCB0 byBtYWtlIGl0IG1vcmUgZ3JhbnVsYXIsIG9wdGltaXNlZCwgZXRjLiBJZiBJbnRlbnQNCj4gaXMg cmVhbGx5IGEgaGlnaCBsZXZlbCBwb2xpY3ksIGl0IHdpbGwgY2hhbmdlIHZlcnkgaW5mcmVxdWVu dGx5LCBzbyBJIHRoaW5rDQo+IG9wdGltaXNhdGlvbnMgYXJlIG5vdCByZXF1aXJlZC4gSGF2aW5n IHNhaWQgdGhpcywgd2Ugc2hvdWxkIGhhdmUgYSAicGxhbiBiIiBpbg0KPiBjYXNlIHdlIGZpbmQg bGF0ZXIgdGhhdCB0aGUgc2ltcGxlIG1ldGhvZCBpc24ndCBnb29kIGVub3VnaC4NCj4gDQo+IEkn bSBhbGwgZm9yIHNpbXBsaWNpdHkuIEhvd2V2ZXIsIGl0IG1pZ2h0IGJlIHRoYXQgc2VuZGluZyB0 aGUgc2VjdGlvbnMNCj4gc2VwYXJhdGVseSB3b3VsZCBhY3R1YWxseSBiZSBzaW1wbGVyLiBJIHRo aW5rIHdlIGRvbid0IGtub3cgeWV0Lg0KDQpJIGRvdWJ0IHRoYXQsIGJ1dCBsZXQncyBsZWF2ZSBv dXIgbWluZCBvcGVuISA6LSkgDQogDQo+ID4+IEFsc28sIGhvdyBpcyB0aGUgcmVsZXZhbmNlIGZv ciBlYWNoIEFTQSBrbm93bj8NCj4gPg0KPiA+IE15IHByb3Bvc2FsOiBJbnRlbnQgY29tZXMgaW4g c2VjdGlvbnM7IHRob3NlIHNlY3Rpb25zIGFyZSBsYWJlbGxlZCB3aXRoIHRoZQ0KPiBuYW1lIG9m IHRoZSBBU0EgLyBhdXRvbm9taWMgZnVuY3Rpb24gdGhleSBiZWxvbmcgdG8uIEFsc28gaGVyZSwg dGhlcmUgYXJlDQo+IG1hbnkgd2F5cyB0byBkbyB0aGlzLCBpdCdzIGEgc2ltcGxlIHByb3Bvc2Fs IHdoaWNoIGNvdWxkIGJlIG9wdGltaXNlZCBpbiBtYW55DQo+IHdheXMuDQo+ID4NCj4gPj4gQW5k IGlzIHRoYXQgdGhlIGNvcnJlY3QNCj4gPj4gZ3JhbnVsYXJpdHkgb2YgdGhlIHNlY3Rpb24/IE1h eWJlIHRoZSBncmFudWxhcml0eSBzaG91bGQgYmUNCj4gPj4gaW5kaXZpZHVhbCBvYmplY3RpdmVz LCBvciBjZXJ0YWluIGdyb3VwcyBvZiBvYmplY3RpdmVzPyBJIHRoaW5rIHRoaXMNCj4gPj4gbmVl ZHMgbW9yZSBkaXNjdXNzaW9uLg0KPiA+DQo+ID4gT24gdGhpcyBvbmUgSSBhZ3JlZSEhIFdlIHNo b3VsZCBoYXZlIG1vcmUgZGlzY3Vzc2lvbnMgb24gdGhhdC4gWW91ciBwb2ludA0KPiBmcm9tIHRo ZSBvdGhlciBtYWlsLCB0aGF0IHdlIHNob3VsZCB0cnkgaW1wbGVtZW50aW5nIHNvbWUgQVNBcyB3 b3VsZCBoZWxwDQo+IHVuZGVyc3RhbmQgdGhpcyBiZXR0ZXIuDQo+IA0KPiBZZXMuIFRoZXJlJ3Mg YmVlbiBhbiBhc3N1bXB0aW9uLCBJIHRoaW5rLCB0aGF0IG9uZSAiYXV0b25vbWljIGZ1bmN0aW9u IiA9PQ0KPiBvbmUgQVNBLg0KPiBXZSBuZWVkIHRvIGJlIGNsZWFyIGlmIHRoYXQgaXMgYW4gYXhp b20sIGFuZCB3ZSBuZWVkIHRvIHRoaW5rIGFib3V0IGhvdw0KPiBBU0FzIGFyZSBuYW1lZCwgYW5k IGlmIHRob3NlIG5hbWVzIG5lZWQgdG8gYmUgcmVnaXN0ZXJlZCBzb21laG93Lg0KDQpZZXMsIHRo YXQgbWlzdW5kZXJzdGFuZGluZyBrZWVwcyBwb3BwaW5nIHVwIGFsbCB0aGUgdGltZS4gIEkgdGhp bmsgUkZDNzU3NSBpcyBxdWl0ZSBjbGVhcjogDQoNCiAgIEF1dG9ub21pYyBGdW5jdGlvbjogQSBm ZWF0dXJlIG9yIGZ1bmN0aW9uIHRoYXQgcmVxdWlyZXMgbm8NCiAgIGNvbmZpZ3VyYXRpb24gYW5k IGNhbiBkZXJpdmUgYWxsIHJlcXVpcmVkIGluZm9ybWF0aW9uIHRocm91Z2ggc2VsZi0NCiAgIGtu b3dsZWRnZSwgZGlzY292ZXJ5LCBvciBJbnRlbnQuDQoNCiAgIEF1dG9ub21pYyBTZXJ2aWNlIEFn ZW50OiBBbiBhZ2VudCBpbXBsZW1lbnRlZCBvbiBhbiBhdXRvbm9taWMgbm9kZQ0KICAgdGhhdCBp bXBsZW1lbnRzIGFuIGF1dG9ub21pYyBmdW5jdGlvbiwgZWl0aGVyIGluIHBhcnQgKGluIHRoZSBj YXNlIG9mDQogICBhIGRpc3RyaWJ1dGVkIGZ1bmN0aW9uKSBvciB3aG9sZS4NCg0KRXhhbXBsZTog VGhlcmUgaXMgdGhlICJhdXRvbm9taWMgZnVuY3Rpb24iICJib290c3RyYXBwaW5nIG9mIG5ldyBu b2RlcyIuIEl0IGNvbnNpc3RzIG9mIDMgZGlmZmVyZW50IEFTQXM6IFRoZSBuZXdfZGV2aWNlIEFT QSwgdGhlIHByb3h5IEFTQSBhbmQgdGhlIHJlZ2lzdHJhciBBU0EuIA0KDQpIb3cgY2FuIHdlIG1h a2UgdGhhdCBjbGVhcmVyPyAoSSB0aG91Z2h0IFJGQzc1NzUgKmlzKiBjbGVhcikuDQoNCj4gPiBC dXQ6IEkgc3VnZ2VzdCB3ZSBtYWtlIHRoaW5ncyBtb3JlIGNvbXBsaWNhdGVkIG9ubHkgaWYgd2Ug cmVhbGx5IGNhbiBzZWUNCj4gd2h5IHRoZSBwcm9wb3NlZCBhcHByb2FjaCB3b3VsZG4ndCB3b3Jr Lg0KPiANCj4gQWdyZWVkLiBBcyBmYXIgYXMgSSBjYW4gc2VlLCBpZiB3ZSBuYWl2ZWx5IGFzc3Vt ZSB0aGF0IHdlIHVzZSBHUkFTUCB0bw0KPiBkaXN0cmlidXRlIEludGVudCwgd2UgY2FuIGZsb29k IEludGVudCBhcyBsb25nIGFzIGl0IGZpdHMgaW4gb25lIHBhY2tldDsgaWYgdGhhdA0KPiBkb2Vz bid0IGFwcGx5LCB3ZSBjYW4gc3luY2hyb25pemUgaXQgdmlhIEdSQVNQL1RDUC4gVGhhdCBzZWVt cyBPSyBmb3Igbm93Lg0KPiBTaW5jZSBJbnRlbnQgaXMgc3VwcG9zZWQgdG8gY2hhbmdlIHJhcmVs eSwgd2UgZG9uJ3QgbmVlZCB0byBvcHRpbWlzZQ0KPiBwZXJmb3JtYW5jZS4NCg0KWWVzLCB3ZSBu ZWVkIHRvIHNldHRsZSBvbiB0aGF0LiBBcyBtZW50aW9uZWQsIEkgc3VnZ2VzdCB3ZSBrZWVwIHRo ZSBzaWduYWxsaW5nICJ0aGVyZSBpcyBJbnRlbnQgdmVyc2lvbiB4IiBhbmQgdGhlIGFjdHVhbCB0 cmFuc2ZlciBzdHJpY3RseSBzZXBhcmF0ZS4gVGhhdCdzIHJlYWxseSBhbiBvcnRob2dvbmFsIG9i c2VydmF0aW9uIHRvIHlvdXJzLCBidXQgSSdkIHJlYWxseSBob3BlIHdlIGNhbiBzZXR0bGUgb24g dGhhdC4gDQoNCk1pY2hhZWwNCg0KIA0KPiBSZWdhcmRzDQo+ICAgICBCcmlhbg0KPiANCj4gPg0K PiA+IE1pY2hhZWwNCj4gPg0KPiA+DQo+ID4+DQo+ID4+IFJlZ2FyZHMNCj4gPj4gICAgQnJpYW4N Cj4gPj4NCj4gPj4gT24gMDkvMDcvMjAxNiAwMzo0NSwgTGF1cmVudCBDaWF2YWdsaWEgd3JvdGU6 DQo+ID4+PiBEZWFyIEFOSU1BIFdHLA0KPiA+Pj4NCj4gPj4+IEZZSTogYSBuZXcgdmVyc2lvbiBv ZiB0aGUgSS1EIGhhcyBiZWVuIHBvc3RlZC4NCj4gPj4+DQo+ID4+PiBUaGUgbWFpbiB1cGRhdGUg aXMgdGhlIGFkZGl0aW9uIG9mIGEgc2VjdGlvbiBvbiBJbnRlbnQgTGlmZSBDeWNsZQ0KPiA+Pj4g YmFzZWQgb24gdGhlIGluaXRpYWwgdGV4dCBwcm92aWRlZCBieSBNaWNoYWVsIEJlaHJpbmdlcg0K PiA+PiAoaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9hbmltYS9yazJDZ082 Mm5tWEZ1S09CWC0NCj4gPj4gR3RiNXYwcDVFKS4NCj4gPj4+IE1pY2hhZWwgaXMgbm93IGFsc28g Y28tYXV0aG9yIG9mIHRoZSBJLUQuDQo+ID4+Pg0KPiA+Pj4gKldlJ3ZlIGFza2VkIHRoZSBBTklN QSBXRyBjaGFpcnMgZm9yIGEgc2xvdCBhdCBJRVRGOTYvQmVybGluIHRvDQo+ID4+PiBwcmVzZW50 IHRoZSB1cGRhdGVzIG9uIHRoaXMgZHJhZnQgYW5kIHJlcG9ydCBvbiB0aGUgZGlzY3Vzc2lvbiBv bg0KPiA+Pj4gSW50ZW50IGFuZCB3YXkgZm9yd2FyZC4qKiAqKllvdXIgY29tbWVudHMgYXJlIHRo dXMgaGlnaGx5IHdlbGNvbWUNCj4gPj4+IGJlZm9yZSB0aGUgbWVldCoqaW5nKiouKg0KPiA+Pj4N Cj4gPj4+IEJlc3QgcmVnYXJkcywgTGF1cmVudC4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gLS0tLS0t LS0gRm9yd2FyZGVkIE1lc3NhZ2UgLS0tLS0tLS0NCj4gPj4+IFN1YmplY3Q6ICAgICBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWR1LWFuaW1hLWFuLWludGVudC0wNC50eHQNCj4g Pj4+IERhdGU6ICAgICBGcmksIDggSnVsIDIwMTYgMDg6Mzk6NDkgLTA3MDANCj4gPj4+IEZyb206 ICAgICBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCj4gPj4+IFRvOiAgICAgTGF1cmVudCBDaWF2 YWdsaWEgPGxhdXJlbnQuY2lhdmFnbGlhQGFsY2F0ZWwtbHVjZW50LmNvbT4sIEplZmVyc29uDQo+ ID4+IENhbXBvcyBOb2JyZSA8amNub2JyZUBpbmYudWZyZ3MuYnI+LCBNaWNoYWVsDQo+ID4+PiBC ZWhyaW5nZXIgPG1iZWhyaW5nQGNpc2NvLmNvbT4sIFNoZW5nIEppYW5nDQo+ID4+IDxqaWFuZ3No ZW5nQGh1YXdlaS5jb20+LA0KPiA+Pj4gWm9uZ3BlbmcgRHUgPGR1em9uZ3BlbmdAaHVhd2VpLmNv bT4sIE1pY2hhZWwgSC4gQmVocmluZ2VyDQo+ID4+PiA8bWJlaHJpbmdAY2lzY28uY29tPiwgTGF1 cmVudCBDaWF2YWdsaWENCj4gPj4+IDxMYXVyZW50LkNpYXZhZ2xpYUBhbGNhdGVsLWx1Y2VudC5j b20+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJh ZnQtZHUtYW5pbWEtYW4taW50ZW50LTA0LnR4dCBoYXMgYmVlbg0KPiA+Pj4gc3VjY2Vzc2Z1bGx5 IHN1Ym1pdHRlZCBieSBMYXVyZW50IENpYXZhZ2xpYSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGDQo+ ID4+PiByZXBvc2l0b3J5Lg0KPiA+Pj4NCj4gPj4+IE5hbWU6ICAgICAgICBkcmFmdC1kdS1hbmlt YS1hbi1pbnRlbnQNCj4gPj4+IFJldmlzaW9uOiAgICAwNA0KPiA+Pj4gVGl0bGU6ICAgICAgICBB TklNQSBJbnRlbnQgUG9saWN5IGFuZCBGb3JtYXQNCj4gPj4+IERvY3VtZW50IGRhdGU6ICAgIDIw MTYtMDctMDgNCj4gPj4+IEdyb3VwOiAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+ID4+ PiBQYWdlczogICAgICAgIDEzDQo+ID4+PiBVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWR1LWFuaW1hLWFuLQ0KPiBpbnRlbnQtDQo+ID4+ IDA0LnR4dA0KPiA+Pj4gU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWR1LWFuaW1hLWFuLWludGVudC8NCj4gPj4+IEh0bWxpemVkOiAgICAgICBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZHUtYW5pbWEtYW4taW50ZW50LTA0DQo+ ID4+PiBEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy YWZ0LWR1LWFuaW1hLWFuLWludGVudC0NCj4gMDQNCj4gPj4+DQo+ID4+PiBBYnN0cmFjdDoNCj4g Pj4+ICAgIE9uZSBvZiB0aGUgZ29hbHMgb2YgYXV0b25vbWljIG5ldHdvcmtpbmcgaXMgdG8gc2lt cGxpZnkgdGhlDQo+ID4+PiAgICBtYW5hZ2VtZW50IG9mIG5ldHdvcmtzIGJ5IGh1bWFuIG9wZXJh dG9ycy4gIEludGVudCBCYXNlZA0KPiBOZXR3b3JraW5nDQo+ID4+PiAgICAoSUJOKSBpcyBhIHBv c3NpYmxlIGFwcHJvYWNoIHRvIHJlYWxpemUgdGhpcyBnb2FsLiAgV2l0aCBJQk4sIHRoZQ0KPiA+ Pj4gICAgb3BlcmF0b3IgaW5kaWNhdGVzIHRvIHRoZSBuZXR3b3JrIHdoYXQgdG8gZG8gKGkuZS4g aGVyIGludGVudCkgYW5kDQo+ID4+PiAgICBub3QgaG93IHRvIGRvIGl0LiAgSW4gdGhlIGZpZWxk IG9mIFBvbGljeSBCYXNlZCBNYW5hZ2VtZW50IChQQk0pLCB0aGUNCj4gPj4+ICAgIGNvbmNlcHQg b2YgaW50ZW50IGlzIGNhbGxlZCBhIGRlY2xhcmF0aXZlIHBvbGljeS4gIFRoaXMgZG9jdW1lbnQN Cj4gPj4+ICAgIHByb3Bvc2VzIGEgcmVmaW5lbWVudCBvZiB0aGUgaW50ZW50IGNvbmNlcHQgaW5p dGlhbGx5IGRlZmluZWQgaW4NCj4gPj4+ICAgIFtSRkM3NTc1XSBmb3IgYXV0b25vbWljIG5ldHdv cmtzIGJ5IHByb3ZpZGluZyBhIG1vcmUgY29tcGxldGUNCj4gPj4+ICAgIGRlZmluaXRpb24sIGEg bGlmZS1jeWNsZSwgc29tZSB1c2UgY2FzZXMgYW5kIGEgdGVudGF0aXZlIGZvcm1hdCBvZg0KPiA+ Pj4gICAgdGhlIEFOSU1BIEludGVudCBQb2xpY3kuDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+ PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0 aGUgdGltZSBvZg0KPiA+Pj4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBh bmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0DQo+IHRvb2xzLmlldGYub3JnLg0KPiA+Pj4NCj4gPj4+ IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4N Cj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4+PiBBbmltYSBtYWlsaW5nIGxpc3QNCj4gPj4+IEFuaW1hQGlldGYub3JnDQo+ID4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hDQo+ID4+Pg0KPiA+Pg0KPiA+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBB bmltYSBtYWlsaW5nIGxpc3QNCj4gPj4gQW5pbWFAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYQ0KPiA+DQo= From nobody Mon Jul 11 05:54:01 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA35A12D187 for ; Mon, 11 Jul 2016 05:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 xZnr5KQz2xNQ for ; Mon, 11 Jul 2016 05:53:56 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 34DC612D182 for ; Mon, 11 Jul 2016 05:53:50 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 3C92EF609D7F8; Mon, 11 Jul 2016 12:53:46 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u6BCrm7A021976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Jul 2016 12:53:48 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u6BCrmes023165 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Jul 2016 14:53:48 +0200 Received: from [172.27.205.129] (135.239.27.38) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 11 Jul 2016 14:53:48 +0200 To: "Michael Behringer (mbehring)" , Brian E Carpenter , anima References: <20160708153949.32209.45567.idtracker@ietfa.amsl.com> <1fe314ad-d22f-1291-7e85-4e51ccd328a2@gmail.com> <54f47cc8-bd8b-3783-274a-86e98d9e49ea@gmail.com> <374d2ce8aec64c8aa7b9124a7e1a2646@XCH-RCD-006.cisco.com> From: Laurent Ciavaglia Organization: Nokia Bell Labs Message-ID: <69f424f0-e76a-f33b-92d1-beb259e4b25b@nokia-bell-labs.com> Date: Mon, 11 Jul 2016 14:53:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <374d2ce8aec64c8aa7b9124a7e1a2646@XCH-RCD-006.cisco.com> Content-Type: multipart/alternative; boundary="------------9F65401FB3972EB2348A8E55" X-Originating-IP: [135.239.27.38] Archived-At: Subject: Re: [Anima] Fwd: New Version Notification for draft-du-anima-an-intent-04.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 12:53:59 -0000 --------------9F65401FB3972EB2348A8E55 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit On 11/07/2016 14:39, Michael Behringer (mbehring) wrote: >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: 11 July 2016 14:16 >> To: Michael Behringer (mbehring) ; Laurent Ciavaglia >> ; anima >> Subject: Re: [Anima] Fwd: New Version Notification for draft-du-anima-an- >> intent-04.txt >> >> On 11/07/2016 19:22, Michael Behringer (mbehring) wrote: >>>> -----Original Message----- >>>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E >>>> Carpenter >>>> Sent: 09 July 2016 12:39 >>>> To: Laurent Ciavaglia ; anima >>>> >>>> Subject: Re: [Anima] Fwd: New Version Notification for >>>> draft-du-anima-an- intent-04.txt >>>> >>>> >>>> >>>> Yes. There's been an assumption, I think, that one "autonomic function" == >>>> one ASA. >>>> We need to be clear if that is an axiom, and we need to think about how >>>> ASAs are named, and if those names need to be registered somehow. > Yes, that misunderstanding keeps popping up all the time. I think RFC7575 is quite clear: > > Autonomic Function: A feature or function that requires no > configuration and can derive all required information through self- > knowledge, discovery, or Intent. > > Autonomic Service Agent: An agent implemented on an autonomic node > that implements an autonomic function, either in part (in the case of > a distributed function) or whole. > > Example: There is the "autonomic function" "bootstrapping of new nodes". It consists of 3 different ASAs: The new_device ASA, the proxy ASA and the registrar ASA. Michael: in your example, the agents represent different parts of the AF functionality. There is an additional dimension: an AF can be deployed over multiple resources(/devices). An ASA, encompassing the whole AF functionality, would then be instantiated on each device. E.g. a load-balancing AF deployed over a set of routers (each router will get an ASA of the load balancing AF). > > How can we make that clearer? (I thought RFC7575 *is* clear). I think that progressing on the life-cycle management will describe how the different elements (AF, ASA, management functions) interacts and when/why/how they are instantiated. This will be presented (again) with more details in IETF96/Berlin. The other discussion thread on the "code" thing is also useful to get a better understanding IMO. finally, the text on ASA in the reference model (or larger side document) could be used to augment / improve the text of RFC7575. Best regards, Laurent. --------------9F65401FB3972EB2348A8E55 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit

On 11/07/2016 14:39, Michael Behringer (mbehring) wrote:
-----Original Message-----
From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
Sent: 11 July 2016 14:16
To: Michael Behringer (mbehring) <mbehring@cisco.com>; Laurent Ciavaglia
<Laurent.Ciavaglia@nokia-bell-labs.com>; anima <anima@ietf.org>
Subject: Re: [Anima] Fwd: New Version Notification for draft-du-anima-an-
intent-04.txt

On 11/07/2016 19:22, Michael Behringer (mbehring) wrote:

-----Original Message-----
From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E
Carpenter
Sent: 09 July 2016 12:39
To: Laurent Ciavaglia <Laurent.Ciavaglia@nokia-bell-labs.com>; anima
<anima@ietf.org>
Subject: Re: [Anima] Fwd: New Version Notification for
draft-du-anima-an- intent-04.txt



Yes. There's been an assumption, I think, that one "autonomic function" ==
one ASA.
We need to be clear if that is an axiom, and we need to think about how
ASAs are named, and if those names need to be registered somehow.

Yes, that misunderstanding keeps popping up all the time.  I think RFC7575 is quite clear: 

   Autonomic Function: A feature or function that requires no
   configuration and can derive all required information through self-
   knowledge, discovery, or Intent.

   Autonomic Service Agent: An agent implemented on an autonomic node
   that implements an autonomic function, either in part (in the case of
   a distributed function) or whole.

Example: There is the "autonomic function" "bootstrapping of new nodes". It consists of 3 different ASAs: The new_device ASA, the proxy ASA and the registrar ASA.
Michael: in your example, the agents represent different parts of the AF functionality.
There is an additional dimension: an AF can be deployed over multiple resources(/devices). An ASA, encompassing the whole AF functionality, would then be instantiated on each device. E.g. a load-balancing AF deployed over a set of routers (each router will get an ASA of the load balancing AF).


How can we make that clearer? (I thought RFC7575 *is* clear).
I think that progressing on the life-cycle management will describe how the different elements (AF, ASA, management functions) interacts and when/why/how they are instantiated. This will be presented (again) with more details in IETF96/Berlin.
The other discussion thread on the "code" thing is also useful to get a better understanding IMO.
finally, the text on ASA in the reference model (or larger side document) could be used to augment / improve the text of RFC7575.

Best regards, Laurent.
--------------9F65401FB3972EB2348A8E55-- From nobody Mon Jul 11 05:55:34 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F24812B03F for ; Mon, 11 Jul 2016 05:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 Ya092z4mDEC2 for ; Mon, 11 Jul 2016 05:55:32 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 97BA812B018 for ; Mon, 11 Jul 2016 05:55:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 77E1B1C0663; Mon, 11 Jul 2016 05:55:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1468241730; bh=PneDglELdb6Cu7oejZje1mqR+zPp1rg4ZWZ6GEy7yKs=; h=Subject:To:References:From:Date:In-Reply-To:From; b=k1QVNXaJXHi6q/gfBQHKEg+8gKgxDPhT1qQtYnR2g+8DKy/oi4YnUL2/6o5MW0F7H IWkJzigs19XlGoQ48R0RE6A3XKA8H9HlmesE07IWX7q3OU84+LGLqvNoaO0LK3+kX3 +wcaaiuZkwwNVANiJmZdUMIVqP0nHyf4RdwNzDaE= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id DE14B1C029E; Mon, 11 Jul 2016 05:55:29 -0700 (PDT) To: "Michael Behringer (mbehring)" , Brian E Carpenter , Laurent Ciavaglia , anima References: <20160708153949.32209.45567.idtracker@ietfa.amsl.com> <1fe314ad-d22f-1291-7e85-4e51ccd328a2@gmail.com> <54f47cc8-bd8b-3783-274a-86e98d9e49ea@gmail.com> <374d2ce8aec64c8aa7b9124a7e1a2646@XCH-RCD-006.cisco.com> From: "Joel M. Halpern" Message-ID: <9dbf5192-39ce-826c-b5aa-e88557051415@joelhalpern.com> Date: Mon, 11 Jul 2016 08:55:28 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <374d2ce8aec64c8aa7b9124a7e1a2646@XCH-RCD-006.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Fwd: New Version Notification for draft-du-anima-an-intent-04.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 12:55:33 -0000 I believe your description, and that of others as to what we "intend", does not line up with the definition you quote. The text says that an ASA "implements an autonomic function." That seems to say that I sould expect an autonomic function to be implemented by an ASA, thus implying a 1-1 relationship. yet, your example states an AF of "bootstrapping", but the funcitonality of the ASA being a much smaller piece. Net: No, the words do not clearly state what we intend. Yours, Joel On 7/11/16 8:39 AM, Michael Behringer (mbehring) wrote: ... >>>> Also, how is the relevance for each ASA known? >>> >>> My proposal: Intent comes in sections; those sections are >>> labelled with the >> name of the ASA / autonomic function they belong to. Also here, >> there are many ways to do this, it's a simple proposal which could >> be optimised in many ways. >>> >>>> And is that the correct granularity of the section? Maybe the >>>> granularity should be individual objectives, or certain groups >>>> of objectives? I think this needs more discussion. >>> >>> On this one I agree!! We should have more discussions on that. >>> Your point >> from the other mail, that we should try implementing some ASAs >> would help understand this better. >> >> Yes. There's been an assumption, I think, that one "autonomic >> function" == one ASA. We need to be clear if that is an axiom, and >> we need to think about how ASAs are named, and if those names need >> to be registered somehow. > > Yes, that misunderstanding keeps popping up all the time. I think > RFC7575 is quite clear: > > Autonomic Function: A feature or function that requires no > configuration and can derive all required information through self- > knowledge, discovery, or Intent. > > Autonomic Service Agent: An agent implemented on an autonomic node > that implements an autonomic function, either in part (in the case > of a distributed function) or whole. > > Example: There is the "autonomic function" "bootstrapping of new > nodes". It consists of 3 different ASAs: The new_device ASA, the > proxy ASA and the registrar ASA. > > How can we make that clearer? (I thought RFC7575 *is* clear). ... From nobody Mon Jul 11 06:10:59 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED5BF12D162 for ; Mon, 11 Jul 2016 06:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 bqa8I7-Ghozn for ; Mon, 11 Jul 2016 06:10:55 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (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 48C7112D0B9 for ; Mon, 11 Jul 2016 06:10:55 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id q132so72714910lfe.3 for ; Mon, 11 Jul 2016 06:10:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=da9Kd0e9CEmBbw2QkFDl0bWuVlSKIzTXPbbTgqvY7LY=; b=dZPBqmCnmaLwGFpPuY1rAEyEW0gJFDiOMzg5sQAFI28doq7iuTkOYXTZLdJ1ovXkyy ZnTTKtgSn8LkShYU9Md8SeRbovviR7roCcMIhZg/W7lGMyvlhSttDnbSOoUo+I7VkBke IOc5C8z5UY462lo3k94PTFlLTjfwDUXBhZBgiZ2aJjWs9HnvPUn65Ajo/LLIDLxfeOBZ bEgcoODVqi4rEQHC85Fkb0E7eEV6L9qVBoM4mVg/zFdzcvWFW0leEOqwqmOJlOrb2wdc F8IWQo3vIpgVin3DkfBwC3e9fN14DphZD3QeWSeKLiPHWKZ8gn50I1F6hcpM6khH/gr+ e3zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=da9Kd0e9CEmBbw2QkFDl0bWuVlSKIzTXPbbTgqvY7LY=; b=jXkcdzoYdaJgEWIOzBJgw3FYJtygLh2EAdYpbakzPN+OndsWpaUme2xBGWsNtu9fLI KMNrC+9a2I9DiqW2AlkxNQj5metYSczY7iGGQNI+KglXPC+GVoZp+RaVNHvX0zrRKSDd qpZWpoklET01l3d7i77nROpCrkcMVz5ZzpEUjVJUH74NrX84WjxDa9r4S9+GFtiKcg7b EG4kBBaMOQPFagzVJR0VARsrXd6Jd8lVeO1/70KTHrFhLnfNHyR3jAc/ZSIkYV+gtEXR WsVJke+B47S328IyCkOYJAwjRdnYs3DP0R8l5AKfiAY8DIjYEjL8IiuAABZaw21FDzHN XFmg== X-Gm-Message-State: ALyK8tLfDkzQNa4UsvsJBF8RZi95FQ7/rFoN9Oi1hswjduS9boA2GwlViZZ7m7TgXGG8pQ== X-Received: by 10.46.71.17 with SMTP id u17mr604847lja.49.1468242653291; Mon, 11 Jul 2016 06:10:53 -0700 (PDT) Received: from [10.0.1.29] (cpc66883-mort6-2-0-cust696.19-2.cable.virginm.net. [92.233.126.185]) by smtp.gmail.com with ESMTPSA id 67sm4139319ljb.41.2016.07.11.06.10.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Jul 2016 06:10:52 -0700 (PDT) To: Laurent Ciavaglia , "Michael Behringer (mbehring)" , anima References: <20160708153949.32209.45567.idtracker@ietfa.amsl.com> <1fe314ad-d22f-1291-7e85-4e51ccd328a2@gmail.com> <54f47cc8-bd8b-3783-274a-86e98d9e49ea@gmail.com> <4ce143d1-d623-702e-5926-1fbc174020ad@nokia-bell-labs.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <4218092c-897c-c8a6-6152-b8ee67c16b6e@gmail.com> Date: Tue, 12 Jul 2016 01:10:52 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <4ce143d1-d623-702e-5926-1fbc174020ad@nokia-bell-labs.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Fwd: New Version Notification for draft-du-anima-an-intent-04.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 13:10:58 -0000 Just blending the two response sub-threads: On 12/07/2016 00:37, Laurent Ciavaglia wrote: > Hello, > >> Yes. There's been an assumption, I think, that one "autonomic function" == one ASA. >> We need to be clear if that is an axiom, and we need to think about how ASAs are >> named, and if those names need to be registered somehow. > > Mmmh... where does this assumption come from...? > I think we've been quite clear the general case is one AF == multiple ASAs. An AF instantiated by (only) one ASA is a sub-case. > Cf. figure 1 of the Reference model draft. >> Yes, that misunderstanding keeps popping up all the time. I think RFC7575 is quite clear: >> >> Autonomic Function: A feature or function that requires no >> configuration and can derive all required information through self- >> knowledge, discovery, or Intent. >> >> Autonomic Service Agent: An agent implemented on an autonomic node >> that implements an autonomic function, either in part (in the case of >> a distributed function) or whole. >> >> Example: There is the "autonomic function" "bootstrapping of new nodes". It consists of 3 different ASAs: The new_device ASA, the proxy ASA and the registrar ASA. > Michael: in your example, the agents represent different parts of the AF functionality. > There is an additional dimension: an AF can be deployed over multiple resources(/devices). An ASA, encompassing the whole AF functionality, would then be instantiated on each device. E.g. a load-balancing AF deployed over a set of routers (each router will get an ASA of the load balancing AF). Right. So an AF can have multiple ASAs in one node, as well as multiple ASAs on different nodes. And if a section of Intent is aimed at a particular AF, then the AF needs a name. But the AF is *realised* by a set of ASAs, which must somehow be associated with the AF's name (otherwise they could not select the relevant Intent). > > Why would ASAs need a name? That ASA need an ID is ok, but machines don't care about having stuff referenced with names... and I > don't think human operators will have to deal with ASAs (one of the goals of ANetworking), or at least not often enough to > justify the use of a naming scheme Well, I used the word 'name' in a computer science sense ;-). Indeed it could be a binary number or it could be a string. I don't see any harm in making it a string, for the sake of debugging convenience (as I have in my prototype) but it isn't required. I remind you that we have so far ducked the question of authorization of ASAs to manage particular objectives. > AFs could have names (and would actually need more than just name, e.g. version number, description of what it does, requires, > etc.). > > Or am I completely overlooking something? No, I don't think so, and some of this needs to be captured for the Reference Model. Regards Brian > > Best regards, Laurent. > From nobody Mon Jul 11 07:46:04 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C65AC12D507 for ; Mon, 11 Jul 2016 07:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 4vq8aceVK4iI for ; Mon, 11 Jul 2016 07:45:59 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 7536C12D08E for ; Mon, 11 Jul 2016 07:45:59 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id C348E2E3929B; Mon, 11 Jul 2016 14:45:54 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u6BEjuIu008679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Jul 2016 14:45:56 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u6BEjtZo001352 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Jul 2016 16:45:56 +0200 Received: from [172.27.205.129] (135.239.27.39) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 11 Jul 2016 16:45:55 +0200 To: "Joel M. Halpern" , "Michael Behringer (mbehring)" , Brian E Carpenter , anima References: <20160708153949.32209.45567.idtracker@ietfa.amsl.com> <1fe314ad-d22f-1291-7e85-4e51ccd328a2@gmail.com> <54f47cc8-bd8b-3783-274a-86e98d9e49ea@gmail.com> <374d2ce8aec64c8aa7b9124a7e1a2646@XCH-RCD-006.cisco.com> <9dbf5192-39ce-826c-b5aa-e88557051415@joelhalpern.com> From: Laurent Ciavaglia Organization: Nokia Bell Labs Message-ID: <91b353d5-7672-c1ae-e173-d43e44b9ee5d@nokia-bell-labs.com> Date: Mon, 11 Jul 2016 16:45:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <9dbf5192-39ce-826c-b5aa-e88557051415@joelhalpern.com> Content-Type: multipart/alternative; boundary="------------7AE459EB7072E4DD17263084" X-Originating-IP: [135.239.27.39] Archived-At: Subject: Re: [Anima] Fwd: New Version Notification for draft-du-anima-an-intent-04.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 14:46:03 -0000 --------------7AE459EB7072E4DD17263084 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Hello, There is some text in draft-peloso-anima-autonomic-function-01 (https://tools.ietf.org/html/draft-peloso-anima-autonomic-function-01) detailing what should be considered when installing, instantiating and operating AF/ASA. Please see sections 3+. Feedback on the text is most welcome as this will be presented at IETF96/Berlin. Best regards, Laurent. On 11/07/2016 14:55, Joel M. Halpern wrote: > I believe your description, and that of others as to what we "intend", > does not line up with the definition you quote. > > The text says that an ASA "implements an autonomic function." That > seems to say that I sould expect an autonomic function to be > implemented by an ASA, thus implying a 1-1 relationship. > > yet, your example states an AF of "bootstrapping", but the > funcitonality of the ASA being a much smaller piece. > > Net: No, the words do not clearly state what we intend. > > Yours, > Joel > > On 7/11/16 8:39 AM, Michael Behringer (mbehring) wrote: > ... >>>>> Also, how is the relevance for each ASA known? >>>> >>>> My proposal: Intent comes in sections; those sections are >>>> labelled with the >>> name of the ASA / autonomic function they belong to. Also here, >>> there are many ways to do this, it's a simple proposal which could >>> be optimised in many ways. >>>> >>>>> And is that the correct granularity of the section? Maybe the >>>>> granularity should be individual objectives, or certain groups >>>>> of objectives? I think this needs more discussion. >>>> >>>> On this one I agree!! We should have more discussions on that. >>>> Your point >>> from the other mail, that we should try implementing some ASAs >>> would help understand this better. >>> >>> Yes. There's been an assumption, I think, that one "autonomic >>> function" == one ASA. We need to be clear if that is an axiom, and >>> we need to think about how ASAs are named, and if those names need >>> to be registered somehow. >> >> Yes, that misunderstanding keeps popping up all the time. I think >> RFC7575 is quite clear: >> >> Autonomic Function: A feature or function that requires no >> configuration and can derive all required information through self- >> knowledge, discovery, or Intent. >> >> Autonomic Service Agent: An agent implemented on an autonomic node >> that implements an autonomic function, either in part (in the case >> of a distributed function) or whole. >> >> Example: There is the "autonomic function" "bootstrapping of new >> nodes". It consists of 3 different ASAs: The new_device ASA, the >> proxy ASA and the registrar ASA. >> >> How can we make that clearer? (I thought RFC7575 *is* clear). > ... > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > -- Laurent Ciavaglia Nokia, Bell Labs +33 160 402 636 route de Villejust - Nozay, France linkedin.com/in/laurent.ciavaglia --------------7AE459EB7072E4DD17263084 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit Hello,

There is some text in draft-peloso-anima-autonomic-function-01 (https://tools.ietf.org/html/draft-peloso-anima-autonomic-function-01) detailing what should be considered when installing, instantiating and operating AF/ASA.
Please see sections 3+.

Feedback on the text is most welcome as this will be presented at IETF96/Berlin.

Best regards, Laurent.


On 11/07/2016 14:55, Joel M. Halpern wrote:
I believe your description, and that of others as to what we "intend", does not line up with the definition you quote.

The text says that an ASA "implements an autonomic function."  That seems to say that I sould expect an autonomic function to be implemented by an ASA, thus implying a 1-1 relationship.

yet, your example states an AF of "bootstrapping", but the funcitonality of the ASA being a much smaller piece.

Net: No, the words do not clearly state what we intend.

Yours,
Joel

On 7/11/16 8:39 AM, Michael Behringer (mbehring) wrote:
...
Also, how is the relevance for each ASA known?

My proposal: Intent comes in sections; those sections are
labelled with the
name of the ASA / autonomic function they belong to. Also here,
there are many ways to do this, it's a simple proposal which could
be optimised in many ways.

And is that the correct granularity of the section? Maybe the
granularity should be individual objectives, or certain groups
of objectives? I think this needs more discussion.

On this one I agree!! We should have more discussions on that.
Your point
from the other mail, that we should try implementing some ASAs
would help understand this better.

Yes. There's been an assumption, I think, that one "autonomic
function" == one ASA. We need to be clear if that is an axiom, and
we need to think about how ASAs are named, and if those names need
to be registered somehow.

Yes, that misunderstanding keeps popping up all the time.  I think
RFC7575 is quite clear:

Autonomic Function: A feature or function that requires no
configuration and can derive all required information through self-
knowledge, discovery, or Intent.

Autonomic Service Agent: An agent implemented on an autonomic node
that implements an autonomic function, either in part (in the case
of a distributed function) or whole.

Example: There is the "autonomic function" "bootstrapping of new
nodes". It consists of 3 different ASAs: The new_device ASA, the
proxy ASA and the registrar ASA.

How can we make that clearer? (I thought RFC7575 *is* clear).
...

_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima


--

Laurent Ciavaglia

Nokia, Bell Labs

 

+33 160 402 636

route de Villejust - Nozay, France

linkedin.com/in/laurent.ciavaglia

--------------7AE459EB7072E4DD17263084-- From nobody Mon Jul 11 07:56:03 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF4612D52B for ; Mon, 11 Jul 2016 07:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 wC0MDbjqo4jw for ; Mon, 11 Jul 2016 07:55:59 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 8FF9512D51B for ; Mon, 11 Jul 2016 07:55:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 7257C3C2E89; Mon, 11 Jul 2016 07:55:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1468248959; bh=KxQSvqXETfhLEDBjWHPq7MWaFuJn4q9qwK8vUGzEZ+U=; h=Subject:To:References:From:Date:In-Reply-To:From; b=iSMU896QJD/RlMUyAu0TbZ6Kd0diZFkF1LtmYKY16Ok5tRjVHyEFze2rSs6ZgGTFE rUQrlBdihzgJ/P7pEEJo+FFYQ+T0fRZ/1dwwkrzCCmlw6OfgSYNpnFIP1RCwIGqa5E pM8LSSfjHoAnqPkIdZm37YbJTOBHQ/tKtPuLpw68= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id C08481C00D1; Mon, 11 Jul 2016 07:55:58 -0700 (PDT) To: Laurent Ciavaglia , "Michael Behringer (mbehring)" , Brian E Carpenter , anima References: <20160708153949.32209.45567.idtracker@ietfa.amsl.com> <1fe314ad-d22f-1291-7e85-4e51ccd328a2@gmail.com> <54f47cc8-bd8b-3783-274a-86e98d9e49ea@gmail.com> <374d2ce8aec64c8aa7b9124a7e1a2646@XCH-RCD-006.cisco.com> <9dbf5192-39ce-826c-b5aa-e88557051415@joelhalpern.com> <91b353d5-7672-c1ae-e173-d43e44b9ee5d@nokia-bell-labs.com> From: "Joel M. Halpern" Message-ID: Date: Mon, 11 Jul 2016 10:55:57 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <91b353d5-7672-c1ae-e173-d43e44b9ee5d@nokia-bell-labs.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Fwd: New Version Notification for draft-du-anima-an-intent-04.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 14:56:01 -0000 Laurent, the text in section 3 of your document is informative. I am left confused about what are the actual definitions of and relationships between an AF (Autonomic Function) and an ASA (Autonomic Service Agent)? The definition Michael pointed at and the conversation on the list seem quite different. Yours, Joel On 7/11/16 10:45 AM, Laurent Ciavaglia wrote: > Hello, > > There is some text in draft-peloso-anima-autonomic-function-01 > (https://tools.ietf.org/html/draft-peloso-anima-autonomic-function-01) > detailing what should be considered when installing, instantiating and > operating AF/ASA. > Please see sections 3+. > > Feedback on the text is most welcome as this will be presented at > IETF96/Berlin. > > Best regards, Laurent. > > > On 11/07/2016 14:55, Joel M. Halpern wrote: >> I believe your description, and that of others as to what we "intend", >> does not line up with the definition you quote. >> >> The text says that an ASA "implements an autonomic function." That >> seems to say that I sould expect an autonomic function to be >> implemented by an ASA, thus implying a 1-1 relationship. >> >> yet, your example states an AF of "bootstrapping", but the >> funcitonality of the ASA being a much smaller piece. >> >> Net: No, the words do not clearly state what we intend. >> >> Yours, >> Joel >> >> On 7/11/16 8:39 AM, Michael Behringer (mbehring) wrote: >> ... >>>>>> Also, how is the relevance for each ASA known? >>>>> >>>>> My proposal: Intent comes in sections; those sections are >>>>> labelled with the >>>> name of the ASA / autonomic function they belong to. Also here, >>>> there are many ways to do this, it's a simple proposal which could >>>> be optimised in many ways. >>>>> >>>>>> And is that the correct granularity of the section? Maybe the >>>>>> granularity should be individual objectives, or certain groups >>>>>> of objectives? I think this needs more discussion. >>>>> >>>>> On this one I agree!! We should have more discussions on that. >>>>> Your point >>>> from the other mail, that we should try implementing some ASAs >>>> would help understand this better. >>>> >>>> Yes. There's been an assumption, I think, that one "autonomic >>>> function" == one ASA. We need to be clear if that is an axiom, and >>>> we need to think about how ASAs are named, and if those names need >>>> to be registered somehow. >>> >>> Yes, that misunderstanding keeps popping up all the time. I think >>> RFC7575 is quite clear: >>> >>> Autonomic Function: A feature or function that requires no >>> configuration and can derive all required information through self- >>> knowledge, discovery, or Intent. >>> >>> Autonomic Service Agent: An agent implemented on an autonomic node >>> that implements an autonomic function, either in part (in the case >>> of a distributed function) or whole. >>> >>> Example: There is the "autonomic function" "bootstrapping of new >>> nodes". It consists of 3 different ASAs: The new_device ASA, the >>> proxy ASA and the registrar ASA. >>> >>> How can we make that clearer? (I thought RFC7575 *is* clear). >> ... >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> > > -- > > Laurent Ciavaglia > > Nokia, Bell Labs > > > > +33 160 402 636 > > route de Villejust - Nozay, France > > linkedin.com/in/laurent.ciavaglia > From nobody Mon Jul 11 09:29:08 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB4EB12D5C4 for ; Mon, 11 Jul 2016 09:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FREEMAIL_DOC_PDF=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 tn5j1pJNr2oi for ; Mon, 11 Jul 2016 09:29:05 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 6EDB612D5C3 for ; Mon, 11 Jul 2016 09:29:04 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id f65so70153310wmi.0 for ; Mon, 11 Jul 2016 09:29:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to; bh=GR2CGOisdwFhER4hj9Bu3FmJ5xjk6oEXVCfRPewR8Sk=; b=RVWPU1ZYnyp+QPUokqi1AFIuWn8Ud+7OHNqKY6aMRI0FXlJokqC2SieTJlDs/1P7TP nl0PO9wmSRIzSRaGTLuIIKBpiYkgoLo1v302KL9Bq3+u6dwjNzuY42PauWYytKzzQY7C hsCj3gxRQYueWh3ZqTecM2vC//qTG1V4joaZHTCascYHxJRhTLkLNLZ10Uw7b+X3cWkX aUumfbOI4JoqCc0kSqV27W0hYsl7Uts9uL2V2boT06GX8pBGXdf+6rtfAeEaEUsM8yaa lXrNFYqvYSzB2iKN7LlH3ULRty3O9y8kjEhHSF8reDlJeGHNroeziILwL5pAkOnKRIIl Otow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to; bh=GR2CGOisdwFhER4hj9Bu3FmJ5xjk6oEXVCfRPewR8Sk=; b=AxuPJmGi82VBJ1SKeUSC7xuOleGbFsKv4ET0yDjWk+6fdyFCkf9nyt3tYOJ95pMp4l 15u7xYdycvqO/0KIaSMxK8T7riVDeGrgFwdV1iEOG6ldnyEcYBihdWT/HF9Lzptqjx4Z EPPp12zKA3k1uGsHBaZJ3l8t15Nu8Y0zDVAdOiRLGZ8jtdWZVBaQkYjk1Ll6YOJaX5rb yqI/ImWNBdbyD2hpsodWrbPh9r/WPMZ3joHNZr18721Pd6QNx/9BN6z5d4r9Uu77QAku js+4tJGpvRWgiIGXqnk0ziKNaDgbsz0lgaHetR2nJpNna/QA+GZeojGhFXvQNrRBgrs+ ie2A== X-Gm-Message-State: ALyK8tJDIlmyBDZiJl9SeJAEltF76WPyHXaNpMjoJ+/H77mbMSscGCmHrhrxGmh9Mugy2Q== X-Received: by 10.194.201.165 with SMTP id kb5mr690609wjc.130.1468254542853; Mon, 11 Jul 2016 09:29:02 -0700 (PDT) Received: from [10.0.1.29] (cpc66883-mort6-2-0-cust696.19-2.cable.virginm.net. [92.233.126.185]) by smtp.gmail.com with ESMTPSA id x203sm2289625wmg.0.2016.07.11.09.29.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Jul 2016 09:29:01 -0700 (PDT) To: Laurent Ciavaglia , "Joel M. Halpern" , "Michael Behringer (mbehring)" , anima References: <20160708153949.32209.45567.idtracker@ietfa.amsl.com> <1fe314ad-d22f-1291-7e85-4e51ccd328a2@gmail.com> <54f47cc8-bd8b-3783-274a-86e98d9e49ea@gmail.com> <374d2ce8aec64c8aa7b9124a7e1a2646@XCH-RCD-006.cisco.com> <9dbf5192-39ce-826c-b5aa-e88557051415@joelhalpern.com> <91b353d5-7672-c1ae-e173-d43e44b9ee5d@nokia-bell-labs.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 12 Jul 2016 04:29:01 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <91b353d5-7672-c1ae-e173-d43e44b9ee5d@nokia-bell-labs.com> Content-Type: multipart/mixed; boundary="------------5B16F3D677FF6A5BF85CF188" Archived-At: Subject: Re: [Anima] Fwd: New Version Notification for draft-du-anima-an-intent-04.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 16:29:07 -0000 This is a multi-part message in MIME format. --------------5B16F3D677FF6A5BF85CF188 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Is the attached drawing correct? It's supposed to be an Autonomic Function implemented across three Autonomic Nodes X, Y and Z containing a total of four ASAs managing two different technical objectives A and B. (If anyone wants to fire back a corrected version I have attached the PPT as well as the PDF.) Regards Brian On 12/07/2016 02:45, Laurent Ciavaglia wrote: > Hello, > > There is some text in draft-peloso-anima-autonomic-function-01 > (https://tools.ietf.org/html/draft-peloso-anima-autonomic-function-01) detailing what should be considered when installing, > instantiating and operating AF/ASA. > Please see sections 3+. > > Feedback on the text is most welcome as this will be presented at IETF96/Berlin. > > Best regards, Laurent. > > > On 11/07/2016 14:55, Joel M. Halpern wrote: >> I believe your description, and that of others as to what we "intend", does not line up with the definition you quote. >> >> The text says that an ASA "implements an autonomic function." That seems to say that I sould expect an autonomic function to >> be implemented by an ASA, thus implying a 1-1 relationship. >> >> yet, your example states an AF of "bootstrapping", but the funcitonality of the ASA being a much smaller piece. >> >> Net: No, the words do not clearly state what we intend. >> >> Yours, >> Joel >> >> On 7/11/16 8:39 AM, Michael Behringer (mbehring) wrote: >> ... >>>>>> Also, how is the relevance for each ASA known? >>>>> >>>>> My proposal: Intent comes in sections; those sections are >>>>> labelled with the >>>> name of the ASA / autonomic function they belong to. Also here, >>>> there are many ways to do this, it's a simple proposal which could >>>> be optimised in many ways. >>>>> >>>>>> And is that the correct granularity of the section? Maybe the >>>>>> granularity should be individual objectives, or certain groups >>>>>> of objectives? I think this needs more discussion. >>>>> >>>>> On this one I agree!! We should have more discussions on that. >>>>> Your point >>>> from the other mail, that we should try implementing some ASAs >>>> would help understand this better. >>>> >>>> Yes. There's been an assumption, I think, that one "autonomic >>>> function" == one ASA. We need to be clear if that is an axiom, and >>>> we need to think about how ASAs are named, and if those names need >>>> to be registered somehow. >>> >>> Yes, that misunderstanding keeps popping up all the time. I think >>> RFC7575 is quite clear: >>> >>> Autonomic Function: A feature or function that requires no >>> configuration and can derive all required information through self- >>> knowledge, discovery, or Intent. >>> >>> Autonomic Service Agent: An agent implemented on an autonomic node >>> that implements an autonomic function, either in part (in the case >>> of a distributed function) or whole. >>> >>> Example: There is the "autonomic function" "bootstrapping of new >>> nodes". It consists of 3 different ASAs: The new_device ASA, the >>> proxy ASA and the registrar ASA. >>> >>> How can we make that clearer? (I thought RFC7575 *is* clear). >> ... >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> > --------------5B16F3D677FF6A5BF85CF188 Content-Type: application/pdf; name="AF-ASA-Obj.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="AF-ASA-Obj.pdf" JVBERi0xLjIKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURl Y29kZT4+CnN0cmVhbQp4nN1YS4/cNgxGmvTlBH23SW86jgOMKonU61qgCJBb0rk1PQ2aFgG2 QPbSv19KIjWyJ9Ms4p4Gg12bpD++RFG03yqjrTLlx9fjzWRV+d3+ObmIOqasgqVrjsqjMSo6 +nf7x/R6KqBkTEyE1MFYH6CgwJjyuIqQUSdF+kL22ndGgKbV52g05E6js0V8nITh0CclYGug SEU5k8cJwbqB4SFWecUK0TULQ0wLmD1beX6cXj+donbqH0rJc/p7M9VMqZfPrinIv6ZfOS5a vLeTbfd8Od6onw/TTy8jGVOHtuY5p2C92lu1p+d8IM+zAmd1SupwM/22uzdbTSEh7D6a91Qa GaLd3Z/3TnvvE+wenLgfn24H7idz0DFAht2nDRWS33027y1xE+4+L08CUgrD7tXfM90nk5MY cyF3vfX+BLw/O43e5FHtgwXKG/P74fn0y2F6MeyDgC1lhhfb2Ry17QyboMqDt6FkXGifTEtx Z5jslIDR1wUT5UweqbSyHeSA/oTthGgWhpgWMHu28rxW9BVFs610wQIpJ/PodAhcuw+pnAL5 E+KiMh4N969ua0FFg8tS/GKOzlHhx15BQ3/km1ZP2LYg9UxZAe9LnMywmfMSk9fhRHpZAGE4 skdpYTTmliXWzuSRFtzDKE9LdFpp74xmXdDs28r3VlHXFM+2mnLgNNjiDJVFWLfDL+c96uBC jAPzqwtNR8Iue6KeMNm3ndYY1ucqh5jcQLrsOanCsI6TXtG2oUU7kzVLdpCDsyO6k6JdGGxd 0LjUjqJ9KJKriGdjkaRcG4+jEFaNx2IK40n46HTLbWd9AH7NXSedlxBSw2yVH1vKIWEucwYz wLegvc1BYycREyfFS1IiNWvGUnUXqehmkmaUENPA8GbACtE1C4MtC5b9Wvldy+dqYtlWOhgL g6zTTGfN9jPrmzlYOpzwvUeWS+OGoRZvoDZpZshM4GLbnUIiLmcGZ0PdX4y2uQ60op1J2r0e YJTHJTqutHdGsy5o9m3le+tG1xTPxm5Ujqqincr44pFVGtCJ+e3iyLpYMu3cxT5nGnpHyJ0h KYQUxhSDT8sUA5iW4oYGE1sSmnYmKWfUOdvM2OQhLtBCivbOaNYFzb6tfOeSuaJ4NpaMzRqL MZfuWjLf3aVk0DhupTxIUset+4oZ4PldN9VRrpNB3h+EAXUUFDRHLdp7EpD22SjHBbqTor0z mnVBs28r39uhdU3xbHzZIpdKl0G482D8/dlgPH5mcvKZw0b+rKFCaF+mnpL5N//xwKbSD1Y7 aAN+whbHD+RyILf87vFw5D6Z96AN0qItTtx7Z2+J68jQ8GZ174jssnDTWOFyjQrBavyQqH6c Qwik011eL25Bjkt/EdVl4aa1whZV/TK2iCpBkqhKm+KgqKW9c6nSe4MC5y8HdS78P4ICWjL8 gKDOV+rF9C/u0ETjZW5kc3RyZWFtCmVuZG9iago2IDAgb2JqCjEwNzgKZW5kb2JqCjQgMCBv YmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSA5MC9QYXJl bnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0ZvbnQgOSAwIFIK Pj4KL0NvbnRlbnRzIDUgMCBSCj4+CmVuZG9iagozIDAgb2JqCjw8IC9UeXBlIC9QYWdlcyAv S2lkcyBbCjQgMCBSCl0gL0NvdW50IDEKL1JvdGF0ZSA5MD4+CmVuZG9iagoxIDAgb2JqCjw8 L1R5cGUgL0NhdGFsb2cgL1BhZ2VzIDMgMCBSCj4+CmVuZG9iago5IDAgb2JqCjw8L1I3Cjcg MCBSPj4KZW5kb2JqCjcgMCBvYmoKPDwvQmFzZUZvbnQvTUZaTVJSK1RpbWVzTmV3Um9tYW4v Rm9udERlc2NyaXB0b3IgOCAwIFIvVHlwZS9Gb250Ci9GaXJzdENoYXIgMS9MYXN0Q2hhciAy NS9XaWR0aHNbIDcyMiA1MDAgMjc4IDUwMCA1MDAgNzc4IDI3OCA0NDQgMjUwIDU1NiA3MjIg NTAwIDQ0NCA3MjIgNTU2CjUwMCA3MjIgNjExIDUwMCA1MDAgNTAwIDcyMiA1MDAgMjc4IDY2 N10KL0VuY29kaW5nIDExIDAgUi9TdWJ0eXBlL1RydWVUeXBlPj4KZW5kb2JqCjExIDAgb2Jq Cjw8L1R5cGUvRW5jb2RpbmcvQmFzZUVuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9EaWZmZXJl bmNlc1sKMS9BL3UvdC9vL24vbS9pL2Mvc3BhY2UvRi9OL2QvZS9ZL1MvdGhyZWUKL1gvWi9v bmUvdHdvL2ZvdXIvTy9iL2ovQl0+PgplbmRvYmoKOCAwIG9iago8PC9UeXBlL0ZvbnREZXNj cmlwdG9yL0ZvbnROYW1lL01GWk1SUitUaW1lc05ld1JvbWFuL0ZvbnRCQm94Wy03NiAtMjE1 IDc3MyA2OTRdL0ZsYWdzIDQKL0FzY2VudCA2OTQKL0NhcEhlaWdodCA2NzcKL0Rlc2NlbnQg LTIxNQovSXRhbGljQW5nbGUgMAovU3RlbVYgMTE1Ci9NaXNzaW5nV2lkdGggNzc3Ci9YSGVp Z2h0IDQ2MAovRm9udEZpbGUyIDEwIDAgUj4+CmVuZG9iagoxMCAwIG9iago8PC9GaWx0ZXIv TFpXRGVjb2RlCi9MZW5ndGgxIDMwNzYwL0xlbmd0aCAyMjMwND4+c3RyZWFtCoAAACAIIDQA gAAAwAUCeUxeMoJEQAdgpESsYzaYThEoIdEJBACbDGdjoIH8MG88Ii3IIB20ZjgZzaw1MHYG AAQuIIBhiZzYeTNHAAHjxBB2UjQZTCZHI/H4xIId5VBBsaKSYQk7wsfYIDnZERIaDadKLHDs bJAZDYbzGYaEWWZBA0toyeDgFBcBlbBAeEIiIDcYTaZaEdamABCcDeczpQju0L+cDkZTgOXM yIMAAeML4RQKjoIBSYAA/ogAHAGlAAG4I/3DrXJrXQ/iU/34BTWABG/jU/3AAwnEb3BOHERK AEsAE+ABIAHgARiAGEAGAACUAFMACDCwBqiOAGeAFeAAcADyAWWAAJugARAAqAAJQCHwAAgA RgAFwCBQAmQAbIAC4AA5AAcoAHAAAUAAJYAG8AIJOYAAigAjYLAAHJ/nSAELQYRB/ly/4AAU AAhgAVwAF0kIAimAAXxIAAkAEFgAhW+IAEef7qgvBJ/maf5sRsTsCgCEh/ljGAASEcwAAiAA TgAP4AEiAEIDUABlNssAADEABTgCPgAw0EIADAABFgIGgCEUf7ch2ABagAaoAiXNgACa8wCm wBM4LRKZRgC/RgH+b5/nOABfAIgbCSiQQAEQ/oAFk6gBBcAYhgKUAABAAATAAHoACcAC3MIP b/gCCboAGIB/hOf4hH+/1QlOAB5AEFYBGMAYDyYAEaiSAAvgARoAFC8QAGsADYnqAIFgCGoA k6AJV2kAJogCd08ojBg6gAPSDyS7EugAVgAFy6DoAEC90vq/IABSAAq2+R4AFLSIAFmABoTm AIsgCYAAmCAZSgKGB/B+f4KH+CtCn+f4ABUAAsUg5Zg2SAB6ACGF+WoVYBhEAY6AIDwCDoAo ZH6QM7AAMgAE5fIAGjY8GwKAB6gAfAAhVnIAnCAQ/AEP5/iuf5UH/AyCAQ0gABwAAogALQAD eiYADuABROo6QAKgeIAn2AQE58ARngIYoCj0Ap4H+SUqU4AAhQWAAn6aAEWZYRcTXsnSdWRZ YIgCEFzhwAInACKQAjOAJHgCSwAlwAJs8eAQDAEEIBDiAR1AGWABmWAZuAIGwCgKf4dbZCwP aUEYACuAA0AAtA/UcAG13q+BigAZIAgqAITACFuMgCa3HgCewBB2AQieQARR7EARvAGQoBke AjbkMfxwH8dZ/H2f5FABXb3O/iVuFVix3gCC2/gCFIAjUAI5gCcewkgARaAGBwBggAYRgGGo BhBAGFQAYWQBiINSAMZAAxnAEDkAQVYBBtAFCSAUMIBRVgHDCP4Nw/hoj/ToR8kAAADFDScA AFgAAaAABulsABQUrG5LQRsjaBA+AAZS940CU21qZFWAAnQv3cJxAAN0ABX2MECBC8ANL7QA htS+AEQoARHRSACJkAIrGAABGKAF3I4XiRfeKCIAUYgUACBsAIH4AghgCCMAIM4AhCxwAEJQ AQ0ABDWAEOgAZqAxgDD+AMQEgABieAGLYAY2T1gEkUP9k0jQkAFEWAUU4BhlgHBQAcJABwxA IGYPwdo/QVD9CyP0bw/gAD+A0P4LY/hLD+GCP4c4/wrD/DyQJGwLQAAuABDUQ6UlILFXqvV8 p4xbAAGMAAuI14hxFVoAEAR+1AABAwAEEbO0ZgxACD8AIRwAhJm6AEJoAQoziACFWcoAQrgB C1OoAIYQAhiACGieIAQ/gBEAAEQQARBgBEIAERoARK0AoEJiKoARSgBFSAEW1CgAi3ACilFK chvgBHMAEdQAVarsAEANdIAgSgCBOAIF4AgcxqpMEcAQTwBBSpXG4AQb6XgCDgAIOQAg7NhF OAIWYAhcx3OAAMEoAwWgDDCAMOIAxMgDFcAMYQAxqADHyAQAQBAWAEBeAQHgBArAEDOAQQYB GxjRAINgAg+wCmlM8GgAongCjCAMBsAwNADBVAMGoAwmADCvAMOgAw/ADgGAOFCTQBw+AHGo Acf4CDjl7GOAB8qcChFCBeAYZ77wCgUAIHgAQ32WgAAwAMOABRDzlRs5OAQbABiOAGNIAoZg AjwAG4AbQARFADDSAMNY/xRgDjaPgAYbwAhWAEL8ALHzSg6AGUERgAB/rSAEz0egAhzgEd2F QAQ6QAgoAIJGhtL1LOSIkAUad1KvAFHQQQAUygdACD6v4AQxQBiDviP8XoAAdVrACN+tYAmY ggAIOAARwaJr/EOAIS5ERnACDSAJu4WE0AFH2ACJc6xUgFDxPgAIPgBCIZzU4AgnkCv7AEPO 17i1ugAGaAEJQBASACC9SRaR4AAD9AC6gdoAQ4oUoAAAIAARdgBG640gQARUADS8EwAQDJ/A BFgAIBoAQbk3GaAOJNT0RhZIk7wATuwoACHgAIKoAxeAGGg/0AJAzIDSW6AEAbGZd2RIJKYN 0LTu0gV6hJlQ0wAkQAwADA52x6D+F4hlDaeZIS+FCAOE4UgAGcC6AI9LpW1oGQMxIQwACIC6 Ugo8GAAhMS7H/PdliCk7mEPs45KwL1mK8P0QRKJ6wLRjXCsEgg+ERJXReEta7VG/sXX8gkAm tAACMAIhM6aZVSt3buywLrWWXCSAMLW8TcVAEEAISbEBcSWBePuAAcemAAAaAADyXzUBQ1UO 0poACv8csuE4P4JGPN5aXGXM4ABXHSg+AAlYKABN4rvEsP9K2Bw0oHAAaM1gycJD/wOEO+gA ApD/EGP9u4Xx/ihH+gIM7dGiMPImP9SQNgACHAKFkAQVgCgrTQzN3JUN4jbAC3dfG8bZvpPl n0dQAOconIID4AouwACKAJMpFjBxGD/GqAACqCQAAiUglw65sQ2gAHczQJAAzqgzH8E4AQsR /hGtAnizgUR/inH+B8AKIw0D/LQ3IXi9ADn8h6QgDwBV6nHTOGYARnOCrvfSi4hAXACnLx4E IKoVAgA/B8D0HgOwdA5BwDcGwNQaAzBkDEGALwXAtBYCsFQKQUAnBMCUEgIwRAhBAB8DwHQO AbA0BkDAFwLAUAmBICIEAHgOAaAwBYCgEgIr+AUAlHCBgsCKCMIwYAQCwBMGAWABATAjCQEj znxwjAjDD8sEwYfn/R+n9X5HzgQfZFh8n7v0vqfG+R9gWAIPlfM+5+P8/3/1fmCB+QM3zvof o/B9f7gID977YWD+7+b9IAICAEDcgHjzgED475YZoIgEYEBxwLQKILECQWARsCILL5YdsC0D AJsDb5YSED75YBsDYEIEMBkBoDANAIj5YAL5QIr8oOwNARQIoMAIjzgAIWL3oIYEYIYMoBTz gAAWIBQBcH4IYBcIgWAC4EYOAWJQAHzJkJ0KBdIIoHQWI+wBABr6oWADQEYIkGYDMMMBkGao AIopYWAKECwIoIgDcFILLzgWAAIIYMYEYMQWA3QIQWAB4FcM0PQIcHMHYWAAwIYWAA8IMIYF gEANMAb7hMwEAWIFgYARQRgXAvwMQMAFYBgMgEYMgMILgLBzYMMOT4wWACIFcJsMMJoPQcgD EL0VMVcHQFgWACQIYLAQ8GcWUJwIkVocgDYAcG4DANL5cXoRQRQQ75YUEC0VEVUXsX8OEX4L ILMWEWqjz5IRQI0R4Rj9IJYKYEEUTJoQoLMUaKEUz5cNAWEMkMUL8MIIoMoEYIsdIEoMANT5 YBIEYIQEcGwNQMD8gDQRUPQKQPIEIWQDQDQIAXI3zcMeYRQKkC4EIWAH4DYEYLIMIIgDgWIi oRUggWYDIIAEADMh0iAEciUiki0jDzgWICACMJMJYFgWIBwB8l8lYBgBsmsmMm8JIMsmEmUm kIEnslclsnkmAJYKQLEN0OAEMUxv5zYEoEYJMAb8QMb5biEC7JoEoHAEcrIMppgRQMYHEpcF Mph3wFgJYWAMkNsRwBMQQRQCAHUpYCEpoWAAoEoCECQRRm0OgMAEYdodkQku0vAEEvQAEOgM Mv0wBGcQsu5m0v8BkvkA8BLccyCdsyUBUOYFcVQFQFUJkRMQsJTzgHwWEzjzgGrzgOwXAAQW EJ8BE1QWEecPQKEc0UoHQF8a0FMTsT4RYXAIBLbzkiQQEC03QMk3hTYMQDZSQIAF4FYLLJoM E4AWAYE4cT04oXACoKs5BSQQE5k5wAU6AFk4k3k30TUkzzgWiWwggCoWABAE09k909s94voC wCYIoNAHUOgC0889LpU98/0+M9s+c+opM/B9Dzkb4EYJYKILQLEBoRUHMpcUwJciFB1CEONA 4KdBNBYLEsVC8s8iFDspkHdBFBQLUrL54EsxgJMeUYgKVBlE6j0uoEr64IoNIMAJALMskOYC cXAAYDYAUUwWFHgLAAUYNCQKkWwIYLlBlENIMW8UQBlFFFAA04gpYXAA4BEZoAlFNLZv8bYC FG4EFL9G4LIBUFNCMOdJ4LFKNLdKdKoMlK9LMUdNtLtMQXAf4eFMII1O9PNHFMwENNEs9DNE sUYHQFdQNElDYWAHdQ9D1RNE1J9JlQIBi2tCb7oAVCYLUZABVJNJdDlQL68bMbUCQI1B4RQM NO4QAMUCUvARQXIAYLFWARQOEHEq02cw9O4XQRYDb8oRk51MCeQHUlY+wIQWKaoRAKIWLHoR AKdBgXIvxTQREiAWSZ6NQMAIQLIWIEgANZALAXJTbHlaQLFagAVa1YtbdcVagEFcxBZOcpFa gBFcwLIDYXM3wg9dKqdeVeoggQAMZxxR1aYAVeMQVbFfYgdfw+1fACFfU3w+1fw9dfAIFeUa kakOaNUiFR9T8OMsdETLIloEIfxCYK4vwfYOgfQb9aAm7OAjjLAm4BpqAeTcZcBXY+wvxFwK wnYEphoAA/ingACAQdgWYAYFQD4H4IICoAY2IMAAZDQT4AZAwb9p49QAB/Q2J/RAwH9qQOFp K5lrh0YYAAYcIWYIoIoGQIAXFsIWYFYF1s1tAcIWQFAFIGUhdsFt4DQDgGQXtsIARchJ4D5H IAYb4WQCwDdudwAbwWQIQIVw1sFxAGwHFxgAYbwWczoGQb4IIBVyQAAd9zSjZ56zhBVv9sAb 4WYFFtgeAIIBtwIgQAZ2IB7M5pQUAAaIhzaIg+wIAAYbQWYEgEwGQT4X4AYuLNgZQAbhRll0 V4oWQBoCIGVzAAYY4AYW5tgD6QoAZOF49wAWoWYB15g7QOYAZYYgdsBYbMpYY35Ya2BYY9YN 7IxKF9oR99oV99o9YB99t6hWYF99oJ9+YAZjqHtzheogd+pet/Jet9het+Beo9aAR8ogYNYA eBoAbIpKzp16gRg1LpQ0gAYRYAYSeDN6gUmDrcODQUWDB1F6jROD2E4Adpw1WFYTeDDcV6gT WEWFapI1RC16gTGDGHIAYS+EQ1l6gS2DGIIAYSuIGDQOwAZbmGRkGJeEd6l2QOYWQDwD4CAI ID2EQEGEQGGEQhWLY1WLo1V3A1QhQhI1TNi+QtGFYWIAYtAiF6gNuNzcF5APoWQEIEdyIPoW YC4DIGQUF5wrhzYrlsArjMorgAlwAPmO+PNugAYPmPmP2QCoaGpzaGtsCGrMqGo9eLoObHgA eTw+whOTx/WT2LeTwhQ3+Ty2GUMw2UA6mV7MuVAAAQmV4SGV+KQhIAYO4AZKxd96gROXtuAD 9s4AYM4WYHIIAGQH4Xa5KW13AM0j4DoGQR+ZooIgeaAWYBIBVtq5ObQB2buaIBIB+ZeZowmb AAYMubQBmbudQDWaeYudQBOcANYIJ/AMYAAPYAefA+wCmfY5mf4Gmf4Imf74YMYWQEgF4D4X QAZUINppIIABwD4P5oCPwAgP74QGAIhB94AiAKBpJpQCSoTceiAFID4L4HjKAMABIOABIQAB J/IBIEABIGABIIABIKABIAt9iP9+AAd6l/NrN/YL4AYAtO4YAWQA4HQGeo4IAI4A2pYSABYU ABYWABYYABYaABYAsQoYDMgAwcAAweAAwAoEAAwGAAwIAAwKAAwMAAwOAAwQAAwSAAwUAAwB OugSAA874BYOABYQABZ/IBYEABYGABYIABYKGrYD4A4AOQB6JLgm4AZLh/RLlrZLmW5Lg9a2 BYIgeLbbmLZYOLpYN3Dbg9YhLbghJYJ/RYLMrbg35YI/h/QB5TQAe2mLu2jMu2g3+2g/ghO2 m2Yhe2xMm4dre3O4aEe39qm4eLe2+4e3g525G4ZJ4hI8uLo8o+w348q2G7B+46xA4AYgy2Ag yjYgxJ6OwfiW1he9Nde9LLu9IhW9BA4AW9OUW+lqm++9rRu++95Mm+6EbAG9LL++pTW+7Tu9 NiW+G+j+4E4YB9gWB9gUB9gSB9gIAHlo1swEXDACXDgL4EYL4EoL4FAL4UoAgN4EYN4EoN4F AN/EoJ4EYJ4EoJ4FAJ/EoH4EYH4EoH4FAH/EoF4EYF4EoF4FAF/EoD4EYD4EoD4FAD/EoR4J gV4JgX4JgZ4JjYIJgN4JgP4JgAYG+o4WYWQFYGAGXL4WQEQEvMhHIWoWQDIDQGQG4B4IJ448 YgYL4AQ8YT/O4AAb/PQhQD/PSkY8aNI8amA8aqQV/PXP4vakYvaNIvalQvfOwvY/nPgveAQA QvfRQAHRxYHTA5XTw/nSXPfTw+wB/T3TXTghViQVgWWpYJ4IIJVvnTpcnPJcghSkZciNJcnU vWXXQ8XWQhTJpcjAHXZuPWXOxcgUHYA0nWXXHTfZd+pqGAQAZqF6hqFrJqGohqFrZqA/gZ4A Z1lqJ1nUvcGDR1lrZ1l+R1j4YLXancHcHTHeIVlvjRQIABoGICo+gCxCwgj2wBGK9hYBm77J 4+A67J7T/gwAIRPgabPhgEmiIJQBoe3iIX3iIQ3iIE/igARBQ7bJ41XjoAIEOxF1IWl1PV4B oFN1IINhZHZMYBrLYxAAHl6EflwAIdfmLJ5UPmoFgIACgEIBofPn4efn4ePn4Tvn4OPn4Hvn /lYAQDhpXl4io+nl4BfqDE3qbFXqwE2xAD4BoY3roK/roG/rt1IAITwAPjpt3tHmQoftYgwD ftyjAWgB4Im2gBLH9mI93l4AIWQHmk01RSPvwD5xzkAHgIPwYAIf3voI/xAfvvoT3xAfXvoS YD4XgAIfIAN14gbtAe2hAcgD9o4AJjAJJRI0gALEn0nzYAJrhX6HrtA55X7jbtA7OlI47tAU nvoQP0B3ZP914TX0xq4EQBH1RYrfv1QT6b/37tBaP2P0wTgWQFgMXxATf6APPyoAP35Gf1QS /6Hz5xwSf6ARPxASX6ANnxAR4WQEvyDVHvtogIJvzjbFv1WfCj/1wAIJnzP7H0wJCbp1/0wg BHWQsRIfXABIsDT0GAJEgZ5hhDWQjGMME6yHiBD68AIjABQAIBAAfAIfibkD5BCoBDoAEYBT UjAIclwIkUkDYAEs2mQOAIPAk3AINAAioMyBETjUHAy0Esoe48XYBEsjAD1n6yhbjjhJAJWq ziAJJWSrD7RXNjoKyD7PFkHEq2D7OEa7D7FEkHK1sYFvm1sX9vAQBWofWIklCwtJJwdyV4sM 4fVojXF/D6lymDIALD6fHgtD6bEZaD6ZEq4wdsQIsXlHD4ANs/r+bD5ZFg+D5MHlmI2nkNsI A8uBABQfHQjOQfHO7D44g5JWdmGN5tYfGGnASruQqxAfE2Ur9sKo3XQCGoAA4BOpAFgHOgHM QHKwHKIHHYHGYHFoHEAHDoDg4A4KAQCQEAgBAHAQBgEAUBEHAMBACAQAQEAABAKFwf5wCAFY AAAkQKAMCEPJEAwCRIAACRHD4AAgAUURfFAAMHCYACUABYAmAYlgEJYpiEAJYAkJYACWKghF gG4ViWXADn+KRYBxJZYAQKAtiwWKQkcLMohWWABEQg4ACoLCDn/LIAkcQoNyEIYsFzD4AheQ pGg3OCQj5OgsiyAIllgYAxyKMQQFgewpvABQoi0WAChGIQMAACw7B+DAfgkHwIhyIwiUxTVO UzTdO1DUAwU/TVShXVNVVWFYMVZV9UgwDpYEtHwsFgVQOy4GVbFgf9dT8I4phALk3gEOIBDe IoiFyAQ4WTZYszeAI9WOIopWMONqCJPdg2HYs4BFZ1lzgHlx25aZZqLa83qKAJZ24LM/CZb9 piTdYiFiEQRWjaZhLHdjFgCYV4z8M96zgElrWYj+F2lZoPAAEmA4kAQPYK1AA4Qn98X1fl0F yBkPgfgKf5FgpYA5epYhKEtlliFmXXQWIb5dbGWBvlBV5XluXhHmWHgCLKdYoEuhYwkOeZkW IUaBY0K5tdoSwpeNYatq+sazrWt1gMoha5sGuXeMJuDIMYijKEYijBtQy7ZtZYEWOw0AwWBA UGEBYjIbm0bVQgBhMMAxDGNG/hMMIylgbgRjKIhYDIEYibyMOz7SIvDcFwnDcQWAx8Zxww8i WIAbPMhYjGIHGlkMIgDCIoRjDbhZlMP4hiXvu17bt4wFgRO57ru4QbyIY/9xzHB8KWHAc4P/ PlgIfI7yU3b8t4/NeVw/EiX5xTdFIoi9MJfUocUwgFN1/Y3kKUgCWKEsQqIQsiHYpY/gLJZg EBYFAlNwwA2CELIQgLAQDgD5NqbwdghAwH4DYukTgBFQAABYK0uAMUcLABsF3+JvBaEGDsDU TonglBQWADoLgPg0m4XMC4EwNghCKCaXAIQXAio4ACHQMBFDSESHUPIdw9DnEEOkQQ5h0DqH UFcQojQ5h3EJKYIQpp+CMopW4PBYA8CKLAICpU+KriPF+L6bggAQF+DwZ65g3g8D+DwR4PDP CvB4AWI78gsBAAkL8EQz1xBfBEG8EQfwRCPBEJ8EQrwRAGjm/MLAtjgyEHeCIAYdQsqpACHS SwdFlxKiPJmTMmAiRFDrESIIAIvhzi+qmMAK4kJuCCCJ0gAwWosAHLAACOpYgjloDOWgU5aA FAAMOWg05aDjloPOWiJxBy0EnLQUctBZzHlhLAIoGIdyWjmCuFQAAMADBkLMGANQZHOm4LMM IZpwi4nGFMLU55xhFCdOyboPAggyAxOgGQsgfgzAUEEB83EWC6n8Mqfw2p/Dqn8PqfwBZuTc mnNWJCrAshzAAHMFYAZVB1huqkOlGYkgrDpRajIAYiSWooh2ktHKRRDorJRriH5TUTolD2mF KVWUUonKpVNJVYRFVSh5DxgyaAAAKByXwAABnoAAE0WJgxdgCF8AAAx6ABC/FlUIAhqBfC0q OAoA9V6nC1JEBkBABgCi/qcjOowAQUgAASAENYAQvTaBWBAewPB+g8CcBAegPAm13AAD+uwP AID8sCDEGAIQI2IBLYgEJM0Tj8BAAMYA/AgS+H2AAEABBgIsHgh4AdZA0KRAAJcIAFAgAYDA BgUAGBwAYROBi04Ag7AAEMjMBwQQJgBDSAEINbAAigKLWm3dvSbXAI8h8fAAAH26UjbxEg8g gE+AeA8AQCTBgFASgoAVRxdABHvWkJMdgHAOAeEACINQYAPD+A8SADxQFAAeBkC55QSABHJX KvI9Augrr4BAdo5AIA8r+DywAEQJA5ACpkq47R+ABHqqmwwAAugBDiF0CYJQZgRAoBYCwFwK ghBqD48wEQaAnBMd8EQBx4ABCUCECYPAuD+AEGAHAFquAlA0CUIQBBjihH2IcOQOAPACZaAI DoMVqjcEoCoEAHjXosBZZ4VYBbQgeACGgIAggDgYAWDkC4GAOA9BpbDMINAMhAzKA8D2HAUg HB4AcJIBxUgHAMEAEAWwCBaAQFsC4WgMBrAQHQCIdAJCcAWJ0BwmQIisAWKwBwyQCjJAuMgD A2QLjZtYCAfIBB84eJWB0AgGQCgbAqBkC18gOgYAOAkC4C8uAdzMEcDIiQLiPP6BgDIAgBAX A0BkBgGQDANAHrkAoBgMAXAsBUCgBwJgEAaQfLACQE2lAYD8QFbQEzoBmEABgEACgaEeBkAI nwMiv1yBmgAM60iNFmAEAQDAPEHEaEAogBhxBPAmF8CYbwJh/2aBMg4BwgATCAiwDVmM7CAs iGAEAoAQACBABkqY+ajAAAaAEIFpQvrJAEH8AQj6pgCGeAIb4Ah3oUAEBkD93RHEhvxXoLoT RyA8HbXkLocR7cxv0O2/2Ax2j95vgQfocRYgGAEENMgtxH1tF+AkZ91sJBxkmOTAwFwc4GwR 1gHIAgIdF6OmQWgfQMiN1zhILIDgeCH28H0YgDhiWGwoHILuEqLU9oqAPECHgag0xQAYA4Iw bA2BmDLZOy+/ACAOCEGXgQbgDFWF8fg4AAhhACCATwbgyCfBMCUDIzxNilG6DAJQph8g+ACG INgVwjAaACAUfw+2jJAEwKkQIpg6hxFyMYagkAzhnFELUfw8AcAQBjLEkQUx/joAGFbKgAAZ ABCYnABSGhZAMBztkf4wDg/WCCAkIoCgjALCWUbp9agUg4BSEAGgYAaDPBoOAGg96uAABpbw BLzQ9AuFUCQXIJBdAXBkgXBvgRhvgShtgXB1ARB0gSgGAkgEAUiDhGBZgUAUERjUByBZhoAY AAgYJ0AaBagBgCgIALAAgLCDhPhagOkOAXgaAOiDghhZgIAGgUgUCprQgKK2ABBxjNgoAQOF ABBIOGuHgQNtBZhYAGAAgGCDhIQeAWhAAWwgAWhQQoAWttBagvgDg/gDvEDUByjiP1LfgaBg AaABAaAACDgfBbuBhfgJgBAJgMgZrusrB0OXr9OZAIObuch2ubudubsAK9q/h2gVh2g5Afw9 h2sDgXh2rDAhg8ggAbAXAXgPATAFCgADARAQgRgQgSAQrFgCKyASgHMTgFAQAxE5ACAWxTAP AHxSgAgQgFgTxTAFAEgXADAYRTAPgGgOgxKMsAqVlVgVBAxhBAu6MKg5AAA4lUgJvAvBtkNl ADsORngDAQgRATO9vBAZNkMOgLPBgbO9sTMTDvgRsQjzO+ARsUg0AdBYhCBRgrghBdA+hAA4 BJB/B1hEgxgXgQgMgNAIg8ALgSgVAzBLgRgNAPgVhLAnAQAnhPgkBAgwBNg0ACAlBEhKg1An gtBKBPAYhbA9hYBAhUAiATgOgWAEACgfgDAFhPA2AnglgcAOgUAggPAFAvBCAngzg/hTKfrM LPBcvmgFOLAABrggAUALOLgHgAAigGggJ+ylgAgVQkAKj0gBADAAgBgEtigAgCAGAFiiStAG xPgGAGtniZo7ADkLgDyzAEABgCM6EFiRuLgGiphOKoIJNxt6ACgAgDLsgDEIACytAGACCpl7 qjibAzDNtpJ+txgBhXgBrtiDh7rTgAgfuDLlAAgwL3AHhwJ+gHs6j0gDgMgHOWOXFXL8g4rB Q8guq+L9TTAIBzAIK/AfgfgcgXsAzaueB+g5AeFMlMsEsDhDgXAVgCA+gIBiTegcrpgHsIu5 AAubg5AAgKgRoarEgagAsMzoyqhchbBSh+hhABA6g3BSh/L6h6BHB/BNAAgzBAABhBB+BGAB BQh+gvydEVgClGA1gACaAPgBAMKluvo6gJCSshgPCWgOAPCaAOiSUDABAKBfABhxAAAL0HD0 UJAFUHAgALkJ0CgBgHgEAOALCWgPg4AAhAN3CQgELqEKgXlLTZguhmhoBmgXgXuqgcr/B2h3 B2E5UY0dTaA+hDhiBiAIUfO3gYANggANkELpgGgIAFAPAEgPgoAQgDAKgHgJgIR+ANANgNgO FZRpkMhgBZASgagQ0vJvAsAaUxvshZgVgXUz0vBZAU0xUyAQATU200gNAPU60vgL04vshZAK 0+PtBLgIAJgaAGgHgF0lgPTjglAHgjAIAkgPAnoAAHgrgIAqgKAsAPA1AHgzgIA0APA7AIBA ACBDgHBFAHu1BDgJBEgPBEDQgHhNgINFBNgPBcgHhcgIBegNBcgPBlgHhlAIBkAOhlAPBtgH hsAIB1gHh0AIB0APB8gHh8AIB8gOh8gPAWAEgHglgNgBAPsrUAkXgOgPUDAEgHAFANgEgLAO ALgNgLEJgD0jgKsNNSA8RVgIAQAIUDAOARAIgIAKAIg4AIsEgIAHrxjUBkrzGLAKNdMnAOhS kPURUSDBiDhatuEDJ+gKsOEHLsgOCDh9AgVs2BAIgBBSgHLzDUAYBZgnsrN4gBB2LogQLogo AHB4AHABgHBTgQA1hFFXK6Aux9ugB2gMANL/Q8B2sBzasCLBL9LBK71SzgACzhhiBDgugHAX FXBD2ohiFWkWh2gAgILNr/Wv2w2vWwWu2xu1O2M3geW1u4MKmrgAu5E+AQs6NlMOsPgagbAb 29TqwS27sQPAxvgFrthUh+h5guARAdgxB/Aqgqw4PTBuiXhsAcgugph+h0gogcgUA3BzUcBj BrAngTgPgXgDmWgHgMAYBJgCAuB9hMBEAogCmWgCAXAQgWAvihgBASB+huLPLgkUhzACgmAA GIkOgcABA+ggAYAtAAAtAPBEgABEXnAZhMgNBOgThWANBWATh0gNB1AThzgXgGAcAAA9ATg8 gZhNAZBMgZhSgSBVAZhsANBsAThsAUAFACAdDUBzhZ1OAbX80019gaX/vtBxgKgLgaNt3a4E AgAM08AZAgARgUAaYHgNtYAiASAiAShEgNBsgAhrASBtAZhygSqur6gSgGgZAIABgKgDANgN AKM1gSALAUAKgYAXAZAigSAlAaArgAgsAMgtAThLABV+kWgdAqgAgtASAwAdA4AdBAAdBQAd AEANAYANAZAoKjAIADgNASAPAUAMgXxPrtgPAL1IgZhEASBNASBsj8gQAdAgAdAoAdAxgBAx gBgwACgwADAwADgwAYA7ADA5gNA5gNg4APA6ASA5gTg9AUBCADBDANhDAPBHgZ4oBlAXhtAX h1gSB9ASAMgs0TgP10RqAIZRgLRMgZgSKjACMogagVgPgSABgRPzgWJdAXARAUAaga10waAL tkABAXAUWNgEBIATAAgTU3AdAa5k0+ghZmEMhABZgfggu+UyAhgjZrPsrS5ngTAmAvgOAA0m AYAOABAOAqgCZYAcAWAY0vIxgigagJAgACBQACEX56ACBwACS153AFAGsSEUvKigqrgAhogg ASgWADAJw2gqgWAGLpgBaGywgG6IgWARWCLyEXAqxWSxaIgHhPAcgdCOBogAAQgAPKFIFXAV gnB6FUq+RBFUugRkubpsgYpYB0k7AAabAWh2pJsA22OYA5aYFVRjrAL/ajB2usRFAJOrUZze UZsIAYRGggAgwWYIgMMrYuANgM1uS+ATASGpsMATAUAMATAZk5ADgY6zgRxJpdP661ABgTgN gU6zgYACgXN1ASgOgRN1APAZABga6ziRRfAeFVO6lXxgxhzmFtA5bGgAA5A4qORfkOu5sJxt tlS+RNbAgZW9gasSMTARxxvFRtbMASsORuxvRzMUgIxuPFu9sTxzu/ABhZBGgjAwhABvhyh+ hAAZgqgSgLgOgTgmgZgBAlBSAxhLBPA+B+g9gSgvgchJBJgnBhBdAyAoA6A4hahfArBhBHgf AsVuBaAPAhAuBCgyhc7fAbDkABg2A/XagSgMASBbg7gzBQgHy0AfhBAmg7hUALB9g3gNhRg8 AnhJAqACKiiRaTEUgP3ggAAWynGmAXiDgPAgGagyAbAEgCAEgFBYAXgBhMAVhdAVhjAVhsgB hpgVh0gCB0gFB9gCB9xZg4ACg4ADQtA/gEBAAChAADBHgDhHkHADxZgVPEAQgGQlZkN6AEAN j/ZRgLxqRptdCDgTAgAUtRgDAHZTxMsnANgTRMgVgWX7EFcDtdCO6JgLpbgTAAQKgUABAUDU Bp6DgTsTABMOgEATgVgUBWAAAUiRAUgYP0gUg4AUgCAUhIS+APj0gnj0hfzPWKAgAXAAAHaF aGAHaHrqAq9K6O9MARUBtu6NAO9LaIgOgNdNAOhPAXHKTSK9FVK+B+9WTVzc2fA4h+r7rAaj B3AuzXgeRErAusOsTjJKL/B2EW9XWvh29hzXsIsK7FqKgIxugbzrAXABbQsNNkNkAZgZ28PB 7O7PgTbQbRAJgR9pCXhRh7gqgngGmWgAgTllh7gGxSAWAYAYh+hdAYAqATAMd3yDLDABh4oM gNG0A1ACgBB+h1glg3h/AagnglASh/ArAzx9AJAMGWgYgQA9b2eIAM+JeGhrAvgsgUESB/hy h/h1AChVcGgTgAhgggAlhFUAAJBHiQgBAgAngauQAAgJAOjBgTgBAWgJgcAJg8AJhMOSABB/ vEAJl9gJZTANgFRqAQ5Rn/pIZRgExMgKZRgNRMgJAJWBNdARAJARAKetl9iDhRSl3r5xNpN3 YXECAEzG2DtuAJApgIgI18AYAIIxgBgIEMhwBae6aI+9h/h6BaaIAq/Ah6BbdNAIBPQIZtgI Afga8qPK8+BQAUhwAUgBAUgJkMABWEMPgQgYARAAhgfRARdPaI6L/CgREMh4DidNARAMgUAw hRdVaWlUuggm9dfczmgVh7FVTU/chzTYdbLBLBB2h2zfgV2oziAAMDgAgc6VFUgDsAsIgug5 IxAUAEgJeNc+TJgcgJAnkbAJT5AtAJA3gAA1AJA9AJBNgAhUgAiphagJBlgAh9ecOTiRMJgu mhxksKJFCALkAAJ/qhZh4JD8BLh/sBZhYGj8JQx0LYLjkAkAODmJv90LKNx2PhuORRbBmMAg MSV/tggA8JRwLTEBBAKjmaygJwxsLIFziGNCfUB/vhahScEAIjkACunU8VgGoU+missgAugM QgEIjQTiYRiMaiEKiMRAcDBUIiOuBQLhYZjMKiEajMZDcbDUIiYTV8RhsAnABj0OCUoC8Atg YFYSBYSPxBBsTE8YP4UC8r40dj0dh0dgUmPwDgMHH0PioSiUaCA5PtEgQiPxe6bUarWANXkU WBMEwMAEh/uECngCmsAAwABsALEgDFLhJUAdUgpUhACHcAnkDocAogDgQhggGigAAMKigDAk MDwPgMXgMBeUIAMQAMYAMgAMCgMkh2GGAIANB+GoQA6IAOgEDoIh4CAEhABIBAeBIPwgBIkg 4MgxgwFYnAgegujkJp2iaCA4hWe0QREAAfnbFgYhgIY8iAGQAg2B4SgWEwNBMCYTAcBgIha5 IAgwFoAgoA8ggACwCyKAIIAUBsjAyAUpACCQEArIQLgJLSqqcqSpqcQIAi6LoAhAAAIggAAQ zTNa8Aus4DTWt67AlNavgEdoAgQAJBn8PR/HWfx0H8QZuF+e5bDcRJHDaWZfnyRI3OKfw3n8 ah/GWfw0ACRwAh4AIhmYWIkkOVB/F4fxaFmRAAhUAIggCLhVkQAAAACABAOCAgCuKAAcAEK4 gAyCRKhYAIH2UAQFgGAAHgI8gUgKFYngCJ4BASCIdFwAIjCAaAbBwGwNAGDYCC+DAvgyL4NC +DYDAKBoCgcAAVGAHQCDoBY6AaOgHDsB44A8OAPjgF44BgRIEEMBZDgaQ4HEIB5DhWVACFQG YIAkBoZgaGgGhqDoZg6GgOhqxAXgEFoCBADwQA+FIUhaGYfACHwBB+AgYAyGAPBgD4YBCHoa B6GokAaJAVCoBYrAaK4ICsFIrBWDoPgCD4BA2GYPhqDYbCoDAqAyKgNCyGQuBmLgaC4GouBs LQbgcAYFgWFIJgWDYUhGBYQB0HYUhgHQ5AkOQJkSEhMAOTAXkyGBUBeYAUGCFRjBXfJ4B0Cg nAQHDlDfrZXgCZ4AgEAI/gD1RdAAXABiWIGRE0GIOA2Do3g+DYPA8XT/deIAaAyTQKBUpweA YBwKAZ5AVgYFQHAIEwE+b54CAMth+1wAwUBiAYRhQCkIFYjIPBEGnVA+EwAhNbwRiACAXgiX 4IgEb4IzQCJXgj+wBgiXAAhDi3A+KwDwK0GgBAS+0IAHxPguACL8Fw7wXD/BcAMFwQAjg1CA C4Z8EYKgABcCAFwMAXDABcAQFwvFvgAIwEZIgAENodQ+F0FYcUQjtDkPQdo/Quw2H6HIHILw VjtRWi0dqDB2gRAkRcrkSwcsSBcCs0oEBiAYAABAdkOknjth1FeLI7Uzoli4O1F6MQgA2BID AA4EwUAmAWCwBIMwAApAeCYGYAQSI9juAcGEcQAAKBaAyOQCwGAsBWCcCAKo7gPAcCk1AEgR xyAQC8A0dyqgQQYDyA0mSolTECmQLoAA5BdCGFgIACQxgLDMA0M4EAxgrAIF0LKZ4bArAAHE rAQwuSmAYAsDADwcs8mADMGEwEvhZK4CMFwAizFpLcBYC4HgBAVAo9cERXywAiAMAcEYEQZz SLsXkGhfQTAkL4DUGgNi7J2BkDYG4AxVglAkF0VgXA0CIBWD4dIvhFhLHeLwHYNAPjDA0BkD oBzUgaCwLUNgfRIg3B0CcfwpBJhMHAK0NgeQcAXA0CEBSlgViHFAF4P4UQfAzCWH0MwbRKBR E0N8BIBQfgeMQNESQkQwCEC0DIMwLAPDDDoIwKgkhpg1AyB8F6uFdAPVwAUV5oEVgDBYLEAQ AghhUCwLQCIBADgYA264cQtADA6BuCgEtYH3gmAiCGED0QMrCBMAIDICADAIRWD+vESiLgQH 6NAaAwAID8r8MAAIL0XgbfeHl+4DQMgJBMDoAIeAAB3BCAUCQHyGDgCAA6YALwIFIAgEEIAK wgBBAGEE/4QBHgfBGDQOwAA8ARD0CIOAKw9AtE0CITIIxTABFMBAVIIRUgiFTbwFoqQXi7BG LsEouwTC6BwLYH4yAIDFA2MUEAyAcjACCNUCQ1QQD5AWPAIIHAJWeBABIEQIASArBQC4F4Lw egQBgBIGAIAdghBsCcGAKwjgAAaBIAAQQQBBBgEEaAQQCDGSMHQFofAXiFBWIkF54CrAMCyC EAYCQRgZBGBYHwPwghLA0EME4BgJAUgcCQFwZQQilxfCcWIBqrVYCACIAgGrRApL3MsCKbYT gbBLVyrwGwNAGA0AislZjJA4riitBg/Ri5TB/lHKYxa9A5TPEoHIObEBLhCYgFqbrPAiTWCI hKuQWkJAMBAA68QNAgA3kYE4LQUAbBODkH4OiSAFACAQDYBVjVeAyCYEQJcmgvBuBsHALQRA QAgCIAILQKOqBaC8iREwBDJCAD4EALwKAg0+C4EOP4UalAAAQAIIgcg4BwCdPVBQMgGXkAgN APwAg/ls6pZYIAAgwVoAEMBgQAiwADYQcAAR4ABAUAF/4+iXhEBAFMEAZD6ggBkAAEQoARAC BE/8YYtrSiWBCGsRSG0ThdQ/DwOI5JQ5VkxJjeEmcsgBIvFCkJpRiRQQ2xIPsVYrp8AgMDgK T+CAQ4FwfhPBeB8M4VwbhwD+JAPCyi8rEpAsCy0+mWZCZkzABDjKUWxiAUgiBeD4AcsuMSnD SCEMgKw3gvDBgrlRUQ5S2BXLqUwDwzAnDSsIFQGCIA/BGBABpRB0BAAmAwHIIwME/Bd0/poS ALA5BMDDqpCyGi26qCIFHVQCWZFl1UClmRbE/Awxwog8AgALJiC0BBMb1kxBwRQWUwAT92mA R0nswAQE87uDkFfgJgA+J4LGYCYUxeL5wVDjiZSsTIACBaaBcwazuBtOIr4JwBgB1pNTypdP MTudUXwE5YwK+fLcBMCfmZ0TY9OWSbetDRhEACCMPIdQtD9F0DoDgFQNgJj4OYfw5M1g2CYP 4D4MwSg+DgEgjI/h6htEwGMAQcwoA7BgNAeIKulgPBd9AcIOQSNxCkAId4/gnC0C+AU1IAQF gJBKBMC4FwIhHVoP4SlEQKggBUAGNSAKAgoUC2ACEoACEOE+DHAABKgsMKCOH8GSACBiBsBQ AqAqJsfuNSAGAeAuCcDSqUAAAmqaFSqggcGqFoAKVyvstSFQQGCABgC8AwC8AyCgBgAIBYAu D2AuDyBMDyBOEWAuESxOAy0ExoAABgAqAOPOBABhBsV+AK9nAsAEAIrY18BIAOBQBOBIrMhG BghdBgCiACCwAOC0A8CwBRBsDmAMDmAODmBQDmBUYUEAACEAAMEIAOEIBQEABUEABgE+BUFG ACFGAEFABgGIA6GqA6HAvuEKAMEOO2BQ86AOa28mdyAgBCBEfSzkA+AAveOUQmRsBCBGA8Aw A6d0nMAw/qmuBMAo1gBMAOAQAQf+04mufA1gBQAwBMAuBeBQj4ARF8K+AwAKA+AgV0AAA+A+ mkAgAeAQLeIYH0Fo9YAECqAsIYHoFo4lGpGsH+HoJeAaAbG2BECAAQQhG0CqgTG6FvHBGoAS FYBA7yIaCAY6QIv4BOCABOCgBODgBOEABOEgBOAO7yAEEwFmBe3MQ2AyQ8hoA0H6eMA0AxIc eMyg3mkw3qy4BzIwEOhQikD6ipI26jI6ioSuByis4Q4MgM4XJO4HJS4MxmxqqyB0seBOPilk ReTKh6lwlwTODkKk50IEAKH+s0Ac6GACBQAkAWB/E9KQB+Aw7s6YAPKeBzHiHQFi6YS+8U46 ACLImam2LaTsLkLoLsLwL0fWnILFK4m0moAudUnEL4BGAGGgACGyA0A0DICkB4H8FyA4BMCk BYH6GAMWMaH8EYCEBeCUAoriCIpoCeB6Rq2YB4A68yNABKBcCsDCH6H6H8FYNoNSNXJ6CCAE BwDIBkBGAUNSBYBYBIC8H8CWACFEC8BcA4BYAzBCA0VwAIFUqgfuAEFoAk6UACJ3HkDEAmA0 BoBwAeBwAgCIAKCUAeEMAIESAaFuASFyAeFyQaBKACCcAACLO2AUDIAIDEAODAAmDoAIDkAO DgAnOgEGAOEAAmFSAAOmFKAaF+dageAUFwAaAoAeAhCiAOP2AGTpCiAWVy1WASAUfDQSASAg AQ2aPKToASgQdcCACABnQeAWm6x+qq9vFjHKAQBAAMBgAMCAAME+AMesA0BeAmB+AmCeAmAG AmAiBkBBGMAgEcAQWMAmDy3KC63QCcHoCaQ+HIQ6C6HMC6kwygCaH6B43hSaAgHMJiiaIuy4 EOijI8GIAAJiIwyyAgGTS/JulCTOBWDk50FoivKuIYHgFkKRP0KKFiKRKydUBCnaBuAuK0Br K2m0m2BGAmAIE0H4EKAEBYEAESLGCAH2FgAGDM/UDYDCLkBMA4NAH2AMDgFWAMH8EyyGGsBe CyD0ACCmIGH+H2H+HIAGFyAKEcSWAABIACGkqpJgFiA8ALGufe0hGoAKeUhgSjHCCqAwAYIY HNGkAnGpWCH+H4FpHYCrWPWTHPWPG8AbVxWYAZFU1SW0J2AGHEKUAolPV8AoAqOSBKASAWBC CyAEAOiKRYB+G6iG3qiEKfXasAGMiEGasPJequlMBNWsPgASAnXATbXOzfXGAXVoAKBMBKhg AZHAANV+JqAhYbWAIYHxWUAbYbWOHcFu0hYuAZYQy5XhXacxY+GbXURaG6GayysOCADyAgfU FIAMFsAMFqAOHUA+V8BMCGAaC6BsBABMDqAGDsAIEMAHI2FMngAQAOCOAOACB0ARFcAaCCAm A8AoCJFUOQ0AAsiuK3XNXQyFXIA8BiA+AKEgAKAEDAAKEAqcP2AKHWAZayhgBIeW6MCgAaDg AaEgAaAIEBbuAaFgAaWfWkAaBAAaBhb6AaGAAaGgAaAOAaP+FuB4BqAaDABKGECWhiQ8BWh6 DkB4RJSgyiRAiJXWhwB+AiIuHqHaH4ACHqjKRkBQAyPqAWAOBMPqZgACA0AUAwA4AAAy6eAY A4ARdrZsTcACAyb1d0A6AMA2TTKwk2kwKek+luTKltJ4CymQnUBkAsmoLQLML6K7LeLOBOBK BmAiAi8onCnQmyLQACB2EKE0EaGkFEEWFWCgFKCsAeBBdyefOCZqDaByC2E6E6DIBqBqBQAE HsFyHiGiHoEqEAB0B0AGFqE4CQA0AgBGDgH6BQH6G4BkBmGQF+FgF6A2AoVyAACNVMAGCUNw TbdUFkAQ1VVjXyCABAAEyOAZWmAMAZHPhxWWAMAsBKQlPIBCDgBCAEBCP+FrGmCqBCP8H+Gp GkApGpiYGUFsAkAliie6AABeHaKcGJcyB+GIT5XgBWGaGJXukgtTDiBaBoAABHZzZ2AuahbK A4AmCoAICmAKCmAMCoAOCwA2CwA4AODOAKDtbQV2BCFouuBAGgBAHAAAHKAKASBuAC/wCsAw CqA4C+BGDAAwDAA4DsAwDkA4EUAkEcAmEgAiEgAwt6FIAEFeBGFmACGCACGOAOGOAyHSAQHI A4HUBAHoSIxoCUAkCuAkEWA+EWBAEABGHgBGSS18F5KEAABBmgA/KEFkAAA6daAGXABhEw2E BCEBiITbEwBABCCgBCDBiEBCEgBCFABCFgBCGABCGgBCHABCHgBCAaBCDMA6G+WWAeGPh8+F iYJ6KRoGCABwJiA6e7XKGYA+AYWwAYEeAYAEAYs9CQAACAAADAAADgAAEgAAFgAA4JkaASBh owN8FUDmA0EGA0AECgA0ACE/pgA0W8AZHmHgAMV0zaANRFRJRNCiCGBECGFyAEEihgQ4Q8Dk DiRERADiH6DiC6HIhtdDi2BWRYHaDjIWhsHIAlXwxsAUCmA6DGA6DmA6AGEmA6V0h6CyByRe 1cBwADrhqgKwACDklEKdTOiuJWq+H+HgFsAmBzAEAgIwP+FlsG7+IaFjsGS+k7eq5A88msAE nQAALteymqLM9hfSmcLgLundhQBKGwEGE4HQdUFoEOFcBiBYB2A8AjQ0BGB8DIB6CiFCESDE CcBufOC4FqGG88G+GwACAcEeCaBMBeBMAqDtGUCUDEFCFIH2CGBcDyN8CJVMV9VVGQAABaAE CXhgxtuJVvGoBSAMAxh4ARh1hsAhGoANmiA6AtV7G2b9VsiVisCqBAAZiTfxWXsQHwCBhyAf GpfxWmBAA4F1W1mu63QbiiA+InW0feAmlOAdGpX+AANS+FNSWfi1XXXaHaBfw0sKKmGBXaGI 4HjFXsv6A3q8lMCkAlwlmiWdAY+EA4DhrSQODAQQaujeBYbqAtYXYtGqAJY3Gqb8ApyABAAI 4lYbhnYZvo1GBTx5YbvDvHx61oBeBdY/jGBXysKcGAGaKdXUG6TMGaRYidXZxKA2IEBeIaFm COCOBoBetSCEBWBcBoDABeD4AID4AKEVb0BeFeckBeAOCABeEAZXiyAsBUAqBWCqAKCqAQCo BWEsAOAOCRaW0+BuAUCOAUCsAUEwAIFOBUFBz+GABeHgBWAE1FmiBCF1mgAXKECACKB4BACe BAC8BADMAUDYBAD0BAE+AAE+BAFUAOFyAOGMBURyAQAmBOAYCCAkA8AmCIAqA6BOAsvKA8A6 CJE7nIAXBxXDwoAOA+WTNSPaAXE7XKAY7+ACDPHmAqDAAsEAAsFeAsAGA+AsEgAsAEAsHWBS CgAMP+FmveBp34IaFugyANueCGD/cuHoKcREh+C6B5SaB54iB4yhdGRbdKByAhdPdSHqiv41 dVdYQCBMlgARfCBMAQBSTSlh5RE8oQ18BUAKBZeWTBeeECKxrfrklCDjrrqgKdeqBK1pe4nQ AknXfRfTfDfGApfMLuAuAKLEAimWLMLQ9ALsAEGOCGEACUEsHAHwGGDyCffuAwA0BWAaK4Ba AeBCAsA2BaAWH8HgBcAMB4DGBeCwCKC2FgDYC2DOCMB6H2ynkmCaFSE7gngqDgH2G6FCCOA4 LWDjAkGwCIDgByCeDQGQGUGuN8CZhOCmAHpDhHrMD7u4lMBQAQAtYBhzvQCqAAR/P9GoR/WW AcAqBhoyTRouPiiuN8P/ifGodbHlfIfp9QAAb0BKAjXSAOzdXR9x9WCrKiIbiRih+U7CH+Gt 9yCr+gGUFvirGoAIBibsiLi4KcC7zEiD++TNjCKdXkBeGaGBXuxphiA6AqEAAAFBpAPKTTpN oyWf9t9r+D+HaQtSBIIAEAgBiqEAOIAOsAOAwABzAB0AB1ABwIB0kBFEBFkBAGBBiCwWBwQF gouH+9CAJgaDYIFAoHw8FQADJXBJmDwfNgcDJxBAcFpqVQcDpgEQkOReKxW3aUwKNSBWzWgz QAP3aXWIXS6KxlVqOL60XWaMRgGyAGQkXwwXQyYAAYAo1gGBQyIA4OQvdhyFiBdw/JmAQAUQ yUNAQHyGDS6Nr+/2AsxQKBpjcCUxULhoGwMGQSWAmXgsXwuWgwWw0BwCAwSBgOCQQDAKFSSB kSAkYBkODEUEEKHVGAlWGFqE2oAmyD20EHoAnmAwmEoeYAQcIgB0SCWCB2QD3hIgIAQODUIA tUun+4AABvOQCUNgSRgERwSTw+VAEVASYgEcgEiQmRIMkyCZSASUgFFwBBagSWAFGOARzgEc AGHoBQKAQaDUIbDABDjDIDoMhBIIkhIDtYPoCAoAAYAsCrACA54crSCo/gqT4Km+CoCAqCoN mm74CJMaBZAoHMgH+dBZAnIqTGwIAkKOjyQC4DYAg2EoIgOA5mJGFANhyB4LACN4LD+CxHgs AYLHolxAAQAIYAQSAEAFOBHgQb4EAGCAECABDpDgBBYAQcAEAMBBVAdHIAESAABAAXABhYIA JBgBwgAcKAHIYBwIAcEFNHgBwAgdFwEsIGgHCGDwhiWDAVic5QVjiOQ5Cafo4h4CB+i6ONeV yq44hWCB2qqdo5KspQVjkCKkC6IYsFkN4KgCLoshWHh+1yeitVmHKyWoAAcBwAFegDZ5aAMA AAgFDgs1nZN4AAOQhi4LBcoaxwgAWEYcgYIAWhyBt/hyBDAFkFAcgPg2EANg0vYUxxZS9guI 4fgwFYJi+E4MBOM3yB2OgqCAMhyutmAaEFmAApQAhXld4ZgpQs5mCYDAuCwZhkGwbguAwDBG EQBBqGgJZzFgShCEwThME2gAMbQAjIMhDi0QoWg+CplEwUp1niWxNGMfpDgCVAC5GMYbCmQY BB2Zg6DoMY8AoRJwgCAJsnW8BllUHQsBIHAgEDRoAB4AFGgOApHAABYAaCJJY3YIYqXsAASX yDqVgEKoJAaBHMiqBoQgwgXNdEnHSgmDDVJMdxaAmCfNASkxwFpz/ZH+axadOKvbmcW3Sd4B oMJMenXdgKvhn+cXagbzXk9p3fkmsWvgAwEFIHEIALieEI3hCP4QgGEIRDfdS3gMAIDCB3eG scW/X80AwRAMCYABeH5rKUsQuggboujtACUlZIzYBFKGaBAYgxilAQBWMRb4KwNixAMAJyQW AgMoAkQIggIYMkDCq+0YAtAlhLIJCAWgQQgwlRcBkG4NyCBAfQekUEEwwPoXSAAED4wDgTdW P8exfYNO8ASCQEbzYgvNJ66AmhLHQPJHgLSILyR7O6Jy8gkw8BblBAwBiIhT4CjNWTF4qL9g fjdGaD8ZqvA5LJgfBAs4kASABDACQOAJI4CgBIPAEgBQQAkCgCQAQQI/SABIYAWYMgZA0kKY 4WYOAdSKkMC0GEkJGAjBLJQwILgMgaBoBgFIHgJhKBEA2T4EglAjBCCcDIQQQAeBCEQBgGQG ATEhDYHLhgRAMh2BIBQkAEgBY6ANgwQwazCXyA8H8xQ1gMJoBkBoJAMBABWDl5JgQNA2keJA DAAQoTbDABgOAGJtCgAwPADABQMCyBGLIUargID2jUUodquVtTyDkVUHgP58rGKeBAeo7R+A BHqUqNqyVqLlDkzMAIMkWAUZ+CIEzQwbATAiBQCzOAKghBqzoGwNQIg0aW00EQBwTglACCkF QOwdgqBUDwHYfgMgxCCP4IYQwXAbASAcDwGgOAoVEBRxNK6Wg8pYDsfwIR+ggCsDkDgJASAa B4FUAIYRKgsBABkB8dFGj/DGP4IwARHgFEe4sAAKQAjEchBRya+gUATCA8ACYH4evFAkBJ2L xHmV3PPFSvSTQJvAAS51z4DQFO7AaY0fwtK6uaMaOyvIVTGjcr5ZBJgQAEvAA+ekFIJ3sBAA YCiywEHNAoBSBYDYzgIP2HbAQpg7QIDWGbAFeEYAVwFKjAgFYxiyAbFsJwDT6QMstRcD8G4N QGgrFkYoG00goArEgCsVADhUAdFACsAwIAV3NEACtPVzgVjQu4BoBAKATggCCCcDwKAiAZrd EECYGgEgqAyBsEAKZdAWFwqOC9qSZgHtOBAB4nwJgBAnfkM4QKiS+mADkAYQAjzFBcCsC4Fw NTMiNB4BoBIk2CiZM8D4HxIAgACA/EQYAQCgBAPAEAAwQAgiC9cf49YLlBBALIFQKxoghnYq 5V49H9KzB4E1XSyQeKwCKGUIg5gm4+WMsMLqxQfg/glWoLAsADDNA2LSWr6QcrGCysOfQOVm ABKeBKaYAJ/0BHqWQIYea3gcA8A4B4HQSgcAeB8DgAc4gbA44YFbLQViBECAEOSvSlLkWrQu htD6Ig0onRXRlEmcs3ZxRyj1IGmNApJSYFC1weArqGIAZAoAthYBiCEDQGwIhhdEC4C1Oad0 9p/WLT9Q8bg8H8CAfgZh1jkCECMEYMgGgHCuCUK4kTbCXBWCGrFWgAgAAi4YAwMABivAAFcA Y060wVe0FlSddgq7ec+BcCLnnmhVAiFUJgMK8O73YP8dUULRBV3eSgB78N6Ar3M5oFYMQbhG 3aA9zXAN4by4G8QIAId8BGCCEcIO+wqhBw1wLiIBpmOaCCEwCli91cBc0Ewk0U3P8g4K8Dkg +iz8X3UArfATAV8T35xYBm/AbxXX07sG4EHP81H+NRfTwAbgc45zwdQQAP8qBuALnYAt8A3A jzDdHMnNARxgOjm/FAQAwc/jAYXP95ggBVxzGA2l9cqBB0rc+MB+L63wCACwGQXgyCKEizoI AjhUCrZ7mYVQX1SCeFUN4VQ/hVAGFUKwBgjgxAwCUFhIQeAsAKAfKA7QX+VjKVq24/Rgeb83 bJmNtLbQDKV6EqKyRiW4gX6eBqyQIDGgZA4GBSoIwT24DzxgC/HgFJD5HvAVgDgYBiEcCIAo g9UAJi+60SQV/Eg8CsG8KYkhB+YQTjOMB1RZiZi0LHPB8byIJ9yKn3yTDy+x98G4WOSOtiTy SJ8QeSD4/LuoJgWQsRiKUsyAv+FhW0Ah/z0p+zyyMzKJYZYZb4WABoJZyYX4AAIxI4AAIsBw F8BwGBI4WoDQDADKLYDBcUDhcQLIswDgGgA4aALId5NAQALLMgLIMC5QFYBoAISEFIEABC+o Dx4YAQfgWgEQG6T4GIXEHBfQEQJiT4I6UQCKT4C5SABwWgEYFaT7dgAYBsJgIKT7gEKIIAHw EYKoE4JoIIKgDwKoIgBAFIG4JoIAHIFIFABAhoEoI4KwK4A73LxgBgBQkIAwAjyII4IwsgDA C4BQLLCYDQCACIEgEIGDEQOAEAWDs564AIGp9cHjCJv4GAG4AIOAG4WDpLmsRwIACwJoK4II EgJgJgD4JoKAJoAQQAJoSEVAADIUVAJowAWyiwGgJoMALALMH4LQWYEIUwP54ZqIQopQJzHy NTIJXRbTIAfocg5UZTIrI7JKfAHkaafMaafTIK1wdqfQowC4HLMgo7NCgCgRmLNjNwCgEQEg ngBoEoEYE0dIELPLOQEQBzOploAICDT4pTQTQgAArYAJXqhRnYGwGxowC8gcgpFiirSgGajI GpnIG8gTS5pZpxLLciiyjCjRnUiEiSkREoA6iqi8hkjMgcjkjqkoGabgMgCQFoNAGYKwPgCo M4RwJYJIOIEIoABQGwHofwHgCYHYEMPwAgDYE4KwGoNYJhdgCoHQIwfwGIJgHIBYAoEIFgJ6 joKYFqmIJYfwHYH4GS+CnSngE4B4AICj5YdgMgB4EwFQMgL4PCEYKoHQPgfwOwKztwD6pwC4 CAEYCIKAAIRQOAFwIAGoJABYFYfwJYLwF0u6pwEgCIKUvwOAGIIADoFgG4fwCoLQGwDapwDY HaqQLwS4FjZirIOB8wBhwwAYe7aoAAGYATbRyKtYC8R7jgGABh4AGM2zeYBwBBMAEYkzooFx 4AEYDoEgFIBDiABDqBQrlQkYEjjgCwDRz4CyWZ46/Ak6yc6wbzgwKs6wdwlLlQCwAADrqADr iADrqQKoDoFIDDjgFIBzfAFJ1k7c+If6J53c+jkTc8+jlABTlQFIAADgAQEkKB7IBMySy5zQ GLYQXwAYcQAACFBpxtCIEtBqywEirIGQA4DQFgATyQqwH7ypYYdodgdh/oFYdop8bz0gpgpr 0i2hYT04YlGCBAshZL2bKgIALwF4CyIM2qIIGNHiD1AFAQGFBVDVDgA6rI14oJOaIJQqJIkb tAggCz6c7k3iKqi5oc8SJYgk8qJIDtKs9SK55ggk+j9qD0+j8iJIFIFJob+wpZZIpwr70TQ7 y0bSM1FKgoswHUR4FQGoBAGsFgxYGAGoKFQIGoOAGoSAGoAoFo78wQMFRAGoQFRQGoWAGoA1 S4aAGoAVS6OVSYGoYCYs8oCyT4B5SAB4IACIEVNgDwEiUUMbOKU89QD03wAZSwFwEYGIE4FQ IIGADwGIIjPrYIGdI9DqIgEYnABwBRm4EgA5OQAJQTEY6YBAT4BAZ85JgoAQXoIADYFIGc4g FQD4FIKAFIMAFIOAFIAgQAFISAFIWAFIhgFICAFIAU+gwIBMWlcwGkXydwewFcYxbJXVgJwq fUfEfFD4HhZgHLNMcaNgGDNpScDAAcO4EoDIAYC7PIAoAyc6nke0fEfTQZXig8frQhmUFMgi hhm4CshUkMhpnMiKj8jtlsjEhxnTS7TKkck4AIJYUISQJYNjtwBwBYGIIUratwGYBQAgIIJo O4OwBYBwGMrQHYCkPbO8sMscsoAQdoYQJYKwHkuQPIK4D4DKpoEhpYB4J4AIO4PoOIQQfwDo LoCwDszYEgI4MgAIKgUoJADU0hwcCAcgAYXM1YB88QAQBjbatYDgCgBgAx4CZh3bCzc82wkB zQBgDRIx4p4FzJF9yoKoAgnjigAgC4EoBABYCAEohrybzwqK2wsYsrKbbiy91IA90l0wDThA DYoNzFxgoNxjACKs2woIBhIweBfQoIAgAgDyZgoor7/SBj0r/pl1D4dq3YIAIoCQQBaYU4Cw WwCwYoAIZIBIYgDobI1YCQc4BQAIJABIIoCwK4CoQoAIRgBIRIB4bIDYA4D4IAGQGoAgxC5Q T4D4AIYwCoZIDSQOAYJIBF1Aht2wBYCRIwwIFYCQBYH4J9R474aGDIKAAgMAAgOAAgSAAgWA AkO4dhf2CoH6zwT7mYBhVRVhVxWAeiNYJoq6eIJYWAFAKeHIKAKILQWIBgDxx4D4AgJIKQLQ LAXomYxwAAAmJoD4x0DgLJZ4XgAADQAYGWJwAACmLIdICAdIDeK2LGLQAmLmLMbILLyccoIA GwAIDoCQEoBwEwATOoEwBQEoAwEwCIB4CgEE8QAIDTETV+PwAADFDTEQCYBoCDEQDZPTEQCo BYvIAADIAuSZeDQBmMfTQkf6NZWRahcyCwCIOoAQOoAwPQBQPQBwPQCQPACwOoDAOoDgBBar J5ZxeqywDkQYHIDeXZFs+oWIBaW5ZJmcFIGVlahyh5paiQGwC5+YAwCrjdmBoZpZRwaAPwNY OwZ4P4Z4PQM4PoZgKcowIQT4QQMIPwNII7aoTwQ4V4PYfgQAUoRYVoPwfIO4IIH4TwPgZAfw bwUAYYegRgtx8wCgf4eIAQHgAgYIABKgftxKCwEoDpSZ4+iR4ABYBk9jcABgCrAYAp1LjgCc 9547Aof77p3ekh4pz+kl403JzQCYBYBAFhMAChIBKoWRdRdKNAfoqYF4doYl1gpQboYD1opN 172V2KtYDIC83NKepgKoCup06aIIDYkwdD7wKt3BI+q4DOqoIACiIIOABYAIBYB5KgCoNICg AIJOtOmi/MEB9OmIB4BZKgAtKoAtK4ggAtLgKuj0+S91MaJOkgfT+J14DoDlN9Fi74qlD+nY rWoaA4rKgrQ72Re4BpI4IAIIBgHIL4AIL5dgH4DoTICITIDIX4CoX6/ADIdADIA4T4DoAIRK 34J4BgJ4BoL4BgL4Boeqc9jgCoDAE51RFkDGLAAO4YAYCgDYUA1ICoGGmut4AYGBdh9IBlP+ mQBYCwZ5G4Cod4CoAYCoMu5AZhxa/IdgICqwBgAIBgFwF4DoWFMADpdQAN5IAoEgCgKDAYQD AYACv4CYWACYYACYaACYcBmoCYMADgVYRNf1glg5XILpbcbI5QLtgsZdg0bNgQcjMkbraEbo o4sjRGTrJ6NahQCMhkvai1mAG4GZnxoBpijwEYGsgciESoJQawawGYFAEIHwCIE4EYQAIgFw LAFQSIG4OYFoC9dQYIfwaYIwfoVwLIH0NIMQMYGYL4MYAQNEm4NIJAEwMpwzZ4AQf9wIfoAY SgAAEpOmh8ToE7b5zRNziGsYEAFDsQkztesjrADzrYkwchF54AEC8Rz4DQCToTcACQk2kzin Qwf4fSx/RQeh6jeYCQEgXVCIC9CoBzxYAwBZT4DAA0yloYkQwBBTeYBABR+wpiM8bQo4HIH5 YYdmoCMC2wYApj2CCGpCC0OBPpP5PPUvTYBYDABwEgEoC/TPTvT4kAAOBiDwAKwqKu9IoIAP P7iYglzCIIDQBV3YCU44E0GaJIEAAzGgEAE3RQeWq/RSKaJPc7+KuppdN7/QFb/F6SBdF4YD KHVqA4ZtFLy914swGoAIE9QQGwEHgAE4OAE4WAE4AgGgBYG4D4HQEAJAD4JAEAAq8QCYJ8G3 HoEPjAEvHoBAE4AIIKnQBAIgEABeiJgoAIIpF/UwEti0DPTwFgocOsOoBYEMRrA4BwAAWBu0 sYOAAIT4AIZ++QAMH9bgEoCSTc5wCW+4SB2G/Pp2/whm/gEG/u//APAoMAEwYUX5V/CTIDIV gRXZXBbKeifDMCelg9FHVdhqgbftiDNwCDPgB4CLOynlB4COXuwxlce7T7QVkorfEki8h4C4 AvGHFiiCiNmQEwA4GoEMkHFNmQE6YoMYB8m4D4E4BwfwdwFoOwPgIoJoOIFgDgG4JHkILIH4 FYNoJYHILXMofoaoT4I+w4EYOIYQQAIQLIRgQAAITIIIGRKgEofoTYQAKAG0pAA4JzpN1Jwx wwHYAH5/6P6H6f6X6v6n6/636QVoAISoAQQkKP8ABv8P8f8X8v8gAgKIAocf9X9gcYAwXf9/ +P+H+f+QA4bABAM3/H/QMwBIcf/ogAJccCgQLb4NCQNW8KhkLh0NBzZCAICJxCZhi8ZMIUXg VbsejwYIQZewbFkmlEnFgcK4dVMumEvmUxmkzm01nE3nU5nk7n09oE/oVBolDo1FpFHpVJpl Lp1NqFPqVRqlTq1VrFXrVZrlbr1dsFfsVhsljs1ltFntVptlrt1tuFvuVxulzu11vF3vV5vl 7v19wF/wWBwmDw2FxGHxWJxmLx2NyGPyWRymTy2VzGXzWZzmbz2d0Gf0Wh0mj02l1Gn1Wp1m r12t2Gv2Wx2mz2213G33W53m73294G/4XB4nD43F5HH5XJ5nL51NAHR6ICAAB6XRCgAAfXAI a6IBA3SEhYK5SKJQJhGAYpGJHJA8GwWHY9CgVC4yIpNEvX/n9/z/wBAMBQHAkCwNA8EQTBUF wY/oCAAKTpQfB7rAAeAMn+f7ongAMMuk60HuiEgACwAArwgAAogAKAACYAAjO0AAUgAGIACO AAkAAHgABsAALAAHYAB6ADsgqAALgAGQACKAAmgA/bvgACQAOo6jovCB7oioNI2jKOYQCcMo 7hAKQ3jaMI3O475IAAAoAARBsEThAh4QtDUBwq64DByAIOT3Ps/g5K0qOlQdDULRDp0TQlFU bRlH0PR0QnhEIWRCKcQhBTNNujTVO04AFPVDUFRVLTICmOAAIAKKwABFVlXVhV9WhEAg5gAE NbVxXVc1vXtd19XleVQf5zVRHFjiRZNk10QFm2fW9nWjY4H2OCYCHGAANWxbVuW3bNv27cFv XIAB/n4AZGxfEIiXTFt3CZeF4AEHMdXof4yXvfIc3xPYAAjEIGRCIuB4K6OCYPekiRC6jtzi /08gKGYZliWBXl0L4Hh4eoEAzObpFEcYOmE65njqMIbn2Oh+kYCE3gc6QEuq/qAgCmVuZHN0 cmVhbQplbmRvYmoKMiAwIG9iago8PC9Qcm9kdWNlcihHUEwgR2hvc3RzY3JpcHQgOC42MykK L0NyZWF0aW9uRGF0ZShEOjIwMTYwNzEyMDQyMDEwKzEyJzAwJykKL01vZERhdGUoRDoyMDE2 MDcxMjA0MjAxMCsxMicwMCcpCi9UaXRsZShNaWNyb3NvZnQgUG93ZXJQb2ludCAtIEFGLUFT QS1PYmoucHB0KQovQ3JlYXRvcihQU2NyaXB0NS5kbGwgVmVyc2lvbiA1LjIuMikKL0F1dGhv cihicmlhbik+PmVuZG9iagp4cmVmCjAgMTIKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMDAx Mzk0IDAwMDAwIG4gCjAwMDAwMjQ0NzQgMDAwMDAgbiAKMDAwMDAwMTMyNSAwMDAwMCBuIAow MDAwMDAxMTgzIDAwMDAwIG4gCjAwMDAwMDAwMTUgMDAwMDAgbiAKMDAwMDAwMTE2MyAwMDAw MCBuIAowMDAwMDAxNDcxIDAwMDAwIG4gCjAwMDAwMDE4NjYgMDAwMDAgbiAKMDAwMDAwMTQ0 MiAwMDAwMCBuIAowMDAwMDAyMDg3IDAwMDAwIG4gCjAwMDAwMDE3MjAgMDAwMDAgbiAKdHJh aWxlcgo8PCAvU2l6ZSAxMiAvUm9vdCAxIDAgUiAvSW5mbyAyIDAgUgovSUQgWzxFODUwOTRD ODJCOUFENDVDOUE0MTBDMDhCQzA4OUM1Qz48RTg1MDk0QzgyQjlBRDQ1QzlBNDEwQzA4QkMw ODlDNUM+XQo+PgpzdGFydHhyZWYKMjQ2OTUKJSVFT0YK --------------5B16F3D677FF6A5BF85CF188 Content-Type: application/vnd.ms-powerpoint; name="AF-ASA-Obj.ppt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="AF-ASA-Obj.ppt" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAAQAAAAAA AAAAEAAADQAAAAEAAAD+////AAAAAAAAAAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////9////FwAAAAMAAAAEAAAABQAAAAYAAAAHAAAA CAAAAAkAAAAKAAAACwAAAAwAAAD+/////v///w8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUA AAAWAAAA/v////7///////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////1IA bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAWAAUA//////////8BAAAAEI2BZJtPzxGG6gCqALkp6AAAAAAAAAAAAAAAAGBU VMyP29EBDgAAAMAQAAAAAAAAUABvAHcAZQByAFAAbwBpAG4AdAAgAEQAbwBjAHUAbQBlAG4A dAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgECAAAAAwAAAP////8AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAyxQAAAAAAAAFAFMAdQBtAG0AYQByAHkA SQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQQA AAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwDgAA AAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkA bwBuAAAAAAAAAAAAAAA4AAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAOgAAAOgBAAAAAAAADwDoA1kDAAABAOkDKAAAAIAWAADgEAAA4BAAAIAW AAAFAAAACgAAAAAAAAAAAAAAAQAAAAAAAAEPAPIDFgEAAC8AyA8MAAAAMADSDwQAAAABAAAA DwDVB0wAAAAAALcPRAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAA2EAxAGTa GABM2hgAdscLMAgAAAAAAAAAZNoYACjdDTAAAAQAAACkDwoAAACAAGAAAAAAAAAAAAClDwwA AAAAAAAILgAAAAcAAAAAAKkPCgAAAAcAAAAAAAkIAABAAKMPbgAAAAUA//0/AAAAIiAAAGQA AAAAAAAAZAAAAAAAAAAAAEACAAAAAAcAAAD//+8AAAAAAAAAAAD//xgAAAAAAQAAAAUAACAB IAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAADwALBHQAAAAPAADw bAAAAAAABvAgAAAADwgAAAMAAAATAAAAAgAAAAEAAAAHAAAAAgAAAA8AAABjAAvwJAAAAIEB BAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACEAAHvEQAAAABAAACAEAAAgCAAAI 9wAAEB8A8A8cAAAAAADzAxQAAAACAAAAAAAAAAAAAAAAAACAAAAAAA8A0Ac3AQAAHwAUBBwA AAAAABUEFAAAALoddewAypo7Mk7NyQDKmjsBAQABDwD6A2cAAAAAAP4DAwAAAAABAAAA/QM0 AAAAQwAAAGQAAABDAAAAZAAAAHbHCzAIAAAAAAAAAFjaGAAAAAAAAAAAACT9//+m////AQAA AHAA+wMIAAAAAAAAAHAIAABwAPsDCAAAAAEAAABACwAAHwAHBDwAAAAAAP0DNAAAACEAAABk AAAAIQAAAGQAAABg8w0wFN4YAAAAAADEQTEAAAAAAAAAAAAAAAAAAAAAAAAAGAAfABMEPAAA AAAA/QM0AAAAZAAAAGQAAABkAAAAZAAAAGDzDTAU3hgAAAAAAMRBMQAAAAAAAAAAAAAAAAAA AAAAAAAYAB8A/wMUAAAAAgAABAwAAAAAAAAAAAAAAAIAAAAPAPAPHAAAAAAA8wMUAAAAAwAA AAQAAAAAAAAAAAEAAAAAAAAAAOoDAAAAAA8A+AN4CAAAAgDvAxgAAAABAAAAAQIHCQgAAAAA AAAAAAAAAAAAAABgAPAHIAAAAAAA/wD///8AAAAAAP//AAD/mQAAAP//AP8AAACWlpYAYADw ByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAGAA8AcgAAAA////AAAAAAAz MzMAAAAAAN3d3QCAgIAATU1NAOrq6gBgAPAHIAAAAP//zAAAAAAAZmYzAICAAAAzmTMAgAAA AAAzzAD/zGYAYADwByAAAAD///8AAAAAAICAgAAAAAAA/8xmAAAA/wDMAMwAwMDAAGAA8Acg AAAA////AAAAAACAgIAAAAAAAMDAwAAAZv8A/wAAAACZAABgAPAHIAAAAP///wAAAAAAgICA AAAAAAAzmf8Amf/MAMwAzACysrIAAACjDz4AAAABAP/9PwAAACIgAABkAAAAAAABAGQAAAAA AAAAAABAAgAAAAAHAAAA///vAAAAAAAAAAAA//8sAAAAAAMAABAAow98AAAABQD//T8AAQAi IAAAZAAAAAAAAABkABQAAADYAAAAQAIAAAAABwAAAP//7wAAAAAAAAAAAP//IAAAAAABAACA BQAAEyDUASABAAACABwAgAUAACIg0AJAAgAAAgAYAIAFAAATIPADYAMAAAIAFACABQAAuwAQ BYAEAAAAACAAow9uAAAABQD//T8AAAAiIAAAZAAAAAAAAABkAB4AAAAAAAAAQAIAAAAABwAA AP//7wAAAAAAAAAAAP//DAAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANg AwAAAAAABQAAgASABAAAAABQAKMPUgAAAAUAAAABCQAAAAABAAAAAAAAAAEAAQkAAAAAAQAg AQAAAAACAAEJAAAAAAEAQAIAAAAAAwABCQAAAAABAGADAAAAAAQAAQkAAAAAAQCABAAAAABg AKMPDAAAAAEAAAAAAAAAAAAAAHAAow8+AAAABQAAAAAAAAAAAAIAHAABAAAAAAAAAAIAGAAC AAAAAAAAAAIAFAADAAAAAAAAAAIAEgAEAAAAAAAAAAIAEgCAAKMPPgAAAAUAAAAAAAAAAAAC ABgAAQAAAAAAAAACABQAAgAAAAAAAAACABIAAwAAAAAAAAACABAABAAAAAAAAAACABAADwAM BLIEAAAPAALwqgQAABAACPAIAAAABgAAAAYEAAAPAAPwQgQAAA8ABPAoAAAAAQAJ8BAAAAAA AAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAABAAABQAAAA8ABPDAAAAAEgAK8AgAAAACBAAAAAoA AJMAC/A2AAAAfwABAAUAgABAbTEAhwABAAAAgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEB AAkAAQICAAAIAAAQ8AgAAACAAbAB0BRQBA8AEfAQAAAAAADDCwgAAAAAAAAAAQAxAA8ADfBC AAAAAACfDwQAAAAAAAAAAACoDyAAAABDbGljayB0byBlZGl0IE1hc3RlciB0aXRsZSBzdHls ZQAAog8GAAAAIQAAAAAADwAE8AQBAAASAArwCAAAAAMEAAAACgAAgwAL8DAAAAB/AAEABQCA AFCSMQCBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAOAEsAHQ FAAPDwAR8BAAAAAAAMMLCAAAAAEAAAACADEADwAN8IwAAAAAAJ8PBAAAAAEAAAAAAKgPUgAA AENsaWNrIHRvIGVkaXQgTWFzdGVyIHRleHQgc3R5bGVzDVNlY29uZCBsZXZlbA1UaGlyZCBs ZXZlbA1Gb3VydGggbGV2ZWwNRmlmdGggbGV2ZWwAAKIPHgAAACEAAAAAAA0AAAABAAwAAAAC AA0AAAADAAwAAAAEAA8ABPC2AAAAEgAK8AgAAAAEBAAAAAoAAIMAC/AwAAAAfwABAAUAgAAE mjEAgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAABgD7ABYAaA EA8AEfAQAAAAAADDCwgAAAACAAAABwExAA8ADfA+AAAAAACfDwQAAAAEAAAAAACgDwIAAAAq AAAAoQ8UAAAAAgAAAAAAAAAAAAIAAAAAAAIADgAAAPgPBAAAAAAAAAAPAATwuAAAABIACvAI AAAABQQAAAAKAACDAAvwMAAAAH8AAQAFAIAAjJkxAIEBBAAACIMBAAAACL8BAQARAMABAQAA CP8BAQAJAAECAgAACAAAEPAIAAAAYA+wB9AOgBAPABHwEAAAAAAAwwsIAAAAAwAAAAkCMQAP AA3wQAAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPFgAAAAIAAAAAAAAIAAABAAIAAAAA AAIADgAAAPoPBAAAAAAAAAAPAATwuAAAABIACvAIAAAABgQAAAAKAACDAAvwMAAAAH8AAQAF AIAA0KkxAIEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAAEPAIAAAAYA8g ENAUgBAPABHwEAAAAAAAwwsIAAAABAAAAAgCMQAPAA3wQAAAAAAAnw8EAAAABAAAAAAAoA8C AAAAKgAAAKEPFgAAAAIAAAAAAAAIAAACAAIAAAAAAAIADgAAANgPBAAAAAAAAAAPAATwSAAA ABIACvAIAAAAAQQAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgAS AP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ ALKysgAgALoPHAAAAEQAZQBmAGEAdQBsAHQAIABEAGUAcwBpAGcAbgAPAO4DpggAAAIA7wMY AAAAEAAAAAAAAAAAAAAAAAAAgAAAAAAHAAAADwAMBFYIAAAPAALwTggAACAACPAIAAAADQAA AA4IAAAPAAPw5gcAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAA CAAABQAAAA8ABPCuAAAAMgAK8AgAAAACCAAAAAoAAKMAC/A8AAAAfwAAAAQAgADMDE8DggAw KgAAhQACAAAAgQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgAAAAg AVABMBXwDw8ADfBCAAAAAACfDwQAAAAEAAAAAACoDxIAAABBdXRvbm9taWMgRnVuY3Rpb24A AKEPFAAAABMAAAAAAAAIAAABABMAAAAAAAAADwAE8JwAAAAyAArwCAAAAAcIAAAACgAAkwAL 8DYAAAB/AAAABACAAFTHTwOFAAIAAACHAAIAAACBAQAAAAi/ARAAEADAAQEAAAj/AQgACAAB AgIAAAgAABDwCAAAAOAEMAxAFPAJDwAN8DYAAAAAAJ8PBAAAAAQAAAAAAKgPBgAAAE5vZGUg WQAAoQ8UAAAABwAAAAAAAAgAAAEABwAAAAAAAAAPAATwmgAAADIACvAIAAAABAgAAAAKAACT AAvwNgAAAH8AAAAEAIAATFlPA4IAMCoAAIUAAgAAAIEBBgAACL8BEAAQAMABAQAACP8BCAAI AAECAgAACAAAEPAIAAAAQAWwDeAQEAgPAA3wNAAAAAAAnw8EAAAABAAAAAAAqA8EAAAAQVNB MwAAoQ8UAAAABQAAAAAAAAgAAAEABQAAAAAAAAAPAATwnAAAADIACvAIAAAACAgAAAAKAACT AAvwNgAAAH8AAAAEAIAA1LhPA4UAAgAAAIcAAgAAAIEBAAAACL8BEAAQAMABAQAACP8BCAAI AAECAgAACAAAEPAIAAAAIASgAgAMMAkPAA3wNgAAAAAAnw8EAAAABAAAAAAAqA8GAAAATm9k ZSBYAAChDxQAAAAHAAAAAAAACAAAAQAHAAAAAAAAAA8ABPCcAAAAMgAK8AgAAAAJCAAAAAoA AJMAC/A2AAAAfwAAAAQAgABU3k8DhQACAAAAhwACAAAAgQEAAAAIvwEQABAAwAEBAAAI/wEI AAgAAQICAAAIAAAQ8AgAAAAgChAIIBDQDg8ADfA2AAAAAACfDwQAAAAEAAAAAACoDwYAAABO b2RlIFoAAKEPFAAAAAcAAAAAAAAIAAABAAcAAAAAAAAADwAE8JoAAAAyAArwCAAAAAYIAAAA CgAAkwAL8DYAAAB/AAAABACAAMS6TwOCADAqAACFAAIAAACBAQYAAAi/ARAAEADAAQEAAAj/ AQgACAABAgIAAAgAABDwCAAAAOAEIARQB7AHDwAN8DQAAAAAAJ8PBAAAAAQAAAAAAKgPBAAA AEFTQTEAAKEPFAAAAAUAAAAAAAAIAAABAAUAAAAAAAAADwAE8JoAAAAyAArwCAAAAAMIAAAA CgAAkwAL8DYAAAB/AAAABACAAFw2MQCCADAqAACFAAIAAACBAQYAAAi/ARAAEADAAQEAAAj/ AQgACAABAgIAAAgAABDwCAAAAOAEsAfgCoAHDwAN8DQAAAAAAJ8PBAAAAAQAAAAAAKgPBAAA AEFTQTIAAKEPFAAAAAUAAAAAAAAIAAABAAUAAAAAAAAADwAE8JoAAAAyAArwCAAAAAUIAAAA CgAAkwAL8DYAAAB/AAAABACAAAxkTwOCADAqAACFAAIAAACBAQYAAAi/ARAAEADAAQEAAAj/ AQgACAABAgIAAAgAABDwCAAAAFAK4AoQDiANDwAN8DQAAAAAAJ8PBAAAAAQAAAAAAKgPBAAA AEFTQTQAAKEPFAAAAAUAAAAAAAAIAAABAAUAAAAAAAAADwAE8JsAAAASAArwCAAAAAoIAAAA CgAAkwAL8DYAAAB/AAAABACAAAQHTwOFAAIAAACHAAEAAACBAf//mQC/ARAAEADAAQEAAAj/ AQgACAABAgIAAAgAABDwCAAAAJAGQA5QEIAHDwAN8DUAAAAAAJ8PBAAAAAQAAAAAAKgPBQAA AE9iaiBBAAChDxQAAAAGAAAAAAAACAAAAQAGAAAAAAAAAA8ABPCbAAAAEgAK8AgAAAAMCAAA AAoAAJMAC/A2AAAAfwAAAAQAgADI2k8DhQACAAAAhwABAAAAgQH//5kAvwEQABAAwAEBAAAI /wEIAAgAAQICAAAIAAAQ8AgAAADQC3ALgA3ADA8ADfA1AAAAAACfDwQAAAAEAAAAAACoDwUA AABPYmogQgAAoQ8UAAAABgAAAAAAAAgAAAEABgAAAAAAAAAPAATwmwAAABIACvAIAAAADQgA AAAKAACTAAvwNgAAAH8AAAAEAIAAmFpPA4UAAgAAAIcAAQAAAIEB//+ZAL8BEAAQAMABAQAA CP8BCAAIAAECAgAACAAAEPAIAAAAMAawBMAGIAcPAA3wNQAAAAAAnw8EAAAABAAAAAAAqA8F AAAAT2JqIEEAAKEPFAAAAAYAAAAAAAAIAAABAAYAAAAAAAAADwAE8JsAAAASAArwCAAAAA4I AAAACgAAkwAL8DYAAAB/AAAABACAAPgKPAKFAAIAAACHAAEAAACBAf//mQC/ARAAEADAAQEA AAj/AQgACAABAgIAAAgAABDwCAAAADAGQAhQCiAHDwAN8DUAAAAAAJ8PBAAAAAQAAAAAAKgP BQAAAE9iaiBCAAChDxQAAAAGAAAAAAAACAAAAQAGAAAAAAAAAA8ABPBIAAAAEgAK8AgAAAAB CAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJ AAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAAAAchcQ AAAAAQAwAAAAAABhAwAA4QsAAAAA9Q8cAAAAAAEAAJwKAAMAAAAAjxQAAAEAAAADAAAAAQB8 dQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQA AAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAA EgAAABMAAAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAAdAAAAHgAAAB8A AAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsAAAAsAAAA LQAAAC4AAAAvAAAAMAAAADEAAAAyAAAAMwAAADQAAAA1AAAANgAAADcAAAA4AAAAOQAAAP7/ //87AAAAPAAAAD0AAAA+AAAAPwAAAEAAAABBAAAA/v////7///////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////v8AAAYBAgAAAAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQq5EIACsn s9kwAAAAQA4AAAsAAAABAAAAYAAAAAIAAABoAAAABAAAAIgAAAAIAAAAmAAAAAkAAACoAAAA EgAAALQAAAAKAAAA1AAAAAwAAADgAAAADQAAAOwAAAAPAAAA+AAAABEAAAAAAQAAAgAAAOQE AAAeAAAAGAAAAFBvd2VyUG9pbnQgUHJlc2VudGF0aW9uAB4AAAAGAAAAYnJpYW4Ab2keAAAA BgAAAGJyaWFuAG9pHgAAAAIAAAAxAGlhHgAAABUAAABNaWNyb3NvZnQgUG93ZXJQb2ludABv bgBAAAAAINeMEgAAAABAAAAAUMLCuY/b0QFAAAAAcJlPzI/b0QEDAAAAFAAAAEcAAAA4DQAA /////wMAAAAIAIkQZwwAAAEACQAAA5QGAAAGACIAAAAAABEAAAAmBg8AGAD/////AAAQAAAA AAAAAAAAwAMAANACAAAJAAAAJgYPAAgA/////wIAAAAXAAAAJgYPACMA/////wQAGwBUTlBQ FACsADEAMgAAAP//TwAUAAAATQBpADEACgAAACYGDwAKAFROUFAAAAIA9AMJAAAAJgYPAAgA /////wMAAAAPAAAAJgYPABQAVE5QUAQADAABAAAAAQAAAAAAAAAFAAAACwIAAAAABQAAAAwC 0ALAAwUAAAAEAQ0AAAAHAAAA/AIAAP///wAAAAQAAAAtAQAACAAAAPoCBQABAAAAAAAAAAQA AAAtAQEABAAAAC0BAAAJAAAAHQYhAPAA0ALAAwAAAAAEAAAALQEAAAcAAAD8AgAA////AAAA BAAAAC0BAgAEAAAA8AEAAAgAAAD6AgAAAAAAAAAAAAAEAAAALQEAABAAAAAmBg8AFgD///// AABHAAAAjwIAABEBAADBAgAACAAAACYGDwAGAP////8BABwAAAD7AgAAAAAAAAAAAAAAAAAA AAAAAAAdInaAASZ2iA8KDTCvRQDszBgAcJMidoABJnbnDWY0BAAAAC0BAwAFAAAACQIAAAAC BQAAABQCAAAAAAUAAAACAQIAAAAQAAAAJgYPABYA/////wAARwEAAI8CAAB5AgAAwQIAAAgA AAAmBg8ABgD/////AQAFAAAACQIAAAACBQAAABQCAAAAAAUAAAACAQIAAAAHAAAA/AIAAADM mQAAAAQAAAAtAQQACAAAAPoCAAABAAAAAAAAAgQAAAAtAQUABwAAABgEqQKJAzAAOAAEAAAA LQECAAQAAADwAQQABAAAAC0BAAAEAAAA8AEFAAUAAAAJAgAAAAIFAAAAFAIAAAAAHAAAAPsC 4P8AAAAAAACQAQAAAAAAQAAAVGltZXMgTmV3IFJvbWFuALjGGABwkyJ2gAEmducNZjQEAAAA LQEEAAQAAADwAQMABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAACIA AAAyCqwAWwESAAAAQXV0b25vbWljIEZ1bmN0aW9uFwAPAAkAEQAPABEAGAAJAA4ACAATABAA DwAOAAkACQAQAA8ABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAAAgECAAAABwAAAPwCAAD///8A AAAEAAAALQEDAAgAAAD6AgAAAQAAAAAAAAIEAAAALQEFAAcAAAAYBKkBYQPQAAgCBAAAAC0B AgAEAAAA8AEDAAQAAAAtAQAABAAAAPABBQAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAJAgAA AAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAQAAAAMgp9AYICBgAAAE5vZGUgWRcA EAAQAA4ACAAXAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAIBAgAAAAcAAAD8AgAAzMz/AAAA BAAAAC0BAwAIAAAA+gIAAAEAAAAAAAACBAAAAC0BBQAHAAAAGARZAdEC4ABIAgQAAAAtAQIA BAAAAPABAwAEAAAALQEAAAQAAADwAQUABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAACQIAAAAC BQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAADQAAADIKEQFkAgQAAABBU0EzFgATABYA EAAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAACAQIAAAAHAAAA/AIAAP///wAAAAQAAAAtAQMA CAAAAPoCAAABAAAAAAAAAgQAAAAtAQUABwAAABgEiQEBArAAcAAEAAAALQECAAQAAADwAQMA BAAAAC0BAAAEAAAA8AEFAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAAkCAAAAAgUAAAAUAgAA AAAFAAAALgEYAAAABQAAAAIBAQAAABAAAAAyCl0BBgEGAAAATm9kZSBYFwAQABAADgAIABcA BQAAAC4BAQAAAAUAAAACAQIAAAAFAAAAAgECAAAABwAAAPwCAAD///8AAAAEAAAALQEDAAgA AAD6AgAAAQAAAAAAAAIEAAAALQEFAAcAAAAYBHkCsQKwAVgBBAAAAC0BAgAEAAAA8AEDAAQA AAAtAQAABAAAAPABBQAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAJAgAAAAIFAAAAFAIAAAAA BQAAAC4BGAAAAAUAAAACAQEAAAAQAAAAMgpPAtQBBgAAAE5vZGUgWhcAEAAQAA4ACAATAAUA AAAuAQEAAAAFAAAAAgECAAAABQAAAAIBAgAAAAcAAAD8AgAAzMz/AAAABAAAAC0BAwAIAAAA +gIAAAEAAAAAAAACBAAAAC0BBQAHAAAAGARJATkB0ACwAAQAAAAtAQIABAAAAPABAwAEAAAA LQEAAAQAAADwAQUABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAACQIAAAACBQAAABQCAAAAAAUA AAAuARgAAAAFAAAAAgEBAAAADQAAADIKAQHMAAQAAABBU0ExFgATABYAEAAFAAAALgEBAAAA BQAAAAIBAgAAAAUAAAACAQIAAAAHAAAA/AIAAMzM/wAAAAQAAAAtAQMACAAAAPoCAAABAAAA AAAAAgQAAAAtAQUABwAAABgEQQHRAdAASAEEAAAALQECAAQAAADwAQMABAAAAC0BAAAEAAAA 8AEFAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAA BQAAAAIBAQAAAA0AAAAyCgABZAEEAAAAQVNBMhYAEwAWABAABQAAAC4BAQAAAAUAAAACAQIA AAAFAAAAAgECAAAABwAAAPwCAADMzP8AAAAEAAAALQEDAAgAAAD6AgAAAQAAAAAAAAIEAAAA LQEFAAcAAAAYBDECWQK4AdABBAAAAC0BAgAEAAAA8AEDAAQAAAAtAQAABAAAAPABBQAFAAAA CQIAAAACBQAAABQCAAAAAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEA AAANAAAAMgrpAewBBAAAAEFTQTQWABMAFgAQAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAIB AgAAAAcAAAD8AgAA//+ZAAAABAAAAC0BAwAIAAAA+gIAAAEAAAAAAAACBAAAAC0BBQAHAAAA GwRBAbkCGAFgAgQAAAAtAQIABAAAAPABAwAEAAAALQEAAAQAAADwAQUABQAAAAkCAAAAAgUA AAAUAgAAAAAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAADwAAADIK NwFlAgUAAABPYmogQQAXABAACQAIABYABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAAAgECAAAA BwAAAPwCAAD//5kAAAAEAAAALQEDAAgAAAD6AgAAAQAAAAAAAAIEAAAALQEFAAcAAAAbBCEC QQL4AegBBAAAAC0BAgAEAAAA8AEDAAQAAAAtAQAABAAAAPABBQAFAAAACQIAAAACBQAAABQC AAAAAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAPAAAAMgoXAu0B BQAAAE9iaiBCABcAEAAJAAgAFQAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAACAQIAAAAHAAAA /AIAAP//mQAAAAQAAAAtAQMACAAAAPoCAAABAAAAAAAAAgQAAAAtAQUABwAAABsEMQEhAQgB yAAEAAAALQECAAQAAADwAQMABAAAAC0BAAAEAAAA8AEFAAUAAAAJAgAAAAIFAAAAFAIAAAAA BQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAAA8AAAAyCicBzQAFAAAA T2JqIEEAFwAQAAkACAAWAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAIBAgAAAAcAAAD8AgAA //+ZAAAABAAAAC0BAwAIAAAA+gIAAAEAAAAAAAACBAAAAC0BBQAHAAAAGwQxAbkBCAFgAQQA AAAtAQIABAAAAPABAwAEAAAALQEAAAQAAADwAQUABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAA CQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAADwAAADIKJwFlAQUAAABPYmog QgAXABAACQAIABUABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAAAgECAAAABAAAAC0BAQAHAAAA /AIBAAAAAAAAAAQAAAAtAQMAHAAAAPsCEAAHAAAAAAC8AgAAAAABAgIiU3lzdGVtADTnDWY0 AAAKADgAigEAAAAABQAAANzQGAAEAAAALQEFAAQAAADwAQQADwAAACYGDwAUAFROUFAEAAwA AAAAAAAAAAAAAAAACQAAACYGDwAIAP////8BAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/ AAAGAQIAAAAAAAAAAAAAAAAAAAAAAAEAAAAC1c3VnC4bEJOXCAArLPmuMAAAALgBAAAQAAAA AQAAAIgAAAADAAAAkAAAAA8AAACoAAAABAAAALQAAAAGAAAAvAAAAAcAAADEAAAACAAAAMwA AAAJAAAA1AAAAAoAAADcAAAAFwAAAOQAAAALAAAA7AAAABAAAAD0AAAAEwAAAPwAAAAWAAAA BAEAAA0AAAAMAQAADAAAAFcBAAACAAAA5AQAAB4AAAAPAAAAT24tc2NyZWVuIFNob3cAAB4A AAABAAAAAG4tcwMAAADLFAAAAwAAAAwAAAADAAAAAQAAAAMAAAAAAAAAAwAAAAAAAAADAAAA AAAAAAMAAACgCgkACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAwAAABAA AABUaW1lcyBOZXcgUm9tYW4ADwAAAERlZmF1bHQgRGVzaWduABgAAABQb3dlclBvaW50IFBy ZXNlbnRhdGlvbgAMEAAABgAAAB4AAAALAAAARm9udHMgVXNlZAADAAAAAQAAAB4AAAAQAAAA RGVzaWduIFRlbXBsYXRlAAMAAAABAAAAHgAAAA0AAABTbGlkZSBUaXRsZXMAAwAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD2Dx0AAAAUAAAAX8CR46cUAAAFAPQDAwBPA2Jy aWFuCAAAAGIAcgBpAGEAbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQwB1AHIAcgBlAG4AdAAgAFUAcwBlAHIA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgD///////////// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABCAAAALwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///// //////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAA= --------------5B16F3D677FF6A5BF85CF188-- From nobody Mon Jul 11 14:21:16 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29DCB12D0CC for ; Mon, 11 Jul 2016 14:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Q0e_-tNGO3LW for ; Mon, 11 Jul 2016 14:21:12 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 D3B4112D0C3 for ; Mon, 11 Jul 2016 14:21:11 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 53503AB9746A1; Mon, 11 Jul 2016 21:21:06 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u6BLL98D005414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Jul 2016 21:21:09 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u6BLL8MW006752 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Jul 2016 23:21:09 +0200 Received: from [135.224.207.171] (135.239.27.41) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 11 Jul 2016 23:21:08 +0200 To: Brian E Carpenter , "Joel M. Halpern" , "Michael Behringer (mbehring)" , anima References: <20160708153949.32209.45567.idtracker@ietfa.amsl.com> <1fe314ad-d22f-1291-7e85-4e51ccd328a2@gmail.com> <54f47cc8-bd8b-3783-274a-86e98d9e49ea@gmail.com> <374d2ce8aec64c8aa7b9124a7e1a2646@XCH-RCD-006.cisco.com> <9dbf5192-39ce-826c-b5aa-e88557051415@joelhalpern.com> <91b353d5-7672-c1ae-e173-d43e44b9ee5d@nokia-bell-labs.com> From: Laurent Ciavaglia Organization: Nokia Bell Labs Message-ID: Date: Mon, 11 Jul 2016 23:21:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EE90BF9FA19DF307F2D9B197" X-Originating-IP: [135.239.27.41] Archived-At: Subject: Re: [Anima] Fwd: New Version Notification for draft-du-anima-an-intent-04.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 21:21:15 -0000 --------------EE90BF9FA19DF307F2D9B197 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Hi Brian, The drawing is interesting... Some questions/remarks come to mind: -Could an ASA handle both objectives (A,B)? -Could ASAs be of different implementations, or from different vendors? -What are the possible options . for intra-AF-inter-node-ASAs communication? (developer's/operator's choice, GRASP, other options?) . for intra-AF-intra-node-ASAs communication? (developer's/operator's choice, GRASP, node OS bus/protocols, other options?) -Although I think it is a possible model, why having ASA1 and ASA2 on node X? I mean what is the criteria that decides if an AF is instantiated by one or multiple ASAs on a given node? -Are ASA1 and ASA2 managing different resources on node X? In case they are, what does it mean to "attach" them to node X (instead of the set of resources they manage)? -Could ASAs have a hierarchy? -A case to add is one ASA managing a remote node (the ASA is installed on an "installation host"). -A case to add is one ASA managing multiple nodes. -Do we have examples of AFs that can illustrate the (variations in the) diagram? (secure bootstrap seems like a workable case...) -Constraints in the deployment/instantiation should be captured at some point, i.e. matching between the ASA capabilities (e.g. what types of resources it can control, what types of hosts it can be installed on...), the installation hosts capabilities (e.g. support dynamic installation, location and reachability...) and the operator's needs (what deployment schemes are favored, functionality coverage vs. cost trade-off...). Sections 3 and 4 of draft-peloso-anima-autonomic-function-01 provides explanations on some of the above questions/remarks. Section 2.2 describes a series of variations in line (but broader / mode detailed) with "Brian's" drawing. HTH, best regards, Laurent. On 11/07/2016 18:29, Brian E Carpenter wrote: > Is the attached drawing correct? It's supposed to be an Autonomic Function > implemented across three Autonomic Nodes X, Y and Z containing a total of > four ASAs managing two different technical objectives A and B. > > (If anyone wants to fire back a corrected version I have attached the PPT > as well as the PDF.) > > Regards > Brian > > On 12/07/2016 02:45, Laurent Ciavaglia wrote: >> Hello, >> >> There is some text in draft-peloso-anima-autonomic-function-01 >> (https://tools.ietf.org/html/draft-peloso-anima-autonomic-function-01) detailing what should be considered when installing, >> instantiating and operating AF/ASA. >> Please see sections 3+. >> >> Feedback on the text is most welcome as this will be presented at IETF96/Berlin. >> >> Best regards, Laurent. >> >> >> On 11/07/2016 14:55, Joel M. Halpern wrote: >>> I believe your description, and that of others as to what we "intend", does not line up with the definition you quote. >>> >>> The text says that an ASA "implements an autonomic function." That seems to say that I sould expect an autonomic function to >>> be implemented by an ASA, thus implying a 1-1 relationship. >>> >>> yet, your example states an AF of "bootstrapping", but the funcitonality of the ASA being a much smaller piece. >>> >>> Net: No, the words do not clearly state what we intend. >>> >>> Yours, >>> Joel >>> >>> On 7/11/16 8:39 AM, Michael Behringer (mbehring) wrote: >>> ... >>>>>>> Also, how is the relevance for each ASA known? >>>>>> My proposal: Intent comes in sections; those sections are >>>>>> labelled with the >>>>> name of the ASA / autonomic function they belong to. Also here, >>>>> there are many ways to do this, it's a simple proposal which could >>>>> be optimised in many ways. >>>>>>> And is that the correct granularity of the section? Maybe the >>>>>>> granularity should be individual objectives, or certain groups >>>>>>> of objectives? I think this needs more discussion. >>>>>> On this one I agree!! We should have more discussions on that. >>>>>> Your point >>>>> from the other mail, that we should try implementing some ASAs >>>>> would help understand this better. >>>>> >>>>> Yes. There's been an assumption, I think, that one "autonomic >>>>> function" == one ASA. We need to be clear if that is an axiom, and >>>>> we need to think about how ASAs are named, and if those names need >>>>> to be registered somehow. >>>> Yes, that misunderstanding keeps popping up all the time. I think >>>> RFC7575 is quite clear: >>>> >>>> Autonomic Function: A feature or function that requires no >>>> configuration and can derive all required information through self- >>>> knowledge, discovery, or Intent. >>>> >>>> Autonomic Service Agent: An agent implemented on an autonomic node >>>> that implements an autonomic function, either in part (in the case >>>> of a distributed function) or whole. >>>> >>>> Example: There is the "autonomic function" "bootstrapping of new >>>> nodes". It consists of 3 different ASAs: The new_device ASA, the >>>> proxy ASA and the registrar ASA. >>>> >>>> How can we make that clearer? (I thought RFC7575 *is* clear). >>> ... >>> >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima >>> -- Laurent Ciavaglia Nokia, Bell Labs +33 160 402 636 route de Villejust - Nozay, France linkedin.com/in/laurent.ciavaglia --------------EE90BF9FA19DF307F2D9B197 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit Hi Brian,

The drawing is interesting...

Some questions/remarks come to mind:
-Could an ASA handle both objectives (A,B)?
-Could ASAs be of different implementations, or from different vendors?
-What are the possible options
    . for intra-AF-inter-node-ASAs communication? (developer's/operator's choice, GRASP, other options?)
    . for intra-AF-intra-node-ASAs communication? (developer's/operator's choice, GRASP, node OS bus/protocols, other options?)
-Although I think it is a possible model, why having ASA1 and ASA2 on node X? I mean what is the criteria that decides if an AF is instantiated by one or multiple ASAs on a given node?
-Are ASA1 and ASA2 managing different resources on node X? In case they are, what does it mean to "attach" them to node X (instead of the set of resources they manage)?
-Could ASAs have a hierarchy?
-A case to add is one ASA managing a remote node (the ASA is installed on an "installation host").
-A case to add is one ASA managing multiple nodes.
-Do we have examples of AFs that can illustrate the (variations in the) diagram? (secure bootstrap seems like a workable case...)
-Constraints in the deployment/instantiation should be captured at some point, i.e. matching between the ASA capabilities (e.g. what types of resources it can control,
   what types of hosts it can be installed on...), the installation hosts capabilities (e.g. support dynamic installation, location and reachability...) and the operator's needs (what deployment schemes are favored, functionality coverage vs. cost trade-off...).

Sections 3 and 4 of draft-peloso-anima-autonomic-function-01 provides explanations on some of the above questions/remarks.
Section 2.2 describes a series of variations in line (but broader / mode detailed) with "Brian's" drawing.

HTH, best regards, Laurent.


On 11/07/2016 18:29, Brian E Carpenter wrote:
Is the attached drawing correct? It's supposed to be an Autonomic Function
implemented across three Autonomic Nodes X, Y and Z containing a total of
four ASAs managing two different technical objectives A and B.

(If anyone wants to fire back a corrected version I have attached the PPT
as well as the PDF.)

Regards
   Brian

On 12/07/2016 02:45, Laurent Ciavaglia wrote:

Hello,

There is some text in draft-peloso-anima-autonomic-function-01
(https://tools.ietf.org/html/draft-peloso-anima-autonomic-function-01) detailing what should be considered when installing,
instantiating and operating AF/ASA.
Please see sections 3+.

Feedback on the text is most welcome as this will be presented at IETF96/Berlin.

Best regards, Laurent.


On 11/07/2016 14:55, Joel M. Halpern wrote:

I believe your description, and that of others as to what we "intend", does not line up with the definition you quote.

The text says that an ASA "implements an autonomic function." That seems to say that I sould expect an autonomic function to
be implemented by an ASA, thus implying a 1-1 relationship.

yet, your example states an AF of "bootstrapping", but the funcitonality of the ASA being a much smaller piece.

Net: No, the words do not clearly state what we intend.

Yours,
Joel

On 7/11/16 8:39 AM, Michael Behringer (mbehring) wrote:
...

Also, how is the relevance for each ASA known?

My proposal: Intent comes in sections; those sections are
labelled with the

name of the ASA / autonomic function they belong to. Also here,
there are many ways to do this, it's a simple proposal which could
be optimised in many ways.


                

                  
And is that the correct granularity of the section? Maybe the
granularity should be individual objectives, or certain groups
of objectives? I think this needs more discussion.


                

                
On this one I agree!! We should have more discussions on that.
Your point


              

              
from the other mail, that we should try implementing some ASAs
would help understand this better.

Yes. There's been an assumption, I think, that one "autonomic
function" == one ASA. We need to be clear if that is an axiom, and
we need to think about how ASAs are named, and if those names need
to be registered somehow.


            

            
Yes, that misunderstanding keeps popping up all the time.  I think
RFC7575 is quite clear:

Autonomic Function: A feature or function that requires no
configuration and can derive all required information through self-
knowledge, discovery, or Intent.

Autonomic Service Agent: An agent implemented on an autonomic node
that implements an autonomic function, either in part (in the case
of a distributed function) or whole.

Example: There is the "autonomic function" "bootstrapping of new
nodes". It consists of 3 different ASAs: The new_device ASA, the
proxy ASA and the registrar ASA.

How can we make that clearer? (I thought RFC7575 *is* clear).


          

          
...

_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima



        

        

      

    

    

    
-- 

      
      
      
      
      
      
      
      
      
      
      

        
Laurent
            Ciavaglia

        
Nokia, Bell
            Labs

        
 

        
+33 160 402
            636

        
route de
            Villejust - Nozay, France

        
linkedin.com/in/laurent.ciavaglia

      

    

  


--------------EE90BF9FA19DF307F2D9B197--


From nobody Mon Jul 11 23:45:29 2016
Return-Path: 
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91BEE12B016 for ; Mon, 11 Jul 2016 23:45:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 islfw8MJg6vC for ; Mon, 11 Jul 2016 23:45:25 -0700 (PDT)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 CACB712B007 for ; Mon, 11 Jul 2016 23:45:24 -0700 (PDT)
Received: by mail-wm0-x233.google.com with SMTP id f65so88536728wmi.0 for ; Mon, 11 Jul 2016 23:45:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=8EeLaN9DrTyqSTSMMhbQRsGIRrZiX79F2+7yBdkSi6c=; b=m6TW3zrgTfioFaiQHBcJT/uqgvUIyc/vQDK5kNDO8OrqaTNzTcKserW95ssCvoBh/a n8sLJOE+Dk5pTJ2AkozuLPbiOo3lw1OZj0Taxt9uuNjV5Y2sGQiDiH5o8SNGpO03GMsA ukstWHyeYSh3QLzGy1pCscDD+PS6vZIFSZu97d3ztHlm7DAB4ciq6EkRS4HQJ56WLwiG IyFRh1XQT7nY57ZUYcs7x+8+dyzpY/h0PDKlwHtoJps3FLoJG9L4KdRDIyEXbZ8m7Kn0 oopk+go93nI9agOb1+BNFCG0Xj4bhoZ8l0eEBALQUUM3X7ZohXarC+CTc0PR6DxoncOA zVAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=8EeLaN9DrTyqSTSMMhbQRsGIRrZiX79F2+7yBdkSi6c=; b=ftwbO69aOY4l3PRbU8SyM/7SeLVbb5Dje2ot3GNWiGfazgKAEVBxIIRdrzjyn7oW/8 gDVWbmDjjNp/A9nF9KntG7N87BHIzYqUL/gp7j8mirlg4fRUBBhLSvGpJAwCj79OSAVZ KepssmjIIs2UYRm0dDgGZF7/I3egWXF2QWHBwiPzpEaez53D26r5JVp4d5L4HqsteUr+ ZEFqRAQCXRn/0LViyBlhWh8VjDbyjNd3cjBc5GRxQppAn6EK1fIL5peS5se4bei//1HX DjSWb79DgcGwEGZUOxr0BjdcBNJhk+39MZHR2rpajD2fnH7UfpIbf7MHoiUliQPdswOj cuQw==
X-Gm-Message-State: ALyK8tLMqdw8ErscZHsMLIUrlpm/sa2bk0s3ifPd6D9p5DHrHDoxnY5azIcrtCvEUnXSKQ==
X-Received: by 10.28.48.3 with SMTP id w3mr18570741wmw.28.1468305923167; Mon, 11 Jul 2016 23:45:23 -0700 (PDT)
Received: from [10.0.1.29] (cpc66883-mort6-2-0-cust696.19-2.cable.virginm.net. [92.233.126.185]) by smtp.gmail.com with ESMTPSA id c74sm26713727wme.1.2016.07.11.23.45.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Jul 2016 23:45:22 -0700 (PDT)
To: Laurent Ciavaglia , "Joel M. Halpern" , "Michael Behringer (mbehring)" , anima 
References: <20160708153949.32209.45567.idtracker@ietfa.amsl.com>  <1fe314ad-d22f-1291-7e85-4e51ccd328a2@gmail.com>  <54f47cc8-bd8b-3783-274a-86e98d9e49ea@gmail.com> <374d2ce8aec64c8aa7b9124a7e1a2646@XCH-RCD-006.cisco.com> <9dbf5192-39ce-826c-b5aa-e88557051415@joelhalpern.com> <91b353d5-7672-c1ae-e173-d43e44b9ee5d@nokia-bell-labs.com>  
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <709634fa-f4a0-0be2-1dda-e160bdf02305@gmail.com>
Date: Tue, 12 Jul 2016 18:45:23 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Anima] Fwd: New Version Notification for draft-du-anima-an-intent-04.txt
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Jul 2016 06:45:27 -0000

Hi Laurent,

On 12/07/2016 09:21, Laurent Ciavaglia wrote:
> Hi Brian,
> 
> The drawing is interesting...

It was intended to provoke questions and I see that it succeeded ;-)
> 
> Some questions/remarks come to mind:
> -Could an ASA handle both objectives (A,B)?

Yes, I see no reasons why not.

> -Could ASAs be of different implementations, or from different vendors?

I think so, if the Objectives have open specifications.

> -What are the possible options
>     . for intra-AF-inter-node-ASAs communication? (developer's/operator's choice, GRASP, other options?)

I hope we would RECOMMEND to use GRASP, but is clearly not the only option.

>     . for intra-AF-intra-node-ASAs communication? (developer's/operator's choice, GRASP, node OS bus/protocols, other options?)

Again GRASP would work, and if the ASAs are independently developed, it would
seem to be the natural choice.

> -Although I think it is a possible model, why having ASA1 and ASA2 on node X? I mean what is the criteria that decides if an AF
> is instantiated by one or multiple ASAs on a given node?

I tend to agree that a single ASA would be more natural, but IMHO we should allow
flexibility.

> -Are ASA1 and ASA2 managing different resources on node X? In case they are, what does it mean to "attach" them to node X
> (instead of the set of resources they manage)?

I think the answer to that is hidden in the definition of the Objectives. If I take the
prefix management use case, there is a local pool of IPv6 prefixes which definitely
belong to the node and can be allocated to users by the node. But if the node runs
short of prefixes, the ASA will have to negotiate with its peer in another node
to increase its pool. So two fundamentally identical ASAs in two nodes, but each
with its own resource pool.

> -Could ASAs have a hierarchy?

I think the answer to that is in the semantics of the AF, not a question of principle.

> -A case to add is one ASA managing a remote node (the ASA is installed on an "installation host").

Right, but then the remote node is *not* an autonomic node; it's a slave.

> -A case to add is one ASA managing multiple nodes.

...multiple slaves.

> -Do we have examples of AFs that can illustrate the (variations in the) diagram? (secure bootstrap seems like a workable case...)

I think bootstrap is one, and for some aspects, prefix management.

> -Constraints in the deployment/instantiation should be captured at some point, i.e. matching between the ASA capabilities (e.g.
> what types of resources it can control,
>    what types of hosts it can be installed on...), the installation hosts capabilities (e.g. support dynamic installation,
> location and reachability...) and the operator's needs (what deployment schemes are favored, functionality coverage vs. cost
> trade-off...).
> 
> Sections 3 and 4 of draft-peloso-anima-autonomic-function-01 provides explanations on some of the above questions/remarks.
> Section 2.2 describes a series of variations in line (but broader / mode detailed) with "Brian's" drawing.

Yes. It was only an illustration that I started for my own understanding.

Thanks
    Brian

> 
> HTH, best regards, Laurent.
> 
> 
> On 11/07/2016 18:29, Brian E Carpenter wrote:
>> Is the attached drawing correct? It's supposed to be an Autonomic Function
>> implemented across three Autonomic Nodes X, Y and Z containing a total of
>> four ASAs managing two different technical objectives A and B.
>>
>> (If anyone wants to fire back a corrected version I have attached the PPT
>> as well as the PDF.)
>>
>> Regards
>>     Brian
>>
>> On 12/07/2016 02:45, Laurent Ciavaglia wrote:
>>> Hello,
>>>
>>> There is some text in draft-peloso-anima-autonomic-function-01
>>> (https://tools.ietf.org/html/draft-peloso-anima-autonomic-function-01) detailing what should be considered when installing,
>>> instantiating and operating AF/ASA.
>>> Please see sections 3+.
>>>
>>> Feedback on the text is most welcome as this will be presented at IETF96/Berlin.
>>>
>>> Best regards, Laurent.
>>>
>>>
>>> On 11/07/2016 14:55, Joel M. Halpern wrote:
>>>> I believe your description, and that of others as to what we "intend", does not line up with the definition you quote.
>>>>
>>>> The text says that an ASA "implements an autonomic function." That seems to say that I sould expect an autonomic function to
>>>> be implemented by an ASA, thus implying a 1-1 relationship.
>>>>
>>>> yet, your example states an AF of "bootstrapping", but the funcitonality of the ASA being a much smaller piece.
>>>>
>>>> Net: No, the words do not clearly state what we intend.
>>>>
>>>> Yours,
>>>> Joel
>>>>
>>>> On 7/11/16 8:39 AM, Michael Behringer (mbehring) wrote:
>>>> ...
>>>>>>>> Also, how is the relevance for each ASA known?
>>>>>>> My proposal: Intent comes in sections; those sections are
>>>>>>> labelled with the
>>>>>> name of the ASA / autonomic function they belong to. Also here,
>>>>>> there are many ways to do this, it's a simple proposal which could
>>>>>> be optimised in many ways.
>>>>>>>> And is that the correct granularity of the section? Maybe the
>>>>>>>> granularity should be individual objectives, or certain groups
>>>>>>>> of objectives? I think this needs more discussion.
>>>>>>> On this one I agree!! We should have more discussions on that.
>>>>>>> Your point
>>>>>> from the other mail, that we should try implementing some ASAs
>>>>>> would help understand this better.
>>>>>>
>>>>>> Yes. There's been an assumption, I think, that one "autonomic
>>>>>> function" == one ASA. We need to be clear if that is an axiom, and
>>>>>> we need to think about how ASAs are named, and if those names need
>>>>>> to be registered somehow.
>>>>> Yes, that misunderstanding keeps popping up all the time.  I think
>>>>> RFC7575 is quite clear:
>>>>>
>>>>> Autonomic Function: A feature or function that requires no
>>>>> configuration and can derive all required information through self-
>>>>> knowledge, discovery, or Intent.
>>>>>
>>>>> Autonomic Service Agent: An agent implemented on an autonomic node
>>>>> that implements an autonomic function, either in part (in the case
>>>>> of a distributed function) or whole.
>>>>>
>>>>> Example: There is the "autonomic function" "bootstrapping of new
>>>>> nodes". It consists of 3 different ASAs: The new_device ASA, the
>>>>> proxy ASA and the registrar ASA.
>>>>>
>>>>> How can we make that clearer? (I thought RFC7575 *is* clear).
>>>> ...
>>>>
>>>> _______________________________________________
>>>> Anima mailing list
>>>> Anima@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/anima
>>>>
> 


From nobody Wed Jul 13 05:16:48 2016
Return-Path: 
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BED2E12DF23; Wed, 13 Jul 2016 05:16:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level: 
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 nqckRH6417fF; Wed, 13 Jul 2016 05:16:44 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 72C1512DD45; Wed, 13 Jul 2016 05:16:44 -0700 (PDT)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 24C1388A53FBC; Wed, 13 Jul 2016 12:16:40 +0000 (GMT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u6DCGf6d001239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Jul 2016 12:16:42 GMT
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u6DCGfZ2023385 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Jul 2016 14:16:41 +0200
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.32]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 13 Jul 2016 14:16:41 +0200
From: "Peloso, Pierre (Nokia - FR)" 
To: Brian E Carpenter , "Michael Behringer (mbehring)" , Sheng Jiang , "anima@ietf.org" , "draft-ietf-anima-grasp.all@ietf.org" 
Thread-Topic: ASA management discussions [was snip of] Review of ANIMA GRASP
Thread-Index: AQHR3QBp9OUt7Z4luE+Se9DV7TPIVw==
Date: Wed, 13 Jul 2016 12:16:40 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.39]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: [Anima] ASA management discussions [was snip of] Review of ANIMA GRASP
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Jul 2016 12:16:48 -0000

SGkgQnJpYW4gYW5kIGFsbCwNCg0KVGhvdWdoIGNvbWluZyBsYXRlLCBJIHRha2Ugc29tZSBvZiB0
aGUgcG9pbnRzIGRpc2N1c3NlZCB0aGVyZSBhcmUgd29ydGggYmVpbmcgcHVzaGVkIGZ1cnRoZXIu
DQpCeSB0aGUgd2F5LCBJIHJlbmFtZWQgdGhlIGRpc2N1c3Npb24gdGhyZWFkIGluIEFTQSBtYW5h
Z2VtZW50IHdlcmUgdGhlIG1haW4gY29uY2VybnMgYWRkcmVzc2VkIGluIHRoZXNlIHNuaXBwZWQg
cG9pbnRzLg0KQSB3YXkgdG8gbWFrZSBjbGVhciB0aGF0IHRoZXNlIHBvaW50cyBnbyBiZXlvbmQg
R1JBU1AgZGVzaWduLCBidXQgY29uY2VybiBBTklNQSBXRyBhcyBhIHdob2xlLg0KDQpUaGFua3Mg
Zm9yIHlvdXIgYW5zd2Vycy4uLi4NCg0KUGllcnJlDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2lu
ZS0tLS0tDQo+IERlwqA6IEJyaWFuIEUgQ2FycGVudGVyIFttYWlsdG86YnJpYW4uZS5jYXJwZW50
ZXJAZ21haWwuY29tXQ0KPiBFbnZvecOpwqA6IHNhbWVkaSAyIGp1aWxsZXQgMjAxNiAwOTo1MA0K
PiDDgMKgOiBQZWxvc28sIFBpZXJyZSAoTm9raWEgLSBGUik7IE1pY2hhZWwgQmVocmluZ2VyICht
YmVocmluZyk7IFNoZW5nIEppYW5nOw0KPiBhbmltYUBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1hbmlt
YS1ncmFzcC5hbGxAaWV0Zi5vcmcNCj4gT2JqZXTCoDogUmU6IFtBbmltYV0gUmV2aWV3IG9mIEFO
SU1BIEdSQVNQDQo+IA0KPiBQaWVycmUsDQo+IA0KPiBMZXQgbWUgdHJ5IHRvIGFuc3dlciB5b3Vy
IHBvaW50cyBiZWxvdy4gSSBoYXZlIGRlbGV0ZWQgYSBsb3Qgb2YgdGV4dCB0byBtYWtlIHRoZQ0K
PiBtZXNzYWdlIHNob3J0IGVub3VnaCB0byByZWFkLiBBbHNvLCBwbGVhc2Ugbm90ZSB0aGF0IG15
IG1haW4gY29uY2VybiBmb3Igbm93IGlzIHRvDQo+IGVuc3VyZSB0aGF0IEdSQVNQIGRvZXMgZXZl
cnl0aGluZyB3ZSBuZWVkOyBtYW55IGFzcGVjdHMgdGhhdCBhcmUgc3BlY2lmaWMgdG8gQVNBDQo+
IGRlc2lnbiBkbyBub3QgYWZmZWN0IHRoaXMuDQo+IE9uIDAyLzA3LzIwMTYgMDM6NTAsIFBlbG9z
bywgUGllcnJlIChOb2tpYSAtIEZSKSB3cm90ZToNCj4gLi4uDQo+ID4+IFllcywgdGhlIHJlZmVy
ZW5jZSBtb2RlbCBzaG91bGQgZ2l2ZSB0aGUgZ2VuZXJhbCBvdmVydmlldywgc28gdGhpcw0KPiA+
PiBkaXNjdXNzaW9uIHNob3VsZCB0byBhIGxhcmdlIGV4dGVudCBnbyB0aGVyZS4NCj4gPiBTZWVt
cyBmYWlyIHRvIG1lIHRvIGhhdmUgc29tZSBtb3JlIG9mIHRoZXNlIGluIHRoZSByZWZlcmVuY2Ug
bW9kZWwuDQo+ID4gSW5zaWRlIGRyYWZ0LXBlbG9zby1hbmltYS1hdXRvbm9taWMtZnVuY3Rpb24s
IHRoZXJlIGlzIHRleHQgb24gdGhlIHJvbGUgb2YgQVNBIGFuZA0KPiB0aGVpciBtYW5hZ2VtZW50
Lg0KPiA+IFdoeSBub3QgYnVpbGRpbmcgdXBvbiBpdCA/DQo+IA0KPiBDZXJ0YWlubHksIGJ1dCB3
ZSBuZWVkIGEgY29tbW9uIHZpZXcgYW5kIHRoZSByZWZlcmVuY2UgbW9kZWwgbXVzdCBub3QgYmVj
b21lIHRvbyBsb25nDQo+IGFuZCBjb21wbGV4LCBvciBub2JvZHkgd2lsbCByZWFkIGl0LiBTbyBJ
IHN0aWxsIHN1c3BlY3Qgd2UgbmVlZCBhIHNlcGFyYXRlIGRvY3VtZW50DQo+IG9uIEFTQSBkZXNp
Z24uDQoNCkkgdGhpbmsgd2UgcmVhY2hlZCB0aGlzIHBvaW50Og0KIC0gaGF2aW5nIHNvbWUgbGln
aHQgYWRkaXRpb25zIHRvIHRoZSByZWZlcmVuY2UgbW9kZWwgdG8ga2VlcCBpdCByZWFkYWJsZSwN
CiAtIGhhdmluZyBhIHNlcGFyYXRlIGRvY3VtZW50IG9uIEFTQSBkZXNpZ246IGp1c3QgbmVlZCBh
dWdtZW50aW5nL21vZGlmeWluZyB0aGUgZHJhZnQgd2UgcHJvcG9zZWQgZnJvbSBiZWZvcmUgSUVU
RiA5NHRoLg0KIA0KPiAuLi4NCj4gPj4gLi4uIGFuZCBpdCBNVVNUIGJlIHBvc3NpYmxlLiBXZSd2
ZSBqdXN0IGhhZCB0aGUgd29ya3Nob3Agb24gQU4gaW4NCj4gPj4gQXRoZW5zLCBhbmQgb25lIGJp
ZyBkaXNjdXNzaW9uIHBvaW50IHdhcyB0aGUgY29vcmRpbmF0aW9uIGZ1bmN0aW9uLg0KPiA+PiBX
aGlsZSB3ZSBoYXZlbid0IGNvbmNsdWRlZCB3aGV0aGVyIHRoaXMgY29vcmRpbmF0aW9uIGZ1bmN0
aW9uIGlzDQo+ID4+IGl0c2VsZiBhbiBBU0Egb3IgcGFydCBvZiB0aGUgaW5mcmFzdHJ1Y3R1cmUs
IHdlIGRvIE5PVCB3YW50IHRvIG1ha2UNCj4gPj4gaXQgdGVjaG5pY2FsbHkgaW1wb3NzaWJsZSBm
b3IgYSBjb29yZGluYXRpb24gZnVuY3Rpb24gdG8gYmUgYW4gQVNBLiBUaGlzIGlzIGEgZ29vZA0K
PiBleGFtcGxlIG9mIHR3byBBU0FzIG9uIHRoZSBzYW1lIGRldmljZSBoYXZpbmcgdG8gY29tbXVu
aWNhdGUuDQo+ID4gQXQgdGhpcyBwb2ludCAyIGNvbW1lbnRzOg0KPiA+ICAgIDEgLSBUaGVyZSBt
YXkgZGVmaW5pdGVseSBiZSB0d28gZGlmZmVyZW50IEFTQXMgd2lsbGluZyB0byBtb2RpZnkgdGhl
IHNhbWUgZGV2aWNlDQo+IHBhcmFtZXRlci4uLg0KPiANCj4gWWVzLCBidXQgYSBkZXZpY2UgcGFy
YW1ldGVyIGlzIG5vdCB0aGUgc2FtZSB0aGluZyBhcyBhIEdSQVNQIG9iamVjdGl2ZS4gSSBoYXZl
IGdyZWF0DQo+IGRpZmZpY3VsdHkgd2l0aCB0aGUgdGhvdWdodCBvZiB0d28gQVNBcyAqaW4gdGhl
IHNhbWUgZGV2aWNlKiB0aGF0IGFyZSBib3RoIGFjdGl2ZWx5DQo+IG5lZ290aWF0aW5nIHRoZSBz
YW1lIEdSQVNQIG9iamVjdGl2ZS4NCg0KSWYgYSBkZXZpY2UgcGFyYW1ldGVyIG1vZGlmaWVkIGJ5
IGFuIEFTQSBpcyBub3Qgb25lIG9mIHRoZSBBU0Egb2JqZWN0aXZlcywgdGhlbiB3aGF0IGlzIGFu
IG9iamVjdGl2ZSA/IENhbiB5b3UgcHJvdmlkZSBleGFtcGxlIG9mIHdoYXQgeW91IGhhdmUgaW4g
bWluZCA/DQoNCj4gDQo+IElmIHR3byBBU0FzIG1vZGlmeSB0aGUgc2FtZSB1bmRlcmx5aW5nIGRl
dmljZSBwYXJhbWV0ZXIsIHRoYXQgbXVzdCBvZiBjb3Vyc2UgYmUNCj4gY29vcmRpbmF0ZWQgYXQg
ZGV2aWNlIGxldmVsLiBJdCBzZWVtcyBsaWtlIGEgcXVpdGUgdHJhZGl0aW9uYWwgcHJvYmxlbSBu
ZWVkaW5nIGEgbG9jaw0KPiBhbmQvb3IgYSB0b2tlbi4NCj4gDQo+IElmIHR3byBBU0FzIGluICpk
aWZmZXJlbnQqIGRldmljZXMgbmVnb3RpYXRlIHRoZSBzYW1lIEdSQVNQIG9iamVjdGl2ZSB0aGF0
IGlzIG9mDQo+IGNvdXJzZSBhYnNvbHV0ZWx5IG5vcm1hbCBhbmQgbWlnaHQgbm90IGNyZWF0ZSBh
bnkgY29vcmRpbmF0aW9uIGlzc3VlLCBkZXBlbmRpbmcgb24NCj4gdGhlIHNlbWFudGljcyBvZiB0
aGUgb2JqZWN0aXZlLg0KPiANCj4gPiAgICAyIC0gTWljaGFlbCBpcyBkZWFsaW5nIGhlcmUgd2l0
aCB0aGUgcm9sZSBvZiBjb29yZGluYXRpb24gZnVuY3Rpb24gd2l0aCByZWdhcmRzDQo+IHRvIEdS
QVNQOiBEdXJpbmcgdGhlIFdTIGRpc2N1c3Npb25zLCAgdGhlcmUgd2FzIGEgc29ydCBvZiBzb2Z0
LWFncmVlbWVudCB0aGF0Og0KPiA+ICAgICAgICAgICAgLSBjb29yZGluYXRpb24gZnVuY3Rpb24g
Y2FuIGJlIGRpc3RyaWJ1dGVkLA0KPiANCj4gT2YgY291cnNlIChhbmQgdGhhdCdzIHRoZSByZWFz
b24gSSByZWNlbnRseSBiZWNhbWUgaW50ZXJlc3RlZCBpbiBkaXN0cmlidXRlZA0KPiBjb25zZW5z
dXMgYWxnb3JpdGhtcykuDQo+IA0KPiA+ICAgICAgICAgICAgLSBjb29yZGluYXRpb24gZnVuY3Rp
b24gaW5zdGFuY2VzIHNob3VsZCBjb250YWluIGEgR1JBU1ANCj4gPiBjbGllbnQsDQo+IA0KPiBX
aGF0J3MgYSBHUkFTUCBjbGllbnQ/IFdlIGhhdmUgaW5pdGlhdG9ycyBhbmQgcmVzcG9uZGVycyBp
biBHUkFTUC4gWW91IGNhbiB0aGluayBvZg0KPiB0aGUgaW5pdGlhdG9yIGFzIGEgY2xpZW50IGFu
ZCB0aGUgcmVzcG9uZGVyIGFzIGEgc2VydmVyLCBidXQgYW55IEFTQSBjYW4gYmUgYm90aA0KPiBp
bml0aWF0b3IgYW5kIHJlc3BvbmRlci4NCkluIG15IHVuZGVyc3RhbmRpbmcgdGhlcmUgaXMgaW4g
ZWFjaCBBdXRvbm9taWMgTm9kZSBhIEdSQVNQIEVuZ2luZS4gRnJvbSB0aGF0IEkgZGVyaXZlIHRo
ZXJlIGlzIGEgc29ydCBvZiBBUEkgdGhlIEFTQSBzaG91bGQgaGF2ZSB0byBwdXNoIGEgbWVzc2Fn
ZSB0byBHUkFTUCBhbmQgcmVjZWl2ZXMgdGhlIGNvbWluZyBvbmVzLiBTbyBiYXNpY2FsbHksIGEg
Y2xpZW50IGlzIHRoZSBBUEkgZm9yIGJvdGggdGhlIGluaXRpYXRvciBhbmQgdGhlIHJlc3BvbmRl
ci4NCg0KVGhlIHBvaW50IGFib3ZlIG1lbnRpb25pbmcgdGhhdCBjb29yZGluYXRpb24gZnVuY3Rp
b24gc2hvdWxkIGNvbnRhaW4gYSBHUkFTUCBjbGllbnQsIHdhcyBqdXN0IHRvIG1lYW4gdGhhdCBj
b29yZGluYXRpb24gZnVuY3Rpb24gc2hvdWxkIGJlIGNhcGFibGUgb2YgaW5pdGlhdGluZyBhbmQg
cmVzcG9uZGluZyB0byBHUkFTUCBzaWduYWxpbmcgKGhlbmNlIGJpbmQgdG8gYSBHUkFTUCBlbmdp
bmUpLiANCldoaWNoIG1heSBub3QgYmUgY2xlYXIgaGVyZSBpcyB0aGUgaW1wbGljaXQ6DQpDb29y
ZGluYXRpb24gZnVuY3Rpb24gaXMgbm90IGFuIEFTQSAoYXQgbGVhc3QgaW4gbXkgb3Bpbmlvbiku
DQpXaHkgbm90PyBCZWNhdXNlIGFuIEFTQSBpcyBhbiBhZ2VudCBvZiBhbiBhdXRvbm9taWMgZnVu
Y3Rpb24uIENvb3JkaW5hdGlvbiBmdW5jdGlvbiBpcyBub3QgYW4gYXV0b25vbWljIGZ1bmN0aW9u
Lg0KSXQgaXMgYSBtZXRhIGZ1bmN0aW9uIGluIGNoYXJnZSBvZiBpbnN1cmluZyBjb29yZGluYXRp
b24gYmV0d2VlbiBhdXRvbm9taWMgZnVuY3Rpb25zLg0KVGhlbiB3aHkgbm90IGdlbmVyYWxpemUg
YW5kIHN0YXRlIHRoYXQgbmV2ZXJ0aGVsZXNzIGxldCBpdCBiZSBhbiBBU0E/DQpCZWNhdXNlIGFs
bCB3ZSd2ZSBiZWVuIHN0cmVzc2luZyBzaW5jZSB0aGUgYmVnaW5uaW5nIG9mIEFOSU1BIGlzIHRo
YXQgQVNBIGhhdmUgdG8gY29tcGx5IHRvIGEgbGlmZS1jeWNsZSogYW5kIGR1dGllcyAobGlrZSBz
ZWxmLWRlc2NyaWJpbmcpLiBUaG91Z2ggY29vcmRpbmF0aW9uIGZ1bmN0aW9uIG1heSBoYXZlIGEg
bGlmZS1jeWNsZSBhbmQgZHV0aWVzLCBJIGFtIHN1cmUgdGhvc2UgYXJlIGRpZmZlcmVudCB0aGFu
IHRoZSBvbmVzLg0KVGhhdCBpcyB3aHkgSSBwbGFjZSB0aGUgZ2VuZXJhbGl6YXRpb24gMSBsZXZl
bCBoaWdoZXI6IEFTQSBhbmQgQ29vcmRpbmF0aW9uIGZ1bmN0aW9uIGNvbnRhaW4gYSBHUkFTUCBj
bGllbnQuIA0KIA0KKiBCdHcsIEkgc2F3IHlvdSBqdXN0IGRyYXcgc29tZSBkZXBsb3ltZW50IG9m
IEFTQSwgYW5kIHRoaXMgZGVwbG95bWVudCBpcyBqdXN0IG9uZSBvZiB0aGUgcG9pbnQgd2UndmUg
cG9pbnRlZCBhcyBiZWluZyBwYXJ0IG9mIHRoZSBBU0EgbGlmZS1jeWNsZS4NCg0KPiA+ICAgICAg
ICAgICAgLSBpdCB3YXMgbm90IGNsZWFyIHlldCB3aGV0aGVyIGNvb3JkaW5hdGlvbiB3b3VsZCBi
ZSBjb21wbGV0ZWx5IGV4dGVybmFsDQo+IHRvIEFOSSAobGlrZSBBU0Egc2l0dGluZyBvbiB0b3Ag
b2YgQU5JKSwgb3Igd291bGQgaGF2ZSBzb21lIHBpZWNlcyBlbWJlZGRlZCBpbiBBTkkuDQo+IA0K
PiBNeSBvcGluaW9uOiB0aGUgc2VtYW50aWNzIG9mIGNvb3JkaW5hdGlvbiBhcmUgdmVyeSBkZXBl
bmRlbnQgb24gdGhlIGluZGl2aWR1YWwgdXNlDQo+IGNhc2UuIFNvIEkgYW0gbm90IHN1cmUgd2hh
dCBnZW5lcmljIHN1cHBvcnQgd2UgY291bGQgcHJvdmlkZSwgYmV5b25kIGJhc2ljIEdSQVNQLiBJ
Zg0KPiB5b3UgY2FuIHNwZWNpZnkgdGhlIHNvcnQgb2YgaW50ZXJhY3Rpb24gcmVxdWlyZWQgYmV0
d2VlbiB0d28gY29vcmRpbmF0b3JzICppbiB0aGUNCj4gZ2VuZXJhbCBjYXNlKiB3ZSBjYW4gdGhl
biBzZWUgd2hldGhlciBpdCBuZWVkcyBhbnkgbmV3IEdSQVNQIG1lc3NhZ2UgdHlwZXMuDQoNCklm
IHlvdSdyZSBub3QgY29udmluY2VkIHRoYXQgYSBnZW5lcmljIHN1cHBvcnQgdG8gY29vcmRpbmF0
ZSBBRiBpcyBmZWFzaWJsZSwgSSB0aGVuIGVuY291cmFnZSB5b3UgdG8gYXR0ZW5kIHRoZSBwcmVz
ZW50YXRpb25zIHRoYXQgTGF1cmVudCB3aWxsIGJlIGdpdmluZyBkdXJpbmcgQU5JTUEgbWVldGlu
ZyBpbiBCZXJsaW4uIEl0IHNwZWNpZmljYWxseSBhZGRyZXNzZXMgdGhpcyBwb2ludC4NClRoZXJl
IGFyZSBzb21lIHJlcXVpcmVtZW50cyB0byBzaWduYWxpbmcgaW4gdGhpcyBwcmVzZW50YXRpb24g
KHNhbWUgYXMgdGhlIG9uZSBhbHJlYWR5IHByZXNlbnRlZCBhdCBZb2tvaGFtYSBhbmQgQnVuZW9z
IEFlcmVzKTogbWFpbmx5IGhhdmluZyBjb21tYW5kIHR5cGUgb2YgbWVzc2FnZXMuDQoNCj4gDQo+
ID4gQ291bGQgd2UgZ2V0IGZlZWQtYmFjayBmcm9tIHRoZSBXRyB0aGVyZSAod2hldGhlciB0aGUg
aHlwb3RoZXNpcyBzdGF0ZWQgYWJvdmUgYXJlDQo+IGFjY2VwdGFibGUsIGFuZCB3aGV0aGVyIHRo
ZXkgbWF5IHByZXZlbnQgc29tZXRoaW5nIGZyb20gd29ya2luZywgYXJlIGluY29tcGF0aWJsZQ0K
PiB3aXRoIHNvbWV0aGluZykuDQo+ID4NCj4gPiBBIHJlbGF0ZWQgcG9pbnQgaXMgdGhlIGZvbGxv
d2luZyBuYW1pbmcgcXVlc3Rpb246DQo+ID4gU2hhbGwgY29vcmRpbmF0aW9uIGZ1bmN0aW9uIGlu
c3RhbmNlcyBiZSBjYXRlZ29yaXplZCBhcyBBU0Egb3Igc2hhbGwgdGhleSBiZWxvbmcgdG8NCj4g
YSBkaWZmZXJlbnQgY2F0ZWdvcnkgPw0KPiA+IE9mIGNvdXJzZSB0aGlzIGRpZmZlcmVudCBjYXRl
Z29yeSBpcyBleHBlY3RlZCB0byBiZSBHUkFTUCBDbGllbnRzLg0KPiANCj4gQWdhaW4sICJHUkFT
UCBjbGllbnQiIGlzbid0IGRlZmluZWQuIEknbGwgYXNzdW1lICJHUkFTUCB1c2VyIi4NCj4gDQo+
ID4gSSBwZXJzb25hbGx5IGNvbnNpZGVyIGEgZGlmZmVyZW50IG5hbWluZyB3b3VsZCBlYXNlIHRo
ZSB1bmRlcnN0YW5kaW5nLCBmb3IgMg0KPiByZWFzb25zOg0KPiA+ICAgLSBBU0EgaW5zdGFuY2Vz
IGFyZSBwaWVjZXMgb2YgYW4gYXV0b25vbWljIGZ1bmN0aW9uLCB3aGlsZSBjb29yZGluYXRpb24g
aXMgYQ0KPiB1dGlsaXR5IHdoaWNoIHBhcnRpY2lwYXRlcyBpbiBtYW5hZ2luZyBhdXRvbm9taWMg
ZnVuY3Rpb25zLg0KPiA+ICAgLSBBU0EgaW5zdGFuY2VzIGR1dGllcyBhcmUgZGlmZmVyZW50IHRo
YXQgQ29vcmRpbmF0aW9uIGluc3RhbmNlcyBkdXRpZXMsIGUuZy4NCj4gPiAgICAgICAgICAgIDEu
IEFuIEFTQSBJbnN0YW5jZSBwYXJ0IG9mIGFuIEF1dG9ub21pYyBmdW5jdGlvbiBpcyBtZWFudCB0
byBzZWxmLQ0KPiBkZXNjcmliZSBpdHNlbGYgZm9yIGNvb3JkaW5hdGlvbiB0byBoYXBwZW4sIGFu
ZCBzaG91bGQgdGhlbiBjb21wbHkgdG8gcmVxdWlyZW1lbnRzLA0KPiB3aGlsZSBjb29yZGluYXRp
b24gZnVuY3Rpb24gaW5zdGFuY2VzIGhhdmUgZGlmZmVyZW50IHJlcXVpcmVtZW50cy4NCj4gPiAg
ICAgICAgICAgIDIuIEEgY29vcmRpbmF0aW9uIGZ1bmN0aW9uIGluc3RhbmNlIG1heSBzZW5kIGlt
cGVyYXRpdmUgY29tbWFuZCB0bw0KPiBBdXRvbm9taWMgRnVuY3Rpb25zIChpLmUuIEFTQSBJbnN0
YW5jZXMpLCB3aGlsZSBhbiBBdXRvbm9taWMgRnVuY3Rpb24gaXMgY2VydGFpbmx5DQo+IG5vdCBl
bnRpdGxlZCBzdWNoIHBlcm1pc3Npb25zIG92ZXIgb3RoZXIgQXV0b25vbWljIEZ1bmN0aW9ucy4N
Cj4gPiBEdXJpbmcgQXRoZW5zIFdTLCBNaWNoYWVsIG5hbWVkIHRoaXMgY2F0ZWdvcnkgIm1hbmFn
ZW1lbnQgYmxvYnMiLCB3aGF0IHdvdWxkIGJlDQo+IG5hbWluZyB0aGF0IGNvdWxkIGJlIGFncmVl
ZCBvbj8NCj4gDQo+IEkgY2FuIGhhdmUgbm8gb3BpbmlvbiBhYm91dCB0aGlzIHVudGlsIHlvdSBj
YW4gYW5zd2VyIG15IHF1ZXN0aW9uIGFib3ZlIGFib3V0IG1lc3NhZ2UNCj4gdHlwZXMuIElmIHdl
IGNhbiBtYXAgdGhlIGNvb3JkaW5hdGlvbiBpbnRlcmFjdGlvbnMgb250byB0aGUgZXhpc3Rpbmcg
R1JBU1ANCj4gaW50ZXJhY3Rpb25zIChkaXNjb3ZlciwgbmVnb3RpYXRlLCBzeW5jaHJvbml6ZSwg
Zmxvb2QpIHRoZW4gSSB3b3VsZCBzdWdnZXN0IHRvDQo+IG1pbmltaXplIHRoZSB0ZXJtaW5vbG9n
eSBieSBjYWxsaW5nIHRoZW0gQ0FTQXMgKENvb3JkaW5hdGluZyBBU0FzKS4gSWYgd2UgbmVlZCBu
ZXcNCj4gR1JBU1AgbWVzc2FnZXMsIHdlIGNhbiBkaXNjdXNzLg0KDQpSZWZlcnJpbmcgdG8gb25l
IG9mIHRoZSBwcmV2aW91cyBwb2ludCBvZiB0aGUgZW1haWwsIGNvb3JkaW5hdGlvbiBmdW5jdGlv
biBub3QgYmVpbmcgYW4gYXV0b25vbWljIGZ1bmN0aW9uIGJ1dCBvbmUgb2YgdGhlIG1hbmFnZW1l
bnQgZnVuY3Rpb24gb2YgYXV0b25vbWljIGZ1bmN0aW9uLCBJIGRvIG5vdCBsaWtlIG5hbWluZyB0
aGVtIEFTQSBub3Igc29tZXRoaW5nIEFTQSANCg0KPiBXaGVuIGNvbnNpZGVyaW5nIHRoaXMsIHJl
bWVtYmVyIHRoYXQgYSBHUkFTUCBPYmplY3RpdmUgY2FuIGhhdmUgYW55IGRhdGEgc3RydWN0dXJl
DQo+IGFuZCBhbnkgc2VtYW50aWNzIHRoYXQgeW91IHdhbnQgaW4gaXRzICd2YWx1ZScgZmllbGQu
DQo+IA0KPiBJIGFtIHRoaW5raW5nIGFib3V0IHNpeCBBU0FzIGVhY2ggc3VwcG9ydGluZyBpdHMg
b3duIG9iamVjdGl2ZToNCj4gImxlZyIsICJ0YWlsIiwgInRydW5rIiwgImVhciIsICJiZWxseSIs
ICJ0dXNrIiouIEJ1dCB0aGV5IGVhY2ggYWxzbyBzeW5jaHJvbml6ZSBhbg0KPiBvYmplY3RpdmUg
Y2FsbGVkICJjb29yZGluYXRlX2VsZXBoYW50IiB3aGljaCBpcyBzdXBwb3J0ZWQgYnkgYSBDQVNB
Lg0KPiBXZSBkZWZpbmUgdGhlIHNlbWFudGljcyBvZiAiY29vcmRpbmF0ZV9lbGVwaGFudCIgc28g
dGhhdCBlYWNoIEFTQSBvYmV5cyB0aGUNCj4gaW5zdHJ1Y3Rpb25zIG9mIHRoZSBDQVNBLg0KPiAN
Cj4gKiBodHRwczovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9CbGluZF9tZW5fYW5kX2FuX2VsZXBo
YW50DQo+IA0KPiAuLi4NCj4gPj4gTm8sIEkgZG9uJ3QgdGhpbmsgc28uIEZvciBhIGxvbmcgdGlt
ZSB3ZSdsbCBoYXZlIG5ldHdvcmtzIHdoZXJlIG5vdA0KPiA+PiBhbGwgbm9kZXMgYXJlIGF1dG9u
b21pYy4gSSB0aGluayBpdCBpcyBsaWtlbHkgdGhhdCB3ZSBoYXZlIEFTQXMgdGhhdA0KPiA+PiBh
bHNvICJtYW5hZ2UiIG90aGVyLCBub24tIGF1dG9ub21pYyBub2Rlcy4gTm93LCB5b3UgY291bGQg
YXJndWUsIHRoYXQNCj4gPj4gaXMgb3V0IG9mIHNjb3BlIGZvciBHUkFTUCBhbmQgdGhhdCdzIHBy
b2JhYmx5IHRydWUuIEJ1dCB3ZSBzaG91bGRuJ3QgZm9yZ2V0IHRoaXMNCj4gbW9kZWwuDQo+IA0K
PiA+IEZyb20gYSBkZXBsb3ltZW50IHBvaW50IG9mIHZpZXcsIHRoZXJlIGFyZSBwbGVudHkgb2Yg
ZGlmZmVyZW50IHdheXMgb2YgbGlua2luZyBhbg0KPiBBU0EgaW5zdGFuY2Ugd2l0aCBhIGRldmlj
ZSBpbnN0YW5jZSwgdGhlIEFTQSBpbnN0YW5jZSBjYW4gYmUgaW5zaWRlIHRoZSBkZXZpY2UgT1Ms
DQo+IGJ1dCBjYW4gYmUgaG9zdGVkIG9uIGEgcmVtb3RlIGhvc3QgYW5kIGludGVyYWN0IHdpdGgg
dGhlIGRldmljZSB0aHJvdWdoIE9wZW5GbG93LA0KPiBTTk1QLCBDTEkgLi4uIFRoZSBjb25zdHJh
aW50cyBtYXkgY29tZSBmcm9tIHRoZSBBU0EgY29kZSBvciBmcm9tIHRoZSBkZXZpY2UNCj4gY2Fw
YWNpdGllcywgaGVuY2UgSSBkZWZpbml0ZWx5IGFncmVlIHdpdGggTWljaGFlbCBvbiB0aGF0Lg0K
PiANCj4gV2UgYWxsIGFncmVlLiBUaGUgQVNBIHVzZXMgdGhlIEdSQVNQIEFQSSBmb3IgaXRzIGF1
dG9ub21pYyBpbnRlcmFjdGlvbnMsIGJ1dCBob3cgaXQNCj4gYWN0dWFsbHkgbWFuYWdlcyBpdHMg
dGFyZ2V0IGRldmljZShzKSBpcyBjb21wbGV0ZWx5IG9wZW4uDQo+IA0KPiA+DQo+ID4+Pj4g4oCc
T3JnYW5pemluZyBvZiBzeW5jaHJvbml6YXRpb24gb3IgbmVnb3RpYXRpb24gY29udGVudOKAnSBi
dWxsZXQgcG9pbnQNCj4gPj4+PiBpbg0KPiA+Pj4gU2VjdGlvbiAzLjIuIEkgYmVsaWV2ZSB0aGlz
IHBvaW50IHNob3VsZCBiZSByZXdyaXR0ZW4gYXMgYQ0KPiA+Pj4gcmVjb21tZW5kYXRpb24gZm9y
IEFTQS4gR1JBU1AgaXMgYSBnZW5lcmljIHBsYXRmb3JtLiBDb25zZXF1ZW50bHksDQo+ID4+PiBp
dCBpcyBpbmRlcGVuZGVudCBmcm9tIGNvbnRlbnQgb3JnYW5pemluZy4NCj4gPj4+DQo+ID4+PiBD
b3JyZWN0LiBGcm9tIHRoZSB3b3JrIEkndmUgZG9uZSBvbiB0aGUgcmVmZXJlbmNlIG1vZGVsIGFu
ZCB0aGUNCj4gPj4+IEdSQVNQIEFQSSwgSSB0aGluayB3ZSB3aWxsIG5lZWQgYSBkb2N1bWVudCBh
bGwgYWJvdXQgQVNBcyBhbmQgaG93DQo+ID4+PiB0aGV5IGFyZSBvcmdhbml6ZWQuDQo+ID4+DQo+
ID4+IEFncmVlLiBUaGlzIHNob3VsZCBwcm9iYWJseSBiZSBhbm90aGVyIHNlY3Rpb24gaW4gdGhl
IHJlZmVyZW5jZQ0KPiA+PiBtb2RlbC4gIEFueSB2b2x1bnRlZXIgZm9yIHNvbWUgdGV4dD8NCj4g
PiBTb21lIHNob3J0IHRleHQgZm9yIHRoZSByZWZlcmVuY2UgbW9kZWwgaXMgb24gbXkgd29yayB0
YWJsZS4NCj4gDQo+IEFzIEkgYWxyZWFkeSBzYWlkLCBJIG1hZGUgc29tZSB1cGRhdGVzIHRvIHRo
ZSByZWZlcmVuY2UgbW9kZWwgb24gR2l0SHViLCBidXQgd2UgYXJlDQo+IG5vdCBkb25lIHlldC4N
Cj4gDQo+ID4gQSBmdWxsIGRvY3VtZW50IGFib3V0IEFTQSBhbmQgaG93IHRoZXJlIG1hbmFnZW1l
bnQgYWxyZWFkeSBleGlzdHMsIHRoZSB3b3JrIGlzIG5vdA0KPiBjb21wbGV0ZSwgYnV0IHRoZXJl
IGlzIGFscmVhZHkgYSBidW5jaCBvZiBtYXRlcmlhbCB0aGVyZTogZHJhZnQtcGVsb3NvLWFuaW1h
LQ0KPiBhdXRvbm9taWMtZnVuY3Rpb24tMDEsIHNvIG1heWJlIG5vdCB3b3J0aCBzdGFydGluZyBm
cm9tIHNjcmF0Y2ggYSBuZXcgZG9jIHdoeSBub3QNCj4gYnVpbGRpbmcgdXBvbiBpdD8NCj4gPg0K
PiA+IEFkZGl0aW9uYWxseSwgdGhpcyBkb2N1bWVudCBhbmQgdGhlIHByZXNlbnRhdGlvbnMgb2Yg
aXQgbWFkZSBib3RoIGluIFlva29oYW1hIGFuZA0KPiBCdWVub3MgQWVyZXMgZXhwbGljaXQgdGhl
IG5lZWRzIGFuZCB0aGUgZmllbGRzIHJlcXVpcmVkIGZvciBBU0Egc2VsZi1kZXNjcmlwdGlvbg0K
PiAoZS5nLiBvbiBzdGFydHVwKSAoc2VlIHNlY3Rpb24gNikuDQo+IA0KPiBJIGhhdmVuJ3QgbG9v
a2VkIGF0IHRoYXQgZm9yIGEgd2hpbGUsIGJ1dCBhZ2FpbiBJIGNhbiBzZWUgaG93IHdlIGNhbiBt
YXAgdGhhdCB0byBhDQo+IEdSQVNQIG9iamVjdGl2ZSwgZm9yIGV4YW1wbGUgaWYgdGhlIEFTQSBp
cyBjYWxsZWQgImFiYyIgdGhlbiBpdHMgbWFuaWZlc3QgY291bGQgYmUgYQ0KPiBzeW5jaHJvbml6
YXRpb24gb2JqZWN0aXZlIGNhbGxlZCAiYWJjLm1hbmlmZXN0IiBvciB3aGF0ZXZlciBjb252ZW50
aW9uIHdlIGNob29zZS4NCkkgYW0gY29udmluY2VkIHRoZXJlIGlzIGEgc3Ryb25nZXIgdGllIGJl
dHdlZW4gb2JqZWN0aXZlcyBhbmQgbWFuaWZlc3QgZmllbGRzIHNlZSBiZWxvdw0KW1JlY29waWVk
XQ0KQSBzdGlsbCBwZW5kaW5nIHF1ZXN0aW9uIGlzIHdoZXRoZXIsIHdlIHNob3VsZCBlbWJlZCB0
aGUgZnVsbA0Kc2VsZi1kZXNjcmlwdGlvbiBpbiBhIHNpbmdsZSBvYmplY3RpdmUsIG9yIHNob3Vs
ZCB3ZSBzcGxpdCBlYWNoDQpzZWN0aW9uIGluIGEgZGlmZmVyZW50IG9iamVjdGl2ZXMgYXMgdGhl
IG9iamVjdGl2ZSBtb2RpZmllcnMgc2hvdWxkIGJlIGRpZmZlcmVudA0KZGVwZW5kaW5nIHdoZXRo
ZXIgdGhlIHBhcnQgb2YgdGhlIHNlbGYgZGVzY3JpcHRpb24gZGlzY2xvc2VzIG1ldHJpY3Mgb3Ig
cGFyYW1ldGVycy4NCltlbmQgb2YgY29weV0NCj4gPiBEdXJpbmcgQXRoZW5zIFdTLCB0aGVyZSB3
YXMgYSBzb2Z0IGNvbnNlbnN1cyBvbiB1c2luZyB0aGUgR1JBU1AgZGlzY292ZXJ5IG1lc3NhZ2UN
Cj4gdG8gZGlzY2xvc2UgdGhlIEFTQXMgc2VsZi1kZXNjcmlwdGlvbi4NCj4gDQo+IFRoYXQgd291
bGQgYmUgZGlzY292ZXIoKSBmb2xsb3dlZCBieSBzeW5jaHJvbml6ZSgpLiBJZiB5b3UgYWdyZWUg
d2l0aCB0aGUNCj4gImFiYy5tYW5pZmVzdCIgY29udmVudGlvbiB3ZSBjYW4gd3JpdGUgdGhlIGNv
ZGUgaW4gUHl0aG9uIHRvbW9ycm93Lg0KPg0KW1doZXJlIHRoZSBjb3B5IHdhc10NCj4gDQo+IEFn
YWluLCB0aGF0IGlzIG9ubHkgYSBtYXR0ZXIgb2YgaG93IHdlIGNob29zZSB0byBkZWZpbmUgaXQu
IEkgZG9uJ3Qgc2VlIGVpdGhlcg0KPiBhcHByb2FjaCBjcmVhdGluZyBhIHRlY2huaWNhbCBkaWZm
Y3VsdHkuIEkgdGhpbmsgd2UnZCBuZWVkIHRvIHBsYXkgd2l0aCBzb21lIHJlYWwNCj4gZXhhbXBs
ZXMgdG8gZGlzY292ZXIgdGhlIGJlc3QgYXBwcm9hY2guIChBbmQgYmVmb3JlIHdlIGdvIHRvbyBm
YXIsIHRoaXMgc2VlbXMgbGlrZSBhbg0KPiBhcmVhIHdoZXJlIHdlIGRlZmluaXRlbHkgbmVlZCBh
biBpbmZvcm1hdGlvbiBtb2RlbC4pDQoNCkluIG9yZGVyIHRvIGdhaW4gaW4gbXV0dWFsIHVuZGVy
c3RhbmRpbmcgb24gdGhpcyBzcGVjaWZpYyBhc3BlY3QsIGFuZCBiZWZvcmUgd29ya2luZyBvbiBl
eGFtcGxlcyAod2hpY2ggaXMgZmluZSksIEkgZW5jb3VyYWdlIHlvdSB0byBoYXZlIGEgZGVlcGVy
IGxvb2sgaW4gd2hhdCBpcyB0aGUgSW5zdGFuY2UgbWFuaWZlc3QgYW5kIHRoZSBsaWZlLWN5Y2xl
IHdlIHByb3Bvc2UgKHNlZSBkcmFmdC1wZWxvc28tYW5pbWEtYXV0b25vbWljLWZ1bmN0aW9uLTAx
IHNlY3Rpb24gNiBhbmQgNyBhbmQgTGF1cmVudCdzIHByZXNlbnRhdGlvbikuIFRoZXNlIGl0ZW1z
IGhhdmUgbm90IGJlZW4gYnVpbHQgb3V0IG9mIHB1cmUgdGhlb3J5LCBidXQgb3V0IG9mIGNvbmZy
b250aW5nIG91cnNlbHZlcyB0byBtYW55IGV4YW1wbGVzIGFuZCBnZW5lcmFsaXppbmcgdGhlIGV4
ZW1wbGlmaWVkIHNvbHV0aW9ucy4gDQogDQo+ID4gQ291bGQgdGhlcmUgYmUgc29tZSBhZGRpdGlv
bmFsIGZlZWQtYmFjaz8gU2hvdWxkIEkgY2xhcmlmeSB0aGUgcXVlc3Rpb24gZmlyc3Q/DQo+IA0K
PiBBIGNvbmNyZXRlIGV4YW1wbGUgd291bGQgYmUgdmVyeSBoZWxwZnVsLg0KPiANCj4gSSB0aGlu
ayBJIGNhdWdodCBhbGwgeW91ciBwb2ludHMsIFBpZXJyZSwgcGxlYXNlIHRlbGwgbWUgaWYgbm90
Lg0KPiANCj4gUmVnYXJkcw0KPiAgICAgQnJpYW4NCg0KDQo=


From nobody Wed Jul 13 09:17:18 2016
Return-Path: 
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0AB212D15E; Wed, 13 Jul 2016 09:17:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 KazZbYgULmM8; Wed, 13 Jul 2016 09:17:14 -0700 (PDT)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 D23FB12D0DC; Wed, 13 Jul 2016 09:17:13 -0700 (PDT)
Received: by mail-wm0-x233.google.com with SMTP id f65so35552309wmi.0; Wed, 13 Jul 2016 09:17:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=qxgN/2buQGL2PvUyKJyrmJFEgoqc2XTd9t/Plmcd9QA=; b=bx7FKIa5pTgbvnpeG5bYZYCED5sLSRzSVcZudLfn9rJPFlQs2RzCcso2m7Bgdv/ZYC 1kowiR/YY8+D0EtphLsD13NML2EUOP3/pKmW9otSUeOCWtW5MBJcfEGIGVcwuOlLHs5M Eju5ngv7vluTqms0nPw1LV6KOPu/hbOgy7r2MlzX4jcDe02st4C2h+InLB5IIRPuIhv9 6WJDWJVKFAHqPPMP1KC3RL3cAU0JvtRwVy6XwPpkjugShW0QTvsbH8fvGLrX3Hxe3pJC 40+oM2nfknR/LMX4amdEsTbSHT4SYUogEEBCIh8+5P8vNucw2BuolSfCYGoPZ5sL1Yn6 KPZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=qxgN/2buQGL2PvUyKJyrmJFEgoqc2XTd9t/Plmcd9QA=; b=OVi7VDotaeOIUmAGdVTOFZ5ciMnedELyLhgY0RP+2uSW3y31hzgG+ckGFvj4ECE6DN Bgn8kwUm5h5vi5ODCfAbdJTg8T30+qKoPbpOez88qAUWj7enDxZ6hmex00gPVanktcep ABYFwzvxb9eo6O6YICsZDCf778V/WryBPvOuLwBAEHSBzn7mZrPpBEnjdmx8CTt/tOyY pRbRnOd+SqlMzPwxU9C5IfDyRlLD69tGoReh1WZ107DEFp58YzU6UvYS/NJx8TMmj9CS Kwq5OZQ95q/Bel0TaxmtNN4jRkstYA6Db5h3hJ8mrzzXh8ZxLM8Cqw4ekOagNY7hDa8P VqyQ==
X-Gm-Message-State: ALyK8tKoogw1j/0KkjJt4AQK5UdmacabbDhcRS668xSxHtB3gsIQMG07mHYW95o3Qlu4Qg==
X-Received: by 10.28.14.75 with SMTP id 72mr27049564wmo.85.1468426632117; Wed, 13 Jul 2016 09:17:12 -0700 (PDT)
Received: from [10.0.1.29] (cpc66883-mort6-2-0-cust696.19-2.cable.virginm.net. [92.233.126.185]) by smtp.gmail.com with ESMTPSA id o142sm37234077wme.20.2016.07.13.09.17.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jul 2016 09:17:11 -0700 (PDT)
To: "Peloso, Pierre (Nokia - FR)" , "Michael Behringer (mbehring)" , Sheng Jiang , "anima@ietf.org" , "draft-ietf-anima-grasp.all@ietf.org" 
References:   
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <085c2600-04a1-40a4-4df1-6a5e7fc0b0ca@gmail.com>
Date: Thu, 14 Jul 2016 04:17:16 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Anima] ASA management discussions [was snip of] Review of ANIMA GRASP
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Jul 2016 16:17:17 -0000

Hi,

Comments in line.

On 14/07/2016 00:16, Peloso, Pierre (Nokia - FR) wrote:
> Hi Brian and all,
>=20
> Though coming late, I take some of the points discussed there are worth=
 being pushed further.
> By the way, I renamed the discussion thread in ASA management were the =
main concerns addressed in these snipped points.
> A way to make clear that these points go beyond GRASP design, but conce=
rn ANIMA WG as a whole.
>=20
> Thanks for your answers....
>=20
> Pierre
>=20
>> -----Message d'origine-----
>> De : Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
>> Envoy=C3=A9 : samedi 2 juillet 2016 09:50
>> =C3=80 : Peloso, Pierre (Nokia - FR); Michael Behringer (mbehring); Sh=
eng Jiang;
>> anima@ietf.org; draft-ietf-anima-grasp.all@ietf.org
>> Objet : Re: [Anima] Review of ANIMA GRASP
>>
>> Pierre,
>>
>> Let me try to answer your points below. I have deleted a lot of text t=
o make the
>> message short enough to read. Also, please note that my main concern f=
or now is to
>> ensure that GRASP does everything we need; many aspects that are speci=
fic to ASA
>> design do not affect this.
>> On 02/07/2016 03:50, Peloso, Pierre (Nokia - FR) wrote:
>> ...
>>>> Yes, the reference model should give the general overview, so this
>>>> discussion should to a large extent go there.
>>> Seems fair to me to have some more of these in the reference model.
>>> Inside draft-peloso-anima-autonomic-function, there is text on the ro=
le of ASA and
>> their management.
>>> Why not building upon it ?
>>
>> Certainly, but we need a common view and the reference model must not =
become too long
>> and complex, or nobody will read it. So I still suspect we need a sepa=
rate document
>> on ASA design.
>=20
> I think we reached this point:
>  - having some light additions to the reference model to keep it readab=
le,
>  - having a separate document on ASA design: just need augmenting/modif=
ying the draft we proposed from before IETF 94th.
> =20
>> ...
>>>> ... and it MUST be possible. We've just had the workshop on AN in
>>>> Athens, and one big discussion point was the coordination function.
>>>> While we haven't concluded whether this coordination function is
>>>> itself an ASA or part of the infrastructure, we do NOT want to make
>>>> it technically impossible for a coordination function to be an ASA. =
This is a good
>> example of two ASAs on the same device having to communicate.
>>> At this point 2 comments:
>>>    1 - There may definitely be two different ASAs willing to modify t=
he same device
>> parameter...
>>
>> Yes, but a device parameter is not the same thing as a GRASP objective=
=2E I have great
>> difficulty with the thought of two ASAs *in the same device* that are =
both actively
>> negotiating the same GRASP objective.
>=20
> If a device parameter modified by an ASA is not one of the ASA objectiv=
es, then what is an objective ? Can you provide example of what you have =
in mind ?

Perhaps I was not clear. There are two parts to this:

1) An objective is (quoting the GRASP spec)
"  o  Technical Objective (usually abbreviated as Objective): A
      technical objective is a configurable parameter or set of
      parameters of some kind, which occurs in three contexts:
      Discovery, Negotiation and Synchronization.  In the protocol, an
      objective is represented by an identifier and if relevant a value.
      Normally, a given objective will not occur in negotiation and
      synchronization contexts simultaneously."

By definition, an Objective is managed by an ASA, using the synchronizati=
on
or negotiation method when it needs to communicate with a peer ASA.
So what would be the meaning of having two ASAs *in the same node*
managing the same Objective?

2) A traditional device parameter might normally be mapped 1:1 into
an Objective, but do we want to make that a rule? Do we want to exclude
cases where an autonomic objective is more abstract than that, so that
the same device parameter is affected by more than one Objective? For
example consider a QoS Objective and a Congestion Objective. They might
both want to change some underlying queueing parameters in a router.
There's a coordination problem within the node, to be solved by the ASAs.=


>=20
>>
>> If two ASAs modify the same underlying device parameter, that must of =
course be
>> coordinated at device level. It seems like a quite traditional problem=
 needing a lock
>> and/or a token.
>>
>> If two ASAs in *different* devices negotiate the same GRASP objective =
that is of
>> course absolutely normal and might not create any coordination issue, =
depending on
>> the semantics of the objective.
>>
>>>    2 - Michael is dealing here with the role of coordination function=
 with regards
>> to GRASP: During the WS discussions,  there was a sort of soft-agreeme=
nt that:
>>>            - coordination function can be distributed,
>>
>> Of course (and that's the reason I recently became interested in distr=
ibuted
>> consensus algorithms).
>>
>>>            - coordination function instances should contain a GRASP
>>> client,
>>
>> What's a GRASP client? We have initiators and responders in GRASP. You=
 can think of
>> the initiator as a client and the responder as a server, but any ASA c=
an be both
>> initiator and responder.
> In my understanding there is in each Autonomic Node a GRASP Engine. Fro=
m that I derive there is a sort of API the ASA should have to push a mess=
age to GRASP and receives the coming ones. So basically, a client is the =
API for both the initiator and the responder.

There is an API and there is a draft:
https://tools.ietf.org/html/draft-liu-anima-grasp-api

>=20
> The point above mentioning that coordination function should contain a =
GRASP client, was just to mean that coordination function should be capab=
le of initiating and responding to GRASP signaling (hence bind to a GRASP=
 engine).=20
> Which may not be clear here is the implicit:
> Coordination function is not an ASA (at least in my opinion).
> Why not? Because an ASA is an agent of an autonomic function. Coordinat=
ion function is not an autonomic function.
> It is a meta function in charge of insuring coordination between autono=
mic functions.
> Then why not generalize and state that nevertheless let it be an ASA?
> Because all we've been stressing since the beginning of ANIMA is that A=
SA have to comply to a life-cycle* and duties (like self-describing). Tho=
ugh coordination function may have a life-cycle and duties, I am sure tho=
se are different than the ones.
> That is why I place the generalization 1 level higher: ASA and Coordina=
tion function contain a GRASP client.=20

That's just terminology; I don't object, but as far as GRASP is concerned=

a coordination function looks exactly like an ASA.

> =20
> * Btw, I saw you just draw some deployment of ASA, and this deployment =
is just one of the point we've pointed as being part of the ASA life-cycl=
e.
>=20

Yes, certainly.

>>>            - it was not clear yet whether coordination would be compl=
etely external
>> to ANI (like ASA sitting on top of ANI), or would have some pieces emb=
edded in ANI.
>>
>> My opinion: the semantics of coordination are very dependent on the in=
dividual use
>> case. So I am not sure what generic support we could provide, beyond b=
asic GRASP. If
>> you can specify the sort of interaction required between two coordinat=
ors *in the
>> general case* we can then see whether it needs any new GRASP message t=
ypes.
>=20
> If you're not convinced that a generic support to coordinate AF is feas=
ible, I then encourage you to attend the presentations that Laurent will =
be giving during ANIMA meeting in Berlin. It specifically addresses this =
point.
> There are some requirements to signaling in this presentation (same as =
the one already presented at Yokohama and Buneos Aeres): mainly having co=
mmand type of messages.

A command is an imperative request, so I think can probably be mapped dir=
ectly
onto a GRASP Request Negotiation message. It's probably a negotiation wit=
h a loop
count =3D 1 since no negotiation is possible, but that depends on the exa=
ct semantics
you need. If that doesn't work out, we could add a new GRASP message type=
,
but since it would presumably need a command/response cycle, I think the
existing request/end messages should work well.

>=20
>>
>>> Could we get feed-back from the WG there (whether the hypothesis stat=
ed above are
>> acceptable, and whether they may prevent something from working, are i=
ncompatible
>> with something).
>>>
>>> A related point is the following naming question:
>>> Shall coordination function instances be categorized as ASA or shall =
they belong to
>> a different category ?
>>> Of course this different category is expected to be GRASP Clients.
>>
>> Again, "GRASP client" isn't defined. I'll assume "GRASP user".
>>
>>> I personally consider a different naming would ease the understanding=
, for 2
>> reasons:
>>>   - ASA instances are pieces of an autonomic function, while coordina=
tion is a
>> utility which participates in managing autonomic functions.
>>>   - ASA instances duties are different that Coordination instances du=
ties, e.g.
>>>            1. An ASA Instance part of an Autonomic function is meant =
to self-
>> describe itself for coordination to happen, and should then comply to =
requirements,
>> while coordination function instances have different requirements.
>>>            2. A coordination function instance may send imperative co=
mmand to
>> Autonomic Functions (i.e. ASA Instances), while an Autonomic Function =
is certainly
>> not entitled such permissions over other Autonomic Functions.
>>> During Athens WS, Michael named this category "management blobs", wha=
t would be
>> naming that could be agreed on?
>>
>> I can have no opinion about this until you can answer my question abov=
e about message
>> types. If we can map the coordination interactions onto the existing G=
RASP
>> interactions (discover, negotiate, synchronize, flood) then I would su=
ggest to
>> minimize the terminology by calling them CASAs (Coordinating ASAs). If=
 we need new
>> GRASP messages, we can discuss.
>=20
> Referring to one of the previous point of the email, coordination funct=
ion not being an autonomic function but one of the management function of=
 autonomic function, I do not like naming them ASA nor something ASA=20

Well, arguing about names is not very interesting, but I would suggest th=
at
this will turn out to be a recursive matter ("Quis custodiet ipsos custod=
es").

>=20
>> When considering this, remember that a GRASP Objective can have any da=
ta structure
>> and any semantics that you want in its 'value' field.
>>
>> I am thinking about six ASAs each supporting its own objective:
>> "leg", "tail", "trunk", "ear", "belly", "tusk"*. But they each also sy=
nchronize an
>> objective called "coordinate_elephant" which is supported by a CASA.
>> We define the semantics of "coordinate_elephant" so that each ASA obey=
s the
>> instructions of the CASA.
>>
>> * https://en.wikipedia.org/wiki/Blind_men_and_an_elephant
>>
>> ...
>>>> No, I don't think so. For a long time we'll have networks where not
>>>> all nodes are autonomic. I think it is likely that we have ASAs that=

>>>> also "manage" other, non- autonomic nodes. Now, you could argue, tha=
t
>>>> is out of scope for GRASP and that's probably true. But we shouldn't=
 forget this
>> model.
>>
>>> From a deployment point of view, there are plenty of different ways o=
f linking an
>> ASA instance with a device instance, the ASA instance can be inside th=
e device OS,
>> but can be hosted on a remote host and interact with the device throug=
h OpenFlow,
>> SNMP, CLI ... The constraints may come from the ASA code or from the d=
evice
>> capacities, hence I definitely agree with Michael on that.
>>
>> We all agree. The ASA uses the GRASP API for its autonomic interaction=
s, but how it
>> actually manages its target device(s) is completely open.
>>
>>>
>>>>>> =E2=80=9COrganizing of synchronization or negotiation content=E2=80=
=9D bullet point
>>>>>> in
>>>>> Section 3.2. I believe this point should be rewritten as a
>>>>> recommendation for ASA. GRASP is a generic platform. Consequently,
>>>>> it is independent from content organizing.
>>>>>
>>>>> Correct. From the work I've done on the reference model and the
>>>>> GRASP API, I think we will need a document all about ASAs and how
>>>>> they are organized.
>>>>
>>>> Agree. This should probably be another section in the reference
>>>> model.  Any volunteer for some text?
>>> Some short text for the reference model is on my work table.
>>
>> As I already said, I made some updates to the reference model on GitHu=
b, but we are
>> not done yet.
>>
>>> A full document about ASA and how there management already exists, th=
e work is not
>> complete, but there is already a bunch of material there: draft-peloso=
-anima-
>> autonomic-function-01, so maybe not worth starting from scratch a new =
doc why not
>> building upon it?
>>>
>>> Additionally, this document and the presentations of it made both in =
Yokohama and
>> Buenos Aeres explicit the needs and the fields required for ASA self-d=
escription
>> (e.g. on startup) (see section 6).
>>
>> I haven't looked at that for a while, but again I can see how we can m=
ap that to a
>> GRASP objective, for example if the ASA is called "abc" then its manif=
est could be a
>> synchronization objective called "abc.manifest" or whatever convention=
 we choose.

> I am convinced there is a stronger tie between objectives and manifest =
fields see below
> [Recopied]
> A still pending question is whether, we should embed the full
> self-description in a single objective, or should we split each
> section in a different objectives as the objective modifiers should be =
different
> depending whether the part of the self description discloses metrics or=
 parameters.
> [end of copy]

I think we have full liberty to decide this later. In fact that's one of =
the
reasons that the naming rule for Objectives, and the format of the value =
field
of an Objective, are both extremely flexible at the level of the GRASP pr=
otocol:
we can defer the question until we know the answer.

>>> During Athens WS, there was a soft consensus on using the GRASP disco=
very message
>> to disclose the ASAs self-description.
>>
>> That would be discover() followed by synchronize(). If you agree with =
the
>> "abc.manifest" convention we can write the code in Python tomorrow.
>>
> [Where the copy was]
>>
>> Again, that is only a matter of how we choose to define it. I don't se=
e either
>> approach creating a technical diffculty. I think we'd need to play wit=
h some real
>> examples to discover the best approach. (And before we go too far, thi=
s seems like an
>> area where we definitely need an information model.)
>=20
> In order to gain in mutual understanding on this specific aspect, and b=
efore working on examples (which is fine), I encourage you to have a deep=
er look in what is the Instance manifest and the life-cycle we propose (s=
ee draft-peloso-anima-autonomic-function-01 section 6 and 7 and Laurent's=
 presentation). These items have not been built out of pure theory, but o=
ut of confronting ourselves to many examples and generalizing the exempli=
fied solutions.=20

I'm sure of that. As I have said, my concern for now, given the Anima WG =
charter,
is to ensure that GRASP has all the flexibility needed.

Regards,
    Brian

> =20
>>> Could there be some additional feed-back? Should I clarify the questi=
on first?
>>
>> A concrete example would be very helpful.
>>
>> I think I caught all your points, Pierre, please tell me if not.
>>
>> Regards
>>     Brian
>=20
>=20


From nobody Thu Jul 14 00:26:44 2016
Return-Path: 
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD4DC12DAD0; Thu, 14 Jul 2016 00:26:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.507
X-Spam-Level: 
X-Spam-Status: No, score=-5.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 UquhmsEsJSrb; Thu, 14 Jul 2016 00:26:40 -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 F298B12B050; Thu, 14 Jul 2016 00:26:39 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CSN93305; Thu, 14 Jul 2016 07:26:37 +0000 (GMT)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 14 Jul 2016 08:26:36 +0100
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Thu, 14 Jul 2016 15:26:29 +0800
From: Sheng Jiang 
To: "anima@ietf.org" 
Thread-Topic: Primary ANIMA Agenda @ IETF 96, Berlin
Thread-Index: AdHdoLRYieQX/M//QRuCEQouV8haZQ==
Date: Thu, 14 Jul 2016 07:26:28 +0000
Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927CAC2FBC@NKGEML515-MBX.china.huawei.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.99.197]
Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B927CAC2FBCNKGEML515MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.57873EAE.0053, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: c47bd651b94ae2ba2dd28a61cbccc732
Archived-At: 
Cc: "anima-chairs@ietf.org" 
Subject: [Anima] Primary ANIMA Agenda @ IETF 96, Berlin
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jul 2016 07:26:42 -0000

--_000_5D36713D8A4E7348A7E10DF7437A4B927CAC2FBCNKGEML515MBXchi_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGksIEFOSU1BIGFsbCwNCg0KVGhlIGNoYWlycyBoYXZlIHVwbG9hZGVkIGEgcHJpbWFyeSBtZWV0
aW5nIGFnZW5kYSBmb3Igb3VyIEFOSU1BIFdHIHNlc3Npb25zIGluIEJlcmxpbiwgR2VybWFueS4N
Cg0KTW9uZGF5LCAxODowMC0yMDowMCwgQWZ0ZXJub29uIFNlc3Npb24gSUlJLCBQb3RzZGFtIElJ
DQpUaHVyc2RheSwgMTY6MjAtMTg6MjAsIEFmdGVybm9vbiBTZXNzaW9uIElJLCBQb3RzZGFtIElJ
SQ0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Ni9hZ2VuZGEvYWdlbmRhLTk2
LWFuaW1hDQoNCklmIHRoZXJlIGlzIGFueSBxdWVzdGlvbiBvciByZXF1ZXN0IG9uIHRoZSBhZ2Vu
ZGEsIHBsZWFzZSBsZXQgdGhlIGNoYWlycyBrbm93Lg0KDQpUaGUgc3BlYWtlcnMgcGxlYXNlIHNl
bmQgeW91ciBzbGlkZXMgdG8gdGhlIGNoYWlyIGluIGFkdmFuY2UsIHNvIHRoYXQgd2UgY291bGQg
dXBsb2FkIHRoZW0gYmVmb3JlIHRoZSBtZWV0aW5nLiBUaGUgc2xpZGVzIGFyZSBkdWUgYmVmb3Jl
IDRwbSBvbiBTdW5kYXksIEp1bHkgMTd0aC4NCg0KQmVzdCByZWdhcmRzLA0KDQpTaGVuZyArIFRv
ZXJsZXNzDQoNCg==

--_000_5D36713D8A4E7348A7E10DF7437A4B927CAC2FBCNKGEML515MBXchi_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg
MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ
cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K
cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K
CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJdGV4dC1qdXN0
aWZ5OmludGVyLWlkZW9ncmFwaDsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZvbnQtZmFtaWx5OiJD
YWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t
c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs
aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUt
cHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7
fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXtt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6Iue6r+aWh+acrCBDaGFyIjsN
Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0
Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt
dHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp
ZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkNoYXINCgl7bXNvLXN0eWxlLW5hbWU6Iue6
r+aWh+acrCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6
57qv5paH5pysOw0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t
c3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQovKiBQYWdlIERlZmluaXRpb25zICovDQpAcGFnZSBX
b3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4w
cHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x
O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz
IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp
ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h
cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp
Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVy
cGxlIiBzdHlsZT0idGV4dC1qdXN0aWZ5LXRyaW06cHVuY3R1YXRpb24iPg0KPGRpdiBjbGFzcz0i
V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5I
aSwgQU5JTUEgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIGNoYWlycyBoYXZlIHVwbG9hZGVk
IGEgcHJpbWFyeSBtZWV0aW5nIGFnZW5kYSBmb3Igb3VyIEFOSU1BIFdHIHNlc3Npb25zIGluIEJl
cmxpbiwgR2VybWFueS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk1vbmRheSwgMTg6MDAtMjA6MDAsIEFm
dGVybm9vbiBTZXNzaW9uIElJSSwgUG90c2RhbSBJSTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaHVyc2RheSwgMTY6MjAtMTg6
MjAsIEFmdGVybm9vbiBTZXNzaW9uIElJLCBQb3RzZGFtIElJSTxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+
PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTYvYWdlbmRhL2FnZW5k
YS05Ni1hbmltYSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTYvYWdlbmRhL2Fn
ZW5kYS05Ni1hbmltYTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPklmIHRoZXJlIGlzIGFueSBxdWVz
dGlvbiBvciByZXF1ZXN0IG9uIHRoZSBhZ2VuZGEsIHBsZWFzZSBsZXQgdGhlIGNoYWlycyBrbm93
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9
IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIHNwZWFrZXJzIHBsZWFzZSBzZW5kIHlvdXIgc2xpZGVz
IHRvIHRoZSBjaGFpciBpbiBhZHZhbmNlLCBzbyB0aGF0IHdlIGNvdWxkIHVwbG9hZCB0aGVtIGJl
Zm9yZSB0aGUgbWVldGluZy4gVGhlIHNsaWRlcyBhcmUgZHVlIGJlZm9yZSA0cG0gb24gU3VuZGF5
LCBKdWx5IDE3dGguPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9
IkVOLVVTIj5TaGVuZyAmIzQzOyBUb2VybGVzczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_5D36713D8A4E7348A7E10DF7437A4B927CAC2FBCNKGEML515MBXchi_--


From nobody Sun Jul 17 20:46:39 2016
Return-Path: 
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9CE412D0C9; Sun, 17 Jul 2016 20:46:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.807
X-Spam-Level: 
X-Spam-Status: No, score=-15.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 Na62W4Csf1fv; Sun, 17 Jul 2016 20:46:35 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC55112D0FC; Sun, 17 Jul 2016 20:46:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24556; q=dns/txt; s=iport; t=1468813595; x=1470023195; h=from:to:subject:date:message-id:mime-version; bh=BdsQdSy4FWx+la9jeXxG653jk4qx/jdiJWSbHuDMyCc=; b=Nb8gUO93x7Mx1ZEtNcHpxQ+WyJutdZabN/9N5fRaL7KpCVBHfmq5lYx/ TlBWB/emSBcivoJaFw3+q80mejtj4rDp02AfCGpuYLCRZFn0fVcj9o8el oRVretBDKa6m0XFBChus6X+PMk5zvVhYtU9G+R3hByM4aLCU/lzXX4NLj 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BFAgAYUIxX/5tdJa1SAQmCcU6BWLh0g?= =?us-ascii?q?XmHQzgUAQEBAQEBAWUnhGMMZhkBBjpAJwQBEIgylBaqfQEBAQcBAQEBI48PARG?= =?us-ascii?q?FcQWIJZB/AYE0jSqPN5AdAR42g3M/hicrGH8BAQE?=
X-IronPort-AV: E=Sophos;i="5.28,382,1464652800";  d="scan'208,217";a="298901087"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jul 2016 03:46:34 +0000
Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u6I3kYt8025497 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 18 Jul 2016 03:46:34 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 17 Jul 2016 23:46:33 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Sun, 17 Jul 2016 23:46:33 -0400
From: "Nancy Cam-Winget (ncamwing)" 
To: "anima@ietf.org" , "secdir@ietf.org" 
Thread-Topic: Initial review of draft-ietf-anima-bootstrapping-keyinfra-03
Thread-Index: AQHR4Kb6hoXgv1OH80i6Ph02ZsBt5Q==
Date: Mon, 18 Jul 2016 03:46:33 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.6.6.160626
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.1.202]
Content-Type: multipart/alternative; boundary="_000_D3B19F2517FA5Fncamwingciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: [Anima] Initial review of draft-ietf-anima-bootstrapping-keyinfra-03
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jul 2016 03:46:38 -0000

--_000_D3B19F2517FA5Fncamwingciscocom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

As the Security Advisor for Anima, I have reviewed draft-ietf-anima-bootstr=
apping-keyinfra-03

and have the following comments:


General

=97=97=97=97=97

Device is used inconsistently, but I believe in general device in this draf=
t is the =93target=94 or =93new device=94  that is being bootstrapped, corr=
ect?



Introduction

=97=97=97=97=97


In the paragraph beginning with =93A precise answer to these questions=85.=
=94 (at end of page 3)

I believe =93devices from a variety of vendors=94 includes all network devi=
ces as well as any generic device coming into the network and require boots=
trap, but its not clear?


Not clear what  =93and a network infrastructure (the domain) that is operat=
ed

   by parties that do not have any priviledged relationship with the

   device vendors=94=85..who are the device vendors? I think it is the =93n=
ew device=94 manfufacturer or vendor?


Terminology

=97=97=97=97=97=97

I am presuming domain =3D internet domain?


Typo:  =93Imprint=94 definition =93key material to identity=94 should be =
=93key material to identify=94


Pledge definition: I think all references to =93device=94 is the device nee=
ding to be bootstrapped?


Audit Token: it would be good to describe the =93manufacturer authorized si=
gning authority=94 (e.g. MASA) as I believe the MASA is in general the vend=
or=92s manufacturer but in general, the MASA is some authority that s the o=
ne that can authorize the prospective devices to a particular domain (e.g. =
the domain of interest).  Thus the =93it=94 in the =93=85that it authorizes=
 bootstrap=94 is the MASA where the domain has assigned as the trusted auth=
ority.


Section 1.2

=97=97=97=97=97=97=97

Figure 1: New Entity =3D New Device (these two terms seems to be used inter=
mittently, my nit would be to pick one for consistency)


MASA service: doesn=92t the MASA also holds an authoritative view of what n=
ew devices can join the specific domain?


Ownership Tracker: in the Figure they are shown as part of the =93Vendor Se=
rvice=94 and =93MASA=94, are they abstractly all the same component but can=
 physically be separate entities?  As it is understood there could be devic=
es that come from multiple vendors, there can be many instances of the =93V=
endor Service=94=85.but could also imply that within a =93Vendor Service=94=
 there can be a decoupling of the MASA and Ownership Tracker?


Section 3.1

=97=97=97=97-=97

=93A New Entity MUST NOT automatically initiate bootstrapping=85.=94  how c=
an this be enforced?  There should be some description of implications in t=
he Security Considerations section (e.g. there may be instances in which a =
New Entity may need to go to a =93factory default=94 state and be re-bootst=
rapped?)


Figure 2:  =93Optional=94 can occur in advance=94 =85.not clear what steps =
can be created in advance and how far in advance.  As the New Entity reques=
ts to join, it=92s ID is not known to the Registrar, at least until the TLS=
 connection is established=85.also, the Nonce is listed as optional, but SH=
OULD or MUST be required to map it to provided Join Request (e.g. it should=
 be part of the same sequence).

Clarity somewhere in the document should be provided as to the operionality=
 of which entity does the Authorization for the New Entity to be bootstrapp=
ed (e.g. is it the MASA or the Domain Registrar)=85.at this point it is not=
 clear


Figure 3: Should the box be =93Identify=94 vs =93Identity=94?


Step 2: =93Identify itself=94 : what is meant by =93Although the Registrar =
is also authenticated these

       credentials are only provisionally accepted at this time=94?  I thin=
k the Registrar is provisionally accepting the 802.1AR to protect the TLS c=
hannel, is that the point of this sentence?  But I also believe the New Dev=
ice must provisionally accept the Registrar=92s cert (also indicated in Fig=
ure 2)?


Step 3: =93Request to Join=94 maps to =93Request Audit Token=94 in Figure 2=
?


Step 4:  =93This requires verification of=85=94: the New Entity does the ve=
rification?  How does it do that? There is not enough details in here to de=
scribe how it actually does this. Perhaps these steps should be prefaces as=
 =93Summary=94 or =93Brief/Abbreviated=94 state descriptions=85.


Step 5: this reads a bit awkward=85.I think the point of this step is that =
it now has enough information, for instance, knowing the domain registrar=
=92s certificate to be able to initiate certificate enrollment; and can do =
such enrollment using RFC 7030. Correct?


Step 6: a nit: membership is based on the successful certificate enrollment=
 of the new entity=85correct?  This is correctly shown in Figure 3 :-)


Section 3.1.1

=97=97=97=97=97=97

1st paragraph is awkward, especially the last sentence, what is the point o=
f stating =93Therefore or clarity a Proxy is always assumed=94?  I think th=
e point is that typically, the discovery is typically achieved through a Pr=
oxy but there can be cases in which it =93could=94 go to a Domain Registrar=
, but unlikely, thus a Proxy is needed, right?


Typo in step =93d=94 : there=92s an extra =93k=94 in =93bootstrapks service=
=94


Section 3.1.2

=97=97=97=97=97=97

=93the communication protocol=94 to be more explicit is during the Discover=
y protocol, correct?


What is the =93bootstrapping protocol server=94 , the Domain Registrar?


Section 3.1.3

=97=97=97=97=97=97=97

What is the =93bootstrapping protocol server=94 , the Domain Registrar?  Th=
is text seems to be inconsistent with Figure 2 as that Figure seems to indi=
cate that the Join Request must be responded to before EST can come into pl=
ay?


Section 3.1.4

=97=97=97=97=97=97=97=97

Similarly, I didn=92t think EST was here =93yet=94=85.the Join Response (wh=
ere the Audit Token is received by the New Entity) must be processed.  It i=
s implied here that the Domain Registrar=92s trust anchor is received.  But=
 I think there are more explicit details to the contents of this response a=
nd how the New Device can actually verify (not sure it can validate?) that =
it has the right information to proceed with EST.


Section 3.3

=97=97=97=97=97=97=97

Would be good to have naming consistancy: Domain registrar vs. Registrar vs=
. Bootstrap Server (should be kept to 1 or 2 names to avoid confusion given=
 that there are already several actors in the flow).


1st paragraph: Implies that the bootstrap server is the one that maintains =
the authorization database/state for which entities may be bootstrapped or =
not?


How does the Registrar know which/what MASA to reach to for the entity?  Is=
 there a required trust relationship between the Registrar and the MASA to =
process the Audit request?  I think there is a MUST for this but I don=92t =
see it in this section.


This section speaks to using EST, but I think the Join Request/Response are=
 new messages (operations) which are augmented then to EST??


Section 4

=97=97=97=97=97=97

Is the Domain Operator the MASA?

Figure 5 looks different than Figure 2 and should be consistent or perhaps =
should be converged unless more details are to be provided in this sequence=
?



Security Considerations

=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97

I need to better understand the full flow and roles of the different actors=
 to later be able to more fully comment on what should be in the security c=
onsiderations.


I think given the current state, this section provides a good start but wou=
ld like to see more on the considerations of trust between the different ac=
tors (especially between the registrar and the MASA)

- Nancy

--_000_D3B19F2517FA5Fncamwingciscocom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable









As the S=
ecurity Advisor for Anima, I have reviewed draft-ietf-anima-bootstrapping-k=
eyinfra-03


and have=
 the following comments:








General<=
/p>

=97=97=
=97=97=97


Device i=
s used inconsistently, but I believe in general device in this draft is the=
 =93target=94 or =93new device=94  that is being bootstrapped, correct=
?














Introduc=
tion


=97=97=
=97=97=97








In the p=
aragraph beginning with =93A precise answer to these questions=85.=94 (at e=
nd of page 3)


I believ=
e =93devices from a variety of vendors=94 includes all network devices as w=
ell as any generic device coming into the network and require bootstrap, bu=
t its not clear?








Not clea=
r what  =93and a network infrastructure (the domain) that is operated<=
/p>

 &n=
bsp; by parties that do not have any priviledged relationship with the


 &n=
bsp; device vendors=94=85..who are the device vendors? I think it is the =
=93new device=94 manfufacturer or vendor?








Terminol=
ogy


=97=97=
=97=97=97=97


I am pre=
suming domain =3D internet domain?








Typo:&nb=
sp; =93Imprint=94 definition =93key material to identity=94 should be =93ke=
y material to identify=94








Pledge d=
efinition: I think all references to =93device=94 is the device needing to =
be bootstrapped?








Audit To=
ken: it would be good to describe the =93manufacturer authorized signing au=
thority=94 (e.g. MASA) as I believe the MASA is in general the vendor=92s m=
anufacturer but in general, the MASA is
 some authority that s the one that can authorize the prospective devices t=
o a particular domain (e.g. the domain of interest).  Thus the =93it=
=94 in the =93=85that it authorizes bootstrap=94 is the MASA where the doma=
in has assigned as the trusted authority.








Section =
1.2


=97=97=
=97=97=97=97=97


Figure 1=
: New Entity =3D New Device (these two terms seems to be used intermittentl=
y, my nit would be to pick one for consistency)








MASA ser=
vice: doesn=92t the MASA also holds an authoritative view of what new devic=
es can join the specific domain?








Ownershi=
p Tracker: in the Figure they are shown as part of the =93Vendor Service=94=
 and =93MASA=94, are they abstractly all the same component but can physica=
lly be separate entities?  As it is understood
 there could be devices that come from multiple vendors, there can be many =
instances of the =93Vendor Service=94=85.but could also imply that within a=
 =93Vendor Service=94 there can be a decoupling of the MASA and Ownership T=
racker?








Section =
3.1


=97=97=
=97=97-=97


=93A New=
 Entity MUST NOT automatically initiate bootstrapping=85.=94  how can =
this be enforced?  There should be some description of implications in=
 the Security Considerations section (e.g. there may
 be instances in which a New Entity may need to go to a =93factory default=
=94 state and be re-bootstrapped?)








Figure 2=
:  =93Optional=94 can occur in advance=94 =85.not clear what steps can=
 be created in advance and how far in advance.  As the New Entity requ=
ests to join, it=92s ID is not known to the Registrar,
 at least until the TLS connection is established=85.also, the Nonce is lis=
ted as optional, but SHOULD or MUST be required to map it to provided Join =
Request (e.g. it should be part of the same sequence).  


Clarity =
somewhere in the document should be provided as to the operionality of whic=
h entity does the Authorization for the New Entity to be bootstrapped (e.g.=
 is it the MASA or the Domain Registrar)=85.at
 this point it is not clear








Figure 3=
: Should the box be =93Identify=94 vs =93Identity=94?








Step 2: =
=93Identify itself=94 : what is meant by =93Although the Registrar is also =
authenticated these


 &n=
bsp;     credentials are only provisionally accepted at this time=
=94?  I think the Registrar is provisionally accepting the 802.1AR to =
protect the TLS channel, is that the point of this sentence? 
 But I also believe the New Device must provisionally accept the Registrar=
=92s cert (also indicated in Figure 2)?








Step 3: =
=93Request to Join=94 maps to =93Request Audit Token=94 in Figure 2?  =









Step 4:&=
nbsp; =93This requires verification of=85=94: the New Entity does the verif=
ication?  How does it do that? There is not enough details in here to =
describe how it actually does this. Perhaps these
 steps should be prefaces as =93Summary=94 or =93Brief/Abbreviated=94 state=
 descriptions=85.








Step 5: =
this reads a bit awkward=85.I think the point of this step is that it now h=
as enough information, for instance, knowing the domain registrar=92s certi=
ficate to be able to initiate certificate
 enrollment; and can do such enrollment using RFC 7030. Correct?








Step 6: =
a nit: membership is based on the successful certificate enrollment of the =
new entity=85correct?  This is correctly shown in Figure 3 :-)








Section =
3.1.1


=97=97=
=97=97=97=97


1st para=
graph is awkward, especially the last sentence, what is the point of statin=
g =93Therefore or clarity a Proxy is always assumed=94?  I think the p=
oint is that typically, the discovery is typically
 achieved through a Proxy but there can be cases in which it =93could=94 go=
 to a Domain Registrar, but unlikely, thus a Proxy is needed, right?








Typo in =
step =93d=94 : there=92s an extra =93k=94 in =93bootstrapks service=94








Section =
3.1.2


=97=97=
=97=97=97=97


=93the c=
ommunication protocol=94 to be more explicit is during the Discovery protoc=
ol, correct?








What is =
the =93bootstrapping protocol server=94 , the Domain Registrar?








Section =
3.1.3


=97=97=
=97=97=97=97=97


What is =
the =93bootstrapping protocol server=94 , the Domain Registrar?  This =
text seems to be inconsistent with Figure 2 as that Figure seems to indicat=
e that the Join Request must be responded to
 before EST can come into play?








Section =
3.1.4


=97=97=
=97=97=97=97=97=97


Similarl=
y, I didn=92t think EST was here =93yet=94=85.the Join Response (where the =
Audit Token is received by the New Entity) must be processed.  It is i=
mplied here that the Domain Registrar=92s trust anchor
 is received.  But I think there are more explicit details to the cont=
ents of this response and how the New Device can actually verify (not sure =
it can validate?) that it has the right information to proceed with EST.







Section =
3.3


=97=97=
=97=97=97=97=97


Would be=
 good to have naming consistancy: Domain registrar vs. Registrar vs. Bootst=
rap Server (should be kept to 1 or 2 names to avoid confusion given that th=
ere are already several actors in
 the flow).








1st para=
graph: Implies that the bootstrap server is the one that maintains the auth=
orization database/state for which entities may be bootstrapped or not? &nb=
sp;








How does=
 the Registrar know which/what MASA to reach to for the entity?  Is th=
ere a required trust relationship between the Registrar and the MASA to pro=
cess the Audit request?  I think there
 is a MUST for this but I don=92t see it in this section.








This sec=
tion speaks to using EST, but I think the Join Request/Response are new mes=
sages (operations) which are augmented then to EST??








Section =
4


=97=97=
=97=97=97=97


Is the D=
omain Operator the MASA?  


Figure 5=
 looks different than Figure 2 and should be consistent or perhaps should b=
e converged unless more details are to be provided in this sequence?














Security=
 Considerations


=97=97=
=97=97=97=97=97=97=97=97=97=97=97=97=97


I need t=
o better understand the full flow and roles of the different actors to late=
r be able to more fully comment on what should be in the security considera=
tions.








I think =
given the current state, this section provides a good start but would like =
to see more on the considerations of trust between the different actors (es=
pecially between the registrar and
 the MASA)









- Nancy




--_000_D3B19F2517FA5Fncamwingciscocom_--


From nobody Sun Jul 17 20:47:31 2016
Return-Path: 
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57D2C12D18A; Sun, 17 Jul 2016 20:47:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.807
X-Spam-Level: 
X-Spam-Status: No, score=-15.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 g-DG3mrGN97J; Sun, 17 Jul 2016 20:47:29 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C47712D0FC; Sun, 17 Jul 2016 20:47:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6029; q=dns/txt; s=iport; t=1468813648; x=1470023248; h=from:to:subject:date:message-id:mime-version; bh=4Y9214TdF4JBoHPPpmAnuXgVTsddBK2TNNVmyXms6QE=; b=EHItR+lTDAYvClvCg3b2mfO5CH8WxUKEap/X1GLMgFBis4ers6jG8ytu m5DiKpK7/t0sUNkdm+gkB8BzfYrjPV3HSIRDXGrNkypZ7uD5ZG604nf3q yMyt0YzhIbqSRKYikysoUdx+7w3bStjJ6iOfxI7PRd+uD4lQeI8Q/M5Ul U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CQAgDiUIxX/4cNJK1cgnFOgVizcIUEg?= =?us-ascii?q?XmHQzgUAQEBAQEBAWUnhGMnZAGBACcEAYhCvxMBAQEBBgEBAQEBIpUSBY5EimA?= =?us-ascii?q?BgTSNKo83kB0BHjaDc4cpfwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.28,382,1464652800";  d="scan'208,217";a="125154613"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Jul 2016 03:47:12 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u6I3lCKu027181 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 18 Jul 2016 03:47:12 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 17 Jul 2016 23:47:11 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Sun, 17 Jul 2016 23:47:11 -0400
From: "Nancy Cam-Winget (ncamwing)" 
To: "anima@ietf.org" , "secdir@ietf.org" 
Thread-Topic: Initial review of  draft-ietf-anima-reference-model-01
Thread-Index: AQHR4KcQhmP1KNYyx0WDpAcA6/CBjw==
Date: Mon, 18 Jul 2016 03:47:11 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.6.6.160626
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.1.202]
Content-Type: multipart/alternative; boundary="_000_D3B19F4917FA63ncamwingciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: [Anima] Initial review of  draft-ietf-anima-reference-model-01
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jul 2016 03:47:30 -0000

--_000_D3B19F4917FA63ncamwingciscocom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

As the Security Advisor for Anima, I have reviewed draft-ietf-anima-referen=
ce-model-01

and have the following comments:


Editorial nits:

Section 4.6 : ACP's full description should be called out as its the first =
instance of its use in this draft.


Section 7.1: "general concepts, such as sitting on top of the ANI, etc." se=
ems to be a dangling sentence (at least ill formed).


Section 7.2 typo in several references: "Enrolment" -> Enrollment



Comments:

Section 6:

  - Self-protecting against what attacks?  All possible attacks (hard to pr=
edict)  or is it "known" attacks as described where?

  - All protocols are secure by default implies that all protocols a config=
ured by default to be encrypted to provide both confidentiality and integri=
ty?


Section 6.2:  is a device =3D autonomic node?


Section 6.3: the MASA is the implied CA as well?


Section 7.2 (as a whole): seems to be incomplete....are constrained vs. unc=
onstrained nodes explained elsewhere?  This description seems to imply its =
definition being in this section, but perhaps more text is missing?


Section 10:

 - The security considerations should discuss the potential for malware, e.=
g. a node that has either been misconfigured or infected.

 - Should there be privacy considerations as potential topology and identit=
ies be disclosed especially during discovery and bootstrap?



   Nancy

--_000_D3B19F4917FA63ncamwingciscocom_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







As the S=
ecurity Advisor for Anima, I have reviewed draft-ietf-anima-reference-model=
-01


and have=
 the following comments:








Editoria=
l nits:


Section =
4.6 : ACP’s full description should be called out as its the first in=
stance of its use in this draft.








Section 7.1: “g=
eneral concepts, such as sitting on top of the ANI, etc.” seems to be=
 a dangling sentence (at least ill formed).








Section 7.=
2 typo in several references: “Enrolment” -> Enrollment














Comments=
:


Section =
6:  


  -=
 Self-protecting against what attacks?  All possible attacks (hard to =
predict)  or is it “known” attacks as described where?


  -=
 All protocols are secure by default implies that all protocols a configure=
d by default to be encrypted to provide both confidentiality and integrity?=









Section =
6.2:  is a device =3D autonomic node?








Section =
6.3: the MASA is the implied CA as well?








Section =
7.2 (as a whole): seems to be incomplete….are constrained vs. unconst=
rained nodes explained elsewhere?  This description seems to imply its=
 definition being in this section, but perhaps
 more text is missing?








Section =
10:


 - =
The security considerations should discuss the potential for malware, e.g. =
a node that has either been misconfigured or infected.


 - =
Should there be privacy considerations as potential topology and identities=
 be disclosed especially during discovery and bootstrap?












  &=
nbsp;Nancy




--_000_D3B19F4917FA63ncamwingciscocom_--


From nobody Mon Jul 18 02:44:14 2016
Return-Path: 
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9107A12D672 for ; Mon, 18 Jul 2016 02:44:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 LxVutfcvkDta for ; Mon, 18 Jul 2016 02:44:11 -0700 (PDT)
Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 D139612D6B2 for ; Mon, 18 Jul 2016 02:39:48 -0700 (PDT)
Received: by mail-qt0-x236.google.com with SMTP id 52so88789534qtq.3 for ; Mon, 18 Jul 2016 02:39:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=mnx/bdxn29E5zZm9TitsFwg9cB2xgZe+/S7zgHODIJs=; b=g71wk4eDqIlCjSl23FzfZbakTaCTpiw4dAY2Wyb/Mcc8emqw0bWli9VoJHqCblhJsf 5fhIFWErgEShTtJDkCKjGh/zAi29Bf8etIBnBRwe7acSFjt7VyjmQ5LWJM8JZ2z6xqsc u1Sq1HVSLPJSiVFI7xm2DYPxnNQr6ljkMex/oLf2534tLgj9GohMiyF+o1HdDm5j18+X x8KjVJWYJ1+78U4Tosh/ip/YzBOhJxd7qtSmR9NBpXv6Gn23dtWcL6X4fAVWsUMq/BCA N6uxVRhcAiJJKjLgzOYWGtrMyn+oTm2c/Rr/TpVUxsR+qYiWseOT3TWhok9NfT5/dsgp dvpA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=mnx/bdxn29E5zZm9TitsFwg9cB2xgZe+/S7zgHODIJs=; b=YxV8zBbEUQRjr6M1k8qjugvHVvc+pbad3QqIOZY4Zbs6G/KAfjOR/v3hkocqZakKrj x1IMSZHaq7FlkVbUPHdx6xvvDW6U3qL/iG38HqX/GPOlqaQsAwUiyZQ5dJN6mkV1bcdd cnLDTUsemkdshLUgjJy2YqYbZ8+HeZS87WDUvsb8da0roLVeR/sQDjJzM7Xs7t2/LKya 3Qx+3+6qiosgVFiZnyOaw6Lw3MciNcuizykUpi7DmK0wY7991pn/00c66/Vhje93j8q6 sb2EVYznKM1mIXMYA2uR+jjrPFij45olOVcJe56fFaat6SYBYIWrexnefoOG6bbC40vq x3BA==
X-Gm-Message-State: ALyK8tLRoOyb4ig+v0uqm96LXwwwJegu3YJjxqXyWiM3evt8e2tUpr6xkE4YX5HK3ySuiA==
X-Received: by 10.200.55.137 with SMTP id d9mr49988582qtc.46.1468834787928; Mon, 18 Jul 2016 02:39:47 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:176:28cc:dc4c:9703:6781? ([2001:67c:370:176:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 55sm2335607qtm.36.2016.07.18.02.39.46 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Jul 2016 02:39:47 -0700 (PDT)
From: Brian E Carpenter 
To: Anima WG 
References: <20160630230229.29590.10045.idtracker@ietfa.amsl.com> <0e01ea99-800f-7fcf-a3bb-ee8c08d8f550@gmail.com>
Organization: University of Auckland
Message-ID: <29519a5a-e380-b103-2846-e8e8a68cb691@gmail.com>
Date: Mon, 18 Jul 2016 21:39:44 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <0e01ea99-800f-7fcf-a3bb-ee8c08d8f550@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-03.txt
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jul 2016 09:44:12 -0000

On 01/07/2016 18:43, Brian E Carpenter wrote:
> Hi,
> 
>>    b.  MUST: Performs DNS-based Service Discovery [RFC6763] over
>>        Multicast DNS [RFC6762] searching for the service
>>        "_bootstrapks._tcp.local.".
> 
> I missed the bit where we got consensus to only specify DNSSD for
> discovery. My understanding was that since all ANs will contain
> the ANI components, GRASP discovery was an equally valid option.
> 
> DNSSD is a fine option for non-ANs that don't contain the ANI
> components.

So after some thought, I believe that we have to change this to better
fit the ANI as a whole by changing it to something like this:

    b1. MUST: Performs DNS-based Service Discovery [RFC6763] over
        Multicast DNS [RFC6762] searching for the service
        "_bootstrapks._tcp.local.".

    b2. MUST: If the node in question supports GRASP signaling
        [I-D.ietf-anima-grasp], also perform GRASP Discovery searching
        for the Objective "_bootstrapks._tcp.local." using a loop
        count of 1 to ensure link-local scope.

That allows non-Anima devices to use DNSSD if that's their bag,
and allows Anima deployments to omit DNSSD support if they want.
The device will use the result of whichever discovery replies first.
We can use the same name with no problem.

I would argue that since all ACP nodes will support GRASP anyway,
ACP-creation should use GRASP discovery, so that DNSSD support doesn't
become mandatory in the ANI. I don't really see what we win by
inserting DNSSD unnecessarily. If it's needed for non-ANI reasons,
that's fine of course, but the ACP doesn't need it.

Regards,

   Brian


From nobody Mon Jul 18 23:15:55 2016
Return-Path: 
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF23C12D08F for ; Mon, 18 Jul 2016 23:15:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.808
X-Spam-Level: 
X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 OmC1N-wxe5Zr for ; Mon, 18 Jul 2016 23:15:51 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E6FF12B02A for ; Mon, 18 Jul 2016 23:15:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2104; q=dns/txt; s=iport; t=1468908951; x=1470118551; h=date:from:to:subject:message-id:mime-version; bh=/5kYc891jNuNpEcOT2qFDwzHtTBlkMi18vXwMW4r/Ns=; b=WfEvvkuBhmx+E30K5ujFu5TojB6e3euHfvUHNrO2QTtOx+S5xc3H/+VF P71Y6ueWtPwKJcJjlU7+os2fDWZqBK3PHk3M/MmwhflTJFo79oWIxVvaF dekQeMybxRsfmU3m3YuU8JkToujk0XDGR1Nf5ano35/pbeqSZYQ0Jti6H U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BmAgBRxI1X/5JdJa1bgz+6OYF6h1c4F?= =?us-ascii?q?AEBAQEBAQFlJ4UKE3s0BYkMn3GddQEBCAEBAQEBIpADgmCCLwWPAIokjlUKjze?= =?us-ascii?q?QHh42hBMciEIBAQE?=
X-IronPort-AV: E=Sophos;i="5.28,388,1464652800"; d="scan'208";a="297946081"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jul 2016 06:15:50 +0000
Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u6J6FnHu021216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 19 Jul 2016 06:15:50 GMT
Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id u6J6Fnx1025567 for ; Mon, 18 Jul 2016 23:15:49 -0700
Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u6J6FnRe025566 for anima@ietf.org; Mon, 18 Jul 2016 23:15:49 -0700
Date: Mon, 18 Jul 2016 23:15:49 -0700
From: Toerless Eckert 
To: anima@ietf.org
Message-ID: <20160719061549.GA24601@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.2i
Archived-At: 
Subject: [Anima] draft-ietf-anima-bootstrapping-keyinfra-03: Concern - MTI
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jul 2016 06:15:53 -0000

Would like the list to express opinions about one (IMHO core) issue
brought up yesterday during the WG meeting:

What is the MTI (Mandatory To Implement) (aka: "MUST") set of protocols
in support of ANIMA bootstrap:

- Right now the draft suggest "MUST" for CoAP and SHOULD for TLS if i am not mistaken.

- Fair warning: As a contributor i am biased towards TLS because i know this 
  is sufficient for all the enterprise/SP ("well managed networks" as we say in our charter)
  use cases. I hope this still allows me to be objective enough to help drive this
  question to a conclusion as a WG-chair ;-):

- For progress -> IESG of bootstrap as a WG charter item, i am somewhat concerned
  about MUST against CoAP because it seems to create a good amount of more
  work for use to get a first round of bootstrap "out the door" (RFC):

  - We would need to make the work of draft-pritikin-coap-bootstrap-00
    part of the mandatory first charter round deliverable (whether through
    folding the text back into the bootstrap draft or separately).

  - We would need to wait for I-D.ietf-core-block to become RFC

  - We would need to resolve the open issues around operations of the proxy
    for CoAP (will describe in separate thread).

To give a more conservative option:
 - Move all CoAP text from bootstrap draft into CoAP draft.
 - Make CoAP draft WG item for bootstrap charter item.
 - Bootstrap mandates (MUST) TLS.
 - CoAP draft describes derived (CoAP) version of bootstrap:
   - CoAP is MUST , requirement to do TLS is reduced to MAY

So i hope this would allow us to pace the work on CoAP based on resolving
the items listed above, and give the industry the option later on to implement
against what they need in their use-case:
  - Product that only is interested in TLS just claims support for bootstrap RFC
  - Product intereested in only CoAP claims support for just coap RFC
  - Product supporting both TLS and CoAP claims support for both.

Thought / opinions / suggestions ? If not yet, pls. have them on thursday ;-)

Thanks!
    Toerless


From nobody Tue Jul 19 00:30:54 2016
Return-Path: 
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF9212D0CB for ; Tue, 19 Jul 2016 00:30:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.808
X-Spam-Level: 
X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 3jA3LnG6qHh9 for ; Tue, 19 Jul 2016 00:30:50 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A45C312B04F for ; Tue, 19 Jul 2016 00:30:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4634; q=dns/txt; s=iport; t=1468913450; x=1470123050; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=6ooVNIs3bdl8RtIHs9Hjdoud5jh9/+qqyEJWaos13nc=; b=HfEI/eFoouBlUD6BNcCbBFf6jZWGbg7itjiQi6NmfXFPeKn/tQHEuWjj LBeOPQfZszfbqhyI9QZfwzKmEs5d43k47vi8hZcCKRLhB+OqQRDwRTbDm weQdJEYOhWttSshq8R4FZf/o7Wxcqwzh7DoFt3KJ7Ng7649XSqkmV/GZ1 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A6BwCu1o1X/5xdJa1bgz9WLU+4ZoF6I?= =?us-ascii?q?oV4AoEwOBQBAQEBAQEBZSeEXQEFAQElEzQLEAsYCSUPBRM2ExsDiBIOvVEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEXBYl0gQOHbIIvBY4LdYRjhUGOVQqPN5AeHjaEE?= =?us-ascii?q?xwyiBABAQE?=
X-IronPort-AV: E=Sophos;i="5.28,388,1464652800"; d="scan'208";a="125604777"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jul 2016 07:30:49 +0000
Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u6J7UnWm005505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jul 2016 07:30:49 GMT
Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id u6J7Um73028287; Tue, 19 Jul 2016 00:30:48 -0700
Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u6J7UmD4028285; Tue, 19 Jul 2016 00:30:48 -0700
Date: Tue, 19 Jul 2016 00:30:48 -0700
From: Toerless Eckert 
To: Brian E Carpenter 
Message-ID: <20160719073048.GB24601@cisco.com>
References: <20160630230229.29590.10045.idtracker@ietfa.amsl.com> <0e01ea99-800f-7fcf-a3bb-ee8c08d8f550@gmail.com> <29519a5a-e380-b103-2846-e8e8a68cb691@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <29519a5a-e380-b103-2846-e8e8a68cb691@gmail.com>
User-Agent: Mutt/1.4.2.2i
Archived-At: 
Cc: Anima WG 
Subject: Re: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-03.txt
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jul 2016 07:30:52 -0000

Brian:

It sounds from your latter text as if you really wouldn't like to see b1. ;-)

Just to refine my position as contributor:

AFAIK, The MUST for mDNS was IMHO from the authors from the following
assumptions:

  1. Devices already will do mDNS
  2. There is nothing wrong with mDNS, anima principle, reuse existing
     protocols unless proven otherwise
  3. Separate code basis from GRASP used securely == highest separation of
     signaling between secure / insecure.

IMHO:

  1. Most network devices i deal with do not do mDNS.
     i do not know enough IoT devices to have opinions about those, but
     i wonder how important those are re. existing anima charter.

  2. a) My main fear remains undesired proxying of mDNS messages by
     some equipment, thereby creating undesired ACP connections. mDNS
     proxying has become quite popular.

     b) IMHO mDNS has a lot of baggage because it's built on a 25 year
     old DNS arch amended with a Service Discovery extension. So
     it's really a lot of complexity under the hood. Unless a solution
     needs to use the DNS namespace i am not sure why it would be
     a preference.

     c) I can't imagine that all the IoT spaces will convege on just
     one discovery protocol as heir preference, so i think it's an
     illusion to think we can hit "one preferred" by all model.
     Eg: DPWS (derived from WS-Discovery) is also used/preferred
     in certain IoT spaces AFAIk.

  3. I have never seen point 3. as a system design principle. My background
     is in routing, and BGP and IGPs for examples are used extensively
     in the same devices running in different instances for different
     isolated domains (eg: l3vpn). Reuse of the same protocols as
     much as possible, because their security properties are understood
     and isolation between different instances is an accepted model of
     reuse and mutual isolation (shared code, no shared data).

So, to me the best principles to adopt in bootstrap are:

  -> Bootstrap Proxies should support all the discovery protocols that
     their clients desire.
  -> Clients that are ANIMA devices themselves have GRASP, thats
     sufficient, and its a protocol we can fully control. If we discover
     problems we can easier fix them as problems with a protocol that
     has a lot of other pre-existing uses and our requirements could
     conflict with those.
  -> If any set of non-ANIMA client devices desiring bootstrap prefer
     mDNS, the proxy of course should also support mDNS.

Comments welcome.

Cheers
   Toerless

On Mon, Jul 18, 2016 at 09:39:44PM +1200, Brian E Carpenter wrote:
> On 01/07/2016 18:43, Brian E Carpenter wrote:
> > Hi,
> > 
> >>    b.  MUST: Performs DNS-based Service Discovery [RFC6763] over
> >>        Multicast DNS [RFC6762] searching for the service
> >>        "_bootstrapks._tcp.local.".
> > 
> > I missed the bit where we got consensus to only specify DNSSD for
> > discovery. My understanding was that since all ANs will contain
> > the ANI components, GRASP discovery was an equally valid option.
> > 
> > DNSSD is a fine option for non-ANs that don't contain the ANI
> > components.
> 
> So after some thought, I believe that we have to change this to better
> fit the ANI as a whole by changing it to something like this:
> 
>     b1. MUST: Performs DNS-based Service Discovery [RFC6763] over
>         Multicast DNS [RFC6762] searching for the service
>         "_bootstrapks._tcp.local.".
> 
>     b2. MUST: If the node in question supports GRASP signaling
>         [I-D.ietf-anima-grasp], also perform GRASP Discovery searching
>         for the Objective "_bootstrapks._tcp.local." using a loop
>         count of 1 to ensure link-local scope.
> 
> That allows non-Anima devices to use DNSSD if that's their bag,
> and allows Anima deployments to omit DNSSD support if they want.
> The device will use the result of whichever discovery replies first.
> We can use the same name with no problem.
> 
> I would argue that since all ACP nodes will support GRASP anyway,
> ACP-creation should use GRASP discovery, so that DNSSD support doesn't
> become mandatory in the ANI. I don't really see what we win by
> inserting DNSSD unnecessarily. If it's needed for non-ANI reasons,
> that's fine of course, but the ACP doesn't need it.
> 
> Regards,
> 
>    Brian
> 
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
Toerless Eckert, eckert@cisco.com


From nobody Tue Jul 19 03:01:58 2016
Return-Path: 
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D71012D529 for ; Tue, 19 Jul 2016 03:01:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.188
X-Spam-Level: 
X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 nAS30PQbiWGn for ; Tue, 19 Jul 2016 03:01:52 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A322712D53A for ; Tue, 19 Jul 2016 02:56:56 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 2BF0120183; Tue, 19 Jul 2016 06:06:23 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C7A08638D1; Tue, 19 Jul 2016 05:56:55 -0400 (EDT)
From: Michael Richardson 
To: Toerless Eckert 
In-Reply-To: <20160719073048.GB24601@cisco.com>
References: <20160630230229.29590.10045.idtracker@ietfa.amsl.com> <0e01ea99-800f-7fcf-a3bb-ee8c08d8f550@gmail.com> <29519a5a-e380-b103-2846-e8e8a68cb691@gmail.com> <20160719073048.GB24601@cisco.com>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Archived-At: 
Cc: Anima WG 
Subject: Re: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-03.txt
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jul 2016 10:01:54 -0000

--=-=-=
Content-Type: text/plain


Toerless Eckert  wrote:
    > 1. Most network devices i deal with do not do mDNS.
    > i do not know enough IoT devices to have opinions about those, but
    > i wonder how important those are re. existing anima charter.

I am not mostly *not* thinking about tiny constrained motes here.

I'm thinking about various appliance-like things: the home NAS, the iDRAC/ILO
service processor, etc.

*THESE* devices might not run GRASP.
They *might* want to join the ACP.
They *do* want to do secure bootstrap.
They already have mDNS.

Or to put it another way: I'm thinking about the light controller, not the
lightblubs.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-




--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEVAwUBV435ZICLcPvd0N1lAQLUqgf9GzI/JrTzvqFX57Yf5sfFR+ngRJCKNii0
kXSZQiF8Fl+5yQ4E5WNKV3yD8o1QQnN7BFXOs+ZGxUnjtjb3HpCmLZZRjOgV9El6
HaAngdzX5/U4u74xa3JLXDL/DnfgqmhjGo+zs7HIQ40gXU9VoXsRLVUiNe3KflZA
9MiVDb8gKTfxniiImki5weGVbBMPfAgiGFUex1xLshleN/3JiOwGV1O+v6LANmhh
ndFeYEbGKxWTJkVC/ZxSqx2cHg6A4gLw+B0IHIQeHhklE1rZQpqLZdmBjfpgeKwY
AYrH8Zw4dOaq9EjrOhEJWZf5ctFBmPntowpnI4SaTqE3Sy/j7vDYRw==
=Ifr5
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Tue Jul 19 03:10:36 2016
Return-Path: 
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F1912D09F for ; Tue, 19 Jul 2016 03:10:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 MPYSy4NFJIvo for ; Tue, 19 Jul 2016 03:10:32 -0700 (PDT)
Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 408B812B006 for ; Tue, 19 Jul 2016 03:10:32 -0700 (PDT)
Received: by mail-lf0-x236.google.com with SMTP id l69so9584706lfg.1 for ; Tue, 19 Jul 2016 03:10:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=oQeErvZPewByOb6gHwMfDc7BrnNhEy9X4pCPtiBDvjs=; b=uPV/MKbuPphohj5lbdjNOH3pDWHyqgdpDpPyV6O0O1ASIFlK+rwsV41l7MGFCU6hR0 hYQssGXsL2Ut/8uiZaGWmoDV8GNexqyVs6gosS0/O+0C/ieYf5GWl6JaQcWo0mfqE3Lz se1r+i7JyULZAcrfuxHHmzo8A2vT64KFterRvVq+phxW5IddoNgju45MhyZAUt0iUrUH TlIPkpCptA7BHmZePwHpZboJ1AkSQlQtfNNDHyaxvQw8e16E1re/u30Q56EcbYAJwOaK PvSzf7FatBbmIe8paYODj+aH3SKzKI3KgIO+YuHLoNu845aJ4KSrjd4n+YmFP+6lPd2s 887Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=oQeErvZPewByOb6gHwMfDc7BrnNhEy9X4pCPtiBDvjs=; b=O4l2cyWrqkmsEoi5kHi+btNHjUNkF+tyooiufIbOmXf28uWosDAPMTBf9OPGfboQRM Q/2seYEQxiyk0prgpm2rjSMbBF2y0J0FdppYIhbs1uhvQ+plI5jKJnD2uNDAB3r4AvMC XmoucMFk9yzscgZaEwZJjggE4FMP7NB2rBhH1YbBezt/JEmQtTtqIlkDhGC/zsqLRs1L 8ilTvJrmlE9dUniJ0z3R+77rkLVTPgJrkFM8lPHzUAMqhObv7Gm4WPtfhcGclGVrnicg 8WkECWKtX/d39CM90RU/t1DzetVTOLanY0e98ovti4WzmCt4ovBk7YsCZnyAFF4NLJin 0qVw==
X-Gm-Message-State: ALyK8tLQqLQBgSZGRGCgfJKnmy2u1vRdpJy5l6LvrvhtU7g7KpHU+fNoljzXjb8R4EN69w==
X-Received: by 10.46.9.144 with SMTP id 138mr16720537ljj.6.1468923030436; Tue, 19 Jul 2016 03:10:30 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:176:28cc:dc4c:9703:6781? ([2001:67c:370:176:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id g88sm3466393ljg.26.2016.07.19.03.10.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jul 2016 03:10:29 -0700 (PDT)
To: Michael Richardson , Toerless Eckert 
References: <20160630230229.29590.10045.idtracker@ietfa.amsl.com> <0e01ea99-800f-7fcf-a3bb-ee8c08d8f550@gmail.com> <29519a5a-e380-b103-2846-e8e8a68cb691@gmail.com> <20160719073048.GB24601@cisco.com> <23103.1468922215@obiwan.sandelman.ca>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <44037e14-ebab-f6ff-9828-bb293b8b4f3b@gmail.com>
Date: Tue, 19 Jul 2016 22:10:29 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <23103.1468922215@obiwan.sandelman.ca>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: Anima WG 
Subject: Re: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-03.txt
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jul 2016 10:10:34 -0000

On 19/07/2016 21:56, Michael Richardson wrote:
> 
> Toerless Eckert  wrote:
>     > 1. Most network devices i deal with do not do mDNS.
>     > i do not know enough IoT devices to have opinions about those, but
>     > i wonder how important those are re. existing anima charter.
> 
> I am not mostly *not* thinking about tiny constrained motes here.
> 
> I'm thinking about various appliance-like things: the home NAS, the iDRAC/ILO
> service processor, etc.
> 
> *THESE* devices might not run GRASP.
> They *might* want to join the ACP.
> They *do* want to do secure bootstrap.
> They already have mDNS.
> 
> Or to put it another way: I'm thinking about the light controller, not the
> lightblubs.

1) the concept of a 'lightblub' is very appealing.

2) on balance, I think I agree with Michael slightly more than
with Toerless. Even though this use case is strictly outside the
Anima charter, I think we'd look very silly if the autonomic security
bootstrap could cope with routers and application devices such as
autonomic energy management boxes, but not with lighting controllers.

   Brian


From nobody Tue Jul 19 03:18:32 2016
Return-Path: 
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB5E12D5A1 for ; Tue, 19 Jul 2016 03:18:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level: 
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 wkQRVCtepGCh for ; Tue, 19 Jul 2016 03:18:29 -0700 (PDT)
Received: from lb1-smtp-cloud3.xs4all.net (lb1-smtp-cloud3.xs4all.net [194.109.24.22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFC1812D5A5 for ; Tue, 19 Jul 2016 03:18:28 -0700 (PDT)
Received: from webmail.xs4all.nl ([194.109.20.214]) by smtp-cloud3.xs4all.net with ESMTP id LaJS1t00Z4d84Ai01aJSGD; Tue, 19 Jul 2016 12:18:27 +0200
Received: from 2001:67c:370:160:35cd:ebda:55b0:e98f by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 19 Jul 2016 12:18:26 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Date: Tue, 19 Jul 2016 12:18:26 +0200
From: peter van der Stok 
To: Brian E Carpenter 
Organization: vanderstok consultancy
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <44037e14-ebab-f6ff-9828-bb293b8b4f3b@gmail.com>
References: <20160630230229.29590.10045.idtracker@ietfa.amsl.com> <0e01ea99-800f-7fcf-a3bb-ee8c08d8f550@gmail.com> <29519a5a-e380-b103-2846-e8e8a68cb691@gmail.com> <20160719073048.GB24601@cisco.com> <23103.1468922215@obiwan.sandelman.ca> <44037e14-ebab-f6ff-9828-bb293b8b4f3b@gmail.com>
Message-ID: <4c3c76bf4ed8f6a580435e5f231b6e9a@xs4all.nl>
X-Sender: stokcons@xs4all.nl (KOe2ABqCFASbeu8PYZN6tiRsU93c79RZ)
User-Agent: XS4ALL Webmail
Archived-At: 
Cc: Michael Richardson , Toerless Eckert , Anima WG 
Subject: Re: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-03.txt
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: consultancy@vanderstok.org
List-Id: Autonomic Networking Integrated Model and Approach 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jul 2016 10:18:31 -0000

>> Or to put it another way: I'm thinking about the light controller, not 
>> the
>> lightblubs.
> 
> 1) the concept of a 'lightblub' is very appealing.
> 
> 2) on balance, I think I agree with Michael slightly more than
> with Toerless. Even though this use case is strictly outside the
> Anima charter, I think we'd look very silly if the autonomic security
> bootstrap could cope with routers and application devices such as
> autonomic energy management boxes, but not with lighting controllers.

Abstracting from the device naming, I agree with Brian and Michael.
There is no guarantee though how blubs can evolve in the future.

Peter


From nobody Tue Jul 19 03:19:19 2016
Return-Path: 
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 863D712D1D7 for ; Tue, 19 Jul 2016 03:19:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.188
X-Spam-Level: 
X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 IQFMsdb9Zzs9 for ; Tue, 19 Jul 2016 03:19:16 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECDE812D1D1 for ; Tue, 19 Jul 2016 03:19:15 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8C77B20183 for ; Tue, 19 Jul 2016 06:28:42 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3C87E638D1 for ; Tue, 19 Jul 2016 06:19:15 -0400 (EDT)
From: Michael Richardson 
To: Anima WG 
In-Reply-To: <20160719073048.GB24601@cisco.com>
References: <20160630230229.29590.10045.idtracker@ietfa.amsl.com> <0e01ea99-800f-7fcf-a3bb-ee8c08d8f550@gmail.com> <29519a5a-e380-b103-2846-e8e8a68cb691@gmail.com> <20160719073048.GB24601@cisco.com>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Archived-At: 
Subject: Re: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-03.txt
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jul 2016 10:19:18 -0000

--=-=-=
Content-Type: text/plain


Toerless Eckert  wrote:
    > 2. a) My main fear remains undesired proxying of mDNS messages by
    > some equipment, thereby creating undesired ACP connections. mDNS
    > proxying has become quite popular.

I don't see the problem.
a) proxy mDNS all you like, the proxy reply is supposed to be a
   link-local address, and if the mDNS was proxied, then the connection
   failed.

b) assuming that a non-link-local address was returned, and the
   implementation was given a routable source address, (very possible
   on an active LAN with DHCP/SLAAC available), and it connects to
   the proxy.  There is then an enrollment. Or there isn't.

b) assuming that the enrollment worked, then whatever the ACP
   discovery mechanism is (is it GRASP? I don't know) would run
   on the link if the new system wanted to join the ACP.

   We never suggested that this discovery would be mDNS.

    > c) I can't imagine that all the IoT spaces will convege on just
    > one discovery protocol as heir preference, so i think it's an
    > illusion to think we can hit "one preferred" by all model.

Multiple vendors are doing this.
We made multicast work in great part so that mDNS would work.

    > 3. I have never seen point 3. as a system design principle. My background
    > is in routing, and BGP and IGPs for examples are used extensively
    > in the same devices running in different instances for different
    > isolated domains (eg: l3vpn). Reuse of the same protocols as
    > much as possible, because their security properties are understood
    > and isolation between different instances is an accepted model of
    > reuse and mutual isolation (shared code, no shared data).

Most priviledge elevation exploits for Windows and Linux leverage that a
feature was added to the code base to support function X, which, when
combined with operation Y, does something unintended.

For an example from the routing space, I point to why we can't use source
routing in most places.  It has no security risks at all until you start
assuming that things behind a firewall are trusted and things outside are
not.

This is the kind of thing that we are thinking about.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-




--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEVAwUBV43+noCLcPvd0N1lAQKMNggAlnftAT+WvUwnkysILc5o6N3uoEWHLIiA
dA3/LZwMTy+C8IDqB2hQzsZKU+UUwhHNvf9P8bLxPatlMNxDMCf9c36p9jtgUBXt
+J9lrG4d5/fSNJ8piSt4A0tHlF7z+guDzOfT6cqNe8PuJp7uKM0gv5PoABTX2Ruq
lIpC5Zqj4hZSHPXefd4aqTbwuiSE9GUd86T2y59n0va/N4kxHS4tQVGBg04Bbh9+
rP8O2TKwJvhqj/HMefUJXdM3G5xA/cDbXW60aLdk5Tgv0L8P6zk3QoucOTh045Kp
pAcQlEtatgRdmSYfSvxvmGO0QzX4+6X7c1jLkK9Rg0oQVzB/T2bNnw==
=P1Wm
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Wed Jul 20 12:27:48 2016
Return-Path: 
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E1912D629 for ; Wed, 20 Jul 2016 12:27:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.808
X-Spam-Level: 
X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 QeLb9oACLRN3 for ; Wed, 20 Jul 2016 12:27:45 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC51812B00A for ; Wed, 20 Jul 2016 12:22:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=374; q=dns/txt; s=iport; t=1469042543; x=1470252143; h=date:from:to:subject:message-id:mime-version; bh=HZacT8WZl9BCz85Wq0PFMQidc/EAHueO7vSQELTia1I=; b=W/3K4Lv9d3TjDOW3tUHMKx5ii75CX0sv1OIfQs4brjBlvloYbDXb+HtJ 05RBosnq06jou4w5MKDP16Vw4zecJNOzTOG4rYyoR+mQ1hrdpwzmY9ONL zzzf+4IqnisuZVl2bNInEGz1pOTHPWEf3tBXFD2yBxezAXDANQwcD+m7c A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CvAwB9zo9X/51dJa1dgz9WfbhegXsmg?= =?us-ascii?q?j2EbjgUAQEBAQEBAWUnQRABhEt7NAWJDA6fb51IDAEkkAOFDwWPAIomhhOIRQq?= =?us-ascii?q?BVgFjjH+QIB42ggscgWwcgXWFZAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.28,395,1464652800"; d="scan'208";a="299584967"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jul 2016 19:22:23 +0000
Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u6KJMMsH018452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 Jul 2016 19:22:22 GMT
Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id u6KJMMjT006997 for ; Wed, 20 Jul 2016 12:22:22 -0700
Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u6KJMM5x006996 for anima@ietf.org; Wed, 20 Jul 2016 12:22:22 -0700
Date: Wed, 20 Jul 2016 12:22:22 -0700
From: Toerless Eckert 
To: anima@ietf.org
Message-ID: <20160720192222.GL7377@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.2i
Archived-At: 
Subject: [Anima] ASN.1 vulnerability
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jul 2016 19:27:46 -0000

Funny... just weeks ago we did discuss in the bootstrap team how to
encode our ANIMA attributes into certs and i think MichaelR threw in to
be very careful and don't step of the well treaded path (known attributes
etc...) in fear of bad ASN.1 parser.

http://arstechnica.com/security/2016/07/software-flaw-puts-mobile-phones-and-networks-at-risk-of-complete-takeover/


From nobody Thu Jul 21 00:21:24 2016
Return-Path: 
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 673AB12DA8A for ; Thu, 21 Jul 2016 00:21:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.808
X-Spam-Level: 
X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 zMaQMBiu2GjH for ; Thu, 21 Jul 2016 00:21:21 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B915412DA89 for ; Thu, 21 Jul 2016 00:21:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2547; q=dns/txt; s=iport; t=1469085681; x=1470295281; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=iaCMAcQPneecEtHdTZ/0/q2swbdjRwVV7dPWnCUc8yE=; b=jOR4Q+sBhQXjAtMLsXh1UB634pESIKzNFKqhC1MFxLGjXaenKRbj4hr8 y36ZzxdSAWeQpwF+aRjIiKqMadbpzqBOFHXxn454RhUf6m/DFH0c8Daxt kw/wPpAZQ1QYjAdYexwKfBu9YSCvghhfDNOxCoVMwAzHtewFBE0QoNUdG w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AfCAD+dpBX/4cNJK1dgz+BUrhigXuGG?= =?us-ascii?q?gKBLDoSAQEBAQEBAWUnQQ4BhAwBAQQBDiwrFAULCxgJJQ8FSRMeiAoIvTIBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEcineHbIIvBY4MdYoljmEKjzqQISQBL4QTHDKEW?= =?us-ascii?q?oJ+AQEB?=
X-IronPort-AV: E=Sophos;i="5.28,398,1464652800"; d="scan'208";a="300532957"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Jul 2016 07:21:21 +0000
Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u6L7LKGe016201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jul 2016 07:21:20 GMT
Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id u6L7LKuS017018; Thu, 21 Jul 2016 00:21:20 -0700
Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u6L7LKYr017017; Thu, 21 Jul 2016 00:21:20 -0700
Date: Thu, 21 Jul 2016 00:21:20 -0700
From: Toerless Eckert 
To: Brian E Carpenter 
Message-ID: <20160721072119.GA16062@cisco.com>
References: <20160630230229.29590.10045.idtracker@ietfa.amsl.com> <0e01ea99-800f-7fcf-a3bb-ee8c08d8f550@gmail.com> <29519a5a-e380-b103-2846-e8e8a68cb691@gmail.com> <20160719073048.GB24601@cisco.com> <23103.1468922215@obiwan.sandelman.ca> <44037e14-ebab-f6ff-9828-bb293b8b4f3b@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <44037e14-ebab-f6ff-9828-bb293b8b4f3b@gmail.com>
User-Agent: Mutt/1.4.2.2i
Archived-At: 
Cc: Michael Richardson , Anima WG 
Subject: Re: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-03.txt
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jul 2016 07:21:23 -0000

Inline

On Tue, Jul 19, 2016 at 10:10:29PM +1200, Brian E Carpenter wrote:
> On 19/07/2016 21:56, Michael Richardson wrote:
> > 
> > Toerless Eckert  wrote:
> >     > 1. Most network devices i deal with do not do mDNS.
> >     > i do not know enough IoT devices to have opinions about those, but
> >     > i wonder how important those are re. existing anima charter.
> > 
> > I am not mostly *not* thinking about tiny constrained motes here.
> > 
> > I'm thinking about various appliance-like things: the home NAS, the iDRAC/ILO
> > service processor, etc.
> > 
> > *THESE* devices might not run GRASP.
> > They *might* want to join the ACP.
> > They *do* want to do secure bootstrap.
> > They already have mDNS.
> > 
> > Or to put it another way: I'm thinking about the light controller, not the
> > lightblubs.
> 
> 1) the concept of a 'lightblub' is very appealing.

I think those are the nodes in the lighning network i proposed yesterday after roll *sigh* ;-)

> 2) on balance, I think I agree with Michael slightly more than
> with Toerless. Even though this use case is strictly outside the
> Anima charter, I think we'd look very silly if the autonomic security
> bootstrap could cope with routers and application devices such as
> autonomic energy management boxes, but not with lighting controllers.

Well, if those nodes *DO* want to join the ACP, they *MUST* already
have GRASP, so we're back to undecideable FUD like "is a separate
protocol more secure than a separate instance".

What we need from a proxy to a client is so simple, it's almost not a protocol:
Periodic link-local multicasted announcement of a data structure on the proxy:
[Name, [(method, locator)], receipt and parsing on client side.

If i take an existing mDNS library, i am sure i will have no easy way
to prohibit the client code from multicasting an mDNS query but
instead only listen to those announcement. So i have to hack into the
mDNS library. Which i may not be able to do because it's most likely OS/library
code that i don't even have in source.

If the device has upfront neither mDNS nore GRASP and does not want to
join the ACP but just bootstrap, it comes down to whats easier to code
into parsing the data structure. Pretty sure a CBOR library would win.
Don't think there's even a library just to parse DNS packets, and
inheriting a whole mDNS library in source and hacking it up to just
receive these packets doesn't sound like a good spend of time.

Cheers
    Toerless


From nobody Thu Jul 21 00:36:18 2016
Return-Path: 
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A349E12DAA8 for ; Thu, 21 Jul 2016 00:36:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.808
X-Spam-Level: 
X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 OumeodcwAAiX for ; Thu, 21 Jul 2016 00:36:14 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B438412DA71 for ; Thu, 21 Jul 2016 00:36:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3447; q=dns/txt; s=iport; t=1469086574; x=1470296174; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=Wv5ASmHwJLzXqF1hS5y4ZTVZ6xOKpLXwH5ZRI7wzHFA=; b=Vc5wzhOMLDVY/tXDI5NTCLCkZdJtczAh/JJLCxfCsNiYjBxOetXkWzqf wskWJVhO1YavBREB0DgWnqk4jq2duTW2gpUwkvsWlG0zWbl96KbMkeKGr PHwPsdb3hzJ0Dt1J7Z8dLXT9mkHrgsipU5/Zzx0cWRCCPmlDqGqY7PmFq E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AtAwCGepBX/5JdJa1dgz+BUrhigXuCY?= =?us-ascii?q?4M3AoEsOBQBAQEBAQEBZSdBDgGEDAEBBAE6PwULCxgJJQ8FNQETE4goCL0uAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBHIp3h2yCLwWIGYZoP4lmjmEKjzqQIR42hBMcM?= =?us-ascii?q?oRagn4BAQE?=
X-IronPort-AV: E=Sophos;i="5.28,398,1464652800"; d="scan'208";a="126482470"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jul 2016 07:36:13 +0000
Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u6L7aDwl021757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jul 2016 07:36:13 GMT
Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id u6L7aD02017744; Thu, 21 Jul 2016 00:36:13 -0700
Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u6L7aDCa017743; Thu, 21 Jul 2016 00:36:13 -0700
Date: Thu, 21 Jul 2016 00:36:13 -0700
From: Toerless Eckert 
To: Michael Richardson 
Message-ID: <20160721073613.GB16062@cisco.com>
References: <20160630230229.29590.10045.idtracker@ietfa.amsl.com> <0e01ea99-800f-7fcf-a3bb-ee8c08d8f550@gmail.com> <29519a5a-e380-b103-2846-e8e8a68cb691@gmail.com> <20160719073048.GB24601@cisco.com> <27877.1468923555@obiwan.sandelman.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <27877.1468923555@obiwan.sandelman.ca>
User-Agent: Mutt/1.4.2.2i
Archived-At: 
Cc: Anima WG 
Subject: Re: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-03.txt
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jul 2016 07:36:16 -0000

On Tue, Jul 19, 2016 at 06:19:15AM -0400, Michael Richardson wrote:
> I don't see the problem.
> a) proxy mDNS all you like, the proxy reply is supposed to be a
>    link-local address, and if the mDNS was proxied, then the connection
>    failed.

Unless multiple devices have the same link-local addresses. Like
the cheap arduino's that do not come with unique MAC addresses
and where then programmed lazily (happened to me).

> b) assuming that a non-link-local address was returned, and the
>    implementation was given a routable source address, (very possible
>    on an active LAN with DHCP/SLAAC available), and it connects to
>    the proxy.  There is then an enrollment. Or there isn't.

And we could explicitly ask implementations to ignore non-LL addresses
because they are an attack vector (one level of security when you do not
choose to use audit-token/ownership-voucher is to carefully plug new
devices only into sane network sockets, so you definitely do not
want to have those sockets infested by mDNS proxied proxy announcements).

> b) assuming that the enrollment worked, then whatever the ACP
>    discovery mechanism is (is it GRASP? I don't know) would run
>    on the link if the new system wanted to join the ACP.
> 
>    We never suggested that this discovery would be mDNS.

Yes, that would be GRASP.

>     > c) I can't imagine that all the IoT spaces will convege on just
>     > one discovery protocol as heir preference, so i think it's an
>     > illusion to think we can hit "one preferred" by all model.
> 
> Multiple vendors are doing this.
> We made multicast work in great part so that mDNS would work.

Link-local or L3 ASM with non-standard larger than LL mDNS ?

>     > 3. I have never seen point 3. as a system design principle. My background
>     > is in routing, and BGP and IGPs for examples are used extensively
>     > in the same devices running in different instances for different
>     > isolated domains (eg: l3vpn). Reuse of the same protocols as
>     > much as possible, because their security properties are understood
>     > and isolation between different instances is an accepted model of
>     > reuse and mutual isolation (shared code, no shared data).
> 
> Most priviledge elevation exploits for Windows and Linux leverage that a
> feature was added to the code base to support function X, which, when
> combined with operation Y, does something unintended.
> 
> For an example from the routing space, I point to why we can't use source
> routing in most places.  It has no security risks at all until you start
> assuming that things behind a firewall are trusted and things outside are
> not.

I can't translate that into something i think would apply to our case, but
if one is worrried that the eg: code-space of full blown GRASP inside
the ACP could be be impacted by the insecure mode GRASP, then i think
it's most easy to write the 10 lines of code to just implement the
periodic insecure mode GRASP announce messages as a one-off. And the
overhead to do this would IMHO compare well with risks of any
other code basis.

> This is the kind of thing that we are thinking about.

Sure. Lots of subtle points. To me they just add up to a negative
on mDNS in this circumstance.

Cheers
   Toerless

> --
> Michael Richardson , Sandelman Software Works
>  -= IPv6 IoT consulting =-


From nobody Thu Jul 21 01:11:17 2016
Return-Path: 
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A7D12DBA7 for ; Thu, 21 Jul 2016 01:11:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 BAphKVWPyhed for ; Thu, 21 Jul 2016 01:10:58 -0700 (PDT)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 DF5C212DBC2 for ; Thu, 21 Jul 2016 01:10:57 -0700 (PDT)
Received: by mail-wm0-x229.google.com with SMTP id o80so14728785wme.1 for ; Thu, 21 Jul 2016 01:10:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=O6KuvRrHHI3ulSlkYko3Y6PlocxFT29ERMjBvHpLT6o=; b=y5KewhKqzwBH8GQMVAkd2csO6MmEygeaDAEaLxOgTEC3AZIbqAt2gW5CCwMIHei/W/ l5PBMagMYBuv78PPuHjfdRGe/XFot9Ifx1fATg3I8ZMBA42D07QvAoMesE9Mr0j7VCd7 HlEuaJgKJ/XIuQm9ly9bRmO/5w2Ct5KZYdPaKpKRrGD67ZnjRezTARqs1fpw9dzUYpXx ZoC3zWflFQr5rrkAWv1+D5K/tH5UrPPrNywdsHQC6dRbkEA+bunL6JJFQaaaIQ/4Qtdv 8AioIYq6TkKlUkaxfC0zxthHNwTTckCdAKRD5lBztUwP38z4RtAJ4PceG+sO9tLK9YK8 ISTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=O6KuvRrHHI3ulSlkYko3Y6PlocxFT29ERMjBvHpLT6o=; b=aHV7yhsEmpZWumiZGGTiZ76XIdt6NnoRnpOT68kjyNcUeFDj4bMIRihpO8MyFaOxnB 4aJP8OimgjIySKNqIibaGJ1ykcnFHK9yvBZQLXe0pbG74z0K8cPlh3bbPcbk/0Zdi8Xt cfMGU+Nd2dWFEnGqEXf8FAj+Cl4L1OmStGj1kc7hi6SiiRWT6L2xJnG+52t98uYQc5oL laQUZOFcTJSy96DIo3NSEYSZ9TD2oEBbq5TiatIglkVjArhn+8mH209RceeU9RG4tcQ9 8NbeDBveW1lmjvbU0hLOQo/1JU+1dM/ILU37GuhB28L19kxEgZsq3v6OaiIWGZPsyJqc Zl7w==
X-Gm-Message-State: ALyK8tIiUluyqg8lTOvggrpvL2O1p1n42ZKiLBWkZWGJT2ipABUOo0gU/H3xQB8t9ZDh0Q==
X-Received: by 10.28.111.213 with SMTP id c82mr15606917wmi.47.1469088656483; Thu, 21 Jul 2016 01:10:56 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:152:28cc:dc4c:9703:6781? ([2001:67c:370:152:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id o142sm2036817wme.20.2016.07.21.01.10.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Jul 2016 01:10:55 -0700 (PDT)
To: Toerless Eckert , Michael Richardson 
References: <20160630230229.29590.10045.idtracker@ietfa.amsl.com> <0e01ea99-800f-7fcf-a3bb-ee8c08d8f550@gmail.com> <29519a5a-e380-b103-2846-e8e8a68cb691@gmail.com> <20160719073048.GB24601@cisco.com> <27877.1468923555@obiwan.sandelman.ca> <20160721073613.GB16062@cisco.com>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <5fbf06df-a2cd-65d2-b3d2-2ff5049da6bd@gmail.com>
Date: Thu, 21 Jul 2016 20:11:00 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <20160721073613.GB16062@cisco.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: Anima WG 
Subject: Re: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-03.txt
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jul 2016 08:11:04 -0000

Rushing to the bottom line:

On 21/07/2016 19:36, Toerless Eckert wrote:

...
> Sure. Lots of subtle points. To me they just add up to a negative
> on mDNS in this circumstance.

Obviously, if the bootstrap and ACP teams come to this conclusion,
this GRASP co-author will not fight it :-).

But we will have to justify it to the rest of the IETF.

   Brian


From nobody Wed Jul 27 03:31:30 2016
Return-Path: 
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A0512DF26 for ; Wed, 27 Jul 2016 03:31:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.508
X-Spam-Level: 
X-Spam-Status: No, score=-5.508 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 t0ReVY4ksJaY for ; Wed, 27 Jul 2016 03:31:27 -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 D65AE12DF18 for ; Wed, 27 Jul 2016 03:31:19 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CTH17541; Wed, 27 Jul 2016 10:31:17 +0000 (GMT)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 27 Jul 2016 11:31:16 +0100
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Wed, 27 Jul 2016 18:31:11 +0800
From: Sheng Jiang 
To: "anima@ietf.org" 
Thread-Topic: Abstract Summary from IETF96
Thread-Index: AdHn8f38+akX2sb0SBWNb/Cq4jIFEw==
Date: Wed, 27 Jul 2016 10:31:10 +0000
Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927CAC8AEC@NKGEML515-MBX.china.huawei.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.200.66.145]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.57988D76.009A, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: c557b7648e87393e843f7dd17776549a
Archived-At: 
Subject: [Anima] Abstract Summary from IETF96
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jul 2016 10:31:29 -0000

Hi, ANIMA,=0A=
=0A=
While we are working on minutes, there is an abstract summary have been upd=
ated.=0A=
=0A=
https://trac.tools.ietf.org/area/int/trac/wiki/IETF96=0A=
=0A=
Regards,=0A=
=0A=
Sheng=


From nobody Wed Jul 27 17:01:51 2016
Return-Path: 
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2CF412DB14 for ; Wed, 27 Jul 2016 17:01:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 52MNvX6pm_0y for ; Wed, 27 Jul 2016 17:01:48 -0700 (PDT)
Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (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 8A6C912DB0F for ; Wed, 27 Jul 2016 17:01:48 -0700 (PDT)
Received: by mail-pf0-x236.google.com with SMTP id x72so15586968pfd.2 for ; Wed, 27 Jul 2016 17:01:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=OkdPMq+xpn+TIaD64bW4GduSgXpYdQKBncSXNfBI6mM=; b=BB6/eCINrk74ZXs1Jxh2NWXF+NEe52X5nalK1gCOYBBsHsvAVnPIBz52/D/qg0Iooa gs62IPFORtCaVQv2HuZv5ysltt0SfL7+h+HQ/KBi5NS8QMWvNmOPuWSb7aoiF3V+m8om PhvT7K38gkJvZdi2q+/ZO819HUQ6ZpHcV96+JrjTCMeEaM8kHG628mvKXZy9tpxnZqnl tuXoyNS5m6q7IMoA4m/mpRrmDj8bJpXlr7aw7LZk+mE88TrsxY2HZaohxL2Sg1QKEz6w S1krBwkiZYmoJAhZCCKhwUxdFvxl5IRgvDTPQu/O8UPhB/zs6etBo5GG/HXdWmWGb1MN aGHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=OkdPMq+xpn+TIaD64bW4GduSgXpYdQKBncSXNfBI6mM=; b=aEJQi6xS0GdhUcaQsqHOhMRkXZRrUJvIVK97uVq9VUHDW5IiPjC9HpJOgRHP9lGHUf zW1Rm0ThAWavX98RpLybXbf81/VzCnHndTp/oWDenpJm4BxYliRBPb7PhMyBPB7/OkiJ 1I+DJHiJUhfLNsD4sZmeJB/G0LSImj7tnxSOPXIQfNbAGH/18O7ucV8IEko+f7/30H8b 6PQdw9WZNq2DtO5dMfQx46NgapPppBiq057r4rZKTHyGlwRoafUYutve+yduUyxOG6MB LE+ol4Kx8NlW4/9j4yZCirE5rjRPXxgI0cl9cwc1ctNQPvCBo5K65lVqNvsNwIcUsvMh mlUg==
X-Gm-Message-State: AEkoousyu+yOo6880IqVXCtdqm9CvJv0ruFlNdKQzMjD6XSRHNEeEJmHa7gyHRj+GDNV9A==
X-Received: by 10.98.86.85 with SMTP id k82mr54954147pfb.82.1469664108012; Wed, 27 Jul 2016 17:01:48 -0700 (PDT)
Received: from ?IPv6:2406:e007:5502:1:28cc:dc4c:9703:6781? ([2406:e007:5502:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id n80sm11829002pfi.19.2016.07.27.17.01.46 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Jul 2016 17:01:47 -0700 (PDT)
To: Anima WG 
References: <20160721102201.4532.10229.idtracker@ietfa.amsl.com>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Thu, 28 Jul 2016 12:01:51 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <20160721102201.4532.10229.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Anima] I-D Action: draft-richardson-anima-state-for-joinrouter-01.txt
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2016 00:01:49 -0000

> 3.2.  method 2: NAPT66 method

I hope this isn't a serious proposal.
(Has anybody thought about NPTv6 from a link-local address?
Slightly less horrible than NAPT66, if it can be made to work.)

> 4.  Comparison of methods

I kind of expected a conclusion.

Regards
   Brian