Re: [coman] FW: COMAN Discussion during IETF 84

peter van der Stok <stokcons@xs4all.nl> Fri, 14 September 2012 09:20 UTC

Return-Path: <stokcons@xs4all.nl>
X-Original-To: coman@ietfa.amsl.com
Delivered-To: coman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4489221F85E6 for <coman@ietfa.amsl.com>; Fri, 14 Sep 2012 02:20:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.154
X-Spam-Level:
X-Spam-Status: No, score=-0.154 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOUVZY28Mrr5 for <coman@ietfa.amsl.com>; Fri, 14 Sep 2012 02:20:20 -0700 (PDT)
Received: from smtp-vbr6.xs4all.nl (smtp-vbr6.xs4all.nl [194.109.24.26]) by ietfa.amsl.com (Postfix) with ESMTP id 031EC21F85AC for <coman@ietf.org>; Fri, 14 Sep 2012 02:20:19 -0700 (PDT)
Received: from roundcube.xs4all.nl (roundcube8.xs4all.net [194.109.20.206]) by smtp-vbr6.xs4all.nl (8.13.8/8.13.8) with ESMTP id q8E9Jmlh038010 for <coman@ietf.org>; Fri, 14 Sep 2012 11:19:48 +0200 (CEST) (envelope-from stokcons@xs4all.nl)
Received: from AMontpellier-556-1-342-254.w90-28.abo.wanadoo.fr ([90.28.102.254]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 14 Sep 2012 11:19:47 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Fri, 14 Sep 2012 11:19:47 +0200
From: peter van der Stok <stokcons@xs4all.nl>
To: coman@ietf.org
Organization: vanderstok consultancy
Mail-Reply-To: <consultancy@vanderstok.org>
In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6404219C16@DEMUEXC006.nsn-intra.net>
References: <80A0822C5E9A4440A5117C2F4CD36A6404219C16@DEMUEXC006.nsn-intra.net>
Message-ID: <3f131b02bfd01bf1cca0e4d0a9060109@xs4all.nl>
X-Sender: stokcons@xs4all.nl (CvAISfxzjPrD31OnGR9rWVWx2QRC6E6C)
User-Agent: XS4ALL Webmail
X-Virus-Scanned: by XS4ALL Virus Scanner
Subject: Re: [coman] FW: COMAN Discussion during IETF 84
X-BeenThere: coman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: consultancy@vanderstok.org
List-Id: Management of Constrained Networks and Devices <coman.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/coman>, <mailto:coman-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/coman>
List-Post: <mailto:coman@ietf.org>
List-Help: <mailto:coman-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/coman>, <mailto:coman-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Sep 2012 09:20:21 -0000

Hi all,

I have been looking through constrained-mgmt-1 document, and I quite 
like it.
I do have a few questions/comments.

In section 1.1 there is no mention of the following aspects:
wireless - I anticipate that a large set of devices are wireless.
battery-less - A subset of the devices will have no power supply and 
get their power from the environment.
sleeping devices - a large part will be accessible during a small 
percentage of the time to save power.

Further the term gateway props up quite often.
Do you mean mean a device situated between two networks which employ 
different network stacks from application to PHY?
Many will interpret the term as such.
I like the proxy which is IP based and does NOT need to be situated on 
a device connecting subnets.
The term router is well known and edge router for a router between 
wireless and wired looks convenient.

section 1.5 discusses classes.
Most important distinction for me is the wired/wireless distinction
and power usage versus power supply.
We might make a matrix (or cube) with on one side the the memory 
aspects and comunication aspects and on the other side the power-supply.

I am impressed by the use case descriptions. They are quite high level.
Where do you want to put more detail: in the Use case or in the 
requirement section 4.1

Details from my point of view are;
1) self organized (home net) versus managed (building control)
2) Configuration happens at several levels (for example):
- application where end-points providing a specified service are 
discovered.
- network, where parameter values (like RPL defines many) need to be 
set to common values to allow interoperability.
The document might point out where we focus.
3) number of subnets, number of devices, response times.
4) stand-alone network, Internet connected network (managed DHCP and 
DNS)
5) operation period, setting-up (commissioning) period, maintenance 
period
6) probably others

Greetings,

peter



Ersue, Mehmet (NSN - DE/Munich) schreef op 2012-08-17 10:54:
> (making it a bit easier to read)
>
> Hi All,
>
> Coman as an activity has been introduced at IETF 84 with a 1-slider 
> in
> the Core WG session (see slide 53, 54 in
> http://www.ietf.org/proceedings/84/slides/slides-84-core-0.pdf).
> Coman document development has been also discussed in the OPS Area 
> open
> session (see
> http://www.ietf.org/proceedings/84/slides/slides-84-opsawg-3.pptx).
>
> There was an ad-hoc discussion on the COnstrained MANanagement 
> (Coman)
> activity during IETF 84 on Wednesday, August 1, 2012.
>
> Participants: Dominique Barthel, Carsten Bormann, Martin Bjorklund, 
> Zhen
> Cao, Benoit Claise, Bob Cole, Mehmet Ersue, Ulrich Herberg, Dan
> Romascanu, Juergen Schoenwaelder, Peter van der Stok
>
> * The discussion on the scope of the work was concerning whether it
> should be focused on the networks with constrained devices only or
> should also cover the management of constrained networks with
> non-constrained devices. The group agreed to describe the use case 
> for
> constrained networks but exclude it for the detailed requirements
> discussion. The requirements for the constrained network use case can 
> be
> put into the annex.
>    - However the behavior of a constrained networks with constrained
> devices is interesting to look at to understand how a constrained
> network (the constrainedness) changes the requirements on the 
> management
> of constrained devices. Carsten Bormann proposed to address the
> management of constrainedness.
>
> * Currently the document gives a top-down application-view with use 
> case
> descriptions. Compared to the top-down view it has been proposed to 
> look
> at the use cases from the bottom-up view to understand the 
> requirements
> of very constrained devices. It would be useful to understand the
> requirements on simplifying the management protocols for very
> constrained devices.
>
> * The deployment type should be discussed, e.g. HAN and AMI have
> different requirements, depending on the size of the network there 
> are
> different requirements.
> * Class of networks should be discussed, where different type of 
> radio
> and communication technologies are in use.
>
> * Zach Shelby is interested in the M2M and cellular scenario. We 
> should
> also look at other SDOs and what they have been doing so far, e.g. 
> ETSI
> device model, OMA device management, or OBIX from OASIS.
> * Chen Zao from China Mobile stated that he finds the cellular and
> mobile network use case as important. Chen can possibly contribute to
> the mobile application use case and requirements.
>
> * One related draft is the configuration draft in the Core WG
> 
> (http://tools.ietf.org/html/draft-nieminen-core-service-discovery-02),
> which defines the basic model for configuration and initial
> authentication. The model in this draft has been integrated into the
> IPSO configuration profile.
> * It has been proposed to list requirements but also features per use
> case. Furthermore the size of a network should be discussed per use
> case.
>
> * Classifying devices based on features:
>    - provide a list of management features and level of features to 
> be
> matched to device classes and use cases,
>    - different devices in a device class might use different subsets.
> * Matching use cases to device classes:
>    - agreed to list the device categories and the assumed network 
> size
> in a use case
>    - provide examples for device classes
> * Giving specific requirements per use case and device class
>    - planned to address in section 4.
>    - series of requirements based on FCAPS
>
> * It has been suggested to reference available work on constrained
> networks/devices (e.g. FP7 EU project Butler-SmartLife). Note that
> Levent Gurgen (cea.fr) kindly provided draft documents (not available
> publicly) of the EU project Butler-SmartLife, which we will use as an
> input for the next version.
>
> * A conclusion section will summarize the gaps and highlight 
> potential
> need for new work.
>
> I would appreciate any comments. Thank you.
>
> Cheers,
> Mehmet
> _______________________________________________
> coman mailing list
> coman@ietf.org
> https://www.ietf.org/mailman/listinfo/coman