Re: [Anima] Charter draft 8...

Rene Struik <rstruik.ext@gmail.com> Thu, 04 September 2014 13:56 UTC

Return-Path: <rstruik.ext@gmail.com>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7A41A88D0 for <anima@ietfa.amsl.com>; Thu, 4 Sep 2014 06:56:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNnajHdUwxP7 for <anima@ietfa.amsl.com>; Thu, 4 Sep 2014 06:56:37 -0700 (PDT)
Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD2551A88CD for <anima@ietf.org>; Thu, 4 Sep 2014 06:56:36 -0700 (PDT)
Received: by mail-ig0-f176.google.com with SMTP id hn18so1108556igb.3 for <anima@ietf.org>; Thu, 04 Sep 2014 06:56:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ZavA61rmOqnYnPw5jmP0pYMUP1JesgnLEVzFqEVzYoo=; b=uW+Bke6C+ESYIFm+tJLLnKILa4LxXCMZCDQMu3yq12NYyQRdA7nQ5plMD8lZhTZEiy wMih7lzKuMwG6BGtDyhkEh8qS3MeQtrhdv3kjYL/9+sXbqd99rGOLZUUtvZGG29eZUke zWIB+gHi2mXDD5J8HouVk0mnEG083T+fMrv7PZS1hLlCrZEVxNgCe3ij2VwQyQ7TpSd7 oXM/ksyDErPK/M9Dq1mv0uhJJq5oxPZMK3bpPMOIb3fsgkSPGy6a3HEuG15XuRUYF/Y+ ngO93LA9mzzIQ8c1ZSNIU0bNF4t/V1xNfFM22IKs9wKozY6rpqMtItUE0VxIpmcfPe9Q eCfw==
X-Received: by 10.50.32.10 with SMTP id e10mr7174601igi.7.1409838996134; Thu, 04 Sep 2014 06:56:36 -0700 (PDT)
Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.118.107]) by mx.google.com with ESMTPSA id ig9sm983616igb.13.2014.09.04.06.56.35 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Sep 2014 06:56:35 -0700 (PDT)
Message-ID: <54086F90.90800@gmail.com>
Date: Thu, 04 Sep 2014 09:56:32 -0400
From: Rene Struik <rstruik.ext@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Michael Behringer (mbehring)" <mbehring@cisco.com>, "Papadimitriou, Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-lucent.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>, "anima@ietf.org" <anima@ietf.org>
References: <54065EC3.9060303@gmail.com> <84675BAA8C49154AB81E2587BE8BDF8323449668@FR711WXCHMBA07.zeu.alcatel-lucent.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21C2EB31@xmb-rcd-x14.cisco.com>
In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF21C2EB31@xmb-rcd-x14.cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/anima/4QWKxu_dwzgSzTYav_bpyr2IaNs
Subject: Re: [Anima] Charter draft 8...
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Sep 2014 13:56:40 -0000

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

On 9/3/2014 9:09 PM, Michael Behringer (mbehring) wrote:
>> -----Original Message-----
>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Papadimitriou,
>> Dimitri (Dimitri)
>> Sent: 03 September 2014 16:33
>> To: Brian E Carpenter; anima@ietf.org
>> 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:anima-bounces@ietf.org] On Behalf Of Brian E
>>> Carpenter
>>> Sent: Wednesday, September 03, 2014 2:20 AM
>>> To: anima@ietf.org
>>> 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
>> Anima@ietf.org
>> https://www.ietf.org/mailman/listinfo/anima
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363