[nmrg] Updating draft-irtf-nmrg-autonomic-network-definitions-00

"Michael Behringer (mbehring)" <mbehring@cisco.com> Tue, 24 June 2014 13:55 UTC

Return-Path: <mbehring@cisco.com>
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 89AC21B2951 for <nmrg@ietfa.amsl.com>; Tue, 24 Jun 2014 06:55:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level:
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=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 CPt0oOczv_Ku for <nmrg@ietfa.amsl.com>; Tue, 24 Jun 2014 06:55:28 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E96F1B294B for <nmrg@irtf.org>; Tue, 24 Jun 2014 06:55:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2984; q=dns/txt; s=iport; t=1403618128; x=1404827728; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=tGrCikYZqThpouQSbwLH+KjRIdiqG2NQQ7i6CNsKEZI=; b=fGFXiU/dDcowcPldo0J5Cx7kaT2I0zRHL8VRt/Lz5Ldp8tp09SVK0wA2 gDcnfbF95JZWgdfOSfNREGixUt3elHAPRjADOT/gZCkweKflzhHPsWXOX GTrz2iek1hxP7KIaKGHh2ED9r+DvF1enWYcqehET10MGY5tN/zCrkvKwQ 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApAGAJ6CqVOtJA2H/2dsb2JhbABZgw1SWqpABQECA5k1AYEGFnWEBQEEOlEBKhRCJgEEARoBiDkNw2MXhWOINxACAR4zgzKBFgWcF5Ilg0JsgUQ
X-IronPort-AV: E=Sophos;i="5.01,538,1400025600"; d="scan'208";a="335366339"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-4.cisco.com with ESMTP; 24 Jun 2014 13:55:27 +0000
Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s5ODtQM7018026 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Jun 2014 13:55:26 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Tue, 24 Jun 2014 08:55:26 -0500
From: "Michael Behringer (mbehring)" <mbehring@cisco.com>
To: "anima@ietf.org" <anima@ietf.org>, "nmrg@irtf.org" <nmrg@irtf.org>
Thread-Topic: Updating draft-irtf-nmrg-autonomic-network-definitions-00
Thread-Index: Ac+Ps8dVKhhDDzh8R4WTmNCrIuSMYg==
Date: Tue, 24 Jun 2014 13:55:25 +0000
Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BCA03D@xmb-rcd-x14.cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.55.238.137]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/QDoMaiZHEmV_O2RCEduWgmMy-Dk
Subject: [nmrg] Updating draft-irtf-nmrg-autonomic-network-definitions-00
X-BeenThere: nmrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Management Research Group discussion list <nmrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/nmrg>, <mailto:nmrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/nmrg/>
List-Post: <mailto:nmrg@irtf.org>
List-Help: <mailto:nmrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/nmrg>, <mailto:nmrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Jun 2014 13:55:31 -0000

NMRG, Anima, 

Having gone through feedback, and re-reading the document myself, here is a list of changes I'm proposing to make to 
http://tools.ietf.org/html/draft-irtf-nmrg-autonomic-network-definitions-00:

High level, I think the "meat" of the document, sections 3, 4 and 6 are pretty complete and correct. If anyone thinks we're missing an important design goal or a non-design goal, please speak up! 

Some details: 

1. Section 3.1. always refers to "nodes". We should rephrase this to "functions". The primary goal here is not to produce a fully autonomic node or network, but autonomic functions. For the foreseeable future fully autonomic nodes/networks will remain the exception. 
Therefore: s/node/function/ in this section. 
Actually, also later on in the doc the doc references sometimes "nodes" or "the network". I suggest to change that to "function". 

2. Common infrastructure. 
In my mail http://www.ietf.org/mail-archive/web/nmrg/current/msg01512.html I suggested to add to the design goals: 

<section title="Common Autonomic Networking Infrastructure">
	<t><xref target="I-D.irtf-nmrg-an-gap-analysis"/> points out that there are already a number of fully or partially autonomic functions available today. However, they are largely independent, and each has its own methods and protocols to communicate, discover, define and distribute policy, etc. </t>
	<t>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. This autonomic networking infrastructure may contain common control and management functions such as messaging, service discovery, negotiation, intent distribution, etc. A common approach to define and manage intent is also required. </t>
	<t>Refer to the reference model below: All the components around the "autonomic service agents" should be common components, such that the autonomic service agents do not have to replicate common tasks individually. </t>
      </section>

Unless I missed it, I haven't seen any negative comments on that section, so I'll add it to the new version. 

3. Use case section. 
In the same email (link above) I proposed some text for the use case section. But frankly, I think this is overtaken by the discussion we had on the list, and out of date. 
We also want to drive this document to publication soon, so procedural issues such as how to report use cases should really not be there any more. 
I suggest we just remove this section completely, since IMO it is not required for the document to be useful and complete. Thoughts? 

Am I missing any feedback, or points we discussed? If so, please let me know! 

I'm finalising version -01 of the document now. I'll circulate first amongst the authors, then post the result. 

Michael