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

[Ballot comment]
I a little bit wonder whether "ANIMA will work on closing gaps and
extending the ANI and its components" is more open-ended than it needs
to be, but have no alternative restricting clauses to suggest.

I'd like to confirm whether "BRSKI features, including proxies,
enrollment, adaptions over various network protocols, variations of
voucher formats" is intended to stay within the bounds of
"professionally-managed networks" per the first paragraph.

[Ballot comment]
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.

[Ballot comment]
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/

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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/

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

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

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

What is "compounding environment"?

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot block]
Hi,

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

[Ballot comment]
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.

Added charter milestone "Adoption of initial drafts on AN components: Discovery and negotiation protocol(s), Bootstrap a trust infrastructure solution, Autonomic control plane solution", due March 2015

[Ballot comment]
Was:

Holding the block in this WG format to allow time for solicited feedback on the updated charter.

From Benoit, Comment (2014-10-29)

Charter v15 has been posted, hopefully addressing the latest issues.
As discussed with Ted, Joel and me, we need to make sure that:
1. the (perceived) overlap with the HOMENET is clarified
2. the HOMENET community provides some feedback on v15
Therefore, Ted will be holding a BLOCK until the two conditions are met.

[Ballot comment]
I'm sad that two of my comments on the previously reviewed charter were ignored, especially when Brian said that he was going to make changes:

1st paragraph:

  An autonomic function works in a distributed way across various
  network elements, but allowing central guidance and reporting, and
  co-existence with non-autonomic methods of management.

Do all autonomic functions work distributed? I'm not sure what this means.

Brian's response: "If they aren't distributed, they just aren't candidates for protocol work. I think the logic of this sentence needs adjustment."

9th paragraph:

  Definition of a discovery functionality for autonomic functions

I don't understand what that means. By "functionality" do you mean protocol?

Brian's response: "Definition of a discovery protocol for autonomic nodes."

[Ballot comment]

I support Ted's block (I think:-).  I suspect that this will be sorted
out ok by the WG if it can be, but I'd also like some better clarity
on how the security bootstrapping here and in homenet are
related/differ.

[Ballot block]
The thing I still see missing in this charter is an explanation of how "professionally managed" and "autonomic" mesh.  What does it mean for an autonomic network to be professionally managed?  What distinguishes an anima network from a homenet, for example?  The charter still reads as though it's solving the same problem as homenet; I realize that this isn't what the proponents actually have in mind, but some greater clarity would be nice: it's still not clear in my mind from reading the charter or from my discussion with Joel and Benoit.

[Ballot comment]
Thanks for the revisions of this charter since I last reviewed it.
The shortening of the text is very helpful.

Para 2
s/build/builds/  or  s/build/will build/

Para 2
Is the work from the NMRG documented anywhere that can be referenced?
I see the later reference to draft-irtf-nmrg-an-gap-analysis, but I
wonder whether there is anything published as a stable reference to
the definitions, design goals and architectural model.

Penultimate para
s/an reference/a reference/

[Ballot comment]
From Benoit, Comment (2014-10-29)

Charter v15 has been posted, hopefully addressing the latest issues.
As discussed with Ted, Joel and me, we need to make sure that:
1. the (perceived) overlap with the HOMENET is clarified
2. the HOMENET community provides some feedback on v15
Therefore, Ted will be holding a BLOCK until the two conditions are met.

[Ballot comment]
Charter v15 has been posted, hopefully addressing the latest issues.
As discussed with Ted, Joel and me, we need to make sure that:
1. the (perceived) overlap with the HOMENET is clarified
2. the HOMENET community provides some feedback on v15
Therefore, Ted will be holding a BLOCK until the two conditions are met.

Unless there are no more BLOCKs on the ANIMA charter, the ANIMA meeting in IETF 91 will be a WG-forming BoF, with Brian Carpenter and Michael Behringer as BoF chairs.

Regards, Benoit

[Ballot comment]

It is not at all clear to me that the security/provisioning
model here would be suitable for home/small networks.
I trust that the WG will evaluate that as they adopt a
draft on that topic and perhaps consider addressing
that via some applicability statement on the method
followed here. I would also strongly encourage this WG
to co-ordinate with HOMENET on this topic. I suspect
that different solutions may be needed for the same
problem (device security information provisioning) in
those different spaces. But there may be value in
attempting to also consider common pieces of what
may be two different overall solutions/approaches.

[Ballot comment]
I find the reference to OSPF in the opening paragraph a bit odd, as implementations of OSPF automatic initial configuration do exist and the draft is a WG draft.

[Ballot comment]
I think this can go to external review, but there are many issues that will need to be resolved during that period for this to get properly chartered.

[Ballot comment]
I am fine with this going for external review given that I expect that review to be rather verbose. With the potential overlap between this work and other WGs (e.g., homenet) and the history of (auto | zero)conf work in the IETF, I will be interested to see how that discussion plays out.

[Ballot comment]
I'm changing this to No Objection for the External Review, since I think the real work needs to happen in a discussion between the Homenet people and the ANIMA people, not between me and Benoit.  The reason I chose BLOCK and not no objection with comment is the issue of whether to resolve this in a BoF or in External Review discussions, but I think the right thing to do is move forward with External Review and see what happens, and we can revisit the BoF/Charter question after the results of that discussion are in.

The following exchange between Mark and Brian illustrates what I want out of a BoF or External Review discussion:

Mark:

[...]

In any case, It's not hard to extrapolate from here that in a year's time or so, if we continue on the current trajectory, homenet will have come up with its own non-anima secure bootstrapping, and anima will have come up with its own non-homenet distributed IPv6 prefix configuration. 

Brian:

