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

[Brian E Carpenter <[e-mail]>]

Hi all,

I've taken the liberty of posting an update to the draft charter
at https://trac.ietf.org/trac/anima/wiki/Recharter2019. I tried
to respond to all the IESG comments, and in particular:

(a) I deleted Intent from the summarised reference model framework,
since the reference model doesn't usefully define Intent.

(b) I tried to make the statement about workload throttling more
implementable.

(c) I still think that the laundry list of *possible* work items
is useful (it helps to define the scope) but I've tried make it
clear that it is only the "indicative scope of possible work items".
It really isn't mission creep; all the items mentioned relate
directly to the ANI and AF topics.

(d) I intentionally removed the reference to not covering machine
learning and AI. It isn't suggested anywhere in the reference model,
so why even mention it?

(e) I fixed nits and tuned the wording in several places.

I hope this helps. We really need a new charter before Montreal.
WG Chairs and AD, over to you...  

Regards
   Brian Carpenter

On 02-May-19 08:39, Brian E Carpenter wrote:
> Hi Alissa,
> 
> On 02-May-19 08:05, Alissa Cooper via Datatracker wrote:
> ...
>> ----------------------------------------------------------------------
>> BLOCK:
>> ----------------------------------------------------------------------
>>
>> (1) "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."
>>
>> I don't understand the implications of this. What happens if the adopted work
>> items have not entered WGLC after the agreed number of cycles? If the answer is
>> anything other than "the WG abandons the work," I don't understand how this is
>> a throttling mechanism. A throttling mechanism would need an explicit limit on
>> the number of adopted work items at any one time, I think.
> 
> I agree that the text is a bit illogical. In a sense it's unnecessary, because
> every WG should be matching its workload to its capacity. Maybe that's all
> we should say, rather than trying to describe a slightly vague algorithm?
> 
>> (2) The proposed work items is a very large and somewhat unbounded list of
>> items, whereas the purpose of writing a charter is to scope the work of the WG
>> and hopefully set out a realistic work plan that will be accompanied by
>> deployment. For a WG that has produced 5 documents in the last 5 years, I think
>> the charter needs to more narrowly focus on the most highly prioritized work
>> items. Once those are nearing completion, it seems as though evaluation of what
>> is needed next based on deployment experience would then dictate the next set
>> of items for another re-charter.
> 
> I think the point here is that now that the relatively small number of
> infrastructure documents are almost finished, the next stage opens up
> the possibilities for a much wider range of work that builds on the
> infrastructure. The priorities aren't even obvious. So this goes with
> the previous point, and to quite some extent the criteria will be
> whether the WG has capacity more than which topic has priority.
> 
> That's why there's a bucket list of work items and a short list of
> immediate milestones.
> 
> Would this help?
> 
> s/Proposed work items include.../Possible work items include.../
> 
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> It would be good to see milestones with dates before this gets approved.
>>
>> I think this charter would benefit from an English edit pass before going out for external review.
> 
> I'll volunteer, when the open issues have been resolved.
> 
>> What is "compounding environment"?
> 
> An excellent question.
> 
>     Brian
>