Subject: [Anima] Notes from the ANIMA Call today

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 25 Sep 2014 07:03:57 +0000

Recording: https://cisco.webex.com/ciscosales/lsr.php?RCID=39ac2040acd6406084512a11c80a0edb 

ANIMA Call
25 Sep 2014

Benoit: Process: Joel and Benoit received our BoF request, it's on the wiki (http://trac.tools.ietf.org/bof/trac/wiki). 
Are there still blocking factors for a charter? 
Assume perfect process: 1 week of IESG review. The IESG call where the IESG
says the charter is ready for external review (2 weeks) Then externals can 
comment for 2 weeks. So minimun is 5 weeks. 
We are still on time. 
Draft -08 of charter has been posted. Only IPv6 management is needs to be added. 
Received an extra few paragraphs. see diff between -06 and -08 of the charter. 

Process: AD not looking for consensus on the textual charter. But there should be consensus that people will work towards the charter goals. 
ADs want to understand open issues. Rene and Dimitri sent a few. Benoit was hoping that Dimitri would be on the call... 
What are the remaining issues? 
- Do we need to list starting points? 

Brian: Discussion should be about the WG documents, not about the charter. 
Sheng, Michael: agree. 
Laurent: Either cite all references or none. Why limit ourselves here?
Benoit: I like the starting points in the charter. The goals listed are very generic, could be understood in too many ways. The starting points should give an idea on what we are thinking about. This doesn't mean that the draft listed is the right one, and maybe "starting point" is not the right term. AD would be happy to have several competing "starting points". 
Dimitri worried that people will adopt drafts just because they are listed. 
Brian: Have never seen a WG that just accepted an existing draft. Do not see an issue here. 
Michael: Should we explain this in the charter? 
Benoit: This is normal WG procedure, not needed to mention explicitly. We should not put in the charter normal IETF process. 
Michael: Worried about negative starting points. 
Benoit: Autonomics has been around for 10 years. the NMRG work progressed very slowly. Let's try out some things and see what works. Risk to boil the ocean. In favour of getting something small done. I would be happy if every year we'd work on a few new use cases. But concerned that we never got anywhere with this. 
Sheng: Added the sentence in question because we wanted to make sure everybody is happy with the charter. Rene and Dimitri seem upset that the charter doesn't contain all they want, but new work can be added. The starting point docs are not adopted yet. 
Benoit: use case issue: hope that we'll get extra use cases that will reuse the components mentioned. Haven't found a way to express that all individual drafts are welcome, but we don't want to review all use cases. That's why we restricted use cases. But everyone should check that HIS use case can reuse components. But cannot write in the charter that if one use case breaks some component, we have to start from scratch. Other things should be worked on. Understand frustration about many use cases not being picked up. 
Brain: If we go ahead, you should make this point on the list / in the meeting. Rene's comments are very contrstructive. 
Benoit: We're not looking for consensus on the charter text, but on consensus that people will work on it. 
Michael: At UCAN BoF, 20 people raised their hands that they will work in this space. 
Benoit: But this is on this charter text, not on UCAN. 
Benoit: Ideally want a last call on the NMRG documents before starting here. 
Michael: We posted the docs about 2-3 weeks ago, no response from RG chairs. In the meantime we got more comments from Rene. 
Benoit: We should post the latest version, our responsibility, not RG chairs. 
Sheng: use case draft already has another version, not posted yet. Give us one week. 
Michael: definitions draft should also have another version in 1 week. 
Benoit: Those 2 docs are building blocks, they shouldn't change massively from now. 
Michael: I believe the docs are fundamentally stable, there will always be small changes. 
Brian, Sheng: Agree. 
Benoit: Sent a few emails to NMRG chairs, to progress the docs. No replies. 
Benoit: Have covered Dimitri's points. Rene's point still has the point the problem statements is not well described. 
Michael: AN in general is a huge architecture, and we want to work bottom up. There is inevitably a huge gap, and people will always feel uncomfortable about this. 
Benoit: Are there still open blocking factors? 
Laurent: No. It's time to go ahead. 
Bing Liu: Should go ahead. 
(no other opinions expressed)
Benoit: We've been listening to everybody; the charter is not perfect; but it is not sure that we can do this in the world of AN. This is why the ADs have pointed at starting points. But would be very happy if other people have other proposals to sovle the same problems, and have a healthy discussion. Concern about accepting the existing docs (email from Rene today: Afraid of being too fast; if WG in Hawaii, existing docs will be blindly accepted) - we should not blindly accept those starting points.  But we should be open and look at every proposal. We might receive blocking comments from IESG. 
Finish the next versions of the NMRG docs asap. Might still change. Will keep pushing NMRG chairs to progress those drafts. 
Laurent: The charter states the the first docs will be accepted in Hawaii. 
Benoit: Very good point!!!! It should NOT happen in November. We need to correct that in the charter. 
Michael: So lets change the charter, change milestones. 
Benoit changing the charter on the fly. See new version on the wiki. 
Some discussion on the precise timing of milestones, not captured in detail; bottom line: We take things a bit more slowly to allow all views to be factored in. 
Benoit: Michael makes a proposal for new milestones TODAY and send it to Benoit. 
Laurent: BoF request has been sent; can we see the proposal? 
Benoit: See ANIMA proposal in http://trac.tools.ietf.org/bof/trac/wiki. 
Benoit: Next wed, IESG will discuss which BoFs should be approved. Benoit will make the point. Then we'll know whether we'll have a BoF or WG. If there is a BoF, then we need to understand the expected outcome. Would like to hear from Dimitri his opinion. A BoF isn't there to solve a problem, but to agree that there is a problem to be solved. Maybe not perfectly described. The only positive point in a BoF is if we can describe the problem statement better. 
Laurent: Would prefer a WG meeting. Would be useful to have time for face to face discussions. It's a complex topix. BoF is not the right type of meeting for this discussion. 
Michael: Let's just meet informally several times in Hawaii. 
Benoit: We should also discuss in NMRG. Any way to work is good. If WG, it should be inclusive to everyone.

