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

[peter van der Stok <[e-mail]>]

Hi Mehmet,

Reaction to your remark below

> 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.
>

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


Ersue, Mehmet (NSN - DE/Munich) schreef op 2012-09-17 15:32:
> Hi Peter,
>
> thank you for your comments. See below.
>
> Cheers,
> Mehmet
>
> ...
>> 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.
>
> We didn't want to make the Introduction too long. However, you are 
> right
> these are important aspects and should be added.
>
>> 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?
>
> Yes, it is often necessary to translate betw. two stacks.
>
>> 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
>
> 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?
>
>> 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
>
> IMO the requirements section should be compact and focusing on
> requirements as short statements. The requirement should be explained 
> as
> much as necessary.
>
>> 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
>
> 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
>
>> 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
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/coman
>>
>> _______________________________________________
>> coman mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/coman
> _______________________________________________
> coman mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/coman