From nobody Sat Nov 1 02:35: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 5742D1A6EE7 for ; Sat, 1 Nov 2014 02:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EZVlm0ARxbF for ; Sat, 1 Nov 2014 02:35:35 -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 E2E0E1A1B99 for ; Sat, 1 Nov 2014 02:35:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7581; q=dns/txt; s=iport; t=1414834534; x=1416044134; h=from:to:subject:date:message-id:references:in-reply-to: reply-to:mime-version; bh=Ch9FVfrvEo9tRHL577ntDlhzQTB65mlXOd1LHh9Y0m4=; b=U4mpeXRzT37A39nSOAuTzEN1NTFc7DAUGR+xVsGwX+R7TnmffDfXMpzX tXcQg4YVqnb9gVm6wYqXojyWxSACLKzl3G29nwDPKisnbS0S6Aqo65eUJ 9mcaFNhYNWxPBjBkTMSuMEJKqyNVvpafBa3Lh7xmy++ZBdrv4exwAZqNf c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAOGoVFStJV2S/2dsb2JhbABcgkhGVFjNNAEJh00CgRUWAQEBAQF9hAIBAQEEAQEBKkEXBAIBGQQBAQolDxgLDgYJCAIEARKIQQ27co1QAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSKdIJNAYNKCwaERQWFGwOGGIZihE+HFoExg02NRoQJgg6BamyCSwEBAQ X-IronPort-AV: E=Sophos; i="5.07,295,1413244800"; d="scan'208,217"; a="92377714" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-7.cisco.com with ESMTP; 01 Nov 2014 09:35:33 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sA19ZXid027409 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 1 Nov 2014 09:35:33 GMT Received: from xmb-rcd-x12.cisco.com ([169.254.2.5]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Sat, 1 Nov 2014 04:35:33 -0500 From: "Benoit Claise (bclaise)" To: "Michael Behringer (mbehring)" , Sheng Jiang , "anima@ietf.org" Thread-Topic: RE : RE: [Anima] Summary status of ANIMA drafts submission Thread-Index: AQHP9bcu+NYsKn33hEqYKOfEG/Dh1w== Date: Sat, 1 Nov 2014 09:35:32 +0000 Message-ID: <03y8f907w2d0ojmbk1s2ndnu.1414834458170@email.android.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AF6A85D@nkgeml512-mbx.china.huawei.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21C9EB57@xmb-rcd-x14.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AF6AFA6@nkgeml512-mbx.china.huawei.com> <545399E7.8010109@cisco.com>, <3AA7118E69D7CD4BA3ECD5716BAF28DF21CA293D@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF21CA293D@xmb-rcd-x14.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_03y8f907w2d0ojmbk1s2ndnu1414834458170emailandroidcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/anima/NJbP_8T8D-TGjFQ8AffQpb8eZMY Subject: Re: [Anima] Summary status of ANIMA drafts submission X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Benoit Claise \(bclaise\)" List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 09:35:37 -0000 --_000_03y8f907w2d0ojmbk1s2ndnu1414834458170emailandroidcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If approve by an AD, yes B. Envoy=E9 depuis un mobile Samsung -------- Message d'origine -------- De : "Michael Behringer (mbehring)" Date : 01/11/2014 6:46 (GMT+01:00) A : "Benoit Claise (bclaise)" ,Sheng Jiang ,anima@ietf.org Objet : RE: [Anima] Summary status of ANIMA drafts submission Ah, so we CAN still submit??? Sorry I was unaware. Will do this first thing= Monday. Michael > -----Original Message----- > From: Benoit Claise (bclaise) > Sent: 31 October 2014 15:17 > To: Sheng Jiang; Michael Behringer (mbehring); anima@ietf.org > Subject: Re: [Anima] Summary status of ANIMA drafts submission > > Dear draft-pritikin-bootstrapping-keyinfrastructures authors, > >>> We are missed one essential component draft that was agreed in the > >>> initial > >>> plan: > >>> > >>> draft-X-anima-trust-bootstrap (Who is responsible?). If people are > >>> still working on it, it may be submitted after the online draft > >>> submission tool reopen at the night of Oct. 8. > >> This is draft-pritikin-bootstrapping-keyinfrastructures. It didn't > >> get re-submitted with "anima" in the title, but this is the draft. > > Hi, Michael, > > > > Even the content remains unchanged, re-submitted with "anima" in the > title would be helpful. For now, this draft does not appear on the WG pag= es, > link below, which is auto generated based on the document naming rules. > > > > https://datatracker.ietf.org/wg/anima/documents/ > > > > Therefore, it is highly possible many people who are interested in ANIM= A > would miss this draft. > > > > So, please do re-submit this draft with "anima" when the online draft > submission tool reopen at the night of Nov. 9th. We will have the meeting > on the Monday, Nov. 10th. > Even better. Rename your draft to > draft-pritikin-anima-bootstrapping-keyinfrastructures, send it now to > internet-drafts@ietf.org, and cc me. > From there, I will approve the post. > > Regards, Benoit > > > > Best regards, > > > > Sheng > > > >> Michael > >> > >>> More contributions and drafts are always welcome. > >>> > >>> The status of the ANIMA meeting in the coming IETF91 will only be > >>> decided at this week's IESG meeting and the chairs are not yet > >>> known. Therefore, > >> the > >>> agenda process is running late. > >>> > >>> Best regards, > >>> > >>> Sheng > >>> _______________________________________________ > >>> 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 > > --_000_03y8f907w2d0ojmbk1s2ndnu1414834458170emailandroidcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
If approve by an AD, yes

B.


Envoy=E9 depuis un mobile Samsu= ng



-------- Message d'origine --------
De : "Michael Behringer (mbehring)" <mbehring@cisco.com> Date : 01/11/2014 6:46 (GMT+01:00)
A : "Benoit Claise (bclaise)" <bclaise@cisco.com>,Sheng Jia= ng <jiangsheng@huawei.com>,anima@ietf.org
Objet : RE: [Anima] Summary status of ANIMA drafts submission


Ah, so we CAN still submit??? Sorry I was unaware.= Will do this first thing Monday.

Michael

> -----Original Message-----
> From: Benoit Claise (bclaise)
> Sent: 31 October 2014 15:17
> To: Sheng Jiang; Michael Behringer (mbehring); anima@ietf.org
> Subject: Re: [Anima] Summary status of ANIMA drafts submission
>
> Dear draft-pritikin-bootstrapping-keyinfrastructures authors,
> >>> We are missed one essential component draft that was agre= ed in the
> >>> initial
> >>> plan:
> >>>
> >>> draft-X-anima-trust-bootstrap (Who is responsible?). If p= eople are
> >>> still working on it, it may be submitted after the online= draft
> >>> submission tool reopen at the night of Oct. 8.
> >> This is draft-pritikin-bootstrapping-keyinfrastructures. It d= idn't
> >> get re-submitted with "anima" in the title, but thi= s is the draft.
> > Hi, Michael,
> >
> > Even the content remains unchanged, re-submitted with "anima= " in the
> title would be helpful. For now, this draft does not appear on the WG = pages,
> link below, which is auto generated based on the document naming rules= .
> >
> > http= s://datatracker.ietf.org/wg/anima/documents/
> >
> > Therefore, it is highly possible many people who are interested i= n ANIMA
> would miss this draft.
> >
> > So, please do re-submit this draft with "anima" when th= e online draft
> submission tool reopen at the night of Nov. 9th. We will have the meet= ing
> on the Monday, Nov. 10th.
> Even better. Rename your draft to
> draft-pritikin-anima-bootstrapping-keyinfrastructures, send it now to<= br> > internet-drafts@ietf.org, and cc me.
>  From there, I will approve the post.
>
> Regards, Benoit
> >
> > Best regards,
> >
> > Sheng
> >
> >> Michael
> >>
> >>> More contributions and drafts are always welcome.
> >>>
> >>> The status of the ANIMA meeting in the coming IETF91 will= only be
> >>> decided at this week's IESG meeting and the chairs are no= t yet
> >>> known. Therefore,
> >> the
> >>> agenda process is running late.
> >>>
> >>> Best regards,
> >>>
> >>> Sheng
> >>> _______________________________________________
> >>> Anima mailing list
> >>> Anima@ietf.org
> >>> h= ttps://www.ietf.org/mailman/listinfo/anima
> > _______________________________________________
> > Anima mailing list
> > Anima@ietf.org
> > https://w= ww.ietf.org/mailman/listinfo/anima
> >

 --_000_03y8f907w2d0ojmbk1s2ndnu1414834458170emailandroidcom_-- From nobody Sat Nov 1 04: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 33C391A86E4; Sat, 1 Nov 2014 04:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxnYTyDX-G60; Sat, 1 Nov 2014 04:41:38 -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 65A6B1A1AE9; Sat, 1 Nov 2014 04:41:36 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLE19556; Sat, 01 Nov 2014 11:41:34 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 1 Nov 2014 11:41:33 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.22]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Sat, 1 Nov 2014 19:41:25 +0800 From: Sheng Jiang To: Ted Lemon Thread-Topic: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15 Thread-Index: AQHP9SIMHDlOqcok8kGUC7qrCmIAsJxLnzZn Date: Sat, 1 Nov 2014 11:41:25 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AF6CD1B@nkgeml512-mbx.china.huawei.com> References: <544FF8FC.5090103@cisco.com> <95338658-B4F2-4634-AC7B-7B893C4DEF2E@iki.fi> <5D36713D8A4E7348A7E10DF7437A4B923AF6C46E@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AF6C7AE@nkgeml512-mbx.china.huawei.com>, <8490A544-45A9-45D2-9C98-D3CBEB28651D@fugue.com> <5D36713D8A4E7348A7E10DF7437A4B923AF6C8A9@nkgeml512-mbx.china.huawei.com>, In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.28.224] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/anima/KcCHIHy42VR8n9s7ZPsKqW-l7qw Cc: Benoit Claise , "homenet@ietf.org" , Markus Stenberg , "anima@ietf.org" Subject: Re: [Anima] [homenet] ANIMA scope + homenet interaction + charter v15 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, 01 Nov 2014 11:41:41 -0000 Hi, Ted, I agree with you that an autonomic network must be able to support incremen= tal grow. So the network topology would not always remain hierarchical. The= refore, hierarchical delegation does not work in an autonomous network. Als= o, it is difficult to remain routing aggregation based on hierarchical topo= logy in an autonomous network. But getting back to where we start the discussion, I still think in a large= network, the requesting prefix may not always be /64. It is reasonable to = have multiple distributed sources for prefix assignment, in a large network= . Autonomic network use case also includes to manage the prefix resource am= ong these prefix pools. Some resource may be transferred from one pool to a= nother with negotiation supporting. In such scenario, the requesting device= may not know the requesting prefix length, unless it has already negotiate= d with a certain requested device. My guess is we should separate the abovementioned scenario from normal /64 = prefix assignment. Also Brian's scenario that a devices may require multipl= e /64 is also common. Best regards, Sheng ________________________________________ From: Ted Lemon [mellon@fugue.com] Sent: 31 October 2014 23:47 To: Sheng Jiang Cc: Benoit Claise; homenet@ietf.org; Markus Stenberg; anima@ietf.org Subject: Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter = v15 On Oct 31, 2014, at 10:55 AM, Sheng Jiang wrote: > The current general mechanism are too general to work for the use case of= hierarchical prefix delegation. But if we add hierarchical topology and no= bypass requests as constraint conditions, we may be able to make hierarchi= cal prefix delegation work. No, that is not the point I am making. The point I am making is that hier= archical delegation simply won't work, no matter what mechanism you put in = place to do it, because the network has to be able to grow incrementally. = With that as a base assumption, you cannot predict where the network will = grow, so you don't know how to construct the hierarchy. Once the hierarch= y is constructed, you would have to renumber on a regular basis to make hie= rarchical delegation work. I think it is preferable to simply allow for a= complete routing table, and then try as best as possible to make routing h= ierarchical, without demanding perfection.= From nobody Sat Nov 1 04:50: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 6BC471A872B; Sat, 1 Nov 2014 04:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azuqSCOVqcEY; Sat, 1 Nov 2014 04:50:27 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FAFF1A8710; Sat, 1 Nov 2014 04:50:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLE19926; Sat, 01 Nov 2014 11:50:23 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 1 Nov 2014 11:50:22 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.22]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Sat, 1 Nov 2014 19:50:16 +0800 From: Sheng Jiang To: Brian E Carpenter , Ralph Droms Thread-Topic: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15 Thread-Index: AQHP9Wl4GX/PQZVIEESA9fvbWEEHCpxLpyhe Date: Sat, 1 Nov 2014 11:50:15 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AF6CD27@nkgeml512-mbx.china.huawei.com> References: <544FF8FC.5090103@cisco.com> <95338658-B4F2-4634-AC7B-7B893C4DEF2E@iki.fi> <5D36713D8A4E7348A7E10DF7437A4B923AF6C46E@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AF6C7AE@nkgeml512-mbx.china.huawei.com> <8490A544-45A9-45D2-9C98-D3CBEB28651D@fugue.com> <5D36713D8A4E7348A7E10DF7437A4B923AF6C8A9@nkgeml512-mbx.china.huawei.com> <5453E246.9000705@gmail.com> <6AD5ADBE-649C-4E30-B2DE-2FE95EEB5112@fugue.com> <9D2D95EC-61CE-48A0-8196-4563E65F963C@gmail.com>, <545426FC.7040504@gmail.com> In-Reply-To: <545426FC.7040504@gmail.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.28.224] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/anima/65w7Z-EtCKWzgEwAeces2yW0ofI Cc: Benoit Claise , "homenet@ietf.org" , Markus Stenberg , Ted Lemon , "anima@ietf.org" Subject: Re: [Anima] [homenet] ANIMA scope + homenet interaction + charter v15 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, 01 Nov 2014 11:50:29 -0000 A very large carrier is normally organizing its network into multiple ASes.= It is naturely aggregated when an AS announced its prefix(es). Complete ro= uting table with in an AS should not be a scaling problem. Because it is no= t possible for all routers have complete routing table, so the path within = an AS may not always be perfect. But reachability would not be in any doubt= s. Sheng ________________________________________ From: homenet [homenet-bounces@ietf.org] on behalf of Brian E Carpenter [br= ian.e.carpenter@gmail.com] Sent: 01 November 2014 8:19 To: Ralph Droms Cc: Markus Stenberg; Ted Lemon; Benoit Claise; homenet@ietf.org; anima@ietf= .org; Sheng Jiang Subject: Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter = v15 On 01/11/2014 12:28, Ralph Droms wrote: > > > >> On Oct 31, 2014, at 4:04 PM, Ted Lemon wrote: >> >>> On Oct 31, 2014, at 3:25 PM, Brian E Carpenter wrote: >>> Well yes. That's exactly why in autonomic management of prefixes, >>> we need peer to peer negotiation, as in "I need 3 /64s that I >>> don't have, do you have any spare ones for me?" Maybe it's >>> badly explained but that is the whole point of our use case. >> Sure, you can approach it as a sort of flood fill algorithm that tries t= o optimize for route aggregation, but copes if that optimization doesn't pa= n out. >> > Do we have use cases in which the number of links is so large that unaggr= egated routing tables will be a problem? Not that I'm aware of. In the case of a carrier, the prefix will be aggrega= ted anyway when it is announced to peer carriers, and possibly aggregated regionally anyway if it's a very large carrier. Of course, there will be a scaling limit and that should be a consideration in the design. Brian _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet= From nobody Sat Nov 1 05:31: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 8EAF61A8884; Sat, 1 Nov 2014 05:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXBpbj6Fh4m4; Sat, 1 Nov 2014 05:31:25 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 6035F1A887E; Sat, 1 Nov 2014 05:31:25 -0700 (PDT) Received: from [10.0.20.107] (c-71-233-43-215.hsd1.nh.comcast.net [71.233.43.215]) by toccata.fugue.com (Postfix) with ESMTPSA id 1813E23808EB; Sat, 1 Nov 2014 08:31:22 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AF6CD1B@nkgeml512-mbx.china.huawei.com> Date: Sat, 1 Nov 2014 08:31:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2DE7FEEE-0060-4EB0-AD81-60B0C63B9A14@fugue.com> References: <544FF8FC.5090103@cisco.com> <95338658-B4F2-4634-AC7B-7B893C4DEF2E@iki.fi> <5D36713D8A4E7348A7E10DF7437A4B923AF6C46E@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AF6C7AE@nkgeml512-mbx.china.huawei.com>, <8490A544-45A9-45D2-9C98-D3CBEB28651D@fugue.com> <5D36713D8A4E7348A7E10DF7437A4B923AF6C8A9@nkgeml512-mbx.china.huawei.com>, <5D36713D8A4E7348A7E10DF7437A4B923AF6CD1B@nkgeml512-mbx.china.huawei.com> To: Sheng Jiang X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/anima/vHczubE4xcJ1oAdlhlDpftKtbPw Cc: Benoit Claise , "homenet@ietf.org" , Markus Stenberg , "anima@ietf.org" Subject: Re: [Anima] [homenet] ANIMA scope + homenet interaction + charter v15 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, 01 Nov 2014 12:31:27 -0000 On Nov 1, 2014, at 7:41 AM, Sheng Jiang wrote: > But getting back to where we start the discussion, I still think in a = large network, the requesting prefix may not always be /64. It is = reasonable to have multiple distributed sources for prefix assignment, = in a large network. Autonomic network use case also includes to manage = the prefix resource among these prefix pools. It's certainly true that if you have multiple repositories for prefixes = to assign, those repositories will need to transfer more than one /64 at = a time, and it will be desirable to maintain pools of prefixes on these = repositories that are aggregated into larger prefixes. But prefix = _assignment_ will always be a single /64. I suspect that this is the = core of our miscommunication--if you talk about prefix assignment and = prefix distribution as if they are the same thing, which is what we = started out doing, then it's easy to imagine that we are talking about = the same thing when really one of is talking about assignment (me) and = the other about distribution (you). Sorry about that. From nobody Sat Nov 1 06:25: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 0B74F1A888B; Sat, 1 Nov 2014 06:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeEfWXlbW9Li; Sat, 1 Nov 2014 06:25:47 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 589241A887D; Sat, 1 Nov 2014 06:25:46 -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 BOH38236; Sat, 01 Nov 2014 13:25:44 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 1 Nov 2014 13:25:43 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.22]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Sat, 1 Nov 2014 21:25:36 +0800 From: Sheng Jiang To: Ted Lemon Thread-Topic: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15 Thread-Index: AQHP9c/JWER7Zsmwy02ECXH46TnbeZxLwVDx Date: Sat, 1 Nov 2014 13:25:35 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AF6CD60@nkgeml512-mbx.china.huawei.com> References: <544FF8FC.5090103@cisco.com> <95338658-B4F2-4634-AC7B-7B893C4DEF2E@iki.fi> <5D36713D8A4E7348A7E10DF7437A4B923AF6C46E@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AF6C7AE@nkgeml512-mbx.china.huawei.com>, <8490A544-45A9-45D2-9C98-D3CBEB28651D@fugue.com> <5D36713D8A4E7348A7E10DF7437A4B923AF6C8A9@nkgeml512-mbx.china.huawei.com>, <5D36713D8A4E7348A7E10DF7437A4B923AF6CD1B@nkgeml512-mbx.china.huawei.com>, <2DE7FEEE-0060-4EB0-AD81-60B0C63B9A14@fugue.com> In-Reply-To: <2DE7FEEE-0060-4EB0-AD81-60B0C63B9A14@fugue.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.21.246] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/anima/Zko_g3aW2Ok9jDCdiZCoek82K0E Cc: Benoit Claise , "homenet@ietf.org" , Markus Stenberg , "anima@ietf.org" Subject: Re: [Anima] [homenet] ANIMA scope + homenet interaction + charter v15 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, 01 Nov 2014 13:25:53 -0000 Hi, Ted, Yes, we mixed different concepts. Actually, this was a very good discussion= . It gives a very good hints to improve the autonomic prefix management dra= ft. Now, we know prefix management should be at least categoried into prefi= x assignment and prefix distribution. :) Thanks for your participation in t= his discussion. Best regards, Sheng ________________________________________ From: homenet [homenet-bounces@ietf.org] on behalf of Ted Lemon [mellon@fug= ue.com] Sent: 01 November 2014 20:31 To: Sheng Jiang Cc: Benoit Claise; homenet@ietf.org; Markus Stenberg; anima@ietf.org Subject: Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter = v15 On Nov 1, 2014, at 7:41 AM, Sheng Jiang wrote: > But getting back to where we start the discussion, I still think in a lar= ge network, the requesting prefix may not always be /64. It is reasonable t= o have multiple distributed sources for prefix assignment, in a large netwo= rk. Autonomic network use case also includes to manage the prefix resource = among these prefix pools. It's certainly true that if you have multiple repositories for prefixes to = assign, those repositories will need to transfer more than one /64 at a tim= e, and it will be desirable to maintain pools of prefixes on these reposito= ries that are aggregated into larger prefixes. But prefix _assignment_ wi= ll always be a single /64. I suspect that this is the core of our miscomm= unication--if you talk about prefix assignment and prefix distribution as i= f they are the same thing, which is what we started out doing, then it's ea= sy to imagine that we are talking about the same thing when really one of i= s talking about assignment (me) and the other about distribution (you). So= rry about that. _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet= From nobody Sat Nov 1 11:57: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 D5A241A00FD; Sat, 1 Nov 2014 11:57:24 -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 HJKSwK3nGxP4; Sat, 1 Nov 2014 11:57:22 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C90561A00AE; Sat, 1 Nov 2014 11:57:22 -0700 (PDT) Received: by mail-pd0-f177.google.com with SMTP id v10so9101210pde.22 for ; Sat, 01 Nov 2014 11:57:22 -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=GEwD6RNsM9CgHFpFamXFdt12F9/IuDLAZpuSm1X7wxg=; b=OLQ0C4dfEjO3uzEf905jLRi1UxxBH5dYGJBX/CH3w5XyZES5sNTRCChi9FZVFlA7qW DNVm/NJbE8sAJu/EH/Je/Lt4FWAszUK+N7N0NCBwTf772sr9dB4DYvI5fW4nYv5hXV2R 5Zn+bMtyYcCp+tW2ThL+dlbEYRfn4WIw8AL3pmko++P5jxQRuVE21zQXy+N4fco9dkPz CXug8tPFBYxjAHe4s8soceNxmUJZdspv627eGY864A1xig5x1YsVt+34aagNPLnrdzH2 /6fPg3FPNfPFdI0Yar34GmqvuTR5Nf4u6Bvwp9uD7aPATVcKrRS40hdxcLW0yX3yNzJS wNWQ== X-Received: by 10.66.66.234 with SMTP id i10mr4598159pat.44.1414868242517; Sat, 01 Nov 2014 11:57:22 -0700 (PDT) Received: from [192.168.178.23] (26.199.69.111.dynamic.snap.net.nz. [111.69.199.26]) by mx.google.com with ESMTPSA id t11sm13092338pdj.89.2014.11.01.11.57.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 01 Nov 2014 11:57:21 -0700 (PDT) Message-ID: <54552D0B.7050209@gmail.com> Date: Sun, 02 Nov 2014 07:57:15 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Sheng Jiang References: <544FF8FC.5090103@cisco.com> <95338658-B4F2-4634-AC7B-7B893C4DEF2E@iki.fi> <5D36713D8A4E7348A7E10DF7437A4B923AF6C46E@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AF6C7AE@nkgeml512-mbx.china.huawei.com>, <8490A544-45A9-45D2-9C98-D3CBEB28651D@fugue.com> <5D36713D8A4E7348A7E10DF7437A4B923AF6C8A9@nkgeml512-mbx.china.huawei.com>, <5D36713D8A4E7348A7E10DF7437A4B923AF6CD1B@nkgeml512-mbx.china.huawei.com>, <2DE7FEEE-0060-4EB0-AD81-60B0C63B9A14@fugue.com> <5D36713D8A4E7348A7E10DF7437A4B923AF6CD60@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AF6CD60@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/k7ui6gfhoZ9c6jMwQETSjJBP4h4 Cc: Benoit Claise , "homenet@ietf.org" , Markus Stenberg , Ted Lemon , "anima@ietf.org" Subject: Re: [Anima] [homenet] ANIMA scope + homenet interaction + charter v15 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, 01 Nov 2014 18:57:25 -0000 Right. Also of course we should follow the correct architectural principle (that any prefix length is valid) but also the agreed practical position (that the subnet length is normally /64, as discussed in draft-ietf-6man-why64 that was just approved). Brian On 02/11/2014 02:25, Sheng Jiang wrote: > Hi, Ted, > > Yes, we mixed different concepts. Actually, this was a very good discussion. It gives a very good hints to improve the autonomic prefix management draft. Now, we know prefix management should be at least categoried into prefix assignment and prefix distribution. :) Thanks for your participation in this discussion. > > Best regards, > > Sheng > ________________________________________ > From: homenet [homenet-bounces@ietf.org] on behalf of Ted Lemon [mellon@fugue.com] > Sent: 01 November 2014 20:31 > To: Sheng Jiang > Cc: Benoit Claise; homenet@ietf.org; Markus Stenberg; anima@ietf.org > Subject: Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15 > > On Nov 1, 2014, at 7:41 AM, Sheng Jiang wrote: >> But getting back to where we start the discussion, I still think in a large network, the requesting prefix may not always be /64. It is reasonable to have multiple distributed sources for prefix assignment, in a large network. Autonomic network use case also includes to manage the prefix resource among these prefix pools. > > It's certainly true that if you have multiple repositories for prefixes to assign, those repositories will need to transfer more than one /64 at a time, and it will be desirable to maintain pools of prefixes on these repositories that are aggregated into larger prefixes. But prefix _assignment_ will always be a single /64. I suspect that this is the core of our miscommunication--if you talk about prefix assignment and prefix distribution as if they are the same thing, which is what we started out doing, then it's easy to imagine that we are talking about the same thing when really one of is talking about assignment (me) and the other about distribution (you). Sorry about that. > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > From nobody Sun Nov 2 08:57: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 6C7141A8979; Sun, 2 Nov 2014 08:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.194 X-Spam-Level: X-Spam-Status: No, score=-13.194 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, 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 hQxLl5taxwd3; Sun, 2 Nov 2014 08:57:35 -0800 (PST) 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 7B0791A894A; Sun, 2 Nov 2014 08:57:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5743; q=dns/txt; s=iport; t=1414947454; x=1416157054; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=YPBdx8XM6JfyffGBwFyPIWWKTLOpWbL0WatUB0Ei5Nw=; b=TUHtQPUYg+bAbTGalPMCiyxcZA7KsLYnZxgnK5DVOs4X5IuX1BAuITND VPjIPEJx3NpHGNtYJsTSq88RQjBOG35FUbthh/rG7enLhM7e1fSlcB4QU SooO07/G2ycR/xyd2Faa+SAcIKi4MEerc2ZFkN/bDXd/ywgaq07Y4IM/u M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArQEAPBhVlStJssW/2dsb2JhbABZAxaDTFiIYcQ2h00CgSgBAQEBAX2EAwEBBHkQCw4KCSUPAkYGDQEHAQEFiDgNyQYBAQEBAQEBAQEBAQEBAQEBAQEBAQEXkD8BAT8QBxGEOgWWaYcYh3WOW4N5PC8BgQ6BPAEBAQ X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208,217";a="233611958" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 02 Nov 2014 16:57:32 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sA2GvWZC014025; Sun, 2 Nov 2014 16:57:32 GMT Message-ID: <5456627C.30000@cisco.com> Date: Sun, 02 Nov 2014 17:57:32 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Pete Resnick References: <20141030144919.7222.58863.idtracker@ietfa.amsl.com> <54537DDF.4090103@cisco.com> <5453B5EF.2040107@qti.qualcomm.com> In-Reply-To: <5453B5EF.2040107@qti.qualcomm.com> Content-Type: multipart/alternative; boundary="------------080506070703010604080909" Archived-At: http://mailarchive.ietf.org/arch/msg/anima/kfhOsb74bI4kToFHSahtpuf5MjQ Cc: The IESG , anima@ietf.org Subject: Re: [Anima] Pete Resnick's No Objection on charter-ietf-anima-00-17: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 16:57:36 -0000 This is a multi-part message in MIME format. --------------080506070703010604080909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Pete, Done in the version 20, https://datatracker.ietf.org/doc/charter-ietf-anima/ Thanks an regards, Benoit > On 10/31/14 5:17 AM, Benoit Claise wrote: >> Pete, >>> 9th paragraph: >>> >>> Definition of a discovery functionality for autonomic functions >>> >>> I don't understand what that means. By "functionality" do you mean >>> protocol? >>> >>> Brian's response: "Definition of a discovery protocol for autonomic >>> nodes." >> After some more investigation, this was discussed in >> http://www.ietf.org/mail-archive/web/anima/current/msg00454.html, >> >> 1) the choice of the term "functionality" instead of "protocol" >> was used on purpose as to avoid choosing _a priori_ the >> (de)composition in protocol(s). i.e. one _a posteriori_ / >> informed decision will be how to "group" the different >> functionality in one or more protocols (or extension of existing >> ones). >> >> I thought that Laurent had a valid argument. > > Then let's take a shot at rewriting it so that it's clear what the > intention is: > > The goal of this working group shall be to develop one or more > protocol specifications (or extensions to existing protocols) to > address the following problem areas. These were selected to according > to the analyzed technical gaps in draft-irtf-nmrg-an-gap-analysis: > > o Discovery for autonomic nodes > > o Negotiation for autonomic nodes > Starting point: draft-jiang-config-negotiation-protocol > > o Bootstrapping a trust infrastructure > Starting point: draft-pritikin-bootstrapping-keyinfrastructures > > o Separated Autonomic Control Plane > Starting point: draft-behringer-autonomic-control-plane > > pr > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------080506070703010604080909 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Pete,

