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

From: Benoit Claise <[email-masked]>
Date: Thu, 11 Sep 2014 12:47:49 +0200

Dear all,

Trying to compile the diffs between charter versions from 
http://trac.tools.ietf.org/bof/anima/trac/wiki/DraftCharter is, let's 
say it, a pain.

We have a nice tool for chartering effort.
Please bookmark https://datatracker.ietf.org/doc/charter-ietf-anima/

Charter "charter-ietf-anima-00-04" corresponds to the version 9 from 
http://trac.tools.ietf.org/bof/anima/trac/wiki/DraftCharter , which I 
consider like the more stable one at this point in time.
Looking at the diffs is very easy. Click on the history tab. Note that 
only formating changes were inserted between versions 
charter-ietf-anima-00-00 and charter-ietf-anima-00-04.

Let's continue the chartering discussion.
In collaboration with Brian and Michael, I can update the charter text 
in the tool.

Regards, Benoit (OPS AD)

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Fri, 12 Sep 2014 08:47:49 +0000

Benoit:

> In collaboration with Brian and Michael, I can update the charter text in
> the tool.

The criteria of "speed" and "focus" for considering a charter as stable are diverting from the real questions such piece of text should provide answers to, in particular, "are we doing the right thing ?", "are we doing the thing right ?", "how are we going to measure/prove success at the end of the first charter term ?"

Assessing whether this group has the critical mass to realize a reusable piece of work instead of a high-risk point-solution is also crucial. Indeed, proceeding by trial-and-error or risking the well-known loophole protocol -> use case -> protocol -> use case -> ... and never see any wide adoption because potential users would need the next use case/feature not covered by the protocol, is neither going to help the "industry" nor the IETF.

An effort aiming at reconciling and combining different charter contributions in an attempt to minimize such risks and produce a reusable piece of work is currently ongoing (cf. <http://www.ietf.org/mail-archive/web/anima/current/msg00242.html>). You would be well advised in considering it.

Thanks,
-dimitri.

> -----Original Message-----
> From: Anima [mailto:[email-masked]] On Behalf Of Benoit Claise
> Sent: Thursday, September 11, 2014 12:48 PM
> To: [email-masked]
> Subject: [Anima] Use of the chartering tool for ANIMA
> 
> Dear all,
> 
> http://trac.tools.ietf.org/bof/anima/trac/wiki/DraftCharter is, let's say
> it, a pain.
> 
> In collaboration with Brian and Michael, I can update the charter text in
> the tool.
> 
> Regards, Benoit (OPS AD)
> 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Benoit Claise <[email-masked]>
Date: Fri, 12 Sep 2014 17:38:22 +0200

Hi Dimitri,
> The criteria of "speed" and "focus" for considering a charter as stable are diverting from
Did I do this mistake to confuse speed/focus with charter stability? I 
don't think so.
> the real questions such piece of text should provide answers to, in particular, "are we doing the right thing ?", "are we doing the thing right ?", "how are we going to measure/prove success at the end of the first charter term ?"
To answer the last question: "by producing quality documents in a timely 
manner"
> An effort aiming at reconciling and combining different charter contributions in an attempt to minimize such risks and produce a reusable piece of work is currently ongoing (cf. <http://www.ietf.or…
Considered it, and I have replied to Laurent.
I don't believe that making a problem bigger helps solving it.

Regards, Benoit

> .

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Fri, 12 Sep 2014 19:56:22 +0000

Hi Benoit, 

The purpose is not to bring a bigger problem but determine its boundaries towards building stronger foundations to the protocol effort. I have tried to explain in <http://www.ietf.org/mail-archive/web/anima/current/msg00261.html> what are the boundaries of a negotiation process, but if I take discovery part for instance, the same type of discussion can be initiated. 

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. 

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 ?

Many thanks,
-dimitri.
> From: Benoit Claise [mailto:[email-masked]]
> Sent: Friday, September 12, 2014 5:38 PM
> To: Papadimitriou, Dimitri (Dimitri); [email-masked]
> Subject: Re: [Anima] Use of the chartering tool for ANIMA
> 
> Hi Dimitri,
> > Benoit:
> >
> >> In collaboration with Brian and Michael, I can update the charter
> >> text in the tool.
> > the real questions such piece of text should provide answers to, in
> particular, "are we doing the right thing ?", "are we doing the thing
> right ?", "how are we going to measure/prove success at the end of the
> first charter term ?"
> > Assessing whether this group has the critical mass to realize a reusable
> piece of work instead of a high-risk point-solution is also crucial.
> Indeed, proceeding by trial-and-error or risking the well-known loophole
> protocol -> use case -> protocol -> use case -> ... and never see any wide
> adoption because potential users would need the next use case/feature not
> covered by the protocol, is neither going to help the "industry" nor the
> IETF.
> >
> > An effort aiming at reconciling and combining different charter
> contributions in an attempt to minimize such risks and produce a reusable
> piece of work is currently ongoing (cf. <http://www.ietf.org/mail-
> archive/web/anima/current/msg00242.html>). You would be well advised in
> considering it.
> >> Looking at the diffs is very easy. Click on the history tab. Note
> >> that only formating changes were inserted between versions
> >> In collaboration with Brian and Michael, I can update the charter
> >> text in the tool.
> >>
> >> Regards, Benoit (OPS AD)
> >>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 13 Sep 2014 08:24:43 +1200

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.)

...
> 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 ? wil…

IPR disclosure is required as soon as a contribution is posted -
there is nothing special about WG adoption in that respect.
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

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Fri, 12 Sep 2014 20:40:12 +0000

Brian:

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Friday, September 12, 2014 10:25 PM
> To: Papadimitriou, Dimitri (Dimitri)
> Cc: Benoit Claise; [email-masked]
> 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>, 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

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 13 Sep 2014 11:17:05 +1200

I have updated the wiki to reflect this. The page at
http://trac.tools.ietf.org/bof/anima/trac/wiki/DraftCharter is
now historical.

   Brian

---

From: Benoit Claise <[email-masked]>
Date: Sat, 13 Sep 2014 09:24:05 +0200

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 ...

... 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

---

From: Benoit Claise <[email-masked]>
Date: Sat, 13 Sep 2014 09:30:18 +0200

Dear all,

> disclosed IPR is a problem or not; that's a consensus matter,
Exactly.

I would like to draw to the attention of the 
draft-jiang-config-negotiation-protocol, 
draft-pritikin-bootstrapping-keyinfrastructures, and 
draft-behringer-autonomic-control-plane draft authors that IPR 
declarations are required, and that IPRs might be an important factor in 
a WG creation.
Actually, this message is valid for all draft authors.

Regards, Benoit

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Sat, 13 Sep 2014 11:11:59 +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:[email-masked]]
Sent: Saturday, September 13, 2014 9:24 AM
To: Papadimitriou, Dimitri (Dimitri); Brian E Carpenter
Cc: [email-masked]
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.

Regards, Benoit

Brian:

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

Cc: Benoit Claise; [email-masked]<mailto:[email-masked]>

Two clarifications:

...

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

(listed in the charter)

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]

   Brian

---

From: Sheng Jiang <[email-masked]>
Date: Sat, 13 Sep 2014 11:56:07 +0000

Hi, Dimitri,

For my understanding,  all three drafts are only listed as *start points*. It means: 1) they are not WG drafts yet, if there were better alternative appoaches, the WG could make an open process to choose. 2) they are not technically mature yet. They are open for any comments/doubts/debates to help them to become mature in the future. But it is the work for the WG stage, not for the draft charter discussion.

Explanation for the word "platform": it means the protocol itself is independent from the negotiation objectives. It only focuses on message exchange, negotiation process, and etc. It should be able to handle any negotiation information/objectives.

Best regards,

Sheng
________________________________________
From: Anima [[email-masked]] on behalf of Papadimitriou, Dimitri (Dimitri) [[email-masked]]
Sent: 13 September 2014 3:56
To: Benoit Claise; [email-masked]
Subject: Re: [Anima] Use of the chartering tool for ANIMA

Hi Benoit,

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 th!
em direct
 ly or indirectly. This type of considerations should be part of a document that could be considered as a starting point.

Many thanks,
-dimitri.

---

From: Sheng Jiang <[email-masked]>
Date: Sat, 13 Sep 2014 12:05:38 +0000

Hi, Benoit,

I can confirm that I am aware of NO relevant IPR for all three drafts, so no IPR disclosure is needed from my side. I complied with the IPR rules defined in BCP78 and BCP79.

Regards,

Sheng
________________________________________
From: Anima [[email-masked]] on behalf of Benoit Claise [[email-masked]]
Sent: 13 September 2014 15:30
To: Brian E Carpenter; Papadimitriou, Dimitri (Dimitri)
Cc: [email-masked]
Subject: Re: [Anima] Use of the chartering tool for ANIMA - IPR

Dear all,

Exactly.

Regards, Benoit

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Sat, 13 Sep 2014 12:18:00 +0000

Hi,

o) We don't need to list documents to explain / characterize a "starting point". I have made concrete suggestions to either explain them in the charter or NRMG references (as widely used to write it down). <http://www.ietf.org/mail-archive/web/anima/current/msg00276.html>

o) The point has been mentioned several times on this list, your individual submission assumes a single protocol for both functionality (negotiation and discovery) whereas it is far from proven this is the right decomposition; hence, the right "starting point". 