---

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

Thanks Michael for your notes.
3 small corrections below.

Regards, Benoit
> Benoit: This is normal WG procedure, not needed to mention explicitly. We should not put in the charter normal IETF process.
ADD: Additionally, I don't think that "Additional work items may only be 
added with approval from the responsible Area Director or by 
re-chartering" is needed. This is normal IETF process.
> Benoit: Autonomics has been around for 10 years. the NMRG work progressed very slowly. Let's try out some things and see what works. Risk to boil the ocean. In favour of getting something small don…
NEW:

But concerned that we never got anywhere if we take too many use cases

> Sheng: Added the sentence in question because we wanted to make sure everybody is happy with the charter.
NEW: Sheng: Added the "Additional work items may only be added with 
approval from the responsible Area Director or by re-chartering" 
sentence in question because we wanted to make sure everybody is happy 
with the charter.
> Rene and Dimitri seem upset that the charter doesn't contain all they want, but new work can be added. The starting point docs are not adopted yet.
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
> .
>

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 25 Sep 2014 08:05:03 +0000

Hi, Michael and Benoit,

Thanks for the notes and correction. Two more small corrections below.

Best regards,

Sheng

>-----Original Message-----
>From: Anima [mailto:[email-masked]] On Behalf Of Benoit Claise
>Sent: Thursday, September 25, 2014 3:55 PM
>To: Michael Behringer (mbehring); [email-masked]
>Subject: Re: [Anima] Notes from the ANIMA Call today
>
>> Recording:
>https://cisco.webex.com/ciscosales/lsr.php?RCID=39ac2040acd6406084512a
>11c80a0edb
>>
>>
>> ANIMA Call
>> 25 Sep 2014
>>
>> Benoit: Process: Joel and Benoit received our BoF request, it's on the wiki
>(http://trac.tools.ietf.org/bof/trac/wiki).
>> Process: AD not looking for consensus on the textual charter. But there
>should be consensus that people will work towards the charter goals.
>> ADs want to understand open issues. Rene and Dimitri sent a few. Benoit
>was hoping that Dimitri would be on the call...

New: Brian: technical discussion should be in the WG stage, not in the charter.

>> Benoit: I like the starting points in the charter. The goals listed are very
>generic, could be understood in too many ways. The starting points should
>give an idea on what we are thinking about. This doesn't mean that the draft
>listed is the right one, and maybe "starting point" is not the right term. AD
>would be happy to have several competing "starting points".
>> Benoit: This is normal WG procedure, not needed to mention explicitly. We
>should not put in the charter normal IETF process.
>> Benoit: Autonomics has been around for 10 years. the NMRG work
>progressed very slowly. Let's try out some things and see what works. Risk to
>boil the ocean. In favour of getting something small done. I would be happy if
>every year we'd work on a few new use cases. But concerned that we never
>got anywhere with this.
>NEW:
>
>> Rene and Dimitri seem upset that the charter doesn't contain all they want,
>but new work can be added. The starting point docs are not adopted yet.
>> Benoit: use case issue: hope that we'll get extra use cases that will reuse the
>components mentioned. Haven't found a way to express that all individual
>drafts are welcome, but we don't want to review all use cases. That's why we
>restricted use cases. But everyone should check that HIS use case can reuse
>components. But cannot write in the charter that if one use case breaks some
>component, we have to start from scratch. Other things should be worked on.
>Understand frustration about many use cases not being picked up.
>> Michael: We posted the docs about 2-3 weeks ago, no response from RG
>chairs. In the meantime we got more comments from Rene.

New: Sheng: gap analysis draft already has another version, not posted yet. Give us
one week.

>> Benoit: Have covered Dimitri's points. Rene's point still has the point the
>problem statements is not well described.
>> Michael: AN in general is a huge architecture, and we want to work bottom
>up. There is inevitably a huge gap, and people will always feel uncomfortable
>about this.
>> Benoit: We've been listening to everybody; the charter is not perfect; but it
>is not sure that we can do this in the world of AN. This is why the ADs have
>pointed at starting points. But would be very happy if other people have other
>proposals to sovle the same problems, and have a healthy discussion.
>Concern about accepting the existing docs (email from Rene today: Afraid of
>being too fast; if WG in Hawaii, existing docs will be blindly accepted) - we
>should not blindly accept those starting points.  But we should be open and
>look at every proposal. We might receive blocking comments from IESG.
>> Finish the next versions of the NMRG docs asap. Might still change. Will
>keep pushing NMRG chairs to progress those drafts.
>> Some discussion on the precise timing of milestones, not captured in detail;
>bottom line: We take things a bit more slowly to allow all views to be factored
>in.
>> Benoit: Next wed, IESG will discuss which BoFs should be approved. Benoit
>will make the point. Then we'll know whether we'll have a BoF or WG. If there
>is a BoF, then we need to understand the expected outcome. Would like to
>hear from Dimitri his opinion. A BoF isn't there to solve a problem, but to
>agree that there is a problem to be solved. Maybe not perfectly described.
>The only positive point in a BoF is if we can describe the problem statement
>better.
>> Laurent: Would prefer a WG meeting. Would be useful to have time for face
>to face discussions. It's a complex topix. BoF is not the right type of meeting
>for this discussion.

---

From: Laurent Ciavaglia <[email-masked]>
Date: Thu, 25 Sep 2014 10:24:49 +0200

Thanks for taking care and posting the minutes.

Please find two small changes, in line.

Best regards, Laurent.

> Dimitri worried that people will adopt drafts just because they are listed.

I think Benoit was talking about Rene, not Dimitri (cf latest emails 
sent on the list by Rene).

> Laurent: Would prefer a WG meeting. Would be useful to have time for face to face discussions. It's a complex topix. BoF is not the right type of meeting for this discussion.

WG and BoF might or not be the right types of meeting for this 
discussion, yet the need is here. How can we organize ourselves to have 
such discussions?

-- 

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

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Thu, 25 Sep 2014 11:55:45 +0000

Hi Benoit,

Recently I posted <http://www.ietf.org/mail-archive/web/anima/current/msg00276.html> a comment mentioning in brief:

[NMRG_Def] mentions that the ACP provides for the communication means (channels, interface, etc.). This document states also that autonomic functions such as discovery mechanisms use the common infrastructure components but the latter (following the charter section on [main goal] also includes a discovery process/mechanism.

Altogether, it reads as if we have two discovery mechanisms (the same for the negotiation process). I have suggested to simplify this by mentioning a "use relationship" between the service agents (and when needed with other components) and the discovery process and leave the discussion as to which level (cf. fig 1 of <http://tools.ietf.org/html/draft-irtf-nmrg-autonomic-network-definitions-03> it belongs/decomposes when this group will put the pieces together at later stage.

I also want to point out it is impossible during conf.calls to have in depth discussions which are at the root of the higher level ones (as we say in French: il n'y a pas de fumee sans feu).

Many thanks,
-dimitri.

> Sent: Thursday, September 25, 2014 9:55 AM
> > Benoit: Process: Joel and Benoit received our BoF request, it's on the
> wiki (http://trac.tools.ietf.org/bof/trac/wiki).
> > Assume perfect process: 1 week of IESG review. The IESG call where the
> > IESG says the charter is ready for external review (2 weeks) Then
> > externals can comment for 2 weeks. So minimun is 5 weeks.
> > We are still on time.
> > Benoit: I like the starting points in the charter. The goals listed are
> very generic, could be understood in too many ways. The starting points
> should give an idea on what we are thinking about. This doesn't mean that
> the draft listed is the right one, and maybe "starting point" is not the
> right term. AD would be happy to have several competing "starting points".
> > Benoit: This is normal WG procedure, not needed to mention explicitly.
> We should not put in the charter normal IETF process.
> added with approval from the responsible Area Director or by re-
> chartering" is needed. This is normal IETF process.
> progressed very slowly. Let's try out some things and see what works. Risk
> to boil the ocean. In favour of getting something small done. I would be
> happy if every year we'd work on a few new use cases. But concerned that
> we never got anywhere with this.
> NEW:
> 
> > Rene and Dimitri seem upset that the charter doesn't contain all they
> want, but new work can be added. The starting point docs are not adopted
> yet.
> > Benoit: use case issue: hope that we'll get extra use cases that will
> reuse the components mentioned. Haven't found a way to express that all
> individual drafts are welcome, but we don't want to review all use cases.
> That's why we restricted use cases. But everyone should check that HIS use
> case can reuse components. But cannot write in the charter that if one use
> case breaks some component, we have to start from scratch. Other things
> should be worked on. Understand frustration about many use cases not being
> picked up.
> > Brain: If we go ahead, you should make this point on the list / in the
> meeting. Rene's comments are very contrstructive.
> > Benoit: Have covered Dimitri's points. Rene's point still has the point
> the problem statements is not well described.
> > Michael: AN in general is a huge architecture, and we want to work
> bottom up. There is inevitably a huge gap, and people will always feel
> uncomfortable about this.
> > Benoit: We've been listening to everybody; the charter is not perfect;
> but it is not sure that we can do this in the world of AN. This is why the
> ADs have pointed at starting points. But would be very happy if other
> people have other proposals to sovle the same problems, and have a healthy
> discussion. Concern about accepting the existing docs (email from Rene
> today: Afraid of being too fast; if WG in Hawaii, existing docs will be
> blindly accepted) - we should not blindly accept those starting points.
> But we should be open and look at every proposal. We might receive
> blocking comments from IESG.
> > Some discussion on the precise timing of milestones, not captured in
> detail; bottom line: We take things a bit more slowly to allow all views
> to be factored in.
> > Benoit: Next wed, IESG will discuss which BoFs should be approved.
> Benoit will make the point. Then we'll know whether we'll have a BoF or
> WG. If there is a BoF, then we need to understand the expected outcome.
> Would like to hear from Dimitri his opinion. A BoF isn't there to solve a
> problem, but to agree that there is a problem to be solved. Maybe not
> perfectly described. The only positive point in a BoF is if we can
> describe the problem statement better.
> > Laurent: Would prefer a WG meeting. Would be useful to have time for
> face to face discussions. It's a complex topix. BoF is not the right type
> of meeting for this discussion.

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 25 Sep 2014 12:27:22 +0000

Laurent, Sheng, thanks for the corrections. It's hard to capture exactly what was said, so I appreciate the corrections. I wasn't planning on providing updated minutes, I think the mail log captures everything, but can do if people prefer...
Michael

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

Best regards, Laurent.

ANIMA Call

25 Sep 2014

We are still on time.

Sheng, Michael: agree.

I think Benoit was talking about Rene, not Dimitri (cf latest emails sent on the list by Rene).

Brian, Sheng: Agree.

WG and BoF might or not be the right types of meeting for this discussion, yet the need is here. How can we organize ourselves to have such discussions?

Anima mailing list

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

Laurent Ciavaglia

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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 26 Sep 2014 08:04:16 +1200

Michael,

Since we have several corrections, I would appreciate a consolidated
version before I post the notes to the wiki.

(Apologies for dropping from the call after about 45 minutes, but the
audio quality degraded badly for some reason.)

Regards
   Brian

On 26/09/2014 00:27, Michael Behringer (mbehring) wrote:
> ------------------------------------------------------------------------
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 26 Sep 2014 08:09:48 +1200

Dimitri,

On 25/09/2014 23:55, Papadimitriou, Dimitri (Dimitri) wrote:
> Altogether, it reads as if we have two discovery mechanisms (the same for the negotiation process). 

Yes, certainly this needs to be resolved as we move forward. That's one reason
we propose an overview draft, and I expect we will need an issue tracker
as well.

> I have suggested to simplify this by mentioning a "use relationship" between the service agents (and when needed with other components) and the discovery process and leave the discussion as to which level (cf. fig 1 of <http://tools.ietf.org/html/draft-irtf-nmrg-autonomic-network-definitions-03> it belongs/decomposes when this group will put the pieces together at later stage.
> 

You can say "There's no smoke without fire" in English, too. But this is
exactly why we want a good discussion at the next IETF (and the milestones
will be adjusted accordingly).

    Brian