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

Hi,
> Hi Benoit:
>
> Thanks for your note. I hope my analysis is useful in improving the 
> quality of background material and "solution-oriented documents" alike.
It certainly is, and was stressed during our call today. Thanks.
>
> 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 should NOT happen.
See the minutes from our call today, posted by Michael.

Regards, Benoit
>
> 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]
> 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
>>>
>>> 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
>>
>
>
> -- 
> email:[e-mail]  | Skype: rstruik
> cell: [phone] | US: [phone]
>
>
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima