[Anima] (pointer to prior technical discussions on docs) Re: Charter draft 8...

[Rene Struik <[e-mail]>]

Hi Brian:

I went through documents [1-5] and just read the new version of the gap analysis [2].

As said in my email of earlier today (9:56am EDT), I have tried and find technical discussions about the solution documents [3-5] on the mailing list, but failed. Hence, me recommending not mentioning those drafts in the charter.

In case I missed something here, I would be happy to be educated and absorbing previous insights on this material. So, any pointers would be more than welcome.

Best regards, Rene

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]