Autonomic Networking Integrated Model and Approach
charter-ietf-anima-02

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/

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.

Thanks you for addressing my BLOCK and comments.

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/

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

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.

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.

I share Alissa's concerns about the broad scoping of the charter and the lack of milestones.