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

[Sheng Jiang <[e-mail]>]

Hi, Rene and all,

There is another draft - "Network Configuration Negotiation Problem Statement and Requirements"
https://tools.ietf.org/html/draft-jiang-config-negotiation-ps-03

It gives the detail analysis why we need a generic negotiation protocol, why the existing protocols do not fit, and describes a generic negotiation behavior model, which document [3] follows.

Best regards,

Sheng

>-----Original Message-----
>From: Anima [mailto:[e-mail]] On Behalf Of Rene Struik
>Sent: Friday, September 05, 2014 4:45 AM
>To: Brian E Carpenter; [e-mail]
>Subject: [Anima] (pointer to prior technical discussions on docs) Re: Charter
>draft 8...
>
>
>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]
>
>
>
>_______________________________________________
>Anima mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/anima