From nobody Mon Jun 1 19:10:14 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 098181A895E for ; Mon, 1 Jun 2015 19:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.111 X-Spam-Level: X-Spam-Status: No, score=-13.111 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xs_bSdxNefr7 for ; Mon, 1 Jun 2015 19:10:10 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4A891A895D for ; Mon, 1 Jun 2015 19:10:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1122; q=dns/txt; s=iport; t=1433211012; x=1434420612; h=date:from:to:cc:subject:message-id:reply-to:mime-version; bh=R3D0bPonnKnaApKOBKjO3W7n2wcJu7kSIG6T4zHvaDo=; b=ExMida4W6KURhtTg7NN4p8VjmgmG7AyFBQKoPLTP9rNt8j1dvkJAuqxg 5kiO9+VOH6NqEt0RQh3MpcxnR7MtNSqAPzVJ1Xwb4KeVPz4chaH0XZu5S uwmbAkFnQswSVuOvg7DRvKg2NlLyaPBSroC8Q+qJFUW14SkMuyqReiCVz s=; X-IronPort-AV: E=Sophos;i="5.13,536,1427760000"; d="scan'208";a="155466609" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-5.cisco.com with ESMTP; 02 Jun 2015 02:10:11 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t522A9Zw012945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Jun 2015 02:10:10 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 t522A95Q001493; Mon, 1 Jun 2015 19:10:09 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t522A8nC001491; Mon, 1 Jun 2015 19:10:08 -0700 Date: Mon, 1 Jun 2015 19:10:08 -0700 From: Toerless Eckert To: Anima WG Message-ID: <20150602021008.GA578@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: Cc: pritikin@cisco.com, mcr@sandelman.ca, anima-chairs@tools.ietf.org Subject: [Anima] Call for Volunteer - ANIMA bootstrap design team X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: anima-chairs@tools.ietf.org, pritikin@cisco.com, mcr@sandelman.ca List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 02:10:12 -0000 Dear all, we are calling for volunteers to form the bootstrap design team for ANIMA. We have selected two editors, Max Pritikin and Michael Richardson. The charter and goals for the bootstrap design team are outlined on its wiki page: http://trac.tools.ietf.org/wg/anima/trac/wiki/Bootstrap Because of the intended design team work, we expect that the design team members would need to spend at least half a day per week on this project for maybe 4..6 month, but it should become less afterwards. We would like to limit the design team to one year (or shorter if the goals are reached faster of course). As WG chairs we will participate and help of course in the design team primarily for logistics and alignment with other IETF effort. The design team discussions will be open to for all interested ANIMA participants even if they can not make the above time commtments. Please reply by end of the week if you are interested to contribute. If you are just interested to follow the work without commitment, please wait until we have created the mailing list. Thank you very much Sheng + Toerless From nobody Wed Jun 3 09:41:04 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E57881ACEAA for ; Wed, 3 Jun 2015 09:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cp4i0uELla-w for ; Wed, 3 Jun 2015 09:41:01 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E41B1ACE90 for ; Wed, 3 Jun 2015 09:40:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=531; q=dns/txt; s=iport; t=1433349659; x=1434559259; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=mUa4NGAWo7+UtkUXyornMSqgv6pEpFlrf/OIHFcCgpo=; b=m3sFLBKz3mEzuKhq3CWGmoac0xEmTja1mZg1fgBeuUmp6hl8YqBcOlBs i1DENd+e7bp5/8zPBTlkZiJKKSNqu+sUjWGU/76ZkafuMJTC/jLM/FBhj kaVtk6BqF5ByfDIJUgMW/wopIVVwUWJqDCdSVb2u+4Crdv5WbWseTtgz3 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B6BADILG9V/5hdJa1bgxCBOL1sZgmHUQKBQTgUAQEBAQEBAYEKhCQBBDpRASoUQiYBBBuIJagGs0sBAQEHAQEBAQEdkBiDT4EWBZMUjE2Dc5IjJIN4gjWBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,547,1427760000"; d="scan'208";a="4222410" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 03 Jun 2015 16:40:58 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t53GewWS027295 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 3 Jun 2015 16:40:58 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.238]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Wed, 3 Jun 2015 11:40:58 -0500 From: "Michael Behringer (mbehring)" To: Anima WG Thread-Topic: Work on Reference Model Thread-Index: AdCeG4md1Xr1iPDOQ4GwzMNlI6V2kQ== Date: Wed, 3 Jun 2015 16:40:58 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC3236@xmb-rcd-x14.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.141] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Anima] Work on Reference Model X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 03 Jun 2015 16:41:03 -0000 Working on the next version of the reference model, and need to have some d= etailed exchanges between the people interested in contributing.=20 I have the following list of people who were interested in contributing to = this work. If you are interested, and are NOT on this list, please ping me.= (I think I may be missing some folks that expressed interest...) B. Carpenter T. Eckert L. Ciavaglia B. Liu Of course we'll take the main discussion to the list. This is about organis= ation primarily. Michael From nobody Wed Jun 3 12:45:57 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00C731ACE86 for ; Wed, 3 Jun 2015 12:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ng09cxsD7FlC for ; Wed, 3 Jun 2015 12:45:54 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1C3F1ACE62 for ; Wed, 3 Jun 2015 12:45:44 -0700 (PDT) Received: by wibdq8 with SMTP id dq8so102915826wib.1 for ; Wed, 03 Jun 2015 12:45:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MniI9OkAbr1rftiK5AJXNB0MPLEVMNbwi9A7tZg0oqA=; b=DEm6y7lo9+75Ah7lOLgf8+c/49ETuazdPCB5UKh8zc459um3oIjuy8SY49dS7ECfjx OFUa0YOl89MNhL59WdYbA6LGwqsU467Nz3hADaEUaECrrSchzmBhvLbXUrcXCjcoOjen SFrzhBiozVgkp8ZLkS3oWw/eEJirBXHMeCJ5UW2yJqa42dxc9vSOQJIVxnm7LsIYkASB yf4I5iGkN3veBdcftR8Scms3K+0NxZUWzzo/4LtzI99yRdyQyjR53962rY/o5obA0bfJ EbOyWe8yh5epuY8K9WeyiBtn/RxxPkJcqIYg8wkgNNxah/3MpVtGqVWruM+mtbnJOCgn tTaA== MIME-Version: 1.0 X-Received: by 10.180.100.74 with SMTP id ew10mr45823258wib.12.1433360743364; Wed, 03 Jun 2015 12:45:43 -0700 (PDT) Received: by 10.27.220.1 with HTTP; Wed, 3 Jun 2015 12:45:43 -0700 (PDT) In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC3236@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC3236@xmb-rcd-x14.cisco.com> Date: Wed, 3 Jun 2015 12:45:43 -0700 Message-ID: From: John Strassner To: "Michael Behringer (mbehring)" Content-Type: multipart/alternative; boundary=14dae9cc9c5af180430517a24de1 Archived-At: Cc: Anima WG Subject: Re: [Anima] Work on Reference Model X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 03 Jun 2015 19:45:56 -0000 --14dae9cc9c5af180430517a24de1 Content-Type: text/plain; charset=UTF-8 Hi Michael, I am happy to contribute. best regards, John On Wed, Jun 3, 2015 at 9:40 AM, Michael Behringer (mbehring) < mbehring@cisco.com> wrote: > Working on the next version of the reference model, and need to have some > detailed exchanges between the people interested in contributing. > > I have the following list of people who were interested in contributing to > this work. If you are interested, and are NOT on this list, please ping > me. (I think I may be missing some folks that expressed interest...) > > B. Carpenter > T. Eckert > L. Ciavaglia > B. Liu > > Of course we'll take the main discussion to the list. This is about > organisation primarily. > > Michael > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > -- regards, John --14dae9cc9c5af180430517a24de1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Michael,

I am happy to co= ntribute.

best regards,
John
=

On Wed, Jun 3, 20= 15 at 9:40 AM, Michael Behringer (mbehring) <mbehring@cisco.com>= wrote:
Working on the next versio= n of the reference model, and need to have some detailed exchanges between = the people interested in contributing.

I have the following list of people who were interested in contributing to = this work. If you are interested, and are NOT on this list, please ping me.= =C2=A0 (I think I may be missing some folks that expressed interest...)

B. Carpenter
T. Eckert
L. Ciavaglia
B. Liu

Of course we'll take the main discussion to the list. This is about org= anisation primarily.

Michael


_______________________________________________
Anima mailing list
Anima@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/anima



--
regards,
John
--14dae9cc9c5af180430517a24de1-- From nobody Thu Jun 4 01:35:07 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30AAD1B2D5A for ; Thu, 4 Jun 2015 01:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEBT5xL-gyWl for ; Thu, 4 Jun 2015 01:35:04 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 812B41A92EA for ; Thu, 4 Jun 2015 01:35:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11844; q=dns/txt; s=iport; t=1433406904; x=1434616504; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=mhaz8t0DPZcWuTEXMBd8mq1K0E2IEVuA5aSEGhi5bRM=; b=NtDP6gno+RelZV/ScGicTleEKQb+mrPbkDrjRLRfFY3VjIE5tqfjVuJd yBUChxJ3hrko9Ms2YrHFJMNkO1JDBm+wwH/eK1uGyuQsjpzqY5JGlpP+/ sNFGPvd7FBN2PqlnWQcarVi6QwP+2mcavkk6Ap0HSOK+d4HZgHioQ6ghL E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D6BAClDHBV/5tdJa1bgkVLVF4Ggxi6PGYJgVABCYV3AhyBGjgUAQEBAQEBAYEKhCIBAQEEAQEBIApBCxACAQgOAwQBAQsdAwICAh8GCxQJCAEBBA4FCIgQAxINtnWeQg2FHAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi0OCTYFWEQEgLQQGAYJoL4EWBZBXgj+JQYMMg3OLHYcHJIN3b4EMOoEBAQEB X-IronPort-AV: E=Sophos;i="5.13,551,1427760000"; d="scan'208,217";a="156184634" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP; 04 Jun 2015 08:35:03 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t548Z3Aq024106 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Jun 2015 08:35:03 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.238]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Thu, 4 Jun 2015 03:35:03 -0500 From: "Michael Behringer (mbehring)" To: John Strassner Thread-Topic: [Anima] Work on Reference Model Thread-Index: AdCeG4md1Xr1iPDOQ4GwzMNlI6V2kQARD+uAABBZ8qA= Date: Thu, 4 Jun 2015 08:35:02 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC4C00@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC3236@xmb-rcd-x14.cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.168.8] Content-Type: multipart/alternative; boundary="_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FC4C00xmbrcdx14ciscoc_" MIME-Version: 1.0 Archived-At: Cc: Anima WG Subject: Re: [Anima] Work on Reference Model X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 04 Jun 2015 08:35:06 -0000 --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FC4C00xmbrcdx14ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm90ZWQuDQoNCkplZmZlcnNvbiBDYW1wb3MgTm9icmUgYWxzbyBwaW5nZWQgbWUgdW5pY2FzdC4N Cg0KRXhwZWN0IGFuIGVtYWlsIHNob3J0bHkuIE9yIHN1Z2dlc3Qgd2hlcmUgeW91IChldmVyeW9u ZSBpbnRlcmVzdGVkKSB3b3VsZCBsaWtlIHRvIGNvbnRyaWJ1dGUuDQoNCk1pY2hhZWwNCg0KRnJv bTogSm9obiBTdHJhc3NuZXIgW21haWx0bzpzdHJhenBkakBnbWFpbC5jb21dDQpTZW50OiAwMyBK dW5lIDIwMTUgMjE6NDYNClRvOiBNaWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpDQpDYzogQW5p bWEgV0cNClN1YmplY3Q6IFJlOiBbQW5pbWFdIFdvcmsgb24gUmVmZXJlbmNlIE1vZGVsDQoNCkhp IE1pY2hhZWwsDQoNCkkgYW0gaGFwcHkgdG8gY29udHJpYnV0ZS4NCg0KYmVzdCByZWdhcmRzLA0K Sm9obg0KDQpPbiBXZWQsIEp1biAzLCAyMDE1IGF0IDk6NDAgQU0sIE1pY2hhZWwgQmVocmluZ2Vy IChtYmVocmluZykgPG1iZWhyaW5nQGNpc2NvLmNvbTxtYWlsdG86bWJlaHJpbmdAY2lzY28uY29t Pj4gd3JvdGU6DQpXb3JraW5nIG9uIHRoZSBuZXh0IHZlcnNpb24gb2YgdGhlIHJlZmVyZW5jZSBt b2RlbCwgYW5kIG5lZWQgdG8gaGF2ZSBzb21lIGRldGFpbGVkIGV4Y2hhbmdlcyBiZXR3ZWVuIHRo ZSBwZW9wbGUgaW50ZXJlc3RlZCBpbiBjb250cmlidXRpbmcuDQoNCkkgaGF2ZSB0aGUgZm9sbG93 aW5nIGxpc3Qgb2YgcGVvcGxlIHdobyB3ZXJlIGludGVyZXN0ZWQgaW4gY29udHJpYnV0aW5nIHRv IHRoaXMgd29yay4gSWYgeW91IGFyZSBpbnRlcmVzdGVkLCBhbmQgYXJlIE5PVCBvbiB0aGlzIGxp c3QsIHBsZWFzZSBwaW5nIG1lLiAgKEkgdGhpbmsgSSBtYXkgYmUgbWlzc2luZyBzb21lIGZvbGtz IHRoYXQgZXhwcmVzc2VkIGludGVyZXN0Li4uKQ0KDQpCLiBDYXJwZW50ZXINClQuIEVja2VydA0K TC4gQ2lhdmFnbGlhDQpCLiBMaXUNCg0KT2YgY291cnNlIHdlJ2xsIHRha2UgdGhlIG1haW4gZGlz Y3Vzc2lvbiB0byB0aGUgbGlzdC4gVGhpcyBpcyBhYm91dCBvcmdhbmlzYXRpb24gcHJpbWFyaWx5 Lg0KDQpNaWNoYWVsDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCkFuaW1hIG1haWxpbmcgbGlzdA0KQW5pbWFAaWV0Zi5vcmc8bWFpbHRvOkFuaW1h QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYQ0K DQoNCg0KLS0NCnJlZ2FyZHMsDQpKb2huDQo= --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FC4C00xmbrcdx14ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9 IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5Ob3RlZC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJy aSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXpl PSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkplZmZlcnNvbiBDYW1wb3MgTm9icmUgYWxzbyBwaW5nZWQg bWUgdW5pY2FzdC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBj b2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkV4cGVjdCBhbiBlbWFpbCBzaG9ydGx5LiBPciBzdWdnZXN0IHdoZXJl IHlvdSAoZXZlcnlvbmUgaW50ZXJlc3RlZCkgd291bGQgbGlrZSB0byBjb250cmlidXRlLg0KPG86 cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNp emU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250Pjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBm YWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ TWljaGFlbDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxmb250IHNpemU9IjIiIGZh Y2U9IlRhaG9tYSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2ZvbnQt d2VpZ2h0OmJvbGQiPkZyb206PC9zcGFuPjwvZm9udD48L2I+PGZvbnQgc2l6ZT0iMiIgZmFjZT0i VGFob21hIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KIEpvaG4g U3RyYXNzbmVyIFttYWlsdG86c3RyYXpwZGpAZ21haWwuY29tXSA8YnI+DQo8Yj48c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U2VudDo8L3NwYW4+PC9iPiAwMyBKdW5lIDIwMTUgMjE6NDY8 YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86PC9zcGFuPjwvYj4gTWlj aGFlbCBCZWhyaW5nZXIgKG1iZWhyaW5nKTxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdo dDpib2xkIj5DYzo8L3NwYW4+PC9iPiBBbmltYSBXRzxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250 LXdlaWdodDpib2xkIj5TdWJqZWN0Ojwvc3Bhbj48L2I+IFJlOiBbQW5pbWFdIFdvcmsgb24gUmVm ZXJlbmNlIE1vZGVsPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBz aXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij5IaSBNaWNoYWVsLDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZv bnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdCI+SSBhbSBoYXBweSB0byBjb250cmlidXRlLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u dD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIz IiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+YmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBz aXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij5Kb2huPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXpl PSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 Ij5PbiBXZWQsIEp1biAzLCAyMDE1IGF0IDk6NDAgQU0sIE1pY2hhZWwgQmVocmluZ2VyIChtYmVo cmluZykgJmx0OzxhIGhyZWY9Im1haWx0bzptYmVocmluZ0BjaXNjby5jb20iIHRhcmdldD0iX2Js YW5rIj5tYmVocmluZ0BjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+V29ya2luZyBvbiB0 aGUgbmV4dCB2ZXJzaW9uIG9mIHRoZSByZWZlcmVuY2UgbW9kZWwsIGFuZCBuZWVkIHRvIGhhdmUg c29tZSBkZXRhaWxlZCBleGNoYW5nZXMgYmV0d2VlbiB0aGUgcGVvcGxlIGludGVyZXN0ZWQgaW4g Y29udHJpYnV0aW5nLjxicj4NCjxicj4NCkkgaGF2ZSB0aGUgZm9sbG93aW5nIGxpc3Qgb2YgcGVv cGxlIHdobyB3ZXJlIGludGVyZXN0ZWQgaW4gY29udHJpYnV0aW5nIHRvIHRoaXMgd29yay4gSWYg eW91IGFyZSBpbnRlcmVzdGVkLCBhbmQgYXJlIE5PVCBvbiB0aGlzIGxpc3QsIHBsZWFzZSBwaW5n IG1lLiZuYnNwOyAoSSB0aGluayBJIG1heSBiZSBtaXNzaW5nIHNvbWUgZm9sa3MgdGhhdCBleHBy ZXNzZWQgaW50ZXJlc3QuLi4pPGJyPg0KPGJyPg0KQi4gQ2FycGVudGVyPGJyPg0KVC4gRWNrZXJ0 PGJyPg0KTC4gQ2lhdmFnbGlhPGJyPg0KQi4gTGl1PGJyPg0KPGJyPg0KT2YgY291cnNlIHdlJ2xs IHRha2UgdGhlIG1haW4gZGlzY3Vzc2lvbiB0byB0aGUgbGlzdC4gVGhpcyBpcyBhYm91dCBvcmdh bmlzYXRpb24gcHJpbWFyaWx5Ljxicj4NCjxicj4NCk1pY2hhZWw8YnI+DQo8YnI+DQo8YnI+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkFuaW1h IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpBbmltYUBpZXRmLm9yZyI+QW5pbWFA aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9hbmltYSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vYW5pbWE8L2E+PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwi Pg0KPGJyPg0KLS0gPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+cmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQg c2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+Sm9objxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FC4C00xmbrcdx14ciscoc_-- From nobody Thu Jun 4 06:18:48 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86D631A879B for ; Thu, 4 Jun 2015 06:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMQwR98Efx1A for ; Thu, 4 Jun 2015 06:18:46 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 194C51A87A5 for ; Thu, 4 Jun 2015 06:18:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2803; q=dns/txt; s=iport; t=1433423927; x=1434633527; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=/EpjEJf3Dx2EjgBucmwyVWeZc64Y21zLau5R2p0eszw=; b=GXjCFvZr5pe60qF46LLqDazqJWVcBERbv/SRNqOOU4WzhOwivVN2KcoG soHr5Q1W3HP21yFk87R/pNolgTnVV1FBomcFBzfGTWjFqA2J4pjmEkZwQ OtfQBQdf5APXn7Ka7IYOgOWGaNAZrSeRw2gVIiV0viw9mwjc8eMV2UOeU A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CfBAClT3BV/4cNJK1bgxCBOL1ZZgmHUQKBODgUAQEBAQEBAYEKhCQBBDpRASoUQiYBBBuIJadUs04BAQEHAQEBAQEdj2ULKINPgRYFi1yHPoxTg3WSLCSDd4FyQ4EBAQEB X-IronPort-AV: E=Sophos;i="5.13,552,1427760000"; d="scan'208";a="156342227" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-5.cisco.com with ESMTP; 04 Jun 2015 13:18:46 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t54DIjmB032411 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 4 Jun 2015 13:18:45 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.238]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Thu, 4 Jun 2015 08:18:45 -0500 From: "Michael Behringer (mbehring)" To: Anima WG Thread-Topic: Next steps for the reference document Thread-Index: AdCeyJnnoO1vHkFQQ5yr85+CL+laOw== Date: Thu, 4 Jun 2015 13:18:44 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC52BD@xmb-rcd-x14.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.168.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Anima] Next steps for the reference document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 04 Jun 2015 13:18:47 -0000 Thanks for all who volunteered to participate in the reference doc. While d= etailed discussions may be between the contributors, the main technical dis= cussions should probably take place on the main list. Here, I summarise my = view on what needs to be done in the reference document.=20 If someone thinks he/she can produce text for the respective sections, plea= se let me / the list know.=20 The overall goal is to show how all the various drafts, protocols, and disc= ussions in the ANIMA WG fit together. Points to address:=20 - We should have a short section on intent. Explaining ingest of intent, di= stribution, the nature (on top of what's in RFC7575). That intent is signed= , time stamps, etc. Probably pointing back to RFC7575. (Note intent distrib= ution is handled in section 7.3) - Do we want to address "constrained" AN nodes, with limited capabilities, = here? I think so... We'll need that for AN in constrained environments. Thi= s could go into a new section in section 3: "constrained network elements".= =20 - The masa section needs to be written. The masa will be an optional elemen= t. Needs to point to the bootstrap draft, which explains the basics.=20 - Naming section needs meat. What names are used for, where it is in the do= main cert.=20 - Addressing section needs to bring in recent discussions. Needs to include= how an ASA uses addressing. per node or per ASA. (I think we concluded per= node).=20 - Domain certificate template. We should write a section on the AN domain c= ertificate. How the various fields are used.=20 - Need to explain sub-domains - Section 9 needs to be worked out. This is all about conflict resolution. = Maybe we should re-name that section? RFC 7575 already mentions this. Maybe= we don't need much more here.=20 - trust management: inside a domain, between domain and sub-domain, and bet= ween domains. This should become a new section.=20 - Need to treat the question of the "out of band" ACP versus the inline ACP= . The two models both work, but there are implications, different benefits,= drawbacks, etc. This needs to be explained.=20 - Routing: In the case of a virtually separate ACP, as in draft-behringer-a= nima-autonomic-control-plane, we need to also define a routing protocol (th= inking of the discussion in homenet, this might be "fun"...)=20 - Need considerations for APIs: How can ASAs use the ANI?=20 - Need considerations for a data model. What it should cover, scope.=20 - We should also describe the management angle - Security considerations need to be expanded. Threat analysis needs work; = need general security considerations, talk about the PKI and trust model, e= tc.=20 Thoughts? Anything missing? Any volunteer for a specific part?=20 Michael From nobody Thu Jun 4 07:56:02 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 858921A8797 for ; Thu, 4 Jun 2015 07:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i_CkeDTnduWn for ; Thu, 4 Jun 2015 07:55:57 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 334221A1BC9 for ; Thu, 4 Jun 2015 07:55:57 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id BCD6C737949F9; Thu, 4 Jun 2015 14:55:51 +0000 (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 t54EtptY012689 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Jun 2015 16:55:51 +0200 Received: from [172.27.204.69] (135.239.27.41) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 4 Jun 2015 16:55:51 +0200 Message-ID: <557066F0.80902@alcatel-lucent.com> Date: Thu, 4 Jun 2015 16:55:44 +0200 From: Laurent Ciavaglia Organization: Alcatel-Lucent Bell Labs France User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , Anima WG References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC52BD@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC52BD@xmb-rcd-x14.cisco.com> Content-Type: multipart/alternative; boundary="------------070104090902040006070908" X-Originating-IP: [135.239.27.41] Archived-At: Subject: Re: [Anima] Next steps for the reference document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 04 Jun 2015 14:56:00 -0000 --------------070104090902040006070908 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Hi Michael, Thanks for rounding the todo / issue list. I am ok to contribute on the intent and section 8 - "coordination / conflict resolution" (as per draft-behringer-anima-reference-model-01), and section 9 - "Hybrid Approach with Non-Autonomic Functions". For "constrained" AN nodes, I think they are in scope, but what is the implication for the reference model document? Do we already have some inputs/requirements (e.g. from other WGs or sources) that could enlighten how / to which extent autonomic networks / their functionalities and mechanisms shall (or not) adapt (to such constrained nodes)? I am not quite sure what you meant by the "management angle"... I assume you are talking about the management/operations of the whole system (as if deployed by e.g. a network operator). if correct, then I think some aspects of lifecycle / phases/ operations should be considered / written in the document. I can contribute to this but would prefer to start with some group discussions to see if we agree on the scope first. A tricky (missing) part might be the relationships among the various component. If judged useful (I think it is especially for ANIMA "outsiders"), it could be in the form of a diagram and/or linked to the (TBC) lifecycle section. Of course, we shall not seek a ultimate, absolute reference diagram, but at least proposing one can help understanding, as you wrote: "show how all the various drafts, protocols, and discussions in the ANIMA WG fit together". Thanks, best regards, Laurent. On 04/06/2015 15:18, Michael Behringer (mbehring) wrote: > Thanks for all who volunteered to participate in the reference doc. While detailed discussions may be between the contributors, the main technical discussions should probably take place on the main list. Here, I summarise my view on what needs to be done in the reference document. > > If someone thinks he/she can produce text for the respective sections, please let me / the list know. > > The overall goal is to show how all the various drafts, protocols, and discussions in the ANIMA WG fit together. > > Points to address: > > - We should have a short section on intent. Explaining ingest of intent, distribution, the nature (on top of what's in RFC7575). That intent is signed, time stamps, etc. Probably pointing back to RFC7575. (Note intent distribution is handled in section 7.3) > - Do we want to address "constrained" AN nodes, with limited capabilities, here? I think so... We'll need that for AN in constrained environments. This could go into a new section in section 3: "constrained network elements". > - The masa section needs to be written. The masa will be an optional element. Needs to point to the bootstrap draft, which explains the basics. > - Naming section needs meat. What names are used for, where it is in the domain cert. > - Addressing section needs to bring in recent discussions. Needs to include how an ASA uses addressing. per node or per ASA. (I think we concluded per node). > - Domain certificate template. We should write a section on the AN domain certificate. How the various fields are used. > - Need to explain sub-domains > - Section 9 needs to be worked out. This is all about conflict resolution. Maybe we should re-name that section? RFC 7575 already mentions this. Maybe we don't need much more here. > - trust management: inside a domain, between domain and sub-domain, and between domains. This should become a new section. > - Need to treat the question of the "out of band" ACP versus the inline ACP. The two models both work, but there are implications, different benefits, drawbacks, etc. This needs to be explained. > - Routing: In the case of a virtually separate ACP, as in draft-behringer-anima-autonomic-control-plane, we need to also define a routing protocol (thinking of the discussion in homenet, this might be "fun"...) > - Need considerations for APIs: How can ASAs use the ANI? > - Need considerations for a data model. What it should cover, scope. > - We should also describe the management angle > - Security considerations need to be expanded. Threat analysis needs work; need general security considerations, talk about the PKI and trust model, etc. > > Thoughts? Anything missing? Any volunteer for a specific part? > > Michael > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > > -- Bien cordialement, Best regards, *Laurent Ciavaglia* Secure Cloud Networking Bell Labs | Alcatel Lucent phone: +33 160 402 636 email: laurent.ciavaglia@alcatel-lucent.com linkedin: laurentciavaglia address: Route de Villejust | 91620 Nozay | France --------------070104090902040006070908 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit Hi Michael,

Thanks for rounding the todo / issue list.

I am ok to contribute on the intent and section 8 - "coordination / conflict resolution" (as per draft-behringer-anima-reference-model-01), and section 9 - "Hybrid Approach with Non-Autonomic Functions".

For "constrained" AN nodes, I think they are in scope, but what is the implication for the reference model document? Do we already have some inputs/requirements (e.g. from other WGs or sources) that could enlighten how / to which extent autonomic networks / their functionalities and mechanisms shall (or not) adapt (to such constrained nodes)?

I am not quite sure what you meant by the "management angle"... I assume you are talking about the management/operations of the whole system (as if deployed by e.g. a network operator). if correct, then I think some aspects of lifecycle / phases/ operations should be considered / written in the document. I can contribute to this but would prefer to start with some group discussions to see if we agree on the scope first.

A tricky (missing) part might be the relationships among the various component. If judged useful (I think it is especially for ANIMA "outsiders"), it could be in the form of a diagram and/or linked to the (TBC) lifecycle section.
Of course, we shall not seek a ultimate, absolute reference diagram, but at least proposing one can help understanding, as you wrote: "show how all the various drafts, protocols, and discussions in the ANIMA WG fit together".

Thanks, best regards, Laurent.


On 04/06/2015 15:18, Michael Behringer (mbehring) wrote:
Thanks for all who volunteered to participate in the reference doc. While detailed discussions may be between the contributors, the main technical discussions should probably take place on the main list. Here, I summarise my view on what needs to be done in the reference document. 

If someone thinks he/she can produce text for the respective sections, please let me / the list know. 

The overall goal is to show how all the various drafts, protocols, and discussions in the ANIMA WG fit together.

Points to address: 

-	We should have a short section on intent. Explaining ingest of intent, distribution, the nature (on top of what's in RFC7575). That intent is signed, time stamps, etc. Probably pointing back to RFC7575. (Note intent distribution is handled in section 7.3)
-	Do we want to address "constrained" AN nodes, with limited capabilities, here? I think so... We'll need that for AN in constrained environments. This could go into a new section in section 3: "constrained network elements". 
-	The masa section needs to be written. The masa will be an optional element. Needs to point to the bootstrap draft, which explains the basics. 
-	Naming section needs meat. What names are used for, where it is in the domain cert. 
-	Addressing section needs to bring in recent discussions. Needs to include how an ASA uses addressing. per node or per ASA. (I think we concluded per node). 
-	Domain certificate template. We should write a section on the AN domain certificate. How the various fields are used. 
-	Need to explain sub-domains
-	Section 9 needs to be worked out. This is all about conflict resolution. Maybe we should re-name that section? RFC 7575 already mentions this. Maybe we don't need much more here. 
-	trust management: inside a domain, between domain and sub-domain, and between domains. This should become a new section. 
-	Need to treat the question of the "out of band" ACP versus the inline ACP. The two models both work, but there are implications, different benefits, drawbacks, etc. This needs to be explained. 
-	Routing: In the case of a virtually separate ACP, as in draft-behringer-anima-autonomic-control-plane, we need to also define a routing protocol (thinking of the discussion in homenet, this might be "fun"...) 
-	Need considerations for APIs: How can ASAs use the ANI? 
-	Need considerations for a data model. What it should cover, scope. 
-	We should also describe the management angle
-	Security considerations need to be expanded. Threat analysis needs work; need general security considerations, talk about the PKI and trust model, etc. 

Thoughts? Anything missing? Any volunteer for a specific part? 

Michael

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

--

Bien cordialement, Best regards,

 

Laurent Ciavaglia

Secure Cloud Networking

Bell Labs | Alcatel Lucent

 

phone: +33 160 402 636

email: laurent.ciavaglia@alcatel-lucent.com

linkedin: laurentciavaglia

address: Route de Villejust | 91620 Nozay | France

--------------070104090902040006070908-- From nobody Thu Jun 4 08:59:36 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0074E1A8AE8 for ; Thu, 4 Jun 2015 08:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.529 X-Spam-Level: X-Spam-Status: No, score=-13.529 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ms_OLGcYCQ1 for ; Thu, 4 Jun 2015 08:59:27 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 639721A8ADC for ; Thu, 4 Jun 2015 08:59:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33177; q=dns/txt; s=iport; t=1433433567; x=1434643167; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=TVd7wzg2ARHrTrbVWzw5cPIljElR7xiaLBQs7Oc7vbM=; b=HOJIpEb7PC6po0W6jBplkhp/9vx5dxLvwRK/MYgG21ClX0Jvr7ynkkJ8 jly0dyTyh382EnCOOe+LsnVuzivn/jdQC4Z4xQimNCWBVhaH+indXZd4d CMTr+Sdkm33ciIlJXVRQl7jPL4CT0BscmBmGrAXlTEkl1sGvdp6bCXRWp w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D2BgCwdHBV/5tdJa1bgkVLVF4GvVk8gWoZAQmFdwKBOEwBAQEBAQGBC4QiAQEBBAEBASpBBBUCAgEIEQQBAQsWAQYHGwwLFAkIAQEEARIIiCUN20EBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBIs/hCIBCgcBIAUoCgGDF4EWBYtchH+CP4Q8iBeDdZIsERODd2+BAwkXI4EBAQEB X-IronPort-AV: E=Sophos;i="5.13,553,1427760000"; d="scan'208,217";a="425302845" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 04 Jun 2015 15:59:25 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t54FxPYL017568 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Jun 2015 15:59:25 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.238]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Thu, 4 Jun 2015 10:59:25 -0500 From: "Michael Behringer (mbehring)" To: Laurent Ciavaglia , Anima WG Thread-Topic: [Anima] Next steps for the reference document Thread-Index: AdCeyJnnoO1vHkFQQ5yr85+CL+laOwAN9cwAAAiCoYA= Date: Thu, 4 Jun 2015 15:59:25 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC5803@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC52BD@xmb-rcd-x14.cisco.com> <557066F0.80902@alcatel-lucent.com> In-Reply-To: <557066F0.80902@alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.141] Content-Type: multipart/alternative; boundary="_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FC5803xmbrcdx14ciscoc_" MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Next steps for the reference document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 04 Jun 2015 15:59:35 -0000 --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FC5803xmbrcdx14ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable inline... From: Laurent Ciavaglia [mailto:Laurent.Ciavaglia@alcatel-lucent.com] Sent: 04 June 2015 16:56 To: Michael Behringer (mbehring); Anima WG Subject: Re: [Anima] Next steps for the reference document Hi Michael, Thanks for rounding the todo / issue list. I am ok to contribute on the intent and section 8 - "coordination / conflic= t resolution" (as per draft-behringer-anima-reference-model-01), and sectio= n 9 - "Hybrid Approach with Non-Autonomic Functions". MB: Thanks for volunteering! For "constrained" AN nodes, I think they are in scope, but what is the impl= ication for the reference model document? Do we already have some inputs/re= quirements (e.g. from other WGs or sources) that could enlighten how / to w= hich extent autonomic networks / their functionalities and mechanisms shall= (or not) adapt (to such constrained nodes)? MB: I think we need to work out what is the minimum "useful" autonomic node= , and specify what the requirements for those are. Personally I do not thin= k we want to make every smallest sensor fully autonomic. I see three classe= s: 1) fully AN capable (what we describe today) 2) constrained AN capable: This will be a node that for example can be= an edge, can use AN functions, but doesn't participate in many functions, = only has stub functionality. 3) non AN capable (according to our definitions here): Those can still= implement something "autonomic" in their own understanding of the world, b= ut it may or may not work with what we're doing here. We need to consider nodes in 1) and 2). For 3) I would argue we'd require s= ome gateway between two different models. None of this is set in stone, it'= s just my current thinking. I am not quite sure what you meant by the "management angle"... I assume yo= u are talking about the management/operations of the whole system (as if de= ployed by e.g. a network operator). if correct, then I think some aspects o= f lifecycle / phases/ operations should be considered / written in the docu= ment. I can contribute to this but would prefer to start with some group di= scussions to see if we agree on the scope first. MB: Yes, that's what I had in mind. Thanks for volunteering. :) A tricky (missing) part might be the relationships among the various compon= ent. If judged useful (I think it is especially for ANIMA "outsiders"), it = could be in the form of a diagram and/or linked to the (TBC) lifecycle sect= ion. Of course, we shall not seek a ultimate, absolute reference diagram, but at= least proposing one can help understanding, as you wrote: "show how all th= e various drafts, protocols, and discussions in the ANIMA WG fit together". MB: Yes, we should have such a diagram. Or diagram(s). Thanks Laurent! Michael Thanks, best regards, Laurent. On 04/06/2015 15:18, Michael Behringer (mbehring) wrote: Thanks for all who volunteered to participate in the reference doc. While d= etailed discussions may be between the contributors, the main technical dis= cussions should probably take place on the main list. Here, I summarise my = view on what needs to be done in the reference document. If someone thinks he/she can produce text for the respective sections, plea= se let me / the list know. The overall goal is to show how all the various drafts, protocols, and disc= ussions in the ANIMA WG fit together. Points to address: - We should have a short section on intent. Explaining ingest of inte= nt, distribution, the nature (on top of what's in RFC7575). That intent is = signed, time stamps, etc. Probably pointing back to RFC7575. (Note intent d= istribution is handled in section 7.3) - Do we want to address "constrained" AN nodes, with limited capabili= ties, here? I think so... We'll need that for AN in constrained environment= s. This could go into a new section in section 3: "constrained network elem= ents". - The masa section needs to be written. The masa will be an optional = element. Needs to point to the bootstrap draft, which explains the basics. - Naming section needs meat. What names are used for, where it is in = the domain cert. - Addressing section needs to bring in recent discussions. Needs to i= nclude how an ASA uses addressing. per node or per ASA. (I think we conclud= ed per node). - Domain certificate template. We should write a section on the AN do= main certificate. How the various fields are used. - Need to explain sub-domains - Section 9 needs to be worked out. This is all about conflict resolu= tion. Maybe we should re-name that section? RFC 7575 already mentions this.= Maybe we don't need much more here. - trust management: inside a domain, between domain and sub-domain, a= nd between domains. This should become a new section. - Need to treat the question of the "out of band" ACP versus the inli= ne ACP. The two models both work, but there are implications, different ben= efits, drawbacks, etc. This needs to be explained. - Routing: In the case of a virtually separate ACP, as in draft-behri= nger-anima-autonomic-control-plane, we need to also define a routing protoc= ol (thinking of the discussion in homenet, this might be "fun"...) - Need considerations for APIs: How can ASAs use the ANI? - Need considerations for a data model. What it should cover, scope. - We should also describe the management angle - Security considerations need to be expanded. Threat analysis needs = work; need general security considerations, talk about the PKI and trust mo= del, etc. Thoughts? Anything missing? Any volunteer for a specific part? Michael _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima -- Bien cordialement, Best regards, Laurent Ciavaglia Secure Cloud Networking Bell Labs | Alcatel Lucent phone: +33 160 402 636 email: laurent.ciavaglia@alcatel-lucent.com linkedin: laurentciavaglia address: Route de Villejust | 91620 Nozay | France --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FC5803xmbrcdx14ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= inline̷= 0;

From: Laurent Ciavaglia [mailto:Laurent.Ciavaglia@alcatel-lucent.com]
Sent: 04 June 2015 16:56
To: Michael Behringer (mbehr= ing); Anima WG
Subject: Re: [Anima] Next st= eps for the reference document

=  <= /font>

Hi Michael,=

Thanks for rounding the todo / issue list.

I am ok to contribute on the intent and section 8 - "coordination / co= nflict resolution" (as per draft-behringer-anima-reference-model-01), = and section 9 - "Hybrid Approach with Non-Autonomic Functions".

MB: Thanks for volunteering!

For "c= onstrained" AN nodes, I think they are in scope, but what is the impli= cation for the reference model document? Do we already have some inputs/requireme= nts (e.g. from other WGs or sources) that could enlighten how / to which ex= tent autonomic networks / their functionalities and mechanisms shall (or no= t) adapt (to such constrained nodes)?

MB: I think we need to work out what is the minimum = 220;useful” autonomic node, and specify what the requirements for those are. Personally I do not think we want to make every smallest se= nsor fully autonomic. I see three classes:

1)      fully AN capable (what we describe today)

2)      constrained AN capable: This will be a node that fo= r example can be an edge, can use AN functions, but doesn’t participa= te in many functions, only has stub functionality.

3)      non AN capable (according to our definitions here):= Those can still implement something “autonomic” in their own u= nderstanding of the world, but it may or may not work with what we’re doing here.

We need to consider nodes in 1) and 2). For 3) I would argue we’d require some gateway between two different models. None of this= is set in stone, it’s just my current thinking.


I am not quite sure what you meant by the "management angle"... I= assume you are talking about the management/operations of the whole system= (as if deployed by e.g. a network operator). if correct, then I think some= aspects of lifecycle / phases/ operations should be considered / written in the document. I can contribute to this b= ut would prefer to start with some group discussions to see if we agree on = the scope first.=

MB: Yes, that’s what I had in mind. Thanks for vo= lunteering. J

A tricky (missing) part might be the relationships among the various compon= ent. If judged useful (I think it is especially for ANIMA "outsiders&q= uot;), it could be in the form of a diagram and/or linked to the (TBC) life= cycle section.
Of course, we shall not seek a ultimate, absolute reference diagram, but at= least proposing one can help understanding, as you wrote: "show how a= ll the various drafts, protocols, and discussions in the ANIMA WG fit toget= her".

MB: Yes, we should have such a diagram. Or diagram(s).

Thanks Laurent!

Michael

Thanks, best regards, Laurent.

On 04/06/2015 15:18, Michael Behringer (mbehring) = wrote:

Thanks for all who volunteered to parti=
cipate in the reference doc. While detailed discussions may be between the =
contributors, the main technical discussions should probably take place on =
the main list. Here, I summarise my view on what needs to be done in the re=
ference document. 
 
If someone thinks he/she can produce te=
xt for the respective sections, please let me / the list know. <=
/span>
 
The overall goal is to show how all the=
 various drafts, protocols, and discussions in the ANIMA WG fit together.
 
Points to address: 
 
-       W=
e should have a short section on intent. Explaining ingest of intent, distr=
ibution, the nature (on top of what's in RFC7575). That intent is signed, t=
ime stamps, etc. Probably pointing back to RFC7575. (Note intent distributi=
on is handled in section 7.3)
-       D=
o we want to address "constrained" AN nodes, with limited capabil=
ities, here? I think so... We'll need that for AN in constrained environmen=
ts. This could go into a new section in section 3: "constrained networ=
k elements". 
-       T=
he masa section needs to be written. The masa will be an optional element. =
Needs to point to the bootstrap draft, which explains the basics. 
-       N=
aming section needs meat. What names are used for, where it is in the domai=
n cert. 
-       A=
ddressing section needs to bring in recent discussions. Needs to include ho=
w an ASA uses addressing. per node or per ASA. (I think we concluded per no=
de). 
-       D=
omain certificate template. We should write a section on the AN domain cert=
ificate. How the various fields are used. 
-       N=
eed to explain sub-domains
-       S=
ection 9 needs to be worked out. This is all about conflict resolution. May=
be we should re-name that section? RFC 7575 already mentions this. Maybe we=
 don't need much more here. 
-       t=
rust management: inside a domain, between domain and sub-domain, and betwee=
n domains. This should become a new section. 

-       N=
eed to treat the question of the "out of band" ACP versus the inl=
ine ACP. The two models both work, but there are implications, different be=
nefits, drawbacks, etc. This needs to be explained. 


-       R=
outing: In the case of a virtually separate ACP, as in draft-behringer-anim=
a-autonomic-control-plane, we need to also define a routing protocol (think=
ing of the discussion in homenet, this might be "fun"...) 


-       N=
eed considerations for APIs: How can ASAs use the ANI? 


-       N=
eed considerations for a data model. What it should cover, scope. 


-       W=
e should also describe the management angle


-       S=
ecurity considerations need to be expanded. Threat analysis needs work; nee=
d general security considerations, talk about the PKI and trust model, etc.=
 


 


Thoughts? Anything missing? Any volunte=
er for a specific part? 


 


Michael


 


_______________________________________=
________


Anima mailing list


Anima=
@ietf.org


https://www.ietf.org/mailman/listinfo/anima=



 


 

=  <= /font>

--

Bien cordialement, Best regards,

 

Laurent Ciavaglia

Secure Cloud Networking

Bell Labs | Alcatel Lucent

 

phone: +33 160 402 636

email: laurent.ciavaglia@= alcatel-lucent.com

linkedin: laurentciavaglia

address: Route de Villejust | 91620 Nozay | France<= o:p>

--_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FC5803xmbrcdx14ciscoc_-- From nobody Thu Jun 4 09:56:50 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D63611A0065; Thu, 4 Jun 2015 09:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yzi0WUmdqfm8; Thu, 4 Jun 2015 09:56:43 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC4F41A0067; Thu, 4 Jun 2015 09:56:43 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id DC4C420098; Thu, 4 Jun 2015 13:10:43 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id F282863AE8; Thu, 4 Jun 2015 12:56:41 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D1FF6637FE; Thu, 4 Jun 2015 12:56:41 -0400 (EDT) From: Michael Richardson To: anima@ietf.org In-Reply-To: <556F8C12.7060003@gmail.com> References: <556F8C12.7060003@gmail.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: Cc: Anima signaling DT Subject: [Anima] some small summary of bootstrap conversation X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 04 Jun 2015 16:56:47 -0000 --=-=-= Content-Type: text/plain The bootstrap design team is still bootstrapping, but Max, Toerless and I have had three 1hr phone conferences (May 29 meeting cancelled). They have been Friday at 1700UTC, but are now Thursday at 1400UTC, and will occur June 11 as well. A doodle poll to confirm a regular time will go out next week once the list of parties has been identified. I think that the AD still has to approve things. We started with a discussion of the charter for the DT, and how it relates to the charter for the WG, and the result is at: https://tools.ietf.org/wg/anima/trac/wiki/Bootstrap the places where it says "OWN" means, it's in scope for this DT, where it says REQUIRE, means that we are assuming it as input, and where it says PROVIDE, means that they are outputs. We continued with a recap discussion and partial walkthrough of draft-pritikin-anima-bootstrapping-keyinfra-01 We have some ideas about terminology that we think might be useful along the lines of ducking/imprinting (cf: Konrad Lorenz and http://en.wikipedia.org/wiki/Imprinting_(psychology) ), but we also thought of fraternities and pledges. If you didn't grow up with http://en.wikipedia.org/wiki/Animal_House, or http://en.wikipedia.org/wiki/Revenge_of_the_Nerds, then let me provide some explanation. The idea that during the bootstrap process, there is a period when the network (the ACP aka fraternity) and the new node (the peldge) check each other out for fitness. Wikipedia says this about fraternities: Requirements may be imposed on those wishing to pledge either by the school or the organization itself, often including a minimum grade point average, wearing a pledge pin, learning about the history and structure of the organization, and performing public service. When a school places an age or tenure requirement on joining, this is called "deferred recruitment", as joining is deferred for a semester or year. The pledgeship period also serves as a probationary period in which both the organization and the pledge decide if they are compatible and will have a fulfilling experience. In today's telecon, we discussed some of the 6tisch specific requirements on bootstrap, specifically: 1) the "pledges" (or joining nodes) are constrained in CPU, code space, and energy (if battery powered, etc) 2) more importantly, the network is very constrained, 250Kbit/s max, 127 byte fraglets, and 6tisch likely would be configured to further restricts the bandwidth in the network available to joining nodes. Calculations suggest that just transmitting a DH pair and associated parts between adjacent nodes could take between 2 and 40s. 3) most protocols will require an authorization protocol that will need to travel through the LLN mesh up to a non-constrained node. The convergence of many such setup processes may well overwhelm the parts of the network closer to the root of the tree. Congestion is an issue, and retransmissions cost energy. I explained some the ideas/conclusions from draft-richardson-6tisch-security-architecture-02 and draft-richardson-6tisch--security-6top-04, which were: a) using CBOR encoded YANG over CoAP/DTLS leverages 6tisch ("6top") plans for 6tisch node/PCE communication, maximizing code reuse. b) initiating the secure bootstrap process from the non-constrained side, and having the constrained nodes remain silent after an initial "hello" packet, allowed the network manager to protect, conserve and prioritize the join bandwidth. c) it turns out there is an additional benefit in making the constrained node the TLS "Server" -- side. Specifically, it means that the selection of crypto parameters is done by the more constrained device, and the Server sends it's certificate payload first. The non-constrained node (or "JCE" == Join Coordination Entity) will receive that certificate, and can consult whatever network (or human) resources is needs to before responding with a Client Certificate that will satisfy the constrained node. It can also know via Trusted CA extension what certificate chain (if any) it needs to provide. It is observed that point (c) is not essential; that a similiar thing can be accomplished with less grace using SNI (RFC6066) and some other extensions. Note that while 6tisch is/plans-to specify that 6top is the protocol that runs over the resulting CoAP/DTLS channel, and that secure join to 6tisch consists of provisioning certain identities and parameters through that channel, the resulting channel could be used for anything. We also noted that in the context of two routers plugged in together on a lonesome grassy knoll would need to form a secure connection; that one needs to be the initiator ("client") and the other the responder ("server") is obvious, but whether both systems need to always support both roles is open for discussion. Perhaps in the constrained case, it is acceptable that constrained devices can always be responders, and in the non-constrained case, they assume both roles. I also note, recalling I was told that one implementation of the ACP consists of IKEv2 initiated channels over IPv6-link-local addresses, that the essential properties the bootstrap design team intends to provide work just fine for IKEv2 as they do for DTLS. I don't know if the ANIMA signaling protocol should occur before such a channel is established, or inside of this (provisional) channel, or whether it should instead run inside IKEv2 (maybe inside EAP). I note that 6tisch has a few potential, "I am here" messages, with RPL DAOs and Efficient-ND (E)AROs being the two ones. GDNP or HNCP or just IKE-port-500 messages are in my opinion also possibilities. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVXCDSYCLcPvd0N1lAQJalQgAuiHhJV6Fqc8FE4Lz/RrIMG2kqMsx3n7q dCB/7qqwqja6NQ1Q47Myn/9yX04zoKF4ALZdvxQoo2dD2Zhzbx2Jlledbub4kz5B +7g8B1wYqpEcnkrMO1H8vybi9r9mc8W1fdN5qW+FSJc3GFg1Bn8x1NJOy0aFGj+5 MZt3Nw8Ju3iw6DUj9Bi/7vWIpXpQuJX5oSzQdZObNudvF/xyTB490SzZWKrI4FwD 70y9++7Gy122TZAycGEJSrfEyqeZpwCsn8BxCWXdrddnmS1ehNqk8xmVN75hy6ha /2ZefSjqluCbJwQfBklsLUB95qx9yB3BRndiabLRnU6FqGJwxzCm0Q== =Mgry -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 4 11:25:00 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 530571A884D for ; Thu, 4 Jun 2015 11:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwwvUjEgpzoJ for ; Thu, 4 Jun 2015 11:24:57 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAB3C1A882E for ; Thu, 4 Jun 2015 11:24:57 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 628E420098; Thu, 4 Jun 2015 14:38:58 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 943AA63AE8; Thu, 4 Jun 2015 14:24:56 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 79A3D637FE; Thu, 4 Jun 2015 14:24:56 -0400 (EDT) From: Michael Richardson To: Laurent Ciavaglia In-Reply-To: <557066F0.80902@alcatel-lucent.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC52BD@xmb-rcd-x14.cisco.com> <557066F0.80902@alcatel-lucent.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: Cc: Anima WG , "Michael Behringer \(mbehring\)" Subject: Re: [Anima] Next steps for the reference document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 04 Jun 2015 18:24:59 -0000 --=-=-= Content-Type: text/plain Laurent Ciavaglia wrote: laurent> For "constrained" AN nodes, I think they are in scope, but what laurent> is the implication for the reference model document? Do we laurent> already have some inputs/requirements (e.g. from other WGs or laurent> sources) that could enlighten how / to which extent autonomic laurent> networks / their functionalities and mechanisms shall (or not) laurent> adapt (to such constrained nodes)? I think that constrained nodes will always need be coordinated by non-constrained nodes, and to the extent that we need to be able to deal with transitivity in trust through the coordinator node, they are in scope. There are really two aspects of constrained nodes as explained by rfc7228: The nodes themselves (section 2.1) vs the network (section 2.2). So, I don't think we need to design for nodes that are as small as Class 2 devices, and I also don't think that our ACP will be a "Challenged Network" once constructed, but it could be that during the construction of the ACP, that Challenged networks will be in scope. (Imagine two BFR-routers with 100Gb/s fiber between them via a photonic switch. They have to set up the ACP that includes the photonic switch via 802.11 or 802.15.4. Once the photonic switch is configured correctly, bandwidth is plentiful, but until then...) Having said this, the role of "constrained node coordinator" may well be a responsability that the AN will need to find. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVXCX+ICLcPvd0N1lAQKRsggApk7m0SkFFtfUww/l/J2BIY8eOhE56IFF sYHuEzHNHYI4EtLCgcJJxgutTMe1MsWw532liS8EhaFpd5zuW34kHD+WP/9J8Hkr 36a+934JLWtCWugaTW3+q+BJK0xbQD6WvSWlmpP13BbU+EAbfPR4EOQiik3RKeRw gG5W2OBM1BnR0uao6CnmODcXjNrDjByknBiyuVNZkEBRcbQfdc0pAN34OiJw7R2J NN1H7DPiK4yt13Nx1U/MGuSk2rPoeIcW89eBbTGXLpzZ+xMNaOFuBIAuK87PNE/5 VqsY+cdmgiAD0yVB2iKGl1wHXbhd49ryKHhEtXhlxGBIO9smsngQXQ== =rRsd -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 4 13:14:20 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D521A90EC for ; Thu, 4 Jun 2015 13:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ki56_zsxTV8U for ; Thu, 4 Jun 2015 13:14:15 -0700 (PDT) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) (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 265FD1A90E5 for ; Thu, 4 Jun 2015 13:14:15 -0700 (PDT) Received: by qgfa63 with SMTP id a63so21406485qgf.0 for ; Thu, 04 Jun 2015 13:14:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=fuw1QV1JSfEm3FnY2EKs+8ghFeapkLJDs8UiTi+aVcw=; b=SdQ++cqc7vuwqcAf3w2+YSdfXAomMPyOpYAezjyyxu27O97MV4Mlz2MImlHIvvswEv 09viSRJ2pJT2CgEKw85QzAgMizxDnaeMPS9Y6sC4qM+7AbDhEzBOQdU9eiRNMR7aOEoU nKD3EGTrZkQpO/fDdBKxYFViwK3r6dviWEDMACCm4MEZFVuvZy6BORGRul6vAt3A58E4 D61SfB/y3QKQ5kbQg9RL0GYj/IdZNO/ciaMKYVqOdEESK8/DnUFU0aemrSuNH+883gcv A9glyC9Jj3keX0BsO0OHInHixQe9dzJuxLfRCvl+nhj8UCyPG2n7jk3w2BvwhKIFujQB C0eQ== X-Received: by 10.140.235.19 with SMTP id g19mr46953459qhc.52.1433448854329; Thu, 04 Jun 2015 13:14:14 -0700 (PDT) MIME-Version: 1.0 References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC52BD@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC52BD@xmb-rcd-x14.cisco.com> From: =?UTF-8?Q?J=C3=A9ferson_Campos_Nobre?= Date: Thu, 04 Jun 2015 20:14:03 +0000 Message-ID: To: "Michael Behringer (mbehring)" , Anima WG Content-Type: multipart/alternative; boundary=001a11376dacc439fd0517b6d16a Archived-At: Subject: Re: [Anima] Next steps for the reference document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 04 Jun 2015 20:14:17 -0000 --001a11376dacc439fd0517b6d16a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Michael. I am willing to contribute with intent, conflict resolution, and management topics. J=C3=A9ferson Em qui, 4 de jun de 2015 =C3=A0s 10:18, Michael Behringer (mbehring) < mbehring@cisco.com> escreveu: > Thanks for all who volunteered to participate in the reference doc. While > detailed discussions may be between the contributors, the main technical > discussions should probably take place on the main list. Here, I summaris= e > my view on what needs to be done in the reference document. > > If someone thinks he/she can produce text for the respective sections, > please let me / the list know. > > The overall goal is to show how all the various drafts, protocols, and > discussions in the ANIMA WG fit together. > > Points to address: > > - We should have a short section on intent. Explaining ingest of > intent, distribution, the nature (on top of what's in RFC7575). That inte= nt > is signed, time stamps, etc. Probably pointing back to RFC7575. (Note > intent distribution is handled in section 7.3) > - Do we want to address "constrained" AN nodes, with limited > capabilities, here? I think so... We'll need that for AN in constrained > environments. This could go into a new section in section 3: "constrained > network elements". > - The masa section needs to be written. The masa will be an optiona= l > element. Needs to point to the bootstrap draft, which explains the basics= . > - Naming section needs meat. What names are used for, where it is i= n > the domain cert. > - Addressing section needs to bring in recent discussions. Needs to > include how an ASA uses addressing. per node or per ASA. (I think we > concluded per node). > - Domain certificate template. We should write a section on the AN > domain certificate. How the various fields are used. > - Need to explain sub-domains > - Section 9 needs to be worked out. This is all about conflict > resolution. Maybe we should re-name that section? RFC 7575 already mentio= ns > this. Maybe we don't need much more here. > - trust management: inside a domain, between domain and sub-domain, > and between domains. This should become a new section. > - Need to treat the question of the "out of band" ACP versus the > inline ACP. The two models both work, but there are implications, differe= nt > benefits, drawbacks, etc. This needs to be explained. > - Routing: In the case of a virtually separate ACP, as in > draft-behringer-anima-autonomic-control-plane, we need to also define a > routing protocol (thinking of the discussion in homenet, this might be > "fun"...) > - Need considerations for APIs: How can ASAs use the ANI? > - Need considerations for a data model. What it should cover, scope= . > - We should also describe the management angle > - Security considerations need to be expanded. Threat analysis need= s > work; need general security considerations, talk about the PKI and trust > model, etc. > > Thoughts? Anything missing? Any volunteer for a specific part? > > Michael > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > --001a11376dacc439fd0517b6d16a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Michael.
I am willing to contribute with intent, co= nflict resolution, and management topics.
J=C3=A9ferson

=
Em qui, 4 de jun de 2015 =C3=A0= s 10:18, Michael Behringer (mbehring) <mbehring@cisco.com> escreveu:
Thanks for all who volunteered to participate in the reference doc. = While detailed discussions may be between the contributors, the main techni= cal discussions should probably take place on the main list. Here, I summar= ise my view on what needs to be done in the reference document.

If someone thinks he/she can produce text for the respective sections, plea= se let me / the list know.

The overall goal is to show how all the various drafts, protocols, and disc= ussions in the ANIMA WG fit together.

Points to address:

-=C2=A0 =C2=A0 =C2=A0 =C2=A0We should have a short section on intent. Expla= ining ingest of intent, distribution, the nature (on top of what's in R= FC7575). That intent is signed, time stamps, etc. Probably pointing back to= RFC7575. (Note intent distribution is handled in section 7.3)
-=C2=A0 =C2=A0 =C2=A0 =C2=A0Do we want to address "constrained" A= N nodes, with limited capabilities, here? I think so... We'll need that= for AN in constrained environments. This could go into a new section in se= ction 3: "constrained network elements".
-=C2=A0 =C2=A0 =C2=A0 =C2=A0The masa section needs to be written. The masa = will be an optional element. Needs to point to the bootstrap draft, which e= xplains the basics.
-=C2=A0 =C2=A0 =C2=A0 =C2=A0Naming section needs meat. What names are used = for, where it is in the domain cert.
-=C2=A0 =C2=A0 =C2=A0 =C2=A0Addressing section needs to bring in recent dis= cussions. Needs to include how an ASA uses addressing. per node or per ASA.= (I think we concluded per node).
-=C2=A0 =C2=A0 =C2=A0 =C2=A0Domain certificate template. We should write a = section on the AN domain certificate. How the various fields are used.
-=C2=A0 =C2=A0 =C2=A0 =C2=A0Need to explain sub-domains
-=C2=A0 =C2=A0 =C2=A0 =C2=A0Section 9 needs to be worked out. This is all a= bout conflict resolution. Maybe we should re-name that section? RFC 7575 al= ready mentions this. Maybe we don't need much more here.
-=C2=A0 =C2=A0 =C2=A0 =C2=A0trust management: inside a domain, between doma= in and sub-domain, and between domains. This should become a new section. -=C2=A0 =C2=A0 =C2=A0 =C2=A0Need to treat the question of the "out of = band" ACP versus the inline ACP. The two models both work, but there a= re implications, different benefits, drawbacks, etc. This needs to be expla= ined.
-=C2=A0 =C2=A0 =C2=A0 =C2=A0Routing: In the case of a virtually separate AC= P, as in draft-behringer-anima-autonomic-control-plane, we need to also def= ine a routing protocol (thinking of the discussion in homenet, this might b= e "fun"...)
-=C2=A0 =C2=A0 =C2=A0 =C2=A0Need considerations for APIs: How can ASAs use = the ANI?
-=C2=A0 =C2=A0 =C2=A0 =C2=A0Need considerations for a data model. What it s= hould cover, scope.
-=C2=A0 =C2=A0 =C2=A0 =C2=A0We should also describe the management angle -=C2=A0 =C2=A0 =C2=A0 =C2=A0Security considerations need to be expanded. Th= reat analysis needs work; need general security considerations, talk about = the PKI and trust model, etc.

Thoughts? Anything missing? Any volunteer for a specific part?

Michael

_______________________________________________
Anima mailing list
Anima@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/anima
--001a11376dacc439fd0517b6d16a-- From nobody Thu Jun 4 13:20:16 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A471A912F for ; Thu, 4 Jun 2015 13:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.696 X-Spam-Level: X-Spam-Status: No, score=-0.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkh5EeiUzwIP for ; Thu, 4 Jun 2015 13:20:10 -0700 (PDT) Received: from mail-qk0-f179.google.com (mail-qk0-f179.google.com [209.85.220.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C9531A910B for ; Thu, 4 Jun 2015 13:20:10 -0700 (PDT) Received: by qkoo18 with SMTP id o18so30169048qko.1 for ; Thu, 04 Jun 2015 13:20:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=P9Mxsd9CkYGnfl3NfsMWMYu57hGPyScyZ9cpKwx7w0M=; b=aIbXLxBabIVdHRzqLpJLxjmUvSb0UFzSj100nThOXQvYPcoHRIeSfrxj+51xV0vmVF 0REa5DVkCwYOK9lTuWPA/siKVhXLbRZ7h9LW18LgUOHPRbAxjzBTNvH1F6SLq8QZrj0c ix9oAHv8rDXJDV5ujtJb+GOG/9a3aZwutwzcauddwGw7t8aBBDBQ3AnoQ+uJbEogvV5h EOeigxkl19X6muvLT2mGhYz5FyqJJ1hQMV+sv43Q8DmTqOhYcyTIK3O+NbY+ex5suB2q V9t4JkNET0ugILSwp3zI6A8xAMDlzaamvAt+7dCddAjrM3ZTD+0gJJ9MgfWFbOgE1JRO NuQg== X-Received: by 10.140.145.209 with SMTP id 200mr47882552qhr.45.1433449209450; Thu, 04 Jun 2015 13:20:09 -0700 (PDT) MIME-Version: 1.0 References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC52BD@xmb-rcd-x14.cisco.com> <557066F0.80902@alcatel-lucent.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC5803@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC5803@xmb-rcd-x14.cisco.com> From: =?UTF-8?Q?J=C3=A9ferson_Campos_Nobre?= Date: Thu, 04 Jun 2015 20:19:59 +0000 Message-ID: To: "Michael Behringer (mbehring)" , Laurent Ciavaglia , Anima WG Content-Type: multipart/alternative; boundary=001a113562e0eed5fb0517b6e6a5 Archived-At: Subject: Re: [Anima] Next steps for the reference document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 04 Jun 2015 20:20:13 -0000 --001a113562e0eed5fb0517b6e6a5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Inline Em qui, 4 de jun de 2015 =C3=A0s 12:59, Michael Behringer (mbehring) < mbehring@cisco.com> escreveu: > inline=E2=80=A6 > > *From:* Laurent Ciavaglia [mailto:Laurent.Ciavaglia@alcatel-lucent.com] > *Sent:* 04 June 2015 16:56 > *To:* Michael Behringer (mbehring); Anima WG > *Subject:* Re: [Anima] Next steps for the reference document > > > > Hi Michael, > > Thanks for rounding the todo / issue list. > > I am ok to contribute on the intent and section 8 - "coordination / > conflict resolution" (as per draft-behringer-anima-reference-model-01), a= nd > section 9 - "Hybrid Approach with Non-Autonomic Functions". > > MB: Thanks for volunteering! > > For "constrained" AN nodes, I think they are in scope, but what is the > implication for the reference model document? Do we already have some > inputs/requirements (e.g. from other WGs or sources) that could enlighten > how / to which extent autonomic networks / their functionalities and > mechanisms shall (or not) adapt (to such constrained nodes)? > > MB: I think we need to work out what is the minimum =E2=80=9Cuseful=E2=80= =9D autonomic > node, and specify what the requirements for those are. Personally I do no= t > think we want to make every smallest sensor fully autonomic. I see three > classes: > > 1) fully AN capable (what we describe today) > > 2) constrained AN capable: This will be a node that for example can > be an edge, can use AN functions, but doesn=E2=80=99t participate in many > functions, only has stub functionality. > > 3) non AN capable (according to our definitions here): Those can > still implement something =E2=80=9Cautonomic=E2=80=9D in their own unders= tanding of the > world, but it may or may not work with what we=E2=80=99re doing here. > > We need to consider nodes in 1) and 2). For 3) I would argue we=E2=80=99d= require > some gateway between two different models. None of this is set in stone, > it=E2=80=99s just my current thinking. > > > I am not quite sure what you meant by the "management angle"... I assume > you are talking about the management/operations of the whole system (as i= f > deployed by e.g. a network operator). if correct, then I think some aspec= ts > of lifecycle / phases/ operations should be considered / written in the > document. I can contribute to this but would prefer to start with some > group discussions to see if we agree on the scope first. > > MB: Yes, that=E2=80=99s what I had in mind. Thanks for volunteering. J > (J=C3=A9ferson) I think it is also important to define/describe the managem= ent interfaces supported by the ASAs and other ANIMA components. > > > A tricky (missing) part might be the relationships among the various > component. If judged useful (I think it is especially for ANIMA > "outsiders"), it could be in the form of a diagram and/or linked to the > (TBC) lifecycle section. > Of course, we shall not seek a ultimate, absolute reference diagram, but > at least proposing one can help understanding, as you wrote: "show how al= l > the various drafts, protocols, and discussions in the ANIMA WG fit > together". > > MB: Yes, we should have such a diagram. Or diagram(s). > > Thanks Laurent! > > Michael > > Thanks, best regards, Laurent. > > On 04/06/2015 15:18, Michael Behringer (mbehring) wrote: > > Thanks for all who volunteered to participate in the reference doc. While= detailed discussions may be between the contributors, the main technical d= iscussions should probably take place on the main list. Here, I summarise m= y view on what needs to be done in the reference document. > > > > If someone thinks he/she can produce text for the respective sections, pl= ease let me / the list know. > > > > The overall goal is to show how all the various drafts, protocols, and di= scussions in the ANIMA WG fit together. > > > > Points to address: > > > > - We should have a short section on intent. Explaining ingest of in= tent, distribution, the nature (on top of what's in RFC7575). That intent i= s signed, time stamps, etc. Probably pointing back to RFC7575. (Note intent= distribution is handled in section 7.3) > > - Do we want to address "constrained" AN nodes, with limited capabi= lities, here? I think so... We'll need that for AN in constrained environme= nts. This could go into a new section in section 3: "constrained network el= ements". > > - The masa section needs to be written. The masa will be an optiona= l element. Needs to point to the bootstrap draft, which explains the basics= . > > - Naming section needs meat. What names are used for, where it is i= n the domain cert. > > - Addressing section needs to bring in recent discussions. Needs to= include how an ASA uses addressing. per node or per ASA. (I think we concl= uded per node). > > - Domain certificate template. We should write a section on the AN = domain certificate. How the various fields are used. > > - Need to explain sub-domains > > - Section 9 needs to be worked out. This is all about conflict reso= lution. Maybe we should re-name that section? RFC 7575 already mentions thi= s. Maybe we don't need much more here. > > - trust management: inside a domain, between domain and sub-domain,= and between domains. This should become a new section. > > - Need to treat the question of the "out of band" ACP versus the in= line ACP. The two models both work, but there are implications, different b= enefits, drawbacks, etc. This needs to be explained. > > - Routing: In the case of a virtually separate ACP, as in draft-beh= ringer-anima-autonomic-control-plane, we need to also define a routing prot= ocol (thinking of the discussion in homenet, this might be "fun"...) > > - Need considerations for APIs: How can ASAs use the ANI? > > - Need considerations for a data model. What it should cover, scope= . > > - We should also describe the management angle > > - Security considerations need to be expanded. Threat analysis need= s work; need general security considerations, talk about the PKI and trust = model, etc. > > > > Thoughts? Anything missing? Any volunteer for a specific part? > > > > Michael > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > > > > > > > -- > > Bien cordialement, Best regards, > > > > *Laurent Ciavaglia* > > Secure Cloud Networking > > Bell Labs | Alcatel Lucent > > > > phone: +33 160 402 636 > > email: laurent.ciavaglia@alcatel-lucent.com > > linkedin: laurentciavaglia > > address: Route de Villejust | 91620 Nozay | France > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > --001a113562e0eed5fb0517b6e6a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Inline

= Em qui, 4 de jun de 2015 =C3=A0s 12:59, Michael Behringer (mbehring) <mbehring@cisco.com> escreveu:

= inline=E2= =80=A6

From: Laurent Ciavaglia [mailto:Laurent.Ciavaglia@alcatel-lucent.com]
Sent: 04 June 2015 16:56
To: Michael Behringer (mbehr= ing); Anima WG
Subject: Re: [Anima] Next st= eps for the reference document

= =C2=A0

Hi Michael,=

Thanks for rounding the todo / issue list.

I am ok to contribute on the intent and section 8 - "coordination / co= nflict resolution" (as per draft-behringer-anima-reference-model-01), = and section 9 - "Hybrid Approach with Non-Autonomic Functions".

MB: Thanks for volunteering!

For "c= onstrained" AN nodes, I think they are in scope, but what is the impli= cation for the reference model document? Do we already have some inputs/requireme= nts (e.g. from other WGs or sources) that could enlighten how / to which ex= tent autonomic networks / their functionalities and mechanisms shall (or no= t) adapt (to such constrained nodes)?

MB: I think we need to work out= what is the minimum =E2=80=9Cuseful=E2=80=9D autonomic node, and specify w= hat the requirements for those are. Personally I do not think we want to make every smallest se= nsor fully autonomic. I see three classes:

1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 fully AN capable (what we describe today)

2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 constrained AN capable: This will be a node that for e= xample can be an edge, can use AN functions, but doesn=E2=80=99t participat= e in many functions, only has stub functionality.

3)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 non AN capable (according to our definitions here): Th= ose can still implement something =E2=80=9Cautonomic=E2=80=9D in their own = understanding of the world, but it may or may not work with what we=E2=80=99re doing here.

We need to consider nodes in 1) and 2). For 3) I would argue we=E2=80=99d require some gateway between two different models. None of th= is is set in stone, it=E2=80=99s just my current thinking.


I am not quite sure what you meant by the "management angle"... I= assume you are talking about the management/operations of the whole system= (as if deployed by e.g. a network operator). if correct, then I think some= aspects of lifecycle / phases/ operations should be considered / written in the document. I can contribute to this b= ut would prefer to start with some group discussions to see if we agree on = the scope first.=

MB: Yes, that=E2=80=99s what I = had in mind. Thanks for volunteering. J

(J=C3=A9ferson) I thi= nk it is also important to define/describe the management interfaces suppor= ted by the ASAs and other ANIMA components.=C2=A0



A tricky (missing) part might be the relationships among the various compon= ent. If judged useful (I think it is especially for ANIMA "outsiders&q= uot;), it could be in the form of a diagram and/or linked to the (TBC) life= cycle section.
Of course, we shall not seek a ultimate, absolute reference diagram, but at= least proposing one can help understanding, as you wrote: "show how a= ll the various drafts, protocols, and discussions in the ANIMA WG fit toget= her".

MB: Yes, we should have such a diagram. Or diagram(s).

Thanks Laurent!

Michael

Thanks, best regards, Laurent.

=

On 04/06/2015 15:18, Michael Behringer (mbehring) = wrote:

Thanks for all who volunteered to parti=
cipate in the reference doc. While detailed discussions may be between the =
contributors, the main technical discussions should probably take place on =
the main list. Here, I summarise my view on what needs to be done in the re=
ference document. 
=C2=A0

If someone thinks he/she can produce te=
xt for the respective sections, please let me / the list know. 


=C2=A0

The overall goal is to show how all the=
 various drafts, protocols, and discussions in the ANIMA WG fit together.


=C2=A0

Points to address: 


=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 W=
e should have a short section on intent. Explaining ingest of intent, distr=
ibution, the nature (on top of what's in RFC7575). That intent is signe=
d, time stamps, etc. Probably pointing back to RFC7575. (Note intent distri=
bution is handled in section 7.3)


-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 D=
o we want to address "constrained" AN nodes, with limited capabil=
ities, here? I think so... We'll need that for AN in constrained enviro=
nments. This could go into a new section in section 3: "constrained ne=
twork elements". 


-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 T=
he masa section needs to be written. The masa will be an optional element. =
Needs to point to the bootstrap draft, which explains the basics. 


-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 N=
aming section needs meat. What names are used for, where it is in the domai=
n cert. 


-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A=
ddressing section needs to bring in recent discussions. Needs to include ho=
w an ASA uses addressing. per node or per ASA. (I think we concluded per no=
de). 


-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 D=
omain certificate template. We should write a section on the AN domain cert=
ificate. How the various fields are used. 

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 N=
eed to explain sub-domains


-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 S=
ection 9 needs to be worked out. This is all about conflict resolution. May=
be we should re-name that section? RFC 7575 already mentions this. Maybe we=
 don't need much more here. 


-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 t=
rust management: inside a domain, between domain and sub-domain, and betwee=
n domains. This should become a new section. 

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 N=
eed to treat the question of the "out of band" ACP versus the inl=
ine ACP. The two models both work, but there are implications, different be=
nefits, drawbacks, etc. This needs to be explained. 


-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 R=
outing: In the case of a virtually separate ACP, as in draft-behringer-anim=
a-autonomic-control-plane, we need to also define a routing protocol (think=
ing of the discussion in homenet, this might be "fun"...) =



-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 N=
eed considerations for APIs: How can ASAs use the ANI? 


-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 N=
eed considerations for a data model. What it should cover, scope. 
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 We should also describe the management angle
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 S=
ecurity considerations need to be expanded. Threat analysis needs work; nee=
d general security considerations, talk about the PKI and trust model, etc.=
 
=C2=A0

Thoughts? Anything missing? Any volunte=
er for a specific part? 


=C2=A0

Michael

=C2=A0

_______________________________________=
________


Anima mailing list=



Anima@ietf.org


https://www.ietf.org/mailman/listinfo/an=
ima


=C2=A0

=C2=A0

= =C2=A0

--

=

Bien cordialement, Best regards,

=C2=A0

Laurent Ciavaglia=

Secure Cloud Networking

Bell Labs | Alcatel Lucent=

=C2=A0

phone: +33=C2=A0160 402=C2=A0636

email: = laurent.ciavaglia@alcatel-lucent.com

linkedin: = laurentciavaglia

address: Route de Villejust | 91620 Nozay | France<= u>

_______________________________________________
Anima mailing list
Anima@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/anima
--001a113562e0eed5fb0517b6e6a5-- From nobody Thu Jun 4 15:40:38 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CEBB1A8957 for ; Thu, 4 Jun 2015 15:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUjoX5Gt300B for ; Thu, 4 Jun 2015 15:40:34 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 959701A8860 for ; Thu, 4 Jun 2015 15:40:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4984; q=dns/txt; s=iport; t=1433457636; x=1434667236; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=G3/B5+nqhWKda6IhGoVxATYQqnI9sf2ZavqtxEPwws8=; b=ROyk2tn+LGekiuqb7/rWdbtFPHZi0owFPYly1KeJ+anmKkoIRhLLRfTk +BZ61URH3/juRnianUtOIZ/gvtDLzul9YsfrqZWz41kNr/FFoLzowlO4X +hiv+X6LYafWisDOvCssZgNs9KcJIoT3rF3HlcPLzQ6eYDhcja5SQK6oy s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ApBADm0nBV/4wNJK1bgxBUXgaDGLs0CYFRCoV3HoETOBQBAQEBAQEBgQqEIwEBBAEBASAROhkEAQgaAiYCBBkMCxUSBAESiC0Nt0KkGgEBAQEBAQEBAQEBAQEBAQEBAQEBARcEgR2KIoQiAQoHAR4RB4MKL4EWBYtchz6LJIEvg3WSLCSDd28BgQIJFyOBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,554,1427760000"; d="scan'208";a="912738" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-4.cisco.com with ESMTP; 04 Jun 2015 22:40:35 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t54MeX6r028488 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 4 Jun 2015 22:40:33 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.5]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Thu, 4 Jun 2015 17:40:33 -0500 From: "Jason Coleman (colemaj)" To: "Michael Behringer (mbehring)" , Anima WG Thread-Topic: [Anima] Next steps for the reference document Thread-Index: AQHQnxd3oO1vHkFQQ5yr85+CL+laOw== Date: Thu, 4 Jun 2015 22:40:32 +0000 Message-ID: <4ABF0A06-CF14-45F8-B1D5-94A0BAA50845@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.8.0.150303 x-originating-ip: [10.89.7.223] Content-Type: text/plain; charset="utf-8" Content-ID: <2BB744E0E71CD944B62401F2777ADF7B@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Next steps for the reference document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 04 Jun 2015 22:40:36 -0000 SSB3b3VsZCBsaWtlIHRvIGhlbHAgd2l0aCB0aGUgZm9sbG93aW5nIGFyZWFzOg0KDQpNYW5hZ2Vt ZW50LCBEb21haW4vU3ViIERvbWFpbiwgYW5kIE91dC1vZi1iYW5kIGFuZCBpbmxpbmUgQUNQDQoN Ci0tIA0KSmFzb24gQ29sZW1hbiBDQ0lFIzEyMDY5DQpqbWNvbGVtYW5AY2lzY28uY29tDQpwaG9u ZTogKzEgNTEyLTM0MC0zMTM0VGVjaG5pY2FsIExlYWQgRW5naW5lZXIgQ01TDQoNCg0KVGhpcyBl bWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9y IHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LiBBbnkgcmV2aWV3LCB1c2Us IGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJp dGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IChvciBhdXRob3JpemVk IHRvIHJlY2VpdmUgZm9yIHRoZSByZWNpcGllbnQpLCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVy IGJ5IHJlcGx5IGVtYWlsIGFuZCBkZWxldGUgYWxsIGNvcGllcyBvZiB0aGlzIG1lc3NhZ2UuDQpG b3IgY29ycG9yYXRlIGxlZ2FsIGluZm9ybWF0aW9uIGdvIHRvOg0KaHR0cDovL3d3dy5jaXNjby5j b20vd2ViL2Fib3V0L2RvaW5nX2J1c2luZXNzL2xlZ2FsL2NyaS9pbmRleC5odG1sDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KT24gNi80LzE1LCA4OjE4IEFNLCAiTWljaGFlbCBCZWhyaW5nZXIgKG1i ZWhyaW5nKSIgPG1iZWhyaW5nQGNpc2NvLmNvbT4gd3JvdGU6DQoNCj5UaGFua3MgZm9yIGFsbCB3 aG8gdm9sdW50ZWVyZWQgdG8gcGFydGljaXBhdGUgaW4gdGhlIHJlZmVyZW5jZSBkb2MuIFdoaWxl IGRldGFpbGVkIGRpc2N1c3Npb25zIG1heSBiZSBiZXR3ZWVuIHRoZSBjb250cmlidXRvcnMsIHRo ZSBtYWluIHRlY2huaWNhbCBkaXNjdXNzaW9ucyBzaG91bGQgcHJvYmFibHkgdGFrZSBwbGFjZSBv biB0aGUgbWFpbiBsaXN0LiBIZXJlLCBJIHN1bW1hcmlzZSBteSB2aWV3IG9uIHdoYXQgbmVlZHMg dG8gYmUgZG9uZSBpbiB0aGUgcmVmZXJlbmNlIGRvY3VtZW50LiANCj4NCj5JZiBzb21lb25lIHRo aW5rcyBoZS9zaGUgY2FuIHByb2R1Y2UgdGV4dCBmb3IgdGhlIHJlc3BlY3RpdmUgc2VjdGlvbnMs IHBsZWFzZSBsZXQgbWUgLyB0aGUgbGlzdCBrbm93LiANCj4NCj5UaGUgb3ZlcmFsbCBnb2FsIGlz IHRvIHNob3cgaG93IGFsbCB0aGUgdmFyaW91cyBkcmFmdHMsIHByb3RvY29scywgYW5kIGRpc2N1 c3Npb25zIGluIHRoZSBBTklNQSBXRyBmaXQgdG9nZXRoZXIuDQo+DQo+UG9pbnRzIHRvIGFkZHJl c3M6IA0KPg0KPi0JV2Ugc2hvdWxkIGhhdmUgYSBzaG9ydCBzZWN0aW9uIG9uIGludGVudC4gRXhw bGFpbmluZyBpbmdlc3Qgb2YgaW50ZW50LCBkaXN0cmlidXRpb24sIHRoZSBuYXR1cmUgKG9uIHRv cCBvZiB3aGF0J3MgaW4gUkZDNzU3NSkuIFRoYXQgaW50ZW50IGlzIHNpZ25lZCwgdGltZSBzdGFt cHMsIGV0Yy4gUHJvYmFibHkgcG9pbnRpbmcgYmFjayB0byBSRkM3NTc1LiAoTm90ZSBpbnRlbnQg ZGlzdHJpYnV0aW9uIGlzIGhhbmRsZWQgaW4gc2VjdGlvbiA3LjMpDQo+LQlEbyB3ZSB3YW50IHRv IGFkZHJlc3MgImNvbnN0cmFpbmVkIiBBTiBub2Rlcywgd2l0aCBsaW1pdGVkIGNhcGFiaWxpdGll cywgaGVyZT8gSSB0aGluayBzby4uLiBXZSdsbCBuZWVkIHRoYXQgZm9yIEFOIGluIGNvbnN0cmFp bmVkIGVudmlyb25tZW50cy4gVGhpcyBjb3VsZCBnbyBpbnRvIGEgbmV3IHNlY3Rpb24gaW4gc2Vj dGlvbiAzOiAiY29uc3RyYWluZWQgbmV0d29yayBlbGVtZW50cyIuIA0KPi0JVGhlIG1hc2Egc2Vj dGlvbiBuZWVkcyB0byBiZSB3cml0dGVuLiBUaGUgbWFzYSB3aWxsIGJlIGFuIG9wdGlvbmFsIGVs ZW1lbnQuIE5lZWRzIHRvIHBvaW50IHRvIHRoZSBib290c3RyYXAgZHJhZnQsIHdoaWNoIGV4cGxh aW5zIHRoZSBiYXNpY3MuIA0KPi0JTmFtaW5nIHNlY3Rpb24gbmVlZHMgbWVhdC4gV2hhdCBuYW1l cyBhcmUgdXNlZCBmb3IsIHdoZXJlIGl0IGlzIGluIHRoZSBkb21haW4gY2VydC4gDQo+LQlBZGRy ZXNzaW5nIHNlY3Rpb24gbmVlZHMgdG8gYnJpbmcgaW4gcmVjZW50IGRpc2N1c3Npb25zLiBOZWVk cyB0byBpbmNsdWRlIGhvdyBhbiBBU0EgdXNlcyBhZGRyZXNzaW5nLiBwZXIgbm9kZSBvciBwZXIg QVNBLiAoSSB0aGluayB3ZSBjb25jbHVkZWQgcGVyIG5vZGUpLiANCj4tCURvbWFpbiBjZXJ0aWZp Y2F0ZSB0ZW1wbGF0ZS4gV2Ugc2hvdWxkIHdyaXRlIGEgc2VjdGlvbiBvbiB0aGUgQU4gZG9tYWlu IGNlcnRpZmljYXRlLiBIb3cgdGhlIHZhcmlvdXMgZmllbGRzIGFyZSB1c2VkLiANCj4tCU5lZWQg dG8gZXhwbGFpbiBzdWItZG9tYWlucw0KPi0JU2VjdGlvbiA5IG5lZWRzIHRvIGJlIHdvcmtlZCBv dXQuIFRoaXMgaXMgYWxsIGFib3V0IGNvbmZsaWN0IHJlc29sdXRpb24uIE1heWJlIHdlIHNob3Vs ZCByZS1uYW1lIHRoYXQgc2VjdGlvbj8gUkZDIDc1NzUgYWxyZWFkeSBtZW50aW9ucyB0aGlzLiBN YXliZSB3ZSBkb24ndCBuZWVkIG11Y2ggbW9yZSBoZXJlLiANCj4tCXRydXN0IG1hbmFnZW1lbnQ6 IGluc2lkZSBhIGRvbWFpbiwgYmV0d2VlbiBkb21haW4gYW5kIHN1Yi1kb21haW4sIGFuZCBiZXR3 ZWVuIGRvbWFpbnMuIFRoaXMgc2hvdWxkIGJlY29tZSBhIG5ldyBzZWN0aW9uLiANCj4tCU5lZWQg dG8gdHJlYXQgdGhlIHF1ZXN0aW9uIG9mIHRoZSAib3V0IG9mIGJhbmQiIEFDUCB2ZXJzdXMgdGhl IGlubGluZSBBQ1AuIFRoZSB0d28gbW9kZWxzIGJvdGggd29yaywgYnV0IHRoZXJlIGFyZSBpbXBs aWNhdGlvbnMsIGRpZmZlcmVudCBiZW5lZml0cywgZHJhd2JhY2tzLCBldGMuIFRoaXMgbmVlZHMg dG8gYmUgZXhwbGFpbmVkLiANCj4tCVJvdXRpbmc6IEluIHRoZSBjYXNlIG9mIGEgdmlydHVhbGx5 IHNlcGFyYXRlIEFDUCwgYXMgaW4gZHJhZnQtYmVocmluZ2VyLWFuaW1hLWF1dG9ub21pYy1jb250 cm9sLXBsYW5lLCB3ZSBuZWVkIHRvIGFsc28gZGVmaW5lIGEgcm91dGluZyBwcm90b2NvbCAodGhp bmtpbmcgb2YgdGhlIGRpc2N1c3Npb24gaW4gaG9tZW5ldCwgdGhpcyBtaWdodCBiZSAiZnVuIi4u LikgDQo+LQlOZWVkIGNvbnNpZGVyYXRpb25zIGZvciBBUElzOiBIb3cgY2FuIEFTQXMgdXNlIHRo ZSBBTkk/IA0KPi0JTmVlZCBjb25zaWRlcmF0aW9ucyBmb3IgYSBkYXRhIG1vZGVsLiBXaGF0IGl0 IHNob3VsZCBjb3Zlciwgc2NvcGUuIA0KPi0JV2Ugc2hvdWxkIGFsc28gZGVzY3JpYmUgdGhlIG1h bmFnZW1lbnQgYW5nbGUNCj4tCVNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIG5lZWQgdG8gYmUgZXhw YW5kZWQuIFRocmVhdCBhbmFseXNpcyBuZWVkcyB3b3JrOyBuZWVkIGdlbmVyYWwgc2VjdXJpdHkg Y29uc2lkZXJhdGlvbnMsIHRhbGsgYWJvdXQgdGhlIFBLSSBhbmQgdHJ1c3QgbW9kZWwsIGV0Yy4g DQo+DQo+VGhvdWdodHM/IEFueXRoaW5nIG1pc3Npbmc/IEFueSB2b2x1bnRlZXIgZm9yIGEgc3Bl Y2lmaWMgcGFydD8gDQo+DQo+TWljaGFlbA0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+QW5pbWEgbWFpbGluZyBsaXN0DQo+QW5pbWFAaWV0Zi5v cmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hDQo= From nobody Thu Jun 4 19:32:10 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A050A1B29CC; Thu, 4 Jun 2015 19:32:08 -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 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 8X1QqvfBLR3T; Thu, 4 Jun 2015 19:32:07 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (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 36A321B29C8; Thu, 4 Jun 2015 19:32:07 -0700 (PDT) Received: by pdjm12 with SMTP id m12so43016944pdj.3; Thu, 04 Jun 2015 19:32:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=JAnwBi2kEs6uzBHMBC/ZNUbAxWx0KdzpGndFlgCL2wU=; b=LRc5oPCj+weIQlzBEU2bXtFzW1PyRD2hQdVgpVL1z3ESXVgFHbJJk9DkJLcpA2D5/I L48e2u5PfZgbBkhI7E8Fuv0H+7Y4twnZOlY+1+JzJBaCJhDPqonxHdamzoE0wwu2gu87 prU+A5qOtN/mmrdgbJIHyOmpSClSY+yVDwVuUrGKrDyGR9sysI1y+r78EpWPpuWO3fXN qQrECehwiSxNSIWy9OSkALPWn/Wnb9L8Wj1XkOfsrg0J5/KWBUHaM3umTDZBb254iR7O MeRWrKFjQex+3tcPtArjkyBU4gwrdLfJWbBOwYUwKRgRts4ybRnUGWEZZLZ5yiTkGWAa ZGLg== X-Received: by 10.66.66.173 with SMTP id g13mr1853670pat.155.1433471526798; Thu, 04 Jun 2015 19:32:06 -0700 (PDT) Received: from ?IPv6:2406:e007:5a73:1:28cc:dc4c:9703:6781? ([2406:e007:5a73:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id l1sm5030423pdp.71.2015.06.04.19.32.03 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jun 2015 19:32:05 -0700 (PDT) Message-ID: <55710A2B.10503@gmail.com> Date: Fri, 05 Jun 2015 14:32:11 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Michael Richardson , anima@ietf.org References: <556F8C12.7060003@gmail.com> <6996.1433437001@sandelman.ca> In-Reply-To: <6996.1433437001@sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima signaling DT Subject: Re: [Anima] [Anima-signaling] some small summary of bootstrap conversation X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 05 Jun 2015 02:32:08 -0000 Michael, Thanks much for the summary. Let me grab at some low hanging targets... On 05/06/2015 04:56, Michael Richardson wrote: ... > We started with a discussion of the charter for the DT, and how it relates to > the charter for the WG, and the result is at: > https://tools.ietf.org/wg/anima/trac/wiki/Bootstrap >> 1. Define the scope of "zero touch bootstrapping". This is critical. Anima signaling deals with the needs of Autonomic Service Agents, not with the devices that they manage in a use-case specific way. So if the scope of your effort is wider than just the devices capable of containing ASAs, the constraints may change considerably. ... > The idea that during the bootstrap process, there is a period > when the network (the ACP aka fraternity) and the new node (the peldge) check > each other out for fitness. We also need to support the case where there is no ACP, just some sort of CA, so that we can use vanilla TLS (or maybe DTLS). ... > I don't know if the ANIMA signaling protocol should occur before such a > channel is established, or inside of this (provisional) channel, or whether > it should instead run inside IKEv2 (maybe inside EAP). The current assumption is that discovery of the nearest trust relay has to take place in the clear (and that draft-pritikin may not be the only method available, going forward). That would mean one cleartext multicast and one cleartext unicast response via GDNP. If that response was forged, the bootstrap process needs to fail. Brian From nobody Thu Jun 4 19:44:05 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4FC01AC3EA for ; Thu, 4 Jun 2015 19:44:03 -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 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 lIacW5b1Hpp1 for ; Thu, 4 Jun 2015 19:44:02 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::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 494311ACAD8 for ; Thu, 4 Jun 2015 19:44:01 -0700 (PDT) Received: by payr10 with SMTP id r10so41334658pay.1 for ; Thu, 04 Jun 2015 19:44:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=A8gXcc4IYrefx4CVRqvNoC+5gFX+qhSUgGoVhgix/rg=; b=OENhfsnCWJy6Mumvf5LOMABIbE4OX6ar2OXToP8vV+m2NnoQ6jan+27J+Vz4er62hV zIsBy1afpJyWI1XfwtE/Zm53rKi8c7YXwW5CNcQCDD8PhbSMKGRuZ3PvBXfWxLaLZpIQ 6q9MEM8QbcERhr3BkMbL7JLjmUKrliD0SsCy6htFKFoak3PF+fU+gqMos9cCgAQm8XnN DovWCJnMgGwPJQzXNaWt15f0h4LnBirTieKvidOEVGxIe+jumN9rIH+ZqOIVdradsb60 mWPM2GsI4+kbuo4ja6JG3zAqu34UVhw934+I46fk1zdDsWQqadDrOnGzVHlRC/JlOZgy 8w/Q== X-Received: by 10.70.138.8 with SMTP id qm8mr2001171pdb.96.1433472241010; Thu, 04 Jun 2015 19:44:01 -0700 (PDT) Received: from ?IPv6:2406:e007:5a73:1:28cc:dc4c:9703:6781? ([2406:e007:5a73:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id om4sm5050123pdb.68.2015.06.04.19.43.57 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jun 2015 19:43:59 -0700 (PDT) Message-ID: <55710CF5.7060602@gmail.com> Date: Fri, 05 Jun 2015 14:44:05 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , Anima WG References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC52BD@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC52BD@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Next steps for the reference document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 05 Jun 2015 02:44:03 -0000 Hi, Somewhere, and I think it needs to be in this document, we should IMHO outline the minimum capabilities of a device capable of running an ASA. Just to mark out the territory with an example, I expect we're agreed that light switches won't run ASAs, whereas the lighting controller for one floor of a large building might do so (communicating with other lighting controllers, the emergency evacuation controller, and other ASAs using Anima signaling). So, a section on device capabilities would help to make this more concrete. For now, this section would probably be a placeholder. Regards Brian From nobody Thu Jun 4 21:12:01 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 434091B2A86 for ; Thu, 4 Jun 2015 21:12:00 -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 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 8EFZIPe1787s for ; Thu, 4 Jun 2015 21:11:58 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::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 BE41E1B2A78 for ; Thu, 4 Jun 2015 21:11:58 -0700 (PDT) Received: by pdjm12 with SMTP id m12so44553049pdj.3 for ; Thu, 04 Jun 2015 21:11:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=whaUoQlSYWrH+XrTZZpy5c6inmcVixxxHSHuzzV07h4=; b=Oufb+gd4Z5HT2TRp6zdmCzpUJD1u3anlW/WDhKEFAg/IuQn0sSerIvrFYQbRmcZ/Ag EookaICAx5DgMSYOOdOR8/ASez+iqhbQMOedj/N2cchOCNbm/I4qajt5fWyN2Pwodo41 rMvKh/Q4Pw6rMXy7knSTNOaI8x+6UixJgi/dnTSXLSZb+FKS6lhAXY29uWGKo+MyAXi/ Zm5MYeDU5NPnr8TvqOxgP7BnGH1Z2H7KZiwC581U3zUKnCChJ+tbiaYfFusy0wgeUaoh LQRVrLXVwCe4LZSdmuK0+r5znnXnSkCc7NQDM4xS17Z/xKRTY5Wkd2ZYOsUXeIVCwbpP M8bw== X-Received: by 10.66.222.41 with SMTP id qj9mr2471326pac.139.1433477518422; Thu, 04 Jun 2015 21:11:58 -0700 (PDT) Received: from ?IPv6:2406:e007:5a73:1:28cc:dc4c:9703:6781? ([2406:e007:5a73:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id qy7sm5157738pbb.12.2015.06.04.21.11.55 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jun 2015 21:11:57 -0700 (PDT) Message-ID: <55712193.5040507@gmail.com> Date: Fri, 05 Jun 2015 16:12:03 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Anima WG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Two questions to the WG from the Signaling Design Team X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 05 Jun 2015 04:12:00 -0000 Hi, The signaling design team has been working on requirements and issues for the Anima signaling protocol, and we have a couple of questions for the WG as a whole. Our goal is to produce a draft for WG discussion and possible adoption in July. Our part of the wiki is at http://trac.tools.ietf.org/wg/anima/trac/wiki/Signaling . Question 1: The current draft design uses a traditional binary TLV protocol (similar to the Homenet DNCP design). Extensions, including the design of the objective(s) for each new autonomic use case, will require careful low-level design and possibly IANA registration. If we want Anima to be an ongoing success, it needs to be convenient for the designers of Autonomic Service Agents to define new objectives and for programmers to express them in code, without being protocol design experts. A binary TLV design is not good from that point of view. It's been proposed to the design team that we should explore a more programmer- friendly approach. The main candidate is to represent the protocol elements in JSON, with a suitable serialization such as CBOR for actual message transmission, to avoid excessive impact on run-time efficiency and footprint. So the question to the working group is: would you prefer to see the design team pursue a JSON solution, or to stick with the current binary TLV approach? Question 2: This is a cosmetic question. The current protocol model assumes that autonomic operations will be either negotiation or synchronization between peers. As time goes on, we might want to extend this model. So should we change the protocol name from GDNP (generic discovery and negotiation) to GRASP (GeneRic Autonomic Signaling Protocol)? Regards Brian Carpenter (Anima Signaling DT editor) From nobody Fri Jun 5 01:17:26 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007011B2D80 for ; Fri, 5 Jun 2015 01:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHgxJaO-pYMR for ; Fri, 5 Jun 2015 01:17:22 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2F251B2D7D for ; Fri, 5 Jun 2015 01:17:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3376; q=dns/txt; s=iport; t=1433492240; x=1434701840; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=u9somoTkhYWyQ0AMcV2JrUQfZSiH283uAFwdnrnaz8w=; b=RGkTYcz9cWoy0+5xPkAfGqRHIe6KqgHHf8+okwlNivzKV+dVI9VgtmMc 5bCZ04N9dlYglhvGNsnIkbdKpRwmjKDxeAbm75xo0/B7VNHz3+tdo994V r5AIOObPaZ5PWlyY4g6jYpaZggVLvjLZLPOdaM6xosIU4/pRg5NHXEkLJ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AsBQCTWnFV/5JdJa1bgxCBMgaDGLpaiEECHIEXTAEBAQEBAYELhCIBAQEEIxFRBAIBCBEEAQEDAgYdAwICAh8RFAEICAEBBAESCIgQAxK3SZ5yDYUbAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhiiKCTYIIOAaCYi+BFgWTH4lIgw6PHYMwg1kkg3dvAYFFgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,557,1427760000"; d="scan'208";a="425513219" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-7.cisco.com with ESMTP; 05 Jun 2015 08:17:19 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t558HJWt004034 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Jun 2015 08:17:19 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.238]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Fri, 5 Jun 2015 03:17:19 -0500 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , Anima WG Thread-Topic: [Anima] Next steps for the reference document Thread-Index: AdCeyJnnoO1vHkFQQ5yr85+CL+laOwAmsvCAAADADAA= Date: Fri, 5 Jun 2015 08:17:18 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC616B@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC52BD@xmb-rcd-x14.cisco.com> <55710CF5.7060602@gmail.com> In-Reply-To: <55710CF5.7060602@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.141] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Next steps for the reference document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 05 Jun 2015 08:17:25 -0000 R29vZCBwb2ludCwgQnJpYW4sIG5vdGVkIGluIG15ICJ0byBkbyBsaXN0Ii4gDQoNClRoaW5raW5n IG91dCBsb3VkOiBTZWN0aW9uIDMgdGFsa3MgYWJvdXQgdmFyaW91cyBub2RlIHR5cGVzLCBhbmQg SSBzdWdnZXN0IHdlIGFsc28gYnJpbmcgaW4gY29uc3RyYWluZWQgbm9kZXMgaGVyZS4gVGhhdCB3 b3VsZCB0aGVuIGxlbmQgaXRzZWxmIG5pY2VseSB0byBhbHNvIGRpc2N1c3MgbWluaW11bSBjYXBh YmlsaXRpZXMuIA0KDQpBY3R1YWxseSwgSSBkb27igJl0IHRoaW5rIEkgYWdyZWUgd2l0aCB5b3Vy IHN0YXRlbWVudCBhYm91dCBsaWdodCBzd2l0Y2hlcyBub3QgaGF2aW5nIEFTQXMuIA0KDQpUaGUg d2F5IHRoaW5ncyBzdGFydCB0byBsb29rIGluIG15IGJyYWluOiANCi0gQ2F0ZWdvcnkgQTogZGV2 aWNlcyB0b28gc21hbGwgdG8gZG8gYW55dGhpbmcgQU4NCi0gQ2F0ZWdvcnkgQjogY29uc3RyYWlu ZWQgQU4gZGV2aWNlcywgdGhhdCBkb24ndCBoYXZlIGFsbCBmdW5jdGlvbnMuIEZvciBleGFtcGxl LCB0aGV5IG1heSBvbmx5IGhhdmUgc3R1YiByb3V0aW5nIGZ1bmN0aW9ucy4gDQotIENhdGVnb3J5 IEM6ICJmdWxsIiBBTiBub2Rlcy4gDQotIGEgbGlnaHQgc3dpdGNoIGNvdWxkIGJlIGluIGVpdGhl ciBjYXRlZ29yeSwgbGlrZWx5IEEgb3IgQiwgbm90IEMgKHB1cmUgZ3Vlc3MpLiANCi0gaWYgdGhl IGxpZ2h0IHN3aXRjaCBmYWxscyBpbnRvIEEsIGl0IGRvZXNuJ3QgaGF2ZSBhbiBBU0EsIHNpbmNl IGl0J3Mgbm90IGF1dG9ub21pYyBpbiBvdXIgZGVmaW5pdGlvbi4gDQotIGlmIGl0J3MgaW4gQiwg YW5kIEkgdGhpbmsgdGhpcyBpcyB0aGUgY2FzZSB5b3UncmUgdGFsa2luZyBhYm91dCg/KSBUSEVO IEkgdGhpbmsgaXQgYWxzbyBoYXMgYW4gQVNBIHRvIGNvbnRyb2wgdGhlIGxpZ2h0LiANCg0KVGhl IEFTQSB3aWxsIGJlIFZFUlkgc2ltcGxlOiANCi0gaWYgbWVjaGFuaWNhbCBzd2l0Y2ggZ29lcyB0 byAib2ZmIiwgc2VuZCBhIG1lc3NhZ2UgdG8gImFsbCBsaWdodHMgdW5kZXIgbXkgY29udHJvbCI6 ICJ0dXJuIE9mZiINCi0gaWYgbWVjaGFuaWNhbCBzd2l0Y2ggZ29lcyB0byAib24iLCBzZW5kIGEg bWVzc2FnZSB0byAiYWxsIGxpZ2h0cyB1bmRlciBteSBjb250cm9sIjogInR1cm4gT24iDQotIHNv bWUgd2F5IHRvIGxlYXJuIHdoaWNoIGxpZ2h0cyBhcmUgdW5kZXIgaXRzIGNvbnRyb2wsIHNvbWUg Z3JvdXBpbmcgb2Ygc29ydHMuIA0KDQpCdXQgdG8gbWUsIHRoYXQgKmlzKiBhbiBBU0EuIEl0IHVz ZXMgdGhlIEF1dG9ub21pYyBpbmZyYXN0cnVjdHVyZSwgbmFtZWx5IHRoZSBtZXNzYWdlIGJ1cy4g DQooQW5kLCBzdHJpY3RseSBzcGVha2luZywgdGhlIGVucm9sbWVudCBwcm9jZXNzIChjbGllbnQg c2lkZSkgaXMgYWxzbyBhbiBBU0EuIFdoaWNoIEkgdGhpbmsgaXMgcHJvYmFibHkgbWFuZGF0b3J5 KSANCg0KU28sIEkgdGhpbmsgaW4gcHJhY3RpY2UgRVZFUlkgZGV2aWNlIGluIGNhdGVnb3J5IEIg b3IgQyB3aWxsIGhhdmUgQVNBcywgYWxiZWl0IGluIHRoZSBzaW1wbGVzdCBjYXNlIGp1c3QgZm9y IGVucm9sbWVudC4gDQoNClRob3VnaHRzPyANCk1pY2hhZWwNCg0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IEJyaWFuIEUgQ2FycGVudGVyIFttYWlsdG86YnJpYW4uZS5j YXJwZW50ZXJAZ21haWwuY29tXQ0KPiBTZW50OiAwNSBKdW5lIDIwMTUgMDQ6NDQNCj4gVG86IE1p Y2hhZWwgQmVocmluZ2VyIChtYmVocmluZyk7IEFuaW1hIFdHDQo+IFN1YmplY3Q6IFJlOiBbQW5p bWFdIE5leHQgc3RlcHMgZm9yIHRoZSByZWZlcmVuY2UgZG9jdW1lbnQNCj4gDQo+IEhpLA0KPiAN Cj4gU29tZXdoZXJlLCBhbmQgSSB0aGluayBpdCBuZWVkcyB0byBiZSBpbiB0aGlzIGRvY3VtZW50 LCB3ZSBzaG91bGQgSU1ITw0KPiBvdXRsaW5lIHRoZSBtaW5pbXVtIGNhcGFiaWxpdGllcyBvZiBh IGRldmljZSBjYXBhYmxlIG9mIHJ1bm5pbmcgYW4gQVNBLg0KPiBKdXN0IHRvIG1hcmsgb3V0IHRo ZSB0ZXJyaXRvcnkgd2l0aCBhbiBleGFtcGxlLCBJIGV4cGVjdCB3ZSdyZSBhZ3JlZWQgdGhhdA0K PiBsaWdodCBzd2l0Y2hlcyB3b24ndCBydW4gQVNBcywgd2hlcmVhcyB0aGUgbGlnaHRpbmcgY29u dHJvbGxlciBmb3Igb25lIGZsb29yDQo+IG9mIGEgbGFyZ2UgYnVpbGRpbmcgbWlnaHQgZG8gc28g KGNvbW11bmljYXRpbmcgd2l0aCBvdGhlciBsaWdodGluZw0KPiBjb250cm9sbGVycywgdGhlIGVt ZXJnZW5jeSBldmFjdWF0aW9uIGNvbnRyb2xsZXIsIGFuZCBvdGhlciBBU0FzIHVzaW5nDQo+IEFu aW1hIHNpZ25hbGluZykuDQo+IA0KPiBTbywgYSBzZWN0aW9uIG9uIGRldmljZSBjYXBhYmlsaXRp ZXMgd291bGQgaGVscCB0byBtYWtlIHRoaXMgbW9yZSBjb25jcmV0ZS4NCj4gRm9yIG5vdywgdGhp cyBzZWN0aW9uIHdvdWxkIHByb2JhYmx5IGJlIGEgcGxhY2Vob2xkZXIuDQo+IA0KPiBSZWdhcmRz DQo+ICAgIEJyaWFuDQo= From nobody Fri Jun 5 01:21:13 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 431041B2D90 for ; Fri, 5 Jun 2015 01:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYh9VEgv_7Sh for ; Fri, 5 Jun 2015 01:21:10 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ACAC1B2D8E for ; Fri, 5 Jun 2015 01:21:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=350; q=dns/txt; s=iport; t=1433492470; x=1434702070; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=HITpMhdAxnkj8wcZ0YbvbquQUtsSvt/SltKjFzub+zg=; b=VjWyj1d+WxDaSZwOLuDO0JH216mZDniV2boVIBzGZ4MxSwz35o/QwVvn oCADdbqU0442wYBqEglyFOSKazuaXBXwgMbd5mB+7UTAQcDyftalmByxf 5GYE+SxtouWfbXS9AB6ozx+rJku7OAmsGaI2GqKvXoJVMrb6gkcQbxNOg U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A9BACTWnFV/5JdJa1bgxCBOIMYulpmCYdSAhyBFzgUAQEBAQEBAYEKhCMBAQQjEVUCAQgaAgYgAgICMBUQAQEEARqIJbdJpBoBAQEBAQEBAQEBAQEBAQEBAQEBARiBIYoihFU4gmgvgRYFkx+ifCSDd4I1gQEBAQE X-IronPort-AV: E=Sophos;i="5.13,557,1427760000"; d="scan'208";a="4743400" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-1.cisco.com with ESMTP; 05 Jun 2015 08:21:09 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t558L9Qp006334 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Jun 2015 08:21:09 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.238]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Fri, 5 Jun 2015 03:21:09 -0500 From: "Michael Behringer (mbehring)" To: =?utf-8?B?SsOpZmVyc29uIENhbXBvcyBOb2JyZQ==?= , Laurent Ciavaglia , Anima WG Thread-Topic: [Anima] Next steps for the reference document Thread-Index: AdCeyJnnoO1vHkFQQ5yr85+CL+laOwAN9cwAAAiCoYAAAtBkgAAOpgvg Date: Fri, 5 Jun 2015 08:21:08 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC618E@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC52BD@xmb-rcd-x14.cisco.com> <557066F0.80902@alcatel-lucent.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC5803@xmb-rcd-x14.cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.141] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Next steps for the reference document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 05 Jun 2015 08:21:11 -0000 IChKw6lmZXJzb24pIEkgdGhpbmsgaXQgaXMgYWxzbyBpbXBvcnRhbnQgdG8gZGVmaW5lL2Rlc2Ny aWJlIHRoZSBtYW5hZ2VtZW50IGludGVyZmFjZXMgc3VwcG9ydGVkIGJ5IHRoZSBBU0FzIGFuZCBv dGhlciBBTklNQSBjb21wb25lbnRzLsKgDQoNCkFncmVlZC4gSSBoYWQgdGhhdCBtZW50YWxseSBz dG9yZWQgaW4gdGhlIGJ1Y2tldDogDQoNCi0JV2Ugc2hvdWxkIGFsc28gZGVzY3JpYmUgdGhlIG1h bmFnZW1lbnQgYW5nbGUNCg0KTWljaGFlbA0K From nobody Fri Jun 5 01:55:27 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161481B2DF5 for ; Fri, 5 Jun 2015 01:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRvvTlWlbxvR for ; Fri, 5 Jun 2015 01:55:21 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (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 4C9381B2DF0 for ; Fri, 5 Jun 2015 01:55:21 -0700 (PDT) Received: by wgbgq6 with SMTP id gq6so51474974wgb.3 for ; Fri, 05 Jun 2015 01:55:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zKK0Psu+XD8imAhyG4WUfxZdXXhVWcT57QvRhIHfYY0=; b=bfgcHC8u9k8+t4P42vkV8XtfpmlxHwtxIa+YEwUB/ilbqP4FwuWl001nQzF+sf/aaF TSzMF9VAT5yXAJcNByQ7tInJNrYsFQRo36EVuocsOISfjetLy04S4FUUgXRetDvzsa5O yQSTi9jVq0osHmQZEeLU3MBNclVBl2sh9XbO0fhZr8r5JBlliOoFqp6YmPxVDxsg+oei mX8R/vzJka/bI29ePa2k/BXsg0oYReQW1uH+92OHJBABVfL6H7Lo2Jje4E72V+zKEQPL IiIJLFXJ4fRoaIWL7dZlxeLWFVq1nGaiqlxfL3g5msWOSmd+bIMSTBt9E78GxgPt7k2x HWxQ== MIME-Version: 1.0 X-Received: by 10.194.21.232 with SMTP id y8mr4678754wje.36.1433494520095; Fri, 05 Jun 2015 01:55:20 -0700 (PDT) Received: by 10.27.220.1 with HTTP; Fri, 5 Jun 2015 01:55:20 -0700 (PDT) In-Reply-To: <55710CF5.7060602@gmail.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC52BD@xmb-rcd-x14.cisco.com> <55710CF5.7060602@gmail.com> Date: Fri, 5 Jun 2015 01:55:20 -0700 Message-ID: From: John Strassner To: Brian E Carpenter Content-Type: multipart/alternative; boundary=047d7b5d5908a868d20517c17345 Archived-At: Cc: Anima WG , "Michael Behringer \(mbehring\)" Subject: Re: [Anima] Next steps for the reference document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 05 Jun 2015 08:55:26 -0000 --047d7b5d5908a868d20517c17345 Content-Type: text/plain; charset=UTF-8 Agreed; I would like to generalize this into a set of: - requirements to be satisfied - capabilities to be advertised - constraints to be applied I'm happy to work on this and other management sections. Also happy to work on the connection between APIs and models. best regards, John On Thu, Jun 4, 2015 at 7:44 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Hi, > > Somewhere, and I think it needs to be in this document, we should > IMHO outline the minimum capabilities of a device capable of running > an ASA. Just to mark out the territory with an example, I expect we're > agreed that light switches won't run ASAs, whereas the lighting > controller for one floor of a large building might do so (communicating > with other lighting controllers, the emergency evacuation controller, > and other ASAs using Anima signaling). > > So, a section on device capabilities would help to make this more > concrete. For now, this section would probably be a placeholder. > > Regards > Brian > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > -- regards, John --047d7b5d5908a868d20517c17345 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agreed; I would like to generalize this into a set of= :
=C2=A0=C2=A0 - requirements to be satisfied
=C2=A0=C2= =A0 - capabilities to be advertised
=C2=A0=C2=A0 - constraints to= be applied

I'm happy to work on this and othe= r management sections.
Also happy to work on the connection betwe= en APIs and models.

best regards,
John

On Thu,= Jun 4, 2015 at 7:44 PM, Brian E Carpenter <brian.e.carpenter@gm= ail.com> wrote:
Hi,

Somewhere, and I think it needs to be in this document, we should
IMHO outline the minimum capabilities of a device capable of running
an ASA. Just to mark out the territory with an example, I expect we're<= br> agreed that light switches won't run ASAs, whereas the lighting
controller for one floor of a large building might do so (communicating
with other lighting controllers, the emergency evacuation controller,
and other ASAs using Anima signaling).

So, a section on device capabilities would help to make this more
concrete. For now, this section would probably be a placeholder.

Regards
=C2=A0 =C2=A0Brian

_______________________________________________
Anima mailing list
Anima@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/anima



--
regards,
John
--047d7b5d5908a868d20517c17345-- From nobody Fri Jun 5 02:32:16 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 412861ACE71 for ; Fri, 5 Jun 2015 02:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDSpZXv3yurZ for ; Fri, 5 Jun 2015 02:32:14 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F41F71ACE3D for ; Fri, 5 Jun 2015 02:32:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2444; q=dns/txt; s=iport; t=1433496734; x=1434706334; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+nj/Axsig14PeXvg7K8GTNvNm8dWExjMmt8IyVBvoWI=; b=CdUmedWXUYJGRrt+UZV6+1gKgNPJw6oql677UCTwZUt1r/MiVgmno2ks mabTN7Sv1krS86qoemRFd9yBzQRsMNR1YAEPZt7wvhbRsfXahnUxlNbM5 Oayeih+hic3hknpq6os8YD6i1eFJPCfY6Yk3nCK/TzAXTlrYkpE5Kh/VP 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A/BAB3a3FV/40NJK1bgxCBMgaDGLpfZgmHUgIcgRk4FAEBAQEBAQGBCoQiAQEBAwEjEUUFCwIBCA4DBAEBAwIGHQMCAgIfERQBCAgBAQQBDQUIiBADCgi3SZ51DYUbAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhiiKCTYIIMQeCaC+BFgEEkx+JSIMOjx2DMINZJIIJHIFSb4FGgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,557,1427760000"; d="scan'208";a="156671075" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Jun 2015 09:30:52 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t559Umwe022716 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Jun 2015 09:30:48 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.238]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Fri, 5 Jun 2015 04:30:48 -0500 From: "Michael Behringer (mbehring)" To: John Strassner , Brian E Carpenter Thread-Topic: [Anima] Next steps for the reference document Thread-Index: AdCeyJnnoO1vHkFQQ5yr85+CL+laOwAmsvCAAAz3PAAACcDrAA== Date: Fri, 5 Jun 2015 09:30:47 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC62CA@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC52BD@xmb-rcd-x14.cisco.com> <55710CF5.7060602@gmail.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.141] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Anima WG Subject: Re: [Anima] Next steps for the reference document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 05 Jun 2015 09:32:15 -0000 PiBGcm9tOiBKb2huIFN0cmFzc25lciBbbWFpbHRvOnN0cmF6cGRqQGdtYWlsLmNvbV0gDQo+IFNl bnQ6IDA1IEp1bmUgMjAxNSAxMDo1NQ0KPiBUbzogQnJpYW4gRSBDYXJwZW50ZXINCj4gQ2M6IE1p Y2hhZWwgQmVocmluZ2VyIChtYmVocmluZyk7IEFuaW1hIFdHDQo+IFN1YmplY3Q6IFJlOiBbQW5p bWFdIE5leHQgc3RlcHMgZm9yIHRoZSByZWZlcmVuY2UgZG9jdW1lbnQNCj4NCj4gQWdyZWVkOyBJ IHdvdWxkIGxpa2UgdG8gZ2VuZXJhbGl6ZSB0aGlzIGludG8gYSBzZXQgb2Y6DQo+wqDCoCAtIHJl cXVpcmVtZW50cyB0byBiZSBzYXRpc2ZpZWQNCj7CoMKgIC0gY2FwYWJpbGl0aWVzIHRvIGJlIGFk dmVydGlzZWQNCj7CoMKgIC0gY29uc3RyYWludHMgdG8gYmUgYXBwbGllZA0KPg0KPiBJJ20gaGFw cHkgdG8gd29yayBvbiB0aGlzIGFuZCBvdGhlciBtYW5hZ2VtZW50IHNlY3Rpb25zLg0KPiBBbHNv IGhhcHB5IHRvIHdvcmsgb24gdGhlIGNvbm5lY3Rpb24gYmV0d2VlbiBBUElzIGFuZCBtb2RlbHMu DQoNCkV4Y2VsbGVudCwgdGhhbmtzIEpvaG4uIA0KDQpJJ20gdGhpbmtpbmcgaG93IHRvIHNsaWNl IGFuZCBkaWNlIHRoaXMgZG9jdW1lbnQuIFRoZSBtb3JlIEkgdGhpbmsgYWJvdXQgaXQsIHRoZSBj dXJyZW50IHN0cnVjdHVyZSBpcyBub3Qgb3B0aW1hbC4gVGhlIHJlZ2lzdHJhciBhbmQgTUFTQSBh cmUgcmVhbGx5IEFTQXMsIGFuZCBzaG91bGQgYmUgZGVhbHQgd2l0aCBpbiBhIHNlcGFyYXRlIHNl Y3Rpb24uIFRoZW4gd2UgY291bGQgcmUtZG8gc2VjdGlvbiAzIGxpa2UgdGhpczogDQoNCjMuIFRo ZSBOZXR3b3JrIEVsZW1lbnQNCi0gQ2xhc3MgMTogdW5jb25zdHJhaW5lZCBhdXRvbm9taWMgbm9k ZXMNCi0gQ2xhc3MgMjogY29uc3RyYWluZWQgYXV0b25vbWljIG5vZGVzDQotIENsYXNzIDM6IG5v bi1hdXRvbm9taWMgbm9kZXMNCg0Kd2hlcmUgZWFjaCBjbGFzcyBkZXNjcmliZXMgdGhlIG1pbmlt dW0gY2FwYWJpbGl0aWVzIChNVVNUIGltcGxlbWVudHMsIGxhdGVyIG9uKS4gDQpPbiB0aGUgY29u c3RyYWluZWQgZGV2aWNlcywgTWljaGFlbCBSaWNoYXJkc29uIHdvdWxkIGJlIGFuIGlkZWFsIGNh bmRpZGF0ZSB0byBwcm92aWRlIHNvbWUgdGV4dD8gV291bGQgeW91IHZvbHVudGVlciBNaWNoYWVs PyBJJ20gdGhpbmtpbmcgYWJvdXQgbWFwcGluZyB0aGF0IG5pY2VseSB0byB0aGUgZXhpc3Rpbmcg d29yaywgbWFraW5nIHN1cmUgaXQgYWxsIGZpdHMgdG9nZXRoZXI/IA0KDQpBbmQgd2UgdGFrZSBN QVNBIGFuZCByZWdpc3RyYXIgaW50byBhIHNlcGFyYXRlIHNlY3Rpb246DQogDQo0LiBTcGVjaWZp YyBBdXRvbm9taWMgRnVuY3Rpb25zDQotIFJlZ2lzdHJhcg0KLSBNQVNBDQoNClRvIHlvdXIgcG9p bnQgImNhcGFiaWxpdGllcyB0byBiZSBhZHZlcnRpc2VkIjogQ2FuIHlvdSBleHBhbmQgb24gdGhh dD8gSSB3b3VsZCBhc3N1bWUgdGhhdCBlYWNoIGJhc2UgbW9kZWwgaGFzICBhIG51bWJlciBvZiBj YXBhYmlsaXRpZXMgdGhhdCBhcmUgYXNzdW1lZC4gU28gYSBub2RlIHdvdWxkIHNheSAiSSdtIGNs YXNzIDEiIC0gd2hpY2ggaW5jbHVkZXMgYSB3aG9sZSBsb3Qgb2YgYmFzZSBjYXBhYmlsaXRpZXMs IHJpZ2h0PyBBbnl0aGluZyBvcHRpb25hbCBvbiB0b3AgbmVlZHMgdG8gYmUgYWR2ZXJ0aXNlZCBz ZXBhcmF0ZWx5LiBCdXQgLSB0aGF0J3Mgc2FpZCBpbiB0d28gc2VudGVuY2VzPyANCg0KVG8geW91 ciBwb2ludCAiY29uc3RyYWludHMgdG8gYmUgYXBwbGllZCIgLSBjYW4geW91IGV4cGFuZD8gDQoN Ck1JY2hhZWwNCg0KDQoNCg== From nobody Fri Jun 5 02:37:19 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3491AD34F for ; Fri, 5 Jun 2015 02:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhxYc_Im3FDi for ; Fri, 5 Jun 2015 02:37:18 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEED71AD259 for ; Fri, 5 Jun 2015 02:37:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2341; q=dns/txt; s=iport; t=1433497037; x=1434706637; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=N23K471sAGCe+HHF6bj2U5PYOsXwxYS2cbqbCZGNzoE=; b=Otn1+qQYY6/hGziVJ48t1Bnwi0JQ+IzoKCNXQVCAEODciycAKAWbkcgz /gnh/pC2M9acJDmKIVJe+5UDohHCg9XIGNdJb3/h8P7JPHTWs6+Xng5+U qqxTYxxYl+0R/CqXRvNx9aZVYOenHXVxdAFhm+kn0tTzQi8+OTQJvcq8G 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A2BADWbHFV/5pdJa1bgxCBMga9d2YJh1ICgTU4FAEBAQEBAQGBCoQiAQEBBDo/DAQCAQgRBAEBAQoUCQcyFAkIAQEEAQ0FCIgl22kBAQEBAQEBAQEBAQEBAQEBAQEBAQEXi0OENAEBHwYrBwaDEYEWAQSTH6J8JIIJHIFSb4EMOoEBAQEB X-IronPort-AV: E=Sophos;i="5.13,557,1427760000"; d="scan'208";a="156701859" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-6.cisco.com with ESMTP; 05 Jun 2015 09:37:17 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t559bHsv031716 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Jun 2015 09:37:17 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.238]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Fri, 5 Jun 2015 04:37:16 -0500 From: "Michael Behringer (mbehring)" To: Michael Richardson , Laurent Ciavaglia Thread-Topic: [Anima] Next steps for the reference document Thread-Index: AdCeyJnnoO1vHkFQQ5yr85+CL+laOwAN9cwAAAdOZQAAFS22AA== Date: Fri, 5 Jun 2015 09:37:15 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC6383@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC52BD@xmb-rcd-x14.cisco.com> <557066F0.80902@alcatel-lucent.com> <26756.1433442296@sandelman.ca> In-Reply-To: <26756.1433442296@sandelman.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.141] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Anima WG Subject: Re: [Anima] Next steps for the reference document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 05 Jun 2015 09:37:19 -0000 > -----Original Message----- > From: mcr@sandelman.ca [mailto:mcr@sandelman.ca] On Behalf Of > Michael Richardson > Sent: 04 June 2015 20:25 > To: Laurent Ciavaglia > Cc: Michael Behringer (mbehring); Anima WG > Subject: Re: [Anima] Next steps for the reference document >=20 >=20 > Laurent Ciavaglia wrote: > laurent> For "constrained" AN nodes, I think they are in scope, but w= hat > laurent> is the implication for the reference model document? Do we > laurent> already have some inputs/requirements (e.g. from other WGs o= r > laurent> sources) that could enlighten how / to which extent autonomi= c > laurent> networks / their functionalities and mechanisms shall (or no= t) > laurent> adapt (to such constrained nodes)? >=20 > I think that constrained nodes will always need be coordinated by non- > constrained nodes, and to the extent that we need to be able to deal with > transitivity in trust through the coordinator node, they are in scope. >=20 > There are really two aspects of constrained nodes as explained by rfc7228= : > The nodes themselves (section 2.1) vs the network (section 2.2). >=20 > So, I don't think we need to design for nodes that are as small as Class = 2 > devices, and I also don't think that our ACP will be a "Challenged Networ= k" > once constructed, but it could be that during the construction of the ACP= , > that Challenged networks will be in scope. >=20 > (Imagine two BFR-routers with 100Gb/s fiber between them via a photonic > switch. They have to set up the ACP that includes the photonic switch via > 802.11 or 802.15.4. Once the photonic switch is configured correctly, > bandwidth is plentiful, but until then...) >=20 > Having said this, the role of "constrained node coordinator" may well be = a > responsability that the AN will need to find. That's for sure. Also what capabilities we expect in a constrained node may= well evolve over time. But you know all the context in that space, can pro= vide us with the right references, etc - as written in the other mail - wou= ld you help us with some text on the constrained nodes?=20 Michael =20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 From nobody Fri Jun 5 02:45:48 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E26521B2B15 for ; Fri, 5 Jun 2015 02:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzmXiUcfqoDP for ; Fri, 5 Jun 2015 02:45:45 -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 CB5C11B2AF7 for ; Fri, 5 Jun 2015 02:45:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXA42910; Fri, 05 Jun 2015 09:45:41 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 5 Jun 2015 10:45:40 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.186]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Fri, 5 Jun 2015 17:45:36 +0800 From: "Liubing (Leo)" To: "Michael Behringer (mbehring)" , Anima WG Thread-Topic: Next steps for the reference document Thread-Index: AdCeyJnnoO1vHkFQQ5yr85+CL+laOwAqtfIQ Date: Fri, 5 Jun 2015 09:45:35 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45A6792330@nkgeml506-mbx.china.huawei.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC52BD@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC52BD@xmb-rcd-x14.cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] Next steps for the reference document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 05 Jun 2015 09:45:47 -0000 Hi Michael, I'm glad to work on the following items:=20 - Naming section needs meat. What names are used for, where it is in the do= main cert. - Addressing section needs to bring in recent discussions. Needs to include= how an ASA uses addressing. per node or per ASA. (I think we concluded per= node). - Need considerations for APIs: How can ASAs use the ANI? Best regards, Bing > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael > Behringer (mbehring) > Sent: Thursday, June 04, 2015 9:19 PM > To: Anima WG > Subject: [Anima] Next steps for the reference document >=20 > Thanks for all who volunteered to participate in the reference doc. While > detailed discussions may be between the contributors, the main technical > discussions should probably take place on the main list. Here, I summaris= e > my view on what needs to be done in the reference document. >=20 > If someone thinks he/she can produce text for the respective sections, > please let me / the list know. >=20 > The overall goal is to show how all the various drafts, protocols, and > discussions in the ANIMA WG fit together. >=20 > Points to address: >=20 > - We should have a short section on intent. Explaining ingest of intent, > distribution, the nature (on top of what's in RFC7575). That intent is si= gned, > time stamps, etc. Probably pointing back to RFC7575. (Note intent > distribution is handled in section 7.3) > - Do we want to address "constrained" AN nodes, with limited > capabilities, here? I think so... We'll need that for AN in constrained > environments. This could go into a new section in section 3: "constrained > network elements". > - The masa section needs to be written. The masa will be an optional > element. Needs to point to the bootstrap draft, which explains the basics= . > - Naming section needs meat. What names are used for, where it is in the > domain cert. > - Addressing section needs to bring in recent discussions. Needs to > include how an ASA uses addressing. per node or per ASA. (I think we > concluded per node). > - Domain certificate template. We should write a section on the AN > domain certificate. How the various fields are used. > - Need to explain sub-domains > - Section 9 needs to be worked out. This is all about conflict resolution= . > Maybe we should re-name that section? RFC 7575 already mentions this. > Maybe we don't need much more here. > - trust management: inside a domain, between domain and sub-domain, > and between domains. This should become a new section. > - Need to treat the question of the "out of band" ACP versus the inline > ACP. The two models both work, but there are implications, different > benefits, drawbacks, etc. This needs to be explained. > - Routing: In the case of a virtually separate ACP, as in > draft-behringer-anima-autonomic-control-plane, we need to also define a > routing protocol (thinking of the discussion in homenet, this might be > "fun"...) > - Need considerations for APIs: How can ASAs use the ANI? > - Need considerations for a data model. What it should cover, scope. > - We should also describe the management angle > - Security considerations need to be expanded. Threat analysis needs > work; need general security considerations, talk about the PKI and trust > model, etc. >=20 > Thoughts? Anything missing? Any volunteer for a specific part? >=20 > Michael >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Fri Jun 5 06:22:43 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7EA1B2F57 for ; Fri, 5 Jun 2015 06:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1D-nKcLz-Cf0 for ; Fri, 5 Jun 2015 06:22:38 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F0B81B2F4F for ; Fri, 5 Jun 2015 06:22:38 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 70A9920098 for ; Fri, 5 Jun 2015 09:36:41 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id C4BAB63AE8; Fri, 5 Jun 2015 09:22:36 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A935263AD9 for ; Fri, 5 Jun 2015 09:22:36 -0400 (EDT) From: Michael Richardson To: anima@ietf.org In-Reply-To: <55710A2B.10503@gmail.com> References: <556F8C12.7060003@gmail.com> <6996.1433437001@sandelman.ca> <55710A2B.10503@gmail.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Anima] [Anima-signaling] some small summary of bootstrap conversation X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 05 Jun 2015 13:22:40 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >>> 1. Define the scope of "zero touch bootstrapping". > This is critical. Anima signaling deals with the needs of Autonomic > Service Agents, not with the devices that they manage in a use-case > specific way. So if the scope of your effort is wider than just the > devices capable of containing ASAs, the constraints may change > considerably. Can you give me an example that you think should be out of scope? > ... >> The idea that during the bootstrap process, there is a period when the >> network (the ACP aka fraternity) and the new node (the pledge) check >> each other out for fitness. > We also need to support the case where there is no ACP, just some sort > of CA, so that we can use vanilla TLS (or maybe DTLS). I think that "CA" doesn't stand for Certificate Authority in this context, but I don't know what it stands for here. Can you give me an example? > ... >> I don't know if the ANIMA signaling protocol should occur before such >> a channel is established, or inside of this (provisional) channel, or >> whether it should instead run inside IKEv2 (maybe inside EAP). > The current assumption is that discovery of the nearest trust relay has > to take place in the clear (and that draft-pritikin may not be the only > method available, going forward). That would mean one cleartext > multicast and one cleartext unicast response via GDNP. If that response > was forged, the bootstrap process needs to fail. I'd like to split things up such that we really have: 1) discovery of peers via variety of protocols X,Y,Z 2) trial establishment of security protocol 3) ASA communication and potential establishment of ACP I see that GDNP can be used for #1 and #3. Other protocols could also be used for (1). I'd like to think of the GDNP that is used for #1 as being of a slightly different flavour than the one for #3. I think that doing so will let us more easily make progress as it will be clear that just because we define an attribute for #3, doesn't mean it's valid for #1. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVXGinICLcPvd0N1lAQKi7gf+MNeglGRjymMm3dUWJ80Lh/auR7Xcay0c PGZgf6KCFjfWemj9wl/dBiFy3miJbJukNJkdTc1GsR8kaUGVwNL47kUmJmGBlIfN NyHhsW/8+5wmZ3FuD26+eznHPiSMchtJVzazzbobq8gdpPASMS7/rkRvteDDttdC PW+JxjZ0fMRmcySZ8l+8SegQIrSX2LQQI6tXWsaEz1EEVu32xVZfaZxGXQNyaMMg /adXnpSBl2emFnQ17jqkg++MxCOSrK+gehJXxjMPNiWyXoe7qT1hMwNatAcviKEW L4ycstSCaYQkqOI1i+A4UJFGmJMl7UaKtk+7I0LHtypPZSDouruafw== =encF -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 5 06:24:50 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7003E1B2F56 for ; Fri, 5 Jun 2015 06:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z_KSbWaKH6tA for ; Fri, 5 Jun 2015 06:24:42 -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 287A11B2F70 for ; Fri, 5 Jun 2015 06:24:42 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id D302220098; Fri, 5 Jun 2015 09:38:45 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 495F763AE8; Fri, 5 Jun 2015 09:24:41 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 2F0BC63AD9; Fri, 5 Jun 2015 09:24:41 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter In-Reply-To: <55710CF5.7060602@gmail.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC52BD@xmb-rcd-x14.cisco.com> <55710CF5.7060602@gmail.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: Cc: Anima WG , "Michael Behringer \(mbehring\)" Subject: Re: [Anima] Next steps for the reference document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 05 Jun 2015 13:24:45 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > Somewhere, and I think it needs to be in this document, we should IMHO > outline the minimum capabilities of a device capable of running an > ASA. Just to mark out the territory with an example, I expect we're > agreed that light switches won't run ASAs, whereas the lighting > controller for one floor of a large building might do so (communicating > with other lighting controllers, the emergency evacuation controller, > and other ASAs using Anima signaling). > So, a section on device capabilities would help to make this more > concrete. For now, this section would probably be a placeholder. "ASA functionality is not expected to fit into a class 2 or smaller device" [RFC7228]. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVXGjGICLcPvd0N1lAQJNeAf8Cl/7c9gun/r/Cc+IJ869rHbDxtUIPu/e DxHbFYcZMwpcHIUuI53j2EnPEyDsCjl6iLk42DQb7CgYWkXpyXE5Knk0h7AcPrDz 22WqJytvzMbMAICqtJwhBYs0G/RekVcMOa3ZflgbjBali4F2o5aS0fapf8CQgcuS Yp3/hKkk3sgq4JuB+3EvRyViRD/aU5pf23ZWB/emF7jiqXV+lxWLwtZ3Znht9tcr htlHDScUMy3rnNTZJbMcHh3jIPoNmik181BkpEIsm9sdq+7G2kuwj5RpClo6aoiA 2rbcHNQdlf3QnpIrfqIGj4d2+7dwruyaaMd0C4ynebuDJOuuP5PKNA== =Ov5+ -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 5 07:29:02 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52691B3021 for ; Fri, 5 Jun 2015 07:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFIk8HAOq5_t for ; Fri, 5 Jun 2015 07:28:59 -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 848B31B301E for ; Fri, 5 Jun 2015 07:28:59 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2146E2002A for ; Fri, 5 Jun 2015 10:43:03 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 68A4A63AE8; Fri, 5 Jun 2015 10:28:58 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4E7E963AD9 for ; Fri, 5 Jun 2015 10:28:58 -0400 (EDT) From: Michael Richardson To: Anima WG In-Reply-To: <55712193.5040507@gmail.com> References: <55712193.5040507@gmail.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Anima] Two questions to the WG from the Signaling Design Team X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 05 Jun 2015 14:29:01 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > If we want Anima to be an ongoing success, it needs to be convenient > for the designers of Autonomic Service Agents to define new objectives > and for programmers to express them in code, without being protocol > design experts. I wish to clarify your words: "protocol design expert" == someone who can write IETF draft, or navigate IANA / Expert Review process. > Question 2: This is a cosmetic question. The current protocol model > assumes that autonomic operations will be either negotiation or > synchronization between peers. As time goes on, we might want to extend > this model. So should we change the protocol name from GDNP (generic > discovery and negotiation) to GRASP (GeneRic Autonomic Signaling > Protocol)? I like GRASP as a name, I don't know if I like the expanstion. I find GDNP a mouthful and hard to type (GNDP...) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVXGyKoCLcPvd0N1lAQIwPwf+IRKd1HUA9eZs1BF59RYooZM/C5P8tc9A 5pK0QyflPL5dkXaxwDrWSTKRqznG9LLpDSPLyWTDt/lZj70I2b368KBM/dGgNukK l38m+/YJUyuZD/qyrXvs1tnJ6izeFmpcES0q3O+8RaBN00K8iUDZ54MIcdAM6o5q m/es+IFsPsuQzhhkLfo5n8nX6QpND2UZ7gV4samHoB97iYcU5bUye1u4PvBzyBA7 S+b8P+nGnwUbKmKAhXtorRanJflTp69a3RbF3EjzdwZurDnAJVkqZdoqFToEi8ys LCETWHkTJm2UAxMxvuZsMM5AOZu+Jn291gNa2KmX4WIndL8cJS8CNA== =hjZM -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 5 07:55:35 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 473421B3066 for ; Fri, 5 Jun 2015 07:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMXK1sI8x3w1 for ; Fri, 5 Jun 2015 07:55:32 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACF0E1B3061 for ; Fri, 5 Jun 2015 07:55:32 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id ABC852002A for ; Fri, 5 Jun 2015 11:09:36 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id EC3C263AE8; Fri, 5 Jun 2015 10:55:31 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D298663AD9 for ; Fri, 5 Jun 2015 10:55:31 -0400 (EDT) From: Michael Richardson To: Anima WG In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC6383@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC52BD@xmb-rcd-x14.cisco.com> <557066F0.80902@alcatel-lucent.com> <26756.1433442296@sandelman.ca> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC6383@xmb-rcd-x14.cisco.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Anima] Next steps for the reference document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 05 Jun 2015 14:55:34 -0000 --=-=-= Content-Type: text/plain Michael Behringer (mbehring) wrote: laurent> For "constrained" AN nodes, I think they are in scope, but what laurent> is the implication for the reference model document? Do we laurent> already have some inputs/requirements (e.g. from other WGs or laurent> sources) that could enlighten how / to which extent autonomic laurent> networks / their functionalities and mechanisms shall (or not) laurent> adapt (to such constrained nodes)? >> I think that constrained nodes will always need be coordinated by non- >> constrained nodes, and to the extent that we need to be able to deal >> with transitivity in trust through the coordinator node, they are in >> scope. >> There are really two aspects of constrained nodes as explained by >> rfc7228: The nodes themselves (section 2.1) vs the network (section >> 2.2). >> >> So, I don't think we need to design for nodes that are as small as >> Class 2 devices, and I also don't think that our ACP will be a >> "Challenged Network" once constructed, but it could be that during the >> construction of the ACP, that Challenged networks will be in scope. >> >> (Imagine two BFR-routers with 100Gb/s fiber between them via a >> photonic switch. They have to set up the ACP that includes the >> photonic switch via 802.11 or 802.15.4. Once the photonic switch is >> configured correctly, bandwidth is plentiful, but until then...) >> >> Having said this, the role of "constrained node coordinator" may well >> be a responsability that the AN will need to find. > That's for sure. Also what capabilities we expect in a constrained node > may well evolve over time. But you know all the context in that space, > can provide us with the right references, etc - as written in the other > mail - would you help us with some text on the constrained nodes? I have read the reference model. Can we adopt this already? I suggest changing: MASA (Manufacturer Authorized Signing Authority): The MASA is a service for devices of a particular vendor. It can validate the identity of devices that are to be used in an autonomic domain, assert which device is owned by which domain, etc. to: MASA (Manufacturer Authorized Signing Authority): The MASA is an online service for devices of a particular vendor. The MASA can validate the identity of devices that are to be used in an autonomic domain. It can provide assertions as to the owner of a particular device. The name/location of the MASA is built-in to the device at the Factory. section 3.4: Constrained Nodes Autonomic Service Agents are not expected to run or fit into class 2 or smaller constrained nodes (see RFC7228). If there are constrained nodes that need to be involved in the Autonomic Control Plane, it is assumed that they do so with the aid of a designated non-constrained node. (Finding and electing an constrained-node helper is itself an autonomic function) Constrained nodes do need to be able to join the network, and the trust infrastructure (section 6) is expected to provide a transitive trust mechanism such that constrained nodes can be helped in a secure way. section 3.5: Challenged networks In comparison to the production network (which may not yet be operational), the Autonomic Control Plane could be considered constrained. The bandwidth differences may be on the order of a 1000x or more (100Gb/s production networks compared to ACP bandwidths between 1Mb/s and 10Mb/s). The resulting ACP is considered slow, but should not in general be considered challenged as defined by RFC7228. As such, the ACP should significantly depreference LLNs and other limited energy networks, but use of such networks during the bootstrap of the ACP is in scope. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVXG4Y4CLcPvd0N1lAQKlNggAtaUz6IWHujT1ogIHss+VnscgNbXzYHc+ 4HpuC2z/RxTdzGd0xEFu4WwSbKxduohb4PkXP2OLnbfNP3YhDKFXqDIj4V1sACEz APKWoOt8WToZ5AI549UnWW3LWMB8ulfCQ4Y6qdJuIxp487rTKcYLc+9plBFW64KK wRpEH/u6wS9aYcE6JWh+8+11SCpyBIld3+tEZ4Uhh3+FUcKtV3UWNWJNjDkxlQsp g0qUuwSquIzgpnJ2ESzGOCj/pio5VcbzNAE5xrK46JRSoCw5Bl5F+wgIZXmSNt0G o17N62iT1IYiPgYMiRp4EJzW3XHe3V8x5jopI/dNtq7eU2AdrODCEw== =Naa3 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 5 13:41:17 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFC651B31F1 for ; Fri, 5 Jun 2015 13:41:15 -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 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 BmQEXfkl8TOS for ; Fri, 5 Jun 2015 13:41:14 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::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 150281B31E9 for ; Fri, 5 Jun 2015 13:41:14 -0700 (PDT) Received: by pdjm12 with SMTP id m12so60130160pdj.3 for ; Fri, 05 Jun 2015 13:41:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jJMPynaA4nt4MxZYhsqv9RVWwhAxoMon9OmGvYwXCCU=; b=t+AJg8awOspMxlVA8+3R2nVLYhWWoeRg7pfz4KH+/OXHVw6wXgffeQcDm0bLqWDHrH YStVj/xpLT1KC27OtMoqWxqFh/Ij30slRhuvYswHUM9RnUeQsWu7c8Atu/ALYJVU4Gag okYJ79YkADTjWxNKWE+PXGvQAPFe+a1pZoYIJmWG4HsnG5TxaAjmTMKMncBM+rx78MwF x5iVQR2dOylkTHCJrRTXR8wHi9X8fTTgmtIJuHfflkZz5E7m7m/cfQDPoL4AZcM8d+zk Nk8dPIn7QvM3brSauwWxd3sSj1b3LNEZiN7indXFMibQ0TH09v3Vm5v6EixxlV3QkoVi Y4Gg== X-Received: by 10.66.182.229 with SMTP id eh5mr8828548pac.18.1433536873606; Fri, 05 Jun 2015 13:41:13 -0700 (PDT) Received: from ?IPv6:2406:e007:6f63:1:28cc:dc4c:9703:6781? ([2406:e007:6f63:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id je4sm7572413pbb.17.2015.06.05.13.41.10 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jun 2015 13:41:12 -0700 (PDT) Message-ID: <5572096F.9060001@gmail.com> Date: Sat, 06 Jun 2015 08:41:19 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: anima@ietf.org References: <556F8C12.7060003@gmail.com> <6996.1433437001@sandelman.ca> <55710A2B.10503@gmail.com> <12379.1433510556@sandelman.ca> In-Reply-To: <12379.1433510556@sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] [Anima-signaling] some small summary of bootstrap conversation X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 05 Jun 2015 20:41:15 -0000 On 06/06/2015 01:22, Michael Richardson wrote: > > Brian E Carpenter wrote: > >>> 1. Define the scope of "zero touch bootstrapping". > > > This is critical. Anima signaling deals with the needs of Autonomic > > Service Agents, not with the devices that they manage in a use-case > > specific way. So if the scope of your effort is wider than just the > > devices capable of containing ASAs, the constraints may change > > considerably. > > Can you give me an example that you think should be out of scope? Well, I'm not sure I have an opinion about that yet. I mean, sticking to the building services scenario, I definitely want all the lighting controls to be trustworthy and authorized. So in that view, the scope is "everything". But I don't expect each light switch to run GDNP. If you set your scope to "everything" then that excludes GDNP as a *required* part of the bootstrap, I think. But that appears to be consistent with your model at the bottom of this message. > > > ... > >> The idea that during the bootstrap process, there is a period when the > >> network (the ACP aka fraternity) and the new node (the pledge) check > >> each other out for fitness. > > > We also need to support the case where there is no ACP, just some sort > > of CA, so that we can use vanilla TLS (or maybe DTLS). > > I think that "CA" doesn't stand for Certificate Authority in this context, > but I don't know what it stands for here. Can you give me an example? In fact I mean Certificate Authority, specifically for example the Domain CA in draft-pritikin. > > ... > >> I don't know if the ANIMA signaling protocol should occur before such > >> a channel is established, or inside of this (provisional) channel, or > >> whether it should instead run inside IKEv2 (maybe inside EAP). > > > The current assumption is that discovery of the nearest trust relay has > > to take place in the clear (and that draft-pritikin may not be the only > > method available, going forward). That would mean one cleartext > > multicast and one cleartext unicast response via GDNP. If that response > > was forged, the bootstrap process needs to fail. > > I'd like to split things up such that we really have: > 1) discovery of peers via variety of protocols X,Y,Z > 2) trial establishment of security protocol > 3) ASA communication and potential establishment of ACP > > I see that GDNP can be used for #1 and #3. Other protocols could also > be used for (1). I'd like to think of the GDNP that is used for #1 as > being of a slightly different flavour than the one for #3. I think that > doing so will let us more easily make progress as it will be clear that > just because we define an attribute for #3, doesn't mean it's valid for #1. We agree on that. Basically 1) should be a strict subset of GDNP. The GDNP engine would need to know that it was running insecurely and therefore limit the allowed features. Brian From nobody Fri Jun 5 13:44:58 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20CA11B3209 for ; Fri, 5 Jun 2015 13:44:57 -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 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 G3RlbvXXQ7LH for ; Fri, 5 Jun 2015 13:44:55 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (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 C233A1B3207 for ; Fri, 5 Jun 2015 13:44:55 -0700 (PDT) Received: by pdbnf5 with SMTP id nf5so60366896pdb.2 for ; Fri, 05 Jun 2015 13:44:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=1yaBpXzrX3ysbPlr7hcYFlim1GZDyachvdZjv4yR8eI=; b=P2Oq+cC06MEr1tl4Mouy0vyomMqyTnagbpvsBufBTqnDik6t0sK2cxgrmEXvleuKQW 04P2YEGdPscnbFvnboc/W6aM8BNg7x1beHTrncRebnqwCa0ZWa4jfdUurjqNB8TTOBNq tqoc1mH/wPza7/N/I35IizlwheVp4LPfJaEnzl7+nUyzus3izgWnBKQz6pEP5oXtHwN8 c7s6LBHvuw9nU6LbGz8imUgQpUJhghUggvpyIfz3qiBuXssE3X8el2Ip5EPUtt0e41yH yRkMPuHMjFd0qCu5ewls+vVQjDfzm3h8wujz3P2x4Kpf6DemdosgzmHL+9GnDcWwiHDS o7zg== X-Received: by 10.70.0.143 with SMTP id 15mr8827404pde.13.1433537095533; Fri, 05 Jun 2015 13:44:55 -0700 (PDT) Received: from ?IPv6:2406:e007:6f63:1:28cc:dc4c:9703:6781? ([2406:e007:6f63:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id sc1sm7731488pac.36.2015.06.05.13.44.52 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jun 2015 13:44:54 -0700 (PDT) Message-ID: <55720A4E.6080006@gmail.com> Date: Sat, 06 Jun 2015 08:45:02 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: anima@ietf.org References: <55712193.5040507@gmail.com> <27763.1433514538@sandelman.ca> In-Reply-To: <27763.1433514538@sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Two questions to the WG from the Signaling Design Team X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 05 Jun 2015 20:44:57 -0000 On 06/06/2015 02:28, Michael Richardson wrote: > > Brian E Carpenter wrote: > > If we want Anima to be an ongoing success, it needs to be convenient > > for the designers of Autonomic Service Agents to define new objectives > > and for programmers to express them in code, without being protocol > > design experts. > > I wish to clarify your words: > "protocol design expert" == someone who can write IETF draft, or > navigate IANA / Expert Review process. There's that, and there is also quite simply (and no insult intended) a recent CS graduate who's been hired to work on an ASA product and has been brought up on object-oriented languages and simply isn't familiar with bit-oriented protocol design. > > > Question 2: This is a cosmetic question. The current protocol model > > assumes that autonomic operations will be either negotiation or > > synchronization between peers. As time goes on, we might want to extend > > this model. So should we change the protocol name from GDNP (generic > > discovery and negotiation) to GRASP (GeneRic Autonomic Signaling > > Protocol)? > > I like GRASP as a name, I don't know if I like the expanstion. > I find GDNP a mouthful and hard to type (GNDP...) The name is more important the expansion, perhaps ;-) Brian From nobody Fri Jun 5 18:07:42 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2D661AC430 for ; Fri, 5 Jun 2015 18:07:40 -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 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 7UsD-UqIliAd for ; Fri, 5 Jun 2015 18:07:39 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (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 7898F1AC42F for ; Fri, 5 Jun 2015 18:07:39 -0700 (PDT) Received: by pacyx8 with SMTP id yx8so22494747pac.2 for ; Fri, 05 Jun 2015 18:07:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=vlSWT97bN16nFNmUIjIo0j4OiN/JKF937X96mK3Z3aw=; b=DoJ682v3PK79BdX0fxTiYHx6ZhBa3Nv2jLQ4X2VyI5VXsKX9hvSiFhtknagZDd3f/0 dqhkkz7z/pRBwoXgG/GMw7Kdc7hqbPH12X9t7hPaUmt0iktd/W2o8bG+I799M/plqcQT 5M71xj5Xx/i+SP8ODg5Vf+vhqnZGxu0rpJla1rUx514nXudRcU9sMEquFS7SKZLv6uR0 8kABv948Dzd/3ShgEbsw7eGxalAsNX/nGA4gL3q381+0CyjtDraSu1um0kRmC5BvDKUZ Q72coKH876eM5Gd82Blz19i9a3XMjz2mR2Kx+OuU7Rsolg9sy8LPYQ/B9dAnP41ey8/S tG/w== X-Received: by 10.70.33.102 with SMTP id q6mr9825743pdi.37.1433552858972; Fri, 05 Jun 2015 18:07:38 -0700 (PDT) Received: from ?IPv6:2406:e007:6f63:1:28cc:dc4c:9703:6781? ([2406:e007:6f63:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id ng13sm7888968pdb.82.2015.06.05.18.07.35 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jun 2015 18:07:37 -0700 (PDT) Message-ID: <557247E1.6060200@gmail.com> Date: Sat, 06 Jun 2015 13:07:45 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Michael Richardson , Anima WG References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC52BD@xmb-rcd-x14.cisco.com> <557066F0.80902@alcatel-lucent.com> <26756.1433442296@sandelman.ca> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC6383@xmb-rcd-x14.cisco.com> <1440.1433516131@sandelman.ca> In-Reply-To: <1440.1433516131@sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Next steps for the reference document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jun 2015 01:07:41 -0000 > Autonomic Service Agents are not expected to run or fit into class 2 or > smaller constrained nodes (see RFC7228). That makes a lot of sense to me (thanks, BTW, for introducing me to RFC 7228). Especially if we take GDNP in the JSON direction, I don't see it on 250kB devices, except maybe for a tiny subset. So, quoting Michael B's earlier message on this thread: > The ASA will be VERY simple: > - if mechanical switch goes to "off", send a message to "all lights under my control": "turn Off" > - if mechanical switch goes to "on", send a message to "all lights under my control": "turn On" > - some way to learn which lights are under its control, some grouping of sorts. Except that, for example, there might be a need for intent saying "ignore mechanical switch iff evacuation_mode and not fireman_mode" or something. In other words things can get complicated quite quickly, so RFC7228-class2 nodes are looking like borderline cases to me. Regards Brian From nobody Sun Jun 7 23:02:20 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 167061B2BFD for ; Sun, 7 Jun 2015 23:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKohTIEMrmpm for ; Sun, 7 Jun 2015 23:02:17 -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 91C8B1B2BFC for ; Sun, 7 Jun 2015 23:02:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BTN36378; Mon, 08 Jun 2015 06:02:15 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 8 Jun 2015 07:02:14 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.152]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Mon, 8 Jun 2015 14:02:06 +0800 From: Sheng Jiang To: Anima WG Thread-Topic: [Anima] Two questions to the WG from the Signaling Design Team Thread-Index: AQHQn0XUIOSSeQd2DEK4OO4YQk/wlp2dc0IAgASslqA= Date: Mon, 8 Jun 2015 06:02:05 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B925F54D13E@nkgeml512-mbx.china.huawei.com> References: <55712193.5040507@gmail.com> <27763.1433514538@sandelman.ca> In-Reply-To: <27763.1433514538@sandelman.ca> 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] Two questions to the WG from the Signaling Design Team X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 08 Jun 2015 06:02:19 -0000 PiAgICA+IFF1ZXN0aW9uIDI6IFRoaXMgaXMgYSBjb3NtZXRpYyBxdWVzdGlvbi4gVGhlIGN1cnJl bnQgcHJvdG9jb2wgbW9kZWwNCj4gICAgPiBhc3N1bWVzIHRoYXQgYXV0b25vbWljIG9wZXJhdGlv bnMgd2lsbCBiZSBlaXRoZXIgbmVnb3RpYXRpb24gb3INCj4gICAgPiBzeW5jaHJvbml6YXRpb24g YmV0d2VlbiBwZWVycy4gQXMgdGltZSBnb2VzIG9uLCB3ZSBtaWdodCB3YW50IHRvDQo+ZXh0ZW5k DQo+ICAgID4gdGhpcyBtb2RlbC4gU28gc2hvdWxkIHdlIGNoYW5nZSB0aGUgcHJvdG9jb2wgbmFt ZSBmcm9tIEdETlANCj4oZ2VuZXJpYw0KPiAgICA+IGRpc2NvdmVyeSBhbmQgbmVnb3RpYXRpb24p IHRvIEdSQVNQIChHZW5lUmljIEF1dG9ub21pYyBTaWduYWxpbmcNCj4gICAgPiBQcm90b2NvbCk/ DQo+DQo+SSBsaWtlIEdSQVNQIGFzIGEgbmFtZSwgSSBkb24ndCBrbm93IGlmIEkgbGlrZSB0aGUg ZXhwYW5zdGlvbi4NCj5JIGZpbmQgR0ROUCBhIG1vdXRoZnVsIGFuZCBoYXJkIHRvIHR5cGUgKEdO RFAuLi4pDQoNCkkgbGlrZSBHUkFTUCBhcyB3ZWxsLCB3aXRoIGRpZmZlcmVudCByZWFzb246IGl0 IGRvZXMgbm90IG1lYW4gdGhlIGZ1bmN0aW9ucyBvbmx5IGhhdmUgZGlzY292ZXJ5IGFuZCBuZWdv dGlhdGlvbi4gU2luY2Ugd2UgYXJlIGRpc2N1c3NpbmcgdG8gYWRkIG1vcmUgc2lnbmFsaW5nIGZ1 bmN0aW9ucywgbGlrZSBzeW5jaHJvbml6YXRpb24sIEdSQVNQIG1heSBiZSBtb3JlIHByb3Blci4N Cg0KU2hlbmcNCg0KPi0tDQo+TWljaGFlbCBSaWNoYXJkc29uIDxtY3IrSUVURkBzYW5kZWxtYW4u Y2E+LCBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MNCj4gLT0gSVB2NiBJb1QgY29uc3VsdGluZyA9 LQ0KPg0KPg0KDQo= From nobody Tue Jun 9 05:06:05 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB5A1A1B0D for ; Tue, 9 Jun 2015 05:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.811 X-Spam-Level: X-Spam-Status: No, score=-11.811 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IopCBL11KPic for ; Tue, 9 Jun 2015 05:06:01 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D8E71A1A37 for ; Tue, 9 Jun 2015 05:06:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5589; q=dns/txt; s=iport; t=1433851561; x=1435061161; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=K3xJA56upbHI/J7sZmq1ffpSnrCXplbhKfdo3A5Qb00=; b=DlZXwM/y9TZn11vh1Oa7Gs2m4e11l0Sk7zo60fhzpEDBo7TKoMOE5S0S V1192ttDemlNhoBouvfdPrWSoQFmmt5cKp94zETW5RXSejHQnAj8eccsC 4cC0ihv8LoI2cp9cOk+UCtx9s2qMBHLfGTDtTrdndvO9lGN4l2oW9U3h6 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BTBQAB1nZV/49dJa1TCYMQgTi+CW+HWgKBRToSAQEBAQEBAYEKhCIBAQEBAgEnE0QLAgEIIhQQMiUBAQQBGogeCNAPAQEBAQEBAQEBAQEBAQEBAQEBGopBgQKEKgMoOIMXgRYFi2iHVocVhUuGe4tlg1skggocgVKBcgIeBxyBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,579,1427760000"; d="scan'208";a="93473" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-8.cisco.com with ESMTP; 09 Jun 2015 12:05:45 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t59C5jmv010886 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Jun 2015 12:05:45 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.238]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Tue, 9 Jun 2015 07:05:45 -0500 From: "Michael Behringer (mbehring)" To: Michael Richardson , Anima WG Thread-Topic: [Anima] Next steps for the reference document Thread-Index: AdCeyJnnoO1vHkFQQ5yr85+CL+laOwAN9cwAAAdOZQAAFS22AAAVzI+AALQntKA= Date: Tue, 9 Jun 2015 12:05:44 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC9C0A@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC52BD@xmb-rcd-x14.cisco.com> <557066F0.80902@alcatel-lucent.com> <26756.1433442296@sandelman.ca> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC6383@xmb-rcd-x14.cisco.com> <1440.1433516131@sandelman.ca> In-Reply-To: <1440.1433516131@sandelman.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.13] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Next steps for the reference document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jun 2015 12:06:04 -0000 MichaelR, great guidance, thanks for that. Inline... > I have read the reference model. > Can we adopt this already? You mean the reference model as a WG item? That's for the chairs to decide,= but my personal target is to have it before Prague in such a shape that ad= option should be unanimous.=20 =20 > I suggest changing: > MASA (Manufacturer Authorized Signing Authority): The MASA is a > service for devices of a particular vendor. It can validate the > identity of devices that are to be used in an autonomic domain, > assert which device is owned by which domain, etc. > to: > MASA (Manufacturer Authorized Signing Authority): The MASA is an > online service for devices of a particular vendor. The MASA > can validate the identity of devices that are to be used in an > autonomic domain. It can provide assertions as to the owner > of a particular device. The name/location of the MASA is built-in > to the device at the Factory. Yes, that's better. Actually, given past discussions on this subject I woul= d also mention explicitly the possibility to just provide a history of the = device. So, adding this to your paragraph would result in (my change in upp= ercase):=20 MASA (Manufacturer Authorized Signing Authority): The MASA is an online service for devices of a particular vendor. The MASA can validate the identity of devices that are to be used in an autonomic domain. It can provide assertions as to the owner OR THE HISTORY of a particular device. The name/location of the MASA is b= uilt-in to the device at the Factory. I'll change that in the doc. Does anyone else have comments here? =20 > section 3.4: Constrained Nodes >=20 > Autonomic Service Agents are not expected to run or fit into class 2 or > smaller constrained nodes (see RFC7228). If there are constrained nodes > that need to be involved in the Autonomic Control Plane, it is assumed th= at > they do so with the aid of a designated non-constrained node. (Finding an= d > electing an constrained-node helper is itself an autonomic function) >=20 > Constrained nodes do need to be able to join the network, and the trust > infrastructure (section 6) is expected to provide a transitive trust > mechanism such that constrained nodes can be helped in a secure way. >=20 > section 3.5: Challenged networks >=20 > In comparison to the production network (which may not yet be > operational), the Autonomic Control Plane could be considered > constrained. The bandwidth differences may be on the order of a 1000x or > more (100Gb/s production networks compared to ACP bandwidths between > 1Mb/s and 10Mb/s). The resulting ACP is considered slow, but should not = in > general be considered challenged as defined by RFC7228. As such, the ACP > should significantly depreference LLNs and other limited energy networks, > but use of such networks during the bootstrap of the ACP is in scope. I think ... this discussion might be addressing the wrong problem. I think = the primary question is not whether a node can run an ASA or not, because i= t assumes that the ANI is the same everywhere.=20 To me, the main question is: Can we have a useful, reduced ANI implementati= on?=20 I can see a constrained AN node, which for example can live at the edge onl= y, doesn't support bootstrap proxy, full routing, etc, and who's ANI is the= refore smaller. Possibly a different security model in the constrained netw= ork; etc.=20 And then, a simple ASA on top of this reduced ANI.=20 And, MichaelR, you *are* saying this, more or less. But I would formulate i= t the other way round, starting with the ANI, and really focusing on that:= =20 section 3.4: Constrained Nodes Constrained nodes have a reduced ANI, with a well-defined minimal functiona= lity (details to be worked out): They do need to be able to join the networ= k, and communicate with at least a helper node which has full ANI functiona= lity.=20 <-- you wrote at this point: ... and the trust infrastructure (section 6) is ex= pected to provide a transitive trust mechanism such that constrained nodes can be helped in a secure way. ... I don't understand what you mean with "can be helped". You mean: If th= e NOC trusts the helper, and the helper trusts the constrained device, we'r= e good, right?=20 -->=20 You wrote further:=20 Autonomic Service Agents are not expected to run or fit into class 2 or smaller constrained nodes (see RFC7228). If there are constrained nodes that need to be involved in the Autonomic Control Plane, it is assumed that they do so with the aid of a designated non-constrained node. (Finding and electing an constrained-node helper is itself an autonomic function) At this point, I would rather defined whether the (reduced) ANI fits into a= class 2 device. Do you think we can make that happen? I would guess so?=20 Once we understand what a reduced ANI means, and which nodes can run it, TH= EN I think we can start thinking about ASAs. And to my previous example of = the light switch, I (still) believe that an ASA could be VERY small. So thi= s is not the key question here, I think.=20 So, in summary, I see:=20 - full ANI - reduced ANI: Probably we need to define exactly which functions we can ex= pect in a reduced ANI. Ideally this would result in a single class.=20 - ASAs that require the full ANI - ASAs that can also run on a reduced ANI.=20 Thoughts? (This is a good discussion!) Michael From nobody Tue Jun 9 13:03:44 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E959F1B2EB8 for ; Tue, 9 Jun 2015 13:03:42 -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 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 FiOGjUsHay3r for ; Tue, 9 Jun 2015 13:03:41 -0700 (PDT) Received: from mail-pd0-x242.google.com (mail-pd0-x242.google.com [IPv6:2607:f8b0:400e:c02::242]) (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 83C0E1A8AA7 for ; Tue, 9 Jun 2015 13:03:41 -0700 (PDT) Received: by pdbht2 with SMTP id ht2so5529643pdb.1 for ; Tue, 09 Jun 2015 13:03:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=BV5woI0D+az0i/Zlj9vwTViaKeIF9e8dEWTYlshcjVo=; b=rG45suC0b0lXk8KSsUvqZffn4boP/fYuit4LqYsjlPvRmPRkvcqsEwA+Gru/i9v8cK t0B9w4BgzPPwyFB8muBC2wlpmcnTlrOvOkgQ/4JRtipj6O2QBGtjy7AjYAVUYb0AED4O G2LhCYFtsF+Ukk7DYTfzEOc9FRwWoGsadIDMPrx8NdZT5CkeRODeJV5fJ9H3ur3IO7wH CoHWES4rOGaOt+hmgZNtQDfQOB5/3IZnuq6ZVCMyyZmesS13gVmJINaN1/8uyxkX3K2l YP29PFgSaFPCkIzBo8xqpV7H7lRVlvb4D7oF/PlCx1ed9DnC7ea+2PX57P0JB8J+vIzv XZ6Q== X-Received: by 10.66.249.1 with SMTP id yq1mr40808062pac.3.1433880221219; Tue, 09 Jun 2015 13:03:41 -0700 (PDT) Received: from ?IPv6:2406:e007:4057:1:28cc:dc4c:9703:6781? ([2406:e007:4057:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id d5sm6401300pdl.85.2015.06.09.13.03.37 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jun 2015 13:03:39 -0700 (PDT) Message-ID: <5577469C.1040405@gmail.com> Date: Wed, 10 Jun 2015 08:03:40 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , Michael Richardson , Anima WG References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC52BD@xmb-rcd-x14.cisco.com> <557066F0.80902@alcatel-lucent.com> <26756.1433442296@sandelman.ca> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC6383@xmb-rcd-x14.cisco.com> <1440.1433516131@sandelman.ca> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC9C0A@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC9C0A@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Next steps for the reference document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jun 2015 20:03:43 -0000 On 10/06/2015 00:05, Michael Behringer (mbehring) wrote: ... > Once we understand what a reduced ANI means, and which nodes can run it, THEN I think we can start thinking about ASAs. And to my previous example of the light switch, I (still) believe that an ASA could be VERY small. So this is not the key question here, I think. The logic of an ASA could be very simple, if that's what you mean by saying it could be very small. But indeed, the question is whether the footprint of the supporting code could be very small. I'm far from convinced of that, especially if we use a prolix format like JSON. However you reduce the ASA functionality, you're going to need a certain set of components, like - minimal O/S - network stack - security stack - bootstrap logic - GDNP engine (which might require a JSON interpreter & CBOR encoder/decoder) - the actual light switch controller and then you can get started with your ASA. Brian > So, in summary, I see: > - full ANI > - reduced ANI: Probably we need to define exactly which functions we can expect in a reduced ANI. Ideally this would result in a single class. > - ASAs that require the full ANI > - ASAs that can also run on a reduced ANI. > > Thoughts? (This is a good discussion!) > Michael > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Tue Jun 9 13:19:49 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB861B30A5 for ; Tue, 9 Jun 2015 13:19:47 -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 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 kaPErfWDFjj4 for ; Tue, 9 Jun 2015 13:19:45 -0700 (PDT) Received: from mail-pa0-x243.google.com (mail-pa0-x243.google.com [IPv6:2607:f8b0:400e:c03::243]) (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 BFF161B2FEA for ; Tue, 9 Jun 2015 13:19:45 -0700 (PDT) Received: by pabli10 with SMTP id li10so6074378pab.1 for ; Tue, 09 Jun 2015 13:19:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=t17nB6aZb4BHEKK2R4YlRNsc75oZBucc+QjOz3lPEpA=; b=n/9Qvw0CKXtFRBuQ/yOr93EnqSVeMFomNLJc1G92wfLVSnyVEr6pXMwG9h5tx0loSM 6gvmZE1tvy2Q8aF2MS9lWRlEUSqDhN9mPose2VMX3MRbJ1ZUVJsKipvS+Wfr34ZRVBC7 PlQxdcuqGHPHTa708RjbL5gJtUzKvyH4Aj0js4WKwJEAm3ijEtMy0q7TkS1lepcShkbh c03ETxtmmJnn83k6LL8bhkGGoc7qGH9ne7j4pYAlG6iWRM+n4gU8wSUTTV9n6mAJBiIY oxohSDJOr5JdPnbwnfe+dNmeq8eliHHso8mHzyd69wYIcwQIl2e6dKJy6rSnj1+Txx3G YJLw== X-Received: by 10.68.219.201 with SMTP id pq9mr42245056pbc.97.1433881185386; Tue, 09 Jun 2015 13:19:45 -0700 (PDT) Received: from ?IPv6:2406:e007:4057:1:28cc:dc4c:9703:6781? ([2406:e007:4057:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id a6sm6456077pas.28.2015.06.09.13.19.42 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jun 2015 13:19:44 -0700 (PDT) Message-ID: <55774A61.6020400@gmail.com> Date: Wed, 10 Jun 2015 08:19:45 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Anima WG References: <20150609195904.5247.53543.idtracker@ietfa.amsl.com> In-Reply-To: <20150609195904.5247.53543.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150609195904.5247.53543.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Fwd: New Non-WG Mailing List: 6band -- 6lo Bootstrapping, Access for Networked Devices X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jun 2015 20:19:47 -0000 Hi, How will this relate to the Anima bootstrapping work? Brian -------- Forwarded Message -------- Subject: New Non-WG Mailing List: 6band -- 6lo Bootstrapping, Access for Networked Devices Date: Tue, 09 Jun 2015 12:59:04 -0700 From: IETF Secretariat Reply-To: ietf@ietf.org To: IETF Announcement List CC: samita.chakrabarti@ericsson.com, Gabriel.Montenegro@microsoft.com, 6band@ietf.org A new IETF non-working group email list has been created. List address: 6band@ietf.org Archive: http://www.ietf.org/mail-archive/web/6band/ To subscribe: https://www.ietf.org/mailman/listinfo/6band Purpose: The scope of this mailing list is mainly to address threat analysis of 6lo networks, secure bootstrapping and evaluating solutions for constrained node devices in constrained-L2-access technology networks. The problem scope is limited to secure network access/bootstrapping of the 6lo nodes. This interest group may also discuss interfaces between network layer and Application layer for sharing security association. The scope of this work does not include Application level security work . The goal is to identify existing candidate technologies or needs for new development of bootstrapping mechanisms. For additional information, please contact the list administrators. From nobody Wed Jun 10 01:36:08 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 708DD1ACD93 for ; Wed, 10 Jun 2015 01:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6i2mgXIJQ5Fd for ; Wed, 10 Jun 2015 01:35:56 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD2DF1ACD82 for ; Wed, 10 Jun 2015 01:35:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3088; q=dns/txt; s=iport; t=1433925357; x=1435134957; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=DTDPHbDuv/iq8Y1rgp3yqgdLu5tsrVcJDdPYhOZR1Vs=; b=mcCP1wlwIXBSwPCwFPT8MYmQANuXamMks7+OStMF926EYxA3UH5nTbVJ roGQPaOaVGZzGAFblCo9KFiHWeLLr4cvGqlv1TcK8UrgIcw/nbpWz5HCm zlPq3h6tR+r8JpUgGXI6/li9aNfcS/Lvin8VgaD4Tf6HWns2XFNTkJ8rp w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CgBABj9XdV/5RdJa1cgxBUXwaDGLpgZgmBOB8KhXsCHIEkOBQBAQEBAQEBgQqEIgEBAQECAQEBASAROhAHBAIBCBEEAQEBAgIGHQMCAgIfBgsUAQgIAgQBEgiIEQMKCA2sSp5TDYU1AQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBIYoigk2CCBYiBoJiL4EWBZNAiVODEI8ygzaDWySDeG8BgUWBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,586,1427760000"; d="scan'208";a="2281791" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-4.cisco.com with ESMTP; 10 Jun 2015 08:35:56 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t5A8ZtAZ029249 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Jun 2015 08:35:55 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.238]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Wed, 10 Jun 2015 03:35:55 -0500 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , Michael Richardson , Anima WG Thread-Topic: [Anima] Next steps for the reference document Thread-Index: AdCeyJnnoO1vHkFQQ5yr85+CL+laOwAN9cwAAAdOZQAAFS22AAAVzI+AALQntKAAH8XKAAAPTiwg Date: Wed, 10 Jun 2015 08:35:54 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FCA7A5@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC52BD@xmb-rcd-x14.cisco.com> <557066F0.80902@alcatel-lucent.com> <26756.1433442296@sandelman.ca> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC6383@xmb-rcd-x14.cisco.com> <1440.1433516131@sandelman.ca> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FC9C0A@xmb-rcd-x14.cisco.com> <5577469C.1040405@gmail.com> In-Reply-To: <5577469C.1040405@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.141] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Next steps for the reference document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jun 2015 08:36:03 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBb bWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbV0NCj4gU2VudDogMDkgSnVuZSAyMDE1 IDIyOjA0DQo+IFRvOiBNaWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpOyBNaWNoYWVsIFJpY2hh cmRzb247IEFuaW1hIFdHDQo+IFN1YmplY3Q6IFJlOiBbQW5pbWFdIE5leHQgc3RlcHMgZm9yIHRo ZSByZWZlcmVuY2UgZG9jdW1lbnQNCj4gDQo+IE9uIDEwLzA2LzIwMTUgMDA6MDUsIE1pY2hhZWwg QmVocmluZ2VyIChtYmVocmluZykgd3JvdGU6DQo+IC4uLg0KPiA+IE9uY2Ugd2UgdW5kZXJzdGFu ZCB3aGF0IGEgcmVkdWNlZCBBTkkgbWVhbnMsIGFuZCB3aGljaCBub2RlcyBjYW4gcnVuDQo+IGl0 LCBUSEVOIEkgdGhpbmsgd2UgY2FuIHN0YXJ0IHRoaW5raW5nIGFib3V0IEFTQXMuIEFuZCB0byBt eSBwcmV2aW91cw0KPiBleGFtcGxlIG9mIHRoZSBsaWdodCBzd2l0Y2gsIEkgKHN0aWxsKSBiZWxp ZXZlIHRoYXQgYW4gQVNBIGNvdWxkIGJlIFZFUlkgc21hbGwuDQo+IFNvIHRoaXMgaXMgbm90IHRo ZSBrZXkgcXVlc3Rpb24gaGVyZSwgSSB0aGluay4NCj4gDQo+IFRoZSBsb2dpYyBvZiBhbiBBU0Eg Y291bGQgYmUgdmVyeSBzaW1wbGUsIGlmIHRoYXQncyB3aGF0IHlvdSBtZWFuIGJ5IHNheWluZw0K PiBpdCBjb3VsZCBiZSB2ZXJ5IHNtYWxsLiBCdXQgaW5kZWVkLCB0aGUgcXVlc3Rpb24gaXMgd2hl dGhlciB0aGUgZm9vdHByaW50IG9mDQo+IHRoZSBzdXBwb3J0aW5nIGNvZGUgY291bGQgYmUgdmVy eSBzbWFsbC4gSSdtIGZhciBmcm9tIGNvbnZpbmNlZCBvZiB0aGF0LA0KPiBlc3BlY2lhbGx5IGlm IHdlIHVzZSBhIHByb2xpeCBmb3JtYXQgbGlrZSBKU09OLiBIb3dldmVyIHlvdSByZWR1Y2UgdGhl IEFTQQ0KPiBmdW5jdGlvbmFsaXR5LCB5b3UncmUgZ29pbmcgdG8gbmVlZCBhIGNlcnRhaW4gc2V0 IG9mIGNvbXBvbmVudHMsIGxpa2UNCj4gIC0gbWluaW1hbCBPL1MNCj4gIC0gbmV0d29yayBzdGFj aw0KPiAgLSBzZWN1cml0eSBzdGFjaw0KPiAgLSBib290c3RyYXAgbG9naWMNCj4gIC0gR0ROUCBl bmdpbmUgKHdoaWNoIG1pZ2h0IHJlcXVpcmUgYSBKU09OIGludGVycHJldGVyICYgQ0JPUg0KPiBl bmNvZGVyL2RlY29kZXIpDQo+ICAtIHRoZSBhY3R1YWwgbGlnaHQgc3dpdGNoIGNvbnRyb2xsZXIN Cj4gYW5kIHRoZW4geW91IGNhbiBnZXQgc3RhcnRlZCB3aXRoIHlvdXIgQVNBLg0KDQpSaWdodC4g VGhhdCdzIHdoYXQgSSBtZWFuIC0gdGhlIGNvbnN0cmFpbnQgaXMgbW9yZSBvbiB0aGUgQU5JIHNp ZGUgdGhhbiBvbiB0aGUgQVNBIHNpZGUuIA0KDQpDYW4gd2UgZXN0aW1hdGUgdGhlIG1pbmltYWwg cmVxdWlyZW1lbnRzIGZvciBhIGNvbnN0cmFpbmVkIEFOSSwgbG9va2luZyBhdCB0aGUgbGlzdCBh Ym92ZT8gDQoNCk9uZSBxdWVzdGlvbiB3ZSBuZWVkIHRvIGFzayBvdXJzZWx2ZXMgaXMgd2hldGhl ciB3ZSB3YW50IHRvIGluY2x1ZGUgdGhlIHdvcmsgb24gY29uc3RyYWluZWQgbm9kZXMgcmlnaHQg bm93IG9yIHB1c2ggdGhhdCBiYWNrPyBJZiB3ZSB1bmRlcnN0YW5kIHRoZSBBTiBtb2RlbCBmb3Ig Y29uc3RyYWluZWQgbm9kZXMgYmV0dGVyLCB3ZSBjYW4gc2VlIHdoZXRoZXIgdGhlcmUgYXJlIGFu eSBpbW1lZGlhdGUgdXNlIGNhc2VzIGFyb3VuZCBmb3IgdGhpcywgd2hpY2ggbWlnaHQgaGVscCB1 cyBwcmlvcml0aXplLiANCg0KTWljaGFlbA0KIA0KPiAgICBCcmlhbg0KPiANCj4gPiBTbywgaW4g c3VtbWFyeSwgSSBzZWU6DQo+ID4gLSBmdWxsIEFOSQ0KPiA+IC0gcmVkdWNlZCBBTkk6IFByb2Jh Ymx5IHdlIG5lZWQgdG8gZGVmaW5lIGV4YWN0bHkgd2hpY2ggZnVuY3Rpb25zIHdlIGNhbg0KPiBl eHBlY3QgaW4gYSByZWR1Y2VkIEFOSS4gSWRlYWxseSB0aGlzIHdvdWxkIHJlc3VsdCBpbiBhIHNp bmdsZSBjbGFzcy4NCj4gPiAtIEFTQXMgdGhhdCByZXF1aXJlIHRoZSBmdWxsIEFOSQ0KPiA+IC0g QVNBcyB0aGF0IGNhbiBhbHNvIHJ1biBvbiBhIHJlZHVjZWQgQU5JLg0KPiA+DQo+ID4gVGhvdWdo dHM/IChUaGlzIGlzIGEgZ29vZCBkaXNjdXNzaW9uISkgTWljaGFlbA0KPiA+DQo+ID4NCj4gPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IEFuaW1h IG1haWxpbmcgbGlzdA0KPiA+IEFuaW1hQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9hbmltYQ0KPiA+DQo= From nobody Wed Jun 10 02:35:16 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED511ACE0E for ; Wed, 10 Jun 2015 02:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zeg-ZuML5dxl for ; Wed, 10 Jun 2015 02:35:05 -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 F28D81ACE0C for ; Wed, 10 Jun 2015 02:35:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXF16699; Wed, 10 Jun 2015 09:35:01 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 10 Jun 2015 10:34:59 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.152]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Wed, 10 Jun 2015 17:34:57 +0800 From: Sheng Jiang To: Anima WG Thread-Topic: Call for Agenda ANIMA @ IETF93 Thread-Index: AdCjYLWNFwnod5ilQb6HZ9KChOr3Nw== Date: Wed, 10 Jun 2015 09:34:56 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B925F54F700@nkgeml512-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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "anima-chairs@tools.ietf.org" Subject: [Anima] Call for Agenda ANIMA @ IETF93 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jun 2015 09:35:09 -0000 SGksIGFsbCwNCg0KV2UgaGF2ZSByZXF1ZXN0ZWQgdHdvIHNlc3Npb25zIG9mIDIgaG91ciArIDEu NSBob3VyIGZvciB0aGUgQU5JTUEgV0cgbWVldGluZyBmb3IgSUVURi05MyAoUHJhZ3VlKSBhbmQg YXJlIHN0YXJ0aW5nIHRvIGNvbGxlY3QgYWdlbmRhIGl0ZW1zIGZvciB0aGlzIHNlc3Npb24uIERp ZmZlcmVudCBmcm9tIElFVEY5MiwgZm9sbG93aW5nIHRoZSBmZWVkYmFjayBmcm9tIG91ciByZXNw b25zaWJsZSBBRHMsIHdlIGRvIG5vdCByZXNlcnZlIHRoZSBzZWNvbmQgc2Vzc2lvbiBmb3Igbm9u LWNoYXJ0ZXIgd29yayBpdGVtcy4gSXQgc2F5cyB0aGUgY2hhcnRlciB3b3JrIGl0ZW0gd291bGQg aGF2ZSBwcmlvcml0eS4gV2Ugd2lsbCBvbmx5IGRpc2N1c3Mgbm9uLWNoYXJ0ZXIgd29yayBpdGVt cyB1bnRpbCB3ZSBmaW5pc2ggY2hhcnRlciB3b3JrIGl0ZW1zLiBBbm90aGVyIGRpZmZlcmVudGlh IGlzIHRoZSBub24tY2hhcnRlciB3b3JrIGl0ZW1zIG11c3QgaGF2ZSBhdCBsZWFzdCBzdWJtaXR0 ZWQgZHJhZnRzIHRvIGJlIGluY2x1ZGVkIGluIHRoZSBhZ2VuZGEuIFRoaXMgdGhyZXNob2xkIG1h eSBldmVuIHJhaXNlIGluIHRoZSBmdXR1cmUgSUVURiBtZWV0aW5ncywgc3VjaCBhcyBhY3RpdmUg ZGlzY3Vzc2lvbiBpbiBtYWlsIGxpc3QuDQoNClBsZWFzZSBzZW5kIHVzIChhbmltYS1jaGFpcnNA dG9vbHMuaWV0Zi5vcmcpIHJlcXVlc3RzIGZvciBzZXNzaW9ucyBhbmQgaW5jbHVkZToNCg0KTmFt ZSBvZiB0aW1lIHNsb3Q6DQpOYW1lIG9mIGRyYWZ0KHMpOg0KVGltZSByZXF1ZXN0ZWQ6DQpQcmVz ZW50ZXIgbmFtZShzKToNCkJyaWVmIGRlc2NyaXB0aW9uIG9mIHdoYXQgaXNzdWVzIG5lZWQgZGlz Y3Vzc2luZyBhbmQgd2hhdCB5b3UgaG9wZSB0byBhY2NvbXBsaXNoIGJ5IHByZXNlbnRpbmcgKHBs ZWFzZSBmb2N1cyBvbiBvcGVuIGlzc3VlcywgcmF0aGVyIHRoYW4gYSBzdGF0dXMgdXBkYXRlKToN Cg0KTW9yZSBkZXRhaWxzIGFib3V0IHRoZSBQcmFndWUgSUVURiBjYW4gYmUgZm91bmQgYXQgaHR0 cDovL3d3dy5pZXRmLm9yZy9tZWV0aW5nLzkzL2luZGV4Lmh0bWwuDQoNCkFnYWluLCBwcmVzZW50 ZXJzIGFuZCBkcmFmdCBhdXRob3JzIHBsZWFzZSBpbnZva2UgYWN0aXZlIGRpc2N1c3Npb25zIGlu IHRoZSBBTklNQSBsaXN0LiBXZSBoYXZlIHZlcnkgbGltaXRlZCB0aW1lIGZvciBlYWNoIHRvcGlj IGluIHRoZSBmYWNlLXRvLWZhY2UgbWVldGluZy4gTWFpbCBsaXN0IGlzIGEgdmVyeSBnb29kIHBs YWNlIHRvIGRpc2N1c3MgYW5kIHJlYWNoIGNvbnNlbnN1cyBvbiB0ZWNobmljYWwgaXNzdWVzLg0K DQpCZXN0IHJlZ2FyZHMsDQoNClRvZXJsZXNzICYgU2hlbmcNCg== From nobody Wed Jun 10 05:14:30 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1701AD291 for ; Wed, 10 Jun 2015 05:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Cs7IxKioU9h for ; Wed, 10 Jun 2015 05:14:26 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05B7D1AD289 for ; Wed, 10 Jun 2015 05:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37748; q=dns/txt; s=iport; t=1433938466; x=1435148066; h=from:to:subject:date:message-id:mime-version; bh=kyrqK97cwpa8o+Gbutvc11JfrgNKeOOzgpl+OYz3ido=; b=cJCVas093KMGWzhi37IILppcRon/9BF15UVSFM8GcxUpHN8CExVz6QZB E57oCO/igfHuPi2j1xsRx+u72olyeQ37comHNGKr5KjkBWTqwPs7xVq97 DfYf9LxvGzBt/tFj1aplsgc+5dPv3dr1eWVIhGoFTICfVoXdCHlLvW+FP I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CwBQDuKHhV/4cNJK1cgkVLVF8Ggxi6QG+BPQEZAQmFegIcgR45EwEBAQEBAQGBCoQkAQEDIwpeARoQCwsBCQIEMBcPAQQbAYglDZwmj1+kJgEBAQEBBQEBAQEBHYpBgQKENAEBH0KCIzsSHYEWBZNKozEkg3hvAYELOoEBAQEB X-IronPort-AV: E=Sophos;i="5.13,587,1427760000"; d="scan'208,217";a="6047214" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-3.cisco.com with ESMTP; 10 Jun 2015 12:14:24 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t5ACEOSa024561 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 10 Jun 2015 12:14:24 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.238]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Wed, 10 Jun 2015 07:14:24 -0500 From: "Michael Behringer (mbehring)" To: Anima WG Thread-Topic: Reference document Thread-Index: AdCjcu1GZJrMma3NQjymMMAjjn5BfA== Date: Wed, 10 Jun 2015 12:14:24 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FCA9C1@xmb-rcd-x14.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.141] Content-Type: multipart/alternative; boundary="_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FCA9C1xmbrcdx14ciscoc_" MIME-Version: 1.0 Archived-At: Subject: [Anima] Reference document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jun 2015 12:14:28 -0000 --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FCA9C1xmbrcdx14ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciBhbGwgdGhlIHZvbHVudGVlcnMgdG8gaGVscCB3aXRoIHRoZSBkb2MgaGVyZS4g SW4gZmFjdCwgSeKAmW0gaGF2aW5nIGEgYml0IG9mIGEgaGFyZCB0aW1lIGZpZ3VyaW5nIG91dCBo b3cgdG8gbW92ZSBmb3J3YXJkLCBiZWNhdXNlIHRoZXJlIGFyZSBzZXZlcmFsIG92ZXJsYXBwaW5n IGVkaXRpbmcgc3VnZ2VzdGlvbnMsIGFuZCB0aGUgZG9jdW1lbnQgc3RydWN0dXJlIGRvZXNu4oCZ dCB0YWtlIHRoZSBsYXRlc3QgZGlzY3Vzc2lvbnMgaW50byBhY2NvdW50Lg0KDQoNCg0KSGVyZSBp cyB3aGF0IEnigJl2ZSBkb25lIG5vdzoNCg0KLSAgICAgICAgICBJIHdvcmtlZCBhbGwgdGhlIG9w ZW4gcG9pbnRzIGludG8gdGhlIG91dGxpbmUgb2YgdGhlIGRvY3VtZW50DQoobW9zdCBvZiB0aGVt IGZyb20gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2FuaW1hL2N1cnJlbnQv bXNnMDEwNDQuaHRtbCApDQpJIG1vdmVkIHNlY3Rpb25zIGJhY2sgYW5kIGZvcnRoLCB0cnlpbmcg dG8gZmlndXJlIG91dCB0aGUgbW9zdCBsb2dpY2FsIHN0cnVjdHVyZS4NClRoZSByZXN1bHQgaXMg YSBjb21wbGV0ZWx5IG5ldywgYnV0IGhvcGVmdWxseSBiZXR0ZXIgc3RydWN0dXJlZCBvdXRsaW5l Lg0KDQotICAgICAgICAgIExldOKAmXMgYWdyZWUgb24gdGhlIG91dGxpbmUgZmlyc3QuIERvZXMg dGhpcyBjYXB0dXJlIGFsbCB0aGUgaW1wb3J0YW50IHBvaW50cz8NCg0KLSAgICAgICAgICBUaGVu LCBiYXNlZCBvbiB0aGUgcHJvcG9zYWxzLCB3ZSBsb29rIGF0IHdobyB3b3JrcyBvdXQgd2hpY2gg c2VjdGlvbiwgdG8gYXZvaWQgb3ZlcmxhcCwgYW5kIG1ha2Ugc3VyZSB3ZeKAmXJlIGluIHN5bmMu IChJ4oCZbGwgcHJvcG9zZSBzb21ldGhpbmcgdG8gZ2V0IHN0YXJ0ZWQpLg0KDQoNCg0KRG9lcyB0 aGlzIG1ha2Ugc2Vuc2U/DQoNCg0KDQpJZiBzbywgYmVsb3cgaXMgdGhlIG5ldyBzdWdnZXN0ZWQg b3V0bGluZS4gSSB0aGluayBpdOKAmXMgbW9yZSBsb2dpY2FsbHkgb3JnYW5pc2VkIG5vdzoNCg0K LSAgICAgICAgICBTZWN0aW9uIDIgZ2l2ZXMgdGhlIGhpZ2ggbGV2ZWwgdmlldywgYXMgZm9yIGV4 YW1wbGUgc29tZW9uZSB3cml0aW5nIEFTQXMgd291bGQgbmVlZCB0byBrbm93Lg0KDQotICAgICAg ICAgIFNlY3Rpb24gMyBpcyB0aGUgYXJjaGl0ZWN0dXJlIG9mIGEgc2luZ2xlIG5vZGUuDQoNCi0g ICAgICAgICAgU2VjdGlvbiA0IGlzIHRoZSBBTkkuIFNvIHRoaXMgaXMgdGhlIOKAnGJhc2VsaW5l 4oCdIGFuIEFOIG5vZGUgbmVlZHMgdG8gc3VwcG9ydC4gSSBtb3ZlZCB0aGUgQUNQIHNlY3Rpb25z IGludG8gdGhpcyBzZWN0aW9uIG5vdywgYmVjYXVzZSBpdOKAmXMgYmFzZSBsaW5lIHJlYWxseS4N Cg0KLSAgICAgICAgICBTZWN0aW9uIDUgZGVzY3JpYmVzIHNlY3VyaXR5LiBJ4oCZdmUgYmVlbiBw dXR0aW5nIHRoZSBzdWItZG9tYWluIHF1ZXN0aW9uIGV2ZW50dWFsbHkgdW5kZXIgdGhpcyBoZWFk aW5nLiBXZSBhbHNvIG5lZWQgdG8gZGVzY3JpYmUgdGhlIGNlcnRpZmljYXRlIGZvcm1hdCBhcyB3 ZWxsLiBJ4oCZdmUgYWxzbyBtb3ZlZCB0aGUgTUFTQSBpbnRvIHRoaXMgc2VjdGlvbiwgc2luY2Ug aXTigJlzIGFib3V0IHRydXN0IGF0IHRoZSBlbmQgb2YgdGhlIGRheS4gKE5vdCAxMDAlIHN1cmUg dGhpcyBpcyB0aGUgYmVzdCBwbGFjZSkuDQoNCi0gICAgICAgICAgU2VjdGlvbiA2IGlzIGFib3V0 IHRoZSBBU0FzLiBJ4oCZdmUgbm93IHRha2VuIG91dCB0aGUgcmVnaXN0cmFyIGZyb20gdGhlIOKA nG5vZGVz4oCdIHNlY3Rpb24gYW5kIG1vdmVkIGl0IGFzIGEg4oCcbXVzdCBpbXBsZW1lbnTigJ0g QVNBIGludG8gdGhlIEFTQSBzZWN0aW9uLiBBbHNvIHRoZSBib290c3RyYXAgZnVuY3Rpb25zIHJl YWxseSBhcmUgQVNBcywgc28gdGhleSBhcmUgaW4gdGhpcyBzZWN0aW9uIG5vdy4gVGhpcyB3YXkg d2Uga2VlcCB0aGUgQU5JIOKAnGNsZWFu4oCdLg0KDQotICAgICAgICAgIFNlY3Rpb24gNyBpcyBh Ym91dCBldmVyeXRoaW5nIE1hbmFnZW1lbnQgYW5kIFByb2dyYW1tYWJpbGl0eS4gSW50ZW50IGJl bG9uZ3MgaW4gaGVyZSwgdGhlIGdlbmVyYWwgZGVzY3JpcHRpb24gb2YgaG93IGFuIEFOIG5ldHdv cmsgaXMgbWFuYWdlZCwgQVBJcywgZGF0YSBtb2RlbHMuDQoNCi0gICAgICAgICAgU2VjdGlvbnMg OCBhbmQgOSBhcmUgdW5jaGFuZ2VkIGZyb20gdGhlIGxhc3QgdmVyc2lvbi4gKGFwYXJ0IGZyb20g bnVtYmVyaW5nKQ0KDQotICAgICAgICAgIEFuZCBJIG1hcmtlZCB0aGUgc2VjdGlvbnMgdGhhdCBh cmUgbm90IGRpcmVjdGx5IGFkZHJlc3NlZCBpbiB0aGUgY3VycmVudCBjaGFydGVyLCBidXQgd2hp Y2ggd2Ugc2hvdWxkIGF0IGxlYXN0IGNvdmVyIGluIHByaW5jaXBsZSBoZXJlLCB3aXRoIGFuICgq KS4NCg0KDQoNCiAgIDEuICBJbnRyb2R1Y3Rpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMw0KDQogICAyLiAgVGhlIE5ldHdvcmsgVmlldyAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDMNCg0KICAgMy4gIFRo ZSBBdXRvbm9taWMgTmV0d29yayBFbGVtZW50IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gICA0DQoNCiAgICAgMy4xLiAgQXJjaGl0ZWN0dXJlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNA0KDQogICAgIDMuMi4gIFVuY29uc3RyYWluZWQgQU4g Tm9kZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDUNCg0KICAgICAzLjMu ICBDb25zdHJhaW5lZCBBTiBOb2RlcyAoKikgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gICA2DQoNCiAgIDQuICBUaGUgQXV0b25vbWljIE5ldHdvcmtpbmcgSW5mcmFzdHJ1Y3R1cmUg LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNg0KDQogICAgIDQuMS4gIE5hbWluZyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDYNCg0KICAgICA0LjIu ICBBZGRyZXNzaW5nICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gICA2DQoNCiAgICAgNC4zLiAgRGlzY292ZXJ5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNw0KDQogICAgIDQuNC4gIFNpZ25hbGluZyBmb3IgTmVn b3RpYXRpb24gYW5kIFN5bmNocm9uaXphdGlvbiAuIC4gLiAuIC4gLiAgIDgNCg0KICAgIDQuNS4g IEludGVudCBEaXN0cmlidXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgIDgNCg0KICAgICA0LjYuICBSb3V0aW5nIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gICA4DQoNCiAgICAgNC43LiAgVGhlIEF1dG9ub21pYyBDb250 cm9sIFBsYW5lIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgOA0KDQogICAgIDQuOC4g IFJlcG9ydGluZyAoKikgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgIDkNCg0KICAgICA0LjkuICBGZWVkYmFjayBMb29wcyAoKikgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gICA5DQoNCiAgIDUuICBTZWN1cml0eSBhbmQgVHJ1c3QgSW5m cmFzdHJ1Y3R1cmUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgOQ0KDQogICAgIDUuMS4g IFB1YmxpYyBLZXkgSW5mcmFzdHJ1Y3R1cmUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgIDkNCg0KICAgICA1LjIuICBEb21haW4gQ2VydGlmaWNhdGUgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gICA5DQoNCiAgICAgNS4zLiAgU3ViLURvbWFpbnMgKCopIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMA0KDQogICAgIDUuNC4g IENyb3NzLURvbWFpbiBGdW5jdGlvbmFsaXR5ICgqKSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgMTANCg0KICAgICA1LjUuICBUaGUgTUFTQSAoKikgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEwDQoNCiAgIDYuICBBdXRvbm9taWMgU2VydmljZSBBZ2Vu dHMgKEFTQSkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMA0KDQogICAgIDYuMS4g IEdlbmVyYWwgRGVzY3JpcHRpb24gb2YgYW4gQVNBIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgMTANCg0KICAgICA2LjIuICBTcGVjaWZpYyBBU0FzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEwDQoNCiAgICAgICA2LjIuMS4gIFRoZSBFbnJvbG1lbnQg QVNBIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMA0KDQogICAgICAgNi4y LjIuICBUaGUgRW5yb2xtZW50IFByb3h5IEFTQSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgMTANCg0KICAgICAgIDYuMi4zLiAgVGhlIFJlZ2lzdHJhciBBU0EgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDExDQoNCiAgIDcuICBNYW5hZ2VtZW50IGFuZCBQcm9ncmFt bWFiaWxpdHkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMQ0KDQogICAgIDcuMS4g IEhvdyBhbiBBTiBOZXR3b3JrIElzIE1hbmFnZWQgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgMTENCg0KICAgICA3LjIuICBJbnRlbnQgKCopICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDExDQoNCiAgICAgNy4zLiAgQVBJcyAoKikgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMQ0KDQogICAgIDcuNC4g IERhdGEgTW9kZWwgKCopICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgMTENCg0KICAgOC4gIENvb3JkaW5hdGlvbiBCZXR3ZWVuIEF1dG9ub21pYyBGdW5jdGlvbnMg KCopICAuIC4gLiAuIC4gLiAuIC4gIDExDQoNCiAgICAgOC4xLiAgVGhlIENvb3JkaW5hdGlvbiBQ cm9ibGVtICgqKSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMQ0KDQogICAgIDguMi4g IEEgQ29vcmRpbmF0aW9uIEZ1bmN0aW9uYWwgQmxvY2sgKCopIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgMTINCg0KICAgOS4gIEh5YnJpZCBBcHByb2FjaCB3aXRoIE5vbi1BdXRvbm9taWMgRnVuY3Rp b25zICgqKSAgLiAuIC4gLiAuIC4gIDEzDQoNCiAgIDEwLiBTZWN1cml0eSBDb25zaWRlcmF0aW9u cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMw0KDQoNCg0KSSBoYXZl IHRoaXMgaW4gWE1MLCB3aWxsIGZpcnN0IGFzayB0aGUgY3VycmVudCBjby1hdXRob3JzIGZvciBh cHByb3ZhbCB0byBwdWJsaXNoIHRoaXMg4oCTIEkgdGhpbmsgaXQgd291bGQgYmUgZ29vZCB0byBo YXZlIHRoZSBuZXcgb3V0bGluZSBhcyBhIG5ldyB2ZXJzaW9uIGF2YWlsYWJsZSB0byBhbGwuIElm IHRoZSBjby1hdXRob3JzIGFyZSBmaW5lIHdpdGggdGhpcywgSeKAmWxsIHB1Ymxpc2ggKGhvcGVm dWxseSB0b21vcnJvdykuDQoNCg0KDQpGZWVkYmFjaz8gTW92aW5nIGluIHRoZSByaWdodCBkaXJl Y3Rpb24/DQoNCk1pY2hhZWwNCg0KDQo= --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FCA9C1xmbrcdx14ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxh aW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V Uzt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0 UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCglt YXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBw dDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4w cHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAq Lw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NTUyNDI0MTY4Ow0KCW1zby1saXN0LXR5cGU6aHli cmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTE4Njk2MDQ0NCAtNTk1MzA0NjYwIDEzNDgw NzU1NSAxMzQ4MDc1NTcgMTM0ODA3NTUzIDEzNDgwNzU1NSAxMzQ4MDc1NTcgMTM0ODA3NTUzIDEz NDgwNzU1NSAxMzQ4MDc1NTc7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1h dDozOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDot Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1m b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDps ZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21h cmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+VGhhbmtzIGZvciBhbGwgdGhlIHZvbHVudGVlcnMgdG8gaGVs cCB3aXRoIHRoZSBkb2MgaGVyZS4gSW4gZmFjdCwgSeKAmW0gaGF2aW5nIGEgYml0IG9mIGEgaGFy ZCB0aW1lIGZpZ3VyaW5nIG91dCBob3cgdG8gbW92ZSBmb3J3YXJkLCBiZWNhdXNlIHRoZXJlIGFy ZSBzZXZlcmFsIG92ZXJsYXBwaW5nIGVkaXRpbmcNCiBzdWdnZXN0aW9ucywgYW5kIHRoZSBkb2N1 bWVudCBzdHJ1Y3R1cmUgZG9lc27igJl0IHRha2UgdGhlIGxhdGVzdCBkaXNjdXNzaW9ucyBpbnRv IGFjY291bnQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48 L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0i Q2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkhlcmUgaXMgd2hhdCBJ4oCZ dmUgZG9uZSBub3c6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDt0ZXh0LWluZGVudDotMTguMHB0 O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxmb250IHNp emU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48c3Bh biBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPGZvbnQgc2l6ZT0iMSIgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ow0KPC9zcGFuPjwvZm9udD48L3NwYW4+PC9zcGFuPjwvZm9udD48IVtlbmRpZl0+SSB3b3JrZWQg YWxsIHRoZSBvcGVuIHBvaW50cyBpbnRvIHRoZQ0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0 OmJvbGQiPm91dGxpbmU8L3NwYW4+PC9iPiBvZiB0aGUgZG9jdW1lbnQ8YnI+DQoobW9zdCBvZiB0 aGVtIGZyb20gPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2Fu aW1hL2N1cnJlbnQvbXNnMDEwNDQuaHRtbCI+DQpodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJj aGl2ZS93ZWIvYW5pbWEvY3VycmVudC9tc2cwMTA0NC5odG1sPC9hPiApIDxicj4NCkkgbW92ZWQg c2VjdGlvbnMgYmFjayBhbmQgZm9ydGgsIHRyeWluZyB0byBmaWd1cmUgb3V0IHRoZSBtb3N0IGxv Z2ljYWwgc3RydWN0dXJlLjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5U aGUgcmVzdWx0IGlzIGEgY29tcGxldGVseSBuZXcsIGJ1dCBob3BlZnVsbHkgYmV0dGVyIHN0cnVj dHVyZWQgb3V0bGluZS48L3NwYW4+PC9iPg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PGZvbnQgc2l6 ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxzcGFu IHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08Zm9udCBzaXplPSIxIiBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+PC9mb250Pjwvc3Bhbj48L3NwYW4+PC9mb250PjwhW2VuZGlmXT5MZXTigJlzIGFn cmVlIG9uIHRoZSBvdXRsaW5lIGZpcnN0LiBEb2VzIHRoaXMgY2FwdHVyZSBhbGwgdGhlIGltcG9y dGFudCBwb2ludHM/DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48Zm9udCBzaXplPSIyIiBmYWNlPSJD YWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+LTxmb250IHNpemU9IjEiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L2Zv bnQ+PC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PCFbZW5kaWZdPlRoZW4sIGJhc2VkIG9uIHRoZSBwcm9w b3NhbHMsIHdlIGxvb2sgYXQgd2hvIHdvcmtzIG91dCB3aGljaCBzZWN0aW9uLCB0byBhdm9pZCBv dmVybGFwLCBhbmQgbWFrZSBzdXJlIHdl4oCZcmUgaW4gc3luYy4gKEnigJlsbCBwcm9wb3NlIHNv bWV0aGluZyB0byBnZXQgc3RhcnRlZCkuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxmb250IHNpemU9IjIiIGZhY2U9 IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Eb2VzIHRoaXMgbWFrZSBz ZW5zZT8NCjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvZm9u dD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxp YnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SWYgc28sIGJlbG93IGlzIHRoZSBu ZXcgc3VnZ2VzdGVkIG91dGxpbmUuIEkgdGhpbmsgaXTigJlzIG1vcmUgbG9naWNhbGx5IG9yZ2Fu aXNlZCBub3c6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21z by1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxmb250IHNpemU9 IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPGZvbnQgc2l6ZT0iMSIgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjwvZm9udD48L3NwYW4+PC9zcGFuPjwvZm9udD48IVtlbmRpZl0+U2VjdGlvbiAyIGdp dmVzIHRoZSBoaWdoIGxldmVsIHZpZXcsIGFzIGZvciBleGFtcGxlIHNvbWVvbmUgd3JpdGluZyBB U0FzIHdvdWxkIG5lZWQgdG8ga25vdy4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21z by1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxmb250IHNpemU9 IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPGZvbnQgc2l6ZT0iMSIgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjwvZm9udD48L3NwYW4+PC9zcGFuPjwvZm9udD48IVtlbmRpZl0+U2VjdGlvbiAzIGlz IHRoZSBhcmNoaXRlY3R1cmUgb2YgYSBzaW5nbGUgbm9kZS4NCjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDt0ZXh0LWluZGVu dDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNd Pjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPGZvbnQgc2l6ZT0iMSIgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOw0KPC9zcGFuPjwvZm9udD48L3NwYW4+PC9zcGFuPjwvZm9udD48IVtlbmRpZl0+ U2VjdGlvbiA0IGlzIHRoZSBBTkkuIFNvIHRoaXMgaXMgdGhlIOKAnGJhc2VsaW5l4oCdIGFuIEFO IG5vZGUgbmVlZHMgdG8gc3VwcG9ydC4gSSBtb3ZlZCB0aGUgQUNQIHNlY3Rpb25zIGludG8gdGhp cyBzZWN0aW9uIG5vdywgYmVjYXVzZSBpdOKAmXMgYmFzZSBsaW5lIHJlYWxseS4NCjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDot MTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48Zm9u dCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08 Zm9udCBzaXplPSIxIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250Ojcu MHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9mb250Pjwvc3Bhbj48L3Nw YW4+PC9mb250PjwhW2VuZGlmXT48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlNlY3Rpb24g NSBkZXNjcmliZXMgc2VjdXJpdHkuIEnigJl2ZSBiZWVuIHB1dHRpbmcgdGhlIHN1Yi1kb21haW4g cXVlc3Rpb24gZXZlbnR1YWxseSB1bmRlcg0KIHRoaXMgaGVhZGluZy4gV2UgYWxzbyBuZWVkIHRv IGRlc2NyaWJlIHRoZSBjZXJ0aWZpY2F0ZSBmb3JtYXQgYXMgd2VsbC4gSeKAmXZlIGFsc28gbW92 ZWQgdGhlIE1BU0EgaW50byB0aGlzIHNlY3Rpb24sIHNpbmNlIGl04oCZcyBhYm91dCB0cnVzdCBh dCB0aGUgZW5kIG9mIHRoZSBkYXkuIChOb3QgMTAwJSBzdXJlIHRoaXMgaXMgdGhlIGJlc3QgcGxh Y2UpLg0KPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlz dDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48Zm9udCBzaXplPSIyIiBm YWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PHNwYW4gc3R5bGU9 Im1zby1saXN0Oklnbm9yZSI+LTxmb250IHNpemU9IjEiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bh bj48L2ZvbnQ+PC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PCFbZW5kaWZdPlNlY3Rpb24gNiBpcyBhYm91 dCB0aGUgQVNBcy4gSeKAmXZlIG5vdyB0YWtlbiBvdXQgdGhlIHJlZ2lzdHJhciBmcm9tIHRoZSDi gJxub2Rlc+KAnSBzZWN0aW9uIGFuZCBtb3ZlZCBpdCBhcyBhIOKAnG11c3QgaW1wbGVtZW504oCd IEFTQSBpbnRvIHRoZSBBU0Egc2VjdGlvbi4gQWxzbyB0aGUgYm9vdHN0cmFwIGZ1bmN0aW9ucyBy ZWFsbHkgYXJlIEFTQXMsIHNvIHRoZXkgYXJlIGluIHRoaXMNCiBzZWN0aW9uIG5vdy4gVGhpcyB3 YXkgd2Uga2VlcCB0aGUgQU5JIOKAnGNsZWFu4oCdLiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7dGV4dC1pbmRlbnQ6LTE4 LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48Zm9u dCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxmb250IHNpemU9IjEiIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PCFbZW5kaWZdPlNlY3Rp b24gNyBpcyBhYm91dCBldmVyeXRoaW5nIE1hbmFnZW1lbnQgYW5kIFByb2dyYW1tYWJpbGl0eS4g SW50ZW50IGJlbG9uZ3MgaW4gaGVyZSwgdGhlIGdlbmVyYWwgZGVzY3JpcHRpb24gb2YgaG93IGFu IEFOIG5ldHdvcmsgaXMgbWFuYWdlZCwgQVBJcywgZGF0YSBtb2RlbHMuDQo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7dGV4 dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9y dExpc3RzXT48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxmb250IHNpemU9IjEi IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PCFb ZW5kaWZdPlNlY3Rpb25zIDggYW5kIDkgYXJlIHVuY2hhbmdlZCBmcm9tIHRoZSBsYXN0IHZlcnNp b24uIChhcGFydCBmcm9tIG51bWJlcmluZyk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDtt c28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48Zm9udCBzaXpl PSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PHNwYW4g c3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxmb250IHNpemU9IjEiIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN Cjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PCFbZW5kaWZdPkFuZCBJIG1hcmtl ZCB0aGUgc2VjdGlvbnMgdGhhdCBhcmUgbm90IGRpcmVjdGx5IGFkZHJlc3NlZCBpbiB0aGUgY3Vy cmVudCBjaGFydGVyLCBidXQgd2hpY2ggd2Ugc2hvdWxkIGF0IGxlYXN0IGNvdmVyIGluIHByaW5j aXBsZSBoZXJlLCB3aXRoIGFuICgqKS4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48 L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0i Q2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyAxLiZu YnNwOyBJbnRyb2R1Y3Rpb24mbmJzcDsgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4mbmJzcDsmbmJzcDsgMzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7IDIuJm5ic3A7IFRoZSBO ZXR3b3JrIFZpZXcmbmJzcDsgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiZuYnNwOyZuYnNwOyAzPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsgMy4mbmJzcDsgVGhlIEF1dG9ub21pYyBO ZXR3b3JrIEVsZW1lbnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiZuYnNwOyZuYnNw OyA0PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi Pjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMy4xLiZuYnNwOyBBcmNoaXRlY3R1cmUmbmJz cDsgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiZuYnNwOyZuYnNw OyA0PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi Pjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMy4yLiZuYnNwOyBVbmNvbnN0cmFpbmVkIEFO IE5vZGVzJm5ic3A7IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiZuYnNwOyZuYnNw OyA1PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi Pjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMy4zLiZuYnNwOyBDb25zdHJhaW5lZCBBTiBO b2RlcyAoKikmbmJzcDsgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiZuYnNwOyZuYnNw OyA2PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi Pjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij4mbmJzcDsmbmJzcDsgNC4mbmJzcDsgVGhlIEF1dG9ub21pYyBOZXR3b3JraW5nIEluZnJh c3RydWN0dXJlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiZuYnNwOyZuYnNwOyA2PG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxmb250IHNpemU9IjIi IGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgNC4xLiZuYnNwOyBOYW1pbmcmbmJzcDsgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiZuYnNwOyZuYnNwOyA2PG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxmb250IHNpemU9IjIi IGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgNC4yLiZuYnNwOyBBZGRyZXNzaW5nJm5ic3A7IC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiZuYnNwOyZuYnNwOyA2PG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxmb250IHNpemU9IjIi IGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgNC4zLiZuYnNwOyBEaXNjb3ZlcnkgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4mbmJzcDsmbmJzcDsgNzxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48Zm9udCBzaXplPSIyIiBmYWNl PSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDQuNC4mbmJzcDsgU2lnbmFsaW5nIGZvciBOZWdvdGlhdGlvbiBhbmQgU3luY2hy b25pemF0aW9uIC4gLiAuIC4gLiAuJm5ic3A7Jm5ic3A7IDg8bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2Fs aWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOzQuNS4mbmJzcDsgSW50ZW50IERpc3RyaWJ1dGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuJm5ic3A7Jm5ic3A7IDg8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA0 LjYuJm5ic3A7IFJvdXRpbmcgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiZuYnNwOyZuYnNwOyA4PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgNC43LiZu YnNwOyBUaGUgQXV0b25vbWljIENvbnRyb2wgUGxhbmUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4mbmJzcDsmbmJzcDsgODxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDQuOC4mbmJzcDsg UmVwb3J0aW5nICgqKSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu Jm5ic3A7Jm5ic3A7IDk8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA0LjkuJm5ic3A7IEZlZWRi YWNrIExvb3BzICgqKSZuYnNwOyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu Jm5ic3A7Jm5ic3A7IDk8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyA1LiZuYnNwOyBTZWN1cml0eSBhbmQgVHJ1c3Qg SW5mcmFzdHJ1Y3R1cmUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuJm5ic3A7Jm5ic3A7IDk8 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGZv bnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA1LjEuJm5ic3A7IFB1YmxpYyBLZXkgSW5mcmFzdHJ1 Y3R1cmUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiZuYnNwOyZuYnNwOyA5PG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxmb250IHNp emU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJz cDsgJm5ic3A7Jm5ic3A7Jm5ic3A7NS4yLiZuYnNwOyBEb21haW4gQ2VydGlmaWNhdGUmbmJzcDsg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiZuYnNwOyZuYnNwOyA5PG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxmb250IHNp emU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgNS4zLiZuYnNwOyBTdWItRG9tYWlucyAoKikgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4mbmJzcDsgMTA8bzpwPjwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGZvbnQgc2l6ZT0iMiIgZmFj ZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyA1LjQuJm5ic3A7IENyb3NzLURvbWFpbiBGdW5jdGlvbmFsaXR5ICgqKSZuYnNw OyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuJm5ic3A7IDEwPG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxmb250IHNpemU9IjIiIGZhY2U9IkNh bGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgNS41LiZuYnNwOyBUaGUgTUFTQSAoKikmbmJzcDsgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiZuYnNwOyAxMDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJp Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7IDYuJm5ic3A7IEF1 dG9ub21pYyBTZXJ2aWNlIEFnZW50cyAoQVNBKSZuYnNwOyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiZuYnNwOyAxMDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDYuMS4mbmJzcDsgR2Vu ZXJhbCBEZXNjcmlwdGlvbiBvZiBhbiBBU0EgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuJm5i c3A7IDEwPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgNi4yLiZuYnNwOyBTcGVjaWZpYyBBU0Fz IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4mbmJzcDsgMTA8bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGZvbnQg c2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu YnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs2LjIuMS4mbmJzcDsgVGhlIEVucm9s bWVudCBBU0EgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4mbmJzcDsgMTA8bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGZvbnQg c2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA2LjIuMi4mbmJzcDsgVGhlIEVucm9s bWVudCBQcm94eSBBU0EgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4mbmJzcDsgMTA8bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGZvbnQg c2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA2LjIuMy4mbmJzcDsgVGhlIFJlZ2lz dHJhciBBU0EgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4mbmJzcDsgMTE8bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGZvbnQg c2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu YnNwOyZuYnNwOyA3LiZuYnNwOyBNYW5hZ2VtZW50IGFuZCBQcm9ncmFtbWFiaWxpdHkmbmJzcDsg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4mbmJzcDsgMTE8bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0i Q2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyA3LjEuJm5ic3A7IEhvdyBhbiBBTiBOZXR3b3JrIElzIE1hbmFnZWQmbmJzcDsgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuJm5ic3A7IDExPG86cD48L286cD48L3NwYW4+PC9mb250 PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGli cmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgNy4yLiZuYnNwOyBJbnRlbnQgKCopJm5ic3A7IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiZuYnNwOyAxMTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDcu My4mbmJzcDsgQVBJcyAoKikmbmJzcDsgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4mbmJzcDsgMTE8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA3LjQuJm5i c3A7IERhdGEgTW9kZWwgKCopJm5ic3A7IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuJm5ic3A7IDExPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsgOC4mbmJzcDsgQ29vcmRpbmF0aW9uIEJl dHdlZW4gQXV0b25vbWljIEZ1bmN0aW9ucyAoKikmbmJzcDsgLiAuIC4gLiAuIC4gLiAuJm5ic3A7 IDExPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi Pjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOC4xLiZuYnNwOyBUaGUgQ29vcmRpbmF0aW9u IFByb2JsZW0gKCopJm5ic3A7IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiZuYnNwOyAxMTxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48Zm9u dCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDguMi4mbmJzcDsgQSBDb29yZGluYXRpb24gRnVuY3Rp b25hbCBCbG9jayAoKikgLiAuIC4gLiAuIC4gLiAuIC4gLiAuJm5ic3A7IDEyPG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxmb250IHNpemU9IjIi IGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJz cDsgOS4mbmJzcDsgSHlicmlkIEFwcHJvYWNoIHdpdGggTm9uLUF1dG9ub21pYyBGdW5jdGlvbnMg KCopJm5ic3A7IC4gLiAuIC4gLiAuJm5ic3A7IDEzPG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmki PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsgMTAuIFNlY3VyaXR5 IENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4mbmJz cDsgMTM8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L2ZvbnQ+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJy aSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkkgaGF2ZSB0aGlzIGluIFhNTCwgd2ls bCBmaXJzdCBhc2sgdGhlIGN1cnJlbnQgY28tYXV0aG9ycyBmb3IgYXBwcm92YWwgdG8gcHVibGlz aCB0aGlzIOKAkyBJIHRoaW5rIGl0IHdvdWxkIGJlIGdvb2QgdG8gaGF2ZSB0aGUgbmV3IG91dGxp bmUgYXMgYSBuZXcgdmVyc2lvbiBhdmFpbGFibGUgdG8gYWxsLg0KIElmIHRoZSBjby1hdXRob3Jz IGFyZSBmaW5lIHdpdGggdGhpcywgSeKAmWxsIHB1Ymxpc2ggKGhvcGVmdWxseSB0b21vcnJvdyku IDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvZm9udD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+RmVlZGJhY2s/IE1vdmluZyBpbiB0aGUgcmln aHQgZGlyZWN0aW9uPw0KPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij5NaWNoYWVsPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9mb250PjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FCA9C1xmbrcdx14ciscoc_-- From nobody Wed Jun 10 09:16:57 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCEC1B3367 for ; Wed, 10 Jun 2015 09:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6cN0B4etnXk for ; Wed, 10 Jun 2015 09:16:53 -0700 (PDT) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) (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 246E21B337E for ; Wed, 10 Jun 2015 09:16:47 -0700 (PDT) Received: by qgfa66 with SMTP id a66so17962239qgf.0 for ; Wed, 10 Jun 2015 09:16:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=YGI+O5YRimRM6OViFV7XmzilIfLh7PEMJuAP2GTy5kw=; b=BF/TVhIuOCg2BlyCCqICYo2uoAPYyq8Gooy5LdHtW6b4x7brfJlDLYZCsWBwBefm9w y/D/qsooRpJ5ksoiKeCa45qHG7iSU/Nb+wArKzlvOR31LMe1gbN22CWbSt149T2pu1re RlECwvbx99o2OA032TC9v7PDadAEox5tZ6hilq2CN4sAMTCVowmxiJ36Pc4fnZtg0Jrk hstsqiFQ7QAQAqSzjJuncI4rdkQ7+8Dgs1eb1uHgzYlTNeeJavPkvWgdAFJybpx2I6/v ZHiUvS68lwi8vtynCWQ6pZmTQyrhfw0shJ2BYGpSn7K+bblOUg2P36hu6Pdw4g6Rr5Zz h9PA== X-Received: by 10.55.15.129 with SMTP id 1mr8350631qkp.29.1433953006242; Wed, 10 Jun 2015 09:16:46 -0700 (PDT) MIME-Version: 1.0 References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FCA9C1@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FCA9C1@xmb-rcd-x14.cisco.com> From: =?UTF-8?Q?J=C3=A9ferson_Campos_Nobre?= Date: Wed, 10 Jun 2015 16:16:35 +0000 Message-ID: To: "Michael Behringer (mbehring)" , Anima WG Content-Type: multipart/alternative; boundary=001a1146f1008fd30305182c33a5 Archived-At: Subject: Re: [Anima] Reference document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jun 2015 16:16:56 -0000 --001a1146f1008fd30305182c33a5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Michael. The structure looks good. Just a clarification: in Section 7, intent will be described in high level, right? I am saying this because I think it is necessary a new I-D for the intent description. Cheers. J=C3=A9ferson Em qua, 10 de jun de 2015 =C3=A0s 09:14, Michael Behringer (mbehring) < mbehring@cisco.com> escreveu: > Thanks for all the volunteers to help with the doc here. In fact, I=E2= =80=99m > having a bit of a hard time figuring out how to move forward, because the= re > are several overlapping editing suggestions, and the document structure > doesn=E2=80=99t take the latest discussions into account. > > > > Here is what I=E2=80=99ve done now: > > - I worked all the open points into the *outline* of the documen= t > (most of them from > http://www.ietf.org/mail-archive/web/anima/current/msg01044.html ) > I moved sections back and forth, trying to figure out the most logical > structure. > *The result is a completely new, but hopefully better structured outline.= * > > - Let=E2=80=99s agree on the outline first. Does this capture al= l the > important points? > > - Then, based on the proposals, we look at who works out which > section, to avoid overlap, and make sure we=E2=80=99re in sync. (I=E2=80= =99ll propose > something to get started). > > > > Does this make sense? > > > > If so, below is the new suggested outline. I think it=E2=80=99s more logi= cally > organised now: > > - Section 2 gives the high level view, as for example someone > writing ASAs would need to know. > > - Section 3 is the architecture of a single node. > > - Section 4 is the ANI. So this is the =E2=80=9Cbaseline=E2=80= =9D an AN node > needs to support. I moved the ACP sections into this section now, because > it=E2=80=99s base line really. > > - Section 5 describes security. I=E2=80=99ve been putting the su= b-domain > question eventually under this heading. We also need to describe the > certificate format as well. I=E2=80=99ve also moved the MASA into this se= ction, > since it=E2=80=99s about trust at the end of the day. (Not 100% sure this= is the > best place). > > - Section 6 is about the ASAs. I=E2=80=99ve now taken out the re= gistrar > from the =E2=80=9Cnodes=E2=80=9D section and moved it as a =E2=80=9Cmust = implement=E2=80=9D ASA into the > ASA section. Also the bootstrap functions really are ASAs, so they are in > this section now. This way we keep the ANI =E2=80=9Cclean=E2=80=9D. > > - Section 7 is about everything Management and Programmability. > Intent belongs in here, the general description of how an AN network is > managed, APIs, data models. > > - Sections 8 and 9 are unchanged from the last version. (apart > from numbering) > > - And I marked the sections that are not directly addressed in > the current charter, but which we should at least cover in principle here= , > with an (*). > > > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 > > 2. The Network View . . . . . . . . . . . . . . . . . . . . . . 3 > > 3. The Autonomic Network Element . . . . . . . . . . . . . . . . 4 > > 3.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 4 > > 3.2. Unconstrained AN Nodes . . . . . . . . . . . . . . . . . 5 > > 3.3. Constrained AN Nodes (*) . . . . . . . . . . . . . . . . 6 > > 4. The Autonomic Networking Infrastructure . . . . . . . . . . . 6 > > 4.1. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 6 > > 4.2. Addressing . . . . . . . . . . . . . . . . . . . . . . . 6 > > 4.3. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 7 > > 4.4. Signaling for Negotiation and Synchronization . . . . . . 8 > > 4.5. Intent Distribution . . . . . . . . . . . . . . . . . . . 8 > > 4.6. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 8 > > 4.7. The Autonomic Control Plane . . . . . . . . . . . . . . . 8 > > 4.8. Reporting (*) . . . . . . . . . . . . . . . . . . . . . . 9 > > 4.9. Feedback Loops (*) . . . . . . . . . . . . . . . . . . . 9 > > 5. Security and Trust Infrastructure . . . . . . . . . . . . . . 9 > > 5.1. Public Key Infrastructure . . . . . . . . . . . . . . . . 9 > > 5.2. Domain Certificate . . . . . . . . . . . . . . . . . . . 9 > > 5.3. Sub-Domains (*) . . . . . . . . . . . . . . . . . . . . . 10 > > 5.4. Cross-Domain Functionality (*) . . . . . . . . . . . . . 10 > > 5.5. The MASA (*) . . . . . . . . . . . . . . . . . . . . . . 10 > > 6. Autonomic Service Agents (ASA) . . . . . . . . . . . . . . . 10 > > 6.1. General Description of an ASA . . . . . . . . . . . . . . 10 > > 6.2. Specific ASAs . . . . . . . . . . . . . . . . . . . . . . 10 > > 6.2.1. The Enrolment ASA . . . . . . . . . . . . . . . . . . 10 > > 6.2.2. The Enrolment Proxy ASA . . . . . . . . . . . . . . . 10 > > 6.2.3. The Registrar ASA . . . . . . . . . . . . . . . . . . 11 > > 7. Management and Programmability . . . . . . . . . . . . . . . 11 > > 7.1. How an AN Network Is Managed . . . . . . . . . . . . . . 11 > > 7.2. Intent (*) . . . . . . . . . . . . . . . . . . . . . . . 11 > > 7.3. APIs (*) . . . . . . . . . . . . . . . . . . . . . . . . 11 > > 7.4. Data Model (*) . . . . . . . . . . . . . . . . . . . . . 11 > > 8. Coordination Between Autonomic Functions (*) . . . . . . . . 11 > > 8.1. The Coordination Problem (*) . . . . . . . . . . . . . . 11 > > 8.2. A Coordination Functional Block (*) . . . . . . . . . . . 12 > > 9. Hybrid Approach with Non-Autonomic Functions (*) . . . . . . 13 > > 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 > > > > I have this in XML, will first ask the current co-authors for approval to > publish this =E2=80=93 I think it would be good to have the new outline a= s a new > version available to all. If the co-authors are fine with this, I=E2=80= =99ll > publish (hopefully tomorrow). > > > > Feedback? Moving in the right direction? > > Michael > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > --001a1146f1008fd30305182c33a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Michael.
The structure looks good.
Just a c= larification: in Section 7, intent will be described in high level, right? = I am saying this because I think it is necessary a new I-D for the intent d= escription.
Cheers.
J=C3=A9ferson

<= div>
Em qua, 10 de jun de 2015 = =C3=A0s 09:14, Michael Behringer (mbehring) <mbehring@cisco.com> escreveu:

Thank= s for all the volunteers to help with the doc here. In fact, I=E2=80=99m ha= ving a bit of a hard time figuring out how to move forward, because there a= re several overlapping editing suggestions, and the document structure doesn=E2=80=99t take the latest di= scussions into account.

=C2=A0

Here = is what I=E2=80=99ve done now:

<= span>-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 I worked all the open points into= the outline of the document
(most of them from http://www.ietf.org/mail-archive/web/anima/current/msg01044.html )
I moved sections back and forth, trying to figure out the most logical stru= cture.
The result is a completely new, but hop= efully better structured outline.

<= span>-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Let=E2=80=99s agree on the outlin= e first. Does this capture all the important points?

<= span>-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Then, based on the proposals, we = look at who works out which section, to avoid overlap, and make sure we=E2= =80=99re in sync. (I=E2=80=99ll propose something to get started).

=C2=A0

Does = this make sense?

=C2=A0

If so= , below is the new suggested outline. I think it=E2=80=99s more logically o= rganised now:

<= span>-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Section 2 gives the high level vi= ew, as for example someone writing ASAs would need to know.

<= span>-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Section 3 is the architecture of = a single node.

<= span>-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Section 4 is the ANI. So this is = the =E2=80=9Cbaseline=E2=80=9D an AN node needs to support. I moved the ACP= sections into this section now, because it=E2=80=99s base line really.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Section 5 describes security. I=E2=80=99ve been putting the s= ub-domain question eventually under this heading. We also need to describe the certificate format as well. I= =E2=80=99ve also moved the MASA into this section, since it=E2=80=99s about= trust at the end of the day. (Not 100% sure this is the best place).

<= span>-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Section 6 is about the ASAs. I=E2= =80=99ve now taken out the registrar from the =E2=80=9Cnodes=E2=80=9D secti= on and moved it as a =E2=80=9Cmust implement=E2=80=9D ASA into the ASA sect= ion. Also the bootstrap functions really are ASAs, so they are in this section now. This way we keep the ANI =E2=80=9Cclean=E2=80=9D. <= /u>

<= span>-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Section 7 is about everything Man= agement and Programmability. Intent belongs in here, the general descriptio= n of how an AN network is managed, APIs, data models.

<= span>-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Sections 8 and 9 are unchanged fr= om the last version. (apart from numbering)

<= span>-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 And I marked the sections that ar= e not directly addressed in the current charter, but which we should at lea= st cover in principle here, with an (*).

=C2=A0

=C2= =A0=C2=A0 1.=C2=A0 Introduction=C2=A0 . . . . . . . . . . . . . . . . . . .= . . . . .=C2=A0=C2=A0 3

=C2= =A0=C2=A0 2.=C2=A0 The Network View=C2=A0 . . . . . . . . . . . . . . . . .= . . . . .=C2=A0=C2=A0 3

=C2= =A0=C2=A0 3.=C2=A0 The Autonomic Network Element . . . . . . . . . . . . . = . . .=C2=A0=C2=A0 4

=C2= =A0=C2=A0=C2=A0=C2=A0 3.1.=C2=A0 Architecture=C2=A0 . . . . . . . . . . . .= . . . . . . . . . .=C2=A0=C2=A0 4

=C2= =A0=C2=A0=C2=A0=C2=A0 3.2.=C2=A0 Unconstrained AN Nodes=C2=A0 . . . . . . .= . . . . . . . . . .=C2=A0=C2=A0 5

=C2= =A0=C2=A0=C2=A0=C2=A0 3.3.=C2=A0 Constrained AN Nodes (*)=C2=A0 . . . . . .= . . . . . . . . . .=C2=A0=C2=A0 6

=C2= =A0=C2=A0 4.=C2=A0 The Autonomic Networking Infrastructure . . . . . . . . = . . .=C2=A0=C2=A0 6

=C2= =A0=C2=A0=C2=A0=C2=A0 4.1.=C2=A0 Naming=C2=A0 . . . . . . . . . . . . . . .= . . . . . . . . . .=C2=A0=C2=A0 6

=C2= =A0=C2=A0=C2=A0=C2=A0 4.2.=C2=A0 Addressing=C2=A0 . . . . . . . . . . . . .= . . . . . . . . . .=C2=A0=C2=A0 6

=C2= =A0=C2=A0=C2=A0=C2=A0 4.3.=C2=A0 Discovery . . . . . . . . . . . . . . . . = . . . . . . . .=C2=A0=C2=A0 7

=C2= =A0=C2=A0=C2=A0=C2=A0 4.4.=C2=A0 Signaling for Negotiation and Synchronizat= ion . . . . . .=C2=A0=C2=A0 8

=C2= =A0=C2=A0=C2=A0=C2=A04.5.=C2=A0 Intent Distribution . . . . . . . . . . . .= . . . . . . .=C2=A0=C2=A0 8

=C2= =A0=C2=A0=C2=A0=C2=A0 4.6.=C2=A0 Routing . . . . . . . . . . . . . . . . . = . . . . . . . .=C2=A0=C2=A0 8

=C2= =A0=C2=A0=C2=A0=C2=A0 4.7.=C2=A0 The Autonomic Control Plane . . . . . . . = . . . . . . . .=C2=A0=C2=A0 8

=C2= =A0=C2=A0=C2=A0=C2=A0 4.8.=C2=A0 Reporting (*) . . . . . . . . . . . . . . = . . . . . . . .=C2=A0=C2=A0 9

=C2= =A0=C2=A0=C2=A0=C2=A0 4.9.=C2=A0 Feedback Loops (*)=C2=A0 . . . . . . . . .= . . . . . . . . . .=C2=A0=C2=A0 9

=C2= =A0=C2=A0 5.=C2=A0 Security and Trust Infrastructure . . . . . . . . . . . = . . .=C2=A0=C2=A0 9

=C2= =A0=C2=A0=C2=A0=C2=A0 5.1.=C2=A0 Public Key Infrastructure . . . . . . . . = . . . . . . . .=C2=A0=C2=A0 9

=C2= =A0 =C2=A0=C2=A0=C2=A05.2.=C2=A0 Domain Certificate=C2=A0 . . . . . . . . .= . . . . . . . . . .=C2=A0=C2=A0 9

=C2= =A0=C2=A0=C2=A0=C2=A0 5.3.=C2=A0 Sub-Domains (*) . . . . . . . . . . . . . = . . . . . . . .=C2=A0 10

=C2= =A0=C2=A0=C2=A0=C2=A0 5.4.=C2=A0 Cross-Domain Functionality (*)=C2=A0 . . .= . . . . . . . . . .=C2=A0 10

=C2= =A0=C2=A0=C2=A0=C2=A0 5.5.=C2=A0 The MASA (*)=C2=A0 . . . . . . . . . . . .= . . . . . . . . . .=C2=A0 10

=C2= =A0=C2=A0 6.=C2=A0 Autonomic Service Agents (ASA)=C2=A0 . . . . . . . . . .= . . . . .=C2=A0 10

=C2= =A0=C2=A0=C2=A0=C2=A0 6.1.=C2=A0 General Description of an ASA . . . . . . = . . . . . . . .=C2=A0 10

=C2= =A0=C2=A0=C2=A0=C2=A0 6.2.=C2=A0 Specific ASAs . . . . . . . . . . . . . . = . . . . . . . .=C2=A0 10

=C2= =A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A06.2.1.=C2=A0 The Enrolment ASA . . . . . = . . . . . . . . . . . . .=C2=A0 10

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 6.2.2.=C2=A0 The Enrolment Proxy ASA . . = . . . . . . . . . . . . .=C2=A0 10

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 6.2.3.=C2=A0 The Registrar ASA . . . . . = . . . . . . . . . . . . .=C2=A0 11

=C2= =A0=C2=A0 7.=C2=A0 Management and Programmability=C2=A0 . . . . . . . . . .= . . . . .=C2=A0 11

=C2= =A0=C2=A0=C2=A0=C2=A0 7.1.=C2=A0 How an AN Network Is Managed=C2=A0 . . . .= . . . . . . . . . .=C2=A0 11

=C2= =A0=C2=A0=C2=A0=C2=A0 7.2.=C2=A0 Intent (*)=C2=A0 . . . . . . . . . . . . .= . . . . . . . . . .=C2=A0 11

=C2= =A0=C2=A0=C2=A0=C2=A0 7.3.=C2=A0 APIs (*)=C2=A0 . . . . . . . . . . . . . .= . . . . . . . . . .=C2=A0 11

=C2= =A0=C2=A0=C2=A0=C2=A0 7.4.=C2=A0 Data Model (*)=C2=A0 . . . . . . . . . . .= . . . . . . . . . .=C2=A0 11

=C2= =A0=C2=A0 8.=C2=A0 Coordination Between Autonomic Functions (*)=C2=A0 . . .= . . . . .=C2=A0 11

=C2= =A0=C2=A0=C2=A0=C2=A0 8.1.=C2=A0 The Coordination Problem (*)=C2=A0 . . . .= . . . . . . . . . .=C2=A0 11

=C2= =A0=C2=A0=C2=A0=C2=A0 8.2.=C2=A0 A Coordination Functional Block (*) . . . = . . . . . . . .=C2=A0 12

=C2= =A0=C2=A0 9.=C2=A0 Hybrid Approach with Non-Autonomic Functions (*)=C2=A0 .= . . . . .=C2=A0 13

=C2= =A0=C2=A0 10. Security Considerations . . . . . . . . . . . . . . . . . . .= =C2=A0 13

=C2=A0

I hav= e this in XML, will first ask the current co-authors for approval to publis= h this =E2=80=93 I think it would be good to have the new outline as a new = version available to all. If the co-authors are fine with this, I=E2=80=99ll publish (hopefully tomo= rrow).

=C2=A0

Feedb= ack? Moving in the right direction?

Micha= el

=C2=A0

_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
--001a1146f1008fd30305182c33a5-- From nobody Wed Jun 10 09:22:30 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E53E1B33A4 for ; Wed, 10 Jun 2015 09:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.21 X-Spam-Level: X-Spam-Status: No, score=-14.21 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, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuwSo1mVKUrg for ; Wed, 10 Jun 2015 09:22:27 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5D701B33A2 for ; Wed, 10 Jun 2015 09:22:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9504; q=dns/txt; s=iport; t=1433953348; x=1435162948; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=jcFRIt/BqC9u7HcSdB9Od6uECmjX+Rg1VNfsZ1XyWxI=; b=TP1+JcsNg8lpuuPEr7k6Nw6fpAN4SOO+JzGiDQ7NXIa9J/mKwVJIqJNU gdcZVnb2aPgtYBvOeHtIPt03n9FEX4ECat7wTX0hJbpdtVwsdC8AUlggr BEox1jAOfUKosuJ5GUUf1LWvxORsWNQtIWkeGSrZcbOBb09knE/VrCkph k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CrBQAAZHhV/5tdJa1cgkVLVF8Ggxi6Bm+HWwIcgR06EgEBAQEBAQGBCoQiAQEBAQMjClwCAQgRBAEBCx0DAgICMBQJCAEBBAESCIgmrTukKgEBAQEBAQEBAQEBAQEBAQEBAQEBAReLQ4RVNwGCaC+BFgWQe4JPozEkg3hvgUaBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,588,1427760000"; d="scan'208,217";a="158012260" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP; 10 Jun 2015 16:22:16 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t5AGMFjk022516 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Jun 2015 16:22:15 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.238]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Wed, 10 Jun 2015 11:22:15 -0500 From: "Michael Behringer (mbehring)" To: =?utf-8?B?SsOpZmVyc29uIENhbXBvcyBOb2JyZQ==?= , "Anima WG" Thread-Topic: [Anima] Reference document Thread-Index: AdCjcu1GZJrMma3NQjymMMAjjn5BfAAT826AAAprYqA= Date: Wed, 10 Jun 2015 16:22:14 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FCAC7D@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FCA9C1@xmb-rcd-x14.cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.141] Content-Type: multipart/alternative; boundary="_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FCAC7Dxmbrcdx14ciscoc_" MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Reference document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jun 2015 16:22:29 -0000 --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FCAC7Dxmbrcdx14ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogSsOpZmVyc29uIENhbXBvcyBOb2JyZSBbbWFpbHRvOmpjbm9icmVAaW5mLnVmcmdzLmJy XQ0KU2VudDogMTAgSnVuZSAyMDE1IDE4OjE3DQpUbzogTWljaGFlbCBCZWhyaW5nZXIgKG1iZWhy aW5nKTsgQW5pbWEgV0cNClN1YmplY3Q6IFJlOiBbQW5pbWFdIFJlZmVyZW5jZSBkb2N1bWVudA0K DQpIaSBNaWNoYWVsLg0KVGhlIHN0cnVjdHVyZSBsb29rcyBnb29kLg0KSnVzdCBhIGNsYXJpZmlj YXRpb246IGluIFNlY3Rpb24gNywgaW50ZW50IHdpbGwgYmUgZGVzY3JpYmVkIGluIGhpZ2ggbGV2 ZWwsIHJpZ2h0PyBJIGFtIHNheWluZyB0aGlzIGJlY2F1c2UgSSB0aGluayBpdCBpcyBuZWNlc3Nh cnkgYSBuZXcgSS1EIGZvciB0aGUgaW50ZW50IGRlc2NyaXB0aW9uLg0KQ2hlZXJzLg0KSsOpZmVy c29uDQoNCg0KT2ggeWVzLCBmb3Igc3VyZSEhIEluIGZhY3QgbW9zdCBzZWN0aW9ucyB3aWxsIGp1 c3QgZXhwbGFpbiB0aGUgY29uY2VwdCwgYW5kIHBvaW50IHRvIHRoZSBkZXRhaWxlZCBkb2N1bWVu dHMuIExpa2UsIHNpZ25hbGxpbmcgcG9pbnRzIHRvIEdETlAsIHRoZSBBQ1AgcG9pbnRzIHRvIHRo ZSBBQ1AgZHJhZnQsIGV0Yy4gV2hhdOKAmXMgaW1wb3J0YW50IHRvIGNvbWUgb3V0IGlzIHRoYXQg SW50ZW50IGlzIG9uZSB3YXkgdG8gaW5mbHVlbmNlIHRoZSBiZWhhdmlvdXIgb2YgYW4gYXV0b25v bWljIG5vZGUuIEhvdyB0aGlzIHdvcmtzIG5lZWRzIHRvIGJlIHNob3duLCBoaWdoIGxldmVsLg0K DQpUaGUgb3ZlcmFsbCBnb2FsIGlzIHRvIHNob3cgaG93IGFsbCB0aG9zZSBkcmFmdHMgYW5kIHdv cmsgaXRlbXMgZml0IHRvZ2V0aGVyLg0KDQpNaWNoYWVsDQoNCg0K --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FCAC7Dxmbrcdx14ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3 Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxm b250IHNpemU9IjIiIGZhY2U9IlRhaG9tYSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2ZvbnQtd2VpZ2h0OmJvbGQiPkZyb206PC9zcGFuPjwvZm9udD48L2I+PGZvbnQg c2l6ZT0iMiIgZmFjZT0iVGFob21hIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPg0KIErDqWZlcnNvbiBDYW1wb3MgTm9icmUgW21haWx0bzpqY25vYnJlQGluZi51ZnJn cy5icl0gPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlNlbnQ6PC9zcGFu PjwvYj4gMTAgSnVuZSAyMDE1IDE4OjE3PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0 OmJvbGQiPlRvOjwvc3Bhbj48L2I+IE1pY2hhZWwgQmVocmluZ2VyIChtYmVocmluZyk7IEFuaW1h IFdHPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6PC9zcGFu PjwvYj4gUmU6IFtBbmltYV0gUmVmZXJlbmNlIGRvY3VtZW50PG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQg c2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+SGkgTWljaGFlbC48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlRoZSBzdHJ1Y3R1cmUgbG9va3MgZ29vZC48 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPkp1c3QgYSBjbGFyaWZpY2F0aW9uOiBpbiBTZWN0aW9uIDcsIGludGVudCB3 aWxsIGJlIGRlc2NyaWJlZCBpbiBoaWdoIGxldmVsLCByaWdodD8gSSBhbSBzYXlpbmcgdGhpcyBi ZWNhdXNlIEkgdGhpbmsgaXQgaXMgbmVjZXNzYXJ5IGEgbmV3IEktRCBmb3IgdGhlIGludGVudCBk ZXNjcmlwdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Q2hlZXJzLjxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MTAuNXB0Ij48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Kw6lmZXJzb248Zm9udCBjb2xvcj0iIzFm NDk3ZCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u dD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIi IGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJD YWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250 IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T2ggeWVzLCBmb3Igc3VyZSEhIEluIGZhY3QgbW9z dCBzZWN0aW9ucyB3aWxsIGp1c3QgZXhwbGFpbiB0aGUgY29uY2VwdCwgYW5kIHBvaW50IHRvIHRo ZSBkZXRhaWxlZCBkb2N1bWVudHMuIExpa2UsDQogc2lnbmFsbGluZyBwb2ludHMgdG8gR0ROUCwg dGhlIEFDUCBwb2ludHMgdG8gdGhlIEFDUCBkcmFmdCwgZXRjLiBXaGF04oCZcyBpbXBvcnRhbnQg dG8gY29tZSBvdXQgaXMgdGhhdCBJbnRlbnQgaXMgb25lIHdheSB0byBpbmZsdWVuY2UgdGhlIGJl aGF2aW91ciBvZiBhbiBhdXRvbm9taWMgbm9kZS4gSG93IHRoaXMgd29ya3MgbmVlZHMgdG8gYmUg c2hvd24sIGhpZ2ggbGV2ZWwuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJp Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9 IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIG92ZXJhbGwgZ29hbCBpcyB0byBzaG93IGhvdyBhbGwg dGhvc2UgZHJhZnRzIGFuZCB3b3JrIGl0ZW1zIGZpdCB0b2dldGhlci4NCjxvOnA+PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xv cj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJy aSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1pY2hhZWw8bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6 ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZh Y2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FCAC7Dxmbrcdx14ciscoc_-- From nobody Wed Jun 10 09:41:32 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 886FC1A8A20 for ; Wed, 10 Jun 2015 09:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWdOmP1ZSb9L for ; Wed, 10 Jun 2015 09:41:30 -0700 (PDT) Received: from mail-qk0-f176.google.com (mail-qk0-f176.google.com [209.85.220.176]) (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 796891A8A01 for ; Wed, 10 Jun 2015 09:41:30 -0700 (PDT) Received: by qkhq76 with SMTP id q76so28035425qkh.2 for ; Wed, 10 Jun 2015 09:41:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=SvUraN8SvPHU0T5s0vjILteP/wTc6F4UezO/2dpnkcs=; b=XJ5LJWgVxdXHR+Jd+W834QxTon/U/C7rqObFuHyU5Lm28UaVb74LfRzohwakpWlApz u396pGzj1F8HvGWXtDJvYY+y36yxBlMbnxyvRZO8eKiAoktd/odQ+xeWe+VSkpyv+7ff i1g332FK9VNDzZ9BRUuf8zpRvfanX+9aW/ZoNluSRWZYII+FhagWXGLIxVfBOn4oMa3+ /Rraheobka7pyk3TsogggZZGV4KznqIjHpCOLpjtLcIta0velBPQBoqukEy9TeyL+Xqn UMr/J15iHWa0b8VHgEFM42p5SMc786QgGOm8ONfY+dRBZK2xjf388CqculVWbjg5jMKw qeig== X-Received: by 10.55.15.129 with SMTP id 1mr8639568qkp.29.1433954488805; Wed, 10 Jun 2015 09:41:28 -0700 (PDT) MIME-Version: 1.0 References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FCA9C1@xmb-rcd-x14.cisco.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FCAC7D@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FCAC7D@xmb-rcd-x14.cisco.com> From: =?UTF-8?Q?J=C3=A9ferson_Campos_Nobre?= Date: Wed, 10 Jun 2015 16:41:17 +0000 Message-ID: To: "Michael Behringer (mbehring)" , Anima WG Content-Type: multipart/alternative; boundary=001a1146f100ee0f6f05182c8bcb Archived-At: Subject: Re: [Anima] Reference document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jun 2015 16:41:31 -0000 --001a1146f100ee0f6f05182c8bcb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Michael. Great, this what I had in mind, just want to make sure. Cheers. J=C3=A9ferson Em qua, 10 de jun de 2015 =C3=A0s 13:22, Michael Behringer (mbehring) < mbehring@cisco.com> escreveu: > *From:* J=C3=A9ferson Campos Nobre [mailto:jcnobre@inf.ufrgs.br] > *Sent:* 10 June 2015 18:17 > *To:* Michael Behringer (mbehring); Anima WG > *Subject:* Re: [Anima] Reference document > > > > Hi Michael. > > The structure looks good. > > Just a clarification: in Section 7, intent will be described in high > level, right? I am saying this because I think it is necessary a new I-D > for the intent description. > > Cheers. > > J=C3=A9ferson > > Oh yes, for sure!! In fact most sections will just explain the concept, > and point to the detailed documents. Like, signalling points to GDNP, the > ACP points to the ACP draft, etc. What=E2=80=99s important to come out is= that > Intent is one way to influence the behaviour of an autonomic node. How th= is > works needs to be shown, high level. > > The overall goal is to show how all those drafts and work items fit > together. > > Michael > --001a1146f100ee0f6f05182c8bcb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Michael.
Great, this what I had in mind,= just want to make sure.
Cheers.
J=C3=A9ferson
Em qua, 10 de jun de 2015 = =C3=A0s 13:22, Michael Behringer (mbehring) <mbehring@cisco.com> escreveu:

From: J=C3=A9ferson Campos Nobre [mailto:jcnobre@inf.ufrgs.br]
Sent: 10 June 2015 18:17
To: Michael Behringer (mbehr= ing); Anima WG
Subject: Re: [Anima] Referen= ce document

=C2=A0

Hi Michael.

The structure looks good.

Just a clarification: in Section 7, intent will be d= escribed in high level, right? I am saying this because I think it is neces= sary a new I-D for the intent description.

Cheers.

J=C3=A9ferson<= /font>

= Oh yes, for sure!! In fact most sections will ju= st explain the concept, and point to the detailed documents. Like, signalling points to GDNP, the ACP points to the ACP draft, etc. What=E2= =80=99s important to come out is that Intent is one way to influence the be= haviour of an autonomic node. How this works needs to be shown, high level.=

= The overall goal is to show how all those drafts= and work items fit together.

= Michael



=C2=A0
--001a1146f100ee0f6f05182c8bcb-- From nobody Thu Jun 11 07:21:39 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACEED1B29D6 for ; Thu, 11 Jun 2015 07:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KG1-wRr8cgYM for ; Thu, 11 Jun 2015 07:21:35 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 985331B29CB for ; Thu, 11 Jun 2015 07:21:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2464; q=dns/txt; s=iport; t=1434032495; x=1435242095; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=jbHvvFfPMD9P693UEVXm4GqRfsaG8sqb/7p6K8FrwMo=; b=I0GqYYM2oG/q97/GA1txkbsbzMaIviiA29o+6CWVnYf6qSUYvCBwBdao +o6goWiBDaq0Hrb974uFZKMkF1y4dj6Wc1ym3qdfnMjmX9iQwjAzmpYOp NKXMLdaQnZMm3MkeRYO0+1pqHpGjfonYh00z4Pd3vY6r/dXheEIsu3dDi o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CjBAD1l3lV/4UNJK1cgxBUXwaDGLlUZgmBY4V4AhyBIDgUAQEBAQEBAYEKhCIBAQEBAyMRPgUOBAIBCBEEAQEDAgYdAwICAjAUAQYBAQUDAgQTCBOIFA2vVKQ7AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhiiKELSg4BoJiL4EWBYt3h1uER4ghQINAklEkg3hvAYECQ4EBAQEB X-IronPort-AV: E=Sophos;i="5.13,595,1427760000"; d="scan'208";a="6403040" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-3.cisco.com with ESMTP; 11 Jun 2015 14:21:34 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t5BELYlB001736 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 11 Jun 2015 14:21:34 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.238]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Thu, 11 Jun 2015 09:21:34 -0500 From: "Michael Behringer (mbehring)" To: Anima WG Thread-Topic: New Version Notification for draft-behringer-anima-reference-model-02.txt Thread-Index: AQHQpFGPiIqZ9PMqvUus6olJUcjipJ2nWqtQ Date: Thu, 11 Jun 2015 14:21:34 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FCC624@xmb-rcd-x14.cisco.com> References: <20150611141853.17617.90411.idtracker@ietfa.amsl.com> In-Reply-To: <20150611141853.17617.90411.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.141] 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-behringer-anima-reference-model-02.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jun 2015 14:21:38 -0000 SGVyZSB0aGUgbmV3IHZlcnNpb24sIGFzIGRpc2N1c3NlZC4gDQoNCk1pY2hhZWwNCg0KPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcg W21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+IFNlbnQ6IDExIEp1bmUgMjAxNSAx NjoxOQ0KPiBUbzogTGF1cmVudCBDaWF2YWdsaWE7IFRvZXJsZXNzIEVja2VydCAoZWNrZXJ0KTsg TWljaGFlbCBCZWhyaW5nZXINCj4gKG1iZWhyaW5nKTsgQnJpYW4gRS4gQ2FycGVudGVyOyBMYXVy ZW50IENpYXZhZ2xpYTsgTWljaGFlbCBCZWhyaW5nZXINCj4gKG1iZWhyaW5nKTsgQmluZyBMaXU7 IEJyaWFuIENhcnBlbnRlcjsgVG9lcmxlc3MgRWNrZXJ0IChlY2tlcnQpOyBCaW5nIExpdQ0KPiBT dWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWJlaHJpbmdlci1hbmlt YS1yZWZlcmVuY2UtDQo+IG1vZGVsLTAyLnR4dA0KPiANCj4gDQo+IEEgbmV3IHZlcnNpb24gb2Yg SS1ELCBkcmFmdC1iZWhyaW5nZXItYW5pbWEtcmVmZXJlbmNlLW1vZGVsLTAyLnR4dA0KPiBoYXMg YmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IE1pY2hhZWwgSC4gQmVocmluZ2VyIGFuZCBw b3N0ZWQgdG8gdGhlDQo+IElFVEYgcmVwb3NpdG9yeS4NCj4gDQo+IE5hbWU6CQlkcmFmdC1iZWhy aW5nZXItYW5pbWEtcmVmZXJlbmNlLW1vZGVsDQo+IFJldmlzaW9uOgkwMg0KPiBUaXRsZToJCUEg UmVmZXJlbmNlIE1vZGVsIGZvciBBdXRvbm9taWMgTmV0d29ya2luZw0KPiBEb2N1bWVudCBkYXRl OgkyMDE1LTA2LTExDQo+IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+IFBhZ2VzOgkJ MTYNCj4gVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1iZWhyaW5nZXItYW5pbWEtcmVmZXJlbmNlLW1vZGVsLTAyLnR4dA0KPiBTdGF0dXM6 ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYmVocmluZ2Vy LWFuaW1hLXJlZmVyZW5jZS1tb2RlbC8NCj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1iZWhyaW5nZXItYW5pbWEtcmVmZXJlbmNlLW1vZGVsLTAyDQo+ IERpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt YmVocmluZ2VyLWFuaW1hLXJlZmVyZW5jZS1tb2RlbC0wMg0KPiANCj4gQWJzdHJhY3Q6DQo+ICAg IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgcmVmZXJlbmNlIG1vZGVsIGZvciBBdXRvbm9taWMg TmV0d29ya2luZy4NCj4gICAgVGhlIGdvYWwgaXMgdG8gZGVmaW5lIGhvdyB0aGUgdmFyaW91cyBl bGVtZW50cyBpbiBhbiBhdXRvbm9taWMNCj4gICAgY29udGV4dCB3b3JrIHRvZ2V0aGVyLCB0byBk ZXNjcmliZSB0aGVpciBpbnRlcmZhY2VzIGFuZCByZWxhdGlvbnMuDQo+ICAgIFdoaWxlIHRoZSBk b2N1bWVudCBpcyB3cml0dGVuIGFzIGdlbmVyYWxseSBhcyBwb3NzaWJsZSwgdGhlIGluaXRpYWwN Cj4gICAgc29sdXRpb25zIGFyZSBsaW1pdGVkIHRvIHRoZSBjaGFydGVyZWQgc2NvcGUgb2YgdGhl IFdHLg0KPiANCj4gDQo+IA0KPiANCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gc3VibWlzc2lvbiB1bnRpbCB0aGUg aHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3Jn Lg0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Thu Jun 11 07:24:52 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E59601B29DA for ; Thu, 11 Jun 2015 07:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0S6PjEa-oJdo for ; Thu, 11 Jun 2015 07:24:49 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F2AF1AD379 for ; Thu, 11 Jun 2015 07:24:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1877; q=dns/txt; s=iport; t=1434032689; x=1435242289; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=asjCIgmOImoo+bbNOtPujEoppxwQhh+v6GwTq8JcjPk=; b=MwfyIQCHnE9OIlBCPjRwN+v8l3jwaceNZcUpa6KZRiDqLPcVf92L0cqn f9A/MQXlvxoBOIhoGWdwdb+AM3CJ20EINdjcWEyhu2avajRBjRqPOyDR5 57Ylbm7e0uNn+IfMDodO8Omzn4+Qr/rc6zw49yvi2TuUSPUkWWTdw7IN1 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BhBABbmXlV/5tdJa1cgxCBObxsZgmHWwKBPDgUAQEBAQEBAYEKhCQBAQM6UQEqFEImAQQbiCegArQaAQEBBwEBAQEei0OEVYNPgRYFhReOO4kcg0yHBIdVhB2DWySCChyBUoI1gQEBAQE X-IronPort-AV: E=Sophos;i="5.13,595,1427760000"; d="scan'208";a="158401658" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP; 11 Jun 2015 14:24:48 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t5BEOmh7000465 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 11 Jun 2015 14:24:48 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.238]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Thu, 11 Jun 2015 09:24:48 -0500 From: "Michael Behringer (mbehring)" To: Anima WG Thread-Topic: Reference doc - who helps where Thread-Index: AdCkPpvDq/REH/c/QD6jsqABU9g+LA== Date: Thu, 11 Jun 2015 14:24:47 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FCC640@xmb-rcd-x14.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.141] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Anima] Reference doc - who helps where X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jun 2015 14:24:51 -0000 With the new outline in place (see draft-behringer-anima-reference-model-02= , just posted), we can now look who owns which section.=20 Now I try to best map the volunteers I've seen to the sections, according t= o their suggestions:=20 - Michael Richardson: section 3.3 (constrained nodes) - Liubing: 4.1 and 4.2 (Naming, addressing) - Brian Carpenter: 4.4 (signaling). Could you also cover 4.5 (intent distri= bution) and 4.3 (discovery)? - very related!!=20 - Jason Coleman: Section 5.1, 5.2, 5.4, 5.5 (PKI, cert, sub and cross-domai= n) - Jeferson Nobre: 7.1, 7.2, 7.3 (Management, intent, aggregated reporting)= =20 - John Strassner: 7.4, 7.5, 7.6 (feedback loops, APIS and models.) - Laurent Ciavaglia: Sections 8 and 9 (do they need an update?) - Toerless and I will share the remaining sections for now.=20 Did I miss any volunteer? Any wrong / missing section?=20 Now, some thoughts on how we progress, to see whether we have consensus. - The owner of a section keeps maintaining that section. This is NOT a one-= off, but requires continued work on your sections.=20 - Anyone in the author team is expected to read the entire doc, and comment= on it, help improve it.=20 - This document is NOT the standard, it just links up all the (future) stan= dards. At the end, each section will point to the relevant standards track = document. Details are for those documents.=20 - This document has the serious danger of getting very big, unless we all p= ay attention. Many sub-sections can probably be done in a few paragraphs. I= suggest that each sub-section should not exceed half a page. (Obviously, t= his is not a precise science, but "more or less".) Therefore:=20 - Writing style should be as concise as possible. Every sentence, every wor= d should be there for a reason.=20 Do we agree? Did I miss something?=20 Michael From nobody Thu Jun 11 12:07:33 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 235501B2CCB for ; Thu, 11 Jun 2015 12:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BK8XcTEJ5D-h for ; Thu, 11 Jun 2015 12:07:30 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) (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 5EFFF1B2CC7 for ; Thu, 11 Jun 2015 12:07:30 -0700 (PDT) Received: by qcjl8 with SMTP id l8so4735708qcj.3 for ; Thu, 11 Jun 2015 12:07:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=jcTNvWFB48PpZFQGfxa3tBuUPLH71Xi+LeannPh+Zo0=; b=QwHC5hD91mNEt8tMn4k8s7uQmWbS56TnCmbSaHd1Zx2KEnqe4S3FOaGfV29rCU2bNa zwVD5v3fD/PtOM8Wce7ejjz3jm4r1EvqQK3BmFpdcIeCS0W+CHmyFwxIYkmP3tZCKIpn qYpoEUuajKSjBN5/cMUrPK6cmhbLZw+3fqQ8YNNJBZ7ecIHaT/fFy5K80hc54retOBUo cawoz/qp4vDwuHywD46x8Lm9KDjASttBsGuflgJG4dkAMXw3u6PJRWWe0EfQdwnL33g0 gSPI49zGGPhgboCIrUNnVdRMu5B8MGpJ7HrpKqa2LVLPAX2Vxr0PJpJQzyCrALV3J6xI Izmw== X-Received: by 10.55.18.9 with SMTP id c9mr22843811qkh.50.1434049649644; Thu, 11 Jun 2015 12:07:29 -0700 (PDT) MIME-Version: 1.0 References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FCC640@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FCC640@xmb-rcd-x14.cisco.com> From: =?UTF-8?Q?J=C3=A9ferson_Campos_Nobre?= Date: Thu, 11 Jun 2015 19:07:19 +0000 Message-ID: To: "Michael Behringer (mbehring)" , Anima WG Content-Type: multipart/alternative; boundary=001a11476364f51b01051842b3b1 Archived-At: Subject: Re: [Anima] Reference doc - who helps where X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jun 2015 19:07:32 -0000 --001a11476364f51b01051842b3b1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Michael. Agreed. Do you plan to have a github rep like in anima signaling? I think it is a good idea because of the number of contributors. Best. J=C3=A9ferson Em qui, 11 de jun de 2015 =C3=A0s 11:24, Michael Behringer (mbehring) < mbehring@cisco.com> escreveu: > With the new outline in place (see > draft-behringer-anima-reference-model-02, just posted), we can now look w= ho > owns which section. > > Now I try to best map the volunteers I've seen to the sections, according > to their suggestions: > - Michael Richardson: section 3.3 (constrained nodes) > - Liubing: 4.1 and 4.2 (Naming, addressing) > - Brian Carpenter: 4.4 (signaling). Could you also cover 4.5 (intent > distribution) and 4.3 (discovery)? - very related!! > - Jason Coleman: Section 5.1, 5.2, 5.4, 5.5 (PKI, cert, sub and > cross-domain) > - Jeferson Nobre: 7.1, 7.2, 7.3 (Management, intent, aggregated reporting= ) > - John Strassner: 7.4, 7.5, 7.6 (feedback loops, APIS and models.) > - Laurent Ciavaglia: Sections 8 and 9 (do they need an update?) > - Toerless and I will share the remaining sections for now. > > Did I miss any volunteer? Any wrong / missing section? > > Now, some thoughts on how we progress, to see whether we have consensus. > - The owner of a section keeps maintaining that section. This is NOT a > one-off, but requires continued work on your sections. > - Anyone in the author team is expected to read the entire doc, and > comment on it, help improve it. > - This document is NOT the standard, it just links up all the (future) > standards. At the end, each section will point to the relevant standards > track document. Details are for those documents. > - This document has the serious danger of getting very big, unless we all > pay attention. Many sub-sections can probably be done in a few paragraphs= . > I suggest that each sub-section should not exceed half a page. (Obviously= , > this is not a precise science, but "more or less".) Therefore: > - Writing style should be as concise as possible. Every sentence, every > word should be there for a reason. > > Do we agree? Did I miss something? > Michael > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > --001a11476364f51b01051842b3b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Michael.
Agreed.
Do you plan to have a github re= p like in anima signaling? I think it is a good idea because of the number = of contributors.
Best.
J=C3=A9ferson

Em qui, 11 de jun de 2015 =C3=A0s 11:24, = Michael Behringer (mbehring) <mbeh= ring@cisco.com> escreveu:
Wi= th the new outline in place (see draft-behringer-anima-reference-model-02, = just posted), we can now look who owns which section.

Now I try to best map the volunteers I've seen to the sections, accordi= ng to their suggestions:
- Michael Richardson: section 3.3 (constrained nodes)
- Liubing: 4.1 and 4.2 (Naming, addressing)
- Brian Carpenter: 4.4 (signaling). Could you also cover 4.5 (intent distri= bution) and 4.3 (discovery)? - very related!!
- Jason Coleman: Section 5.1, 5.2, 5.4, 5.5 (PKI, cert, sub and cross-domai= n)
- Jeferson Nobre: 7.1, 7.2, 7.3 (Management, intent, aggregated reporting)<= br> - John Strassner: 7.4, 7.5, 7.6 (feedback loops, APIS and models.)
- Laurent Ciavaglia: Sections 8 and 9 (do they need an update?)
- Toerless and I will share the remaining sections for now.

Did I miss any volunteer? Any wrong / missing section?

Now, some thoughts on how we progress, to see whether we have consensus. - The owner of a section keeps maintaining that section. This is NOT a one-= off, but requires continued work on your sections.
- Anyone in the author team is expected to read the entire doc, and comment= on it, help improve it.
- This document is NOT the standard, it just links up all the (future) stan= dards. At the end, each section will point to the relevant standards track = document. Details are for those documents.
- This document has the serious danger of getting very big, unless we all p= ay attention. Many sub-sections can probably be done in a few paragraphs. I= suggest that each sub-section should not exceed half a page. (Obviously, t= his is not a precise science, but "more or less".)=C2=A0 Therefor= e:
- Writing style should be as concise as possible. Every sentence, every wor= d should be there for a reason.

Do we agree? Did I miss something?
Michael




_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
--001a11476364f51b01051842b3b1-- From nobody Thu Jun 11 22:34:41 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCB51A1BE5 for ; Thu, 11 Jun 2015 22:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jUgyQ7J3wUK for ; Thu, 11 Jun 2015 22:34:39 -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 0B7091A1BE7 for ; Thu, 11 Jun 2015 22:34:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXH15485; Fri, 12 Jun 2015 05:34:37 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 12 Jun 2015 06:32:40 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.186]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Fri, 12 Jun 2015 13:32:34 +0800 From: "Liubing (Leo)" To: Anima WG Thread-Topic: Intent Distribution draft -00 Thread-Index: AQHQpNEvhFtspgYaiUyq9dzaB/KLXw== Date: Fri, 12 Jun 2015 05:32:34 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45A6794F2C@nkgeml506-mbx.china.huawei.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FCC640@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FCC640@xmb-rcd-x14.cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Anima] Intent Distribution draft -00 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jun 2015 05:34:41 -0000 Hi Dear all in Anima, As we are discussing the reference model draft recently, also as Michael B.= commented: > - This document is NOT the standard, it just links up all the (future) st= andards. > At the end, each section will point to the relevant standards track docum= ent. > Details are for those documents. We actually have been exploring the intent related issues for some time. So= we thought it might be good to reveal our current work for discussion. We've uploaded a draft to discuss the Intent Distribution issue: > Name: draft-liu-anima-intent-distribution > Revision: 00 > Title: Intent Distribution for Autonomic Networking > Document date: 2015-06-12 > Group: Individual Submission > Pages: 10 > URL: https://www.ietf.org/internet-drafts/draft-liu-anima-intent= -distribution-00.txt > Status: https://datatracker.ietf.org/doc/draft-liu-anima-intent-d= istribution/ > Htmlized: https://tools.ietf.org/html/draft-liu-anima-intent-distri= bution-00 The document is still at the initial stage, so we're quite open to discuss = any of the content. We also expect more of you to contribute on this work. Many thanks! Best regards, Bing From nobody Fri Jun 12 00:07:17 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 713AA1A1B67 for ; Fri, 12 Jun 2015 00:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7Hsmn4fEURN for ; Fri, 12 Jun 2015 00:07:14 -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 5AE1B1A1B71 for ; Fri, 12 Jun 2015 00:07:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXH22136; Fri, 12 Jun 2015 07:07:12 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 12 Jun 2015 08:07:11 +0100 Received: from NKGEML505-MBX.china.huawei.com ([169.254.1.218]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Fri, 12 Jun 2015 15:07:05 +0800 From: Duzongpeng To: "anima@ietf.org" Thread-Topic: [Anima] Intent Concept and Format draft - 00 Thread-Index: AdCk3mDxi7MD0pBbQNqujG1SanHhog== Date: Fri, 12 Jun 2015 07:07:04 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.160] Content-Type: multipart/alternative; boundary="_000_BAFEC9523F57BC48A51C20226A5589575E930623nkgeml505mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Anima] Intent Concept and Format draft - 00 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jun 2015 07:07:16 -0000 --_000_BAFEC9523F57BC48A51C20226A5589575E930623nkgeml505mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all: We have submitted another new draft about Intent. Welcome for comments. Its purpose is to clarify the concept of Intent and explore the common form= at of an Intent. It is essential to have a standard Intent for autonomic network. We believe= more attention should be paid on this aspect. The content of this draft is still at the preliminary stage. Welcome to joi= n in. Name: draft-du-anima-an-intent Revision: 00 Title: Autonomic Network Intent and Format Document date: 2015-06-11 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-du-anima-an-inte= nt-00.txt Status: https://datatracker.ietf.org/doc/draft-du-anima-an-intent/ Htmlized: https://tools.ietf.org/html/draft-du-anima-an-intent-00 Abstract: This document describes the concept and consideration of the Autonomic Network Intent, and proposes a uniform format for the Autonomic Network Intent. Best regards Zongpeng Du --_000_BAFEC9523F57BC48A51C20226A5589575E930623nkgeml505mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all:

 <= /span>

We have submitted = another new draft about Intent. Welcome for comments.

 <= /span>

Its purpose is to = clarify the concept of Intent and explore the common format of an Intent.

 <= /span>

It is essential to= have a standard Intent for autonomic network. We believe more attention sh= ould be paid on this aspect.

 <= /span>

The content of thi= s draft is still at the preliminary stage. Welcome to join in.

 <= /span>

Name:    = ;          draft-du-anima-an-i= ntent

Revision: 00

Title:   &nbs= p;             = Autonomic Network Intent and Format

Document date:  &n= bsp;   2015-06-11

Group:   &nbs= p;          Individual Submiss= ion

Pages:   &nbs= p;          6

URL:    =         https://www.ietf.org/internet-drafts/draft-du-anima-an-intent-00.txt

Status:   &nb= sp;     https://datatracker.ietf.org/doc/draft-du-anima-an-intent/

Htmlized:   &= nbsp;   https://tools.ietf.org/html/draft-du-anima-an-intent-00

 

 

Abstract:<= /p>

   This document d= escribes the concept and consideration of the

   Autonomic Netwo= rk Intent, and proposes a uniform format for the

   Autonomic Netwo= rk Intent.

 

Best regards<= /o:p>

Zongpeng Du

--_000_BAFEC9523F57BC48A51C20226A5589575E930623nkgeml505mbxchi_-- From nobody Fri Jun 12 14:50:04 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6C71AD0AD for ; Fri, 12 Jun 2015 14:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxHUgOlAG4Cg for ; Fri, 12 Jun 2015 14:49:59 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::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 34B7C1ACF1D for ; Fri, 12 Jun 2015 14:49:59 -0700 (PDT) Received: by wiga1 with SMTP id a1so27263149wig.0 for ; Fri, 12 Jun 2015 14:49:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=z1Jz60fUSBRaydOPYg7dAmO2XKf0pg11XOxoJpVYjvQ=; b=FI3UTc/AEYIGatnDjPR5wntZYZZ5TXffnxLt/NUrxhFM1TKepC7JApvb0OTGVCWG1g xVXeS3TV5mHTTdsG9YR4Pb9VFqOc+h+A50j4sj6V0DI5dUk9q/f+9BLKe0rPMu93xNTG s1Mn7bPm1U2DBSQ3LBiwKMLdfrqs1h/D64wMtL0wl7Ajs8T5u9eGhMs38guugA8DhqRS tbmGTjoNHfiiwx5qHUvR5SSgYfM6aUSyAAgaTDw4MKyBBQJwu519VQfJKaQ3Bih8PNV1 j4gr5WENqA2xRyBigTBD7F35q8hu3iAM+nY97CzqxHCGLSeyDNF1u7L32ez1vFXH/OcG VixA== MIME-Version: 1.0 X-Received: by 10.180.100.194 with SMTP id fa2mr10624520wib.8.1434145797896; Fri, 12 Jun 2015 14:49:57 -0700 (PDT) Received: by 10.27.220.1 with HTTP; Fri, 12 Jun 2015 14:49:57 -0700 (PDT) In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FCC640@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FCC640@xmb-rcd-x14.cisco.com> Date: Fri, 12 Jun 2015 14:49:57 -0700 Message-ID: From: John Strassner To: "Michael Behringer (mbehring)" Content-Type: multipart/alternative; boundary=f46d0444ed39d7018e05185916c5 Archived-At: Cc: Anima WG Subject: Re: [Anima] Reference doc - who helps where X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jun 2015 21:50:02 -0000 --f46d0444ed39d7018e05185916c5 Content-Type: text/plain; charset=UTF-8 Hi Michael, thanks for organizing this. I'm confirming both my assigned sections as well as reading and commenting on the entire draft. Regarding 7.2 (intent), we should be careful to sync (or explain why we disagree) with intent as being defined in the 100 or so other places that people are working on it. We don't need to sync in this document of course - but we should be prepared to deal with this (imho inevitable) question when it comes up. I'm happy to help Jefferson here (I'm active in ONF, ONOS, Congress, TMF, and remember - SUPA has also defined intent). How would you like to proceed on updates? For example, if I update 7.3, should I send a draft-behringer-anima-reference-model-02-7.3-from-jcs.txt to the author list, ANIMA, or a to-be-defined GitHub site? best regards, John On Thu, Jun 11, 2015 at 7:24 AM, Michael Behringer (mbehring) < mbehring@cisco.com> wrote: > With the new outline in place (see > draft-behringer-anima-reference-model-02, just posted), we can now look who > owns which section. > > Now I try to best map the volunteers I've seen to the sections, according > to their suggestions: > - Michael Richardson: section 3.3 (constrained nodes) > - Liubing: 4.1 and 4.2 (Naming, addressing) > - Brian Carpenter: 4.4 (signaling). Could you also cover 4.5 (intent > distribution) and 4.3 (discovery)? - very related!! > - Jason Coleman: Section 5.1, 5.2, 5.4, 5.5 (PKI, cert, sub and > cross-domain) > - Jeferson Nobre: 7.1, 7.2, 7.3 (Management, intent, aggregated reporting) > - John Strassner: 7.4, 7.5, 7.6 (feedback loops, APIS and models.) > - Laurent Ciavaglia: Sections 8 and 9 (do they need an update?) > - Toerless and I will share the remaining sections for now. > > Did I miss any volunteer? Any wrong / missing section? > > Now, some thoughts on how we progress, to see whether we have consensus. > - The owner of a section keeps maintaining that section. This is NOT a > one-off, but requires continued work on your sections. > - Anyone in the author team is expected to read the entire doc, and > comment on it, help improve it. > - This document is NOT the standard, it just links up all the (future) > standards. At the end, each section will point to the relevant standards > track document. Details are for those documents. > - This document has the serious danger of getting very big, unless we all > pay attention. Many sub-sections can probably be done in a few paragraphs. > I suggest that each sub-section should not exceed half a page. (Obviously, > this is not a precise science, but "more or less".) Therefore: > - Writing style should be as concise as possible. Every sentence, every > word should be there for a reason. > > Do we agree? Did I miss something? > Michael > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > -- regards, John --f46d0444ed39d7018e05185916c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Michael,

thanks for organ= izing this. I'm confirming both my assigned sections as well as reading= and commenting on the entire draft.

Regarding 7.2= (intent), we should be careful to sync (or explain why we disagree) with i= ntent as being defined in the 100 or so other places that people are workin= g on it. We don't need to sync in this document of course - but we shou= ld be prepared to deal with this (imho inevitable) question when it comes u= p. I'm happy to help Jefferson here (I'm active in ONF, ONOS, Congr= ess, TMF, and remember - SUPA has also defined intent).

How would you like to proceed on updates? For example, if I update 7.= 3, should I send a draft-behringer-anima-reference-model-02-7.3-from-jcs.tx= t to the author list, ANIMA, or a to-be-defined GitHub site?

=
best regards,
John

On Thu, Jun 11, 2015 at 7:24 AM, Michael = Behringer (mbehring) <mbehring@cisco.com> wrote:
With the new outline in place (see draft-behringer-= anima-reference-model-02, just posted), we can now look who owns which sect= ion.

Now I try to best map the volunteers I've seen to the sections, accordi= ng to their suggestions:
- Michael Richardson: section 3.3 (constrained nodes)
- Liubing: 4.1 and 4.2 (Naming, addressing)
- Brian Carpenter: 4.4 (signaling). Could you also cover 4.5 (intent distri= bution) and 4.3 (discovery)? - very related!!
- Jason Coleman: Section 5.1, 5.2, 5.4, 5.5 (PKI, cert, sub and cross-domai= n)
- Jeferson Nobre: 7.1, 7.2, 7.3 (Management, intent, aggregated reporting)<= br> - John Strassner: 7.4, 7.5, 7.6 (feedback loops, APIS and models.)
- Laurent Ciavaglia: Sections 8 and 9 (do they need an update?)
- Toerless and I will share the remaining sections for now.

Did I miss any volunteer? Any wrong / missing section?

Now, some thoughts on how we progress, to see whether we have consensus. - The owner of a section keeps maintaining that section. This is NOT a one-= off, but requires continued work on your sections.
- Anyone in the author team is expected to read the entire doc, and comment= on it, help improve it.
- This document is NOT the standard, it just links up all the (future) stan= dards. At the end, each section will point to the relevant standards track = document. Details are for those documents.
- This document has the serious danger of getting very big, unless we all p= ay attention. Many sub-sections can probably be done in a few paragraphs. I= suggest that each sub-section should not exceed half a page. (Obviously, t= his is not a precise science, but "more or less".)=C2=A0 Therefor= e:
- Writing style should be as concise as possible. Every sentence, every wor= d should be there for a reason.

Do we agree? Did I miss something?
Michael




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



--
regards,
John
--f46d0444ed39d7018e05185916c5-- From nobody Fri Jun 12 14:51:52 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED2531ACF1D for ; Fri, 12 Jun 2015 14:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeZhsGwx86Lu for ; Fri, 12 Jun 2015 14:51:46 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (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 531D11ACEF6 for ; Fri, 12 Jun 2015 14:51:46 -0700 (PDT) Received: by wiga1 with SMTP id a1so27286014wig.0 for ; Fri, 12 Jun 2015 14:51:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lvhlU7cerffbthX8EDsVcbJAUHVPQn/uPRVpINL7j5k=; b=Lv7KaJDrMT4izn+MI6H+az/W5axEqSPNwudSc1KWONkJY4187JFwKAie6nw/DlBumO HocBHLxZJv46tN0hpKiXeeoIKDQOTSwr2dAM3S+hXgR8vDrNAx5APFWemps6BvIm++yy jUUmzY/25VvX+tnlDrcN2RkCNhGDo6MomUSvZQ6D4JGs75XK+O7PckecV1m2Zdz+gcuZ J/6i3Pr/dreZjspX/F1zALR9Q0s0SI9/YjejFu0fsEmEuRbAOIvpv/pvii8SXta6GdpF 4DNUGRRqZRl9Bs3CB/YiGP0sGyRaG5T3ZeWhFyrho9DfckIOyTTqeN5ODt0s2gkGhceD qMjg== MIME-Version: 1.0 X-Received: by 10.180.87.201 with SMTP id ba9mr10491555wib.73.1434145905049; Fri, 12 Jun 2015 14:51:45 -0700 (PDT) Received: by 10.27.220.1 with HTTP; Fri, 12 Jun 2015 14:51:44 -0700 (PDT) In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FCA9C1@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FCA9C1@xmb-rcd-x14.cisco.com> Date: Fri, 12 Jun 2015 14:51:44 -0700 Message-ID: From: John Strassner To: "Michael Behringer (mbehring)" Content-Type: multipart/alternative; boundary=f46d0444eb553a03a20518591dbf Archived-At: Cc: Anima WG Subject: Re: [Anima] Reference document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jun 2015 21:51:50 -0000 --f46d0444eb553a03a20518591dbf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry, forgot to respond. Feedback is MUCH BETTER. :-) best regards, John On Wed, Jun 10, 2015 at 5:14 AM, Michael Behringer (mbehring) < mbehring@cisco.com> wrote: > Thanks for all the volunteers to help with the doc here. In fact, I=E2= =80=99m > having a bit of a hard time figuring out how to move forward, because the= re > are several overlapping editing suggestions, and the document structure > doesn=E2=80=99t take the latest discussions into account. > > > > Here is what I=E2=80=99ve done now: > > - I worked all the open points into the *outline* of the documen= t > (most of them from > http://www.ietf.org/mail-archive/web/anima/current/msg01044.html ) > I moved sections back and forth, trying to figure out the most logical > structure. > *The result is a completely new, but hopefully better structured outline.= * > > - Let=E2=80=99s agree on the outline first. Does this capture al= l the > important points? > > - Then, based on the proposals, we look at who works out which > section, to avoid overlap, and make sure we=E2=80=99re in sync. (I=E2=80= =99ll propose > something to get started). > > > > Does this make sense? > > > > If so, below is the new suggested outline. I think it=E2=80=99s more logi= cally > organised now: > > - Section 2 gives the high level view, as for example someone > writing ASAs would need to know. > > - Section 3 is the architecture of a single node. > > - Section 4 is the ANI. So this is the =E2=80=9Cbaseline=E2=80= =9D an AN node > needs to support. I moved the ACP sections into this section now, because > it=E2=80=99s base line really. > > - Section 5 describes security. I=E2=80=99ve been putting the su= b-domain > question eventually under this heading. We also need to describe the > certificate format as well. I=E2=80=99ve also moved the MASA into this se= ction, > since it=E2=80=99s about trust at the end of the day. (Not 100% sure this= is the > best place). > > - Section 6 is about the ASAs. I=E2=80=99ve now taken out the re= gistrar > from the =E2=80=9Cnodes=E2=80=9D section and moved it as a =E2=80=9Cmust = implement=E2=80=9D ASA into the > ASA section. Also the bootstrap functions really are ASAs, so they are in > this section now. This way we keep the ANI =E2=80=9Cclean=E2=80=9D. > > - Section 7 is about everything Management and Programmability. > Intent belongs in here, the general description of how an AN network is > managed, APIs, data models. > > - Sections 8 and 9 are unchanged from the last version. (apart > from numbering) > > - And I marked the sections that are not directly addressed in > the current charter, but which we should at least cover in principle here= , > with an (*). > > > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 > > 2. The Network View . . . . . . . . . . . . . . . . . . . . . . 3 > > 3. The Autonomic Network Element . . . . . . . . . . . . . . . . 4 > > 3.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 4 > > 3.2. Unconstrained AN Nodes . . . . . . . . . . . . . . . . . 5 > > 3.3. Constrained AN Nodes (*) . . . . . . . . . . . . . . . . 6 > > 4. The Autonomic Networking Infrastructure . . . . . . . . . . . 6 > > 4.1. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 6 > > 4.2. Addressing . . . . . . . . . . . . . . . . . . . . . . . 6 > > 4.3. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 7 > > 4.4. Signaling for Negotiation and Synchronization . . . . . . 8 > > 4.5. Intent Distribution . . . . . . . . . . . . . . . . . . . 8 > > 4.6. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 8 > > 4.7. The Autonomic Control Plane . . . . . . . . . . . . . . . 8 > > 4.8. Reporting (*) . . . . . . . . . . . . . . . . . . . . . . 9 > > 4.9. Feedback Loops (*) . . . . . . . . . . . . . . . . . . . 9 > > 5. Security and Trust Infrastructure . . . . . . . . . . . . . . 9 > > 5.1. Public Key Infrastructure . . . . . . . . . . . . . . . . 9 > > 5.2. Domain Certificate . . . . . . . . . . . . . . . . . . . 9 > > 5.3. Sub-Domains (*) . . . . . . . . . . . . . . . . . . . . . 10 > > 5.4. Cross-Domain Functionality (*) . . . . . . . . . . . . . 10 > > 5.5. The MASA (*) . . . . . . . . . . . . . . . . . . . . . . 10 > > 6. Autonomic Service Agents (ASA) . . . . . . . . . . . . . . . 10 > > 6.1. General Description of an ASA . . . . . . . . . . . . . . 10 > > 6.2. Specific ASAs . . . . . . . . . . . . . . . . . . . . . . 10 > > 6.2.1. The Enrolment ASA . . . . . . . . . . . . . . . . . . 10 > > 6.2.2. The Enrolment Proxy ASA . . . . . . . . . . . . . . . 10 > > 6.2.3. The Registrar ASA . . . . . . . . . . . . . . . . . . 11 > > 7. Management and Programmability . . . . . . . . . . . . . . . 11 > > 7.1. How an AN Network Is Managed . . . . . . . . . . . . . . 11 > > 7.2. Intent (*) . . . . . . . . . . . . . . . . . . . . . . . 11 > > 7.3. APIs (*) . . . . . . . . . . . . . . . . . . . . . . . . 11 > > 7.4. Data Model (*) . . . . . . . . . . . . . . . . . . . . . 11 > > 8. Coordination Between Autonomic Functions (*) . . . . . . . . 11 > > 8.1. The Coordination Problem (*) . . . . . . . . . . . . . . 11 > > 8.2. A Coordination Functional Block (*) . . . . . . . . . . . 12 > > 9. Hybrid Approach with Non-Autonomic Functions (*) . . . . . . 13 > > 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 > > > > I have this in XML, will first ask the current co-authors for approval to > publish this =E2=80=93 I think it would be good to have the new outline a= s a new > version available to all. If the co-authors are fine with this, I=E2=80= =99ll > publish (hopefully tomorrow). > > > > Feedback? Moving in the right direction? > > Michael > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > > --=20 regards, John --f46d0444eb553a03a20518591dbf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry, forgot to respond. Feedback is MUCH BETTER. :-= )

best regards,
John

On Wed, Jun 10, 2015 at 5= :14 AM, Michael Behringer (mbehring) <mbehring@cisco.com> w= rote:

Thanks = for all the volunteers to help with the doc here. In fact, I=E2=80=99m havi= ng a bit of a hard time figuring out how to move forward, because there are= several overlapping editing suggestions, and the document structure doesn=E2=80=99t take the latest di= scussions into account.

=C2=A0

Here is= what I=E2=80=99ve done now:

-= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I worked all the open points into= the outline of the document
(most of them from http://www.ietf.org/mail-archive/web/anima/current/msg01044.html )
I moved sections back and forth, trying to figure out the most logical stru= cture.
The result is a completely new, but hop= efully better structured outline.

-= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Let=E2=80=99s agree on the outlin= e first. Does this capture all the important points?

-= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Then, based on the proposals, we = look at who works out which section, to avoid overlap, and make sure we=E2= =80=99re in sync. (I=E2=80=99ll propose something to get started).

=C2=A0

Does th= is make sense?

=C2=A0

If so, = below is the new suggested outline. I think it=E2=80=99s more logically org= anised now:

-= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Section 2 gives the high level vi= ew, as for example someone writing ASAs would need to know.

-= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Section 3 is the architecture of = a single node.

-= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Section 4 is the ANI. So this is = the =E2=80=9Cbaseline=E2=80=9D an AN node needs to support. I moved the ACP= sections into this section now, because it=E2=80=99s base line really.

-=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Section 5 describes security. I=E2=80=99ve been putting the sub= -domain question eventually under this heading. We also need to describe the certificate format as well. I= =E2=80=99ve also moved the MASA into this section, since it=E2=80=99s about= trust at the end of the day. (Not 100% sure this is the best place).

-= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Section 6 is about the ASAs. I=E2= =80=99ve now taken out the registrar from the =E2=80=9Cnodes=E2=80=9D secti= on and moved it as a =E2=80=9Cmust implement=E2=80=9D ASA into the ASA sect= ion. Also the bootstrap functions really are ASAs, so they are in this section now. This way we keep the ANI =E2=80=9Cclean=E2=80=9D. <= /u>

-= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Section 7 is about everything Man= agement and Programmability. Intent belongs in here, the general descriptio= n of how an AN network is managed, APIs, data models.

-= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Sections 8 and 9 are unchanged fr= om the last version. (apart from numbering)

-= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 And I marked the sections that ar= e not directly addressed in the current charter, but which we should at lea= st cover in principle here, with an (*).

=C2=A0

=C2=A0= =C2=A0 1.=C2=A0 Introduction=C2=A0 . . . . . . . . . . . . . . . . . . . . = . . . .=C2=A0=C2=A0 3

=C2=A0= =C2=A0 2.=C2=A0 The Network View=C2=A0 . . . . . . . . . . . . . . . . . . = . . . .=C2=A0=C2=A0 3

=C2=A0= =C2=A0 3.=C2=A0 The Autonomic Network Element . . . . . . . . . . . . . . .= .=C2=A0=C2=A0 4

=C2=A0= =C2=A0=C2=A0=C2=A0 3.1.=C2=A0 Architecture=C2=A0 . . . . . . . . . . . . . = . . . . . . . . .=C2=A0=C2=A0 4

=C2=A0= =C2=A0=C2=A0=C2=A0 3.2.=C2=A0 Unconstrained AN Nodes=C2=A0 . . . . . . . . = . . . . . . . . .=C2=A0=C2=A0 5

=C2=A0= =C2=A0=C2=A0=C2=A0 3.3.=C2=A0 Constrained AN Nodes (*)=C2=A0 . . . . . . . = . . . . . . . . .=C2=A0=C2=A0 6

=C2=A0= =C2=A0 4.=C2=A0 The Autonomic Networking Infrastructure . . . . . . . . . .= .=C2=A0=C2=A0 6

=C2=A0= =C2=A0=C2=A0=C2=A0 4.1.=C2=A0 Naming=C2=A0 . . . . . . . . . . . . . . . . = . . . . . . . . .=C2=A0=C2=A0 6

=C2=A0= =C2=A0=C2=A0=C2=A0 4.2.=C2=A0 Addressing=C2=A0 . . . . . . . . . . . . . . = . . . . . . . . .=C2=A0=C2=A0 6

=C2=A0= =C2=A0=C2=A0=C2=A0 4.3.=C2=A0 Discovery . . . . . . . . . . . . . . . . . .= . . . . . .=C2=A0=C2=A0 7

=C2=A0= =C2=A0=C2=A0=C2=A0 4.4.=C2=A0 Signaling for Negotiation and Synchronization= . . . . . .=C2=A0=C2=A0 8

=C2=A0= =C2=A0=C2=A0=C2=A04.5.=C2=A0 Intent Distribution . . . . . . . . . . . . . = . . . . . .=C2=A0=C2=A0 8

=C2=A0= =C2=A0=C2=A0=C2=A0 4.6.=C2=A0 Routing . . . . . . . . . . . . . . . . . . .= . . . . . .=C2=A0=C2=A0 8

=C2=A0= =C2=A0=C2=A0=C2=A0 4.7.=C2=A0 The Autonomic Control Plane . . . . . . . . .= . . . . . .=C2=A0=C2=A0 8

=C2=A0= =C2=A0=C2=A0=C2=A0 4.8.=C2=A0 Reporting (*) . . . . . . . . . . . . . . . .= . . . . . .=C2=A0=C2=A0 9

=C2=A0= =C2=A0=C2=A0=C2=A0 4.9.=C2=A0 Feedback Loops (*)=C2=A0 . . . . . . . . . . = . . . . . . . . .=C2=A0=C2=A0 9

=C2=A0= =C2=A0 5.=C2=A0 Security and Trust Infrastructure . . . . . . . . . . . . .= .=C2=A0=C2=A0 9

=C2=A0= =C2=A0=C2=A0=C2=A0 5.1.=C2=A0 Public Key Infrastructure . . . . . . . . . .= . . . . . .=C2=A0=C2=A0 9

=C2=A0 = =C2=A0=C2=A0=C2=A05.2.=C2=A0 Domain Certificate=C2=A0 . . . . . . . . . . .= . . . . . . . .=C2=A0=C2=A0 9

=C2=A0= =C2=A0=C2=A0=C2=A0 5.3.=C2=A0 Sub-Domains (*) . . . . . . . . . . . . . . .= . . . . . .=C2=A0 10

=C2=A0= =C2=A0=C2=A0=C2=A0 5.4.=C2=A0 Cross-Domain Functionality (*)=C2=A0 . . . . = . . . . . . . . .=C2=A0 10

=C2=A0= =C2=A0=C2=A0=C2=A0 5.5.=C2=A0 The MASA (*)=C2=A0 . . . . . . . . . . . . . = . . . . . . . . .=C2=A0 10

=C2=A0= =C2=A0 6.=C2=A0 Autonomic Service Agents (ASA)=C2=A0 . . . . . . . . . . . = . . . .=C2=A0 10

=C2=A0= =C2=A0=C2=A0=C2=A0 6.1.=C2=A0 General Description of an ASA . . . . . . . .= . . . . . .=C2=A0 10

=C2=A0= =C2=A0=C2=A0=C2=A0 6.2.=C2=A0 Specific ASAs . . . . . . . . . . . . . . . .= . . . . . .=C2=A0 10

=C2=A0= =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A06.2.1.=C2=A0 The Enrolment ASA . . . . . . .= . . . . . . . . . . .=C2=A0 10

=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 6.2.2.=C2=A0 The Enrolment Proxy ASA . . . .= . . . . . . . . . . .=C2=A0 10

=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 6.2.3.=C2=A0 The Registrar ASA . . . . . . .= . . . . . . . . . . .=C2=A0 11

=C2=A0= =C2=A0 7.=C2=A0 Management and Programmability=C2=A0 . . . . . . . . . . . = . . . .=C2=A0 11

=C2=A0= =C2=A0=C2=A0=C2=A0 7.1.=C2=A0 How an AN Network Is Managed=C2=A0 . . . . . = . . . . . . . . .=C2=A0 11

=C2=A0= =C2=A0=C2=A0=C2=A0 7.2.=C2=A0 Intent (*)=C2=A0 . . . . . . . . . . . . . . = . . . . . . . . .=C2=A0 11

=C2=A0= =C2=A0=C2=A0=C2=A0 7.3.=C2=A0 APIs (*)=C2=A0 . . . . . . . . . . . . . . . = . . . . . . . . .=C2=A0 11

=C2=A0= =C2=A0=C2=A0=C2=A0 7.4.=C2=A0 Data Model (*)=C2=A0 . . . . . . . . . . . . = . . . . . . . . .=C2=A0 11

=C2=A0= =C2=A0 8.=C2=A0 Coordination Between Autonomic Functions (*)=C2=A0 . . . . = . . . .=C2=A0 11

=C2=A0= =C2=A0=C2=A0=C2=A0 8.1.=C2=A0 The Coordination Problem (*)=C2=A0 . . . . . = . . . . . . . . .=C2=A0 11

=C2=A0= =C2=A0=C2=A0=C2=A0 8.2.=C2=A0 A Coordination Functional Block (*) . . . . .= . . . . . .=C2=A0 12

=C2=A0= =C2=A0 9.=C2=A0 Hybrid Approach with Non-Autonomic Functions (*)=C2=A0 . . = . . . .=C2=A0 13

=C2=A0= =C2=A0 10. Security Considerations . . . . . . . . . . . . . . . . . . .=C2= =A0 13

=C2=A0

I have = this in XML, will first ask the current co-authors for approval to publish = this =E2=80=93 I think it would be good to have the new outline as a new ve= rsion available to all. If the co-authors are fine with this, I=E2=80=99ll publish (hopefully tomo= rrow).

=C2=A0

Feedbac= k? Moving in the right direction? =

Michael=

=C2=A0


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




--
regards,
John
--f46d0444eb553a03a20518591dbf-- From nobody Sun Jun 14 13:32:23 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8531B30C9 for ; Sun, 14 Jun 2015 13:32:21 -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 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 JQxH9pPwkIzY for ; Sun, 14 Jun 2015 13:32:20 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 357CE1B30C7 for ; Sun, 14 Jun 2015 13:32:20 -0700 (PDT) Received: by pdbnf5 with SMTP id nf5so57895249pdb.2 for ; Sun, 14 Jun 2015 13:32:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=Gvirco0QqznR2TIMU/sP3FsOrnt00/8meGdCPzlnQ0U=; b=WQVP2l6GVfk0GXIdrqofVoeKB6ZNT8OrQ7p7zPjfnrCGVS4D0ekbY5/iAGKFAZco0R l6H+LT7XVXOkXw1kMpYNRfBHNiVGhtOPtVZhOX6wb8oIs6LTR1/EpZ360dzEPurAD22P +b6e7Zt2yXitMbOXPUiF50EucFL/9wDLW81YUHtnEd2/C59U1iSfcVCNFfve5zVB/qHa K8qcUtdBql64UiiaWn+bgAV/nTkBsase84zCQM40D/UY9RB6ym+4u3BhjiGlDPISpQE0 JSnrHalJQB0ms6Jc7c6wPyMCDVS20iqwrdIzYI/JODCieTjL6AwXPlu3Ivn6u1uN2wS0 L0Kg== X-Received: by 10.66.100.233 with SMTP id fb9mr41050313pab.128.1434313939921; Sun, 14 Jun 2015 13:32:19 -0700 (PDT) Received: from ?IPv6:2406:e007:6a73:1:28cc:dc4c:9703:6781? ([2406:e007:6a73:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id ax2sm9996032pac.21.2015.06.14.13.32.16 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Jun 2015 13:32:18 -0700 (PDT) Message-ID: <557DE4C8.4050507@gmail.com> Date: Mon, 15 Jun 2015 08:32:08 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Anima WG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Domains X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2015 20:32:21 -0000 Hi, I want to raise a point about the reference model that the authors of draft-behringer-anima-reference-model didn't settle before version -02 came out a few days ago. There's placeholder text in the draft about Sub-Domains and Cross-Domain Functionality. I suggested that we should also list "Overlapping Domains" as a topic. In other words, regions of a network could be considered to be in two different domains simultaneously. The question is whether we want our model to include that possibility? It certainly has implications for security. An example would be some sort of resource that needed to be shared between two otherwise separate domains; that resource could be considered to be in both domains. So I can see three possible models, shown in the folowing ASCII art: ------------------------------------------- | Shared Resource | | | | ------------------ ------------------ | | | Subddomain1 | | Subddomain2 | | | | | | | | | | | | | | | ------------------ ------------------ | | | ------------------------------------------- 1. Shared resource in outer domain ------------------ ------------------ | Domain1 | | Domain2 | | | | | | Shared | | | | Resource<|xxx|> | ------------------ ------------------ 2. Shared resource in one domain, with cross-domain access ---------------------- | Domain1 ------|------------------ | | Shared Domain2 | | |Resource | | | | | ---------------|------ | ------------------------- 3. Shared resource in domain overlap Regards Brian From nobody Sun Jun 14 14:06:38 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCDE1B3162 for ; Sun, 14 Jun 2015 14:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejjIOd3xvGUE for ; Sun, 14 Jun 2015 14:06:35 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4CC51B3160 for ; Sun, 14 Jun 2015 14:06:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4025; q=dns/txt; s=iport; t=1434315996; x=1435525596; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=88aXk5CDQAZJjBhBfhbaL3+yi66u2roB4qF2w68nGFc=; b=K5AGswClKhI2i2kqgxXxq43IjFUy5d6e8OPOBjARawQMj61IVrVnLBck rI6wSsc2+vZInc7d1coxtzaWc0bUuEiGfdPgxUmaBQJJtpJADafP+WF/r x7qWPBtLKh6FBWcD+r6MxPUYVvX06Ww+1YPYCvCoo8W2hLcjmlZRk/f1G k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BWBQAY7H1V/5hdJa1cgxBUX79gCoV6AoEhPBABAQEBAQEBgQqEIwEBBAEBATc0CxALGAklDwUTNhOILw3IewEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi0SFBgeDF4EWBYZ6hW6Gc4tBAYEzkwKDWyaEGR4xgkcBAQE X-IronPort-AV: E=Sophos;i="5.13,614,1427760000"; d="scan'208";a="159383976" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Jun 2015 21:06:35 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t5EL6XAA025050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Jun 2015 21:06:33 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 t5EL6Wlg025593; Sun, 14 Jun 2015 14:06:32 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t5EL6Wnw025592; Sun, 14 Jun 2015 14:06:32 -0700 Date: Sun, 14 Jun 2015 14:06:32 -0700 From: Toerless Eckert To: Brian E Carpenter Message-ID: <20150614210632.GA23588@cisco.com> References: <557DE4C8.4050507@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <557DE4C8.4050507@gmail.com> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Anima WG Subject: Re: [Anima] Domains X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2015 21:06:36 -0000 First of all, i think it's not clear to me how we exactly define "resource", so i think we should do that first, so that we talk about the same thing. Maybe we can start with use-cases and then try to explain how we would solve them, then the right pictures of your model would IMHO evolve: Mergers/Aquisitions/splits/sale of nodes Lets say we wanted to solve this at the cert level: Mechanisms required to make this seamless/online: a) establish 2nd cert b) change 2nd cert to primary (owner cert) c) delete 2nd cert - establish AN neighboring to all neighbors with either 1st or 2nd cert. Merger would then be done as follow: Network wide: 1. establish buying companies cert on all aquired companies AN devices - using the registrar of that aquired company, because only that will be trusted. At the end of this, you've got contiguous AN connectivity. 2. change 2nd cert to primary, still with intent/authorization from aquired company. After this step, there is only one primary intent/autohrization - the one of the aquiring company. 3. delete aquired company certs. A problem with this is likely that cheap TPM hardware can only deal with one cert, so the 2ndary certs need to be done in SW, which than raises questions of online protection. And b) is a critical operation. I think we won't be able to get around the complex "cert in SW" linking back to a primary cert in HW to protect it, because we certainly want to solve "autonomic VM on an autonomic Host". The VMs could of course be in a different autonomic domain and would have to trust the host, so the host would want to protect the VMs certs in the same way as his own 2ndary certs. cheers Toerless On Mon, Jun 15, 2015 at 08:32:08AM +1200, Brian E Carpenter wrote: > Hi, > > I want to raise a point about the reference model that the authors of > draft-behringer-anima-reference-model didn't settle before version -02 > came out a few days ago. There's placeholder text in the draft about > Sub-Domains and Cross-Domain Functionality. I suggested that we > should also list "Overlapping Domains" as a topic. In other words, > regions of a network could be considered to be in two different > domains simultaneously. The question is whether we want our model > to include that possibility? It certainly has implications for security. > > An example would be some sort of resource that needed to be shared > between two otherwise separate domains; that resource could be considered > to be in both domains. > > So I can see three possible models, shown in the folowing ASCII art: > > ------------------------------------------- > | Shared Resource | > | | > | ------------------ ------------------ | > | | Subddomain1 | | Subddomain2 | | > | | | | | | > | | | | | | > | ------------------ ------------------ | > | | > ------------------------------------------- > > 1. Shared resource in outer domain > > ------------------ ------------------ > | Domain1 | | Domain2 | > | | | | > | Shared | | | > | Resource<|xxx|> | > ------------------ ------------------ > > 2. Shared resource in one domain, with cross-domain access > > ---------------------- > | Domain1 ------|------------------ > | | Shared Domain2 | > | |Resource | > | | | | > ---------------|------ | > ------------------------- > > 3. Shared resource in domain overlap > > Regards > Brian > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Sun Jun 14 18:21:57 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC0C1ACE5E for ; Sun, 14 Jun 2015 18:21:56 -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 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 RRAiaAlmMahK for ; Sun, 14 Jun 2015 18:21:54 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::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 0E6101ACDF7 for ; Sun, 14 Jun 2015 18:21:54 -0700 (PDT) Received: by padev16 with SMTP id ev16so55016076pad.0 for ; Sun, 14 Jun 2015 18:21:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qYMUcUwoD8ciVAmOPHM7EsqngzAbQA0YcRj4+8FVn+Q=; b=iHRsxqne9+8srT8dB3lwCOx+7H0CCcXSZe/4cYTR3KA1k33rsfcNhxSSj+ERD3S4GW WnTTeWTkbbmY7kDW2a1oO1ebBFtsZ0WUdm3pbWold2FSb4Hg8I+xEwelhZTZB/fpHz5r YmxkJTgOge3Mur0AW3s0wha7CV9dXsGHIvLf9f7s6fP/hDiVlY40UJMs3sq3a7a7+LYo e4mlf/b34m/I43FRAeYh8bmggT2SujPLOWx2ZG8mV3LxMofHrM4N9Aw0M6QlH1EofWy+ P0ps8okxYNfX2zGO8Cdke+OCpYCiuvDHeEs9zBQjqG7/sGQEClqcQaY9wYYX8EWZxnca 9SRA== X-Received: by 10.66.146.100 with SMTP id tb4mr43511001pab.70.1434331313678; Sun, 14 Jun 2015 18:21:53 -0700 (PDT) Received: from ?IPv6:2406:e007:6a73:1:28cc:dc4c:9703:6781? ([2406:e007:6a73:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id j9sm9749995pbq.92.2015.06.14.18.21.50 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Jun 2015 18:21:52 -0700 (PDT) Message-ID: <557E28AC.7060202@gmail.com> Date: Mon, 15 Jun 2015 13:21:48 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Toerless Eckert References: <557DE4C8.4050507@gmail.com> <20150614210632.GA23588@cisco.com> In-Reply-To: <20150614210632.GA23588@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima WG Subject: Re: [Anima] Domains X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jun 2015 01:21:56 -0000 Hi Toerless, On 15/06/2015 09:06, Toerless Eckert wrote: > First of all, i think it's not clear to me how we exactly define > "resource", so i think we should do that first, so that we talk > about the same thing. I was trying to be a bit more generic, but let's say that in the AN context, I mean an entity that is capable of being authenticated and authorised for AN purposes. Most times that would mean an ASA or a device capable of containing an ASA. > > Maybe we can start with use-cases and then try to explain how we would > solve them, then the right pictures of your model would IMHO evolve: One use case is what people were calling a bandwidth broker some years ago. If it's trying to allocate bandwidth across carrier-to-carrier boundaries, it could (IMHO) be modelled with any of my three diagrams. > Mergers/Aquisitions/splits/sale of nodes > > Lets say we wanted to solve this at the cert level: > Mechanisms required to make this seamless/online: > > a) establish 2nd cert > b) change 2nd cert to primary (owner cert) > c) delete 2nd cert > - establish AN neighboring to all neighbors with either 1st or 2nd cert. Hmm. That's a very ambitious use case. Will we really see people coding up an ASA for this? (There is presumably a trivial break-before-make solution: disconnect the nodes in question, reconnect them to their new network, and normal AN bootstrap will then follow. But doing it make- before-break with business continuity is a very different question.) > Merger would then be done as follow: > > Network wide: > 1. establish buying companies cert on all aquired companies > AN devices - using the registrar of that aquired company, because > only that will be trusted. At the end of this, you've got > contiguous AN connectivity. > > 2. change 2nd cert to primary, still with intent/authorization from > aquired company. After this step, there is only one primary > intent/autohrization - the one of the aquiring company. > > 3. delete aquired company certs. > > A problem with this is likely that cheap TPM hardware can only deal > with one cert, so the 2ndary certs need to be done in SW, which > than raises questions of online protection. And b) is a critical > operation. > > I think we won't be able to get around the complex "cert in SW" > linking back to a primary cert in HW to protect it, because we certainly > want to solve "autonomic VM on an autonomic Host". The VMs could of > course be in a different autonomic domain and would have to trust the host, > so the host would want to protect the VMs certs in the same way as his own > 2ndary certs. In general, for VMs and tenant systems, we're going to need some sort of nested "Russian dolls" arrangement, but I assume that would be in the "sub-domains" model. Rgds Brian > > cheers > Toerless > > > On Mon, Jun 15, 2015 at 08:32:08AM +1200, Brian E Carpenter wrote: >> Hi, >> >> I want to raise a point about the reference model that the authors of >> draft-behringer-anima-reference-model didn't settle before version -02 >> came out a few days ago. There's placeholder text in the draft about >> Sub-Domains and Cross-Domain Functionality. I suggested that we >> should also list "Overlapping Domains" as a topic. In other words, >> regions of a network could be considered to be in two different >> domains simultaneously. The question is whether we want our model >> to include that possibility? It certainly has implications for security. >> >> An example would be some sort of resource that needed to be shared >> between two otherwise separate domains; that resource could be considered >> to be in both domains. >> >> So I can see three possible models, shown in the folowing ASCII art: >> >> ------------------------------------------- >> | Shared Resource | >> | | >> | ------------------ ------------------ | >> | | Subddomain1 | | Subddomain2 | | >> | | | | | | >> | | | | | | >> | ------------------ ------------------ | >> | | >> ------------------------------------------- >> >> 1. Shared resource in outer domain >> >> ------------------ ------------------ >> | Domain1 | | Domain2 | >> | | | | >> | Shared | | | >> | Resource<|xxx|> | >> ------------------ ------------------ >> >> 2. Shared resource in one domain, with cross-domain access >> >> ---------------------- >> | Domain1 ------|------------------ >> | | Shared Domain2 | >> | |Resource | >> | | | | >> ---------------|------ | >> ------------------------- >> >> 3. Shared resource in domain overlap >> >> Regards >> Brian >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > From nobody Sun Jun 14 20:25:12 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F390A1B29F3 for ; Sun, 14 Jun 2015 20:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZwZnKfaDbsd for ; Sun, 14 Jun 2015 20:25:09 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC8691B29F1 for ; Sun, 14 Jun 2015 20:25:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4532; q=dns/txt; s=iport; t=1434338708; x=1435548308; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=inJa92rpqwpx15ZUltIVvmTlgV43ZIm3UqH8HHHhWX8=; b=FXL159RNHckVXyvDD8/t6h1AF+nDQUgfjIHSu9Phu5dyTSAsal3vYrIR kof/okSwE8OGMIctVgX63SPVZJ/Qxxvein7AMNUGCiHpCes0G02up+b/c /LjNl2bGkC/pakZB2islRlGRlgxpWGkHwyRZwIBOYDoMKn6sOqFkLUWQy Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ALBQDwRH5V/5pdJa1cgxBUX71mgVcKhXoCgSg6EgEBAQEBAQGBCoQiAQEBAwEBAQE3LQcLBQsLGAklDwUTNhMbiAwIDckEAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLRIQ9SQeDF4EWBYZ6hQFthB+CVItBAZgQJoQZHjGBBIFDAQEB X-IronPort-AV: E=Sophos;i="5.13,616,1427760000"; d="scan'208";a="7229744" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 15 Jun 2015 03:25:07 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t5F3P7Cv018223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Jun 2015 03:25:07 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 t5F3P6WO014255; Sun, 14 Jun 2015 20:25:06 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t5F3P662014252; Sun, 14 Jun 2015 20:25:06 -0700 Date: Sun, 14 Jun 2015 20:25:06 -0700 From: Toerless Eckert To: Brian E Carpenter Message-ID: <20150615032506.GA13907@cisco.com> References: <557DE4C8.4050507@gmail.com> <20150614210632.GA23588@cisco.com> <557E28AC.7060202@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <557E28AC.7060202@gmail.com> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Anima WG Subject: Re: [Anima] Domains X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jun 2015 03:25:11 -0000 On Mon, Jun 15, 2015 at 01:21:48PM +1200, Brian E Carpenter wrote: > One use case is what people were calling a bandwidth broker some years > ago. If it's trying to allocate bandwidth across carrier-to-carrier > boundaries, it could (IMHO) be modelled with any of my three diagrams. OK, thats a good use-case, i just fail to see how we would map this to the term (shared) resource). The agents on both sides, SP/Enterprise would have to establish mutual trust, which could easily be based on some ceremonies that permit the other sides cert or better CA to be used for authentication. > Hmm. That's a very ambitious use case. Will we really see people coding > up an ASA for this? (There is presumably a trivial break-before-make > solution: disconnect the nodes in question, reconnect them to their new > network, and normal AN bootstrap will then follow. But doing it make- > before-break with business continuity is a very different question.) Right. > > I think we won't be able to get around the complex "cert in SW" > > linking back to a primary cert in HW to protect it, because we certainly > > want to solve "autonomic VM on an autonomic Host". The VMs could of > > course be in a different autonomic domain and would have to trust the host, > > so the host would want to protect the VMs certs in the same way as his own > > 2ndary certs. > > In general, for VMs and tenant systems, we're going to need some sort > of nested "Russian dolls" arrangement, but I assume that would be in > the "sub-domains" model. Well, i think i understand how a host can provide virtual Cert storage, and how doing that would be similar to managing secondary Cert storage for its own use. I have not seen an explanation of a "sub-domain" model. We can put some additional info into the cert (eg: into subject name), and require certain cert/SN properties for authorization, but i am not sure about the generic model. Cheers Toerless > Rgds > Brian > > > > > cheers > > Toerless > > > > > > On Mon, Jun 15, 2015 at 08:32:08AM +1200, Brian E Carpenter wrote: > >> Hi, > >> > >> I want to raise a point about the reference model that the authors of > >> draft-behringer-anima-reference-model didn't settle before version -02 > >> came out a few days ago. There's placeholder text in the draft about > >> Sub-Domains and Cross-Domain Functionality. I suggested that we > >> should also list "Overlapping Domains" as a topic. In other words, > >> regions of a network could be considered to be in two different > >> domains simultaneously. The question is whether we want our model > >> to include that possibility? It certainly has implications for security. > >> > >> An example would be some sort of resource that needed to be shared > >> between two otherwise separate domains; that resource could be considered > >> to be in both domains. > >> > >> So I can see three possible models, shown in the folowing ASCII art: > >> > >> ------------------------------------------- > >> | Shared Resource | > >> | | > >> | ------------------ ------------------ | > >> | | Subddomain1 | | Subddomain2 | | > >> | | | | | | > >> | | | | | | > >> | ------------------ ------------------ | > >> | | > >> ------------------------------------------- > >> > >> 1. Shared resource in outer domain > >> > >> ------------------ ------------------ > >> | Domain1 | | Domain2 | > >> | | | | > >> | Shared | | | > >> | Resource<|xxx|> | > >> ------------------ ------------------ > >> > >> 2. Shared resource in one domain, with cross-domain access > >> > >> ---------------------- > >> | Domain1 ------|------------------ > >> | | Shared Domain2 | > >> | |Resource | > >> | | | | > >> ---------------|------ | > >> ------------------------- > >> > >> 3. Shared resource in domain overlap > >> > >> Regards > >> Brian > >> > >> _______________________________________________ > >> Anima mailing list > >> Anima@ietf.org > >> https://www.ietf.org/mailman/listinfo/anima > > -- --- Toerless Eckert, eckert@cisco.com From nobody Mon Jun 15 05:54:53 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 087B71B35EF for ; Mon, 15 Jun 2015 05:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqefVscVqYyA for ; Mon, 15 Jun 2015 05:54:50 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 094251B35B8 for ; Mon, 15 Jun 2015 05:54:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5387; q=dns/txt; s=iport; t=1434372891; x=1435582491; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=7gv0m1gytpCnYkA5AovWEt3BvLVzqTdEOfGThKh35XE=; b=W8Q3SqK7QW6xnA55nMcV+cQoMVVpthKyiaeO2zTjWIn0L4VHUxmhylAk 75MAtDkt7H+A/mddKO13XKZZDQv5vTJjJKx5uDmRzzUn7Z2oyQPTYVqw2 qI2obVOYNPsbs5Mg7JnVDpRxZHPyolgqgm54jDXwHZ+OT2/rI87eiGDzi Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ClBQDZyX5V/51dJa1cgxBUXwa8dYJGCoV4AoE0PBABAQEBAQEBgQqEIgEBAQQBAQE3NBcEAgEIEQQBAQsUCQcnCxQJCAIEARIIiCcNyhABAQEBAQEBAQEBAQEBAQEBAQEBAQETBIpCgQKEVTgGgxGBFgWGeoxhAYx0kwKDWyaCCxyBUm+BRoEBAQEB X-IronPort-AV: E=Sophos;i="5.13,618,1427760000"; d="scan'208";a="159554319" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP; 15 Jun 2015 12:54:50 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t5FCsnYv002182 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Jun 2015 12:54:49 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.179]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Mon, 15 Jun 2015 07:54:49 -0500 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , Anima WG Thread-Topic: [Anima] Domains Thread-Index: AQHQpuE76O8jwXjqQEChS4azZXo/Fp2tLVdg Date: Mon, 15 Jun 2015 12:54:48 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FE5DF6@xmb-rcd-x14.cisco.com> References: <557DE4C8.4050507@gmail.com> In-Reply-To: <557DE4C8.4050507@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.141] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Domains X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jun 2015 12:54:52 -0000 Brain,=20 Yes, this is a recurring question, and needs to be better explained. The sa= me question came up in Homenet a couple of years back, and this is how I an= swered it: In short, every autonomic entity has A SINGLE owner, and thus a = single domain.=20 Let's first define what we're talking about: I specifically state "autonomi= c entity" above. I.e., something that can negotiate on its own. That's what= we're concerned with here. Specifically, a queue in a router is NOT an aut= onomic entity. Therefore, even if several different domains use it, this ha= s to be managed by the autonomic entity (the router), which negotiates bits= and pieces for different domains. But the negotiator is the router, an aut= onomic entity, and that one has only one domain.=20 1. I claim for every autonomic entity out there, there is one single admini= strative "owner". The one who has root access, enable, short, the full admi= n rights.=20 Example: Take the homenet CPE. There is a managed services model, where the= SP maintains the CPE, there is the case where the homenet owner is control= ling the CPE. Inside the home network, there may be a device that is owned = by a utility, which maybe uses your network to communicate with sensors, or= uses your Internet connection to call home. You may have some influence on= the device settings, but the utility is the administrative owner.=20 2. The owner of the autonomic entity can grant some rights to other people.= =20 In your bandwidth broker example, there is still ONE autonomic entity who h= as full admin rights over a device (with all its queues, etc). This entity = grants rights to another domain to use a certain amount of buffering, whate= ver, on the device. A special case of that:=20 3. A device, owned by domain A, can run a container / VM / other virtualiza= tion concept that belongs to domain B.=20 Then you get to a case where there is the base hardware which is owned by o= ne domain, and say VMs running on top belonging to another domain. That is = supported, and we should have clear boundaries in this case.=20 4. Domain A can grant rights to for example a VM of domain B.=20 Example, on my home CPE, I run a container that belongs to the utility; i g= ive that access to my Internet connection, possibly to a specific SSID, wha= tever.=20 Clean separation, clean authorization of rights.=20 Looking at your pictures, I think all three show a "resource" as *not* bein= g an autonomic entity, but as a sub-part of an autonomic entity, example wa= s the link between two domains. This is where the confusion is coming from.= If we agree that we're talking about the domain of an *autonomic entity*, = then the picture is different, and hopefully clearer. Then it's up to the a= utonomic entities (and possibly domains) that share a non-autonomic entity = to negotiate its usage.=20 Does that make sense?=20 Michael > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E > Carpenter > Sent: 14 June 2015 22:32 > To: Anima WG > Subject: [Anima] Domains >=20 > Hi, >=20 > I want to raise a point about the reference model that the authors of dra= ft- > behringer-anima-reference-model didn't settle before version -02 came out > a few days ago. There's placeholder text in the draft about Sub-Domains a= nd > Cross-Domain Functionality. I suggested that we should also list > "Overlapping Domains" as a topic. In other words, regions of a network > could be considered to be in two different domains simultaneously. The > question is whether we want our model to include that possibility? It > certainly has implications for security. >=20 > An example would be some sort of resource that needed to be shared > between two otherwise separate domains; that resource could be > considered to be in both domains. >=20 > So I can see three possible models, shown in the folowing ASCII art: >=20 > ------------------------------------------- > | Shared Resource | > | | > | ------------------ ------------------ | > | | Subddomain1 | | Subddomain2 | | > | | | | | | > | | | | | | > | ------------------ ------------------ | > | | > ------------------------------------------- >=20 > 1. Shared resource in outer domain >=20 > ------------------ ------------------ > | Domain1 | | Domain2 | > | | | | > | Shared | | | > | Resource<|xxx|> | > ------------------ ------------------ >=20 > 2. Shared resource in one domain, with cross-domain access >=20 > ---------------------- > | Domain1 ------|------------------ > | | Shared Domain2 | > | |Resource | > | | | | > ---------------|------ | > ------------------------- >=20 > 3. Shared resource in domain overlap >=20 > Regards > Brian >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Mon Jun 15 07:18:08 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D99411B2D90 for ; Mon, 15 Jun 2015 07:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.928 X-Spam-Level: X-Spam-Status: No, score=-5.928 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63ACvR-PZuQX for ; Mon, 15 Jun 2015 07:18:04 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 7F20D1B2D67 for ; Mon, 15 Jun 2015 07:18:03 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 6374ADA64290D; Mon, 15 Jun 2015 14:17:58 +0000 (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 t5FEHOtA022880 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Jun 2015 16:17:58 +0200 Received: from [172.27.204.37] (135.239.27.38) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 15 Jun 2015 16:17:01 +0200 Message-ID: <557EDE5C.2070600@alcatel-lucent.com> Date: Mon, 15 Jun 2015 16:17:00 +0200 From: Laurent Ciavaglia Organization: Alcatel-Lucent Bell Labs France User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , Brian E Carpenter , Anima WG References: <557DE4C8.4050507@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FE5DF6@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FE5DF6@xmb-rcd-x14.cisco.com> Content-Type: multipart/alternative; boundary="------------030300050008020505010001" X-Originating-IP: [135.239.27.38] Archived-At: Subject: Re: [Anima] Domains X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jun 2015 14:18:08 -0000 --------------030300050008020505010001 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Dear Michael, Brian, all, I share and support Michael's explanation... and would add to it another level of "decoupling" : decoupling between the autonomic entity and its execution "host". In summary we would have: -An autonomic entity controlling one or more resources. Example: a load balancing optimization autonomic function controlling several routers. -The same autonomic entity executing over 'x'. 'x' could be one / part / all of the above routers' OS ; a NMS ; one or several VMs on remote computer(s). Here we are touching at two models: the coupling model and the deployment model. -The coupling model is whether the autonomic entity, its executing host(s) and the resource(s) are more or less coupled/integrated: . the load balancing optimization autonomic function runs on the OS of the routers it controls ; or . the load balancing optimization autonomic function runs on the OS of a computer and uses appropriate commands to effect control on the remote routers. -The deployment model is intrinsically linked to the capabilities/limitations of the coupling model and autonomic components designs but is also primarily concerned by how the autonomic networks is deployed: more or less centralized/distributed/mix and is dictated by other reasons/constraints such as cost, efficiency... As we are in the process of documenting ANIMA's reference model, I think we should describe (even briefly) the different setups and be more specific if we face behaviors / situations we wish to avoid or on the contrary wish to enforce. I don't think it is necessary to go into all the details of the coupling model, as it is/should be available in other references/WGs/SDOs (e.g. IaaS, PaaS and variations of...) On the resource aspect, we need the assumptions on how it is "shared" in the first place (model and interfaces)(as per Michael's message: "autonomic entities (and possibly domains) that share a non-autonomic entity to negotiate its usage". In order to operate properly, the autonomic network(s)/functions will have to know (Intent) the resources they are supposed to control, how they can access them (esp. if decoupled) and the extent of their usage rights over these resources. This is also key for the conflict / coordination aspects. If we don't (and I'm sure we don't) want autonomic networks to be static (configuration-wise), then we will have to cater for these aspects to be exchanged / discovered / negotiated (dynamically) among the participating peers. Finally, it would be nice to clarify the domain "boundary" or dimension: is it technology, administrative, topology...? HTH, best regards, Laurent. On 15/06/2015 14:54, Michael Behringer (mbehring) wrote: > Brain, > > Yes, this is a recurring question, and needs to be better explained. The same question came up in Homenet a couple of years back, and this is how I answered it: In short, every autonomic entity has A SINGLE owner, and thus a single domain. > > Let's first define what we're talking about: I specifically state "autonomic entity" above. I.e., something that can negotiate on its own. That's what we're concerned with here. Specifically, a queue in a router is NOT an autonomic entity. Therefore, even if several different domains use it, this has to be managed by the autonomic entity (the router), which negotiates bits and pieces for different domains. But the negotiator is the router, an autonomic entity, and that one has only one domain. > > 1. I claim for every autonomic entity out there, there is one single administrative "owner". The one who has root access, enable, short, the full admin rights. > > Example: Take the homenet CPE. There is a managed services model, where the SP maintains the CPE, there is the case where the homenet owner is controlling the CPE. Inside the home network, there may be a device that is owned by a utility, which maybe uses your network to communicate with sensors, or uses your Internet connection to call home. You may have some influence on the device settings, but the utility is the administrative owner. > > 2. The owner of the autonomic entity can grant some rights to other people. > > In your bandwidth broker example, there is still ONE autonomic entity who has full admin rights over a device (with all its queues, etc). This entity grants rights to another domain to use a certain amount of buffering, whatever, on the device. A special case of that: > > 3. A device, owned by domain A, can run a container / VM / other virtualization concept that belongs to domain B. > > Then you get to a case where there is the base hardware which is owned by one domain, and say VMs running on top belonging to another domain. That is supported, and we should have clear boundaries in this case. > > 4. Domain A can grant rights to for example a VM of domain B. > > Example, on my home CPE, I run a container that belongs to the utility; i give that access to my Internet connection, possibly to a specific SSID, whatever. > > Clean separation, clean authorization of rights. > > Looking at your pictures, I think all three show a "resource" as *not* being an autonomic entity, but as a sub-part of an autonomic entity, example was the link between two domains. This is where the confusion is coming from. If we agree that we're talking about the domain of an *autonomic entity*, then the picture is different, and hopefully clearer. Then it's up to the autonomic entities (and possibly domains) that share a non-autonomic entity to negotiate its usage. > > Does that make sense? > Michael > > > >> -----Original Message----- >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E >> Carpenter >> Sent: 14 June 2015 22:32 >> To: Anima WG >> Subject: [Anima] Domains >> >> Hi, >> >> I want to raise a point about the reference model that the authors of draft- >> behringer-anima-reference-model didn't settle before version -02 came out >> a few days ago. There's placeholder text in the draft about Sub-Domains and >> Cross-Domain Functionality. I suggested that we should also list >> "Overlapping Domains" as a topic. In other words, regions of a network >> could be considered to be in two different domains simultaneously. The >> question is whether we want our model to include that possibility? It >> certainly has implications for security. >> >> An example would be some sort of resource that needed to be shared >> between two otherwise separate domains; that resource could be >> considered to be in both domains. >> >> So I can see three possible models, shown in the folowing ASCII art: >> >> ------------------------------------------- >> | Shared Resource | >> | | >> | ------------------ ------------------ | >> | | Subddomain1 | | Subddomain2 | | >> | | | | | | >> | | | | | | >> | ------------------ ------------------ | >> | | >> ------------------------------------------- >> >> 1. Shared resource in outer domain >> >> ------------------ ------------------ >> | Domain1 | | Domain2 | >> | | | | >> | Shared | | | >> | Resource<|xxx|> | >> ------------------ ------------------ >> >> 2. Shared resource in one domain, with cross-domain access >> >> ---------------------- >> | Domain1 ------|------------------ >> | | Shared Domain2 | >> | |Resource | >> | | | | >> ---------------|------ | >> ------------------------- >> >> 3. Shared resource in domain overlap >> >> Regards >> Brian >> >> _______________________________________________ >> 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 > > -- Bien cordialement, Best regards, *Laurent Ciavaglia* Secure Cloud Networking Bell Labs | Alcatel Lucent phone: +33 160 402 636 email: laurent.ciavaglia@alcatel-lucent.com linkedin: laurentciavaglia address: Route de Villejust | 91620 Nozay | France --------------030300050008020505010001 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit Dear Michael, Brian, all,

I share and support Michael's explanation... and would add to it another level of "decoupling" : decoupling between the autonomic entity and its execution "host".

In summary we would have:
    -An autonomic entity controlling one or more resources. Example: a load balancing optimization autonomic function controlling several routers.
    -The same autonomic entity executing over 'x'. 'x' could be one / part / all of the above routers' OS ; a NMS ; one or several VMs on remote computer(s).

Here we are touching at two models: the coupling model and the deployment model.
-The coupling model is whether the autonomic entity, its executing host(s) and the resource(s) are more or less coupled/integrated:   
    . the load balancing optimization autonomic function runs on the OS of the routers it controls ; or
    . the load balancing optimization autonomic function runs on the OS of a computer and uses appropriate commands to effect control on the remote routers.

-The deployment model is intrinsically linked to the capabilities/limitations of the coupling model and autonomic components designs but is also primarily concerned by how the autonomic networks is deployed: more or less centralized/distributed/mix and is dictated by other reasons/constraints such as cost, efficiency...

As we are in the process of documenting ANIMA's reference model, I think we should describe (even briefly) the different setups and be more specific if we face behaviors / situations we wish to avoid or on the contrary wish to enforce.
I don't think it is necessary to go into all the details of the coupling model, as it is/should be available in other references/WGs/SDOs (e.g. IaaS, PaaS and variations of...)

On the resource aspect, we need the assumptions on how it is "shared" in the first place (model and interfaces)(as per Michael's message: "autonomic entities (and possibly domains) that share a non-autonomic entity to negotiate its usage".
In order to operate properly, the autonomic network(s)/functions will have to know (Intent) the resources they are supposed to control, how they can access them (esp. if decoupled) and the extent of their usage rights over these resources. This is also key for the conflict / coordination aspects.
If we don't (and I'm sure we don't) want autonomic networks to be static (configuration-wise), then we will have to cater for these aspects to be exchanged / discovered / negotiated (dynamically) among the participating peers.

Finally, it would be nice to clarify the domain "boundary" or dimension: is it technology, administrative, topology...?

HTH, best regards, Laurent.


On 15/06/2015 14:54, Michael Behringer (mbehring) wrote:
Brain, 

Yes, this is a recurring question, and needs to be better explained. The same question came up in Homenet a couple of years back, and this is how I answered it: In short, every autonomic entity has A SINGLE owner, and thus a single domain. 

Let's first define what we're talking about: I specifically state "autonomic entity" above. I.e., something that can negotiate on its own. That's what we're concerned with here. Specifically, a queue in a router is NOT an autonomic entity. Therefore, even if several different domains use it, this has to be managed by the autonomic entity (the router), which negotiates bits and pieces for different domains. But the negotiator is the router, an autonomic entity, and that one has only one domain. 

1. I claim for every autonomic entity out there, there is one single administrative "owner". The one who has root access, enable, short, the full admin rights. 

Example: Take the homenet CPE. There is a managed services model, where the SP maintains the CPE, there is the case where the homenet owner is controlling the CPE. Inside the home network, there may be a device that is owned by a utility, which maybe uses your network to communicate with sensors, or uses your Internet connection to call home. You may have some influence on the device settings, but the utility is the administrative owner. 

2. The owner of the autonomic entity can grant some rights to other people. 

In your bandwidth broker example, there is still ONE autonomic entity who has full admin rights over a device (with all its queues, etc). This entity grants rights to another domain to use a certain amount of buffering, whatever, on the device. A special case of that: 

3. A device, owned by domain A, can run a container / VM / other virtualization concept that belongs to domain B. 

Then you get to a case where there is the base hardware which is owned by one domain, and say VMs running on top belonging to another domain. That is supported, and we should have clear boundaries in this case. 

4. Domain A can grant rights to for example a VM of domain B. 

Example, on my home CPE, I run a container that belongs to the utility; i give that access to my Internet connection, possibly to a specific SSID, whatever. 

Clean separation, clean authorization of rights. 

Looking at your pictures, I think all three show a "resource" as *not* being an autonomic entity, but as a sub-part of an autonomic entity, example was the link between two domains. This is where the confusion is coming from. If we agree that we're talking about the domain of an *autonomic entity*, then the picture is different, and hopefully clearer. Then it's up to the autonomic entities (and possibly domains) that share a non-autonomic entity to negotiate its usage. 

Does that make sense? 
Michael




-----Original Message-----
From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E
Carpenter
Sent: 14 June 2015 22:32
To: Anima WG
Subject: [Anima] Domains

Hi,

I want to raise a point about the reference model that the authors of draft-
behringer-anima-reference-model didn't settle before version -02 came out
a few days ago. There's placeholder text in the draft about Sub-Domains and
Cross-Domain Functionality. I suggested that we should also list
"Overlapping Domains" as a topic. In other words, regions of a network
could be considered to be in two different domains simultaneously. The
question is whether we want our model to include that possibility? It
certainly has implications for security.

An example would be some sort of resource that needed to be shared
between two otherwise separate domains; that resource could be
considered to be in both domains.

So I can see three possible models, shown in the folowing ASCII art:

-------------------------------------------
|           Shared Resource               |
|                                         |
| ------------------   ------------------ |
| | Subddomain1    |   | Subddomain2    | |
| |                |   |                | |
| |                |   |                | |
| ------------------   ------------------ |
|                                         |
-------------------------------------------

1. Shared resource in outer domain

 ------------------   ------------------
 |   Domain1      |   |   Domain2      |
 |                |   |                |
 |         Shared |   |                |
 |       Resource<|xxx|>               |
 ------------------   ------------------

2. Shared resource in one domain, with cross-domain access

 ----------------------
 |   Domain1    ------|------------------
 |              | Shared    Domain2     |
 |              |Resource               |
 |              |     |                 |
 ---------------|------                 |
                -------------------------

3. Shared resource in domain overlap

Regards
    Brian

_______________________________________________
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

--

Bien cordialement, Best regards,

 

Laurent Ciavaglia

Secure Cloud Networking

Bell Labs | Alcatel Lucent

 

phone: +33 160 402 636

email: laurent.ciavaglia@alcatel-lucent.com

linkedin: laurentciavaglia

address: Route de Villejust | 91620 Nozay | France

--------------030300050008020505010001-- From nobody Mon Jun 15 08:58:56 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E321B3734 for ; Mon, 15 Jun 2015 08:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClSlobeJX7QZ for ; Mon, 15 Jun 2015 08:58:52 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0D381B36C2 for ; Mon, 15 Jun 2015 08:58:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11247; q=dns/txt; s=iport; t=1434383906; x=1435593506; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=FsZgnaXXq94NFDY2auMaEvFv/pEQYo1Iwb1nQLu6+Rw=; b=ac+BX67ZQKrUMDs9tcVsHMvJrqQgfcP5+vM2x4ywbJcwJfXRRmHnok+F No3Zc+0yFHoMS+Seay18UtM41vCqaRPXwdD8aytWthfjy09webrDwU639 FoEC36qJ/FoCkJc28ZSOHnn2tF3V/gA4gTE2jFN1UbT4XzzJ0B80GH6US w=; X-IronPort-AV: E=Sophos;i="5.13,618,1427760000"; d="scan'208";a="523389512" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 15 Jun 2015 15:58:25 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t5FFwNdd007927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Jun 2015 15:58: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 t5FFwM1t031676; Mon, 15 Jun 2015 08:58:22 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t5FFwM8s031675; Mon, 15 Jun 2015 08:58:22 -0700 Date: Mon, 15 Jun 2015 08:58:22 -0700 From: Toerless Eckert To: Laurent Ciavaglia Message-ID: <20150615155822.GC13907@cisco.com> References: <557DE4C8.4050507@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FE5DF6@xmb-rcd-x14.cisco.com> <557EDE5C.2070600@alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <557EDE5C.2070600@alcatel-lucent.com> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Anima WG , "Michael Behringer \(mbehring\)" Subject: Re: [Anima] Domains X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jun 2015 15:58:55 -0000 Thanks, Laurent Do you have specific thoughts on what you described as "behaviors / situations we wish to avoid or on the contrary wish to enforce" ? >From my side: I think i have already expressed in the past that i think ASA and AFs should be deployable dynamically - like applications, independently of each other (of course, as required with appropriate dependency resolution like in applications as well). So it would be good if we had language in the reference model to reflect that. Eg: Right now we have the constrained/unconstrained AN Nodes. Unconstrained is just full ANI, but does not specify requirements against ASAs. Constrained, we didn't define yet. So maybe more consistently: Dynamic ASA (AN Node) - can dynamically install ASA Constrained ASA (AN Node) - Eg: ASA are bundled with underlying OS. Constrained should just be a superset and we can define more sspecific terms, like "No custom ASA" or the like Full ANI (AN Node) - Replaces term "Unconstrained AN Node" -> Unconstrained ANI can still have constrained ASA. -> "Unconstrained" seems a bad word choice for ANI because the implications of the reference model is that the ANI has a defined functionality, and that means its never "unconstrained", so an implementation can at best do "full". This is IMHO different from ASA, which the reference model does not constrain in what they could do. Constrained ANI (AN Node) - Replaces term "Constrained AN Node" Cheers Toerless On Mon, Jun 15, 2015 at 04:17:00PM +0200, Laurent Ciavaglia wrote: > Dear Michael, Brian, all, > > I share and support Michael's explanation... and would add to it another > level of "decoupling" : decoupling between the autonomic entity and its > execution "host". > > In summary we would have: > -An autonomic entity controlling one or more resources. Example: a > load balancing optimization autonomic function controlling several routers. > -The same autonomic entity executing over 'x'. 'x' could be one / > part / all of the above routers' OS ; a NMS ; one or several VMs on > remote computer(s). > > Here we are touching at two models: the coupling model and the > deployment model. > -The coupling model is whether the autonomic entity, its executing > host(s) and the resource(s) are more or less coupled/integrated: > . the load balancing optimization autonomic function runs on the OS > of the routers it controls ; or > . the load balancing optimization autonomic function runs on the OS > of a computer and uses appropriate commands to effect control on the > remote routers. > > -The deployment model is intrinsically linked to the > capabilities/limitations of the coupling model and autonomic components > designs but is also primarily concerned by how the autonomic networks is > deployed: more or less centralized/distributed/mix and is dictated by > other reasons/constraints such as cost, efficiency... > > As we are in the process of documenting ANIMA's reference model, I think > we should describe (even briefly) the different setups and be more > specific if we face behaviors / situations we wish to avoid or on the > contrary wish to enforce. > I don't think it is necessary to go into all the details of the coupling > model, as it is/should be available in other references/WGs/SDOs (e.g. > IaaS, PaaS and variations of...) > > On the resource aspect, we need the assumptions on how it is "shared" in > the first place (model and interfaces)(as per Michael's message: > "autonomic entities (and possibly domains) that share a non-autonomic > entity to negotiate its usage". > In order to operate properly, the autonomic network(s)/functions will > have to know (Intent) the resources they are supposed to control, how > they can access them (esp. if decoupled) and the extent of their usage > rights over these resources. This is also key for the conflict / > coordination aspects. > If we don't (and I'm sure we don't) want autonomic networks to be static > (configuration-wise), then we will have to cater for these aspects to be > exchanged / discovered / negotiated (dynamically) among the > participating peers. > > Finally, it would be nice to clarify the domain "boundary" or dimension: > is it technology, administrative, topology...? > > HTH, best regards, Laurent. > > > On 15/06/2015 14:54, Michael Behringer (mbehring) wrote: > >Brain, > > > >Yes, this is a recurring question, and needs to be better explained. The > >same question came up in Homenet a couple of years back, and this is how I > >answered it: In short, every autonomic entity has A SINGLE owner, and thus > >a single domain. > > > >Let's first define what we're talking about: I specifically state > >"autonomic entity" above. I.e., something that can negotiate on its own. > >That's what we're concerned with here. Specifically, a queue in a router > >is NOT an autonomic entity. Therefore, even if several different domains > >use it, this has to be managed by the autonomic entity (the router), which > >negotiates bits and pieces for different domains. But the negotiator is > >the router, an autonomic entity, and that one has only one domain. > > > >1. I claim for every autonomic entity out there, there is one single > >administrative "owner". The one who has root access, enable, short, the > >full admin rights. > > > >Example: Take the homenet CPE. There is a managed services model, where > >the SP maintains the CPE, there is the case where the homenet owner is > >controlling the CPE. Inside the home network, there may be a device that > >is owned by a utility, which maybe uses your network to communicate with > >sensors, or uses your Internet connection to call home. You may have some > >influence on the device settings, but the utility is the administrative > >owner. > > > >2. The owner of the autonomic entity can grant some rights to other people. > > > >In your bandwidth broker example, there is still ONE autonomic entity who > >has full admin rights over a device (with all its queues, etc). This > >entity grants rights to another domain to use a certain amount of > >buffering, whatever, on the device. A special case of that: > > > >3. A device, owned by domain A, can run a container / VM / other > >virtualization concept that belongs to domain B. > > > >Then you get to a case where there is the base hardware which is owned by > >one domain, and say VMs running on top belonging to another domain. That > >is supported, and we should have clear boundaries in this case. > > > >4. Domain A can grant rights to for example a VM of domain B. > > > >Example, on my home CPE, I run a container that belongs to the utility; i > >give that access to my Internet connection, possibly to a specific SSID, > >whatever. > > > >Clean separation, clean authorization of rights. > > > >Looking at your pictures, I think all three show a "resource" as *not* > >being an autonomic entity, but as a sub-part of an autonomic entity, > >example was the link between two domains. This is where the confusion is > >coming from. If we agree that we're talking about the domain of an > >*autonomic entity*, then the picture is different, and hopefully clearer. > >Then it's up to the autonomic entities (and possibly domains) that share a > >non-autonomic entity to negotiate its usage. > > > >Does that make sense? > >Michael > > > > > > > >>-----Original Message----- > >>From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E > >>Carpenter > >>Sent: 14 June 2015 22:32 > >>To: Anima WG > >>Subject: [Anima] Domains > >> > >>Hi, > >> > >>I want to raise a point about the reference model that the authors of > >>draft- > >>behringer-anima-reference-model didn't settle before version -02 came out > >>a few days ago. There's placeholder text in the draft about Sub-Domains > >>and > >>Cross-Domain Functionality. I suggested that we should also list > >>"Overlapping Domains" as a topic. In other words, regions of a network > >>could be considered to be in two different domains simultaneously. The > >>question is whether we want our model to include that possibility? It > >>certainly has implications for security. > >> > >>An example would be some sort of resource that needed to be shared > >>between two otherwise separate domains; that resource could be > >>considered to be in both domains. > >> > >>So I can see three possible models, shown in the folowing ASCII art: > >> > >>------------------------------------------- > >>| Shared Resource | > >>| | > >>| ------------------ ------------------ | > >>| | Subddomain1 | | Subddomain2 | | > >>| | | | | | > >>| | | | | | > >>| ------------------ ------------------ | > >>| | > >>------------------------------------------- > >> > >>1. Shared resource in outer domain > >> > >> ------------------ ------------------ > >> | Domain1 | | Domain2 | > >> | | | | > >> | Shared | | | > >> | Resource<|xxx|> | > >> ------------------ ------------------ > >> > >>2. Shared resource in one domain, with cross-domain access > >> > >> ---------------------- > >> | Domain1 ------|------------------ > >> | | Shared Domain2 | > >> | |Resource | > >> | | | | > >> ---------------|------ | > >> ------------------------- > >> > >>3. Shared resource in domain overlap > >> > >>Regards > >> Brian > >> > >>_______________________________________________ > >>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 > > > > > > -- > > Bien cordialement, Best regards, > > *Laurent Ciavaglia* > > Secure Cloud Networking > > Bell Labs | Alcatel Lucent > > phone: +33 160 402 636 > > email: laurent.ciavaglia@alcatel-lucent.com > > > linkedin: laurentciavaglia > > address: Route de Villejust | 91620 Nozay | France > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- Toerless Eckert, eckert@cisco.com From nobody Mon Jun 15 13:29:39 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F253B1A8A85 for ; Mon, 15 Jun 2015 13:29:37 -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 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 KsfyzeGc2jy9 for ; Mon, 15 Jun 2015 13:29:36 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (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 006501A8A83 for ; Mon, 15 Jun 2015 13:29:35 -0700 (PDT) Received: by pdbki1 with SMTP id ki1so80416816pdb.1 for ; Mon, 15 Jun 2015 13:29:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=iS9wzzaccUAw7Mr/IDe81NMy0AT4ZQyEdtRosd5kdZo=; b=zGy8tBX4UcOUV/0NQNub5VSkgNJzY4uwTo7MGB3pP5jHI9jO8vaoQmp0pBcdwLBTOG DBY1cpu3xiGBmnJHK5QZCC1slyUVj2ssNAeRu4eJCZRxQ/1d+5Ey2D42yl/1j9y8j6of yvkQQg2WlO2deiUEMhBPQqtn4DZlidKgErdsPBJeqdN7jmAJAbGsAKvGMQQn3/BtFEBD /8nvmV6kqMFV1Z60bc76cUo+abcnft85tbDSysqggV+ByqqO77mHKMJFQPsirfKpMAwk 9N86Gox3DD2h2YcGrArBqbVLRbooz3ODPL3T0M8zF5gYMS+svG/7Egka6H+x04+FM2hM iakA== X-Received: by 10.68.68.203 with SMTP id y11mr51509021pbt.34.1434400175614; Mon, 15 Jun 2015 13:29:35 -0700 (PDT) Received: from ?IPv6:2406:e007:7f7c:1:28cc:dc4c:9703:6781? ([2406:e007:7f7c:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id j9sm13123662pdm.53.2015.06.15.13.29.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jun 2015 13:29:34 -0700 (PDT) Message-ID: <557F35A6.4020700@gmail.com> Date: Tue, 16 Jun 2015 08:29:26 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , Anima WG References: <557DE4C8.4050507@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FE5DF6@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FE5DF6@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Domains X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jun 2015 20:29:38 -0000 Michael (and I've also read Laurent's and Toerless's messages), On 16/06/2015 00:54, Michael Behringer (mbehring) wrote: > Brain, > > Yes, this is a recurring question, and needs to be better explained. The same question came up in Homenet a couple of years back, and this is how I answered it: In short, every autonomic entity has A SINGLE owner, and thus a single domain. We do need to be sure first what a "domain" is. An administrative boundary is not necessarily the same as a trust boundary. I can well imagine an entity that is in a given admin domain being trusted both in that domain and in another domain. In that sense, trust domains might overlap when admin domains cannot overlap. Also I'm pretty sure that domains can contain domains, both in the admin view and in the trust view. But the nesting might not be the same. Please note, I don't have a fixed opinion here, I just want clarity in our model and terminology. Brian > > Let's first define what we're talking about: I specifically state "autonomic entity" above. I.e., something that can negotiate on its own. That's what we're concerned with here. Specifically, a queue in a router is NOT an autonomic entity. Therefore, even if several different domains use it, this has to be managed by the autonomic entity (the router), which negotiates bits and pieces for different domains. But the negotiator is the router, an autonomic entity, and that one has only one domain. > > 1. I claim for every autonomic entity out there, there is one single administrative "owner". The one who has root access, enable, short, the full admin rights. > > Example: Take the homenet CPE. There is a managed services model, where the SP maintains the CPE, there is the case where the homenet owner is controlling the CPE. Inside the home network, there may be a device that is owned by a utility, which maybe uses your network to communicate with sensors, or uses your Internet connection to call home. You may have some influence on the device settings, but the utility is the administrative owner. > > 2. The owner of the autonomic entity can grant some rights to other people. > > In your bandwidth broker example, there is still ONE autonomic entity who has full admin rights over a device (with all its queues, etc). This entity grants rights to another domain to use a certain amount of buffering, whatever, on the device. A special case of that: > > 3. A device, owned by domain A, can run a container / VM / other virtualization concept that belongs to domain B. > > Then you get to a case where there is the base hardware which is owned by one domain, and say VMs running on top belonging to another domain. That is supported, and we should have clear boundaries in this case. > > 4. Domain A can grant rights to for example a VM of domain B. > > Example, on my home CPE, I run a container that belongs to the utility; i give that access to my Internet connection, possibly to a specific SSID, whatever. > > Clean separation, clean authorization of rights. > > Looking at your pictures, I think all three show a "resource" as *not* being an autonomic entity, but as a sub-part of an autonomic entity, example was the link between two domains. This is where the confusion is coming from. If we agree that we're talking about the domain of an *autonomic entity*, then the picture is different, and hopefully clearer. Then it's up to the autonomic entities (and possibly domains) that share a non-autonomic entity to negotiate its usage. > > Does that make sense? > Michael > > > >> -----Original Message----- >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E >> Carpenter >> Sent: 14 June 2015 22:32 >> To: Anima WG >> Subject: [Anima] Domains >> >> Hi, >> >> I want to raise a point about the reference model that the authors of draft- >> behringer-anima-reference-model didn't settle before version -02 came out >> a few days ago. There's placeholder text in the draft about Sub-Domains and >> Cross-Domain Functionality. I suggested that we should also list >> "Overlapping Domains" as a topic. In other words, regions of a network >> could be considered to be in two different domains simultaneously. The >> question is whether we want our model to include that possibility? It >> certainly has implications for security. >> >> An example would be some sort of resource that needed to be shared >> between two otherwise separate domains; that resource could be >> considered to be in both domains. >> >> So I can see three possible models, shown in the folowing ASCII art: >> >> ------------------------------------------- >> | Shared Resource | >> | | >> | ------------------ ------------------ | >> | | Subddomain1 | | Subddomain2 | | >> | | | | | | >> | | | | | | >> | ------------------ ------------------ | >> | | >> ------------------------------------------- >> >> 1. Shared resource in outer domain >> >> ------------------ ------------------ >> | Domain1 | | Domain2 | >> | | | | >> | Shared | | | >> | Resource<|xxx|> | >> ------------------ ------------------ >> >> 2. Shared resource in one domain, with cross-domain access >> >> ---------------------- >> | Domain1 ------|------------------ >> | | Shared Domain2 | >> | |Resource | >> | | | | >> ---------------|------ | >> ------------------------- >> >> 3. Shared resource in domain overlap >> >> Regards >> Brian >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > . > From nobody Mon Jun 15 13:44:00 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EEF31A905C; Mon, 15 Jun 2015 13:43:59 -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 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 y1pG_4Epu7_7; Mon, 15 Jun 2015 13:43:57 -0700 (PDT) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::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 C09571A905B; Mon, 15 Jun 2015 13:43:57 -0700 (PDT) Received: by pdbki1 with SMTP id ki1so80641498pdb.1; Mon, 15 Jun 2015 13:43:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8v5z0ImPmcppwD2VYEFAWvkXJga8QTVEPnQXgAovxa0=; b=XuTd6b2G/IjhpaO0Bs4WyEV8QPOt9pNrRqX+bpZhU2PI0mW1DyFMMdVFsqX5TNJElQ x9wt16+W3vVRzpWVAksiLij3EWgX//FMeRdis8Xo5e38QmILnbL/AMpJwt/Fi/Jdg/Op HEicPFBmLCn/fiKsTE1joaRjltIthkKKky5Fb/6CnRIBM18Ikwai3FWIWykke8MCvE3L IFdObZOyq43HUYlLilcr5zVAfgqxjKjwh6OvBGQGLmsh3gAuDynyaSiqyEZ9BdyPTLiq sjPr/utKD1HQyTnitrxco7RbK7PsWjbJr381B/zC21oeUgaBm3q5W2S8uqulZ3gnitUL 2Fvg== X-Received: by 10.70.1.103 with SMTP id 7mr52188614pdl.147.1434401037442; Mon, 15 Jun 2015 13:43:57 -0700 (PDT) Received: from ?IPv6:2406:e007:7f7c:1:28cc:dc4c:9703:6781? ([2406:e007:7f7c:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id wx8sm13112770pbc.1.2015.06.15.13.43.53 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jun 2015 13:43:56 -0700 (PDT) Message-ID: <557F3909.4010502@gmail.com> Date: Tue, 16 Jun 2015 08:43:53 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Anima WG , draft-ietf-homenet-prefix-assignment.all@ietf.org References: <20150615110116.19793.74572.idtracker@ietfa.amsl.com> In-Reply-To: <20150615110116.19793.74572.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150615110116.19793.74572.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Fwd: I-D Action: draft-ietf-homenet-prefix-assignment-07.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jun 2015 20:43:59 -0000 Hi Anima, I notice that this draft has just been revised (following IETF Last Call) to state this: Although it does not require to be configured to operate properly, it supports custom configuration by means of variable priority assignments, and can therefore be used in fully autonomic as well as professionally managed networks. That makes it apparently overlap with our charter. I personally believe that Anima participants should look at the draft. Its last call ended a few days ago, so it is now urgent to make any comments before it goes to the IESG for approval. Brian -------- Forwarded Message -------- Subject: I-D Action: draft-ietf-homenet-prefix-assignment-07.txt Date: Mon, 15 Jun 2015 04:01:16 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: homenet@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Home Networking Working Group of the IETF. Title : Distributed Prefix Assignment Algorithm Authors : Pierre Pfister Benjamin Paterson Jari Arkko Filename : draft-ietf-homenet-prefix-assignment-07.txt Pages : 19 Date : 2015-06-15 Abstract: This document specifies a distributed algorithm for automatic prefix assignment. Thus it provides an alternative to manual or centralized prefix and address assignment techniques. Given a set of delegated prefixes, it ensures that at most one prefix is assigned from each delegated prefix to each link. Nodes may assign available prefixes to the links they are directly connected to, or for other private purposes. The algorithm eventually converges and ensures that all assigned prefixes do not overlap. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-homenet-prefix-assignment/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-homenet-prefix-assignment-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-prefix-assignment-07 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Jun 15 17:02:17 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45DE61A89B5 for ; Mon, 15 Jun 2015 17:02:15 -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 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 yKfZtFtNE2ly for ; Mon, 15 Jun 2015 17:02:14 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (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 F29DF1A8A8C for ; Mon, 15 Jun 2015 17:02:13 -0700 (PDT) Received: by pabqy3 with SMTP id qy3so827292pab.3 for ; Mon, 15 Jun 2015 17:02:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jItI5De4iGROu8EL3ncSPeCBmGKyqleJwkEeDTEfbBk=; b=kRfo5/7TXI11Xy6b7EMJw4+uWPsiLbfw4lqedGj7mbTr998HCvgXeSjx5y7fX+6Wt3 8LcNW5cfzQtMBeqfWOn8PdkXN5+JCJTVXE4Cs+9wVFpBSeKXLbDRwCHFQi6m6kBv09Tz Dx2ypbYFBBdVpg1T2nRxAbXLTHYbzJekS7vbkxOUP5eBjlPTeqQMUB+ybDHsNlat9uXV JURRlMcHMzTn8a7PRU3j4NP2H26WM5Ddg3ooTttjcYIk4b+GVezazhG5/Kzpe0r8bDkv EcrNJmY7JezGosovk/nWOaHWBgJMYFUYIICHPKZAvvyNLFzpnYOtEjCy0J3UvL5aVg9s 1/hQ== X-Received: by 10.70.93.36 with SMTP id cr4mr52225692pdb.68.1434412933661; Mon, 15 Jun 2015 17:02:13 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by mx.google.com with ESMTPSA id ck4sm13327916pbc.67.2015.06.15.17.02.10 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jun 2015 17:02:12 -0700 (PDT) Message-ID: <557F6784.2090708@gmail.com> Date: Tue, 16 Jun 2015 12:02:12 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Anima WG References: <20150612050737.22507.16247.idtracker@ietfa.amsl.com> In-Reply-To: <20150612050737.22507.16247.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-liu-anima-intent-distribution-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jun 2015 00:02:15 -0000 Hi, I think this is useful to start the discussion on the nature and requirements for intent distribution. A few first comments: 1. I agree that potentially intent could be injected anywhere (with some sort of authorization). In many networks it will actually come from a central NOC, but the flexibility is good. 2. As far as the signaling protocol goes, I take this as a fairly strong indication that we need an unsolicited mechanism to flood intent (as well a solicited model where an ASA discovers a source of intent and requests the intent data). Since we already need a safe mechanism to flood discovery, I don't think this will be too hard. 3. For the moment I think details of the protocol element don't matter too much - if we do change GDNP to a JSON/CBOR model, it would look different but would have the same semantics. Brian From nobody Mon Jun 15 17:15:44 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3371B31E8 for ; Mon, 15 Jun 2015 17:15:43 -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 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 ryKc97fEIOhm for ; Mon, 15 Jun 2015 17:15:42 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::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 313831B3192 for ; Mon, 15 Jun 2015 17:15:42 -0700 (PDT) Received: by pdbnf5 with SMTP id nf5so1179114pdb.2 for ; Mon, 15 Jun 2015 17:15:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=kTORo4zQG9ug7JxVj+bZpp+4/4LvjdArcIXEYnJhTOc=; b=qiaz7zsveV1HlQcF9bylcCT+9j00cL6Ukmt/SIYNgv16UWD1twVST8hz21KCdPyUK9 9xM869Pvw1biDtKMSzNYnrAzOsU0cZNPxeELDg8vLSW6FE65qrW/3d547KTlrZwrfG0S P/dneXAYD+vb6zqZiuMGQN8y97zD4oiJqDxxekKlFTSeaaj5LEih2D00jxnUxc9tRKx/ jCyV9qHzCICBuT1C+nCY1WELp4XGT3GWLT+k+Uhz5nPjnqgZEE0e8fLKnDi8ydluumi1 FuahtoT6soXLgNbqWx10CB4Xjp2yEF8Fv2HCs+Pc0m4YNdHc0VV7PPQLKso2wkEHBIYK VyEg== X-Received: by 10.68.232.194 with SMTP id tq2mr53107799pbc.90.1434413741754; Mon, 15 Jun 2015 17:15:41 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by mx.google.com with ESMTPSA id eu5sm13355188pbb.44.2015.06.15.17.15.39 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jun 2015 17:15:40 -0700 (PDT) Message-ID: <557F6AAB.7050203@gmail.com> Date: Tue, 16 Jun 2015 12:15:39 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Anima WG References: <20150612064329.8725.45070.idtracker@ietfa.amsl.com> In-Reply-To: <20150612064329.8725.45070.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-du-anima-an-intent-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jun 2015 00:15:43 -0000 Hi, Just to see if I am understanding the ideas in this draft, here's a sketch of how to represent the intent for the draft-jiang-anima-prefix-management use case in JSON terms. (If we end up with JSON for the signaling protocol, I will argue for JSON for intent too.) Obviously this is hand-waving; the main question is whether it can express the sort of things we might want to support in intent. {"example_intent": [{"intent_type": "IPv6_prefix"}, {"autonomic_domain": "Customer_X_intranet"}, {"version": 73}, {"date": "20150616"}, {"content": [{"max_prefix_length": 60}, {"min_prefix_length": 48}, {"max_prefixes_per_customer": 2}, {"SLA_check_needed": true}, {"enable_log": false}]}]} Regards Brian From nobody Tue Jun 16 01:00:47 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D837A1B334A for ; Tue, 16 Jun 2015 01:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eV02_nc6FDn6 for ; Tue, 16 Jun 2015 01:00:44 -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 7208B1B3341 for ; Tue, 16 Jun 2015 01:00:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BTV28764; Tue, 16 Jun 2015 08:00:39 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 16 Jun 2015 09:00:06 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.186]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Tue, 16 Jun 2015 15:59:59 +0800 From: "Liubing (Leo)" To: Brian E Carpenter , Anima WG Thread-Topic: [Anima] I-D Action: draft-liu-anima-intent-distribution-00.txt Thread-Index: AQHQpM29ycvbbrLZ6Um211kGHwVg6Z2tv6wAgAEEmiA= Date: Tue, 16 Jun 2015 07:59:58 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45A6796C28@nkgeml506-mbx.china.huawei.com> References: <20150612050737.22507.16247.idtracker@ietfa.amsl.com> <557F6784.2090708@gmail.com> In-Reply-To: <557F6784.2090708@gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] I-D Action: draft-liu-anima-intent-distribution-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jun 2015 08:00:46 -0000 Hi Brian, Thanks for your quick comments. Please see replies inline. > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E > Carpenter > Sent: Tuesday, June 16, 2015 8:02 AM > To: Anima WG > Subject: Re: [Anima] I-D Action: draft-liu-anima-intent-distribution-00.t= xt >=20 > Hi, >=20 > I think this is useful to start the discussion on the nature and requirem= ents > for intent distribution. [Bing] Yes, let's identify the requirements first. > A few first comments: >=20 > 1. I agree that potentially intent could be injected anywhere (with some = sort > of authorization). In many networks it will actually come from a central = NOC, > but the flexibility is good. [Bing] NOC is for sure a typical use case. For the "arbitrary injection poi= nt" case, my guess is that the ANI relevant intent might require or at leas= t benefit from it. > 2. As far as the signaling protocol goes, I take this as a fairly strong > indication that we need an unsolicited mechanism to flood intent (as well= a > solicited model where an ASA discovers a source of intent and requests th= e > intent data). Since we already need a safe mechanism to flood discovery, = I > don't think this will be too hard. [Bing] Indeed. We used to have a brief discussion about unsolicited synchro= nization in previous version of the GDNP draft. Maybe it's good restore it = back and extent the semantic. For flooding mechanism, this draft provides a specific solution as describe= d in https://tools.ietf.org/html/draft-liu-anima-intent-distribution-00#sec= tion-3.2.3 . I think this applies to discovery too. But for sure, this is NOT to settle down the solution by myself, it is food= for discussion. > 3. For the moment I think details of the protocol element don't matter to= o > much - if we do change GDNP to a JSON/CBOR model, it would look > different but would have the same semantics. [Bing] Yes, the specific designs are food for discussion at current stage.= =20 There is one design principle I'd like to ask all of you: do we need a dedi= cated Intent Distribution message, or we just consider Intent Distribution = as a specific content of the Unsolicited Messages? The draft follows the latter approach, since we thought of Intent Distribut= ion as an affair that the ASA needs to handle rather than the protocol mode= l handling it. Best regards, Bing > Brian >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Tue Jun 16 01:12:30 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE601A00DC for ; Tue, 16 Jun 2015 01:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.529 X-Spam-Level: X-Spam-Status: No, score=-13.529 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jo-5ri-X0vLJ for ; Tue, 16 Jun 2015 01:12:18 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FCA21A0070 for ; Tue, 16 Jun 2015 01:12:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=48665; q=dns/txt; s=iport; t=1434442338; x=1435651938; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=bcLDgMF3gl/w7lOIJm9Ows3IuHUtLiAFYqdlcws+IlU=; b=dTzWwVfmeArvr5mgjbWQlpcfeChfgqB+odCeDcx3XWrR4hSpBGY97BmC ZxJnHMDGkK8MvSzWkaBuCmhxM6uPkaPEbFnTliklHi9kiBM54DDkCrBnV S1G/wnX823stofn1SQUHaMTEXbBRTbx+b1t+4e+mabHgy0nV+HAXxIk2t Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CeBgC82X9V/4ENJK1bgkVLVF8GvS88gXEZAQmFeAKBODwQAQEBAQEBAYEKhCIBAQEEAQEBKkEXAgICAQgRBAEBCxYBBgcbDAsUCQgCBAESCIgnDcwrAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwSKPoEChCMRASAFKAoBBoMRgRYFhnqMYQGET4JVhVCTAoNbERWCCxyBUm+BDDqBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,624,1427760000"; d="scan'208,217";a="159768309" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP; 16 Jun 2015 08:12:16 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t5G8CGFm002249 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Jun 2015 08:12:16 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.179]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Tue, 16 Jun 2015 03:12:15 -0500 From: "Michael Behringer (mbehring)" To: Laurent Ciavaglia , "Brian E Carpenter" , Anima WG Thread-Topic: [Anima] Domains Thread-Index: AQHQpuE76O8jwXjqQEChS4azZXo/Fp2tLVdggADEmwCAANREcA== Date: Tue, 16 Jun 2015 08:12:14 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FED61D@xmb-rcd-x14.cisco.com> References: <557DE4C8.4050507@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FE5DF6@xmb-rcd-x14.cisco.com> <557EDE5C.2070600@alcatel-lucent.com> In-Reply-To: <557EDE5C.2070600@alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.132] Content-Type: multipart/alternative; boundary="_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FED61Dxmbrcdx14ciscoc_" MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Domains X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jun 2015 08:12:28 -0000 --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FED61Dxmbrcdx14ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is a good discussion, you bring up some very good points. Toerless is = already one step further, let me first understand how your statements and m= y understanding match. Coupling: The way I see it: The ANI *is* coupled with the node and its OS. = Yes, there are two variants (constrained ANI and "full" ANI), let's leave t= hat out for now. But, do you agree that the *infrastructure* is the propert= y of a node. It does NOT move, it is actually coupled to the node. When you talk about decoupling, in my mind that is true for the ASAs. Those= should be completely de-coupled, and this is in line with Toerless' thinki= ng: You can run an ASA anywhere, possibly move it around, instantiate it on= ly for a certain time frame, etc. Do we agree on that? Then, we need to bring into the reference model essent= ially those statements: "ANI - coupled to a node", and "ASA - decoupled". (= And, you're right - that needs to be mentioned!) Then, let me re-phrase the load balancing example in my words, to see wheth= er I got it: The loadbalancing intelligence is an ASA, as such it is not c= oupled to any OS, and can run anywhere. And yes, it can control resources o= n 1) other AN nodes and 2) non-AN resources, which isn't reflected in the m= odel yet either. Are we in sync? To the "boundary" discussion: are you referring to a particular section in = the reference model? Not quite clear what you mean here. Michael From: Laurent Ciavaglia [mailto:Laurent.Ciavaglia@alcatel-lucent.com] Sent: 15 June 2015 16:17 To: Michael Behringer (mbehring); Brian E Carpenter; Anima WG Subject: Re: [Anima] Domains Dear Michael, Brian, all, I share and support Michael's explanation... and would add to it another le= vel of "decoupling" : decoupling between the autonomic entity and its execu= tion "host". In summary we would have: -An autonomic entity controlling one or more resources. Example: a load= balancing optimization autonomic function controlling several routers. -The same autonomic entity executing over 'x'. 'x' could be one / part = / all of the above routers' OS ; a NMS ; one or several VMs on remote compu= ter(s). Here we are touching at two models: the coupling model and the deployment m= odel. -The coupling model is whether the autonomic entity, its executing host(s) = and the resource(s) are more or less coupled/integrated: . the load balancing optimization autonomic function runs on the OS of = the routers it controls ; or . the load balancing optimization autonomic function runs on the OS of = a computer and uses appropriate commands to effect control on the remote ro= uters. -The deployment model is intrinsically linked to the capabilities/limitatio= ns of the coupling model and autonomic components designs but is also prima= rily concerned by how the autonomic networks is deployed: more or less cent= ralized/distributed/mix and is dictated by other reasons/constraints such a= s cost, efficiency... As we are in the process of documenting ANIMA's reference model, I think we= should describe (even briefly) the different setups and be more specific i= f we face behaviors / situations we wish to avoid or on the contrary wish t= o enforce. I don't think it is necessary to go into all the details of the coupling mo= del, as it is/should be available in other references/WGs/SDOs (e.g. IaaS, = PaaS and variations of...) On the resource aspect, we need the assumptions on how it is "shared" in th= e first place (model and interfaces)(as per Michael's message: "autonomic e= ntities (and possibly domains) that share a non-autonomic entity to negotia= te its usage". In order to operate properly, the autonomic network(s)/functions will have = to know (Intent) the resources they are supposed to control, how they can a= ccess them (esp. if decoupled) and the extent of their usage rights over th= ese resources. This is also key for the conflict / coordination aspects. If we don't (and I'm sure we don't) want autonomic networks to be static (c= onfiguration-wise), then we will have to cater for these aspects to be exch= anged / discovered / negotiated (dynamically) among the participating peers= . Finally, it would be nice to clarify the domain "boundary" or dimension: is= it technology, administrative, topology...? HTH, best regards, Laurent. On 15/06/2015 14:54, Michael Behringer (mbehring) wrote: Brain, Yes, this is a recurring question, and needs to be better explained. The sa= me question came up in Homenet a couple of years back, and this is how I an= swered it: In short, every autonomic entity has A SINGLE owner, and thus a = single domain. Let's first define what we're talking about: I specifically state "autonomi= c entity" above. I.e., something that can negotiate on its own. That's what= we're concerned with here. Specifically, a queue in a router is NOT an aut= onomic entity. Therefore, even if several different domains use it, this ha= s to be managed by the autonomic entity (the router), which negotiates bits= and pieces for different domains. But the negotiator is the router, an aut= onomic entity, and that one has only one domain. 1. I claim for every autonomic entity out there, there is one single admini= strative "owner". The one who has root access, enable, short, the full admi= n rights. Example: Take the homenet CPE. There is a managed services model, where the= SP maintains the CPE, there is the case where the homenet owner is control= ling the CPE. Inside the home network, there may be a device that is owned = by a utility, which maybe uses your network to communicate with sensors, or= uses your Internet connection to call home. You may have some influence on= the device settings, but the utility is the administrative owner. 2. The owner of the autonomic entity can grant some rights to other people. In your bandwidth broker example, there is still ONE autonomic entity who h= as full admin rights over a device (with all its queues, etc). This entity = grants rights to another domain to use a certain amount of buffering, whate= ver, on the device. A special case of that: 3. A device, owned by domain A, can run a container / VM / other virtualiza= tion concept that belongs to domain B. Then you get to a case where there is the base hardware which is owned by o= ne domain, and say VMs running on top belonging to another domain. That is = supported, and we should have clear boundaries in this case. 4. Domain A can grant rights to for example a VM of domain B. Example, on my home CPE, I run a container that belongs to the utility; i g= ive that access to my Internet connection, possibly to a specific SSID, wha= tever. Clean separation, clean authorization of rights. Looking at your pictures, I think all three show a "resource" as *not* bein= g an autonomic entity, but as a sub-part of an autonomic entity, example wa= s the link between two domains. This is where the confusion is coming from.= If we agree that we're talking about the domain of an *autonomic entity*, = then the picture is different, and hopefully clearer. Then it's up to the a= utonomic entities (and possibly domains) that share a non-autonomic entity = to negotiate its usage. Does that make sense? Michael -----Original Message----- From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E Carpenter Sent: 14 June 2015 22:32 To: Anima WG Subject: [Anima] Domains Hi, I want to raise a point about the reference model that the authors of draft= - behringer-anima-reference-model didn't settle before version -02 came out a few days ago. There's placeholder text in the draft about Sub-Domains and Cross-Domain Functionality. I suggested that we should also list "Overlapping Domains" as a topic. In other words, regions of a network could be considered to be in two different domains simultaneously. The question is whether we want our model to include that possibility? It certainly has implications for security. An example would be some sort of resource that needed to be shared between two otherwise separate domains; that resource could be considered to be in both domains. So I can see three possible models, shown in the folowing ASCII art: ------------------------------------------- | Shared Resource | | | | ------------------ ------------------ | | | Subddomain1 | | Subddomain2 | | | | | | | | | | | | | | | ------------------ ------------------ | | | ------------------------------------------- 1. Shared resource in outer domain ------------------ ------------------ | Domain1 | | Domain2 | | | | | | Shared | | | | Resource<|xxx|> | ------------------ ------------------ 2. Shared resource in one domain, with cross-domain access ---------------------- | Domain1 ------|------------------ | | Shared Domain2 | | |Resource | | | | | ---------------|------ | ------------------------- 3. Shared resource in domain overlap Regards Brian _______________________________________________ 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 -- Bien cordialement, Best regards, Laurent Ciavaglia Secure Cloud Networking Bell Labs | Alcatel Lucent phone: +33 160 402 636 email: laurent.ciavaglia@alcatel-lucent.com linkedin: laurentciavaglia address: Route de Villejust | 91620 Nozay | France --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FED61Dxmbrcdx14ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= This is a g= ood discussion, you bring up some very good points. Toerless is already one= step further, let me first understand how your statements and my understanding match.

= Coupling: T= he way I see it: The ANI *is= * coupled with the node and its OS. Yes, there are two variants (constrained ANI and “full” ANI), let’s= leave that out for now. But, do you agree that the *infrastructure* is the property of a node. It does= NOT move, it is actually coupled to the node.

= When you ta= lk about decoupling, in my mind that is true for the ASAs. Those should be = completely de-coupled, and this is in line with Toerless’ thinking: You can run an ASA anywhere, possibly move = it around, instantiate it only for a certain time frame, etc.

= Do we agree= on that? Then, we need to bring into the reference model essentially those= statements: “ANI – coupled to a node”, and “ASA – decoupled”. (And, you’re right – that= needs to be mentioned!)

= Then, let m= e re-phrase the load balancing example in my words, to see whether I got it= : The  loadbalancing intelligence is an ASA, as such it is not coupled to any OS, and can run anywhere. And yes, it can= control resources on 1) other AN nodes and 2) non-AN resources, which isn&= #8217;t reflected in the model yet either.

= Are we in s= ync?

= To the R= 20;boundary” discussion: are you referring to a particular section in= the reference model? Not quite clear what you mean here.

= Michael

=  =

From: Laurent Ciavaglia [mailto:Laurent.Ciavaglia@alcatel-lucent.com]
Sent: 15 June 2015 16:17
To: Michael Behringer (mbehr= ing); Brian E Carpenter; Anima WG
Subject: Re: [Anima] Domains=

=  <= /font>

Dear Michael, Brian, all,

I share and support Michael's explanation... and would add to it another le= vel of "decoupling" : decoupling between the autonomic entity and= its execution "host".

In summary we would have:
    -An autonomic entity controlling one or more resources. = Example: a load balancing optimization autonomic function controlling sever= al routers.
    -The same autonomic entity executing over 'x'. 'x' could= be one / part / all of the above routers' OS ; a NMS ; one or several VMs = on remote computer(s).

Here we are touching at two models: the coupling model and the deployment m= odel.
-The coupling model is whether the autonomic entity, its executing host(s) = and the resource(s) are more or less coupled/integrated:   
    . the load balancing optimization autonomic function runs on the OS of the routers it controls ; or
    . the load balancing optimization autonomic function run= s on the OS of a computer and uses appropriate commands to effect control o= n the remote routers.

-The deployment model is intrinsically linked to the capabilities/limitatio= ns of the coupling model and autonomic components designs but is also prima= rily concerned by how the autonomic networks is deployed: more or less cent= ralized/distributed/mix and is dictated by other reasons/constraints such as cost, efficiency...

As we are in the process of documenting ANIMA's reference model, I think we= should describe (even briefly) the different setups and be more specific i= f we face behaviors / situations we wish to avoid or on the contrary wish t= o enforce.
I don't think it is necessary to go into all the details of the coupling mo= del, as it is/should be available in other references/WGs/SDOs (e.g. IaaS, = PaaS and variations of...)

On the resource aspect, we need the assumptions on how it is "shared&q= uot; in the first place (model and interfaces)(as per Michael's message: &q= uot;autonomic entities (and possibly domains) that share a non-autonomic en= tity to negotiate its usage".
In order to operate properly, the autonomic network(s)/functions will have = to know (Intent) the resources they are supposed to control, how they can a= ccess them (esp. if decoupled) and the extent of their usage rights over th= ese resources. This is also key for the conflict / coordination aspects.
If we don't (and I'm sure we don't) want autonomic networks to be static (configu= ration-wise), then we will have to cater for these aspects to be exchanged / discovered / negotiated (dynamically) among the participating peers.

Finally, it would be nice to clarify the domain "boundary" or dim= ension: is it technology, administrative, topology...?

HTH, best regards, Laurent.

On 15/06/2015 14:54, Michael Behringer (mbehring) = wrote:

Brain, 
 
Yes, this is a recurring question, and =
needs to be better explained. The same question came up in Homenet a couple=
 of years back, and this is how I answered it: In short, every autonomic en=
tity has A SINGLE owner, and thus a single domain. 
 
Let's first define what we're talking a=
bout: I specifically state "autonomic entity" above. I.e., someth=
ing that can negotiate on its own. That's what we're concerned with here. S=
pecifically, a queue in a router is NOT an autonomic entity. Therefore, eve=
n if several different domains use it, this has to be managed by the autono=
mic entity (the router), which negotiates bits and pieces for different dom=
ains. But the negotiator is the router, an autonomic entity, and that one h=
as only one domain. 
 
1. I claim for every autonomic entity o=
ut there, there is one single administrative "owner". The one who=
 has root access, enable, short, the full admin rights. <=
/font>
 
Example: Take the homenet CPE. There is=
 a managed services model, where the SP maintains the CPE, there is the cas=
e where the homenet owner is controlling the CPE. Inside the home network, =
there may be a device that is owned by a utility, which maybe uses your net=
work to communicate with sensors, or uses your Internet connection to call =
home. You may have some influence on the device settings, but the utility i=
s the administrative owner. 
 
2. The owner of the autonomic entity ca=
n grant some rights to other people. 
 
In your bandwidth broker example, there=
 is still ONE autonomic entity who has full admin rights over a device (wit=
h all its queues, etc). This entity grants rights to another domain to use =
a certain amount of buffering, whatever, on the device. A special case of t=
hat: 
 
3. A device, owned by domain A, can run=
 a container / VM / other virtualization concept that belongs to domain B. =

 
Then you get to a case where there is t=
he base hardware which is owned by one domain, and say VMs running on top b=
elonging to another domain. That is supported, and we should have clear bou=
ndaries in this case. 
 
4. Domain A can grant rights to for exa=
mple a VM of domain B. 
 
Example, on my home CPE, I run a contai=
ner that belongs to the utility; i give that access to my Internet connecti=
on, possibly to a specific SSID, whatever. 
 
Clean separation, clean authorization o=
f rights. 
 
Looking at your pictures, I think all t=
hree show a "resource" as *not* being an autonomic entity, but as=
 a sub-part of an autonomic entity, example was the link between two domain=
s. This is where the confusion is coming from. If we agree that we're talki=
ng about the domain of an *autonomic entity*, then the picture is different=
, and hopefully clearer. Then it's up to the autonomic entities (and possib=
ly domains) that share a non-autonomic entity to negotiate its usage. =

 
Does that make sense? 
Michael
 
 
 
-----Original Message-----
From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E
Carpenter

Sent: 14 June 2015 22:32


To: Anima WG

Subject: [Anima] Domains


 


Hi,


 


I want to raise a point about the refer=
ence model that the authors of draft-


behringer-anima-reference-model didn't =
settle before version -02 came out


a few days ago. There's placeholder tex=
t in the draft about Sub-Domains and


Cross-Domain Functionality. I suggested=
 that we should also list


"Overlapping Domains" as a to=
pic. In other words, regions of a network


could be considered to be in two differ=
ent domains simultaneously. The


question is whether we want our model t=
o include that possibility? It


certainly has implications for security=
.


 


An example would be some sort of resour=
ce that needed to be shared


between two otherwise separate domains;=
 that resource could be


considered to be in both domains.<=
/o:p>


 


So I can see three possible models, sho=
wn in the folowing ASCII art:


 


---------------------------------------=
----


|      &n=
bsp;    Shared Resource      &=
nbsp;        |<=
/pre>

|      &n=
bsp;            =
;            &n=
bsp;         |


| ------------------   ------=
------------ |


| | Subddomain1    |&nbs=
p;  | Subddomain2    | |


| |      =
          |   | =
;            &n=
bsp;  | |


| |      =
          |   | =
;            &n=
bsp;  | |


| ------------------   ------=
------------ |


|      &n=
bsp;            =
;            &n=
bsp;         |


---------------------------------------=
----


 


1. Shared resource in outer domain=



 


 ------------------   -------=
-----------


 |   Domain1   =
;   |   |   Domain2    &n=
bsp; |


 |      &=
nbsp;         |   | =
            &nb=
sp;  |


 |      &=
nbsp;  Shared |   |       =
;         |


 |       =
Resource<|xxx|>         =
      |


 ------------------   -------=
-----------


 


2. Shared resource in one domain, with =
cross-domain access


 


 ----------------------


 |   Domain1   =
; ------|------------------


 |      &=
nbsp;       | Shared    Domain=
2     |


 |      &=
nbsp;       |Resource    =
           |


 |      &=
nbsp;       |     | =
            &nb=
sp;   |


 ---------------|------  &nbs=
p;            &=
nbsp; |


      &nb=
sp;         -----------------------=
--


 


3. Shared resource in domain overlap


 


Regards


    Brian


 


_______________________________________=
________


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=

 
 

=  <= /font>

--

Bien cordialement, Best regards,

 

Laurent Ciavaglia

Secure Cloud Networking

Bell Labs | Alcatel Lucent

 

phone: +33 160 402 636

email: laurent.ciavaglia@= alcatel-lucent.com

linkedin: laurentciavaglia

address: Route de Villejust | 91620 Nozay | France<= o:p>

--_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FED61Dxmbrcdx14ciscoc_-- From nobody Tue Jun 16 01:20:27 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0521A1AC1 for ; Tue, 16 Jun 2015 01:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUqjNnMHVLsj for ; Tue, 16 Jun 2015 01:20:25 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAB071A1AB2 for ; Tue, 16 Jun 2015 01:20:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1911; q=dns/txt; s=iport; t=1434442825; x=1435652425; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Y0EoyH43vxup9G7z3bOo9l7naThKIv2YVAkNXiE7v2o=; b=RlSXjXxcvFBIcTqfSHQjeyw3cav11foBs3F0/Iak2+xS61/Hq2HRKYj6 HUW9XQzlDMAik+yeO2z7Ye/7jFS/gkhwFrOkaG/J5BAiEuNniqnj/OMi5 u8UhchWm95eX6aQ/ITS5LLoX+sWtDwz6bcnZfJx91C47IOWE1KBYodSyl U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AuBQD8239V/40NJK1bgxCBOb0viEgCgTk7EQEBAQEBAQGBCoQiAQEBAwEnEz8FCwIBCCIUEDIlAgQBDQ2IHwjMOwEBAQEBAQEBAQEBAQEBAQEBAQEBAReLRIRVMQeDF4EWAQSTWwGjUSaDeYI1gQEBAQE X-IronPort-AV: E=Sophos;i="5.13,624,1427760000"; d="scan'208";a="3873025" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-5.cisco.com with ESMTP; 16 Jun 2015 08:20:25 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t5G8KOMD004501 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Jun 2015 08:20:24 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.179]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Tue, 16 Jun 2015 03:20:24 -0500 From: "Michael Behringer (mbehring)" To: "Toerless Eckert (eckert)" , Laurent Ciavaglia Thread-Topic: [Anima] Domains Thread-Index: AQHQpuE76O8jwXjqQEChS4azZXo/Fp2tLVdggADEmwCAABxSAIAAvMBQ Date: Tue, 16 Jun 2015 08:20:23 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FED638@xmb-rcd-x14.cisco.com> References: <557DE4C8.4050507@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FE5DF6@xmb-rcd-x14.cisco.com> <557EDE5C.2070600@alcatel-lucent.com> <20150615155822.GC13907@cisco.com> In-Reply-To: <20150615155822.GC13907@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Anima WG Subject: Re: [Anima] Domains X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jun 2015 08:20:26 -0000 > So maybe more consistently: > Dynamic ASA (AN Node) - can dynamically install ASA > Constrained ASA (AN Node) - Eg: ASA are bundled with underlying OS. > Constrained > should just be a superset and we can de= fine > more sspecific terms, like "No custom A= SA" or the like > Full ANI (AN Node) - Replaces term "Unconstrained AN Node" > -> Unconstrained ANI can still have con= strained ASA. > -> "Unconstrained" seems a bad word cho= ice for ANI > because the implications of the refe= rence model > is that the ANI has a defined functi= onality, > and that means its never "unconstrai= ned", so > an implementation can at best do "fu= ll". This > is IMHO different from ASA, which th= e reference > model does not constrain in what the= y could do. > Constrained ANI (AN Node) - Replaces term "Constrained AN Node" Toerless,=20 I'm with you on the ANI. We have full and constrained, and constrained may = not be able to "host" all ASAs. So far so good.=20 On the ASA, to me "bundled with OS" may be an implementation choice, but no= t the architectural reference. In the reference doc, I prefer we add "de-co= upled from node OS and its ANI" (as suggested by Laurent).=20 I'm not sure it makes sense to talk about "constrained ASAs". A resource ma= y be constrained, a user is not. To me, the ANI is a resource, and an ASA i= s a user of that resource. So maybe we should simply say "a constrained ANI= may not be able to run all ASAs" and leave it there?=20 Michael From nobody Tue Jun 16 01:25:01 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC311A1ADC for ; Tue, 16 Jun 2015 01:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-zAuYCHhQEO for ; Tue, 16 Jun 2015 01:24:59 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BE731A1A75 for ; Tue, 16 Jun 2015 01:24:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BTV31835; Tue, 16 Jun 2015 08:24:57 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 16 Jun 2015 09:24:56 +0100 Received: from NKGEML505-MBX.china.huawei.com ([169.254.1.218]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Tue, 16 Jun 2015 16:22:16 +0800 From: Duzongpeng To: Brian E Carpenter Thread-Topic: [Anima] I-D Action: draft-du-anima-an-intent-00.txt Thread-Index: AQHQp8moI2n5wgbDeECFGLP1EVnwwZ2ud0pA Date: Tue, 16 Jun 2015 08:22:16 +0000 Message-ID: References: <20150612064329.8725.45070.idtracker@ietfa.amsl.com> <557F6AAB.7050203@gmail.com> In-Reply-To: <557F6AAB.7050203@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.160] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Anima WG Subject: Re: [Anima] I-D Action: draft-du-anima-an-intent-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jun 2015 08:25:01 -0000 Hi Brian: Thanks for your valuable suggestions. I agree that JSON is an option. IMO, what we need for intent is a common format, no matter it is XML-based = or JSON-based. XML and JSON are both machine and human readable, and easily processed. Another major concern about autonomic intent is whether we need a common po= licy language here.=20 XML and JSON are good for data exchange, however, it is hard for them to ca= rry some complicated semantics or logic. So, perhaps we need a common policy language to simplify the expression job= s and make intent more flexible to extend. For example, an operator may need to configure the autonomic network as "Ef= ficiency First" at 7:00-23:00, and "Energy-saving First" at 23:00-7:00. These configurations have some conditions and actions, which falls into the= scope of "policy".=20 About the prefix management use case, we may have the policies like if role= A, the prefix length is XXX. Best Regards Zongpeng Du -----Original Message----- From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E Carpenter Sent: Tuesday, June 16, 2015 8:16 AM To: Anima WG Subject: Re: [Anima] I-D Action: draft-du-anima-an-intent-00.txt Hi, Just to see if I am understanding the ideas in this draft, here's a sketch = of how to represent the intent for the draft-jiang-anima-prefix-management = use case in JSON terms. (If we end up with JSON for the signaling protocol, I will argue for JSON f= or intent too.) Obviously this is hand-waving; the main question is whether it can express = the sort of things we might want to support in intent. {"example_intent": [{"intent_type": "IPv6_prefix"}, {"autonomic_domain": "Customer_X_intranet"}, {"version": 73}, {"date": "20150616"}, {"content": [{"max_prefix_length": 60}, {"min_prefix_length": 48}, {"max_prefixes_per_customer": 2}, {"SLA_check_needed": true}, {"enable_log": false}]}]} Regards Brian _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima From nobody Tue Jun 16 01:40:12 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 004641A8886 for ; Tue, 16 Jun 2015 01:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrMskCw_ZTIZ for ; Tue, 16 Jun 2015 01:40:08 -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 1217C1A8874 for ; Tue, 16 Jun 2015 01:40:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11418; q=dns/txt; s=iport; t=1434444008; x=1435653608; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ZRkimgzM62Pv+cXEdTDVlw0z1j6JHOpJWQ8lgtkGJ0E=; b=FENO45vAtQjPcQNBxoXkNqvi05w0FDK7ubBAXxJ6tQK8q5uIkfkSjzV4 gRshG6ICbfljhIoSzh4MgoC1hHY9Lw3ZEQycUSwgSdUNqrYJnDsp3RfSu Tyu8T2mp77jzBGdi1IX5/HxZ+w8Se4rwlxfgu2av/P+G281YYEmkls0xe 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CRBQAN4H9V/5FdJa1bgxBUXwaDGLoXgkYKhXgCHIEePBABAQEBAQEBgQqEIgEBAQQBAQEgEToXBAIBCBEEAQEBAgIGHQMCAgIfBgsUAQgIAgQBEgiIEgMSDbU7kSQNhUIBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGJIYECgk2CCBYiBoJiL4EWBYZ6jGEBhE+FEoMTQYNDgwWIPoM7g1smggscgVJvAYFFgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,625,1427760000"; d="scan'208";a="159722259" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-3.cisco.com with ESMTP; 16 Jun 2015 08:39:26 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t5G8dQQ8011308 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Jun 2015 08:39:26 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.179]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Tue, 16 Jun 2015 03:39:25 -0500 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , Anima WG Thread-Topic: [Anima] Domains Thread-Index: AQHQpuE76O8jwXjqQEChS4azZXo/Fp2tLVdggAEsqQCAAHMe4A== Date: Tue, 16 Jun 2015 08:39:24 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FED6A8@xmb-rcd-x14.cisco.com> References: <557DE4C8.4050507@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FE5DF6@xmb-rcd-x14.cisco.com> <557F35A6.4020700@gmail.com> In-Reply-To: <557F35A6.4020700@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.132] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Domains X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jun 2015 08:40:11 -0000 QnJpYW4sIA0KDQpZZXMsIHRoYXQgbmVlZHMgdG8gYmUgbWFkZSBtb3JlIGNsZWFyLiANCg0KVG8g bWU6IA0KLSBBZG1pbmlzdHJhdGl2ZSBkb21haW46IEFsbCBub2RlcyB1bmRlciBvbmUgYWRtaW5p c3RyYXRpdmUgY29udHJvbCwgZXg6ICJleGFtcGxlLmRvbWFpbi5jb20iLiBTdXJlbHksIHRoYXQg aGFzIGJlZW4gZGVmaW5lZCBiZWZvcmUgc29tZXdoZXJlIGFuZCB3ZSBjYW4gbGV2ZXJhZ2UgdGhh dCBkZWZpbml0aW9uPyBUaGUgQkdQIGF1dG9ub21vdXMgc3lzdGVtIGNvbWVzIHRvIG1pbmQuIFRo YXQgc2hvdWxkIGJlIGVhc3kuIA0KDQpUcnVzdCBpcyBoYXJkZXIsIGluIGZhY3QsICJ0cnVzdCIg aXMgbWF5YmUgdGhlIHdyb25nIHRlcm0uIFRoaXMgaXMgcmVhbGx5IGFsbCBhYm91dCBhdXRoZW50 aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiwgYW5kIG1heWJlIHdlIHNob3VsZCB1c2UgdGhvc2Ug dGVybXMgZm9yIGNsYXJpdHkuIA0KDQpBdXRoZW50aWNhdGlvbjogYW4gQU4gbm9kZSBjYW4gYXV0 aGVudGljYXRlIGFsbCBvdGhlciBub2RlcyB1bmRlciB0aGUgc2FtZSBQS0kgcm9vdC4gVGhhdCBp bmNsdWRlcyBzdWItZG9tYWlucyBmb3IgZXhhbXBsZS4gQnV0LCBpZiBJIGhhdmUgdGhlIHJvb3Qg Q0EgY2VydCBvZiBhbm90aGVyIGRvbWFpbiwgYW5kIGhhdmUgZGVjaWRlZCAocG9saWN5IGRlY2lz aW9uISkgdG8gdHJ1c3QgdGhhdCwgSSBjYW4gYWxzbyBhdXRoZW50aWNhdGUgb3RoZXIgZG9tYWlu cy4gVGhpcyBpcyBhbGwganVzdCBhYm91dCBrbm93aW5nIHdobyBJIHRhbGsgdG8sIG5vdGhpbmcg bW9yZS4gVGhpcyBpcyB0aGUgc2ltcGxlIHBhcnQuIA0KDQpOb3csIG9uY2UgSSBrbm93IHdobyBJ IHRhbGsgdG8sIHRoZXJlIGFyZSBkaWZmZXJlbnQgaW1wbGljYXRpb25zLCBhbmQgdGhvc2Ugd2ls bCBiZSBwYXJ0bHkgcG9saWN5IGRyaXZlbiwgcGFydGx5IGRlZmF1bHRzLiANCg0KS2V5IHF1ZXN0 aW9uIGlzOiBBdXRob3JpemVkIHRvIGRvIHdoYXQ/IEEgbm9kZSBjYW4gYXV0aG9yaXplIGFub3Ro ZXIgbm9kZSB0bzogDQotIGpvaW4gdGhlIEFDUA0KLSBuZWdvdGlhdGUgcGFyYW1ldGVycyBmb3Ig cHJvdG9jb2wgWC4gDQotIHJlY2VpdmUgaW50ZW50IGZyb20uIA0KLSAuLi4gDQoNCldlIG5lZWQg dG8gZGVmaW5lIGEgcmVhc29uYWJsZSBkZWZhdWx0IGF1dGhvcml6YXRpb24gc2NoZW1lLCBhbmQs IGdvaW5nIGJ5IGRpc2N1c3Npb25zIEkndmUgaGFkIHdpdGggb3BlcmF0b3JzIHNvIGZhciwgSSB0 aGluayB3ZSB3aWxsIG5lZWQgdG8gYWxsb3cgZm9yIGN1c3RvbWl6YXRpb24gdmlhIEludGVudC4g DQoNCkV4YW1wbGU6IFRoZXJlIGlzIGV4YW1wbGUuY29tIGFuZCBzdWJkb21haW4uZXhhbXBsZS5j b20uIFNob3VsZCB0aGUgQUNQIGVzdGFibGlzaCBhY3Jvc3MgYm90aD8gSSBoYXZlIGhlYXJkIGJv dGggY3VzdG9tZXIgcmVxdWlyZW1lbnRzOiAxKSBZZXMsIEkgd2FudCBvbmUgYmlnIEFDUCB0byBt YW5hZ2UgZXZlcnl0aGluZyBpbiBhIGZsYXQgbWFuYWdlbWVudCBoaWVyYXJjaHkNCjIpIE5vLCBJ IHdhbnQgdGhlIEFDUCBmb3IgZXhhbXBsZS5jb20gc2VwYXJhdGUgZnJvbSB0aGUgQUNQIGZvciBz dWJkb21haW4uZXhhbXBsZS5jb20uIA0KDQpXb3JrIHRvIGJlIGRvbmUgaGVyZS4uLiBXZSBuZWVk IHRvIGRlZmluZSBhIGdvb2QgZGVmYXVsdCBiZWhhdmlvdXIsIHdpdGggdGhlIGhvcGUgdGhhdCB0 aGVyZSB3aWxsIGJlIG1pbmltYWwgZXhjZXB0aW9ucyByZXF1aXJlZC4uLiANCg0KTWljaGFlbA0K DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJyaWFuIEUgQ2FycGVudGVy IFttYWlsdG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tXQ0KPiBTZW50OiAxNSBKdW5lIDIw MTUgMjI6MjkNCj4gVG86IE1pY2hhZWwgQmVocmluZ2VyIChtYmVocmluZyk7IEFuaW1hIFdHDQo+ IFN1YmplY3Q6IFJlOiBbQW5pbWFdIERvbWFpbnMNCj4gDQo+IE1pY2hhZWwgKGFuZCBJJ3ZlIGFs c28gcmVhZCBMYXVyZW50J3MgYW5kIFRvZXJsZXNzJ3MgbWVzc2FnZXMpLA0KPiANCj4gT24gMTYv MDYvMjAxNSAwMDo1NCwgTWljaGFlbCBCZWhyaW5nZXIgKG1iZWhyaW5nKSB3cm90ZToNCj4gPiBC cmFpbiwNCj4gPg0KPiA+IFllcywgdGhpcyBpcyBhIHJlY3VycmluZyBxdWVzdGlvbiwgYW5kIG5l ZWRzIHRvIGJlIGJldHRlciBleHBsYWluZWQuIFRoZQ0KPiBzYW1lIHF1ZXN0aW9uIGNhbWUgdXAg aW4gSG9tZW5ldCBhIGNvdXBsZSBvZiB5ZWFycyBiYWNrLCBhbmQgdGhpcyBpcyBob3cgSQ0KPiBh bnN3ZXJlZCBpdDogSW4gc2hvcnQsIGV2ZXJ5IGF1dG9ub21pYyBlbnRpdHkgaGFzIEEgU0lOR0xF IG93bmVyLCBhbmQgdGh1cw0KPiBhIHNpbmdsZSBkb21haW4uDQo+IA0KPiBXZSBkbyBuZWVkIHRv IGJlIHN1cmUgZmlyc3Qgd2hhdCBhICJkb21haW4iIGlzLiBBbiBhZG1pbmlzdHJhdGl2ZSBib3Vu ZGFyeQ0KPiBpcyBub3QgbmVjZXNzYXJpbHkgdGhlIHNhbWUgYXMgYSB0cnVzdCBib3VuZGFyeS4g SSBjYW4gd2VsbCBpbWFnaW5lIGFuIGVudGl0eQ0KPiB0aGF0IGlzIGluIGEgZ2l2ZW4gYWRtaW4g ZG9tYWluIGJlaW5nIHRydXN0ZWQgYm90aCBpbiB0aGF0IGRvbWFpbiBhbmQgaW4NCj4gYW5vdGhl ciBkb21haW4uDQo+IEluIHRoYXQgc2Vuc2UsIHRydXN0IGRvbWFpbnMgIG1pZ2h0IG92ZXJsYXAg d2hlbiBhZG1pbiBkb21haW5zIGNhbm5vdA0KPiBvdmVybGFwLg0KPiANCj4gQWxzbyBJJ20gcHJl dHR5IHN1cmUgdGhhdCBkb21haW5zIGNhbiBjb250YWluIGRvbWFpbnMsIGJvdGggaW4gdGhlIGFk bWluDQo+IHZpZXcgYW5kIGluIHRoZSB0cnVzdCB2aWV3LiBCdXQgdGhlIG5lc3RpbmcgbWlnaHQg bm90IGJlIHRoZSBzYW1lLg0KPiANCj4gUGxlYXNlIG5vdGUsIEkgZG9uJ3QgaGF2ZSBhIGZpeGVk IG9waW5pb24gaGVyZSwgSSBqdXN0IHdhbnQgY2xhcml0eSBpbiBvdXINCj4gbW9kZWwgYW5kIHRl cm1pbm9sb2d5Lg0KPiANCj4gICAgICBCcmlhbg0KPiANCj4gPg0KPiA+IExldCdzIGZpcnN0IGRl ZmluZSB3aGF0IHdlJ3JlIHRhbGtpbmcgYWJvdXQ6IEkgc3BlY2lmaWNhbGx5IHN0YXRlICJhdXRv bm9taWMNCj4gZW50aXR5IiBhYm92ZS4gSS5lLiwgc29tZXRoaW5nIHRoYXQgY2FuIG5lZ290aWF0 ZSBvbiBpdHMgb3duLiBUaGF0J3Mgd2hhdA0KPiB3ZSdyZSBjb25jZXJuZWQgd2l0aCBoZXJlLiBT cGVjaWZpY2FsbHksIGEgcXVldWUgaW4gYSByb3V0ZXIgaXMgTk9UIGFuDQo+IGF1dG9ub21pYyBl bnRpdHkuIFRoZXJlZm9yZSwgZXZlbiBpZiBzZXZlcmFsIGRpZmZlcmVudCBkb21haW5zIHVzZSBp dCwgdGhpcw0KPiBoYXMgdG8gYmUgbWFuYWdlZCBieSB0aGUgYXV0b25vbWljIGVudGl0eSAodGhl IHJvdXRlciksIHdoaWNoIG5lZ290aWF0ZXMNCj4gYml0cyBhbmQgcGllY2VzIGZvciBkaWZmZXJl bnQgZG9tYWlucy4gQnV0IHRoZSBuZWdvdGlhdG9yIGlzIHRoZSByb3V0ZXIsIGFuDQo+IGF1dG9u b21pYyBlbnRpdHksIGFuZCB0aGF0IG9uZSBoYXMgb25seSBvbmUgZG9tYWluLg0KPiA+DQo+ID4g MS4gSSBjbGFpbSBmb3IgZXZlcnkgYXV0b25vbWljIGVudGl0eSBvdXQgdGhlcmUsIHRoZXJlIGlz IG9uZSBzaW5nbGUNCj4gYWRtaW5pc3RyYXRpdmUgIm93bmVyIi4gVGhlIG9uZSB3aG8gaGFzIHJv b3QgYWNjZXNzLCBlbmFibGUsIHNob3J0LCB0aGUgZnVsbA0KPiBhZG1pbiByaWdodHMuDQo+ID4N Cj4gPiBFeGFtcGxlOiBUYWtlIHRoZSBob21lbmV0IENQRS4gVGhlcmUgaXMgYSBtYW5hZ2VkIHNl cnZpY2VzIG1vZGVsLA0KPiB3aGVyZSB0aGUgU1AgbWFpbnRhaW5zIHRoZSBDUEUsIHRoZXJlIGlz IHRoZSBjYXNlIHdoZXJlIHRoZSBob21lbmV0DQo+IG93bmVyIGlzIGNvbnRyb2xsaW5nIHRoZSBD UEUuIEluc2lkZSB0aGUgaG9tZSBuZXR3b3JrLCB0aGVyZSBtYXkgYmUgYQ0KPiBkZXZpY2UgdGhh dCBpcyBvd25lZCBieSBhIHV0aWxpdHksIHdoaWNoIG1heWJlIHVzZXMgeW91ciBuZXR3b3JrIHRv DQo+IGNvbW11bmljYXRlIHdpdGggc2Vuc29ycywgb3IgdXNlcyB5b3VyIEludGVybmV0IGNvbm5l Y3Rpb24gdG8gY2FsbCBob21lLg0KPiBZb3UgbWF5IGhhdmUgc29tZSBpbmZsdWVuY2Ugb24gdGhl IGRldmljZSBzZXR0aW5ncywgYnV0IHRoZSB1dGlsaXR5IGlzIHRoZQ0KPiBhZG1pbmlzdHJhdGl2 ZSBvd25lci4NCj4gPg0KPiA+IDIuIFRoZSBvd25lciBvZiB0aGUgYXV0b25vbWljIGVudGl0eSBj YW4gZ3JhbnQgc29tZSByaWdodHMgdG8gb3RoZXINCj4gcGVvcGxlLg0KPiA+DQo+ID4gSW4geW91 ciBiYW5kd2lkdGggYnJva2VyIGV4YW1wbGUsIHRoZXJlIGlzIHN0aWxsIE9ORSBhdXRvbm9taWMg ZW50aXR5DQo+IHdobyBoYXMgZnVsbCBhZG1pbiByaWdodHMgb3ZlciBhIGRldmljZSAod2l0aCBh bGwgaXRzIHF1ZXVlcywgZXRjKS4gVGhpcyBlbnRpdHkNCj4gZ3JhbnRzIHJpZ2h0cyB0byBhbm90 aGVyIGRvbWFpbiB0byB1c2UgYSBjZXJ0YWluIGFtb3VudCBvZiBidWZmZXJpbmcsDQo+IHdoYXRl dmVyLCBvbiB0aGUgZGV2aWNlLiBBIHNwZWNpYWwgY2FzZSBvZiB0aGF0Og0KPiA+DQo+ID4gMy4g QSBkZXZpY2UsIG93bmVkIGJ5IGRvbWFpbiBBLCBjYW4gcnVuIGEgY29udGFpbmVyIC8gVk0gLyBv dGhlcg0KPiB2aXJ0dWFsaXphdGlvbiBjb25jZXB0IHRoYXQgYmVsb25ncyB0byBkb21haW4gQi4N Cj4gPg0KPiA+IFRoZW4geW91IGdldCB0byBhIGNhc2Ugd2hlcmUgdGhlcmUgaXMgdGhlIGJhc2Ug aGFyZHdhcmUgd2hpY2ggaXMgb3duZWQNCj4gYnkgb25lIGRvbWFpbiwgYW5kIHNheSBWTXMgcnVu bmluZyBvbiB0b3AgYmVsb25naW5nIHRvIGFub3RoZXIgZG9tYWluLg0KPiBUaGF0IGlzIHN1cHBv cnRlZCwgYW5kIHdlIHNob3VsZCBoYXZlIGNsZWFyIGJvdW5kYXJpZXMgaW4gdGhpcyBjYXNlLg0K PiA+DQo+ID4gNC4gRG9tYWluIEEgY2FuIGdyYW50IHJpZ2h0cyB0byBmb3IgZXhhbXBsZSBhIFZN IG9mIGRvbWFpbiBCLg0KPiA+DQo+ID4gRXhhbXBsZSwgb24gbXkgaG9tZSBDUEUsIEkgcnVuIGEg Y29udGFpbmVyIHRoYXQgYmVsb25ncyB0byB0aGUgdXRpbGl0eTsgaQ0KPiBnaXZlIHRoYXQgYWNj ZXNzIHRvIG15IEludGVybmV0IGNvbm5lY3Rpb24sIHBvc3NpYmx5IHRvIGEgc3BlY2lmaWMgU1NJ RCwNCj4gd2hhdGV2ZXIuDQo+ID4NCj4gPiBDbGVhbiBzZXBhcmF0aW9uLCBjbGVhbiBhdXRob3Jp emF0aW9uIG9mIHJpZ2h0cy4NCj4gPg0KPiA+IExvb2tpbmcgYXQgeW91ciBwaWN0dXJlcywgSSB0 aGluayBhbGwgdGhyZWUgc2hvdyBhICJyZXNvdXJjZSIgYXMgKm5vdCogYmVpbmcNCj4gYW4gYXV0 b25vbWljIGVudGl0eSwgYnV0IGFzIGEgc3ViLXBhcnQgb2YgYW4gYXV0b25vbWljIGVudGl0eSwg ZXhhbXBsZSB3YXMNCj4gdGhlIGxpbmsgYmV0d2VlbiB0d28gZG9tYWlucy4gVGhpcyBpcyB3aGVy ZSB0aGUgY29uZnVzaW9uIGlzIGNvbWluZyBmcm9tLg0KPiBJZiB3ZSBhZ3JlZSB0aGF0IHdlJ3Jl IHRhbGtpbmcgYWJvdXQgdGhlIGRvbWFpbiBvZiBhbiAqYXV0b25vbWljIGVudGl0eSosDQo+IHRo ZW4gdGhlIHBpY3R1cmUgaXMgZGlmZmVyZW50LCBhbmQgaG9wZWZ1bGx5IGNsZWFyZXIuIFRoZW4g aXQncyB1cCB0byB0aGUNCj4gYXV0b25vbWljIGVudGl0aWVzIChhbmQgcG9zc2libHkgZG9tYWlu cykgdGhhdCBzaGFyZSBhIG5vbi1hdXRvbm9taWMNCj4gZW50aXR5IHRvIG5lZ290aWF0ZSBpdHMg dXNhZ2UuDQo+ID4NCj4gPiBEb2VzIHRoYXQgbWFrZSBzZW5zZT8NCj4gPiBNaWNoYWVsDQo+ID4N Cj4gPg0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IEFu aW1hIFttYWlsdG86YW5pbWEtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJyaWFuIEUN Cj4gPj4gQ2FycGVudGVyDQo+ID4+IFNlbnQ6IDE0IEp1bmUgMjAxNSAyMjozMg0KPiA+PiBUbzog QW5pbWEgV0cNCj4gPj4gU3ViamVjdDogW0FuaW1hXSBEb21haW5zDQo+ID4+DQo+ID4+IEhpLA0K PiA+Pg0KPiA+PiBJIHdhbnQgdG8gcmFpc2UgYSBwb2ludCBhYm91dCB0aGUgcmVmZXJlbmNlIG1v ZGVsIHRoYXQgdGhlIGF1dGhvcnMgb2YNCj4gPj4gZHJhZnQtIGJlaHJpbmdlci1hbmltYS1yZWZl cmVuY2UtbW9kZWwgZGlkbid0IHNldHRsZSBiZWZvcmUgdmVyc2lvbg0KPiA+PiAtMDIgY2FtZSBv dXQgYSBmZXcgZGF5cyBhZ28uIFRoZXJlJ3MgcGxhY2Vob2xkZXIgdGV4dCBpbiB0aGUgZHJhZnQN Cj4gPj4gYWJvdXQgU3ViLURvbWFpbnMgYW5kIENyb3NzLURvbWFpbiBGdW5jdGlvbmFsaXR5LiBJ IHN1Z2dlc3RlZCB0aGF0IHdlDQo+ID4+IHNob3VsZCBhbHNvIGxpc3QgIk92ZXJsYXBwaW5nIERv bWFpbnMiIGFzIGEgdG9waWMuIEluIG90aGVyIHdvcmRzLA0KPiA+PiByZWdpb25zIG9mIGEgbmV0 d29yayBjb3VsZCBiZSBjb25zaWRlcmVkIHRvIGJlIGluIHR3byBkaWZmZXJlbnQNCj4gPj4gZG9t YWlucyBzaW11bHRhbmVvdXNseS4gVGhlIHF1ZXN0aW9uIGlzIHdoZXRoZXIgd2Ugd2FudCBvdXIg bW9kZWwgdG8NCj4gPj4gaW5jbHVkZSB0aGF0IHBvc3NpYmlsaXR5PyBJdCBjZXJ0YWlubHkgaGFz IGltcGxpY2F0aW9ucyBmb3Igc2VjdXJpdHkuDQo+ID4+DQo+ID4+IEFuIGV4YW1wbGUgd291bGQg YmUgc29tZSBzb3J0IG9mIHJlc291cmNlIHRoYXQgbmVlZGVkIHRvIGJlIHNoYXJlZA0KPiA+PiBi ZXR3ZWVuIHR3byBvdGhlcndpc2Ugc2VwYXJhdGUgZG9tYWluczsgdGhhdCByZXNvdXJjZSBjb3Vs ZCBiZQ0KPiA+PiBjb25zaWRlcmVkIHRvIGJlIGluIGJvdGggZG9tYWlucy4NCj4gPj4NCj4gPj4g U28gSSBjYW4gc2VlIHRocmVlIHBvc3NpYmxlIG1vZGVscywgc2hvd24gaW4gdGhlIGZvbG93aW5n IEFTQ0lJIGFydDoNCj4gPj4NCj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiA+PiB8ICAgICAgICAgICBTaGFyZWQgUmVzb3VyY2UgICAgICAgICAgICAg ICB8DQo+ID4+IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4g Pj4gfCAtLS0tLS0tLS0tLS0tLS0tLS0gICAtLS0tLS0tLS0tLS0tLS0tLS0gfA0KPiA+PiB8IHwg U3ViZGRvbWFpbjEgICAgfCAgIHwgU3ViZGRvbWFpbjIgICAgfCB8DQo+ID4+IHwgfCAgICAgICAg ICAgICAgICB8ICAgfCAgICAgICAgICAgICAgICB8IHwNCj4gPj4gfCB8ICAgICAgICAgICAgICAg IHwgICB8ICAgICAgICAgICAgICAgIHwgfA0KPiA+PiB8IC0tLS0tLS0tLS0tLS0tLS0tLSAgIC0t LS0tLS0tLS0tLS0tLS0tLSB8DQo+ID4+IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwNCj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPiA+Pg0KPiA+PiAxLiBTaGFyZWQgcmVzb3VyY2UgaW4gb3V0ZXIgZG9tYWluDQo+ID4+ DQo+ID4+ICAtLS0tLS0tLS0tLS0tLS0tLS0gICAtLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4gIHwg ICBEb21haW4xICAgICAgfCAgIHwgICBEb21haW4yICAgICAgfA0KPiA+PiAgfCAgICAgICAgICAg ICAgICB8ICAgfCAgICAgICAgICAgICAgICB8DQo+ID4+ICB8ICAgICAgICAgU2hhcmVkIHwgICB8 ICAgICAgICAgICAgICAgIHwNCj4gPj4gIHwgICAgICAgUmVzb3VyY2U8fHh4eHw+ICAgICAgICAg ICAgICAgfA0KPiA+PiAgLS0tLS0tLS0tLS0tLS0tLS0tICAgLS0tLS0tLS0tLS0tLS0tLS0tDQo+ ID4+DQo+ID4+IDIuIFNoYXJlZCByZXNvdXJjZSBpbiBvbmUgZG9tYWluLCB3aXRoIGNyb3NzLWRv bWFpbiBhY2Nlc3MNCj4gPj4NCj4gPj4gIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4gIHwg ICBEb21haW4xICAgIC0tLS0tLXwtLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4gIHwgICAgICAgICAg ICAgIHwgU2hhcmVkICAgIERvbWFpbjIgICAgIHwNCj4gPj4gIHwgICAgICAgICAgICAgIHxSZXNv dXJjZSAgICAgICAgICAgICAgIHwNCj4gPj4gIHwgICAgICAgICAgICAgIHwgICAgIHwgICAgICAg ICAgICAgICAgIHwNCj4gPj4gIC0tLS0tLS0tLS0tLS0tLXwtLS0tLS0gICAgICAgICAgICAgICAg IHwNCj4gPj4gICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4N Cj4gPj4gMy4gU2hhcmVkIHJlc291cmNlIGluIGRvbWFpbiBvdmVybGFwDQo+ID4+DQo+ID4+IFJl Z2FyZHMNCj4gPj4gICAgIEJyaWFuDQo+ID4+DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IEFuaW1hIG1haWxpbmcgbGlzdA0KPiA+PiBB bmltYUBpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2FuaW1hDQo+ID4gLg0KPiA+DQo= From nobody Tue Jun 16 19:27:47 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 617E41B3782 for ; Tue, 16 Jun 2015 19:27:46 -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 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 CM6tBoyuSN9q for ; Tue, 16 Jun 2015 19:27:43 -0700 (PDT) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::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 77BEF1B3786 for ; Tue, 16 Jun 2015 19:27:42 -0700 (PDT) Received: by pdjm12 with SMTP id m12so27139024pdj.3 for ; Tue, 16 Jun 2015 19:27:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=LpyrdyvVZHQ++gc4hweMtkCaqjKLW01XHVIEVSsk+b0=; b=PB41xLBQ4zZCBLY8g2aQV4ZtO0uaId/Ks3upTGdy52i41Dr6Bjg7GY56USUnkOHfbp J3lojW2WKn+sF0PTzKaa7i3KQ5t5cVylG0Q4eb8pC1yvE/SZ3rfDRIHA4XsEf2qyytKS CxzMUJl5BjHBl92ehNQx+wPIwBGNrUE9HNka1Fm9zABQyEIYqPMKm7tY9d73WvpG5IsT qugEo0fg52COVXgfD+3v4OGRkqVezi9rf104WRYaRvdYJDUC5LbbdKoO3LE7ZoBcHlpB KdIfXaPUqHE/EEz6oPOA79HhJl4GcJRRbRlSbpPcRn0w6AjC1pZlW8uRRu+yugbUHPvo oojQ== X-Received: by 10.66.249.68 with SMTP id ys4mr6140463pac.103.1434508062057; Tue, 16 Jun 2015 19:27:42 -0700 (PDT) Received: from ?IPv6:2406:e007:516f:1:28cc:dc4c:9703:6781? ([2406:e007:516f:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id gs7sm2761703pbc.6.2015.06.16.19.27.37 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Jun 2015 19:27:40 -0700 (PDT) Message-ID: <5580DB1D.9010009@gmail.com> Date: Wed, 17 Jun 2015 14:27:41 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , Anima WG References: <557DE4C8.4050507@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FE5DF6@xmb-rcd-x14.cisco.com> <557F35A6.4020700@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FED6A8@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FED6A8@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Domains X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 17 Jun 2015 02:27:46 -0000 On 16/06/2015 20:39, Michael Behringer (mbehring) wrote: > Brian, > > Yes, that needs to be made more clear. > > To me: > - Administrative domain: All nodes under one administrative control, ex: "example.domain.com". Surely, that has been defined before somewhere and we can leverage that definition? The BGP autonomous system comes to mind. That should be easy. When is anything ever easy?... In fact the definition in RFC 1136 is amazingly good still: Administrative Domain (AD) "A collection of End Systems, Intermediate Systems, and subnetworks operated by a single organization or administrative authority. The components which make up the domain are assumed to interoperate with a significant degree of mutual trust among themselves, but interoperate with other Administrative Domains in a mutually suspicious manner" [1]. and it's actually a quotation from ISO/TR 9575, 1989 :-). > Trust is harder, in fact, "trust" is maybe the wrong term. This is really all about authentication and authorization, and maybe we should use those terms for clarity. Well, there's a sequence: I claim an identity, you authenticate that identity, then you check the authorized capabilities for that identity, and then you trust me (but only for those specific capabilities). At an abstract level this is all old news, I guess. It just gets complicated when authorization and capabilities cross domain boundaries. (I actually worked on that a bit for grid computing a decade ago; I don't really think it's relevant but we did publish something, which IBM has charmingly stuck behind a paywall: http://dx.doi.org/10.1147/sj.434.0689 .) Brian > Authentication: an AN node can authenticate all other nodes under the same PKI root. That includes sub-domains for example. But, if I have the root CA cert of another domain, and have decided (policy decision!) to trust that, I can also authenticate other domains. This is all just about knowing who I talk to, nothing more. This is the simple part. > > Now, once I know who I talk to, there are different implications, and those will be partly policy driven, partly defaults. > > Key question is: Authorized to do what? A node can authorize another node to: > - join the ACP > - negotiate parameters for protocol X. > - receive intent from. > - ... > > We need to define a reasonable default authorization scheme, and, going by discussions I've had with operators so far, I think we will need to allow for customization via Intent. > > Example: There is example.com and subdomain.example.com. Should the ACP establish across both? I have heard both customer requirements: 1) Yes, I want one big ACP to manage everything in a flat management hierarchy > 2) No, I want the ACP for example.com separate from the ACP for subdomain.example.com. > > Work to be done here... We need to define a good default behaviour, with the hope that there will be minimal exceptions required... > > Michael > >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: 15 June 2015 22:29 >> To: Michael Behringer (mbehring); Anima WG >> Subject: Re: [Anima] Domains >> >> Michael (and I've also read Laurent's and Toerless's messages), >> >> On 16/06/2015 00:54, Michael Behringer (mbehring) wrote: >>> Brain, >>> >>> Yes, this is a recurring question, and needs to be better explained. The >> same question came up in Homenet a couple of years back, and this is how I >> answered it: In short, every autonomic entity has A SINGLE owner, and thus >> a single domain. >> >> We do need to be sure first what a "domain" is. An administrative boundary >> is not necessarily the same as a trust boundary. I can well imagine an entity >> that is in a given admin domain being trusted both in that domain and in >> another domain. >> In that sense, trust domains might overlap when admin domains cannot >> overlap. >> >> Also I'm pretty sure that domains can contain domains, both in the admin >> view and in the trust view. But the nesting might not be the same. >> >> Please note, I don't have a fixed opinion here, I just want clarity in our >> model and terminology. >> >> Brian >> >>> >>> Let's first define what we're talking about: I specifically state "autonomic >> entity" above. I.e., something that can negotiate on its own. That's what >> we're concerned with here. Specifically, a queue in a router is NOT an >> autonomic entity. Therefore, even if several different domains use it, this >> has to be managed by the autonomic entity (the router), which negotiates >> bits and pieces for different domains. But the negotiator is the router, an >> autonomic entity, and that one has only one domain. >>> >>> 1. I claim for every autonomic entity out there, there is one single >> administrative "owner". The one who has root access, enable, short, the full >> admin rights. >>> >>> Example: Take the homenet CPE. There is a managed services model, >> where the SP maintains the CPE, there is the case where the homenet >> owner is controlling the CPE. Inside the home network, there may be a >> device that is owned by a utility, which maybe uses your network to >> communicate with sensors, or uses your Internet connection to call home. >> You may have some influence on the device settings, but the utility is the >> administrative owner. >>> >>> 2. The owner of the autonomic entity can grant some rights to other >> people. >>> >>> In your bandwidth broker example, there is still ONE autonomic entity >> who has full admin rights over a device (with all its queues, etc). This entity >> grants rights to another domain to use a certain amount of buffering, >> whatever, on the device. A special case of that: >>> >>> 3. A device, owned by domain A, can run a container / VM / other >> virtualization concept that belongs to domain B. >>> >>> Then you get to a case where there is the base hardware which is owned >> by one domain, and say VMs running on top belonging to another domain. >> That is supported, and we should have clear boundaries in this case. >>> >>> 4. Domain A can grant rights to for example a VM of domain B. >>> >>> Example, on my home CPE, I run a container that belongs to the utility; i >> give that access to my Internet connection, possibly to a specific SSID, >> whatever. >>> >>> Clean separation, clean authorization of rights. >>> >>> Looking at your pictures, I think all three show a "resource" as *not* being >> an autonomic entity, but as a sub-part of an autonomic entity, example was >> the link between two domains. This is where the confusion is coming from. >> If we agree that we're talking about the domain of an *autonomic entity*, >> then the picture is different, and hopefully clearer. Then it's up to the >> autonomic entities (and possibly domains) that share a non-autonomic >> entity to negotiate its usage. >>> >>> Does that make sense? >>> Michael >>> >>> >>> >>>> -----Original Message----- >>>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E >>>> Carpenter >>>> Sent: 14 June 2015 22:32 >>>> To: Anima WG >>>> Subject: [Anima] Domains >>>> >>>> Hi, >>>> >>>> I want to raise a point about the reference model that the authors of >>>> draft- behringer-anima-reference-model didn't settle before version >>>> -02 came out a few days ago. There's placeholder text in the draft >>>> about Sub-Domains and Cross-Domain Functionality. I suggested that we >>>> should also list "Overlapping Domains" as a topic. In other words, >>>> regions of a network could be considered to be in two different >>>> domains simultaneously. The question is whether we want our model to >>>> include that possibility? It certainly has implications for security. >>>> >>>> An example would be some sort of resource that needed to be shared >>>> between two otherwise separate domains; that resource could be >>>> considered to be in both domains. >>>> >>>> So I can see three possible models, shown in the folowing ASCII art: >>>> >>>> ------------------------------------------- >>>> | Shared Resource | >>>> | | >>>> | ------------------ ------------------ | >>>> | | Subddomain1 | | Subddomain2 | | >>>> | | | | | | >>>> | | | | | | >>>> | ------------------ ------------------ | >>>> | | >>>> ------------------------------------------- >>>> >>>> 1. Shared resource in outer domain >>>> >>>> ------------------ ------------------ >>>> | Domain1 | | Domain2 | >>>> | | | | >>>> | Shared | | | >>>> | Resource<|xxx|> | >>>> ------------------ ------------------ >>>> >>>> 2. Shared resource in one domain, with cross-domain access >>>> >>>> ---------------------- >>>> | Domain1 ------|------------------ >>>> | | Shared Domain2 | >>>> | |Resource | >>>> | | | | >>>> ---------------|------ | >>>> ------------------------- >>>> >>>> 3. Shared resource in domain overlap >>>> >>>> Regards >>>> Brian >>>> >>>> _______________________________________________ >>>> Anima mailing list >>>> Anima@ietf.org >>>> https://www.ietf.org/mailman/listinfo/anima >>> . >>> From nobody Tue Jun 16 21:09:59 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1A81B3B8E for ; Tue, 16 Jun 2015 21:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyn3dh9Rt3_h for ; Tue, 16 Jun 2015 21:09:50 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 643891B3B89 for ; Tue, 16 Jun 2015 21:09:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=231; q=dns/txt; s=iport; t=1434514190; x=1435723790; h=date:from:to:subject:message-id:reply-to:mime-version; bh=X2E3tFXQ+WFq739+Tu3Qe1YMmWkIJH8rq74xQY+xy2A=; b=PgjfWxFHJ4lxp4YX8PBgr79etOJEpDAc784XPDB95Lu/ECVb3/vlD/eK kMQHt6c7ib1cDNBf08kITy8YD77rt9oo3lHq0wkxps4hUGxrrv2ZAmbtI sIbY1GjZPW74b+oi3teikEaGFFlwO7YrjEzEArZpzS6wDhK97U4n1kEL8 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CEBQAG8oBV/4sNJK1bgxC/YodUAYFYOhIBAQEBAQEBgQqEY3s0BYkLp0CHU45gj3MBAQEHAQEBAQEdj2cRAW6DAYEWBYxqhnWLRAGBM4QJklwmhBkegT2BOwEBAQ X-IronPort-AV: E=Sophos;i="5.13,630,1427760000"; d="scan'208";a="7895146" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-3.cisco.com with ESMTP; 17 Jun 2015 04:09:49 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t5H49mMo024880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 17 Jun 2015 04:09: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 t5H49k5u015316 for ; Tue, 16 Jun 2015 21:09:47 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t5H49kWg015312 for anima@ietf.org; Tue, 16 Jun 2015 21:09:46 -0700 Date: Tue, 16 Jun 2015 21:09:46 -0700 From: Toerless Eckert To: anima@ietf.org Message-ID: <20150617040946.GA27147@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] anima-bootstrap: check X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: anima-chairs@tools.ietf.org List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2015 04:09:51 -0000 Hi folks, If you had responded to our poll for the anima bootstrap team, you should have gotten an invite email now. If not, then please send us an email because i must have overlooked an email Thanks! Sheng & Toerless From nobody Wed Jun 17 05:41:40 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5A61A9060 for ; Wed, 17 Jun 2015 05:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OItiCvRSmkht for ; Wed, 17 Jun 2015 05:41:37 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77AB31A9055 for ; Wed, 17 Jun 2015 05:41:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1606; q=dns/txt; s=iport; t=1434544897; x=1435754497; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=0rJYVV3YQ0sfttst06kX2J3jn9i6cuguLP5jFtzuYkU=; b=Rt9nAlbTeSWxLNYRSf0Xs7jmC807Y5UkB2trzkLp5TH7NQXF2kfH6iJv hcHStJqL1z+of3GqEUgFDKPqYKTswifJ5d2vEqfm0qg1fYOQRmTZakziH IqnDnXPa0BJAOSaHBhIjZVbraUSHqNmo8zoCagr+DwNDoFe7a9bY8stHx M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AiBQDEaYFV/4wNJK1cgxBUZYMYug1mCYFnhXgCHIEeOBQBAQEBAQEBgQqEJAEEIxFFEgEiAgYgAgQwFREBBA4NiCcNs0CWSQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSGKI4Q0AQEfMYJvL4EUBZNoAYRSiCiECopkhCODWyaDeYFyBwIXI4ECAQEB X-IronPort-AV: E=Sophos;i="5.13,632,1427760000"; d="scan'208";a="160279857" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-5.cisco.com with ESMTP; 17 Jun 2015 12:41:36 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t5HCfa6c000325 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jun 2015 12:41:36 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.179]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Wed, 17 Jun 2015 07:41:36 -0500 From: "Michael Behringer (mbehring)" To: Anima WG Thread-Topic: Reference doc on github Thread-Index: AdCo+dAvfC4NDb/zTJOIdvnhU/aAQg== Date: Wed, 17 Jun 2015 12:41:35 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FEE3B8@xmb-rcd-x14.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.132] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-behringer-anima-reference-model@tools.ietf.org" Subject: [Anima] Reference doc on github X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 17 Jun 2015 12:41:39 -0000 SSBoYXZlIG5vdyBhbHNvIGNyZWF0ZWQgYSByZXBvc2l0b3J5IGluIGdpdGh1YjogaHR0cHM6Ly9n aXRodWIuY29tL21iZWhyaW5nL0FOSU1BLVJlZmVyZW5jZS1Nb2RlbA0KDQpJIHN1Z2dlc3RlZCBp bml0aWFsIGNvbnRyaWJ1dGlvbnMsIGFzIHBlciBiZWxvdyBsaXN0IChvcGVuIHRvIG1vcmUgc3Vn Z2VzdGlvbnMgOy0pIA0KDQotIE1pY2hhZWwgUmljaGFyZHNvbjogc2VjdGlvbiAzLjMgKGNvbnN0 cmFpbmVkIG5vZGVzKQ0KLSBMaXViaW5nOiA0LjEgYW5kIDQuMiAoTmFtaW5nLCBhZGRyZXNzaW5n KQ0KLSBCcmlhbiBDYXJwZW50ZXI6IDQuNCAoc2lnbmFsaW5nKS4gQ291bGQgeW91IGFsc28gY292 ZXIgNC41IChpbnRlbnQgZGlzdHJpYnV0aW9uKSBhbmQgNC4zIChkaXNjb3ZlcnkpPyAtIHZlcnkg cmVsYXRlZCEhDQotIEphc29uIENvbGVtYW46IFNlY3Rpb24gNS4xLCA1LjIsIDUuNCwgNS41IChQ S0ksIGNlcnQsIHN1YiBhbmQgY3Jvc3MtZG9tYWluKQ0KLSBKZWZlcnNvbiBOb2JyZTogNy4xLCA3 LjIsIDcuMyAoTWFuYWdlbWVudCwgaW50ZW50LCBhZ2dyZWdhdGVkIHJlcG9ydGluZykNCi0gSm9o biBTdHJhc3NuZXI6IDcuNCwgNy41LCA3LjYgKGZlZWRiYWNrIGxvb3BzLCBBUElTIGFuZCBtb2Rl bHMuKQ0KLSBMYXVyZW50IENpYXZhZ2xpYTogU2VjdGlvbnMgOCBhbmQgOSAoZG8gdGhleSBuZWVk IGFuIHVwZGF0ZT8pDQotIFRvZXJsZXNzIGFuZCBJIHdpbGwgc2hhcmUgdGhlIHJlbWFpbmluZyBz ZWN0aW9ucyBmb3Igbm93Lg0KDQpDYW4gdGhlIHZvbHVudGVlcnMgcGxlYXNlIGxldCBtZSBrbm93 IGJ5IHdoZW4gdGhleSBjYW4gY29udHJpYnV0ZSB0aGVpciB0ZXh0PyAgRWl0aGVyIGluIGdpdGh1 YiAobGV0IG1lIGtub3cgeW91ciBJRCBpZiB5b3Ugd2FudCB0byBjb250cmlidXRlIHRoZXJlKSAN Cg0KR2l0aHViIGlzIG5vdCBtYW5kYXRvcnkgLSBJZiB5b3Ugd2FudCB0byBzZW5kIG1lIHlvdXIg dGV4dCB2aWEgbWFpbCwgdGhhdCdzIG9rLiBJJ2Qgc3Ryb25nbHkgcHJlZmVyIFhNTCBmb3JtYXR0 ZWQgc2VjdGlvbnMgaWYgcG9zc2libGUgOy0pIA0KDQpDYW4gd2UgaGF2ZSBhbGwgdGV4dCBpbiBi eSBXZWQgbmV4dCB3ZWVrPyANCg0KSSBwbGFuIHRvIGNvbnNvbGlkYXRlIGFuZCBwdXNoIC0wMyBi eSBlbmQgb2YgbmV4dCB3ZWVrLiANCg0KTWljaGFlbA0K From nobody Wed Jun 17 08:06:55 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05CF01ACED2 for ; Wed, 17 Jun 2015 08:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glZp0_NhvJ-i for ; Wed, 17 Jun 2015 08:06:52 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7703C1ACE94 for ; Wed, 17 Jun 2015 08:06:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2714; q=dns/txt; s=iport; t=1434553613; x=1435763213; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xeO6Ks7m+nNTJJ2gweRg17OulhcBigksYi0yn7lgIwc=; b=hwmOhiMhaeU2Fk3m8+3vcqieu3AMu4E4TImUR+PvbrXRGsn+Pts/T+jX dyOJv0ArLKCORFZv7x6k4BoYn95nmhkdlXNdBgNcT//GhvuNhgmS6+l15 Rj4o2d22Cu9yqxypBIGH/XLys7Epmacw2l2kE+tUWGewHvh0VlPpVWqIo 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CFBQAIjIFV/5RdJa1cgxBUXwa8b2YJgV0KhXgCgTY4FAEBAQEBAQF/C4QiAQEBBAEBARodNAsMBAIBCBEEAQELFAkHJwsUCQgBAQQOBQgBiCYNyjABAQEBAQEBAQEBAQEBAQEBAQEBAQEXi0SELQcBAR8xAgUGgxGBFAWMAIdoAYx6hAqKZId+JmODFm8BgQIJFyOBAgEBAQ X-IronPort-AV: E=Sophos;i="5.13,633,1427760000"; d="scan'208";a="160328976" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-6.cisco.com with ESMTP; 17 Jun 2015 15:06:52 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t5HF6pMI022294 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jun 2015 15:06:51 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.179]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Wed, 17 Jun 2015 10:06:51 -0500 From: "Michael Behringer (mbehring)" To: "anima-chairs@tools.ietf.org" Thread-Topic: Call for Agenda ANIMA @ IETF93 Thread-Index: AdCjYLWNFwnod5ilQb6HZ9KChOr3NwFp9zGw Date: Wed, 17 Jun 2015 15:06:50 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FEE62E@xmb-rcd-x14.cisco.com> References: <5D36713D8A4E7348A7E10DF7437A4B925F54F700@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B925F54F700@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Anima WG Subject: Re: [Anima] Call for Agenda ANIMA @ IETF93 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 17 Jun 2015 15:06:54 -0000 Sheng,=20 Here my proposals:=20 Name of time slot: ANIMA Reference Model Name of draft(s): draft-behringer-anima-reference-model Time requested: 30 Presenter name(s): Michael Behringer Brief description: Describe current status and open issues. Goal: Consensus= on next steps; Accept as WG item Name of time slot: Autonomic Addressing Name of draft(s): draft-behringer-anima-autonomic-addressing Time requested: 15 Presenter name(s): Michael Behringer Brief description: Goal: Get consensus on the approach or understand issues= ; Accept as WG item New version to be posted tomorrow. Name of time slot: Autonomic Control Plane Name of draft(s): draft-behringer-anima-autonomic-control-plane Time requested: 15=20 Presenter name(s): Michael Behringer Brief description: Clarify open questions and issues. Goal: Accept as WG it= em Michael > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Sheng Jiang > Sent: 10 June 2015 11:35 > To: Anima WG > Cc: anima-chairs@tools.ietf.org > Subject: [Anima] Call for Agenda ANIMA @ IETF93 >=20 > Hi, all, >=20 > We have requested two sessions of 2 hour + 1.5 hour for the ANIMA WG > meeting for IETF-93 (Prague) and are starting to collect agenda items for= this > session. Different from IETF92, following the feedback from our responsib= le > ADs, 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 until we finish charter work items. Another differenti= a is > the non-charter work items must have at least submitted drafts to be > included in the agenda. This threshold may even raise in the future IETF > meetings, such as active discussion in mail list. >=20 > Please send us (anima-chairs@tools.ietf.org) requests for sessions and > include: >=20 > 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 stat= us > update): >=20 > More details about the Prague IETF can be found at > http://www.ietf.org/meeting/93/index.html. >=20 > Again, presenters and draft authors please invoke active discussions in t= he > 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. >=20 > Best regards, >=20 > Toerless & Sheng > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Wed Jun 17 08:51:06 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75D9D1AD2C4 for ; Wed, 17 Jun 2015 08:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZsROBam4C5P for ; Wed, 17 Jun 2015 08:51:02 -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 1D6531AD272 for ; Wed, 17 Jun 2015 08:51:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18586; q=dns/txt; s=iport; t=1434556262; x=1435765862; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/13mYlTFRy9XWqRm50loWdYuGSLXDhcWTaOIZCtfdtY=; b=iXgfO3FzRtLmCntoEOeE2sBTAjQDFsQIQ56sOUEJiY/dQx5FQXusG/uq fJpqiSy1iWnbI562bJgdje6Rq5IPcsOxdWmMUHQdVxZUtqcNTbB0n2W4Y PdX/CbtW8kP2DwcmvtGyp443oLmWBbqlx5RjCVtc44kc1iN73/j6Z1yy4 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AoBQALl4FV/4cNJK1cgkVLVF8Ggxi5WGYJgV0BCYV4AhyBGjgUAQEBAQEBAYEKhCIBAQEEAQEBIApBCxACAQgOAwQBAQsdAwICAh8GCxQJCAEBBA4FCIgSAxINs3WRAQ2FRQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi0SCTYFnAQEfLQQGAYJoL4EUBYUajk4BiSg9gxWHE4dbaIM7g1smggscgVJvgQw6gQIBAQE X-IronPort-AV: E=Sophos;i="5.13,633,1427760000"; d="scan'208,217";a="160208353" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-3.cisco.com with ESMTP; 17 Jun 2015 15:51:01 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t5HFp1T6028070 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jun 2015 15:51:01 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.179]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Wed, 17 Jun 2015 10:51:01 -0500 From: "Michael Behringer (mbehring)" To: John Strassner Thread-Topic: [Anima] Reference doc - who helps where Thread-Index: AdCkPpvDq/REH/c/QD6jsqABU9g+LABRQYuAAORfLWA= Date: Wed, 17 Jun 2015 15:51:00 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FEE6D6@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FCC640@xmb-rcd-x14.cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.132] Content-Type: multipart/alternative; boundary="_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FEE6D6xmbrcdx14ciscoc_" MIME-Version: 1.0 Archived-At: Cc: Anima WG Subject: Re: [Anima] Reference doc - who helps where X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 17 Jun 2015 15:51:04 -0000 --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FEE6D6xmbrcdx14ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogSm9obiBTdHJhc3NuZXIgW21haWx0bzpzdHJhenBkakBnbWFpbC5jb21dDQpTZW50OiAx MiBKdW5lIDIwMTUgMjM6NTANClRvOiBNaWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpDQpDYzog QW5pbWEgV0cNClN1YmplY3Q6IFJlOiBbQW5pbWFdIFJlZmVyZW5jZSBkb2MgLSB3aG8gaGVscHMg d2hlcmUNCg0KSGkgTWljaGFlbCwNCg0KdGhhbmtzIGZvciBvcmdhbml6aW5nIHRoaXMuIEknbSBj b25maXJtaW5nIGJvdGggbXkgYXNzaWduZWQgc2VjdGlvbnMgYXMgd2VsbCBhcyByZWFkaW5nIGFu ZCBjb21tZW50aW5nIG9uIHRoZSBlbnRpcmUgZHJhZnQuDQoNClJlZ2FyZGluZyA3LjIgKGludGVu dCksIHdlIHNob3VsZCBiZSBjYXJlZnVsIHRvIHN5bmMgKG9yIGV4cGxhaW4gd2h5IHdlIGRpc2Fn cmVlKSB3aXRoIGludGVudCBhcyBiZWluZyBkZWZpbmVkIGluIHRoZSAxMDAgb3Igc28gb3RoZXIg cGxhY2VzIHRoYXQgcGVvcGxlIGFyZSB3b3JraW5nIG9uIGl0LiBXZSBkb24ndCBuZWVkIHRvIHN5 bmMgaW4gdGhpcyBkb2N1bWVudCBvZiBjb3Vyc2UgLSBidXQgd2Ugc2hvdWxkIGJlIHByZXBhcmVk IHRvIGRlYWwgd2l0aCB0aGlzIChpbWhvIGluZXZpdGFibGUpIHF1ZXN0aW9uIHdoZW4gaXQgY29t ZXMgdXAuIEknbSBoYXBweSB0byBoZWxwIEplZmZlcnNvbiBoZXJlIChJJ20gYWN0aXZlIGluIE9O RiwgT05PUywgQ29uZ3Jlc3MsIFRNRiwgYW5kIHJlbWVtYmVyIC0gU1VQQSBoYXMgYWxzbyBkZWZp bmVkIGludGVudCkuDQoNCk1COiBJbmRlZWQuIFdl4oCZbGwgaGF2ZSBpbnRlcmVzdGluZyBkaXNj dXNzaW9ucyBvbiB0aGF0LiBBIGxvdCBkZXBlbmRzIG9uIHRoZSB3YXkgSW50ZW50IGlzIGRlZmlu ZWQsIElNTy4gSWYgd2UgaGF2ZSBhIGNsZWFyIGRlZmluaXRpb24gd2XigJlyZSBhIHN0ZXAgZnVy dGhlci4NCg0KSG93IHdvdWxkIHlvdSBsaWtlIHRvIHByb2NlZWQgb24gdXBkYXRlcz8gRm9yIGV4 YW1wbGUsIGlmIEkgdXBkYXRlIDcuMywgc2hvdWxkIEkgc2VuZCBhIGRyYWZ0LWJlaHJpbmdlci1h bmltYS1yZWZlcmVuY2UtbW9kZWwtMDItNy4zLWZyb20tamNzLnR4dCB0byB0aGUgYXV0aG9yIGxp c3QsIEFOSU1BLCBvciBhIHRvLWJlLWRlZmluZWQgR2l0SHViIHNpdGU/DQoNCk1COiBZb3Ugd2ls bCBoYXZlIHNlZW4gbXkgZ2l0aHViIG1haWwgdG9kYXkuIFdoaWNoZXZlciB3YXkgeW91IHByZWZl ciwgcmVhbGx5LiBJIHN1Z2dlc3QgdG8gY29weSB0aGUgYW5pbWEgbGlzdCBvbiB0aGUgdGV4dHMs IHNvIHRoYXQgcGVvcGxlIGNhbiByZWFkL2NvbW1lbnQgcmlnaHQgYXdheS4NCg0KTWljaGFlbA0K DQoNCmJlc3QgcmVnYXJkcywNCkpvaG4NCg0KT24gVGh1LCBKdW4gMTEsIDIwMTUgYXQgNzoyNCBB TSwgTWljaGFlbCBCZWhyaW5nZXIgKG1iZWhyaW5nKSA8bWJlaHJpbmdAY2lzY28uY29tPG1haWx0 bzptYmVocmluZ0BjaXNjby5jb20+PiB3cm90ZToNCldpdGggdGhlIG5ldyBvdXRsaW5lIGluIHBs YWNlIChzZWUgZHJhZnQtYmVocmluZ2VyLWFuaW1hLXJlZmVyZW5jZS1tb2RlbC0wMiwganVzdCBw b3N0ZWQpLCB3ZSBjYW4gbm93IGxvb2sgd2hvIG93bnMgd2hpY2ggc2VjdGlvbi4NCg0KTm93IEkg dHJ5IHRvIGJlc3QgbWFwIHRoZSB2b2x1bnRlZXJzIEkndmUgc2VlbiB0byB0aGUgc2VjdGlvbnMs IGFjY29yZGluZyB0byB0aGVpciBzdWdnZXN0aW9uczoNCi0gTWljaGFlbCBSaWNoYXJkc29uOiBz ZWN0aW9uIDMuMyAoY29uc3RyYWluZWQgbm9kZXMpDQotIExpdWJpbmc6IDQuMSBhbmQgNC4yIChO YW1pbmcsIGFkZHJlc3NpbmcpDQotIEJyaWFuIENhcnBlbnRlcjogNC40IChzaWduYWxpbmcpLiBD b3VsZCB5b3UgYWxzbyBjb3ZlciA0LjUgKGludGVudCBkaXN0cmlidXRpb24pIGFuZCA0LjMgKGRp c2NvdmVyeSk/IC0gdmVyeSByZWxhdGVkISENCi0gSmFzb24gQ29sZW1hbjogU2VjdGlvbiA1LjEs IDUuMiwgNS40LCA1LjUgKFBLSSwgY2VydCwgc3ViIGFuZCBjcm9zcy1kb21haW4pDQotIEplZmVy c29uIE5vYnJlOiA3LjEsIDcuMiwgNy4zIChNYW5hZ2VtZW50LCBpbnRlbnQsIGFnZ3JlZ2F0ZWQg cmVwb3J0aW5nKQ0KLSBKb2huIFN0cmFzc25lcjogNy40LCA3LjUsIDcuNiAoZmVlZGJhY2sgbG9v cHMsIEFQSVMgYW5kIG1vZGVscy4pDQotIExhdXJlbnQgQ2lhdmFnbGlhOiBTZWN0aW9ucyA4IGFu ZCA5IChkbyB0aGV5IG5lZWQgYW4gdXBkYXRlPykNCi0gVG9lcmxlc3MgYW5kIEkgd2lsbCBzaGFy ZSB0aGUgcmVtYWluaW5nIHNlY3Rpb25zIGZvciBub3cuDQoNCkRpZCBJIG1pc3MgYW55IHZvbHVu dGVlcj8gQW55IHdyb25nIC8gbWlzc2luZyBzZWN0aW9uPw0KDQpOb3csIHNvbWUgdGhvdWdodHMg b24gaG93IHdlIHByb2dyZXNzLCB0byBzZWUgd2hldGhlciB3ZSBoYXZlIGNvbnNlbnN1cy4NCi0g VGhlIG93bmVyIG9mIGEgc2VjdGlvbiBrZWVwcyBtYWludGFpbmluZyB0aGF0IHNlY3Rpb24uIFRo aXMgaXMgTk9UIGEgb25lLW9mZiwgYnV0IHJlcXVpcmVzIGNvbnRpbnVlZCB3b3JrIG9uIHlvdXIg c2VjdGlvbnMuDQotIEFueW9uZSBpbiB0aGUgYXV0aG9yIHRlYW0gaXMgZXhwZWN0ZWQgdG8gcmVh ZCB0aGUgZW50aXJlIGRvYywgYW5kIGNvbW1lbnQgb24gaXQsIGhlbHAgaW1wcm92ZSBpdC4NCi0g VGhpcyBkb2N1bWVudCBpcyBOT1QgdGhlIHN0YW5kYXJkLCBpdCBqdXN0IGxpbmtzIHVwIGFsbCB0 aGUgKGZ1dHVyZSkgc3RhbmRhcmRzLiBBdCB0aGUgZW5kLCBlYWNoIHNlY3Rpb24gd2lsbCBwb2lu dCB0byB0aGUgcmVsZXZhbnQgc3RhbmRhcmRzIHRyYWNrIGRvY3VtZW50LiBEZXRhaWxzIGFyZSBm b3IgdGhvc2UgZG9jdW1lbnRzLg0KLSBUaGlzIGRvY3VtZW50IGhhcyB0aGUgc2VyaW91cyBkYW5n ZXIgb2YgZ2V0dGluZyB2ZXJ5IGJpZywgdW5sZXNzIHdlIGFsbCBwYXkgYXR0ZW50aW9uLiBNYW55 IHN1Yi1zZWN0aW9ucyBjYW4gcHJvYmFibHkgYmUgZG9uZSBpbiBhIGZldyBwYXJhZ3JhcGhzLiBJ IHN1Z2dlc3QgdGhhdCBlYWNoIHN1Yi1zZWN0aW9uIHNob3VsZCBub3QgZXhjZWVkIGhhbGYgYSBw YWdlLiAoT2J2aW91c2x5LCB0aGlzIGlzIG5vdCBhIHByZWNpc2Ugc2NpZW5jZSwgYnV0ICJtb3Jl IG9yIGxlc3MiLikgIFRoZXJlZm9yZToNCi0gV3JpdGluZyBzdHlsZSBzaG91bGQgYmUgYXMgY29u Y2lzZSBhcyBwb3NzaWJsZS4gRXZlcnkgc2VudGVuY2UsIGV2ZXJ5IHdvcmQgc2hvdWxkIGJlIHRo ZXJlIGZvciBhIHJlYXNvbi4NCg0KRG8gd2UgYWdyZWU/IERpZCBJIG1pc3Mgc29tZXRoaW5nPw0K TWljaGFlbA0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KQW5pbWEgbWFpbGluZyBsaXN0DQpBbmltYUBpZXRmLm9yZzxtYWlsdG86QW5pbWFA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hDQoN Cg0KDQotLQ0KcmVnYXJkcywNCkpvaG4NCg== --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FEE6D6xmbrcdx14ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48Zm9udCBzaXplPSIyIiBm YWNlPSJUYWhvbWEiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztmb250 LXdlaWdodDpib2xkIj5Gcm9tOjwvc3Bhbj48L2ZvbnQ+PC9iPjxmb250IHNpemU9IjIiIGZhY2U9 IlRhaG9tYSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCiBKb2hu IFN0cmFzc25lciBbbWFpbHRvOnN0cmF6cGRqQGdtYWlsLmNvbV0gPGJyPg0KPGI+PHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlNlbnQ6PC9zcGFuPjwvYj4gMTIgSnVuZSAyMDE1IDIzOjUw PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOjwvc3Bhbj48L2I+IE1p Y2hhZWwgQmVocmluZ2VyIChtYmVocmluZyk8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWln aHQ6Ym9sZCI+Q2M6PC9zcGFuPjwvYj4gQW5pbWEgV0c8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9u dC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDo8L3NwYW4+PC9iPiBSZTogW0FuaW1hXSBSZWZlcmVuY2Ug ZG9jIC0gd2hvIGhlbHBzIHdoZXJlPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij5IaSBNaWNoYWVsLDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+dGhhbmtzIGZvciBvcmdhbml6aW5nIHRoaXMuIEknbSBjb25maXJt aW5nIGJvdGggbXkgYXNzaWduZWQgc2VjdGlvbnMgYXMgd2VsbCBhcyByZWFkaW5nIGFuZCBjb21t ZW50aW5nIG9uIHRoZSBlbnRpcmUgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij5SZWdhcmRpbmcgNy4yIChpbnRlbnQpLCB3ZSBzaG91bGQgYmUg Y2FyZWZ1bCB0byBzeW5jIChvciBleHBsYWluIHdoeSB3ZSBkaXNhZ3JlZSkgd2l0aCBpbnRlbnQg YXMgYmVpbmcgZGVmaW5lZCBpbiB0aGUgMTAwIG9yIHNvIG90aGVyIHBsYWNlcyB0aGF0IHBlb3Bs ZSBhcmUgd29ya2luZyBvbg0KIGl0LiBXZSBkb24ndCBuZWVkIHRvIHN5bmMgaW4gdGhpcyBkb2N1 bWVudCBvZiBjb3Vyc2UgLSBidXQgd2Ugc2hvdWxkIGJlIHByZXBhcmVkIHRvIGRlYWwgd2l0aCB0 aGlzIChpbWhvIGluZXZpdGFibGUpIHF1ZXN0aW9uIHdoZW4gaXQgY29tZXMgdXAuIEknbSBoYXBw eSB0byBoZWxwIEplZmZlcnNvbiBoZXJlIChJJ20gYWN0aXZlIGluIE9ORiwgT05PUywgQ29uZ3Jl c3MsIFRNRiwgYW5kIHJlbWVtYmVyIC0gU1VQQSBoYXMgYWxzbyBkZWZpbmVkIGludGVudCkuPG86 cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxmb250IHNpemU9IjMiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBz aXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1COiBJbmRlZWQuIFdl4oCZbGwgaGF2ZSBpbnRlcmVz dGluZyBkaXNjdXNzaW9ucyBvbiB0aGF0LiBBIGxvdCBkZXBlbmRzIG9uIHRoZSB3YXkgSW50ZW50 IGlzIGRlZmluZWQsIElNTy4gSWYgd2UNCiBoYXZlIGEgY2xlYXIgZGVmaW5pdGlvbiB3ZeKAmXJl IGEgc3RlcCBmdXJ0aGVyLiA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmki PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+SG93IHdvdWxkIHlvdSBsaWtlIHRvIHByb2NlZWQgb24gdXBkYXRlcz8g Rm9yIGV4YW1wbGUsIGlmIEkgdXBkYXRlIDcuMywgc2hvdWxkIEkgc2VuZCBhIGRyYWZ0LWJlaHJp bmdlci1hbmltYS1yZWZlcmVuY2UtbW9kZWwtMDItNy4zLWZyb20tamNzLnR4dCB0byB0aGUgYXV0 aG9yIGxpc3QsIEFOSU1BLA0KIG9yIGEgdG8tYmUtZGVmaW5lZCBHaXRIdWIgc2l0ZT88bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGZvbnQgc2l6ZT0iMyIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9 IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+TUI6IFlvdSB3aWxsIGhhdmUgc2VlbiBteSBnaXRodWIgbWFp bCB0b2RheS4gV2hpY2hldmVyIHdheSB5b3UgcHJlZmVyLCByZWFsbHkuIEkgc3VnZ2VzdCB0byBj b3B5IHRoZSBhbmltYSBsaXN0DQogb24gdGhlIHRleHRzLCBzbyB0aGF0IHBlb3BsZSBjYW4gcmVh ZC9jb21tZW50IHJpZ2h0IGF3YXkuIDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2Fs aWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBz aXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1pY2hhZWw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2Qi IGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQg c2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+YmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Kb2huPG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5PbiBUaHUsIEp1biAxMSwgMjAx NSBhdCA3OjI0IEFNLCBNaWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpICZsdDs8YSBocmVmPSJt YWlsdG86bWJlaHJpbmdAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+bWJlaHJpbmdAY2lzY28u Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPldpdGggdGhlIG5ldyBvdXRsaW5lIGluIHBsYWNlIChz ZWUgZHJhZnQtYmVocmluZ2VyLWFuaW1hLXJlZmVyZW5jZS1tb2RlbC0wMiwganVzdCBwb3N0ZWQp LCB3ZSBjYW4gbm93IGxvb2sgd2hvIG93bnMgd2hpY2ggc2VjdGlvbi48YnI+DQo8YnI+DQpOb3cg SSB0cnkgdG8gYmVzdCBtYXAgdGhlIHZvbHVudGVlcnMgSSd2ZSBzZWVuIHRvIHRoZSBzZWN0aW9u cywgYWNjb3JkaW5nIHRvIHRoZWlyIHN1Z2dlc3Rpb25zOjxicj4NCi0gTWljaGFlbCBSaWNoYXJk c29uOiBzZWN0aW9uIDMuMyAoY29uc3RyYWluZWQgbm9kZXMpPGJyPg0KLSBMaXViaW5nOiA0LjEg YW5kIDQuMiAoTmFtaW5nLCBhZGRyZXNzaW5nKTxicj4NCi0gQnJpYW4gQ2FycGVudGVyOiA0LjQg KHNpZ25hbGluZykuIENvdWxkIHlvdSBhbHNvIGNvdmVyIDQuNSAoaW50ZW50IGRpc3RyaWJ1dGlv bikgYW5kIDQuMyAoZGlzY292ZXJ5KT8gLSB2ZXJ5IHJlbGF0ZWQhITxicj4NCi0gSmFzb24gQ29s ZW1hbjogU2VjdGlvbiA1LjEsIDUuMiwgNS40LCA1LjUgKFBLSSwgY2VydCwgc3ViIGFuZCBjcm9z cy1kb21haW4pPGJyPg0KLSBKZWZlcnNvbiBOb2JyZTogNy4xLCA3LjIsIDcuMyAoTWFuYWdlbWVu dCwgaW50ZW50LCBhZ2dyZWdhdGVkIHJlcG9ydGluZyk8YnI+DQotIEpvaG4gU3RyYXNzbmVyOiA3 LjQsIDcuNSwgNy42IChmZWVkYmFjayBsb29wcywgQVBJUyBhbmQgbW9kZWxzLik8YnI+DQotIExh dXJlbnQgQ2lhdmFnbGlhOiBTZWN0aW9ucyA4IGFuZCA5IChkbyB0aGV5IG5lZWQgYW4gdXBkYXRl Pyk8YnI+DQotIFRvZXJsZXNzIGFuZCBJIHdpbGwgc2hhcmUgdGhlIHJlbWFpbmluZyBzZWN0aW9u cyBmb3Igbm93Ljxicj4NCjxicj4NCkRpZCBJIG1pc3MgYW55IHZvbHVudGVlcj8gQW55IHdyb25n IC8gbWlzc2luZyBzZWN0aW9uPzxicj4NCjxicj4NCk5vdywgc29tZSB0aG91Z2h0cyBvbiBob3cg d2UgcHJvZ3Jlc3MsIHRvIHNlZSB3aGV0aGVyIHdlIGhhdmUgY29uc2Vuc3VzLjxicj4NCi0gVGhl IG93bmVyIG9mIGEgc2VjdGlvbiBrZWVwcyBtYWludGFpbmluZyB0aGF0IHNlY3Rpb24uIFRoaXMg aXMgTk9UIGEgb25lLW9mZiwgYnV0IHJlcXVpcmVzIGNvbnRpbnVlZCB3b3JrIG9uIHlvdXIgc2Vj dGlvbnMuPGJyPg0KLSBBbnlvbmUgaW4gdGhlIGF1dGhvciB0ZWFtIGlzIGV4cGVjdGVkIHRvIHJl YWQgdGhlIGVudGlyZSBkb2MsIGFuZCBjb21tZW50IG9uIGl0LCBoZWxwIGltcHJvdmUgaXQuPGJy Pg0KLSBUaGlzIGRvY3VtZW50IGlzIE5PVCB0aGUgc3RhbmRhcmQsIGl0IGp1c3QgbGlua3MgdXAg YWxsIHRoZSAoZnV0dXJlKSBzdGFuZGFyZHMuIEF0IHRoZSBlbmQsIGVhY2ggc2VjdGlvbiB3aWxs IHBvaW50IHRvIHRoZSByZWxldmFudCBzdGFuZGFyZHMgdHJhY2sgZG9jdW1lbnQuIERldGFpbHMg YXJlIGZvciB0aG9zZSBkb2N1bWVudHMuPGJyPg0KLSBUaGlzIGRvY3VtZW50IGhhcyB0aGUgc2Vy aW91cyBkYW5nZXIgb2YgZ2V0dGluZyB2ZXJ5IGJpZywgdW5sZXNzIHdlIGFsbCBwYXkgYXR0ZW50 aW9uLiBNYW55IHN1Yi1zZWN0aW9ucyBjYW4gcHJvYmFibHkgYmUgZG9uZSBpbiBhIGZldyBwYXJh Z3JhcGhzLiBJIHN1Z2dlc3QgdGhhdCBlYWNoIHN1Yi1zZWN0aW9uIHNob3VsZCBub3QgZXhjZWVk IGhhbGYgYSBwYWdlLiAoT2J2aW91c2x5LCB0aGlzIGlzIG5vdCBhIHByZWNpc2Ugc2NpZW5jZSwg YnV0DQogJnF1b3Q7bW9yZSBvciBsZXNzJnF1b3Q7LikmbmJzcDsgVGhlcmVmb3JlOjxicj4NCi0g V3JpdGluZyBzdHlsZSBzaG91bGQgYmUgYXMgY29uY2lzZSBhcyBwb3NzaWJsZS4gRXZlcnkgc2Vu dGVuY2UsIGV2ZXJ5IHdvcmQgc2hvdWxkIGJlIHRoZXJlIGZvciBhIHJlYXNvbi48YnI+DQo8YnI+ DQpEbyB3ZSBhZ3JlZT8gRGlkIEkgbWlzcyBzb21ldGhpbmc/PGJyPg0KTWljaGFlbDxicj4NCjxi cj4NCjxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KQW5pbWEgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv OkFuaW1hQGlldGYub3JnIj5BbmltYUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYTwvYT48bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXpl PSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 Ij48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8YnI+DQotLSA8bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIz IiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5y ZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Kb2huPG86cD48L286cD48L3NwYW4+PC9mb250 PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FEE6D6xmbrcdx14ciscoc_-- From nobody Wed Jun 17 09:19:29 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4588B1B29F8 for ; Wed, 17 Jun 2015 09:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2DWyTlR8CBQ for ; Wed, 17 Jun 2015 09:19:25 -0700 (PDT) Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com [209.85.192.52]) (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 5F1661ACEAA for ; Wed, 17 Jun 2015 09:19:25 -0700 (PDT) Received: by qgf75 with SMTP id 75so16986025qgf.1 for ; Wed, 17 Jun 2015 09:19:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=niSnDhbWFyure5Vib+/+cwZ7JbTQJFXpv545W/uT6aM=; b=iojkus56zszoExv0q4ebATIi31NxO7oz1bxzA6gZfXLr9EbknKIZTCeE6RoElgljcj oLAtra9WfaCbZGS3BNPbDe9/UOxy/vygSqwKtfBdGCqpwCFddE2UJtwbwQiGtI7Iepd2 A6Nv5m2WvxRMSSamIVQidFZf37xAVSxrSbfdwfpY3fDrhClyeMqyyYKFspXgSMHRpdMN oO/zDmAEhnhzXduKqNe0LD791lnC3KejyyulBvB9AD/6tw4uWAWB4hnkzpBHtP6zy0CL 8kKJw+MetM4D72Sj1Rqi/oKFB0C0youxrObmeS4rpY4zctQUIIoiHhap8mIt11akYWF9 GMHw== X-Received: by 10.140.194.141 with SMTP id p135mr9409508qha.20.1434557963656; Wed, 17 Jun 2015 09:19:23 -0700 (PDT) MIME-Version: 1.0 References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FEE3B8@xmb-rcd-x14.cisco.com> In-Reply-To: From: =?UTF-8?Q?J=C3=A9ferson_Campos_Nobre?= Date: Wed, 17 Jun 2015 16:19:13 +0000 Message-ID: To: "Michael Behringer (mbehring)" , Anima WG Content-Type: multipart/alternative; boundary=001a114273eed563830518b90d2c Archived-At: Cc: "draft-behringer-anima-reference-model@tools.ietf.org" Subject: Re: [Anima] Reference doc on github X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 17 Jun 2015 16:19:27 -0000 --001a114273eed563830518b90d2c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > Hi Michael. > Could you please add me in the github rep? My ID is jcnobre > I think Wed next week is a reasonable time. > Thanks. > Best. > J=C3=A9ferson > > Em qua, 17 de jun de 2015 =C3=A0s 09:41, Michael Behringer (mbehring) < > mbehring@cisco.com> escreveu: > >> I have now also created a repository in github: >> https://github.com/mbehring/ANIMA-Reference-Model >> >> I suggested initial contributions, as per below list (open to more >> suggestions ;-) >> >> - Michael Richardson: section 3.3 (constrained nodes) >> - Liubing: 4.1 and 4.2 (Naming, addressing) >> - Brian Carpenter: 4.4 (signaling). Could you also cover 4.5 (intent >> distribution) and 4.3 (discovery)? - very related!! >> - Jason Coleman: Section 5.1, 5.2, 5.4, 5.5 (PKI, cert, sub and >> cross-domain) >> - Jeferson Nobre: 7.1, 7.2, 7.3 (Management, intent, aggregated reportin= g) >> - John Strassner: 7.4, 7.5, 7.6 (feedback loops, APIS and models.) >> - Laurent Ciavaglia: Sections 8 and 9 (do they need an update?) >> - Toerless and I will share the remaining sections for now. >> >> Can the volunteers please let me know by when they can contribute their >> text? Either in github (let me know your ID if you want to contribute >> there) >> >> Github is not mandatory - If you want to send me your text via mail, >> that's ok. I'd strongly prefer XML formatted sections if possible ;-) >> >> Can we have all text in by Wed next week? >> >> I plan to consolidate and push -03 by end of next week. >> >> Michael >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> > --001a114273eed563830518b90d2c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=
Hi Michael.
Could you please add me in the github rep?= My ID is jcnobre
I think Wed next week is a reasonable time.
Thanks.
Best.
= J=C3=A9ferson

Em qua, 17 de jun de 2015 =C3=A0s 09:41, Michael Behrin= ger (mbehring) <= mbehring@cisco.com> escreveu:
h= ttps://github.com/mbehring/ANIMA-Reference-Model

I suggested initial contributions, as per below list (open to more suggesti= ons ;-)

- Michael Richardson: section 3.3 (constrained nodes)
- Liubing: 4.1 and 4.2 (Naming, addressing)
- Brian Carpenter: 4.4 (signaling). Could you also cover 4.5 (intent distri= bution) and 4.3 (discovery)? - very related!!
- Jason Coleman: Section 5.1, 5.2, 5.4, 5.5 (PKI, cert, sub and cross-domai= n)
- Jeferson Nobre: 7.1, 7.2, 7.3 (Management, intent, aggregated reporting)<= br> - John Strassner: 7.4, 7.5, 7.6 (feedback loops, APIS and models.)
- Laurent Ciavaglia: Sections 8 and 9 (do they need an update?)
- Toerless and I will share the remaining sections for now.

Can the volunteers please let me know by when they can contribute their tex= t?=C2=A0 Either in github (let me know your ID if you want to contribute th= ere)

Github is not mandatory - If you want to send me your text via mail, that&#= 39;s ok. I'd strongly prefer XML formatted sections if possible ;-)

Can we have all text in by Wed next week?

I plan to consolidate and push -03 by end of next week.

Michael
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
--001a114273eed563830518b90d2c-- From nobody Wed Jun 17 10:03:59 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B05B1B2AF1 for ; Wed, 17 Jun 2015 10:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.21 X-Spam-Level: X-Spam-Status: No, score=-14.21 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, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDEFUySxmg-u for ; Wed, 17 Jun 2015 10:03:56 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97ACB1B2AF0 for ; Wed, 17 Jun 2015 10:03:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12016; q=dns/txt; s=iport; t=1434560636; x=1435770236; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=uenfRzY8K9nFt27hYzGZ2WwMh9GGWIv9B+o9X+UHxrc=; b=Xn3yq+5uMK9nDkhGmA01AENbG7u174B2TjQq0do+BG++1Mk6DU0VgOSw 1znCbDOImAwqNtRlch5bs3w7thupJnOznWr8k1frMB/GQQDQlqmXG/75f i2A//6tQauSzYOoIyiXjeq3sy8Znl+spsjStbmWrVW6kO+NMTFVRX1aFx 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AoBQDfp4FV/4cNJK1cgkVLVF8Ggxi5WGYJgV0BCYV4AhyBHTgUAQEBAQEBAYEKhCIBAQEEAQEBIApBCxACAQgRBAEBCx0DAgICJQsUCQgBAQQBDQUIiCcNsxKWTgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi0SENAEBHy0EBgGCaC+BFAWREYJXAYRSiCiECopkhCODWyaDeW+BAwcCFyOBAgEBAQ X-IronPort-AV: E=Sophos;i="5.13,633,1427760000"; d="scan'208,217";a="2433128" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-8.cisco.com with ESMTP; 17 Jun 2015 17:03:55 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t5HH3trm025999 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jun 2015 17:03:55 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.179]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Wed, 17 Jun 2015 12:03:55 -0500 From: "Michael Behringer (mbehring)" To: =?utf-8?B?SsOpZmVyc29uIENhbXBvcyBOb2JyZQ==?= , "Anima WG" Thread-Topic: [Anima] Reference doc on github Thread-Index: AdCo+dAvfC4NDb/zTJOIdvnhU/aAQgASUZcAAAAK4YAACOzX8A== Date: Wed, 17 Jun 2015 17:03:54 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FEE7B1@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FEE3B8@xmb-rcd-x14.cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.132] Content-Type: multipart/alternative; boundary="_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FEE7B1xmbrcdx14ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "draft-behringer-anima-reference-model@tools.ietf.org" Subject: Re: [Anima] Reference doc on github X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 17 Jun 2015 17:03:58 -0000 --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FEE7B1xmbrcdx14ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ZG9uZSEgVGhhbmtzIGZvciB0aGUgY29uZmlybWF0aW9uIQ0KDQpGcm9tOiBKw6lmZXJzb24gQ2Ft cG9zIE5vYnJlIFttYWlsdG86amNub2JyZUBpbmYudWZyZ3MuYnJdDQpTZW50OiAxNyBKdW5lIDIw MTUgMTg6MTkNClRvOiBNaWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpOyBBbmltYSBXRw0KQ2M6 IGRyYWZ0LWJlaHJpbmdlci1hbmltYS1yZWZlcmVuY2UtbW9kZWxAdG9vbHMuaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbQW5pbWFdIFJlZmVyZW5jZSBkb2Mgb24gZ2l0aHViDQoNCkhpIE1pY2hhZWwu DQpDb3VsZCB5b3UgcGxlYXNlIGFkZCBtZSBpbiB0aGUgZ2l0aHViIHJlcD8gTXkgSUQgaXMgamNu b2JyZQ0KSSB0aGluayBXZWQgbmV4dCB3ZWVrIGlzIGEgcmVhc29uYWJsZSB0aW1lLg0KVGhhbmtz Lg0KQmVzdC4NCkrDqWZlcnNvbg0KDQpFbSBxdWEsIDE3IGRlIGp1biBkZSAyMDE1IMOgcyAwOTo0 MSwgTWljaGFlbCBCZWhyaW5nZXIgKG1iZWhyaW5nKSA8bWJlaHJpbmdAY2lzY28uY29tPG1haWx0 bzptYmVocmluZ0BjaXNjby5jb20+PiBlc2NyZXZldToNCkkgaGF2ZSBub3cgYWxzbyBjcmVhdGVk IGEgcmVwb3NpdG9yeSBpbiBnaXRodWI6IGh0dHBzOi8vZ2l0aHViLmNvbS9tYmVocmluZy9BTklN QS1SZWZlcmVuY2UtTW9kZWwNCg0KSSBzdWdnZXN0ZWQgaW5pdGlhbCBjb250cmlidXRpb25zLCBh cyBwZXIgYmVsb3cgbGlzdCAob3BlbiB0byBtb3JlIHN1Z2dlc3Rpb25zIDstKQ0KDQotIE1pY2hh ZWwgUmljaGFyZHNvbjogc2VjdGlvbiAzLjMgKGNvbnN0cmFpbmVkIG5vZGVzKQ0KLSBMaXViaW5n OiA0LjEgYW5kIDQuMiAoTmFtaW5nLCBhZGRyZXNzaW5nKQ0KLSBCcmlhbiBDYXJwZW50ZXI6IDQu NCAoc2lnbmFsaW5nKS4gQ291bGQgeW91IGFsc28gY292ZXIgNC41IChpbnRlbnQgZGlzdHJpYnV0 aW9uKSBhbmQgNC4zIChkaXNjb3ZlcnkpPyAtIHZlcnkgcmVsYXRlZCEhDQotIEphc29uIENvbGVt YW46IFNlY3Rpb24gNS4xLCA1LjIsIDUuNCwgNS41IChQS0ksIGNlcnQsIHN1YiBhbmQgY3Jvc3Mt ZG9tYWluKQ0KLSBKZWZlcnNvbiBOb2JyZTogNy4xLCA3LjIsIDcuMyAoTWFuYWdlbWVudCwgaW50 ZW50LCBhZ2dyZWdhdGVkIHJlcG9ydGluZykNCi0gSm9obiBTdHJhc3NuZXI6IDcuNCwgNy41LCA3 LjYgKGZlZWRiYWNrIGxvb3BzLCBBUElTIGFuZCBtb2RlbHMuKQ0KLSBMYXVyZW50IENpYXZhZ2xp YTogU2VjdGlvbnMgOCBhbmQgOSAoZG8gdGhleSBuZWVkIGFuIHVwZGF0ZT8pDQotIFRvZXJsZXNz IGFuZCBJIHdpbGwgc2hhcmUgdGhlIHJlbWFpbmluZyBzZWN0aW9ucyBmb3Igbm93Lg0KDQpDYW4g dGhlIHZvbHVudGVlcnMgcGxlYXNlIGxldCBtZSBrbm93IGJ5IHdoZW4gdGhleSBjYW4gY29udHJp YnV0ZSB0aGVpciB0ZXh0PyAgRWl0aGVyIGluIGdpdGh1YiAobGV0IG1lIGtub3cgeW91ciBJRCBp ZiB5b3Ugd2FudCB0byBjb250cmlidXRlIHRoZXJlKQ0KDQpHaXRodWIgaXMgbm90IG1hbmRhdG9y eSAtIElmIHlvdSB3YW50IHRvIHNlbmQgbWUgeW91ciB0ZXh0IHZpYSBtYWlsLCB0aGF0J3Mgb2su IEknZCBzdHJvbmdseSBwcmVmZXIgWE1MIGZvcm1hdHRlZCBzZWN0aW9ucyBpZiBwb3NzaWJsZSA7 LSkNCg0KQ2FuIHdlIGhhdmUgYWxsIHRleHQgaW4gYnkgV2VkIG5leHQgd2Vlaz8NCg0KSSBwbGFu IHRvIGNvbnNvbGlkYXRlIGFuZCBwdXNoIC0wMyBieSBlbmQgb2YgbmV4dCB3ZWVrLg0KDQpNaWNo YWVsDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQW5p bWEgbWFpbGluZyBsaXN0DQpBbmltYUBpZXRmLm9yZzxtYWlsdG86QW5pbWFAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hDQo= --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FEE7B1xmbrcdx14ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9 IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5kb25lISBUaGFua3MgZm9yIHRoZSBjb25maXJtYXRpb24hPG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNv bG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow Y20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iVGFob21hIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Zm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTo8 L3NwYW4+PC9mb250PjwvYj48Zm9udCBzaXplPSIyIiBmYWNlPSJUYWhvbWEiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQogSsOpZmVyc29uIENhbXBvcyBOb2JyZSBb bWFpbHRvOmpjbm9icmVAaW5mLnVmcmdzLmJyXSA8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13 ZWlnaHQ6Ym9sZCI+U2VudDo8L3NwYW4+PC9iPiAxNyBKdW5lIDIwMTUgMTg6MTk8YnI+DQo8Yj48 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86PC9zcGFuPjwvYj4gTWljaGFlbCBCZWhy aW5nZXIgKG1iZWhyaW5nKTsgQW5pbWEgV0c8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWln aHQ6Ym9sZCI+Q2M6PC9zcGFuPjwvYj4gZHJhZnQtYmVocmluZ2VyLWFuaW1hLXJlZmVyZW5jZS1t b2RlbEB0b29scy5pZXRmLm9yZzxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5TdWJqZWN0Ojwvc3Bhbj48L2I+IFJlOiBbQW5pbWFdIFJlZmVyZW5jZSBkb2Mgb24gZ2l0aHVi PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPkhpIE1pY2hhZWwuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Db3VsZCB5b3UgcGxlYXNlIGFk ZCBtZSBpbiB0aGUgZ2l0aHViIHJlcD8gTXkgSUQgaXMgamNub2JyZTxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBz aXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij5JIHRoaW5rIFdlZCBuZXh0IHdlZWsgaXMgYSByZWFzb25hYmxlIHRpbWUuPG86cD48L286 cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPlRoYW5rcy48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QmVzdC48bzpwPjwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+SsOpZmVyc29uPG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkVtIHF1YSwgMTcgZGUg anVuIGRlIDIwMTUgw6BzIDA5OjQxLCBNaWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpICZsdDs8 YSBocmVmPSJtYWlsdG86bWJlaHJpbmdAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+bWJlaHJp bmdAY2lzY28uY29tPC9hPiZndDsgZXNjcmV2ZXU6PG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9 IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi PkkgaGF2ZSBub3cgYWxzbyBjcmVhdGVkIGEgcmVwb3NpdG9yeSBpbiBnaXRodWI6DQo8YSBocmVm PSJodHRwczovL2dpdGh1Yi5jb20vbWJlaHJpbmcvQU5JTUEtUmVmZXJlbmNlLU1vZGVsIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly9naXRodWIuY29tL21iZWhyaW5nL0FOSU1BLVJlZmVyZW5jZS1N b2RlbDwvYT48YnI+DQo8YnI+DQpJIHN1Z2dlc3RlZCBpbml0aWFsIGNvbnRyaWJ1dGlvbnMsIGFz IHBlciBiZWxvdyBsaXN0IChvcGVuIHRvIG1vcmUgc3VnZ2VzdGlvbnMgOy0pPGJyPg0KPGJyPg0K LSBNaWNoYWVsIFJpY2hhcmRzb246IHNlY3Rpb24gMy4zIChjb25zdHJhaW5lZCBub2Rlcyk8YnI+ DQotIExpdWJpbmc6IDQuMSBhbmQgNC4yIChOYW1pbmcsIGFkZHJlc3NpbmcpPGJyPg0KLSBCcmlh biBDYXJwZW50ZXI6IDQuNCAoc2lnbmFsaW5nKS4gQ291bGQgeW91IGFsc28gY292ZXIgNC41IChp bnRlbnQgZGlzdHJpYnV0aW9uKSBhbmQgNC4zIChkaXNjb3ZlcnkpPyAtIHZlcnkgcmVsYXRlZCEh PGJyPg0KLSBKYXNvbiBDb2xlbWFuOiBTZWN0aW9uIDUuMSwgNS4yLCA1LjQsIDUuNSAoUEtJLCBj ZXJ0LCBzdWIgYW5kIGNyb3NzLWRvbWFpbik8YnI+DQotIEplZmVyc29uIE5vYnJlOiA3LjEsIDcu MiwgNy4zIChNYW5hZ2VtZW50LCBpbnRlbnQsIGFnZ3JlZ2F0ZWQgcmVwb3J0aW5nKTxicj4NCi0g Sm9obiBTdHJhc3NuZXI6IDcuNCwgNy41LCA3LjYgKGZlZWRiYWNrIGxvb3BzLCBBUElTIGFuZCBt b2RlbHMuKTxicj4NCi0gTGF1cmVudCBDaWF2YWdsaWE6IFNlY3Rpb25zIDggYW5kIDkgKGRvIHRo ZXkgbmVlZCBhbiB1cGRhdGU/KTxicj4NCi0gVG9lcmxlc3MgYW5kIEkgd2lsbCBzaGFyZSB0aGUg cmVtYWluaW5nIHNlY3Rpb25zIGZvciBub3cuPGJyPg0KPGJyPg0KQ2FuIHRoZSB2b2x1bnRlZXJz IHBsZWFzZSBsZXQgbWUga25vdyBieSB3aGVuIHRoZXkgY2FuIGNvbnRyaWJ1dGUgdGhlaXIgdGV4 dD8mbmJzcDsgRWl0aGVyIGluIGdpdGh1YiAobGV0IG1lIGtub3cgeW91ciBJRCBpZiB5b3Ugd2Fu dCB0byBjb250cmlidXRlIHRoZXJlKTxicj4NCjxicj4NCkdpdGh1YiBpcyBub3QgbWFuZGF0b3J5 IC0gSWYgeW91IHdhbnQgdG8gc2VuZCBtZSB5b3VyIHRleHQgdmlhIG1haWwsIHRoYXQncyBvay4g SSdkIHN0cm9uZ2x5IHByZWZlciBYTUwgZm9ybWF0dGVkIHNlY3Rpb25zIGlmIHBvc3NpYmxlIDst KTxicj4NCjxicj4NCkNhbiB3ZSBoYXZlIGFsbCB0ZXh0IGluIGJ5IFdlZCBuZXh0IHdlZWs/PGJy Pg0KPGJyPg0KSSBwbGFuIHRvIGNvbnNvbGlkYXRlIGFuZCBwdXNoIC0wMyBieSBlbmQgb2YgbmV4 dCB3ZWVrLjxicj4NCjxicj4NCk1pY2hhZWw8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCkFuaW1hIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzpBbmltYUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPkFuaW1hQGlldGYub3Jn PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v YW5pbWEiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2FuaW1hPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FEE7B1xmbrcdx14ciscoc_-- From nobody Wed Jun 17 21:57:59 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5349C1B2EDF for ; Wed, 17 Jun 2015 21:57:57 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3fGEC66o98P for ; Wed, 17 Jun 2015 21:57:55 -0700 (PDT) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (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 1157D1B2ED9 for ; Wed, 17 Jun 2015 21:57:55 -0700 (PDT) Received: by wicnd19 with SMTP id nd19so10697485wic.1 for ; Wed, 17 Jun 2015 21:57:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ECpyn3en9bsRXD3ToZYjanhhAWDitcs2D0xFcmltNhQ=; b=UDk3Dg7LPnthOleAl2rf5Amrt60T5jK1AHdx7lmco/8VHbxCmYgHcXdGGHvcMfviRb 3s7e3AtUfMsvC/jK3JWZc0VzPmal57phZlM9oiMFOk0MLI2GrvD5IMGq9SYfszh5J8ew l4JshWlHZnKGh72UaxsYan/opTvvA03G6YoQyojy9AX8zWLacJaARSkigRel8DyFONGO IwamdciGEBI8j3pf9jwDqap+MUVS9qhy3BXMTcpuJHQDMISYC5C7OBeKd772ulYUEzdh /rS1uZZZEWGXzBS3Psv9qfkQgAbni+tbAs0ESrOO+onJ+VjTcskxVibx1ZEIUQ+sLU2c 17ug== MIME-Version: 1.0 X-Received: by 10.180.100.74 with SMTP id ew10mr62266530wib.12.1434603428763; Wed, 17 Jun 2015 21:57:08 -0700 (PDT) Received: by 10.27.220.1 with HTTP; Wed, 17 Jun 2015 21:57:08 -0700 (PDT) In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FEE7B1@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FEE3B8@xmb-rcd-x14.cisco.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FEE7B1@xmb-rcd-x14.cisco.com> Date: Wed, 17 Jun 2015 21:57:08 -0700 Message-ID: From: John Strassner To: "Michael Behringer (mbehring)" Content-Type: multipart/alternative; boundary=14dae9cc9c5ac3dc2a0518c3a349 Archived-At: Cc: "draft-behringer-anima-reference-model@tools.ietf.org" , =?UTF-8?Q?J=C3=A9ferson_Campos_Nobre?= , Anima WG Subject: Re: [Anima] Reference doc on github X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 18 Jun 2015 04:57:57 -0000 --14dae9cc9c5ac3dc2a0518c3a349 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My github ID is strazzie123 On Wed, Jun 17, 2015 at 10:03 AM, Michael Behringer (mbehring) < mbehring@cisco.com> wrote: > done! Thanks for the confirmation! > > > > *From:* J=C3=A9ferson Campos Nobre [mailto:jcnobre@inf.ufrgs.br] > *Sent:* 17 June 2015 18:19 > *To:* Michael Behringer (mbehring); Anima WG > *Cc:* draft-behringer-anima-reference-model@tools.ietf.org > *Subject:* Re: [Anima] Reference doc on github > > > > Hi Michael. > > Could you please add me in the github rep? My ID is jcnobre > > I think Wed next week is a reasonable time. > > Thanks. > > Best. > > J=C3=A9ferson > > > > Em qua, 17 de jun de 2015 =C3=A0s 09:41, Michael Behringer (mbehring) < > mbehring@cisco.com> escreveu: > > I have now also created a repository in github: > https://github.com/mbehring/ANIMA-Reference-Model > > I suggested initial contributions, as per below list (open to more > suggestions ;-) > > - Michael Richardson: section 3.3 (constrained nodes) > - Liubing: 4.1 and 4.2 (Naming, addressing) > - Brian Carpenter: 4.4 (signaling). Could you also cover 4.5 (intent > distribution) and 4.3 (discovery)? - very related!! > - Jason Coleman: Section 5.1, 5.2, 5.4, 5.5 (PKI, cert, sub and > cross-domain) > - Jeferson Nobre: 7.1, 7.2, 7.3 (Management, intent, aggregated reporting= ) > - John Strassner: 7.4, 7.5, 7.6 (feedback loops, APIS and models.) > - Laurent Ciavaglia: Sections 8 and 9 (do they need an update?) > - Toerless and I will share the remaining sections for now. > > Can the volunteers please let me know by when they can contribute their > text? Either in github (let me know your ID if you want to contribute > there) > > Github is not mandatory - If you want to send me your text via mail, > that's ok. I'd strongly prefer XML formatted sections if possible ;-) > > Can we have all text in by Wed next week? > > I plan to consolidate and push -03 by end of next week. > > Michael > _______________________________________________ > 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 > > --=20 regards, John --14dae9cc9c5ac3dc2a0518c3a349 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My github ID is strazzie123
 --14dae9cc9c5ac3dc2a0518c3a349-- From nobody Wed Jun 17 22:23:08 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2281AD363 for ; Wed, 17 Jun 2015 22:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbKolHRgdQjF for ; Wed, 17 Jun 2015 22:23:05 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::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 0300E1B2F63 for ; Wed, 17 Jun 2015 22:23:04 -0700 (PDT) Received: by wgez8 with SMTP id z8so53453471wge.0 for ; Wed, 17 Jun 2015 22:23:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HbGsht7fb0zFujoYLMXw5PoCpdFev8mjKcIJJNr3Z8U=; b=LyOSTnmH6lcKk8RniBciyE/9jY6Xa3CBUNrZPx2FrYbtAZH24OAvqAYZRmsKZy0+l2 Pck60K88VRAXCjpHr8i6zJnTurY19/suMhE9zqQAnoFjigvaL6CaxoeMx7/Zp9PnEm6C acyRyKeQ6y7gUAjgSb2PCQ/by/NnRw2EZubY1zMq75Uvip4tBtWvqlO45J/N/8FsnvNr 2Jcc26/IniFWc3zM7nEZXMMbP1yMhZ6ZJwVZjc/hd/qKQVRQ91DyK0b7BBskeEvQueXM DPgXUg373PMF4HInFC0yviob8q1+cGH88WKjoIu+b4TrPhMwZD/yWDixok+alck+jakI 5clA== MIME-Version: 1.0 X-Received: by 10.180.211.109 with SMTP id nb13mr30411490wic.8.1434604983753; Wed, 17 Jun 2015 22:23:03 -0700 (PDT) Received: by 10.27.220.1 with HTTP; Wed, 17 Jun 2015 22:23:03 -0700 (PDT) In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FEE3B8@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FEE3B8@xmb-rcd-x14.cisco.com> Date: Wed, 17 Jun 2015 22:23:03 -0700 Message-ID: From: John Strassner To: "Michael Behringer (mbehring)" Content-Type: multipart/alternative; boundary=001a11c3819e73207b0518c400b9 Archived-At: Cc: "draft-behringer-anima-reference-model@tools.ietf.org" , Anima WG Subject: Re: [Anima] Reference doc on github X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 18 Jun 2015 05:23:07 -0000 --001a11c3819e73207b0518c400b9 Content-Type: text/plain; charset=UTF-8 I hope to be done with my sections by Monday next week. I will also provide comments on most other sections by Wednesday next week. regards, John On Wed, Jun 17, 2015 at 5:41 AM, Michael Behringer (mbehring) < mbehring@cisco.com> wrote: > I have now also created a repository in github: > https://github.com/mbehring/ANIMA-Reference-Model > > I suggested initial contributions, as per below list (open to more > suggestions ;-) > > - Michael Richardson: section 3.3 (constrained nodes) > - Liubing: 4.1 and 4.2 (Naming, addressing) > - Brian Carpenter: 4.4 (signaling). Could you also cover 4.5 (intent > distribution) and 4.3 (discovery)? - very related!! > - Jason Coleman: Section 5.1, 5.2, 5.4, 5.5 (PKI, cert, sub and > cross-domain) > - Jeferson Nobre: 7.1, 7.2, 7.3 (Management, intent, aggregated reporting) > - John Strassner: 7.4, 7.5, 7.6 (feedback loops, APIS and models.) > - Laurent Ciavaglia: Sections 8 and 9 (do they need an update?) > - Toerless and I will share the remaining sections for now. > > Can the volunteers please let me know by when they can contribute their > text? Either in github (let me know your ID if you want to contribute > there) > > Github is not mandatory - If you want to send me your text via mail, > that's ok. I'd strongly prefer XML formatted sections if possible ;-) > > Can we have all text in by Wed next week? > > I plan to consolidate and push -03 by end of next week. > > Michael > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > -- regards, John --001a11c3819e73207b0518c400b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I hope to be done with my sections by Monday next wee= k. I will also provide comments on most other sections by Wednesday next we= ek.

regards,
John

On Wed, Jun 17, 2015 at 5:4= 1 AM, Michael Behringer (mbehring) <mbehring@cisco.com> wro= te:
I have now also created a repository = in github: https://github.com/mbehring/ANIMA-Refere= nce-Model

I suggested initial contributions, as per below list (open to more suggesti= ons ;-)

- Michael Richardson: section 3.3 (constrained nodes)
- Liubing: 4.1 and 4.2 (Naming, addressing)
- Brian Carpenter: 4.4 (signaling). Could you also cover 4.5 (intent distri= bution) and 4.3 (discovery)? - very related!!
- Jason Coleman: Section 5.1, 5.2, 5.4, 5.5 (PKI, cert, sub and cross-domai= n)
- Jeferson Nobre: 7.1, 7.2, 7.3 (Management, intent, aggregated reporting)<= br> - John Strassner: 7.4, 7.5, 7.6 (feedback loops, APIS and models.)
- Laurent Ciavaglia: Sections 8 and 9 (do they need an update?)
- Toerless and I will share the remaining sections for now.

Can the volunteers please let me know by when they can contribute their tex= t?=C2=A0 Either in github (let me know your ID if you want to contribute th= ere)

Github is not mandatory - If you want to send me your text via mail, that&#= 39;s ok. I'd strongly prefer XML formatted sections if possible ;-)

Can we have all text in by Wed next week?

I plan to consolidate and push -03 by end of next week.

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



--
regards,
John
--001a11c3819e73207b0518c400b9-- From nobody Thu Jun 18 00:03:13 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E8E1B2FE6 for ; Thu, 18 Jun 2015 00:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6QYDnIXqgI1 for ; Thu, 18 Jun 2015 00:03:09 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33D941B305E for ; Thu, 18 Jun 2015 00:03:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19294; q=dns/txt; s=iport; t=1434610989; x=1435820589; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WqS9loII/OkKTtDRdwrdHRNZy1ar5XuM5Xry1ZhzXt8=; b=SU/urnbLI4HfMtg9t9sP89z/wX8X0uTka8lZSlw8zkCLhScJ3MEiKkVL xy5zrZQZKz3IIuIzzT8z9/RORKonx/KeCHinaBWXTuzUuEcnXBO0ra5Us O5RRtvq9i2bqYtYrOPIwd8qafYDlitEyw67fn+2MqXMau8pJOovqfrlLz 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C4BAD+a4JV/5ldJa1cgkVLVF8Ggxi5bGYJgVsBCYV4AhyBFzgUAQEBAQEBAYEKhCIBAQEEAQEBIApBCxACAQgOAwQBAQsdAwICAh8GCxQJCAEBBA4FCIgSAxINrkmQXw2FVQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi0WCTYFnAQEfLQQGAYJoL4EUBZEXglkBhFKFFYMWhAqKZmmDPINbJoN5b4EDBwIXI4ECAQEB X-IronPort-AV: E=Sophos;i="5.13,638,1427760000"; d="scan'208,217";a="2607122" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 18 Jun 2015 07:03:08 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t5I738GW032335 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Jun 2015 07:03:08 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.179]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Thu, 18 Jun 2015 02:03:08 -0500 From: "Michael Behringer (mbehring)" To: John Strassner Thread-Topic: [Anima] Reference doc on github Thread-Index: AdCo+dAvfC4NDb/zTJOIdvnhU/aAQgASUZcAAAAK4YAACOzX8AARi3YAAAYY4XA= Date: Thu, 18 Jun 2015 07:03:07 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FEEAC8@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FEE3B8@xmb-rcd-x14.cisco.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FEE7B1@xmb-rcd-x14.cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.132] Content-Type: multipart/alternative; boundary="_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FEEAC8xmbrcdx14ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "draft-behringer-anima-reference-model@tools.ietf.org" , =?utf-8?B?SsOpZmVyc29uIENhbXBvcyBOb2JyZQ==?= , Anima WG Subject: Re: [Anima] Reference doc on github X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 18 Jun 2015 07:03:11 -0000 --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FEEAC8xmbrcdx14ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWRkZWQhDQoNCkZyb206IEpvaG4gU3RyYXNzbmVyIFttYWlsdG86c3RyYXpwZGpAZ21haWwuY29t XQ0KU2VudDogMTggSnVuZSAyMDE1IDA2OjU3DQpUbzogTWljaGFlbCBCZWhyaW5nZXIgKG1iZWhy aW5nKQ0KQ2M6IErDqWZlcnNvbiBDYW1wb3MgTm9icmU7IEFuaW1hIFdHOyBkcmFmdC1iZWhyaW5n ZXItYW5pbWEtcmVmZXJlbmNlLW1vZGVsQHRvb2xzLmlldGYub3JnDQpTdWJqZWN0OiBSZTogW0Fu aW1hXSBSZWZlcmVuY2UgZG9jIG9uIGdpdGh1Yg0KDQpNeSBnaXRodWIgSUQgaXMgc3RyYXp6aWUx MjMNCg0KT24gV2VkLCBKdW4gMTcsIDIwMTUgYXQgMTA6MDMgQU0sIE1pY2hhZWwgQmVocmluZ2Vy IChtYmVocmluZykgPG1iZWhyaW5nQGNpc2NvLmNvbTxtYWlsdG86bWJlaHJpbmdAY2lzY28uY29t Pj4gd3JvdGU6DQpkb25lISBUaGFua3MgZm9yIHRoZSBjb25maXJtYXRpb24hDQoNCkZyb206IErD qWZlcnNvbiBDYW1wb3MgTm9icmUgW21haWx0bzpqY25vYnJlQGluZi51ZnJncy5icjxtYWlsdG86 amNub2JyZUBpbmYudWZyZ3MuYnI+XQ0KU2VudDogMTcgSnVuZSAyMDE1IDE4OjE5DQpUbzogTWlj aGFlbCBCZWhyaW5nZXIgKG1iZWhyaW5nKTsgQW5pbWEgV0cNCkNjOiBkcmFmdC1iZWhyaW5nZXIt YW5pbWEtcmVmZXJlbmNlLW1vZGVsQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1iZWhyaW5n ZXItYW5pbWEtcmVmZXJlbmNlLW1vZGVsQHRvb2xzLmlldGYub3JnPg0KU3ViamVjdDogUmU6IFtB bmltYV0gUmVmZXJlbmNlIGRvYyBvbiBnaXRodWINCg0KSGkgTWljaGFlbC4NCkNvdWxkIHlvdSBw bGVhc2UgYWRkIG1lIGluIHRoZSBnaXRodWIgcmVwPyBNeSBJRCBpcyBqY25vYnJlDQpJIHRoaW5r IFdlZCBuZXh0IHdlZWsgaXMgYSByZWFzb25hYmxlIHRpbWUuDQpUaGFua3MuDQpCZXN0Lg0KSsOp ZmVyc29uDQoNCkVtIHF1YSwgMTcgZGUganVuIGRlIDIwMTUgw6BzIDA5OjQxLCBNaWNoYWVsIEJl aHJpbmdlciAobWJlaHJpbmcpIDxtYmVocmluZ0BjaXNjby5jb208bWFpbHRvOm1iZWhyaW5nQGNp c2NvLmNvbT4+IGVzY3JldmV1Og0KSSBoYXZlIG5vdyBhbHNvIGNyZWF0ZWQgYSByZXBvc2l0b3J5 IGluIGdpdGh1YjogaHR0cHM6Ly9naXRodWIuY29tL21iZWhyaW5nL0FOSU1BLVJlZmVyZW5jZS1N b2RlbA0KDQpJIHN1Z2dlc3RlZCBpbml0aWFsIGNvbnRyaWJ1dGlvbnMsIGFzIHBlciBiZWxvdyBs aXN0IChvcGVuIHRvIG1vcmUgc3VnZ2VzdGlvbnMgOy0pDQoNCi0gTWljaGFlbCBSaWNoYXJkc29u OiBzZWN0aW9uIDMuMyAoY29uc3RyYWluZWQgbm9kZXMpDQotIExpdWJpbmc6IDQuMSBhbmQgNC4y IChOYW1pbmcsIGFkZHJlc3NpbmcpDQotIEJyaWFuIENhcnBlbnRlcjogNC40IChzaWduYWxpbmcp LiBDb3VsZCB5b3UgYWxzbyBjb3ZlciA0LjUgKGludGVudCBkaXN0cmlidXRpb24pIGFuZCA0LjMg KGRpc2NvdmVyeSk/IC0gdmVyeSByZWxhdGVkISENCi0gSmFzb24gQ29sZW1hbjogU2VjdGlvbiA1 LjEsIDUuMiwgNS40LCA1LjUgKFBLSSwgY2VydCwgc3ViIGFuZCBjcm9zcy1kb21haW4pDQotIEpl ZmVyc29uIE5vYnJlOiA3LjEsIDcuMiwgNy4zIChNYW5hZ2VtZW50LCBpbnRlbnQsIGFnZ3JlZ2F0 ZWQgcmVwb3J0aW5nKQ0KLSBKb2huIFN0cmFzc25lcjogNy40LCA3LjUsIDcuNiAoZmVlZGJhY2sg bG9vcHMsIEFQSVMgYW5kIG1vZGVscy4pDQotIExhdXJlbnQgQ2lhdmFnbGlhOiBTZWN0aW9ucyA4 IGFuZCA5IChkbyB0aGV5IG5lZWQgYW4gdXBkYXRlPykNCi0gVG9lcmxlc3MgYW5kIEkgd2lsbCBz aGFyZSB0aGUgcmVtYWluaW5nIHNlY3Rpb25zIGZvciBub3cuDQoNCkNhbiB0aGUgdm9sdW50ZWVy cyBwbGVhc2UgbGV0IG1lIGtub3cgYnkgd2hlbiB0aGV5IGNhbiBjb250cmlidXRlIHRoZWlyIHRl eHQ/ICBFaXRoZXIgaW4gZ2l0aHViIChsZXQgbWUga25vdyB5b3VyIElEIGlmIHlvdSB3YW50IHRv IGNvbnRyaWJ1dGUgdGhlcmUpDQoNCkdpdGh1YiBpcyBub3QgbWFuZGF0b3J5IC0gSWYgeW91IHdh bnQgdG8gc2VuZCBtZSB5b3VyIHRleHQgdmlhIG1haWwsIHRoYXQncyBvay4gSSdkIHN0cm9uZ2x5 IHByZWZlciBYTUwgZm9ybWF0dGVkIHNlY3Rpb25zIGlmIHBvc3NpYmxlIDstKQ0KDQpDYW4gd2Ug aGF2ZSBhbGwgdGV4dCBpbiBieSBXZWQgbmV4dCB3ZWVrPw0KDQpJIHBsYW4gdG8gY29uc29saWRh dGUgYW5kIHB1c2ggLTAzIGJ5IGVuZCBvZiBuZXh0IHdlZWsuDQoNCk1pY2hhZWwNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpBbmltYSBtYWlsaW5nIGxp c3QNCkFuaW1hQGlldGYub3JnPG1haWx0bzpBbmltYUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWENCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCkFuaW1hIG1haWxpbmcgbGlzdA0KQW5pbWFAaWV0Zi5v cmc8bWFpbHRvOkFuaW1hQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9hbmltYQ0KDQoNCg0KLS0NCnJlZ2FyZHMsDQpKb2huDQo= --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FEEAC8xmbrcdx14ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tR0I7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3 ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkFkZGVkITxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxmb250IHNpemU9IjIi IGZhY2U9IlRhaG9tYSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Zv bnQtd2VpZ2h0OmJvbGQiPkZyb206PC9zcGFuPjwvZm9udD48L2I+PGZvbnQgc2l6ZT0iMiIgZmFj ZT0iVGFob21hIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KIEpv aG4gU3RyYXNzbmVyIFttYWlsdG86c3RyYXpwZGpAZ21haWwuY29tXSA8YnI+DQo8Yj48c3BhbiBz dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U2VudDo8L3NwYW4+PC9iPiAxOCBKdW5lIDIwMTUgMDY6 NTc8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86PC9zcGFuPjwvYj4g TWljaGFlbCBCZWhyaW5nZXIgKG1iZWhyaW5nKTxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdl aWdodDpib2xkIj5DYzo8L3NwYW4+PC9iPiBKw6lmZXJzb24gQ2FtcG9zIE5vYnJlOyBBbmltYSBX RzsgZHJhZnQtYmVocmluZ2VyLWFuaW1hLXJlZmVyZW5jZS1tb2RlbEB0b29scy5pZXRmLm9yZzxi cj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0Ojwvc3Bhbj48L2I+ IFJlOiBbQW5pbWFdIFJlZmVyZW5jZSBkb2Mgb24gZ2l0aHViPG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXpl PSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPk15IGdpdGh1YiBJRCBpcyBzdHJhenppZTEyMzxvOnA+PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPk9uIFdlZCwgSnVuIDE3LCAyMDE1IGF0 IDEwOjAzIEFNLCBNaWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpICZsdDs8YSBocmVmPSJtYWls dG86bWJlaHJpbmdAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+bWJlaHJpbmdAY2lzY28uY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIg ZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PmRvbmUhIFRoYW5rcyBmb3IgdGhlIGNvbmZpcm1hdGlvbiE8L3NwYW4+PC9mb250PjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFm NDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCB3aW5kb3d0ZXh0IDEuNXB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNC4wcHQ7Ym9yZGVyLWNvbG9yOmN1cnJlbnRDb2xvciBjdXJyZW50Q29sb3IgY3Vy cmVudENvbG9yIGJsdWUiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtO2JvcmRl ci1jb2xvcjpjdXJyZW50Q29sb3IgY3VycmVudENvbG9yIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PGI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iVGFob21hIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Zm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTo8L3NwYW4+PC9mb250Pjwv Yj48Zm9udCBzaXplPSIyIiBmYWNlPSJUYWhvbWEiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+DQogSsOpZmVyc29uIENhbXBvcyBOb2JyZSBbbWFpbHRvOjxhIGhyZWY9 Im1haWx0bzpqY25vYnJlQGluZi51ZnJncy5iciIgdGFyZ2V0PSJfYmxhbmsiPmpjbm9icmVAaW5m LnVmcmdzLmJyPC9hPl0NCjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5T ZW50Ojwvc3Bhbj48L2I+IDE3IEp1bmUgMjAxNSAxODoxOTxicj4NCjxiPjxzcGFuIHN0eWxlPSJm b250LXdlaWdodDpib2xkIj5Ubzo8L3NwYW4+PC9iPiBNaWNoYWVsIEJlaHJpbmdlciAobWJlaHJp bmcpOyBBbmltYSBXRzxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzo8 L3NwYW4+PC9iPiA8YSBocmVmPSJtYWlsdG86ZHJhZnQtYmVocmluZ2VyLWFuaW1hLXJlZmVyZW5j ZS1tb2RlbEB0b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KZHJhZnQtYmVocmluZ2Vy LWFuaW1hLXJlZmVyZW5jZS1tb2RlbEB0b29scy5pZXRmLm9yZzwvYT48YnI+DQo8Yj48c3BhbiBz dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDo8L3NwYW4+PC9iPiBSZTogW0FuaW1hXSBS ZWZlcmVuY2UgZG9jIG9uIGdpdGh1Yjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIzIiBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0O2JvcmRlci1jb2xvcjpjdXJyZW50Q29s b3IgY3VycmVudENvbG9yIGN1cnJlbnRDb2xvciByZ2IoMjA0LDIwNCwyMDQpIj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkhpIE1pY2hhZWwuPG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNp emU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQiPkNvdWxkIHlvdSBwbGVhc2UgYWRkIG1lIGluIHRoZSBnaXRodWIgcmVwPyBNeSBJRCBpcyBq Y25vYnJlPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+SSB0aGluayBXZWQgbmV4dCB3ZWVrIGlzIGEg cmVhc29uYWJsZSB0aW1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlRoYW5rcy48bzpwPjwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij5CZXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9 IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi PkrDqWZlcnNvbjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjMiIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+RW0gcXVhLCAxNyBkZSBqdW4gZGUgMjAxNSDDoHMgMDk6NDEs IE1pY2hhZWwgQmVocmluZ2VyIChtYmVocmluZykgJmx0OzxhIGhyZWY9Im1haWx0bzptYmVocmlu Z0BjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5tYmVocmluZ0BjaXNjby5jb208L2E+Jmd0Ow0K IGVzY3JldmV1OjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQ7Ym9yZGVyLWNvbG9yOmN1 cnJlbnRDb2xvciBjdXJyZW50Q29sb3IgY3VycmVudENvbG9yIHJnYigyMDQsMjA0LDIwNCkiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5JIGhhdmUgbm93IGFsc28gY3JlYXRl ZCBhIHJlcG9zaXRvcnkgaW4gZ2l0aHViOg0KPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL21i ZWhyaW5nL0FOSU1BLVJlZmVyZW5jZS1Nb2RlbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZ2l0 aHViLmNvbS9tYmVocmluZy9BTklNQS1SZWZlcmVuY2UtTW9kZWw8L2E+PGJyPg0KPGJyPg0KSSBz dWdnZXN0ZWQgaW5pdGlhbCBjb250cmlidXRpb25zLCBhcyBwZXIgYmVsb3cgbGlzdCAob3BlbiB0 byBtb3JlIHN1Z2dlc3Rpb25zIDstKTxicj4NCjxicj4NCi0gTWljaGFlbCBSaWNoYXJkc29uOiBz ZWN0aW9uIDMuMyAoY29uc3RyYWluZWQgbm9kZXMpPGJyPg0KLSBMaXViaW5nOiA0LjEgYW5kIDQu MiAoTmFtaW5nLCBhZGRyZXNzaW5nKTxicj4NCi0gQnJpYW4gQ2FycGVudGVyOiA0LjQgKHNpZ25h bGluZykuIENvdWxkIHlvdSBhbHNvIGNvdmVyIDQuNSAoaW50ZW50IGRpc3RyaWJ1dGlvbikgYW5k IDQuMyAoZGlzY292ZXJ5KT8gLSB2ZXJ5IHJlbGF0ZWQhITxicj4NCi0gSmFzb24gQ29sZW1hbjog U2VjdGlvbiA1LjEsIDUuMiwgNS40LCA1LjUgKFBLSSwgY2VydCwgc3ViIGFuZCBjcm9zcy1kb21h aW4pPGJyPg0KLSBKZWZlcnNvbiBOb2JyZTogNy4xLCA3LjIsIDcuMyAoTWFuYWdlbWVudCwgaW50 ZW50LCBhZ2dyZWdhdGVkIHJlcG9ydGluZyk8YnI+DQotIEpvaG4gU3RyYXNzbmVyOiA3LjQsIDcu NSwgNy42IChmZWVkYmFjayBsb29wcywgQVBJUyBhbmQgbW9kZWxzLik8YnI+DQotIExhdXJlbnQg Q2lhdmFnbGlhOiBTZWN0aW9ucyA4IGFuZCA5IChkbyB0aGV5IG5lZWQgYW4gdXBkYXRlPyk8YnI+ DQotIFRvZXJsZXNzIGFuZCBJIHdpbGwgc2hhcmUgdGhlIHJlbWFpbmluZyBzZWN0aW9ucyBmb3Ig bm93Ljxicj4NCjxicj4NCkNhbiB0aGUgdm9sdW50ZWVycyBwbGVhc2UgbGV0IG1lIGtub3cgYnkg d2hlbiB0aGV5IGNhbiBjb250cmlidXRlIHRoZWlyIHRleHQ/Jm5ic3A7IEVpdGhlciBpbiBnaXRo dWIgKGxldCBtZSBrbm93IHlvdXIgSUQgaWYgeW91IHdhbnQgdG8gY29udHJpYnV0ZSB0aGVyZSk8 YnI+DQo8YnI+DQpHaXRodWIgaXMgbm90IG1hbmRhdG9yeSAtIElmIHlvdSB3YW50IHRvIHNlbmQg bWUgeW91ciB0ZXh0IHZpYSBtYWlsLCB0aGF0J3Mgb2suIEknZCBzdHJvbmdseSBwcmVmZXIgWE1M IGZvcm1hdHRlZCBzZWN0aW9ucyBpZiBwb3NzaWJsZSA7LSk8YnI+DQo8YnI+DQpDYW4gd2UgaGF2 ZSBhbGwgdGV4dCBpbiBieSBXZWQgbmV4dCB3ZWVrPzxicj4NCjxicj4NCkkgcGxhbiB0byBjb25z b2xpZGF0ZSBhbmQgcHVzaCAtMDMgYnkgZW5kIG9mIG5leHQgd2Vlay48YnI+DQo8YnI+DQpNaWNo YWVsPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpBbmltYSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86QW5pbWFAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5BbmltYUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYTwvYT48bzpwPjwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGZvbnQg c2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpBbmltYSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86QW5pbWFAaWV0 Zi5vcmciPkFuaW1hQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWEiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u dD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxicj4NCjxi ciBjbGVhcj0iYWxsIj4NCjxicj4NCi0tIDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPnJlZ2FyZHMsPG86 cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQiPkpvaG48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FEEAC8xmbrcdx14ciscoc_-- From nobody Thu Jun 18 03:06:03 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABD61B310B for ; Thu, 18 Jun 2015 03:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRCFVVq41HeP for ; Thu, 18 Jun 2015 03:06:01 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C2D61A8869 for ; Thu, 18 Jun 2015 03:06:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3814; q=dns/txt; s=iport; t=1434621960; x=1435831560; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=HzTq9BmkNZzL9/lhdNXpTS/ntsMknJJ57OZB5JV43Xg=; b=KKV/rPzXF7J+Ohtf7tLZjX9Gxx0ZtlzgUXIlGHD/0x4ydCbabJmv0+c7 xPdyPOnOZH/kyZl026v1DcuVS2ZBNzevVZIiU3Lj6MQHXl9gUHheXeEzI cn1X9zvQWeWo+6BVVCPwoSGo2sKRiUF/nYjoY7h3ViPqVEUy2icRkn7KA s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C1BAC2loJV/5FdJa1cgxBUXwaDGLlwZgmBZYV4AhyBHDgUAQEBAQEBAYEKhCIBAQEEIxFDDgQCAQgRBAEBAwIGHQMCAgIwFAEGAQEFAwIEEwiIJw2uZpZEAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhiiSEVTgGgmIvgRQFjAaHagGEUogrQYNJkmYmgjyBPW+BRoECAQEB X-IronPort-AV: E=Sophos;i="5.13,638,1427760000"; d="scan'208";a="4542538" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-6.cisco.com with ESMTP; 18 Jun 2015 10:06:00 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t5IA60ZV021698 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 18 Jun 2015 10:06:00 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.179]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Thu, 18 Jun 2015 05:06:00 -0500 From: "Michael Behringer (mbehring)" To: Anima WG Thread-Topic: New Version Notification for draft-behringer-anima-autonomic-addressing-01.txt Thread-Index: AQHQqazmj+CnfAg61EOsqHb7/WnjTp2yBoOw Date: Thu, 18 Jun 2015 10:05:59 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FEEC1B@xmb-rcd-x14.cisco.com> References: <20150618095520.3486.12039.idtracker@ietfa.amsl.com> In-Reply-To: <20150618095520.3486.12039.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.132] 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-behringer-anima-autonomic-addressing-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 18 Jun 2015 10:06:03 -0000 QU5JTUEgV0csIA0KDQpJIHVwZGF0ZWQgdGhlIGFkZHJlc3NpbmcgZHJhZnQsIGFuZCBhZGRlZCBt b3JlIHN0cnVjdHVyZSB0byBpdCwgYWRkZWQgcmVxdWlyZW1lbnRzLCBmdW5kYW1lbnRhbCBjb25j ZXB0LiANCg0KUGxlYXNlIHJldmlldyB0aGUgZG9jdW1lbnQuIA0KDQpJbiBhIGZpcnN0IGluc3Rh bmNlLCBJJ2QgYmUgaW50ZXJlc3RlZCBpbiB0aGUgaWRlYSBvZiB0aGUgYmFzZSBzY2hlbWUsIHdo aWNoIGlzIHdoeSBJIGhhdmUgc2VwYXJhdGVkIHRoYXQgcGFydCBvdXQgaW4gdGhlIG5ldyB2ZXJz aW9uLiBUaGUgYmFzZSBzY2hlbWUgaXMgcHJldHR5IHNpbXBsZSBhbmQgbmFpbHMgZG93bjogDQot IHRoYXQgd2UgdXNlIFVMQSwgd2hlcmUgd2UgZW5jb2RlIHRoZSBkb21haW4gbmFtZS4gDQotIHRo YXQgdGhlcmUgc2hvdWxkIGJlIGEgInR5cGUiIGZpZWxkIHRvIGJlIGFibGUgdG8gc3VwcG9ydCBk aWZmZXJlbnQgd2F5cyBvZiBhZGRyZXNzaW5nIG5vZGVzIGluIGEgbmV0d29yay4gDQoNCldoYXQg ZG8geW91IHRoaW5rIGFib3V0IHRoaXM/IElzIHRoaXMgdGhlIHJpZ2h0IGRpcmVjdGlvbj8gDQoN ClRoZW4sIGluIHRoZSBkZXRhaWxzLCBJIHRoaW5rIHRoZXJlIGFyZSBtYW55IGNob2ljZXMsIHRo ZSBmaWVsZHMgY2FuIGJlIHZhcmlhYmx5IGxvbmcsIGV0Yy4gVG9lcmxlc3MgaGFkIHN1Z2dlc3Rl ZCBzb21lICJ2aXJ0dWFsaXphdGlvbiBiaXRzIiBhdCB0aGUgZW5kIG9mIHRoZSBhZGRyZXNzIHRv IGJlIGFibGUgdG8gYWRkcmVzcyBkaWZmZXJlbnQgVk1zIGZvciBleGFtcGxlIG9uIGFuIGF1dG9u b21pYyBub2RlLiAoTmV3IHNlY3Rpb24gNS4yLikgIFVuZG91YnRlZGx5IHdlJ2xsIGhhdmUgbG90 cyBvZiBkaXNjdXNzaW9uIGFuZCBpZGVhcyBmb3IgdGhlIHN1Yi1zY2hlbWVzLiANCg0KQnV0IGZp cnN0IG9mIGFsbCBJJ2QgbGlrZSBzb21lIGZlZWRiYWNrIG9uIHRoZSBiYXNlIHNjaGVtZSwgdG8g c2VlIHdoZXRoZXIgd2UncmUgb24gdGhlIHJpZ2h0IHRyYWNrLg0KIA0KRmVlZGJhY2sgcGxlYXNl ISANCg0KTWljaGFlbA0KDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmddDQo+IFNlbnQ6IDE4IEp1bmUgMjAxNSAxMTo1NQ0KPiBUbzogTWljaGFlbCBCZWhyaW5nZXIg KG1iZWhyaW5nKTsgTWljaGFlbCBCZWhyaW5nZXIgKG1iZWhyaW5nKQ0KPiBTdWJqZWN0OiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWJlaHJpbmdlci1hbmltYS1hdXRvbm9taWMt DQo+IGFkZHJlc3NpbmctMDEudHh0DQo+IA0KPiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy YWZ0LWJlaHJpbmdlci1hbmltYS1hdXRvbm9taWMtYWRkcmVzc2luZy0wMS50eHQNCj4gaGFzIGJl ZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBNaWNoYWVsIEguIEJlaHJpbmdlciBhbmQgcG9z dGVkIHRvIHRoZQ0KPiBJRVRGIHJlcG9zaXRvcnkuDQo+IA0KPiBOYW1lOgkJZHJhZnQtYmVocmlu Z2VyLWFuaW1hLWF1dG9ub21pYy1hZGRyZXNzaW5nDQo+IFJldmlzaW9uOgkwMQ0KPiBUaXRsZToJ CUFuIEF1dG9ub21pYyBJUHY2IEFkZHJlc3NpbmcgU2NoZW1lDQo+IERvY3VtZW50IGRhdGU6CTIw MTUtMDYtMTgNCj4gR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4gUGFnZXM6CQk4DQo+ IFVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtYmVocmluZ2VyLWFuaW1hLQ0KPiBhdXRvbm9taWMtYWRkcmVzc2luZy0wMS50eHQNCj4gU3Rh dHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJlaHJp bmdlci1hbmltYS0NCj4gYXV0b25vbWljLWFkZHJlc3NpbmcvDQo+IEh0bWxpemVkOiAgICAgICBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmVocmluZ2VyLWFuaW1hLWF1dG9ub21p Yy0NCj4gYWRkcmVzc2luZy0wMQ0KPiBEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5v cmcvcmZjZGlmZj91cmwyPWRyYWZ0LWJlaHJpbmdlci1hbmltYS0NCj4gYXV0b25vbWljLWFkZHJl c3NpbmctMDENCj4gDQo+IEFic3RyYWN0Og0KPiAgICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBh IGdlbmVyaWMgSVB2NiBhZGRyZXNzaW5nIHNjaGVtZSB3aGljaCBpcw0KPiAgICBzdWl0YWJsZSBm b3IgYXV0b25vbWljIG5vZGVzLCB3aGVyZSBub2RlIGFkZHJlc3NpbmcgbXVzdCBub3QgZGVwZW5k DQo+ICAgIG9uIGEgY2VudHJhbGx5IG1hbmFnZWQgc2NoZW1lLiAgSXQgYXNzdW1lcyBhIHVuaXF1 ZSBkb21haW4gbmFtZSBhbmQNCj4gICAgZGV2aWNlIG5hbWUsIGFuZCBhdXRvbWF0aWNhbGx5IGRl cml2ZXMgYSB1bmlxdWUgSVB2NiBhZGRyZXNzIGZyb20NCj4gICAgdGhvc2UuICBUaGUgc2NoZW1l IGFsbG93cyBmb3IgYSBmbGF0IGFkZHJlc3MgaGllcmFyY2h5IGFzIHdlbGwgYXMNCj4gICAgb3B0 aW9uYWxseSwgd2hlbiByZXF1aXJlZCwgdGhlIGRlZmluaXRpb24gb2Ygem9uZXMgd2hpY2ggYXJl DQo+ICAgIGFnZ3JlZ2F0YWJsZS4NCj4gDQo+IA0KPiANCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQg aXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+IHN1Ym1p c3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBh dCB0b29scy5pZXRmLm9yZy4NCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Thu Jun 18 18:34:17 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D89371A00C2 for ; Thu, 18 Jun 2015 18:34:15 -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 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 SCB0gFzq-ix2 for ; Thu, 18 Jun 2015 18:34:14 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4FCB1A00BF for ; Thu, 18 Jun 2015 18:34:13 -0700 (PDT) Received: by pacyx8 with SMTP id yx8so73391885pac.2 for ; Thu, 18 Jun 2015 18:34:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2LGsluVcufsW9ols9+kC9Q0vB9QXH66WU6fxHIAT7RQ=; b=D1Iafs35Ja2pOXUPLpVTPCwYI/gf3TrdhNXGB2tql3JO5LX6KoIvkIAriaRhSOC27S nmqzc1VEsX7UBNWrtS0G5D+RhxW0QxVE6/LCDGtCwESON/5K9r/A67ocaswRW5cFrLB/ 0Nnbh+ynsImT2yCKgynYDKn90IkejgrC4/s/heh9WQ+InrinfT5uzjLwK16qebUEgGsq E2Hosx3Ttu00n1ZVIRuVOxJUA+Bdep1udJeUyDhIFizuhzuxAecxCYeOFx47q5rXH5vP cFNgfkENL3W4ig+cWmt74q+BJiXIOs72LhOmhGQ/basKH05+2AgTtcoViPGWB2Hc+vBt ypVg== X-Received: by 10.66.255.67 with SMTP id ao3mr26342086pad.60.1434677653642; Thu, 18 Jun 2015 18:34:13 -0700 (PDT) Received: from ?IPv6:2406:e007:4c72:1:28cc:dc4c:9703:6781? ([2406:e007:4c72:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id cd10sm9355083pac.7.2015.06.18.18.34.10 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jun 2015 18:34:12 -0700 (PDT) Message-ID: <5583719A.4070100@gmail.com> Date: Fri, 19 Jun 2015 13:34:18 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Anima WG References: <20150619012637.B76E7180471@rfc-editor.org> In-Reply-To: <20150619012637.B76E7180471@rfc-editor.org> X-Forwarded-Message-Id: <20150619012637.B76E7180471@rfc-editor.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Fwd: RFC 7575 on Autonomic Networking: Definitions and Design Goals X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 19 Jun 2015 01:34:16 -0000 -------- Forwarded Message -------- Subject: RFC 7575 on Autonomic Networking: Definitions and Design Goals Date: Thu, 18 Jun 2015 18:26:37 -0700 (PDT) From: rfc-editor@rfc-editor.org Reply-To: ietf@ietf.org To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org, irtf-announce@irtf.org CC: drafts-update-ref@iana.org, nmrg@irtf.org, rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 7575 Title: Autonomic Networking: Definitions and Design Goals Author: M. Behringer, M. Pritikin, S. Bjarnason, A. Clemm, B. Carpenter, S. Jiang, L. Ciavaglia Status: Informational Stream: IRTF Date: June 2015 Mailbox: mbehring@cisco.com, pritikin@cisco.com, sbjarnas@cisco.com, alex@cisco.com, brian.e.carpenter@gmail.com, jiangsheng@huawei.com, Laurent.Ciavaglia@alcatel-lucent.com Pages: 16 Characters: 36838 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-irtf-nmrg-autonomic-network-definitions-07.txt URL: https://www.rfc-editor.org/info/rfc7575 DOI: http://dx.doi.org/10.17487/RFC7575 Autonomic systems were first described in 2001. The fundamental goal is self-management, including self-configuration, self-optimization, self-healing, and self-protection. This is achieved by an autonomic function having minimal dependencies on human administrators or centralized management systems. It usually implies distribution across network elements. This document defines common language and outlines design goals (and what are not design goals) for autonomic functions. A high-level reference model illustrates how functional elements in an Autonomic Network interact. This document is a product of the IRTF's Network Management Research Group. This document is a product of the Network Management Research Group of the IRTF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce, rfc-dist and IRTF-Announce lists.To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist https://www.irtf.org/mailman/listinfo/irtf-announce For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Jun 18 18:34:44 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5A21A0105 for ; Thu, 18 Jun 2015 18:34:43 -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 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 2tx4s_zeFXGZ for ; Thu, 18 Jun 2015 18:34:41 -0700 (PDT) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::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 5F4041A00C2 for ; Thu, 18 Jun 2015 18:34:41 -0700 (PDT) Received: by pdjm12 with SMTP id m12so78568135pdj.3 for ; Thu, 18 Jun 2015 18:34:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=puoRnCD9pFGM7Nf9DSVN+BleGojsP8Kh7BaGu942JXg=; b=xaPss26pVFmH5fqUF51S0mbgzYOug6kP+60k4xZEKMguQ95KFOsuMewi2jSLd7Bmkl t7+gu0903yfv+LWAxUeem1AUdxV1gk+654GOUtfG2zUYeyU0DcF9R+OqAPyfcLwI/X7l zxkWmt2g4EIeeAup5cS90/2CGikQqfrgTULRhElVXFx3PmwHR0cyJHcaA9e9JoWDIF3L Br4WDJtOek2HNQpx0HsYcaj2YGSMa11gYGkkWIUyYZs48eLdPFH1tg44x93lb83XZnol iad9dTn79saBMr39kTzbaZb85c2rL6WMNuzhTJuh/dmTh6/KT+d5qgkux9zijD9MLo4E hfsg== X-Received: by 10.66.163.69 with SMTP id yg5mr25967944pab.150.1434677681111; Thu, 18 Jun 2015 18:34:41 -0700 (PDT) Received: from ?IPv6:2406:e007:4c72:1:28cc:dc4c:9703:6781? ([2406:e007:4c72:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id tr3sm9262656pbc.75.2015.06.18.18.34.38 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jun 2015 18:34:40 -0700 (PDT) Message-ID: <558371B6.9020509@gmail.com> Date: Fri, 19 Jun 2015 13:34:46 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Anima WG References: <20150619012702.E663218046B@rfc-editor.org> In-Reply-To: <20150619012702.E663218046B@rfc-editor.org> X-Forwarded-Message-Id: <20150619012702.E663218046B@rfc-editor.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Fwd: RFC 7576 on General Gap Analysis for Autonomic Networking X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 19 Jun 2015 01:34:43 -0000 -------- Forwarded Message -------- Subject: RFC 7576 on General Gap Analysis for Autonomic Networking Date: Thu, 18 Jun 2015 18:27:02 -0700 (PDT) From: rfc-editor@rfc-editor.org Reply-To: ietf@ietf.org To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org, irtf-announce@irtf.org CC: nmrg@irtf.org, rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 7576 Title: General Gap Analysis for Autonomic Networking Author: S. Jiang, B. Carpenter, M. Behringer Status: Informational Stream: IRTF Date: June 2015 Mailbox: jiangsheng@huawei.com, brian.e.carpenter@gmail.com, mbehring@cisco.com Pages: 17 Characters: 42472 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-irtf-nmrg-an-gap-analysis-06.txt URL: https://www.rfc-editor.org/info/rfc7576 DOI: http://dx.doi.org/10.17487/RFC7576 This document provides a problem statement and general gap analysis for an IP-based Autonomic Network that is mainly based on distributed network devices. The document provides background by reviewing the current status of autonomic aspects of IP networks and the extent to which current network management depends on centralization and human administrators. Finally, the document outlines the general features that are missing from current network abilities and are needed in the ideal Autonomic Network concept. This document is a product of the IRTF's Network Management Research Group. This document is a product of the Network Management Research Group of the IRTF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce, rfc-dist and IRTF-Announce lists.To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist https://www.irtf.org/mailman/listinfo/irtf-announce For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Jun 18 18:50:18 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9AC1A1EF5 for ; Thu, 18 Jun 2015 18:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kdZ57Igx5aL for ; Thu, 18 Jun 2015 18:50:15 -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 37E011A1BAE for ; Thu, 18 Jun 2015 18:50:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXN94311; Fri, 19 Jun 2015 01:50:12 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 19 Jun 2015 02:50:12 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.186]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Fri, 19 Jun 2015 09:50:00 +0800 From: "Liubing (Leo)" To: "Michael Behringer (mbehring)" , Anima WG Thread-Topic: Reference doc on github Thread-Index: AdCo+dAvfC4NDb/zTJOIdvnhU/aAQgBN186g Date: Fri, 19 Jun 2015 01:50:00 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45A6797BFA@nkgeml506-mbx.china.huawei.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FEE3B8@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FEE3B8@xmb-rcd-x14.cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "draft-behringer-anima-reference-model@tools.ietf.org" Subject: Re: [Anima] Reference doc on github X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 19 Jun 2015 01:50:17 -0000 Hi Michael, My Github ID is: liubingpang > - Liubing: 4.1 and 4.2 (Naming, addressing) I'm thinking about naming recently, so I think I can provide some text by n= ext Wed. But for addressing, I don't have new stuff to add this time. But I'll check= the relevant text again to see whether we need revision. Best regards, Bing > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael > Behringer (mbehring) > Sent: Wednesday, June 17, 2015 8:42 PM > To: Anima WG > Cc: draft-behringer-anima-reference-model@tools.ietf.org > Subject: [Anima] Reference doc on github >=20 > I have now also created a repository in github: > https://github.com/mbehring/ANIMA-Reference-Model >=20 > I suggested initial contributions, as per below list (open to more > suggestions ;-) >=20 > - Michael Richardson: section 3.3 (constrained nodes) > - Liubing: 4.1 and 4.2 (Naming, addressing) > - Brian Carpenter: 4.4 (signaling). Could you also cover 4.5 (intent > distribution) and 4.3 (discovery)? - very related!! > - Jason Coleman: Section 5.1, 5.2, 5.4, 5.5 (PKI, cert, sub and cross-dom= ain) > - Jeferson Nobre: 7.1, 7.2, 7.3 (Management, intent, aggregated reporting= ) > - John Strassner: 7.4, 7.5, 7.6 (feedback loops, APIS and models.) > - Laurent Ciavaglia: Sections 8 and 9 (do they need an update?) > - Toerless and I will share the remaining sections for now. >=20 > Can the volunteers please let me know by when they can contribute their > text? Either in github (let me know your ID if you want to contribute th= ere) >=20 > Github is not mandatory - If you want to send me your text via mail, that= 's ok. > I'd strongly prefer XML formatted sections if possible ;-) >=20 > Can we have all text in by Wed next week? >=20 > I plan to consolidate and push -03 by end of next week. >=20 > Michael > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Thu Jun 18 19:33:39 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4211A905E for ; Thu, 18 Jun 2015 19:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yv_Z7qX-m6cX for ; Thu, 18 Jun 2015 19:33:37 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D5CC1A9050 for ; Thu, 18 Jun 2015 19:33:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=254; q=dns/txt; s=iport; t=1434681217; x=1435890817; h=date:from:to:subject:message-id:mime-version; bh=KUYyzuzkwYRTrKCgFRe2gU1nLMhfLQBbWKjz8X9BIfw=; b=Bfk4f+D9nn8++o79HyQ6gqystyxMo5lEjzCDntXn9QhhBGZQowTjbuK7 c8Pgjp/r/wsb0XbOUbCV8tZBRoJcBLDPu/0upla+H34lESLipyHiTDtm7 FPiUUQoK/JJ8vn4zJAicCcw6qkZYSl9CPRv9QV0oLwC8mOCUui/2ISZK3 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BJBAB/foNV/4ENJK1cgxBUvlkJgWaHNzgUAQEBAQEBAYEKhGM0RwMxBYkLDZ12pjQBAQEHAQEBAQEZBJBohBUFjHeGfYRUhncBgTWEC5JoJoQZHoJ5AQEB X-IronPort-AV: E=Sophos;i="5.13,642,1427760000"; d="scan'208";a="160921544" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jun 2015 02:33:36 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t5J2XaHQ026472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 19 Jun 2015 02:33:36 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 t5J2XZb4000690 for ; Thu, 18 Jun 2015 19:33:35 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t5J2XZ2C000689 for anima@ietf.org; Thu, 18 Jun 2015 19:33:35 -0700 Date: Thu, 18 Jun 2015 19:33:35 -0700 From: Toerless Eckert To: anima@ietf.org Message-ID: <20150619023335.GP27147@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] anima-bootstrap created X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 19 Jun 2015 02:33:38 -0000 Mailing list for anima-bootstrap has been created. Team members aresubscribed. If you wish to follow the work please feel free to subscribe. all pointers on the wiki: https://tools.ietf.org/wg/anima/trac/wiki/Bootstrap Thanks Sheng & Toerless From nobody Fri Jun 19 04:11:26 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757941A8957 for ; Fri, 19 Jun 2015 04:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-F5jMBTObjU for ; Fri, 19 Jun 2015 04:11:19 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 9575C1A8955 for ; Fri, 19 Jun 2015 04:11:18 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id C3FA761ECAD64; Fri, 19 Jun 2015 11:11:14 +0000 (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 t5JBBGts008857 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Jun 2015 13:11:16 +0200 Received: from [172.27.204.134] (135.239.27.39) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 19 Jun 2015 13:11:15 +0200 Message-ID: <5583F8D3.6070208@alcatel-lucent.com> Date: Fri, 19 Jun 2015 13:11:15 +0200 From: Laurent Ciavaglia Organization: Alcatel-Lucent Bell Labs France User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , Anima WG References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FEE3B8@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FEE3B8@xmb-rcd-x14.cisco.com> Content-Type: multipart/alternative; boundary="------------010200060008090809050207" X-Originating-IP: [135.239.27.39] Archived-At: Cc: "draft-behringer-anima-reference-model@tools.ietf.org" Subject: Re: [Anima] Reference doc on github X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 19 Jun 2015 11:11:24 -0000 --------------010200060008090809050207 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Dear Michael, all, Section 8 is new, so I don't think it needs an upate for -03, but I would be happy to make changes based on feedback/comments. For Section 9: Is the current text referring to RFC7575, Section 3.2. Coexistence with Traditional Management? If yes, then I would suggest renaming Section 9 to reflect the actual content which focuses on "management or operation mode" prioritization. If agreed/correct, I can update the text for Section 9 by next Wednesday. Though, the topic of "hybrid" operations (autonomic and non-autonomic) is still relevant, but slightly different from prioritization. Some ongoing discussions on the ANIMA mailing list on domain, intent, and constrained nodes participate in this topic. A text on this in -03 is too ambitious, but we can trigger a discussion thread to capture the operating principles ANIMA aims at concerning this hybrid mode of operation (i.e. how AFs and non-AFs co-operate, are managed/governed by Intent/other means, role of "helping" nodes/functions/gateways...) Best regards, Laurent. On 17/06/2015 14:41, Michael Behringer (mbehring) wrote: > I have now also created a repository in github: https://github.com/mbehring/ANIMA-Reference-Model > > I suggested initial contributions, as per below list (open to more suggestions ;-) > > - Michael Richardson: section 3.3 (constrained nodes) > - Liubing: 4.1 and 4.2 (Naming, addressing) > - Brian Carpenter: 4.4 (signaling). Could you also cover 4.5 (intent distribution) and 4.3 (discovery)? - very related!! > - Jason Coleman: Section 5.1, 5.2, 5.4, 5.5 (PKI, cert, sub and cross-domain) > - Jeferson Nobre: 7.1, 7.2, 7.3 (Management, intent, aggregated reporting) > - John Strassner: 7.4, 7.5, 7.6 (feedback loops, APIS and models.) > - Laurent Ciavaglia: Sections 8 and 9 (do they need an update?) > - Toerless and I will share the remaining sections for now. > > Can the volunteers please let me know by when they can contribute their text? Either in github (let me know your ID if you want to contribute there) > > Github is not mandatory - If you want to send me your text via mail, that's ok. I'd strongly prefer XML formatted sections if possible ;-) > > Can we have all text in by Wed next week? > > I plan to consolidate and push -03 by end of next week. > > Michael -- Bien cordialement, Best regards, *Laurent Ciavaglia* Secure Cloud Networking Bell Labs | Alcatel Lucent phone: +33 160 402 636 email: laurent.ciavaglia@alcatel-lucent.com linkedin: laurentciavaglia address: Route de Villejust | 91620 Nozay | France --------------010200060008090809050207 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit Dear Michael, all,

Section 8 is new, so I don't think it needs an upate for -03, but I would be happy to make changes based on feedback/comments.

For Section 9: Is the current text referring to RFC7575, Section 3.2. Coexistence with Traditional Management?
If yes, then I would suggest renaming Section 9 to reflect the actual content which focuses on "management or operation mode" prioritization.
If agreed/correct, I can update the text for Section 9 by next Wednesday.

Though, the topic of "hybrid" operations (autonomic and non-autonomic) is still relevant, but slightly different from prioritization. Some ongoing discussions on the ANIMA mailing list on domain, intent, and constrained nodes participate in this topic.
A text on this in -03 is too ambitious, but we can trigger a discussion thread to capture the operating principles ANIMA aims at concerning this hybrid mode of operation (i.e. how AFs and non-AFs co-operate, are managed/governed by Intent/other means, role of "helping" nodes/functions/gateways...)

Best regards, Laurent.


On 17/06/2015 14:41, Michael Behringer (mbehring) wrote:
I have now also created a repository in github: https://github.com/mbehring/ANIMA-Reference-Model

I suggested initial contributions, as per below list (open to more suggestions ;-) 

- Michael Richardson: section 3.3 (constrained nodes)
- Liubing: 4.1 and 4.2 (Naming, addressing)
- Brian Carpenter: 4.4 (signaling). Could you also cover 4.5 (intent distribution) and 4.3 (discovery)? - very related!!
- Jason Coleman: Section 5.1, 5.2, 5.4, 5.5 (PKI, cert, sub and cross-domain)
- Jeferson Nobre: 7.1, 7.2, 7.3 (Management, intent, aggregated reporting)
- John Strassner: 7.4, 7.5, 7.6 (feedback loops, APIS and models.)
- Laurent Ciavaglia: Sections 8 and 9 (do they need an update?)
- Toerless and I will share the remaining sections for now.

Can the volunteers please let me know by when they can contribute their text?  Either in github (let me know your ID if you want to contribute there) 

Github is not mandatory - If you want to send me your text via mail, that's ok. I'd strongly prefer XML formatted sections if possible ;-) 

Can we have all text in by Wed next week? 

I plan to consolidate and push -03 by end of next week. 

Michael

--

Bien cordialement, Best regards,

 

Laurent Ciavaglia

Secure Cloud Networking

Bell Labs | Alcatel Lucent

 

phone: +33 160 402 636

email: laurent.ciavaglia@alcatel-lucent.com

linkedin: laurentciavaglia

address: Route de Villejust | 91620 Nozay | France

--------------010200060008090809050207-- From nobody Fri Jun 19 09:36:48 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C26B71A9236 for ; Fri, 19 Jun 2015 09:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4UC_JBf-0Rz for ; Fri, 19 Jun 2015 09:36:46 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F4201AC410 for ; Fri, 19 Jun 2015 09:36:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2606; q=dns/txt; s=iport; t=1434731806; x=1435941406; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KIL4ZUVVgjokg+FJhMNlb+mydpO/1FCOuhrdFiNrk1k=; b=mzmLSa4+dSLHaElvjd/SeXaFG2p8fHyZX7F8bkngc9GiH64ZEp+wGfTe +pTExWAokBaj/ArY1agdeXvF+eEh9TWUpQ1nmpJuerwWgEfXuElcUUeye TvvJ2Bl6M03Wpt7M6Qa83XkNzWmp25LZB1OKldIK/2eCnm/bq2zfkxXjB A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BLBADERIRV/5FdJa1cgxBUXwa9FWYJgVwKhXgCgT04FAEBAQEBAQGBCoQiAQEBAwEBAQE3NAsMBAIBCBEEAQELFAkHJwsUCQgBAQQBDQUIiB8IDcYTAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLRYQ0AQEfMQcGgxGBFAWRIYJbAYRViDKEC4pphCWDWyaDeW+BAwcCFyOBAgEBAQ X-IronPort-AV: E=Sophos;i="5.13,644,1427760000"; d="scan'208";a="161117840" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jun 2015 16:36:44 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t5JGaiEj025005 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Jun 2015 16:36:44 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.179]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Fri, 19 Jun 2015 11:36:44 -0500 From: "Michael Behringer (mbehring)" To: "Liubing (Leo)" , Anima WG Thread-Topic: Reference doc on github Thread-Index: AdCo+dAvfC4NDb/zTJOIdvnhU/aAQgBN186gAB8uMLA= Date: Fri, 19 Jun 2015 16:36:43 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0385@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FEE3B8@xmb-rcd-x14.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F45A6797BFA@nkgeml506-mbx.china.huawei.com> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45A6797BFA@nkgeml506-mbx.china.huawei.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-behringer-anima-reference-model@tools.ietf.org" Subject: Re: [Anima] Reference doc on github X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 19 Jun 2015 16:36:47 -0000 > -----Original Message----- > From: Liubing (Leo) [mailto:leo.liubing@huawei.com] > Sent: 19 June 2015 03:50 > To: Michael Behringer (mbehring); Anima WG > Cc: draft-behringer-anima-reference-model@tools.ietf.org > Subject: RE: Reference doc on github >=20 > Hi Michael, >=20 > My Github ID is: liubingpang added. =20 > > - Liubing: 4.1 and 4.2 (Naming, addressing) > I'm thinking about naming recently, so I think I can provide some text by > next Wed. > But for addressing, I don't have new stuff to add this time. But I'll che= ck the > relevant text again to see whether we need revision. Had some exchange with Sheng; I think I'll merge the current addressing doc= partly into the reference model, and partly into the ACP draft, so I take = the edit token on that one for now.=20 Michael >=20 > Best regards, > Bing >=20 > > -----Original Message----- > > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael > > Behringer (mbehring) > > Sent: Wednesday, June 17, 2015 8:42 PM > > To: Anima WG > > Cc: draft-behringer-anima-reference-model@tools.ietf.org > > Subject: [Anima] Reference doc on github > > > > I have now also created a repository in github: > > https://github.com/mbehring/ANIMA-Reference-Model > > > > I suggested initial contributions, as per below list (open to more > > suggestions ;-) > > > > - Michael Richardson: section 3.3 (constrained nodes) > > - Liubing: 4.1 and 4.2 (Naming, addressing) > > - Brian Carpenter: 4.4 (signaling). Could you also cover 4.5 (intent > > distribution) and 4.3 (discovery)? - very related!! > > - Jason Coleman: Section 5.1, 5.2, 5.4, 5.5 (PKI, cert, sub and > > cross-domain) > > - Jeferson Nobre: 7.1, 7.2, 7.3 (Management, intent, aggregated > > reporting) > > - John Strassner: 7.4, 7.5, 7.6 (feedback loops, APIS and models.) > > - Laurent Ciavaglia: Sections 8 and 9 (do they need an update?) > > - Toerless and I will share the remaining sections for now. > > > > Can the volunteers please let me know by when they can contribute > > their text? Either in github (let me know your ID if you want to > > contribute there) > > > > Github is not mandatory - If you want to send me your text via mail, th= at's > ok. > > I'd strongly prefer XML formatted sections if possible ;-) > > > > Can we have all text in by Wed next week? > > > > I plan to consolidate and push -03 by end of next week. > > > > Michael > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima From nobody Fri Jun 19 09:39:17 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739BF1AC422 for ; Fri, 19 Jun 2015 09:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPXgTgWgtM-o for ; Fri, 19 Jun 2015 09:39:13 -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 12CD61AC424 for ; Fri, 19 Jun 2015 09:39:09 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id B12A220012 for ; Fri, 19 Jun 2015 12:54:00 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 782A163B10; Fri, 19 Jun 2015 12:39:07 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 5CC7263AEC for ; Fri, 19 Jun 2015 12:39:07 -0400 (EDT) From: Michael Richardson To: Anima WG In-Reply-To: <5583719A.4070100@gmail.com> References: <20150619012637.B76E7180471@rfc-editor.org> <5583719A.4070100@gmail.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Anima] Fwd: RFC 7575 on Autonomic Networking: Definitions and Design Goals X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 19 Jun 2015 16:39:15 -0000 --=-=-= Content-Type: text/plain >>>>> rfc-editor writes: Brian E Carpenter wrote: > RFC 7575 "seventy-five seventy-five" has a nice ring to it. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVYRFqICLcPvd0N1lAQIgMgf+OcWFUY02piGI6V0/u0W6kJMuZsrsQpPG +fdofXR0J3abDGRudJqU89PVfqTQ0ID6ZVgzBH1n65K3zJ61p1hFpG+yVLQXZRg1 Aiwp1YoElzEq7YVWipvnqPkXHi36/FxVhA1/aziXVfEy3MN3UEvtl357uzfTkm/4 uAsWYDbdLAqsH8PoDd5rdhRXCJRYIwmRfZC72b71uuTHCzJJm0xGjstXCSP4N+6p oQql7abF7H6vC/+NGY3PVo6prsmClCyma9yjU24Tl35VS7BkRt2TNyxfbENkeD9t HxX7aCMUl7Nccl6JLlEPSn4w1aKNhKOaQbAoO6xq5vcOFE7R116bMg== =UCaj -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Jun 20 21:52:53 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7C41A0076 for ; Sat, 20 Jun 2015 21:52:52 -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 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 PcGz4dDDJ-YL for ; Sat, 20 Jun 2015 21:52:50 -0700 (PDT) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::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 C65E31A007B for ; Sat, 20 Jun 2015 21:52:50 -0700 (PDT) Received: by pdjn11 with SMTP id n11so116825042pdj.0 for ; Sat, 20 Jun 2015 21:52:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=PjxDkh9hdCM1q1Vv5OS3PJTTxgW+Uo+Q1zQm66gsh6U=; b=X5r64xBOJqmvhdpCDJCKNIqHAlxtqYWgfFdjY2JiFtKbQkIbpPiDL4T+T3aixGQRq7 dCFxgtVn1F7bTmARX4QzZDxkLtXRUf4Gjs5iw6Rc5ysmqTM/cAMU39lrPOKkMI0X74IZ XMO5Bz6jhwlGgMrriYl7MlIPDMFTULslNhs7iry1ltCaHwwv0lK2jNAvpYxHnIuHRTLR G19AenaC9hhWgUZMicObX/G8oN3iylGDIH8b0fF2izlMvNag/Aqe7zoSyW0YpUyHPLUF BFqNh2cnEXMhQ4IzGEtz8PJAyqgRYNwXUuzqANdLxm41NJMOjzTLpO/xNPKu8gfqhSE/ JrQQ== X-Received: by 10.68.107.97 with SMTP id hb1mr46765181pbb.143.1434862370556; Sat, 20 Jun 2015 21:52:50 -0700 (PDT) Received: from ?IPv6:2406:e007:79cc:1:28cc:dc4c:9703:6781? ([2406:e007:79cc:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id oa3sm15677897pbb.23.2015.06.20.21.52.48 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 20 Jun 2015 21:52:49 -0700 (PDT) Message-ID: <5586431F.2090202@gmail.com> Date: Sun, 21 Jun 2015 16:52:47 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Anima WG References: <20150621043842.7597.57574.idtracker@ietfa.amsl.com> In-Reply-To: <20150621043842.7597.57574.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150621043842.7597.57574.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Fwd: I-D Action: draft-carpenter-anima-gdn-protocol-04.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2015 04:52:52 -0000 Hi, This version reflects discussions in the signaling design team, but it still isn't a consensus of the design team. We'll try to get one more version out before Prague if possible. The requirements and open issues have been brought up to date; the actual protocol hasn't changed much except for adding a flooding mode. We still have one big open issue to discuss in Prague: whether to stay with binary TLVs or to change to a JSON/CBOR object-oriented design. Regards Brian -------- Forwarded Message -------- Subject: I-D Action: draft-carpenter-anima-gdn-protocol-04.txt Date: Sat, 20 Jun 2015 21:38:42 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Generic Discovery and Negotiation Protocol for Autonomic Networking Authors : Brian Carpenter Bing Liu Filename : draft-carpenter-anima-gdn-protocol-04.txt Pages : 46 Date : 2015-06-20 Abstract: This document establishes requirements for a signaling protocol that enables autonomic devices and autonomic service agents to dynamically discover peers, to synchronize state with them, and to negotiate parameter settings mutually with them. The document then defines a general protocol for discovery, synchronization and negotiation, while the technical objectives for specific scenarios are to be described in separate documents. An Appendix briefly discusses existing protocols with comparable features. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-carpenter-anima-gdn-protocol/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-carpenter-anima-gdn-protocol-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-carpenter-anima-gdn-protocol-04 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Sun Jun 21 10:28:17 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A83B71B2A76 for ; Sun, 21 Jun 2015 10:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.601 X-Spam-Level: *** X-Spam-Status: No, score=3.601 tagged_above=-999 required=5 tests=[BAYES_99=3.5, BAYES_999=0.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 zeKznXLQsPan for ; Sun, 21 Jun 2015 10:28:14 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::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 6D7DF1A038B for ; Sun, 21 Jun 2015 10:28:14 -0700 (PDT) Received: by wgfq1 with SMTP id q1so77530240wgf.1 for ; Sun, 21 Jun 2015 10:28:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=H/0ILU51g4WqWQ4+DUxFHaoDH8U0aK75gZucuElEEbU=; b=q6q597FEEcwUAm/BvRWwJrh465BeeOvBjrIooaDSO0qSlxiwCwtW8LqCC3s/Xi7TN/ j5N8Ai/iJPqPY4KX9yvYpNdqD9dg1VS7Ddmhr2vp13A4+2U+yVEKj9lW0aLWHegADaHZ 9x9wya/5CAG9z7eVYApRG8Bqrf1Gi54pWN97FkVujQvdUMKILcctUe0eH8npECkuyxlE E37vAt9OD3+vISmaO0Gp5So5EGSt+bak8bdCnW/rSW9TxTxfyaabjcm8sXKoKN4TSLkg kJNzZ767D/tRS37/fkxCzSSU1ll31nm9wHWOaH+eDCVOJzPBYX00KRDN1dUDCIZu17DO we0Q== MIME-Version: 1.0 X-Received: by 10.194.58.109 with SMTP id p13mr35213854wjq.36.1434907693082; Sun, 21 Jun 2015 10:28:13 -0700 (PDT) Received: by 10.27.220.1 with HTTP; Sun, 21 Jun 2015 10:28:13 -0700 (PDT) Date: Sun, 21 Jun 2015 10:28:13 -0700 Message-ID: From: John Strassner To: Anima WG Content-Type: multipart/alternative; boundary=047d7ba977ae54ef0905190a7b6b Archived-At: Subject: [Anima] Questions on RFC7575 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2015 17:28:16 -0000 --047d7ba977ae54ef0905190a7b6b Content-Type: text/plain; charset=UTF-8 I started reviewing both the reference model as well as other pertinent documents, so that when I write my sections for the reference model, they are consistent. :-) In doing so, I have a number of questions on RFC7575. Part of this may be my academic nature, part may be because I have undoubtedly missed something in past emails as I come up to speed, and partly because I'm likely under-caffeinated. Hopefully, some of this will help improve the reference model (and possibly other documents as well). Questions on RFC7575 Page 3 "Autonomic functions can be defined in two ways: o On a node level: Nodes interact with each other to form feedback loops. o On a system level: Feedback loops include central elements as well." What is a "central element"? Does this mean that the feedback loop includes centralized management mechanisms, or that there is additional logic outside of just the nodes? Page 5, definition of intent Why is intent scoped to a single autonomic domain? Page 5, definition of autonomic domain Why is autonomic domain tied to intent as the only management paradigm? The vast majority of work in autonomic networking does NOT use intent (what I call declarative logic, I failed marketing :-) ). I completely agree with using intent, and perhaps even emphasizing it, but I don't agree with excluding other management paradigms. Page 5, self-management "They configure themselves, based on self-knowledge, discovery, and Intent." The word "discovery" is confusing me. Suppose a node runs a utility function to decide what its next configuration change should be. It is not "discovering" something that existed - rather, it is computing new knowledge. A machine learning function that infers new knowledge is an even better example of something that is not "discovered". I'm probably missing something, but why was this choice made? The thing that really bothers me is that this assumes that all knowledge can be discovered - that is, it is existing, like an apple on a tree, ready to be plucked. In the autonomic systems that I've built, this is only sometimes the case. It is vital for an autonomic system to be able to learn new knowledge via computation and inference, as well as decide that previous knowledge was incorrect. Neither of these are discovery functions. Page 6, last paragraph above section 3.2 "...closed-loop control is an important aspect of self-managing systems. This implies peer-to-peer dialogues between the parties that make up the closed loop. Such dialogues require two-way "discussion" or "negotiation" between each pair or groups of peers involved in the loop,..." First, by "peer", I assume you mean two (or more) equipotent entities that make some portion of their resources available to others. Second, and more importantly, a closed control loop does not require each entity in the closed control loop to talk to negotiate with other entities. Now, in an autonomic control loop, this could very well be the case, but it is unclear to me why it MUST be the case. The obvious nightmare scenario is that the negotiation fails. Then what - we have no control loop at all? Pages 7-8, Section 3.6 Most autonomic networking systems to date have NOT been built with an intent (or declarative) style interface. FOCALE enables declarative and prescriptive (e.g., ECA policy rules) to be used. Others just use ECA (or an equivalent) paradigm. Hence, I'm wondering why intent is the ONLY paradigm that is mentioned in this RFC that is suitable for autonomic networking? Shouldn't we try and peacefully coexist, just as the nodes are peacefully coexisting with non-autonomic directives? Page 9, section 3.7 "However, in an Autonomic Network, reporting should happen on a network-wide basis." True, but shouldn't individual nodes and collections of nodes still report? That isn't implied in the wording. Furthermore, the last paragraph says: "Autonomic network events should concern the Autonomic Network as a whole, not individual systems in isolation." I agree that the goal is to report on the system as a whole, but isn't such a report collected from individual nodes? Just like in your example, the nodes need to be able to see that a problem has already been reported in order to know not to issue the same problem. Pages 12-13, section 5 Why is an Autonomic **User** Agent the interface to a control loop? I can see an external entity wanting to configure and monitor the control loop, but why wouldn't the User Agent talk to the Service Agent to do this? I do note that this figure is under discussion and being revised in the reference model. Page 13, Figure 1 Where is the Autonomic Node in the Reference Model? I do note that this figure is under discussion and being revised in the reference model. However, even in Figure 2 of the reference model, it is still unclear what the "node" is. But more on that later. -- regards, John --047d7ba977ae54ef0905190a7b6b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I started reviewing both the reference model as well = as other pertinent documents, so that when I write my sections for the refe= rence model, they are consistent. :-)

In doing so,= I have a number of questions on RFC7575. Part of this may be my academic n= ature, part may be because I have undoubtedly missed something in past emai= ls as I come up to speed, and partly because I'm likely under-caffeinat= ed. Hopefully, some of this will help improve the reference model (and poss= ibly other documents as well).

Questions on RFC757= 5
Page 3
"Autonomic functions can be defined in two ways:
=C2= =A0 o On a node level: Nodes interact with each other to form feedback
= =C2=A0=C2=A0=C2=A0 loops.
=C2=A0 o On a system level: Feedback loops inc= lude central elements as
=C2=A0=C2=A0=C2=A0 well."
What is a &qu= ot;central element"? Does this mean that the feedback loop includes ce= ntralized management mechanisms, or that there is additional logic outside = of just the nodes?

Page 5, definition of intentWhy is intent scoped to a single autonomic domain?

Page 5, definition of autonomic domain
Why is autonomic domain tied to= intent as the only management paradigm? The vast majority of work in auton= omic networking does NOT use intent (what I call declarative logic, I faile= d marketing :-) ). I completely agree with using intent, and perhaps even e= mphasizing it, but I don't agree with excluding other management paradi= gms.

Page 5, self-management
"They configu= re themselves, based on self-knowledge, discovery, and Intent."
The= word "discovery" is confusing me. Suppose a node runs a utility = function to decide what its next configuration change should be. It is not = "discovering" something that existed - rather, it is computing ne= w knowledge. A machine learning function that infers new knowledge is an ev= en better example of something that is not "discovered". I'm = probably missing something, but why was this choice made?
The thi= ng that really bothers me is that this assumes that all knowledge can be di= scovered - that is, it is existing, like an apple on a tree, ready to be pl= ucked. In the autonomic systems that I've built, this is only sometimes= the case. It is vital for an autonomic system to be able to learn new know= ledge via computation and inference, as well as decide that previous knowle= dge was incorrect. Neither of these are discovery functions.

=
Page 6, last paragraph above section 3.2
"...closed-loop= control is an important aspect of self-managing systems.
This i= mplies peer-to-peer dialogues between the parties that make up
t= he closed loop. Such dialogues require two-way "discussion" or &q= uot;negotiation"
between each pair or groups of peers invol= ved in the loop,..."
First, by "peer", I assume you mean = two (or more) equipotent entities that make some portion of their resources= available to others. Second, and more importantly, a closed control loop d= oes not require each entity in the closed control loop to talk to negotiate= with other entities. Now, in an autonomic control loop, this could very we= ll be the case, but it is unclear to me why it MUST be the case. The obviou= s nightmare scenario is that the negotiation fails. Then what - we have no = control loop at all?

Pages 7-8, Section 3.6
Mos= t autonomic networking systems to date have NOT been built with an intent (= or declarative) style interface. FOCALE enables declarative and prescriptiv= e (e.g., ECA policy rules) to be used. Others just use ECA (or an equivalen= t) paradigm. Hence, I'm wondering why intent is the ONLY paradigm that = is mentioned in this RFC that is suitable for autonomic networking? Shouldn= 't we try and peacefully coexist, just as the nodes are peacefully coex= isting with non-autonomic directives?

Page 9, sect= ion 3.7
"However, in an Autonomic Network, reporting should happen = on a network-wide basis."
True, but shouldn't individual= nodes and collections of nodes still report? That isn't implied in the= wording.
Furthermore, the last paragraph says: "Autonomic n= etwork events should concern the Autonomic Network as a whole, not individu= al systems in isolation." I agree that the goal is to report on the sy= stem as a whole, but isn't such a report collected from individual node= s? Just like in your example, the nodes need to be able to see that a probl= em has already been reported in order to know not to issue the same problem= .

Pages 12-13, section 5
Why is an Autonomic **= User** Agent the interface to a control loop? I can see an external entity = wanting to configure and monitor the control loop, but why wouldn't the= User Agent talk to the Service Agent to do this? I do note that this figur= e is under discussion and being revised in the reference model.
<= br>
Page 13, Figure 1
Where is the Autonomic Node in the Refer= ence Model? I do note that this figure is under discussion and being revise= d in the reference model. However, even in Figure 2 of the reference model,= it is still unclear what the "node" is. But more on that later.<= br>

--
r= egards,
John

On Wed, Jun 17, 2015 at 10:03 AM, Michael = Behringer (mbehring) <mbehring@cisco.com> wrote:

= done! Thanks for the confirmation!

= =C2=A0

From: J=C3=A9ferson Campos Nobre [mailto:jcnobre@inf.ufrgs.br]
Sent: 17 June 2015 18:19
To: Michael Behringer (mbehr= ing); Anima WG
Cc: draft-beh= ringer-anima-reference-model@tools.ietf.org
Subject: Re: [Anima] Referen= ce doc on github

=C2=A0

Hi Michael.

Could you please add me in the github rep? My ID is jc= nobre

I think Wed next week is a reasonable time.<= /u>

Thanks.

Best.

J=C3=A9ferson

=C2=A0

Em qua, 17 de jun de 2015 =C3=A0s 09:41, Michael Behri= nger (mbehring) <mbehring@cisco.com> escreveu:

I have now also created a repository in github: https://github.com/mbehring/ANIMA-Reference-Model

I suggested initial contributions, as per below list (open to more suggesti= ons ;-)

- Michael Richardson: section 3.3 (constrained nodes)
- Liubing: 4.1 and 4.2 (Naming, addressing)
- Brian Carpenter: 4.4 (signaling). Could you also cover 4.5 (intent distri= bution) and 4.3 (discovery)? - very related!!
- Jason Coleman: Section 5.1, 5.2, 5.4, 5.5 (PKI, cert, sub and cross-domai= n)
- Jeferson Nobre: 7.1, 7.2, 7.3 (Management, intent, aggregated reporting)<= br> - John Strassner: 7.4, 7.5, 7.6 (feedback loops, APIS and models.)
- Laurent Ciavaglia: Sections 8 and 9 (do they need an update?)
- Toerless and I will share the remaining sections for now.

Can the volunteers please let me know by when they can contribute their tex= t?=C2=A0 Either in github (let me know your ID if you want to contribute th= ere)

Github is not mandatory - If you want to send me your text via mail, that&#= 39;s ok. I'd strongly prefer XML formatted sections if possible ;-)

Can we have all text in by Wed next week?

I plan to consolidate and push -03 by end of next week.

Michael
_______________________________________________
Anima mailing list
Anima@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/anima<= /p>


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




--
regards,
John
--047d7ba977ae54ef0905190a7b6b-- From nobody Sun Jun 21 19:08:48 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6292A1A882E for ; Sun, 21 Jun 2015 19:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0J_80rUIePPA for ; Sun, 21 Jun 2015 19:08:45 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::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 CDEDB1A882D for ; Sun, 21 Jun 2015 19:08:45 -0700 (PDT) Received: by pabvl15 with SMTP id vl15so77135288pab.1 for ; Sun, 21 Jun 2015 19:08:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=AFz8aCgJS6NLnYqsdhl9H32SYhSII2Mw0Kl0I5mgbWM=; b=aTxSRnIrD8dxF5qjJLZcWPUhKb5aE/lomIuUdibR2GRHySJ0QZYJc3x5Vfvn1xPjd0 bYgyrmjbUJ/rHzLzIjI2w1PhAHKzHN0DVbwIoDQ/+TK9tDDUEi/FEtw2t0R7Mx/y0eae F04GpHh+sYJXvle2XOHCZ0/5eMbfAjlnbz+fJlotyZeGbd7iaAvQP6BFRp5LifkLpDed I3nVaws97/wt7TlKNtlaYqpg6KA0ph+K4JCtOqAw07SWsP1sfwMUYU2tVuFNBtNQ+8qh da77v3lRxdJXl/p2OnCXxZr09HzWoln69xevlP17CUS0sP+xgUdkF7yIGW2zJIa9aeJC rFhQ== X-Received: by 10.70.127.202 with SMTP id ni10mr53432364pdb.41.1434938925394; Sun, 21 Jun 2015 19:08:45 -0700 (PDT) Received: from [172.19.58.141] ([131.203.112.141]) by mx.google.com with ESMTPSA id go5sm17866309pbd.36.2015.06.21.19.08.42 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 21 Jun 2015 19:08:43 -0700 (PDT) Message-ID: <55876E20.2070508@gmail.com> Date: Mon, 22 Jun 2015 14:08:32 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Anima WG References: <20150618095520.3486.7068.idtracker@ietfa.amsl.com> In-Reply-To: <20150618095520.3486.7068.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-behringer-anima-autonomic-addressing-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jun 2015 02:08:47 -0000 Hi Michael, Sitting waiting for a flight... > IPv6 only: Autonomic processes should use exclusively IPv6, for > simplicity reasons. I agree with this as long as it's an RFC 2119 SHOULD, i.e. IPv4 could be used in extraordinary circumstances. The GDNP design is fundamentally IP-version independent. > Separation: Autonomic address space is used separately from user > address space and other address realms. This supports the robustness > requirement. That applies to all AN traffic *using routable addresses*. However, some autonomic signaling will require to be sent directly using link local addresses, especially link local multicast addresses, during discovery and bootstrap actions. > Loopback-only: Only loopback interfaces ... I know I'm repeating myself, but it really would be clearer if you said this the other way round, and I don't think it affects what you mean at all: Overlay network: Routeable addresses for AN nodes are used exclusively in a secure overlay network which is the basis of the ACP. This means that these addresses will be assigned to the loopback interface in most operating systems. All other interfaces exclusively use IPv6 link local for autonomic functions. The usage of IPv6 link local addressing is discussed in [RFC7404]. Use-ULA: For these overlay addresses of autonomic nodes, we use Unique Local Addresses (ULA), as specified in [RFC4193]. An alternative scheme was discussed, using assigned ULA addressing. The consensus was to use standard ULA, because it was deemed to be sufficient. Brian From nobody Mon Jun 22 08:46:55 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22CF31B2FB4 for ; Mon, 22 Jun 2015 08:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.81 X-Spam-Level: X-Spam-Status: No, score=-11.81 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dGK4uuKClPM for ; Mon, 22 Jun 2015 08:46:49 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 071C71A007A for ; Mon, 22 Jun 2015 08:46:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=56266; q=dns/txt; s=iport; t=1434988009; x=1436197609; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=dZWrNMmXdhMvfGi8oO4MXdK05iicZysOKFpXqDNBD50=; b=cKHdTcth2T4NI8C+m7iBHSCkdFs1Hua5HmHO5VcIkBeGV6Pscl8E6d2d cbfFZJ5oIaaF+O94MhtdbebbkJN/hZBaksHvb65e3/FrRGoaGdcWxfH9a +Lhc3VUvsW2EXQ1akKsCx4s27X+ilg6OQ8J/4iwgm2o9ylDhOWu82ILPx Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A4BQCOLYhV/5hdJa1cgkVLVF8Ggxi6B4hNAhyBHDsRAQEBAQEBAYEKhCIBAQEEIwpAAhoCAQgOAwQBAQsWAQYDAgICMBQJCAIEARIIiCe0M5YMAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tFgT2DGDcBBoJiL4EUBZN9AYcshVuTHINbJoN5b4FGgQIBAQE X-IronPort-AV: E=Sophos;i="5.13,660,1427760000"; d="scan'208,217";a="161737744" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-6.cisco.com with ESMTP; 22 Jun 2015 15:46:47 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t5MFklZP010235 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Jun 2015 15:46:47 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.179]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Mon, 22 Jun 2015 10:46:47 -0500 From: "Michael Behringer (mbehring)" To: John Strassner , Anima WG Thread-Topic: [Anima] Questions on RFC7575 Thread-Index: AQHQrEesFqw6Ify300iTXQ4+kek8/J24oWbg Date: Mon, 22 Jun 2015 15:46:46 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0F36@xmb-rcd-x14.cisco.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.134] Content-Type: multipart/alternative; boundary="_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0F36xmbrcdx14ciscoc_" MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Questions on RFC7575 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jun 2015 15:46:53 -0000 --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0F36xmbrcdx14ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9obiwgbGV0IG1lIHRha2UgYSBzdGFiIGF0IHJlc3BvbmRpbmfigKYgQW5kIHRoYW5rcyBm b3Igc2hhcmluZyB5b3VyIHRob3VnaHRzLiBBIGJpdCBsYXRlIHRvIGJyaW5nIHRoZW0gaW50byBS RkM3NTc1LCBidXQgYSBnb29kIHRpbWluZyBmb3IgdGhlIHJlZmVyZW5jZSBtb2RlbC4NCg0KRnJv bTogQW5pbWEgW21haWx0bzphbmltYS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSm9o biBTdHJhc3NuZXINClNlbnQ6IDIxIEp1bmUgMjAxNSAxOToyOA0KVG86IEFuaW1hIFdHDQpTdWJq ZWN0OiBbQW5pbWFdIFF1ZXN0aW9ucyBvbiBSRkM3NTc1DQoNCkkgc3RhcnRlZCByZXZpZXdpbmcg Ym90aCB0aGUgcmVmZXJlbmNlIG1vZGVsIGFzIHdlbGwgYXMgb3RoZXIgcGVydGluZW50IGRvY3Vt ZW50cywgc28gdGhhdCB3aGVuIEkgd3JpdGUgbXkgc2VjdGlvbnMgZm9yIHRoZSByZWZlcmVuY2Ug bW9kZWwsIHRoZXkgYXJlIGNvbnNpc3RlbnQuIDotKQ0KDQpJbiBkb2luZyBzbywgSSBoYXZlIGEg bnVtYmVyIG9mIHF1ZXN0aW9ucyBvbiBSRkM3NTc1LiBQYXJ0IG9mIHRoaXMgbWF5IGJlIG15IGFj YWRlbWljIG5hdHVyZSwgcGFydCBtYXkgYmUgYmVjYXVzZSBJIGhhdmUgdW5kb3VidGVkbHkgbWlz c2VkIHNvbWV0aGluZyBpbiBwYXN0IGVtYWlscyBhcyBJIGNvbWUgdXAgdG8gc3BlZWQsIGFuZCBw YXJ0bHkgYmVjYXVzZSBJJ20gbGlrZWx5IHVuZGVyLWNhZmZlaW5hdGVkLiBIb3BlZnVsbHksIHNv bWUgb2YgdGhpcyB3aWxsIGhlbHAgaW1wcm92ZSB0aGUgcmVmZXJlbmNlIG1vZGVsIChhbmQgcG9z c2libHkgb3RoZXIgZG9jdW1lbnRzIGFzIHdlbGwpLg0KDQpRdWVzdGlvbnMgb24gUkZDNzU3NQ0K UGFnZSAzDQoiQXV0b25vbWljIGZ1bmN0aW9ucyBjYW4gYmUgZGVmaW5lZCBpbiB0d28gd2F5czoN CiAgbyBPbiBhIG5vZGUgbGV2ZWw6IE5vZGVzIGludGVyYWN0IHdpdGggZWFjaCBvdGhlciB0byBm b3JtIGZlZWRiYWNrDQogICAgbG9vcHMuDQogIG8gT24gYSBzeXN0ZW0gbGV2ZWw6IEZlZWRiYWNr IGxvb3BzIGluY2x1ZGUgY2VudHJhbCBlbGVtZW50cyBhcw0KICAgIHdlbGwuIg0KV2hhdCBpcyBh ICJjZW50cmFsIGVsZW1lbnQiPyBEb2VzIHRoaXMgbWVhbiB0aGF0IHRoZSBmZWVkYmFjayBsb29w IGluY2x1ZGVzIGNlbnRyYWxpemVkIG1hbmFnZW1lbnQgbWVjaGFuaXNtcywgb3IgdGhhdCB0aGVy ZSBpcyBhZGRpdGlvbmFsIGxvZ2ljIG91dHNpZGUgb2YganVzdCB0aGUgbm9kZXM/DQoNCk1COiBB IGNlbnRyYWwgZWxlbWVudCBpcyBhIGNvbnRyb2xsZXIgZm9yIGV4YW1wbGUuIFRoZSBwb2ludCBv ZiB0aGUgc2VjdGlvbiBpczogWW91IGNvdWxkIGRlZmluZSBhbiDigJxhdXRvbm9taWMgbmV0d29y a+KAnSB3aGVyZSBldmVyeSBub2RlIGhhcyBleGFjdGx5IHRoZSBzYW1lIGludGVyZmFjZXMgYXMg dG9kYXkgKHByaW1hcmlseSBDTEksIFNOTVAsIE5FVENPTkYpLCBhbmQgd2hlcmUgYSBjb250cm9s bGVyIGlzIGludm9sdmVkIGluIGFsbCBjb250cm9sIGxvb3BzLiBPdXIgZGVmaW5pdGlvbiBvZiDi gJxhdXRvbm9taWPigJ0gaXMgZnVydGhlciBkb3duIGluIHRoZSBuZXR3b3JrLCB3aGVyZSBub2Rl cyBpbnRlcmFjdCBkaXJlY3RseSB3aXRoIG5vZGVzLiBOb3cgd2UgYWxsIHVuZGVyc3RhbmQgdGhp cyBpc27igJl0IGJsYWNrIGFuZCB3aGl0ZSwgYnV0IHRoZSBlbXBoYXNpcyBvZiB0aGUgd29yayBp biB0aGUgSUVURiBzaG91bGQgYmUgbm9kZS10by1ub2RlIGludGVyYWN0aW9ucy4NCg0KUGFnZSA1 LCBkZWZpbml0aW9uIG9mIGludGVudA0KV2h5IGlzIGludGVudCBzY29wZWQgdG8gYSBzaW5nbGUg YXV0b25vbWljIGRvbWFpbj8NCg0KTUI6IEludGVudCBpc27igJl0IGEgcG9saWN5IGxhbmd1YWdl IGxpa2UgbW9zdCBvdGhlciwgd2hlcmUgeW91IGNhbiBlc3NlbnRpYWxseSBkZWZpbmUgYSBwb2xp Y3kgZm9yIGV2ZXJ5IG5ldHdvcmsgZWxlbWVudCBzZXBhcmF0ZWx5LiBUaGUgZnVuZGFtZW50YWwg aWRlYSBpcyB0aGF0IHRoZXJlIGlzIG9uZSBpbnRlbnQgZm9yIHRoZSBlbnRpcmUgbmV0d29yay4g VGh1cyB0aGlzIGRlZmluaXRpb24uDQpNeSBwZXJzb25hbCBvcGluaW9uOiBJZiB3ZSBsZXQgSW50 ZW50IHNsaXAgaW50byB0aGUgZWxlbWVudCBtYW5hZ2VtZW50IHNjb3BlLCB3ZeKAmXZlIG1pc3Nl ZCBhbiBvcHBvcnR1bml0eS4gSW50ZW50IGlzIGEgcG9saWN5IG9uIG5ldHdvcmsgc2NvcGUuDQoN ClBhZ2UgNSwgZGVmaW5pdGlvbiBvZiBhdXRvbm9taWMgZG9tYWluDQpXaHkgaXMgYXV0b25vbWlj IGRvbWFpbiB0aWVkIHRvIGludGVudCBhcyB0aGUgb25seSBtYW5hZ2VtZW50IHBhcmFkaWdtPyBU aGUgdmFzdCBtYWpvcml0eSBvZiB3b3JrIGluIGF1dG9ub21pYyBuZXR3b3JraW5nIGRvZXMgTk9U IHVzZSBpbnRlbnQgKHdoYXQgSSBjYWxsIGRlY2xhcmF0aXZlIGxvZ2ljLCBJIGZhaWxlZCBtYXJr ZXRpbmcgOi0pICkuIEkgY29tcGxldGVseSBhZ3JlZSB3aXRoIHVzaW5nIGludGVudCwgYW5kIHBl cmhhcHMgZXZlbiBlbXBoYXNpemluZyBpdCwgYnV0IEkgZG9uJ3QgYWdyZWUgd2l0aCBleGNsdWRp bmcgb3RoZXIgbWFuYWdlbWVudCBwYXJhZGlnbXMuDQoNCk1COiBQcm9iYWJseSBhIHF1ZXN0aW9u IG9mIHdvcmRpbmcuIEluIG15IHJlYWRpbmcgeW91IGhhdmUgMSkgYXV0b25vbWljIGRlZmF1bHQg YmVoYXZpb3VyIChjb3VsZCBhbHNvIGNhbGwgdGhpcyDigJxkZWZhdWx0IGludGVudOKAnSksIDIp IEludGVudCwgYW5kIDMpIHRyYWRpdGlvbmFsIG1hbmFnZW1lbnQgc2NoZW1lcywgc3VjaCBhcyBO RVRDT05GLCBTTk1QLCBDTEksIGV0Y+KApg0KU28gd2UgZG9u4oCZdCBleGNsdWRlIG90aGVyIG1h bmFnZW1lbnQgcGFyYWRpZ21zLCB0aGV5IGFyZSBoYW5kbGVzIGluIHNlY3Rpb24gMy4yLiBJcyB0 aGF0IHdoYXQgeW91IG1lYW4/DQooWW91IGNvdWxkIGFsc28gZGVmaW5lIGFuIGF1dG9ub21pYyBk b21haW4gYnkgdGhlIHpvbmUgb2YgdHJ1c3Qgb2YgdGhlIGNlcnRpZmljYXRlcy4pDQoNClBhZ2Ug NSwgc2VsZi1tYW5hZ2VtZW50DQoiVGhleSBjb25maWd1cmUgdGhlbXNlbHZlcywgYmFzZWQgb24g c2VsZi1rbm93bGVkZ2UsIGRpc2NvdmVyeSwgYW5kIEludGVudC4iDQpUaGUgd29yZCAiZGlzY292 ZXJ5IiBpcyBjb25mdXNpbmcgbWUuIFN1cHBvc2UgYSBub2RlIHJ1bnMgYSB1dGlsaXR5IGZ1bmN0 aW9uIHRvIGRlY2lkZSB3aGF0IGl0cyBuZXh0IGNvbmZpZ3VyYXRpb24gY2hhbmdlIHNob3VsZCBi ZS4gSXQgaXMgbm90ICJkaXNjb3ZlcmluZyIgc29tZXRoaW5nIHRoYXQgZXhpc3RlZCAtIHJhdGhl ciwgaXQgaXMgY29tcHV0aW5nIG5ldyBrbm93bGVkZ2UuIEEgbWFjaGluZSBsZWFybmluZyBmdW5j dGlvbiB0aGF0IGluZmVycyBuZXcga25vd2xlZGdlIGlzIGFuIGV2ZW4gYmV0dGVyIGV4YW1wbGUg b2Ygc29tZXRoaW5nIHRoYXQgaXMgbm90ICJkaXNjb3ZlcmVkIi4gSSdtIHByb2JhYmx5IG1pc3Np bmcgc29tZXRoaW5nLCBidXQgd2h5IHdhcyB0aGlzIGNob2ljZSBtYWRlPw0KVGhlIHRoaW5nIHRo YXQgcmVhbGx5IGJvdGhlcnMgbWUgaXMgdGhhdCB0aGlzIGFzc3VtZXMgdGhhdCBhbGwga25vd2xl ZGdlIGNhbiBiZSBkaXNjb3ZlcmVkIC0gdGhhdCBpcywgaXQgaXMgZXhpc3RpbmcsIGxpa2UgYW4g YXBwbGUgb24gYSB0cmVlLCByZWFkeSB0byBiZSBwbHVja2VkLiBJbiB0aGUgYXV0b25vbWljIHN5 c3RlbXMgdGhhdCBJJ3ZlIGJ1aWx0LCB0aGlzIGlzIG9ubHkgc29tZXRpbWVzIHRoZSBjYXNlLiBJ dCBpcyB2aXRhbCBmb3IgYW4gYXV0b25vbWljIHN5c3RlbSB0byBiZSBhYmxlIHRvIGxlYXJuIG5l dyBrbm93bGVkZ2UgdmlhIGNvbXB1dGF0aW9uIGFuZCBpbmZlcmVuY2UsIGFzIHdlbGwgYXMgZGVj aWRlIHRoYXQgcHJldmlvdXMga25vd2xlZGdlIHdhcyBpbmNvcnJlY3QuIE5laXRoZXIgb2YgdGhl c2UgYXJlIGRpc2NvdmVyeSBmdW5jdGlvbnMuDQoNCk1COiBJIHRoaW5rIHRoZSBjb25mdXNpb24g aXMgdGhlIGRlZmluaXRpb24gb2Yg4oCcZGlzY292ZXJ54oCdIGhlcmUuIEl04oCZcyBub3Qgb25s eSBkaXNjb3ZlcnkgaW4gdGhlIHNlbnNlIG9mIHNlcnZpY2UgZGlzY292ZXJ5LCBidXQgZm9yIGV4 YW1wbGUsIGZpbmRpbmcgbmVpZ2hib3JzLCBuZWdvdGlhdGluZyBwYXJhbWV0ZXJzIHdpdGggdGhl bSwgZXRjLg0KVGhlIGFib3ZlIHBocmFzZSBpbiBvdGhlciB3b3Jkczog4oCcSSBrbm93IG15IGNh cGFiaWxpdGllcywgSSBzZWUgd2hhdCBlbHNlIGlzIHRoZXJlIChhbmQgdGFsayB0byBpdCBwb3Rl bnRpYWxseSksIGFuZCBJIHNlZSB3aGF0IHRoZSBib3NzIHdhbnRzIHRvIGhhcHBlbiAoaW50ZW50 KS4gQmFzZWQgb24gYWxsIG9mIHRoaXMgSSBkZWNpZGUgd2hhdCBJ4oCZbSBnb2luZyB0byBkb+KA nS4NCkkgdGhpbmsgaXTigJlzIGEgcXVlc3Rpb24gb2Ygd29yZGluZy4gV2UgaGFkIHRoaXMgZ3Jh cGhpYyAoc2ltaWxhciB0byBmaWd1cmUgMSksIHdoZXJlIHRoZXJlIGFyZSB0aGUgMyBpbnB1dCB2 ZWN0b3JzICghKSBvZiBpbmZvcm1hdGlvbiwgb24gd2hpY2ggeW91IGJhc2UgeW91ciBkZWNpc2lv bnMuIFRoZSBpbmZlcmVuY2UgeW91IG1lbnRpb24gaXMgYSBjb25zZXF1ZW5jZSBvZiB0aG9zZSBp bnB1dHMuIEluIG90aGVyIHdvcmRzLCB0aGUg4oCcYnJhaW7igJ0gdGhhdCBhY3R1YWxseSBtYWtl cyB0aGUgaW5mZXJlbmNlLCBpcyBpbiBvdXIgbW9kZWwgdGhlIGF1dG9ub21pYyBzZXJ2aWNlIGFn ZW50Lg0KRG9lcyB0aGF0IG1ha2Ugc2Vuc2U/DQoNClBhZ2UgNiwgbGFzdCBwYXJhZ3JhcGggYWJv dmUgc2VjdGlvbiAzLjINCiIuLi5jbG9zZWQtbG9vcCBjb250cm9sIGlzIGFuIGltcG9ydGFudCBh c3BlY3Qgb2Ygc2VsZi1tYW5hZ2luZyBzeXN0ZW1zLg0KVGhpcyBpbXBsaWVzIHBlZXItdG8tcGVl ciBkaWFsb2d1ZXMgYmV0d2VlbiB0aGUgcGFydGllcyB0aGF0IG1ha2UgdXANCnRoZSBjbG9zZWQg bG9vcC4gU3VjaCBkaWFsb2d1ZXMgcmVxdWlyZSB0d28td2F5ICJkaXNjdXNzaW9uIiBvciAibmVn b3RpYXRpb24iDQpiZXR3ZWVuIGVhY2ggcGFpciBvciBncm91cHMgb2YgcGVlcnMgaW52b2x2ZWQg aW4gdGhlIGxvb3AsLi4uIg0KRmlyc3QsIGJ5ICJwZWVyIiwgSSBhc3N1bWUgeW91IG1lYW4gdHdv IChvciBtb3JlKSBlcXVpcG90ZW50IGVudGl0aWVzIHRoYXQgbWFrZSBzb21lIHBvcnRpb24gb2Yg dGhlaXIgcmVzb3VyY2VzIGF2YWlsYWJsZSB0byBvdGhlcnMuIFNlY29uZCwgYW5kIG1vcmUgaW1w b3J0YW50bHksIGEgY2xvc2VkIGNvbnRyb2wgbG9vcCBkb2VzIG5vdCByZXF1aXJlIGVhY2ggZW50 aXR5IGluIHRoZSBjbG9zZWQgY29udHJvbCBsb29wIHRvIHRhbGsgdG8gbmVnb3RpYXRlIHdpdGgg b3RoZXIgZW50aXRpZXMuIE5vdywgaW4gYW4gYXV0b25vbWljIGNvbnRyb2wgbG9vcCwgdGhpcyBj b3VsZCB2ZXJ5IHdlbGwgYmUgdGhlIGNhc2UsIGJ1dCBpdCBpcyB1bmNsZWFyIHRvIG1lIHdoeSBp dCBNVVNUIGJlIHRoZSBjYXNlLiBUaGUgb2J2aW91cyBuaWdodG1hcmUgc2NlbmFyaW8gaXMgdGhh dCB0aGUgbmVnb3RpYXRpb24gZmFpbHMuIFRoZW4gd2hhdCAtIHdlIGhhdmUgbm8gY29udHJvbCBs b29wIGF0IGFsbD8NCg0KTUI6IEkgZ3Vlc3MgeW91ciBwb2ludCBpcyB0aGF0IGFuIGF1dG9ub21p YyBwcm9jZXNzIGRvZXNu4oCZdCBIQVZFIHRvIGhhdmUgYSBjb250cm9sIGxvb3AuIEkgd291bGQg YXJndWUgdGhhdCB0aGUgdHlwaWNhbCBhdXRvbm9taWMgZnVuY3Rpb24gRE9FUyBoYXZlIG5vZGUt dG8tbm9kZSBpbnRlcmFjdGlvbnMuIFRoaXMgaXMgd2hhdCBhdXRvbm9taWNzIGlzIGFsbCBhYm91 dC4gTm93LCB5ZXMsIHRoZXJlIHdpbGwgYmUgY2FzZXMgd2hlcmUgdGhpcyBmYWlscywgYW5kIHdo ZXJlIGEgbm9kZSBhbHNvIG5lZWRzIHRvIGRvIHNvbWV0aGluZyBzZW5zaWJsZSBpbiBjYXNlIG9m IGNvbXBsZXRlIGlzb2xhdGlvbi4gQnV0IHRoYXTigJlzIGFuIGV4Y2VwdGlvbiBzdGF0ZSBpbiBt eSBtaW5kLg0KDQpQYWdlcyA3LTgsIFNlY3Rpb24gMy42DQpNb3N0IGF1dG9ub21pYyBuZXR3b3Jr aW5nIHN5c3RlbXMgdG8gZGF0ZSBoYXZlIE5PVCBiZWVuIGJ1aWx0IHdpdGggYW4gaW50ZW50IChv ciBkZWNsYXJhdGl2ZSkgc3R5bGUgaW50ZXJmYWNlLiBGT0NBTEUgZW5hYmxlcyBkZWNsYXJhdGl2 ZSBhbmQgcHJlc2NyaXB0aXZlIChlLmcuLCBFQ0EgcG9saWN5IHJ1bGVzKSB0byBiZSB1c2VkLiBP dGhlcnMganVzdCB1c2UgRUNBIChvciBhbiBlcXVpdmFsZW50KSBwYXJhZGlnbS4gSGVuY2UsIEkn bSB3b25kZXJpbmcgd2h5IGludGVudCBpcyB0aGUgT05MWSBwYXJhZGlnbSB0aGF0IGlzIG1lbnRp b25lZCBpbiB0aGlzIFJGQyB0aGF0IGlzIHN1aXRhYmxlIGZvciBhdXRvbm9taWMgbmV0d29ya2lu Zz8gU2hvdWxkbid0IHdlIHRyeSBhbmQgcGVhY2VmdWxseSBjb2V4aXN0LCBqdXN0IGFzIHRoZSBu b2RlcyBhcmUgcGVhY2VmdWxseSBjb2V4aXN0aW5nIHdpdGggbm9uLWF1dG9ub21pYyBkaXJlY3Rp dmVzPw0KDQpNQjogVG8gbWUsIEVDQSBpcyBlbmNvZGVkIGluIGFuIEFTQSBvciBhbiBhdXRvbm9t aWMgZnVuY3Rpb24uIFRoZSBmdW5jdGlvbiBzYXlzIHdoYXQgYWN0aW9uIHlvdSB0YWtlIGluIHNw ZWNpZmljIGV2ZW50cywgYW5kIHVuZGVyIHdoaWNoIGNvbmRpdGlvbi4NCkV4YW1wbGU6IFRoZSDi gJxlbnJvbG1lbnQgcHJveHkgQVNB4oCdIGhhcyB0aGUgZm9sbG93aW5nIChoYXJkIGNvZGVkKSBF U0E6DQoNCi0gICAgICAgICAgRXZlbnQ6IEEgbmV3IG5vZGUgaXMgZGV0ZWN0ZWQNCg0KLSAgICAg ICAgICBDb25kaXRpb246IGl0IGRvZXNu4oCZdCBoYXZlIGEgZG9tYWluIGNlcnQgeWV0DQoNCi0g ICAgICAgICAgQWN0aW9uOiBJIGludml0ZSB0aGUgbm9kZSB0byBqb2luIG15IG5ldHdvcmsuDQpO b3csIEludGVudCBpcyBpbiBteSBtaW5kIGEgaGlnaGVyIGxldmVsIGNvbmNlcHQgd2hpY2ggY291 bGQgbm93IHN0YXRlIOKAnGRvIG5vdCBlbnJvbCBuZXcgbm9kZXMgYXQgdGhpcyBtb21lbnTigJ0u DQpIb3cgd291bGQgeW91IHNlZSB0aGF0Pw0KDQpQYWdlIDksIHNlY3Rpb24gMy43DQoiSG93ZXZl ciwgaW4gYW4gQXV0b25vbWljIE5ldHdvcmssIHJlcG9ydGluZyBzaG91bGQgaGFwcGVuIG9uIGEg bmV0d29yay13aWRlIGJhc2lzLiINClRydWUsIGJ1dCBzaG91bGRuJ3QgaW5kaXZpZHVhbCBub2Rl cyBhbmQgY29sbGVjdGlvbnMgb2Ygbm9kZXMgc3RpbGwgcmVwb3J0PyBUaGF0IGlzbid0IGltcGxp ZWQgaW4gdGhlIHdvcmRpbmcuDQoNCk1COiBZZXMsIHRoZXkgc2hvdWxkLiBUaGlzIGlzIOKAnHRy YWRpdGlvbmFsIG1hbmFnZW1lbnQgbWV0aG9kc+KAnS4gSW4gb3VyIG1vZGVsLCBldmVyeSBub2Rl IGRvZXMgdGhlIG5vcm1hbCBzeXNsb2csIGV0Yy4sIGFuZCBhZ2dyZWdhdGVkIHJlcG9ydGluZyBp cyB0aGUgbmV3IHRoaW5nIHRoYXQgY29tZXMgd2l0aCBBTi4NCg0KRnVydGhlcm1vcmUsIHRoZSBs YXN0IHBhcmFncmFwaCBzYXlzOiAiQXV0b25vbWljIG5ldHdvcmsgZXZlbnRzIHNob3VsZCBjb25j ZXJuIHRoZSBBdXRvbm9taWMgTmV0d29yayBhcyBhIHdob2xlLCBub3QgaW5kaXZpZHVhbCBzeXN0 ZW1zIGluIGlzb2xhdGlvbi4iIEkgYWdyZWUgdGhhdCB0aGUgZ29hbCBpcyB0byByZXBvcnQgb24g dGhlIHN5c3RlbSBhcyBhIHdob2xlLCBidXQgaXNuJ3Qgc3VjaCBhIHJlcG9ydCBjb2xsZWN0ZWQg ZnJvbSBpbmRpdmlkdWFsIG5vZGVzPyBKdXN0IGxpa2UgaW4geW91ciBleGFtcGxlLCB0aGUgbm9k ZXMgbmVlZCB0byBiZSBhYmxlIHRvIHNlZSB0aGF0IGEgcHJvYmxlbSBoYXMgYWxyZWFkeSBiZWVu IHJlcG9ydGVkIGluIG9yZGVyIHRvIGtub3cgbm90IHRvIGlzc3VlIHRoZSBzYW1lIHByb2JsZW0u DQoNCk1COiBUaGVyZSBhcmUgdHdvIHBhcmFsbGVsIG1ldGhvZHMgb2YgcmVwb3J0aW5nOg0KDQox KSAgICAgIHRoZSB0cmFkaXRpb25hbCBldmVyeS1ub2RlLXRvLWNvbnRyb2xsZXIgbWV0aG9kLCB3 aGVyZSB0aGUgaW50ZWxsaWdlbmNlIGlzIGNlbnRyYWwNCg0KMikgICAgICBhIGRpc3RyaWJ1dGVk IHJlcG9ydGluZyBmdW5jdGlvbiwgd2hlcmUgbm9kZXMgYWdncmVnYXRlLCBwcm9jZXNzLCBzdW1t YXJpc2UsIGNvcnJlbGF0ZSwg4oCmICBpbmZvcm1hdGlvbiBiZWZvcmUgaGFuZGluZyBpdCB0byB0 aGUgY29udHJvbGxlci4gSGVyZSB0aGUgaW50ZWxsaWdlbmNlIGlzIGRpc3RyaWJ1dGVkLg0KQm90 aCB3aWxsIGNvLWV4aXN0LiBUaGUgUkZDIGZvY3VzZXMgb24gdGhlIG5ldyBtZXRob2QgKGFuZCBv YnZpb3VzbHkgaXNu4oCZdCBjbGVhciBlbm91Z2ggYWJvdXQgaXTigKYpDQoNClBhZ2VzIDEyLTEz LCBzZWN0aW9uIDUNCldoeSBpcyBhbiBBdXRvbm9taWMgKipVc2VyKiogQWdlbnQgdGhlIGludGVy ZmFjZSB0byBhIGNvbnRyb2wgbG9vcD8gSSBjYW4gc2VlIGFuIGV4dGVybmFsIGVudGl0eSB3YW50 aW5nIHRvIGNvbmZpZ3VyZSBhbmQgbW9uaXRvciB0aGUgY29udHJvbCBsb29wLCBidXQgd2h5IHdv dWxkbid0IHRoZSBVc2VyIEFnZW50IHRhbGsgdG8gdGhlIFNlcnZpY2UgQWdlbnQgdG8gZG8gdGhp cz8gSSBkbyBub3RlIHRoYXQgdGhpcyBmaWd1cmUgaXMgdW5kZXIgZGlzY3Vzc2lvbiBhbmQgYmVp bmcgcmV2aXNlZCBpbiB0aGUgcmVmZXJlbmNlIG1vZGVsLg0KDQpNQjogWWVzLCB0aGF04oCZcyBj b25mdXNpbmcgd29yZGluZywgYW5kIG5vdyB0aGF0IHlvdSBtZW50aW9uIGl0LCB5ZXMgd2Ugc2hv dWxkIGhhdmUgcHJvYmFibHkgbG9va2VkIGZvciBhIGJldHRlciB0ZXJtLiBUaGUgaWRlYSBpczog VGhlIOKAnGludGVsbGlnZW5jZeKAnSBvZiBhbiBhdXRvbm9taWMgZnVuY3Rpb24gaXMgaW4gdGhl IEFTQSAobWlkZGxlIG9mIGZpZ3VyZSAxKS4gVGhlcmUgYXJlIG5vdyBob3Jpem9udGFsIGZlZWRi YWNrIGxvb3BzIGFuZCBub3J0aGJvdW5kIGZlZWRiYWNrIGxvb3BzLiBGb3IgZXhhbXBsZSwgdGhl cmUgaXMgbGlrZWx5IGEgZnVuY3Rpb24gaW4gdGhlIGVucm9sbWVudCBwcm9jZXNzLCB3aGVyZSBh IG1lc3NhZ2UgZ2V0cyBzZW50IHRvIHRoZSBhZG1pbjog4oCcSGVyZeKAmXMgYSBuZXcgbm9kZSwg SSBkb27igJl0IHRoaW5rIGl0IGJlbG9uZ3MgaW50byBvdXIgbmV0d29yaywgSeKAmXZlIHF1YXJh bnRpbmVkIHRoYXQgbm9kZSBmb3Igbm93OyB3b3VsZCB5b3UgbGlrZSBtZSB0byAxKSBhY2NlcHQg dGhlIG5vZGUgYW55d2F5LCBvciAyKSBtYXJrIGl0IGFzIGJhZD/igJ0NCg0KSSBhZ3JlZSB0aGUg dGVybSDigJx1c2VyIGFnZW504oCdIGlzIG5vdCBnb29kLiBXZSBuZWVkIHRvIGZpbmQgYSBiZXR0 ZXIgb25lLiBTdWdnZXN0aW9ucz8NCg0KUGFnZSAxMywgRmlndXJlIDENCldoZXJlIGlzIHRoZSBB dXRvbm9taWMgTm9kZSBpbiB0aGUgUmVmZXJlbmNlIE1vZGVsPyBJIGRvIG5vdGUgdGhhdCB0aGlz IGZpZ3VyZSBpcyB1bmRlciBkaXNjdXNzaW9uIGFuZCBiZWluZyByZXZpc2VkIGluIHRoZSByZWZl cmVuY2UgbW9kZWwuIEhvd2V2ZXIsIGV2ZW4gaW4gRmlndXJlIDIgb2YgdGhlIHJlZmVyZW5jZSBt b2RlbCwgaXQgaXMgc3RpbGwgdW5jbGVhciB3aGF0IHRoZSAibm9kZSIgaXMuIEJ1dCBtb3JlIG9u IHRoYXQgbGF0ZXIuDQoNCk1COiBUaGUgd2hvbGUgdGhpbmcgaXMgdGhlIG5vZGUuIFRoYXTigJlz IHdoeSB0aGUgZmlndXJlIGlzIGNhbGxlZCDigJxSZWZlcmVuY2UgTW9kZWwgZm9yIGFuIEF1dG9u b21pYyBOb2Rl4oCdLg0KDQpUaGFua3MgZm9yIGFsbCB5b3VyIGlucHV0IEpvaG4hIExldOKAmXMg bWFrZSBzdXJlIHRoYXQgYWxsIHRoZXNlIHBvaW50cyBnZXQgYWRkcmVzc2VkIGluIHRoZSByZWZl cmVuY2UgbW9kZWwuDQoNCk1pY2hhZWwNCi0tDQpyZWdhcmRzLA0KSm9obg0K --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0F36xmbrcdx14ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQ YXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1h cmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0 Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBw dCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6Njg3ODcw NzQyOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMzMz MTEwNDIgNTQwMzMxOTA0IDEzNDgwNzU1NSAxMzQ4MDc1NTcgMTM0ODA3NTUzIDEzNDgwNzU1NSAx MzQ4MDc1NTcgMTM0ODA3NTUzIDEzNDgwNzU1NSAxMzQ4MDc1NTc7fQ0KQGxpc3QgbDA6bGV2ZWwx DQoJe21zby1sZXZlbC1zdGFydC1hdDo5MDE7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1mb250LWZhbWls eTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBs aXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg bDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7 bXNvLWxpc3QtaWQ6MTEyMzAzMzkyMTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlz dC10ZW1wbGF0ZS1pZHM6NTAxMjU0MDM2IDEzNDgwNzU2OSAxMzQ4MDc1NzcgMTM0ODA3NTc5IDEz NDgwNzU2NyAxMzQ4MDc1NzcgMTM0ODA3NTc5IDEzNDgwNzU2NyAxMzQ4MDc1NzcgMTM0ODA3NTc5 O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtdGV4dDoiJTFcKSI7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxl dmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQt aW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxv d2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBw dDt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3Qg bDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXtt YXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIg Y29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5IaSBKb2huLCBsZXQgbWUgdGFrZSBhIHN0YWIgYXQgcmVzcG9uZGlu Z+KApiBBbmQgdGhhbmtzIGZvciBzaGFyaW5nIHlvdXIgdGhvdWdodHMuIEEgYml0IGxhdGUgdG8g YnJpbmcgdGhlbSBpbnRvDQogUkZDNzU3NSwgYnV0IGEgZ29vZCB0aW1pbmcgZm9yIHRoZSByZWZl cmVuY2UgbW9kZWwuIDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxmb250IHNpemU9 IjIiIGZhY2U9IlRhaG9tYSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2ZvbnQtd2VpZ2h0OmJvbGQiPkZyb206PC9zcGFuPjwvZm9udD48L2I+PGZvbnQgc2l6ZT0iMiIg ZmFjZT0iVGFob21hIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0K IEFuaW1hIFttYWlsdG86YW5pbWEtYm91bmNlc0BpZXRmLm9yZ10gPGI+PHNwYW4gc3R5bGU9ImZv bnQtd2VpZ2h0OmJvbGQiPk9uIEJlaGFsZiBPZg0KPC9zcGFuPjwvYj5Kb2huIFN0cmFzc25lcjxi cj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TZW50Ojwvc3Bhbj48L2I+IDIx IEp1bmUgMjAxNSAxOToyODxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5U bzo8L3NwYW4+PC9iPiBBbmltYSBXRzxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi b2xkIj5TdWJqZWN0Ojwvc3Bhbj48L2I+IFtBbmltYV0gUXVlc3Rpb25zIG9uIFJGQzc1NzU8bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkkgc3RhcnRlZCBy ZXZpZXdpbmcgYm90aCB0aGUgcmVmZXJlbmNlIG1vZGVsIGFzIHdlbGwgYXMgb3RoZXIgcGVydGlu ZW50IGRvY3VtZW50cywgc28gdGhhdCB3aGVuIEkgd3JpdGUgbXkgc2VjdGlvbnMgZm9yIHRoZSBy ZWZlcmVuY2UgbW9kZWwsIHRoZXkgYXJlIGNvbnNpc3RlbnQuIDotKTxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBz aXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+SW4gZG9pbmcgc28sIEkgaGF2ZSBhIG51 bWJlciBvZiBxdWVzdGlvbnMgb24gUkZDNzU3NS4gUGFydCBvZiB0aGlzIG1heSBiZSBteSBhY2Fk ZW1pYyBuYXR1cmUsIHBhcnQgbWF5IGJlIGJlY2F1c2UgSSBoYXZlIHVuZG91YnRlZGx5IG1pc3Nl ZCBzb21ldGhpbmcgaW4gcGFzdCBlbWFpbHMgYXMNCiBJIGNvbWUgdXAgdG8gc3BlZWQsIGFuZCBw YXJ0bHkgYmVjYXVzZSBJJ20gbGlrZWx5IHVuZGVyLWNhZmZlaW5hdGVkLiBIb3BlZnVsbHksIHNv bWUgb2YgdGhpcyB3aWxsIGhlbHAgaW1wcm92ZSB0aGUgcmVmZXJlbmNlIG1vZGVsIChhbmQgcG9z c2libHkgb3RoZXIgZG9jdW1lbnRzIGFzIHdlbGwpLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+UXVlc3Rpb25zIG9uIFJGQzc1NzU8YnI+DQpQYWdlIDM8 YnI+DQomcXVvdDtBdXRvbm9taWMgZnVuY3Rpb25zIGNhbiBiZSBkZWZpbmVkIGluIHR3byB3YXlz Ojxicj4NCiZuYnNwOyBvIE9uIGEgbm9kZSBsZXZlbDogTm9kZXMgaW50ZXJhY3Qgd2l0aCBlYWNo IG90aGVyIHRvIGZvcm0gZmVlZGJhY2s8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgbG9vcHMuPGJy Pg0KJm5ic3A7IG8gT24gYSBzeXN0ZW0gbGV2ZWw6IEZlZWRiYWNrIGxvb3BzIGluY2x1ZGUgY2Vu dHJhbCBlbGVtZW50cyBhczxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyB3ZWxsLiZxdW90Ozxicj4N CldoYXQgaXMgYSAmcXVvdDtjZW50cmFsIGVsZW1lbnQmcXVvdDs/IERvZXMgdGhpcyBtZWFuIHRo YXQgdGhlIGZlZWRiYWNrIGxvb3AgaW5jbHVkZXMgY2VudHJhbGl6ZWQgbWFuYWdlbWVudCBtZWNo YW5pc21zLCBvciB0aGF0IHRoZXJlIGlzIGFkZGl0aW9uYWwgbG9naWMgb3V0c2lkZSBvZiBqdXN0 IHRoZSBub2Rlcz88bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29s b3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5NQjogQSBjZW50cmFsIGVsZW1lbnQgaXMgYSBjb250cm9sbGVyIGZvciBl eGFtcGxlLiBUaGUgcG9pbnQgb2YgdGhlIHNlY3Rpb24gaXM6IFlvdSBjb3VsZCBkZWZpbmUgYW4g 4oCcYXV0b25vbWljDQogbmV0d29ya+KAnSB3aGVyZSBldmVyeSBub2RlIGhhcyBleGFjdGx5IHRo ZSBzYW1lIGludGVyZmFjZXMgYXMgdG9kYXkgKHByaW1hcmlseSBDTEksIFNOTVAsIE5FVENPTkYp LCBhbmQgd2hlcmUgYSBjb250cm9sbGVyIGlzIGludm9sdmVkIGluIGFsbCBjb250cm9sIGxvb3Bz LiBPdXIgZGVmaW5pdGlvbiBvZiDigJxhdXRvbm9taWPigJ0gaXMgZnVydGhlciBkb3duIGluIHRo ZSBuZXR3b3JrLCB3aGVyZSBub2RlcyBpbnRlcmFjdCBkaXJlY3RseSB3aXRoIG5vZGVzLg0KIE5v dyB3ZSBhbGwgdW5kZXJzdGFuZCB0aGlzIGlzbuKAmXQgYmxhY2sgYW5kIHdoaXRlLCBidXQgdGhl IGVtcGhhc2lzIG9mIHRoZSB3b3JrIGluIHRoZSBJRVRGIHNob3VsZCBiZSBub2RlLXRvLW5vZGUg aW50ZXJhY3Rpb25zLg0KPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9u dCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0Ij5QYWdlIDUsIGRlZmluaXRpb24gb2YgaW50ZW50PGJyPg0KV2h5IGlzIGludGVudCBz Y29wZWQgdG8gYSBzaW5nbGUgYXV0b25vbWljIGRvbWFpbj88bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0i MyIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9m b250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0 OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+TUI6IEludGVudCBpc27igJl0IGEgcG9saWN5IGxhbmd1YWdlIGxpa2UgbW9zdCBvdGhl ciwgd2hlcmUgeW91IGNhbiBlc3NlbnRpYWxseSBkZWZpbmUgYSBwb2xpY3kgZm9yIGV2ZXJ5IG5l dHdvcmsNCiBlbGVtZW50IHNlcGFyYXRlbHkuIFRoZSBmdW5kYW1lbnRhbCBpZGVhIGlzIHRoYXQg dGhlcmUgaXMgb25lIGludGVudCBmb3IgdGhlIGVudGlyZSBuZXR3b3JrLiBUaHVzIHRoaXMgZGVm aW5pdGlvbi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk15IHBlcnNvbmFsIG9waW5pb246 IElmIHdlIGxldCBJbnRlbnQgc2xpcCBpbnRvIHRoZSBlbGVtZW50IG1hbmFnZW1lbnQgc2NvcGUs IHdl4oCZdmUgbWlzc2VkIGFuIG9wcG9ydHVuaXR5LiBJbnRlbnQNCiBpcyBhIHBvbGljeSBvbiBu ZXR3b3JrIHNjb3BlLiA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+UGFnZSA1LCBkZWZpbml0aW9uIG9mIGF1dG9ub21pYyBkb21haW48YnI+DQpX aHkgaXMgYXV0b25vbWljIGRvbWFpbiB0aWVkIHRvIGludGVudCBhcyB0aGUgb25seSBtYW5hZ2Vt ZW50IHBhcmFkaWdtPyBUaGUgdmFzdCBtYWpvcml0eSBvZiB3b3JrIGluIGF1dG9ub21pYyBuZXR3 b3JraW5nIGRvZXMgTk9UIHVzZSBpbnRlbnQgKHdoYXQgSSBjYWxsIGRlY2xhcmF0aXZlIGxvZ2lj LCBJIGZhaWxlZCBtYXJrZXRpbmcgOi0pICkuIEkgY29tcGxldGVseSBhZ3JlZSB3aXRoIHVzaW5n IGludGVudCwgYW5kIHBlcmhhcHMgZXZlbiBlbXBoYXNpemluZw0KIGl0LCBidXQgSSBkb24ndCBh Z3JlZSB3aXRoIGV4Y2x1ZGluZyBvdGhlciBtYW5hZ2VtZW50IHBhcmFkaWdtcy48bzpwPjwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGZvbnQgc2l6ZT0iMyIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIi IGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+TUI6IFByb2JhYmx5IGEgcXVlc3Rpb24gb2Ygd29yZGluZy4gSW4g bXkgcmVhZGluZyB5b3UgaGF2ZSAxKSBhdXRvbm9taWMgZGVmYXVsdCBiZWhhdmlvdXIgKGNvdWxk IGFsc28gY2FsbCB0aGlzDQog4oCcZGVmYXVsdCBpbnRlbnTigJ0pLCAyKSBJbnRlbnQsIGFuZCAz KSB0cmFkaXRpb25hbCBtYW5hZ2VtZW50IHNjaGVtZXMsIHN1Y2ggYXMgTkVUQ09ORiwgU05NUCwg Q0xJLCBldGPigKYmbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJy aSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNvIHdlIGRvbuKA mXQgZXhjbHVkZSBvdGhlciBtYW5hZ2VtZW50IHBhcmFkaWdtcywgdGhleSBhcmUgaGFuZGxlcyBp biBzZWN0aW9uIDMuMi4gSXMgdGhhdCB3aGF0IHlvdSBtZWFuPw0KPG86cD48L286cD48L3NwYW4+ PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIj MWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+KFlvdSBjb3VsZCBhbHNvIGRlZmluZSBhbiBhdXRvbm9taWMgZG9tYWluIGJ5IHRo ZSB6b25lIG9mIHRydXN0IG9mIHRoZSBjZXJ0aWZpY2F0ZXMuKQ0KPG86cD48L286cD48L3NwYW4+ PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIj MWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlBhZ2UgNSwgc2VsZi1tYW5hZ2Vt ZW50PGJyPg0KJnF1b3Q7VGhleSBjb25maWd1cmUgdGhlbXNlbHZlcywgYmFzZWQgb24gc2VsZi1r bm93bGVkZ2UsIGRpc2NvdmVyeSwgYW5kIEludGVudC4mcXVvdDs8YnI+DQpUaGUgd29yZCAmcXVv dDtkaXNjb3ZlcnkmcXVvdDsgaXMgY29uZnVzaW5nIG1lLiBTdXBwb3NlIGEgbm9kZSBydW5zIGEg dXRpbGl0eSBmdW5jdGlvbiB0byBkZWNpZGUgd2hhdCBpdHMgbmV4dCBjb25maWd1cmF0aW9uIGNo YW5nZSBzaG91bGQgYmUuIEl0IGlzIG5vdCAmcXVvdDtkaXNjb3ZlcmluZyZxdW90OyBzb21ldGhp bmcgdGhhdCBleGlzdGVkIC0gcmF0aGVyLCBpdCBpcyBjb21wdXRpbmcgbmV3IGtub3dsZWRnZS4g QSBtYWNoaW5lIGxlYXJuaW5nIGZ1bmN0aW9uIHRoYXQgaW5mZXJzDQogbmV3IGtub3dsZWRnZSBp cyBhbiBldmVuIGJldHRlciBleGFtcGxlIG9mIHNvbWV0aGluZyB0aGF0IGlzIG5vdCAmcXVvdDtk aXNjb3ZlcmVkJnF1b3Q7LiBJJ20gcHJvYmFibHkgbWlzc2luZyBzb21ldGhpbmcsIGJ1dCB3aHkg d2FzIHRoaXMgY2hvaWNlIG1hZGU/PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlRoZSB0aGluZyB0aGF0 IHJlYWxseSBib3RoZXJzIG1lIGlzIHRoYXQgdGhpcyBhc3N1bWVzIHRoYXQgYWxsIGtub3dsZWRn ZSBjYW4gYmUgZGlzY292ZXJlZCAtIHRoYXQgaXMsIGl0IGlzIGV4aXN0aW5nLCBsaWtlIGFuIGFw cGxlIG9uIGEgdHJlZSwgcmVhZHkgdG8gYmUgcGx1Y2tlZC4gSW4NCiB0aGUgYXV0b25vbWljIHN5 c3RlbXMgdGhhdCBJJ3ZlIGJ1aWx0LCB0aGlzIGlzIG9ubHkgc29tZXRpbWVzIHRoZSBjYXNlLiBJ dCBpcyB2aXRhbCBmb3IgYW4gYXV0b25vbWljIHN5c3RlbSB0byBiZSBhYmxlIHRvIGxlYXJuIG5l dyBrbm93bGVkZ2UgdmlhIGNvbXB1dGF0aW9uIGFuZCBpbmZlcmVuY2UsIGFzIHdlbGwgYXMgZGVj aWRlIHRoYXQgcHJldmlvdXMga25vd2xlZGdlIHdhcyBpbmNvcnJlY3QuIE5laXRoZXIgb2YgdGhl c2UgYXJlIGRpc2NvdmVyeQ0KIGZ1bmN0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZh Y2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NQjogSSB0aGluayB0aGUgY29uZnVzaW9u IGlzIHRoZSBkZWZpbml0aW9uIG9mIOKAnGRpc2NvdmVyeeKAnSBoZXJlLiBJdOKAmXMgbm90IG9u bHkgZGlzY292ZXJ5IGluIHRoZSBzZW5zZSBvZiBzZXJ2aWNlDQogZGlzY292ZXJ5LCBidXQgZm9y IGV4YW1wbGUsIGZpbmRpbmcgbmVpZ2hib3JzLCBuZWdvdGlhdGluZyBwYXJhbWV0ZXJzIHdpdGgg dGhlbSwgZXRjLg0KPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIGFib3ZlIHBocmFzZSBp biBvdGhlciB3b3Jkczog4oCcSSBrbm93IG15IGNhcGFiaWxpdGllcywgSSBzZWUgd2hhdCBlbHNl IGlzIHRoZXJlIChhbmQgdGFsayB0byBpdCBwb3RlbnRpYWxseSksDQogYW5kIEkgc2VlIHdoYXQg dGhlIGJvc3Mgd2FudHMgdG8gaGFwcGVuIChpbnRlbnQpLiBCYXNlZCBvbiBhbGwgb2YgdGhpcyBJ IGRlY2lkZSB3aGF0IEnigJltIGdvaW5nIHRvIGRv4oCdLg0KPG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0 OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SSB0aGluayBpdOKAmXMgYSBxdWVzdGlvbiBvZiB3b3JkaW5nLiBXZSBoYWQgdGhpcyBn cmFwaGljIChzaW1pbGFyIHRvIGZpZ3VyZSAxKSwgd2hlcmUgdGhlcmUgYXJlIHRoZSAzIGlucHV0 IHZlY3RvcnMNCiAoISkgb2YgaW5mb3JtYXRpb24sIG9uIHdoaWNoIHlvdSBiYXNlIHlvdXIgZGVj aXNpb25zLiBUaGUgaW5mZXJlbmNlIHlvdSBtZW50aW9uIGlzIGEgY29uc2VxdWVuY2Ugb2YgdGhv c2UgaW5wdXRzLiBJbiBvdGhlciB3b3JkcywgdGhlIOKAnGJyYWlu4oCdIHRoYXQgYWN0dWFsbHkg bWFrZXMgdGhlIGluZmVyZW5jZSwgaXMgaW4gb3VyIG1vZGVsIHRoZSBhdXRvbm9taWMgc2Vydmlj ZSBhZ2VudC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjojMUY0 OTdEIj5Eb2VzIHRoYXQgbWFrZSBzZW5zZT8NCjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFj ZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5QYWdlIDYsIGxhc3QgcGFyYWdyYXBoIGFib3ZlIHNl Y3Rpb24gMy4yPGJyPg0KJnF1b3Q7Li4uY2xvc2VkLWxvb3AgY29udHJvbCBpcyBhbiBpbXBvcnRh bnQgYXNwZWN0IG9mIHNlbGYtbWFuYWdpbmcgc3lzdGVtcy4gPG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9 IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi PlRoaXMgaW1wbGllcyBwZWVyLXRvLXBlZXIgZGlhbG9ndWVzIGJldHdlZW4gdGhlIHBhcnRpZXMg dGhhdCBtYWtlIHVwDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+dGhlIGNsb3NlZCBsb29wLiBTdWNo IGRpYWxvZ3VlcyByZXF1aXJlIHR3by13YXkgJnF1b3Q7ZGlzY3Vzc2lvbiZxdW90OyBvciAmcXVv dDtuZWdvdGlhdGlvbiZxdW90Ow0KPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPmJldHdlZW4gZWFjaCBw YWlyIG9yIGdyb3VwcyBvZiBwZWVycyBpbnZvbHZlZCBpbiB0aGUgbG9vcCwuLi4mcXVvdDs8YnI+ DQpGaXJzdCwgYnkgJnF1b3Q7cGVlciZxdW90OywgSSBhc3N1bWUgeW91IG1lYW4gdHdvIChvciBt b3JlKSBlcXVpcG90ZW50IGVudGl0aWVzIHRoYXQgbWFrZSBzb21lIHBvcnRpb24gb2YgdGhlaXIg cmVzb3VyY2VzIGF2YWlsYWJsZSB0byBvdGhlcnMuIFNlY29uZCwgYW5kIG1vcmUgaW1wb3J0YW50 bHksIGEgY2xvc2VkIGNvbnRyb2wgbG9vcCBkb2VzIG5vdCByZXF1aXJlIGVhY2ggZW50aXR5IGlu IHRoZSBjbG9zZWQgY29udHJvbCBsb29wIHRvIHRhbGsgdG8gbmVnb3RpYXRlDQogd2l0aCBvdGhl ciBlbnRpdGllcy4gTm93LCBpbiBhbiBhdXRvbm9taWMgY29udHJvbCBsb29wLCB0aGlzIGNvdWxk IHZlcnkgd2VsbCBiZSB0aGUgY2FzZSwgYnV0IGl0IGlzIHVuY2xlYXIgdG8gbWUgd2h5IGl0IE1V U1QgYmUgdGhlIGNhc2UuIFRoZSBvYnZpb3VzIG5pZ2h0bWFyZSBzY2VuYXJpbyBpcyB0aGF0IHRo ZSBuZWdvdGlhdGlvbiBmYWlscy4gVGhlbiB3aGF0IC0gd2UgaGF2ZSBubyBjb250cm9sIGxvb3Ag YXQgYWxsPzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NQjogSSBndWVzcyB5b3VyIHBvaW50 IGlzIHRoYXQgYW4gYXV0b25vbWljIHByb2Nlc3MgZG9lc27igJl0IEhBVkUgdG8gaGF2ZSBhIGNv bnRyb2wgbG9vcC4gSSB3b3VsZCBhcmd1ZSB0aGF0IHRoZQ0KIHR5cGljYWwgYXV0b25vbWljIGZ1 bmN0aW9uIERPRVMgaGF2ZSBub2RlLXRvLW5vZGUgaW50ZXJhY3Rpb25zLiBUaGlzIGlzIHdoYXQg YXV0b25vbWljcyBpcyBhbGwgYWJvdXQuIE5vdywgeWVzLCB0aGVyZSB3aWxsIGJlIGNhc2VzIHdo ZXJlIHRoaXMgZmFpbHMsIGFuZCB3aGVyZSBhIG5vZGUgYWxzbyBuZWVkcyB0byBkbyBzb21ldGhp bmcgc2Vuc2libGUgaW4gY2FzZSBvZiBjb21wbGV0ZSBpc29sYXRpb24uIEJ1dCB0aGF04oCZcyBh biBleGNlcHRpb24NCiBzdGF0ZSBpbiBteSBtaW5kLiA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2Qi IGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+UGFnZXMgNy04LCBTZWN0aW9uIDMuNjxicj4N Ck1vc3QgYXV0b25vbWljIG5ldHdvcmtpbmcgc3lzdGVtcyB0byBkYXRlIGhhdmUgTk9UIGJlZW4g YnVpbHQgd2l0aCBhbiBpbnRlbnQgKG9yIGRlY2xhcmF0aXZlKSBzdHlsZSBpbnRlcmZhY2UuIEZP Q0FMRSBlbmFibGVzIGRlY2xhcmF0aXZlIGFuZCBwcmVzY3JpcHRpdmUgKGUuZy4sIEVDQSBwb2xp Y3kgcnVsZXMpIHRvIGJlIHVzZWQuIE90aGVycyBqdXN0IHVzZSBFQ0EgKG9yIGFuIGVxdWl2YWxl bnQpIHBhcmFkaWdtLiBIZW5jZSwgSSdtIHdvbmRlcmluZw0KIHdoeSBpbnRlbnQgaXMgdGhlIE9O TFkgcGFyYWRpZ20gdGhhdCBpcyBtZW50aW9uZWQgaW4gdGhpcyBSRkMgdGhhdCBpcyBzdWl0YWJs ZSBmb3IgYXV0b25vbWljIG5ldHdvcmtpbmc/IFNob3VsZG4ndCB3ZSB0cnkgYW5kIHBlYWNlZnVs bHkgY29leGlzdCwganVzdCBhcyB0aGUgbm9kZXMgYXJlIHBlYWNlZnVsbHkgY29leGlzdGluZyB3 aXRoIG5vbi1hdXRvbm9taWMgZGlyZWN0aXZlcz88bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgY29s b3I9IiMxZjQ5N2QiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250Pjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBm YWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ TUI6IFRvIG1lLCBFQ0EgaXMgZW5jb2RlZCBpbiBhbiBBU0Egb3IgYW4gYXV0b25vbWljIGZ1bmN0 aW9uLiBUaGUgZnVuY3Rpb24gc2F5cyB3aGF0IGFjdGlvbiB5b3UgdGFrZSBpbiBzcGVjaWZpYw0K IGV2ZW50cywgYW5kIHVuZGVyIHdoaWNoIGNvbmRpdGlvbi4gPG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0 OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+RXhhbXBsZTogVGhlIOKAnGVucm9sbWVudCBwcm94eSBBU0HigJ0gaGFzIHRoZSBmb2xs b3dpbmcgKGhhcmQgY29kZWQpIEVTQToNCjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8 cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxmb250IHNpemU9IjIi IGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxmb250IHNp emU9IjEiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvc3Bhbj48L2Zv bnQ+PCFbZW5kaWZdPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJp Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RXZlbnQ6IEEgbmV3 IG5vZGUgaXMgZGV0ZWN0ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0Omww IGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48Zm9udCBzaXplPSIyIiBjb2xvcj0i IzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08Zm9udCBzaXplPSIxIiBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9mb250Pjwvc3Bhbj48L3NwYW4+PC9mb250PjwhW2Vu ZGlmXT48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNvbmRpdGlvbjogaXQgZG9lc27i gJl0IGhhdmUgYSBkb21haW4gY2VydCB5ZXQNCjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxmb250IHNpemU9 IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxmb250 IHNpemU9IjEiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvc3Bhbj48 L2ZvbnQ+PCFbZW5kaWZdPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxp YnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWN0aW9uOiBJ IGludml0ZSB0aGUgbm9kZSB0byBqb2luIG15IG5ldHdvcmsuDQo8bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMx ZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5Ob3csIEludGVudCBpcyBpbiBteSBtaW5kIGEgaGlnaGVyIGxldmVsIGNvbmNlcHQg d2hpY2ggY291bGQgbm93IHN0YXRlIOKAnGRvIG5vdCBlbnJvbCBuZXcgbm9kZXMgYXQgdGhpcyBt b21lbnTigJ0uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Ib3cgd291bGQgeW91IHNlZSB0 aGF0Pw0KPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNp emU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQiPlBhZ2UgOSwgc2VjdGlvbiAzLjc8YnI+DQomcXVvdDtIb3dldmVyLCBpbiBhbiBBdXRvbm9t aWMgTmV0d29yaywgcmVwb3J0aW5nIHNob3VsZCBoYXBwZW4gb24gYSBuZXR3b3JrLXdpZGUgYmFz aXMuJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlRydWUsIGJ1dCBzaG91bGRuJ3QgaW5kaXZp ZHVhbCBub2RlcyBhbmQgY29sbGVjdGlvbnMgb2Ygbm9kZXMgc3RpbGwgcmVwb3J0PyBUaGF0IGlz bid0IGltcGxpZWQgaW4gdGhlIHdvcmRpbmcuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNl PSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxm b250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TUI6IFllcywgdGhleSBzaG91bGQuIFRoaXMg aXMg4oCcdHJhZGl0aW9uYWwgbWFuYWdlbWVudCBtZXRob2Rz4oCdLiBJbiBvdXIgbW9kZWwsIGV2 ZXJ5IG5vZGUgZG9lcyB0aGUgbm9ybWFsIHN5c2xvZywNCiBldGMuLCBhbmQgYWdncmVnYXRlZCBy ZXBvcnRpbmcgaXMgdGhlIG5ldyB0aGluZyB0aGF0IGNvbWVzIHdpdGggQU4uIDxvOnA+PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBj b2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5GdXJ0aGVybW9yZSwg dGhlIGxhc3QgcGFyYWdyYXBoIHNheXM6ICZxdW90O0F1dG9ub21pYyBuZXR3b3JrIGV2ZW50cyBz aG91bGQgY29uY2VybiB0aGUgQXV0b25vbWljIE5ldHdvcmsgYXMgYSB3aG9sZSwgbm90IGluZGl2 aWR1YWwgc3lzdGVtcyBpbiBpc29sYXRpb24uJnF1b3Q7IEkgYWdyZWUgdGhhdCB0aGUNCiBnb2Fs IGlzIHRvIHJlcG9ydCBvbiB0aGUgc3lzdGVtIGFzIGEgd2hvbGUsIGJ1dCBpc24ndCBzdWNoIGEg cmVwb3J0IGNvbGxlY3RlZCBmcm9tIGluZGl2aWR1YWwgbm9kZXM/IEp1c3QgbGlrZSBpbiB5b3Vy IGV4YW1wbGUsIHRoZSBub2RlcyBuZWVkIHRvIGJlIGFibGUgdG8gc2VlIHRoYXQgYSBwcm9ibGVt IGhhcyBhbHJlYWR5IGJlZW4gcmVwb3J0ZWQgaW4gb3JkZXIgdG8ga25vdyBub3QgdG8gaXNzdWUg dGhlIHNhbWUgcHJvYmxlbS48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgY29sb3I9IiMxZjQ5N2Qi IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJp Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TUI6IFRoZXJlIGFy ZSB0d28gcGFyYWxsZWwgbWV0aG9kcyBvZiByZXBvcnRpbmc6DQo8bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVu dDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48 Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25v cmUiPjEpPGZvbnQgc2l6ZT0iMSIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvZm9udD48L3NwYW4+PC9zcGFuPjwvZm9udD48IVtlbmRp Zl0+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj50aGUgdHJhZGl0aW9uYWwgZXZlcnkt bm9kZS10by1jb250cm9sbGVyIG1ldGhvZCwgd2hlcmUgdGhlIGludGVsbGlnZW5jZSBpcyBjZW50 cmFsPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+ PCFbaWYgIXN1cHBvcnRMaXN0c10+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9 IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3Bh biBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4yKTxmb250IHNpemU9IjEiIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L2ZvbnQ+PC9zcGFu Pjwvc3Bhbj48L2ZvbnQ+PCFbZW5kaWZdPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBm YWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ YSBkaXN0cmlidXRlZCByZXBvcnRpbmcgZnVuY3Rpb24sIHdoZXJlIG5vZGVzIGFnZ3JlZ2F0ZSwg cHJvY2Vzcywgc3VtbWFyaXNlLCBjb3JyZWxhdGUsDQog4oCmICZuYnNwO2luZm9ybWF0aW9uIGJl Zm9yZSBoYW5kaW5nIGl0IHRvIHRoZSBjb250cm9sbGVyLiBIZXJlIHRoZSBpbnRlbGxpZ2VuY2Ug aXMgZGlzdHJpYnV0ZWQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmki PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Cb3RoIHdpbGwgY28t ZXhpc3QuIFRoZSBSRkMgZm9jdXNlcyBvbiB0aGUgbmV3IG1ldGhvZCAoYW5kIG9idmlvdXNseSBp c27igJl0IGNsZWFyIGVub3VnaCBhYm91dCBpdOKApikNCjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u dD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3 ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5QYWdlcyAxMi0xMywgc2VjdGlvbiA1PGJy Pg0KV2h5IGlzIGFuIEF1dG9ub21pYyAqKlVzZXIqKiBBZ2VudCB0aGUgaW50ZXJmYWNlIHRvIGEg Y29udHJvbCBsb29wPyBJIGNhbiBzZWUgYW4gZXh0ZXJuYWwgZW50aXR5IHdhbnRpbmcgdG8gY29u ZmlndXJlIGFuZCBtb25pdG9yIHRoZSBjb250cm9sIGxvb3AsIGJ1dCB3aHkgd291bGRuJ3QgdGhl IFVzZXIgQWdlbnQgdGFsayB0byB0aGUgU2VydmljZSBBZ2VudCB0byBkbyB0aGlzPyBJIGRvIG5v dGUgdGhhdCB0aGlzIGZpZ3VyZSBpcyB1bmRlciBkaXNjdXNzaW9uDQogYW5kIGJlaW5nIHJldmlz ZWQgaW4gdGhlIHJlZmVyZW5jZSBtb2RlbC48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgY29sb3I9 IiMxZjQ5N2QiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNl PSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TUI6 IFllcywgdGhhdOKAmXMgY29uZnVzaW5nIHdvcmRpbmcsIGFuZCBub3cgdGhhdCB5b3UgbWVudGlv biBpdCwgeWVzIHdlIHNob3VsZCBoYXZlIHByb2JhYmx5IGxvb2tlZCBmb3IgYSBiZXR0ZXINCiB0 ZXJtLiBUaGUgaWRlYSBpczogVGhlIOKAnGludGVsbGlnZW5jZeKAnSBvZiBhbiBhdXRvbm9taWMg ZnVuY3Rpb24gaXMgaW4gdGhlIEFTQSAobWlkZGxlIG9mIGZpZ3VyZSAxKS4gVGhlcmUgYXJlIG5v dyBob3Jpem9udGFsIGZlZWRiYWNrIGxvb3BzIGFuZCBub3J0aGJvdW5kIGZlZWRiYWNrIGxvb3Bz LiBGb3IgZXhhbXBsZSwgdGhlcmUgaXMgbGlrZWx5IGEgZnVuY3Rpb24gaW4gdGhlIGVucm9sbWVu dCBwcm9jZXNzLCB3aGVyZSBhIG1lc3NhZ2UgZ2V0cw0KIHNlbnQgdG8gdGhlIGFkbWluOiDigJxI ZXJl4oCZcyBhIG5ldyBub2RlLCBJIGRvbuKAmXQgdGhpbmsgaXQgYmVsb25ncyBpbnRvIG91ciBu ZXR3b3JrLCBJ4oCZdmUgcXVhcmFudGluZWQgdGhhdCBub2RlIGZvciBub3c7IHdvdWxkIHlvdSBs aWtlIG1lIHRvIDEpIGFjY2VwdCB0aGUgbm9kZSBhbnl3YXksIG9yIDIpIG1hcmsgaXQgYXMgYmFk P+KAnTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFm NDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkkgYWdyZWUgdGhlIHRlcm0g4oCcdXNlciBhZ2VudOKAnSBpcyBub3QgZ29vZC4gV2Ug bmVlZCB0byBmaW5kIGEgYmV0dGVyIG9uZS4gU3VnZ2VzdGlvbnM/DQo8bzpwPjwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9 IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+UGFnZSAxMywgRmlndXJlIDE8 YnI+DQpXaGVyZSBpcyB0aGUgQXV0b25vbWljIE5vZGUgaW4gdGhlIFJlZmVyZW5jZSBNb2RlbD8g SSBkbyBub3RlIHRoYXQgdGhpcyBmaWd1cmUgaXMgdW5kZXIgZGlzY3Vzc2lvbiBhbmQgYmVpbmcg cmV2aXNlZCBpbiB0aGUgcmVmZXJlbmNlIG1vZGVsLiBIb3dldmVyLCBldmVuIGluIEZpZ3VyZSAy IG9mIHRoZSByZWZlcmVuY2UgbW9kZWwsIGl0IGlzIHN0aWxsIHVuY2xlYXIgd2hhdCB0aGUgJnF1 b3Q7bm9kZSZxdW90OyBpcy4gQnV0IG1vcmUgb24gdGhhdCBsYXRlci48YnI+DQo8YnIgY2xlYXI9 ImFsbCI+DQo8Zm9udCBjb2xvcj0iIzFmNDk3ZCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi Pk1COiBUaGUgd2hvbGUgdGhpbmcgaXMgdGhlIG5vZGUuIFRoYXTigJlzIHdoeSB0aGUgZmlndXJl IGlzIGNhbGxlZCDigJxSZWZlcmVuY2UgTW9kZWwgZm9yIGFuIEF1dG9ub21pYyBOb2Rl4oCdLg0K PG86cD48L286cD48L3NwYW4+PC9mb250Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250 IHNpemU9IjMiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgYWxsIHlvdXIg aW5wdXQgSm9obiEgTGV04oCZcyBtYWtlIHN1cmUgdGhhdCBhbGwgdGhlc2UgcG9pbnRzIGdldCBh ZGRyZXNzZWQgaW4gdGhlIHJlZmVyZW5jZSBtb2RlbC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u dD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBjb2xvcj0iIzFmNDk3 ZCIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6IzFGNDk3RCI+ TWljaGFlbDwvc3Bhbj48L2ZvbnQ+PGJyPg0KLS0gPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+cmVnYXJkcyw8bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+Sm9objxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0F36xmbrcdx14ciscoc_-- From nobody Mon Jun 22 09:40:31 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E62001B3026 for ; Mon, 22 Jun 2015 09:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.612 X-Spam-Level: X-Spam-Status: No, score=-12.612 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rakt5dlPMGAq for ; Mon, 22 Jun 2015 09:40:29 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D78111B2FC3 for ; Mon, 22 Jun 2015 09:40:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1403; q=dns/txt; s=iport; t=1434991228; x=1436200828; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=J5QXPKqtXzavoFdRb5uOhGgKZuCTquIcb1ECh2CIuXk=; b=EHwEG24K4BNy2j/dMBWq/RLoTD513BJ21H2DfNSSaO/gUVXhxVjgl3Ag Souir2SGZ+xtQlUGxGxTZepQrWjh/lcl+UTDqlpdvd2wEeHzlrDG3pXV/ rlGpUNwXFZgAVkOOyoqX7y/UMPqGWMOfQn6goug3+t283CTz2crXRi2PD E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A5BABFOYhV/5hdJa1cgxCBOb0gZgmHXgKBOjgUAQEBAQEBAYEKhCQBBDpRASoUQiYBBBuIJ6R6pXIBAQEHAgEfkBqDT4EUBZN9AaN+JmODFoI1gQIBAQE X-IronPort-AV: E=Sophos;i="5.13,660,1427760000"; d="scan'208";a="9314314" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 22 Jun 2015 16:40:28 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t5MGeSXM023259 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 22 Jun 2015 16:40:28 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.179]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Mon, 22 Jun 2015 11:40:27 -0500 From: "Michael Behringer (mbehring)" To: Anima WG Thread-Topic: Common Ground on the ACP Thread-Index: AdCp2kWzuNSXI7ELQ66smCIeol/FLQ== Date: Mon, 22 Jun 2015 16:40:26 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0FAB@xmb-rcd-x14.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Anima] Common Ground on the ACP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jun 2015 16:40:30 -0000 ANIMA,=20 Trying to get a new version of the ACP draft out later this week, I'm tryin= g to understand what we're all agreeing on, and what not.=20 As I see it, the high level requirements (below) and the benefits would go = into the reference model, the details into the ACP draft.=20 Requirements for an ACP:=20 1 - The ACP SHOULD provide robust connectivity As far as possible, it should be independent of configured addressing, c= onfiguration and routing.=20 (2 and 3 build on this requirement, but also have value on their own) 2 - The ACP MUST have a separate address space from the data plane. Reason: traceability, debug-ability, separation from data plane, securit= y (can block at edge)=20 3 - The ACP MUST use autonomically managed address space Reason: easy bootstrap and setup ("autonomic"); robustness (admin can't = mess things up so easily). I think we agreed: ULA seems like a good choice for 1 and 2. 4 - The ACP MUST be generic Usable by all the functions and protocols of the AN infrastructure. MUST= NOT be tied to a particular protocol.=20 5- The ACP MUST provide security:=20 Messages coming through the ACP are authenticated to be from a trusted n= ode, and encrypted. =20 4a - MUST: ACP Hop-by-hop authentication 4b - SHOULD: ACP Hop-by-hop encryption Do we agree on those requirements?=20 Michael From nobody Mon Jun 22 09:59:21 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60EAA1AD35B for ; Mon, 22 Jun 2015 09:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IaXzwJ8u2aIR for ; Mon, 22 Jun 2015 09:59:19 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 853291B305E for ; Mon, 22 Jun 2015 09:59:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2712; q=dns/txt; s=iport; t=1434992355; x=1436201955; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=jBYERyTBh78tOxzQJ/xUX0dd6WLPX888QoF6x4npxYg=; b=hrMdU/bgHz8LKtolYTwweOZGuS6ieFH+d0+yCW0LgOpVzcB44u2wCOBn CVg0mSRuHLbF2orjDevNvudkI9/Q3OGxi754wn2mcXJzL3rKZtLkQPdrZ WMrplZnTf/uxNKL0u/BkvaHpscEXaoQ20b6eOklyAB2z4VsHVCjWD0Zsk 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A+BAB+PYhV/5ldJa1cgxBUXwa9IGYJgVwKhXgCgTo4FAEBAQEBAQGBCoQiAQEBAwEBAQE3NBAHBAIBCBEEAQELFAkHJwsUCQgCBAESCIgfCA3KSQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi0WEVTgGgxGBFAWTfQGjfiaCCxyBUm+BRoECAQEB X-IronPort-AV: E=Sophos;i="5.13,660,1427760000"; d="scan'208";a="5581614" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 22 Jun 2015 16:59:14 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t5MGxEqR013505 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Jun 2015 16:59:14 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.179]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Mon, 22 Jun 2015 11:59:14 -0500 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , Anima WG Thread-Topic: [Anima] I-D Action: draft-behringer-anima-autonomic-addressing-01.txt Thread-Index: AQHQrJBjXSw9x2jKGEu1JXctgOXCf524u2PQ Date: Mon, 22 Jun 2015 16:59:14 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0FDC@xmb-rcd-x14.cisco.com> References: <20150618095520.3486.7068.idtracker@ietfa.amsl.com> <55876E20.2070508@gmail.com> In-Reply-To: <55876E20.2070508@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] I-D Action: draft-behringer-anima-autonomic-addressing-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jun 2015 16:59:20 -0000 > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E > Carpenter > Sent: 22 June 2015 04:09 > To: Anima WG > Subject: Re: [Anima] I-D Action: draft-behringer-anima-autonomic- > addressing-01.txt >=20 > Hi Michael, >=20 > Sitting waiting for a flight... >=20 > > IPv6 only: Autonomic processes should use exclusively IPv6, for > > simplicity reasons. >=20 > I agree with this as long as it's an RFC 2119 SHOULD, i.e. IPv4 could be = used in > extraordinary circumstances. The GDNP design is fundamentally IP-version > independent. Yes, as long as it's really "extraordinary" ;-) That 2119 says "SHOULD" m= eans like you need a really good reason to not do it. What would such a goo= d reason be? Just saying, in our implementation we often get the requiremen= t "we want IPv4", and when you dig, the reason is that they don't want to d= eploy IPv6, and that's the only reason. Slippery slope...=20 How would you avoid mission creep? =20 > > Separation: Autonomic address space is used separately from user > > address space and other address realms. This supports the robustness > > requirement. >=20 > That applies to all AN traffic *using routable addresses*. However, some > autonomic signaling will require to be sent directly using link local > addresses, especially link local multicast addresses, during discovery an= d > bootstrap actions. In my thinking, link local is also separate from user address space. I coul= d mention explicitly that this includes link local?=20 =20 > > Loopback-only: Only loopback interfaces ... >=20 > I know I'm repeating myself, but it really would be clearer if you said t= his > the other way round, and I don't think it affects what you mean at all: >=20 > Overlay network: Routeable addresses for AN nodes are used exclusively in > a secure overlay network which is the basis of the ACP. This means that > these addresses will be assigned to the loopback interface in most > operating > systems. All other interfaces exclusively use IPv6 link local for autonom= ic > functions. The usage of IPv6 link local addressing is discussed in [RFC7= 404]. This works for me.=20 > Use-ULA: For these overlay addresses of autonomic nodes, we use Unique > Local Addresses (ULA), as specified in [RFC4193]. An alternative > scheme was discussed, using assigned ULA addressing. The consensus > was to use standard ULA, because it was deemed to be sufficient. That too.=20 Thanks for input!=20 Michael > Brian >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Mon Jun 22 14:24:37 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F091A8A1F for ; Mon, 22 Jun 2015 14:24:30 -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 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 PS9hgNz4gCZ1 for ; Mon, 22 Jun 2015 14:24:29 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::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 E07091ACD55 for ; Mon, 22 Jun 2015 14:24:28 -0700 (PDT) Received: by paceq1 with SMTP id eq1so117278890pac.3 for ; Mon, 22 Jun 2015 14:24:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=WEC62cquqnPEokAJHbDbTPD2CnuTzm80XcykaPDOTuc=; b=nwT4oWoyHaaVFsOfl05MXQdyam6byO+RNjhyvmDrXQRgZrpNXi2vmK/B2qJ5y5fCrx rzEILcGAugPPGVPAZlWsbuc9MtKqjP6NSSJ80y9INaeHaUbcyB+jpwB2+E1Bi4VZUp6i hGJB7QrDI78Z/AvUSf+PXW/fNtW4VJHaxBhDlnxDce0r49fFYmKdkMOEo1AjGwz9Exko 8g2QM2z21l5diO1LStHm7SVjFifG/mTvsWhnAZDrUZs5wgTeMwH+jZJLgolZY1pgSKrB lhGJqDMCzybd7XZ4Kjw/DmLl4L3PU/lReNzhnlWk74r6fTbQOj7uh1r96mfoHcp+X9wk AoVQ== X-Received: by 10.66.66.202 with SMTP id h10mr62169095pat.145.1435008268520; Mon, 22 Jun 2015 14:24:28 -0700 (PDT) Received: from [172.20.3.93] ([119.17.32.167]) by mx.google.com with ESMTPSA id fy5sm20854577pdb.93.2015.06.22.14.24.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jun 2015 14:24:27 -0700 (PDT) Message-ID: <55887D04.2070205@gmail.com> Date: Tue, 23 Jun 2015 09:24:20 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , Anima WG References: <20150618095520.3486.7068.idtracker@ietfa.amsl.com> <55876E20.2070508@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0FDC@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0FDC@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-behringer-anima-autonomic-addressing-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jun 2015 21:24:30 -0000 All agreed but one comment added: On 23/06/2015 04:59, Michael Behringer (mbehring) wrote: >> -----Original Message----- >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E >> Carpenter >> Sent: 22 June 2015 04:09 >> To: Anima WG >> Subject: Re: [Anima] I-D Action: draft-behringer-anima-autonomic- >> addressing-01.txt >> >> Hi Michael, >> >> Sitting waiting for a flight... >> >>> IPv6 only: Autonomic processes should use exclusively IPv6, for >>> simplicity reasons. >> >> I agree with this as long as it's an RFC 2119 SHOULD, i.e. IPv4 could be used in >> extraordinary circumstances. The GDNP design is fundamentally IP-version >> independent. > > Yes, as long as it's really "extraordinary" ;-) That 2119 says "SHOULD" means like you need a really good reason to not do it. What would such a good reason be? Just saying, in our implementation we often get the requirement "we want IPv4", and when you dig, the reason is that they don't want to deploy IPv6, and that's the only reason. Slippery slope... > > How would you avoid mission creep? Firstly we should stand firm on the ACP being self-creating and by definition based on IPv6. Secondly, I can still imagine a case where a corner of a network is still stuck in IPv4-only land, but we wanted to reach out to it. I have enough experience with IPv6-over-IPv4 tunnels to not want to insist on tunneling in such a case. Brian > >>> Separation: Autonomic address space is used separately from user >>> address space and other address realms. This supports the robustness >>> requirement. >> >> That applies to all AN traffic *using routable addresses*. However, some >> autonomic signaling will require to be sent directly using link local >> addresses, especially link local multicast addresses, during discovery and >> bootstrap actions. > > In my thinking, link local is also separate from user address space. I could mention explicitly that this includes link local? > >>> Loopback-only: Only loopback interfaces ... >> >> I know I'm repeating myself, but it really would be clearer if you said this >> the other way round, and I don't think it affects what you mean at all: >> >> Overlay network: Routeable addresses for AN nodes are used exclusively in >> a secure overlay network which is the basis of the ACP. This means that >> these addresses will be assigned to the loopback interface in most >> operating >> systems. All other interfaces exclusively use IPv6 link local for autonomic >> functions. The usage of IPv6 link local addressing is discussed in [RFC7404]. > > This works for me. > >> Use-ULA: For these overlay addresses of autonomic nodes, we use Unique >> Local Addresses (ULA), as specified in [RFC4193]. An alternative >> scheme was discussed, using assigned ULA addressing. The consensus >> was to use standard ULA, because it was deemed to be sufficient. > > That too. > > Thanks for input! > > Michael > >> Brian >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > From nobody Mon Jun 22 14:30:03 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 421151AD34D for ; Mon, 22 Jun 2015 14:30:02 -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 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 PMsEEL90B8ZR for ; Mon, 22 Jun 2015 14:30:00 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (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 D04941AD33F for ; Mon, 22 Jun 2015 14:30:00 -0700 (PDT) Received: by paceq1 with SMTP id eq1so117352595pac.3 for ; Mon, 22 Jun 2015 14:30:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4BAjafxW/9kFuhr2nwDDSmWRMIWqxq7U3W6Tk3mrls8=; b=IZ1EwjlYkSQ0+FtzAhjSiFk0tWVsERH4tLntgexMNS87qo5AfGnws+25+UtHE3YQiD PnQH4Ez35e1446uQb5tPxzUbegKqRBLChvfQoVl14vb1Y5amLZkDZMvdVskumoD7OfSP 3j1TjnjRwKfQKfwI8U//ogPzeZ0Zd4MucE6u7SetPA1qzr51ds56gYjQaMiSWwmSnvVW 66VQlPqW/0iBRYFPdbcMKhtmgYxzSYgElH0+KDieyGzrQFOslCUdjQ3JsKY8jyfgRAf8 n+5DhLMC80/ZHNvf1KaPiLZXTC3WdMyM5lCfRoPpGteWf/wPT5bEEbX0Jh8FosfkKKPs 1a0g== X-Received: by 10.68.197.102 with SMTP id it6mr28428593pbc.65.1435008600509; Mon, 22 Jun 2015 14:30:00 -0700 (PDT) Received: from [172.20.3.93] ([119.17.32.167]) by mx.google.com with ESMTPSA id q4sm20882696pdo.42.2015.06.22.14.29.57 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jun 2015 14:29:59 -0700 (PDT) Message-ID: <55887E55.9000207@gmail.com> Date: Tue, 23 Jun 2015 09:29:57 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , Anima WG References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0FAB@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0FAB@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Common Ground on the ACP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jun 2015 21:30:02 -0000 Hi Michael, I pretty much agree, but > 4a - MUST: ACP Hop-by-hop authentication > 4b - SHOULD: ACP Hop-by-hop encryption I suppose these are meant to be 5a/b, but more substantively, is hop-by-hop a *requirement*? End-to-end is definitely required, but hop-by-hop seems like an implementation choice. My opinion is that in these days of pervasive surveillance, encryption is a very strong SHOULD indeed. Brian On 23/06/2015 04:40, Michael Behringer (mbehring) wrote: > ANIMA, > > Trying to get a new version of the ACP draft out later this week, I'm trying to understand what we're all agreeing on, and what not. > > As I see it, the high level requirements (below) and the benefits would go into the reference model, the details into the ACP draft. > > Requirements for an ACP: > > 1 - The ACP SHOULD provide robust connectivity > As far as possible, it should be independent of configured addressing, configuration and routing. > (2 and 3 build on this requirement, but also have value on their own) > > 2 - The ACP MUST have a separate address space from the data plane. > Reason: traceability, debug-ability, separation from data plane, security (can block at edge) > > 3 - The ACP MUST use autonomically managed address space > Reason: easy bootstrap and setup ("autonomic"); robustness (admin can't mess things up so easily). > > I think we agreed: ULA seems like a good choice for 1 and 2. > > 4 - The ACP MUST be generic > Usable by all the functions and protocols of the AN infrastructure. MUST NOT be tied to a particular protocol. > > 5- The ACP MUST provide security: > Messages coming through the ACP are authenticated to be from a trusted node, and encrypted. > > 4a - MUST: ACP Hop-by-hop authentication > 4b - SHOULD: ACP Hop-by-hop encryption > > Do we agree on those requirements? > > Michael > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Mon Jun 22 17:42:32 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8D71B311E for ; Mon, 22 Jun 2015 17:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.111 X-Spam-Level: X-Spam-Status: No, score=-13.111 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyrEj5u7zBMe for ; Mon, 22 Jun 2015 17:42:29 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82DB51ACE45 for ; Mon, 22 Jun 2015 17:42:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3847; q=dns/txt; s=iport; t=1435020149; x=1436229749; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=VXLpQ95iYHjivpbFASFKdFvIZcCzI7J4XWl6sc4CojE=; b=I2SbXY8YcTZ7zsFABU0muoZndjh/cu5vZCKSFpa/NvnpYe2+NYm0Eza4 43089480cXguD+4MjdekTIT5sCwfcFq1H5gBwYmx/SWQV7cjamDmSP4OS wi+n9xVIywFQgY4+IZfOIWlFQQxyXc8lbvw99Xaw5OMKwl8t252jNUCUG k=; X-IronPort-AV: E=Sophos;i="5.13,662,1427760000"; d="scan'208";a="161904198" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-5.cisco.com with ESMTP; 23 Jun 2015 00:42:29 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t5N0gSBF012221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Jun 2015 00:42:28 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 t5N0gRYl013573; Mon, 22 Jun 2015 17:42:27 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t5N0gRNo013572; Mon, 22 Jun 2015 17:42:27 -0700 Date: Mon, 22 Jun 2015 17:42:27 -0700 From: Toerless Eckert To: Brian E Carpenter Message-ID: <20150623004227.GA27886@cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0FAB@xmb-rcd-x14.cisco.com> <55887E55.9000207@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55887E55.9000207@gmail.com> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Anima WG , "Michael Behringer \(mbehring\)" Subject: Re: [Anima] Common Ground on the ACP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jun 2015 00:42:31 -0000 Brian: These are intertwined: Lets just start assuming end-to-end encryption is good enough. How do we create between ASAs security associations. We definitely would like that not every ASA needs to build out a separate security stack. So ultimately, this would require you to either figure out network wide group-keys or something like up to a full-mesh of p2p keys (eg: via IKE). That can easily lead to a big chunk of key negotiations. And when we looked at HW keys, then #SAs is usually the limit on HW platforms. Some platforms meant to be big VPN headens may have enough to do this, most network devices won't. And with just end-to-end, you still haven't eliminated injection of DoS traffic to just overload long network paths: Because only the ultimate receiver will be able to authenticate and reject the packets. Thats about the point when you start to love hop-by-hop security. Which is by the way also the argument used by 802.1ae, which is also hop-by-hop. And which os by the way a quite attractive option to use for ACP IMHO. So when you're back disecting hop-by-hop security, you have authentication and encryption. To the best of my knowledge, you can have authentication without encryption, but not the other way around. Or rather: when you can decrypt, authentication was implied. Which is why we can't turn MUST/SHOULD around. Cheers Toerless On Tue, Jun 23, 2015 at 09:29:57AM +1200, Brian E Carpenter wrote: > Hi Michael, > > I pretty much agree, but > > > 4a - MUST: ACP Hop-by-hop authentication > > 4b - SHOULD: ACP Hop-by-hop encryption > > I suppose these are meant to be 5a/b, but more substantively, is hop-by-hop > a *requirement*? End-to-end is definitely required, but hop-by-hop seems > like an implementation choice. > > My opinion is that in these days of pervasive surveillance, encryption > is a very strong SHOULD indeed. > > Brian > > On 23/06/2015 04:40, Michael Behringer (mbehring) wrote: > > ANIMA, > > > > Trying to get a new version of the ACP draft out later this week, I'm trying to understand what we're all agreeing on, and what not. > > > > As I see it, the high level requirements (below) and the benefits would go into the reference model, the details into the ACP draft. > > > > Requirements for an ACP: > > > > 1 - The ACP SHOULD provide robust connectivity > > As far as possible, it should be independent of configured addressing, configuration and routing. > > (2 and 3 build on this requirement, but also have value on their own) > > > > 2 - The ACP MUST have a separate address space from the data plane. > > Reason: traceability, debug-ability, separation from data plane, security (can block at edge) > > > > 3 - The ACP MUST use autonomically managed address space > > Reason: easy bootstrap and setup ("autonomic"); robustness (admin can't mess things up so easily). > > > > I think we agreed: ULA seems like a good choice for 1 and 2. > > > > 4 - The ACP MUST be generic > > Usable by all the functions and protocols of the AN infrastructure. MUST NOT be tied to a particular protocol. > > > > 5- The ACP MUST provide security: > > Messages coming through the ACP are authenticated to be from a trusted node, and encrypted. > > > > 4a - MUST: ACP Hop-by-hop authentication > > 4b - SHOULD: ACP Hop-by-hop encryption > > > > Do we agree on those requirements? > > > > Michael > > > > _______________________________________________ > > 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 -- --- Toerless Eckert, eckert@cisco.com From nobody Mon Jun 22 18:20:20 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398971ACD9C for ; Mon, 22 Jun 2015 18:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trcuDFfO8MRN for ; Mon, 22 Jun 2015 18:20:10 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41FA51B3177 for ; Mon, 22 Jun 2015 18:20:09 -0700 (PDT) Received: by wicnd19 with SMTP id nd19so91756452wic.1 for ; Mon, 22 Jun 2015 18:20:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xMbEcYEcVPaQbp0fFahdyGBVFvS102EyF9/VwS4GxyI=; b=oxjzq6AMRHmncQM3nBfPpyknGAvppJHm7sEP8JGfm68qEwdY8Q8r9fJrivMW1tCMkP w45mp9lYnLHOZUbjNKXnb3C94pOfGGYnxw4ef75YqRJ8DxF8N5Cnn7S2lTNpzJL5agAN jvsYabn7NYJLicV5tOZ/M+zCpbJCWhHiTmlZKcla6SkwuLLDMk771F9v2bEbAlDOh+LV ozy6jffJZmPyjW1l+kl7l7mIaInegkDBAFcp8qsw02oaq7JbcqJeG/AIyT31N8lQBTwp 2xSL5pRNebwghYncXnKi3ffsPfJ5KfbBv32ug+KZmxSAgQRK5N1spdt2LJSbwXJOSdIc n/KA== MIME-Version: 1.0 X-Received: by 10.194.189.80 with SMTP id gg16mr46996032wjc.9.1435022407956; Mon, 22 Jun 2015 18:20:07 -0700 (PDT) Received: by 10.27.220.1 with HTTP; Mon, 22 Jun 2015 18:20:07 -0700 (PDT) In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0F36@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0F36@xmb-rcd-x14.cisco.com> Date: Mon, 22 Jun 2015 18:20:07 -0700 Message-ID: From: John Strassner To: "Michael Behringer (mbehring)" , John Strassner Content-Type: multipart/alternative; boundary=047d7bb03f9cdeff2505192530e7 Archived-At: Cc: Anima WG Subject: Re: [Anima] Questions on RFC7575 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jun 2015 01:20:18 -0000 --047d7bb03f9cdeff2505192530e7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Michael for the response. My purpose was not to affect RFC7575, but rather to ensure consistency as we move forward. Please see inline as well. Questions on RFC7575 Page 3 "Autonomic functions can be defined in two ways: o On a node level: Nodes interact with each other to form feedback loops. o On a system level: Feedback loops include central elements as well." What is a "central element"? Does this mean that the feedback loop includes centralized management mechanisms, or that there is additional logic outside of just the nodes? MB: A central element is a controller for example. The point of the section is: You could define an =E2=80=9Cautonomic network=E2=80=9D where every nod= e has exactly the same interfaces as today (primarily CLI, SNMP, NETCONF), and where a controller is involved in all control loops. Our definition of =E2=80=9Caut= onomic=E2=80=9D is further down in the network, where nodes interact directly with nodes. Now we all understand this isn=E2=80=99t black and white, but the emphasis = of the work in the IETF should be node-to-node interactions. OK, got it. Just to ensure, is it fair to say that a "central element" is one in which non-autonomic functions are used that may affect the behavior of autonomic nodes? Page 5, definition of intent Why is intent scoped to a single autonomic domain? MB: Intent isn=E2=80=99t a policy language like most other, where you can essentially define a policy for every network element separately. The fundamental idea is that there is one intent for the entire network. Thus this definition. My personal opinion: If we let Intent slip into the element management scope, we=E2=80=99ve missed an opportunity. Intent is a policy on network s= cope. Here you lost me. ODL GBP and ODL NIC, OpenStack Congress, some nascent work in the ONF, and TMF ZOOM would all disagree. Intent, for better or worse, has been characterized as The New Policy (no offense to Light Reading). But then at the end you say "Intent is a policy on network scope", so maybe I'm reading you too literally? (see I haven't changed since my Cisco days :-) ). Plus, do you really mean "for the entire network"? Isn't "for a given set of administrative domains" good enough? Page 5, definition of autonomic domain Why is autonomic domain tied to intent as the only management paradigm? The vast majority of work in autonomic networking does NOT use intent (what I call declarative logic, I failed marketing :-) ). I completely agree with using intent, and perhaps even emphasizing it, but I don't agree with excluding other management paradigms. MB: Probably a question of wording. In my reading you have 1) autonomic default behaviour (could also call this =E2=80=9Cdefault intent=E2=80=9D), = 2) Intent, and 3) traditional management schemes, such as NETCONF, SNMP, CLI, etc=E2=80=A6 So we don=E2=80=99t exclude other management paradigms, they are handles in= section 3.2. Is that what you mean? (You could also define an autonomic domain by the zone of trust of the certificates.) Yes. Note that in SUPA, we derive intent and traditional (i.e., ECA) from the same Policy info model. This has the nice property of letting intent translate across actors and be used to fire ECA policies (and vice versa). Page 5, self-management "They configure themselves, based on self-knowledge, discovery, and Intent.= " The word "discovery" is confusing me. Suppose a node runs a utility function to decide what its next configuration change should be. It is not "discovering" something that existed - rather, it is computing new knowledge. A machine learning function that infers new knowledge is an even better example of something that is not "discovered". I'm probably missing something, but why was this choice made? The thing that really bothers me is that this assumes that all knowledge can be discovered - that is, it is existing, like an apple on a tree, ready to be plucked. In the autonomic systems that I've built, this is only sometimes the case. It is vital for an autonomic system to be able to learn new knowledge via computation and inference, as well as decide that previous knowledge was incorrect. Neither of these are discovery functions. MB: I think the confusion is the definition of =E2=80=9Cdiscovery=E2=80=9D = here. It=E2=80=99s not only discovery in the sense of service discovery, but for example, finding neighbors, negotiating parameters with them, etc. The above phrase in other words: =E2=80=9CI know my capabilities, I see wha= t else is there (and talk to it potentially), and I see what the boss wants to happen (intent). Based on all of this I decide what I=E2=80=99m going to do= =E2=80=9D. I think it=E2=80=99s a question of wording. We had this graphic (similar to= figure 1), where there are the 3 input vectors (!) of information, on which you base your decisions. The inference you mention is a consequence of those inputs. In other words, the =E2=80=9Cbrain=E2=80=9D that actually makes the= inference, is in our model the autonomic service agent. Does that make sense? I think so. I still think that my two examples are not discovery. I had somehow concluded that discovery was all-inclusive, but when I look at your answer, I realize that it isn't. Still, in the reference document, I think we should point this out. I do agree that discovery is sometimes not explicitly mentioned, which is a shame, since it is such a vital function. It would therefore be OK imho to emphasize discovery as long as we leave some wiggle room for dynamically creating and removing knowledge. Page 6, last paragraph above section 3.2 "...closed-loop control is an important aspect of self-managing systems. This implies peer-to-peer dialogues between the parties that make up the closed loop. Such dialogues require two-way "discussion" or "negotiation" between each pair or groups of peers involved in the loop,..." First, by "peer", I assume you mean two (or more) equipotent entities that make some portion of their resources available to others. Second, and more importantly, a closed control loop does not require each entity in the closed control loop to talk to negotiate with other entities. Now, in an autonomic control loop, this could very well be the case, but it is unclear to me why it MUST be the case. The obvious nightmare scenario is that the negotiation fails. Then what - we have no control loop at all? MB: I guess your point is that an autonomic process doesn=E2=80=99t HAVE to= have a control loop. I would argue that the typical autonomic function DOES have node-to-node interactions. This is what autonomics is all about. Now, yes, there will be cases where this fails, and where a node also needs to do something sensible in case of complete isolation. But that=E2=80=99s an exc= eption state in my mind. No. Let me try again. The text that bothers me is "[closed-loop] implies peer-to-peer dialogues between the parties that make up the close loop". That isn't how traditional control loops are typically built, and I'm personally not familiar with any autonomic system that builds them in this way. Sure, it would be nice to allow this when necessary - FOCALE had this feature through a dedicated control interface that could adapt the function carried out by a control loop element based on (for example) changing context - but I disagree that it is a MANDATORY function. To your second point, I do (of course!) agree that autonomics is about node-to-node interactions. But, it is also about system-wide interactions. My point was that if you mandate negotiation in order to create a control loop, and the negotiation fails, you're in trouble. And yes, that would be an exception state in my mind, as it violates a basic principle in autonomics - consensual behavior. Pages 7-8, Section 3.6 Most autonomic networking systems to date have NOT been built with an intent (or declarative) style interface. FOCALE enables declarative and prescriptive (e.g., ECA policy rules) to be used. Others just use ECA (or an equivalent) paradigm. Hence, I'm wondering why intent is the ONLY paradigm that is mentioned in this RFC that is suitable for autonomic networking? Shouldn't we try and peacefully coexist, just as the nodes are peacefully coexisting with non-autonomic directives? MB: To me, ECA is encoded in an ASA or an autonomic function. The function says what action you take in specific events, and under which condition. Example: The =E2=80=9Cenrolment proxy ASA=E2=80=9D has the following (hard = coded) ESA: - Event: A new node is detected - Condition: it doesn=E2=80=99t have a domain cert yet - Action: I invite the node to join my network. Now, Intent is in my mind a higher level concept which could now state =E2= =80=9Cdo not enrol new nodes at this moment=E2=80=9D. How would you see that? Is the action a typo, and you really meant: "I do not invite the node to join my network"? As stated, I would say that the ECA policy would NOT fire because it violates intent. However, to my earlier point above about intent and ECA policies being able to call each other - ABSOLUTELY. Page 9, section 3.7 "However, in an Autonomic Network, reporting should happen on a network-wide basis." True, but shouldn't individual nodes and collections of nodes still report? That isn't implied in the wording. MB: Yes, they should. This is =E2=80=9Ctraditional management methods=E2=80= =9D. In our model, every node does the normal syslog, etc., and aggregated reporting is the new thing that comes with AN. Got it, thanks. Furthermore, the last paragraph says: "Autonomic network events should concern the Autonomic Network as a whole, not individual systems in isolation." I agree that the goal is to report on the system as a whole, but isn't such a report collected from individual nodes? Just like in your example, the nodes need to be able to see that a problem has already been reported in order to know not to issue the same problem. MB: There are two parallel methods of reporting: 1) the traditional every-node-to-controller method, where the intelligence is central 2) a distributed reporting function, where nodes aggregate, process, summarise, correlate, =E2=80=A6 information before handing it to the contr= oller. Here the intelligence is distributed. Both will co-exist. The RFC focuses on the new method (and obviously isn=E2= =80=99t clear enough about it=E2=80=A6) OK, got it. In FOCALE, we almost NEVER used node-to-controller (well, FOCALE predates SDN controllers, but let's say controller =3D=3D some centralized manager) unless the majority (or more) of nodes failed. We did use an umbrella management paradigm (similar to clusterheads in P2P networks), where the clusterheads did collection, filtering, correlation, and possibly other functions before passing the data (not necessarily up!). I'm happy to focus on the new, just want to ensure we have some fallback position for not just legacy integration, but more importantly, failure modes. Pages 12-13, section 5 Why is an Autonomic **User** Agent the interface to a control loop? I can see an external entity wanting to configure and monitor the control loop, but why wouldn't the User Agent talk to the Service Agent to do this? I do note that this figure is under discussion and being revised in the reference model. MB: Yes, that=E2=80=99s confusing wording, and now that you mention it, yes= we should have probably looked for a better term. The idea is: The =E2=80=9Cintelligence=E2=80=9D of an autonomic function is in the ASA (midd= le of figure 1). There are now horizontal feedback loops and northbound feedback loops. For example, there is likely a function in the enrolment process, where a message gets sent to the admin: =E2=80=9CHere=E2=80=99s a new node, I don= =E2=80=99t think it belongs into our network, I=E2=80=99ve quarantined that node for now; would= you like me to 1) accept the node anyway, or 2) mark it as bad?=E2=80=9D I agree the term =E2=80=9Cuser agent=E2=80=9D is not good. We need to find = a better one. Suggestions? So does "user agent" mean "(autonomic) management agent"? Probably NOT a user-facing agent, right? In the tradition of Calm Technology, the best and most ubiquitous functions are those that don't demand attention, but rather inform. Page 13, Figure 1 Where is the Autonomic Node in the Reference Model? I do note that this figure is under discussion and being revised in the reference model. However, even in Figure 2 of the reference model, it is still unclear what the "node" is. But more on that later. MB: The whole thing is the node. That=E2=80=99s why the figure is called = =E2=80=9CReference Model for an Autonomic Node=E2=80=9D. But if it is a **node**, then why is it running its own internal feedback loops? Note that "node" implies a single something. Clearly, the single something can contain groups of other somethings, but why would a feedback loop exist in the single something when we are emphasizing inter-node communication and functionality? I think that this figure would be improved by showing interfaces to the Autonomic Control Plane and to the OS; right now, they are inside of the node, and that I don't understand. In FOCALE, as well as other architectures, knowledge did not have to be embedded in the node, it could be received from other places in the network. Hence, I think that showing interfaces to where knowledge is obtained and where it is discovered is more generic. Of course, more capable nodes could contain these functions, but I'm not convinced that this is the norm. Thanks for all your input John! Let=E2=80=99s make sure that all these poin= ts get addressed in the reference model. I hope it helps. I think I can now write my sections in a way that will be more consistent. More feedback coming later. Michael best regards, John On Mon, Jun 22, 2015 at 8:46 AM, Michael Behringer (mbehring) < mbehring@cisco.com> wrote: > Hi John, let me take a stab at responding=E2=80=A6 And thanks for sharin= g your > thoughts. A bit late to bring them into RFC7575, but a good timing for th= e > reference model. > > > > *From:* Anima [mailto:anima-bounces@ietf.org] *On Behalf Of *John > Strassner > *Sent:* 21 June 2015 19:28 > *To:* Anima WG > *Subject:* [Anima] Questions on RFC7575 > > > > I started reviewing both the reference model as well as other pertinent > documents, so that when I write my sections for the reference model, they > are consistent. :-) > > > > In doing so, I have a number of questions on RFC7575. Part of this may be > my academic nature, part may be because I have undoubtedly missed somethi= ng > in past emails as I come up to speed, and partly because I'm likely > under-caffeinated. Hopefully, some of this will help improve the referenc= e > model (and possibly other documents as well). > > > > Questions on RFC7575 > Page 3 > "Autonomic functions can be defined in two ways: > o On a node level: Nodes interact with each other to form feedback > loops. > o On a system level: Feedback loops include central elements as > well." > What is a "central element"? Does this mean that the feedback loop > includes centralized management mechanisms, or that there is additional > logic outside of just the nodes? > > > > MB: A central element is a controller for example. The point of the > section is: You could define an =E2=80=9Cautonomic network=E2=80=9D where= every node has > exactly the same interfaces as today (primarily CLI, SNMP, NETCONF), and > where a controller is involved in all control loops. Our definition of > =E2=80=9Cautonomic=E2=80=9D is further down in the network, where nodes i= nteract directly > with nodes. Now we all understand this isn=E2=80=99t black and white, but= the > emphasis of the work in the IETF should be node-to-node interactions. > > > > Page 5, definition of intent > Why is intent scoped to a single autonomic domain? > > > > MB: Intent isn=E2=80=99t a policy language like most other, where you can > essentially define a policy for every network element separately. The > fundamental idea is that there is one intent for the entire network. Thus > this definition. > > My personal opinion: If we let Intent slip into the element management > scope, we=E2=80=99ve missed an opportunity. Intent is a policy on network= scope. > > > > Page 5, definition of autonomic domain > Why is autonomic domain tied to intent as the only management paradigm? > The vast majority of work in autonomic networking does NOT use intent (wh= at > I call declarative logic, I failed marketing :-) ). I completely agree wi= th > using intent, and perhaps even emphasizing it, but I don't agree with > excluding other management paradigms. > > > > MB: Probably a question of wording. In my reading you have 1) autonomic > default behaviour (could also call this =E2=80=9Cdefault intent=E2=80=9D)= , 2) Intent, and > 3) traditional management schemes, such as NETCONF, SNMP, CLI, etc=E2=80= =A6 > > So we don=E2=80=99t exclude other management paradigms, they are handles = in > section 3.2. Is that what you mean? > > (You could also define an autonomic domain by the zone of trust of the > certificates.) > > > > Page 5, self-management > "They configure themselves, based on self-knowledge, discovery, and > Intent." > The word "discovery" is confusing me. Suppose a node runs a utility > function to decide what its next configuration change should be. It is no= t > "discovering" something that existed - rather, it is computing new > knowledge. A machine learning function that infers new knowledge is an ev= en > better example of something that is not "discovered". I'm probably missin= g > something, but why was this choice made? > > The thing that really bothers me is that this assumes that all knowledge > can be discovered - that is, it is existing, like an apple on a tree, rea= dy > to be plucked. In the autonomic systems that I've built, this is only > sometimes the case. It is vital for an autonomic system to be able to lea= rn > new knowledge via computation and inference, as well as decide that > previous knowledge was incorrect. Neither of these are discovery function= s. > > > > MB: I think the confusion is the definition of =E2=80=9Cdiscovery=E2=80= =9D here. It=E2=80=99s not > only discovery in the sense of service discovery, but for example, findin= g > neighbors, negotiating parameters with them, etc. > > The above phrase in other words: =E2=80=9CI know my capabilities, I see w= hat else > is there (and talk to it potentially), and I see what the boss wants to > happen (intent). Based on all of this I decide what I=E2=80=99m going to = do=E2=80=9D. > > I think it=E2=80=99s a question of wording. We had this graphic (similar = to figure > 1), where there are the 3 input vectors (!) of information, on which you > base your decisions. The inference you mention is a consequence of those > inputs. In other words, the =E2=80=9Cbrain=E2=80=9D that actually makes t= he inference, is > in our model the autonomic service agent. > > Does that make sense? > > > > Page 6, last paragraph above section 3.2 > "...closed-loop control is an important aspect of self-managing systems. > > This implies peer-to-peer dialogues between the parties that make up > > the closed loop. Such dialogues require two-way "discussion" or > "negotiation" > > between each pair or groups of peers involved in the loop,..." > First, by "peer", I assume you mean two (or more) equipotent entities tha= t > make some portion of their resources available to others. Second, and mor= e > importantly, a closed control loop does not require each entity in the > closed control loop to talk to negotiate with other entities. Now, in an > autonomic control loop, this could very well be the case, but it is uncle= ar > to me why it MUST be the case. The obvious nightmare scenario is that the > negotiation fails. Then what - we have no control loop at all? > > > > MB: I guess your point is that an autonomic process doesn=E2=80=99t HAVE = to have a > control loop. I would argue that the typical autonomic function DOES have > node-to-node interactions. This is what autonomics is all about. Now, yes= , > there will be cases where this fails, and where a node also needs to do > something sensible in case of complete isolation. But that=E2=80=99s an e= xception > state in my mind. > > > > Pages 7-8, Section 3.6 > Most autonomic networking systems to date have NOT been built with an > intent (or declarative) style interface. FOCALE enables declarative and > prescriptive (e.g., ECA policy rules) to be used. Others just use ECA (or > an equivalent) paradigm. Hence, I'm wondering why intent is the ONLY > paradigm that is mentioned in this RFC that is suitable for autonomic > networking? Shouldn't we try and peacefully coexist, just as the nodes ar= e > peacefully coexisting with non-autonomic directives? > > > > MB: To me, ECA is encoded in an ASA or an autonomic function. The functio= n > says what action you take in specific events, and under which condition. > > Example: The =E2=80=9Cenrolment proxy ASA=E2=80=9D has the following (har= d coded) ESA: > > - Event: A new node is detected > > - Condition: it doesn=E2=80=99t have a domain cert yet > > - Action: I invite the node to join my network. > > Now, Intent is in my mind a higher level concept which could now state = =E2=80=9Cdo > not enrol new nodes at this moment=E2=80=9D. > > How would you see that? > > > > Page 9, section 3.7 > "However, in an Autonomic Network, reporting should happen on a > network-wide basis." > > True, but shouldn't individual nodes and collections of nodes still > report? That isn't implied in the wording. > > > > MB: Yes, they should. This is =E2=80=9Ctraditional management methods=E2= =80=9D. In our > model, every node does the normal syslog, etc., and aggregated reporting = is > the new thing that comes with AN. > > > > Furthermore, the last paragraph says: "Autonomic network events should > concern the Autonomic Network as a whole, not individual systems in > isolation." I agree that the goal is to report on the system as a whole, > but isn't such a report collected from individual nodes? Just like in you= r > example, the nodes need to be able to see that a problem has already been > reported in order to know not to issue the same problem. > > > > MB: There are two parallel methods of reporting: > > 1) the traditional every-node-to-controller method, where the > intelligence is central > > 2) a distributed reporting function, where nodes aggregate, process, > summarise, correlate, =E2=80=A6 information before handing it to the con= troller. > Here the intelligence is distributed. > > Both will co-exist. The RFC focuses on the new method (and obviously isn= =E2=80=99t > clear enough about it=E2=80=A6) > > > > Pages 12-13, section 5 > Why is an Autonomic **User** Agent the interface to a control loop? I can > see an external entity wanting to configure and monitor the control loop, > but why wouldn't the User Agent talk to the Service Agent to do this? I d= o > note that this figure is under discussion and being revised in the > reference model. > > > > MB: Yes, that=E2=80=99s confusing wording, and now that you mention it, y= es we > should have probably looked for a better term. The idea is: The > =E2=80=9Cintelligence=E2=80=9D of an autonomic function is in the ASA (mi= ddle of figure 1). > There are now horizontal feedback loops and northbound feedback loops. Fo= r > example, there is likely a function in the enrolment process, where a > message gets sent to the admin: =E2=80=9CHere=E2=80=99s a new node, I don= =E2=80=99t think it > belongs into our network, I=E2=80=99ve quarantined that node for now; wou= ld you > like me to 1) accept the node anyway, or 2) mark it as bad?=E2=80=9D > > > > I agree the term =E2=80=9Cuser agent=E2=80=9D is not good. We need to fin= d a better one. > Suggestions? > > > > Page 13, Figure 1 > Where is the Autonomic Node in the Reference Model? I do note that this > figure is under discussion and being revised in the reference model. > However, even in Figure 2 of the reference model, it is still unclear wha= t > the "node" is. But more on that later. > > MB: The whole thing is the node. That=E2=80=99s why the figure is called > =E2=80=9CReference Model for an Autonomic Node=E2=80=9D. > > > > Thanks for all your input John! Let=E2=80=99s make sure that all these po= ints get > addressed in the reference model. > > > > Michael > -- > > regards, > > John > --=20 regards, John --047d7bb03f9cdeff2505192530e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jun 22, 2015 at 8:46 AM, Michael Behringer (mbehri= ng) <mbehring@cisco.com> wrote:

= Hi John, let me take a stab at responding= =E2=80=A6 And thanks for sharing your thoughts. A bit late to bring them in= to RFC7575, but a good timing for the reference model. <= /font>

= =C2=A0

From: Anima [mailto:= anima-bounces@ietf.org] On Behalf O= f John Strassner
Sent: 21 June 2015 19:28
To: Anima WG
Subject: [Anima] Questions o= n RFC7575

=C2=A0

I started reviewing both the reference model as well a= s other pertinent documents, so that when I write my sections for the refer= ence model, they are consistent. :-)

=C2=A0

In doing so, I have a number of questions on RFC7575. = Part of this may be my academic nature, part may be because I have undoubte= dly missed something in past emails as I come up to speed, and partly because I'm likely under-caffeinated. H= opefully, some of this will help improve the reference model (and possibly = other documents as well).

=C2=A0

Questions on RFC7575
Page 3
"Autonomic functions can be defined in two ways:
=C2=A0 o On a node level: Nodes interact with each other to form feedback =C2=A0=C2=A0=C2=A0 loops.
=C2=A0 o On a system level: Feedback loops include central elements as
=C2=A0=C2=A0=C2=A0 well."
What is a "central element"? Does this mean that the feedback loo= p includes centralized management mechanisms, or that there is additional l= ogic outside of just the nodes?

= =C2=A0

= MB: A central element is a controller for e= xample. The point of the section is: You could define an =E2=80=9Cautonomic network=E2=80=9D where every node has exactly the same interfaces as today= (primarily CLI, SNMP, NETCONF), and where a controller is involved in all = control loops. Our definition of =E2=80=9Cautonomic=E2=80=9D is further dow= n in the network, where nodes interact directly with nodes. Now we all understand this isn=E2=80=99t black and white, but the emphasis= of the work in the IETF should be node-to-node interactions.

=C2=A0

Page 5, definition of intent
Why is intent scoped to a single autonomic domain?

=C2=A0

= MB: Intent isn=E2=80=99t a policy language = like most other, where you can essentially define a policy for every networ= k element separately. The fundamental idea is that there is one intent for t= he entire network. Thus this definition.

= My personal opinion: If we let Intent slip = into the element management scope, we=E2=80=99ve missed an opportunity. Int= ent is a policy on network scope.

= =C2=A0

Page 5, definition of autonomic domain
Why is autonomic domain tied to intent as the only management paradigm? The= vast majority of work in autonomic networking does NOT use intent (what I = call declarative logic, I failed marketing :-) ). I completely agree with u= sing intent, and perhaps even emphasizing it, but I don't agree with excluding other management paradigms.

=C2=A0

= MB: Probably a question of wording. In my r= eading you have 1) autonomic default behaviour (could also call this =E2=80=9Cdefault intent=E2=80=9D), 2) Intent, and 3) traditional managemen= t schemes, such as NETCONF, SNMP, CLI, etc=E2=80=A6=C2=A0

= So we don=E2=80=99t exclude other managemen= t paradigms, they are handles in section 3.2. Is that what you mean?

= (You could also define an autonomic domain = by the zone of trust of the certificates.)

= =C2=A0

Page 5, self-management
"They configure themselves, based on self-knowledge, discovery, and In= tent."
The word "discovery" is confusing me. Suppose a node runs a utili= ty function to decide what its next configuration change should be. It is n= ot "discovering" something that existed - rather, it is computing= new knowledge. A machine learning function that infers new knowledge is an even better example of something that is not "dis= covered". I'm probably missing something, but why was this choice = made?

The thing that really bothers me is that this assumes = that all knowledge can be discovered - that is, it is existing, like an app= le on a tree, ready to be plucked. In the autonomic systems that I've built, this is only sometimes the case= . It is vital for an autonomic system to be able to learn new knowledge via= computation and inference, as well as decide that previous knowledge was i= ncorrect. Neither of these are discovery functions.

= =C2=A0

= MB: I think the confusion is the definition= of =E2=80=9Cdiscovery=E2=80=9D here. It=E2=80=99s not only discovery in th= e sense of service discovery, but for example, finding neighbors, negotiating parameters with= them, etc.

= The above phrase in other words: =E2=80=9CI= know my capabilities, I see what else is there (and talk to it potentially= ), and I see what the boss wants to happen (intent). Based on all of this I d= ecide what I=E2=80=99m going to do=E2=80=9D.

= I think it=E2=80=99s a question of wording.= We had this graphic (similar to figure 1), where there are the 3 input vec= tors (!) of information, on which you base your decisions. The inference you me= ntion is a consequence of those inputs. In other words, the =E2=80=9Cbrain= =E2=80=9D that actually makes the inference, is in our model the autonomic = service agent.

Does that make = sense?

= =C2=A0

Page 6, last paragraph above section 3.2
"...closed-loop control is an important aspect of self-managing system= s.

This implies peer-to-peer dialogues between the partie= s that make up

the closed loop. Such dialogues require two-way "= discussion" or "negotiation"

between each pair or groups of peers involved in the l= oop,..."
First, by "peer", I assume you mean two (or more) equipotent enti= ties that make some portion of their resources available to others. Second,= and more importantly, a closed control loop does not require each entity i= n the closed control loop to talk to negotiate with other entities. Now, in an autonomic control loop, this could very we= ll be the case, but it is unclear to me why it MUST be the case. The obviou= s nightmare scenario is that the negotiation fails. Then what - we have no = control loop at all?

=C2=A0

= MB: I guess your point is that an autonomic= process doesn=E2=80=99t HAVE to have a control loop. I would argue that th= e typical autonomic function DOES have node-to-node interactions. This is wh= at autonomics is all about. Now, yes, there will be cases where this fails,= and where a node also needs to do something sensible in case of complete i= solation. But that=E2=80=99s an exception state in my mind.

= =C2=A0

Pages 7-8, Section 3.6
Most autonomic networking systems to date have NOT been built with an inten= t (or declarative) style interface. FOCALE enables declarative and prescrip= tive (e.g., ECA policy rules) to be used. Others just use ECA (or an equiva= lent) paradigm. Hence, I'm wondering why intent is the ONLY paradigm that is mentioned in this RFC that is suit= able for autonomic networking? Shouldn't we try and peacefully coexist,= just as the nodes are peacefully coexisting with non-autonomic directives?=

=C2=A0

= MB: To me, ECA is encoded in an ASA or an a= utonomic function. The function says what action you take in specific events, and under which condition.

= Example: The =E2=80=9Cenrolment proxy ASA= =E2=80=9D has the following (hard coded) ESA:

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Event: A new node is det= ected

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Condition: it doesn=E2= =80=99t have a domain cert yet

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Action: I invite the nod= e to join my network.

= Now, Intent is in my mind a higher level co= ncept which could now state =E2=80=9Cdo not enrol new nodes at this moment= =E2=80=9D.

= How would you see that?

= =C2=A0

Page 9, section 3.7
"However, in an Autonomic Network, reporting should happen on a networ= k-wide basis."

True, but shouldn't individual nodes and collectio= ns of nodes still report? That isn't implied in the wording.<= /u>

= =C2=A0

= MB: Yes, they should. This is =E2=80=9Ctrad= itional management methods=E2=80=9D. In our model, every node does the norm= al syslog, etc., and aggregated reporting is the new thing that comes with AN.

= =C2=A0

Furthermore, the last paragraph says: "Autonomic = network events should concern the Autonomic Network as a whole, not individ= ual systems in isolation." I agree that the goal is to report on the system as a whole, but isn't such a report co= llected from individual nodes? Just like in your example, the nodes need to= be able to see that a problem has already been reported in order to know n= ot to issue the same problem.

=C2=A0

= MB: There are two parallel methods of repor= ting:

1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the traditional every-no= de-to-controller method, where the intelligence is central

2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a distributed reporting = function, where nodes aggregate, process, summarise, correlate, =E2=80=A6 =C2=A0information before handing it to the controller. Here the = intelligence is distributed.

= Both will co-exist. The RFC focuses on the = new method (and obviously isn=E2=80=99t clear enough about it=E2=80=A6)

= =C2=A0

Pages 12-13, section 5
Why is an Autonomic **User** Agent the interface to a control loop? I can s= ee an external entity wanting to configure and monitor the control loop, bu= t why wouldn't the User Agent talk to the Service Agent to do this? I d= o note that this figure is under discussion and being revised in the reference model.

=C2=A0

= MB: Yes, that=E2=80=99s confusing wording, = and now that you mention it, yes we should have probably looked for a bette= r term. The idea is: The =E2=80=9Cintelligence=E2=80=9D of an autonomic func= tion is in the ASA (middle of figure 1). There are now horizontal feedback = loops and northbound feedback loops. For example, there is likely a functio= n in the enrolment process, where a message gets sent to the admin: =E2=80=9CHere=E2=80=99s a new node, I don=E2=80=99t thi= nk it belongs into our network, I=E2=80=99ve quarantined that node for now;= would you like me to 1) accept the node anyway, or 2) mark it as bad?=E2= =80=9D

= =C2=A0

= I agree the term =E2=80=9Cuser agent=E2=80= =9D is not good. We need to find a better one. Suggestions?

= =C2=A0

Page 13, Figure 1
Where is the Autonomic Node in the Reference Model? I do note that this fig= ure is under discussion and being revised in the reference model. However, = even in Figure 2 of the reference model, it is still unclear what the "= ;node" is. But more on that later.

MB: The whole = thing is the node. That=E2=80=99s why the figure is called =E2=80=9CReferen= ce Model for an Autonomic Node=E2=80=9D.

=C2=A0

Thanks for all = your input John! Let=E2=80=99s make sure that all these points get addresse= d in the reference model.

=C2=A0

Michael<= /font>
--

regards,

John




--
regards,
John
--047d7bb03f9cdeff2505192530e7-- From nobody Mon Jun 22 19:47:33 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE071B322D for ; Mon, 22 Jun 2015 19:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIu_MX5Y7vRd for ; Mon, 22 Jun 2015 19:47:30 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::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 442D71B322B for ; Mon, 22 Jun 2015 19:47:30 -0700 (PDT) Received: by wgbhy7 with SMTP id hy7so156089701wgb.2 for ; Mon, 22 Jun 2015 19:47:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kcQdm1UJDLbsAzXfBJX+z4NzkRQNcU70U/fVOqMT0e0=; b=vEgoTvGMBaFY8PjPKwCjMLR0KBu8XvZUhdqKD6aa2g7DbdKMAfaeGLhlRxXos8Kf2g ET5MhybwFiTCwp+MRoXsvuXkbgpenC9UW3fUx+qoodSREnv312//NFyN+LfnY4io0lri TyHxVoiRRe2iXZsU1rrL8iu17pT/bVzCj5fLi49c3O60J/fFJPTyFCuQpJpbxwSuEXM4 EI1y2Y87OcBglLad6wlPnsWqhJI9gU6WqLcAUb411v27cZO2Uvje4FRIR2tmnJMI+KTj rJPhAEur39wy2w78YLZYgxlaQ4amY1sObuOr4U3e+iZWN77XlJvJ8VkZMJYqoEzrVx5E 8RUw== MIME-Version: 1.0 X-Received: by 10.180.109.136 with SMTP id hs8mr36937892wib.73.1435027649074; Mon, 22 Jun 2015 19:47:29 -0700 (PDT) Received: by 10.27.220.1 with HTTP; Mon, 22 Jun 2015 19:47:29 -0700 (PDT) In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0FAB@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0FAB@xmb-rcd-x14.cisco.com> Date: Mon, 22 Jun 2015 19:47:29 -0700 Message-ID: From: John Strassner To: "Michael Behringer (mbehring)" Content-Type: multipart/alternative; boundary=e89a8f234557441b4c05192669ac Archived-At: Cc: Anima WG Subject: Re: [Anima] Common Ground on the ACP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jun 2015 02:47:32 -0000 --e89a8f234557441b4c05192669ac Content-Type: text/plain; charset=UTF-8 Hi Michael, I agree with all of your points. For 4, I hope we get to a point where we can treat the interface to an ACP more like an Abstract Data Type, and then add additional requirements to it. However, any that I can think of right now would simply strengthen the MUST (and MUST NOT) that you have already specified here. For 5, you have a minor typo (they should be 5a and 5b). Shouldn't there be a 5c and a 5d, which are the E2E versions of 5a and 5b? regards, John On Mon, Jun 22, 2015 at 9:40 AM, Michael Behringer (mbehring) < mbehring@cisco.com> wrote: > ANIMA, > > Trying to get a new version of the ACP draft out later this week, I'm > trying to understand what we're all agreeing on, and what not. > > As I see it, the high level requirements (below) and the benefits would go > into the reference model, the details into the ACP draft. > > Requirements for an ACP: > > 1 - The ACP SHOULD provide robust connectivity > As far as possible, it should be independent of configured addressing, > configuration and routing. > (2 and 3 build on this requirement, but also have value on their own) > > 2 - The ACP MUST have a separate address space from the data plane. > Reason: traceability, debug-ability, separation from data plane, > security (can block at edge) > > 3 - The ACP MUST use autonomically managed address space > Reason: easy bootstrap and setup ("autonomic"); robustness (admin can't > mess things up so easily). > > I think we agreed: ULA seems like a good choice for 1 and 2. > > 4 - The ACP MUST be generic > Usable by all the functions and protocols of the AN infrastructure. > MUST NOT be tied to a particular protocol. > > 5- The ACP MUST provide security: > Messages coming through the ACP are authenticated to be from a trusted > node, and encrypted. > > 4a - MUST: ACP Hop-by-hop authentication > 4b - SHOULD: ACP Hop-by-hop encryption > > Do we agree on those requirements? > > Michael > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > -- regards, John --e89a8f234557441b4c05192669ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Michael,

I agree with all= of your points.

For 4, I hope we get to a point w= here we can treat the interface to an ACP more like an Abstract Data Type, = and then add additional requirements to it. However, any that I can think o= f right now would simply strengthen the MUST (and MUST NOT) that you have a= lready specified here.

For 5, you have a minor typ= o (they should be 5a and 5b). Shouldn't there be a 5c and a 5d, which a= re the E2E versions of 5a and 5b?

regards,
John

On Mon, Jun 22, 2015 at 9:40 AM, Michael Behringer (mbehring) <mbehri= ng@cisco.com> wrote:
ANIMA,=

Trying to get a new version of the ACP draft out later this week, I'm t= rying to understand what we're all agreeing on, and what not.

As I see it, the high level requirements (below) and the benefits would go = into the reference model, the details into the ACP draft.

Requirements for an ACP:

1 - The ACP SHOULD provide robust connectivity
=C2=A0 =C2=A0As far as possible, it should be independent of configured add= ressing, configuration and routing.
=C2=A0 =C2=A0(2 and 3 build on this requirement, but also have value on the= ir own)

2 - The ACP MUST have a separate address space from the data plane.
=C2=A0 =C2=A0Reason: traceability, debug-ability, separation from data plan= e, security (can block at edge)

3 - The ACP MUST use autonomically managed address space
=C2=A0 =C2=A0Reason: easy bootstrap and setup ("autonomic"); robu= stness (admin can't mess things up so easily).

=C2=A0 =C2=A0I think we agreed: ULA seems like a good choice for 1 and 2.
4 - The ACP MUST be generic
=C2=A0 =C2=A0Usable by all the functions and protocols of the AN infrastruc= ture. MUST NOT be tied to a particular protocol.

5- The ACP MUST provide security:
=C2=A0 =C2=A0Messages coming through the ACP are authenticated to be from a= trusted node, and encrypted.

=C2=A0 =C2=A04a - MUST: ACP Hop-by-hop authentication
=C2=A0 =C2=A04b - SHOULD: ACP Hop-by-hop encryption

Do we agree on those requirements?

Michael

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



--
regards,
John
--e89a8f234557441b4c05192669ac-- From nobody Mon Jun 22 23:13:49 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7D081A88B9 for ; Mon, 22 Jun 2015 23:13:47 -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 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 6Oe7n30bjP5v for ; Mon, 22 Jun 2015 23:13:46 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (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 E97FE1A88B8 for ; Mon, 22 Jun 2015 23:13:45 -0700 (PDT) Received: by pdbci14 with SMTP id ci14so64535pdb.2 for ; Mon, 22 Jun 2015 23:13:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=NraTyDt7dFXMC4quTJYZDg4YEZtCXexoKnDnJUFQsXM=; b=s5Fx7JaF6ztoOsOxnaVe1bNikdpRj3IDnJQ1dGB6qUCW6CirHKB5Bjfc4AJjgqaX1b konCRYMa7xdfr2neCgwCN2FVxoJThusunFRwrF3LmZIxjertmxRAd7eYJHwmN8SEXRic pQK7sWtBFFSu4rVcLHTQxdRnMdMO43Y0QW03i+84jEtq1Kb/6D+ZeLCYHwQSvKaApnLT qwykYDu626MaA0gR4DDlcPprHl1I2RGF243Sm4Bi+E72IKrR7f5RPe4Bl0qsQebTV422 EdLG95V2Ecf6IreDNfrpfr9pwVepyDPQJlc0G0oo89XSRvY2getc6OJDHzdyUTB9botm DH4w== X-Received: by 10.70.135.168 with SMTP id pt8mr66108521pdb.8.1435040025526; Mon, 22 Jun 2015 23:13:45 -0700 (PDT) Received: from [172.20.3.93] ([119.17.32.167]) by mx.google.com with ESMTPSA id ks9sm21902381pdb.36.2015.06.22.23.13.41 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jun 2015 23:13:43 -0700 (PDT) Message-ID: <5588F90B.40605@gmail.com> Date: Tue, 23 Jun 2015 18:13:31 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Toerless Eckert References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0FAB@xmb-rcd-x14.cisco.com> <55887E55.9000207@gmail.com> <20150623004227.GA27886@cisco.com> In-Reply-To: <20150623004227.GA27886@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima WG , "Michael Behringer \(mbehring\)" Subject: Re: [Anima] Common Ground on the ACP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jun 2015 06:13:48 -0000 On 23/06/2015 12:42, Toerless Eckert wrote: > Brian: These are intertwined: > > Lets just start assuming end-to-end encryption is good enough. I was talking about requirements. The requirement is that third parties can't read the traffic. That's an end-to-end requirement. The solution might be hop-by-hop but that's a separate discussion, That's all I meant to say. (However, in general, hop-by-hop decryption and re-encryption increases the attack surface for a bad actor. So if hop-by-hop is simpler to implement, there is a security trade-off. But that's a design discussion, not a requirements discussion.) One more comment at the end... > How do we create between ASAs security associations. We definitely would > like that not every ASA needs to build out a separate security stack. > > So ultimately, this would require you to either figure out network wide > group-keys or something like up to a full-mesh of p2p keys (eg: via IKE). > That can easily lead to a big chunk of key negotiations. And when we > looked at HW keys, then #SAs is usually the limit on HW platforms. Some > platforms meant to be big VPN headens may have enough to do this, most > network devices won't. > > And with just end-to-end, you still haven't eliminated injection of > DoS traffic to just overload long network paths: Because only the ultimate > receiver will be able to authenticate and reject the packets. > > Thats about the point when you start to love hop-by-hop security. Which > is by the way also the argument used by 802.1ae, which is also hop-by-hop. > And which os by the way a quite attractive option to use for ACP IMHO. > > So when you're back disecting hop-by-hop security, you have authentication > and encryption. To the best of my knowledge, you can have authentication > without encryption, but not the other way around. Or rather: when you > can decrypt, authentication was implied. Which is why we can't turn > MUST/SHOULD around. Indeed not. But if you are seriously worried about, e.g., enemy backdoors in your network, it will be MUST/MUST. (I've just finished reading Bruce Schneier's book, and it certainly makes one think about this topic.) Brian > Cheers > Toerless > > > On Tue, Jun 23, 2015 at 09:29:57AM +1200, Brian E Carpenter wrote: >> Hi Michael, >> >> I pretty much agree, but >> >>> 4a - MUST: ACP Hop-by-hop authentication >>> 4b - SHOULD: ACP Hop-by-hop encryption >> >> I suppose these are meant to be 5a/b, but more substantively, is hop-by-hop >> a *requirement*? End-to-end is definitely required, but hop-by-hop seems >> like an implementation choice. >> >> My opinion is that in these days of pervasive surveillance, encryption >> is a very strong SHOULD indeed. >> >> Brian >> >> On 23/06/2015 04:40, Michael Behringer (mbehring) wrote: >>> ANIMA, >>> >>> Trying to get a new version of the ACP draft out later this week, I'm trying to understand what we're all agreeing on, and what not. >>> >>> As I see it, the high level requirements (below) and the benefits would go into the reference model, the details into the ACP draft. >>> >>> Requirements for an ACP: >>> >>> 1 - The ACP SHOULD provide robust connectivity >>> As far as possible, it should be independent of configured addressing, configuration and routing. >>> (2 and 3 build on this requirement, but also have value on their own) >>> >>> 2 - The ACP MUST have a separate address space from the data plane. >>> Reason: traceability, debug-ability, separation from data plane, security (can block at edge) >>> >>> 3 - The ACP MUST use autonomically managed address space >>> Reason: easy bootstrap and setup ("autonomic"); robustness (admin can't mess things up so easily). >>> >>> I think we agreed: ULA seems like a good choice for 1 and 2. >>> >>> 4 - The ACP MUST be generic >>> Usable by all the functions and protocols of the AN infrastructure. MUST NOT be tied to a particular protocol. >>> >>> 5- The ACP MUST provide security: >>> Messages coming through the ACP are authenticated to be from a trusted node, and encrypted. >>> >>> 4a - MUST: ACP Hop-by-hop authentication >>> 4b - SHOULD: ACP Hop-by-hop encryption >>> >>> Do we agree on those requirements? >>> >>> Michael >>> >>> _______________________________________________ >>> 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 Tue Jun 23 02:46:23 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 165331AC42C for ; Tue, 23 Jun 2015 02:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQxGLmAs3EUB for ; Tue, 23 Jun 2015 02:46:13 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 116E41ACAD5 for ; Tue, 23 Jun 2015 02:43:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16852; q=dns/txt; s=iport; t=1435052593; x=1436262193; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=m8rd5HYHNOlPrPY/s/+YgA0RVQ70/SqJeFzqC1vKVOs=; b=Q+0CLus1Yu62BLOk8o3q0mVXE851E8/8WwqgxoU6oBP2VIDy242O4xHg 3S3YQvqQ5tiifm5dW6iAqS4S/9urd4jMCT7ju5/dr34rXwlMDxHgzw9ac J6KPh/2Q1wKhtI/5BH//4LR/sstXO/hLWY04B6Uqb8Ec2XWxAZZ+nMSQZ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DvAwDVKIlV/4oNJK1bgkVLVF8Ggxi5WmYJgVwBCYV4AhyBJzgUAQEBAQEBAYEKhCIBAQEEAQEBIApBCxACAQgOAwQBAQsdAwICAh8GCxQJCAEBBA4FCIgSAxINtT+QVQ2FbQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi0qCTYFWEQEgLQQGAYJoL4EUBZN/AYlvgxuPY4M9g1smY4MXb4EMOoECAQEB X-IronPort-AV: E=Sophos;i="5.13,665,1427760000"; d="scan'208,217";a="5804674" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-4.cisco.com with ESMTP; 23 Jun 2015 09:43:12 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t5N9hCKN029661 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Jun 2015 09:43:12 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.179]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Tue, 23 Jun 2015 04:43:11 -0500 From: "Michael Behringer (mbehring)" To: John Strassner Thread-Topic: [Anima] Common Ground on the ACP Thread-Index: AdCp2kWzuNSXI7ELQ66smCIeol/FLQDrpT+AAAFaZpA= Date: Tue, 23 Jun 2015 09:43:11 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF2677@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0FAB@xmb-rcd-x14.cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.33] Content-Type: multipart/alternative; boundary="_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FF2677xmbrcdx14ciscoc_" MIME-Version: 1.0 Archived-At: Cc: Anima WG Subject: Re: [Anima] Common Ground on the ACP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jun 2015 09:46:18 -0000 --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FF2677xmbrcdx14ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW5saW5l4oCmDQoNCkZyb206IEpvaG4gU3RyYXNzbmVyIFttYWlsdG86c3RyYXpwZGpAZ21haWwu Y29tXQ0KU2VudDogMjMgSnVuZSAyMDE1IDA0OjQ3DQpUbzogTWljaGFlbCBCZWhyaW5nZXIgKG1i ZWhyaW5nKQ0KQ2M6IEFuaW1hIFdHDQpTdWJqZWN0OiBSZTogW0FuaW1hXSBDb21tb24gR3JvdW5k IG9uIHRoZSBBQ1ANCg0KSGkgTWljaGFlbCwNCg0KSSBhZ3JlZSB3aXRoIGFsbCBvZiB5b3VyIHBv aW50cy4NCg0KRm9yIDQsIEkgaG9wZSB3ZSBnZXQgdG8gYSBwb2ludCB3aGVyZSB3ZSBjYW4gdHJl YXQgdGhlIGludGVyZmFjZSB0byBhbiBBQ1AgbW9yZSBsaWtlIGFuIEFic3RyYWN0IERhdGEgVHlw ZQ0KDQpNQjogQ2FuIHlvdSBleHBhbmQgaGVyZT8gTm90IHN1cmUgSSB1bmRlcnN0YW5kIHdoYXQg eW91IG1lYW4uDQoNCiwgYW5kIHRoZW4gYWRkIGFkZGl0aW9uYWwgcmVxdWlyZW1lbnRzIHRvIGl0 LiBIb3dldmVyLCBhbnkgdGhhdCBJIGNhbiB0aGluayBvZiByaWdodCBub3cgd291bGQgc2ltcGx5 IHN0cmVuZ3RoZW4gdGhlIE1VU1QgKGFuZCBNVVNUIE5PVCkgdGhhdCB5b3UgaGF2ZSBhbHJlYWR5 IHNwZWNpZmllZCBoZXJlLg0KDQpGb3IgNSwgeW91IGhhdmUgYSBtaW5vciB0eXBvICh0aGV5IHNo b3VsZCBiZSA1YSBhbmQgNWIpLiBTaG91bGRuJ3QgdGhlcmUgYmUgYSA1YyBhbmQgYSA1ZCwgd2hp Y2ggYXJlIHRoZSBFMkUgdmVyc2lvbnMgb2YgNWEgYW5kIDViPw0KDQpNQjogU2VlIHByZXZpb3Vz IGVtYWlsIHRvIEJyaWFuLiBJIHRoaW5rIHdl4oCZbGwgYWRkcmVzcyB0aGF0IGluIHRoZSBuZXcg dGV4dC4NCg0KTWljaGFlbA0KDQpyZWdhcmRzLA0KSm9obg0KDQpPbiBNb24sIEp1biAyMiwgMjAx NSBhdCA5OjQwIEFNLCBNaWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpIDxtYmVocmluZ0BjaXNj by5jb208bWFpbHRvOm1iZWhyaW5nQGNpc2NvLmNvbT4+IHdyb3RlOg0KQU5JTUEsDQoNClRyeWlu ZyB0byBnZXQgYSBuZXcgdmVyc2lvbiBvZiB0aGUgQUNQIGRyYWZ0IG91dCBsYXRlciB0aGlzIHdl ZWssIEknbSB0cnlpbmcgdG8gdW5kZXJzdGFuZCB3aGF0IHdlJ3JlIGFsbCBhZ3JlZWluZyBvbiwg YW5kIHdoYXQgbm90Lg0KDQpBcyBJIHNlZSBpdCwgdGhlIGhpZ2ggbGV2ZWwgcmVxdWlyZW1lbnRz IChiZWxvdykgYW5kIHRoZSBiZW5lZml0cyB3b3VsZCBnbyBpbnRvIHRoZSByZWZlcmVuY2UgbW9k ZWwsIHRoZSBkZXRhaWxzIGludG8gdGhlIEFDUCBkcmFmdC4NCg0KUmVxdWlyZW1lbnRzIGZvciBh biBBQ1A6DQoNCjEgLSBUaGUgQUNQIFNIT1VMRCBwcm92aWRlIHJvYnVzdCBjb25uZWN0aXZpdHkN CiAgIEFzIGZhciBhcyBwb3NzaWJsZSwgaXQgc2hvdWxkIGJlIGluZGVwZW5kZW50IG9mIGNvbmZp Z3VyZWQgYWRkcmVzc2luZywgY29uZmlndXJhdGlvbiBhbmQgcm91dGluZy4NCiAgICgyIGFuZCAz IGJ1aWxkIG9uIHRoaXMgcmVxdWlyZW1lbnQsIGJ1dCBhbHNvIGhhdmUgdmFsdWUgb24gdGhlaXIg b3duKQ0KDQoyIC0gVGhlIEFDUCBNVVNUIGhhdmUgYSBzZXBhcmF0ZSBhZGRyZXNzIHNwYWNlIGZy b20gdGhlIGRhdGEgcGxhbmUuDQogICBSZWFzb246IHRyYWNlYWJpbGl0eSwgZGVidWctYWJpbGl0 eSwgc2VwYXJhdGlvbiBmcm9tIGRhdGEgcGxhbmUsIHNlY3VyaXR5IChjYW4gYmxvY2sgYXQgZWRn ZSkNCg0KMyAtIFRoZSBBQ1AgTVVTVCB1c2UgYXV0b25vbWljYWxseSBtYW5hZ2VkIGFkZHJlc3Mg c3BhY2UNCiAgIFJlYXNvbjogZWFzeSBib290c3RyYXAgYW5kIHNldHVwICgiYXV0b25vbWljIik7 IHJvYnVzdG5lc3MgKGFkbWluIGNhbid0IG1lc3MgdGhpbmdzIHVwIHNvIGVhc2lseSkuDQoNCiAg IEkgdGhpbmsgd2UgYWdyZWVkOiBVTEEgc2VlbXMgbGlrZSBhIGdvb2QgY2hvaWNlIGZvciAxIGFu ZCAyLg0KDQo0IC0gVGhlIEFDUCBNVVNUIGJlIGdlbmVyaWMNCiAgIFVzYWJsZSBieSBhbGwgdGhl IGZ1bmN0aW9ucyBhbmQgcHJvdG9jb2xzIG9mIHRoZSBBTiBpbmZyYXN0cnVjdHVyZS4gTVVTVCBO T1QgYmUgdGllZCB0byBhIHBhcnRpY3VsYXIgcHJvdG9jb2wuDQoNCjUtIFRoZSBBQ1AgTVVTVCBw cm92aWRlIHNlY3VyaXR5Og0KICAgTWVzc2FnZXMgY29taW5nIHRocm91Z2ggdGhlIEFDUCBhcmUg YXV0aGVudGljYXRlZCB0byBiZSBmcm9tIGEgdHJ1c3RlZCBub2RlLCBhbmQgZW5jcnlwdGVkLg0K DQogICA0YSAtIE1VU1Q6IEFDUCBIb3AtYnktaG9wIGF1dGhlbnRpY2F0aW9uDQogICA0YiAtIFNI T1VMRDogQUNQIEhvcC1ieS1ob3AgZW5jcnlwdGlvbg0KDQpEbyB3ZSBhZ3JlZSBvbiB0aG9zZSBy ZXF1aXJlbWVudHM/DQoNCk1pY2hhZWwNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCkFuaW1hIG1haWxpbmcgbGlzdA0KQW5pbWFAaWV0Zi5vcmc8bWFp bHRvOkFuaW1hQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9hbmltYQ0KDQoNCg0KLS0NCnJlZ2FyZHMsDQpKb2huDQo= --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FF2677xmbrcdx14ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9 IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5JbmxpbmXigKY8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGli cmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48Zm9u dCBzaXplPSIyIiBmYWNlPSJUYWhvbWEiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztmb250LXdlaWdodDpib2xkIj5Gcm9tOjwvc3Bhbj48L2ZvbnQ+PC9iPjxmb250IHNp emU9IjIiIGZhY2U9IlRhaG9tYSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4NCiBKb2huIFN0cmFzc25lciBbbWFpbHRvOnN0cmF6cGRqQGdtYWlsLmNvbV0gPGJyPg0K PGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlNlbnQ6PC9zcGFuPjwvYj4gMjMgSnVu ZSAyMDE1IDA0OjQ3PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOjwv c3Bhbj48L2I+IE1pY2hhZWwgQmVocmluZ2VyIChtYmVocmluZyk8YnI+DQo8Yj48c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6PC9zcGFuPjwvYj4gQW5pbWEgV0c8YnI+DQo8Yj48c3Bh biBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDo8L3NwYW4+PC9iPiBSZTogW0FuaW1h XSBDb21tb24gR3JvdW5kIG9uIHRoZSBBQ1A8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQiPkhpIE1pY2hhZWwsPG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij5JIGFncmVlIHdpdGggYWxsIG9mIHlvdXIgcG9pbnRzLjxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Rm9yIDQsIEkg aG9wZSB3ZSBnZXQgdG8gYSBwb2ludCB3aGVyZSB3ZSBjYW4gdHJlYXQgdGhlIGludGVyZmFjZSB0 byBhbiBBQ1AgbW9yZSBsaWtlIGFuIEFic3RyYWN0IERhdGEgVHlwZTxmb250IGNvbG9yPSIjMWY0 OTdkIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9mb250 Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIg Y29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNh bGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NQjogQ2Fu IHlvdSBleHBhbmQgaGVyZT8gTm90IHN1cmUgSSB1bmRlcnN0YW5kIHdoYXQgeW91IG1lYW4uDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQg c2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+LCBhbmQgdGhlbiBhZGQgYWRk aXRpb25hbCByZXF1aXJlbWVudHMgdG8gaXQuIEhvd2V2ZXIsIGFueSB0aGF0IEkgY2FuIHRoaW5r IG9mIHJpZ2h0IG5vdyB3b3VsZCBzaW1wbHkgc3RyZW5ndGhlbiB0aGUgTVVTVCAoYW5kIE1VU1Qg Tk9UKSB0aGF0IHlvdSBoYXZlIGFscmVhZHkgc3BlY2lmaWVkDQogaGVyZS48bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZv bnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkZvciA1LCB5b3UgaGF2ZSBhIG1p bm9yIHR5cG8gKHRoZXkgc2hvdWxkIGJlIDVhIGFuZCA1YikuIFNob3VsZG4ndCB0aGVyZSBiZSBh IDVjIGFuZCBhIDVkLCB3aGljaCBhcmUgdGhlIEUyRSB2ZXJzaW9ucyBvZiA1YSBhbmQgNWI/PG86 cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxmb250IHNpemU9IjMiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBz aXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1COiBTZWUgcHJldmlvdXMgZW1haWwgdG8gQnJpYW4u IEkgdGhpbmsgd2XigJlsbCBhZGRyZXNzIHRoYXQgaW4gdGhlIG5ldyB0ZXh0Lg0KPG86cD48L286 cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIi IGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJD YWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWljaGFl bDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9u dCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9u dD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIz IiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5y ZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Kb2huPG86cD48L286cD48L3NwYW4+PC9mb250 PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQg c2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5PbiBNb24sIEp1biAyMiwgMjAxNSBhdCA5OjQwIEFN LCBNaWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpICZsdDs8YSBocmVmPSJtYWlsdG86bWJlaHJp bmdAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+bWJlaHJpbmdAY2lzY28uY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPkFOSU1BLDxicj4NCjxicj4NClRyeWluZyB0byBnZXQgYSBuZXcgdmVyc2lv biBvZiB0aGUgQUNQIGRyYWZ0IG91dCBsYXRlciB0aGlzIHdlZWssIEknbSB0cnlpbmcgdG8gdW5k ZXJzdGFuZCB3aGF0IHdlJ3JlIGFsbCBhZ3JlZWluZyBvbiwgYW5kIHdoYXQgbm90Ljxicj4NCjxi cj4NCkFzIEkgc2VlIGl0LCB0aGUgaGlnaCBsZXZlbCByZXF1aXJlbWVudHMgKGJlbG93KSBhbmQg dGhlIGJlbmVmaXRzIHdvdWxkIGdvIGludG8gdGhlIHJlZmVyZW5jZSBtb2RlbCwgdGhlIGRldGFp bHMgaW50byB0aGUgQUNQIGRyYWZ0Ljxicj4NCjxicj4NClJlcXVpcmVtZW50cyBmb3IgYW4gQUNQ Ojxicj4NCjxicj4NCjEgLSBUaGUgQUNQIFNIT1VMRCBwcm92aWRlIHJvYnVzdCBjb25uZWN0aXZp dHk8YnI+DQombmJzcDsgJm5ic3A7QXMgZmFyIGFzIHBvc3NpYmxlLCBpdCBzaG91bGQgYmUgaW5k ZXBlbmRlbnQgb2YgY29uZmlndXJlZCBhZGRyZXNzaW5nLCBjb25maWd1cmF0aW9uIGFuZCByb3V0 aW5nLjxicj4NCiZuYnNwOyAmbmJzcDsoMiBhbmQgMyBidWlsZCBvbiB0aGlzIHJlcXVpcmVtZW50 LCBidXQgYWxzbyBoYXZlIHZhbHVlIG9uIHRoZWlyIG93bik8YnI+DQo8YnI+DQoyIC0gVGhlIEFD UCBNVVNUIGhhdmUgYSBzZXBhcmF0ZSBhZGRyZXNzIHNwYWNlIGZyb20gdGhlIGRhdGEgcGxhbmUu PGJyPg0KJm5ic3A7ICZuYnNwO1JlYXNvbjogdHJhY2VhYmlsaXR5LCBkZWJ1Zy1hYmlsaXR5LCBz ZXBhcmF0aW9uIGZyb20gZGF0YSBwbGFuZSwgc2VjdXJpdHkgKGNhbiBibG9jayBhdCBlZGdlKTxi cj4NCjxicj4NCjMgLSBUaGUgQUNQIE1VU1QgdXNlIGF1dG9ub21pY2FsbHkgbWFuYWdlZCBhZGRy ZXNzIHNwYWNlPGJyPg0KJm5ic3A7ICZuYnNwO1JlYXNvbjogZWFzeSBib290c3RyYXAgYW5kIHNl dHVwICgmcXVvdDthdXRvbm9taWMmcXVvdDspOyByb2J1c3RuZXNzIChhZG1pbiBjYW4ndCBtZXNz IHRoaW5ncyB1cCBzbyBlYXNpbHkpLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtJIHRoaW5rIHdl IGFncmVlZDogVUxBIHNlZW1zIGxpa2UgYSBnb29kIGNob2ljZSBmb3IgMSBhbmQgMi48YnI+DQo8 YnI+DQo0IC0gVGhlIEFDUCBNVVNUIGJlIGdlbmVyaWM8YnI+DQombmJzcDsgJm5ic3A7VXNhYmxl IGJ5IGFsbCB0aGUgZnVuY3Rpb25zIGFuZCBwcm90b2NvbHMgb2YgdGhlIEFOIGluZnJhc3RydWN0 dXJlLiBNVVNUIE5PVCBiZSB0aWVkIHRvIGEgcGFydGljdWxhciBwcm90b2NvbC48YnI+DQo8YnI+ DQo1LSBUaGUgQUNQIE1VU1QgcHJvdmlkZSBzZWN1cml0eTo8YnI+DQombmJzcDsgJm5ic3A7TWVz c2FnZXMgY29taW5nIHRocm91Z2ggdGhlIEFDUCBhcmUgYXV0aGVudGljYXRlZCB0byBiZSBmcm9t IGEgdHJ1c3RlZCBub2RlLCBhbmQgZW5jcnlwdGVkLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDs0 YSAtIE1VU1Q6IEFDUCBIb3AtYnktaG9wIGF1dGhlbnRpY2F0aW9uPGJyPg0KJm5ic3A7ICZuYnNw OzRiIC0gU0hPVUxEOiBBQ1AgSG9wLWJ5LWhvcCBlbmNyeXB0aW9uPGJyPg0KPGJyPg0KRG8gd2Ug YWdyZWUgb24gdGhvc2UgcmVxdWlyZW1lbnRzPzxicj4NCjxicj4NCk1pY2hhZWw8YnI+DQo8YnI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkFu aW1hIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpBbmltYUBpZXRmLm9yZyI+QW5p bWFAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9hbmltYSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vYW5pbWE8L2E+PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PGJyPg0KPGJyIGNsZWFyPSJh bGwiPg0KPGJyPg0KLS0gPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+cmVnYXJkcyw8bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZv bnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdCI+Sm9objxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FF2677xmbrcdx14ciscoc_-- From nobody Tue Jun 23 02:46:34 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CED91ACCEE for ; Tue, 23 Jun 2015 02:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lp8yqihsU7ah for ; Tue, 23 Jun 2015 02:46:18 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C21371AC43B for ; Tue, 23 Jun 2015 02:43:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=132868; q=dns/txt; s=iport; t=1435052596; x=1436262196; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=R2s1g2rST+y310BMuyKSP/W6M2PeJ1jTlIfv5m0Ir9Q=; b=DPxBOQecJ1depJcLn7Y2I/hmdPeFVriSP/VCvXhfe8fNXcJKKgZIyYo/ sz250M+IzOSww/flWSWoHCSOYVE5rM5bCZdpqcKaMLBo0/On/sHuNNnVJ 2VrK3LB/1oCeZIyy59WgwhDY/WbgLhLr3IIcBtiyyohr0uEZk1bZB5vo1 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BfBQC4KYlV/49dJa1bgkVLVF8Ggxi5WohNAhyBJzsRAQEBAQEBAYEKhCIBAQEEGgEICjoGAgoQAgEIDgMEAQELFgEGAwICAh8RFAkIAgQOBQiIEgMStU2QVQ2FbQEBAQEBAQEBAQEBAQEBAQEBAQEBAReKSIECgT2BEIFnAQEfMQYBBoJiL4EUBYUcjmMBhTmBdYIEPYMbj2ODPYNbJoIMHIFSb4EMOoECAQEB X-IronPort-AV: E=Sophos;i="5.13,665,1427760000"; d="scan'208,217";a="162054468" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Jun 2015 09:43:14 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t5N9hE0Z022178 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Jun 2015 09:43:14 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.179]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Tue, 23 Jun 2015 04:43:14 -0500 From: "Michael Behringer (mbehring)" To: John Strassner Thread-Topic: [Anima] Questions on RFC7575 Thread-Index: AQHQrEesFqw6Ify300iTXQ4+kek8/J24oWbggAD/V4CAACPngA== Date: Tue, 23 Jun 2015 09:43:13 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF268A@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0F36@xmb-rcd-x14.cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.33] Content-Type: multipart/alternative; boundary="_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FF268Axmbrcdx14ciscoc_" MIME-Version: 1.0 Archived-At: Cc: Anima WG Subject: Re: [Anima] Questions on RFC7575 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jun 2015 09:46:33 -0000 --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FF268Axmbrcdx14ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogSm9obiBTdHJhc3NuZXIgW21haWx0bzpzdHJhenBkakBnbWFpbC5jb21dDQpb4oCmXQ0K UXVlc3Rpb25zIG9uIFJGQzc1NzUNClBhZ2UgMw0KIkF1dG9ub21pYyBmdW5jdGlvbnMgY2FuIGJl IGRlZmluZWQgaW4gdHdvIHdheXM6DQogIG8gT24gYSBub2RlIGxldmVsOiBOb2RlcyBpbnRlcmFj dCB3aXRoIGVhY2ggb3RoZXIgdG8gZm9ybSBmZWVkYmFjaw0KICAgIGxvb3BzLg0KICBvIE9uIGEg c3lzdGVtIGxldmVsOiBGZWVkYmFjayBsb29wcyBpbmNsdWRlIGNlbnRyYWwgZWxlbWVudHMgYXMN CiAgICB3ZWxsLiINCldoYXQgaXMgYSAiY2VudHJhbCBlbGVtZW50Ij8gRG9lcyB0aGlzIG1lYW4g dGhhdCB0aGUgZmVlZGJhY2sgbG9vcCBpbmNsdWRlcyBjZW50cmFsaXplZCBtYW5hZ2VtZW50IG1l Y2hhbmlzbXMsIG9yIHRoYXQgdGhlcmUgaXMgYWRkaXRpb25hbCBsb2dpYyBvdXRzaWRlIG9mIGp1 c3QgdGhlIG5vZGVzPw0KDQpNQjogQSBjZW50cmFsIGVsZW1lbnQgaXMgYSBjb250cm9sbGVyIGZv ciBleGFtcGxlLiBUaGUgcG9pbnQgb2YgdGhlIHNlY3Rpb24gaXM6IFlvdSBjb3VsZCBkZWZpbmUg YW4g4oCcYXV0b25vbWljIG5ldHdvcmvigJ0gd2hlcmUgZXZlcnkgbm9kZSBoYXMgZXhhY3RseSB0 aGUgc2FtZSBpbnRlcmZhY2VzIGFzIHRvZGF5IChwcmltYXJpbHkgQ0xJLCBTTk1QLCBORVRDT05G KSwgYW5kIHdoZXJlIGEgY29udHJvbGxlciBpcyBpbnZvbHZlZCBpbiBhbGwgY29udHJvbCBsb29w cy4gT3VyIGRlZmluaXRpb24gb2Yg4oCcYXV0b25vbWlj4oCdIGlzIGZ1cnRoZXIgZG93biBpbiB0 aGUgbmV0d29yaywgd2hlcmUgbm9kZXMgaW50ZXJhY3QgZGlyZWN0bHkgd2l0aCBub2Rlcy4gTm93 IHdlIGFsbCB1bmRlcnN0YW5kIHRoaXMgaXNu4oCZdCBibGFjayBhbmQgd2hpdGUsIGJ1dCB0aGUg ZW1waGFzaXMgb2YgdGhlIHdvcmsgaW4gdGhlIElFVEYgc2hvdWxkIGJlIG5vZGUtdG8tbm9kZSBp bnRlcmFjdGlvbnMuDQo8amNzPiBPSywgZ290IGl0LiBKdXN0IHRvIGVuc3VyZSwgaXMgaXQgZmFp ciB0byBzYXkgdGhhdCBhICJjZW50cmFsIGVsZW1lbnQiIGlzIG9uZSBpbiB3aGljaCBub24tYXV0 b25vbWljIGZ1bmN0aW9ucyBhcmUgdXNlZCB0aGF0IG1heSBhZmZlY3QgdGhlIGJlaGF2aW9yIG9m IGF1dG9ub21pYyBub2Rlcz8gPC9qY3M+DQpNQjI6IFRoaXMgaXMgY29ycmVjdCBidXQgbm90IGNv bXBsZXRlLiBCZWNhdXNlIGFsc28gYSBub3JtYWwgbm9kZSBoYXMgbm9uLWF1dG9ub21pYyBmdW5j dGlvbnMgdGhhdCBtYXkgYWZmZWN0IHRoZSBiZWhhdmlvdXIgb2YgdGhhdCBub2RlIChvciBvdGhl cnMpLg0KUGFnZSA1LCBkZWZpbml0aW9uIG9mIGludGVudA0KV2h5IGlzIGludGVudCBzY29wZWQg dG8gYSBzaW5nbGUgYXV0b25vbWljIGRvbWFpbj8NCg0KTUI6IEludGVudCBpc27igJl0IGEgcG9s aWN5IGxhbmd1YWdlIGxpa2UgbW9zdCBvdGhlciwgd2hlcmUgeW91IGNhbiBlc3NlbnRpYWxseSBk ZWZpbmUgYSBwb2xpY3kgZm9yIGV2ZXJ5IG5ldHdvcmsgZWxlbWVudCBzZXBhcmF0ZWx5LiBUaGUg ZnVuZGFtZW50YWwgaWRlYSBpcyB0aGF0IHRoZXJlIGlzIG9uZSBpbnRlbnQgZm9yIHRoZSBlbnRp cmUgbmV0d29yay4gVGh1cyB0aGlzIGRlZmluaXRpb24uDQpNeSBwZXJzb25hbCBvcGluaW9uOiBJ ZiB3ZSBsZXQgSW50ZW50IHNsaXAgaW50byB0aGUgZWxlbWVudCBtYW5hZ2VtZW50IHNjb3BlLCB3 ZeKAmXZlIG1pc3NlZCBhbiBvcHBvcnR1bml0eS4gSW50ZW50IGlzIGEgcG9saWN5IG9uIG5ldHdv cmsgc2NvcGUuDQo8amNzPiBIZXJlIHlvdSBsb3N0IG1lLiBPREwgR0JQIGFuZCBPREwgTklDLCBP cGVuU3RhY2sgQ29uZ3Jlc3MsIHNvbWUgbmFzY2VudCB3b3JrIGluIHRoZSBPTkYsIGFuZCBUTUYg Wk9PTSB3b3VsZCBhbGwgZGlzYWdyZWUuIEludGVudCwgZm9yIGJldHRlciBvciB3b3JzZSwgaGFz IGJlZW4gY2hhcmFjdGVyaXplZCBhcyBUaGUgTmV3IFBvbGljeSAobm8gb2ZmZW5zZSB0byBMaWdo dCBSZWFkaW5nKS4gQnV0IHRoZW4gYXQgdGhlIGVuZCB5b3Ugc2F5ICJJbnRlbnQgaXMgYSBwb2xp Y3kgb24gbmV0d29yayBzY29wZSIsIHNvIG1heWJlIEknbSByZWFkaW5nIHlvdSB0b28gbGl0ZXJh bGx5PyAoc2VlIEkgaGF2ZW4ndCBjaGFuZ2VkIHNpbmNlIG15IENpc2NvIGRheXMgOi0pICkuDQpN QjI6IEkga25vdywgbG90cyBvZiBncm91cHMgaGF2ZSBieSBub3cgcGlja2VkIHVwIHRoZSDigJxp bnRlbnTigJ0gd29yZCwgYW5kIHNpbmNlIHdlIG5ldmVyIHJlYWxseSBkZWZpbmVkIGl0IGluIGRl dGFpbCwgaXQgbm93IG1lYW5zIGFueXRoaW5nIHRvIGFueW9uZS4gKEkgdGhpbmsg4oCTIGhvcGVm dWxseSBJ4oCZbSB3cm9uZykuIFdlIHNob3VsZCBkaXNjdXNzIHRoaXMgaW4gUHJhZ3VlLg0KUGx1 cywgZG8geW91IHJlYWxseSBtZWFuICJmb3IgdGhlIGVudGlyZSBuZXR3b3JrIj8gSXNuJ3QgImZv ciBhIGdpdmVuIHNldCBvZiBhZG1pbmlzdHJhdGl2ZSBkb21haW5zIiBnb29kIGVub3VnaD8gPC9q Y3M+DQogTUIyOiBkb21haW4gaXMgdGhlIHJpZ2h0IHRlcm0uDQpQYWdlIDUsIGRlZmluaXRpb24g b2YgYXV0b25vbWljIGRvbWFpbg0KV2h5IGlzIGF1dG9ub21pYyBkb21haW4gdGllZCB0byBpbnRl bnQgYXMgdGhlIG9ubHkgbWFuYWdlbWVudCBwYXJhZGlnbT8gVGhlIHZhc3QgbWFqb3JpdHkgb2Yg d29yayBpbiBhdXRvbm9taWMgbmV0d29ya2luZyBkb2VzIE5PVCB1c2UgaW50ZW50ICh3aGF0IEkg Y2FsbCBkZWNsYXJhdGl2ZSBsb2dpYywgSSBmYWlsZWQgbWFya2V0aW5nIDotKSApLiBJIGNvbXBs ZXRlbHkgYWdyZWUgd2l0aCB1c2luZyBpbnRlbnQsIGFuZCBwZXJoYXBzIGV2ZW4gZW1waGFzaXpp bmcgaXQsIGJ1dCBJIGRvbid0IGFncmVlIHdpdGggZXhjbHVkaW5nIG90aGVyIG1hbmFnZW1lbnQg cGFyYWRpZ21zLg0KDQpNQjogUHJvYmFibHkgYSBxdWVzdGlvbiBvZiB3b3JkaW5nLiBJbiBteSBy ZWFkaW5nIHlvdSBoYXZlIDEpIGF1dG9ub21pYyBkZWZhdWx0IGJlaGF2aW91ciAoY291bGQgYWxz byBjYWxsIHRoaXMg4oCcZGVmYXVsdCBpbnRlbnTigJ0pLCAyKSBJbnRlbnQsIGFuZCAzKSB0cmFk aXRpb25hbCBtYW5hZ2VtZW50IHNjaGVtZXMsIHN1Y2ggYXMgTkVUQ09ORiwgU05NUCwgQ0xJLCBl dGPigKYNClNvIHdlIGRvbuKAmXQgZXhjbHVkZSBvdGhlciBtYW5hZ2VtZW50IHBhcmFkaWdtcywg dGhleSBhcmUgaGFuZGxlcyBpbiBzZWN0aW9uIDMuMi4gSXMgdGhhdCB3aGF0IHlvdSBtZWFuPw0K KFlvdSBjb3VsZCBhbHNvIGRlZmluZSBhbiBhdXRvbm9taWMgZG9tYWluIGJ5IHRoZSB6b25lIG9m IHRydXN0IG9mIHRoZSBjZXJ0aWZpY2F0ZXMuKQ0KPGpjcz4gWWVzLiBOb3RlIHRoYXQgaW4gU1VQ QSwgd2UgZGVyaXZlIGludGVudCBhbmQgdHJhZGl0aW9uYWwgKGkuZS4sIEVDQSkgZnJvbSB0aGUg c2FtZSBQb2xpY3kgaW5mbyBtb2RlbC4gVGhpcyBoYXMgdGhlIG5pY2UgcHJvcGVydHkgb2YgbGV0 dGluZyBpbnRlbnQgdHJhbnNsYXRlIGFjcm9zcyBhY3RvcnMgYW5kIGJlIHVzZWQgdG8gZmlyZSBF Q0EgcG9saWNpZXMgKGFuZCB2aWNlIHZlcnNhKS4gPC9qY3M+DQogTUIyOiBOZWVkIHRvIGRpc2N1 c3MgdGhpcyBpbiBtb3JlIGRldGFpbCwgaW4gUHJhZ3VlIDstKQ0KUGFnZSA1LCBzZWxmLW1hbmFn ZW1lbnQNCiJUaGV5IGNvbmZpZ3VyZSB0aGVtc2VsdmVzLCBiYXNlZCBvbiBzZWxmLWtub3dsZWRn ZSwgZGlzY292ZXJ5LCBhbmQgSW50ZW50LiINClRoZSB3b3JkICJkaXNjb3ZlcnkiIGlzIGNvbmZ1 c2luZyBtZS4gU3VwcG9zZSBhIG5vZGUgcnVucyBhIHV0aWxpdHkgZnVuY3Rpb24gdG8gZGVjaWRl IHdoYXQgaXRzIG5leHQgY29uZmlndXJhdGlvbiBjaGFuZ2Ugc2hvdWxkIGJlLiBJdCBpcyBub3Qg ImRpc2NvdmVyaW5nIiBzb21ldGhpbmcgdGhhdCBleGlzdGVkIC0gcmF0aGVyLCBpdCBpcyBjb21w dXRpbmcgbmV3IGtub3dsZWRnZS4gQSBtYWNoaW5lIGxlYXJuaW5nIGZ1bmN0aW9uIHRoYXQgaW5m ZXJzIG5ldyBrbm93bGVkZ2UgaXMgYW4gZXZlbiBiZXR0ZXIgZXhhbXBsZSBvZiBzb21ldGhpbmcg dGhhdCBpcyBub3QgImRpc2NvdmVyZWQiLiBJJ20gcHJvYmFibHkgbWlzc2luZyBzb21ldGhpbmcs IGJ1dCB3aHkgd2FzIHRoaXMgY2hvaWNlIG1hZGU/DQpUaGUgdGhpbmcgdGhhdCByZWFsbHkgYm90 aGVycyBtZSBpcyB0aGF0IHRoaXMgYXNzdW1lcyB0aGF0IGFsbCBrbm93bGVkZ2UgY2FuIGJlIGRp c2NvdmVyZWQgLSB0aGF0IGlzLCBpdCBpcyBleGlzdGluZywgbGlrZSBhbiBhcHBsZSBvbiBhIHRy ZWUsIHJlYWR5IHRvIGJlIHBsdWNrZWQuIEluIHRoZSBhdXRvbm9taWMgc3lzdGVtcyB0aGF0IEkn dmUgYnVpbHQsIHRoaXMgaXMgb25seSBzb21ldGltZXMgdGhlIGNhc2UuIEl0IGlzIHZpdGFsIGZv ciBhbiBhdXRvbm9taWMgc3lzdGVtIHRvIGJlIGFibGUgdG8gbGVhcm4gbmV3IGtub3dsZWRnZSB2 aWEgY29tcHV0YXRpb24gYW5kIGluZmVyZW5jZSwgYXMgd2VsbCBhcyBkZWNpZGUgdGhhdCBwcmV2 aW91cyBrbm93bGVkZ2Ugd2FzIGluY29ycmVjdC4gTmVpdGhlciBvZiB0aGVzZSBhcmUgZGlzY292 ZXJ5IGZ1bmN0aW9ucy4NCg0KTUI6IEkgdGhpbmsgdGhlIGNvbmZ1c2lvbiBpcyB0aGUgZGVmaW5p dGlvbiBvZiDigJxkaXNjb3ZlcnnigJ0gaGVyZS4gSXTigJlzIG5vdCBvbmx5IGRpc2NvdmVyeSBp biB0aGUgc2Vuc2Ugb2Ygc2VydmljZSBkaXNjb3ZlcnksIGJ1dCBmb3IgZXhhbXBsZSwgZmluZGlu ZyBuZWlnaGJvcnMsIG5lZ290aWF0aW5nIHBhcmFtZXRlcnMgd2l0aCB0aGVtLCBldGMuDQpUaGUg YWJvdmUgcGhyYXNlIGluIG90aGVyIHdvcmRzOiDigJxJIGtub3cgbXkgY2FwYWJpbGl0aWVzLCBJ IHNlZSB3aGF0IGVsc2UgaXMgdGhlcmUgKGFuZCB0YWxrIHRvIGl0IHBvdGVudGlhbGx5KSwgYW5k IEkgc2VlIHdoYXQgdGhlIGJvc3Mgd2FudHMgdG8gaGFwcGVuIChpbnRlbnQpLiBCYXNlZCBvbiBh bGwgb2YgdGhpcyBJIGRlY2lkZSB3aGF0IEnigJltIGdvaW5nIHRvIGRv4oCdLg0KSSB0aGluayBp dOKAmXMgYSBxdWVzdGlvbiBvZiB3b3JkaW5nLiBXZSBoYWQgdGhpcyBncmFwaGljIChzaW1pbGFy IHRvIGZpZ3VyZSAxKSwgd2hlcmUgdGhlcmUgYXJlIHRoZSAzIGlucHV0IHZlY3RvcnMgKCEpIG9m IGluZm9ybWF0aW9uLCBvbiB3aGljaCB5b3UgYmFzZSB5b3VyIGRlY2lzaW9ucy4gVGhlIGluZmVy ZW5jZSB5b3UgbWVudGlvbiBpcyBhIGNvbnNlcXVlbmNlIG9mIHRob3NlIGlucHV0cy4gSW4gb3Ro ZXIgd29yZHMsIHRoZSDigJxicmFpbuKAnSB0aGF0IGFjdHVhbGx5IG1ha2VzIHRoZSBpbmZlcmVu Y2UsIGlzIGluIG91ciBtb2RlbCB0aGUgYXV0b25vbWljIHNlcnZpY2UgYWdlbnQuDQpEb2VzIHRo YXQgbWFrZSBzZW5zZT8NCjxqY3M+IEkgdGhpbmsgc28uIEkgc3RpbGwgdGhpbmsgdGhhdCBteSB0 d28gZXhhbXBsZXMgYXJlIG5vdCBkaXNjb3ZlcnkuIEkgaGFkIHNvbWVob3cgY29uY2x1ZGVkIHRo YXQgZGlzY292ZXJ5IHdhcyBhbGwtaW5jbHVzaXZlLCBidXQgd2hlbiBJIGxvb2sgYXQgeW91ciBh bnN3ZXIsIEkgcmVhbGl6ZSB0aGF0IGl0IGlzbid0LiBTdGlsbCwgaW4gdGhlIHJlZmVyZW5jZSBk b2N1bWVudCwgSSB0aGluayB3ZSBzaG91bGQgcG9pbnQgdGhpcyBvdXQuIEkgZG8gYWdyZWUgdGhh dCBkaXNjb3ZlcnkgaXMgc29tZXRpbWVzIG5vdCBleHBsaWNpdGx5IG1lbnRpb25lZCwgd2hpY2gg aXMgYSBzaGFtZSwgc2luY2UgaXQgaXMgc3VjaCBhIHZpdGFsIGZ1bmN0aW9uLiBJdCB3b3VsZCB0 aGVyZWZvcmUgYmUgT0sgaW1obyB0byBlbXBoYXNpemUgZGlzY292ZXJ5IGFzIGxvbmcgYXMgd2Ug bGVhdmUgc29tZSB3aWdnbGUgcm9vbSBmb3IgZHluYW1pY2FsbHkgY3JlYXRpbmcgYW5kIHJlbW92 aW5nIGtub3dsZWRnZS4gPC9qY3M+DQpNQjI6IEl0IHdvdWxkIGhlbHAgbWUgaWYgeW91IGNvdWxk IHN1Z2dlc3Qgd2hlcmUgaW4gdGhlIGRvYyB0byBtYWtlIHRob3NlIGNoYW5nZXMuDQpQYWdlIDYs IGxhc3QgcGFyYWdyYXBoIGFib3ZlIHNlY3Rpb24gMy4yDQoiLi4uY2xvc2VkLWxvb3AgY29udHJv bCBpcyBhbiBpbXBvcnRhbnQgYXNwZWN0IG9mIHNlbGYtbWFuYWdpbmcgc3lzdGVtcy4NClRoaXMg aW1wbGllcyBwZWVyLXRvLXBlZXIgZGlhbG9ndWVzIGJldHdlZW4gdGhlIHBhcnRpZXMgdGhhdCBt YWtlIHVwDQp0aGUgY2xvc2VkIGxvb3AuIFN1Y2ggZGlhbG9ndWVzIHJlcXVpcmUgdHdvLXdheSAi ZGlzY3Vzc2lvbiIgb3IgIm5lZ290aWF0aW9uIg0KYmV0d2VlbiBlYWNoIHBhaXIgb3IgZ3JvdXBz IG9mIHBlZXJzIGludm9sdmVkIGluIHRoZSBsb29wLC4uLiINCkZpcnN0LCBieSAicGVlciIsIEkg YXNzdW1lIHlvdSBtZWFuIHR3byAob3IgbW9yZSkgZXF1aXBvdGVudCBlbnRpdGllcyB0aGF0IG1h a2Ugc29tZSBwb3J0aW9uIG9mIHRoZWlyIHJlc291cmNlcyBhdmFpbGFibGUgdG8gb3RoZXJzLiBT ZWNvbmQsIGFuZCBtb3JlIGltcG9ydGFudGx5LCBhIGNsb3NlZCBjb250cm9sIGxvb3AgZG9lcyBu b3QgcmVxdWlyZSBlYWNoIGVudGl0eSBpbiB0aGUgY2xvc2VkIGNvbnRyb2wgbG9vcCB0byB0YWxr IHRvIG5lZ290aWF0ZSB3aXRoIG90aGVyIGVudGl0aWVzLiBOb3csIGluIGFuIGF1dG9ub21pYyBj b250cm9sIGxvb3AsIHRoaXMgY291bGQgdmVyeSB3ZWxsIGJlIHRoZSBjYXNlLCBidXQgaXQgaXMg dW5jbGVhciB0byBtZSB3aHkgaXQgTVVTVCBiZSB0aGUgY2FzZS4gVGhlIG9idmlvdXMgbmlnaHRt YXJlIHNjZW5hcmlvIGlzIHRoYXQgdGhlIG5lZ290aWF0aW9uIGZhaWxzLiBUaGVuIHdoYXQgLSB3 ZSBoYXZlIG5vIGNvbnRyb2wgbG9vcCBhdCBhbGw/DQoNCk1COiBJIGd1ZXNzIHlvdXIgcG9pbnQg aXMgdGhhdCBhbiBhdXRvbm9taWMgcHJvY2VzcyBkb2VzbuKAmXQgSEFWRSB0byBoYXZlIGEgY29u dHJvbCBsb29wLiBJIHdvdWxkIGFyZ3VlIHRoYXQgdGhlIHR5cGljYWwgYXV0b25vbWljIGZ1bmN0 aW9uIERPRVMgaGF2ZSBub2RlLXRvLW5vZGUgaW50ZXJhY3Rpb25zLiBUaGlzIGlzIHdoYXQgYXV0 b25vbWljcyBpcyBhbGwgYWJvdXQuIE5vdywgeWVzLCB0aGVyZSB3aWxsIGJlIGNhc2VzIHdoZXJl IHRoaXMgZmFpbHMsIGFuZCB3aGVyZSBhIG5vZGUgYWxzbyBuZWVkcyB0byBkbyBzb21ldGhpbmcg c2Vuc2libGUgaW4gY2FzZSBvZiBjb21wbGV0ZSBpc29sYXRpb24uIEJ1dCB0aGF04oCZcyBhbiBl eGNlcHRpb24gc3RhdGUgaW4gbXkgbWluZC4NCjxqY3M+IE5vLiBMZXQgbWUgdHJ5IGFnYWluLg0K VGhlIHRleHQgdGhhdCBib3RoZXJzIG1lIGlzICJbY2xvc2VkLWxvb3BdIGltcGxpZXMgcGVlci10 by1wZWVyIGRpYWxvZ3VlcyBiZXR3ZWVuIHRoZSBwYXJ0aWVzIHRoYXQgbWFrZSB1cCB0aGUgY2xv c2UgbG9vcCIuIFRoYXQgaXNuJ3QgaG93IHRyYWRpdGlvbmFsIGNvbnRyb2wgbG9vcHMgYXJlIHR5 cGljYWxseSBidWlsdCwgYW5kIEknbSBwZXJzb25hbGx5IG5vdCBmYW1pbGlhciB3aXRoIGFueSBh dXRvbm9taWMgc3lzdGVtIHRoYXQgYnVpbGRzIHRoZW0gaW4gdGhpcyB3YXkuIFN1cmUsIGl0IHdv dWxkIGJlIG5pY2UgdG8gYWxsb3cgdGhpcyB3aGVuIG5lY2Vzc2FyeSAtIEZPQ0FMRSBoYWQgdGhp cyBmZWF0dXJlIHRocm91Z2ggYSBkZWRpY2F0ZWQgY29udHJvbCBpbnRlcmZhY2UgdGhhdCBjb3Vs ZCBhZGFwdCB0aGUgZnVuY3Rpb24gY2FycmllZCBvdXQgYnkgYSBjb250cm9sIGxvb3AgZWxlbWVu dCBiYXNlZCBvbiAoZm9yIGV4YW1wbGUpIGNoYW5naW5nIGNvbnRleHQgLSBidXQgSSBkaXNhZ3Jl ZSB0aGF0IGl0IGlzIGEgTUFOREFUT1JZIGZ1bmN0aW9uLg0KTUIyOiBXZSBuZWVkIHRvIGRpc2N1 c3MgdGhpcyBhcyB3ZWxsIGluIFByYWd1ZS4gSSBoYXZlIHRoZSBmZWVsaW5nIHdl4oCZcmUgbm90 IHRhbGtpbmcgYWJvdXQgdGhlIHNhbWUgdGhpbmcuDQpUbyB5b3VyIHNlY29uZCBwb2ludCwgSSBk byAob2YgY291cnNlISkgYWdyZWUgdGhhdCBhdXRvbm9taWNzIGlzIGFib3V0IG5vZGUtdG8tbm9k ZSBpbnRlcmFjdGlvbnMuIEJ1dCwgaXQgaXMgYWxzbyBhYm91dCBzeXN0ZW0td2lkZSBpbnRlcmFj dGlvbnMuIE15IHBvaW50IHdhcyB0aGF0IGlmIHlvdSBtYW5kYXRlIG5lZ290aWF0aW9uIGluIG9y ZGVyIHRvIGNyZWF0ZSBhIGNvbnRyb2wgbG9vcCwgYW5kIHRoZSBuZWdvdGlhdGlvbiBmYWlscywg eW91J3JlIGluIHRyb3VibGUuIEFuZCB5ZXMsIHRoYXQgd291bGQgYmUgYW4gZXhjZXB0aW9uIHN0 YXRlIGluIG15IG1pbmQsIGFzIGl0IHZpb2xhdGVzIGEgYmFzaWMgcHJpbmNpcGxlIGluIGF1dG9u b21pY3MgLSBjb25zZW5zdWFsIGJlaGF2aW9yLiA8L2pjcz4NCg0KUGFnZXMgNy04LCBTZWN0aW9u IDMuNg0KTW9zdCBhdXRvbm9taWMgbmV0d29ya2luZyBzeXN0ZW1zIHRvIGRhdGUgaGF2ZSBOT1Qg YmVlbiBidWlsdCB3aXRoIGFuIGludGVudCAob3IgZGVjbGFyYXRpdmUpIHN0eWxlIGludGVyZmFj ZS4gRk9DQUxFIGVuYWJsZXMgZGVjbGFyYXRpdmUgYW5kIHByZXNjcmlwdGl2ZSAoZS5nLiwgRUNB IHBvbGljeSBydWxlcykgdG8gYmUgdXNlZC4gT3RoZXJzIGp1c3QgdXNlIEVDQSAob3IgYW4gZXF1 aXZhbGVudCkgcGFyYWRpZ20uIEhlbmNlLCBJJ20gd29uZGVyaW5nIHdoeSBpbnRlbnQgaXMgdGhl IE9OTFkgcGFyYWRpZ20gdGhhdCBpcyBtZW50aW9uZWQgaW4gdGhpcyBSRkMgdGhhdCBpcyBzdWl0 YWJsZSBmb3IgYXV0b25vbWljIG5ldHdvcmtpbmc/IFNob3VsZG4ndCB3ZSB0cnkgYW5kIHBlYWNl ZnVsbHkgY29leGlzdCwganVzdCBhcyB0aGUgbm9kZXMgYXJlIHBlYWNlZnVsbHkgY29leGlzdGlu ZyB3aXRoIG5vbi1hdXRvbm9taWMgZGlyZWN0aXZlcz8NCg0KTUI6IFRvIG1lLCBFQ0EgaXMgZW5j b2RlZCBpbiBhbiBBU0Egb3IgYW4gYXV0b25vbWljIGZ1bmN0aW9uLiBUaGUgZnVuY3Rpb24gc2F5 cyB3aGF0IGFjdGlvbiB5b3UgdGFrZSBpbiBzcGVjaWZpYyBldmVudHMsIGFuZCB1bmRlciB3aGlj aCBjb25kaXRpb24uDQpFeGFtcGxlOiBUaGUg4oCcZW5yb2xtZW50IHByb3h5IEFTQeKAnSBoYXMg dGhlIGZvbGxvd2luZyAoaGFyZCBjb2RlZCkgRVNBOg0KDQotICAgICAgICAgIEV2ZW50OiBBIG5l dyBub2RlIGlzIGRldGVjdGVkDQoNCi0gICAgICAgICAgQ29uZGl0aW9uOiBpdCBkb2VzbuKAmXQg aGF2ZSBhIGRvbWFpbiBjZXJ0IHlldA0KDQotICAgICAgICAgIEFjdGlvbjogSSBpbnZpdGUgdGhl IG5vZGUgdG8gam9pbiBteSBuZXR3b3JrLg0KTm93LCBJbnRlbnQgaXMgaW4gbXkgbWluZCBhIGhp Z2hlciBsZXZlbCBjb25jZXB0IHdoaWNoIGNvdWxkIG5vdyBzdGF0ZSDigJxkbyBub3QgZW5yb2wg bmV3IG5vZGVzIGF0IHRoaXMgbW9tZW504oCdLg0KSG93IHdvdWxkIHlvdSBzZWUgdGhhdD8NCjxq Y3M+IElzIHRoZSBhY3Rpb24gYSB0eXBvLCBhbmQgeW91IHJlYWxseSBtZWFudDogIkkgZG8gbm90 IGludml0ZSB0aGUgbm9kZSB0byBqb2luIG15IG5ldHdvcmsiPw0KTUIyOiBObywgdGhpcyBpcyB0 aGUgYWN0dWFsIGJlaGF2aW91ciBvZiBhIGJvb3RzdHJhcCBwcm94eS4gSWYgYSBub2RlIGlzIG5l dyBhbmQgZG9lc27igJl0IGhhdmUgYSBkb21haW4gY2VydCB5ZXQsIHlvdSBpbnZpdGUgaXQgdG8g am9pbiB0aGUgZG9tYWluIChjb250cm9sbGVkIGJ5IHRoZSByZWdpc3RyYXIgb2YgY291cnNlKS4g QW55d2F5LCB0aGF04oCZcyBhIGRldGFpbCBJIHRoaW5rLg0KQXMgc3RhdGVkLCBJIHdvdWxkIHNh eSB0aGF0IHRoZSBFQ0EgcG9saWN5IHdvdWxkIE5PVCBmaXJlIGJlY2F1c2UgaXQgdmlvbGF0ZXMg aW50ZW50LiBIb3dldmVyLCB0byBteSBlYXJsaWVyIHBvaW50IGFib3ZlIGFib3V0IGludGVudCBh bmQgRUNBIHBvbGljaWVzIGJlaW5nIGFibGUgdG8gY2FsbCBlYWNoIG90aGVyIC0gQUJTT0xVVEVM WS4gPC9qY3M+DQogTUIyOiBJIHRoaW5rIHdl4oCZcmUgYWN0dWFsbHkgb24gdGhlIHNhbWUgcGFn ZSBoZXJlLCBhbmQgaXTigJlzIGEgcXVlc3Rpb24gb2Ygd29yZGluZy4NClBhZ2UgOSwgc2VjdGlv biAzLjcNCiJIb3dldmVyLCBpbiBhbiBBdXRvbm9taWMgTmV0d29yaywgcmVwb3J0aW5nIHNob3Vs ZCBoYXBwZW4gb24gYSBuZXR3b3JrLXdpZGUgYmFzaXMuIg0KVHJ1ZSwgYnV0IHNob3VsZG4ndCBp bmRpdmlkdWFsIG5vZGVzIGFuZCBjb2xsZWN0aW9ucyBvZiBub2RlcyBzdGlsbCByZXBvcnQ/IFRo YXQgaXNuJ3QgaW1wbGllZCBpbiB0aGUgd29yZGluZy4NCg0KTUI6IFllcywgdGhleSBzaG91bGQu IFRoaXMgaXMg4oCcdHJhZGl0aW9uYWwgbWFuYWdlbWVudCBtZXRob2Rz4oCdLiBJbiBvdXIgbW9k ZWwsIGV2ZXJ5IG5vZGUgZG9lcyB0aGUgbm9ybWFsIHN5c2xvZywgZXRjLiwgYW5kIGFnZ3JlZ2F0 ZWQgcmVwb3J0aW5nIGlzIHRoZSBuZXcgdGhpbmcgdGhhdCBjb21lcyB3aXRoIEFOLg0KPGpjcz4g R290IGl0LCB0aGFua3MuIDwvamNzPg0KDQpGdXJ0aGVybW9yZSwgdGhlIGxhc3QgcGFyYWdyYXBo IHNheXM6ICJBdXRvbm9taWMgbmV0d29yayBldmVudHMgc2hvdWxkIGNvbmNlcm4gdGhlIEF1dG9u b21pYyBOZXR3b3JrIGFzIGEgd2hvbGUsIG5vdCBpbmRpdmlkdWFsIHN5c3RlbXMgaW4gaXNvbGF0 aW9uLiIgSSBhZ3JlZSB0aGF0IHRoZSBnb2FsIGlzIHRvIHJlcG9ydCBvbiB0aGUgc3lzdGVtIGFz IGEgd2hvbGUsIGJ1dCBpc24ndCBzdWNoIGEgcmVwb3J0IGNvbGxlY3RlZCBmcm9tIGluZGl2aWR1 YWwgbm9kZXM/IEp1c3QgbGlrZSBpbiB5b3VyIGV4YW1wbGUsIHRoZSBub2RlcyBuZWVkIHRvIGJl IGFibGUgdG8gc2VlIHRoYXQgYSBwcm9ibGVtIGhhcyBhbHJlYWR5IGJlZW4gcmVwb3J0ZWQgaW4g b3JkZXIgdG8ga25vdyBub3QgdG8gaXNzdWUgdGhlIHNhbWUgcHJvYmxlbS4NCg0KTUI6IFRoZXJl IGFyZSB0d28gcGFyYWxsZWwgbWV0aG9kcyBvZiByZXBvcnRpbmc6DQoNCjEpICAgICAgdGhlIHRy YWRpdGlvbmFsIGV2ZXJ5LW5vZGUtdG8tY29udHJvbGxlciBtZXRob2QsIHdoZXJlIHRoZSBpbnRl bGxpZ2VuY2UgaXMgY2VudHJhbA0KDQoyKSAgICAgIGEgZGlzdHJpYnV0ZWQgcmVwb3J0aW5nIGZ1 bmN0aW9uLCB3aGVyZSBub2RlcyBhZ2dyZWdhdGUsIHByb2Nlc3MsIHN1bW1hcmlzZSwgY29ycmVs YXRlLCDigKYgIGluZm9ybWF0aW9uIGJlZm9yZSBoYW5kaW5nIGl0IHRvIHRoZSBjb250cm9sbGVy LiBIZXJlIHRoZSBpbnRlbGxpZ2VuY2UgaXMgZGlzdHJpYnV0ZWQuDQpCb3RoIHdpbGwgY28tZXhp c3QuIFRoZSBSRkMgZm9jdXNlcyBvbiB0aGUgbmV3IG1ldGhvZCAoYW5kIG9idmlvdXNseSBpc27i gJl0IGNsZWFyIGVub3VnaCBhYm91dCBpdOKApikNCjxqY3M+IE9LLCBnb3QgaXQuIEluIEZPQ0FM RSwgd2UgYWxtb3N0IE5FVkVSIHVzZWQgbm9kZS10by1jb250cm9sbGVyICh3ZWxsLCBGT0NBTEUg cHJlZGF0ZXMgU0ROIGNvbnRyb2xsZXJzLCBidXQgbGV0J3Mgc2F5IGNvbnRyb2xsZXIgPT0gc29t ZSBjZW50cmFsaXplZCBtYW5hZ2VyKSB1bmxlc3MgdGhlIG1ham9yaXR5IChvciBtb3JlKSBvZiBu b2RlcyBmYWlsZWQuIFdlIGRpZCB1c2UgYW4gdW1icmVsbGEgbWFuYWdlbWVudCBwYXJhZGlnbSAo c2ltaWxhciB0byBjbHVzdGVyaGVhZHMgaW4gUDJQIG5ldHdvcmtzKSwgd2hlcmUgdGhlIGNsdXN0 ZXJoZWFkcyBkaWQgY29sbGVjdGlvbiwgZmlsdGVyaW5nLCBjb3JyZWxhdGlvbiwgYW5kIHBvc3Np Ymx5IG90aGVyIGZ1bmN0aW9ucyBiZWZvcmUgcGFzc2luZyB0aGUgZGF0YSAobm90IG5lY2Vzc2Fy aWx5IHVwISkuIEknbSBoYXBweSB0byBmb2N1cyBvbiB0aGUgbmV3LCBqdXN0IHdhbnQgdG8gZW5z dXJlIHdlIGhhdmUgc29tZSBmYWxsYmFjayBwb3NpdGlvbiBmb3Igbm90IGp1c3QgbGVnYWN5IGlu dGVncmF0aW9uLCBidXQgbW9yZSBpbXBvcnRhbnRseSwgZmFpbHVyZSBtb2Rlcy4gPC9qY3M+DQog TUIyOiBBY2suIChJIHRoaW5rKSDimLogICBBbmQgSSBzdGFydCB0byB1bmRlcnN0YW5kIHdoZXJl IHNvbWUgb2Ygb3VyIGNvbmZ1c2lvbnMgYXJlIGNvbWluZyBmcm9tLiBGT0NBTEUgZG9lcyBoYXZl IGEgZGlmZmVyZW50IG1vZGVsIEkgdGhpbmsuIE5lZWRzIG1vcmUgZGlzY3Vzc2lvbi4NClBhZ2Vz IDEyLTEzLCBzZWN0aW9uIDUNCldoeSBpcyBhbiBBdXRvbm9taWMgKipVc2VyKiogQWdlbnQgdGhl IGludGVyZmFjZSB0byBhIGNvbnRyb2wgbG9vcD8gSSBjYW4gc2VlIGFuIGV4dGVybmFsIGVudGl0 eSB3YW50aW5nIHRvIGNvbmZpZ3VyZSBhbmQgbW9uaXRvciB0aGUgY29udHJvbCBsb29wLCBidXQg d2h5IHdvdWxkbid0IHRoZSBVc2VyIEFnZW50IHRhbGsgdG8gdGhlIFNlcnZpY2UgQWdlbnQgdG8g ZG8gdGhpcz8gSSBkbyBub3RlIHRoYXQgdGhpcyBmaWd1cmUgaXMgdW5kZXIgZGlzY3Vzc2lvbiBh bmQgYmVpbmcgcmV2aXNlZCBpbiB0aGUgcmVmZXJlbmNlIG1vZGVsLg0KDQpNQjogWWVzLCB0aGF0 4oCZcyBjb25mdXNpbmcgd29yZGluZywgYW5kIG5vdyB0aGF0IHlvdSBtZW50aW9uIGl0LCB5ZXMg d2Ugc2hvdWxkIGhhdmUgcHJvYmFibHkgbG9va2VkIGZvciBhIGJldHRlciB0ZXJtLiBUaGUgaWRl YSBpczogVGhlIOKAnGludGVsbGlnZW5jZeKAnSBvZiBhbiBhdXRvbm9taWMgZnVuY3Rpb24gaXMg aW4gdGhlIEFTQSAobWlkZGxlIG9mIGZpZ3VyZSAxKS4gVGhlcmUgYXJlIG5vdyBob3Jpem9udGFs IGZlZWRiYWNrIGxvb3BzIGFuZCBub3J0aGJvdW5kIGZlZWRiYWNrIGxvb3BzLiBGb3IgZXhhbXBs ZSwgdGhlcmUgaXMgbGlrZWx5IGEgZnVuY3Rpb24gaW4gdGhlIGVucm9sbWVudCBwcm9jZXNzLCB3 aGVyZSBhIG1lc3NhZ2UgZ2V0cyBzZW50IHRvIHRoZSBhZG1pbjog4oCcSGVyZeKAmXMgYSBuZXcg bm9kZSwgSSBkb27igJl0IHRoaW5rIGl0IGJlbG9uZ3MgaW50byBvdXIgbmV0d29yaywgSeKAmXZl IHF1YXJhbnRpbmVkIHRoYXQgbm9kZSBmb3Igbm93OyB3b3VsZCB5b3UgbGlrZSBtZSB0byAxKSBh Y2NlcHQgdGhlIG5vZGUgYW55d2F5LCBvciAyKSBtYXJrIGl0IGFzIGJhZD/igJ0NCg0KSSBhZ3Jl ZSB0aGUgdGVybSDigJx1c2VyIGFnZW504oCdIGlzIG5vdCBnb29kLiBXZSBuZWVkIHRvIGZpbmQg YSBiZXR0ZXIgb25lLiBTdWdnZXN0aW9ucz8NCjxqY3M+IFNvIGRvZXMgInVzZXIgYWdlbnQiIG1l YW4gIihhdXRvbm9taWMpIG1hbmFnZW1lbnQgYWdlbnQiPyBQcm9iYWJseSBOT1QgYSB1c2VyLWZh Y2luZyBhZ2VudCwgcmlnaHQ/IEluIHRoZSB0cmFkaXRpb24gb2YgQ2FsbSBUZWNobm9sb2d5LCB0 aGUgYmVzdCBhbmQgbW9zdCB1YmlxdWl0b3VzIGZ1bmN0aW9ucyBhcmUgdGhvc2UgdGhhdCBkb24n dCBkZW1hbmQgYXR0ZW50aW9uLCBidXQgcmF0aGVyIGluZm9ybS4gPC9qY3M+DQogTWIyOiBNYXli ZSB0aGF04oCZcyB0aGUgcmlnaHQgdGVybS4gTmVlZCB0byB0aGluayBtb3Jl4oCmDQpQYWdlIDEz LCBGaWd1cmUgMQ0KV2hlcmUgaXMgdGhlIEF1dG9ub21pYyBOb2RlIGluIHRoZSBSZWZlcmVuY2Ug TW9kZWw/IEkgZG8gbm90ZSB0aGF0IHRoaXMgZmlndXJlIGlzIHVuZGVyIGRpc2N1c3Npb24gYW5k IGJlaW5nIHJldmlzZWQgaW4gdGhlIHJlZmVyZW5jZSBtb2RlbC4gSG93ZXZlciwgZXZlbiBpbiBG aWd1cmUgMiBvZiB0aGUgcmVmZXJlbmNlIG1vZGVsLCBpdCBpcyBzdGlsbCB1bmNsZWFyIHdoYXQg dGhlICJub2RlIiBpcy4gQnV0IG1vcmUgb24gdGhhdCBsYXRlci4NCg0KTUI6IFRoZSB3aG9sZSB0 aGluZyBpcyB0aGUgbm9kZS4gVGhhdOKAmXMgd2h5IHRoZSBmaWd1cmUgaXMgY2FsbGVkIOKAnFJl ZmVyZW5jZSBNb2RlbCBmb3IgYW4gQXV0b25vbWljIE5vZGXigJ0uDQo8amNzPiBCdXQgaWYgaXQg aXMgYSAqKm5vZGUqKiwgdGhlbiB3aHkgaXMgaXQgcnVubmluZyBpdHMgb3duIGludGVybmFsIGZl ZWRiYWNrIGxvb3BzPyBOb3RlIHRoYXQgIm5vZGUiIGltcGxpZXMgYSBzaW5nbGUgc29tZXRoaW5n LiBDbGVhcmx5LCB0aGUgc2luZ2xlIHNvbWV0aGluZyBjYW4gY29udGFpbiBncm91cHMgb2Ygb3Ro ZXIgc29tZXRoaW5ncywgYnV0IHdoeSB3b3VsZCBhIGZlZWRiYWNrIGxvb3AgZXhpc3QgaW4gdGhl IHNpbmdsZSBzb21ldGhpbmcgd2hlbiB3ZSBhcmUgZW1waGFzaXppbmcgaW50ZXItbm9kZSBjb21t dW5pY2F0aW9uIGFuZCBmdW5jdGlvbmFsaXR5Pw0KTUIyOiBXaGVyZSBkbyB5b3Ugc2VlIGEgZmVl ZGJhY2sgbG9vcCBpbiB0aGUgbm9kZT8hPyBJIGRvbuKAmXQhICDimLoNCkkgdGhpbmsgdGhhdCB0 aGlzIGZpZ3VyZSB3b3VsZCBiZSBpbXByb3ZlZCBieSBzaG93aW5nIGludGVyZmFjZXMgdG8gdGhl IEF1dG9ub21pYyBDb250cm9sIFBsYW5lIGFuZCB0byB0aGUgT1M7IHJpZ2h0IG5vdywgdGhleSBh cmUgaW5zaWRlIG9mIHRoZSBub2RlLCBhbmQgdGhhdCBJIGRvbid0IHVuZGVyc3RhbmQuIEluIEZP Q0FMRSwgYXMgd2VsbCBhcyBvdGhlciBhcmNoaXRlY3R1cmVzLCBrbm93bGVkZ2UgZGlkIG5vdCBo YXZlIHRvIGJlIGVtYmVkZGVkIGluIHRoZSBub2RlLCBpdCBjb3VsZCBiZSByZWNlaXZlZCBmcm9t IG90aGVyIHBsYWNlcyBpbiB0aGUgbmV0d29yay4gSGVuY2UsIEkgdGhpbmsgdGhhdCBzaG93aW5n IGludGVyZmFjZXMgdG8gd2hlcmUga25vd2xlZGdlIGlzIG9idGFpbmVkIGFuZCB3aGVyZSBpdCBp cyBkaXNjb3ZlcmVkIGlzIG1vcmUgZ2VuZXJpYy4gT2YgY291cnNlLCBtb3JlIGNhcGFibGUgbm9k ZXMgY291bGQgY29udGFpbiB0aGVzZSBmdW5jdGlvbnMsIGJ1dCBJJ20gbm90IGNvbnZpbmNlZCB0 aGF0IHRoaXMgaXMgdGhlIG5vcm0uIDwvamNzPg0KDQpUaGFua3MgZm9yIGFsbCB5b3VyIGlucHV0 IEpvaG4hIExldOKAmXMgbWFrZSBzdXJlIHRoYXQgYWxsIHRoZXNlIHBvaW50cyBnZXQgYWRkcmVz c2VkIGluIHRoZSByZWZlcmVuY2UgbW9kZWwuDQo8amNzPiBJIGhvcGUgaXQgaGVscHMuIEkgdGhp bmsgSSBjYW4gbm93IHdyaXRlIG15IHNlY3Rpb25zIGluIGEgd2F5IHRoYXQgd2lsbCBiZSBtb3Jl IGNvbnNpc3RlbnQuIE1vcmUgZmVlZGJhY2sgY29taW5nIGxhdGVyLiA8L2pjcz4NCiBNQjI6IFRo YW5rcyBmb3IgZmVlZGJhY2suIEkgdGhpbmsgd2Ugc2hvdWxkIHNpbmdsZSBvdXQgc3BlY2lmaWMg aXNzdWVzLCBhbmQgY3JlYXRlIGEgc3BlY2lmaWMgbWFpbCB0aHJlYWQgb24gZWFjaCwgdGhpcyBv bmUgaXMgc3RhcnRpbmcgdG8gZ2V0IG1lc3N5IOKYug0KTWljaGFlbA0KDQpNaWNoYWVsDQoNCmJl c3QgcmVnYXJkcywNCkpvaG4NCg0KDQoNCk9uIE1vbiwgSnVuIDIyLCAyMDE1IGF0IDg6NDYgQU0s IE1pY2hhZWwgQmVocmluZ2VyIChtYmVocmluZykgPG1iZWhyaW5nQGNpc2NvLmNvbTxtYWlsdG86 bWJlaHJpbmdAY2lzY28uY29tPj4gd3JvdGU6DQpIaSBKb2huLCBsZXQgbWUgdGFrZSBhIHN0YWIg YXQgcmVzcG9uZGluZ+KApiBBbmQgdGhhbmtzIGZvciBzaGFyaW5nIHlvdXIgdGhvdWdodHMuIEEg Yml0IGxhdGUgdG8gYnJpbmcgdGhlbSBpbnRvIFJGQzc1NzUsIGJ1dCBhIGdvb2QgdGltaW5nIGZv ciB0aGUgcmVmZXJlbmNlIG1vZGVsLg0KDQpGcm9tOiBBbmltYSBbbWFpbHRvOmFuaW1hLWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOmFuaW1hLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2Yg Sm9obiBTdHJhc3NuZXINClNlbnQ6IDIxIEp1bmUgMjAxNSAxOToyOA0KVG86IEFuaW1hIFdHDQpT dWJqZWN0OiBbQW5pbWFdIFF1ZXN0aW9ucyBvbiBSRkM3NTc1DQoNCkkgc3RhcnRlZCByZXZpZXdp bmcgYm90aCB0aGUgcmVmZXJlbmNlIG1vZGVsIGFzIHdlbGwgYXMgb3RoZXIgcGVydGluZW50IGRv Y3VtZW50cywgc28gdGhhdCB3aGVuIEkgd3JpdGUgbXkgc2VjdGlvbnMgZm9yIHRoZSByZWZlcmVu Y2UgbW9kZWwsIHRoZXkgYXJlIGNvbnNpc3RlbnQuIDotKQ0KDQpJbiBkb2luZyBzbywgSSBoYXZl IGEgbnVtYmVyIG9mIHF1ZXN0aW9ucyBvbiBSRkM3NTc1LiBQYXJ0IG9mIHRoaXMgbWF5IGJlIG15 IGFjYWRlbWljIG5hdHVyZSwgcGFydCBtYXkgYmUgYmVjYXVzZSBJIGhhdmUgdW5kb3VidGVkbHkg bWlzc2VkIHNvbWV0aGluZyBpbiBwYXN0IGVtYWlscyBhcyBJIGNvbWUgdXAgdG8gc3BlZWQsIGFu ZCBwYXJ0bHkgYmVjYXVzZSBJJ20gbGlrZWx5IHVuZGVyLWNhZmZlaW5hdGVkLiBIb3BlZnVsbHks IHNvbWUgb2YgdGhpcyB3aWxsIGhlbHAgaW1wcm92ZSB0aGUgcmVmZXJlbmNlIG1vZGVsIChhbmQg cG9zc2libHkgb3RoZXIgZG9jdW1lbnRzIGFzIHdlbGwpLg0KDQpRdWVzdGlvbnMgb24gUkZDNzU3 NQ0KUGFnZSAzDQoiQXV0b25vbWljIGZ1bmN0aW9ucyBjYW4gYmUgZGVmaW5lZCBpbiB0d28gd2F5 czoNCiAgbyBPbiBhIG5vZGUgbGV2ZWw6IE5vZGVzIGludGVyYWN0IHdpdGggZWFjaCBvdGhlciB0 byBmb3JtIGZlZWRiYWNrDQogICAgbG9vcHMuDQogIG8gT24gYSBzeXN0ZW0gbGV2ZWw6IEZlZWRi YWNrIGxvb3BzIGluY2x1ZGUgY2VudHJhbCBlbGVtZW50cyBhcw0KICAgIHdlbGwuIg0KV2hhdCBp cyBhICJjZW50cmFsIGVsZW1lbnQiPyBEb2VzIHRoaXMgbWVhbiB0aGF0IHRoZSBmZWVkYmFjayBs b29wIGluY2x1ZGVzIGNlbnRyYWxpemVkIG1hbmFnZW1lbnQgbWVjaGFuaXNtcywgb3IgdGhhdCB0 aGVyZSBpcyBhZGRpdGlvbmFsIGxvZ2ljIG91dHNpZGUgb2YganVzdCB0aGUgbm9kZXM/DQoNCk1C OiBBIGNlbnRyYWwgZWxlbWVudCBpcyBhIGNvbnRyb2xsZXIgZm9yIGV4YW1wbGUuIFRoZSBwb2lu dCBvZiB0aGUgc2VjdGlvbiBpczogWW91IGNvdWxkIGRlZmluZSBhbiDigJxhdXRvbm9taWMgbmV0 d29ya+KAnSB3aGVyZSBldmVyeSBub2RlIGhhcyBleGFjdGx5IHRoZSBzYW1lIGludGVyZmFjZXMg YXMgdG9kYXkgKHByaW1hcmlseSBDTEksIFNOTVAsIE5FVENPTkYpLCBhbmQgd2hlcmUgYSBjb250 cm9sbGVyIGlzIGludm9sdmVkIGluIGFsbCBjb250cm9sIGxvb3BzLiBPdXIgZGVmaW5pdGlvbiBv ZiDigJxhdXRvbm9taWPigJ0gaXMgZnVydGhlciBkb3duIGluIHRoZSBuZXR3b3JrLCB3aGVyZSBu b2RlcyBpbnRlcmFjdCBkaXJlY3RseSB3aXRoIG5vZGVzLiBOb3cgd2UgYWxsIHVuZGVyc3RhbmQg dGhpcyBpc27igJl0IGJsYWNrIGFuZCB3aGl0ZSwgYnV0IHRoZSBlbXBoYXNpcyBvZiB0aGUgd29y ayBpbiB0aGUgSUVURiBzaG91bGQgYmUgbm9kZS10by1ub2RlIGludGVyYWN0aW9ucy4NCg0KUGFn ZSA1LCBkZWZpbml0aW9uIG9mIGludGVudA0KV2h5IGlzIGludGVudCBzY29wZWQgdG8gYSBzaW5n bGUgYXV0b25vbWljIGRvbWFpbj8NCg0KTUI6IEludGVudCBpc27igJl0IGEgcG9saWN5IGxhbmd1 YWdlIGxpa2UgbW9zdCBvdGhlciwgd2hlcmUgeW91IGNhbiBlc3NlbnRpYWxseSBkZWZpbmUgYSBw b2xpY3kgZm9yIGV2ZXJ5IG5ldHdvcmsgZWxlbWVudCBzZXBhcmF0ZWx5LiBUaGUgZnVuZGFtZW50 YWwgaWRlYSBpcyB0aGF0IHRoZXJlIGlzIG9uZSBpbnRlbnQgZm9yIHRoZSBlbnRpcmUgbmV0d29y ay4gVGh1cyB0aGlzIGRlZmluaXRpb24uDQpNeSBwZXJzb25hbCBvcGluaW9uOiBJZiB3ZSBsZXQg SW50ZW50IHNsaXAgaW50byB0aGUgZWxlbWVudCBtYW5hZ2VtZW50IHNjb3BlLCB3ZeKAmXZlIG1p c3NlZCBhbiBvcHBvcnR1bml0eS4gSW50ZW50IGlzIGEgcG9saWN5IG9uIG5ldHdvcmsgc2NvcGUu DQoNClBhZ2UgNSwgZGVmaW5pdGlvbiBvZiBhdXRvbm9taWMgZG9tYWluDQpXaHkgaXMgYXV0b25v bWljIGRvbWFpbiB0aWVkIHRvIGludGVudCBhcyB0aGUgb25seSBtYW5hZ2VtZW50IHBhcmFkaWdt PyBUaGUgdmFzdCBtYWpvcml0eSBvZiB3b3JrIGluIGF1dG9ub21pYyBuZXR3b3JraW5nIGRvZXMg Tk9UIHVzZSBpbnRlbnQgKHdoYXQgSSBjYWxsIGRlY2xhcmF0aXZlIGxvZ2ljLCBJIGZhaWxlZCBt YXJrZXRpbmcgOi0pICkuIEkgY29tcGxldGVseSBhZ3JlZSB3aXRoIHVzaW5nIGludGVudCwgYW5k IHBlcmhhcHMgZXZlbiBlbXBoYXNpemluZyBpdCwgYnV0IEkgZG9uJ3QgYWdyZWUgd2l0aCBleGNs dWRpbmcgb3RoZXIgbWFuYWdlbWVudCBwYXJhZGlnbXMuDQoNCk1COiBQcm9iYWJseSBhIHF1ZXN0 aW9uIG9mIHdvcmRpbmcuIEluIG15IHJlYWRpbmcgeW91IGhhdmUgMSkgYXV0b25vbWljIGRlZmF1 bHQgYmVoYXZpb3VyIChjb3VsZCBhbHNvIGNhbGwgdGhpcyDigJxkZWZhdWx0IGludGVudOKAnSks IDIpIEludGVudCwgYW5kIDMpIHRyYWRpdGlvbmFsIG1hbmFnZW1lbnQgc2NoZW1lcywgc3VjaCBh cyBORVRDT05GLCBTTk1QLCBDTEksIGV0Y+KApg0KU28gd2UgZG9u4oCZdCBleGNsdWRlIG90aGVy IG1hbmFnZW1lbnQgcGFyYWRpZ21zLCB0aGV5IGFyZSBoYW5kbGVzIGluIHNlY3Rpb24gMy4yLiBJ cyB0aGF0IHdoYXQgeW91IG1lYW4/DQooWW91IGNvdWxkIGFsc28gZGVmaW5lIGFuIGF1dG9ub21p YyBkb21haW4gYnkgdGhlIHpvbmUgb2YgdHJ1c3Qgb2YgdGhlIGNlcnRpZmljYXRlcy4pDQoNClBh Z2UgNSwgc2VsZi1tYW5hZ2VtZW50DQoiVGhleSBjb25maWd1cmUgdGhlbXNlbHZlcywgYmFzZWQg b24gc2VsZi1rbm93bGVkZ2UsIGRpc2NvdmVyeSwgYW5kIEludGVudC4iDQpUaGUgd29yZCAiZGlz Y292ZXJ5IiBpcyBjb25mdXNpbmcgbWUuIFN1cHBvc2UgYSBub2RlIHJ1bnMgYSB1dGlsaXR5IGZ1 bmN0aW9uIHRvIGRlY2lkZSB3aGF0IGl0cyBuZXh0IGNvbmZpZ3VyYXRpb24gY2hhbmdlIHNob3Vs ZCBiZS4gSXQgaXMgbm90ICJkaXNjb3ZlcmluZyIgc29tZXRoaW5nIHRoYXQgZXhpc3RlZCAtIHJh dGhlciwgaXQgaXMgY29tcHV0aW5nIG5ldyBrbm93bGVkZ2UuIEEgbWFjaGluZSBsZWFybmluZyBm dW5jdGlvbiB0aGF0IGluZmVycyBuZXcga25vd2xlZGdlIGlzIGFuIGV2ZW4gYmV0dGVyIGV4YW1w bGUgb2Ygc29tZXRoaW5nIHRoYXQgaXMgbm90ICJkaXNjb3ZlcmVkIi4gSSdtIHByb2JhYmx5IG1p c3Npbmcgc29tZXRoaW5nLCBidXQgd2h5IHdhcyB0aGlzIGNob2ljZSBtYWRlPw0KVGhlIHRoaW5n IHRoYXQgcmVhbGx5IGJvdGhlcnMgbWUgaXMgdGhhdCB0aGlzIGFzc3VtZXMgdGhhdCBhbGwga25v d2xlZGdlIGNhbiBiZSBkaXNjb3ZlcmVkIC0gdGhhdCBpcywgaXQgaXMgZXhpc3RpbmcsIGxpa2Ug YW4gYXBwbGUgb24gYSB0cmVlLCByZWFkeSB0byBiZSBwbHVja2VkLiBJbiB0aGUgYXV0b25vbWlj IHN5c3RlbXMgdGhhdCBJJ3ZlIGJ1aWx0LCB0aGlzIGlzIG9ubHkgc29tZXRpbWVzIHRoZSBjYXNl LiBJdCBpcyB2aXRhbCBmb3IgYW4gYXV0b25vbWljIHN5c3RlbSB0byBiZSBhYmxlIHRvIGxlYXJu IG5ldyBrbm93bGVkZ2UgdmlhIGNvbXB1dGF0aW9uIGFuZCBpbmZlcmVuY2UsIGFzIHdlbGwgYXMg ZGVjaWRlIHRoYXQgcHJldmlvdXMga25vd2xlZGdlIHdhcyBpbmNvcnJlY3QuIE5laXRoZXIgb2Yg dGhlc2UgYXJlIGRpc2NvdmVyeSBmdW5jdGlvbnMuDQoNCk1COiBJIHRoaW5rIHRoZSBjb25mdXNp b24gaXMgdGhlIGRlZmluaXRpb24gb2Yg4oCcZGlzY292ZXJ54oCdIGhlcmUuIEl04oCZcyBub3Qg b25seSBkaXNjb3ZlcnkgaW4gdGhlIHNlbnNlIG9mIHNlcnZpY2UgZGlzY292ZXJ5LCBidXQgZm9y IGV4YW1wbGUsIGZpbmRpbmcgbmVpZ2hib3JzLCBuZWdvdGlhdGluZyBwYXJhbWV0ZXJzIHdpdGgg dGhlbSwgZXRjLg0KVGhlIGFib3ZlIHBocmFzZSBpbiBvdGhlciB3b3Jkczog4oCcSSBrbm93IG15 IGNhcGFiaWxpdGllcywgSSBzZWUgd2hhdCBlbHNlIGlzIHRoZXJlIChhbmQgdGFsayB0byBpdCBw b3RlbnRpYWxseSksIGFuZCBJIHNlZSB3aGF0IHRoZSBib3NzIHdhbnRzIHRvIGhhcHBlbiAoaW50 ZW50KS4gQmFzZWQgb24gYWxsIG9mIHRoaXMgSSBkZWNpZGUgd2hhdCBJ4oCZbSBnb2luZyB0byBk b+KAnS4NCkkgdGhpbmsgaXTigJlzIGEgcXVlc3Rpb24gb2Ygd29yZGluZy4gV2UgaGFkIHRoaXMg Z3JhcGhpYyAoc2ltaWxhciB0byBmaWd1cmUgMSksIHdoZXJlIHRoZXJlIGFyZSB0aGUgMyBpbnB1 dCB2ZWN0b3JzICghKSBvZiBpbmZvcm1hdGlvbiwgb24gd2hpY2ggeW91IGJhc2UgeW91ciBkZWNp c2lvbnMuIFRoZSBpbmZlcmVuY2UgeW91IG1lbnRpb24gaXMgYSBjb25zZXF1ZW5jZSBvZiB0aG9z ZSBpbnB1dHMuIEluIG90aGVyIHdvcmRzLCB0aGUg4oCcYnJhaW7igJ0gdGhhdCBhY3R1YWxseSBt YWtlcyB0aGUgaW5mZXJlbmNlLCBpcyBpbiBvdXIgbW9kZWwgdGhlIGF1dG9ub21pYyBzZXJ2aWNl IGFnZW50Lg0KRG9lcyB0aGF0IG1ha2Ugc2Vuc2U/DQoNClBhZ2UgNiwgbGFzdCBwYXJhZ3JhcGgg YWJvdmUgc2VjdGlvbiAzLjINCiIuLi5jbG9zZWQtbG9vcCBjb250cm9sIGlzIGFuIGltcG9ydGFu dCBhc3BlY3Qgb2Ygc2VsZi1tYW5hZ2luZyBzeXN0ZW1zLg0KVGhpcyBpbXBsaWVzIHBlZXItdG8t cGVlciBkaWFsb2d1ZXMgYmV0d2VlbiB0aGUgcGFydGllcyB0aGF0IG1ha2UgdXANCnRoZSBjbG9z ZWQgbG9vcC4gU3VjaCBkaWFsb2d1ZXMgcmVxdWlyZSB0d28td2F5ICJkaXNjdXNzaW9uIiBvciAi bmVnb3RpYXRpb24iDQpiZXR3ZWVuIGVhY2ggcGFpciBvciBncm91cHMgb2YgcGVlcnMgaW52b2x2 ZWQgaW4gdGhlIGxvb3AsLi4uIg0KRmlyc3QsIGJ5ICJwZWVyIiwgSSBhc3N1bWUgeW91IG1lYW4g dHdvIChvciBtb3JlKSBlcXVpcG90ZW50IGVudGl0aWVzIHRoYXQgbWFrZSBzb21lIHBvcnRpb24g b2YgdGhlaXIgcmVzb3VyY2VzIGF2YWlsYWJsZSB0byBvdGhlcnMuIFNlY29uZCwgYW5kIG1vcmUg aW1wb3J0YW50bHksIGEgY2xvc2VkIGNvbnRyb2wgbG9vcCBkb2VzIG5vdCByZXF1aXJlIGVhY2gg ZW50aXR5IGluIHRoZSBjbG9zZWQgY29udHJvbCBsb29wIHRvIHRhbGsgdG8gbmVnb3RpYXRlIHdp dGggb3RoZXIgZW50aXRpZXMuIE5vdywgaW4gYW4gYXV0b25vbWljIGNvbnRyb2wgbG9vcCwgdGhp cyBjb3VsZCB2ZXJ5IHdlbGwgYmUgdGhlIGNhc2UsIGJ1dCBpdCBpcyB1bmNsZWFyIHRvIG1lIHdo eSBpdCBNVVNUIGJlIHRoZSBjYXNlLiBUaGUgb2J2aW91cyBuaWdodG1hcmUgc2NlbmFyaW8gaXMg dGhhdCB0aGUgbmVnb3RpYXRpb24gZmFpbHMuIFRoZW4gd2hhdCAtIHdlIGhhdmUgbm8gY29udHJv bCBsb29wIGF0IGFsbD8NCg0KTUI6IEkgZ3Vlc3MgeW91ciBwb2ludCBpcyB0aGF0IGFuIGF1dG9u b21pYyBwcm9jZXNzIGRvZXNu4oCZdCBIQVZFIHRvIGhhdmUgYSBjb250cm9sIGxvb3AuIEkgd291 bGQgYXJndWUgdGhhdCB0aGUgdHlwaWNhbCBhdXRvbm9taWMgZnVuY3Rpb24gRE9FUyBoYXZlIG5v ZGUtdG8tbm9kZSBpbnRlcmFjdGlvbnMuIFRoaXMgaXMgd2hhdCBhdXRvbm9taWNzIGlzIGFsbCBh Ym91dC4gTm93LCB5ZXMsIHRoZXJlIHdpbGwgYmUgY2FzZXMgd2hlcmUgdGhpcyBmYWlscywgYW5k IHdoZXJlIGEgbm9kZSBhbHNvIG5lZWRzIHRvIGRvIHNvbWV0aGluZyBzZW5zaWJsZSBpbiBjYXNl IG9mIGNvbXBsZXRlIGlzb2xhdGlvbi4gQnV0IHRoYXTigJlzIGFuIGV4Y2VwdGlvbiBzdGF0ZSBp biBteSBtaW5kLg0KDQpQYWdlcyA3LTgsIFNlY3Rpb24gMy42DQpNb3N0IGF1dG9ub21pYyBuZXR3 b3JraW5nIHN5c3RlbXMgdG8gZGF0ZSBoYXZlIE5PVCBiZWVuIGJ1aWx0IHdpdGggYW4gaW50ZW50 IChvciBkZWNsYXJhdGl2ZSkgc3R5bGUgaW50ZXJmYWNlLiBGT0NBTEUgZW5hYmxlcyBkZWNsYXJh dGl2ZSBhbmQgcHJlc2NyaXB0aXZlIChlLmcuLCBFQ0EgcG9saWN5IHJ1bGVzKSB0byBiZSB1c2Vk LiBPdGhlcnMganVzdCB1c2UgRUNBIChvciBhbiBlcXVpdmFsZW50KSBwYXJhZGlnbS4gSGVuY2Us IEknbSB3b25kZXJpbmcgd2h5IGludGVudCBpcyB0aGUgT05MWSBwYXJhZGlnbSB0aGF0IGlzIG1l bnRpb25lZCBpbiB0aGlzIFJGQyB0aGF0IGlzIHN1aXRhYmxlIGZvciBhdXRvbm9taWMgbmV0d29y a2luZz8gU2hvdWxkbid0IHdlIHRyeSBhbmQgcGVhY2VmdWxseSBjb2V4aXN0LCBqdXN0IGFzIHRo ZSBub2RlcyBhcmUgcGVhY2VmdWxseSBjb2V4aXN0aW5nIHdpdGggbm9uLWF1dG9ub21pYyBkaXJl Y3RpdmVzPw0KDQpNQjogVG8gbWUsIEVDQSBpcyBlbmNvZGVkIGluIGFuIEFTQSBvciBhbiBhdXRv bm9taWMgZnVuY3Rpb24uIFRoZSBmdW5jdGlvbiBzYXlzIHdoYXQgYWN0aW9uIHlvdSB0YWtlIGlu IHNwZWNpZmljIGV2ZW50cywgYW5kIHVuZGVyIHdoaWNoIGNvbmRpdGlvbi4NCkV4YW1wbGU6IFRo ZSDigJxlbnJvbG1lbnQgcHJveHkgQVNB4oCdIGhhcyB0aGUgZm9sbG93aW5nIChoYXJkIGNvZGVk KSBFU0E6DQoNCi0gICAgICAgICAgRXZlbnQ6IEEgbmV3IG5vZGUgaXMgZGV0ZWN0ZWQNCg0KLSAg ICAgICAgICBDb25kaXRpb246IGl0IGRvZXNu4oCZdCBoYXZlIGEgZG9tYWluIGNlcnQgeWV0DQoN Ci0gICAgICAgICAgQWN0aW9uOiBJIGludml0ZSB0aGUgbm9kZSB0byBqb2luIG15IG5ldHdvcmsu DQpOb3csIEludGVudCBpcyBpbiBteSBtaW5kIGEgaGlnaGVyIGxldmVsIGNvbmNlcHQgd2hpY2gg Y291bGQgbm93IHN0YXRlIOKAnGRvIG5vdCBlbnJvbCBuZXcgbm9kZXMgYXQgdGhpcyBtb21lbnTi gJ0uDQpIb3cgd291bGQgeW91IHNlZSB0aGF0Pw0KDQpQYWdlIDksIHNlY3Rpb24gMy43DQoiSG93 ZXZlciwgaW4gYW4gQXV0b25vbWljIE5ldHdvcmssIHJlcG9ydGluZyBzaG91bGQgaGFwcGVuIG9u IGEgbmV0d29yay13aWRlIGJhc2lzLiINClRydWUsIGJ1dCBzaG91bGRuJ3QgaW5kaXZpZHVhbCBu b2RlcyBhbmQgY29sbGVjdGlvbnMgb2Ygbm9kZXMgc3RpbGwgcmVwb3J0PyBUaGF0IGlzbid0IGlt cGxpZWQgaW4gdGhlIHdvcmRpbmcuDQoNCk1COiBZZXMsIHRoZXkgc2hvdWxkLiBUaGlzIGlzIOKA nHRyYWRpdGlvbmFsIG1hbmFnZW1lbnQgbWV0aG9kc+KAnS4gSW4gb3VyIG1vZGVsLCBldmVyeSBu b2RlIGRvZXMgdGhlIG5vcm1hbCBzeXNsb2csIGV0Yy4sIGFuZCBhZ2dyZWdhdGVkIHJlcG9ydGlu ZyBpcyB0aGUgbmV3IHRoaW5nIHRoYXQgY29tZXMgd2l0aCBBTi4NCg0KRnVydGhlcm1vcmUsIHRo ZSBsYXN0IHBhcmFncmFwaCBzYXlzOiAiQXV0b25vbWljIG5ldHdvcmsgZXZlbnRzIHNob3VsZCBj b25jZXJuIHRoZSBBdXRvbm9taWMgTmV0d29yayBhcyBhIHdob2xlLCBub3QgaW5kaXZpZHVhbCBz eXN0ZW1zIGluIGlzb2xhdGlvbi4iIEkgYWdyZWUgdGhhdCB0aGUgZ29hbCBpcyB0byByZXBvcnQg b24gdGhlIHN5c3RlbSBhcyBhIHdob2xlLCBidXQgaXNuJ3Qgc3VjaCBhIHJlcG9ydCBjb2xsZWN0 ZWQgZnJvbSBpbmRpdmlkdWFsIG5vZGVzPyBKdXN0IGxpa2UgaW4geW91ciBleGFtcGxlLCB0aGUg bm9kZXMgbmVlZCB0byBiZSBhYmxlIHRvIHNlZSB0aGF0IGEgcHJvYmxlbSBoYXMgYWxyZWFkeSBi ZWVuIHJlcG9ydGVkIGluIG9yZGVyIHRvIGtub3cgbm90IHRvIGlzc3VlIHRoZSBzYW1lIHByb2Js ZW0uDQoNCk1COiBUaGVyZSBhcmUgdHdvIHBhcmFsbGVsIG1ldGhvZHMgb2YgcmVwb3J0aW5nOg0K DQoxKSAgICAgIHRoZSB0cmFkaXRpb25hbCBldmVyeS1ub2RlLXRvLWNvbnRyb2xsZXIgbWV0aG9k LCB3aGVyZSB0aGUgaW50ZWxsaWdlbmNlIGlzIGNlbnRyYWwNCg0KMikgICAgICBhIGRpc3RyaWJ1 dGVkIHJlcG9ydGluZyBmdW5jdGlvbiwgd2hlcmUgbm9kZXMgYWdncmVnYXRlLCBwcm9jZXNzLCBz dW1tYXJpc2UsIGNvcnJlbGF0ZSwg4oCmICBpbmZvcm1hdGlvbiBiZWZvcmUgaGFuZGluZyBpdCB0 byB0aGUgY29udHJvbGxlci4gSGVyZSB0aGUgaW50ZWxsaWdlbmNlIGlzIGRpc3RyaWJ1dGVkLg0K Qm90aCB3aWxsIGNvLWV4aXN0LiBUaGUgUkZDIGZvY3VzZXMgb24gdGhlIG5ldyBtZXRob2QgKGFu ZCBvYnZpb3VzbHkgaXNu4oCZdCBjbGVhciBlbm91Z2ggYWJvdXQgaXTigKYpDQoNClBhZ2VzIDEy LTEzLCBzZWN0aW9uIDUNCldoeSBpcyBhbiBBdXRvbm9taWMgKipVc2VyKiogQWdlbnQgdGhlIGlu dGVyZmFjZSB0byBhIGNvbnRyb2wgbG9vcD8gSSBjYW4gc2VlIGFuIGV4dGVybmFsIGVudGl0eSB3 YW50aW5nIHRvIGNvbmZpZ3VyZSBhbmQgbW9uaXRvciB0aGUgY29udHJvbCBsb29wLCBidXQgd2h5 IHdvdWxkbid0IHRoZSBVc2VyIEFnZW50IHRhbGsgdG8gdGhlIFNlcnZpY2UgQWdlbnQgdG8gZG8g dGhpcz8gSSBkbyBub3RlIHRoYXQgdGhpcyBmaWd1cmUgaXMgdW5kZXIgZGlzY3Vzc2lvbiBhbmQg YmVpbmcgcmV2aXNlZCBpbiB0aGUgcmVmZXJlbmNlIG1vZGVsLg0KDQpNQjogWWVzLCB0aGF04oCZ cyBjb25mdXNpbmcgd29yZGluZywgYW5kIG5vdyB0aGF0IHlvdSBtZW50aW9uIGl0LCB5ZXMgd2Ug c2hvdWxkIGhhdmUgcHJvYmFibHkgbG9va2VkIGZvciBhIGJldHRlciB0ZXJtLiBUaGUgaWRlYSBp czogVGhlIOKAnGludGVsbGlnZW5jZeKAnSBvZiBhbiBhdXRvbm9taWMgZnVuY3Rpb24gaXMgaW4g dGhlIEFTQSAobWlkZGxlIG9mIGZpZ3VyZSAxKS4gVGhlcmUgYXJlIG5vdyBob3Jpem9udGFsIGZl ZWRiYWNrIGxvb3BzIGFuZCBub3J0aGJvdW5kIGZlZWRiYWNrIGxvb3BzLiBGb3IgZXhhbXBsZSwg dGhlcmUgaXMgbGlrZWx5IGEgZnVuY3Rpb24gaW4gdGhlIGVucm9sbWVudCBwcm9jZXNzLCB3aGVy ZSBhIG1lc3NhZ2UgZ2V0cyBzZW50IHRvIHRoZSBhZG1pbjog4oCcSGVyZeKAmXMgYSBuZXcgbm9k ZSwgSSBkb27igJl0IHRoaW5rIGl0IGJlbG9uZ3MgaW50byBvdXIgbmV0d29yaywgSeKAmXZlIHF1 YXJhbnRpbmVkIHRoYXQgbm9kZSBmb3Igbm93OyB3b3VsZCB5b3UgbGlrZSBtZSB0byAxKSBhY2Nl cHQgdGhlIG5vZGUgYW55d2F5LCBvciAyKSBtYXJrIGl0IGFzIGJhZD/igJ0NCg0KSSBhZ3JlZSB0 aGUgdGVybSDigJx1c2VyIGFnZW504oCdIGlzIG5vdCBnb29kLiBXZSBuZWVkIHRvIGZpbmQgYSBi ZXR0ZXIgb25lLiBTdWdnZXN0aW9ucz8NCg0KUGFnZSAxMywgRmlndXJlIDENCldoZXJlIGlzIHRo ZSBBdXRvbm9taWMgTm9kZSBpbiB0aGUgUmVmZXJlbmNlIE1vZGVsPyBJIGRvIG5vdGUgdGhhdCB0 aGlzIGZpZ3VyZSBpcyB1bmRlciBkaXNjdXNzaW9uIGFuZCBiZWluZyByZXZpc2VkIGluIHRoZSBy ZWZlcmVuY2UgbW9kZWwuIEhvd2V2ZXIsIGV2ZW4gaW4gRmlndXJlIDIgb2YgdGhlIHJlZmVyZW5j ZSBtb2RlbCwgaXQgaXMgc3RpbGwgdW5jbGVhciB3aGF0IHRoZSAibm9kZSIgaXMuIEJ1dCBtb3Jl IG9uIHRoYXQgbGF0ZXIuDQoNCk1COiBUaGUgd2hvbGUgdGhpbmcgaXMgdGhlIG5vZGUuIFRoYXTi gJlzIHdoeSB0aGUgZmlndXJlIGlzIGNhbGxlZCDigJxSZWZlcmVuY2UgTW9kZWwgZm9yIGFuIEF1 dG9ub21pYyBOb2Rl4oCdLg0KDQpUaGFua3MgZm9yIGFsbCB5b3VyIGlucHV0IEpvaG4hIExldOKA mXMgbWFrZSBzdXJlIHRoYXQgYWxsIHRoZXNlIHBvaW50cyBnZXQgYWRkcmVzc2VkIGluIHRoZSBy ZWZlcmVuY2UgbW9kZWwuDQoNCk1pY2hhZWwNCi0tDQpyZWdhcmRzLA0KSm9obg0KDQoNCg0KLS0N CnJlZ2FyZHMsDQpKb2huDQo= --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FF268Axmbrcdx14ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29B Y2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFs bG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1HQjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow Y20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iVGFob21hIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Zm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTo8 L3NwYW4+PC9mb250PjwvYj48Zm9udCBzaXplPSIyIiBmYWNlPSJUYWhvbWEiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQogSm9obiBTdHJhc3NuZXIgW21haWx0bzpz dHJhenBkakBnbWFpbC5jb21dIDxicj4NCjxiPjxmb250IGNvbG9yPSIjMWY0OTdkIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RDtmb250LXdlaWdodDpib2xkIj5b4oCmXTwvc3Bhbj48L2ZvbnQ+ PC9iPjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlF1ZXN0aW9ucyBvbiBS RkM3NTc1PGJyPg0KUGFnZSAzPGJyPg0KJnF1b3Q7QXV0b25vbWljIGZ1bmN0aW9ucyBjYW4gYmUg ZGVmaW5lZCBpbiB0d28gd2F5czo8YnI+DQombmJzcDsgbyBPbiBhIG5vZGUgbGV2ZWw6IE5vZGVz IGludGVyYWN0IHdpdGggZWFjaCBvdGhlciB0byBmb3JtIGZlZWRiYWNrPGJyPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7IGxvb3BzLjxicj4NCiZuYnNwOyBvIE9uIGEgc3lzdGVtIGxldmVsOiBGZWVkYmFj ayBsb29wcyBpbmNsdWRlIGNlbnRyYWwgZWxlbWVudHMgYXM8YnI+DQombmJzcDsmbmJzcDsmbmJz cDsgd2VsbC4mcXVvdDs8YnI+DQpXaGF0IGlzIGEgJnF1b3Q7Y2VudHJhbCBlbGVtZW50JnF1b3Q7 PyBEb2VzIHRoaXMgbWVhbiB0aGF0IHRoZSBmZWVkYmFjayBsb29wIGluY2x1ZGVzIGNlbnRyYWxp emVkIG1hbmFnZW1lbnQgbWVjaGFuaXNtcywgb3IgdGhhdCB0aGVyZSBpcyBhZGRpdGlvbmFsIGxv Z2ljIG91dHNpZGUgb2YganVzdCB0aGUgbm9kZXM/PG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2Qi IGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1COiBBIGNlbnRyYWwgZWxlbWVu dCBpcyBhIGNvbnRyb2xsZXIgZm9yIGV4YW1wbGUuDQogVGhlIHBvaW50IG9mIHRoZSBzZWN0aW9u IGlzOiBZb3UgY291bGQgZGVmaW5lIGFuIOKAnGF1dG9ub21pYyBuZXR3b3Jr4oCdIHdoZXJlIGV2 ZXJ5IG5vZGUgaGFzIGV4YWN0bHkgdGhlIHNhbWUgaW50ZXJmYWNlcyBhcyB0b2RheSAocHJpbWFy aWx5IENMSSwgU05NUCwgTkVUQ09ORiksIGFuZCB3aGVyZSBhIGNvbnRyb2xsZXIgaXMgaW52b2x2 ZWQgaW4gYWxsIGNvbnRyb2wgbG9vcHMuIE91ciBkZWZpbml0aW9uIG9mIOKAnGF1dG9ub21pY+KA nSBpcyBmdXJ0aGVyDQogZG93biBpbiB0aGUgbmV0d29yaywgd2hlcmUgbm9kZXMgaW50ZXJhY3Qg ZGlyZWN0bHkgd2l0aCBub2Rlcy4gTm93IHdlIGFsbCB1bmRlcnN0YW5kIHRoaXMgaXNu4oCZdCBi bGFjayBhbmQgd2hpdGUsIGJ1dCB0aGUgZW1waGFzaXMgb2YgdGhlIHdvcmsgaW4gdGhlIElFVEYg c2hvdWxkIGJlIG5vZGUtdG8tbm9kZSBpbnRlcmFjdGlvbnMuDQo8L3NwYW4+PC9mb250PjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMyIg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jmx0 O2pjcyZndDsgT0ssIGdvdCBpdC4gSnVzdCB0byBlbnN1cmUsIGlzIGl0IGZhaXIgdG8gc2F5IHRo YXQgYSAmcXVvdDtjZW50cmFsIGVsZW1lbnQmcXVvdDsgaXMgb25lIGluIHdoaWNoIG5vbi1hdXRv bm9taWMgZnVuY3Rpb25zDQogYXJlIHVzZWQgdGhhdCBtYXkgYWZmZWN0IHRoZSBiZWhhdmlvciBv ZiBhdXRvbm9taWMgbm9kZXM/ICZsdDsvamNzJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjMiIGNvbG9yPSIjMWY0OTdk IiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOiMxRjQ5N0QiPk1CMjogVGhpcyBpcyBjb3JyZWN0IGJ1dCBub3QgY29tcGxldGUuIEJlY2F1 c2UgYWxzbyBhIG5vcm1hbCBub2RlIGhhcyBub24tYXV0b25vbWljDQogZnVuY3Rpb25zIHRoYXQg bWF5IGFmZmVjdCB0aGUgYmVoYXZpb3VyIG9mIHRoYXQgbm9kZSAob3Igb3RoZXJzKS4gPC9zcGFu PjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+UGFnZSA1LCBkZWZpbml0aW9uIG9mIGludGVudDxicj4NCldoeSBp cyBpbnRlbnQgc2NvcGVkIHRvIGEgc2luZ2xlIGF1dG9ub21pYyBkb21haW4/PG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGZvbnQgc2l6ZT0iMyIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwv Zm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0i MiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5NQjogSW50ZW50IGlzbuKAmXQgYSBwb2xpY3kgbGFuZ3VhZ2Ug bGlrZSBtb3N0IG90aGVyLA0KIHdoZXJlIHlvdSBjYW4gZXNzZW50aWFsbHkgZGVmaW5lIGEgcG9s aWN5IGZvciBldmVyeSBuZXR3b3JrIGVsZW1lbnQgc2VwYXJhdGVseS4gVGhlIGZ1bmRhbWVudGFs IGlkZWEgaXMgdGhhdCB0aGVyZSBpcyBvbmUgaW50ZW50IGZvciB0aGUgZW50aXJlIG5ldHdvcmsu IFRodXMgdGhpcyBkZWZpbml0aW9uLg0KPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMyIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6IzFG NDk3RCI+TXkgcGVyc29uYWwgb3BpbmlvbjogSWYgd2UgbGV0IEludGVudCBzbGlwIGludG8gdGhl IGVsZW1lbnQgbWFuYWdlbWVudCBzY29wZSwNCiB3ZeKAmXZlIG1pc3NlZCBhbiBvcHBvcnR1bml0 eS4gSW50ZW50IGlzIGEgcG9saWN5IG9uIG5ldHdvcmsgc2NvcGUuIDxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIz IiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtjb2xvcjojMUY0OTdEIj4mbHQ7amNzJmd0OyBIZXJlIHlvdSBsb3N0IG1l LiBPREwgR0JQIGFuZCZuYnNwO09ETCBOSUMsIE9wZW5TdGFjayBDb25ncmVzcywgc29tZSBuYXNj ZW50DQogd29yayBpbiB0aGUgT05GLCBhbmQgVE1GIFpPT00gd291bGQgYWxsIGRpc2FncmVlLiBJ bnRlbnQsIGZvciBiZXR0ZXIgb3Igd29yc2UsIGhhcyBiZWVuIGNoYXJhY3Rlcml6ZWQgYXMgVGhl IE5ldyBQb2xpY3kgKG5vIG9mZmVuc2UgdG8mbmJzcDtMaWdodCZuYnNwO1JlYWRpbmcpLiZuYnNw O0J1dCB0aGVuIGF0IHRoZSBlbmQgeW91IHNheSAmcXVvdDtJbnRlbnQgaXMgYSBwb2xpY3kgb24g bmV0d29yayBzY29wZSZxdW90Oywgc28gbWF5YmUgSSdtIHJlYWRpbmcgeW91IHRvbyBsaXRlcmFs bHk/DQogKHNlZSBJIGhhdmVuJ3QgY2hhbmdlZCBzaW5jZSBteSBDaXNjbyBkYXlzIDotKSApLiA8 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9u dCBzaXplPSIzIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjojMUY0OTdEIj5NQjI6IEkga25vdywgbG90cyBv ZiBncm91cHMgaGF2ZSBieSBub3cgcGlja2VkIHVwIHRoZSDigJxpbnRlbnTigJ0gd29yZCwgYW5k IHNpbmNlDQogd2UgbmV2ZXIgcmVhbGx5IGRlZmluZWQgaXQgaW4gZGV0YWlsLCBpdCBub3cgbWVh bnMgYW55dGhpbmcgdG8gYW55b25lLiAoSSB0aGluayDigJMgaG9wZWZ1bGx5IEnigJltIHdyb25n KS4gV2Ugc2hvdWxkIGRpc2N1c3MgdGhpcyBpbiBQcmFndWUuDQo8L3NwYW4+PC9mb250Pjxmb250 IGNvbG9yPSIjMWY0OTdkIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMyIg Y29sb3I9IiMxZjQ5N2QiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Y29sb3I6IzFGNDk3RCI+UGx1cywgZG8geW91IHJlYWxseSBtZWFuJm5ic3A7 JnF1b3Q7Zm9yIHRoZSBlbnRpcmUgbmV0d29yayZxdW90Oz8gSXNuJ3QgJnF1b3Q7Zm9yIGEgZ2l2 ZW4gc2V0IG9mIGFkbWluaXN0cmF0aXZlDQogZG9tYWlucyZxdW90OyBnb29kIGVub3VnaD8mbmJz cDsmbHQ7L2pjcyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJD YWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjwvZm9udD48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJy aSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1CMjoNCiBkb21h aW4gaXMgdGhlIHJpZ2h0IHRlcm0uIDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjMiIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlBhZ2UgNSwgZGVm aW5pdGlvbiBvZiBhdXRvbm9taWMgZG9tYWluPGJyPg0KV2h5IGlzIGF1dG9ub21pYyBkb21haW4g dGllZCB0byBpbnRlbnQgYXMgdGhlIG9ubHkgbWFuYWdlbWVudCBwYXJhZGlnbT8gVGhlIHZhc3Qg bWFqb3JpdHkgb2Ygd29yayBpbiBhdXRvbm9taWMgbmV0d29ya2luZyBkb2VzIE5PVCB1c2UgaW50 ZW50ICh3aGF0IEkgY2FsbCBkZWNsYXJhdGl2ZSBsb2dpYywgSSBmYWlsZWQgbWFya2V0aW5nIDot KSApLiBJIGNvbXBsZXRlbHkgYWdyZWUgd2l0aCB1c2luZyBpbnRlbnQsIGFuZCBwZXJoYXBzIGV2 ZW4gZW1waGFzaXppbmcNCiBpdCwgYnV0IEkgZG9uJ3QgYWdyZWUgd2l0aCBleGNsdWRpbmcgb3Ro ZXIgbWFuYWdlbWVudCBwYXJhZGlnbXMuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMyIgY29sb3I9 IiMxZjQ5N2QiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZh Y2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5N QjogUHJvYmFibHkgYSBxdWVzdGlvbiBvZiB3b3JkaW5nLiBJbiBteSByZWFkaW5nIHlvdQ0KIGhh dmUgMSkgYXV0b25vbWljIGRlZmF1bHQgYmVoYXZpb3VyIChjb3VsZCBhbHNvIGNhbGwgdGhpcyDi gJxkZWZhdWx0IGludGVudOKAnSksIDIpIEludGVudCwgYW5kIDMpIHRyYWRpdGlvbmFsIG1hbmFn ZW1lbnQgc2NoZW1lcywgc3VjaCBhcyBORVRDT05GLCBTTk1QLCBDTEksIGV0Y+KApiZuYnNwOw0K PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZv bnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TbyB3ZSBkb27igJl0IGV4Y2x1ZGUgb3RoZXIg bWFuYWdlbWVudCBwYXJhZGlnbXMsIHRoZXkNCiBhcmUgaGFuZGxlcyBpbiBzZWN0aW9uIDMuMi4g SXMgdGhhdCB3aGF0IHlvdSBtZWFuPyA8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIzIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjojMUY0 OTdEIj4oWW91IGNvdWxkIGFsc28gZGVmaW5lIGFuIGF1dG9ub21pYyBkb21haW4gYnkgdGhlIHpv bmUgb2YgdHJ1c3Qgb2YgdGhlIGNlcnRpZmljYXRlcy4pDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMyIgY29s b3I9IiMxZjQ5N2QiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Y29sb3I6IzFGNDk3RCI+Jmx0O2pjcyZndDsgWWVzLiBOb3RlIHRoYXQgaW4gU1VQ QSwgd2UgZGVyaXZlIGludGVudCBhbmQgdHJhZGl0aW9uYWwgKGkuZS4sIEVDQSkgZnJvbQ0KIHRo ZSBzYW1lIFBvbGljeSBpbmZvIG1vZGVsLiBUaGlzIGhhcyB0aGUgbmljZSBwcm9wZXJ0eSBvZiBs ZXR0aW5nIGludGVudCB0cmFuc2xhdGUgYWNyb3NzIGFjdG9ycyBhbmQgYmUgdXNlZCB0byBmaXJl IEVDQSBwb2xpY2llcyAoYW5kIHZpY2UgdmVyc2EpLiAmbHQ7L2pjcyZndDs8bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNp emU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvZm9udD48Zm9udCBzaXplPSIy IiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPk1CMjoNCiBOZWVkIHRvIGRpc2N1c3MgdGhpcyBpbiBtb3JlIGRl dGFpbCwgaW4gUHJhZ3VlIDstKSA8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5QYWdlIDUsIHNlbGYt bWFuYWdlbWVudDxicj4NCiZxdW90O1RoZXkgY29uZmlndXJlIHRoZW1zZWx2ZXMsIGJhc2VkIG9u IHNlbGYta25vd2xlZGdlLCBkaXNjb3ZlcnksIGFuZCBJbnRlbnQuJnF1b3Q7PGJyPg0KVGhlIHdv cmQgJnF1b3Q7ZGlzY292ZXJ5JnF1b3Q7IGlzIGNvbmZ1c2luZyBtZS4gU3VwcG9zZSBhIG5vZGUg cnVucyBhIHV0aWxpdHkgZnVuY3Rpb24gdG8gZGVjaWRlIHdoYXQgaXRzIG5leHQgY29uZmlndXJh dGlvbiBjaGFuZ2Ugc2hvdWxkIGJlLiBJdCBpcyBub3QgJnF1b3Q7ZGlzY292ZXJpbmcmcXVvdDsg c29tZXRoaW5nIHRoYXQgZXhpc3RlZCAtIHJhdGhlciwgaXQgaXMgY29tcHV0aW5nIG5ldyBrbm93 bGVkZ2UuIEEgbWFjaGluZSBsZWFybmluZyBmdW5jdGlvbiB0aGF0IGluZmVycw0KIG5ldyBrbm93 bGVkZ2UgaXMgYW4gZXZlbiBiZXR0ZXIgZXhhbXBsZSBvZiBzb21ldGhpbmcgdGhhdCBpcyBub3Qg JnF1b3Q7ZGlzY292ZXJlZCZxdW90Oy4gSSdtIHByb2JhYmx5IG1pc3Npbmcgc29tZXRoaW5nLCBi dXQgd2h5IHdhcyB0aGlzIGNob2ljZSBtYWRlPzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjMiIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlRoZSB0 aGluZyB0aGF0IHJlYWxseSBib3RoZXJzIG1lIGlzIHRoYXQgdGhpcyBhc3N1bWVzIHRoYXQgYWxs IGtub3dsZWRnZSBjYW4gYmUgZGlzY292ZXJlZCAtIHRoYXQgaXMsIGl0IGlzDQogZXhpc3Rpbmcs IGxpa2UgYW4gYXBwbGUgb24gYSB0cmVlLCByZWFkeSB0byBiZSBwbHVja2VkLiBJbiB0aGUgYXV0 b25vbWljIHN5c3RlbXMgdGhhdCBJJ3ZlIGJ1aWx0LCB0aGlzIGlzIG9ubHkgc29tZXRpbWVzIHRo ZSBjYXNlLiBJdCBpcyB2aXRhbCBmb3IgYW4gYXV0b25vbWljIHN5c3RlbSB0byBiZSBhYmxlIHRv IGxlYXJuIG5ldyBrbm93bGVkZ2UgdmlhIGNvbXB1dGF0aW9uIGFuZCBpbmZlcmVuY2UsIGFzIHdl bGwgYXMgZGVjaWRlIHRoYXQgcHJldmlvdXMNCiBrbm93bGVkZ2Ugd2FzIGluY29ycmVjdC4gTmVp dGhlciBvZiB0aGVzZSBhcmUgZGlzY292ZXJ5IGZ1bmN0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIyIiBjb2xvcj0i IzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJp Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TUI6IEkgdGhpbmsg dGhlIGNvbmZ1c2lvbiBpcyB0aGUgZGVmaW5pdGlvbiBvZiDigJxkaXNjb3ZlcnnigJ0NCiBoZXJl LiBJdOKAmXMgbm90IG9ubHkgZGlzY292ZXJ5IGluIHRoZSBzZW5zZSBvZiBzZXJ2aWNlIGRpc2Nv dmVyeSwgYnV0IGZvciBleGFtcGxlLCBmaW5kaW5nIG5laWdoYm9ycywgbmVnb3RpYXRpbmcgcGFy YW1ldGVycyB3aXRoIHRoZW0sIGV0Yy4NCjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNl PSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhl IGFib3ZlIHBocmFzZSBpbiBvdGhlciB3b3Jkczog4oCcSSBrbm93IG15IGNhcGFiaWxpdGllcywN CiBJIHNlZSB3aGF0IGVsc2UgaXMgdGhlcmUgKGFuZCB0YWxrIHRvIGl0IHBvdGVudGlhbGx5KSwg YW5kIEkgc2VlIHdoYXQgdGhlIGJvc3Mgd2FudHMgdG8gaGFwcGVuIChpbnRlbnQpLiBCYXNlZCBv biBhbGwgb2YgdGhpcyBJIGRlY2lkZSB3aGF0IEnigJltIGdvaW5nIHRvIGRv4oCdLg0KPC9zcGFu PjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6 ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHRoaW5rIGl04oCZcyBhIHF1ZXN0aW9uIG9mIHdvcmRp bmcuIFdlIGhhZCB0aGlzIGdyYXBoaWMNCiAoc2ltaWxhciB0byBmaWd1cmUgMSksIHdoZXJlIHRo ZXJlIGFyZSB0aGUgMyBpbnB1dCB2ZWN0b3JzICghKSBvZiBpbmZvcm1hdGlvbiwgb24gd2hpY2gg eW91IGJhc2UgeW91ciBkZWNpc2lvbnMuIFRoZSBpbmZlcmVuY2UgeW91IG1lbnRpb24gaXMgYSBj b25zZXF1ZW5jZSBvZiB0aG9zZSBpbnB1dHMuIEluIG90aGVyIHdvcmRzLCB0aGUg4oCcYnJhaW7i gJ0gdGhhdCBhY3R1YWxseSBtYWtlcyB0aGUgaW5mZXJlbmNlLCBpcyBpbiBvdXIgbW9kZWwgdGhl DQogYXV0b25vbWljIHNlcnZpY2UgYWdlbnQuIDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjMiIGNv bG9yPSIjMWY0OTdkIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2NvbG9yOiMxRjQ5N0QiPkRvZXMgdGhhdCBtYWtlIHNlbnNlPw0KPG86cD48L286 cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250 IHNpemU9IjMiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiMxRjQ5N0QiPiZsdDtqY3MmZ3Q7IEkgdGhpbmsg c28uIEkgc3RpbGwgdGhpbmsgdGhhdCBteSB0d28gZXhhbXBsZXMgYXJlIG5vdCBkaXNjb3Zlcnku IEkgaGFkDQogc29tZWhvdyBjb25jbHVkZWQgdGhhdCBkaXNjb3Zlcnkgd2FzIGFsbC1pbmNsdXNp dmUsIGJ1dCB3aGVuIEkgbG9vayBhdCB5b3VyIGFuc3dlciwgSSByZWFsaXplIHRoYXQgaXQgaXNu J3QuIFN0aWxsLCBpbiB0aGUgcmVmZXJlbmNlIGRvY3VtZW50LCBJIHRoaW5rIHdlIHNob3VsZCBw b2ludCB0aGlzIG91dC4gSSBkbyBhZ3JlZSB0aGF0IGRpc2NvdmVyeSBpcyBzb21ldGltZXMgbm90 IGV4cGxpY2l0bHkgbWVudGlvbmVkLCB3aGljaCBpcyBhIHNoYW1lLA0KIHNpbmNlIGl0IGlzIHN1 Y2ggYSB2aXRhbCBmdW5jdGlvbi4gSXQgd291bGQgdGhlcmVmb3JlIGJlIE9LIGltaG8gdG8gZW1w aGFzaXplIGRpc2NvdmVyeSBhcyBsb25nIGFzIHdlIGxlYXZlIHNvbWUgd2lnZ2xlIHJvb20gZm9y IGR5bmFtaWNhbGx5IGNyZWF0aW5nIGFuZCByZW1vdmluZyBrbm93bGVkZ2UuICZsdDsvamNzJmd0 OzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NQjI6IEl0IHdvdWxkIGhlbHAg bWUgaWYgeW91IGNvdWxkIHN1Z2dlc3Qgd2hlcmUgaW4NCiB0aGUgZG9jIHRvIG1ha2UgdGhvc2Ug Y2hhbmdlcy4gPC9zcGFuPjwvZm9udD48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFj ZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlBhZ2UgNiwgbGFzdCBwYXJhZ3JhcGggYWJvdmUg c2VjdGlvbiAzLjI8YnI+DQomcXVvdDsuLi5jbG9zZWQtbG9vcCBjb250cm9sIGlzIGFuIGltcG9y dGFudCBhc3BlY3Qgb2Ygc2VsZi1tYW5hZ2luZyBzeXN0ZW1zLiA8bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBz aXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij5UaGlzIGltcGxpZXMgcGVlci10by1wZWVyIGRpYWxvZ3VlcyBiZXR3ZWVuIHRoZSBwYXJ0 aWVzIHRoYXQgbWFrZSB1cA0KPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+dGhlIGNsb3NlZCBsb29w LiBTdWNoIGRpYWxvZ3VlcyByZXF1aXJlIHR3by13YXkgJnF1b3Q7ZGlzY3Vzc2lvbiZxdW90OyBv ciAmcXVvdDtuZWdvdGlhdGlvbiZxdW90Ow0KPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMyIgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+YmV0d2Vl biBlYWNoIHBhaXIgb3IgZ3JvdXBzIG9mIHBlZXJzIGludm9sdmVkIGluIHRoZSBsb29wLC4uLiZx dW90Ozxicj4NCkZpcnN0LCBieSAmcXVvdDtwZWVyJnF1b3Q7LCBJIGFzc3VtZSB5b3UgbWVhbiB0 d28gKG9yIG1vcmUpIGVxdWlwb3RlbnQgZW50aXRpZXMgdGhhdCBtYWtlIHNvbWUgcG9ydGlvbiBv ZiB0aGVpciByZXNvdXJjZXMgYXZhaWxhYmxlIHRvIG90aGVycy4gU2Vjb25kLCBhbmQgbW9yZSBp bXBvcnRhbnRseSwgYSBjbG9zZWQgY29udHJvbCBsb29wIGRvZXMgbm90IHJlcXVpcmUgZWFjaCBl bnRpdHkgaW4gdGhlIGNsb3NlZCBjb250cm9sIGxvb3AgdG8gdGFsayB0byBuZWdvdGlhdGUNCiB3 aXRoIG90aGVyIGVudGl0aWVzLiBOb3csIGluIGFuIGF1dG9ub21pYyBjb250cm9sIGxvb3AsIHRo aXMgY291bGQgdmVyeSB3ZWxsIGJlIHRoZSBjYXNlLCBidXQgaXQgaXMgdW5jbGVhciB0byBtZSB3 aHkgaXQgTVVTVCBiZSB0aGUgY2FzZS4gVGhlIG9idmlvdXMgbmlnaHRtYXJlIHNjZW5hcmlvIGlz IHRoYXQgdGhlIG5lZ290aWF0aW9uIGZhaWxzLiBUaGVuIHdoYXQgLSB3ZSBoYXZlIG5vIGNvbnRy b2wgbG9vcCBhdCBhbGw/PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMyIgY29sb3I9IiMxZjQ5N2Qi IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMyIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6IzFGNDk3RCI+ TUI6IEkgZ3Vlc3MgeW91ciBwb2ludCBpcyB0aGF0IGFuIGF1dG9ub21pYyBwcm9jZXNzIGRvZXNu 4oCZdCBIQVZFIHRvIGhhdmUgYSBjb250cm9sDQogbG9vcC4gSSB3b3VsZCBhcmd1ZSB0aGF0IHRo ZSB0eXBpY2FsIGF1dG9ub21pYyBmdW5jdGlvbiBET0VTIGhhdmUgbm9kZS10by1ub2RlIGludGVy YWN0aW9ucy4gVGhpcyBpcyB3aGF0IGF1dG9ub21pY3MgaXMgYWxsIGFib3V0LiBOb3csIHllcywg dGhlcmUgd2lsbCBiZSBjYXNlcyB3aGVyZSB0aGlzIGZhaWxzLCBhbmQgd2hlcmUgYSBub2RlIGFs c28gbmVlZHMgdG8gZG8gc29tZXRoaW5nIHNlbnNpYmxlIGluIGNhc2Ugb2YgY29tcGxldGUgaXNv bGF0aW9uLg0KIEJ1dCB0aGF04oCZcyBhbiBleGNlcHRpb24gc3RhdGUgaW4gbXkgbWluZC4gPG86 cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i Pjxmb250IHNpemU9IjMiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiMxRjQ5N0QiPiZsdDtqY3MmZ3Q7IE5v LiBMZXQgbWUgdHJ5IGFnYWluLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjMiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiMxRjQ5N0Qi PlRoZSB0ZXh0IHRoYXQgYm90aGVycyBtZSBpcyAmcXVvdDtbY2xvc2VkLWxvb3BdIGltcGxpZXMg cGVlci10by1wZWVyIGRpYWxvZ3VlcyBiZXR3ZWVuDQogdGhlIHBhcnRpZXMgdGhhdCBtYWtlIHVw IHRoZSBjbG9zZSBsb29wJnF1b3Q7LiBUaGF0IGlzbid0IGhvdyB0cmFkaXRpb25hbCBjb250cm9s IGxvb3BzIGFyZSB0eXBpY2FsbHkgYnVpbHQsIGFuZCBJJ20gcGVyc29uYWxseSBub3QgZmFtaWxp YXIgd2l0aCBhbnkgYXV0b25vbWljIHN5c3RlbSB0aGF0IGJ1aWxkcyB0aGVtIGluIHRoaXMgd2F5 LiBTdXJlLCBpdCB3b3VsZCBiZSBuaWNlIHRvIGFsbG93IHRoaXMgd2hlbiBuZWNlc3NhcnkgLSBG T0NBTEUgaGFkDQogdGhpcyBmZWF0dXJlIHRocm91Z2ggYSBkZWRpY2F0ZWQgY29udHJvbCBpbnRl cmZhY2UgdGhhdCBjb3VsZCBhZGFwdCB0aGUgZnVuY3Rpb24gY2FycmllZCBvdXQgYnkgYSBjb250 cm9sIGxvb3AgZWxlbWVudCBiYXNlZCBvbiAoZm9yIGV4YW1wbGUpIGNoYW5naW5nIGNvbnRleHQg LSBidXQgSSBkaXNhZ3JlZSB0aGF0IGl0IGlzIGEgTUFOREFUT1JZIGZ1bmN0aW9uLjxvOnA+PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9 IjMiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2NvbG9yOiMxRjQ5N0QiPk1CMjogV2UgbmVlZCB0byBkaXNjdXNzIHRo aXMgYXMgd2VsbCBpbiBQcmFndWUuIEkgaGF2ZSB0aGUgZmVlbGluZyB3ZeKAmXJlIG5vdCB0YWxr aW5nDQogYWJvdXQgdGhlIHNhbWUgdGhpbmcuIDwvc3Bhbj48L2ZvbnQ+PGZvbnQgY29sb3I9IiMx ZjQ5N2QiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIzIiBjb2xvcj0iIzFm NDk3ZCIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjojMUY0OTdEIj5UbyB5b3VyIHNlY29uZCBwb2ludCwgSSBkbyAob2YgY291cnNlISkg YWdyZWUgdGhhdCBhdXRvbm9taWNzIGlzIGFib3V0IG5vZGUtdG8tbm9kZQ0KIGludGVyYWN0aW9u cy4gQnV0LCBpdCBpcyBhbHNvIGFib3V0IHN5c3RlbS13aWRlIGludGVyYWN0aW9ucy4gTXkgcG9p bnQgd2FzIHRoYXQgaWYgeW91IG1hbmRhdGUgbmVnb3RpYXRpb24gaW4gb3JkZXIgdG8gY3JlYXRl IGEgY29udHJvbCBsb29wLCBhbmQgdGhlIG5lZ290aWF0aW9uIGZhaWxzLCB5b3UncmUgaW4gdHJv dWJsZS4gQW5kIHllcywgdGhhdCB3b3VsZCBiZSBhbiBleGNlcHRpb24gc3RhdGUgaW4gbXkgbWlu ZCwgYXMgaXQgdmlvbGF0ZXMNCiBhIGJhc2ljIHByaW5jaXBsZSBpbiBhdXRvbm9taWNzIC0gY29u c2Vuc3VhbCBiZWhhdmlvci4gJmx0Oy9qY3MmZ3Q7PG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIyIiBjb2xvcj0i IzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlBhZ2VzIDctOCwgU2VjdGlv biAzLjY8YnI+DQpNb3N0IGF1dG9ub21pYyBuZXR3b3JraW5nIHN5c3RlbXMgdG8gZGF0ZSBoYXZl IE5PVCBiZWVuIGJ1aWx0IHdpdGggYW4gaW50ZW50IChvciBkZWNsYXJhdGl2ZSkgc3R5bGUgaW50 ZXJmYWNlLiBGT0NBTEUgZW5hYmxlcyBkZWNsYXJhdGl2ZSBhbmQgcHJlc2NyaXB0aXZlIChlLmcu LCBFQ0EgcG9saWN5IHJ1bGVzKSB0byBiZSB1c2VkLiBPdGhlcnMganVzdCB1c2UgRUNBIChvciBh biBlcXVpdmFsZW50KSBwYXJhZGlnbS4gSGVuY2UsIEknbSB3b25kZXJpbmcNCiB3aHkgaW50ZW50 IGlzIHRoZSBPTkxZIHBhcmFkaWdtIHRoYXQgaXMgbWVudGlvbmVkIGluIHRoaXMgUkZDIHRoYXQg aXMgc3VpdGFibGUgZm9yIGF1dG9ub21pYyBuZXR3b3JraW5nPyBTaG91bGRuJ3Qgd2UgdHJ5IGFu ZCBwZWFjZWZ1bGx5IGNvZXhpc3QsIGp1c3QgYXMgdGhlIG5vZGVzIGFyZSBwZWFjZWZ1bGx5IGNv ZXhpc3Rpbmcgd2l0aCBub24tYXV0b25vbWljIGRpcmVjdGl2ZXM/PG86cD48L286cD48L3NwYW4+ PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQg c2l6ZT0iMyIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvZm9udD48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMiIgY29s b3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5NQjogVG8gbWUsIEVDQSBpcyBlbmNvZGVkIGluIGFuIEFTQSBvciBhbiBh dXRvbm9taWMNCiBmdW5jdGlvbi4gVGhlIGZ1bmN0aW9uIHNheXMgd2hhdCBhY3Rpb24geW91IHRh a2UgaW4gc3BlY2lmaWMgZXZlbnRzLCBhbmQgdW5kZXIgd2hpY2ggY29uZGl0aW9uLg0KPC9zcGFu PjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6 ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5FeGFtcGxlOiBUaGUg4oCcZW5yb2xtZW50IHByb3h5IEFT QeKAnSBoYXMgdGhlIGZvbGxvd2luZw0KIChoYXJkIGNvZGVkKSBFU0E6IDwvc3Bhbj48L2ZvbnQ+ PG86cD48L286cD48L3A+DQo8cD48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0i Q2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi08L3Nw YW4+PC9mb250Pjxmb250IHNpemU9IjEiIGNvbG9yPSIjMWY0OTdkIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvZm9udD48Zm9udCBzaXplPSIyIiBj b2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkV2ZW50OiBBIG5ldyBub2RlIGlzIGRldGVjdGVkPC9zcGFuPjwvZm9u dD48bzpwPjwvbzpwPjwvcD4NCjxwPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNl PSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LTwv c3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMSIgY29sb3I9IiMxZjQ5N2QiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9mb250Pjxmb250IHNpemU9IjIi IGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Q29uZGl0aW9uOiBpdCBkb2VzbuKAmXQgaGF2ZSBhIGRvbWFpbiBj ZXJ0IHlldA0KPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwPjxmb250IHNpemU9IjIi IGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+LTwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMSIgY29sb3I9IiMx ZjQ5N2QiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PC9mb250Pjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWN0aW9uOiBJIGludml0ZSB0 aGUgbm9kZSB0byBqb2luIG15IG5ldHdvcmsuDQo8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIg ZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi Pk5vdywgSW50ZW50IGlzIGluIG15IG1pbmQgYSBoaWdoZXIgbGV2ZWwgY29uY2VwdCB3aGljaA0K IGNvdWxkIG5vdyBzdGF0ZSDigJxkbyBub3QgZW5yb2wgbmV3IG5vZGVzIGF0IHRoaXMgbW9tZW50 4oCdLiA8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48Zm9udCBzaXplPSIzIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjojMUY0OTdEIj5Ib3cgd291bGQgeW91 IHNlZSB0aGF0Pw0KPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjMiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiMxRjQ5N0Qi PiZsdDtqY3MmZ3Q7IElzIHRoZSBhY3Rpb24gYSB0eXBvLCBhbmQgeW91IHJlYWxseSBtZWFudDog JnF1b3Q7SSBkbyBub3QgaW52aXRlIHRoZSBub2RlIHRvDQogam9pbiBteSBuZXR3b3JrJnF1b3Q7 PyA8L3NwYW4+PC9mb250Pjxmb250IGNvbG9yPSIjMWY0OTdkIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NQjI6IE5vLCB0aGlzIGlzIHRo ZSBhY3R1YWwgYmVoYXZpb3VyIG9mIGEgYm9vdHN0cmFwDQogcHJveHkuIElmIGEgbm9kZSBpcyBu ZXcgYW5kIGRvZXNu4oCZdCBoYXZlIGEgZG9tYWluIGNlcnQgeWV0LCB5b3UgaW52aXRlIGl0IHRv IGpvaW4gdGhlIGRvbWFpbiAoY29udHJvbGxlZCBieSB0aGUgcmVnaXN0cmFyIG9mIGNvdXJzZSku IEFueXdheSwgdGhhdOKAmXMgYSBkZXRhaWwgSSB0aGluay4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjMiIGNvbG9yPSIj MWY0OTdkIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2NvbG9yOiMxRjQ5N0QiPkFzIHN0YXRlZCwgSSB3b3VsZCBzYXkgdGhhdCB0aGUgRUNBIHBv bGljeSB3b3VsZCBOT1QgZmlyZSBiZWNhdXNlIGl0IHZpb2xhdGVzDQogaW50ZW50LiBIb3dldmVy LCB0byBteSBlYXJsaWVyIHBvaW50IGFib3ZlIGFib3V0IGludGVudCBhbmQgRUNBIHBvbGljaWVz IGJlaW5nIGFibGUgdG8gY2FsbCBlYWNoIG90aGVyIC0gQUJTT0xVVEVMWS4gJmx0Oy9qY3MmZ3Q7 PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+ PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NQjI6DQogSSB0aGluayB3ZeKAmXJlIGFj dHVhbGx5IG9uIHRoZSBzYW1lIHBhZ2UgaGVyZSwgYW5kIGl04oCZcyBhIHF1ZXN0aW9uIG9mIHdv cmRpbmcuIDwvc3Bhbj4NCjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+UGFnZSA5LCBzZWN0aW9uIDMuNzxicj4N CiZxdW90O0hvd2V2ZXIsIGluIGFuIEF1dG9ub21pYyBOZXR3b3JrLCByZXBvcnRpbmcgc2hvdWxk IGhhcHBlbiBvbiBhIG5ldHdvcmstd2lkZSBiYXNpcy4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBz aXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij5UcnVlLCBidXQgc2hvdWxkbid0IGluZGl2aWR1YWwgbm9kZXMgYW5kIGNvbGxlY3Rpb25z IG9mIG5vZGVzIHN0aWxsIHJlcG9ydD8gVGhhdCBpc24ndCBpbXBsaWVkIGluIHRoZSB3b3JkaW5n LjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxm b250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMyIgY29sb3I9IiMx ZjQ5N2QiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Y29sb3I6IzFGNDk3RCI+TUI6IFllcywgdGhleSBzaG91bGQuIFRoaXMgaXMg4oCcdHJhZGl0 aW9uYWwgbWFuYWdlbWVudCBtZXRob2Rz4oCdLiBJbiBvdXIgbW9kZWwsDQogZXZlcnkgbm9kZSBk b2VzIHRoZSBub3JtYWwgc3lzbG9nLCBldGMuLCBhbmQgYWdncmVnYXRlZCByZXBvcnRpbmcgaXMg dGhlIG5ldyB0aGluZyB0aGF0IGNvbWVzIHdpdGggQU4uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMyIgY29s b3I9IiMxZjQ5N2QiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Y29sb3I6IzFGNDk3RCI+Jmx0O2pjcyZndDsgR290IGl0LCB0aGFua3MuICZsdDsv amNzJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmki PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij5GdXJ0aGVybW9yZSwgdGhlIGxhc3QgcGFyYWdyYXBoIHNheXM6ICZx dW90O0F1dG9ub21pYyBuZXR3b3JrIGV2ZW50cyBzaG91bGQgY29uY2VybiB0aGUgQXV0b25vbWlj IE5ldHdvcmsgYXMgYSB3aG9sZSwNCiBub3QgaW5kaXZpZHVhbCBzeXN0ZW1zIGluIGlzb2xhdGlv bi4mcXVvdDsgSSBhZ3JlZSB0aGF0IHRoZSBnb2FsIGlzIHRvIHJlcG9ydCBvbiB0aGUgc3lzdGVt IGFzIGEgd2hvbGUsIGJ1dCBpc24ndCBzdWNoIGEgcmVwb3J0IGNvbGxlY3RlZCBmcm9tIGluZGl2 aWR1YWwgbm9kZXM/IEp1c3QgbGlrZSBpbiB5b3VyIGV4YW1wbGUsIHRoZSBub2RlcyBuZWVkIHRv IGJlIGFibGUgdG8gc2VlIHRoYXQgYSBwcm9ibGVtIGhhcyBhbHJlYWR5IGJlZW4gcmVwb3J0ZWQN CiBpbiBvcmRlciB0byBrbm93IG5vdCB0byBpc3N1ZSB0aGUgc2FtZSBwcm9ibGVtLjxvOnA+PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxmb250IHNpemU9IjMiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNp emU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TUI6IFRoZXJlIGFyZSB0d28gcGFyYWxsZWwgbWV0aG9k cyBvZiByZXBvcnRpbmc6DQo8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHA+PGZvbnQg c2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4xKTwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMSIg Y29sb3I9IiMxZjQ5N2QiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9mb250Pjxmb250IHNp emU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+dGhlIHRyYWRpdGlvbmFsIGV2ZXJ5LW5vZGUtdG8tY29u dHJvbGxlciBtZXRob2QsIHdoZXJlIHRoZSBpbnRlbGxpZ2VuY2UgaXMgY2VudHJhbDwvc3Bhbj48 L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cD48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIg ZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjIpPC9zcGFuPjwvZm9udD48Zm9udCBzaXplPSIxIiBjb2xvcj0iIzFmNDk3ZCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZh Y2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5h IGRpc3RyaWJ1dGVkIHJlcG9ydGluZyBmdW5jdGlvbiwgd2hlcmUgbm9kZXMgYWdncmVnYXRlLCBw cm9jZXNzLCBzdW1tYXJpc2UsIGNvcnJlbGF0ZSwg4oCmICZuYnNwO2luZm9ybWF0aW9uIGJlZm9y ZSBoYW5kaW5nDQogaXQgdG8gdGhlIGNvbnRyb2xsZXIuIEhlcmUgdGhlIGludGVsbGlnZW5jZSBp cyBkaXN0cmlidXRlZC4gPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMyIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6IzFGNDk3RCI+Qm90 aCB3aWxsIGNvLWV4aXN0LiBUaGUgUkZDIGZvY3VzZXMgb24gdGhlIG5ldyBtZXRob2QgKGFuZCBv YnZpb3VzbHkgaXNu4oCZdCBjbGVhcg0KIGVub3VnaCBhYm91dCBpdOKApikgPG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNp emU9IjMiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiMxRjQ5N0QiPiZsdDtqY3MmZ3Q7IE9LLCBnb3QgaXQu IEluIEZPQ0FMRSwgd2UgYWxtb3N0IE5FVkVSIHVzZWQgbm9kZS10by1jb250cm9sbGVyICh3ZWxs LCBGT0NBTEUNCiBwcmVkYXRlcyBTRE4gY29udHJvbGxlcnMsIGJ1dCBsZXQncyBzYXkgY29udHJv bGxlciA9PSBzb21lIGNlbnRyYWxpemVkIG1hbmFnZXIpIHVubGVzcyB0aGUgbWFqb3JpdHkgKG9y IG1vcmUpIG9mIG5vZGVzIGZhaWxlZC4gV2UgZGlkIHVzZSBhbiB1bWJyZWxsYSBtYW5hZ2VtZW50 IHBhcmFkaWdtIChzaW1pbGFyIHRvIGNsdXN0ZXJoZWFkcyBpbiBQMlAgbmV0d29ya3MpLCB3aGVy ZSB0aGUgY2x1c3RlcmhlYWRzIGRpZCBjb2xsZWN0aW9uLCBmaWx0ZXJpbmcsDQogY29ycmVsYXRp b24sIGFuZCBwb3NzaWJseSBvdGhlciBmdW5jdGlvbnMgYmVmb3JlIHBhc3NpbmcgdGhlIGRhdGEg KG5vdCBuZWNlc3NhcmlseSB1cCEpLiBJJ20gaGFwcHkgdG8gZm9jdXMgb24gdGhlIG5ldywganVz dCB3YW50IHRvIGVuc3VyZSB3ZSBoYXZlIHNvbWUgZmFsbGJhY2sgcG9zaXRpb24gZm9yIG5vdCBq dXN0IGxlZ2FjeSBpbnRlZ3JhdGlvbiwgYnV0IG1vcmUgaW1wb3J0YW50bHksIGZhaWx1cmUgbW9k ZXMuICZsdDsvamNzJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9 IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PC9mb250Pjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxp YnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TUIyOg0KIEFj ay4gKEkgdGhpbmspIDwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2Qi IGZhY2U9IldpbmdkaW5ncyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPko8L3NwYW4+PC9mb250Pjxmb250IHNpemU9IjIi IGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+DQogJm5ic3A7Jm5ic3A7QW5kIEkgc3RhcnQgdG8gdW5kZXJzdGFu ZCB3aGVyZSBzb21lIG9mIG91ciBjb25mdXNpb25zIGFyZSBjb21pbmcgZnJvbS4gRk9DQUxFIGRv ZXMgaGF2ZSBhIGRpZmZlcmVudCBtb2RlbCBJIHRoaW5rLiBOZWVkcyBtb3JlIGRpc2N1c3Npb24u PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+UGFnZXMgMTItMTMsIHNlY3Rpb24gNTxicj4NCldoeSBp cyBhbiBBdXRvbm9taWMgKipVc2VyKiogQWdlbnQgdGhlIGludGVyZmFjZSB0byBhIGNvbnRyb2wg bG9vcD8gSSBjYW4gc2VlIGFuIGV4dGVybmFsIGVudGl0eSB3YW50aW5nIHRvIGNvbmZpZ3VyZSBh bmQgbW9uaXRvciB0aGUgY29udHJvbCBsb29wLCBidXQgd2h5IHdvdWxkbid0IHRoZSBVc2VyIEFn ZW50IHRhbGsgdG8gdGhlIFNlcnZpY2UgQWdlbnQgdG8gZG8gdGhpcz8gSSBkbyBub3RlIHRoYXQg dGhpcyBmaWd1cmUgaXMgdW5kZXIgZGlzY3Vzc2lvbg0KIGFuZCBiZWluZyByZXZpc2VkIGluIHRo ZSByZWZlcmVuY2UgbW9kZWwuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMyIgY29sb3I9IiMxZjQ5 N2QiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNh bGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NQjogWWVz LCB0aGF04oCZcyBjb25mdXNpbmcgd29yZGluZywgYW5kIG5vdyB0aGF0IHlvdQ0KIG1lbnRpb24g aXQsIHllcyB3ZSBzaG91bGQgaGF2ZSBwcm9iYWJseSBsb29rZWQgZm9yIGEgYmV0dGVyIHRlcm0u IFRoZSBpZGVhIGlzOiBUaGUg4oCcaW50ZWxsaWdlbmNl4oCdIG9mIGFuIGF1dG9ub21pYyBmdW5j dGlvbiBpcyBpbiB0aGUgQVNBIChtaWRkbGUgb2YgZmlndXJlIDEpLiBUaGVyZSBhcmUgbm93IGhv cml6b250YWwgZmVlZGJhY2sgbG9vcHMgYW5kIG5vcnRoYm91bmQgZmVlZGJhY2sgbG9vcHMuIEZv ciBleGFtcGxlLCB0aGVyZSBpcyBsaWtlbHkNCiBhIGZ1bmN0aW9uIGluIHRoZSBlbnJvbG1lbnQg cHJvY2Vzcywgd2hlcmUgYSBtZXNzYWdlIGdldHMgc2VudCB0byB0aGUgYWRtaW46IOKAnEhlcmXi gJlzIGEgbmV3IG5vZGUsIEkgZG9u4oCZdCB0aGluayBpdCBiZWxvbmdzIGludG8gb3VyIG5ldHdv cmssIEnigJl2ZSBxdWFyYW50aW5lZCB0aGF0IG5vZGUgZm9yIG5vdzsgd291bGQgeW91IGxpa2Ug bWUgdG8gMSkgYWNjZXB0IHRoZSBub2RlIGFueXdheSwgb3IgMikgbWFyayBpdCBhcyBiYWQ/4oCd PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZv bnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIzIiBjb2xvcj0iIzFm NDk3ZCIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjojMUY0OTdEIj5JIGFncmVlIHRoZSB0ZXJtIOKAnHVzZXIgYWdlbnTigJ0gaXMgbm90 IGdvb2QuIFdlIG5lZWQgdG8gZmluZCBhIGJldHRlciBvbmUuIFN1Z2dlc3Rpb25zPw0KPG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxm b250IHNpemU9IjMiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiMxRjQ5N0QiPiZsdDtqY3MmZ3Q7IFNvIGRv ZXMgJnF1b3Q7dXNlciBhZ2VudCZxdW90OyBtZWFuICZxdW90OyhhdXRvbm9taWMpIG1hbmFnZW1l bnQgYWdlbnQmcXVvdDs/IFByb2JhYmx5IE5PVCBhDQogdXNlci1mYWNpbmcgYWdlbnQsIHJpZ2h0 PyBJbiB0aGUgdHJhZGl0aW9uIG9mIENhbG0gVGVjaG5vbG9neSwgdGhlIGJlc3QgYW5kIG1vc3Qg dWJpcXVpdG91cyBmdW5jdGlvbnMgYXJlIHRob3NlIHRoYXQgZG9uJ3QgZGVtYW5kIGF0dGVudGlv biwgYnV0IHJhdGhlciBpbmZvcm0uICZsdDsvamNzJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u dD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMiIgY29s b3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9mb250Pjxmb250IHNpemU9IjIiIGNvbG9yPSIj MWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+TWIyOg0KIE1heWJlIHRoYXTigJlzIHRoZSByaWdodCB0ZXJtLiBOZWVkIHRvIHRo aW5rIG1vcmXigKYgPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+UGFnZSAxMywgRmlndXJlIDE8YnI+ DQpXaGVyZSBpcyB0aGUgQXV0b25vbWljIE5vZGUgaW4gdGhlIFJlZmVyZW5jZSBNb2RlbD8gSSBk byBub3RlIHRoYXQgdGhpcyBmaWd1cmUgaXMgdW5kZXIgZGlzY3Vzc2lvbiBhbmQgYmVpbmcgcmV2 aXNlZCBpbiB0aGUgcmVmZXJlbmNlIG1vZGVsLiBIb3dldmVyLCBldmVuIGluIEZpZ3VyZSAyIG9m IHRoZSByZWZlcmVuY2UgbW9kZWwsIGl0IGlzIHN0aWxsIHVuY2xlYXIgd2hhdCB0aGUgJnF1b3Q7 bm9kZSZxdW90OyBpcy4gQnV0IG1vcmUgb24gdGhhdCBsYXRlci48YnI+DQo8YnIgY2xlYXI9ImFs bCI+DQo8Zm9udCBjb2xvcj0iIzFmNDk3ZCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPk1C OiBUaGUgd2hvbGUgdGhpbmcgaXMgdGhlIG5vZGUuIFRoYXTigJlzIHdoeSB0aGUgZmlndXJlIGlz IGNhbGxlZCDigJxSZWZlcmVuY2UgTW9kZWwgZm9yIGFuIEF1dG9ub21pYyBOb2Rl4oCdLg0KPC9z cGFuPjwvZm9udD48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48Zm9udCBzaXplPSIzIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjojMUY0OTdEIj4mbHQ7amNz Jmd0OyBCdXQgaWYgaXQgaXMgYSAqKm5vZGUqKiwgdGhlbiB3aHkgaXMgaXQgcnVubmluZyBpdHMg b3duIGludGVybmFsIGZlZWRiYWNrDQogbG9vcHM/IE5vdGUgdGhhdCAmcXVvdDtub2RlJnF1b3Q7 IGltcGxpZXMgYSBzaW5nbGUgc29tZXRoaW5nLiBDbGVhcmx5LCB0aGUgc2luZ2xlIHNvbWV0aGlu ZyBjYW4gY29udGFpbiBncm91cHMgb2Ygb3RoZXIgc29tZXRoaW5ncywgYnV0IHdoeSB3b3VsZCBh IGZlZWRiYWNrIGxvb3AgZXhpc3QgaW4gdGhlIHNpbmdsZSBzb21ldGhpbmcgd2hlbiB3ZSBhcmUg ZW1waGFzaXppbmcgaW50ZXItbm9kZSBjb21tdW5pY2F0aW9uIGFuZCBmdW5jdGlvbmFsaXR5Pzwv c3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250 IHNpemU9IjMiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiMxRjQ5N0QiPk1CMjogV2hlcmUgZG8geW91IHNl ZSBhIGZlZWRiYWNrIGxvb3AgaW4gdGhlIG5vZGU/IT8gSSBkb27igJl0ISZuYnNwOw0KPC9zcGFu PjwvZm9udD48Zm9udCBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iV2luZ2RpbmdzIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPko8L3NwYW4+PC9mb250Pjxm b250IGNvbG9yPSIjMWY0OTdkIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+DQo8L3NwYW4+ PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXpl PSIzIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjojMUY0OTdEIj5JIHRoaW5rIHRoYXQgdGhpcyBmaWd1cmUg d291bGQgYmUgaW1wcm92ZWQgYnkgc2hvd2luZyBpbnRlcmZhY2VzIHRvIHRoZSBBdXRvbm9taWMN CiBDb250cm9sIFBsYW5lIGFuZCB0byB0aGUgT1M7IHJpZ2h0IG5vdywgdGhleSBhcmUgaW5zaWRl IG9mIHRoZSBub2RlLCBhbmQgdGhhdCBJIGRvbid0IHVuZGVyc3RhbmQuIEluIEZPQ0FMRSwgYXMg d2VsbCBhcyBvdGhlciBhcmNoaXRlY3R1cmVzLCBrbm93bGVkZ2UgZGlkIG5vdCBoYXZlIHRvIGJl IGVtYmVkZGVkIGluIHRoZSBub2RlLCBpdCBjb3VsZCBiZSByZWNlaXZlZCBmcm9tIG90aGVyIHBs YWNlcyBpbiB0aGUgbmV0d29yay4gSGVuY2UsIEkNCiB0aGluayB0aGF0IHNob3dpbmcgaW50ZXJm YWNlcyB0byB3aGVyZSBrbm93bGVkZ2UgaXMgb2J0YWluZWQgYW5kIHdoZXJlIGl0IGlzIGRpc2Nv dmVyZWQgaXMgbW9yZSBnZW5lcmljLiBPZiBjb3Vyc2UsIG1vcmUgY2FwYWJsZSBub2RlcyBjb3Vs ZCBjb250YWluIHRoZXNlIGZ1bmN0aW9ucywgYnV0IEknbSBub3QgY29udmluY2VkIHRoYXQgdGhp cyBpcyB0aGUgbm9ybS4gJmx0Oy9qY3MmZ3Q7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMyIgY29sb3I9IiMxZjQ5N2QiIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMyIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6IzFGNDk3RCI+VGhh bmtzIGZvciBhbGwgeW91ciBpbnB1dCBKb2huISBMZXTigJlzIG1ha2Ugc3VyZSB0aGF0IGFsbCB0 aGVzZSBwb2ludHMgZ2V0IGFkZHJlc3NlZA0KIGluIHRoZSByZWZlcmVuY2UgbW9kZWwuIDwvc3Bh bj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNp emU9IjMiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiMxRjQ5N0QiPiZsdDtqY3MmZ3Q7IEkgaG9wZSBpdCBo ZWxwcy4gSSB0aGluayBJIGNhbiBub3cgd3JpdGUgbXkgc2VjdGlvbnMgaW4gYSB3YXkgdGhhdCB3 aWxsDQogYmUgbW9yZSBjb25zaXN0ZW50LiBNb3JlIGZlZWRiYWNrIGNvbWluZyBsYXRlci4gJmx0 Oy9qY3MmZ3Q7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PGZvbnQgc2l6ZT0iMyIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjwvZm9udD48Zm9udCBjb2xvcj0iIzFmNDk3ZCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPk1CMjogVGhhbmtzIGZvcg0KIGZlZWRiYWNrLiBJIHRoaW5rIHdlIHNob3VsZCBzaW5nbGUg b3V0IHNwZWNpZmljIGlzc3VlcywgYW5kIGNyZWF0ZSBhIHNwZWNpZmljIG1haWwgdGhyZWFkIG9u IGVhY2gsIHRoaXMgb25lIGlzIHN0YXJ0aW5nIHRvIGdldCBtZXNzeQ0KPC9zcGFuPjwvZm9udD48 Zm9udCBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iV2luZ2RpbmdzIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPko8L3NwYW4+PC9mb250Pjxmb250IGNvbG9y PSIjMWY0OTdkIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+DQo8L3NwYW4+PC9mb250Pjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIyIiBjb2xv cj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPk1pY2hhZWw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2Fs aWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250 IHNpemU9IjMiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiMxRjQ5N0QiPk1pY2hhZWw8L3NwYW4+PC9mb250 PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+YmVzdCByZWdhcmRz LDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Kb2huPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIz IiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQiPk9uIE1vbiwgSnVuIDIyLCAyMDE1IGF0IDg6NDYgQU0sIE1pY2hh ZWwgQmVocmluZ2VyIChtYmVocmluZykgJmx0OzxhIGhyZWY9Im1haWx0bzptYmVocmluZ0BjaXNj by5jb20iIHRhcmdldD0iX2JsYW5rIj5tYmVocmluZ0BjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgSm9obiwgbGV0IG1l IHRha2UgYSBzdGFiIGF0IHJlc3BvbmRpbmfigKYgQW5kIHRoYW5rcw0KIGZvciBzaGFyaW5nIHlv dXIgdGhvdWdodHMuIEEgYml0IGxhdGUgdG8gYnJpbmcgdGhlbSBpbnRvIFJGQzc1NzUsIGJ1dCBh IGdvb2QgdGltaW5nIGZvciB0aGUgcmVmZXJlbmNlIG1vZGVsLg0KPC9zcGFuPjwvZm9udD48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9 IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgd2luZG93dGV4dCAxLjVwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDQuMHB0O2JvcmRlci1jb2xvcjpjdXJyZW50Q29sb3IgY3VycmVudENvbG9y IGN1cnJlbnRDb2xvciBibHVlIj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbTti b3JkZXItY29sb3I6Y3VycmVudENvbG9yIGN1cnJlbnRDb2xvciI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxiPjxmb250IHNpemU9IjIiIGZhY2U9IlRhaG9tYSI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2ZvbnQtd2VpZ2h0OmJvbGQiPkZyb206PC9zcGFuPjwvZm9u dD48L2I+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iVGFob21hIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPg0KIEFuaW1hIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmFuaW1h LWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5hbmltYS1ib3VuY2VzQGlldGYub3Jn PC9hPl0NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5PbiBCZWhhbGYgT2YgPC9z cGFuPjwvYj5Kb2huIFN0cmFzc25lcjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi b2xkIj5TZW50Ojwvc3Bhbj48L2I+IDIxIEp1bmUgMjAxNSAxOToyODxicj4NCjxiPjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5Ubzo8L3NwYW4+PC9iPiBBbmltYSBXRzxicj4NCjxiPjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0Ojwvc3Bhbj48L2I+IFtBbmltYV0g UXVlc3Rpb25zIG9uIFJGQzc1NzU8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij5JIHN0YXJ0ZWQgcmV2aWV3aW5nIGJvdGggdGhlIHJlZmVyZW5jZSBt b2RlbCBhcyB3ZWxsIGFzIG90aGVyIHBlcnRpbmVudCBkb2N1bWVudHMsIHNvIHRoYXQgd2hlbiBJ IHdyaXRlIG15IHNlY3Rpb25zDQogZm9yIHRoZSByZWZlcmVuY2UgbW9kZWwsIHRoZXkgYXJlIGNv bnNpc3RlbnQuIDotKTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxm b250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQiPkluIGRvaW5nIHNvLCBJIGhhdmUgYSBudW1iZXIgb2YgcXVlc3Rpb25zIG9uIFJG Qzc1NzUuIFBhcnQgb2YgdGhpcyBtYXkgYmUgbXkgYWNhZGVtaWMgbmF0dXJlLCBwYXJ0IG1heSBi ZSBiZWNhdXNlDQogSSBoYXZlIHVuZG91YnRlZGx5IG1pc3NlZCBzb21ldGhpbmcgaW4gcGFzdCBl bWFpbHMgYXMgSSBjb21lIHVwIHRvIHNwZWVkLCBhbmQgcGFydGx5IGJlY2F1c2UgSSdtIGxpa2Vs eSB1bmRlci1jYWZmZWluYXRlZC4gSG9wZWZ1bGx5LCBzb21lIG9mIHRoaXMgd2lsbCBoZWxwIGlt cHJvdmUgdGhlIHJlZmVyZW5jZSBtb2RlbCAoYW5kIHBvc3NpYmx5IG90aGVyIGRvY3VtZW50cyBh cyB3ZWxsKS48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBz aXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij5RdWVzdGlvbnMgb24gUkZDNzU3NTxicj4NClBhZ2UgMzxicj4NCiZxdW90O0F1dG9ub21p YyBmdW5jdGlvbnMgY2FuIGJlIGRlZmluZWQgaW4gdHdvIHdheXM6PGJyPg0KJm5ic3A7IG8gT24g YSBub2RlIGxldmVsOiBOb2RlcyBpbnRlcmFjdCB3aXRoIGVhY2ggb3RoZXIgdG8gZm9ybSBmZWVk YmFjazxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBsb29wcy48YnI+DQombmJzcDsgbyBPbiBhIHN5 c3RlbSBsZXZlbDogRmVlZGJhY2sgbG9vcHMgaW5jbHVkZSBjZW50cmFsIGVsZW1lbnRzIGFzPGJy Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IHdlbGwuJnF1b3Q7PGJyPg0KV2hhdCBpcyBhICZxdW90O2Nl bnRyYWwgZWxlbWVudCZxdW90Oz8gRG9lcyB0aGlzIG1lYW4gdGhhdCB0aGUgZmVlZGJhY2sgbG9v cCBpbmNsdWRlcyBjZW50cmFsaXplZCBtYW5hZ2VtZW50IG1lY2hhbmlzbXMsIG9yIHRoYXQgdGhl cmUgaXMgYWRkaXRpb25hbCBsb2dpYyBvdXRzaWRlIG9mIGp1c3QgdGhlIG5vZGVzPzxvOnA+PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9 IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZh Y2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5N QjogQSBjZW50cmFsIGVsZW1lbnQgaXMgYSBjb250cm9sbGVyIGZvciBleGFtcGxlLg0KIFRoZSBw b2ludCBvZiB0aGUgc2VjdGlvbiBpczogWW91IGNvdWxkIGRlZmluZSBhbiDigJxhdXRvbm9taWMg bmV0d29ya+KAnSB3aGVyZSBldmVyeSBub2RlIGhhcyBleGFjdGx5IHRoZSBzYW1lIGludGVyZmFj ZXMgYXMgdG9kYXkgKHByaW1hcmlseSBDTEksIFNOTVAsIE5FVENPTkYpLCBhbmQgd2hlcmUgYSBj b250cm9sbGVyIGlzIGludm9sdmVkIGluIGFsbCBjb250cm9sIGxvb3BzLiBPdXIgZGVmaW5pdGlv biBvZiDigJxhdXRvbm9taWPigJ0gaXMgZnVydGhlcg0KIGRvd24gaW4gdGhlIG5ldHdvcmssIHdo ZXJlIG5vZGVzIGludGVyYWN0IGRpcmVjdGx5IHdpdGggbm9kZXMuIE5vdyB3ZSBhbGwgdW5kZXJz dGFuZCB0aGlzIGlzbuKAmXQgYmxhY2sgYW5kIHdoaXRlLCBidXQgdGhlIGVtcGhhc2lzIG9mIHRo ZSB3b3JrIGluIHRoZSBJRVRGIHNob3VsZCBiZSBub2RlLXRvLW5vZGUgaW50ZXJhY3Rpb25zLg0K PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMyIg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+UGFn ZSA1LCBkZWZpbml0aW9uIG9mIGludGVudDxicj4NCldoeSBpcyBpbnRlbnQgc2NvcGVkIHRvIGEg c2luZ2xlIGF1dG9ub21pYyBkb21haW4/PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMyIgY29sb3I9 IiMxZjQ5N2QiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZh Y2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5N QjogSW50ZW50IGlzbuKAmXQgYSBwb2xpY3kgbGFuZ3VhZ2UgbGlrZSBtb3N0IG90aGVyLA0KIHdo ZXJlIHlvdSBjYW4gZXNzZW50aWFsbHkgZGVmaW5lIGEgcG9saWN5IGZvciBldmVyeSBuZXR3b3Jr IGVsZW1lbnQgc2VwYXJhdGVseS4gVGhlIGZ1bmRhbWVudGFsIGlkZWEgaXMgdGhhdCB0aGVyZSBp cyBvbmUgaW50ZW50IGZvciB0aGUgZW50aXJlIG5ldHdvcmsuIFRodXMgdGhpcyBkZWZpbml0aW9u Lg0KPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NeSBwZXJzb25hbCBvcGluaW9uOiBJZiB3 ZSBsZXQgSW50ZW50IHNsaXAgaW50byB0aGUNCiBlbGVtZW50IG1hbmFnZW1lbnQgc2NvcGUsIHdl 4oCZdmUgbWlzc2VkIGFuIG9wcG9ydHVuaXR5LiBJbnRlbnQgaXMgYSBwb2xpY3kgb24gbmV0d29y ayBzY29wZS4NCjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvZm9u dD48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+UGFnZSA1LCBkZWZpbml0aW9uIG9mIGF1dG9ub21pYyBkb21haW48YnI+DQpX aHkgaXMgYXV0b25vbWljIGRvbWFpbiB0aWVkIHRvIGludGVudCBhcyB0aGUgb25seSBtYW5hZ2Vt ZW50IHBhcmFkaWdtPyBUaGUgdmFzdCBtYWpvcml0eSBvZiB3b3JrIGluIGF1dG9ub21pYyBuZXR3 b3JraW5nIGRvZXMgTk9UIHVzZSBpbnRlbnQgKHdoYXQgSSBjYWxsIGRlY2xhcmF0aXZlIGxvZ2lj LCBJIGZhaWxlZCBtYXJrZXRpbmcgOi0pICkuIEkgY29tcGxldGVseSBhZ3JlZSB3aXRoIHVzaW5n IGludGVudCwgYW5kIHBlcmhhcHMgZXZlbiBlbXBoYXNpemluZw0KIGl0LCBidXQgSSBkb24ndCBh Z3JlZSB3aXRoIGV4Y2x1ZGluZyBvdGhlciBtYW5hZ2VtZW50IHBhcmFkaWdtcy48bzpwPjwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48Zm9udCBzaXplPSIzIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXpl PSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1COiBQcm9iYWJseSBhIHF1ZXN0aW9uIG9mIHdvcmRpbmcu IEluIG15IHJlYWRpbmcgeW91DQogaGF2ZSAxKSBhdXRvbm9taWMgZGVmYXVsdCBiZWhhdmlvdXIg KGNvdWxkIGFsc28gY2FsbCB0aGlzIOKAnGRlZmF1bHQgaW50ZW504oCdKSwgMikgSW50ZW50LCBh bmQgMykgdHJhZGl0aW9uYWwgbWFuYWdlbWVudCBzY2hlbWVzLCBzdWNoIGFzIE5FVENPTkYsIFNO TVAsIENMSSwgZXRj4oCmJm5ic3A7DQo8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0i Q2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNvIHdl IGRvbuKAmXQgZXhjbHVkZSBvdGhlciBtYW5hZ2VtZW50IHBhcmFkaWdtcywgdGhleQ0KIGFyZSBo YW5kbGVzIGluIHNlY3Rpb24gMy4yLiBJcyB0aGF0IHdoYXQgeW91IG1lYW4/IDwvc3Bhbj48L2Zv bnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjIi IGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+KFlvdSBjb3VsZCBhbHNvIGRlZmluZSBhbiBhdXRvbm9taWMgZG9t YWluIGJ5IHRoZSB6b25lDQogb2YgdHJ1c3Qgb2YgdGhlIGNlcnRpZmljYXRlcy4pIDwvc3Bhbj48 L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9 IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMyIgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+UGFnZSA1 LCBzZWxmLW1hbmFnZW1lbnQ8YnI+DQomcXVvdDtUaGV5IGNvbmZpZ3VyZSB0aGVtc2VsdmVzLCBi YXNlZCBvbiBzZWxmLWtub3dsZWRnZSwgZGlzY292ZXJ5LCBhbmQgSW50ZW50LiZxdW90Ozxicj4N ClRoZSB3b3JkICZxdW90O2Rpc2NvdmVyeSZxdW90OyBpcyBjb25mdXNpbmcgbWUuIFN1cHBvc2Ug YSBub2RlIHJ1bnMgYSB1dGlsaXR5IGZ1bmN0aW9uIHRvIGRlY2lkZSB3aGF0IGl0cyBuZXh0IGNv bmZpZ3VyYXRpb24gY2hhbmdlIHNob3VsZCBiZS4gSXQgaXMgbm90ICZxdW90O2Rpc2NvdmVyaW5n JnF1b3Q7IHNvbWV0aGluZyB0aGF0IGV4aXN0ZWQgLSByYXRoZXIsIGl0IGlzIGNvbXB1dGluZyBu ZXcga25vd2xlZGdlLiBBIG1hY2hpbmUgbGVhcm5pbmcgZnVuY3Rpb24gdGhhdCBpbmZlcnMNCiBu ZXcga25vd2xlZGdlIGlzIGFuIGV2ZW4gYmV0dGVyIGV4YW1wbGUgb2Ygc29tZXRoaW5nIHRoYXQg aXMgbm90ICZxdW90O2Rpc2NvdmVyZWQmcXVvdDsuIEknbSBwcm9iYWJseSBtaXNzaW5nIHNvbWV0 aGluZywgYnV0IHdoeSB3YXMgdGhpcyBjaG9pY2UgbWFkZT88bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXpl PSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 Ij5UaGUgdGhpbmcgdGhhdCByZWFsbHkgYm90aGVycyBtZSBpcyB0aGF0IHRoaXMgYXNzdW1lcyB0 aGF0IGFsbCBrbm93bGVkZ2UgY2FuIGJlIGRpc2NvdmVyZWQgLSB0aGF0IGlzLCBpdCBpcw0KIGV4 aXN0aW5nLCBsaWtlIGFuIGFwcGxlIG9uIGEgdHJlZSwgcmVhZHkgdG8gYmUgcGx1Y2tlZC4gSW4g dGhlIGF1dG9ub21pYyBzeXN0ZW1zIHRoYXQgSSd2ZSBidWlsdCwgdGhpcyBpcyBvbmx5IHNvbWV0 aW1lcyB0aGUgY2FzZS4gSXQgaXMgdml0YWwgZm9yIGFuIGF1dG9ub21pYyBzeXN0ZW0gdG8gYmUg YWJsZSB0byBsZWFybiBuZXcga25vd2xlZGdlIHZpYSBjb21wdXRhdGlvbiBhbmQgaW5mZXJlbmNl LCBhcyB3ZWxsIGFzIGRlY2lkZSB0aGF0IHByZXZpb3VzDQoga25vd2xlZGdlIHdhcyBpbmNvcnJl Y3QuIE5laXRoZXIgb2YgdGhlc2UgYXJlIGRpc2NvdmVyeSBmdW5jdGlvbnMuPG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMiIg Y29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0i Q2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1COiBJ IHRoaW5rIHRoZSBjb25mdXNpb24gaXMgdGhlIGRlZmluaXRpb24gb2Yg4oCcZGlzY292ZXJ54oCd DQogaGVyZS4gSXTigJlzIG5vdCBvbmx5IGRpc2NvdmVyeSBpbiB0aGUgc2Vuc2Ugb2Ygc2Vydmlj ZSBkaXNjb3ZlcnksIGJ1dCBmb3IgZXhhbXBsZSwgZmluZGluZyBuZWlnaGJvcnMsIG5lZ290aWF0 aW5nIHBhcmFtZXRlcnMgd2l0aCB0aGVtLCBldGMuDQo8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3 ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlRoZSBhYm92ZSBwaHJhc2UgaW4gb3RoZXIgd29yZHM6IOKAnEkga25vdyBteSBjYXBhYmls aXRpZXMsDQogSSBzZWUgd2hhdCBlbHNlIGlzIHRoZXJlIChhbmQgdGFsayB0byBpdCBwb3RlbnRp YWxseSksIGFuZCBJIHNlZSB3aGF0IHRoZSBib3NzIHdhbnRzIHRvIGhhcHBlbiAoaW50ZW50KS4g QmFzZWQgb24gYWxsIG9mIHRoaXMgSSBkZWNpZGUgd2hhdCBJ4oCZbSBnb2luZyB0byBkb+KAnS4N Cjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxm b250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0aGluayBpdOKAmXMgYSBxdWVzdGlvbiBv ZiB3b3JkaW5nLiBXZSBoYWQgdGhpcyBncmFwaGljDQogKHNpbWlsYXIgdG8gZmlndXJlIDEpLCB3 aGVyZSB0aGVyZSBhcmUgdGhlIDMgaW5wdXQgdmVjdG9ycyAoISkgb2YgaW5mb3JtYXRpb24sIG9u IHdoaWNoIHlvdSBiYXNlIHlvdXIgZGVjaXNpb25zLiBUaGUgaW5mZXJlbmNlIHlvdSBtZW50aW9u IGlzIGEgY29uc2VxdWVuY2Ugb2YgdGhvc2UgaW5wdXRzLiBJbiBvdGhlciB3b3JkcywgdGhlIOKA nGJyYWlu4oCdIHRoYXQgYWN0dWFsbHkgbWFrZXMgdGhlIGluZmVyZW5jZSwgaXMgaW4gb3VyIG1v ZGVsIHRoZQ0KIGF1dG9ub21pYyBzZXJ2aWNlIGFnZW50LiA8L3NwYW4+PC9mb250PjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXpl PSIzIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjojMUY0OTdEIj5Eb2VzIHRoYXQgbWFrZSBzZW5zZT8NCjwv c3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250 IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0i MyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+ UGFnZSA2LCBsYXN0IHBhcmFncmFwaCBhYm92ZSBzZWN0aW9uIDMuMjxicj4NCiZxdW90Oy4uLmNs b3NlZC1sb29wIGNvbnRyb2wgaXMgYW4gaW1wb3J0YW50IGFzcGVjdCBvZiBzZWxmLW1hbmFnaW5n IHN5c3RlbXMuIDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlRoaXMgaW1wbGllcyBwZWVyLXRvLXBl ZXIgZGlhbG9ndWVzIGJldHdlZW4gdGhlIHBhcnRpZXMgdGhhdCBtYWtlIHVwDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij50aGUgY2xvc2VkIGxvb3AuIFN1Y2ggZGlhbG9ndWVzIHJlcXVpcmUgdHdv LXdheSAmcXVvdDtkaXNjdXNzaW9uJnF1b3Q7IG9yICZxdW90O25lZ290aWF0aW9uJnF1b3Q7DQo8 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij5iZXR3ZWVuIGVhY2ggcGFpciBvciBncm91cHMgb2YgcGVl cnMgaW52b2x2ZWQgaW4gdGhlIGxvb3AsLi4uJnF1b3Q7PGJyPg0KRmlyc3QsIGJ5ICZxdW90O3Bl ZXImcXVvdDssIEkgYXNzdW1lIHlvdSBtZWFuIHR3byAob3IgbW9yZSkgZXF1aXBvdGVudCBlbnRp dGllcyB0aGF0IG1ha2Ugc29tZSBwb3J0aW9uIG9mIHRoZWlyIHJlc291cmNlcyBhdmFpbGFibGUg dG8gb3RoZXJzLiBTZWNvbmQsIGFuZCBtb3JlIGltcG9ydGFudGx5LCBhIGNsb3NlZCBjb250cm9s IGxvb3AgZG9lcyBub3QgcmVxdWlyZSBlYWNoIGVudGl0eSBpbiB0aGUgY2xvc2VkIGNvbnRyb2wg bG9vcCB0byB0YWxrIHRvIG5lZ290aWF0ZQ0KIHdpdGggb3RoZXIgZW50aXRpZXMuIE5vdywgaW4g YW4gYXV0b25vbWljIGNvbnRyb2wgbG9vcCwgdGhpcyBjb3VsZCB2ZXJ5IHdlbGwgYmUgdGhlIGNh c2UsIGJ1dCBpdCBpcyB1bmNsZWFyIHRvIG1lIHdoeSBpdCBNVVNUIGJlIHRoZSBjYXNlLiBUaGUg b2J2aW91cyBuaWdodG1hcmUgc2NlbmFyaW8gaXMgdGhhdCB0aGUgbmVnb3RpYXRpb24gZmFpbHMu IFRoZW4gd2hhdCAtIHdlIGhhdmUgbm8gY29udHJvbCBsb29wIGF0IGFsbD88bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 Zm9udCBzaXplPSIzIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9m b250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIy IiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPk1COiBJIGd1ZXNzIHlvdXIgcG9pbnQgaXMgdGhhdCBhbiBhdXRv bm9taWMgcHJvY2Vzcw0KIGRvZXNu4oCZdCBIQVZFIHRvIGhhdmUgYSBjb250cm9sIGxvb3AuIEkg d291bGQgYXJndWUgdGhhdCB0aGUgdHlwaWNhbCBhdXRvbm9taWMgZnVuY3Rpb24gRE9FUyBoYXZl IG5vZGUtdG8tbm9kZSBpbnRlcmFjdGlvbnMuIFRoaXMgaXMgd2hhdCBhdXRvbm9taWNzIGlzIGFs bCBhYm91dC4gTm93LCB5ZXMsIHRoZXJlIHdpbGwgYmUgY2FzZXMgd2hlcmUgdGhpcyBmYWlscywg YW5kIHdoZXJlIGEgbm9kZSBhbHNvIG5lZWRzIHRvIGRvIHNvbWV0aGluZyBzZW5zaWJsZQ0KIGlu IGNhc2Ugb2YgY29tcGxldGUgaXNvbGF0aW9uLiBCdXQgdGhhdOKAmXMgYW4gZXhjZXB0aW9uIHN0 YXRlIGluIG15IG1pbmQuIDwvc3Bhbj4NCjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGli cmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij5QYWdlcyA3LTgsIFNlY3Rpb24gMy42PGJyPg0KTW9zdCBhdXRv bm9taWMgbmV0d29ya2luZyBzeXN0ZW1zIHRvIGRhdGUgaGF2ZSBOT1QgYmVlbiBidWlsdCB3aXRo IGFuIGludGVudCAob3IgZGVjbGFyYXRpdmUpIHN0eWxlIGludGVyZmFjZS4gRk9DQUxFIGVuYWJs ZXMgZGVjbGFyYXRpdmUgYW5kIHByZXNjcmlwdGl2ZSAoZS5nLiwgRUNBIHBvbGljeSBydWxlcykg dG8gYmUgdXNlZC4gT3RoZXJzIGp1c3QgdXNlIEVDQSAob3IgYW4gZXF1aXZhbGVudCkgcGFyYWRp Z20uIEhlbmNlLCBJJ20gd29uZGVyaW5nDQogd2h5IGludGVudCBpcyB0aGUgT05MWSBwYXJhZGln bSB0aGF0IGlzIG1lbnRpb25lZCBpbiB0aGlzIFJGQyB0aGF0IGlzIHN1aXRhYmxlIGZvciBhdXRv bm9taWMgbmV0d29ya2luZz8gU2hvdWxkbid0IHdlIHRyeSBhbmQgcGVhY2VmdWxseSBjb2V4aXN0 LCBqdXN0IGFzIHRoZSBub2RlcyBhcmUgcGVhY2VmdWxseSBjb2V4aXN0aW5nIHdpdGggbm9uLWF1 dG9ub21pYyBkaXJlY3RpdmVzPzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjMiIGNvbG9yPSIjMWY0 OTdkIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJD YWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TUI6IFRv IG1lLCBFQ0EgaXMgZW5jb2RlZCBpbiBhbiBBU0Egb3IgYW4gYXV0b25vbWljDQogZnVuY3Rpb24u IFRoZSBmdW5jdGlvbiBzYXlzIHdoYXQgYWN0aW9uIHlvdSB0YWtlIGluIHNwZWNpZmljIGV2ZW50 cywgYW5kIHVuZGVyIHdoaWNoIGNvbmRpdGlvbi4NCjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdk IiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+RXhhbXBsZTogVGhlIOKAnGVucm9sbWVudCBwcm94eSBBU0HigJ0gaGFzIHRoZSBmb2xsb3dp bmcNCiAoaGFyZCBjb2RlZCkgRVNBOiA8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHA+ PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tPC9zcGFuPjwvZm9udD48Zm9udCBzaXpl PSIxIiBjb2xvcj0iIzFmNDk3ZCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjoj MUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9 IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5FdmVu dDogQSBuZXcgbm9kZSBpcyBkZXRlY3RlZDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8 cD48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi08L3NwYW4+PC9mb250Pjxmb250IHNp emU9IjEiIGNvbG9yPSIjMWY0OTdkIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjwvZm9udD48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFj ZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNv bmRpdGlvbjogaXQgZG9lc27igJl0IGhhdmUgYSBkb21haW4gY2VydCB5ZXQNCjwvc3Bhbj48L2Zv bnQ+PG86cD48L286cD48L3A+DQo8cD48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFj ZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi08 L3NwYW4+PC9mb250Pjxmb250IHNpemU9IjEiIGNvbG9yPSIjMWY0OTdkIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvZm9udD48Zm9udCBzaXplPSIy IiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkFjdGlvbjogSSBpbnZpdGUgdGhlIG5vZGUgdG8gam9pbiBteSBu ZXR3b3JrLg0KPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Ob3csIEludGVudCBpcyBpbiBt eSBtaW5kIGEgaGlnaGVyIGxldmVsIGNvbmNlcHQgd2hpY2gNCiBjb3VsZCBub3cgc3RhdGUg4oCc ZG8gbm90IGVucm9sIG5ldyBub2RlcyBhdCB0aGlzIG1vbWVudOKAnS4gPC9zcGFuPjwvZm9udD48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMiIgY29s b3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5Ib3cgd291bGQgeW91IHNlZSB0aGF0Pw0KPC9zcGFuPjwvZm9udD48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9 IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5QYWdlIDksIHNlY3Rpb24g My43PGJyPg0KJnF1b3Q7SG93ZXZlciwgaW4gYW4gQXV0b25vbWljIE5ldHdvcmssIHJlcG9ydGlu ZyBzaG91bGQgaGFwcGVuIG9uIGEgbmV0d29yay13aWRlIGJhc2lzLiZxdW90OzxvOnA+PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i Pjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPlRydWUsIGJ1dCBzaG91bGRuJ3QgaW5kaXZpZHVhbCBub2RlcyBhbmQgY29s bGVjdGlvbnMgb2Ygbm9kZXMgc3RpbGwgcmVwb3J0PyBUaGF0IGlzbid0IGltcGxpZWQgaW4gdGhl IHdvcmRpbmcuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9mb250 PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIyIiBj b2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPk1COiBZZXMsIHRoZXkgc2hvdWxkLiBUaGlzIGlzIOKAnHRyYWRpdGlv bmFsIG1hbmFnZW1lbnQNCiBtZXRob2Rz4oCdLiBJbiBvdXIgbW9kZWwsIGV2ZXJ5IG5vZGUgZG9l cyB0aGUgbm9ybWFsIHN5c2xvZywgZXRjLiwgYW5kIGFnZ3JlZ2F0ZWQgcmVwb3J0aW5nIGlzIHRo ZSBuZXcgdGhpbmcgdGhhdCBjb21lcyB3aXRoIEFOLg0KPC9zcGFuPjwvZm9udD48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5 N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5GdXJ0aGVybW9yZSwgdGhlIGxhc3Qg cGFyYWdyYXBoIHNheXM6ICZxdW90O0F1dG9ub21pYyBuZXR3b3JrIGV2ZW50cyBzaG91bGQgY29u Y2VybiB0aGUgQXV0b25vbWljIE5ldHdvcmsgYXMgYSB3aG9sZSwNCiBub3QgaW5kaXZpZHVhbCBz eXN0ZW1zIGluIGlzb2xhdGlvbi4mcXVvdDsgSSBhZ3JlZSB0aGF0IHRoZSBnb2FsIGlzIHRvIHJl cG9ydCBvbiB0aGUgc3lzdGVtIGFzIGEgd2hvbGUsIGJ1dCBpc24ndCBzdWNoIGEgcmVwb3J0IGNv bGxlY3RlZCBmcm9tIGluZGl2aWR1YWwgbm9kZXM/IEp1c3QgbGlrZSBpbiB5b3VyIGV4YW1wbGUs IHRoZSBub2RlcyBuZWVkIHRvIGJlIGFibGUgdG8gc2VlIHRoYXQgYSBwcm9ibGVtIGhhcyBhbHJl YWR5IGJlZW4gcmVwb3J0ZWQNCiBpbiBvcmRlciB0byBrbm93IG5vdCB0byBpc3N1ZSB0aGUgc2Ft ZSBwcm9ibGVtLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjMiIGNvbG9yPSIjMWY0OTdkIiBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TUI6IFRoZXJlIGFyZSB0 d28gcGFyYWxsZWwgbWV0aG9kcyBvZiByZXBvcnRpbmc6DQo8L3NwYW4+PC9mb250PjxvOnA+PC9v OnA+PC9wPg0KPHA+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmki PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4xKTwvc3Bhbj48L2Zv bnQ+PGZvbnQgc2l6ZT0iMSIgY29sb3I9IiMxZjQ5N2QiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PC9mb250Pjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+dGhlIHRyYWRpdGlvbmFs IGV2ZXJ5LW5vZGUtdG8tY29udHJvbGxlciBtZXRob2QsIHdoZXJlIHRoZSBpbnRlbGxpZ2VuY2Ug aXMgY2VudHJhbDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cD48Zm9udCBzaXplPSIy IiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjIpPC9zcGFuPjwvZm9udD48Zm9udCBzaXplPSIxIiBjb2xvcj0i IzFmNDk3ZCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMiIg Y29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5hIGRpc3RyaWJ1dGVkIHJlcG9ydGluZyBmdW5jdGlvbiwgd2hlcmUg bm9kZXMgYWdncmVnYXRlLCBwcm9jZXNzLCBzdW1tYXJpc2UsIGNvcnJlbGF0ZSwg4oCmICZuYnNw O2luZm9ybWF0aW9uIGJlZm9yZSBoYW5kaW5nDQogaXQgdG8gdGhlIGNvbnRyb2xsZXIuIEhlcmUg dGhlIGludGVsbGlnZW5jZSBpcyBkaXN0cmlidXRlZC4gPC9zcGFuPjwvZm9udD48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5 N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5Cb3RoIHdpbGwgY28tZXhpc3QuIFRoZSBSRkMgZm9jdXNlcyBvbiB0aGUgbmV3IG1ldGhv ZA0KIChhbmQgb2J2aW91c2x5IGlzbuKAmXQgY2xlYXIgZW5vdWdoIGFib3V0IGl04oCmKSA8L3Nw YW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBz aXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjMi IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlBh Z2VzIDEyLTEzLCBzZWN0aW9uIDU8YnI+DQpXaHkgaXMgYW4gQXV0b25vbWljICoqVXNlcioqIEFn ZW50IHRoZSBpbnRlcmZhY2UgdG8gYSBjb250cm9sIGxvb3A/IEkgY2FuIHNlZSBhbiBleHRlcm5h bCBlbnRpdHkgd2FudGluZyB0byBjb25maWd1cmUgYW5kIG1vbml0b3IgdGhlIGNvbnRyb2wgbG9v cCwgYnV0IHdoeSB3b3VsZG4ndCB0aGUgVXNlciBBZ2VudCB0YWxrIHRvIHRoZSBTZXJ2aWNlIEFn ZW50IHRvIGRvIHRoaXM/IEkgZG8gbm90ZSB0aGF0IHRoaXMgZmlndXJlIGlzIHVuZGVyIGRpc2N1 c3Npb24NCiBhbmQgYmVpbmcgcmV2aXNlZCBpbiB0aGUgcmVmZXJlbmNlIG1vZGVsLjxvOnA+PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxmb250IHNpemU9IjMiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNp emU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TUI6IFllcywgdGhhdOKAmXMgY29uZnVzaW5nIHdvcmRp bmcsIGFuZCBub3cgdGhhdCB5b3UNCiBtZW50aW9uIGl0LCB5ZXMgd2Ugc2hvdWxkIGhhdmUgcHJv YmFibHkgbG9va2VkIGZvciBhIGJldHRlciB0ZXJtLiBUaGUgaWRlYSBpczogVGhlIOKAnGludGVs bGlnZW5jZeKAnSBvZiBhbiBhdXRvbm9taWMgZnVuY3Rpb24gaXMgaW4gdGhlIEFTQSAobWlkZGxl IG9mIGZpZ3VyZSAxKS4gVGhlcmUgYXJlIG5vdyBob3Jpem9udGFsIGZlZWRiYWNrIGxvb3BzIGFu ZCBub3J0aGJvdW5kIGZlZWRiYWNrIGxvb3BzLiBGb3IgZXhhbXBsZSwgdGhlcmUgaXMgbGlrZWx5 DQogYSBmdW5jdGlvbiBpbiB0aGUgZW5yb2xtZW50IHByb2Nlc3MsIHdoZXJlIGEgbWVzc2FnZSBn ZXRzIHNlbnQgdG8gdGhlIGFkbWluOiDigJxIZXJl4oCZcyBhIG5ldyBub2RlLCBJIGRvbuKAmXQg dGhpbmsgaXQgYmVsb25ncyBpbnRvIG91ciBuZXR3b3JrLCBJ4oCZdmUgcXVhcmFudGluZWQgdGhh dCBub2RlIGZvciBub3c7IHdvdWxkIHlvdSBsaWtlIG1lIHRvIDEpIGFjY2VwdCB0aGUgbm9kZSBh bnl3YXksIG9yIDIpIG1hcmsgaXQgYXMgYmFkP+KAnTwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdk IiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGFncmVlIHRoZSB0ZXJtIOKA nHVzZXIgYWdlbnTigJ0gaXMgbm90IGdvb2QuIFdlIG5lZWQNCiB0byBmaW5kIGEgYmV0dGVyIG9u ZS4gU3VnZ2VzdGlvbnM/IDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJp Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+UGFnZSAxMywgRmlndXJlIDE8YnI+DQpXaGVyZSBpcyB0aGUgQXV0 b25vbWljIE5vZGUgaW4gdGhlIFJlZmVyZW5jZSBNb2RlbD8gSSBkbyBub3RlIHRoYXQgdGhpcyBm aWd1cmUgaXMgdW5kZXIgZGlzY3Vzc2lvbiBhbmQgYmVpbmcgcmV2aXNlZCBpbiB0aGUgcmVmZXJl bmNlIG1vZGVsLiBIb3dldmVyLCBldmVuIGluIEZpZ3VyZSAyIG9mIHRoZSByZWZlcmVuY2UgbW9k ZWwsIGl0IGlzIHN0aWxsIHVuY2xlYXIgd2hhdCB0aGUgJnF1b3Q7bm9kZSZxdW90OyBpcy4gQnV0 IG1vcmUgb24gdGhhdCBsYXRlci48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8Zm9udCBjb2xvcj0i IzFmNDk3ZCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPk1COiBUaGUgd2hvbGUgdGhpbmcg aXMgdGhlIG5vZGUuIFRoYXTigJlzIHdoeSB0aGUgZmlndXJlIGlzIGNhbGxlZCDigJxSZWZlcmVu Y2UgTW9kZWwgZm9yIGFuIEF1dG9ub21pYyBOb2Rl4oCdLg0KPC9zcGFuPjwvZm9udD48bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXpl PSIzIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIzIiBjb2xvcj0i IzFmNDk3ZCIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIGFsbCB5b3VyIGlucHV0IEpvaG4hIExldOKA mXMgbWFrZSBzdXJlIHRoYXQgYWxsIHRoZXNlIHBvaW50cyBnZXQgYWRkcmVzc2VkDQogaW4gdGhl IHJlZmVyZW5jZSBtb2RlbC4gPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMyIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PGZvbnQgc2l6ZT0iMyIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6IzFGNDk3RCI+TWljaGFlbDwvc3Bh bj48L2ZvbnQ+PGJyPg0KLS0gPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5yZWdhcmRzLDxvOnA+PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxm b250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQiPkpvaG48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8YnI+DQotLSA8bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij5yZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Kb2huPG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FF268Axmbrcdx14ciscoc_-- From nobody Tue Jun 23 02:50:31 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3281AC41D for ; Tue, 23 Jun 2015 02:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLOH298lp0KF for ; Tue, 23 Jun 2015 02:50:28 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E36041AC416 for ; Tue, 23 Jun 2015 02:50:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4434; q=dns/txt; s=iport; t=1435053028; x=1436262628; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=m6Kszrp+MzkYF+pIssd9su1+TcP+1oivLBFYmfXM/Rs=; b=Cm9IlJ6oFBnTVqJG19LDdfigpVxyXx2Ed+Uv6mVlpFTAjb6ejbp5q+po 5Ev6RbK89RIxcCXBKzSW03Qth0UauqRe4OSqd0RoSm9g7Jl7fUqST8b5q Vm0ETLKrslz8TOj7ykhuhAbkL/kX9TfkX9ruf2Oi1D2XW+9G7xVadY7u5 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BgBQCpKolV/51dJa1bgxBUXwaDGLlab4FcCoV4AhyBJzkTAQEBAQEBAYEKhCIBAQEDAQEBASAROhAHBAIBCBEEAQEBAgIGHQMCAgIfBgsUAQgIAQEEARIIiBIDCggNtUKQVA2FbQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSGKKYJNgggWIgaCYi+BFAWTfwGJb5J+hxgmY4MXbwGBRYECAQEB X-IronPort-AV: E=Sophos;i="5.13,665,1427760000"; d="scan'208";a="161938691" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP; 23 Jun 2015 09:50:27 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t5N9oRCv029910 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Jun 2015 09:50:27 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.179]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Tue, 23 Jun 2015 04:50:26 -0500 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , Anima WG Thread-Topic: [Anima] Common Ground on the ACP Thread-Index: AdCp2kWzuNSXI7ELQ66smCIeol/FLQDgjkeAAAlYj2A= Date: Tue, 23 Jun 2015 09:50:25 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF26FB@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0FAB@xmb-rcd-x14.cisco.com> <55887E55.9000207@gmail.com> In-Reply-To: <55887E55.9000207@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.33] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Common Ground on the ACP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jun 2015 09:50:29 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBb bWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbV0NCj4gU2VudDogMjIgSnVuZSAyMDE1 IDIzOjMwDQo+IFRvOiBNaWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpOyBBbmltYSBXRw0KPiBT dWJqZWN0OiBSZTogW0FuaW1hXSBDb21tb24gR3JvdW5kIG9uIHRoZSBBQ1ANCj4gDQo+IEhpIE1p Y2hhZWwsDQo+IA0KPiBJIHByZXR0eSBtdWNoIGFncmVlLCBidXQNCj4gDQo+ID4gICAgNGEgLSBN VVNUOiBBQ1AgSG9wLWJ5LWhvcCBhdXRoZW50aWNhdGlvbg0KPiA+ICAgIDRiIC0gU0hPVUxEOiBB Q1AgSG9wLWJ5LWhvcCBlbmNyeXB0aW9uDQo+IA0KPiBJIHN1cHBvc2UgdGhlc2UgYXJlIG1lYW50 IHRvIGJlIDVhL2IsIA0KDQpJbmRlZWQuIFNodWZmbGluZyBlcnJvci4gV291bGQgaGF2ZSBiZW5l Zml0dGVkIG9mIGF1dG9ub21pYyBhZGRyZXNzaW5nIDotKSANCg0KPiBidXQgbW9yZSBzdWJzdGFu dGl2ZWx5LCBpcyBob3AtYnktDQo+IGhvcCBhICpyZXF1aXJlbWVudCo/IEVuZC10by1lbmQgaXMg ZGVmaW5pdGVseSByZXF1aXJlZCwgYnV0IGhvcC1ieS1ob3ANCj4gc2VlbXMgbGlrZSBhbiBpbXBs ZW1lbnRhdGlvbiBjaG9pY2UuDQoNCkFjdHVhbGx5LCB0aGUgZW1waGFzaXMgaXMgb24gdGhlICJh dXRoZW50aWNhdGlvbiIuIFRoZSAiaG9wLWJ5LWhvcCIgSSBzZWUgYXMgdGhlIGRlZmF1bHQgbW9k ZSBvZiBvcGVyYXRpb24sIGFuZCB0aGVyZSBtYXkgYmUgZXhjZXB0aW9ucyB3aGVyZSB5b3UgY3Jl YXRlIHNlY3VyaXR5IGFzc29jaWF0aW9ucyBlbmQtdG8tZW5kLiBJJ2xsIHJlLXBocmFzZSB0aGF0 IHRvIG1ha2UgaXQgY2xlYXJlci4gDQpIb3AgYnkgaG9wIGhhcyB0aGUgdmVyeSBuaWNlIHByb3Bl cnR5IHRoYXQgeW91IGNhbiBsZXZlcmFnZSBsaW5rLWxvY2FsLCBoYXZlIHRoZXJlZm9yZSBubyBk ZXBlbmRlbmN5IC8gY29uZmxpY3Qgd2l0aCBjb25maWd1cmF0aW9uLCB0aHVzIG1ha2luZyB0aGUg Y29tbXVuaWNhdGlvbnMgbXVjaCBtb3JlIHJvYnVzdC4gDQoNClJlYWRpbmcgdGhpcyBhZ2Fpbiwg SSBqdXN0IHJlYWxpc2Ugbm93IHRoYXQgdGhlICJob3AgYnkgaG9wIiBkb2Vzbid0IHJlYWxseSBi ZWxvbmcgdG8gdGhlIHNlY3VyaXR5IHBvaW50LiBBY3R1YWxseSwgdGhpcyBpcyBhIHN1Yi1wb2lu dCB0byBwb2ludCAxIChyb2J1c3QgY29ubmVjdGl2aXR5KTogLiBJJ2xsIGFkZCBpdCB0aGVyZS4g DQoNCj4gTXkgb3BpbmlvbiBpcyB0aGF0IGluIHRoZXNlIGRheXMgb2YgcGVydmFzaXZlIHN1cnZl aWxsYW5jZSwgZW5jcnlwdGlvbiBpcyBhDQo+IHZlcnkgc3Ryb25nIFNIT1VMRCBpbmRlZWQuDQoN CkNvbXBsZXRlbHkgYWdyZWUuIEFuZCwgb25jZSB5b3UgaGF2ZSBhIHNlY3VyaXR5IGFzc29jaWF0 aW9uIChmb3IgYXV0aGVudGljYXRpb24pIGFueXdheSwgeW91IG1heSBub3JtYWxseSBhcyB3ZWxs IGVuY3J5cHQuIA0KDQpNaWNoYWVsDQoNCj4gDQo+ICAgICBCcmlhbg0KPiANCj4gT24gMjMvMDYv MjAxNSAwNDo0MCwgTWljaGFlbCBCZWhyaW5nZXIgKG1iZWhyaW5nKSB3cm90ZToNCj4gPiBBTklN QSwNCj4gPg0KPiA+IFRyeWluZyB0byBnZXQgYSBuZXcgdmVyc2lvbiBvZiB0aGUgQUNQIGRyYWZ0 IG91dCBsYXRlciB0aGlzIHdlZWssIEknbSB0cnlpbmcNCj4gdG8gdW5kZXJzdGFuZCB3aGF0IHdl J3JlIGFsbCBhZ3JlZWluZyBvbiwgYW5kIHdoYXQgbm90Lg0KPiA+DQo+ID4gQXMgSSBzZWUgaXQs IHRoZSBoaWdoIGxldmVsIHJlcXVpcmVtZW50cyAoYmVsb3cpIGFuZCB0aGUgYmVuZWZpdHMgd291 bGQgZ28NCj4gaW50byB0aGUgcmVmZXJlbmNlIG1vZGVsLCB0aGUgZGV0YWlscyBpbnRvIHRoZSBB Q1AgZHJhZnQuDQo+ID4NCj4gPiBSZXF1aXJlbWVudHMgZm9yIGFuIEFDUDoNCj4gPg0KPiA+IDEg LSBUaGUgQUNQIFNIT1VMRCBwcm92aWRlIHJvYnVzdCBjb25uZWN0aXZpdHkNCj4gPiAgICBBcyBm YXIgYXMgcG9zc2libGUsIGl0IHNob3VsZCBiZSBpbmRlcGVuZGVudCBvZiBjb25maWd1cmVkIGFk ZHJlc3NpbmcsDQo+IGNvbmZpZ3VyYXRpb24gYW5kIHJvdXRpbmcuDQo+ID4gICAgKDIgYW5kIDMg YnVpbGQgb24gdGhpcyByZXF1aXJlbWVudCwgYnV0IGFsc28gaGF2ZSB2YWx1ZSBvbiB0aGVpcg0K PiA+IG93bikNCj4gPg0KPiA+IDIgLSBUaGUgQUNQIE1VU1QgaGF2ZSBhIHNlcGFyYXRlIGFkZHJl c3Mgc3BhY2UgZnJvbSB0aGUgZGF0YSBwbGFuZS4NCj4gPiAgICBSZWFzb246IHRyYWNlYWJpbGl0 eSwgZGVidWctYWJpbGl0eSwgc2VwYXJhdGlvbiBmcm9tIGRhdGEgcGxhbmUsDQo+ID4gc2VjdXJp dHkgKGNhbiBibG9jayBhdCBlZGdlKQ0KPiA+DQo+ID4gMyAtIFRoZSBBQ1AgTVVTVCB1c2UgYXV0 b25vbWljYWxseSBtYW5hZ2VkIGFkZHJlc3Mgc3BhY2UNCj4gPiAgICBSZWFzb246IGVhc3kgYm9v dHN0cmFwIGFuZCBzZXR1cCAoImF1dG9ub21pYyIpOyByb2J1c3RuZXNzIChhZG1pbg0KPiBjYW4n dCBtZXNzIHRoaW5ncyB1cCBzbyBlYXNpbHkpLg0KPiA+DQo+ID4gICAgSSB0aGluayB3ZSBhZ3Jl ZWQ6IFVMQSBzZWVtcyBsaWtlIGEgZ29vZCBjaG9pY2UgZm9yIDEgYW5kIDIuDQo+ID4NCj4gPiA0 IC0gVGhlIEFDUCBNVVNUIGJlIGdlbmVyaWMNCj4gPiAgICBVc2FibGUgYnkgYWxsIHRoZSBmdW5j dGlvbnMgYW5kIHByb3RvY29scyBvZiB0aGUgQU4gaW5mcmFzdHJ1Y3R1cmUuIE1VU1QNCj4gTk9U IGJlIHRpZWQgdG8gYSBwYXJ0aWN1bGFyIHByb3RvY29sLg0KPiA+DQo+ID4gNS0gVGhlIEFDUCBN VVNUIHByb3ZpZGUgc2VjdXJpdHk6DQo+ID4gICAgTWVzc2FnZXMgY29taW5nIHRocm91Z2ggdGhl IEFDUCBhcmUgYXV0aGVudGljYXRlZCB0byBiZSBmcm9tIGEgdHJ1c3RlZA0KPiBub2RlLCBhbmQg ZW5jcnlwdGVkLg0KPiA+DQo+ID4gICAgNGEgLSBNVVNUOiBBQ1AgSG9wLWJ5LWhvcCBhdXRoZW50 aWNhdGlvbg0KPiA+ICAgIDRiIC0gU0hPVUxEOiBBQ1AgSG9wLWJ5LWhvcCBlbmNyeXB0aW9uDQo+ ID4NCj4gPiBEbyB3ZSBhZ3JlZSBvbiB0aG9zZSByZXF1aXJlbWVudHM/DQo+ID4NCj4gPiBNaWNo YWVsDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+IEFuaW1hIG1haWxpbmcgbGlzdA0KPiA+IEFuaW1hQGlldGYub3JnDQo+ID4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYQ0KPiA+DQo= From nobody Tue Jun 23 02:57:32 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39FCF1AC7E8 for ; Tue, 23 Jun 2015 02:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.078 X-Spam-Level: ** X-Spam-Status: No, score=2.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkyoJny5AIAu for ; Tue, 23 Jun 2015 02:57:28 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B21F71AC7E7 for ; Tue, 23 Jun 2015 02:57:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUG01773; Tue, 23 Jun 2015 09:57:26 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 23 Jun 2015 10:57:22 +0100 Received: from NKGEML505-MBX.china.huawei.com ([169.254.1.218]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Tue, 23 Jun 2015 17:57:15 +0800 From: Duzongpeng To: Brian E Carpenter , Toerless Eckert Thread-Topic: [Anima] Common Ground on the ACP Thread-Index: AdCp2kWzuNSXI7ELQ66smCIeol/FLQDFUImAAAa5FYAAC4/4gAAX3yHg Date: Tue, 23 Jun 2015 09:57:14 +0000 Message-ID: References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0FAB@xmb-rcd-x14.cisco.com> <55887E55.9000207@gmail.com> <20150623004227.GA27886@cisco.com> <5588F90B.40605@gmail.com> In-Reply-To: <5588F90B.40605@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.149.226] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "Michael Behringer \(mbehring\)" , Anima WG Subject: [Anima] =?gb2312?b?tPC4tDogIENvbW1vbiBHcm91bmQgb24gdGhlIEFDUA==?= X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jun 2015 09:57:30 -0000 SGksIEJyaWFuIGFuZCBUb2VybGVzczoNCg0KIEluIG15IG9waW5pb24sIGJvdGggdGhlIGhvcC1i eS1ob3AgZW5jcnlwdGlvbiBhbmQgdGhlIGVuZC10by1lbmQgZW5jcnlwdGlvbiBhcmUgbmVlZGVk IGluIHRoZSBBdXRvbm9taWMgbmV0d29yay4NCg0KIFRoZSBIb3AtYnktaG9wIG9uZSBjYW4gcHJv dmlkZWQgYSB1bmlmb3JtIGVuY3J5cHRpb24gaW5mcmFzdHJ1Y3R1cmUgZm9yIGFsbCB0aGUgdHJh ZmZpYy4gSXQgY2FuIHNpbXBseSB0aGUgZW5jcnlwdGlvbiBqb2JzLg0KDQogVGhlIGVuZC10by1l bmQgb25lIGNhbiBwcm92aWRlIGFuIGVuY3J5cHRpb24gc29sdXRpb24gZm9yIHR3byBwZWVyIG5v ZGVzLiANCiBPbmUgb2YgdGhlIHJlYXNvbnMgd2h5IHdlIG5lZWQgdGhpcyBpcyB0aGF0IHBlcmhh cHMgc29tZSBpbmZvcm1hdGlvbiBpcyBzcGVjaWZpYyBmb3IgdGhlIHBlZXIgbm9kZS4gDQogDQog SW4gZGV0YWlsLCANCgkxLiBNYXliZSB0aGUgc2VuZGVyIGRvZXMgbm90IHdhbnQgdGhlIG1pZGRs ZSBub2RlcyB0byBrbm93IHRoZSBpbmZvcm1hdGlvbiBkdWUgdG8gYSBoaWdoIHNlY3VyaXR5IGxl dmVyIHJlcXVpcmVtZW50Lg0KCTIuIE9yIGlmIHRoZSBtZXNzYWdlcyBhcmUgc2VudCBhY3Jvc3Mg ZG9tYWlucywgdGhlIHNlbmRlciBtYXkgYmUgbm90IHN1cmUgYWJvdXQgdGhlIHNlY3VyaXR5IGNv bmZpZ3VyYXRpb24gb2YgYW5vdGhlciBkb21haW4uIEFub3RoZXIgZG9tYWluIG1heSBjaG9vc2Ug bm90IHRvIGVuY3J5cHQgdGhlaXIgdHJhZmZpYy4NCiAgIA0KDQpCZXN0IFJlZ2FyZHMNClpvbmdw ZW5nIER1DQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBBbmltYSBbbWFpbHRvOmFuaW1h LWJvdW5jZXNAaWV0Zi5vcmddILT6se0gQnJpYW4gRSBDYXJwZW50ZXINCreiy83KsbzkOiAyMDE1 xOo21MIyM8jVIDE0OjE0DQrK1bz+yMs6IFRvZXJsZXNzIEVja2VydA0Ks63LzTogQW5pbWEgV0c7 IE1pY2hhZWwgQmVocmluZ2VyIChtYmVocmluZykNCtb3zOI6IFJlOiBbQW5pbWFdIENvbW1vbiBH cm91bmQgb24gdGhlIEFDUA0KDQpPbiAyMy8wNi8yMDE1IDEyOjQyLCBUb2VybGVzcyBFY2tlcnQg d3JvdGU6DQo+IEJyaWFuOiBUaGVzZSBhcmUgaW50ZXJ0d2luZWQ6DQo+IA0KPiBMZXRzIGp1c3Qg c3RhcnQgYXNzdW1pbmcgZW5kLXRvLWVuZCBlbmNyeXB0aW9uIGlzIGdvb2QgZW5vdWdoLg0KDQpJ IHdhcyB0YWxraW5nIGFib3V0IHJlcXVpcmVtZW50cy4gVGhlIHJlcXVpcmVtZW50IGlzIHRoYXQg dGhpcmQgcGFydGllcyBjYW4ndCByZWFkIHRoZSB0cmFmZmljLiBUaGF0J3MgYW4gZW5kLXRvLWVu ZCByZXF1aXJlbWVudC4NCg0KVGhlIHNvbHV0aW9uIG1pZ2h0IGJlIGhvcC1ieS1ob3AgYnV0IHRo YXQncyBhIHNlcGFyYXRlIGRpc2N1c3Npb24sIFRoYXQncyBhbGwgSSBtZWFudCB0byBzYXkuDQoN CihIb3dldmVyLCBpbiBnZW5lcmFsLCBob3AtYnktaG9wIGRlY3J5cHRpb24gYW5kIHJlLWVuY3J5 cHRpb24gaW5jcmVhc2VzIHRoZSBhdHRhY2sgc3VyZmFjZSBmb3IgYSBiYWQgYWN0b3IuIFNvIGlm IGhvcC1ieS1ob3AgaXMgc2ltcGxlciB0byBpbXBsZW1lbnQsIHRoZXJlIGlzIGEgc2VjdXJpdHkg dHJhZGUtb2ZmLiBCdXQgdGhhdCdzIGEgZGVzaWduIGRpc2N1c3Npb24sIG5vdCBhIHJlcXVpcmVt ZW50cyBkaXNjdXNzaW9uLikNCg0KT25lIG1vcmUgY29tbWVudCBhdCB0aGUgZW5kLi4uDQoNCj4g SG93IGRvIHdlIGNyZWF0ZSBiZXR3ZWVuIEFTQXMgc2VjdXJpdHkgYXNzb2NpYXRpb25zLiBXZSBk ZWZpbml0ZWx5IA0KPiB3b3VsZCBsaWtlIHRoYXQgbm90IGV2ZXJ5IEFTQSBuZWVkcyB0byBidWls ZCBvdXQgYSBzZXBhcmF0ZSBzZWN1cml0eSBzdGFjay4NCj4gDQo+IFNvIHVsdGltYXRlbHksIHRo aXMgd291bGQgcmVxdWlyZSB5b3UgdG8gZWl0aGVyIGZpZ3VyZSBvdXQgbmV0d29yayANCj4gd2lk ZSBncm91cC1rZXlzIG9yIHNvbWV0aGluZyBsaWtlIHVwIHRvIGEgZnVsbC1tZXNoIG9mIHAycCBr ZXlzIChlZzogdmlhIElLRSkuDQo+IFRoYXQgY2FuIGVhc2lseSBsZWFkIHRvIGEgYmlnIGNodW5r IG9mIGtleSBuZWdvdGlhdGlvbnMuIEFuZCB3aGVuIHdlIA0KPiBsb29rZWQgYXQgSFcga2V5cywg dGhlbiAjU0FzIGlzIHVzdWFsbHkgdGhlIGxpbWl0IG9uIEhXIHBsYXRmb3Jtcy4gDQo+IFNvbWUg cGxhdGZvcm1zIG1lYW50IHRvIGJlIGJpZyBWUE4gaGVhZGVucyBtYXkgaGF2ZSBlbm91Z2ggdG8g ZG8gdGhpcywgDQo+IG1vc3QgbmV0d29yayBkZXZpY2VzIHdvbid0Lg0KPiANCj4gQW5kIHdpdGgg anVzdCBlbmQtdG8tZW5kLCB5b3Ugc3RpbGwgaGF2ZW4ndCBlbGltaW5hdGVkIGluamVjdGlvbiBv ZiANCj4gRG9TIHRyYWZmaWMgdG8ganVzdCBvdmVybG9hZCBsb25nIG5ldHdvcmsgcGF0aHM6IEJl Y2F1c2Ugb25seSB0aGUgDQo+IHVsdGltYXRlIHJlY2VpdmVyIHdpbGwgYmUgYWJsZSB0byBhdXRo ZW50aWNhdGUgYW5kIHJlamVjdCB0aGUgcGFja2V0cy4NCj4gDQo+IFRoYXRzIGFib3V0IHRoZSBw b2ludCB3aGVuIHlvdSBzdGFydCB0byBsb3ZlIGhvcC1ieS1ob3Agc2VjdXJpdHkuIA0KPiBXaGlj aCBpcyBieSB0aGUgd2F5IGFsc28gdGhlIGFyZ3VtZW50IHVzZWQgYnkgODAyLjFhZSwgd2hpY2gg aXMgYWxzbyBob3AtYnktaG9wLg0KPiBBbmQgd2hpY2ggb3MgYnkgdGhlIHdheSBhIHF1aXRlIGF0 dHJhY3RpdmUgb3B0aW9uIHRvIHVzZSBmb3IgQUNQIElNSE8uDQo+IA0KPiBTbyB3aGVuIHlvdSdy ZSBiYWNrIGRpc2VjdGluZyBob3AtYnktaG9wIHNlY3VyaXR5LCB5b3UgaGF2ZSANCj4gYXV0aGVu dGljYXRpb24gYW5kIGVuY3J5cHRpb24uIFRvIHRoZSBiZXN0IG9mIG15IGtub3dsZWRnZSwgeW91 IGNhbiANCj4gaGF2ZSBhdXRoZW50aWNhdGlvbiB3aXRob3V0IGVuY3J5cHRpb24sIGJ1dCBub3Qg dGhlIG90aGVyIHdheSBhcm91bmQuIA0KPiBPciByYXRoZXI6IHdoZW4geW91IGNhbiBkZWNyeXB0 LCBhdXRoZW50aWNhdGlvbiB3YXMgaW1wbGllZC4gV2hpY2ggaXMgDQo+IHdoeSB3ZSBjYW4ndCB0 dXJuIE1VU1QvU0hPVUxEIGFyb3VuZC4NCg0KSW5kZWVkIG5vdC4gQnV0IGlmIHlvdSBhcmUgc2Vy aW91c2x5IHdvcnJpZWQgYWJvdXQsIGUuZy4sIGVuZW15IGJhY2tkb29ycyBpbiB5b3VyIG5ldHdv cmssIGl0IHdpbGwgYmUgTVVTVC9NVVNULiAoSSd2ZSBqdXN0IGZpbmlzaGVkIHJlYWRpbmcgQnJ1 Y2UgU2NobmVpZXIncyBib29rLCBhbmQgaXQgY2VydGFpbmx5IG1ha2VzIG9uZSB0aGluayBhYm91 dCB0aGlzIHRvcGljLikNCg0KICAgQnJpYW4NCg0KPiBDaGVlcnMNCj4gICAgIFRvZXJsZXNzDQo+ IA0KPiANCj4gT24gVHVlLCBKdW4gMjMsIDIwMTUgYXQgMDk6Mjk6NTdBTSArMTIwMCwgQnJpYW4g RSBDYXJwZW50ZXIgd3JvdGU6DQo+PiBIaSBNaWNoYWVsLA0KPj4NCj4+IEkgcHJldHR5IG11Y2gg YWdyZWUsIGJ1dA0KPj4NCj4+PiAgICA0YSAtIE1VU1Q6IEFDUCBIb3AtYnktaG9wIGF1dGhlbnRp Y2F0aW9uDQo+Pj4gICAgNGIgLSBTSE9VTEQ6IEFDUCBIb3AtYnktaG9wIGVuY3J5cHRpb24NCj4+ DQo+PiBJIHN1cHBvc2UgdGhlc2UgYXJlIG1lYW50IHRvIGJlIDVhL2IsIGJ1dCBtb3JlIHN1YnN0 YW50aXZlbHksIGlzIA0KPj4gaG9wLWJ5LWhvcCBhICpyZXF1aXJlbWVudCo/IEVuZC10by1lbmQg aXMgZGVmaW5pdGVseSByZXF1aXJlZCwgYnV0IA0KPj4gaG9wLWJ5LWhvcCBzZWVtcyBsaWtlIGFu IGltcGxlbWVudGF0aW9uIGNob2ljZS4NCj4+DQo+PiBNeSBvcGluaW9uIGlzIHRoYXQgaW4gdGhl c2UgZGF5cyBvZiBwZXJ2YXNpdmUgc3VydmVpbGxhbmNlLCANCj4+IGVuY3J5cHRpb24gaXMgYSB2 ZXJ5IHN0cm9uZyBTSE9VTEQgaW5kZWVkLg0KPj4NCj4+ICAgICBCcmlhbg0KPj4NCj4+IE9uIDIz LzA2LzIwMTUgMDQ6NDAsIE1pY2hhZWwgQmVocmluZ2VyIChtYmVocmluZykgd3JvdGU6DQo+Pj4g QU5JTUEsDQo+Pj4NCj4+PiBUcnlpbmcgdG8gZ2V0IGEgbmV3IHZlcnNpb24gb2YgdGhlIEFDUCBk cmFmdCBvdXQgbGF0ZXIgdGhpcyB3ZWVrLCBJJ20gdHJ5aW5nIHRvIHVuZGVyc3RhbmQgd2hhdCB3 ZSdyZSBhbGwgYWdyZWVpbmcgb24sIGFuZCB3aGF0IG5vdC4gDQo+Pj4NCj4+PiBBcyBJIHNlZSBp dCwgdGhlIGhpZ2ggbGV2ZWwgcmVxdWlyZW1lbnRzIChiZWxvdykgYW5kIHRoZSBiZW5lZml0cyB3 b3VsZCBnbyBpbnRvIHRoZSByZWZlcmVuY2UgbW9kZWwsIHRoZSBkZXRhaWxzIGludG8gdGhlIEFD UCBkcmFmdC4gDQo+Pj4NCj4+PiBSZXF1aXJlbWVudHMgZm9yIGFuIEFDUDogDQo+Pj4NCj4+PiAx IC0gVGhlIEFDUCBTSE9VTEQgcHJvdmlkZSByb2J1c3QgY29ubmVjdGl2aXR5DQo+Pj4gICAgQXMg ZmFyIGFzIHBvc3NpYmxlLCBpdCBzaG91bGQgYmUgaW5kZXBlbmRlbnQgb2YgY29uZmlndXJlZCBh ZGRyZXNzaW5nLCBjb25maWd1cmF0aW9uIGFuZCByb3V0aW5nLiANCj4+PiAgICAoMiBhbmQgMyBi dWlsZCBvbiB0aGlzIHJlcXVpcmVtZW50LCBidXQgYWxzbyBoYXZlIHZhbHVlIG9uIHRoZWlyIA0K Pj4+IG93bikNCj4+Pg0KPj4+IDIgLSBUaGUgQUNQIE1VU1QgaGF2ZSBhIHNlcGFyYXRlIGFkZHJl c3Mgc3BhY2UgZnJvbSB0aGUgZGF0YSBwbGFuZS4NCj4+PiAgICBSZWFzb246IHRyYWNlYWJpbGl0 eSwgZGVidWctYWJpbGl0eSwgc2VwYXJhdGlvbiBmcm9tIGRhdGEgcGxhbmUsIA0KPj4+IHNlY3Vy aXR5IChjYW4gYmxvY2sgYXQgZWRnZSkNCj4+Pg0KPj4+IDMgLSBUaGUgQUNQIE1VU1QgdXNlIGF1 dG9ub21pY2FsbHkgbWFuYWdlZCBhZGRyZXNzIHNwYWNlDQo+Pj4gICAgUmVhc29uOiBlYXN5IGJv b3RzdHJhcCBhbmQgc2V0dXAgKCJhdXRvbm9taWMiKTsgcm9idXN0bmVzcyAoYWRtaW4gY2FuJ3Qg bWVzcyB0aGluZ3MgdXAgc28gZWFzaWx5KS4NCj4+Pg0KPj4+ICAgIEkgdGhpbmsgd2UgYWdyZWVk OiBVTEEgc2VlbXMgbGlrZSBhIGdvb2QgY2hvaWNlIGZvciAxIGFuZCAyLg0KPj4+DQo+Pj4gNCAt IFRoZSBBQ1AgTVVTVCBiZSBnZW5lcmljDQo+Pj4gICAgVXNhYmxlIGJ5IGFsbCB0aGUgZnVuY3Rp b25zIGFuZCBwcm90b2NvbHMgb2YgdGhlIEFOIGluZnJhc3RydWN0dXJlLiBNVVNUIE5PVCBiZSB0 aWVkIHRvIGEgcGFydGljdWxhciBwcm90b2NvbC4gDQo+Pj4NCj4+PiA1LSBUaGUgQUNQIE1VU1Qg cHJvdmlkZSBzZWN1cml0eTogDQo+Pj4gICAgTWVzc2FnZXMgY29taW5nIHRocm91Z2ggdGhlIEFD UCBhcmUgYXV0aGVudGljYXRlZCB0byBiZSBmcm9tIGEgdHJ1c3RlZCBub2RlLCBhbmQgZW5jcnlw dGVkLiAgDQo+Pj4NCj4+PiAgICA0YSAtIE1VU1Q6IEFDUCBIb3AtYnktaG9wIGF1dGhlbnRpY2F0 aW9uDQo+Pj4gICAgNGIgLSBTSE9VTEQ6IEFDUCBIb3AtYnktaG9wIGVuY3J5cHRpb24NCj4+Pg0K Pj4+IERvIHdlIGFncmVlIG9uIHRob3NlIHJlcXVpcmVtZW50cz8gDQo+Pj4NCj4+PiBNaWNoYWVs DQo+Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4+IEFuaW1hIG1haWxpbmcgbGlzdA0KPj4+IEFuaW1hQGlldGYub3JnDQo+Pj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYQ0KPj4+DQo+Pg0KPj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IEFuaW1hIG1haWxp bmcgbGlzdA0KPj4gQW5pbWFAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vYW5pbWENCj4gDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpBbmltYSBtYWlsaW5nIGxpc3QNCkFuaW1hQGlldGYub3JnDQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hDQo= From nobody Tue Jun 23 09:09:24 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204BC1ACDB3 for ; Tue, 23 Jun 2015 09:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.928 X-Spam-Level: X-Spam-Status: No, score=-5.928 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxoBB43_tPpk for ; Tue, 23 Jun 2015 09:09:11 -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 B1FAF1ACDBF for ; Tue, 23 Jun 2015 09:09:10 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 224621A2A95EB; Tue, 23 Jun 2015 16:09:05 +0000 (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 t5NG92OS014162 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Jun 2015 18:09:03 +0200 Received: from [172.27.204.134] (135.239.27.38) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 23 Jun 2015 18:09:02 +0200 Message-ID: <5589849E.4030205@alcatel-lucent.com> Date: Tue, 23 Jun 2015 18:09:02 +0200 From: Laurent Ciavaglia Organization: Alcatel-Lucent Bell Labs France User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: John Strassner , "Michael Behringer (mbehring)" References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0F36@xmb-rcd-x14.cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010504020806040806030702" X-Originating-IP: [135.239.27.38] Archived-At: Cc: Anima WG Subject: Re: [Anima] Questions on RFC7575 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jun 2015 16:09:21 -0000 --------------010504020806040806030702 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Dear John, Michael, All, Please see below for my 2 cents... Best regards, Laurent. On 23/06/2015 03:20, John Strassner wrote: > Thanks Michael for the response. My purpose was not to affect RFC7575, > but rather to ensure consistency as we move forward. Please see inline > as well. > > Questions on RFC7575 > Page 3 > "Autonomic functions can be defined in two ways: > o On a node level: Nodes interact with each other to form feedback > loops. > o On a system level: Feedback loops include central elements as > well." > What is a "central element"? Does this mean that the feedback loop > includes centralized management mechanisms, or that there is > additional logic outside of just the nodes? > > MB: A central element is a controller for example. The point of the > section is: You could define an “autonomic network” where every node > has exactly the same interfaces as today (primarily CLI, SNMP, > NETCONF), and where a controller is involved in all control loops. Our > definition of “autonomic” is further down in the network, where nodes > interact directly with nodes. Now we all understand this isn’t black > and white, but the emphasis of the work in the IETF should be > node-to-node interactions. > > OK, got it. Just to ensure, is it fair to say that a "central > element" is one in which non-autonomic functions are used that may > affect the behavior of autonomic nodes? > LC: Agreed, with the precision that the central element can also host autonomic functions, in addition to the non-autonomic functions, i.e. avoid the understanding that the central element is _only_ composed of non-autonomic functions. > > Page 5, definition of intent > Why is intent scoped to a single autonomic domain? > > MB: Intent isn’t a policy language like most other, where you can > essentially define a policy for every network element separately. The > fundamental idea is that there is one intent for the entire network. > Thus this definition. > > My personal opinion: If we let Intent slip into the element management > scope, we’ve missed an opportunity. Intent is a policy on network scope. > > Here you lost me. ODL GBP and ODL NIC, OpenStack Congress, some > nascent work in the ONF, and TMF ZOOM would all disagree. Intent, for > better or worse, has been characterized as The New Policy (no offense > to Light Reading). But then at the end you say "Intent is a policy on > network scope", so maybe I'm reading you too literally? (see I haven't > changed since my Cisco days :-) ). > LC: I guess what Michael / RFC7575 mean by "one intent for the entire network" and not going into the "element management scope" is to voluntarily "stop" the intent at the network level and by doing this setting the system or network-wide goal. For sure, this decision assumes that there are other / underlying mechanisms to translate / define the lower layers / levels / per element policies. LC: I think ANIMA (or other initiatives) could bring new ideas / mechanisms on how to make sure that the whole system / network work well / as planned by employing a netwrok-level intent (e.g. how autonomic elements knows to which domain(s) they belong, how they can understand / translate the intent correctly...). > > > Plus, do you really mean "for the entire network"? Isn't "for a given > set of administrative domains" good enough? > LC: I think "the entire network" means for "one network domain". Going by our (loose) definition (RFC7575) a set of domains can also apply. As for "adminstrative", this is still under discussion as to which criteria are used to define "domain" (cf discussion thread on the ANIMA mailing list). > > Page 5, definition of autonomic domain > Why is autonomic domain tied to intent as the only management > paradigm? The vast majority of work in autonomic networking does NOT > use intent (what I call declarative logic, I failed marketing :-) ). I > completely agree with using intent, and perhaps even emphasizing it, > but I don't agree with excluding other management paradigms. > > MB: Probably a question of wording. In my reading you have 1) > autonomic default behaviour (could also call this “default intent”), > 2) Intent, and 3) traditional management schemes, such as NETCONF, > SNMP, CLI, etc… > > So we don’t exclude other management paradigms, they are handles in > section 3.2. Is that what you mean? > > (You could also define an autonomic domain by the zone of trust of the > certificates.) > > Yes. Note that in SUPA, we derive intent and traditional (i.e., > ECA) from the same Policy info model. This has the nice property of > letting intent translate across actors and be used to fire ECA > policies (and vice versa). > LC: I don't know what 1) autonomic default behavior / default intent really means (i.e. what behavor(s) it will trigger. Also, for me, 2) and 3) are not competing management schemes. They are different levels of abstraction and capability. You can have A- the human operator / OSS injecting (managing) directly all the network elements solely via NETCONF, SNMP, CLI... You can have B- the human operator / OSS injecting (managing) via a policy (imperative or declarative model) which are then translated into NETCONF, SNMP, CLI... In A, the intent / policy is not explicitly defined, it is in the "mind" of the human operator who knows what the network and the network elements should do and then directly translate it into the NETCONF, SNMP, CLI parameters/values. In B, the intent / policy is explicitly defined, and a mechanism/function is responsible for the translation into the appropriate output. In parallel the priority between the different mode of operations needs to be specified (cf other discussion on the ANIMA mailing list). > Page 5, self-management > "They configure themselves, based on self-knowledge, discovery, and > Intent." > The word "discovery" is confusing me. Suppose a node runs a utility > function to decide what its next configuration change should be. It is > not "discovering" something that existed - rather, it is computing new > knowledge. A machine learning function that infers new knowledge is an > even better example of something that is not "discovered". I'm > probably missing something, but why was this choice made? > > The thing that really bothers me is that this assumes that all > knowledge can be discovered - that is, it is existing, like an apple > on a tree, ready to be plucked. In the autonomic systems that I've > built, this is only sometimes the case. It is vital for an autonomic > system to be able to learn new knowledge via computation and > inference, as well as decide that previous knowledge was incorrect. > Neither of these are discovery functions. > > MB: I think the confusion is the definition of “discovery” here. It’s > not only discovery in the sense of service discovery, but for example, > finding neighbors, negotiating parameters with them, etc. > > The above phrase in other words: “I know my capabilities, I see what > else is there (and talk to it potentially), and I see what the boss > wants to happen (intent). Based on all of this I decide what I’m going > to do”. > > I think it’s a question of wording. We had this graphic (similar to > figure 1), where there are the 3 input vectors (!) of information, on > which you base your decisions. The inference you mention is a > consequence of those inputs. In other words, the “brain” that actually > makes the inference, is in our model the autonomic service agent. > > Does that make sense? > > I think so. I still think that my two examples are not > discovery. I had somehow concluded that discovery was all-inclusive, > but when I look at your answer, I realize that it isn't. Still, in the > reference document, I think we should point this out. I do agree that > discovery is sometimes not explicitly mentioned, which is a shame, > since it is such a vital function. It would therefore be OK imho to > emphasize discovery as long as we leave some wiggle room for > dynamically creating and removing knowledge. > LC: Fully agree with John. If we follow a strict definition: you can only discover (pre-)existing knowledge. I think in ANIMA we aim also to address the case where the autonomic functions / the system as a whole creates new knowledge, this is opening the realm of learning capable agents and several base mechanisms /functions could be subject to standardization in this area, providing a net functionality gain. > > Page 6, last paragraph above section 3.2 > "...closed-loop control is an important aspect of self-managing systems. > > This implies peer-to-peer dialogues between the parties that make up > > the closed loop. Such dialogues require two-way "discussion" or > "negotiation" > > between each pair or groups of peers involved in the loop,..." > First, by "peer", I assume you mean two (or more) equipotent entities > that make some portion of their resources available to others. Second, > and more importantly, a closed control loop does not require each > entity in the closed control loop to talk to negotiate with other > entities. Now, in an autonomic control loop, this could very well be > the case, but it is unclear to me why it MUST be the case. The obvious > nightmare scenario is that the negotiation fails. Then what - we have > no control loop at all? > > MB: I guess your point is that an autonomic process doesn’t HAVE to > have a control loop. I would argue that the typical autonomic function > DOES have node-to-node interactions. This is what autonomics is all > about. Now, yes, there will be cases where this fails, and where a > node also needs to do something sensible in case of complete > isolation. But that’s an exception state in my mind. > > No. Let me try again. > > The text that bothers me is "[closed-loop] implies peer-to-peer > dialogues between the parties that make up the close loop". That isn't > how traditional control loops are typically built, and I'm personally > not familiar with any autonomic system that builds them in this way. > Sure, it would be nice to allow this when necessary - FOCALE had this > feature through a dedicated control interface that could adapt the > function carried out by a control loop element based on (for example) > changing context - but I disagree that it is a MANDATORY function. > LC: I think the use of "require" might be too strong / misleading in the sense that it is not a MUST (in the requirements process meaning) We could/should clarify this in the reference model. > > > To your second point, I do (of course!) agree that autonomics is about > node-to-node interactions. But, it is also about system-wide > interactions. My point was that if you mandate negotiation in order to > create a control loop, and the negotiation fails, you're in trouble. > And yes, that would be an exception state in my mind, as it violates a > basic principle in autonomics - consensual behavior. > LC: a work item for the reference model document could be to describe more clearly where those control loops are in the model/among which elements (i.e. instances of the same autonomic functions, between different autonomic functions, vertical vs. horizontal...) > > Pages 7-8, Section 3.6 > Most autonomic networking systems to date have NOT been built with an > intent (or declarative) style interface. FOCALE enables declarative > and prescriptive (e.g., ECA policy rules) to be used. Others just use > ECA (or an equivalent) paradigm. Hence, I'm wondering why intent is > the ONLY paradigm that is mentioned in this RFC that is suitable for > autonomic networking? Shouldn't we try and peacefully coexist, just as > the nodes are peacefully coexisting with non-autonomic directives? > > MB: To me, ECA is encoded in an ASA or an autonomic function. The > function says what action you take in specific events, and under which > condition. > > Example: The “enrolment proxy ASA” has the following (hard coded) ESA: > > -Event: A new node is detected > > -Condition: it doesn’t have a domain cert yet > > -Action: I invite the node to join my network. > > Now, Intent is in my mind a higher level concept which could now state > “do not enrol new nodes at this moment”. > > How would you see that? > > Is the action a typo, and you really meant: "I do not invite the > node to join my network"? As stated, I would say that the ECA policy > would NOT fire because it violates intent. However, to my earlier > point above about intent and ECA policies being able to call each > other - ABSOLUTELY. > LC: I think Michael was illustrating the fact that the intent and the ECA policy could be defined at different levels and might contradict each other (something we should try to prevent by design/BCP in ANIMA) and then you need to handle this conflict (e;g. using the priorities or other techniques (knowing that policy conflict resolution is not a solved problem)). > > Page 9, section 3.7 > "However, in an Autonomic Network, reporting should happen on a > network-wide basis." > > True, but shouldn't individual nodes and collections of nodes still > report? That isn't implied in the wording. > > MB: Yes, they should. This is “traditional management methods”. In our > model, every node does the normal syslog, etc., and aggregated > reporting is the new thing that comes with AN. > > Got it, thanks. > > Furthermore, the last paragraph says: "Autonomic network events should > concern the Autonomic Network as a whole, not individual systems in > isolation." I agree that the goal is to report on the system as a > whole, but isn't such a report collected from individual nodes? Just > like in your example, the nodes need to be able to see that a problem > has already been reported in order to know not to issue the same problem. > > MB: There are two parallel methods of reporting: > > 1)the traditional every-node-to-controller method, where the > intelligence is central > > 2)a distributed reporting function, where nodes aggregate, process, > summarise, correlate, … information before handing it to the > controller. Here the intelligence is distributed. > > Both will co-exist. The RFC focuses on the new method (and obviously > isn’t clear enough about it…) > > OK, got it. In FOCALE, we almost NEVER used node-to-controller > (well, FOCALE predates SDN controllers, but let's say controller == > some centralized manager) unless the majority (or more) of nodes > failed. We did use an umbrella management paradigm (similar to > clusterheads in P2P networks), where the clusterheads did collection, > filtering, correlation, and possibly other functions before passing > the data (not necessarily up!). I'm happy to focus on the new, just > want to ensure we have some fallback position for not just legacy > integration, but more importantly, failure modes. > > Pages 12-13, section 5 > Why is an Autonomic **User** Agent the interface to a control loop? I > can see an external entity wanting to configure and monitor the > control loop, but why wouldn't the User Agent talk to the Service > Agent to do this? I do note that this figure is under discussion and > being revised in the reference model. > > MB: Yes, that’s confusing wording, and now that you mention it, yes we > should have probably looked for a better term. The idea is: The > “intelligence” of an autonomic function is in the ASA (middle of > figure 1). There are now horizontal feedback loops and northbound > feedback loops. For example, there is likely a function in the > enrolment process, where a message gets sent to the admin: “Here’s a > new node, I don’t think it belongs into our network, I’ve quarantined > that node for now; would you like me to 1) accept the node anyway, or > 2) mark it as bad?” > > I agree the term “user agent” is not good. We need to find a better > one. Suggestions? > > So does "user agent" mean "(autonomic) management agent"? > Probably NOT a user-facing agent, right? In the tradition of Calm > Technology, the best and most ubiquitous functions are those that > don't demand attention, but rather inform. > LC: We will certainly need to revise this part of the model, and start by defining who interfaces with it (e.g. the human operator / the OSS) and to do what with the system, once done I think the diagrams will be clearer and less equivoque. > Page 13, Figure 1 > Where is the Autonomic Node in the Reference Model? I do note that > this figure is under discussion and being revised in the reference > model. However, even in Figure 2 of the reference model, it is still > unclear what the "node" is. But more on that later. > > MB: The whole thing is the node. That’s why the figure is called > “Reference Model for an Autonomic Node”. > > But if it is a **node**, then why is it running its own internal > feedback loops? Note that "node" implies a single something. Clearly, > the single something can contain groups of other somethings, but why > would a feedback loop exist in the single something when we are > emphasizing inter-node communication and functionality? > > > I think that this figure would be improved by showing interfaces to > the Autonomic Control Plane and to the OS; right now, they are inside > of the node, and that I don't understand. In FOCALE, as well as other > architectures, knowledge did not have to be embedded in the node, it > could be received from other places in the network. Hence, I think > that showing interfaces to where knowledge is obtained and where it is > discovered is more generic. Of course, more capable nodes could > contain these functions, but I'm not convinced that this is the norm. > > > Thanks for all your input John! Let’s make sure that all these points > get addressed in the reference model. > > I hope it helps. I think I can now write my sections in a way > that will be more consistent. More feedback coming later. > > Michael > > > best regards, > John > > > > On Mon, Jun 22, 2015 at 8:46 AM, Michael Behringer (mbehring) > > wrote: > > Hi John, let me take a stab at responding… And thanks for sharing > your thoughts. A bit late to bring them into RFC7575, but a good > timing for the reference model. > > *From:*Anima [mailto:anima-bounces@ietf.org > ] *On Behalf Of *John Strassner > *Sent:* 21 June 2015 19:28 > *To:* Anima WG > *Subject:* [Anima] Questions on RFC7575 > > I started reviewing both the reference model as well as other > pertinent documents, so that when I write my sections for the > reference model, they are consistent. :-) > > In doing so, I have a number of questions on RFC7575. Part of this > may be my academic nature, part may be because I have undoubtedly > missed something in past emails as I come up to speed, and partly > because I'm likely under-caffeinated. Hopefully, some of this will > help improve the reference model (and possibly other documents as > well). > > Questions on RFC7575 > Page 3 > "Autonomic functions can be defined in two ways: > o On a node level: Nodes interact with each other to form feedback > loops. > o On a system level: Feedback loops include central elements as > well." > What is a "central element"? Does this mean that the feedback loop > includes centralized management mechanisms, or that there is > additional logic outside of just the nodes? > > MB: A central element is a controller for example. The point of > the section is: You could define an “autonomic network” where > every node has exactly the same interfaces as today (primarily > CLI, SNMP, NETCONF), and where a controller is involved in all > control loops. Our definition of “autonomic” is further down in > the network, where nodes interact directly with nodes. Now we all > understand this isn’t black and white, but the emphasis of the > work in the IETF should be node-to-node interactions. > > Page 5, definition of intent > Why is intent scoped to a single autonomic domain? > > MB: Intent isn’t a policy language like most other, where you can > essentially define a policy for every network element separately. > The fundamental idea is that there is one intent for the entire > network. Thus this definition. > > My personal opinion: If we let Intent slip into the element > management scope, we’ve missed an opportunity. Intent is a policy > on network scope. > > Page 5, definition of autonomic domain > Why is autonomic domain tied to intent as the only management > paradigm? The vast majority of work in autonomic networking does > NOT use intent (what I call declarative logic, I failed marketing > :-) ). I completely agree with using intent, and perhaps even > emphasizing it, but I don't agree with excluding other management > paradigms. > > MB: Probably a question of wording. In my reading you have 1) > autonomic default behaviour (could also call this “default > intent”), 2) Intent, and 3) traditional management schemes, such > as NETCONF, SNMP, CLI, etc… > > So we don’t exclude other management paradigms, they are handles > in section 3.2. Is that what you mean? > > (You could also define an autonomic domain by the zone of trust of > the certificates.) > > Page 5, self-management > "They configure themselves, based on self-knowledge, discovery, > and Intent." > The word "discovery" is confusing me. Suppose a node runs a > utility function to decide what its next configuration change > should be. It is not "discovering" something that existed - > rather, it is computing new knowledge. A machine learning function > that infers new knowledge is an even better example of something > that is not "discovered". I'm probably missing something, but why > was this choice made? > > The thing that really bothers me is that this assumes that all > knowledge can be discovered - that is, it is existing, like an > apple on a tree, ready to be plucked. In the autonomic systems > that I've built, this is only sometimes the case. It is vital for > an autonomic system to be able to learn new knowledge via > computation and inference, as well as decide that previous > knowledge was incorrect. Neither of these are discovery functions. > > MB: I think the confusion is the definition of “discovery” here. > It’s not only discovery in the sense of service discovery, but for > example, finding neighbors, negotiating parameters with them, etc. > > The above phrase in other words: “I know my capabilities, I see > what else is there (and talk to it potentially), and I see what > the boss wants to happen (intent). Based on all of this I decide > what I’m going to do”. > > I think it’s a question of wording. We had this graphic (similar > to figure 1), where there are the 3 input vectors (!) of > information, on which you base your decisions. The inference you > mention is a consequence of those inputs. In other words, the > “brain” that actually makes the inference, is in our model the > autonomic service agent. > > Does that make sense? > > Page 6, last paragraph above section 3.2 > "...closed-loop control is an important aspect of self-managing > systems. > > This implies peer-to-peer dialogues between the parties that make up > > the closed loop. Such dialogues require two-way "discussion" or > "negotiation" > > between each pair or groups of peers involved in the loop,..." > First, by "peer", I assume you mean two (or more) equipotent > entities that make some portion of their resources available to > others. Second, and more importantly, a closed control loop does > not require each entity in the closed control loop to talk to > negotiate with other entities. Now, in an autonomic control loop, > this could very well be the case, but it is unclear to me why it > MUST be the case. The obvious nightmare scenario is that the > negotiation fails. Then what - we have no control loop at all? > > MB: I guess your point is that an autonomic process doesn’t HAVE > to have a control loop. I would argue that the typical autonomic > function DOES have node-to-node interactions. This is what > autonomics is all about. Now, yes, there will be cases where this > fails, and where a node also needs to do something sensible in > case of complete isolation. But that’s an exception state in my mind. > > Pages 7-8, Section 3.6 > Most autonomic networking systems to date have NOT been built with > an intent (or declarative) style interface. FOCALE enables > declarative and prescriptive (e.g., ECA policy rules) to be used. > Others just use ECA (or an equivalent) paradigm. Hence, I'm > wondering why intent is the ONLY paradigm that is mentioned in > this RFC that is suitable for autonomic networking? Shouldn't we > try and peacefully coexist, just as the nodes are peacefully > coexisting with non-autonomic directives? > > MB: To me, ECA is encoded in an ASA or an autonomic function. The > function says what action you take in specific events, and under > which condition. > > Example: The “enrolment proxy ASA” has the following (hard coded) > ESA: > > -Event: A new node is detected > > -Condition: it doesn’t have a domain cert yet > > -Action: I invite the node to join my network. > > Now, Intent is in my mind a higher level concept which could now > state “do not enrol new nodes at this moment”. > > How would you see that? > > Page 9, section 3.7 > "However, in an Autonomic Network, reporting should happen on a > network-wide basis." > > True, but shouldn't individual nodes and collections of nodes > still report? That isn't implied in the wording. > > MB: Yes, they should. This is “traditional management methods”. In > our model, every node does the normal syslog, etc., and aggregated > reporting is the new thing that comes with AN. > > Furthermore, the last paragraph says: "Autonomic network events > should concern the Autonomic Network as a whole, not individual > systems in isolation." I agree that the goal is to report on the > system as a whole, but isn't such a report collected from > individual nodes? Just like in your example, the nodes need to be > able to see that a problem has already been reported in order to > know not to issue the same problem. > > MB: There are two parallel methods of reporting: > > 1)the traditional every-node-to-controller method, where the > intelligence is central > > 2)a distributed reporting function, where nodes aggregate, > process, summarise, correlate, … information before handing it to > the controller. Here the intelligence is distributed. > > Both will co-exist. The RFC focuses on the new method (and > obviously isn’t clear enough about it…) > > Pages 12-13, section 5 > Why is an Autonomic **User** Agent the interface to a control > loop? I can see an external entity wanting to configure and > monitor the control loop, but why wouldn't the User Agent talk to > the Service Agent to do this? I do note that this figure is under > discussion and being revised in the reference model. > > MB: Yes, that’s confusing wording, and now that you mention it, > yes we should have probably looked for a better term. The idea is: > The “intelligence” of an autonomic function is in the ASA (middle > of figure 1). There are now horizontal feedback loops and > northbound feedback loops. For example, there is likely a function > in the enrolment process, where a message gets sent to the admin: > “Here’s a new node, I don’t think it belongs into our network, > I’ve quarantined that node for now; would you like me to 1) accept > the node anyway, or 2) mark it as bad?” > > I agree the term “user agent” is not good. We need to find a > better one. Suggestions? > > Page 13, Figure 1 > Where is the Autonomic Node in the Reference Model? I do note that > this figure is under discussion and being revised in the reference > model. However, even in Figure 2 of the reference model, it is > still unclear what the "node" is. But more on that later. > > MB: The whole thing is the node. That’s why the figure is called > “Reference Model for an Autonomic Node”. > > Thanks for all your input John! Let’s make sure that all these > points get addressed in the reference model. > > Michael > -- > > regards, > > John > > > > > -- > regards, > John > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- Bien cordialement, Best regards, *Laurent Ciavaglia* Secure Cloud Networking Bell Labs | Alcatel Lucent phone: +33 160 402 636 email: laurent.ciavaglia@alcatel-lucent.com linkedin: laurentciavaglia address: Route de Villejust | 91620 Nozay | France --------------010504020806040806030702 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit Dear John, Michael, All,

Please see below for my 2 cents...

Best regards, Laurent.



On 23/06/2015 03:20, John Strassner wrote:
Thanks Michael for the response. My purpose was not to affect RFC7575, but rather to ensure consistency as we move forward. Please see inline as well.

Questions on RFC7575
Page 3
"Autonomic functions can be defined in two ways:
  o On a node level: Nodes interact with each other to form feedback
    loops.
  o On a system level: Feedback loops include central elements as
    well."
What is a "central element"? Does this mean that the feedback loop includes centralized management mechanisms, or that there is additional logic outside of just the nodes?

 

MB: A central element is a controller for example. The point of the section is: You could define an “autonomic network” where every node has exactly the same interfaces as today (primarily CLI, SNMP, NETCONF), and where a controller is involved in all control loops. Our definition of “autonomic” is further down in the network, where nodes interact directly with nodes. Now we all understand this isn’t black and white, but the emphasis of the work in the IETF should be node-to-node interactions.

<jcs> OK, got it. Just to ensure, is it fair to say that a "central element" is one in which non-autonomic functions are used that may affect the behavior of autonomic nodes? </jcs>

LC: Agreed, with the precision that the central element can also host autonomic functions, in addition to the non-autonomic functions, i.e. avoid the understanding that the central element is only composed of non-autonomic functions.


Page 5, definition of intent
Why is intent scoped to a single autonomic domain?

 

MB: Intent isn’t a policy language like most other, where you can essentially define a policy for every network element separately. The fundamental idea is that there is one intent for the entire network. Thus this definition.

My personal opinion: If we let Intent slip into the element management scope, we’ve missed an opportunity. Intent is a policy on network scope.

<jcs> Here you lost me. ODL GBP and ODL NIC, OpenStack Congress, some nascent work in the ONF, and TMF ZOOM would all disagree. Intent, for better or worse, has been characterized as The New Policy (no offense to Light Reading). But then at the end you say "Intent is a policy on network scope", so maybe I'm reading you too literally? (see I haven't changed since my Cisco days :-) ).

LC: I guess what Michael / RFC7575 mean by "one intent for the entire network" and not going into the "element management scope" is to voluntarily "stop" the intent at the network level and by doing this setting the system or network-wide goal.
For sure, this decision assumes that there are other / underlying mechanisms to translate / define the lower layers / levels / per element policies.
LC: I think ANIMA (or other initiatives) could bring new ideas / mechanisms on how to make sure that the whole system / network work well / as planned by employing a netwrok-level intent (e.g. how autonomic elements knows to which domain(s) they belong, how they can understand / translate the intent correctly...).    


Plus, do you really mean "for the entire network"? Isn't "for a given set of administrative domains" good enough? </jcs>

LC: I think "the entire network" means for "one network domain". Going by our (loose) definition (RFC7575) a set of domains can also apply. As for "adminstrative", this is still under discussion as to which criteria are used to define "domain" (cf discussion thread on the ANIMA mailing list).

 

Page 5, definition of autonomic domain
Why is autonomic domain tied to intent as the only management paradigm? The vast majority of work in autonomic networking does NOT use intent (what I call declarative logic, I failed marketing :-) ). I completely agree with using intent, and perhaps even emphasizing it, but I don't agree with excluding other management paradigms.

 

MB: Probably a question of wording. In my reading you have 1) autonomic default behaviour (could also call this “default intent”), 2) Intent, and 3) traditional management schemes, such as NETCONF, SNMP, CLI, etc… 

So we don’t exclude other management paradigms, they are handles in section 3.2. Is that what you mean?

(You could also define an autonomic domain by the zone of trust of the certificates.)

<jcs> Yes. Note that in SUPA, we derive intent and traditional (i.e., ECA) from the same Policy info model. This has the nice property of letting intent translate across actors and be used to fire ECA policies (and vice versa). </jcs>

LC: I don't know what 1) autonomic default behavior / default intent really means (i.e. what behavor(s) it will trigger. Also, for me, 2) and 3) are not competing management schemes. They are different levels of abstraction and capability.
You can have A- the human operator / OSS injecting (managing) directly all the network elements solely via NETCONF, SNMP, CLI...
You can have B- the human operator / OSS injecting (managing) via a policy (imperative or declarative model) which are then translated into NETCONF, SNMP, CLI...
In A, the intent / policy is not explicitly defined, it is in the "mind" of the human operator who knows what the network and the network elements should do and then directly translate it into the NETCONF, SNMP, CLI parameters/values.
In B, the intent / policy is explicitly defined, and a mechanism/function is responsible for the translation into the appropriate output.
In parallel the priority between the different mode of operations needs to be specified (cf other discussion on the ANIMA mailing list).

 

Page 5, self-management
"They configure themselves, based on self-knowledge, discovery, and Intent."
The word "discovery" is confusing me. Suppose a node runs a utility function to decide what its next configuration change should be. It is not "discovering" something that existed - rather, it is computing new knowledge. A machine learning function that infers new knowledge is an even better example of something that is not "discovered". I'm probably missing something, but why was this choice made?

The thing that really bothers me is that this assumes that all knowledge can be discovered - that is, it is existing, like an apple on a tree, ready to be plucked. In the autonomic systems that I've built, this is only sometimes the case. It is vital for an autonomic system to be able to learn new knowledge via computation and inference, as well as decide that previous knowledge was incorrect. Neither of these are discovery functions.

 

MB: I think the confusion is the definition of “discovery” here. It’s not only discovery in the sense of service discovery, but for example, finding neighbors, negotiating parameters with them, etc.

The above phrase in other words: “I know my capabilities, I see what else is there (and talk to it potentially), and I see what the boss wants to happen (intent). Based on all of this I decide what I’m going to do”.

I think it’s a question of wording. We had this graphic (similar to figure 1), where there are the 3 input vectors (!) of information, on which you base your decisions. The inference you mention is a consequence of those inputs. In other words, the “brain” that actually makes the inference, is in our model the autonomic service agent.

Does that make sense?

<jcs> I think so. I still think that my two examples are not discovery. I had somehow concluded that discovery was all-inclusive, but when I look at your answer, I realize that it isn't. Still, in the reference document, I think we should point this out. I do agree that discovery is sometimes not explicitly mentioned, which is a shame, since it is such a vital function. It would therefore be OK imho to emphasize discovery as long as we leave some wiggle room for dynamically creating and removing knowledge. </jcs>

LC: Fully agree with John. If we follow a strict definition: you can only discover (pre-)existing knowledge. I think in ANIMA we aim also to address the case where the autonomic functions / the system as a whole creates new knowledge, this is opening  the realm of learning capable agents and several base mechanisms /functions could be subject to standardization in this area, providing a net functionality gain.

 

Page 6, last paragraph above section 3.2
"...closed-loop control is an important aspect of self-managing systems.

This implies peer-to-peer dialogues between the parties that make up

the closed loop. Such dialogues require two-way "discussion" or "negotiation"

between each pair or groups of peers involved in the loop,..."
First, by "peer", I assume you mean two (or more) equipotent entities that make some portion of their resources available to others. Second, and more importantly, a closed control loop does not require each entity in the closed control loop to talk to negotiate with other entities. Now, in an autonomic control loop, this could very well be the case, but it is unclear to me why it MUST be the case. The obvious nightmare scenario is that the negotiation fails. Then what - we have no control loop at all?

 

MB: I guess your point is that an autonomic process doesn’t HAVE to have a control loop. I would argue that the typical autonomic function DOES have node-to-node interactions. This is what autonomics is all about. Now, yes, there will be cases where this fails, and where a node also needs to do something sensible in case of complete isolation. But that’s an exception state in my mind.

<jcs> No. Let me try again.

The text that bothers me is "[closed-loop] implies peer-to-peer dialogues between the parties that make up the close loop". That isn't how traditional control loops are typically built, and I'm personally not familiar with any autonomic system that builds them in this way. Sure, it would be nice to allow this when necessary - FOCALE had this feature through a dedicated control interface that could adapt the function carried out by a control loop element based on (for example) changing context - but I disagree that it is a MANDATORY function.

LC: I think the use of "require" might be too strong / misleading in the sense that it is not a MUST (in the requirements process meaning) We could/should clarify this in the reference model.


To your second point, I do (of course!) agree that autonomics is about node-to-node interactions. But, it is also about system-wide interactions. My point was that if you mandate negotiation in order to create a control loop, and the negotiation fails, you're in trouble. And yes, that would be an exception state in my mind, as it violates a basic principle in autonomics - consensual behavior. </jcs>

LC: a work item for the reference model document could be to describe more clearly where those control loops are in the model/among which elements (i.e. instances of the same autonomic functions, between different autonomic functions, vertical vs. horizontal...)

 

Pages 7-8, Section 3.6
Most autonomic networking systems to date have NOT been built with an intent (or declarative) style interface. FOCALE enables declarative and prescriptive (e.g., ECA policy rules) to be used. Others just use ECA (or an equivalent) paradigm. Hence, I'm wondering why intent is the ONLY paradigm that is mentioned in this RFC that is suitable for autonomic networking? Shouldn't we try and peacefully coexist, just as the nodes are peacefully coexisting with non-autonomic directives?

 

MB: To me, ECA is encoded in an ASA or an autonomic function. The function says what action you take in specific events, and under which condition.

Example: The “enrolment proxy ASA” has the following (hard coded) ESA:

-          Event: A new node is detected

-          Condition: it doesn’t have a domain cert yet

-          Action: I invite the node to join my network.

Now, Intent is in my mind a higher level concept which could now state “do not enrol new nodes at this moment”.

How would you see that?

<jcs> Is the action a typo, and you really meant: "I do not invite the node to join my network"? As stated, I would say that the ECA policy would NOT fire because it violates intent. However, to my earlier point above about intent and ECA policies being able to call each other - ABSOLUTELY. </jcs>

LC: I think Michael was illustrating the fact that the intent and the ECA policy could be defined at different levels and might contradict each other (something we should try to prevent by design/BCP in ANIMA) and then you need to handle this conflict (e;g. using the priorities or other techniques (knowing that policy conflict resolution is not a solved problem)).

 

Page 9, section 3.7
"However, in an Autonomic Network, reporting should happen on a network-wide basis."

True, but shouldn't individual nodes and collections of nodes still report? That isn't implied in the wording.

 

MB: Yes, they should. This is “traditional management methods”. In our model, every node does the normal syslog, etc., and aggregated reporting is the new thing that comes with AN.

<jcs> Got it, thanks. </jcs>

 

Furthermore, the last paragraph says: "Autonomic network events should concern the Autonomic Network as a whole, not individual systems in isolation." I agree that the goal is to report on the system as a whole, but isn't such a report collected from individual nodes? Just like in your example, the nodes need to be able to see that a problem has already been reported in order to know not to issue the same problem.

 

MB: There are two parallel methods of reporting:

1)      the traditional every-node-to-controller method, where the intelligence is central

2)      a distributed reporting function, where nodes aggregate, process, summarise, correlate, …  information before handing it to the controller. Here the intelligence is distributed.

Both will co-exist. The RFC focuses on the new method (and obviously isn’t clear enough about it…)

<jcs> OK, got it. In FOCALE, we almost NEVER used node-to-controller (well, FOCALE predates SDN controllers, but let's say controller == some centralized manager) unless the majority (or more) of nodes failed. We did use an umbrella management paradigm (similar to clusterheads in P2P networks), where the clusterheads did collection, filtering, correlation, and possibly other functions before passing the data (not necessarily up!). I'm happy to focus on the new, just want to ensure we have some fallback position for not just legacy integration, but more importantly, failure modes. </jcs>

 

Pages 12-13, section 5
Why is an Autonomic **User** Agent the interface to a control loop? I can see an external entity wanting to configure and monitor the control loop, but why wouldn't the User Agent talk to the Service Agent to do this? I do note that this figure is under discussion and being revised in the reference model.

 

MB: Yes, that’s confusing wording, and now that you mention it, yes we should have probably looked for a better term. The idea is: The “intelligence” of an autonomic function is in the ASA (middle of figure 1). There are now horizontal feedback loops and northbound feedback loops. For example, there is likely a function in the enrolment process, where a message gets sent to the admin: “Here’s a new node, I don’t think it belongs into our network, I’ve quarantined that node for now; would you like me to 1) accept the node anyway, or 2) mark it as bad?”

 

I agree the term “user agent” is not good. We need to find a better one. Suggestions?

<jcs> So does "user agent" mean "(autonomic) management agent"? Probably NOT a user-facing agent, right? In the tradition of Calm Technology, the best and most ubiquitous functions are those that don't demand attention, but rather inform. </jcs>

 

LC: We will certainly need to revise this part of the model, and start by defining who interfaces with it (e.g. the human operator / the OSS) and to do what with the system, once done I think the diagrams will be clearer and less equivoque.

Page 13, Figure 1
Where is the Autonomic Node in the Reference Model? I do note that this figure is under discussion and being revised in the reference model. However, even in Figure 2 of the reference model, it is still unclear what the "node" is. But more on that later.

MB: The whole thing is the node. That’s why the figure is called “Reference Model for an Autonomic Node”.

<jcs> But if it is a **node**, then why is it running its own internal feedback loops? Note that "node" implies a single something. Clearly, the single something can contain groups of other somethings, but why would a feedback loop exist in the single something when we are emphasizing inter-node communication and functionality?


I think that this figure would be improved by showing interfaces to the Autonomic Control Plane and to the OS; right now, they are inside of the node, and that I don't understand. In FOCALE, as well as other architectures, knowledge did not have to be embedded in the node, it could be received from other places in the network. Hence, I think that showing interfaces to where knowledge is obtained and where it is discovered is more generic. Of course, more capable nodes could contain these functions, but I'm not convinced that this is the norm. </jcs>

 

Thanks for all your input John! Let’s make sure that all these points get addressed in the reference model.

<jcs> I hope it helps. I think I can now write my sections in a way that will be more consistent. More feedback coming later. </jcs>

 

Michael


best regards,
John



On Mon, Jun 22, 2015 at 8:46 AM, Michael Behringer (mbehring) <mbehring@cisco.com> wrote:

Hi John, let me take a stab at responding… And thanks for sharing your thoughts. A bit late to bring them into RFC7575, but a good timing for the reference model.

 

From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of John Strassner
Sent: 21 June 2015 19:28
To: Anima WG
Subject: [Anima] Questions on RFC7575

 

I started reviewing both the reference model as well as other pertinent documents, so that when I write my sections for the reference model, they are consistent. :-)

 

In doing so, I have a number of questions on RFC7575. Part of this may be my academic nature, part may be because I have undoubtedly missed something in past emails as I come up to speed, and partly because I'm likely under-caffeinated. Hopefully, some of this will help improve the reference model (and possibly other documents as well).

 

Questions on RFC7575
Page 3
"Autonomic functions can be defined in two ways:
  o On a node level: Nodes interact with each other to form feedback
    loops.
  o On a system level: Feedback loops include central elements as
    well."
What is a "central element"? Does this mean that the feedback loop includes centralized management mechanisms, or that there is additional logic outside of just the nodes?

 

MB: A central element is a controller for example. The point of the section is: You could define an “autonomic network” where every node has exactly the same interfaces as today (primarily CLI, SNMP, NETCONF), and where a controller is involved in all control loops. Our definition of “autonomic” is further down in the network, where nodes interact directly with nodes. Now we all understand this isn’t black and white, but the emphasis of the work in the IETF should be node-to-node interactions.

 

Page 5, definition of intent
Why is intent scoped to a single autonomic domain?

 

MB: Intent isn’t a policy language like most other, where you can essentially define a policy for every network element separately. The fundamental idea is that there is one intent for the entire network. Thus this definition.

My personal opinion: If we let Intent slip into the element management scope, we’ve missed an opportunity. Intent is a policy on network scope.

 

Page 5, definition of autonomic domain
Why is autonomic domain tied to intent as the only management paradigm? The vast majority of work in autonomic networking does NOT use intent (what I call declarative logic, I failed marketing :-) ). I completely agree with using intent, and perhaps even emphasizing it, but I don't agree with excluding other management paradigms.

 

MB: Probably a question of wording. In my reading you have 1) autonomic default behaviour (could also call this “default intent”), 2) Intent, and 3) traditional management schemes, such as NETCONF, SNMP, CLI, etc… 

So we don’t exclude other management paradigms, they are handles in section 3.2. Is that what you mean?

(You could also define an autonomic domain by the zone of trust of the certificates.)

 

Page 5, self-management
"They configure themselves, based on self-knowledge, discovery, and Intent."
The word "discovery" is confusing me. Suppose a node runs a utility function to decide what its next configuration change should be. It is not "discovering" something that existed - rather, it is computing new knowledge. A machine learning function that infers new knowledge is an even better example of something that is not "discovered". I'm probably missing something, but why was this choice made?

The thing that really bothers me is that this assumes that all knowledge can be discovered - that is, it is existing, like an apple on a tree, ready to be plucked. In the autonomic systems that I've built, this is only sometimes the case. It is vital for an autonomic system to be able to learn new knowledge via computation and inference, as well as decide that previous knowledge was incorrect. Neither of these are discovery functions.

 

MB: I think the confusion is the definition of “discovery” here. It’s not only discovery in the sense of service discovery, but for example, finding neighbors, negotiating parameters with them, etc.

The above phrase in other words: “I know my capabilities, I see what else is there (and talk to it potentially), and I see what the boss wants to happen (intent). Based on all of this I decide what I’m going to do”.

I think it’s a question of wording. We had this graphic (similar to figure 1), where there are the 3 input vectors (!) of information, on which you base your decisions. The inference you mention is a consequence of those inputs. In other words, the “brain” that actually makes the inference, is in our model the autonomic service agent.

Does that make sense?

 

Page 6, last paragraph above section 3.2
"...closed-loop control is an important aspect of self-managing systems.

This implies peer-to-peer dialogues between the parties that make up

the closed loop. Such dialogues require two-way "discussion" or "negotiation"

between each pair or groups of peers involved in the loop,..."
First, by "peer", I assume you mean two (or more) equipotent entities that make some portion of their resources available to others. Second, and more importantly, a closed control loop does not require each entity in the closed control loop to talk to negotiate with other entities. Now, in an autonomic control loop, this could very well be the case, but it is unclear to me why it MUST be the case. The obvious nightmare scenario is that the negotiation fails. Then what - we have no control loop at all?

 

MB: I guess your point is that an autonomic process doesn’t HAVE to have a control loop. I would argue that the typical autonomic function DOES have node-to-node interactions. This is what autonomics is all about. Now, yes, there will be cases where this fails, and where a node also needs to do something sensible in case of complete isolation. But that’s an exception state in my mind.

 

Pages 7-8, Section 3.6
Most autonomic networking systems to date have NOT been built with an intent (or declarative) style interface. FOCALE enables declarative and prescriptive (e.g., ECA policy rules) to be used. Others just use ECA (or an equivalent) paradigm. Hence, I'm wondering why intent is the ONLY paradigm that is mentioned in this RFC that is suitable for autonomic networking? Shouldn't we try and peacefully coexist, just as the nodes are peacefully coexisting with non-autonomic directives?

 

MB: To me, ECA is encoded in an ASA or an autonomic function. The function says what action you take in specific events, and under which condition.

Example: The “enrolment proxy ASA” has the following (hard coded) ESA:

-          Event: A new node is detected

-          Condition: it doesn’t have a domain cert yet

-          Action: I invite the node to join my network.

Now, Intent is in my mind a higher level concept which could now state “do not enrol new nodes at this moment”.

How would you see that?

 

Page 9, section 3.7
"However, in an Autonomic Network, reporting should happen on a network-wide basis."

True, but shouldn't individual nodes and collections of nodes still report? That isn't implied in the wording.

 

MB: Yes, they should. This is “traditional management methods”. In our model, every node does the normal syslog, etc., and aggregated reporting is the new thing that comes with AN.

 

Furthermore, the last paragraph says: "Autonomic network events should concern the Autonomic Network as a whole, not individual systems in isolation." I agree that the goal is to report on the system as a whole, but isn't such a report collected from individual nodes? Just like in your example, the nodes need to be able to see that a problem has already been reported in order to know not to issue the same problem.

 

MB: There are two parallel methods of reporting:

1)      the traditional every-node-to-controller method, where the intelligence is central

2)      a distributed reporting function, where nodes aggregate, process, summarise, correlate, …  information before handing it to the controller. Here the intelligence is distributed.

Both will co-exist. The RFC focuses on the new method (and obviously isn’t clear enough about it…)

 

Pages 12-13, section 5
Why is an Autonomic **User** Agent the interface to a control loop? I can see an external entity wanting to configure and monitor the control loop, but why wouldn't the User Agent talk to the Service Agent to do this? I do note that this figure is under discussion and being revised in the reference model.

 

MB: Yes, that’s confusing wording, and now that you mention it, yes we should have probably looked for a better term. The idea is: The “intelligence” of an autonomic function is in the ASA (middle of figure 1). There are now horizontal feedback loops and northbound feedback loops. For example, there is likely a function in the enrolment process, where a message gets sent to the admin: “Here’s a new node, I don’t think it belongs into our network, I’ve quarantined that node for now; would you like me to 1) accept the node anyway, or 2) mark it as bad?”

 

I agree the term “user agent” is not good. We need to find a better one. Suggestions?

 

Page 13, Figure 1
Where is the Autonomic Node in the Reference Model? I do note that this figure is under discussion and being revised in the reference model. However, even in Figure 2 of the reference model, it is still unclear what the "node" is. But more on that later.

MB: The whole thing is the node. That’s why the figure is called “Reference Model for an Autonomic Node”.

 

Thanks for all your input John! Let’s make sure that all these points get addressed in the reference model.

 

Michael
--

regards,

John




--
regards,
John


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

--

Bien cordialement, Best regards,

 

Laurent Ciavaglia

Secure Cloud Networking

Bell Labs | Alcatel Lucent

 

phone: +33 160 402 636

email: laurent.ciavaglia@alcatel-lucent.com

linkedin: laurentciavaglia

address: Route de Villejust | 91620 Nozay | France

--------------010504020806040806030702-- From nobody Tue Jun 23 20:57:41 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1BB1B326E for ; Tue, 23 Jun 2015 20:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPv7zjY7PnvV for ; Tue, 23 Jun 2015 20:57:33 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::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 C7EF31B3448 for ; Tue, 23 Jun 2015 20:57:32 -0700 (PDT) Received: by wiga1 with SMTP id a1so123420358wig.0 for ; Tue, 23 Jun 2015 20:57:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=SvKrdaDQmJPtfzKnD+8T7oASVhhwga9Cyxs7+k3qW3A=; b=yu9qS2AxEpu3j/YSb1HCbpFB4Rc9U0f+Jofd1ptFvXJ/lbDaVJAF61Nwp7U9jslUeC OHnreQJafDxRcHxV/jVHECsYD/UvSw8AMKI2+XsQD+PA3lZxlbWGuPH2bbeTNUJYgCAZ kYkYBBFA5rc8ZcSY3r9PbtBdhsFYY1JlVD/1Zp7bEL8/uIATLF1RtKQUcByO+BbWQL4B tmuqqz01FxSotHWeqAHdmg9WznbiOO17zfe5A1jFy6YLI9lQf5UAAXY7xQjOjEj6oU78 aJJ+Qkuj3w+PTKmAUT+eWgPOrK5HrG90aNj8oKj6McWc3u3PLkUZFx3kUpSbPyXBzbFp 3/Dw== MIME-Version: 1.0 X-Received: by 10.180.211.109 with SMTP id nb13mr807817wic.8.1435118251570; Tue, 23 Jun 2015 20:57:31 -0700 (PDT) Received: by 10.27.102.6 with HTTP; Tue, 23 Jun 2015 20:57:31 -0700 (PDT) Date: Tue, 23 Jun 2015 20:57:31 -0700 Message-ID: From: John Strassner To: Michael Behringer , John Strassner , Anima WG Content-Type: multipart/alternative; boundary=001a11c3819e987c8305193b81dd Archived-At: Subject: Re: [Anima] Questions on RFC7575 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jun 2015 03:57:40 -0000 --001a11c3819e987c8305193b81dd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Michael, thanks again for replying. I've answered inline ( ). best regards, John *From:* John Strassner [mailto:strazpdj@gmail.com] *[=E2=80=A6]* Questions on RFC7575 Page 3 "Autonomic functions can be defined in two ways: o On a node level: Nodes interact with each other to form feedback loops. o On a system level: Feedback loops include central elements as well." What is a "central element"? Does this mean that the feedback loop includes centralized management mechanisms, or that there is additional logic outside of just the nodes? MB: A central element is a controller for example. The point of the section is: You could define an =E2=80=9Cautonomic network=E2=80=9D where every nod= e has exactly the same interfaces as today (primarily CLI, SNMP, NETCONF), and where a controller is involved in all control loops. Our definition of =E2=80=9Caut= onomic=E2=80=9D is further down in the network, where nodes interact directly with nodes. Now we all understand this isn=E2=80=99t black and white, but the emphasis = of the work in the IETF should be node-to-node interactions. OK, got it. Just to ensure, is it fair to say that a "central element" is one in which non-autonomic functions are used that may affect the behavior of autonomic nodes? MB2: This is correct but not complete. Because also a normal node has non-autonomic functions that may affect the behaviour of that node (or others). True, but I wouldn't think of a "normal node" as a "central element". So perhaps the language needs to be widened? Page 5, definition of intent Why is intent scoped to a single autonomic domain? MB: Intent isn=E2=80=99t a policy language like most other, where you can essentially define a policy for every network element separately. The fundamental idea is that there is one intent for the entire network. Thus this definition. My personal opinion: If we let Intent slip into the element management scope, we=E2=80=99ve missed an opportunity. Intent is a policy on network s= cope. Here you lost me. ODL GBP and ODL NIC, OpenStack Congress, some nascent work in the ONF, and TMF ZOOM would all disagree. Intent, for better or worse, has been characterized as The New Policy (no offense to Light Reading). But then at the end you say "Intent is a policy on network scope", so maybe I'm reading you too literally? (see I haven't changed since my Cisco days :-) ). MB2: I know, lots of groups have by now picked up the =E2=80=9Cintent=E2=80= =9D word, and since we never really defined it in detail, it now means anything to anyone. (I think =E2=80=93 hopefully I=E2=80=99m wrong). We should discuss = this in Prague. No, sadly, you are right. Do you mean =E2=80=9Cintent=E2=80=9D as an= =E2=80=9Cinterface=E2=80=9D or set of =E2=80=9CAPIs=E2=80=9D? This appeals to me, because if there was such an intent =E2=80=9Cbox=E2=80= =9D that allowed declarative programmatic control, then policies could be an input to as well as an output from this box. Plus, do you really mean "for the entire network"? Isn't "for a given set of administrative domains" good enough? MB2: domain is the right term. YAY! J Page 5, definition of autonomic domain Why is autonomic domain tied to intent as the only management paradigm? The vast majority of work in autonomic networking does NOT use intent (what I call declarative logic, I failed marketing :-) ). I completely agree with using intent, and perhaps even emphasizing it, but I don't agree with excluding other management paradigms. MB: Probably a question of wording. In my reading you have 1) autonomic default behaviour (could also call this =E2=80=9Cdefault intent=E2=80=9D), = 2) Intent, and 3) traditional management schemes, such as NETCONF, SNMP, CLI, etc=E2=80=A6 So we don=E2=80=99t exclude other management paradigms, they are handles in= section 3.2. Is that what you mean? (You could also define an autonomic domain by the zone of trust of the certificates.) Yes. Note that in SUPA, we derive intent and traditional (i.e., ECA) from the same Policy info model. This has the nice property of letting intent translate across actors and be used to fire ECA policies (and vice versa). MB2: Need to discuss this in more detail, in Prague ;-) Happy to. I=E2=80=99ve used the Policy Continuum to represent the fa= ct that different actors speak and think about policies that need to cooperate and communicate using different terms, syntax, and semantics. No one policy language will ever address all actors (e.g., business people, product people, application developers, administrators), just like Python or Ruby will never eliminate Java, much less C. In SUPA (and in DEN-ng and in the TMF ZOOM), we have defined a common foundation representing policy concepts; from this we derive two different types of policies (four in DEN-ng and ZOOM): ECA and declarative (i.e., intent). This enables a declarative policy to call ECA policies in the process of translating it to a form that is more amenable for communicating to a management entity or a device. Page 5, self-management "They configure themselves, based on self-knowledge, discovery, and Intent.= " The word "discovery" is confusing me. Suppose a node runs a utility function to decide what its next configuration change should be. It is not "discovering" something that existed - rather, it is computing new knowledge. A machine learning function that infers new knowledge is an even better example of something that is not "discovered". I'm probably missing something, but why was this choice made? The thing that really bothers me is that this assumes that all knowledge can be discovered - that is, it is existing, like an apple on a tree, ready to be plucked. In the autonomic systems that I've built, this is only sometimes the case. It is vital for an autonomic system to be able to learn new knowledge via computation and inference, as well as decide that previous knowledge was incorrect. Neither of these are discovery functions. MB: I think the confusion is the definition of =E2=80=9Cdiscovery=E2=80=9D = here. It=E2=80=99s not only discovery in the sense of service discovery, but for example, finding neighbors, negotiating parameters with them, etc. The above phrase in other words: =E2=80=9CI know my capabilities, I see wha= t else is there (and talk to it potentially), and I see what the boss wants to happen (intent). Based on all of this I decide what I=E2=80=99m going to do= =E2=80=9D. I think it=E2=80=99s a question of wording. We had this graphic (similar to= figure 1), where there are the 3 input vectors (!) of information, on which you base your decisions. The inference you mention is a consequence of those inputs. In other words, the =E2=80=9Cbrain=E2=80=9D that actually makes the= inference, is in our model the autonomic service agent. Does that make sense? I think so. I still think that my two examples are not discovery. I had somehow concluded that discovery was all-inclusive, but when I look at your answer, I realize that it isn't. Still, in the reference document, I think we should point this out. I do agree that discovery is sometimes not explicitly mentioned, which is a shame, since it is such a vital function. It would therefore be OK imho to emphasize discovery as long as we leave some wiggle room for dynamically creating and removing knowledge. MB2: It would help me if you could suggest where in the doc to make those changes. I=E2=80=99d be happy to. Let me finish sections 7.4-7.6, and then I= =E2=80=99ll send a review of the entire document (hopefully by this Friday) Page 6, last paragraph above section 3.2 "...closed-loop control is an important aspect of self-managing systems. This implies peer-to-peer dialogues between the parties that make up the closed loop. Such dialogues require two-way "discussion" or "negotiation" between each pair or groups of peers involved in the loop,..." First, by "peer", I assume you mean two (or more) equipotent entities that make some portion of their resources available to others. Second, and more importantly, a closed control loop does not require each entity in the closed control loop to talk to negotiate with other entities. Now, in an autonomic control loop, this could very well be the case, but it is unclear to me why it MUST be the case. The obvious nightmare scenario is that the negotiation fails. Then what - we have no control loop at all? MB: I guess your point is that an autonomic process doesn=E2=80=99t HAVE to= have a control loop. I would argue that the typical autonomic function DOES have node-to-node interactions. This is what autonomics is all about. Now, yes, there will be cases where this fails, and where a node also needs to do something sensible in case of complete isolation. But that=E2=80=99s an exc= eption state in my mind. No. Let me try again. The text that bothers me is "[closed-loop] implies peer-to-peer dialogues between the parties that make up the close loop". That isn't how traditional control loops are typically built, and I'm personally not familiar with any autonomic system that builds them in this way. Sure, it would be nice to allow this when necessary - FOCALE had this feature through a dedicated control interface that could adapt the function carried out by a control loop element based on (for example) changing context - but I disagree that it is a MANDATORY function. MB2: We need to discuss this as well in Prague. I have the feeling we=E2=80= =99re not talking about the same thing. OK. Feel free to start a thread, or wait till 7.4 is done. I=E2=80= =99ll try and sneak some text in there that better explains what I=E2=80=99m thinking= without making it a long dissertation. J To your second point, I do (of course!) agree that autonomics is about node-to-node interactions. But, it is also about system-wide interactions. My point was that if you mandate negotiation in order to create a control loop, and the negotiation fails, you're in trouble. And yes, that would be an exception state in my mind, as it violates a basic principle in autonomics - consensual behavior. Pages 7-8, Section 3.6 Most autonomic networking systems to date have NOT been built with an intent (or declarative) style interface. FOCALE enables declarative and prescriptive (e.g., ECA policy rules) to be used. Others just use ECA (or an equivalent) paradigm. Hence, I'm wondering why intent is the ONLY paradigm that is mentioned in this RFC that is suitable for autonomic networking? Shouldn't we try and peacefully coexist, just as the nodes are peacefully coexisting with non-autonomic directives? MB: To me, ECA is encoded in an ASA or an autonomic function. The function says what action you take in specific events, and under which condition. Example: The =E2=80=9Cenrolment proxy ASA=E2=80=9D has the following (hard = coded) ESA: - Event: A new node is detected - Condition: it doesn=E2=80=99t have a domain cert yet - Action: I invite the node to join my network. Now, Intent is in my mind a higher level concept which could now state =E2= =80=9Cdo not enrol new nodes at this moment=E2=80=9D. How would you see that? Is the action a typo, and you really meant: "I do not invite the node to join my network"? MB2: No, this is the actual behaviour of a bootstrap proxy. If a node is new and doesn=E2=80=99t have a domain cert yet, you invite it to join the d= omain (controlled by the registrar of course). Anyway, that=E2=80=99s a detail I = think. As stated, I would say that the ECA policy would NOT fire because it violates intent. However, to my earlier point above about intent and ECA policies being able to call each other - ABSOLUTELY. MB2: I think we=E2=80=99re actually on the same page here, and it=E2=80=99= s a question of wording. If you are trying to illustrate a conflict in intent (which by the way most people in other SDOs say does not exist, which I disagree with), then I agree. Otherwise, my turn to ask you for a detailed discussion in Prague. Page 9, section 3.7 "However, in an Autonomic Network, reporting should happen on a network-wide basis." True, but shouldn't individual nodes and collections of nodes still report? That isn't implied in the wording. MB: Yes, they should. This is =E2=80=9Ctraditional management methods=E2=80= =9D. In our model, every node does the normal syslog, etc., and aggregated reporting is the new thing that comes with AN. Got it, thanks. Furthermore, the last paragraph says: "Autonomic network events should concern the Autonomic Network as a whole, not individual systems in isolation." I agree that the goal is to report on the system as a whole, but isn't such a report collected from individual nodes? Just like in your example, the nodes need to be able to see that a problem has already been reported in order to know not to issue the same problem. MB: There are two parallel methods of reporting: 1) the traditional every-node-to-controller method, where the intelligence is central 2) a distributed reporting function, where nodes aggregate, process, summarise, correlate, =E2=80=A6 information before handing it to the contr= oller. Here the intelligence is distributed. Both will co-exist. The RFC focuses on the new method (and obviously isn=E2= =80=99t clear enough about it=E2=80=A6) OK, got it. In FOCALE, we almost NEVER used node-to-controller (well, FOCALE predates SDN controllers, but let's say controller =3D=3D some centralized manager) unless the majority (or more) of nodes failed. We did use an umbrella management paradigm (similar to clusterheads in P2P networks), where the clusterheads did collection, filtering, correlation, and possibly other functions before passing the data (not necessarily up!). I'm happy to focus on the new, just want to ensure we have some fallback position for not just legacy integration, but more importantly, failure modes. MB2: Ack. (I think) J And I start to understand where some of our confusions are coming from. FOCALE does have a different model I think. Needs more discussion. Pages 12-13, section 5 Why is an Autonomic **User** Agent the interface to a control loop? I can see an external entity wanting to configure and monitor the control loop, but why wouldn't the User Agent talk to the Service Agent to do this? I do note that this figure is under discussion and being revised in the reference model. MB: Yes, that=E2=80=99s confusing wording, and now that you mention it, yes= we should have probably looked for a better term. The idea is: The =E2=80=9Cintelligence=E2=80=9D of an autonomic function is in the ASA (midd= le of figure 1). There are now horizontal feedback loops and northbound feedback loops. For example, there is likely a function in the enrolment process, where a message gets sent to the admin: =E2=80=9CHere=E2=80=99s a new node, I don= =E2=80=99t think it belongs into our network, I=E2=80=99ve quarantined that node for now; would= you like me to 1) accept the node anyway, or 2) mark it as bad?=E2=80=9D I agree the term =E2=80=9Cuser agent=E2=80=9D is not good. We need to find = a better one. Suggestions? So does "user agent" mean "(autonomic) management agent"? Probably NOT a user-facing agent, right? In the tradition of Calm Technology, the best and most ubiquitous functions are those that don't demand attention, but rather inform. Mb2: Maybe that=E2=80=99s the right term. Need to think more=E2=80=A6 Page 13, Figure 1 Where is the Autonomic Node in the Reference Model? I do note that this figure is under discussion and being revised in the reference model. However, even in Figure 2 of the reference model, it is still unclear what the "node" is. But more on that later. MB: The whole thing is the node. That=E2=80=99s why the figure is called = =E2=80=9CReference Model for an Autonomic Node=E2=80=9D. But if it is a **node**, then why is it running its own internal feedback loops? Note that "node" implies a single something. Clearly, the single something can contain groups of other somethings, but why would a feedback loop exist in the single something when we are emphasizing inter-node communication and functionality? MB2: Where do you see a feedback loop in the node?!? I don=E2=80=99t! J Figure 1 in RFC7575, Feedback Loops box is within the Node outer line. I think that this figure would be improved by showing interfaces to the Autonomic Control Plane and to the OS; right now, they are inside of the node, and that I don't understand. In FOCALE, as well as other architectures, knowledge did not have to be embedded in the node, it could be received from other places in the network. Hence, I think that showing interfaces to where knowledge is obtained and where it is discovered is more generic. Of course, more capable nodes could contain these functions, but I'm not convinced that this is the norm. Thanks for all your input John! Let=E2=80=99s make sure that all these poin= ts get addressed in the reference model. I hope it helps. I think I can now write my sections in a way that will be more consistent. More feedback coming later. MB2: Thanks for feedback. I think we should single out specific issues, and create a specific mail thread on each, this one is starting to get messy J I was hoping that we had converged, but if something needs more discussion, please don=E2=80=99t hesitate to start a new list. Michael Michael best regards, John --=20 regards, John --001a11c3819e987c8305193b81dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Michael for the response. My purpose was not t= o affect RFC7575, but rather to ensure consistency as we move forward. Plea= se see inline as well.

Questi= ons on RFC7575
Page 3
"Autonomic functions can be defined in t= wo ways:
=C2=A0 o On a node level: Nodes interact with each other to fo= rm feedback
=C2=A0=C2=A0=C2=A0 loops.
=C2=A0 o On a system level: F= eedback loops include central elements as
=C2=A0=C2=A0=C2=A0 well."= ;
What is a "central element"? Does this mean that the feedba= ck loop includes centralized management mechanisms, or that there is additi= onal logic outside of just the nodes?

=C2=A0

MB: A central element is a controller for example. The= point of the section is: You could define an =E2=80=9Cautonomic network=E2= =80=9D where every node has exactly the same interfaces as today (primarily= CLI, SNMP, NETCONF), and where a controller is involved in all control loo= ps. Our definition of =E2=80=9Cautonomic=E2=80=9D is further down in the ne= twork, where nodes interact directly with nodes. Now we all understand this= isn=E2=80=99t black and white, but the emphasis of the work in the IETF sh= ould be node-to-node interactions.

<jcs> OK, got it. Just to ensure, is it fair to s= ay that a "central element" is one in which non-autonomic functio= ns are used that may affect the behavior of autonomic nodes? </jcs>


Page 5, definition of intent
Why is intent scoped to a= single autonomic domain?

=C2=A0

MB: Intent isn=E2=80=99t a = policy language like most other, where you can essentially define a policy = for every network element separately. The fundamental idea is that there is= one intent for the entire network. Thus this definition.

My personal opinion: If we let Intent slip into t= he element management scope, we=E2=80=99ve missed an opportunity. Intent is= a policy on network scope.

<jcs>= ; Here you lost me. ODL GBP and=C2=A0ODL NIC, OpenStack Congress, some nasc= ent work in the ONF, and TMF ZOOM would all disagree. Intent, for better or= worse, has been characterized as The New Policy (no offense to=C2=A0Light= =C2=A0Reading).=C2=A0But then at the end you say "Intent is a policy o= n network scope", so maybe I'm reading you too literally? (see I h= aven't changed since my Cisco days :-) ).


Plus, do you really me= an=C2=A0"for the entire network"? Isn't "for a given set= of administrative domains" good enough?=C2=A0</jcs>

=C2=A0<= /u>

Page 5, definition of = autonomic domain
Why is autonomic domain tied to intent as the only man= agement paradigm? The vast majority of work in autonomic networking does NO= T use intent (what I call declarative logic, I failed marketing :-) ). I co= mpletely agree with using intent, and perhaps even emphasizing it, but I do= n't agree with excluding other management paradigms.

=C2=A0

MB: Probably a question of wording. In my reading you have 1) autonomic= default behaviour (could also call this =E2=80=9Cdefault intent=E2=80=9D)= , 2) Intent, and 3) traditional management schemes, such as NETCONF, SNMP, = CLI, etc=E2=80=A6=C2=A0

So we don=E2=80=99t exclude other management paradigms, they a= re handles in section 3.2. Is that what you mean?

(You could also define an autonomic domain by the zone of= trust of the certificates.)

<jcs&g= t; Yes. Note that in SUPA, we derive intent and traditional (i.e., ECA) fro= m the same Policy info model. This has the nice property of letting intent = translate across actors and be used to fire ECA policies (and vice versa). = </jcs>

=C2=A0

Page 5, self-management
"They configure themselves, based on sel= f-knowledge, discovery, and Intent."
The word "discovery"= ; is confusing me. Suppose a node runs a utility function to decide what it= s next configuration change should be. It is not "discovering" so= mething that existed - rather, it is computing new knowledge. A machine lea= rning function that infers new knowledge is an even better example of somet= hing that is not "discovered". I'm probably missing something= , but why was this choice made?

<= p class=3D"MsoNormal">The thing that really bothers me is that this assumes t= hat all knowledge can be discovered - that is, it is existing, like an appl= e on a tree, ready to be plucked. In the autonomic systems that I've bu= ilt, this is only sometimes the case. It is vital for an autonomic system t= o be able to learn new knowledge via computation and inference, as well as = decide that previous knowledge was incorrect. Neither of these are discover= y functions.

=C2=A0

MB= : I think the confusion is the definition of =E2=80=9Cdiscovery=E2=80=9D he= re. It=E2=80=99s not only discovery in the sense of service discovery, but = for example, finding neighbors, negotiating parameters with them, etc. <= /u>

The above phras= e in other words: =E2=80=9CI know my capabilities, I see what else is there= (and talk to it potentially), and I see what the boss wants to happen (int= ent). Based on all of this I decide what I=E2=80=99m going to do=E2=80=9D. =

I think it= =E2=80=99s a question of wording. We had this graphic (similar to figure 1)= , where there are the 3 input vectors (!) of information, on which you base= your decisions. The inference you mention is a consequence of those inputs= . In other words, the =E2=80=9Cbrain=E2=80=9D that actually makes the infer= ence, is in our model the autonomic service agent.

Does that make s= ense?

<jcs> I think so. I still = think that my two examples are not discovery. I had somehow concluded that = discovery was all-inclusive, but when I look at your answer, I realize that= it isn't. Still, in the reference document, I think we should point th= is out. I do agree that discovery is sometimes not explicitly mentioned, wh= ich is a shame, since it is such a vital function. It would therefore be OK= imho to emphasize discovery as long as we leave some wiggle room for dynam= ically creating and removing knowledge. </jcs>

=C2=A0<= /font>

Page 6, last paragraph above sect= ion 3.2
"...closed-loop control is an important aspect of self-man= aging systems.

This implies peer-to-peer dialogues between the parties that make up

the closed l= oop. Such dialogues require two-way "discussion" or "negotia= tion"

= between each pair or groups of peers involved in the loop,..."
Fir= st, by "peer", I assume you mean two (or more) equipotent entitie= s that make some portion of their resources available to others. Second, an= d more importantly, a closed control loop does not require each entity in t= he closed control loop to talk to negotiate with other entities. Now, in an= autonomic control loop, this could very well be the case, but it is unclea= r to me why it MUST be the case. The obvious nightmare scenario is that the= negotiation fails. Then what - we have no control loop at all?

=C2=A0

MB: I gues= s your point is that an autonomic process doesn=E2=80=99t HAVE to have a co= ntrol loop. I would argue that the typical autonomic function DOES have nod= e-to-node interactions. This is what autonomics is all about. Now, yes, the= re will be cases where this fails, and where a node also needs to do someth= ing sensible in case of complete isolation. But that=E2=80=99s an exception= state in my mind.

<jcs> No. Let= me try again.

The text that bothers = me is "[closed-loop] implies peer-to-peer dialogues between the partie= s that make up the close loop". That isn't how traditional control= loops are typically built, and I'm personally not familiar with any au= tonomic system that builds them in this way. Sure, it would be nice to allo= w this when necessary - FOCALE had this feature through a dedicated control= interface that could adapt the function carried out by a control loop elem= ent based on (for example) changing context - but I disagree that it is a M= ANDATORY function.


=

To your second point, I do (of course!) agree that= autonomics is about node-to-node interactions. But, it is also about syste= m-wide interactions. My point was that if you mandate negotiation in order = to create a control loop, and the negotiation fails, you're in trouble.= And yes, that would be an exception state in my mind, as it violates a bas= ic principle in autonomics - consensual behavior. </jcs>

=C2=A0

Pages 7-8, Section 3.6<= br> Most autonomic networking systems to date have NOT been built with an i= ntent (or declarative) style interface. FOCALE enables declarative and pres= criptive (e.g., ECA policy rules) to be used. Others just use ECA (or an eq= uivalent) paradigm. Hence, I'm wondering why intent is the ONLY paradig= m that is mentioned in this RFC that is suitable for autonomic networking? = Shouldn't we try and peacefully coexist, just as the nodes are peaceful= ly coexisting with non-autonomic directives?

= =C2=A0

MB: To m= e, ECA is encoded in an ASA or an autonomic function. The function says wha= t action you take in specific events, and under which condition. =

Example: The =E2=80= =9Cenrolment proxy ASA=E2=80=9D has the following (hard coded) ESA: =

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Event: A new node is detected

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Condition: it doesn=E2=80=99t have a= domain cert yet

-= =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Action: I invite the node to join my network. <= /u>

Now, Intent is = in my mind a higher level concept which could now state =E2=80=9Cdo not enr= ol new nodes at this moment=E2=80=9D.

<= p class=3D"MsoNormal">

How would you see that?

<jcs&= gt; Is the action a typo, and you really meant: "I do not invite the n= ode to join my network"? As stated, I would say that the ECA policy wo= uld NOT fire because it violates intent. However, to my earlier point above= about intent and ECA policies being able to call each other - ABSOLUTELY. = </jcs>

=C2=A0

Page 9, section 3.7
"However, in an Autonomic Network, reporting= should happen on a network-wide basis."

True, but shouldn't individual nodes = and collections of nodes still report? That isn't implied in the wordin= g.

= =C2=A0

MB: Yes, they should. This is = =E2=80=9Ctraditional management methods=E2=80=9D. In our model, every node = does the normal syslog, etc., and aggregated reporting is the new thing tha= t comes with AN.

<jcs> Got it, t= hanks. </jcs>

=C2=A0

Furthermore, the last paragraph says: "Autonomic network even= ts should concern the Autonomic Network as a whole, not individual systems = in isolation." I agree that the goal is to report on the system as a w= hole, but isn't such a report collected from individual nodes? Just lik= e in your example, the nodes need to be able to see that a problem has alre= ady been reported in order to know not to issue the same problem.=

=C2=A0

MB: There are two parallel methods of reporting:

1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the traditional every-node-= to-controller method, where the intelligence is central

<= span style=3D"color:rgb(31,73,125);font-family:"Calibri","sa= ns-serif";font-size:11pt">2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a distributed reporting function, = where nodes aggregate, process, summarise, correlate, =E2=80=A6 =C2=A0info= rmation before handing it to the controller. Here the intelligence is distr= ibuted.

Both will co-exist. The = RFC focuses on the new method (and obviously isn=E2=80=99t clear enough abo= ut it=E2=80=A6)

<jcs> OK, got it= . In FOCALE, we almost NEVER used node-to-controller (well, FOCALE predates= SDN controllers, but let's say controller =3D=3D some centralized mana= ger) unless the majority (or more) of nodes failed. We did use an umbrella = management paradigm (similar to clusterheads in P2P networks), where the cl= usterheads did collection, filtering, correlation, and possibly other funct= ions before passing the data (not necessarily up!). I'm happy to focus = on the new, just want to ensure we have some fallback position for not just= legacy integration, but more importantly, failure modes. </jcs>

=C2= =A0

Pages 12-13, se= ction 5
Why is an Autonomic **User** Agent the interface to a control l= oop? I can see an external entity wanting to configure and monitor the cont= rol loop, but why wouldn't the User Agent talk to the Service Agent to = do this? I do note that this figure is under discussion and being revised i= n the reference model.

= =C2=A0

MB: Yes, that=E2=80=99s conf= using wording, and now that you mention it, yes we should have probably loo= ked for a better term. The idea is: The =E2=80=9Cintelligence=E2=80=9D of a= n autonomic function is in the ASA (middle of figure 1). There are now hori= zontal feedback loops and northbound feedback loops. For example, there is = likely a function in the enrolment process, where a message gets sent to th= e admin: =E2=80=9CHere=E2=80=99s a new node, I don=E2=80=99t think it belon= gs into our network, I=E2=80=99ve quarantined that node for now; would you = like me to 1) accept the node anyway, or 2) mark it as bad?=E2=80=9D=

=C2=A0

I agree the term =E2=80=9Cuser agent=E2=80= =9D is not good. We need to find a better one. Suggestions?

<jcs> So does "user agent" mean "= ;(autonomic) management agent"? Probably NOT a user-facing agent, righ= t? In the tradition of Calm Technology, the best and most ubiquitous functi= ons are those that don't demand attention, but rather inform. </jcs&= gt;

=C2=A0

Page 13= , Figure 1
Where is the Autonomic Node in the Reference Model? I do not= e that this figure is under discussion and being revised in the reference m= odel. However, even in Figure 2 of the reference model, it is still unclear= what the "node" is. But more on that later.

MB: The whole= thing is the node. That=E2=80=99s why the figure is called =E2=80=9CRefere= nce Model for an Autonomic Node=E2=80=9D.

<= p class=3D"MsoNormal"><jcs> But if it is a **node**, then why is it running its own i= nternal feedback loops? Note that "node" implies a single somethi= ng. Clearly, the single something can contain groups of other somethings, b= ut why would a feedback loop exist in the single something when we are emph= asizing inter-node communication and functionality?


<= font face=3D"Times New Roman" size=3D"3">I think that this= figure would be improved by showing interfaces to the Autonomic Control Pl= ane and to the OS; right now, they are inside of the node, and that I don&#= 39;t understand. In FOCALE, as well as other architectures, knowledge did n= ot have to be embedded in the node, it could be received from other places = in the network. Hence, I think that showing interfaces to where knowledge i= s obtained and where it is discovered is more generic. Of course, more capa= ble nodes could contain these functions, but I'm not convinced that thi= s is the norm. </jcs>

=C2=A0

Thanks f= or all your input John! Let=E2=80=99s make sure that all these points get a= ddressed in the reference model.

<= font color=3D"#1f497d" face=3D"Times New Roman" size=3D"3"><jcs> I hope it helps. I think I = can now write my sections in a way that will be more consistent. More feedb= ack coming later. </jcs>

=C2=A0

Michael


best regards,
John

Hi Michael,

thanks again for replying. I'= ve answered inline (<jcs2/> )= .

best regards,
John

=C2=A0

From:strazpdj@gmail.com]
[=E2=80=A6]

Questions on RFC7575
Page 3
"Autonomic functions can be defined in two ways:
=C2=A0 o On a node level: Nodes interact with each other to form feedback =C2=A0=C2=A0=C2=A0 loops.
=C2=A0 o On a system level: Feedback loops include central elements as
=C2=A0=C2=A0=C2=A0 well."
What is a "central element"? Does this mean that the feedback loo= p includes centralized management mechanisms, or that there is additional log= ic outside of just the nodes?

=C2=A0

MB: A central element is a controller for example. The point of the section is: You could define an =E2=80=9Cautonomic network=E2=80=9D where every node has exactly the same i= nterfaces as today (primarily CLI, SNMP, NETCONF), and where a controller is involved in all control loops. Our definition of =E2=80=9Cautonomic=E2=80=9D is further dow= n in the network, where nodes interact directly with nodes. Now we all understand this isn=E2= =80=99t black and white, but the emphasis of the work in the IETF should be node-to-node interactions.

<jcs> OK, got it. Just to= ensure, is it fair to say that a "central element" is one in which non-autonomic functions are use= d that may affect the behavior of autonomic nodes? </jcs>

MB2: This is correct but not c= omplete. Because also a normal node has non-autonomic functions that may affect the behaviour of that node= (or others).

<jcs2> True, but I wouldn't thi= nk of a "normal node" as a "central element". So perhaps the language needs to be widen= ed? </jcs2>

=C2=A0

Page 5, definition of intent Why is intent scoped to a single autonomic domain?

=C2=A0

MB: Intent isn=E2=80=99t a policy language like most other, where you can essentially define a policy for eve= ry network element separately. The fundamental idea is that there is one inten= t for the entire network. Thus this definition.

My personal opinion: If we let= Intent slip into the element management scope, we=E2=80=99ve missed an opportunity. Intent is a policy o= n network scope.

<jcs> Here you lost me. = ODL GBP and=C2=A0ODL NIC, OpenStack Congress, some nascent work in the ONF, and TMF ZOOM would all disagree. Intent, for better or worse, has been characterized as The New Po= licy (no offense to=C2=A0Light=C2=A0Reading).=C2=A0But then at the end you say "Intent is a policy on network scope", so maybe I'm reading y= ou too literally? (see I haven't changed since my Cisco days :-) ).

MB2: I know, lots of groups ha= ve by now picked up the =E2=80=9Cintent=E2=80=9D word, and since we never really defined it in detail, it now means anything= to anyone. (I think =E2=80=93 hopefully I=E2=80=99m wrong). We should discuss = this in Prague.

<jcs2> No, sadly, you are right. Do= you mean =E2=80=9Cintent=E2=80=9D as an =E2=80=9Cinterface=E2=80=9D or set of =E2=80=9CAPIs=E2=80=9D?

This appeals to me, because if there was = such an intent =E2=80=9Cbox=E2=80=9D that allowed declarative programmatic control, then policies could be an input t= o as well as an output from this box. </jcs2>

=C2=A0

Plus, do you really mean=C2=A0= "for the entire network"? Isn't "for a given set of administrative domains&qu= ot; good enough?=C2=A0</jcs>

=C2=A0MB2: domain is the right term.

<jcs2> YAY! J </jcs2>

=C2=A0

Page 5, definition of autonomic= domain
Why is autonomic domain tied to intent as the only management paradigm? The vast majority of work in autonomic networking does NOT use intent (what I c= all declarative logic, I failed marketing :-) ). I completely agree with using intent, and perhaps even emphasizing it, but I don't agree with excludi= ng other management paradigms.

=C2=A0

MB: Probably a question of wording. In my reading you have 1) autonomic default behaviour (could al= so call this =E2=80=9Cdefault intent=E2=80=9D), 2) Intent, and 3) traditional = management schemes, such as NETCONF, SNMP, CLI, etc=E2=80=A6=C2=A0

So we don=E2=80=99t exclude other management paradigms, they are handles in section 3.2. Is that what you mea= n?

(You could also define an auto= nomic domain by the zone of trust of the certificates.)

<jcs> Yes. Note that in = SUPA, we derive intent and traditional (i.e., ECA) from the same Policy info model. This has the nice property of letting intent translate across actors and be used to fire ECA policies (and vice versa). </jcs>

=C2=A0MB2: Need to discuss this in more detail, in Prague ;-)

<jcs2> Happy to. I=E2=80=99ve used = the Policy Continuum to represent the fact that different actors speak and think about policies that need to cooperate and communicate using different terms, syntax, and semantics. No = one policy language will ever address all actors (e.g., business people, produc= t people, application developers, administrators), just like Python or Ruby w= ill never eliminate Java, much less C. In SUPA (and in DEN-ng and in the TMF ZO= OM), we have defined a common foundation representing policy concepts; from this= we derive two different types of policies (four in DEN-ng and ZOOM): ECA and declarative (i.e., intent). This enables a declarative policy to call ECA policies in the process of translating it to a form that is more amenable f= or communicating to a management entity or a device. </jcs2>

<= font color=3D"#000000" face=3D"Times New Roman" size=3D"3">

=C2=A0

Page 5, self-management
"They configure themselves, based on self-knowledge, discovery, and Intent."
The word "discovery" is confusing me. Suppose a node runs a utili= ty function to decide what its next configuration change should be. It is not "discovering" something that existed - rather, it is computing ne= w knowledge. A machine learning function that infers new knowledge is an even better example of something that is not "discovered". I'm pro= bably missing something, but why was this choice made?

The thing that really bothers m= e is that this assumes that all knowledge can be discovered - that is, it is existing, like an apple on a t= ree, ready to be plucked. In the autonomic systems that I've built, this is = only sometimes the case. It is vital for an autonomic system to be able to learn= new knowledge via computation and inference, as well as decide that previous knowledge was incorrect. Neither of these are discovery functions.

=C2=A0

MB: I think the confusion is the definition of =E2=80=9Cdiscovery=E2=80=9D here. It=E2=80=99s not onl= y discovery in the sense of service discovery, but for example, finding neighbors, negotiating paramete= rs with them, etc.

The above phrase in other words: =E2=80=9CI know my capabilities, I see what else is there (and talk = to it potentially), and I see what the boss wants to happen (intent). Based on al= l of this I decide what I=E2=80=99m going to do=E2=80=9D.

I think it=E2=80=99s a question of wording. We had this graphic (similar to figure 1), where there are the = 3 input vectors (!) of information, on which you base your decisions. The inference you mention is a consequence of those inputs. In other words, the =E2=80=9Cbrain=E2=80=9D that actually makes the inference, is in our model = the autonomic service agent.

Does that make sense? <= /p>

<jcs> I think so. I stil= l think that my two examples are not discovery. I had somehow concluded that discovery was all-inclusive, bu= t when I look at your answer, I realize that it isn't. Still, in the refe= rence document, I think we should point this out. I do agree that discovery is sometimes not explicitly mentioned, which is a shame, since it is such a vi= tal function. It would therefore be OK imho to emphasize discovery as long as w= e leave some wiggle room for dynamically creating and removing knowledge. </jcs>

MB2: It would help me if you could suggest where in the doc to make those changes. =C2=A0

<jcs2> I=E2=80=99d be happy to. Let= me finish sections 7.4-7.6, and then I=E2=80=99ll send a review of the entire document (hopefully by this F= riday) </jcs2>

=C2=A0

Page 6, last paragraph above se= ction 3.2
"...closed-loop control is an important aspect of self-managing system= s.

This implies peer-to-peer dialo= gues between the parties that make up

the closed loop. Such dialogues= require two-way "discussion" or "negotiation"

between each pair or groups of = peers involved in the loop,..."
First, by "peer", I assume you mean two (or more) equipotent enti= ties that make some portion of their resources available to others. Second, and = more importantly, a closed control loop does not require each entity in the clos= ed control loop to talk to negotiate with other entities. Now, in an autonomic control loop, this could very well be the case, but it is unclear to me why= it MUST be the case. The obvious nightmare scenario is that the negotiation fa= ils. Then what - we have no control loop at all?

=C2=A0

MB: I guess your point is that= an autonomic process doesn=E2=80=99t HAVE to have a control loop. I would argue that the typical autonomic function D= OES have node-to-node interactions. This is what autonomics is all about. Now, = yes, there will be cases where this fails, and where a node also needs to do something sensible in case of complete isolation. But that=E2=80=99s an exc= eption state in my mind.

<jcs> No. Let me try aga= in.

The text that bothers me is &q= uot;[closed-loop] implies peer-to-peer dialogues between the parties that make up the close loop"= ;. That isn't how traditional control loops are typically built, and I'= ;m personally not familiar with any autonomic system that builds them in this = way. Sure, it would be nice to allow this when necessary - FOCALE had this featu= re through a dedicated control interface that could adapt the function carried= out by a control loop element based on (for example) changing context - but I disagree that it is a MANDATORY function.

MB2: We need to discuss this a= s well in Prague. I have the feeling we=E2=80=99re not talking about the same thing.

<jcs2> OK. Feel free to start a thr= ead, or wait till 7.4 is done. I=E2=80=99ll try and sneak some text in there that better explains wh= at I=E2=80=99m thinking without making it a long dissertation. J </jcs2>

=C2=A0

To your second point, I do (of= course!) agree that autonomics is about node-to-node interactions. But, it is also about system-wide interactions. My point was that if you mandate negotiation in order to crea= te a control loop, and the negotiation fails, you're in trouble. And yes, th= at would be an exception state in my mind, as it violates a basic principle in autonomics - consensual behavior. </jcs>

=C2=A0

Pages 7-8, Section 3.6
Most autonomic networking systems to date have NOT been built with an inten= t (or declarative) style interface. FOCALE enables declarative and prescripti= ve (e.g., ECA policy rules) to be used. Others just use ECA (or an equivalent) paradigm. Hence, I'm wondering why intent is the ONLY paradigm that is mentioned in this RFC that is suitable for autonomic networking? Shouldn= 9;t we try and peacefully coexist, just as the nodes are peacefully coexisting wit= h non-autonomic directives?

=C2=A0

MB: To me, ECA is encoded in an ASA or an autonomic function. The function says what action you take = in specific events, and under which condition.

Example: The =E2=80=9Cenrolment proxy ASA=E2=80=9D has the following (hard coded) ESA:

-=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Event: A new node is detected

-=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Condition: it doesn=E2=80=99t have a domain cert yet

-=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Action: I invite the node to join my network.

Now, Intent is in my mind a higher level concept which could now state =E2=80=9Cdo not enrol new node= s at this moment=E2=80=9D.

How would you see that?

<jcs> Is the action a ty= po, and you really meant: "I do not invite the node to join my network"?

MB2: No, this is the actual behaviour of a bootstrap proxy. If a node is new and doesn=E2=80=99t= have a domain cert yet, you invite it to join the domain (controlled by the regist= rar of course). Anyway, that=E2=80=99s a detail I think.

As stated, I would say that th= e ECA policy would NOT fire because it violates intent. However, to my earlier point above about intent= and ECA policies being able to call each other - ABSOLUTELY. </jcs>

=C2=A0MB2: I think we=E2=80=99re actually on the same page here, and it=E2=80=99s a question of wording.

<jcs2> If you are trying to illustr= ate a conflict in intent (which by the way most people in other SDOs say does not exist, which I disagree with), then I agree. Otherwise, my turn to ask you for a detailed discussion in Prague. </jcs2>

=C2=A0

Page 9, section 3.7
"However, in an Autonomic Network, reporting should happen on a network-wide basis."

True, but shouldn't individ= ual nodes and collections of nodes still report? That isn't implied in the wording.

=C2=A0

MB: Yes, they should. This is = =E2=80=9Ctraditional management methods=E2=80=9D. In our model, every node does the normal syslog, etc., and aggregated repor= ting is the new thing that comes with AN.

<jcs> Got it, thanks. &l= t;/jcs>

=C2=A0

Furthermore, the last paragraph= says: "Autonomic network events should concern the Autonomic Network as a whole, not individual syst= ems in isolation." I agree that the goal is to report on the system as a whole, but isn't such a report collected from individual nodes? Just li= ke in your example, the nodes need to be able to see that a problem has already b= een reported in order to know not to issue the same problem.

=C2=A0

MB: There are two parallel methods of reporting:

1)=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 the traditional every-node-to-controller method, where the intelligence is cent= ral

2)=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 a distributed reporting function, where nodes aggregate, process, summarise, correlate, =E2=80=A6 =C2=A0information before handing it to the controller.= Here the intelligence is distributed.

Both will co-exist. The RFC fo= cuses on the new method (and obviously isn=E2=80=99t clear enough about it=E2=80=A6)

<jcs> OK, got it. In FOC= ALE, we almost NEVER used node-to-controller (well, FOCALE predates SDN controllers, but let's sa= y controller =3D=3D some centralized manager) unless the majority (or more) o= f nodes failed. We did use an umbrella management paradigm (similar to clusterheads= in P2P networks), where the clusterheads did collection, filtering, correlatio= n, and possibly other functions before passing the data (not necessarily up!).= I'm happy to focus on the new, just want to ensure we have some fallback positi= on for not just legacy integration, but more importantly, failure modes. </jcs>

=C2=A0MB2: Ack. (I think) J =C2=A0=C2=A0And I start to understand where some= of our confusions are coming from. FOCALE does have a different model I think. Nee= ds more discussion.

=C2=A0

Pages 12-13, section 5
Why is an Autonomic **User** Agent the interface to a control loop? I can s= ee an external entity wanting to configure and monitor the control loop, but w= hy wouldn't the User Agent talk to the Service Agent to do this? I do note= that this figure is under discussion and being revised in the reference model.

=C2=A0

MB: Yes, that=E2=80=99s confusing wording, and now that you mention it, yes we should have probably looked fo= r a better term. The idea is: The =E2=80=9Cintelligence=E2=80=9D of an autonomi= c function is in the ASA (middle of figure 1). There are now horizontal feedback loops and northbound feedback loops. For example, there is likely a function in the enrolment process, where a message gets sent to the admin: =E2=80=9CHere=E2= =80=99s a new node, I don=E2=80=99t think it belongs into our network, I=E2=80=99ve quarantined= that node for now; would you like me to 1) accept the node anyway, or 2) mark it as bad?=E2=80= =9D

=C2=A0

I agree the term =E2=80=9Cuser= agent=E2=80=9D is not good. We need to find a better one. Suggestions?

<jcs> So does "user= agent" mean "(autonomic) management agent"? Probably NOT a user-facing agent, right? In the tradition of Calm Technology, the best and most ubiquitous functions are th= ose that don't demand attention, but rather inform. </jcs>

=

=C2=A0Mb2: Maybe that=E2=80=99s the right term. Need to think more=E2=80=A6

=C2=A0

Page 13, Figure 1
Where is the Autonomic Node in the Reference Model? I do note that this fig= ure is under discussion and being revised in the reference model. However, even= in Figure 2 of the reference model, it is still unclear what the "node&qu= ot; is. But more on that later.

MB: The whole thing is the node. That=E2=80=99s why the figure is called =E2=80=9CReference Model = for an Autonomic Node=E2=80=9D.

<jcs> But if it is a **n= ode**, then why is it running its own internal feedback loops? Note that "node" implies a single something. Clearly, the single something can contain groups of other somethings, but why would a feedback loop exist in the single something whe= n we are emphasizing inter-node communication and functionality?

MB2: Where do you see a feedba= ck loop in the node?!? I don=E2=80=99t!=C2=A0 J

<jcs2> Figure 1 in RFC7575, Feedbac= k Loops box is within the Node outer line. </jcs2>

=C2=A0

I think that this figure would= be improved by showing interfaces to the Autonomic Control Plane and to the OS; right now, they are inside of= the node, and that I don't understand. In FOCALE, as well as other architec= tures, knowledge did not have to be embedded in the node, it could be received fro= m other places in the network. Hence, I think that showing interfaces to wher= e knowledge is obtained and where it is discovered is more generic. Of course= , more capable nodes could contain these functions, but I'm not convinced= that this is the norm. </jcs>

=C2=A0

Thanks for all your input John= ! Let=E2=80=99s make sure that all these points get addressed in the reference model.

<jcs> I hope it helps. I= think I can now write my sections in a way that will be more consistent. More feedback coming later. </jcs= >

=C2=A0MB2: Thanks for feedback= . I think we should single out specific issues, and create a specific mail thread on each, this one is starting to get messy J

<jcs2> I was hoping that we had con= verged, but if something needs more discussion, please don=E2=80=99t hesitate to start a new list. &= lt;/jcs2>

=C2=A0

Michael

=C2=A0

Michael

=C2=A0

best regards,

John

--

regards,

Joh= n

--001a11c3819e987c8305193b81dd-- From nobody Tue Jun 23 21:37:48 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C721A87AC for ; Tue, 23 Jun 2015 21:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESYnLc4NGHLQ for ; Tue, 23 Jun 2015 21:37:42 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::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 9CA171A1EF4 for ; Tue, 23 Jun 2015 21:37:41 -0700 (PDT) Received: by wguu7 with SMTP id u7so25619095wgu.3 for ; Tue, 23 Jun 2015 21:37:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lTorxizMTM94wdBrAp/morRUPokik/uRK5cFugKObho=; b=Z+B9G6bBmZshy68TYdw5lRval2H7wtm/AW668iVx2F5h2Pagmj7P3j4AXFfH8Q1Lo4 UfVtH0mqYoZfLoW5aI1LNW/tHJ2jSx2qJRvAjbOXKSWN+Y/TEktafqk5ogCneEVHbWcT 7HDu6aCr8MJizPnGoxwVA8twSynT++50O3S1xlEqbOXewTwCldjgi1XjhrCIS7Ys2Zw2 LNjhVCuCrYjQgNGC6yb+8l1hdlhiyzmz9B8yWPxw9Zt86ezJUqkOUPr/2DPTP3sxkbm4 ZjQba3MAH+XPc5wkpWTUNcrWy3YJDutifA14q9l3kD/UkV0y1EYoYcMroecxqBA1oqhx UcaQ== MIME-Version: 1.0 X-Received: by 10.194.173.8 with SMTP id bg8mr64760062wjc.65.1435120660164; Tue, 23 Jun 2015 21:37:40 -0700 (PDT) Received: by 10.27.102.6 with HTTP; Tue, 23 Jun 2015 21:37:40 -0700 (PDT) In-Reply-To: <5580DB1D.9010009@gmail.com> References: <557DE4C8.4050507@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FE5DF6@xmb-rcd-x14.cisco.com> <557F35A6.4020700@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FED6A8@xmb-rcd-x14.cisco.com> <5580DB1D.9010009@gmail.com> Date: Tue, 23 Jun 2015 21:37:40 -0700 Message-ID: From: John Strassner To: Brian E Carpenter Content-Type: multipart/alternative; boundary=089e013c678228b4d205193c1156 Archived-At: Cc: Anima WG , "Michael Behringer \(mbehring\)" Subject: Re: [Anima] Domains X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jun 2015 04:37:46 -0000 --089e013c678228b4d205193c1156 Content-Type: text/plain; charset=UTF-8 Hi Brian and Michael, I have three quick comments. >In fact the definition in RFC 1136 is amazingly good still: > > Administrative Domain (AD) > "A collection of End Systems, Intermediate Systems, and > subnetworks operated by a single organization or administrative > authority. The components which make up the domain are assumed > to interoperate with a significant degree of mutual trust among > themselves, but interoperate with other Administrative Domains > in a mutually suspicious manner" [1]. > ... This is a good start, but imho it is missing a key ingredient: policy. (Note: if intent means "declarative interface" and not "declarative policy", as I hypothesized in my last email, then it is missing that as well). Alternatively, we could do what I did in DEN-ng: define the concept of a Domain, subclass to AdministrativeDomain, and subclass this to get a PolicyDomain. This has the advantage of not altering the semantics of RFC1136, but rather refining them to include policy-based management. This also helps with federating domains. > Trust is harder, in fact, "trust" is maybe the wrong term. This is really all about authentication and authorization, and maybe we should use those terms for clarity. Agreed! Trust comes after authentication and authorization. More specifically, third-party trust defines a third party that vouches for the trustworthiness of other parties that want to trust each other, but have no formal relationship to establish that trust. I guess we could also work in the concept of direct trust (i.e., when entities from separate domains that do not have cross-certified exchange keying information are required to trust each other) as well. >Well, there's a sequence: I claim an identity, you authenticate that >identity, then you check the authorized capabilities for that identity, and then >you trust me (but only for those specific capabilities). Nicely stated. For me, autonomic nodes advertise capabilities and needs; both could possibly have constraints. Capabilities define what functions the node can do (or help do, if it can't complete the function); needs are what the node needs help in doing. This enables nodes to work together, sharing their functionality, to accomplish mutually beneficial goals (and/or beneficial for the community). regards, John On Tue, Jun 16, 2015 at 7:27 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 16/06/2015 20:39, Michael Behringer (mbehring) wrote: > > Brian, > > > > Yes, that needs to be made more clear. > > > > To me: > > - Administrative domain: All nodes under one administrative control, ex: > "example.domain.com". Surely, that has been defined before somewhere and > we can leverage that definition? The BGP autonomous system comes to mind. > That should be easy. > > When is anything ever easy?... > > In fact the definition in RFC 1136 is amazingly good still: > > Administrative Domain (AD) > > "A collection of End Systems, Intermediate Systems, and > subnetworks operated by a single organization or administrative > authority. The components which make up the domain are assumed > to interoperate with a significant degree of mutual trust among > themselves, but interoperate with other Administrative Domains > in a mutually suspicious manner" [1]. > > and it's actually a quotation from ISO/TR 9575, 1989 :-). > > > Trust is harder, in fact, "trust" is maybe the wrong term. This is > really all about authentication and authorization, and maybe we should use > those terms for clarity. > > Well, there's a sequence: I claim an identity, you authenticate that > identity, then you check the authorized capabilities for that identity, > and then > you trust me (but only for those specific capabilities). > > At an abstract level this is all old news, I guess. It just gets > complicated > when authorization and capabilities cross domain boundaries. (I actually > worked on that a bit for grid computing a decade ago; I don't really think > it's relevant but we did publish something, which IBM has charmingly stuck > behind a paywall: http://dx.doi.org/10.1147/sj.434.0689 .) > > Brian > > > Authentication: an AN node can authenticate all other nodes under the > same PKI root. That includes sub-domains for example. But, if I have the > root CA cert of another domain, and have decided (policy decision!) to > trust that, I can also authenticate other domains. This is all just about > knowing who I talk to, nothing more. This is the simple part. > > > > Now, once I know who I talk to, there are different implications, and > those will be partly policy driven, partly defaults. > > > > Key question is: Authorized to do what? A node can authorize another > node to: > > - join the ACP > > - negotiate parameters for protocol X. > > - receive intent from. > > - ... > > > > We need to define a reasonable default authorization scheme, and, going > by discussions I've had with operators so far, I think we will need to > allow for customization via Intent. > > > > Example: There is example.com and subdomain.example.com. Should the ACP > establish across both? I have heard both customer requirements: 1) Yes, I > want one big ACP to manage everything in a flat management hierarchy > > 2) No, I want the ACP for example.com separate from the ACP for > subdomain.example.com. > > > > Work to be done here... We need to define a good default behaviour, with > the hope that there will be minimal exceptions required... > > > > Michael > > > >> -----Original Message----- > >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > >> Sent: 15 June 2015 22:29 > >> To: Michael Behringer (mbehring); Anima WG > >> Subject: Re: [Anima] Domains > >> > >> Michael (and I've also read Laurent's and Toerless's messages), > >> > >> On 16/06/2015 00:54, Michael Behringer (mbehring) wrote: > >>> Brain, > >>> > >>> Yes, this is a recurring question, and needs to be better explained. > The > >> same question came up in Homenet a couple of years back, and this is > how I > >> answered it: In short, every autonomic entity has A SINGLE owner, and > thus > >> a single domain. > >> > >> We do need to be sure first what a "domain" is. An administrative > boundary > >> is not necessarily the same as a trust boundary. I can well imagine an > entity > >> that is in a given admin domain being trusted both in that domain and in > >> another domain. > >> In that sense, trust domains might overlap when admin domains cannot > >> overlap. > >> > >> Also I'm pretty sure that domains can contain domains, both in the admin > >> view and in the trust view. But the nesting might not be the same. > >> > >> Please note, I don't have a fixed opinion here, I just want clarity in > our > >> model and terminology. > >> > >> Brian > >> > >>> > >>> Let's first define what we're talking about: I specifically state > "autonomic > >> entity" above. I.e., something that can negotiate on its own. That's > what > >> we're concerned with here. Specifically, a queue in a router is NOT an > >> autonomic entity. Therefore, even if several different domains use it, > this > >> has to be managed by the autonomic entity (the router), which negotiates > >> bits and pieces for different domains. But the negotiator is the > router, an > >> autonomic entity, and that one has only one domain. > >>> > >>> 1. I claim for every autonomic entity out there, there is one single > >> administrative "owner". The one who has root access, enable, short, the > full > >> admin rights. > >>> > >>> Example: Take the homenet CPE. There is a managed services model, > >> where the SP maintains the CPE, there is the case where the homenet > >> owner is controlling the CPE. Inside the home network, there may be a > >> device that is owned by a utility, which maybe uses your network to > >> communicate with sensors, or uses your Internet connection to call home. > >> You may have some influence on the device settings, but the utility is > the > >> administrative owner. > >>> > >>> 2. The owner of the autonomic entity can grant some rights to other > >> people. > >>> > >>> In your bandwidth broker example, there is still ONE autonomic entity > >> who has full admin rights over a device (with all its queues, etc). > This entity > >> grants rights to another domain to use a certain amount of buffering, > >> whatever, on the device. A special case of that: > >>> > >>> 3. A device, owned by domain A, can run a container / VM / other > >> virtualization concept that belongs to domain B. > >>> > >>> Then you get to a case where there is the base hardware which is owned > >> by one domain, and say VMs running on top belonging to another domain. > >> That is supported, and we should have clear boundaries in this case. > >>> > >>> 4. Domain A can grant rights to for example a VM of domain B. > >>> > >>> Example, on my home CPE, I run a container that belongs to the > utility; i > >> give that access to my Internet connection, possibly to a specific SSID, > >> whatever. > >>> > >>> Clean separation, clean authorization of rights. > >>> > >>> Looking at your pictures, I think all three show a "resource" as *not* > being > >> an autonomic entity, but as a sub-part of an autonomic entity, example > was > >> the link between two domains. This is where the confusion is coming > from. > >> If we agree that we're talking about the domain of an *autonomic > entity*, > >> then the picture is different, and hopefully clearer. Then it's up to > the > >> autonomic entities (and possibly domains) that share a non-autonomic > >> entity to negotiate its usage. > >>> > >>> Does that make sense? > >>> Michael > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E > >>>> Carpenter > >>>> Sent: 14 June 2015 22:32 > >>>> To: Anima WG > >>>> Subject: [Anima] Domains > >>>> > >>>> Hi, > >>>> > >>>> I want to raise a point about the reference model that the authors of > >>>> draft- behringer-anima-reference-model didn't settle before version > >>>> -02 came out a few days ago. There's placeholder text in the draft > >>>> about Sub-Domains and Cross-Domain Functionality. I suggested that we > >>>> should also list "Overlapping Domains" as a topic. In other words, > >>>> regions of a network could be considered to be in two different > >>>> domains simultaneously. The question is whether we want our model to > >>>> include that possibility? It certainly has implications for security. > >>>> > >>>> An example would be some sort of resource that needed to be shared > >>>> between two otherwise separate domains; that resource could be > >>>> considered to be in both domains. > >>>> > >>>> So I can see three possible models, shown in the folowing ASCII art: > >>>> > >>>> ------------------------------------------- > >>>> | Shared Resource | > >>>> | | > >>>> | ------------------ ------------------ | > >>>> | | Subddomain1 | | Subddomain2 | | > >>>> | | | | | | > >>>> | | | | | | > >>>> | ------------------ ------------------ | > >>>> | | > >>>> ------------------------------------------- > >>>> > >>>> 1. Shared resource in outer domain > >>>> > >>>> ------------------ ------------------ > >>>> | Domain1 | | Domain2 | > >>>> | | | | > >>>> | Shared | | | > >>>> | Resource<|xxx|> | > >>>> ------------------ ------------------ > >>>> > >>>> 2. Shared resource in one domain, with cross-domain access > >>>> > >>>> ---------------------- > >>>> | Domain1 ------|------------------ > >>>> | | Shared Domain2 | > >>>> | |Resource | > >>>> | | | | > >>>> ---------------|------ | > >>>> ------------------------- > >>>> > >>>> 3. Shared resource in domain overlap > >>>> > >>>> Regards > >>>> Brian > >>>> > >>>> _______________________________________________ > >>>> 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 > -- regards, John --089e013c678228b4d205193c1156 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Brian and Michael,

I have= three quick comments.

>In fact the definition = in RFC 1136 is amazingly good still:
>
>=C2=A0=C2=A0=C2=A0Admin= istrative Domain (AD)

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0"A collection of End Systems, Intermediate Systems, and
>= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0subnetworks operated by a single organiza= tion or administrative
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0authority.= =C2=A0 The components which make up the domain are assumed
= >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to interoperate with a significant d= egree of mutual trust among
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0thems= elves, but interoperate with other Administrative Domains
= >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in a mutually suspicious manner"= [1].
> ...

This is a good start, but imho i= t is missing a key ingredient: policy. (Note: if intent means "declara= tive interface" and not "declarative policy", as I hypothesi= zed in my last email, then it is missing that as well).

Alternatively, we could do what I did in DEN-ng: define the concept o= f a Domain, subclass to AdministrativeDomain, and subclass this to get a Po= licyDomain. This has the advantage of not altering the semantics of RFC1136= , but rather refining them to include policy-based management. This also he= lps with federating domains.

> Trust is harder, in fact, &= quot;trust" is maybe the wrong term. This is really all about authenti= cation and authorization, and maybe we should use those terms for clarity.<= /div>

Agreed! Trust=C2=A0comes after authentication and = authorization. More specifically, third-party trust defines a third party t= hat vouches for the trustworthiness of=C2=A0other parties that want to trus= t each other, but have no formal relationship to establish that trust. I gu= ess we could also work in the concept of direct trust (i.e., when entities = from separate domains that do not have cross-certified exchange keying info= rmation are required to trust each other) as well.

=C2=A0>Well, t= here's a sequence: I claim an identity, you authenticate that
=C2=A0= >identity, then you check the authorized capabilities for that identity,= and then
>you trust me (but only for those specific capabilities).<= /div>

Nicely stated.=C2=A0For me, autonomic nodes advert= ise capabilities and needs; both could possibly have constraints. Capabilit= ies define what=C2=A0functions the node can do (or help do, if it can't= complete the function);=C2=A0needs are what the node=C2=A0needs help in do= ing. This enables nodes to work together, sharing their functionality, to a= ccomplish mutually beneficial goals (and/or beneficial for the community).<= br>

regards,
John

On Tue, Jun 16, 2015 at = 7:27 PM, Brian E Carpenter <brian.e.carpenter@gmail.com><= /span> wrote:
On 16/06/2015 20:39, Michae= l Behringer (mbehring) wrote:
> Brian,
>
> Yes, that needs to be made more clear.
>
> To me:
> - Administrative domain: All nodes under one administrative control, e= x: "example.domain.com". Surely, that has been defined before= somewhere and we can leverage that definition? The BGP autonomous system c= omes to mind. That should be easy.

When is anything ever easy?...

In fact the definition in RFC 1136 is amazingly good still:

=C2=A0 =C2=A0 =C2=A0Administrative Domain (AD)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"A collection of End Systems, Interm= ediate Systems, and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0subnetworks operated by a single organiza= tion or administrative
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0authority.=C2=A0 The components which mak= e up the domain are assumed
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to interoperate with a significant degree= of mutual trust among
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0themselves, but interoperate with other A= dministrative Domains
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in a mutually suspicious manner" [1]= .

and it's actually a quotation from ISO/TR 9575, 1989 :-).

> Trust is harder, in fact, "trust" is maybe the wrong term. T= his is really all about authentication and authorization, and maybe we shou= ld use those terms for clarity.

Well, there's a sequence: I claim an identity, you authenticate that identity, then you check the authorized capabilities for that identity, and= then
you trust me (but only for those specific capabilities).

At an abstract level this is all old news, I guess. It just gets complicate= d
when authorization and capabilities cross domain boundaries. (I actually worked on that a bit for grid computing a decade ago; I don't really th= ink
it's relevant but we did publish something, which IBM has charmingly st= uck
behind a paywall: http://dx.doi.org/10.1147/sj.434.0689 .)=

=C2=A0 =C2=A0 =C2=A0Brian

> Authentication: an AN node can authenticate all other nodes under the = same PKI root. That includes sub-domains for example. But, if I have the ro= ot CA cert of another domain, and have decided (policy decision!) to trust = that, I can also authenticate other domains. This is all just about knowing= who I talk to, nothing more. This is the simple part.
>
> Now, once I know who I talk to, there are different implications, and = those will be partly policy driven, partly defaults.
>
> Key question is: Authorized to do what? A node can authorize another n= ode to:
> - join the ACP
> - negotiate parameters for protocol X.
> - receive intent from.
> - ...
>
> We need to define a reasonable default authorization scheme, and, goin= g by discussions I've had with operators so far, I think we will need t= o allow for customization via Intent.
>
> Example: There is example.com and subdomain.example.com. Should th= e ACP establish across both? I have heard both customer requirements: 1) Ye= s, I want one big ACP to manage everything in a flat management hierarchy > 2) No, I want the ACP for example.com separate from the ACP for subd= omain.example.com.
>
> Work to be done here... We need to define a good default behaviour, wi= th the hope that there will be minimal exceptions required...
>
> Michael
>
>> -----Original Message-----
>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
>> Sent: 15 June 2015 22:29
>> To: Michael Behringer (mbehring); Anima WG
>> Subject: Re: [Anima] Domains
>>
>> Michael (and I've also read Laurent's and Toerless's m= essages),
>>
>> On 16/06/2015 00:54, Michael Behringer (mbehring) wrote:
>>> Brain,
>>>
>>> Yes, this is a recurring question, and needs to be better expl= ained. The
>> same question came up in Homenet a couple of years back, and this = is how I
>> answered it: In short, every autonomic entity has A SINGLE owner, = and thus
>> a single domain.
>>
>> We do need to be sure first what a "domain" is. An admin= istrative boundary
>> is not necessarily the same as a trust boundary. I can well imagin= e an entity
>> that is in a given admin domain being trusted both in that domain = and in
>> another domain.
>> In that sense, trust domains=C2=A0 might overlap when admin domain= s cannot
>> overlap.
>>
>> Also I'm pretty sure that domains can contain domains, both in= the admin
>> view and in the trust view. But the nesting might not be the same.=
>>
>> Please note, I don't have a fixed opinion here, I just want cl= arity in our
>> model and terminology.
>>
>>=C2=A0 =C2=A0 =C2=A0 Brian
>>
>>>
>>> Let's first define what we're talking about: I specifi= cally state "autonomic
>> entity" above. I.e., something that can negotiate on its own.= That's what
>> we're concerned with here. Specifically, a queue in a router i= s NOT an
>> autonomic entity. Therefore, even if several different domains use= it, this
>> has to be managed by the autonomic entity (the router), which nego= tiates
>> bits and pieces for different domains. But the negotiator is the r= outer, an
>> autonomic entity, and that one has only one domain.
>>>
>>> 1. I claim for every autonomic entity out there, there is one = single
>> administrative "owner". The one who has root access, ena= ble, short, the full
>> admin rights.
>>>
>>> Example: Take the homenet CPE. There is a managed services mod= el,
>> where the SP maintains the CPE, there is the case where the homene= t
>> owner is controlling the CPE. Inside the home network, there may b= e a
>> device that is owned by a utility, which maybe uses your network t= o
>> communicate with sensors, or uses your Internet connection to call= home.
>> You may have some influence on the device settings, but the utilit= y is the
>> administrative owner.
>>>
>>> 2. The owner of the autonomic entity can grant some rights to = other
>> people.
>>>
>>> In your bandwidth broker example, there is still ONE autonomic= entity
>> who has full admin rights over a device (with all its queues, etc)= . This entity
>> grants rights to another domain to use a certain amount of bufferi= ng,
>> whatever, on the device. A special case of that:
>>>
>>> 3. A device, owned by domain A, can run a container / VM / oth= er
>> virtualization concept that belongs to domain B.
>>>
>>> Then you get to a case where there is the base hardware which = is owned
>> by one domain, and say VMs running on top belonging to another dom= ain.
>> That is supported, and we should have clear boundaries in this cas= e.
>>>
>>> 4. Domain A can grant rights to for example a VM of domain B.<= br> >>>
>>> Example, on my home CPE, I run a container that belongs to the= utility; i
>> give that access to my Internet connection, possibly to a specific= SSID,
>> whatever.
>>>
>>> Clean separation, clean authorization of rights.
>>>
>>> Looking at your pictures, I think all three show a "resou= rce" as *not* being
>> an autonomic entity, but as a sub-part of an autonomic entity, exa= mple was
>> the link between two domains. This is where the confusion is comin= g from.
>> If we agree that we're talking about the domain of an *autonom= ic entity*,
>> then the picture is different, and hopefully clearer. Then it'= s up to the
>> autonomic entities (and possibly domains) that share a non-autonom= ic
>> entity to negotiate its usage.
>>>
>>> Does that make sense?
>>> Michael
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E
>>>> Carpenter
>>>> Sent: 14 June 2015 22:32
>>>> To: Anima WG
>>>> Subject: [Anima] Domains
>>>>
>>>> Hi,
>>>>
>>>> I want to raise a point about the reference model that the= authors of
>>>> draft- behringer-anima-reference-model didn't settle b= efore version
>>>> -02 came out a few days ago. There's placeholder text = in the draft
>>>> about Sub-Domains and Cross-Domain Functionality. I sugges= ted that we
>>>> should also list "Overlapping Domains" as a topi= c. In other words,
>>>> regions of a network could be considered to be in two diff= erent
>>>> domains simultaneously. The question is whether we want ou= r model to
>>>> include that possibility? It certainly has implications fo= r security.
>>>>
>>>> An example would be some sort of resource that needed to b= e shared
>>>> between two otherwise separate domains; that resource coul= d be
>>>> considered to be in both domains.
>>>>
>>>> So I can see three possible models, shown in the folowing = ASCII art:
>>>>
>>>> -------------------------------------------
>>>> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Shared Resource= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>>> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|
>>>> | ------------------=C2=A0 =C2=A0------------------ |
>>>> | | Subddomain1=C2=A0 =C2=A0 |=C2=A0 =C2=A0| Subddomain2= =C2=A0 =C2=A0 | |
>>>> | |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= |=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | |=
>>>> | |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= |=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | |=
>>>> | ------------------=C2=A0 =C2=A0------------------ |
>>>> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|
>>>> -------------------------------------------
>>>>
>>>> 1. Shared resource in outer domain
>>>>
>>>>=C2=A0 ------------------=C2=A0 =C2=A0------------------ >>>>=C2=A0 |=C2=A0 =C2=A0Domain1=C2=A0 =C2=A0 =C2=A0 |=C2=A0 = =C2=A0|=C2=A0 =C2=A0Domain2=C2=A0 =C2=A0 =C2=A0 |
>>>>=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |
>>>>=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Shared |=C2=A0 = =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
>>>>=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0Resource<|xxx|>=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>>>=C2=A0 ------------------=C2=A0 =C2=A0------------------ >>>>
>>>> 2. Shared resource in one domain, with cross-domain access=
>>>>
>>>>=C2=A0 ----------------------
>>>>=C2=A0 |=C2=A0 =C2=A0Domain1=C2=A0 =C2=A0 ------|----------= --------
>>>>=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | = Shared=C2=A0 =C2=A0 Domain2=C2=A0 =C2=A0 =C2=A0|
>>>>=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |R= esource=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>>>=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|
>>>>=C2=A0 ---------------|------=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0-------------------------
>>>>
>>>> 3. Shared resource in domain overlap
>>>>
>>>> Regards
>>>>=C2=A0 =C2=A0 =C2=A0Brian
>>>>
>>>> _______________________________________________
>>>> Anima mailing list
>>>> Anima@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/an= ima
>>> .
>>>

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



--
regards,
John
--089e013c678228b4d205193c1156-- From nobody Tue Jun 23 23:39:15 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78B31B2AC6 for ; Tue, 23 Jun 2015 23:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0nDcj7UqCdz for ; Tue, 23 Jun 2015 23:39:12 -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 AE9B01B2ABC for ; Tue, 23 Jun 2015 23:39:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUG91407; Wed, 24 Jun 2015 06:39:10 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 24 Jun 2015 07:39:08 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.152]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Wed, 24 Jun 2015 14:39:03 +0800 From: Sheng Jiang To: Anima WG Thread-Topic: ANIMA sessions in IETF 93, Pargue Thread-Index: AdCuSHSwDdR76KfrQ0WEP9f3ILG8xQ== Date: Wed, 24 Jun 2015 06:39:02 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B925F5590EA@nkgeml512-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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "anima-chairs@tools.ietf.org" Subject: [Anima] ANIMA sessions in IETF 93, Pargue X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jun 2015 06:39:12 -0000 SGksIGFsbCwNCg0KV2UgaGF2ZSBiZWVuIGFsbG9jYXRlZCB0d28gc2Vzc2lvbnMgd2l0aCBnb29k IHRpbWVzICgyKyAxLjUgaG91cnMpLiBQbGVhc2UgYXJyYW5nZSB5b3VyIHRyaXAgYWNjb3JkaW5n bHkuDQoNCjk6MDAtMTE6MzAJTW9uZGF5IE1vcm5pbmcgc2Vzc2lvbiBJDQoNCjE3OjQwLTE5OjEw CVRodXJzZGF5IEFmdGVybm9vbiBzZXNzaW9uIElJSQ0KDQpQbGVhc2Ugc2VuZCB5b3VyIHJlcXVl c3QgZm9yIHRpbWUgc2xvdHMgdG8gdGhlIGNoYWlycy4gVGhlIG5vbi1jaGFydGVyIHdvcmsgaXRl bXMgbXVzdCBoYXZlIGF0IGxlYXN0IHN1Ym1pdHRlZCBkcmFmdHMgdG8gYmUgaW5jbHVkZWQgaW4g dGhlIGFnZW5kYS4gVGhlIGNoYWlycyB3aWxsIHB1Ymxpc2ggdGhlIGFnZW5kYSB3ZWxsIGFmdGVy IHRoZSBkcmFmdCBzdWJtaXNzaW9uIGRlYWRsaW5lLiA6KQ0KDQpCZXN0IHJlZ2FyZHMsDQoNClNo ZW5nICsgVG9lcmxlc3MNCg== From nobody Wed Jun 24 10:12:42 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994071B2BD0 for ; Wed, 24 Jun 2015 10:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIW-nJPbZoXh for ; Wed, 24 Jun 2015 10:12:40 -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 2EFE41B2C00 for ; Wed, 24 Jun 2015 10:11:48 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 998962002A; Wed, 24 Jun 2015 13:26:57 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 6E42363AE8; Wed, 24 Jun 2015 13:11:47 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 525BB63AD9; Wed, 24 Jun 2015 13:11:47 -0400 (EDT) From: Michael Richardson To: "Michael Behringer \(mbehring\)" In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0FDC@xmb-rcd-x14.cisco.com> References: <20150618095520.3486.7068.idtracker@ietfa.amsl.com> <55876E20.2070508@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0FDC@xmb-rcd-x14.cisco.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: Cc: Anima WG Subject: Re: [Anima] I-D Action: draft-behringer-anima-autonomic-addressing-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jun 2015 17:12:41 -0000 --=-=-= Content-Type: text/plain Michael Behringer (mbehring) wrote: >> > IPv6 only: Autonomic processes should use exclusively IPv6, for >> > simplicity reasons. >> >> I agree with this as long as it's an RFC 2119 SHOULD, i.e. IPv4 could be used in >> extraordinary circumstances. The GDNP design is fundamentally IP-version >> independent. > Yes, as long as it's really "extraordinary" ;-) That 2119 says > "SHOULD" means like you need a really good reason to not do it. What > would such a good reason be? Just saying, in our implementation we > often get the requirement "we want IPv4", and when you dig, the reason > is that they don't want to deploy IPv6, and that's the only > reason. Slippery slope... a) to respond to the immediate "we want IPv4" --- I'd just tell the customer that it uses a custom link layer protocol that uses an ethernet type different than 0x0800... just like CDP does :-) (I don't think you need to "deploy" IPv6 to have an ACP...) b) the only thing I care about is that nobody is allowed to say, "but mechanism XYZ does not exist in IPv4". That's all. I don't know if we will need IPv6-only things, but maybe. ... >> Use-ULA: For these overlay addresses of autonomic nodes, we use Unique >> Local Addresses (ULA), as specified in [RFC4193]. An alternative >> scheme was discussed, using assigned ULA addressing. The consensus >> was to use standard ULA, because it was deemed to be sufficient. It might be that ULA is an IPv6-only feature. I don't consider 10/8 to be the same, as it is not statistically unique inside the AS. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVYrk0ICLcPvd0N1lAQIhrAgAvCh7/tQ/KbNYX/B48zX8UHW0QzRec0KH V5mBvPK59+jNyJ2cbeKOPqM4z3kXWpaK89QF2Gyc0pwup/x42huPTbA03REh/qdA KfpDlIt+Eh8tSbdyrZeGU/eBL2jbgygVHjBliWxDpxl5zc5TUT75LTHg+9VMeU0d KZm0Tm0NMoCsvt2zDkccoS9Ic9G0ZJo9BEVXhsP1Csv4dtvdRn10Z3eihHUlEhv3 mTDl10hqVNkO3ZO9V17XNWHjXSNdhnLLchukvgXQWRrqmo0VDzoACREbshl5a6/a 7HjYbMU09n6eu6VVM5SrK58bmL5swnYSqZAT1wyLeCfRsNRPzOd3VA== =sMyY -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 24 19:06:31 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834A01A876F for ; Wed, 24 Jun 2015 19:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOLgQ_HbkVmT for ; Wed, 24 Jun 2015 19:06:28 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C2E91A874A for ; Wed, 24 Jun 2015 19:06:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXX78510; Thu, 25 Jun 2015 02:06:26 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 25 Jun 2015 03:06:25 +0100 Received: from NKGEML505-MBX.china.huawei.com ([169.254.1.218]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Thu, 25 Jun 2015 10:06:19 +0800 From: Duzongpeng To: Michael Richardson , "Michael Behringer (mbehring)" Thread-Topic: Whether IPv6 only for ACP? //RE: [Anima] I-D Action: draft-behringer-anima-autonomic-addressing-01.txt Thread-Index: AQHQrQ0JxnKyEMklr0+LN8cjKtz67Z27YX2AgAET6hA= Date: Thu, 25 Jun 2015 02:06:19 +0000 Message-ID: References: <20150618095520.3486.7068.idtracker@ietfa.amsl.com> <55876E20.2070508@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0FDC@xmb-rcd-x14.cisco.com> <21740.1435165907@sandelman.ca> In-Reply-To: <21740.1435165907@sandelman.ca> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.149.226] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Anima WG Subject: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft-behringer-anima-autonomic-addressing-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 25 Jun 2015 02:06:29 -0000 Hi, Michael Richardson: I agree with your option. Perhaps ACP is not needed to be IPv6 only. Of course, an IPv6 only autonomic control plane is ok for all the services= in autonomic network, and the solution has the advantage of simplicity as = mentioned by Michael Behringer. However, the network operator may be more familiar with the IPv4-base mana= gement. In the beginning of the ACP deployment, the network operator may not be ve= ry confident about the decisions made by the autonomic network. Some kinds = of monitoring jobs may be desired by the network operators. At this time, t= he operator may want to see some IPv4 addresses. So, perhaps we need to pro= vide IPv4-based ACP as an option for these parts of operators. Otherwise, w= e can only answer them "sorry, we only support IPv6 here". As IPv4 has been widely deployed, perhaps an IPv4-based autonomic network = will be accepted by more network managers at the beginning. Indeed, at this time, an IPv4-based ACP is not as mature as the IPv6 one. = Thus, perhaps some work needs to be done at this direction. For example, as= you mentioned, how can we get an address instead of the ULA in IPv6. Best regards Zongpeng Du -----Original Message----- From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael Richardson Sent: Thursday, June 25, 2015 1:12 AM To: Michael Behringer (mbehring) Cc: Anima WG Subject: Re: [Anima] I-D Action: draft-behringer-anima-autonomic-addressing= -01.txt Michael Behringer (mbehring) wrote: >> > IPv6 only: Autonomic processes should use exclusively IPv6, for >> > simplicity reasons. >> >> I agree with this as long as it's an RFC 2119 SHOULD, i.e. IPv4 coul= d be used in >> extraordinary circumstances. The GDNP design is fundamentally IP-ver= sion >> independent. > Yes, as long as it's really "extraordinary" ;-) That 2119 says > "SHOULD" means like you need a really good reason to not do it. What > would such a good reason be? Just saying, in our implementation we > often get the requirement "we want IPv4", and when you dig, the reaso= n > is that they don't want to deploy IPv6, and that's the only > reason. Slippery slope... a) to respond to the immediate "we want IPv4" --- I'd just tell the custome= r that it uses a custom link layer protocol that uses an ethernet type different than 0x0800... just like CDP does :-) (I don't think you need to "deploy" IPv6 to have an ACP...) b) the only thing I care about is that nobody is allowed to say, "but mechanism XYZ does not exist in IPv4". That's all. I don't know if we will need IPv6-only things, but maybe. ... >> Use-ULA: For these overlay addresses of autonomic nodes, we use Uniq= ue >> Local Addresses (ULA), as specified in [RFC4193]. An alternative >> scheme was discussed, using assigned ULA addressing. The consensus >> was to use standard ULA, because it was deemed to be sufficient. It might be that ULA is an IPv6-only feature. I don't consider 10/8 to be the same, as it is not statistically unique ins= ide the AS. -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- From nobody Wed Jun 24 20:00:54 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C6E1A90D3 for ; Wed, 24 Jun 2015 20:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIkq_Ap5_8g8 for ; Wed, 24 Jun 2015 20:00:51 -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 705301A8FD5 for ; Wed, 24 Jun 2015 20:00:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUH90332; Thu, 25 Jun 2015 03:00:47 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 25 Jun 2015 04:00:46 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.152]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Thu, 25 Jun 2015 11:00:34 +0800 From: Sheng Jiang To: Duzongpeng , Michael Richardson , "Michael Behringer (mbehring)" Thread-Topic: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft-behringer-anima-autonomic-addressing-01.txt Thread-Index: AQHQru7z1uF+rKGbAUuFV4RBjHzBhZ28hwvA Date: Thu, 25 Jun 2015 03:00:33 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B925F559959@nkgeml512-mbx.china.huawei.com> References: <20150618095520.3486.7068.idtracker@ietfa.amsl.com> <55876E20.2070508@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0FDC@xmb-rcd-x14.cisco.com> <21740.1435165907@sandelman.ca> In-Reply-To: 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Anima WG Subject: Re: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft-behringer-anima-autonomic-addressing-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 25 Jun 2015 03:00:53 -0000 V2UgbmV2ZXIgaGF2ZSBhIHJlc3RyaWN0aW9uIHNhaWQgdGhhdCBBdXRvbm9taWMgTmV0d29yayBt dXN0IGJlIElQdjYtYmFzZWQuIFRoZSBzYW1lIGZvciB0aGUgQU5JTUEgY3VycmVudCBjaGFydGVy LiBJZiB0aGVyZSBhcmUgY3VzdG9tZXJzIHdhbnQgSVB2NC1iYXNlZCBBQ1Agb3IgSVB2NC1iYXNl ZCBBdXRvbm9taWMgTmV0d29yaywgSSBndWVzcyB3ZSBzaG91bGQgYWxzbyB3b3JrIG9uIHRoYXQu IEJ5IHNheWluZyBzbywgSSBzdGlsbCBwcmVmZXIgSVB2NiBvdmVyIElQdjQgYmVjYXVzZSB3ZSBh cmUgZnV0dXJlIG5ldHdvcmsgb3JpZW50ZWQsIGFuZCBJIGFzc3VtZSBmdXR1cmUgbmV0d29yayBp cyBtb3JlIElQdjYuIElmIHdlIGNvdWxkIHdvcmsgb3V0IHNvbWV0aGluZyBJUCBJbmRlcGVuZGVu dCwgaXQgbWF5IGJlIGJldHRlci4NCg0KQmVzdCByZWdhcmRzLA0KDQpTaGVuZw0KDQo+LS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBBbmltYSBbbWFpbHRvOmFuaW1hLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEdXpvbmdwZW5nDQo+U2VudDogVGh1cnNkYXksIEp1bmUg MjUsIDIwMTUgMTA6MDYgQU0NCj5UbzogTWljaGFlbCBSaWNoYXJkc29uOyBNaWNoYWVsIEJlaHJp bmdlciAobWJlaHJpbmcpDQo+Q2M6IEFuaW1hIFdHDQo+U3ViamVjdDogW0FuaW1hXSBXaGV0aGVy IElQdjYgb25seSBmb3IgQUNQPyAvL1JFOiBJLUQgQWN0aW9uOg0KPmRyYWZ0LWJlaHJpbmdlci1h bmltYS1hdXRvbm9taWMtYWRkcmVzc2luZy0wMS50eHQNCj4NCj5IaSwgTWljaGFlbCBSaWNoYXJk c29uOg0KPg0KPglJIGFncmVlIHdpdGggeW91ciBvcHRpb24uIFBlcmhhcHMgQUNQIGlzIG5vdCBu ZWVkZWQgdG8gYmUgSVB2NiBvbmx5Lg0KPg0KPglPZiBjb3Vyc2UsIGFuIElQdjYgb25seSBhdXRv bm9taWMgY29udHJvbCBwbGFuZSBpcyBvayBmb3IgYWxsIHRoZSBzZXJ2aWNlcw0KPmluIGF1dG9u b21pYyBuZXR3b3JrLCBhbmQgdGhlIHNvbHV0aW9uIGhhcyB0aGUgYWR2YW50YWdlIG9mIHNpbXBs aWNpdHkgYXMNCj5tZW50aW9uZWQgYnkgTWljaGFlbCBCZWhyaW5nZXIuDQo+DQo+CUhvd2V2ZXIs IHRoZSBuZXR3b3JrIG9wZXJhdG9yIG1heSBiZSBtb3JlIGZhbWlsaWFyIHdpdGggdGhlIElQdjQt YmFzZQ0KPm1hbmFnZW1lbnQuDQo+CUluIHRoZSBiZWdpbm5pbmcgb2YgdGhlIEFDUCBkZXBsb3lt ZW50LCB0aGUgbmV0d29yayBvcGVyYXRvciBtYXkgbm90DQo+YmUgdmVyeSBjb25maWRlbnQgYWJv dXQgdGhlIGRlY2lzaW9ucyBtYWRlIGJ5IHRoZSBhdXRvbm9taWMgbmV0d29yay4gU29tZQ0KPmtp bmRzIG9mIG1vbml0b3Jpbmcgam9icyBtYXkgYmUgZGVzaXJlZCBieSB0aGUgbmV0d29yayBvcGVy YXRvcnMuIEF0IHRoaXMNCj50aW1lLCB0aGUgb3BlcmF0b3IgbWF5IHdhbnQgdG8gc2VlIHNvbWUg SVB2NCBhZGRyZXNzZXMuIFNvLCBwZXJoYXBzIHdlDQo+bmVlZCB0byBwcm92aWRlIElQdjQtYmFz ZWQgQUNQIGFzIGFuIG9wdGlvbiBmb3IgdGhlc2UgcGFydHMgb2Ygb3BlcmF0b3JzLg0KPk90aGVy d2lzZSwgd2UgY2FuIG9ubHkgYW5zd2VyIHRoZW0gInNvcnJ5LCB3ZSBvbmx5IHN1cHBvcnQgSVB2 NiBoZXJlIi4NCj4NCj4JQXMgSVB2NCBoYXMgYmVlbiB3aWRlbHkgZGVwbG95ZWQsIHBlcmhhcHMg YW4gSVB2NC1iYXNlZCBhdXRvbm9taWMNCj5uZXR3b3JrIHdpbGwgYmUgYWNjZXB0ZWQgYnkgbW9y ZSBuZXR3b3JrIG1hbmFnZXJzIGF0IHRoZSBiZWdpbm5pbmcuDQo+DQo+CUluZGVlZCwgYXQgdGhp cyB0aW1lLCBhbiBJUHY0LWJhc2VkIEFDUCBpcyBub3QgYXMgbWF0dXJlIGFzIHRoZSBJUHY2IG9u ZS4NCj5UaHVzLCBwZXJoYXBzIHNvbWUgd29yayBuZWVkcyB0byBiZSBkb25lIGF0IHRoaXMgZGly ZWN0aW9uLiBGb3IgZXhhbXBsZSwgYXMNCj55b3UgbWVudGlvbmVkLCBob3cgY2FuIHdlIGdldCBh biBhZGRyZXNzIGluc3RlYWQgb2YgdGhlIFVMQSBpbiBJUHY2Lg0KPg0KPkJlc3QgcmVnYXJkcw0K PlpvbmdwZW5nIER1DQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBBbmlt YSBbbWFpbHRvOmFuaW1hLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNaWNoYWVsDQo+ UmljaGFyZHNvbg0KPlNlbnQ6IFRodXJzZGF5LCBKdW5lIDI1LCAyMDE1IDE6MTIgQU0NCj5Ubzog TWljaGFlbCBCZWhyaW5nZXIgKG1iZWhyaW5nKQ0KPkNjOiBBbmltYSBXRw0KPlN1YmplY3Q6IFJl OiBbQW5pbWFdIEktRCBBY3Rpb246DQo+ZHJhZnQtYmVocmluZ2VyLWFuaW1hLWF1dG9ub21pYy1h ZGRyZXNzaW5nLTAxLnR4dA0KPg0KPg0KPk1pY2hhZWwgQmVocmluZ2VyIChtYmVocmluZykgPG1i ZWhyaW5nQGNpc2NvLmNvbT4gd3JvdGU6DQo+ICAgID4+ID4gSVB2NiBvbmx5OiBBdXRvbm9taWMg cHJvY2Vzc2VzIHNob3VsZCB1c2UgZXhjbHVzaXZlbHkgSVB2NiwgZm9yDQo+ICAgID4+ID4gc2lt cGxpY2l0eSByZWFzb25zLg0KPiAgICA+Pg0KPiAgICA+PiBJIGFncmVlIHdpdGggdGhpcyBhcyBs b25nIGFzIGl0J3MgYW4gUkZDIDIxMTkgU0hPVUxELCBpLmUuIElQdjQgY291bGQgYmUNCj51c2Vk IGluDQo+ICAgID4+IGV4dHJhb3JkaW5hcnkgY2lyY3Vtc3RhbmNlcy4gVGhlIEdETlAgZGVzaWdu IGlzIGZ1bmRhbWVudGFsbHkNCj5JUC12ZXJzaW9uDQo+ICAgID4+IGluZGVwZW5kZW50Lg0KPg0K PiAgICA+IFllcywgYXMgbG9uZyBhcyBpdCdzIHJlYWxseSAiZXh0cmFvcmRpbmFyeSIgOy0pICAg VGhhdCAyMTE5IHNheXMNCj4gICAgPiAiU0hPVUxEIiBtZWFucyBsaWtlIHlvdSBuZWVkIGEgcmVh bGx5IGdvb2QgcmVhc29uIHRvIG5vdCBkbyBpdC4gV2hhdA0KPiAgICA+IHdvdWxkIHN1Y2ggYSBn b29kIHJlYXNvbiBiZT8gSnVzdCBzYXlpbmcsIGluIG91ciBpbXBsZW1lbnRhdGlvbiB3ZQ0KPiAg ICA+IG9mdGVuIGdldCB0aGUgcmVxdWlyZW1lbnQgIndlIHdhbnQgSVB2NCIsIGFuZCB3aGVuIHlv dSBkaWcsIHRoZQ0KPnJlYXNvbg0KPiAgICA+IGlzIHRoYXQgdGhleSBkb24ndCB3YW50IHRvIGRl cGxveSBJUHY2LCBhbmQgdGhhdCdzIHRoZSBvbmx5DQo+ICAgID4gcmVhc29uLiBTbGlwcGVyeSBz bG9wZS4uLg0KPg0KPmEpIHRvIHJlc3BvbmQgdG8gdGhlIGltbWVkaWF0ZSAid2Ugd2FudCBJUHY0 IiAtLS0gSSdkIGp1c3QgdGVsbCB0aGUgY3VzdG9tZXINCj4gICB0aGF0IGl0IHVzZXMgYSBjdXN0 b20gbGluayBsYXllciBwcm90b2NvbCB0aGF0IHVzZXMgYW4gZXRoZXJuZXQgdHlwZQ0KPiAgIGRp ZmZlcmVudCB0aGFuIDB4MDgwMC4uLiBqdXN0IGxpa2UgQ0RQIGRvZXMgOi0pDQo+ICAgKEkgZG9u J3QgdGhpbmsgeW91IG5lZWQgdG8gImRlcGxveSIgSVB2NiB0byBoYXZlIGFuIEFDUC4uLikNCj4N Cj5iKSB0aGUgb25seSB0aGluZyBJIGNhcmUgYWJvdXQgaXMgdGhhdCBub2JvZHkgaXMgYWxsb3dl ZCB0byBzYXksICJidXQNCj4gICBtZWNoYW5pc20gWFlaIGRvZXMgbm90IGV4aXN0IGluIElQdjQi LiAgVGhhdCdzIGFsbC4gIEkgZG9uJ3Qga25vdyBpZg0KPiAgIHdlIHdpbGwgbmVlZCBJUHY2LW9u bHkgdGhpbmdzLCBidXQgbWF5YmUuDQo+DQo+Li4uDQo+DQo+ICAgID4+IFVzZS1VTEE6IEZvciB0 aGVzZSBvdmVybGF5IGFkZHJlc3NlcyBvZiBhdXRvbm9taWMgbm9kZXMsIHdlIHVzZQ0KPlVuaXF1 ZQ0KPiAgICA+PiBMb2NhbCBBZGRyZXNzZXMgKFVMQSksIGFzIHNwZWNpZmllZCBpbiBbUkZDNDE5 M10uICBBbiBhbHRlcm5hdGl2ZQ0KPiAgICA+PiBzY2hlbWUgd2FzIGRpc2N1c3NlZCwgdXNpbmcg YXNzaWduZWQgVUxBIGFkZHJlc3NpbmcuICBUaGUNCj5jb25zZW5zdXMNCj4gICAgPj4gd2FzIHRv IHVzZSBzdGFuZGFyZCBVTEEsIGJlY2F1c2UgaXQgd2FzIGRlZW1lZCB0byBiZSBzdWZmaWNpZW50 Lg0KPg0KPkl0IG1pZ2h0IGJlIHRoYXQgVUxBIGlzIGFuIElQdjYtb25seSBmZWF0dXJlLg0KPkkg ZG9uJ3QgY29uc2lkZXIgMTAvOCB0byBiZSB0aGUgc2FtZSwgYXMgaXQgaXMgbm90IHN0YXRpc3Rp Y2FsbHkgdW5pcXVlIGluc2lkZSB0aGUNCj5BUy4NCj4NCj4tLQ0KPk1pY2hhZWwgUmljaGFyZHNv biA8bWNyK0lFVEZAc2FuZGVsbWFuLmNhPiwgU2FuZGVsbWFuIFNvZnR3YXJlIFdvcmtzDQo+LT0g SVB2NiBJb1QgY29uc3VsdGluZyA9LQ0KPg0KPg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+QW5pbWEgbWFpbGluZyBsaXN0DQo+QW5pbWFAaWV0 Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hDQo= From nobody Thu Jun 25 00:25:03 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7278B1B30C4 for ; Thu, 25 Jun 2015 00:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JbRni_rwZis for ; Thu, 25 Jun 2015 00:24:59 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80A111B30CC for ; Thu, 25 Jun 2015 00:24:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5075; q=dns/txt; s=iport; t=1435217099; x=1436426699; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4Y0Nz7vFpQnFCx88cvfhB1a0z3bX0fNkDvMYEji1dIA=; b=MXSgwTMLRlmUJf/5BhTfVHk6wez+k8GCe+mKaRipjutfdoeUW4gmapfk 4oiAidT0dg6C3ffTE6Tv2V01H4sz0B21e0GHHA1rbt/1B2IkZ73uRh6hw ZpgFJSZJwOPV8HGNl5wUWzRtGCwP4CaSpBK/LRA4OgECpzjl8eliZDqD3 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DFAwDsq4tV/4UNJK1bgxGBMwa8JGYJhCqDMAICAoE7OBQBAQEBAQEBgQqEIgEBAQQ6PwwEAgEIEQQBAQEKFAUEBzIUCQgCBAENBQgMB4gUzXQBAQEBAQEBAQEBAQEBAQEBAQEBAQEXi0qEVTEHBoMRgRQBBJQFAY0KkyKDXCZjgVqBPW+BRoECAQEB X-IronPort-AV: E=Sophos;i="5.13,674,1427760000"; d="scan'208";a="4511055" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-8.cisco.com with ESMTP; 25 Jun 2015 07:24:58 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t5P7OwaL005551 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Jun 2015 07:24:58 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.179]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Thu, 25 Jun 2015 02:24:58 -0500 From: "Michael Behringer (mbehring)" To: Duzongpeng , Michael Richardson Thread-Topic: Whether IPv6 only for ACP? //RE: [Anima] I-D Action: draft-behringer-anima-autonomic-addressing-01.txt Thread-Index: AQHQrqDe96DpknYCFUCVDoF9SLw7zJ28zZyAgAACIiA= Date: Thu, 25 Jun 2015 07:24:58 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF42B9@xmb-rcd-x14.cisco.com> References: <20150618095520.3486.7068.idtracker@ietfa.amsl.com> <55876E20.2070508@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0FDC@xmb-rcd-x14.cisco.com> <21740.1435165907@sandelman.ca> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Anima WG Subject: Re: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft-behringer-anima-autonomic-addressing-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 25 Jun 2015 07:25:01 -0000 OK, I think there is some confusion around this topic.=20 A network with autonomic functions (we all agree that a fully autonomic net= work is not our main target for now) can support on the *data plane* any pr= otocol the operator wants to use, including IPv4, appletalk and IPv8 (when = it comes).=20 The statement is for the signalling, messaging and other protocols INSIDE t= he ACP, used by Autonomic Service Agents.=20 Autonomic Service Agents will be exposed to a developer community, and the = vendors implementing the ACP. There is absolutely no reason to standardise = more than one protocol for this purpose.=20 MichaelR is right: You don't need to actively deploy IPv6 to use the ACP. I= t just happens. With one caveat: If you connect an NMS system into the ACP = for "virtual out of band" usage, then that system needs to support IPv6. Bu= t that is typically not a problem, in our experience.=20 In other words: We're saying that *autonomic functions* (which the end user= isn't exposed to at all) are exclusively IPv6, but the network can provide= any service the operator wants. Specifically, an autonomic function (runni= ng on an IPv6 control plane) may well negotiate addressing for IPv4 service= s.=20 Michael > -----Original Message----- > From: Duzongpeng [mailto:duzongpeng@huawei.com] > Sent: 25 June 2015 04:06 > To: Michael Richardson; Michael Behringer (mbehring) > Cc: Anima WG > Subject: Whether IPv6 only for ACP? //RE: [Anima] I-D Action: draft- > behringer-anima-autonomic-addressing-01.txt >=20 > Hi, Michael Richardson: >=20 > I agree with your option. Perhaps ACP is not needed to be IPv6 only. >=20 > Of course, an IPv6 only autonomic control plane is ok for all the > services in autonomic network, and the solution has the advantage of > simplicity as mentioned by Michael Behringer. >=20 > However, the network operator may be more familiar with the IPv4- > base management. > In the beginning of the ACP deployment, the network operator may > not be very confident about the decisions made by the autonomic network. > Some kinds of monitoring jobs may be desired by the network operators. At > this time, the operator may want to see some IPv4 addresses. So, perhaps > we need to provide IPv4-based ACP as an option for these parts of > operators. Otherwise, we can only answer them "sorry, we only support > IPv6 here". >=20 > As IPv4 has been widely deployed, perhaps an IPv4-based > autonomic network will be accepted by more network managers at the > beginning. >=20 > Indeed, at this time, an IPv4-based ACP is not as mature as the IPv6 > one. Thus, perhaps some work needs to be done at this direction. For > example, as you mentioned, how can we get an address instead of the ULA > in IPv6. >=20 > Best regards > Zongpeng Du >=20 > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael > Richardson > Sent: Thursday, June 25, 2015 1:12 AM > To: Michael Behringer (mbehring) > Cc: Anima WG > Subject: Re: [Anima] I-D Action: draft-behringer-anima-autonomic- > addressing-01.txt >=20 >=20 > Michael Behringer (mbehring) wrote: > >> > IPv6 only: Autonomic processes should use exclusively IPv6, for > >> > simplicity reasons. > >> > >> I agree with this as long as it's an RFC 2119 SHOULD, i.e. IPv4 co= uld be > used in > >> extraordinary circumstances. The GDNP design is fundamentally IP- > version > >> independent. >=20 > > Yes, as long as it's really "extraordinary" ;-) That 2119 says > > "SHOULD" means like you need a really good reason to not do it. Wha= t > > would such a good reason be? Just saying, in our implementation we > > often get the requirement "we want IPv4", and when you dig, the > reason > > is that they don't want to deploy IPv6, and that's the only > > reason. Slippery slope... >=20 > a) to respond to the immediate "we want IPv4" --- I'd just tell the custo= mer > that it uses a custom link layer protocol that uses an ethernet type > different than 0x0800... just like CDP does :-) > (I don't think you need to "deploy" IPv6 to have an ACP...) >=20 > b) the only thing I care about is that nobody is allowed to say, "but > mechanism XYZ does not exist in IPv4". That's all. I don't know if > we will need IPv6-only things, but maybe. >=20 > ... >=20 > >> Use-ULA: For these overlay addresses of autonomic nodes, we use > Unique > >> Local Addresses (ULA), as specified in [RFC4193]. An alternative > >> scheme was discussed, using assigned ULA addressing. The consensu= s > >> was to use standard ULA, because it was deemed to be sufficient. >=20 > It might be that ULA is an IPv6-only feature. > I don't consider 10/8 to be the same, as it is not statistically unique i= nside > the AS. >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 From nobody Thu Jun 25 00:31:21 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A391B30D8 for ; Thu, 25 Jun 2015 00:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koioiwYRvE5E for ; Thu, 25 Jun 2015 00:31:17 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA7731B30D7 for ; Thu, 25 Jun 2015 00:31:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6088; q=dns/txt; s=iport; t=1435217476; x=1436427076; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=MsL8v/SKQNDCBPjncj1rrgJLBBdmesuyJHIUyHEC5wg=; b=M+XRWECo3klesGCs9DYv5/V6Zyeh7ZAGNVewoh+fTxK6ZVjhzpkQFdYV JQ+x8mHzsmEiXYrqnGesuJYZIh2KWpq7pemF1czoA3sj/g/KTbwdWRph1 TU6wLlm9pA5neLgYsJATDf1upeyIXONLSuqMSDeQfbtR2e68Q7BVyEWRR E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DJAwC8rYtV/5hdJa1bgxFUXwa8JGYJgVwKgkSDMAICAoE7OBQBAQEBAQEBgQqEIgEBAQQBAQE3NAsMBAIBCBEEAQEBChQFBAcnCxQJCAIEAQ0FCAwHiBQNzVoBAQEBAQEBAQEBAQEBAQEBAQEBAQETBItKhFUxBwaDEYEUBZQFAY0KkyKDXCZjgVqBPW+BRoECAQEB X-IronPort-AV: E=Sophos;i="5.13,675,1427760000"; d="scan'208";a="6412740" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 25 Jun 2015 07:31:15 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t5P7VFaZ021044 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Jun 2015 07:31:15 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.179]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Thu, 25 Jun 2015 02:31:15 -0500 From: "Michael Behringer (mbehring)" To: Duzongpeng , Michael Richardson Thread-Topic: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft-behringer-anima-autonomic-addressing-01.txt Thread-Index: AQHQrxgQihHNTFLA7UCRUDT1wSatXp280xlg Date: Thu, 25 Jun 2015 07:31:14 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF431B@xmb-rcd-x14.cisco.com> References: <20150618095520.3486.7068.idtracker@ietfa.amsl.com> <55876E20.2070508@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0FDC@xmb-rcd-x14.cisco.com> <21740.1435165907@sandelman.ca> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF42B9@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF42B9@xmb-rcd-x14.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Anima WG Subject: Re: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft-behringer-anima-autonomic-addressing-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 25 Jun 2015 07:31:19 -0000 Re-reading my own message, one thing to add: Brian has already stated that = GDNP is protocol independent, and it should be. Of course we want to develo= p everything IP version independent wherever possible.=20 But there has to be some default autonomic addressing, routing, and for THA= T we want to look at IPv6 only at this point.=20 Michael > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael > Behringer (mbehring) > Sent: 25 June 2015 09:25 > To: Duzongpeng; Michael Richardson > Cc: Anima WG > Subject: Re: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft- > behringer-anima-autonomic-addressing-01.txt >=20 > OK, I think there is some confusion around this topic. >=20 > A network with autonomic functions (we all agree that a fully autonomic > network is not our main target for now) can support on the *data plane* a= ny > protocol the operator wants to use, including IPv4, appletalk and IPv8 (w= hen > it comes). >=20 > The statement is for the signalling, messaging and other protocols INSIDE > the ACP, used by Autonomic Service Agents. >=20 > Autonomic Service Agents will be exposed to a developer community, and > the vendors implementing the ACP. There is absolutely no reason to > standardise more than one protocol for this purpose. >=20 > MichaelR is right: You don't need to actively deploy IPv6 to use the ACP.= It > just happens. With one caveat: If you connect an NMS system into the ACP > for "virtual out of band" usage, then that system needs to support IPv6. = But > that is typically not a problem, in our experience. >=20 > In other words: We're saying that *autonomic functions* (which the end > user isn't exposed to at all) are exclusively IPv6, but the network can > provide any service the operator wants. Specifically, an autonomic functi= on > (running on an IPv6 control plane) may well negotiate addressing for IPv4 > services. >=20 > Michael >=20 > > -----Original Message----- > > From: Duzongpeng [mailto:duzongpeng@huawei.com] > > Sent: 25 June 2015 04:06 > > To: Michael Richardson; Michael Behringer (mbehring) > > Cc: Anima WG > > Subject: Whether IPv6 only for ACP? //RE: [Anima] I-D Action: draft- > > behringer-anima-autonomic-addressing-01.txt > > > > Hi, Michael Richardson: > > > > I agree with your option. Perhaps ACP is not needed to be IPv6 only. > > > > Of course, an IPv6 only autonomic control plane is ok for all the > > services in autonomic network, and the solution has the advantage of > > simplicity as mentioned by Michael Behringer. > > > > However, the network operator may be more familiar with the IPv4- > > base management. > > In the beginning of the ACP deployment, the network operator may > not > > be very confident about the decisions made by the autonomic network. > > Some kinds of monitoring jobs may be desired by the network operators. > > At this time, the operator may want to see some IPv4 addresses. So, > > perhaps we need to provide IPv4-based ACP as an option for these parts > > of operators. Otherwise, we can only answer them "sorry, we only > > support > > IPv6 here". > > > > As IPv4 has been widely deployed, perhaps an IPv4-based > autonomic > > network will be accepted by more network managers at the beginning. > > > > Indeed, at this time, an IPv4-based ACP is not as mature as the IPv6 > > one. Thus, perhaps some work needs to be done at this direction. For > > example, as you mentioned, how can we get an address instead of the > > ULA in IPv6. > > > > Best regards > > Zongpeng Du > > > > -----Original Message----- > > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael > > Richardson > > Sent: Thursday, June 25, 2015 1:12 AM > > To: Michael Behringer (mbehring) > > Cc: Anima WG > > Subject: Re: [Anima] I-D Action: draft-behringer-anima-autonomic- > > addressing-01.txt > > > > > > Michael Behringer (mbehring) wrote: > > >> > IPv6 only: Autonomic processes should use exclusively IPv6, fo= r > > >> > simplicity reasons. > > >> > > >> I agree with this as long as it's an RFC 2119 SHOULD, i.e. IPv4 > > could be used in > > >> extraordinary circumstances. The GDNP design is fundamentally > > IP- version > > >> independent. > > > > > Yes, as long as it's really "extraordinary" ;-) That 2119 says > > > "SHOULD" means like you need a really good reason to not do it. W= hat > > > would such a good reason be? Just saying, in our implementation w= e > > > often get the requirement "we want IPv4", and when you dig, the > > reason > > > is that they don't want to deploy IPv6, and that's the only > > > reason. Slippery slope... > > > > a) to respond to the immediate "we want IPv4" --- I'd just tell the > customer > > that it uses a custom link layer protocol that uses an ethernet type > > different than 0x0800... just like CDP does :-) > > (I don't think you need to "deploy" IPv6 to have an ACP...) > > > > b) the only thing I care about is that nobody is allowed to say, "but > > mechanism XYZ does not exist in IPv4". That's all. I don't know if > > we will need IPv6-only things, but maybe. > > > > ... > > > > >> Use-ULA: For these overlay addresses of autonomic nodes, we use > > Unique > > >> Local Addresses (ULA), as specified in [RFC4193]. An alternativ= e > > >> scheme was discussed, using assigned ULA addressing. The > consensus > > >> was to use standard ULA, because it was deemed to be sufficient. > > > > It might be that ULA is an IPv6-only feature. > > I don't consider 10/8 to be the same, as it is not statistically > > unique inside the AS. > > > > -- > > Michael Richardson , Sandelman Software > Works > > -=3D IPv6 IoT consulting =3D- > > > > >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Thu Jun 25 01:10:14 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798D71B31D3 for ; Thu, 25 Jun 2015 01:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwOgZQXbpSFS for ; Thu, 25 Jun 2015 01:10:11 -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 CA6E51B31A8 for ; Thu, 25 Jun 2015 01:10:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUI15855; Thu, 25 Jun 2015 08:10:09 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 25 Jun 2015 09:10:08 +0100 Received: from NKGEML505-MBX.china.huawei.com ([169.254.1.218]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Thu, 25 Jun 2015 16:10:03 +0800 From: Duzongpeng To: "Michael Behringer (mbehring)" , Michael Richardson Thread-Topic: Whether IPv6 only for ACP? //RE: [Anima] I-D Action: draft-behringer-anima-autonomic-addressing-01.txt Thread-Index: AQHQrQ0JxnKyEMklr0+LN8cjKtz67Z27YX2AgAET6hD//9p3AIAAhy2A Date: Thu, 25 Jun 2015 08:10:02 +0000 Message-ID: References: <20150618095520.3486.7068.idtracker@ietfa.amsl.com> <55876E20.2070508@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0FDC@xmb-rcd-x14.cisco.com> <21740.1435165907@sandelman.ca> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF42B9@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF42B9@xmb-rcd-x14.cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.149.226] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Anima WG Subject: Re: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft-behringer-anima-autonomic-addressing-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 25 Jun 2015 08:10:13 -0000 Hi, Michael Behringer Thanks for your reply. Please see inline. Best regards Zongpeng Du -----Original Message----- From: Michael Behringer (mbehring) [mailto:mbehring@cisco.com]=20 Sent: Thursday, June 25, 2015 3:25 PM To: Duzongpeng; Michael Richardson Cc: Anima WG Subject: RE: Whether IPv6 only for ACP? //RE: [Anima] I-D Action: draft-beh= ringer-anima-autonomic-addressing-01.txt OK, I think there is some confusion around this topic.=20 A network with autonomic functions (we all agree that a fully autonomic net= work is not our main target for now) can support on the *data plane* any pr= otocol the operator wants to use, including IPv4, appletalk and IPv8 (when = it comes).=20 [duzongpeng] Agree. [duzongpeng] The statement is for the signalling, messaging and other protocols INSIDE t= he ACP, used by Autonomic Service Agents.=20 Autonomic Service Agents will be exposed to a developer community, and the = vendors implementing the ACP. There is absolutely no reason to standardise = more than one protocol for this purpose.=20 [duzongpeng]=20 I agree that it is vendor's job to implement ACP, and the ACP is kind of = transparent for the operators.=20 Also, I agree that IPv6-based ACP works well for this purpose.=20 However, it does not mean that vendors can not implement an IPv4-based AC= P. =20 Indeed, autonomic network's goal is to make management jobs as less as po= ssible, but in some circumstance, the network operator do need to confirm e= very action of the network nodes. For examples, when debugging, or a high s= ecurity level is suddenly needed. In this time, the ACP should not be trans= parent for the operators. We can not preclude this IPv4 requirement at the beginning. It should be = the operator's option to use an IPv6-based or an IPv4-based one. [duzongpeng] MichaelR is right: You don't need to actively deploy IPv6 to use the ACP. I= t just happens. With one caveat: If you connect an NMS system into the ACP = for "virtual out of band" usage, then that system needs to support IPv6. Bu= t that is typically not a problem, in our experience.=20 [duzongpeng]=20 I agree that "it just happens".=20 However, if we have deployed an IPv4-based ACP, perhaps the solution for = connecting an NMS system into the ACP for "virtual out of band" usage will = become easier. Within an IPv4 network, perhaps the IPv4-based ACP has bette= r compatibility than the IPv6 one. In my understanding, using IPv6 only ACP as you suggested will make the d= esign jobs of autonomic control plane much easier. But, it is a tradeoff be= tween doing less jobs and considering more about satisfying the different r= equirements of network managers.=20 Perhaps in future, when every network is IPv6, an IPv4-based ACP can be e= asily updated to IPv6-based because it can bootstrap itself, and all are au= tonomic. [duzongpeng] In other words: We're saying that *autonomic functions* (which the end user= isn't exposed to at all) are exclusively IPv6, but the network can provide= any service the operator wants. Specifically, an autonomic function (runni= ng on an IPv6 control plane) may well negotiate addressing for IPv4 service= s.=20 Michael > -----Original Message----- > From: Duzongpeng [mailto:duzongpeng@huawei.com] > Sent: 25 June 2015 04:06 > To: Michael Richardson; Michael Behringer (mbehring) > Cc: Anima WG > Subject: Whether IPv6 only for ACP? //RE: [Anima] I-D Action: draft-=20 > behringer-anima-autonomic-addressing-01.txt >=20 > Hi, Michael Richardson: >=20 > I agree with your option. Perhaps ACP is not needed to be IPv6 only. >=20 > Of course, an IPv6 only autonomic control plane is ok for all the=20 > services in autonomic network, and the solution has the advantage of=20 > simplicity as mentioned by Michael Behringer. >=20 > However, the network operator may be more familiar with the IPv4-=20 > base management. > In the beginning of the ACP deployment, the network operator may not=20 > be very confident about the decisions made by the autonomic network. > Some kinds of monitoring jobs may be desired by the network operators.=20 > At this time, the operator may want to see some IPv4 addresses. So,=20 > perhaps we need to provide IPv4-based ACP as an option for these parts=20 > of operators. Otherwise, we can only answer them "sorry, we only=20 > support > IPv6 here". >=20 > As IPv4 has been widely deployed, perhaps an IPv4-based autonomic=20 > network will be accepted by more network managers at the beginning. >=20 > Indeed, at this time, an IPv4-based ACP is not as mature as the IPv6=20 > one. Thus, perhaps some work needs to be done at this direction. For=20 > example, as you mentioned, how can we get an address instead of the=20 > ULA in IPv6. >=20 > Best regards > Zongpeng Du >=20 > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael=20 > Richardson > Sent: Thursday, June 25, 2015 1:12 AM > To: Michael Behringer (mbehring) > Cc: Anima WG > Subject: Re: [Anima] I-D Action: draft-behringer-anima-autonomic-=20 > addressing-01.txt >=20 >=20 > Michael Behringer (mbehring) wrote: > >> > IPv6 only: Autonomic processes should use exclusively IPv6, for > >> > simplicity reasons. > >> > >> I agree with this as long as it's an RFC 2119 SHOULD, i.e. IPv4=20 > could be used in > >> extraordinary circumstances. The GDNP design is fundamentally=20 > IP- version > >> independent. >=20 > > Yes, as long as it's really "extraordinary" ;-) That 2119 says > > "SHOULD" means like you need a really good reason to not do it. Wha= t > > would such a good reason be? Just saying, in our implementation we > > often get the requirement "we want IPv4", and when you dig, the=20 > reason > > is that they don't want to deploy IPv6, and that's the only > > reason. Slippery slope... >=20 > a) to respond to the immediate "we want IPv4" --- I'd just tell the custo= mer > that it uses a custom link layer protocol that uses an ethernet type > different than 0x0800... just like CDP does :-) > (I don't think you need to "deploy" IPv6 to have an ACP...) >=20 > b) the only thing I care about is that nobody is allowed to say, "but > mechanism XYZ does not exist in IPv4". That's all. I don't know if > we will need IPv6-only things, but maybe. >=20 > ... >=20 > >> Use-ULA: For these overlay addresses of autonomic nodes, we use=20 > Unique > >> Local Addresses (ULA), as specified in [RFC4193]. An alternative > >> scheme was discussed, using assigned ULA addressing. The consensu= s > >> was to use standard ULA, because it was deemed to be sufficient. >=20 > It might be that ULA is an IPv6-only feature. > I don't consider 10/8 to be the same, as it is not statistically=20 > unique inside the AS. >=20 > -- > Michael Richardson , Sandelman Software Works=20 > -=3D IPv6 IoT consulting =3D- >=20 >=20 From nobody Thu Jun 25 01:24:07 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8783F1B324E for ; Thu, 25 Jun 2015 01:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebK8o4HyGMkX for ; Thu, 25 Jun 2015 01:24:03 -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 064DC1B31FC for ; Thu, 25 Jun 2015 01:24:02 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUI17949; Thu, 25 Jun 2015 08:24:01 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 25 Jun 2015 09:24:00 +0100 Received: from NKGEML505-MBX.china.huawei.com ([169.254.1.218]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Thu, 25 Jun 2015 16:23:51 +0800 From: Duzongpeng To: "Michael Behringer (mbehring)" , Michael Richardson Thread-Topic: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft-behringer-anima-autonomic-addressing-01.txt Thread-Index: AQHQrxkRDomOGjtUGEW0YQrF2SXEn5284BqA Date: Thu, 25 Jun 2015 08:23:51 +0000 Message-ID: References: <20150618095520.3486.7068.idtracker@ietfa.amsl.com> <55876E20.2070508@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0FDC@xmb-rcd-x14.cisco.com> <21740.1435165907@sandelman.ca> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF42B9@xmb-rcd-x14.cisco.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF431B@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF431B@xmb-rcd-x14.cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.149.226] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Anima WG Subject: Re: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft-behringer-anima-autonomic-addressing-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 25 Jun 2015 08:24:05 -0000 Hi, Michael Behringer I agree that the default setting of the ACP could be IPv6-based, which may = make the communication across autonomic domains easier to implement. What I suggested is that we first have an IPv6-based ACP ready, and define = an IPv4-based one as an alternative option. Best regards Zongpeng Du -----Original Message----- From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael Behringer = (mbehring) Sent: Thursday, June 25, 2015 3:31 PM To: Duzongpeng; Michael Richardson Cc: Anima WG Subject: Re: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft-beh= ringer-anima-autonomic-addressing-01.txt Re-reading my own message, one thing to add: Brian has already stated that = GDNP is protocol independent, and it should be. Of course we want to develo= p everything IP version independent wherever possible.=20 But there has to be some default autonomic addressing, routing, and for THA= T we want to look at IPv6 only at this point.=20 Michael > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael=20 > Behringer (mbehring) > Sent: 25 June 2015 09:25 > To: Duzongpeng; Michael Richardson > Cc: Anima WG > Subject: Re: [Anima] Whether IPv6 only for ACP? //RE: I-D Action:=20 > draft- behringer-anima-autonomic-addressing-01.txt >=20 > OK, I think there is some confusion around this topic. >=20 > A network with autonomic functions (we all agree that a fully=20 > autonomic network is not our main target for now) can support on the=20 > *data plane* any protocol the operator wants to use, including IPv4,=20 > appletalk and IPv8 (when it comes). >=20 > The statement is for the signalling, messaging and other protocols=20 > INSIDE the ACP, used by Autonomic Service Agents. >=20 > Autonomic Service Agents will be exposed to a developer community, and=20 > the vendors implementing the ACP. There is absolutely no reason to=20 > standardise more than one protocol for this purpose. >=20 > MichaelR is right: You don't need to actively deploy IPv6 to use the=20 > ACP. It just happens. With one caveat: If you connect an NMS system=20 > into the ACP for "virtual out of band" usage, then that system needs=20 > to support IPv6. But that is typically not a problem, in our experience. >=20 > In other words: We're saying that *autonomic functions* (which the end=20 > user isn't exposed to at all) are exclusively IPv6, but the network=20 > can provide any service the operator wants. Specifically, an autonomic=20 > function (running on an IPv6 control plane) may well negotiate=20 > addressing for IPv4 services. >=20 > Michael >=20 > > -----Original Message----- > > From: Duzongpeng [mailto:duzongpeng@huawei.com] > > Sent: 25 June 2015 04:06 > > To: Michael Richardson; Michael Behringer (mbehring) > > Cc: Anima WG > > Subject: Whether IPv6 only for ACP? //RE: [Anima] I-D Action: draft-=20 > > behringer-anima-autonomic-addressing-01.txt > > > > Hi, Michael Richardson: > > > > I agree with your option. Perhaps ACP is not needed to be IPv6 only. > > > > Of course, an IPv6 only autonomic control plane is ok for all the=20 > > services in autonomic network, and the solution has the advantage of=20 > > simplicity as mentioned by Michael Behringer. > > > > However, the network operator may be more familiar with the IPv4-=20 > > base management. > > In the beginning of the ACP deployment, the network operator may > not > > be very confident about the decisions made by the autonomic network. > > Some kinds of monitoring jobs may be desired by the network operators. > > At this time, the operator may want to see some IPv4 addresses. So,=20 > > perhaps we need to provide IPv4-based ACP as an option for these=20 > > parts of operators. Otherwise, we can only answer them "sorry, we=20 > > only support > > IPv6 here". > > > > As IPv4 has been widely deployed, perhaps an IPv4-based > autonomic > > network will be accepted by more network managers at the beginning. > > > > Indeed, at this time, an IPv4-based ACP is not as mature as the=20 > > IPv6 one. Thus, perhaps some work needs to be done at this=20 > > direction. For example, as you mentioned, how can we get an address=20 > > instead of the ULA in IPv6. > > > > Best regards > > Zongpeng Du > > > > -----Original Message----- > > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael=20 > > Richardson > > Sent: Thursday, June 25, 2015 1:12 AM > > To: Michael Behringer (mbehring) > > Cc: Anima WG > > Subject: Re: [Anima] I-D Action: draft-behringer-anima-autonomic-=20 > > addressing-01.txt > > > > > > Michael Behringer (mbehring) wrote: > > >> > IPv6 only: Autonomic processes should use exclusively IPv6, fo= r > > >> > simplicity reasons. > > >> > > >> I agree with this as long as it's an RFC 2119 SHOULD, i.e.=20 > > IPv4 could be used in > > >> extraordinary circumstances. The GDNP design is fundamentally > > IP- version > > >> independent. > > > > > Yes, as long as it's really "extraordinary" ;-) That 2119 says > > > "SHOULD" means like you need a really good reason to not do it. W= hat > > > would such a good reason be? Just saying, in our implementation w= e > > > often get the requirement "we want IPv4", and when you dig,=20 > > the reason > > > is that they don't want to deploy IPv6, and that's the only > > > reason. Slippery slope... > > > > a) to respond to the immediate "we want IPv4" --- I'd just tell the > customer > > that it uses a custom link layer protocol that uses an ethernet type > > different than 0x0800... just like CDP does :-) > > (I don't think you need to "deploy" IPv6 to have an ACP...) > > > > b) the only thing I care about is that nobody is allowed to say, "but > > mechanism XYZ does not exist in IPv4". That's all. I don't know if > > we will need IPv6-only things, but maybe. > > > > ... > > > > >> Use-ULA: For these overlay addresses of autonomic nodes, we=20 > > use Unique > > >> Local Addresses (ULA), as specified in [RFC4193]. An alternativ= e > > >> scheme was discussed, using assigned ULA addressing. The > consensus > > >> was to use standard ULA, because it was deemed to be sufficient. > > > > It might be that ULA is an IPv6-only feature. > > I don't consider 10/8 to be the same, as it is not statistically=20 > > unique inside the AS. > > > > -- > > Michael Richardson , Sandelman Software > Works > > -=3D IPv6 IoT consulting =3D- > > > > >=20 > _______________________________________________ > 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 Thu Jun 25 04:56:40 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DEC61B3566 for ; Thu, 25 Jun 2015 04:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AC_1Yp4uwoin for ; Thu, 25 Jun 2015 04:56:28 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 307F11B3556 for ; Thu, 25 Jun 2015 04:56:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8076; q=dns/txt; s=iport; t=1435233382; x=1436442982; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=g7CXF15yDnYpX6bpYtV5CW2/oY/y/R+fgKkV3IEmLYs=; b=gv1fVS1pahXGq1bHAfiRK9mRsB94alrKsveqGnzHTlYMSdZK0O6+fsXI 6EAGNmIRKD9q/inrHaypHgeKM31JgKITAZW/f62Vx1rUs2d6iwTJmssg8 sxqkN7+I6b58aD5TNk2L1P3kdBffomh59tqSZEUpqLkej6M0lCOqpNtFu o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DJAwDs64tV/4wNJK1bgxFUXwa8JmYJgVwKgkSDMAICAoE+OBQBAQEBAQEBgQqEIgEBAQMBAQEBNzQLBQcEAgEIEQQBAQEKFAUEBycLFAkIAgQBDQUIDAeIDAgNzWIBAQEBAQEBAQEBAQEBAQEBAQEBAQETBItKhFUxBwaDEYEUBZQFAY0KkyKDXCZjgVqBPW+BRoECAQEB X-IronPort-AV: E=Sophos;i="5.13,675,1427760000"; d="scan'208";a="162522182" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-2.cisco.com with ESMTP; 25 Jun 2015 11:56:21 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t5PBuK6L013401 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Jun 2015 11:56:20 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.179]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Thu, 25 Jun 2015 06:56:19 -0500 From: "Michael Behringer (mbehring)" To: Duzongpeng , Michael Richardson Thread-Topic: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft-behringer-anima-autonomic-addressing-01.txt Thread-Index: AQHQrxgQihHNTFLA7UCRUDT1wSatXp280xlggABjEID//+XrMA== Date: Thu, 25 Jun 2015 11:56:19 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF47B1@xmb-rcd-x14.cisco.com> References: <20150618095520.3486.7068.idtracker@ietfa.amsl.com> <55876E20.2070508@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0FDC@xmb-rcd-x14.cisco.com> <21740.1435165907@sandelman.ca> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF42B9@xmb-rcd-x14.cisco.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF431B@xmb-rcd-x14.cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Anima WG Subject: Re: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft-behringer-anima-autonomic-addressing-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 25 Jun 2015 11:56:31 -0000 For something new like AN, where the standardised specs will take at least = a couple of years to appear in anyone's products, where we do NOT have back= ward compatibility issues, where we do not address end systems for some yea= rs to come, I personally think it is insane to even consider IPv4.=20 But I think we do have agreement that we start with IPv6 only, and just kee= p the door open, in case we need to support it. If the working group wants = to do that, I'll change the text accordingly. Maybe a discussion for Prague= ?=20 Michael > -----Original Message----- > From: Duzongpeng [mailto:duzongpeng@huawei.com] > Sent: 25 June 2015 10:24 > To: Michael Behringer (mbehring); Michael Richardson > Cc: Anima WG > Subject: RE: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft- > behringer-anima-autonomic-addressing-01.txt >=20 > Hi, Michael Behringer >=20 > I agree that the default setting of the ACP could be IPv6-based, which ma= y > make the communication across autonomic domains easier to implement. >=20 > What I suggested is that we first have an IPv6-based ACP ready, and defin= e > an IPv4-based one as an alternative option. >=20 > Best regards > Zongpeng Du >=20 > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael > Behringer (mbehring) > Sent: Thursday, June 25, 2015 3:31 PM > To: Duzongpeng; Michael Richardson > Cc: Anima WG > Subject: Re: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft- > behringer-anima-autonomic-addressing-01.txt >=20 > Re-reading my own message, one thing to add: Brian has already stated tha= t > GDNP is protocol independent, and it should be. Of course we want to > develop everything IP version independent wherever possible. >=20 > But there has to be some default autonomic addressing, routing, and for > THAT we want to look at IPv6 only at this point. >=20 > Michael >=20 > > -----Original Message----- > > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael > > Behringer (mbehring) > > Sent: 25 June 2015 09:25 > > To: Duzongpeng; Michael Richardson > > Cc: Anima WG > > Subject: Re: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: > > draft- behringer-anima-autonomic-addressing-01.txt > > > > OK, I think there is some confusion around this topic. > > > > A network with autonomic functions (we all agree that a fully > > autonomic network is not our main target for now) can support on the > > *data plane* any protocol the operator wants to use, including IPv4, > > appletalk and IPv8 (when it comes). > > > > The statement is for the signalling, messaging and other protocols > > INSIDE the ACP, used by Autonomic Service Agents. > > > > Autonomic Service Agents will be exposed to a developer community, and > > the vendors implementing the ACP. There is absolutely no reason to > > standardise more than one protocol for this purpose. > > > > MichaelR is right: You don't need to actively deploy IPv6 to use the > > ACP. It just happens. With one caveat: If you connect an NMS system > > into the ACP for "virtual out of band" usage, then that system needs > > to support IPv6. But that is typically not a problem, in our experience= . > > > > In other words: We're saying that *autonomic functions* (which the end > > user isn't exposed to at all) are exclusively IPv6, but the network > > can provide any service the operator wants. Specifically, an autonomic > > function (running on an IPv6 control plane) may well negotiate > > addressing for IPv4 services. > > > > Michael > > > > > -----Original Message----- > > > From: Duzongpeng [mailto:duzongpeng@huawei.com] > > > Sent: 25 June 2015 04:06 > > > To: Michael Richardson; Michael Behringer (mbehring) > > > Cc: Anima WG > > > Subject: Whether IPv6 only for ACP? //RE: [Anima] I-D Action: draft- > > > behringer-anima-autonomic-addressing-01.txt > > > > > > Hi, Michael Richardson: > > > > > > I agree with your option. Perhaps ACP is not needed to be IPv6 only. > > > > > > Of course, an IPv6 only autonomic control plane is ok for all the > > > services in autonomic network, and the solution has the advantage of > > > simplicity as mentioned by Michael Behringer. > > > > > > However, the network operator may be more familiar with the IPv4- > > > base management. > > > In the beginning of the ACP deployment, the network operator may > > not > > > be very confident about the decisions made by the autonomic network. > > > Some kinds of monitoring jobs may be desired by the network operators= . > > > At this time, the operator may want to see some IPv4 addresses. So, > > > perhaps we need to provide IPv4-based ACP as an option for these > > > parts of operators. Otherwise, we can only answer them "sorry, we > > > only support > > > IPv6 here". > > > > > > As IPv4 has been widely deployed, perhaps an IPv4-based > > autonomic > > > network will be accepted by more network managers at the beginning. > > > > > > Indeed, at this time, an IPv4-based ACP is not as mature as the > > > IPv6 one. Thus, perhaps some work needs to be done at this > > > direction. For example, as you mentioned, how can we get an address > > > instead of the ULA in IPv6. > > > > > > Best regards > > > Zongpeng Du > > > > > > -----Original Message----- > > > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael > > > Richardson > > > Sent: Thursday, June 25, 2015 1:12 AM > > > To: Michael Behringer (mbehring) > > > Cc: Anima WG > > > Subject: Re: [Anima] I-D Action: draft-behringer-anima-autonomic- > > > addressing-01.txt > > > > > > > > > Michael Behringer (mbehring) wrote: > > > >> > IPv6 only: Autonomic processes should use exclusively IPv6, = for > > > >> > simplicity reasons. > > > >> > > > >> I agree with this as long as it's an RFC 2119 SHOULD, i.e. > > > IPv4 could be used in > > > >> extraordinary circumstances. The GDNP design is fundamentally > > > IP- version > > > >> independent. > > > > > > > Yes, as long as it's really "extraordinary" ;-) That 2119 say= s > > > > "SHOULD" means like you need a really good reason to not do it. > What > > > > would such a good reason be? Just saying, in our implementation= we > > > > often get the requirement "we want IPv4", and when you dig, > > > the reason > > > > is that they don't want to deploy IPv6, and that's the only > > > > reason. Slippery slope... > > > > > > a) to respond to the immediate "we want IPv4" --- I'd just tell the > > customer > > > that it uses a custom link layer protocol that uses an ethernet ty= pe > > > different than 0x0800... just like CDP does :-) > > > (I don't think you need to "deploy" IPv6 to have an ACP...) > > > > > > b) the only thing I care about is that nobody is allowed to say, "but > > > mechanism XYZ does not exist in IPv4". That's all. I don't know = if > > > we will need IPv6-only things, but maybe. > > > > > > ... > > > > > > >> Use-ULA: For these overlay addresses of autonomic nodes, we > > > use Unique > > > >> Local Addresses (ULA), as specified in [RFC4193]. An alternat= ive > > > >> scheme was discussed, using assigned ULA addressing. The > > consensus > > > >> was to use standard ULA, because it was deemed to be sufficien= t. > > > > > > It might be that ULA is an IPv6-only feature. > > > I don't consider 10/8 to be the same, as it is not statistically > > > unique inside the AS. > > > > > > -- > > > Michael Richardson , Sandelman Software > > Works > > > -=3D IPv6 IoT consulting =3D- > > > > > > > > > > _______________________________________________ > > 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 Thu Jun 25 14:31:51 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D601B1B2AD9 for ; Thu, 25 Jun 2015 14:31:49 -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 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 FDOeSz_owNPf for ; Thu, 25 Jun 2015 14:31:48 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (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 E3E441B2AD5 for ; Thu, 25 Jun 2015 14:31:47 -0700 (PDT) Received: by pdjn11 with SMTP id n11so61099656pdj.0 for ; Thu, 25 Jun 2015 14:31:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=asHlrnA2Xye1DadL5Igg6GjugnEq1Y8xWpo/GjTxzT4=; b=yyAxvjZFvQRz0wmC89kbEn9PA60NZadaInpLTrjcVdI97gtWDkgiJTUFHTuy1npCsu KHdSXyfInOasO6aZe0gvLlDSvstMjH+BESKtCo97VU6BZW+LCBoDiCuMVVNNBrOUkCYx 8fS73fxSGh1gbV9wD1d2pP7Qs3ZfEjkAI1MYlEZgWdnsWdrEdR1Zs/UG35Q2uIcdVKXo rEFrQV9jopyaTyOFsZTAZ3S0ZJINv2tzdv1PrTsST5lNmOdErcpo67j+dzm9ruToMBvm IyeYSqjGzaejskZRYk3NalY0vXFqoVHvRHZ41tcgCXQlAYpSyDiBOtWiYJjgWHUB1/7w NyVQ== X-Received: by 10.68.134.226 with SMTP id pn2mr2070715pbb.86.1435267907596; Thu, 25 Jun 2015 14:31:47 -0700 (PDT) Received: from [172.20.1.103] ([119.17.32.167]) by mx.google.com with ESMTPSA id m17sm12545128pdn.87.2015.06.25.14.31.44 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jun 2015 14:31:46 -0700 (PDT) Message-ID: <558C7343.9000802@gmail.com> Date: Fri, 26 Jun 2015 09:31:47 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: anima@ietf.org References: <20150618095520.3486.7068.idtracker@ietfa.amsl.com> <55876E20.2070508@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0FDC@xmb-rcd-x14.cisco.com> <21740.1435165907@sandelman.ca> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft-behringer-anima-autonomic-addressing-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 25 Jun 2015 21:31:50 -0000 On 25/06/2015 14:06, Duzongpeng wrote: > Hi, Michael Richardson: > > I agree with your option. Perhaps ACP is not needed to be IPv6 only. However, IPv6 has an enormous advantage in a cold start with all devices assumed in factory condition. Every IPv6 stack will acquire a valid link-local address even if no other device (such as a router or DHCP server) is configured and there is no Intent in place. That is what we need for a true AN. > > Of course, an IPv6 only autonomic control plane is ok for all the services in autonomic network, and the solution has the advantage of simplicity as mentioned by Michael Behringer. > > However, the network operator may be more familiar with the IPv4-base management. I'm sorry but such operators are quickly becoming dinosaurs. Looking at the current growth rate of IPv6, and knowing that it will take several years for Anima work to be complete, I think those operators will be in serious trouble. > In the beginning of the ACP deployment, the network operator may not be very confident about the decisions made by the autonomic network. Some kinds of monitoring jobs may be desired by the network operators. At this time, the operator may want to see some IPv4 addresses. Their traditional NMS could still be IPv4, and they could still see IPv4 information through an IPv6 ACP. > So, perhaps we need to provide IPv4-based ACP as an option for these parts of operators. Otherwise, we can only answer them "sorry, we only support IPv6 here". No, the answer is "IPv6 will be deployed automatically with no work by you, but old IPv4 services will not be interrupted." Actually we should think about an "IPv4 management" use case for AN, running over an IPv6 ACP. Best regards, Brian > > As IPv4 has been widely deployed, perhaps an IPv4-based autonomic network will be accepted by more network managers at the beginning. > > Indeed, at this time, an IPv4-based ACP is not as mature as the IPv6 one. Thus, perhaps some work needs to be done at this direction. For example, as you mentioned, how can we get an address instead of the ULA in IPv6. > > Best regards > Zongpeng Du > > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael Richardson > Sent: Thursday, June 25, 2015 1:12 AM > To: Michael Behringer (mbehring) > Cc: Anima WG > Subject: Re: [Anima] I-D Action: draft-behringer-anima-autonomic-addressing-01.txt > > > Michael Behringer (mbehring) wrote: > >> > IPv6 only: Autonomic processes should use exclusively IPv6, for > >> > simplicity reasons. > >> > >> I agree with this as long as it's an RFC 2119 SHOULD, i.e. IPv4 could be used in > >> extraordinary circumstances. The GDNP design is fundamentally IP-version > >> independent. > > > Yes, as long as it's really "extraordinary" ;-) That 2119 says > > "SHOULD" means like you need a really good reason to not do it. What > > would such a good reason be? Just saying, in our implementation we > > often get the requirement "we want IPv4", and when you dig, the reason > > is that they don't want to deploy IPv6, and that's the only > > reason. Slippery slope... > > a) to respond to the immediate "we want IPv4" --- I'd just tell the customer > that it uses a custom link layer protocol that uses an ethernet type > different than 0x0800... just like CDP does :-) > (I don't think you need to "deploy" IPv6 to have an ACP...) > > b) the only thing I care about is that nobody is allowed to say, "but > mechanism XYZ does not exist in IPv4". That's all. I don't know if > we will need IPv6-only things, but maybe. > > ... > > >> Use-ULA: For these overlay addresses of autonomic nodes, we use Unique > >> Local Addresses (ULA), as specified in [RFC4193]. An alternative > >> scheme was discussed, using assigned ULA addressing. The consensus > >> was to use standard ULA, because it was deemed to be sufficient. > > It might be that ULA is an IPv6-only feature. > I don't consider 10/8 to be the same, as it is not statistically unique inside the AS. > > -- > Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > . > From nobody Thu Jun 25 18:32:24 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 806601B29DA for ; Thu, 25 Jun 2015 18:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4vs6htpS1WB for ; Thu, 25 Jun 2015 18:32:21 -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 970DD1B29B8 for ; Thu, 25 Jun 2015 18:32:20 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXY96976; Fri, 26 Jun 2015 01:32:19 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 26 Jun 2015 02:32:18 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.152]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Fri, 26 Jun 2015 09:32:08 +0800 From: Sheng Jiang To: Brian E Carpenter , "anima@ietf.org" , "Michael Behringer (mbehring)" , Michael Richardson Thread-Topic: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft-behringer-anima-autonomic-addressing-01.txt Thread-Index: AQHQru7z1uF+rKGbAUuFV4RBjHzBhZ29OLOAgADCY8A= Date: Fri, 26 Jun 2015 01:32:07 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B925F55A5BB@nkgeml512-mbx.china.huawei.com> References: <20150618095520.3486.7068.idtracker@ietfa.amsl.com> <55876E20.2070508@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0FDC@xmb-rcd-x14.cisco.com> <21740.1435165907@sandelman.ca> <558C7343.9000802@gmail.com> In-Reply-To: <558C7343.9000802@gmail.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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Duzongpeng Subject: Re: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft-behringer-anima-autonomic-addressing-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jun 2015 01:32:23 -0000 SGksIEJyaWFuIGFuZCBNaWNoYWVsIEIsDQoNCkluIG15IHJlYWRpbmcsIGl0IHNlZW1zIHdlIHRh a2UgYSB3cm9uZyBhcmd1bWVudCBoZXJlLiBXaGF0IHdlIGFyZSB0YWxraW5nIGFib3V0IGlzIE5P VCBzdG9wIElQdjYtYmFzZWQgQUNQLiBJdCBpcyByZW1haW5pbmcgb24gb3VyIHByaW9yaXR5IG9y IGRlZmF1bHQgY2hvaWNlLiBUZWNobmljYWxseSwgSSBhbSBub3Qgc3VyZSB0aGUgcG9zc2liaWxp dHkgb3IgZmVhc2liaWxpdHkgSVAgaW5kZXBlbmRlbnQuIElmIHllcywgSVAgaW5kZXBlbmRlbnQg bWF5IGJlIHByZWZlcnJlZCBvdmVyIElQdjYtb25seS4NCg0KQnV0IG1lYW53aGlsZSwgYSBwYXJh bGxlbCBJUHY0LWJhc2VkIEFDUCAob3IgSVAgaW5kZXBlbmRlbnQpIG1lY2hhbmlzbSBzaG91bGQg bm90IGJyaW5nIGFueSBoYXJtLiBJUHY0IGJhc2VkIEludGVybmV0L25ldHdvcmtzIGFyZSBzdGls bCBoYXZpbmcgdGhlIG1vdGl2YXRpb24gdG8gaW1wcm92ZSBpdHNlbGYuIFBhcnRpY3VsYXJseSwg bWFueSBjbG9zZWQgZW50ZXJwcmlzZSBuZXR3b3JrcyBtYW55IHJlbWFpbiBJUHY0LW9ubHkgZm9y IGEgd2hpbGUuIE1hbnkgSUVURiBXRywgc3VjaCBhcyBESEMsIGFyZSB3b3JraW5nIG9uIGJvdGgg SVB2NCBhbmQgSVB2NiBzaW11bHRhbmVvdXNseSwgb2YgY291cnNlLCB3aXRoIElQdjQgaW4gbG93 ZXIgcHJlZmVyZW5jZSBhbmQgcHJpb3JpdHkuDQoNCiJJUHY0IG1hbmFnZW1lbnQiIHVzZSBjYXNl IGZvciBBTiwgcnVubmluZyBvdmVyIGFuIElQdjYgQUNQIHdvdWxkIGFsc28gYmUgYW4gaW50ZXJl c3QgdXNlIGNhc2UuIEl0IGlzIHZhbHVhYmxlIGluIHRoZSBkdWFsIHN0YWNrIG5ldHdvcmsgb3Ig InJ1bm5pbmcgSVB2NCBhcyBhIHNlcnZpY2UiLg0KDQpSZWdhcmRzLA0KDQpTaGVuZw0KDQo+LS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBBbmltYSBbbWFpbHRvOmFuaW1hLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmlhbiBFDQo+Q2FycGVudGVyDQo+U2VudDogRnJp ZGF5LCBKdW5lIDI2LCAyMDE1IDU6MzIgQU0NCj5UbzogYW5pbWFAaWV0Zi5vcmcNCj5TdWJqZWN0 OiBSZTogW0FuaW1hXSBXaGV0aGVyIElQdjYgb25seSBmb3IgQUNQPyAvL1JFOiBJLUQgQWN0aW9u Og0KPmRyYWZ0LWJlaHJpbmdlci1hbmltYS1hdXRvbm9taWMtYWRkcmVzc2luZy0wMS50eHQNCj4N Cj5PbiAyNS8wNi8yMDE1IDE0OjA2LCBEdXpvbmdwZW5nIHdyb3RlOg0KPj4gSGksIE1pY2hhZWwg UmljaGFyZHNvbjoNCj4+DQo+PiAJSSBhZ3JlZSB3aXRoIHlvdXIgb3B0aW9uLiBQZXJoYXBzIEFD UCBpcyBub3QgbmVlZGVkIHRvIGJlIElQdjYgb25seS4NCj4NCj5Ib3dldmVyLCBJUHY2IGhhcyBh biBlbm9ybW91cyBhZHZhbnRhZ2UgaW4gYSBjb2xkIHN0YXJ0IHdpdGggYWxsIGRldmljZXMNCj5h c3N1bWVkIGluIGZhY3RvcnkgY29uZGl0aW9uLiBFdmVyeSBJUHY2IHN0YWNrIHdpbGwgYWNxdWly ZSBhIHZhbGlkIGxpbmstbG9jYWwNCj5hZGRyZXNzIGV2ZW4gaWYgbm8gb3RoZXIgZGV2aWNlIChz dWNoIGFzIGEgcm91dGVyIG9yIERIQ1Agc2VydmVyKSBpcyBjb25maWd1cmVkDQo+YW5kIHRoZXJl IGlzIG5vIEludGVudCBpbiBwbGFjZS4gVGhhdCBpcyB3aGF0IHdlIG5lZWQgZm9yIGEgdHJ1ZSBB Ti4NCj4NCj4+DQo+PiAJT2YgY291cnNlLCBhbiBJUHY2IG9ubHkgYXV0b25vbWljIGNvbnRyb2wg cGxhbmUgaXMgb2sgZm9yIGFsbCB0aGUgc2VydmljZXMNCj5pbiBhdXRvbm9taWMgbmV0d29yaywg YW5kIHRoZSBzb2x1dGlvbiBoYXMgdGhlIGFkdmFudGFnZSBvZiBzaW1wbGljaXR5IGFzDQo+bWVu dGlvbmVkIGJ5IE1pY2hhZWwgQmVocmluZ2VyLg0KPj4NCj4+IAlIb3dldmVyLCB0aGUgbmV0d29y ayBvcGVyYXRvciBtYXkgYmUgbW9yZSBmYW1pbGlhciB3aXRoIHRoZSBJUHY0LWJhc2UNCj5tYW5h Z2VtZW50Lg0KPg0KPkknbSBzb3JyeSBidXQgc3VjaCBvcGVyYXRvcnMgYXJlIHF1aWNrbHkgYmVj b21pbmcgZGlub3NhdXJzLiBMb29raW5nIGF0IHRoZQ0KPmN1cnJlbnQgZ3Jvd3RoIHJhdGUgb2Yg SVB2NiwgYW5kIGtub3dpbmcgdGhhdCBpdCB3aWxsIHRha2Ugc2V2ZXJhbCB5ZWFycw0KPmZvciBB bmltYSB3b3JrIHRvIGJlIGNvbXBsZXRlLCBJIHRoaW5rIHRob3NlIG9wZXJhdG9ycyB3aWxsIGJl IGluIHNlcmlvdXMNCj50cm91YmxlLg0KPg0KPj4gCUluIHRoZSBiZWdpbm5pbmcgb2YgdGhlIEFD UCBkZXBsb3ltZW50LCB0aGUgbmV0d29yayBvcGVyYXRvciBtYXkgbm90DQo+YmUgdmVyeSBjb25m aWRlbnQgYWJvdXQgdGhlIGRlY2lzaW9ucyBtYWRlIGJ5IHRoZSBhdXRvbm9taWMgbmV0d29yay4g U29tZQ0KPmtpbmRzIG9mIG1vbml0b3Jpbmcgam9icyBtYXkgYmUgZGVzaXJlZCBieSB0aGUgbmV0 d29yayBvcGVyYXRvcnMuIEF0IHRoaXMNCj50aW1lLCB0aGUgb3BlcmF0b3IgbWF5IHdhbnQgdG8g c2VlIHNvbWUgSVB2NCBhZGRyZXNzZXMuDQo+DQo+VGhlaXIgdHJhZGl0aW9uYWwgTk1TIGNvdWxk IHN0aWxsIGJlIElQdjQsIGFuZCB0aGV5IGNvdWxkIHN0aWxsIHNlZSBJUHY0DQo+aW5mb3JtYXRp b24NCj50aHJvdWdoIGFuIElQdjYgQUNQLg0KPg0KPj4gU28sIHBlcmhhcHMgd2UgbmVlZCB0byBw cm92aWRlIElQdjQtYmFzZWQgQUNQIGFzIGFuIG9wdGlvbiBmb3IgdGhlc2UgcGFydHMNCj5vZiBv cGVyYXRvcnMuIE90aGVyd2lzZSwgd2UgY2FuIG9ubHkgYW5zd2VyIHRoZW0gInNvcnJ5LCB3ZSBv bmx5IHN1cHBvcnQNCj5JUHY2IGhlcmUiLg0KPg0KPk5vLCB0aGUgYW5zd2VyIGlzICJJUHY2IHdp bGwgYmUgZGVwbG95ZWQgYXV0b21hdGljYWxseSB3aXRoIG5vIHdvcmsgYnkgeW91LA0KPmJ1dA0K Pm9sZCBJUHY0IHNlcnZpY2VzIHdpbGwgbm90IGJlIGludGVycnVwdGVkLiINCj4NCj5BY3R1YWxs eSB3ZSBzaG91bGQgdGhpbmsgYWJvdXQgYW4gIklQdjQgbWFuYWdlbWVudCIgdXNlIGNhc2UgZm9y IEFOLA0KPnJ1bm5pbmcNCj5vdmVyIGFuIElQdjYgQUNQLg0KPg0KPkJlc3QgcmVnYXJkcywNCj4g ICBCcmlhbg0KPg0KPj4NCj4+IAlBcyBJUHY0IGhhcyBiZWVuIHdpZGVseSBkZXBsb3llZCwgcGVy aGFwcyBhbiBJUHY0LWJhc2VkIGF1dG9ub21pYw0KPm5ldHdvcmsgd2lsbCBiZSBhY2NlcHRlZCBi eSBtb3JlIG5ldHdvcmsgbWFuYWdlcnMgYXQgdGhlIGJlZ2lubmluZy4NCj4+DQo+PiAJSW5kZWVk LCBhdCB0aGlzIHRpbWUsIGFuIElQdjQtYmFzZWQgQUNQIGlzIG5vdCBhcyBtYXR1cmUgYXMgdGhl IElQdjYgb25lLg0KPlRodXMsIHBlcmhhcHMgc29tZSB3b3JrIG5lZWRzIHRvIGJlIGRvbmUgYXQg dGhpcyBkaXJlY3Rpb24uIEZvciBleGFtcGxlLCBhcw0KPnlvdSBtZW50aW9uZWQsIGhvdyBjYW4g d2UgZ2V0IGFuIGFkZHJlc3MgaW5zdGVhZCBvZiB0aGUgVUxBIGluIElQdjYuDQo+Pg0KPj4gQmVz dCByZWdhcmRzDQo+PiBab25ncGVuZyBEdQ0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+PiBGcm9tOiBBbmltYSBbbWFpbHRvOmFuaW1hLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBNaWNoYWVsDQo+UmljaGFyZHNvbg0KPj4gU2VudDogVGh1cnNkYXksIEp1bmUgMjUs IDIwMTUgMToxMiBBTQ0KPj4gVG86IE1pY2hhZWwgQmVocmluZ2VyIChtYmVocmluZykNCj4+IENj OiBBbmltYSBXRw0KPj4gU3ViamVjdDogUmU6IFtBbmltYV0gSS1EIEFjdGlvbjoNCj5kcmFmdC1i ZWhyaW5nZXItYW5pbWEtYXV0b25vbWljLWFkZHJlc3NpbmctMDEudHh0DQo+Pg0KPj4NCj4+IE1p Y2hhZWwgQmVocmluZ2VyIChtYmVocmluZykgPG1iZWhyaW5nQGNpc2NvLmNvbT4gd3JvdGU6DQo+ PiAgICAgPj4gPiBJUHY2IG9ubHk6IEF1dG9ub21pYyBwcm9jZXNzZXMgc2hvdWxkIHVzZSBleGNs dXNpdmVseSBJUHY2LCBmb3INCj4+ICAgICA+PiA+IHNpbXBsaWNpdHkgcmVhc29ucy4NCj4+ICAg ICA+Pg0KPj4gICAgID4+IEkgYWdyZWUgd2l0aCB0aGlzIGFzIGxvbmcgYXMgaXQncyBhbiBSRkMg MjExOSBTSE9VTEQsIGkuZS4gSVB2NCBjb3VsZA0KPmJlIHVzZWQgaW4NCj4+ICAgICA+PiBleHRy YW9yZGluYXJ5IGNpcmN1bXN0YW5jZXMuIFRoZSBHRE5QIGRlc2lnbiBpcyBmdW5kYW1lbnRhbGx5 DQo+SVAtdmVyc2lvbg0KPj4gICAgID4+IGluZGVwZW5kZW50Lg0KPj4NCj4+ICAgICA+IFllcywg YXMgbG9uZyBhcyBpdCdzIHJlYWxseSAiZXh0cmFvcmRpbmFyeSIgOy0pICAgVGhhdCAyMTE5IHNh eXMNCj4+ICAgICA+ICJTSE9VTEQiIG1lYW5zIGxpa2UgeW91IG5lZWQgYSByZWFsbHkgZ29vZCBy ZWFzb24gdG8gbm90IGRvIGl0Lg0KPldoYXQNCj4+ICAgICA+IHdvdWxkIHN1Y2ggYSBnb29kIHJl YXNvbiBiZT8gSnVzdCBzYXlpbmcsIGluIG91ciBpbXBsZW1lbnRhdGlvbiB3ZQ0KPj4gICAgID4g b2Z0ZW4gZ2V0IHRoZSByZXF1aXJlbWVudCAid2Ugd2FudCBJUHY0IiwgYW5kIHdoZW4geW91IGRp ZywgdGhlDQo+cmVhc29uDQo+PiAgICAgPiBpcyB0aGF0IHRoZXkgZG9uJ3Qgd2FudCB0byBkZXBs b3kgSVB2NiwgYW5kIHRoYXQncyB0aGUgb25seQ0KPj4gICAgID4gcmVhc29uLiBTbGlwcGVyeSBz bG9wZS4uLg0KPj4NCj4+IGEpIHRvIHJlc3BvbmQgdG8gdGhlIGltbWVkaWF0ZSAid2Ugd2FudCBJ UHY0IiAtLS0gSSdkIGp1c3QgdGVsbCB0aGUgY3VzdG9tZXINCj4+ICAgIHRoYXQgaXQgdXNlcyBh IGN1c3RvbSBsaW5rIGxheWVyIHByb3RvY29sIHRoYXQgdXNlcyBhbiBldGhlcm5ldCB0eXBlDQo+ PiAgICBkaWZmZXJlbnQgdGhhbiAweDA4MDAuLi4ganVzdCBsaWtlIENEUCBkb2VzIDotKQ0KPj4g ICAgKEkgZG9uJ3QgdGhpbmsgeW91IG5lZWQgdG8gImRlcGxveSIgSVB2NiB0byBoYXZlIGFuIEFD UC4uLikNCj4+DQo+PiBiKSB0aGUgb25seSB0aGluZyBJIGNhcmUgYWJvdXQgaXMgdGhhdCBub2Jv ZHkgaXMgYWxsb3dlZCB0byBzYXksICJidXQNCj4+ICAgIG1lY2hhbmlzbSBYWVogZG9lcyBub3Qg ZXhpc3QgaW4gSVB2NCIuICBUaGF0J3MgYWxsLiAgSSBkb24ndCBrbm93IGlmDQo+PiAgICB3ZSB3 aWxsIG5lZWQgSVB2Ni1vbmx5IHRoaW5ncywgYnV0IG1heWJlLg0KPj4NCj4+IC4uLg0KPj4NCj4+ ICAgICA+PiBVc2UtVUxBOiBGb3IgdGhlc2Ugb3ZlcmxheSBhZGRyZXNzZXMgb2YgYXV0b25vbWlj IG5vZGVzLCB3ZSB1c2UNCj5VbmlxdWUNCj4+ICAgICA+PiBMb2NhbCBBZGRyZXNzZXMgKFVMQSks IGFzIHNwZWNpZmllZCBpbiBbUkZDNDE5M10uICBBbiBhbHRlcm5hdGl2ZQ0KPj4gICAgID4+IHNj aGVtZSB3YXMgZGlzY3Vzc2VkLCB1c2luZyBhc3NpZ25lZCBVTEEgYWRkcmVzc2luZy4gIFRoZQ0K PmNvbnNlbnN1cw0KPj4gICAgID4+IHdhcyB0byB1c2Ugc3RhbmRhcmQgVUxBLCBiZWNhdXNlIGl0 IHdhcyBkZWVtZWQgdG8gYmUgc3VmZmljaWVudC4NCj4+DQo+PiBJdCBtaWdodCBiZSB0aGF0IFVM QSBpcyBhbiBJUHY2LW9ubHkgZmVhdHVyZS4NCj4+IEkgZG9uJ3QgY29uc2lkZXIgMTAvOCB0byBi ZSB0aGUgc2FtZSwgYXMgaXQgaXMgbm90IHN0YXRpc3RpY2FsbHkgdW5pcXVlIGluc2lkZQ0KPnRo ZSBBUy4NCj4+DQo+PiAtLQ0KPj4gTWljaGFlbCBSaWNoYXJkc29uIDxtY3IrSUVURkBzYW5kZWxt YW4uY2E+LCBTYW5kZWxtYW4gU29mdHdhcmUNCj5Xb3JrcyAgLT0gSVB2NiBJb1QgY29uc3VsdGlu ZyA9LQ0KPj4NCj4+DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+IEFuaW1hIG1haWxpbmcgbGlzdA0KPj4gQW5pbWFAaWV0Zi5vcmcNCj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWENCj4+IC4NCj4+DQo+ DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5Bbmlt YSBtYWlsaW5nIGxpc3QNCj5BbmltYUBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vYW5pbWENCg== From nobody Thu Jun 25 19:23:15 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC0C1A2182 for ; Thu, 25 Jun 2015 19:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtJy-ReQQsLQ for ; Thu, 25 Jun 2015 19:23:11 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E66AA1A1F70 for ; Thu, 25 Jun 2015 19:23:10 -0700 (PDT) Received: by wibdq8 with SMTP id dq8so5263715wib.1 for ; Thu, 25 Jun 2015 19:23:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uqhUgEA/aUO5sGgaEaFabnaDKC/3lfoayv82w9vdLhs=; b=YYvCKCML9dyXxKN2PFweNvtIjxmSlo2kMG7Ywxp4Yu5uJ1ialrYJ5UJEG5aZ4ofPvL nexp5ROiHEvyK4US4ohVIK1GrosDziGitFO9rdlAR0eDQo7TT5fQz0GmiLL14+mpsTGI UejU4j6ZyfPjaiy8HYdiuaegtGUSED97BS2PCU3EfXfNv8bKK288Bk55PlaGGoWhJ8PI Zk5RHkwALwEiiDJVfAR5tFhvUR+yMIr8LVM+l/wjpYqmDiUMRocwRsVOsQ1KovS8f0Bg s6XrvEgsXEyQxoEOQAsrshW4+eRSn/EX9GxfVqdvZkwsb4FrQ7NKWLaB+dbP5Q5K3Yaa NRmQ== MIME-Version: 1.0 X-Received: by 10.180.9.225 with SMTP id d1mr307076wib.73.1435285389710; Thu, 25 Jun 2015 19:23:09 -0700 (PDT) Received: by 10.27.102.6 with HTTP; Thu, 25 Jun 2015 19:23:09 -0700 (PDT) In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF2677@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0FAB@xmb-rcd-x14.cisco.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF2677@xmb-rcd-x14.cisco.com> Date: Thu, 25 Jun 2015 19:23:09 -0700 Message-ID: From: John Strassner To: "Michael Behringer (mbehring)" , John Strassner Content-Type: multipart/alternative; boundary=001a11c2b2d6ce198c0519626bcc Archived-At: Cc: Anima WG Subject: Re: [Anima] Common Ground on the ACP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jun 2015 02:23:13 -0000 --001a11c2b2d6ce198c0519626bcc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Michael, sorry, just noticed that I forgot to respond to this. This actually applies to section 7.5 of the reference model, but I didn't go into Abstract Data Types (ADTs) there in the copy I sent you, as I thought that this was too detailed. An ADT defines a set of classes that represent data and the operations allowed on those data. The classes are defined to be abstract so as to separate the specification of the data and operations from their implementation. Traditionally, ADTs are collections, and share a set of core operations, such as add, remove, access, find, and retrieve. They can support helper functions (e.g., is the collection empty, clear the collection, provide a subset of the collection, etc.). Things like Stacks, Queues, Lists, Dictionaries, and Graphs are good examples of ADTs. regards, John On Tue, Jun 23, 2015 at 2:43 AM, Michael Behringer (mbehring) < mbehring@cisco.com> wrote: > Inline=E2=80=A6 > > > > *From:* John Strassner [mailto:strazpdj@gmail.com] > *Sent:* 23 June 2015 04:47 > *To:* Michael Behringer (mbehring) > *Cc:* Anima WG > *Subject:* Re: [Anima] Common Ground on the ACP > > > > Hi Michael, > > > > I agree with all of your points. > > > > For 4, I hope we get to a point where we can treat the interface to an AC= P > more like an Abstract Data Type > > > > MB: Can you expand here? Not sure I understand what you mean. > > > > , and then add additional requirements to it. However, any that I can > think of right now would simply strengthen the MUST (and MUST NOT) that y= ou > have already specified here. > > > > For 5, you have a minor typo (they should be 5a and 5b). Shouldn't there > be a 5c and a 5d, which are the E2E versions of 5a and 5b? > > > > MB: See previous email to Brian. I think we=E2=80=99ll address that in th= e new > text. > > > > Michael > > > > regards, > > John > > > > On Mon, Jun 22, 2015 at 9:40 AM, Michael Behringer (mbehring) < > mbehring@cisco.com> wrote: > > ANIMA, > > Trying to get a new version of the ACP draft out later this week, I'm > trying to understand what we're all agreeing on, and what not. > > As I see it, the high level requirements (below) and the benefits would g= o > into the reference model, the details into the ACP draft. > > Requirements for an ACP: > > 1 - The ACP SHOULD provide robust connectivity > As far as possible, it should be independent of configured addressing, > configuration and routing. > (2 and 3 build on this requirement, but also have value on their own) > > 2 - The ACP MUST have a separate address space from the data plane. > Reason: traceability, debug-ability, separation from data plane, > security (can block at edge) > > 3 - The ACP MUST use autonomically managed address space > Reason: easy bootstrap and setup ("autonomic"); robustness (admin can'= t > mess things up so easily). > > I think we agreed: ULA seems like a good choice for 1 and 2. > > 4 - The ACP MUST be generic > Usable by all the functions and protocols of the AN infrastructure. > MUST NOT be tied to a particular protocol. > > 5- The ACP MUST provide security: > Messages coming through the ACP are authenticated to be from a trusted > node, and encrypted. > > 4a - MUST: ACP Hop-by-hop authentication > 4b - SHOULD: ACP Hop-by-hop encryption > > Do we agree on those requirements? > > Michael > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > > > > > -- > > regards, > > John > --=20 regards, John --001a11c2b2d6ce198c0519626bcc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Michael,

sorry, just noti= ced that I forgot to respond to this. This actually applies to section 7.5 = of the reference model, but I didn't go into Abstract Data Types (ADTs)= there in the copy I sent you, as I thought that this was too detailed.

An ADT defines a set of classes that represent data a= nd the operations allowed on those data. The classes are defined to be abst= ract so as to separate the specification of the data and operations from th= eir implementation.

Traditionally, ADTs are collec= tions, and share a set of core operations, such as add, remove, access, fin= d, and retrieve. They can support helper functions (e.g., is the collection= empty, clear the collection, provide a subset of the collection, etc.). Th= ings like Stacks, Queues, Lists, Dictionaries, and Graphs are good examples= of ADTs.

regards,
John

On Tue, Jun 23, 2015 a= t 2:43 AM, Michael Behringer (mbehring) <mbehring@cisco.com> wrote:

= Inline=E2=80=A6=

= =C2=A0

From: John Strassner [mailto:strazpdj@gmail.com]
Sent: 23 June 2015 04:47
To: Michael Behringer (mbehr= ing)
Cc: Anima WG
Subject: Re: [Anima] Common = Ground on the ACP

=C2=A0

Hi Michael,

=C2=A0

I agree with all of your points.<= /font>

=C2=A0

For 4, I hope we get to a point where we can treat the= interface to an ACP more like an Abstract Data Type

= =C2=A0

= MB: Can you expand here? Not sure I underst= and what you mean.

= =C2=A0

, and then add additional requirements to it. However,= any that I can think of right now would simply strengthen the MUST (and MU= ST NOT) that you have already specified here.

=C2=A0

For 5, you have a minor typo (they should be 5a and 5b= ). Shouldn't there be a 5c and a 5d, which are the E2E versions of 5a a= nd 5b?

=C2=A0

= MB: See previous email to Brian. I think we= =E2=80=99ll address that in the new text.

= =C2=A0

= Michael

= =C2=A0

regards,

John

=C2=A0

On Mon, Jun 22, 2015 at 9:40 AM, Michael Behringer (mb= ehring) <mbehrin= g@cisco.com> wrote:

ANIMA,

Trying to get a new version of the ACP draft out later this week, I'm t= rying to understand what we're all agreeing on, and what not.

As I see it, the high level requirements (below) and the benefits would go = into the reference model, the details into the ACP draft.

Requirements for an ACP:

1 - The ACP SHOULD provide robust connectivity
=C2=A0 =C2=A0As far as possible, it should be independent of configured add= ressing, configuration and routing.
=C2=A0 =C2=A0(2 and 3 build on this requirement, but also have value on the= ir own)

2 - The ACP MUST have a separate address space from the data plane.
=C2=A0 =C2=A0Reason: traceability, debug-ability, separation from data plan= e, security (can block at edge)

3 - The ACP MUST use autonomically managed address space
=C2=A0 =C2=A0Reason: easy bootstrap and setup ("autonomic"); robu= stness (admin can't mess things up so easily).

=C2=A0 =C2=A0I think we agreed: ULA seems like a good choice for 1 and 2.
4 - The ACP MUST be generic
=C2=A0 =C2=A0Usable by all the functions and protocols of the AN infrastruc= ture. MUST NOT be tied to a particular protocol.

5- The ACP MUST provide security:
=C2=A0 =C2=A0Messages coming through the ACP are authenticated to be from a= trusted node, and encrypted.

=C2=A0 =C2=A04a - MUST: ACP Hop-by-hop authentication
=C2=A0 =C2=A04b - SHOULD: ACP Hop-by-hop encryption

Do we agree on those requirements?

Michael

_______________________________________________
Anima mailing list
Anima@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/anima<= /p>




--

regards,

John




--
regards,
John
--001a11c2b2d6ce198c0519626bcc-- From nobody Fri Jun 26 00:14:26 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D357F1B348B for ; Fri, 26 Jun 2015 00:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilto6QRykT9o for ; Fri, 26 Jun 2015 00:14:22 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B35D1B3484 for ; Fri, 26 Jun 2015 00:14:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9792; q=dns/txt; s=iport; t=1435302862; x=1436512462; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=e6GAoyr9aK36V6GMPhkKYADMczbIakg+L4dCCEk3ggk=; b=SlyTjYLvq3+IFBlJaKfgfnLDtygTcjGaE6IeiAQecHZTevZKsuRwqB/j cMXKVU8M4VrdC3O3lif7QpIYMpqqieIZZQ2KJi/gVCMvd5wROt/ei+LzT CR3IA3Th9h/L6bHrnwbUmzAOwJQiW2XnIhWfJjyLZ+lrtIU0NQYaQ3uvV I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CLBACF+4xV/4QNJK1bgxFUXwaDGLkQZgmBXAqCRIM0AhyBHDgUAQEBAQEBAYEKhCIBAQEDAQEBASAROgsMBAIBCBEEAQEBAgIGGQQDAgICJQsUAQgIAgQBDQUIE4gMCA24DJZOAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBIYophDsaFhsHBoJiL4EUBZQGAY0LkyODXCZjgVqBPW+BRoECAQEB X-IronPort-AV: E=Sophos;i="5.13,683,1427760000"; d="scan'208";a="4853213" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-8.cisco.com with ESMTP; 26 Jun 2015 07:14:21 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t5Q7ELnX027422 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Jun 2015 07:14:21 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.179]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Fri, 26 Jun 2015 02:14:21 -0500 From: "Michael Behringer (mbehring)" To: Sheng Jiang , Brian E Carpenter , "anima@ietf.org" , "Michael Richardson" Thread-Topic: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft-behringer-anima-autonomic-addressing-01.txt Thread-Index: AQHQr45clpskeIiiNEWNIDUk6nqfsJ2+VIiAgAAKIuA= Date: Fri, 26 Jun 2015 07:14:20 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF5CA2@xmb-rcd-x14.cisco.com> References: <20150618095520.3486.7068.idtracker@ietfa.amsl.com> <55876E20.2070508@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0FDC@xmb-rcd-x14.cisco.com> <21740.1435165907@sandelman.ca> <558C7343.9000802@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F55A5BB@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B925F55A5BB@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.134] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Duzongpeng Subject: Re: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft-behringer-anima-autonomic-addressing-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jun 2015 07:14:25 -0000 U2hlbmc6IFdIWT8/PyBXaHkgd291bGQgeW91IHdhbnQgYW4gSVB2NCBjb250cm9sIHBsYW5lPyBJ ZiB5b3UgaGF2ZSBhIGdvb2QgYW5zd2VyIHRvIHRoYXQgcXVlc3Rpb24sIHdlIGNhbiBhcmd1ZS4g Oi0pIA0KDQpUYWtlIEJHUDogSXQgY2FuIHJ1biBvbiBlaXRoZXIgdjQgb3IgdjYsIGFuZCBpdCBj YW4gbmVnb3RpYXRlIGFueSBwcm90b2NvbCB1bmRlciB0aGUgc3VuLiB0aGUgY29udHJvbCBwbGFu ZSBwcm90b2NvbCBoYXMgbGl0dGxlIHRvIGRvIHdpdGggd2hhdCBpdCBuZWdvdGlhdGVzLiANCg0K VGFrZSBJU0lTOiBJdCdzIG5vdCBldmVuIElQISEgDQoNCk90aGVyIFdHcyBtYXkgaGF2ZSBnb29k IHJlYXNvbnM6IEZvciBleGFtcGxlOiBpbnRlcmZhY2luZyBlbmQgc3lzdGVtcyB3aGVyZSB3ZSBj YW5ub3QgZXhwZWN0IElQdjYgc3VwcG9ydC4gQU4gaXMgTkVXLCB0aGUgQU5JIGlzIE5FVywgdGhl cmUgaXMgbm8gbGVnYWN5LiANCg0KTWljaGFlbA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IFNoZW5nIEppYW5nIFttYWlsdG86amlhbmdzaGVuZ0BodWF3ZWkuY29tXQ0K PiBTZW50OiAyNiBKdW5lIDIwMTUgMDM6MzINCj4gVG86IEJyaWFuIEUgQ2FycGVudGVyOyBhbmlt YUBpZXRmLm9yZzsgTWljaGFlbCBCZWhyaW5nZXIgKG1iZWhyaW5nKTsNCj4gTWljaGFlbCBSaWNo YXJkc29uDQo+IENjOiBEdXpvbmdwZW5nDQo+IFN1YmplY3Q6IFJFOiBbQW5pbWFdIFdoZXRoZXIg SVB2NiBvbmx5IGZvciBBQ1A/IC8vUkU6IEktRCBBY3Rpb246IGRyYWZ0LQ0KPiBiZWhyaW5nZXIt YW5pbWEtYXV0b25vbWljLWFkZHJlc3NpbmctMDEudHh0DQo+IA0KPiBIaSwgQnJpYW4gYW5kIE1p Y2hhZWwgQiwNCj4gDQo+IEluIG15IHJlYWRpbmcsIGl0IHNlZW1zIHdlIHRha2UgYSB3cm9uZyBh cmd1bWVudCBoZXJlLiBXaGF0IHdlIGFyZQ0KPiB0YWxraW5nIGFib3V0IGlzIE5PVCBzdG9wIElQ djYtYmFzZWQgQUNQLiBJdCBpcyByZW1haW5pbmcgb24gb3VyIHByaW9yaXR5IG9yDQo+IGRlZmF1 bHQgY2hvaWNlLiBUZWNobmljYWxseSwgSSBhbSBub3Qgc3VyZSB0aGUgcG9zc2liaWxpdHkgb3Ig ZmVhc2liaWxpdHkgSVANCj4gaW5kZXBlbmRlbnQuIElmIHllcywgSVAgaW5kZXBlbmRlbnQgbWF5 IGJlIHByZWZlcnJlZCBvdmVyIElQdjYtb25seS4NCj4gDQo+IEJ1dCBtZWFud2hpbGUsIGEgcGFy YWxsZWwgSVB2NC1iYXNlZCBBQ1AgKG9yIElQIGluZGVwZW5kZW50KSBtZWNoYW5pc20NCj4gc2hv dWxkIG5vdCBicmluZyBhbnkgaGFybS4gSVB2NCBiYXNlZCBJbnRlcm5ldC9uZXR3b3JrcyBhcmUg c3RpbGwgaGF2aW5nIHRoZQ0KPiBtb3RpdmF0aW9uIHRvIGltcHJvdmUgaXRzZWxmLiBQYXJ0aWN1 bGFybHksIG1hbnkgY2xvc2VkIGVudGVycHJpc2UgbmV0d29ya3MNCj4gbWFueSByZW1haW4gSVB2 NC1vbmx5IGZvciBhIHdoaWxlLiBNYW55IElFVEYgV0csIHN1Y2ggYXMgREhDLCBhcmUgd29ya2lu Zw0KPiBvbiBib3RoIElQdjQgYW5kIElQdjYgc2ltdWx0YW5lb3VzbHksIG9mIGNvdXJzZSwgd2l0 aCBJUHY0IGluIGxvd2VyDQo+IHByZWZlcmVuY2UgYW5kIHByaW9yaXR5Lg0KPiANCj4gIklQdjQg bWFuYWdlbWVudCIgdXNlIGNhc2UgZm9yIEFOLCBydW5uaW5nIG92ZXIgYW4gSVB2NiBBQ1Agd291 bGQgYWxzbw0KPiBiZSBhbiBpbnRlcmVzdCB1c2UgY2FzZS4gSXQgaXMgdmFsdWFibGUgaW4gdGhl IGR1YWwgc3RhY2sgbmV0d29yayBvciAicnVubmluZw0KPiBJUHY0IGFzIGEgc2VydmljZSIuDQo+ IA0KPiBSZWdhcmRzLA0KPiANCj4gU2hlbmcNCj4gDQo+ID4tLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiA+RnJvbTogQW5pbWEgW21haWx0bzphbmltYS1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgQnJpYW4gRQ0KPiA+Q2FycGVudGVyDQo+ID5TZW50OiBGcmlkYXksIEp1bmUgMjYs IDIwMTUgNTozMiBBTQ0KPiA+VG86IGFuaW1hQGlldGYub3JnDQo+ID5TdWJqZWN0OiBSZTogW0Fu aW1hXSBXaGV0aGVyIElQdjYgb25seSBmb3IgQUNQPyAvL1JFOiBJLUQgQWN0aW9uOg0KPiA+ZHJh ZnQtYmVocmluZ2VyLWFuaW1hLWF1dG9ub21pYy1hZGRyZXNzaW5nLTAxLnR4dA0KPiA+DQo+ID5P biAyNS8wNi8yMDE1IDE0OjA2LCBEdXpvbmdwZW5nIHdyb3RlOg0KPiA+PiBIaSwgTWljaGFlbCBS aWNoYXJkc29uOg0KPiA+Pg0KPiA+PiAJSSBhZ3JlZSB3aXRoIHlvdXIgb3B0aW9uLiBQZXJoYXBz IEFDUCBpcyBub3QgbmVlZGVkIHRvIGJlIElQdjYgb25seS4NCj4gPg0KPiA+SG93ZXZlciwgSVB2 NiBoYXMgYW4gZW5vcm1vdXMgYWR2YW50YWdlIGluIGEgY29sZCBzdGFydCB3aXRoIGFsbA0KPiA+ ZGV2aWNlcyBhc3N1bWVkIGluIGZhY3RvcnkgY29uZGl0aW9uLiBFdmVyeSBJUHY2IHN0YWNrIHdp bGwgYWNxdWlyZSBhDQo+ID52YWxpZCBsaW5rLWxvY2FsIGFkZHJlc3MgZXZlbiBpZiBubyBvdGhl ciBkZXZpY2UgKHN1Y2ggYXMgYSByb3V0ZXIgb3INCj4gPkRIQ1Agc2VydmVyKSBpcyBjb25maWd1 cmVkIGFuZCB0aGVyZSBpcyBubyBJbnRlbnQgaW4gcGxhY2UuIFRoYXQgaXMgd2hhdCB3ZQ0KPiBu ZWVkIGZvciBhIHRydWUgQU4uDQo+ID4NCj4gPj4NCj4gPj4gCU9mIGNvdXJzZSwgYW4gSVB2NiBv bmx5IGF1dG9ub21pYyBjb250cm9sIHBsYW5lIGlzIG9rIGZvciBhbGwgdGhlDQo+ID4+IHNlcnZp Y2VzDQo+ID5pbiBhdXRvbm9taWMgbmV0d29yaywgYW5kIHRoZSBzb2x1dGlvbiBoYXMgdGhlIGFk dmFudGFnZSBvZiBzaW1wbGljaXR5DQo+ID5hcyBtZW50aW9uZWQgYnkgTWljaGFlbCBCZWhyaW5n ZXIuDQo+ID4+DQo+ID4+IAlIb3dldmVyLCB0aGUgbmV0d29yayBvcGVyYXRvciBtYXkgYmUgbW9y ZSBmYW1pbGlhciB3aXRoIHRoZQ0KPiA+PiBJUHY0LWJhc2UNCj4gPm1hbmFnZW1lbnQuDQo+ID4N Cj4gPkknbSBzb3JyeSBidXQgc3VjaCBvcGVyYXRvcnMgYXJlIHF1aWNrbHkgYmVjb21pbmcgZGlu b3NhdXJzLiBMb29raW5nIGF0DQo+ID50aGUgY3VycmVudCBncm93dGggcmF0ZSBvZiBJUHY2LCBh bmQga25vd2luZyB0aGF0IGl0IHdpbGwgdGFrZSBzZXZlcmFsDQo+ID55ZWFycyBmb3IgQW5pbWEg d29yayB0byBiZSBjb21wbGV0ZSwgSSB0aGluayB0aG9zZSBvcGVyYXRvcnMgd2lsbCBiZSBpbg0K PiA+c2VyaW91cyB0cm91YmxlLg0KPiA+DQo+ID4+IAlJbiB0aGUgYmVnaW5uaW5nIG9mIHRoZSBB Q1AgZGVwbG95bWVudCwgdGhlIG5ldHdvcmsgb3BlcmF0b3IgbWF5DQo+IG5vdA0KPiA+YmUgdmVy eSBjb25maWRlbnQgYWJvdXQgdGhlIGRlY2lzaW9ucyBtYWRlIGJ5IHRoZSBhdXRvbm9taWMgbmV0 d29yay4NCj4gPlNvbWUga2luZHMgb2YgbW9uaXRvcmluZyBqb2JzIG1heSBiZSBkZXNpcmVkIGJ5 IHRoZSBuZXR3b3JrIG9wZXJhdG9ycy4NCj4gPkF0IHRoaXMgdGltZSwgdGhlIG9wZXJhdG9yIG1h eSB3YW50IHRvIHNlZSBzb21lIElQdjQgYWRkcmVzc2VzLg0KPiA+DQo+ID5UaGVpciB0cmFkaXRp b25hbCBOTVMgY291bGQgc3RpbGwgYmUgSVB2NCwgYW5kIHRoZXkgY291bGQgc3RpbGwgc2VlDQo+ ID5JUHY0IGluZm9ybWF0aW9uIHRocm91Z2ggYW4gSVB2NiBBQ1AuDQo+ID4NCj4gPj4gU28sIHBl cmhhcHMgd2UgbmVlZCB0byBwcm92aWRlIElQdjQtYmFzZWQgQUNQIGFzIGFuIG9wdGlvbiBmb3Ig dGhlc2UNCj4gPj4gcGFydHMNCj4gPm9mIG9wZXJhdG9ycy4gT3RoZXJ3aXNlLCB3ZSBjYW4gb25s eSBhbnN3ZXIgdGhlbSAic29ycnksIHdlIG9ubHkNCj4gPnN1cHBvcnQNCj4gPklQdjYgaGVyZSIu DQo+ID4NCj4gPk5vLCB0aGUgYW5zd2VyIGlzICJJUHY2IHdpbGwgYmUgZGVwbG95ZWQgYXV0b21h dGljYWxseSB3aXRoIG5vIHdvcmsgYnkNCj4gPnlvdSwgYnV0IG9sZCBJUHY0IHNlcnZpY2VzIHdp bGwgbm90IGJlIGludGVycnVwdGVkLiINCj4gPg0KPiA+QWN0dWFsbHkgd2Ugc2hvdWxkIHRoaW5r IGFib3V0IGFuICJJUHY0IG1hbmFnZW1lbnQiIHVzZSBjYXNlIGZvciBBTiwNCj4gPnJ1bm5pbmcg b3ZlciBhbiBJUHY2IEFDUC4NCj4gPg0KPiA+QmVzdCByZWdhcmRzLA0KPiA+ICAgQnJpYW4NCj4g Pg0KPiA+Pg0KPiA+PiAJQXMgSVB2NCBoYXMgYmVlbiB3aWRlbHkgZGVwbG95ZWQsIHBlcmhhcHMg YW4gSVB2NC1iYXNlZA0KPiBhdXRvbm9taWMNCj4gPm5ldHdvcmsgd2lsbCBiZSBhY2NlcHRlZCBi eSBtb3JlIG5ldHdvcmsgbWFuYWdlcnMgYXQgdGhlIGJlZ2lubmluZy4NCj4gPj4NCj4gPj4gCUlu ZGVlZCwgYXQgdGhpcyB0aW1lLCBhbiBJUHY0LWJhc2VkIEFDUCBpcyBub3QgYXMgbWF0dXJlIGFz IHRoZSBJUHY2DQo+IG9uZS4NCj4gPlRodXMsIHBlcmhhcHMgc29tZSB3b3JrIG5lZWRzIHRvIGJl IGRvbmUgYXQgdGhpcyBkaXJlY3Rpb24uIEZvcg0KPiA+ZXhhbXBsZSwgYXMgeW91IG1lbnRpb25l ZCwgaG93IGNhbiB3ZSBnZXQgYW4gYWRkcmVzcyBpbnN0ZWFkIG9mIHRoZSBVTEENCj4gaW4gSVB2 Ni4NCj4gPj4NCj4gPj4gQmVzdCByZWdhcmRzDQo+ID4+IFpvbmdwZW5nIER1DQo+ID4+DQo+ID4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IEFuaW1hIFttYWlsdG86YW5p bWEtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1pY2hhZWwNCj4gPlJpY2hhcmRzb24N Cj4gPj4gU2VudDogVGh1cnNkYXksIEp1bmUgMjUsIDIwMTUgMToxMiBBTQ0KPiA+PiBUbzogTWlj aGFlbCBCZWhyaW5nZXIgKG1iZWhyaW5nKQ0KPiA+PiBDYzogQW5pbWEgV0cNCj4gPj4gU3ViamVj dDogUmU6IFtBbmltYV0gSS1EIEFjdGlvbjoNCj4gPmRyYWZ0LWJlaHJpbmdlci1hbmltYS1hdXRv bm9taWMtYWRkcmVzc2luZy0wMS50eHQNCj4gPj4NCj4gPj4NCj4gPj4gTWljaGFlbCBCZWhyaW5n ZXIgKG1iZWhyaW5nKSA8bWJlaHJpbmdAY2lzY28uY29tPiB3cm90ZToNCj4gPj4gICAgID4+ID4g SVB2NiBvbmx5OiBBdXRvbm9taWMgcHJvY2Vzc2VzIHNob3VsZCB1c2UgZXhjbHVzaXZlbHkgSVB2 NiwgZm9yDQo+ID4+ICAgICA+PiA+IHNpbXBsaWNpdHkgcmVhc29ucy4NCj4gPj4gICAgID4+DQo+ ID4+ICAgICA+PiBJIGFncmVlIHdpdGggdGhpcyBhcyBsb25nIGFzIGl0J3MgYW4gUkZDIDIxMTkg U0hPVUxELCBpLmUuDQo+ID4+IElQdjQgY291bGQNCj4gPmJlIHVzZWQgaW4NCj4gPj4gICAgID4+ IGV4dHJhb3JkaW5hcnkgY2lyY3Vtc3RhbmNlcy4gVGhlIEdETlAgZGVzaWduIGlzIGZ1bmRhbWVu dGFsbHkNCj4gPklQLXZlcnNpb24NCj4gPj4gICAgID4+IGluZGVwZW5kZW50Lg0KPiA+Pg0KPiA+ PiAgICAgPiBZZXMsIGFzIGxvbmcgYXMgaXQncyByZWFsbHkgImV4dHJhb3JkaW5hcnkiIDstKSAg IFRoYXQgMjExOSBzYXlzDQo+ID4+ICAgICA+ICJTSE9VTEQiIG1lYW5zIGxpa2UgeW91IG5lZWQg YSByZWFsbHkgZ29vZCByZWFzb24gdG8gbm90IGRvIGl0Lg0KPiA+V2hhdA0KPiA+PiAgICAgPiB3 b3VsZCBzdWNoIGEgZ29vZCByZWFzb24gYmU/IEp1c3Qgc2F5aW5nLCBpbiBvdXIgaW1wbGVtZW50 YXRpb24gd2UNCj4gPj4gICAgID4gb2Z0ZW4gZ2V0IHRoZSByZXF1aXJlbWVudCAid2Ugd2FudCBJ UHY0IiwgYW5kIHdoZW4geW91IGRpZywgdGhlDQo+ID5yZWFzb24NCj4gPj4gICAgID4gaXMgdGhh dCB0aGV5IGRvbid0IHdhbnQgdG8gZGVwbG95IElQdjYsIGFuZCB0aGF0J3MgdGhlIG9ubHkNCj4g Pj4gICAgID4gcmVhc29uLiBTbGlwcGVyeSBzbG9wZS4uLg0KPiA+Pg0KPiA+PiBhKSB0byByZXNw b25kIHRvIHRoZSBpbW1lZGlhdGUgIndlIHdhbnQgSVB2NCIgLS0tIEknZCBqdXN0IHRlbGwgdGhl DQo+IGN1c3RvbWVyDQo+ID4+ICAgIHRoYXQgaXQgdXNlcyBhIGN1c3RvbSBsaW5rIGxheWVyIHBy b3RvY29sIHRoYXQgdXNlcyBhbiBldGhlcm5ldCB0eXBlDQo+ID4+ICAgIGRpZmZlcmVudCB0aGFu IDB4MDgwMC4uLiBqdXN0IGxpa2UgQ0RQIGRvZXMgOi0pDQo+ID4+ICAgIChJIGRvbid0IHRoaW5r IHlvdSBuZWVkIHRvICJkZXBsb3kiIElQdjYgdG8gaGF2ZSBhbiBBQ1AuLi4pDQo+ID4+DQo+ID4+ IGIpIHRoZSBvbmx5IHRoaW5nIEkgY2FyZSBhYm91dCBpcyB0aGF0IG5vYm9keSBpcyBhbGxvd2Vk IHRvIHNheSwgImJ1dA0KPiA+PiAgICBtZWNoYW5pc20gWFlaIGRvZXMgbm90IGV4aXN0IGluIElQ djQiLiAgVGhhdCdzIGFsbC4gIEkgZG9uJ3Qga25vdyBpZg0KPiA+PiAgICB3ZSB3aWxsIG5lZWQg SVB2Ni1vbmx5IHRoaW5ncywgYnV0IG1heWJlLg0KPiA+Pg0KPiA+PiAuLi4NCj4gPj4NCj4gPj4g ICAgID4+IFVzZS1VTEE6IEZvciB0aGVzZSBvdmVybGF5IGFkZHJlc3NlcyBvZiBhdXRvbm9taWMg bm9kZXMsIHdlDQo+ID4+IHVzZQ0KPiA+VW5pcXVlDQo+ID4+ICAgICA+PiBMb2NhbCBBZGRyZXNz ZXMgKFVMQSksIGFzIHNwZWNpZmllZCBpbiBbUkZDNDE5M10uICBBbiBhbHRlcm5hdGl2ZQ0KPiA+ PiAgICAgPj4gc2NoZW1lIHdhcyBkaXNjdXNzZWQsIHVzaW5nIGFzc2lnbmVkIFVMQSBhZGRyZXNz aW5nLiAgVGhlDQo+ID5jb25zZW5zdXMNCj4gPj4gICAgID4+IHdhcyB0byB1c2Ugc3RhbmRhcmQg VUxBLCBiZWNhdXNlIGl0IHdhcyBkZWVtZWQgdG8gYmUgc3VmZmljaWVudC4NCj4gPj4NCj4gPj4g SXQgbWlnaHQgYmUgdGhhdCBVTEEgaXMgYW4gSVB2Ni1vbmx5IGZlYXR1cmUuDQo+ID4+IEkgZG9u J3QgY29uc2lkZXIgMTAvOCB0byBiZSB0aGUgc2FtZSwgYXMgaXQgaXMgbm90IHN0YXRpc3RpY2Fs bHkNCj4gPj4gdW5pcXVlIGluc2lkZQ0KPiA+dGhlIEFTLg0KPiA+Pg0KPiA+PiAtLQ0KPiA+PiBN aWNoYWVsIFJpY2hhcmRzb24gPG1jcitJRVRGQHNhbmRlbG1hbi5jYT4sIFNhbmRlbG1hbiBTb2Z0 d2FyZQ0KPiA+V29ya3MgIC09IElQdjYgSW9UIGNvbnN1bHRpbmcgPS0NCj4gPj4NCj4gPj4NCj4g Pj4NCj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPj4gQW5pbWEgbWFpbGluZyBsaXN0DQo+ID4+IEFuaW1hQGlldGYub3JnDQo+ID4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWENCj4gPj4gLg0KPiA+Pg0KPiA+ DQo+ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ QW5pbWEgbWFpbGluZyBsaXN0DQo+ID5BbmltYUBpZXRmLm9yZw0KPiA+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYQ0K From nobody Fri Jun 26 00:41:22 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B11141B34E8 for ; Fri, 26 Jun 2015 00:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQRIaE3rdE3g for ; Fri, 26 Jun 2015 00:41:18 -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 AFBB81B34E7 for ; Fri, 26 Jun 2015 00:41:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUK09810; Fri, 26 Jun 2015 07:41:16 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 26 Jun 2015 08:41:15 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.152]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Fri, 26 Jun 2015 15:41:07 +0800 From: Sheng Jiang To: "Michael Behringer (mbehring)" Thread-Topic: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft-behringer-anima-autonomic-addressing-01.txt Thread-Index: AQHQru7z1uF+rKGbAUuFV4RBjHzBhZ29OLOAgADCY8D//+BgAIAAiVig Date: Fri, 26 Jun 2015 07:41:06 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B925F55A6F4@nkgeml512-mbx.china.huawei.com> References: <20150618095520.3486.7068.idtracker@ietfa.amsl.com> <55876E20.2070508@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0FDC@xmb-rcd-x14.cisco.com> <21740.1435165907@sandelman.ca> <558C7343.9000802@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F55A5BB@nkgeml512-mbx.china.huawei.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF5CA2@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF5CA2@xmb-rcd-x14.cisco.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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Duzongpeng , Michael Richardson , "anima@ietf.org" Subject: Re: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft-behringer-anima-autonomic-addressing-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jun 2015 07:41:20 -0000 U28sIHlvdSBhcmUgc2F5aW5nIHdlIHNob3VsZCBuZXZlciBoYXZlIGEgSVB2NC1iYXNlZCBBdXRv bm9taWMgTmV0d29yaz8gSXQgbWF5IGJlIHdhc3RlIGlmIGFsbCBkZXZpY2VzIGhhdmUgYmVlbiBk dWFsLXN0YWNrIG9yIElQdjYtb25seS4gQnV0IGl0IHdvdWxkIHN0aWxsIGJlIGxvbmcgd2F5IHRv IGNvbWUuIEkgaGF2ZSBiZWVuIHdvcmtpbmcgb24gSVB2NiBzaW5jZSAyMDAxLiBBdCB0aGF0IHRp bWUsIHdlIHdlcmUgZXhwZWN0aW5nIElQdjQgbWlnaHQgYmUgdGVybWluYXRlZCBieSAyMDA2LiBU aGVyZSBhcmUgbmV3IGZlYXR1cmVzIHRoYXQgYXJlIGRldmVsb3BlZCB3aXRoIElQdjYsIGJ1dCBs YXRlciB0aGV5IGFyZSBhbHNvIGFkb3B0ZWQgaW50byBJUHY0LiBJbiBsYXN0IDIwIHllYXJzLCB0 aGUgdGVjaG5vbG9naWVzIGluIElQdjQgZGlkIG5vdCBzdG9wLiBJZiBBQ1Agb3Igb3RoZXIgQU4g ZnVuY3Rpb25zIGNhbiBiZSBpbmNyZW1lbnRhbGx5IGFkZGVkIGludG8gbGVnYWN5IElQdjQgZGV2 aWNlcywgaXQgd291bGQgbm90IGJlIGFueSBoYXJtIGZvciBvd25lcnMuIFNvLCB0aGF0IEFOIGlz IG5ldyBkb2VzIG5vdCBtZWFuIGl0IGNvdWxkIG5vdCB1c2UgaW4gSVB2NC4NCg0KRG9uJ3QgZ2V0 IG1lIHdyb25nLiBJIGFtIE5PVCBhcmd1aW5nIHRoYXQgd2UgIm11c3QiIGRvIHRoYXQuIEFnYWlu LCBhcyBJIHNhaWQsIHdlICJtYXkiIGRvIHRoYXQgd2l0aCBsb3cgcHJpb3JpdHkgd2hpbGUgSSBk b24ndCB0aGluayBpdCBoYXJtcy4gSWYgdGhlcmUgYXJlIGNsZWFybHkgcmVxdWlyZW1lbnRzIGZy b20gb3BlcmF0b3JzLCB3ZSBtYXkgcmlzZSB0aGUgIm1heSIgdG8gYmUgInNob3VsZCIuDQoNClJl Z2FyZHMsDQoNClNoZW5nDQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IE1p Y2hhZWwgQmVocmluZ2VyIChtYmVocmluZykgW21haWx0bzptYmVocmluZ0BjaXNjby5jb21dDQo+ U2VudDogRnJpZGF5LCBKdW5lIDI2LCAyMDE1IDM6MTQgUE0NCj5UbzogU2hlbmcgSmlhbmc7IEJy aWFuIEUgQ2FycGVudGVyOyBhbmltYUBpZXRmLm9yZzsgTWljaGFlbCBSaWNoYXJkc29uDQo+Q2M6 IER1em9uZ3BlbmcNCj5TdWJqZWN0OiBSRTogW0FuaW1hXSBXaGV0aGVyIElQdjYgb25seSBmb3Ig QUNQPyAvL1JFOiBJLUQgQWN0aW9uOg0KPmRyYWZ0LWJlaHJpbmdlci1hbmltYS1hdXRvbm9taWMt YWRkcmVzc2luZy0wMS50eHQNCj4NCj5TaGVuZzogV0hZPz8/IFdoeSB3b3VsZCB5b3Ugd2FudCBh biBJUHY0IGNvbnRyb2wgcGxhbmU/IElmIHlvdSBoYXZlIGENCj5nb29kIGFuc3dlciB0byB0aGF0 IHF1ZXN0aW9uLCB3ZSBjYW4gYXJndWUuIDotKQ0KPg0KPlRha2UgQkdQOiBJdCBjYW4gcnVuIG9u IGVpdGhlciB2NCBvciB2NiwgYW5kIGl0IGNhbiBuZWdvdGlhdGUgYW55IHByb3RvY29sDQo+dW5k ZXIgdGhlIHN1bi4gdGhlIGNvbnRyb2wgcGxhbmUgcHJvdG9jb2wgaGFzIGxpdHRsZSB0byBkbyB3 aXRoIHdoYXQgaXQNCj5uZWdvdGlhdGVzLg0KPg0KPlRha2UgSVNJUzogSXQncyBub3QgZXZlbiBJ UCEhDQo+DQo+T3RoZXIgV0dzIG1heSBoYXZlIGdvb2QgcmVhc29uczogRm9yIGV4YW1wbGU6IGlu dGVyZmFjaW5nIGVuZCBzeXN0ZW1zDQo+d2hlcmUgd2UgY2Fubm90IGV4cGVjdCBJUHY2IHN1cHBv cnQuIEFOIGlzIE5FVywgdGhlIEFOSSBpcyBORVcsIHRoZXJlIGlzIG5vDQo+bGVnYWN5Lg0KPg0K Pk1pY2hhZWwNCj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBTaGVu ZyBKaWFuZyBbbWFpbHRvOmppYW5nc2hlbmdAaHVhd2VpLmNvbV0NCj4+IFNlbnQ6IDI2IEp1bmUg MjAxNSAwMzozMg0KPj4gVG86IEJyaWFuIEUgQ2FycGVudGVyOyBhbmltYUBpZXRmLm9yZzsgTWlj aGFlbCBCZWhyaW5nZXIgKG1iZWhyaW5nKTsNCj4+IE1pY2hhZWwgUmljaGFyZHNvbg0KPj4gQ2M6 IER1em9uZ3BlbmcNCj4+IFN1YmplY3Q6IFJFOiBbQW5pbWFdIFdoZXRoZXIgSVB2NiBvbmx5IGZv ciBBQ1A/IC8vUkU6IEktRCBBY3Rpb246IGRyYWZ0LQ0KPj4gYmVocmluZ2VyLWFuaW1hLWF1dG9u b21pYy1hZGRyZXNzaW5nLTAxLnR4dA0KPj4NCj4+IEhpLCBCcmlhbiBhbmQgTWljaGFlbCBCLA0K Pj4NCj4+IEluIG15IHJlYWRpbmcsIGl0IHNlZW1zIHdlIHRha2UgYSB3cm9uZyBhcmd1bWVudCBo ZXJlLiBXaGF0IHdlIGFyZQ0KPj4gdGFsa2luZyBhYm91dCBpcyBOT1Qgc3RvcCBJUHY2LWJhc2Vk IEFDUC4gSXQgaXMgcmVtYWluaW5nIG9uIG91ciBwcmlvcml0eSBvcg0KPj4gZGVmYXVsdCBjaG9p Y2UuIFRlY2huaWNhbGx5LCBJIGFtIG5vdCBzdXJlIHRoZSBwb3NzaWJpbGl0eSBvciBmZWFzaWJp bGl0eSBJUA0KPj4gaW5kZXBlbmRlbnQuIElmIHllcywgSVAgaW5kZXBlbmRlbnQgbWF5IGJlIHBy ZWZlcnJlZCBvdmVyIElQdjYtb25seS4NCj4+DQo+PiBCdXQgbWVhbndoaWxlLCBhIHBhcmFsbGVs IElQdjQtYmFzZWQgQUNQIChvciBJUCBpbmRlcGVuZGVudCkgbWVjaGFuaXNtDQo+PiBzaG91bGQg bm90IGJyaW5nIGFueSBoYXJtLiBJUHY0IGJhc2VkIEludGVybmV0L25ldHdvcmtzIGFyZSBzdGls bCBoYXZpbmcgdGhlDQo+PiBtb3RpdmF0aW9uIHRvIGltcHJvdmUgaXRzZWxmLiBQYXJ0aWN1bGFy bHksIG1hbnkgY2xvc2VkIGVudGVycHJpc2UgbmV0d29ya3MNCj4+IG1hbnkgcmVtYWluIElQdjQt b25seSBmb3IgYSB3aGlsZS4gTWFueSBJRVRGIFdHLCBzdWNoIGFzIERIQywgYXJlDQo+d29ya2lu Zw0KPj4gb24gYm90aCBJUHY0IGFuZCBJUHY2IHNpbXVsdGFuZW91c2x5LCBvZiBjb3Vyc2UsIHdp dGggSVB2NCBpbiBsb3dlcg0KPj4gcHJlZmVyZW5jZSBhbmQgcHJpb3JpdHkuDQo+Pg0KPj4gIklQ djQgbWFuYWdlbWVudCIgdXNlIGNhc2UgZm9yIEFOLCBydW5uaW5nIG92ZXIgYW4gSVB2NiBBQ1Ag d291bGQgYWxzbw0KPj4gYmUgYW4gaW50ZXJlc3QgdXNlIGNhc2UuIEl0IGlzIHZhbHVhYmxlIGlu IHRoZSBkdWFsIHN0YWNrIG5ldHdvcmsgb3IgInJ1bm5pbmcNCj4+IElQdjQgYXMgYSBzZXJ2aWNl Ii4NCj4+DQo+PiBSZWdhcmRzLA0KPj4NCj4+IFNoZW5nDQo+Pg0KPj4gPi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+PiA+RnJvbTogQW5pbWEgW21haWx0bzphbmltYS1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgQnJpYW4gRQ0KPj4gPkNhcnBlbnRlcg0KPj4gPlNlbnQ6IEZyaWRh eSwgSnVuZSAyNiwgMjAxNSA1OjMyIEFNDQo+PiA+VG86IGFuaW1hQGlldGYub3JnDQo+PiA+U3Vi amVjdDogUmU6IFtBbmltYV0gV2hldGhlciBJUHY2IG9ubHkgZm9yIEFDUD8gLy9SRTogSS1EIEFj dGlvbjoNCj4+ID5kcmFmdC1iZWhyaW5nZXItYW5pbWEtYXV0b25vbWljLWFkZHJlc3NpbmctMDEu dHh0DQo+PiA+DQo+PiA+T24gMjUvMDYvMjAxNSAxNDowNiwgRHV6b25ncGVuZyB3cm90ZToNCj4+ ID4+IEhpLCBNaWNoYWVsIFJpY2hhcmRzb246DQo+PiA+Pg0KPj4gPj4gCUkgYWdyZWUgd2l0aCB5 b3VyIG9wdGlvbi4gUGVyaGFwcyBBQ1AgaXMgbm90IG5lZWRlZCB0byBiZSBJUHY2IG9ubHkuDQo+ PiA+DQo+PiA+SG93ZXZlciwgSVB2NiBoYXMgYW4gZW5vcm1vdXMgYWR2YW50YWdlIGluIGEgY29s ZCBzdGFydCB3aXRoIGFsbA0KPj4gPmRldmljZXMgYXNzdW1lZCBpbiBmYWN0b3J5IGNvbmRpdGlv bi4gRXZlcnkgSVB2NiBzdGFjayB3aWxsIGFjcXVpcmUgYQ0KPj4gPnZhbGlkIGxpbmstbG9jYWwg YWRkcmVzcyBldmVuIGlmIG5vIG90aGVyIGRldmljZSAoc3VjaCBhcyBhIHJvdXRlciBvcg0KPj4g PkRIQ1Agc2VydmVyKSBpcyBjb25maWd1cmVkIGFuZCB0aGVyZSBpcyBubyBJbnRlbnQgaW4gcGxh Y2UuIFRoYXQgaXMgd2hhdCB3ZQ0KPj4gbmVlZCBmb3IgYSB0cnVlIEFOLg0KPj4gPg0KPj4gPj4N Cj4+ID4+IAlPZiBjb3Vyc2UsIGFuIElQdjYgb25seSBhdXRvbm9taWMgY29udHJvbCBwbGFuZSBp cyBvayBmb3IgYWxsIHRoZQ0KPj4gPj4gc2VydmljZXMNCj4+ID5pbiBhdXRvbm9taWMgbmV0d29y aywgYW5kIHRoZSBzb2x1dGlvbiBoYXMgdGhlIGFkdmFudGFnZSBvZiBzaW1wbGljaXR5DQo+PiA+ YXMgbWVudGlvbmVkIGJ5IE1pY2hhZWwgQmVocmluZ2VyLg0KPj4gPj4NCj4+ID4+IAlIb3dldmVy LCB0aGUgbmV0d29yayBvcGVyYXRvciBtYXkgYmUgbW9yZSBmYW1pbGlhciB3aXRoIHRoZQ0KPj4g Pj4gSVB2NC1iYXNlDQo+PiA+bWFuYWdlbWVudC4NCj4+ID4NCj4+ID5JJ20gc29ycnkgYnV0IHN1 Y2ggb3BlcmF0b3JzIGFyZSBxdWlja2x5IGJlY29taW5nIGRpbm9zYXVycy4gTG9va2luZyBhdA0K Pj4gPnRoZSBjdXJyZW50IGdyb3d0aCByYXRlIG9mIElQdjYsIGFuZCBrbm93aW5nIHRoYXQgaXQg d2lsbCB0YWtlIHNldmVyYWwNCj4+ID55ZWFycyBmb3IgQW5pbWEgd29yayB0byBiZSBjb21wbGV0 ZSwgSSB0aGluayB0aG9zZSBvcGVyYXRvcnMgd2lsbCBiZSBpbg0KPj4gPnNlcmlvdXMgdHJvdWJs ZS4NCj4+ID4NCj4+ID4+IAlJbiB0aGUgYmVnaW5uaW5nIG9mIHRoZSBBQ1AgZGVwbG95bWVudCwg dGhlIG5ldHdvcmsgb3BlcmF0b3IgbWF5DQo+PiBub3QNCj4+ID5iZSB2ZXJ5IGNvbmZpZGVudCBh Ym91dCB0aGUgZGVjaXNpb25zIG1hZGUgYnkgdGhlIGF1dG9ub21pYyBuZXR3b3JrLg0KPj4gPlNv bWUga2luZHMgb2YgbW9uaXRvcmluZyBqb2JzIG1heSBiZSBkZXNpcmVkIGJ5IHRoZSBuZXR3b3Jr IG9wZXJhdG9ycy4NCj4+ID5BdCB0aGlzIHRpbWUsIHRoZSBvcGVyYXRvciBtYXkgd2FudCB0byBz ZWUgc29tZSBJUHY0IGFkZHJlc3Nlcy4NCj4+ID4NCj4+ID5UaGVpciB0cmFkaXRpb25hbCBOTVMg Y291bGQgc3RpbGwgYmUgSVB2NCwgYW5kIHRoZXkgY291bGQgc3RpbGwgc2VlDQo+PiA+SVB2NCBp bmZvcm1hdGlvbiB0aHJvdWdoIGFuIElQdjYgQUNQLg0KPj4gPg0KPj4gPj4gU28sIHBlcmhhcHMg d2UgbmVlZCB0byBwcm92aWRlIElQdjQtYmFzZWQgQUNQIGFzIGFuIG9wdGlvbiBmb3IgdGhlc2UN Cj4+ID4+IHBhcnRzDQo+PiA+b2Ygb3BlcmF0b3JzLiBPdGhlcndpc2UsIHdlIGNhbiBvbmx5IGFu c3dlciB0aGVtICJzb3JyeSwgd2Ugb25seQ0KPj4gPnN1cHBvcnQNCj4+ID5JUHY2IGhlcmUiLg0K Pj4gPg0KPj4gPk5vLCB0aGUgYW5zd2VyIGlzICJJUHY2IHdpbGwgYmUgZGVwbG95ZWQgYXV0b21h dGljYWxseSB3aXRoIG5vIHdvcmsgYnkNCj4+ID55b3UsIGJ1dCBvbGQgSVB2NCBzZXJ2aWNlcyB3 aWxsIG5vdCBiZSBpbnRlcnJ1cHRlZC4iDQo+PiA+DQo+PiA+QWN0dWFsbHkgd2Ugc2hvdWxkIHRo aW5rIGFib3V0IGFuICJJUHY0IG1hbmFnZW1lbnQiIHVzZSBjYXNlIGZvciBBTiwNCj4+ID5ydW5u aW5nIG92ZXIgYW4gSVB2NiBBQ1AuDQo+PiA+DQo+PiA+QmVzdCByZWdhcmRzLA0KPj4gPiAgIEJy aWFuDQo+PiA+DQo+PiA+Pg0KPj4gPj4gCUFzIElQdjQgaGFzIGJlZW4gd2lkZWx5IGRlcGxveWVk LCBwZXJoYXBzIGFuIElQdjQtYmFzZWQNCj4+IGF1dG9ub21pYw0KPj4gPm5ldHdvcmsgd2lsbCBi ZSBhY2NlcHRlZCBieSBtb3JlIG5ldHdvcmsgbWFuYWdlcnMgYXQgdGhlIGJlZ2lubmluZy4NCj4+ ID4+DQo+PiA+PiAJSW5kZWVkLCBhdCB0aGlzIHRpbWUsIGFuIElQdjQtYmFzZWQgQUNQIGlzIG5v dCBhcyBtYXR1cmUgYXMgdGhlIElQdjYNCj4+IG9uZS4NCj4+ID5UaHVzLCBwZXJoYXBzIHNvbWUg d29yayBuZWVkcyB0byBiZSBkb25lIGF0IHRoaXMgZGlyZWN0aW9uLiBGb3INCj4+ID5leGFtcGxl LCBhcyB5b3UgbWVudGlvbmVkLCBob3cgY2FuIHdlIGdldCBhbiBhZGRyZXNzIGluc3RlYWQgb2Yg dGhlIFVMQQ0KPj4gaW4gSVB2Ni4NCj4+ID4+DQo+PiA+PiBCZXN0IHJlZ2FyZHMNCj4+ID4+IFpv bmdwZW5nIER1DQo+PiA+Pg0KPj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+ IEZyb206IEFuaW1hIFttYWlsdG86YW5pbWEtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IE1pY2hhZWwNCj4+ID5SaWNoYXJkc29uDQo+PiA+PiBTZW50OiBUaHVyc2RheSwgSnVuZSAyNSwg MjAxNSAxOjEyIEFNDQo+PiA+PiBUbzogTWljaGFlbCBCZWhyaW5nZXIgKG1iZWhyaW5nKQ0KPj4g Pj4gQ2M6IEFuaW1hIFdHDQo+PiA+PiBTdWJqZWN0OiBSZTogW0FuaW1hXSBJLUQgQWN0aW9uOg0K Pj4gPmRyYWZ0LWJlaHJpbmdlci1hbmltYS1hdXRvbm9taWMtYWRkcmVzc2luZy0wMS50eHQNCj4+ ID4+DQo+PiA+Pg0KPj4gPj4gTWljaGFlbCBCZWhyaW5nZXIgKG1iZWhyaW5nKSA8bWJlaHJpbmdA Y2lzY28uY29tPiB3cm90ZToNCj4+ID4+ICAgICA+PiA+IElQdjYgb25seTogQXV0b25vbWljIHBy b2Nlc3NlcyBzaG91bGQgdXNlIGV4Y2x1c2l2ZWx5IElQdjYsDQo+Zm9yDQo+PiA+PiAgICAgPj4g PiBzaW1wbGljaXR5IHJlYXNvbnMuDQo+PiA+PiAgICAgPj4NCj4+ID4+ICAgICA+PiBJIGFncmVl IHdpdGggdGhpcyBhcyBsb25nIGFzIGl0J3MgYW4gUkZDIDIxMTkgU0hPVUxELCBpLmUuDQo+PiA+ PiBJUHY0IGNvdWxkDQo+PiA+YmUgdXNlZCBpbg0KPj4gPj4gICAgID4+IGV4dHJhb3JkaW5hcnkg Y2lyY3Vtc3RhbmNlcy4gVGhlIEdETlAgZGVzaWduIGlzIGZ1bmRhbWVudGFsbHkNCj4+ID5JUC12 ZXJzaW9uDQo+PiA+PiAgICAgPj4gaW5kZXBlbmRlbnQuDQo+PiA+Pg0KPj4gPj4gICAgID4gWWVz LCBhcyBsb25nIGFzIGl0J3MgcmVhbGx5ICJleHRyYW9yZGluYXJ5IiA7LSkgICBUaGF0IDIxMTkg c2F5cw0KPj4gPj4gICAgID4gIlNIT1VMRCIgbWVhbnMgbGlrZSB5b3UgbmVlZCBhIHJlYWxseSBn b29kIHJlYXNvbiB0byBub3QgZG8gaXQuDQo+PiA+V2hhdA0KPj4gPj4gICAgID4gd291bGQgc3Vj aCBhIGdvb2QgcmVhc29uIGJlPyBKdXN0IHNheWluZywgaW4gb3VyIGltcGxlbWVudGF0aW9uDQo+ d2UNCj4+ID4+ICAgICA+IG9mdGVuIGdldCB0aGUgcmVxdWlyZW1lbnQgIndlIHdhbnQgSVB2NCIs IGFuZCB3aGVuIHlvdSBkaWcsIHRoZQ0KPj4gPnJlYXNvbg0KPj4gPj4gICAgID4gaXMgdGhhdCB0 aGV5IGRvbid0IHdhbnQgdG8gZGVwbG95IElQdjYsIGFuZCB0aGF0J3MgdGhlIG9ubHkNCj4+ID4+ ICAgICA+IHJlYXNvbi4gU2xpcHBlcnkgc2xvcGUuLi4NCj4+ID4+DQo+PiA+PiBhKSB0byByZXNw b25kIHRvIHRoZSBpbW1lZGlhdGUgIndlIHdhbnQgSVB2NCIgLS0tIEknZCBqdXN0IHRlbGwgdGhl DQo+PiBjdXN0b21lcg0KPj4gPj4gICAgdGhhdCBpdCB1c2VzIGEgY3VzdG9tIGxpbmsgbGF5ZXIg cHJvdG9jb2wgdGhhdCB1c2VzIGFuIGV0aGVybmV0IHR5cGUNCj4+ID4+ICAgIGRpZmZlcmVudCB0 aGFuIDB4MDgwMC4uLiBqdXN0IGxpa2UgQ0RQIGRvZXMgOi0pDQo+PiA+PiAgICAoSSBkb24ndCB0 aGluayB5b3UgbmVlZCB0byAiZGVwbG95IiBJUHY2IHRvIGhhdmUgYW4gQUNQLi4uKQ0KPj4gPj4N Cj4+ID4+IGIpIHRoZSBvbmx5IHRoaW5nIEkgY2FyZSBhYm91dCBpcyB0aGF0IG5vYm9keSBpcyBh bGxvd2VkIHRvIHNheSwgImJ1dA0KPj4gPj4gICAgbWVjaGFuaXNtIFhZWiBkb2VzIG5vdCBleGlz dCBpbiBJUHY0Ii4gIFRoYXQncyBhbGwuICBJIGRvbid0IGtub3cgaWYNCj4+ID4+ICAgIHdlIHdp bGwgbmVlZCBJUHY2LW9ubHkgdGhpbmdzLCBidXQgbWF5YmUuDQo+PiA+Pg0KPj4gPj4gLi4uDQo+ PiA+Pg0KPj4gPj4gICAgID4+IFVzZS1VTEE6IEZvciB0aGVzZSBvdmVybGF5IGFkZHJlc3NlcyBv ZiBhdXRvbm9taWMgbm9kZXMsIHdlDQo+PiA+PiB1c2UNCj4+ID5VbmlxdWUNCj4+ID4+ICAgICA+ PiBMb2NhbCBBZGRyZXNzZXMgKFVMQSksIGFzIHNwZWNpZmllZCBpbiBbUkZDNDE5M10uICBBbg0K PmFsdGVybmF0aXZlDQo+PiA+PiAgICAgPj4gc2NoZW1lIHdhcyBkaXNjdXNzZWQsIHVzaW5nIGFz c2lnbmVkIFVMQSBhZGRyZXNzaW5nLiAgVGhlDQo+PiA+Y29uc2Vuc3VzDQo+PiA+PiAgICAgPj4g d2FzIHRvIHVzZSBzdGFuZGFyZCBVTEEsIGJlY2F1c2UgaXQgd2FzIGRlZW1lZCB0byBiZQ0KPnN1 ZmZpY2llbnQuDQo+PiA+Pg0KPj4gPj4gSXQgbWlnaHQgYmUgdGhhdCBVTEEgaXMgYW4gSVB2Ni1v bmx5IGZlYXR1cmUuDQo+PiA+PiBJIGRvbid0IGNvbnNpZGVyIDEwLzggdG8gYmUgdGhlIHNhbWUs IGFzIGl0IGlzIG5vdCBzdGF0aXN0aWNhbGx5DQo+PiA+PiB1bmlxdWUgaW5zaWRlDQo+PiA+dGhl IEFTLg0KPj4gPj4NCj4+ID4+IC0tDQo+PiA+PiBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitJRVRG QHNhbmRlbG1hbi5jYT4sIFNhbmRlbG1hbiBTb2Z0d2FyZQ0KPj4gPldvcmtzICAtPSBJUHY2IElv VCBjb25zdWx0aW5nID0tDQo+PiA+Pg0KPj4gPj4NCj4+ID4+DQo+PiA+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4gQW5pbWEgbWFpbGluZyBs aXN0DQo+PiA+PiBBbmltYUBpZXRmLm9yZw0KPj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9hbmltYQ0KPj4gPj4gLg0KPj4gPj4NCj4+ID4NCj4+ID5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPkFuaW1hIG1haWxpbmcg bGlzdA0KPj4gPkFuaW1hQGlldGYub3JnDQo+PiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9hbmltYQ0K From nobody Fri Jun 26 01:36:43 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5B91A01BA for ; Fri, 26 Jun 2015 01:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.588 X-Spam-Level: X-Spam-Status: No, score=-1.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpCBqn3y0PBJ for ; Fri, 26 Jun 2015 01:36:39 -0700 (PDT) Received: from webmail3.hi.local (www.outitgoes.com [79.170.40.67]) (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 D6DB51A01A9 for ; Fri, 26 Jun 2015 01:36:38 -0700 (PDT) Received: from localhost ([127.0.0.1]) by webmail3.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1Z8P7b-0000x6-Lp; Fri, 26 Jun 2015 09:36:27 +0100 Message-Id: From: "Jonathan Hansford" To: "Michael Behringer (mbehring)" , "Duzongpeng" , "Michael Richardson" X-Mailer: Atmail 6.6.0.11156 X-Originating-IP: 212.159.131.152 in-reply-to: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF47B1@xmb-rcd-x14.cisco.com> Date: Fri, 26 Jun 2015 09:36:27 +0100 Content-Type: multipart/alternative; boundary="=_892f74be6ccd6bc5f296d012722b7566" MIME-Version: 1.0 Archived-At: Cc: Anima WG Subject: Re: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft-behringer-anima-autonomic-addressing-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jun 2015 08:36:42 -0000 --=_892f74be6ccd6bc5f296d012722b7566 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There are some systems outside the Internet that have no urgent need=0At= o move to IPv6 and developers would rather focus on more urgent=0Aneeds.= =C2=A0Autonomic networking could well be one of those more urgent=0Anee= ds.=0AJonathan=0A=0A----- Original Message -----=0AFrom: "Michael Behrin= ger (mbehring)" =0ATo:"Duzongpeng" , "Michael Richardson" =0ACc:"Anima W= G" =0ASent:Thu, 25 Jun 2015 11:56:19 +0000=0ASubject:Re: [Anima] Whether= IPv6 only for ACP? //RE: I-D Action:=0Adraft-behringer-anima-autonomic-= addressing-01.txt=0A=0A For something new like AN, where the standardise= d specs will take at=0Aleast a couple of years to appear in anyone's pro= ducts, where we do=0ANOT have backward compatibility issues, where we do= not address end=0Asystems for some years to come, I personally think it= is insane to=0Aeven consider IPv4. =0A=0A But I think we do have agreem= ent that we start with IPv6 only, and=0Ajust keep the door open, in case= we need to support it. If the working=0Agroup wants to do that, I'll ch= ange the text accordingly. Maybe a=0Adiscussion for Prague? =0A=0A Micha= el=0A=0A > -----Original Message-----=0A > From: Duzongpeng [mailto:duzo= ngpeng@huawei.com]=0A > Sent: 25 June 2015 10:24=0A > To: Michael Behrin= ger (mbehring); Michael Richardson=0A > Cc: Anima WG=0A > Subject: RE: [= Anima] Whether IPv6 only for ACP? //RE: I-D Action:=0Adraft-=0A > behrin= ger-anima-autonomic-addressing-01.txt=0A > =0A > Hi, Michael Behringer= =0A > =0A > I agree that the default setting of the ACP could be IPv6-ba= sed,=0Awhich may=0A > make the communication across autonomic domains ea= sier to=0Aimplement.=0A > =0A > What I suggested is that we first have a= n IPv6-based ACP ready, and=0Adefine=0A > an IPv4-based one as an altern= ative option.=0A > =0A > Best regards=0A > Zongpeng Du=0A > =0A > -----O= riginal Message-----=0A > From: Anima [mailto:anima-bounces@ietf.org] On= Behalf Of Michael=0A > Behringer (mbehring)=0A > Sent: Thursday, June 2= 5, 2015 3:31 PM=0A > To: Duzongpeng; Michael Richardson=0A > Cc: Anima W= G=0A > Subject: Re: [Anima] Whether IPv6 only for ACP? //RE: I-D Action:= =0Adraft-=0A > behringer-anima-autonomic-addressing-01.txt=0A > =0A > Re= -reading my own message, one thing to add: Brian has already=0Astated th= at=0A > GDNP is protocol independent, and it should be. Of course we wan= t=0Ato=0A > develop everything IP version independent wherever possible.= =0A > =0A > But there has to be some default autonomic addressing, routi= ng, and=0Afor=0A > THAT we want to look at IPv6 only at this point.=0A >= =0A > Michael=0A > =0A > > -----Original Message-----=0A > > From: Anim= a [mailto:anima-bounces@ietf.org] On Behalf Of Michael=0A > > Behringer= (mbehring)=0A > > Sent: 25 June 2015 09:25=0A > > To: Duzongpeng; Micha= el Richardson=0A > > Cc: Anima WG=0A > > Subject: Re: [Anima] Whether IP= v6 only for ACP? //RE: I-D Action:=0A > > draft- behringer-anima-autonom= ic-addressing-01.txt=0A > >=0A > > OK, I think there is some confusion a= round this topic.=0A > >=0A > > A network with autonomic functions (we a= ll agree that a fully=0A > > autonomic network is not our main target fo= r now) can support on=0Athe=0A > > *data plane* any protocol the operato= r wants to use, including=0AIPv4,=0A > > appletalk and IPv8 (when it com= es).=0A > >=0A > > The statement is for the signalling, messaging and ot= her=0Aprotocols=0A > > INSIDE the ACP, used by Autonomic Service Agents.= =0A > >=0A > > Autonomic Service Agents will be exposed to a developer= =0Acommunity, and=0A > > the vendors implementing the ACP. There is abso= lutely no reason=0Ato=0A > > standardise more than one protocol for this= purpose.=0A > >=0A > > MichaelR is right: You don't need to actively de= ploy IPv6 to use=0Athe=0A > > ACP. It just happens. With one caveat: If= you connect an NMS=0Asystem=0A > > into the ACP for "virtual out of ban= d" usage, then that system=0Aneeds=0A > > to support IPv6. But that is t= ypically not a problem, in our=0Aexperience.=0A > >=0A > > In other word= s: We're saying that *autonomic functions* (which=0Athe end=0A > > user= isn't exposed to at all) are exclusively IPv6, but the=0Anetwork=0A > >= can provide any service the operator wants. Specifically, an=0Aautonomi= c=0A > > function (running on an IPv6 control plane) may well negotiate= =0A > > addressing for IPv4 services.=0A > >=0A > > Michael=0A > >=0A >= > > -----Original Message-----=0A > > > From: Duzongpeng [mailto:duzong= peng@huawei.com]=0A > > > Sent: 25 June 2015 04:06=0A > > > To: Michael= Richardson; Michael Behringer (mbehring)=0A > > > Cc: Anima WG=0A > > >= Subject: Whether IPv6 only for ACP? //RE: [Anima] I-D Action:=0Adraft-= =0A > > > behringer-anima-autonomic-addressing-01.txt=0A > > >=0A > > >= Hi, Michael Richardson:=0A > > >=0A > > > I agree with your option. Per= haps ACP is not needed to be IPv6=0Aonly.=0A > > >=0A > > > Of course, a= n IPv6 only autonomic control plane is ok for all=0Athe=0A > > > service= s in autonomic network, and the solution has the=0Aadvantage of=0A > > >= simplicity as mentioned by Michael Behringer.=0A > > >=0A > > > However= , the network operator may be more familiar with the=0AIPv4-=0A > > > ba= se management.=0A > > > In the beginning of the ACP deployment, the netw= ork operator=0Amay=0A > > not=0A > > > be very confident about the decis= ions made by the autonomic=0Anetwork.=0A > > > Some kinds of monitoring= jobs may be desired by the network=0Aoperators.=0A > > > At this time,= the operator may want to see some IPv4 addresses.=0ASo,=0A > > > perhap= s we need to provide IPv4-based ACP as an option for=0Athese=0A > > > pa= rts of operators. Otherwise, we can only answer them "sorry,=0Awe=0A > >= > only support=0A > > > IPv6 here".=0A > > >=0A > > > As IPv4 has been= widely deployed, perhaps an IPv4-based=0A > > autonomic=0A > > > networ= k will be accepted by more network managers at the=0Abeginning.=0A > > >= =0A > > > Indeed, at this time, an IPv4-based ACP is not as mature as th= e=0A > > > IPv6 one. Thus, perhaps some work needs to be done at this=0A= > > > direction. For example, as you mentioned, how can we get an=0Aadd= ress=0A > > > instead of the ULA in IPv6.=0A > > >=0A > > > Best regards= =0A > > > Zongpeng Du=0A > > >=0A > > > -----Original Message-----=0A >= > > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of=0AMichael= =0A > > > Richardson=0A > > > Sent: Thursday, June 25, 2015 1:12 AM=0A >= > > To: Michael Behringer (mbehring)=0A > > > Cc: Anima WG=0A > > > Sub= ject: Re: [Anima] I-D Action:=0Adraft-behringer-anima-autonomic-=0A > >= > addressing-01.txt=0A > > >=0A > > >=0A > > > Michael Behringer (mbehr= ing) wrote:=0A > > > >> > IPv6 only: Autonomic processes should use exc= lusively=0AIPv6, for=0A > > > >> > simplicity reasons.=0A > > > >>=0A >= > > >> I agree with this as long as it's an RFC 2119 SHOULD, i.e.=0A >= > > IPv4 could be used in=0A > > > >> extraordinary circumstances. The= GDNP design is=0Afundamentally=0A > > > IP- version=0A > > > >> indepen= dent.=0A > > >=0A > > > > Yes, as long as it's really "extraordinary" ;-= ) That 2119=0Asays=0A > > > > "SHOULD" means like you need a really good= reason to not do=0Ait.=0A > What=0A > > > > would such a good reason be= ? Just saying, in our=0Aimplementation we=0A > > > > often get the requi= rement "we want IPv4", and when you dig,=0A > > > the reason=0A > > > >= is that they don't want to deploy IPv6, and that's the only=0A > > > >= reason. Slippery slope...=0A > --=_892f74be6ccd6bc5f296d012722b7566 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There are some systems outside the Internet tha= t have no urgent need to move to IPv6 and developers would rather focus= on more urgent needs. =C2=A0Autonomic networking could well be one of t= hose more urgent needs.

Jonathan


<= blockquote>
----- Original Message -----
From:=
"Michael Behringer (mbehring)" <mbehring@cisco.com>
To:
"Duzongpeng" <duzongpen= g@huawei.com>, "Michael Richardson" <mcr+ietf@sandelman.ca>
Cc:
"Anima WG" <anima@ietf.o= rg>
Sent:
Thu, 25 Jun 2015= 11:56:19 +0000
Subject:
Re:= [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft-behringer-an= ima-autonomic-addressing-01.txt


=0AFor something new li= ke AN, where the standardised specs will take at least a couple of years= to appear in anyone's products, where we do NOT have backward compatibi= lity issues, where we do not address end systems for some years to come,= I personally think it is insane to even consider IPv4.

=0AB= ut I think we do have agreement that we start with IPv6 only, and just k= eep the door open, in case we need to support it. If the working group w= ants to do that, I'll change the text accordingly. Maybe a discussion fo= r Prague?

=0AMichael

=0A> -----Original Messag= e-----
=0A> From: Duzongpeng [mailto:duzongpeng@huawei.com]
=0A> Sent: 25 June 2015 10:24
=0A> To: Michael Behringer (mb= ehring); Michael Richardson
=0A> Cc: Anima WG
=0A> Subje= ct: RE: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft-
=0A> behringer-anima-autonomic-addressing-01.txt
=0A>
= =0A> Hi, Michael Behringer
=0A>
=0A> I agree that th= e default setting of the ACP could be IPv6-based, which may
=0A>= make the communication across autonomic domains easier to implement.=0A>
=0A> What I suggested is that we first have an IPv6-= based ACP ready, and define
=0A> an IPv4-based one as an alterna= tive option.
=0A>
=0A> Best regards
=0A> Zongpe= ng Du
=0A>
=0A> -----Original Message-----
=0A>= From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael
= =0A> Behringer (mbehring)
=0A> Sent: Thursday, June 25, 2015= 3:31 PM
=0A> To: Duzongpeng; Michael Richardson
=0A> Cc= : Anima WG
=0A> Subject: Re: [Anima] Whether IPv6 only for ACP?= //RE: I-D Action: draft-
=0A> behringer-anima-autonomic-address= ing-01.txt
=0A>
=0A> Re-reading my own message, one thi= ng to add: Brian has already stated that
=0A> GDNP is protocol i= ndependent, and it should be. Of course we want to
=0A> develop= everything IP version independent wherever possible.
=0A>
=0A> But there has to be some default autonomic addressing, routing,= and for
=0A> THAT we want to look at IPv6 only at this point.=0A>
=0A> Michael
=0A>
=0A> > -----O= riginal Message-----
=0A> > From: Anima [mailto:anima-bounces= @ietf.org] On Behalf Of Michael
=0A> > Behringer (mbehring)=0A> > Sent: 25 June 2015 09:25
=0A> > To: Duzongpe= ng; Michael Richardson
=0A> > Cc: Anima WG
=0A> >= Subject: Re: [Anima] Whether IPv6 only for ACP? //RE: I-D Action:
= =0A> > draft- behringer-anima-autonomic-addressing-01.txt
=0A= > >
=0A> > OK, I think there is some confusion around t= his topic.
=0A> >
=0A> > A network with autonomic= functions (we all agree that a fully
=0A> > autonomic networ= k is not our main target for now) can support on the
=0A> > *= data plane* any protocol the operator wants to use, including IPv4,
=0A> > appletalk and IPv8 (when it comes).
=0A> >
=0A> > The statement is for the signalling, messaging and other p= rotocols
=0A> > INSIDE the ACP, used by Autonomic Service Age= nts.
=0A> >
=0A> > Autonomic Service Agents will b= e exposed to a developer community, and
=0A> > the vendors im= plementing the ACP. There is absolutely no reason to
=0A> > s= tandardise more than one protocol for this purpose.
=0A> >=0A> > MichaelR is right: You don't need to actively deploy IPv= 6 to use the
=0A> > ACP. It just happens. With one caveat: If= you connect an NMS system
=0A> > into the ACP for "virtual o= ut of band" usage, then that system needs
=0A> > to support I= Pv6. But that is typically not a problem, in our experience.
=0A>= ; >
=0A> > In other words: We're saying that *autonomic fu= nctions* (which the end
=0A> > user isn't exposed to at all)= are exclusively IPv6, but the network
=0A> > can provide any= service the operator wants. Specifically, an autonomic
=0A> >= ; function (running on an IPv6 control plane) may well negotiate
= =0A> > addressing for IPv4 services.
=0A> >
=0A>= ; > Michael
=0A> >
=0A> > > -----Original Me= ssage-----
=0A> > > From: Duzongpeng [mailto:duzongpeng@hu= awei.com]
=0A> > > Sent: 25 June 2015 04:06
=0A> &= gt; > To: Michael Richardson; Michael Behringer (mbehring)
=0A&g= t; > > Cc: Anima WG
=0A> > > Subject: Whether IPv6 o= nly for ACP? //RE: [Anima] I-D Action: draft-
=0A> > > beh= ringer-anima-autonomic-addressing-01.txt
=0A> > >
=0A= > > > Hi, Michael Richardson:
=0A> > >
=0A&g= t; > > =09I agree with your option. Perhaps ACP is not needed to b= e IPv6 only.
=0A> > >
=0A> > > =09Of course,= an IPv6 only autonomic control plane is ok for all the
=0A> >= ; > services in autonomic network, and the solution has the advantage= of
=0A> > > simplicity as mentioned by Michael Behringer.=
=0A> > >
=0A> > > =09However, the network o= perator may be more familiar with the IPv4-
=0A> > > base= management.
=0A> > > =09In the beginning of the ACP deplo= yment, the network operator may
=0A> > not
=0A> >= > be very confident about the decisions made by the autonomic networ= k.
=0A> > > Some kinds of monitoring jobs may be desired b= y the network operators.
=0A> > > At this time, the operat= or may want to see some IPv4 addresses. So,
=0A> > > perha= ps we need to provide IPv4-based ACP as an option for these
=0A>= > > parts of operators. Otherwise, we can only answer them "sorry= , we
=0A> > > only support
=0A> > > IPv6 her= e".
=0A> > >
=0A> > > =09As IPv4 has been wi= dely deployed, perhaps an IPv4-based
=0A> > autonomic
= =0A> > > network will be accepted by more network managers at t= he beginning.
=0A> > >
=0A> > > =09Indeed, a= t this time, an IPv4-based ACP is not as mature as the
=0A> >= > IPv6 one. Thus, perhaps some work needs to be done at this
= =0A> > > direction. For example, as you mentioned, how can we g= et an address
=0A> > > instead of the ULA in IPv6.
= =0A> > >
=0A> > > Best regards
=0A> >= > Zongpeng Du
=0A> > >
=0A> > > -----Ori= ginal Message-----
=0A> > > From: Anima [mailto:anima-boun= ces@ietf.org] On Behalf Of Michael
=0A> > > Richardson=0A> > > Sent: Thursday, June 25, 2015 1:12 AM
=0A>= > > To: Michael Behringer (mbehring)
=0A> > > Cc: A= nima WG
=0A> > > Subject: Re: [Anima] I-D Action: draft-be= hringer-anima-autonomic-
=0A> > > addressing-01.txt
= =0A> > >
=0A> > >
=0A> > > Michael= Behringer (mbehring) <mbehring@cisco.com> wrote:
=0A> >= ; > >> > IPv6 only: Autonomic processes should use exclu= sively IPv6, for
=0A> > > >> > simplicity rea= sons.
=0A> > > >>
=0A> > > >= ;> I agree with this as long as it's an RFC 2119 SHOULD, i.e.
= =0A> > > IPv4 could be used in
=0A> > > >&= gt; extraordinary circumstances. The GDNP design is fundamentally
= =0A> > > IP- version
=0A> > > >> indepe= ndent.
=0A> > >
=0A> > > > Yes, as lo= ng as it's really "extraordinary" ;-) That 2119 says
=0A> >= > > "SHOULD" means like you need a really good reason to not= do it.
=0A> What
=0A> > > > would such a g= ood reason be? Just saying, in our implementation we
=0A> > &= gt; > often get the requirement "we want IPv4", and when you dig,=
=0A> > > the reason
=0A> > > > is th= at they don't want to deploy IPv6, and that's the only
=0A> >= > > reason. Slippery slope...
=0A&gt --=_892f74be6ccd6bc5f296d012722b7566-- From nobody Fri Jun 26 01:39:09 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D22C1A0233 for ; Fri, 26 Jun 2015 01:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.588 X-Spam-Level: X-Spam-Status: No, score=-1.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkwWxpK-_5l7 for ; Fri, 26 Jun 2015 01:39:04 -0700 (PDT) Received: from webmail3.hi.local (www.outitgoes.com [79.170.40.67]) (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 4C7D71A0218 for ; Fri, 26 Jun 2015 01:39:04 -0700 (PDT) Received: from localhost ([127.0.0.1]) by webmail3.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1Z8PA1-00018K-JE; Fri, 26 Jun 2015 09:38:57 +0100 Message-Id: From: "Jonathan Hansford" To: "Michael Behringer (mbehring)" , "Duzongpeng" , "Michael Richardson" X-Mailer: Atmail 6.6.0.11156 X-Originating-IP: 212.159.131.152 in-reply-to: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF47B1@xmb-rcd-x14.cisco.com> Date: Fri, 26 Jun 2015 09:38:57 +0100 Content-Type: multipart/alternative; boundary="=_48afb362d8846ecc027de0b29c5e03c9" MIME-Version: 1.0 Archived-At: Cc: Anima WG Subject: Re: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft-behringer-anima-autonomic-addressing-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jun 2015 08:39:07 -0000 --=_48afb362d8846ecc027de0b29c5e03c9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There are some systems outside the Internet that have no urgent need=0At= o move to IPv6 and developers would rather focus on more urgent=0Aneeds.= =C2=A0Autonomic networking could well be one of those more urgent=0Anee= ds.=0AJonathan=0A=0A----- Original Message -----=0AFrom: "Michael Behrin= ger (mbehring)" =0ATo:"Duzongpeng" , "Michael Richardson" =0ACc:"Anima W= G" =0ASent:Thu, 25 Jun 2015 11:56:19 +0000=0ASubject:Re: [Anima] Whether= IPv6 only for ACP? //RE: I-D Action:=0Adraft-behringer-anima-autonomic-= addressing-01.txt=0A=0A For something new like AN, where the standardise= d specs will take at=0Aleast a couple of years to appear in anyone's pro= ducts, where we do=0ANOT have backward compatibility issues, where we do= not address end=0Asystems for some years to come, I personally think it= is insane to=0Aeven consider IPv4. =0A=0A But I think we do have agreem= ent that we start with IPv6 only, and=0Ajust keep the door open, in case= we need to support it. If the working=0Agroup wants to do that, I'll ch= ange the text accordingly. Maybe a=0Adiscussion for Prague? =0A=0A Micha= el=0A=0A > -----Original Message-----=0A > From: Duzongpeng [mailto:duzo= ngpeng@huawei.com]=0A > Sent: 25 June 2015 10:24=0A > To: Michael Behrin= ger (mbehring); Michael Richardson=0A > Cc: Anima WG=0A > Subject: RE: [= Anima] Whether IPv6 only for ACP? //RE: I-D Action:=0Adraft-=0A > behrin= ger-anima-autonomic-addressing-01.txt=0A > =0A > Hi, Michael Behringer= =0A > =0A > I agree that the default setting of the ACP could be IPv6-ba= sed,=0Awhich may=0A > make the communication across autonomic domains ea= sier to=0Aimplement.=0A > =0A > What I suggested is that we first have a= n IPv6-based ACP ready, and=0Adefine=0A > an IPv4-based one as an altern= ative option.=0A > =0A > Best regards=0A > Zongpeng Du=0A > =0A > -----O= riginal Message-----=0A > From: Anima [mailto:anima-bounces@ietf.org] On= Behalf Of Michael=0A > Behringer (mbehring)=0A > Sent: Thursday, June 2= 5, 2015 3:31 PM=0A > To: Duzongpeng; Michael Richardson=0A > Cc: Anima W= G=0A > Subject: Re: [Anima] Whether IPv6 only for ACP? //RE: I-D Action:= =0Adraft-=0A > behringer-anima-autonomic-addressing-01.txt=0A > =0A > Re= -reading my own message, one thing to add: Brian has already=0Astated th= at=0A > GDNP is protocol independent, and it should be. Of course we wan= t=0Ato=0A > develop everything IP version independent wherever possible.= =0A > =0A > But there has to be some default autonomic addressing, routi= ng, and=0Afor=0A > THAT we want to look at IPv6 only at this point.=0A >= =0A > Michael=0A > =0A > > -----Original Message-----=0A > > From: Anim= a [mailto:anima-bounces@ietf.org] On Behalf Of Michael=0A > > Behringer= (mbehring)=0A > > Sent: 25 June 2015 09:25=0A > > To: Duzongpeng; Micha= el Richardson=0A > > Cc: Anima WG=0A > > Subject: Re: [Anima] Whether IP= v6 only for ACP? //RE: I-D Action:=0A > > draft- behringer-anima-autonom= ic-addressing-01.txt=0A > >=0A > > OK, I think there is some confusion a= round this topic.=0A > >=0A > > A network with autonomic functions (we a= ll agree that a fully=0A > > autonomic network is not our main target fo= r now) can support on=0Athe=0A > > *data plane* any protocol the operato= r wants to use, including=0AIPv4,=0A > > appletalk and IPv8 (when it com= es).=0A > >=0A > > The statement is for the signalling, messaging and ot= her=0Aprotocols=0A > > INSIDE the ACP, used by Autonomic Service Agents.= =0A > >=0A > > Autonomic Service Agents will be exposed to a developer= =0Acommunity, and=0A > > the vendors implementing the ACP. There is abso= lutely no reason=0Ato=0A > > standardise more than one protocol for this= purpose.=0A > >=0A > > MichaelR is right: You don't need to actively de= ploy IPv6 to use=0Athe=0A > > ACP. It just happens. With one caveat: If= you connect an NMS=0Asystem=0A > > into the ACP for "virtual out of ban= d" usage, then that system=0Aneeds=0A > > to support IPv6. But that is t= ypically not a problem, in our=0Aexperience.=0A > >=0A > > In other word= s: We're saying that *autonomic functions* (which=0Athe end=0A > > user= isn't exposed to at all) are exclusively IPv6, but the=0Anetwork=0A > >= can provide any service the operator wants. Specifically, an=0Aautonomi= c=0A > > function (running on an IPv6 control plane) may well negotiate= =0A > > addressing for IPv4 services.=0A > >=0A > > Michael=0A > >=0A >= > > -----Original Message-----=0A > > > From: Duzongpeng [mailto:duzong= peng@huawei.com]=0A > > > Sent: 25 June 2015 04:06=0A > > > To: Michael= Richardson; Michael Behringer (mbehring)=0A > > > Cc: Anima WG=0A > > >= Subject: Whether IPv6 only for ACP? //RE: [Anima] I-D Action:=0Adraft-= =0A > > > behringer-anima-autonomic-addressing-01.txt=0A > > >=0A > > >= Hi, Michael Richardson:=0A > > >=0A > > > I agree with your option. Per= haps ACP is not needed to be IPv6=0Aonly.=0A > > >=0A > > > Of course, a= n IPv6 only autonomic control plane is ok for all=0Athe=0A > > > service= s in autonomic network, and the solution has the=0Aadvantage of=0A > > >= simplicity as mentioned by Michael Behringer.=0A > > >=0A > > > However= , the network operator may be more familiar with the=0AIPv4-=0A > > > ba= se management.=0A > > > In the beginning of the ACP deployment, the netw= ork operator=0Amay=0A > > not=0A > > > be very confident about the decis= ions made by the autonomic=0Anetwork.=0A > > > Some kinds of monitoring= jobs may be desired by the network=0Aoperators.=0A > > > At this time,= the operator may want to see some IPv4 addresses.=0ASo,=0A > > > perhap= s we need to provide IPv4-based ACP as an option for=0Athese=0A > > > pa= rts of operators. Otherwise, we can only answer them "sorry,=0Awe=0A > >= > only support=0A > > > IPv6 here".=0A > > >=0A > > > As IPv4 has been= widely deployed, perhaps an IPv4-based=0A > > autonomic=0A > > > networ= k will be accepted by more network managers at the=0Abeginning.=0A > > >= =0A > > > Indeed, at this time, an IPv4-based ACP is not as mature as th= e=0A > > > IPv6 one. Thus, perhaps some work needs to be done at this=0A= > > > direction. For example, as you mentioned, how can we get an=0Aadd= ress=0A > > > instead of the ULA in IPv6.=0A > > >=0A > > > Best regards= =0A > > > Zongpeng Du=0A > > >=0A > > > -----Original Message-----=0A >= > > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of=0AMichael= =0A > > > Richardson=0A > > > Sent: Thursday, June 25, 2015 1:12 AM=0A >= > > To: Michael Behringer (mbehring)=0A > > > Cc: Anima WG=0A > > > Sub= ject: Re: [Anima] I-D Action:=0Adraft-behringer-anima-autonomic-=0A > >= > addressing-01.txt=0A > > >=0A > > >=0A > > > Michael Behringer (mbehr= ing) wrote:=0A > > > >> > IPv6 only: Autonomic processes should use exc= lusively=0AIPv6, for=0A > > > >> > simplicity reasons.=0A > > > >>=0A >= > > >> I agree with this as long as it's an RFC 2119 SHOULD, i.e.=0A >= > > IPv4 could be used in=0A > > > >> extraordinary circumstances. The= GDNP design is=0Afundamentally=0A > > > IP- version=0A > > > >> indepen= dent.=0A > > >=0A > > > > Yes, as long as it's really "extraordinary" ;-= ) That 2119=0Asays=0A > > > > "SHOULD" means like you need a really good= reason to not do=0Ait.=0A > What=0A > > > > would such a good reason be= ? Just saying, in our=0Aimplementation we=0A > > > > often get the requi= rement "we want IPv4", and when you dig,=0A > > > the reason=0A > > > >= is that they don't want to deploy IPv6, and that's the only=0A > > > >= reason. Slippery slope...=0A > > >=0A > > > a) to respond to the immedi= ate "we want IPv4" --- I'd just tell=0Athe=0A > > customer=0A > > > that= it uses a custom link layer protocol that uses an ethernet=0Atype=0A >= > > different than 0x0800... just like CDP does :-)=0A > > > (I don't t= hink you need to "deploy" IPv6 to have an ACP...)=0A > > >=0A > > > b) t= he only thing I care about is that nobody is allowed to=0Asay, "but=0A >= > > mechanism XYZ does not exist in IPv4". That's all. I don't know=0Ai= f=0A > > > we will need IPv6-only things, but maybe.=0A > > >=0A > > > .= .=0A > > >=0A > > > >> Use-ULA: For these overlay addresses of autonomi= c nodes, we=0A > > > use Unique=0A > > > >> Local Addresses (ULA), as sp= ecified in [RFC4193]. An=0Aalternative=0A > > > >> scheme was discussed,= using assigned ULA addressing. The=0A > > consensus=0A > > > >> was to= use standard ULA, because it was deemed to be=0Asufficient.=0A > > >=0A= > > > It might be that ULA is an IPv6-only feature.=0A > > > I don't co= nsider 10/8 to be the same, as it is not=0Astatistically=0A > > > unique= inside the AS.=0A > > >=0A > > > --=0A > > > Michael Richardson , Sande= lman Software=0A > > Works=0A > > > -=3D IPv6 IoT consulting =3D-=0A > >= >=0A > > >=0A > >=0A > > ______________________________________________= _=0A > > Anima mailing list=0A > > Anima@ietf.org=0A > > https://www.iet= f.org/mailman/listinfo/anima=0A > =0A > ________________________________= _______________=0A > Anima mailing list=0A > Anima@ietf.org=0A > https:/= /www.ietf.org/mailman/listinfo/anima=0A=0A _____________________________= __________________=0A Anima mailing list=0A Anima@ietf.org=0A https://ww= w.ietf.org/mailman/listinfo/anima=0A --=_48afb362d8846ecc027de0b29c5e03c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There are some systems outside the Internet tha= t have no urgent need to move to IPv6 and developers would rather focus= on more urgent needs. =C2=A0Autonomic networking could well be one of t= hose more urgent needs.

Jonathan


<= blockquote>
----- Original Message -----
From:=
"Michael Behringer (mbehring)" <mbehring@cisco.com>
To:
"Duzongpeng" <duzongpen= g@huawei.com>, "Michael Richardson" <mcr+ietf@sandelman.ca>
Cc:
"Anima WG" <anima@ietf.o= rg>
Sent:
Thu, 25 Jun 2015= 11:56:19 +0000
Subject:
Re:= [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft-behringer-an= ima-autonomic-addressing-01.txt


=0AFor something new li= ke AN, where the standardised specs will take at least a couple of years= to appear in anyone's products, where we do NOT have backward compatibi= lity issues, where we do not address end systems for some years to come,= I personally think it is insane to even consider IPv4.

=0AB= ut I think we do have agreement that we start with IPv6 only, and just k= eep the door open, in case we need to support it. If the working group w= ants to do that, I'll change the text accordingly. Maybe a discussion fo= r Prague?

=0AMichael

=0A> -----Original Messag= e-----
=0A> From: Duzongpeng [mailto:duzongpeng@huawei.com]
=0A> Sent: 25 June 2015 10:24
=0A> To: Michael Behringer (mb= ehring); Michael Richardson
=0A> Cc: Anima WG
=0A> Subje= ct: RE: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft-
=0A> behringer-anima-autonomic-addressing-01.txt
=0A>
= =0A> Hi, Michael Behringer
=0A>
=0A> I agree that th= e default setting of the ACP could be IPv6-based, which may
=0A>= make the communication across autonomic domains easier to implement.=0A>
=0A> What I suggested is that we first have an IPv6-= based ACP ready, and define
=0A> an IPv4-based one as an alterna= tive option.
=0A>
=0A> Best regards
=0A> Zongpe= ng Du
=0A>
=0A> -----Original Message-----
=0A>= From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael
= =0A> Behringer (mbehring)
=0A> Sent: Thursday, June 25, 2015= 3:31 PM
=0A> To: Duzongpeng; Michael Richardson
=0A> Cc= : Anima WG
=0A> Subject: Re: [Anima] Whether IPv6 only for ACP?= //RE: I-D Action: draft-
=0A> behringer-anima-autonomic-address= ing-01.txt
=0A>
=0A> Re-reading my own message, one thi= ng to add: Brian has already stated that
=0A> GDNP is protocol i= ndependent, and it should be. Of course we want to
=0A> develop= everything IP version independent wherever possible.
=0A>
=0A> But there has to be some default autonomic addressing, routing,= and for
=0A> THAT we want to look at IPv6 only at this point.=0A>
=0A> Michael
=0A>
=0A> > -----O= riginal Message-----
=0A> > From: Anima [mailto:anima-bounces= @ietf.org] On Behalf Of Michael
=0A> > Behringer (mbehring)=0A> > Sent: 25 June 2015 09:25
=0A> > To: Duzongpe= ng; Michael Richardson
=0A> > Cc: Anima WG
=0A> >= Subject: Re: [Anima] Whether IPv6 only for ACP? //RE: I-D Action:
= =0A> > draft- behringer-anima-autonomic-addressing-01.txt
=0A= > >
=0A> > OK, I think there is some confusion around t= his topic.
=0A> >
=0A> > A network with autonomic= functions (we all agree that a fully
=0A> > autonomic networ= k is not our main target for now) can support on the
=0A> > *= data plane* any protocol the operator wants to use, including IPv4,
=0A> > appletalk and IPv8 (when it comes).
=0A> >
=0A> > The statement is for the signalling, messaging and other p= rotocols
=0A> > INSIDE the ACP, used by Autonomic Service Age= nts.
=0A> >
=0A> > Autonomic Service Agents will b= e exposed to a developer community, and
=0A> > the vendors im= plementing the ACP. There is absolutely no reason to
=0A> > s= tandardise more than one protocol for this purpose.
=0A> >=0A> > MichaelR is right: You don't need to actively deploy IPv= 6 to use the
=0A> > ACP. It just happens. With one caveat: If= you connect an NMS system
=0A> > into the ACP for "virtual o= ut of band" usage, then that system needs
=0A> > to support I= Pv6. But that is typically not a problem, in our experience.
=0A>= ; >
=0A> > In other words: We're saying that *autonomic fu= nctions* (which the end
=0A> > user isn't exposed to at all)= are exclusively IPv6, but the network
=0A> > can provide any= service the operator wants. Specifically, an autonomic
=0A> >= ; function (running on an IPv6 control plane) may well negotiate
= =0A> > addressing for IPv4 services.
=0A> >
=0A>= ; > Michael
=0A> >
=0A> > > -----Original Me= ssage-----
=0A> > > From: Duzongpeng [mailto:duzongpeng@hu= awei.com]
=0A> > > Sent: 25 June 2015 04:06
=0A> &= gt; > To: Michael Richardson; Michael Behringer (mbehring)
=0A&g= t; > > Cc: Anima WG
=0A> > > Subject: Whether IPv6 o= nly for ACP? //RE: [Anima] I-D Action: draft-
=0A> > > beh= ringer-anima-autonomic-addressing-01.txt
=0A> > >
=0A= > > > Hi, Michael Richardson:
=0A> > >
=0A&g= t; > > =09I agree with your option. Perhaps ACP is not needed to b= e IPv6 only.
=0A> > >
=0A> > > =09Of course,= an IPv6 only autonomic control plane is ok for all the
=0A> >= ; > services in autonomic network, and the solution has the advantage= of
=0A> > > simplicity as mentioned by Michael Behringer.=
=0A> > >
=0A> > > =09However, the network o= perator may be more familiar with the IPv4-
=0A> > > base= management.
=0A> > > =09In the beginning of the ACP deplo= yment, the network operator may
=0A> > not
=0A> >= > be very confident about the decisions made by the autonomic networ= k.
=0A> > > Some kinds of monitoring jobs may be desired b= y the network operators.
=0A> > > At this time, the operat= or may want to see some IPv4 addresses. So,
=0A> > > perha= ps we need to provide IPv4-based ACP as an option for these
=0A>= > > parts of operators. Otherwise, we can only answer them "sorry= , we
=0A> > > only support
=0A> > > IPv6 her= e".
=0A> > >
=0A> > > =09As IPv4 has been wi= dely deployed, perhaps an IPv4-based
=0A> > autonomic
= =0A> > > network will be accepted by more network managers at t= he beginning.
=0A> > >
=0A> > > =09Indeed, a= t this time, an IPv4-based ACP is not as mature as the
=0A> >= > IPv6 one. Thus, perhaps some work needs to be done at this
= =0A> > > direction. For example, as you mentioned, how can we g= et an address
=0A> > > instead of the ULA in IPv6.
= =0A> > >
=0A> > > Best regards
=0A> >= > Zongpeng Du
=0A> > >
=0A> > > -----Ori= ginal Message-----
=0A> > > From: Anima [mailto:anima-boun= ces@ietf.org] On Behalf Of Michael
=0A> > > Richardson=0A> > > Sent: Thursday, June 25, 2015 1:12 AM
=0A>= > > To: Michael Behringer (mbehring)
=0A> > > Cc: A= nima WG
=0A> > > Subject: Re: [Anima] I-D Action: draft-be= hringer-anima-autonomic-
=0A> > > addressing-01.txt
= =0A> > >
=0A> > >
=0A> > > Michael= Behringer (mbehring) <mbehring@cisco.com> wrote:
=0A> >= ; > >> > IPv6 only: Autonomic processes should use exclu= sively IPv6, for
=0A> > > >> > simplicity rea= sons.
=0A> > > >>
=0A> > > >= ;> I agree with this as long as it's an RFC 2119 SHOULD, i.e.
= =0A> > > IPv4 could be used in
=0A> > > >&= gt; extraordinary circumstances. The GDNP design is fundamentally
= =0A> > > IP- version
=0A> > > >> indepe= ndent.
=0A> > >
=0A> > > > Yes, as lo= ng as it's really "extraordinary" ;-) That 2119 says
=0A> >= > > "SHOULD" means like you need a really good reason to not= do it.
=0A> What
=0A> > > > would such a g= ood reason be? Just saying, in our implementation we
=0A> > &= gt; > often get the requirement "we want IPv4", and when you dig,=
=0A> > > the reason
=0A> > > > is th= at they don't want to deploy IPv6, and that's the only
=0A> >= > > reason. Slippery slope...
=0A> > >
=0A= > > > a) to respond to the immediate "we want IPv4" --- I'd jus= t tell the
=0A> > customer
=0A> > > that it= uses a custom link layer protocol that uses an ethernet type
=0A&g= t; > > different than 0x0800... just like CDP does :-)
=0A= > > > (I don't think you need to "deploy" IPv6 to have an AC= P...)
=0A> > >
=0A> > > b) the only thing I= care about is that nobody is allowed to say, "but
=0A> > >= ; mechanism XYZ does not exist in IPv4". That's all. I don't know i= f
=0A> > > we will need IPv6-only things, but maybe.=0A> > >
=0A> > > ...
=0A> > >=0A> > > >> Use-ULA: For these overlay addresses= of autonomic nodes, we
=0A> > > use Unique
=0A> &= gt; > >> Local Addresses (ULA), as specified in [RFC4193].= An alternative
=0A> > > >> scheme was discusse= d, using assigned ULA addressing. The
=0A> > consensus
= =0A> > > >> was to use standard ULA, because it was d= eemed to be sufficient.
=0A> > >
=0A> > > It= might be that ULA is an IPv6-only feature.
=0A> > > I don= 't consider 10/8 to be the same, as it is not statistically
=0A>= > > unique inside the AS.
=0A> > >
=0A> >= ; > --
=0A> > > Michael Richardson <mcr+IETF@sandelm= an.ca>, Sandelman Software
=0A> > Works
=0A> >= > -=3D IPv6 IoT consulting =3D-
=0A> > >
=0A>= > >
=0A> >
=0A> > _________________________= ______________________
=0A> > Anima mailing list
=0A>= > Anima@ietf.org
=0A> > https://www.ietf.org/mailman/list= info/anima
=0A>
=0A> __________________________________= _____________
=0A> Anima mailing list
=0A> Anima@ietf.or= g
=0A> https://www.ietf.org/mailman/listinfo/anima

= =0A_______________________________________________
=0AAnima mailing= list
=0AAnima@ietf.org
=0Ahttps://www.ietf.org/mailman/listin= fo/anima
--=_48afb362d8846ecc027de0b29c5e03c9-- From nobody Fri Jun 26 02:35:54 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F1B1A701D for ; Fri, 26 Jun 2015 02:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqobWB5p29ls for ; Fri, 26 Jun 2015 02:35:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91F2E1A7017 for ; Fri, 26 Jun 2015 02:35:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYA23839; Fri, 26 Jun 2015 09:35:45 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 26 Jun 2015 10:35:39 +0100 Received: from NKGEML505-MBX.china.huawei.com ([169.254.1.218]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Fri, 26 Jun 2015 17:35:34 +0800 From: Duzongpeng To: Jonathan Hansford , "Michael Behringer (mbehring)" , Michael Richardson Thread-Topic: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft-behringer-anima-autonomic-addressing-01.txt Thread-Index: AQHQrxkRDomOGjtUGEW0YQrF2SXEn5284BqA//+3fICAAVswgIAAk4EQ Date: Fri, 26 Jun 2015 09:35:33 +0000 Message-ID: References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF47B1@xmb-rcd-x14.cisco.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.149.226] Content-Type: multipart/alternative; boundary="_000_BAFEC9523F57BC48A51C20226A5589575E932046nkgeml505mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Anima WG Subject: Re: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft-behringer-anima-autonomic-addressing-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jun 2015 09:35:52 -0000 --_000_BAFEC9523F57BC48A51C20226A5589575E932046nkgeml505mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9uYXRoYW46DQoNCiAgICAgICAgIEkgdGhpbmsgeW91IGFyZSB0YWxraW5nIGFib3V0IHRo ZSBuZXR3b3JrIGluIHRoZSBlbnRlcnByaXNlIGFuZCBjYW1wdXMsIHdoZXJlIG1pZ2h0IGJlIElQ djQuDQoNCiAgICAgICAgIFRoaXMgcGFydCBvZiBjdXN0b21zIGRvbuKAmXQgY2FyZSBtdWNoIGFi b3V0IHdoYXQgdGVjaG5vbG9neSBpcyB1c2VkIHVuZGVybmVhdGggdGhlIG5ldHdvcmsuIFRoZXkg b25seSBjYXJlIGFib3V0IHRoZSBzZXJ2aWNlIGxheWVyLg0KDQpUaGV5IHdhbnQgdGhlIGRldGFp bGVkIG5ldHdvcmsgaW5mb3JtYXRpb24gYXMgdHJhbnNwYXJlbnQgYXMgcG9zc2libGUuIEF1dG9u b21pYyBuZXR3b3JrIGNhbiBzdXJlbHkgZnVsZmlsbCB0aGVzZSBuZWVkcy4NCg0KQmVzdCBSZWdh cmRzDQpab25ncGVuZyBEdQ0KDQpGcm9tOiBBbmltYSBbbWFpbHRvOmFuaW1hLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBKb25hdGhhbiBIYW5zZm9yZA0KU2VudDogRnJpZGF5LCBKdW5l IDI2LCAyMDE1IDQ6MzkgUE0NClRvOiBNaWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpOyBEdXpv bmdwZW5nOyBNaWNoYWVsIFJpY2hhcmRzb24NCkNjOiBBbmltYSBXRw0KU3ViamVjdDogUmU6IFtB bmltYV0gV2hldGhlciBJUHY2IG9ubHkgZm9yIEFDUD8gLy9SRTogSS1EIEFjdGlvbjogZHJhZnQt YmVocmluZ2VyLWFuaW1hLWF1dG9ub21pYy1hZGRyZXNzaW5nLTAxLnR4dA0KDQpUaGVyZSBhcmUg c29tZSBzeXN0ZW1zIG91dHNpZGUgdGhlIEludGVybmV0IHRoYXQgaGF2ZSBubyB1cmdlbnQgbmVl ZCB0byBtb3ZlIHRvIElQdjYgYW5kIGRldmVsb3BlcnMgd291bGQgcmF0aGVyIGZvY3VzIG9uIG1v cmUgdXJnZW50IG5lZWRzLiAgQXV0b25vbWljIG5ldHdvcmtpbmcgY291bGQgd2VsbCBiZSBvbmUg b2YgdGhvc2UgbW9yZSB1cmdlbnQgbmVlZHMuDQoNCkpvbmF0aGFuDQoNCg0KLS0tLS0gT3JpZ2lu YWwgTWVzc2FnZSAtLS0tLQ0KRnJvbToNCiJNaWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpIiA8 bWJlaHJpbmdAY2lzY28uY29tPG1haWx0bzptYmVocmluZ0BjaXNjby5jb20+Pg0KDQpUbzoNCiJE dXpvbmdwZW5nIiA8ZHV6b25ncGVuZ0BodWF3ZWkuY29tPG1haWx0bzpkdXpvbmdwZW5nQGh1YXdl aS5jb20+PiwgIk1pY2hhZWwgUmljaGFyZHNvbiIgPG1jcitpZXRmQHNhbmRlbG1hbi5jYTxtYWls dG86bWNyK2lldGZAc2FuZGVsbWFuLmNhPj4NCkNjOg0KIkFuaW1hIFdHIiA8YW5pbWFAaWV0Zi5v cmc8bWFpbHRvOmFuaW1hQGlldGYub3JnPj4NClNlbnQ6DQpUaHUsIDI1IEp1biAyMDE1IDExOjU2 OjE5ICswMDAwDQpTdWJqZWN0Og0KUmU6IFtBbmltYV0gV2hldGhlciBJUHY2IG9ubHkgZm9yIEFD UD8gLy9SRTogSS1EIEFjdGlvbjogZHJhZnQtYmVocmluZ2VyLWFuaW1hLWF1dG9ub21pYy1hZGRy ZXNzaW5nLTAxLnR4dA0KDQoNCkZvciBzb21ldGhpbmcgbmV3IGxpa2UgQU4sIHdoZXJlIHRoZSBz dGFuZGFyZGlzZWQgc3BlY3Mgd2lsbCB0YWtlIGF0IGxlYXN0IGEgY291cGxlIG9mIHllYXJzIHRv IGFwcGVhciBpbiBhbnlvbmUncyBwcm9kdWN0cywgd2hlcmUgd2UgZG8gTk9UIGhhdmUgYmFja3dh cmQgY29tcGF0aWJpbGl0eSBpc3N1ZXMsIHdoZXJlIHdlIGRvIG5vdCBhZGRyZXNzIGVuZCBzeXN0 ZW1zIGZvciBzb21lIHllYXJzIHRvIGNvbWUsIEkgcGVyc29uYWxseSB0aGluayBpdCBpcyBpbnNh bmUgdG8gZXZlbiBjb25zaWRlciBJUHY0Lg0KDQpCdXQgSSB0aGluayB3ZSBkbyBoYXZlIGFncmVl bWVudCB0aGF0IHdlIHN0YXJ0IHdpdGggSVB2NiBvbmx5LCBhbmQganVzdCBrZWVwIHRoZSBkb29y IG9wZW4sIGluIGNhc2Ugd2UgbmVlZCB0byBzdXBwb3J0IGl0LiBJZiB0aGUgd29ya2luZyBncm91 cCB3YW50cyB0byBkbyB0aGF0LCBJJ2xsIGNoYW5nZSB0aGUgdGV4dCBhY2NvcmRpbmdseS4gTWF5 YmUgYSBkaXNjdXNzaW9uIGZvciBQcmFndWU/DQoNCk1pY2hhZWwNCg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBEdXpvbmdwZW5nIFttYWlsdG86ZHV6b25ncGVuZ0BodWF3 ZWkuY29tXQ0KPiBTZW50OiAyNSBKdW5lIDIwMTUgMTA6MjQNCj4gVG86IE1pY2hhZWwgQmVocmlu Z2VyIChtYmVocmluZyk7IE1pY2hhZWwgUmljaGFyZHNvbg0KPiBDYzogQW5pbWEgV0cNCj4gU3Vi amVjdDogUkU6IFtBbmltYV0gV2hldGhlciBJUHY2IG9ubHkgZm9yIEFDUD8gLy9SRTogSS1EIEFj dGlvbjogZHJhZnQtDQo+IGJlaHJpbmdlci1hbmltYS1hdXRvbm9taWMtYWRkcmVzc2luZy0wMS50 eHQNCj4NCj4gSGksIE1pY2hhZWwgQmVocmluZ2VyDQo+DQo+IEkgYWdyZWUgdGhhdCB0aGUgZGVm YXVsdCBzZXR0aW5nIG9mIHRoZSBBQ1AgY291bGQgYmUgSVB2Ni1iYXNlZCwgd2hpY2ggbWF5DQo+ IG1ha2UgdGhlIGNvbW11bmljYXRpb24gYWNyb3NzIGF1dG9ub21pYyBkb21haW5zIGVhc2llciB0 byBpbXBsZW1lbnQuDQo+DQo+IFdoYXQgSSBzdWdnZXN0ZWQgaXMgdGhhdCB3ZSBmaXJzdCBoYXZl IGFuIElQdjYtYmFzZWQgQUNQIHJlYWR5LCBhbmQgZGVmaW5lDQo+IGFuIElQdjQtYmFzZWQgb25l IGFzIGFuIGFsdGVybmF0aXZlIG9wdGlvbi4NCj4NCj4gQmVzdCByZWdhcmRzDQo+IFpvbmdwZW5n IER1DQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEFuaW1hIFttYWls dG86YW5pbWEtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1pY2hhZWwNCj4gQmVocmlu Z2VyIChtYmVocmluZykNCj4gU2VudDogVGh1cnNkYXksIEp1bmUgMjUsIDIwMTUgMzozMSBQTQ0K PiBUbzogRHV6b25ncGVuZzsgTWljaGFlbCBSaWNoYXJkc29uDQo+IENjOiBBbmltYSBXRw0KPiBT dWJqZWN0OiBSZTogW0FuaW1hXSBXaGV0aGVyIElQdjYgb25seSBmb3IgQUNQPyAvL1JFOiBJLUQg QWN0aW9uOiBkcmFmdC0NCj4gYmVocmluZ2VyLWFuaW1hLWF1dG9ub21pYy1hZGRyZXNzaW5nLTAx LnR4dA0KPg0KPiBSZS1yZWFkaW5nIG15IG93biBtZXNzYWdlLCBvbmUgdGhpbmcgdG8gYWRkOiBC cmlhbiBoYXMgYWxyZWFkeSBzdGF0ZWQgdGhhdA0KPiBHRE5QIGlzIHByb3RvY29sIGluZGVwZW5k ZW50LCBhbmQgaXQgc2hvdWxkIGJlLiBPZiBjb3Vyc2Ugd2Ugd2FudCB0bw0KPiBkZXZlbG9wIGV2 ZXJ5dGhpbmcgSVAgdmVyc2lvbiBpbmRlcGVuZGVudCB3aGVyZXZlciBwb3NzaWJsZS4NCj4NCj4g QnV0IHRoZXJlIGhhcyB0byBiZSBzb21lIGRlZmF1bHQgYXV0b25vbWljIGFkZHJlc3NpbmcsIHJv dXRpbmcsIGFuZCBmb3INCj4gVEhBVCB3ZSB3YW50IHRvIGxvb2sgYXQgSVB2NiBvbmx5IGF0IHRo aXMgcG9pbnQuDQo+DQo+IE1pY2hhZWwNCj4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiA+IEZyb206IEFuaW1hIFttYWlsdG86YW5pbWEtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIE1pY2hhZWwNCj4gPiBCZWhyaW5nZXIgKG1iZWhyaW5nKQ0KPiA+IFNlbnQ6IDI1IEp1 bmUgMjAxNSAwOToyNQ0KPiA+IFRvOiBEdXpvbmdwZW5nOyBNaWNoYWVsIFJpY2hhcmRzb24NCj4g PiBDYzogQW5pbWEgV0cNCj4gPiBTdWJqZWN0OiBSZTogW0FuaW1hXSBXaGV0aGVyIElQdjYgb25s eSBmb3IgQUNQPyAvL1JFOiBJLUQgQWN0aW9uOg0KPiA+IGRyYWZ0LSBiZWhyaW5nZXItYW5pbWEt YXV0b25vbWljLWFkZHJlc3NpbmctMDEudHh0DQo+ID4NCj4gPiBPSywgSSB0aGluayB0aGVyZSBp cyBzb21lIGNvbmZ1c2lvbiBhcm91bmQgdGhpcyB0b3BpYy4NCj4gPg0KPiA+IEEgbmV0d29yayB3 aXRoIGF1dG9ub21pYyBmdW5jdGlvbnMgKHdlIGFsbCBhZ3JlZSB0aGF0IGEgZnVsbHkNCj4gPiBh dXRvbm9taWMgbmV0d29yayBpcyBub3Qgb3VyIG1haW4gdGFyZ2V0IGZvciBub3cpIGNhbiBzdXBw b3J0IG9uIHRoZQ0KPiA+ICpkYXRhIHBsYW5lKiBhbnkgcHJvdG9jb2wgdGhlIG9wZXJhdG9yIHdh bnRzIHRvIHVzZSwgaW5jbHVkaW5nIElQdjQsDQo+ID4gYXBwbGV0YWxrIGFuZCBJUHY4ICh3aGVu IGl0IGNvbWVzKS4NCj4gPg0KPiA+IFRoZSBzdGF0ZW1lbnQgaXMgZm9yIHRoZSBzaWduYWxsaW5n LCBtZXNzYWdpbmcgYW5kIG90aGVyIHByb3RvY29scw0KPiA+IElOU0lERSB0aGUgQUNQLCB1c2Vk IGJ5IEF1dG9ub21pYyBTZXJ2aWNlIEFnZW50cy4NCj4gPg0KPiA+IEF1dG9ub21pYyBTZXJ2aWNl IEFnZW50cyB3aWxsIGJlIGV4cG9zZWQgdG8gYSBkZXZlbG9wZXIgY29tbXVuaXR5LCBhbmQNCj4g PiB0aGUgdmVuZG9ycyBpbXBsZW1lbnRpbmcgdGhlIEFDUC4gVGhlcmUgaXMgYWJzb2x1dGVseSBu byByZWFzb24gdG8NCj4gPiBzdGFuZGFyZGlzZSBtb3JlIHRoYW4gb25lIHByb3RvY29sIGZvciB0 aGlzIHB1cnBvc2UuDQo+ID4NCj4gPiBNaWNoYWVsUiBpcyByaWdodDogWW91IGRvbid0IG5lZWQg dG8gYWN0aXZlbHkgZGVwbG95IElQdjYgdG8gdXNlIHRoZQ0KPiA+IEFDUC4gSXQganVzdCBoYXBw ZW5zLiBXaXRoIG9uZSBjYXZlYXQ6IElmIHlvdSBjb25uZWN0IGFuIE5NUyBzeXN0ZW0NCj4gPiBp bnRvIHRoZSBBQ1AgZm9yICJ2aXJ0dWFsIG91dCBvZiBiYW5kIiB1c2FnZSwgdGhlbiB0aGF0IHN5 c3RlbSBuZWVkcw0KPiA+IHRvIHN1cHBvcnQgSVB2Ni4gQnV0IHRoYXQgaXMgdHlwaWNhbGx5IG5v dCBhIHByb2JsZW0sIGluIG91ciBleHBlcmllbmNlLg0KPiA+DQo+ID4gSW4gb3RoZXIgd29yZHM6 IFdlJ3JlIHNheWluZyB0aGF0ICphdXRvbm9taWMgZnVuY3Rpb25zKiAod2hpY2ggdGhlIGVuZA0K PiA+IHVzZXIgaXNuJ3QgZXhwb3NlZCB0byBhdCBhbGwpIGFyZSBleGNsdXNpdmVseSBJUHY2LCBi dXQgdGhlIG5ldHdvcmsNCj4gPiBjYW4gcHJvdmlkZSBhbnkgc2VydmljZSB0aGUgb3BlcmF0b3Ig d2FudHMuIFNwZWNpZmljYWxseSwgYW4gYXV0b25vbWljDQo+ID4gZnVuY3Rpb24gKHJ1bm5pbmcg b24gYW4gSVB2NiBjb250cm9sIHBsYW5lKSBtYXkgd2VsbCBuZWdvdGlhdGUNCj4gPiBhZGRyZXNz aW5nIGZvciBJUHY0IHNlcnZpY2VzLg0KPiA+DQo+ID4gTWljaGFlbA0KPiA+DQo+ID4gPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogRHV6b25ncGVuZyBbbWFpbHRvOmR1 em9uZ3BlbmdAaHVhd2VpLmNvbV0NCj4gPiA+IFNlbnQ6IDI1IEp1bmUgMjAxNSAwNDowNg0KPiA+ ID4gVG86IE1pY2hhZWwgUmljaGFyZHNvbjsgTWljaGFlbCBCZWhyaW5nZXIgKG1iZWhyaW5nKQ0K PiA+ID4gQ2M6IEFuaW1hIFdHDQo+ID4gPiBTdWJqZWN0OiBXaGV0aGVyIElQdjYgb25seSBmb3Ig QUNQPyAvL1JFOiBbQW5pbWFdIEktRCBBY3Rpb246IGRyYWZ0LQ0KPiA+ID4gYmVocmluZ2VyLWFu aW1hLWF1dG9ub21pYy1hZGRyZXNzaW5nLTAxLnR4dA0KPiA+ID4NCj4gPiA+IEhpLCBNaWNoYWVs IFJpY2hhcmRzb246DQo+ID4gPg0KPiA+ID4gSSBhZ3JlZSB3aXRoIHlvdXIgb3B0aW9uLiBQZXJo YXBzIEFDUCBpcyBub3QgbmVlZGVkIHRvIGJlIElQdjYgb25seS4NCj4gPiA+DQo+ID4gPiBPZiBj b3Vyc2UsIGFuIElQdjYgb25seSBhdXRvbm9taWMgY29udHJvbCBwbGFuZSBpcyBvayBmb3IgYWxs IHRoZQ0KPiA+ID4gc2VydmljZXMgaW4gYXV0b25vbWljIG5ldHdvcmssIGFuZCB0aGUgc29sdXRp b24gaGFzIHRoZSBhZHZhbnRhZ2Ugb2YNCj4gPiA+IHNpbXBsaWNpdHkgYXMgbWVudGlvbmVkIGJ5 IE1pY2hhZWwgQmVocmluZ2VyLg0KPiA+ID4NCj4gPiA+IEhvd2V2ZXIsIHRoZSBuZXR3b3JrIG9w ZXJhdG9yIG1heSBiZSBtb3JlIGZhbWlsaWFyIHdpdGggdGhlIElQdjQtDQo+ID4gPiBiYXNlIG1h bmFnZW1lbnQuDQo+ID4gPiBJbiB0aGUgYmVnaW5uaW5nIG9mIHRoZSBBQ1AgZGVwbG95bWVudCwg dGhlIG5ldHdvcmsgb3BlcmF0b3IgbWF5DQo+ID4gbm90DQo+ID4gPiBiZSB2ZXJ5IGNvbmZpZGVu dCBhYm91dCB0aGUgZGVjaXNpb25zIG1hZGUgYnkgdGhlIGF1dG9ub21pYyBuZXR3b3JrLg0KPiA+ ID4gU29tZSBraW5kcyBvZiBtb25pdG9yaW5nIGpvYnMgbWF5IGJlIGRlc2lyZWQgYnkgdGhlIG5l dHdvcmsgb3BlcmF0b3JzLg0KPiA+ID4gQXQgdGhpcyB0aW1lLCB0aGUgb3BlcmF0b3IgbWF5IHdh bnQgdG8gc2VlIHNvbWUgSVB2NCBhZGRyZXNzZXMuIFNvLA0KPiA+ID4gcGVyaGFwcyB3ZSBuZWVk IHRvIHByb3ZpZGUgSVB2NC1iYXNlZCBBQ1AgYXMgYW4gb3B0aW9uIGZvciB0aGVzZQ0KPiA+ID4g cGFydHMgb2Ygb3BlcmF0b3JzLiBPdGhlcndpc2UsIHdlIGNhbiBvbmx5IGFuc3dlciB0aGVtICJz b3JyeSwgd2UNCj4gPiA+IG9ubHkgc3VwcG9ydA0KPiA+ID4gSVB2NiBoZXJlIi4NCj4gPiA+DQo+ ID4gPiBBcyBJUHY0IGhhcyBiZWVuIHdpZGVseSBkZXBsb3llZCwgcGVyaGFwcyBhbiBJUHY0LWJh c2VkDQo+ID4gYXV0b25vbWljDQo+ID4gPiBuZXR3b3JrIHdpbGwgYmUgYWNjZXB0ZWQgYnkgbW9y ZSBuZXR3b3JrIG1hbmFnZXJzIGF0IHRoZSBiZWdpbm5pbmcuDQo+ID4gPg0KPiA+ID4gSW5kZWVk LCBhdCB0aGlzIHRpbWUsIGFuIElQdjQtYmFzZWQgQUNQIGlzIG5vdCBhcyBtYXR1cmUgYXMgdGhl DQo+ID4gPiBJUHY2IG9uZS4gVGh1cywgcGVyaGFwcyBzb21lIHdvcmsgbmVlZHMgdG8gYmUgZG9u ZSBhdCB0aGlzDQo+ID4gPiBkaXJlY3Rpb24uIEZvciBleGFtcGxlLCBhcyB5b3UgbWVudGlvbmVk LCBob3cgY2FuIHdlIGdldCBhbiBhZGRyZXNzDQo+ID4gPiBpbnN0ZWFkIG9mIHRoZSBVTEEgaW4g SVB2Ni4NCj4gPiA+DQo+ID4gPiBCZXN0IHJlZ2FyZHMNCj4gPiA+IFpvbmdwZW5nIER1DQo+ID4g Pg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IEFuaW1hIFtt YWlsdG86YW5pbWEtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1pY2hhZWwNCj4gPiA+ IFJpY2hhcmRzb24NCj4gPiA+IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDI1LCAyMDE1IDE6MTIgQU0N Cj4gPiA+IFRvOiBNaWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpDQo+ID4gPiBDYzogQW5pbWEg V0cNCj4gPiA+IFN1YmplY3Q6IFJlOiBbQW5pbWFdIEktRCBBY3Rpb246IGRyYWZ0LWJlaHJpbmdl ci1hbmltYS1hdXRvbm9taWMtDQo+ID4gPiBhZGRyZXNzaW5nLTAxLnR4dA0KPiA+ID4NCj4gPiA+ DQo+ID4gPiBNaWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpIDxtYmVocmluZ0BjaXNjby5jb208 bWFpbHRvOm1iZWhyaW5nQGNpc2NvLmNvbT4+IHdyb3RlOg0KPiA+ID4gPj4gPiBJUHY2IG9ubHk6 IEF1dG9ub21pYyBwcm9jZXNzZXMgc2hvdWxkIHVzZSBleGNsdXNpdmVseSBJUHY2LCBmb3INCj4g PiA+ID4+ID4gc2ltcGxpY2l0eSByZWFzb25zLg0KPiA+ID4gPj4NCj4gPiA+ID4+IEkgYWdyZWUg d2l0aCB0aGlzIGFzIGxvbmcgYXMgaXQncyBhbiBSRkMgMjExOSBTSE9VTEQsIGkuZS4NCj4gPiA+ IElQdjQgY291bGQgYmUgdXNlZCBpbg0KPiA+ID4gPj4gZXh0cmFvcmRpbmFyeSBjaXJjdW1zdGFu Y2VzLiBUaGUgR0ROUCBkZXNpZ24gaXMgZnVuZGFtZW50YWxseQ0KPiA+ID4gSVAtIHZlcnNpb24N Cj4gPiA+ID4+IGluZGVwZW5kZW50Lg0KPiA+ID4NCj4gPiA+ID4gWWVzLCBhcyBsb25nIGFzIGl0 J3MgcmVhbGx5ICJleHRyYW9yZGluYXJ5IiA7LSkgVGhhdCAyMTE5IHNheXMNCj4gPiA+ID4gIlNI T1VMRCIgbWVhbnMgbGlrZSB5b3UgbmVlZCBhIHJlYWxseSBnb29kIHJlYXNvbiB0byBub3QgZG8g aXQuDQo+IFdoYXQNCj4gPiA+ID4gd291bGQgc3VjaCBhIGdvb2QgcmVhc29uIGJlPyBKdXN0IHNh eWluZywgaW4gb3VyIGltcGxlbWVudGF0aW9uIHdlDQo+ID4gPiA+IG9mdGVuIGdldCB0aGUgcmVx dWlyZW1lbnQgIndlIHdhbnQgSVB2NCIsIGFuZCB3aGVuIHlvdSBkaWcsDQo+ID4gPiB0aGUgcmVh c29uDQo+ID4gPiA+IGlzIHRoYXQgdGhleSBkb24ndCB3YW50IHRvIGRlcGxveSBJUHY2LCBhbmQg dGhhdCdzIHRoZSBvbmx5DQo+ID4gPiA+IHJlYXNvbi4gU2xpcHBlcnkgc2xvcGUuLi4NCj4gPiA+ DQo+ID4gPiBhKSB0byByZXNwb25kIHRvIHRoZSBpbW1lZGlhdGUgIndlIHdhbnQgSVB2NCIgLS0t IEknZCBqdXN0IHRlbGwgdGhlDQo+ID4gY3VzdG9tZXINCj4gPiA+IHRoYXQgaXQgdXNlcyBhIGN1 c3RvbSBsaW5rIGxheWVyIHByb3RvY29sIHRoYXQgdXNlcyBhbiBldGhlcm5ldCB0eXBlDQo+ID4g PiBkaWZmZXJlbnQgdGhhbiAweDA4MDAuLi4ganVzdCBsaWtlIENEUCBkb2VzIDotKQ0KPiA+ID4g KEkgZG9uJ3QgdGhpbmsgeW91IG5lZWQgdG8gImRlcGxveSIgSVB2NiB0byBoYXZlIGFuIEFDUC4u LikNCj4gPiA+DQo+ID4gPiBiKSB0aGUgb25seSB0aGluZyBJIGNhcmUgYWJvdXQgaXMgdGhhdCBu b2JvZHkgaXMgYWxsb3dlZCB0byBzYXksICJidXQNCj4gPiA+IG1lY2hhbmlzbSBYWVogZG9lcyBu b3QgZXhpc3QgaW4gSVB2NCIuIFRoYXQncyBhbGwuIEkgZG9uJ3Qga25vdyBpZg0KPiA+ID4gd2Ug d2lsbCBuZWVkIElQdjYtb25seSB0aGluZ3MsIGJ1dCBtYXliZS4NCj4gPiA+DQo+ID4gPiAuLi4N Cj4gPiA+DQo+ID4gPiA+PiBVc2UtVUxBOiBGb3IgdGhlc2Ugb3ZlcmxheSBhZGRyZXNzZXMgb2Yg YXV0b25vbWljIG5vZGVzLCB3ZQ0KPiA+ID4gdXNlIFVuaXF1ZQ0KPiA+ID4gPj4gTG9jYWwgQWRk cmVzc2VzIChVTEEpLCBhcyBzcGVjaWZpZWQgaW4gW1JGQzQxOTNdLiBBbiBhbHRlcm5hdGl2ZQ0K PiA+ID4gPj4gc2NoZW1lIHdhcyBkaXNjdXNzZWQsIHVzaW5nIGFzc2lnbmVkIFVMQSBhZGRyZXNz aW5nLiBUaGUNCj4gPiBjb25zZW5zdXMNCj4gPiA+ID4+IHdhcyB0byB1c2Ugc3RhbmRhcmQgVUxB LCBiZWNhdXNlIGl0IHdhcyBkZWVtZWQgdG8gYmUgc3VmZmljaWVudC4NCj4gPiA+DQo+ID4gPiBJ dCBtaWdodCBiZSB0aGF0IFVMQSBpcyBhbiBJUHY2LW9ubHkgZmVhdHVyZS4NCj4gPiA+IEkgZG9u J3QgY29uc2lkZXIgMTAvOCB0byBiZSB0aGUgc2FtZSwgYXMgaXQgaXMgbm90IHN0YXRpc3RpY2Fs bHkNCj4gPiA+IHVuaXF1ZSBpbnNpZGUgdGhlIEFTLg0KPiA+ID4NCj4gPiA+IC0tDQo+ID4gPiBN aWNoYWVsIFJpY2hhcmRzb24gPG1jcitJRVRGQHNhbmRlbG1hbi5jYTxtYWlsdG86bWNyK0lFVEZA c2FuZGVsbWFuLmNhPj4sIFNhbmRlbG1hbiBTb2Z0d2FyZQ0KPiA+IFdvcmtzDQo+ID4gPiAtPSBJ UHY2IElvVCBjb25zdWx0aW5nID0tDQo+ID4gPg0KPiA+ID4NCj4gPg0KPiA+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gQW5pbWEgbWFpbGluZyBs aXN0DQo+ID4gQW5pbWFAaWV0Zi5vcmc8bWFpbHRvOkFuaW1hQGlldGYub3JnPg0KPiA+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWENCj4NCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQW5pbWEgbWFpbGluZyBsaXN0 DQo+IEFuaW1hQGlldGYub3JnPG1haWx0bzpBbmltYUBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYQ0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KQW5pbWEgbWFpbGluZyBsaXN0DQpBbmltYUBpZXRm Lm9yZzxtYWlsdG86QW5pbWFAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2FuaW1hDQo= --_000_BAFEC9523F57BC48A51C20226A5589575E932046nkgeml505mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNSA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlw ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0 YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi5om55rOo5qGG 5paH5pysIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZTo5LjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQ2hhcg0KCXttc28tc3R5bGUt bmFtZToi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazrmibnms6jmoYbmlofmnKw7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h cmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5IaSBKb25hdGhhbjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkg dGhpbmsgeW91IGFyZSB0YWxraW5nIGFib3V0IHRoZSBuZXR3b3JrIGluIHRoZSBlbnRlcnByaXNl IGFuZCBjYW1wdXMsIHdoZXJlIG1pZ2h0IGJlIElQdjQuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBUaGlzIHBhcnQgb2YgY3VzdG9tcyBkb27igJl0IGNhcmUgbXVjaCBhYm91dCB3aGF0IHRl Y2hub2xvZ3kgaXMgdXNlZCB1bmRlcm5lYXRoIHRoZSBuZXR3b3JrLiBUaGV5IG9ubHkgY2FyZSBh Ym91dCB0aGUgc2VydmljZSBsYXllci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJ0ZXh0LWluZGVudDoyMS4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhleSB3YW50IHRoZSBkZXRhaWxlZCBuZXR3 b3JrIGluZm9ybWF0aW9uIGFzIHRyYW5zcGFyZW50IGFzIHBvc3NpYmxlLiBBdXRvbm9taWMgbmV0 d29yayBjYW4gc3VyZWx5IGZ1bGZpbGwgdGhlc2UgbmVlZHMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkJlc3QgUmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Wm9uZ3BlbmcgRHU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBBbmltYSBbbWFpbHRvOmFuaW1hLWJvdW5jZXNA aWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkpvbmF0aGFuIEhhbnNmb3JkPGJyPg0KPGI+ U2VudDo8L2I+IEZyaWRheSwgSnVuZSAyNiwgMjAxNSA0OjM5IFBNPGJyPg0KPGI+VG86PC9iPiBN aWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpOyBEdXpvbmdwZW5nOyBNaWNoYWVsIFJpY2hhcmRz b248YnI+DQo8Yj5DYzo8L2I+IEFuaW1hIFdHPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbQW5p bWFdIFdoZXRoZXIgSVB2NiBvbmx5IGZvciBBQ1A/IC8vUkU6IEktRCBBY3Rpb246IGRyYWZ0LWJl aHJpbmdlci1hbmltYS1hdXRvbm9taWMtYWRkcmVzc2luZy0wMS50eHQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGVyZSBhcmUgc29t ZSBzeXN0ZW1zIG91dHNpZGUgdGhlIEludGVybmV0IHRoYXQgaGF2ZSBubyB1cmdlbnQgbmVlZCB0 byBtb3ZlIHRvIElQdjYgYW5kIGRldmVsb3BlcnMgd291bGQgcmF0aGVyIGZvY3VzIG9uIG1vcmUg dXJnZW50IG5lZWRzLiAmbmJzcDtBdXRvbm9taWMgbmV0d29ya2luZw0KIGNvdWxkIHdlbGwgYmUg b25lIG9mIHRob3NlIG1vcmUgdXJnZW50IG5lZWRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Sm9uYXRoYW48YnI+DQo8YnI+DQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KLS0tLS0gT3JpZ2luYWwgTWVzc2Fn ZSAtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6I0U0RTRFNCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PG86cD48L286cD48L3NwYW4+PC9iPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6I0U0RTRFNCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZxdW90O01pY2hhZWwg QmVocmluZ2VyIChtYmVocmluZykmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzptYmVocmluZ0Bj aXNjby5jb20iPm1iZWhyaW5nQGNpc2NvLmNvbTwvYT4mZ3Q7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Ubzo8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+JnF1 b3Q7RHV6b25ncGVuZyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmR1em9uZ3BlbmdAaHVhd2Vp LmNvbSI+ZHV6b25ncGVuZ0BodWF3ZWkuY29tPC9hPiZndDssICZxdW90O01pY2hhZWwgUmljaGFy ZHNvbiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1jciYjNDM7aWV0ZkBzYW5kZWxtYW4uY2Ei Pm1jciYjNDM7aWV0ZkBzYW5kZWxtYW4uY2E8L2E+Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Q2M6PG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiZxdW90O0FuaW1hIFdHJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YW5pbWFAaWV0 Zi5vcmciPmFuaW1hQGlldGYub3JnPC9hPiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPlNlbnQ6PG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPlRodSwgMjUgSnVuIDIwMTUgMTE6NTY6MTkgJiM0MzswMDAwPG86cD48L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TdWJqZWN0OjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5SZTogW0FuaW1hXSBXaGV0aGVyIElQdjYgb25seSBmb3IgQUNQPyAv L1JFOiBJLUQgQWN0aW9uOiBkcmFmdC1iZWhyaW5nZXItYW5pbWEtYXV0b25vbWljLWFkZHJlc3Np bmctMDEudHh0PGJyPg0KPGJyPg0KPGJyPg0KRm9yIHNvbWV0aGluZyBuZXcgbGlrZSBBTiwgd2hl cmUgdGhlIHN0YW5kYXJkaXNlZCBzcGVjcyB3aWxsIHRha2UgYXQgbGVhc3QgYSBjb3VwbGUgb2Yg eWVhcnMgdG8gYXBwZWFyIGluIGFueW9uZSdzIHByb2R1Y3RzLCB3aGVyZSB3ZSBkbyBOT1QgaGF2 ZSBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IGlzc3Vlcywgd2hlcmUgd2UgZG8gbm90IGFkZHJlc3Mg ZW5kIHN5c3RlbXMgZm9yIHNvbWUgeWVhcnMgdG8gY29tZSwgSSBwZXJzb25hbGx5IHRoaW5rIGl0 DQogaXMgaW5zYW5lIHRvIGV2ZW4gY29uc2lkZXIgSVB2NC4gPGJyPg0KPGJyPg0KQnV0IEkgdGhp bmsgd2UgZG8gaGF2ZSBhZ3JlZW1lbnQgdGhhdCB3ZSBzdGFydCB3aXRoIElQdjYgb25seSwgYW5k IGp1c3Qga2VlcCB0aGUgZG9vciBvcGVuLCBpbiBjYXNlIHdlIG5lZWQgdG8gc3VwcG9ydCBpdC4g SWYgdGhlIHdvcmtpbmcgZ3JvdXAgd2FudHMgdG8gZG8gdGhhdCwgSSdsbCBjaGFuZ2UgdGhlIHRl eHQgYWNjb3JkaW5nbHkuIE1heWJlIGEgZGlzY3Vzc2lvbiBmb3IgUHJhZ3VlPw0KPGJyPg0KPGJy Pg0KTWljaGFlbDxicj4NCjxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+ DQomZ3Q7IEZyb206IER1em9uZ3BlbmcgWzxhIGhyZWY9Im1haWx0bzpkdXpvbmdwZW5nQGh1YXdl aS5jb20iPm1haWx0bzpkdXpvbmdwZW5nQGh1YXdlaS5jb208L2E+XTxicj4NCiZndDsgU2VudDog MjUgSnVuZSAyMDE1IDEwOjI0PGJyPg0KJmd0OyBUbzogTWljaGFlbCBCZWhyaW5nZXIgKG1iZWhy aW5nKTsgTWljaGFlbCBSaWNoYXJkc29uPGJyPg0KJmd0OyBDYzogQW5pbWEgV0c8YnI+DQomZ3Q7 IFN1YmplY3Q6IFJFOiBbQW5pbWFdIFdoZXRoZXIgSVB2NiBvbmx5IGZvciBBQ1A/IC8vUkU6IEkt RCBBY3Rpb246IGRyYWZ0LTxicj4NCiZndDsgYmVocmluZ2VyLWFuaW1hLWF1dG9ub21pYy1hZGRy ZXNzaW5nLTAxLnR4dDxicj4NCiZndDsgPGJyPg0KJmd0OyBIaSwgTWljaGFlbCBCZWhyaW5nZXI8 YnI+DQomZ3Q7IDxicj4NCiZndDsgSSBhZ3JlZSB0aGF0IHRoZSBkZWZhdWx0IHNldHRpbmcgb2Yg dGhlIEFDUCBjb3VsZCBiZSBJUHY2LWJhc2VkLCB3aGljaCBtYXk8YnI+DQomZ3Q7IG1ha2UgdGhl IGNvbW11bmljYXRpb24gYWNyb3NzIGF1dG9ub21pYyBkb21haW5zIGVhc2llciB0byBpbXBsZW1l bnQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFdoYXQgSSBzdWdnZXN0ZWQgaXMgdGhhdCB3ZSBmaXJz dCBoYXZlIGFuIElQdjYtYmFzZWQgQUNQIHJlYWR5LCBhbmQgZGVmaW5lPGJyPg0KJmd0OyBhbiBJ UHY0LWJhc2VkIG9uZSBhcyBhbiBhbHRlcm5hdGl2ZSBvcHRpb24uPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IEJlc3QgcmVnYXJkczxicj4NCiZndDsgWm9uZ3BlbmcgRHU8YnI+DQomZ3Q7IDxicj4NCiZn dDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IEFuaW1hIFs8YSBo cmVmPSJtYWlsdG86YW5pbWEtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmFuaW1hLWJvdW5jZXNA aWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgTWljaGFlbDxicj4NCiZndDsgQmVocmluZ2VyICht YmVocmluZyk8YnI+DQomZ3Q7IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDI1LCAyMDE1IDM6MzEgUE08 YnI+DQomZ3Q7IFRvOiBEdXpvbmdwZW5nOyBNaWNoYWVsIFJpY2hhcmRzb248YnI+DQomZ3Q7IENj OiBBbmltYSBXRzxicj4NCiZndDsgU3ViamVjdDogUmU6IFtBbmltYV0gV2hldGhlciBJUHY2IG9u bHkgZm9yIEFDUD8gLy9SRTogSS1EIEFjdGlvbjogZHJhZnQtPGJyPg0KJmd0OyBiZWhyaW5nZXIt YW5pbWEtYXV0b25vbWljLWFkZHJlc3NpbmctMDEudHh0PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFJl LXJlYWRpbmcgbXkgb3duIG1lc3NhZ2UsIG9uZSB0aGluZyB0byBhZGQ6IEJyaWFuIGhhcyBhbHJl YWR5IHN0YXRlZCB0aGF0PGJyPg0KJmd0OyBHRE5QIGlzIHByb3RvY29sIGluZGVwZW5kZW50LCBh bmQgaXQgc2hvdWxkIGJlLiBPZiBjb3Vyc2Ugd2Ugd2FudCB0bzxicj4NCiZndDsgZGV2ZWxvcCBl dmVyeXRoaW5nIElQIHZlcnNpb24gaW5kZXBlbmRlbnQgd2hlcmV2ZXIgcG9zc2libGUuPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IEJ1dCB0aGVyZSBoYXMgdG8gYmUgc29tZSBkZWZhdWx0IGF1dG9ub21p YyBhZGRyZXNzaW5nLCByb3V0aW5nLCBhbmQgZm9yPGJyPg0KJmd0OyBUSEFUIHdlIHdhbnQgdG8g bG9vayBhdCBJUHY2IG9ubHkgYXQgdGhpcyBwb2ludC48YnI+DQomZ3Q7IDxicj4NCiZndDsgTWlj aGFlbDxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t PGJyPg0KJmd0OyAmZ3Q7IEZyb206IEFuaW1hIFs8YSBocmVmPSJtYWlsdG86YW5pbWEtYm91bmNl c0BpZXRmLm9yZyI+bWFpbHRvOmFuaW1hLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYg T2YgTWljaGFlbDxicj4NCiZndDsgJmd0OyBCZWhyaW5nZXIgKG1iZWhyaW5nKTxicj4NCiZndDsg Jmd0OyBTZW50OiAyNSBKdW5lIDIwMTUgMDk6MjU8YnI+DQomZ3Q7ICZndDsgVG86IER1em9uZ3Bl bmc7IE1pY2hhZWwgUmljaGFyZHNvbjxicj4NCiZndDsgJmd0OyBDYzogQW5pbWEgV0c8YnI+DQom Z3Q7ICZndDsgU3ViamVjdDogUmU6IFtBbmltYV0gV2hldGhlciBJUHY2IG9ubHkgZm9yIEFDUD8g Ly9SRTogSS1EIEFjdGlvbjo8YnI+DQomZ3Q7ICZndDsgZHJhZnQtIGJlaHJpbmdlci1hbmltYS1h dXRvbm9taWMtYWRkcmVzc2luZy0wMS50eHQ8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsg T0ssIEkgdGhpbmsgdGhlcmUgaXMgc29tZSBjb25mdXNpb24gYXJvdW5kIHRoaXMgdG9waWMuPGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEEgbmV0d29yayB3aXRoIGF1dG9ub21pYyBmdW5j dGlvbnMgKHdlIGFsbCBhZ3JlZSB0aGF0IGEgZnVsbHk8YnI+DQomZ3Q7ICZndDsgYXV0b25vbWlj IG5ldHdvcmsgaXMgbm90IG91ciBtYWluIHRhcmdldCBmb3Igbm93KSBjYW4gc3VwcG9ydCBvbiB0 aGU8YnI+DQomZ3Q7ICZndDsgKmRhdGEgcGxhbmUqIGFueSBwcm90b2NvbCB0aGUgb3BlcmF0b3Ig d2FudHMgdG8gdXNlLCBpbmNsdWRpbmcgSVB2NCw8YnI+DQomZ3Q7ICZndDsgYXBwbGV0YWxrIGFu ZCBJUHY4ICh3aGVuIGl0IGNvbWVzKS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgVGhl IHN0YXRlbWVudCBpcyBmb3IgdGhlIHNpZ25hbGxpbmcsIG1lc3NhZ2luZyBhbmQgb3RoZXIgcHJv dG9jb2xzPGJyPg0KJmd0OyAmZ3Q7IElOU0lERSB0aGUgQUNQLCB1c2VkIGJ5IEF1dG9ub21pYyBT ZXJ2aWNlIEFnZW50cy48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgQXV0b25vbWljIFNl cnZpY2UgQWdlbnRzIHdpbGwgYmUgZXhwb3NlZCB0byBhIGRldmVsb3BlciBjb21tdW5pdHksIGFu ZDxicj4NCiZndDsgJmd0OyB0aGUgdmVuZG9ycyBpbXBsZW1lbnRpbmcgdGhlIEFDUC4gVGhlcmUg aXMgYWJzb2x1dGVseSBubyByZWFzb24gdG88YnI+DQomZ3Q7ICZndDsgc3RhbmRhcmRpc2UgbW9y ZSB0aGFuIG9uZSBwcm90b2NvbCBmb3IgdGhpcyBwdXJwb3NlLjxicj4NCiZndDsgJmd0Ozxicj4N CiZndDsgJmd0OyBNaWNoYWVsUiBpcyByaWdodDogWW91IGRvbid0IG5lZWQgdG8gYWN0aXZlbHkg ZGVwbG95IElQdjYgdG8gdXNlIHRoZTxicj4NCiZndDsgJmd0OyBBQ1AuIEl0IGp1c3QgaGFwcGVu cy4gV2l0aCBvbmUgY2F2ZWF0OiBJZiB5b3UgY29ubmVjdCBhbiBOTVMgc3lzdGVtPGJyPg0KJmd0 OyAmZ3Q7IGludG8gdGhlIEFDUCBmb3IgJnF1b3Q7dmlydHVhbCBvdXQgb2YgYmFuZCZxdW90OyB1 c2FnZSwgdGhlbiB0aGF0IHN5c3RlbSBuZWVkczxicj4NCiZndDsgJmd0OyB0byBzdXBwb3J0IElQ djYuIEJ1dCB0aGF0IGlzIHR5cGljYWxseSBub3QgYSBwcm9ibGVtLCBpbiBvdXIgZXhwZXJpZW5j ZS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSW4gb3RoZXIgd29yZHM6IFdlJ3JlIHNh eWluZyB0aGF0ICphdXRvbm9taWMgZnVuY3Rpb25zKiAod2hpY2ggdGhlIGVuZDxicj4NCiZndDsg Jmd0OyB1c2VyIGlzbid0IGV4cG9zZWQgdG8gYXQgYWxsKSBhcmUgZXhjbHVzaXZlbHkgSVB2Niwg YnV0IHRoZSBuZXR3b3JrPGJyPg0KJmd0OyAmZ3Q7IGNhbiBwcm92aWRlIGFueSBzZXJ2aWNlIHRo ZSBvcGVyYXRvciB3YW50cy4gU3BlY2lmaWNhbGx5LCBhbiBhdXRvbm9taWM8YnI+DQomZ3Q7ICZn dDsgZnVuY3Rpb24gKHJ1bm5pbmcgb24gYW4gSVB2NiBjb250cm9sIHBsYW5lKSBtYXkgd2VsbCBu ZWdvdGlhdGU8YnI+DQomZ3Q7ICZndDsgYWRkcmVzc2luZyBmb3IgSVB2NCBzZXJ2aWNlcy48YnI+ DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgTWljaGFlbDxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgRnJvbTogRHV6b25ncGVuZyBbPGEgaHJlZj0ibWFpbHRvOmR1em9uZ3BlbmdAaHVhd2VpLmNv bSI+bWFpbHRvOmR1em9uZ3BlbmdAaHVhd2VpLmNvbTwvYT5dPGJyPg0KJmd0OyAmZ3Q7ICZndDsg U2VudDogMjUgSnVuZSAyMDE1IDA0OjA2PGJyPg0KJmd0OyAmZ3Q7ICZndDsgVG86IE1pY2hhZWwg UmljaGFyZHNvbjsgTWljaGFlbCBCZWhyaW5nZXIgKG1iZWhyaW5nKTxicj4NCiZndDsgJmd0OyAm Z3Q7IENjOiBBbmltYSBXRzxicj4NCiZndDsgJmd0OyAmZ3Q7IFN1YmplY3Q6IFdoZXRoZXIgSVB2 NiBvbmx5IGZvciBBQ1A/IC8vUkU6IFtBbmltYV0gSS1EIEFjdGlvbjogZHJhZnQtPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgYmVocmluZ2VyLWFuaW1hLWF1dG9ub21pYy1hZGRyZXNzaW5nLTAxLnR4dDxi cj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgSGksIE1pY2hhZWwgUmljaGFy ZHNvbjo8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IEkgYWdyZWUgd2l0 aCB5b3VyIG9wdGlvbi4gUGVyaGFwcyBBQ1AgaXMgbm90IG5lZWRlZCB0byBiZSBJUHY2IG9ubHku PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBPZiBjb3Vyc2UsIGFuIElQ djYgb25seSBhdXRvbm9taWMgY29udHJvbCBwbGFuZSBpcyBvayBmb3IgYWxsIHRoZTxicj4NCiZn dDsgJmd0OyAmZ3Q7IHNlcnZpY2VzIGluIGF1dG9ub21pYyBuZXR3b3JrLCBhbmQgdGhlIHNvbHV0 aW9uIGhhcyB0aGUgYWR2YW50YWdlIG9mPGJyPg0KJmd0OyAmZ3Q7ICZndDsgc2ltcGxpY2l0eSBh cyBtZW50aW9uZWQgYnkgTWljaGFlbCBCZWhyaW5nZXIuPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDsgJmd0OyBIb3dldmVyLCB0aGUgbmV0d29yayBvcGVyYXRvciBtYXkgYmUgbW9y ZSBmYW1pbGlhciB3aXRoIHRoZSBJUHY0LTxicj4NCiZndDsgJmd0OyAmZ3Q7IGJhc2UgbWFuYWdl bWVudC48YnI+DQomZ3Q7ICZndDsgJmd0OyBJbiB0aGUgYmVnaW5uaW5nIG9mIHRoZSBBQ1AgZGVw bG95bWVudCwgdGhlIG5ldHdvcmsgb3BlcmF0b3IgbWF5PGJyPg0KJmd0OyAmZ3Q7IG5vdDxicj4N CiZndDsgJmd0OyAmZ3Q7IGJlIHZlcnkgY29uZmlkZW50IGFib3V0IHRoZSBkZWNpc2lvbnMgbWFk ZSBieSB0aGUgYXV0b25vbWljIG5ldHdvcmsuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgU29tZSBraW5k cyBvZiBtb25pdG9yaW5nIGpvYnMgbWF5IGJlIGRlc2lyZWQgYnkgdGhlIG5ldHdvcmsgb3BlcmF0 b3JzLjxicj4NCiZndDsgJmd0OyAmZ3Q7IEF0IHRoaXMgdGltZSwgdGhlIG9wZXJhdG9yIG1heSB3 YW50IHRvIHNlZSBzb21lIElQdjQgYWRkcmVzc2VzLiBTbyw8YnI+DQomZ3Q7ICZndDsgJmd0OyBw ZXJoYXBzIHdlIG5lZWQgdG8gcHJvdmlkZSBJUHY0LWJhc2VkIEFDUCBhcyBhbiBvcHRpb24gZm9y IHRoZXNlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgcGFydHMgb2Ygb3BlcmF0b3JzLiBPdGhlcndpc2Us IHdlIGNhbiBvbmx5IGFuc3dlciB0aGVtICZxdW90O3NvcnJ5LCB3ZTxicj4NCiZndDsgJmd0OyAm Z3Q7IG9ubHkgc3VwcG9ydDxicj4NCiZndDsgJmd0OyAmZ3Q7IElQdjYgaGVyZSZxdW90Oy48YnI+ DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IEFzIElQdjQgaGFzIGJlZW4gd2lk ZWx5IGRlcGxveWVkLCBwZXJoYXBzIGFuIElQdjQtYmFzZWQ8YnI+DQomZ3Q7ICZndDsgYXV0b25v bWljPGJyPg0KJmd0OyAmZ3Q7ICZndDsgbmV0d29yayB3aWxsIGJlIGFjY2VwdGVkIGJ5IG1vcmUg bmV0d29yayBtYW5hZ2VycyBhdCB0aGUgYmVnaW5uaW5nLjxicj4NCiZndDsgJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7ICZndDsgSW5kZWVkLCBhdCB0aGlzIHRpbWUsIGFuIElQdjQtYmFzZWQgQUNQ IGlzIG5vdCBhcyBtYXR1cmUgYXMgdGhlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgSVB2NiBvbmUuIFRo dXMsIHBlcmhhcHMgc29tZSB3b3JrIG5lZWRzIHRvIGJlIGRvbmUgYXQgdGhpczxicj4NCiZndDsg Jmd0OyAmZ3Q7IGRpcmVjdGlvbi4gRm9yIGV4YW1wbGUsIGFzIHlvdSBtZW50aW9uZWQsIGhvdyBj YW4gd2UgZ2V0IGFuIGFkZHJlc3M8YnI+DQomZ3Q7ICZndDsgJmd0OyBpbnN0ZWFkIG9mIHRoZSBV TEEgaW4gSVB2Ni48YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IEJlc3Qg cmVnYXJkczxicj4NCiZndDsgJmd0OyAmZ3Q7IFpvbmdwZW5nIER1PGJyPg0KJmd0OyAmZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZn dDsgJmd0OyAmZ3Q7IEZyb206IEFuaW1hIFs8YSBocmVmPSJtYWlsdG86YW5pbWEtYm91bmNlc0Bp ZXRmLm9yZyI+bWFpbHRvOmFuaW1hLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2Yg TWljaGFlbDxicj4NCiZndDsgJmd0OyAmZ3Q7IFJpY2hhcmRzb248YnI+DQomZ3Q7ICZndDsgJmd0 OyBTZW50OiBUaHVyc2RheSwgSnVuZSAyNSwgMjAxNSAxOjEyIEFNPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgVG86IE1pY2hhZWwgQmVocmluZ2VyIChtYmVocmluZyk8YnI+DQomZ3Q7ICZndDsgJmd0OyBD YzogQW5pbWEgV0c8YnI+DQomZ3Q7ICZndDsgJmd0OyBTdWJqZWN0OiBSZTogW0FuaW1hXSBJLUQg QWN0aW9uOiBkcmFmdC1iZWhyaW5nZXItYW5pbWEtYXV0b25vbWljLTxicj4NCiZndDsgJmd0OyAm Z3Q7IGFkZHJlc3NpbmctMDEudHh0PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsg Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IE1pY2hhZWwgQmVocmluZ2VyIChtYmVocmluZykgJmx0 OzxhIGhyZWY9Im1haWx0bzptYmVocmluZ0BjaXNjby5jb20iPm1iZWhyaW5nQGNpc2NvLmNvbTwv YT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgSVB2NiBvbmx5 OiBBdXRvbm9taWMgcHJvY2Vzc2VzIHNob3VsZCB1c2UgZXhjbHVzaXZlbHkgSVB2NiwgZm9yPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyBzaW1wbGljaXR5IHJlYXNvbnMuPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyBJIGFn cmVlIHdpdGggdGhpcyBhcyBsb25nIGFzIGl0J3MgYW4gUkZDIDIxMTkgU0hPVUxELCBpLmUuPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgSVB2NCBjb3VsZCBiZSB1c2VkIGluPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OyZndDsgZXh0cmFvcmRpbmFyeSBjaXJjdW1zdGFuY2VzLiBUaGUgR0ROUCBkZXNpZ24g aXMgZnVuZGFtZW50YWxseTxicj4NCiZndDsgJmd0OyAmZ3Q7IElQLSB2ZXJzaW9uPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyZndDsgaW5kZXBlbmRlbnQuPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFllcywgYXMgbG9uZyBhcyBpdCdzIHJlYWxseSAmcXVvdDtl eHRyYW9yZGluYXJ5JnF1b3Q7IDstKSBUaGF0IDIxMTkgc2F5czxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgJnF1b3Q7U0hPVUxEJnF1b3Q7IG1lYW5zIGxpa2UgeW91IG5lZWQgYSByZWFsbHkgZ29v ZCByZWFzb24gdG8gbm90IGRvIGl0Ljxicj4NCiZndDsgV2hhdDxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgd291bGQgc3VjaCBhIGdvb2QgcmVhc29uIGJlPyBKdXN0IHNheWluZywgaW4gb3VyIGlt cGxlbWVudGF0aW9uIHdlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBvZnRlbiBnZXQgdGhlIHJl cXVpcmVtZW50ICZxdW90O3dlIHdhbnQgSVB2NCZxdW90OywgYW5kIHdoZW4geW91IGRpZyw8YnI+ DQomZ3Q7ICZndDsgJmd0OyB0aGUgcmVhc29uPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBpcyB0 aGF0IHRoZXkgZG9uJ3Qgd2FudCB0byBkZXBsb3kgSVB2NiwgYW5kIHRoYXQncyB0aGUgb25seTxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgcmVhc29uLiBTbGlwcGVyeSBzbG9wZS4uLjxicj4NCiZn dDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgYSkgdG8gcmVzcG9uZCB0byB0aGUgaW1t ZWRpYXRlICZxdW90O3dlIHdhbnQgSVB2NCZxdW90OyAtLS0gSSdkIGp1c3QgdGVsbCB0aGU8YnI+ DQomZ3Q7ICZndDsgY3VzdG9tZXI8YnI+DQomZ3Q7ICZndDsgJmd0OyB0aGF0IGl0IHVzZXMgYSBj dXN0b20gbGluayBsYXllciBwcm90b2NvbCB0aGF0IHVzZXMgYW4gZXRoZXJuZXQgdHlwZTxicj4N CiZndDsgJmd0OyAmZ3Q7IGRpZmZlcmVudCB0aGFuIDB4MDgwMC4uLiBqdXN0IGxpa2UgQ0RQIGRv ZXMgOi0pPGJyPg0KJmd0OyAmZ3Q7ICZndDsgKEkgZG9uJ3QgdGhpbmsgeW91IG5lZWQgdG8gJnF1 b3Q7ZGVwbG95JnF1b3Q7IElQdjYgdG8gaGF2ZSBhbiBBQ1AuLi4pPGJyPg0KJmd0OyAmZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBiKSB0aGUgb25seSB0aGluZyBJIGNhcmUgYWJvdXQgaXMg dGhhdCBub2JvZHkgaXMgYWxsb3dlZCB0byBzYXksICZxdW90O2J1dDxicj4NCiZndDsgJmd0OyAm Z3Q7IG1lY2hhbmlzbSBYWVogZG9lcyBub3QgZXhpc3QgaW4gSVB2NCZxdW90Oy4gVGhhdCdzIGFs bC4gSSBkb24ndCBrbm93IGlmPGJyPg0KJmd0OyAmZ3Q7ICZndDsgd2Ugd2lsbCBuZWVkIElQdjYt b25seSB0aGluZ3MsIGJ1dCBtYXliZS48YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyAmZ3Q7IC4uLjxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZn dDsgVXNlLVVMQTogRm9yIHRoZXNlIG92ZXJsYXkgYWRkcmVzc2VzIG9mIGF1dG9ub21pYyBub2Rl cywgd2U8YnI+DQomZ3Q7ICZndDsgJmd0OyB1c2UgVW5pcXVlPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyZndDsgTG9jYWwgQWRkcmVzc2VzIChVTEEpLCBhcyBzcGVjaWZpZWQgaW4gW1JGQzQxOTNd LiBBbiBhbHRlcm5hdGl2ZTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7IHNjaGVtZSB3YXMg ZGlzY3Vzc2VkLCB1c2luZyBhc3NpZ25lZCBVTEEgYWRkcmVzc2luZy4gVGhlPGJyPg0KJmd0OyAm Z3Q7IGNvbnNlbnN1czxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7IHdhcyB0byB1c2Ugc3Rh bmRhcmQgVUxBLCBiZWNhdXNlIGl0IHdhcyBkZWVtZWQgdG8gYmUgc3VmZmljaWVudC48YnI+DQom Z3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IEl0IG1pZ2h0IGJlIHRoYXQgVUxBIGlz IGFuIElQdjYtb25seSBmZWF0dXJlLjxicj4NCiZndDsgJmd0OyAmZ3Q7IEkgZG9uJ3QgY29uc2lk ZXIgMTAvOCB0byBiZSB0aGUgc2FtZSwgYXMgaXQgaXMgbm90IHN0YXRpc3RpY2FsbHk8YnI+DQom Z3Q7ICZndDsgJmd0OyB1bmlxdWUgaW5zaWRlIHRoZSBBUy48YnI+DQomZ3Q7ICZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyAmZ3Q7IC0tPGJyPg0KJmd0OyAmZ3Q7ICZndDsgTWljaGFlbCBSaWNoYXJk c29uICZsdDs8YSBocmVmPSJtYWlsdG86bWNyJiM0MztJRVRGQHNhbmRlbG1hbi5jYSI+bWNyJiM0 MztJRVRGQHNhbmRlbG1hbi5jYTwvYT4mZ3Q7LCBTYW5kZWxtYW4gU29mdHdhcmU8YnI+DQomZ3Q7 ICZndDsgV29ya3M8YnI+DQomZ3Q7ICZndDsgJmd0OyAtPSBJUHY2IElvVCBjb25zdWx0aW5nID0t PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCiZndDsgJmd0OyBBbmltYSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgPGEg aHJlZj0ibWFpbHRvOkFuaW1hQGlldGYub3JnIj5BbmltYUBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7 ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmlt YSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYTwvYT48YnI+DQom Z3Q7IDxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQomZ3Q7IEFuaW1hIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFp bHRvOkFuaW1hQGlldGYub3JnIj5BbmltYUBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWEiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWE8L2E+PGJyPg0KPGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpBbmltYSBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86QW5pbWFAaWV0Zi5vcmciPkFuaW1hQGlldGYub3Jn PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v YW5pbWEiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWE8L2E+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BAFEC9523F57BC48A51C20226A5589575E932046nkgeml505mbxchi_-- From nobody Fri Jun 26 03:27:47 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11B81A90DC for ; Fri, 26 Jun 2015 03:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uGRlTMcxhuI for ; Fri, 26 Jun 2015 03:27:44 -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 58F3C1A90D9 for ; Fri, 26 Jun 2015 03:27:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYA29611; Fri, 26 Jun 2015 10:27:42 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 26 Jun 2015 11:27:41 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.186]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Fri, 26 Jun 2015 18:27:34 +0800 From: "Liubing (Leo)" To: Anima WG Thread-Topic: Naming discussion (Section 4.1 of the Reference-Model draft) Thread-Index: AdCv+rXE5dOVpQhdRKmevUBqnlbbhA== Date: Fri, 26 Jun 2015 10:27:34 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45A6799F26@nkgeml506-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Anima] Naming discussion (Section 4.1 of the Reference-Model draft) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jun 2015 10:27:46 -0000 Hi Dear all, I've generated some text regarding to the naming of autonomic network devic= es. This is to fit the Section 4.1 in the Reference-Model draft. Below is the content which includes some rough ideas. Please feel free to c= omment. 4.1. Naming 4.1.1. Naming requirements o Representing each device Inside a domain, each autonomic device needs a domain specific identifier. [Open Questions] Are there devices that don't need names? Do ASAs need names? o Uniqueness The names MUST NOT collide within one autonomic domain. It is acceptable that the names in different domains collide, since they could be distinguished by domains. o Semantic Encoding It is RECOMMENDED that the names encode some semantics rather than meaningless strings. The semantics might be: + Location + Device type + Functional role + Ownership + etc. This is for ease of management consideration that network administrators could easily recognize the device directly through the names. o Consistency The devices' naming SHOULD follow the same pattern within a domain. 4.1.2. Proposed Mechanisms o Structured Naming Pattern The whole name string could be divided into several fields, each of which representing a specific semantic as described above. For example: Location-DeviceType-FunctionalRole- DistinguisherNumber@NameofDomain. The structure should be flexible that some fields are optional. When these optional fields are added, the name could still be recognized as the previous one. In above example, the "DistinguisherNumber" and "NameofDomain" are mandatory whereas others are optional. At initial stage, the devices might be only capable of self-generating the mandatory fields and the "DeviceType" because of the lack of knowledge. Later, they might have learned the "Location" and "FunctionalRole" and added the fields into current name. However, the other devices could still recognize it according to the same "DistinguisherNumber". o Advertised Common Fields Some fields in the structured name might be common among the domain (e.g. "Location" "NameofDomain"). Thus, these part of the names could be advertised through Intent Distribution (Section 4.5). o Self-generated Fields The mandatory fields SHOULD be self-generated so that one device could name itself sufficiently without any advertised knowledges. There should various methods for a device to extract/generate a proper word for each mandatory semantic fields (e.g. "DeviceType", "DistinguisherNum") from its self-knowledge. Detailed design of specific naming patterns and methods are out of scope of this document. Best regards, Bing From nobody Fri Jun 26 03:43:19 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC921ACD37 for ; Fri, 26 Jun 2015 03:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.712 X-Spam-Level: X-Spam-Status: No, score=0.712 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, MANGLED_ANIMAL=2.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-fIqgfluYwm for ; Fri, 26 Jun 2015 03:43:13 -0700 (PDT) Received: from webmail3.hi.local (www.outitgoes.com [79.170.40.67]) (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 5074E1ACD27 for ; Fri, 26 Jun 2015 03:43:13 -0700 (PDT) Received: from localhost ([127.0.0.1]) by webmail3.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1Z8R65-0002AK-HB; Fri, 26 Jun 2015 11:43:01 +0100 Message-Id: From: "Jonathan Hansford" To: "Duzongpeng" , "Jonathan Hansford" , "Michael Behringer (mbehring)" , "Michael Richardson" X-Mailer: Atmail 6.6.0.11156 X-Originating-IP: 212.159.131.152 in-reply-to: Date: Fri, 26 Jun 2015 11:43:01 +0100 Content-Type: multipart/alternative; boundary="=_d33dcf021ed30128641c16156d5f8bd6" MIME-Version: 1.0 Archived-At: Cc: Anima WG Subject: Re: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft-behringer-anima-autonomic-addressing-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jun 2015 10:43:17 -0000 --=_d33dcf021ed30128641c16156d5f8bd6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =0A=0A=09I'm thinking particularly about closed networks such as used by= the=0Amilitary where budgets can be tight, capabilities have to be trad= ed=0Aand replacement of many devices could occur in the 10+ years=0Atime= scale. Consequently many (most?) devices could be stuck on IPv4=0Afor a= long period of time. In those types of environments, network=0Amanageme= nt can be very labour intensive and the provision of autonomic=0Anetwork= ing could well be considered a far better investment than=0Aswitching to= IPv6, replacing a lot of expensive hardware that can only=0Asupport IPv= 4=0A=0A----- Original Message -----=0AFrom: "Duzongpeng" =0ATo:"Jonathan= Hansford" , "Michael Behringer (mbehring)" , "Michael=0ARichardson" =0A= Cc:"Anima WG" =0ASent:Fri, 26 Jun 2015 09:35:33 +0000=0ASubject:RE: [Ani= ma] Whether IPv6 only for ACP? //RE: I-D Action:=0Adraft-behringer-anima= -autonomic-addressing-01.txt=0A=0A=09Hi Jonathan:=0A=0A=09=C2=A0=0A=0A= =09=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I think you are talk= ing about the network in the=0Aenterprise and campus, where might be IPv= 4.=0A=0A=09=C2=A0=0A=0A=09=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 This part of customs don=E2=80=99t care much about what=0Atechnology= is used underneath the network. They only care about the=0Aservice laye= r.=0A=0A=09=C2=A0=0A=0A=09They want the detailed network information as= transparent as=0Apossible. Autonomic network can surely fulfill these n= eeds.=0A=0A=09=C2=A0=0A=0A=09Best Regards=0A=0A=09Zongpeng Du=0A=0A=09= =C2=A0=0A=0A=09FROM: Anima [mailto:anima-bounces@ietf.org] ON BEHALF OF= Jonathan=0AHansford=0ASENT: Friday, June 26, 2015 4:39 PM=0ATO: Michael= Behringer (mbehring); Duzongpeng; Michael Richardson=0ACC: Anima WG=0AS= UBJECT: Re: [Anima] Whether IPv6 only for ACP? //RE: I-D Action:=0Adraft= -behringer-anima-autonomic-addressing-01.txt=0A=0A=09=C2=A0=0A=0A=09Ther= e are some systems outside the Internet that have no urgent need=0Ato mo= ve to IPv6 and developers would rather focus on more urgent=0Aneeds. =C2= =A0Autonomic networking could well be one of those more urgent=0Aneeds.= =0A=0A=09=C2=A0=0A=0A=09Jonathan=0A=0A ----- Original Message -----=0A= =0A=09FROM:=0A=0A=09"Michael Behringer (mbehring)" =0A=0A=09=C2=A0=0A=0A= =09TO:=0A=0A=09"Duzongpeng" , "Michael Richardson" =0A=0A=09CC:=0A=0A=09= "Anima WG" =0A=0A=09SENT:=0A=0A=09Thu, 25 Jun 2015 11:56:19 +0000=0A=0A= =09SUBJECT:=0A=0A=09Re: [Anima] Whether IPv6 only for ACP? //RE: I-D Act= ion:=0Adraft-behringer-anima-autonomic-addressing-01.txt=0A=0A For somet= hing new like AN, where the standardised specs will take at=0Aleast a co= uple of years to appear in anyone's products, where we do=0ANOT have bac= kward compatibility issues, where we do not address end=0Asystems for so= me years to come, I personally think it is insane to=0Aeven consider IPv= 4. =0A=0A But I think we do have agreement that we start with IPv6 only,= and=0Ajust keep the door open, in case we need to support it. If the wo= rking=0Agroup wants to do that, I'll change the text accordingly. Maybe= a=0Adiscussion for Prague? =0A=0A Michael=0A=0A > -----Original Message= -----=0A > From: Duzongpeng [mailto:duzongpeng@huawei.com [5]]=0A > Sent= : 25 June 2015 10:24=0A > To: Michael Behringer (mbehring); Michael Rich= ardson=0A > Cc: Anima WG=0A > Subject: RE: [Anima] Whether IPv6 only for= ACP? //RE: I-D Action:=0Adraft-=0A > behringer-anima-autonomic-addressi= ng-01.txt=0A > =0A > Hi, Michael Behringer=0A > =0A > I agree that the d= efault setting of the ACP could be IPv6-based,=0Awhich may=0A > make the= communication across autonomic domains easier to=0Aimplement.=0A > =0A= > What I suggested is that we first have an IPv6-based ACP ready, and= =0Adefine=0A > an IPv4-based one as an alternative option.=0A > =0A > Be= st regards=0A > Zongpeng Du=0A > =0A > -----Original Message-----=0A > F= rom: Anima [mailto:anima-bounces@ietf.org [6]] On Behalf Of=0AMichael=0A= > Behringer (mbehring)=0A > Sent: Thursday, June 25, 2015 3:31 PM=0A >= To: Duzongpeng; Michael Richardson=0A > Cc: Anima WG=0A > Subject: Re:= [Anima] Whether IPv6 only for ACP? //RE: I-D Action:=0Adraft-=0A > behr= inger-anima-autonomic-addressing-01.txt=0A > =0A > Re-reading my own mes= sage, one thing to add: Brian has already=0Astated that=0A > GDNP is pro= tocol independent, and it should be. Of course we want=0Ato=0A > develop= everything IP version independent wherever possible.=0A > =0A > But the= re has to be some default autonomic addressing, routing, and=0Afor=0A >= THAT we want to look at IPv6 only at this point.=0A > =0A > Michael=0A= > =0A > > -----Original Message-----=0A > > From: Anima [mailto:anima-b= ounces@ietf.org [7]] On Behalf Of=0AMichael=0A > > Behringer (mbehring)= =0A > > Sent: 25 June 2015 09:25=0A > > To: Duzongpeng; Michael Richards= on=0A > > Cc: Anima WG=0A > > Subject: Re: [Anima] Whether IPv6 only for= ACP? //RE: I-D Action:=0A > > draft- behringer-anima-autonomic-addressi= ng-01.txt=0A > >=0A > > OK, I think there is some confusion around this= topic.=0A > >=0A > > A network with autonomic functions (we all agree t= hat a fully=0A > > autonomic network is not our main target for now) can= support on=0Athe=0A > > *data plane* any protocol the operator wants to= use, including=0AIPv4,=0A > > appletalk and IPv8 (when it comes).=0A >= >=0A > > The statement is for the signalling, messaging and other=0Apro= tocols=0A > > INSIDE the ACP, used by Autonomic Service Agents.=0A > >= =0A > > Autonomic Service Agents will be exposed to a developer=0Acommun= ity, and=0A > > the vendors implementing the ACP. There is absolutely no= reason=0Ato=0A > > standardise more than one protocol for this purpose.= =0A > >=0A > > MichaelR is right: You don't need to actively deploy IPv6= to use=0Athe=0A > > ACP. It just happens. With one caveat: If you conne= ct an NMS=0Asystem=0A > > into the ACP for "virtual out of band" usage,= then that system=0Aneeds=0A > > to support IPv6. But that is typically= not a problem, in our=0Aexperience.=0A > >=0A > > In other words: We're= saying that *autonomic functions* (which=0Athe end=0A > > user isn't ex= posed to at all) are exclusively IPv6, but the=0Anetwork=0A > > can prov= ide any service the operator wants. Specifically, an=0Aautonomic=0A > >= function (running on an IPv6 control plane) may well negotiate=0A > > a= ddressing for IPv4 services.=0A > >=0A > > Michael=0A > >=0A > > > -----= Original Message-----=0A > > > From: Duzongpeng [mailto:duzongpeng@huawe= i.com [8]]=0A > > > Sent: 25 June 2015 04:06=0A > > > To: Michael Richar= dson; Michael Behringer (mbehring)=0A > > > Cc: Anima WG=0A > > > Subjec= t: Whether IPv6 only for ACP? //RE: [Anima] I-D Action:=0Adraft-=0A > >= > behringer-anima-autonomic-addressing-01.txt=0A > > >=0A > > > Hi, Mic= hael Richardson:=0A > > >=0A > > > I agree with your option. Perhaps ACP= is not needed to be IPv6=0Aonly.=0A > > >=0A > > > Of course, an IPv6 o= nly autonomic control plane is ok for all=0Athe=0A > > > services in aut= onomic network, and the solution has the=0Aadvantage of=0A > > > simplic= ity as mentioned by Michael Behringer.=0A > > >=0A > > > However, the ne= twork operator may be more familiar with the=0AIPv4-=0A > > > base manag= ement.=0A > > > In the beginning of the ACP deployment, the network oper= ator=0Amay=0A > > not=0A > > > be very confident about the decisions mad= e by the autonomic=0Anetwork.=0A > > > Some kinds of monitoring jobs may= be desired by the network=0Aoperators.=0A > > > At this time, the opera= tor may want to see some IPv4 addresses.=0ASo,=0A > > > perhaps we need= to provide IPv4-based ACP as an option for=0Athese=0A > > > parts of op= erators. Otherwise, we can only answer them "sorry,=0Awe=0A > > > only s= upport=0A > > > IPv6 here".=0A > > >=0A > > > As IPv4 has been widely de= ployed, perhaps an IPv4-based=0A > > autonomic=0A > > > network will be= accepted by more network managers at the=0Abeginning.=0A > > >=0A > > >= Indeed, at this time, an IPv4-based ACP is not as mature as the=0A > >= > IPv6 one. Thus, perhaps some work needs to be done at this=0A > > > d= irection. For example, as you mentioned, how can we get an=0Aaddress=0A= > > > instead of the ULA in IPv6.=0A > > >=0A > > > Best regards=0A > >= > Zongpeng Du=0A > > >=0A > > > -----Original Message-----=0A > > > Fro= m: Anima [mailto:anima-bounces@ietf.org [9]] On Behalf Of=0AMichael=0A >= > > Richardson=0A > > > Sent: Thursday, June 25, 2015 1:12 AM=0A > > >= To: Michael Behringer (mbehring)=0A > > > Cc: Anima WG=0A > > > Subject= : Re: [Anima] I-D Action:=0Adraft-behringer-anima-autonomic-=0A > > > ad= dressing-01.txt=0A > > >=0A > > >=0A > > > Michael Behringer (mbehring)= wrote:=0A > > > >> > IPv6 only: Autonomic processes should use exclusi= vely=0AIPv6, for=0A > > > >> > simplicity reasons.=0A > > > >>=0A > > >= >> I agree with this as long as it's an RFC 2119 SHOULD, i.e.=0A > > >= IPv4 could be used in=0A > > > >> extraordinary circumstances. The GDNP= design is=0Afundamentally=0A > > > IP- version=0A > > > >> independent.= =0A > > >=0A > > > > Yes, as long as it's really "extraordinary" ;-) Tha= t 2119=0Asays=0A > > > > "SHOULD" means like you need a really good reas= on to not do=0Ait.=0A > What=0A > > > > would such a good reason be? Jus= t saying, in our=0Aimplementation we=0A > > > > often get the requiremen= t "we want IPv4", and when you dig,=0A > > > the reason=0A > > > > is th= at they don't want to deploy IPv6, and that's the only=0A > > > > reason= Slippery slope...=0A > > >=0A > > > a) to respond to the immediate "we= want IPv4" --- I'd just tell=0Athe=0A > > customer=0A > > > that it use= s a custom link layer protocol that uses an ethernet=0Atype=0A > > > dif= ferent than 0x0800... just like CDP does :-)=0A > > > (I don't think you= need to "deploy" IPv6 to have an ACP...)=0A > > >=0A > > > b) the only= thing I care about is that nobody is allowed to=0Asay, "but=0A > > > me= chanism XYZ does not exist in IPv4". That's all. I don't know=0Aif=0A >= > > we will need IPv6-only things, but maybe.=0A > > >=0A > > > ...=0A= > > >=0A > > > >> Use-ULA: For these overlay addresses of autonomic nod= es, we=0A > > > use Unique=0A > > > >> Local Addresses (ULA), as specifi= ed in [RFC4193]. An=0Aalternative=0A > > > >> scheme was discussed, usin= g assigned ULA addressing. The=0A > > consensus=0A > > > >> was to use s= tandard ULA, because it was deemed to be=0Asufficient.=0A > > >=0A > > >= It might be that ULA is an IPv6-only feature.=0A > > > I don't consider= 10/8 to be the same, as it is not=0Astatistically=0A > > > unique insid= e the AS.=0A > > >=0A > > > --=0A > > > Michael Richardson , Sandelman S= oftware=0A > > Works=0A > > > -=3D IPv6 IoT consulting =3D-=0A > > >=0A= > > >=0A > >=0A > > _______________________________________________=0A= > > Anima mailing list=0A > > Anima@ietf.org [12]=0A > > https://www.ie= tf.org/mailman/listinfo/anima [13]=0A > =0A > __________________________= _____________________=0A > Anima mailing list=0A > Anima@ietf.org [14]= =0A > https://www.ietf.org/mailman/listinfo/anima [15]=0A=0A ___________= ____________________________________=0A Anima mailing list=0AAnima@ietf.= org [16]=0Ahttps://www.ietf.org/mailman/listinfo/anima [17]=0A=0A=09 = =0A=0ALinks:=0A------=0A[1] mailto:mbehring@cisco.com=0A[2] mailto:duzo= ngpeng@huawei.com=0A[3] mailto:mcr+ietf@sandelman.ca=0A[4] mailto:anima@= ietf.org=0A[5] mailto:duzongpeng@huawei.com=0A[6] mailto:anima-bounces@i= etf.org=0A[7] mailto:anima-bounces@ietf.org=0A[8] mailto:duzongpeng@huaw= ei.com=0A[9] mailto:anima-bounces@ietf.org=0A[10] mailto:mbehring@cisco.= com=0A[11] mailto:mcr+IETF@sandelman.ca=0A[12] mailto:Anima@ietf.org=0A[= 13] https://www.ietf.org/mailman/listinfo/anima=0A[14] mailto:Anima@ietf= org=0A[15] https://www.ietf.org/mailman/listinfo/anima=0A[16] mailto:An= ima@ietf.org=0A[17] https://www.ietf.org/mailman/listinfo/anima=0A --=_d33dcf021ed30128641c16156d5f8bd6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I'm thinking particularly about closed netwo= rks such as used by the military where budgets can be tight, capabilitie= s have to be traded and replacement of many devices could occur in the 1= 0+ years timescale. Consequently many (most?) devices could be stuck on= IPv4 for a long period of time. In those types of environments, network= management can be very labour intensive and the provision of autonomic= networking could well be considered a far better investment than switch= ing to IPv6, replacing a lot of expensive hardware that can only support= IPv4



----- Original Message ----= -
From:
"Duzongpeng" <duzongpeng@huawei.co= m>

To:
"Jonathan Han= sford" <jonathan@hansfords.net>, "Michael Behringer (mbehring)" &l= t;mbehring@cisco.com>, "Michael Richardson" <mcr+ietf@sandelman.ca= >
Cc:
"Anima WG" <anima= @ietf.org>
Sent:
Fri, 26 J= un 2015 09:35:33 +0000
Subject:RE: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft-behrin= ger-anima-autonomic-addressing-01.txt


=0A

Hi Jonathan:

=0A

=C2=A0

=0A

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I think you are talk= ing about the network in the enterprise and campus, where might be IPv4.=

=0A

=C2=A0

=0A

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This part of customs don=E2=80=99t care m= uch about what technology is used underneath the network. They only care= about the service layer.

=0A

=C2=A0

=0A

They want the detailed network informa= tion as transparent as possible. Autonomic network can surely fulfill th= ese needs.

=0A

=C2=A0

=0A

Best Rega= rds

=0A

Zongpeng Du

=0A

<= p>=C2=A0

=0A
=0A
=0A

Anima= [mailto:anima-bounces@ietf.org]=0AOn Behalf Of Jonathan Hansford=
Sent: Friday, June 26, 2015 4:39 PM
To: Michael= Behringer (mbehring); Duzongpeng; Michael Richardson
Cc: An= ima WG
Subject: Re: [Anima] Whether IPv6 only for ACP? //RE:= I-D Action: draft-behringer-anima-autonomic-addressing-01.txt

=0A
=0A
=0A

=C2=A0

=0A

There are some systems outside= the Internet that have no urgent need to move to IPv6 and developers wo= uld rather focus on more urgent needs. =C2=A0Autonomic networking=0A cou= ld well be one of those more urgent needs.

=0A=0A

= =C2=A0

=0A
=0A
=0A

Jonathan

=0A


=0A----- Original Message -----

=0A=0A
=0A

From:

=0A
=0A<= p class=3D"MsoNormal" style=3D"background:#e4e4e4;">"Michael Behringer (mbehring)" <mbehring@cisco.com>

=0A
= =0A

=C2= =A0

=0A
=0A

To:

=0A
=0A

"Duzongpeng" <duzongpeng@huawei.com>, "Michael Richardson"= <mcr+ietf@sandelman.ca&= gt;

=0A
=0A

Cc:

=0A
=0A

"Anima WG" <anima@ietf.org>

= =0A
=0A

Sent:<= /span>

=0A
=0A

Thu, 25 Jun 2015 11:56:19 +0000

=

=0A
=0A

Su= bject:

=0A
=0A

Re: [Anima] Whether IPv6 only for ACP? //RE:= I-D Action: draft-behringer-anima-autonomic-addressing-01.txt

=0AFor something new like AN, where the standardised specs will= take at least a couple of years to appear in anyone's products, where w= e do NOT have backward compatibility issues, where we do not address end= systems for some years to come, I personally think it=0A is insane to e= ven consider IPv4.

=0ABut I think we do have agreement that= we start with IPv6 only, and just keep the door open, in case we need t= o support it. If the working group wants to do that, I'll change the tex= t accordingly. Maybe a discussion for Prague?=0A

=0AMichael
=0A> -----Original Message-----
=0A> From: Duzongpe= ng [mailto:duzongpeng@huawei.co= m]
=0A> Sent: 25 June 2015 10:24
=0A> To: Michael Be= hringer (mbehring); Michael Richardson
=0A> Cc: Anima WG
= =0A> Subject: RE: [Anima] Whether IPv6 only for ACP? //RE: I-D Action= : draft-
=0A> behringer-anima-autonomic-addressing-01.txt
= =0A>
=0A> Hi, Michael Behringer
=0A>
=0A> I= agree that the default setting of the ACP could be IPv6-based, which ma= y
=0A> make the communication across autonomic domains easier to= implement.
=0A>
=0A> What I suggested is that we first= have an IPv6-based ACP ready, and define
=0A> an IPv4-based one= as an alternative option.
=0A>
=0A> Best regards
= =0A> Zongpeng Du
=0A>
=0A> -----Original Message----= -
=0A> From: Anima [ma= ilto:anima-bounces@ietf.org] On Behalf Of Michael
=0A> Behri= nger (mbehring)
=0A> Sent: Thursday, June 25, 2015 3:31 PM
= =0A> To: Duzongpeng; Michael Richardson
=0A> Cc: Anima WG=0A> Subject: Re: [Anima] Whether IPv6 only for ACP? //RE: I-D Act= ion: draft-
=0A> behringer-anima-autonomic-addressing-01.txt=0A>
=0A> Re-reading my own message, one thing to add: Br= ian has already stated that
=0A> GDNP is protocol independent, a= nd it should be. Of course we want to
=0A> develop everything IP= version independent wherever possible.
=0A>
=0A> But t= here has to be some default autonomic addressing, routing, and for
= =0A> THAT we want to look at IPv6 only at this point.
=0A> =0A> Michael
=0A>
=0A> > -----Original Messag= e-----
=0A> > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael
=0A= > > Behringer (mbehring)
=0A> > Sent: 25 June 2015 09:2= 5
=0A> > To: Duzongpeng; Michael Richardson
=0A> >= Cc: Anima WG
=0A> > Subject: Re: [Anima] Whether IPv6 only f= or ACP? //RE: I-D Action:
=0A> > draft- behringer-anima-auton= omic-addressing-01.txt
=0A> >
=0A> > OK, I think t= here is some confusion around this topic.
=0A> >
=0A>= > A network with autonomic functions (we all agree that a fully
=0A> > autonomic network is not our main target for now) can supp= ort on the
=0A> > *data plane* any protocol the operator want= s to use, including IPv4,
=0A> > appletalk and IPv8 (when it= comes).
=0A> >
=0A> > The statement is for the si= gnalling, messaging and other protocols
=0A> > INSIDE the ACP= , used by Autonomic Service Agents.
=0A> >
=0A> >= Autonomic Service Agents will be exposed to a developer community, and<= br />=0A> > the vendors implementing the ACP. There is absolutely= no reason to
=0A> > standardise more than one protocol for t= his purpose.
=0A> >
=0A> > MichaelR is right: You= don't need to actively deploy IPv6 to use the
=0A> > ACP. It= just happens. With one caveat: If you connect an NMS system
=0A>= ; > into the ACP for "virtual out of band" usage, then that system ne= eds
=0A> > to support IPv6. But that is typically not a probl= em, in our experience.
=0A> >
=0A> > In other word= s: We're saying that *autonomic functions* (which the end
=0A> &= gt; user isn't exposed to at all) are exclusively IPv6, but the network<= br />=0A> > can provide any service the operator wants. Specifical= ly, an autonomic
=0A> > function (running on an IPv6 control= plane) may well negotiate
=0A> > addressing for IPv4 service= s.
=0A> >
=0A> > Michael
=0A> >
= =0A> > > -----Original Message-----
=0A> > > From= : Duzongpeng [mailto:duzongpeng= @huawei.com]
=0A> > > Sent: 25 June 2015 04:06
= =0A> > > To: Michael Richardson; Michael Behringer (mbehring)=0A> > > Cc: Anima WG
=0A> > > Subject: Wheth= er IPv6 only for ACP? //RE: [Anima] I-D Action: draft-
=0A> >= > behringer-anima-autonomic-addressing-01.txt
=0A> > >=
=0A> > > Hi, Michael Richardson:
=0A> > >=0A> > > I agree with your option. Perhaps ACP is not neede= d to be IPv6 only.
=0A> > >
=0A> > > Of cour= se, an IPv6 only autonomic control plane is ok for all the
=0A>= > > services in autonomic network, and the solution has the advan= tage of
=0A> > > simplicity as mentioned by Michael Behrin= ger.
=0A> > >
=0A> > > However, the network= operator may be more familiar with the IPv4-
=0A> > > bas= e management.
=0A> > > In the beginning of the ACP deploym= ent, the network operator may
=0A> > not
=0A> > &g= t; be very confident about the decisions made by the autonomic network.<= br />=0A> > > Some kinds of monitoring jobs may be desired by t= he network operators.
=0A> > > At this time, the operator= may want to see some IPv4 addresses. So,
=0A> > > perhaps= we need to provide IPv4-based ACP as an option for these
=0A> &= gt; > parts of operators. Otherwise, we can only answer them "sorry,= we
=0A> > > only support
=0A> > > IPv6 here= ".
=0A> > >
=0A> > > As IPv4 has been widely= deployed, perhaps an IPv4-based
=0A> > autonomic
=0A>= ; > > network will be accepted by more network managers at the beg= inning.
=0A> > >
=0A> > > Indeed, at this ti= me, an IPv4-based ACP is not as mature as the
=0A> > > IPv= 6 one. Thus, perhaps some work needs to be done at this
=0A> >= ; > direction. For example, as you mentioned, how can we get an addre= ss
=0A> > > instead of the ULA in IPv6.
=0A> >= >
=0A> > > Best regards
=0A> > > Zongpen= g Du
=0A> > >
=0A> > > -----Original Message= -----
=0A> > > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael
=0A> > > Richardson
=0A> > > Sent: Thursday, Jun= e 25, 2015 1:12 AM
=0A> > > To: Michael Behringer (mbehrin= g)
=0A> > > Cc: Anima WG
=0A> > > Subject: R= e: [Anima] I-D Action: draft-behringer-anima-autonomic-
=0A> >= ; > addressing-01.txt
=0A> > >
=0A> > >=0A> > > Michael Behringer (mbehring) <mbehring@cisco.com> wrote:
=0A> >= > >> > IPv6 only: Autonomic processes should use exclusivel= y IPv6, for
=0A> > > >> > simplicity reasons.=0A> > > >>
=0A> > > >> I agree wi= th this as long as it's an RFC 2119 SHOULD, i.e.
=0A> > >= IPv4 could be used in
=0A> > > >> extraordinary cir= cumstances. The GDNP design is fundamentally
=0A> > > IP-= version
=0A> > > >> independent.
=0A> >= >
=0A> > > > Yes, as long as it's really "extraordi= nary" ;-) That 2119 says
=0A> > > > "SHOULD" means like= you need a really good reason to not do it.
=0A> What
=0A&= gt; > > > would such a good reason be? Just saying, in our impl= ementation we
=0A> > > > often get the requirement "we= want IPv4", and when you dig,
=0A> > > the reason
= =0A> > > > is that they don't want to deploy IPv6, and that'= s the only
=0A> > > > reason. Slippery slope...
= =0A> > >
=0A> > > a) to respond to the immediate= "we want IPv4" --- I'd just tell the
=0A> > customer
= =0A> > > that it uses a custom link layer protocol that uses an= ethernet type
=0A> > > different than 0x0800... just like= CDP does :-)
=0A> > > (I don't think you need to "deploy"= IPv6 to have an ACP...)
=0A> > >
=0A> > > b= ) the only thing I care about is that nobody is allowed to say, "but=0A> > > mechanism XYZ does not exist in IPv4". That's all.= I don't know if
=0A> > > we will need IPv6-only things, b= ut maybe.
=0A> > >
=0A> > > ...
=0A>= > >
=0A> > > >> Use-ULA: For these overlay ad= dresses of autonomic nodes, we
=0A> > > use Unique
= =0A> > > >> Local Addresses (ULA), as specified in [RFC41= 93]. An alternative
=0A> > > >> scheme was discussed= , using assigned ULA addressing. The
=0A> > consensus
= =0A> > > >> was to use standard ULA, because it was deeme= d to be sufficient.
=0A> > >
=0A> > > It mig= ht be that ULA is an IPv6-only feature.
=0A> > > I don't c= onsider 10/8 to be the same, as it is not statistically
=0A> >= ; > unique inside the AS.
=0A> > >
=0A> > &g= t; --
=0A> > > Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software=0A> > Works
=0A> > > -=3D IPv6 IoT consulting= =3D-
=0A> > >
=0A> > >
=0A> >=0A> > _______________________________________________
=0A= > > Anima mailing list
=0A> > Anima@ietf.org
=0A> > https://www.ietf.org/mailman/listinfo/anim= a
=0A>
=0A> _______________________________________= ________
=0A> Anima mailing list
=0A> Anima@ietf.org
=0A> https://www.ietf.org/mailman/listinfo/an= ima

=0A_______________________________________________=0AAnima mailing list
Anima@ie= tf.org
= https://www.ietf.org/mailman/listinfo/anima

= =0A
=0A
=0A=0A --=_d33dcf021ed30128641c16156d5f8bd6-- From nobody Fri Jun 26 07:56:56 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCC111B3046 for ; Fri, 26 Jun 2015 07:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2iyeSxD6X2L for ; Fri, 26 Jun 2015 07:56:51 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADBE61B3042 for ; Fri, 26 Jun 2015 07:56:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9694; q=dns/txt; s=iport; t=1435330611; x=1436540211; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=zgUSGFlIHqKsBtcggUvt1/sSBkc4DImYrAlTtwRNvD8=; b=gARnN2JmVC/N5bHAcDspRdRm3lYS4kjhlhvBtBP1YqrTIdlsgRD68PND q2xst1zt7tDOiS7usGQms0UR2isSXQO1psZTwlatzC0nnUHGnmwNXE0PC I27mrLWC3Mco52vtPt4r4KPLf5ogvH38tA62AEM/QdsoALZ7wlKlgS5Tw Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AVBQAMaI1V/4QNJK1bgxFUX70lCYFcCoJEgzQCgTo4FAEBAQEBAQGBCoQiAQEBBAEBATU2Cg0ECxEEAQEBCRYEBAcJAwIBAgEVHwkIEwYCAQEXiBQNv0+PbwEBAQEBAQEDAQEBAQEBAQEBFQSLSoQ3BFIGhCUBBJQEi1KBOoZ7jCeDXCZjgSkcFYFZIjGCSAEBAQ X-IronPort-AV: E=Sophos;i="5.13,685,1427760000"; d="scan'208";a="4949011" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-9.cisco.com with ESMTP; 26 Jun 2015 14:56:49 +0000 Received: from [10.86.255.30] ([10.86.255.30]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t5QEume7022124 for ; Fri, 26 Jun 2015 14:56:48 GMT Message-ID: <558D6830.9080008@cisco.com> Date: Fri, 26 Jun 2015 10:56:48 -0400 From: Paul Duffy Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: anima@ietf.org References: <20150618095520.3486.7068.idtracker@ietfa.amsl.com> <55876E20.2070508@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0FDC@xmb-rcd-x14.cisco.com> <21740.1435165907@sandelman.ca> <558C7343.9000802@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F55A5BB@nkgeml512-mbx.china.huawei.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF5CA2@xmb-rcd-x14.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B925F55A6F4@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B925F55A6F4@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft-behringer-anima-autonomic-addressing-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: paduffy@cisco.com List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 14:56:54 -0000 Surely this WG understands the difference in the IPv6 deployment situation 2001 versus 2015. All major platform OSs ship today IPv6 enabled. Many major service providers are already IPv6 enabled or in the process of switching over. IEC TC57 (Power Systems) requires that all new and evolution of current standards support IPv6 starting 2015. The embedded RTOS space is a laggard, but that is also changing fast. IPv6 is the only way to go in the constrained / LLN space ... look at the work ongoing in the IETF 6lo, Wi-SUN Alliance, Thread Group, OIC, uPnP, etc. I could go on further, but I'm bored ;) Are we really going to argue AMINA IPv4 support based on the situation in 2001? Its my strong desire that this WG not in any way let IPv4 considerations delay your ACP work. Lead us into the future. Cheers On 6/26/2015 3:41 AM, Sheng Jiang wrote: > So, you are saying we should never have a IPv4-based Autonomic Network? It may be waste if all devices have been dual-stack or IPv6-only. But it would still be long way to come. I have been working on IPv6 since 2001. At that time, we were expecting IPv4 might be terminated by 2006. There are new features that are developed with IPv6, but later they are also adopted into IPv4. In last 20 years, the technologies in IPv4 did not stop. If ACP or other AN functions can be incrementally added into legacy IPv4 devices, it would not be any harm for owners. So, that AN is new does not mean it could not use in IPv4. > > Don't get me wrong. I am NOT arguing that we "must" do that. Again, as I said, we "may" do that with low priority while I don't think it harms. If there are clearly requirements from operators, we may rise the "may" to be "should". > > Regards, > > Sheng > >> -----Original Message----- >> From: Michael Behringer (mbehring) [mailto:mbehring@cisco.com] >> Sent: Friday, June 26, 2015 3:14 PM >> To: Sheng Jiang; Brian E Carpenter; anima@ietf.org; Michael Richardson >> Cc: Duzongpeng >> Subject: RE: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: >> draft-behringer-anima-autonomic-addressing-01.txt >> >> Sheng: WHY??? Why would you want an IPv4 control plane? If you have a >> good answer to that question, we can argue. :-) >> >> Take BGP: It can run on either v4 or v6, and it can negotiate any protocol >> under the sun. the control plane protocol has little to do with what it >> negotiates. >> >> Take ISIS: It's not even IP!! >> >> Other WGs may have good reasons: For example: interfacing end systems >> where we cannot expect IPv6 support. AN is NEW, the ANI is NEW, there is no >> legacy. >> >> Michael >> >>> -----Original Message----- >>> From: Sheng Jiang [mailto:jiangsheng@huawei.com] >>> Sent: 26 June 2015 03:32 >>> To: Brian E Carpenter; anima@ietf.org; Michael Behringer (mbehring); >>> Michael Richardson >>> Cc: Duzongpeng >>> Subject: RE: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft- >>> behringer-anima-autonomic-addressing-01.txt >>> >>> Hi, Brian and Michael B, >>> >>> In my reading, it seems we take a wrong argument here. What we are >>> talking about is NOT stop IPv6-based ACP. It is remaining on our priority or >>> default choice. Technically, I am not sure the possibility or feasibility IP >>> independent. If yes, IP independent may be preferred over IPv6-only. >>> >>> But meanwhile, a parallel IPv4-based ACP (or IP independent) mechanism >>> should not bring any harm. IPv4 based Internet/networks are still having the >>> motivation to improve itself. Particularly, many closed enterprise networks >>> many remain IPv4-only for a while. Many IETF WG, such as DHC, are >> working >>> on both IPv4 and IPv6 simultaneously, of course, with IPv4 in lower >>> preference and priority. >>> >>> "IPv4 management" use case for AN, running over an IPv6 ACP would also >>> be an interest use case. It is valuable in the dual stack network or "running >>> IPv4 as a service". >>> >>> Regards, >>> >>> Sheng >>> >>>> -----Original Message----- >>>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E >>>> Carpenter >>>> Sent: Friday, June 26, 2015 5:32 AM >>>> To: anima@ietf.org >>>> Subject: Re: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: >>>> draft-behringer-anima-autonomic-addressing-01.txt >>>> >>>> On 25/06/2015 14:06, Duzongpeng wrote: >>>>> Hi, Michael Richardson: >>>>> >>>>> I agree with your option. Perhaps ACP is not needed to be IPv6 only. >>>> However, IPv6 has an enormous advantage in a cold start with all >>>> devices assumed in factory condition. Every IPv6 stack will acquire a >>>> valid link-local address even if no other device (such as a router or >>>> DHCP server) is configured and there is no Intent in place. That is what we >>> need for a true AN. >>>>> Of course, an IPv6 only autonomic control plane is ok for all the >>>>> services >>>> in autonomic network, and the solution has the advantage of simplicity >>>> as mentioned by Michael Behringer. >>>>> However, the network operator may be more familiar with the >>>>> IPv4-base >>>> management. >>>> >>>> I'm sorry but such operators are quickly becoming dinosaurs. Looking at >>>> the current growth rate of IPv6, and knowing that it will take several >>>> years for Anima work to be complete, I think those operators will be in >>>> serious trouble. >>>> >>>>> In the beginning of the ACP deployment, the network operator may >>> not >>>> be very confident about the decisions made by the autonomic network. >>>> Some kinds of monitoring jobs may be desired by the network operators. >>>> At this time, the operator may want to see some IPv4 addresses. >>>> >>>> Their traditional NMS could still be IPv4, and they could still see >>>> IPv4 information through an IPv6 ACP. >>>> >>>>> So, perhaps we need to provide IPv4-based ACP as an option for these >>>>> parts >>>> of operators. Otherwise, we can only answer them "sorry, we only >>>> support >>>> IPv6 here". >>>> >>>> No, the answer is "IPv6 will be deployed automatically with no work by >>>> you, but old IPv4 services will not be interrupted." >>>> >>>> Actually we should think about an "IPv4 management" use case for AN, >>>> running over an IPv6 ACP. >>>> >>>> Best regards, >>>> Brian >>>> >>>>> As IPv4 has been widely deployed, perhaps an IPv4-based >>> autonomic >>>> network will be accepted by more network managers at the beginning. >>>>> Indeed, at this time, an IPv4-based ACP is not as mature as the IPv6 >>> one. >>>> Thus, perhaps some work needs to be done at this direction. For >>>> example, as you mentioned, how can we get an address instead of the ULA >>> in IPv6. >>>>> Best regards >>>>> Zongpeng Du >>>>> >>>>> -----Original Message----- >>>>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael >>>> Richardson >>>>> Sent: Thursday, June 25, 2015 1:12 AM >>>>> To: Michael Behringer (mbehring) >>>>> Cc: Anima WG >>>>> Subject: Re: [Anima] I-D Action: >>>> draft-behringer-anima-autonomic-addressing-01.txt >>>>> >>>>> Michael Behringer (mbehring) wrote: >>>>> >> > IPv6 only: Autonomic processes should use exclusively IPv6, >> for >>>>> >> > simplicity reasons. >>>>> >> >>>>> >> I agree with this as long as it's an RFC 2119 SHOULD, i.e. >>>>> IPv4 could >>>> be used in >>>>> >> extraordinary circumstances. The GDNP design is fundamentally >>>> IP-version >>>>> >> independent. >>>>> >>>>> > Yes, as long as it's really "extraordinary" ;-) That 2119 says >>>>> > "SHOULD" means like you need a really good reason to not do it. >>>> What >>>>> > would such a good reason be? Just saying, in our implementation >> we >>>>> > often get the requirement "we want IPv4", and when you dig, the >>>> reason >>>>> > is that they don't want to deploy IPv6, and that's the only >>>>> > reason. Slippery slope... >>>>> >>>>> a) to respond to the immediate "we want IPv4" --- I'd just tell the >>> customer >>>>> that it uses a custom link layer protocol that uses an ethernet type >>>>> different than 0x0800... just like CDP does :-) >>>>> (I don't think you need to "deploy" IPv6 to have an ACP...) >>>>> >>>>> b) the only thing I care about is that nobody is allowed to say, "but >>>>> mechanism XYZ does not exist in IPv4". That's all. I don't know if >>>>> we will need IPv6-only things, but maybe. >>>>> >>>>> ... >>>>> >>>>> >> Use-ULA: For these overlay addresses of autonomic nodes, we >>>>> use >>>> Unique >>>>> >> Local Addresses (ULA), as specified in [RFC4193]. An >> alternative >>>>> >> scheme was discussed, using assigned ULA addressing. The >>>> consensus >>>>> >> was to use standard ULA, because it was deemed to be >> sufficient. >>>>> It might be that ULA is an IPv6-only feature. >>>>> I don't consider 10/8 to be the same, as it is not statistically >>>>> unique inside >>>> the AS. >>>>> -- >>>>> Michael Richardson , Sandelman Software >>>> Works -= IPv6 IoT consulting =- >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > . > From nobody Fri Jun 26 11:47:20 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7451ABD35 for ; Fri, 26 Jun 2015 11:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7sqgdHZC0sr for ; Fri, 26 Jun 2015 11:47:18 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA14C1ABD3B for ; Fri, 26 Jun 2015 11:47:15 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 97181200A3 for ; Fri, 26 Jun 2015 15:02:31 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 50BAB63AE8; Fri, 26 Jun 2015 14:47:14 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3779A63AD9 for ; Fri, 26 Jun 2015 14:47:14 -0400 (EDT) From: Michael Richardson To: "Anima WG" In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft-behringer-anima-autonomic-addressing-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jun 2015 18:47:19 -0000 --=-=-= Content-Type: text/plain Jonathan Hansford wrote: > There are some systems outside the Internet that have no urgent need > to move to IPv6 and developers would rather focus on more urgent > needs. Autonomic networking could well be one of those more urgent > needs. The Autonomic Control Plane is *not* IPv6. It just looks like IPv6. It's a new fangled protocol that has nothing to do with any of the deployed production network. As such, it is *ENTIRELY* greenfield. It's all new code. It likely doesn't even get forwarded using whatever ASICs your hardware might have... If someone wants to do this with something that looks like IPv4, that's fine, but I want nobody complaining if we specify a mechanism (such as ULAs or ND or SEND) that does never been defined in the thing that looks like IPv4. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVY2eMYCLcPvd0N1lAQJ19gf/WJlEwcjEgeAQy8pxnafHgZaRq4PCE8N3 vXXo4j9KetRKZkih+lTdqI0yqgI++of24zzk/x48tyPfT58+LZOWyV7tJiXjgg41 BEeDn7DjJHHOvdYvHkt1an+s2GydRF8NK0OinpYij/vgYO1skiS6rDPNiTy7UEUp sTcKBfuJzNNnhTVhMvCKBAU7Ux6g/GdooJ31ab0/+Lfu0SJegWuBd9tmGXR3EoZK NG2liaJs7NWXNW8N4kaRneMI4n+LqMGtdZaMFU3XTyHJlmgYMoAQVwfCPqdHC1Lw ZdEf9hzEp9A7RCCrfoWY6d0OC/4uVYtFFfF4/eq1zUSOCAn5mE1dQw== =4UpI -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 26 13:45:31 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B501ACD1C for ; Fri, 26 Jun 2015 13:45:29 -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 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 8LuRRXk-58f5 for ; Fri, 26 Jun 2015 13:45:27 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (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 70E631A8900 for ; Fri, 26 Jun 2015 13:45:27 -0700 (PDT) Received: by pdbci14 with SMTP id ci14so81004513pdb.2 for ; Fri, 26 Jun 2015 13:45:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Qf6rjfXq63/OKhhd9j64f/wIfKB3prlFNHYABGNE1vc=; b=WHj+Tf0/CC/8ZLc+dldBg1pg0ZVTmhX4hCSk5Zo9Me3009YCtxK5hMHbpDNmhwiaZw Gq0yWWGTWucdtEVWTxzEZyV5hp0S8WG6A6V8gSyLmrkSJ0YPRt8RRrExmxLfxYErHnFo 1zANyULW7CMjg4SQwynZlnEBhU3K3Fk+6lzn6AUt+TXmGZ3TKJClL6wdvtY8S+HQuZy9 IknjMKnmv7RJSr8V7WNgMeFOOSDfgWEN8+lZ+FfVkty6wW9cYhEISY5n6WbtK3rob9zf vlNC6+UlrBzzq96Nal9cpBxzhkKGVCqwY2fqGo5I2wyIHJB2E31p0QZqEnyIckQ0pEOf 0TwQ== X-Received: by 10.68.185.37 with SMTP id ez5mr6984207pbc.74.1435351527192; Fri, 26 Jun 2015 13:45:27 -0700 (PDT) Received: from ?IPv6:2406:e007:4e59:1:28cc:dc4c:9703:6781? ([2406:e007:4e59:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id pb6sm10475998pbc.75.2015.06.26.13.45.24 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jun 2015 13:45:25 -0700 (PDT) Message-ID: <558DB9ED.3040207@gmail.com> Date: Sat, 27 Jun 2015 08:45:33 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: anima@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft-behringer-anima-autonomic-addressing-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jun 2015 20:45:29 -0000 On 26/06/2015 20:36, Jonathan Hansford wrote: > There are some systems outside the Internet that have no urgent need > to move to IPv6 and developers would rather focus on more urgent > needs. Autonomic networking could well be one of those more urgent > needs. What is the harm if the AN products that they install happen to configure themselves to use IPv6? Since any router that acts as an autonomic node will be modern enough to support an IPv6 ACP with no manual intervention, why would the operator even know or care? Brian > Jonathan > > ----- Original Message ----- > From: "Michael Behringer (mbehring)" > To:"Duzongpeng" , "Michael Richardson" > Cc:"Anima WG" > Sent:Thu, 25 Jun 2015 11:56:19 +0000 > Subject:Re: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: > draft-behringer-anima-autonomic-addressing-01.txt > > For something new like AN, where the standardised specs will take at > least a couple of years to appear in anyone's products, where we do > NOT have backward compatibility issues, where we do not address end > systems for some years to come, I personally think it is insane to > even consider IPv4. > > But I think we do have agreement that we start with IPv6 only, and > just keep the door open, in case we need to support it. If the working > group wants to do that, I'll change the text accordingly. Maybe a > discussion for Prague? > > Michael > > > -----Original Message----- > > From: Duzongpeng [mailto:duzongpeng@huawei.com] > > Sent: 25 June 2015 10:24 > > To: Michael Behringer (mbehring); Michael Richardson > > Cc: Anima WG > > Subject: RE: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: > draft- > > behringer-anima-autonomic-addressing-01.txt > > > > Hi, Michael Behringer > > > > I agree that the default setting of the ACP could be IPv6-based, > which may > > make the communication across autonomic domains easier to > implement. > > > > What I suggested is that we first have an IPv6-based ACP ready, and > define > > an IPv4-based one as an alternative option. > > > > Best regards > > Zongpeng Du > > > > -----Original Message----- > > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael > > Behringer (mbehring) > > Sent: Thursday, June 25, 2015 3:31 PM > > To: Duzongpeng; Michael Richardson > > Cc: Anima WG > > Subject: Re: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: > draft- > > behringer-anima-autonomic-addressing-01.txt > > > > Re-reading my own message, one thing to add: Brian has already > stated that > > GDNP is protocol independent, and it should be. Of course we want > to > > develop everything IP version independent wherever possible. > > > > But there has to be some default autonomic addressing, routing, and > for > > THAT we want to look at IPv6 only at this point. > > > > Michael > > > > > -----Original Message----- > > > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael > > > Behringer (mbehring) > > > Sent: 25 June 2015 09:25 > > > To: Duzongpeng; Michael Richardson > > > Cc: Anima WG > > > Subject: Re: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: > > > draft- behringer-anima-autonomic-addressing-01.txt > > > > > > OK, I think there is some confusion around this topic. > > > > > > A network with autonomic functions (we all agree that a fully > > > autonomic network is not our main target for now) can support on > the > > > *data plane* any protocol the operator wants to use, including > IPv4, > > > appletalk and IPv8 (when it comes). > > > > > > The statement is for the signalling, messaging and other > protocols > > > INSIDE the ACP, used by Autonomic Service Agents. > > > > > > Autonomic Service Agents will be exposed to a developer > community, and > > > the vendors implementing the ACP. There is absolutely no reason > to > > > standardise more than one protocol for this purpose. > > > > > > MichaelR is right: You don't need to actively deploy IPv6 to use > the > > > ACP. It just happens. With one caveat: If you connect an NMS > system > > > into the ACP for "virtual out of band" usage, then that system > needs > > > to support IPv6. But that is typically not a problem, in our > experience. > > > > > > In other words: We're saying that *autonomic functions* (which > the end > > > user isn't exposed to at all) are exclusively IPv6, but the > network > > > can provide any service the operator wants. Specifically, an > autonomic > > > function (running on an IPv6 control plane) may well negotiate > > > addressing for IPv4 services. > > > > > > Michael > > > > > > > -----Original Message----- > > > > From: Duzongpeng [mailto:duzongpeng@huawei.com] > > > > Sent: 25 June 2015 04:06 > > > > To: Michael Richardson; Michael Behringer (mbehring) > > > > Cc: Anima WG > > > > Subject: Whether IPv6 only for ACP? //RE: [Anima] I-D Action: > draft- > > > > behringer-anima-autonomic-addressing-01.txt > > > > > > > > Hi, Michael Richardson: > > > > > > > > I agree with your option. Perhaps ACP is not needed to be IPv6 > only. > > > > > > > > Of course, an IPv6 only autonomic control plane is ok for all > the > > > > services in autonomic network, and the solution has the > advantage of > > > > simplicity as mentioned by Michael Behringer. > > > > > > > > However, the network operator may be more familiar with the > IPv4- > > > > base management. > > > > In the beginning of the ACP deployment, the network operator > may > > > not > > > > be very confident about the decisions made by the autonomic > network. > > > > Some kinds of monitoring jobs may be desired by the network > operators. > > > > At this time, the operator may want to see some IPv4 addresses. > So, > > > > perhaps we need to provide IPv4-based ACP as an option for > these > > > > parts of operators. Otherwise, we can only answer them "sorry, > we > > > > only support > > > > IPv6 here". > > > > > > > > As IPv4 has been widely deployed, perhaps an IPv4-based > > > autonomic > > > > network will be accepted by more network managers at the > beginning. > > > > > > > > Indeed, at this time, an IPv4-based ACP is not as mature as the > > > > IPv6 one. Thus, perhaps some work needs to be done at this > > > > direction. For example, as you mentioned, how can we get an > address > > > > instead of the ULA in IPv6. > > > > > > > > Best regards > > > > Zongpeng Du > > > > > > > > -----Original Message----- > > > > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of > Michael > > > > Richardson > > > > Sent: Thursday, June 25, 2015 1:12 AM > > > > To: Michael Behringer (mbehring) > > > > Cc: Anima WG > > > > Subject: Re: [Anima] I-D Action: > draft-behringer-anima-autonomic- > > > > addressing-01.txt > > > > > > > > > > > > Michael Behringer (mbehring) wrote: > > > > >> > IPv6 only: Autonomic processes should use exclusively > IPv6, for > > > > >> > simplicity reasons. > > > > >> > > > > >> I agree with this as long as it's an RFC 2119 SHOULD, i.e. > > > > IPv4 could be used in > > > > >> extraordinary circumstances. The GDNP design is > fundamentally > > > > IP- version > > > > >> independent. > > > > > > > > > Yes, as long as it's really "extraordinary" ;-) That 2119 > says > > > > > "SHOULD" means like you need a really good reason to not do > it. > > What > > > > > would such a good reason be? Just saying, in our > implementation we > > > > > often get the requirement "we want IPv4", and when you dig, > > > > the reason > > > > > is that they don't want to deploy IPv6, and that's the only > > > > > reason. Slippery slope... > > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Fri Jun 26 18:37:06 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 462841B2AB0 for ; Fri, 26 Jun 2015 18:37:05 -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 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 YAmsP2WGMEiU for ; Fri, 26 Jun 2015 18:37:03 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FB371A6F7A for ; Fri, 26 Jun 2015 18:37:03 -0700 (PDT) Received: by pabvl15 with SMTP id vl15so76794143pab.1 for ; Fri, 26 Jun 2015 18:37:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jRVfjsHxgqHXMbYSWJr6MIAJhMBNUoKqnxcw2KSSGV4=; b=HU/5JTlz+U8Zg/ZGpWcc6qBPgSWPB3M+Gw7U+E8nI6QGsc3Cv/P0+S/35Sc34LXoJ1 TgcJ6kEyi8fPjKl0InlKRUCho2x9uqaZlMOGd+5eojY0bcihAk2skyhs4L9EhDKdx4/M uwTdRdwI1z0X3l/JmJV3Za/+SfUoOammonVZ+24UwGA5eMYvdfh9NWXnczdU5DqzEc4U gUCyT9K3g9IRJTsgfXhG53sJJzuRo0XXon7/VK3B/BhA9GnuSt+6yYjUIwkgrC1zVdMX 0nrlfhFQISuXa+tUM80cPhJqiOjvpI+RONSdDDH1RzYgsIcjkhqOfXFkyErVlPkIG0n2 BWJQ== X-Received: by 10.68.252.168 with SMTP id zt8mr8803332pbc.1.1435369023194; Fri, 26 Jun 2015 18:37:03 -0700 (PDT) Received: from ?IPv6:2406:e007:4e59:1:28cc:dc4c:9703:6781? ([2406:e007:4e59:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id y2sm19978625pdi.80.2015.06.26.18.36.59 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jun 2015 18:37:01 -0700 (PDT) Message-ID: <558DFE45.4050906@gmail.com> Date: Sat, 27 Jun 2015 13:37:09 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: anima@ietf.org References: <8AE0F17B87264D4CAC7DE0AA6C406F45A6799F26@nkgeml506-mbx.china.huawei.com> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45A6799F26@nkgeml506-mbx.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Naming discussion (Section 4.1 of the Reference-Model draft) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 27 Jun 2015 01:37:05 -0000 On 26/06/2015 22:27, Liubing (Leo) wrote: > Hi Dear all, > > I've generated some text regarding to the naming of autonomic network devices. This is to fit the Section 4.1 in the Reference-Model draft. > Below is the content which includes some rough ideas. Please feel free to comment. > > 4.1. Naming > > 4.1.1. Naming requirements > > o Representing each device > Inside a domain, each autonomic device needs a domain specific > identifier. > [Open Questions] Are there devices that don't need names? Do > ASAs need names? > > o Uniqueness > The names MUST NOT collide within one autonomic domain. > It is acceptable that the names in different domains collide, > since they could be distinguished by domains. Well, yes, we have a system for that, which is the DNS. Is there any reason not to use DNS names? > o Semantic Encoding > It is RECOMMENDED that the names encode some semantics rather > than meaningless strings. The semantics might be: > + Location > + Device type > + Functional role > + Ownership > + etc. > This is for ease of management consideration that network > administrators could easily recognize the device directly > through the names. I'm generally against making this a formal recommendation. I understand very well that it may be a common operational practice already, but it's quite subject to human error and in a truly autonomic network nobody should ever see the names anyway. Also, they would need to change autonomically whenever the topology changes. Brian > o Consistency > The devices' naming SHOULD follow the same pattern within a > domain. > > 4.1.2. Proposed Mechanisms > > o Structured Naming Pattern > The whole name string could be divided into several fields, > each of which representing a specific semantic as described > above. For example: Location-DeviceType-FunctionalRole- > DistinguisherNumber@NameofDomain. > > The structure should be flexible that some fields are optional. > When these optional fields are added, the name could still be > recognized as the previous one. In above example, the > "DistinguisherNumber" and "NameofDomain" are mandatory whereas > others are optional. At initial stage, the devices might be > only capable of self-generating the mandatory fields and the > "DeviceType" because of the lack of knowledge. Later, they > might have learned the "Location" and "FunctionalRole" and > added the fields into current name. However, the other devices > could still recognize it according to the same > "DistinguisherNumber". > > o Advertised Common Fields > Some fields in the structured name might be common among the > domain (e.g. "Location" "NameofDomain"). Thus, these part of > the names could be advertised through Intent > Distribution (Section 4.5). > > o Self-generated Fields > The mandatory fields SHOULD be self-generated so that one > device could name itself sufficiently without any advertised > knowledges. > There should various methods for a device to extract/generate a > proper word for each mandatory semantic fields (e.g. > "DeviceType", "DistinguisherNum") from its self-knowledge. > > Detailed design of specific naming patterns and methods are out of > scope of this document. > > > > Best regards, > Bing > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Fri Jun 26 18:46:26 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 624661B2AF7 for ; Fri, 26 Jun 2015 18:46:25 -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 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 UHNcfGAnNjTe for ; Fri, 26 Jun 2015 18:46:23 -0700 (PDT) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::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 CFB831B2AF5 for ; Fri, 26 Jun 2015 18:46:23 -0700 (PDT) Received: by pdbci14 with SMTP id ci14so84099610pdb.2 for ; Fri, 26 Jun 2015 18:46:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=22UBAF5aqAWHlBUBA+9zoWqAMWwm0vH4xWqVOofPQHg=; b=oBZUprX9YeiUDZ0tPnXh07kVYdjJDrlhG+RC0FxonZ9wAwWg3Gc3+94gGmxofIoD92 N7oqzF8X66HnNA61fYtB0w7pPJEHBtTt6gxC2kdtWQVtDQlJif25g/GH2b3J0DpI5jEo XEP9vpv91ANuTyGm44k2wkHS6iN8730FaG/tToAWsQsIWt31JJLbtBDqwuW3PGsLsTG7 E3YB1Kx4lKhsHPlzczgeFZoJaD7mWhxDQ09u5B9cLXVjluKazqvJ/pwYfKre8ONzbPGd Y/hWrRCBgpDyQuRA+G5JDcLLtdbiqRYFvAmXzsZFdaUGqt+1fHNEOmjP3g7UJh6ZDfsU dRJw== X-Received: by 10.68.247.166 with SMTP id yf6mr8748716pbc.3.1435369583517; Fri, 26 Jun 2015 18:46:23 -0700 (PDT) Received: from ?IPv6:2406:e007:4e59:1:28cc:dc4c:9703:6781? ([2406:e007:4e59:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id j7sm34676036pdp.83.2015.06.26.18.46.20 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jun 2015 18:46:22 -0700 (PDT) Message-ID: <558E0076.90201@gmail.com> Date: Sat, 27 Jun 2015 13:46:30 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: anima@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Anima] Central element [Questions on RFC7575] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 27 Jun 2015 01:46:25 -0000 On 24/06/2015 15:57, John Strassner wrote: =2E.. > What is a "central element"? Does this mean that the feedback loop incl= udes > centralized management mechanisms, or that there is additional logic > outside of just the nodes? >=20 >=20 >=20 > MB: A central element is a controller for example. The point of the sec= tion > is: You could define an =E2=80=9Cautonomic network=E2=80=9D where every= node has exactly > the same interfaces as today (primarily CLI, SNMP, NETCONF), and where = a > controller is involved in all control loops. Our definition of =E2=80=9C= autonomic=E2=80=9D > is further down in the network, where nodes interact directly with node= s. > Now we all understand this isn=E2=80=99t black and white, but the empha= sis of the > work in the IETF should be node-to-node interactions. >=20 > OK, got it. Just to ensure, is it fair to say that a "central > element" is one in which non-autonomic functions are used that may affe= ct > the behavior of autonomic nodes? >=20 > MB2: This is correct but not complete. Because also a normal node has > non-autonomic functions that may affect the behaviour of that node (or > others). >=20 > True, but I wouldn't think of a "normal node" as a "central > element". So perhaps the language needs to be widened? At an earlier stage in the protocol draft, we had strong emphasis on hierarchical structure, and discovering one's hierarchical superior. We have gradually reduced that in the text to the observation that in an AN, discovering your "superior" is no different than discovering other peers; it's just a source of information or shared resource like any other. I think the same logic will apply to "central" elements. They are nodes that some human has chosen to put a label on saying "central" and they happen to receive resources and Intent and maybe other information from humans, for wider distribution. But the network is a mesh, not a tree, and these nodes are just arbitrary points in the mesh (or the cloud, if you prefer a modern buzzword). Brian From nobody Fri Jun 26 18:55:51 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2322F1A004E for ; Fri, 26 Jun 2015 18:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zq00zGK66OS3 for ; Fri, 26 Jun 2015 18:55:47 -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 D73391A0020 for ; Fri, 26 Jun 2015 18:55:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYA86900; Sat, 27 Jun 2015 01:55:45 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 27 Jun 2015 02:55:44 +0100 Received: from NKGEML505-MBX.china.huawei.com ([169.254.1.218]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Sat, 27 Jun 2015 09:55:38 +0800 From: Duzongpeng To: "paduffy@cisco.com" , "anima@ietf.org" Thread-Topic: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft-behringer-anima-autonomic-addressing-01.txt Thread-Index: AQHQr45pvgg3y1Hre0qREj6wAypd6p29epqAgABfnQCAAAd7AIAAebsAgAE49XA= Date: Sat, 27 Jun 2015 01:55:37 +0000 Message-ID: References: <20150618095520.3486.7068.idtracker@ietfa.amsl.com> <55876E20.2070508@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0FDC@xmb-rcd-x14.cisco.com> <21740.1435165907@sandelman.ca> <558C7343.9000802@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F55A5BB@nkgeml512-mbx.china.huawei.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF5CA2@xmb-rcd-x14.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B925F55A6F4@nkgeml512-mbx.china.huawei.com> <558D6830.9080008@cisco.com> In-Reply-To: <558D6830.9080008@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.149.226] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft-behringer-anima-autonomic-addressing-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 27 Jun 2015 01:55:50 -0000 Hi Paul: I want make some clarifications. What I have suggested is to do an IPv6-AC= P first, and considering an IPv4 one if needed. So, I don't think it results in any delay for the former one. I agree that it is the trend that IPv6 will replace IPv4 in future, but fo= r better popularization of Autonomic network, maybe we can provide some alt= ernative options to network operators. Best Regards Zongpeng Du -----Original Message----- From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Paul Duffy Sent: Friday, June 26, 2015 10:57 PM To: anima@ietf.org Subject: Re: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft-beh= ringer-anima-autonomic-addressing-01.txt Surely this WG understands the difference in the IPv6 deployment situation = 2001 versus 2015. All major platform OSs ship today IPv6 enabled. Many major service provide= rs are already IPv6 enabled or in the process of switching over.=20 IEC TC57 (Power Systems) requires that all new and evolution of current sta= ndards support IPv6 starting 2015. The embedded RTOS space is a laggard, bu= t that is also changing fast. IPv6 is the only way to go in the constrained= / LLN space ... look at the work ongoing in the IETF 6lo, Wi-SUN Alliance,= Thread Group, OIC, uPnP, etc. I could go on further, but I'm bored ;) Are we really going to argue AMINA IPv4 support based on the situation in 2= 001? Its my strong desire that this WG not in any way let IPv4 considerations de= lay your ACP work. Lead us into the future. Cheers On 6/26/2015 3:41 AM, Sheng Jiang wrote: > So, you are saying we should never have a IPv4-based Autonomic Network? I= t may be waste if all devices have been dual-stack or IPv6-only. But it wou= ld still be long way to come. I have been working on IPv6 since 2001. At th= at time, we were expecting IPv4 might be terminated by 2006. There are new = features that are developed with IPv6, but later they are also adopted into= IPv4. In last 20 years, the technologies in IPv4 did not stop. If ACP or o= ther AN functions can be incrementally added into legacy IPv4 devices, it w= ould not be any harm for owners. So, that AN is new does not mean it could = not use in IPv4. > > Don't get me wrong. I am NOT arguing that we "must" do that. Again, as I = said, we "may" do that with low priority while I don't think it harms. If t= here are clearly requirements from operators, we may rise the "may" to be "= should". > > Regards, > > Sheng > >> -----Original Message----- >> From: Michael Behringer (mbehring) [mailto:mbehring@cisco.com] >> Sent: Friday, June 26, 2015 3:14 PM >> To: Sheng Jiang; Brian E Carpenter; anima@ietf.org; Michael=20 >> Richardson >> Cc: Duzongpeng >> Subject: RE: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: >> draft-behringer-anima-autonomic-addressing-01.txt >> >> Sheng: WHY??? Why would you want an IPv4 control plane? If you have a=20 >> good answer to that question, we can argue. :-) >> >> Take BGP: It can run on either v4 or v6, and it can negotiate any=20 >> protocol under the sun. the control plane protocol has little to do=20 >> with what it negotiates. >> >> Take ISIS: It's not even IP!! >> >> Other WGs may have good reasons: For example: interfacing end systems=20 >> where we cannot expect IPv6 support. AN is NEW, the ANI is NEW, there=20 >> is no legacy. >> >> Michael >> >>> -----Original Message----- >>> From: Sheng Jiang [mailto:jiangsheng@huawei.com] >>> Sent: 26 June 2015 03:32 >>> To: Brian E Carpenter; anima@ietf.org; Michael Behringer (mbehring);=20 >>> Michael Richardson >>> Cc: Duzongpeng >>> Subject: RE: [Anima] Whether IPv6 only for ACP? //RE: I-D Action:=20 >>> draft- behringer-anima-autonomic-addressing-01.txt >>> >>> Hi, Brian and Michael B, >>> >>> In my reading, it seems we take a wrong argument here. What we are=20 >>> talking about is NOT stop IPv6-based ACP. It is remaining on our=20 >>> priority or default choice. Technically, I am not sure the=20 >>> possibility or feasibility IP independent. If yes, IP independent may b= e preferred over IPv6-only. >>> >>> But meanwhile, a parallel IPv4-based ACP (or IP independent)=20 >>> mechanism should not bring any harm. IPv4 based Internet/networks=20 >>> are still having the motivation to improve itself. Particularly,=20 >>> many closed enterprise networks many remain IPv4-only for a while.=20 >>> Many IETF WG, such as DHC, are >> working >>> on both IPv4 and IPv6 simultaneously, of course, with IPv4 in lower=20 >>> preference and priority. >>> >>> "IPv4 management" use case for AN, running over an IPv6 ACP would=20 >>> also be an interest use case. It is valuable in the dual stack=20 >>> network or "running >>> IPv4 as a service". >>> >>> Regards, >>> >>> Sheng >>> >>>> -----Original Message----- >>>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E=20 >>>> Carpenter >>>> Sent: Friday, June 26, 2015 5:32 AM >>>> To: anima@ietf.org >>>> Subject: Re: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: >>>> draft-behringer-anima-autonomic-addressing-01.txt >>>> >>>> On 25/06/2015 14:06, Duzongpeng wrote: >>>>> Hi, Michael Richardson: >>>>> >>>>> I agree with your option. Perhaps ACP is not needed to be IPv6 only. >>>> However, IPv6 has an enormous advantage in a cold start with all=20 >>>> devices assumed in factory condition. Every IPv6 stack will acquire=20 >>>> a valid link-local address even if no other device (such as a=20 >>>> router or DHCP server) is configured and there is no Intent in=20 >>>> place. That is what we >>> need for a true AN. >>>>> Of course, an IPv6 only autonomic control plane is ok for all the=20 >>>>> services >>>> in autonomic network, and the solution has the advantage of=20 >>>> simplicity as mentioned by Michael Behringer. >>>>> However, the network operator may be more familiar with the=20 >>>>> IPv4-base >>>> management. >>>> >>>> I'm sorry but such operators are quickly becoming dinosaurs.=20 >>>> Looking at the current growth rate of IPv6, and knowing that it=20 >>>> will take several years for Anima work to be complete, I think=20 >>>> those operators will be in serious trouble. >>>> >>>>> In the beginning of the ACP deployment, the network operator may >>> not >>>> be very confident about the decisions made by the autonomic network. >>>> Some kinds of monitoring jobs may be desired by the network operators. >>>> At this time, the operator may want to see some IPv4 addresses. >>>> >>>> Their traditional NMS could still be IPv4, and they could still see >>>> IPv4 information through an IPv6 ACP. >>>> >>>>> So, perhaps we need to provide IPv4-based ACP as an option for=20 >>>>> these parts >>>> of operators. Otherwise, we can only answer them "sorry, we only=20 >>>> support >>>> IPv6 here". >>>> >>>> No, the answer is "IPv6 will be deployed automatically with no work=20 >>>> by you, but old IPv4 services will not be interrupted." >>>> >>>> Actually we should think about an "IPv4 management" use case for=20 >>>> AN, running over an IPv6 ACP. >>>> >>>> Best regards, >>>> Brian >>>> >>>>> As IPv4 has been widely deployed, perhaps an IPv4-based >>> autonomic >>>> network will be accepted by more network managers at the beginning. >>>>> Indeed, at this time, an IPv4-based ACP is not as mature as the=20 >>>>> IPv6 >>> one. >>>> Thus, perhaps some work needs to be done at this direction. For=20 >>>> example, as you mentioned, how can we get an address instead of the=20 >>>> ULA >>> in IPv6. >>>>> Best regards >>>>> Zongpeng Du >>>>> >>>>> -----Original Message----- >>>>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael >>>> Richardson >>>>> Sent: Thursday, June 25, 2015 1:12 AM >>>>> To: Michael Behringer (mbehring) >>>>> Cc: Anima WG >>>>> Subject: Re: [Anima] I-D Action: >>>> draft-behringer-anima-autonomic-addressing-01.txt >>>>> >>>>> Michael Behringer (mbehring) wrote: >>>>> >> > IPv6 only: Autonomic processes should use exclusively=20 >>>>> IPv6, >> for >>>>> >> > simplicity reasons. >>>>> >> >>>>> >> I agree with this as long as it's an RFC 2119 SHOULD, i.e. >>>>> IPv4 could >>>> be used in >>>>> >> extraordinary circumstances. The GDNP design is=20 >>>>> fundamentally >>>> IP-version >>>>> >> independent. >>>>> >>>>> > Yes, as long as it's really "extraordinary" ;-) That 2119 sa= ys >>>>> > "SHOULD" means like you need a really good reason to not do it= . >>>> What >>>>> > would such a good reason be? Just saying, in our=20 >>>>> implementation >> we >>>>> > often get the requirement "we want IPv4", and when you dig,=20 >>>>> the >>>> reason >>>>> > is that they don't want to deploy IPv6, and that's the only >>>>> > reason. Slippery slope... >>>>> >>>>> a) to respond to the immediate "we want IPv4" --- I'd just tell=20 >>>>> the >>> customer >>>>> that it uses a custom link layer protocol that uses an ethernet t= ype >>>>> different than 0x0800... just like CDP does :-) >>>>> (I don't think you need to "deploy" IPv6 to have an ACP...) >>>>> >>>>> b) the only thing I care about is that nobody is allowed to say, "but >>>>> mechanism XYZ does not exist in IPv4". That's all. I don't know= if >>>>> we will need IPv6-only things, but maybe. >>>>> >>>>> ... >>>>> >>>>> >> Use-ULA: For these overlay addresses of autonomic nodes,=20 >>>>> we use >>>> Unique >>>>> >> Local Addresses (ULA), as specified in [RFC4193]. An >> alternative >>>>> >> scheme was discussed, using assigned ULA addressing. The >>>> consensus >>>>> >> was to use standard ULA, because it was deemed to be >> sufficient. >>>>> It might be that ULA is an IPv6-only feature. >>>>> I don't consider 10/8 to be the same, as it is not statistically=20 >>>>> unique inside >>>> the AS. >>>>> -- >>>>> Michael Richardson , Sandelman Software >>>> Works -=3D IPv6 IoT consulting =3D- >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 > _______________________________________________ > 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 Fri Jun 26 19:11:13 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7CBD1B2BC8 for ; Fri, 26 Jun 2015 19:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-p-Cuvn_vuR for ; Fri, 26 Jun 2015 19:11:10 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CF371B2BC7 for ; Fri, 26 Jun 2015 19:11:09 -0700 (PDT) Received: by lagx9 with SMTP id x9so73991478lag.1 for ; Fri, 26 Jun 2015 19:11:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Tek0CzFz8a2cxYpU12NUn+koZzbSB/f7OTIWDMCZPAo=; b=drpcMAE18JxriwdUpJxtSxSUvGErTT1HGgfGzC9orCqg0AVqZ1GblccJ/o0WbEn8YN hLmzicmtnkkG6WW+dnI44Ii7/mFWiybt9eCnY10wUBg0vZyNurIak0zi1RWjTkfQ7H8K FY+3p3g4HNek8TWUXFzFF3VJv8UEyXbAMJUSy6G5wBB6bOF45GwgYs91BeTi+wbXECHg rajd6rKCL9C6jbtIAX+vs66vg3JEiCKkD8oUJg/ELZnjPz469R9JhMyxbb1cWspHiAC5 Pnr05oW3yIqQZx+vMynE0Gyb67xH+lfXs2qgA6D1aVkiv/Xna7f/2QeDc45XSGv4gbG4 S9hg== MIME-Version: 1.0 X-Received: by 10.152.219.3 with SMTP id pk3mr4210191lac.114.1435371067925; Fri, 26 Jun 2015 19:11:07 -0700 (PDT) Received: by 10.25.198.70 with HTTP; Fri, 26 Jun 2015 19:11:07 -0700 (PDT) In-Reply-To: <558E0076.90201@gmail.com> References: <558E0076.90201@gmail.com> Date: Fri, 26 Jun 2015 19:11:07 -0700 Message-ID: From: John Strassner To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a113409d49feb790519765e06 Archived-At: Cc: Anima WG Subject: Re: [Anima] Central element [Questions on RFC7575] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 27 Jun 2015 02:11:12 -0000 --001a113409d49feb790519765e06 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Brian, thanks for the explanation. I do agree with you that hierarchy, or a set, or other types of relationships, are **just** relationships, and are only "special" in a particular context (if at all). That being said, I think you run the risk of confusing people by using "central", since that has some unfortunate non-autonomic connotations. Just my 2 cents. regards, John On Fri, Jun 26, 2015 at 6:46 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 24/06/2015 15:57, John Strassner wrote: > > ... > > What is a "central element"? Does this mean that the feedback loop > includes > > centralized management mechanisms, or that there is additional logic > > outside of just the nodes? > > > > > > > > MB: A central element is a controller for example. The point of the > section > > is: You could define an =E2=80=9Cautonomic network=E2=80=9D where every= node has exactly > > the same interfaces as today (primarily CLI, SNMP, NETCONF), and where = a > > controller is involved in all control loops. Our definition of > =E2=80=9Cautonomic=E2=80=9D > > is further down in the network, where nodes interact directly with node= s. > > Now we all understand this isn=E2=80=99t black and white, but the empha= sis of the > > work in the IETF should be node-to-node interactions. > > > > OK, got it. Just to ensure, is it fair to say that a "central > > element" is one in which non-autonomic functions are used that may affe= ct > > the behavior of autonomic nodes? > > > > MB2: This is correct but not complete. Because also a normal node has > > non-autonomic functions that may affect the behaviour of that node (or > > others). > > > > True, but I wouldn't think of a "normal node" as a "central > > element". So perhaps the language needs to be widened? > > At an earlier stage in the protocol draft, we had strong emphasis on > hierarchical structure, and discovering one's hierarchical superior. > We have gradually reduced that in the text to the observation that > in an AN, discovering your "superior" is no different than discovering > other peers; it's just a source of information or shared resource > like any other. I think the same logic will apply to "central" > elements. They are nodes that some human has chosen to put a label > on saying "central" and they happen to receive resources and Intent > and maybe other information from humans, for wider distribution. > But the network is a mesh, not a tree, and these nodes are just > arbitrary points in the mesh (or the cloud, if you prefer a modern > buzzword). > > Brian > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > --=20 regards, John --001a113409d49feb790519765e06 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Brian,

thanks for the exp= lanation.

I do agree with you that hierarchy, or a= set, or other types of
relationships, are **just** relationships= , and are only "special"
in a particular context (if at= all). That being said, I think you
run the risk of confusing peo= ple by using "central", since that
has some unfortunate= non-autonomic connotations.

Just my 2 cents.

regards,
John

On Fri, Jun 26, 2015 at 6:46 PM, Bri= an E Carpenter <brian.e.carpenter@gmail.com> wrote= :
On 24/06/2015 15:57, John Strassner wro= te:

...
> What is a "central element"? Does this mean that the feedbac= k loop includes
> centralized management mechanisms, or that there is additional logic > outside of just the nodes?
>
>
>
> MB: A central element is a controller for example. The point of the se= ction
> is: You could define an =E2=80=9Cautonomic network=E2=80=9D where ever= y node has exactly
> the same interfaces as today (primarily CLI, SNMP, NETCONF), and where= a
> controller is involved in all control loops. Our definition of =E2=80= =9Cautonomic=E2=80=9D
> is further down in the network, where nodes interact directly with nod= es.
> Now we all understand this isn=E2=80=99t black and white, but the emph= asis of the
> work in the IETF should be node-to-node interactions.
>
> <jcs> OK, got it. Just to ensure, is it fair to say that a "= ;central
> element" is one in which non-autonomic functions are used that ma= y affect
> the behavior of autonomic nodes? </jcs>
>
> MB2: This is correct but not complete. Because also a normal node has<= br> > non-autonomic functions that may affect the behaviour of that node (or=
> others).
>
> <jcs2> True, but I wouldn't think of a "normal node&quo= t; as a "central
> element". So perhaps the language needs to be widened? </jcs2&= gt;

At an earlier stage in the protocol draft, we had strong emphasis on
hierarchical structure, and discovering one's hierarchical superior. We have gradually reduced that in the text to the observation that
in an AN, discovering your "superior" is no different than discov= ering
other peers; it's just a source of information or shared resource
like any other. I think the same logic will apply to "central" elements. They are nodes that some human has chosen to put a label
on saying "central" and they happen to receive resources and Inte= nt
and maybe other information from humans, for wider distribution.
But the network is a mesh, not a tree, and these nodes are just
arbitrary points in the mesh (or the cloud, if you prefer a modern
buzzword).

=C2=A0 =C2=A0 Brian

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



--
regards,
John
--001a113409d49feb790519765e06-- From nobody Fri Jun 26 19:23:49 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6501B2C25 for ; Fri, 26 Jun 2015 19:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCowjQKA4h7l for ; Fri, 26 Jun 2015 19:23:46 -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 272AE1B2C23 for ; Fri, 26 Jun 2015 19:23:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUK85368; Sat, 27 Jun 2015 02:23:44 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 27 Jun 2015 03:23:43 +0100 Received: from NKGEML505-MBX.china.huawei.com ([169.254.1.218]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Sat, 27 Jun 2015 10:23:38 +0800 From: Duzongpeng To: Brian E Carpenter , "anima@ietf.org" Thread-Topic: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft-behringer-anima-autonomic-addressing-01.txt Thread-Index: AQHQrxkRDomOGjtUGEW0YQrF2SXEn5284BqA//+3fICAAVp9gIAAy7aAgADeP+A= Date: Sat, 27 Jun 2015 02:23:38 +0000 Message-ID: References: <558DB9ED.3040207@gmail.com> In-Reply-To: <558DB9ED.3040207@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.149.226] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft-behringer-anima-autonomic-addressing-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 27 Jun 2015 02:23:49 -0000 Hi Brian, In my understanding, although the ACP is designed as transparent as possibl= e, it does mean that the operator will never notice them in practice. Sometimes, the ACP needs to be able to connect to a NMS which may be an IPv= 4 one.=20 Sometimes, operators must be able to ensure the ACP is not misused, such as= in debugging. IMO, we can not assume that IPv6 would have replaced all the IPv4 when auto= nomic network becomes a common commercial feature. Even if it is only a requirement from a small part of operators who care mo= re about compatibility, it is worth considering. Best Regards Zongpeng Du -----Original Message----- From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E Carpenter Sent: Saturday, June 27, 2015 4:46 AM To: anima@ietf.org Subject: Re: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft-beh= ringer-anima-autonomic-addressing-01.txt On 26/06/2015 20:36, Jonathan Hansford wrote: > There are some systems outside the Internet that have no urgent need=20 > to move to IPv6 and developers would rather focus on more urgent=20 > needs. Autonomic networking could well be one of those more urgent=20 > needs. What is the harm if the AN products that they install happen to configure t= hemselves to use IPv6? Since any router that acts as an autonomic node will= be modern enough to support an IPv6 ACP with no manual intervention, why w= ould the operator even know or care? Brian > Jonathan >=20 > ----- Original Message ----- > From: "Michael Behringer (mbehring)"=20 > To:"Duzongpeng" , "Michael Richardson"=20 > Cc:"Anima WG"=20 > Sent:Thu, 25 Jun 2015 11:56:19 +0000 > Subject:Re: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: > draft-behringer-anima-autonomic-addressing-01.txt >=20 > For something new like AN, where the standardised specs will take at=20 > least a couple of years to appear in anyone's products, where we do=20 > NOT have backward compatibility issues, where we do not address end=20 > systems for some years to come, I personally think it is insane to=20 > even consider IPv4. >=20 > But I think we do have agreement that we start with IPv6 only, and=20 > just keep the door open, in case we need to support it. If the working=20 > group wants to do that, I'll change the text accordingly. Maybe a=20 > discussion for Prague? >=20 > Michael >=20 > > -----Original Message----- > > From: Duzongpeng [mailto:duzongpeng@huawei.com] > Sent: 25 June=20 > 2015 10:24 > To: Michael Behringer (mbehring); Michael Richardson >=20 > Cc: Anima WG > Subject: RE: [Anima] Whether IPv6 only for ACP? //RE:=20 > I-D Action: > draft- > > behringer-anima-autonomic-addressing-01.txt > > > > Hi, Michael Behringer > > > > I agree that the default setting of the ACP could be IPv6-based,=20 > which may > make the communication across autonomic domains easier to=20 > implement. > > > > What I suggested is that we first have an IPv6-based ACP ready, and=20 > define > an IPv4-based one as an alternative option. > > > > Best regards > > Zongpeng Du > > > > -----Original Message----- > > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael >=20 > Behringer (mbehring) > Sent: Thursday, June 25, 2015 3:31 PM > To:=20 > Duzongpeng; Michael Richardson > Cc: Anima WG > Subject: Re: [Anima]=20 > Whether IPv6 only for ACP? //RE: I-D Action: > draft- > > behringer-anima-autonomic-addressing-01.txt > > > > Re-reading my own message, one thing to add: Brian has already=20 > stated that > GDNP is protocol independent, and it should be. Of=20 > course we want to > develop everything IP version independent=20 > wherever possible. > > > > But there has to be some default autonomic addressing, routing, and=20 > for > THAT we want to look at IPv6 only at this point. > > > > Michael > > > > > -----Original Message----- > > > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael =20 > > > Behringer (mbehring) > > Sent: 25 June 2015 09:25 > > To:=20 > Duzongpeng; Michael Richardson > > Cc: Anima WG > > Subject: Re:=20 > [Anima] Whether IPv6 only for ACP? //RE: I-D Action: > > > draft- behringer-anima-autonomic-addressing-01.txt > > > > > > OK, I think there is some confusion around this topic. > > > > > > A network with autonomic functions (we all agree that a fully >=20 > > autonomic network is not our main target for now) can support on the =20 > > > *data plane* any protocol the operator wants to use, including=20 > IPv4, > > appletalk and IPv8 (when it comes). > > > > > > The statement is for the signalling, messaging and other=20 > protocols > > INSIDE the ACP, used by Autonomic Service Agents. > > > > > > Autonomic Service Agents will be exposed to a developer=20 > community, and > > the vendors implementing the ACP. There is=20 > absolutely no reason to > > standardise more than one protocol for=20 > this purpose. > > > > > > MichaelR is right: You don't need to actively deploy IPv6 to use=20 > the > > ACP. It just happens. With one caveat: If you connect an NMS=20 > system > > into the ACP for "virtual out of band" usage, then that=20 > system needs > > to support IPv6. But that is typically not a=20 > problem, in our experience. > > > > > > In other words: We're saying that *autonomic functions* (which=20 > the end > > user isn't exposed to at all) are exclusively IPv6, but=20 > the network > > can provide any service the operator wants.=20 > Specifically, an autonomic > > function (running on an IPv6 control=20 > plane) may well negotiate > > addressing for IPv4 services. > > > > > > Michael > > > > > > > -----Original Message----- > > > > From: Duzongpeng [mailto:duzongpeng@huawei.com] > > > Sent: 25=20 > June 2015 04:06 > > > To: Michael Richardson; Michael Behringer=20 > (mbehring) > > > Cc: Anima WG > > > Subject: Whether IPv6 only for=20 > ACP? //RE: [Anima] I-D Action: > draft- > > > > behringer-anima-autonomic-addressing-01.txt > > > > > > > > Hi, Michael Richardson: > > > > > > > > I agree with your option. Perhaps ACP is not needed to be IPv6=20 > only. > > > > > > > > Of course, an IPv6 only autonomic control plane is ok for all=20 > the > > > services in autonomic network, and the solution has the=20 > advantage of > > > simplicity as mentioned by Michael Behringer. > > > > > > > > However, the network operator may be more familiar with the > IPv4- > > > > base management. > > > > In the beginning of the ACP deployment, the network operator=20 > may > > not > > > be very confident about the decisions made by the=20 > autonomic network. > > > > Some kinds of monitoring jobs may be desired by the network=20 > operators. > > > > At this time, the operator may want to see some IPv4 addresses. > So, > > > > perhaps we need to provide IPv4-based ACP as an option for=20 > these > > > parts of operators. Otherwise, we can only answer them=20 > "sorry, we > > > only support > > > IPv6 here". > > > > > > > > As IPv4 has been widely deployed, perhaps an IPv4-based > >=20 > autonomic > > > network will be accepted by more network managers at=20 > the beginning. > > > > > > > > Indeed, at this time, an IPv4-based ACP is not as mature as the =20 > > > > IPv6 one. Thus, perhaps some work needs to be done at this > >=20 > > direction. For example, as you mentioned, how can we get an address =20 > > > > instead of the ULA in IPv6. > > > > > > > > Best regards > > > > Zongpeng Du > > > > > > > > -----Original Message----- > > > > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of=20 > Michael > > > Richardson > > > Sent: Thursday, June 25, 2015 1:12 AM =20 > > > > To: Michael Behringer (mbehring) > > > Cc: Anima WG > > >=20 > Subject: Re: [Anima] I-D Action: > draft-behringer-anima-autonomic- > > > > addressing-01.txt > > > > > > > > > > > > Michael Behringer (mbehring) wrote: > > > > >> > IPv6 only: Autonomic processes should use exclusively=20 > IPv6, for > > > >> > simplicity reasons. > > > > >> > > > > >> I agree with this as long as it's an RFC 2119 SHOULD, i.e. > > > > IPv4 could be used in > > > > >> extraordinary circumstances. The GDNP design is=20 > fundamentally > > > IP- version > > > >> independent. > > > > > > > > > Yes, as long as it's really "extraordinary" ;-) That 2119=20 > says > > > > "SHOULD" means like you need a really good reason to not=20 > do it. > > What > > > > > would such a good reason be? Just saying, in our=20 > implementation we > > > > often get the requirement "we want IPv4",=20 > and when you dig, > > > the reason > > > > is that they don't want=20 > to deploy IPv6, and that's the only > > > > reason. Slippery slope... > > >=20 >=20 >=20 > _______________________________________________ > 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 Fri Jun 26 19:31:21 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC391B2B42 for ; Fri, 26 Jun 2015 19:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOxsluQSeVtt for ; Fri, 26 Jun 2015 19:31:19 -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 85DFF1B2C6D for ; Fri, 26 Jun 2015 19:31:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYA88385; Sat, 27 Jun 2015 02:31:16 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 27 Jun 2015 03:31:15 +0100 Received: from NKGEML505-MBX.china.huawei.com ([169.254.1.218]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Sat, 27 Jun 2015 10:31:09 +0800 From: Duzongpeng To: Michael Richardson , Anima WG Thread-Topic: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft-behringer-anima-autonomic-addressing-01.txt Thread-Index: AQHQrxkRDomOGjtUGEW0YQrF2SXEn5284BqA//+3fICAAVp9gIAAqqcAgAEGqJA= Date: Sat, 27 Jun 2015 02:31:09 +0000 Message-ID: References: <32262.1435344434@sandelman.ca> In-Reply-To: <32262.1435344434@sandelman.ca> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.149.226] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft-behringer-anima-autonomic-addressing-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 27 Jun 2015 02:31:20 -0000 Hi Michael Richardson, Just ensure there is no misunderstanding here. IMO, the ACP is mostly softw= are based.=20 Of course, normally only new products can provide that feature. Best regards Zongpeng Du -----Original Message----- From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael Richardson Sent: Saturday, June 27, 2015 2:47 AM To: Anima WG Subject: Re: [Anima] Whether IPv6 only for ACP? //RE: I-D Action: draft-beh= ringer-anima-autonomic-addressing-01.txt Jonathan Hansford wrote: > There are some systems outside the Internet that have no urgent need > to move to IPv6 and developers would rather focus on more urgent > needs. Autonomic networking could well be one of those more urgent > needs. The Autonomic Control Plane is *not* IPv6. It just looks like IPv6. It's a new fangled protocol that has nothing to do with any of the deployed= production network. As such, it is *ENTIRELY* greenfield. It's all new code. It likely doesn't even get forwarded using whatever ASICs your hardware might have... If someone wants to do this with something that looks like IPv4, that's fin= e, but I want nobody complaining if we specify a mechanism (such as ULAs or= ND or SEND) that does never been defined in the thing that looks like IPv4= . -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- From nobody Sat Jun 27 17:18:12 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 434841B2EB0 for ; Sat, 27 Jun 2015 17:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhkklVLtQzvS for ; Sat, 27 Jun 2015 17:18:07 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::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 38E711B2B38 for ; Sat, 27 Jun 2015 17:18:07 -0700 (PDT) Received: by wicnd19 with SMTP id nd19so43952920wic.1 for ; Sat, 27 Jun 2015 17:18:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VPQQKCX5OWhDfYS4C4eUjb7eq0LvFIzSWyb+ls5Ewfc=; b=u3UHs1NDqz15octG0kZS86HPduphxp2RVig9krKkF49DcyewB0hYNvbespGEqFgsMb MYg6aCSbgzD5RS1pACgoW8fn6MK5dzVT9ymhUXcNkk/eDq4p4RLsrx7U/SZzUC2/GyOa rr9f9ET1wqOJDsYRYJvLiuXjp2CVkzB89bgOGIf44UcxKZGh/dyKyap36WXsPaqEI5Ow 7vYiprm2OtywPX+U74+b0U1CSFcsyRSKEuZnLJisTdh2FYDl4wAc+ZaUp89LQvP67Moj 4KBzQkUO4W+g9KXe3oW/YOpXRN8TASZ0pT3KtuJNKpu5YWU9zlGblXcnkCdjTEWZC89s QnBQ== MIME-Version: 1.0 X-Received: by 10.180.211.109 with SMTP id nb13mr9283201wic.8.1435450685937; Sat, 27 Jun 2015 17:18:05 -0700 (PDT) Received: by 10.27.39.5 with HTTP; Sat, 27 Jun 2015 17:18:05 -0700 (PDT) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45A6799F26@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F45A6799F26@nkgeml506-mbx.china.huawei.com> Date: Sat, 27 Jun 2015 17:18:05 -0700 Message-ID: From: John Strassner To: "Liubing (Leo)" Content-Type: multipart/alternative; boundary=001a11c3819e3a5cb6051988e862 Archived-At: Cc: Anima WG Subject: Re: [Anima] Naming discussion (Section 4.1 of the Reference-Model draft) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2015 00:18:11 -0000 --001a11c3819e3a5cb6051988e862 Content-Type: text/plain; charset=UTF-8 Dear Leo, please see inline, look for .. regards, John 4.1. Naming 4.1.1. Naming requirements o Representing each device Inside a domain, each autonomic device needs a domain specific identifier. [Open Questions] Are there devices that don't need names? Do ASAs need names? I think that each **entity** that can potentially interact with other entities MUST HAVE a name. I think of ASAs as managed entities, so yes, they do as well. o Uniqueness The names MUST NOT collide within one autonomic domain. It is acceptable that the names in different domains collide, since they could be distinguished by domains. I dislike name collisions, unless there is a good reason to have them (and please don't say "because it is easier" :-) ). That being said, I would expect them to be registered in the DNS. o Semantic Encoding It is RECOMMENDED that the names encode some semantics rather than meaningless strings. The semantics might be: + Location + Device type + Functional role + Ownership + etc. This is for ease of management consideration that network administrators could easily recognize the device directly through the names. I am a big fan of semantics. I actively work on ontologies, different types of logic, metadata-based systems, etc. However, I would NOT recommend this. First, I guarantee you that we will rathole on defining a canonical representation for generating strings. Second, if I was an ASA (I've been called worse :s), I wouldn't pay attention to the name of an object as much as I would its connections or its metadata. I would expect the metadata to be well structured, and not just consist of meaningless text. Hence, I would recommend (pun intended) that we instead concentrate on defining semantics of metadata o Consistency The devices' naming SHOULD follow the same pattern within a domain. s/domain/autonomic domain. You can't rename legacy systems. 4.1.2. Proposed Mechanisms o Structured Naming Pattern The whole name string could be divided into several fields, each of which representing a specific semantic as described above. For example: Location-DeviceType-FunctionalRole- DistinguisherNumber@NameofDomain. Why not use metadata to encode the semantics, and standardize the metadata object taxonomy instead? Also, if I look at the modern router or switch, the name is useless. What I see is a chassis containing a set of cards, where each card can play one or more roles. I would search on roles (which is, of course, a type of metadata). In this way, I get real information, not abbreviated strings concatenated together. The structure should be flexible that some fields are optional. When these optional fields are added, the name could still be recognized as the previous one. In above example, the "DistinguisherNumber" and "NameofDomain" are mandatory whereas others are optional. At initial stage, the devices might be only capable of self-generating the mandatory fields and the "DeviceType" because of the lack of knowledge. Later, they might have learned the "Location" and "FunctionalRole" and added the fields into current name. However, the other devices could still recognize it according to the same "DistinguisherNumber". Yikers! First, having a node that is changing its name is annoying. Of course, this is a good filter for robust coding :s. Second, an autonomic domain will add new data all the time (or else it's probably dead). How do we determine what data is "name-worthy"? o Advertised Common Fields Some fields in the structured name might be common among the domain (e.g. "Location" "NameofDomain"). Thus, these part of the names could be advertised through Intent Distribution (Section 4.5). I would hope that intent would be smarter and more abstract. If a field is common, then intent can be abstract and the translation to a common field is much easier. In other words, being common is not a good reason to be included in intent. o Self-generated Fields The mandatory fields SHOULD be self-generated so that one device could name itself sufficiently without any advertised knowledges. There should various methods for a device to extract/generate a proper word for each mandatory semantic fields (e.g. "DeviceType", "DistinguisherNum") from its self-knowledge. Detailed design of specific naming patterns and methods are out of scope of this document. On Fri, Jun 26, 2015 at 3:27 AM, Liubing (Leo) wrote: > Hi Dear all, > > I've generated some text regarding to the naming of autonomic network > devices. This is to fit the Section 4.1 in the Reference-Model draft. > Below is the content which includes some rough ideas. Please feel free to > comment. > > 4.1. Naming > > 4.1.1. Naming requirements > > o Representing each device > Inside a domain, each autonomic device needs a domain specific > identifier. > [Open Questions] Are there devices that don't need names? Do > ASAs need names? > > o Uniqueness > The names MUST NOT collide within one autonomic domain. > It is acceptable that the names in different domains collide, > since they could be distinguished by domains. > > o Semantic Encoding > It is RECOMMENDED that the names encode some semantics rather > than meaningless strings. The semantics might be: > + Location > + Device type > + Functional role > + Ownership > + etc. > This is for ease of management consideration that network > administrators could easily recognize the device directly > through the names. > > o Consistency > The devices' naming SHOULD follow the same pattern within a > domain. > > 4.1.2. Proposed Mechanisms > > o Structured Naming Pattern > The whole name string could be divided into several fields, > each of which representing a specific semantic as described > above. For example: Location-DeviceType-FunctionalRole- > DistinguisherNumber@NameofDomain. > > The structure should be flexible that some fields are optional. > When these optional fields are added, the name could still be > recognized as the previous one. In above example, the > "DistinguisherNumber" and "NameofDomain" are mandatory whereas > others are optional. At initial stage, the devices might be > only capable of self-generating the mandatory fields and the > "DeviceType" because of the lack of knowledge. Later, they > might have learned the "Location" and "FunctionalRole" and > added the fields into current name. However, the other devices > could still recognize it according to the same > "DistinguisherNumber". > > o Advertised Common Fields > Some fields in the structured name might be common among the > domain (e.g. "Location" "NameofDomain"). Thus, these part of > the names could be advertised through Intent > Distribution (Section 4.5). > > o Self-generated Fields > The mandatory fields SHOULD be self-generated so that one > device could name itself sufficiently without any advertised > knowledges. > There should various methods for a device to extract/generate a > proper word for each mandatory semantic fields (e.g. > "DeviceType", "DistinguisherNum") from its self-knowledge. > > Detailed design of specific naming patterns and methods are out of > scope of this document. > > > > Best regards, > Bing > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > -- regards, John --001a11c3819e3a5cb6051988e862 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Leo,

please see inline,= look for <jcs>..</jcs>

regards,
=
John


4.1.=C2=A0 Naming

= 4.1.1.=C2=A0 Naming requirements

=C2=A0 =C2=A0o=C2=A0 Representing= each device
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Inside a domain, each au= tonomic device needs a domain specific
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0identifier.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Open Questions] Are t= here devices that don't need names?=C2=A0 Do
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0ASAs need names?
<jcs>
I think that = each=C2=A0**entity** that can potentially interact with other entities
MUST HAVE a name. I think of ASAs as managed entities, so yes,
<= div>they do as well.
</jcs>

=C2=A0=C2=A0=C2=A0=C2=A0= o=C2=A0 Uniqueness
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The names MUST NOT= collide within one autonomic domain.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0It is acceptable that the names in different domains collide,
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0since they could be distinguished by domains.
<jcs>
I dislike name collisions, unless there is a= good reason to have them
(and please don't say=C2=A0"be= cause it is easier" :-) ). That being said, I
would expect t= hem to=C2=A0be registered in the DNS.
</jcs>

= =C2=A0=C2=A0=C2=A0=C2=A0o=C2=A0 Semantic Encoding
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0It is RECOMMENDED that the names encode some semantics rather<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0than meaningless strings.=C2=A0 The s= emantics might be:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 Location =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 Device type
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0+=C2=A0 Functional role
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0+=C2=A0 Ownership
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 etc.=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This is for ease of management consi= deration that network
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0administrators = could easily recognize the device directly
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0through the names.
<jcs>
I am a big fan of = semantics. I actively work on ontologies, different
types of logi= c, metadata-based systems, etc. However, I would NOT
recommend th= is. First,=C2=A0I guarantee you that we will rathole on defining
= a canonical representation for generating strings. Second, if I was=C2=A0an=
ASA (I've been called worse :s), I wouldn't pay attentio= n to the name
of an object as much as I would its connections or = its metadata. I
would expect the metadata to be well structured, = and=C2=A0not just consist
of meaningless text.=C2=A0Hence, I woul= d recommend=C2=A0(pun intended) that
we instead concentrate on de= fining=C2=A0semantics of metadata
</jcs>

=C2=A0=C2= =A0=C2=A0=C2=A0o=C2=A0 Consistency
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Th= e devices' naming SHOULD follow the same pattern within a
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0domain.
<jcs>
s/domain= /autonomic domain. You can't rename legacy systems.
</jcs&= gt;

=C2=A04.1.2.=C2=A0 Proposed Mechanisms

=C2=A0 =C2=A0 o= =C2=A0 Structured Naming Pattern
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The = whole name string could be divided into several fields,
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0each of which representing a specific semantic as descr= ibed
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0above.=C2=A0 For example: Locati= on-DeviceType-FunctionalRole-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Disting= uisherNumber@NameofDomain.
<jcs>
Why not use meta= data to encode the semantics, and=C2=A0standardize the
metadata o= bject taxonomy instead? Also, if I look at the modern
router or = switch,=C2=A0the name is useless. What I see is a chassis
contain= ing a set of cards, where each card can play one or more roles.
I= would=C2=A0search on roles (which is, of course, a type of metadata). In
this way, I get real information, not abbreviated strings=C2=A0con= catenated
together.
</jcs>

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0The structure should be flexib= le that some fields are optional.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Whe= n these optional fields are added, the name could still be
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0recognized as the previous one.=C2=A0 In above exam= ple, the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"DistinguisherNumber&qu= ot; and "NameofDomain" are mandatory whereas
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0others are optional.=C2=A0 At initial stage, the device= s might be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0only capable of self-gener= ating the mandatory fields and the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&q= uot;DeviceType" because of the lack of knowledge.=C2=A0 Later, they =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0might have learned the "Location&q= uot; and "FunctionalRole" and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0added the fields into current name.=C2=A0 However, the other devices
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0could still recognize it according to th= e same
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"DistinguisherNumber"= ;.
<jcs>
Yikers!
First, having a node t= hat is changing its name is annoying. Of course,
this is a good f= ilter for robust coding :s.
Second, an autonomic domain will add = new data all the=C2=A0time (or else
it's=C2=A0probably dead).= How do we determine what data is "name-worthy"?
</j= cs>

=C2=A0=C2=A0=C2=A0=C2=A0o=C2=A0 Advertised Common Fields
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Some fields in the structured name might = be common among the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0domain (e.g.=C2= =A0 "Location" "NameofDomain").=C2=A0 Thus, these part = of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the names could be advertised thro= ugh Intent
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Distribution (Section 4.5)= .
<jcs>
I would hope that intent would be smarter= and more abstract. If a field
is common, then intent can be abst= ract and the translation to a common
field is much easier.=C2=A0I= n other words, being common is not a good reason
to be included i= n intent.
</jcs>

=C2=A0=C2=A0=C2=A0=C2=A0o=C2=A0 Sel= f-generated Fields
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The mandatory fiel= ds SHOULD be self-generated so that one
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0device could name itself sufficiently without any advertised
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0knowledges.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0There should various methods for a device to extract/generate a
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0proper word for each mandatory semantic fiel= ds (e.g.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"DeviceType", &quo= t;DistinguisherNum") from its self-knowledge.

=C2=A0 =C2=A0Det= ailed design of specific naming patterns and methods are out of
=C2=A0 = =C2=A0scope of this document.

On Fri, Jun 26, 2015 at 3:27 AM, Liubing (Leo) <leo.liubing@huawei.com> wrote:
Hi Dear all,

I've generated some text regarding to the naming of autonomic network d= evices. This is to fit the Section 4.1 in the Reference-Model draft.
Below is the content which includes some rough ideas. Please feel free to c= omment.

4.1.=C2=A0 Naming

4.1.1.=C2=A0 Naming requirements

=C2=A0 =C2=A0o=C2=A0 Representing each device
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Inside a domain, each autonomic device ne= eds a domain specific
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0identifier.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Open Questions] Are there devices that d= on't need names?=C2=A0 Do
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ASAs need names?

=C2=A0 =C2=A0o=C2=A0 Uniqueness
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The names MUST NOT collide within one aut= onomic domain.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It is acceptable that the names in differ= ent domains collide,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0since they could be distinguished by doma= ins.

=C2=A0 =C2=A0o=C2=A0 Semantic Encoding
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It is RECOMMENDED that the names encode s= ome semantics rather
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0than meaningless strings.=C2=A0 The seman= tics might be:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 Location
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 Device type
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 Functional role
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 Ownership
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 etc.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This is for ease of management considerat= ion that network
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0administrators could easily recognize the= device directly
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0through the names.

=C2=A0 =C2=A0o=C2=A0 Consistency
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The devices' naming SHOULD follow the= same pattern within a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0domain.

4.1.2.=C2=A0 Proposed Mechanisms

=C2=A0 =C2=A0 o=C2=A0 Structured Naming Pattern
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The whole name string could be divided in= to several fields,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0each of which representing a specific sem= antic as described
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0above.=C2=A0 For example: Location-Device= Type-FunctionalRole-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DistinguisherNumber@NameofDomain.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The structure should be flexible that som= e fields are optional.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0When these optional fields are added, the= name could still be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0recognized as the previous one.=C2=A0 In = above example, the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"DistinguisherNumber" and "= ;NameofDomain" are mandatory whereas
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0others are optional.=C2=A0 At initial sta= ge, the devices might be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0only capable of self-generating the manda= tory fields and the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"DeviceType" because of the lac= k of knowledge.=C2=A0 Later, they
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0might have learned the "Location&quo= t; and "FunctionalRole" and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0added the fields into current name.=C2=A0= However, the other devices
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0could still recognize it according to the= same
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"DistinguisherNumber".

=C2=A0 =C2=A0o=C2=A0 Advertised Common Fields
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Some fields in the structured name might = be common among the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0domain (e.g.=C2=A0 "Location" &= quot;NameofDomain").=C2=A0 Thus, these part of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the names could be advertised through Int= ent
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Distribution (Section 4.5).

=C2=A0 =C2=A0o=C2=A0 Self-generated Fields
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The mandatory fields SHOULD be self-gener= ated so that one
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0device could name itself sufficiently wit= hout any advertised
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0knowledges.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0There should various methods for a device= to extract/generate a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0proper word for each mandatory semantic f= ields (e.g.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"DeviceType", "Distinguish= erNum") from its self-knowledge.

=C2=A0 =C2=A0Detailed design of specific naming patterns and methods are ou= t of
=C2=A0 =C2=A0scope of this document.



Best regards,
Bing

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



--
regards,
John
--001a11c3819e3a5cb6051988e862-- From nobody Mon Jun 29 00:13:37 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C65331A1BEF for ; Mon, 29 Jun 2015 00:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Ae_YCfzXtKJ for ; Mon, 29 Jun 2015 00:13:34 -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 51F121A1BEC for ; Mon, 29 Jun 2015 00:13:33 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYC38968; Mon, 29 Jun 2015 07:13:32 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 29 Jun 2015 08:13:31 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.135]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Mon, 29 Jun 2015 15:13:25 +0800 From: "Liubing (Leo)" To: Brian E Carpenter , "anima@ietf.org" Thread-Topic: [Anima] Naming discussion (Section 4.1 of the Reference-Model draft) Thread-Index: AdCv+rXE5dOVpQhdRKmevUBqnlbbhAAPARKAAIBwerA= Date: Mon, 29 Jun 2015 07:13:25 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C21D1AD8@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F45A6799F26@nkgeml506-mbx.china.huawei.com> <558DFE45.4050906@gmail.com> In-Reply-To: <558DFE45.4050906@gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] Naming discussion (Section 4.1 of the Reference-Model draft) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jun 2015 07:13:35 -0000 Hi Brian, Thanks for your comments, pls see inline. > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E > Carpenter > Sent: Saturday, June 27, 2015 9:37 AM > To: anima@ietf.org > Subject: Re: [Anima] Naming discussion (Section 4.1 of the Reference-Mode= l > draft) >=20 > On 26/06/2015 22:27, Liubing (Leo) wrote: > > Hi Dear all, > > > > I've generated some text regarding to the naming of autonomic network > devices. This is to fit the Section 4.1 in the Reference-Model draft. > > Below is the content which includes some rough ideas. Please feel free = to > comment. > > > > 4.1. Naming > > > > 4.1.1. Naming requirements > > > > o Representing each device > > Inside a domain, each autonomic device needs a domain > specific > > identifier. > > [Open Questions] Are there devices that don't need names? > Do > > ASAs need names? > > > > o Uniqueness > > The names MUST NOT collide within one autonomic domain. > > It is acceptable that the names in different domains collide, > > since they could be distinguished by domains. >=20 > Well, yes, we have a system for that, which is the DNS. Is there any reas= on > not to use DNS names? >=20 > > o Semantic Encoding > > It is RECOMMENDED that the names encode some semantics > rather > > than meaningless strings. The semantics might be: > > + Location > > + Device type > > + Functional role > > + Ownership > > + etc. > > This is for ease of management consideration that network > > administrators could easily recognize the device directly > > through the names. >=20 > I'm generally against making this a formal recommendation. I understand > very well that it may be a common operational practice already, but it's = quite > subject to human error [Bing] The described pattern isn't for manual configuration. I was imaginin= g the semantic fields could be generated by the autonomic devices themselve= s.=20 The name space of the semantics don't necessarily need to be standardized, = the vendors could set vocabulary by themselves. Since the goal is human-rea= dable, human could understand different vocabularies. > and in a truly autonomic network nobody should ever > see the names anyway.=20 [Bing] When we discussed AN management in the Reference Model draft with Mi= chael B. We all agreed that traditional management would co-exist with auto= nomic management. In this sense, do you think the naming is useful for the traditional manage= ment part? > Also, they would need to change autonomically > whenever the topology changes.=20 [Bing] Yes, this would probably happen. John also mentioned the naming chan= ge is "annoying" in the other thread.=20 So I was just thinking, maybe we could divide the name into two parts: one = part is the "basic-name" which should be permanent; the other part is "name= -tags" (e.g. Location, Functional Role, Ownership etc.) which are some info= that might be useful for administration but might probably changes.=20 Best regards, Bing > Brian >=20 > > o Consistency > > The devices' naming SHOULD follow the same pattern within a > > domain. > > > > 4.1.2. Proposed Mechanisms > > > > o Structured Naming Pattern > > The whole name string could be divided into several fields, > > each of which representing a specific semantic as described > > above. For example: Location-DeviceType-FunctionalRole- > > DistinguisherNumber@NameofDomain. > > > > The structure should be flexible that some fields are optional= . > > When these optional fields are added, the name could still be > > recognized as the previous one. In above example, the > > "DistinguisherNumber" and "NameofDomain" are mandatory > whereas > > others are optional. At initial stage, the devices might be > > only capable of self-generating the mandatory fields and the > > "DeviceType" because of the lack of knowledge. Later, they > > might have learned the "Location" and "FunctionalRole" and > > added the fields into current name. However, the other > devices > > could still recognize it according to the same > > "DistinguisherNumber". > > > > o Advertised Common Fields > > Some fields in the structured name might be common among > the > > domain (e.g. "Location" "NameofDomain"). Thus, these > part of > > the names could be advertised through Intent > > Distribution (Section 4.5). > > > > o Self-generated Fields > > The mandatory fields SHOULD be self-generated so that one > > device could name itself sufficiently without any advertised > > knowledges. > > There should various methods for a device to extract/generate > a > > proper word for each mandatory semantic fields (e.g. > > "DeviceType", "DistinguisherNum") from its self-knowledge. > > > > Detailed design of specific naming patterns and methods are out of > > scope of this document. > > > > > > > > Best regards, > > Bing > > > > _______________________________________________ > > 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 Jun 29 00:39:06 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA48A1A6FFC for ; Mon, 29 Jun 2015 00:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvX0DGdBzYos for ; Mon, 29 Jun 2015 00:39:03 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B65C91A6FF8 for ; Mon, 29 Jun 2015 00:39:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8050; q=dns/txt; s=iport; t=1435563540; x=1436773140; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=RVVr6lIBqGfwsOGVSvKkVtUPry42J6n/TDNAlsUZkhc=; b=I+2a8jWzzJwT4vAu1q9zUb+0zy2Ift04YSEBMCZvVrMHeUeLD00Y2p2f pqKX5ZguSLF6FwkFgMRSdNbi3J8mPLnEMyRNmFLqR8yedHdjNNMQr6fW/ gffyduETbOpk7hQV6YfzLY6pgnYaM5nGtjchrJ5sPw41Y5Nh5kFfJJpUn E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AUBQAs9ZBV/4YNJK1bgxFUXwa9JIFcCoV4AoErOhIBAQEBAQEBgQqEIgEBAQQBAQE3NAYRBAIBCBEEAQEBChQJBycLFAkIAQEEARIIiCcNxV4BAQEBAQEBAQEBAQEBAQEBAQEBAQETBItKhFU4BoMRgRQFjBKHcgGNDoQRjxODXSaCB4Fzb4FGgQIBAQE X-IronPort-AV: E=Sophos;i="5.13,697,1427760000"; d="scan'208";a="11095136" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-1.cisco.com with ESMTP; 29 Jun 2015 07:38:59 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t5T7cxTi027123 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Jun 2015 07:38:59 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.179]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Mon, 29 Jun 2015 02:38:59 -0500 From: "Michael Behringer (mbehring)" To: "Liubing (Leo)" , Brian E Carpenter , "anima@ietf.org" Thread-Topic: [Anima] Naming discussion (Section 4.1 of the Reference-Model draft) Thread-Index: AdCv+rXE5dOVpQhdRKmevUBqnlbbhAAqPtGAAHBTqoAACd7LoA== Date: Mon, 29 Jun 2015 07:38:58 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF7FCF@xmb-rcd-x14.cisco.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F45A6799F26@nkgeml506-mbx.china.huawei.com> <558DFE45.4050906@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C21D1AD8@nkgeml506-mbx.china.huawei.com> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45C21D1AD8@nkgeml506-mbx.china.huawei.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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] Naming discussion (Section 4.1 of the Reference-Model draft) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jun 2015 07:39:05 -0000 I guess we need to take a step back here. There is indeed a big question on= whether naming discussed in this framework is meant for "human" consumptio= n, or not.=20 In our pre-standard implementation we chose to pick names automatically, an= d they are at this point clearly NOT for human consumption. We just make su= re they're unique. The admin provides the domain name, which is the same fo= r all devices.=20 In a SOHO environment, I claim things should just happen automatically, and= the name really doesn't matter much to humans.=20 In an SP, we could either use the same model, or allow for operator input. = So an SP can provide a mapping between unique device identifier (UDI) and a= name that he'd like this device to have. This mapping can be provided in a= number of different forms, let's leave that for further considerations.=20 But I think, from the ANIMA point of view, we should say: During the enrolm= ent process the admin can provide a name for a device (and a domain name, b= tw). If a name is provided, it is used (in the certificate for example). If= not, a unique, autonomically created name is used. We need an algorithm th= at creates the autonomic name. (I tried to explain that in the addressing d= oc, but it was clearly not clear enough).=20 Personally, I think we shouldn't define how the name is constructed, if the= operator puts one in.=20 So, in summary:=20 - case 1: Admin provides UDI to name mapping, then that name is used. (we d= on't care what's inside the name) - case 2: name is created autonomically, using algorithm x=20 Thoughts?=20 Michael > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Liubing (Leo) > Sent: 29 June 2015 09:13 > To: Brian E Carpenter; anima@ietf.org > Subject: Re: [Anima] Naming discussion (Section 4.1 of the Reference- > Model draft) >=20 > Hi Brian, >=20 > Thanks for your comments, pls see inline. >=20 > > -----Original Message----- > > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E > > Carpenter > > Sent: Saturday, June 27, 2015 9:37 AM > > To: anima@ietf.org > > Subject: Re: [Anima] Naming discussion (Section 4.1 of the > > Reference-Model > > draft) > > > > On 26/06/2015 22:27, Liubing (Leo) wrote: > > > Hi Dear all, > > > > > > I've generated some text regarding to the naming of autonomic > > > network > > devices. This is to fit the Section 4.1 in the Reference-Model draft. > > > Below is the content which includes some rough ideas. Please feel > > > free to > > comment. > > > > > > 4.1. Naming > > > > > > 4.1.1. Naming requirements > > > > > > o Representing each device > > > Inside a domain, each autonomic device needs a domain > > specific > > > identifier. > > > [Open Questions] Are there devices that don't need names? > > Do > > > ASAs need names? > > > > > > o Uniqueness > > > The names MUST NOT collide within one autonomic domain. > > > It is acceptable that the names in different domains collide= , > > > since they could be distinguished by domains. > > > > Well, yes, we have a system for that, which is the DNS. Is there any > > reason not to use DNS names? > > > > > o Semantic Encoding > > > It is RECOMMENDED that the names encode some semantics > > rather > > > than meaningless strings. The semantics might be: > > > + Location > > > + Device type > > > + Functional role > > > + Ownership > > > + etc. > > > This is for ease of management consideration that network > > > administrators could easily recognize the device directly > > > through the names. > > > > I'm generally against making this a formal recommendation. I > > understand very well that it may be a common operational practice > > already, but it's quite subject to human error > [Bing] The described pattern isn't for manual configuration. I was imagin= ing > the semantic fields could be generated by the autonomic devices > themselves. > The name space of the semantics don't necessarily need to be standardized= , > the vendors could set vocabulary by themselves. Since the goal is human- > readable, human could understand different vocabularies. >=20 > > and in a truly autonomic network nobody should ever see the names > > anyway. > [Bing] When we discussed AN management in the Reference Model draft > with Michael B. We all agreed that traditional management would co-exist > with autonomic management. > In this sense, do you think the naming is useful for the traditional > management part? >=20 > > Also, they would need to change autonomically whenever the topology > > changes. > [Bing] Yes, this would probably happen. John also mentioned the naming > change is "annoying" in the other thread. > So I was just thinking, maybe we could divide the name into two parts: on= e > part is the "basic-name" which should be permanent; the other part is > "name-tags" (e.g. Location, Functional Role, Ownership etc.) which are > some info that might be useful for administration but might probably > changes. >=20 > Best regards, > Bing >=20 > > Brian > > > > > o Consistency > > > The devices' naming SHOULD follow the same pattern within a > > > domain. > > > > > > 4.1.2. Proposed Mechanisms > > > > > > o Structured Naming Pattern > > > The whole name string could be divided into several fields, > > > each of which representing a specific semantic as described > > > above. For example: Location-DeviceType-FunctionalRole- > > > DistinguisherNumber@NameofDomain. > > > > > > The structure should be flexible that some fields are option= al. > > > When these optional fields are added, the name could still b= e > > > recognized as the previous one. In above example, the > > > "DistinguisherNumber" and "NameofDomain" are mandatory > > whereas > > > others are optional. At initial stage, the devices might be > > > only capable of self-generating the mandatory fields and the > > > "DeviceType" because of the lack of knowledge. Later, they > > > might have learned the "Location" and "FunctionalRole" and > > > added the fields into current name. However, the other > > devices > > > could still recognize it according to the same > > > "DistinguisherNumber". > > > > > > o Advertised Common Fields > > > Some fields in the structured name might be common among > > the > > > domain (e.g. "Location" "NameofDomain"). Thus, these > > part of > > > the names could be advertised through Intent > > > Distribution (Section 4.5). > > > > > > o Self-generated Fields > > > The mandatory fields SHOULD be self-generated so that one > > > device could name itself sufficiently without any advertised > > > knowledges. > > > There should various methods for a device to > > > extract/generate > > a > > > proper word for each mandatory semantic fields (e.g. > > > "DeviceType", "DistinguisherNum") from its self-knowledge. > > > > > > Detailed design of specific naming patterns and methods are out of > > > scope of this document. > > > > > > > > > > > > Best regards, > > > Bing > > > > > > _______________________________________________ > > > 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 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Mon Jun 29 01:31:14 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A52E1A882B for ; Mon, 29 Jun 2015 01:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CS13YfwTvvRx for ; Mon, 29 Jun 2015 01:31:10 -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 2EBB81A882C for ; Mon, 29 Jun 2015 01:31:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUM42743; Mon, 29 Jun 2015 08:31:08 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 29 Jun 2015 09:31:08 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.135]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Mon, 29 Jun 2015 16:31:04 +0800 From: "Liubing (Leo)" To: "Michael Behringer (mbehring)" , Brian E Carpenter , "anima@ietf.org" Thread-Topic: [Anima] Naming discussion (Section 4.1 of the Reference-Model draft) Thread-Index: AdCv+rXE5dOVpQhdRKmevUBqnlbbhAAPARKAAIBwerD//4Y9AP//b7qg Date: Mon, 29 Jun 2015 08:31:04 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C21D4B31@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F45A6799F26@nkgeml506-mbx.china.huawei.com> <558DFE45.4050906@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C21D1AD8@nkgeml506-mbx.china.huawei.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF7FCF@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF7FCF@xmb-rcd-x14.cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] Naming discussion (Section 4.1 of the Reference-Model draft) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jun 2015 08:31:13 -0000 Hi Michael and all, Regarding to "human", I think there are two aspects: 1. Human get involved in generating names. I guess it's what you meant by "= human consumption". 2. The names are generated by the devices automatically and also human read= able. So that it might be easier for the administrators, e.g. when they're = analyzing/debugging a network issue. For no.1, I also agree human should not participate in the name generation = procedure (except the special cases you discussed below). For no.2, of course it needs a more complex algorithm/molding than only ens= uring the uniqueness. My proposed text was trying to discuss the possibilit= y a bit in this direction.=20 But from the AN management requirement perspective, do you think no.2 make = sense? Best regards, Bing > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael > Behringer (mbehring) > Sent: Monday, June 29, 2015 3:39 PM > To: Liubing (Leo); Brian E Carpenter; anima@ietf.org > Subject: Re: [Anima] Naming discussion (Section 4.1 of the Reference-Mode= l > draft) >=20 > I guess we need to take a step back here. There is indeed a big question = on > whether naming discussed in this framework is meant for "human" > consumption, or not. >=20 > In our pre-standard implementation we chose to pick names automatically, > and they are at this point clearly NOT for human consumption. We just mak= e > sure they're unique. The admin provides the domain name, which is the sam= e > for all devices. >=20 > In a SOHO environment, I claim things should just happen automatically, a= nd > the name really doesn't matter much to humans. >=20 > In an SP, we could either use the same model, or allow for operator input= . So > an SP can provide a mapping between unique device identifier (UDI) and a > name that he'd like this device to have. This mapping can be provided in = a > number of different forms, let's leave that for further considerations. >=20 > But I think, from the ANIMA point of view, we should say: During the > enrolment process the admin can provide a name for a device (and a domain > name, btw). If a name is provided, it is used (in the certificate for exa= mple). > If not, a unique, autonomically created name is used. We need an algorith= m > that creates the autonomic name. (I tried to explain that in the addressi= ng > doc, but it was clearly not clear enough). >=20 > Personally, I think we shouldn't define how the name is constructed, if t= he > operator puts one in. >=20 > So, in summary: > - case 1: Admin provides UDI to name mapping, then that name is used. (we > don't care what's inside the name) > - case 2: name is created autonomically, using algorithm x >=20 > Thoughts? > Michael >=20 >=20 >=20 > > -----Original Message----- > > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Liubing (Leo) > > Sent: 29 June 2015 09:13 > > To: Brian E Carpenter; anima@ietf.org > > Subject: Re: [Anima] Naming discussion (Section 4.1 of the Reference- > > Model draft) > > > > Hi Brian, > > > > Thanks for your comments, pls see inline. > > > > > -----Original Message----- > > > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E > > > Carpenter > > > Sent: Saturday, June 27, 2015 9:37 AM > > > To: anima@ietf.org > > > Subject: Re: [Anima] Naming discussion (Section 4.1 of the > > > Reference-Model > > > draft) > > > > > > On 26/06/2015 22:27, Liubing (Leo) wrote: > > > > Hi Dear all, > > > > > > > > I've generated some text regarding to the naming of autonomic > > > > network > > > devices. This is to fit the Section 4.1 in the Reference-Model draft. > > > > Below is the content which includes some rough ideas. Please feel > > > > free to > > > comment. > > > > > > > > 4.1. Naming > > > > > > > > 4.1.1. Naming requirements > > > > > > > > o Representing each device > > > > Inside a domain, each autonomic device needs a domain > > > specific > > > > identifier. > > > > [Open Questions] Are there devices that don't need names? > > > Do > > > > ASAs need names? > > > > > > > > o Uniqueness > > > > The names MUST NOT collide within one autonomic > domain. > > > > It is acceptable that the names in different domains colli= de, > > > > since they could be distinguished by domains. > > > > > > Well, yes, we have a system for that, which is the DNS. Is there any > > > reason not to use DNS names? > > > > > > > o Semantic Encoding > > > > It is RECOMMENDED that the names encode some > semantics > > > rather > > > > than meaningless strings. The semantics might be: > > > > + Location > > > > + Device type > > > > + Functional role > > > > + Ownership > > > > + etc. > > > > This is for ease of management consideration that network > > > > administrators could easily recognize the device directly > > > > through the names. > > > > > > I'm generally against making this a formal recommendation. I > > > understand very well that it may be a common operational practice > > > already, but it's quite subject to human error > > [Bing] The described pattern isn't for manual configuration. I was > > imagining the semantic fields could be generated by the autonomic > > devices themselves. > > The name space of the semantics don't necessarily need to be > > standardized, the vendors could set vocabulary by themselves. Since > > the goal is human- readable, human could understand different > vocabularies. > > > > > and in a truly autonomic network nobody should ever see the names > > > anyway. > > [Bing] When we discussed AN management in the Reference Model draft > > with Michael B. We all agreed that traditional management would > > co-exist with autonomic management. > > In this sense, do you think the naming is useful for the traditional > > management part? > > > > > Also, they would need to change autonomically whenever the topology > > > changes. > > [Bing] Yes, this would probably happen. John also mentioned the naming > > change is "annoying" in the other thread. > > So I was just thinking, maybe we could divide the name into two parts: > > one part is the "basic-name" which should be permanent; the other part > > is "name-tags" (e.g. Location, Functional Role, Ownership etc.) which > > are some info that might be useful for administration but might > > probably changes. > > > > Best regards, > > Bing > > > > > Brian > > > > > > > o Consistency > > > > The devices' naming SHOULD follow the same pattern > within a > > > > domain. > > > > > > > > 4.1.2. Proposed Mechanisms > > > > > > > > o Structured Naming Pattern > > > > The whole name string could be divided into several fields= , > > > > each of which representing a specific semantic as describe= d > > > > above. For example: > Location-DeviceType-FunctionalRole- > > > > DistinguisherNumber@NameofDomain. > > > > > > > > The structure should be flexible that some fields are > optional. > > > > When these optional fields are added, the name could still > be > > > > recognized as the previous one. In above example, the > > > > "DistinguisherNumber" and "NameofDomain" are > mandatory > > > whereas > > > > others are optional. At initial stage, the devices might = be > > > > only capable of self-generating the mandatory fields and > the > > > > "DeviceType" because of the lack of knowledge. Later, > they > > > > might have learned the "Location" and "FunctionalRole" > and > > > > added the fields into current name. However, the other > > > devices > > > > could still recognize it according to the same > > > > "DistinguisherNumber". > > > > > > > > o Advertised Common Fields > > > > Some fields in the structured name might be common > among > > > the > > > > domain (e.g. "Location" "NameofDomain"). Thus, these > > > part of > > > > the names could be advertised through Intent > > > > Distribution (Section 4.5). > > > > > > > > o Self-generated Fields > > > > The mandatory fields SHOULD be self-generated so that > one > > > > device could name itself sufficiently without any advertis= ed > > > > knowledges. > > > > There should various methods for a device to > > > > extract/generate > > > a > > > > proper word for each mandatory semantic fields (e.g. > > > > "DeviceType", "DistinguisherNum") from its self-knowledge. > > > > > > > > Detailed design of specific naming patterns and methods are out = of > > > > scope of this document. > > > > > > > > > > > > > > > > Best regards, > > > > Bing > > > > > > > > _______________________________________________ > > > > 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 > > > > _______________________________________________ > > 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 Jun 29 01:49:06 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B039F1A1C04 for ; Mon, 29 Jun 2015 01:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2K3OpJwFXQOp for ; Mon, 29 Jun 2015 01:49:03 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D80F91A040B for ; Mon, 29 Jun 2015 01:49:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2457; q=dns/txt; s=iport; t=1435567742; x=1436777342; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=5GJ31uQuflhHcY/QkArUpeLoDDBuCkgWPWRaUc3mKGM=; b=B+uDzHf8Bfa/1/EWkFnUUNmkH5YAC8JVPWG90BmbwtaNria8ruZHN59G E1n2p3D5mxBIagpRKO/H8SnNuiAyOjZHpYy9L55y6FckwKUiiUr3VVQWm 2fEGWioAaWl7pDfZsJmazMfb6PMFxA52gAoZbmDQkansUNs3APUeEme6P A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AQBQAHBpFV/5RdJa1bgxGBMwa9IYdeAoEsOhIBAQEBAQEBgQqEIgEBAQQ6SwQCAQgRBAEBCxQJBzIUCQgBAQQBEgiIJ8V+AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tKhFU4BoMRgRQFjBKHcgGkDyaCB4Fzb4FGgQIBAQE X-IronPort-AV: E=Sophos;i="5.13,698,1427760000"; d="scan'208";a="163685280" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-7.cisco.com with ESMTP; 29 Jun 2015 08:49:02 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t5T8n1pL014424 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Jun 2015 08:49:01 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.179]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Mon, 29 Jun 2015 03:49:01 -0500 From: "Michael Behringer (mbehring)" To: "Liubing (Leo)" , Brian E Carpenter , "anima@ietf.org" Thread-Topic: [Anima] Naming discussion (Section 4.1 of the Reference-Model draft) Thread-Index: AdCv+rXE5dOVpQhdRKmevUBqnlbbhAAqPtGAAHBTqoAACd7LoP//xrsAgABRv8A= Date: Mon, 29 Jun 2015 08:49:01 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF818A@xmb-rcd-x14.cisco.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F45A6799F26@nkgeml506-mbx.china.huawei.com> <558DFE45.4050906@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C21D1AD8@nkgeml506-mbx.china.huawei.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF7FCF@xmb-rcd-x14.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C21D4B31@nkgeml506-mbx.china.huawei.com> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45C21D4B31@nkgeml506-mbx.china.huawei.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Naming discussion (Section 4.1 of the Reference-Model draft) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jun 2015 08:49:04 -0000 > -----Original Message----- > From: Liubing (Leo) [mailto:leo.liubing@huawei.com] > Sent: 29 June 2015 10:31 > To: Michael Behringer (mbehring); Brian E Carpenter; anima@ietf.org > Subject: RE: [Anima] Naming discussion (Section 4.1 of the Reference-Mode= l > draft) >=20 > Hi Michael and all, >=20 > Regarding to "human", I think there are two aspects: > 1. Human get involved in generating names. I guess it's what you meant by > "human consumption". > 2. The names are generated by the devices automatically and also human > readable. So that it might be easier for the administrators, e.g. when th= ey're > analyzing/debugging a network issue. >=20 > For no.1, I also agree human should not participate in the name generatio= n > procedure (except the special cases you discussed below). > For no.2, of course it needs a more complex algorithm/molding than only > ensuring the uniqueness. My proposed text was trying to discuss the > possibility a bit in this direction. > But from the AN management requirement perspective, do you think no.2 > make sense? >=20 > Best regards, > Bing Bing,=20 Let me be more verbose in my proposal:=20 - case 1: Admin provides UDI to name mapping, then that name is used.=20 (we don't care what's inside the name) I suggest that in this case we treat the name as opaque, i.e., ANIMA=20 doesn't care how it's made.=20 I think case 1 is relatively easy to agree on. Right? - case 2: name is created autonomically, using algorithm x Here, I suggest that we don't even try to do something "intelligent".=20 Reasoning: What can we figure out automatically, really? Well, device type,= vendor can be derived from some h/w information. What else?=20 topology - NOT! (not one that's useful to an admin). Frankly I think it is = impossible to come up with an automated naming scheme that is 1) completely= automatic and 2) admins will be happy with. Let's not even try ;-)=20 BTW, I suggest we put UDI info into a field of the certificate, so that it'= s available when needed, but not onto the name. So in the cert, you do find= info on, e.g., device type if needed.=20 BTW, I think I never mentioned this explicitly, but I think the "autonomic = name" we're talking about here should NOT be the hostname of the device. Ag= ain, this is to keep traditionally maintained config and autonomic informat= ion as clearly separated as possible. Michael From nobody Mon Jun 29 02:01:29 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF18B1A21A3 for ; Mon, 29 Jun 2015 02:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGRvMjGP3NEo for ; Mon, 29 Jun 2015 02:01:25 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D11971A8733 for ; Mon, 29 Jun 2015 02:01:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=331; q=dns/txt; s=iport; t=1435568484; x=1436778084; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=di2Ot8NPh2rjLNE8ePbwBS69WJ9qfIR1lOzF+KrNGWs=; b=de6lzSDenhGutHcTNGnbt30ulaIodGgLq0hTIhyWE975RrIb7uR4DoF7 DiZloPaHxntvJnODfdfwpaUZeBhkdAK2zi7vPCWuyA8OMEivkdbrQoZyp Ldug0bxbd/XvNOMOMsFHG8AjcHCyFygNN5e27y4ClEtU/tHALJ1L6yqLW U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CxAwC4CJFV/4gNJK1bgxGBOb0YCYdeAoEtOBQBAQEBAQEBgQqEJAEEOlEBKhRCJgEEG4gnoCGlZQEBAQEGAQEBAQEdi0qEVYNPgRQFlAQBjQ6EEZJwJoN6gjWBAgEBAQ X-IronPort-AV: E=Sophos;i="5.13,698,1427760000"; d="scan'208";a="5468076" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-8.cisco.com with ESMTP; 29 Jun 2015 09:01:24 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t5T91ORc031109 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 29 Jun 2015 09:01:24 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.179]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Mon, 29 Jun 2015 04:01:24 -0500 From: "Michael Behringer (mbehring)" To: "anima@ietf.org" Thread-Topic: New version of reference model: Posting tomorrow Thread-Index: AdCySipog4oxfFzmS6SSLZTJlZf0zg== Date: Mon, 29 Jun 2015 09:01:23 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF81D6@xmb-rcd-x14.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Anima] New version of reference model: Posting tomorrow X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jun 2015 09:01:27 -0000 Just a note: I'm planning to post the next version of the reference model b= y tomorrow.=20 Not everybody provided their section yet, if you still would like to, pleas= e do so today :-)=20 Needless to say, this is just another working version, and the sections do = not necessarily document consensus yet.=20 Michael From nobody Mon Jun 29 02:39:22 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 295251A88DB for ; Mon, 29 Jun 2015 02:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.529 X-Spam-Level: X-Spam-Status: No, score=-13.529 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98EtZRlChv4B for ; Mon, 29 Jun 2015 02:39:19 -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 C8AD31A890B for ; Mon, 29 Jun 2015 02:39:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24118; q=dns/txt; s=iport; t=1435570758; x=1436780358; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2EJ26AaVx6pTMGo6WpPAj3z1pJutmKa0XIzIVdq3/b4=; b=bdKU3ceMHqrG3OowIGJSGxHtHOC80ttESILEWTiBo9JBku7A9EhTRIVM b86P4sgM3eOGg78vdm9er9vjqHM7Y+h5YI3JbuZExVSMEUeCN7QS4Anu4 TkWt7Z0oqJbMHMqzyUA4KlgMFpcCXQ4obbBxJy0ps2zwTOC/rqNKyPoGH 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CjBQAMEZFV/4QNJK1bgkVMVF8GvG4qCYFmhXgCHIETOBQBAQEBAQEBgQqEIgEBAQQjCkELDgICAQgRBAEBCx0DAgICGRcUCQgBAQQBDQUIDIgbDa96lgcBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBItGhCMQAgEfBREXBAYBgmgvgRQFlAQBhFiINoQRgw2HX4Qng10RFYN6b4EDBzyBAgEBAQ X-IronPort-AV: E=Sophos;i="5.13,698,1427760000"; d="scan'208,217";a="163675448" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP; 29 Jun 2015 09:39:17 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t5T9dHnk005146 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Jun 2015 09:39:17 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.179]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Mon, 29 Jun 2015 04:39:17 -0500 From: "Michael Behringer (mbehring)" To: Laurent Ciavaglia , Anima WG Thread-Topic: Reference doc on github Thread-Index: AdCo+dAvfC4NDb/zTJOIdvnhU/aAQgBsMD2AAekoXPA= Date: Mon, 29 Jun 2015 09:39:16 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF828B@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FEE3B8@xmb-rcd-x14.cisco.com> <5583F8D3.6070208@alcatel-lucent.com> In-Reply-To: <5583F8D3.6070208@alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.34] Content-Type: multipart/alternative; boundary="_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FF828Bxmbrcdx14ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "draft-behringer-anima-reference-model@tools.ietf.org" Subject: Re: [Anima] Reference doc on github X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jun 2015 09:39:21 -0000 --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FF828Bxmbrcdx14ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTGF1cmVudCwNClJlZ2FyZGluZyBzZWN0aW9uIDg6IEFncmVlLCBubyBjaGFuZ2VzIG5lZWRl ZCBmb3Igbm93LCBidXQgZmVlZGJhY2sgZnJvbSB0aGUgY29tbXVuaXR5Lg0KUmVnYXJkaW5nIHNl Y3Rpb24gOTogSSByZS1yZWFkIGJvdGgsIHRoaXMgc2VjdGlvbiBhbmQgc2VjdGlvbiAzLjIuIG9m IFJGQzc1NzUuIE15IHBlcnNvbmFsIG9waW5pb24gaXMgdGhhdCB0aGlzIHNlY3Rpb24gaXMgbm90 IG5lZWRlZCBpbiB0aGUgcmVmZXJlbmNlIGRvY3VtZW50LCBhbmQgSSBzdWdnZXN0IHRoZXJlZm9y ZSB0byBkcm9wIGl0Lg0KTGV04oCZcyBrZWVwIHRoZSBkb2N1bWVudCBhcyBjb25jaXNlIGFzIHBv c3NpYmxlLg0KTWljaGFlbA0KRnJvbTogTGF1cmVudCBDaWF2YWdsaWEgW21haWx0bzpMYXVyZW50 LkNpYXZhZ2xpYUBhbGNhdGVsLWx1Y2VudC5jb21dDQpTZW50OiAxOSBKdW5lIDIwMTUgMTM6MTEN ClRvOiBNaWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpOyBBbmltYSBXRw0KQ2M6IGRyYWZ0LWJl aHJpbmdlci1hbmltYS1yZWZlcmVuY2UtbW9kZWxAdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBSZWZlcmVuY2UgZG9jIG9uIGdpdGh1Yg0KDQpEZWFyIE1pY2hhZWwsIGFsbCwNCg0KU2VjdGlv biA4IGlzIG5ldywgc28gSSBkb24ndCB0aGluayBpdCBuZWVkcyBhbiB1cGF0ZSBmb3IgLTAzLCBi dXQgSSB3b3VsZCBiZSBoYXBweSB0byBtYWtlIGNoYW5nZXMgYmFzZWQgb24gZmVlZGJhY2svY29t bWVudHMuDQoNCkZvciBTZWN0aW9uIDk6IElzIHRoZSBjdXJyZW50IHRleHQgcmVmZXJyaW5nIHRv IFJGQzc1NzUsIFNlY3Rpb24gMy4yLiBDb2V4aXN0ZW5jZSB3aXRoIFRyYWRpdGlvbmFsIE1hbmFn ZW1lbnQ/DQpJZiB5ZXMsIHRoZW4gSSB3b3VsZCBzdWdnZXN0IHJlbmFtaW5nIFNlY3Rpb24gOSB0 byByZWZsZWN0IHRoZSBhY3R1YWwgY29udGVudCB3aGljaCBmb2N1c2VzIG9uICJtYW5hZ2VtZW50 IG9yIG9wZXJhdGlvbiBtb2RlIiBwcmlvcml0aXphdGlvbi4NCklmIGFncmVlZC9jb3JyZWN0LCBJ IGNhbiB1cGRhdGUgdGhlIHRleHQgZm9yIFNlY3Rpb24gOSBieSBuZXh0IFdlZG5lc2RheS4NCg0K VGhvdWdoLCB0aGUgdG9waWMgb2YgImh5YnJpZCIgb3BlcmF0aW9ucyAoYXV0b25vbWljIGFuZCBu b24tYXV0b25vbWljKSBpcyBzdGlsbCByZWxldmFudCwgYnV0IHNsaWdodGx5IGRpZmZlcmVudCBm cm9tIHByaW9yaXRpemF0aW9uLiBTb21lIG9uZ29pbmcgZGlzY3Vzc2lvbnMgb24gdGhlIEFOSU1B IG1haWxpbmcgbGlzdCBvbiBkb21haW4sIGludGVudCwgYW5kIGNvbnN0cmFpbmVkIG5vZGVzIHBh cnRpY2lwYXRlIGluIHRoaXMgdG9waWMuDQpBIHRleHQgb24gdGhpcyBpbiAtMDMgaXMgdG9vIGFt Yml0aW91cywgYnV0IHdlIGNhbiB0cmlnZ2VyIGEgZGlzY3Vzc2lvbiB0aHJlYWQgdG8gY2FwdHVy ZSB0aGUgb3BlcmF0aW5nIHByaW5jaXBsZXMgQU5JTUEgYWltcyBhdCBjb25jZXJuaW5nIHRoaXMg aHlicmlkIG1vZGUgb2Ygb3BlcmF0aW9uIChpLmUuIGhvdyBBRnMgYW5kIG5vbi1BRnMgY28tb3Bl cmF0ZSwgYXJlIG1hbmFnZWQvZ292ZXJuZWQgYnkgSW50ZW50L290aGVyIG1lYW5zLCByb2xlIG9m ICJoZWxwaW5nIiBub2Rlcy9mdW5jdGlvbnMvZ2F0ZXdheXMuLi4pDQoNCkJlc3QgcmVnYXJkcywg TGF1cmVudC4NCg0KT24gMTcvMDYvMjAxNSAxNDo0MSwgTWljaGFlbCBCZWhyaW5nZXIgKG1iZWhy aW5nKSB3cm90ZToNCg0KSSBoYXZlIG5vdyBhbHNvIGNyZWF0ZWQgYSByZXBvc2l0b3J5IGluIGdp dGh1YjogaHR0cHM6Ly9naXRodWIuY29tL21iZWhyaW5nL0FOSU1BLVJlZmVyZW5jZS1Nb2RlbA0K DQoNCg0KSSBzdWdnZXN0ZWQgaW5pdGlhbCBjb250cmlidXRpb25zLCBhcyBwZXIgYmVsb3cgbGlz dCAob3BlbiB0byBtb3JlIHN1Z2dlc3Rpb25zIDstKQ0KDQoNCg0KLSBNaWNoYWVsIFJpY2hhcmRz b246IHNlY3Rpb24gMy4zIChjb25zdHJhaW5lZCBub2RlcykNCg0KLSBMaXViaW5nOiA0LjEgYW5k IDQuMiAoTmFtaW5nLCBhZGRyZXNzaW5nKQ0KDQotIEJyaWFuIENhcnBlbnRlcjogNC40IChzaWdu YWxpbmcpLiBDb3VsZCB5b3UgYWxzbyBjb3ZlciA0LjUgKGludGVudCBkaXN0cmlidXRpb24pIGFu ZCA0LjMgKGRpc2NvdmVyeSk/IC0gdmVyeSByZWxhdGVkISENCg0KLSBKYXNvbiBDb2xlbWFuOiBT ZWN0aW9uIDUuMSwgNS4yLCA1LjQsIDUuNSAoUEtJLCBjZXJ0LCBzdWIgYW5kIGNyb3NzLWRvbWFp bikNCg0KLSBKZWZlcnNvbiBOb2JyZTogNy4xLCA3LjIsIDcuMyAoTWFuYWdlbWVudCwgaW50ZW50 LCBhZ2dyZWdhdGVkIHJlcG9ydGluZykNCg0KLSBKb2huIFN0cmFzc25lcjogNy40LCA3LjUsIDcu NiAoZmVlZGJhY2sgbG9vcHMsIEFQSVMgYW5kIG1vZGVscy4pDQoNCi0gTGF1cmVudCBDaWF2YWds aWE6IFNlY3Rpb25zIDggYW5kIDkgKGRvIHRoZXkgbmVlZCBhbiB1cGRhdGU/KQ0KDQotIFRvZXJs ZXNzIGFuZCBJIHdpbGwgc2hhcmUgdGhlIHJlbWFpbmluZyBzZWN0aW9ucyBmb3Igbm93Lg0KDQoN Cg0KQ2FuIHRoZSB2b2x1bnRlZXJzIHBsZWFzZSBsZXQgbWUga25vdyBieSB3aGVuIHRoZXkgY2Fu IGNvbnRyaWJ1dGUgdGhlaXIgdGV4dD8gIEVpdGhlciBpbiBnaXRodWIgKGxldCBtZSBrbm93IHlv dXIgSUQgaWYgeW91IHdhbnQgdG8gY29udHJpYnV0ZSB0aGVyZSkNCg0KDQoNCkdpdGh1YiBpcyBu b3QgbWFuZGF0b3J5IC0gSWYgeW91IHdhbnQgdG8gc2VuZCBtZSB5b3VyIHRleHQgdmlhIG1haWws IHRoYXQncyBvay4gSSdkIHN0cm9uZ2x5IHByZWZlciBYTUwgZm9ybWF0dGVkIHNlY3Rpb25zIGlm IHBvc3NpYmxlIDstKQ0KDQoNCg0KQ2FuIHdlIGhhdmUgYWxsIHRleHQgaW4gYnkgV2VkIG5leHQg d2Vlaz8NCg0KDQoNCkkgcGxhbiB0byBjb25zb2xpZGF0ZSBhbmQgcHVzaCAtMDMgYnkgZW5kIG9m IG5leHQgd2Vlay4NCg0KDQoNCk1pY2hhZWwNCg0KLS0NCg0KQmllbiBjb3JkaWFsZW1lbnQsIEJl c3QgcmVnYXJkcywNCg0KTGF1cmVudCBDaWF2YWdsaWENClNlY3VyZSBDbG91ZCBOZXR3b3JraW5n DQpCZWxsIExhYnMgfCBBbGNhdGVsIEx1Y2VudA0KDQpwaG9uZTogKzMzIDE2MCA0MDIgNjM2DQpl bWFpbDogbGF1cmVudC5jaWF2YWdsaWFAYWxjYXRlbC1sdWNlbnQuY29tPG1haWx0bzpsYXVyZW50 LmNpYXZhZ2xpYUBhbGNhdGVsLWx1Y2VudC5jb20+DQpsaW5rZWRpbjogbGF1cmVudGNpYXZhZ2xp YTxodHRwOi8vZnIubGlua2VkaW4uY29tL2luL2xhdXJlbnRjaWF2YWdsaWEvPg0KYWRkcmVzczog Um91dGUgZGUgVmlsbGVqdXN0IHwgOTE2MjAgTm96YXkgfCBGcmFuY2UNCg== --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FF828Bxmbrcdx14ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlRyZWJ1Y2hldCBNUyBcLCBz YW5zLXNlcmlmIjsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbToxMC4w cHQ7DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWxpbmUtaGVpZ2h0OjExNSU7DQoJZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMzMzMz MzM7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2lu LXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjEwLjBwdDsNCgltYXJnaW4tbGVmdDowY207DQoJ bGluZS1oZWlnaHQ6MTE1JTsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7DQoJY29sb3I6IzMzMzMzMzsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9 DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZv cm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjojMzMz MzMzO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjU5NS4zcHQgODQxLjlwdDsN CgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9Indo aXRlIiBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29s b3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2xpbmUtaGVpZ2h0OjExNSU7Y29sb3I6IzFGNDk3RCI+SGkgTGF1cmVudCwNCjxvOnA+PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBj b2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7bGluZS1oZWlnaHQ6MTE1JTtjb2xvcjojMUY0OTdEIj5SZWdhcmRpbmcgc2VjdGlvbiA4OiBB Z3JlZSwgbm8gY2hhbmdlcyBuZWVkZWQgZm9yIG5vdywgYnV0IGZlZWRiYWNrIGZyb20gdGhlIGNv bW11bml0eS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7bGluZS1oZWlnaHQ6MTE1JTtjb2xvcjojMUY0OTdEIj5S ZWdhcmRpbmcgc2VjdGlvbiA5OiBJIHJlLXJlYWQgYm90aCwgdGhpcyBzZWN0aW9uIGFuZCBzZWN0 aW9uIDMuMi4gb2YgUkZDNzU3NS4gTXkgcGVyc29uYWwgb3BpbmlvbiBpcyB0aGF0IHRoaXMgc2Vj dGlvbiBpcyBub3QgbmVlZGVkDQogaW4gdGhlIHJlZmVyZW5jZSBkb2N1bWVudCwgYW5kIEkgc3Vn Z2VzdCB0aGVyZWZvcmUgdG8gZHJvcCBpdC4gPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNl PSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtsaW5lLWhlaWdodDoxMTUl O2NvbG9yOiMxRjQ5N0QiPkxldOKAmXMga2VlcCB0aGUgZG9jdW1lbnQgYXMgY29uY2lzZSBhcyBw b3NzaWJsZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7bGluZS1oZWlnaHQ6MTE1JTtjb2xvcjojMUY0OTdEIj5N aWNoYWVsPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBw dCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdDtsaW5lLWhl aWdodDpub3JtYWwiPg0KPGI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJUYWhv bWEiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0 ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCO2ZvbnQtd2VpZ2h0OmJvbGQiPkZyb206PC9z cGFuPjwvZm9udD48L2I+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJUYWhvbWEi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0 O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj4NCiBMYXVyZW50IENpYXZhZ2xpYSBbbWFpbHRv OkxhdXJlbnQuQ2lhdmFnbGlhQGFsY2F0ZWwtbHVjZW50LmNvbV0gPGJyPg0KPGI+PHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlNlbnQ6PC9zcGFuPjwvYj4gMTkgSnVuZSAyMDE1IDEzOjEx PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOjwvc3Bhbj48L2I+IE1p Y2hhZWwgQmVocmluZ2VyIChtYmVocmluZyk7IEFuaW1hIFdHPGJyPg0KPGI+PHNwYW4gc3R5bGU9 ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOjwvc3Bhbj48L2I+IGRyYWZ0LWJlaHJpbmdlci1hbmltYS1y ZWZlcmVuY2UtbW9kZWxAdG9vbHMuaWV0Zi5vcmc8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13 ZWlnaHQ6Ym9sZCI+U3ViamVjdDo8L3NwYW4+PC9iPiBSZTogUmVmZXJlbmNlIGRvYyBvbiBnaXRo dWI8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMzMzMzMzIiBmYWNlPSJDYWxpYnJp Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtsaW5lLWhlaWdodDoxMTUlIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzMzMzMzMyIgZmFj ZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2xpbmUtaGVpZ2h0 OjExNSU7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkRlYXIgTWljaGFlbCwg YWxsLDxicj4NCjxicj4NClNlY3Rpb24gOCBpcyBuZXcsIHNvIEkgZG9uJ3QgdGhpbmsgaXQgbmVl ZHMgYW4gdXBhdGUgZm9yIC0wMywgYnV0IEkgd291bGQgYmUgaGFwcHkgdG8gbWFrZSBjaGFuZ2Vz IGJhc2VkIG9uIGZlZWRiYWNrL2NvbW1lbnRzLjxicj4NCjxicj4NCkZvciBTZWN0aW9uIDk6IElz IHRoZSBjdXJyZW50IHRleHQgcmVmZXJyaW5nIHRvIFJGQzc1NzUsIFNlY3Rpb24gMy4yLiBDb2V4 aXN0ZW5jZSB3aXRoIFRyYWRpdGlvbmFsIE1hbmFnZW1lbnQ/PGJyPg0KSWYgeWVzLCB0aGVuIEkg d291bGQgc3VnZ2VzdCByZW5hbWluZyBTZWN0aW9uIDkgdG8gcmVmbGVjdCB0aGUgYWN0dWFsIGNv bnRlbnQgd2hpY2ggZm9jdXNlcyBvbiAmcXVvdDttYW5hZ2VtZW50IG9yIG9wZXJhdGlvbiBtb2Rl JnF1b3Q7IHByaW9yaXRpemF0aW9uLjxicj4NCklmIGFncmVlZC9jb3JyZWN0LCBJIGNhbiB1cGRh dGUgdGhlIHRleHQgZm9yIFNlY3Rpb24gOSBieSBuZXh0IFdlZG5lc2RheS48YnI+DQo8YnI+DQpU aG91Z2gsIHRoZSB0b3BpYyBvZiAmcXVvdDtoeWJyaWQmcXVvdDsgb3BlcmF0aW9ucyAoYXV0b25v bWljIGFuZCBub24tYXV0b25vbWljKSBpcyBzdGlsbCByZWxldmFudCwgYnV0IHNsaWdodGx5IGRp ZmZlcmVudCBmcm9tIHByaW9yaXRpemF0aW9uLiBTb21lIG9uZ29pbmcgZGlzY3Vzc2lvbnMgb24g dGhlIEFOSU1BIG1haWxpbmcgbGlzdCBvbiBkb21haW4sIGludGVudCwgYW5kIGNvbnN0cmFpbmVk IG5vZGVzIHBhcnRpY2lwYXRlIGluIHRoaXMgdG9waWMuPGJyPg0KQSB0ZXh0IG9uIHRoaXMgaW4g LTAzIGlzIHRvbyBhbWJpdGlvdXMsIGJ1dCB3ZSBjYW4gdHJpZ2dlciBhIGRpc2N1c3Npb24gdGhy ZWFkIHRvIGNhcHR1cmUgdGhlIG9wZXJhdGluZyBwcmluY2lwbGVzIEFOSU1BIGFpbXMgYXQgY29u Y2VybmluZyB0aGlzIGh5YnJpZCBtb2RlIG9mIG9wZXJhdGlvbiAoaS5lLiBob3cgQUZzIGFuZCBu b24tQUZzIGNvLW9wZXJhdGUsIGFyZSBtYW5hZ2VkL2dvdmVybmVkIGJ5IEludGVudC9vdGhlciBt ZWFucywgcm9sZQ0KIG9mICZxdW90O2hlbHBpbmcmcXVvdDsgbm9kZXMvZnVuY3Rpb25zL2dhdGV3 YXlzLi4uKTxicj4NCjxicj4NCkJlc3QgcmVnYXJkcywgTGF1cmVudC48YnI+DQo8YnI+DQo8L3Nw YW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxmb250IHNpemU9 IjIiIGNvbG9yPSIjMzMzMzMzIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtsaW5lLWhlaWdodDoxMTUlIj5PbiAxNy8wNi8yMDE1IDE0OjQxLCBNaWNoYWVsIEJl aHJpbmdlciAobWJlaHJpbmcpIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzMzMzMzMyIgZmFjZT0iQ291cmll ciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2xpbmUtaGVpZ2h0OjExNSUiPkkg aGF2ZSBub3cgYWxzbyBjcmVhdGVkIGEgcmVwb3NpdG9yeSBpbiBnaXRodWI6IDxhIGhyZWY9Imh0 dHBzOi8vZ2l0aHViLmNvbS9tYmVocmluZy9BTklNQS1SZWZlcmVuY2UtTW9kZWwiPmh0dHBzOi8v Z2l0aHViLmNvbS9tYmVocmluZy9BTklNQS1SZWZlcmVuY2UtTW9kZWw8L2E+PG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzMzMzMzMyIg ZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2xpbmUtaGVp Z2h0OjExNSUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxwcmU+PGZv bnQgc2l6ZT0iMiIgY29sb3I9IiMzMzMzMzMiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtsaW5lLWhlaWdodDoxMTUlIj5JIHN1Z2dlc3RlZCBpbml0aWFs IGNvbnRyaWJ1dGlvbnMsIGFzIHBlciBiZWxvdyBsaXN0IChvcGVuIHRvIG1vcmUgc3VnZ2VzdGlv bnMgOy0pIDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0i MiIgY29sb3I9IiMzMzMzMzMiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtsaW5lLWhlaWdodDoxMTUlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wcmU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMzMzMzMzIiBmYWNlPSJDb3Vy aWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bGluZS1oZWlnaHQ6MTE1JSI+ LSBNaWNoYWVsIFJpY2hhcmRzb246IHNlY3Rpb24gMy4zIChjb25zdHJhaW5lZCBub2Rlcyk8bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSIj MzMzMzMzIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 bGluZS1oZWlnaHQ6MTE1JSI+LSBMaXViaW5nOiA0LjEgYW5kIDQuMiAoTmFtaW5nLCBhZGRyZXNz aW5nKTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIg Y29sb3I9IiMzMzMzMzMiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtsaW5lLWhlaWdodDoxMTUlIj4tIEJyaWFuIENhcnBlbnRlcjogNC40IChzaWduYWxp bmcpLiBDb3VsZCB5b3UgYWxzbyBjb3ZlciA0LjUgKGludGVudCBkaXN0cmlidXRpb24pIGFuZCA0 LjMgKGRpc2NvdmVyeSk/IC0gdmVyeSByZWxhdGVkISE8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wcmU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMzMzMzMzIiBmYWNlPSJDb3VyaWVy IE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bGluZS1oZWlnaHQ6MTE1JSI+LSBK YXNvbiBDb2xlbWFuOiBTZWN0aW9uIDUuMSwgNS4yLCA1LjQsIDUuNSAoUEtJLCBjZXJ0LCBzdWIg YW5kIGNyb3NzLWRvbWFpbik8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxm b250IHNpemU9IjIiIGNvbG9yPSIjMzMzMzMzIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bGluZS1oZWlnaHQ6MTE1JSI+LSBKZWZlcnNvbiBOb2JyZTog Ny4xLCA3LjIsIDcuMyAoTWFuYWdlbWVudCwgaW50ZW50LCBhZ2dyZWdhdGVkIHJlcG9ydGluZyk8 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9y PSIjMzMzMzMzIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7bGluZS1oZWlnaHQ6MTE1JSI+LSBKb2huIFN0cmFzc25lcjogNy40LCA3LjUsIDcuNiAoZmVl ZGJhY2sgbG9vcHMsIEFQSVMgYW5kIG1vZGVscy4pPG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzMzMzMzMyIgZmFjZT0iQ291cmllciBO ZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2xpbmUtaGVpZ2h0OjExNSUiPi0gTGF1 cmVudCBDaWF2YWdsaWE6IFNlY3Rpb25zIDggYW5kIDkgKGRvIHRoZXkgbmVlZCBhbiB1cGRhdGU/ KTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29s b3I9IiMzMzMzMzMiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtsaW5lLWhlaWdodDoxMTUlIj4tIFRvZXJsZXNzIGFuZCBJIHdpbGwgc2hhcmUgdGhlIHJl bWFpbmluZyBzZWN0aW9ucyBmb3Igbm93LjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4N CjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMzMzMzMzMiIGZhY2U9IkNvdXJpZXIgTmV3Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtsaW5lLWhlaWdodDoxMTUlIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSIj MzMzMzMzIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 bGluZS1oZWlnaHQ6MTE1JSI+Q2FuIHRoZSB2b2x1bnRlZXJzIHBsZWFzZSBsZXQgbWUga25vdyBi eSB3aGVuIHRoZXkgY2FuIGNvbnRyaWJ1dGUgdGhlaXIgdGV4dD8mbmJzcDsgRWl0aGVyIGluIGdp dGh1YiAobGV0IG1lIGtub3cgeW91ciBJRCBpZiB5b3Ugd2FudCB0byBjb250cmlidXRlIHRoZXJl KSA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNv bG9yPSIjMzMzMzMzIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7bGluZS1oZWlnaHQ6MTE1JSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250Pjwv cHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzMzMzMzMyIgZmFjZT0iQ291cmllciBO ZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2xpbmUtaGVpZ2h0OjExNSUiPkdpdGh1 YiBpcyBub3QgbWFuZGF0b3J5IC0gSWYgeW91IHdhbnQgdG8gc2VuZCBtZSB5b3VyIHRleHQgdmlh IG1haWwsIHRoYXQncyBvay4gSSdkIHN0cm9uZ2x5IHByZWZlciBYTUwgZm9ybWF0dGVkIHNlY3Rp b25zIGlmIHBvc3NpYmxlIDstKSA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJl Pjxmb250IHNpemU9IjIiIGNvbG9yPSIjMzMzMzMzIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bGluZS1oZWlnaHQ6MTE1JSI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzMzMzMz MyIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2xpbmUt aGVpZ2h0OjExNSUiPkNhbiB3ZSBoYXZlIGFsbCB0ZXh0IGluIGJ5IFdlZCBuZXh0IHdlZWs/IDxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9 IiMzMzMzMzMiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtsaW5lLWhlaWdodDoxMTUlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+ DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMzMzMzMzIiBmYWNlPSJDb3VyaWVyIE5ldyI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bGluZS1oZWlnaHQ6MTE1JSI+SSBwbGFuIHRv IGNvbnNvbGlkYXRlIGFuZCBwdXNoIC0wMyBieSBlbmQgb2YgbmV4dCB3ZWVrLiA8bzpwPjwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMzMzMzMz IiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bGluZS1o ZWlnaHQ6MTE1JSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48 Zm9udCBzaXplPSIyIiBjb2xvcj0iIzMzMzMzMyIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2xpbmUtaGVpZ2h0OjExNSUiPk1pY2hhZWw8bzpwPjwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzMzMzMzMyIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7bGluZS1oZWlnaHQ6MTE1JSI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbTowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0O2xpbmUtaGVpZ2h0Om5vcm1hbCI+ DQo8Zm9udCBzaXplPSIyIiBjb2xvcj0iIzMzMzMzMyIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPi0tIDxicj4NCjxicj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQg c2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u dD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTowY207bWFy Z2luLWJvdHRvbTouMDAwMXB0O2xpbmUtaGVpZ2h0Om5vcm1hbCI+DQo8Zm9udCBzaXplPSIyIiBj b2xvcj0iIzMzMzMzMyIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPkJpZW4gY29yZGlhbGVtZW50LCBCZXN0IHJlZ2FyZHMsPC9zcGFuPjwvZm9udD48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjBjbTtt YXJnaW4tYm90dG9tOi4wMDAxcHQ7bGluZS1oZWlnaHQ6bm9ybWFsIj4NCjxmb250IHNpemU9IjIi IGNvbG9yPSIjMzMzMzMzIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdCI+Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQ7bGlu ZS1oZWlnaHQ6bm9ybWFsIj4NCjxiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMzMzMzMzIiBmYWNl PSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LXdlaWdodDpib2xk Ij5MYXVyZW50IENpYXZhZ2xpYTwvc3Bhbj48L2ZvbnQ+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MGNtO21hcmdpbi1ib3R0b206 LjAwMDFwdDtsaW5lLWhlaWdodDpub3JtYWwiPg0KPGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMzMzMz MzMiIGZhY2U9IlRyZWJ1Y2hldCBNUyAsIHNhbnMtc2VyaWYiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyAsIHNhbnMtc2VyaWYmcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPlNlY3VyZSBDbG91ZCBOZXR3b3JraW5nPC9zcGFuPjwvZm9u dD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQ7bGluZS1oZWlnaHQ6bm9ybWFsIj4NCjxmb250 IHNpemU9IjIiIGNvbG9yPSIjMzMzMzMzIiBmYWNlPSJUcmVidWNoZXQgTVMgLCBzYW5zLXNlcmlm Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUcmVidWNo ZXQgTVMgLCBzYW5zLXNlcmlmJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5CZWxsIExhYnMgfCBB bGNhdGVsIEx1Y2VudDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0O2xp bmUtaGVpZ2h0Om5vcm1hbCI+DQo8Zm9udCBzaXplPSIyIiBjb2xvcj0iIzMzMzMzMyIgZmFjZT0i VHJlYnVjaGV0IE1TICwgc2Fucy1zZXJpZiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TICwgc2Fucy1zZXJpZiZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjBjbTttYXJnaW4tYm90dG9tOi4wMDAx cHQ7bGluZS1oZWlnaHQ6bm9ybWFsIj4NCjxmb250IHNpemU9IjIiIGNvbG9yPSIjMzMzMzMzIiBm YWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+cGhvbmU6ICYjNDM7 MzMmbmJzcDsxNjAgNDAyJm5ic3A7NjM2DQo8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MGNtO21hcmdpbi1ib3R0 b206LjAwMDFwdDtsaW5lLWhlaWdodDpub3JtYWwiPg0KPGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMz MzMzMzMiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5lbWFp bDoNCjwvc3Bhbj48L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOmxhdXJlbnQuY2lhdmFnbGlhQGFsY2F0 ZWwtbHVjZW50LmNvbSI+PGZvbnQgc2l6ZT0iMiI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0Ij5sYXVyZW50LmNpYXZhZ2xpYUBhbGNhdGVsLWx1Y2VudC5jb208L3NwYW4+ PC9mb250PjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQ7bGluZS1oZWlnaHQ6bm9ybWFs Ij4NCjxmb250IHNpemU9IjIiIGNvbG9yPSIjMzMzMzMzIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+bGlua2VkaW46DQo8L3NwYW4+PC9mb250PjxhIGhyZWY9 Imh0dHA6Ly9mci5saW5rZWRpbi5jb20vaW4vbGF1cmVudGNpYXZhZ2xpYS8iPjxmb250IHNpemU9 IjIiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+bGF1cmVudGNpYXZh Z2xpYTwvc3Bhbj48L2ZvbnQ+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdDtsaW5lLWhl aWdodDpub3JtYWwiPg0KPGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMzMzMzMzMiIGZhY2U9IkNhbGli cmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5hZGRyZXNzOiBSb3V0ZSBkZSBWaWxs ZWp1c3QgfCA5MTYyMCBOb3pheSB8IEZyYW5jZTwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FF828Bxmbrcdx14ciscoc_-- From nobody Mon Jun 29 02:45:38 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 135B51A8925 for ; Mon, 29 Jun 2015 02:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.928 X-Spam-Level: X-Spam-Status: No, score=-5.928 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmEFoGYH1l2b for ; Mon, 29 Jun 2015 02:45:34 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 654ED1A1AA8 for ; Mon, 29 Jun 2015 02:45:33 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id B3A3314AA1970; Mon, 29 Jun 2015 09:45:29 +0000 (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 t5T9jTcA019405 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Jun 2015 11:45:30 +0200 Received: from [172.27.204.50] (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, 29 Jun 2015 11:45:29 +0200 Message-ID: <559113B8.2060601@alcatel-lucent.com> Date: Mon, 29 Jun 2015 11:45:28 +0200 From: Laurent Ciavaglia Organization: Alcatel-Lucent Bell Labs France User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , Anima WG References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FEE3B8@xmb-rcd-x14.cisco.com> <5583F8D3.6070208@alcatel-lucent.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF828B@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF828B@xmb-rcd-x14.cisco.com> Content-Type: multipart/alternative; boundary="------------070507050800090302000604" X-Originating-IP: [135.239.27.39] Archived-At: Cc: "draft-behringer-anima-reference-model@tools.ietf.org" Subject: Re: [Anima] Reference doc on github X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jun 2015 09:45:37 -0000 --------------070507050800090302000604 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Dear Michael, I think that in ANIMA we should eventually document "interactions" with non-autonomic networks. It is fine for me to not have a section in the reference document for the moment, as this topic is still largely undefined. So ok to drop the section in the next version, knowing that in furhter revision it might be integrated again (probably under a different name). Thanks, best regards, Laurent. On 29/06/2015 11:39, Michael Behringer (mbehring) wrote: > > Hi Laurent, > > Regarding section 8: Agree, no changes needed for now, but feedback > from the community. > > Regarding section 9: I re-read both, this section and section 3.2. of > RFC7575. My personal opinion is that this section is not needed in the > reference document, and I suggest therefore to drop it. > > Let’s keep the document as concise as possible. > > Michael > > *From:*Laurent Ciavaglia [mailto:Laurent.Ciavaglia@alcatel-lucent.com] > *Sent:* 19 June 2015 13:11 > *To:* Michael Behringer (mbehring); Anima WG > *Cc:* draft-behringer-anima-reference-model@tools.ietf.org > *Subject:* Re: Reference doc on github > > Dear Michael, all, > > Section 8 is new, so I don't think it needs an upate for -03, but I > would be happy to make changes based on feedback/comments. > > For Section 9: Is the current text referring to RFC7575, Section 3.2. > Coexistence with Traditional Management? > If yes, then I would suggest renaming Section 9 to reflect the actual > content which focuses on "management or operation mode" prioritization. > If agreed/correct, I can update the text for Section 9 by next Wednesday. > > Though, the topic of "hybrid" operations (autonomic and non-autonomic) > is still relevant, but slightly different from prioritization. Some > ongoing discussions on the ANIMA mailing list on domain, intent, and > constrained nodes participate in this topic. > A text on this in -03 is too ambitious, but we can trigger a > discussion thread to capture the operating principles ANIMA aims at > concerning this hybrid mode of operation (i.e. how AFs and non-AFs > co-operate, are managed/governed by Intent/other means, role of > "helping" nodes/functions/gateways...) > > Best regards, Laurent. > > On 17/06/2015 14:41, Michael Behringer (mbehring) wrote: > > I have now also created a repository in github:https://github.com/mbehring/ANIMA-Reference-Model > > > > I suggested initial contributions, as per below list (open to more suggestions ;-) > > > > - Michael Richardson: section 3.3 (constrained nodes) > > - Liubing: 4.1 and 4.2 (Naming, addressing) > > - Brian Carpenter: 4.4 (signaling). Could you also cover 4.5 (intent distribution) and 4.3 (discovery)? - very related!! > > - Jason Coleman: Section 5.1, 5.2, 5.4, 5.5 (PKI, cert, sub and cross-domain) > > - Jeferson Nobre: 7.1, 7.2, 7.3 (Management, intent, aggregated reporting) > > - John Strassner: 7.4, 7.5, 7.6 (feedback loops, APIS and models.) > > - Laurent Ciavaglia: Sections 8 and 9 (do they need an update?) > > - Toerless and I will share the remaining sections for now. > > > > Can the volunteers please let me know by when they can contribute their text? Either in github (let me know your ID if you want to contribute there) > > > > Github is not mandatory - If you want to send me your text via mail, that's ok. I'd strongly prefer XML formatted sections if possible ;-) > > > > Can we have all text in by Wed next week? > > > > I plan to consolidate and push -03 by end of next week. > > > > Michael > > -- > > Bien cordialement, Best regards, > > *Laurent Ciavaglia* > > Secure Cloud Networking > > Bell Labs | Alcatel Lucent > > phone: +33 160 402 636 > > email: laurent.ciavaglia@alcatel-lucent.com > > > linkedin: laurentciavaglia > > address: Route de Villejust | 91620 Nozay | France > -- Bien cordialement, Best regards, *Laurent Ciavaglia* Secure Cloud Networking Bell Labs | Alcatel Lucent phone: +33 160 402 636 email: laurent.ciavaglia@alcatel-lucent.com linkedin: laurentciavaglia address: Route de Villejust | 91620 Nozay | France --------------070507050800090302000604 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit Dear Michael,

I think that in ANIMA we should eventually document "interactions" with non-autonomic networks.

It is fine for me to not have a section in the reference document for the moment, as this topic is still largely undefined. So ok to drop the section in the next version, knowing that in furhter revision it might be integrated again (probably under a different name).

Thanks, best regards, Laurent.


On 29/06/2015 11:39, Michael Behringer (mbehring) wrote:

Hi Laurent,

Regarding section 8: Agree, no changes needed for now, but feedback from the community.

Regarding section 9: I re-read both, this section and section 3.2. of RFC7575. My personal opinion is that this section is not needed in the reference document, and I suggest therefore to drop it.

Let’s keep the document as concise as possible.

Michael

From: Laurent Ciavaglia [mailto:Laurent.Ciavaglia@alcatel-lucent.com]
Sent: 19 June 2015 13:11
To: Michael Behringer (mbehring); Anima WG
Cc: draft-behringer-anima-reference-model@tools.ietf.org
Subject: Re: Reference doc on github

 

Dear Michael, all,

Section 8 is new, so I don't think it needs an upate for -03, but I would be happy to make changes based on feedback/comments.

For Section 9: Is the current text referring to RFC7575, Section 3.2. Coexistence with Traditional Management?
If yes, then I would suggest renaming Section 9 to reflect the actual content which focuses on "management or operation mode" prioritization.
If agreed/correct, I can update the text for Section 9 by next Wednesday.

Though, the topic of "hybrid" operations (autonomic and non-autonomic) is still relevant, but slightly different from prioritization. Some ongoing discussions on the ANIMA mailing list on domain, intent, and constrained nodes participate in this topic.
A text on this in -03 is too ambitious, but we can trigger a discussion thread to capture the operating principles ANIMA aims at concerning this hybrid mode of operation (i.e. how AFs and non-AFs co-operate, are managed/governed by Intent/other means, role of "helping" nodes/functions/gateways...)

Best regards, Laurent.

On 17/06/2015 14:41, Michael Behringer (mbehring) wrote:

I have now also created a repository in github: https://github.com/mbehring/ANIMA-Reference-Model
 
I suggested initial contributions, as per below list (open to more suggestions ;-) 
 
- Michael Richardson: section 3.3 (constrained nodes)
- Liubing: 4.1 and 4.2 (Naming, addressing)
- Brian Carpenter: 4.4 (signaling). Could you also cover 4.5 (intent distribution) and 4.3 (discovery)? - very related!!
- Jason Coleman: Section 5.1, 5.2, 5.4, 5.5 (PKI, cert, sub and cross-domain)
- Jeferson Nobre: 7.1, 7.2, 7.3 (Management, intent, aggregated reporting)
- John Strassner: 7.4, 7.5, 7.6 (feedback loops, APIS and models.)
- Laurent Ciavaglia: Sections 8 and 9 (do they need an update?)
- Toerless and I will share the remaining sections for now.
 
Can the volunteers please let me know by when they can contribute their text?  Either in github (let me know your ID if you want to contribute there) 
 
Github is not mandatory - If you want to send me your text via mail, that's ok. I'd strongly prefer XML formatted sections if possible ;-) 
 
Can we have all text in by Wed next week? 
 
I plan to consolidate and push -03 by end of next week. 
 
Michael

 

--

Bien cordialement, Best regards,

 

Laurent Ciavaglia

Secure Cloud Networking

Bell Labs | Alcatel Lucent

 

phone: +33 160 402 636

email: laurent.ciavaglia@alcatel-lucent.com

linkedin: laurentciavaglia

address: Route de Villejust | 91620 Nozay | France


--

Bien cordialement, Best regards,

 

Laurent Ciavaglia

Secure Cloud Networking

Bell Labs | Alcatel Lucent

 

phone: +33 160 402 636

email: laurent.ciavaglia@alcatel-lucent.com

linkedin: laurentciavaglia

address: Route de Villejust | 91620 Nozay | France

--------------070507050800090302000604-- From nobody Mon Jun 29 02:46:34 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD2B1A87E9 for ; Mon, 29 Jun 2015 02:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.529 X-Spam-Level: X-Spam-Status: No, score=-13.529 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id op8YkrGBscFj for ; Mon, 29 Jun 2015 02:46:30 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CFDD1A86E6 for ; Mon, 29 Jun 2015 02:46:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35662; q=dns/txt; s=iport; t=1435571189; x=1436780789; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=nQWYh7olzxR+nPcv+mLgXkUdX38BdRvlMoxPoGKxJoo=; b=g1HvngRcDQJR4CYMQQkVP7Rv4397dqfmBtngGBInJoUbz5VGAYyRfIUC JLX5KRc1kOnBiWSGt8Yyz5tsGdYLoATQEKGPJkV5q9iMk+vprujgq5VbA +0pWHHddF8/x2geQ2W7GbgFOb+uaw93NSjHkTJQ6Cy63wyg93Vr5rr9Q7 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CjBQCrE5FV/4cNJK1bgkVMVF8GvG4qCYFmhXgCHIETOBQBAQEBAQEBgQqEIgEBAQQjCkELDgICAQgRBAEBCxYBBgMCAgIZFxQJCAEBBAENBQgMiBsNsAiWBgEBAQEBAQEBAQEBAQEBAQEBAQEBARcEi0aEIxACAR8FERcEBgGCaC+BFAWMEodyAYRYiDaEEYMNh1+EJ4NdERWDem+BAwc8gQIBAQE X-IronPort-AV: E=Sophos;i="5.13,698,1427760000"; d="scan'208,217";a="163856741" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Jun 2015 09:46:28 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t5T9kRDP013589 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Jun 2015 09:46:27 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.179]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Mon, 29 Jun 2015 04:46:27 -0500 From: "Michael Behringer (mbehring)" To: Laurent Ciavaglia , Anima WG Thread-Topic: [Anima] Reference doc on github Thread-Index: AdCo+dAvfC4NDb/zTJOIdvnhU/aAQgBsMD2AAekoXPAACsK2AAAKc9Ew Date: Mon, 29 Jun 2015 09:46:26 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF82F3@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FEE3B8@xmb-rcd-x14.cisco.com> <5583F8D3.6070208@alcatel-lucent.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF828B@xmb-rcd-x14.cisco.com> <559113B8.2060601@alcatel-lucent.com> In-Reply-To: <559113B8.2060601@alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.34] Content-Type: multipart/alternative; boundary="_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FF82F3xmbrcdx14ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "draft-behringer-anima-reference-model@tools.ietf.org" Subject: Re: [Anima] Reference doc on github X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jun 2015 09:46:33 -0000 --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FF82F3xmbrcdx14ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWNrLCB0aGFua3MgZm9yIHRoZSBxdWljayByZXNwb25zZSEg4pi6DQpNaWNoYWVsDQoNCkZyb206 IEFuaW1hIFttYWlsdG86YW5pbWEtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExhdXJl bnQgQ2lhdmFnbGlhDQpTZW50OiAyOSBKdW5lIDIwMTUgMTE6NDUNClRvOiBNaWNoYWVsIEJlaHJp bmdlciAobWJlaHJpbmcpOyBBbmltYSBXRw0KQ2M6IGRyYWZ0LWJlaHJpbmdlci1hbmltYS1yZWZl cmVuY2UtbW9kZWxAdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbQW5pbWFdIFJlZmVyZW5j ZSBkb2Mgb24gZ2l0aHViDQoNCkRlYXIgTWljaGFlbCwNCg0KSSB0aGluayB0aGF0IGluIEFOSU1B IHdlIHNob3VsZCBldmVudHVhbGx5IGRvY3VtZW50ICJpbnRlcmFjdGlvbnMiIHdpdGggbm9uLWF1 dG9ub21pYyBuZXR3b3Jrcy4NCg0KSXQgaXMgZmluZSBmb3IgbWUgdG8gbm90IGhhdmUgYSBzZWN0 aW9uIGluIHRoZSByZWZlcmVuY2UgZG9jdW1lbnQgZm9yIHRoZSBtb21lbnQsIGFzIHRoaXMgdG9w aWMgaXMgc3RpbGwgbGFyZ2VseSB1bmRlZmluZWQuIFNvIG9rIHRvIGRyb3AgdGhlIHNlY3Rpb24g aW4gdGhlIG5leHQgdmVyc2lvbiwga25vd2luZyB0aGF0IGluIGZ1cmh0ZXIgcmV2aXNpb24gaXQg bWlnaHQgYmUgaW50ZWdyYXRlZCBhZ2FpbiAocHJvYmFibHkgdW5kZXIgYSBkaWZmZXJlbnQgbmFt ZSkuDQoNClRoYW5rcywgYmVzdCByZWdhcmRzLCBMYXVyZW50Lg0KDQpPbiAyOS8wNi8yMDE1IDEx OjM5LCBNaWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpIHdyb3RlOg0KSGkgTGF1cmVudCwNClJl Z2FyZGluZyBzZWN0aW9uIDg6IEFncmVlLCBubyBjaGFuZ2VzIG5lZWRlZCBmb3Igbm93LCBidXQg ZmVlZGJhY2sgZnJvbSB0aGUgY29tbXVuaXR5Lg0KUmVnYXJkaW5nIHNlY3Rpb24gOTogSSByZS1y ZWFkIGJvdGgsIHRoaXMgc2VjdGlvbiBhbmQgc2VjdGlvbiAzLjIuIG9mIFJGQzc1NzUuIE15IHBl cnNvbmFsIG9waW5pb24gaXMgdGhhdCB0aGlzIHNlY3Rpb24gaXMgbm90IG5lZWRlZCBpbiB0aGUg cmVmZXJlbmNlIGRvY3VtZW50LCBhbmQgSSBzdWdnZXN0IHRoZXJlZm9yZSB0byBkcm9wIGl0Lg0K TGV04oCZcyBrZWVwIHRoZSBkb2N1bWVudCBhcyBjb25jaXNlIGFzIHBvc3NpYmxlLg0KTWljaGFl bA0KRnJvbTogTGF1cmVudCBDaWF2YWdsaWEgW21haWx0bzpMYXVyZW50LkNpYXZhZ2xpYUBhbGNh dGVsLWx1Y2VudC5jb21dDQpTZW50OiAxOSBKdW5lIDIwMTUgMTM6MTENClRvOiBNaWNoYWVsIEJl aHJpbmdlciAobWJlaHJpbmcpOyBBbmltYSBXRw0KQ2M6IGRyYWZ0LWJlaHJpbmdlci1hbmltYS1y ZWZlcmVuY2UtbW9kZWxAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWJlaHJpbmdlci1hbmlt YS1yZWZlcmVuY2UtbW9kZWxAdG9vbHMuaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogUmVmZXJlbmNl IGRvYyBvbiBnaXRodWINCg0KRGVhciBNaWNoYWVsLCBhbGwsDQoNClNlY3Rpb24gOCBpcyBuZXcs IHNvIEkgZG9uJ3QgdGhpbmsgaXQgbmVlZHMgYW4gdXBhdGUgZm9yIC0wMywgYnV0IEkgd291bGQg YmUgaGFwcHkgdG8gbWFrZSBjaGFuZ2VzIGJhc2VkIG9uIGZlZWRiYWNrL2NvbW1lbnRzLg0KDQpG b3IgU2VjdGlvbiA5OiBJcyB0aGUgY3VycmVudCB0ZXh0IHJlZmVycmluZyB0byBSRkM3NTc1LCBT ZWN0aW9uIDMuMi4gQ29leGlzdGVuY2Ugd2l0aCBUcmFkaXRpb25hbCBNYW5hZ2VtZW50Pw0KSWYg eWVzLCB0aGVuIEkgd291bGQgc3VnZ2VzdCByZW5hbWluZyBTZWN0aW9uIDkgdG8gcmVmbGVjdCB0 aGUgYWN0dWFsIGNvbnRlbnQgd2hpY2ggZm9jdXNlcyBvbiAibWFuYWdlbWVudCBvciBvcGVyYXRp b24gbW9kZSIgcHJpb3JpdGl6YXRpb24uDQpJZiBhZ3JlZWQvY29ycmVjdCwgSSBjYW4gdXBkYXRl IHRoZSB0ZXh0IGZvciBTZWN0aW9uIDkgYnkgbmV4dCBXZWRuZXNkYXkuDQoNClRob3VnaCwgdGhl IHRvcGljIG9mICJoeWJyaWQiIG9wZXJhdGlvbnMgKGF1dG9ub21pYyBhbmQgbm9uLWF1dG9ub21p YykgaXMgc3RpbGwgcmVsZXZhbnQsIGJ1dCBzbGlnaHRseSBkaWZmZXJlbnQgZnJvbSBwcmlvcml0 aXphdGlvbi4gU29tZSBvbmdvaW5nIGRpc2N1c3Npb25zIG9uIHRoZSBBTklNQSBtYWlsaW5nIGxp c3Qgb24gZG9tYWluLCBpbnRlbnQsIGFuZCBjb25zdHJhaW5lZCBub2RlcyBwYXJ0aWNpcGF0ZSBp biB0aGlzIHRvcGljLg0KQSB0ZXh0IG9uIHRoaXMgaW4gLTAzIGlzIHRvbyBhbWJpdGlvdXMsIGJ1 dCB3ZSBjYW4gdHJpZ2dlciBhIGRpc2N1c3Npb24gdGhyZWFkIHRvIGNhcHR1cmUgdGhlIG9wZXJh dGluZyBwcmluY2lwbGVzIEFOSU1BIGFpbXMgYXQgY29uY2VybmluZyB0aGlzIGh5YnJpZCBtb2Rl IG9mIG9wZXJhdGlvbiAoaS5lLiBob3cgQUZzIGFuZCBub24tQUZzIGNvLW9wZXJhdGUsIGFyZSBt YW5hZ2VkL2dvdmVybmVkIGJ5IEludGVudC9vdGhlciBtZWFucywgcm9sZSBvZiAiaGVscGluZyIg bm9kZXMvZnVuY3Rpb25zL2dhdGV3YXlzLi4uKQ0KDQpCZXN0IHJlZ2FyZHMsIExhdXJlbnQuDQoN Cg0KT24gMTcvMDYvMjAxNSAxNDo0MSwgTWljaGFlbCBCZWhyaW5nZXIgKG1iZWhyaW5nKSB3cm90 ZToNCg0KSSBoYXZlIG5vdyBhbHNvIGNyZWF0ZWQgYSByZXBvc2l0b3J5IGluIGdpdGh1YjogaHR0 cHM6Ly9naXRodWIuY29tL21iZWhyaW5nL0FOSU1BLVJlZmVyZW5jZS1Nb2RlbA0KDQoNCg0KSSBz dWdnZXN0ZWQgaW5pdGlhbCBjb250cmlidXRpb25zLCBhcyBwZXIgYmVsb3cgbGlzdCAob3BlbiB0 byBtb3JlIHN1Z2dlc3Rpb25zIDstKQ0KDQoNCg0KLSBNaWNoYWVsIFJpY2hhcmRzb246IHNlY3Rp b24gMy4zIChjb25zdHJhaW5lZCBub2RlcykNCg0KLSBMaXViaW5nOiA0LjEgYW5kIDQuMiAoTmFt aW5nLCBhZGRyZXNzaW5nKQ0KDQotIEJyaWFuIENhcnBlbnRlcjogNC40IChzaWduYWxpbmcpLiBD b3VsZCB5b3UgYWxzbyBjb3ZlciA0LjUgKGludGVudCBkaXN0cmlidXRpb24pIGFuZCA0LjMgKGRp c2NvdmVyeSk/IC0gdmVyeSByZWxhdGVkISENCg0KLSBKYXNvbiBDb2xlbWFuOiBTZWN0aW9uIDUu MSwgNS4yLCA1LjQsIDUuNSAoUEtJLCBjZXJ0LCBzdWIgYW5kIGNyb3NzLWRvbWFpbikNCg0KLSBK ZWZlcnNvbiBOb2JyZTogNy4xLCA3LjIsIDcuMyAoTWFuYWdlbWVudCwgaW50ZW50LCBhZ2dyZWdh dGVkIHJlcG9ydGluZykNCg0KLSBKb2huIFN0cmFzc25lcjogNy40LCA3LjUsIDcuNiAoZmVlZGJh Y2sgbG9vcHMsIEFQSVMgYW5kIG1vZGVscy4pDQoNCi0gTGF1cmVudCBDaWF2YWdsaWE6IFNlY3Rp b25zIDggYW5kIDkgKGRvIHRoZXkgbmVlZCBhbiB1cGRhdGU/KQ0KDQotIFRvZXJsZXNzIGFuZCBJ IHdpbGwgc2hhcmUgdGhlIHJlbWFpbmluZyBzZWN0aW9ucyBmb3Igbm93Lg0KDQoNCg0KQ2FuIHRo ZSB2b2x1bnRlZXJzIHBsZWFzZSBsZXQgbWUga25vdyBieSB3aGVuIHRoZXkgY2FuIGNvbnRyaWJ1 dGUgdGhlaXIgdGV4dD8gIEVpdGhlciBpbiBnaXRodWIgKGxldCBtZSBrbm93IHlvdXIgSUQgaWYg eW91IHdhbnQgdG8gY29udHJpYnV0ZSB0aGVyZSkNCg0KDQoNCkdpdGh1YiBpcyBub3QgbWFuZGF0 b3J5IC0gSWYgeW91IHdhbnQgdG8gc2VuZCBtZSB5b3VyIHRleHQgdmlhIG1haWwsIHRoYXQncyBv ay4gSSdkIHN0cm9uZ2x5IHByZWZlciBYTUwgZm9ybWF0dGVkIHNlY3Rpb25zIGlmIHBvc3NpYmxl IDstKQ0KDQoNCg0KQ2FuIHdlIGhhdmUgYWxsIHRleHQgaW4gYnkgV2VkIG5leHQgd2Vlaz8NCg0K DQoNCkkgcGxhbiB0byBjb25zb2xpZGF0ZSBhbmQgcHVzaCAtMDMgYnkgZW5kIG9mIG5leHQgd2Vl ay4NCg0KDQoNCk1pY2hhZWwNCg0KLS0NCg0KDQpCaWVuIGNvcmRpYWxlbWVudCwgQmVzdCByZWdh cmRzLA0KDQpMYXVyZW50IENpYXZhZ2xpYQ0KU2VjdXJlIENsb3VkIE5ldHdvcmtpbmcNCkJlbGwg TGFicyB8IEFsY2F0ZWwgTHVjZW50DQoNCnBob25lOiArMzMgMTYwIDQwMiA2MzYNCmVtYWlsOiBs YXVyZW50LmNpYXZhZ2xpYUBhbGNhdGVsLWx1Y2VudC5jb208bWFpbHRvOmxhdXJlbnQuY2lhdmFn bGlhQGFsY2F0ZWwtbHVjZW50LmNvbT4NCmxpbmtlZGluOiBsYXVyZW50Y2lhdmFnbGlhPGh0dHA6 Ly9mci5saW5rZWRpbi5jb20vaW4vbGF1cmVudGNpYXZhZ2xpYS8+DQphZGRyZXNzOiBSb3V0ZSBk ZSBWaWxsZWp1c3QgfCA5MTYyMCBOb3pheSB8IEZyYW5jZQ0KDQotLQ0KDQpCaWVuIGNvcmRpYWxl bWVudCwgQmVzdCByZWdhcmRzLA0KDQpMYXVyZW50IENpYXZhZ2xpYQ0KU2VjdXJlIENsb3VkIE5l dHdvcmtpbmcNCkJlbGwgTGFicyB8IEFsY2F0ZWwgTHVjZW50DQoNCnBob25lOiArMzMgMTYwIDQw MiA2MzYNCmVtYWlsOiBsYXVyZW50LmNpYXZhZ2xpYUBhbGNhdGVsLWx1Y2VudC5jb208bWFpbHRv OmxhdXJlbnQuY2lhdmFnbGlhQGFsY2F0ZWwtbHVjZW50LmNvbT4NCmxpbmtlZGluOiBsYXVyZW50 Y2lhdmFnbGlhPGh0dHA6Ly9mci5saW5rZWRpbi5jb20vaW4vbGF1cmVudGNpYXZhZ2xpYS8+DQph ZGRyZXNzOiBSb3V0ZSBkZSBWaWxsZWp1c3QgfCA5MTYyMCBOb3pheSB8IEZyYW5jZQ0K --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FF82F3xmbrcdx14ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25z b2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OiJUcmVidWNoZXQgTVMiOw0KCXBhbm9zZS0xOjIgMTEgNiAzIDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlRyZWJ1Y2hldCBNUyBcLCBzYW5zLXNlcmlm IjsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbi10 b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbToxMC4wcHQ7DQoJbWFy Z2luLWxlZnQ6MGNtOw0KCWxpbmUtaGVpZ2h0OjExNSU7DQoJZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMzMzMzMzM7DQoJbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBj bTsNCgltYXJnaW4tYm90dG9tOjEwLjBwdDsNCgltYXJnaW4tbGVmdDowY207DQoJbGluZS1oZWln aHQ6MTE1JTsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIs InNlcmlmIjsNCgljb2xvcjojMzMzMzMzOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30N CnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFy Z2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMzMzMzMzOw0KCW1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNv LXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5 OkNvbnNvbGFzOw0KCWNvbG9yOiMzMzMzMzM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6IzFGNDk3RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFs bG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6IzMzMzMzMzsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjU5NS4zcHQgODQxLjlwdDsNCgltYXJnaW46NzAu ODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJF Ti1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2Qi IGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2xpbmUtaGVpZ2h0 OjExNSU7Y29sb3I6IzFGNDk3RCI+QWNrLCB0aGFua3MgZm9yIHRoZSBxdWljayByZXNwb25zZSEN Cjwvc3Bhbj48L2ZvbnQ+PGZvbnQgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IldpbmdkaW5ncyI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj5KPC9zcGFuPjwv Zm9udD48Zm9udCBjb2xvcj0iIzFmNDk3ZCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPg0K PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250 IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtsaW5lLWhlaWdodDoxMTUlO2NvbG9yOiMxRjQ5N0QiPk1pY2hhZWw8bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6 ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2xpbmUtaGVpZ2h0OjExNSU7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdDtsaW5lLWhlaWdodDpub3JtYWwiPg0K PGI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJUYWhvbWEiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLUdCO2ZvbnQtd2VpZ2h0OmJvbGQiPkZyb206PC9zcGFuPjwvZm9udD48L2I+ PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJUYWhvbWEiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLUdCIj4NCiBBbmltYSBbbWFpbHRvOmFuaW1hLWJvdW5jZXNAaWV0Zi5vcmddIDxi PjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5PbiBCZWhhbGYgT2YNCjwvc3Bhbj48L2I+ TGF1cmVudCBDaWF2YWdsaWE8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+ U2VudDo8L3NwYW4+PC9iPiAyOSBKdW5lIDIwMTUgMTE6NDU8YnI+DQo8Yj48c3BhbiBzdHlsZT0i Zm9udC13ZWlnaHQ6Ym9sZCI+VG86PC9zcGFuPjwvYj4gTWljaGFlbCBCZWhyaW5nZXIgKG1iZWhy aW5nKTsgQW5pbWEgV0c8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6 PC9zcGFuPjwvYj4gZHJhZnQtYmVocmluZ2VyLWFuaW1hLXJlZmVyZW5jZS1tb2RlbEB0b29scy5p ZXRmLm9yZzxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0Ojwv c3Bhbj48L2I+IFJlOiBbQW5pbWFdIFJlZmVyZW5jZSBkb2Mgb24gZ2l0aHViPG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Zm9udCBzaXplPSIyIiBjb2xvcj0iIzMzMzMzMyIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7bGluZS1oZWlnaHQ6MTE1JSI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMzMzMzMzMiIGZhY2U9IkNvdXJpZXIgTmV3 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtsaW5lLWhlaWdodDoxMTUlO2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5EZWFyIE1pY2hh ZWwsPGJyPg0KPGJyPg0KSSB0aGluayB0aGF0IGluIEFOSU1BIHdlIHNob3VsZCBldmVudHVhbGx5 IGRvY3VtZW50ICZxdW90O2ludGVyYWN0aW9ucyZxdW90OyB3aXRoIG5vbi1hdXRvbm9taWMgbmV0 d29ya3MuPGJyPg0KPGJyPg0KSXQgaXMgZmluZSBmb3IgbWUgdG8gbm90IGhhdmUgYSBzZWN0aW9u IGluIHRoZSByZWZlcmVuY2UgZG9jdW1lbnQgZm9yIHRoZSBtb21lbnQsIGFzIHRoaXMgdG9waWMg aXMgc3RpbGwgbGFyZ2VseSB1bmRlZmluZWQuIFNvIG9rIHRvIGRyb3AgdGhlIHNlY3Rpb24gaW4g dGhlIG5leHQgdmVyc2lvbiwga25vd2luZyB0aGF0IGluIGZ1cmh0ZXIgcmV2aXNpb24gaXQgbWln aHQgYmUgaW50ZWdyYXRlZCBhZ2FpbiAocHJvYmFibHkgdW5kZXIgYSBkaWZmZXJlbnQNCiBuYW1l KS48YnI+DQo8YnI+DQpUaGFua3MsIGJlc3QgcmVnYXJkcywgTGF1cmVudC48YnI+DQo8YnI+DQo8 L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxmb250IHNp emU9IjIiIGNvbG9yPSIjMzMzMzMzIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtsaW5lLWhlaWdodDoxMTUlIj5PbiAyOS8wNi8yMDE1IDExOjM5LCBNaWNoYWVs IEJlaHJpbmdlciAobWJlaHJpbmcpIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMx ZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2xpbmUt aGVpZ2h0OjExNSU7Y29sb3I6IzFGNDk3RCI+SGkgTGF1cmVudCwNCjwvc3Bhbj48L2ZvbnQ+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0i IzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7bGlu ZS1oZWlnaHQ6MTE1JTtjb2xvcjojMUY0OTdEIj5SZWdhcmRpbmcgc2VjdGlvbiA4OiBBZ3JlZSwg bm8gY2hhbmdlcyBuZWVkZWQgZm9yIG5vdywgYnV0IGZlZWRiYWNrIGZyb20gdGhlIGNvbW11bml0 eS4NCjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7bGluZS1oZWlnaHQ6MTE1JTtjb2xvcjojMUY0OTdEIj5SZWdhcmRp bmcgc2VjdGlvbiA5OiBJIHJlLXJlYWQgYm90aCwgdGhpcyBzZWN0aW9uIGFuZCBzZWN0aW9uIDMu Mi4gb2YgUkZDNzU3NS4gTXkgcGVyc29uYWwgb3BpbmlvbiBpcyB0aGF0IHRoaXMgc2VjdGlvbiBp cyBub3QgbmVlZGVkDQogaW4gdGhlIHJlZmVyZW5jZSBkb2N1bWVudCwgYW5kIEkgc3VnZ2VzdCB0 aGVyZWZvcmUgdG8gZHJvcCBpdC4gPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxp YnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtsaW5lLWhlaWdodDoxMTUlO2NvbG9y OiMxRjQ5N0QiPkxldOKAmXMga2VlcCB0aGUgZG9jdW1lbnQgYXMgY29uY2lzZSBhcyBwb3NzaWJs ZS4NCjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7bGluZS1oZWlnaHQ6MTE1JTtjb2xvcjojMUY0OTdEIj5NaWNoYWVs PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdDtsaW5lLWhlaWdodDpu b3JtYWwiPg0KPGI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJUYWhvbWEiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0O21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCO2ZvbnQtd2VpZ2h0OmJvbGQiPkZyb206PC9zcGFuPjwv Zm9udD48L2I+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJUYWhvbWEiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0O21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLUdCIj4NCiBMYXVyZW50IENpYXZhZ2xpYSBbPGEgaHJlZj0ibWFp bHRvOkxhdXJlbnQuQ2lhdmFnbGlhQGFsY2F0ZWwtbHVjZW50LmNvbSI+bWFpbHRvOkxhdXJlbnQu Q2lhdmFnbGlhQGFsY2F0ZWwtbHVjZW50LmNvbTwvYT5dDQo8YnI+DQo8Yj48c3BhbiBzdHlsZT0i Zm9udC13ZWlnaHQ6Ym9sZCI+U2VudDo8L3NwYW4+PC9iPiAxOSBKdW5lIDIwMTUgMTM6MTE8YnI+ DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86PC9zcGFuPjwvYj4gTWljaGFl bCBCZWhyaW5nZXIgKG1iZWhyaW5nKTsgQW5pbWEgV0c8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9u dC13ZWlnaHQ6Ym9sZCI+Q2M6PC9zcGFuPjwvYj4gPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWJlaHJp bmdlci1hbmltYS1yZWZlcmVuY2UtbW9kZWxAdG9vbHMuaWV0Zi5vcmciPg0KZHJhZnQtYmVocmlu Z2VyLWFuaW1hLXJlZmVyZW5jZS1tb2RlbEB0b29scy5pZXRmLm9yZzwvYT48YnI+DQo8Yj48c3Bh biBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDo8L3NwYW4+PC9iPiBSZTogUmVmZXJl bmNlIGRvYyBvbiBnaXRodWI8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMzMzMzMz IiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtsaW5lLWhlaWdo dDoxMTUlIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Zm9udCBzaXplPSIyIiBjb2xv cj0iIzMzMzMzMyIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2xpbmUtaGVpZ2h0OjExNSU7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPkRlYXIgTWljaGFlbCwgYWxsLDxicj4NCjxicj4NClNlY3Rpb24g OCBpcyBuZXcsIHNvIEkgZG9uJ3QgdGhpbmsgaXQgbmVlZHMgYW4gdXBhdGUgZm9yIC0wMywgYnV0 IEkgd291bGQgYmUgaGFwcHkgdG8gbWFrZSBjaGFuZ2VzIGJhc2VkIG9uIGZlZWRiYWNrL2NvbW1l bnRzLjxicj4NCjxicj4NCkZvciBTZWN0aW9uIDk6IElzIHRoZSBjdXJyZW50IHRleHQgcmVmZXJy aW5nIHRvIFJGQzc1NzUsIFNlY3Rpb24gMy4yLiBDb2V4aXN0ZW5jZSB3aXRoIFRyYWRpdGlvbmFs IE1hbmFnZW1lbnQ/PGJyPg0KSWYgeWVzLCB0aGVuIEkgd291bGQgc3VnZ2VzdCByZW5hbWluZyBT ZWN0aW9uIDkgdG8gcmVmbGVjdCB0aGUgYWN0dWFsIGNvbnRlbnQgd2hpY2ggZm9jdXNlcyBvbiAm cXVvdDttYW5hZ2VtZW50IG9yIG9wZXJhdGlvbiBtb2RlJnF1b3Q7IHByaW9yaXRpemF0aW9uLjxi cj4NCklmIGFncmVlZC9jb3JyZWN0LCBJIGNhbiB1cGRhdGUgdGhlIHRleHQgZm9yIFNlY3Rpb24g OSBieSBuZXh0IFdlZG5lc2RheS48YnI+DQo8YnI+DQpUaG91Z2gsIHRoZSB0b3BpYyBvZiAmcXVv dDtoeWJyaWQmcXVvdDsgb3BlcmF0aW9ucyAoYXV0b25vbWljIGFuZCBub24tYXV0b25vbWljKSBp cyBzdGlsbCByZWxldmFudCwgYnV0IHNsaWdodGx5IGRpZmZlcmVudCBmcm9tIHByaW9yaXRpemF0 aW9uLiBTb21lIG9uZ29pbmcgZGlzY3Vzc2lvbnMgb24gdGhlIEFOSU1BIG1haWxpbmcgbGlzdCBv biBkb21haW4sIGludGVudCwgYW5kIGNvbnN0cmFpbmVkIG5vZGVzIHBhcnRpY2lwYXRlIGluIHRo aXMgdG9waWMuPGJyPg0KQSB0ZXh0IG9uIHRoaXMgaW4gLTAzIGlzIHRvbyBhbWJpdGlvdXMsIGJ1 dCB3ZSBjYW4gdHJpZ2dlciBhIGRpc2N1c3Npb24gdGhyZWFkIHRvIGNhcHR1cmUgdGhlIG9wZXJh dGluZyBwcmluY2lwbGVzIEFOSU1BIGFpbXMgYXQgY29uY2VybmluZyB0aGlzIGh5YnJpZCBtb2Rl IG9mIG9wZXJhdGlvbiAoaS5lLiBob3cgQUZzIGFuZCBub24tQUZzIGNvLW9wZXJhdGUsIGFyZSBt YW5hZ2VkL2dvdmVybmVkIGJ5IEludGVudC9vdGhlciBtZWFucywgcm9sZQ0KIG9mICZxdW90O2hl bHBpbmcmcXVvdDsgbm9kZXMvZnVuY3Rpb25zL2dhdGV3YXlzLi4uKTxicj4NCjxicj4NCkJlc3Qg cmVnYXJkcywgTGF1cmVudC48YnI+DQo8YnI+DQo8YnI+DQo8L3NwYW4+PC9mb250PjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMzMzMzMz IiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtsaW5lLWhlaWdo dDoxMTUlIj5PbiAxNy8wNi8yMDE1IDE0OjQxLCBNaWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcp IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48Zm9u dCBzaXplPSIyIiBjb2xvcj0iIzMzMzMzMyIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2xpbmUtaGVpZ2h0OjExNSUiPkkgaGF2ZSBub3cgYWxzbyBjcmVh dGVkIGEgcmVwb3NpdG9yeSBpbiBnaXRodWI6IDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9t YmVocmluZy9BTklNQS1SZWZlcmVuY2UtTW9kZWwiPmh0dHBzOi8vZ2l0aHViLmNvbS9tYmVocmlu Zy9BTklNQS1SZWZlcmVuY2UtTW9kZWw8L2E+PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJl Pg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzMzMzMzMyIgZmFjZT0iQ291cmllciBOZXci PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2xpbmUtaGVpZ2h0OjExNSUiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9 IiMzMzMzMzMiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtsaW5lLWhlaWdodDoxMTUlIj5JIHN1Z2dlc3RlZCBpbml0aWFsIGNvbnRyaWJ1dGlvbnMsIGFz IHBlciBiZWxvdyBsaXN0IChvcGVuIHRvIG1vcmUgc3VnZ2VzdGlvbnMgOy0pIDxvOnA+PC9vOnA+ PC9zcGFuPjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMzMzMzMzMi IGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtsaW5lLWhl aWdodDoxMTUlIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxm b250IHNpemU9IjIiIGNvbG9yPSIjMzMzMzMzIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bGluZS1oZWlnaHQ6MTE1JSI+LSBNaWNoYWVsIFJpY2hhcmRz b246IHNlY3Rpb24gMy4zIChjb25zdHJhaW5lZCBub2Rlcyk8bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wcmU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMzMzMzMzIiBmYWNlPSJDb3Vy aWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bGluZS1oZWlnaHQ6MTE1JSI+ LSBMaXViaW5nOiA0LjEgYW5kIDQuMiAoTmFtaW5nLCBhZGRyZXNzaW5nKTxvOnA+PC9vOnA+PC9z cGFuPjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMzMzMzMzMiIGZh Y2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtsaW5lLWhlaWdo dDoxMTUlIj4tIEJyaWFuIENhcnBlbnRlcjogNC40IChzaWduYWxpbmcpLiBDb3VsZCB5b3UgYWxz byBjb3ZlciA0LjUgKGludGVudCBkaXN0cmlidXRpb24pIGFuZCA0LjMgKGRpc2NvdmVyeSk/IC0g dmVyeSByZWxhdGVkISE8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250 IHNpemU9IjIiIGNvbG9yPSIjMzMzMzMzIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7bGluZS1oZWlnaHQ6MTE1JSI+LSBKYXNvbiBDb2xlbWFuOiBTZWN0 aW9uIDUuMSwgNS4yLCA1LjQsIDUuNSAoUEtJLCBjZXJ0LCBzdWIgYW5kIGNyb3NzLWRvbWFpbik8 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9y PSIjMzMzMzMzIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7bGluZS1oZWlnaHQ6MTE1JSI+LSBKZWZlcnNvbiBOb2JyZTogNy4xLCA3LjIsIDcuMyAoTWFu YWdlbWVudCwgaW50ZW50LCBhZ2dyZWdhdGVkIHJlcG9ydGluZyk8bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMzMzMzMzIiBmYWNlPSJD b3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bGluZS1oZWlnaHQ6MTE1 JSI+LSBKb2huIFN0cmFzc25lcjogNy40LCA3LjUsIDcuNiAoZmVlZGJhY2sgbG9vcHMsIEFQSVMg YW5kIG1vZGVscy4pPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBz aXplPSIyIiBjb2xvcj0iIzMzMzMzMyIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2xpbmUtaGVpZ2h0OjExNSUiPi0gTGF1cmVudCBDaWF2YWdsaWE6IFNl Y3Rpb25zIDggYW5kIDkgKGRvIHRoZXkgbmVlZCBhbiB1cGRhdGU/KTxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMzMzMzMzMiIGZhY2U9 IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtsaW5lLWhlaWdodDox MTUlIj4tIFRvZXJsZXNzIGFuZCBJIHdpbGwgc2hhcmUgdGhlIHJlbWFpbmluZyBzZWN0aW9ucyBm b3Igbm93LjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0i MiIgY29sb3I9IiMzMzMzMzMiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtsaW5lLWhlaWdodDoxMTUlIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wcmU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMzMzMzMzIiBmYWNlPSJDb3Vy aWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bGluZS1oZWlnaHQ6MTE1JSI+ Q2FuIHRoZSB2b2x1bnRlZXJzIHBsZWFzZSBsZXQgbWUga25vdyBieSB3aGVuIHRoZXkgY2FuIGNv bnRyaWJ1dGUgdGhlaXIgdGV4dD8mbmJzcDsgRWl0aGVyIGluIGdpdGh1YiAobGV0IG1lIGtub3cg eW91ciBJRCBpZiB5b3Ugd2FudCB0byBjb250cmlidXRlIHRoZXJlKSA8bzpwPjwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMzMzMzMzIiBmYWNl PSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bGluZS1oZWlnaHQ6 MTE1JSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBz aXplPSIyIiBjb2xvcj0iIzMzMzMzMyIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2xpbmUtaGVpZ2h0OjExNSUiPkdpdGh1YiBpcyBub3QgbWFuZGF0b3J5 IC0gSWYgeW91IHdhbnQgdG8gc2VuZCBtZSB5b3VyIHRleHQgdmlhIG1haWwsIHRoYXQncyBvay4g SSdkIHN0cm9uZ2x5IHByZWZlciBYTUwgZm9ybWF0dGVkIHNlY3Rpb25zIGlmIHBvc3NpYmxlIDst KSA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNv bG9yPSIjMzMzMzMzIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7bGluZS1oZWlnaHQ6MTE1JSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzMzMzMzMyIgZmFjZT0iQ291cmllciBO ZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2xpbmUtaGVpZ2h0OjExNSUiPkNhbiB3 ZSBoYXZlIGFsbCB0ZXh0IGluIGJ5IFdlZCBuZXh0IHdlZWs/IDxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMzMzMzMzMiIGZhY2U9IkNv dXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtsaW5lLWhlaWdodDoxMTUl Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250IHNpemU9 IjIiIGNvbG9yPSIjMzMzMzMzIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7bGluZS1oZWlnaHQ6MTE1JSI+SSBwbGFuIHRvIGNvbnNvbGlkYXRlIGFuZCBw dXNoIC0wMyBieSBlbmQgb2YgbmV4dCB3ZWVrLiA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w cmU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMzMzMzMzIiBmYWNlPSJDb3VyaWVyIE5l dyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bGluZS1oZWlnaHQ6MTE1JSI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xv cj0iIzMzMzMzMyIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2xpbmUtaGVpZ2h0OjExNSUiPk1pY2hhZWw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w cmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBj b2xvcj0iIzMzMzMzMyIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7bGluZS1oZWlnaHQ6MTE1JSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTowY207bWFy Z2luLWJvdHRvbTouMDAwMXB0O2xpbmUtaGVpZ2h0Om5vcm1hbCI+DQo8Zm9udCBzaXplPSIyIiBj b2xvcj0iIzMzMzMzMyIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPi0tIDxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTowY207bWFyZ2luLWJvdHRv bTouMDAwMXB0O2xpbmUtaGVpZ2h0Om5vcm1hbCI+DQo8Zm9udCBzaXplPSIyIiBjb2xvcj0iIzMz MzMzMyIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkJpZW4g Y29yZGlhbGVtZW50LCBCZXN0IHJlZ2FyZHMsPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjBjbTttYXJnaW4tYm90 dG9tOi4wMDAxcHQ7bGluZS1oZWlnaHQ6bm9ybWFsIj4NCjxmb250IHNpemU9IjIiIGNvbG9yPSIj MzMzMzMzIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5i c3A7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQ7bGluZS1oZWlnaHQ6 bm9ybWFsIj4NCjxiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMzMzMzMzIiBmYWNlPSJDYWxpYnJp Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LXdlaWdodDpib2xkIj5MYXVyZW50 IENpYXZhZ2xpYTwvc3Bhbj48L2ZvbnQ+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdDts aW5lLWhlaWdodDpub3JtYWwiPg0KPGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMzMzMzMzMiIGZhY2U9 IlRyZWJ1Y2hldCBNUyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlNlY3VyZSBD bG91ZCBOZXR3b3JraW5nPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQ7 bGluZS1oZWlnaHQ6bm9ybWFsIj4NCjxmb250IHNpemU9IjIiIGNvbG9yPSIjMzMzMzMzIiBmYWNl PSJUcmVidWNoZXQgTVMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5CZWxsIExh YnMgfCBBbGNhdGVsIEx1Y2VudDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTowY207bWFyZ2luLWJvdHRvbTouMDAw MXB0O2xpbmUtaGVpZ2h0Om5vcm1hbCI+DQo8Zm9udCBzaXplPSIyIiBjb2xvcj0iIzMzMzMzMyIg ZmFjZT0iVHJlYnVjaGV0IE1TIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5i c3A7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQ7bGluZS1oZWlnaHQ6 bm9ybWFsIj4NCjxmb250IHNpemU9IjIiIGNvbG9yPSIjMzMzMzMzIiBmYWNlPSJDYWxpYnJpIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+cGhvbmU6ICYjNDM7MzMmbmJzcDsxNjAgNDAy Jm5ic3A7NjM2DQo8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdDtsaW5l LWhlaWdodDpub3JtYWwiPg0KPGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMzMzMzMzMiIGZhY2U9IkNh bGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5lbWFpbDoNCjwvc3Bhbj48L2Zv bnQ+PGEgaHJlZj0ibWFpbHRvOmxhdXJlbnQuY2lhdmFnbGlhQGFsY2F0ZWwtbHVjZW50LmNvbSI+ PGZvbnQgc2l6ZT0iMiI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5s YXVyZW50LmNpYXZhZ2xpYUBhbGNhdGVsLWx1Y2VudC5jb208L3NwYW4+PC9mb250PjwvYT48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjBj bTttYXJnaW4tYm90dG9tOi4wMDAxcHQ7bGluZS1oZWlnaHQ6bm9ybWFsIj4NCjxmb250IHNpemU9 IjIiIGNvbG9yPSIjMzMzMzMzIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdCI+bGlua2VkaW46DQo8L3NwYW4+PC9mb250PjxhIGhyZWY9Imh0dHA6Ly9mci5saW5r ZWRpbi5jb20vaW4vbGF1cmVudGNpYXZhZ2xpYS8iPjxmb250IHNpemU9IjIiPjxzcGFuIGxhbmc9 IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+bGF1cmVudGNpYXZhZ2xpYTwvc3Bhbj48L2Zv bnQ+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdDtsaW5lLWhlaWdodDpub3JtYWwiPg0K PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMzMzMzMzMiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0Ij5hZGRyZXNzOiBSb3V0ZSBkZSBWaWxsZWp1c3QgfCA5MTYyMCBO b3pheSB8IEZyYW5jZTwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdDtsaW5lLWhlaWdodDpub3JtYWwiPg0KPGZvbnQg c2l6ZT0iMyIgY29sb3I9IiMzMzMzMzMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQ7bGluZS1oZWln aHQ6bm9ybWFsIj4NCjxmb250IHNpemU9IjMiIGNvbG9yPSIjMzMzMzMzIiBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1HQiI+LS0NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTowY207bWFyZ2luLWJv dHRvbTouMDAwMXB0O2xpbmUtaGVpZ2h0Om5vcm1hbCI+DQo8Zm9udCBzaXplPSIyIiBjb2xvcj0i IzMzMzMzMyIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkJp ZW4gY29yZGlhbGVtZW50LCBCZXN0IHJlZ2FyZHMsPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjBjbTttYXJnaW4t Ym90dG9tOi4wMDAxcHQ7bGluZS1oZWlnaHQ6bm9ybWFsIj4NCjxmb250IHNpemU9IjIiIGNvbG9y PSIjMzMzMzMzIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQ7bGluZS1oZWln aHQ6bm9ybWFsIj4NCjxiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMzMzMzMzIiBmYWNlPSJDYWxp YnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LXdlaWdodDpib2xkIj5MYXVy ZW50IENpYXZhZ2xpYTwvc3Bhbj48L2ZvbnQ+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MGNtO21hcmdpbi1ib3R0b206LjAwMDFw dDtsaW5lLWhlaWdodDpub3JtYWwiPg0KPGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMzMzMzMzMiIGZh Y2U9IlRyZWJ1Y2hldCBNUyAsIHNhbnMtc2VyaWYiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyAsIHNhbnMtc2VyaWYmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPlNlY3VyZSBDbG91ZCBOZXR3b3JraW5nPC9zcGFuPjwvZm9udD48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjBj bTttYXJnaW4tYm90dG9tOi4wMDAxcHQ7bGluZS1oZWlnaHQ6bm9ybWFsIj4NCjxmb250IHNpemU9 IjIiIGNvbG9yPSIjMzMzMzMzIiBmYWNlPSJUcmVidWNoZXQgTVMgLCBzYW5zLXNlcmlmIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMg LCBzYW5zLXNlcmlmJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5CZWxsIExhYnMgfCBBbGNhdGVs IEx1Y2VudDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbTowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0O2xpbmUtaGVp Z2h0Om5vcm1hbCI+DQo8Zm9udCBzaXplPSIyIiBjb2xvcj0iIzMzMzMzMyIgZmFjZT0iVHJlYnVj aGV0IE1TICwgc2Fucy1zZXJpZiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TICwgc2Fucy1zZXJpZiZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQ7bGlu ZS1oZWlnaHQ6bm9ybWFsIj4NCjxmb250IHNpemU9IjIiIGNvbG9yPSIjMzMzMzMzIiBmYWNlPSJD YWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+cGhvbmU6ICYjNDM7MzMmbmJz cDsxNjAgNDAyJm5ic3A7NjM2DQo8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MGNtO21hcmdpbi1ib3R0b206LjAw MDFwdDtsaW5lLWhlaWdodDpub3JtYWwiPg0KPGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMzMzMzMzMi IGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5lbWFpbDoNCjwv c3Bhbj48L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOmxhdXJlbnQuY2lhdmFnbGlhQGFsY2F0ZWwtbHVj ZW50LmNvbSI+PGZvbnQgc2l6ZT0iMiI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij5sYXVyZW50LmNpYXZhZ2xpYUBhbGNhdGVsLWx1Y2VudC5jb208L3NwYW4+PC9mb250 PjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQ7bGluZS1oZWlnaHQ6bm9ybWFsIj4NCjxm b250IHNpemU9IjIiIGNvbG9yPSIjMzMzMzMzIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdCI+bGlua2VkaW46DQo8L3NwYW4+PC9mb250PjxhIGhyZWY9Imh0dHA6 Ly9mci5saW5rZWRpbi5jb20vaW4vbGF1cmVudGNpYXZhZ2xpYS8iPjxmb250IHNpemU9IjIiPjxz cGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+bGF1cmVudGNpYXZhZ2xpYTwv c3Bhbj48L2ZvbnQ+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdDtsaW5lLWhlaWdodDpu b3JtYWwiPg0KPGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMzMzMzMzMiIGZhY2U9IkNhbGlicmkiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5hZGRyZXNzOiBSb3V0ZSBkZSBWaWxsZWp1c3Qg fCA5MTYyMCBOb3pheSB8IEZyYW5jZTwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22FF82F3xmbrcdx14ciscoc_-- From nobody Mon Jun 29 02:58:49 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC931A8974 for ; Mon, 29 Jun 2015 02:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbPgK8xNNXs8 for ; Mon, 29 Jun 2015 02:58:45 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 D83F51A896F for ; Mon, 29 Jun 2015 02:58:44 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id EC009BD48853E; Mon, 29 Jun 2015 09:58:41 +0000 (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 t5T9wdnD003016 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Jun 2015 11:58:39 +0200 Received: from [172.27.204.50] (135.239.27.38) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 29 Jun 2015 11:58:39 +0200 Message-ID: <559116CE.5000107@alcatel-lucent.com> Date: Mon, 29 Jun 2015 11:58:38 +0200 From: Laurent Ciavaglia Organization: Alcatel-Lucent Bell Labs France User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , "Liubing (Leo)" , Brian E Carpenter , "anima@ietf.org" References: <8AE0F17B87264D4CAC7DE0AA6C406F45A6799F26@nkgeml506-mbx.china.huawei.com> <558DFE45.4050906@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C21D1AD8@nkgeml506-mbx.china.huawei.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF7FCF@xmb-rcd-x14.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C21D4B31@nkgeml506-mbx.china.huawei.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF818A@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF818A@xmb-rcd-x14.cisco.com> Content-Type: multipart/alternative; boundary="------------020903020700000104020502" X-Originating-IP: [135.239.27.38] Archived-At: Subject: Re: [Anima] Naming discussion (Section 4.1 of the Reference-Model draft) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jun 2015 09:58:48 -0000 --------------020903020700000104020502 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Hello, 1) Which elements require identification? . AF, ASA, AN, something else? For me, the only base element in ANIMA that would need an new identifier is the AF. And a clear relationship map among the AF, ASA, AN, etc. should be defined/available at deployment-/run-time (cf coupling / deployment models discussion). 2) What's the visibility of the identifier? . Should all identifiers be discoverable, advertisable, maintained consistently (where/how)? For me, the AF is the (only) logical point of interaction, and thus should be domain-wide visible. The AF provides the redirection mechanism to its ASAs, i.e. if an entity needs to talk directly to an ASA, it should have first interacted with the corresponding AF. In some cases, the communication between entity-x and ASA could be made direct / optimized (such as in the knowledge/information plane flows). 3) An identifier to do what / for what purpose? . Should the identifier be used for bootstrapping, routing, signaling, AF-to-AF communication? . A unique identifier is certainly necessary for monitoring, forensic... . Should the identifier be "human-friendly"? I don't think it should, but we can certainly devise some mechanisms to make identifier / group of identifiers (e.g. by roles) appear in an elegant/intelligible manner to a (human-)user interface. Please note that if we consider systems with thousands of elements the human-friendliness of information representation goes well-beyond (actually against) having human-friendly identifiers. 4) Do we consider that the elements we want to identify have a unique identifier or multiple ones? Are the identifier summarizable (reached as a group, reached as a role?) 5) On Leo's initial proposition: the naming structure makes me think more of the notion of a descriptor attached to the autonomic element, describing various aspects of it. The identifier being one. Many other information could be present in such a descriptor (will post specifically on that later). What do you think? Best regards, Laurent. On 29/06/2015 10:49, Michael Behringer (mbehring) wrote: >> -----Original Message----- >> From: Liubing (Leo) [mailto:leo.liubing@huawei.com] >> Sent: 29 June 2015 10:31 >> To: Michael Behringer (mbehring); Brian E Carpenter; anima@ietf.org >> Subject: RE: [Anima] Naming discussion (Section 4.1 of the Reference-Model >> draft) >> >> Hi Michael and all, >> >> Regarding to "human", I think there are two aspects: >> 1. Human get involved in generating names. I guess it's what you meant by >> "human consumption". >> 2. The names are generated by the devices automatically and also human >> readable. So that it might be easier for the administrators, e.g. when they're >> analyzing/debugging a network issue. >> >> For no.1, I also agree human should not participate in the name generation >> procedure (except the special cases you discussed below). >> For no.2, of course it needs a more complex algorithm/molding than only >> ensuring the uniqueness. My proposed text was trying to discuss the >> possibility a bit in this direction. >> But from the AN management requirement perspective, do you think no.2 >> make sense? >> >> Best regards, >> Bing > Bing, > Let me be more verbose in my proposal: > > - case 1: Admin provides UDI to name mapping, then that name is used. > (we don't care what's inside the name) > I suggest that in this case we treat the name as opaque, i.e., ANIMA > doesn't care how it's made. > I think case 1 is relatively easy to agree on. Right? > > - case 2: name is created autonomically, using algorithm x > Here, I suggest that we don't even try to do something "intelligent". > > Reasoning: What can we figure out automatically, really? Well, device type, vendor can be derived from some h/w information. What else? > topology - NOT! (not one that's useful to an admin). Frankly I think it is impossible to come up with an automated naming scheme that is 1) completely automatic and 2) admins will be happy with. Let's not even try ;-) > > BTW, I suggest we put UDI info into a field of the certificate, so that it's available when needed, but not onto the name. So in the cert, you do find info on, e.g., device type if needed. > > BTW, I think I never mentioned this explicitly, but I think the "autonomic name" we're talking about here should NOT be the hostname of the device. Again, this is to keep traditionally maintained config and autonomic information as clearly separated as possible. > > Michael > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > > -- Bien cordialement, Best regards, *Laurent Ciavaglia* Secure Cloud Networking Bell Labs | Alcatel Lucent phone: +33 160 402 636 email: laurent.ciavaglia@alcatel-lucent.com linkedin: laurentciavaglia address: Route de Villejust | 91620 Nozay | France --------------020903020700000104020502 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit Hello,

1) Which elements require identification?
    . AF, ASA, AN, something else?
    For me, the only base element in ANIMA that would need an new identifier is the AF.
    And a clear relationship map among the AF, ASA, AN, etc. should be defined/available at deployment-/run-time (cf coupling / deployment models discussion).

2) What's the visibility of the identifier?
    . Should all identifiers be discoverable, advertisable, maintained consistently (where/how)?
    For me, the AF is the (only) logical point of interaction, and thus should be domain-wide visible.
    The AF provides the redirection mechanism to its ASAs, i.e. if an entity needs to talk directly to an ASA, it should have first interacted with the corresponding AF. In some cases, the communication between entity-x and ASA could be made direct / optimized (such as in the knowledge/information plane flows).

3) An identifier to do what / for what purpose?
    . Should the identifier be used for bootstrapping, routing, signaling, AF-to-AF communication?
    . A unique identifier is certainly necessary for monitoring, forensic...
    . Should the identifier be "human-friendly"? I don't think it should, but we can certainly devise some mechanisms to make identifier / group of identifiers (e.g. by roles) appear in an elegant/intelligible manner to a (human-)user interface. Please note that if we consider systems with thousands of elements the human-friendliness of information representation goes well-beyond (actually against) having human-friendly identifiers.

4) Do we consider that the elements we want to identify have a unique identifier or multiple ones? Are the identifier summarizable (reached as a group, reached as a role?)

5) On Leo's initial proposition: the naming structure makes me think more of the notion of a descriptor attached to the autonomic element, describing various aspects of it. The identifier being one. Many other information could be present in such a descriptor (will post specifically on that later).

What do you think?

Best regards, Laurent.




On 29/06/2015 10:49, Michael Behringer (mbehring) wrote:
-----Original Message-----
From: Liubing (Leo) [mailto:leo.liubing@huawei.com]
Sent: 29 June 2015 10:31
To: Michael Behringer (mbehring); Brian E Carpenter; anima@ietf.org
Subject: RE: [Anima] Naming discussion (Section 4.1 of the Reference-Model
draft)

Hi Michael and all,

Regarding to "human", I think there are two aspects:
1. Human get involved in generating names. I guess it's what you meant by
"human consumption".
2. The names are generated by the devices automatically and also human
readable. So that it might be easier for the administrators, e.g. when they're
analyzing/debugging a network issue.

For no.1, I also agree human should not participate in the name generation
procedure (except the special cases you discussed below).
For no.2, of course it needs a more complex algorithm/molding than only
ensuring the uniqueness. My proposed text was trying to discuss the
possibility a bit in this direction.
But from the AN management requirement perspective, do you think no.2
make sense?

Best regards,
Bing

Bing, 
Let me be more verbose in my proposal: 

- case 1: Admin provides UDI to name mapping, then that name is used. 
  (we don't care what's inside the name)
  I suggest that in this case we treat the name as opaque, i.e., ANIMA 
  doesn't care how it's made. 
  I think case 1 is relatively easy to agree on. Right?

- case 2: name is created autonomically, using algorithm x
  Here, I suggest that we don't even try to do something "intelligent". 

Reasoning: What can we figure out automatically, really? Well, device type, vendor can be derived from some h/w information. What else? 
topology - NOT! (not one that's useful to an admin). Frankly I think it is impossible to come up with an automated naming scheme that is 1) completely automatic and 2) admins will be happy with. Let's not even try ;-) 

BTW, I suggest we put UDI info into a field of the certificate, so that it's available when needed, but not onto the name. So in the cert, you do find info on, e.g.,  device type if needed. 

BTW, I think I never mentioned this explicitly, but I think the "autonomic name" we're talking about here should NOT be the hostname of the device. Again, this is to keep traditionally maintained config and autonomic information as clearly separated as possible.

Michael

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

--

Bien cordialement, Best regards,

 

Laurent Ciavaglia

Secure Cloud Networking

Bell Labs | Alcatel Lucent

 

phone: +33 160 402 636

email: laurent.ciavaglia@alcatel-lucent.com

linkedin: laurentciavaglia

address: Route de Villejust | 91620 Nozay | France

--------------020903020700000104020502-- From nobody Mon Jun 29 03:08:50 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09B71A89AB for ; Mon, 29 Jun 2015 03:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2ufdhhZmguB for ; Mon, 29 Jun 2015 03:08:45 -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 79F061A89A0 for ; Mon, 29 Jun 2015 03:08:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUM56892; Mon, 29 Jun 2015 10:08:42 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 29 Jun 2015 11:08:40 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.135]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Mon, 29 Jun 2015 18:08:37 +0800 From: "Liubing (Leo)" To: John Strassner Thread-Topic: [Anima] Naming discussion (Section 4.1 of the Reference-Model draft) Thread-Index: AdCv+rXE5dOVpQhdRKmevUBqnlbbhAA+iMOAAFGQFnA= Date: Mon, 29 Jun 2015 10:08:36 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C21D5BFD@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F45A6799F26@nkgeml506-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.117] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F45C21D5BFDnkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Anima WG Subject: Re: [Anima] Naming discussion (Section 4.1 of the Reference-Model draft) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jun 2015 10:08:49 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F45C21D5BFDnkgeml506mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9obiwNCg0KVGhhbmtzIGZvciB5b3VyIGVsYWJvcmF0ZSByZXZpZXcgYW5kIGNvbW1lbnRz LCBwbGVhc2Ugc2VlIHJlcGxpZXMgaW5saW5lLg0KDQpGcm9tOiBKb2huIFN0cmFzc25lciBbbWFp bHRvOnN0cmF6cGRqQGdtYWlsLmNvbV0NClNlbnQ6IFN1bmRheSwgSnVuZSAyOCwgMjAxNSA4OjE4 IEFNDQpUbzogTGl1YmluZyAoTGVvKQ0KQ2M6IEFuaW1hIFdHDQpTdWJqZWN0OiBSZTogW0FuaW1h XSBOYW1pbmcgZGlzY3Vzc2lvbiAoU2VjdGlvbiA0LjEgb2YgdGhlIFJlZmVyZW5jZS1Nb2RlbCBk cmFmdCkNCg0KRGVhciBMZW8sDQoNCnBsZWFzZSBzZWUgaW5saW5lLCBsb29rIGZvciA8amNzPi4u PC9qY3M+DQoNCnJlZ2FyZHMsDQpKb2huDQoNCg0KNC4xLiAgTmFtaW5nDQoNCjQuMS4xLiAgTmFt aW5nIHJlcXVpcmVtZW50cw0KDQogICBvICBSZXByZXNlbnRpbmcgZWFjaCBkZXZpY2UNCiAgICAg ICAgIEluc2lkZSBhIGRvbWFpbiwgZWFjaCBhdXRvbm9taWMgZGV2aWNlIG5lZWRzIGEgZG9tYWlu IHNwZWNpZmljDQogICAgICAgICBpZGVudGlmaWVyLg0KICAgICAgICAgW09wZW4gUXVlc3Rpb25z XSBBcmUgdGhlcmUgZGV2aWNlcyB0aGF0IGRvbid0IG5lZWQgbmFtZXM/ICBEbw0KICAgICAgICAg QVNBcyBuZWVkIG5hbWVzPw0KPGpjcz4NCkkgdGhpbmsgdGhhdCBlYWNoICoqZW50aXR5KiogdGhh dCBjYW4gcG90ZW50aWFsbHkgaW50ZXJhY3Qgd2l0aCBvdGhlciBlbnRpdGllcw0KTVVTVCBIQVZF IGEgbmFtZS4gSSB0aGluayBvZiBBU0FzIGFzIG1hbmFnZWQgZW50aXRpZXMsIHNvIHllcywNCnRo ZXkgZG8gYXMgd2VsbC4NCjwvamNzPg0KW0JpbmddIE9LLCB0aGFua3MgZm9yIHlvdXIgb3Bpbmlv bi4gSSBkb27igJl0IGhhdmUgYSBzdHJvbmcgZmVlbGluZyBvbiB0aGlzLiBJIGhhdmVu4oCZdCBm aWd1cmVkIG91dCB0aGUgbmVjZXNzaXR5IG9mIG5hbWluZyBBU0FzLCBidXQgbWVhbndoaWxlIEkg Y291bGRu4oCZdCBkZW55IGl0IGVpdGhlci4NCg0KDQogICAgbyAgVW5pcXVlbmVzcw0KICAgICAg ICAgVGhlIG5hbWVzIE1VU1QgTk9UIGNvbGxpZGUgd2l0aGluIG9uZSBhdXRvbm9taWMgZG9tYWlu Lg0KICAgICAgICAgSXQgaXMgYWNjZXB0YWJsZSB0aGF0IHRoZSBuYW1lcyBpbiBkaWZmZXJlbnQg ZG9tYWlucyBjb2xsaWRlLA0KICAgICAgICAgc2luY2UgdGhleSBjb3VsZCBiZSBkaXN0aW5ndWlz aGVkIGJ5IGRvbWFpbnMuDQo8amNzPg0KSSBkaXNsaWtlIG5hbWUgY29sbGlzaW9ucywgdW5sZXNz IHRoZXJlIGlzIGEgZ29vZCByZWFzb24gdG8gaGF2ZSB0aGVtDQooYW5kIHBsZWFzZSBkb24ndCBz YXkgImJlY2F1c2UgaXQgaXMgZWFzaWVyIiA6LSkgKS4gVGhhdCBiZWluZyBzYWlkLCBJDQp3b3Vs ZCBleHBlY3QgdGhlbSB0byBiZSByZWdpc3RlcmVkIGluIHRoZSBETlMuDQo8L2pjcz4NCltCaW5n XSBJZGVhbGx5LCB3ZSBzdXJlbHkgcHJlZmVyIHRoYXQgbmFtZXMgbmV2ZXIgY29sbGlkZSwgZXZl biBhY3Jvc3MgZG9tYWlucy4gQnV0IG15IGNvbmNlcm4gd2FzIHRoYXQgaXQgbWlnaHQgYmUgZGlm ZmljdWx0IHRvIGVuc3VyZSB1bmlxdWVuZXNzIGFjcm9zcyBtdWx0aXBsZSBkb21haW5zIHRoYW4g b25seSB3aXRoaW4gb25lIGRvbWFpbi4NCklmIEROUyBpcyBpbnRyb2R1Y2VkIHRvIHRoZSBBTkks IHRoZW4gSSBndWVzcyB0aGlzIGlzc3VlIGlzIGRvbmUuIEJ1dCB3b3VsZCBpbnRyb2R1Y2luZyBE TlMgYnJpbmcgc29tZSB1bmF2b2lkYWJsZSBodW1hbiBjb25zdW1wdGlvbj8NCg0KICAgIG8gIFNl bWFudGljIEVuY29kaW5nDQogICAgICAgICBJdCBpcyBSRUNPTU1FTkRFRCB0aGF0IHRoZSBuYW1l cyBlbmNvZGUgc29tZSBzZW1hbnRpY3MgcmF0aGVyDQogICAgICAgICB0aGFuIG1lYW5pbmdsZXNz IHN0cmluZ3MuICBUaGUgc2VtYW50aWNzIG1pZ2h0IGJlOg0KICAgICAgICAgKyAgTG9jYXRpb24N CiAgICAgICAgICsgIERldmljZSB0eXBlDQogICAgICAgICArICBGdW5jdGlvbmFsIHJvbGUNCiAg ICAgICAgICsgIE93bmVyc2hpcA0KICAgICAgICAgKyAgZXRjLg0KICAgICAgICAgVGhpcyBpcyBm b3IgZWFzZSBvZiBtYW5hZ2VtZW50IGNvbnNpZGVyYXRpb24gdGhhdCBuZXR3b3JrDQogICAgICAg ICBhZG1pbmlzdHJhdG9ycyBjb3VsZCBlYXNpbHkgcmVjb2duaXplIHRoZSBkZXZpY2UgZGlyZWN0 bHkNCiAgICAgICAgIHRocm91Z2ggdGhlIG5hbWVzLg0KPGpjcz4NCkkgYW0gYSBiaWcgZmFuIG9m IHNlbWFudGljcy4gSSBhY3RpdmVseSB3b3JrIG9uIG9udG9sb2dpZXMsIGRpZmZlcmVudA0KdHlw ZXMgb2YgbG9naWMsIG1ldGFkYXRhLWJhc2VkIHN5c3RlbXMsIGV0Yy4gSG93ZXZlciwgSSB3b3Vs ZCBOT1QNCnJlY29tbWVuZCB0aGlzLiBGaXJzdCwgSSBndWFyYW50ZWUgeW91IHRoYXQgd2Ugd2ls bCByYXRob2xlIG9uIGRlZmluaW5nDQphIGNhbm9uaWNhbCByZXByZXNlbnRhdGlvbiBmb3IgZ2Vu ZXJhdGluZyBzdHJpbmdzLiBTZWNvbmQsIGlmIEkgd2FzIGFuDQpBU0EgKEkndmUgYmVlbiBjYWxs ZWQgd29yc2UgOnMpLCBJIHdvdWxkbid0IHBheSBhdHRlbnRpb24gdG8gdGhlIG5hbWUNCm9mIGFu IG9iamVjdCBhcyBtdWNoIGFzIEkgd291bGQgaXRzIGNvbm5lY3Rpb25zIG9yIGl0cyBtZXRhZGF0 YS4gSQ0Kd291bGQgZXhwZWN0IHRoZSBtZXRhZGF0YSB0byBiZSB3ZWxsIHN0cnVjdHVyZWQsIGFu ZCBub3QganVzdCBjb25zaXN0DQpvZiBtZWFuaW5nbGVzcyB0ZXh0LiBIZW5jZSwgSSB3b3VsZCBy ZWNvbW1lbmQgKHB1biBpbnRlbmRlZCkgdGhhdA0Kd2UgaW5zdGVhZCBjb25jZW50cmF0ZSBvbiBk ZWZpbmluZyBzZW1hbnRpY3Mgb2YgbWV0YWRhdGENCjwvamNzPg0KW0JpbmddIFRoYW5rcyBmb3Ig dGhlIHRlY2huaWNhbCBzdWdnZXN0aW9uLiBXb3VsZCB5b3UgbWluZCBlbGFib3JhdGluZyBhIGJp dCBtb3JlIG9uIHdoYXQgZGlkIHlvdSBtZWFuIGJ5IOKAnG1ldGFkYXRh4oCdPyBTb3JyeSBmb3Ig bXkgZm9vbGlzaOKYug0KDQoNCiAgICBvICBDb25zaXN0ZW5jeQ0KICAgICAgICAgVGhlIGRldmlj ZXMnIG5hbWluZyBTSE9VTEQgZm9sbG93IHRoZSBzYW1lIHBhdHRlcm4gd2l0aGluIGENCiAgICAg ICAgIGRvbWFpbi4NCjxqY3M+DQpzL2RvbWFpbi9hdXRvbm9taWMgZG9tYWluLiBZb3UgY2FuJ3Qg cmVuYW1lIGxlZ2FjeSBzeXN0ZW1zLg0KPC9qY3M+DQpbQmluZ10gQWdyZWVkLiBUaGFua3MgZm9y IGNvcnJlY3Rpb24uDQoNCg0KIDQuMS4yLiAgUHJvcG9zZWQgTWVjaGFuaXNtcw0KDQogICAgbyAg U3RydWN0dXJlZCBOYW1pbmcgUGF0dGVybg0KICAgICAgICAgVGhlIHdob2xlIG5hbWUgc3RyaW5n IGNvdWxkIGJlIGRpdmlkZWQgaW50byBzZXZlcmFsIGZpZWxkcywNCiAgICAgICAgIGVhY2ggb2Yg d2hpY2ggcmVwcmVzZW50aW5nIGEgc3BlY2lmaWMgc2VtYW50aWMgYXMgZGVzY3JpYmVkDQogICAg ICAgICBhYm92ZS4gIEZvciBleGFtcGxlOiBMb2NhdGlvbi1EZXZpY2VUeXBlLUZ1bmN0aW9uYWxS b2xlLQ0KICAgICAgICAgRGlzdGluZ3Vpc2hlck51bWJlckBOYW1lb2ZEb21haW4uDQo8amNzPg0K V2h5IG5vdCB1c2UgbWV0YWRhdGEgdG8gZW5jb2RlIHRoZSBzZW1hbnRpY3MsIGFuZCBzdGFuZGFy ZGl6ZSB0aGUNCm1ldGFkYXRhIG9iamVjdCB0YXhvbm9teSBpbnN0ZWFkPyBBbHNvLCBpZiBJIGxv b2sgYXQgdGhlIG1vZGVybg0Kcm91dGVyIG9yIHN3aXRjaCwgdGhlIG5hbWUgaXMgdXNlbGVzcy4g V2hhdCBJIHNlZSBpcyBhIGNoYXNzaXMNCmNvbnRhaW5pbmcgYSBzZXQgb2YgY2FyZHMsIHdoZXJl IGVhY2ggY2FyZCBjYW4gcGxheSBvbmUgb3IgbW9yZSByb2xlcy4NCkkgd291bGQgc2VhcmNoIG9u IHJvbGVzICh3aGljaCBpcywgb2YgY291cnNlLCBhIHR5cGUgb2YgbWV0YWRhdGEpLiBJbg0KdGhp cyB3YXksIEkgZ2V0IHJlYWwgaW5mb3JtYXRpb24sIG5vdCBhYmJyZXZpYXRlZCBzdHJpbmdzIGNv bmNhdGVuYXRlZA0KdG9nZXRoZXIuDQo8L2pjcz4NCltCaW5nXSBUaGUgc2FtZSDigJxtZXRhZGF0 YeKAnSBxdWVzdGlvbiBhcyBhYm92ZS4NCg0KDQogICAgICAgICAgVGhlIHN0cnVjdHVyZSBzaG91 bGQgYmUgZmxleGlibGUgdGhhdCBzb21lIGZpZWxkcyBhcmUgb3B0aW9uYWwuDQogICAgICAgICBX aGVuIHRoZXNlIG9wdGlvbmFsIGZpZWxkcyBhcmUgYWRkZWQsIHRoZSBuYW1lIGNvdWxkIHN0aWxs IGJlDQogICAgICAgICByZWNvZ25pemVkIGFzIHRoZSBwcmV2aW91cyBvbmUuICBJbiBhYm92ZSBl eGFtcGxlLCB0aGUNCiAgICAgICAgICJEaXN0aW5ndWlzaGVyTnVtYmVyIiBhbmQgIk5hbWVvZkRv bWFpbiIgYXJlIG1hbmRhdG9yeSB3aGVyZWFzDQogICAgICAgICBvdGhlcnMgYXJlIG9wdGlvbmFs LiAgQXQgaW5pdGlhbCBzdGFnZSwgdGhlIGRldmljZXMgbWlnaHQgYmUNCiAgICAgICAgIG9ubHkg Y2FwYWJsZSBvZiBzZWxmLWdlbmVyYXRpbmcgdGhlIG1hbmRhdG9yeSBmaWVsZHMgYW5kIHRoZQ0K ICAgICAgICAgIkRldmljZVR5cGUiIGJlY2F1c2Ugb2YgdGhlIGxhY2sgb2Yga25vd2xlZGdlLiAg TGF0ZXIsIHRoZXkNCiAgICAgICAgIG1pZ2h0IGhhdmUgbGVhcm5lZCB0aGUgIkxvY2F0aW9uIiBh bmQgIkZ1bmN0aW9uYWxSb2xlIiBhbmQNCiAgICAgICAgIGFkZGVkIHRoZSBmaWVsZHMgaW50byBj dXJyZW50IG5hbWUuICBIb3dldmVyLCB0aGUgb3RoZXIgZGV2aWNlcw0KICAgICAgICAgY291bGQg c3RpbGwgcmVjb2duaXplIGl0IGFjY29yZGluZyB0byB0aGUgc2FtZQ0KICAgICAgICAgIkRpc3Rp bmd1aXNoZXJOdW1iZXIiLg0KPGpjcz4NCllpa2VycyENCkZpcnN0LCBoYXZpbmcgYSBub2RlIHRo YXQgaXMgY2hhbmdpbmcgaXRzIG5hbWUgaXMgYW5ub3lpbmcuIE9mIGNvdXJzZSwNCnRoaXMgaXMg YSBnb29kIGZpbHRlciBmb3Igcm9idXN0IGNvZGluZyA6cy4NClNlY29uZCwgYW4gYXV0b25vbWlj IGRvbWFpbiB3aWxsIGFkZCBuZXcgZGF0YSBhbGwgdGhlIHRpbWUgKG9yIGVsc2UNCml0J3MgcHJv YmFibHkgZGVhZCkuIEhvdyBkbyB3ZSBkZXRlcm1pbmUgd2hhdCBkYXRhIGlzICJuYW1lLXdvcnRo eSI/DQo8L2pjcz4NCltCaW5nXSBBcyBJIHJlcGxpZWQgdG8gQnJpYW4gaW4gYW5vdGhlciB0aHJl YWQ6IG1heWJlIHdlIGNvdWxkIGRpdmlkZSB0aGUgbmFtZSBpbnRvIHR3byBwYXJ0czogb25lIHBh cnQgaXMgdGhlICJiYXNpYy1uYW1lIiB3aGljaCBzaG91bGQgYmUgcGVybWFuZW50OyB0aGUgb3Ro ZXIgcGFydCBpcyAibmFtZS10YWdzIiAoZS5nLiBMb2NhdGlvbiwgRnVuY3Rpb25hbCBSb2xlLCBP d25lcnNoaXAgZXRjLikgd2hpY2ggYXJlIHNvbWUgaW5mbyB0aGF0IG1pZ2h0IGJlIHVzZWZ1bCBm b3IgYWRtaW5pc3RyYXRpb24gYnV0IG1pZ2h0IHByb2JhYmx5IGNoYW5nZXMuDQpIb3cgZG8geW91 IHRoaW5rIGFib3V0IGl0Pw0KDQoNCiAgICBvICBBZHZlcnRpc2VkIENvbW1vbiBGaWVsZHMNCiAg ICAgICAgIFNvbWUgZmllbGRzIGluIHRoZSBzdHJ1Y3R1cmVkIG5hbWUgbWlnaHQgYmUgY29tbW9u IGFtb25nIHRoZQ0KICAgICAgICAgZG9tYWluIChlLmcuICAiTG9jYXRpb24iICJOYW1lb2ZEb21h aW4iKS4gIFRodXMsIHRoZXNlIHBhcnQgb2YNCiAgICAgICAgIHRoZSBuYW1lcyBjb3VsZCBiZSBh ZHZlcnRpc2VkIHRocm91Z2ggSW50ZW50DQogICAgICAgICBEaXN0cmlidXRpb24gKFNlY3Rpb24g NC41KS4NCjxqY3M+DQpJIHdvdWxkIGhvcGUgdGhhdCBpbnRlbnQgd291bGQgYmUgc21hcnRlciBh bmQgbW9yZSBhYnN0cmFjdC4gSWYgYSBmaWVsZA0KaXMgY29tbW9uLCB0aGVuIGludGVudCBjYW4g YmUgYWJzdHJhY3QgYW5kIHRoZSB0cmFuc2xhdGlvbiB0byBhIGNvbW1vbg0KZmllbGQgaXMgbXVj aCBlYXNpZXIuIEluIG90aGVyIHdvcmRzLCBiZWluZyBjb21tb24gaXMgbm90IGEgZ29vZCByZWFz b24NCnRvIGJlIGluY2x1ZGVkIGluIGludGVudC4NCjwvamNzPg0KW0JpbmddIEluIHRoZSBwZXJz cGVjdGl2ZSBvZiBjb25jaXNlIGNvbmNlcHQsIEkgYWxzbyB0aGluayBJbnRlbnQgbWlnaHQgbm90 IGJlIHByb3BlciB0byBjYXJyeSB0aGlzIGtpbmQgb2YgaW5mby4gQnV0IEludGVudCBEaXN0cmli dXRpb24gaXMgdGhlIG9ubHkgdGhpbmcgSSBjYW4gdGVsbCB0byBhZHZlcnRpc2UgdGhlIGNvbW1v biBpbmZvIHRvIHRoZSBBTi4NCkFueSBvdGhlciBhcHByb2FjaGVzPw0KDQpCZXN0IHJlZ2FyZHMs DQpCaW5nDQoNCg0KICAgIG8gIFNlbGYtZ2VuZXJhdGVkIEZpZWxkcw0KICAgICAgICAgVGhlIG1h bmRhdG9yeSBmaWVsZHMgU0hPVUxEIGJlIHNlbGYtZ2VuZXJhdGVkIHNvIHRoYXQgb25lDQogICAg ICAgICBkZXZpY2UgY291bGQgbmFtZSBpdHNlbGYgc3VmZmljaWVudGx5IHdpdGhvdXQgYW55IGFk dmVydGlzZWQNCiAgICAgICAgIGtub3dsZWRnZXMuDQogICAgICAgICBUaGVyZSBzaG91bGQgdmFy aW91cyBtZXRob2RzIGZvciBhIGRldmljZSB0byBleHRyYWN0L2dlbmVyYXRlIGENCiAgICAgICAg IHByb3BlciB3b3JkIGZvciBlYWNoIG1hbmRhdG9yeSBzZW1hbnRpYyBmaWVsZHMgKGUuZy4NCiAg ICAgICAgICJEZXZpY2VUeXBlIiwgIkRpc3Rpbmd1aXNoZXJOdW0iKSBmcm9tIGl0cyBzZWxmLWtu b3dsZWRnZS4NCg0KICAgRGV0YWlsZWQgZGVzaWduIG9mIHNwZWNpZmljIG5hbWluZyBwYXR0ZXJu cyBhbmQgbWV0aG9kcyBhcmUgb3V0IG9mDQogICBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KDQpP biBGcmksIEp1biAyNiwgMjAxNSBhdCAzOjI3IEFNLCBMaXViaW5nIChMZW8pIDxsZW8ubGl1Ymlu Z0BodWF3ZWkuY29tPG1haWx0bzpsZW8ubGl1YmluZ0BodWF3ZWkuY29tPj4gd3JvdGU6DQpIaSBE ZWFyIGFsbCwNCg0KSSd2ZSBnZW5lcmF0ZWQgc29tZSB0ZXh0IHJlZ2FyZGluZyB0byB0aGUgbmFt aW5nIG9mIGF1dG9ub21pYyBuZXR3b3JrIGRldmljZXMuIFRoaXMgaXMgdG8gZml0IHRoZSBTZWN0 aW9uIDQuMSBpbiB0aGUgUmVmZXJlbmNlLU1vZGVsIGRyYWZ0Lg0KQmVsb3cgaXMgdGhlIGNvbnRl bnQgd2hpY2ggaW5jbHVkZXMgc29tZSByb3VnaCBpZGVhcy4gUGxlYXNlIGZlZWwgZnJlZSB0byBj b21tZW50Lg0KDQo0LjEuICBOYW1pbmcNCg0KNC4xLjEuICBOYW1pbmcgcmVxdWlyZW1lbnRzDQoN CiAgIG8gIFJlcHJlc2VudGluZyBlYWNoIGRldmljZQ0KICAgICAgICAgSW5zaWRlIGEgZG9tYWlu LCBlYWNoIGF1dG9ub21pYyBkZXZpY2UgbmVlZHMgYSBkb21haW4gc3BlY2lmaWMNCiAgICAgICAg IGlkZW50aWZpZXIuDQogICAgICAgICBbT3BlbiBRdWVzdGlvbnNdIEFyZSB0aGVyZSBkZXZpY2Vz IHRoYXQgZG9uJ3QgbmVlZCBuYW1lcz8gIERvDQogICAgICAgICBBU0FzIG5lZWQgbmFtZXM/DQoN CiAgIG8gIFVuaXF1ZW5lc3MNCiAgICAgICAgIFRoZSBuYW1lcyBNVVNUIE5PVCBjb2xsaWRlIHdp dGhpbiBvbmUgYXV0b25vbWljIGRvbWFpbi4NCiAgICAgICAgIEl0IGlzIGFjY2VwdGFibGUgdGhh dCB0aGUgbmFtZXMgaW4gZGlmZmVyZW50IGRvbWFpbnMgY29sbGlkZSwNCiAgICAgICAgIHNpbmNl IHRoZXkgY291bGQgYmUgZGlzdGluZ3Vpc2hlZCBieSBkb21haW5zLg0KDQogICBvICBTZW1hbnRp YyBFbmNvZGluZw0KICAgICAgICAgSXQgaXMgUkVDT01NRU5ERUQgdGhhdCB0aGUgbmFtZXMgZW5j b2RlIHNvbWUgc2VtYW50aWNzIHJhdGhlcg0KICAgICAgICAgdGhhbiBtZWFuaW5nbGVzcyBzdHJp bmdzLiAgVGhlIHNlbWFudGljcyBtaWdodCBiZToNCiAgICAgICAgICsgIExvY2F0aW9uDQogICAg ICAgICArICBEZXZpY2UgdHlwZQ0KICAgICAgICAgKyAgRnVuY3Rpb25hbCByb2xlDQogICAgICAg ICArICBPd25lcnNoaXANCiAgICAgICAgICsgIGV0Yy4NCiAgICAgICAgIFRoaXMgaXMgZm9yIGVh c2Ugb2YgbWFuYWdlbWVudCBjb25zaWRlcmF0aW9uIHRoYXQgbmV0d29yaw0KICAgICAgICAgYWRt aW5pc3RyYXRvcnMgY291bGQgZWFzaWx5IHJlY29nbml6ZSB0aGUgZGV2aWNlIGRpcmVjdGx5DQog ICAgICAgICB0aHJvdWdoIHRoZSBuYW1lcy4NCg0KICAgbyAgQ29uc2lzdGVuY3kNCiAgICAgICAg IFRoZSBkZXZpY2VzJyBuYW1pbmcgU0hPVUxEIGZvbGxvdyB0aGUgc2FtZSBwYXR0ZXJuIHdpdGhp biBhDQogICAgICAgICBkb21haW4uDQoNCjQuMS4yLiAgUHJvcG9zZWQgTWVjaGFuaXNtcw0KDQog ICAgbyAgU3RydWN0dXJlZCBOYW1pbmcgUGF0dGVybg0KICAgICAgICAgVGhlIHdob2xlIG5hbWUg c3RyaW5nIGNvdWxkIGJlIGRpdmlkZWQgaW50byBzZXZlcmFsIGZpZWxkcywNCiAgICAgICAgIGVh Y2ggb2Ygd2hpY2ggcmVwcmVzZW50aW5nIGEgc3BlY2lmaWMgc2VtYW50aWMgYXMgZGVzY3JpYmVk DQogICAgICAgICBhYm92ZS4gIEZvciBleGFtcGxlOiBMb2NhdGlvbi1EZXZpY2VUeXBlLUZ1bmN0 aW9uYWxSb2xlLQ0KICAgICAgICAgRGlzdGluZ3Vpc2hlck51bWJlckBOYW1lb2ZEb21haW4uDQoN CiAgICAgICAgIFRoZSBzdHJ1Y3R1cmUgc2hvdWxkIGJlIGZsZXhpYmxlIHRoYXQgc29tZSBmaWVs ZHMgYXJlIG9wdGlvbmFsLg0KICAgICAgICAgV2hlbiB0aGVzZSBvcHRpb25hbCBmaWVsZHMgYXJl IGFkZGVkLCB0aGUgbmFtZSBjb3VsZCBzdGlsbCBiZQ0KICAgICAgICAgcmVjb2duaXplZCBhcyB0 aGUgcHJldmlvdXMgb25lLiAgSW4gYWJvdmUgZXhhbXBsZSwgdGhlDQogICAgICAgICAiRGlzdGlu Z3Vpc2hlck51bWJlciIgYW5kICJOYW1lb2ZEb21haW4iIGFyZSBtYW5kYXRvcnkgd2hlcmVhcw0K ICAgICAgICAgb3RoZXJzIGFyZSBvcHRpb25hbC4gIEF0IGluaXRpYWwgc3RhZ2UsIHRoZSBkZXZp Y2VzIG1pZ2h0IGJlDQogICAgICAgICBvbmx5IGNhcGFibGUgb2Ygc2VsZi1nZW5lcmF0aW5nIHRo ZSBtYW5kYXRvcnkgZmllbGRzIGFuZCB0aGUNCiAgICAgICAgICJEZXZpY2VUeXBlIiBiZWNhdXNl IG9mIHRoZSBsYWNrIG9mIGtub3dsZWRnZS4gIExhdGVyLCB0aGV5DQogICAgICAgICBtaWdodCBo YXZlIGxlYXJuZWQgdGhlICJMb2NhdGlvbiIgYW5kICJGdW5jdGlvbmFsUm9sZSIgYW5kDQogICAg ICAgICBhZGRlZCB0aGUgZmllbGRzIGludG8gY3VycmVudCBuYW1lLiAgSG93ZXZlciwgdGhlIG90 aGVyIGRldmljZXMNCiAgICAgICAgIGNvdWxkIHN0aWxsIHJlY29nbml6ZSBpdCBhY2NvcmRpbmcg dG8gdGhlIHNhbWUNCiAgICAgICAgICJEaXN0aW5ndWlzaGVyTnVtYmVyIi4NCg0KICAgbyAgQWR2 ZXJ0aXNlZCBDb21tb24gRmllbGRzDQogICAgICAgICBTb21lIGZpZWxkcyBpbiB0aGUgc3RydWN0 dXJlZCBuYW1lIG1pZ2h0IGJlIGNvbW1vbiBhbW9uZyB0aGUNCiAgICAgICAgIGRvbWFpbiAoZS5n LiAgIkxvY2F0aW9uIiAiTmFtZW9mRG9tYWluIikuICBUaHVzLCB0aGVzZSBwYXJ0IG9mDQogICAg ICAgICB0aGUgbmFtZXMgY291bGQgYmUgYWR2ZXJ0aXNlZCB0aHJvdWdoIEludGVudA0KICAgICAg ICAgRGlzdHJpYnV0aW9uIChTZWN0aW9uIDQuNSkuDQoNCiAgIG8gIFNlbGYtZ2VuZXJhdGVkIEZp ZWxkcw0KICAgICAgICAgVGhlIG1hbmRhdG9yeSBmaWVsZHMgU0hPVUxEIGJlIHNlbGYtZ2VuZXJh dGVkIHNvIHRoYXQgb25lDQogICAgICAgICBkZXZpY2UgY291bGQgbmFtZSBpdHNlbGYgc3VmZmlj aWVudGx5IHdpdGhvdXQgYW55IGFkdmVydGlzZWQNCiAgICAgICAgIGtub3dsZWRnZXMuDQogICAg ICAgICBUaGVyZSBzaG91bGQgdmFyaW91cyBtZXRob2RzIGZvciBhIGRldmljZSB0byBleHRyYWN0 L2dlbmVyYXRlIGENCiAgICAgICAgIHByb3BlciB3b3JkIGZvciBlYWNoIG1hbmRhdG9yeSBzZW1h bnRpYyBmaWVsZHMgKGUuZy4NCiAgICAgICAgICJEZXZpY2VUeXBlIiwgIkRpc3Rpbmd1aXNoZXJO dW0iKSBmcm9tIGl0cyBzZWxmLWtub3dsZWRnZS4NCg0KICAgRGV0YWlsZWQgZGVzaWduIG9mIHNw ZWNpZmljIG5hbWluZyBwYXR0ZXJucyBhbmQgbWV0aG9kcyBhcmUgb3V0IG9mDQogICBzY29wZSBv ZiB0aGlzIGRvY3VtZW50Lg0KDQoNCg0KQmVzdCByZWdhcmRzLA0KQmluZw0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQW5pbWEgbWFpbGluZyBsaXN0 DQpBbmltYUBpZXRmLm9yZzxtYWlsdG86QW5pbWFAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hDQoNCg0KDQotLQ0KcmVnYXJkcywNCkpvaG4NCg== --_000_8AE0F17B87264D4CAC7DE0AA6C406F45C21D5BFDnkgeml506mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcy LjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkhpIEpvaG4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5r cyBmb3IgeW91ciBlbGFib3JhdGUgcmV2aWV3IGFuZCBjb21tZW50cywgcGxlYXNlIHNlZSByZXBs aWVzIGlubGluZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSm9obiBTdHJhc3NuZXIgW21h aWx0bzpzdHJhenBkakBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBKdW5l IDI4LCAyMDE1IDg6MTggQU08YnI+DQo8Yj5Ubzo8L2I+IExpdWJpbmcgKExlbyk8YnI+DQo8Yj5D Yzo8L2I+IEFuaW1hIFdHPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbQW5pbWFdIE5hbWluZyBk aXNjdXNzaW9uIChTZWN0aW9uIDQuMSBvZiB0aGUgUmVmZXJlbmNlLU1vZGVsIGRyYWZ0KTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+RGVhciBMZW8sPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5wbGVhc2Ugc2Vl IGlubGluZSwgbG9vayBmb3IgJmx0O2pjcyZndDsuLiZsdDsvamNzJmd0OzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+cmVnYXJkcyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+Sm9objxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjQuMS4mbmJzcDsgTmFtaW5nPGJyPg0K PGJyPg0KNC4xLjEuJm5ic3A7IE5hbWluZyByZXF1aXJlbWVudHM8YnI+DQo8YnI+DQombmJzcDsg Jm5ic3A7byZuYnNwOyBSZXByZXNlbnRpbmcgZWFjaCBkZXZpY2U8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7SW5zaWRlIGEgZG9tYWluLCBlYWNoIGF1dG9ub21pYyBkZXZp Y2UgbmVlZHMgYSBkb21haW4gc3BlY2lmaWM8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7aWRlbnRpZmllci48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7W09wZW4gUXVlc3Rpb25zXSBBcmUgdGhlcmUgZGV2aWNlcyB0aGF0IGRvbid0IG5lZWQgbmFt ZXM/Jm5ic3A7IERvPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0FTQXMg bmVlZCBuYW1lcz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jmx0O2pjcyZndDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+SSB0aGluayB0aGF0IGVhY2gmbmJzcDsqKmVudGl0eSoqIHRoYXQgY2FuIHBvdGVu dGlhbGx5IGludGVyYWN0IHdpdGggb3RoZXIgZW50aXRpZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ TVVTVCBIQVZFIGEgbmFtZS4gSSB0aGluayBvZiBBU0FzIGFzIG1hbmFnZWQgZW50aXRpZXMsIHNv IHllcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+dGhleSBkbyBhcyB3ZWxsLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbHQ7L2pjcyZndDs8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286 cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W0JpbmddIE9LLCB0aGFu a3MgZm9yIHlvdXIgb3Bpbmlvbi4gSSBkb27igJl0IGhhdmUgYSBzdHJvbmcgZmVlbGluZyBvbiB0 aGlzLiBJIGhhdmVu4oCZdCBmaWd1cmVkIG91dCB0aGUgbmVjZXNzaXR5IG9mIG5hbWluZyBBU0Fz LCBidXQgbWVhbndoaWxlIEkNCiBjb3VsZG7igJl0IGRlbnkgaXQgZWl0aGVyLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+ DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtvJm5ic3A7IFVuaXF1ZW5lc3M8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhlIG5hbWVzIE1VU1QgTk9UIGNvbGxp ZGUgd2l0aGluIG9uZSBhdXRvbm9taWMgZG9tYWluLjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtJdCBpcyBhY2NlcHRhYmxlIHRoYXQgdGhlIG5hbWVzIGluIGRpZmZlcmVu dCBkb21haW5zIGNvbGxpZGUsPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O3NpbmNlIHRoZXkgY291bGQgYmUgZGlzdGluZ3Vpc2hlZCBieSBkb21haW5zLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj4mbHQ7amNzJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGRpc2xpa2UgbmFt ZSBjb2xsaXNpb25zLCB1bmxlc3MgdGhlcmUgaXMgYSBnb29kIHJlYXNvbiB0byBoYXZlIHRoZW08 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+KGFuZCBwbGVhc2UgZG9uJ3Qgc2F5Jm5ic3A7JnF1b3Q7YmVj YXVzZSBpdCBpcyBlYXNpZXImcXVvdDsgOi0pICkuIFRoYXQgYmVpbmcgc2FpZCwgSTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj53b3VsZCBleHBlY3QgdGhlbSB0byZuYnNwO2JlIHJlZ2lzdGVyZWQgaW4g dGhlIEROUy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jmx0Oy9qY3MmZ3Q7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bQmluZ10gSWRlYWxseSwgd2Ugc3VyZWx5IHBy ZWZlciB0aGF0IG5hbWVzIG5ldmVyIGNvbGxpZGUsIGV2ZW4gYWNyb3NzIGRvbWFpbnMuIEJ1dCBt eSBjb25jZXJuIHdhcyB0aGF0IGl0IG1pZ2h0IGJlIGRpZmZpY3VsdCB0byBlbnN1cmUgdW5pcXVl bmVzcw0KIGFjcm9zcyBtdWx0aXBsZSBkb21haW5zIHRoYW4gb25seSB3aXRoaW4gb25lIGRvbWFp bi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklmIEROUyBpcyBp bnRyb2R1Y2VkIHRvIHRoZSBBTkksIHRoZW4gSSBndWVzcyB0aGlzIGlzc3VlIGlzIGRvbmUuIEJ1 dCB3b3VsZCBpbnRyb2R1Y2luZyBETlMgYnJpbmcgc29tZSB1bmF2b2lkYWJsZSBodW1hbiBjb25z dW1wdGlvbj8NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsm bmJzcDtvJm5ic3A7IFNlbWFudGljIEVuY29kaW5nPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO0l0IGlzIFJFQ09NTUVOREVEIHRoYXQgdGhlIG5hbWVzIGVuY29kZSBzb21l IHNlbWFudGljcyByYXRoZXI8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 dGhhbiBtZWFuaW5nbGVzcyBzdHJpbmdzLiZuYnNwOyBUaGUgc2VtYW50aWNzIG1pZ2h0IGJlOjxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOyZuYnNwOyBMb2NhdGlv bjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOyZuYnNwOyBEZXZp Y2UgdHlwZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOyZuYnNw OyBGdW5jdGlvbmFsIHJvbGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 JiM0MzsmbmJzcDsgT3duZXJzaGlwPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyYjNDM7Jm5ic3A7IGV0Yy48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7VGhpcyBpcyBmb3IgZWFzZSBvZiBtYW5hZ2VtZW50IGNvbnNpZGVyYXRpb24gdGhhdCBuZXR3 b3JrPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2FkbWluaXN0cmF0b3Jz IGNvdWxkIGVhc2lseSByZWNvZ25pemUgdGhlIGRldmljZSBkaXJlY3RseTxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0aHJvdWdoIHRoZSBuYW1lcy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+Jmx0O2pjcyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SSBhbSBhIGJpZyBmYW4g b2Ygc2VtYW50aWNzLiBJIGFjdGl2ZWx5IHdvcmsgb24gb250b2xvZ2llcywgZGlmZmVyZW50PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPnR5cGVzIG9mIGxvZ2ljLCBtZXRhZGF0YS1iYXNlZCBzeXN0ZW1z LCBldGMuIEhvd2V2ZXIsIEkgd291bGQgTk9UPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPnJlY29tbWVu ZCB0aGlzLiBGaXJzdCwmbmJzcDtJIGd1YXJhbnRlZSB5b3UgdGhhdCB3ZSB3aWxsIHJhdGhvbGUg b24gZGVmaW5pbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+YSBjYW5vbmljYWwgcmVwcmVzZW50YXRp b24gZm9yIGdlbmVyYXRpbmcgc3RyaW5ncy4gU2Vjb25kLCBpZiBJIHdhcyZuYnNwO2FuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPkFTQSAoSSd2ZSBiZWVuIGNhbGxlZCB3b3JzZSA6cyksIEkgd291bGRu J3QgcGF5IGF0dGVudGlvbiB0byB0aGUgbmFtZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5vZiBhbiBv YmplY3QgYXMgbXVjaCBhcyBJIHdvdWxkIGl0cyBjb25uZWN0aW9ucyBvciBpdHMgbWV0YWRhdGEu IEk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+d291bGQgZXhwZWN0IHRoZSBtZXRhZGF0YSB0byBiZSB3 ZWxsIHN0cnVjdHVyZWQsIGFuZCZuYnNwO25vdCBqdXN0IGNvbnNpc3Q8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+b2YgbWVhbmluZ2xlc3MgdGV4dC4mbmJzcDtIZW5jZSwgSSB3b3VsZCByZWNvbW1lbmQm bmJzcDsocHVuIGludGVuZGVkKSB0aGF0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPndlIGluc3RlYWQg Y29uY2VudHJhdGUgb24gZGVmaW5pbmcmbmJzcDtzZW1hbnRpY3Mgb2YgbWV0YWRhdGE8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+Jmx0Oy9qY3MmZ3Q7PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxv OnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltCaW5nXSBU aGFua3MgZm9yIHRoZSB0ZWNobmljYWwgc3VnZ2VzdGlvbi4gV291bGQgeW91IG1pbmQgZWxhYm9y YXRpbmcgYSBiaXQgbW9yZSBvbiB3aGF0IGRpZCB5b3UgbWVhbiBieSDigJxtZXRhZGF0YeKAnT8g U29ycnkgZm9yIG15IGZvb2xpc2g8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj5KPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7byZuYnNwOyBDb25z aXN0ZW5jeTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaGUgZGV2aWNl cycgbmFtaW5nIFNIT1VMRCBmb2xsb3cgdGhlIHNhbWUgcGF0dGVybiB3aXRoaW4gYTxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkb21haW4uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPiZsdDtqY3MmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPnMvZG9tYWluL2F1dG9ub21pYyBk b21haW4uIFlvdSBjYW4ndCByZW5hbWUgbGVnYWN5IHN5c3RlbXMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPiZsdDsvamNzJmd0OzxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwv c3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bQmluZ10gQWdyZWVkLiBUaGFu a3MgZm9yIGNvcnJlY3Rpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4NCiZuYnNwOzQuMS4yLiZuYnNwOyBQ cm9wb3NlZCBNZWNoYW5pc21zPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBvJm5ic3A7IFN0cnVj dHVyZWQgTmFtaW5nIFBhdHRlcm48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7VGhlIHdob2xlIG5hbWUgc3RyaW5nIGNvdWxkIGJlIGRpdmlkZWQgaW50byBzZXZlcmFsIGZp ZWxkcyw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZWFjaCBvZiB3aGlj aCByZXByZXNlbnRpbmcgYSBzcGVjaWZpYyBzZW1hbnRpYyBhcyBkZXNjcmliZWQ8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YWJvdmUuJm5ic3A7IEZvciBleGFtcGxlOiBM b2NhdGlvbi1EZXZpY2VUeXBlLUZ1bmN0aW9uYWxSb2xlLTxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtEaXN0aW5ndWlzaGVyTnVtYmVyQE5hbWVvZkRvbWFpbi48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+Jmx0O2pjcyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+V2h5IG5vdCB1 c2UgbWV0YWRhdGEgdG8gZW5jb2RlIHRoZSBzZW1hbnRpY3MsIGFuZCZuYnNwO3N0YW5kYXJkaXpl IHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5tZXRhZGF0YSBvYmplY3QgdGF4b25vbXkgaW5zdGVh ZD8gQWxzbywgaWYgSSBsb29rIGF0IHRoZSBtb2Rlcm4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5y b3V0ZXIgb3Igc3dpdGNoLCZuYnNwO3RoZSBuYW1lIGlzIHVzZWxlc3MuIFdoYXQgSSBzZWUgaXMg YSBjaGFzc2lzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPmNvbnRhaW5pbmcgYSBzZXQgb2YgY2FyZHMs IHdoZXJlIGVhY2ggY2FyZCBjYW4gcGxheSBvbmUgb3IgbW9yZSByb2xlcy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+SSB3b3VsZCZuYnNwO3NlYXJjaCBvbiByb2xlcyAod2hpY2ggaXMsIG9mIGNvdXJz ZSwgYSB0eXBlIG9mIG1ldGFkYXRhKS4gSW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+dGhpcyB3YXks IEkgZ2V0IHJlYWwgaW5mb3JtYXRpb24sIG5vdCBhYmJyZXZpYXRlZCBzdHJpbmdzJm5ic3A7Y29u Y2F0ZW5hdGVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPnRvZ2V0aGVyLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj4mbHQ7L2pjcyZndDs8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48 L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W0JpbmddIFRoZSBzYW1lIOKA nG1ldGFkYXRh4oCdIHF1ZXN0aW9uIGFzIGFib3ZlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUaGUg c3RydWN0dXJlIHNob3VsZCBiZSBmbGV4aWJsZSB0aGF0IHNvbWUgZmllbGRzIGFyZSBvcHRpb25h bC48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7V2hlbiB0aGVzZSBvcHRp b25hbCBmaWVsZHMgYXJlIGFkZGVkLCB0aGUgbmFtZSBjb3VsZCBzdGlsbCBiZTxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyZWNvZ25pemVkIGFzIHRoZSBwcmV2aW91cyBv bmUuJm5ic3A7IEluIGFib3ZlIGV4YW1wbGUsIHRoZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsmcXVvdDtEaXN0aW5ndWlzaGVyTnVtYmVyJnF1b3Q7IGFuZCAmcXVvdDtO YW1lb2ZEb21haW4mcXVvdDsgYXJlIG1hbmRhdG9yeSB3aGVyZWFzPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO290aGVycyBhcmUgb3B0aW9uYWwuJm5ic3A7IEF0IGluaXRp YWwgc3RhZ2UsIHRoZSBkZXZpY2VzIG1pZ2h0IGJlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO29ubHkgY2FwYWJsZSBvZiBzZWxmLWdlbmVyYXRpbmcgdGhlIG1hbmRhdG9y eSBmaWVsZHMgYW5kIHRoZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsm cXVvdDtEZXZpY2VUeXBlJnF1b3Q7IGJlY2F1c2Ugb2YgdGhlIGxhY2sgb2Yga25vd2xlZGdlLiZu YnNwOyBMYXRlciwgdGhleTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtt aWdodCBoYXZlIGxlYXJuZWQgdGhlICZxdW90O0xvY2F0aW9uJnF1b3Q7IGFuZCAmcXVvdDtGdW5j dGlvbmFsUm9sZSZxdW90OyBhbmQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7YWRkZWQgdGhlIGZpZWxkcyBpbnRvIGN1cnJlbnQgbmFtZS4mbmJzcDsgSG93ZXZlciwgdGhl IG90aGVyIGRldmljZXM8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y291 bGQgc3RpbGwgcmVjb2duaXplIGl0IGFjY29yZGluZyB0byB0aGUgc2FtZTxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtEaXN0aW5ndWlzaGVyTnVtYmVyJnF1b3Q7 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbHQ7amNzJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Z aWtlcnMhPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkZpcnN0LCBoYXZpbmcgYSBub2RlIHRoYXQgaXMg Y2hhbmdpbmcgaXRzIG5hbWUgaXMgYW5ub3lpbmcuIE9mIGNvdXJzZSw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+dGhpcyBpcyBhIGdvb2QgZmlsdGVyIGZvciByb2J1c3QgY29kaW5nIDpzLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5TZWNvbmQsIGFuIGF1dG9ub21pYyBkb21haW4gd2lsbCBhZGQgbmV3IGRh dGEgYWxsIHRoZSZuYnNwO3RpbWUgKG9yIGVsc2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+aXQncyZu YnNwO3Byb2JhYmx5IGRlYWQpLiBIb3cgZG8gd2UgZGV0ZXJtaW5lIHdoYXQgZGF0YSBpcyAmcXVv dDtuYW1lLXdvcnRoeSZxdW90Oz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jmx0Oy9qY3MmZ3Q7PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPltCaW5nXSBBcyBJIHJlcGxpZWQgdG8gQnJpYW4gaW4gYW5vdGhl ciB0aHJlYWQ6IG1heWJlIHdlIGNvdWxkIGRpdmlkZSB0aGUgbmFtZSBpbnRvIHR3byBwYXJ0czog b25lIHBhcnQgaXMgdGhlICZxdW90O2Jhc2ljLW5hbWUmcXVvdDsgd2hpY2ggc2hvdWxkIGJlIHBl cm1hbmVudDsNCiB0aGUgb3RoZXIgcGFydCBpcyAmcXVvdDtuYW1lLXRhZ3MmcXVvdDsgKGUuZy4g TG9jYXRpb24sIEZ1bmN0aW9uYWwgUm9sZSwgT3duZXJzaGlwIGV0Yy4pIHdoaWNoIGFyZSBzb21l IGluZm8gdGhhdCBtaWdodCBiZSB1c2VmdWwgZm9yIGFkbWluaXN0cmF0aW9uIGJ1dCBtaWdodCBw cm9iYWJseSBjaGFuZ2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SG93IGRvIHlvdSB0aGluayBhYm91dCBpdD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7byZuYnNwOyBBZHZlcnRpc2VkIENvbW1vbiBGaWVsZHM8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7U29tZSBmaWVsZHMgaW4gdGhlIHN0cnVjdHVy ZWQgbmFtZSBtaWdodCBiZSBjb21tb24gYW1vbmcgdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO2RvbWFpbiAoZS5nLiZuYnNwOyAmcXVvdDtMb2NhdGlvbiZxdW90OyAm cXVvdDtOYW1lb2ZEb21haW4mcXVvdDspLiZuYnNwOyBUaHVzLCB0aGVzZSBwYXJ0IG9mPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3RoZSBuYW1lcyBjb3VsZCBiZSBhZHZl cnRpc2VkIHRocm91Z2ggSW50ZW50PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO0Rpc3RyaWJ1dGlvbiAoU2VjdGlvbiA0LjUpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbHQ7 amNzJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIHdvdWxkIGhvcGUgdGhhdCBpbnRlbnQgd291 bGQgYmUgc21hcnRlciBhbmQgbW9yZSBhYnN0cmFjdC4gSWYgYSBmaWVsZDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5pcyBjb21tb24sIHRoZW4gaW50ZW50IGNhbiBiZSBhYnN0cmFjdCBhbmQgdGhlIHRy YW5zbGF0aW9uIHRvIGEgY29tbW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPmZpZWxkIGlzIG11Y2gg ZWFzaWVyLiZuYnNwO0luIG90aGVyIHdvcmRzLCBiZWluZyBjb21tb24gaXMgbm90IGEgZ29vZCBy ZWFzb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+dG8gYmUgaW5jbHVkZWQgaW4gaW50ZW50LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj4mbHQ7L2pjcyZndDs8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W0Jpbmdd IEluIHRoZSBwZXJzcGVjdGl2ZSBvZiBjb25jaXNlIGNvbmNlcHQsIEkgYWxzbyB0aGluayBJbnRl bnQgbWlnaHQgbm90IGJlIHByb3BlciB0byBjYXJyeSB0aGlzIGtpbmQgb2YgaW5mby4gQnV0IElu dGVudCBEaXN0cmlidXRpb24gaXMgdGhlDQogb25seSB0aGluZyBJIGNhbiB0ZWxsIHRvIGFkdmVy dGlzZSB0aGUgY29tbW9uIGluZm8gdG8gdGhlIEFOLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+QW55IG90aGVyIGFwcHJvYWNoZXM/PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkJpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7byZuYnNwOyBTZWxmLWdlbmVyYXRlZCBGaWVsZHM8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhlIG1hbmRhdG9yeSBmaWVsZHMgU0hPVUxEIGJlIHNlbGYt Z2VuZXJhdGVkIHNvIHRoYXQgb25lPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO2RldmljZSBjb3VsZCBuYW1lIGl0c2VsZiBzdWZmaWNpZW50bHkgd2l0aG91dCBhbnkgYWR2 ZXJ0aXNlZDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtrbm93bGVkZ2Vz Ljxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaGVyZSBzaG91bGQgdmFy aW91cyBtZXRob2RzIGZvciBhIGRldmljZSB0byBleHRyYWN0L2dlbmVyYXRlIGE8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cHJvcGVyIHdvcmQgZm9yIGVhY2ggbWFuZGF0 b3J5IHNlbWFudGljIGZpZWxkcyAoZS5nLjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsmcXVvdDtEZXZpY2VUeXBlJnF1b3Q7LCAmcXVvdDtEaXN0aW5ndWlzaGVyTnVtJnF1 b3Q7KSBmcm9tIGl0cyBzZWxmLWtub3dsZWRnZS48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7RGV0 YWlsZWQgZGVzaWduIG9mIHNwZWNpZmljIG5hbWluZyBwYXR0ZXJucyBhbmQgbWV0aG9kcyBhcmUg b3V0IG9mPGJyPg0KJm5ic3A7ICZuYnNwO3Njb3BlIG9mIHRoaXMgZG9jdW1lbnQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBGcmksIEp1biAyNiwg MjAxNSBhdCAzOjI3IEFNLCBMaXViaW5nIChMZW8pICZsdDs8YSBocmVmPSJtYWlsdG86bGVvLmxp dWJpbmdAaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmxlby5saXViaW5nQGh1YXdlaS5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+SGkgRGVhciBhbGwsPGJyPg0KPGJyPg0KSSd2ZSBnZW5lcmF0 ZWQgc29tZSB0ZXh0IHJlZ2FyZGluZyB0byB0aGUgbmFtaW5nIG9mIGF1dG9ub21pYyBuZXR3b3Jr IGRldmljZXMuIFRoaXMgaXMgdG8gZml0IHRoZSBTZWN0aW9uIDQuMSBpbiB0aGUgUmVmZXJlbmNl LU1vZGVsIGRyYWZ0Ljxicj4NCkJlbG93IGlzIHRoZSBjb250ZW50IHdoaWNoIGluY2x1ZGVzIHNv bWUgcm91Z2ggaWRlYXMuIFBsZWFzZSBmZWVsIGZyZWUgdG8gY29tbWVudC48YnI+DQo8YnI+DQo0 LjEuJm5ic3A7IE5hbWluZzxicj4NCjxicj4NCjQuMS4xLiZuYnNwOyBOYW1pbmcgcmVxdWlyZW1l bnRzPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO28mbmJzcDsgUmVwcmVzZW50aW5nIGVhY2ggZGV2 aWNlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0luc2lkZSBhIGRvbWFp biwgZWFjaCBhdXRvbm9taWMgZGV2aWNlIG5lZWRzIGEgZG9tYWluIHNwZWNpZmljPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2lkZW50aWZpZXIuPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1tPcGVuIFF1ZXN0aW9uc10gQXJlIHRoZXJlIGRldmlj ZXMgdGhhdCBkb24ndCBuZWVkIG5hbWVzPyZuYnNwOyBEbzxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtBU0FzIG5lZWQgbmFtZXM/PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNw O28mbmJzcDsgVW5pcXVlbmVzczxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtUaGUgbmFtZXMgTVVTVCBOT1QgY29sbGlkZSB3aXRoaW4gb25lIGF1dG9ub21pYyBkb21haW4u PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0l0IGlzIGFjY2VwdGFibGUg dGhhdCB0aGUgbmFtZXMgaW4gZGlmZmVyZW50IGRvbWFpbnMgY29sbGlkZSw8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c2luY2UgdGhleSBjb3VsZCBiZSBkaXN0aW5ndWlz aGVkIGJ5IGRvbWFpbnMuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO28mbmJzcDsgU2VtYW50aWMg RW5jb2Rpbmc8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SXQgaXMgUkVD T01NRU5ERUQgdGhhdCB0aGUgbmFtZXMgZW5jb2RlIHNvbWUgc2VtYW50aWNzIHJhdGhlcjxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0aGFuIG1lYW5pbmdsZXNzIHN0cmlu Z3MuJm5ic3A7IFRoZSBzZW1hbnRpY3MgbWlnaHQgYmU6PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyYjNDM7Jm5ic3A7IExvY2F0aW9uPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7Jm5ic3A7IERldmljZSB0eXBlPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7Jm5ic3A7IEZ1bmN0aW9uYWwgcm9sZTxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOyZuYnNwOyBPd25lcnNoaXA8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzsmbmJzcDsgZXRjLjxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaGlzIGlzIGZvciBlYXNlIG9m IG1hbmFnZW1lbnQgY29uc2lkZXJhdGlvbiB0aGF0IG5ldHdvcms8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7YWRtaW5pc3RyYXRvcnMgY291bGQgZWFzaWx5IHJlY29nbml6 ZSB0aGUgZGV2aWNlIGRpcmVjdGx5PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO3Rocm91Z2ggdGhlIG5hbWVzLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtvJm5ic3A7IENv bnNpc3RlbmN5PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1RoZSBkZXZp Y2VzJyBuYW1pbmcgU0hPVUxEIGZvbGxvdyB0aGUgc2FtZSBwYXR0ZXJuIHdpdGhpbiBhPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RvbWFpbi48YnI+DQo8YnI+DQo0LjEu Mi4mbmJzcDsgUHJvcG9zZWQgTWVjaGFuaXNtczxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgbyZu YnNwOyBTdHJ1Y3R1cmVkIE5hbWluZyBQYXR0ZXJuPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO1RoZSB3aG9sZSBuYW1lIHN0cmluZyBjb3VsZCBiZSBkaXZpZGVkIGludG8g c2V2ZXJhbCBmaWVsZHMsPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Vh Y2ggb2Ygd2hpY2ggcmVwcmVzZW50aW5nIGEgc3BlY2lmaWMgc2VtYW50aWMgYXMgZGVzY3JpYmVk PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Fib3ZlLiZuYnNwOyBGb3Ig ZXhhbXBsZTogTG9jYXRpb24tRGV2aWNlVHlwZS1GdW5jdGlvbmFsUm9sZS08YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RGlzdGluZ3Vpc2hlck51bWJlckBOYW1lb2ZEb21h aW4uPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1RoZSBzdHJ1 Y3R1cmUgc2hvdWxkIGJlIGZsZXhpYmxlIHRoYXQgc29tZSBmaWVsZHMgYXJlIG9wdGlvbmFsLjxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtXaGVuIHRoZXNlIG9wdGlvbmFs IGZpZWxkcyBhcmUgYWRkZWQsIHRoZSBuYW1lIGNvdWxkIHN0aWxsIGJlPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3JlY29nbml6ZWQgYXMgdGhlIHByZXZpb3VzIG9uZS4m bmJzcDsgSW4gYWJvdmUgZXhhbXBsZSwgdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyZxdW90O0Rpc3Rpbmd1aXNoZXJOdW1iZXImcXVvdDsgYW5kICZxdW90O05hbWVv ZkRvbWFpbiZxdW90OyBhcmUgbWFuZGF0b3J5IHdoZXJlYXM8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7b3RoZXJzIGFyZSBvcHRpb25hbC4mbmJzcDsgQXQgaW5pdGlhbCBz dGFnZSwgdGhlIGRldmljZXMgbWlnaHQgYmU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7b25seSBjYXBhYmxlIG9mIHNlbGYtZ2VuZXJhdGluZyB0aGUgbWFuZGF0b3J5IGZp ZWxkcyBhbmQgdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90 O0RldmljZVR5cGUmcXVvdDsgYmVjYXVzZSBvZiB0aGUgbGFjayBvZiBrbm93bGVkZ2UuJm5ic3A7 IExhdGVyLCB0aGV5PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO21pZ2h0 IGhhdmUgbGVhcm5lZCB0aGUgJnF1b3Q7TG9jYXRpb24mcXVvdDsgYW5kICZxdW90O0Z1bmN0aW9u YWxSb2xlJnF1b3Q7IGFuZDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDth ZGRlZCB0aGUgZmllbGRzIGludG8gY3VycmVudCBuYW1lLiZuYnNwOyBIb3dldmVyLCB0aGUgb3Ro ZXIgZGV2aWNlczxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtjb3VsZCBz dGlsbCByZWNvZ25pemUgaXQgYWNjb3JkaW5nIHRvIHRoZSBzYW1lPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O0Rpc3Rpbmd1aXNoZXJOdW1iZXImcXVvdDsuPGJy Pg0KPGJyPg0KJm5ic3A7ICZuYnNwO28mbmJzcDsgQWR2ZXJ0aXNlZCBDb21tb24gRmllbGRzPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1NvbWUgZmllbGRzIGluIHRoZSBz dHJ1Y3R1cmVkIG5hbWUgbWlnaHQgYmUgY29tbW9uIGFtb25nIHRoZTxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkb21haW4gKGUuZy4mbmJzcDsgJnF1b3Q7TG9jYXRpb24m cXVvdDsgJnF1b3Q7TmFtZW9mRG9tYWluJnF1b3Q7KS4mbmJzcDsgVGh1cywgdGhlc2UgcGFydCBv Zjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0aGUgbmFtZXMgY291bGQg YmUgYWR2ZXJ0aXNlZCB0aHJvdWdoIEludGVudDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtEaXN0cmlidXRpb24gKFNlY3Rpb24gNC41KS48YnI+DQo8YnI+DQombmJzcDsg Jm5ic3A7byZuYnNwOyBTZWxmLWdlbmVyYXRlZCBGaWVsZHM8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7VGhlIG1hbmRhdG9yeSBmaWVsZHMgU0hPVUxEIGJlIHNlbGYtZ2Vu ZXJhdGVkIHNvIHRoYXQgb25lPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O2RldmljZSBjb3VsZCBuYW1lIGl0c2VsZiBzdWZmaWNpZW50bHkgd2l0aG91dCBhbnkgYWR2ZXJ0 aXNlZDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtrbm93bGVkZ2VzLjxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaGVyZSBzaG91bGQgdmFyaW91 cyBtZXRob2RzIGZvciBhIGRldmljZSB0byBleHRyYWN0L2dlbmVyYXRlIGE8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cHJvcGVyIHdvcmQgZm9yIGVhY2ggbWFuZGF0b3J5 IHNlbWFudGljIGZpZWxkcyAoZS5nLjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsmcXVvdDtEZXZpY2VUeXBlJnF1b3Q7LCAmcXVvdDtEaXN0aW5ndWlzaGVyTnVtJnF1b3Q7 KSBmcm9tIGl0cyBzZWxmLWtub3dsZWRnZS48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7RGV0YWls ZWQgZGVzaWduIG9mIHNwZWNpZmljIG5hbWluZyBwYXR0ZXJucyBhbmQgbWV0aG9kcyBhcmUgb3V0 IG9mPGJyPg0KJm5ic3A7ICZuYnNwO3Njb3BlIG9mIHRoaXMgZG9jdW1lbnQuPGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KQmVzdCByZWdhcmRzLDxicj4NCkJpbmc8YnI+DQo8YnI+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkFuaW1hIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpBbmltYUBpZXRmLm9yZyI+QW5pbWFAaWV0Zi5vcmc8 L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9h bmltYSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vYW5pbWE8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPGJyPg0K LS0gPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+cmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Sm9o bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_8AE0F17B87264D4CAC7DE0AA6C406F45C21D5BFDnkgeml506mbxchi_-- From nobody Mon Jun 29 18:34:53 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81B121A87E2 for ; Mon, 29 Jun 2015 18:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.511 X-Spam-Level: X-Spam-Status: No, score=-0.511 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjjo9fqOlMCY for ; Mon, 29 Jun 2015 18:34:50 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBC771A879B for ; Mon, 29 Jun 2015 18:34:50 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 05138203B0 for ; Mon, 29 Jun 2015 21:50:17 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id E2CDF63AE8; Mon, 29 Jun 2015 21:34:47 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id C6CCB637FE for ; Mon, 29 Jun 2015 21:34:47 -0400 (EDT) From: Michael Richardson To: "anima\@ietf.org" In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF7FCF@xmb-rcd-x14.cisco.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F45A6799F26@nkgeml506-mbx.china.huawei.com> <558DFE45.4050906@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C21D1AD8@nkgeml506-mbx.china.huawei.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF7FCF@xmb-rcd-x14.cisco.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Anima] Naming discussion (Section 4.1 of the Reference-Model draft) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jun 2015 01:34:52 -0000 --=-=-= Content-Type: text/plain Michael Behringer (mbehring) wrote: > In our pre-standard implementation we chose to pick names > automatically, and they are at this point clearly NOT for human > consumption. We just make sure they're unique. The admin provides the > domain name, which is the same for all devices. Were the names related in any way to serial numbers, MAC addresses, or something that could be inspected physically by a human on the outside of the device? I think that this is pretty important, particularly in a SOHO environment. > In a SOHO environment, I claim things should just happen automatically, > and the name really doesn't matter much to humans. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVZHyN4CLcPvd0N1lAQJ9swf+L45sOnrjSTxVTkgCxqyx4+jhIv/Igg9q 9xGYF0CWIDLcRVtqdMLNaZS3RrHkLhnrHoKV3J0aFlkvjEdzaVVEbUZWyKTU8OWq doeLeb1woZIC/7BPIX/HshWksKBjvoZxW8vvu3pURpAtBXIHji1hYFMoyClQNWhk yAqQtu8fSwQAtAEWSIpjCCmjL1bNM4IK+0hx6GCUB1/NTj9lz9c78A0BEb4Plh1E ru58yOROpqZ0pjeZt0lhtQlzdd1imktUJjL/ZITftn9LWLZeLt7iY3vCab5+KxCd OiXHsLVNIU9wU+s6XhHcoM7bSGC2kIsqZCvfTvVtDaAXYvitXLPPOA== =EwN/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 29 20:01:26 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C37F1B2FB4 for ; Mon, 29 Jun 2015 20:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFITR-wKLlTB for ; Mon, 29 Jun 2015 20:01:25 -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 BB71E1B2FB1 for ; Mon, 29 Jun 2015 20:01:23 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYD35966; Tue, 30 Jun 2015 03:01:21 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 30 Jun 2015 04:01:20 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.155]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Tue, 30 Jun 2015 11:01:13 +0800 From: Sheng Jiang To: "anima@ietf.org" Thread-Topic: ANIMA Primary Agenda Thread-Index: AdCy4QURFHuXrXvGT4+ARFN8rPSmbQ== Date: Tue, 30 Jun 2015 03:01:12 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927AFE6362@nkgeml512-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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "anima-chairs@tools.ietf.org" Subject: [Anima] ANIMA Primary Agenda X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jun 2015 03:01:26 -0000 SGksIGFsbCwNCg0KV2UgaGF2ZSB1cGxvYWRlZCBhIHByaW1hcnkgYWdlbmRhIGZvciBJRVRGIDkz LCB0aGUgYmxvdyBsaW5rLiBJdCBpcyBzdGlsbCBhIHN1YmplY3QgdG8gYmUgY2hhbmdlZC4gV2Ug d2lsbCBub3QgZmluYWxpemUgaXQgc3RpbGwgdGhlIFRodXJzZGF5IGJlZm9yZSB0aGUgSUVURiA5 My4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTMvYWdlbmRhL2FnZW5kYS05 My1hbmltYQ0KDQpJZiB5b3UgaGF2ZSBhbnkgbmV3IGFnZW5kYSByZXF1ZXN0cyAob3IgY2hhbmdl cyksIHBsZWFzZSBsZXQgdXMga25vdyBiZWZvcmUgMTV0aCwgSnVseSAoYW5kIGluZGljYXRlIHRo ZSBwcmVzZW50YXRpb24gbmFtZSwgZHJhZnQocyksIHByZXNlbnRlciwgdGltZSwgYW5kIGJyaWVm IGRlc2NyaXB0aW9uKS4NCg0KSW4gdGhlIGludGVyZXN0IG9mIHRpbWUsIGFsbCBwcmVzZW50YXRp b25zIHNob3VsZCBtaW5pbWl6ZSBzdGF0dXMgdXBkYXRlcyBhbmQgZm9jdXMgb24gZGlzY3Vzc2lu ZyBvdXRzdGFuZGluZyBpc3N1ZXMvbmV4dCBzdGVwcy4gVGhlIHNsaWRlcyBhcmUgZXhwZWN0ZWQg YmVmb3JlIHRoZSBJRVRGIHJlY2VwdGlvbiBvbiBTdW5kYXksIDE5dGggSnVseS4NCg0KQmVzdCBy ZWdhcmRzLA0KDQpTaGVuZyArIFRvZXJsZXNzDQo= From nobody Mon Jun 29 20:50:18 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAC9F1B3039 for ; Mon, 29 Jun 2015 20:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGbGwBlGGyhc for ; Mon, 29 Jun 2015 20:50:08 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EEA01B302E for ; Mon, 29 Jun 2015 20:50:07 -0700 (PDT) Received: by wiar9 with SMTP id r9so22355812wia.1 for ; Mon, 29 Jun 2015 20:50:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jLo+T0Z1FITZ5HYSA9fAYTJB76mDdqrzhwPVczfOmtE=; b=VgFi2mADZatp2+I6e2obzSHgMKX0F4OsK1tQp/Rce+QiC0t20vH9iW0tsn4SRhPvFv 3Ecz0tbd7ieXgUV3jx2hVx0enh9UV7MXqzjeEligbrfkJJkFTvLylnGn8hVVI35l8krU aTJECGDF+MAvyZp7yXL1nNRnFVRWq8tOIKDlpC5qtI9JJlpY9gaUDmh/SUHE2//sf0UK QCLt8qBjZ96nwqhVUFp5ljF6ZEilq3skTRPBzEHDIORA2xemNglE/iedCbO5B9GNf7Dn TcsuVulFqHccjVtsiwXtF6zDJuKsbou9d6WJMQ7d7hzRsDgRU84K1Ept/LL3w+s6qA9o rweQ== MIME-Version: 1.0 X-Received: by 10.180.182.33 with SMTP id eb1mr28075346wic.8.1435636206141; Mon, 29 Jun 2015 20:50:06 -0700 (PDT) Received: by 10.27.39.5 with HTTP; Mon, 29 Jun 2015 20:50:06 -0700 (PDT) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45C21D1AD8@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F45A6799F26@nkgeml506-mbx.china.huawei.com> <558DFE45.4050906@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C21D1AD8@nkgeml506-mbx.china.huawei.com> Date: Mon, 29 Jun 2015 20:50:06 -0700 Message-ID: From: John Strassner To: "Liubing (Leo)" , John Strassner Content-Type: multipart/alternative; boundary=047d7b62273e1808210519b41a6c Archived-At: Cc: "anima@ietf.org" Subject: Re: [Anima] Naming discussion (Section 4.1 of the Reference-Model draft) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jun 2015 03:50:12 -0000 --047d7b62273e1808210519b41a6c Content-Type: text/plain; charset=UTF-8 Hi Leo, please see inline, look for .. regards, John > On 26/06/2015 22:27, Liubing (Leo) wrote: > > Hi Dear all, > > > > I've generated some text regarding to the naming of autonomic network > > devices. This is to fit the Section 4.1 in the Reference-Model draft. > > Below is the content which includes some rough ideas. Please feel free to > > comment. > > > > 4.1. Naming > > > > 4.1.1. Naming requirements > > > > o Representing each device > > Inside a domain, each autonomic device needs a domain > > specific identifier. > > [Open Questions] Are there devices that don't need names? > > Do ASAs need names? > > > > o Uniqueness > > The names MUST NOT collide within one autonomic domain. > > It is acceptable that the names in different domains collide, > > since they could be distinguished by domains. > > Well, yes, we have a system for that, which is the DNS. Is there any reason > not to use DNS names? > > > o Semantic Encoding > > It is RECOMMENDED that the names encode some semantics > > rather than meaningless strings. The semantics might be: > > + Location > > + Device type > > + Functional role > > + Ownership > > + etc. > > This is for ease of management consideration that network > > administrators could easily recognize the device directly > > through the names. > > I'm generally against making this a formal recommendation. I understand > very well that it may be a common operational practice already, but it's quite > subject to human error [Bing] The described pattern isn't for manual configuration. I was imagining the semantic fields could be generated by the autonomic devices themselves. The name space of the semantics don't necessarily need to be standardized, the vendors could set vocabulary by themselves. Since the goal is human-readable, human could understand different vocabularies. The problem with this is the complexity of the vocabulary. There have been decades of research on standardizing vovabularies. It is still not a solved problem. However, if you want to do this, then I strongly recommend that you consider using ontologies to establish a formal lexicon (in the computational linguistics sense of the word). > and in a truly autonomic network nobody should ever > see the names anyway. [Bing] When we discussed AN management in the Reference Model draft with Michael B. We all agreed that traditional management would co-exist with autonomic management. In this sense, do you think the naming is useful for the traditional management part? Names are typically only meaningful for human users. Otherwise, objectIDs are a LOT simpler for a machine to use. I'm confused as to what the goal is here...and for the "traditional" part, I think that an autonomic network MUST NOT force any name changes on legacy environments. > Also, they would need to change autonomically > whenever the topology changes. [Bing] Yes, this would probably happen. John also mentioned the naming change is "annoying" in the other thread. So I was just thinking, maybe we could divide the name into two parts: one part is the "basic-name" which should be permanent; the other part is "name-tags" (e.g. Location, Functional Role, Ownership etc.) which are some info that might be useful for administration but might probably changes. I strongly recommend that you use metadata to gain information about a node of interest. Names are a bad way to do this. Best regards, Bing On Mon, Jun 29, 2015 at 12:13 AM, Liubing (Leo) wrote: > Hi Brian, > > Thanks for your comments, pls see inline. > > > -----Original Message----- > > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E > > Carpenter > > Sent: Saturday, June 27, 2015 9:37 AM > > To: anima@ietf.org > > Subject: Re: [Anima] Naming discussion (Section 4.1 of the > Reference-Model > > draft) > > > > On 26/06/2015 22:27, Liubing (Leo) wrote: > > > Hi Dear all, > > > > > > I've generated some text regarding to the naming of autonomic network > > devices. This is to fit the Section 4.1 in the Reference-Model draft. > > > Below is the content which includes some rough ideas. Please feel free > to > > comment. > > > > > > 4.1. Naming > > > > > > 4.1.1. Naming requirements > > > > > > o Representing each device > > > Inside a domain, each autonomic device needs a domain > > specific > > > identifier. > > > [Open Questions] Are there devices that don't need names? > > Do > > > ASAs need names? > > > > > > o Uniqueness > > > The names MUST NOT collide within one autonomic domain. > > > It is acceptable that the names in different domains collide, > > > since they could be distinguished by domains. > > > > Well, yes, we have a system for that, which is the DNS. Is there any > reason > > not to use DNS names? > > > > > o Semantic Encoding > > > It is RECOMMENDED that the names encode some semantics > > rather > > > than meaningless strings. The semantics might be: > > > + Location > > > + Device type > > > + Functional role > > > + Ownership > > > + etc. > > > This is for ease of management consideration that network > > > administrators could easily recognize the device directly > > > through the names. > > > > I'm generally against making this a formal recommendation. I understand > > very well that it may be a common operational practice already, but it's > quite > > subject to human error > [Bing] The described pattern isn't for manual configuration. I was > imagining the semantic fields could be generated by the autonomic devices > themselves. > The name space of the semantics don't necessarily need to be standardized, > the vendors could set vocabulary by themselves. Since the goal is > human-readable, human could understand different vocabularies. > > > and in a truly autonomic network nobody should ever > > see the names anyway. > [Bing] When we discussed AN management in the Reference Model draft with > Michael B. We all agreed that traditional management would co-exist with > autonomic management. > In this sense, do you think the naming is useful for the traditional > management part? > > > Also, they would need to change autonomically > > whenever the topology changes. > [Bing] Yes, this would probably happen. John also mentioned the naming > change is "annoying" in the other thread. > So I was just thinking, maybe we could divide the name into two parts: one > part is the "basic-name" which should be permanent; the other part is > "name-tags" (e.g. Location, Functional Role, Ownership etc.) which are some > info that might be useful for administration but might probably changes. > > Best regards, > Bing > > > Brian > > > > > o Consistency > > > The devices' naming SHOULD follow the same pattern within a > > > domain. > > > > > > 4.1.2. Proposed Mechanisms > > > > > > o Structured Naming Pattern > > > The whole name string could be divided into several fields, > > > each of which representing a specific semantic as described > > > above. For example: Location-DeviceType-FunctionalRole- > > > DistinguisherNumber@NameofDomain. > > > > > > The structure should be flexible that some fields are > optional. > > > When these optional fields are added, the name could still be > > > recognized as the previous one. In above example, the > > > "DistinguisherNumber" and "NameofDomain" are mandatory > > whereas > > > others are optional. At initial stage, the devices might be > > > only capable of self-generating the mandatory fields and the > > > "DeviceType" because of the lack of knowledge. Later, they > > > might have learned the "Location" and "FunctionalRole" and > > > added the fields into current name. However, the other > > devices > > > could still recognize it according to the same > > > "DistinguisherNumber". > > > > > > o Advertised Common Fields > > > Some fields in the structured name might be common among > > the > > > domain (e.g. "Location" "NameofDomain"). Thus, these > > part of > > > the names could be advertised through Intent > > > Distribution (Section 4.5). > > > > > > o Self-generated Fields > > > The mandatory fields SHOULD be self-generated so that one > > > device could name itself sufficiently without any advertised > > > knowledges. > > > There should various methods for a device to extract/generate > > a > > > proper word for each mandatory semantic fields (e.g. > > > "DeviceType", "DistinguisherNum") from its self-knowledge. > > > > > > Detailed design of specific naming patterns and methods are out of > > > scope of this document. > > > > > > > > > > > > Best regards, > > > Bing > > > > > > _______________________________________________ > > > 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 > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > -- regards, John --047d7b62273e1808210519b41a6c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Leo,

please see inli= ne, look for <jcs>..</jcs>

regards,
John


=C2=A0> On 26/06/2015 22:27, L= iubing (Leo) wrote:
=C2=A0> > Hi Dear all,
=C2=A0> >
= =C2=A0> > I've generated some text regarding to the naming of aut= onomic network
=C2=A0> > devices. This is to fit the Section 4.1 i= n the Reference-Model draft.
=C2=A0> > Below is the content which = includes some rough ideas. Please feel free to
=C2=A0> > comment.<= br>=C2=A0> >
=C2=A0> > 4.1.=C2=A0 Naming
=C2=A0> ><= br>=C2=A0> > 4.1.1.=C2=A0 Naming requirements
=C2=A0> >
= =C2=A0> >=C2=A0=C2=A0=C2=A0 o=C2=A0 Representing each device
=C2= =A0> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Inside a= domain, each autonomic device needs a domain
=C2=A0> >=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 specific identifier.
=C2= =A0> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [Open Qu= estions] Are there devices that don't need names?
=C2=A0> >=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Do ASAs need names?
= =C2=A0> >
=C2=A0> >=C2=A0=C2=A0=C2=A0 o=C2=A0 Uniqueness
= =C2=A0> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The n= ames MUST NOT collide within one autonomic domain.
=C2=A0> >=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 It is acceptable that the = names in different domains collide,
=C2=A0> >=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 since they could be distinguished by doma= ins.
=C2=A0>
=C2=A0> Well, yes, we have a system for that, whic= h is the DNS. Is there any reason
=C2=A0> not to use DNS names?
= =C2=A0>
=C2=A0> >=C2=A0=C2=A0=C2=A0 o=C2=A0 Semantic Encoding=C2=A0> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 It = is RECOMMENDED that the names encode some semantics
=C2=A0 > >=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 rather than meaningless strin= gs.=C2=A0 The semantics might be:
=C2=A0> >=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +=C2=A0 Location
=C2=A0> >=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +=C2=A0 Device type
=C2= =A0> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +=C2=A0 = Functional role
=C2=A0> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 +=C2=A0 Ownership
=C2=A0> >=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +=C2=A0 etc.
=C2=A0> >=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This is for ease of managemen= t consideration that network
=C2=A0> >=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 administrators could easily recognize the devic= e directly
=C2=A0> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 through the names.
=C2=A0>
=C2=A0> I'm generally = against making this a formal recommendation. I understand
=C2=A0> ver= y well that it may be a common operational practice already, but it's q= uite
=C2=A0> subject to human error

=C2=A0[Bing] The describe= d pattern isn't for manual configuration. I was imagining the semantic = fields could be generated by the autonomic devices themselves.
=C2=A0The= name space of the semantics don't necessarily need to be standardized,= the vendors could set vocabulary by themselves. Since the goal is human-re= adable, human could understand different vocabularies.

<jcs>The problem with this is the complexity of the vocabulary. There
have b= een decades of research on standardizing vovabularies. It
is still not a= solved problem. However, if you want to do this,
then I strongly recomm= end that you consider using ontologies to
establish a formal lexicon (in= the computational linguistics
sense of the word).
</jcs>

=C2=A0> and in a truly autonomic network nobody should ever
=C2=A0&g= t; see the names anyway.
=C2=A0[Bing] When we discussed AN management in= the Reference Model draft with Michael B. We all agreed that traditional m= anagement would co-exist with autonomic management.
=C2=A0In this sense,= do you think the naming is useful for the traditional management part?

=

<jcs>
Names are typically only meaningful for human users. Othe= rwise,
objectIDs are a LOT simpler for a machine to use. I'm confuse= d
as to what the goal is here...and for the "traditional" part= , I
think that an autonomic network MUST NOT force any name changes
o= n legacy environments.
</jcs>

=C2=A0> Also, they would ne= ed to change autonomically
=C2=A0> whenever the topology changes.
= =C2=A0[Bing] Yes, this would probably happen. John also mentioned the namin= g change is "annoying" in the other thread.
=C2=A0So I was jus= t thinking, maybe we could divide the name into two parts: one part is the = "basic-name" which should be permanent; the other part is "n= ame-tags" (e.g. Location, Functional Role, Ownership etc.) which are s= ome info that might be useful for administration but might probably changes= .

<jcs>
I strongly recommend that you use metadata to gain i= nformation
about a node of interest. Names are a bad way to do this.
= </jcs>

=C2=A0Best regards,
=C2=A0Bing


On Mon, Jun 29, 2015 at 12= :13 AM, Liubing (Leo) <leo.liubing@huawei.com> wrote:
Hi Brian,

Thanks for your comments, pls see inline.

> -----Original Message-----
> From: Anima [mailto:anima-bo= unces@ietf.org] On Behalf Of Brian E
> Carpenter
> Sent: Saturday, June 27, 2015 9:37 AM
> To: anima@ietf.org
> Subject: Re: [Anima] Naming discussion (Section 4.1 of the Reference-M= odel
> draft)
>
> On 26/06/2015 22:27, Liubing (Leo) wrote:
> > Hi Dear all,
> >
> > I've generated some text regarding to the naming of autonomic= network
> devices. This is to fit the Section 4.1 in the Reference-Model draft.<= br> > > Below is the content which includes some rough ideas. Please feel= free to
> comment.
> >
> > 4.1.=C2=A0 Naming
> >
> > 4.1.1.=C2=A0 Naming requirements
> >
> >=C2=A0 =C2=A0 o=C2=A0 Representing each device
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Inside a domain, each autonomic= device needs a domain
> specific
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 identifier.
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Open Questions] Are there devi= ces that don't need names?
> Do
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ASAs need names?
> >
> >=C2=A0 =C2=A0 o=C2=A0 Uniqueness
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The names MUST NOT collide with= in one autonomic domain.
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 It is acceptable that the names= in different domains collide,
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 since they could be distinguish= ed by domains.
>
> Well, yes, we have a system for that, which is the DNS. Is there any r= eason
> not to use DNS names?
>
> >=C2=A0 =C2=A0 o=C2=A0 Semantic Encoding
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 It is RECOMMENDED that the name= s encode some semantics
> rather
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 than meaningless strings.=C2=A0= The semantics might be:
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +=C2=A0 Location
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +=C2=A0 Device type
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +=C2=A0 Functional role
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +=C2=A0 Ownership
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +=C2=A0 etc.
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This is for ease of management = consideration that network
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 administrators could easily rec= ognize the device directly
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 through the names.
>
> I'm generally against making this a formal recommendation. I under= stand
> very well that it may be a common operational practice already, but it= 's quite
> subject to human error
[Bing] The described pattern isn't for manual configuration. I was imag= ining the semantic fields could be generated by the autonomic devices thems= elves.
The name space of the semantics don't necessarily need to be standardiz= ed, the vendors could set vocabulary by themselves. Since the goal is human= -readable, human could understand different vocabularies.

> and in a truly autonomic network nobody should ever
> see the names anyway.
[Bing] When we discussed AN management in the Reference Model draft with Mi= chael B. We all agreed that traditional management would co-exist with auto= nomic management.
In this sense, do you think the naming is useful for the traditional manage= ment part?

> Also, they would need to change autonomically
> whenever the topology changes.
[Bing] Yes, this would probably happen. John also mentioned the naming chan= ge is "annoying" in the other thread.
So I was just thinking, maybe we could divide the name into two parts: one = part is the "basic-name" which should be permanent; the other par= t is "name-tags" (e.g. Location, Functional Role, Ownership etc.)= which are some info that might be useful for administration but might prob= ably changes.

Best regards,
Bing

>=C2=A0 =C2=A0 Brian
>
> >=C2=A0 =C2=A0 o=C2=A0 Consistency
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The devices' naming SHOULD = follow the same pattern within a
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 domain.
> >
> > 4.1.2.=C2=A0 Proposed Mechanisms
> >
> >=C2=A0 =C2=A0 =C2=A0o=C2=A0 Structured Naming Pattern
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The whole name string could be = divided into several fields,
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 each of which representing a sp= ecific semantic as described
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 above.=C2=A0 For example: Locat= ion-DeviceType-FunctionalRole-
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DistinguisherNumber@NameofDomai= n.
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The structure should be flexibl= e that some fields are optional.
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 When these optional fields are = added, the name could still be
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 recognized as the previous one.= =C2=A0 In above example, the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "DistinguisherNumber"= and "NameofDomain" are mandatory
> whereas
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 others are optional.=C2=A0 At i= nitial stage, the devices might be
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 only capable of self-generating= the mandatory fields and the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "DeviceType" because = of the lack of knowledge.=C2=A0 Later, they
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 might have learned the "Lo= cation" and "FunctionalRole" and
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 added the fields into current n= ame.=C2=A0 However, the other
> devices
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 could still recognize it accord= ing to the same
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "DistinguisherNumber"= .
> >
> >=C2=A0 =C2=A0 o=C2=A0 Advertised Common Fields
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Some fields in the structured n= ame might be common among
> the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 domain (e.g.=C2=A0 "Locati= on" "NameofDomain").=C2=A0 Thus, these
> part of
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the names could be advertised t= hrough Intent
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Distribution (Section 4.5).
> >
> >=C2=A0 =C2=A0 o=C2=A0 Self-generated Fields
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The mandatory fields SHOULD be = self-generated so that one
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 device could name itself suffic= iently without any advertised
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 knowledges.
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 There should various methods fo= r a device to extract/generate
> a
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 proper word for each mandatory = semantic fields (e.g.
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "DeviceType", "D= istinguisherNum") from its self-knowledge.
> >
> >=C2=A0 =C2=A0 Detailed design of specific naming patterns and meth= ods are out of
> >=C2=A0 =C2=A0 scope of this document.
> >
> >
> >
> > Best regards,
> > Bing
> >
> > _______________________________________________
> > 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

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



--
regards,
John
--047d7b62273e1808210519b41a6c-- From nobody Mon Jun 29 21:25:24 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBB841B3079 for ; Mon, 29 Jun 2015 21:25:23 -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 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 GIAf1gVHgRNS for ; Mon, 29 Jun 2015 21:25:21 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::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 944D81B3064 for ; Mon, 29 Jun 2015 21:25:21 -0700 (PDT) Received: by pabvl15 with SMTP id vl15so115872947pab.1 for ; Mon, 29 Jun 2015 21:25:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=twydh22YO8tQAdZlUaSVK5SvNShU8rDp9xkErnKaIWE=; b=jy9veNKdSxhGUaQhBwPnJs0jC1/zpgo+bHng08sDcfIzM2dtD9u3afah4+WA26TQcn L6mT5/FqJSedbE02qXL//fHK8/g9e+ht2XesVK8qSFSqdbo+q7RrJ227z2hNWIzpz/Q8 Dr/sJlKWQz1oOY2VlSGLKywna6kRRh3CikrHQvc2eoQpKuwwVAsnQwQtqJGXLTyodtSl XiSJ1aCWOy9jkwTeeoDEWn/F2nUMYbi5SXrpFlOckKyok2UPfdtYFrMGDYKEIEhphg0r 3jrXmrngWL0CEfwU/a8LmMQd/JlyvJb2XDH0TFmu0GfVVF5NvF6IAjIO4CVmjhjo1nqa TJ0w== X-Received: by 10.70.55.199 with SMTP id u7mr39037261pdp.42.1435638321338; Mon, 29 Jun 2015 21:25:21 -0700 (PDT) Received: from ?IPv6:2406:e007:6ec9:1:28cc:dc4c:9703:6781? ([2406:e007:6ec9:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id dl5sm43803756pbd.78.2015.06.29.21.25.17 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jun 2015 21:25:20 -0700 (PDT) Message-ID: <55921A2E.4080203@gmail.com> Date: Tue, 30 Jun 2015 16:25:18 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: John Strassner , "Liubing (Leo)" References: <8AE0F17B87264D4CAC7DE0AA6C406F45A6799F26@nkgeml506-mbx.china.huawei.com> <558DFE45.4050906@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C21D1AD8@nkgeml506-mbx.china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "anima@ietf.org" Subject: [Anima] Metadata [was Naming discussion (Section 4.1 of the Reference-Model draft)] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jun 2015 04:25:23 -0000 On 30/06/2015 15:50, John Strassner wrote: ... > > Also, they would need to change autonomically > > whenever the topology changes. > [Bing] Yes, this would probably happen. John also mentioned the naming > change is "annoying" in the other thread. > So I was just thinking, maybe we could divide the name into two parts: one > part is the "basic-name" which should be permanent; the other part is > "name-tags" (e.g. Location, Functional Role, Ownership etc.) which are some > info that might be useful for administration but might probably changes. > > > I strongly recommend that you use metadata to gain information > about a node of interest. Names are a bad way to do this. > When I think about more carefully, I agree with John on this. DNS names must be unique at any one time, but they may change autonomically, and I think they could be misleading after topology changes.** It seems to me that Node Information metadata would be very suitable to be treated as a Technical Objective like any other (in Anima signaling jargon), subject to discovery and synchronization like any other complex parameter. A node's current DNS name and its current IP address(es) could be considered as part of its Node Information. I think that each node's constant ID will emerge from the security bootstrap work. ** OK, it was me who refused categorically to allow the name info.cern.ch to be assigned to a machine at MIT, when Tim Berners-Lee moved from CERN to MIT. I thought it would be very misleading, and I still think that. Brian From nobody Mon Jun 29 23:51:09 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E1F1B370D for ; Mon, 29 Jun 2015 23:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaJ5nUG7-Jge for ; Mon, 29 Jun 2015 23:51:06 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C51C1B370B for ; Mon, 29 Jun 2015 23:51:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1680; q=dns/txt; s=iport; t=1435647066; x=1436856666; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=HnnnckJX/kircq381WLDgPpaN6kQy8IZPFcQuFXt0qw=; b=SgTiXfskDdK8k6PjM/F78eT4b/GpaLdsPGfucOEeSUoUjJcmcKhaMkEI eErYDM46I8E1kSIkuU1HVfr07HD4i5qQFOmSCLC9twtcM0hxkLwRS4d48 K7BO9AVBQwlgVdEbYEv0DfZz7ovSKTLMiuBQPV6AqcIzHLD4g+If4uy81 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CnAwB7O5JV/5RdJa1RCoMRgTMGvSsJh18CgTw4FAEBAQEBAQGBCoQiAQEBAwE6RAsCAQgYChQQMiUBAQQBEgiIHwjKTwEBAQEBAQEBAQEBAQEBAQEBAQEZi0qEKSw4gxeBFAEEjBKHcgGNDocej2Mmg3pvgUaBAgEBAQ X-IronPort-AV: E=Sophos;i="5.15,375,1432598400"; d="scan'208";a="164061226" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-8.cisco.com with ESMTP; 30 Jun 2015 06:51:05 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t5U6p5sr004574 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Jun 2015 06:51:05 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.179]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Tue, 30 Jun 2015 01:51:05 -0500 From: "Michael Behringer (mbehring)" To: Michael Richardson , "anima@ietf.org" Thread-Topic: [Anima] Naming discussion (Section 4.1 of the Reference-Model draft) Thread-Index: AdCv+rXE5dOVpQhdRKmevUBqnlbbhAAqPtGAAHBTqoAACd7LoAAcmDGAAABguSA= Date: Tue, 30 Jun 2015 06:51:04 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FFA6D2@xmb-rcd-x14.cisco.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F45A6799F26@nkgeml506-mbx.china.huawei.com> <558DFE45.4050906@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C21D1AD8@nkgeml506-mbx.china.huawei.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF7FCF@xmb-rcd-x14.cisco.com> <31859.1435628087@sandelman.ca> In-Reply-To: <31859.1435628087@sandelman.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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] Naming discussion (Section 4.1 of the Reference-Model draft) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jun 2015 06:51:08 -0000 > Michael Behringer (mbehring) wrote: > > In our pre-standard implementation we chose to pick names > > automatically, and they are at this point clearly NOT for human > > consumption. We just make sure they're unique. The admin provides > the > > domain name, which is the same for all devices. >=20 > Were the names related in any way to serial numbers, MAC addresses, or > something that could be inspected physically by a human on the outside of > the device? >=20 > I think that this is pretty important, particularly in a SOHO environment= . Yes, the issue is that there can be (should be) more than one registrar, an= d we wanted a scheme where the admin really doesn't have to do ANYTHING. Th= us our scheme, where the registrar ID is the length of the MAC address:=20 The 64 bit device ID is then composed as: o 48 bit: Registrar ID, a number unique inside the domain that identifies the registrar which assigned the name to the device. A MAC address of the registrar can be used for this purpose. o 16 bit: Device ID, a number which is unique for a given registrar, to identify the device. This can be a sequentially assigned number. Each registrar keeps track of the devices it assigned. Now you have a domai= n wide unique addressing scheme, and the admin didn't need to do anything. = And the zoning / aggregation is optional, and really independent of the bas= e scheme.=20 Now my question: I think the text isn't clear enough on this yet - can you = let me know how we can make it clearer, or what wasn't clear when you first= read it.=20 Michael From nobody Tue Jun 30 04:50:35 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98A661A8A12 for ; Tue, 30 Jun 2015 04:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UyHbmht8kE7p for ; Tue, 30 Jun 2015 04:50:32 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BDDF1A8A0F for ; Tue, 30 Jun 2015 04:50:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4914; q=dns/txt; s=iport; t=1435665032; x=1436874632; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=WAgaHWcmSrGi/mpIlRqkVldD4P+8gxnUn+A9+qsuXHI=; b=d0Lz1Cw7dQG/5U8ys+GxsTeOgylUuS+JnK6jtgTQnruNcSsD+3/t4HUz +BjS6CjZH/VCfM7UsQBR4Ef++guMp8uBiCIivUg6lf0iuCMCfz0ffvoni 7Pul5OzdY3A4BkjEBB1JtLQPdgo4Cv3QbmMOofN8+yCZNEbACKKp3YIUy k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DFAwDHgZJV/5ldJa1bgxFUXwaDGLogCYFrhXQCHIEtOBQBAQEBAQEBgQqEIgEBAQQjET4FDgQCAQgRBAEBAwIGCxIDAgICMBQBBgEBBQMCBBMIE4gUDbNqlngBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGKKYQtBwEBHzgGBIJeL4EUBYwUh3MBhFmIN0SDTopuiAMmg3pvgQMJFyOBAgEBAQ X-IronPort-AV: E=Sophos;i="5.15,377,1432598400"; d="scan'208";a="5822146" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 30 Jun 2015 11:50:31 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t5UBoVKh023585 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 30 Jun 2015 11:50:31 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.179]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Tue, 30 Jun 2015 06:50:31 -0500 From: "Michael Behringer (mbehring)" To: "anima@ietf.org" Thread-Topic: New Version Notification for draft-behringer-anima-reference-model-03.txt Thread-Index: AQHQsxwuKj73LE2R9UWEaoPrt/tf8p3E0jjQ Date: Tue, 30 Jun 2015 11:50:30 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FFABA6@xmb-rcd-x14.cisco.com> References: <20150630100437.21543.5089.idtracker@ietfa.amsl.com> In-Reply-To: <20150630100437.21543.5089.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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: [Anima] FW: New Version Notification for draft-behringer-anima-reference-model-03.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jun 2015 11:50:34 -0000 VGhpcyBpcyB0aGUgbGF0ZXN0IHZlcnNpb24sIHRha2luZyBpbnRvIGFjY291bnQgYWxsIHRoZSB0 ZXh0IEkgcmVjZWl2ZWQgKG9yIHRoYXQgd2FzIGRpcmVjdGx5IGFkZGVkIG9uIGdpdGh1YikuIA0K DQpMb29rIGF0IHRoZSBkZWx0YTogDQpodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDE9 ZHJhZnQtYmVocmluZ2VyLWFuaW1hLXJlZmVyZW5jZS1tb2RlbC0wMiZ1cmwyPWRyYWZ0LWJlaHJp bmdlci1hbmltYS1yZWZlcmVuY2UtbW9kZWwtMDMNCg0KVGhlIGltcG9ydGFudCBjaGFuZ2VzIGFy ZTogDQoNCi0gdGhlIG5ldyBzZWN0aW9uIG9uIG5hbWluZywgZnJvbSBCaW5nLiANCi0gdGV4dCBm b3IgdGhlIHNlY3Rpb25zIG9uIGRpc2NvdmVyeSwgc2lnbmFsbGluZywgYW5kIGludGVudCBkaXN0 cmlidXRpb24uIA0KLSBJIG1vdmVkIHRoZSBlbnRpcmUgZHJhZnQtYmVocmluZ2VyLWF1dG9ub21p Yy1hZGRyZXNzaW5nIGludG8gdGhlIHJlZmVyZW5jZSBtb2RlbC4gU2hlbmcgcG9pbnRlZCBvdXQg dGhhdCB0aGUgYWRkcmVzc2luZyBkcmFmdCBpc24ndCBhIGNoYXJ0ZXJlZCBXRyBkcmFmdCwgYW5k IGhlIHN1Z2dlc3RlZCB0byBtZXJnZSB3aXRoIGFuIGV4aXN0aW5nIGRvY3VtZW50LCBpZiB3ZSB3 YW50IHRvIGRpc2N1c3MgaXQgaW4gUHJhZ3VlLiANCi0gSSBzaG9ydGVuZWQgdGhlIEFDUCBzZWN0 aW9uIChhIGJpdCksIGJlY2F1c2UgdGhhdCB0ZXh0IHNob3VsZCByZWFsbHkgZ28gaW50byB0aGUg QUNQIGRyYWZ0LiAodXBkYXRlIG9uIHRoYXQgb25lLCBzaG9ydGx5ISkNCi0gc2VjdGlvbnMgNy41 LiwgNy42LiwgNy43LiBhcmUgbmV3IGZyb20gSm9obi4gDQotIHNlY3Rpb24gNy40IGlzIG92ZXJs YXBwaW5nIHNvbWV3aGF0IHdpdGggdGhlIG5ldyBzZWN0aW9uIDcuNSBmcm9tIEpvaG4sIHNob3Vs ZCBiZSBtZXJnZWQsIGJ1dCBJIGRpZG4ndCBnZXQgdG8gdGhhdCB5ZXQuIA0KLSBJIHRvb2sgb3V0 IHRoZSBvbGQgc2VjdGlvbiA5IChIeWJyaWQgQXBwcm9hY2ggd2l0aCBOb24tQXV0b25vbWljIEZ1 bmN0aW9ucyAoKikpLCBzaW5jZSB0aGF0IGlzIHJlYWxseSBjb3ZlcmVkIGluIFJGQzc1NzUuIA0K DQpOb3RlIHRoYXQgYWxsIG5ldyBzZWN0aW9ucyBhcmUgZm9yIGRpc2N1c3Npb24sIHRoZXkgZG8g bm90IHJlcHJlc2VudCBjb25zZW5zdXMgYXQgdGhpcyBwb2ludC4gU29tZSBkaXNjdXNzaW9ucyBh cmUgbm90IHlldCByZWZsZWN0ZWQgaW4gdGhlIGRvY3VtZW50Lg0KDQpPbiBnaXRodWIgKGh0dHBz Oi8vZ2l0aHViLmNvbS9tYmVocmluZy9BTklNQS1SZWZlcmVuY2UtTW9kZWwpIEkgaGF2ZSBkZWxl dGVkICotMDMgKHhtbCBhbmQgdHh0KSwgYmVjYXVzZSB0aG9zZSBhcmUgbm93IG9uIHRvb2xzLmll dGYub3JnLiB0aGUgeG1sIGFuZCB0eHQgZmlsZSB3aXRob3V0IHZlcnNpb24gbnVtYmVyIGFyZSBp ZGVudGljYWwgdG8gdGhlIHBvc3RlZCB2ZXJzaW9uLiANCkFsbCBuZXcgY2hhbmdlczogdG8gZHJh ZnQtYmVocmluZ2VyLWFuaW1hLXJlZmVyZW5jZS1tb2RlbC54bWwsIHBsZWFzZSENCg0KRnVydGhl ciBjb250cmlidXRpb25zOiANCi0gRWl0aGVyIG1haWwgbWUgKHRleHQgKndpdGgqIFhNTCB0YWdz LCBwbGVhc2UhKSANCi0gT3IgY29udHJpYnV0ZSBkaXJlY3RseSBvbiBnaXRodWIgDQoNClRoYW5r cyB0byBhbGwgd2hvIGNvbnRyaWJ1dGVkISBMb29raW5nIGZvcndhcmQgdG8gYSBsaXZlbHkgZGlz Y3Vzc2lvbiBpbiBQcmFndWUuDQpNaWNoYWVsDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmddDQo+IFNlbnQ6IDMwIEp1bmUgMjAxNSAxMjowNQ0KPiBUbzogTGF1cmVu dCBDaWF2YWdsaWE7IEplZmVyc29uIENhbXBvcyBOb2JyZTsgQmluZyBMaXU7IFRvZXJsZXNzIEVj a2VydA0KPiAoZWNrZXJ0KTsgTWljaGFlbCBCZWhyaW5nZXIgKG1iZWhyaW5nKTsgQnJpYW4gRS4g Q2FycGVudGVyOyBMYXVyZW50DQo+IENpYXZhZ2xpYTsgSm9obiBTdHJhc3NuZXI7IE1pY2hhZWwg QmVocmluZ2VyIChtYmVocmluZyk7IEJpbmcgTGl1OyBCcmlhbg0KPiBDYXJwZW50ZXI7IEplZmVy c29uIENhbXBvcyBOb2JyZTsgVG9lcmxlc3MgRWNrZXJ0IChlY2tlcnQpOyBKb2huIFN0cmFzc25l cg0KPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWJlaHJpbmdl ci1hbmltYS1yZWZlcmVuY2UtDQo+IG1vZGVsLTAzLnR4dA0KPiANCj4gDQo+IEEgbmV3IHZlcnNp b24gb2YgSS1ELCBkcmFmdC1iZWhyaW5nZXItYW5pbWEtcmVmZXJlbmNlLW1vZGVsLTAzLnR4dA0K PiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IE1pY2hhZWwgSC4gQmVocmluZ2Vy IGFuZCBwb3N0ZWQgdG8gdGhlDQo+IElFVEYgcmVwb3NpdG9yeS4NCj4gDQo+IE5hbWU6CQlkcmFm dC1iZWhyaW5nZXItYW5pbWEtcmVmZXJlbmNlLW1vZGVsDQo+IFJldmlzaW9uOgkwMw0KPiBUaXRs ZToJCUEgUmVmZXJlbmNlIE1vZGVsIGZvciBBdXRvbm9taWMgTmV0d29ya2luZw0KPiBEb2N1bWVu dCBkYXRlOgkyMDE1LTA2LTMwDQo+IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+IFBh Z2VzOgkJMjkNCj4gVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1iZWhyaW5nZXItYW5pbWEtDQo+IHJlZmVyZW5jZS1tb2RlbC0wMy50eHQN Cj4gU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWJlaHJpbmdlci1hbmltYS0NCj4gcmVmZXJlbmNlLW1vZGVsLw0KPiBIdG1saXplZDogICAgICAg aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJlaHJpbmdlci1hbmltYS1yZWZlcmVu Y2UtDQo+IG1vZGVsLTAzDQo+IERpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9y ZmNkaWZmP3VybDI9ZHJhZnQtYmVocmluZ2VyLWFuaW1hLQ0KPiByZWZlcmVuY2UtbW9kZWwtMDMN Cj4gDQo+IEFic3RyYWN0Og0KPiAgICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIHJlZmVyZW5j ZSBtb2RlbCBmb3IgQXV0b25vbWljIE5ldHdvcmtpbmcuDQo+ICAgIFRoZSBnb2FsIGlzIHRvIGRl ZmluZSBob3cgdGhlIHZhcmlvdXMgZWxlbWVudHMgaW4gYW4gYXV0b25vbWljDQo+ICAgIGNvbnRl eHQgd29yayB0b2dldGhlciwgdG8gZGVzY3JpYmUgdGhlaXIgaW50ZXJmYWNlcyBhbmQgcmVsYXRp b25zLg0KPiAgICBXaGlsZSB0aGUgZG9jdW1lbnQgaXMgd3JpdHRlbiBhcyBnZW5lcmFsbHkgYXMg cG9zc2libGUsIHRoZSBpbml0aWFsDQo+ICAgIHNvbHV0aW9ucyBhcmUgbGltaXRlZCB0byB0aGUg Y2hhcnRlcmVkIHNjb3BlIG9mIHRoZSBXRy4NCj4gDQo+IA0KPiANCj4gDQo+IFBsZWFzZSBub3Rl IHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+ IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls YWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Tue Jun 30 05:06:39 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 163FE1A8A6D for ; Tue, 30 Jun 2015 05:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N58ufmQ5hpzn for ; Tue, 30 Jun 2015 05:06:36 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A287A1A8A17 for ; Tue, 30 Jun 2015 05:06:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3373; q=dns/txt; s=iport; t=1435665997; x=1436875597; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tRVWb3ygulV6B95m0ZW9ca7/q2ye/hYaZlwoYG2Rfzc=; b=nEQS90MuV8RS5DyXEmdqdLHzx/lPS2+yr69beSWszgR8ry8R2COveYCy LzxyVaCrIzIRWyq6gpcaBXz3iJWILFMYeDFVfWOUqbN+GLFsItTxfcSrH BCy/OI33LEj2jzYBdkUGS2mN1SSOEg//POIpEnSjR5KPgfvYTxkTbzSSN s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C8AwBHhZJV/5FdJa1bgxFUXwa9OQmBXQyFdgKBSjgUAQEBAQEBAYEKhCIBAQEEAQEBNzICCAMMBAIBCBEEAQEBChQJBycLFAkIAgQBDQUIiCcNyTQBAQEBAQEBAQEBAQEBAQEBAQEBAQEXi0qEVTEHBoMRgRQFjBSHcwGEWYh7lj8mgj2BPW8BgUWBAgEBAQ X-IronPort-AV: E=Sophos;i="5.15,377,1432598400"; d="scan'208";a="11465775" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-2.cisco.com with ESMTP; 30 Jun 2015 12:06:36 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t5UC6Ze9012350 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Jun 2015 12:06:35 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.179]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Tue, 30 Jun 2015 07:06:35 -0500 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , John Strassner , "Liubing (Leo)" Thread-Topic: [Anima] Metadata [was Naming discussion (Section 4.1 of the Reference-Model draft)] Thread-Index: AQHQsuzLG2m+QuqUtke4ci/pPDBQzp3E8LGQ Date: Tue, 30 Jun 2015 12:06:34 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FFAC01@xmb-rcd-x14.cisco.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F45A6799F26@nkgeml506-mbx.china.huawei.com> <558DFE45.4050906@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C21D1AD8@nkgeml506-mbx.china.huawei.com> <55921A2E.4080203@gmail.com> In-Reply-To: <55921A2E.4080203@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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: Cc: "anima@ietf.org" Subject: Re: [Anima] Metadata [was Naming discussion (Section 4.1 of the Reference-Model draft)] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jun 2015 12:06:39 -0000 Agree with the below sentiments:=20 AN should assign a permanent node name to a node, which is, from an AN pers= pective independent of its current role, location and function. This is ind= ependent of the "hostname" used today, which remains as is, and an operator= can do with that one what he likes. To encode role, location, function, et= c, we use other metadata.=20 The AN node name will be part of the node certificate, which is permanent. = Also because of this, there should be no role, function or location encoded= into that name.=20 Now, up to here, I believe we're reaching a consensus. Right?=20 The following statement will undoubtedly raise interesting debates: I claim= the address assignment should follow the same principles, such that a node= IP address is permanent, and essentially an identifier. Now, we all know t= hat sometimes aggregation is needed, for that we brought in the "zones". Bu= t the addressing scheme now in the reference doc (https://tools.ietf.org/ht= ml/draft-behringer-anima-reference-model-03#section-4.2) is meant to allow = for exactly this: The "device ID" remains constant, as an identifier, the z= one ID can be used to aggregate, if needed. Thoughts?=20 Michael=20 > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E > Carpenter > Sent: 30 June 2015 06:25 > To: John Strassner; Liubing (Leo) > Cc: anima@ietf.org > Subject: [Anima] Metadata [was Naming discussion (Section 4.1 of the > Reference-Model draft)] >=20 > On 30/06/2015 15:50, John Strassner wrote: > ... > > > Also, they would need to change autonomically > whenever the > > topology changes. > > [Bing] Yes, this would probably happen. John also mentioned the > > naming change is "annoying" in the other thread. > > So I was just thinking, maybe we could divide the name into two > > parts: one part is the "basic-name" which should be permanent; the > > other part is "name-tags" (e.g. Location, Functional Role, Ownership > > etc.) which are some info that might be useful for administration but > might probably changes. > > > > > > I strongly recommend that you use metadata to gain information about a > > node of interest. Names are a bad way to do this. > > >=20 > When I think about more carefully, I agree with John on this. > DNS names must be unique at any one time, but they may change > autonomically, and I think they could be misleading after topology > changes.** >=20 > It seems to me that Node Information metadata would be very suitable to > be treated as a Technical Objective like any other (in Anima signaling > jargon), subject to discovery and synchronization like any other complex > parameter. A node's current DNS name and its current IP > address(es) could be considered as part of its Node Information. >=20 > I think that each node's constant ID will emerge from the security bootst= rap > work. >=20 > ** OK, it was me who refused categorically to allow the name info.cern.ch > to be assigned to a machine at MIT, when Tim Berners-Lee moved from > CERN to MIT. I thought it would be very misleading, and I still think tha= t. >=20 > Brian >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Tue Jun 30 10:03:57 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0521B3208 for ; Tue, 30 Jun 2015 10:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HiAo-qutN13t for ; Tue, 30 Jun 2015 10:03:29 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 326241B3203 for ; Tue, 30 Jun 2015 10:03:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3186; q=dns/txt; s=iport; t=1435683809; x=1436893409; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=wFtuKfG9cUMDO/pCOtmL3x17nnJz3JiYejrzB7lwFn8=; b=h1Ho3WZ9k4cG0zZL+zmnNiASw3I0yWiOGxcLj1vAej5pTtTqGH5lZ0k1 92E7oD4Q86ZtJ9YZc/3vcTNVcyVu4+6Q9n90VeDzRayeYdLSHbtoIAHqN xGKsjilOj/iRFNFlmaUc5i2etWZrt6F2ymHUVsF3s5fiDn4308v8Uhk7/ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D1AwBhy5JV/51dJa1bgxFUXwaDGLolCYFrhXgCHIE0OBQBAQEBAQEBgQqEIgEBAQQjEUMOBAIBCBEEAQEDAgYLEgMCAgIwFAEGAQEFAwIEEwiIJw2xWZcEAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhiimEVTgGBIJeL4EUBYwUh3MBhFmIN0SDTpJxJoI9gT1vgUaBAgEBAQ X-IronPort-AV: E=Sophos;i="5.15,379,1432598400"; d="scan'208";a="5908280" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 30 Jun 2015 17:03:28 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t5UH3SCx004432 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 30 Jun 2015 17:03:28 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.179]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Tue, 30 Jun 2015 12:03:28 -0500 From: "Michael Behringer (mbehring)" To: "anima@ietf.org" Thread-Topic: New Version Notification for draft-behringer-anima-autonomic-control-plane-03.txt Thread-Index: AQHQs1X+T456AwbJB0SHno1VDhJcZp3FRiKQ Date: Tue, 30 Jun 2015 17:03:27 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FFB02B@xmb-rcd-x14.cisco.com> References: <20150630165807.9689.5171.idtracker@ietfa.amsl.com> In-Reply-To: <20150630165807.9689.5171.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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: [Anima] FW: New Version Notification for draft-behringer-anima-autonomic-control-plane-03.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jun 2015 17:03:39 -0000 VGhpcyB2ZXJzaW9uIHRha2VzIGludG8gYWNjb3VudCB0aGUgbGF0ZXN0IGRpc2N1c3Npb25zLCBp bmNsdWRlcyB0aGUgcmVxdWlyZW1lbnRzLCBldGMuIFNvLCBJIHRoaW5rIHdlJ3JlIGEgc3RlcCBm dXJ0aGVyIGluIGNvbW1vbiB1bmRlcnN0YW5kaW5nIG9mIHRoZSBBQ1AuIA0KDQpUaGUgbWFpbiBq b2IgSSBzZWUgY29taW5nIHVwIChkaWRuJ3QgZ2V0IHJvdW5kIGRvaW5nIHRoaXMgeWV0KSBpcyB0 byBvdXRsaW5lIHRoZSBpbXBsZW1lbnRhdGlvbiBjaG9pY2VzLCBtb3N0IG5vdGFibHksIHRoZSBz ZXBhcmF0ZSBBQ1AgKFZSRiBiYXNlZCkgb3IgdGhlICJkYXRhIHBsYW5lIEFDUCIuIA0KDQpGZWVk YmFjayB3ZWxjb21lISANCk1pY2hhZWwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmddDQo+IFNlbnQ6IDMwIEp1bmUgMjAxNSAxODo1OA0KPiBUbzogQmFsYWppIEIgTCAo YmxiYWxhamkpOyBNaWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpOyBUb2VybGVzcyBFY2tlcnQN Cj4gKGVja2VydCk7IFN0ZWludGhvciBCamFybmFzb24gKHNiamFybmFzKTsgTWljaGFlbCBCZWhy aW5nZXIgKG1iZWhyaW5nKTsNCj4gVG9lcmxlc3MgRWNrZXJ0IChlY2tlcnQpOyBTdGVpbnRob3Ig Qmphcm5hc29uIChzYmphcm5hcyk7IEJhbGFqaSBCIEwgKGJsYmFsYWppKQ0KPiBTdWJqZWN0OiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWJlaHJpbmdlci1hbmltYS1hdXRvbm9t aWMtDQo+IGNvbnRyb2wtcGxhbmUtMDMudHh0DQo+IA0KPiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJ LUQsIGRyYWZ0LWJlaHJpbmdlci1hbmltYS1hdXRvbm9taWMtY29udHJvbC1wbGFuZS0NCj4gMDMu dHh0DQo+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTWljaGFlbCBILiBCZWhy aW5nZXIgYW5kIHBvc3RlZCB0byB0aGUNCj4gSUVURiByZXBvc2l0b3J5Lg0KPiANCj4gTmFtZToJ CWRyYWZ0LWJlaHJpbmdlci1hbmltYS1hdXRvbm9taWMtY29udHJvbC1wbGFuZQ0KPiBSZXZpc2lv bjoJMDMNCj4gVGl0bGU6CQlBbiBBdXRvbm9taWMgQ29udHJvbCBQbGFuZQ0KPiBEb2N1bWVudCBk YXRlOgkyMDE1LTA2LTMwDQo+IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+IFBhZ2Vz OgkJMTgNCj4gVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC1iZWhyaW5nZXItYW5pbWEtDQo+IGF1dG9ub21pYy1jb250cm9sLXBsYW5lLTAz LnR4dA0KPiBTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtYmVocmluZ2VyLWFuaW1hLQ0KPiBhdXRvbm9taWMtY29udHJvbC1wbGFuZS8NCj4gSHRt bGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iZWhyaW5nZXIt YW5pbWEtYXV0b25vbWljLQ0KPiBjb250cm9sLXBsYW5lLTAzDQo+IERpZmY6ICAgICAgICAgICBo dHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtYmVocmluZ2VyLWFuaW1hLQ0K PiBhdXRvbm9taWMtY29udHJvbC1wbGFuZS0wMw0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgIEF1dG9u b21pYyBmdW5jdGlvbnMgbmVlZCBhIGNvbnRyb2wgcGxhbmUgdG8gY29tbXVuaWNhdGUsIHdoaWNo DQo+ICAgIGRlcGVuZHMgb24gc29tZSBhZGRyZXNzaW5nIGFuZCByb3V0aW5nLiAgVGhpcyBBdXRv bm9taWMgQ29udHJvbCBQbGFuZQ0KPiAgICBzaG91bGQgaWRlYWxseSBiZSBzZWxmLW1hbmFnaW5n LCBhbmQgYXMgaW5kZXBlbmRlbnQgYXMgcG9zc2libGUgb2YNCj4gICAgY29uZmlndXJhdGlvbi4g IE9uZSBhcHBsaWNhdGlvbiBpcyBhICJ2aXJ0dWFsIG91dCBvZiBiYW5kIGNoYW5uZWwiDQo+ICAg IGZvciBjb21tdW5pY2F0aW9ucyBvdmVyIGEgbmV0d29yayB0aGF0IGlzIG5vdCBjb25maWd1cmVk IG9yIG1pcy0NCj4gICAgY29uZmlndXJlZC4gIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHJlcXVp cmVtZW50cyBhbmQgaW1wbGVtZW50YXRpb24NCj4gICAgb3B0aW9ucyBmb3IgYW4gIkF1dG9ub21p YyBDb250cm9sIFBsYW5lIi4NCj4gDQo+IA0KPiANCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+IHN1Ym1pc3Np b24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0 b29scy5pZXRmLm9yZy4NCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Tue Jun 30 17:02:15 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 569A81B2BA7 for ; Tue, 30 Jun 2015 17:02:14 -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 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 TT6Vz7xvlHvE for ; Tue, 30 Jun 2015 17:02:12 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::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 2152B1B2B93 for ; Tue, 30 Jun 2015 17:02:12 -0700 (PDT) Received: by pdcu2 with SMTP id u2so14684065pdc.3 for ; Tue, 30 Jun 2015 17:02:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7YaJYIolNPw1v1UUg7Xp9uQ/KP24rDHJXLzNj+vhX34=; b=si/OzbbU2gTFIOkS4h9ikVNdCJrabusVA+ImVPGd60lsHqtd2E/IR/jzxdT8kCIXih Uzj+B8Ar9yTGjBBujSuK+Bshx9IPsNM/jmAfyedRKXX0dlLFIi64/QIG2itQmdf+PB+A Nj6w7w0ZwWUkFMuUJVoV76ZalilHKWvSpEq+gO9/PC47cTxjzKyKb73vhLQZeun+BmrG dHh07XzIcgUQIzqr+EqjaSQDu+vZyiP4H+BtZ8Fn3UT8xcjzgWJnAqULJ7lsJyj56XyD z2ybn5LFLcJq9Xy7GKilQ9iRkB/7d4cz9wEbMSk4Dz8kkU7fPJpwmvkQLOS+p1SodmqR 3I5A== X-Received: by 10.70.103.200 with SMTP id fy8mr47958368pdb.136.1435708932157; Tue, 30 Jun 2015 17:02:12 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by mx.google.com with ESMTPSA id k5sm63105pdb.53.2015.06.30.17.02.08 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jun 2015 17:02:10 -0700 (PDT) Message-ID: <55932E02.60906@gmail.com> Date: Wed, 01 Jul 2015 12:02:10 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , John Strassner , "Liubing (Leo)" References: <8AE0F17B87264D4CAC7DE0AA6C406F45A6799F26@nkgeml506-mbx.china.huawei.com> <558DFE45.4050906@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C21D1AD8@nkgeml506-mbx.china.huawei.com> <55921A2E.4080203@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FFAC01@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FFAC01@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "anima@ietf.org" Subject: Re: [Anima] Metadata [was Naming discussion (Section 4.1 of the Reference-Model draft)] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jul 2015 00:02:14 -0000 On 01/07/2015 00:06, Michael Behringer (mbehring) wrote: > Agree with the below sentiments: > > AN should assign a permanent node name to a node, which is, from an AN perspective independent of its current role, location and function. This is independent of the "hostname" used today, which remains as is, and an operator can do with that one what he likes. To encode role, location, function, etc, we use other metadata. > > The AN node name will be part of the node certificate, which is permanent. Also because of this, there should be no role, function or location encoded into that name. > > Now, up to here, I believe we're reaching a consensus. Right? > > The following statement will undoubtedly raise interesting debates: I claim the address assignment should follow the same principles, such that a node IP address is permanent, and essentially an identifier. I think you'll need to define "permanent". If there is some kind of major event (like a long power cut, for example) you might end up with a complete cold start of the network and re-creation of the ACP, and then I think renumbering would probably occur. But certainly the address should not change as a routine matter. > Now, we all know that sometimes aggregation is needed, for that we brought in the "zones". But the addressing scheme now in the reference doc (https://tools.ietf.org/html/draft-behringer-anima-reference-model-03#section-4.2) is meant to allow for exactly this: The "device ID" remains constant, as an identifier, the zone ID can be used to aggregate, if needed. Thoughts? For large networks, yes. Small networks can flat-route anyway. Brian > > Michael > >> -----Original Message----- >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E >> Carpenter >> Sent: 30 June 2015 06:25 >> To: John Strassner; Liubing (Leo) >> Cc: anima@ietf.org >> Subject: [Anima] Metadata [was Naming discussion (Section 4.1 of the >> Reference-Model draft)] >> >> On 30/06/2015 15:50, John Strassner wrote: >> ... >>> > Also, they would need to change autonomically > whenever the >>> topology changes. >>> [Bing] Yes, this would probably happen. John also mentioned the >>> naming change is "annoying" in the other thread. >>> So I was just thinking, maybe we could divide the name into two >>> parts: one part is the "basic-name" which should be permanent; the >>> other part is "name-tags" (e.g. Location, Functional Role, Ownership >>> etc.) which are some info that might be useful for administration but >> might probably changes. >>> >>> >>> I strongly recommend that you use metadata to gain information about a >>> node of interest. Names are a bad way to do this. >>> >> >> When I think about more carefully, I agree with John on this. >> DNS names must be unique at any one time, but they may change >> autonomically, and I think they could be misleading after topology >> changes.** >> >> It seems to me that Node Information metadata would be very suitable to >> be treated as a Technical Objective like any other (in Anima signaling >> jargon), subject to discovery and synchronization like any other complex >> parameter. A node's current DNS name and its current IP >> address(es) could be considered as part of its Node Information. >> >> I think that each node's constant ID will emerge from the security bootstrap >> work. >> >> ** OK, it was me who refused categorically to allow the name info.cern.ch >> to be assigned to a machine at MIT, when Tim Berners-Lee moved from >> CERN to MIT. I thought it would be very misleading, and I still think that. >> >> Brian >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > From nobody Tue Jun 30 17:18:49 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 699511B2CC7 for ; Tue, 30 Jun 2015 17:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLnBhHcG6lza for ; Tue, 30 Jun 2015 17:18:44 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::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 822E81B2CC5 for ; Tue, 30 Jun 2015 17:18:43 -0700 (PDT) Received: by wgck11 with SMTP id k11so22988278wgc.0 for ; Tue, 30 Jun 2015 17:18:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NBdJ1DpgzGJ8deABeoFIWFjByQwa9giNHguBsIfd9fw=; b=eNWovdxUSQvZ/FvNtgU8/9iXp+kR7/SR4V+SlW6e57I/knqo+u89JllvJebf5vO1Ug rojQPNwycpVqOY5qpGGU+LelZK5sCNu7SWFTqJyerAz5i6bL7Anaq+gaYaNi292td+1+ /rtXv/Yq4HpT7TgfjCdI1QN83JwTgo1kwlbZPc6S2wu30i3uGZtNsnuTt94bRvp63hRq OKLeeqZgvlMKXn4ExQ9h2XVM9XK2uKHwzrlR4KamkyDwgOSOsv4mLiNCFS6zWMhcKiXq Ce8jviD79qE1+Q8jgukFsi22j67yKCc5qAjQQ1meTYTCc0Ep+4IimoD/t8PvMymzJq8u bzHQ== MIME-Version: 1.0 X-Received: by 10.180.72.177 with SMTP id e17mr815398wiv.12.1435709922724; Tue, 30 Jun 2015 17:18:42 -0700 (PDT) Received: by 10.27.39.5 with HTTP; Tue, 30 Jun 2015 17:18:42 -0700 (PDT) In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF7FCF@xmb-rcd-x14.cisco.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F45A6799F26@nkgeml506-mbx.china.huawei.com> <558DFE45.4050906@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C21D1AD8@nkgeml506-mbx.china.huawei.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF7FCF@xmb-rcd-x14.cisco.com> Date: Tue, 30 Jun 2015 17:18:42 -0700 Message-ID: From: John Strassner To: "Michael Behringer (mbehring)" , John Strassner Content-Type: multipart/alternative; boundary=f46d043c7c16f1cde30519c54356 Archived-At: Cc: "anima@ietf.org" , "Liubing \(Leo\)" Subject: Re: [Anima] Naming discussion (Section 4.1 of the Reference-Model draft) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jul 2015 00:18:48 -0000 --f46d043c7c16f1cde30519c54356 Content-Type: text/plain; charset=UTF-8 Hi Michael, et al., I'm confused as to why there is a question. One of the principal goals of autonomics is to reduce the administrative burden on humans. When I combine this with the WG's desire to use "intent", then why would a name be necessary at all? Why wouldn't the preferred model be to talk in terms of roles or user-friendly aliases (e.g., MyInternetGateway)? Do I really need to call the AAA server that I use 'Fred'? :-) And, with all due respect, naming a device WiringCloset3Rack2Chassis7-Router-InternetGateway... doesn't really help (and that's assuming you could get everyone to agree on a taxonomy like that). Plus, legacy environments aren't going to care how we name our devices - they will have their own names, and will also don't care if we like them or not. This is why I keep asking why naming is important. If you are using a name for locating something (boo! hiss!), then you SHOULD instead use metadata, which can do a much more thorough job and give you many more options. If you are using a name for programming something ((boo!)^2) then you SHOULD instead be using a much richer means to identify the (hint) object that you are trying to interact with. If you are using it for something else, then let's focus on that and see why it is needed. BTW, I'm obviously guessing at the first two use cases, and am hoping that I am wrong on both. :-) I have nothing against names, but I would rather use the right tool for the right job. In addition, as I said previously, if this really is an autonomic system, and the name changes, what good is it? Wouldn't it be better to describe the role the object plays (i.e., the role-object pattern), or metadata that can be used to hunt the little bugger down? Both of these are independent of change, since they describe behavior of the thing, and not an (arbitrary) name that was tacked on to the thing. > But I think, from the ANIMA point of view, we should say: During > the enrolment process the admin can provide a name for a > device (and a domain name, btw). If a name is provided, it is used > (in the certificate for example). If not, a unique, autonomically > created name is used. We need an algorithm that creates the > autonomic name. (I tried to explain that in the addressing doc, > but it was clearly not clear enough). Agreed, but I would argue that this should be automatically created not autonomically created. :-) > Personally, I think we shouldn't define how the name is > constructed, if the operator puts one in. Completely agree. The operator will ignore us anyway. :-) regards, John On Mon, Jun 29, 2015 at 12:38 AM, Michael Behringer (mbehring) < mbehring@cisco.com> wrote: > I guess we need to take a step back here. There is indeed a big question > on whether naming discussed in this framework is meant for "human" > consumption, or not. > > In our pre-standard implementation we chose to pick names automatically, > and they are at this point clearly NOT for human consumption. We just make > sure they're unique. The admin provides the domain name, which is the same > for all devices. > > In a SOHO environment, I claim things should just happen automatically, > and the name really doesn't matter much to humans. > > In an SP, we could either use the same model, or allow for operator input. > So an SP can provide a mapping between unique device identifier (UDI) and a > name that he'd like this device to have. This mapping can be provided in a > number of different forms, let's leave that for further considerations. > > But I think, from the ANIMA point of view, we should say: During the > enrolment process the admin can provide a name for a device (and a domain > name, btw). If a name is provided, it is used (in the certificate for > example). If not, a unique, autonomically created name is used. We need an > algorithm that creates the autonomic name. (I tried to explain that in the > addressing doc, but it was clearly not clear enough). > > Personally, I think we shouldn't define how the name is constructed, if > the operator puts one in. > > So, in summary: > - case 1: Admin provides UDI to name mapping, then that name is used. (we > don't care what's inside the name) > - case 2: name is created autonomically, using algorithm x > > Thoughts? > Michael > > > > > -----Original Message----- > > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Liubing (Leo) > > Sent: 29 June 2015 09:13 > > To: Brian E Carpenter; anima@ietf.org > > Subject: Re: [Anima] Naming discussion (Section 4.1 of the Reference- > > Model draft) > > > > Hi Brian, > > > > Thanks for your comments, pls see inline. > > > > > -----Original Message----- > > > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E > > > Carpenter > > > Sent: Saturday, June 27, 2015 9:37 AM > > > To: anima@ietf.org > > > Subject: Re: [Anima] Naming discussion (Section 4.1 of the > > > Reference-Model > > > draft) > > > > > > On 26/06/2015 22:27, Liubing (Leo) wrote: > > > > Hi Dear all, > > > > > > > > I've generated some text regarding to the naming of autonomic > > > > network > > > devices. This is to fit the Section 4.1 in the Reference-Model draft. > > > > Below is the content which includes some rough ideas. Please feel > > > > free to > > > comment. > > > > > > > > 4.1. Naming > > > > > > > > 4.1.1. Naming requirements > > > > > > > > o Representing each device > > > > Inside a domain, each autonomic device needs a domain > > > specific > > > > identifier. > > > > [Open Questions] Are there devices that don't need names? > > > Do > > > > ASAs need names? > > > > > > > > o Uniqueness > > > > The names MUST NOT collide within one autonomic domain. > > > > It is acceptable that the names in different domains > collide, > > > > since they could be distinguished by domains. > > > > > > Well, yes, we have a system for that, which is the DNS. Is there any > > > reason not to use DNS names? > > > > > > > o Semantic Encoding > > > > It is RECOMMENDED that the names encode some semantics > > > rather > > > > than meaningless strings. The semantics might be: > > > > + Location > > > > + Device type > > > > + Functional role > > > > + Ownership > > > > + etc. > > > > This is for ease of management consideration that network > > > > administrators could easily recognize the device directly > > > > through the names. > > > > > > I'm generally against making this a formal recommendation. I > > > understand very well that it may be a common operational practice > > > already, but it's quite subject to human error > > [Bing] The described pattern isn't for manual configuration. I was > imagining > > the semantic fields could be generated by the autonomic devices > > themselves. > > The name space of the semantics don't necessarily need to be > standardized, > > the vendors could set vocabulary by themselves. Since the goal is human- > > readable, human could understand different vocabularies. > > > > > and in a truly autonomic network nobody should ever see the names > > > anyway. > > [Bing] When we discussed AN management in the Reference Model draft > > with Michael B. We all agreed that traditional management would co-exist > > with autonomic management. > > In this sense, do you think the naming is useful for the traditional > > management part? > > > > > Also, they would need to change autonomically whenever the topology > > > changes. > > [Bing] Yes, this would probably happen. John also mentioned the naming > > change is "annoying" in the other thread. > > So I was just thinking, maybe we could divide the name into two parts: > one > > part is the "basic-name" which should be permanent; the other part is > > "name-tags" (e.g. Location, Functional Role, Ownership etc.) which are > > some info that might be useful for administration but might probably > > changes. > > > > Best regards, > > Bing > > > > > Brian > > > > > > > o Consistency > > > > The devices' naming SHOULD follow the same pattern within a > > > > domain. > > > > > > > > 4.1.2. Proposed Mechanisms > > > > > > > > o Structured Naming Pattern > > > > The whole name string could be divided into several fields, > > > > each of which representing a specific semantic as described > > > > above. For example: Location-DeviceType-FunctionalRole- > > > > DistinguisherNumber@NameofDomain. > > > > > > > > The structure should be flexible that some fields are > optional. > > > > When these optional fields are added, the name could still > be > > > > recognized as the previous one. In above example, the > > > > "DistinguisherNumber" and "NameofDomain" are mandatory > > > whereas > > > > others are optional. At initial stage, the devices might be > > > > only capable of self-generating the mandatory fields and the > > > > "DeviceType" because of the lack of knowledge. Later, they > > > > might have learned the "Location" and "FunctionalRole" and > > > > added the fields into current name. However, the other > > > devices > > > > could still recognize it according to the same > > > > "DistinguisherNumber". > > > > > > > > o Advertised Common Fields > > > > Some fields in the structured name might be common among > > > the > > > > domain (e.g. "Location" "NameofDomain"). Thus, these > > > part of > > > > the names could be advertised through Intent > > > > Distribution (Section 4.5). > > > > > > > > o Self-generated Fields > > > > The mandatory fields SHOULD be self-generated so that one > > > > device could name itself sufficiently without any advertised > > > > knowledges. > > > > There should various methods for a device to > > > > extract/generate > > > a > > > > proper word for each mandatory semantic fields (e.g. > > > > "DeviceType", "DistinguisherNum") from its self-knowledge. > > > > > > > > Detailed design of specific naming patterns and methods are out of > > > > scope of this document. > > > > > > > > > > > > > > > > Best regards, > > > > Bing > > > > > > > > _______________________________________________ > > > > 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 > > > > _______________________________________________ > > 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 > -- regards, John --f46d043c7c16f1cde30519c54356 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Michael, et al.,

I'm = confused as to why there is a question.

One of the= principal goals of autonomics is to reduce the administrative burden on hu= mans. When I combine this with the WG's desire to use "intent"= ;, then why would a name be necessary at all? Why wouldn't the preferre= d model be to talk in terms of roles or user-friendly aliases (e.g., MyInte= rnetGateway)? Do I really need to call the AAA server that I use 'Fred&= #39;? :-) And, with all due respect, naming a device WiringCloset3Rack2Chas= sis7-Router-InternetGateway... doesn't really help (and that's assu= ming you could get everyone to agree on a taxonomy like that).
Plus, legacy environments aren't going to care how we name= our devices - they will have their own names, and will also don't care= if we like them or not.

This is why I keep asking= why naming is important. If you are using a name for locating something (b= oo! hiss!), then you SHOULD instead use metadata, which can do a much more = thorough job and give you many more options. If you are using a name for pr= ogramming something ((boo!)^2) then you SHOULD instead be using a much rich= er means to identify the (hint) object that you are trying to interact with= . If you are using it for something else, then let's focus on that and = see why it is needed. BTW, I'm obviously guessing at the first two use = cases, and am hoping that I am wrong on both. :-)

= I have nothing against names, but I would rather use the right tool for the= right job. In addition, as I said previously, if this really is an autonom= ic system, and the name changes, what good is it? Wouldn't it be better= to describe the role the object plays (i.e., the role-object pattern), or = metadata that can be used to hunt the little bugger down? Both of these are= independent of change, since they describe behavior of the thing, and not = an (arbitrary) name that was tacked on to the thing.

>=C2=A0But I think, from the ANIMA point of view, we should say: Duri= ng
> the enrolment process the admin can provide a name for a=
> device (and a domain name, btw). If a name is provided, it= is used
> (in the certificate for example). If not, a unique= , autonomically
> created name is used. We need an algorithm = that creates the
> autonomic name. (I tried to explain that in the a= ddressing doc,
> but it was clearly not clear enough).
Agreed, but I would argue that this should be automatically cre= ated
not autonomically created. :-)

>=C2=A0Personally, = I think we shouldn't define how the name is
> constructed= , if the operator puts one in.

Completely agree. T= he operator will ignore us anyway. :-)

regards= ,
John

On Mon, Jun 29, 2015 at 12:38 AM, Michael Behringer (mbehring) <= span dir=3D"ltr"><mbehring@cisco.com> wrote:
anima-bo= unces@ietf.org] On Behalf Of Liubing (Leo)
> Sent: 29 June 2015 09:13
> To: Brian E Carpenter; anima@ietf.or= g
> Subject: Re: [Anima] Naming discussion (Section 4.1 of the Reference-<= br> > Model draft)
>
> Hi Brian,
>
> Thanks for your comments, pls see inline.
>
> > -----Original Message-----
> > From: Anima [mailto:ani= ma-bounces@ietf.org] On Behalf Of Brian E
> > Carpenter
> > Sent: Saturday, June 27, 2015 9:37 AM
> > To: anima@ietf.org
> > Subject: Re: [Anima] Naming discussion (Section 4.1 of the
> > Reference-Model
> > draft)
> >
> > On 26/06/2015 22:27, Liubing (Leo) wrote:
> > > Hi Dear all,
> > >
> > > I've generated some text regarding to the naming of auto= nomic
> > > network
> > devices. This is to fit the Section 4.1 in the Reference-Model dr= aft.
> > > Below is the content which includes some rough ideas. Please= feel
> > > free to
> > comment.
> > >
> > > 4.1.=C2=A0 Naming
> > >
> > > 4.1.1.=C2=A0 Naming requirements
> > >
> > >=C2=A0 =C2=A0 o=C2=A0 Representing each device
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Inside a domain, each auto= nomic device needs a domain
> > specific
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 identifier.
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Open Questions] Are there= devices that don't need names?
> > Do
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ASAs need names?
> > >
> > >=C2=A0 =C2=A0 o=C2=A0 Uniqueness
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The names MUST NOT collide= within one autonomic domain.
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 It is acceptable that the = names in different domains collide,
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 since they could be distin= guished by domains.
> >
> > Well, yes, we have a system for that, which is the DNS. Is there = any
> > reason not to use DNS names?
> >
> > >=C2=A0 =C2=A0 o=C2=A0 Semantic Encoding
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 It is RECOMMENDED that the= names encode some semantics
> > rather
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 than meaningless strings.= =C2=A0 The semantics might be:
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +=C2=A0 Location
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +=C2=A0 Device type
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +=C2=A0 Functional role > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +=C2=A0 Ownership
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +=C2=A0 etc.
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This is for ease of manage= ment consideration that network
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 administrators could easil= y recognize the device directly
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 through the names.
> >
> > I'm generally against making this a formal recommendation. I<= br> > > understand very well that it may be a common operational practice=
> > already, but it's quite subject to human error
> [Bing] The described pattern isn't for manual configuration. I was= imagining
> the semantic fields could be generated by the autonomic devices
> themselves.
> The name space of the semantics don't necessarily need to be stand= ardized,
> the vendors could set vocabulary by themselves. Since the goal is huma= n-
> readable, human could understand different vocabularies.
>
> > and in a truly autonomic network nobody should ever see the names=
> > anyway.
> [Bing] When we discussed AN management in the Reference Model draft > with Michael B. We all agreed that traditional management would co-exi= st
> with autonomic management.
> In this sense, do you think the naming is useful for the traditional > management part?
>
> > Also, they would need to change autonomically whenever the topolo= gy
> > changes.
> [Bing] Yes, this would probably happen. John also mentioned the naming=
> change is "annoying" in the other thread.
> So I was just thinking, maybe we could divide the name into two parts:= one
> part is the "basic-name" which should be permanent; the othe= r part is
> "name-tags" (e.g. Location, Functional Role, Ownership etc.)= which are
> some info that might be useful for administration but might probably > changes.
>
> Best regards,
> Bing
>
> >=C2=A0 =C2=A0 Brian
> >
> > >=C2=A0 =C2=A0 o=C2=A0 Consistency
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The devices' naming SH= OULD follow the same pattern within a
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 domain.
> > >
> > > 4.1.2.=C2=A0 Proposed Mechanisms
> > >
> > >=C2=A0 =C2=A0 =C2=A0o=C2=A0 Structured Naming Pattern
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The whole name string coul= d be divided into several fields,
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 each of which representing= a specific semantic as described
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 above.=C2=A0 For example: = Location-DeviceType-FunctionalRole-
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DistinguisherNumber@Nameof= Domain.
> > >
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The structure should be fl= exible that some fields are optional.
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 When these optional fields= are added, the name could still be
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 recognized as the previous= one.=C2=A0 In above example, the
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "DistinguisherNumber&= quot; and "NameofDomain" are mandatory
> > whereas
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 others are optional.=C2=A0= At initial stage, the devices might be
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 only capable of self-gener= ating the mandatory fields and the
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "DeviceType" bec= ause of the lack of knowledge.=C2=A0 Later, they
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 might have learned the &qu= ot;Location" and "FunctionalRole" and
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 added the fields into curr= ent name.=C2=A0 However, the other
> > devices
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 could still recognize it a= ccording to the same
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "DistinguisherNumber&= quot;.
> > >
> > >=C2=A0 =C2=A0 o=C2=A0 Advertised Common Fields
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Some fields in the structu= red name might be common among
> > the
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 domain (e.g.=C2=A0 "L= ocation" "NameofDomain").=C2=A0 Thus, these
> > part of
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the names could be adverti= sed through Intent
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Distribution (Section 4.5)= .
> > >
> > >=C2=A0 =C2=A0 o=C2=A0 Self-generated Fields
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The mandatory fields SHOUL= D be self-generated so that one
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 device could name itself s= ufficiently without any advertised
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 knowledges.
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 There should various metho= ds for a device to
> > > extract/generate
> > a
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 proper word for each manda= tory semantic fields (e.g.
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "DeviceType", &q= uot;DistinguisherNum") from its self-knowledge.
> > >
> > >=C2=A0 =C2=A0 Detailed design of specific naming patterns and= methods are out of
> > >=C2=A0 =C2=A0 scope of this document.
> > >
> > >
> > >
> > > Best regards,
> > > Bing
> > >
> > > _______________________________________________
> > > Anima mailing list
> > > Anima@ietf.org
> > > https://www.ietf.org/mailman/listinfo/anim= a
> > >
> >
> > _______________________________________________
> > 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

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



--
regards,
John
--f46d043c7c16f1cde30519c54356-- From nobody Tue Jun 30 17:26:23 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A26D1A0068 for ; Tue, 30 Jun 2015 17:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.718 X-Spam-Level: X-Spam-Status: No, score=-1.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gp91EvtuuVn3 for ; Tue, 30 Jun 2015 17:26:19 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (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 58FD61A0056 for ; Tue, 30 Jun 2015 17:26:19 -0700 (PDT) Received: by wibdq8 with SMTP id dq8so30909586wib.1 for ; Tue, 30 Jun 2015 17:21:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fhpcruklAV9MTUpfy8w84F7qusvW6l5NwhQaFm9sM4w=; b=EIp5VdQcyj2SOR+sI3c2tPQRJm5VOPsWtWy6NcV7bYT7jBNDjUXeYX8ihNqEmmx621 cChHtI8gSZZiQyp7Jmfz5SHxE6L5y0i/3C3TQm6nG7wKdPZb4BN4SA70x/eBfnmSD9m4 m4AEheWy2ojEhPjjsVmzTDf2pGKBvJawRnctPYS1B9PIhpMoxLPKps/LiHPVA2e46sAB 8dlWFw8qrut7fO1u+xXXD/rYb58yTB0MsHTYYRtLb0SafNwdJJoG0343SJQ/CQfhJphJ GDa4InAsnRtXu7jabL2Vfwq0j2YNARZxURCpAj4k9QHEk8x2ZklisUeyg5M5/fn2/sbs 83rg== MIME-Version: 1.0 X-Received: by 10.194.58.109 with SMTP id p13mr47249622wjq.36.1435710078451; Tue, 30 Jun 2015 17:21:18 -0700 (PDT) Received: by 10.27.39.5 with HTTP; Tue, 30 Jun 2015 17:21:18 -0700 (PDT) In-Reply-To: <559113B8.2060601@alcatel-lucent.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FEE3B8@xmb-rcd-x14.cisco.com> <5583F8D3.6070208@alcatel-lucent.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF828B@xmb-rcd-x14.cisco.com> <559113B8.2060601@alcatel-lucent.com> Date: Tue, 30 Jun 2015 17:21:18 -0700 Message-ID: From: John Strassner To: Laurent Ciavaglia Content-Type: multipart/alternative; boundary=047d7ba977ae3a063f0519c54dd4 Archived-At: Cc: "draft-behringer-anima-reference-model@tools.ietf.org" , Anima WG , "Michael Behringer \(mbehring\)" Subject: Re: [Anima] Reference doc on github X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jul 2015 00:26:22 -0000 --047d7ba977ae3a063f0519c54dd4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree with Laurent. It doesn't have to be authored now, but we need to address it. Otherwise, we aren't relevant to existing deployments, which would be bad. regards, John On Mon, Jun 29, 2015 at 2:45 AM, Laurent Ciavaglia < Laurent.Ciavaglia@alcatel-lucent.com> wrote: > Dear Michael, > > I think that in ANIMA we should eventually document "interactions" with > non-autonomic networks. > > It is fine for me to not have a section in the reference document for the > moment, as this topic is still largely undefined. So ok to drop the secti= on > in the next version, knowing that in furhter revision it might be > integrated again (probably under a different name). > > Thanks, best regards, Laurent. > > > On 29/06/2015 11:39, Michael Behringer (mbehring) wrote: > > Hi Laurent, > > Regarding section 8: Agree, no changes needed for now, but feedback from > the community. > > Regarding section 9: I re-read both, this section and section 3.2. of > RFC7575. My personal opinion is that this section is not needed in the > reference document, and I suggest therefore to drop it. > > Let=E2=80=99s keep the document as concise as possible. > > Michael > > *From:* Laurent Ciavaglia [mailto:Laurent.Ciavaglia@alcatel-lucent.com > ] > *Sent:* 19 June 2015 13:11 > *To:* Michael Behringer (mbehring); Anima WG > *Cc:* draft-behringer-anima-reference-model@tools.ietf.org > *Subject:* Re: Reference doc on github > > > > Dear Michael, all, > > Section 8 is new, so I don't think it needs an upate for -03, but I would > be happy to make changes based on feedback/comments. > > For Section 9: Is the current text referring to RFC7575, Section 3.2. > Coexistence with Traditional Management? > If yes, then I would suggest renaming Section 9 to reflect the actual > content which focuses on "management or operation mode" prioritization. > If agreed/correct, I can update the text for Section 9 by next Wednesday. > > Though, the topic of "hybrid" operations (autonomic and non-autonomic) is > still relevant, but slightly different from prioritization. Some ongoing > discussions on the ANIMA mailing list on domain, intent, and constrained > nodes participate in this topic. > A text on this in -03 is too ambitious, but we can trigger a discussion > thread to capture the operating principles ANIMA aims at concerning this > hybrid mode of operation (i.e. how AFs and non-AFs co-operate, are > managed/governed by Intent/other means, role of "helping" > nodes/functions/gateways...) > > Best regards, Laurent. > > On 17/06/2015 14:41, Michael Behringer (mbehring) wrote: > > I have now also created a repository in github: https://github.com/mbehri= ng/ANIMA-Reference-Model > > > > I suggested initial contributions, as per below list (open to more sugges= tions ;-) > > > > - Michael Richardson: section 3.3 (constrained nodes) > > - Liubing: 4.1 and 4.2 (Naming, addressing) > > - Brian Carpenter: 4.4 (signaling). Could you also cover 4.5 (intent dist= ribution) and 4.3 (discovery)? - very related!! > > - Jason Coleman: Section 5.1, 5.2, 5.4, 5.5 (PKI, cert, sub and cross-dom= ain) > > - Jeferson Nobre: 7.1, 7.2, 7.3 (Management, intent, aggregated reporting= ) > > - John Strassner: 7.4, 7.5, 7.6 (feedback loops, APIS and models.) > > - Laurent Ciavaglia: Sections 8 and 9 (do they need an update?) > > - Toerless and I will share the remaining sections for now. > > > > Can the volunteers please let me know by when they can contribute their t= ext? Either in github (let me know your ID if you want to contribute there= ) > > > > Github is not mandatory - If you want to send me your text via mail, that= 's ok. I'd strongly prefer XML formatted sections if possible ;-) > > > > Can we have all text in by Wed next week? > > > > I plan to consolidate and push -03 by end of next week. > > > > Michael > > > > -- > > Bien cordialement, Best regards, > > > > *Laurent Ciavaglia* > > Secure Cloud Networking > > Bell Labs | Alcatel Lucent > > > > phone: +33 160 402 636 > > email: laurent.ciavaglia@alcatel-lucent.com > > linkedin: laurentciavaglia > > address: Route de Villejust | 91620 Nozay | France > > > -- > > Bien cordialement, Best regards, > > > > *Laurent Ciavaglia* > > Secure Cloud Networking > > Bell Labs | Alcatel Lucent > > > > phone: +33 160 402 636 > > email: laurent.ciavaglia@alcatel-lucent.com > > linkedin: laurentciavaglia > > address: Route de Villejust | 91620 Nozay | France > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > > --=20 regards, John --047d7ba977ae3a063f0519c54dd4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree with Laurent. It doesn't have to be autho= red now, but we need to address it. Otherwise, we aren't relevant to ex= isting deployments, which would be bad.

regards,
John

On Mon, Jun 29, 2015 at 2:45 AM, Laurent Ciavaglia <Laurent.Ciavaglia@alcatel-lucent.com> wrote:
=20 =20 =20
Dear Michael,

I think that in ANIMA we should eventually document "interaction= s" with non-autonomic networks.

It is fine for me to not have a section in the reference document for the moment, as this topic is still largely undefined. So ok to drop the section in the next version, knowing that in furhter revision it might be integrated again (probably under a different name).

Thanks, best regards, Laurent.


On 29/06/2015 11:39, Michael Behringer (mbehring) wrote:
=20 =20 =20

Hi Laurent,

Regarding section 8: Agree, no changes needed for now, but feedback from the community.

Regarding section 9: I re-read both, this section and section 3.2. of RFC7575. My personal opinion is that this section is not needed in the reference document, and I suggest therefore to drop it.

Let=E2=80=99s keep the document as concise as possible.

Michael

From:= Laurent Ciavaglia [mailto:Laurent.Ciavaglia@alcatel-lucent.com]
Sent: 19 June 2015 13:11
To: Michael Behringer (mbehring); Anima WG
Cc: draft-behringer-anima-reference-model@to= ols.ietf.org
Subject: Re: Reference doc on github=

=C2=A0<= /u>

Dear Michael, all,

Section 8 is new, so I don't think it needs an upate fo= r -03, but I would be happy to make changes based on feedback/comments.

For Section 9: Is the current text referring to RFC7575, Section 3.2. Coexistence with Traditional Management?
If yes, then I would suggest renaming Section 9 to reflect the actual content which focuses on "managemen= t or operation mode" prioritization.
If agreed/correct, I can update the text for Section 9 by next Wednesday.

Though, the topic of "hybrid" operations (autonom= ic and non-autonomic) is still relevant, but slightly different from prioritization. Some ongoing discussions on the ANIMA mailing list on domain, intent, and constrained nodes participate in this topic.
A text on this in -03 is too ambitious, but we can trigger a discussion thread to capture the operating principles ANIMA aims at concerning this hybrid mode of operation (i.e. how AFs and non-AFs co-operate, are managed/governed by Intent/other means, role of "helping" nodes/functions/gateways...)

Best regards, Laurent.

On 17/06/2015 14:41, Michael Behringer (mbehring) wrote:<= /u>

I have now also created a rep=
ository in github: https://github.com/mbehring/ANIMA-Reference-Model
=C2=A0
I suggested initial contribut=
ions, as per below list (open to more suggestions ;-) =

=C2=A0
- Michael Richardson: section=
 3.3 (constrained nodes)
- Liubing: 4.1 and 4.2 (Namin=
g, addressing)
- Brian Carpenter: 4.4 (signa=
ling). Could you also cover 4.5 (intent distribution) and 4.3 (discovery)? =
- very related!!
- Jason Coleman: Section 5.1,=
 5.2, 5.4, 5.5 (PKI, cert, sub and cross-domain)
- Jeferson Nobre: 7.1, 7.2, 7=
.3 (Management, intent, aggregated reporting)
            
- John Strassner: 7.4, 7.5, 7=
.6 (feedback loops, APIS and models.)

            
- Laurent Ciavaglia: Sections=
 8 and 9 (do they need an update?)

            
- Toerless and I will share t=
he remaining sections for now.

            
=C2=A0

            
Can the volunteers please let=
 me know by when they can contribute their text?=C2=A0 Either in github (le=
t me know your ID if you want to contribute there) 

            
=C2=A0

            
Github is not mandatory - If =
you want to send me your text via mail, that's ok. I'd strongly pre=
fer XML formatted sections if possible ;-) 
            
=C2=A0

            
Can we have all text in by We=
d next week? 

            
=C2=A0

            
I plan to consolidate and pus=
h -03 by end of next week. 

            
=C2=A0

            
Michael<=
/font>

=C2=A0<= /u>

--
=20 =20 =20 =20 =20 =20 =20 =20 =20 =20

Bien cordialement, Best regards,

=C2=A0

Laurent Ciavaglia

Secure Cloud Networking

Bell Labs | Alcatel Lucent

=C2=A0

phone: +33=C2=A0160 402=C2=A0636

email: laurent.ciavaglia@alcatel-lucent.com=

linkedin: laurentciavaglia

address: Route de Villejust | 91620 Nozay | France


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




--
regards,
John
--047d7ba977ae3a063f0519c54dd4-- From nobody Tue Jun 30 20:44:58 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB5F1A21C5 for ; Tue, 30 Jun 2015 20:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bgfhiZ8U6tQ for ; Tue, 30 Jun 2015 20:44:54 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FE1C1A21AE for ; Tue, 30 Jun 2015 20:44:54 -0700 (PDT) Received: by wicgi11 with SMTP id gi11so33202988wic.0 for ; Tue, 30 Jun 2015 20:44:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RyLOW3LqEobQ8N8hdDuhslGt9AL/dGnvpnnX212LLPA=; b=BU6sH103RO+WEruQKPGwudGTPAejD02F08jNPbchJ7OtIVyH3zhJu89+o+JXt1TT5z C5nk3K7bqxO3MgJYZqtRGGDDrksXi0Jq6KBMP7xHH1qFiSjnA7wf63RHnwCbDmzq17vW 3NJmQ+IBQ7RByka1Cn9eHQuZ7KGitCygMjdf/Hg88rJiH7T7rjSmYMZPtSyTwy6YF4kB t6Lh0RX97b796ahbsXTcTLLqndSnwo0FJN0FkDxzlotM105Lf8zG4wavDNjgu/2E9Mu9 br2QfBkce4zSVFEZbtrLBm9MlZFUKhUoCboP6c+Dn2Gmlgdyni76Kk/a3yW6HKcM91zA HsxA== MIME-Version: 1.0 X-Received: by 10.180.109.136 with SMTP id hs8mr1893502wib.73.1435722293381; Tue, 30 Jun 2015 20:44:53 -0700 (PDT) Received: by 10.27.39.5 with HTTP; Tue, 30 Jun 2015 20:44:53 -0700 (PDT) In-Reply-To: <55932E02.60906@gmail.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F45A6799F26@nkgeml506-mbx.china.huawei.com> <558DFE45.4050906@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C21D1AD8@nkgeml506-mbx.china.huawei.com> <55921A2E.4080203@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FFAC01@xmb-rcd-x14.cisco.com> <55932E02.60906@gmail.com> Date: Tue, 30 Jun 2015 20:44:53 -0700 Message-ID: From: John Strassner To: Brian E Carpenter Content-Type: multipart/alternative; boundary=e89a8f2345574b0e290519c825e3 Archived-At: Cc: "anima@ietf.org" , "Liubing \(Leo\)" , "Michael Behringer \(mbehring\)" Subject: Re: [Anima] Metadata [was Naming discussion (Section 4.1 of the Reference-Model draft)] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jul 2015 03:44:57 -0000 --e89a8f2345574b0e290519c825e3 Content-Type: text/plain; charset=UTF-8 Agreed, good points. regards, John On Tue, Jun 30, 2015 at 5:02 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 01/07/2015 00:06, Michael Behringer (mbehring) wrote: > > Agree with the below sentiments: > > > > AN should assign a permanent node name to a node, which is, from an AN > perspective independent of its current role, location and function. This is > independent of the "hostname" used today, which remains as is, and an > operator can do with that one what he likes. To encode role, location, > function, etc, we use other metadata. > > > > The AN node name will be part of the node certificate, which is > permanent. Also because of this, there should be no role, function or > location encoded into that name. > > > > Now, up to here, I believe we're reaching a consensus. Right? > > > > The following statement will undoubtedly raise interesting debates: I > claim the address assignment should follow the same principles, such that a > node IP address is permanent, and essentially an identifier. > > I think you'll need to define "permanent". If there is some kind of major > event (like a long power cut, for example) you might end up with a > complete cold start of the network and re-creation of the ACP, and then > I think renumbering would probably occur. But certainly the address > should not change as a routine matter. > > > Now, we all know that sometimes aggregation is needed, for that we > brought in the "zones". But the addressing scheme now in the reference doc ( > https://tools.ietf.org/html/draft-behringer-anima-reference-model-03#section-4.2) > is meant to allow for exactly this: The "device ID" remains constant, as an > identifier, the zone ID can be used to aggregate, if needed. Thoughts? > > For large networks, yes. Small networks can flat-route anyway. > > Brian > > > > > Michael > > > >> -----Original Message----- > >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E > >> Carpenter > >> Sent: 30 June 2015 06:25 > >> To: John Strassner; Liubing (Leo) > >> Cc: anima@ietf.org > >> Subject: [Anima] Metadata [was Naming discussion (Section 4.1 of the > >> Reference-Model draft)] > >> > >> On 30/06/2015 15:50, John Strassner wrote: > >> ... > >>> > Also, they would need to change autonomically > whenever the > >>> topology changes. > >>> [Bing] Yes, this would probably happen. John also mentioned the > >>> naming change is "annoying" in the other thread. > >>> So I was just thinking, maybe we could divide the name into two > >>> parts: one part is the "basic-name" which should be permanent; the > >>> other part is "name-tags" (e.g. Location, Functional Role, Ownership > >>> etc.) which are some info that might be useful for administration but > >> might probably changes. > >>> > >>> > >>> I strongly recommend that you use metadata to gain information about a > >>> node of interest. Names are a bad way to do this. > >>> > >> > >> When I think about more carefully, I agree with John on this. > >> DNS names must be unique at any one time, but they may change > >> autonomically, and I think they could be misleading after topology > >> changes.** > >> > >> It seems to me that Node Information metadata would be very suitable to > >> be treated as a Technical Objective like any other (in Anima signaling > >> jargon), subject to discovery and synchronization like any other complex > >> parameter. A node's current DNS name and its current IP > >> address(es) could be considered as part of its Node Information. > >> > >> I think that each node's constant ID will emerge from the security > bootstrap > >> work. > >> > >> ** OK, it was me who refused categorically to allow the name > info.cern.ch > >> to be assigned to a machine at MIT, when Tim Berners-Lee moved from > >> CERN to MIT. I thought it would be very misleading, and I still think > that. > >> > >> Brian > >> > >> _______________________________________________ > >> Anima mailing list > >> Anima@ietf.org > >> https://www.ietf.org/mailman/listinfo/anima > > > -- regards, John --e89a8f2345574b0e290519c825e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agreed, good points.

regards= ,
John

On Tue, Jun 30, 2015 at 5:02 PM, Brian E Carpenter <b= rian.e.carpenter@gmail.com> wrote:
On 01/07/2015 00:06, Michael Behringer (mbehring) wrote:
> Agree with the below sentiments:
>
> AN should assign a permanent node name to a node, which is, from an AN= perspective independent of its current role, location and function. This i= s independent of the "hostname" used today, which remains as is, = and an operator can do with that one what he likes. To encode role, locatio= n, function, etc, we use other metadata.
>
> The AN node name will be part of the node certificate, which is perman= ent. Also because of this, there should be no role, function or location en= coded into that name.
>
> Now, up to here, I believe we're reaching a consensus. Right?
>
> The following statement will undoubtedly raise interesting debates: I = claim the address assignment should follow the same principles, such that a= node IP address is permanent, and essentially an identifier.

I think you'll need to define "permanent". If there is some k= ind of major
event (like a long power cut, for example) you might end up with a
complete cold start of the network and re-creation of the ACP, and then
I think renumbering would probably occur. But certainly the address
should not change as a routine matter.

> Now, we all know that sometimes aggregation is needed, for that we bro= ught in the "zones". But the addressing scheme now in the referen= ce doc (https://tool= s.ietf.org/html/draft-behringer-anima-reference-model-03#section-4.2) i= s meant to allow for exactly this: The "device ID" remains consta= nt, as an identifier, the zone ID can be used to aggregate, if needed. Thou= ghts?

For large networks, yes. Small networks can flat-route anyway.

=C2=A0 =C2=A0Brian

>
> Michael
>
>> -----Original Message-----
>> From: Anima [mailto:anim= a-bounces@ietf.org] On Behalf Of Brian E
>> Carpenter
>> Sent: 30 June 2015 06:25
>> To: John Strassner; Liubing (Leo)
>> Cc: anima@ietf.org
>> Subject: [Anima] Metadata [was Naming discussion (Section 4.1 of t= he
>> Reference-Model draft)]
>>
>> On 30/06/2015 15:50, John Strassner wrote:
>> ...
>>>=C2=A0 > Also, they would need to change autonomically=C2=A0= > whenever the
>>> topology changes.
>>>=C2=A0 [Bing] Yes, this would probably happen. John also mentio= ned the
>>> naming change is "annoying" in the other thread.
>>>=C2=A0 So I was just thinking, maybe we could divide the name i= nto two
>>> parts: one part is the "basic-name" which should be = permanent; the
>>> other part is "name-tags" (e.g. Location, Functional= Role, Ownership
>>> etc.) which are some info that might be useful for administrat= ion but
>> might probably changes.
>>>
>>> <jcs>
>>> I strongly recommend that you use metadata to gain information= about a
>>> node of interest. Names are a bad way to do this.
>>> </jcs>
>>
>> When I think about more carefully, I agree with John on this.
>> DNS names must be unique at any one time, but they may change
>> autonomically, and I think they could be misleading after topology=
>> changes.**
>>
>> It seems to me that Node Information metadata would be very suitab= le to
>> be treated as a Technical Objective like any other (in Anima signa= ling
>> jargon), subject to discovery and synchronization like any other c= omplex
>> parameter. A node's current DNS name and its current IP
>> address(es) could be considered as part of its Node Information. >>
>> I think that each node's constant ID will emerge from the secu= rity bootstrap
>> work.
>>
>> ** OK, it was me who refused categorically to allow the name info.cern.c= h
>> to be assigned to a machine at MIT, when Tim Berners-Lee moved fro= m
>> CERN to MIT. I thought it would be very misleading, and I still th= ink that.
>>
>>=C2=A0 =C2=A0Brian
>>
>> _______________________________________________
>> Anima mailing list
>> Anima@ietf.org
>> https://www.ietf.org/mailman/listinfo/anima<= br> >



--
regards,
John
--e89a8f2345574b0e290519c825e3--