Re: [Anima] Concerns on Anima pre-WG status and potential directions to address these (Re: Notes from the ANIMA Call Today)

[Benoit Claise <[e-mail]>]

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
>
> 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:[e-mail]] *On Behalf Of *Michael 
>>>> Behringer (mbehring)
>>>> *Sent:* Friday, September 12, 2014 3:06 PM
>>>> *To:* CIAVAGLIA, LAURENT (LAURENT); [e-mail]
>>>> *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:[e-mail]]
>>>> *Sent:* 12 September 2014 14:53
>>>> *To:* Michael Behringer (mbehring); [e-mail] 
>>>> <mailto:[e-mail]>
>>>> *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
>>>>
>>>>     [e-mail]  <mailto:[e-mail]>
>>>>
>>>>     https://www.ietf.org/mailman/listinfo/anima
>>>>
>>>>       
>>>>
>>>> -- 
>>>>
>>>> Bien cordialement, Best regards,
>>>>
>>>> *Laurent Ciavaglia*
>>>>
>>>> Advanced Internet Research
>>>>
>>>> Bell Labs | Alcatel Lucent
>>>>
>>>> phone: [phone]
>>>>
>>>> email: [e-mail] 
>>>> <mailto:[e-mail]>
>>>>
>>>> linkedin: laurentciavaglia 
>>>> <http://fr.linkedin.com/in/laurentciavaglia/>
>>>>
>>>> address: Route de Villejust | 91620 Nozay | France
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Anima mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/anima
>>>
>>>
>>>
>>> _______________________________________________
>>> Anima mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/anima
>>
>>
>> -- 
>> email:[e-mail]  | Skype: rstruik
>> cell: [phone] | US: [phone]
>
>
> -- 
> email:[e-mail]  | Skype: rstruik
> cell: [phone] | US: [phone]
>
>
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima