Re: [Anima] Use of the chartering tool for ANIMA - draft names mentioned or not?

"Papadimitriou, Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-lucent.com> Sat, 13 September 2014 11:12 UTC

Return-Path: <dimitri.papadimitriou@alcatel-lucent.com>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1828C1A06CC for <anima@ietfa.amsl.com>; Sat, 13 Sep 2014 04:12:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.551
X-Spam-Level:
X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 BvDeXNicAU1N for <anima@ietfa.amsl.com>; Sat, 13 Sep 2014 04:12:05 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 A93A51A06AF for <anima@ietf.org>; Sat, 13 Sep 2014 04:12:04 -0700 (PDT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id B0F95FAFF206A; Sat, 13 Sep 2014 11:11:57 +0000 (GMT)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s8DBBx4G001990 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 13 Sep 2014 13:11:59 +0200
Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.52]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Sat, 13 Sep 2014 13:11:59 +0200
From: "Papadimitriou, Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-lucent.com>
To: Benoit Claise <bclaise@cisco.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>
Thread-Topic: [Anima] Use of the chartering tool for ANIMA - draft names mentioned or not?
Thread-Index: AQHPzyPAR02kKyY620OczE9gcwT46Jv+yBaw
Date: Sat, 13 Sep 2014 11:11:59 +0000
Message-ID: <84675BAA8C49154AB81E2587BE8BDF8323454144@FR711WXCHMBA07.zeu.alcatel-lucent.com>
References: <54117DD5.3090303@cisco.com> <84675BAA8C49154AB81E2587BE8BDF832345311E@FR711WXCHMBA07.zeu.alcatel-lucent.com> <5413136E.1060801@cisco.com> <84675BAA8C49154AB81E2587BE8BDF8323453C1A@FR711WXCHMBA07.zeu.alcatel-lucent.com> <5413568B.5060801@gmail.com> <84675BAA8C49154AB81E2587BE8BDF8323453C9A@FR711WXCHMBA07.zeu.alcatel-lucent.com> <5413F115.9080504@cisco.com>
In-Reply-To: <5413F115.9080504@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.41]
Content-Type: multipart/alternative; boundary="_000_84675BAA8C49154AB81E2587BE8BDF8323454144FR711WXCHMBA07z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/anima/g5-yMfG_cqIoS7RFJWh0PPa1O4U
Cc: "anima@ietf.org" <anima@ietf.org>
Subject: Re: [Anima] Use of the chartering tool for ANIMA - draft names mentioned or not?
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Sep 2014 11:12:09 -0000

Hello,

In order to be more verbose without constraining subsequent work/development, here below you will find three concrete suggestions:


1.  For the ACP, a description is provided in http://tools.ietf.org/html/draft-irtf-nmrg-autonomic-network-definitions-03 :



