Subject: [Anima] Notes from the ANIMA Call Today

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 11 Sep 2014 13:31:08 +0000

Below are the notes I took, and the recording is here: 
https://cisco.webex.com/ciscosales/lsr.php?RCID=b7a36fd25d7946d6a843aff0927d7a93 

Michael

--

Notes from the ANIMA Call
11 Sep 2014, 6am GMT

Attendees
Bing Liu, Brian Carpenter, Dan Romascanu, Dimitri P., Laurent Ciavaglia, Sheng Jiang, Yu Fu, Michael Behringer (notes)

Notes
Sheng prepared v9 of the charter. Presented his current view on things. 

List of items where we have not consensus:
1) Methodology of this working group
Two different approaches at the moment, bottom up and top down. 

2) Selection of use cases
At which step do we plan the working group? What should be the first use cases? 

3) Common infrastructure components
Sheng: We should first work on those components, BEFORE working on use cases. 

Michael: Do we agree on infrastructure versus autonomic service agents? 
Yes. (no objection) 

Dimitri: We have service agents that exchange information. Use case driven approach. Sheng is a communication driven approach. 
Brian: Misunderstanding. Approach in proposed charter, we need to first understand communication layer. 
Dimitri: Communication is part of current charter, there are different modes. Negotiation for example. 
Laurent: The current negotiation proposal is just one proposal. But there are many potential solutions. 
Michael: The charter doesn't say the current draft is the chosen one. 
Laurent: Yes, but the boundary conditions are not clear. It is not clear which the requirements are for such a protocol. 
Sheng: Yes, but this should be the job of the working group, to define precise requirements, and work out a proposed protocol. 
Dimitri: Differnt means to translate negotiation requirements to protocol. If we don't have a broad overview we may go down the wrong track. Might end up in an open protocol. 
Brian: Completely agree. 
Michael: Problem statement seems to be: Do we describe the requirements BEFORE the charter or once we are chartered? 
Laurent: We need to be explicit that the charter is about functionalities, and it's the job of the working group to translate this into protocols. 
Sheng: This will take too long. 
Michael: Can we start with the simple communication methods, and expand as needed? 
Dimitri: master-slave, consensus based, gossip, and other mechanisms. That needs to be settled before we do the work. The charter must allow this. 
Dan: Can include in charter about infrastructure functional requirements. There should be a general requirements doc. 
Michael: ADs didn't want to start with a lengthy requirements process. 
Dan: Need an intermediate state. 
Dimitri: Charter needs to include "validate use cases against architecture". NMRG docs are a good starting point. Validation is key. Should have had an autonomic model document. Like for intserv/diffserv. 
Michael: Can we not start with a simple unicast negotiation method? 
Laurent: Need to worry about oscillation on a higher level. 
Dimitri: Need to work on use cases to derive requirements. Determine the use cases you need to determine this. Need a broad set of use cases to define boundaries (not requirements). We should select use cases by area, for example bootstrap. We need three areas. 1) Bootstrapping (self-configuration), 2) self-protection and 3) open, on self-healing for example. 
Sheng: So far no reporting area. There are many areas to work on. We don't know them yet. 
Dimitri: We DO know them. Self-* features. 
Laurent: The self-* features are in. 
Michael: Need to document the different viewpoints.

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Thu, 11 Sep 2014 13:46:14 +0000

Michael: 

At the end of the call, I also asked if it would be possible for Laurent to continue the exercise he has started (and posted before the call).
<http://www.ietf.org/mail-archive/web/anima/current/msg00242.html>

Thanks,
-dimitri.

> -----Original Message-----
> From: Anima [mailto:[email-masked]] On Behalf Of Michael Behringer
> (mbehring)
> Sent: Thursday, September 11, 2014 3:31 PM
> To: [email-masked]
> Subject: [Anima] Notes from the ANIMA Call Today
> 
> Bing Liu, Brian Carpenter, Dan Romascanu, Dimitri P., Laurent Ciavaglia,
> Sheng Jiang, Yu Fu, Michael Behringer (notes)
> 
> Notes
> Dimitri: We have service agents that exchange information. Use case driven
> approach. Sheng is a communication driven approach.
> Laurent: Yes, but the boundary conditions are not clear. It is not clear
> which the requirements are for such a protocol.
> Sheng: Yes, but this should be the job of the working group, to define
> precise requirements, and work out a proposed protocol.
> Dimitri: Differnt means to translate negotiation requirements to protocol.
> If we don't have a broad overview we may go down the wrong track. Might
> end up in an open protocol.
> Brian: Completely agree.
> Michael: Problem statement seems to be: Do we describe the requirements
> BEFORE the charter or once we are chartered?
> Laurent: We need to be explicit that the charter is about functionalities,
> and it's the job of the working group to translate this into protocols.
> Dimitri: master-slave, consensus based, gossip, and other mechanisms. That
> needs to be settled before we do the work. The charter must allow this.
> Dan: Can include in charter about infrastructure functional requirements.
> There should be a general requirements doc.
> Dimitri: Charter needs to include "validate use cases against
> architecture". NMRG docs are a good starting point. Validation is key.
> Should have had an autonomic model document. Like for intserv/diffserv.
> Dimitri: Need to work on use cases to derive requirements. Determine the
> use cases you need to determine this. Need a broad set of use cases to
> define boundaries (not requirements). We should select use cases by area,
> for example bootstrap. We need three areas. 1) Bootstrapping (self-
> configuration), 2) self-protection and 3) open, on self-healing for
> example.
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

Subject: Charter draft-10
From: "CIAVAGLIA, LAURENT (LAURENT)" <[email-masked]>
To: anima <[email-masked]>
Cc: Brian E Carpenter <[email-masked]>, Michael Behringer <[email-masked]>, Sheng Jiang <[email-masked]>, "Toerless Eckert (eckert)" <[email-masked]>, "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Thu, 11 Sep 2014 03:38:40 +0000

Dear all,

I have made the exercise to combine for the better (and the worse ;p) the latest draft charters posted (-09-Sheng, -v03-Dimitri) plus some of the comments made on the list on that topic.

I sincerely hope this version will help to reach / increase the consensus among us.

Some points remains TBD, but I think we can sort these out if we agree on the other parts (which are stabilized / not conflictual).

Talk to you soon (or via email).

--

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

*       English - detected
*       English
*       French

*       English
*       French

<javascript:void(0);>

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 11 Sep 2014 13:48:36 +0000

Thanks for the clarification / correction. All, please don't hesitate to flag issues like Dimitri just did. 

Michael

> From: Papadimitriou, Dimitri (Dimitri)
> [mailto:[email-masked]]
> Sent: 11 September 2014 15:46
> To: Michael Behringer (mbehring); [email-masked]
> Subject: RE: Notes from the ANIMA Call Today
> 
> Michael:
> 
> At the end of the call, I also asked if it would be possible for Laurent to
> continue the exercise he has started (and posted before the call).
> https://cisco.webex.com/ciscosales/lsr.php?RCID=b7a36fd25d7946d6a843af
> > f092
> > 7d7a93
> >
> > Michael
> >
> > --
> >
> >
> >
> > Bing Liu, Brian Carpenter, Dan Romascanu, Dimitri P., Laurent
> > Ciavaglia, Sheng Jiang, Yu Fu, Michael Behringer (notes)
> >
> > Notes
> > Sheng: We should first work on those components, BEFORE working on
> use
> > cases.
> >
> > Dimitri: We have service agents that exchange information. Use case
> > driven approach. Sheng is a communication driven approach.
> > Laurent: Yes, but the boundary conditions are not clear. It is not
> > clear which the requirements are for such a protocol.
> > If we don't have a broad overview we may go down the wrong track.
> > Might end up in an open protocol.
> > Brian: Completely agree.
> > Michael: Problem statement seems to be: Do we describe the
> > requirements BEFORE the charter or once we are chartered?
> > Laurent: We need to be explicit that the charter is about
> > functionalities, and it's the job of the working group to translate this into
> protocols.
> > Dimitri: master-slave, consensus based, gossip, and other mechanisms.
> > That needs to be settled before we do the work. The charter must allow
> this.
> > Dimitri: Need to work on use cases to derive requirements. Determine
> > the use cases you need to determine this. Need a broad set of use
> > cases to define boundaries (not requirements). We should select use
> > cases by area, for example bootstrap. We need three areas. 1)
> > Bootstrapping (self- configuration), 2) self-protection and 3) open,
> > on self-healing for example.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 12 Sep 2014 08:25:43 +1200

> Dimitri: Charter needs to include "validate use cases against architecture". NMRG docs are a good starting point. Validation is key. Should have had an autonomic model document. Like for intserv/di…

Let's not rewrite history. The diffserv architecture document (RFC 2475) was
produced in parallel with the protocol document (RFC 2474) not in advance.
Actually the starting point for diffserv was the "two-bit" draft which was
a preliminary protocol design in 1997, later published for the record as
RFC 2638.

That's the model we're proposing to repeat in the v9 charter:
"It is essential that these components and solutions fit together as an integrated whole.
For this reason, an overview document will be developed in parallel with the individual
specifications."
(That reflects my prejudice that "architecture" is a big word that the
IETF does well to avoid, whereas "overview" is more modest. But it's
really the same thing.)

I don't know the history of IntServ in similar detail, but since that
effort failed, and NSIS seems likely to fail too, they are not models
that we should follow, are they?

    Brian

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Thu, 11 Sep 2014 22:12:39 +0000

> From: Anima [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Thursday, September 11, 2014 10:26 PM
> To: Michael Behringer (mbehring)
> Cc: [email-masked]
> Subject: Re: [Anima] Notes from the ANIMA Call Today
> 

I referred to IntServ (RFC 1633) which documented a model and its components to derive signaling such as RSVP (RFC 2205) --see also mailing list
<http://www.ietf.org/mail-archive/web/anima/current/msg00237.html>

--> I didn't refer to DiffServ (this should be corrected in the minutes) neither aimed at rewriting history. 

> Let's not rewrite history. The diffserv architecture document (RFC 2475)
> was produced in parallel with the protocol document (RFC 2474) not in
> advance.

The issue is the term "solutions": one would expect a single/unified solution, target which can't be reconciled with the reduced set of cases considered so far. By bundling the set of cases in the charter and mandating protocols shall only be applicable to them, one de-facto locks this group (from both ends) following the reasoning that the necessary condition (specific solution/protocol) is a sufficient condition -- whereas it is provably insufficient.

> For this reason, an overview document will be developed in parallel with
> the individual specifications."
> effort failed, and NSIS seems likely to fail too, they are not models that
> we should follow, are they?

I didn't make such statement. I stated that as long as RSVP protocol had been designed alongside with a model IntServ/RFC 1633 the protocol specification remained well articulated; on the other hand, efforts to provide next steps without identifying objective boundaries lead unfortunately to an open ended protocol effort though it had shown that translating functionality into protocols has no unique 1:1 match; hence, articulation of the anima tasks would benefit from exploiting what has been learned out of these experiences.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 12 Sep 2014 11:30:38 +1200

> I didn't make such statement. I stated that as long as RSVP protocol had been designed alongside with a model IntServ/RFC 1633 the protocol specification remained well articulated; on the other han…

OK. I understand that you didn't mention diffserv, but in my view
(prejudiced, since I was WG co-chair), the diffserv case worked
out quite well. The WG -00 drafts for protocol and architecture
were posted at the same time (May 1998). Ever since RFC 2474/5,
several of us have carefully reviewed every proposal for a new
diffserv PHB for coherence with the architecture. I am not really
disagreeing with you and I think this approach is what the v9
charter leads to.

I also agree that the proposed discovery/negotiation protocol
cannot be selected or designed without a context. Actually,
that's exactly why draft-jiang-config-negotiation-ps exists.

    Brian

---

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

> "It is essential that these components and solutions fit together as

The issue is the term "solutions": one would expect a single/unified solution, target which can't be reconciled with the reduced set of cases considered so far. 

By bundling the set of cases in the charter (instead of functionality) and mandating protocols shall only be applicable to them, one de-facto locks this group from both ends following the reasoning that the necessary condition (specific solution/protocol) is a sufficient condition to get it right -- whereas this condition is insufficient as long as one doesn't prove the contrary -- 

Putting this under the argument of AD desire of "speed" and "focus" makes situation even worse as diverting from the real questions this charter should provide answers to "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 ?", etc.
 
-d.
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Friday, September 12, 2014 1:31 AM
> To: Papadimitriou, Dimitri (Dimitri)
> Cc: Michael Behringer (mbehring); [email-masked]
> > I referred to IntServ (RFC 1633) which documented a model and its
> > components to derive signaling such as RSVP (RFC 2205) --see also
> > mailing list
> >> Let's not rewrite history. The diffserv architecture document (RFC
> >> 2475) was produced in parallel with the protocol document (RFC 2474)
> >> not in advance.
> >> Actually the starting point for diffserv was the "two-bit" draft
> >> which was a preliminary protocol design in 1997, later published for
> >> the record as RFC 2638.
> >>
> > The issue is the term "solutions": one would expect a single/unified
> solution, target which can't be reconciled with the reduced set of cases
> considered so far. By bundling the set of cases in the charter and
> mandating protocols shall only be applicable to them, one de-facto locks
> this group (from both ends) following the reasoning that the necessary
> condition (specific solution/protocol) is a sufficient condition --
> whereas it is provably insufficient.
> >
> >> For this reason, an overview document will be developed in parallel
> >> with the individual specifications."
> >> (That reflects my prejudice that "architecture" is a big word that
> >> the IETF does well to avoid, whereas "overview" is more modest. But
> >> it's really the same thing.)
> >>
> > I didn't make such statement. I stated that as long as RSVP protocol had
> been designed alongside with a model IntServ/RFC 1633 the protocol
> specification remained well articulated; on the other hand, efforts to
> provide next steps without identifying objective boundaries lead
> unfortunately to an open ended protocol effort though it had shown that
> translating functionality into protocols has no unique 1:1 match; hence,
> articulation of the anima tasks would benefit from exploiting what has
> been learned out of these experiences.
> 
> (prejudiced, since I was WG co-chair), the diffserv case worked out quite
> well. The WG -00 drafts for protocol and architecture were posted at the
> same time (May 1998). Ever since RFC 2474/5, several of us have carefully
> reviewed every proposal for a new diffserv PHB for coherence with the
> architecture. I am not really disagreeing with you and I think this
> approach is what the v9 charter leads to.
> 
> I also agree that the proposed discovery/negotiation protocol cannot be
> selected or designed without a context. Actually, that's exactly why
> draft-jiang-config-negotiation-ps exists.
> 
>     Brian

---

From: Laurent Ciavaglia <[email-masked]>
Date: Fri, 12 Sep 2014 14:53:08 +0200

Dear Michael,

Thanks for taking and sharing the minutes, and driving this call ;)

Two corrections in the minutes: (my last two comments of the call)
1) Laurent: Need to worry about oscillation on a higher level.
     --> Laurent: in some cases, unicast communication is not suited to 
coordinate multiple autonomic functions (how to resolve conflicts, 
avoidoscillations, etc.). other means should be considered. this is what 
we need to define (i.e. the negotiation functionality boundaries) before 
specifying the protocol(s).

2) Laurent: The self-* features are in.
     --> as written in charter -10, the conventional self-chop features 
are in: configuration, protection, healing and optimization. these 
should be the minimal basis for the group scope.

Thanks, best regards, Laurent.

-- 

*Laurent Ciavaglia*

phone: +33 160 402 636

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

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

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Fri, 12 Sep 2014 13:05:43 +0000

Laurent,
Thanks for the corrections. It's difficult to participate in the discussion AND try to catch everything correctly, so I count on everybody to provide such corrections if needed. BTW, I don't think we need to re-do those notes, since the notes AND your (and Dimitri's) comments are in the same mail thread in the archive. Do you agree?
Personally, I think a lot of these discussions will be easier and clearer when we're actually arguing about a protocol or method.
I think the charter has been sometimes misunderstood as "we will do this and nothing else", whereas the intent is "our initial focus is this". (And we say this explicitly)  In my view all of the points you raise MUST be raised, but I think we'll raise them when we discuss the solutions.
Michael

From: Laurent Ciavaglia [mailto:[email-masked]]
Sent: 12 September 2014 14:53
To: Michael Behringer (mbehring); [email-masked]
Subject: Re: [Anima] Notes from the ANIMA Call Today

Dear Michael,

Two corrections in the minutes: (my last two comments of the call)
1) Laurent: Need to worry about oscillation on a higher level.
    --> Laurent: in some cases, unicast communication is not suited to coordinate multiple autonomic functions (how to resolve conflicts, avoid oscillations, etc.). other means should be considered. this is what we need to define (i.e. the negotiation functionality boundaries) before specifying the protocol(s).

2) Laurent: The self-* features are in.
    --> as written in charter -10, the conventional self-chop features are in: configuration, protection, healing and optimization. these should be the minimal basis for the group scope.

Michael

--

11 Sep 2014, 6am GMT

Attendees

Notes

Yes. (no objection)

Brian: Completely agree.

Anima mailing list

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

Laurent Ciavaglia

phone: +33 160 402 636

---

From: Laurent Ciavaglia <[email-masked]>
Date: Fri, 12 Sep 2014 15:54:01 +0200

Michael,

please see inline.

On 12/09/2014 15:05, Michael Behringer (mbehring) wrote:
>
> Laurent,
>
> Thanks for the corrections. It's difficult to participate in the 
> discussion AND try to catch everything correctly, so I count on 
> everybody to provide such corrections if needed. BTW, I don't think we 
> need to re-do those notes, since the notes AND your (and Dimitri's) 
> comments are in the same mail thread in the archive. Do you agree?
>
yes, of course.

> Personally, I think a lot of these discussions will be easier and 
> clearer when we're actually arguing about a protocol or method.
>
As discussed yesterday on the call: first define the boundaries of the 
functionality, then specify the protocols.
It is the understanding of the boundaries of the functionality as a 
reusable component to solve several cases that will create the value 
(/genericity) in the protocols.
Also there is no automatic 1:1 mapping of the set of functionality to 
the set of protocols.

> I think the charter has been sometimes misunderstood as "we will do 
> this and nothing else", whereas the intent is "our initial focus is this".
>
yes, probably.
what is not helping to solve this impression ("this and nothing else"), is
     -that the charter v1-9 are explicitly naming 2 cases, leaving 
no/few room to others.
     -that the focus is on "protocolsfirst and protocolsonly" instead of 
functionality and protocols (charter v10 is proposing a fast track to 
"test" 1 functionality / protocol(s) in parallel to the progress of the 
other WG activities).

> (And we say this explicitly)  In my view all of the points you raise 
> MUST be raised, but I think we'll raise them when we discuss the 
> solutions.
>
Agreed. One of my concerns is that the initial scope in open enough to 
attract a large base of contributions/contributors. Said in other words: 
will potential contributors find areas (e.g. config., healing, protect., 
optim.) where their problems/interests/competencies can be 
addressed/applied.

> Michael
>
> *From:*Laurent Ciavaglia [mailto:[email-masked]]
> *Sent:* 12 September 2014 14:53
> *To:* Michael Behringer (mbehring); [email-masked]
> *Subject:* Re: [Anima] Notes from the ANIMA Call Today
>
> Dear Michael,
>
> avoid oscillations, etc.). other means should be considered. this is 
> what we need to define (i.e. the negotiation functionality boundaries) 
> before specifying the protocol(s).
>
>     [email-masked]  <mailto:[email-masked]>
>

-- 

*Laurent Ciavaglia*

phone: +33 160 402 636

---

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

Michael,
If the charter has been sometimes misunderstood as "we will do this and nothing else", whereas the intent is "our initial focus is this"  can you explain me how to deal with the following situation. I am interested in the following part
[specific goals]
o Definition of a discovery and negotiation protocol for autonomic functions
I have tried to explain during the call that underneath "negotiation" sits the problem by which a collection of interacting agents aim at reaching agreement in order to realize an "intent" is a key aspect of the work. Renumbering/address management being outside my scope/interest, how practically the charter does allow me to work in this item when it states:
The working group will initially consider a simple example as a test case for further work.
o Definition of solution for IPv6 prefix management within a network
There is however a broader technical point of concern, the charter aims defining such component but for instance behind the term negotiation we understand different things Section 2.3 http://tools.ietf.org/html/draft-jiang-config-negotiation-ps-03 is about base information exchange (more precisely a base description of what [Jen1998] [Jen2001] describes as the negotiation object. Thus missing i) the actual "negotiation protocols are the set of rules that govern the interaction. This covers, the permissible types of participants (e.g., the negotiators and relevant third parties), the negotiation states (e.g., accepting bids, negotiation closed), the events that cause state transitions (e.g., no more bidders, bid accepted), and the valid actions of the participants in particular states (e.g., which can be sent by whom, to whom and at when)." and ii) the agents' reasoning models which provide "the decision making apparatus by which participants attempt to achieve their objectives. 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"
Negotiation in the present context following [Jen1998] can indeed be viewed as a "distributed search through a space of potential agreements about some joint problem [...] To improve the efficiency of the negotiation process, the recipient needs to be able to provide more useful feedback on the proposals it receives than just whether or not it agrees to them. This feedback can take the form of a critique (comments on which parts of the proposal the agent likes or dislikes) or a counter-proposal (an alternative proposal generated in response to a proposal). From such feedback, the proposer should be able to generate a proposal which is more likely to lead to an agreement (if it chooses to do so).

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

Thanks,
-dimitri.

From: Anima [mailto:[email-masked]] On Behalf Of Michael Behringer (mbehring)
Sent: Friday, September 12, 2014 3:06 PM
To: CIAVAGLIA, LAURENT (LAURENT); [email-masked]
Subject: Re: [Anima] Notes from the ANIMA Call Today

Laurent,

From: Laurent Ciavaglia [mailto:[email-masked]]
Sent: 12 September 2014 14:53
To: Michael Behringer (mbehring); [email-masked]<mailto:[email-masked]>
Subject: Re: [Anima] Notes from the ANIMA Call Today

Dear Michael,

Michael

--

11 Sep 2014, 6am GMT

Attendees

Notes

Yes. (no objection)

Brian: Completely agree.

Anima mailing list

Laurent Ciavaglia

phone: +33 160 402 636

---

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

On 12/09/2014 15:54, Laurent Ciavaglia wrote:
>> everybody to provide such corrections if needed. BTW, I don't think 
>> we need to re-do those notes, since the notes AND your (and 
>> Dimitri's) comments are in the same mail thread in the archive. Do 
>> you agree?
>>
> yes, of course.
>
>     -that the focus is on "protocolsfirst and protocolsonly" instead 
> of functionality and protocols (charter v10 is proposing a fast track 
> to "test" 1 functionality / protocol(s) in parallel to the progress of 
> the other WG activities).
>
> attract a large base of contributions/contributors. Said in other 
> words: will potential contributors find areas (e.g. config., healing, 
> protect., optim.) where their problems/interests/competencies can be 
> addressed/applied.
The development of autonomic networking use cases, according to the 
criteria at 
http://www.ietf.org/proceedings/90/slides/slides-90-ucan-0.pdf, is 
encouraged, but we have to understand that not all uses cases can be 
considered in an initial charter.

Regards, Benoit
>>     --> Laurent: in some cases, unicast communication is not suited 
>> to coordinate multiple autonomic functions (how to resolve conflicts, 
>> what we need to define (i.e. the negotiation functionality 
>> boundaries) before specifying the protocol(s).
>>
>>     --> as written in charter -10, the conventional self-chop 
>> features are in: configuration, protection, healing and optimization. 
>> these should be the minimal basis for the group scope.
>>

---

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

Dimitri,
>
> Michael,
>
> If the charter has been sometimes misunderstood as "we will do this 
> and nothing else", whereas the intent is "our initial focus is this"
>
I believe it's covered by the charter.

The scope of this working group's effort for the initial stage is much
more modest

> can you explain me how to deal with the following situation. I am 
> interested in the following part
>
> /[specific goals]/
>
> /o Definition of a discovery and negotiation protocol for autonomic 
> functions/
>
> I have tried to explain during the call that underneath "negotiation" 
> sits theproblem by which a collection of interacting/agents/ aim at 
> reaching agreement in order to realize an "intent" is a key aspect of 
> the work. Renumbering/address management being outside my 
> scope/interest, how practically the charter does allow me to work in 
> this item when it states:
>
> /The working group will initially consider a simple example as a test 
> case for further work. /
>
That text improved in the just-posted draft version. See 
https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-anima%2Fwithmilestones-00-04.txt&difftype=--html&submit=Go!&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-anima%2Fwithmilestones-00-05.txt
>
> //
>
> /o Definition of solution for IPv6 prefix management within a network/
>
I agree that this bullet is not described enough.

Regards, Benoit
>
> //
>
> There is however a broader technical point of concern, the charter 
> aims defining such component but for instance behind the term 
> negotiation we understand different things Section 2.3 
> http://tools.ietf.org/html/draft-jiang-config-negotiation-ps-03 is 
> about base information exchange (more precisely a base description of 
> what [Jen1998] [Jen2001] describes as the negotiation object. Thus 
> missing i) the actual "*_negotiation protocols_* are the set of rules 
> that govern the interaction. This covers, the permissible types of 
> participants (e.g., the negotiators and relevant third parties), the 
> negotiation states (e.g., accepting bids, negotiation closed), the 
> events that cause state transitions (e.g., no more bidders, bid 
> accepted), and the valid actions of the participants in particular 
> states (e.g., which can be sent by whom, to whom and at when)." and 
> ii) the *_agents' reasoning models_* which provide "the decision 
> making apparatus by which participants attempt to achieve their 
> objectives. 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"
>
> Negotiation in the present context following [Jen1998] can indeed be 
> viewed as a "distributed search through a space of potential 
> agreements about some joint problem [...] To improve the efficiency of 
> the negotiation process, the recipient needs to be able to provide 
> more useful feedback on the proposals it receives than just whether or 
> not it agrees to them. This feedback can take the form of a critique 
> (comments on which parts of the proposal the agent likes or dislikes) 
> or a counter-proposal (an alternative proposal generated in response 
> to a proposal). From such feedback, the proposer should be able to 
> generate a proposal which is more likely to lead to an agreement (if 
> it chooses to do so).
>
> [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.
>
> Thanks,
>
> -dimitri.
>
> *From:*Anima [mailto:[email-masked]] *On Behalf Of *Michael 
> Behringer (mbehring)
> *Sent:* Friday, September 12, 2014 3:06 PM
> *To:* CIAVAGLIA, LAURENT (LAURENT); [email-masked]
> this and nothing else", whereas the intent is "our initial focus is 
> this". (And we say this explicitly)  In my view all of the points you 
> raise MUST be raised, but I think we'll raise them when we discuss the 
> solutions.
>
> Michael
>
> *To:* Michael Behringer (mbehring); [email-masked] <mailto:[email-masked]>

---

From: Rene Struik <[email-masked]>
Date: Fri, 12 Sep 2014 12:12:15 -0400

Dear colleagues:

I did not want to comment on the mailing list prior to me circulating 
comments on the all the drafts mentioned in the charter, but the AD 
artillery at this stage kind of forces me to weigh-in.

First of all, I have not read draft charter 09 (or the mock version 10) 
yet {these are only 1 1/2 day fresh though}; nor did I participate in 
the last conference call (in the middle of my sleep cycle).

Here is my quick feedback on charter status/controversy:
- main concern with draft charter discussions is that, while the BOF had 
~200 people in attendance, discussions on the call/mailing list seem to 
draw in only a handful of people. This does not bode well for support 
for the effort. {It could be that people are intimidated by presumably 
having to read the drafts mentioned in the charter first (I was 
intimidated by this myself, but now did all this, and also read the 40 
page survey on autonomic networking).} This makes me wonder why not more 
people are interested. [It has some advantages as well, since sometimes 
a small group works better.]
- second concern is that, at least with prior versions of the draft 
charter, specific draft solutions were seemingly taken as deliverable 
direction. In my mind, it would be better to describe the problem areas 
the soon to be WG is supposed to work on (hence, my question to you on 
ACP one para description).
- third concern is that there seems to be a divide in "camps" that I 
would like to understand better. Wouldn't it be better to try and bridge 
this before sending stuff the direction of an AD (esp. when so few 
people are involved)?

I would think trying to understand what drives the different "camps" has 
priority. Perhaps, some massaging cycles help here?

Having 10 draft charter drafts is okay, esp. since most of them happened 
in the August time window (when also Benoit Claise was on vacation, so 
it seems...). By itself, the version number does not indicate concensus 
or stability.

Here is my own action plan/to-dos in this area:
- Describe the three areas that are supposedly to be tackled first in 
one para, no other context required, language. Idea here is to make the 
charter readable for non-expert readers
- Circulate my comments on the various drafts mentioned in various draft 
charters (I have lots of comments on, e.g., the definition draft and 
some fundamental ones on each of the three solution drafts).

The two items above I had originally plan to complete last weekend; I 
hope to be able to do this by Mon-Tue next week.

Personally, I think the draft charter controversies have a bigger chance 
to be addressed by a) having a clear description of what the group wants 
to accomplish; (b) having some actual technical discussion on the 
solution drafts, definition/gap analysis drafts, which - so far - have 
been hard to trace.

Hence, my action plan above. Once again, apologies for delays in 
circulating "deeper" inputs here (I am not a salaried employee ... and 
volunteer in this efforts, because think it is important and useful, if 
done right).

Best regards, Rene

On 9/12/2014 11:57 AM, Benoit Claise wrote:
>> agreements about some joint problem [...] To improve the efficiency 
>> of the negotiation process, the recipient needs to be able to provide 
>> more useful feedback on the proposals it receives than just whether 
>> or not it agrees to them. This feedback can take the form of a 
>> critique (comments on which parts of the proposal the agent likes or 
>> dislikes) or a counter-proposal (an alternative proposal generated in 
>> response to a proposal). From such feedback, the proposer should be 
>> able to generate a proposal which is more likely to lead to an 
>> agreement (if it chooses to do so).
>>
>> raise MUST be raised, but I think we'll raise them when we discuss 
>> the solutions.
>>
>> Michael
>>
>> <mailto:[email-masked]>

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

---

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

> a small group works better.]

I am not actually surprised at this. I would have preferred a
few more people to chime in with independent opinions, but
frankly many people find charter discussions a bit boring, and
we haven't been discussing concrete proposals.

> ACP one para description).

The "starting point" drafts have been removed from the charter.
I think the problem area is fairly well described in the NMRG
dcouments I (and increasingly in the charter as it has expanded).

> this before sending stuff the direction of an AD (esp. when so few

We have been trying; that's exactly why there were so many
versions of the charter. Speaking personally, I believe that we
have responded to every point that has been raised, while
considering the advice we were given by the ADs in Toronto.

> charter readable for non-expert readers

Well, that's exactly why I wanted the starting point drafts
mentioned in the charter; summarising each draft in one
paragraph is hard.

> charters (I have lots of comments on, e.g., the definition draft 

That is an NMRG document, not part of the chartering discussion.

> and

But we were asked to remove them from the charter. Of course,
I welcome technical discussion, when we have a WG to discuss in.

> to accomplish; 

I believe that the current draft charter is completely clear on
that.

(b) having some actual technical discussion on the
> solution drafts, definition/gap analysis drafts, which - so far - have

That is the work of the WG, not of a chartering discussion,
IMHO. I look forward to it.

   Brian

>>>     Dimitri: We have service agents that exchange information. Use
>>> case driven approach. Sheng is a communication driven approach.
>>>
>>>     Dimitri: Communication is part of current charter, there are
>>> different modes. Negotiation for example.
>>>
>>>     Laurent: Yes, but the boundary conditions are not clear. It is
>>> not clear which the requirements are for such a protocol.
>>>
>>>     Sheng: Yes, but this should be the job of the working group, to
>>> define precise requirements, and work out a proposed protocol.
>>>
>>>     Dimitri: Differnt means to translate negotiation requirements to
>>> protocol. If we don't have a broad overview we may go down the wrong
>>> track. Might end up in an open protocol.
>>>
>>>     Brian: Completely agree.
>>>
>>> functionalities, and it's the job of the working group to translate
>>> this into protocols.
>>>
>>>     Dimitri: master-slave, consensus based, gossip, and other
>>> mechanisms. That needs to be settled before we do the work. The
>>> charter must allow this.
>>>
>>>     Dan: Can include in charter about infrastructure functional
>>> requirements. There should be a general requirements doc.
>>>
>>> architecture". NMRG docs are a good starting point. Validation is
>>> key. Should have had an autonomic model document. Like for
>>> intserv/diffserv.
>>>
>>>     Dimitri: Need to work on use cases to derive requirements.
>>> Determine the use cases you need to determine this. Need a broad set
>>> of use cases to define boundaries (not requirements). We should
>>> select use cases by area, for example bootstrap. We need three areas.
>>> 1) Bootstrapping (self-configuration), 2) self-protection and 3)
>>> open, on self-healing for example.
>>>
> ------------------------------------------------------------------------
>

---

From: Laurent Ciavaglia <[email-masked]>
Date: Mon, 15 Sep 2014 12:55:31 +0200

Dear Benoit, all,

[snip]

On 12/09/2014 17:47, Benoit Claise wrote:
>> Agreed. One of my concerns is that the initial scope in open enough 
>> to attract a large base of contributions/contributors. Said in other 

The proposed alternative is rather to consider in the initial charter a 
set of functionalities (e.g. negotiation, discovery, bootstrapping...) 
we agree on, and review use cases against those to start the process.

Thanks, Laurent.

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 17 Sep 2014 16:51:14 +0000

Hi Dimitri,
Sorry for a late reply, but your emails are not easy to digest :)   But I think I found one point that may get us further:
You write that we are "missing i) the actual "negotiation protocols are the set of rules that govern the interaction."  Actually, that is by design! :)  The rules that govern the interaction are defined in the autonomic service agents, which to design are outside scope for this WG. So I think we CAN focus on the bits on the wire, and that is exactly what the draft does.
In other words: At this point in time, the autonomic infrastructure focuses on the low level interactions. The way I see it:
We are following an "iterative" approach:

1)      take two use cases (ie autonomic service agents that would use an autonomic infrastructure)

2)      Figure out what the infrastructure needs to provide as "services" to those autonomic service agents

3)      write some drafts to keep track of what the ANI needs to do

4)      select more use cases, go to 2)
Bottom line: we add functionality over the iterations. Over time we'll also increase the value of the An infrastructure. We only "call it a day" when we are satisfied to have done something useful that's worth sticking into an RFC.
Can we live with the first iteration not being complete nor perfect, and adding more functionality in a second round?
Michael
From: Papadimitriou, Dimitri (Dimitri) [mailto:[email-masked]]
Sent: 12 September 2014 17:06
To: Michael Behringer (mbehring); CIAVAGLIA, LAURENT (LAURENT)
Cc: [email-masked]
Subject: RE: [Anima] Notes from the ANIMA Call Today

Michael,

Thanks,
-dimitri.

From: Anima [mailto:[email-masked]] On Behalf Of Michael Behringer (mbehring)
Sent: Friday, September 12, 2014 3:06 PM
To: CIAVAGLIA, LAURENT (LAURENT); [email-masked]<mailto:[email-masked]>
Subject: Re: [Anima] Notes from the ANIMA Call Today

Laurent,

Dear Michael,

Michael

--

11 Sep 2014, 6am GMT

Attendees

Notes

Yes. (no objection)

Brian: Completely agree.

Anima mailing list

Laurent Ciavaglia

phone: +33 160 402 636

---

From: Rene Struik <[email-masked]>
Date: Thu, 18 Sep 2014 09:59:08 -0400

Dear colleagues:

As you saw, I did review six documents all mentioned in the draft 
charter and posted thorough reviews on five of these:
review of draft-irtf-nmrg-autonomic-network-definitions-03, see 
http://www.ietf.org/mail-archive/web/anima/current/msg00297.html
review of draft-irtf-nmrg-an-gap-analysis-01, see 
http://www.ietf.org/mail-archive/web/anima/current/msg00298.html
review of draft-jiang-config-negotiation-ps-03, see 
http://www.ietf.org/mail-archive/web/anima/current/msg00306.html
review of draft-jiang-config-negotiation-protocol-02, see 
http://www.ietf.org/mail-archive/web/anima/current/msg00309.html
review of draft-behringer-autonomic-control-plane-00, see 
http://www.ietf.org/mail-archive/web/anima/current/msg00317.html
review of draft-pritikin-bootstrapping-keyinfrastructures-00 (still pending)

 From these detailed reviews, it should be clear that there are lots of 
questions on the design goals, gaps and design philosophy, and three 
solution drafts floating around for now. I also had trouble finding a 
succinct analysis of what is required and what is missing in prior RFC art.

I would strongly suggest putting this whole effort on hold and improving 
the supposedly "baseline documents" that underpin the draft charter, 
since those underpinnings are very hard to understand (also for me after 
spending considerable time on this). I think the solution drafts leave 
so many questions and lack so much analysis, that it is highly premature 
to consider these as suitable basis for working group deliberations.

I would like to see this group succeed. I do know that some of the 
proponents of the draft charter also have a stake (as co-author) in all 
the drafts I critically examined. So, one can choose to move ahead on 
procedural grounds, no matter technical reservations regarding the 
foundations of this effort. We are all technical people, though, and I 
hope you would all agree that we ned to go back to the drawing board and 
improve the currently shaky foundations first.

Personally, I disagree with the assessment one has to include solution 
drafts in a charter (no matter whether an AD might have suggested so), 
esp. if one has an extremely hard time to trace any technical discussion 
on mailing lists. My technical reviews were aimed at filling this void.

Let us not bury ourselves in procedural arm-wrestling; this topic area 
is important enough to do right and not start on the wrong footing.

Best regards, Rene

On 9/12/2014 12:12 PM, Rene Struik wrote:
> First of all, I have not read draft charter 09 (or the mock version 
> 10) yet {these are only 1 1/2 day fresh though}; nor did I participate 
> in the last conference call (in the middle of my sleep cycle).
>
> - main concern with draft charter discussions is that, while the BOF 
> had ~200 people in attendance, discussions on the call/mailing list 
> seem to draw in only a handful of people. This does not bode well for 
> support for the effort. {It could be that people are intimidated by 
> presumably having to read the drafts mentioned in the charter first (I 
> was intimidated by this myself, but now did all this, and also read 
> the 40 page survey on autonomic networking).} This makes me wonder why 
> not more people are interested. [It has some advantages as well, since 
> sometimes a small group works better.]
> direction. In my mind, it would be better to describe the problem 
> areas the soon to be WG is supposed to work on (hence, my question to 
> you on ACP one para description).
> would like to understand better. Wouldn't it be better to try and 
> bridge this before sending stuff the direction of an AD (esp. when so 
> few people are involved)?
>
> I would think trying to understand what drives the different "camps" 
> has priority. Perhaps, some massaging cycles help here?
>
> Having 10 draft charter drafts is okay, esp. since most of them 
> happened in the August time window (when also Benoit Claise was on 
> vacation, so it seems...). By itself, the version number does not 
> indicate concensus or stability.
>
> one para, no other context required, language. Idea here is to make 
> the charter readable for non-expert readers
> - Circulate my comments on the various drafts mentioned in various 
> draft charters (I have lots of comments on, e.g., the definition draft 
> and some fundamental ones on each of the three solution drafts).
>
> Personally, I think the draft charter controversies have a bigger 
> chance to be addressed by a) having a clear description of what the 
> group wants to accomplish; (b) having some actual technical discussion 
> on the solution drafts, definition/gap analysis drafts, which - so far 
> - have been hard to trace.
>
> volunteer in this efforts, because think it is important and useful, 
> if done right).
>
> Best regards, Rene
>
>>> I have tried to explain during the call that underneath 
>>> "negotiation" sits theproblem by which a collection of 
>>> interacting/agents/ aim at reaching agreement in order to realize an 
>>> "intent" is a key aspect of the work. Renumbering/address management 
>>> being outside my scope/interest, how practically the charter does 
>>> allow me to work in this item when it states:
>>>
>>> /The working group will initially consider a simple example as a 
>>> test case for further work. /
>>>
>>> about base information exchange (more precisely a base description 
>>> of what [Jen1998] [Jen2001] describes as the negotiation object. 
>>> Thus missing i) the actual "*_negotiation protocols_* are the set of 
>>> rules that govern the interaction. This covers, the permissible 
>>> types of participants (e.g., the negotiators and relevant third 
>>> parties), the negotiation states (e.g., accepting bids, negotiation 
>>> closed), the events that cause state transitions (e.g., no more 
>>> bidders, bid accepted), and the valid actions of the participants in 
>>> particular states (e.g., which can be sent by whom, to whom and at 
>>> when)." and ii) the *_agents' reasoning models_* which provide "the 
>>> decision making apparatus by which participants attempt to achieve 
>>> their objectives. 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"
>>>
>>> of the negotiation process, the recipient needs to be able to 
>>> provide more useful feedback on the proposals it receives than just 
>>> whether or not it agrees to them. This feedback can take the form of 
>>> a critique (comments on which parts of the proposal the agent likes 
>>> or dislikes) or a counter-proposal (an alternative proposal 
>>> generated in response to a proposal). From such feedback, the 
>>> proposer should be able to generate a proposal which is more likely 
>>> to lead to an agreement (if it chooses to do so).
>>>
>>> <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
>>>
>>> Nick Jennings, Chris Preist, and Michael Schroeder. 1999. 
>>> Negotiation in multi-agent systems./Knowl. Eng. Rev./14, 3 
>>> (September 1999), pp.285-289.
>>>
>>> Thanks,
>>>
>>> -dimitri.
>>>
>>> this". (And we say this explicitly)  In my view all of the points 
>>> you raise MUST be raised, but I think we'll raise them when we 
>>> discuss the solutions.
>>>
>>> Michael
>>>
>>> to coordinate multiple autonomic functions (how to resolve 
>>> conflicts, avoid oscillations, etc.). other means should be 
>>> considered. this is what we need to define (i.e. the negotiation 
>>> functionality boundaries) before specifying the protocol(s).
>>>
>>> features are in: configuration, protection, healing and 
>>> optimization. these should be the minimal basis for the group scope.
>>>
> email:[email-masked]  | Skype: rstruik

---

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

Thanks René for your analysis.
Note that it's the role of a WG to discuss how to solve the problems 
(the technical aspects).
At charter time, we have to agree that there are problems to be solved.