o) If as of today (charter writing time) there are known technical issues/concerns in some these documents (the notion of negotiation process this document uses is far from being satisfactory as already explained on this list cf. <http://www.ietf.org/mail-archive/web/anima/current/msg00261.html> , the same for discovery process cf. <http://www.ietf.org/mail-archive/web/anima/current/msg00268.html>), why should they be considered as starting point ?  

Thanks,
-dimitri. 

> From: Sheng Jiang [mailto:[email-masked]]
> Sent: Saturday, September 13, 2014 1:56 PM
> To: Papadimitriou, Dimitri (Dimitri); Benoit Claise; [email-masked]
> Subject: RE: [Anima] Use of the chartering tool for ANIMA
> 
> Hi, Dimitri,
> 
> For my understanding,  all three drafts are only listed as *start points*.
> It means: 1) they are not WG drafts yet, if there were better alternative
> appoaches, the WG could make an open process to choose. 2) they are not
> technically mature yet. They are open for any comments/doubts/debates to
> help them to become mature in the future. But it is the work for the WG
> stage, not for the draft charter discussion.
> 
> Explanation for the word "platform": it means the protocol itself is
> independent from the negotiation objectives. It only focuses on message
> exchange, negotiation process, and etc. It should be able to handle any
> negotiation information/objectives.
> 
> Best regards,
> 
> Sheng
> From: Anima [[email-masked]] on behalf of Papadimitriou, Dimitri
> (Dimitri) [[email-masked]]
> The purpose is not to bring a bigger problem but determine its boundaries
> towards building stronger foundations to the protocol effort. I have tried
> to explain in <http://www.ietf.org/mail-
> archive/web/anima/current/msg00261.html> what are the boundaries of a
> negotiation process, but if I take discovery part for instance, the same
> type of discussion can be initiated.
> 
> 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 th!
> em direct
>  ly or indirectly. This type of considerations should be part of a
> document that could be considered as a starting point.
> 
> 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
> > To answer the last question: "by producing quality documents in a
> > timely manner"
> > >
> > Indeed, proceeding by trial-and-error or risking the well-known
> > loophole protocol -> use case -> protocol -> use case -> ... and never
> > see any wide adoption because potential users would need the next use
> > case/feature not covered by the protocol, is neither going to help the
> > "industry" nor the IETF.
> > >
> > contributions in an attempt to minimize such risks and produce a
> > reusable piece of work is currently ongoing (cf.
> > <http://www.ietf.org/mail- archive/web/anima/current/msg00242.html>).
> > You would be well advised in considering it.
> > >> http://trac.tools.ietf.org/bof/anima/trac/wiki/DraftCharter is,
> > >> let's say it, a pain.
> > >>
> > >> Please bookmark
> > >> Charter "charter-ietf-anima-00-04" corresponds to the version 9
> > >> from http://trac.tools.ietf.org/bof/anima/trac/wiki/DraftCharter ,
> > >> which I consider like the more stable one at this point in time.

---

From: Sheng Jiang <[email-masked]>
Date: Sat, 13 Sep 2014 12:21:19 +0000

Hi, Benoit,

Thanks for your concrete suggestions. we will apply them.

One explanation: Michael and I did discuss the different level of discovery in Toronto. In ACP, it needs discovery mechanism to find other autonomic nodes. This needs discovery mechanism in protocol level. The current ACP draft does not clearly define or choose a certain protocol for this yet. It is definitely possible to use the generic discovery and negotiation protocol, that may be produced by ANIMA, for ACP. We did say we would do that in the future.

Best regards,

Sheng

________________________________
From: Anima [[email-masked]] on behalf of Papadimitriou, Dimitri (Dimitri) [[email-masked]]
Sent: 13 September 2014 19:11
To: Benoit Claise; Brian E Carpenter
Cc: [email-masked]
Subject: Re: [Anima] Use of the chartering tool for ANIMA - draft names mentioned or not?

Hello,

[main goal]

=>  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.

Regards,
-dimitri.

Dear all,

Let me split the issue.

  access

Regards, Benoit

Brian:

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

Two clarifications:

...

(listed in the charter)

[specific goals]

   Brian

---

From: Sheng Jiang <[email-masked]>
Date: Sat, 13 Sep 2014 12:40:06 +0000

Hi, Dimitri,

Firstly, you jump too fast into some technical discussions which should be made in the WG stage, rather than draft charter stage.

Secondly, I could agree with you that so far the proposed protocol is not generic enough to solve all the requirements. We will keep working on this. Your comments are very helpful for us to make it better. We really appreciate your comments and participation. This is the best efforts we have done so far. It is fair to list it as *start point*. You could NOT ask a start point to be mature or perfect. We are not even sure there will be a protocol generic enough to suit all scenarios. But this does not mean we should stop working. 

Best regards,

Sheng
________________________________________
From: Papadimitriou, Dimitri (Dimitri) [[email-masked]]
Sent: 13 September 2014 20:18
To: Sheng Jiang; Benoit Claise; [email-masked]
Subject: RE: [Anima] Use of the chartering tool for ANIMA

Hi,

Thanks,
-dimitri.

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Sat, 13 Sep 2014 19:08:42 +0000

Hello,

> Sent: Saturday, September 13, 2014 2:40 PM
> Firstly, you jump too fast into some technical discussions which should be
> made in the WG stage, rather than draft charter stage.

I don't think that a statement like "Please, drop the document from the charter" without any technical argument would be appropriate.

> Secondly, I could agree with you that so far the proposed protocol is not
> generic enough to solve all the requirements. We will keep working on
> this. Your comments are very helpful for us to make it better. We really
> appreciate your comments and participation. This is the best efforts we
> have done so far. It is fair to list it as *start point*. You could NOT
> ask a start point to be mature or perfect. We are not even sure there will
> be a protocol generic enough to suit all scenarios. But this does not mean
> we should stop working.

Actually i) I start to think that instead of indicating a fixed starting point, if it wouldn't be more appropriate to document source(s) of info helping guidance (such as early reviews), this would help keeping focus (fixing a starting point doesn't give such info), ii) by trying to impose a starting point with this document (for which I have not seen any objective argument showing we can't progress without it) may lead to the inverse effect than the initial objective, iii) submissions this WG is calling for may start from a different but stronger basis than this starting point (this would make later consensus even more complex to reach).

Thanks,
-dimitri.

> o) We don't need to list documents to explain / characterize a "starting
> point". I have made concrete suggestions to either explain them in the
> charter or NRMG references (as widely used to write it down).
> <http://www.ietf.org/mail-archive/web/anima/current/msg00276.html>
> 
> o) The point has been mentioned several times on this list, your
> individual submission assumes a single protocol for both functionality
> (negotiation and discovery) whereas it is far from proven this is the
> right decomposition; hence, the right "starting point".
> 
> o) If as of today (charter writing time) there are known technical
> issues/concerns in some these documents (the notion of negotiation process
> this document uses is far from being satisfactory as already explained on
> this list cf. <http://www.ietf.org/mail-
> archive/web/anima/current/msg00261.html> , the same for discovery process
> cf. <http://www.ietf.org/mail-archive/web/anima/current/msg00268.html>),
> why should they be considered as starting point ?
> 
> Thanks,
> -dimitri.
> 
> > It means: 1) they are not WG drafts yet, if there were better
> > alternative appoaches, the WG could make an open process to choose. 2)
> > they are not technically mature yet. They are open for any
> > comments/doubts/debates to help them to become mature in the future.
> > But it is the work for the WG stage, not for the draft charter
> discussion.
> >
> > independent from the negotiation objectives. It only focuses on
> > message exchange, negotiation process, and etc. It should be able to
> > handle any negotiation information/objectives.
> >
> > Best regards,
> >
> > Sheng
> > The purpose is not to bring a bigger problem but determine its
> > boundaries towards building stronger foundations to the protocol
> > effort. I have tried to explain in <http://www.ietf.org/mail-
> > negotiation process, but if I take discovery part for instance, the
> > same type of discussion can be initiated.
> >
> > (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
> > 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 ?
> >
> > Many thanks,
> > -dimitri.
> > > Did I do this mistake to confuse speed/focus with charter stability?
> > > I don't think so.
> > > particular, "are we doing the right thing ?", "are we doing the
> > > thing right ?", "how are we going to measure/prove success at the
> > > end of the first charter term ?"
> > > loophole protocol -> use case -> protocol -> use case -> ... and
> > > never see any wide adoption because potential users would need the
> > > next use case/feature not covered by the protocol, is neither going
> > > to help the "industry" nor the IETF.
> > > >
> > > >> from http://trac.tools.ietf.org/bof/anima/trac/wiki/DraftCharter
> > > >> , which I consider like the more stable one at this point in time.

---

From: Sheng Jiang <[email-masked]>
Date: Sat, 13 Sep 2014 23:55:13 +0000

Dimitri,

You missed the right discussion point, again. Like Benoit asked: the real question is: should a future WG be working on discovery and negotiation. If the concensus is no, we should, of course, drop this problem and the start point document. If the concensus is yes, we list the existing proposal as a start point and keep working to make it better. My understanding so far, nobody, including you, say no to the problem. After then, again, as I explained before, the start point documents are not WG drafts yet, if there were better alternative appoaches, the WG would make an open process to choose. List of  start points only means we have concrete proposals. It is much better than empty, or start from zero.

Regards,

Sheng
Sent: 14 September 2014 3:08

Hello,

Thanks,
-dimitri.

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Sun, 14 Sep 2014 00:54:43 +0000

Jiang:

You wrote:
> If the concensus is yes, we list the existing
> proposal as a start point and keep working to make it better. 

This statement is incorrect as two tracks have been listed by Benoit (see <http://www.ietf.org/mail-archive/web/anima/current/msg00274.html>) and below excerpt:

"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 ..."

I have explained how to cope with track 2 in case this would be the blocking point in moving in that direction. Cf. <http://www.ietf.org/mail-archive/web/anima/current/msg00276.html> -- note: I have been delving in your document to see which definition you use for discovery and couldn't find any. Even worse the document confuses discovery and negotiation process.

I have explained technically why you document is not suited as starting point and why initiating the work from the wrong starting point will lead to more problems than be helpful.

Finally, repeating the same kind of argument as you do since two weeks, reinforces the problem listed in my previous post "submissions this WG is calling for may start from a different but stronger basis than this starting point (this would make later consensus even more complex to reach)". 

Thanks,
-dimitri.

> Sent: Sunday, September 14, 2014 1:55 AM
> You missed the right discussion point, again. Like Benoit asked: the real
> question is: should a future WG be working on discovery and negotiation.
> If the concensus is no, we should, of course, drop this problem and the
> start point document. If the concensus is yes, we list the existing
> proposal as a start point and keep working to make it better. My
> understanding so far, nobody, including you, say no to the problem. After
> then, again, as I explained before, the start point documents are not WG
> drafts yet, if there were better alternative appoaches, the WG would make
> an open process to choose. List of  start points only means we have
> concrete proposals. It is much better than empty, or start from zero.
> 
> Regards,
> 
> Sheng
> > Firstly, you jump too fast into some technical discussions which
> > should be made in the WG stage, rather than draft charter stage.
> 
> I don't think that a statement like "Please, drop the document from the
> charter" without any technical argument would be appropriate.
> 
> > Secondly, I could agree with you that so far the proposed protocol is
> > not generic enough to solve all the requirements. We will keep working
> > on this. Your comments are very helpful for us to make it better. We
> > really appreciate your comments and participation. This is the best
> > efforts we have done so far. It is fair to list it as *start point*.
> > You could NOT ask a start point to be mature or perfect. We are not
> > even sure there will be a protocol generic enough to suit all
> > scenarios. But this does not mean we should stop working.
> 
> Actually i) I start to think that instead of indicating a fixed starting
> point, if it wouldn't be more appropriate to document source(s) of info
> helping guidance (such as early reviews), this would help keeping focus
> (fixing a starting point doesn't give such info), ii) by trying to impose
> a starting point with this document (for which I have not seen any
> objective argument showing we can't progress without it) may lead to the
> inverse effect than the initial objective, iii) submissions this WG is
> calling for may start from a different but stronger basis than this
> starting point (this would make later consensus even more complex to
> reach).
> 
> Thanks,
> -dimitri.
> 
> > Best regards,
> >
> > Sheng
> > o) We don't need to list documents to explain / characterize a
> > "starting point". I have made concrete suggestions to either explain
> > them in the charter or NRMG references (as widely used to write it
> down).
> > issues/concerns in some these documents (the notion of negotiation
> > process this document uses is far from being satisfactory as already
> > explained on this list cf. <http://www.ietf.org/mail-
> > archive/web/anima/current/msg00261.html> , the same for discovery
> > process cf.
> > <http://www.ietf.org/mail-archive/web/anima/current/msg00268.html>),
> > > alternative appoaches, the WG could make an open process to choose.
> > > 2) they are not technically mature yet. They are open for any
> > > archive/web/anima/current/msg00261.html> what are the boundaries of
> > > a negotiation process, but if I take discovery part for instance,
> > > the same type of discussion can be initiated.
> > >
> > > 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
> > > any IPR application to the documents listed in the charter ? will
> > > you allow this group proposing its royalty free protocol ?
> > >
> > > Many thanks,
> > > -dimitri.
> > > > >> In collaboration with Brian and Michael, I can update the
> > > > >> charter text in the tool.
> > > > next use case/feature not covered by the protocol, is neither
> > > > going to help the "industry" nor the IETF.
> > > > >
> > > > <http://www.ietf.org/mail-
> archive/web/anima/current/msg00242.html>).
> > > > >> from
> > > > >> http://trac.tools.ietf.org/bof/anima/trac/wiki/DraftCharter
> > > > >> Looking at the diffs is very easy. Click on the history tab.
> > > > >> Note that only formating changes were inserted between versions
> > > > >> In collaboration with Brian and Michael, I can update the
> > > > >> charter text in the tool.
> > > > >>
> > > > >> Regards, Benoit (OPS AD)
> > > > >>

---

From: Sheng Jiang <[email-masked]>
Date: Sun, 14 Sep 2014 07:33:15 +0000

Hi, Dimitri,

I understand your concerns. They are valid, but not as serious as you described.

We actually share the same understanding regarding to discovery. The different for discovery definition is only the matter of terminology choice. You used "agent" while we have "negotiation counterpart". We will follow whatever the future WG decides on this.

Yes, we have tied discovery and negotiation process together in our document, because we think, to be able to generic enough, the same agent may want to negotiate with different peers when the negotiation objecives are different, so the discovery process needs to be associated with negotiation objective. But it is certailly possible and easy to separate discovery and negotiation processes in our document, if it is the future WG consensus.

Thanks for your comments. But again, it is too early to discuss these details.

Regards,

Sheng
Sent: 14 September 2014 8:54

Jiang:

Thanks,
-dimitri.

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 15 Sep 2014 09:09:49 +0000

> (bclaise)
> Sent: 13 September 2014 09:30
> 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.
> > 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.
> Exactly.
> 
> I would like to draw to the attention of the draft-jiang-config-negotiation-
> protocol,
> draft-pritikin-bootstrapping-keyinfrastructures, and draft-behringer-
> autonomic-control-plane draft authors that IPR declarations are required,
> and that IPRs might be an important factor in a WG creation.