Which we should try to coordinate, since I see no reason in
theory why there can't be common underlying mechanisms between
enterprise, carrier and SOHO. But I don't want to hear in 2 years
time that homenet is stuck because anima hasn't met its milestones.

Ted:

Right now Homenet has a solution for the distributed configuration problem with a spec and at least one WIP implementation, and is working seriously on the mutual authentication problem.  There may be some synergy between what Homenet is trying to do and what ANIMA is trying to do.  If there is, it would be a big win to coordinate the two groups' activities.  It may also be that there is no synergy, and the efforts are really effectively independent.

Before the working group is chartered, I would like to see some clarity reached about this.  If there is synergy, I'd like there to be some clear agreement about how to move forward so that ANIMA can achieve its goals and Homenet can achieve its goals without either creating an interop problem or stalling.

[Ballot block]
The following exchange between Mark and Brian illustrates what I want out of a BoF or External Review discussion:

Mark:

[...]

In any case, It's not hard to extrapolate from here that in a year's time or so, if we continue on the current trajectory, homenet will have come up with its own non-anima secure bootstrapping, and anima will have come up with its own non-homenet distributed IPv6 prefix configuration. 

Brian:

Which we should try to coordinate, since I see no reason in
theory why there can't be common underlying mechanisms between
enterprise, carrier and SOHO. But I don't want to hear in 2 years
time that homenet is stuck because anima hasn't met its milestones.

Ted:

Right now Homenet has a solution for the distributed configuration problem with a spec and at least one WIP implementation, and is working seriously on the mutual authentication problem.  There may be some synergy between what Homenet is trying to do and what ANIMA is trying to do.  If there is, it would be a big win to coordinate the two groups' activities.  It may also be that there is no synergy, and the efforts are really effectively independent.

Before the working group is chartered, I would like to see some clarity reached about this.  If there is synergy, I'd like there to be some clear agreement about how to move forward so that ANIMA can achieve its goals and Homenet can achieve its goals without either creating an interop problem or stalling.

[Ballot comment]
A very long charter tex, but that has been said multiple times already. Better to trim the charter to something that has less words but is more expressive about the scope.

[Ballot comment]
I do think this could be very useful work if the scope is clear and the objectives can be met.  The current charter reads as if it is quite broad to me.

I agree with Pete that there are some things in the charter that are not quite clear enough.  When a security model is mentioned, I'm guessing it means narrowly scoped for whatever is defined.  Could you elaborate on what is intended?

The SACM WG and I2NSF (just a mailing list at this point) may have some overlap with the security portion or maybe not depending on what was intended.  It may be helpful to make sure there is some relationship (folks from each paying attention).

Thanks.

[Ballot block]
Why is this on the agenda as a proposed charter for external review when we have an approved BoF of the same name for Honolulu?

[Ballot comment]
I have no objection to having a go at this work, although I really worry that scope needs to be very tightly screwed down and enforced to stop this going off the rails.

The charter text here is hugely long. Does it need so many words to scope what the working group is going to do? The general problem space description reads more like a BoF proposal, and I worry that more words means more loopholes (or rat holes) for the introduction of work that is out of the principal focus.

I'm sure that good discussions have led to the list of four areas of self management. I do worry that these may be three too many to achieve any progress. Maybe it would be better to walk before we run?

But I won't Block this charter for any of this. Just ask the interest parties to think hard.

[Ballot comment]
This is right on the borderline of "Block" for me. I have no objection to the basic work to be done at all, but there's a bunch of stuff in this charter that is unclear to me. I really hope you'll do an edit pass before external review. Overall, I think the text of this charter is unwieldy and needs to be reduced to make it clearer. Specific comments below.

1st paragraph:

  An autonomic function works in a distributed way across various
  network elements, but allowing central guidance and reporting, and
  co-existence with non-autonomic methods of management.

Do all autonomic functions work distributed? I'm not sure what this means.

  s/behaviors/functions

It seems like you switched terminology for no particular reason.

2nd paragraph: (nit) s/healing and optimization/healing, and optimization
(I actually was momentarily confused as to what the four were.)

Seems like the 3rd paragraph could be reduced.

I'm not sure what purpose the 4th paragraph serves. Sounds more like the intro to a document this WG should produce. I would strike it.

6th paragraph:

  The infrastructure should be capable of

Don't you mean "The components should be capable of"?

9th paragraph:

  Definition of a discovery functionality for autonomic functions

I don't understand what that means. By "functionality" do you mean protocol?

10th paragraph. First, let me just correct the English:

  Each proposal should have its own motivation and complete workflow as
  an autonomic process. The design of these proposals should clearly
  target reusability in other use cases. The WG will verify all
  proposed solutions to make sure the components are reusable,
  necessary, and sufficient.

But even with that done, I'm not at all sure what the above means. Does the first sentence simply mean that the document should not normatively reference each other, or is it saying something else? And the last sentence seems repetitive and obvious. Does it mean something that I'm missing?

11th paragraph: Does the first sentence simply mean, "In addition, the WG will develop solutions for the following two use cases:"? Perhaps you could say that. :-)

[Ballot comment]
I urge you to split the very long fourth paragraph, for readability.  A good way would be to insert two paragraph breaks into it, one before "A simple example is", and one before "Autonomic networking is intended to reduce OpEx".

[Ballot comment]
I've been involved in this one through the non-wg forming bof, though it is not wg.

I think this charter reflects a narrowly scoped activity poised for a relatively short timeline, which if successful leaves the door open to rechartering.

[Ballot comment]
I've been involved in this one through the non-wg forming bof, though it is not my wg.

I think this charter reflects a narrowly scoped activity poised for a relatively short timeline, which if successful leaves the door open to rechartering.