Summary: Has a BLOCK. Has enough positions to pass once BLOCK positions are resolved.
Ballot question: "Is this charter ready for external review?"
(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. (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.
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. What is "compounding environment"?
The sentence in the first paragraph: "for automated network management and control of networks that are developed, built and operated by professionals." I found the wording "operated by professionals" confusing. Especially this is the first sentence of the charter. It seems to be a cut and paste reversal from the reference model document where it says: "loosely referred to as "professionally managed" networks". The reference model differentiates between managed networks and unmanaged networks. It further differentiates for managed networks between traditional (non-autonomic) networks and autonomic networks. The interpretation is the network does need to managed (by professionals), and then one can introduce autonomic management, due to the additional security and trust issues the autonomic model does not cover. Suggest to use the wording of the reference model document to give context or (I prefer) reuse the wording in the original charter for the first two paragraphs as the original was very clear in scope of use.
I support Alissa’s positions on clarifying the throttling mechanism (BLOCK #1) and concerns about the size of the proposed scope relative to historical publication rates (BLOCK #2) I also have a few editorial nits: s/signalling/signaling/ s/management,autonomic/ management, autonomic/ s/the the/the/
I agree with comments raised in the Block positions, especially the very open-ended nature of the charter. One editorial nit: 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 extended ANI and its components. nit: s/extended/extending/
I share Alissa's concerns about the broad scoping of the charter and the lack of milestones.
I support Alissa's second point that the charter is very broad and it could be more productive to use the tool of having a charter to focus down to a few more specific items. However, I don't know the work of this group well enough to provide any more detailed guidance on that.
Hi, DISCUSS/BLOCK part, for the record. start --- 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). DISCUSS/BLOCK part, for the record. 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.
Please note that I support Martin's BLOCK with respect to the support or absence of support of "Intent". Deborah's question about 'by professionals' is indeed a very valid point.
I most definitely supports Alissa's second Block. This charter allows anything that can be claimed to relate to the ANIMA framework. That is way to open, I think this charter should be rewritten to more explicitly target the work there exist interest in pursuing. That way we (IESG) are also not writing a blank check that the WG will cash in later.