From nobody Thu Oct 2 10:03:35 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7021A893C for ; Thu, 2 Oct 2014 10:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.036 X-Spam-Level: X-Spam-Status: No, score=-3.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786] 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 bYZRPwaVfcJL for ; Thu, 2 Oct 2014 10:03:29 -0700 (PDT) Received: from mx2.eict.de (mx2.eict.de [212.91.241.168]) by ietfa.amsl.com (Postfix) with ESMTP id 2753A1A8951 for ; Thu, 2 Oct 2014 10:03:29 -0700 (PDT) Received: by mx2.eict.de (Postfix, from userid 481) id 1FFED1FF63; Thu, 2 Oct 2014 19:03:26 +0200 (CEST) Received: from mail.eict.de (mx1 [172.16.6.1]) by mx2.eict.de (Postfix) with ESMTP id 9C9DC1FF5F; Thu, 2 Oct 2014 19:03:23 +0200 (CEST) Received: from sbs2008.eict.local (sbs2008.intern.eict.de [192.168.2.11]) by mail.eict.de (Postfix) with ESMTP id 3E7A8378246; Thu, 2 Oct 2014 19:03:23 +0200 (CEST) Received: from SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298]) by SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298%13]) with mapi; Thu, 2 Oct 2014 19:03:22 +0200 From: Kostas Pentikousis To: Brian E Carpenter , "nmrg@irtf.org" Date: Thu, 2 Oct 2014 19:03:21 +0200 Thread-Topic: [nmrg] Autonomic networking drafts - call for comments Thread-Index: Ac/Y8yWW2OcJsDBBQJWMYlBrSRLUwAFbpuWA Message-ID: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C72AFDB@SBS2008.eict.local> References: <54232BBD.2090107@gmail.com> In-Reply-To: <54232BBD.2090107@gmail.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/_KEKKC0Je1P_MLVlGgEWDllv-ZM Subject: Re: [nmrg] Autonomic networking drafts - call for comments X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 17:03:32 -0000 SGkgQnJpYW4sDQoNCkkgaGF2ZSBnb25lIHRocm91Z2ggdGhlIGRyYWZ0cyBhbmQgYWx0aG91Z2gg dGhlIHJlY2VudCB1cGRhdGVzIChpLmUuIGFmdGVyIHRoZSBsb25nIGRpc2N1c3Npb24gd2UgaGFk IGluIFRvcm9udG8pIGhhdmUgYmVlbiBpbiB0aGUgcmlnaHQgZGlyZWN0aW9uLCBJIGZlZWwgdGhh dCBtdWNoIGlzIGxlZnQgdG8gYmUgZGVzaXJlZC4NCg0KSW5zdGVhZCBvZiB3cml0aW5nIGEgbG9u ZyBlbWFpbCBvbiB0aGUgaXNzdWVzIEkgdG91Y2hlZCB1cG9uIGluIHRoZSBsYXN0IE5NUkcgbWVl dGluZywgSSB0b29rIHRoZSBsaWJlcnR5IHRvIHdyaXRlIHRoZSBmb2xsb3dpbmcgZHJhZnQgaHR0 cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1wZW50aWtvdXNpcy1ubXJnLWFuZHIv IGluIG9yZGVyIHRvIGNvbnRyaWJ1dGUgaW4gYSBjb25zdHJ1Y3RpdmUgbWFubmVyIHRvIHRoZSBv bmdvaW5nIGRpc2N1c3Npb24gaW4gTk1SRy4NCg0KSWYgZm9sa3MgYXJlIGludGVyZXN0ZWQgaW4g Y29udHJpYnV0aW5nIHRleHQgdG8gdGhpcyBkcmFmdCwgZmVlbCBmcmVlIHRvIGRyb3AgbWUgYSBs aW5lLg0KDQpCZXN0IHJlZ2FyZHMsDQoNCktvc3Rhcw0KDQoNCnwgLS0tLS1VcnNwcsO8bmdsaWNo ZSBOYWNocmljaHQtLS0tLQ0KfCBWb246IEJyaWFuIEUgQ2FycGVudGVyIFttYWlsdG86YnJpYW4u ZS5jYXJwZW50ZXJAZ21haWwuY29tXQ0KfCBHZXNlbmRldDogTWl0dHdvY2gsIDI0LiBTZXB0ZW1i ZXIgMjAxNCAyMjozOA0KfCBBbjogbm1yZ0BpcnRmLm9yZw0KfCBCZXRyZWZmOiBbbm1yZ10gQXV0 b25vbWljIG5ldHdvcmtpbmcgZHJhZnRzIC0gY2FsbCBmb3IgY29tbWVudHMNCnwgDQp8IEhpLA0K fCANCnwgVGhlIGF1dGhvcnMgb2YgZHJhZnQtaXJ0Zi1ubXJnLWF1dG9ub21pYy1uZXR3b3JrLWRl ZmluaXRpb25zLTAzDQp8IGFuZCBkcmFmdC1pcnRmLW5tcmctYW4tZ2FwLWFuYWx5c2lzLTAxIGhh dmUgcmVjZWl2ZWQgdmVyeSBkZXRhaWxlZA0KfCByZXZpZXdzIGJ5IFJlbiBTdHJ1aWsgb3ZlciBv biB0aGUgYW5pbWFAaWV0Zi5vcmcgbGlzdCwgYW5kIHdlIHdpbGwgc29vbg0KfCBwcm9kdWNlIG5l dyB2ZXJzaW9ucyBhY2NvcmRpbmdseS4gV2UnZCByZWFsbHkgbGlrZSB0byBnZXQgZmluYWwNCnwg Y29tbWVudHMgZnJvbSBhbGwgTk1SRyBwYXJ0aWNpcGFudHMgYXMgc29vbiBhcyBwb3NzaWJsZSAo bGlrZSB3aXRoaW4gYQ0KfCB3ZWVrISksIHNpbmNlIHdlIHdhbnQgdG8gbW92ZSB0aGVzZSBkcmFm dHMgZm9yd2FyZC4NCnwgDQp8IFRoYW5rcyBpbiBhZHZhbmNlLA0KfCANCnwgICAgQnJpYW4gQ2Fy cGVudGVyDQp8IA0KDQo= From nobody Thu Oct 2 11:54:19 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C5A1A1B5A for ; Thu, 2 Oct 2014 11:54:17 -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 f1ulUiN5P8sA for ; Thu, 2 Oct 2014 11:54:16 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2D541A1B14 for ; Thu, 2 Oct 2014 11:54:15 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id bj1so3264781pad.29 for ; Thu, 02 Oct 2014 11:54:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=acdKk4T3YMMNohrynYoCFk8brX0QYmWgayM7mQMKVCI=; b=L9uhHBdGoPwZWTqohkhYrM1T5c4Gp1fe1dDgZf5t+7jEdpNVbm9wdmQpuJrjXkelp7 ybt+oNZKAWV9+CqoiNeuSQQSGh1PcWH8tmrIGJ4CUpwSnCojNheFA3GuII5TuX/iwWvt Pq8CGRF43EFDw3XPwzqS8bZS2ZNz3NxrJxzwdK2NJpNsk41sUmsltW8OwwbvXzx7DIsT 7L4DmIZQOWYaw2JgwY3BGO83msFZECLgQLuAH21BQbr2dpUzjx0jlvltj7QZAa463PMl wJHszDhSQ+jvla15Z2r2ZXIzxrPS7No+/Bsfcddlz81c2JAcRAbmPXaztQBEYwnIojwa pLeQ== X-Received: by 10.68.233.197 with SMTP id ty5mr1230742pbc.22.1412276055316; Thu, 02 Oct 2014 11:54:15 -0700 (PDT) Received: from [192.168.178.23] (81.199.69.111.dynamic.snap.net.nz. [111.69.199.81]) by mx.google.com with ESMTPSA id qs4sm4395693pbb.90.2014.10.02.11.54.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Oct 2014 11:54:14 -0700 (PDT) Message-ID: <542D9F58.1010000@gmail.com> Date: Fri, 03 Oct 2014 07:54:16 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: nmrg@irtf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/OzOmp1DrcslFx2XelBcgIJIeluM Subject: [nmrg] [Fwd: I-D Action: draft-irtf-nmrg-an-gap-analysis-02.txt] X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 18:54:17 -0000 This update responds to all comments received recently. There are quite a lot of changes. Brian + co-authors -------- Original Message -------- Subject: I-D Action: draft-irtf-nmrg-an-gap-analysis-02.txt Date: Thu, 02 Oct 2014 11:51:26 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Management Research Group Working Group of the IETF. Title : Gap Analysis for Autonomic Networking Authors : Sheng Jiang Brian Carpenter Michael H. Behringer Filename : draft-irtf-nmrg-an-gap-analysis-02.txt Pages : 16 Date : 2014-10-02 Abstract: This document provides a problem statement and gap analysis for an IP-based autonomic network that is mainly based on distributed network devices. The document provides a background by reviewing the current status of autonomic aspects of IP networks and the extent to which current network management depends on centralisation and human administrators. Finally the document describes the general gaps between current network abilities and the ideal autonomic network concept. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-irtf-nmrg-an-gap-analysis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-irtf-nmrg-an-gap-analysis-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-irtf-nmrg-an-gap-analysis-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Fri Oct 3 06:48:54 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 687031A0311 for ; Fri, 3 Oct 2014 06:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.587 X-Spam-Level: X-Spam-Status: No, score=-12.587 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncePM44T3xp4 for ; Fri, 3 Oct 2014 06:48:50 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC0E11A1A95 for ; Fri, 3 Oct 2014 06:48:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22694; q=dns/txt; s=iport; t=1412344129; x=1413553729; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ovOraAU6chy3fzUn9PIUNuyAvlwuYSn96a6bLx/4prk=; b=QkcbINdgUZrXU58JUVsUe7DclHby9XRilh1Lg2SyhtnTODeNb38PYI8Z xa14qK/6XnQW/tRPRX4qTDFMxBcuE9a1z14xJIBxATQ/UJJ0lFKdNhCO7 ulzMhUZrSjL9i4rJpVeUv/UoLVbF6tw7lJFKozPwN2l2Wjn/UpiZ2Nnx1 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAFioLlStJV2c/2dsb2JhbABXCYMOgSsE0ksCgQoWAXuEAwEBAQMBGAIDHSsUBQcEAgEIDgMBAwEBCwsJCQcyFAMGCAIEAQ0FCIguCL8mAReKOIUbAycxBwYEgyOBHgWPWoIahn2FeoNCgyqJaIN/g2NsgQZCgQIBAQE X-IronPort-AV: E=Sophos;i="5.04,647,1406592000"; d="scan'208";a="360446533" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 03 Oct 2014 13:48:47 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s93DmlYr025947 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Oct 2014 13:48:47 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.204]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Fri, 3 Oct 2014 08:48:47 -0500 From: "Michael Behringer (mbehring)" To: Rene Struik , "anima@ietf.org" Thread-Topic: [Anima] review of draft-irtf-nmrg-autonomic-network-definitions-03 Thread-Index: AQHP0e9qhBeXD8S03Uq0EGQztbFMk5weKbzQ Date: Fri, 3 Oct 2014 13:48:46 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF21C5AD3E@xmb-rcd-x14.cisco.com> References: <5418A1BC.3070803@gmail.com> In-Reply-To: <5418A1BC.3070803@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/MMDCmyJCxfaUZq6oL1CVPggtEc0 Cc: "nmrg@irtf.org" Subject: Re: [nmrg] [Anima] review of draft-irtf-nmrg-autonomic-network-definitions-03 X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 13:48:52 -0000 Finally working on the next version of this document. Thanks for your detai= led review Rene, inline more... =20 > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Rene Struik > Sent: 16 September 2014 22:47 > To: anima@ietf.org > Subject: [Anima] review of draft-irtf-nmrg-autonomic-network-definitions- > 03 >=20 > Dear colleagues: >=20 > Please find below my initial comments on draft-irtf-nmrg-autonomic- > network-definitions-03. >=20 > 1. Summary: >=20 > The draft provides a loose introduction of some autonomic networking > notions and then lists some design goals and non-goals. >=20 > 2. General comments: >=20 > a) The title of the document is somewhat misleading, since the document i= s > mostly about goals and non-goals and less about definitions. I don't have a better title for now, and still think that the title should = mention both parts. > b) The goal of autonomic networking is described {Section 2} in terms of Section 2? That's just the definitions. "goals" points to section 3, but ac= tually, I think you're really referring to the intro? =20 > reversing the swing of a pendulum that previously swung into the directio= n > of replacing localized configuration and network management decision > criteria by centralized ones (by putting "intelligence" into network > management tools rather than devices themselves) into the counter-swing > of putting more intelligence in devices themselves. What is missing, > though, is a somewhat more balanced treatment of the topic: > after all, network design exercises have to deal with many trade-offs, wi= th > optimal choices not a priori cast in stone. As case in point, consider se= nsor > networks: here, energy savings and spotty connectivity favor localized > decisions, whereas configuration may benefit from a more holistic view of > the network (e.g., to manage time latency and energy cost, as with, e.g., > 6TiSCH, or to reduce the shear amount of traffic to communicate micro- > updates on state that may be flushed from a more centralized repository i= n > one protocol pass). I would strongly suggest giving this entire section m= ore > substance by bringing in various elements of network design consideration= s > besides configuration (e.g., audit/log functionality) and paying tribute = to > trade-offs in device capabilities, energy usage, time latencies, flexibil= ity, > security, ease of use, and the-like. Now, it reads like a "cutting the no= n- > localized cord" ode no matter what. This should also include some > discussion on whether localized decisions result in anything close to a > "global optimum", what the effect is if some local decisions are disturbe= d > (whether due to malicious act or otherwise), and whether convergence > actually can take place. {NOTE: I do realize that this is an internet dra= ft and > not an academic paper, but why not at least mention some of this??} Independently where this actually belongs, let me make a clarifying stateme= nt here: We are trying NOT to judge what is better. This is invariably goin= g to get into a religious war, which I really don't want to have, because i= t doesn't help.=20 But I see the point you're making - We shouldn't make it sound that complet= e decentralisation is the real goal, and I agree with that (and never meant= to imply that). Let me work in some verbiage to that regard. Bottom line o= f the argument is, as I see it:=20 - "autonomic" is for most networks NOT black and white - some functions are better centralised, some decentralised - the discussion on which function should follow which paradigm is out of s= cope for this doc.=20 - this doc describes the decentralised functions.=20 Does that cut it?=20 And, looking at where this discussion fits best, I think it should be part = of the "introduction" section. I added the following (plus some small edit= s along the way):=20 Some network deployments benefit from a fully autonomic approach, = for=20 example networks with a large number of relatively simple devices.=20 Most of currently deployed networks however will require a mixed appr= oach, where some functions are autonomic and others are centrally mangaged. Central management of networking functions clearly has advantages and will be chosen for many networking functions. This document does not= =20 discuss which functions should be centralised or follow an autonomic= =20 approach. Instead, it should help make the decision which is the best= =20 approach for a given situation. =20 > c) I would also describe some other factors that may have contributed > {Section 2} to complexity and non-flexibility, where lack of "separation = of > concern" (e.g., encoding addresses in a topology-aware fashion -- nice fo= r > semi-static networks, but a major headache for mobile networks, where > flexibility comes at a premium) may unfortunately have driven part of the > design activities in the past for whatever reason and where vested > economical interests may have favored centralized control points > (think: service providers, with centralized user authentication functiona= lity; > and with an interest in raising the entry bar for new network entrants, v= ia > these same control points). Hmmm... These are all good points, but I think this is mainly historical co= nsiderations, which may lead to more and more text being added, and I would= really like to keep this document as short as possible.=20 Can we leave out WHY certain decisions were made in the past, or do you rea= lly think this is a major part of the document?=20 > d) It should be made more clear that autonomic networking has limits, sin= ce > it cannot really deal well with device-specific functions, since "intent" > treats all devices within a network generically and similarly (e.g., in t= heir > role as routers or as "members of a domain"). This may have repercussions > when applying these notions to security architectural design that include= s > applications, since physical devices are often not generic, but display > tailored functions, without too much redundancy and replication. I think the new section above covers that, by not even trying to make auton= omics the "right" architecture in the future, but a part of a bigger scheme= . Again, yes, we could enter into more detail here, but I think the above p= aragraph might be clear enough? I think your main point is "AN isn't for ev= erything" - and I think we make that point now. > e) Some of the non-goals seem to be actually goals that one, for some > reason (politics, unions?) does not want to label as such. As an example,= the > objective clearly is to significantly reduce human involvement in network > management, for all but specialized functions=20 I can see how you can read it this way, and am thinking on how to fix that = perception. But we state clearly in the "goals" that " It is the design goa= l to make functions on network nodes self- managing, in other words, minima= lly dependent on management systems or controllers, as well as human operat= ors." (3.1). But it is NOT a design goals to ELIMINATE human operators.=20 I'll try to fix that perception, because it's clearly misleading (and thank= s for pointing this out!). I now start that section with "Section 3.1 state= s that "It is the design goal to [...] minimally dependent on [...] human o= perators". It is however not a design goal to completely eliminate them."=20 > (conflicting with Section 4.1, > but implied by the last sentence hereof > -- "more like doctors than hospital orderlies"), to reduce control by > management rather than "network management controls" (which are > completely different things altogether!) (Section 4.3),=20 We mean to say that even if a function is autonomic, you can still control = it (albeit by different means).=20 I rename the phrase in question to "Eliminate central control " - should be= clearer?=20 But again, I *do* think it is a non-goal to ELIMINATE central control. Do w= e agree?=20 I start this section now with " While it is a goal to simplify northbound i= nterfaces (, it is not a goal to eliminate c= entral control, but to allow it on a higher abstraction level." > to sanitize the > current complexities and thereby strive for elimination of configuration > tools (Section 4.4) and existing network management systems (Section 4.5)= . For sections 4.4 and 4.5 I actually agree with you! This is incorrect as li= sted here, and thanks for spotting this. For a given autonomic function (!)= the goal is indeed to eliminate complex config tools and NMS systems.=20 These 2 points really belong to the co-existence section, because since in = reality only some functions will be autonomic, traditional tools will still= be needed for the non-autonomic functions.=20 And I just re-read the co-existence section, and think it is sufficiently c= lear. I'll therefore just remove those two paragraphs.=20 Well spotted, thanks! :-)=20 > If the goal of the autonomic networking exercise is *not* to clean up the > current complexities, do things better, with ultimate goal of brushing so= me > of the current procedures/dead wood/ossified methods aside, why even > start this effort at all? Stating goals as non-goals is not credible. Mor= e to the > point would be that one takes into account "managed change", co-existence > of new systems with pre-existing ones, etc., but that is something that > applies to any development. A draft with goals should make a convincing > case, including convincing no loss of manageability and anomaly control, > and not pay lip service to all those who might be impacted by this > (moreover, this is a technical document, isn't it?). Let me know whether it's better now, and if you spot anything else that's i= ncoherent or misleading.=20 > 3. Specific comments >=20 > Section 1: > 1) First sentence (p. 2): "control loops" should read "control loop" Actually, the way I see it there isn't necessarily a single control loop. I= guess it depends how you define "control loop".=20 > 2) First sentence (pp. 2-3): remove the word autonomic (twice), which is > really overused here, without definition yet.=20 done.=20 > Moreover, the definition in > Section 2 is really strict, so most networks may not be labelled this way= . Yes, this is the result of some previous discussion, where some folks felt = strongly that an autonomic node can only be called that if it is fully self= -managed, with all self-CHOP features. The new version emphasises much more= the autonomic function. To me, that is way more relevant to the work at ha= nd.=20 Frankly we can re-open that debate, but I think the current set of definiti= ons is coherent and logical. You could come up with other coherent sets of = definitions. We just need to settle on one.=20 > 3) Forelast para (p. 3): define "as a well as northbound" (or, better, re= move > this topology-related notions and replace by "and with external processes= " > or the-like) Fixed.=20 > Section 2: > 4) The word "autonomic" is defined in terms of self*, which is not that > descriptive. Couldn't one describe this in terms of devices reaching > localized decisions, via observation (akin to the nervous system analogue= )? The self-* paradigm has been widely used in research and other autonomic ar= chitectures, and I suggest we use the same scheme here as elsewhere. Actual= ly, it is quite hard to define "autonomic" in a couple of sentences... Let'= s use existing definitions here.=20 > 5) The description of "intent" seems to preclude codifying device-specifi= c > functionality in, e.g., a device certificate or attribute certificate. (A= s > described in the draft, it seems to codify only "domain" policy attribute= s.) This is intentional. Well, the intent is network wide. Certificates can hav= e attributes. The two don't contradict each other.=20 > As an aside, codifying domains seems to require careful network planning > and coordination and knowing in advance which domain a node should > belong to. I wonder to what degree this limits flexibility of deployment = and > ease of use. This is a good question. Indeed, we need to keep our eyes open to this ques= tion in the future.=20 =20 > Section 3: > 6) First bullet (p. 6): With self-configuration, how does one distinguish= two > devices A and B or elevate one to be in control of the other?=20 You use a tie-breaker algorithm to decide. As in routing protocols. Worst c= ase "lowest IP wins". Many ways to do that. Should this be elaborated here?= Is that not too detailed?=20 > Shouldn't one > mention somewhere privacy aspects (what if a retail store "discovers" may > cell phone and now conveniently tracks this, since the cell phone has to > authenticate itself first?) I prefer to keep that one out of a "definitions and goals" draft.=20 > 7) Second bullet (p. 6): With self-healing, how does one recover from > anomalies that cannot easily be decided by majority rules (such as with > security)? There is some different page scheme between us... To me, page 6 doesn't hav= e a second bullet... Are you referring to page 4 (definition of self-healin= g). And, I don't understand that question... Can you expand please?=20 > 8) Third bullet (p. 7): With self-optimizing, shouldn't one add some verb= iage > as to local vs. global optimization and the potential impact of a local > disturbance of the system on state? (As to the latter, I can imagine ther= e to > be a few algorithms that lend themselves to easy convergence and failure > recovery, whereas with others, localized failure recovery is almost doome= d > to fail.) [yes, now I have it: your page scheme =3D mine+2 pages] So, yes, as with some of the previous points, we could go into more details= . I think we don't want to roll up all nuances of the approach in a definit= ions draft? Please let me know if you disagree...=20 > 9) First para Section 3.2: "forseeable" should read "foreseeable" Fixed, thanks!=20 > 10) First para Section 3.2: "fully autonomic nodes and network(s)" > (i.e., make the last word plural) Fixed. > 11) In Section 3.2, the priority order (where human decisions rule) shoul= d > not necessarily be a "design principle"; rather, it should be a potential > instantiation of a policy-setting. After all, management functionality sh= ould > consider a mix of local self-management functions, plus oversight (thereb= y, > keeping operational invariants), where different applications may call fo= r > different decision criteria prioritization and choices. (In fact, this is= alluded > to in the last para of Section 3.2, withe auto-pilot and nuclear plant > scenarios.) One may want to add some verbiage here as well to graceful > degradation and failure recovery. OK, you're right that strictly speaking the design goal is "coexistence" an= d questions on order of priorities are not really part of the goal. But thi= s question has been asked and should be address somewhere, and i don't see = a better place right now...=20 "more verbiage" - same comment as before :-) Yes, we could, but we were t= rying to keep this document short and limited to definitions and goals. I c= an be convinced I think, but I'm not convinced yet :-) =20 > 12) First para (p. 6): replace "trustworhty" by "reliable" ok. done. > 13) In Section 3.3, first para, one should omit the subsentence "using a > domain identity, for example a certificate issued by a domain certificate > authority". After all, there are multiple ways for a device to evidence g= roup > membership, besides issuing domain specific certs. As case in point, with > sensor networks such as w/HART, ZigBee, ISA SP100, network membership > is evidenced by the use of a group key and network access is arbitraged b= y a > network manager (who may coincide or coordinate with the originator of > the group key). This is why we use the term "for example". You're mentioning another exampl= e. Both are ok. :-)=20 > 14) In Section 3.3, first para, replace "common trust anchor" by "mutuall= y > respected trust anchor" (after all, it may be that two devices A and B ha= ve > certs issued by different CAs, but nevertheless A respect B's certificate > authority's CA and vice-versa). good point. Fixed! (you don't miss anything, do you?! :-)=20 > 15) In Section 3.3, 2nd para, while it is possible to have domain entitie= s, this > is not a priori necessary for autonomic networking: as already mentioned > above, if network access involves a network manager, it could simply > perform membership tests via a white list of devices (SubjectPublicKeyInf= o, > so to speak). Should one use domain identities, one should clearly > articulate how these should be issued, what preplanning and coordination > this requires and what the impact is on flexibility of deployment. This > should be compared with alternatives, such as the use of group keys in th= e > sensor network example above. As a final note, if one where to use domain > identities, these could also be realized via attribute certs, rather than > device certs. So. Again, we can go into 100 times more detail here, and all the options y= ou list are correct, and will probably be used somewhere. I think the purpo= se of this document is not to be complete, but to point out the fundamental= concepts really.=20 What we're trying to say is "a node must be able to authenticate another no= de". Now you're right, "domain identity" doesn't capture all of your exampl= es, and you may also not require always a "strong, cryptographically verifi= able" one. Can we still try to put this concept into a short paragraph?=20 I think this should be explained in a different doc. - Goes beyond the scop= e here.=20 > 16) In Section 3.4, I believe it has merit to replace the somewhat > positional/almost ideological language ("decentralization above all") by = the > more neutral statement that one aims to "improve the ability to cope with > changes". (This is also the language in the ACM 2006 survey paper by Dobs= on > et al). Ideologies are bad. Except if you create them yourself! :-)=20 I see your point. And it's politically a bit risky, I see that. At the same= time I think the phrase "de-centralisation and distribution are fundamenta= l to the concept." is actually a lot clearer to the reader than "improving = the ability to cope with changes".=20 In other words, here I think it's worth walking a fine line on political ac= ceptability, to the benefit of clarity. Thoughts?=20 > 17) In Section 3.4, 2nd para, one should add some verbiage to the effect = that > a central repository of information has also been in the interest of vest= ed > interests, since this has been about control and lock-in of users/custome= rs > as well. It is not clear to me why an autonomic network > *must* be able to use a centralized system in order to be deployable. > Isn't this just lip service to the vested interests? {I can very well ima= gine, > e.g., completely distributed wifi access, with local micropayment to pay = for > ongoing access, without need for any centralized system, except perhaps > for settling those micro-payments. This seems to indicate that the > autonomic approach could live in parallel of whatever central > repositories/control points might be operatioal right now.} I think we're trying to say "if operationally relevant data is kept central= ly, an AN system must be able to use it.". We're also saying that "it is po= ssible to distribute such databases and that should be considered". Actuall= y we're trying to NOT be dogmatic here, in practice a lot of information is= centralised, and we better work with it. Actually I use this to justify th= e above sentence. :-) =20 There is one change I can make that will "smoothen" the argument, I'll chan= ge the "must" to "should". But re-reading this section, I think it expresse= s exactly what we want to say?!=20 And frankly, I don't want to go into the reason WHY some data might be cent= ralised, and what the commercial consequences are. OK?=20 > 18) In Section 3.5, I would explicitly mention audit/log/monitoring and > failure recovery mechanisms, as well as, perhaps, aggregated functionalit= y > that is relevant when one zooms out (e.g., lease more capacity on backbon= e > if local network generates lots of traffic). Added. > 19) Section 3.6, last sentence of first para: I would argue that some of = these > details do matter, e.g., auto-address configuration, naming of entities, = etc. Can you expand? I'm not with you... > 20) Section 3.7, first para: I wonder how "autonomic network reporting" > provides functional trouble shooting? (Faulty components, anomaly > detection, dead link, etc.) Example: instead of getting 50 syslogs that all have a common root cause, a= ggregated reporting could provide a single message back to the operator "li= nk between x and y down." Keep in mind, this is in parallel with traditiona= l methods such as syslog for the time being.=20 > 21) Section 3.7, last para: replace "special algorithms" by "specific > algorithms" done. > 22) Section 3.7, last para: while I agree one should be cognoscent to not > create unnecessary messaging, I again have trouble to see how one could > build a reliable system if one purportedly does not care about detail. Wi= th > some systems, this may violate per-device requirements (e.g., specific > safety valve info does not come through). Good discussion, but not for a definitions doc, IMO.=20 > 23) Section 3.8, first para: replace "however, they" by "however, these" Done. > 24) Section 4, first para: replace "items which" by "items that" (also o= n > numerous other locations in the draft) Done here. Prefer a native English speaker to fix the others, not sure... > 25) Section 4.2, p. 9: replace "fault" by "error" Actually in the hardware context I think "fault" is more appropriate than "= error". Am I looking at the wrong sport?=20 THANKS for this very detailed review, with tons of good comments! I expect = to issue a new version later today. Michael =20 From nobody Fri Oct 3 07:41:46 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5589B1A00A3 for ; Fri, 3 Oct 2014 07:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 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.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksfTgAHOvVWO for ; Fri, 3 Oct 2014 07:41:43 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8670A1A008D for ; Fri, 3 Oct 2014 07:41:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3294; q=dns/txt; s=iport; t=1412347303; x=1413556903; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CEZUX/wHQjCodzuiKqXM48rvGIFpKw1Ld2ZWIK5PnGg=; b=JXL3rPwiVjPTYpU61xieQCTtAGuX4h4bMBo7d9uhuTBvrBBe5QIUKslM J1Fjl6Co7XEUI94F/BwhTRKU7LTu4UQ/cVNWAqA4DWT2VGE0z/o2vOx88 PRheP15atsvH/CgTcct1FZnUCMLCzguh1qjBGo250ZkSgBadgXZmukcTA g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FABW1LlStJA2I/2dsb2JhbABggw5TUwUEgn7IAYdNAhlxFgF7hAMBAQEEIxFDAgwEAgEIEQQBAQMCBh0DAgICMBQBBgEBBQMCBAENBQgBiDUIBakvlXoBF4EsjlExBwaCcTaBHgWRdIQ8iDs7gweREYFoOIFDbIFIgQIBAQE X-IronPort-AV: E=Sophos;i="5.04,647,1406592000"; d="scan'208";a="360520969" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-4.cisco.com with ESMTP; 03 Oct 2014 14:41:42 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s93EfgVW023779 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Oct 2014 14:41:42 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.204]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Fri, 3 Oct 2014 09:41:42 -0500 From: "Michael Behringer (mbehring)" To: "nmrg@irtf.org" , Lisandro Zambenedetti Granville Thread-Topic: New Version Notification for draft-irtf-nmrg-autonomic-network-definitions-04.txt Thread-Index: AQHP3xfHrHkNUVWcNUu3wYSukDOVUJwecZ1g Date: Fri, 3 Oct 2014 14:41:42 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF21C5AFB7@xmb-rcd-x14.cisco.com> References: <20141003143855.18824.51976.idtracker@ietfa.amsl.com> In-Reply-To: <20141003143855.18824.51976.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.138] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/0gK37p6RLB_fzoPS2V6Mvz9DK5g Cc: "anima@ietf.org" Subject: [nmrg] FW: New Version Notification for draft-irtf-nmrg-autonomic-network-definitions-04.txt X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 14:41:45 -0000 VGhpcyB2ZXJzaW9uIGFkZHJlc3NlcyB0aGUgKGV4dGVuc2l2ZSkgY29tbWVudHMgYnkgUmVuZSBT dHJ1aWssIGFkZHMgdGhlIGRlZmluaXRpb24gb2YgImF1dG9tYXRpYyIgZnJvbSB0aGUgZ2FwIGFu YWx5c2lzIGRyYWZ0LCBhbmQgaGFzIGEgZmV3IGVkaXRvcmlhbCBmaXhlcy4gV2UgYmVsaWV2ZSB0 aGlzIHZlcnNpb24gaXMgcmVhZHkgZm9yIGxhc3QgY2FsbC4gDQoNCk1pY2hhZWwgKG9uIGJlaGFs ZiBvZiB0aGUgYXV0aG9yIHRlYW0pDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmddDQo+IFNlbnQ6IDAzIE9jdG9iZXIgMjAxNCAxNjozOQ0KPiBUbzogTGF1cmVudCBD aWF2YWdsaWE7IE1heCBQcml0aWtpbiAocHJpdGlraW4pOyBMYXVyZW50IENpYXZhZ2xpYTsgQWxl eGFuZGVyDQo+IENsZW1tIChhbGV4KTsgQnJpYW4gRS4gQ2FycGVudGVyOyBTaGVuZyBKaWFuZzsg U3RlaW50aG9yIEJqYXJuYXNvbg0KPiAoc2JqYXJuYXMpOyBNaWNoYWVsIEJlaHJpbmdlciAobWJl aHJpbmcpOyBNYXggUHJpdGlraW4gKHByaXRpa2luKTsgU3RlaW50aG9yDQo+IEJqYXJuYXNvbiAo c2JqYXJuYXMpOyBNaWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpOyBCcmlhbiBDYXJwZW50ZXI7 DQo+IEFsZXhhbmRlciBDbGVtbSAoYWxleCk7IFNoZW5nIEppYW5nDQo+IFN1YmplY3Q6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaXJ0Zi1ubXJnLWF1dG9ub21pYy1uZXR3b3Jr LQ0KPiBkZWZpbml0aW9ucy0wNC50eHQNCj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwg ZHJhZnQtaXJ0Zi1ubXJnLWF1dG9ub21pYy1uZXR3b3JrLWRlZmluaXRpb25zLTA0LnR4dA0KPiBo YXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IE1pY2hhZWwgQmVocmluZ2VyIGFuZCBw b3N0ZWQgdG8gdGhlDQo+IElFVEYgcmVwb3NpdG9yeS4NCj4gDQo+IE5hbWU6CQlkcmFmdC1pcnRm LW5tcmctYXV0b25vbWljLW5ldHdvcmstZGVmaW5pdGlvbnMNCj4gUmV2aXNpb246CTA0DQo+IFRp dGxlOgkJQXV0b25vbWljIE5ldHdvcmtpbmcgLSBEZWZpbml0aW9ucyBhbmQgRGVzaWduIEdvYWxz DQo+IERvY3VtZW50IGRhdGU6CTIwMTQtMTAtMDMNCj4gR3JvdXA6CQlubXJnDQo+IFBhZ2VzOgkJ MTUNCj4gVVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LWlydGYtbm1yZy1hdXRvbm9taWMtDQo+IG5ldHdvcmstZGVmaW5pdGlvbnMtMDQudHh0 DQo+IFN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pcnRmLW5tcmctYXV0b25vbWljLQ0KPiBuZXR3b3JrLWRlZmluaXRpb25zLw0KPiBIdG1saXpl ZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaXJ0Zi1ubXJnLWF1dG9u b21pYy1uZXR3b3JrLQ0KPiBkZWZpbml0aW9ucy0wNA0KPiBEaWZmOiAgICAgICAgICAgaHR0cDov L3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaXJ0Zi1ubXJnLWF1dG9ub21pYy0NCj4g bmV0d29yay1kZWZpbml0aW9ucy0wNA0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgIEF1dG9ub21pYyBz eXN0ZW1zIHdlcmUgZmlyc3QgZGVzY3JpYmVkIGluIDIwMDEuICBUaGUgZnVuZGFtZW50YWwgZ29h bA0KPiAgICBpcyBzZWxmLW1hbmFnZW1lbnQsIGluY2x1ZGluZyBzZWxmLWNvbmZpZ3VyYXRpb24s IHNlbGYtb3B0aW1pemF0aW9uLA0KPiAgICBzZWxmLWhlYWxpbmcgYW5kIHNlbGYtcHJvdGVjdGlv bi4NCj4gDQo+ICAgIFRoaXMgZG9jdW1lbnQgYXBwbGllcyB0aGUgY29uY2VwdHMgb2YgYXV0b25v bWljIHN5c3RlbXMgdG8gYSBuZXR3b3JrLA0KPiAgICBhbmQgZGVzY3JpYmVzIHRoZSBkZWZpbml0 aW9ucyBhbmQgZGVzaWduIGdvYWxzIG9mIEF1dG9ub21pYw0KPiAgICBOZXR3b3JraW5nLiAgVGhl IGhpZ2gtbGV2ZWwgZ29hbCBmb3IgYW4gYXV0b25vbWljIGZ1bmN0aW9uIGlzIHRvIGhhdmUNCj4g ICAgbWluaW1hbCBkZXBlbmRlbmNpZXMgb24gaHVtYW4gYWRtaW5pc3RyYXRvcnMgb3IgY2VudHJh bGl6ZWQNCj4gICAgbWFuYWdlbWVudCBzeXN0ZW1zLiAgVGhpcyB1c3VhbGx5IGltcGxpZXMgZGlz dHJpYnV0aW9uIGFjcm9zcyBuZXR3b3JrDQo+ICAgIGVsZW1lbnRzLg0KPiANCj4gDQo+IA0KPiAN Cj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20g dGhlIHRpbWUgb2YNCj4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQg ZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiANCj4gVGhlIElFVEYgU2Vj cmV0YXJpYXQNCg0K From nobody Sun Oct 12 12:19:21 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0411A6F61 for ; Fri, 10 Oct 2014 09:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNY-fexQYrqL for ; Fri, 10 Oct 2014 09:20:20 -0700 (PDT) Received: from out27-ams.mf.surf.net (out27-ams.mf.surf.net [145.0.1.27]) (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 859F01A893C for ; Fri, 10 Oct 2014 09:16:48 -0700 (PDT) Received: from smtps.utwente.nl (smtp-o1.utsp.utwente.nl [130.89.2.9]) by outgoing1-ams.mf.surf.net (8.14.4/8.14.4/Debian-4) with ESMTP id s9AGH0nn029698 for ; Fri, 10 Oct 2014 18:17:00 +0200 Received: from [10.87.2.156] ([145.15.244.20]) by smtps.utwente.nl (8.13.8) with ESMTP id s9AGGfGN000595 for ; Fri, 10 Oct 2014 18:16:45 +0200 From: Rick Hofstede Content-Type: multipart/alternative; boundary="Apple-Mail=_FA96F69A-3215-4DD9-A204-0690D7FAE7FE" Message-Id: <072CB38B-276F-4BC7-8B51-E5ADDA47FD1A@utwente.nl> Date: Fri, 10 Oct 2014 18:16:18 +0200 To: nmrg@irtf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Bayes-Prob: 0.9999 (Score 4.7, tokens from: utwente-out:default, base:default, @@RPTN) X-CanIt-Geo: ip=130.89.2.9; country=NL; region=Provincie Overijssel; city=Enschede; latitude=52.2195; longitude=6.8912; http://maps.google.com/maps?q=52.2195,6.8912&z=6 X-CanItPRO-Stream: utwente-out:default (inherits from utwente:default, base:default) X-Canit-Stats-ID: 0uN1sh0mh - 09dacbd43837 - 20141010 X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/PuC2r2wm6GyspaM0hKdyH4arex0 X-Mailman-Approved-At: Sun, 12 Oct 2014 12:19:16 -0700 Subject: [nmrg] =?windows-1252?q?CfP_-_Special_Issue_of_the_International_?= =?windows-1252?q?Journal_on_Network_Management_=28IJNM=29=3A_=22Measure?= =?windows-1252?q?=2C_Detect_and_Mitigate_=96_Challenges_and_Trends_in_Net?= =?windows-1252?q?work_Security=22?= X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 16:20:27 -0000 --Apple-Mail=_FA96F69A-3215-4DD9-A204-0690D7FAE7FE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 [Apologies for receiving multiple copies] A PDF version of this call can be downloaded at: http://wwwhome.cs.utwente.nl/~sperottoa/cfp_ijnm_network_security.pdf CALL FOR PAPERS Special Issue of the International Journal on Network Management (IJNM): = =20 "Measure, Detect and Mitigate =96 Challenges and Trends in Network = Security" Submission Deadline: December 1, 2014 Publication: September, 2015 Scope of the Special Issue Cybercrime has developed rapidly within the last decade and in particular the last years have seen an unprecedented amount of attacks. Despite increased national as well as international effort against cybercrime and the global financial crisis, cybercrime still has double-digit annual growth rates. On the one hand, more and more services and systems migrate to the Internet and cloud storage systems. On the other hand, the commercial success of the Internet and the possibilities to carry out attacks from a relatively safe distance attracts criminals and made e-Crime to a multi-billion dollar market. In addition, recent trends have highlighted that not only end-hosts are the target of attacks, but also the Internet infrastructure itself, with attacks aiming at impeding the functioning of e.g., the Domain Name System (DNS) or Internet backbones.=20 The dramatic trends in attack evolution call upon innovative solutions. Nowadays, detection and mitigation of network attacks are more than ever a must. However, current solutions need to evolve fast in order to cope with new attack scenarios. The goal of this Special Issue is twofold. We encourage, on the one hand, contributions characterizing and measuring emerging network threats; on the other hand we welcome submissions presenting cutting-edge detection and mitigation techniques effective against network attacks and insider activities in today and future small-to-enterprise sized networks and in backbones. Areas of Interest Contributions in the following areas are of specific interest, but not limited to: * Identification and Classification of Attacks * Network Measurements to Understand Cyber-criminal activities * Network Attacks Characterization * Multi-Layer Network Detection * Inter-Domain and Cooperative Detection and Mitigation * Detection in Encrypted Networks * Supervised/Unsupervised Network Detection * Alert and Event Correlation * Visualization of Network Attacks and Alerts * Interaction of Detection Systems and Exchange Formats * Future Trends in Network Detection and Mitigation * Mitigation of Large-Scale Distributed Attacks * Novel Network Measurements and Data Analyses of Internet Malware Submission Guidelines Authors should submit their papers in PDF format only to http://mc.manuscriptcentral.com/nem =20 Paper submissions should not exceed 20 pages (double-space). Author = instructions are available at = http://onlinelibrary.wiley.com/journal/10.1002/(ISSN)1099-1190/homepage/Fo= rAuthors.html and the respective LaTeX template can be found at = http://onlinelibrary.wiley.com/journal/10.1002/(ISSN)1099-1190/homepage/la= tex_class_file.htm Important Deadlines Submission Deadline: December 1, 2014 =20 Notification of Acceptance:March 1, 2015 =20 Final Version: June 15, 2015 =20 Publication: September 1,2015 Submissions to http://mc.manuscriptcentral.com/nem in PDF only. Guest Editors Gabi Dreo Rodosek - Universit=E4t der Bundeswehr Munich, Germany = =20 Anna Sperotto - University of Twente, The Netherlands = =20 Corinna Schmitt - University of Zurich, Switzerland = =20 Rick Hofstede - University of Twente, The Netherlands = =20 Alberto Dainotti - CAIDA, University of California,San Diego, USA = = --Apple-Mail=_FA96F69A-3215-4DD9-A204-0690D7FAE7FE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 [Apologies for receiving multiple copies]

A =    PDF   version   of =    this   call    can =   be    downloaded   at:
http://wwwhome.cs.utwente.nl/~sperottoa/cfp_ijnm_network_security.pdf=

CALL FOR PAPERS

Special Issue of the International = Journal on Network Management (IJNM):  
"Measure, Detect and = Mitigate =96 Challenges and Trends in Network = Security"

Submission Deadline: December 1, 2014 Publication: = September, 2015

Scope of the Special Issue

Cybercrime =  has  developed  rapidly  within  the last =  decade  and  in
particular  the  last =  years  have  seen an  unprecedented  amount =  of
attacks. Despite  increased national  as well as =  international effort
against cybercrime  and the global = financial  crisis, cybercrime still
has double-digit annual =  growth rates. On the one  hand, more and more
services =  and  systems  migrate  to  the Internet =  and  cloud  storage
systems. On the other hand, the = commercial success of the Internet and
the possibilities to carry out = attacks from a relatively safe distance
attracts criminals and made =  e-Crime to a multi-billion dollar market.
In addition, =  recent trends have  highlighted that not  only = end-hosts
are  the  target of  attacks,  but =  also  the Internet  infrastructure
itself, with = attacks  aiming at impeding the functioning  of e.g., = the
Domain Name System (DNS) or Internet backbones. 

The =  dramatic   trends  in  attack  evolution =   call  upon  innovative
solutions. Nowadays, =  detection and mitigation of  network attacks are
more than = ever a must.  However, current solutions need to evolve fast
in = order to  cope with new attack scenarios. The  goal of this = Special
Issue  is  twofold.  We  encourage, =  on the  one  hand,  contributions
characterizing = and  measuring emerging  network threats; on  the = other
hand  we  welcome submissions  presenting =  cutting-edge detection  and
mitigation  techniques = effective against  network attacks  and insider
activities = in today and  future small-to-enterprise sized networks and
in = backbones.

Areas of Interest

Contributions in the = following areas are of specific interest, but not
limited to:
* = Identification and Classification of Attacks
* Network Measurements = to Understand Cyber-criminal activities
* Network Attacks = Characterization
* Multi-Layer Network Detection
* Inter-Domain = and Cooperative Detection and Mitigation
* Detection in Encrypted = Networks
* Supervised/Unsupervised Network Detection
* Alert and = Event Correlation
* Visualization of Network Attacks and Alerts
* = Interaction of Detection Systems and Exchange Formats
* Future Trends = in Network Detection and Mitigation
* Mitigation of Large-Scale = Distributed Attacks
* Novel Network Measurements and Data Analyses of = Internet Malware

Submission Guidelines

Authors =   should  submit   their  papers =   in  PDF   format   only =  to
http://mc.manuscriptcentral.c= om/nem   

Paper  submissions =   should  not exceed 20  pages (double-space). = Author instructions  are available at
http://onlinelibrary.wiley.com/journal/10.1002/(ISS= N)1099-1190/homepage/ForAuthors.html
and    the =   respective    LaTeX =    template   can    be =   found    at
http://onlinelibrary.wiley.com/journal/10.1002= /(ISSN)1099-1190/homepage/latex_class_file.htm

Important = Deadlines

Submission  Deadline:  December 1,  2014 =  
Notification of  Acceptance:March 1, 2015  
Final = Version: June 15, 2015  
Publication: September = 1,2015

Submissions to http://mc.manuscriptcentral.c= om/nem in PDF only.

Guest Editors

Gabi  Dreo =  Rodosek  -  Universit=E4t  der  Bundeswehr =  Munich,  Germany <gabi.dreo@unibw.de> =  
Anna  Sperotto   -  University  of =  Twente,  The Netherlands  <a.sperotto@utwente.nl> <= br>Corinna  Schmitt -  University of Zurich, Switzerland = <schmitt@ifi.uzh.ch> 
Ric= k Hofstede - University of Twente, The  Netherlands <r.j.hofstede@utwente.nl>&nb= sp;
Alberto  Dainotti - CAIDA, University of California,San = Diego, USA <alberto@caida.org>= --Apple-Mail=_FA96F69A-3215-4DD9-A204-0690D7FAE7FE-- From nobody Mon Oct 13 07:07:36 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5E4A1ACCE4 for ; Mon, 13 Oct 2014 07:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.088 X-Spam-Level: X-Spam-Status: No, score=-7.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, 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 7aBsoHCNx791 for ; Mon, 13 Oct 2014 07:07:20 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C61021A1AB5 for ; Mon, 13 Oct 2014 07:07:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,711,1406617200"; d="scan'208";a="160568212" Received: from hioexcmbx08-prd.hq.netapp.com ([10.122.105.41]) by mx11-out.netapp.com with ESMTP; 13 Oct 2014 07:07:20 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 13 Oct 2014 07:07:18 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::9047:8c6c:1d6e:4581%21]) with mapi id 15.00.0995.031; Mon, 13 Oct 2014 07:07:18 -0700 From: "Eggert, Lars" To: "nmrg@irtf.org" Thread-Topic: [IRTF-Announce] Applied Networking Research Prize 2014 presentation s at IETF-91 Thread-Index: AQHP5u7/SZoy0UvMlE27q8714T6n6w== Date: Mon, 13 Oct 2014 14:07:17 +0000 Message-ID: <476F7D76-3BAE-4392-847D-13BA45AAAA75@netapp.com> References: <4705B28C-7F64-4D05-8D3A-791B9A2D7B24@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <260126307E29094CAA04CF556D95FFA2@hq.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/INOPJgKCkpAiR6dODa_uep72sd8 Subject: [nmrg] Fwd: [IRTF-Announce] Applied Networking Research Prize 2014 presentation s at IETF-91 X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 14:07:28 -0000 Misbah's talk is likely of interest to NMRG folks Begin forwarded message: > From: "Eggert, Lars" > Subject: [IRTF-Announce] Applied Networking Research Prize 2014 presentat= ion s at IETF-91 > Date: October 13, 2014 at 16:00:55 GMT+2 > To: "irtf-announce@irtf.org" > Cc: "irtf-discuss@irtf.org" , "ietf@ietf.org Maili= ng List" > Reply-To: "anrp@irtf.org" >=20 > ********************************************************************** > The call for ANRP nominations for the 2015 awards cycle is now > open! Read more about the ANRP at http://irtf.org/anrp. >=20 > DEADLINE IS OCTOBER 31, 2014 > ********************************************************************** >=20 > Hi, >=20 > we are extremely pleased to report that for the 2014 award period > of the Applied Networking Research Prize (ANRP), 46 eligible > nominations were received. Each submission was reviewed by four > members of the selection committee according to a diverse set of > criteria, including scientific excellence and substance, timeliness, > relevance, and potential impact on the Internet. >=20 > Based on this review, six submissions were awarded an Applied > Networking Research Prize for 2014. The final three prize winners > for 2014 will present their work at IETF-91 in Honolulu, HI, USA. > The ANRP awards for IETF-91 go to: >=20 > *** Sharon Goldberg *** for discussing threats when BGP RPKI > authorities are faulty, misconfigured, compromised, or compelled > to misbehave: >=20 > Danny Cooper, Ethan Heilman, Kyle Brogle, Leonid Reyzin and > Sharon Goldberg. On the Risk of Misbehaving RPKI Authorities. > Proc. ACM Workshop on Hot Topics in Networks (HotNets-XII), > College Park, MD, USA, November 2013. >=20 > *** Tobias Flach *** for the design of novel loss recovery mechanisms > for TCP that minimize timeout-driven recovery: >=20 > Tobias Flach, Nandita Dukkipati, Andreas Terzis, Barath > Raghavan, Neal Cardwell, Yuchung Cheng, Ankur Jain, Shuai Hao, > Ethan Katz-Bassett, Ramesh Govindan. Reducing Web Latency: the > Virtue of Gentle Aggression. Proc. ACM SIGCOMM, Hong Kong, China, > August 2013. >=20 > *** Misbah Uddin *** for developing matching and ranking for > network search queries to make operational data available in > real-time to management applications: >=20 > Misbah Uddin, Rolf Stadler and Alexander Clemm. Scalable > Matching and Ranking for Network Search. Proc. International > Conference on Network and Service Management (CNSM), Z=FCrich, > Switzerland, October 2013. >=20 > Sharon, Tobias and Misbah have been invited to present his findings in > the IRTF Open Meeting during IETF-91 in Honolulu, HI, USA. Join > them there! >=20 > Please subscribe to the IRTF-Announce mailing list in order to receive > future calls for ANRP nominations and join ISOC to stay informed of > other networking research initiatives: >=20 > http://irtf.org/mailman/listinfo/irtf-announce > http://isoc.org/join >=20 > Regards, >=20 > Lars Eggert, IRTF Chair http://irtf.org/anrp > Mat Ford, Internet Society http://isoc.org/research >=20 > -- >=20 > 2014 ANRP Selection Committee >=20 > Mark Allman, ICIR > Marcelo Bagnulo, UC3M > Lou Berger, LabN > Olivier Bonaventure, UCL Louvain > Ross Callon, Juniper > KC Claffy, CAIDA > Lars Eggert, NetApp > Stephen Farrell, Trinity College Dublin > Olivier Festor, INRIA > Mat Ford, ISOC > Lisandro Granville, UFRGS > Volker Hilt, Bell Labs > Suresh Krishnan, Ericsson > Dan Massey, Colorado State > Al Morton, AT&T Laboratories > J=F6rg Ott, Aalto University > Colin Perkins, University of Glasgow > Stefano Previdi, Cisco > J=FCrgen Sch=F6nw=E4lder, Jacobs University Bremen > Joe Touch, USC/ISI > Rolf Winter, Hochschule Augsburg > Yang Richard Yang, Yale > Lixia Zhang, UCLA >=20 From nobody Mon Oct 13 09:07:44 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 370A81A1A7A for ; Mon, 13 Oct 2014 09:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786, 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 LftYpEC3UIKI for ; Mon, 13 Oct 2014 09:06:52 -0700 (PDT) Received: from delivery2.ufrgs.br (delivery2.ufrgs.br [143.54.2.212]) by ietfa.amsl.com (Postfix) with ESMTP id B2D421A0394 for ; Mon, 13 Oct 2014 09:06:51 -0700 (PDT) Received: from delivery2.ufrgs.br (localhost [127.0.0.1]) by delivery2.ufrgs.br (Postfix) with ESMTP id B781720A3D3 for ; Mon, 13 Oct 2014 13:06:49 -0300 (BRT) Received: from msa2.ufrgs.br (msa2.ufrgs.br [143.54.2.209]) by delivery2.ufrgs.br (Postfix) with ESMTP id ED6543007BD for ; Mon, 13 Oct 2014 13:06:48 -0300 (BRT) From: Lisandro Zambenedetti Granville Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 13 Oct 2014 09:06:43 -0700 To: nmrg@irtf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/N2_VDyHanmTiTEb66PKO5C-7DWk Subject: [nmrg] Last Call X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 16:06:54 -0000 Dear NMRG This message is to start a two week last call (LC) on the following NMRG = documents on autonomics in network management: . draft-irtf-nmrg-an-gap-analysis-02.txt https://datatracker.ietf.org/doc/draft-irtf-nmrg-an-gap-analysis/ . draft-irtf-nmrg-autonomic-network-definitions-04.txt = http://datatracker.ietf.org/doc/draft-irtf-nmrg-autonomic-network-definiti= ons/ Please review the documents and provide your feedback in this two week = window. This last calls ends in Oct. 27th. Lisandro and Olivier From nobody Thu Oct 23 08:17:34 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC6DE1AC3D0 for ; Thu, 23 Oct 2014 08:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.339 X-Spam-Level: ** X-Spam-Status: No, score=2.339 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, RCVD_IN_DNSWL_LOW=-0.7, 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 nfRzHEdCCNKP for ; Thu, 23 Oct 2014 08:17:29 -0700 (PDT) Received: from delivery1.ufrgs.br (delivery1.ufrgs.br [143.54.2.211]) by ietfa.amsl.com (Postfix) with ESMTP id A500F1AC3C7 for ; Thu, 23 Oct 2014 08:17:28 -0700 (PDT) Received: from delivery1.ufrgs.br (localhost [127.0.0.1]) by delivery1.ufrgs.br (Postfix) with ESMTP id 65A533007CE for ; Thu, 23 Oct 2014 13:17:25 -0200 (BRST) Received: from msa1.ufrgs.br (msa1.ufrgs.br [143.54.2.208]) by delivery1.ufrgs.br (Postfix) with ESMTP id B807B3D70E for ; Thu, 23 Oct 2014 13:17:25 -0200 (BRST) From: Lisandro Zambenedetti Granville Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 23 Oct 2014 17:17:13 +0200 To: nmrg@irtf.org Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) X-Mailer: Apple Mail (2.1990.1) X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/RlpcXsVLaLFai2qvcAcTPZcgS8s Subject: [nmrg] Planning the next NMRG meetings for 2015 X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 15:17:31 -0000 Dear NMRG subscribers Back in 2011, we run a poll on this list to collect your feedback in = regard to topics that NMRG could focus on. At that point, the use of = autonomic computing for network management revealed to be an often = mentioned topic. =46rom that point and on, we organized some meetings on = autonomics for management that ultimately resulted in some I-D = proposals, a BoF in the last IETF meeting, and the ANIMA initiative. We=E2=80=99ve also been running a series of successful workshops =E2=80=9C= on the usages of NetFlow/IPFIX in Network management=E2=80=9D, the last = one being held in Berlim during IETF 87. A next workshop is planned for = the NMRG meeting in the upcoming IETF 93 in Prague. Some other = topic-specific meetings have been also organized, such as =E2=80=9Clossy = and low power networks management=E2=80=9D (27th NMRG meeting during = IETF 81 in Quebec), "Management Aspects of Emerging Networking = Paradigms=E2=80=9D (29th NMRG meeting during IETF 86 in Orlando), and = the =E2=80=9C1st Workshop on Large Scale Network Measurements=E2=80=9D = (31st NMRG meeting during CNSM 2013 in Zurich). In order to bring more transparency and planning for the upcoming = meeting in 2015 (thanks Juergen Schoenwaelder for comments on this = regard in the list), we would like to share with you our initial = thoughts, re-run the poll we mentioned in the beginning of this message, = and collect your feedback for the NMRG next steps. We would like to = organize in 2015 four NMRG meeting: 3 meetings during IETFs, in addition = to an interim meeting together with IM or CNSM 2015, if the conference = calendar allows that. As such, the upcoming meetings would be, in = principle: NMRG meeting during IETF 92, Dallas, Mar. 2015 - Topic: TBD NMRG meeting during IETF 93, Prague, Jul. 2015 - Topic: Together with the Flamingo FP7 project, we scheduled another = edition of the flow-based measurement workshop. Since the last workshop = in this series happened in Berlim Aug. 2013, we believe Jul. 2015 would = be a good moment for another issue. NMRG meeting during IETF 94, Yokohama, Nov. 2015 - Topic: TBD NMRG (interim) meeting, occasionally together with IM 2015 (May 2015, = Ottawa) or CNSM 2015 (possibly Oct./Nov. 2015, TBD) - Topic: TBD NMRG meetings don=E2=80=99t need to have specific topics. The 35th = meeting in Rio will not be centered on a single topic (call for = contributions will be distributed in the next message). Still, having a = set of main topics would certainly guide better the work developed under = the NMRG belt. As mentioned above, we would like to hear the feedback of = NMRG subscribers on topics that you believe should be addressed. As a = reference and starting point for another poll, please observe below the = list of topics (arbitrary order) considered back in 2011. a) Management of the Internet of Things b) Autonomics management / network learning c) Network-wide safe configuration d) Energy monitoring and management e) Network flow measurement and analysis f) Large-scale network-wide measurements g) Management of virtual machines and clouds Considering the above, we would like to ask you the following questions: 1) For the interim meeting, what seems more adequate for your personal = calendar, i.e., IM or CNSM? We=E2=80=99ll try to accommodate the 2015 = interim meeting in a moment that more people could potentially attend. 2) Would you include additional topics to the list above? Which ones? = Some =E2=80=9Cmodern=E2=80=9D topics may be already covered with a = slight different phrasing. For example, management of NFV would fall = under item g) above or require a specific topic.=20 3) Do you have interest in any of these topics? If so, in which order? We=E2=80=99ll appreciate if you could reply these questions. That would = give us important information for the next steps of NMRG. Best regards, Olivier and Lisandro NMRG Co-Chairs From nobody Thu Oct 23 08:17:44 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56891AC3D1 for ; Thu, 23 Oct 2014 08:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.339 X-Spam-Level: ** X-Spam-Status: No, score=2.339 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, RCVD_IN_DNSWL_LOW=-0.7, 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 RHtaVFDMiMzh for ; Thu, 23 Oct 2014 08:17:40 -0700 (PDT) Received: from delivery1.ufrgs.br (delivery1.ufrgs.br [143.54.2.211]) by ietfa.amsl.com (Postfix) with ESMTP id 034441A9023 for ; Thu, 23 Oct 2014 08:17:40 -0700 (PDT) Received: from delivery1.ufrgs.br (localhost [127.0.0.1]) by delivery1.ufrgs.br (Postfix) with ESMTP id 17B4A3008B7 for ; Thu, 23 Oct 2014 13:17:39 -0200 (BRST) Received: from msa1.ufrgs.br (msa1.ufrgs.br [143.54.2.208]) by delivery1.ufrgs.br (Postfix) with ESMTP id 0D4123D70E for ; Thu, 23 Oct 2014 13:17:39 -0200 (BRST) From: Lisandro Zambenedetti Granville Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <2EF6B26A-CF61-4679-9ACE-A68135BC1E63@inf.ufrgs.br> Date: Thu, 23 Oct 2014 17:17:37 +0200 To: nmrg@irtf.org Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) X-Mailer: Apple Mail (2.1990.1) X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/ZhIcWRZRljqb4KVVmd70eLW7fJQ Subject: [nmrg] 35th NMRG meeting - Call for Contributions X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 15:17:41 -0000 Dear all, We are glad to announce that the 35th NMRG meeting will take place in Rio de Janeiro, Nov. 17th 2014, during CNSM 2014. We are sending this message to invite you to participate in the NRMG meeting as well as to collect your interest to present research work. We invite interested speakers to briefly describe their potential talks in reaction to this call informing title, speaker names, and topic. NMRG is specially interested, but not limited, in the topics listed below: - Real world experiences in employing protocols for network management, regardless weather such protocols has been designed with management in mind; - Frameworks and architectures devoted or adapted to network management; - Lessons learned, both positive and negative, on using protocols, frameworks, and architectures - Disruptive and incremental deployment of new technologies in traditional network management solutions; - Management of emerging networking paradigms (eg., ICN, SDN, NFV, DCN, etc.) Contributions should be submitted via e-mail to olivier.festor@inria.fr and granville@inf.ufrgs.br. Best regards, Olivier & Lisandro NMRG Co-Chairs From nobody Thu Oct 23 09:52:50 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B22411ACDA8 for ; Thu, 23 Oct 2014 09:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLjP2sH4Pax0 for ; Thu, 23 Oct 2014 09:52:46 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ADD81ACD9E for ; Thu, 23 Oct 2014 09:52:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6348; q=dns/txt; s=iport; t=1414083167; x=1415292767; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=EJU7hld2/gNmoavhzfbXAhUlaPN2xhWGqbi5vf5GlKQ=; b=cyeDxMpm8rQbUF9c0UqXQcGyamk0H1lsdmlRZwlFyIdJ7fGS3mtcaeDv F8Gvdr8+HEoRE0Ri+jI6LmEqngWolcJFZlE1kmJrWTjR/SGLxX+/v4dkQ /RuFXm64ZtTNy90TyWYRFG8BsySwkwVpTDEflrvDrnjMm1NLZsSEIjUEc 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAEkxSVStJV2Q/2dsb2JhbABcgw5UXIMCyXIKh00CG3cWAX2EAgEBAQQBAQEaBhE0BQEXBAIBCBEEAQEDAgYdAwICAiULFAEICAIEARIIiDkNtAaUWQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSyJK4NpgUodOAaCcTaBHgWSBYcJhgCDSY0yhAGDeGyBSIEDAQEB X-IronPort-AV: E=Sophos;i="5.04,776,1406592000"; d="scan'208";a="89688565" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-1.cisco.com with ESMTP; 23 Oct 2014 16:52:46 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s9NGqjwZ032478 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Oct 2014 16:52:45 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.26]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Thu, 23 Oct 2014 11:52:45 -0500 From: "Alexander Clemm (alex)" To: Lisandro Zambenedetti Granville , "nmrg@irtf.org" Thread-Topic: [nmrg] Planning the next NMRG meetings for 2015 Thread-Index: AQHP7tR70P5oRjh5n0iE6Mv6Q25Gy5w95Bqw Date: Thu, 23 Oct 2014 16:52:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.80.224] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/bbNwHdFpgLn9zh0gMqDNc4C0nJ8 Subject: Re: [nmrg] Planning the next NMRG meetings for 2015 X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 16:52:48 -0000 SGkgTGlzYW5kcm8sDQoNCnRvIHlvdXIgZmlyc3QgcXVlc3Rpb24sIEkgdGhpbmsgaGF2aW5nIGFu IE5NUkcgbWVldGluZyBpbiBjb25qdW5jdGlvbiB3aXRoIElNIHdvdWxkIG1ha2Ugc2Vuc2UsIGFz IGl0IGlzIHdpZGVseSBhdHRlbmRlZCBieSBOTVJHJ3MgdGFyZ2V0IGF1ZGllbmNlIGFuZCBoYXMg bGFyZ2VyIHBhcnRpY2lwYXRpb24gdGhhbiBDTlNNLiAgT24geW91ciB0b3BpY3MsIChlKSBhbmQg KGYpIHNlZW0gY2xvc2VseSByZWxhdGVkIChtZWFzdXJlbWVudHMpLiAgUGVyaGFwcyBjb25zaWRl ciBjb21iaW5pbmcgdGhlbSBhbmQgY2FsbGluZyBvdXQgYSB0b3BpYyBtb3JlIGdlbmVyYWxseSBv biBTZXJ2aWNlIEFzc3VyYW5jZSBpbnN0ZWFkIChvZiB3aGljaCBtZWFzdXJlbWVudHMgYXJlIG9m IGNvdXJzZSBvbmUgYXNwZWN0Li4uKS4NCg0KQ2hlZXJzDQotLS0gQWxleA0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbm1yZyBbbWFpbHRvOm5tcmctYm91bmNlc0BpcnRmLm9y Z10gT24gQmVoYWxmIE9mIExpc2FuZHJvIFphbWJlbmVkZXR0aSBHcmFudmlsbGUNClNlbnQ6IFRo dXJzZGF5LCBPY3RvYmVyIDIzLCAyMDE0IDg6MTcgQU0NClRvOiBubXJnQGlydGYub3JnDQpTdWJq ZWN0OiBbbm1yZ10gUGxhbm5pbmcgdGhlIG5leHQgTk1SRyBtZWV0aW5ncyBmb3IgMjAxNQ0KDQpE ZWFyIE5NUkcgc3Vic2NyaWJlcnMNCg0KQmFjayBpbiAyMDExLCB3ZSBydW4gYSBwb2xsIG9uIHRo aXMgbGlzdCB0byBjb2xsZWN0IHlvdXIgZmVlZGJhY2sgIGluIHJlZ2FyZCB0byB0b3BpY3MgdGhh dCBOTVJHIGNvdWxkIGZvY3VzIG9uLiBBdCB0aGF0IHBvaW50LCB0aGUgdXNlIG9mIGF1dG9ub21p YyBjb21wdXRpbmcgZm9yIG5ldHdvcmsgbWFuYWdlbWVudCByZXZlYWxlZCB0byBiZSBhbiBvZnRl biBtZW50aW9uZWQgdG9waWMuIEZyb20gdGhhdCBwb2ludCBhbmQgb24sIHdlIG9yZ2FuaXplZCBz b21lIG1lZXRpbmdzIG9uIGF1dG9ub21pY3MgZm9yIG1hbmFnZW1lbnQgdGhhdCB1bHRpbWF0ZWx5 IHJlc3VsdGVkIGluIHNvbWUgSS1EIHByb3Bvc2FscywgYSBCb0YgaW4gdGhlIGxhc3QgSUVURiBt ZWV0aW5nLCBhbmQgdGhlIEFOSU1BIGluaXRpYXRpdmUuDQoNCldl4oCZdmUgYWxzbyBiZWVuIHJ1 bm5pbmcgYSBzZXJpZXMgb2Ygc3VjY2Vzc2Z1bCB3b3Jrc2hvcHMg4oCcb24gdGhlIHVzYWdlcyBv ZiBOZXRGbG93L0lQRklYIGluIE5ldHdvcmsgbWFuYWdlbWVudOKAnSwgdGhlIGxhc3Qgb25lIGJl aW5nIGhlbGQgaW4gQmVybGltIGR1cmluZyBJRVRGIDg3LiBBIG5leHQgd29ya3Nob3AgaXMgcGxh bm5lZCBmb3IgdGhlIE5NUkcgbWVldGluZyBpbiB0aGUgdXBjb21pbmcgSUVURiA5MyBpbiBQcmFn dWUuIFNvbWUgb3RoZXIgdG9waWMtc3BlY2lmaWMgbWVldGluZ3MgaGF2ZSBiZWVuIGFsc28gb3Jn YW5pemVkLCBzdWNoIGFzIOKAnGxvc3N5IGFuZCBsb3cgcG93ZXIgbmV0d29ya3MgbWFuYWdlbWVu dOKAnSAoMjd0aCBOTVJHIG1lZXRpbmcgZHVyaW5nIElFVEYgODEgaW4gUXVlYmVjKSwgIk1hbmFn ZW1lbnQgQXNwZWN0cyBvZiBFbWVyZ2luZyBOZXR3b3JraW5nIFBhcmFkaWdtc+KAnSAoMjl0aCBO TVJHIG1lZXRpbmcgZHVyaW5nIElFVEYgODYgaW4gT3JsYW5kbyksIGFuZCB0aGUg4oCcMXN0IFdv cmtzaG9wIG9uIExhcmdlIFNjYWxlIE5ldHdvcmsgTWVhc3VyZW1lbnRz4oCdICgzMXN0IE5NUkcg bWVldGluZyBkdXJpbmcgQ05TTSAyMDEzIGluIFp1cmljaCkuDQoNCkluIG9yZGVyIHRvIGJyaW5n IG1vcmUgdHJhbnNwYXJlbmN5IGFuZCBwbGFubmluZyBmb3IgdGhlIHVwY29taW5nIG1lZXRpbmcg aW4gMjAxNSAodGhhbmtzIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciBmb3IgY29tbWVudHMgb24gdGhp cyByZWdhcmQgaW4gdGhlIGxpc3QpLCB3ZSB3b3VsZCBsaWtlIHRvIHNoYXJlIHdpdGggeW91IG91 ciBpbml0aWFsIHRob3VnaHRzLCByZS1ydW4gdGhlIHBvbGwgd2UgbWVudGlvbmVkIGluIHRoZSBi ZWdpbm5pbmcgb2YgdGhpcyBtZXNzYWdlLCBhbmQgY29sbGVjdCB5b3VyIGZlZWRiYWNrIGZvciB0 aGUgTk1SRyBuZXh0IHN0ZXBzLiBXZSB3b3VsZCBsaWtlIHRvIG9yZ2FuaXplIGluIDIwMTUgZm91 ciBOTVJHIG1lZXRpbmc6IDMgbWVldGluZ3MgZHVyaW5nIElFVEZzLCBpbiBhZGRpdGlvbiB0byBh biBpbnRlcmltIG1lZXRpbmcgdG9nZXRoZXIgd2l0aCBJTSBvciBDTlNNIDIwMTUsIGlmIHRoZSBj b25mZXJlbmNlIGNhbGVuZGFyIGFsbG93cyB0aGF0LiBBcyBzdWNoLCB0aGUgdXBjb21pbmcgbWVl dGluZ3Mgd291bGQgYmUsIGluIHByaW5jaXBsZToNCg0KTk1SRyBtZWV0aW5nIGR1cmluZyBJRVRG IDkyLCBEYWxsYXMsIE1hci4gMjAxNQ0KLSBUb3BpYzogVEJEDQoNCk5NUkcgbWVldGluZyBkdXJp bmcgSUVURiA5MywgUHJhZ3VlLCBKdWwuIDIwMTUNCi0gVG9waWM6IFRvZ2V0aGVyIHdpdGggdGhl IEZsYW1pbmdvIEZQNyBwcm9qZWN0LCB3ZSBzY2hlZHVsZWQgYW5vdGhlciBlZGl0aW9uIG9mIHRo ZSBmbG93LWJhc2VkIG1lYXN1cmVtZW50IHdvcmtzaG9wLiBTaW5jZSB0aGUgbGFzdCB3b3Jrc2hv cCBpbiB0aGlzIHNlcmllcyBoYXBwZW5lZCBpbiBCZXJsaW0gQXVnLiAyMDEzLCB3ZSBiZWxpZXZl IEp1bC4gMjAxNSB3b3VsZCBiZSBhIGdvb2QgbW9tZW50IGZvciBhbm90aGVyIGlzc3VlLg0KDQpO TVJHIG1lZXRpbmcgZHVyaW5nIElFVEYgOTQsIFlva29oYW1hLCBOb3YuIDIwMTUNCi0gVG9waWM6 IFRCRA0KDQpOTVJHIChpbnRlcmltKSBtZWV0aW5nLCBvY2Nhc2lvbmFsbHkgdG9nZXRoZXIgd2l0 aCBJTSAyMDE1IChNYXkgMjAxNSwgT3R0YXdhKSBvciBDTlNNIDIwMTUgKHBvc3NpYmx5IE9jdC4v Tm92LiAyMDE1LCBUQkQpDQotIFRvcGljOiBUQkQNCg0KTk1SRyBtZWV0aW5ncyBkb27igJl0IG5l ZWQgdG8gaGF2ZSBzcGVjaWZpYyB0b3BpY3MuIFRoZSAzNXRoIG1lZXRpbmcgaW4gUmlvIHdpbGwg bm90IGJlIGNlbnRlcmVkIG9uIGEgc2luZ2xlIHRvcGljIChjYWxsIGZvciBjb250cmlidXRpb25z IHdpbGwgYmUgZGlzdHJpYnV0ZWQgaW4gdGhlIG5leHQgbWVzc2FnZSkuIFN0aWxsLCBoYXZpbmcg YSBzZXQgb2YgbWFpbiB0b3BpY3Mgd291bGQgY2VydGFpbmx5IGd1aWRlIGJldHRlciB0aGUgd29y ayBkZXZlbG9wZWQgdW5kZXIgdGhlIE5NUkcgYmVsdC4gQXMgbWVudGlvbmVkIGFib3ZlLCB3ZSB3 b3VsZCBsaWtlIHRvIGhlYXIgdGhlIGZlZWRiYWNrIG9mIE5NUkcgc3Vic2NyaWJlcnMgb24gdG9w aWNzIHRoYXQgeW91IGJlbGlldmUgc2hvdWxkIGJlIGFkZHJlc3NlZC4gQXMgYSByZWZlcmVuY2Ug YW5kIHN0YXJ0aW5nIHBvaW50IGZvciBhbm90aGVyIHBvbGwsIHBsZWFzZSBvYnNlcnZlIGJlbG93 IHRoZSBsaXN0IG9mIHRvcGljcyAoYXJiaXRyYXJ5IG9yZGVyKSBjb25zaWRlcmVkIGJhY2sgaW4g MjAxMS4NCg0KYSkgTWFuYWdlbWVudCBvZiB0aGUgSW50ZXJuZXQgb2YgVGhpbmdzDQpiKSBBdXRv bm9taWNzIG1hbmFnZW1lbnQgLyBuZXR3b3JrIGxlYXJuaW5nDQpjKSBOZXR3b3JrLXdpZGUgc2Fm ZSBjb25maWd1cmF0aW9uDQpkKSBFbmVyZ3kgbW9uaXRvcmluZyBhbmQgbWFuYWdlbWVudA0KZSkg TmV0d29yayBmbG93IG1lYXN1cmVtZW50IGFuZCBhbmFseXNpcw0KZikgTGFyZ2Utc2NhbGUgbmV0 d29yay13aWRlIG1lYXN1cmVtZW50cw0KZykgTWFuYWdlbWVudCBvZiB2aXJ0dWFsIG1hY2hpbmVz IGFuZCBjbG91ZHMNCg0KQ29uc2lkZXJpbmcgdGhlIGFib3ZlLCB3ZSB3b3VsZCBsaWtlIHRvIGFz ayB5b3UgdGhlIGZvbGxvd2luZyBxdWVzdGlvbnM6DQoNCjEpIEZvciB0aGUgaW50ZXJpbSBtZWV0 aW5nLCB3aGF0IHNlZW1zIG1vcmUgYWRlcXVhdGUgZm9yIHlvdXIgcGVyc29uYWwgY2FsZW5kYXIs IGkuZS4sIElNIG9yIENOU00/IFdl4oCZbGwgdHJ5IHRvIGFjY29tbW9kYXRlIHRoZSAyMDE1IGlu dGVyaW0gbWVldGluZyBpbiBhIG1vbWVudCB0aGF0IG1vcmUgcGVvcGxlIGNvdWxkIHBvdGVudGlh bGx5IGF0dGVuZC4NCg0KMikgV291bGQgeW91IGluY2x1ZGUgYWRkaXRpb25hbCB0b3BpY3MgdG8g dGhlIGxpc3QgYWJvdmU/IFdoaWNoIG9uZXM/IFNvbWUg4oCcbW9kZXJu4oCdIHRvcGljcyBtYXkg YmUgYWxyZWFkeSBjb3ZlcmVkIHdpdGggYSBzbGlnaHQgZGlmZmVyZW50IHBocmFzaW5nLiBGb3Ig ZXhhbXBsZSwgbWFuYWdlbWVudCBvZiBORlYgd291bGQgZmFsbCB1bmRlciBpdGVtIGcpIGFib3Zl IG9yIHJlcXVpcmUgYSBzcGVjaWZpYyB0b3BpYy4gDQoNCjMpIERvIHlvdSBoYXZlIGludGVyZXN0 IGluIGFueSBvZiB0aGVzZSB0b3BpY3M/IElmIHNvLCBpbiB3aGljaCBvcmRlcj8NCg0KV2XigJls bCBhcHByZWNpYXRlIGlmIHlvdSBjb3VsZCByZXBseSB0aGVzZSBxdWVzdGlvbnMuIFRoYXQgd291 bGQgZ2l2ZSB1cyBpbXBvcnRhbnQgaW5mb3JtYXRpb24gZm9yIHRoZSBuZXh0IHN0ZXBzIG9mIE5N UkcuDQoNCkJlc3QgcmVnYXJkcywNCg0KT2xpdmllciBhbmQgTGlzYW5kcm8NCk5NUkcgQ28tQ2hh aXJzDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpu bXJnIG1haWxpbmcgbGlzdA0Kbm1yZ0BpcnRmLm9yZw0KaHR0cHM6Ly93d3cuaXJ0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9ubXJnDQo= From nobody Fri Oct 24 00:50:53 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C331AD6C7 for ; Fri, 24 Oct 2014 00:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHvcygHHhNIp for ; Fri, 24 Oct 2014 00:50:49 -0700 (PDT) Received: from out63-ams.mf.surf.net (out63-ams.mf.surf.net [145.0.1.63]) (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 C97191A8912 for ; Fri, 24 Oct 2014 00:50:48 -0700 (PDT) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by outgoing3-ams.mf.surf.net (8.14.4/8.14.4/Debian-4) with ESMTP id s9O7q8Om012525; Fri, 24 Oct 2014 09:52:08 +0200 Received: from EXMBX31.ad.utwente.nl (130.89.4.146) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 24 Oct 2014 09:50:42 +0200 Received: from EXMBX34.ad.utwente.nl (130.89.4.149) by EXMBX31.ad.utwente.nl (130.89.4.146) with Microsoft SMTP Server (TLS) id 15.0.913.22; Fri, 24 Oct 2014 09:50:40 +0200 Received: from EXMBX34.ad.utwente.nl ([130.89.4.149]) by EXMBX34.ad.utwente.nl ([130.89.4.149]) with mapi id 15.00.0913.011; Fri, 24 Oct 2014 09:50:40 +0200 From: To: Thread-Topic: [nmrg] Planning the next NMRG meetings for 2015 Thread-Index: AQHP7tSU8r0hLVjKDkW/70DCXh8ajZw+4L+5 Date: Fri, 24 Oct 2014 07:50:39 +0000 Message-ID: <41AF3B94-DF91-4969-A8EA-C32FF131DD94@utwente.nl> References: In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Bayes-Prob: 0.5 (Score 0, tokens from: utwente-out:default, base:default, @@RPTN) X-CanIt-Geo: ip=130.89.5.49; country=NL; region=Provincie Overijssel; city=Enschede; latitude=52.2195; longitude=6.8912; http://maps.google.com/maps?q=52.2195,6.8912&z=6 X-CanItPRO-Stream: utwente-out:default (inherits from utwente:default, base:default) X-Canit-Stats-ID: 0bN6TQ8H9 - 7a04d6ac4f0d - 20141024 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/5Eo73l9BxDnLuUQKaP5Wob6xCC4 Cc: nmrg@irtf.org Subject: Re: [nmrg] Planning the next NMRG meetings for 2015 X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 07:50:52 -0000 Dear Lisandro (and others) What I miss in the IRTF are security management issues. As far as I know, t= here is a Crypto RG, but crypto is just one part of the puzzle. I'm not awa= re of other WGs on security, but please correct me if I'm wrong. Nice topics that, in my opinion, would fit well in a Network (operations an= d) Management RG are: - how well is BCP38 (IP spoofing) implemented? - how much worse is the amplification of DNSSEC? (We will present a paper o= n that at next IMC) - what is the behavior of botnets / DGAs? - what privacy sensitive data is leaked from various protocols, without use= rs awareness? I can make this list much longer. The key is that I propose to shift our fo= cus more from "the deign of management technologies" to the "analysis of op= erational problems".=20 Regarding location, I propose to focus (next to IETF) rather on IM/NOMS ins= tead of CNSM. In addition, we could meet with organizations more coupled to= the operational aspects, such as RIPE (many of us might be interested in a= tlas) and TERENA (TNC). Bye Aiko > On 23 okt. 2014, at 17:18, "Lisandro Zambenedetti Granville" wrote: >=20 > Dear NMRG subscribers >=20 > Back in 2011, we run a poll on this list to collect your feedback in reg= ard to topics that NMRG could focus on. At that point, the use of autonomic= computing for network management revealed to be an often mentioned topic. = >From that point and on, we organized some meetings on autonomics for manage= ment that ultimately resulted in some I-D proposals, a BoF in the last IETF= meeting, and the ANIMA initiative. >=20 > We=92ve also been running a series of successful workshops =93on the usag= es of NetFlow/IPFIX in Network management=94, the last one being held in Be= rlim during IETF 87. A next workshop is planned for the NMRG meeting in the= upcoming IETF 93 in Prague. Some other topic-specific meetings have been a= lso organized, such as =93lossy and low power networks management=94 (27th = NMRG meeting during IETF 81 in Quebec), "Management Aspects of Emerging Net= working Paradigms=94 (29th NMRG meeting during IETF 86 in Orlando), and the= =931st Workshop on Large Scale Network Measurements=94 (31st NMRG meeting = during CNSM 2013 in Zurich). >=20 > In order to bring more transparency and planning for the upcoming meeting= in 2015 (thanks Juergen Schoenwaelder for comments on this regard in the l= ist), we would like to share with you our initial thoughts, re-run the poll= we mentioned in the beginning of this message, and collect your feedback f= or the NMRG next steps. We would like to organize in 2015 four NMRG meeting= : 3 meetings during IETFs, in addition to an interim meeting together with = IM or CNSM 2015, if the conference calendar allows that. As such, the upcom= ing meetings would be, in principle: >=20 > NMRG meeting during IETF 92, Dallas, Mar. 2015 > - Topic: TBD >=20 > NMRG meeting during IETF 93, Prague, Jul. 2015 > - Topic: Together with the Flamingo FP7 project, we scheduled another edi= tion of the flow-based measurement workshop. Since the last workshop in thi= s series happened in Berlim Aug. 2013, we believe Jul. 2015 would be a good= moment for another issue. >=20 > NMRG meeting during IETF 94, Yokohama, Nov. 2015 > - Topic: TBD >=20 > NMRG (interim) meeting, occasionally together with IM 2015 (May 2015, Ott= awa) or CNSM 2015 (possibly Oct./Nov. 2015, TBD) > - Topic: TBD >=20 > NMRG meetings don=92t need to have specific topics. The 35th meeting in R= io will not be centered on a single topic (call for contributions will be d= istributed in the next message). Still, having a set of main topics would c= ertainly guide better the work developed under the NMRG belt. As mentioned = above, we would like to hear the feedback of NMRG subscribers on topics tha= t you believe should be addressed. As a reference and starting point for an= other poll, please observe below the list of topics (arbitrary order) consi= dered back in 2011. >=20 > a) Management of the Internet of Things > b) Autonomics management / network learning > c) Network-wide safe configuration > d) Energy monitoring and management > e) Network flow measurement and analysis > f) Large-scale network-wide measurements > g) Management of virtual machines and clouds >=20 > Considering the above, we would like to ask you the following questions: >=20 > 1) For the interim meeting, what seems more adequate for your personal ca= lendar, i.e., IM or CNSM? We=92ll try to accommodate the 2015 interim meeti= ng in a moment that more people could potentially attend. >=20 > 2) Would you include additional topics to the list above? Which ones? Som= e =93modern=94 topics may be already covered with a slight different phrasi= ng. For example, management of NFV would fall under item g) above or requir= e a specific topic.=20 >=20 > 3) Do you have interest in any of these topics? If so, in which order? >=20 > We=92ll appreciate if you could reply these questions. That would give us= important information for the next steps of NMRG. >=20 > Best regards, >=20 > Olivier and Lisandro > NMRG Co-Chairs >=20 > _______________________________________________ > nmrg mailing list > nmrg@irtf.org > https://www.irtf.org/mailman/listinfo/nmrg From nobody Sat Oct 25 03:55:55 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1926B1A8790 for ; Sat, 25 Oct 2014 03:55:53 -0700 (PDT) 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 RM5f9tol1d92 for ; Sat, 25 Oct 2014 03:55:50 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62BD01A8780 for ; Sat, 25 Oct 2014 03:55:50 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 41A984D4F7B70; Sat, 25 Oct 2014 10:55:46 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s9PAtlQY022101 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 25 Oct 2014 12:55:48 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.219]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Sat, 25 Oct 2014 12:55:47 +0200 From: "Papadimitriou, Dimitri (Dimitri)" To: Lisandro Zambenedetti Granville , "nmrg@irtf.org" Thread-Topic: [nmrg] Planning the next NMRG meetings for 2015 Thread-Index: AQHP7tSEnoEugUNM2Um6UgQqUWFrUpw+Il1Q Date: Sat, 25 Oct 2014 10:55:46 +0000 Message-ID: <84675BAA8C49154AB81E2587BE8BDF832348E297@FR711WXCHMBA07.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/vHse5JyGSq1jRgXCZOj_ot9LIpo Subject: Re: [nmrg] Planning the next NMRG meetings for 2015 X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2014 10:55:53 -0000 SGVsbG8sDQoNCkkgd291bGQgbGlrZSB0byBzZWUgdGhlIGxpc3QgZXh0ZW5kZWQgdG8gdGhlIGZv bGxvd2luZyB0b3BpY3M6DQoNCm8pIGluZm9ybWF0aW9uL2NvbnRlbnQgbmV0d29ya3MgbWFuYWdl bWVudCANCg0KbykgbW92ZSBiZXlvbmQgc3BhdGlvLXRlbXBvcmFsIGFuYWx5c2lzIG9mIHRyYWZm aWMgZmxvd3MgYW5kIGNvbnNpZGVyIHN0cnVjdHVyZSBhbmQgc2VtYW50aWMgYW5hbHlzaXMgb2Yg aW5mb3JtYXRpb24gZmxvd3MNCg0KbykgY29vcGVyYXRpdmUvYWdlbnQtYmFzZWQgbWFuYWdlbWVu dCANCg0KTW9yZSBnZW5lcmFsbHksIGl0IHNlZW1zIGFkdmlzYWJsZSB0byBrZWVwIGEgbW9yZSB0 ZWNobm9sb2d5LWluZGVwZW5kZW50IGFwcHJvYWNoLCBmb3IgaW5zdGFuY2UgaW5zdGVhZCBvZiB0 YXJnZXRpbmcgIk5GViIgb3Igc2ltaWxhciwgZm9jdXMgb24gZnVuY3Rpb24gcGxhY2VtZW50IHBy b2JsZW1zLCBmdW5jdGlvbmFsLWFic3RyYWN0aW9uIGFuZCBuZXR3b3JrLWZ1bmN0aW9uIGRyaXZl biBtYW5hZ2VtZW50Lg0KDQpDb25jZXJuaW5nIG1lZXRpbmcgdmVudWVzOiBteSBwcmVmZXJlbmNl IGdvZXMgdG8ga2VlcCBiYWxhbmNlIGJldHdlZW4gbnVtYmVyIG9mIG1lZXRpbmdzIG9yZ2FuaXpl ZCBkdXJpbmcgSUVURiAoMikgYW5kIGNvbmZlcmVuY2VzICgyKSwgdGh1cyBib3RoIElNIGFuZCBD TlNNIGJ1dCBpdCBjb3VsZCBiZSBhbHNvIHZhbHVhYmxlIHRvIGNvbnNpZGVyIGluc3RlYWQgYSBj b25mZXJlbmNlIHdoaWNoIGhhcyBhIG1vcmUgc3BlY2lmaWMgc2NvcGUgKHJlbGF0ZWQgdG8gdGhl IHRvcGljIG9mIHRoZSBOTVJHIG1lZXRpbmcpLg0KDQpUaGFua3MsDQotZGltaXRyaS4NCg0KDQoN Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbm1yZyBbbWFpbHRvOm5tcmct Ym91bmNlc0BpcnRmLm9yZ10gT24gQmVoYWxmIE9mIExpc2FuZHJvDQo+IFphbWJlbmVkZXR0aSBH cmFudmlsbGUNCj4gU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMjMsIDIwMTQgNToxNyBQTQ0KPiBU bzogbm1yZ0BpcnRmLm9yZw0KPiBTdWJqZWN0OiBbbm1yZ10gUGxhbm5pbmcgdGhlIG5leHQgTk1S RyBtZWV0aW5ncyBmb3IgMjAxNQ0KPiANCj4gRGVhciBOTVJHIHN1YnNjcmliZXJzDQo+IA0KPiBC YWNrIGluIDIwMTEsIHdlIHJ1biBhIHBvbGwgb24gdGhpcyBsaXN0IHRvIGNvbGxlY3QgeW91ciBm ZWVkYmFjayAgaW4NCj4gcmVnYXJkIHRvIHRvcGljcyB0aGF0IE5NUkcgY291bGQgZm9jdXMgb24u IEF0IHRoYXQgcG9pbnQsIHRoZSB1c2Ugb2YNCj4gYXV0b25vbWljIGNvbXB1dGluZyBmb3IgbmV0 d29yayBtYW5hZ2VtZW50IHJldmVhbGVkIHRvIGJlIGFuIG9mdGVuDQo+IG1lbnRpb25lZCB0b3Bp Yy4gRnJvbSB0aGF0IHBvaW50IGFuZCBvbiwgd2Ugb3JnYW5pemVkIHNvbWUgbWVldGluZ3Mgb24N Cj4gYXV0b25vbWljcyBmb3IgbWFuYWdlbWVudCB0aGF0IHVsdGltYXRlbHkgcmVzdWx0ZWQgaW4g c29tZSBJLUQgcHJvcG9zYWxzLA0KPiBhIEJvRiBpbiB0aGUgbGFzdCBJRVRGIG1lZXRpbmcsIGFu ZCB0aGUgQU5JTUEgaW5pdGlhdGl2ZS4NCj4gDQo+IFdl4oCZdmUgYWxzbyBiZWVuIHJ1bm5pbmcg YSBzZXJpZXMgb2Ygc3VjY2Vzc2Z1bCB3b3Jrc2hvcHMg4oCcb24gdGhlIHVzYWdlcyBvZg0KPiBO ZXRGbG93L0lQRklYIGluIE5ldHdvcmsgbWFuYWdlbWVudOKAnSwgdGhlIGxhc3Qgb25lIGJlaW5n IGhlbGQgaW4gQmVybGltDQo+IGR1cmluZyBJRVRGIDg3LiBBIG5leHQgd29ya3Nob3AgaXMgcGxh bm5lZCBmb3IgdGhlIE5NUkcgbWVldGluZyBpbiB0aGUNCj4gdXBjb21pbmcgSUVURiA5MyBpbiBQ cmFndWUuIFNvbWUgb3RoZXIgdG9waWMtc3BlY2lmaWMgbWVldGluZ3MgaGF2ZSBiZWVuDQo+IGFs c28gb3JnYW5pemVkLCBzdWNoIGFzIOKAnGxvc3N5IGFuZCBsb3cgcG93ZXIgbmV0d29ya3MgbWFu YWdlbWVudOKAnSAoMjd0aA0KPiBOTVJHIG1lZXRpbmcgZHVyaW5nIElFVEYgODEgaW4gUXVlYmVj KSwgIk1hbmFnZW1lbnQgQXNwZWN0cyBvZiBFbWVyZ2luZw0KPiBOZXR3b3JraW5nIFBhcmFkaWdt c+KAnSAoMjl0aCBOTVJHIG1lZXRpbmcgZHVyaW5nIElFVEYgODYgaW4gT3JsYW5kbyksIGFuZA0K PiB0aGUg4oCcMXN0IFdvcmtzaG9wIG9uIExhcmdlIFNjYWxlIE5ldHdvcmsgTWVhc3VyZW1lbnRz 4oCdICgzMXN0IE5NUkcgbWVldGluZw0KPiBkdXJpbmcgQ05TTSAyMDEzIGluIFp1cmljaCkuDQo+ IA0KPiBJbiBvcmRlciB0byBicmluZyBtb3JlIHRyYW5zcGFyZW5jeSBhbmQgcGxhbm5pbmcgZm9y IHRoZSB1cGNvbWluZyBtZWV0aW5nDQo+IGluIDIwMTUgKHRoYW5rcyBKdWVyZ2VuIFNjaG9lbndh ZWxkZXIgZm9yIGNvbW1lbnRzIG9uIHRoaXMgcmVnYXJkIGluIHRoZQ0KPiBsaXN0KSwgd2Ugd291 bGQgbGlrZSB0byBzaGFyZSB3aXRoIHlvdSBvdXIgaW5pdGlhbCB0aG91Z2h0cywgcmUtcnVuIHRo ZQ0KPiBwb2xsIHdlIG1lbnRpb25lZCBpbiB0aGUgYmVnaW5uaW5nIG9mIHRoaXMgbWVzc2FnZSwg YW5kIGNvbGxlY3QgeW91cg0KPiBmZWVkYmFjayBmb3IgdGhlIE5NUkcgbmV4dCBzdGVwcy4gV2Ug d291bGQgbGlrZSB0byBvcmdhbml6ZSBpbiAyMDE1IGZvdXINCj4gTk1SRyBtZWV0aW5nOiAzIG1l ZXRpbmdzIGR1cmluZyBJRVRGcywgaW4gYWRkaXRpb24gdG8gYW4gaW50ZXJpbSBtZWV0aW5nDQo+ IHRvZ2V0aGVyIHdpdGggSU0gb3IgQ05TTSAyMDE1LCBpZiB0aGUgY29uZmVyZW5jZSBjYWxlbmRh ciBhbGxvd3MgdGhhdC4gQXMNCj4gc3VjaCwgdGhlIHVwY29taW5nIG1lZXRpbmdzIHdvdWxkIGJl LCBpbiBwcmluY2lwbGU6DQo+IA0KPiBOTVJHIG1lZXRpbmcgZHVyaW5nIElFVEYgOTIsIERhbGxh cywgTWFyLiAyMDE1DQo+IC0gVG9waWM6IFRCRA0KPiANCj4gTk1SRyBtZWV0aW5nIGR1cmluZyBJ RVRGIDkzLCBQcmFndWUsIEp1bC4gMjAxNQ0KPiAtIFRvcGljOiBUb2dldGhlciB3aXRoIHRoZSBG bGFtaW5nbyBGUDcgcHJvamVjdCwgd2Ugc2NoZWR1bGVkIGFub3RoZXINCj4gZWRpdGlvbiBvZiB0 aGUgZmxvdy1iYXNlZCBtZWFzdXJlbWVudCB3b3Jrc2hvcC4gU2luY2UgdGhlIGxhc3Qgd29ya3No b3AgaW4NCj4gdGhpcyBzZXJpZXMgaGFwcGVuZWQgaW4gQmVybGltIEF1Zy4gMjAxMywgd2UgYmVs aWV2ZSBKdWwuIDIwMTUgd291bGQgYmUgYQ0KPiBnb29kIG1vbWVudCBmb3IgYW5vdGhlciBpc3N1 ZS4NCj4gDQo+IE5NUkcgbWVldGluZyBkdXJpbmcgSUVURiA5NCwgWW9rb2hhbWEsIE5vdi4gMjAx NQ0KPiAtIFRvcGljOiBUQkQNCj4gDQo+IE5NUkcgKGludGVyaW0pIG1lZXRpbmcsIG9jY2FzaW9u YWxseSB0b2dldGhlciB3aXRoIElNIDIwMTUgKE1heSAyMDE1LA0KPiBPdHRhd2EpIG9yIENOU00g MjAxNSAocG9zc2libHkgT2N0Li9Ob3YuIDIwMTUsIFRCRCkNCj4gLSBUb3BpYzogVEJEDQo+IA0K PiBOTVJHIG1lZXRpbmdzIGRvbuKAmXQgbmVlZCB0byBoYXZlIHNwZWNpZmljIHRvcGljcy4gVGhl IDM1dGggbWVldGluZyBpbiBSaW8NCj4gd2lsbCBub3QgYmUgY2VudGVyZWQgb24gYSBzaW5nbGUg dG9waWMgKGNhbGwgZm9yIGNvbnRyaWJ1dGlvbnMgd2lsbCBiZQ0KPiBkaXN0cmlidXRlZCBpbiB0 aGUgbmV4dCBtZXNzYWdlKS4gU3RpbGwsIGhhdmluZyBhIHNldCBvZiBtYWluIHRvcGljcyB3b3Vs ZA0KPiBjZXJ0YWlubHkgZ3VpZGUgYmV0dGVyIHRoZSB3b3JrIGRldmVsb3BlZCB1bmRlciB0aGUg Tk1SRyBiZWx0LiBBcw0KPiBtZW50aW9uZWQgYWJvdmUsIHdlIHdvdWxkIGxpa2UgdG8gaGVhciB0 aGUgZmVlZGJhY2sgb2YgTk1SRyBzdWJzY3JpYmVycyBvbg0KPiB0b3BpY3MgdGhhdCB5b3UgYmVs aWV2ZSBzaG91bGQgYmUgYWRkcmVzc2VkLiBBcyBhIHJlZmVyZW5jZSBhbmQgc3RhcnRpbmcNCj4g cG9pbnQgZm9yIGFub3RoZXIgcG9sbCwgcGxlYXNlIG9ic2VydmUgYmVsb3cgdGhlIGxpc3Qgb2Yg dG9waWNzIChhcmJpdHJhcnkNCj4gb3JkZXIpIGNvbnNpZGVyZWQgYmFjayBpbiAyMDExLg0KPiAN Cj4gYSkgTWFuYWdlbWVudCBvZiB0aGUgSW50ZXJuZXQgb2YgVGhpbmdzDQo+IGIpIEF1dG9ub21p Y3MgbWFuYWdlbWVudCAvIG5ldHdvcmsgbGVhcm5pbmcNCj4gYykgTmV0d29yay13aWRlIHNhZmUg Y29uZmlndXJhdGlvbg0KPiBkKSBFbmVyZ3kgbW9uaXRvcmluZyBhbmQgbWFuYWdlbWVudA0KPiBl KSBOZXR3b3JrIGZsb3cgbWVhc3VyZW1lbnQgYW5kIGFuYWx5c2lzDQo+IGYpIExhcmdlLXNjYWxl IG5ldHdvcmstd2lkZSBtZWFzdXJlbWVudHMNCj4gZykgTWFuYWdlbWVudCBvZiB2aXJ0dWFsIG1h Y2hpbmVzIGFuZCBjbG91ZHMNCj4gDQo+IENvbnNpZGVyaW5nIHRoZSBhYm92ZSwgd2Ugd291bGQg bGlrZSB0byBhc2sgeW91IHRoZSBmb2xsb3dpbmcgcXVlc3Rpb25zOg0KPiANCj4gMSkgRm9yIHRo ZSBpbnRlcmltIG1lZXRpbmcsIHdoYXQgc2VlbXMgbW9yZSBhZGVxdWF0ZSBmb3IgeW91ciBwZXJz b25hbA0KPiBjYWxlbmRhciwgaS5lLiwgSU0gb3IgQ05TTT8gV2XigJlsbCB0cnkgdG8gYWNjb21t b2RhdGUgdGhlIDIwMTUgaW50ZXJpbQ0KPiBtZWV0aW5nIGluIGEgbW9tZW50IHRoYXQgbW9yZSBw ZW9wbGUgY291bGQgcG90ZW50aWFsbHkgYXR0ZW5kLg0KPiANCj4gMikgV291bGQgeW91IGluY2x1 ZGUgYWRkaXRpb25hbCB0b3BpY3MgdG8gdGhlIGxpc3QgYWJvdmU/IFdoaWNoIG9uZXM/IFNvbWUN Cj4g4oCcbW9kZXJu4oCdIHRvcGljcyBtYXkgYmUgYWxyZWFkeSBjb3ZlcmVkIHdpdGggYSBzbGln aHQgZGlmZmVyZW50IHBocmFzaW5nLg0KPiBGb3IgZXhhbXBsZSwgbWFuYWdlbWVudCBvZiBORlYg d291bGQgZmFsbCB1bmRlciBpdGVtIGcpIGFib3ZlIG9yIHJlcXVpcmUgYQ0KPiBzcGVjaWZpYyB0 b3BpYy4NCj4gDQo+IDMpIERvIHlvdSBoYXZlIGludGVyZXN0IGluIGFueSBvZiB0aGVzZSB0b3Bp Y3M/IElmIHNvLCBpbiB3aGljaCBvcmRlcj8NCj4gDQo+IFdl4oCZbGwgYXBwcmVjaWF0ZSBpZiB5 b3UgY291bGQgcmVwbHkgdGhlc2UgcXVlc3Rpb25zLiBUaGF0IHdvdWxkIGdpdmUgdXMNCj4gaW1w b3J0YW50IGluZm9ybWF0aW9uIGZvciB0aGUgbmV4dCBzdGVwcyBvZiBOTVJHLg0KPiANCj4gQmVz dCByZWdhcmRzLA0KPiANCj4gT2xpdmllciBhbmQgTGlzYW5kcm8NCj4gTk1SRyBDby1DaGFpcnMN Cj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IG5tcmcgbWFpbGluZyBsaXN0DQo+IG5tcmdAaXJ0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaXJ0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9ubXJnDQo= From nobody Mon Oct 27 09:37:04 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB461A0451 for ; Mon, 27 Oct 2014 09:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.26 X-Spam-Level: X-Spam-Status: No, score=-4.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, 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 Vw9J9Cu5zIGa for ; Mon, 27 Oct 2014 09:36:57 -0700 (PDT) Received: from mx2.eict.de (mx2.eict.de [212.91.241.168]) by ietfa.amsl.com (Postfix) with ESMTP id B30451A0A6B for ; Mon, 27 Oct 2014 09:36:56 -0700 (PDT) Received: by mx2.eict.de (Postfix, from userid 481) id C1DBF1FF5B; Mon, 27 Oct 2014 17:36:55 +0100 (CET) Received: from mail.eict.de (mx1 [172.16.6.1]) by mx2.eict.de (Postfix) with ESMTP id 4B8EF1FF56; Mon, 27 Oct 2014 17:36:55 +0100 (CET) Received: from sbs2008.eict.local (sbs2008.intern.eict.de [192.168.2.11]) by mail.eict.de (Postfix) with ESMTP id DA1663783F8; Mon, 27 Oct 2014 17:36:54 +0100 (CET) Received: from SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298]) by SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298%13]) with mapi; Mon, 27 Oct 2014 17:36:54 +0100 From: Kostas Pentikousis To: "nmrg@irtf.org" Date: Mon, 27 Oct 2014 17:36:53 +0100 Thread-Topic: New Version Notification for draft-pentikousis-nmrg-andr-01.txt Thread-Index: Ac/yA0YbGP3WMbadRNaTnOSKhptcDAAAAqyg Message-ID: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C7ADE11@SBS2008.eict.local> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/zJeO2lxGZJ7HCNSWWXYeKk0b7mI Cc: "draft-pentikousis-nmrg-andr@tools.ietf.org" Subject: [nmrg] WG: New Version Notification for draft-pentikousis-nmrg-andr-01.txt X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 16:36:59 -0000 RGVhciBhbGwsDQoNCldlIGhhdmUgdXBkYXRlZCBkcmFmdC1wZW50aWtvdXNpcy1ubXJnLWFuZHIg aW4gdGltZSBmb3IgdGhlIGN1dG9mZiB0b2RheS4gV2UncmUgbG9va2luZyBmb3J3YXJkIHRvIHlv dXIgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zIGFuZCwgbW9yZSBpbXBvcnRhbnRseSwgdGV4dCBj b250cmlidXRpb25zIGFuZCByZWZlcmVuY2VzIHdoaWNoIGNvdWxkIGZ1cnRoZXIgZW5oYW5jZSB0 aGlzIGRvY3VtZW50Lg0KDQpXZSB3b3VsZCBsaWtlIHRvIHNlZSBtb3JlIGZvbGtzIGdldHRpbmcg b24gYm9hcmQgdGhpcyBkaXNjdXNzaW9uIGFuZCBkb2N1bWVudCBkZXZlbG9wbWVudC4gSW4gdGhl IHBhc3QsIHNpbWlsYXIgZWZmb3J0cyB3b3JrZWQgd2VsbCwgZS5nLiBpbiBJQ05SRy4gU28gcGxl YXNlIGNvbnNpZGVyIHRoaXMgYXMgYW4gb3BlbiAoYW5kIHN0YW5kaW5nKSBpbnZpdGF0aW9uIDop DQoNCkJlc3QgcmVnYXJkcywNCg0KS29zdGFzDQoNCg0KLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNo cmljaHQtLS0tLQ0KVm9uOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmddIA0KR2VzZW5kZXQ6IE1vbnRhZywgMjcuIE9rdG9iZXIgMjAxNCAx NzozMA0KQW46IE1hbm9saXMgU2lmYWxha2lzOyBLb3N0YXMgUGVudGlrb3VzaXM7IEtvc3RhcyBQ ZW50aWtvdXNpczsgTWFub2xpcyBTaWZhbGFraXMNCkJldHJlZmY6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtcGVudGlrb3VzaXMtbm1yZy1hbmRyLTAxLnR4dA0KDQoNCkEgbmV3 IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1wZW50aWtvdXNpcy1ubXJnLWFuZHItMDEudHh0DQpoYXMg YmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEtvc3RhcyBQZW50aWtvdXNpcyBhbmQgcG9z dGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1wZW50aWtvdXNpcy1u bXJnLWFuZHINClJldmlzaW9uOgkwMQ0KVGl0bGU6CQlBdXRvbm9taWMgTmV0d29ya2luZyBEZWZp bml0aW9ucyBSZXZpc2l0ZWQNCkRvY3VtZW50IGRhdGU6CTIwMTQtMTAtMjcNCkdyb3VwOgkJSW5k aXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTEwDQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtcGVudGlrb3VzaXMtbm1yZy1hbmRyLTAx LnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LXBlbnRpa291c2lzLW5tcmctYW5kci8NCkh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1wZW50aWtvdXNpcy1ubXJnLWFuZHItMDENCkRpZmY6ICAgICAg ICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1wZW50aWtvdXNpcy1u bXJnLWFuZHItMDENCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IHJldmlzaXRzIHRoZSBh dXRvbm9taWMgbmV0d29ya2luZyB0ZXJtaW5vbG9neQ0KICAgZXN0YWJsaXNoZWQgaW4gcGVlci1y ZXZpZXdlZCBsaXRlcmF0dXJlLCBhaW1pbmcgdG8gY29udHJpYnV0ZSB0byB0aGUNCiAgIG9uZ29p bmcgZGlzY3Vzc2lvbiBpbiB0aGUgSVJURiBOTVJHIGFib3V0IGhvdyB0byBtb3ZlIGZvcndhcmQg d2l0aA0KICAgc3RhbmRhcmRpemluZyB2YXJpb3VzIGF1dG9ub21pYyBuZXR3b3JraW5nIGFzcGVj dHMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0 IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9u IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9v bHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Mon Oct 27 11:59:55 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7942A1ACF94 for ; Mon, 27 Oct 2014 11:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, 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 i5kOQYuNShpY for ; Mon, 27 Oct 2014 11:59:18 -0700 (PDT) Received: from mx2.eict.de (mx2.eict.de [212.91.241.168]) by ietfa.amsl.com (Postfix) with ESMTP id F15621ACF89 for ; Mon, 27 Oct 2014 11:58:59 -0700 (PDT) Received: by mx2.eict.de (Postfix, from userid 481) id 059FE1FF58; Mon, 27 Oct 2014 19:58:59 +0100 (CET) Received: from mail.eict.de (mx1 [172.16.6.1]) by mx2.eict.de (Postfix) with ESMTP id E97D21FF54; Mon, 27 Oct 2014 19:58:57 +0100 (CET) Received: from sbs2008.eict.local (sbs2008.intern.eict.de [192.168.2.11]) by mail.eict.de (Postfix) with ESMTP id 7C3FA3783F8; Mon, 27 Oct 2014 19:58:57 +0100 (CET) Received: from SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298]) by SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298%13]) with mapi; Mon, 27 Oct 2014 19:58:57 +0100 From: Kostas Pentikousis To: "draft-irtf-nmrg-autonomic-network-definitions@tools.ietf.org" Date: Mon, 27 Oct 2014 19:58:56 +0100 Thread-Topic: Review of draft-irtf-nmrg-autonomic-network-definitions-04 Thread-Index: Ac/yGA8TNsBjbQGLRvadi3gNm27XaA== Message-ID: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C7ADE14@SBS2008.eict.local> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/oFceJbMhdX7MIxVuBzRGm7RDmng Cc: "nmrg@irtf.org" Subject: [nmrg] Review of draft-irtf-nmrg-autonomic-network-definitions-04 X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 18:59:29 -0000 Dear authors, all, I reviewed draft-irtf-nmrg-autonomic-network-definitions-04. Overall, the d= raft is easy-to-read, but it feels more like "original" work than the RG do= cuments I'm familiar with. As I mentioned in the Toronto meeting and on the= list, the draft lacks the appropriate list of "citations and references to= relevant research publications". I personally do not consider sufficient t= he three references mentioned in passing ("There is a large literature, including several useful overview papers (e.g., [Samaan],= [Movahedi], and [Dobson])"). Further, several assumptions remain unstated = (could be fixed by adding a new section) and certain inconsistencies persis= t in this revision (see below). In summary: If this draft is to become the reference RFC on Autonomic Netwo= rking, more work is needed in the RG. General comments: ----------------- The draft includes some normative-resembling language, which may be mislead= ing to uninitiated readers: =20 * "For this reason we suggest here to NOT generally disable autonomic funct= ions if they encounter unexpected conditions ..." * "Autonomic functions must be able to adapt their behavior ... " * "Intent must not be used to convey low-level commands or concepts ..." * "an autonomic function must understand the full life cycle of the device = it runs on ... * "Warnings however should be issued if node specific overrides may conflic= t with autonomic behaviour." * "Information about the network should be collected and aggregated by the = network itself, presented in consolidated fashion to the administrator." * "Autonomic network events should concern the autonomic network as a whole= , not individual systems in isolation. ..." (and the rest of the paragraph) * "apply specific algorithms to determine what should be reported." * "All the components around the "autonomic service agents" should be commo= n components, such that the autonomic service agents do not have to replica= te common tasks individually." Doesn't this read like an implementation sug= gestion? * "autonomic functions in the context of this framework should therefore op= erate at the IP layer." I guess it would be better to rephrase the above sentences to avoid future = misunderstandings. Also, have we reached consensus in NMRG that "The goal of the work on auton= omic networking in the IETF is therefore not just to create autonomic funct= ions, but to define a common infrastructure that autonomic functions can us= e." And, why is an NMRG draft indicating what the IETF goal is? Section-specific comments: -------------------------- - Abstract: The sentence "This document applies the concepts of autonomic s= ystems to a network, ..." does not reflect the draft contents. There is ver= y little that is being _applied_ to, as no references to earlier work are g= iven for the concepts defined in the draft (as per Sec. 2). As mentioned ab= ove, the text reads more like original work undertaken for this draft. - Section 1: The draft makes an implicit assumption which should become exp= licit. Namely, the draft adopts a node-centric approach ("Autonomic Network= ing aims at putting the intelligence of today's operations back into algori= thms at the node level ...". This assumption should be stated explicitly. M= ind you, not everyone in the research community may agree that AN should be= defined at the node level, instead of at the system level. I'd would be in= terested in other folks' opinion/pointers in earlier literature on this. No= te that "node" is defined in Sec. 2 by what it does (i.e. it "employs exclu= sively autonomic functions"). The following sentence implies a certain dichotomy: "a mixed approach, wher= e some functions are autonomic and others are centrally mangaged", which ma= y be true if you have the node-centric assumption in mind. A RoutFlow-like = network runs OSPF "centrally" but I would argue that it retains the autonom= ic properties of the protocol at the system level ("Autonomic Domain" in te= rms of this draft). This dichotomy appears later in the text as well, e.g. = "which functions should be centralised or follow an autonomic approach." Regarding related work, the text indicates that in "the present document we= focus on concepts and definitions that seem sufficiently mature to become = the basis for interoperable specifications in the near future." Since no re= ferences are given, _who_ has determined that the "concepts and definitions= " in this draft are "mature". The authors? NMRG? ... Was there a workshop t= o tackle this point? Perhaps adding a reference would resolve this in a spe= edy manner. Ditto for the ending sentence of this section: "This document p= rovides the definitions and design goals for Autonomic Networking." In whic= h context? Another assumption is that the draft aims for a migration environment ("suc= h specifications will need to co-exist with traditional methods of network = configuration and management, rather than realising an exclusively autonomi= c system with all the properties that it would require."). A distinct secti= on entitled "Assumptions" would serve the casual reader well. - Section 2: Since no references are provided, some text should be added to= explicitly state that these definitions are specified by _this_ draft. Alt= ernatively, of course, refs could be added. It's not crystal clear what is the relationship between an Autonomic Networ= k and a Autonomic Domain. Based on their current definitions, it appears to= be the lack of (the same) intent. Please clarify. The concept of an operating region for an autonomic node/network/domain is = missing in the definitions. - Section 3: Do we have consensus in NMRG that "The original design goals o= f autonomic systems as described in [Kephart] also apply to Autonomic Netwo= rks" (as-is)? I heard different opinions, but I'm curious what others in th= e RG think. In Sec. 3.1: "Functions do not require to be configured," -- by whom? Do you mean a netw= ork operator? "secure themselves against potential attacks." -- shouldn't this be a bit s= coped? Proposed text: OLD: "determine ways to optimise their behaviour." NEW: "determine ways to optimise their behavior against a set of well-defin= ed goals". In Sec. 3.2: "Conflict resolution between autonomic default behaviour and intent on one = side ..." -- This may be confusing. Why doesn't _autonomic default behavior= _ include intent? Please clarify. Given the implicit node-centric approach adopted in this draft (see above) = the following sentence is a bit contradictory, and I think inconsistent wit= h the rest of the text: "Generally, autonomic mechanisms define a network w= ide behaviour, whereas the alternative methods are typically on a node by n= ode basis."=20 Then, "Node based management concepts take a higher priority over autonomic= methods." But don't we refer to Autonomic Nodes? As the draft indicates, network operations tend to be manual/configuration-= oriented as opposed to adopting well-defined algorithms for steering operat= ion. Is operating an atomic plant less critical or less complex than operat= ing a network? Some retrospective/discussion on earlier efforts in the auto= nomic networking practice would be valuable here. In sec. 3.4: does the following maxim "If a problem can be solved in a dist= ributed manner, it should not be centralised." belong to this draft? In Sec. 3.6: the goal "optimize my network for energy efficiency" is not we= ll-defined. Abstraction may it be, but it has to be measurable somehow. See= proposed text above. Also, it's not clear how this sentence "The administrator should not even b= e exposed to the version of the IP protocol running in the network." is rel= ated with "energy optimization". In Sec. 3.9: Please add a couple of references/examples to better document = the sentence "For example, layer 2 switching today is already relatively au= tonomic in many environments; routing functions can be autonomic."=20 - Section 4: In general this section needs further editing. First, the open= ing sentence ("This section identifies various items that are explicitly no= t design goals for autonomic networks, ...") is quite vague. For whom is th= is _not_ a design goal? NMRG? IRTF? IETF? Researchers? Practitioners? Engin= eers? Network operators? Protocol designers/implementers? In general, it is= not clear whose anxieties does this section address by explicitly declarin= g non-goals. Second, are the following sentences really needed? * "(They should become more like doctors than hospital orderlies.)" * "Truck rolls will not be eliminated when faulty equipment needs to be rep= laced." * "Senior management might fear loss of control of an autonomic network." In general, is Section 4 needed in the first place? Isn't it better to defi= ne the goals clearly so that listing an arbitrary set of non-goals becomes = redundant? - Section 5: wrt Fig. 1, it's not clear why the "Autonomic Control Plane" i= s outside the "Standard Operating System Functions". Such an illustration s= omehow indicates that ACP is an add-on, as opposed to being part and parcel= of an autonomic node. Editorial/Nits: ----- In the beginning of Sec. 2, a sentence such as "This document uses the foll= owing terms:" would be nice to add. s/mangaged./managed. s/self- managing,/self-managing, s/take place."/take place. s/outside scope/outside the scope respected‎ ??? s/(Section 3.5,/ (Section 3.5) Finally, there's no text adhering to RFC 5743, Sec. 2.1. It would be good t= o add in the next draft revision. Best regards, Kostas From nobody Mon Oct 27 17:04:51 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01A911A86FE for ; Mon, 27 Oct 2014 17:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.978 X-Spam-Level: X-Spam-Status: No, score=-2.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, GB_I_INVITATION=-2, MIME_8BIT_HEADER=0.3, 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 lSNSYMuyC-ir for ; Mon, 27 Oct 2014 17:04:45 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FB191A1B85 for ; Mon, 27 Oct 2014 17:04:45 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id u10so6722188lbd.15 for ; Mon, 27 Oct 2014 17:04:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=+umcmmQm8Oii2DS1OBBzgIvQhKMeofjAok0wKr6aKpo=; b=ewxnuWTYBSdb6jY88pk2Y8rxYoL5/VT44H8dDQxD+RPgy2KoZjBazAmC+Pa8c/Zn7L +kSNJKrMAjGLAfOzHv0Q/uyz9Fq93Xd6sSI4MVu4vu8vhg1BJ6L0ZB1dB+lKThs2yNkW M6g4ggvjOmnfEagcDzBaK35TUNMrjoca9gmqOS/ZMeQlZdZspUlCLDXWsnZ2aySC+5nM XFVukgTyTdlTAUdEa5Hcvwm5pKPClj2SWegDY7s2rYbMUMxIeH45SIbOhaNYIzRcp+a7 j2qzG/roO664nh0Hm611rn3NunpXv6vO/l5O1WPcTiXpZiYTuITN9NzjhyEgfqVYpGxx 2VXg== MIME-Version: 1.0 X-Received: by 10.152.36.5 with SMTP id m5mr16285592laj.51.1414454683253; Mon, 27 Oct 2014 17:04:43 -0700 (PDT) Sender: jeferson.nobre@gmail.com Received: by 10.112.18.136 with HTTP; Mon, 27 Oct 2014 17:04:43 -0700 (PDT) In-Reply-To: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C7ADE11@SBS2008.eict.local> References: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C7ADE11@SBS2008.eict.local> Date: Mon, 27 Oct 2014 22:04:43 -0200 X-Google-Sender-Auth: 45cx7GFcpueZxBZBhIVjGqImGUw Message-ID: From: =?UTF-8?Q?J=C3=A9ferson_Campos_Nobre?= To: Kostas Pentikousis Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/Fpv4h_bNQUI2MecxlwBckaw5zNY Cc: "nmrg@irtf.org" , "draft-pentikousis-nmrg-andr@tools.ietf.org" Subject: Re: [nmrg] WG: New Version Notification for draft-pentikousis-nmrg-andr-01.txt X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 00:04:49 -0000 Hi Kostas. I think that there are 2 papers that could/should be considered too, specially considering the NMRG context: - Samaan, Nancy, and Ahmed Karmouch. "Towards autonomic network management: an analysis of current and future research directions." Communications Surveys & Tutorials, IEEE 11.3 (2009): 22-36. - Jennings, Brendan, et al. "Towards autonomic management of communications networks." Communications Magazine, IEEE 45.10 (2007): 112-121. Cheers. J=C3=A9ferson Campos Nobre PhD Student Computer Networks Group - Institute of Informatics Federal University of Rio Grande do Sul http://www.inf.ufrgs.br/~jcnobre On Mon, Oct 27, 2014 at 2:36 PM, Kostas Pentikousis wrote: > Dear all, > > We have updated draft-pentikousis-nmrg-andr in time for the cutoff today.= We're looking forward to your comments and suggestions and, more important= ly, text contributions and references which could further enhance this docu= ment. > > We would like to see more folks getting on board this discussion and docu= ment development. In the past, similar efforts worked well, e.g. in ICNRG. = So please consider this as an open (and standing) invitation :) > > Best regards, > > Kostas > > > -----Urspr=C3=BCngliche Nachricht----- > Von: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Gesendet: Montag, 27. Oktober 2014 17:30 > An: Manolis Sifalakis; Kostas Pentikousis; Kostas Pentikousis; Manolis Si= falakis > Betreff: New Version Notification for draft-pentikousis-nmrg-andr-01.txt > > > A new version of I-D, draft-pentikousis-nmrg-andr-01.txt > has been successfully submitted by Kostas Pentikousis and posted to the I= ETF repository. > > Name: draft-pentikousis-nmrg-andr > Revision: 01 > Title: Autonomic Networking Definitions Revisited > Document date: 2014-10-27 > Group: Individual Submission > Pages: 10 > URL: http://www.ietf.org/internet-drafts/draft-pentikousis-nmr= g-andr-01.txt > Status: https://datatracker.ietf.org/doc/draft-pentikousis-nmrg-a= ndr/ > Htmlized: http://tools.ietf.org/html/draft-pentikousis-nmrg-andr-01 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-pentikousis-nmrg= -andr-01 > > Abstract: > This document revisits the autonomic networking terminology > established in peer-reviewed literature, aiming to contribute to the > ongoing discussion in the IRTF NMRG about how to move forward with > standardizing various autonomic networking aspects. > > > > > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > nmrg mailing list > nmrg@irtf.org > https://www.irtf.org/mailman/listinfo/nmrg From nobody Mon Oct 27 17:41:07 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 020DC1A03D0 for ; Mon, 27 Oct 2014 17:41:06 -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 DACGknmZj2qD for ; Mon, 27 Oct 2014 17:41:04 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 079581A0360 for ; Mon, 27 Oct 2014 17:41:04 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id lf10so4096232pab.4 for ; Mon, 27 Oct 2014 17:41:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=QFPvB9jHANyj8QSvhJOzbiWi7B1quARcMCu1B0pK9P0=; b=Rt6IwKFhELHR4AXLa6IhFvwvIif2wa4z2HSQ0MA/1W/v1jQKJGNdKBA9X4ixxU06uy LwNCEZWCNXYuu4QQaYLjInmCTi4tg31lT+UdzhcDm27+kF3vvcSMnyvLdBFJH1GPdvqi oPPS7eDNv7VMRLnSvemRBvVo40XHJ/e/nCsWSJVm2/YDmPPuOCcTmkkpexjBL5Z1jNkA mWBroUq4A5kzhm3De1Rvt/glZKhwZKgrdAvt2dEwga1lpu6vwu9ZI7GAJM8HV3VMkSeb mAGS1R1wjcTWWDLKV/XxuEnyQS3d450tgj4be7EkTOcyzfRiayksgL21z86YBjhdrc8n OKOA== X-Received: by 10.70.35.229 with SMTP id l5mr27268799pdj.47.1414456863630; Mon, 27 Oct 2014 17:41:03 -0700 (PDT) Received: from [192.168.178.23] (142.193.69.111.dynamic.snap.net.nz. [111.69.193.142]) by mx.google.com with ESMTPSA id x13sm11932346pdk.22.2014.10.27.17.40.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Oct 2014 17:41:02 -0700 (PDT) Message-ID: <544EE61C.4070102@gmail.com> Date: Tue, 28 Oct 2014 13:41:00 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Kostas Pentikousis References: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C7ADE14@SBS2008.eict.local> In-Reply-To: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C7ADE14@SBS2008.eict.local> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/1HTvQT8E-Pw_28hLnlPin-P0h4I Cc: "draft-irtf-nmrg-autonomic-network-definitions@tools.ietf.org" , "nmrg@irtf.org" Subject: Re: [nmrg] Review of draft-irtf-nmrg-autonomic-network-definitions-04 X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 00:41:06 -0000 Kostas, Thanks for the review. I will leave the detailed issues for Michael since he is the document editor. I do want to comment on some general points in line below. On 28/10/2014 07:58, Kostas Pentikousis wrote: > Dear authors, all, > > I reviewed draft-irtf-nmrg-autonomic-network-definitions-04. > Overall, the draft is easy-to-read, but it feels more like > "original" work than the RG documents I'm familiar with. As I > mentioned in the Toronto meeting and on the list, the draft > lacks the appropriate list of "citations and references to > relevant research publications". I personally do not consider > sufficient the three references mentioned in passing ("There > is a large literature, including several useful overview > papers (e.g., [Samaan], [Movahedi], and [Dobson])"). This is not an academic research publication or a dissertation, that would require a complete literature review. I think that mentioning a few papers is really all that is called for. We did try to identify papers that seemed to survey the field. > Further, > several assumptions remain unstated (could be fixed by adding > a new section) and certain inconsistencies persist in this > revision (see below). > > In summary: If this draft is to become the reference RFC on > Autonomic Networking, Is that the goal? I see it more as a snapshot of current understanding. > more work is needed in the RG. I am sure more work is needed; hence my idea that this draft is a snapshot. > General comments: ----------------- > > The draft includes some normative-resembling language, which > may be misleading to uninitiated readers: Really? They are just normal English words and we do not cite RFC 2119, of course. And it is intended to be an Informational RFC, so I don't see any real reason for confusion. (The upper case NOT could be made lower case.) > Also, have we reached consensus in NMRG that "The goal of the > work on autonomic networking in the IETF is therefore not > just to create autonomic functions, but to define a common > infrastructure that autonomic functions can use." And, why is > an NMRG draft indicating what the IETF goal is? It's pretty common for work in the IRTF to be preparation for work in the IETF. You are correct that decisions about the IETF are taken in the IETF, so I agree that this should be rephrased to make the responsibility clear. Regards, Brian From nobody Tue Oct 28 09:16:15 2014 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC4AA1A907B for ; Tue, 28 Oct 2014 09:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, 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 wPXgK3Y9cHaG for ; Tue, 28 Oct 2014 09:16:10 -0700 (PDT) Received: from mx2.eict.de (mx2.eict.de [212.91.241.168]) by ietfa.amsl.com (Postfix) with ESMTP id 521D51A9093 for ; Tue, 28 Oct 2014 09:12:23 -0700 (PDT) Received: by mx2.eict.de (Postfix, from userid 481) id 286291FF58; Tue, 28 Oct 2014 17:12:22 +0100 (CET) Received: from mail.eict.de (mx1 [172.16.6.1]) by mx2.eict.de (Postfix) with ESMTP id 75BD01FF55; Tue, 28 Oct 2014 17:12:21 +0100 (CET) Received: from sbs2008.eict.local (sbs2008.intern.eict.de [192.168.2.11]) by mail.eict.de (Postfix) with ESMTP id 246D83783FD; Tue, 28 Oct 2014 17:12:21 +0100 (CET) Received: from SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298]) by SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298%13]) with mapi; Tue, 28 Oct 2014 17:12:21 +0100 From: Kostas Pentikousis To: Lisandro Zambenedetti Granville , "nmrg@irtf.org" Date: Tue, 28 Oct 2014 17:12:20 +0100 Thread-Topic: [nmrg] Planning the next NMRG meetings for 2015 Thread-Index: Ac/whf/xsIpsVFzBQWy1GZXUZfq8BwCQVZZQ Message-ID: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C7ADE6A@SBS2008.eict.local> References: <84675BAA8C49154AB81E2587BE8BDF832348E297@FR711WXCHMBA07.zeu.alcatel-lucent.com> In-Reply-To: <84675BAA8C49154AB81E2587BE8BDF832348E297@FR711WXCHMBA07.zeu.alcatel-lucent.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/Z3_S0SM787M4vG8nxIqxpcEnlI8 Subject: Re: [nmrg] Planning the next NMRG meetings for 2015 X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 16:16:13 -0000 SGkgTGlzYW5kcm8sIGFsbCwNCg0KfCAtLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0t DQp8IFZvbjogUGFwYWRpbWl0cmlvdSwgRGltaXRyaSAoRGltaXRyaSkNCnwgW21haWx0bzpkaW1p dHJpLnBhcGFkaW1pdHJpb3VAYWxjYXRlbC1sdWNlbnQuY29tXQ0KfCBHZXNlbmRldDogU2Ftc3Rh ZywgMjUuIE9rdG9iZXIgMjAxNCAxMjo1Ng0KfCBBbjogTGlzYW5kcm8gWmFtYmVuZWRldHRpIEdy YW52aWxsZTsgbm1yZ0BpcnRmLm9yZw0KfCBCZXRyZWZmOiBSZTogW25tcmddIFBsYW5uaW5nIHRo ZSBuZXh0IE5NUkcgbWVldGluZ3MgZm9yIDIwMTUNCnwgDQp8IEhlbGxvLA0KfCANCnwgSSB3b3Vs ZCBsaWtlIHRvIHNlZSB0aGUgbGlzdCBleHRlbmRlZCB0byB0aGUgZm9sbG93aW5nIHRvcGljczoN CnwgDQp8IG8pIGluZm9ybWF0aW9uL2NvbnRlbnQgbmV0d29ya3MgbWFuYWdlbWVudA0KDQpJJ2Qg bGlrZSB0byBzZWNvbmQgRGltaXRyaSBvbiB0aGlzIG9uZS4NCg0KQmFjayBpbiBJRVRGIDg2ICho dHRwczovL3RyYWMudG9vbHMuaWV0Zi5vcmcvZ3JvdXAvaXJ0Zi90cmFjL3dpa2kvTmV0d29ya01h bmFnZW1lbnRSZXNlYXJjaEdyb3VwQWcmTGdPcmxhbmRvKSB3ZSBwcmVzZW50ZWQgYW4gZWFybGll ciB2ZXJzaW9uIG9mIGRyYWZ0LWNvcnVqby1pY24tbWdtdCAoaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtY29ydWpvLWljbi1tZ210LykuIEFsdGhvdWdoIHRoZSBkcmFmdCBo YXMgYmVlbiBmdXJ0aGVyIGRldmVsb3BlZCBzaW5jZSB0aGVuLCBtb3JlIHdvcmsgaXMgZm9yZXNl ZW4gYW5kIHdlIHdvdWxkIGJlIGhhcHB5IHRvIGhhdmUgTk1SRyBtZW1iZXJzIHJldmlldyBhbmQg Y29udHJpYnV0ZS4NCg0KVGhlcmUgYXJlIHR3byBhc3BlY3RzIHRoYXQgZm9sa3MgbWF5IGJlIGlu dGVyZXN0ZWQgaW4gdGhpcyBkaXJlY3Rpb24uIEZpcnN0LCBtYW5hZ2VtZW50IG9mIGFuIGluZm9y bWF0aW9uLWNlbnRyaWMgbmV0d29yay4gVGhlcmUgd2FzIGVhcmxpZXIgd29yayBpbiBGUDcgNFdB UkQsIGJ1dCBJJ20gc3VyZSBvdGhlcnMgaGF2ZSBkb25lIHdvcmsgaW4gdGhpcyBkaXJlY3Rpb24g c2luY2UgdGhlbi4gU2Vjb25kLCBpdCdzIHZlcnkgaW50ZXJlc3RpbmcgdG8gc2VlIGhvdyBJQ04g Y2FuIGJlIHVzZWQgdG8gbWFuYWdlIG5ldHdvcmtzLiBUaGUgYmVzdCBwYXBlciB3aW5uZXIgb2Yg U0lHQ09NTSBJQ04gMjAxNCwgYnkgQXJ1bWFpdGh1cmFpIGV0IGFsLiBlbnRpdGxlZCAiRXhwbG9p dGluZyBJQ04gZm9yIEZsZXhpYmxlIE1hbmFnZW1lbnQgaW4gU29mdHdhcmUtRGVmaW5lZCBOZXR3 b3JrcyIgd291bGQgYmUgYW4gZXhjZWxsZW50IGV4YW1wbGUgb2YgdGhpcyBsYXR0ZXIgY2F0ZWdv cnkuIGRyYWZ0LWNvcnVqby1pY24tbWdtdCBkaXNjdXNzZXMgdG8gc29tZSBkZWdyZWUgYm90aCBh c3BlY3RzLCBidXQgSSdtIHN1cmUgdGhlcmUncyBsb3RzIG9mIHNwYWNlIGZvciBvdGhlciBkcmFm dHMgaW4gTk1SRyBpbiB0aGlzIGFyZWEuDQoNCjxzbmlwPg0KfCBNb3JlIGdlbmVyYWxseSwgaXQg c2VlbXMgYWR2aXNhYmxlIHRvIGtlZXAgYSBtb3JlIHRlY2hub2xvZ3ktDQp8IGluZGVwZW5kZW50 IGFwcHJvYWNoLCBmb3IgaW5zdGFuY2UgaW5zdGVhZCBvZiB0YXJnZXRpbmcgIk5GViIgb3INCnwg c2ltaWxhciwgZm9jdXMgb24gZnVuY3Rpb24gcGxhY2VtZW50IHByb2JsZW1zLCBmdW5jdGlvbmFs LWFic3RyYWN0aW9uDQp8IGFuZCBuZXR3b3JrLWZ1bmN0aW9uIGRyaXZlbiBtYW5hZ2VtZW50Lg0K DQpTZWNvbmQgdGhpcyB0b28sIGFsdGhvdWdoIHNvbWUgTkZWLW1hbmFnZW1lbnQgc3BlY2lmaWMg ZHJhZnRzIGNvdWxkIGJlIGRvbmUgaW4gTk1SRyBvciBpbiBjbG9zZSBjb29wZXJhdGlvbiB3aXRo IHRoZSBwcm9wb3NlZCBORlZSRy4NCg0KUmVnYXJkaW5nIHRoZSBtZWV0aW5nczogV2hhdCB3b3Jr ZWQgd2VsbCBpbiBJQ05SRyBmb3Igc29tZSB0aW1lIG5vdyB3YXMgdG8gc2NoZWR1bGUgYSBmdWxs IGRheSBtZWV0aW5nIGFuZCB3b3JrIG9uIFJHIGRyYWZ0cyB0b2dldGhlciAob3IgaW4gc3BsaXQg Z3JvdXBzKSBkdXJpbmcgdGhlIElFVEYgd2VlayAoZS5nLiBvbiBTdW5kYXkpLiBUaGlzIGNvdWxk IGJlIHNlZW4gYXMgYSBwYXJ0aWN1bGFyIGZvcm0gb2YgYSBkZXNpZ24gdGVhbSAod2l0aG91dCB0 aGUgcHJvdG9jb2wgZGV2ZWxvcG1lbnQpIGFuZCBjYW4gaGVscCByZWFjaCBjb25zZW5zdXMgb24g Y29tcHJlaGVuc2l2ZSBoaWdoLXF1YWxpdHkgUkcgZHJhZnRzLg0KDQpCZXN0IHJlZ2FyZHMsDQoN Cktvc3Rhcw0K