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

[Rene Struik <[e-mail]>]

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