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:
> 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:
>> 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:anima-bounces@ietf.org] *On Behalf Of *Michael 
>>> Behringer (mbehring)
>>> *Sent:* Friday, September 12, 2014 3:06 PM
>>> *To:* CIAVAGLIA, LAURENT (LAURENT); anima@ietf.org
>>> *Subject:* Re: [Anima] Notes from the ANIMA Call Today
>>>
>>> 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:Laurent.Ciavaglia@alcatel-lucent.com]
>>> *Sent:* 12 September 2014 14:53
>>> *To:* Michael Behringer (mbehring); anima@ietf.org 
>>> <mailto:anima@ietf.org>
>>> *Subject:* Re: [Anima] Notes from the ANIMA Call Today
>>>
>>> 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, 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.
>>>
>>> Thanks, best regards, Laurent.
>>>
>>> On 11/09/2014 15:31, Michael Behringer (mbehring) wrote:
>>>
>>>     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.
>>>
>>>       
>>>
>>>       
>>>
>>>       
>>>
>>>     _______________________________________________
>>>
>>>     Anima mailing list
>>>
>>>     Anima@ietf.org  <mailto:Anima@ietf.org>
>>>
>>>     https://www.ietf.org/mailman/listinfo/anima
>>>
>>>       
>>>
>>> -- 
>>>
>>> Bien cordialement, Best regards,
>>>
>>> *Laurent Ciavaglia*
>>>
>>> Advanced Internet Research
>>>
>>> Bell Labs | Alcatel Lucent
>>>
>>> phone: +33 160 402 636
>>>
>>> email: laurent.ciavaglia@alcatel-lucent.com 
>>> <mailto:laurent.ciavaglia@alcatel-lucent.com>
>>>
>>> linkedin: laurentciavaglia <http://fr.linkedin.com/in/laurentciavaglia/>
>>>
>>> address: Route de Villejust | 91620 Nozay | France
>>>
>>>
>>>
>>> _______________________________________________
>>> Anima mailing list
>>> Anima@ietf.org
>>> https://www.ietf.org/mailman/listinfo/anima
>>
>>
>>
>> _______________________________________________
>> Anima mailing list
>> Anima@ietf.org
>> https://www.ietf.org/mailman/listinfo/anima
>
>
> -- 
> email:rstruik.ext@gmail.com  | Skype: rstruik
> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363