Regards, Benoit
> I would strongly suggest putting this whole effort on hold and 
> improving the supposedly "baseline documents" that underpin the draft 
> charter, since those underpinnings are very hard to understand (also 
> for me after spending considerable time on this). I think the solution 
> drafts leave so many questions and lack so much analysis, that it is 
> highly premature to consider these as suitable basis for working group 
> deliberations.
>
> proponents of the draft charter also have a stake (as co-author) in 
> all the drafts I critically examined. So, one can choose to move ahead 
> on procedural grounds, no matter technical reservations regarding the 
> hope you would all agree that we ned to go back to the drawing board 
> and improve the currently shaky foundations first.
>
> esp. if one has an extremely hard time to trace any technical 
> discussion on mailing lists. My technical reviews were aimed at 
> filling this void.
>
>> 10) yet {these are only 1 1/2 day fresh though}; nor did I 
>> participate in the last conference call (in the middle of my sleep 
>> cycle).
>>
>> presumably having to read the drafts mentioned in the charter first 
>> (I was intimidated by this myself, but now did all this, and also 
>> read the 40 page survey on autonomic networking).} This makes me 
>> wonder why not more people are interested. [It has some advantages as 
>> well, since sometimes a small group works better.]
>> draft charters (I have lots of comments on, e.g., the definition 
>> draft and some fundamental ones on each of the three solution drafts).
>>
>> group wants to accomplish; (b) having some actual technical 
>> discussion on the solution drafts, definition/gap analysis drafts, 
>> which - so far - have been hard to trace.
>>
>> circulating "deeper" inputs here (I am not a salaried employee ... 
>> and volunteer in this efforts, because think it is important and 
>> useful, if done right).
>>
>> Best regards, Rene
>>
>>>> interacting/agents/ aim at reaching agreement in order to realize 
>>>> an "intent" is a key aspect of the work. Renumbering/address 
>>>> management being outside my scope/interest, how practically the 
>>>> charter does allow me to work in this item when it states:
>>>>
>>>> Thus missing i) the actual "*_negotiation protocols_* are the set 
>>>> of rules that govern the interaction. This covers, the permissible 
>>>> bidders, bid accepted), and the valid actions of the participants 
>>>> in particular states (e.g., which can be sent by whom, to whom and 
>>>> at when)." and ii) the *_agents' reasoning models_* which provide 
>>>> "the decision making apparatus by which participants attempt to 
>>>> achieve their objectives. 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"
>>>>
>>>> Negotiation in the present context following [Jen1998] can indeed 
>>>> be viewed as a "distributed search through a space of potential 
>>>> whether or not it agrees to them. This feedback can take the form 
>>>> of a critique (comments on which parts of the proposal the agent 
>>>> likes or dislikes) or a counter-proposal (an alternative proposal 
>>>> Multi-Agent Systems* from Martin Beer, Mark D'inverno, Michael 
>>>> Luck, Nick Jennings, Chris Preist, and Michael Schroeder. 1999. 
>>>> linkedin: laurentciavaglia 
>>>> <http://fr.linkedin.com/in/laurentciavaglia/>
>>>>

---

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

Hi Benoit:

Thanks for your note. I hope my analysis is useful in improving the 
quality of background material and "solution-oriented documents" alike.

Please note that my analysis does not only deal with "how problems are 
solved"; it also comments on the presumed "foundations" (the definition 
draft and gap analysis) for this effort and "which problems are to be 
solved". My overall conclusion, based on my own detailed review, 
unfortunately is that there is that the work items do not have a solid 
footing in the gap analysis. Thereby, it is not entirely clear that the 
three solution drafts (which are all individual documents that happen to 
be floating around on the nmrg server) are necessarily the right items 
to focus on.

Hence, my reservations with the charter.

This is the scenario I fear will transpire:
- one will approve draft, since "the show must go on"
- there will be three drafts for which a WG adoption email will be 
issued prior to the November meeting
- chairs/some people will argue it should be adopted simply because it 
is there (and since there are no competing drafts)

This will leave no room discussing the merits of the problems these 
drafts are addressing (which, btw, are kind of defined in a circular 
fashion, by simply being defined by the solution drafts that happen to 
be on the nmrg list.

Shouldn't one aim higher and avoid this whole scenario transpiring?

I don't want to be blamed to put a spoke in the wheel, but if I would be 
managing this as a project in a company and would be sitting on budget, 
I would send the teams back to redo their homework, failure of 
completion resulting in zero budget being awarded at this stage.

Best regards, Rene

[excerpt email Rene Struik as of Thu Sep 18, 2014]

On 9/24/2014 2:29 PM, Benoit Claise wrote:
>> From these detailed reviews, it should be clear that there are lots 
>> of questions on the design goals, gaps and design philosophy, and 
>> three solution drafts floating around for now. I also had trouble 
>> finding a succinct analysis of what is required and what is missing 
>> in prior RFC art.
>>
>> for me after spending considerable time on this). I think the 
>> solution drafts leave so many questions and lack so much analysis, 
>> that it is highly premature to consider these as suitable basis for 
>> working group deliberations.
>>
>> all the drafts I critically examined. So, one can choose to move 
>> ahead on procedural grounds, no matter technical reservations 
>> regarding the foundations of this effort. We are all technical 
>> people, though, and I hope you would all agree that we ned to go back 
>> to the drawing board and improve the currently shaky foundations first.
>>
>> Personally, I disagree with the assessment one has to include 
>> solution drafts in a charter (no matter whether an AD might have 
>> suggested so), esp. if one has an extremely hard time to trace any 
>> technical discussion on mailing lists. My technical reviews were 
>> aimed at filling this void.
>>
>> Let us not bury ourselves in procedural arm-wrestling; this topic 
>> area is important enough to do right and not start on the wrong footing.
>>
>> Best regards, Rene
>>
>>> I did not want to comment on the mailing list prior to me 
>>> circulating comments on the all the drafts mentioned in the charter, 
>>> but the AD artillery at this stage kind of forces me to weigh-in.
>>>
>>> seem to draw in only a handful of people. This does not bode well 
>>> for support for the effort. {It could be that people are intimidated 
>>> by presumably having to read the drafts mentioned in the charter 
>>> first (I was intimidated by this myself, but now did all this, and 
>>> also read the 40 page survey on autonomic networking).} This makes 
>>> me wonder why not more people are interested. [It has some 
>>> advantages as well, since sometimes a small group works better.]
>>> charter, specific draft solutions were seemingly taken as 
>>> deliverable direction. In my mind, it would be better to describe 
>>> the problem areas the soon to be WG is supposed to work on (hence, 
>>> my question to you on ACP one para description).
>>> bridge this before sending stuff the direction of an AD (esp. when 
>>> so few people are involved)?
>>>
>>> - Describe the three areas that are supposedly to be tackled first 
>>> in one para, no other context required, language. Idea here is to 
>>> make the charter readable for non-expert readers
>>> The two items above I had originally plan to complete last weekend; 
>>> I hope to be able to do this by Mon-Tue next week.
>>>
>>>>> If the charter has been sometimes misunderstood as "we will do 
>>>>> this and nothing else", whereas the intent is "our initial focus 
>>>>> is this"
>>>>>
>>>>> /o Definition of a discovery and negotiation protocol for 
>>>>> autonomic functions/
>>>>>
>>>>> parties), the negotiation states (e.g., accepting bids, 
>>>>> negotiation closed), the events that cause state transitions 
>>>>> (e.g., no more bidders, bid accepted), and the valid actions of 
>>>>> the participants in particular states (e.g., which can be sent by 
>>>>> whom, to whom and at when)." and ii) the *_agents' reasoning 
>>>>> models_* which provide "the decision making apparatus by which 
>>>>> participants attempt to achieve their objectives. 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"
>>>>>
>>>>> agreements about some joint problem [...] To improve the 
>>>>> efficiency of the negotiation process, the recipient needs to be 
>>>>> able to provide more useful feedback on the proposals it receives 
>>>>> than just whether or not it agrees to them. This feedback can take 
>>>>> the form of a critique (comments on which parts of the proposal 
>>>>> the agent likes or dislikes) or a counter-proposal (an alternative 
>>>>> proposal generated in response to a proposal). From such feedback, 
>>>>> the proposer should be able to generate a proposal which is more 
>>>>> likely to lead to an agreement (if it chooses to do so).
>>>>>
>>>>> *From:*Anima [mailto:[email-masked]] *On Behalf Of 
>>>>> *Michael Behringer (mbehring)
>>>>> everybody to provide such corrections if needed. BTW, I don't 
>>>>> think we need to re-do those notes, since the notes AND your (and 
>>>>> I think the charter has been sometimes misunderstood as "we will 
>>>>> do this and nothing else", whereas the intent is "our initial 
>>>>> focus is this". (And we say this explicitly)  In my view all of 
>>>>> the points you raise MUST be raised, but I think we'll raise them 
>>>>> when we discuss the solutions.
>>>>>
>>>>> Michael
>>>>>
>>>>> *From:*Laurent Ciavaglia 
>>>>> [mailto:[email-masked]]
>>>>>     --> Laurent: in some cases, unicast communication is not 
>>>>> suited to coordinate multiple autonomic functions (how to resolve

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 25 Sep 2014 11:57:13 +1200

Rene,

> issued prior to the November meeting

I truly doubt that. I don't think there will be time, even if the
WG is chartered as quickly as humanly possible. Also, the idea of
the various authors is that those drafts all need to be transformed
into draft-author-anima-*-00 drafts in the light of the charter,
and then take their chances in WG discussion. And of course other people
are at liberty to post their own draft-author-anima-*-00 drafts too.

If you look at the draft agenda currently posted in the BOF wiki,
you will see a lot time for discussion.
http://trac.tools.ietf.org/bof/trac/wiki/WikiStart#ANIMAproposal

    Brian

>>>>>>     Laurent: The current negotiation proposal is just one
>>>>>> proposal. But there are many potential solutions.
>>>>>>
>>>>>>     Sheng: Yes, but this should be the job of the working group,
>>>>>> to define precise requirements, and work out a proposed protocol.
>>>>>>
>>>>>>     Dimitri: Differnt means to translate negotiation requirements
>>>>>> to protocol. If we don't have a broad overview we may go down the
>>>>>> wrong track. Might end up in an open protocol.
>>>>>>
>>>>>>     Brian: Completely agree.
>>>>>>
>>>>>> functionalities, and it's the job of the working group to
>>>>>> translate this into protocols.
>>>>>>
>>>>>> Determine the use cases you need to determine this. Need a broad
>>>>>> set of use cases to define boundaries (not requirements). We
>>>>>> should select use cases by area, for example bootstrap. We need
>>>>>> three areas. 1) Bootstrapping (self-configuration), 2)
>>>>>> self-protection and 3) open, on self-healing for example.
>>>>>>

