From nobody Sat Sep 6 08:28: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 7E3621A02D1 for ; Sat, 6 Sep 2014 08:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.303 X-Spam-Level: X-Spam-Status: No, score=-1.303 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-1.652] 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 rYoyb3W6H-bR for ; Sat, 6 Sep 2014 08:28:51 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 816CF1A0450 for ; Sat, 6 Sep 2014 08:28:51 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id CA7A212C6 for ; Sat, 6 Sep 2014 17:28:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id RjIwnO9uw4FY for ; Sat, 6 Sep 2014 17:28:45 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Sat, 6 Sep 2014 17:28:49 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 13B4420036 for ; Sat, 6 Sep 2014 17:28:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id vgR5Ve5ZLDuK for ; Sat, 6 Sep 2014 17:28:48 +0200 (CEST) Received: from exchange.jacobs-university.de (shubcas03.jacobs.jacobs-university.de [10.70.0.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "exchange.jacobs-university.de", Issuer "Jacobs University CA - G01" (not verified)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 569D120035 for ; Sat, 6 Sep 2014 17:28:48 +0200 (CEST) Received: from SXCHMB01.jacobs.jacobs-university.de ([fe80::c1f:c30f:99ac:df0c]) by SHUBCAS05.jacobs.jacobs-university.de ([::1]) with mapi id 14.03.0195.001; Sat, 6 Sep 2014 17:28:48 +0200 From: "Bajpai, Vaibhav" To: "nmrg@irtf.org" Thread-Topic: 31st NMRG meeting - 1st NMRG workshop on large scale network measurements Thread-Index: AQHPyedAT+ElBebYJ0mlH1qul3dbvQ== Date: Sat, 6 Sep 2014 15:28:47 +0000 Message-ID: <542F18B0-F224-4369-A088-BAB33FF63953@jacobs-university.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.50.203.30] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/fP5ESGDb00NOBXvUZW4JCLzUQtk Subject: [nmrg] 31st NMRG meeting - 1st NMRG workshop on large scale network measurements 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, 06 Sep 2014 15:28:53 -0000 NMRG, > From: nmrg-bounces@irtf.org [mailto:nmrg-bounces@irtf.org] On Behalf Of J= uergen Schoenwaelder > Sent: Sunday, September 08, 2013 6:46 PM > To: nmrg@irtf.org > Subject: [nmrg] 31st NMRG meeting - 1st NMRG workshop on large scale netw= ork measurements >=20 > 1st Workshop on Large Scale Network Measurements > (31st NMRG meeting) >=20 > Location: Zurich, Switzerland (co-located with CNSM 2013 [1]) > Date: Monday, October 14 > Deadline: Friday, September 20 A report summarising the topics discussed at ^ workshop is now available on= line: http://dx.doi.org/10.1007/s10922-014-9328-2 Best, Vaibhav ----------------------------------------------------- Vaibhav Bajpai Research I, Room 91 Computer Networks and Distributed Systems (CNDS) Lab School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com= From nobody Mon Sep 8 05:51:12 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 683BB1A87AD for ; Mon, 8 Sep 2014 05:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.452 X-Spam-Level: X-Spam-Status: No, score=-13.452 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q_o0YooEhyN2 for ; Mon, 8 Sep 2014 05:51:09 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFC751A8799 for ; Mon, 8 Sep 2014 05:51:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8064; q=dns/txt; s=iport; t=1410180669; x=1411390269; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=X2Y2OteyVmc1KWyQvcx4WwRKErl7N4WRQg5vOPOTxGo=; b=Xfh4FuFIsDF3+wJWC1j2uttfTU0hcGwCxNvkBtoa5MG7ztiijPDy9NnW 4PthFjneWsHPPI0d3rnQZKAFIe2r0rRlHTQSIEivi2pojlWVPfxc2w4jN M7heBFmeqPTD4rvdSX4p+vdJJB4WQX6I3l5CafCRIeuUCzm1ZQEZZM+4j o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AokGAIqlDVStJssW/2dsb2JhbABZg2BXiFfBEwEJh0wBgSh4hAQBAQQBAQFrChELIRYPCQMCAQIBFTAGDQYCAQEXiCcNumsBEwSNPYIXhEwBBJxyh0GNa4NjOy+CTwEBAQ X-IronPort-AV: E=Sophos;i="5.04,486,1406592000"; d="scan'208,217";a="170698645" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 08 Sep 2014 12:51:06 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s88Cp5hf005960 for ; Mon, 8 Sep 2014 12:51:05 GMT Message-ID: <540DA639.8080702@cisco.com> Date: Mon, 08 Sep 2014 14:51:05 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: "nmrg@irtf.org" References: <53CD5D41.6050302@cisco.com> In-Reply-To: <53CD5D41.6050302@cisco.com> Content-Type: multipart/alternative; boundary="------------040107000309080306020404" Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/WiInEPszBd91pMuRaVLyxZF_6NA Subject: Re: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01 feedback 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, 08 Sep 2014 12:51:11 -0000 This is a multi-part message in MIME format. --------------040107000309080306020404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Thanks for addressing my concerns in the version 3 of the draft-irtf-nmrg-autonomic-network-definitions. Minor point, as mentioned below: I would have put the automatic definition directly in draft-irtf-nmrg-autonomic-network-definitions. o Automatic: A process that occurs without human intervention, with step-by-step execution of rules. However it relies on humans defining the sequence of rules, so is not Autonomic in the full sense. For example, a start-up script is automatic but not autonomic. Regards, Benoit > Dear all, > > - Make it clear that the definition means a logical OR > Autonomic: Self-managing (self-configuring, self-protecting, self- > healing and self-optimizing); however, allowing high-level guidance > by a central entity, through intent. > - > Intent: An abstract, high level policy used to operate the network > autonomically. Its scope is an autonomic domain, such as an > enterprise network._It does not contain configuration or information > for a specific node._ It may contain information pertaining to nodes > with a specific role. > > Well in the end, configuration or information for a specific node will be involved. > I guess you want to rephrase that the intent is a general policy above configuration or information for a specific node, dealing with the intent you want to have from the network. > > - When I read "It requires no configuration" in ... > > Autonomic Function: A feature or function which requires no > configuration, and can derive all required information either through > self-knowledge, discovery or through intent. > > OR > > Fully Autonomic Node: A node which employs exclusively autonomic > functions. It requires no configuration. > > ... I wondered about an initial configuration before a device is shipped. Autonomic or not? > Coincidently, this was just discussed at the time of typing these lines, by Brian, presenting in NMRG. > I understand that this is automatic, right? > And I see a extra definition in draft-irtf-nmrg-an-gap-analysis-00 > > o Automatic: A process that occurs without human intervention, with > step-by-step execution of rules. However it relies on humans > defining the sequence of rules, so is not Autonomic in the full > sense. For example, a start-up script is automatic but not > autonomic. > > draft-irtf-nmrg-autonomic-network-definitions would benefit from this definition in my opinion, and a few words on the difference between autonomic and automatic > > - > Northbound interface. These days, with the SDN/controller story, this is a confusing term. > I would rephrase the section and the text inside > OLD: > 3.4. Simplification of the Northbound Interfaces > OLD: > 3.4. Simplification of the Autonomic Node Northbound Interfaces > > - > 3.7 Modularity > Section 3 intro says: > > This section explains the high level goals of Autonomic Networking, > independent of any specific solutions. > > Is this an Autonomic Networking design goal to be modular? Not really > I see this more like a good deployment practice, i.e. if you think about an autonomic protocol, please think of deployment, i.e. modularity > > Regards, Benoit > > > > _______________________________________________ > nmrg mailing list > nmrg@irtf.org > https://www.irtf.org/mailman/listinfo/nmrg --------------040107000309080306020404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear all,

Thanks for addressing my concerns in the version 3 of the draft-irtf-nmrg-autonomic-network-definitions.
Minor point, as mentioned below: I would have put the automatic definition directly in draft-irtf-nmrg-autonomic-network-definitions.
  o  Automatic: A process that occurs without human intervention, with
      step-by-step execution of rules.  However it relies on humans
      defining the sequence of rules, so is not Autonomic in the full
      sense.  For example, a start-up script is automatic but not
      autonomic.

Regards, Benoit
Dear all,

- Make it clear that the definition means a logical OR
   Autonomic: Self-managing (self-configuring, self-protecting, self-
   healing and self-optimizing); however, allowing high-level guidance
   by a central entity, through intent.
- 
   Intent: An abstract, high level policy used to operate the network
   autonomically.  Its scope is an autonomic domain, such as an
   enterprise network.  It does not contain configuration or information
   for a specific node.  It may contain information pertaining to nodes
   with a specific role.

Well in the end, configuration or information for a specific node will be involved.
I guess you want to rephrase that the intent is a general policy above configuration or information for a specific node, dealing with the intent you want to have from the network.

-  When I read "It requires no configuration" in ...

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

   OR

   Fully Autonomic Node: A node which employs exclusively autonomic
   functions.  It requires no configuration.

... I wondered about an initial configuration before a device is shipped. Autonomic or not?
Coincidently, this was just discussed at the time of typing these lines, by Brian, presenting in NMRG.
I understand that this is automatic, right?
And I see a extra definition in draft-irtf-nmrg-an-gap-analysis-00

  o  Automatic: A process that occurs without human intervention, with
      step-by-step execution of rules.  However it relies on humans
      defining the sequence of rules, so is not Autonomic in the full
      sense.  For example, a start-up script is automatic but not
      autonomic.

draft-irtf-nmrg-autonomic-network-definitions would benefit from this definition in my opinion, and a few words on the difference between autonomic and automatic

-
Northbound interface. These days, with the SDN/controller story, this is a confusing term. 
I would rephrase the section and the text inside
OLD: 
3.4.  Simplification of the Northbound Interfaces
OLD: 
3.4.  Simplification of the Autonomic Node Northbound Interfaces

- 
3.7 Modularity
Section 3 intro says:

   This section explains the high level goals of Autonomic Networking,
   independent of any specific solutions.

Is this an Autonomic Networking design goal to be modular? Not really
I see this more like a good deployment practice, i.e. if you think about an autonomic protocol, please think of deployment, i.e. modularity

Regards, Benoit




_______________________________________________
nmrg mailing list
nmrg@irtf.org
https://www.irtf.org/mailman/listinfo/nmrg

--------------040107000309080306020404-- From nobody Mon Sep 8 07:06:03 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 AFDBE1A0371 for ; Mon, 8 Sep 2014 07:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.152 X-Spam-Level: X-Spam-Status: No, score=-16.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8Zwb-PVqGuK for ; Mon, 8 Sep 2014 07:05:43 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AA291A87E7 for ; Mon, 8 Sep 2014 07:05:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21992; q=dns/txt; s=iport; t=1410185143; x=1411394743; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=W3K9pAmsSNZHWesEtKRC+T4P5iwmBdrtHTxog2TZNDU=; b=jUXT7fwbT7MazmyVDkQOPOB1o6tHoS1MXoK4JOFQIjRi2FQQiTtnW4lJ YN4LUHnrpZ/O+052aacoM6EfvWeaVtwInUggjNLxm7BFeXOOAwJHoR75V sv5q3zEEpTPxWFA7ufZ29ycGhP3ftCw0xYTzn4BKGNeNi/wUFAVgWAu3q w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoFAAS3DVStJV2P/2dsb2JhbABZgkdGU1cEyWYBCYdMAYEQFniEAwEBAQQBAQEqQRsCAQgRBAEBCxYHBycLFAkIAgQBEggTiCcNum4BEwSNPYFfLQoBgy+BHQWPK4IVoF6DYWyBSIEHAQEB X-IronPort-AV: E=Sophos; i="5.04,486,1406592000"; d="scan'208,217"; a="75929626" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-3.cisco.com with ESMTP; 08 Sep 2014 14:05:41 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s88E5ffv008684 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 8 Sep 2014 14:05:41 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.204]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Mon, 8 Sep 2014 09:05:41 -0500 From: "Michael Behringer (mbehring)" To: "Benoit Claise (bclaise)" , "nmrg@irtf.org" Thread-Topic: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01 feedback Thread-Index: AQHPpRJ4n42notfsnEKKX2aXPrYPepv30MeA///A8pA= Date: Mon, 8 Sep 2014 14:05:40 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF21C33119@xmb-rcd-x14.cisco.com> References: <53CD5D41.6050302@cisco.com> <540DA639.8080702@cisco.com> In-Reply-To: <540DA639.8080702@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.134] Content-Type: multipart/alternative; boundary="_000_3AA7118E69D7CD4BA3ECD5716BAF28DF21C33119xmbrcdx14ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/_hihn86hnXta7QbMOsHM0mxwR5Y Subject: Re: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01 feedback 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, 08 Sep 2014 14:05:51 -0000 --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF21C33119xmbrcdx14ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Must have slipped through. I'll include it in the next version. Michael From: nmrg [mailto:nmrg-bounces@irtf.org] On Behalf Of Benoit Claise (bclai= se) Sent: 08 September 2014 14:51 To: nmrg@irtf.org Subject: Re: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01 feedba= ck Dear all, Thanks for addressing my concerns in the version 3 of the draft-irtf-nmrg-a= utonomic-network-definitions. Minor point, as mentioned below: I would have put the automatic definition = directly in draft-irtf-nmrg-autonomic-network-definitions. o Automatic: A process that occurs without human intervention, with step-by-step execution of rules. However it relies on humans defining the sequence of rules, so is not Autonomic in the full sense. For example, a start-up script is automatic but not autonomic. Regards, Benoit Dear all, - Make it clear that the definition means a logical OR Autonomic: Self-managing (self-configuring, self-protecting, self- healing and self-optimizing); however, allowing high-level guidance by a central entity, through intent. - Intent: An abstract, high level policy used to operate the network autonomically. Its scope is an autonomic domain, such as an enterprise network. It does not contain configuration or information for a specific node. It may contain information pertaining to nodes with a specific role. Well in the end, configuration or information for a specific node will be i= nvolved. I guess you want to rephrase that the intent is a general policy above conf= iguration or information for a specific node, dealing with the intent you w= ant to have from the network. - When I read "It requires no configuration" in ... Autonomic Function: A feature or function which requires no configuration, and can derive all required information either through self-knowledge, discovery or through intent. OR Fully Autonomic Node: A node which employs exclusively autonomic functions. It requires no configuration. ... I wondered about an initial configuration before a device is shipped. A= utonomic or not? Coincidently, this was just discussed at the time of typing these lines, by= Brian, presenting in NMRG. I understand that this is automatic, right? And I see a extra definition in draft-irtf-nmrg-an-gap-analysis-00 o Automatic: A process that occurs without human intervention, with step-by-step execution of rules. However it relies on humans defining the sequence of rules, so is not Autonomic in the full sense. For example, a start-up script is automatic but not autonomic. draft-irtf-nmrg-autonomic-network-definitions would benefit from this defin= ition in my opinion, and a few words on the difference between autonomic an= d automatic - Northbound interface. These days, with the SDN/controller story, this is a = confusing term. I would rephrase the section and the text inside OLD: 3.4. Simplification of the Northbound Interfaces OLD: 3.4. Simplification of the Autonomic Node Northbound Interfaces - 3.7 Modularity Section 3 intro says: This section explains the high level goals of Autonomic Networking, independent of any specific solutions. Is this an Autonomic Networking design goal to be modular? Not really I see this more like a good deployment practice, i.e. if you think about an= autonomic protocol, please think of deployment, i.e. modularity Regards, Benoit _______________________________________________ nmrg mailing list nmrg@irtf.org https://www.irtf.org/mailman/listinfo/nmrg --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF21C33119xmbrcdx14ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Must have slipped through. I’ll include it= in the next version.

