[Anima] (on protocol elements and systems) Re: Charter draft 8...

[Rene Struik <[e-mail]>]

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


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

On 9/4/2014 4:22 PM, Brian E Carpenter wrote:
> Rene,
>
> On 05/09/2014 01:56, Rene Struik wrote:
>> 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.
> 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.
>
>> 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,
> 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?
>
>> b) Remove unclarity as to whether the charter aims at autonomic behavior
>> 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.
>
>> 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.
> 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.
>
>> 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 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
>
>> 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
>>
>> On 9/3/2014 9:09 PM, Michael Behringer (mbehring) wrote:
>>>> -----Original Message-----
>>>> From: Anima [mailto:[e-mail]] On Behalf Of Papadimitriou,
>>>> Dimitri (Dimitri)
>>>> Sent: 03 September 2014 16:33
>>>> To: Brian E Carpenter; [e-mail]
>>>> Subject: Re: [Anima] Charter draft 8...
>>>>
>>>> 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.
>>> 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.
>>>>
>>>>> -----Original Message-----
>>>>> From: Anima [mailto:[e-mail]] On Behalf Of Brian E
>>>>> Carpenter
>>>>> Sent: Wednesday, September 03, 2014 2:20 AM
>>>>> To: [e-mail]
>>>>> Subject: [Anima] Charter draft 8...
>>>>>
>>>>> ...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
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Anima mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/anima
>>> _______________________________________________
>>> Anima mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/anima
>>


-- 
email: [e-mail] | Skype: rstruik
cell: [phone] | US: [phone]