---

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

Hi, Rene,
It has been made clear that the potential ANIMA WG would NOT adopt these start point drafts by default. These drafts need to be discussed and improved during the WG stage. They may be replaced by better approaches. They may be merged with other proposals. The discussion would take as long as it needs. Only after the WG reach the consensus, at least rough consensus, a draft would be adoption. Your worries are reasonable, but it is IETF’s familiar regulation to avoid them.
Best regards,
Sheng
From: Anima [mailto:[email-masked]] On Behalf Of Rene Struik
Sent: Thursday, September 25, 2014 7:01 AM
To: Benoit Claise; Papadimitriou, Dimitri (Dimitri); Michael Behringer (mbehring); CIAVAGLIA, LAURENT (LAURENT)
Cc: [email-masked]
Subject: Re: [Anima] Concerns on Anima pre-WG status and potential directions to address these (Re: Notes from the ANIMA Call Today)

Hi Benoit:

Thanks for your note. I hope my analysis is useful in improving the quality of background material and "solution-oriented documents" alike.

Please note that my analysis does not only deal with "how problems are solved"; it also comments on the presumed "foundations" (the definition draft and gap analysis) for this effort and "which problems are to be solved". My overall conclusion, based on my own detailed review, unfortunately is that there is that the work items do not have a solid footing in the gap analysis. Thereby, it is not entirely clear that the three solution drafts (which are all individual documents that happen to be floating around on the nmrg server) are necessarily the right items to focus on.

This is the scenario I fear will transpire:
- one will approve draft, since "the show must go on"
- there will be three drafts for which a WG adoption email will be issued prior to the November meeting
- chairs/some people will argue it should be adopted simply because it is there (and since there are no competing drafts)

This will leave no room discussing the merits of the problems these drafts are addressing (which, btw, are kind of defined in a circular fashion, by simply being defined by the solution drafts that happen to be on the nmrg list.

I don't want to be blamed to put a spoke in the wheel, but if I would be managing this as a project in a company and would be sitting on budget, I would send the teams back to redo their homework, failure of completion resulting in zero budget being awarded at this stage.

Best regards, Rene

[excerpt email Rene Struik as of Thu Sep 18, 2014]
I would strongly suggest putting this whole effort on hold and improving the supposedly "baseline documents" that underpin the draft charter, since those underpinnings are very hard to understand (also for me after spending considerable time on this). I think the solution drafts leave so many questions and lack so much analysis, that it is highly premature to consider these as suitable basis for working group deliberations.

On 9/24/2014 2:29 PM, Benoit Claise wrote:
Thanks René for your analysis.
Note that it's the role of a WG to discuss how to solve the problems (the technical aspects).
At charter time, we have to agree that there are problems to be solved.

Regards, Benoit
Dear colleagues:

As you saw, I did review six documents all mentioned in the draft charter and posted thorough reviews on five of these:
review of draft-irtf-nmrg-autonomic-network-definitions-03, see http://www.ietf.org/mail-archive/web/anima/current/msg00297.html
review of draft-irtf-nmrg-an-gap-analysis-01, see http://www.ietf.org/mail-archive/web/anima/current/msg00298.html
review of draft-jiang-config-negotiation-ps-03, see http://www.ietf.org/mail-archive/web/anima/current/msg00306.html
review of draft-jiang-config-negotiation-protocol-02, see http://www.ietf.org/mail-archive/web/anima/current/msg00309.html
review of draft-behringer-autonomic-control-plane-00, see http://www.ietf.org/mail-archive/web/anima/current/msg00317.html
review of draft-pritikin-bootstrapping-keyinfrastructures-00 (still pending)

From these detailed reviews, it should be clear that there are lots of questions on the design goals, gaps and design philosophy, and three solution drafts floating around for now. I also had trouble finding a succinct analysis of what is required and what is missing in prior RFC art.

I would strongly suggest putting this whole effort on hold and improving the supposedly "baseline documents" that underpin the draft charter, since those underpinnings are very hard to understand (also for me after spending considerable time on this). I think the solution drafts leave so many questions and lack so much analysis, that it is highly premature to consider these as suitable basis for working group deliberations.

I would like to see this group succeed. I do know that some of the proponents of the draft charter also have a stake (as co-author) in all the drafts I critically examined. So, one can choose to move ahead on procedural grounds, no matter technical reservations regarding the foundations of this effort. We are all technical people, though, and I hope you would all agree that we ned to go back to the drawing board and improve the currently shaky foundations first.

Personally, I disagree with the assessment one has to include solution drafts in a charter (no matter whether an AD might have suggested so), esp. if one has an extremely hard time to trace any technical discussion on mailing lists. My technical reviews were aimed at filling this void.

Let us not bury ourselves in procedural arm-wrestling; this topic area is important enough to do right and not start on the wrong footing.

Best regards, Rene

I did not want to comment on the mailing list prior to me circulating comments on the all the drafts mentioned in the charter, but the AD artillery at this stage kind of forces me to weigh-in.

First of all, I have not read draft charter 09 (or the mock version 10) yet {these are only 1 1/2 day fresh though}; nor did I participate in the last conference call (in the middle of my sleep cycle).

Here is my quick feedback on charter status/controversy:
- main concern with draft charter discussions is that, while the BOF had ~200 people in attendance, discussions on the call/mailing list seem to draw in only a handful of people. This does not bode well for support for the effort. {It could be that people are intimidated by presumably having to read the drafts mentioned in the charter first (I was intimidated by this myself, but now did all this, and also read the 40 page survey on autonomic networking).} This makes me wonder why not more people are interested. [It has some advantages as well, since sometimes a small group works better.]
- second concern is that, at least with prior versions of the draft charter, specific draft solutions were seemingly taken as deliverable direction. In my mind, it would be better to describe the problem areas the soon to be WG is supposed to work on (hence, my question to you on ACP one para description).
- third concern is that there seems to be a divide in "camps" that I would like to understand better. Wouldn't it be better to try and bridge this before sending stuff the direction of an AD (esp. when so few people are involved)?

I would think trying to understand what drives the different "camps" has priority. Perhaps, some massaging cycles help here?

Having 10 draft charter drafts is okay, esp. since most of them happened in the August time window (when also Benoit Claise was on vacation, so it seems...). By itself, the version number does not indicate concensus or stability.

Here is my own action plan/to-dos in this area:
- Describe the three areas that are supposedly to be tackled first in one para, no other context required, language. Idea here is to make the charter readable for non-expert readers
- Circulate my comments on the various drafts mentioned in various draft charters (I have lots of comments on, e.g., the definition draft and some fundamental ones on each of the three solution drafts).

The two items above I had originally plan to complete last weekend; I hope to be able to do this by Mon-Tue next week.

Personally, I think the draft charter controversies have a bigger chance to be addressed by a) having a clear description of what the group wants to accomplish; (b) having some actual technical discussion on the solution drafts, definition/gap analysis drafts, which - so far - have been hard to trace.

