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

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
> > coman@ietf.org
> > https://www.ietf.org/mailman/listinfo/coman
> 
> _______________________________________________
> coman mailing list
> coman@ietf.org
> https://www.ietf.org/mailman/listinfo/coman