Autonomic Control Plane: Allows the node to communicate with other
      autonomic nodes.  Autonomic functions such as intent distribution,
      feedback loops, discovery mechanisms, etc, use the autonomic
      control plane.  The autonomic control plane can run inband, over a
      configured VPN, over a self-managing overlay network, as described
      in [I-D.behringer-autonomic-control-plane<http://tools.ietf.org/html/draft-irtf-nmrg-autonomic-network-definitions-03#ref-I-D.behringer-autonomic-control-plane>], or over a traditional
      out of band network.  Security is a requirement for the Autonomic
      Control Plane, which can be bootstrapped by a mechanism as
      described in [I-D.pritikin-bootstrapping-keyinfrastructures<http://tools.ietf.org/html/draft-irtf-nmrg-autonomic-network-definitions-03#ref-I-D.pritikin-bootstrapping-keyinfrastructures>].



It reads as the ACP provides for the communication means (channels, interface, etc.). However, there is an important point to be clarified: this definition states that autonomic functions such as discovery mechanisms use the common infrastructure components but the latter (following the charter) also includes a discovery process/mechanism:


[main goal]
The main goal of the ANIMA WG is therefore to develop common infrastructure components for distributed functions. The infrastructure should be capable of providing the following services to those distributed functions:
o a common way to identify nodes
o a common security model
o a discovery mechanism
o […]


ð  Altogether, it reads as if we have two discovery mechanisms (the same for the negotiation process). I have suggested to simplify this by mentioning a “use relationship” between the service agents (and when needed with other components) and the discovery process and leave the discussion as to which level (cf. fig 1 of <http://tools.ietf.org/html/draft-irtf-nmrg-autonomic-network-definitions-03> it belongs/decomposes when this group will put the pieces together at later stage.


2.  Concerning the description of discovery process, and following <http://www.ietf.org/mail-archive/web/anima/current/msg00268.html> I suggest to use the following description either in the charter or in the NMRG doc’s it refers to:



Discovery is the mechanism used by agents to determine: where is a given (set of) agent(s) located, what can a given (set of) agent(s) perform/execute (function) or provide (resource), which knowledge/information can a given set of agent(s) deliver; inter-agent exchanges for discovery purposes can operate either directly (without involving a third party) or indirectly (e.g., by means of a directory or a dictionary) and independently of the underlying routing topology.


Note_1: once the point 1 is clarified, we can certainly extend its applicability to other elements (components) of the autonomic plane.

Note_2: we could refine with spatial scope (i.e. single admin domain or not) but don’t want to be prescriptive in that respect.





3.  Concerning the description of negotiation process and following <http://www.ietf.org/mail-archive/web/anima/current/msg00261.html> I suggest to use the following description either in the charter or in the NMRG doc’s it refers to:

Negotiation enables groups of agents to reach mutual agreement regarding some joint goal or problem by means of interactive search through a space of potential agreements. This interactive mechanism comprises negotiation protocols : the set of rules that govern the interaction,  negotiation objects : the range of issues over which agreement must be reached and allowable operations/changes on these objects, and agents’ reasoning models : the decision making procedures by which participants attempt to achieve their goals. The sophistication of the model is determined by the protocol used, the nature of the negotiation object, and the range of operations that can be performed on it.

Note_1: same as note 1 above for point 2.

Note_2: as I understand we’d like to progress step-by-step we can leave reasoning models with lower priority at first stage.


May be similar short description can be provided for the key infrastructure bootstrap (following draft-pritikin ?)


Regards,
-dimitri.

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Saturday, September 13, 2014 9:24 AM
To: Papadimitriou, Dimitri (Dimitri); Brian E Carpenter
Cc: anima@ietf.org
Subject: Re: [Anima] Use of the chartering tool for ANIMA - draft names mentioned or not?

Dear all,

Let me split the issue.
I inserted the draft names back in the charter at https://datatracker.ietf.org/doc/charter-ietf-anima/
As explained in a previous email (Subject "ANIMA status"):
Regarding the starting points mentioning the draft names, I actually believe that pointing to existing work is a plus, to see some description behind a single bullet point. Let's imagine that you read "Definition of a solution for a separated Autonomic Control Plane" for the first time (this is what will happen when/if this charter is proposed for last-call), I'm sure that would lead to many questions or potential wrong assumptions.
Note, however, that mentioning starting points doesn't imply that we ask you to adopt those document as WG items now.
I see two tracks from here:
1. We keep the draft names as starting points.

2. We remove the draft names BUT you have to be slightly more verbose on what you try to achieve WITHOUT going in the full discussion right now. For example, all Dmitri's questions are valid ...

Discovery as documented "draft-jiang-config-negotiation-protocol" (listed in the charter) states it is designed to be a generic negotiation platform (if someone can explain what the word platform means in this context this would be really helpful), it assumes "the main target scenarios are still hierarchical networks [...] we assume that each network element has a hierarchical superior" (how does such constraint relate to the NRMG framework document which states "Those nodes communicate with each other through an Autonomic Control Plane which provides a robust and secure communications overlay" which reads plane needs drive the inter-agent communication paths and not the other way around), and more importantly it doesn't put at all in perspective the three components of a discovery process in such systems: where is agent X (location), what can do/provide agent Y (function/resource), which knowledge has agent Z (information) and whether other agents should

  access

 either of them directly or indirectly. This type of considerations should be part of a document that could be considered as a starting point.
... but I wonder whether we should answer all them now, at charter time.

The real question is: should a future WG be working on this problem?

Regards, Benoit


Brian:



-----Original Message-----

From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]

Sent: Friday, September 12, 2014 10:25 PM

To: Papadimitriou, Dimitri (Dimitri)

Cc: Benoit Claise; anima@ietf.org<mailto:anima@ietf.org>

Subject: Re: [Anima] Use of the chartering tool for ANIMA



Two clarifications:



On 13/09/2014 07:56, Papadimitriou, Dimitri (Dimitri) wrote:

...

Discovery as documented "draft-jiang-config-negotiation-protocol"

(listed in the charter)



No, we have removed it from the charter according to earlier discussions.

(I'd be glad to respond to your specific comments on the draft, but that

is not a chartering issue.)



In the latest version (as posted by Benoit <http://www.ietf.org/mail-archive/web/anima/current/msg00266.html><http://www.ietf.org/mail-archive/web/anima/current/msg00266.html>, I read:



[specific goals]

The goals of this working group are below. The were selected to according to the

analyzed technical gaps in draft-irtf-nmrg-an-gap-analysis:

o Definition of a discovery and negotiation protocol for autonomic functions

   Starting point: draft-jiang-config-negotiation-protocol

o Definition of a solution to bootstrap a trust infrastructure

   Starting point: draft-pritikin-bootstrapping-keyinfrastructures

o Definition of a solution for a separated Autonomic Control Plane

   Starting point: draft-behringer-autonomic-control-plane



Side question: as the IETF now asks for IPR related issues once adopting

a document (from its charter), what would happen in case of any IPR

application to the documents listed in the charter ? will you allow this

group proposing its royalty free protocol ?



IPR disclosure is required as soon as a contribution is posted - there is

nothing special about WG adoption in that respect.



I don't understand then why my mailbox is full of emails from WG chairs asking for any IPR issue upon WG adoption.



Also, each WG makes its own decisions about whether any disclosed IPR is a

problem or not; that's a consensus matter, not an AD choice.



   Brian