Done in the version 20, https://datatracker.ietf.org/doc/charter-ietf-anima/

Thanks an regards, Benoit
On 10/31/14 5:17 AM, Benoit Claise wrote:
Pete,
9th paragraph:

   Definition of a discovery functionality for autonomic functions

I don't understand what that means. By "functionality" do you mean
protocol?

Brian's response: "Definition of a discovery protocol for autonomic
nodes."
After some more investigation, this was discussed in http://www.ietf.org/mail-archive/web/anima/current/msg00454.html,
1) the choice of the term "functionality" instead of "protocol" was used on purpose as to avoid choosing a priori the (de)composition in protocol(s). i.e. one a posteriori / informed decision will be how to "group" the different functionality in one or more protocols (or extension of existing ones).
I thought that Laurent had a valid argument.

Then let's take a shot at rewriting it so that it's clear what the intention is:

   The goal of this working group shall be to develop one or more
   protocol specifications (or extensions to existing protocols) to
   address the following problem areas. These were selected to according
   to the analyzed technical gaps in draft-irtf-nmrg-an-gap-analysis:

   o Discovery for autonomic nodes

   o Negotiation for autonomic nodes
      Starting point: draft-jiang-config-negotiation-protocol

   o Bootstrapping a trust infrastructure
      Starting point: draft-pritikin-bootstrapping-keyinfrastructures

   o Separated Autonomic Control Plane
      Starting point: draft-behringer-autonomic-control-plane

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

--------------080506070703010604080909-- From nobody Sun Nov 2 09:44: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 8CA211ABD39; Sun, 2 Nov 2014 09:44:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.694 X-Spam-Level: X-Spam-Status: No, score=-5.694 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, 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 GyV2RFxYea9g; Sun, 2 Nov 2014 09:44:27 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B667E1A8986; Sun, 2 Nov 2014 09:44:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1414950267; x=1446486267; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=ffEr7/giOOWRKmWI5VY9WU1eQuuElHa3Hpb7tLLdlcQ=; b=ZapEjyzCS22rxXr2Fydelg+EVSWxEKhSQFxvdHSmwudCBKGPogjK8hES O3MfLIMay3sPWu4zGK7Q33UQJLmsMvTjfF4cihuaPvFD3kMoy6Tgoa73M VHwDcsmfbpkEZiJuQ9XEGEcmwt3+ZHLxWtFWMuwOdlFN+DUzSLRZ2sVH1 Q=; X-IronPort-AV: E=McAfee;i="5600,1067,7610"; a="77358501" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Nov 2014 09:44:26 -0800 X-IronPort-AV: E=Sophos;i="5.07,295,1413270000"; d="scan'208,217";a="836837693" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 02 Nov 2014 09:44:24 -0800 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc08.na.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sun, 2 Nov 2014 09:44:24 -0800 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Sun, 2 Nov 2014 09:44:23 -0800 Message-ID: <54566D6A.6080002@qti.qualcomm.com> Date: Sun, 2 Nov 2014 11:44:10 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Benoit Claise References: <20141030144919.7222.58863.idtracker@ietfa.amsl.com> <54537DDF.4090103@cisco.com> <5453B5EF.2040107@qti.qualcomm.com> <5456627C.30000@cisco.com> In-Reply-To: <5456627C.30000@cisco.com> Content-Type: multipart/alternative; boundary="------------030707000306060504030900" X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01G.na.qualcomm.com (10.46.200.111) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/anima/gsnsE1HA7yVDckXd7NOx4FebNUI Cc: The IESG , anima@ietf.org Subject: Re: [Anima] Pete Resnick's No Objection on charter-ietf-anima-00-17: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 17:44:29 -0000 --------------030707000306060504030900 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Excellent. Thanks. pr On 11/2/14 10:57 AM, Benoit Claise wrote: > Hi Pete, > > Done in the version 20, > https://datatracker.ietf.org/doc/charter-ietf-anima/ > > Thanks an regards, Benoit >> On 10/31/14 5:17 AM, Benoit Claise wrote: >>> Pete, >>>> 9th paragraph: >>>> >>>> Definition of a discovery functionality for autonomic functions >>>> >>>> I don't understand what that means. By "functionality" do you mean >>>> protocol? >>>> >>>> Brian's response: "Definition of a discovery protocol for autonomic >>>> nodes." >>> After some more investigation, this was discussed in >>> http://www.ietf.org/mail-archive/web/anima/current/msg00454.html, >>> >>> 1) the choice of the term "functionality" instead of "protocol" >>> was used on purpose as to avoid choosing _a priori_ the >>> (de)composition in protocol(s). i.e. one _a posteriori_ / >>> informed decision will be how to "group" the different >>> functionality in one or more protocols (or extension of existing >>> ones). >>> >>> I thought that Laurent had a valid argument. >> >> Then let's take a shot at rewriting it so that it's clear what the >> intention is: >> >> The goal of this working group shall be to develop one or more >> protocol specifications (or extensions to existing protocols) to >> address the following problem areas. These were selected to according >> to the analyzed technical gaps in draft-irtf-nmrg-an-gap-analysis: >> >> o Discovery for autonomic nodes >> >> o Negotiation for autonomic nodes >> Starting point: draft-jiang-config-negotiation-protocol >> >> o Bootstrapping a trust infrastructure >> Starting point: draft-pritikin-bootstrapping-keyinfrastructures >> >> o Separated Autonomic Control Plane >> Starting point: draft-behringer-autonomic-control-plane >> >> pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------030707000306060504030900 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Excellent. Thanks.

pr

On 11/2/14 10:57 AM, Benoit Claise wrote:
Hi Pete,

Done in the version 20, https://datatracker.ietf.org/doc/charter-ietf-anima/

Thanks an regards, Benoit
On 10/31/14 5:17 AM, Benoit Claise wrote:
Pete,
9th paragraph:

   Definition of a discovery functionality for autonomic functions

I don't understand what that means. By "functionality" do you mean
protocol?

Brian's response: "Definition of a discovery protocol for autonomic
nodes."
After some more investigation, this was discussed in http://www.ietf.org/mail-archive/web/anima/current/msg00454.html,
1) the choice of the term "functionality" instead of "protocol" was used on purpose as to avoid choosing a priori the (de)composition in protocol(s). i.e. one a posteriori / informed decision will be how to "group" the different functionality in one or more protocols (or extension of existing ones).
I thought that Laurent had a valid argument.

Then let's take a shot at rewriting it so that it's clear what the intention is:

   The goal of this working group shall be to develop one or more
   protocol specifications (or extensions to existing protocols) to
   address the following problem areas. These were selected to according
   to the analyzed technical gaps in draft-irtf-nmrg-an-gap-analysis:

   o Discovery for autonomic nodes

   o Negotiation for autonomic nodes
      Starting point: draft-jiang-config-negotiation-protocol

   o Bootstrapping a trust infrastructure
      Starting point: draft-pritikin-bootstrapping-keyinfrastructures

   o Separated Autonomic Control Plane
      Starting point: draft-behringer-autonomic-control-plane

pr

-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--------------030707000306060504030900-- From nobody Sun Nov 2 22:07:03 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 0C42C1A0267; Sun, 2 Nov 2014 22:07:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.094 X-Spam-Level: X-Spam-Status: No, score=-15.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, 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 4bIx0hqwzz-S; Sun, 2 Nov 2014 22:06:57 -0800 (PST) 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 BA3AD1A03B3; Sun, 2 Nov 2014 22:06:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16015; q=dns/txt; s=iport; t=1414994816; x=1416204416; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=hYLfVHqGxGRtzPrXX1UAP4Ui+nCgI8z5+84jL18oPyg=; b=VOdMk7SszB1QJ4Ym0pHfLUIZKj61/3+UIY9C0J3Qaq12aPLAWDJazKTv S8TbGFn5NXfkyicLI9paZnRp9hKaLY0n54YU5vv72zfjG4qjKXQwCljkB lhhrFbmmNgCXCJNjjeOr6YMBGc4IR8UEWAihpupn/xILsFCYSo+6ZA2g/ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFACoaV1StJA2D/2dsb2JhbABcgkhGVFgEzUUBCYdNAoEgFgEBAQEBfYQCAQEBBAEBASpBCxACAQgRBAEBCwsSBycLFAkIAgQBDQUIE4gmDck4AQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSQXy0EBgEKgyOBHgWPe4IfhxKbJYI0gURsgUiBAwEBAQ X-IronPort-AV: E=Sophos;i="5.07,305,1413244800"; d="scan'208,217";a="369025854" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-2.cisco.com with ESMTP; 03 Nov 2014 06:06:54 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sA366s2P032145 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Nov 2014 06:06:54 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.159]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Mon, 3 Nov 2014 00:06:54 -0600 From: "Michael Behringer (mbehring)" To: "Benoit Claise (bclaise)" , Stephen Farrell , Brian E Carpenter Thread-Topic: [Anima] Stephen Farrell's No Objection on charter-ietf-anima-00-15: (with COMMENT) Thread-Index: AQHP9EnE5lyivgA220SRAnmLMtYKWJxJpyQAgAAk9YCAAMRUAP//3LNg Date: Mon, 3 Nov 2014 06:06:53 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF21CA3D1C@xmb-rcd-x14.cisco.com> References: <20141030135938.20303.81400.idtracker@ietfa.amsl.com> <5452D190.1060007@gmail.com> <5452F091.3050503@cs.tcd.ie> <54539542.8070607@cisco.com> In-Reply-To: <54539542.8070607@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.134] Content-Type: multipart/alternative; boundary="_000_3AA7118E69D7CD4BA3ECD5716BAF28DF21CA3D1Cxmbrcdx14ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/anima/sKFx8-UiSP_j1L7dqn2_Eh331uw Cc: The IESG , "anima@ietf.org" Subject: Re: [Anima] Stephen Farrell's No Objection on charter-ietf-anima-00-15: (with COMMENT) 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, 03 Nov 2014 06:07:00 -0000 --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF21CA3D1Cxmbrcdx14ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Good wording, I think it brings it to the point. Michael From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Benoit Claise (bcl= aise) Sent: 31 October 2014 14:57 To: Stephen Farrell; Brian E Carpenter Cc: The IESG; anima@ietf.org Subject: Re: [Anima] Stephen Farrell's No Objection on charter-ietf-anima-0= 0-15: (with COMMENT) On 31/10/2014 03:14, Stephen Farrell wrote: On 31/10/14 00:02, Brian E Carpenter wrote: On 31/10/2014 02:59, Stephen Farrell wrote: ... I support Ted's block (I think:-). I suspect that this will be sorted out ok by the WG if it can be, but I'd also like some better clarity on how the security bootstrapping here and in homenet are related/differ. IMHO understanding that (and where draft-ietf-netconf-zerotouch fits in) is part of the first order of business of the WG. I don't think we can resolve it without more technical analysis. Agreed. My remaining, but for-now-ignorable concern relates to the current wording which sort-of tells anima to re-use homenet work in this space - I think it's likely different solutions for security bootstrapping will be needed and so we ought not end up trying to stop work on one such just because another exists, if the use-cases/environments are in reality sufficiently different. I'll try work with Benoit to suggest some better words but do agree that what's really needed is the detailed analysis which needs both WGs doing work and isn't a thing to try fix in either charter. Here is what Stephen and I came up with: OLD: Where suitable protocols, models or methods exist (for example, in the HOME= NET WG), they will be preferred over creating new ones. NEW: ANIMA and HOMENET will need to co-ordinate to ensure that the commonalities= and differences in solutions are properly taken into account. Where suitable protocols, models or methods ex= ist, they will be preferred over creating new ones. This is now in the charter v19 Regards, Benoit S. Brian _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF21CA3D1Cxmbrcdx14ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Good wording, I think it brings it to the point.

=  

= Michael

=  

= From: Anima [mailto:anima-bounces@ietf= .org] On Behalf Of Benoit Claise (= bclaise)
Sent: 31 October 2014 14:57<= br> To: Stephen Farrell; Brian E= Carpenter
Cc: The IESG; anima@ietf.org
Subject: Re: [Anima] Stephen= Farrell's No Objection on charter-ietf-anima-00-15: (with COMMENT)

 

On 31/10/2014 03:14, Stephen Farrell= wrote:

 
 
On 31/10/14 00:02, Brian E Carpenter wrote:
On 31/10/2014 02:59, Stephen Farrell wrote:
...
I support Ted's block (I think:-).  I suspect that th=
is will be sorted
out ok by the WG if it can be, but I'd also like some bett=
er clarity
on how the security bootstrapping here and in homenet are<=
o:p>
related/differ.
 
IMHO understanding that (and where draft-ietf-netconf-zero=
touch
fits in) is part of the first order of business of the WG.=
 I don't
think we can resolve it without more technical analysis.
 
Agreed. My remaining, but for-now-ignorable concern relate=
s to
the current wording which sort-of tells anima to re-use ho=
menet
work in this space - I think it's likely different solutio=
ns
for security bootstrapping will be needed and so we ought =
not end
up trying to stop work on one such just because another ex=
ists,
if the use-cases/environments are in reality sufficiently<=
o:p>
different. I'll try work with Benoit to suggest some bette=
r words
but do agree that what's really needed is the detailed ana=
lysis
which needs both WGs doing work and isn't a thing to try f=
ix in
either charter.

Here is what Stephen and I came up w= ith:

OLD:

Where suitable protocols, models or methods exist (for exa=
mple, in the HOMENET
WG), they will be preferred over creating new ones.

NEW:

ANIMA and HOMENET will need to co-ordinate to ensure that =
the commonalities and differences in solutions are 
properly taken into account. Where suitable =
protocols, models or methods exist, they will be preferred over creating ne=
w ones.

This = is now in the charter v19

Regards, Benoit


 
 
S.
 
 
 
    Brian
 
 
_______________________________________________=

Anima mailing list
Anima@ietf.org<=
/o:p>
ht=
tps://www.ietf.org/mailman/listinfo/anima

 


 
--_000_3AA7118E69D7CD4BA3ECD5716BAF28DF21CA3D1Cxmbrcdx14ciscoc_-- From nobody Mon Nov 3 09:50: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 C54661A6F2F for ; Mon, 3 Nov 2014 09:50:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 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.594, 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 i6DtwSy7kgcq for ; Mon, 3 Nov 2014 09:50:45 -0800 (PST) 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 54F1E1A6F30 for ; Mon, 3 Nov 2014 09:50:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=322; q=dns/txt; s=iport; t=1415037046; x=1416246646; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=1gWI95Vn01+TPUkrRRD9UuEX08m886agXBNC8A/ItTQ=; b=UifwxNcGBO2aQGi1E0ABIzZI9QQcYa50+dTzFmruDnAVa1rDz1tWrbsQ 4U7PE6Bg+ZYSTUj349LX4E0Xtb6fxWJX/ncivvybN8O7wMaeJVIC2GH6V 2911zZTRQWfFlW6cnSIglbtgXHe5yFlOV2hWtrdLkLy3OsKNroWlt9aqy 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFABXAV1StJA2J/2dsb2JhbABcgw5UXM4Gh00CgSMWAQEBAQFyC4QEAQQ6UQEqFEImAQQbiDkNpCqjVQEBAQEBBQEBAQEBAQEXBJBfg2WBHgWSGoRPnWiDeII0gQMBAQE X-IronPort-AV: E=Sophos;i="5.07,308,1413244800"; d="scan'208";a="368889701" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-5.cisco.com with ESMTP; 03 Nov 2014 17:50:45 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sA3Hoivj029161 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 3 Nov 2014 17:50:44 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.159]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Mon, 3 Nov 2014 11:50:44 -0600 From: "Michael Behringer (mbehring)" To: "anima@ietf.org" Thread-Topic: New name for keyinfrastructure bootstrap draft Thread-Index: Ac/3jqaJ+pEgR+mJTYqG4SnFngQrtQ== Date: Mon, 3 Nov 2014 17:50:43 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF21CA532A@xmb-rcd-x14.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/anima/kbRrBKLw9freGg3doPyE-LYJ22Y Subject: [Anima] New name for keyinfrastructure bootstrap draft X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 17:50:47 -0000 FYI: draft-pritikin-bootstrapping-keyinfrastructures-01=20 is now reposted with the name "anima" in the title, content unchanged. New = title:=20 https://tools.ietf.org/html/draft-pritikin-anima-bootstrapping-keyinfra Therefore, it now shows up at:=20 https://datatracker.ietf.org/wg/anima/documents/ Michael From nobody Mon Nov 3 10: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 63BDC1A6F97; Mon, 3 Nov 2014 10:08:45 -0800 (PST) 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 Uzc7zXTRmgHs; Mon, 3 Nov 2014 10:08:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB6501A0235; Mon, 3 Nov 2014 10:08:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Joel Jaeggli" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141103180843.2593.39135.idtracker@ietfa.amsl.com> Date: Mon, 03 Nov 2014 10:08:43 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/anima/gmhcrx_iG1x3YDEqmh5acKLWt8M Cc: anima@ietf.org Subject: [Anima] Joel Jaeggli's Block on charter-ietf-anima-00-21: (with BLOCK and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 18:08:45 -0000 Joel Jaeggli has entered the following ballot position for charter-ietf-anima-00-21: Block When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-anima/ ---------------------------------------------------------------------- BLOCK: ---------------------------------------------------------------------- Removing block, no longer required. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Was: Holding the block in this WG format to allow time for solicited feedback on the updated charter. >From Benoit, Comment (2014-10-29) Charter v15 has been posted, hopefully addressing the latest issues. As discussed with Ted, Joel and me, we need to make sure that: 1. the (perceived) overlap with the HOMENET is clarified 2. the HOMENET community provides some feedback on v15 Therefore, Ted will be holding a BLOCK until the two conditions are met. From nobody Mon Nov 3 13:36: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 81A181A06FD for ; Mon, 3 Nov 2014 13:36:43 -0800 (PST) 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 tSHRS_rv-IQR for ; Mon, 3 Nov 2014 13:36:42 -0800 (PST) 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 245A21A0A6A for ; Mon, 3 Nov 2014 13:36:42 -0800 (PST) Received: by mail-pa0-f52.google.com with SMTP id fa1so12832364pad.25 for ; Mon, 03 Nov 2014 13:36:41 -0800 (PST) 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=1pfSA/36dU7rD72P5hWHPaJ8A2CkLzs4SOTm/JQBKSA=; b=wjxlQkFN7YsaUPcz61Jb+tJkGua61dOhKWKvnPnY4RRhEtEc3AF99EN9cLysbsyd42 Xd87YVb6D8Gs/hGU3xXZXFK5xSf93/qLEyYvUoQg70l3aVQyTDj/nLdsk3EoNVC5zO4d 27olN11n+gh2sGWKdpDVmntxNJyZg1hQKnTcg6MdY9+Ybgv03vQBx6ZHk788w8D9jg3W obnmiKVC/WjaPP6aN5hRXRD9kEjlQiy+257C/g5GHkE3B6PspjYI2ftn4ZQUF0kysupN dUhTuZAPf9yY2BU8uvAMh9vHqJP+oCKiJK4HDfzf2wfC+NXkoP6Lm6E6C93fz++zuz8K OXUQ== X-Received: by 10.68.136.137 with SMTP id qa9mr38649668pbb.8.1415050601639; Mon, 03 Nov 2014 13:36:41 -0800 (PST) Received: from [130.216.38.108] (sc-cs-567-laptop.cs.auckland.ac.nz. [130.216.38.108]) by mx.google.com with ESMTPSA id u9sm18085760pdr.16.2014.11.03.13.36.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Nov 2014 13:36:40 -0800 (PST) Message-ID: <5457F566.4080409@gmail.com> Date: Tue, 04 Nov 2014 10:36:38 +1300 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: <20141017131337.4423.84144.idtracker@ietfa.amsl.com> In-Reply-To: <20141017131337.4423.84144.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/0Zk80ddGdHCY-tcLxrFmeQ9g5mY Subject: Re: [Anima] I-D Action: draft-behringer-anima-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, 03 Nov 2014 21:36:43 -0000 Hi, This draft seems fairly clear to me, though I assume it will evolve as other aspects of anima become clear. The proposal to use a ULA prefix (section 3.7) seems good, since it decouples the ACP from all external addressing considerations and will work from a pure factory-reset condition. However, it does raise a question (which also came up in homenet recently). What happens if the network partitions? The ACP will automatically partition too, but it will presumably keep the same /48 ULA prefix everywhere. Does the partitioned network retain the same domain ID in both parts? What happends in the part that doesn't include the trust anchor? What happens if the network recombines - will there be a risk of clashing subnets created during the partition? Also what happens if two previously unrelated networks combine? Brian From nobody Mon Nov 3 13:40:55 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 79C2F1A1A00 for ; Mon, 3 Nov 2014 13:40:46 -0800 (PST) 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 0aNJc1N1qyWd for ; Mon, 3 Nov 2014 13:40:41 -0800 (PST) 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 549AF1A19E3 for ; Mon, 3 Nov 2014 13:40:41 -0800 (PST) Received: by mail-pd0-f182.google.com with SMTP id fp1so12320564pdb.13 for ; Mon, 03 Nov 2014 13:40:41 -0800 (PST) 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=qcXVfsvY/B0s5reVM3QjDuEgphgWbFsLQvoQIe9fbhk=; b=SH85q6O+7Nbt5MrDn9JUlX5UzcGrs4/8fZ+b9V7IbaxojPTAC8voQt9qXx6Pvn5L2r PszxhQUre/vE8ayhkpqV5iFgpNsmBVaAwzSld0XIXBLSOjIzUhwtzyt0XGbF1TNvkKJj lKKqYxuLlNYFScx/7j1zQHglTICKEEklct+GjKOenK6b1vapTV/ZkYl4Qf45BFB/gVjo RDsF3EJ6yHuECh51ks/taPhigve8mpZId+KUTD3tr/DTGCXhNhXvRL00Iox5nPLsiEtp DmJzAggOO7um9XLEpM13jQDJp9k+TC60p2bVzPsB8h645fSobAdckP1gv8MippgGZg4V xe/g== X-Received: by 10.66.146.71 with SMTP id ta7mr46035756pab.16.1415050841031; Mon, 03 Nov 2014 13:40:41 -0800 (PST) Received: from [130.216.38.108] (sc-cs-567-laptop.cs.auckland.ac.nz. [130.216.38.108]) by mx.google.com with ESMTPSA id zw1sm17957420pbb.82.2014.11.03.13.40.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Nov 2014 13:40:39 -0800 (PST) Message-ID: <5457F654.5040201@gmail.com> Date: Tue, 04 Nov 2014 10:40:36 +1300 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: <20141027014624.3213.36345.idtracker@ietfa.amsl.com> In-Reply-To: <20141027014624.3213.36345.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/zVsB9826xJhOfUcZO1X4zlZQpuY Subject: Re: [Anima] I-D Action: draft-eckert-anima-stable-connectivity-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, 03 Nov 2014 21:40:47 -0000 Hi, I think my main comment right now on this draft is: please change the title and maybe expand the abstract. It would definitely help if the title mentioned OAM, because at the moment it seems to make a very general claim but the intended applicability is more limited. Brian From nobody Mon Nov 3 13:56: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 9E2C11A1A12 for ; Mon, 3 Nov 2014 13:56:42 -0800 (PST) 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 NsLee6KlMPuP for ; Mon, 3 Nov 2014 13:56:40 -0800 (PST) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41A9D1A0396 for ; Mon, 3 Nov 2014 13:56:40 -0800 (PST) Received: by mail-pa0-f47.google.com with SMTP id kx10so12991558pab.20 for ; Mon, 03 Nov 2014 13:56:39 -0800 (PST) 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=bgVP/p/mcVWBJxyS1/4foeHllKcsECPW3G+Lq9siCCI=; b=0Y8o8u8MpV01L0AG7faL6uHj4oX7lOnOhgXZ65U5lmr2d2BXdQA9qmBSL0Ysqei4Tu nKops2v6RgqWKI9N4NT2Dt0FtimLAtzBaXFkKEfDej7z+KwbS2XEi2QOkoi6qb+Phf0E AFZgqYUV3mbzshVdg7VvwHSfOG7+vsDD9Kj2g7ibQAY+RpBgdjU/YTMI1pSipDx2WosS 2gzwroXVwNxNARrAAZQSN49BK9CVOfbH+0W2nI8FRl4Uo5TwkcksvT0TEeprPo39KX4o qJ6cCHwrmi03vhHlszFl6Kgrpc46/aB1n+2EgDyxNSBR/mG27gO7AhZOIsmb3Rsiim3J MTUg== X-Received: by 10.66.180.166 with SMTP id dp6mr11956884pac.101.1415051799896; Mon, 03 Nov 2014 13:56:39 -0800 (PST) Received: from [130.216.38.108] (sc-cs-567-laptop.cs.auckland.ac.nz. [130.216.38.108]) by mx.google.com with ESMTPSA id y2sm18098184pdp.31.2014.11.03.13.56.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Nov 2014 13:56:35 -0800 (PST) Message-ID: <5457FA11.7080505@gmail.com> Date: Tue, 04 Nov 2014 10:56:33 +1300 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: <20141017123010.13535.14361.idtracker@ietfa.amsl.com> In-Reply-To: <20141017123010.13535.14361.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/pcArTSvn_KCCzlNS6gEy9mixIWA Subject: Re: [Anima] I-D Action: draft-behringer-anima-reference-model-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, 03 Nov 2014 21:56:42 -0000 Hi, Yes, I know I'm an author of this draft, but I thought I'd mention my comments on the list anyway, since there was a bit of a rush to get it out before the cutoff. > Abstract > > This document describes a reference model for Autonomic Networking. > The goal is to define how the various elements in an autonomic > context work together, to describe their interfaces and relations. Perhaps we should add that the document is written as generally as possible but the initial solutions are limited to the chartered scope of the WG. We should probably repeat that in the Introduction, plus a note that it is a living document that will not be finalised until the initial technical solutions are stable. I hope that we can fill in the TBD items over the next 12 months. > o MASA: The MASA is service... Expand the abbreviation when first used. > 7.5. Feedback Loops > > Feedback loops are required in an autonomic network to allow > administrator intervention, while maintaining a default behaviour. > Through a feedback loop an administrator can be prompted with a > default action, and has the possibility to acknowledge or override > the proposed default action. I found this a bit confusing, because we also have closed loops in autonomic systems, which can also be described as "feedback loops". Maybe we can just rewrite this using "human intervention". Also I wonder whether we prefer "operator" or "administrator"? They have slightly different nuances. Brian Regards Brian From nobody Mon Nov 3 15:13: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 32B151A8859 for ; Mon, 3 Nov 2014 15:13:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 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.594, 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 ZTpWvsWWB3SH for ; Mon, 3 Nov 2014 15:13:10 -0800 (PST) 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 573431A8853 for ; Mon, 3 Nov 2014 15:13:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=592; q=dns/txt; s=iport; t=1415056389; x=1416265989; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=JQJUTq26cHslLji9oMriIqP5X6VEYpEN2Qn2Miozzg4=; b=N4+8SD2AkbA78BXKsp1o3czPWA4baNK1G/KqWmSdbbjjJobHL4nlZ+cj 6xJi4lroFxLkOkKcUscjcTCz6x2XCXWeOO/VB7QouHTbNifQnkGQinZys SpYJe4qpeyZlv9UI27grGokQ2Fi5vpy8pCo3gn9vok5DrNFGGo2253vd/ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar0EANALWFStJssW/2dsb2JhbABchDrVboE7AQEBAQFyC4RBQAE8FhgDAgECAUsNAQUCAQGIPcsqAQEBAQEBAQMBAQEBAQEckC4RAVCEUgEEngGBMYNNgneOW4N5PC+BD4E8AQEB X-IronPort-AV: E=Sophos;i="5.07,310,1413244800"; d="scan'208";a="234454757" 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; 03 Nov 2014 23:12:47 +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 sA3NCkef016492; Mon, 3 Nov 2014 23:12:47 GMT Message-ID: <54580BEE.4090403@cisco.com> Date: Tue, 04 Nov 2014 00:12:46 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.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/yASk597j27_TbHP4OZK9WRTXZok Cc: Joel jaeggli Subject: [Anima] ANIMA charter v21 approved for WG creation 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, 03 Nov 2014 23:13:12 -0000 Dear all, I just sent the email to the IESG secretariat to approve the charter v21 for WG creation. I would like to thanks everybody involved in the creation of this new WG, and specifically Brian Carpenter and Michael Behringer, the two UCAN BoF chairs who have been driving this effort from day one. Please note that the two WG chairs are Sheng Jiang Toerless Eckert Now that we have a WG, the two chairs and I will be setting up the agenda ASAP. Let the work begin ... or continue in this case. Regards, Benoit From nobody Mon Nov 3 15:21: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 774921A8876 for ; Mon, 3 Nov 2014 15:21:12 -0800 (PST) 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 zQs91OK6TJrk for ; Mon, 3 Nov 2014 15:21:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 84C631A8878 for ; Mon, 3 Nov 2014 15:21:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141103232110.27767.81062.idtracker@ietfa.amsl.com> Date: Mon, 03 Nov 2014 15:21:10 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/anima/NeV8omRBgtpOMudb4SrHtserp18 Subject: [Anima] Milestones changed for anima WG X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 23:21:12 -0000 Added milestone "Adoption of initial drafts on AN components: Discovery and negotiation protocol(s), Bootstrap a trust infrastructure solution, Autonomic control plane solution", due March 2015. Added milestone "Adoption of reference model", due July 2015. Added milestone "Adoption of the two validation drafts", due July 2015. Added milestone "Submit discovery and negotiation protocol(s) to IESG (Standards Track)", due April 2016. Added milestone "Submit bootstrap a trust infrastructure solution to IESG (Standards Track)", due April 2016. Added milestone "Submit the two validation drafts to IESG (Informational)", due September 2016. Added milestone "Submit autonomic control plane solution to IESG (Standards Track)", due September 2016. Added milestone "Submit reference model to IESG (Informational)", due December 2016. Added milestone "recharter to refocus scope, or close", due December 2016. URL: http://datatracker.ietf.org/wg/anima/charter/ From nobody Mon Nov 3 15:32: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 298761A8876; Mon, 3 Nov 2014 15:32:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSpY2x9CyVCW; Mon, 3 Nov 2014 15:32:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8530F1A887E; Mon, 3 Nov 2014 15:32:24 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.7.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141103233224.27774.9837.idtracker@ietfa.amsl.com> Date: Mon, 03 Nov 2014 15:32:24 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/anima/ZmJrprreg30nJ7cN3D5pRrX15GY Cc: anima WG Subject: [Anima] WG Action: Formed Autonomic Networking Integrated Model and Approach (anima) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 23:32:29 -0000 A new IETF working group has been formed in the Operations and Management Area. For additional information please contact the Area Directors or the WG Chairs. Autonomic Networking Integrated Model and Approach (anima) ------------------------------------------------ Current Status: BOF WG Chairs: Toerless Eckert Sheng Jiang Assigned Area Director: Benoit Claise Mailing list Address: anima@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/anima Archive: http://www.ietf.org/mail-archive/web/anima/ Charter: Autonomic networking refers to the self-managing characteristics (configuration, protection, healing, and optimization) of distributed network elements, adapting to unpredictable changes while hiding intrinsic complexity from operators and users. Autonomic Networking, which often involves closed-loop control, is applicable to the complete network (functions) lifecycle (e.g. installation, commissioning, operating, etc). An autonomic function that works in a distributed way across various network elements is a candidate for protocol design. Such functions should allow central guidance and reporting, and co-existence with non-autonomic methods of management. The general objective of this working group is to enable the progressive introduction of autonomic functions into operational networks, as well as reusable autonomic network infrastructure, in order to reduce the OpEx. This work builds on definitions and design goals, as well as a simple architecture model undertaken in the Network Management Research Group (NMRG) of the IRTF (See draft-irtf-nmrg-an-gap-analysis and its companion draft-irtf-nmrg-autonomic-network-definitions). Elements of autonomic functions already exist today. However, all such functions today have their own discovery, node identification, negotiation, transport, messaging and security mechanisms as well as non-autonomic management interfaces. There is no common infrastructure for distributed functions. This leads to inefficiencies. Additionally, management and optimisation of operational device configurations is expensive, tedious, and prone to human error. A simple example is assigning address prefixes to network segments in a large and constantly changing network. Similarly, repair or bypassing of faults requires human intervention and causes significant down time. This WG will develop a system of autonomic functions that carry out the intentions of the network operator without the need for detailed low- level management of individual devices. This will be done by providing a secure closed-loop interaction mechanism whereby network elements cooperate directly to satisfy management intent. The working group will develop a control paradigm where network processes coordinate their decisions and automatically translate them into local actions, based on various sources of information including operator-supplied configuration information or from the existing protocols, such as routing protocol, etc. While a complete solution for full autonomic networking is an ambitious goal, the initial scope of this working group's effort is much more modest: the specification of a minimum set of specific reusable infrastructure components to support autonomic interactions between devices, and to specify the application of these components to one or two elementary use cases of general value. Practically, these components should be capable of providing the following services to those distributed functions: o a common way to identify nodes o a common security model o a discovery mechanism o a negotiation mechanism to enable closed-loop interaction o a secure and logically separated communications channel o a consistent autonomic management model ANIMA and HOMENET will need to co-ordinate to ensure that the commonalities and differences in solutions are properly taken into account. Where suitable protocols, models or methods exist, they will be preferred over creating new ones. It is preferred that autonomic functions would co-exist with traditional methods of management and configuration, and the initial focus would be on self-configuration. Future work may include a more detailed systems architecture to support the development of autonomic service agents. The ANIMA working group focuses on professionally-managed networks. Like traditional network management, the topological scope of autonomic functions is expected to be limited by administrative boundaries. The goal of this working group shall be to develop one or more protocol specifications (or extensions to existing protocols) to address the following problem areas. These were selected to according to the analyzed technical gaps in draft-irtf-nmrg-an-gap-analysis: o Discovery for autonomic nodes o Negotiation for autonomic nodes Starting point: draft-carpenter-anima-gdn-protocol o Bootstrapping a trust infrastructure Starting point: draft-pritikin-anima-bootstrapping-keyinfra o Separated Autonomic Control Plane Starting point: draft-behringer-anima-autonomic-control-plane The design of these proposals should clearly target reusability. In addition, the WG will validate the application and reusability of the components to the following two use cases: o A solution for distributed IPv6 prefix management within a large-scale network. Although prefix delegation is currently supported, it relies on human action to subdivide and assign prefixes according to local requirements, and this process could become autonomic. o A solution for always-on, data plane independent connectivity between network elements (i.e., stable in the case of mis-configurations), which can be used for call home, network provisioning, or simply trouble- shooting. It is essential that these components and solutions fit together as an integrated whole. For this reason, a reference document will be developed in parallel with the individual specifications. The initial set of work items is limited to the above list to stay focused and avoid "boiling the ocean". Additional documents concerning other autonomic infrastructure components, policy intent, use cases or autonomic service agents are strongly encouraged, as individual submissions, or as submissions to the IRTF Network Network Management Research Group. Additional work items may only be added with approval from the responsible Area Director or by re-chartering. Milestones: Mar 2015 - Adoption of initial drafts on AN components: Discovery and negotiation protocol(s), Bootstrap a trust infrastructure solution, Autonomic control plane solution Jul 2015 - Adoption of reference model Jul 2015 - Adoption of the two validation drafts Apr 2016 - Submit discovery and negotiation protocol(s) to IESG (Standards Track) Apr 2016 - Submit bootstrap a trust infrastructure solution to IESG (Standards Track) Sep 2016 - Submit the two validation drafts to IESG (Informational) Sep 2016 - Submit autonomic control plane solution to IESG (Standards Track) Dec 2016 - Submit reference model to IESG (Informational) Dec 2016 - recharter to refocus scope, or close From nobody Tue Nov 4 02:11:02 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 204531A8946 for ; Tue, 4 Nov 2014 02:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.094 X-Spam-Level: X-Spam-Status: No, score=-15.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, 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 M79zhvceDVh1 for ; Tue, 4 Nov 2014 02:10:58 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 180881A1A2E for ; Tue, 4 Nov 2014 02:10:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10233; q=dns/txt; s=iport; t=1415095858; x=1416305458; h=from:to:cc:subject:date:message-id:mime-version; bh=fh+QSkCsium9Sy9JacpLh69xOdgjurg3w/P23P+pdc0=; b=FIwg9lDTHkWMau/ooO3jW4aPhtxI7Gw2sfhdamfgXeEtUFTJRqhfGSBo is2kJiQZKEwZuGzEpkdTcGRU+/tiPNDxr0gNC5Yp7+AlrYhBnxMV/laPg OObTJmqyUXRjbx24WSTGFbMoRDxDDUDSRkQiHIO5UqTFM6I9+u+QMFiYz A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigGAE2lWFStJA2F/2dsb2JhbABCFwOCSEZUWASDAstSh0sCHIEFFgEBAQEBcguEBAECAiMGBDkCEQ4EAQIoCgQMBgIEGRckAgEBAw4NiDkNOLVthVCPYwEBAQEBAQEBAQEBAQEBAQEBAQEBARcEjm+BWRMWCwwEGAeCXzaBHgWLPIZkhE9Wg26EBRKDOpFSgyVTbAGBBQQ+gQMBAQE X-IronPort-AV: E=Sophos; i="5.07,312,1413244800"; d="scan'208,217"; a="93133794" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-3.cisco.com with ESMTP; 04 Nov 2014 10:10:57 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id sA4AAvS9003150 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Nov 2014 10:10:57 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.140]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Tue, 4 Nov 2014 04:10:56 -0600 From: "Michael Behringer (mbehring)" To: "anima@ietf.org" Thread-Topic: ANIMA conference call Thread-Index: Ac/MyrnKyiSCV2OiSR6hGuZVGkOSiArTOTcQ Importance: high X-Priority: 1 Date: Tue, 4 Nov 2014 10:10:56 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF21CA601D@xmb-rcd-x14.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.134] Content-Type: multipart/alternative; boundary="_000_3AA7118E69D7CD4BA3ECD5716BAF28DF21CA601Dxmbrcdx14ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/anima/Ge32gBUQxjaualoydNh_CnfreYc Cc: 'Hesham ElBakoury' , "'Henderickx, Wim \(Wim\)'" , Dean Bogdanovic , "Fuyu \(Eleven\)" , "'Laurent.Ciavaglia@alcatel-lucent.com'" Subject: [Anima] Canceled: ANIMA conference call 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, 04 Nov 2014 10:11:00 -0000 --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF21CA601Dxmbrcdx14ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Given that we have a WG now, Benoit has suggested that we cancel this meeti= ng, since it's not appropriate any more. See you all next Monday in Honolulu! Michael Host key: 873069 Join WebEx meeting Meeting number: 306 341 917 Meeting password: anima Join bTy phone +1-866-432-9903 Call-in toll-free number (US/Canada) +1-408-525-6800 Call-in toll number (US/Canada) Access code: 306 341 917 Global call-in numbers | Toll-free calling restrictions= Can't join the meeting? Contact support. IMPORTANT NOTICE: Please note that this WebEx service allows audio and othe= r information sent during the session to be recorded, which may be discover= able in a legal matter. You should inform all meeting attendees prior to re= cording if you intend to record the meeting. --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF21CA601Dxmbrcdx14ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Given that we have a WG now, Benoit has sugges= ted that we cancel this meeting, since it’s not appropriate any more.=
 
See you all next Monday in Honolulu!
 
Michael
 
Host key: 873069 
Join WebEx meeting
Meeting number:  306 341 917   &= nbsp; 
Meeting password:     = ;  anima  
 
 
Join bTy phone 
+1-866-432-9903 Call-in toll-free number (US/Ca= nada) 
+1-408-525-6800 Call-in toll number (US/Canada)=  
Access code: 306 341 917 
= Global call-in numbers  |  Toll-free calling restrictions  


 
Can't join the meeting? Contact support.  
 
IMPORTANT NOTICE: Please note that this WebEx servi= ce allows audio and other information sent during the session to be recorde= d, which may be discoverable in a legal matter. You should inform all meeti= ng attendees prior to recording if you intend to record the meeting.
&nbs= p;
&nbs= p;
 --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF21CA601Dxmbrcdx14ciscoc_ Content-Type: text/calendar; charset="utf-8"; method=CANCEL Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpNRVRIT0Q6Q0FOQ0VMDQpQUk9ESUQ6TWljcm9zb2Z0IEV4Y2hhbmdl IFNlcnZlciAyMDEwDQpWRVJTSU9OOjIuMA0KQkVHSU46VlRJTUVaT05FDQpUWklEOlJvbWFuY2Ug U3RhbmRhcmQgVGltZQ0KQkVHSU46U1RBTkRBUkQNCkRUU1RBUlQ6MTYwMTAxMDFUMDMwMDAwDQpU Wk9GRlNFVEZST006KzAyMDANClRaT0ZGU0VUVE86KzAxMDANClJSVUxFOkZSRVE9WUVBUkxZO0lO VEVSVkFMPTE7QllEQVk9LTFTVTtCWU1PTlRIPTEwDQpFTkQ6U1RBTkRBUkQNCkJFR0lOOkRBWUxJ R0hUDQpEVFNUQVJUOjE2MDEwMTAxVDAyMDAwMA0KVFpPRkZTRVRGUk9NOiswMTAwDQpUWk9GRlNF VFRPOiswMjAwDQpSUlVMRTpGUkVRPVlFQVJMWTtJTlRFUlZBTD0xO0JZREFZPS0xU1U7QllNT05U SD0zDQpFTkQ6REFZTElHSFQNCkVORDpWVElNRVpPTkUNCkJFR0lOOlZFVkVOVA0KT1JHQU5JWkVS O0NOPU1pY2hhZWwgQmVocmluZ2VyIChtYmVocmluZyk6TUFJTFRPOm1iZWhyaW5nQGNpc2NvLmNv bQ0KQVRURU5ERUU7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JT VlA9VFJVRTtDTj1hbmltYUBpZXRmDQogLm9yZzpNQUlMVE86YW5pbWFAaWV0Zi5vcmcNCkFUVEVO REVFO1JPTEU9T1BULVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7 Q049J0hlc2hhbSBFbA0KIEJha291cnknOk1BSUxUTzpIZXNoYW0uRWxCYWtvdXJ5QGh1YXdlaS5j b20NCkFUVEVOREVFO1JPTEU9T1BULVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtS U1ZQPVRSVUU7Q049J0xhdXJlbnQuQw0KIGlhdmFnbGlhQGFsY2F0ZWwtbHVjZW50LmNvbSc6TUFJ TFRPOkxhdXJlbnQuQ2lhdmFnbGlhQGFsY2F0ZWwtbHVjZW50LmNvbQ0KQVRURU5ERUU7Uk9MRT1P UFQtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9VFJVRTtDTj0iJ0hlbmRl cmljaw0KIHgsIFdpbSAoV2ltKSciOk1BSUxUTzp3aW0uaGVuZGVyaWNreEBhbGNhdGVsLWx1Y2Vu dC5jb20NCkFUVEVOREVFO1JPTEU9T1BULVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElP TjtSU1ZQPVRSVUU7Q049RGVhbiBCb2dkYQ0KIG5vdmljOk1BSUxUTzpkZWFuYkBqdW5pcGVyLm5l dA0KQVRURU5ERUU7Uk9MRT1PUFQtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JT VlA9VFJVRTtDTj1GdXl1IChFbGV2DQogZW4pOk1BSUxUTzplbGV2ZW4uZnV5dUBodWF3ZWkuY29t DQpERVNDUklQVElPTjtMQU5HVUFHRT1lbi1VUzpHaXZlbiB0aGF0IHdlIGhhdmUgYSBXRyBub3dc LCBCZW5vaXQgaGFzIHN1Z2dlc3QNCiBlZCB0aGF0IHdlIGNhbmNlbCB0aGlzIG1lZXRpbmdcLCBz aW5jZSBpdOKAmXMgbm90IGFwcHJvcHJpYXRlIGFueSBtb3JlLlxuXA0KIG5TZWUgeW91IGFsbCBu ZXh0IE1vbmRheSBpbiBIb25vbHVsdSFcblxuTWljaGFlbFxuXG5cbkhvc3Qga2V5OiA4NzMwNjlc bkpvDQogaW4gV2ViRXggbWVldGluZzxodHRwczovL2Npc2NvLndlYmV4LmNvbS9jaXNjby9qLnBo cD9NVElEPW0wM2M1OTNmZTEwNGViYjMNCiA3Yjc4NGJmMWQ4MDA5NmMxNT5cbk1lZXRpbmcgbnVt YmVyOiAgICAgICAgIDMwNiAzNDEgOTE3XG5NZWV0aW5nIHBhc3N3b3JkOg0KICAgICAgICBhbmlt YVxuXG5cbkpvaW4gYlR5IHBob25lXG4rMS04NjYtNDMyLTk5MDMgQ2FsbC1pbiB0b2xsLWZyZWUg bnVtYmVyDQogIChVUy9DYW5hZGEpXG4rMS00MDgtNTI1LTY4MDAgQ2FsbC1pbiB0b2xsIG51bWJl ciAoVVMvQ2FuYWRhKVxuQWNjZXNzIGNvZGUNCiA6IDMwNiAzNDEgOTE3XG5HbG9iYWwgY2FsbC1p biBudW1iZXJzPGh0dHBzOi8vY2lzY28ud2ViZXguY29tL2Npc2NvL2dsb2JhbA0KIGNhbGxpbi5w aHA/c2VydmljZVR5cGU9TUMmRUQ9MjExMTI2NzEzJnRvbGxGcmVlPTE+ICB8ICBUb2xsLWZyZWUg Y2FsbGluZyByDQogZXN0cmljdGlvbnM8aHR0cDovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxmcmVl X3Jlc3RyaWN0aW9ucy5wZGY+XG5cblxuXG5DYW4NCiAndCBqb2luIHRoZSBtZWV0aW5nPyBDb250 YWN0IHN1cHBvcnQuPGh0dHBzOi8vY2lzY28ud2ViZXguY29tL2Npc2NvL21jPlxuXA0KIG5JTVBP UlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxvd3Mg YXVkaW8gYW5kIG90DQogaGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRv IGJlIHJlY29yZGVkXCwgd2hpY2ggbWF5IGJlIGRpc2MNCiBvdmVyYWJsZSBpbiBhIGxlZ2FsIG1h dHRlci4gWW91IHNob3VsZCBpbmZvcm0gYWxsIG1lZXRpbmcgYXR0ZW5kZWVzIHByaW9yIA0KIHRv IHJlY29yZGluZyBpZiB5b3UgaW50ZW5kIHRvIHJlY29yZCB0aGUgbWVldGluZy5cblxuXG4NClNV TU1BUlk7TEFOR1VBR0U9ZW4tVVM6Q2FuY2VsZWQ6IEFOSU1BIGNvbmZlcmVuY2UgY2FsbA0KRFRT VEFSVDtUWklEPVJvbWFuY2UgU3RhbmRhcmQgVGltZToyMDE0MTEwNlQwODAwMDANCkRURU5EO1Ra SUQ9Um9tYW5jZSBTdGFuZGFyZCBUaW1lOjIwMTQxMTA2VDA5MDAwMA0KVUlEOjA0MDAwMDAwODIw MEUwMDA3NEM1QjcxMDFBODJFMDA4MDAwMDAwMDA5MDAyNTM3RERCQ0NDRjAxMDAwMDAwMDAwMDAw MDAwDQogMDEwMDAwMDAwODQxRDk4QjEyQzg3N0I0REIwQUE2NDU2ODg0MThCMTgNClJFQ1VSUkVO Q0UtSUQ7VFpJRD1Sb21hbmNlIFN0YW5kYXJkIFRpbWU6MjAxNDExMDZUMDgwMDAwDQpDTEFTUzpQ VUJMSUMNClBSSU9SSVRZOjENCkRUU1RBTVA6MjAxNDExMDRUMTAxMDU1Wg0KVFJBTlNQOk9QQVFV RQ0KU1RBVFVTOkNBTkNFTExFRA0KU0VRVUVOQ0U6Mg0KTE9DQVRJT047TEFOR1VBR0U9ZW4tVVM6 aHR0cHM6Ly9jaXNjby53ZWJleC5jb20vY2lzY28NClgtTUlDUk9TT0ZULUNETy1BUFBULVNFUVVF TkNFOjINClgtTUlDUk9TT0ZULUNETy1PV05FUkFQUFRJRDoxNTYwOTc1MzI2DQpYLU1JQ1JPU09G VC1DRE8tQlVTWVNUQVRVUzpGUkVFDQpYLU1JQ1JPU09GVC1DRE8tSU5URU5ERURTVEFUVVM6RlJF RQ0KWC1NSUNST1NPRlQtQ0RPLUFMTERBWUVWRU5UOkZBTFNFDQpYLU1JQ1JPU09GVC1DRE8tSU1Q T1JUQU5DRToyDQpYLU1JQ1JPU09GVC1DRE8tSU5TVFRZUEU6Mw0KWC1NSUNST1NPRlQtRElTQUxM T1ctQ09VTlRFUjpGQUxTRQ0KRU5EOlZFVkVOVA0KRU5EOlZDQUxFTkRBUg0K --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF21CA601Dxmbrcdx14ciscoc_-- From nobody Tue Nov 4 07:03:10 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 22DF71A8954 for ; Tue, 4 Nov 2014 07:03:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 7vqq5ecOgJcY for ; Tue, 4 Nov 2014 07:03:07 -0800 (PST) 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 50B801A8910 for ; Tue, 4 Nov 2014 07:03:07 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOK24279; Tue, 04 Nov 2014 15:03:05 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 4 Nov 2014 15:03:05 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.22]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Tue, 4 Nov 2014 23:03:00 +0800 From: Sheng Jiang To: "anima@ietf.org" Thread-Topic: Agenda for ANIMA WG meeting in IETF 91 Thread-Index: Ac/4QGwoTZaYey0lTui05s3dHi2D8Q== Date: Tue, 4 Nov 2014 15:02:59 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AF6E5FA@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.18.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/anima/YBuY22JJCmdKzmq7RtGyTSCtACM Subject: [Anima] Agenda for ANIMA WG meeting in IETF 91 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, 04 Nov 2014 15:03:09 -0000 Hi, all, we have uploaded the agenda for ANIMA WG meeting in IETF 91. Speaker inform= ation will be added after confirmation. https://datatracker.ietf.org/meeting/91/agenda/anima/ 1. Agenda bashing (5 min) 2. Area Director introduction (Benoit, 10 min) 3. NMRG Documents status (5 min) 4. Autonomic functions/requirements in homenet + Questions/Answers (30 min) (speaker to be confirmed) 5. WG chartered work items (120 min, 18 min each for 6 drafts, 8 min for pr= esentation + 10 min for discussion, 10 min for zerotouch) A Generic Discovery and Negotiation Protocol for Autonomic Networking (draft-carpenter-anima-gdn-protocol) An Autonomic Control Plane (draft-behringer-anima-autonomic-control-plane) Bootstrapping Key Infrastructures (draft-pritikin-anima-bootstrapping-keyinfra) Zero Touch Provisioning for NETCONF Call Home (to be confirmed, 10 min) (draft-ietf-netconf-zerotouch) A Reference Model for Autonomic Networking (draft-behringer-anima-reference-model) Autonomic Network Stable Connectivity (draft-eckert-anima-stable-connectivity) Autonomic Prefix Management in Large-scale Networks (draft-jiang-anima-prefix-management) 6. Closing (10 min) Best regards, Sheng + Toerless= From nobody Tue Nov 4 17:06: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 CF9871A1AB2 for ; Tue, 4 Nov 2014 17:06:40 -0800 (PST) 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 Gm4lV6RFji8U for ; Tue, 4 Nov 2014 17:06:39 -0800 (PST) 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 0CF381A1AB1 for ; Tue, 4 Nov 2014 17:06:38 -0800 (PST) Received: by mail-pd0-f182.google.com with SMTP id fp1so14801326pdb.13 for ; Tue, 04 Nov 2014 17:06:38 -0800 (PST) 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=7ehifcurlgPT8YSAnxKREH+JdXNLyPdh2WPHD8wXghg=; b=QIIHPaVVZznCLN0aJpos6jvwR8dPyyojVMDXSKKu4J8wGtgQtexRzP7NsfoL0sb8ob hSzVy0glyQEuiItb6H0HpnD4Mcxfh7Dz44m9SrSE6cMM7Lb4iE1YEY3QLkWONws+BDuz TnyXYjbsCqNaQ20yqV8fe2mbnWyhXZPykqNzJaM6WQN0Aj5PRq7a34MTpFUh/j3T5YAo 2ypye46HAPKF8GkZ/CZn905HTbBKEpGk21d7XKMvUXw6U07/uGR0SmBWaMMzE9nHc9OH ZEnLG8LRCqC7eDOyLaOL7U7NlCU5iUtPlaYwQkaHgYJb0McnaQ4yz823uJdpHnJmGbpl GopQ== X-Received: by 10.70.98.141 with SMTP id ei13mr52393691pdb.65.1415149598265; Tue, 04 Nov 2014 17:06:38 -0800 (PST) Received: from [192.168.178.23] (210.199.69.111.dynamic.snap.net.nz. [111.69.199.210]) by mx.google.com with ESMTPSA id qr8sm165230pbc.96.2014.11.04.17.06.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Nov 2014 17:06:37 -0800 (PST) Message-ID: <5459781E.2030001@gmail.com> Date: Wed, 05 Nov 2014 14:06:38 +1300 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/wszJHA9iWkJy68q8a-Qgq_GAwoU Subject: [Anima] Anima wiki has moved 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, 05 Nov 2014 01:06:41 -0000 The anima wiki is now at https://tools.ietf.org/wg/anima/trac/wiki/WikiStart The old material has been copied across as a historical section. Regards Brian From nobody Thu Nov 6 01:57: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 454BB1A1A86 for ; Thu, 6 Nov 2014 01:57:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 No_EXkmYpG9O for ; Thu, 6 Nov 2014 01:57:09 -0800 (PST) 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 B3D9C1A1AB5 for ; Thu, 6 Nov 2014 01:57:08 -0800 (PST) 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 BOL74469; Thu, 06 Nov 2014 09:57:06 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 6 Nov 2014 09:56:52 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.22]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Thu, 6 Nov 2014 17:56:46 +0800 From: Sheng Jiang To: "anima@ietf.org" Thread-Topic: Agenda updated Thread-Index: Ac/5p94AoffTexo8Snmk9rfArbBEng== Date: Thu, 6 Nov 2014 09:56:45 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AF70DC3@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.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/eqIFADWcncJM7NdjjZNNXmbQz64 Subject: [Anima] Agenda updated 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, 06 Nov 2014 09:57:10 -0000 SGksIGFsbCwNCg0KV2UgaGF2ZSB1cGRhdGVkIHRoZSBBTklNQSBhZ2VuZGEsIG1haW5seSBhZGRl ZCB0aGUgc3BlYWtlcnMgYW5kIG1lZXRpbmcgaW5mb3JtYXRpb24uIA0KDQpodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL21lZXRpbmcvOTEvYWdlbmRhL2FuaW1hLw0KDQpCZXN0IHJlZ2FyZHMs DQoNClNoZW5nICsgVG9lcmxlc3MNCg== From nobody Thu Nov 6 17:37:23 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 B96321A8AAD for ; Thu, 6 Nov 2014 17:37:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 d7ShsRZ7C2Gi for ; Thu, 6 Nov 2014 17:37:20 -0800 (PST) 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 297FD1A6F38 for ; Thu, 6 Nov 2014 17:37:20 -0800 (PST) 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 BLI97078; Fri, 07 Nov 2014 01:37:18 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 7 Nov 2014 01:37:16 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.22]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Fri, 7 Nov 2014 09:37:12 +0800 From: Sheng Jiang To: Brian E Carpenter , Michael Behringer Thread-Topic: Pre-meeting on Sunday night Thread-Index: Ac/6K1tLmqlKopHhRX+Pacebve2dQQ== Date: Fri, 7 Nov 2014 01:37:11 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AF711AE@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.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/iOWNKr_T563jqTs_WwsEIZqYZkQ Cc: "anima@ietf.org" Subject: [Anima] Pre-meeting on Sunday night 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, 07 Nov 2014 01:37:21 -0000 SGksIEJyaWFuIGFuZCBNaWNoYWVsLA0KDQpUaGFua3MgZm9yIGFncmVlaW5nIHRvIG1lZXQgdXMg Zm9yIHByZS1tZWV0aW5nIHByZXBhcmF0aW9uLiBMZXQncyBtZWV0IGFmdGVyIHRoZSBJRVRGIHJl Y2VwdGlvbiBvbiBTdW5kYXkuIDdwbSBhcm91bmQgdGhlIHJlZ2lzdHJhdGlvbiBkZXNrLg0KDQpJ biBhbnkgY2FzZSB5b3UgY2Fubm90IG1ha2UgaXQsIHBsZWFzZSBsZXQgdXMga25vdy4NCg0KQmVz dCByZWdhcmRzLA0KDQpTaGVuZyArIFRvZXJsZXNzDQo= From nobody Thu Nov 6 18:16:21 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 ADEFB1ACE91 for ; Thu, 6 Nov 2014 18:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 6P_0M4zOkC0C for ; Thu, 6 Nov 2014 18:16:19 -0800 (PST) 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 417681ACE7C for ; Thu, 6 Nov 2014 18:16:18 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLI99106; Fri, 07 Nov 2014 02:16:16 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 7 Nov 2014 02:16:15 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.22]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Fri, 7 Nov 2014 10:16:11 +0800 From: Sheng Jiang To: "anima@ietf.org" Thread-Topic: Volunteer needed for minutes taker and jabber scriber Thread-Index: Ac/6MM1uT/0Dvf+rSYarjtzhAipx6Q== Date: Fri, 7 Nov 2014 02:16:09 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AF711F0@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.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/Xr-ZSrk2HqGT5Qd1epHXA-sILoA Cc: "anima-chairs@tools.ietf.org" Subject: [Anima] Volunteer needed for minutes taker and jabber scriber 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, 07 Nov 2014 02:16:19 -0000 SGksIGFsbCwNCg0KVGhlIGZpcnN0IEFOSU1BIFdHIG1lZXRpbmcgd2lsbCBiZSBob2xkIG9uIHRo ZSBNb25kYXkgKE9jdC4gMTB0aCkgb2YgdGhlIElFVEYgd2VlaywgMTUyMCB0byAxODMwLiBXZSBu ZWVkIHZvbHVudGVlciBmb3IgbWludXRlcyB0YWtlciBhbmQgamFiYmVyIHNjcmliZXIuIElmIHlv dSBhcmUgd2lsbGluZyB0byBoZWxwLCBwbGVhc2UgbGV0IHRoZSBjaGFpcnMga25vdy4NCg0KTWFu eSB0aGFua3MgaW4gYWR2YW5jZS4NCg0KQmVzdCByZWdhcmRzLA0KDQpTaGVuZyArIFRvZXJsZXNz DQo= From nobody Thu Nov 6 19:32:10 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 CA9D11A013B for ; Thu, 6 Nov 2014 19:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 A854p0s_ksmi for ; Thu, 6 Nov 2014 19:32:08 -0800 (PST) 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 449931A0125 for ; Thu, 6 Nov 2014 19:32:08 -0800 (PST) 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 BLJ03818; Fri, 07 Nov 2014 03:32:06 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 7 Nov 2014 03:32:06 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.22]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Fri, 7 Nov 2014 11:32:02 +0800 From: Sheng Jiang To: "anima@ietf.org" Thread-Topic: Volunteer needed for minutes taker and jabber scriber Thread-Index: Ac/6MM1uT/0Dvf+rSYarjtzhAipx6QACmdMQ Date: Fri, 7 Nov 2014 03:32:01 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AF712A9@nkgeml512-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AF711F0@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AF711F0@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.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/dGhyOlopJ49OrYe8hGaeYA-1oHc Subject: Re: [Anima] Volunteer needed for minutes taker and jabber scriber 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, 07 Nov 2014 03:32:10 -0000 T29wcy4uLiBPdXIgbWVldGluZyB3aWxsIGJlIE5vdi4gMTB0aC4gTXkgYmFkLg0KDQpTaGVuZw0K DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBBbmltYSBbbWFpbHRvOmFuaW1h LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTaGVuZyBKaWFuZw0KPlNlbnQ6IEZyaWRh eSwgTm92ZW1iZXIgMDcsIDIwMTQgMTA6MTYgQU0NCj5UbzogYW5pbWFAaWV0Zi5vcmcNCj5DYzog YW5pbWEtY2hhaXJzQHRvb2xzLmlldGYub3JnDQo+U3ViamVjdDogW0FuaW1hXSBWb2x1bnRlZXIg bmVlZGVkIGZvciBtaW51dGVzIHRha2VyIGFuZCBqYWJiZXIgc2NyaWJlcg0KPg0KPkhpLCBhbGws DQo+DQo+VGhlIGZpcnN0IEFOSU1BIFdHIG1lZXRpbmcgd2lsbCBiZSBob2xkIG9uIHRoZSBNb25k YXkgKE9jdC4gMTB0aCkgb2YgdGhlDQo+SUVURiB3ZWVrLCAxNTIwIHRvIDE4MzAuIFdlIG5lZWQg dm9sdW50ZWVyIGZvciBtaW51dGVzIHRha2VyIGFuZCBqYWJiZXINCj5zY3JpYmVyLiBJZiB5b3Ug YXJlIHdpbGxpbmcgdG8gaGVscCwgcGxlYXNlIGxldCB0aGUgY2hhaXJzIGtub3cuDQo+DQo+TWFu eSB0aGFua3MgaW4gYWR2YW5jZS4NCj4NCj5CZXN0IHJlZ2FyZHMsDQo+DQo+U2hlbmcgKyBUb2Vy bGVzcw0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ QW5pbWEgbWFpbGluZyBsaXN0DQo+QW5pbWFAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hDQo= From nobody Sat Nov 8 00:23: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 EEE9C1A1B86 for ; Sat, 8 Nov 2014 00:23:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.581 X-Spam-Level: X-Spam-Status: No, score=-13.581 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.594, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514, 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 W2ooEo8yc7bG for ; Sat, 8 Nov 2014 00:23:29 -0800 (PST) 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 52C411A1B83 for ; Sat, 8 Nov 2014 00:23:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1903; q=dns/txt; s=iport; t=1415435010; x=1416644610; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=pGCmJHi+UGm5ig/fjpahzJVfi0w1ANcpYBTHQw4SsWg=; b=EwbLHbPYgpCCv4GgYOXMVgKyQDjSM2omi/J3BCLIpiSkMmomeGjFzNuI H93hHPtUck4i5SKBYaC3659Wx889IYwWuFfZs7ke6WDjd8bYESJzIiY1f eandp/zu03mvbma7kZJnbZHDOcvbjjFjktYqqoCKvchNDKbDzchv8a4ls 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAEfSXVStJV2S/2dsb2JhbABbgw5UWQTLUwqHTwKBGRYBAQEBAX2EAgEBAQQBAQE3NAYRBAIBCBEEAQELFAkHJwsUCQgBAQQBEgiIOQ3OOwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEkGA4BoMngR4BBJInhFSde4N5bIFIgQMBAQE X-IronPort-AV: E=Sophos;i="5.07,338,1413244800"; d="scan'208";a="370797526" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-2.cisco.com with ESMTP; 08 Nov 2014 08:23:29 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sA88NSnM006987 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 8 Nov 2014 08:23:28 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.140]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Sat, 8 Nov 2014 02:23:28 -0600 From: "Michael Behringer (mbehring)" To: Sheng Jiang , "anima@ietf.org" Thread-Topic: Agenda for ANIMA WG meeting in IETF 91 Thread-Index: Ac/4QGwoTZaYey0lTui05s3dHi2D8QC47zjQ Date: Sat, 8 Nov 2014 08:23:27 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF21CAFEB9@xmb-rcd-x14.cisco.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AF6E5FA@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AF6E5FA@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.61.209.34] 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/7f29M5zBRNH72w8AnAHkgDeAaHE Subject: Re: [Anima] Agenda for ANIMA WG meeting in IETF 91 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, 08 Nov 2014 08:23:31 -0000 Sheng,=20 Quick feedback: I suggest to present draft-behringer-anima-reference-model = first, since it really sets the stage for the other documents.=20 Michael > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Sheng Jiang > Sent: 04 November 2014 16:03 > To: anima@ietf.org > Subject: [Anima] Agenda for ANIMA WG meeting in IETF 91 >=20 > Hi, all, >=20 > we have uploaded the agenda for ANIMA WG meeting in IETF 91. Speaker > information will be added after confirmation. >=20 > https://datatracker.ietf.org/meeting/91/agenda/anima/ >=20 > 1. Agenda bashing (5 min) > 2. Area Director introduction (Benoit, 10 min) 3. NMRG Documents status (= 5 > min) 4. Autonomic functions/requirements in homenet + > Questions/Answers (30 min) > (speaker to be confirmed) > 5. WG chartered work items (120 min, 18 min each for 6 drafts, 8 min for > presentation + 10 min for discussion, 10 min for zerotouch) > A Generic Discovery and Negotiation Protocol for Autonomic Networking > (draft-carpenter-anima-gdn-protocol) > An Autonomic Control Plane > (draft-behringer-anima-autonomic-control-plane) > Bootstrapping Key Infrastructures > (draft-pritikin-anima-bootstrapping-keyinfra) > Zero Touch Provisioning for NETCONF Call Home (to be confirmed, 10 min= ) > (draft-ietf-netconf-zerotouch) > A Reference Model for Autonomic Networking > (draft-behringer-anima-reference-model) > Autonomic Network Stable Connectivity > (draft-eckert-anima-stable-connectivity) > Autonomic Prefix Management in Large-scale Networks > (draft-jiang-anima-prefix-management) > 6. Closing (10 min) >=20 > Best regards, >=20 > Sheng + Toerless > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Sat Nov 8 01:06: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 EAC501A1BE4 for ; Sat, 8 Nov 2014 01:06:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 l3aGnYfZd-93 for ; Sat, 8 Nov 2014 01:06:43 -0800 (PST) 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 CF9751A1BDD for ; Sat, 8 Nov 2014 01:06:40 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLK12628; Sat, 08 Nov 2014 09:06:38 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 8 Nov 2014 09:06:36 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.22]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Sat, 8 Nov 2014 17:06:33 +0800 From: Sheng Jiang To: "Michael Behringer (mbehring)" , "anima@ietf.org" Thread-Topic: Agenda for ANIMA WG meeting in IETF 91 Thread-Index: Ac/4QGwoTZaYey0lTui05s3dHi2D8QC47zjQAAOgrTE= Date: Sat, 8 Nov 2014 09:06:33 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AF7284F@nkgeml512-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AF6E5FA@nkgeml512-mbx.china.huawei.com>, <3AA7118E69D7CD4BA3ECD5716BAF28DF21CAFEB9@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF21CAFEB9@xmb-rcd-x14.cisco.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.24.167] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/anima/B60XS221b6D6LWkZhlR74hhJjH8 Subject: Re: [Anima] Agenda for ANIMA WG meeting in IETF 91 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, 08 Nov 2014 09:06:53 -0000 Hi, Michael, My plan is to make your presentation of draft-behringer-anima-reference-mod= el as a summary for these reusable components rather than an introduction f= or them. I think it would be better to start from small then bigger picture= . This would help people to understand the reference model better. Cheers, Sheng ________________________________________ From: Michael Behringer (mbehring) [mbehring@cisco.com] Sent: 08 November 2014 16:23 To: Sheng Jiang; anima@ietf.org Subject: RE: Agenda for ANIMA WG meeting in IETF 91 Sheng, Quick feedback: I suggest to present draft-behringer-anima-reference-model = first, since it really sets the stage for the other documents. Michael > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Sheng Jiang > Sent: 04 November 2014 16:03 > To: anima@ietf.org > Subject: [Anima] Agenda for ANIMA WG meeting in IETF 91 > > Hi, all, > > we have uploaded the agenda for ANIMA WG meeting in IETF 91. Speaker > information will be added after confirmation. > > https://datatracker.ietf.org/meeting/91/agenda/anima/ > > 1. Agenda bashing (5 min) > 2. Area Director introduction (Benoit, 10 min) 3. NMRG Documents status (= 5 > min) 4. Autonomic functions/requirements in homenet + > Questions/Answers (30 min) > (speaker to be confirmed) > 5. WG chartered work items (120 min, 18 min each for 6 drafts, 8 min for > presentation + 10 min for discussion, 10 min for zerotouch) > A Generic Discovery and Negotiation Protocol for Autonomic Networking > (draft-carpenter-anima-gdn-protocol) > An Autonomic Control Plane > (draft-behringer-anima-autonomic-control-plane) > Bootstrapping Key Infrastructures > (draft-pritikin-anima-bootstrapping-keyinfra) > Zero Touch Provisioning for NETCONF Call Home (to be confirmed, 10 min= ) > (draft-ietf-netconf-zerotouch) > A Reference Model for Autonomic Networking > (draft-behringer-anima-reference-model) > Autonomic Network Stable Connectivity > (draft-eckert-anima-stable-connectivity) > Autonomic Prefix Management in Large-scale Networks > (draft-jiang-anima-prefix-management) > 6. Closing (10 min) > > Best regards, > > Sheng + Toerless > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima= From nobody Sat Nov 8 01:28: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 859641A6EDC for ; Sat, 8 Nov 2014 01:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 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.594, 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 OTxLrabF_QfM for ; Sat, 8 Nov 2014 01:28:47 -0800 (PST) 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 973871A212A for ; Sat, 8 Nov 2014 01:28:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2953; q=dns/txt; s=iport; t=1415438928; x=1416648528; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=psTeDQql7M4U5VCt5cynmoAQZRYh0Fv9GUb/J0L3gbc=; b=NBXQ1KSlvlG5T9XBjuVWOJ5Fi8BuZtlcV5cuUphP69S1Pi2JM48/foVx sbSlgtKR5WoXiBw/sIVHI9UpYd1Xeb0E12VTCdJBTHifCDFI0a52N6EQN y5miLq5hh7BWKDjLXY/NSHxWfY5zE7P3H3SpYqyl0qwzj+nqXjPE2g4K6 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFADrhXVStJV2c/2dsb2JhbABbgw5UWQTLUwqHTwKBGRYBAQEBAX2EAgEBAQQBAQEkEzQGEQQCAQgRBAEBCxQJBycLFAkIAQEEARIIiDkNzkMBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIp1hWs4BoMngR4BBJInhFSIUZEhhAmDeWyBSIEDAQEB X-IronPort-AV: E=Sophos;i="5.07,339,1413244800"; d="scan'208";a="367376961" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 08 Nov 2014 09:28:47 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id sA89Skvp003381 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 8 Nov 2014 09:28:46 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.140]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Sat, 8 Nov 2014 03:28:46 -0600 From: "Michael Behringer (mbehring)" To: Sheng Jiang , "anima@ietf.org" Thread-Topic: Agenda for ANIMA WG meeting in IETF 91 Thread-Index: Ac/4QGwoTZaYey0lTui05s3dHi2D8QC47zjQAAOgrTEAAOSUsA== Date: Sat, 8 Nov 2014 09:28:46 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF21CAFFE5@xmb-rcd-x14.cisco.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AF6E5FA@nkgeml512-mbx.china.huawei.com>, <3AA7118E69D7CD4BA3ECD5716BAF28DF21CAFEB9@xmb-rcd-x14.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AF7284F@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AF7284F@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.61.209.34] 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/ynEZqjLGGUUTD5lgfrtw11RkAgs Subject: Re: [Anima] Agenda for ANIMA WG meeting in IETF 91 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, 08 Nov 2014 09:28:49 -0000 OK, I'm a top-down person, so I usually work overview --> details, but you'= re the chair, no problem with that either :-)=20 Michael > -----Original Message----- > From: Sheng Jiang [mailto:jiangsheng@huawei.com] > Sent: 08 November 2014 10:07 > To: Michael Behringer (mbehring); anima@ietf.org > Subject: RE: Agenda for ANIMA WG meeting in IETF 91 >=20 > Hi, Michael, >=20 > My plan is to make your presentation of draft-behringer-anima-reference- > model as a summary for these reusable components rather than an > introduction for them. I think it would be better to start from small the= n > bigger picture. This would help people to understand the reference model > better. >=20 > Cheers, >=20 > Sheng > ________________________________________ > From: Michael Behringer (mbehring) [mbehring@cisco.com] > Sent: 08 November 2014 16:23 > To: Sheng Jiang; anima@ietf.org > Subject: RE: Agenda for ANIMA WG meeting in IETF 91 >=20 > Sheng, >=20 > Quick feedback: I suggest to present draft-behringer-anima-reference- > model first, since it really sets the stage for the other documents. >=20 > Michael >=20 > > -----Original Message----- > > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Sheng Jiang > > Sent: 04 November 2014 16:03 > > To: anima@ietf.org > > Subject: [Anima] Agenda for ANIMA WG meeting in IETF 91 > > > > Hi, all, > > > > we have uploaded the agenda for ANIMA WG meeting in IETF 91. Speaker > > information will be added after confirmation. > > > > https://datatracker.ietf.org/meeting/91/agenda/anima/ > > > > 1. Agenda bashing (5 min) > > 2. Area Director introduction (Benoit, 10 min) 3. NMRG Documents > > status (5 > > min) 4. Autonomic functions/requirements in homenet + > > Questions/Answers (30 min) > > (speaker to be confirmed) > > 5. WG chartered work items (120 min, 18 min each for 6 drafts, 8 min > > for presentation + 10 min for discussion, 10 min for zerotouch) > > A Generic Discovery and Negotiation Protocol for Autonomic Networkin= g > > (draft-carpenter-anima-gdn-protocol) > > An Autonomic Control Plane > > (draft-behringer-anima-autonomic-control-plane) > > Bootstrapping Key Infrastructures > > (draft-pritikin-anima-bootstrapping-keyinfra) > > Zero Touch Provisioning for NETCONF Call Home (to be confirmed, 10 > min) > > (draft-ietf-netconf-zerotouch) > > A Reference Model for Autonomic Networking > > (draft-behringer-anima-reference-model) > > Autonomic Network Stable Connectivity > > (draft-eckert-anima-stable-connectivity) > > Autonomic Prefix Management in Large-scale Networks > > (draft-jiang-anima-prefix-management) > > 6. Closing (10 min) > > > > Best regards, > > > > Sheng + Toerless > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima From nobody Sun Nov 9 11:23:07 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 C1FA31A3B9E for ; Sun, 9 Nov 2014 11:23:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 gn2E_-GuJRY7 for ; Sun, 9 Nov 2014 11:23:04 -0800 (PST) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B729E1A6F45 for ; Sun, 9 Nov 2014 11:23:03 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id b13so7257677wgh.40 for ; Sun, 09 Nov 2014 11:23:02 -0800 (PST) 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=Z3HdNp2LiEv9XJq3MhgLfL3xbq8e9bjXz/P2O+DgMA8=; b=TM2zqxzdFMM8lcwZc7xrYrRjA92IzX5g5qeIRdfIdVY6LLo6GSO/7l9SwGLmFDDAtL XvKthLCokjfCWBe7MdDZ1rE+SxhJ4Pa4RDpEN8ME5HhFnKMXSA/4Gz6nUuGLLR/6uCj/ CVbRCi1LLZDh8+NMf8d3DwqkPdclR2rAIdvnrbcfSFTFFJG3aE4QqDaNGvAgTCLmAJ4+ YsctPDt7BoL1GGHupqgeUXjkHTql0QJ0nAGIqBezD25/t9ovrzXUoGpySmCGGZyOPnfv ApbuB4G7sEukCJURLw2Rp/Pr+bM6rADUwHy+hZvrp6qqb9nEbc/4TUMl92jGApdfYFQa DHaQ== X-Received: by 10.180.19.164 with SMTP id g4mr24040321wie.51.1415560982521; Sun, 09 Nov 2014 11:23:02 -0800 (PST) Received: from [31.133.138.232] (dhcp-8ae8.meeting.ietf.org. [31.133.138.232]) by mx.google.com with ESMTPSA id da3sm20278648wjb.12.2014.11.09.11.23.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 09 Nov 2014 11:23:02 -0800 (PST) Message-ID: <545FBF0F.8040201@gmail.com> Date: Mon, 10 Nov 2014 08:22:55 +1300 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/WFJZqluMZi-4CpJCVfCapJxbP_4 Subject: [Anima] draft-pritikin-anima-bootstrapping-keyinfra-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: Sun, 09 Nov 2014 19:23:05 -0000 Hi, I have a few comments on this draft after a fairly quick reading. Firstly a general point. I suggest deleting every occurrence of the word "cloud" in the document. I couldn't find any place where it actually means anything. > MASA Cloud Service: A Manufacturer Authorized Signing Authority > (MASA) cloud service on the global Internet. At a minimum the > MASA provides a trusted repository for audit information > concerning privacy protected bootstrapping events. As a service > offering the MASA can encorporate many of the bootstrapping > elements (such as the Registrar and the Domain CA) into the cloud > service. 1) The MASA abbreviation is used several times before it's defined. 2) How can a given vendor's MASA service incorporate the Registrar and Domain CA functions for a multi-vendor customer? We are not here to make customer capture easier for vendors. 3) Having those functions *outside* the target domain seems like a serious security exposure in itself. I think we should strongly recommend that the Registrar and Domain CA are physically within the target domain (for the "professionally managed" networks in anima scope). > 3.3. Accepting New Entities > > For each New Entity the Registrar is informed a priori the unique > identifier (e.g. serial number). That should probably be (e.g. manufacturer's OUI + serial number). > This can be supplied automatically > from the Orchestrator [[EDNOTE: TBD]] or inputed manually by the > administrator. I think there's a third option: acquired automatically when the new entity is first connected inside the target domain's physically secure area (e.g. its central warehouse), before shipping to its final destination (e.g. a remote PoP). ... > ...(Registrars > can be shipped with the keyIdentifier of a significant number of > third-party manufacturers). That seems dangerous, in the same way that shipping browser code with built-in CA certificates is an attack vector. I can see why you might have to do this for consumer networks, but it doesn't seem advisable for carriers or large enterprises. > 4.1. Behavior of a new entity > > A New Entity that has not yet been bootstrapped attempts to find a > local domain and join it. A number of methods are attempted for > establishing communications with the domain in a specified order. > > Client behavior is as follows: > > 1. Discover a communication channel to the "closest" Registrar by > trying the following steps in this order: > > A. Search for a Proxy on the local link using Neighbor > Discovery. If multiple local proxies are discovered attempt > communications with each before widening the search to other > options. If this fails: > > B. Obtain an IP address using DHCP, and search for a local > registrar using DNS service discovery. If this fails: > > C. Obtain an IP address using DHCP, and search for a pre-defined > Factory provided global registrar using DNS. I believe that the discovery and search would be appropriately done using whatever anima adopts for generic autonomic discovery (running temporarily without full security, for obvious reasons, but we have that issue in any case during bootstrapping). > 4.5.1. Network boundaries This is an important topic but I'm not sure it belongs in the present draft. It may need a new draft that we haven't yet planned. Brian -- Regards Brian Carpenter http://orcid.org/0000-0001-7924-6182 From nobody Tue Nov 11 16:34: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 3B24B1A90FE for ; Tue, 11 Nov 2014 16:34:36 -0800 (PST) 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 t9L-U_jhFwqE for ; Tue, 11 Nov 2014 16:34:34 -0800 (PST) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F84F1A9006 for ; Tue, 11 Nov 2014 16:34:34 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id f15so9320196lbj.23 for ; Tue, 11 Nov 2014 16:34:32 -0800 (PST) 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=7B1k70nygiVd/JOMhHXFhTgqaToLmhLhFIP3VkK/r4g=; b=z8O4s828QFsLF2IypTJzcjR/YhEPaLgFqUZ+qLs/v/ZUI7lHwMY7EmSVXH9jTBOhfF I4S2nA1Slx3ebgYh+LSkwhxhKcebn2Lm1q64W5p/ThLzvPfwIy3cvvLgvJU4Am8ltsPM JoIuM+0Z2Myln98NCMoWRkerrtOgVBidZvTa5f7kDGkl3Oc0j2CswXL/J+sexUB5kEeu br8zrzrRQFMFLkooPMuDso3+vDQZKyIigCN0TKUSWACWue4Q9CsxDt15fApsttSIvKEI SgWtayl2grZGpUrBf/wBP4YxNkGs03NEAHFyX8fX7xKmJ8CbgrtTN9GlIwpEc+3t0q9G Hwgg== MIME-Version: 1.0 X-Received: by 10.152.22.74 with SMTP id b10mr38990022laf.16.1415752472651; Tue, 11 Nov 2014 16:34:32 -0800 (PST) Sender: jeferson.nobre@gmail.com Received: by 10.112.18.136 with HTTP; Tue, 11 Nov 2014 16:34:32 -0800 (PST) In-Reply-To: <20141111191306.17583.28459.idtracker@ietfa.amsl.com> References: <20141111191306.17583.28459.idtracker@ietfa.amsl.com> Date: Tue, 11 Nov 2014 14:34:32 -1000 X-Google-Sender-Auth: mY_DtPQqkmtOIG2zFWUfeyzuNdg 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/WyXaQldCC1ELpTeu0M1I8_zXuR4 Subject: [Anima] Fwd: New Version Notification for draft-irtf-nmrg-autonomic-sla-violation-detection-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 00:34:36 -0000 ---------- Forwarded message ---------- From: Date: Tue, Nov 11, 2014 at 9:13 AM Subject: New Version Notification for draft-irtf-nmrg-autonomic-sla-violation-detection-01.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-01.txt has been successfully submitted by Jeferson Campos Nobre and posted to the IETF repository. Name: draft-irtf-nmrg-autonomic-sla-violation-detection Revision: 01 Title: Autonomic Networking Use Case for Distributed Detection of SLA Violations Document date: 2014-11-10 Group: nmrg Pages: 9 URL: http://www.ietf.org/internet-drafts/draft-irtf-nmrg-autonomic-sla-violation-detection-01.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-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-irtf-nmrg-autonomic-sla-violation-detection-01 Abstract: This document describes a use case for autonomic networking in distributed detection of Service Level Agreement (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 Fri Nov 14 17:48: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 D0D2E1A00AD; Fri, 14 Nov 2014 17:48:33 -0800 (PST) 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, HTML_MESSAGE=0.001, 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 SjvH31tS9Nwg; Fri, 14 Nov 2014 17:48:32 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0792.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:792]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 041C01A00A9; Fri, 14 Nov 2014 17:48:31 -0800 (PST) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.16.15; Sat, 15 Nov 2014 01:48:09 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.239]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.239]) with mapi id 15.01.0016.006; Sat, 15 Nov 2014 01:48:09 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: zero touch update Thread-Index: AQHQAHY0WDogy9sUUUCVbVxAwvNC9Q== Date: Sat, 15 Nov 2014 01:48:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [66.129.239.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; x-forefront-prvs: 03965EFC76 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(199003)(189002)(20776003)(83506001)(101416001)(36756003)(120916001)(2501002)(97736003)(86362001)(92726001)(2656002)(4396001)(50986999)(99396003)(99286002)(95666004)(110136001)(66066001)(106116001)(106356001)(40100003)(122556002)(21056001)(2351001)(46102003)(77156002)(105586002)(16236675004)(64706001)(107046002)(229853001)(54356999)(62966003)(77096003)(87936001)(133083001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_D08BD4A58908Akwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/anima/Cq_gKf5Kgg5SOHj1MwVR1uXukJA Cc: Russ Mundy , Wes Hardaker , Sean Turner , "anima@ietf.org" Subject: [Anima] zero touch update 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, 15 Nov 2014 01:48:34 -0000 --_000_D08BD4A58908Akwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The ZeroTouch draft received a lot of valuable comments this week (thank yo= u everyone). One concern raised regards the feasibility for Vendors knowin= g which devices are owned by whom, especially in light of downstream channe= ls and resellers. The anima-bootstrapping-keyinfra resolves this by replac= ing proof of ownership with an audit log assertion, for post-incident foren= sics analysis. This approach is easy to implement, but the security assura= nce it provides is fairly low (e.g., the damage could be done before the lo= gs are reviewed). Leveraging L2 before L3 is fine, as is leveraging L1 before L2, so long as = the higher layers have equal or greater security assurances (no security do= wngrade attack). That said, our use-case of needing to support gateway de= vices connecting to 3rd-party networks precludes the use of L2, as there is= no other local device to connect to. One idea is say that the proof-of-ownership is only required for gateway de= vices connecting to remotely administered networks, so as to lower the burd= en on Vendors mentioned above with there being far fewer of these kinds of = devices. Whittling the numbers down further, we could add optional support= for NFC, so that proof-of-ownership is also not required for devices havin= g the right hardware. All this to say that the authors believe that this needs to be discussed mo= re and thus we will not likely be pushing for a WGLC in December after all. Thanks, Kent --_000_D08BD4A58908Akwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <62152BCE061A1947957BD87758C1AF83@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

The ZeroTouch draft received a lot of valuable comments this week (tha= nk you everyone).  One concern raised regards the feasibility for Vend= ors knowing which devices are owned by whom, especially in light of downstr= eam channels and resellers.  The anima-bootstrapping-keyinfra resolves this by replacing proof of ownership with an audit log assertion,= for post-incident forensics analysis.  This approach is easy to imple= ment, but the security assurance it provides is fairly low (e.g., the damag= e could be done before the logs are reviewed).

Leveraging L2 before L3 is fine, as is leveraging L1 before L2, so lon= g as the higher layers have equal or greater security assurances (no securi= ty downgrade attack).   That said, our use-case of needing to support = gateway devices connecting to 3rd-party networks precludes the use of L2, as there is no other local device to con= nect to.

One idea is say that the proof-of-ownership is only required for gatew= ay devices connecting to remotely administered networks, so as to lower the= burden on Vendors mentioned above with there being far fewer of these kind= s of devices.  Whittling the numbers down further, we could add optional support for NFC, so that proof-of-owne= rship is also not required for devices having the right hardware.

All this to say that the authors believe that this needs to be discuss= ed more and thus we will not likely be pushing for a WGLC in December after= all.

Thanks,
Kent



--_000_D08BD4A58908Akwatsenjunipernet_-- From nobody Sat Nov 15 22:34: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 423851A89A5; Sat, 15 Nov 2014 22:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.305 X-Spam-Level: **** X-Spam-Status: No, score=4.305 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_19=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_28=0.6, RP_MATCHES_RCVD=-0.594, 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 tM9_rGoOWyig; Sat, 15 Nov 2014 22:34:13 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC3EC1A898A; Sat, 15 Nov 2014 22:34:12 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4732920012; Sun, 16 Nov 2014 01:36:31 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 71388637F5; Sun, 16 Nov 2014 01:34:11 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 55D0C637EA; Sun, 16 Nov 2014 01:34:11 -0500 (EST) From: Michael Richardson To: Kent Watsen In-Reply-To: References: 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/xikl_ieWOtcUF4GtM3ezumgrres Cc: Russ Mundy , Wes Hardaker , Sean Turner , "netconf@ietf.org" , "anima@ietf.org" Subject: Re: [Anima] zero touch update X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Nov 2014 06:34:15 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Kent,=20 in the days up to Toronto, before it was clear the amount of convergence that we might get, I wrote the following email. This is intended to be a more detailed expansion of the certificates= =20 used in draft-pritikin-anima-bootstrapping-keyinfra-00. =20=20=20=20=20=20 It could be that the MASA provides the certificates online,=20 at deployment time, but the goal was to provide a system which could be used entirely offline, and then let parts of it go online as desired. Easier to go this way than the other way. draft-richardson-6tisch-idevid-cert-00 describes a RFC3779-like extension. the email is: https://mailarchive.ietf.org/arch/msg/6tisch-security/2kObJLkLlhuI-HU9s5y= qfRm0n00 this is what I imagine. I will perhaps put this into an appendix. Please remmeber that this comes from 6tisch, which anticipates deployment into industrial settings (Oil refineries, chemical plants, etc.), and while I've made up some semi-consumer oriented things here, we imagine something involving industrial consortia. I don't pretend that this is at all useful for other scenarioes due to lack of a high-enough margin for the supply cha= in to care about such things.=20 (I guess the Coyote Plant should have been in New Mexico) =3D=3D=3D=3D To make it easier to explain, and talk about, I'm going to give some names. Factory: ACME National-VAR: Cadabra Regional-Var: Sesame Plant: Coyote So, the manager (Wiley) at the Coyote Plant, has just received 1000 new (wireless) Road-Runner Detector, and plans to spread them along the highway. The detectors are IDevID 210001 through 210999. Each Detector has an 802.1AR certificate pre-installed that looks like: Issuer: C=3DUS, ST=3DNew Jersey, L=3DFairfield, O=3DACME Rocket-Powered Products, OU=3DSensor-Network-Division Validity Not Before: Feb 17 19:51:50 2010 GMT Not After : Dec 31 23:59:59 9999 GMT Subject: CN=3Droadrunner210001 Data: Serial Number: 21:00:01 Subject Public Key Info: ... {this is the proof of identity certificate} When ACME Factory's Sensor Netowrk Division ships 100 crates of sensors to Cadabra, it issues a certificate: Issuer: C=3DUS, ST=3DNew Jersey, L=3DFairfield, O=3DACME Rocket-Powered Products, OU=3DSensor-Network-Division Validity Not Before: Feb 17 19:51:50 2010 GMT Not After : Dec 31 23:59:59 9999 GMT Subject: C=3DUS,ST=3DWashington,L=3DSeattle,O=3DCadabra,OU=3DLogist= ics RFC3779-Like-Extension: Range(210000, 219999) When Cadabra ships cases 1-20 to Sesame, it issues a certificate: Issuer: C=3DUS,ST=3DWashington,L=3DSeattle,O=3DCadabra,OU=3DLogisti= cs Validity Not Before: Feb 17 19:51:50 2010 GMT Not After : Dec 31 23:59:59 9999 GMT Subject: C=3DUS, ST=3DArkansus, L=3DBentonville, O=3DSesame Bix Box Retail, OU=3DSmall Stuff Distribution RFC3779-Like-Extension: Range(210000, 211999) When Coyote Inc buys those 10 boxes of 100 sensors, the bill of sale includes: Issuer: C=3DUS, ST=3DArkansus, L=3DBentonville, O=3DSesame Bix Box Retail, OU=3DSmall Stuff Distribution Validity Not Before: Feb 17 19:51:50 2010 GMT Not After : Dec 31 23:59:59 9999 GMT Subject: C=3DUS, ST=3DNevada, L=3DTonopah, O=3DCoyote Inc, OU=3DSupper RFC3779-Like-Extension: Range(210000, 210099) RFC3779-Like-Extension: Range(210200, 210299) RFC3779-Like-Extension: Range(210400, 210499) RFC3779-Like-Extension: Range(210600, 210699) RFC3779-Like-Extension: Range(210800, 210899) RFC3779-Like-Extension: Range(211000, 211099) RFC3779-Like-Extension: Range(211200, 211299) RFC3779-Like-Extension: Range(211600, 211699) RFC3779-Like-Extension: Range(211800, 211899) (cause, a shipper sent them every other box, the ranges are not contiguous) The mote/sensor when it sees this certificate, can verity that it's DevID is in the range, and therefore knows that it has found the right network. Should Coyote find that they had too many, they can sell some of these sensors to Sheepdog Sam Inc, by issuing a certificate: Issuer: C=3DUS, ST=3DNevada, L=3DTonopah, O=3DCoyote Inc, OU=3DSupper Validity Not Before: Feb 17 19:51:50 2010 GMT Not After : Dec 31 23:59:59 9999 GMT Subject: C=3DGB, ST=3DScotland, L=3DEdinburgh, O=3DSheepsRUs, OU=3DSheepdog RFC3779-Like-Extension: Range(210050, 210099) RFC3779-Like-Extension: Range(211611, 211623) of course, since Coyote actually still has a valid certificate, all parties would be advised to use the Enrollment over Secure Transport or an API into 802.1AR, to put an operational certificate in place. Getting back to factory default might be impossible (WirelessHart does this, I think), or at least, will wipe the private key associated with the new certificate from the device. BTW: the extension is likely about 20 bytes base, with 5 bytes per IDEVID. =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) iQEVAwUBVGhFX4CLcPvd0N1lAQIjpAgAmLsziM4blxyDpMiVwagWiPjokxVp+Aoy iuXodKKUPLFoV3Ak69H+dGP9KtUhezmEIen/a8Sxoj9+li3oWmJ0O4x8a/klInHd c4VTBHJ8Bd4p8k6wJZG2NtDEXaVhubABzih6Lno4wcHw0xECn4SKNI9KkGETihoY D1xbhshwJZgmTAmiaVKkkQNgcIHMM/HnhgAv0JxF+0+bhlg7FpYVuKdjZdOzUqBT Ef4zWoDX0+1vmD1mi5h3tlQ8KuPqP1tUFU55xH+8A51Z6WjuwUPBYZDF58UpFNPE GUyg5Z4cZLJXoljN4wJL6AZ6A5JWxdNdd9/jwvjqqKC1o7+RvYtfkA== =NQ3M -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Nov 15 22:35: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 A09FF1A89A6; Sat, 15 Nov 2014 22:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 Z02fZ_QjCFrx; Sat, 15 Nov 2014 22:35:22 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9E271A89A5; Sat, 15 Nov 2014 22:35:21 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E91C120012; Sun, 16 Nov 2014 01:37:40 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 3D39D637F4; Sun, 16 Nov 2014 01:35:21 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 26102637EA; Sun, 16 Nov 2014 01:35:21 -0500 (EST) From: Michael Richardson To: Kent Watsen In-Reply-To: References: 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/AKjKjlunbc8vhAdjF4l3itNMcl0 Cc: Russ Mundy , Wes Hardaker , Sean Turner , "netconf@ietf.org" , "anima@ietf.org" Subject: Re: [Anima] zero touch update X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Nov 2014 06:35:23 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Kent Watsen wrote: > The ZeroTouch draft received a lot of valuable comments this week > (thank you everyone). One concern raised regards the feasibility for > Vendors knowing which devices are owned by whom, especially in light = of > downstream channels and resellers. The anima-bootstrapping-keyinfra I should have been clear that it was the mention of channels and resellers that made me send the previous email with the RoadRunner/Coyote inspired example. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVGhFpYCLcPvd0N1lAQKcswf/UVjy6k+3NDwGkNRcdYJxMbaF1D3YaqIc 8vFWM1aIkg4U8bL29ssD3u6uuHPjaiLUupsiCx7ZXWWhDgcuvIkiDiZ6N92PxTh/ ZQdpSQTVfcaUk8CGBqlaQXQTJS2BjGllTQbtN1YUg2aWe0vP6tmgXUNrQJQ3mMaV 6q0KyJrUod0Y04zP1aIGYpboHKWSD2gfMDaPKLcU0D/XcwSzyaq0KdnXo6uKqjRN 4drrTsu+8a7JVqGor5HY6pedD2D0SmNDF9ct4f7+xcFifmuz7vWK+R0RuRTUJt5n fHHfrkTn3B10nuPUqsDJi/lNwGR4N7VD5fSOQj7DIBPfZbcqhagNFg== =Cs14 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Nov 23 13:12:35 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 774B71A1AAA for ; Sun, 23 Nov 2014 13:12:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.388 X-Spam-Level: *** X-Spam-Status: No, score=3.388 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_52=0.6, MIME_NO_TEXT=1.999, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOrp-68rbew4 for ; Sun, 23 Nov 2014 13:12:32 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 364111A1AAC for ; Sun, 23 Nov 2014 13:12:32 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DF29020098 for ; Sun, 23 Nov 2014 16:15:16 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 7F552637F5; Sun, 23 Nov 2014 16:12:30 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 69D3163745 for ; Sun, 23 Nov 2014 16:12:30 -0500 (EST) From: Michael Richardson To: anima@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.2; nmh 1.3; 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/nT52wpD7AfnB9ctJ_28znyMqr0I Subject: [Anima] comments on prefix delegation and GDN protocol document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Nov 2014 21:12:33 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable I read these on the airplane. section 3.1 why send a GDN discovery message asking for a Prefix Option, instead of just sending a DHCPv6 Discovery message with PD as a request? Is there a way to get a prefix that isn't DHCPv6PD? I guess section 3.3 leaves this as an open question... I would say, either = do DHCPv6, or don't, but run a protocol to decide if you are going to run a protocol. I'm unclear if the prefix being allocated is for production use, or is for numbering the control channel(s). I will note that if one uses RPL to build a control channel, that RPL also can distribute prefixes in PIOs. wrt: the GDN protocol and requirements: 5.2.1: why does the GDN protocol need to run over IPv4? I would agree that it might need to configure IPv4 services, but I can't see a reason why it should be complicated by the need to support legacy 32-bit stuff.=20=20 I would suspect that the GDN protocol might run in the supervisor processor for a router/switch/server (server: I'm thinking IBM Service Processor, DELL iDrac, as well as in the control plane processor of a router), so I can't see an installed base reason for IPv4/32-bit support 5.2.3: I think the GNDP should run over DTLS or IKEv2/IPsec (pick one), and that the certificates involved should key that channel rather than invent a new one. 5.2.3.1: algorithm agility, you can't say: don't fallback to an algorithm considered weak. If the software author knew the algorithm was weak at the time the code was written, the algorithm would not have been included. That's the whole problem here: you need to be able to incrementally deploy new algorithms, so you need an upgrade mechanism, and you *have to* fallback when the other node does not support stronger algorithm, and the attacker will convince you... The only out is that you can do something in the certificates=20 that says what ought to be supported. As far as I can see the only reason to use assymetric signatures on each message is in order to support multicast. My understanding is that this protocol will primarily occur between adjacent routing equipment. While we pretend via Layer-2 devices that ethernet is still made up of broadcast coax cables, except for wifi, there are probably only two devices connected at each end of the cable. So I suggest that while a multicast based discovery protocol is appropriate (and why not use DHCPv6 or RPL), once the end point is discovered, it seems that one should run GNDP over point to point DLTS or IPsec. =2D-=20 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) iQEVAwUBVHJNu4CLcPvd0N1lAQLlegf/da7QOMMKCecGYt9Fo47gSsnjI8ErpG6r 8c8kGzBUI86miRiIt7l6foW8BcFR89vMViXCAL0tQyA9idZX0MVJZZvVQZSSQXuc 8BMJq7ChIh/mz6/hDcrrNpVHbgi8P2/9GRQ6reyhb5R1PmYhUPKMtdldI18XqNVC A2zrtZKLM8sLTlgdtr+XH1pJKh6YU0Z5NF2pKTbv7Oo5VPdMkUnwcLuZxIHwHM6d hiXr+EaPnXkG71sak+x6mTFjzTQIP0xIta38b1RJQB2A9EW1NnBombweRFIn3iw6 5l86qq/RThfM7sxsVqhUg9PwZkvJzjjNx7pverTJByGV40Lz7dsuBQ== =Cnst -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Nov 23 13:15: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 28AC51A1AAF for ; Sun, 23 Nov 2014 13:15:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.293 X-Spam-Level: *** X-Spam-Status: No, score=3.293 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MIME_NO_TEXT=1.999, SPF_PASS=-0.001, TRACKER_ID=1.306, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVBnlqbll8vM for ; Sun, 23 Nov 2014 13:15:11 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62B751A1AAD for ; Sun, 23 Nov 2014 13:15:11 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id D729D20098 for ; Sun, 23 Nov 2014 16:17:56 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id A315B637F5; Sun, 23 Nov 2014 16:15:10 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8FE4A63745 for ; Sun, 23 Nov 2014 16:15:10 -0500 (EST) From: Michael Richardson To: anima X-Attribution: mcr X-Mailer: MH-E 8.2; nmh 1.3; 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/WgsiT3gGl5JRnrFwuOVj3lioRpU Subject: [Anima] eckert-anima-stable-connectivity X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Nov 2014 21:15:12 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable section 2.1.3 suggests that the ACP would be numbered out of ULA. This would make sense for IoT-type uses, but I don't think operators would want to use ULA. There are two reasons for this: 1) lack of whois means that diagnostics and packet leaks, particularly at the edge of the network are rather hard to diagnose. Operators will want to use address space with whois. Not that this doesn't mean globally routable, ULA-C would work, or some form of Non-Connected Network pool would be ideal for this. (This is a recurring thing that I and a few others bring up at ARIN since around 2008, but so far few care about non-public-internet IPv6 needs.) 2) reverse DNS is important for things like SSH connections, especially with IPv6. It's hard to get ULA reverse setup, because it requires a split-horizon DNS, which means that that one has to be able to contr= =3D ol every single DNS request to go out to one's internal servers. This means getting the network to be completely concave. I predict that ACP will occasionally make associations between adjacent operators (across peering links). This is fine: the connection will come u= p, and then the two peers will say, "hey, that's not the AUTONOMOUS SYSTEM I w= as looking for", and each will want to log the other's IP, so even if one can arrange for concave DNS, it's a good idea to be able to see other side's reverse names too. =2D-=20 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) iQEVAwUBVHJOW4CLcPvd0N1lAQLQUwf7B8sQAoz4h2EDQR8DYENrWkVzcPavVe+g VWZuvSQROEOmXId8QfoSO0CPgXj2HclsMvP1bNRAcQwjI6GJ5xdKJhZWom7MTeii rBissGF9ruN4SwPUXEK1NNjJwb6LThqPoeKjmOH607qFn2RA5Za9rJdGtU7gX9ML vv4APWZrj5Xwjer2nb369FaXtZhUjEWY1oujGtHnimBOKO+2t92fj+1rNDhpk5I7 b1dwFZvEqUec8xrGFLhZjbAedBUuMbkcmivPLmSZ4c0mU5EBmNWEyDpmsOALGVHP Y/GxkyfjI+FrjwI3qJMFEzLzREzFhwIJWkZxt8zqyU16+T4Ktvk5iQ== =nSAh -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Nov 23 14:03:48 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 8BE291A1B27 for ; Sun, 23 Nov 2014 14:03:46 -0800 (PST) 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 Q6cfxqDcFu3v for ; Sun, 23 Nov 2014 14:03:44 -0800 (PST) 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 B06E11A1B14 for ; Sun, 23 Nov 2014 14:03:44 -0800 (PST) Received: by mail-pd0-f178.google.com with SMTP id g10so6426593pdj.9 for ; Sun, 23 Nov 2014 14:03:44 -0800 (PST) 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=nkuG7Zbk6tSt1R32Mg0LK2YX+O7T4lDmyYQCXmrhtdY=; b=IT7YPR3eVlmfhfR9SMIC/GFid91ue9ls4lSNA7aL9CM19kwWVHO2P9MwNkq8S0QZ0R 6iVaUe0mVLT4UuNPtymXoCeGEwZQIMtlzjcEPOxov0LdzxkUQU//ZWb5PLJ3LcJ90NXW VcLSdw+/meUPIgk7oZhcSclsAzcabnzP7iDHruFrpY5HgfR2v+Ol8mFDxq9TOAX8Wo8H tM3/wgoTb9OpqNrgP+6EbtYcEbz17QevrWfW6t+gUpHMGj0YejmbDcIWFuSiC6EWg8H+ PXYhresQ7q1it8DafiuYx+kKjWSrma0jSpRoY3dyM3cP4n+I2A9oRCqVGqrm79XDyK+e /ZoA== X-Received: by 10.66.142.166 with SMTP id rx6mr27741365pab.33.1416780223971; Sun, 23 Nov 2014 14:03:43 -0800 (PST) Received: from [192.168.178.26] (7.194.69.111.dynamic.snap.net.nz. [111.69.194.7]) by mx.google.com with ESMTPSA id is15sm10485649pbd.87.2014.11.23.14.03.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 23 Nov 2014 14:03:43 -0800 (PST) Message-ID: <547259BD.90105@gmail.com> Date: Mon, 24 Nov 2014 11:03:41 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Michael Richardson References: <29308.1416777150@sandelman.ca> In-Reply-To: <29308.1416777150@sandelman.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/uUPpDX2F7_uvUHWl4i30ojIE3z4 Cc: anima@ietf.org Subject: Re: [Anima] comments on prefix delegation and GDN protocol document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Nov 2014 22:03:46 -0000 Focussing on GDN; I will leave Sheng to comment on the prefix delegation case: On 24/11/2014 10:12, Michael Richardson wrote: ... > wrt: the GDN protocol and requirements: > > 5.2.1: why does the GDN protocol need to run over IPv4? > I would agree that it might need to configure IPv4 services, but I can't > see a reason why it should be complicated by the need to support legacy > 32-bit stuff. Because the context is the whole Internet, and although my instinct is the same as yours, I don't think it's realistic for the next ten or twenty years to assume IPv6 transport everywhere. > I would suspect that the GDN protocol might run in the supervisor > processor for a router/switch/server (server: I'm thinking IBM Service > Processor, DELL iDrac, as well as in the control plane processor of a > router), so I can't see an installed base reason for IPv4/32-bit support GDN could run anywhere, really. That's what the "G" means, isn't it? > > 5.2.3: I think the GNDP should run over DTLS or IKEv2/IPsec (pick one), and > that the certificates involved should key that channel rather than > invent a new one. Personally I'm open to not reinventing wheels. I regard this area as very liable to change, and it needs to be fully compatible with the trust bootstrap stuff too. > 5.2.3.1: algorithm agility, you can't say: don't fallback to an algorithm > considered weak. If the software author knew the algorithm was > weak at the time the code was written, the algorithm would > not have been included. That's the whole problem here: you need to > be able to incrementally deploy new algorithms, so you need an > upgrade mechanism, and you *have to* fallback when the other node > does not support stronger algorithm, and the attacker will > convince you... > > The only out is that you can do something in the certificates > that says what ought to be supported. We've also got policy intent in the future too, like an intent that says "Don't accept algorithm X any more." (Doesn't putting it in the cert mean that you need to be very sure that certificate revocation will work? Well, I guess that needs to work anyway.) > As far as I can see the only reason to use assymetric signatures on each > message is in order to support multicast. > > My understanding is that this protocol will primarily occur between adjacent > routing equipment. I don't have that understanding. Actually we specifically want to assume as little as possible, and we specically want to be able to reach more distant peers if they are the best negotiation counterpart for some resource. > While we pretend via Layer-2 devices that ethernet is > still made up of broadcast coax cables, except for wifi, there are probably > only two devices connected at each end of the cable. > So I suggest that while a multicast based discovery protocol is appropriate > (and why not use DHCPv6 or RPL), once the end point is discovered, it seems > that one should run GNDP over point to point DLTS or IPsec. Yes, once you have identified the counterpart it should be unicast and secure. Thanks! Brian From nobody Mon Nov 24 01:28: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 74FD41A1EE8 for ; Mon, 24 Nov 2014 01:28:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1S8fNNpVNk5V for ; Mon, 24 Nov 2014 01:28:34 -0800 (PST) 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 4945F1A1EE9 for ; Mon, 24 Nov 2014 01:28:34 -0800 (PST) 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 BLY88862; Mon, 24 Nov 2014 09:28:32 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 24 Nov 2014 09:28:32 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.72]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Mon, 24 Nov 2014 17:28:27 +0800 From: Sheng Jiang To: Michael Richardson , "anima@ietf.org" Thread-Topic: [Anima] comments on prefix delegation and GDN protocol document Thread-Index: AQHQB2I3Sfw2I+WNPEyDG0xA5b+q5ZxvAAuw Date: Mon, 24 Nov 2014 09:28:26 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AF9BF48@nkgeml512-mbx.china.huawei.com> References: <29308.1416777150@sandelman.ca> In-Reply-To: <29308.1416777150@sandelman.ca> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.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/fv-LBNGyIY1uONYhXm8wKMTYuJQ Subject: Re: [Anima] comments on prefix delegation and GDN protocol document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 09:28:37 -0000 SGksIE1pY2hhZWwsDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4gVGhlIHJlcGxpZXMgaW4g bGluZXMuDQoNCj5Gcm9tOiBBbmltYSBbbWFpbHRvOmFuaW1hLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBNaWNoYWVsDQo+UmljaGFyZHNvbg0KPg0KPnNlY3Rpb24gMy4xDQo+d2h5IHNl bmQgYSBHRE4gZGlzY292ZXJ5IG1lc3NhZ2UgYXNraW5nIGZvciBhIFByZWZpeCBPcHRpb24sIGlu c3RlYWQgb2YganVzdA0KPnNlbmRpbmcgYSBESENQdjYgRGlzY292ZXJ5IG1lc3NhZ2Ugd2l0aCBQ RCBhcyBhIHJlcXVlc3Q/DQoNClRoZSBESENQdjYgUEQgZG9lcyBub3Qgd29yayB3aXRoIERIQ1B2 NiBkaXNjb3ZlcnkgbWVzc2FnZSwgYnkgZGVmaW5pdGlvbi4gUkZDMzYzMyAoREhDUHY2IFBEKSBp cyBhY3R1YWxseSB3b3JraW5nIGJldHdlZW4gcm91dGVycywgcmF0aGVyIHRoYW4gdHJhZGl0aW9u YWwgREhDUHY2IHNlcnZlci9jbGllbnQuIFNvLCBESENQdjYgUEQgaXMgYmFzZWQgb24gdGhlIGFz c3VtcHRpb24sIHRoZSByZXF1ZXN0aW5nIHJvdXRlciBhbHJlYWR5IGtub3cgdGhlIHJlcXVlc3Qg cm91dGVyLCB0aGF0J3Mgd2hlcmUgdG8gc2VuZCB0aGUgcHJlZml4IHBkIHJlcXVlc3QuIFNlY3Rp b24gMy4xIGRlc2NyaWJlcyBhIGJlaGF2aW9yIHRvIGRpc2NvdmVyIHRoZSByZXF1ZXN0IHJvdXRl ciB1c2luZyBHRE4gcHJvdG9jb2wuDQoNCj5JcyB0aGVyZSBhIHdheSB0byBnZXQgYSBwcmVmaXgg dGhhdCBpc24ndCBESENQdjZQRD8NCj5JIGd1ZXNzIHNlY3Rpb24gMy4zIGxlYXZlcyB0aGlzIGFz IGFuIG9wZW4gcXVlc3Rpb24uLi4gSSB3b3VsZCBzYXksIGVpdGhlciBkbw0KPkRIQ1B2Niwgb3Ig ZG9uJ3QsIGJ1dCBydW4gYSBwcm90b2NvbCB0byBkZWNpZGUgaWYgeW91IGFyZSBnb2luZyB0byBy dW4gYQ0KPnByb3RvY29sLg0KDQpTbyBmYXIsIHRoZSBESENQdjYgUEQgc2VlbXMgb25seSB3YXkg dG8gZ2V0IGEgcHJlZml4LCB1bmxlc3Mgd2UgYWxzbyBzdXBwb3J0IGl0IHVzaW5nIEdETi4gVGhl IHNlY3Rpb24gcG9pbnQgb2Ygc2VjdGlvbiAzLjMgaXMgbm90IHdoZXRoZXIgcnVuIERIQ1B2NlBE LiBUaGUgcG9pbnQgaXMgdG8gZGVjaWRlIHdoaWNoIGRldmljZSB0byByZXF1ZXN0IGEgcHJlZml4 IGFuZCB3aGV0aGVyIHRoYXQgZGV2aWNlIGhhcyBlbm91Z2ggcmVzb3VyY2UuIElmIG5vLCB3aGV0 aGVyIGNoYW5nZSB0aGUgcmVxdWVzdGVkIGRldmljZSBvciBzZXR0bGUgZG93biB3aXRoIGEgc21h bGxlciBwcmVmaXguDQoNCj5JJ20gdW5jbGVhciBpZiB0aGUgcHJlZml4IGJlaW5nIGFsbG9jYXRl ZCBpcyBmb3IgcHJvZHVjdGlvbiB1c2UsIG9yIGlzIGZvcg0KPm51bWJlcmluZyB0aGUgY29udHJv bCBjaGFubmVsKHMpLg0KDQpCb3RoIHVzYWdlcyBhcmUgY292ZXJlZCBieSB0aGUgc2FtZSBwcm9j ZWR1cmUuDQoNCj5JIHdpbGwgbm90ZSB0aGF0IGlmIG9uZSB1c2VzIFJQTCB0byBidWlsZCBhIGNv bnRyb2wgY2hhbm5lbCwgdGhhdCBSUEwgYWxzbw0KPmNhbiBkaXN0cmlidXRlIHByZWZpeGVzIGlu IFBJT3MuDQoNClRoZSBhZHZlcnRpc2VtZW50IG9mIHByZWZpeCBpbmZvcm1hdGlvbiwgaW4gTkQg b3IgUlBMLCBpcyB2ZXJ5IGRpZmZlcmVudCBmcm9tIHByZWZpeCBkZWxlZ2F0aW9uLiBUaGUgZm9y bWVyIGlzIGEgZmxvb2RpbmcgaW5mb3JtYXRpb24uIFRoZSBwcmVmaXggaXMgc2hhcmVkIGJ5IGFu eSBub2RlcyB0aGF0IHJlY2VpdmVkIHRoZSBwcmVmaXggaW5mb3JtYXRpb24uIFRoZSBsYXR0ZXIg aXMgdG8gZGVsZWdhdGUgYSBwcmVmaXggdG8gdGhlIHJlY2VpdmVkIG5vZGUgb25seS4gRnVydGhl cm1vcmUsIHdlIGFsc28gbmVlZCB0byB0cmFuc2ZlciB0aGUgcHJlZml4IGFtb25nIG11bHRpcGxl IHJlcG9zaXRvcmllcy4NCg0KQmVzdCByZWdhcmRzLA0KDQpTaGVuZw0K From nobody Tue Nov 25 21:59: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 79DA51A8940; Tue, 25 Nov 2014 13:37:49 -0800 (PST) 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 pMcoWeLv6m4n; Tue, 25 Nov 2014 13:37:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8711A8909; Tue, 25 Nov 2014 13:37:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Liaison Statement Management Tool To: Toerless Eckert , Sheng Jiang X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141125213747.4784.98968.idtracker@ietfa.amsl.com> Date: Tue, 25 Nov 2014 13:37:47 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/anima/EcWiMR88a__zhaPV4U3ssSOfzJI X-Mailman-Approved-At: Tue, 25 Nov 2014 21:59:20 -0800 Cc: Benoit Claise , Joel Jaeggli , tayeb.benmeriem@orange.com, anima@ietf.org Subject: [Anima] New Liaison Statement, "Liaison Statement to IETF regarding Comments on ANIMA WG charter from ETSI NTECH AFI and suggested synergies and collaboration" X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 21:37:49 -0000 Title: Liaison Statement to IETF regarding Comments on ANIMA WG charter from ETSI NTECH AFI and suggested synergies and collaboration Submission Date: 2014-11-25 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1365/ Please reply by 2014-12-15 From: ETSI NTECH (Chantal Bonardi ) To: Autonomic Networking Integrated Model and Approach (Toerless Eckert , Sheng Jiang ) Cc: Benoit Claise ,Joel Jaeggli ,anima@ietf.org,tayeb.benmeriem@orange.com Response Contact: Technical Contact: Purpose: For comment Body: We hereby propose ideas on IETF related work that could be carried out par ANIMA WG to complement the work in ETSI NTECH/AFI WG on Evolution of Management towards Autonomic Future Internet (AFI) to prevent duplication of work and effort already undertaken by ETSI NTECH AFI for years. Supplementary details can be found in the Annexes. This input may be vital to IETF groups that are working on topics that are closely related to the work of ETSI NTECH/AFI WG. 1. Overall description: Comments on the ANIMA WG Charter The ETSI NTECH AFI working group is aware that IETF recently created a new working group on autonomic networking named “ANIMA”. We reviewed the draft charter description for ANIMA and would like to provide a set of comments and suggestions on how the two groups could collaborate and complement each other. 2. Actions: Suggested synergies 2.1. IETF related work that could be carried out in IETF/ANIMA WG to complement the work in ETSI NTECH/AFI WG We think at least the following collaboration topics should be of high interest to both parties: • The process of analysis of requirements for autonomic behaviors in networks, in management tasks and in network automation (in general) in order to design autonomic functions and associated communications on the basis of instantiation of the GANA model [1] onto target reference architecture, requires answers to questions such as: • What protocols (could be IETF protocols) can be used by the instantiated of GANA Functional Blocks (FBs) on the reference points of the FBs to communicate and to convey data/information • In the target environment, are there protocols that already exist and could be used as the vehicles • to communicate the FBs messages and data/information on the reference points, or should new IETF protocol(s) be designed for that? • What messages, data format and control semantics should the FBs communicate to implement the requirements for autonomic behavior and/or automation in general • Are special IETF protocols required to be introduced? Those questions imply that IETF protocols and solutions can be introduced to address them. This may lead to a number of ANIMA WG drafts being introduced. The requirements analysis is an ongoing process in ETSI NTECH/AFI, and the outcome can feed input to such ANIMA WG related activities. • ETSI NTECH/AFI has produced a Technical Specification (recently published) [2] [3] on Scenarios, Use Cases and Requirements for Autonomic/Self-Managing Future Internet. ANIMA WG experts can also perform analysis of those scenarios, use cases and related requirements for autonomic behaviors, in order to derive ANIMA WG based solutions to addressing such requirements. 2.2. Workshops and Tutorials ETSI NTECH/AFI welcomes the idea of co-organizing workshops or can be invited to meetings where they can give a tutorial on AFI work on Autonomic Networking related Specifications, such as the AFI GANA Reference Model for Autonomic Networking, Cognitive Networking and Self-Management, and its instantiations onto various reference architectures toward autonomics-enabled networks, e.g. during IETF events. For example, ETSI NTECH/AFI does co-organize workshops with ITU-T SG13, SG2 and SG15, and also with other Multi-SDOs/Fora. Thank you, Looking forward to progressing to the next level of our collaboration, ETSI NTECH AFI Working Group Attachments: Liaison Statement to IETF regarding Comments on ANIMA WG charter from ETSI NTECH AFI and suggested synergies and collaboration https://datatracker.ietf.org/documents/LIAISON/liaison-2014-11-25-etsi-ntech-anima-liaison-statement-to-ietf-regarding-comments-on-anima-wg-charter-from-etsi-ntech-afi-and-suggested-synergies-and-c-attachment-1.pdf From nobody Thu Nov 27 00:25: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 251691A0166 for ; Thu, 27 Nov 2014 00:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nv2j-HPCbpWw for ; Thu, 27 Nov 2014 00:25:08 -0800 (PST) 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 246F41A0360 for ; Thu, 27 Nov 2014 00:25:08 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPH06908; Thu, 27 Nov 2014 08:25:06 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 27 Nov 2014 08:25:05 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.72]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Thu, 27 Nov 2014 16:24:53 +0800 From: Sheng Jiang To: "anima@ietf.org" Thread-Topic: draft ANIMA minutes Thread-Index: AdAKG51RKQnbyKuVQbiqPgqRxlVDAA== Date: Thu, 27 Nov 2014 08:24:52 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AFAEA90@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.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/zXZT2UpAPo-FQ6O_4xzenLHn1eI Cc: Laurent Ciavaglia , "Liubing \(Leo\)" Subject: [Anima] draft ANIMA minutes 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, 27 Nov 2014 08:25:10 -0000 QWxsIEFOSU1BLA0KIA0KUGxlYXNlIGZpbmQgYmVsb3cgdGhlIGRyYWZ0IG1pbnV0ZXMgb2YgdGhl IEFOSU1BIHNlc3Npb24gaW4gSUVURiA5MToNCg0KaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVk aW5ncy85MS9taW51dGVzL21pbnV0ZXMtOTEtYW5pbWENCg0KVGhhbmtzIExhdXJlbnQgQ2lhdmFn bGlhIGFuZCBCaW5nIExpdSBmb3IgdGFraW5nIHRoZSBtaW51dGVzLg0KDQpQbGVhc2Ugc2VuZCB5 b3VyIGNvbW1lbnRzIHRvIHRoZSBjby1jaGFpcnMgYnkgRGVjIDA0LCAyMDE0Lg0KIA0KQ2hlZXJz LA0KDQpTaGVuZyArIFRvZXJsZXNzDQo= From nobody Fri Nov 28 17:26: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 466651A1BB4 for ; Fri, 28 Nov 2014 17:26:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juIz_GVhWS8n for ; Fri, 28 Nov 2014 17:26:26 -0800 (PST) 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 E74B71A1BA4 for ; Fri, 28 Nov 2014 17:26:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2859; q=dns/txt; s=iport; t=1417224386; x=1418433986; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=eLSxmxslA5RKjXVgEl+3RV6sESRah3P+vDUUrJHuFBY=; b=jm0yett3HCv+N/SdRzpPNylVWL3WWk05MUJKKOiv6mwfG3oCuOINa7R5 Onfdr1O0qDzaiCgV8+n+KtG3VDXvvTrtXe7anfT0afMNwgAnNIwYLWcvN 6FM1V1Cux+ESxgRa5PHXO8V8ps/AUSaQ+JMn4kbJ7k7c3I9kaky2eRoLt E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAD4geVStJA2E/2dsb2JhbABbgwZRWMcKCoZOAoELFgEBAQEBfYQCAQEBAwEBAQE3NAsFCwsYCSUPBRM2E4g3CQ3SHgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEkHsHgymBHwWLFZExAZVDhBweMIJHAQEB X-IronPort-AV: E=Sophos;i="5.07,480,1413244800"; d="scan'208";a="101049070" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-8.cisco.com with ESMTP; 29 Nov 2014 01:26:26 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sAT1QOHO003603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 29 Nov 2014 01:26: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 sAT1QNPr026585; Fri, 28 Nov 2014 17:26:23 -0800 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id sAT1QNTh026584; Fri, 28 Nov 2014 17:26:23 -0800 Date: Fri, 28 Nov 2014 17:26:23 -0800 From: Toerless Eckert To: Michael Richardson Message-ID: <20141129012623.GA25550@cisco.com> References: <29880.1416777310@sandelman.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <29880.1416777310@sandelman.ca> User-Agent: Mutt/1.4.2.2i Archived-At: http://mailarchive.ietf.org/arch/msg/anima/QSAI7nPP7-pbRb7FTYazxzNJqiQ Cc: anima Subject: Re: [Anima] eckert-anima-stable-connectivity 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, 29 Nov 2014 01:26:28 -0000 On Sun, Nov 23, 2014 at 04:15:10PM -0500, Michael Richardson wrote: > > section 2.1.3 suggests that the ACP would be numbered out of ULA. > This would make sense for IoT-type uses, but I don't think operators would > want to use ULA. There are two reasons for this: > 1) lack of whois means that diagnostics and packet leaks, particularly > at the edge of the network are rather hard to diagnose. Operators > will want to use address space with whois. Not that this doesn't > mean globally routable, ULA-C would work, or some form of Non-Connected > Network pool would be ideal for this. (This is a recurring thing that > I and a few others bring up at ARIN since around 2008, but so far > few care about non-public-internet IPv6 needs.) Hmm.. We propose (and did implement) ULA because it make zero-touch address assignment easy. I also thought it was a benefit to have non Internte routeable addresses for an OAM plan that ultimately is meant to be protected from outside access. I am sure it would be possible to make ACP work with a different prefix than ULA. Could for example be derived from S-UDI subject name elements. > 2) reverse DNS is important for things like SSH connections, especially > with IPv6. It's hard to get ULA reverse setup, because it requires > a split-horizon DNS, which means that that one has to be able to control > every single DNS request to go out to one's internal servers. > This means getting the network to be completely concave. Well... It wouldn't be "anywhere" in the network, but just within dedicated management areas (NOC). Any stats how popular or unpopular split-DNS is ? I've seen companies seeing it as a big benefit. DOes the IETF have any docs that make judgement calls about it ? > I predict that ACP will occasionally make associations between adjacent > operators (across peering links). This is fine: the connection will come up, > and then the two peers will say, "hey, that's not the AUTONOMOUS SYSTEM I was > looking for", and each will want to log the other's IP, so even if one can > arrange for concave DNS, it's a good idea to be able to see other side's > reverse names too. So thats the first explicit example of diagnostic, and it's a good one. I'd say we could also put the diagnostics into the AN discovery protocols aka: have them announce a domain-name. Thanks a lot for these comments. Will integrte the technical aspects into the draft. Cheers Toerless > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- Toerless Eckert, eckert@cisco.com From nobody Sat Nov 29 10:55: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 A3D3A1A1DFA for ; Sat, 29 Nov 2014 10:55:27 -0800 (PST) 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 szt3XFWSqphM for ; Sat, 29 Nov 2014 10:55:26 -0800 (PST) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E32FB1A1DE1 for ; Sat, 29 Nov 2014 10:55:25 -0800 (PST) Received: by mail-pd0-f175.google.com with SMTP id y10so8328286pdj.6 for ; Sat, 29 Nov 2014 10:55:25 -0800 (PST) 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=ypaZIz8qcXJh6DY7LBavoMpD2QmKGzsHNStwQQ2sN/o=; b=0WzZ1ADeMMPT8+fhgq07iYyTZITncL6e2x0oK04ysd4/v7KXx2SQJEc+REi9uB+rqe nMZ2s6FMq5+cnp5rWjca4yNkzCJ7DeHg3ub4oQKC70GQZvDSUNIJubNwZiOXduCaDSMR TfaBdwe02lULuf1MxcEXid+UymCc06SYwpuaRUoH4WUgZiN+n1RDW817Utk/C5mt7daR +JRCrCY9qFnb6oJTKp/sKhI0U0yoIUPztN+HgOQ6YRACVar+De4amzUSoGGu2twX1PJm rDfHDFp26yyDsUAlpB1vXMpy/VAUh9QXqJdtTIW7olZZhuYGNepdiKxddwejGAaCuvKN fIXA== X-Received: by 10.68.132.198 with SMTP id ow6mr84809404pbb.61.1417287325165; Sat, 29 Nov 2014 10:55:25 -0800 (PST) Received: from [192.168.178.26] (40.196.69.111.dynamic.snap.net.nz. [111.69.196.40]) by mx.google.com with ESMTPSA id qf1sm13270595pdb.49.2014.11.29.10.55.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 29 Nov 2014 10:55:24 -0800 (PST) Message-ID: <547A16A2.9030904@gmail.com> Date: Sun, 30 Nov 2014 07:55:30 +1300 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: <29880.1416777310@sandelman.ca> <20141129012623.GA25550@cisco.com> In-Reply-To: <20141129012623.GA25550@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/nTRXUnPEjV5C8aIBSeJNpXXdy5o Cc: Michael Richardson , anima Subject: Re: [Anima] eckert-anima-stable-connectivity 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, 29 Nov 2014 18:55:28 -0000 On 29/11/2014 14:26, Toerless Eckert wrote: > On Sun, Nov 23, 2014 at 04:15:10PM -0500, Michael Richardson wrote: ... >> 2) reverse DNS is important for things like SSH connections, especially >> with IPv6. I see this as a potential problem. It is widely felt that reverse DNS is a bogus requirement, because tens of millions of reverse DNS entries are automatically synthesised and therefore meaningless as any kind of authentication. There are also already numerous reports of operational failures caused by mail exchangers and the like that expect them for IPv6. I think we should draw a line in the sand and ensure that nothing in anima requires reverse DNS. It certainly has no place in a trust model. I think ULAs are a fine idea for this, but we do have to work out the rules if a network partitions or merges. Probably the NOC itself needs to "own" the ULA (but then is the NOC itself distributed, in which case who owns the prefix after partition?). Of course there should be an option to use a normal prefix if the operator prefers. Brian From nobody Sun Nov 30 09:19: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 D1B051A1A36 for ; Sun, 30 Nov 2014 09:19:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FagEHzr-UZNR for ; Sun, 30 Nov 2014 09:19:34 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99D681A1A2D for ; Sun, 30 Nov 2014 09:19:34 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 6004B20012; Sun, 30 Nov 2014 12:22:43 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 7E6D9637F5; Sun, 30 Nov 2014 12:19:32 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6684663740; Sun, 30 Nov 2014 12:19:32 -0500 (EST) From: Michael Richardson To: anima In-Reply-To: <20141129012623.GA25550@cisco.com> References: <29880.1416777310@sandelman.ca> <20141129012623.GA25550@cisco.com> 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/VO6dc0qSbjPsQvop5WcZtbgFHjY Cc: Toerless Eckert Subject: Re: [Anima] eckert-anima-stable-connectivity X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Nov 2014 17:19:38 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Toerless Eckert wrote: > On Sun, Nov 23, 2014 at 04:15:10PM -0500, Michael Richardson wrote: >>=20 >> section 2.1.3 suggests that the ACP would be numbered out of ULA. >> This would make sense for IoT-type uses, but I don't think operators= would >> want to use ULA. There are two reasons for this: >> 1) lack of whois means that diagnostics and packet leaks, particular= ly >> at the edge of the network are rather hard to diagnose. Operators >> will want to use address space with whois. Not that this doesn't >> mean globally routable, ULA-C would work, or some form of Non-Connec= ted >> Network pool would be ideal for this. (This is a recurring thing that >> I and a few others bring up at ARIN since around 2008, but so far >> few care about non-public-internet IPv6 needs.) > Hmm.. We propose (and did implement) ULA because it make zero-touch > address assignment easy. I also thought it was a benefit to have non > Internte routeable addresses for an OAM plan that ultimately is meant= to be > protected from outside access. Yes, I totally agree with it being non-routed. I'm saying the problem is with ULA-R. >> 2) reverse DNS is important for things like SSH connections, especia= lly >> with IPv6. It's hard to get ULA reverse setup, because it requires >> a split-horizon DNS, which means that that one has to be able to con= trol >> every single DNS request to go out to one's internal servers. >> This means getting the network to be completely concave. > Well... It wouldn't be "anywhere" in the network, but just within > dedicated management areas (NOC). Any stats how popular or unpopular= =20 > split-DNS is ? I've seen companies seeing it as a big benefit. DOes > the IETF have any docs that make judgement calls about it ? Split-DNS is impossible for many ISPs --- their networks are not concave. Some try. Many fail. The result is usually IP[v4] address literals in conf= ig files, which makes upgrade to IPv6 very very very error prone. Split-DNS is very very problematic for enterprises that have road warriors because the remote-access connections make their network not concave...=20 If you then throw *contractors* who sit inside Enterprise A, and have connectivity to the inside of Enterprise B, and it's impossible. Those fol= ks either have a horrible life of "VPN on" / "work a bit" / "VPN off" / "work = a bit"/.. or they just resort to using IP address literals, because nothing else work= s. >> I predict that ACP will occasionally make associations between adjac= ent >> operators (across peering links). This is fine: the connection will= come up, >> and then the two peers will say, "hey, that's not the AUTONOMOUS SYS= TEM I was >> looking for", and each will want to log the other's IP, so even if o= ne can >> arrange for concave DNS, it's a good idea to be able to see other si= de's >> reverse names too. > So thats the first explicit example of diagnostic, and it's a good on= e. > I'd say we could also put the diagnostics into the AN discovery proto= cols > aka: have them announce a domain-name. > Thanks a lot for these comments. Will integrte the technical aspects = into > the draft. Thanks. {I sold some of the first commercial firewalls in the mid-1990s that includ= ed split-DNS as not only the recommended option, but the default, hard-to-chan= ge option, and I see it as being a serious serious mistake. It was security-through-obscurity. } =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVHtRpICLcPvd0N1lAQIbZAgAsj/SN47jszX0FaE8pa/YowXGQKn6H5UJ S2VwpA1x19GFf3a4ewlHy2B+SSmWC+37UYGwmMjAvYNCOqqv+DsbhqueL0l+3n2H 7yznT4fNs7xtnM4bU9xT+7kTTLVh8a2JeCSNtZ6CPWxPeiGHB0C05bG4V/e5IBX0 wDfWCJbXrNl+JzHn+to1nztJosavcLgKTHPFCfKeKrg9TnCvsyjCzjrEw4y2D2z6 uZS7zbv51UhLsDDuuEi4f7/4qjc4TNZxhYKRPWaLCUfuJVE/xAHk88H41PxUXhx3 JoOIf2VPVYoaXVacNk97sZ5cGA9qD3AiXUlk11tFMnL74PG6IQcZ3g== =rC2t -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Nov 30 09:28: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 C774B1A1A3B for ; Sun, 30 Nov 2014 09:28:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqOnLJB0BJxC for ; Sun, 30 Nov 2014 09:28:10 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E55001A1A3C for ; Sun, 30 Nov 2014 09:28:09 -0800 (PST) Received: from mb-aye.local (c-67-171-230-191.hsd1.wa.comcast.net [67.171.230.191]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id sAUHS2Lq022262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 30 Nov 2014 17:28:03 GMT (envelope-from joelja@bogus.com) Message-ID: <547B539C.9030101@bogus.com> Date: Sun, 30 Nov 2014 09:27:56 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:34.0) Gecko/20100101 Thunderbird/34.0 MIME-Version: 1.0 To: Michael Richardson , anima References: <29880.1416777310@sandelman.ca> <20141129012623.GA25550@cisco.com> <18588.1417367972@sandelman.ca> In-Reply-To: <18588.1417367972@sandelman.ca> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6sKEBvHXGmmkM8IOKttanoh8j7Ud7qIUa" Archived-At: http://mailarchive.ietf.org/arch/msg/anima/NDS6MJ_NRxgxxmC6TTPNxjOmr9A Cc: Toerless Eckert Subject: Re: [Anima] eckert-anima-stable-connectivity X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Nov 2014 17:28:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6sKEBvHXGmmkM8IOKttanoh8j7Ud7qIUa Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 11/30/14 9:19 AM, Michael Richardson wrote: >=20 > Toerless Eckert wrote: > > On Sun, Nov 23, 2014 at 04:15:10PM -0500, Michael Richardson wrot= e: > >>=20 > >> section 2.1.3 suggests that the ACP would be numbered out of ULA= =2E > >> This would make sense for IoT-type uses, but I don't think opera= tors would > >> want to use ULA. There are two reasons for this: > >> 1) lack of whois means that diagnostics and packet leaks, partic= ularly > >> at the edge of the network are rather hard to diagnose. Operator= s > >> will want to use address space with whois. Not that this doesn'= t > >> mean globally routable, ULA-C would work, or some form of Non-Co= nnected > >> Network pool would be ideal for this. (This is a recurring thing= that > >> I and a few others bring up at ARIN since around 2008, but so fa= r > >> few care about non-public-internet IPv6 needs.) >=20 > > Hmm.. We propose (and did implement) ULA because it make zero-tou= ch > > address assignment easy. I also thought it was a benefit to have = non > > Internte routeable addresses for an OAM plan that ultimately is m= eant to be > > protected from outside access. >=20 > Yes, I totally agree with it being non-routed. > I'm saying the problem is with ULA-R. >=20 > >> 2) reverse DNS is important for things like SSH connections, esp= ecially > >> with IPv6. It's hard to get ULA reverse setup, because it requi= res > >> a split-horizon DNS, which means that that one has to be able to= control > >> every single DNS request to go out to one's internal servers. > >> This means getting the network to be completely concave. >=20 > > Well... It wouldn't be "anywhere" in the network, but just within= > > dedicated management areas (NOC). Any stats how popular or unpopu= lar=20 > > split-DNS is ? I've seen companies seeing it as a big benefit. DO= es > > the IETF have any docs that make judgement calls about it ? >=20 > Split-DNS is impossible for many ISPs --- their networks are not concav= e. > Some try. Many fail. The result is usually IP[v4] address literals in = config > files, which makes upgrade to IPv6 very very very error prone. >=20 > Split-DNS is very very problematic for enterprises that have road warri= ors > because the remote-access connections make their network not concave...= =20 >=20 > If you then throw *contractors* who sit inside Enterprise A, and hav= e > connectivity to the inside of Enterprise B, and it's impossible. Those= folks > either have a horrible life of "VPN on" / "work a bit" / "VPN off" / "w= ork a bit"/.. > or they just resort to using IP address literals, because nothing else = works. Resolvers don't come with scopes attached to them (neither do names) so the "I have to make this work with more than one set at the same time" is basically a non-starter. Even those those of us who have had to misfortune to have to deploy it typically expect it to break with some regularity. > >> I predict that ACP will occasionally make associations between a= djacent > >> operators (across peering links). This is fine: the connection = will come up, > >> and then the two peers will say, "hey, that's not the AUTONOMOUS= SYSTEM I was > >> looking for", and each will want to log the other's IP, so even = if one can > >> arrange for concave DNS, it's a good idea to be able to see othe= r side's > >> reverse names too. >=20 > > So thats the first explicit example of diagnostic, and it's a goo= d one. > > I'd say we could also put the diagnostics into the AN discovery p= rotocols > > aka: have them announce a domain-name. >=20 > > Thanks a lot for these comments. Will integrte the technical aspe= cts into > > the draft. >=20 > Thanks. > {I sold some of the first commercial firewalls in the mid-1990s that in= cluded > split-DNS as not only the recommended option, but the default, hard-to-= change > option, and I see it as being a serious serious mistake. It was > security-through-obscurity. } >=20 >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 --6sKEBvHXGmmkM8IOKttanoh8j7Ud7qIUa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlR7U5wACgkQ8AA1q7Z/VrKnGwCggDsQdFF7z0pFNwYqjPZbpjki HG4AnRRgvhYYU28OdKKKouV5DpRU21PS =8E/a -----END PGP SIGNATURE----- --6sKEBvHXGmmkM8IOKttanoh8j7Ud7qIUa-- From nobody Sun Nov 30 09:57: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 01C281A1A4A for ; Sun, 30 Nov 2014 09:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8nUq4DqW4p6 for ; Sun, 30 Nov 2014 09:57:26 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C1AF1A1A42 for ; Sun, 30 Nov 2014 09:57:26 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C92A920012 for ; Sun, 30 Nov 2014 13:00:34 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id AD118637F5; Sun, 30 Nov 2014 12:57:24 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 984AB637EA for ; Sun, 30 Nov 2014 12:57:24 -0500 (EST) From: Michael Richardson To: anima In-Reply-To: <547A16A2.9030904@gmail.com> References: <29880.1416777310@sandelman.ca> <20141129012623.GA25550@cisco.com> <547A16A2.9030904@gmail.com> 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/avWIyXWsYBlYANjtAuwNXe8_J0c Subject: Re: [Anima] eckert-anima-stable-connectivity X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Nov 2014 17:57:28 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Brian E Carpenter wrote: > On 29/11/2014 14:26, Toerless Eckert wrote: >> On Sun, Nov 23, 2014 at 04:15:10PM -0500, Michael Richardson wrote: > ... >>> 2) reverse DNS is important for things like SSH connections, especi= ally >>> with IPv6. > I see this as a potential problem. It is widely felt that > reverse DNS is a bogus requirement, because tens of millions of > reverse DNS entries are automatically synthesised and therefore > meaningless as any kind of authentication. There are also It was never about authentication, and the various detractors of reverse DNS do not listen very well. It's about auditing, and it's about reputation. > already numerous reports of operational failures caused by mail > exchangers and the like that expect them for IPv6. Too late.=20 You can not deliver email to any major provider over IPv6 without a valid reverse name. Should his affect ANIMA? I don't think so, but that boat has sailed.=20 The problem with ULA-Random in an enterprise is that, when it escapes, it is impossible to know who is using it for what.=20=20 =2D-=20 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) iQEVAwUBVHtahICLcPvd0N1lAQK6awf/Saq0bfEDTFabejEF+9zhuDqSu/JvJzx0 UgxvAaNMfySUsMaEAyd3WRjeC6LUjx56a2U1KiUcOAPdTYAwZeUsRT3+LfLks0wH blsJXXLMftJUeerPJOhCB54551t0dDM9GU3RNjaDFyfIoDiKBZiKbnXnrHuCV4to ZfaSABUlL9Ql+02m3rkybcdjwjauU5SclE1RT8/6RlblImrXZTlSL7pdPeWZ6M7z +wn4j12Aj9OtVPHe6pjTUoyGsPHB6NKm1waBcXsw8pf2rBumPJ1lT+TTkDILmJVa af1rcL5EIFuaRxCgseDy15ig0FI7M2xD+NHe8yjclN2zkGap4WB2xw== =4qqE -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Nov 30 11:08: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 A771A1A1A6B for ; Sun, 30 Nov 2014 11:08:25 -0800 (PST) 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 yT_TxVQnd3Or for ; Sun, 30 Nov 2014 11:08:24 -0800 (PST) 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 098B41A1A69 for ; Sun, 30 Nov 2014 11:08:24 -0800 (PST) Received: by mail-pd0-f179.google.com with SMTP id w10so9485340pde.38 for ; Sun, 30 Nov 2014 11:08:23 -0800 (PST) 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=LcZBxCJTdXz9FdLccjVaWZC7ERQ2VlKYisI42IWFbDI=; b=r4IZTnB46IgM2RYFcl+nrjRKYy+1Z6sYl0po68KD0AyeLmvqxqZ1mNr3zEacyNjwny /BC7Da58VBjAUWsCK64h2dMZex5tf1GBI2sxA8dncUgh+V9/Uo4Z1d3c3Zpo3ksKjfcT XzoF1o3vOJ4Z1o2lUvcigAdMuyWAHvpxHECY/+QYdbsiIg77n8EuCrMqBcLDZu9NMI6R 2ahO2KWTuno/dDVu8GBHNnmO1BIyXD3LfyBBX5gViJlAUKQosm7Xmqs5N6nqXCjby+2D Gu7hjpfyRh2F9/7C5Slb85q5/V1BsBWfTuqxL+uyFa8mcUmJL+XZk4AK0uxrgfYEfcDA msow== X-Received: by 10.70.19.226 with SMTP id i2mr46888626pde.26.1417374503290; Sun, 30 Nov 2014 11:08:23 -0800 (PST) Received: from [192.168.178.26] (16.197.69.111.dynamic.snap.net.nz. [111.69.197.16]) by mx.google.com with ESMTPSA id ye3sm15385351pbb.93.2014.11.30.11.08.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 30 Nov 2014 11:08:22 -0800 (PST) Message-ID: <547B6B1D.9090003@gmail.com> Date: Mon, 01 Dec 2014 08:08:13 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Michael Richardson References: <29880.1416777310@sandelman.ca> <20141129012623.GA25550@cisco.com> <547A16A2.9030904@gmail.com> <26092.1417370244@sandelman.ca> In-Reply-To: <26092.1417370244@sandelman.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/3qWuTP6NDFq5w1zYUqw7dIOjqIw Cc: anima Subject: Re: [Anima] eckert-anima-stable-connectivity X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Nov 2014 19:08:25 -0000 On 01/12/2014 06:57, Michael Richardson wrote: > Brian E Carpenter wrote: > > On 29/11/2014 14:26, Toerless Eckert wrote: > >> On Sun, Nov 23, 2014 at 04:15:10PM -0500, Michael Richardson wrote: > > ... > >>> 2) reverse DNS is important for things like SSH connections, especially > >>> with IPv6. > > > I see this as a potential problem. It is widely felt that > > reverse DNS is a bogus requirement, because tens of millions of > > reverse DNS entries are automatically synthesised and therefore > > meaningless as any kind of authentication. There are also > > It was never about authentication, and the various detractors of reverse DNS > do not listen very well. It's about auditing, and it's about reputation. Yes, my choice of word was sloppy, but as far as I'm concerned the fact that many if not most reverse records are automatically synthesised destroys their value for auditing, reputation and pretty much everything else. > > > already numerous reports of operational failures caused by mail > > exchangers and the like that expect them for IPv6. > > Too late. > You can not deliver email to any major provider over IPv6 without a valid > reverse name. I know, and that's exactly why it's already meaningless. > Should his affect ANIMA? I don't think so, but that boat has > sailed. Indeed. In the anima context, all I'm saying is that we shouldn't accidentally end up depending on it. > The problem with ULA-Random in an enterprise is that, when it escapes, it is > impossible to know who is using it for what. Well, that's also a feature, from a privacy PoV. Brian From nobody Sun Nov 30 15:07:53 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 3B2211A1AB8 for ; Sun, 30 Nov 2014 15:07:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFQQqHT-EutR for ; Sun, 30 Nov 2014 15:07:45 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B442D1A1AA7 for ; Sun, 30 Nov 2014 15:07:44 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 2AA7B20012; Sun, 30 Nov 2014 18:10:54 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 47643637F6; Sun, 30 Nov 2014 18:07:43 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 2DF6C63740; Sun, 30 Nov 2014 18:07:43 -0500 (EST) From: Michael Richardson To: Brian E Carpenter In-Reply-To: <547B6B1D.9090003@gmail.com> References: <29880.1416777310@sandelman.ca> <20141129012623.GA25550@cisco.com> <547A16A2.9030904@gmail.com> <26092.1417370244@sandelman.ca> <547B6B1D.9090003@gmail.com> 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/NblLbGSAYSnIHbbZ-SKwYLx-paY Cc: anima Subject: Re: [Anima] eckert-anima-stable-connectivity X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Nov 2014 23:07:49 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Brian E Carpenter wrote: >> >> On Sun, Nov 23, 2014 at 04:15:10PM -0500, Michael Richardson wrot= e: >> > ... >> >>> 2) reverse DNS is important for things like SSH connections, esp= ecially >> >>> with IPv6. >>=20 >> > I see this as a potential problem. It is widely felt that >> > reverse DNS is a bogus requirement, because tens of millions of >> > reverse DNS entries are automatically synthesised and therefore >> > meaningless as any kind of authentication. There are also >>=20 >> It was never about authentication, and the various detractors of rev= erse DNS >> do not listen very well. It's about auditing, and it's about reputa= tion. > Yes, my choice of word was sloppy, but as far as I'm concerned the fa= ct > that many if not most reverse records are automatically synthesised > destroys their value for auditing, reputation and pretty much everyth= ing > else. 1) they won't be synthesized in IPv6 :-) 2) synthesized records that say ip231.example.com may be WAY more useful (particularly if the forward is there too) because it points you at abuse@example.com, rather than the SWIP entry of abuse@example-com-paren= t-isp.com. Let me assure you that this is hugely valuable information to have in logs, and short cuts a great deal of investigation.=20=20=20 >> The problem with ULA-Random in an enterprise is that, when it escape= s, it is >> impossible to know who is using it for what. > Well, that's also a feature, from a privacy PoV. When you have traffic on *your* network with source addresses you can not identify, and therefore can not easily track it back to the faulty/misconfigured device, it is not a feature. It's an **attack** Dealing with this kind of attack is likely to cause one to deploy lots and lots of privacy violating devices inside the enterprise. I love privacy too (I will claim: more than you many people), but I do not think the upper 64-bits of an address can be private. Remember: the traffic isn't going anywhere: BCP38 filtering at some point will kill it outbound, and there can never be any inbound traffic responding.=20=20 A BCP38-related question about Anima Control Plane would be: what kind of filtering is appropriate. Consider two networks which merge... does one renumber?=20=20 I propose that we adopt some terminology from chemistry for our networks. Individual ANIMA entites are atoms... they can form bonds to other atoms to form molecules. Molecules may coalese to form bigger molecules. A molecule (can become)/is "grounded" (a RPL term) to a substrate (i.e. a NOC). We may have a use for the various kinds of bonds (covalent, ionic, hydrogen, van-der-Walls)... I would claim that molecules that spontaneously form should use ULA-R until such time as they become grounded, at which point they would adopt the numbering from the NOC (which I suggest should be NCN or ULA-C).=20=20 =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVHujPoCLcPvd0N1lAQLkrgf/U/QFl6l+vW3ocZk/aC9NzHhciFCif4RE xuCDPo8KnQzJGY8almquj2uuGBZJFWXSF/tRsgakej4GBj+8ah0rSL8oEVCvT/u2 7qo4wz7TPyaXd4BoP2G/4bc+pmHkJo17WU9A4A4iOpfHySeVArEZYam+6wUQgtod DRg2d9Tssy0/Lg2bY00uUMJsMYabp4WQAhCD69Z4qc39um+Q81dUm/2mw8iAFBQM /u91/LWKtLcXqy+yKuI89MsAFmrt6R/QsP+byJ2KixBk2rvuv4EqKn8Dxv0LexOy Joe/XUBzufq9Fuew8JXeW1hA19ASAxy1bU9rtTBYNoE5QseziEpIJw== =XxXV -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Nov 30 17:18: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 9017F1A008C for ; Sun, 30 Nov 2014 17:18:03 -0800 (PST) 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 Bm1j8y0bLux6 for ; Sun, 30 Nov 2014 17:18:01 -0800 (PST) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E1C51A008B for ; Sun, 30 Nov 2014 17:18:01 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id et14so9967515pad.31 for ; Sun, 30 Nov 2014 17:18:00 -0800 (PST) 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=BE0bSqGrjcuh8iBPQvsaVPoVLJkjRwXngTnteOLJvWY=; b=QUxIFslJihzM9/BtbSpU/Joo24Z0iuTER9+Zt/VkH2wplAPIew70su0doSeOH3P/o1 sfGYV0Z85kQTMvcyKfp6G293IsKqXNPFhbpuguDl5P3Ey3MNct0bw87cou1pUoGT6OoU /Ue9xH4A+eCzxlMoz8no1j/DrZKO2YNMctjBsMvcv7K2vdLl6xDhnhjhvfHhtHzuPS1G RmObXst8S1UtI30N4B7z/ZV0Q6htc8sn/vmPyu+xuoiW6Lqts6jja4nFOPxjVwtfdIEJ 66t3YKuzt8yW3b1Auo7ws7Qc65PWGP1RLIPfeXZhlDsnOFSErlckPi0XoAbtEWSr8GYi XYoA== X-Received: by 10.68.69.48 with SMTP id b16mr93404113pbu.59.1417396680406; Sun, 30 Nov 2014 17:18:00 -0800 (PST) Received: from [192.168.178.26] (16.197.69.111.dynamic.snap.net.nz. [111.69.197.16]) by mx.google.com with ESMTPSA id jp15sm15856754pbb.17.2014.11.30.17.17.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 30 Nov 2014 17:17:59 -0800 (PST) Message-ID: <547BC1C3.2010704@gmail.com> Date: Mon, 01 Dec 2014 14:17:55 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Michael Richardson References: <29880.1416777310@sandelman.ca> <20141129012623.GA25550@cisco.com> <547A16A2.9030904@gmail.com> <26092.1417370244@sandelman.ca> <547B6B1D.9090003@gmail.com> <25412.1417388863@sandelman.ca> In-Reply-To: <25412.1417388863@sandelman.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/anima/UNLWqIWmS330lNYUmELDTqWr-Jg Cc: anima Subject: Re: [Anima] eckert-anima-stable-connectivity 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, 01 Dec 2014 01:18:03 -0000 On 01/12/2014 12:07, Michael Richardson wrote: > Brian E Carpenter wrote: > >> >> On Sun, Nov 23, 2014 at 04:15:10PM -0500, Michael Richardson wrote: > >> > ... > >> >>> 2) reverse DNS is important for things like SSH connections, especially > >> >>> with IPv6. > >> > >> > I see this as a potential problem. It is widely felt that > >> > reverse DNS is a bogus requirement, because tens of millions of > >> > reverse DNS entries are automatically synthesised and therefore > >> > meaningless as any kind of authentication. There are also > >> > >> It was never about authentication, and the various detractors of reverse DNS > >> do not listen very well. It's about auditing, and it's about reputation. > > > Yes, my choice of word was sloppy, but as far as I'm concerned the fact > > that many if not most reverse records are automatically synthesised > > destroys their value for auditing, reputation and pretty much everything > > else. > > 1) they won't be synthesized in IPv6 :-) Right, and I certainly don't expect them to exist for an ACP. > > 2) synthesized records that say ip231.example.com may be WAY more useful > (particularly if the forward is there too) because it points you at > abuse@example.com, rather than the SWIP entry of abuse@example-com-parent-isp.com. > > Let me assure you that this is hugely valuable information to have in logs, > and short cuts a great deal of investigation. Yes, I can believe that. Peace, it's a side issue for anima. > > >> The problem with ULA-Random in an enterprise is that, when it escapes, it is > >> impossible to know who is using it for what. > > > Well, that's also a feature, from a privacy PoV. > > When you have traffic on *your* network with source addresses you can not > identify, and therefore can not easily track it back to the > faulty/misconfigured device, it is not a feature. It's an **attack** > Dealing with this kind of attack is likely to cause one to deploy lots and > lots of privacy violating devices inside the enterprise. I love privacy too > (I will claim: more than you many people), but I do not think the upper > 64-bits of an address can be private. Remember: the traffic isn't going > anywhere: BCP38 filtering at some point will kill it outbound, and there can > never be any inbound traffic responding. Exactly, and site egresses should stop it even before it hits any BCP38 filters. So I have never had any real level of concern about ULA leakage; I don't really see why it's going to happen more than say Net 10 leakage does today. > A BCP38-related question about Anima Control Plane would be: what kind of > filtering is appropriate. Consider two networks which merge... does one > renumber? Yes, both splits and merges are an issue. In the "professionally managed" networks that anima is scoped for, hopefully there will not be unplanned merges, but we do need to consider these issues. > I propose that we adopt some terminology from chemistry for our networks. > > Individual ANIMA entites are atoms... they can form bonds to other atoms to > form molecules. Molecules may coalese to form bigger molecules. > > A molecule (can become)/is "grounded" (a RPL term) to a substrate > (i.e. a NOC). We may have a use for the various kinds of bonds (covalent, > ionic, hydrogen, van-der-Walls)... I would claim that molecules that > spontaneously form should use ULA-R until such time as they become grounded, > at which point they would adopt the numbering from the NOC (which I suggest > should be NCN or ULA-C). But there's no such thing as ULA-C. Also, the way enterprise networks are extended is a bit different from IoT or homenets in this respect. I think the model needs to be flexible on what kind of prefix is used. I do agree with your implication that renumbering of the ACP needs to be regarded as a routine event (e.g., assume renumbering might happen after every significant outage and again after the outage is fixed). Node identities should matter a lot more than node addresses. Brian