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

From: peter van der Stok <[email-masked]>
Date: Fri, 14 Sep 2012 11:19:47 +0200

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/coman

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 17 Sep 2012 15:32:15 +0200

Hi Peter,

thank you for your comments. See below.

Cheers, 
Mehmet 

...
> percentage of the time to save power.

We didn't want to make the Introduction too long. However, you are right
these are important aspects and should be added. 
 
> different network stacks from application to PHY?

Yes, it is often necessary to translate betw. two stacks.

> Most important distinction for me is the wired/wireless distinction

Looking at it from the network management pov. why is actually
wired/wireless distinction so important? Wired and wireless devices can
be similarly constrained or powerful. I think power consumption is not
directly related to being wireless.

> and power usage versus power supply.

Do you mean battery usage vs. power supply?

> Where do you want to put more detail: in the Use case or in the

IMO the requirements section should be compact and focusing on
requirements as short statements. The requirement should be explained as
much as necessary.

> 5) operation period, setting-up (commissioning) period, maintenance

Thanks. Let's see how this evolves during editing. 

Would you like to match them to corresponding use cases and provide some
text?

Cheers,
Mehmet

---

From: peter van der Stok <[email-masked]>
Date: Tue, 18 Sep 2012 10:23:57 +0200

Hi Mehmet,

Reaction to your remark below

> directly related to being wireless.

Wireless is interesting to do retrofit, without recabling, leading to 
lower installation cost.
The disadvantage is all the trouble with power saving, reducing 
resources and battery consumption.

The moment you have cables there is also some form of power, and 
putting in more resources is not extremely expensive.

Consequently in my view wireless and low-resource are terms which apply 
to almost the same set of devices.

I will think about text (few) for the requirements. and some more text 
for individual subjects

Peter