Thanks for the reminder, Benoit. There is IPR on draft-behringer-autonomic-control-plane, and that is declared (see datatracker), as well as for draft-pritikin-bootstrapping-keyinfrastructures, which we forgot to declare and are now in the process of doing so. (Background: This draft evolved from draft-behringer-homenet-trust-bootstrap, for which we DID declare the IPR, but we overlooked that for the new draft we need to declare again.). 

Michael

---

From: Laurent Ciavaglia <[email-masked]>
Date: Mon, 15 Sep 2014 13:05:54 +0200

Dear Benoit, all,

I am in favor of track nr. 2., and yes, I believe the WG should address 
such problem(s) (assuming I undestood correctly problem in this context 
as the set of functionalities in scope of the WG).

I would describe these parts (functionalities) in the charter by:
     -naming the functionality, short description, references (articles, 
I-Ds).

HTH, best regards, Laurent.

On 13/09/2014 09:24, Benoit Claise wrote:
>     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.
>
> 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 ...
>
>>> Cc: Benoit Claise;[email-masked]
>> In the latest version (as posted by Benoit<http://www.ietf.org/mail-archive/web/anima/current/msg00266.html>, I read:
>>
>> [specific goals]

-- 

Bien cordialement, Best regards,

*Laurent Ciavaglia*

Advanced Internet Research

Bell Labs | Alcatel Lucent

phone: +33 160 402 636

email: [email-masked] 
<mailto:[email-masked]>

linkedin: laurentciavaglia <http://fr.linkedin.com/in/laurentciavaglia/>

address: Route de Villejust | 91620 Nozay | France

---

From: Benoit Claise <[email-masked]>
Date: Wed, 24 Sep 2014 20:40:41 +0200

Dimitri,

Reading an old email thread, so maybe this point is not valid any 
longer, but anyway...
> I have explained technically why you document is not suited as 
> starting point and why initiating the work from the wrong starting 
> point will lead to more problems than be helpful. 
If you (still) believe it's the case, I encourage you (or anybody else) 
to write your own draft.

Regards, Benoit

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Wed, 24 Sep 2014 19:07:28 +0000

Benoit,

> Sent: Wednesday, September 24, 2014 8:41 PM
> To: Papadimitriou, Dimitri (Dimitri); Sheng Jiang; [email-masked]
> Reading an old email thread, so maybe this point is not valid any longer,
> but anyway...
> If you (still) believe it's the case, I encourage you (or anybody else) to
> write your own draft.

Yes it is. 

However this doesn't justify listing solution drafts in the charter. On the other let's assume we would like to show there is prior-work ... Why don't we list much more foundational document on multi-agent discovery / negotiation process in multi-agent systems ?

Regards,
-dimitri.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 25 Sep 2014 08:41:53 +1200

Dimitri,

If you have a specific reading list to suggest, please do so.
(Needless to say, for IETF work, these need to be freely available
documents, not behind a paywall.)

   Brian

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Wed, 24 Sep 2014 20:47:49 +0000

Brian,

I have already sent a couple of freely available readings ref's concerning negotiation and discovery process for multi-agent systems/MAS. Cf. <http://www.ietf.org/mail-archive/web/anima/current/msg00261.html>

Thanks,
-dimitri.

> Sent: Wednesday, September 24, 2014 10:42 PM
> Cc: Benoit Claise; Sheng Jiang; [email-masked]
> >> If you (still) believe it's the case, I encourage you (or anybody
> >> else) to write your own draft.
> >
> > Yes it is.
> >
> > However this doesn't justify listing solution drafts in the charter. On
> the other let's assume we would like to show there is prior-work ... Why
> don't we list much more foundational document on multi-agent discovery /
> negotiation process in multi-agent systems ?
> >
> > Regards,
> > -dimitri.
> >
> >> Regards, Benoit
> >

---

From: Benoit Claise <[email-masked]>
Date: Wed, 24 Sep 2014 23:45:20 +0200

Dimitri,

The references you mentioned ...

[Jen1998] N.R.Jennings, S.Parsons, P.Noriega, and C.Sierra. On 
argumentation-based negotiation, /Proceedings of the International 
Workshop on Multi-Agent Systems/, pages 1.7, Boston, USA, 1998.

[Jen2001] N.R.Jennings 
<http://link.springer.com/search?facet-author=%22N.R.+Jennings%22> et 
al., Automated Negotiation: Prospects, Methods and Challenges; Group 
Decision and Negotiation, March 2001, Volume 10, Issue 2, pp 199-215

Please also take a look at the following paper *on Negotiation in 
Multi-Agent Systems* from Martin Beer, Mark D'inverno, Michael Luck, 
Nick Jennings, Chris Preist, and Michael Schroeder. 1999. Negotiation in 
multi-agent systems./Knowl. Eng. Rev./14, 3 (September 1999), pp.285-289.

... are perfectly fine in draft (I guess), but not appropriate for a 
charter IMO.

Regards, Benoit

---

From: Rene Struik <[email-masked]>
Date: Wed, 24 Sep 2014 19:06:14 -0400

Hi Benoit:

Just a brief note (just in case I misinterpreted you here): I hope I am 
right in the sense that you are not arguing to adopt a draft, simply 
because there are currently no competing drafts, right? Draft should be 
judged on their merit and the merits of ideas incorporated in these and 
not on the basis of "electing a candidate, since there is only one on 
the list, no matter the profile/characteristics that should exhibited". 
In my mind, it is perfectly fine to have a vacancy for a while (to 
continue the candidacy analogy), if one has not found the proper 
candidate yt or has moving job descriptions.

Best regards, Rene

==

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Thu, 25 Sep 2014 01:55:26 +0000

Hi Benoit,

These documents provide clearer definitions of what negotiation means and implies (in particular they don’t limit negotiation to “messaging” i.e. specific data formats exchanges). These can be tuned for the needs of this effort as it progresses but at least there would be a common understanding of what the protocol work would cover.

This is what is currently missing towards an effective contribution process… do you think appropriate to face situations where after contributing one ends up with comments such as “sorry this is not what we mean by negotiation/discovery” and endless discussions between what some hypothetically meant (or not) and contributors understanding ?

Thanks,
-dimitri.

From: Benoit Claise [mailto:[email-masked]]
Sent: Wednesday, September 24, 2014 11:45 PM
To: Papadimitriou, Dimitri (Dimitri); Brian E Carpenter
Cc: Sheng Jiang; [email-masked]
Subject: Re: [Anima] Use of the chartering tool for ANIMA

Dimitri,

The references you mentioned ...
[Jen1998] N.R.Jennings, S.Parsons, P.Noriega, and C.Sierra. On argumentation-based negotiation, Proceedings of the International Workshop on Multi-Agent Systems, pages 1.7, Boston, USA, 1998.
[Jen2001] N.R.Jennings<http://link.springer.com/search?facet-author=%22N.R.+Jennings%22> et al., Automated Negotiation: Prospects, Methods and Challenges; Group Decision and Negotiation, March 2001, Volume 10, Issue 2, pp 199-215
Please also take a look at the following paper on Negotiation in Multi-Agent Systems from Martin Beer, Mark D'inverno, Michael Luck, Nick Jennings, Chris Preist, and Michael Schroeder. 1999. Negotiation in multi-agent systems. Knowl. Eng. Rev. 14, 3 (September 1999), pp.285-289.

... are perfectly fine in draft (I guess), but not appropriate for a charter IMO.

Regards, Benoit

Brian,

I have already sent a couple of freely available readings ref's concerning negotiation and discovery process for multi-agent systems/MAS. Cf. <http://www.ietf.org/mail-archive/web/anima/current/msg00261.html><http://www.ietf.org/mail-archive/web/anima/current/msg00261.html>

Thanks,

-dimitri.

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

Cc: Benoit Claise; Sheng Jiang; [email-masked]<mailto:[email-masked]>

Dimitri,

   Brian

Benoit,

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

To: Papadimitriou, Dimitri (Dimitri); Sheng Jiang; [email-masked]<mailto:[email-masked]>

Dimitri,

longer, but anyway...

Yes it is.

Regards,

-dimitri.

Regards, Benoit

Anima mailing list

[email-masked]<mailto:[email-masked]>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 25 Sep 2014 14:20:28 +1200

On 25/09/2014 13:55, Papadimitriou, Dimitri (Dimitri) wrote:
> Hi Benoit,
> 
> These documents provide clearer definitions of what negotiation means and implies (in particular they don’t limit negotiation to “messaging”

I'm confused. We design protocols here, so negotiation that doesn't
involve messages is by definition not in scope. Certainly I'd expect
the negotiation *algorithm* to depend heavily on the application...

> i.e. specific data formats exchanges). 

...and I would also expect the message format to depend heavily on
the application.

> These can be tuned for the needs of this effort as it progresses but at least there would be a common understanding of what the protocol work would cover.

In that case, why don't you contribute a draft that does exactly that?
Of the three drafts you mention, [Jen2001] is behind the Springer
pay wall so not much use for IETF purposes, and [Jen1998] seems to me to be
too general to actually tell me anything. [Beer1999] tells me one
interesting thing in particular:

"Can all aspects of negotiation be incorporated into predefined communication protocols?
Most members of the panel suggested that this is not possible and that it is the agent’s reasoning
model that is the key to successful negotiation."

That certainly seems true, which argues for a very simple underlying
protocol with minimal complexity.

Anyway, a draft written in IETF-speak that summarises the academic work
would, I think, be very helpful.

   Brian

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 25 Sep 2014 02:33:13 +0000

Hi, Dimitri,

Thanks so much for this. We will study them and put on the definition of negotiation/discovery into our draft. It would help us moving forward. I personally believe we do not have much different on the basic understanding. And for sure, we should continue discuss this and reach consensus when WG is created.

For now, my observation is that we have the same understanding that some generic negotiation/discovery function is needed.  I believe it is WG’s work to reach the consensus on the meaning of negotiation/discovery. I also believe our potential anima WG would be fair and would not adopt any drafts if any fundamental concepts did not reach WG consensus or at least rough consensus.

Best regards,

Sheng

From: Papadimitriou, Dimitri (Dimitri) [mailto:[email-masked]]
Sent: Thursday, September 25, 2014 9:55 AM
To: Benoit Claise; Brian E Carpenter
Cc: Sheng Jiang; [email-masked]
Subject: RE: [Anima] Use of the chartering tool for ANIMA

Hi Benoit,

Thanks,
-dimitri.

Cc: Sheng Jiang; [email-masked]<mailto:[email-masked]>

Dimitri,

Regards, Benoit

Brian,

Thanks,

-dimitri.

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

Dimitri,

   Brian

Benoit,

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

Dimitri,

longer, but anyway...

Yes it is.

Regards,

-dimitri.

Regards, Benoit

Anima mailing list

---

From: Benoit Claise <[email-masked]>
Date: Thu, 25 Sep 2014 09:45:31 +0200

Hi,

> Hi Benoit:
>
> Just a brief note (just in case I misinterpreted you here): I hope I 
> am right in the sense that you are not arguing to adopt a draft, 
> simply because there are currently no competing drafts, right? 
Correct.
> Draft should be judged on their merit and the merits of ideas 
> incorporated in these and not on the basis of "electing a candidate, 
> since there is only one on the list, no matter the 
> profile/characteristics that should exhibited". In my mind, it is 
> perfectly fine to have a vacancy for a while (to continue the 
> candidacy analogy), if one has not found the proper candidate yt or 
> has moving job descriptions.
We share the same thoughts.
During the call today, Laurent realized that there was a mistake in the 
deliverables

    Nov 2014 - WG formation and adoption of initial drafts (see "specific goals")
                - Mar IETF 92nd -

This deadline will be pushed.

Regards, Benoit

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Thu, 25 Sep 2014 11:36:08 +0000

Brian, all

> Sent: Thursday, September 25, 2014 4:20 AM
> > These documents provide clearer definitions of what negotiation means
> and implies (in particular they don’t limit negotiation to “messaging”
> 
> involve messages is by definition not in scope. Certainly I'd expect the
> negotiation *algorithm* to depend heavily on the application...

I am not calling for standardizing reasoning models (never stated this), just referring to the fact that the protocol work goes well beyond specifying formats/bits on the wire.

By the very nature of negotiation this wouldn't work (it is not a TE attribute exchange protocol we are building up where each node can apply its own TE algorithm).

> ...and I would also expect the message format to depend heavily on the
> application.
> 
> > These can be tuned for the needs of this effort as it progresses but at
> least there would be a common understanding of what the protocol work
> would cover.
> 
> Of the three drafts you mention, [Jen2001] is behind the Springer pay wall
> so not much use for IETF purposes, and [Jen1998] seems to me to be too
> general to actually tell me anything. 

I have provided possible use of this background by proposing definitions in

In general, this is one of my main concern for future working activities; if you look carefully at this thread the point was to define a scope to negotiation and discovery; alongside arguments I have hard time to follow ("pay walls", "general" while the scope is to be generic) the discussion is fading while we remain without a definition or refined scope of what negotiation or discovery imply which would have allowed us to progress.

Hence, the premises (some would call this the agreement on the problem statement and work coverage) are still not there while facing the following situation: on one hand, one doesn't want to include in the charter that such discussions are needed to refine them; on the other, they are needed for outsiders (people not involved in the list of documents part of the charter) to effectively contribute otherwise their role would be limited in e.g. surveying past research work, commenting and reviewing documents.

> [Beer1999] tells me one interesting thing in particular:
> 
> Most members of the panel suggested that this is not possible and that it
> is the agent’s reasoning model that is the key to successful negotiation."
>

This ref. brings the following point: if there is no bottomline understanding of what agent reasoning models entail, how to build the communication protocol (as it not possible to come with a solution without holistic view of the negotiation process and propose a predefined communication process) ? in other terms modularizing/decomposing at too early stage may lead to mismatch (in particular which parts are generic and not) --note: in any case communication would only be a part of the solution the working group aims at bringing.

> would, I think, be very helpful.

This would be needed (can certainly contribute). I didn't want to overload the mailing list with long lists of ref's. The question is how it will be used, to analyze a posteriori or to guide a priori. 

>    Brian
> 
> > This is what is currently missing towards an effective contribution
> process… do you think appropriate to face situations where after
> contributing one ends up with comments such as “sorry this is not what we
> mean by negotiation/discovery” and endless discussions between what some
> hypothetically meant (or not) and contributors understanding ?
> >
> > Thanks,
> > -dimitri.
> >
> >
> argumentation-based negotiation, Proceedings of the International Workshop
> on Multi-Agent Systems, pages 1.7, Boston, USA, 1998.
> > [Jen2001]
> > N.R.Jennings<http://link.springer.com/search?facet-
> author=%22N.R.+Jennings%22> et al., Automated Negotiation: Prospects,
> Methods and Challenges; Group Decision and Negotiation, March 2001, Volume
> 10, Issue 2, pp 199-215 Please also take a look at the following paper on
> Negotiation in Multi-Agent Systems from Martin Beer, Mark D'inverno,
> Michael Luck, Nick Jennings, Chris Preist, and Michael Schroeder. 1999.
> Negotiation in multi-agent systems. Knowl. Eng. Rev. 14, 3 (September
> 1999), pp.285-289.
> >
> > I have already sent a couple of freely available readings ref's
> > concerning negotiation and discovery process for multi-agent
> > systems/MAS. Cf.
> > <http://www.ietf.org/mail-archive/web/anima/current/msg00261.html><htt
> > p://www.ietf.org/mail-archive/web/anima/current/msg00261.html>
> >
> >
> >
> > Thanks,
> >
> > -dimitri.
> >
> >
> >
> >
> >
> >
> >