Subject: [Anima] Charter draft 8...

From: Brian E Carpenter <[email-masked]>
Date: Wed, 03 Sep 2014 12:20:19 +1200

...is attached and in the wiki. Many points have been revised.
I also put a list of issues addressed by this version in the wiki.

http://trac.tools.ietf.org/bof/anima/trac/wiki/DraftCharter

Regards
   Brian Carpenter

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Wed, 3 Sep 2014 23:33:11 +0000

My comments on this new version of the charter are the following:

1. "A complete solution for autonomic networking would be a very ambitious goal. The scope of
this working group's effort for the initial stage is much more modest"

but then milestones include specific items for delivery of a "complete solution" 

Jan 2016 - WGLC for autonomic control plane draft
Jan 2016 - WGLC for overview draft
           - Mar IETF - 
Apr 2016 - submit autonomic control plane draft to IESG (standards track)

-> this BoF group should either stay modest or ambitious but can't both at the same time.

2. Concerning use cases; some uses cases are qualified a priori as "justified" (where is the proof ?), operationally required (where is the support ?) and mature (have they ever been discussed on this list ?) others are positioned as complex, out of scope, for further study, "boiling the ocean" ... for the NMRG may be (if they are kind enough).

-> This BoF group has to set a clearer process (criteria, metrics, etc.) if it wants to pre-select use cases and include them in the charter.

3. In the meantime, this arbitrary pre-selection misses feedback from BoF session and discussion on this list: is pre-selection the right approach ? assuming a pre-selection would be performed would the resulting use cases be sufficiently representative ? some use cases may help in progressing understanding of AN but those may not necessarily correspond to the ones with high priority from an operational perspective ? 

-> For all these reasons, it has been suggested to avoid pre-selection and prefer the approach where it is up to participant (the "community") to raise the case they would like to see considered in the design process and not the charter (which is intended to steer contributions and not a priori classify them as low priority (see below)). Why is this alternative not considered ? what are the objective arguments to favor pre-selection instead of an  open process ?

4. "Some important topics are intentionally not included in the initial goals as they are
considered separate matters that should be considered later, although they are in the scope 
for discussion with lower priority:"

Yet another ambiguity: how a topic can be classified at the same time as "important" but considered with "low priority"; this also opens the question who sets the priorities ? and more fundamentally have we documented with tangible arguments where the operational priorities are ?

5. "It is recognized that autonomic functions will co-exist with traditional methods of management and configuration, and the initial focus will be on self-configuration." 

Who has recognized this fact (as phrased it looks as ground truth) ? is it a transient or a permanent situation ? does it imply that the initial focus should be on configuration ? looks again contradictory also from that perspective, one could read following this statement it would be much more appropriate to look at functionality remaining partially covered more than those covered (configuration).

I would appreciate the answer going well beyond the arguments "we are not aiming at mathematically correct statements" (as I'd like just to see coherent, consistent and verifiable statements), "this is how we used to do it" (actually it isn't since IETF has always been driven by cross-fertilization and not single viewpoints), "this how AD's have asked us to shape the charter" (despite the fact that ADs don't set the technical agenda, don't select use cases or their number, etc.)

-d.

> -----Original Message-----
> From: Anima [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Wednesday, September 03, 2014 2:20 AM
> To: [email-masked]
> Subject: [Anima] Charter draft 8...
>

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Thu, 4 Sep 2014 00:54:38 +0000

-d.

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 4 Sep 2014 01:09:24 +0000

> From: Anima [mailto:[email-masked]] On Behalf Of Papadimitriou,
> Dimitri (Dimitri)
> Sent: 03 September 2014 16:33
> To: Brian E Carpenter; [email-masked]
> Subject: Re: [Anima] Charter draft 8...
> 
> 1. "A complete solution for autonomic networking would be a very
> ambitious goal. The scope of this working group's effort for the initial stage
> is much more modest"
> 
> Jan 2016 - WGLC for autonomic control plane draft Jan 2016 - WGLC for
> overview draft
>            - Mar IETF -

I do not understand. The milestones do not talk about "complete solution" at all? What are you referring to and how do you suggest we change it? 
 
> 2. Concerning use cases; some uses cases are qualified a priori as "justified"
> (where is the proof ?), operationally required (where is the support ?) and
> mature (have they ever been discussed on this list ?) others are positioned
> as complex, out of scope, for further study, "boiling the ocean" ... for the
> NMRG may be (if they are kind enough).
> 
> -> This BoF group has to set a clearer process (criteria, metrics, etc.) if it
> wants to pre-select use cases and include them in the charter.

This is a very open and broad statement. Can you please be specific? I don't think we should start by defining what "justified" (term is actually not used in the charter), "required" and "mature" means. 

I suggest you specifically tell us which specific things are not * (reuse term above). 

> 3. In the meantime, this arbitrary pre-selection misses feedback from BoF
> session and discussion on this list: is pre-selection the right approach ?
> assuming a pre-selection would be performed would the resulting use cases
> be sufficiently representative ? some use cases may help in progressing
> understanding of AN but those may not necessarily correspond to the ones
> with high priority from an operational perspective ?
> 
> -> For all these reasons, it has been suggested to avoid pre-selection and
> prefer the approach where it is up to participant (the "community") to raise
> the case they would like to see considered in the design process and not the
> charter (which is intended to steer contributions and not a priori classify
> them as low priority (see below)). Why is this alternative not considered ?
> what are the objective arguments to favor pre-selection instead of an  open
> process ?

This discussion *is* the open process, Dimitri. :-)    Please raise the use cases you would like to see considered, and if the community agrees, we'll put them on. What we can NOT have is to keep circling around this question forever. The goal is to have this discussion now, agree on one, and THEN, when the charter is agreed on, we stick to it. 

> 4. "Some important topics are intentionally not included in the initial goals
> as they are considered separate matters that should be considered later,
> although they are in the scope for discussion with lower priority:"
> 
> Yet another ambiguity: how a topic can be classified at the same time as
> "important" but considered with "low priority"; this also opens the question
> who sets the priorities ? and more fundamentally have we documented
> with tangible arguments where the operational priorities are ?

Again, please refrain from general procedural questions, and state which topic we should include. We're open to any argument. And it is all of us here who set the priority. 
 
> 5. "It is recognized that autonomic functions will co-exist with traditional
> methods of management and configuration, and the initial focus will be on
> self-configuration."
> 
> Who has recognized this fact (as phrased it looks as ground truth) ? 

We are saying that there won't be for the first phase a COMPLETE autonomic device with this effort, but we go function by function. I consider this very reasonable actually. Why do you disagree with this statement? Are you suggesting we should aim for fully self-managing devices? 

Again, once the charter is agreed by all the goal is that we all agree on what's written here. It does NOT mean that the people contributing to the charter so far are imposing this. 

> is it a
> transient or a permanent situation ? does it imply that the initial focus
> should be on configuration ? looks again contradictory also from that
> perspective, one could read following this statement it would be much
> more appropriate to look at functionality remaining partially covered more
> than those covered (configuration).

This is not the intention, and I suggest we re-phrase to "It is recognized that autonomic functions will FOR THE FORESEEABLE FUTURE co-exist with traditional methods of management and configuration, and the initial focus will be on self-configuration."

Would this address your concern? If not, can you suggest text please? 

Michael

> I would appreciate the answer going well beyond the arguments "we are
> not aiming at mathematically correct statements" (as I'd like just to see
> coherent, consistent and verifiable statements), "this is how we used to do
> it" (actually it isn't since IETF has always been driven by cross-fertilization
> and not single viewpoints), "this how AD's have asked us to shape the
> charter" (despite the fact that ADs don't set the technical agenda, don't
> select use cases or their number, etc.)
> 
> -d.
> 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Rene Struik <[email-masked]>
Date: Thu, 04 Sep 2014 09:56:32 -0400

Dear all:

Some brief feedback on the draft charter (08):

a) Remove reference to drafts [3-5] as documents to be adopted from the 
charter.
I have tried and find technical discussions about these documents on the 
mailing list, but failed. It is unclear what problems the designs in 
[3-5] solve, security goals are missing, and design seems to be adhoc.

b) Remove unclarity as to whether the charter aims at autonomic behavior 
or coming up with a default protocol.
The charter seems to originate from desire to simplify network 
management, but from reading documentation it seems to mostly deal with 
(yet another?) set of protocols, without making it clear how this helps 
in fostering autonomic/automatic behavior.

The main culprit here seems to be that there is no architectural 
blueprint. I am afraid having yet more point solutions to unclear 
problems does not bring simplified, yet flexible and secure network 
management, esp. for internet of things devices, closer.

I read the following drafts:
[1] draft-irtf-nmrg-autonomic-network-definitions-03
[2] draft-irtf-nmrg-an-gap-analysis-00 (sorry, did not read 01 yet)
[3] draft-jiang-config-negotiation-protocol-02
[4] draft-pritikin-bootstrapping-keyinfrastructures-00
[5] draft-behringer-autonomic-control-plane-00

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 05 Sep 2014 08:22:39 +1200

Rene,

> a) Remove reference to drafts [3-5] as documents to be adopted from the

They are not proposed as documents to be adopted. They are proposed
as starting points, which is quite a different statement. I'm also
now aware of at least one other starting point for [3], which might
be added. It's very common to have such starting points for WG
discussion.

> [3-5] solve, 

I disagree. [4] and [5] include their own problem statements (which is
why they were considered as uses cases in the BOF). [3] has a separate
problem statement draft, draft-jiang-config-negotiation-ps.

> security goals are missing, 

They all consider security requirements, so I think that is unfair,
and since they are only starting points, not even proposed for WG
adoption, they are not called on to be complete. I think everyone
is clear that an insecure autonomic control plane would be
disastrous, but we can't develop the threat model in the abstract.

> and design seems to be adhoc.

That seems to me to be the case for every initial design. But again,
why does this really matter for starting points?

> or coming up with a default protocol.

I don't see any ambiguity. It aims at common infrastructure as the basis
for autonomic functions, co-existing with traditional management tools.

> in fostering autonomic/automatic behavior.

Now here your logic defeats me. How can we foster autonomic behaviour,
in a multivendor world, without agreeing on standard protocols to
achieve such behaviour?

It's true, I think, that those of us working on this have not found
any existing protocol that seems to have the right characteristics,
because there is a profound difference between top-down management
and autonomic self-management. I'm not too happy about this but
there it is.

> management, esp. for internet of things devices, closer.

I disagree with this assessment. In general, as I've mentiond before,
I have seen the IETF failing quite often when it aims at architectural
blueprints, and succeeding quite often (but certainly not always) when
it aims at simple generic tools. I believe that this is the aiming
point here too (not the same thing as point solutions).

I thing the IoT angle needs more discussion, however. What are the
components in an IoT scenario that would act as AN service agents?

As Michael said elsewhere, we are now looking for specific text
change proposals to the draft charter.

Regards
   Brian

>>> -> this BoF group should either stay modest or ambitious but can't
>>> both at
>>> the same time.
>> I do not understand. The milestones do not talk about "complete
>> solution" at all? What are you referring to and how do you suggest we
>> change it?
>>  
>> This is a very open and broad statement. Can you please be specific? I
>> don't think we should start by defining what "justified" (term is
>> actually not used in the charter), "required" and "mature" means.
>>
>> This discussion *is* the open process, Dimitri. :-)    Please raise
>> the use cases you would like to see considered, and if the community
>> agrees, we'll put them on. What we can NOT have is to keep circling
>> around this question forever. The goal is to have this discussion now,
>> agree on one, and THEN, when the charter is agreed on, we stick to it.
>>
>> Again, please refrain from general procedural questions, and state
>> which topic we should include. We're open to any argument. And it is
>> all of us here who set the priority.
>>  
>> We are saying that there won't be for the first phase a COMPLETE
>> autonomic device with this effort, but we go function by function. I
>> consider this very reasonable actually. Why do you disagree with this
>> statement? Are you suggesting we should aim for fully self-managing
>> devices?
>>
>> Again, once the charter is agreed by all the goal is that we all agree
>> on what's written here. It does NOT mean that the people contributing
>> to the charter so far are imposing this.
>>
>>> is it a
>> This is not the intention, and I suggest we re-phrase to "It is
>> recognized that autonomic functions will FOR THE FORESEEABLE FUTURE
>> co-exist with traditional methods of management and configuration, and
>> the initial focus will be on self-configuration."
>>

---

From: Rene Struik <[email-masked]>
Date: Thu, 04 Sep 2014 17:05:55 -0400

Hi Brian:

In my mind, some IETF protocols fail not necessarily because of grand 
architectural blueprint visions, but because they may not solve the 
right problem, may not consider sufficient contextual information (e.g., 
by leaving out certain lifecycle elements), or do not sufficiently 
consider user experiences. That is why one now has mailing lists trying 
to tackle topics as diverse as "opportunistic security", "endymail", 
etc. While these are not necessarily examples in the autonomic 
networking realm, this illustrates that it is very well possible to 
arrive at a mismatch when trying to weave protocols together to form a 
nimble, flexible, and easy to use system. This seems to suggest that one 
must step back and reflect on the architectural picture as well. Hence, 
my assessment re "culprit".

Best regards, Rene

point here too (not the same thing as point solutions)