=  

= Michael

=  

= From: nmrg [mailto:nmrg-bounces@irtf.org] On= Behalf Of Benoit Claise (bclaise)
Sent: 08 September 2014 14:5= 1
To: nmrg@irtf.org
Subject: Re: [nmrg] draft-ir= tf-nmrg-autonomic-network-definitions-01 feedback<= /p>

 

Dear all,

Thanks for addressing my concerns in the version 3 of the draft-irtf-nmrg-a= utonomic-network-definitions.
Minor point, as mentioned below: I would have put the automatic definition = directly in draft-irtf-nmrg-autonomic-network-definitions.

 
  o  Automatic: A process that occurs without hu=
man intervention, with
      step-by-step execution of r=
ules.  However it relies on humans
      defining the sequence of ru=
les, so is not Autonomic in the full
      sense.  For example, a=
 start-up script is automatic but not
      autonomic.


Regards, Benoit

Dear all,

- Make it clear that the definition means a logical OR

   Autonomic: Self-managing (self-configuring, s=
elf-protecting, self-
   healing and self-optimizing); however, allowi=
ng high-level guidance
   by a central entity, through intent.

- 

   Intent: An abstract, high level policy u=
sed to operate the network
   autonomically.  Its scope is an autonomi=
c domain, such as an
   enterprise network.  It does not cont=
