Re: [Anima] Martin Vigoureux's Block on charter-ietf-anima-01-05: (with BLOCK and COMMENT)

["Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <[e-mail]>]

Hi Toerless,

Please see in-line.
Thanks

-m

-----Original Message-----
From: Toerless Eckert <[e-mail]> 
Sent: Wednesday, May 1, 2019 16:15
To: Vigoureux, Martin (Nokia - FR/Paris-Saclay) <[e-mail]>
Cc: Barry Leiba <[e-mail]>; [e-mail]; The IESG <[e-mail]>; [e-mail]
Subject: Re: [Anima] Martin Vigoureux's Block on charter-ietf-anima-01-05: (with BLOCK and COMMENT)

Thanks, Martin, inline

On Mon, Apr 29, 2019 at 08:50:16PM +0000, Vigoureux, Martin (Nokia - FR/Paris-Saclay) wrote:
> Hi Barry,
> 
> I had reached the same conclusion, but I think not everyone might and as you highlight it shouldn't be difficult to make sure that there is no misunderstanding of what is in scope and out of scope of the charter.

On the first item, would Barry's rewrite proposal resolve your concern ?
If not, do you have a specific textual suggestion ?

I'd replace paragraphs 3 to 6 with the following 4 paragraphs:
The reference model for autonomic networking developed by the ANIMA WG is defined in draft-ietf-anima-reference-model. This reference model includes, but is not limited to, the Autonomic Networking Infrastructure (ANI) and Autonomic Functions (AF) built from software modules called Autonomic Service Agents (ASA).

The ANI is specified through prior ANIMA work. It is composed of the Autonomic Control Plane (ACP; RFC 8368), Bootstrap over Secure Key Infrastructures (BRSKI) including Vouchers (RFC8366), and the Generic Autonomic Signaling Protocol (GRASP). ANIMA will work on closing gaps and extend ANI and its components.

ANIMA will start to define Autonomic Functions (AF) to enable service automation in networks; it will also work on generic aspects of ASA including design guidelines and lifecycle management including coordination and dependency management.

Work not related to the framework is welcome for review, but WG adoption of such work requires explicit rechartering. Also, ANIMA will not work on Intent or machine learning and other AI techniques without explicit rechartering.


Also, the implications of that sentence are not clear:
   It will rely on Network Management Research Group (NMRG) to define
   the next steps for Intent.
Does it mean that NMRG work on intent can/will be reused by ANIMA for the work defined by this charter, or does it mean that ANIMA expects NMRG to work on Intent such that when ANIMA recharters again it will have material at hand to work on Intent?
The former case would somehow contradict the "no work on intent" rule, and the latter would be setting what NMRG shall work on (but it would be strange that ANIMA specifies the work items of NMRG).
But maybe the intent of that sentence is something completely different. So at best it requires some clarification, or maybe simply needs to be removed.

> On the second item, I am afraid that this charter might be setting expectations on the pace (though not quantified) at which documents will be processed between adoption and LC.

Yes, although i would call it more "preference" than "expectation".

We had from day 1 of ANIMA expectations from our ADs for speedy delivery of implementable results helping operators (rightfully so given how ANIMA is in OPS) versus an ongoing influx of more researchy participants (rightfully so given ANIMA was created from NMRG output).

In this context we felt it to be useful to emphasise to both constituents (OPS/IESG and participants) how we need to manage our process to meet expecations.

Understood, but the rule is not defined clearly enough, and in fact I agree with Alissa on this.
I think that Brian's suggestion is the best option.

Cheers
    Toerless

> -m
> 
> -----Original Message-----
> From: Barry Leiba <[e-mail]>
> Sent: Monday, April 29, 2019 20:59
> To: Vigoureux, Martin (Nokia - FR/Paris-Saclay) 
> <[e-mail]>
> Cc: The IESG <[e-mail]>; [e-mail]; [e-mail]
> Subject: Re: Martin Vigoureux's Block on charter-ietf-anima-01-05: 
> (with BLOCK and COMMENT)
> 
> > I am under the impression that there is a small ambiguity in the 
> > charter, which shouldn't be hard to resolve:
> >
> >    ANIMA work will rely on the framework described in
> >    draft-ietf-anima-reference-model. [...] The three areas of the framework are
> >    [...] and (3) Intent.
> >
> >    ANIMA will not work on Intent [...] without explicit rechartering.
> >
> > The first piece seems to allow for working on Intent while the 
> > second clearly not (within the current charter).
> 
> I tripped over that also when I first read it, but then understood:
> the WG will rely on the framework, which includes a set of things.
> Not all of those things will be worked on via this charter.  In particular, "intent" is one of the things that won't be.
> 
> As I read it, I think the charter is OK.  I suppose it could be clarified this way:
> 
> OLD
> ANIMA work will rely on the framework described in draft-ietf-anima-reference-model. Work not related to this framework is welcome for review, but WG adoption of such work requires explicit rechartering. The three areas of the framework are (1) the Autonomic Networking Infrastructure (ANI), (2) Autonomic Functions (AF) built from software modules called Autonomic Service Agents (ASA) and (3) Intent.
> 
> NEW
> ANIMA work will rely on the framework described in draft-ietf-anima-reference-model, though only parts of the framework are in scope for this charter, as detailed below.  Work not related to this framework is welcome for review, but WG adoption of such work requires explicit rechartering.
> The three areas of the framework are (1) the Autonomic Networking Infrastructure (ANI), (2) Autonomic Functions (AF) built from software modules called Autonomic Service Agents (ASA) and (3) Intent.
> 
> END
> 
> > I'm not sure to understand what the following means:
> >
> >    Acceptance of work items by the WG will be scheduled/throttled so that
> >    contributors can target them to enter WG last call after not more than a number
> >    of IETF meeting cycles agreed by the AD.
> 
> As I read it, it means that the working group won't take on so much work that the work they do take on doesn't get done.  Acceptance is based on negotiating a schedule (based on meeting cycles), and if the schedule isn't met, new work items can't be accepted.
> 
> Barry
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima