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

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.

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.

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

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.

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.

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.

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.

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

I'm a No Objection on going for external review, but I have thoughts that heavily overlap Adrian, Pete and Ted.

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.

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.