ain configuration or information
   for a specific node. &=
nbsp;It may contain information pertaining to nodes
   with a specific role.
 
Well in the end, configuration or information for a specif=
ic node will be involved.
I guess you want to rephrase that the intent is a general =
policy above configuration or information for a specific node, dealing with=
 the intent you want to have from the network.

 


-  When I read "It requires no configuration&quo=
t; in ...


 


   Autonomic Function: A feature or function whi=
ch requires no


   configuration, and can derive all required in=
formation either through


   self-knowledge, discovery or through intent.<=
o:p>


 


   OR


 


   Fully Autonomic Node: A node which employs ex=
clusively autonomic


   functions.  It requires no configuration=
.


 


... I wondered about an initial configuration before a dev=
ice is shipped. Autonomic or not?


Coincidently, this was just discussed at the time of typin=
g these lines, by Brian, presenting in NMRG.


I understand that this is automatic, right?


And I see a extra definition in draft-irtf-nmrg-an-gap-ana=
lysis-00


 


  o  Automatic: A process that occurs without hu=
man intervention, with


      step-by-step execution of r=
ules.  However it relies on humans


      defining the sequence of ru=
les, so is not Autonomic in the full


      sense.  For example, a=
 start-up script is automatic but not


      autonomic.


 


draft-irtf-nmrg-autonomic-network-definitions would benefi=
t from this definition in my opinion, and a few words on the difference bet=
ween autonomic and automatic


 


-


Northbound interface. These days, with the SDN/controller =
story, this is a confusing term. 


I would rephrase the section and the text inside


OLD: 


3.4.  Simplification of the Northbound Interfaces


OLD: 


3.4.  Simplification of the Autonomic Node Northbound=
 Interfaces


 


- 


3.7 Modularity


Section 3 intro says:


 


   This section explains the high level goals of=
 Autonomic Networking,


   independent of any specific solutions.


 


Is this an Autonomic Networking design goal to be modular?=
 Not really


I see this more like a good deployment practice, i.e. if y=
ou think about an autonomic protocol, please think of deployment, i.e. modu=
larity


 


Regards, Benoit


 











_______________________________________________=



nmrg mailing list


nmrg@irtf.org


htt=
ps://www.irtf.org/mailman/listinfo/nmrg

 

--_000_3AA7118E69D7CD4BA3ECD5716BAF28DF21C33119xmbrcdx14ciscoc_-- From nobody Wed Sep 24 13:39:29 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 D4A3C1A0398 for ; Wed, 24 Sep 2014 13:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GiPk-wKDJfP for ; Wed, 24 Sep 2014 13:39:19 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 209281A19E9 for ; Wed, 24 Sep 2014 13:38:20 -0700 (PDT) Received: by mail-pa0-f50.google.com with SMTP id lj1so960939pab.9 for ; Wed, 24 Sep 2014 13:38:19 -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=svJey9Qv/B2ieVIcuw3JP7hJ5moRX0IgHwHCC/A4B1E=; b=e2J8o+K94yiFG4nf+D8jV1lNafxq5B0jGYUsd8+zO+MgJ7o3fNewWIuvXB2pHrCswV NJ3yEW9ykW+sI6szmqT8VVZ2njjMelc28kIwNik1Lt4eihR6YVupH6aCgwmSA38Pwnmf cAyPVGTxfrDKTWXs12MLIr7OU+AN+MpWwoHrJueAvfhLs8zBJ/fw3srhTmx7kH3I95gd ATDRWyfZ+m18K7NssNzrKFnOcc6Ei7pgDnCyIONQxgSL1cZKbxTdNnnaRhVbIzGFrr1J 3vAGxW8wMML2yDhA84xPvNL6BHVL5ErkOeIJv5NzrzpyjWk2Aqs6CBxYMlDaLmA1ye3/ 4F3A== X-Received: by 10.70.127.131 with SMTP id ng3mr15755683pdb.31.1411591099798; Wed, 24 Sep 2014 13:38:19 -0700 (PDT) Received: from [192.168.178.23] (163.199.69.111.dynamic.snap.net.nz. [111.69.199.163]) by mx.google.com with ESMTPSA id dg9sm163909pdb.50.2014.09.24.13.38.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Sep 2014 13:38:18 -0700 (PDT) Message-ID: <54232BBD.2090107@gmail.com> Date: Thu, 25 Sep 2014 08:38:21 +1200 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=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/seK1oO23eC1-dwfoaCZ_5LmTaeE Subject: [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: Wed, 24 Sep 2014 20:39:22 -0000 Hi, The authors of draft-irtf-nmrg-autonomic-network-definitions-03 and draft-irtf-nmrg-an-gap-analysis-01 have received very detailed reviews by Ren Struik over on the anima@ietf.org list, and we will soon produce new versions accordingly. We'd really like to get final comments from all NMRG participants as soon as possible (like within a week!), since we want to move these drafts forward. Thanks in advance, Brian Carpenter From nobody Mon Sep 29 06:41: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 7E9D51A1AE4 for ; Mon, 29 Sep 2014 06:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, 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 ZZUfSu8GCSKU for ; Mon, 29 Sep 2014 06:41:51 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECD2A1A1A6E for ; Mon, 29 Sep 2014 06:41:50 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 723F4752 for ; Mon, 29 Sep 2014 15:41:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id AB6vhlesPN7z for ; Mon, 29 Sep 2014 15:41:48 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Mon, 29 Sep 2014 15:41:48 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id DFF5920036 for ; Mon, 29 Sep 2014 15:41:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id LnBw23ooYy-J; Mon, 29 Sep 2014 15:41:47 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3EBC220035; Mon, 29 Sep 2014 15:41:48 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E484E2EA8B21; Mon, 29 Sep 2014 15:41:46 +0200 (CEST) Date: Mon, 29 Sep 2014 15:41:46 +0200 From: Juergen Schoenwaelder To: nmrg@irtf.org Message-ID: <20140929134144.GA77841@elstar.local> Mail-Followup-To: nmrg@irtf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/Ygu5uhVPsj3P48zzfF6RvbUAg9U Subject: [nmrg] 35th nmrg meeting in Rio de Janeiro X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 13:41:54 -0000 Hi, I have seen but I do not recall having seen any discussion of this meeting on this mailing list. Note that November 17th is Monday after the IETF meeting in Honolulu. I am wondering which process is used to determine future NMRG meetings... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Sep 29 06:55: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 946041A6FAE for ; Mon, 29 Sep 2014 06:55:18 -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 1FcaPIH_su82 for ; Mon, 29 Sep 2014 06:55:16 -0700 (PDT) Received: from puma.inf.ufrgs.br (puma.inf.ufrgs.br [143.54.11.5]) by ietfa.amsl.com (Postfix) with ESMTP id 185B21A6FAB for ; Mon, 29 Sep 2014 06:55:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by puma.inf.ufrgs.br (Postfix) with ESMTP id CA62C61D37; Mon, 29 Sep 2014 10:55:13 -0300 (BRT) Received: from air-de-lisandro.rnp.local (host56.na-df.rnp.br [200.130.78.56]) by puma.inf.ufrgs.br (Postfix) with ESMTP id A846561D36; Mon, 29 Sep 2014 10:55:11 -0300 (BRT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Lisandro Zambenedetti Granville In-Reply-To: <20140929134144.GA77841@elstar.local> Date: Mon, 29 Sep 2014 10:55:13 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140929134144.GA77841@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/8rwb5NlOBzeLEjbIGTDgGdD3JlE Cc: nmrg@irtf.org Subject: Re: [nmrg] 35th nmrg meeting in Rio de Janeiro 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, 29 Sep 2014 13:55:18 -0000 Hello Juergen The original plan is to have, along a year, 3 meetings together with = IETF in addition to an interim meeting. That happened perfectly last = year, having that interim meeting you organized in CNSM 2013. This year, = however, because CNSM 2014 happens the week immediately after IETF 91, = we will have only NMRG meeting on CNSM, skipping IETF 91.=20 Best regards, Lisandro and Olivier Em 29/09/2014, =E0(s) 10:41, Juergen Schoenwaelder = escreveu: > Hi, >=20 > I have seen but I do not > recall having seen any discussion of this meeting on this mailing > list. Note that November 17th is Monday after the IETF meeting in > Honolulu. I am wondering which process is used to determine future > NMRG meetings... >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > nmrg mailing list > nmrg@irtf.org > https://www.irtf.org/mailman/listinfo/nmrg From nobody Mon Sep 29 07:05:52 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 5AB871A1AFF for ; Mon, 29 Sep 2014 07:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, 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 tOGgRF7fN5in for ; Mon, 29 Sep 2014 07:05:48 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56C691A1AE4 for ; Mon, 29 Sep 2014 07:05:48 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 266E471A; Mon, 29 Sep 2014 16:05:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id o6BzmGckV4fA; Mon, 29 Sep 2014 16:05:46 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 29 Sep 2014 16:05:46 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 919FF20035; Mon, 29 Sep 2014 16:05:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id MjCwWmGQRHcb; Mon, 29 Sep 2014 16:05:46 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 55CD920037; Mon, 29 Sep 2014 16:05:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2DB302EA8C83; Mon, 29 Sep 2014 16:05:42 +0200 (CEST) Date: Mon, 29 Sep 2014 16:05:42 +0200 From: Juergen Schoenwaelder To: Lisandro Zambenedetti Granville Message-ID: <20140929140540.GA78151@elstar.local> Mail-Followup-To: Lisandro Zambenedetti Granville , nmrg@irtf.org References: <20140929134144.GA77841@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/Jnxn0tgB2gZtxgIxjL4MPdxnx7U Cc: nmrg@irtf.org Subject: Re: [nmrg] 35th nmrg meeting in Rio de Janeiro X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 14:05:50 -0000 So who is deciding things and how? Is it decided for the NMRG or does the RG have a way to participate in the decision making? Should the RG not at least be made aware first hand of meeting decisions taken? /js On Mon, Sep 29, 2014 at 10:55:13AM -0300, Lisandro Zambenedetti Granville wrote: > Hello Juergen > > The original plan is to have, along a year, 3 meetings together with IETF in addition to an interim meeting. That happened perfectly last year, having that interim meeting you organized in CNSM 2013. This year, however, because CNSM 2014 happens the week immediately after IETF 91, we will have only NMRG meeting on CNSM, skipping IETF 91. > > Best regards, > > Lisandro and Olivier > > Em 29/09/2014, à(s) 10:41, Juergen Schoenwaelder escreveu: > > > Hi, > > > > I have seen but I do not > > recall having seen any discussion of this meeting on this mailing > > list. Note that November 17th is Monday after the IETF meeting in > > Honolulu. I am wondering which process is used to determine future > > NMRG meetings... > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > nmrg mailing list > > nmrg@irtf.org > > https://www.irtf.org/mailman/listinfo/nmrg > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Sep 29 08:02: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 CFFF71A876F for ; Mon, 29 Sep 2014 08:02:16 -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 T9A5p4J1vTjD for ; Mon, 29 Sep 2014 08:02:13 -0700 (PDT) Received: from mx2.eict.de (mx2.eict.de [212.91.241.168]) by ietfa.amsl.com (Postfix) with ESMTP id A4B611A6FAE for ; Mon, 29 Sep 2014 08:02:12 -0700 (PDT) Received: by mx2.eict.de (Postfix, from userid 481) id 8F2131FF58; Mon, 29 Sep 2014 17:02:11 +0200 (CEST) Received: from mail.eict.de (mx1 [172.16.6.1]) by mx2.eict.de (Postfix) with ESMTP id 01F861FF55; Mon, 29 Sep 2014 17:02:11 +0200 (CEST) Received: from sbs2008.eict.local (sbs2008.intern.eict.de [192.168.2.11]) by mail.eict.de (Postfix) with ESMTP id A09B23782F8; Mon, 29 Sep 2014 17:02:10 +0200 (CEST) Received: from SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298]) by SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298%13]) with mapi; Mon, 29 Sep 2014 17:02:10 +0200 From: Kostas Pentikousis To: Parviz Yegani , Georgios Karagiannis Date: Mon, 29 Sep 2014 17:02:09 +0200 Thread-Topic: [Supa] New SUPA charter Thread-Index: Ac/ahWvRdCpLkwMuTtyyGHVJ39XOQQBbfr/g Message-ID: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C72ADDE@SBS2008.eict.local> References: In-Reply-To: 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/sZnraMWYhPFT1MLrkZpNZB1uwYQ Cc: "nmrg@irtf.org" , "supa@ietf.org" Subject: Re: [nmrg] [Supa] New SUPA charter 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, 29 Sep 2014 15:02:17 -0000 SGkgR2Vvcmdpb3MsDQoNCkkgc2Vjb25kIFBhcnZpeiwgaXTigJlzIG11Y2ggYmV0dGVyIGFmdGVy IHRoZSByZWNlbnQgcmV2aXNpb25zLiBBIGZldyBjb21tZW50cyB3cnQgdG8gdGhlIHZlcnNpb24g YXQgaHR0cHM6Ly9naXRodWIuY29tL2xpdXNodWNoZW5nL1NVUEEvd2lraS9TVVBBLUNoYXJ0ZXIN Cg0KRG8gd2UgbmVlZCB0aGlzIHBocmFzZTogInRvIHNoaWZ0IHRoZSBiYWxhbmNlIFtvZiBjb3N0 cz9dIGluIHRoZWlyIGZhdm9yIj8gU1VQQSBzaG91bGQgbm90IGJlIGEgemVyby1zdW0gZ2FtZS4g RXZlcnlvbmUgc2hvdWxkIGJlbmVmaXQgKHZlbmRvcnMsIG9wZXJhdG9ycywgYWRtaW5zLCB1c2Vy cywgbmV3IHNlcnZpY2UgcHJvdmlkZXJzKS4NCg0KRG8gd2UgUkVBTExZIGhhdmUgdG8gY2FwaXRh bGl6ZSBQT0xJQ1ksIFVOSUZJRUQsIFNIQVJFRCwgYW5kIEFVVE9NQVRJQ0FMTFk/IDopDQoNClRo ZSBwYXJhZ3JhcGggc3RhcnRpbmcgd2l0aCAiU29tZSBJRVRGIHdvcmtpbmcgZ3JvdXBzLi4uIiBt YXkgYmUgdXNlZnVsIHRvIG1vdGl2YXRlIGNoYXJ0ZXJpbmcgdGhlIFdHLCBidXQgSSdtIG5vdCBz dXJlIGl0IHNob3VsZCBiZSBwYXJ0IG9mIHRoZSBmaW5hbCBjaGFydGVyLg0KDQpGaW5hbGx5LCB0 aGUgbGFzdCBwYXJhZ3JhcGhzIHN0YXJ0aW5nIHdpdGggIlNVUEEgd2lsbCB3b3JrIG9uIGRlZmlu aW5nLi4uICIgYW5kIGVuZGluZyB3aXRoIHRoZSBzZWN0aW9uIG9uIFdvcmsgSXRlbXMgaGFzIGEg Yml0IG9mIG92ZXJsYXAgd2l0aCB0aGUgcmVtYWluaW5nIHRleHQgKFdvcmsgSXRlbXMsIERlbGl2 ZXJhYmxlcykuIEkgaGF2ZSBhIGZldyBtb3JlIGVkaXRvcmlhbCBjb21tZW50cyAoZS5nLiBzL3N0 YXJ0ZWQgd29yayByZWxhdGluZy9zdGFydGVkIHdvcmsgcmVsYXRlZCksIGJ1dCB3ZSBjYW4gaGFu ZGxlIHRoYXQgb2ZmbGluZS4NCg0KQmVzdCByZWdhcmRzLA0KDQpLb3N0YXMNCg0KUFM6IEkgdG9v ayB0aGUgbGliZXJ0eSB0byBDQyBOTVJHIGFzIHNvbWUgZm9sa3MgaW4gdGhhdCBncm91cCBtYXkg aGF2ZSBhbiBpbnRlcmVzdCBpbiB0aGlzIGxpbmUgb2Ygd29yay4NCg0KfCBWb246IFBhcnZpeiBZ ZWdhbmkgW21haWx0bzpweWVnYW5pQGdtYWlsLmNvbV0gDQp8IEdlc2VuZGV0OiBTYW1zdGFnLCAy Ny4gU2VwdGVtYmVyIDIwMTQgMDY6MDcNCnwgQW46IEdlb3JnaW9zIEthcmFnaWFubmlzDQp8IENj OiBzdXBhQGlldGYub3JnDQp8IEJldHJlZmY6IFJlOiBbU3VwYV0gTmV3IFNVUEEgY2hhcnRlcg0K fA0KfCBHcmVhdCBqb2IgR2Vvcmdpb3MuIFRoZSBjaGFydGVyIGlzIHdlbGwgd3JpdHRlbiBhbmQg bmljZWx5IHN0cnVjdHVyZWQuIFRoZSBub3Rpb24gb2YgIm5ldHdvcmsgYm94ZXMiLCBob3dldmVy LCANCnwgaXMgYSBiaXQgY29uZnVzaW5nLiBJJ2QgcmF0aGVyIHRvIHJlcGxhY2UgaXQgd2l0aCAi bmV0d29yayBub2RlcyIgb3IgIm5ldHdvcmsgY29tcG9uZW50cyIuIEkgYWxzbyBoYXZlDQp8IHNv bWUgb3RoZXIgbWlub3IgZWRpdG9yaWFsIGNvbW1lbnRzLiBJIHdpbGwgc2VuZCBpdCBpbiBhIHNl cGFyYXRlIGVtYWlsLiBJdCdzIGdvb2QgdGhhdCB5b3UgbWVudGlvbmVkIHRoZQ0KfCBTVVBBIFdH IChvbmNlIGZvcm1lZCkgd2lsbCBjb2xsYWJvcmF0ZSB3aXRoIG90aGVyIHJlbGV2YW50IGdyb3Vw cyB3aXRoaW4gSUVURiAoTkVUQ09ORiwgWWFuZyBkb2N0b3JzLCAuLikNCnwgdG8gZW5zdXJlIGNv bnNpc3RlbmN5IGFuZCBhdm9pZCBkaXZlcmdlbmNlIG9yIHBlcmhhcHMgYW55IHBvc3NpYmxlIGR1 cGxpY2F0aW9uIG9mIHdvcmsuDQoNCnwgVGhhbmtzLA0KfCBQYXJ2aXoNCg== From nobody Tue Sep 30 05:01:09 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 785C61A0331; Tue, 30 Sep 2014 03:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 dn21brwtNA2N; Tue, 30 Sep 2014 03:21:44 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 624501A031F; Tue, 30 Sep 2014 03:21:43 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKB72285; Tue, 30 Sep 2014 10:21:30 +0000 (GMT) Received: from LHREML516-MBX.china.huawei.com ([169.254.1.85]) by lhreml402-hub.china.huawei.com ([10.201.5.241]) with mapi id 14.03.0158.001; Tue, 30 Sep 2014 11:21:23 +0100 From: Georgios Karagiannis To: Kostas Pentikousis Thread-Topic: [Supa] New SUPA charter Thread-Index: Ac/ZIUcaEK+SU+lYTNqeRV6T6bQAHwA3sVMAAHt6SIAAKi/zMA== Date: Tue, 30 Sep 2014 10:21:23 +0000 Message-ID: References: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C72ADDE@SBS2008.eict.local> In-Reply-To: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C72ADDE@SBS2008.eict.local> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.64.47] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/UQjjOxlQC-YiHqOz5nvuFumWeWE X-Mailman-Approved-At: Tue, 30 Sep 2014 05:01:08 -0700 Cc: "nmrg@irtf.org" , "supa@ietf.org" , Parviz Yegani Subject: Re: [nmrg] [Supa] New SUPA charter 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, 30 Sep 2014 10:21:45 -0000 RGVhciBLb3N0YXMsDQoNClRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHRoZSBwcm92aWRlZCBjb21t ZW50cyBvbiB0aGUgU1VQQSBjaGFydGVyIQ0KDQpQbGVhc2Ugc2VlIGluIGxpbmUhDQoNCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogS29zdGFzIFBlbnRpa291c2lzIFttYWls dG86ay5wZW50aWtvdXNpc0BlaWN0LmRlXQ0KPiBTZW50OiBNb25kYXksIFNlcHRlbWJlciAyOSwg MjAxNCA1OjAyIFBNDQo+IFRvOiBQYXJ2aXogWWVnYW5pOyBHZW9yZ2lvcyBLYXJhZ2lhbm5pcw0K PiBDYzogc3VwYUBpZXRmLm9yZzsgbm1yZ0BpcnRmLm9yZw0KPiBTdWJqZWN0OiBBVzogW1N1cGFd IE5ldyBTVVBBIGNoYXJ0ZXINCj4gDQo+IEhpIEdlb3JnaW9zLA0KPiANCj4gSSBzZWNvbmQgUGFy dml6LCBpdOKAmXMgbXVjaCBiZXR0ZXIgYWZ0ZXIgdGhlIHJlY2VudCByZXZpc2lvbnMuIEEgZmV3 IGNvbW1lbnRzDQo+IHdydCB0byB0aGUgdmVyc2lvbiBhdCBodHRwczovL2dpdGh1Yi5jb20vbGl1 c2h1Y2hlbmcvU1VQQS93aWtpL1NVUEEtQ2hhcnRlcg0KPiANCj4gRG8gd2UgbmVlZCB0aGlzIHBo cmFzZTogInRvIHNoaWZ0IHRoZSBiYWxhbmNlIFtvZiBjb3N0cz9dIGluIHRoZWlyIGZhdm9yIj8N Cj4gU1VQQSBzaG91bGQgbm90IGJlIGEgemVyby1zdW0gZ2FtZS4gRXZlcnlvbmUgc2hvdWxkIGJl bmVmaXQgKHZlbmRvcnMsDQo+IG9wZXJhdG9ycywgYWRtaW5zLCB1c2VycywgbmV3IHNlcnZpY2Ug cHJvdmlkZXJzKS4NCls+XSANCkdlb3JnaW9zOiBBZ3JlZSB3aXRoIHlvdSwgdGhhdCBldmVyeW9u ZSBzaG91bGQgYmVuZWZpdCAodmVuZG9ycywNCm9wZXJhdG9ycywgYWRtaW5zLCB1c2VycywgbmV3 IHNlcnZpY2UgcHJvdmlkZXJzKS4NCldlIG5lZWQgdG8gcmVwaHJhc2UgdGhpcyB0ZXh0LiANCg0K PiANCj4gRG8gd2UgUkVBTExZIGhhdmUgdG8gY2FwaXRhbGl6ZSBQT0xJQ1ksIFVOSUZJRUQsIFNI QVJFRCwgYW5kIEFVVE9NQVRJQ0FMTFk/IDopDQpbPl0gDQpHZW9yZ2lvczogbm90IHJlYWxseSwg d2UganVzdCB1c2VkIHRoZW0gdG8gbWFrZSB0aGUgZW1waGFzaXplIGhvdyB0aGUgU1VQQSBhYmJy ZXZpYXRpb24gcmVsYXRlcyB0byB0aGUgY2hhcnRlciBkZXNjcmlwdGlvbi4gSSBhc3N1bWUgdGhh dCB3ZSBjYW4gbWFyayB0aGVzZSB3b3JkcyB1c2luZyBhbm90aGVyIG1ldGhvZCwgZS5nLiwgIiIN Cg0KPiANCj4gVGhlIHBhcmFncmFwaCBzdGFydGluZyB3aXRoICJTb21lIElFVEYgd29ya2luZyBn cm91cHMuLi4iIG1heSBiZSB1c2VmdWwgdG8NCj4gbW90aXZhdGUgY2hhcnRlcmluZyB0aGUgV0cs IGJ1dCBJJ20gbm90IHN1cmUgaXQgc2hvdWxkIGJlIHBhcnQgb2YgdGhlIGZpbmFsDQo+IGNoYXJ0 ZXIuDQpbPl0gDQoNCkdlb3JnaW9zOiBOb3Qgc3VyZSwgaG93IHdlIHNob3VsZCBoYW5kbGUgdGhp cyBpc3N1ZS4gV2UgdXNlZCB0aGUgcGFyYWdyYXBoIHRvIHNob3cgdGhlIHJlbGF0aW9uIHdpdGgg b3RoZXIgSUVURiBXR3MuDQoNCj4gDQo+IEZpbmFsbHksIHRoZSBsYXN0IHBhcmFncmFwaHMgc3Rh cnRpbmcgd2l0aCAiU1VQQSB3aWxsIHdvcmsgb24gZGVmaW5pbmcuLi4gIg0KPiBhbmQgZW5kaW5n IHdpdGggdGhlIHNlY3Rpb24gb24gV29yayBJdGVtcyBoYXMgYSBiaXQgb2Ygb3ZlcmxhcCB3aXRo IHRoZQ0KPiByZW1haW5pbmcgdGV4dCAoV29yayBJdGVtcywgRGVsaXZlcmFibGVzKS4gDQpbPl0g DQoNCkdlb3JnaW9zOiBUaGFua3MsICB3ZSB3aWxsIHRyeSB0byByZW1vdmUgdGhlIG92ZXJsYXAg YXMgbXVjaCBhcyBwb3NzaWJsZS4NCg0KSSBoYXZlIGEgZmV3IG1vcmUgZWRpdG9yaWFsDQo+IGNv bW1lbnRzIChlLmcuIHMvc3RhcnRlZCB3b3JrIHJlbGF0aW5nL3N0YXJ0ZWQgd29yayByZWxhdGVk KSwgYnV0IHdlIGNhbg0KPiBoYW5kbGUgdGhhdCBvZmZsaW5lLg0KWz5dIA0KDQpHZW9yZ2lvczog dGhhbmsgeW91IHZlcnkgbXVjaCENCg0KQmVzdCByZWdhcmRzLA0KR2Vvcmdpb3MNCg0KPiANCj4g QmVzdCByZWdhcmRzLA0KPiANCj4gS29zdGFzDQo+IA0KPiBQUzogSSB0b29rIHRoZSBsaWJlcnR5 IHRvIENDIE5NUkcgYXMgc29tZSBmb2xrcyBpbiB0aGF0IGdyb3VwIG1heSBoYXZlIGFuDQo+IGlu dGVyZXN0IGluIHRoaXMgbGluZSBvZiB3b3JrLg0KPiANCj4gfCBWb246IFBhcnZpeiBZZWdhbmkg W21haWx0bzpweWVnYW5pQGdtYWlsLmNvbV0NCj4gfCBHZXNlbmRldDogU2Ftc3RhZywgMjcuIFNl cHRlbWJlciAyMDE0IDA2OjA3DQo+IHwgQW46IEdlb3JnaW9zIEthcmFnaWFubmlzDQo+IHwgQ2M6 IHN1cGFAaWV0Zi5vcmcNCj4gfCBCZXRyZWZmOiBSZTogW1N1cGFdIE5ldyBTVVBBIGNoYXJ0ZXIN Cj4gfA0KPiB8IEdyZWF0IGpvYiBHZW9yZ2lvcy4gVGhlIGNoYXJ0ZXIgaXMgd2VsbCB3cml0dGVu IGFuZCBuaWNlbHkgc3RydWN0dXJlZC4NCj4gfCBUaGUgbm90aW9uIG9mICJuZXR3b3JrIGJveGVz IiwgaG93ZXZlciwgaXMgYSBiaXQgY29uZnVzaW5nLiBJJ2QgcmF0aGVyDQo+IHwgdG8gcmVwbGFj ZSBpdCB3aXRoICJuZXR3b3JrIG5vZGVzIiBvciAibmV0d29yayBjb21wb25lbnRzIi4gSSBhbHNv DQo+IHwgaGF2ZSBzb21lIG90aGVyIG1pbm9yIGVkaXRvcmlhbCBjb21tZW50cy4gSSB3aWxsIHNl bmQgaXQgaW4gYSBzZXBhcmF0ZQ0KPiB8IGVtYWlsLiBJdCdzIGdvb2QgdGhhdCB5b3UgbWVudGlv bmVkIHRoZSBTVVBBIFdHIChvbmNlIGZvcm1lZCkgd2lsbA0KPiBjb2xsYWJvcmF0ZSB3aXRoIG90 aGVyIHJlbGV2YW50IGdyb3VwcyB3aXRoaW4gSUVURiAoTkVUQ09ORiwgWWFuZyBkb2N0b3JzLCAu LikNCj4gdG8gZW5zdXJlIGNvbnNpc3RlbmN5IGFuZCBhdm9pZCBkaXZlcmdlbmNlIG9yIHBlcmhh cHMgYW55IHBvc3NpYmxlIGR1cGxpY2F0aW9uDQo+IG9mIHdvcmsuDQo+IA0KPiB8IFRoYW5rcywN Cj4gfCBQYXJ2aXoNCg==