Hence, my action plan above. Once again, apologies for delays in circulating "deeper" inputs here (I am not a salaried employee ... and volunteer in this efforts, because think it is important and useful, if done right).

Best regards, Rene

On 9/12/2014 11:57 AM, Benoit Claise wrote:
Dimitri,
Michael,
If the charter has been sometimes misunderstood as “we will do this and nothing else”, whereas the intent is “our initial focus is this”
I believe it's covered by the charter.

more modest

can you explain me how to deal with the following situation. I am interested in the following part
[specific goals]
o Definition of a discovery and negotiation protocol for autonomic functions
I have tried to explain during the call that underneath “negotiation” sits the problem by which a collection of interacting agents aim at reaching agreement in order to realize an “intent” is a key aspect of the work. Renumbering/address management being outside my scope/interest, how practically the charter does allow me to work in this item when it states:
The working group will initially consider a simple example as a test case for further work.
That text improved in the just-posted draft version. See https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-anima%2Fwithmilestones-00-04.txt&difftype=--html&submit=Go!&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-anima%2Fwithmilestones-00-05.txt<https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-anima%2Fwithmilestones-00-04.txt&difftype=--html&submit=Go%21&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-anima%2Fwithmilestones-00-05.txt>

Regards, Benoit

There is however a broader technical point of concern, the charter aims defining such component but for instance behind the term negotiation we understand different things Section 2.3 http://tools.ietf.org/html/draft-jiang-config-negotiation-ps-03 is about base information exchange (more precisely a base description of what [Jen1998] [Jen2001] describes as the negotiation object. Thus missing i) the actual “negotiation protocols are the set of rules that govern the interaction. This covers, the permissible types of participants (e.g., the negotiators and relevant third parties), the negotiation states (e.g., accepting bids, negotiation closed), the events that cause state transitions (e.g., no more bidders, bid accepted), and the valid actions of the participants in particular states (e.g., which can be sent by whom, to whom and at when).” and ii) the agents’ reasoning models which provide “the decision making apparatus by which participants attempt to achieve their objectives. 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”
Negotiation in the present context following [Jen1998] can indeed be viewed as a “distributed search through a space of potential agreements about some joint problem […] To improve the efficiency of the negotiation process, the recipient needs to be able to provide more useful feedback on the proposals it receives than just whether or not it agrees to them. This feedback can take the form of a critique (comments on which parts of the proposal the agent likes or dislikes) or a counter-proposal (an alternative proposal generated in response to a proposal). From such feedback, the proposer should be able to generate a proposal which is more likely to lead to an agreement (if it chooses to do so).

Thanks,
-dimitri.

Laurent,
Thanks for the corrections. It’s difficult to participate in the discussion AND try to catch everything correctly, so I count on everybody to provide such corrections if needed. BTW, I don’t think we need to re-do those notes, since the notes AND your (and Dimitri’s) comments are in the same mail thread in the archive. Do you agree?
Personally, I think a lot of these discussions will be easier and clearer when we’re actually arguing about a protocol or method.
I think the charter has been sometimes misunderstood as “we will do this and nothing else”, whereas the intent is “our initial focus is this”. (And we say this explicitly)  In my view all of the points you raise MUST be raised, but I think we’ll raise them when we discuss the solutions.
Michael

Dear Michael,

Michael

--

11 Sep 2014, 6am GMT

Attendees

Notes

Yes. (no objection)

Brian: Completely agree.

Anima mailing list

Laurent Ciavaglia

phone: +33 160 402 636

Anima mailing list

Anima mailing list

--

email: [email-masked]<mailto:[email-masked]> | Skype: rstruik

--

email: [email-masked]<mailto:[email-masked]> | Skype: rstruik

Anima mailing list

--

email: [email-masked]<mailto:[email-masked]> | Skype: rstruik

---

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

Hi,
> quality of background material and "solution-oriented documents" alike.
It certainly is, and was stressed during our call today. Thanks.
> solved"; it also comments on the presumed "foundations" (the 
> definition draft and gap analysis) for this effort and "which problems 
> are to be solved". My overall conclusion, based on my own detailed 
> review, unfortunately is that there is that the work items do not have 
> a solid footing in the gap analysis. Thereby, it is not entirely clear 
> that the three solution drafts (which are all individual documents 
> that happen to be floating around on the nmrg server) are necessarily 
> the right items to focus on.
>
This should NOT happen.
See the minutes from our call today, posted by Michael.

Regards, Benoit
> I don't want to be blamed to put a spoke in the wheel, but if I would 
> be managing this as a project in a company and would be sitting on 
> budget, I would send the teams back to redo their homework, failure of 
>>> improving the supposedly "baseline documents" that underpin the 
>>> draft charter, since those underpinnings are very hard to understand 
>>> (also for me after spending considerable time on this). I think the 
>>> people, though, and I hope you would all agree that we ned to go 
>>> back to the drawing board and improve the currently shaky 
>>> foundations first.
>>>
>>>> circulating comments on the all the drafts mentioned in the 
>>>> charter, but the AD artillery at this stage kind of forces me to 
>>>> weigh-in.
>>>>
>>>> - main concern with draft charter discussions is that, while the 
>>>> BOF had ~200 people in attendance, discussions on the call/mailing 
>>>> list seem to draw in only a handful of people. This does not bode 
>>>> well for support for the effort. {It could be that people are 
>>>> intimidated by presumably having to read the drafts mentioned in 
>>>> the charter first (I was intimidated by this myself, but now did 
>>>> all this, and also read the 40 page survey on autonomic 
>>>> networking).} This makes me wonder why not more people are 
>>>> interested. [It has some advantages as well, since sometimes a 
>>>> small group works better.]
>>>> - third concern is that there seems to be a divide in "camps" that 
>>>> I would like to understand better. Wouldn't it be better to try and 
>>>> I would think trying to understand what drives the different 
>>>> "camps" has priority. Perhaps, some massaging cycles help here?
>>>>
>>>>>> There is however a broader technical point of concern, the 
>>>>>> charter aims defining such component but for instance behind the 
>>>>>> term negotiation we understand different things Section 2.3 
>>>>>> http://tools.ietf.org/html/draft-jiang-config-negotiation-ps-03 
>>>>>> is about base information exchange (more precisely a base 
>>>>>> description of what [Jen1998] [Jen2001] describes as the 
>>>>>> negotiation object. Thus missing i) the actual "*_negotiation 
>>>>>> protocols_* are the set of rules that govern the interaction. 
>>>>>> This covers, the permissible types of participants (e.g., the 
>>>>>> negotiators and relevant third parties), the negotiation states 
>>>>>> (e.g., accepting bids, negotiation closed), the events that cause 
>>>>>> state transitions (e.g., no more bidders, bid accepted), and the 
>>>>>> valid actions of the participants in particular states (e.g., 
>>>>>> which can be sent by whom, to whom and at when)." and ii) the 
>>>>>> *_agents' reasoning models_* which provide "the decision making 
>>>>>> apparatus by which participants attempt to achieve their 
>>>>>> protocol used, the nature of the negotiation object, and the 
>>>>>> than just whether or not it agrees to them. This feedback can 
>>>>>> take the form of a critique (comments on which parts of the 
>>>>>> proposal the agent likes or dislikes) or a counter-proposal (an 
>>>>>> alternative proposal generated in response to a proposal). From 
>>>>>> such feedback, the proposer should be able to generate a proposal 
>>>>>> which is more likely to lead to an agreement (if it chooses to do 
>>>>>> so).
>>>>>>
>>>>>> argumentation-based negotiation, /Proceedings of the 
>>>>>> International Workshop on Multi-Agent Systems/, pages 1.7, 
>>>>>> Boston, USA, 1998.
>>>>>>
>>>>>> [Jen2001] N.R.Jennings 
>>>>>> al., Automated Negotiation: Prospects, Methods and Challenges; 
>>>>>> Group Decision and Negotiation, March 2001, Volume 10, Issue 2, 
>>>>>> pp 199-215
>>>>>>
>>>>>> Dimitri's) comments are in the same mail thread in the archive. 
>>>>>> Do you agree?
>>>>>>