From nobody Wed Jun 11 12:54:18 2014 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 94DB21A0299 for ; Wed, 11 Jun 2014 12:54: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 AVyGl9_T7D2R for ; Wed, 11 Jun 2014 12:54:09 -0700 (PDT) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A53611A0275 for ; Wed, 11 Jun 2014 12:54:03 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id ft15so148758pdb.25 for ; Wed, 11 Jun 2014 12:54: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:content-type:content-transfer-encoding; bh=GnRoJLfRPRPPSsmK5/wt1GV+AvWiM/A8lXxH8tDYn/8=; b=RAykFk0AngkPQZdAnS75Xjurr/INuyzcjut+S59tJRWqAC3pW/2mUiMO/r04Kn3FB8 8nFGeUoaDGiqOYbR/mR8WrnDVXt5bjWzFo0GJUC8+sVft+BVufGYtX6fF5Ak3zSC7L47 +MPPxRXbWJSX4H/kwXTRvsoWjrnTPJrvJI6ZqZ4jFESeyokyMoWH9fojWXV4lo+CZ0Mp lvn/Fi8NjRgHQHDGbisj6S+yc8tcMWSLH/6mo6rzDvophPOHyRbtlFGIQ01sRKfwaFD2 uDuevmIxt8crU3s89rEuzE08kzqhUXWyXW+2G1EJtVq6MReyKSYhXKtU4tfIK+Qfsajb RmTg== X-Received: by 10.68.229.68 with SMTP id so4mr7474119pbc.110.1402516443038; Wed, 11 Jun 2014 12:54:03 -0700 (PDT) Received: from [192.168.178.23] (68.195.69.111.dynamic.snap.net.nz. [111.69.195.68]) by mx.google.com with ESMTPSA id ja8sm76518864pbd.3.2014.06.11.12.54.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Jun 2014 12:54:02 -0700 (PDT) Message-ID: <5398B3D9.6010206@gmail.com> Date: Thu, 12 Jun 2014 07:54:01 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: anima@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/NzLGyUNrG2_t4mvU_w4S91Kwbzk Subject: [Anima] Test transmission 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, 11 Jun 2014 19:54:15 -0000 Hi, An introductory message will follow when more people have had time to join this list. I'd appreciate a volunteer to act as the second list administrator; it's a standard mailman list. Regards Brian Carpenter From nobody Wed Jun 11 12:58:25 2014 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 C81811B289D; Wed, 11 Jun 2014 12:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 78tUpWLEakCB; Wed, 11 Jun 2014 12:44:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E471B289E; Wed, 11 Jun 2014 12:44:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140611194455.24116.99203.idtracker@ietfa.amsl.com> Date: Wed, 11 Jun 2014 12:44:55 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/anima/pBzUUHIKpcL_Np_uHPkpfb7JISc X-Mailman-Approved-At: Wed, 11 Jun 2014 12:58:25 -0700 Cc: brian.e.carpenter@gmail.com, anima@ietf.org Subject: [Anima] New Non-WG Mailing List: Anima -- Autonomic Networking Integrated Model and Approach X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@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, 11 Jun 2014 19:44:56 -0000 A new IETF non-working group email list has been created. List address: anima@ietf.org Archive: http://www.ietf.org/mail-archive/web/anima/ To subscribe: https://www.ietf.org/mailman/listinfo/anima Purpose: The fundamental goal of Autonomic Networking (AN) is self-management, including self-configuration, self-optimization, self-healing and self-protection. The ANIMA list is for discussion of autonomic networking, including the following topics: - Definitions and gap analysis for AN - Use cases for AN - Common requirements for an autonomic infrastructure - Problem statement and preliminary ideas for possible protocol work For more details see the proposed UCAN BOF at http://trac.tools.ietf.org/bof/trac/wiki/WikiStart#UCANproposal For additional information, please contact the list administrators. From nobody Wed Jun 11 17:55:39 2014 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 29E071B291C for ; Wed, 11 Jun 2014 17:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 yCTl1y2svsHl for ; Wed, 11 Jun 2014 17:55:33 -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 28F991B2902 for ; Wed, 11 Jun 2014 17:55:33 -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 BFI09292; Thu, 12 Jun 2014 00:55:31 +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; Thu, 12 Jun 2014 01:55:30 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.68]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Thu, 12 Jun 2014 08:55:26 +0800 From: Sheng Jiang To: Brian E Carpenter , "anima@ietf.org" Thread-Topic: [Anima] Test transmission Thread-Index: AQHPha7w7jSGVVKPA0OC2k9TZNB+NJtspmsQ Date: Thu, 12 Jun 2014 00:55:25 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AE8B06E@nkgeml512-mbx.china.huawei.com> References: <5398B3D9.6010206@gmail.com> In-Reply-To: <5398B3D9.6010206@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.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/anima/_3QCUy43LiclH4JaEExhhmSL0ZI Subject: Re: [Anima] Test transmission 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, 12 Jun 2014 00:55:37 -0000 PkknZCBhcHByZWNpYXRlIGEgdm9sdW50ZWVyIHRvIGFjdCBhcyB0aGUgc2Vjb25kIGxpc3QgYWRt aW5pc3RyYXRvcjsNCj5pdCdzIGEgc3RhbmRhcmQgbWFpbG1hbiBsaXN0Lg0KDQpJIGFtIHdpbGxp bmcgdG8gZG8gaXQuDQoNCkJlc3QgcmVnYXJkcywNCg0KU2hlbmcNCg0KPlJlZ2FyZHMNCj4gICBC cmlhbiBDYXJwZW50ZXINCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPkFuaW1hIG1haWxpbmcgbGlzdA0KPkFuaW1hQGlldGYub3JnDQo+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYQ0K From nobody Thu Jun 12 02:07:34 2014 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 8C98F1A0460 for ; Thu, 12 Jun 2014 02:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 AwLzGeXBFBLe for ; Thu, 12 Jun 2014 02:07:31 -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 5C0BB1A0199 for ; Thu, 12 Jun 2014 02:07:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4437; q=dns/txt; s=iport; t=1402564050; x=1403773650; h=message-id:date:from:mime-version:to:subject; bh=1ULbFZ4Lzz8FthSMoSfb5EVXabAQEN3Jvu3T3C5akHE=; b=CFvW7mp81TKn1bUZb9x4xU3Fof2tKkqShoaQrQwNf1j6Ap2uSKwlkMpa b0Zgxd/nFJw68hKrznweKdhZRAyFU7bCp7X2CkGlnxwtu8iU7+5Osy0CI hZ4GwM5YbsvA6iT/4Py7fLQhm01cnG0xGZ8XMyuz9sOksD5NpCBOclVyx M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmYFAEVtmVOtJssW/2dsb2JhbABag1+qJQEBAQEBAQUBmj91hH4EIB0WGAMCAQIBWAgBARYBiCcNohKvOReFXIgdEQGFGASaMoFDhTeMWIM+O4E5 X-IronPort-AV: E=Sophos; i="5.01,463,1400025600"; d="scan'208,217"; a="78781828" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 12 Jun 2014 09:07:28 +0000 Received: from [10.60.67.91] (ams-bclaise-89110.cisco.com [10.60.67.91]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s5C97SWJ000973 for ; Thu, 12 Jun 2014 09:07:28 GMT Message-ID: <53996DD0.8080604@cisco.com> Date: Thu, 12 Jun 2014 11:07:28 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: anima@ietf.org Content-Type: multipart/alternative; boundary="------------090202090806070903080909" Archived-At: http://mailarchive.ietf.org/arch/msg/anima/Beu06WAbIJbsP4Q9SyMTozqH8jI Subject: [Anima] UCAN BoF approved 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, 12 Jun 2014 09:07:32 -0000 This is a multi-part message in MIME format. --------------090202090806070903080909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, As the responsible AD, let me share the news: The IESG/IAB approved the UCAN BoF yesterday. Some concerns were discussed, which would need to addressed on this list, during the BoF preparation, or during the BoF: - What is the commonality between all the use cases? - How would the IETF attract people to work on this topic? For example, the operators. - Not sure there are universal solutions to the problem space, so it is not clear that we should work on the general rather than specific solutions - "100 people in the room is too optimistic", 30 is more realistic. I reduced it to 50 in the WIKI ACTION: this email should be forwarded to the homenet WG to attract more people IMO, a successful UCAN BoF would be: - You explain (draft-irtf-nmrg-autonomic-network-definitions , draft-irtf-nmrg-an-gap-analysis ) and you set up the stage on what AN is and what AN is not. The second part is equally important, when I see your BoF description "The fundamental goal of Autonomic Networking (AN) is self-management, including self-configuration, self-optimization, self-healing and self-protection. " - You provide the criteria for which use cases are in scope. - You review the different use cases, and try to classify them. - You try to deduce commonality/requirements between use cases or you decide on which specific pain points you want to work on. - You provide examples of protocol work you envision *This Bof is accepted, however this is a conditional acceptance*: BoF accepted at the condition that the proponents put some serious energy to finish the 2 NMRG drafts. Regards, Benoit --------------090202090806070903080909 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

As the responsible AD, let me share the news: The IESG/IAB approved the UCAN BoF yesterday.

Some concerns were discussed, which would need to addressed on this list, during the BoF preparation, or during the BoF:
- What is the commonality between all the use cases?
- How would the IETF attract people to work on this topic? For example, the operators.
- Not sure there are universal solutions to the problem space, so it is not clear that we should work on the general rather than specific solutions
- "100 people in the room is too optimistic", 30 is more realistic. I reduced it to 50 in the WIKI
    ACTION: this email should be forwarded to the homenet WG to attract more people

IMO, a successful UCAN BoF would be:
- You explain  (draft-irtf-nmrg-autonomic-network-definitions, draft-irtf-nmrg-an-gap-analysis) and you set up the stage on what AN is and what AN is not. The second part is equally important, when I see your BoF description "The fundamental goal of Autonomic Networking (AN) is self-management, including self-configuration, self-optimization, self-healing and self-protection. "
- You provide the criteria for which use cases are in scope.
- You review the different use cases, and try to classify them.
- You try to deduce commonality/requirements between use cases or you decide on which specific pain points you want to work on.
- You provide examples of protocol work you envision

This Bof is accepted, however this is a conditional acceptance: BoF accepted at the condition that the proponents put some serious energy to finish the 2 NMRG drafts.

Regards, Benoit
--------------090202090806070903080909-- From nobody Thu Jun 12 13:34:39 2014 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 D31301A0240 for ; Thu, 12 Jun 2014 13:34: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 1dPKBj8kCBkq for ; Thu, 12 Jun 2014 13:34:35 -0700 (PDT) Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFC531A023D for ; Thu, 12 Jun 2014 13:34:35 -0700 (PDT) Received: by mail-pb0-f42.google.com with SMTP id ma3so1124758pbc.15 for ; Thu, 12 Jun 2014 13:34: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:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jpdoX1ur3SNRdrcRUg1UyTw1rpT6cZE5SUSNuOQ7L3A=; b=QL74iFRIGcDVl7414n9QDs5D4I6DkWprQagB6DCqRngzvv6nhnBf1R5O7Po9EZ5RNp s9tV8XCXwd2U4Azkr/JFgV5c0vyyYKWTa0v6/7UQXpeqytt1xUwAq7yUKYkNa6eg5XfD tZ0fcwh3psmrpBfSObzbZFrInG05O1EJLCPexR1SYzN4616NxxSFxoxm95es+uxck0AT UoaVC18mzAKzf7VmXFOcFweI4I+YDG44xfCxdKvWghJdiWCbZ/ep7znvL4J1CjXyy6tu GEiUzZVNCyjkOgLdnkuFnLN/5OYtI9DcBRDRw7qnZnm5zwpEHNKME73WkJ0wZXGCigu9 bqYw== X-Received: by 10.66.121.197 with SMTP id lm5mr23932343pab.118.1402605275639; Thu, 12 Jun 2014 13:34:35 -0700 (PDT) Received: from [192.168.178.23] (148.200.69.111.dynamic.snap.net.nz. [111.69.200.148]) by mx.google.com with ESMTPSA id oa3sm82016147pbb.15.2014.06.12.13.34.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 13:34:35 -0700 (PDT) Message-ID: <539A0EE3.4040900@gmail.com> Date: Fri, 13 Jun 2014 08:34:43 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Benoit Claise References: <53996DD0.8080604@cisco.com> In-Reply-To: <53996DD0.8080604@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/bYqqZHUMOnkGLpaKthtafWIEzk4 Cc: anima@ietf.org Subject: Re: [Anima] UCAN BoF approved 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, 12 Jun 2014 20:34:38 -0000 Hi Benoit, On 12/06/2014 21:07, Benoit Claise wrote: > Dear all, > > As the responsible AD, let me share the news: The IESG/IAB approved the > UCAN BoF yesterday. Thank you very much for your support and advocacy! > > Some concerns were discussed, which would need to addressed on this > list, during the BoF preparation, or during the BoF: > - What is the commonality between all the use cases? I think that extracting that is the whole point of calling for and discussing the use cases, although it may need some detailed work after the BOF as well. > - How would the IETF attract people to work on this topic? For example, > the operators. That's why we want at least one real operator on the final agenda. While they may not do the detailed work, we definitely them to be present as customers for the work. > - Not sure there are universal solutions to the problem space, so it is > not clear that we should work on the general rather than specific solutions My personal opinion is that we will end up with a mixed solution, since we cannot abolish existing mechanisms. But do we really want a hundred flowers to bloom? I don't think so. > - "100 people in the room is too optimistic", 30 is more realistic. I > reduced it to 50 in the WIKI Well, I hope that's wrong, but we will see! > ACTION: this email should be forwarded to the homenet WG to attract > more people This email, or a more specific one? > > IMO, a successful UCAN BoF would be: > - You explain (draft-irtf-nmrg-autonomic-network-definitions > , > draft-irtf-nmrg-an-gap-analysis > ) and you > set up the stage on what AN is and what AN is not. The second part is > equally important, when I see your BoF description "The fundamental goal > of Autonomic Networking (AN) is self-management, including > self-configuration, self-optimization, self-healing and self-protection. " > - You provide the criteria for which use cases are in scope. > - You review the different use cases, and try to classify them. > - You try to deduce commonality/requirements between use cases or you > decide on which specific pain points you want to work on. > - You provide examples of protocol work you envision Yes. We'd like to add one short talk from an operator about expectations; since our first choice speaker has refused due to a change in his circumstances, we need another suggestion or volunteer. > > *This Bof is accepted, however this is a conditional acceptance*: BoF > accepted at the condition that the proponents put some serious energy to > finish the 2 NMRG drafts. Understood. Of course we cannot control the NMRG itself. Regards, Brian > > Regards, Benoit > > > ------------------------------------------------------------------------ > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Thu Jun 12 13:45:30 2014 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 0CDE41A0273 for ; Thu, 12 Jun 2014 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 VBgxnLDyxLch for ; Thu, 12 Jun 2014 13:45:28 -0700 (PDT) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7BE21A025E for ; Thu, 12 Jun 2014 13:45:27 -0700 (PDT) Received: by mail-pb0-f54.google.com with SMTP id jt11so1383655pbb.41 for ; Thu, 12 Jun 2014 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:content-type:content-transfer-encoding; bh=K1cuBPnUW36OCO9paa2CrwAthv45032q7TCpVAsyrPc=; b=nxnqWGccprIggpYV6LJPqMSKIkFVT/pYuUIrkt4DUe/va5FcSwQZtcH0TtE1w2OAkt XhzJlM4YdIqEJmD739+t6TXipjGIgJnEjwE3WAcyUmaRiL4XIBzB4ilYQ7obBWLvmhb7 3WAuiRhoBLVyIVatoF7aZJ6z9od7U8lMfw+t1enzMP9gl5HH2nWshZsWGJklnsLlKish wzMEXhVYn6T+vn9n6LrlsFlpxYGdi/WeR3Pg7Z3Jeq/J/Q5/8qA17fdrcYk7r5sivuaH 5sxAfDuGntYez/gUBzQcHDD9vpZiYFVPN7EyYtRq950T+ApnGXoqTbIBgx+frqJcUfHC qmAg== X-Received: by 10.69.19.225 with SMTP id gx1mr15340291pbd.34.1402605927663; Thu, 12 Jun 2014 13:45:27 -0700 (PDT) Received: from [192.168.178.23] (148.200.69.111.dynamic.snap.net.nz. [111.69.200.148]) by mx.google.com with ESMTPSA id pz10sm82018438pbb.33.2014.06.12.13.45.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 13:45:27 -0700 (PDT) Message-ID: <539A116F.6060204@gmail.com> Date: Fri, 13 Jun 2014 08:45:35 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: anima@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/anima/KwYQ4AAXTalBnjXY5q6Y6eVq6CY Subject: [Anima] Reading list 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, 12 Jun 2014 20:45:29 -0000 Hi, The very basic reading list for anima is: http://tools.ietf.org/html/draft-irtf-nmrg-autonomic-network-definitions =E2=80=8Bhttp://tools.ietf.org/html/draft-irtf-nmrg-an-gap-analysis Our most urgent task before the BOF is to bring those drafts up to date, so please review them as soon as possible. Although they are NMRG drafts, we can discuss them here. We have only about 3 weeks until the I-D cutoff (2014-07-04). The other drafts considered relevant are in the BOF description: http://trac.tools.ietf.org/bof/trac/wiki/WikiStart#UCANApprovedforIETF90 Brian From nobody Fri Jun 13 05:16:11 2014 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 7E97D1B2853 for ; Fri, 13 Jun 2014 05:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 ZXT66FDbd-iN for ; Fri, 13 Jun 2014 05:16:07 -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 658F11A04CA for ; Fri, 13 Jun 2014 05:16:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2479; q=dns/txt; s=iport; t=1402661767; x=1403871367; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ljBLgSBAcEctjvit2RCY0x8y7+oliiylADmdzstzi84=; b=MysoNYs/goZ/3c0V5tjGP9rHPqUk+nkZ0YTmjFVv7MKV5hJCx4nNmPkf H3mNhfF5ISqUOifMtUW5NXwWJ+EX4prut66hbSIw/WmiskRE2FwjuIZzA phbSw63Kf+0eVW7FyyeLAY44ShYg//sJ0Q+8BpfMh1vudxtRlgBeGJvqh 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As8FAJvqmlOtJssW/2dsb2JhbABag1+DRaZuAQQBBQGRY4c8AYEZdYQDAQEBAwEBAQEgFTYGBAEQCxoCBRYLAgIJAwIBAgEVMAYNAQUCAQGINggNslyfMxeBKoQyiB4RAVAHgnWBTAEDmjaBQ4U3jFqDPjuBOQ X-IronPort-AV: E=Sophos;i="5.01,471,1400025600"; d="scan'208";a="80122738" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 13 Jun 2014 12:16:05 +0000 Received: from [10.60.67.91] (ams-bclaise-89110.cisco.com [10.60.67.91]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s5DCG5VC005124; Fri, 13 Jun 2014 12:16:05 GMT Message-ID: <539AEB85.3020402@cisco.com> Date: Fri, 13 Jun 2014 14:16:05 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brian E Carpenter References: <53996DD0.8080604@cisco.com> <539A0EE3.4040900@gmail.com> In-Reply-To: <539A0EE3.4040900@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/1bX7cVnp8wbe_YnQq3WB_5GGiGU Cc: anima@ietf.org Subject: Re: [Anima] UCAN BoF approved 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, 13 Jun 2014 12:16:09 -0000 Hi Brian, > >> - How would the IETF attract people to work on this topic? For example, >> the operators. > That's why we want at least one real operator on the final agenda. While > they may not do the detailed work, we definitely them to be present as > customers for the work. Good. >> ACTION: this email should be forwarded to the homenet WG to attract >> more people > This email, or a more specific one? I would say: up to you to promote the BoF in the best possible way :-) > >> IMO, a successful UCAN BoF would be: >> - You explain (draft-irtf-nmrg-autonomic-network-definitions >> , >> draft-irtf-nmrg-an-gap-analysis >> ) and you >> set up the stage on what AN is and what AN is not. The second part is >> equally important, when I see your BoF description "The fundamental goal >> of Autonomic Networking (AN) is self-management, including >> self-configuration, self-optimization, self-healing and self-protection. " >> - You provide the criteria for which use cases are in scope. >> - You review the different use cases, and try to classify them. >> - You try to deduce commonality/requirements between use cases or you >> decide on which specific pain points you want to work on. >> - You provide examples of protocol work you envision > Yes. We'd like to add one short talk from an operator about expectations; > since our first choice speaker has refused due to a change in his > circumstances, we need another suggestion or volunteer. Good addition. > >> *This Bof is accepted, however this is a conditional acceptance*: BoF >> accepted at the condition that the proponents put some serious energy to >> finish the 2 NMRG drafts. > Understood. Of course we cannot control the NMRG itself. Interestingly, my previous paragraph initially continued like this : "Not sure I would have a way to enforce this tough. " :-) The point is that, since we deal with the same set of people, this "milestone" would be a good indication of your willingness to make this work happen. Regards, Benoit > > Regards, > Brian > >> Regards, Benoit >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > . > From nobody Mon Jun 16 10:05:34 2014 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 61D6D1A00C9 for ; Mon, 16 Jun 2014 10:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 nNT2ajDNqsJb for ; Mon, 16 Jun 2014 10:05:31 -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 0BF861A000B for ; Mon, 16 Jun 2014 10:05:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=432; q=dns/txt; s=iport; t=1402938331; x=1404147931; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=5Qnt0dQ1Fwts0eDpBXjBqZUB/BxatXkCWYjaxGO5eBQ=; b=JwmAkLP+sKjYS4TgvvenznlOQhwCp+PXD1waES6lE0U6SL4it6d/vYM7 L6XqBU9eaMGoNOQoz8ltt7QsbNsbQAhADJnZf8kKLFWssls273zNFphBP YOEmiOoUnFFiaYHSlgdGzGliRMtlZgZ0Td+HH1MDde17AxzF7Crwuxjw6 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At8FAHASn1OtJA2L/2dsb2JhbABagw2BLKlvAQEBAQEBBQEFmR8BgREWdYQFAQQ6UQEqFEImAQQbiDqiD60gF4VjiGKDZYEWBK4bg0CCMA X-IronPort-AV: E=Sophos;i="5.01,487,1400025600"; d="scan'208";a="333470149" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-6.cisco.com with ESMTP; 16 Jun 2014 17:05:30 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s5GH5UfC008899 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 16 Jun 2014 17:05:30 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Mon, 16 Jun 2014 12:05:30 -0500 From: "Michael Behringer (mbehring)" To: "anima@ietf.org" Thread-Topic: Review of draft-irtf-nmrg-autonomic-network-definitions-00 Thread-Index: Ac+JgvaPHDoyXljjTxupgmBZU4xEaA== Date: Mon, 16 Jun 2014 17:05:29 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BB3787@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.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/anima/FBnq7CGPOqrmDj4iZdbKHSqXnyQ Subject: [Anima] Review of draft-irtf-nmrg-autonomic-network-definitions-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: Mon, 16 Jun 2014 17:05:33 -0000 I'm starting to work on the next version of draft-irtf-nmrg-autonomic-netwo= rk-definitions-00.=20 We should try to finalise this document asap; please review the document an= d provide your feedback here on this list. If you are ok with the document = as it is, please also state this. In addition to detailed comments, we need= a good feeling on how far away we are from a potential final version.=20 Thanks, Michael From nobody Mon Jun 16 13:38:14 2014 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 934EF1A01EB for ; Mon, 16 Jun 2014 13:37:41 -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 rH84n7WsLJaP for ; Mon, 16 Jun 2014 13:37:32 -0700 (PDT) Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A53C71A00DA for ; Mon, 16 Jun 2014 13:37:32 -0700 (PDT) Received: by mail-pb0-f53.google.com with SMTP id uo5so4596064pbc.12 for ; Mon, 16 Jun 2014 13:37:32 -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=uMh6j6THgzOgoiNtUo7c8xyKluVwKTU/lncUlnSB5So=; b=kCw9unkjRz4wW1T5Hao7Tr1tBtJmnCgsxaYmgJoRX9D8EkBrhlgXQ+13ZrPBVIIvHK E0bVOkbteFh7ESkgip2zBrozcA06T3P9v/KqKBDjosotB45EBxyQXUAQU+8ZZ0ilIc7v 9jicXZ+xhQvY9e6ZeY5OlvbzoGFGfJQDUF18NEGcgH+nyXiThVB3m7j/i+YHDvJU5lFm F7B20Y/3MHgzMhfSMyteQBWNloJR0EdDXWLEuwAdttRBcq1dPSIa1fG58oHBgJ3mx1cV CgerEnhEh/sakEQ0TL3Tx+qWQQHziK8NRcBjlzC5x5zowB2J0a4FGBaDPYP6wieUjwwr Nq4A== X-Received: by 10.66.100.200 with SMTP id fa8mr26958802pab.23.1402951052344; Mon, 16 Jun 2014 13:37:32 -0700 (PDT) Received: from [192.168.178.23] (10.192.69.111.dynamic.snap.net.nz. [111.69.192.10]) by mx.google.com with ESMTPSA id io8sm20322948pbc.96.2014.06.16.13.37.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Jun 2014 13:37:31 -0700 (PDT) Message-ID: <539F558B.8040701@gmail.com> Date: Tue, 17 Jun 2014 08:37:31 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Michael Behringer (mbehring)" References: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BB3787@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BB3787@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/uGc7mncd2JweAIwoyGkGRM8D9IM Cc: "anima@ietf.org" Subject: Re: [Anima] Review of draft-irtf-nmrg-autonomic-network-definitions-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: Mon, 16 Jun 2014 20:37:41 -0000 X-List-Received-Date: Mon, 16 Jun 2014 20:37:41 -0000 Let me add my request to Michael's. The authors have been staring at this draft for too long so we need new eyes to look at it. What is not clear to you? What is missing? There is one section we definitely have to update: > 5. Guidelines for Case Studies > > [This section is work in progress.] However, this was discussed a few months ago on the NMRG list, so we have draft text for this already, and a few use case documents to validate it. Regards Brian On 17/06/2014 05:05, Michael Behringer (mbehring) wrote: > I'm starting to work on the next version of draft-irtf-nmrg-autonomic-network-definitions-00. > > We should try to finalise this document asap; please review the document and provide your feedback here on this list. If you are ok with the document as it is, please also state this. In addition to detailed comments, we need a good feeling on how far away we are from a potential final version. > > Thanks, > Michael > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Mon Jun 16 15:49:39 2014 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 F103B1A01D6; Mon, 16 Jun 2014 13:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_MIME_NO_TEXT=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 Jz7xNtI0B6dv; Mon, 16 Jun 2014 13:13:14 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ECBB1A01C7; Mon, 16 Jun 2014 13:13:14 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id B88DC20011; Mon, 16 Jun 2014 16:17:05 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id A69DC63B0E; Mon, 16 Jun 2014 16:13:12 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 96EEA63B0A; Mon, 16 Jun 2014 16:13:12 -0400 (EDT) From: Michael Richardson To: anima@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/anima/BAbcycIv86DQe2bvCdSVHHsJcVA X-Mailman-Approved-At: Mon, 16 Jun 2014 15:49:34 -0700 Cc: 6tisch-security <6tisch-security@ietf.org> Subject: [Anima] autonomic bootstrap: gap analysis X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: anima@ietf.org List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 20:13:21 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable I recognize that bootstrap is only one of the autonomic mechanisms that are relevant to this group. I have much reading on the other aspects which I hope to get done. The 6tisch security design team has been working on a "zero-touch" mechanism that would permit constrained devices to join a Lowpower/Loss Network (LLN) in a secure way. We have considered adapting EAP-TLS (as ZigbeeIP has done), or turning the WirelessHART (IEC62591) packet flow into something mo= re IPv6-like. While there are significant bits of design space to explore while trying to optimize packet count, size and total energy risk of the join protocol; the idea that there should be a set of authorization tokens From=20the device vendor which would permit the network and new nodes to recognize each other has been central to all discussions. while draft-pritikin-bootstrapping-keyinfrastructures and draft-behringer-autonomic-bootstrap-00 have proposed valid high level concepts, I believe that specification of the authz token is critical for the IoT space. A great concern that is that the LLNs created remain operational for decades at a time, and that the components can individually and also in aggregate be both (re-)sold, and/or the service provider operating the network be replaced. (There are real life examples where a part of a 100 square mile refinery is actually sold to a competitor; obviously it doesn't get moved. On the other side, one has the very real risk that you bought your sensor network From=20a "Nortel") I was pointed at 802.1AR's device ID mechanism. Really, 802.1AR is about an API between a (constrained) device and it's cryptographic hardware module/TPM. It profiles a number of IETF PKIX specifications in a useful way, but there is little there in terms of actual protocol. When it comes = to what does an *DevID look like, in it's section 7.2.8, saying that the DN should contain a "serialNumber" attribute: The formatting of this field shall contain a unique X.500 Distinguished Name (DN). This may include the unique device serial numbe= r assigned by the manufacturer or any other suitable unique DN value that the issuer prefers. What I have observed is that there needs to be a way to clearly delegate fr= om Factory(Vendor) to VAR to DISTRIBUTOR to RESELLER to Plant-OWNER to SERVICE-PROVIDER. It would significantly reduce the number of certificat= es in (non-constrained device) databases for some levels of this hierarchy if the IDevID were aggregateable in some fashion. RFC3779 came to mind, which deals with delegation of Autonomous Systems Numbers (ASN) and IP address ranges from RIRs to LIRs to ISPs and Enterprises. RFC3779: X.509 Extensions for IP Addresses and AS Identifiers I created: X509.v3 certificate extension for authorization of device ownership draft-richardson-6tisch-idevid-cert-00 which cribbed together via nroff2xml and a search and replace. The Pritikin and Behringer documents seem to assume that the ultimate goal = of the trusted enrollment process is to create a path in which "EST"=3D Enroll= ment over Secure Transport could operate that would permit a new locally significant certificate to be loaded into the new device. I agree with that goal. There is the question of how that trust circuit is created, and in discussi= on it seemed that it involve some kind of leap-of-faith TLS setup which would = be authenticated by the "authz" tokens later on. I disagree; I think that with appropriate evaluation of path constraints that the authentication can occur within the TLS protocol. (Even easier if done in IKEv2) =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU59P2ICLcPvd0N1lAQLqrggAhrRKqmv7h4vARo3LgeplKsw7ghMCA+ho KRE6ESV4geNv54RRCQAH1w56wm9Leg1zRk7Dx23BDuU2IZibrYgv6rWnMpVQE6u9 cD785znF4hlLUAYy8hhlFJoz4l0XfK17kMWN9GXkNKFzhZogB2HoHV6IMXpfIbLH +VUEGxTGC950nloG8dCU4mpK4KgW6dmKDcTjoXR5Ymtp0EVYZZsMtWocWOHSnWLl +sBsb9nGVF3WGH5n//Gq36a504B/ixqk4oCGm/XAFOC+zxZXc8Fx8jBZHwHkENzi cu+akpKy5P0CsQmx+5AdqB15h82eq5CyuLoVLeLztVNewQX7JeIn+Q== =h6ra -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 16 16:00:49 2014 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 B1BA31A02B3; Mon, 16 Jun 2014 16:00: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 gDQKEkLpNuzo; Mon, 16 Jun 2014 16:00:44 -0700 (PDT) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E45E11A02A8; Mon, 16 Jun 2014 16:00:43 -0700 (PDT) Received: by mail-pd0-f179.google.com with SMTP id w10so2252825pde.24 for ; Mon, 16 Jun 2014 16:00:43 -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=7hoSwgd8rh5ckrYFcje5ScKq2UK/DXdDO2/0uy6kPe4=; b=0zRYQ69lsHPHgHzmDzSwXTnElSloVBNLrD8LFWJCsZKTo4pKM8kKC/jEts0g4eIhlP UgDZHutRqzvgzlVigFyXZOH1hEfWeBlTx8WBJtS7i5DcRqQREp/uDy92BoTk0W4LBXsF 2ogqxu5h+ibWAZS1xcKYcb6TDfnOfXhBx+8nAdqJm77nD+b4VFjpFuWzei5n4s5bfF0u NDeRmVwz4T5IZDvWa4xTvlazCAaYSToImIpWre/B80R/5C7fEKF8W7PzMg/0YAkf7zgA +eppNH27rah511M/ld3GLisWzebOtrSmfl/eAAAVXf0+CawrZnL3HZ5zNrIO2EuV/p6r 7Fpg== X-Received: by 10.68.194.202 with SMTP id hy10mr28064686pbc.94.1402959643574; Mon, 16 Jun 2014 16:00:43 -0700 (PDT) Received: from [192.168.178.23] (10.192.69.111.dynamic.snap.net.nz. [111.69.192.10]) by mx.google.com with ESMTPSA id ue3sm20664327pbc.49.2014.06.16.16.00.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Jun 2014 16:00:42 -0700 (PDT) Message-ID: <539F771A.3000008@gmail.com> Date: Tue, 17 Jun 2014 11:00:42 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: anima@ietf.org References: <26717.1402949592@sandelman.ca> In-Reply-To: <26717.1402949592@sandelman.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/CWuHRkmYTimdf2cNyCLo1TxUbao Cc: 6tisch-security <6tisch-security@ietf.org> Subject: [Anima] Scope question [was: autonomic bootstrap: gap analysis] 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, 16 Jun 2014 23:00:46 -0000 Michael's message is very interesting. For present purposes, i.e. getting ready for the UCAN BOF, do we need to add some points to the relevant use case draft (http://tools.ietf.org/html/draft-behringer-autonomic-bootstrap)? More generally - I think the AN protagonists have been thinking of the scope of AN being carrier, enterprise, and home networks. Should we add IoT to the scope? I think it's an important question, because it would put new meanings on "simple" and "available resources". It seems obvious that IoT networks need to be completely autonomic, but is it the *same* autonomic? Regards Brian On 17/06/2014 08:13, Michael Richardson wrote: > I recognize that bootstrap is only one of the autonomic mechanisms that > are relevant to this group. I have much reading on the other aspects > which I hope to get done. > > The 6tisch security design team has been working on a "zero-touch" mechanism > that would permit constrained devices to join a Lowpower/Loss Network (LLN) > in a secure way. We have considered adapting EAP-TLS (as ZigbeeIP has > done), or turning the WirelessHART (IEC62591) packet flow into something more > IPv6-like. While there are significant bits of design space to explore > while trying to optimize packet count, size and total energy risk of the > join protocol; the idea that there should be a set of authorization tokens > From the device vendor which would permit the network and new nodes to > recognize each other has been central to all discussions. > > while draft-pritikin-bootstrapping-keyinfrastructures and > draft-behringer-autonomic-bootstrap-00 > > have proposed valid high level concepts, I believe that specification of the > authz token is critical for the IoT space. A great concern that is that the > LLNs created remain operational for decades at a time, and that the > components can individually and also in aggregate be both (re-)sold, > and/or the service provider operating the network be replaced. > > (There are real life examples where a part of a 100 square mile refinery > is actually sold to a competitor; obviously it doesn't get moved. On the > other side, one has the very real risk that you bought your sensor network > From a "Nortel") > > I was pointed at 802.1AR's device ID mechanism. Really, 802.1AR is about an > API between a (constrained) device and it's cryptographic hardware > module/TPM. It profiles a number of IETF PKIX specifications in a useful > way, but there is little there in terms of actual protocol. When it comes to > what does an *DevID look like, in it's section 7.2.8, saying that the DN > should contain a "serialNumber" attribute: > > The formatting of this field shall contain a unique X.500 > Distinguished Name (DN). This may include the unique device serial number assigned by the manufacturer > or any other suitable unique DN value that the issuer prefers. > > What I have observed is that there needs to be a way to clearly delegate from > Factory(Vendor) to VAR to DISTRIBUTOR to RESELLER to Plant-OWNER to > SERVICE-PROVIDER. It would significantly reduce the number of certificates > in (non-constrained device) databases for some levels of this hierarchy if > the IDevID were aggregateable in some fashion. RFC3779 came to mind, which > deals with delegation of Autonomous Systems Numbers (ASN) and IP address > ranges from RIRs to LIRs to ISPs and Enterprises. > RFC3779: X.509 Extensions for IP Addresses and AS Identifiers > > I created: > X509.v3 certificate extension for authorization of device ownership > draft-richardson-6tisch-idevid-cert-00 > > which cribbed together via nroff2xml and a search and replace. > > The Pritikin and Behringer documents seem to assume that the ultimate goal of > the trusted enrollment process is to create a path in which "EST"= Enrollment > over Secure Transport could operate that would permit a new locally > significant certificate to be loaded into the new device. > I agree with that goal. > > There is the question of how that trust circuit is created, and in discussion > it seemed that it involve some kind of leap-of-faith TLS setup which would be > authenticated by the "authz" tokens later on. I disagree; I think that with > appropriate evaluation of path constraints that the authentication can occur > within the TLS protocol. (Even easier if done in IKEv2) > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > From nobody Mon Jun 16 23:19:28 2014 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 628BF1A0284; Mon, 16 Jun 2014 23:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 7GmRpHpVEKSU; Mon, 16 Jun 2014 23:19:23 -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 663C31A027F; Mon, 16 Jun 2014 23:19:22 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFM87509; Tue, 17 Jun 2014 06:19:21 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 17 Jun 2014 07:19:20 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.68]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Tue, 17 Jun 2014 14:19:15 +0800 From: Sheng Jiang To: Brian E Carpenter , "anima@ietf.org" Thread-Topic: [Anima] Scope question [was: autonomic bootstrap: gap analysis] Thread-Index: AQHPibbV52AKeSyN3kOxWJK/qa8C6Jt0rREQ Date: Tue, 17 Jun 2014 06:19:14 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AE8CBDD@nkgeml512-mbx.china.huawei.com> References: <26717.1402949592@sandelman.ca> <539F771A.3000008@gmail.com> In-Reply-To: <539F771A.3000008@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.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/anima/EDgtWBUFr9qoOPnPtfqP4x_fDxY Cc: 6tisch-security <6tisch-security@ietf.org> Subject: Re: [Anima] Scope question [was: autonomic bootstrap: gap analysis] 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, 17 Jun 2014 06:19:26 -0000 Pk1pY2hhZWwncyBtZXNzYWdlIGlzIHZlcnkgaW50ZXJlc3RpbmcuIEZvciBwcmVzZW50IHB1cnBv c2VzLA0KPmkuZS4gZ2V0dGluZyByZWFkeSBmb3IgdGhlIFVDQU4gQk9GLCBkbyB3ZSBuZWVkIHRv IGFkZCBzb21lDQo+cG9pbnRzIHRvIHRoZSByZWxldmFudCB1c2UgY2FzZSBkcmFmdA0KPihodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iZWhyaW5nZXItYXV0b25vbWljLWJvb3RzdHJh cCk/DQo+DQo+TW9yZSBnZW5lcmFsbHkgLSBJIHRoaW5rIHRoZSBBTiBwcm90YWdvbmlzdHMgaGF2 ZSBiZWVuIHRoaW5raW5nDQo+b2YgdGhlIHNjb3BlIG9mIEFOIGJlaW5nIGNhcnJpZXIsIGVudGVy cHJpc2UsIGFuZCBob21lIG5ldHdvcmtzLg0KPlNob3VsZCB3ZSBhZGQgSW9UIHRvIHRoZSBzY29w ZT8gSSB0aGluayBpdCdzIGFuIGltcG9ydGFudA0KPnF1ZXN0aW9uLCBiZWNhdXNlIGl0IHdvdWxk IHB1dCBuZXcgbWVhbmluZ3Mgb24gInNpbXBsZSIgYW5kDQo+ImF2YWlsYWJsZSByZXNvdXJjZXMi LiBJdCBzZWVtcyBvYnZpb3VzIHRoYXQgSW9UIG5ldHdvcmtzIG5lZWQNCj50byBiZSBjb21wbGV0 ZWx5IGF1dG9ub21pYywgYnV0IGlzIGl0IHRoZSAqc2FtZSogYXV0b25vbWljPw0KDQpJbmRlZWQs IHRoZSBzY29wZSBpcyBhbiBpbXBvcnRhbnQgcXVlc3Rpb24uIEZvciBtZSwgdGhlIGFuc3dlciBy ZWx5IG9uIHNvbHV0aW9uIHJhdGhlciB0aGFuIGF1dG9ub21pYyBjb25jZXB0LiBFdmVyeSBuZXR3 b3JrLCBubyBtYXR0ZXIgd2hhdCBraW5kIG9mIG5ldHdvcmsgaXQgaXMsIGhhcyB0aGUgcmVxdWly ZW1lbnRzIHRvIGJlIGF1dG9ub21pYywgb3IgbW9yZSBhbmQgbW9yZSBhdXRvbm9taWMuIEhvd2V2 ZXIsIGdpdmluZyB0aGUgZGlmZmVyZW5jZXMgb2YgdGhlc2UgbmV0d29ya3MsIHdlIG1heSBub3Qg YmUgYWJsZSB0byBmaW5kIGEgZ2VuZXJpYyBzb2x1dGlvbiB0aGF0IHN1aXRzIGFsbC4gSXQgaXMg dGltZSBmb3IgdXMgdG8gc3RhcnQgZGlzY3VzcyB0aGUgcG90ZW50aWFsIHNvbHV0aW9uIGFuZCB0 aGVpciBzdWl0YWJsZSBzY2VuYXJpb3MuIEFmdGVyIHRoZW4sIHdlIG1heSBrbm93IHdoZXRoZXIg d2UgY2FuIHVuaWZ5IGludG8gdGhlIHNhbWUgYXV0b25vbWljIG5ldHdvcmsgb3Igd2UgaGF2ZSB0 byBzZXR0bGUgb24gbW9yZSB0aGFuIG9uZSBhdXRvbm9taWMgbmV0d29yayBhcmNoaXRlY3R1cmUu DQoNClJlZ2FyZHMsDQoNClNoZW5nDQoNCj5SZWdhcmRzDQo+ICAgQnJpYW4NCj4NCj5PbiAxNy8w Ni8yMDE0IDA4OjEzLCBNaWNoYWVsIFJpY2hhcmRzb24gd3JvdGU6DQo+PiBJIHJlY29nbml6ZSB0 aGF0IGJvb3RzdHJhcCBpcyBvbmx5IG9uZSBvZiB0aGUgYXV0b25vbWljIG1lY2hhbmlzbXMgdGhh dA0KPj4gYXJlIHJlbGV2YW50IHRvIHRoaXMgZ3JvdXAuICBJIGhhdmUgbXVjaCByZWFkaW5nIG9u IHRoZSBvdGhlciBhc3BlY3RzDQo+PiB3aGljaCBJIGhvcGUgdG8gZ2V0IGRvbmUuDQo+Pg0KPj4g VGhlIDZ0aXNjaCBzZWN1cml0eSBkZXNpZ24gdGVhbSBoYXMgYmVlbiB3b3JraW5nIG9uIGEgInpl cm8tdG91Y2giDQo+bWVjaGFuaXNtDQo+PiB0aGF0IHdvdWxkIHBlcm1pdCBjb25zdHJhaW5lZCBk ZXZpY2VzIHRvIGpvaW4gYSBMb3dwb3dlci9Mb3NzIE5ldHdvcmsNCj4oTExOKQ0KPj4gaW4gYSBz ZWN1cmUgd2F5LiAgIFdlIGhhdmUgY29uc2lkZXJlZCBhZGFwdGluZyBFQVAtVExTIChhcyBaaWdi ZWVJUCBoYXMNCj4+IGRvbmUpLCBvciB0dXJuaW5nIHRoZSBXaXJlbGVzc0hBUlQgKElFQzYyNTkx KSBwYWNrZXQgZmxvdyBpbnRvIHNvbWV0aGluZw0KPm1vcmUNCj4+IElQdjYtbGlrZS4gIFdoaWxl IHRoZXJlIGFyZSBzaWduaWZpY2FudCBiaXRzIG9mIGRlc2lnbiBzcGFjZSB0byBleHBsb3JlDQo+ PiB3aGlsZSB0cnlpbmcgdG8gb3B0aW1pemUgcGFja2V0IGNvdW50LCBzaXplIGFuZCB0b3RhbCBl bmVyZ3kgcmlzayBvZiB0aGUNCj4+IGpvaW4gcHJvdG9jb2w7ICB0aGUgaWRlYSB0aGF0IHRoZXJl IHNob3VsZCBiZSBhIHNldCBvZiBhdXRob3JpemF0aW9uIHRva2Vucw0KPj4gRnJvbSB0aGUgZGV2 aWNlIHZlbmRvciB3aGljaCB3b3VsZCBwZXJtaXQgdGhlIG5ldHdvcmsgYW5kIG5ldyBub2RlcyB0 bw0KPj4gcmVjb2duaXplIGVhY2ggb3RoZXIgaGFzIGJlZW4gY2VudHJhbCB0byBhbGwgZGlzY3Vz c2lvbnMuDQo+Pg0KPj4gd2hpbGUgZHJhZnQtcHJpdGlraW4tYm9vdHN0cmFwcGluZy1rZXlpbmZy YXN0cnVjdHVyZXMgYW5kDQo+PiAgICAgICBkcmFmdC1iZWhyaW5nZXItYXV0b25vbWljLWJvb3Rz dHJhcC0wMA0KPj4NCj4+IGhhdmUgcHJvcG9zZWQgdmFsaWQgaGlnaCBsZXZlbCBjb25jZXB0cywg SSBiZWxpZXZlIHRoYXQgc3BlY2lmaWNhdGlvbiBvZiB0aGUNCj4+IGF1dGh6IHRva2VuIGlzIGNy aXRpY2FsIGZvciB0aGUgSW9UIHNwYWNlLiAgQSBncmVhdCBjb25jZXJuIHRoYXQgaXMgdGhhdCB0 aGUNCj4+IExMTnMgY3JlYXRlZCByZW1haW4gb3BlcmF0aW9uYWwgZm9yIGRlY2FkZXMgYXQgYSB0 aW1lLCBhbmQgdGhhdCB0aGUNCj4+IGNvbXBvbmVudHMgY2FuIGluZGl2aWR1YWxseSBhbmQgYWxz byBpbiBhZ2dyZWdhdGUgYmUgYm90aCAocmUtKXNvbGQsDQo+PiBhbmQvb3IgdGhlIHNlcnZpY2Ug cHJvdmlkZXIgb3BlcmF0aW5nIHRoZSBuZXR3b3JrIGJlIHJlcGxhY2VkLg0KPj4NCj4+IChUaGVy ZSBhcmUgcmVhbCBsaWZlIGV4YW1wbGVzIHdoZXJlIGEgcGFydCBvZiBhIDEwMCBzcXVhcmUgbWls ZSByZWZpbmVyeQ0KPj4gaXMgYWN0dWFsbHkgc29sZCB0byBhIGNvbXBldGl0b3I7IG9idmlvdXNs eSBpdCBkb2Vzbid0IGdldCBtb3ZlZC4gIE9uIHRoZQ0KPj4gb3RoZXIgc2lkZSwgb25lIGhhcyB0 aGUgdmVyeSByZWFsIHJpc2sgdGhhdCB5b3UgYm91Z2h0IHlvdXIgc2Vuc29yIG5ldHdvcmsNCj4+ IEZyb20gYSAiTm9ydGVsIikNCj4+DQo+PiBJIHdhcyBwb2ludGVkIGF0IDgwMi4xQVIncyBkZXZp Y2UgSUQgbWVjaGFuaXNtLiAgUmVhbGx5LCA4MDIuMUFSIGlzIGFib3V0DQo+YW4NCj4+IEFQSSBi ZXR3ZWVuIGEgKGNvbnN0cmFpbmVkKSBkZXZpY2UgYW5kIGl0J3MgY3J5cHRvZ3JhcGhpYyBoYXJk d2FyZQ0KPj4gbW9kdWxlL1RQTS4gICBJdCBwcm9maWxlcyBhIG51bWJlciBvZiBJRVRGIFBLSVgg c3BlY2lmaWNhdGlvbnMgaW4gYSB1c2VmdWwNCj4+IHdheSwgYnV0IHRoZXJlIGlzIGxpdHRsZSB0 aGVyZSBpbiB0ZXJtcyBvZiBhY3R1YWwgcHJvdG9jb2wuICBXaGVuIGl0IGNvbWVzIHRvDQo+PiB3 aGF0IGRvZXMgYW4gKkRldklEIGxvb2sgbGlrZSwgaW4gaXQncyBzZWN0aW9uIDcuMi44LCBzYXlp bmcgdGhhdCB0aGUgRE4NCj4+IHNob3VsZCBjb250YWluIGEgInNlcmlhbE51bWJlciIgYXR0cmli dXRlOg0KPj4NCj4+ICAgIFRoZSBmb3JtYXR0aW5nIG9mIHRoaXMgZmllbGQgc2hhbGwgY29udGFp biBhIHVuaXF1ZSBYLjUwMA0KPj4gICAgRGlzdGluZ3Vpc2hlZCBOYW1lIChETikuIFRoaXMgbWF5 IGluY2x1ZGUgdGhlIHVuaXF1ZSBkZXZpY2Ugc2VyaWFsDQo+bnVtYmVyIGFzc2lnbmVkIGJ5IHRo ZSBtYW51ZmFjdHVyZXINCj4+ICAgIG9yIGFueSBvdGhlciBzdWl0YWJsZSB1bmlxdWUgRE4gdmFs dWUgdGhhdCB0aGUgaXNzdWVyIHByZWZlcnMuDQo+Pg0KPj4gV2hhdCBJIGhhdmUgb2JzZXJ2ZWQg aXMgdGhhdCB0aGVyZSBuZWVkcyB0byBiZSBhIHdheSB0byBjbGVhcmx5IGRlbGVnYXRlDQo+ZnJv bQ0KPj4gRmFjdG9yeShWZW5kb3IpIHRvIFZBUiB0byBESVNUUklCVVRPUiB0byBSRVNFTExFUiB0 byBQbGFudC1PV05FUiB0bw0KPj4gU0VSVklDRS1QUk9WSURFUi4gICAgSXQgd291bGQgc2lnbmlm aWNhbnRseSByZWR1Y2UgdGhlIG51bWJlciBvZg0KPmNlcnRpZmljYXRlcw0KPj4gaW4gKG5vbi1j b25zdHJhaW5lZCBkZXZpY2UpIGRhdGFiYXNlcyBmb3Igc29tZSBsZXZlbHMgb2YgdGhpcyBoaWVy YXJjaHkgaWYNCj4+IHRoZSBJRGV2SUQgd2VyZSBhZ2dyZWdhdGVhYmxlIGluIHNvbWUgZmFzaGlv bi4gIFJGQzM3NzkgY2FtZSB0byBtaW5kLA0KPndoaWNoDQo+PiBkZWFscyB3aXRoIGRlbGVnYXRp b24gb2YgQXV0b25vbW91cyBTeXN0ZW1zIE51bWJlcnMgKEFTTikgYW5kIElQDQo+YWRkcmVzcw0K Pj4gcmFuZ2VzIGZyb20gUklScyB0byBMSVJzIHRvIElTUHMgYW5kIEVudGVycHJpc2VzLg0KPj4g ICAgICAgICAgIFJGQzM3Nzk6IFguNTA5IEV4dGVuc2lvbnMgZm9yIElQIEFkZHJlc3NlcyBhbmQg QVMgSWRlbnRpZmllcnMNCj4+DQo+PiBJIGNyZWF0ZWQ6DQo+PiAgICAgWDUwOS52MyBjZXJ0aWZp Y2F0ZSBleHRlbnNpb24gZm9yIGF1dGhvcml6YXRpb24gb2YgZGV2aWNlIG93bmVyc2hpcA0KPj4g ICAgICAgICAgICAgICAgICBkcmFmdC1yaWNoYXJkc29uLTZ0aXNjaC1pZGV2aWQtY2VydC0wMA0K Pj4NCj4+IHdoaWNoIGNyaWJiZWQgdG9nZXRoZXIgdmlhIG5yb2ZmMnhtbCBhbmQgYSBzZWFyY2gg YW5kIHJlcGxhY2UuDQo+Pg0KPj4gVGhlIFByaXRpa2luIGFuZCBCZWhyaW5nZXIgZG9jdW1lbnRz IHNlZW0gdG8gYXNzdW1lIHRoYXQgdGhlIHVsdGltYXRlDQo+Z29hbCBvZg0KPj4gdGhlIHRydXN0 ZWQgZW5yb2xsbWVudCBwcm9jZXNzIGlzIHRvIGNyZWF0ZSBhIHBhdGggaW4gd2hpY2ggIkVTVCI9 DQo+RW5yb2xsbWVudA0KPj4gb3ZlciBTZWN1cmUgVHJhbnNwb3J0IGNvdWxkIG9wZXJhdGUgdGhh dCB3b3VsZCBwZXJtaXQgYSBuZXcgbG9jYWxseQ0KPj4gc2lnbmlmaWNhbnQgY2VydGlmaWNhdGUg dG8gYmUgbG9hZGVkIGludG8gdGhlIG5ldyBkZXZpY2UuDQo+PiBJIGFncmVlIHdpdGggdGhhdCBn b2FsLg0KPj4NCj4+IFRoZXJlIGlzIHRoZSBxdWVzdGlvbiBvZiBob3cgdGhhdCB0cnVzdCBjaXJj dWl0IGlzIGNyZWF0ZWQsIGFuZCBpbiBkaXNjdXNzaW9uDQo+PiBpdCBzZWVtZWQgdGhhdCBpdCBp bnZvbHZlIHNvbWUga2luZCBvZiBsZWFwLW9mLWZhaXRoIFRMUyBzZXR1cCB3aGljaCB3b3VsZA0K PmJlDQo+PiBhdXRoZW50aWNhdGVkIGJ5IHRoZSAiYXV0aHoiIHRva2VucyBsYXRlciBvbi4gIEkg ZGlzYWdyZWU7IEkgdGhpbmsgdGhhdCB3aXRoDQo+PiBhcHByb3ByaWF0ZSBldmFsdWF0aW9uIG9m IHBhdGggY29uc3RyYWludHMgdGhhdCB0aGUgYXV0aGVudGljYXRpb24gY2FuDQo+b2NjdXINCj4+ IHdpdGhpbiB0aGUgVExTIHByb3RvY29sLiAoRXZlbiBlYXNpZXIgaWYgZG9uZSBpbiBJS0V2MikN Cj4+DQo+PiAtLQ0KPj4gTWljaGFlbCBSaWNoYXJkc29uIDxtY3IrSUVURkBzYW5kZWxtYW4uY2E+ LCBTYW5kZWxtYW4gU29mdHdhcmUNCj5Xb3Jrcw0KPj4gIC09IElQdjYgSW9UIGNvbnN1bHRpbmcg PS0NCj4+DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj5BbmltYSBtYWlsaW5nIGxpc3QNCj5BbmltYUBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWENCg== From nobody Mon Jun 16 23:49:05 2014 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 413A31A029B for ; Mon, 16 Jun 2014 23:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 fbxJSw_ZWBaM for ; Mon, 16 Jun 2014 23:49:00 -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 7ADA81A0289 for ; Mon, 16 Jun 2014 23:49:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2000; q=dns/txt; s=iport; t=1402987741; x=1404197341; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=u/7cLCJLJvJW18nvGTrG8ppN29Ep7GIxD/Zxd3Zj9NI=; b=dBZDaBQ6odIvENaLAPNz+E87/lCRihqKoi/2+zEJXGkBHCnvOeKh42c5 0v+TBj58voa8sKYFZItaUWaN7In5LjVegztNTFGqZtBqAKWa7tNWCPMr2 lGjN9aZc2EDQzhkiLmJBrDoZKYeiwW7x915g8HOpX0uLVFtagXdKDRj5b g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusGAC7kn1OtJV2c/2dsb2JhbABagw1SWoJspwsBAQEBAQEFAZFphz0BGXUWdYQDAQEBAwEBAQEgEToLBQsCAQgYAgIGIAICAiULFRABAQQOBQiIMggNrHyeLRMEgSqEOYhiFhsHgnc2gRYErhuDQIFwJBw X-IronPort-AV: E=Sophos;i="5.01,492,1400025600"; d="scan'208";a="333403501" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 17 Jun 2014 06:49:00 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s5H6mxEB023126 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Jun 2014 06:48:59 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Tue, 17 Jun 2014 01:48:59 -0500 From: "Michael Behringer (mbehring)" To: Brian E Carpenter Thread-Topic: [Anima] Review of draft-irtf-nmrg-autonomic-network-definitions-00 Thread-Index: Ac+JgvaPHDoyXljjTxupgmBZU4xEaAASb3WAAArE56A= Date: Tue, 17 Jun 2014 06:48:58 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BB3F8B@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BB3787@xmb-rcd-x14.cisco.com> <539F558B.8040701@gmail.com> In-Reply-To: <539F558B.8040701@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.137] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/anima/NarvGX1uCROXvVY5BiTmDha5TfM Cc: "anima@ietf.org" Subject: Re: [Anima] Review of draft-irtf-nmrg-autonomic-network-definitions-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: Tue, 17 Jun 2014 06:49:02 -0000 PiBUaGVyZSBpcyBvbmUgc2VjdGlvbiB3ZSBkZWZpbml0ZWx5IGhhdmUgdG8gdXBkYXRlOg0KPiAN Cj4gPiA1LiAgR3VpZGVsaW5lcyBmb3IgQ2FzZSBTdHVkaWVzDQo+ID4NCj4gPiAgICBbVGhpcyBz ZWN0aW9uIGlzIHdvcmsgaW4gcHJvZ3Jlc3MuXQ0KDQpNeSB2aWV3OiBBdCB0aGUgdGltZSBvZiB3 cml0aW5nIHRoaXMsIGl0IHdhcyBtZWFudCB0byBoZWxwIGluIHRoZSBwcm9jZWR1cmUgdG8gZ2V0 IGNhc2Ugc3R1ZGllcywgYW5kIHllcywgd2UgZG8gaGF2ZSB0aGUgdGV4dC4gDQoNCk5vdywgaWYg dGhpcyBkb2N1bWVudCBpcyB0byBiZSBwdWJsaXNoZWQgc29tZSB0aW1lLCBJIHRoaW5rIHdlIHNo b3VsZCBtb3ZlIGF3YXkgZnJvbSBwcm9jZWR1cmFsIHRleHQsIGFuZCB0b3dhcmRzIHRleHQgdGhh dCBkZXNjcmliZXMgaW4gZ2VuZXJhbCB3aGF0IG1ha2VzIGEgZ29vZCBhdXRvbm9taWMgZnVuY3Rp b25hbGl0eS4gU28gYWxyZWFkeSB0aGUgd29yZCAiY2FzZSBzdHVkeSIgbWF5IGJlIG1pc2xlYWRp bmcuICBJJ2xsIGhhdmUgYSBnbyBhdCBzb21lIG5ldyB0ZXh0LCBidXQgYW0gb2YgY291cnNlIGhh cHB5IHRvIHRha2Ugc3VnZ2VzdGlvbnMuIA0KDQpNaWNoYWVsDQogDQo+IEhvd2V2ZXIsIHRoaXMg d2FzIGRpc2N1c3NlZCBhIGZldyBtb250aHMgYWdvIG9uIHRoZSBOTVJHIGxpc3QsIHNvIHdlDQo+ IGhhdmUgZHJhZnQgdGV4dCBmb3IgdGhpcyBhbHJlYWR5LCBhbmQgYSBmZXcgdXNlIGNhc2UgZG9j dW1lbnRzIHRvIHZhbGlkYXRlIGl0Lg0KPiANCj4gUmVnYXJkcw0KPiAgICBCcmlhbg0KPiANCj4g T24gMTcvMDYvMjAxNCAwNTowNSwgTWljaGFlbCBCZWhyaW5nZXIgKG1iZWhyaW5nKSB3cm90ZToN Cj4gPiBJJ20gc3RhcnRpbmcgdG8gd29yayBvbiB0aGUgbmV4dCB2ZXJzaW9uIG9mIGRyYWZ0LWly dGYtbm1yZy1hdXRvbm9taWMtDQo+IG5ldHdvcmstZGVmaW5pdGlvbnMtMDAuDQo+ID4NCj4gPiBX ZSBzaG91bGQgdHJ5IHRvIGZpbmFsaXNlIHRoaXMgZG9jdW1lbnQgYXNhcDsgcGxlYXNlIHJldmll dyB0aGUgZG9jdW1lbnQNCj4gYW5kIHByb3ZpZGUgeW91ciBmZWVkYmFjayBoZXJlIG9uIHRoaXMg bGlzdC4gSWYgeW91IGFyZSBvayB3aXRoIHRoZSBkb2N1bWVudA0KPiBhcyBpdCBpcywgcGxlYXNl IGFsc28gc3RhdGUgdGhpcy4gSW4gYWRkaXRpb24gdG8gZGV0YWlsZWQgY29tbWVudHMsIHdlIG5l ZWQgYQ0KPiBnb29kIGZlZWxpbmcgb24gaG93IGZhciBhd2F5IHdlIGFyZSBmcm9tIGEgcG90ZW50 aWFsIGZpbmFsIHZlcnNpb24uDQo+ID4NCj4gPiBUaGFua3MsDQo+ID4gTWljaGFlbA0KPiA+DQo+ ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBB bmltYSBtYWlsaW5nIGxpc3QNCj4gPiBBbmltYUBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWENCj4gPg0K From nobody Mon Jun 16 23:59:13 2014 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 C7E0D1A0299; Mon, 16 Jun 2014 23:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 JIsampmaXL4O; Mon, 16 Jun 2014 23:59:02 -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 14D601A0286; Mon, 16 Jun 2014 23:59:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6259; q=dns/txt; s=iport; t=1402988342; x=1404197942; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=lpx2Qh+KDOEsZq+O9kCh+wXvbLgCKl+OUojMHFbZc3Q=; b=Wj5nU8VpoyNKungDPulc2qIrPH4C1HDmT2o8FGT4YLFMwpI2X8W4ak2Z L+35PvAnS/eLwNLiZoI2a5o5LxIu1cUGYmKvuGil/R6eMgK9EX7VTvmRO zcV0kHDz4GwF3BgySUbeV670vRhyktK8YH3PpyhwhnP06svSae5sV9flC Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AukGAFTmn1OtJV2T/2dsb2JhbABagw1SWql3AQEBAQEBBQGRaYc9AYEOFnWEAwEBAQMBAQEBNy0HCwUHBAIBCBEEAQEBChQJBycLFAkIAgQBDQUIEQKIHwgNyywXhWOIYjEHBoMngRYEnAaSFYNAgjA X-IronPort-AV: E=Sophos;i="5.01,492,1400025600"; d="scan'208";a="53642551" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-7.cisco.com with ESMTP; 17 Jun 2014 06:59:01 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s5H6x1bV004389 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Jun 2014 06:59:01 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Tue, 17 Jun 2014 01:59:01 -0500 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , "anima@ietf.org" Thread-Topic: [Anima] Scope question [was: autonomic bootstrap: gap analysis] Thread-Index: AQHPibbWdqAxK5GJ0ECGIzHVDHkcBZt03Xfg Date: Tue, 17 Jun 2014 06:59:00 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BB3FF4@xmb-rcd-x14.cisco.com> References: <26717.1402949592@sandelman.ca> <539F771A.3000008@gmail.com> In-Reply-To: <539F771A.3000008@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.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/anima/hk0uiy49elnqGy8pzUmuOeFmLmw Cc: 6tisch-security <6tisch-security@ietf.org> Subject: Re: [Anima] Scope question [was: autonomic bootstrap: gap analysis] 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, 17 Jun 2014 06:59:06 -0000 > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E > Carpenter > Sent: 17 June 2014 01:01 > To: anima@ietf.org > Cc: 6tisch-security > Subject: [Anima] Scope question [was: autonomic bootstrap: gap analysis] >=20 > Michael's message is very interesting. For present purposes, i.e. getting > ready for the UCAN BOF, do we need to add some points to the relevant use > case draft (http://tools.ietf.org/html/draft-behringer-autonomic- > bootstrap)? >=20 > More generally - I think the AN protagonists have been thinking of the > scope of AN being carrier, enterprise, and home networks. > Should we add IoT to the scope? I think it's an important question, becau= se > it would put new meanings on "simple" and "available resources". It seems > obvious that IoT networks need to be completely autonomic, but is it the > *same* autonomic? Brian, we have always positioned AN also in the IoT context, and I agree wi= th Sheng, AN can be used everywhere. Especially when it comes to devices th= at will be deployed and managed in the thousands or even millions, autonomi= c concepts are a requirement, not a nice to have.=20 We have positioned draft-pritikin-bootstrapping-keyinfrastructures as a hig= h-level solution in 6tisch. It explains how you CAN bootstrap a network, ze= ro-touch AND secure, and fits perfectly to the 6tisch requirements. The cor= responding use case is described in draft-behringer-autonomic-bootstrap.=20 To me, the bootstrap problem is one of the real solid examples of autonomic= behaviour, because to bootstrap a device into a network I MUST have some f= unctionality on the devices, ie, distribution is absolutely mandatory here.= =20 So this is one of the criteria for the use cases: Is distribution a require= ment? Because if it is, then this points very clearly to an autonomic solut= ion.=20 Michael =20 > Regards > Brian >=20 > On 17/06/2014 08:13, Michael Richardson wrote: > > I recognize that bootstrap is only one of the autonomic mechanisms > > that are relevant to this group. I have much reading on the other > > aspects which I hope to get done. > > > > The 6tisch security design team has been working on a "zero-touch" > > mechanism that would permit constrained devices to join a > Lowpower/Loss Network (LLN) > > in a secure way. We have considered adapting EAP-TLS (as ZigbeeIP has > > done), or turning the WirelessHART (IEC62591) packet flow into > > something more IPv6-like. While there are significant bits of design > > space to explore while trying to optimize packet count, size and total > > energy risk of the join protocol; the idea that there should be a set > > of authorization tokens From the device vendor which would permit the > > network and new nodes to recognize each other has been central to all > discussions. > > > > while draft-pritikin-bootstrapping-keyinfrastructures and > > draft-behringer-autonomic-bootstrap-00 > > > > have proposed valid high level concepts, I believe that specification > > of the authz token is critical for the IoT space. A great concern > > that is that the LLNs created remain operational for decades at a > > time, and that the components can individually and also in aggregate > > be both (re-)sold, and/or the service provider operating the network be > replaced. > > > > (There are real life examples where a part of a 100 square mile > > refinery is actually sold to a competitor; obviously it doesn't get > > moved. On the other side, one has the very real risk that you bought > > your sensor network From a "Nortel") > > > > I was pointed at 802.1AR's device ID mechanism. Really, 802.1AR is > > about an API between a (constrained) device and it's cryptographic > hardware > > module/TPM. It profiles a number of IETF PKIX specifications in a use= ful > > way, but there is little there in terms of actual protocol. When it > > comes to what does an *DevID look like, in it's section 7.2.8, saying > > that the DN should contain a "serialNumber" attribute: > > > > The formatting of this field shall contain a unique X.500 > > Distinguished Name (DN). This may include the unique device serial > number assigned by the manufacturer > > or any other suitable unique DN value that the issuer prefers. > > > > What I have observed is that there needs to be a way to clearly > > delegate from > > Factory(Vendor) to VAR to DISTRIBUTOR to RESELLER to Plant-OWNER to > > SERVICE-PROVIDER. It would significantly reduce the number of > certificates > > in (non-constrained device) databases for some levels of this > > hierarchy if the IDevID were aggregateable in some fashion. RFC3779 > > came to mind, which deals with delegation of Autonomous Systems > > Numbers (ASN) and IP address ranges from RIRs to LIRs to ISPs and > Enterprises. > > RFC3779: X.509 Extensions for IP Addresses and AS > > Identifiers > > > > I created: > > X509.v3 certificate extension for authorization of device ownership > > draft-richardson-6tisch-idevid-cert-00 > > > > which cribbed together via nroff2xml and a search and replace. > > > > The Pritikin and Behringer documents seem to assume that the ultimate > > goal of the trusted enrollment process is to create a path in which > > "EST"=3D Enrollment over Secure Transport could operate that would > > permit a new locally significant certificate to be loaded into the new > device. > > I agree with that goal. > > > > There is the question of how that trust circuit is created, and in > > discussion it seemed that it involve some kind of leap-of-faith TLS > > setup which would be authenticated by the "authz" tokens later on. I > > disagree; I think that with appropriate evaluation of path constraints > > that the authentication can occur within the TLS protocol. (Even > > easier if done in IKEv2) > > > > -- > > 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 Tue Jun 17 00:44:44 2014 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 AD0EA1A02BC; Tue, 17 Jun 2014 00:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 A6QCEBsgBmtx; Tue, 17 Jun 2014 00:21:06 -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 07DAE1A02BF; Tue, 17 Jun 2014 00:21:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7311; q=dns/txt; s=iport; t=1402989666; x=1404199266; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NDRPzcfQ7RQq8/EVAw3NODrk/VsfoqYGb7QendTFadU=; b=iTpYHrD1RB9Un0fsIxR5W80FSJvuJC6o0R6uQg6d4ARsSI86/htqVK5m KMs5OC8W1aF37GutRaozv9RBIRXOHg6HRRi57M6KZXEFk+8gJy7cOs8YH ESZ/SD4kMQw2orTUh1A//B60aM5rVAatWm3Pa1D4MDNrEbr/Ute71GfuH k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AloGAO/rn1OtJV2Q/2dsb2JhbABagw1STaoEAQEBAQEHkWmGbFEBgQ4WdYQDAQEBBAEBAWQHCwwEAgEIEQQBAQEnBycLFAkIAgQOBRkCiCcNyzIXhWOFdAGCazMHBoMngRYEigWQPoFDkhWBfoFC X-IronPort-AV: E=Sophos;i="5.01,492,1400025600"; d="scan'208";a="53643757" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-2.cisco.com with ESMTP; 17 Jun 2014 07:21:05 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s5H7L4So014818 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Jun 2014 07:21:04 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.126]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Tue, 17 Jun 2014 02:21:04 -0500 From: "Pascal Thubert (pthubert)" To: "Michael Behringer (mbehring)" Thread-Topic: [6tisch-security] [Anima] Scope question [was: autonomic bootstrap: gap analysis] Thread-Index: AQHPibbWdqAxK5GJ0ECGIzHVDHkcBZt03XfggAAIgAY= Date: Tue, 17 Jun 2014 07:21:03 +0000 Message-ID: References: <26717.1402949592@sandelman.ca> <539F771A.3000008@gmail.com>, <3AA7118E69D7CD4BA3ECD5716BAF28DF21BB3FF4@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BB3FF4@xmb-rcd-x14.cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/anima/0_d2k65wMwZqRaN-zA9-68TK3F0 X-Mailman-Approved-At: Tue, 17 Jun 2014 00:44:40 -0700 Cc: 6tisch-security <6tisch-security@ietf.org>, "anima@ietf.org" Subject: Re: [Anima] [6tisch-security] Scope question [was: autonomic bootstrap: gap analysis] 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, 17 Jun 2014 07:21:08 -0000 I agree with Michael, As IT and more specifically IEEE/IETF technology is getting pervasive, we n= eed to simplify commissioning and deployment in a fundamental manner. There are no CCIEs in an oil field or a deep mine in Alaska and still growi= ng amounts of IP and Ethernet devices get deployed in all sorts of places, = homes, curbs, factory floors, you name it, with a renewed interest in wirel= ess monitoring. 6TiSCH targets at some of those environments and it clearly requires AN for= use cases with huge scalability or ease-of-deployment constraints. And certainly, the lack of CCIEs is more pervasive than just the WSN/6TiSCH= ... Pascal Le 17 juin 2014 =E0 08:59, "Michael Behringer (mbehring)" a =E9crit : >> -----Original Message----- >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E >> Carpenter >> Sent: 17 June 2014 01:01 >> To: anima@ietf.org >> Cc: 6tisch-security >> Subject: [Anima] Scope question [was: autonomic bootstrap: gap analysis] >>=20 >> Michael's message is very interesting. For present purposes, i.e. gettin= g >> ready for the UCAN BOF, do we need to add some points to the relevant us= e >> case draft (http://tools.ietf.org/html/draft-behringer-autonomic- >> bootstrap)? >>=20 >> More generally - I think the AN protagonists have been thinking of the >> scope of AN being carrier, enterprise, and home networks. >> Should we add IoT to the scope? I think it's an important question, beca= use >> it would put new meanings on "simple" and "available resources". It seem= s >> obvious that IoT networks need to be completely autonomic, but is it the >> *same* autonomic? >=20 > Brian, we have always positioned AN also in the IoT context, and I agree = with Sheng, AN can be used everywhere. Especially when it comes to devices = that will be deployed and managed in the thousands or even millions, autono= mic concepts are a requirement, not a nice to have.=20 >=20 > We have positioned draft-pritikin-bootstrapping-keyinfrastructures as a h= igh-level solution in 6tisch. It explains how you CAN bootstrap a network, = zero-touch AND secure, and fits perfectly to the 6tisch requirements. The c= orresponding use case is described in draft-behringer-autonomic-bootstrap.= =20 >=20 > To me, the bootstrap problem is one of the real solid examples of autonom= ic behaviour, because to bootstrap a device into a network I MUST have some= functionality on the devices, ie, distribution is absolutely mandatory her= e.=20 >=20 > So this is one of the criteria for the use cases: Is distribution a requi= rement? Because if it is, then this points very clearly to an autonomic sol= ution.=20 >=20 > Michael >=20 >=20 >> Regards >> Brian >>=20 >>> On 17/06/2014 08:13, Michael Richardson wrote: >>> I recognize that bootstrap is only one of the autonomic mechanisms >>> that are relevant to this group. I have much reading on the other >>> aspects which I hope to get done. >>>=20 >>> The 6tisch security design team has been working on a "zero-touch" >>> mechanism that would permit constrained devices to join a >> Lowpower/Loss Network (LLN) >>> in a secure way. We have considered adapting EAP-TLS (as ZigbeeIP has >>> done), or turning the WirelessHART (IEC62591) packet flow into >>> something more IPv6-like. While there are significant bits of design >>> space to explore while trying to optimize packet count, size and total >>> energy risk of the join protocol; the idea that there should be a set >>> of authorization tokens From the device vendor which would permit the >>> network and new nodes to recognize each other has been central to all >> discussions. >>>=20 >>> while draft-pritikin-bootstrapping-keyinfrastructures and >>> draft-behringer-autonomic-bootstrap-00 >>>=20 >>> have proposed valid high level concepts, I believe that specification >>> of the authz token is critical for the IoT space. A great concern >>> that is that the LLNs created remain operational for decades at a >>> time, and that the components can individually and also in aggregate >>> be both (re-)sold, and/or the service provider operating the network be >> replaced. >>>=20 >>> (There are real life examples where a part of a 100 square mile >>> refinery is actually sold to a competitor; obviously it doesn't get >>> moved. On the other side, one has the very real risk that you bought >>> your sensor network From a "Nortel") >>>=20 >>> I was pointed at 802.1AR's device ID mechanism. Really, 802.1AR is >>> about an API between a (constrained) device and it's cryptographic >> hardware >>> module/TPM. It profiles a number of IETF PKIX specifications in a use= ful >>> way, but there is little there in terms of actual protocol. When it >>> comes to what does an *DevID look like, in it's section 7.2.8, saying >>> that the DN should contain a "serialNumber" attribute: >>>=20 >>> The formatting of this field shall contain a unique X.500 >>> Distinguished Name (DN). This may include the unique device serial >> number assigned by the manufacturer >>> or any other suitable unique DN value that the issuer prefers. >>>=20 >>> What I have observed is that there needs to be a way to clearly >>> delegate from >>> Factory(Vendor) to VAR to DISTRIBUTOR to RESELLER to Plant-OWNER to >>> SERVICE-PROVIDER. It would significantly reduce the number of >> certificates >>> in (non-constrained device) databases for some levels of this >>> hierarchy if the IDevID were aggregateable in some fashion. RFC3779 >>> came to mind, which deals with delegation of Autonomous Systems >>> Numbers (ASN) and IP address ranges from RIRs to LIRs to ISPs and >> Enterprises. >>> RFC3779: X.509 Extensions for IP Addresses and AS >>> Identifiers >>>=20 >>> I created: >>> X509.v3 certificate extension for authorization of device ownership >>> draft-richardson-6tisch-idevid-cert-00 >>>=20 >>> which cribbed together via nroff2xml and a search and replace. >>>=20 >>> The Pritikin and Behringer documents seem to assume that the ultimate >>> goal of the trusted enrollment process is to create a path in which >>> "EST"=3D Enrollment over Secure Transport could operate that would >>> permit a new locally significant certificate to be loaded into the new >> device. >>> I agree with that goal. >>>=20 >>> There is the question of how that trust circuit is created, and in >>> discussion it seemed that it involve some kind of leap-of-faith TLS >>> setup which would be authenticated by the "authz" tokens later on. I >>> disagree; I think that with appropriate evaluation of path constraints >>> that the authentication can occur within the TLS protocol. (Even >>> easier if done in IKEv2) >>>=20 >>> -- >>> Michael Richardson , Sandelman Software >> Works >>> -=3D IPv6 IoT consulting =3D- >>=20 >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >=20 > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security From nobody Tue Jun 17 01:04:15 2014 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 1A82C1A0304; Tue, 17 Jun 2014 01:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-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 XvVtDyemaYht; Tue, 17 Jun 2014 01:04:04 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E33D1A02F9; Tue, 17 Jun 2014 01:04:04 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s5H8415Y001101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Jun 2014 03:04:01 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s5H841bZ028010 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Jun 2014 04:04:01 -0400 Received: from [135.244.33.51] (135.5.27.16) by US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 17 Jun 2014 04:03:59 -0400 Message-ID: <539FF669.7020001@alcatel-lucent.com> Date: Tue, 17 Jun 2014 10:03:53 +0200 From: Laurent Ciavaglia Organization: Alcatel-Lucent Bell Labs France User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , "anima@ietf.org" , <6tisch-security@ietf.org> References: <26717.1402949592@sandelman.ca> <539F771A.3000008@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BB3FF4@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BB3FF4@xmb-rcd-x14.cisco.com> Content-Type: multipart/alternative; boundary="------------070302050706030409050707" X-Originating-IP: [135.5.27.16] Archived-At: http://mailarchive.ietf.org/arch/msg/anima/sdafkIicxpmPMP7Kj7hRVFc8W-o Subject: Re: [Anima] Scope question [was: autonomic bootstrap: gap analysis] 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, 17 Jun 2014 08:04:09 -0000 --------------070302050706030409050707 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Dear Michael, all, It's nice to see inputs/thoughts from very different domains (IoT) coming in! Connected devices or entities are for sure in the scope of applicability for autonomic networking. And if we consider the future 5G networks, the number of connected "nodes" will be even more important and will put even more pressure on the (operators of the) networking infrastructures to cope with e.g. up-to-date/synchronized inventory (just to name one). In this context, autonomic technologies definitely make sense: to address scalability, optimisation/adaptation of the control process/functions, coordination/orchestration among autonomic nodes/functions, etc). If we speak IoT/Smart objects, I see a clear and easy first link with SmartHome (homenet), and as long as we see a _role_ for the network (thus the "_connecte__d_" x), and someone acting as an "operator" (not necessarily a classical telco carrier: e.g. who the homenet operator(s)?), there is a place for autonomic technologies. What we can provide (ultimately) is a (consistent/integrated?) set of autonomic/management tools for these very operators applicable in the different technological/industrial domains (smart homes, smart cities... and of course also "purely" telecommuncations networks). Of course one goal would be to not re-specify/develop the core solutions for all the different domains. This is very much in line with one of our goals in this BoF to identify commonalities that will drive the protocol/architecture work. Autonomic networking will/should develop and provide both the procotols/mechanisms and the right (simple, extensible, composable) interfaces for operators to use them (in different domains). As for the point on distribution, I don't know how to phrase it, but it is even more than a requirement, it is part of the nature of any networked environment: distributed in nature. So we will have to "attach" a number of basic/essential (autonomic) functionality to the (distributed) "nodes". Secured bootstrap is one. Others well-known ones could be (TBD): discovery, information exchange, capability negotiation, enforcement, group communications... Best regards, Laurent. On 17/06/2014 08:59, Michael Behringer (mbehring) wrote: >> -----Original Message----- >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E >> Carpenter >> Sent: 17 June 2014 01:01 >> To:anima@ietf.org >> Cc: 6tisch-security >> Subject: [Anima] Scope question [was: autonomic bootstrap: gap analysis] >> >> Michael's message is very interesting. For present purposes, i.e. getting >> ready for the UCAN BOF, do we need to add some points to the relevant use >> case draft (http://tools.ietf.org/html/draft-behringer-autonomic- >> bootstrap)? >> >> More generally - I think the AN protagonists have been thinking of the >> scope of AN being carrier, enterprise, and home networks. >> Should we add IoT to the scope? I think it's an important question, because >> it would put new meanings on "simple" and "available resources". It seems >> obvious that IoT networks need to be completely autonomic, but is it the >> *same* autonomic? > Brian, we have always positioned AN also in the IoT context, and I agree with Sheng, AN can be used everywhere. Especially when it comes to devices that will be deployed and managed in the thousands or even millions, autonomic concepts are a requirement, not a nice to have. > > We have positioned draft-pritikin-bootstrapping-keyinfrastructures as a high-level solution in 6tisch. It explains how you CAN bootstrap a network, zero-touch AND secure, and fits perfectly to the 6tisch requirements. The corresponding use case is described in draft-behringer-autonomic-bootstrap. > > To me, the bootstrap problem is one of the real solid examples of autonomic behaviour, because to bootstrap a device into a network I MUST have some functionality on the devices, ie, distribution is absolutely mandatory here. > > So this is one of the criteria for the use cases: Is distribution a requirement? Because if it is, then this points very clearly to an autonomic solution. > > Michael > > >> Regards >> Brian >> >> On 17/06/2014 08:13, Michael Richardson wrote: >>> I recognize that bootstrap is only one of the autonomic mechanisms >>> that are relevant to this group. I have much reading on the other >>> aspects which I hope to get done. >>> >>> The 6tisch security design team has been working on a "zero-touch" >>> mechanism that would permit constrained devices to join a >> Lowpower/Loss Network (LLN) >>> in a secure way. We have considered adapting EAP-TLS (as ZigbeeIP has >>> done), or turning the WirelessHART (IEC62591) packet flow into >>> something more IPv6-like. While there are significant bits of design >>> space to explore while trying to optimize packet count, size and total >>> energy risk of the join protocol; the idea that there should be a set >>> of authorization tokens From the device vendor which would permit the >>> network and new nodes to recognize each other has been central to all >> discussions. >>> while draft-pritikin-bootstrapping-keyinfrastructures and >>> draft-behringer-autonomic-bootstrap-00 >>> >>> have proposed valid high level concepts, I believe that specification >>> of the authz token is critical for the IoT space. A great concern >>> that is that the LLNs created remain operational for decades at a >>> time, and that the components can individually and also in aggregate >>> be both (re-)sold, and/or the service provider operating the network be >> replaced. >>> (There are real life examples where a part of a 100 square mile >>> refinery is actually sold to a competitor; obviously it doesn't get >>> moved. On the other side, one has the very real risk that you bought >>> your sensor network From a "Nortel") >>> >>> I was pointed at 802.1AR's device ID mechanism. Really, 802.1AR is >>> about an API between a (constrained) device and it's cryptographic >> hardware >>> module/TPM. It profiles a number of IETF PKIX specifications in a useful >>> way, but there is little there in terms of actual protocol. When it >>> comes to what does an *DevID look like, in it's section 7.2.8, saying >>> that the DN should contain a "serialNumber" attribute: >>> >>> The formatting of this field shall contain a unique X.500 >>> Distinguished Name (DN). This may include the unique device serial >> number assigned by the manufacturer >>> or any other suitable unique DN value that the issuer prefers. >>> >>> What I have observed is that there needs to be a way to clearly >>> delegate from >>> Factory(Vendor) to VAR to DISTRIBUTOR to RESELLER to Plant-OWNER to >>> SERVICE-PROVIDER. It would significantly reduce the number of >> certificates >>> in (non-constrained device) databases for some levels of this >>> hierarchy if the IDevID were aggregateable in some fashion. RFC3779 >>> came to mind, which deals with delegation of Autonomous Systems >>> Numbers (ASN) and IP address ranges from RIRs to LIRs to ISPs and >> Enterprises. >>> RFC3779: X.509 Extensions for IP Addresses and AS >>> Identifiers >>> >>> I created: >>> X509.v3 certificate extension for authorization of device ownership >>> draft-richardson-6tisch-idevid-cert-00 >>> >>> which cribbed together via nroff2xml and a search and replace. >>> >>> The Pritikin and Behringer documents seem to assume that the ultimate >>> goal of the trusted enrollment process is to create a path in which >>> "EST"= Enrollment over Secure Transport could operate that would >>> permit a new locally significant certificate to be loaded into the new >> device. >>> I agree with that goal. >>> >>> There is the question of how that trust circuit is created, and in >>> discussion it seemed that it involve some kind of leap-of-faith TLS >>> setup which would be authenticated by the "authz" tokens later on. I >>> disagree; I think that with appropriate evaluation of path constraints >>> that the authentication can occur within the TLS protocol. (Even >>> easier if done in IKEv2) >>> >>> -- >>> 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 > -- Bien cordialement, Best regards, *Laurent Ciavaglia* Research Manager | Project Manager Network Algorithms, Protocols and Security Group Bell Labs | Alcatel Lucent phone: +33 160 402 636 email: laurent.ciavaglia@alcatel-lucent.com linkedin: laurentciavaglia address: Route de Villejust | 91620 NOZAY | France --------------070302050706030409050707 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Dear Michael, all,

It's nice to see inputs/thoughts from very different domains (IoT) coming in!

Connected devices or entities are for sure in the scope of applicability for autonomic networking. And if we consider the future 5G networks, the number of connected "nodes" will be even more important and will put even more pressure on the (operators of the) networking infrastructures to cope with e.g. up-to-date/synchronized inventory (just to name one).
In this context, autonomic technologies definitely make sense: to address scalability, optimisation/adaptation of the control process/functions, coordination/orchestration among autonomic nodes/functions, etc).

If we speak IoT/Smart objects, I see a clear and easy first link with SmartHome (homenet), and as long as we see a role for the network (thus the "connected" x), and someone acting as an "operator" (not necessarily a classical telco carrier: e.g. who the homenet operator(s)?), there is a place for autonomic technologies.

What we can provide (ultimately)  is a (consistent/integrated?) set of autonomic/management tools for these very operators applicable in the different technological/industrial domains (smart homes, smart cities... and of course also "purely" telecommuncations networks). Of course one goal would be to not re-specify/develop the core solutions for all the different domains. This is very much in line with one of our goals in this BoF to identify commonalities that will drive the protocol/architecture work.
Autonomic networking will/should develop and provide both the procotols/mechanisms and the right (simple, extensible, composable) interfaces for operators to use them (in different domains).

As for the point on distribution, I don't know how to phrase it, but it is even more than a requirement, it is part of the nature of any networked environment: distributed in nature. So we will have to "attach" a number of basic/essential (autonomic) functionality to the (distributed) "nodes". Secured bootstrap is one. Others well-known ones could be (TBD): discovery, information exchange, capability negotiation, enforcement, group communications...

Best regards, Laurent.
On 17/06/2014 08:59, Michael Behringer (mbehring) wrote:
-----Original Message-----
From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E
Carpenter
Sent: 17 June 2014 01:01
To: anima@ietf.org
Cc: 6tisch-security
Subject: [Anima] Scope question [was: autonomic bootstrap: gap analysis]

Michael's message is very interesting. For present purposes, i.e. getting
ready for the UCAN BOF, do we need to add some points to the relevant use
case draft (http://tools.ietf.org/html/draft-behringer-autonomic-
bootstrap)?

More generally - I think the AN protagonists have been thinking of the
scope of AN being carrier, enterprise, and home networks.
Should we add IoT to the scope? I think it's an important question, because
it would put new meanings on "simple" and "available resources". It seems
obvious that IoT networks need to be completely autonomic, but is it the
*same* autonomic?

Brian, we have always positioned AN also in the IoT context, and I agree with Sheng, AN can be used everywhere. Especially when it comes to devices that will be deployed and managed in the thousands or even millions, autonomic concepts are a requirement, not a nice to have. 

We have positioned draft-pritikin-bootstrapping-keyinfrastructures as a high-level solution in 6tisch. It explains how you CAN bootstrap a network, zero-touch AND secure, and fits perfectly to the 6tisch requirements. The corresponding use case is described in draft-behringer-autonomic-bootstrap. 

To me, the bootstrap problem is one of the real solid examples of autonomic behaviour, because to bootstrap a device into a network I MUST have some functionality on the devices, ie, distribution is absolutely mandatory here. 

So this is one of the criteria for the use cases: Is distribution a requirement? Because if it is, then this points very clearly to an autonomic solution. 

Michael

 

Regards
   Brian

On 17/06/2014 08:13, Michael Richardson wrote:

I recognize that bootstrap is only one of the autonomic mechanisms
that are relevant to this group.  I have much reading on the other
aspects which I hope to get done.

The 6tisch security design team has been working on a "zero-touch"
mechanism that would permit constrained devices to join a

Lowpower/Loss Network (LLN)

in a secure way.   We have considered adapting EAP-TLS (as ZigbeeIP has
done), or turning the WirelessHART (IEC62591) packet flow into
something more IPv6-like.  While there are significant bits of design
space to explore while trying to optimize packet count, size and total
energy risk of the join protocol;  the idea that there should be a set
of authorization tokens From the device vendor which would permit the
network and new nodes to recognize each other has been central to all

discussions.

while draft-pritikin-bootstrapping-keyinfrastructures and
      draft-behringer-autonomic-bootstrap-00

have proposed valid high level concepts, I believe that specification
of the authz token is critical for the IoT space.  A great concern
that is that the LLNs created remain operational for decades at a
time, and that the components can individually and also in aggregate
be both (re-)sold, and/or the service provider operating the network be

replaced.

(There are real life examples where a part of a 100 square mile
refinery is actually sold to a competitor; obviously it doesn't get
moved.  On the other side, one has the very real risk that you bought
your sensor network From a "Nortel")

I was pointed at 802.1AR's device ID mechanism.  Really, 802.1AR is
about an API between a (constrained) device and it's cryptographic

hardware

module/TPM.   It profiles a number of IETF PKIX specifications in a useful
way, but there is little there in terms of actual protocol.  When it
comes to what does an *DevID look like, in it's section 7.2.8, saying
that the DN should contain a "serialNumber" attribute:

   The formatting of this field shall contain a unique X.500
   Distinguished Name (DN). This may include the unique device serial

number assigned by the manufacturer

   or any other suitable unique DN value that the issuer prefers.

What I have observed is that there needs to be a way to clearly
delegate from
Factory(Vendor) to VAR to DISTRIBUTOR to RESELLER to Plant-OWNER to
SERVICE-PROVIDER.    It would significantly reduce the number of

certificates

in (non-constrained device) databases for some levels of this
hierarchy if the IDevID were aggregateable in some fashion.  RFC3779
came to mind, which deals with delegation of Autonomous Systems
Numbers (ASN) and IP address ranges from RIRs to LIRs to ISPs and

Enterprises.

          RFC3779: X.509 Extensions for IP Addresses and AS
Identifiers

I created:
    X509.v3 certificate extension for authorization of device ownership
                 draft-richardson-6tisch-idevid-cert-00

which cribbed together via nroff2xml and a search and replace.

The Pritikin and Behringer documents seem to assume that the ultimate
goal of the trusted enrollment process is to create a path in which
"EST"= Enrollment over Secure Transport could operate that would
permit a new locally significant certificate to be loaded into the new

device.

I agree with that goal.

There is the question of how that trust circuit is created, and in
discussion it seemed that it involve some kind of leap-of-faith TLS
setup which would be authenticated by the "authz" tokens later on.  I
disagree; I think that with appropriate evaluation of path constraints
that the authentication can occur within the TLS protocol. (Even
easier if done in IKEv2)

--
Michael Richardson <mcr+IETF@sandelman.ca>, 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

--

Bien cordialement, Best regards,

 

Laurent Ciavaglia

Research Manager | Project Manager

Network Algorithms, Protocols and Security Group

Bell Labs | Alcatel Lucent

 

phone: +33 160 402 636

email: laurent.ciavaglia@alcatel-lucent.com

linkedin: laurentciavaglia

address: Route de Villejust | 91620 NOZAY | France

--------------070302050706030409050707-- From nobody Tue Jun 17 01:18:01 2014 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 505D51A030A; Tue, 17 Jun 2014 01:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 aA_l88SZxUPa; Tue, 17 Jun 2014 01:17:53 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB4551A029F; Tue, 17 Jun 2014 01:17:52 -0700 (PDT) X-AuditID: c1b4fb3a-f79746d000006fe2-74-539ff9ae3014 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 4B.A5.28642.EA9FF935; Tue, 17 Jun 2014 10:17:50 +0200 (CEST) Received: from [159.107.197.187] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.29) with Microsoft SMTP Server id 14.3.174.1; Tue, 17 Jun 2014 10:17:48 +0200 Message-ID: <539FF9AC.5000304@ericsson.com> Date: Tue, 17 Jun 2014 10:17:48 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , Brian E Carpenter , "anima@ietf.org" References: <26717.1402949592@sandelman.ca> <539F771A.3000008@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BB3FF4@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BB3FF4@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM+Jvje66n/ODDSbfVLJoXrmI3eLhoutM Fm0X9zFZXJt3kdmBxWPK742sHjtn3WX3WLLkJ1MAcxSXTUpqTmZZapG+XQJXxpMJ/AWzTCvO XepnbmBs0O5i5OSQEDCRODlrLiOELSZx4d56ti5GLg4hgaOMEkv/7IVy1jJK7Jx1Esjh4OAV 0Ja43JUG0sAioCrR/e43WDObgJHE1P7zLCC2qECUxK6+X+wgNq+AoMTJmU9YQOaICPQySrSv u8UGkmAW0JOY8RVis7CAj8TZx5vA4kICnYwS765KgticAr4Sk883s0LU20pcmHOdBcKWl9j+ dg4zRL2GxMMLf1knMArOQrJvFpKWWUhaFjAyr2IULU4tLs5NNzLSSy3KTC4uzs/Ty0st2cQI DOaDW35b7WA8+NzxEKMAB6MSD+8Cg/nBQqyJZcWVuYcYpTlYlMR5F56bFywkkJ5YkpqdmlqQ WhRfVJqTWnyIkYmDU6qBsbTLK+l/Tkjpjq4DG7xeXjicrNPSznx+9gOZbZ//HFJ0bN1S37TZ 72Fv1JW32TlGnIGxmaeXX3n7v3nmp3++9W8PJupGVW2S+y+d8utdSd3bZpkNjV//HX1aUWt0 MKpOxuP7pMedUgL1B3sXBwUF//NdaHauVSrxiJ6vcM3EPxsnLGH8LMU7S4mlOCPRUIu5qDgR AOupTohHAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/anima/WG5LIHW0Bc6CX1VxbKPAP9UGI8o Cc: 6tisch-security <6tisch-security@ietf.org> Subject: Re: [Anima] Scope question [was: autonomic bootstrap: gap analysis] 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, 17 Jun 2014 08:17:58 -0000 When speaking about bootstraping, does this have much in common with the http://tools.ietf.org/html/draft-kwatsen-netconf-zerotouch-01 draft? regards balazs On 2014-06-17 08:59, Michael Behringer (mbehring) wrote: >> -----Original Message----- >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E >> Carpenter >> Sent: 17 June 2014 01:01 >> To: anima@ietf.org >> Cc: 6tisch-security >> Subject: [Anima] Scope question [was: autonomic bootstrap: gap analysis] >> >> Michael's message is very interesting. For present purposes, i.e. getting >> ready for the UCAN BOF, do we need to add some points to the relevant use >> case draft (http://tools.ietf.org/html/draft-behringer-autonomic- >> bootstrap)? >> >> More generally - I think the AN protagonists have been thinking of the >> scope of AN being carrier, enterprise, and home networks. >> Should we add IoT to the scope? I think it's an important question, because >> it would put new meanings on "simple" and "available resources". It seems >> obvious that IoT networks need to be completely autonomic, but is it the >> *same* autonomic? > Brian, we have always positioned AN also in the IoT context, and I agree with Sheng, AN can be used everywhere. Especially when it comes to devices that will be deployed and managed in the thousands or even millions, autonomic concepts are a requirement, not a nice to have. > > We have positioned draft-pritikin-bootstrapping-keyinfrastructures as a high-level solution in 6tisch. It explains how you CAN bootstrap a network, zero-touch AND secure, and fits perfectly to the 6tisch requirements. The corresponding use case is described in draft-behringer-autonomic-bootstrap. > > To me, the bootstrap problem is one of the real solid examples of autonomic behaviour, because to bootstrap a device into a network I MUST have some functionality on the devices, ie, distribution is absolutely mandatory here. > > So this is one of the criteria for the use cases: Is distribution a requirement? Because if it is, then this points very clearly to an autonomic solution. > > Michael > > >> Regards >> Brian >> >> On 17/06/2014 08:13, Michael Richardson wrote: >>> I recognize that bootstrap is only one of the autonomic mechanisms >>> that are relevant to this group. I have much reading on the other >>> aspects which I hope to get done. >>> >>> The 6tisch security design team has been working on a "zero-touch" >>> mechanism that would permit constrained devices to join a >> Lowpower/Loss Network (LLN) >>> in a secure way. We have considered adapting EAP-TLS (as ZigbeeIP has >>> done), or turning the WirelessHART (IEC62591) packet flow into >>> something more IPv6-like. While there are significant bits of design >>> space to explore while trying to optimize packet count, size and total >>> energy risk of the join protocol; the idea that there should be a set >>> of authorization tokens From the device vendor which would permit the >>> network and new nodes to recognize each other has been central to all >> discussions. >>> while draft-pritikin-bootstrapping-keyinfrastructures and >>> draft-behringer-autonomic-bootstrap-00 >>> >>> have proposed valid high level concepts, I believe that specification >>> of the authz token is critical for the IoT space. A great concern >>> that is that the LLNs created remain operational for decades at a >>> time, and that the components can individually and also in aggregate >>> be both (re-)sold, and/or the service provider operating the network be >> replaced. >>> (There are real life examples where a part of a 100 square mile >>> refinery is actually sold to a competitor; obviously it doesn't get >>> moved. On the other side, one has the very real risk that you bought >>> your sensor network From a "Nortel") >>> >>> I was pointed at 802.1AR's device ID mechanism. Really, 802.1AR is >>> about an API between a (constrained) device and it's cryptographic >> hardware >>> module/TPM. It profiles a number of IETF PKIX specifications in a useful >>> way, but there is little there in terms of actual protocol. When it >>> comes to what does an *DevID look like, in it's section 7.2.8, saying >>> that the DN should contain a "serialNumber" attribute: >>> >>> The formatting of this field shall contain a unique X.500 >>> Distinguished Name (DN). This may include the unique device serial >> number assigned by the manufacturer >>> or any other suitable unique DN value that the issuer prefers. >>> >>> What I have observed is that there needs to be a way to clearly >>> delegate from >>> Factory(Vendor) to VAR to DISTRIBUTOR to RESELLER to Plant-OWNER to >>> SERVICE-PROVIDER. It would significantly reduce the number of >> certificates >>> in (non-constrained device) databases for some levels of this >>> hierarchy if the IDevID were aggregateable in some fashion. RFC3779 >>> came to mind, which deals with delegation of Autonomous Systems >>> Numbers (ASN) and IP address ranges from RIRs to LIRs to ISPs and >> Enterprises. >>> RFC3779: X.509 Extensions for IP Addresses and AS >>> Identifiers >>> >>> I created: >>> X509.v3 certificate extension for authorization of device ownership >>> draft-richardson-6tisch-idevid-cert-00 >>> >>> which cribbed together via nroff2xml and a search and replace. >>> >>> The Pritikin and Behringer documents seem to assume that the ultimate >>> goal of the trusted enrollment process is to create a path in which >>> "EST"= Enrollment over Secure Transport could operate that would >>> permit a new locally significant certificate to be loaded into the new >> device. >>> I agree with that goal. >>> >>> There is the question of how that trust circuit is created, and in >>> discussion it seemed that it involve some kind of leap-of-faith TLS >>> setup which would be authenticated by the "authz" tokens later on. I >>> disagree; I think that with appropriate evaluation of path constraints >>> that the authentication can occur within the TLS protocol. (Even >>> easier if done in IKEv2) >>> >>> -- >>> 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 -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Tel: +36-1-437-7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Tue Jun 17 05:50:01 2014 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 46D9D1A0376; Tue, 17 Jun 2014 05:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 4UdZxiV2vBvp; Tue, 17 Jun 2014 05:49:53 -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 CE6CE1A0016; Tue, 17 Jun 2014 05:49:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7915; q=dns/txt; s=iport; t=1403009394; x=1404218994; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=dn546IJmcd4GVK8JikpFWHYe2s8FK2vOtooMRQ1C8WE=; b=Qc6fMp0RlcF8Rwx1iNUbiPn08/c5upJbbZumwtJtoSauwFEWSur2J5Z3 ToS7DOmgb3MgLmB4w/zMQ8WkJNigMRyV2zyDxP3TPnjb0yI4nKNU4NzVa t9VCYF9wcLTqjijKpukPZrhegBm2Hp0oet4UzMRncGFh5DtBtCHJs4tYr 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AukGAI44oFOtJA2K/2dsb2JhbABagw1SWql+AQEBAQEBBQGRaYc9AYEMFnWEAwEBAQMBAQEBNy0HCwUHBAIBCBEEAQEBChQJBycLFAkIAgQBDQUIEQKIHwgNy3oXhWOIMREBHzEHBoMngRYEnAaSFYNAgXc5 X-IronPort-AV: E=Sophos;i="5.01,493,1400025600"; d="scan'208";a="333641025" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-7.cisco.com with ESMTP; 17 Jun 2014 12:49:53 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s5HCnpI0008951 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Jun 2014 12:49:51 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Tue, 17 Jun 2014 07:49:51 -0500 From: "Michael Behringer (mbehring)" To: Balazs Lengyel , Brian E Carpenter , "anima@ietf.org" Thread-Topic: [Anima] Scope question [was: autonomic bootstrap: gap analysis] Thread-Index: AQHPibbWdqAxK5GJ0ECGIzHVDHkcBZt03XfggABsLAD//8+9AA== Date: Tue, 17 Jun 2014 12:49:51 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BB5AB4@xmb-rcd-x14.cisco.com> References: <26717.1402949592@sandelman.ca> <539F771A.3000008@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BB3FF4@xmb-rcd-x14.cisco.com> <539FF9AC.5000304@ericsson.com> In-Reply-To: <539FF9AC.5000304@ericsson.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.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/anima/KUkTuQ3F9cnEzTqZDTZaCAJTiVU Cc: 6tisch-security <6tisch-security@ietf.org> Subject: Re: [Anima] Scope question [was: autonomic bootstrap: gap analysis] 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, 17 Jun 2014 12:49:58 -0000 > -----Original Message----- > From: Balazs Lengyel [mailto:balazs.lengyel@ericsson.com] > Sent: 17 June 2014 10:18 > To: Michael Behringer (mbehring); Brian E Carpenter; anima@ietf.org > Cc: 6tisch-security > Subject: Re: [Anima] Scope question [was: autonomic bootstrap: gap > analysis] >=20 > When speaking about bootstraping, does this have much in common with > the > http://tools.ietf.org/html/draft-kwatsen-netconf-zerotouch-01 > draft? > regards balazs In a nutshell:=20 draft-kwatsen-netconf-zerotouch-01 expects the config server URIs to be pre= -provisioned. (If I understand it correctly, from section 4.1 - didn't read= the whole doc, so correct me if I'm wrong).=20 draft-pritikin-bootstrapping-keyinfrastructures does not require any pre-pr= ovisioning. The new device "learns" to which network it belongs, and will f= ind the servers through discovery.=20 Michael > On 2014-06-17 08:59, Michael Behringer (mbehring) wrote: > >> -----Original Message----- > >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E > >> Carpenter > >> Sent: 17 June 2014 01:01 > >> To: anima@ietf.org > >> Cc: 6tisch-security > >> Subject: [Anima] Scope question [was: autonomic bootstrap: gap > >> analysis] > >> > >> Michael's message is very interesting. For present purposes, i.e. > >> getting ready for the UCAN BOF, do we need to add some points to the > >> relevant use case draft > >> (http://tools.ietf.org/html/draft-behringer-autonomic- > >> bootstrap)? > >> > >> More generally - I think the AN protagonists have been thinking of > >> the scope of AN being carrier, enterprise, and home networks. > >> Should we add IoT to the scope? I think it's an important question, > >> because it would put new meanings on "simple" and "available > >> resources". It seems obvious that IoT networks need to be completely > >> autonomic, but is it the > >> *same* autonomic? > > Brian, we have always positioned AN also in the IoT context, and I agre= e > with Sheng, AN can be used everywhere. Especially when it comes to > devices that will be deployed and managed in the thousands or even > millions, autonomic concepts are a requirement, not a nice to have. > > > > We have positioned draft-pritikin-bootstrapping-keyinfrastructures as a > high-level solution in 6tisch. It explains how you CAN bootstrap a networ= k, > zero-touch AND secure, and fits perfectly to the 6tisch requirements. The > corresponding use case is described in draft-behringer-autonomic- > bootstrap. > > > > To me, the bootstrap problem is one of the real solid examples of > autonomic behaviour, because to bootstrap a device into a network I MUST > have some functionality on the devices, ie, distribution is absolutely > mandatory here. > > > > So this is one of the criteria for the use cases: Is distribution a > requirement? Because if it is, then this points very clearly to an autono= mic > solution. > > > > Michael > > > > > >> Regards > >> Brian > >> > >> On 17/06/2014 08:13, Michael Richardson wrote: > >>> I recognize that bootstrap is only one of the autonomic mechanisms > >>> that are relevant to this group. I have much reading on the other > >>> aspects which I hope to get done. > >>> > >>> The 6tisch security design team has been working on a "zero-touch" > >>> mechanism that would permit constrained devices to join a > >> Lowpower/Loss Network (LLN) > >>> in a secure way. We have considered adapting EAP-TLS (as ZigbeeIP h= as > >>> done), or turning the WirelessHART (IEC62591) packet flow into > >>> something more IPv6-like. While there are significant bits of > >>> design space to explore while trying to optimize packet count, size > >>> and total energy risk of the join protocol; the idea that there > >>> should be a set of authorization tokens From the device vendor which > >>> would permit the network and new nodes to recognize each other has > >>> been central to all > >> discussions. > >>> while draft-pritikin-bootstrapping-keyinfrastructures and > >>> draft-behringer-autonomic-bootstrap-00 > >>> > >>> have proposed valid high level concepts, I believe that > >>> specification of the authz token is critical for the IoT space. A > >>> great concern that is that the LLNs created remain operational for > >>> decades at a time, and that the components can individually and also > >>> in aggregate be both (re-)sold, and/or the service provider > >>> operating the network be > >> replaced. > >>> (There are real life examples where a part of a 100 square mile > >>> refinery is actually sold to a competitor; obviously it doesn't get > >>> moved. On the other side, one has the very real risk that you > >>> bought your sensor network From a "Nortel") > >>> > >>> I was pointed at 802.1AR's device ID mechanism. Really, 802.1AR is > >>> about an API between a (constrained) device and it's cryptographic > >> hardware > >>> module/TPM. It profiles a number of IETF PKIX specifications in a u= seful > >>> way, but there is little there in terms of actual protocol. When it > >>> comes to what does an *DevID look like, in it's section 7.2.8, > >>> saying that the DN should contain a "serialNumber" attribute: > >>> > >>> The formatting of this field shall contain a unique X.500 > >>> Distinguished Name (DN). This may include the unique device > >>> serial > >> number assigned by the manufacturer > >>> or any other suitable unique DN value that the issuer prefers. > >>> > >>> What I have observed is that there needs to be a way to clearly > >>> delegate from > >>> Factory(Vendor) to VAR to DISTRIBUTOR to RESELLER to Plant-OWNER to > >>> SERVICE-PROVIDER. It would significantly reduce the number of > >> certificates > >>> in (non-constrained device) databases for some levels of this > >>> hierarchy if the IDevID were aggregateable in some fashion. RFC3779 > >>> came to mind, which deals with delegation of Autonomous Systems > >>> Numbers (ASN) and IP address ranges from RIRs to LIRs to ISPs and > >> Enterprises. > >>> RFC3779: X.509 Extensions for IP Addresses and AS > >>> Identifiers > >>> > >>> I created: > >>> X509.v3 certificate extension for authorization of device owners= hip > >>> draft-richardson-6tisch-idevid-cert-00 > >>> > >>> which cribbed together via nroff2xml and a search and replace. > >>> > >>> The Pritikin and Behringer documents seem to assume that the > >>> ultimate goal of the trusted enrollment process is to create a path > >>> in which "EST"=3D Enrollment over Secure Transport could operate that > >>> would permit a new locally significant certificate to be loaded into > >>> the new > >> device. > >>> I agree with that goal. > >>> > >>> There is the question of how that trust circuit is created, and in > >>> discussion it seemed that it involve some kind of leap-of-faith TLS > >>> setup which would be authenticated by the "authz" tokens later on. > >>> I disagree; I think that with appropriate evaluation of path > >>> constraints that the authentication can occur within the TLS > >>> protocol. (Even easier if done in IKEv2) > >>> > >>> -- > >>> 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 >=20 > -- > Balazs Lengyel Ericsson Hungary Ltd. > System Manager > ECN: 831 7320 Tel: +36-1-437-7320 > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Tue Jun 17 12:49:50 2014 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 723901A00E7 for ; Tue, 17 Jun 2014 12:49:48 -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 KjssNZBc3noa for ; Tue, 17 Jun 2014 12:49:45 -0700 (PDT) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F0D61A00DF for ; Tue, 17 Jun 2014 12:49:45 -0700 (PDT) Received: by mail-pb0-f54.google.com with SMTP id un15so2954365pbc.27 for ; Tue, 17 Jun 2014 12:49:44 -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=mnBMshhf+PNH7Oyz8/Vg/bgQIojEEubScra0FfXemvg=; b=CVQPjO+mFrMDQawuUIu/3HNPTMKsyFqYwKiNKQP6Ywk4bsEy+RhuaUnL1Y+mYBfvEp 2BitPREL1j9XEwUvDdKxkh9sQvJF+SstlIXh7fBOpG4ddbLVyrKepS2IEQRKLHAhraZi mONYapDEmGux17imjQMF+gVPf5g7NYemuSPuJJpmDy0yevYqq5Z8yBbnmL3A8AHAGTzk +uZAekJNTPbjEJL3awFCwegHt9AxzDAxPapLf3XvXhgxCcalQczS34HYpDzlQo4V+H58 GEmLGBtSh+tf6fTCco8fZWmUhWbmxZkfC5LUjuAQJiFR22/8g3w01SLuU9LFQmeUL4vp IeWw== X-Received: by 10.66.132.81 with SMTP id os17mr35043201pab.137.1403034582524; Tue, 17 Jun 2014 12:49:42 -0700 (PDT) Received: from [192.168.178.23] (171.198.69.111.dynamic.snap.net.nz. [111.69.198.171]) by mx.google.com with ESMTPSA id xd11sm24527615pac.8.2014.06.17.12.49.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Jun 2014 12:49:41 -0700 (PDT) Message-ID: <53A09BD3.504@gmail.com> Date: Wed, 18 Jun 2014 07:49:39 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Michael Behringer (mbehring)" References: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BB3787@xmb-rcd-x14.cisco.com> <539F558B.8040701@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BB3F8B@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BB3F8B@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/4SduCcLnWOo12F76rIwgLgyDg9E Cc: "anima@ietf.org" Subject: Re: [Anima] Review of draft-irtf-nmrg-autonomic-network-definitions-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: Tue, 17 Jun 2014 19:49:48 -0000 On 17/06/2014 18:48, Michael Behringer (mbehring) wrote: >> There is one section we definitely have to update: >> >>> 5. Guidelines for Case Studies >>> >>> [This section is work in progress.] > > My view: At the time of writing this, it was meant to help in the procedure to get case studies, and yes, we do have the text. > > Now, if this document is to be published some time, I think we should move away from procedural text, and towards text that describes in general what makes a good autonomic functionality. Good point. > So already the word "case study" may be misleading. Yes, and the list of topics we developed for case studies can also serve as a list of topics to consider when evaluating functionality. > I'll have a go at some new text, but am of course happy to take suggestions. Please do. The I-D deadline is 2014-07-04 (Friday) UTC 23:59. Brian > Michael > >> However, this was discussed a few months ago on the NMRG list, so we >> have draft text for this already, and a few use case documents to validate it. >> >> Regards >> Brian >> >> On 17/06/2014 05:05, Michael Behringer (mbehring) wrote: >>> I'm starting to work on the next version of draft-irtf-nmrg-autonomic- >> network-definitions-00. >>> We should try to finalise this document asap; please review the document >> and provide your feedback here on this list. If you are ok with the document >> as it is, please also state this. In addition to detailed comments, we need a >> good feeling on how far away we are from a potential final version. >>> Thanks, >>> Michael >>> >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima >>> From nobody Tue Jun 17 12:52:24 2014 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 896891A00B7; Tue, 17 Jun 2014 12:52: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 b-Xc3WRc3oo8; Tue, 17 Jun 2014 12:52:19 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E48BE1A0163; Tue, 17 Jun 2014 12:52:18 -0700 (PDT) Received: by mail-pa0-f50.google.com with SMTP id bj1so4230134pad.23 for ; Tue, 17 Jun 2014 12:52:18 -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=OkLFEFPr64z3Kz8FHY/gBmGv7o1D/2m6FrbtKA2b3No=; b=U6CNw/OaaHovA3G6b2WaI71YOfvafC0vX/NFYKD0bPEdmm99iEGT3oKT0X77pv+y2X jvMav0nKykegY7JOT2inkEapa4npbFKpjFcF5tkqUUiFlIHyDYGKedwOl1/uqDHZX59T /jQfNZ09F6YVFTn7YZpS4uM1CZHRSf97Tc5x5fYdakHW64owBm3JoVVVQSi8fD0cfuo4 sTPn/L8iLqpC6nKUZauZxzat6w55YGKIzjyYP5onFM8v2GGPizGo/AMLWIrK05AON6Xq /beHnErGIAW6++3Xu8mSQAxU5u8gPNJPxtcH/LxSt9JpdgGU3bbFQEqc9zF0V8NsghW6 tgyw== X-Received: by 10.68.189.68 with SMTP id gg4mr35275232pbc.42.1403034738600; Tue, 17 Jun 2014 12:52:18 -0700 (PDT) Received: from [192.168.178.23] (171.198.69.111.dynamic.snap.net.nz. [111.69.198.171]) by mx.google.com with ESMTPSA id ao4sm25349736pbc.51.2014.06.17.12.52.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Jun 2014 12:52:18 -0700 (PDT) Message-ID: <53A09C73.2060309@gmail.com> Date: Wed, 18 Jun 2014 07:52:19 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Michael Behringer (mbehring)" References: <26717.1402949592@sandelman.ca> <539F771A.3000008@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BB3FF4@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BB3FF4@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/Yoj8_VidrOpQCVb_en7UsoiaBxw Cc: 6tisch-security <6tisch-security@ietf.org>, "anima@ietf.org" Subject: Re: [Anima] Scope question [was: autonomic bootstrap: gap analysis] 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, 17 Jun 2014 19:52:21 -0000 On 17/06/2014 18:59, Michael Behringer (mbehring) wrote: >> -----Original Message----- >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E >> Carpenter >> Sent: 17 June 2014 01:01 >> To: anima@ietf.org >> Cc: 6tisch-security >> Subject: [Anima] Scope question [was: autonomic bootstrap: gap analysis] >> >> Michael's message is very interesting. For present purposes, i.e. getting >> ready for the UCAN BOF, do we need to add some points to the relevant use >> case draft (http://tools.ietf.org/html/draft-behringer-autonomic- >> bootstrap)? >> >> More generally - I think the AN protagonists have been thinking of the >> scope of AN being carrier, enterprise, and home networks. >> Should we add IoT to the scope? I think it's an important question, because >> it would put new meanings on "simple" and "available resources". It seems >> obvious that IoT networks need to be completely autonomic, but is it the >> *same* autonomic? > > Brian, we have always positioned AN also in the IoT context, and I agree with Sheng, AN can be used everywhere. Especially when it comes to devices that will be deployed and managed in the thousands or even millions, autonomic concepts are a requirement, not a nice to have. Fully agree. But when I see people asking whether we will use YANG, I find myself wondering about low-end devices in an IoT context. Brian > We have positioned draft-pritikin-bootstrapping-keyinfrastructures as a high-level solution in 6tisch. It explains how you CAN bootstrap a network, zero-touch AND secure, and fits perfectly to the 6tisch requirements. The corresponding use case is described in draft-behringer-autonomic-bootstrap. > > To me, the bootstrap problem is one of the real solid examples of autonomic behaviour, because to bootstrap a device into a network I MUST have some functionality on the devices, ie, distribution is absolutely mandatory here. > > So this is one of the criteria for the use cases: Is distribution a requirement? Because if it is, then this points very clearly to an autonomic solution. > > Michael > > >> Regards >> Brian >> >> On 17/06/2014 08:13, Michael Richardson wrote: >>> I recognize that bootstrap is only one of the autonomic mechanisms >>> that are relevant to this group. I have much reading on the other >>> aspects which I hope to get done. >>> >>> The 6tisch security design team has been working on a "zero-touch" >>> mechanism that would permit constrained devices to join a >> Lowpower/Loss Network (LLN) >>> in a secure way. We have considered adapting EAP-TLS (as ZigbeeIP has >>> done), or turning the WirelessHART (IEC62591) packet flow into >>> something more IPv6-like. While there are significant bits of design >>> space to explore while trying to optimize packet count, size and total >>> energy risk of the join protocol; the idea that there should be a set >>> of authorization tokens From the device vendor which would permit the >>> network and new nodes to recognize each other has been central to all >> discussions. >>> while draft-pritikin-bootstrapping-keyinfrastructures and >>> draft-behringer-autonomic-bootstrap-00 >>> >>> have proposed valid high level concepts, I believe that specification >>> of the authz token is critical for the IoT space. A great concern >>> that is that the LLNs created remain operational for decades at a >>> time, and that the components can individually and also in aggregate >>> be both (re-)sold, and/or the service provider operating the network be >> replaced. >>> (There are real life examples where a part of a 100 square mile >>> refinery is actually sold to a competitor; obviously it doesn't get >>> moved. On the other side, one has the very real risk that you bought >>> your sensor network From a "Nortel") >>> >>> I was pointed at 802.1AR's device ID mechanism. Really, 802.1AR is >>> about an API between a (constrained) device and it's cryptographic >> hardware >>> module/TPM. It profiles a number of IETF PKIX specifications in a useful >>> way, but there is little there in terms of actual protocol. When it >>> comes to what does an *DevID look like, in it's section 7.2.8, saying >>> that the DN should contain a "serialNumber" attribute: >>> >>> The formatting of this field shall contain a unique X.500 >>> Distinguished Name (DN). This may include the unique device serial >> number assigned by the manufacturer >>> or any other suitable unique DN value that the issuer prefers. >>> >>> What I have observed is that there needs to be a way to clearly >>> delegate from >>> Factory(Vendor) to VAR to DISTRIBUTOR to RESELLER to Plant-OWNER to >>> SERVICE-PROVIDER. It would significantly reduce the number of >> certificates >>> in (non-constrained device) databases for some levels of this >>> hierarchy if the IDevID were aggregateable in some fashion. RFC3779 >>> came to mind, which deals with delegation of Autonomous Systems >>> Numbers (ASN) and IP address ranges from RIRs to LIRs to ISPs and >> Enterprises. >>> RFC3779: X.509 Extensions for IP Addresses and AS >>> Identifiers >>> >>> I created: >>> X509.v3 certificate extension for authorization of device ownership >>> draft-richardson-6tisch-idevid-cert-00 >>> >>> which cribbed together via nroff2xml and a search and replace. >>> >>> The Pritikin and Behringer documents seem to assume that the ultimate >>> goal of the trusted enrollment process is to create a path in which >>> "EST"= Enrollment over Secure Transport could operate that would >>> permit a new locally significant certificate to be loaded into the new >> device. >>> I agree with that goal. >>> >>> There is the question of how that trust circuit is created, and in >>> discussion it seemed that it involve some kind of leap-of-faith TLS >>> setup which would be authenticated by the "authz" tokens later on. I >>> disagree; I think that with appropriate evaluation of path constraints >>> that the authentication can occur within the TLS protocol. (Even >>> easier if done in IKEv2) >>> >>> -- >>> Michael Richardson , Sandelman Software >> Works >>> -= IPv6 IoT consulting =- >>> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > . > From nobody Tue Jun 17 13:00:14 2014 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 947891A0160; Tue, 17 Jun 2014 13:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 6HoNdtAWjvE1; Tue, 17 Jun 2014 13:00:11 -0700 (PDT) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D661E1A0123; Tue, 17 Jun 2014 13:00:10 -0700 (PDT) Received: by mail-yk0-f178.google.com with SMTP id q9so5636555ykb.37 for ; Tue, 17 Jun 2014 13:00:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=vwPj4T7GE9QKb47LQpXtDx/E2h2usp75U/ONdcdjGew=; b=jbFvO2WpFa/zK20tPCMB+E6tOnzBr24FJMDhrx1bnlWogOvH3FTEKLmt32annfAPUT NtWJsPbcxFamkr6q4kAGugmGY459OVFOhNOkWlUTZSuuT1RRPuLLJtRg7+dpGLtd5TdV tbtxFvvBrkBwLXmeYEcXQwWP7qEymGean7fciGNiQO/3QA6tITdlrXso9qJMTmLsWSLL Ee+yAfq8X3Kal1gNr/DDDGI0KbyWoBdCikL2lNSJ+d+io54cu/yYySinPD19sokXyYyY Omox/pFc92x2+4xorLVTsj+rpptYcqGn3jp1/3PL7Ueiex/RLAvwQqbJTAhwh2E8tgZA rgvQ== MIME-Version: 1.0 X-Received: by 10.236.153.9 with SMTP id e9mr46117448yhk.15.1403035210089; Tue, 17 Jun 2014 13:00:10 -0700 (PDT) Received: by 10.170.156.130 with HTTP; Tue, 17 Jun 2014 13:00:10 -0700 (PDT) In-Reply-To: <26717.1402949592@sandelman.ca> References: <26717.1402949592@sandelman.ca> Date: Tue, 17 Jun 2014 15:00:10 -0500 Message-ID: From: Behcet Sarikaya To: anima@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/anima/0Ku1A30AQHR7cKlnEXuwfiTBntY Cc: 6tisch-security <6tisch-security@ietf.org> Subject: Re: [Anima] autonomic bootstrap: gap analysis X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 20:00:12 -0000 Hi Michael, I had a draft on this for quite longtime, the link is: http://tools.ietf.org/html/draft-sarikaya-ace-secure-bootstrapping-00 you forgot to mention this one? Behcet On Mon, Jun 16, 2014 at 3:13 PM, Michael Richardson wrote: > > I recognize that bootstrap is only one of the autonomic mechanisms that > are relevant to this group. I have much reading on the other aspects > which I hope to get done. > > The 6tisch security design team has been working on a "zero-touch" mechanism > that would permit constrained devices to join a Lowpower/Loss Network (LLN) > in a secure way. We have considered adapting EAP-TLS (as ZigbeeIP has > done), or turning the WirelessHART (IEC62591) packet flow into something more > IPv6-like. While there are significant bits of design space to explore > while trying to optimize packet count, size and total energy risk of the > join protocol; the idea that there should be a set of authorization tokens > From the device vendor which would permit the network and new nodes to > recognize each other has been central to all discussions. > > while draft-pritikin-bootstrapping-keyinfrastructures and > draft-behringer-autonomic-bootstrap-00 > > have proposed valid high level concepts, I believe that specification of the > authz token is critical for the IoT space. A great concern that is that the > LLNs created remain operational for decades at a time, and that the > components can individually and also in aggregate be both (re-)sold, > and/or the service provider operating the network be replaced. > > (There are real life examples where a part of a 100 square mile refinery > is actually sold to a competitor; obviously it doesn't get moved. On the > other side, one has the very real risk that you bought your sensor network > From a "Nortel") > > I was pointed at 802.1AR's device ID mechanism. Really, 802.1AR is about an > API between a (constrained) device and it's cryptographic hardware > module/TPM. It profiles a number of IETF PKIX specifications in a useful > way, but there is little there in terms of actual protocol. When it comes to > what does an *DevID look like, in it's section 7.2.8, saying that the DN > should contain a "serialNumber" attribute: > > The formatting of this field shall contain a unique X.500 > Distinguished Name (DN). This may include the unique device serial number assigned by the manufacturer > or any other suitable unique DN value that the issuer prefers. > > What I have observed is that there needs to be a way to clearly delegate from > Factory(Vendor) to VAR to DISTRIBUTOR to RESELLER to Plant-OWNER to > SERVICE-PROVIDER. It would significantly reduce the number of certificates > in (non-constrained device) databases for some levels of this hierarchy if > the IDevID were aggregateable in some fashion. RFC3779 came to mind, which > deals with delegation of Autonomous Systems Numbers (ASN) and IP address > ranges from RIRs to LIRs to ISPs and Enterprises. > RFC3779: X.509 Extensions for IP Addresses and AS Identifiers > > I created: > X509.v3 certificate extension for authorization of device ownership > draft-richardson-6tisch-idevid-cert-00 > > which cribbed together via nroff2xml and a search and replace. > > The Pritikin and Behringer documents seem to assume that the ultimate goal of > the trusted enrollment process is to create a path in which "EST"= Enrollment > over Secure Transport could operate that would permit a new locally > significant certificate to be loaded into the new device. > I agree with that goal. > > There is the question of how that trust circuit is created, and in discussion > it seemed that it involve some kind of leap-of-faith TLS setup which would be > authenticated by the "authz" tokens later on. I disagree; I think that with > appropriate evaluation of path constraints that the authentication can occur > within the TLS protocol. (Even easier if done in IKEv2) > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Tue Jun 17 18:30:12 2014 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 50F461A0089 for ; Tue, 17 Jun 2014 18:30:09 -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 A6H1ocA9Zlf0 for ; Tue, 17 Jun 2014 18:30:07 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5FF91A006C for ; Tue, 17 Jun 2014 18:30:07 -0700 (PDT) Received: by mail-pa0-f49.google.com with SMTP id lj1so142329pab.36 for ; Tue, 17 Jun 2014 18:30:07 -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=dwymSY8rgjWL1aLfP3xhTHHbATyqgx16MDXiZ2YvhPE=; b=xxT0bEUErOd9AqPcg/flID223STNtdB6jWoI0lXOsA3syF+HsE5lxkudlYmBrx4xpT sOJlGAe1pd0/VKuHYRcjaIr+rxVHm0EwlTGlDq8FVtN/Y3MYqNsEhtjR/clOP+icrRk0 Ap8Q1wLA6qwAosuWdvqGqVeh2ltufUyzVdZdkroLEAfKJZxYQrv1wk0pYUUSU0XF/pbt WSezTueSzoqupwQDRHzsQBVRY/KXQcc3cv7Qanh9wcLnCJmuWfHPddsccAAV+8BkD+RC T77zBuglB1ggu93jGFTbIBW+VGVdGfomYv85lkrHW7w5OaE6Aou8OrDv0YeqrlUtK+UX 5vXQ== X-Received: by 10.68.161.101 with SMTP id xr5mr3362352pbb.168.1403055007403; Tue, 17 Jun 2014 18:30:07 -0700 (PDT) Received: from [172.24.60.8] (wireless-nat-21.auckland.ac.nz. [130.216.30.132]) by mx.google.com with ESMTPSA id pw4sm402798pbc.61.2014.06.17.18.30.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Jun 2014 18:30:06 -0700 (PDT) Message-ID: <53A0EBA1.4060404@gmail.com> Date: Wed, 18 Jun 2014 13:30:09 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: anima@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/xInAGgARQJQG9Kdh6hrUX65GVhk Subject: [Anima] What do operators want from 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: Wed, 18 Jun 2014 01:30:09 -0000 For the UCAN BOF in Toronto, we're looking for an operator of a reasonably large network who could talk for 5 or 10 minutes about what operators want from autonomic networking. Any volunteers? Current agenda etc. is to be found at http://trac.tools.ietf.org/bof/trac/wiki/WikiStart#UCANApprovedforIETF90 Regards Brian From nobody Tue Jun 17 23:16:40 2014 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 579A21A0253; Tue, 17 Jun 2014 23:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 qJT9x27weCWT; Tue, 17 Jun 2014 23:15:28 -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 38F961A0259; Tue, 17 Jun 2014 23:15:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=524; q=dns/txt; s=iport; t=1403072104; x=1404281704; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ko41FcMAMBzf8TKTwWl6kbkduv+u3iuwIo0KbOL+BkM=; b=UaBPOKWNbszBDGC89zKMi7ZQ64oSglF7Xa+87v77a7GJ0p6ZdrsZ2BS4 /0LYX9EV0hHYRg2sb7VuSDO7eMAVZEIJmtKOoVbiMVEydSRI8u7MAaZoB DDMjh7DHhGHHNgHEvoNK08uIQZinfZuBPMoAjmBTUCQH+G2xUF9Jnb8UK A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8IAPctoVOtJA2I/2dsb2JhbABagw1SWqoBDAEBAQEBAQUBmSgBgRAWdYQDAQEBBDo/DAQCAQgRBAEBCxQJBzIUCQgCBAENBQiIOg3LHBeFYohiMQcGgyeBFgEDnAaSFYNCgjA X-IronPort-AV: E=Sophos;i="5.01,499,1400025600"; d="scan'208";a="333696070" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-1.cisco.com with ESMTP; 18 Jun 2014 06:15:02 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s5I6F2kf029639 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Jun 2014 06:15:02 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Wed, 18 Jun 2014 01:15:02 -0500 From: "Michael Behringer (mbehring)" To: "sarikaya@ieee.org" , "anima@ietf.org" Thread-Topic: [Anima] autonomic bootstrap: gap analysis Thread-Index: AQHPimbHvkmm1okankiBjKDA2xpKqJt2ZFjw Date: Wed, 18 Jun 2014 06:15:01 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BB66C4@xmb-rcd-x14.cisco.com> References: <26717.1402949592@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.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/anima/nKovDZofBdpzSevsRSSL7cEnrcA Cc: 6tisch-security <6tisch-security@ietf.org> Subject: Re: [Anima] autonomic bootstrap: gap analysis 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, 18 Jun 2014 06:16:27 -0000 > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Behcet > Sarikaya > Sent: 17 June 2014 22:00 > To: anima@ietf.org > Cc: 6tisch-security > Subject: Re: [Anima] autonomic bootstrap: gap analysis >=20 > Hi Michael, >=20 > I had a draft on this for quite longtime, the link is: >=20 > http://tools.ietf.org/html/draft-sarikaya-ace-secure-bootstrapping-00 >=20 > you forgot to mention this one? I missed that one. Will have a look now. Thanks for the pointer! Michael From nobody Tue Jun 17 23:37:56 2014 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 80E2F1A0009; Tue, 17 Jun 2014 23:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 jElDcRBWAj8a; Tue, 17 Jun 2014 23:37:49 -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 B20CC1A0007; Tue, 17 Jun 2014 23:37:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8185; q=dns/txt; s=iport; t=1403073469; x=1404283069; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=9+ZIVMN7aArTmaku+db5ZHfIxWdxT8YBFeQGmZeiOp0=; b=eguDN4D6ifPSLoabp0LSe+4mdxiF0Pb729OCAWm69fDE/w7PaomLvrj8 3kcwj9x9yNRexNcSGlm3e7FsZ1hPCE857weLUIpK6PQN53BjFq0t+wofb VEEi/HFmkK0z5nIVEMZfJSpsgCQABSwUADx3s2sJGfxn5RXMxBdXxvACN Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAIAKcyoVOtJA2D/2dsb2JhbABagw1SWqoNAQEBAQEBBQGRaYc/AYEQFnWEAwEBAQMBAQEBNy0HCwUHBAIBCBEEAQEBChQJBycLFAkIAgQBDQUIEQKIHwgNyyIXhWKDYIUCMQcGgyeBFgScBpIVg0KCMA X-IronPort-AV: E=Sophos;i="5.01,499,1400025600"; d="scan'208";a="333909412" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-8.cisco.com with ESMTP; 18 Jun 2014 06:37:48 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s5I6bmJ5021596 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Jun 2014 06:37:48 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.126]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Wed, 18 Jun 2014 01:37:48 -0500 From: "Pascal Thubert (pthubert)" To: Brian E Carpenter , "Michael Behringer (mbehring)" Thread-Topic: [Anima] Scope question [was: autonomic bootstrap: gap analysis] Thread-Index: AQHPimWl+r7+Wyo420qLfv6C2sl4f5t2aUfA Date: Wed, 18 Jun 2014 06:37:47 +0000 Deferred-Delivery: Wed, 18 Jun 2014 06:37:00 +0000 Message-ID: References: <26717.1402949592@sandelman.ca> <539F771A.3000008@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BB3FF4@xmb-rcd-x14.cisco.com> <53A09C73.2060309@gmail.com> In-Reply-To: <53A09C73.2060309@gmail.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.221.222] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/anima/-k5r_6umjBBeub7qCtdPrpQStvo Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "anima@ietf.org" Subject: Re: [Anima] Scope question [was: autonomic bootstrap: gap analysis] 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, 18 Jun 2014 06:37:52 -0000 Hello Brian >> Brian, we have always positioned AN also in the IoT context, and I agree >> with Sheng, AN can be used everywhere. Especially when it comes to devic= es >> that will be deployed and managed in the thousands or even millions, >> autonomic concepts are a requirement, not a nice to have. > Fully agree. But when I see people asking whether we will use YANG, I fin= d > myself wondering about low-end devices in an IoT context. 6TiSCH uses YANG to model the configuration data of the 6top sublayer.=20 There was no perceived contradiction between that modelling and the constrained environment that we are targeting for. AN is definitely a key technology for large scale IoT applications. In the specific use case of industrial, additional policies may still have to be a= pplied to impose zone and conduits structures, but the more autonomicity the better. Cheers, Pascal > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E > Carpenter > Sent: mardi 17 juin 2014 21:52 > To: Michael Behringer (mbehring) > Cc: 6tisch-security; anima@ietf.org > Subject: Re: [Anima] Scope question [was: autonomic bootstrap: gap > analysis] >=20 > On 17/06/2014 18:59, Michael Behringer (mbehring) wrote: > >> -----Original Message----- > >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E > >> Carpenter > >> Sent: 17 June 2014 01:01 > >> To: anima@ietf.org > >> Cc: 6tisch-security > >> Subject: [Anima] Scope question [was: autonomic bootstrap: gap > >> analysis] > >> > >> Michael's message is very interesting. For present purposes, i.e. > >> getting ready for the UCAN BOF, do we need to add some points to the > >> relevant use case draft > >> (http://tools.ietf.org/html/draft-behringer-autonomic- > >> bootstrap)? > >> > >> More generally - I think the AN protagonists have been thinking of > >> the scope of AN being carrier, enterprise, and home networks. > >> Should we add IoT to the scope? I think it's an important question, > >> because it would put new meanings on "simple" and "available > >> resources". It seems obvious that IoT networks need to be completely > >> autonomic, but is it the > >> *same* autonomic? > > > > Brian, we have always positioned AN also in the IoT context, and I agre= e > with Sheng, AN can be used everywhere. Especially when it comes to device= s > that will be deployed and managed in the thousands or even millions, > autonomic concepts are a requirement, not a nice to have. >=20 > Fully agree. But when I see people asking whether we will use YANG, I fin= d > myself wondering about low-end devices in an IoT context. >=20 > Brian >=20 > > We have positioned draft-pritikin-bootstrapping-keyinfrastructures as a > high-level solution in 6tisch. It explains how you CAN bootstrap a networ= k, > zero-touch AND secure, and fits perfectly to the 6tisch requirements. The > corresponding use case is described in draft-behringer-autonomic-bootstra= p. > > > > To me, the bootstrap problem is one of the real solid examples of > autonomic behaviour, because to bootstrap a device into a network I MUST > have some functionality on the devices, ie, distribution is absolutely > mandatory here. > > > > So this is one of the criteria for the use cases: Is distribution a > requirement? Because if it is, then this points very clearly to an autono= mic > solution. > > > > Michael > > > > > >> Regards > >> Brian > >> > >> On 17/06/2014 08:13, Michael Richardson wrote: > >>> I recognize that bootstrap is only one of the autonomic mechanisms > >>> that are relevant to this group. I have much reading on the other > >>> aspects which I hope to get done. > >>> > >>> The 6tisch security design team has been working on a "zero-touch" > >>> mechanism that would permit constrained devices to join a > >> Lowpower/Loss Network (LLN) > >>> in a secure way. We have considered adapting EAP-TLS (as ZigbeeIP h= as > >>> done), or turning the WirelessHART (IEC62591) packet flow into > >>> something more IPv6-like. While there are significant bits of > >>> design space to explore while trying to optimize packet count, size > >>> and total energy risk of the join protocol; the idea that there > >>> should be a set of authorization tokens From the device vendor which > >>> would permit the network and new nodes to recognize each other has > >>> been central to all > >> discussions. > >>> while draft-pritikin-bootstrapping-keyinfrastructures and > >>> draft-behringer-autonomic-bootstrap-00 > >>> > >>> have proposed valid high level concepts, I believe that > >>> specification of the authz token is critical for the IoT space. A > >>> great concern that is that the LLNs created remain operational for > >>> decades at a time, and that the components can individually and also > >>> in aggregate be both (re-)sold, and/or the service provider > >>> operating the network be > >> replaced. > >>> (There are real life examples where a part of a 100 square mile > >>> refinery is actually sold to a competitor; obviously it doesn't get > >>> moved. On the other side, one has the very real risk that you > >>> bought your sensor network From a "Nortel") > >>> > >>> I was pointed at 802.1AR's device ID mechanism. Really, 802.1AR is > >>> about an API between a (constrained) device and it's cryptographic > >> hardware > >>> module/TPM. It profiles a number of IETF PKIX specifications in a u= seful > >>> way, but there is little there in terms of actual protocol. When it > >>> comes to what does an *DevID look like, in it's section 7.2.8, > >>> saying that the DN should contain a "serialNumber" attribute: > >>> > >>> The formatting of this field shall contain a unique X.500 > >>> Distinguished Name (DN). This may include the unique device > >>> serial > >> number assigned by the manufacturer > >>> or any other suitable unique DN value that the issuer prefers. > >>> > >>> What I have observed is that there needs to be a way to clearly > >>> delegate from > >>> Factory(Vendor) to VAR to DISTRIBUTOR to RESELLER to Plant-OWNER to > >>> SERVICE-PROVIDER. It would significantly reduce the number of > >> certificates > >>> in (non-constrained device) databases for some levels of this > >>> hierarchy if the IDevID were aggregateable in some fashion. RFC3779 > >>> came to mind, which deals with delegation of Autonomous Systems > >>> Numbers (ASN) and IP address ranges from RIRs to LIRs to ISPs and > >> Enterprises. > >>> RFC3779: X.509 Extensions for IP Addresses and AS > >>> Identifiers > >>> > >>> I created: > >>> X509.v3 certificate extension for authorization of device ownersh= ip > >>> draft-richardson-6tisch-idevid-cert-00 > >>> > >>> which cribbed together via nroff2xml and a search and replace. > >>> > >>> The Pritikin and Behringer documents seem to assume that the > >>> ultimate goal of the trusted enrollment process is to create a path > >>> in which "EST"=3D Enrollment over Secure Transport could operate that > >>> would permit a new locally significant certificate to be loaded into > >>> the new > >> device. > >>> I agree with that goal. > >>> > >>> There is the question of how that trust circuit is created, and in > >>> discussion it seemed that it involve some kind of leap-of-faith TLS > >>> setup which would be authenticated by the "authz" tokens later on. > >>> I disagree; I think that with appropriate evaluation of path > >>> constraints that the authentication can occur within the TLS > >>> protocol. (Even easier if done in IKEv2) > >>> > >>> -- > >>> 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 Wed Jun 18 12:51:34 2014 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 7D5441A02B7; Wed, 18 Jun 2014 12:51:31 -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 f5rB2_r44ZPP; Wed, 18 Jun 2014 12:51:29 -0700 (PDT) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F68A1A0132; Wed, 18 Jun 2014 12:51:29 -0700 (PDT) Received: by mail-pb0-f51.google.com with SMTP id rp16so1073952pbb.24 for ; Wed, 18 Jun 2014 12:51: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:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=iWQRPUZp5Np/MwYtp8GeYF0bVXiO+7Dr+WtyXN/H9vg=; b=bEEgVih+3USa3tfxdV91M4Jc8JFWajx6HPctzupt1F6toTj4JosJdmMve2qpaTBxLP tfZHdN6Lcbvt48ZO/O7XUymTzf+pao6PUT1fk0Z+w6pn95Tg5QIbGnOok6lHP2+0ugUK 3eL25w6iDssQyJTGTre4U8oH1dn8PFKzeyP3DqwkrBqdNZt0HnhqkFa7DGgs2Kl7ElsO mwxWA5g5WySBxpUVvWXtOUrUVjcv4kLR9hNAcTG8vos3U4CVLsPJbyxsFT4WkjH0LIAg FXCD2n8/0pzPJqYmPjnSJ85gHwqEN6OWZG2I9dQcQ0Z+J1Nkl2MHeVc47l4Ev4uRqsTZ u4WA== X-Received: by 10.68.193.193 with SMTP id hq1mr143332pbc.107.1403121088701; Wed, 18 Jun 2014 12:51:28 -0700 (PDT) Received: from [192.168.178.23] (207.194.69.111.dynamic.snap.net.nz. [111.69.194.207]) by mx.google.com with ESMTPSA id xh10sm14918266pac.24.2014.06.18.12.51.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Jun 2014 12:51:28 -0700 (PDT) Message-ID: <53A1EDC4.9060800@gmail.com> Date: Thu, 19 Jun 2014 07:51:32 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <26717.1402949592@sandelman.ca> <539F771A.3000008@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BB3FF4@xmb-rcd-x14.cisco.com> <53A09C73.2060309@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/Sq88ZddxQbkunNmBXOpx6cZxQ4Y Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "anima@ietf.org" , "Michael Behringer \(mbehring\)" Subject: Re: [Anima] Scope question [was: autonomic bootstrap: gap analysis] 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, 18 Jun 2014 19:51:31 -0000 On 18/06/2014 18:37, Pascal Thubert (pthubert) wrote: > Hello Brian > >>> Brian, we have always positioned AN also in the IoT context, and I agree >>> with Sheng, AN can be used everywhere. Especially when it comes to devices >>> that will be deployed and managed in the thousands or even millions, >>> autonomic concepts are a requirement, not a nice to have. > >> Fully agree. But when I see people asking whether we will use YANG, I find >> myself wondering about low-end devices in an IoT context. > > 6TiSCH uses YANG to model the configuration data of the 6top sublayer. > There was no perceived contradiction between that modelling and the > constrained environment that we are targeting for. For those of us on the anima list that don't follow 6TiSCH in detail, can you sketch out the boundary between the high level model and the low end devices? (I fully recognise the advantage of a high level model.) Brian > > AN is definitely a key technology for large scale IoT applications. In the > specific use case of industrial, additional policies may still have to be applied > to impose zone and conduits structures, but the more autonomicity the > better. > > Cheers, > > Pascal > >> -----Original Message----- >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E >> Carpenter >> Sent: mardi 17 juin 2014 21:52 >> To: Michael Behringer (mbehring) >> Cc: 6tisch-security; anima@ietf.org >> Subject: Re: [Anima] Scope question [was: autonomic bootstrap: gap >> analysis] >> >> On 17/06/2014 18:59, Michael Behringer (mbehring) wrote: >>>> -----Original Message----- >>>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E >>>> Carpenter >>>> Sent: 17 June 2014 01:01 >>>> To: anima@ietf.org >>>> Cc: 6tisch-security >>>> Subject: [Anima] Scope question [was: autonomic bootstrap: gap >>>> analysis] >>>> >>>> Michael's message is very interesting. For present purposes, i.e. >>>> getting ready for the UCAN BOF, do we need to add some points to the >>>> relevant use case draft >>>> (http://tools.ietf.org/html/draft-behringer-autonomic- >>>> bootstrap)? >>>> >>>> More generally - I think the AN protagonists have been thinking of >>>> the scope of AN being carrier, enterprise, and home networks. >>>> Should we add IoT to the scope? I think it's an important question, >>>> because it would put new meanings on "simple" and "available >>>> resources". It seems obvious that IoT networks need to be completely >>>> autonomic, but is it the >>>> *same* autonomic? >>> Brian, we have always positioned AN also in the IoT context, and I agree >> with Sheng, AN can be used everywhere. Especially when it comes to devices >> that will be deployed and managed in the thousands or even millions, >> autonomic concepts are a requirement, not a nice to have. >> >> Fully agree. But when I see people asking whether we will use YANG, I find >> myself wondering about low-end devices in an IoT context. >> >> Brian >> >>> We have positioned draft-pritikin-bootstrapping-keyinfrastructures as a >> high-level solution in 6tisch. It explains how you CAN bootstrap a network, >> zero-touch AND secure, and fits perfectly to the 6tisch requirements. The >> corresponding use case is described in draft-behringer-autonomic-bootstrap. >>> To me, the bootstrap problem is one of the real solid examples of >> autonomic behaviour, because to bootstrap a device into a network I MUST >> have some functionality on the devices, ie, distribution is absolutely >> mandatory here. >>> So this is one of the criteria for the use cases: Is distribution a >> requirement? Because if it is, then this points very clearly to an autonomic >> solution. >>> Michael >>> >>> >>>> Regards >>>> Brian >>>> >>>> On 17/06/2014 08:13, Michael Richardson wrote: >>>>> I recognize that bootstrap is only one of the autonomic mechanisms >>>>> that are relevant to this group. I have much reading on the other >>>>> aspects which I hope to get done. >>>>> >>>>> The 6tisch security design team has been working on a "zero-touch" >>>>> mechanism that would permit constrained devices to join a >>>> Lowpower/Loss Network (LLN) >>>>> in a secure way. We have considered adapting EAP-TLS (as ZigbeeIP has >>>>> done), or turning the WirelessHART (IEC62591) packet flow into >>>>> something more IPv6-like. While there are significant bits of >>>>> design space to explore while trying to optimize packet count, size >>>>> and total energy risk of the join protocol; the idea that there >>>>> should be a set of authorization tokens From the device vendor which >>>>> would permit the network and new nodes to recognize each other has >>>>> been central to all >>>> discussions. >>>>> while draft-pritikin-bootstrapping-keyinfrastructures and >>>>> draft-behringer-autonomic-bootstrap-00 >>>>> >>>>> have proposed valid high level concepts, I believe that >>>>> specification of the authz token is critical for the IoT space. A >>>>> great concern that is that the LLNs created remain operational for >>>>> decades at a time, and that the components can individually and also >>>>> in aggregate be both (re-)sold, and/or the service provider >>>>> operating the network be >>>> replaced. >>>>> (There are real life examples where a part of a 100 square mile >>>>> refinery is actually sold to a competitor; obviously it doesn't get >>>>> moved. On the other side, one has the very real risk that you >>>>> bought your sensor network From a "Nortel") >>>>> >>>>> I was pointed at 802.1AR's device ID mechanism. Really, 802.1AR is >>>>> about an API between a (constrained) device and it's cryptographic >>>> hardware >>>>> module/TPM. It profiles a number of IETF PKIX specifications in a useful >>>>> way, but there is little there in terms of actual protocol. When it >>>>> comes to what does an *DevID look like, in it's section 7.2.8, >>>>> saying that the DN should contain a "serialNumber" attribute: >>>>> >>>>> The formatting of this field shall contain a unique X.500 >>>>> Distinguished Name (DN). This may include the unique device >>>>> serial >>>> number assigned by the manufacturer >>>>> or any other suitable unique DN value that the issuer prefers. >>>>> >>>>> What I have observed is that there needs to be a way to clearly >>>>> delegate from >>>>> Factory(Vendor) to VAR to DISTRIBUTOR to RESELLER to Plant-OWNER to >>>>> SERVICE-PROVIDER. It would significantly reduce the number of >>>> certificates >>>>> in (non-constrained device) databases for some levels of this >>>>> hierarchy if the IDevID were aggregateable in some fashion. RFC3779 >>>>> came to mind, which deals with delegation of Autonomous Systems >>>>> Numbers (ASN) and IP address ranges from RIRs to LIRs to ISPs and >>>> Enterprises. >>>>> RFC3779: X.509 Extensions for IP Addresses and AS >>>>> Identifiers >>>>> >>>>> I created: >>>>> X509.v3 certificate extension for authorization of device ownership >>>>> draft-richardson-6tisch-idevid-cert-00 >>>>> >>>>> which cribbed together via nroff2xml and a search and replace. >>>>> >>>>> The Pritikin and Behringer documents seem to assume that the >>>>> ultimate goal of the trusted enrollment process is to create a path >>>>> in which "EST"= Enrollment over Secure Transport could operate that >>>>> would permit a new locally significant certificate to be loaded into >>>>> the new >>>> device. >>>>> I agree with that goal. >>>>> >>>>> There is the question of how that trust circuit is created, and in >>>>> discussion it seemed that it involve some kind of leap-of-faith TLS >>>>> setup which would be authenticated by the "authz" tokens later on. >>>>> I disagree; I think that with appropriate evaluation of path >>>>> constraints that the authentication can occur within the TLS >>>>> protocol. (Even easier if done in IKEv2) >>>>> >>>>> -- >>>>> 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 > From nobody Fri Jun 20 05:14:54 2014 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 E6C451A0401 for ; Fri, 20 Jun 2014 05:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 BiaGFpX0O-K1 for ; Fri, 20 Jun 2014 05:14:50 -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 36FE11A064E for ; Fri, 20 Jun 2014 05:14:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2868; q=dns/txt; s=iport; t=1403266490; x=1404476090; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=LgSQodbEIIlPLtU+lssblnsrXG8LScUV2ots7OEC2uc=; b=YqXYnrmJiUj00bd8P389Sj58M9/THREaKxBH2wVQhCKkBCEhcSx0C3lD 6fu7uxtTCXXugnH4GCYkRdJEa3QdsNRvRSR/NXxqtTTvJaQektyHRXGT5 bhhwioNVLfPtt7QPcZczky5CtoZ23MB5dGoO2uU2tqlX1pEkDkqyWSl+K Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4GAOUkpFOtJV2Z/2dsb2JhbABZgw1SWqloNwEBAQEBAQUBkWuHPwGBBhZ1hAMBAQEEAQEBNzQXBAIBCBEEAQELFAkHJwsUBwEBBQMCBBMIAYg5DcsSF4ViiGMzBQaDJ4EWBJwHjBiFf4NCbIFE X-IronPort-AV: E=Sophos;i="5.01,513,1400025600"; d="scan'208";a="334505585" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 20 Jun 2014 12:14:49 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s5KCEn8d018205 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 20 Jun 2014 12:14:49 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Fri, 20 Jun 2014 07:14:49 -0500 From: "Michael Behringer (mbehring)" To: "anima@ietf.org" Thread-Topic: I-D Action: draft-behringer-autonomic-control-plane-00.txt Thread-Index: AQHPjG3EJl0xwnCxwU6YiY92IDk6PZt5xQTg Date: Fri, 20 Jun 2014 12:14:47 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BBAB34@xmb-rcd-x14.cisco.com> References: <20140620095502.9324.99373.idtracker@ietfa.amsl.com> In-Reply-To: <20140620095502.9324.99373.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.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/anima/gVy7-yAUEcADRxAEJfZ5EVrJxE8 Subject: [Anima] FW: I-D Action: draft-behringer-autonomic-control-plane-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: Fri, 20 Jun 2014 12:14:52 -0000 The draft we just posted makes another good use case for an autonomic funct= ion, and we'd like to suggest it for the agenda of the UCAN BoF.=20 In a nutshell: Every autonomic node creates a secure channel to all its nei= ghbours, based on link local addressing. Those channels are kept in a diffe= rent context (VRF), and thus automatically create an overlay network. The t= hing to note is that this overlay network doesn't depend on config or (conf= igured) addressing, and is therefore not affected by many common config or = routing errors.=20 It is a classical autonomic function, because every node must act independe= ntly for this "virtual out of band" channel to come up. A good example for = a self-managing function. We'd love to get feedback on this draft.=20 Michael > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: 20 June 2014 11:55 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-behringer-autonomic-control-plane-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : An Autonomic Control Plane > Authors : Michael H. Behringer > Steinthor Bjarnason > Balaji BL > Toerless Eckert > Filename : draft-behringer-autonomic-control-plane-00.txt > Pages : 10 > Date : 2014-06-20 >=20 > Abstract: > In certain scenarios, for example when bootstrapping a network, it is > desirable to automatically bring up a secure, routed control plane, > which is independent of device configurations and global routing > table. This document describes an approach for an "Autonomic Control > Plane", which can be used as a "virtual out of band channel" - a > self-managing overlay network, which is independent of configuration, > addressing and routing on the data plane. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-behringer-autonomic-control-plane/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-behringer-autonomic-control-plane-00 >=20 >=20 > 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.iet= f.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > 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 Fri Jun 20 12:40:22 2014 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 2E20A1B28B1 for ; Fri, 20 Jun 2014 12:40: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 JlOkmYf_oI5g for ; Fri, 20 Jun 2014 12:40:12 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C8021A02F6 for ; Fri, 20 Jun 2014 12:40:12 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id y10so3291178pdj.5 for ; Fri, 20 Jun 2014 12:40:11 -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=ut27cYoUmD5Zp2EBUVB4MYvZh8Jcufpt2l9TipVnS6g=; b=0VjPQG45Ofs4keWvWT7aVq7sEpfeMvbdCmjNd8ufKmczkth/sIK0uh3V2P6zQDSSpW y9DxBtxoLjIGxwvVZ2SvijlcZ5jihac4A3GZfOnOTnR/pTDb9iCRfOXZclq3AEL1RYjy cxebFigvu3Af5Wgq2y0xrINcBgcskRygYa1VhNwWc95FlfIK9crdtpocXbXNURUK42Nj rFLx61D6zP8+w6ZWjdbpbiUgy79ir8BrXyVmOCyy1HYHqECm1JiC8EZHa2XYrhwS19KG fZT1LAIU1dw4BM98ocg/iw8ugLeWqnWK2dsHxrQOk37m7d+Nf+bjzTUFBfJKTNaywRjT KBWA== X-Received: by 10.68.213.34 with SMTP id np2mr7438849pbc.167.1403293211453; Fri, 20 Jun 2014 12:40:11 -0700 (PDT) Received: from [192.168.178.23] (224.195.69.111.dynamic.snap.net.nz. [111.69.195.224]) by mx.google.com with ESMTPSA id qv3sm14757237pbb.87.2014.06.20.12.40.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Jun 2014 12:40:10 -0700 (PDT) Message-ID: <53A48E1E.6040909@gmail.com> Date: Sat, 21 Jun 2014 07:40:14 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Michael Behringer (mbehring)" References: <20140620095502.9324.99373.idtracker@ietfa.amsl.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BBAB34@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BBAB34@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/UjGrKU76tLghNWk07YU8mS_SOFE Cc: "anima@ietf.org" Subject: Re: [Anima] FW: I-D Action: draft-behringer-autonomic-control-plane-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: Fri, 20 Jun 2014 19:40:14 -0000 Michael, I've only had time for a quick glance so far (it's 07:40 Saturday for me) but this seems closer to solution space than to use cases. More when it gets to the top of my reading list... Regards Brian On 21/06/2014 00:14, Michael Behringer (mbehring) wrote: > The draft we just posted makes another good use case for an autonomic function, and we'd like to suggest it for the agenda of the UCAN BoF. > > In a nutshell: Every autonomic node creates a secure channel to all its neighbours, based on link local addressing. Those channels are kept in a different context (VRF), and thus automatically create an overlay network. The thing to note is that this overlay network doesn't depend on config or (configured) addressing, and is therefore not affected by many common config or routing errors. > > It is a classical autonomic function, because every node must act independently for this "virtual out of band" channel to come up. A good example for a self-managing function. > > We'd love to get feedback on this draft. > Michael > >> -----Original Message----- >> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of >> internet-drafts@ietf.org >> Sent: 20 June 2014 11:55 >> To: i-d-announce@ietf.org >> Subject: I-D Action: draft-behringer-autonomic-control-plane-00.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : An Autonomic Control Plane >> Authors : Michael H. Behringer >> Steinthor Bjarnason >> Balaji BL >> Toerless Eckert >> Filename : draft-behringer-autonomic-control-plane-00.txt >> Pages : 10 >> Date : 2014-06-20 >> >> Abstract: >> In certain scenarios, for example when bootstrapping a network, it is >> desirable to automatically bring up a secure, routed control plane, >> which is independent of device configurations and global routing >> table. This document describes an approach for an "Autonomic Control >> Plane", which can be used as a "virtual out of band channel" - a >> self-managing overlay network, which is independent of configuration, >> addressing and routing on the data plane. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-behringer-autonomic-control-plane/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-behringer-autonomic-control-plane-00 >> >> >> 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 > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Sun Jun 22 22:54:52 2014 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 C0A911B29B1 for ; Sun, 22 Jun 2014 22:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 gpujrF06GQZz for ; Sun, 22 Jun 2014 22:54:48 -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 B37D21B29AC for ; Sun, 22 Jun 2014 22:54:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5880; q=dns/txt; s=iport; t=1403502888; x=1404712488; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JdU4Z5sTzHEAYrNytj5UZDy+7Zs5AKszQL9P4CkUBv0=; b=Llow+fAxPX1v8ftiGjNiq9zY3tDKyxuKne9+v3dyP/+oxKQB/s1h4Wj3 c29/82CN6c2sosnKNZ5KQryJOQvBbCvmHj6yukjDAe235GgpdnIR6u8ZC mnW+yznQuOquTXPkbqNxdDFDsFN5jpON1OKsxXQyQkAOAwd3kQeGmlQcB c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsHAIfAp1OtJV2S/2dsb2JhbABZgw1SWoJtpw83AQEBAQEBBQGRdYdAARluFnWEAwEBAQQBAQEgEToLDAQCAQgRBAEBAQICBh0DAgICHwYLFAEHAQgCBA4FCAESiBMDEQ2oOJZ7DYZLF4EqhDmGdIF0FhsHBoJxNoEWBJhSgz+MGAOGA4NCbIFE X-IronPort-AV: E=Sophos;i="5.01,527,1400025600"; d="scan'208";a="334910858" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-2.cisco.com with ESMTP; 23 Jun 2014 05:54:47 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s5N5slna006000 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Jun 2014 05:54:47 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Mon, 23 Jun 2014 00:54:47 -0500 From: "Michael Behringer (mbehring)" To: Brian E Carpenter Thread-Topic: [Anima] FW: I-D Action: draft-behringer-autonomic-control-plane-00.txt Thread-Index: AQHPjL90h1Ok6RP9NkiG2xT+ia8NvJt+NQ1Q Date: Mon, 23 Jun 2014 05:54:46 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BBC9DD@xmb-rcd-x14.cisco.com> References: <20140620095502.9324.99373.idtracker@ietfa.amsl.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BBAB34@xmb-rcd-x14.cisco.com> <53A48E1E.6040909@gmail.com> In-Reply-To: <53A48E1E.6040909@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.137] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/anima/gq6rayh_7i6VM1a4069JTmKFRWw Cc: "anima@ietf.org" Subject: Re: [Anima] FW: I-D Action: draft-behringer-autonomic-control-plane-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: Mon, 23 Jun 2014 05:54:51 -0000 V2VsbCwgeWVzLCBpdCBhbHNvIGRlc2NyaWJlcyB0aGUgc29sdXRpb24gKGZyYW5rbHksIGdpdmVu IHRoYXQgdGhpcyBpcyBjb21wbGV0ZWx5IG5ldywgSSB0aGluayB3ZSBtdXN0IGRlc2NyaWJlIGhv dyBpdCB3b3JrcyBmb3IgaXQgdG8gYmUgdW5kZXJzdG9vZC4gDQoNCkF0IHRoZSBzYW1lIHRpbWUs IGl0IGlzIGEgdXNlIGNhc2UsIGFuZCB0aGUgdGhyZWUgdXNlIGNhc2VzIGFyZSBkZXNjcmliZWQg aW4gdGhlIGRvYy4gVGhlIGNvbW11bmljYXRpb25zIGlzIGFsc28gZGVzY3JpYmVkLiANCg0KRXZl cnlib2R5LCBwbGVhc2UgaGF2ZSBhIGxvb2ssIGFuZCBsZXQgbWUga25vdyB3aGV0aGVyIHdlIHNo b3VsZCANCjEpIHN1Ym1pdCBhIHB1cmUgdXNlIGNhc2UgZHJhZnQgZm9yIHRoaXMgKHdoaWNoIHdv dWxkIGJlIHF1aXRlIG92ZXJsYXBwaW5nIG9yDQoyKSBhZGQgbW9yZSBvZiB0aGUgdGVtcGxhdGUg aW5mbyBpbiB0aGlzIGRyYWZ0IG9yIA0KMykgd2hldGhlciBpdCdzICJnb29kIGVub3VnaCIgZm9y IHRoZSBkaXNjdXNzdGlvbi4gDQoNCk1pY2hhZWwNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IEJyaWFuIEUgQ2FycGVudGVyIFttYWlsdG86YnJpYW4uZS5jYXJwZW50 ZXJAZ21haWwuY29tXQ0KPiBTZW50OiAyMCBKdW5lIDIwMTQgMjE6NDANCj4gVG86IE1pY2hhZWwg QmVocmluZ2VyIChtYmVocmluZykNCj4gQ2M6IGFuaW1hQGlldGYub3JnDQo+IFN1YmplY3Q6IFJl OiBbQW5pbWFdIEZXOiBJLUQgQWN0aW9uOiBkcmFmdC1iZWhyaW5nZXItYXV0b25vbWljLWNvbnRy b2wtDQo+IHBsYW5lLTAwLnR4dA0KPiANCj4gTWljaGFlbCwNCj4gDQo+IEkndmUgb25seSBoYWQg dGltZSBmb3IgYSBxdWljayBnbGFuY2Ugc28gZmFyIChpdCdzIDA3OjQwIFNhdHVyZGF5IGZvciBt ZSkgYnV0DQo+IHRoaXMgc2VlbXMgY2xvc2VyIHRvIHNvbHV0aW9uIHNwYWNlIHRoYW4gdG8gdXNl IGNhc2VzLg0KPiANCj4gTW9yZSB3aGVuIGl0IGdldHMgdG8gdGhlIHRvcCBvZiBteSByZWFkaW5n IGxpc3QuLi4NCj4gDQo+IFJlZ2FyZHMNCj4gICAgQnJpYW4NCj4gDQo+IE9uIDIxLzA2LzIwMTQg MDA6MTQsIE1pY2hhZWwgQmVocmluZ2VyIChtYmVocmluZykgd3JvdGU6DQo+ID4gVGhlIGRyYWZ0 IHdlIGp1c3QgcG9zdGVkIG1ha2VzIGFub3RoZXIgZ29vZCB1c2UgY2FzZSBmb3IgYW4gYXV0b25v bWljDQo+IGZ1bmN0aW9uLCBhbmQgd2UnZCBsaWtlIHRvIHN1Z2dlc3QgaXQgZm9yIHRoZSBhZ2Vu ZGEgb2YgdGhlIFVDQU4gQm9GLg0KPiA+DQo+ID4gSW4gYSBudXRzaGVsbDogRXZlcnkgYXV0b25v bWljIG5vZGUgY3JlYXRlcyBhIHNlY3VyZSBjaGFubmVsIHRvIGFsbCBpdHMNCj4gbmVpZ2hib3Vy cywgYmFzZWQgb24gbGluayBsb2NhbCBhZGRyZXNzaW5nLiBUaG9zZSBjaGFubmVscyBhcmUga2Vw dCBpbiBhDQo+IGRpZmZlcmVudCBjb250ZXh0IChWUkYpLCBhbmQgdGh1cyBhdXRvbWF0aWNhbGx5 IGNyZWF0ZSBhbiBvdmVybGF5IG5ldHdvcmsuDQo+IFRoZSB0aGluZyB0byBub3RlIGlzIHRoYXQg dGhpcyBvdmVybGF5IG5ldHdvcmsgZG9lc24ndCBkZXBlbmQgb24gY29uZmlnIG9yDQo+IChjb25m aWd1cmVkKSBhZGRyZXNzaW5nLCBhbmQgaXMgdGhlcmVmb3JlIG5vdCBhZmZlY3RlZCBieSBtYW55 IGNvbW1vbg0KPiBjb25maWcgb3Igcm91dGluZyBlcnJvcnMuDQo+ID4NCj4gPiBJdCBpcyBhIGNs YXNzaWNhbCBhdXRvbm9taWMgZnVuY3Rpb24sIGJlY2F1c2UgZXZlcnkgbm9kZSBtdXN0IGFjdA0K PiBpbmRlcGVuZGVudGx5IGZvciB0aGlzICJ2aXJ0dWFsIG91dCBvZiBiYW5kIiBjaGFubmVsIHRv IGNvbWUgdXAuIEEgZ29vZA0KPiBleGFtcGxlIGZvciBhIHNlbGYtbWFuYWdpbmcgZnVuY3Rpb24u DQo+ID4NCj4gPiBXZSdkIGxvdmUgdG8gZ2V0IGZlZWRiYWNrIG9uIHRoaXMgZHJhZnQuDQo+ID4g TWljaGFlbA0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206 IEktRC1Bbm5vdW5jZSBbbWFpbHRvOmktZC1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYNCj4gPj4gT2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+ID4+IFNlbnQ6IDIwIEp1 bmUgMjAxNCAxMTo1NQ0KPiA+PiBUbzogaS1kLWFubm91bmNlQGlldGYub3JnDQo+ID4+IFN1Ympl Y3Q6IEktRCBBY3Rpb246IGRyYWZ0LWJlaHJpbmdlci1hdXRvbm9taWMtY29udHJvbC1wbGFuZS0w MC50eHQNCj4gPj4NCj4gPj4NCj4gPj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxl IGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQo+ID4+IGRpcmVjdG9yaWVzLg0KPiA+ Pg0KPiA+Pg0KPiA+PiAgICAgICAgIFRpdGxlICAgICAgICAgICA6IEFuIEF1dG9ub21pYyBDb250 cm9sIFBsYW5lDQo+ID4+ICAgICAgICAgQXV0aG9ycyAgICAgICAgIDogTWljaGFlbCBILiBCZWhy aW5nZXINCj4gPj4gICAgICAgICAgICAgICAgICAgICAgICAgICBTdGVpbnRob3IgQmphcm5hc29u DQo+ID4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgQmFsYWppIEJMDQo+ID4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgVG9lcmxlc3MgRWNrZXJ0DQo+ID4+IAlGaWxlbmFtZSAgICAgICAg OiBkcmFmdC1iZWhyaW5nZXItYXV0b25vbWljLWNvbnRyb2wtcGxhbmUtMDAudHh0DQo+ID4+IAlQ YWdlcyAgICAgICAgICAgOiAxMA0KPiA+PiAJRGF0ZSAgICAgICAgICAgIDogMjAxNC0wNi0yMA0K PiA+Pg0KPiA+PiBBYnN0cmFjdDoNCj4gPj4gICAgSW4gY2VydGFpbiBzY2VuYXJpb3MsIGZvciBl eGFtcGxlIHdoZW4gYm9vdHN0cmFwcGluZyBhIG5ldHdvcmssIGl0IGlzDQo+ID4+ICAgIGRlc2ly YWJsZSB0byBhdXRvbWF0aWNhbGx5IGJyaW5nIHVwIGEgc2VjdXJlLCByb3V0ZWQgY29udHJvbCBw bGFuZSwNCj4gPj4gICAgd2hpY2ggaXMgaW5kZXBlbmRlbnQgb2YgZGV2aWNlIGNvbmZpZ3VyYXRp b25zIGFuZCBnbG9iYWwgcm91dGluZw0KPiA+PiAgICB0YWJsZS4gIFRoaXMgZG9jdW1lbnQgZGVz Y3JpYmVzIGFuIGFwcHJvYWNoIGZvciBhbiAiQXV0b25vbWljIENvbnRyb2wNCj4gPj4gICAgUGxh bmUiLCB3aGljaCBjYW4gYmUgdXNlZCBhcyBhICJ2aXJ0dWFsIG91dCBvZiBiYW5kIGNoYW5uZWwi IC0gYQ0KPiA+PiAgICBzZWxmLW1hbmFnaW5nIG92ZXJsYXkgbmV0d29yaywgd2hpY2ggaXMgaW5k ZXBlbmRlbnQgb2YgY29uZmlndXJhdGlvbiwNCj4gPj4gICAgYWRkcmVzc2luZyBhbmQgcm91dGlu ZyBvbiB0aGUgZGF0YSBwbGFuZS4NCj4gPj4NCj4gPj4NCj4gPj4gVGhlIElFVEYgZGF0YXRyYWNr ZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+ID4+IGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJlaHJpbmdlci1hdXRvbm9taWMtY29udHJvbC1wbA0KPiA+ PiBhbmUvDQo+ID4+DQo+ID4+IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxh YmxlIGF0Og0KPiA+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iZWhyaW5nZXIt YXV0b25vbWljLWNvbnRyb2wtcGxhbmUtMDANCj4gPj4NCj4gPj4NCj4gPj4gUGxlYXNlIG5vdGUg dGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4g Pj4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZh aWxhYmxlIGF0DQo+IHRvb2xzLmlldGYub3JnLg0KPiA+Pg0KPiA+PiBJbnRlcm5ldC1EcmFmdHMg YXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+ID4+IGZ0cDovL2Z0cC5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+ID4+DQo+ID4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IEktRC1Bbm5vdW5jZSBtYWlsaW5nIGxp c3QNCj4gPj4gSS1ELUFubm91bmNlQGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo+ID4+IEludGVybmV0LURyYWZ0IGRpcmVj dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sIG9yDQo+ID4+IGZ0cDovL2Z0 cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0DQo+ID4NCj4gPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IEFuaW1hIG1haWxpbmcgbGlz dA0KPiA+IEFuaW1hQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9hbmltYQ0KPiA+DQo= From nobody Mon Jun 23 01:08:51 2014 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 EF3D81B2890 for ; Mon, 23 Jun 2014 01:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 xW_ez3W9vSby for ; Mon, 23 Jun 2014 01:08: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 BA88A1B287E for ; Mon, 23 Jun 2014 01:08:43 -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 BJB05235; Mon, 23 Jun 2014 08:08:42 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 23 Jun 2014 09:08:41 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.249]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Mon, 23 Jun 2014 16:08:33 +0800 From: Sheng Jiang To: "Michael Behringer (mbehring)" Thread-Topic: [Anima] FW: I-D Action: draft-behringer-autonomic-control-plane-00.txt Thread-Index: AQHPjqesHV8eRTDXyEeGw6wx8sUweJt+Ts0w Date: Mon, 23 Jun 2014 08:08:32 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AEAB401@nkgeml512-mbx.china.huawei.com> References: <20140620095502.9324.99373.idtracker@ietfa.amsl.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BBAB34@xmb-rcd-x14.cisco.com> <53A48E1E.6040909@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BBC9DD@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BBC9DD@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.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/anima/PkjhxmpODFZiQUeP8DSShksR75A Cc: "anima@ietf.org" Subject: Re: [Anima] FW: I-D Action: draft-behringer-autonomic-control-plane-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: Mon, 23 Jun 2014 08:08:47 -0000 SGksIE1pY2hhZWwsDQoNCkFmdGVyIHJlYWQgdGhyb3VnaCB0aGlzIGRyYWZ0LCBJIGhhdmUgZnVs bHkgb2YgcXVlc3Rpb25zIGZvciB0aGUgc29sdXRpb24gZmVhc2liaWxpdHkuIFRoZXJlIGFyZSBh IGxvdCBvZiBkZXNpZ24gZGV0YWlscyBtaXNzaW5nLiBJIGJlbGlldmUgaXQgaXMgYmVjYXVzZSB5 b3Ugd2VyZSB0cnlpbmcgdG8gZGVzY3JpYmUgdGhlIHNvbHV0aW9uIGluIGEgdmVyeSBhYnN0cmFj dCB3YXkgaW4gb3JkZXIgdG8gZml0IGludG8gYW4gdXNlIGNhc2Ugc3R5bGUgZG9jdW1lbnQuDQoN ClRoZXJlZm9yZSwgSSB3b3VsZCBzdWdnZXN0IHlvdSB0byBzdWJtaXQgdHdvIHNlcGFyYXRlZCBk cmFmdHM6IGEgcHVyZSB1c2UgY2FzZSBkcmFmdCBmb3IgdGhpcyBhbmQgYW5vdGhlciBzb2x1dGlv biBkcmFmdCB3aXRoIGFuIG92ZXJhbGwgcGljdHVyZSBhbmQgbXVjaCBtb3JlIGRlc2lnbiBkZXRh aWxzLiBBcyB3ZSBhZ3JlZWQsIHdlIHNob3VsZCBub3Qgc3RvcCBpbiB1c2UgY2FzZXMgc3RhZ2Ug Zm9yIGxvbmcsIHNvIHlvdXIgcG90ZW50aWFsIHNvbHV0aW9uIGNvdWxkIGFsc28gYmUgZGlzY3Vz c2lvbiBvYmplY3RzLg0KDQpBIGNvdXBsZSBvZiBoaWdoLWxldmVsIGRlc2lnbiBxdWVzdGlvbnM6 IGF1dGhlbnRpY2F0aW9uIG9uIGEgbmV3IGRldmljZSBhbmQgZG9tYWluIGVzdGFibGlzaC4gSG93 IGEgbmV3IGRldmljZSB2YWxpZGF0ZSBpdHMgZGlzY292ZXJlZCBuZWlnaGJvciBpcyB0cnVzdGVk IGdpdmluZyB0aGF0IG9mZmxpbmUgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtIGFyZSB2ZXJ5IGV4 cGVuc2l2ZT8gSG93IGFuZCB3aG8gaXMgc2V0IHVwIHRoZSBkb21haW4gYm91bmRhcnkgb2YgdGhl IGF1dG9ub21pYyBuZXR3b3JrIGluIHRoZSBBQ1AgdXNlIGNhc2U/DQoNCkJlc3QgcmVnYXJkcywN Cg0KU2hlbmcNCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogQW5pbWEgW21h aWx0bzphbmltYS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWljaGFlbA0KPkJlaHJp bmdlciAobWJlaHJpbmcpDQo+U2VudDogTW9uZGF5LCBKdW5lIDIzLCAyMDE0IDE6NTUgUE0NCj5U bzogQnJpYW4gRSBDYXJwZW50ZXINCj5DYzogYW5pbWFAaWV0Zi5vcmcNCj5TdWJqZWN0OiBSZTog W0FuaW1hXSBGVzogSS1EIEFjdGlvbjoNCj5kcmFmdC1iZWhyaW5nZXItYXV0b25vbWljLWNvbnRy b2wtcGxhbmUtMDAudHh0DQo+DQo+V2VsbCwgeWVzLCBpdCBhbHNvIGRlc2NyaWJlcyB0aGUgc29s dXRpb24gKGZyYW5rbHksIGdpdmVuIHRoYXQgdGhpcyBpcyBjb21wbGV0ZWx5DQo+bmV3LCBJIHRo aW5rIHdlIG11c3QgZGVzY3JpYmUgaG93IGl0IHdvcmtzIGZvciBpdCB0byBiZSB1bmRlcnN0b29k Lg0KPg0KPkF0IHRoZSBzYW1lIHRpbWUsIGl0IGlzIGEgdXNlIGNhc2UsIGFuZCB0aGUgdGhyZWUg dXNlIGNhc2VzIGFyZSBkZXNjcmliZWQgaW4gdGhlDQo+ZG9jLiBUaGUgY29tbXVuaWNhdGlvbnMg aXMgYWxzbyBkZXNjcmliZWQuDQo+DQo+RXZlcnlib2R5LCBwbGVhc2UgaGF2ZSBhIGxvb2ssIGFu ZCBsZXQgbWUga25vdyB3aGV0aGVyIHdlIHNob3VsZA0KPjEpIHN1Ym1pdCBhIHB1cmUgdXNlIGNh c2UgZHJhZnQgZm9yIHRoaXMgKHdoaWNoIHdvdWxkIGJlIHF1aXRlIG92ZXJsYXBwaW5nIG9yDQo+ MikgYWRkIG1vcmUgb2YgdGhlIHRlbXBsYXRlIGluZm8gaW4gdGhpcyBkcmFmdCBvcg0KPjMpIHdo ZXRoZXIgaXQncyAiZ29vZCBlbm91Z2giIGZvciB0aGUgZGlzY3Vzc3Rpb24uDQo+DQo+TWljaGFl bA0KPg0KPg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IEJyaWFuIEUg Q2FycGVudGVyIFttYWlsdG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tXQ0KPj4gU2VudDog MjAgSnVuZSAyMDE0IDIxOjQwDQo+PiBUbzogTWljaGFlbCBCZWhyaW5nZXIgKG1iZWhyaW5nKQ0K Pj4gQ2M6IGFuaW1hQGlldGYub3JnDQo+PiBTdWJqZWN0OiBSZTogW0FuaW1hXSBGVzogSS1EIEFj dGlvbjogZHJhZnQtYmVocmluZ2VyLWF1dG9ub21pYy1jb250cm9sLQ0KPj4gcGxhbmUtMDAudHh0 DQo+Pg0KPj4gTWljaGFlbCwNCj4+DQo+PiBJJ3ZlIG9ubHkgaGFkIHRpbWUgZm9yIGEgcXVpY2sg Z2xhbmNlIHNvIGZhciAoaXQncyAwNzo0MCBTYXR1cmRheSBmb3IgbWUpIGJ1dA0KPj4gdGhpcyBz ZWVtcyBjbG9zZXIgdG8gc29sdXRpb24gc3BhY2UgdGhhbiB0byB1c2UgY2FzZXMuDQo+Pg0KPj4g TW9yZSB3aGVuIGl0IGdldHMgdG8gdGhlIHRvcCBvZiBteSByZWFkaW5nIGxpc3QuLi4NCj4+DQo+ PiBSZWdhcmRzDQo+PiAgICBCcmlhbg0KPj4NCj4+IE9uIDIxLzA2LzIwMTQgMDA6MTQsIE1pY2hh ZWwgQmVocmluZ2VyIChtYmVocmluZykgd3JvdGU6DQo+PiA+IFRoZSBkcmFmdCB3ZSBqdXN0IHBv c3RlZCBtYWtlcyBhbm90aGVyIGdvb2QgdXNlIGNhc2UgZm9yIGFuIGF1dG9ub21pYw0KPj4gZnVu Y3Rpb24sIGFuZCB3ZSdkIGxpa2UgdG8gc3VnZ2VzdCBpdCBmb3IgdGhlIGFnZW5kYSBvZiB0aGUg VUNBTiBCb0YuDQo+PiA+DQo+PiA+IEluIGEgbnV0c2hlbGw6IEV2ZXJ5IGF1dG9ub21pYyBub2Rl IGNyZWF0ZXMgYSBzZWN1cmUgY2hhbm5lbCB0byBhbGwgaXRzDQo+PiBuZWlnaGJvdXJzLCBiYXNl ZCBvbiBsaW5rIGxvY2FsIGFkZHJlc3NpbmcuIFRob3NlIGNoYW5uZWxzIGFyZSBrZXB0IGluIGEN Cj4+IGRpZmZlcmVudCBjb250ZXh0IChWUkYpLCBhbmQgdGh1cyBhdXRvbWF0aWNhbGx5IGNyZWF0 ZSBhbiBvdmVybGF5IG5ldHdvcmsuDQo+PiBUaGUgdGhpbmcgdG8gbm90ZSBpcyB0aGF0IHRoaXMg b3ZlcmxheSBuZXR3b3JrIGRvZXNuJ3QgZGVwZW5kIG9uIGNvbmZpZyBvcg0KPj4gKGNvbmZpZ3Vy ZWQpIGFkZHJlc3NpbmcsIGFuZCBpcyB0aGVyZWZvcmUgbm90IGFmZmVjdGVkIGJ5IG1hbnkgY29t bW9uDQo+PiBjb25maWcgb3Igcm91dGluZyBlcnJvcnMuDQo+PiA+DQo+PiA+IEl0IGlzIGEgY2xh c3NpY2FsIGF1dG9ub21pYyBmdW5jdGlvbiwgYmVjYXVzZSBldmVyeSBub2RlIG11c3QgYWN0DQo+ PiBpbmRlcGVuZGVudGx5IGZvciB0aGlzICJ2aXJ0dWFsIG91dCBvZiBiYW5kIiBjaGFubmVsIHRv IGNvbWUgdXAuIEEgZ29vZA0KPj4gZXhhbXBsZSBmb3IgYSBzZWxmLW1hbmFnaW5nIGZ1bmN0aW9u Lg0KPj4gPg0KPj4gPiBXZSdkIGxvdmUgdG8gZ2V0IGZlZWRiYWNrIG9uIHRoaXMgZHJhZnQuDQo+ PiA+IE1pY2hhZWwNCj4+ID4NCj4+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+ PiBGcm9tOiBJLUQtQW5ub3VuY2UgW21haWx0bzppLWQtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmDQo+PiA+PiBPZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCj4+ID4+IFNl bnQ6IDIwIEp1bmUgMjAxNCAxMTo1NQ0KPj4gPj4gVG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0K Pj4gPj4gU3ViamVjdDogSS1EIEFjdGlvbjogZHJhZnQtYmVocmluZ2VyLWF1dG9ub21pYy1jb250 cm9sLXBsYW5lLTAwLnR4dA0KPj4gPj4NCj4+ID4+DQo+PiA+PiBBIE5ldyBJbnRlcm5ldC1EcmFm dCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCj4+ID4+IGRp cmVjdG9yaWVzLg0KPj4gPj4NCj4+ID4+DQo+PiA+PiAgICAgICAgIFRpdGxlICAgICAgICAgICA6 IEFuIEF1dG9ub21pYyBDb250cm9sIFBsYW5lDQo+PiA+PiAgICAgICAgIEF1dGhvcnMgICAgICAg ICA6IE1pY2hhZWwgSC4gQmVocmluZ2VyDQo+PiA+PiAgICAgICAgICAgICAgICAgICAgICAgICAg IFN0ZWludGhvciBCamFybmFzb24NCj4+ID4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgQmFs YWppIEJMDQo+PiA+PiAgICAgICAgICAgICAgICAgICAgICAgICAgIFRvZXJsZXNzIEVja2VydA0K Pj4gPj4gCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWJlaHJpbmdlci1hdXRvbm9taWMtY29udHJv bC1wbGFuZS0wMC50eHQNCj4+ID4+IAlQYWdlcyAgICAgICAgICAgOiAxMA0KPj4gPj4gCURhdGUg ICAgICAgICAgICA6IDIwMTQtMDYtMjANCj4+ID4+DQo+PiA+PiBBYnN0cmFjdDoNCj4+ID4+ICAg IEluIGNlcnRhaW4gc2NlbmFyaW9zLCBmb3IgZXhhbXBsZSB3aGVuIGJvb3RzdHJhcHBpbmcgYSBu ZXR3b3JrLCBpdCBpcw0KPj4gPj4gICAgZGVzaXJhYmxlIHRvIGF1dG9tYXRpY2FsbHkgYnJpbmcg dXAgYSBzZWN1cmUsIHJvdXRlZCBjb250cm9sIHBsYW5lLA0KPj4gPj4gICAgd2hpY2ggaXMgaW5k ZXBlbmRlbnQgb2YgZGV2aWNlIGNvbmZpZ3VyYXRpb25zIGFuZCBnbG9iYWwgcm91dGluZw0KPj4g Pj4gICAgdGFibGUuICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhbiBhcHByb2FjaCBmb3IgYW4g IkF1dG9ub21pYw0KPkNvbnRyb2wNCj4+ID4+ICAgIFBsYW5lIiwgd2hpY2ggY2FuIGJlIHVzZWQg YXMgYSAidmlydHVhbCBvdXQgb2YgYmFuZCBjaGFubmVsIiAtIGENCj4+ID4+ICAgIHNlbGYtbWFu YWdpbmcgb3ZlcmxheSBuZXR3b3JrLCB3aGljaCBpcyBpbmRlcGVuZGVudCBvZg0KPmNvbmZpZ3Vy YXRpb24sDQo+PiA+PiAgICBhZGRyZXNzaW5nIGFuZCByb3V0aW5nIG9uIHRoZSBkYXRhIHBsYW5l Lg0KPj4gPj4NCj4+ID4+DQo+PiA+PiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBm b3IgdGhpcyBkcmFmdCBpczoNCj4+ID4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWJlaHJpbmdlci1hdXRvbm9taWMtY29udHJvbC1wbA0KPj4gPj4gYW5lLw0KPj4gPj4N Cj4+ID4+IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPj4g Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmVocmluZ2VyLWF1dG9ub21pYy1j b250cm9sLXBsYW5lLTAwDQo+PiA+Pg0KPj4gPj4NCj4+ID4+IFBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+PiA+PiBzdWJt aXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg YXQNCj4+IHRvb2xzLmlldGYub3JnLg0KPj4gPj4NCj4+ID4+IEludGVybmV0LURyYWZ0cyBhcmUg YWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4+ID4+IGZ0cDovL2Z0cC5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+PiA+Pg0KPj4gPj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+IEktRC1Bbm5vdW5jZSBtYWlsaW5nIGxp c3QNCj4+ID4+IEktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KPj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCj4+ID4+IEludGVybmV0LURyYWZ0IGRp cmVjdG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sIG9yDQo+PiA+PiBmdHA6 Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0KPj4gPg0KPj4gPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPiBBbmltYSBtYWls aW5nIGxpc3QNCj4+ID4gQW5pbWFAaWV0Zi5vcmcNCj4+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9hbmltYQ0KPj4gPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+QW5pbWEgbWFpbGluZyBsaXN0DQo+QW5pbWFAaWV0Zi5v cmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hDQo= From nobody Mon Jun 23 01:53:54 2014 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 D8CDB1B2A2D for ; Mon, 23 Jun 2014 01:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 xPwFTYxjtq5r for ; Mon, 23 Jun 2014 01:53:50 -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 9B9E11B2A46 for ; Mon, 23 Jun 2014 01:49:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11196; q=dns/txt; s=iport; t=1403513351; x=1404722951; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=veTYuhSz/5W8Cw+zVzBfjt4pzDY0QFqerqWs3yrRpgA=; b=i78qdtHLrcYF4adL20/slXT88vkW9SIdX7pe/F5zCTpeggxrq5Oaeb+4 dMjhR88/4wV/ySw+6rEGLYKMjvYeVJRl8XpQfHMqMuUIYueFFNpAruICB QdeYKD5Fe7/bmi/Wz8/SurdPmGNeuQG1js4qlCPA6w+1n7ETaTxtF9ryi E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwHAObop1OtJA2H/2dsb2JhbABZgw1SWoJtpxM3AQEBAQEBBQGRdYdAARlxFnWEAwEBAQQBAQEgEToGBQwEAgEIEQQBAQECAgYdAwICAh8GCxQBBwEIAgQOBQgBEogTAxENqE6Wfg2GSxeBKoQ5hnSBdBYbBwaCcTaBFgSWO4IXgz+MGAOGA4NCbIEEJBw X-IronPort-AV: E=Sophos;i="5.01,528,1400025600"; d="scan'208";a="55173391" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-2.cisco.com with ESMTP; 23 Jun 2014 08:49:05 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s5N8n5qC006284 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Jun 2014 08:49:05 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Mon, 23 Jun 2014 03:49:05 -0500 From: "Michael Behringer (mbehring)" To: Sheng Jiang Thread-Topic: [Anima] FW: I-D Action: draft-behringer-autonomic-control-plane-00.txt Thread-Index: AQHPjrpdtKG3vBvmiUqtKH5MW6fI6Jt+W0+g Date: Mon, 23 Jun 2014 08:49:04 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BBCEDE@xmb-rcd-x14.cisco.com> References: <20140620095502.9324.99373.idtracker@ietfa.amsl.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BBAB34@xmb-rcd-x14.cisco.com> <53A48E1E.6040909@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BBC9DD@xmb-rcd-x14.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AEAB401@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AEAB401@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.137] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/anima/GLeDt4a0QPToInMgxjdPKg0N-2M Cc: "anima@ietf.org" Subject: Re: [Anima] FW: I-D Action: draft-behringer-autonomic-control-plane-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: Mon, 23 Jun 2014 08:53:53 -0000 SGkgU2hlbmcsIA0KDQpUbyB5b3VyIHF1ZXN0aW9uczogRXNzZW50aWFsbHkgd2UgaGF2ZSB0d28g Yml0czogDQoNCi0gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcHJpdGlraW4tYm9v dHN0cmFwcGluZy1rZXlpbmZyYXN0cnVjdHVyZXMgZGVzY3JpYmVzIGhvdyBkZXZpY2VzIGluIGEg ZG9tYWluIGdldCBhIGRvbWFpbiBjZXJ0aWZpY2F0ZSwgc2VjdXJlbHksIGFuZCB6ZXJvLXRvdWNo LiBUaG9zZSBkb21haW4gY2VydGlmaWNhdGVzIGFyZSBub3cgdXNlZCBmb3IgZGV2aWNlcyB0byBh dXRoZW50aWNhdGUgZWFjaCBvdGhlci4gQW5kIA0KLSBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1iZWhyaW5nZXItYXV0b25vbWljLWNvbnRyb2wtcGxhbmUtMDAgdXNlcyB0aGUgZG9t YWluIGNlcnRpZmljYXRlcyB0byBzZWN1cmUgaXRzIGludGVyYWN0aW9ucywgYW5kIHRvIGZvcm0g dGhlIGF1dG9ub21pYyBjb250cm9sIHBsYW5lLiBTZWN0aW9uIDMuMSB0cmllcyB0byBleHBsYWlu IHRoYXQgd2UgbmVlZCB0aGUgYWJvdmUgZHJhZnQgZm9yIHRoaXMgb25lLiANCg0KVGhlIG9ubHkg Y2VudHJhbGlzZWQgYml0IGluIHRoZSBzb2x1dGlvbiBpcyBhICJyZWdpc3RyYXIiIGNvbXBvbmVu dCwgd2hpY2ggY2hlY2tzIHRoYXQgZGV2aWNlcyBhcmUgaW5kZWVkIHBhcnQgb2YgdGhlIGRvbWFp biAoYmFzZWQgb24gc2VyaWFsIG51bWJlciBvciB2ZW5kb3IgY2VydGlmaWNhdGUpLCBhbmQgaGFu ZHMgb3V0IHRoZSBkb21haW4gY2VydGlmaWNhdGVzLiBTbyB0aGlzIGlzIGEgdHJ1bHkgYXV0b25v bWljIHNvbHV0aW9uIC0gYXMgZGlzdHJpYnV0ZWQgYXMgcG9zc2libGUuIA0KDQpOb3csIEkgYWdy ZWUsIHRoaXMgZHJhZnQgaXNuJ3Qgd3JpdHRlbiB3aXRoIHRoZSB1c2UgY2FzZSB0ZW1wbGF0ZSAo c29ycnkgd2UgaGFkIHN0YXJ0ZWQgdGhpcyBvbmUgYSBsb25nIHRpbWUgYWdvKS4gV2UgY2FuIG9m IGNvdXJzZSBkbyBhIHNlcGFyYXRlIHVzZSBjYXNlIGRyYWZ0LCBidXQgZnJhbmtseSwgSSdkIHBy ZWZlciBpZiB3ZSBjYW4ga2VlcCB0aGUgaW5mbyBpbiBvbmUgcGxhY2UuIA0KDQpGcm9tIHRoZSB1 c2UgY2FzZSB0ZW1wbGF0ZSwgd2UgYWxyZWFkeSBoYXZlIGluIHRoZSBBQ1AgZHJhZnQ6IA0KLSBp bnRybw0KLSBwcm9ibGVtIHN0YXRlbWVudA0KLSBiZW5lZml0cyAodGhpcyBpcyBpbiBzZWN0aW9u IDYgInVzZSBjYXNlcyBmb3IgdGhlIEFDUCIpDQotIHVzZXIgZXhwZXJpZW5jZSAoc2VjdGlvbiA3 KQ0KLSBUaGUgIkFuYWx5c2lzIG9mIFBhcmFtZXRlcnMgYW5kIEluZm9ybWF0aW9uIEludm9sdmVk IiBpcyBjb250YWluZWQgaW4gc2VjdGlvbiAzLiANCg0KVGhlcmUgaXMgbWlzc2luZzogDQotIGNv bXBhcmlzb24gd2l0aCBjdXJyZW50IHNvbHV0aW9uczogQnV0IEkgY2xhaW0gdGhlcmUgaXMgcmVh bGx5IG5vdGhpbmcgY29tcGFyYWJsZSB0b2RheSwgc28gdGhpcyBzZWN0aW9uIGRvZXNuJ3QgbWFr ZSB0b28gbXVjaCBzZW5zZS4gDQoNClNvIEknZCBhcmd1ZSB3aGlsZSB0aGUgdGVtcGxhdGUgaXNu J3Qgc3RyaWN0bHkgZm9sbG93ZWQsIHRoZSBjb250ZW50IGlzIHRoZXJlLiANCg0KQnV0IGlmIHlv dSBmZWVsIHN0cm9uZ2x5IHRoYXQgd2Ugc2hvdWxkIGFsc28gaGF2ZSBhIHNlcGFyYXRlIHVzZSBj YXNlIGRyYWZ0LCBJJ20gaGFwcHkgdG8gcHJvZHVjZSBvbmUuIFdvdWxkIGxpa2UgdG8gYXZvaWQg c3BlbmRpbmcgdGhlIGN5Y2xlcyB0aG91Z2ggdW5sZXNzIHJlYWxseSBuZWVkZWQuIDotKSAgUGxl YXNlIGxldCB1cyBrbm93IQ0KDQpNaWNoYWVsDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBTaGVuZyBKaWFuZyBbbWFpbHRvOmppYW5nc2hlbmdAaHVhd2VpLmNvbV0N Cj4gU2VudDogMjMgSnVuZSAyMDE0IDEwOjA5DQo+IFRvOiBNaWNoYWVsIEJlaHJpbmdlciAobWJl aHJpbmcpDQo+IENjOiBhbmltYUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogW0FuaW1hXSBGVzog SS1EIEFjdGlvbjogZHJhZnQtYmVocmluZ2VyLWF1dG9ub21pYy1jb250cm9sLQ0KPiBwbGFuZS0w MC50eHQNCj4gDQo+IEhpLCBNaWNoYWVsLA0KPiANCj4gQWZ0ZXIgcmVhZCB0aHJvdWdoIHRoaXMg ZHJhZnQsIEkgaGF2ZSBmdWxseSBvZiBxdWVzdGlvbnMgZm9yIHRoZSBzb2x1dGlvbg0KPiBmZWFz aWJpbGl0eS4gVGhlcmUgYXJlIGEgbG90IG9mIGRlc2lnbiBkZXRhaWxzIG1pc3NpbmcuIEkgYmVs aWV2ZSBpdCBpcyBiZWNhdXNlDQo+IHlvdSB3ZXJlIHRyeWluZyB0byBkZXNjcmliZSB0aGUgc29s dXRpb24gaW4gYSB2ZXJ5IGFic3RyYWN0IHdheSBpbiBvcmRlciB0byBmaXQNCj4gaW50byBhbiB1 c2UgY2FzZSBzdHlsZSBkb2N1bWVudC4NCj4gDQo+IFRoZXJlZm9yZSwgSSB3b3VsZCBzdWdnZXN0 IHlvdSB0byBzdWJtaXQgdHdvIHNlcGFyYXRlZCBkcmFmdHM6IGEgcHVyZSB1c2UNCj4gY2FzZSBk cmFmdCBmb3IgdGhpcyBhbmQgYW5vdGhlciBzb2x1dGlvbiBkcmFmdCB3aXRoIGFuIG92ZXJhbGwg cGljdHVyZSBhbmQNCj4gbXVjaCBtb3JlIGRlc2lnbiBkZXRhaWxzLiBBcyB3ZSBhZ3JlZWQsIHdl IHNob3VsZCBub3Qgc3RvcCBpbiB1c2UgY2FzZXMNCj4gc3RhZ2UgZm9yIGxvbmcsIHNvIHlvdXIg cG90ZW50aWFsIHNvbHV0aW9uIGNvdWxkIGFsc28gYmUgZGlzY3Vzc2lvbiBvYmplY3RzLg0KPiAN Cj4gQSBjb3VwbGUgb2YgaGlnaC1sZXZlbCBkZXNpZ24gcXVlc3Rpb25zOiBhdXRoZW50aWNhdGlv biBvbiBhIG5ldyBkZXZpY2UNCj4gYW5kIGRvbWFpbiBlc3RhYmxpc2guIEhvdyBhIG5ldyBkZXZp Y2UgdmFsaWRhdGUgaXRzIGRpc2NvdmVyZWQgbmVpZ2hib3IgaXMNCj4gdHJ1c3RlZCBnaXZpbmcg dGhhdCBvZmZsaW5lIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSBhcmUgdmVyeSBleHBlbnNpdmU/ DQo+IEhvdyBhbmQgd2hvIGlzIHNldCB1cCB0aGUgZG9tYWluIGJvdW5kYXJ5IG9mIHRoZSBhdXRv bm9taWMgbmV0d29yayBpbg0KPiB0aGUgQUNQIHVzZSBjYXNlPw0KPiANCj4gQmVzdCByZWdhcmRz LA0KPiANCj4gU2hlbmcNCj4gDQo+ID4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+RnJv bTogQW5pbWEgW21haWx0bzphbmltYS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWlj aGFlbA0KPiA+QmVocmluZ2VyIChtYmVocmluZykNCj4gPlNlbnQ6IE1vbmRheSwgSnVuZSAyMywg MjAxNCAxOjU1IFBNDQo+ID5UbzogQnJpYW4gRSBDYXJwZW50ZXINCj4gPkNjOiBhbmltYUBpZXRm Lm9yZw0KPiA+U3ViamVjdDogUmU6IFtBbmltYV0gRlc6IEktRCBBY3Rpb246DQo+ID5kcmFmdC1i ZWhyaW5nZXItYXV0b25vbWljLWNvbnRyb2wtcGxhbmUtMDAudHh0DQo+ID4NCj4gPldlbGwsIHll cywgaXQgYWxzbyBkZXNjcmliZXMgdGhlIHNvbHV0aW9uIChmcmFua2x5LCBnaXZlbiB0aGF0IHRo aXMgaXMNCj4gPmNvbXBsZXRlbHkgbmV3LCBJIHRoaW5rIHdlIG11c3QgZGVzY3JpYmUgaG93IGl0 IHdvcmtzIGZvciBpdCB0byBiZQ0KPiB1bmRlcnN0b29kLg0KPiA+DQo+ID5BdCB0aGUgc2FtZSB0 aW1lLCBpdCBpcyBhIHVzZSBjYXNlLCBhbmQgdGhlIHRocmVlIHVzZSBjYXNlcyBhcmUNCj4gPmRl c2NyaWJlZCBpbiB0aGUgZG9jLiBUaGUgY29tbXVuaWNhdGlvbnMgaXMgYWxzbyBkZXNjcmliZWQu DQo+ID4NCj4gPkV2ZXJ5Ym9keSwgcGxlYXNlIGhhdmUgYSBsb29rLCBhbmQgbGV0IG1lIGtub3cg d2hldGhlciB3ZSBzaG91bGQNCj4gPjEpIHN1Ym1pdCBhIHB1cmUgdXNlIGNhc2UgZHJhZnQgZm9y IHRoaXMgKHdoaWNoIHdvdWxkIGJlIHF1aXRlDQo+ID5vdmVybGFwcGluZyBvcg0KPiA+MikgYWRk IG1vcmUgb2YgdGhlIHRlbXBsYXRlIGluZm8gaW4gdGhpcyBkcmFmdCBvcg0KPiA+Mykgd2hldGhl ciBpdCdzICJnb29kIGVub3VnaCIgZm9yIHRoZSBkaXNjdXNzdGlvbi4NCj4gPg0KPiA+TWljaGFl bA0KPiA+DQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTog QnJpYW4gRSBDYXJwZW50ZXIgW21haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb21dDQo+ ID4+IFNlbnQ6IDIwIEp1bmUgMjAxNCAyMTo0MA0KPiA+PiBUbzogTWljaGFlbCBCZWhyaW5nZXIg KG1iZWhyaW5nKQ0KPiA+PiBDYzogYW5pbWFAaWV0Zi5vcmcNCj4gPj4gU3ViamVjdDogUmU6IFtB bmltYV0gRlc6IEktRCBBY3Rpb246DQo+ID4+IGRyYWZ0LWJlaHJpbmdlci1hdXRvbm9taWMtY29u dHJvbC0NCj4gPj4gcGxhbmUtMDAudHh0DQo+ID4+DQo+ID4+IE1pY2hhZWwsDQo+ID4+DQo+ID4+ IEkndmUgb25seSBoYWQgdGltZSBmb3IgYSBxdWljayBnbGFuY2Ugc28gZmFyIChpdCdzIDA3OjQw IFNhdHVyZGF5IGZvcg0KPiA+PiBtZSkgYnV0IHRoaXMgc2VlbXMgY2xvc2VyIHRvIHNvbHV0aW9u IHNwYWNlIHRoYW4gdG8gdXNlIGNhc2VzLg0KPiA+Pg0KPiA+PiBNb3JlIHdoZW4gaXQgZ2V0cyB0 byB0aGUgdG9wIG9mIG15IHJlYWRpbmcgbGlzdC4uLg0KPiA+Pg0KPiA+PiBSZWdhcmRzDQo+ID4+ ICAgIEJyaWFuDQo+ID4+DQo+ID4+IE9uIDIxLzA2LzIwMTQgMDA6MTQsIE1pY2hhZWwgQmVocmlu Z2VyIChtYmVocmluZykgd3JvdGU6DQo+ID4+ID4gVGhlIGRyYWZ0IHdlIGp1c3QgcG9zdGVkIG1h a2VzIGFub3RoZXIgZ29vZCB1c2UgY2FzZSBmb3IgYW4NCj4gPj4gPiBhdXRvbm9taWMNCj4gPj4g ZnVuY3Rpb24sIGFuZCB3ZSdkIGxpa2UgdG8gc3VnZ2VzdCBpdCBmb3IgdGhlIGFnZW5kYSBvZiB0 aGUgVUNBTiBCb0YuDQo+ID4+ID4NCj4gPj4gPiBJbiBhIG51dHNoZWxsOiBFdmVyeSBhdXRvbm9t aWMgbm9kZSBjcmVhdGVzIGEgc2VjdXJlIGNoYW5uZWwgdG8gYWxsDQo+ID4+ID4gaXRzDQo+ID4+ IG5laWdoYm91cnMsIGJhc2VkIG9uIGxpbmsgbG9jYWwgYWRkcmVzc2luZy4gVGhvc2UgY2hhbm5l bHMgYXJlIGtlcHQNCj4gPj4gaW4gYSBkaWZmZXJlbnQgY29udGV4dCAoVlJGKSwgYW5kIHRodXMg YXV0b21hdGljYWxseSBjcmVhdGUgYW4gb3ZlcmxheQ0KPiBuZXR3b3JrLg0KPiA+PiBUaGUgdGhp bmcgdG8gbm90ZSBpcyB0aGF0IHRoaXMgb3ZlcmxheSBuZXR3b3JrIGRvZXNuJ3QgZGVwZW5kIG9u DQo+ID4+IGNvbmZpZyBvcg0KPiA+PiAoY29uZmlndXJlZCkgYWRkcmVzc2luZywgYW5kIGlzIHRo ZXJlZm9yZSBub3QgYWZmZWN0ZWQgYnkgbWFueSBjb21tb24NCj4gPj4gY29uZmlnIG9yIHJvdXRp bmcgZXJyb3JzLg0KPiA+PiA+DQo+ID4+ID4gSXQgaXMgYSBjbGFzc2ljYWwgYXV0b25vbWljIGZ1 bmN0aW9uLCBiZWNhdXNlIGV2ZXJ5IG5vZGUgbXVzdCBhY3QNCj4gPj4gaW5kZXBlbmRlbnRseSBm b3IgdGhpcyAidmlydHVhbCBvdXQgb2YgYmFuZCIgY2hhbm5lbCB0byBjb21lIHVwLiBBDQo+ID4+ IGdvb2QgZXhhbXBsZSBmb3IgYSBzZWxmLW1hbmFnaW5nIGZ1bmN0aW9uLg0KPiA+PiA+DQo+ID4+ ID4gV2UnZCBsb3ZlIHRvIGdldCBmZWVkYmFjayBvbiB0aGlzIGRyYWZ0Lg0KPiA+PiA+IE1pY2hh ZWwNCj4gPj4gPg0KPiA+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiA+PiBG cm9tOiBJLUQtQW5ub3VuY2UgW21haWx0bzppLWQtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZ10g T24NCj4gPj4gPj4gQmVoYWxmIE9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KPiA+PiA+PiBT ZW50OiAyMCBKdW5lIDIwMTQgMTE6NTUNCj4gPj4gPj4gVG86IGktZC1hbm5vdW5jZUBpZXRmLm9y Zw0KPiA+PiA+PiBTdWJqZWN0OiBJLUQgQWN0aW9uOg0KPiA+PiA+PiBkcmFmdC1iZWhyaW5nZXIt YXV0b25vbWljLWNvbnRyb2wtcGxhbmUtMDAudHh0DQo+ID4+ID4+DQo+ID4+ID4+DQo+ID4+ID4+ IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVy bmV0LURyYWZ0cw0KPiA+PiA+PiBkaXJlY3Rvcmllcy4NCj4gPj4gPj4NCj4gPj4gPj4NCj4gPj4g Pj4gICAgICAgICBUaXRsZSAgICAgICAgICAgOiBBbiBBdXRvbm9taWMgQ29udHJvbCBQbGFuZQ0K PiA+PiA+PiAgICAgICAgIEF1dGhvcnMgICAgICAgICA6IE1pY2hhZWwgSC4gQmVocmluZ2VyDQo+ ID4+ID4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgU3RlaW50aG9yIEJqYXJuYXNvbg0KPiA+ PiA+PiAgICAgICAgICAgICAgICAgICAgICAgICAgIEJhbGFqaSBCTA0KPiA+PiA+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgIFRvZXJsZXNzIEVja2VydA0KPiA+PiA+PiAJRmlsZW5hbWUgICAg ICAgIDogZHJhZnQtYmVocmluZ2VyLWF1dG9ub21pYy1jb250cm9sLXBsYW5lLTAwLnR4dA0KPiA+ PiA+PiAJUGFnZXMgICAgICAgICAgIDogMTANCj4gPj4gPj4gCURhdGUgICAgICAgICAgICA6IDIw MTQtMDYtMjANCj4gPj4gPj4NCj4gPj4gPj4gQWJzdHJhY3Q6DQo+ID4+ID4+ICAgIEluIGNlcnRh aW4gc2NlbmFyaW9zLCBmb3IgZXhhbXBsZSB3aGVuIGJvb3RzdHJhcHBpbmcgYSBuZXR3b3JrLCBp dCBpcw0KPiA+PiA+PiAgICBkZXNpcmFibGUgdG8gYXV0b21hdGljYWxseSBicmluZyB1cCBhIHNl Y3VyZSwgcm91dGVkIGNvbnRyb2wgcGxhbmUsDQo+ID4+ID4+ICAgIHdoaWNoIGlzIGluZGVwZW5k ZW50IG9mIGRldmljZSBjb25maWd1cmF0aW9ucyBhbmQgZ2xvYmFsIHJvdXRpbmcNCj4gPj4gPj4g ICAgdGFibGUuICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhbiBhcHByb2FjaCBmb3IgYW4gIkF1 dG9ub21pYw0KPiA+Q29udHJvbA0KPiA+PiA+PiAgICBQbGFuZSIsIHdoaWNoIGNhbiBiZSB1c2Vk IGFzIGEgInZpcnR1YWwgb3V0IG9mIGJhbmQgY2hhbm5lbCIgLSBhDQo+ID4+ID4+ICAgIHNlbGYt bWFuYWdpbmcgb3ZlcmxheSBuZXR3b3JrLCB3aGljaCBpcyBpbmRlcGVuZGVudCBvZg0KPiA+Y29u ZmlndXJhdGlvbiwNCj4gPj4gPj4gICAgYWRkcmVzc2luZyBhbmQgcm91dGluZyBvbiB0aGUgZGF0 YSBwbGFuZS4NCj4gPj4gPj4NCj4gPj4gPj4NCj4gPj4gPj4gVGhlIElFVEYgZGF0YXRyYWNrZXIg c3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+ID4+ID4+IGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJlaHJpbmdlci1hdXRvbm9taWMtY29udHJvbA0KPiA+PiA+ PiAtcGwNCj4gPj4gPj4gYW5lLw0KPiA+PiA+Pg0KPiA+PiA+PiBUaGVyZSdzIGFsc28gYSBodG1s aXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4gPj4gPj4gaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtYmVocmluZ2VyLWF1dG9ub21pYy1jb250cm9sLXBsYW5lDQo+ID4+ID4+IC0w MA0KPiA+PiA+Pg0KPiA+PiA+Pg0KPiA+PiA+PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtl IGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPiA+PiA+PiBzdWJtaXNzaW9u IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQNCj4g Pj4gdG9vbHMuaWV0Zi5vcmcuDQo+ID4+ID4+DQo+ID4+ID4+IEludGVybmV0LURyYWZ0cyBhcmUg YWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gPj4gPj4gZnRwOi8vZnRwLmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4gPj4gPj4NCj4gPj4gPj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gPj4gSS1ELUFubm91bmNlIG1h aWxpbmcgbGlzdA0KPiA+PiA+PiBJLUQtQW5ub3VuY2VAaWV0Zi5vcmcNCj4gPj4gPj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCj4gPj4gPj4gSW50 ZXJuZXQtRHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwg b3INCj4gPj4gPj4gZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQNCj4g Pj4gPg0KPiA+PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4+ID4gQW5pbWEgbWFpbGluZyBsaXN0DQo+ID4+ID4gQW5pbWFAaWV0Zi5vcmcNCj4g Pj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hDQo+ID4+ID4N Cj4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID5B bmltYSBtYWlsaW5nIGxpc3QNCj4gPkFuaW1hQGlldGYub3JnDQo+ID5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hDQo= From nobody Mon Jun 23 04:06:06 2014 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 2B9291B2A92 for ; Mon, 23 Jun 2014 04:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 X2VVyzrozk9R for ; Mon, 23 Jun 2014 04:06:04 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87C0A1B290F for ; Mon, 23 Jun 2014 04:05:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=191; q=dns/txt; s=iport; t=1403521539; x=1404731139; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=x2Sh4Z05vedF1nNsgycCJD34ESIyka8DZ7Tf+LbNN18=; b=CqTWUc2iPlcpqQqWZVahXaqIKhsWUovMC1E4CRI88tBZcjq44MEYUe+g LwiJiNUHGvroKDUPcWeDp7GPvto5+2g6n34v1ZyffgOvjFvVDkqRHgOzI MpadcnUAGS3d01rvid8v9n2bi4PE8PBzThKUTdIBrcWEu9P1NtzvghpSQ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvkEAKgJqFOtJssW/2dsb2JhbABZkUqdKAEBAQEBAQUBmlV1hEJAPRYYAwIBAgFYCAEBiD6YbKx/F4VjiTaELQEDmkyGfYxmg0Q7 X-IronPort-AV: E=Sophos;i="5.01,529,1400025600"; d="scan'208";a="95599760" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 23 Jun 2014 11:05:36 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s5NB5aKx026674 for ; Mon, 23 Jun 2014 11:05:36 GMT Message-ID: <53A80A00.2000905@cisco.com> Date: Mon, 23 Jun 2014 13:05:36 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: anima@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/kRXNkpDVJFLBazCKCxw4NcEfrqo Subject: [Anima] Ucan BoF chairs 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, 23 Jun 2014 11:06:05 -0000 Dear all, As responsible AD, I selected Brian Carpenter and Michael Behringer as BoF chairs. Background info: For a successful BoF, we should all review RFC 5434. Regards, Benoit From nobody Mon Jun 23 10:32:59 2014 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 8DE071B2B6E for ; Mon, 23 Jun 2014 10:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 bmJnOuBaOuJ2 for ; Mon, 23 Jun 2014 10:32:56 -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 ECAF61B2B99 for ; Mon, 23 Jun 2014 10:32:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5729; q=dns/txt; s=iport; t=1403544775; x=1404754375; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=gSZ4o0wH9uFZikv3aIL78ZhNdHoqygvGtA8uxsafzf0=; b=FN8nSiHiDDgJP370NXPjPuJQEK7iUnSSrEWnvlA+/k3asUwGtUcWZh13 VctWb+F+zF8pEpEGdGncbkvopxt5u5/QxxU9pZWZyhHlnpTcYh7S23Ns6 t9JWl55WPLgfL/7Vj9KZY7RD186IIv+61CKi7D5D+FM4omADP50BFaJcM Y=; X-IronPort-AV: E=Sophos;i="5.01,531,1400025600"; d="scan'208";a="335098222" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 23 Jun 2014 17:32:54 +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 s5NHWr7P021289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jun 2014 17:32:54 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 s5NHWoag027273; Mon, 23 Jun 2014 10:32:50 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id s5NHWoZL027272; Mon, 23 Jun 2014 10:32:50 -0700 Date: Mon, 23 Jun 2014 10:32:50 -0700 From: Toerless Eckert To: Sheng Jiang Message-ID: <20140623173250.GU11315@cisco.com> References: <20140620095502.9324.99373.idtracker@ietfa.amsl.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BBAB34@xmb-rcd-x14.cisco.com> <53A48E1E.6040909@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BBC9DD@xmb-rcd-x14.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AEAB401@nkgeml512-mbx.china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AEAB401@nkgeml512-mbx.china.huawei.com> User-Agent: Mutt/1.4.2.2i Archived-At: http://mailarchive.ietf.org/arch/msg/anima/nKat78xPaZOAgg5eHWbgEztNDcE Cc: "anima@ietf.org" , "Michael Behringer \(mbehring\)" Subject: Re: [Anima] FW: I-D Action: draft-behringer-autonomic-control-plane-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: Mon, 23 Jun 2014 17:32:58 -0000 Just trying to catch up with the anima process - do we have a list of candidate draft - obviously i primarily have no track of the non-cisco drafts. Wanted to check what the set of use-case drafts is. Any wiki for anima listing drafts ? Thanks Toerless On Mon, Jun 23, 2014 at 08:08:32AM +0000, Sheng Jiang wrote: > Hi, Michael, > > After read through this draft, I have fully of questions for the solution feasibility. There are a lot of design details missing. I believe it is because you were trying to describe the solution in a very abstract way in order to fit into an use case style document. > > Therefore, I would suggest you to submit two separated drafts: a pure use case draft for this and another solution draft with an overall picture and much more design details. As we agreed, we should not stop in use cases stage for long, so your potential solution could also be discussion objects. > > A couple of high-level design questions: authentication on a new device and domain establish. How a new device validate its discovered neighbor is trusted giving that offline authentication mechanism are very expensive? How and who is set up the domain boundary of the autonomic network in the ACP use case? > > Best regards, > > Sheng > > >-----Original Message----- > >From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael > >Behringer (mbehring) > >Sent: Monday, June 23, 2014 1:55 PM > >To: Brian E Carpenter > >Cc: anima@ietf.org > >Subject: Re: [Anima] FW: I-D Action: > >draft-behringer-autonomic-control-plane-00.txt > > > >Well, yes, it also describes the solution (frankly, given that this is completely > >new, I think we must describe how it works for it to be understood. > > > >At the same time, it is a use case, and the three use cases are described in the > >doc. The communications is also described. > > > >Everybody, please have a look, and let me know whether we should > >1) submit a pure use case draft for this (which would be quite overlapping or > >2) add more of the template info in this draft or > >3) whether it's "good enough" for the discusstion. > > > >Michael > > > > > >> -----Original Message----- > >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > >> Sent: 20 June 2014 21:40 > >> To: Michael Behringer (mbehring) > >> Cc: anima@ietf.org > >> Subject: Re: [Anima] FW: I-D Action: draft-behringer-autonomic-control- > >> plane-00.txt > >> > >> Michael, > >> > >> I've only had time for a quick glance so far (it's 07:40 Saturday for me) but > >> this seems closer to solution space than to use cases. > >> > >> More when it gets to the top of my reading list... > >> > >> Regards > >> Brian > >> > >> On 21/06/2014 00:14, Michael Behringer (mbehring) wrote: > >> > The draft we just posted makes another good use case for an autonomic > >> function, and we'd like to suggest it for the agenda of the UCAN BoF. > >> > > >> > In a nutshell: Every autonomic node creates a secure channel to all its > >> neighbours, based on link local addressing. Those channels are kept in a > >> different context (VRF), and thus automatically create an overlay network. > >> The thing to note is that this overlay network doesn't depend on config or > >> (configured) addressing, and is therefore not affected by many common > >> config or routing errors. > >> > > >> > It is a classical autonomic function, because every node must act > >> independently for this "virtual out of band" channel to come up. A good > >> example for a self-managing function. > >> > > >> > We'd love to get feedback on this draft. > >> > Michael > >> > > >> >> -----Original Message----- > >> >> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf > >> >> Of internet-drafts@ietf.org > >> >> Sent: 20 June 2014 11:55 > >> >> To: i-d-announce@ietf.org > >> >> Subject: I-D Action: draft-behringer-autonomic-control-plane-00.txt > >> >> > >> >> > >> >> A New Internet-Draft is available from the on-line Internet-Drafts > >> >> directories. > >> >> > >> >> > >> >> Title : An Autonomic Control Plane > >> >> Authors : Michael H. Behringer > >> >> Steinthor Bjarnason > >> >> Balaji BL > >> >> Toerless Eckert > >> >> Filename : draft-behringer-autonomic-control-plane-00.txt > >> >> Pages : 10 > >> >> Date : 2014-06-20 > >> >> > >> >> Abstract: > >> >> In certain scenarios, for example when bootstrapping a network, it is > >> >> desirable to automatically bring up a secure, routed control plane, > >> >> which is independent of device configurations and global routing > >> >> table. This document describes an approach for an "Autonomic > >Control > >> >> Plane", which can be used as a "virtual out of band channel" - a > >> >> self-managing overlay network, which is independent of > >configuration, > >> >> addressing and routing on the data plane. > >> >> > >> >> > >> >> The IETF datatracker status page for this draft is: > >> >> https://datatracker.ietf.org/doc/draft-behringer-autonomic-control-pl > >> >> ane/ > >> >> > >> >> There's also a htmlized version available at: > >> >> http://tools.ietf.org/html/draft-behringer-autonomic-control-plane-00 > >> >> > >> >> > >> >> Please note that it may take a couple of minutes from the time of > >> >> submission until the htmlized version and diff are available at > >> tools.ietf.org. > >> >> > >> >> Internet-Drafts are also available by anonymous FTP at: > >> >> ftp://ftp.ietf.org/internet-drafts/ > >> >> From nobody Mon Jun 23 13:22:31 2014 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 9D1821B2AFE for ; Mon, 23 Jun 2014 13:22:28 -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 0wdYMBtDyJJI for ; Mon, 23 Jun 2014 13:22:25 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC48A1B2C20 for ; Mon, 23 Jun 2014 13:22:25 -0700 (PDT) Received: by mail-pa0-f49.google.com with SMTP id lj1so6260728pab.36 for ; Mon, 23 Jun 2014 13:22:25 -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=shXhfWNQQJ1qe5MrMYwOr2P9VzOqynwQNK5kkYgqa58=; b=Pepuik9WnNUU3MWiVT7aFw2ysDH2gCGN4/esY6t+0dD4dxyYnBO7GtxvToc+/9Sxhw HCuu4mD9MrCFziW+43dMGCAVdyQm/m/e6aj9dFc7rKgVJNkoOWb8V96bIGNBdDKeotG3 rsdTOpBQwxaSxjVgGhsviIXglC6fGFsEtAiSiQWLxtJ0Qj2JEBU9+RfJQH+p6rGkmiTS WpbvYNCYjBbd2HWYh6h/YRnd1u7riqh0h4br3QZMAwsKFjabmi8LtkYz1viqdjLNJ6W+ V6iDkN6fAa/s8xnp1Z8qog4+2Ud2IPh/D7Tq3sKGVVf+dz6sY/KhiOCucEjvZbdosDyB d5dw== X-Received: by 10.67.4.163 with SMTP id cf3mr32316367pad.92.1403554945514; Mon, 23 Jun 2014 13:22:25 -0700 (PDT) Received: from [192.168.178.23] (244.196.69.111.dynamic.snap.net.nz. [111.69.196.244]) by mx.google.com with ESMTPSA id yv7sm98578903pac.33.2014.06.23.13.22.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Jun 2014 13:22:24 -0700 (PDT) Message-ID: <53A88C82.3020605@gmail.com> Date: Tue, 24 Jun 2014 08:22:26 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Toerless Eckert References: <20140620095502.9324.99373.idtracker@ietfa.amsl.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BBAB34@xmb-rcd-x14.cisco.com> <53A48E1E.6040909@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BBC9DD@xmb-rcd-x14.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AEAB401@nkgeml512-mbx.china.huawei.com> <20140623173250.GU11315@cisco.com> In-Reply-To: <20140623173250.GU11315@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/22HGWfdgBAsyYhl39OWxlBR55KE Cc: "Michael Behringer \(mbehring\)" , "anima@ietf.org" , Sheng Jiang Subject: Re: [Anima] FW: I-D Action: draft-behringer-autonomic-control-plane-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: Mon, 23 Jun 2014 20:22:28 -0000 Toerless, At the moment there is a reading list in the wiki entry for the UCAN BOF. As we seem to be receiving several drafts at the moment, I will update the wiki in a day or two. Michael and I will discuss the BOF agenda soon of course. We probably won't have time for every use case to be presented, and certainly not in detail. Regards Brian On 24/06/2014 05:32, Toerless Eckert wrote: > Just trying to catch up with the anima process - do we have a list > of candidate draft - obviously i primarily have no track of the non-cisco > drafts. Wanted to check what the set of use-case drafts is. > > Any wiki for anima listing drafts ? > > Thanks > Toerless > > On Mon, Jun 23, 2014 at 08:08:32AM +0000, Sheng Jiang wrote: >> Hi, Michael, >> >> After read through this draft, I have fully of questions for the solution feasibility. There are a lot of design details missing. I believe it is because you were trying to describe the solution in a very abstract way in order to fit into an use case style document. >> >> Therefore, I would suggest you to submit two separated drafts: a pure use case draft for this and another solution draft with an overall picture and much more design details. As we agreed, we should not stop in use cases stage for long, so your potential solution could also be discussion objects. >> >> A couple of high-level design questions: authentication on a new device and domain establish. How a new device validate its discovered neighbor is trusted giving that offline authentication mechanism are very expensive? How and who is set up the domain boundary of the autonomic network in the ACP use case? >> >> Best regards, >> >> Sheng >> >>> -----Original Message----- >>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael >>> Behringer (mbehring) >>> Sent: Monday, June 23, 2014 1:55 PM >>> To: Brian E Carpenter >>> Cc: anima@ietf.org >>> Subject: Re: [Anima] FW: I-D Action: >>> draft-behringer-autonomic-control-plane-00.txt >>> >>> Well, yes, it also describes the solution (frankly, given that this is completely >>> new, I think we must describe how it works for it to be understood. >>> >>> At the same time, it is a use case, and the three use cases are described in the >>> doc. The communications is also described. >>> >>> Everybody, please have a look, and let me know whether we should >>> 1) submit a pure use case draft for this (which would be quite overlapping or >>> 2) add more of the template info in this draft or >>> 3) whether it's "good enough" for the discusstion. >>> >>> Michael >>> >>> >>>> -----Original Message----- >>>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >>>> Sent: 20 June 2014 21:40 >>>> To: Michael Behringer (mbehring) >>>> Cc: anima@ietf.org >>>> Subject: Re: [Anima] FW: I-D Action: draft-behringer-autonomic-control- >>>> plane-00.txt >>>> >>>> Michael, >>>> >>>> I've only had time for a quick glance so far (it's 07:40 Saturday for me) but >>>> this seems closer to solution space than to use cases. >>>> >>>> More when it gets to the top of my reading list... >>>> >>>> Regards >>>> Brian >>>> >>>> On 21/06/2014 00:14, Michael Behringer (mbehring) wrote: >>>>> The draft we just posted makes another good use case for an autonomic >>>> function, and we'd like to suggest it for the agenda of the UCAN BoF. >>>>> In a nutshell: Every autonomic node creates a secure channel to all its >>>> neighbours, based on link local addressing. Those channels are kept in a >>>> different context (VRF), and thus automatically create an overlay network. >>>> The thing to note is that this overlay network doesn't depend on config or >>>> (configured) addressing, and is therefore not affected by many common >>>> config or routing errors. >>>>> It is a classical autonomic function, because every node must act >>>> independently for this "virtual out of band" channel to come up. A good >>>> example for a self-managing function. >>>>> We'd love to get feedback on this draft. >>>>> Michael >>>>> >>>>>> -----Original Message----- >>>>>> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf >>>>>> Of internet-drafts@ietf.org >>>>>> Sent: 20 June 2014 11:55 >>>>>> To: i-d-announce@ietf.org >>>>>> Subject: I-D Action: draft-behringer-autonomic-control-plane-00.txt >>>>>> >>>>>> >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>>> directories. >>>>>> >>>>>> >>>>>> Title : An Autonomic Control Plane >>>>>> Authors : Michael H. Behringer >>>>>> Steinthor Bjarnason >>>>>> Balaji BL >>>>>> Toerless Eckert >>>>>> Filename : draft-behringer-autonomic-control-plane-00.txt >>>>>> Pages : 10 >>>>>> Date : 2014-06-20 >>>>>> >>>>>> Abstract: >>>>>> In certain scenarios, for example when bootstrapping a network, it is >>>>>> desirable to automatically bring up a secure, routed control plane, >>>>>> which is independent of device configurations and global routing >>>>>> table. This document describes an approach for an "Autonomic >>> Control >>>>>> Plane", which can be used as a "virtual out of band channel" - a >>>>>> self-managing overlay network, which is independent of >>> configuration, >>>>>> addressing and routing on the data plane. >>>>>> >>>>>> >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-behringer-autonomic-control-pl >>>>>> ane/ >>>>>> >>>>>> There's also a htmlized version available at: >>>>>> http://tools.ietf.org/html/draft-behringer-autonomic-control-plane-00 >>>>>> >>>>>> >>>>>> 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/ >>>>>> > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Mon Jun 23 18:24:30 2014 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 B195F1A04E7 for ; Mon, 23 Jun 2014 18:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 iFHoBfC0Px-s for ; Mon, 23 Jun 2014 18:24:26 -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 B381B1A03B7 for ; Mon, 23 Jun 2014 18:24:25 -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 BJC74372; Tue, 24 Jun 2014 01:24:24 +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; Tue, 24 Jun 2014 02:24:23 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.249]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Tue, 24 Jun 2014 09:24:18 +0800 From: Sheng Jiang To: "Michael Behringer (mbehring)" Thread-Topic: [Anima] FW: I-D Action: draft-behringer-autonomic-control-plane-00.txt Thread-Index: AQHPjqesHV8eRTDXyEeGw6wx8sUweJt+Ts0w//+NwACAAZqQoA== Date: Tue, 24 Jun 2014 01:24:18 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AEB48F5@nkgeml512-mbx.china.huawei.com> References: <20140620095502.9324.99373.idtracker@ietfa.amsl.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BBAB34@xmb-rcd-x14.cisco.com> <53A48E1E.6040909@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BBC9DD@xmb-rcd-x14.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AEAB401@nkgeml512-mbx.china.huawei.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BBCEDE@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BBCEDE@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.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/anima/D0cyl5oKp84Ns8xb-s8XlViQxAk Cc: "anima@ietf.org" Subject: Re: [Anima] FW: I-D Action: draft-behringer-autonomic-control-plane-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, 24 Jun 2014 01:24:28 -0000 SGksIE1pY2hhZWwsDQoNClRoYW5rcyBmb3IgeW91ciByZXBseSBhbmQgZXhwbGFuYXRpb24uIFBl cnNvbmFsbHksIEkgYW0gZmluZSB0byBoYXZlIHRoZSBjdXJyZW50IGZvcm0gYXMgYW4gdXNlIGNh c2UgZG9jdW1lbnQuIE15IHBvaW50IGlzIHRoZSBtZWNoYW5pc21zIG1lbnRpb25lZCBpbiB0aGlz IGRyYWZ0IGFyZSBzY2F0dGVyZWQgcGllY2UgYnkgcGllY2UuIEl0IHdvdWxkIGJlIGJldHRlciB0 aGF0IHlvdSBoYXZlIGFub3RoZXIgZGVkaWNhdGVkIHNvbHV0aW9uIGRvY3VtZW50IHRvIGRlc2Ny aWJlIHRoZSBBQ1Agc29sdXRpb24gYXMgYSB3aG9sZS4NCg0KU2hlbmcNCg0KPi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogTWljaGFlbCBCZWhyaW5nZXIgKG1iZWhyaW5nKSBbbWFp bHRvOm1iZWhyaW5nQGNpc2NvLmNvbV0NCj5TZW50OiBNb25kYXksIEp1bmUgMjMsIDIwMTQgNDo0 OSBQTQ0KPlRvOiBTaGVuZyBKaWFuZw0KPkNjOiBhbmltYUBpZXRmLm9yZw0KPlN1YmplY3Q6IFJF OiBbQW5pbWFdIEZXOiBJLUQgQWN0aW9uOg0KPmRyYWZ0LWJlaHJpbmdlci1hdXRvbm9taWMtY29u dHJvbC1wbGFuZS0wMC50eHQNCj4NCj5IaSBTaGVuZywNCj4NCj5UbyB5b3VyIHF1ZXN0aW9uczog RXNzZW50aWFsbHkgd2UgaGF2ZSB0d28gYml0czoNCj4NCj4tIGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXByaXRpa2luLWJvb3RzdHJhcHBpbmcta2V5aW5mcmFzdHJ1Y3R1cmVzDQo+ ZGVzY3JpYmVzIGhvdyBkZXZpY2VzIGluIGEgZG9tYWluIGdldCBhIGRvbWFpbiBjZXJ0aWZpY2F0 ZSwgc2VjdXJlbHksIGFuZA0KPnplcm8tdG91Y2guIFRob3NlIGRvbWFpbiBjZXJ0aWZpY2F0ZXMg YXJlIG5vdyB1c2VkIGZvciBkZXZpY2VzIHRvDQo+YXV0aGVudGljYXRlIGVhY2ggb3RoZXIuIEFu ZA0KPi0gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmVocmluZ2VyLWF1dG9ub21p Yy1jb250cm9sLXBsYW5lLTAwIHVzZXMNCj50aGUgZG9tYWluIGNlcnRpZmljYXRlcyB0byBzZWN1 cmUgaXRzIGludGVyYWN0aW9ucywgYW5kIHRvIGZvcm0gdGhlIGF1dG9ub21pYw0KPmNvbnRyb2wg cGxhbmUuIFNlY3Rpb24gMy4xIHRyaWVzIHRvIGV4cGxhaW4gdGhhdCB3ZSBuZWVkIHRoZSBhYm92 ZSBkcmFmdCBmb3INCj50aGlzIG9uZS4NCj4NCj5UaGUgb25seSBjZW50cmFsaXNlZCBiaXQgaW4g dGhlIHNvbHV0aW9uIGlzIGEgInJlZ2lzdHJhciIgY29tcG9uZW50LCB3aGljaA0KPmNoZWNrcyB0 aGF0IGRldmljZXMgYXJlIGluZGVlZCBwYXJ0IG9mIHRoZSBkb21haW4gKGJhc2VkIG9uIHNlcmlh bCBudW1iZXIgb3INCj52ZW5kb3IgY2VydGlmaWNhdGUpLCBhbmQgaGFuZHMgb3V0IHRoZSBkb21h aW4gY2VydGlmaWNhdGVzLiBTbyB0aGlzIGlzIGEgdHJ1bHkNCj5hdXRvbm9taWMgc29sdXRpb24g LSBhcyBkaXN0cmlidXRlZCBhcyBwb3NzaWJsZS4NCj4NCj5Ob3csIEkgYWdyZWUsIHRoaXMgZHJh ZnQgaXNuJ3Qgd3JpdHRlbiB3aXRoIHRoZSB1c2UgY2FzZSB0ZW1wbGF0ZSAoc29ycnkgd2UgaGFk DQo+c3RhcnRlZCB0aGlzIG9uZSBhIGxvbmcgdGltZSBhZ28pLiBXZSBjYW4gb2YgY291cnNlIGRv IGEgc2VwYXJhdGUgdXNlIGNhc2UNCj5kcmFmdCwgYnV0IGZyYW5rbHksIEknZCBwcmVmZXIgaWYg d2UgY2FuIGtlZXAgdGhlIGluZm8gaW4gb25lIHBsYWNlLg0KPg0KPkZyb20gdGhlIHVzZSBjYXNl IHRlbXBsYXRlLCB3ZSBhbHJlYWR5IGhhdmUgaW4gdGhlIEFDUCBkcmFmdDoNCj4tIGludHJvDQo+ LSBwcm9ibGVtIHN0YXRlbWVudA0KPi0gYmVuZWZpdHMgKHRoaXMgaXMgaW4gc2VjdGlvbiA2ICJ1 c2UgY2FzZXMgZm9yIHRoZSBBQ1AiKQ0KPi0gdXNlciBleHBlcmllbmNlIChzZWN0aW9uIDcpDQo+ LSBUaGUgIkFuYWx5c2lzIG9mIFBhcmFtZXRlcnMgYW5kIEluZm9ybWF0aW9uIEludm9sdmVkIiBp cyBjb250YWluZWQgaW4NCj5zZWN0aW9uIDMuDQo+DQo+VGhlcmUgaXMgbWlzc2luZzoNCj4tIGNv bXBhcmlzb24gd2l0aCBjdXJyZW50IHNvbHV0aW9uczogQnV0IEkgY2xhaW0gdGhlcmUgaXMgcmVh bGx5IG5vdGhpbmcNCj5jb21wYXJhYmxlIHRvZGF5LCBzbyB0aGlzIHNlY3Rpb24gZG9lc24ndCBt YWtlIHRvbyBtdWNoIHNlbnNlLg0KPg0KPlNvIEknZCBhcmd1ZSB3aGlsZSB0aGUgdGVtcGxhdGUg aXNuJ3Qgc3RyaWN0bHkgZm9sbG93ZWQsIHRoZSBjb250ZW50IGlzIHRoZXJlLg0KPg0KPkJ1dCBp ZiB5b3UgZmVlbCBzdHJvbmdseSB0aGF0IHdlIHNob3VsZCBhbHNvIGhhdmUgYSBzZXBhcmF0ZSB1 c2UgY2FzZSBkcmFmdCwgSSdtDQo+aGFwcHkgdG8gcHJvZHVjZSBvbmUuIFdvdWxkIGxpa2UgdG8g YXZvaWQgc3BlbmRpbmcgdGhlIGN5Y2xlcyB0aG91Z2ggdW5sZXNzDQo+cmVhbGx5IG5lZWRlZC4g Oi0pICBQbGVhc2UgbGV0IHVzIGtub3chDQo+DQo+TWljaGFlbA0KPg0KPg0KPj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IFNoZW5nIEppYW5nIFttYWlsdG86amlhbmdzaGVu Z0BodWF3ZWkuY29tXQ0KPj4gU2VudDogMjMgSnVuZSAyMDE0IDEwOjA5DQo+PiBUbzogTWljaGFl bCBCZWhyaW5nZXIgKG1iZWhyaW5nKQ0KPj4gQ2M6IGFuaW1hQGlldGYub3JnDQo+PiBTdWJqZWN0 OiBSRTogW0FuaW1hXSBGVzogSS1EIEFjdGlvbjogZHJhZnQtYmVocmluZ2VyLWF1dG9ub21pYy1j b250cm9sLQ0KPj4gcGxhbmUtMDAudHh0DQo+Pg0KPj4gSGksIE1pY2hhZWwsDQo+Pg0KPj4gQWZ0 ZXIgcmVhZCB0aHJvdWdoIHRoaXMgZHJhZnQsIEkgaGF2ZSBmdWxseSBvZiBxdWVzdGlvbnMgZm9y IHRoZSBzb2x1dGlvbg0KPj4gZmVhc2liaWxpdHkuIFRoZXJlIGFyZSBhIGxvdCBvZiBkZXNpZ24g ZGV0YWlscyBtaXNzaW5nLiBJIGJlbGlldmUgaXQgaXMgYmVjYXVzZQ0KPj4geW91IHdlcmUgdHJ5 aW5nIHRvIGRlc2NyaWJlIHRoZSBzb2x1dGlvbiBpbiBhIHZlcnkgYWJzdHJhY3Qgd2F5IGluIG9y ZGVyIHRvIGZpdA0KPj4gaW50byBhbiB1c2UgY2FzZSBzdHlsZSBkb2N1bWVudC4NCj4+DQo+PiBU aGVyZWZvcmUsIEkgd291bGQgc3VnZ2VzdCB5b3UgdG8gc3VibWl0IHR3byBzZXBhcmF0ZWQgZHJh ZnRzOiBhIHB1cmUgdXNlDQo+PiBjYXNlIGRyYWZ0IGZvciB0aGlzIGFuZCBhbm90aGVyIHNvbHV0 aW9uIGRyYWZ0IHdpdGggYW4gb3ZlcmFsbCBwaWN0dXJlIGFuZA0KPj4gbXVjaCBtb3JlIGRlc2ln biBkZXRhaWxzLiBBcyB3ZSBhZ3JlZWQsIHdlIHNob3VsZCBub3Qgc3RvcCBpbiB1c2UgY2FzZXMN Cj4+IHN0YWdlIGZvciBsb25nLCBzbyB5b3VyIHBvdGVudGlhbCBzb2x1dGlvbiBjb3VsZCBhbHNv IGJlIGRpc2N1c3Npb24gb2JqZWN0cy4NCj4+DQo+PiBBIGNvdXBsZSBvZiBoaWdoLWxldmVsIGRl c2lnbiBxdWVzdGlvbnM6IGF1dGhlbnRpY2F0aW9uIG9uIGEgbmV3IGRldmljZQ0KPj4gYW5kIGRv bWFpbiBlc3RhYmxpc2guIEhvdyBhIG5ldyBkZXZpY2UgdmFsaWRhdGUgaXRzIGRpc2NvdmVyZWQg bmVpZ2hib3IgaXMNCj4+IHRydXN0ZWQgZ2l2aW5nIHRoYXQgb2ZmbGluZSBhdXRoZW50aWNhdGlv biBtZWNoYW5pc20gYXJlIHZlcnkgZXhwZW5zaXZlPw0KPj4gSG93IGFuZCB3aG8gaXMgc2V0IHVw IHRoZSBkb21haW4gYm91bmRhcnkgb2YgdGhlIGF1dG9ub21pYyBuZXR3b3JrIGluDQo+PiB0aGUg QUNQIHVzZSBjYXNlPw0KPj4NCj4+IEJlc3QgcmVnYXJkcywNCj4+DQo+PiBTaGVuZw0KPj4NCj4+ ID4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPkZyb206IEFuaW1hIFttYWlsdG86YW5p bWEtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1pY2hhZWwNCj4+ID5CZWhyaW5nZXIg KG1iZWhyaW5nKQ0KPj4gPlNlbnQ6IE1vbmRheSwgSnVuZSAyMywgMjAxNCAxOjU1IFBNDQo+PiA+ VG86IEJyaWFuIEUgQ2FycGVudGVyDQo+PiA+Q2M6IGFuaW1hQGlldGYub3JnDQo+PiA+U3ViamVj dDogUmU6IFtBbmltYV0gRlc6IEktRCBBY3Rpb246DQo+PiA+ZHJhZnQtYmVocmluZ2VyLWF1dG9u b21pYy1jb250cm9sLXBsYW5lLTAwLnR4dA0KPj4gPg0KPj4gPldlbGwsIHllcywgaXQgYWxzbyBk ZXNjcmliZXMgdGhlIHNvbHV0aW9uIChmcmFua2x5LCBnaXZlbiB0aGF0IHRoaXMgaXMNCj4+ID5j b21wbGV0ZWx5IG5ldywgSSB0aGluayB3ZSBtdXN0IGRlc2NyaWJlIGhvdyBpdCB3b3JrcyBmb3Ig aXQgdG8gYmUNCj4+IHVuZGVyc3Rvb2QuDQo+PiA+DQo+PiA+QXQgdGhlIHNhbWUgdGltZSwgaXQg aXMgYSB1c2UgY2FzZSwgYW5kIHRoZSB0aHJlZSB1c2UgY2FzZXMgYXJlDQo+PiA+ZGVzY3JpYmVk IGluIHRoZSBkb2MuIFRoZSBjb21tdW5pY2F0aW9ucyBpcyBhbHNvIGRlc2NyaWJlZC4NCj4+ID4N Cj4+ID5FdmVyeWJvZHksIHBsZWFzZSBoYXZlIGEgbG9vaywgYW5kIGxldCBtZSBrbm93IHdoZXRo ZXIgd2Ugc2hvdWxkDQo+PiA+MSkgc3VibWl0IGEgcHVyZSB1c2UgY2FzZSBkcmFmdCBmb3IgdGhp cyAod2hpY2ggd291bGQgYmUgcXVpdGUNCj4+ID5vdmVybGFwcGluZyBvcg0KPj4gPjIpIGFkZCBt b3JlIG9mIHRoZSB0ZW1wbGF0ZSBpbmZvIGluIHRoaXMgZHJhZnQgb3INCj4+ID4zKSB3aGV0aGVy IGl0J3MgImdvb2QgZW5vdWdoIiBmb3IgdGhlIGRpc2N1c3N0aW9uLg0KPj4gPg0KPj4gPk1pY2hh ZWwNCj4+ID4NCj4+ID4NCj4+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+PiBG cm9tOiBCcmlhbiBFIENhcnBlbnRlciBbbWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNv bV0NCj4+ID4+IFNlbnQ6IDIwIEp1bmUgMjAxNCAyMTo0MA0KPj4gPj4gVG86IE1pY2hhZWwgQmVo cmluZ2VyIChtYmVocmluZykNCj4+ID4+IENjOiBhbmltYUBpZXRmLm9yZw0KPj4gPj4gU3ViamVj dDogUmU6IFtBbmltYV0gRlc6IEktRCBBY3Rpb246DQo+PiA+PiBkcmFmdC1iZWhyaW5nZXItYXV0 b25vbWljLWNvbnRyb2wtDQo+PiA+PiBwbGFuZS0wMC50eHQNCj4+ID4+DQo+PiA+PiBNaWNoYWVs LA0KPj4gPj4NCj4+ID4+IEkndmUgb25seSBoYWQgdGltZSBmb3IgYSBxdWljayBnbGFuY2Ugc28g ZmFyIChpdCdzIDA3OjQwIFNhdHVyZGF5IGZvcg0KPj4gPj4gbWUpIGJ1dCB0aGlzIHNlZW1zIGNs b3NlciB0byBzb2x1dGlvbiBzcGFjZSB0aGFuIHRvIHVzZSBjYXNlcy4NCj4+ID4+DQo+PiA+PiBN b3JlIHdoZW4gaXQgZ2V0cyB0byB0aGUgdG9wIG9mIG15IHJlYWRpbmcgbGlzdC4uLg0KPj4gPj4N Cj4+ID4+IFJlZ2FyZHMNCj4+ID4+ICAgIEJyaWFuDQo+PiA+Pg0KPj4gPj4gT24gMjEvMDYvMjAx NCAwMDoxNCwgTWljaGFlbCBCZWhyaW5nZXIgKG1iZWhyaW5nKSB3cm90ZToNCj4+ID4+ID4gVGhl IGRyYWZ0IHdlIGp1c3QgcG9zdGVkIG1ha2VzIGFub3RoZXIgZ29vZCB1c2UgY2FzZSBmb3IgYW4N Cj4+ID4+ID4gYXV0b25vbWljDQo+PiA+PiBmdW5jdGlvbiwgYW5kIHdlJ2QgbGlrZSB0byBzdWdn ZXN0IGl0IGZvciB0aGUgYWdlbmRhIG9mIHRoZSBVQ0FOIEJvRi4NCj4+ID4+ID4NCj4+ID4+ID4g SW4gYSBudXRzaGVsbDogRXZlcnkgYXV0b25vbWljIG5vZGUgY3JlYXRlcyBhIHNlY3VyZSBjaGFu bmVsIHRvIGFsbA0KPj4gPj4gPiBpdHMNCj4+ID4+IG5laWdoYm91cnMsIGJhc2VkIG9uIGxpbmsg bG9jYWwgYWRkcmVzc2luZy4gVGhvc2UgY2hhbm5lbHMgYXJlIGtlcHQNCj4+ID4+IGluIGEgZGlm ZmVyZW50IGNvbnRleHQgKFZSRiksIGFuZCB0aHVzIGF1dG9tYXRpY2FsbHkgY3JlYXRlIGFuIG92 ZXJsYXkNCj4+IG5ldHdvcmsuDQo+PiA+PiBUaGUgdGhpbmcgdG8gbm90ZSBpcyB0aGF0IHRoaXMg b3ZlcmxheSBuZXR3b3JrIGRvZXNuJ3QgZGVwZW5kIG9uDQo+PiA+PiBjb25maWcgb3INCj4+ID4+ IChjb25maWd1cmVkKSBhZGRyZXNzaW5nLCBhbmQgaXMgdGhlcmVmb3JlIG5vdCBhZmZlY3RlZCBi eSBtYW55IGNvbW1vbg0KPj4gPj4gY29uZmlnIG9yIHJvdXRpbmcgZXJyb3JzLg0KPj4gPj4gPg0K Pj4gPj4gPiBJdCBpcyBhIGNsYXNzaWNhbCBhdXRvbm9taWMgZnVuY3Rpb24sIGJlY2F1c2UgZXZl cnkgbm9kZSBtdXN0IGFjdA0KPj4gPj4gaW5kZXBlbmRlbnRseSBmb3IgdGhpcyAidmlydHVhbCBv dXQgb2YgYmFuZCIgY2hhbm5lbCB0byBjb21lIHVwLiBBDQo+PiA+PiBnb29kIGV4YW1wbGUgZm9y IGEgc2VsZi1tYW5hZ2luZyBmdW5jdGlvbi4NCj4+ID4+ID4NCj4+ID4+ID4gV2UnZCBsb3ZlIHRv IGdldCBmZWVkYmFjayBvbiB0aGlzIGRyYWZ0Lg0KPj4gPj4gPiBNaWNoYWVsDQo+PiA+PiA+DQo+ PiA+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPj4gPj4gRnJvbTogSS1ELUFu bm91bmNlIFttYWlsdG86aS1kLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+PiA+PiA+ PiBCZWhhbGYgT2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+PiA+PiA+PiBTZW50OiAyMCBK dW5lIDIwMTQgMTE6NTUNCj4+ID4+ID4+IFRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCj4+ID4+ ID4+IFN1YmplY3Q6IEktRCBBY3Rpb246DQo+PiA+PiA+PiBkcmFmdC1iZWhyaW5nZXItYXV0b25v bWljLWNvbnRyb2wtcGxhbmUtMDAudHh0DQo+PiA+PiA+Pg0KPj4gPj4gPj4NCj4+ID4+ID4+IEEg TmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0 LURyYWZ0cw0KPj4gPj4gPj4gZGlyZWN0b3JpZXMuDQo+PiA+PiA+Pg0KPj4gPj4gPj4NCj4+ID4+ ID4+ICAgICAgICAgVGl0bGUgICAgICAgICAgIDogQW4gQXV0b25vbWljIENvbnRyb2wgUGxhbmUN Cj4+ID4+ID4+ICAgICAgICAgQXV0aG9ycyAgICAgICAgIDogTWljaGFlbCBILiBCZWhyaW5nZXIN Cj4+ID4+ID4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgU3RlaW50aG9yIEJqYXJuYXNvbg0K Pj4gPj4gPj4gICAgICAgICAgICAgICAgICAgICAgICAgICBCYWxhamkgQkwNCj4+ID4+ID4+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgVG9lcmxlc3MgRWNrZXJ0DQo+PiA+PiA+PiAJRmlsZW5h bWUgICAgICAgIDogZHJhZnQtYmVocmluZ2VyLWF1dG9ub21pYy1jb250cm9sLXBsYW5lLTAwLnR4 dA0KPj4gPj4gPj4gCVBhZ2VzICAgICAgICAgICA6IDEwDQo+PiA+PiA+PiAJRGF0ZSAgICAgICAg ICAgIDogMjAxNC0wNi0yMA0KPj4gPj4gPj4NCj4+ID4+ID4+IEFic3RyYWN0Og0KPj4gPj4gPj4g ICAgSW4gY2VydGFpbiBzY2VuYXJpb3MsIGZvciBleGFtcGxlIHdoZW4gYm9vdHN0cmFwcGluZyBh IG5ldHdvcmssDQo+aXQgaXMNCj4+ID4+ID4+ICAgIGRlc2lyYWJsZSB0byBhdXRvbWF0aWNhbGx5 IGJyaW5nIHVwIGEgc2VjdXJlLCByb3V0ZWQgY29udHJvbA0KPnBsYW5lLA0KPj4gPj4gPj4gICAg d2hpY2ggaXMgaW5kZXBlbmRlbnQgb2YgZGV2aWNlIGNvbmZpZ3VyYXRpb25zIGFuZCBnbG9iYWwg cm91dGluZw0KPj4gPj4gPj4gICAgdGFibGUuICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhbiBh cHByb2FjaCBmb3IgYW4gIkF1dG9ub21pYw0KPj4gPkNvbnRyb2wNCj4+ID4+ID4+ICAgIFBsYW5l Iiwgd2hpY2ggY2FuIGJlIHVzZWQgYXMgYSAidmlydHVhbCBvdXQgb2YgYmFuZCBjaGFubmVsIiAt IGENCj4+ID4+ID4+ICAgIHNlbGYtbWFuYWdpbmcgb3ZlcmxheSBuZXR3b3JrLCB3aGljaCBpcyBp bmRlcGVuZGVudCBvZg0KPj4gPmNvbmZpZ3VyYXRpb24sDQo+PiA+PiA+PiAgICBhZGRyZXNzaW5n IGFuZCByb3V0aW5nIG9uIHRoZSBkYXRhIHBsYW5lLg0KPj4gPj4gPj4NCj4+ID4+ID4+DQo+PiA+ PiA+PiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoN Cj4+ID4+ID4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJlaHJpbmdl ci1hdXRvbm9taWMtY29udHJvbA0KPj4gPj4gPj4gLXBsDQo+PiA+PiA+PiBhbmUvDQo+PiA+PiA+ Pg0KPj4gPj4gPj4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6 DQo+PiA+PiA+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iZWhyaW5nZXItYXV0 b25vbWljLWNvbnRyb2wtcGxhbmUNCj4+ID4+ID4+IC0wMA0KPj4gPj4gPj4NCj4+ID4+ID4+DQo+ PiA+PiA+PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMg ZnJvbSB0aGUgdGltZSBvZg0KPj4gPj4gPj4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQg dmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0DQo+PiA+PiB0b29scy5pZXRmLm9yZy4N Cj4+ID4+ID4+DQo+PiA+PiA+PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5 IGFub255bW91cyBGVFAgYXQ6DQo+PiA+PiA+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzLw0KPj4gPj4gPj4NCj4+ID4+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+PiA+PiA+PiBJLUQtQW5ub3VuY2UgbWFpbGluZyBsaXN0DQo+ PiA+PiA+PiBJLUQtQW5ub3VuY2VAaWV0Zi5vcmcNCj4+ID4+ID4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo+PiA+PiA+PiBJbnRlcm5ldC1EcmFm dCBkaXJlY3RvcmllczogaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbCBvcg0KPj4gPj4g Pj4gZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQNCj4+ID4+ID4NCj4+ ID4+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ ID4+ID4gQW5pbWEgbWFpbGluZyBsaXN0DQo+PiA+PiA+IEFuaW1hQGlldGYub3JnDQo+PiA+PiA+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWENCj4+ID4+ID4NCj4+ ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPkFu aW1hIG1haWxpbmcgbGlzdA0KPj4gPkFuaW1hQGlldGYub3JnDQo+PiA+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYQ0K From nobody Mon Jun 23 20:58:32 2014 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 DF6D21B2825 for ; Mon, 23 Jun 2014 20:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 rGWDoOE94rfX for ; Mon, 23 Jun 2014 20:58:26 -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 C111A1A0547 for ; Mon, 23 Jun 2014 20:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9959; q=dns/txt; s=iport; t=1403582305; x=1404791905; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=HGQZTa/EjAXCXWf2O/y10jZ2JPeMF0oI/RGihV+fci0=; b=JeDNd/8bQIba75TQvHGUqOMRxp75o+S09Lz6z19JnCOkWbS0D79YROAs iLqUpk7yZ25bnieCJNJppHVqGGE/kjzw3/42m5wVhxZLNuL6H7/QGf50J gzFMXgv1OmAKXsBlWqQq161n9AuejfoRETLVQQj2rdE+3bjtRrNTyIn4q 0=; X-IronPort-AV: E=Sophos;i="5.01,535,1400025600"; d="scan'208";a="334974599" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-1.cisco.com with ESMTP; 24 Jun 2014 03:58:25 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s5O3wOXB015287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Jun 2014 03:58:25 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 s5O3wHwj008671; Mon, 23 Jun 2014 20:58:18 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id s5O3wGKr008669; Mon, 23 Jun 2014 20:58:16 -0700 Date: Mon, 23 Jun 2014 20:58:16 -0700 From: Toerless Eckert To: Sheng Jiang Message-ID: <20140624035816.GG11315@cisco.com> References: <20140620095502.9324.99373.idtracker@ietfa.amsl.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BBAB34@xmb-rcd-x14.cisco.com> <53A48E1E.6040909@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BBC9DD@xmb-rcd-x14.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AEAB401@nkgeml512-mbx.china.huawei.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BBCEDE@xmb-rcd-x14.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AEB48F5@nkgeml512-mbx.china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AEB48F5@nkgeml512-mbx.china.huawei.com> User-Agent: Mutt/1.4.2.2i Archived-At: http://mailarchive.ietf.org/arch/msg/anima/JfLxnmAQGCBLyc_yuHcUn-kUKPo Cc: "anima@ietf.org" , "Michael Behringer \(mbehring\)" Subject: Re: [Anima] FW: I-D Action: draft-behringer-autonomic-control-plane-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, 24 Jun 2014 03:58:29 -0000 Sheng, The elements that where contributed as separate drafts are also useable by themselves without necessarily having to be compounded into the ACP. They are more like lower layer modules. On Tue, Jun 24, 2014 at 01:24:18AM +0000, Sheng Jiang wrote: > Hi, Michael, > > Thanks for your reply and explanation. Personally, I am fine to have the current form as an use case document. My point is the mechanisms mentioned in this draft are scattered piece by piece. It would be better that you have another dedicated solution document to describe the ACP solution as a whole. > > Sheng > > >-----Original Message----- > >From: Michael Behringer (mbehring) [mailto:mbehring@cisco.com] > >Sent: Monday, June 23, 2014 4:49 PM > >To: Sheng Jiang > >Cc: anima@ietf.org > >Subject: RE: [Anima] FW: I-D Action: > >draft-behringer-autonomic-control-plane-00.txt > > > >Hi Sheng, > > > >To your questions: Essentially we have two bits: > > > >- http://tools.ietf.org/html/draft-pritikin-bootstrapping-keyinfrastructures > >describes how devices in a domain get a domain certificate, securely, and > >zero-touch. Those domain certificates are now used for devices to > >authenticate each other. And > >- http://tools.ietf.org/html/draft-behringer-autonomic-control-plane-00 uses > >the domain certificates to secure its interactions, and to form the autonomic > >control plane. Section 3.1 tries to explain that we need the above draft for > >this one. > > > >The only centralised bit in the solution is a "registrar" component, which > >checks that devices are indeed part of the domain (based on serial number or > >vendor certificate), and hands out the domain certificates. So this is a truly > >autonomic solution - as distributed as possible. > > > >Now, I agree, this draft isn't written with the use case template (sorry we had > >started this one a long time ago). We can of course do a separate use case > >draft, but frankly, I'd prefer if we can keep the info in one place. > > > >From the use case template, we already have in the ACP draft: > >- intro > >- problem statement > >- benefits (this is in section 6 "use cases for the ACP") > >- user experience (section 7) > >- The "Analysis of Parameters and Information Involved" is contained in > >section 3. > > > >There is missing: > >- comparison with current solutions: But I claim there is really nothing > >comparable today, so this section doesn't make too much sense. > > > >So I'd argue while the template isn't strictly followed, the content is there. > > > >But if you feel strongly that we should also have a separate use case draft, I'm > >happy to produce one. Would like to avoid spending the cycles though unless > >really needed. :-) Please let us know! > > > >Michael > > > > > >> -----Original Message----- > >> From: Sheng Jiang [mailto:jiangsheng@huawei.com] > >> Sent: 23 June 2014 10:09 > >> To: Michael Behringer (mbehring) > >> Cc: anima@ietf.org > >> Subject: RE: [Anima] FW: I-D Action: draft-behringer-autonomic-control- > >> plane-00.txt > >> > >> Hi, Michael, > >> > >> After read through this draft, I have fully of questions for the solution > >> feasibility. There are a lot of design details missing. I believe it is because > >> you were trying to describe the solution in a very abstract way in order to fit > >> into an use case style document. > >> > >> Therefore, I would suggest you to submit two separated drafts: a pure use > >> case draft for this and another solution draft with an overall picture and > >> much more design details. As we agreed, we should not stop in use cases > >> stage for long, so your potential solution could also be discussion objects. > >> > >> A couple of high-level design questions: authentication on a new device > >> and domain establish. How a new device validate its discovered neighbor is > >> trusted giving that offline authentication mechanism are very expensive? > >> How and who is set up the domain boundary of the autonomic network in > >> the ACP use case? > >> > >> Best regards, > >> > >> Sheng > >> > >> >-----Original Message----- > >> >From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael > >> >Behringer (mbehring) > >> >Sent: Monday, June 23, 2014 1:55 PM > >> >To: Brian E Carpenter > >> >Cc: anima@ietf.org > >> >Subject: Re: [Anima] FW: I-D Action: > >> >draft-behringer-autonomic-control-plane-00.txt > >> > > >> >Well, yes, it also describes the solution (frankly, given that this is > >> >completely new, I think we must describe how it works for it to be > >> understood. > >> > > >> >At the same time, it is a use case, and the three use cases are > >> >described in the doc. The communications is also described. > >> > > >> >Everybody, please have a look, and let me know whether we should > >> >1) submit a pure use case draft for this (which would be quite > >> >overlapping or > >> >2) add more of the template info in this draft or > >> >3) whether it's "good enough" for the discusstion. > >> > > >> >Michael > >> > > >> > > >> >> -----Original Message----- > >> >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > >> >> Sent: 20 June 2014 21:40 > >> >> To: Michael Behringer (mbehring) > >> >> Cc: anima@ietf.org > >> >> Subject: Re: [Anima] FW: I-D Action: > >> >> draft-behringer-autonomic-control- > >> >> plane-00.txt > >> >> > >> >> Michael, > >> >> > >> >> I've only had time for a quick glance so far (it's 07:40 Saturday for > >> >> me) but this seems closer to solution space than to use cases. > >> >> > >> >> More when it gets to the top of my reading list... > >> >> > >> >> Regards > >> >> Brian > >> >> > >> >> On 21/06/2014 00:14, Michael Behringer (mbehring) wrote: > >> >> > The draft we just posted makes another good use case for an > >> >> > autonomic > >> >> function, and we'd like to suggest it for the agenda of the UCAN BoF. > >> >> > > >> >> > In a nutshell: Every autonomic node creates a secure channel to all > >> >> > its > >> >> neighbours, based on link local addressing. Those channels are kept > >> >> in a different context (VRF), and thus automatically create an overlay > >> network. > >> >> The thing to note is that this overlay network doesn't depend on > >> >> config or > >> >> (configured) addressing, and is therefore not affected by many common > >> >> config or routing errors. > >> >> > > >> >> > It is a classical autonomic function, because every node must act > >> >> independently for this "virtual out of band" channel to come up. A > >> >> good example for a self-managing function. > >> >> > > >> >> > We'd love to get feedback on this draft. > >> >> > Michael > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On > >> >> >> Behalf Of internet-drafts@ietf.org > >> >> >> Sent: 20 June 2014 11:55 > >> >> >> To: i-d-announce@ietf.org > >> >> >> Subject: I-D Action: > >> >> >> draft-behringer-autonomic-control-plane-00.txt > >> >> >> > >> >> >> > >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts > >> >> >> directories. > >> >> >> > >> >> >> > >> >> >> Title : An Autonomic Control Plane > >> >> >> Authors : Michael H. Behringer > >> >> >> Steinthor Bjarnason > >> >> >> Balaji BL > >> >> >> Toerless Eckert > >> >> >> Filename : draft-behringer-autonomic-control-plane-00.txt > >> >> >> Pages : 10 > >> >> >> Date : 2014-06-20 > >> >> >> > >> >> >> Abstract: > >> >> >> In certain scenarios, for example when bootstrapping a network, > >it is > >> >> >> desirable to automatically bring up a secure, routed control > >plane, > >> >> >> which is independent of device configurations and global routing > >> >> >> table. This document describes an approach for an "Autonomic > >> >Control > >> >> >> Plane", which can be used as a "virtual out of band channel" - a > >> >> >> self-managing overlay network, which is independent of > >> >configuration, > >> >> >> addressing and routing on the data plane. > >> >> >> > >> >> >> > >> >> >> The IETF datatracker status page for this draft is: > >> >> >> https://datatracker.ietf.org/doc/draft-behringer-autonomic-control > >> >> >> -pl > >> >> >> ane/ > >> >> >> > >> >> >> There's also a htmlized version available at: > >> >> >> http://tools.ietf.org/html/draft-behringer-autonomic-control-plane > >> >> >> -00 > >> >> >> > >> >> >> > >> >> >> 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 > >> >> > > >> >> > _______________________________________________ > >> >> > 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 -- --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture SDN: Let me play with the network, mommy! From nobody Tue Jun 24 01:16:14 2014 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 490001A0564 for ; Tue, 24 Jun 2014 01:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, 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 jWaK_4HYFqhz for ; Tue, 24 Jun 2014 01:14:56 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54C251B298D for ; Tue, 24 Jun 2014 01:14:56 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id l4so6109337lbv.0 for ; Tue, 24 Jun 2014 01:14:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=I+3tecruN8T2NxNQevBNUjl+qeFIR61N3iryNku7rj4=; b=c4Rhvwa7BWZEb27SGWeqMhHpwVQW653l29f+3M17WYScrbdTjvanbmvw0Hvdy7Fn4O 8zx688hhE+f+c7rQjvkNkpXozwUH9uZwMcVveitalDc+HoC0dMOhUl2achwREcuLAyIa oaZd1ov9RQlscx2SbVyMAYUX9PTmToJsRjokpQeUvuCrp4yT+CE65n8RHpVEqXPhxQ+d 9N4GaiPd1qIr1eCXTobt+vKketGRf7TgdQktn80OJTh+4EMfyQ0jVXPiqY6J7ThEqQas vsCd7vW6cmkWxjOPHhN66TTQRbEBVW+y3eS+YWraHyvGQh5pILNdhiWC2u6Gx1IMZXXP Grmg== MIME-Version: 1.0 X-Received: by 10.112.77.41 with SMTP id p9mr1194085lbw.53.1403597694486; Tue, 24 Jun 2014 01:14:54 -0700 (PDT) Sender: jeferson.nobre@gmail.com Received: by 10.112.146.228 with HTTP; Tue, 24 Jun 2014 01:14:54 -0700 (PDT) In-Reply-To: <20140623221805.12892.61525.idtracker@ietfa.amsl.com> References: <20140623221805.12892.61525.idtracker@ietfa.amsl.com> Date: Tue, 24 Jun 2014 05:14:54 -0300 X-Google-Sender-Auth: JgfoF7oM2K9vrmOqy8xJFC1mKao Message-ID: From: =?UTF-8?Q?J=C3=A9ferson_Campos_Nobre?= To: nmrg@irtf.org, anima@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/anima/FEqOmFCN8uEXtQJIaUpym7u6wQY Subject: [Anima] Fwd: New Version Notification for draft-irtf-nmrg-autonomic-sla-violation-detection-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, 24 Jun 2014 08:16:12 -0000 ---------- Forwarded message ---------- From: Date: Mon, Jun 23, 2014 at 7:18 PM Subject: New Version Notification for draft-irtf-nmrg-autonomic-sla-violation-detection-00.txt To: Jeferson Campos Nobre , Alexander Clemm , Alberto Gonzalez Prieto , Lisandro Zambenedetti Granville A new version of I-D, draft-irtf-nmrg-autonomic-sla-violation-detection-00.txt has been successfully submitted by Jeferson Campos Nobre and posted to the IETF repository. Name: draft-irtf-nmrg-autonomic-sla-violation-detection Revision: 00 Title: Autonomic Networking Use Case for Distributed Detection of SLA Violations Document date: 2014-06-20 Group: nmrg Pages: 9 URL: http://www.ietf.org/internet-drafts/draft-irtf-nmrg-autonomic-sla-violation-detection-00.txt Status: https://datatracker.ietf.org/doc/draft-irtf-nmrg-autonomic-sla-violation-detection/ Htmlized: http://tools.ietf.org/html/draft-irtf-nmrg-autonomic-sla-violation-detection-00 Abstract: This document describes a use case for autonomic networking in distributed detection of SLA violations. It is one of a series of use cases intended to illustrate requirements for autonomic networking. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Tue Jun 24 06:55:34 2014 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 8B0A41B2A11 for ; Tue, 24 Jun 2014 06:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsL5z2itkfhU for ; Tue, 24 Jun 2014 06:55:28 -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 3378F1B293D for ; Tue, 24 Jun 2014 06:55:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2984; q=dns/txt; s=iport; t=1403618128; x=1404827728; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=tGrCikYZqThpouQSbwLH+KjRIdiqG2NQQ7i6CNsKEZI=; b=fGFXiU/dDcowcPldo0J5Cx7kaT2I0zRHL8VRt/Lz5Ldp8tp09SVK0wA2 gDcnfbF95JZWgdfOSfNREGixUt3elHAPRjADOT/gZCkweKflzhHPsWXOX GTrz2iek1hxP7KIaKGHh2ED9r+DvF1enWYcqehET10MGY5tN/zCrkvKwQ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApAGAJ6CqVOtJA2H/2dsb2JhbABZgw1SWqpABQECA5k1AYEGFnWEBQEEOlEBKhRCJgEEARoBiDkNw2MXhWOINxACAR4zgzKBFgWcF5Ilg0JsgUQ X-IronPort-AV: E=Sophos;i="5.01,538,1400025600"; d="scan'208";a="335366339" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-4.cisco.com with ESMTP; 24 Jun 2014 13:55:27 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s5ODtQM7018026 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Jun 2014 13:55:26 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Tue, 24 Jun 2014 08:55:26 -0500 From: "Michael Behringer (mbehring)" To: "anima@ietf.org" , "nmrg@irtf.org" Thread-Topic: Updating draft-irtf-nmrg-autonomic-network-definitions-00 Thread-Index: Ac+Ps8dVKhhDDzh8R4WTmNCrIuSMYg== Date: Tue, 24 Jun 2014 13:55:25 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BCA03D@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.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/anima/OQ6RXS3G7f_KoelIupQf9F7WA08 Subject: [Anima] Updating draft-irtf-nmrg-autonomic-network-definitions-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: Tue, 24 Jun 2014 13:55:31 -0000 NMRG, Anima,=20 Having gone through feedback, and re-reading the document myself, here is a= list of changes I'm proposing to make to=20 http://tools.ietf.org/html/draft-irtf-nmrg-autonomic-network-definitions-00= : High level, I think the "meat" of the document, sections 3, 4 and 6 are pre= tty complete and correct. If anyone thinks we're missing an important desig= n goal or a non-design goal, please speak up!=20 Some details:=20 1. Section 3.1. always refers to "nodes". We should rephrase this to "funct= ions". The primary goal here is not to produce a fully autonomic node or ne= twork, but autonomic functions. For the foreseeable future fully autonomic = nodes/networks will remain the exception.=20 Therefore: s/node/function/ in this section.=20 Actually, also later on in the doc the doc references sometimes "nodes" or = "the network". I suggest to change that to "function".=20 2. Common infrastructure.=20 In my mail http://www.ietf.org/mail-archive/web/nmrg/current/msg01512.html = I suggested to add to the design goals:=20
points out that there = are already a number of fully or partially autonomic functions available to= day. However, they are largely independent, and each has its own methods an= d protocols to communicate, discover, define and distribute policy, etc. The goal of the work on autonomic networking in the IETF is therefore n= ot just to create autonomic functions, but to define a common infrastructur= e that autonomic functions can use. This autonomic networking infrastructur= e may contain common control and management functions such as messaging, se= rvice discovery, negotiation, intent distribution, etc. A common approach t= o define and manage intent is also required. Refer to the reference model below: All the components around the "auto= nomic service agents" should be common components, such that the autonomic = service agents do not have to replicate common tasks individually.
Unless I missed it, I haven't seen any negative comments on that section, s= o I'll add it to the new version.=20 3. Use case section.=20 In the same email (link above) I proposed some text for the use case sectio= n. But frankly, I think this is overtaken by the discussion we had on the l= ist, and out of date.=20 We also want to drive this document to publication soon, so procedural issu= es such as how to report use cases should really not be there any more.=20 I suggest we just remove this section completely, since IMO it is not requi= red for the document to be useful and complete. Thoughts?=20 Am I missing any feedback, or points we discussed? If so, please let me kno= w!=20 I'm finalising version -01 of the document now. I'll circulate first amongs= t the authors, then post the result.=20 Michael From nobody Tue Jun 24 13:05:49 2014 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 532191A0657 for ; Tue, 24 Jun 2014 13:05:44 -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=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id it7PtBTcLMs4 for ; Tue, 24 Jun 2014 13:05:42 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 750321A0652 for ; Tue, 24 Jun 2014 13:05:42 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id et14so689474pad.7 for ; Tue, 24 Jun 2014 13:05: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:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=upK/BlFINC7Mc/Q1hzFvErAW6qQqXcspio1UHsTJ4Jc=; b=JC0b7xGgAUYaRJRoAN0TOV/TgqJ16obe/bqBUwuLxiMpoLzzHpAL7qsI8Sr6iJNPE6 nj+NGndsmZOPSx0WYKlmBueNp6Im5QyyYvrUDlB6i/weSDpLrtw/E8C2D8tF1HNRwRhi Eyv6I0a/PhbOsoCH8ziDBTKk0EDlN3v73D2vQudOQqYSqEnojBMySN3JA2O0fSNcKjGS dEGu0R2W7V6EBnNJwhIviZdQtZO32ZjhNBYaYxg1H2E1dQutDzAVyCs7AO3A7WYsttfq boNmGCZ6PgBJJ4KjziJ+myAS5OGY1qM6ULtsgk0xX4ZSXDQx8dZsDKDAOFAozUudhRDZ nSbQ== X-Received: by 10.66.254.37 with SMTP id af5mr4437068pad.113.1403640342084; Tue, 24 Jun 2014 13:05:42 -0700 (PDT) Received: from [192.168.178.23] (247.193.69.111.dynamic.snap.net.nz. [111.69.193.247]) by mx.google.com with ESMTPSA id bx5sm1712750pbd.69.2014.06.24.13.05.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Jun 2014 13:05:41 -0700 (PDT) Message-ID: <53A9DA1A.6050600@gmail.com> Date: Wed, 25 Jun 2014 08:05:46 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Michael Behringer (mbehring)" References: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BCA03D@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BCA03D@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/YpCUnzhH9_RM4xPNOBc17f6qlcE Cc: "nmrg@irtf.org" , "anima@ietf.org" Subject: Re: [Anima] Updating draft-irtf-nmrg-autonomic-network-definitions-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: Tue, 24 Jun 2014 20:05:44 -0000 Michael, I think that's all reasonable; I will re-read the whole draft when you circulate it to the co-authors. ... > 3. Use case section. > In the same email (link above) I proposed some text for the use case section. But frankly, I think this is overtaken by the discussion we had on the list, and out of date. > We also want to drive this document to publication soon, so procedural issues such as how to report use cases should really not be there any more. > I suggest we just remove this section completely, since IMO it is not required for the document to be useful and complete. Thoughts? I agree. I think the use cases will be very valuable in confirming solution requirements, but this topic doesn't really belong with the definitions. Brian From nobody Tue Jun 24 13:20:00 2014 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 CF0D01B27C4 for ; Tue, 24 Jun 2014 13:19:58 -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 4igqpi8mXuju for ; Tue, 24 Jun 2014 13:19:56 -0700 (PDT) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C52671B27DE for ; Tue, 24 Jun 2014 13:19:56 -0700 (PDT) Received: by mail-pb0-f45.google.com with SMTP id rr13so686868pbb.32 for ; Tue, 24 Jun 2014 13:19:56 -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=DYcxnPbAcXytv+aBhTo+7xB/9DEwY/BJ9IiVethWyts=; b=ePc+DzawHeGXUR64kr2LTekz4Iic2QOy+5TOJFyDbchqlwuZKdT0CXwzeF90VS72er KJeclBcvMRJflLFk787LxLF0pPxZmPbvTyKX1QRQlianak3kLL2tBcsdhQm37sZlU5Qt WsGCqQjY/4crDUinv+QwFzxVJS4ZApF3OPJhtjlCOmOH24A/r0XBdNGZIf3m6XCyG644 m1KcfUngM5fguouh2jP/eKLNeNqul30ibWKNpJ+O6sLfbMx3Y882sXwGS3FVudZ2R/Zw VgQTfB9DSIb6rSzTsUB3XRypNXGv6LhMZAfnqshFo/YaZ7Lh3vx6I0gmPNDBz3PM9Oso Bt5A== X-Received: by 10.66.148.70 with SMTP id tq6mr4906917pab.56.1403641196450; Tue, 24 Jun 2014 13:19:56 -0700 (PDT) Received: from [192.168.178.23] (247.193.69.111.dynamic.snap.net.nz. [111.69.193.247]) by mx.google.com with ESMTPSA id nh8sm1777039pbc.25.2014.06.24.13.19.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Jun 2014 13:19:55 -0700 (PDT) Message-ID: <53A9DD71.5030609@gmail.com> Date: Wed, 25 Jun 2014 08:20:01 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: anima@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/oYL3en4XdONdsgXIgXY8NS9zoVk Subject: [Anima] UCAN BOF scheduled in Toronto 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, 24 Jun 2014 20:19:59 -0000 According to the draft agenda, the UCAN BOF (Use Cases for Autonomic Networking) is scheduled for: 1300-1500 EDT Wednesday Afternoon Session I in the Ballroom. The BOF description including the reading list is at http://trac.tools.ietf.org/bof/trac/wiki/WikiStart#UCANApprovedforIETF90 There's a draft agenda there but it will definitely change. NMRG is Monday afternoon, so the BOF chairs will coordinate with the NMRG chairs to avoid unnecessary overlap. (Reminder: IETF agendas are subject to change, up to and during the meeting.) Regards Brian Carpenter From nobody Wed Jun 25 01:34:43 2014 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 119201B2B0F for ; Wed, 25 Jun 2014 01:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 FAAbOp7KkoIk for ; Wed, 25 Jun 2014 01:34:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B4501B2ADD for ; Wed, 25 Jun 2014 01:34:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGL20478; Wed, 25 Jun 2014 08:34:38 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 25 Jun 2014 09:34:37 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.249]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Wed, 25 Jun 2014 16:34:30 +0800 From: Sheng Jiang To: "Michael Behringer (mbehring)" , "anima@ietf.org" , "nmrg@irtf.org" Thread-Topic: Updating draft-irtf-nmrg-autonomic-network-definitions-00 Thread-Index: Ac+Ps8dVKhhDDzh8R4WTmNCrIuSMYgAmu8DA Date: Wed, 25 Jun 2014 08:34:30 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AEBC73A@nkgeml512-mbx.china.huawei.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BCA03D@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BCA03D@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.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/anima/WnbrOCjAGPUjGJ2VBAjXH4DKqfM Subject: Re: [Anima] Updating draft-irtf-nmrg-autonomic-network-definitions-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: Wed, 25 Jun 2014 08:34:42 -0000 SGksIE1pY2hhZWwsDQoNCllvdXIgc3VnZ2VzdGlvbnMgbG9va3MgZ29vZC4gDQoNCk9uZSBjb21t ZW50czogdGhlIGN1cnJlbnQgZGVmaW5pdGlvbiBvZiBhdXRvbm9taWMgbmV0d29yayBsb29rcyB2 YWd1ZS4gTWF5IEkgcHJvcG9zZSB0byBtb2RpZnkgaXQ6IGEgbmV0d29yayB3aGljaCBlbXBsb3lz IGF1dG9ub21pYyBmdW5jdGlvbnMgbmV0d29yay13aWRlLg0KDQpCZXN0IHJlZ2FyZHMsDQoNClNo ZW5nDQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IEFuaW1hIFttYWlsdG86 YW5pbWEtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1pY2hhZWwNCj5CZWhyaW5nZXIg KG1iZWhyaW5nKQ0KPlNlbnQ6IFR1ZXNkYXksIEp1bmUgMjQsIDIwMTQgOTo1NSBQTQ0KPlRvOiBh bmltYUBpZXRmLm9yZzsgbm1yZ0BpcnRmLm9yZw0KPlN1YmplY3Q6IFtBbmltYV0gVXBkYXRpbmcg ZHJhZnQtaXJ0Zi1ubXJnLWF1dG9ub21pYy1uZXR3b3JrLWRlZmluaXRpb25zLTAwDQo+DQo+Tk1S RywgQW5pbWEsDQo+DQo+SGF2aW5nIGdvbmUgdGhyb3VnaCBmZWVkYmFjaywgYW5kIHJlLXJlYWRp bmcgdGhlIGRvY3VtZW50IG15c2VsZiwgaGVyZSBpcyBhDQo+bGlzdCBvZiBjaGFuZ2VzIEknbSBw cm9wb3NpbmcgdG8gbWFrZSB0bw0KPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWly dGYtbm1yZy1hdXRvbm9taWMtbmV0d29yay1kZWZpbml0aW9ucy0wMDoNCj4NCj5IaWdoIGxldmVs LCBJIHRoaW5rIHRoZSAibWVhdCIgb2YgdGhlIGRvY3VtZW50LCBzZWN0aW9ucyAzLCA0IGFuZCA2 IGFyZSBwcmV0dHkNCj5jb21wbGV0ZSBhbmQgY29ycmVjdC4gSWYgYW55b25lIHRoaW5rcyB3ZSdy ZSBtaXNzaW5nIGFuIGltcG9ydGFudCBkZXNpZ24NCj5nb2FsIG9yIGEgbm9uLWRlc2lnbiBnb2Fs LCBwbGVhc2Ugc3BlYWsgdXAhDQo+DQo+U29tZSBkZXRhaWxzOg0KPg0KPjEuIFNlY3Rpb24gMy4x LiBhbHdheXMgcmVmZXJzIHRvICJub2RlcyIuIFdlIHNob3VsZCByZXBocmFzZSB0aGlzIHRvDQo+ ImZ1bmN0aW9ucyIuIFRoZSBwcmltYXJ5IGdvYWwgaGVyZSBpcyBub3QgdG8gcHJvZHVjZSBhIGZ1 bGx5IGF1dG9ub21pYyBub2RlDQo+b3IgbmV0d29yaywgYnV0IGF1dG9ub21pYyBmdW5jdGlvbnMu IEZvciB0aGUgZm9yZXNlZWFibGUgZnV0dXJlIGZ1bGx5DQo+YXV0b25vbWljIG5vZGVzL25ldHdv cmtzIHdpbGwgcmVtYWluIHRoZSBleGNlcHRpb24uDQo+VGhlcmVmb3JlOiBzL25vZGUvZnVuY3Rp b24vIGluIHRoaXMgc2VjdGlvbi4NCj5BY3R1YWxseSwgYWxzbyBsYXRlciBvbiBpbiB0aGUgZG9j IHRoZSBkb2MgcmVmZXJlbmNlcyBzb21ldGltZXMgIm5vZGVzIiBvcg0KPiJ0aGUgbmV0d29yayIu IEkgc3VnZ2VzdCB0byBjaGFuZ2UgdGhhdCB0byAiZnVuY3Rpb24iLg0KPg0KPjIuIENvbW1vbiBp bmZyYXN0cnVjdHVyZS4NCj5JbiBteSBtYWlsDQo+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFy Y2hpdmUvd2ViL25tcmcvY3VycmVudC9tc2cwMTUxMi5odG1sIEkNCj5zdWdnZXN0ZWQgdG8gYWRk IHRvIHRoZSBkZXNpZ24gZ29hbHM6DQo+DQo+PHNlY3Rpb24gdGl0bGU9IkNvbW1vbiBBdXRvbm9t aWMgTmV0d29ya2luZyBJbmZyYXN0cnVjdHVyZSI+DQo+CTx0Pjx4cmVmIHRhcmdldD0iSS1ELmly dGYtbm1yZy1hbi1nYXAtYW5hbHlzaXMiLz4gcG9pbnRzIG91dCB0aGF0IHRoZXJlDQo+YXJlIGFs cmVhZHkgYSBudW1iZXIgb2YgZnVsbHkgb3IgcGFydGlhbGx5IGF1dG9ub21pYyBmdW5jdGlvbnMg YXZhaWxhYmxlIHRvZGF5Lg0KPkhvd2V2ZXIsIHRoZXkgYXJlIGxhcmdlbHkgaW5kZXBlbmRlbnQs IGFuZCBlYWNoIGhhcyBpdHMgb3duIG1ldGhvZHMgYW5kDQo+cHJvdG9jb2xzIHRvIGNvbW11bmlj YXRlLCBkaXNjb3ZlciwgZGVmaW5lIGFuZCBkaXN0cmlidXRlIHBvbGljeSwgZXRjLiA8L3Q+DQo+ CTx0PlRoZSBnb2FsIG9mIHRoZSB3b3JrIG9uIGF1dG9ub21pYyBuZXR3b3JraW5nIGluIHRoZSBJ RVRGIGlzDQo+dGhlcmVmb3JlIG5vdCBqdXN0IHRvIGNyZWF0ZSBhdXRvbm9taWMgZnVuY3Rpb25z LCBidXQgdG8gZGVmaW5lIGEgY29tbW9uDQo+aW5mcmFzdHJ1Y3R1cmUgdGhhdCBhdXRvbm9taWMg ZnVuY3Rpb25zIGNhbiB1c2UuIFRoaXMgYXV0b25vbWljIG5ldHdvcmtpbmcNCj5pbmZyYXN0cnVj dHVyZSBtYXkgY29udGFpbiBjb21tb24gY29udHJvbCBhbmQgbWFuYWdlbWVudCBmdW5jdGlvbnMg c3VjaA0KPmFzIG1lc3NhZ2luZywgc2VydmljZSBkaXNjb3ZlcnksIG5lZ290aWF0aW9uLCBpbnRl bnQgZGlzdHJpYnV0aW9uLCBldGMuIEENCj5jb21tb24gYXBwcm9hY2ggdG8gZGVmaW5lIGFuZCBt YW5hZ2UgaW50ZW50IGlzIGFsc28gcmVxdWlyZWQuIDwvdD4NCj4JPHQ+UmVmZXIgdG8gdGhlIHJl ZmVyZW5jZSBtb2RlbCBiZWxvdzogQWxsIHRoZSBjb21wb25lbnRzIGFyb3VuZCB0aGUNCj4iYXV0 b25vbWljIHNlcnZpY2UgYWdlbnRzIiBzaG91bGQgYmUgY29tbW9uIGNvbXBvbmVudHMsIHN1Y2gg dGhhdCB0aGUNCj5hdXRvbm9taWMgc2VydmljZSBhZ2VudHMgZG8gbm90IGhhdmUgdG8gcmVwbGlj YXRlIGNvbW1vbiB0YXNrcyBpbmRpdmlkdWFsbHkuDQo+PC90Pg0KPiAgICAgIDwvc2VjdGlvbj4N Cj4NCj5Vbmxlc3MgSSBtaXNzZWQgaXQsIEkgaGF2ZW4ndCBzZWVuIGFueSBuZWdhdGl2ZSBjb21t ZW50cyBvbiB0aGF0IHNlY3Rpb24sIHNvDQo+SSdsbCBhZGQgaXQgdG8gdGhlIG5ldyB2ZXJzaW9u Lg0KPg0KPjMuIFVzZSBjYXNlIHNlY3Rpb24uDQo+SW4gdGhlIHNhbWUgZW1haWwgKGxpbmsgYWJv dmUpIEkgcHJvcG9zZWQgc29tZSB0ZXh0IGZvciB0aGUgdXNlIGNhc2Ugc2VjdGlvbi4NCj5CdXQg ZnJhbmtseSwgSSB0aGluayB0aGlzIGlzIG92ZXJ0YWtlbiBieSB0aGUgZGlzY3Vzc2lvbiB3ZSBo YWQgb24gdGhlIGxpc3QsIGFuZA0KPm91dCBvZiBkYXRlLg0KPldlIGFsc28gd2FudCB0byBkcml2 ZSB0aGlzIGRvY3VtZW50IHRvIHB1YmxpY2F0aW9uIHNvb24sIHNvIHByb2NlZHVyYWwgaXNzdWVz DQo+c3VjaCBhcyBob3cgdG8gcmVwb3J0IHVzZSBjYXNlcyBzaG91bGQgcmVhbGx5IG5vdCBiZSB0 aGVyZSBhbnkgbW9yZS4NCj5JIHN1Z2dlc3Qgd2UganVzdCByZW1vdmUgdGhpcyBzZWN0aW9uIGNv bXBsZXRlbHksIHNpbmNlIElNTyBpdCBpcyBub3QgcmVxdWlyZWQNCj5mb3IgdGhlIGRvY3VtZW50 IHRvIGJlIHVzZWZ1bCBhbmQgY29tcGxldGUuIFRob3VnaHRzPw0KPg0KPkFtIEkgbWlzc2luZyBh bnkgZmVlZGJhY2ssIG9yIHBvaW50cyB3ZSBkaXNjdXNzZWQ/IElmIHNvLCBwbGVhc2UgbGV0IG1l IGtub3chDQo+DQo+SSdtIGZpbmFsaXNpbmcgdmVyc2lvbiAtMDEgb2YgdGhlIGRvY3VtZW50IG5v dy4gSSdsbCBjaXJjdWxhdGUgZmlyc3QgYW1vbmdzdCB0aGUNCj5hdXRob3JzLCB0aGVuIHBvc3Qg dGhlIHJlc3VsdC4NCj4NCj5NaWNoYWVsDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj5BbmltYSBtYWlsaW5nIGxpc3QNCj5BbmltYUBpZXRmLm9y Zw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWENCg== From nobody Wed Jun 25 17:44:33 2014 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 07CEB1B29E8 for ; Wed, 25 Jun 2014 17:44: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 od-HHhB2v5JV for ; Wed, 25 Jun 2014 17:44:27 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACF5E1B29E6 for ; Wed, 25 Jun 2014 17:44:27 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id r10so2298439pdi.37 for ; Wed, 25 Jun 2014 17:44: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:content-type:content-transfer-encoding; bh=Syq80W2BIcJUWt989DeZqhNfhPGgANuggOAYMNxNgI4=; b=sUzQ9toMvMKL4Ps7T77q/4ApNF0hy4kPZpf2F+74/WUXBJfHVkgsSDR2Q5NrbdOzPw 9QcPy6gxGEDhDVszhg/fIe7XPneqJkcWDz4jWKpgriCXi7Vr0TMFIVN/lAxq1k4JXLcj leTH2K5X3ZugoZn93twzJOPNJZhBGEhV/2quOmN5c27J7MAkRjIU8Hiv7qXfckKnki4Y 7uzzSIKzEO4Yksj4YZl969q09fMlGRn3h84oPcYOM34oOXioEHreLW+nQL+sdHEK5l82 BfcukdxF5BtuZG27sB0P9muIywivOzVfoBEMfD97yxPO6NEr1XZzOXRRztF2RVj6p9OW 703Q== X-Received: by 10.66.231.139 with SMTP id tg11mr16327711pac.87.1403743467317; Wed, 25 Jun 2014 17:44:27 -0700 (PDT) Received: from [192.168.178.23] (153.199.69.111.dynamic.snap.net.nz. [111.69.199.153]) by mx.google.com with ESMTPSA id vy5sm25740492pac.13.2014.06.25.17.44.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Jun 2014 17:44:26 -0700 (PDT) Message-ID: <53AB6CF3.1010103@gmail.com> Date: Thu, 26 Jun 2014 12:44:35 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: anima@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/cc8JAM1ZNPNZRo7SDcz5jVLaF50 Subject: [Anima] [Fwd: I-D Action: draft-jiang-config-negotiation-protocol-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, 26 Jun 2014 00:44:30 -0000 Hi, this is FYI as this is a solution draft and the anima discussion has not yet reached that stage. Discussion is welcome, of course. Brian -------- Original Message -------- Subject: I-D Action: draft-jiang-config-negotiation-protocol-02.txt Date: Wed, 25 Jun 2014 13:59:05 -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 : Configuration Discovery and Negotiation Protocol for Network Devices Authors : Sheng Jiang Brian Carpenter Bing Liu Filename : draft-jiang-config-negotiation-protocol-02.txt Pages : 26 Date : 2014-06-25 Abstract: This document defines a new protocol that enables intelligent devices to dynamically discover and negotiate their configuration with counterpart devices. This document only defines a general protocol as a negotiation platform while the negotiation objectives for specific scenarios are to be described in separate documents. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-jiang-config-negotiation-protocol/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-jiang-config-negotiation-protocol-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-jiang-config-negotiation-protocol-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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 Thu Jun 26 03:23:43 2014 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 D18B81B2B27 for ; Thu, 26 Jun 2014 03:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxD6-hpWIsF4 for ; Thu, 26 Jun 2014 03:23:39 -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 CB8A21B2B11 for ; Thu, 26 Jun 2014 03:23:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2246; q=dns/txt; s=iport; t=1403778220; x=1404987820; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=2tldV/M+Vjp/d3+Fey0iPbbEoK1gXL/q8aW5I92PHLY=; b=BFHvq2woKukGj2GVM987/rxFYyNIolLakoXdvP9aGcpO2lHH0+SnW/m9 HXHR/f+Jlf8LlMtm+TvgJCU6SZF9iQ6+hEZ1NjvcNSb560PNEaMiHyfMu HMZ4LrfhKxOlKOfpVBkSNvT2uRR0q1FH3yxJXsvSMMDVH9RkdbOQ1iR+B o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnAGAObzq1OtJA2G/2dsb2JhbABagw2BLIJupy8BAQEBAQEFAWyYbQEZcRZ1hAMBAQEDASMRUQQCAQgRBAEBAwIGHQMCAgIwFAEICAEBBAESCIgyCKU3nVYXgSuEOYhrOAaCcTaBFgEErkeDQoIw X-IronPort-AV: E=Sophos;i="5.01,552,1400025600"; d="scan'208";a="332680056" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-9.cisco.com with ESMTP; 26 Jun 2014 10:23:39 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s5QANbVo007602 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Jun 2014 10:23:38 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Thu, 26 Jun 2014 05:23:37 -0500 From: "Michael Behringer (mbehring)" To: Sheng Jiang , "anima@ietf.org" , "nmrg@irtf.org" Thread-Topic: Updating draft-irtf-nmrg-autonomic-network-definitions-00 Thread-Index: Ac+Ps8dVKhhDDzh8R4WTmNCrIuSMYgAmu8DAADYwkFA= Date: Thu, 26 Jun 2014 10:23:36 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BD222A@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BCA03D@xmb-rcd-x14.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AEBC73A@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AEBC73A@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.137] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/anima/UKaeSkJnWU8UK5eOeP-JvSWr_TY Subject: Re: [Anima] Updating draft-irtf-nmrg-autonomic-network-definitions-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: Thu, 26 Jun 2014 10:23:41 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBTaGVuZyBKaWFuZyBbbWFpbHRv OmppYW5nc2hlbmdAaHVhd2VpLmNvbV0NCj4gU2VudDogMjUgSnVuZSAyMDE0IDEwOjM1DQo+IFRv OiBNaWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpOyBhbmltYUBpZXRmLm9yZzsgbm1yZ0BpcnRm Lm9yZw0KPiBTdWJqZWN0OiBSRTogVXBkYXRpbmcgZHJhZnQtaXJ0Zi1ubXJnLWF1dG9ub21pYy1u ZXR3b3JrLWRlZmluaXRpb25zLTAwDQo+IA0KPiBIaSwgTWljaGFlbCwNCj4gDQo+IFlvdXIgc3Vn Z2VzdGlvbnMgbG9va3MgZ29vZC4NCj4gDQo+IE9uZSBjb21tZW50czogdGhlIGN1cnJlbnQgZGVm aW5pdGlvbiBvZiBhdXRvbm9taWMgbmV0d29yayBsb29rcyB2YWd1ZS4NCj4gTWF5IEkgcHJvcG9z ZSB0byBtb2RpZnkgaXQ6IGEgbmV0d29yayB3aGljaCBlbXBsb3lzIGF1dG9ub21pYyBmdW5jdGlv bnMNCj4gbmV0d29yay13aWRlLg0KDQpUaGFua3MgZm9yIHRoZSBzdWdnZXN0aW9uIFNoZW5nLiBX ZWxsLCBJIHRoaW5rIHRoZSBkZWZpbml0aW9uIGlzIHJlY3Vyc2l2ZSwgYW5kIGFjdHVhbGx5IERP RVMgcmVmbGVjdCB3aGF0IHlvdSdyZSBzdWdnZXN0aW5nLCBiZWNhdXNlIGl0IHNheXM6IA0KDQog ICAgICA8dD5BdXRvbm9taWMgTmV0d29yazogQSBuZXR3b3JrIGNvbnRhaW5pbmcgYXV0b25vbWlj IG5vZGVzLjwvdD4NCmFuZCANCiAgICAgIDx0PkF1dG9ub21pYyBOb2RlOiBBIG5vZGUgd2hpY2gg ZW1wbG95cyBhdXRvbm9taWMgZnVuY3Rpb25zLiBJdCBtYXkNCiAgICAgIG9wZXJhdGUgb24gYW55 IGxheWVyIG9mIHRoZSBuZXR3b3JraW5nIHN0YWNrLiBFeGFtcGxlcyBhcmUgcm91dGVycywNCiAg ICAgIHN3aXRjaGVzLCBwZXJzb25hbCBjb21wdXRlcnMsIGNhbGwgbWFuYWdlcnMsIGV0Yy48L3Q+ DQoNClRoZSBvbmx5IHRoaW5nIHRoYXQncyBub3QgY292ZXJlZCBpcyB0aGUgIm5ldHdvcmsgd2lk ZSIuIEJ1dCB0aGF0J3MgYWxzbyBub3QgbmVjZXNzYXJpbHkgdHJ1ZSwgYmVjYXVzZSBhbiBhdXRv bm9taWMgZnVuY3Rpb24gY291bGQgd2VsbCBzcGFuIG9ubHkgYSBmZXcgZGV2aWNlcy4gDQoNCldl IGNvdWxkIGNoYW5nZSB0aGUgQXV0b25vbWljIEZ1bmN0aW9uIGRlZmluaXRpb24gdG8gKGxhc3Qg c2VudGVuY2UgYWRkZWQpOiANCg0KICAgICAgPHQ+QXV0b25vbWljIEZ1bmN0aW9uOiBBIGZ1bmN0 aW9uIHdoaWNoIHJlcXVpcmVzIG5vIGNvbmZpZ3VyYXRpb24sIGFuZA0KICAgICAgY2FuIGRlcml2 ZSBhbGwgcmVxdWlyZWQgaW5mb3JtYXRpb24gZWl0aGVyIHRocm91Z2ggc2VsZi1rbm93bGVkZ2Us IGRpc2NvdmVyeSAgICANCiAgICAgIG9yIHRocm91Z2ggaW50ZW50LiBUeXBpY2FsbHkgYW4gYXV0 b25vbWljIGZ1bmN0aW9uIHNwYW5zIHNldmVyYWwgbm9kZXMuPC90Pg0KDQpXaGF0IGRvIHlvdSB0 aGluaz8gSSdtIGEgYml0IGluIGJldHdlZW4gInllcywgdGhpcyBpcyBtb3JlIHByZWNpc2UiLCBh bmQgInRoaXMgZG9lc24ndCBhZGQgbXVjaCB2YWx1ZSBhbmQgY29tcGxpY2F0ZXMgdGhpbmdzIi4g U2xpZ2h0IHRlbmRlbmN5IHRvIGFncmVlIHRvIGFkZCBpdC4gDQoNClRob3VnaHRzPyANCg0KTWlj aGFlbA0KDQoNCj4gDQo+IEJlc3QgcmVnYXJkcywNCj4gDQo+IFNoZW5nDQo= From nobody Thu Jun 26 18:33:34 2014 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 DC34B1B30A3 for ; Thu, 26 Jun 2014 18:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 B0hK9BduRVQ0 for ; Thu, 26 Jun 2014 18:33:31 -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 5CA291B3075 for ; Thu, 26 Jun 2014 18:33:31 -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 BGN67745; Fri, 27 Jun 2014 01:33:30 +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; Fri, 27 Jun 2014 02:33:29 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.249]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Fri, 27 Jun 2014 09:33:26 +0800 From: Sheng Jiang To: "Michael Behringer (mbehring)" , "anima@ietf.org" , "nmrg@irtf.org" Thread-Topic: Updating draft-irtf-nmrg-autonomic-network-definitions-00 Thread-Index: Ac+Ps8dVKhhDDzh8R4WTmNCrIuSMYgAmu8DAADYwkFAAHyjQkA== Date: Fri, 27 Jun 2014 01:33:25 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AEC11E3@nkgeml512-mbx.china.huawei.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BCA03D@xmb-rcd-x14.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AEBC73A@nkgeml512-mbx.china.huawei.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BD222A@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BD222A@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.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/anima/3V5G1db6ixe_Awdw-uwer39jmTs Subject: Re: [Anima] Updating draft-irtf-nmrg-autonomic-network-definitions-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, 27 Jun 2014 01:33:33 -0000 Pj4gT25lIGNvbW1lbnRzOiB0aGUgY3VycmVudCBkZWZpbml0aW9uIG9mIGF1dG9ub21pYyBuZXR3 b3JrIGxvb2tzIHZhZ3VlLg0KPj4gTWF5IEkgcHJvcG9zZSB0byBtb2RpZnkgaXQ6IGEgbmV0d29y ayB3aGljaCBlbXBsb3lzIGF1dG9ub21pYyBmdW5jdGlvbnMNCj4+IG5ldHdvcmstd2lkZS4NCj4N Cj5UaGFua3MgZm9yIHRoZSBzdWdnZXN0aW9uIFNoZW5nLiBXZWxsLCBJIHRoaW5rIHRoZSBkZWZp bml0aW9uIGlzIHJlY3Vyc2l2ZSwgYW5kDQo+YWN0dWFsbHkgRE9FUyByZWZsZWN0IHdoYXQgeW91 J3JlIHN1Z2dlc3RpbmcsIGJlY2F1c2UgaXQgc2F5czoNCj4NCj4gICAgICA8dD5BdXRvbm9taWMg TmV0d29yazogQSBuZXR3b3JrIGNvbnRhaW5pbmcgYXV0b25vbWljIG5vZGVzLjwvdD4NCj5hbmQN Cj4gICAgICA8dD5BdXRvbm9taWMgTm9kZTogQSBub2RlIHdoaWNoIGVtcGxveXMgYXV0b25vbWlj IGZ1bmN0aW9ucy4gSXQNCj5tYXkNCj4gICAgICBvcGVyYXRlIG9uIGFueSBsYXllciBvZiB0aGUg bmV0d29ya2luZyBzdGFjay4gRXhhbXBsZXMgYXJlIHJvdXRlcnMsDQo+ICAgICAgc3dpdGNoZXMs IHBlcnNvbmFsIGNvbXB1dGVycywgY2FsbCBtYW5hZ2VycywgZXRjLjwvdD4NCj4NCj5UaGUgb25s eSB0aGluZyB0aGF0J3Mgbm90IGNvdmVyZWQgaXMgdGhlICJuZXR3b3JrIHdpZGUiLiBCdXQgdGhh dCdzIGFsc28gbm90DQo+bmVjZXNzYXJpbHkgdHJ1ZSwgYmVjYXVzZSBhbiBhdXRvbm9taWMgZnVu Y3Rpb24gY291bGQgd2VsbCBzcGFuIG9ubHkgYSBmZXcNCj5kZXZpY2VzLg0KDQpIaSwgTWljaGFl bCwNCg0KVGhlIHBvaW50IGlzIGhvdyBtdWNoIHNjYWxlIG9mIGF1dG9ub21pYyBmdW5jdGlvbiBj YW4gYmUgY2FsbGVkIGFuIGF1dG9ub21pYyBuZXR3b3JrLiBTYXksIGlmIHRoZXJlIGlzIGEgbmV0 d29yayB3aXRoIGh1bmRyZWRzIGRldmljZXMsIHR3byBvZiB0aGVzZSBkZXZpY2VzIGhhcyBiZWVu IGRlcGxveWVkIHNvbWUgYXV0b25vbWljIGZ1bmN0aW9ucy4gQ2FuIHRoZSBuZXR3b3JrIGJlIGNs YWltZWQgYXMgYW4gYXV0b25vbWljIG5ldHdvcms/ICJOZXR3b3JrIHdpZGUiIGRvZXMgbm90IG1l YW4gZXZlcnkgZGV2aWNlcy4gSXQgbWVhbnMgYSBsYXJnZSBwb3J0aW9uIG9mIHRoZSBuZXR3b3Jr IGhhdmUgYXV0b25vbWljIGZ1bmN0aW9ucy4NCg0KPldlIGNvdWxkIGNoYW5nZSB0aGUgQXV0b25v bWljIEZ1bmN0aW9uIGRlZmluaXRpb24gdG8gKGxhc3Qgc2VudGVuY2UgYWRkZWQpOg0KPg0KPiAg ICAgIDx0PkF1dG9ub21pYyBGdW5jdGlvbjogQSBmdW5jdGlvbiB3aGljaCByZXF1aXJlcyBubyBj b25maWd1cmF0aW9uLA0KPmFuZA0KPiAgICAgIGNhbiBkZXJpdmUgYWxsIHJlcXVpcmVkIGluZm9y bWF0aW9uIGVpdGhlciB0aHJvdWdoIHNlbGYta25vd2xlZGdlLA0KPmRpc2NvdmVyeQ0KPiAgICAg IG9yIHRocm91Z2ggaW50ZW50LiBUeXBpY2FsbHkgYW4gYXV0b25vbWljIGZ1bmN0aW9uIHNwYW5z IHNldmVyYWwNCj5ub2Rlcy48L3Q+DQo+DQo+V2hhdCBkbyB5b3UgdGhpbms/IEknbSBhIGJpdCBp biBiZXR3ZWVuICJ5ZXMsIHRoaXMgaXMgbW9yZSBwcmVjaXNlIiwgYW5kICJ0aGlzDQo+ZG9lc24n dCBhZGQgbXVjaCB2YWx1ZSBhbmQgY29tcGxpY2F0ZXMgdGhpbmdzIi4gU2xpZ2h0IHRlbmRlbmN5 IHRvIGFncmVlIHRvDQo+YWRkIGl0Lg0KDQpUaGlzIGlzIGhlbHBmdWwuIEJ1dCBpdCBkb2VzIG5v dCBhZGRyZXNzIG15IGNvbmNlcm4gcmVnYXJkaW5nIHRvIHRoZSBhdXRvbm9taWMgbmV0d29yayBk ZWZpbml0aW9uLg0KDQpSZWdhcmRzLA0KDQpTaGVuZw0KDQo+VGhvdWdodHM/DQo+DQo+TWljaGFl bA0KPg0KPg0KPj4NCj4+IEJlc3QgcmVnYXJkcywNCj4+DQo+PiBTaGVuZw0K From nobody Fri Jun 27 00:00:31 2014 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 5A42E1B3069 for ; Fri, 27 Jun 2014 00:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWthFEj-h_ZZ for ; Fri, 27 Jun 2014 00:00:26 -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 6F8F01B2ACB for ; Fri, 27 Jun 2014 00:00:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3556; q=dns/txt; s=iport; t=1403852426; x=1405062026; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=V3IQoLT1LcxVGR6u7oHP4EnLhpEXLZUswsRAAgatbvg=; b=VFZEsV1guvp6NOGesksn7KCq7GlBrKZQD4r6xNVaQ5oVhwVSKKDE572B iARjdp9wkb01Bdufbs+jsDX+gqff0Av2/YN5C9vcwAZWMvFAUKSmZDKDP HIETlCrkVnCyofe9gq+tR2aDoXnYo4JwkU2Wve94WvIUBHP15/SfB6KQO 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuMFAEAWrVOtJV2b/2dsb2JhbABbgw2BLIJup0QBAQEBAQEFAW2YfQEZcRZ1hAMBAQEEIxFRBAIBCBEEAQEDAgYdAwICAjAUAQgIAQEEARIIiDqlWJ04F4ErhDmIRCc4BoJxNoEWBa5Og0KBbkI X-IronPort-AV: E=Sophos;i="5.01,558,1400025600"; d="scan'208";a="336015545" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 27 Jun 2014 07:00:25 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s5R70Pau005064 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Jun 2014 07:00:25 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Fri, 27 Jun 2014 02:00:18 -0500 From: "Michael Behringer (mbehring)" To: Sheng Jiang , "anima@ietf.org" , "nmrg@irtf.org" Thread-Topic: Updating draft-irtf-nmrg-autonomic-network-definitions-00 Thread-Index: Ac+Ps8dVKhhDDzh8R4WTmNCrIuSMYgAmu8DAADYwkFAAHyjQkAAMNiqA Date: Fri, 27 Jun 2014 07:00:17 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BD33ED@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BCA03D@xmb-rcd-x14.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AEBC73A@nkgeml512-mbx.china.huawei.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BD222A@xmb-rcd-x14.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AEC11E3@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AEC11E3@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.133] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/anima/mb1UIguSqm2BFAFuczRJqBKjqvg Subject: Re: [Anima] Updating draft-irtf-nmrg-autonomic-network-definitions-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, 27 Jun 2014 07:00:28 -0000 U2hlbmcsIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFNoZW5nIEpp YW5nIFttYWlsdG86amlhbmdzaGVuZ0BodWF3ZWkuY29tXQ0KPiBTZW50OiAyNyBKdW5lIDIwMTQg MDM6MzMNCj4gVG86IE1pY2hhZWwgQmVocmluZ2VyIChtYmVocmluZyk7IGFuaW1hQGlldGYub3Jn OyBubXJnQGlydGYub3JnDQo+IFN1YmplY3Q6IFJFOiBVcGRhdGluZyBkcmFmdC1pcnRmLW5tcmct YXV0b25vbWljLW5ldHdvcmstZGVmaW5pdGlvbnMtMDANCj4gDQo+ID4+IE9uZSBjb21tZW50czog dGhlIGN1cnJlbnQgZGVmaW5pdGlvbiBvZiBhdXRvbm9taWMgbmV0d29yayBsb29rcw0KPiB2YWd1 ZS4NCj4gPj4gTWF5IEkgcHJvcG9zZSB0byBtb2RpZnkgaXQ6IGEgbmV0d29yayB3aGljaCBlbXBs b3lzIGF1dG9ub21pYw0KPiA+PiBmdW5jdGlvbnMgbmV0d29yay13aWRlLg0KPiA+DQo+ID5UaGFu a3MgZm9yIHRoZSBzdWdnZXN0aW9uIFNoZW5nLiBXZWxsLCBJIHRoaW5rIHRoZSBkZWZpbml0aW9u IGlzDQo+ID5yZWN1cnNpdmUsIGFuZCBhY3R1YWxseSBET0VTIHJlZmxlY3Qgd2hhdCB5b3UncmUg c3VnZ2VzdGluZywgYmVjYXVzZSBpdA0KPiBzYXlzOg0KPiA+DQo+ID4gICAgICA8dD5BdXRvbm9t aWMgTmV0d29yazogQSBuZXR3b3JrIGNvbnRhaW5pbmcgYXV0b25vbWljIG5vZGVzLjwvdD4NCj4g PmFuZA0KPiA+ICAgICAgPHQ+QXV0b25vbWljIE5vZGU6IEEgbm9kZSB3aGljaCBlbXBsb3lzIGF1 dG9ub21pYyBmdW5jdGlvbnMuIEl0DQo+ID5tYXkNCj4gPiAgICAgIG9wZXJhdGUgb24gYW55IGxh eWVyIG9mIHRoZSBuZXR3b3JraW5nIHN0YWNrLiBFeGFtcGxlcyBhcmUgcm91dGVycywNCj4gPiAg ICAgIHN3aXRjaGVzLCBwZXJzb25hbCBjb21wdXRlcnMsIGNhbGwgbWFuYWdlcnMsIGV0Yy48L3Q+ DQo+ID4NCj4gPlRoZSBvbmx5IHRoaW5nIHRoYXQncyBub3QgY292ZXJlZCBpcyB0aGUgIm5ldHdv cmsgd2lkZSIuIEJ1dCB0aGF0J3MNCj4gPmFsc28gbm90IG5lY2Vzc2FyaWx5IHRydWUsIGJlY2F1 c2UgYW4gYXV0b25vbWljIGZ1bmN0aW9uIGNvdWxkIHdlbGwNCj4gPnNwYW4gb25seSBhIGZldyBk ZXZpY2VzLg0KPiANCj4gSGksIE1pY2hhZWwsDQo+IA0KPiBUaGUgcG9pbnQgaXMgaG93IG11Y2gg c2NhbGUgb2YgYXV0b25vbWljIGZ1bmN0aW9uIGNhbiBiZSBjYWxsZWQgYW4NCj4gYXV0b25vbWlj IG5ldHdvcmsuIFNheSwgaWYgdGhlcmUgaXMgYSBuZXR3b3JrIHdpdGggaHVuZHJlZHMgZGV2aWNl cywgdHdvIG9mDQo+IHRoZXNlIGRldmljZXMgaGFzIGJlZW4gZGVwbG95ZWQgc29tZSBhdXRvbm9t aWMgZnVuY3Rpb25zLiBDYW4gdGhlDQo+IG5ldHdvcmsgYmUgY2xhaW1lZCBhcyBhbiBhdXRvbm9t aWMgbmV0d29yaz8gIk5ldHdvcmsgd2lkZSIgZG9lcyBub3QNCj4gbWVhbiBldmVyeSBkZXZpY2Vz LiBJdCBtZWFucyBhIGxhcmdlIHBvcnRpb24gb2YgdGhlIG5ldHdvcmsgaGF2ZQ0KPiBhdXRvbm9t aWMgZnVuY3Rpb25zLg0KDQpUaGUgZnVuZGFtZW50YWwgcXVlc3Rpb24gaXMgd2hldGhlciB3ZSB3 YW50IHRvIGluY2x1ZGUgYXV0b25vbWljIGZ1bmN0aW9ucyB0aGF0IGZvciBleGFtcGxlIGp1c3Qg aW52b2x2ZSB0d28gZGV2aWNlcy4gQW5kIEkgd291bGQgc3Ryb25nbHkgc3VnZ2VzdCBZRVMsIGZv ciBleGFtcGxlIEkgY2FuIHNlZSBpbXByb3ZlbWVudHMgb24gVlJSUCBpbiB0aGUgZnV0dXJlIGFz IGFuIGF1dG9ub21pYyBmdW5jdGlvbiAoeW91IGNvdWxkIGFscmVhZHkgY2xhaW0gc29tZSBsaW1p dGVkIGF1dG9ub215LCBpbiBmYWN0KS4gV2Ugd2FudCB0byBjb3ZlciB0aGF0LCByaWdodD8gDQoN Ck1pY2hhZWwNCg0KPiA+V2UgY291bGQgY2hhbmdlIHRoZSBBdXRvbm9taWMgRnVuY3Rpb24gZGVm aW5pdGlvbiB0byAobGFzdCBzZW50ZW5jZQ0KPiBhZGRlZCk6DQo+ID4NCj4gPiAgICAgIDx0PkF1 dG9ub21pYyBGdW5jdGlvbjogQSBmdW5jdGlvbiB3aGljaCByZXF1aXJlcyBubw0KPiA+Y29uZmln dXJhdGlvbiwgYW5kDQo+ID4gICAgICBjYW4gZGVyaXZlIGFsbCByZXF1aXJlZCBpbmZvcm1hdGlv biBlaXRoZXIgdGhyb3VnaA0KPiA+c2VsZi1rbm93bGVkZ2UsIGRpc2NvdmVyeQ0KPiA+ICAgICAg b3IgdGhyb3VnaCBpbnRlbnQuIFR5cGljYWxseSBhbiBhdXRvbm9taWMgZnVuY3Rpb24gc3BhbnMg c2V2ZXJhbA0KPiA+bm9kZXMuPC90Pg0KPiA+DQo+ID5XaGF0IGRvIHlvdSB0aGluaz8gSSdtIGEg Yml0IGluIGJldHdlZW4gInllcywgdGhpcyBpcyBtb3JlIHByZWNpc2UiLA0KPiA+YW5kICJ0aGlz IGRvZXNuJ3QgYWRkIG11Y2ggdmFsdWUgYW5kIGNvbXBsaWNhdGVzIHRoaW5ncyIuIFNsaWdodA0K PiA+dGVuZGVuY3kgdG8gYWdyZWUgdG8gYWRkIGl0Lg0KPiANCj4gVGhpcyBpcyBoZWxwZnVsLiBC dXQgaXQgZG9lcyBub3QgYWRkcmVzcyBteSBjb25jZXJuIHJlZ2FyZGluZyB0byB0aGUNCj4gYXV0 b25vbWljIG5ldHdvcmsgZGVmaW5pdGlvbi4NCj4gDQo+IFJlZ2FyZHMsDQo+IA0KPiBTaGVuZw0K PiANCj4gPlRob3VnaHRzPw0KPiA+DQo+ID5NaWNoYWVsDQo+ID4NCj4gPg0KPiA+Pg0KPiA+PiBC ZXN0IHJlZ2FyZHMsDQo+ID4+DQo+ID4+IFNoZW5nDQo= From nobody Fri Jun 27 00:39:14 2014 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 1CF2A1B278A for ; Fri, 27 Jun 2014 00:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 wn3m8YLd9NQ2 for ; Fri, 27 Jun 2014 00:39: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 7890D1A0047 for ; Fri, 27 Jun 2014 00:39:04 -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 BJI02042; Fri, 27 Jun 2014 07:39:03 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 27 Jun 2014 08:39:02 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.249]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Fri, 27 Jun 2014 15:38:59 +0800 From: Sheng Jiang To: "Michael Behringer (mbehring)" , "anima@ietf.org" , "nmrg@irtf.org" Thread-Topic: Updating draft-irtf-nmrg-autonomic-network-definitions-00 Thread-Index: Ac+Ps8dVKhhDDzh8R4WTmNCrIuSMYgAmu8DAADYwkFAAHyjQkAAMNiqAAAEyf8A= Date: Fri, 27 Jun 2014 07:38:58 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AEC1488@nkgeml512-mbx.china.huawei.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BCA03D@xmb-rcd-x14.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AEBC73A@nkgeml512-mbx.china.huawei.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BD222A@xmb-rcd-x14.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AEC11E3@nkgeml512-mbx.china.huawei.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BD33ED@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BD33ED@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.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/anima/nqh8vOxXxqKmBppQCK0wjX70Z7A Subject: Re: [Anima] Updating draft-irtf-nmrg-autonomic-network-definitions-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, 27 Jun 2014 07:39:09 -0000 Pj4gPlRoZSBvbmx5IHRoaW5nIHRoYXQncyBub3QgY292ZXJlZCBpcyB0aGUgIm5ldHdvcmsgd2lk ZSIuIEJ1dCB0aGF0J3MNCj4+ID5hbHNvIG5vdCBuZWNlc3NhcmlseSB0cnVlLCBiZWNhdXNlIGFu IGF1dG9ub21pYyBmdW5jdGlvbiBjb3VsZCB3ZWxsDQo+PiA+c3BhbiBvbmx5IGEgZmV3IGRldmlj ZXMuDQo+Pg0KPj4gSGksIE1pY2hhZWwsDQo+Pg0KPj4gVGhlIHBvaW50IGlzIGhvdyBtdWNoIHNj YWxlIG9mIGF1dG9ub21pYyBmdW5jdGlvbiBjYW4gYmUgY2FsbGVkIGFuDQo+PiBhdXRvbm9taWMg bmV0d29yay4gU2F5LCBpZiB0aGVyZSBpcyBhIG5ldHdvcmsgd2l0aCBodW5kcmVkcyBkZXZpY2Vz LCB0d28gb2YNCj4+IHRoZXNlIGRldmljZXMgaGFzIGJlZW4gZGVwbG95ZWQgc29tZSBhdXRvbm9t aWMgZnVuY3Rpb25zLiBDYW4gdGhlDQo+PiBuZXR3b3JrIGJlIGNsYWltZWQgYXMgYW4gYXV0b25v bWljIG5ldHdvcms/ICJOZXR3b3JrIHdpZGUiIGRvZXMgbm90DQo+PiBtZWFuIGV2ZXJ5IGRldmlj ZXMuIEl0IG1lYW5zIGEgbGFyZ2UgcG9ydGlvbiBvZiB0aGUgbmV0d29yayBoYXZlDQo+PiBhdXRv bm9taWMgZnVuY3Rpb25zLg0KPg0KPlRoZSBmdW5kYW1lbnRhbCBxdWVzdGlvbiBpcyB3aGV0aGVy IHdlIHdhbnQgdG8gaW5jbHVkZSBhdXRvbm9taWMgZnVuY3Rpb25zDQo+dGhhdCBmb3IgZXhhbXBs ZSBqdXN0IGludm9sdmUgdHdvIGRldmljZXMuIEFuZCBJIHdvdWxkIHN0cm9uZ2x5IHN1Z2dlc3Qg WUVTLA0KPmZvciBleGFtcGxlIEkgY2FuIHNlZSBpbXByb3ZlbWVudHMgb24gVlJSUCBpbiB0aGUg ZnV0dXJlIGFzIGFuIGF1dG9ub21pYw0KPmZ1bmN0aW9uICh5b3UgY291bGQgYWxyZWFkeSBjbGFp bSBzb21lIGxpbWl0ZWQgYXV0b25vbXksIGluIGZhY3QpLiBXZSB3YW50DQo+dG8gY292ZXIgdGhh dCwgcmlnaHQ/DQoNClRoYXQncyBhIHZhbGlkIHVzZSBjYXNlIGZvciBhdXRvbm9taWMgZnVuY3Rp b24gZGVwbG95bWVudC4gQnV0LCB3aXRoIHRoZXNlIHR3byBkZXZpY2VzIGF1dG9ub21pYyBob3Qg c3RhbmRieSBvciBiYWNrdXAgZWFjaCBvdGhlciwgc2hvdWxkIHRoZSB3aG9sZSBuZXR3b3JrIGJl IGNhbGxlZCBhbiBhdXRvbm9taWMgbmV0d29yaz8gSWYgeW91IHRoaW5rICJuZXR3b3JrLXdpZGUi IGlzIGEgdG9vIGhpZ2ggdGhyZXNob2xkIGZvciBhdXRvbm9taWMgbmV0d29yaywgd2UgY2FuIHdv cmsgb3V0IHNvbWUgbG93ZXIgZGVzY3JpcHRpb24uDQoNClNoZW5nDQo= From nobody Fri Jun 27 02:46:29 2014 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 9DBD41B2F44 for ; Fri, 27 Jun 2014 02:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 X1fmtpZPDXof for ; Fri, 27 Jun 2014 02:46:27 -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 E3C9F1B2F3F for ; Fri, 27 Jun 2014 02:46:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2120; q=dns/txt; s=iport; t=1403862388; x=1405071988; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Q1ocg8J5OpNSx2I5G6lSNDvnux7wSBsoRFUuWIlVarE=; b=jlzOsRA46rGT0L2Y9tp0jeFyIe5LK1lupCAJvycsq1I+g5APf2SZ/9R9 z6zWl8icyfpk/Fiy7oJ+DR+Eb9l7pecK2nSM6sJhbgrM9e8f/6fI51DWA z4D84VQHXG3pbLWpId+w1tpjIa8TrOkeZkkZr4nCFFSkA9cSUtVA4NszG E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuMFALM8rVOtJA2E/2dsb2JhbABbgw1SWqo0AQEBAQEBBQFtkT2HQAGBCRZ1hAMBAQEDAQEBATc0EAcEAgEIEQQBAQsUCQcnCxQJCAIEARIIiDIIDcMYEwSFZIgxEyc4BoMngRYFrk6DQoFuQg X-IronPort-AV: E=Sophos;i="5.01,559,1400025600"; d="scan'208";a="56419208" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-7.cisco.com with ESMTP; 27 Jun 2014 09:46:27 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s5R9kPHG024726 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Jun 2014 09:46:25 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Fri, 27 Jun 2014 04:46:25 -0500 From: "Michael Behringer (mbehring)" To: Sheng Jiang , "anima@ietf.org" , "nmrg@irtf.org" Thread-Topic: [Anima] Updating draft-irtf-nmrg-autonomic-network-definitions-00 Thread-Index: AQHPkdrr6+2vwpJ910WiHlHnnKpqvZuEtJXw Date: Fri, 27 Jun 2014 09:46:24 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BD3776@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BCA03D@xmb-rcd-x14.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AEBC73A@nkgeml512-mbx.china.huawei.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BD222A@xmb-rcd-x14.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AEC11E3@nkgeml512-mbx.china.huawei.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BD33ED@xmb-rcd-x14.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AEC1488@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AEC1488@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.133] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/anima/7t6tueHg0b-sqZHZLMPRY7pYmAQ Subject: Re: [Anima] Updating draft-irtf-nmrg-autonomic-network-definitions-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, 27 Jun 2014 09:46:28 -0000 > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Sheng Jiang > Sent: 27 June 2014 09:39 > To: Michael Behringer (mbehring); anima@ietf.org; nmrg@irtf.org > Subject: Re: [Anima] Updating draft-irtf-nmrg-autonomic-network- > definitions-00 >=20 > >> >The only thing that's not covered is the "network wide". But that's > >> >also not necessarily true, because an autonomic function could well > >> >span only a few devices. > >> > >> Hi, Michael, > >> > >> The point is how much scale of autonomic function can be called an > >> autonomic network. Say, if there is a network with hundreds devices, > >> two of these devices has been deployed some autonomic functions. Can > >> the network be claimed as an autonomic network? "Network wide" does > >> not mean every devices. It means a large portion of the network have > >> autonomic functions. > > > >The fundamental question is whether we want to include autonomic > >functions that for example just involve two devices. And I would > >strongly suggest YES, for example I can see improvements on VRRP in the > >future as an autonomic function (you could already claim some limited > >autonomy, in fact). We want to cover that, right? >=20 > That's a valid use case for autonomic function deployment. But, with thes= e > two devices autonomic hot standby or backup each other, should the whole > network be called an autonomic network? If you think "network-wide" is a > too high threshold for autonomic network, we can work out some lower > description. Indeed, many people will probably imply that what we call an "autonomic net= work" is actually what we define as a "fully autonomic network".=20 Maybe the better phrase would be "partially autonomic network".=20 But, no doubt we'll have more discussions around this at the IETF. I sugges= t to leave it for now, discuss at NMRG how people feel we should call it. O= K?=20 =20 Michael > Sheng > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Fri Jun 27 02:55:33 2014 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 EE0EE1B2F44 for ; Fri, 27 Jun 2014 02:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 5ZhsYMUvzzQ1 for ; Fri, 27 Jun 2014 02:55:29 -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 AA3BB1B2F3B for ; Fri, 27 Jun 2014 02:55:28 -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 BGO03776; Fri, 27 Jun 2014 09:55:27 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 27 Jun 2014 10:55:26 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.249]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Fri, 27 Jun 2014 17:55:20 +0800 From: Sheng Jiang To: "Michael Behringer (mbehring)" , "anima@ietf.org" , "nmrg@irtf.org" Thread-Topic: [Anima] Updating draft-irtf-nmrg-autonomic-network-definitions-00 Thread-Index: AQHPkeytPe7kAOvbJkO8AgJ/3sNQlJuEtauA Date: Fri, 27 Jun 2014 09:55:20 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AEC157F@nkgeml512-mbx.china.huawei.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BCA03D@xmb-rcd-x14.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AEBC73A@nkgeml512-mbx.china.huawei.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BD222A@xmb-rcd-x14.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AEC11E3@nkgeml512-mbx.china.huawei.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BD33ED@xmb-rcd-x14.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AEC1488@nkgeml512-mbx.china.huawei.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BD3776@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BD3776@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.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/anima/PGy6v69SqboD8VQoQSykzcQkx9Y Subject: Re: [Anima] Updating draft-irtf-nmrg-autonomic-network-definitions-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, 27 Jun 2014 09:55:31 -0000 Pj4gPj4gVGhlIHBvaW50IGlzIGhvdyBtdWNoIHNjYWxlIG9mIGF1dG9ub21pYyBmdW5jdGlvbiBj YW4gYmUgY2FsbGVkIGFuDQo+PiA+PiBhdXRvbm9taWMgbmV0d29yay4gU2F5LCBpZiB0aGVyZSBp cyBhIG5ldHdvcmsgd2l0aCBodW5kcmVkcyBkZXZpY2VzLA0KPj4gPj4gdHdvIG9mIHRoZXNlIGRl dmljZXMgaGFzIGJlZW4gZGVwbG95ZWQgc29tZSBhdXRvbm9taWMgZnVuY3Rpb25zLiBDYW4NCj4+ ID4+IHRoZSBuZXR3b3JrIGJlIGNsYWltZWQgYXMgYW4gYXV0b25vbWljIG5ldHdvcms/ICJOZXR3 b3JrIHdpZGUiIGRvZXMNCj4+ID4+IG5vdCBtZWFuIGV2ZXJ5IGRldmljZXMuIEl0IG1lYW5zIGEg bGFyZ2UgcG9ydGlvbiBvZiB0aGUgbmV0d29yayBoYXZlDQo+PiA+PiBhdXRvbm9taWMgZnVuY3Rp b25zLg0KPj4gPg0KPj4gPlRoZSBmdW5kYW1lbnRhbCBxdWVzdGlvbiBpcyB3aGV0aGVyIHdlIHdh bnQgdG8gaW5jbHVkZSBhdXRvbm9taWMNCj4+ID5mdW5jdGlvbnMgdGhhdCBmb3IgZXhhbXBsZSBq dXN0IGludm9sdmUgdHdvIGRldmljZXMuIEFuZCBJIHdvdWxkDQo+PiA+c3Ryb25nbHkgc3VnZ2Vz dCBZRVMsIGZvciBleGFtcGxlIEkgY2FuIHNlZSBpbXByb3ZlbWVudHMgb24gVlJSUCBpbiB0aGUN Cj4+ID5mdXR1cmUgYXMgYW4gYXV0b25vbWljIGZ1bmN0aW9uICh5b3UgY291bGQgYWxyZWFkeSBj bGFpbSBzb21lIGxpbWl0ZWQNCj4+ID5hdXRvbm9teSwgaW4gZmFjdCkuIFdlIHdhbnQgdG8gY292 ZXIgdGhhdCwgcmlnaHQ/DQo+Pg0KPj4gVGhhdCdzIGEgdmFsaWQgdXNlIGNhc2UgZm9yIGF1dG9u b21pYyBmdW5jdGlvbiBkZXBsb3ltZW50LiBCdXQsIHdpdGggdGhlc2UNCj4+IHR3byBkZXZpY2Vz IGF1dG9ub21pYyBob3Qgc3RhbmRieSBvciBiYWNrdXAgZWFjaCBvdGhlciwgc2hvdWxkIHRoZSB3 aG9sZQ0KPj4gbmV0d29yayBiZSBjYWxsZWQgYW4gYXV0b25vbWljIG5ldHdvcms/IElmIHlvdSB0 aGluayAibmV0d29yay13aWRlIiBpcyBhDQo+PiB0b28gaGlnaCB0aHJlc2hvbGQgZm9yIGF1dG9u b21pYyBuZXR3b3JrLCB3ZSBjYW4gd29yayBvdXQgc29tZSBsb3dlcg0KPj4gZGVzY3JpcHRpb24u DQo+DQo+SW5kZWVkLCBtYW55IHBlb3BsZSB3aWxsIHByb2JhYmx5IGltcGx5IHRoYXQgd2hhdCB3 ZSBjYWxsIGFuICJhdXRvbm9taWMNCj5uZXR3b3JrIiBpcyBhY3R1YWxseSB3aGF0IHdlIGRlZmlu ZSBhcyBhICJmdWxseSBhdXRvbm9taWMgbmV0d29yayIuDQo+TWF5YmUgdGhlIGJldHRlciBwaHJh c2Ugd291bGQgYmUgInBhcnRpYWxseSBhdXRvbm9taWMgbmV0d29yayIuDQoNClRoaXMgc291bmRz IGJldHRlciBmb3IgbWUuDQoNCj5CdXQsIG5vIGRvdWJ0IHdlJ2xsIGhhdmUgbW9yZSBkaXNjdXNz aW9ucyBhcm91bmQgdGhpcyBhdCB0aGUgSUVURi4gSSBzdWdnZXN0IHRvDQo+bGVhdmUgaXQgZm9y IG5vdywgZGlzY3VzcyBhdCBOTVJHIGhvdyBwZW9wbGUgZmVlbCB3ZSBzaG91bGQgY2FsbCBpdC4g T0s/DQoNClRoYXQncyBvaywgZm9yIHN1cmUuIDopDQoNClNoZW5nDQoNCj5NaWNoYWVsDQo+DQo+ PiBTaGVuZw0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+IEFuaW1hIG1haWxpbmcgbGlzdA0KPj4gQW5pbWFAaWV0Zi5vcmcNCj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWENCg== From nobody Fri Jun 27 03:13:24 2014 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 4A17E1B2F4F for ; Fri, 27 Jun 2014 03:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehGXA5YUsH-z for ; Fri, 27 Jun 2014 03:13:07 -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 8E0A01B2F35 for ; Fri, 27 Jun 2014 03:13:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3272; q=dns/txt; s=iport; t=1403863986; x=1405073586; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=PNQ9zGlBrOy1iqpprb9ZfG25ia7wPhTok4PYoRlzBPg=; b=LlMoG736L39Rw5WS7cZZEaDKIDjQh2YjBlQNKllMEyO6oEBr4GJCV6m0 7o7/Tm2uI+dn3sB6set+IFhD72Fn8biGPoWvA1FPVLRrVipWYSTMtra9+ doz8G7i76z+qsaD1G6gAQwYGa9i/aXbEKMR7qL2AQAh5omNk+sM7WhioI w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As4HAH1DrVOtJA2N/2dsb2JhbABbgw1SUweCbqdGAQEBAQEBBQFtmH0BGXAWdYQDAQEBBCMRQw4EAgEIEQQBAQMCBh0DAgICMBQBBgEBBQMCBAESCAGIOQgFpWOdNheBK4Q5iGs4BoJxNoEWBZwfki+CAIFCgjA X-IronPort-AV: E=Sophos;i="5.01,559,1400025600"; d="scan'208";a="336076896" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-5.cisco.com with ESMTP; 27 Jun 2014 10:13:05 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s5RAD4SL006187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Jun 2014 10:13:04 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Fri, 27 Jun 2014 05:13:04 -0500 From: "Michael Behringer (mbehring)" To: "nmrg@irtf.org" , "anima@ietf.org" Thread-Topic: New Version Notification for draft-irtf-nmrg-autonomic-network-definitions-01.txt Thread-Index: AQHPkfAES8LHcl/Qh0uLaV91EAdcf5uEvEjg Date: Fri, 27 Jun 2014 10:13:03 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BD3806@xmb-rcd-x14.cisco.com> References: <20140627101020.24416.82468.idtracker@ietfa.amsl.com> In-Reply-To: <20140627101020.24416.82468.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.133] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/anima/trj1eQJCT4NCtUK1jbAdD0lAY04 Subject: [Anima] FW: New Version Notification for draft-irtf-nmrg-autonomic-network-definitions-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, 27 Jun 2014 10:13:10 -0000 Tk1SRywgQW5pbWEsIA0KDQpIZXJlIGlzIHRoZSBsYXRlc3QgdmVyc2lvbiBvZiB0aGUgYXV0b25v bWljcyBkZWZpbml0aW9ucyBhbmQgZGVzaWduIGdvYWxzIGRyYWZ0LiBXZSBiZWxpZXZlIHRoYXQg d2UncmUgdmVyeSBjbG9zZSB0byBsYXN0IGNhbGwsIGFuZCB3b3VsZCByZXF1ZXN0IHJldmlldyBh bmQgZmVlZGJhY2suIA0KDQpJcyB0aGlzIGRvY3VtZW50IHJlYWR5IHRvIGJlIHB1Ymxpc2hlZD8g DQoNCk1pY2hhZWwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+ IFNlbnQ6IDI3IEp1bmUgMjAxNCAxMjoxMA0KPiBUbzogTGF1cmVudCBDaWF2YWdsaWE7IE1heCBQ cml0aWtpbiAocHJpdGlraW4pOyBBbGV4YW5kZXIgQ2xlbW0gKGFsZXgpOyBCcmlhbg0KPiBFLiBD YXJwZW50ZXI7IFNoZW5nIEppYW5nOyBTdGVpbnRob3IgQmphcm5hc29uIChzYmphcm5hcyk7IE1p Y2hhZWwgQmVocmluZ2VyDQo+IChtYmVocmluZyk7IE1heCBQcml0aWtpbiAocHJpdGlraW4pOyBT dGVpbnRob3IgQmphcm5hc29uIChzYmphcm5hcyk7IE1pY2hhZWwNCj4gQmVocmluZ2VyIChtYmVo cmluZyk7IEJyaWFuIENhcnBlbnRlcjsgQWxleGFuZGVyIENsZW1tIChhbGV4KTsgTGF1cmVudA0K PiBDaWF2YWdsaWE7IFNoZW5nIEppYW5nDQo+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtaXJ0Zi1ubXJnLWF1dG9ub21pYy1uZXR3b3JrLQ0KPiBkZWZpbml0aW9u cy0wMS50eHQNCj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaXJ0Zi1ubXJn LWF1dG9ub21pYy1uZXR3b3JrLWRlZmluaXRpb25zLTAxLnR4dA0KPiBoYXMgYmVlbiBzdWNjZXNz ZnVsbHkgc3VibWl0dGVkIGJ5IE1pY2hhZWwgQmVocmluZ2VyIGFuZCBwb3N0ZWQgdG8gdGhlDQo+ IElFVEYgcmVwb3NpdG9yeS4NCj4gDQo+IE5hbWU6CQlkcmFmdC1pcnRmLW5tcmctYXV0b25vbWlj LW5ldHdvcmstZGVmaW5pdGlvbnMNCj4gUmV2aXNpb246CTAxDQo+IFRpdGxlOgkJQXV0b25vbWlj IE5ldHdvcmtpbmcgLSBEZWZpbml0aW9ucyBhbmQgRGVzaWduIEdvYWxzDQo+IERvY3VtZW50IGRh dGU6CTIwMTQtMDYtMjcNCj4gR3JvdXA6CQlubXJnDQo+IFBhZ2VzOgkJMTMNCj4gVVJMOiAgICAg ICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlydGYtbm1y Zy1hdXRvbm9taWMtDQo+IG5ldHdvcmstZGVmaW5pdGlvbnMtMDEudHh0DQo+IFN0YXR1czogICAg ICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pcnRmLW5tcmctYXV0 b25vbWljLQ0KPiBuZXR3b3JrLWRlZmluaXRpb25zLw0KPiBIdG1saXplZDogICAgICAgaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaXJ0Zi1ubXJnLWF1dG9ub21pYy1uZXR3b3JrLQ0K PiBkZWZpbml0aW9ucy0wMQ0KPiBEaWZmOiAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9y ZmNkaWZmP3VybDI9ZHJhZnQtaXJ0Zi1ubXJnLWF1dG9ub21pYy0NCj4gbmV0d29yay1kZWZpbml0 aW9ucy0wMQ0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgIEF1dG9ub21pYyBzeXN0ZW1zIHdlcmUgZmly c3QgZGVzY3JpYmVkIGluIDIwMDEuICBUaGUgZnVuZGFtZW50YWwgZ29hbA0KPiAgICBpcyBzZWxm LW1hbmFnZW1lbnQsIGluY2x1ZGluZyBzZWxmLWNvbmZpZ3VyYXRpb24sIHNlbGYtb3B0aW1pemF0 aW9uLA0KPiAgICBzZWxmLWhlYWxpbmcgYW5kIHNlbGYtcHJvdGVjdGlvbi4NCj4gDQo+ICAgIFRo aXMgZG9jdW1lbnQgYXBwbGllcyB0aGUgY29uY2VwdHMgb2YgYXV0b25vbWljIHN5c3RlbXMgdG8g YSBuZXR3b3JrLA0KPiAgICBhbmQgZGVzY3JpYmVzIHRoZSBkZWZpbml0aW9ucyBhbmQgZGVzaWdu IGdvYWxzIG9mIEF1dG9ub21pYw0KPiAgICBOZXR3b3JraW5nLiAgVGhlIGhpZ2gtbGV2ZWwgZ29h bCBmb3IgYW4gYXV0b25vbWljIGZ1bmN0aW9uIGlzIHRvIGhhdmUNCj4gICAgbWluaW1hbCBkZXBl bmRlbmNpZXMgb24gaHVtYW4gYWRtaW5pc3RyYXRvcnMgb3IgY2VudHJhbGl6ZWQNCj4gICAgbWFu YWdlbWVudCBzeXN0ZW1zLiAgVGhpcyB1c3VhbGx5IGltcGxpZXMgZGlzdHJpYnV0aW9uIGFjcm9z cyBuZXR3b3JrDQo+ICAgIGVsZW1lbnRzLg0KPiANCj4gDQo+IA0KPiANCj4gUGxlYXNlIG5vdGUg dGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4g c3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxh YmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Fri Jun 27 22:01:13 2014 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 2754D1A029D for ; Fri, 27 Jun 2014 22:01:12 -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 PU6Tdb6-Rurk for ; Fri, 27 Jun 2014 22:01:01 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B33D71A029A for ; Fri, 27 Jun 2014 22:01:01 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id et14so5570740pad.21 for ; Fri, 27 Jun 2014 22:01: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=cQT6FmOQLni2qWoF2Ozz8RxQ0kwUf1m475huD3TSm5g=; b=R4zl80t14S5KGV0tztnRxU40MVemBoK1BXgnZnb/EpCg7LfvwZ9W1jHDLjf6ffhbZL liMZLpSDu2TgkyKXncH7haJ4dTp+EXci5pUM6j7WtBYSv8JniuX4KZI95W0mWK4zHsfj C1MsoYCN3BxLwkUXDHLAYcgkC+00+oxZVFIQ1cu6I1PgCKtqgAAJbEiLZvlSpGXRA5OX /MErupaieBVIUy84HpLHc9A4mzp+WJoMPBno5LRtVtp8ySZ1oWA+QGvvjXRU26N2gTgc Yxyq5eCZ0LEbLhS6pA9Zy7jqHk9JpQOeKkL+oJsG8V1B6zqKZKUN4w456Lwn5hWrgNRT 2rWQ== X-Received: by 10.68.180.65 with SMTP id dm1mr35759792pbc.142.1403931661388; Fri, 27 Jun 2014 22:01:01 -0700 (PDT) Received: from [192.168.178.23] (83.198.69.111.dynamic.snap.net.nz. [111.69.198.83]) by mx.google.com with ESMTPSA id tf10sm17233239pbc.70.2014.06.27.22.00.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Jun 2014 22:01:00 -0700 (PDT) Message-ID: <53AE4C1A.8070900@gmail.com> Date: Sat, 28 Jun 2014 17:01:14 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: draft-bogdanovic-nmrg-mobile-backhaul-use-case@ietf.org, anima@ietf.org References: <20140623165625.20901.29157.idtracker@ietfa.amsl.com> In-Reply-To: <20140623165625.20901.29157.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/P5xEVOPN7qI43zLbcOIGrhV4ot4 Subject: Re: [Anima] I-D Action: draft-bogdanovic-nmrg-mobile-backhaul-use-case-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: Sat, 28 Jun 2014 05:01:12 -0000 Hi, Thanks for this use case. I have one immediate comment. In the section on "4.2. Information needed from policy intent" you have listed the addresses of various units and ethernet ports. I would expect that in an AN solution, all that would be discovered automatically, and might even not be known centrally. In any case I don't really see it as policy information. Regards Brian Carpenter From nobody Fri Jun 27 22:02:58 2014 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 674EA1A029A for ; Fri, 27 Jun 2014 22:02: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 UeUQoL862v3a for ; Fri, 27 Jun 2014 22:02:52 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C17D81A02A3 for ; Fri, 27 Jun 2014 22:02:52 -0700 (PDT) Received: by mail-pa0-f50.google.com with SMTP id bj1so5620745pad.9 for ; Fri, 27 Jun 2014 22:02:52 -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=/AjmE+hapQwnu8xnmPwyKz3fExgCjblFjrRQ+5VN1qc=; b=uYQ1P2caEmkdKpg3eJi17Afp0AslYIsf75G5pO2h8ygnGwnDILQYSStIyAsMNcG22x 3PvwOzg6YK3nlpL4lv0PDHNxsDW7PF8QY4Cxp/W6U4lPznXW/Tb1g3CsS3Kir30Scx/f BDyZtfNp89yzkRn0ctbAVz6Dfs4T0Nfipq7dEahtgd9k0craCIlR1ArKn0rCVClERuvh psEMuRoc1Mtzb238sPrKP5a99WCC6j8RstrsH2YMeGsr0OpQUVsyymqsi9GtojQYwmaT Ti+1y4rAhIoEqgO9qDjdvFrKFmxctRs+IC/obj9EmNFzoMesVkiDR72o/JR0Yx6vptvy mxzQ== X-Received: by 10.68.180.65 with SMTP id dm1mr35769674pbc.142.1403931772496; Fri, 27 Jun 2014 22:02:52 -0700 (PDT) Received: from [192.168.178.23] (83.198.69.111.dynamic.snap.net.nz. [111.69.198.83]) by mx.google.com with ESMTPSA id ha10sm17293894pbd.1.2014.06.27.22.02.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Jun 2014 22:02:52 -0700 (PDT) Message-ID: <53AE4C89.8000803@gmail.com> Date: Sat, 28 Jun 2014 17:03:05 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: draft-bogdanovic-nmrg-mobile-backhaul-use-case@tools.ietf.org, anima@ietf.org References: <20140623165625.20901.29157.idtracker@ietfa.amsl.com> In-Reply-To: <20140623165625.20901.29157.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/SMHRAyKhttZQHQ5vZRsvjkFgjtA Subject: Re: [Anima] I-D Action: draft-bogdanovic-nmrg-mobile-backhaul-use-case-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: Sat, 28 Jun 2014 05:02:57 -0000 (Sorry, retry with correct address) Hi, Thanks for this use case. I have one immediate comment. In the section on "4.2. Information needed from policy intent" you have listed the addresses of various units and ethernet ports. I would expect that in an AN solution, all that would be discovered automatically, and might even not be known centrally. In any case I don't really see it as policy information. Regards Brian Carpenter From nobody Fri Jun 27 22:07:44 2014 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 C934A1A02A3 for ; Fri, 27 Jun 2014 22:07: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 Va16zXD8aMDe for ; Fri, 27 Jun 2014 22:07:41 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7984B1A0297 for ; Fri, 27 Jun 2014 22:07:41 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id eu11so5540270pac.25 for ; Fri, 27 Jun 2014 22:07: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:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=PV2pR5HVEHDD4TJzDgHxyKqWvD4N7QQB4RvWpuFmt1A=; b=y8SkA0sxgLSGx7LpfsaVTCYVEMqojj/r5RVg9g3dV05hoCuVFHVXUNQNgTlUair1tD 6yYopTJLRPQ+H3CjHS8nf1NcB8yVO8Y3Nxhm6gAg3FnEiqFhmcH+TGuzai0GjmeB6G0a QbH+VpV4b+K6gQxqCzjJmIfRV+Kcn4bB7ZW2FrljrTKu5EkwMuQR7S2TSWejcwo7Whoi bn8s5+/kmCNXLKV1xoogiWdzxRspg8jvNGSvV1YqjUZe96xZugb5w4NE7n7aiLdCxwft UUoTI0kJfB6iU1PkgXcvh34o9TwTN+/0xM2r27qI5zu5+th3o8XecZ22wFfgXtr2ppcm RsDw== X-Received: by 10.68.231.7 with SMTP id tc7mr36080980pbc.32.1403932061145; Fri, 27 Jun 2014 22:07:41 -0700 (PDT) Received: from [192.168.178.23] (83.198.69.111.dynamic.snap.net.nz. [111.69.198.83]) by mx.google.com with ESMTPSA id ei4sm17281621pbb.42.2014.06.27.22.07.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Jun 2014 22:07:40 -0700 (PDT) Message-ID: <53AE4DA8.9000505@gmail.com> Date: Sat, 28 Jun 2014 17:07:52 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: draft-irtf-nmrg-autonomic-sla-violation-detection@tools.ietf.org References: <20140623221803.12892.86764.idtracker@ietfa.amsl.com> In-Reply-To: <20140623221803.12892.86764.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/8Czo2GJzeQvrTYJMKpc1bRhSC6I Cc: anima@ietf.org Subject: Re: [Anima] I-D Action: draft-irtf-nmrg-autonomic-sla-violation-detection-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: Sat, 28 Jun 2014 05:07:43 -0000 Hi, And thanks for this use case too. I see that the policy intent section is TBD. Are you thinking of things like policy about how far a service can deviate from its SLO, and how long a time before it counts as a violation? Maybe a default SLO too? Or maybe SLOs will be part of the intent? Regards Brian Carpenter From nobody Fri Jun 27 22:17:37 2014 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 0D7FE1A02AC for ; Fri, 27 Jun 2014 22:17:36 -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 e1NUlavDHkel for ; Fri, 27 Jun 2014 22:17:34 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFABD1A02A9 for ; Fri, 27 Jun 2014 22:17:34 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id hz1so5595860pad.38 for ; Fri, 27 Jun 2014 22:17:34 -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=loa98kaqA0d9eMb0N5hD1tKCOdr9X6HnHMkIWfRfBYA=; b=wtoVte9HvzF9J1v9oArU7rXYNHdlJKa7b7AtMQYfITnWZy65vHVL/ACQqU2el5xAaL nUs/tulXTRa5MhIwVIXEPpzZQ9Y9NOdWtDudqZ6AerbRMiCFgYVlu1vjEpIrlPqfj0eY mHNbgxSuw5ITeKWUkf9pNpLhKJkpdLc6Fb7pmIy6pIMPn8SW2bbuvCD6c+ygyOFw8fxx Um5iuUcXSSKrZjre/xFGaai9HKVNrappiZDf4eaLZ5xSCcd3/7fq2oIZBdS168iWMXLb 0F2WiRsih2wnvbJmmMhCeCSXJbR9RliX4LxJ4zNSmY5zUdr+zP94gvBMgyDO0dVf6bPB PZ5A== X-Received: by 10.67.30.97 with SMTP id kd1mr36506911pad.15.1403932654465; Fri, 27 Jun 2014 22:17:34 -0700 (PDT) Received: from [192.168.178.23] (83.198.69.111.dynamic.snap.net.nz. [111.69.198.83]) by mx.google.com with ESMTPSA id su8sm17298070pbc.72.2014.06.27.22.17.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Jun 2014 22:17:33 -0700 (PDT) Message-ID: <53AE4FFB.9070900@gmail.com> Date: Sat, 28 Jun 2014 17:17:47 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: draft-behringer-autonomic-control-plane@tools.ietf.org References: <20140620095502.9324.99373.idtracker@ietfa.amsl.com> In-Reply-To: <20140620095502.9324.99373.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/oZ2GUWjTKCMlkTYszQjPlwer8po Cc: anima@ietf.org Subject: Re: [Anima] I-D Action: draft-behringer-autonomic-control-plane-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: Sat, 28 Jun 2014 05:17:36 -0000 BOF Chair hat on: Please think about how you can separate out the use case items from the solution space items. These will belong in two completely separate parts of the agenda. BOF Chair hat off, and in solution space: You suggest one option is to establish a "secure IP tunnel" e.g. using IPsec. 1. It isn't clear whether you want to use a tunnel for secrecy or just for authentication. That needs to be stated. 2. IPsec would require a whole bunch of key management complexity. There are ways to avoid that (although it's impossible to avoid some sort of certificate infrastructure, I think). Your other option is L2 separation. I'm not sure that can be applied everywhere, and doesn't it imply a fully bridged network? Regards Brian Carpenter From nobody Sat Jun 28 13:12:46 2014 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 56F531A0040 for ; Sat, 28 Jun 2014 13:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 BEIa1QgA51Jy for ; Sat, 28 Jun 2014 13:12:42 -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 5B7A11A003A for ; Sat, 28 Jun 2014 13:12:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3337; q=dns/txt; s=iport; t=1403986363; x=1405195963; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=9xd/64PDYQKRcsh88MJYxsFqJWs2LYqqZK4Uf+pf85c=; b=IK5Gp1vV6OP28IbkKFZ+tkdRTibNJ3Dc4WbakC83DDurMCXoPDn8UnCY il+Xk+FtqipK5agQ/HJhjKrwdreLKz7UmrRfuZg9r/cwOnKTKA0gUf9wU EPBKbqJ6pRuqaV3YkqRUqwCgilHcFTcZEFRNU+tJfYpkP7WIx1S2e6D00 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoFAGEhr1OtJA2H/2dsb2JhbABagw1Sq1wBAQEBAQEFAW0BkUKHQAGBCRZ1hAMBAQEDAQEBATcxAwsFCwsSBgklDwUTIhQTG4gfCA3FehMEhWSJIQeDLYEWBYpHkBUBk3uDYh0 X-IronPort-AV: E=Sophos;i="5.01,567,1400025600"; d="scan'208";a="56728461" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-8.cisco.com with ESMTP; 28 Jun 2014 20:12:41 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s5SKCdsC031823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Jun 2014 20:12:40 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 s5SKCciq032122; Sat, 28 Jun 2014 13:12:38 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id s5SKCcjT032121; Sat, 28 Jun 2014 13:12:38 -0700 Date: Sat, 28 Jun 2014 13:12:38 -0700 From: Toerless Eckert To: Brian E Carpenter Message-ID: <20140628201238.GA22713@cisco.com> References: <20140620095502.9324.99373.idtracker@ietfa.amsl.com> <53AE4FFB.9070900@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53AE4FFB.9070900@gmail.com> User-Agent: Mutt/1.4.2.2i Archived-At: http://mailarchive.ietf.org/arch/msg/anima/E8xV94hLNd-cJ8wZQ4pj58XcE6s Cc: draft-behringer-autonomic-control-plane@tools.ietf.org, anima@ietf.org Subject: Re: [Anima] I-D Action: draft-behringer-autonomic-control-plane-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: Sat, 28 Jun 2014 20:12:44 -0000 Thanks, Brian, inline... On Sat, Jun 28, 2014 at 05:17:47PM +1200, Brian E Carpenter wrote: > BOF Chair hat on: Please think about how you can separate > out the use case items from the solution space items. These > will belong in two completely separate parts of the agenda. Thats fine. Wouldn't be aproblem at all to present these two aspects separately in Toronto. Will check with the other authors if/how we can improve the draft before IETF, not sure. Its the vacation time... > BOF Chair hat off, and in solution space: > > You suggest one option is to establish a "secure IP tunnel" > e.g. using IPsec. > > 1. It isn't clear whether you want to use a tunnel for secrecy > or just for authentication. That needs to be stated. Right. In fact, the goal was to express that there are two layers to the channel building: security and separation from data plane. Any combination of one or more available mechanisms is a candidate option. Something like MacSec for example would provide both very low layer separatation AND security (but may have short term the most product support challenges). Wrt. to security: IMHO, you MUST have authentication, and secrecy (encryption) would be on by default and disabling it must be a well controllable operation (so it can not happen unintentional). Unfortunately operators must be required to disable encryption to match legal requirements. > 2. IPsec would require a whole bunch of key management complexity. > There are ways to avoid that (although it's impossible to avoid > some sort of certificate infrastructure, I think). Example ? "I am not a security expert, but..." ((c) layman society), my impression is that the operational complexity is 95% based on using public key certificates - whatever protocol you choose, IPsec, (d)TLS, MacSec or whatever else supports PKI. And there does not seems to be a way around PKI it if you want "real security" ((c) security experts). Given multiple choices with PKI support, i'd still pick the one that best matches other requirements. Thats for example why we gave the example of IPsec - its widely supported in network equipment. > Your other option is L2 separation. I'm not sure that can be > applied everywhere, and doesn't it imply a fully bridged network? Hmm.. this comment makes me think that you may not have read this as we intended to: The channel is always between two adjacent AN devices. If you have a large L2 network consisting all of AN devices, then each one still has a separate channel to each of its direct neighbors. Which would be the same if this network was purely a routed network. In routers, its usually quite easy to have a separate L2 tag for a separate L3 context - eg: in cisco routers we call this a "routed subinterface". The complexities in other existing type of devices vary. But when you know the requirement upfront in new devices its IMHO always easy to design support for this. Cheers Toerless > > Regards > Brian Carpenter > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture SDN: Let me play with the network, mommy! From nobody Sat Jun 28 13:41:41 2014 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 0DD411A0073 for ; Sat, 28 Jun 2014 13:41: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 hQF2lcP9volo for ; Sat, 28 Jun 2014 13:41:38 -0700 (PDT) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C14D1A001C for ; Sat, 28 Jun 2014 13:41:38 -0700 (PDT) Received: by mail-pd0-f182.google.com with SMTP id y13so6126266pdi.27 for ; Sat, 28 Jun 2014 13:41:37 -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=EE1sZVvvTbE4+/TKRWYjuxeq/x8ie+BIRpAIULsNBIk=; b=dscVkGiJ3Ohswl9vemawALvsH0G7mcPTjKIaAavlpZllUnCxu4E+wNrqnO5DIhuWvF nQAYdyNvcpg/4orkH7Apz0BB2s35TmJFeYLP6rXIZwge5MWBXcXABTVWi+Eq992gyaHs EIT8oW4W95eT31m0SKK1EmVOHfmfxuRLHARQi8hxNJhSdeX94fIep2F7YXjeP2roi056 wb2GDvl7ioJ97zpGoyWu6QYXmwhr4baDH46vb7vVL3Nc1WXfZyCVSFgL7clJLZuIYNXV R6AgHtlyVG5IpEhP2/o0z6NgMaV5l6lA0DnmfC88+AOSkgklsV/Ekeq1h84zPnv3maND XSPw== X-Received: by 10.66.237.8 with SMTP id uy8mr40853649pac.95.1403988097677; Sat, 28 Jun 2014 13:41:37 -0700 (PDT) Received: from [192.168.178.23] (50.198.69.111.dynamic.snap.net.nz. [111.69.198.50]) by mx.google.com with ESMTPSA id zc10sm72436096pac.46.2014.06.28.13.41.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 28 Jun 2014 13:41:36 -0700 (PDT) Message-ID: <53AF287E.2060307@gmail.com> Date: Sun, 29 Jun 2014 08:41:34 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Toerless Eckert References: <20140620095502.9324.99373.idtracker@ietfa.amsl.com> <53AE4FFB.9070900@gmail.com> <20140628201238.GA22713@cisco.com> In-Reply-To: <20140628201238.GA22713@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/QAtkux26Yp6MYoL-3k-d6Q3jPd0 Cc: draft-behringer-autonomic-control-plane@tools.ietf.org, anima@ietf.org Subject: Re: [Anima] I-D Action: draft-behringer-autonomic-control-plane-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: Sat, 28 Jun 2014 20:41:40 -0000 On 29/06/2014 08:12, Toerless Eckert wrote: > Thanks, Brian, > inline... > > On Sat, Jun 28, 2014 at 05:17:47PM +1200, Brian E Carpenter wrote: >> BOF Chair hat on: Please think about how you can separate >> out the use case items from the solution space items. These >> will belong in two completely separate parts of the agenda. > > Thats fine. Wouldn't be aproblem at all to present these two > aspects separately in Toronto. > > Will check with the other authors if/how we can improve the draft > before IETF, not sure. Its the vacation time... > >> BOF Chair hat off, and in solution space: >> >> You suggest one option is to establish a "secure IP tunnel" >> e.g. using IPsec. >> >> 1. It isn't clear whether you want to use a tunnel for secrecy >> or just for authentication. That needs to be stated. > > Right. In fact, the goal was to express that there are two layers > to the channel building: security and separation from data plane. > Any combination of one or more available mechanisms is a candidate > option. Something like MacSec for example would provide both > very low layer separatation AND security (but may have short term the > most product support challenges). > > Wrt. to security: IMHO, you MUST have authentication, and secrecy > (encryption) would be on by default and disabling it must be > a well controllable operation (so it can not happen unintentional). > Unfortunately operators must be required to disable encryption to match > legal requirements. > >> 2. IPsec would require a whole bunch of key management complexity. >> There are ways to avoid that (although it's impossible to avoid >> some sort of certificate infrastructure, I think). > > Example ? Well, I didn't mean to suggest that we can avoid PKI within the AN domain; there doesn't seem to be any way out of that, as you say below. > "I am not a security expert, but..." ((c) layman society), ...ditto. > > my impression is that the operational complexity is 95% based > on using public key certificates - whatever protocol you > choose, IPsec, (d)TLS, MacSec or whatever else supports PKI. ...my impression is that IPsec/IKEv2 brings more complexity than the other approaches (including the kind of homebrew we describe in draft-jiang-config-negotiation-protocol). > And there does not seems to be a way around PKI it if you want > "real security" ((c) security experts). > > Given multiple choices with PKI support, i'd still pick the > one that best matches other requirements. Thats for example why > we gave the example of IPsec - its widely supported in network equipment. Sure, but it isn't the only candidate. > >> Your other option is L2 separation. I'm not sure that can be >> applied everywhere, and doesn't it imply a fully bridged network? > > Hmm.. this comment makes me think that you may not have read this > as we intended to: The channel is always between two adjacent > AN devices. If you have a large L2 network consisting all of > AN devices, then each one still has a separate channel to each of > its direct neighbors. Which would be the same if this network > was purely a routed network. OK. But that means you require perfect congruence between the AN topology and the L2 topology, doesn't it? > In routers, its usually quite easy to have a separate L2 tag for > a separate L3 context - eg: in cisco routers we call this > a "routed subinterface". The complexities in other existing type > of devices vary. But when you know the requirement upfront in new > devices its IMHO always easy to design support for this. OK, but in the standards context this needs to be vendor-independent. Brian > Cheers > Toerless >> Regards >> Brian Carpenter >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > From nobody Sat Jun 28 18:50:22 2014 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 7FC211A008A; Sat, 28 Jun 2014 14:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 eD_vanaOz5Qp; Sat, 28 Jun 2014 14:02:02 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0144.outbound.protection.outlook.com [207.46.163.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AFB11A0085; Sat, 28 Jun 2014 14:02:02 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB423.namprd05.prod.outlook.com (10.141.58.146) with Microsoft SMTP Server (TLS) id 15.0.974.11; Sat, 28 Jun 2014 21:02:00 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.110]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.110]) with mapi id 15.00.0974.002; Sat, 28 Jun 2014 21:02:00 +0000 From: Dean Bogdanovic To: Brian E Carpenter Thread-Topic: I-D Action: draft-bogdanovic-nmrg-mobile-backhaul-use-case-00.txt Thread-Index: AQHPko5VW0YUev070EW1SY6IIGMP5ZuHA0qA Date: Sat, 28 Jun 2014 21:01:59 +0000 Message-ID: <7F667A3C-978A-4732-BFD6-CA32DC58A120@juniper.net> References: <20140623165625.20901.29157.idtracker@ietfa.amsl.com> <53AE4C89.8000803@gmail.com> In-Reply-To: <53AE4C89.8000803@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.12] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0256C18696 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(24454002)(199002)(189002)(51704005)(377454003)(85852003)(79102001)(83072002)(92566001)(82746002)(19580395003)(19580405001)(57306001)(2656002)(81542001)(88136002)(104166001)(89996001)(92726001)(77982001)(87936001)(81342001)(77156001)(76176999)(74662001)(31966008)(83716003)(50226001)(4396001)(50986999)(36756003)(99396002)(46102001)(83322001)(66066001)(33656002)(74502001)(93916002)(87286001)(76482001)(86362001)(64706001)(80022001)(62966002)(101416001)(85306003)(99286002)(95666004)(77096002)(20776003)(105586002)(106116001)(106356001)(21056001)(107046002)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB423; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <3ECC319471078E41B86534BC12922C18@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/anima/6JQ5wUTEePZJ8_3mHdHFdnbAEzM X-Mailman-Approved-At: Sat, 28 Jun 2014 18:50:14 -0700 Cc: "netmod@ietf.org" , "anima@ietf.org" Subject: Re: [Anima] I-D Action: draft-bogdanovic-nmrg-mobile-backhaul-use-case-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: Sat, 28 Jun 2014 21:02:04 -0000 Brian, I'm aware of that issue, but today router is not aware of microwave managem= ent network. Where locally connected devices have some ideas how to figure = out, for remote devices have no idea how to get stats without SNMP. And man= agement networks are usually out of band.=20 I'm interested to hear how remote microwave devices could send counters inf= ormation using existing tools today, this is one part that I plan to look m= ore into it Dean On Jun 28, 2014, at 1:03 AM, Brian E Carpenter wrote: > (Sorry, retry with correct address) >=20 > Hi, >=20 > Thanks for this use case. I have one immediate comment. > In the section on "4.2. Information needed from policy intent" > you have listed the addresses of various units and ethernet ports. > I would expect that in an AN solution, all that would be discovered > automatically, and might even not be known centrally. In any case > I don't really see it as policy information. >=20 > Regards > Brian Carpenter >=20 From nobody Sat Jun 28 18:50:24 2014 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 3F1D41A00A8 for ; Sat, 28 Jun 2014 14:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4tgE4uKeKxz for ; Sat, 28 Jun 2014 14:25:04 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C75011A00A3 for ; Sat, 28 Jun 2014 14:25:03 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB422.namprd05.prod.outlook.com (10.141.58.142) with Microsoft SMTP Server (TLS) id 15.0.974.11; Sat, 28 Jun 2014 21:24:54 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.110]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.110]) with mapi id 15.00.0974.002; Sat, 28 Jun 2014 21:24:54 +0000 From: Dean Bogdanovic To: Brian E Carpenter Thread-Topic: I-D Action: draft-bogdanovic-nmrg-mobile-backhaul-use-case-00.txt Thread-Index: AQHPko5VW0YUev070EW1SY6IIGMP5ZuHCbCA Date: Sat, 28 Jun 2014 21:24:54 +0000 Message-ID: References: <20140623165625.20901.29157.idtracker@ietfa.amsl.com> <53AE4C89.8000803@gmail.com> In-Reply-To: <53AE4C89.8000803@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.17] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0256C18696 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199002)(51704005)(377454003)(24454002)(81542001)(87936001)(50986999)(83716003)(76176999)(93916002)(81342001)(31966008)(74662001)(77982001)(87286001)(80022001)(76482001)(21056001)(64706001)(20776003)(46102001)(57306001)(79102001)(2656002)(99396002)(86362001)(88136002)(85852003)(101416001)(89996001)(36756003)(82746002)(66066001)(77096002)(74502001)(92566001)(85306003)(62966002)(99286002)(92726001)(4396001)(104166001)(95666004)(83322001)(19580405001)(77156001)(50226001)(83072002)(33656002)(107046002)(106116001)(105586002)(19580395003)(106356001)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB422; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/anima/Ogvy1iifEeM6yQj-xNImLtB6g68 X-Mailman-Approved-At: Sat, 28 Jun 2014 18:50:17 -0700 Cc: "nmrg@irtf.org" , "anima@ietf.org" Subject: Re: [Anima] I-D Action: draft-bogdanovic-nmrg-mobile-backhaul-use-case-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: Sat, 28 Jun 2014 21:25:05 -0000 One more time with right email address Brian, I'm aware of that issue, but today router is not aware of microwave managem= ent network. Where locally connected devices have some ideas how to figure = out, for remote devices have no idea how to get stats without SNMP. And man= agement networks are usually out of band.=20 I'm interested to hear how remote microwave devices could send counters inf= ormation using existing tools today, this is one part that I plan to look m= ore into it Dean On Jun 28, 2014, at 1:03 AM, Brian E Carpenter wrote: > (Sorry, retry with correct address) >=20 > Hi, >=20 > Thanks for this use case. I have one immediate comment. > In the section on "4.2. Information needed from policy intent" > you have listed the addresses of various units and ethernet ports. > I would expect that in an AN solution, all that would be discovered > automatically, and might even not be known centrally. In any case > I don't really see it as policy information. >=20 > Regards > Brian Carpenter >=20 From nobody Sun Jun 29 20:26:24 2014 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 16DA91A0103 for ; Sun, 29 Jun 2014 20:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 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, 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 F6kHqbwCkJT9 for ; Sun, 29 Jun 2014 20:26:21 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49CF41A00FF for ; Sun, 29 Jun 2014 20:26:21 -0700 (PDT) Received: by mail-pa0-f50.google.com with SMTP id bj1so7756031pad.23 for ; Sun, 29 Jun 2014 20:26: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 :subject:content-type:content-transfer-encoding; bh=9gW0n+taznkaW5hWCJ71RCMfLHNctK7y57QGqEVuFJk=; b=UaNYxkTAueWN4dhokJAVAKMJEFac/IgRWHwTi7PuzYYSOGxiTHIughVlfbyxvZ9hkH i9ovvkw/eTCoI+3KsCpvcVPa7MTaNCNduIQSpTCA4NjvjK6bnj7xfRwSt+6TN4+vZxOF 3b7Ik0iTZvZOF7e31jY8Jo6WA8UB0Ehkyhuk0C7zDA16ynALgtNCZMDvPPSSe+pKBJrs U7sUnJR2cVF5RBkRIxba0ZRZTRpwD/WtEG7cq201uptY+heQVDWE8BnFQM2yfcjU1ZV0 VPIgJHansRYB3CeUSyXLqcMLnWDNwyHEeFt48KXsRqNBp0d6WERXZIO8bNYZa6eXLnkz LITw== X-Received: by 10.68.226.197 with SMTP id ru5mr49305920pbc.77.1404098780892; Sun, 29 Jun 2014 20:26:20 -0700 (PDT) Received: from [192.168.178.23] (28.196.69.111.dynamic.snap.net.nz. [111.69.196.28]) by mx.google.com with ESMTPSA id gq4sm25220870pbc.64.2014.06.29.20.26.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 29 Jun 2014 20:26:20 -0700 (PDT) Message-ID: <53B0D8D3.4070403@gmail.com> Date: Mon, 30 Jun 2014 15:26:11 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: anima@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/r3qR4rcF4vzsxXaQ24jYT2qUWYw Subject: [Anima] Preparing the UCAN BOF 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: Mon, 30 Jun 2014 03:26:23 -0000 Hi, While Michael Behringer is on leave, I will continue to prepare the BOF agenda. Some comments: - The initial overview is fairly short. As always, please read the drafts in advance. Those two drafts will be discussed in more detail in NMRG on Monday. - We propose to give a short slot to each use case announced so far. There won't be much time for questions, so again please read in advance. I will contact the various authors soon with a plan for getting through the main points of each case efficiently. - We've added a short item on solution space. This is not intended as a thorough discussion on solutions. The idea is to show that there are concrete mechanisms that can realistically be implemented. For now the latest agenda is in the wiki, and today it looks like this: 1. Agenda bashing (5 min) 2. Overview of autonomic networking ideas and the need, scope and criteria for use cases (draft-irtf-nmrg-autonomic-network-definitions, draft-irtf-nmrg-an-gap-analysis) (20 min) 3. Use cases (5 min each): - homenet (draft-carpenter-nmrg-homenet-an-use-case) - large network address management (draft-jiang-auto-addr-management) - securely bootstrapping new devices (draft-behringer-autonomic-bootstrap) - autonomic control plane (draft-behringer-autonomic-control-plane) - distributed detection of SLA violations (draft-irtf-nmrg-autonomic-sla-violation-detection) - mobile backhaul (draft-bogdanovic-nmrg-mobile-backhaul-use-case) - risk aware routing (draft-TBD) 4. Approaches to solution space (10 min) Discovery + negotiation (draft-jiang-config-negotiation-protocol, draft-jiang-config-negotiation-ps) Autonomic bootstrap of an Autonomic Control Plane (draft-pritikin-bootstrapping-keyinfrastructures, draft-behringer-autonomic-control-plane) 5. Discussion, including identifying other uses cases & next steps (50 min) Regards Brian Carpenter From nobody Sun Jun 29 22:11:40 2014 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 974A21A016E for ; Sun, 29 Jun 2014 22:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, 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 frcj3TwgnIyI for ; Sun, 29 Jun 2014 22:11:36 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1B0C1A0169 for ; Sun, 29 Jun 2014 22:11:35 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id mc6so4546089lab.27 for ; Sun, 29 Jun 2014 22:11:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=ce/MCQBU0pKGZPkJrK1fCYbriW642Yp3OwdmuIiYLnE=; b=P1uOlZrcWOABhiz4/5i6IgfF8xCSWB3XgKAfiyeF0GCtGI6Sp4y67Zv1JNe/AC0txx CD1L9MS5nriwmURgeUmjd6gA6tCwN/xLe3mGQRpo3pewxMd4Hq3hd+KTTCDuEJmfB3r7 c2dokjfPJ2GazkmgUyrOmIHX4IF1Pl4hMcJltsYb9LLnGEmovTfDMaoJQp5ZxsUZT2AI Jp+vykTqylIRHShcUmXJQCGW282CTEZwCNPUkz6FIE54cj1b4Ew4zFFH+xHyUak+wAh5 uvV3MdCZR0m+MewdTL61NdQEnGu4wMr5PoJh9clS+5bBzm4z4yAZoR/vmKxed4LeUemk uNtA== MIME-Version: 1.0 X-Received: by 10.152.43.103 with SMTP id v7mr65313lal.70.1404105093917; Sun, 29 Jun 2014 22:11:33 -0700 (PDT) Sender: jeferson.nobre@gmail.com Received: by 10.112.146.228 with HTTP; Sun, 29 Jun 2014 22:11:33 -0700 (PDT) In-Reply-To: <53AE4DA8.9000505@gmail.com> References: <20140623221803.12892.86764.idtracker@ietfa.amsl.com> <53AE4DA8.9000505@gmail.com> Date: Mon, 30 Jun 2014 02:11:33 -0300 X-Google-Sender-Auth: 2WEx931_i5LhcjjETcDeONZH4i0 Message-ID: From: =?UTF-8?Q?J=C3=A9ferson_Campos_Nobre?= To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/anima/1c_LdyFP94oqWFDEqOqffDcV-kY Cc: draft-irtf-nmrg-autonomic-sla-violation-detection@tools.ietf.org, anima@ietf.org Subject: Re: [Anima] I-D Action: draft-irtf-nmrg-autonomic-sla-violation-detection-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: Mon, 30 Jun 2014 05:11:37 -0000 Hi Brian. Yes, the police intent section will cover information related to the SLO monitoring/management. In fact, the points you mentioned are addressed on our solution. We will write another I-D to describe it. BTW, I think that, at some point, we will have to discuss how the intent will be refined in lower level policies. Maybe this can be done in each specific solution space, I am not sure if a more general policy solution would be a good idea. Thanks. J=C3=A9ferson Campos Nobre PhD Student Computer Networks Group - Institute of Informatics Federal University of Rio Grande do Sul http://www.inf.ufrgs.br/~jcnobre On Sat, Jun 28, 2014 at 2:07 AM, Brian E Carpenter wrote: > Hi, > > And thanks for this use case too. I see that the policy intent > section is TBD. Are you thinking of things like policy about > how far a service can deviate from its SLO, and how long > a time before it counts as a violation? Maybe a default SLO > too? Or maybe SLOs will be part of the intent? > > Regards > Brian Carpenter > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima