Subject: Re: [Coma] (no subject)
From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
To: "ext Yan Wang" <[email-masked]>
Cc: [email-masked]
Date: Sat, 30 Jun 2012 15:28:59 +0200
List-Id: Management of Constrained Networks and Devices <coma.ietf.org>

Hi Yan,

> Maybe we should propose several use cases of different kinds of
networks. 
> It is good to make clear about their common requirements and
individual requirements.

I would appreciate it if you could provide the type of constraint
networks/devices and the use cases you have in mind as input for
discussion.

Our aim is to look at the use cases and requirements independently of
existing protocols. We might highlight gaps in existing technologies but
selecting the right protocol is an individual decision. 

Cheers, 
Mehmet 

> -----Original Message-----
> From: ext Yan Wang [mailto:[email-masked]]
> Sent: Friday, June 29, 2012 3:11 PM
> To: Ersue, Mehmet (NSN - DE/Munich); 'Juergen Schoenwaelder'
> Cc: [email-masked]
> Subject: RE: [Coma] (no subject)
> 
> Dear Mehmet and Juergen,
> Thank you for your replies. Service management is really more suitable
to
> put in the use case.
> There are many kinds of constraint networks and devices, as well as
many
> kinds of existing protocols for network management. I am still not
quite
> clear about the management requirements. Maybe we should propose
several use
> cases of different kinds of networks. It is good to make clear about
their
> common requirements and individual requirements.
> 
> 
> Best wishes,
> Yan
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> > Ersue, Mehmet (NSN - DE/Munich)
> > Sent: Friday, June 29, 2012 5:15 PM
> > To: Juergen Schoenwaelder; Yan Wang
> > Cc: [email-masked]
> > Subject: Re: [Coma] (no subject)
> >
> > Hi Yan,
> >
> > service management is a huge topic area and I assume we cannot cover
it
> > exhaustively. IMO service management should be discussed as part of
the
> use
> > cases. Based on this we need to understand the requirements on the
> > management of networks with constrained devices.
> >
> > Cheers,
> > Mehmet
> >
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]] On
Behalf
> > Of ext
> > > Juergen Schoenwaelder
> > > Sent: Thursday, June 28, 2012 5:19 PM
> > > To: Yan Wang
> > > Cc: [email-masked]
> > > Subject: Re: [Coma] (no subject)
> > >
> > > On Thu, Jun 28, 2012 at 04:29:29PM +0800, Yan Wang wrote:
> > >
> > > > By the way,
> > > >
http://tools.ietf.org/html/draft-ietf-lwig-guidance-00#section-4.5
> > mentioned
> > > > development of a light-weight SNMP agent for resource
constrained
> > devices
> > > > running the 6LoWPAN/RPL protocol stack.
> > >
> > > We have implemented an SNMP stack on Contiki and we have published
> > > details about it. I think I only very partially agree with what is
> > > written in this section 4.5. There is also an old expired I-D that
> > > might be relevant: <draft-hamid-6lowpan-snmp-optimizations-03.txt>
> > >
> > > > What the relationship between coma and core, coma and lwig?
> > >
> > > My understanding is that CORE is specifying CoAP. CoAP may be used
for
> > > management but CORE is not chartered to specifically look at this
> > > question. LWIG is looking at coming up with general guidelines for
> > > light-weight implementations of IP protocols and hence might
include
> > > guidelines for implementing SNMP. COMA probably can take a broader
> > > look at what is needed and in particular what the requirements
driving
> > > things are. There is also discussion on the netconf WG list
related to
> > > constrained devices, but it is as of now not chartered work.
> > >
> > > I assume COMA is an attempt to provide a common place to discuss
the
> > > management requirements and aspects of constrained networks and
> > > devices instead of having discussions in several places.
> > >
> > > Of course, as Bert Wijnen kept saying, adding a protocol with the
best
> > > intentions to replace other protocols just leads at the end to one
> > > more protocol. If that applies to discussion lists as well, then
we
> > > just have one more. ;-)
> > >
> > > /js
> > >
> > > --
> > > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > > Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen,
Germany
> > > Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
> > > _______________________________________________
> > > Coma mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/coma
> > _______________________________________________
> > Coma mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/coma

From: "Yan Wang" <[email-masked]>
To: "'Ersue, Mehmet \(NSN - DE/Munich\)'" <[email-masked]>, "'Juergen Schoenwaelder'" <[email-masked]>
Date: Fri, 29 Jun 2012 21:11:09 +0800
Cc: [email-masked]
Subject: Re: [Coma] (no subject)

Dear Mehmet and Juergen,
Thank you for your replies. Service management is really more suitable to
put in the use case.
There are many kinds of constraint networks and devices, as well as many
kinds of existing protocols for network management. I am still not quite
clear about the management requirements. Maybe we should propose several use
cases of different kinds of networks. It is good to make clear about their
common requirements and individual requirements. 

Best wishes,
Yan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ersue, Mehmet (NSN - DE/Munich)
> Sent: Friday, June 29, 2012 5:15 PM
> To: Juergen Schoenwaelder; Yan Wang
> Cc: [email-masked]
> Subject: Re: [Coma] (no subject)
> 
> Hi Yan,
> 
> service management is a huge topic area and I assume we cannot cover it
> exhaustively. IMO service management should be discussed as part of the
use
> cases. Based on this we need to understand the requirements on the
> management of networks with constrained devices.
> 
> Cheers,
> Mehmet
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ext
> > Juergen Schoenwaelder
> > Sent: Thursday, June 28, 2012 5:19 PM
> > To: Yan Wang
> > Cc: [email-masked]
> > Subject: Re: [Coma] (no subject)
> >
> > On Thu, Jun 28, 2012 at 04:29:29PM +0800, Yan Wang wrote:
> >
> > > By the way,
> > > http://tools.ietf.org/html/draft-ietf-lwig-guidance-00#section-4.5
> mentioned
> > > development of a light-weight SNMP agent for resource constrained
> devices
> > > running the 6LoWPAN/RPL protocol stack.
> >
> > We have implemented an SNMP stack on Contiki and we have published
> > details about it. I think I only very partially agree with what is
> > written in this section 4.5. There is also an old expired I-D that
> > might be relevant: <draft-hamid-6lowpan-snmp-optimizations-03.txt>
> >
> > > What the relationship between coma and core, coma and lwig?
> >
> > My understanding is that CORE is specifying CoAP. CoAP may be used for
> > management but CORE is not chartered to specifically look at this
> > question. LWIG is looking at coming up with general guidelines for
> > light-weight implementations of IP protocols and hence might include
> > guidelines for implementing SNMP. COMA probably can take a broader
> > look at what is needed and in particular what the requirements driving
> > things are. There is also discussion on the netconf WG list related to
> > constrained devices, but it is as of now not chartered work.
> >
> > I assume COMA is an attempt to provide a common place to discuss the
> > management requirements and aspects of constrained networks and
> > devices instead of having discussions in several places.
> >
> > Of course, as Bert Wijnen kept saying, adding a protocol with the best
> > intentions to replace other protocols just leads at the end to one
> > more protocol. If that applies to discussion lists as well, then we
> > just have one more. ;-)
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> > Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
> > _______________________________________________
> > Coma mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/coma
> _______________________________________________
> Coma mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/coma

Content-class: urn:content-classes:message
Date: Fri, 29 Jun 2012 11:15:16 +0200
From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
To: "Juergen Schoenwaelder" <[email-masked]>, "Yan Wang" <[email-masked]>
Cc: [email-masked]
Subject: Re: [Coma] (no subject)

Hi Yan,

service management is a huge topic area and I assume we cannot cover it
exhaustively. IMO service management should be discussed as part of the
use cases. Based on this we need to understand the requirements on the
management of networks with constrained devices.

Cheers, 
Mehmet 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext
> Juergen Schoenwaelder
> Sent: Thursday, June 28, 2012 5:19 PM
> To: Yan Wang
> Cc: [email-masked]
> Subject: Re: [Coma] (no subject)
> 
> On Thu, Jun 28, 2012 at 04:29:29PM +0800, Yan Wang wrote:
> 
> > By the way,
> > http://tools.ietf.org/html/draft-ietf-lwig-guidance-00#section-4.5
mentioned
> > development of a light-weight SNMP agent for resource constrained
devices
> > running the 6LoWPAN/RPL protocol stack.
> 
> We have implemented an SNMP stack on Contiki and we have published
> details about it. I think I only very partially agree with what is
> written in this section 4.5. There is also an old expired I-D that
> might be relevant: <draft-hamid-6lowpan-snmp-optimizations-03.txt>
> 
> > What the relationship between coma and core, coma and lwig?
> 
> My understanding is that CORE is specifying CoAP. CoAP may be used for
> management but CORE is not chartered to specifically look at this
> question. LWIG is looking at coming up with general guidelines for
> light-weight implementations of IP protocols and hence might include
> guidelines for implementing SNMP. COMA probably can take a broader
> look at what is needed and in particular what the requirements driving
> things are. There is also discussion on the netconf WG list related to
> constrained devices, but it is as of now not chartered work.
> 
> I assume COMA is an attempt to provide a common place to discuss the
> management requirements and aspects of constrained networks and
> devices instead of having discussions in several places.
> 
> Of course, as Bert Wijnen kept saying, adding a protocol with the best
> intentions to replace other protocols just leads at the end to one
> more protocol. If that applies to discussion lists as well, then we
> just have one more. ;-)
> 
> /js
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
> _______________________________________________
> Coma mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/coma

Date: Thu, 28 Jun 2012 17:18:51 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Yan Wang <[email-masked]>
Mail-Followup-To: Yan Wang <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: Re: [Coma] (no subject)
Reply-To: Juergen Schoenwaelder <[email-masked]>

On Thu, Jun 28, 2012 at 04:29:29PM +0800, Yan Wang wrote:
 
> By the way,
> http://tools.ietf.org/html/draft-ietf-lwig-guidance-00#section-4.5 mentioned
> development of a light-weight SNMP agent for resource constrained devices
> running the 6LoWPAN/RPL protocol stack.

We have implemented an SNMP stack on Contiki and we have published
details about it. I think I only very partially agree with what is
written in this section 4.5. There is also an old expired I-D that
might be relevant: <draft-hamid-6lowpan-snmp-optimizations-03.txt>

> What the relationship between coma and core, coma and lwig?

My understanding is that CORE is specifying CoAP. CoAP may be used for
management but CORE is not chartered to specifically look at this
question. LWIG is looking at coming up with general guidelines for
light-weight implementations of IP protocols and hence might include
guidelines for implementing SNMP. COMA probably can take a broader
look at what is needed and in particular what the requirements driving
things are. There is also discussion on the netconf WG list related to
constrained devices, but it is as of now not chartered work.

I assume COMA is an attempt to provide a common place to discuss the
management requirements and aspects of constrained networks and
devices instead of having discussions in several places.

Of course, as Bert Wijnen kept saying, adding a protocol with the best
intentions to replace other protocols just leads at the end to one
more protocol. If that applies to discussion lists as well, then we
just have one more. ;-)

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

From: "Yan Wang" <[email-masked]>
To: <[email-masked]>
Date: Thu, 28 Jun 2012 16:29:29 +0800
Subject: [Coma]  (no subject)

This is a multi-part message in MIME format.

------=_NextPart_000_00B2_01CD554B.310C4BD0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi all

I just saw this mailing list and it seems valuable. I don't know whether
management of service in the constrained network is also inside the scope. 

By the way,
http://tools.ietf.org/html/draft-ietf-lwig-guidance-00#section-4.5 mentioned
development of a light-weight SNMP agent for resource constrained devices
running the 6LoWPAN/RPL protocol stack.

What the relationship between coma and core, coma and lwig?

Best wishes,

Yan

------=_NextPart_000_00B2_01CD554B.310C4BD0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:\5B8B\4F53;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"\@\5B8B\4F53";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	text-align:justify;
	text-justify:inter-ideograph;
	font-size:10.5pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"\7EAF\6587\672C Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:"Calibri","sans-serif";}
span.Char
	{mso-style-name:"\7EAF\6587\672C Char";
	mso-style-priority:99;
	mso-style-link:\7EAF\6587\672C;
	font-family:"Calibri","sans-serif";}
.MsoChpDefault
	{mso-style-type:export-only;}
/* Page Definitions */
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=ZH-CN link=blue vlink=purple style='text-justify-trim:punctuation'><div class=WordSection1><p class=MsoPlainText><span lang=EN-US>Hi all<o:p></o:p></span></p><p class=MsoPlainText><span lang=EN-US><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span lang=EN-US>I just saw this mailing list and it seems valuable. I don</span><span lang=EN-US style='font-family:"Courier New"'>&#8217;</span><span lang=EN-US>t know whether management of service in the constrained network is also inside the scope. <o:p></o:p></span></p><p class=MsoPlainText><span lang=EN-US>By the way, <a href="http://tools.ietf.org/html/draft-ietf-lwig-guidance-00#section-4.5">http://tools.ietf.org/html/draft-ietf-lwig-guidance-00#section-4.5</a> mentioned development of a light-weight SNMP agent for resource constrained devices running the 6LoWPAN/RPL protocol stack.<o:p></o:p></span></p><p class=MsoPlainText><span lang=EN-US>What the relationship between coma and core, coma and lwig?<o:p></o:p></span></p><p class=MsoPlainText><span lang=EN-US><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span lang=EN-US>Best wishes,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>Yan<o:p></o:p></span></p><p class=MsoPlainText><span lang=EN-US><o:p>&nbsp;</o:p></span></p></div></body></html>
------=_NextPart_000_00B2_01CD554B.310C4BD0--

From: Carsten Bormann <[email-masked]>
Date: Tue, 19 Jun 2012 12:21:58 +0200
To: [email-masked]
Subject: [Coma] One venue to discuss coma...

I'm not a big fan of CfP spam, but this might actually be a good (and timely) venue to meet up to work on some of this.

Grüße, Carsten

CALL FOR PAPERS

2nd MONAMI SmaRT Workshop

Workshop on Smart objects Resource managemenT

26 September 2012

Hamburg University of Technology, Germany

In the context of Future Networks, the term “smart objects” is used to refer to everyday objects of all kinds that are enhanced with computational intelligence and the capability to communicate with each other and with online services. They are essential elements of cyber-physical systems enabling multifaceted applications in fields such as logistics, smart buildings, intelligent transport, and smart city applications.

The MONAMI SmaRT Workshop is complementary to the main conference. The workshop will look into the opportunities that smart objects create for infrastructure and infrastructure-less networks and how new services can be deployed and managed. Smart objects incorporate monitoring and control functions and need to communicate with each other and with gateways. In many cases, communication is based on wireless sensor networks integrated with an object, such as parts of a building, logistic goods, vehicles or environmental sensors and actuators. In other cases, communication is based on a hybrid approach where part of the network is infrastructure-based and the rest is self-organized.

Managing such smart objects requires algorithms and approaches based, in part, on general concepts discussed in MONAMI. However, the workshop will go one step further and consider, in particular:

●      Energy-efficient, self-organized access and routing schemes for smart object systems

●      Testbeds and experimental evaluation of services based on smart objects

●      Service and application management platforms for a variety of applications, e.g. smart cities

●      Autonomic network monitoring and management for smart object networks

●      Future Internet Architectures with smart objects

Accepted papers of exceptional merit will be considered for inclusion in the ACM/Springer Mobile Networks and Applications (MONET) Special Issue on Smart Object Applications and Management.

Paper Submission

We encourage submissions of high-quality technical papers reporting original research that has not been previously published, and is not currently submitted for consideration elsewhere. Full Papers should not exceed 10 pages in the Springer Lecture Notes of ICST (LNICST) format. Full paper submission details are available at http://mon-ami.org/cfp_smart.shtml

All submitted papers will be peer-reviewed by at least three MONAMI TPC members, including a Workshop Chair, to ensure high quality and relevance to the topics of the workshop. All accepted papers will be published in the Springer LNICST series and then be included in major article indexing services.

Important Dates

Paper Submission Deadline:     15 July 2012 (firm deadline; no extensions will be given)

Notification of Acceptance:    15 August 2012

Camera Ready Deadline:         21 August 2012

Workshop Date:                 26 September 2012

Workshop Chairs

Maciej Mühleisen, Hamburg University of Technology, Germany
Bernd-Ludwig Wenning, Cork Institute of Technology, Ireland 

Steering Committee

Ramon Aguero, University of Cantabria, Spain
Carsten Bormann, Universität Bremen TZI, Germany
Kostas Pentikousis, Huawei Technologies, Germany
Dirk Pesch, Cork Institute of Technology, Ireland
Andreas Timm-Giel, Hamburg University of Technology, Germany

CFP at:

http://mon-ami.org/2012/media/uploads/MONAMISmaRT_2012.pdf

From: Ulrich Herberg <[email-masked]>
Date: Wed, 13 Jun 2012 15:56:40 -0700
To: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Cc: ext Johannes Gilger <[email-masked]>, "[email-masked]" <[email-masked]>, Cullen Jennings <[email-masked]>
Subject: Re: [Coma] If all you had was an LED ...

Hi,

On Jun 13, 2012, at 11:20, "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]> wrote:

> Hi Cullen, Johannes,
> [...]
> 
>> This also brings me to the question of how much this list
>> will touch into management of security, i.e. bootstrapping of security
>> associations, setting of access control rights, etc.
> 
> I think the management of security should be in our focus. Though what management of security covers is open for discussion.

Right. What I wonder is if the network topology and the kind of link layer have an influence, e.g., if keys for certain L2 are to be exchanged (or should we focus on layer 3+ only? But sometimes, they same keys could be used at multiple layers...). The topology may matter, e.g., in case of MANETs, since at the time of bootstrapping security credentials, routing may not be established (chicken/egg problem).

But in essence, managing security bootstrapping is interesting, and I believe in focus for this discussion.

Best
Ulrich

> 
> Cheers,
> Mehmet
> 
> 
> 
> _______________________________________________
> Coma mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/coma

Content-class: urn:content-classes:message
Date: Wed, 13 Jun 2012 19:50:41 +0200
From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
To: "ext Ulrich Herberg" <[email-masked]>, <[email-masked]>
Subject: Re: [Coma] Possible topics?

Hi Ulrich,

your comments and suggestions are valuable. See below for a few
comments.

> >> - Should we support a distributed approach or a enforce a
centralized
> >> NMS? (or support both modes of operation?)
> >
> > Based on the size and type of the network both approaches could make
> > sense.
> 
> I also think this is reasonable. A distributed approach is, of course,
> much more difficult to do right, but would be very interesting in
> cases where no single NMS is part of the network architecture. In
> order to generalize this requirement, it seems to me that there could
> be a discussion about different use cases, scenarios and topologies
> for management. In the SNMP world, that is somewhat simpler
> (client/server).

I think we should list the relevant topologies, use cases and scenarios
for management first. Deriving the requirements would be than more easy.
 
> >
> >> - Which transport protocols do we want to use? TCP/UDP or something
> > like COAP?
> >
> > As Benoit stated we are talking on requirements and not on
solutions;
> > especially we will not propose to use a specific protocol or
solution.
> 
> Right, that is certainly a good idea to start with requirements first.
> So, let me have another try:
> - A requirement is that a management protocol for constrained devices
> supports light-weight transport protocols, both in terms of code
> complexity and suitability for constrained channels.
> In LLNs and MANETs, TCP is known to not perform well, which was one of
> the reasons to develop COAP. (I assume that other types of networks
> are also in scope for this discussion, but nevertheless, we may want
> to discuss requirements of the transport layer).

Yes, Manet-like networks are also in scope for this discussion. Power
and bandwidth consumption are important criteria in a network of
constrained devices. These criteria has implications on the efficiency
of the transport layer.
 
> >
> >> - Do we need efficient, reliable multicast (like NORM, but
> >> lightweight) to distribute control traffic more efficiently?
> 
> Let me elaborate on this one a bit more. Let's assume that a network
> operator wants to set a parameter on 10 routers at the same time. One
> could of course establish 10 unicast connections to each router and
> set the parameter. But (in particular with regards to inefficiency of
> TCP in mesh networks), that may not be feasible. For monitoring
> performance or state of a larger number of networks, multicast could
> also be useful. I am not sure if multicast operations should be
> reliable, but in some scenarios that may be required.

Multicast is an essential mechanism e.g. in M2M scenarios. Let's discuss
it further whether a reliable multicast should be a requirement.
 
> >> - Can we provide sufficient levels of security without putting too
> >> much burden on constrained devices? Which authentication modes do
we
> >> need?
> 
> I think that security will be a major point in this discussion. The
> problem with security is that it always comes at a cost (code
> complexity, CPU resource requirements for de-/encryption, memory
> requirements, message overhead). If we have a classification of
> devices with regards to their resources, maybe we should have some
> conformance requirements for security in each device class? (e.g.,
> "class 0 devices MUST support <low-level-of-security>, class devices 1
> MUST in addition support <higher-level-of-security>, ...").

Agree, we need such a classification at least as a hint on what is
possible to integrate into the device. E.g. SSH might not be possible
because of the code size. DTLS is more compact.

> >> - Should there be a proxy functionality like RMON (or something
like
> >> the currently developed REPORT-MIB in MANET), in order to record
> >> performance related values locally and then send to a NMS later?
> 
> The REPORT-MIB is currently under development in the MANET group. The
> idea was essentially that we want to collect performance related (or
> other kinds of) information on a router over time, and then return it
> to a management station for evaluation, without the need to
> periodically poll the router. It is a tradeoff between storing such
> information on the (constrained) device, or having a more frequent
> message exchange.

And a frequent message exchange results to more energy consumption,
which is bad. We might need a light version of energy monitoring which
could result to a dynamic definition of the message exchange frequency.
 
> >> - Will there be a mapping to existing management protocols like
SNMP
> >> for border gateways?
> 
> I think that this would be extremely important. Since SNMP and NETCONF
> are already widely used, some kind of mapping would allow
> compatibility and end-to-end information exchange. Of course, it would
> be some work to create such mappings. It could also be challenging
> with regards to (end-to-end) security.

Excellent point. The optimal case would be if the mapping is pretty easy
like between HTTP and CoAP. If the constrained device uses any light
version of the protocol which is already in use in the core network this
would be perfect. However, it is not that easy to use a reduced version
of SNMP or Netconf together with the application logic etc. in one
C1-device with little memory.

> >> - Is there any assumption for this work about the reliability of
the
> >> channel, the kind of the link layer (e.g., wireless/wired),
mobility
> >> etc? Or is the only assumption that the devices are "constrained"
(in
> >> terms of memory? CPU? network connection?)
> 
> I believe this is important for several of the above mentioned issues
> (e.g., requirements for transport protocols, limitations for security
> overhead on messages etc). I suggest that before we dig into all the
> requirements, we need to get a clear idea which kinds of networks and
> devices we want to consider, and what "constrained" means (the latter
> is already discussed in some of the other email threads).

This is exactly what we should do as a first step.
 
> > Good questions. It would be helpful if you could start a discussion
by
> > stating why you think these should be requirements on constrained
> > networks.
> 
> I hope that helped to make this (certainly non-exhaustive) list
> clearer. I suggest that we first come up with more requirements,
> filter out those we believe are interesting and then classify them
> into different topics. If some of the mailing list participants find a
> few of the above listed items interesting, I could move (some of) them
> into a separate email thread each for making it easier to read.
> 
> I have not followed the mailing list since the very beginning, but is
> the intention to consider having a BOF later on? I think that would be
> a good idea.

It is too early to think on a BoF. Let's do a gap analysis at the end
and point to new work. Let's see how much work is necessary to do and
where it belongs to. I assume the rest will be then discussed in
OPS-DIR, Core WG or a Bar BoF. As you know IETF does only work which can
be defined concretely and happens soon. If we don't know how to do it,
it belongs to IRTF or somewhere else.
  
> Best
> Ulrich

Cheers,
Mehmet

Content-class: urn:content-classes:message
Date: Wed, 13 Jun 2012 20:20:34 +0200
From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
To: "ext Johannes Gilger" <[email-masked]>, "Cullen Jennings" <[email-masked]>
Cc: [email-masked]
Subject: Re: [Coma] If all you had was an LED ...

Date: Fri, 8 Jun 2012 14:30:57 -0700
From: Ulrich Herberg <[email-masked]>
To: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [Coma] Possible topics?

Hi Mehmet,

please see my answer inline.

On Fri, Jun 8, 2012 at 4:27 AM, Ersue, Mehmet (NSN - DE/Munich)
<[email-masked]> wrote:
> Hi Ulrich,
>
>> I just discovered this mailing list. Some aspects I have in mind about
>> the topic of managing constrained devices and networks:
>>
>> - Do we actually manage single devices or whole networks (or groups of
>> devices)? At least in MANETs, it may be of equal interest to monitor
>> (and manage) the performance of a whole network, rather than just a
>> single router.
>
> Our aim is to look also at constrained networks and groups of devices.

That is good, and I think very important. My background is in MANETs
and LLNs, where I think such a thing is missing but very important.
IMO, it would be very valuable to both monitor and manage whole
networks. Two examples could be:
  - Change a router parameter for several routers at the same time
(instead of multiple unicast connections
  - Acquire state or (performance-related) statistics from a group of
routers. E.g., in MANETs, the information from a single router may not
give enough information about bottlenecks, inefficiencies etc. of the
whole network.

>
>> - Should we support a distributed approach or a enforce a centralized
>> NMS? (or support both modes of operation?)
>
> Based on the size and type of the network both approaches could make
> sense.

I also think this is reasonable. A distributed approach is, of course,
much more difficult to do right, but would be very interesting in
cases where no single NMS is part of the network architecture. In
order to generalize this requirement, it seems to me that there could
be a discussion about different use cases, scenarios and topologies
for management. In the SNMP world, that is somewhat simpler
(client/server).

>
>> - Which transport protocols do we want to use? TCP/UDP or something
> like COAP?
>
> As Benoit stated we are talking on requirements and not on solutions;
> especially we will not propose to use a specific protocol or solution.

Right, that is certainly a good idea to start with requirements first.
So, let me have another try:
- A requirement is that a management protocol for constrained devices
supports light-weight transport protocols, both in terms of code
complexity and suitability for constrained channels.
In LLNs and MANETs, TCP is known to not perform well, which was one of
the reasons to develop COAP. (I assume that other types of networks
are also in scope for this discussion, but nevertheless, we may want
to discuss requirements of the transport layer).

>
>> - Do we need efficient, reliable multicast (like NORM, but
>> lightweight) to distribute control traffic more efficiently?

Let me elaborate on this one a bit more. Let's assume that a network
operator wants to set a parameter on 10 routers at the same time. One
could of course establish 10 unicast connections to each router and
set the parameter. But (in particular with regards to inefficiency of
TCP in mesh networks), that may not be feasible. For monitoring
performance or state of a larger number of networks, multicast could
also be useful. I am not sure if multicast operations should be
reliable, but in some scenarios that may be required.

>> - Can we provide sufficient levels of security without putting too
>> much burden on constrained devices? Which authentication modes do we
>> need?

I think that security will be a major point in this discussion. The
problem with security is that it always comes at a cost (code
complexity, CPU resource requirements for de-/encryption, memory
requirements, message overhead). If we have a classification of
devices with regards to their resources, maybe we should have some
conformance requirements for security in each device class? (e.g.,
"class 0 devices MUST support <low-level-of-security>, class devices 1
MUST in addition support <higher-level-of-security>, ...").

>> - Should there be a proxy functionality like RMON (or something like
>> the currently developed REPORT-MIB in MANET), in order to record
>> performance related values locally and then send to a NMS later?

The REPORT-MIB is currently under development in the MANET group. The
idea was essentially that we want to collect performance related (or
other kinds of) information on a router over time, and then return it
to a management station for evaluation, without the need to
periodically poll the router. It is a tradeoff between storing such
information on the (constrained) device, or having a more frequent
message exchange.

>> - Will there be a mapping to existing management protocols like SNMP
>> for border gateways?

I think that this would be extremely important. Since SNMP and NETCONF
are already widely used, some kind of mapping would allow
compatibility and end-to-end information exchange. Of course, it would
be some work to create such mappings. It could also be challenging
with regards to (end-to-end) security.

>> - Is there any assumption for this work about the reliability of the
>> channel, the kind of the link layer (e.g., wireless/wired), mobility
>> etc? Or is the only assumption that the devices are "constrained" (in
>> terms of memory? CPU? network connection?)

I believe this is important for several of the above mentioned issues
(e.g., requirements for transport protocols, limitations for security
overhead on messages etc). I suggest that before we dig into all the
requirements, we need to get a clear idea which kinds of networks and
devices we want to consider, and what "constrained" means (the latter
is already discussed in some of the other email threads).

> Good questions. It would be helpful if you could start a discussion by
> stating why you think these should be requirements on constrained
> networks.

I hope that helped to make this (certainly non-exhaustive) list
clearer. I suggest that we first come up with more requirements,
filter out those we believe are interesting and then classify them
into different topics. If some of the mailing list participants find a
few of the above listed items interesting, I could move (some of) them
into a separate email thread each for making it easier to read.

I have not followed the mailing list since the very beginning, but is
the intention to consider having a BOF later on? I think that would be
a good idea.

Best
Ulrich

Content-class: urn:content-classes:message
Date: Fri, 8 Jun 2012 15:02:06 +0200
From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: [Coma] Reprogramming Protocols

This is a multi-part message in MIME format.

------_=_NextPart_001_01CD4576.E839B4DF
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Jonathan,

this could be seen under the SW/firmware distribution, however
reprogramming protocol code is a device specific logic and not a
management task.

Cheers, 
Mehmet 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext [email-masked]
Sent: Friday, June 08, 2012 2:38 PM
To: [email-masked]
Subject: [Coma] Reprogramming Protocols

Hi,

One thing that hasn't yet been mentioned (unless I missed it) is the
issue or reprogramming protocols for adding new applications or
modifying/patching existing applications/firmware. I imagine this is of
particular interest in Sensor Nets but may also be beneficial in other
scenarios. Will this also be considered within coma?

Thanks,

Jonathan

________________________________

This email and any files attached are intended for the addressee and may
contain information of a confidential nature. If you are not the
intended recipient, be aware that this email was sent to you in error
and you should not disclose, distribute, print, copy or make other use
of this email or its attachments. Such actions, in fact, may be
unlawful. In compliance with the various Regulations and Acts, General
Dynamics United Kingdom Limited reserves the right to monitor (and
examine for viruses) all emails and email attachments, both inbound and
outbound. Email communications and their attachments may not be secure
or error- or virus-free and the company does not accept liability or
responsibility for such matters or the consequences thereof. General
Dynamics United Kingdom Limited, Registered Office: 21 Holborn Viaduct,
London EC1A 2DY. Registered in England and Wales No: 1911653. 

------_=_NextPart_001_01CD4576.E839B4DF
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Verdana;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:"Arial","sans-serif";
	color:windowtext;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Verdana","sans-serif";
	color:blue;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:blue'>Hi Jonathan,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:blue'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:blue'>this could be seen under the SW/firmware distribution, however reprogramming protocol code is a device specific logic and not a management task.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:blue'><o:p>&nbsp;</o:p></span></p><div><p class=MsoNormal><span lang=DE style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:blue'>Cheers,</span><span lang=DE style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:blue'> <br></span><span lang=DE style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:blue'>Mehmet</span><span lang=DE style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:blue'> <o:p></o:p></span></p></div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:blue'><o:p>&nbsp;</o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> [email-masked] [mailto:[email-masked]] <b>On Behalf Of </b>ext [email-masked]<br><b>Sent:</b> Friday, June 08, 2012 2:38 PM<br><b>To:</b> [email-masked]<br><b>Subject:</b> [Coma] Reprogramming Protocols<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal><span lang=EN-GB style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Hi,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB style='font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span lang=EN-GB style='font-size:10.0pt;font-family:"Arial","sans-serif"'>One thing that hasn&#8217;t yet been mentioned (unless I missed it) is the issue or reprogramming protocols for adding new applications or modifying/patching existing applications/firmware. I imagine this is of particular interest in Sensor Nets but may also be beneficial in other scenarios. Will this also be considered within coma?<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB style='font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span lang=EN-GB style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Thanks,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB style='font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span lang=EN-GB style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Jonathan</span><span lang=EN-GB><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p>&nbsp;</o:p></span></p><div><div class=MsoNormal align=center style='text-align:center'><span lang=EN-GB><hr size=2 width="100%" align=center></span></div><p class=MsoNormal><span lang=EN-GB>This email and any files attached are intended for the addressee and may contain information of a confidential nature. If you are not the intended recipient, be aware that this email was sent to you in error and you should not disclose, distribute, print, copy or make other use of this email or its attachments. Such actions, in fact, may be unlawful. In compliance with the various Regulations and Acts, General Dynamics United Kingdom Limited reserves the right to monitor (and examine for viruses) all emails and email attachments, both inbound and outbound. Email communications and their attachments may not be secure or error- or virus-free and the company does not accept liability or responsibility for such matters or the consequences thereof. General Dynamics United Kingdom Limited, Registered Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and Wales No: 1911653. <o:p></o:p></span></p></div></div></div></body></html>
------_=_NextPart_001_01CD4576.E839B4DF--

Content-class: urn:content-classes:message
Date: Fri, 8 Jun 2012 13:38:18 +0100
From: <[email-masked]>
To: <[email-masked]>
Subject: [Coma] Reprogramming Protocols

This is a multi-part message in MIME format.

------_=_NextPart_001_01CD4573.955D1909
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-NAIMIME-Disclaimer: 1
X-NAIMIME-Modified: 1

Hi,

One thing that hasn't yet been mentioned (unless I missed it) is the
issue or reprogramming protocols for adding new applications or
modifying/patching existing applications/firmware. I imagine this is of
particular interest in Sensor Nets but may also be beneficial in other
scenarios. Will this also be considered within coma?

Thanks,

Jonathan

This email and any files attached are intended for the addressee and may contain information of a confidential nature. If you are not the intended recipient, be aware that this email was sent to you in error and you should not disclose, distribute, print, copy or make other use of this email or its attachments. Such actions, in fact, may be unlawful. In compliance with the various Regulations and Acts, General Dynamics United Kingdom Limited reserves the right to monitor (and examine for viruses) all emails and email attachments, both inbound and outbound. Email communications and their attachments may not be secure or error- or virus-free and the company does not accept liability or responsibility for such matters or the consequences thereof. General Dynamics United Kingdom Limited, Registered Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and Wales No: 1911653. 

------_=_NextPart_001_01CD4573.955D1909
Content-Type: text/HTML;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-NAIMIME-Disclaimer: 1
X-NAIMIME-Modified: 1

<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle19
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=EN-GB link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Hi,<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>One thing that hasn&#8217;t yet been mentioned (unless I
missed it) is the issue or reprogramming protocols for adding new applications or
modifying/patching existing applications/firmware. I imagine this is of particular
interest in Sensor Nets but may also be beneficial in other scenarios. Will
this also be considered within coma?<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Thanks,<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Jonathan</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

<DIV><P><HR>
This email and any files attached are intended for the addressee and may contain information of a confidential nature. If you are not the intended recipient, be aware that this email was sent to you in error and you should not disclose, distribute, print, copy or make other use of this email or its attachments. Such actions, in fact, may be unlawful. In compliance with the various Regulations and Acts, General Dynamics United Kingdom Limited reserves the right to monitor (and examine for viruses) all emails and email attachments, both inbound and outbound. Email communications and their attachments may not be secure or error- or virus-free and the company does not accept liability or responsibility for such matters or the consequences thereof. General Dynamics United Kingdom Limited, Registered Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and Wales No: 1911653. 
</P></DIV>
</body>

</html>

------_=_NextPart_001_01CD4573.955D1909--

Content-class: urn:content-classes:message
Date: Fri, 8 Jun 2012 13:28:20 +0200
From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
To: "ext Rares Ivan" <[email-masked]>, <[email-masked]>
Subject: Re: [Coma] Constrained Device Classes 0, 1 and 2 and their need for Management

Hi Rares,

> Hello,
> 
> In my opinion the classification should not be directly connected to
the hardware
> capabilities of devices (like processing power, RAM, flash) just
because same functional
> features can be supported on devices with very different hardware
capabilities and
> architecture. There shouldn't be any mention of hardware resources.

We are interested to know which applications and features are possible
to run on different devices. However, the type of the application you
can run on a device is dependent on the available hardware capabilities.
So the device classes are used as a tool and will help us as a means to
an end. 
 
> The classification shall be based on various sets of features
supported by a device.
> Therefore the complete list of features can be divided in subsets
where Class-0 (C0) is
> the smallest set of supported features, Class-1 (C1) adds more
features on top of C0,
> Class-2 (C2) adds more features on top of C1, and so on. A Class-2
device is implicitly

I assume you mean "possible" features. E.g. based on the constrained
nature of resources, a device may support only a few of the features
(classified as C1) at a time.

> compliant with Class-1 and Class-0, therefore a network manager that
can manage
> Class-2 can also manage the lower classes; a manager that can only
manage Class-1
> devices could only manage Class-2 devices based on features specific
to Class-1, which
> is the manager's limitation.
> 
> The higher the class, the more features a device supports, and based
on this
> classification a manager would know what the capabilities of a device
shall be. There
> wouldn't be any in-between classes specs allowed, and a device cannot
be claimed as
> Class-2 compliant unless it supports ALL the features required by that
category.

Cheers,
Mehmet
 
> Regards,
>   Rares
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of Juergen
> Schoenwaelder
> Sent: Wednesday, June 06, 2012 5:22 AM
> To: Ersue, Mehmet (NSN - DE/Munich)
> Cc: [email-masked]
> Subject: Re: [Coma] Constrained Device Classes 0, 1 and 2 and their
need for
> Management
> 
> On Wed, Jun 06, 2012 at 10:42:13AM +0200, Ersue, Mehmet (NSN -
DE/Munich)
> wrote:
> > Hi All,
> >
> > following is an attempt to define the device classes in constrained
> > networks a bit more in detail. The text below follows the definition
> > of the three device classes provided by Carsten.
> >
> > Class-0 (C0) devices are very constrained sensor-like motes. They
will
> > most likely not have the possibility to have a direct communications
> > with the Internet in a secure manner. These class-0 devices will
> > participate in Internet communications with the help of larger
devices
> > acting as proxy or gateways.
> >
> > Class-1 (C1) devices are assumed to have about 10 Kbytes of RAM and
> > roughly 100 Kbytes of code space (e.g. Flash). For example, this
could
> > be an AVR Raven mote (http://www.atmel.com/tools/AVRRAVEN.aspx).
> > Class-1 devices can't easily talk to other Internet nodes with a
full
> > protocol stack using HTTP, TLS and related security protocols, and
> > XML-based data representations. However, they have enough power to
use
> > a reduced or lightweight protocol stack (e.g. with CoAP and UDP) and
> > participate in meaningful conversations without the help of a
gateway
> > node. So they can be integrated into the IoT network in one way or
the
> > other but need to spare with memory for the protocol and application
usage.
> >
> > Class-2 (C2) devices are embedded devices with around 50 Kbytes of
RAM
> > and maybe 250 Kbytes of code space and can support mostly the same
> > protocol stack as used on notebooks or servers. However, even these
> > devices can benefit from lightweight and energy-efficient protocols
> > and producing less bandwidth on air. Furthermore, using less network
> > resources would leave more resources available to applications. As
> > such using the same protocol stack on Class 1 and 2 devices might be
> > beneficial.
> >
> > I assume we cannot do much for the management on C0 devices. They
will
> > be most likely preconfigured and if ever will be reconfigured
seldomly
> > with a very small data set.
> >
> > For C1 devices it is indeed subject for discussion and to understand
> > what type of applications they could run and which management
> > mechanisms would be most suitable.
> > Even though they have some more functionality available we need to
> > assess C2 devices for the type of applications they will be running
> > and the management they would need. To be able to derive the
> > requirements we need to discuss the uses cases and how the devices
are
> > involved in the management scenario. The use cases where C1 or C2
> > devices build a cluster or are part of a hierarchy as well as the
> > assumed degree of automation might be essentially important.
> >
> > Comments are welcome.
> 
> This classification is very rough since devices differ in their
architecture. For example,
> some devices can run their software right out of flash memory and
hence their RAM is
> really only used for the storage of variables and the stack. Other
devices have to copy
> the machine code from flash to RAM before they can execute it. Such
devices have
> relatively large amounts of RAM but most of it is used to store
machine code.
> 
> /js
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
> _______________________________________________
> Coma mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/coma
> _______________________________________________
> Coma mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/coma

Content-class: urn:content-classes:message
Date: Fri, 8 Jun 2012 13:27:07 +0200
From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
To: "ext Ulrich Herberg" <[email-masked]>, <[email-masked]>
Subject: Re: [Coma] Possible topics?

Hi Ulrich,

> I just discovered this mailing list. Some aspects I have in mind about
> the topic of managing constrained devices and networks:
> 
> - Do we actually manage single devices or whole networks (or groups of
> devices)? At least in MANETs, it may be of equal interest to monitor
> (and manage) the performance of a whole network, rather than just a
> single router.

Our aim is to look also at constrained networks and groups of devices.

> - Should we support a distributed approach or a enforce a centralized
> NMS? (or support both modes of operation?)

Based on the size and type of the network both approaches could make
sense.

> - Which transport protocols do we want to use? TCP/UDP or something
like COAP?

As Benoit stated we are talking on requirements and not on solutions;
especially we will not propose to use a specific protocol or solution.

> - Do we need efficient, reliable multicast (like NORM, but
> lightweight) to distribute control traffic more efficiently?
> - Can we provide sufficient levels of security without putting too
> much burden on constrained devices? Which authentication modes do we
> need?
> - Should there be a proxy functionality like RMON (or something like
> the currently developed REPORT-MIB in MANET), in order to record
> performance related values locally and then send to a NMS later?
> - Will there be a mapping to existing management protocols like SNMP
> for border gateways?
> - Is there any assumption for this work about the reliability of the
> channel, the kind of the link layer (e.g., wireless/wired), mobility
> etc? Or is the only assumption that the devices are "constrained" (in
> terms of memory? CPU? network connection?)

Good questions. It would be helpful if you could start a discussion by
stating why you think these should be requirements on constrained
networks.

> Best
> Ulrich

Cheers,
Mehmet
  
> 
> 
> [Coma] Subject: New Non-WG Mailing List: coma -- Management of
> Constrained Networks and Devices
> 
>     From: IETF Secretariat <ietf-secretariat at ietf.org>
>     To: IETF Announcement List <ietf-announce at ietf.org>
>     Cc: bclaise at cisco.com, coma at ietf.org
>     Date: Wed, 16 May 2012 10:39:36 -0700
>     List-id: Management of Constrained Networks and Devices
<coma.ietf.org>
> 
> A new IETF non-working group email list has been created.
> 
> List address: coma at ietf.org
> Archive:  http://www.ietf.org/mail-archive/web/coma/
> To subscribe:  https://www.ietf.org/mailman/listinfo/coma
> 
> Purpose: This list is for the discussion related to the management of
> constrained networks and devices. The IETF so far has not developed
> specific technologies for the management of constrained networks.
> There is a need to
> understand the requirements for the management of such a constrained
> network and its devices.
> 
> For additional information, please contact the list administrators.
> _______________________________________________
> Coma mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/coma

Content-class: urn:content-classes:message
Date: Fri, 8 Jun 2012 13:06:49 +0200
From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: [Coma] (no subject)

This is a multi-part message in MIME format.

------_=_NextPart_001_01CD4566.CD9E6095
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear Tayeb,

your contribution as an operator is very valuable.

I agree we should look at the business needs and requirements. I would
appreciate it if you could provide some text on this.

Let's see how the document evolves and whether we can plan a gap
analysis already for the first release.

Cheers, 
Mehmet 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext [email-masked]
Sent: Wednesday, June 06, 2012 10:05 PM
To: [email-masked]
Subject: [Coma] (no subject)

Dear all,

It's an excellent idea to investigate this domain. From my perspective,
the first requirements related to the management aspect of such devices
in their particular environment are auto-configuration which is
addressed by design. When it comes to standardization for sure there is
some work to do accordingly.

Within operator's environment, could be Fixed or Mobile networks, the
Home Gateway and its attached devices, BBF protocol TR-69 is adopted and
used for managing (configuration) of HomeNodeB and HomeeNodeBs. Netconf
and its associated modeling language Yang have reached a maturity and
are implemented in vendors' solutions. Some extensions are considered in
order to address management aspects beyond simple configuration. 

The requirements and associated solutions should be business driven, and
then we address the technical solutions. That means, we should look at
the vertical market needs (Health, Digital Home, ...) in terms of
expectation of SLAs. Then the question is how to translate these SLAs
into SLOs, metrics and how to track, measure, collect and report them
(the needed management models and tools) in order to meet the SLAs.

The question related to the management is 3-fold:

- Which protocol: should we adapt the existing ones (TR-69, Netconf, )
to this constrained devices and network, or should designnew ones as
IETF did for routing protocols.

- Which interface:  We should not re-invente the wheel

- Which Data model:  We should not re-invente the wheel. 

So, this first draft should contain at least the following sections

-    Problem statement

-    Business needs and requirements

-    Technical requirements

-    Gap analysis: missing pieces to be covered by IETF and other SDOs

-    New topics to be investigated

 

Regards

Tayeb

 

________________________________________________________________________
_________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete
altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for
messages that have been modified, changed or falsified.
Thank you.

------_=_NextPart_001_01CD4566.CD9E6095
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Verdana;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Consolas;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:Consolas;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
span.TextebrutCar
	{mso-style-name:"Texte brut Car";
	mso-style-priority:99;
	mso-style-link:"Texte brut";
	font-family:Consolas;}
p.Textebrut, li.Textebrut, div.Textebrut
	{mso-style-name:"Texte brut";
	mso-style-link:"Texte brut Car";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.EmailStyle23
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle24
	{mso-style-type:personal-reply;
	font-family:"Verdana","sans-serif";
	color:blue;}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:914048466;
	mso-list-type:hybrid;
	mso-list-template-ids:-1438196870 1601317376 67895299 67895301 67895297 67895299 67895301 67895297 67895299 67895301;}
@list l0:level1
	{mso-level-start-at:0;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Consolas;
	mso-fareast-font-family:SimSun;
	mso-bidi-font-family:Arial;}
@list l0:level2
	{mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level3
	{mso-level-tab-stop:108.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level4
	{mso-level-tab-stop:144.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level5
	{mso-level-tab-stop:180.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level6
	{mso-level-tab-stop:216.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level7
	{mso-level-tab-stop:252.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level8
	{mso-level-tab-stop:288.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level9
	{mso-level-tab-stop:324.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:blue'>Dear Tayeb,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:blue'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:blue'>your contribution as an operator is very valuable.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:blue'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:blue'>I agree we should look at the business needs and requirements. I would appreciate it if you could provide some text on this.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:blue'>Let&#8217;s see how the document evolves and whether we can plan a gap analysis already for the first release.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:blue'><o:p>&nbsp;</o:p></span></p><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:blue'>Cheers,</span><span style='color:blue'> <br></span><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:blue'>Mehmet</span><span style='color:blue'> <o:p></o:p></span></p></div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:blue'><o:p>&nbsp;</o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> <a href="mailto:[email-masked]">[email-masked]</a> [<a href="mailto:[email-masked]">mailto:[email-masked]</a>] <b>On Behalf Of </b>ext <a href="mailto:[email-masked]">[email-masked]</a><br><b>Sent:</b> Wednesday, June 06, 2012 10:05 PM<br><b>To:</b> <a href="mailto:[email-masked]">[email-masked]</a><br><b>Subject:</b> [Coma] (no subject)<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal><span lang=FR>Dear all,<o:p></o:p></span></p><p class=MsoNormal><span lang=FR><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText>It&#8217;s an excellent idea to investigate this domain. From my perspective, the first requirements related to the management aspect of such devices in their particular environment are auto-configuration which is addressed by design. When it comes to standardization for sure there is some work to do accordingly.<o:p></o:p></p><p class=MsoPlainText><o:p>&nbsp;</o:p></p><p class=MsoPlainText>Within operator's environment, could be Fixed or Mobile networks, the Home Gateway and its attached devices, BBF protocol TR-69 is adopted and used for managing (configuration) of HomeNodeB and HomeeNodeBs. Netconf and its associated modeling language Yang have reached a maturity and are implemented in vendors' solutions. Some extensions are considered in order to address management aspects beyond simple configuration. <o:p></o:p></p><p class=MsoPlainText><o:p>&nbsp;</o:p></p><p class=MsoPlainText>The requirements and associated solutions should be business driven, and then we address the technical solutions. That means, we should look at the vertical market needs (Health, Digital Home, ...) in terms of expectation of SLAs. Then the question is how to translate these SLAs into SLOs, metrics and how to track, measure, collect and report them (the needed management models and tools) in order to meet the SLAs.<o:p></o:p></p><p class=MsoPlainText><o:p>&nbsp;</o:p></p><p class=MsoPlainText>The question related to the management is 3-fold:<o:p></o:p></p><p class=MsoPlainText>- Which protocol: should we adapt the existing ones (TR-69, Netconf, ) to this constrained devices and network, or should designnew ones as IETF did for routing protocols.<o:p></o:p></p><p class=MsoPlainText>- Which interface: &nbsp;We should not re-invente the wheel<o:p></o:p></p><p class=MsoPlainText>- Which Data model: &nbsp;We should not re-invente the wheel. <o:p></o:p></p><p class=MsoPlainText><o:p>&nbsp;</o:p></p><p class=MsoPlainText>So, this first draft should contain at least the following sections<o:p></o:p></p><p class=MsoPlainText style='margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp; </span></span><![endif]>Problem statement<o:p></o:p></p><p class=MsoPlainText style='margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp; </span></span><![endif]>Business needs and requirements<o:p></o:p></p><p class=MsoPlainText style='margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp; </span></span><![endif]>Technical requirements<o:p></o:p></p><p class=MsoPlainText style='margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp; </span></span><![endif]>Gap analysis: missing pieces to be covered by IETF and other SDOs<o:p></o:p></p><p class=MsoPlainText style='margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp; </span></span><![endif]>New topics to be investigated<o:p></o:p></p><p class=MsoPlainText style='margin-left:36.0pt'><o:p>&nbsp;</o:p></p><p class=MsoPlainText><o:p>&nbsp;</o:p></p><p class=MsoPlainText>Regards<o:p></o:p></p><p class=MsoPlainText><o:p>&nbsp;</o:p></p><p class=MsoPlainText>Tayeb<o:p></o:p></p><p class=MsoPlainText><o:p>&nbsp;</o:p></p><p class=MsoNormal><o:p>&nbsp;</o:p></p><pre><span lang=FR>_________________________________________________________________________________________________________________________<o:p></o:p></span></pre><pre><span lang=FR><o:p>&nbsp;</o:p></span></pre><pre><span lang=FR>Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc<o:p></o:p></span></pre><pre><span lang=FR>pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler<o:p></o:p></span></pre><pre><span lang=FR>a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,<o:p></o:p></span></pre><pre><span lang=FR>France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.<o:p></o:p></span></pre><pre><span lang=FR><o:p>&nbsp;</o:p></span></pre><pre><span lang=FR>This message and its attachments may contain confidential or privileged information that may be protected by law;<o:p></o:p></span></pre><pre><span lang=FR>they should not be distributed, used or copied without authorisation.<o:p></o:p></span></pre><pre><span lang=FR>If you have received this email in error, please notify the sender and delete this message and its attachments.<o:p></o:p></span></pre><pre><span lang=FR>As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.<o:p></o:p></span></pre><pre><span lang=FR>Thank you.<o:p></o:p></span></pre></div></div></body></html>
------_=_NextPart_001_01CD4566.CD9E6095--

Date: Fri, 8 Jun 2012 09:26:25 +0200
From: Johannes Gilger <[email-masked]>
To: Cullen Jennings <[email-masked]>
Cc: [email-masked]
Subject: Re: [Coma] If all you had was an LED ...

Hi list,

On 07/06/12 11:40, Cullen Jennings wrote:
> How would you use these 1 or two LEDs to help manage the device? 
>
> It would be possible to send a small message as a burst of rapidly
> changing light patterns that was detectable by the video camera on a
> smart phone. Would it make sense to use this for something like POST
> codes on PCs? 
> 
> What are the various states that an operator would want to be able to
> see? I'm assuming this is mostly states that are important when one
> can't get networked base management. 
> 
> Thoughts? Pointers to what existing systems do ?

I'm also interested about this (or very similar) out-of-band channels in
real-world applications. Using the LED OOB-channel could prove to be a
reliable way to manage the devices, and maybe even to exchange security
parameters. If there was a protocol, it would help in exchanging
different kinds of information (short POST-like codes vs. whole
shared/asymmetric keys) over the air.

This also brings me to the question of how much this list
will touch into management of security, i.e. bootstrapping of security
associations, setting of access control rights, etc.

Regards,
Johannes

-- 
Dipl.-Inform. Johannes Gilger
Research Group IT-Security
UMIC Research Centre
RWTH Aachen University
Mies-van-der-Rohe-Straße 15
52074 Aachen

Office: 211
Phone: +49 241 80 20781
Fax:   +49 241 80 22731

http://itsec.rwth-aachen.de

From: Cullen Jennings <[email-masked]>
Date: Thu, 7 Jun 2012 11:40:12 -0700
To: [email-masked]
Subject: [Coma] If all you had was an LED ...

Imagine an sensor devices that is very cheap and connects to the network. Lets say the only UI the device has a single LED, or perhaps a red and green LED. 

How would you use these 1 or two LEDs to help manage the device? 

Lots of existing stuff blinks them in various ways to indicate different states of the network (no carrier, connected but no IP, etc). Would it make sense to have some standardized recommendation about this? 

It would be possible to send a small message as a burst of rapidly changing light patterns that was detectable by the video camera on a smart phone. Would it make sense to use this for something like POST codes on PCs? 

What are the various states that an operator would want to be able to see? I'm assuming this is mostly states that are important when one can't get networked base management. 

Thoughts? Pointers to what existing systems do ?

Thanks, Cullen

From: "Randy Presuhn" <[email-masked]>
To: <[email-masked]>
Date: Thu, 7 Jun 2012 15:01:52 -0700
Subject: Re: [Coma] Management of Constrained Networks and Devices

Hi -

> From: <[email-masked]>
> To: <[email-masked]>
> Sent: Thursday, June 07, 2012 8:00 AM
> Subject: [Coma] Management of Constrained Networks and Devices
...
> Coma is identified as being for the Management of Constrained Networks
> and Devices, yet the discussion to date seems to have just focused on
> constrained devices. So is the "and" a boolean, meaning neither
> "Unconstrained Devices on Constrained Networks" nor "Constrained Devices
> on Unconstrained Networks" are included? For example, manpack HF radios
> may not be constrained devices but do exist on a constrained network and
> may need to be remotely managed. Should they be included?

I read it as "management of constrained networks, and management of
constrained devices".

Having a birthday party for Bob and Carol doesn't preclude
Ted and Alice from getting some cake, too.

I think it is quite reasonable to raise the question of high-capability
devices only reachable through constrained networks, and that seems
clearly within the scope of management of constrained networks.

Randy

Date: Thu, 7 Jun 2012 14:26:48 -0700
From: Ulrich Herberg <[email-masked]>
To: [email-masked]
Subject: [Coma] Possible topics?

Hi,

I just discovered this mailing list. Some aspects I have in mind about
the topic of managing constrained devices and networks:

- Do we actually manage single devices or whole networks (or groups of
devices)? At least in MANETs, it may be of equal interest to monitor
(and manage) the performance of a whole network, rather than just a
single router.
- Should we support a distributed approach or a enforce a centralized
NMS? (or support both modes of operation?)
- Which transport protocols do we want to use? TCP/UDP or something like COAP?
- Do we need efficient, reliable multicast (like NORM, but
lightweight) to distribute control traffic more efficiently?
- Can we provide sufficient levels of security without putting too
much burden on constrained devices? Which authentication modes do we
need?
- Should there be a proxy functionality like RMON (or something like
the currently developed REPORT-MIB in MANET), in order to record
performance related values locally and then send to a NMS later?
- Will there be a mapping to existing management protocols like SNMP
for border gateways?
- Is there any assumption for this work about the reliability of the
channel, the kind of the link layer (e.g., wireless/wired), mobility
etc? Or is the only assumption that the devices are "constrained" (in
terms of memory? CPU? network connection?)

Best
Ulrich

[Coma] Subject: New Non-WG Mailing List: coma -- Management of
Constrained Networks and Devices

    From: IETF Secretariat <ietf-secretariat at ietf.org>
    To: IETF Announcement List <ietf-announce at ietf.org>
    Cc: bclaise at cisco.com, coma at ietf.org
    Date: Wed, 16 May 2012 10:39:36 -0700
    List-id: Management of Constrained Networks and Devices <coma.ietf.org>

A new IETF non-working group email list has been created.

List address: coma at ietf.org
Archive:  http://www.ietf.org/mail-archive/web/coma/
To subscribe:  https://www.ietf.org/mailman/listinfo/coma

Purpose: This list is for the discussion related to the management of
constrained networks and devices. The IETF so far has not developed
specific technologies for the management of constrained networks.
There is a need to
understand the requirements for the management of such a constrained
network and its devices.

For additional information, please contact the list administrators.

From: Zach Shelby <[email-masked]>
Date: Thu, 7 Jun 2012 17:06:51 +0200
To: <[email-masked]>
Cc: [email-masked]
Subject: Re: [Coma] Management of Constrained Networks and Devices

Jonathan,

Excellent point. It is Constrained Networks *or* Devices in practice really, as you point out there are cases when not so constrained devices are on challenging networks. Any 802.15.4 network for example falls under this category. 

So the discussion about Class 0, 1, 2 doesn't really explain the whole story. 

Zach

On Jun 7, 2012, at 5:00 PM, <[email-masked]> wrote:

> Could someone clarify something for me please?
>  
> Coma is identified as being for the Management of Constrained Networks and Devices, yet the discussion to date seems to have just focused on constrained devices. So is the �and� a boolean, meaning neither �Unconstrained Devices on Constrained Networks� nor �Constrained Devices on Unconstrained Networks� are included? For example, manpack HF radios may not be constrained devices but do exist on a constrained network and may need to be remotely managed. Should they be included?

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

Content-class: urn:content-classes:message
Date: Thu, 7 Jun 2012 16:00:16 +0100
From: <[email-masked]>
To: <[email-masked]>
Subject: [Coma] Management of Constrained Networks and Devices

This is a multi-part message in MIME format.

------_=_NextPart_001_01CD44BE.3A13195F
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-NAIMIME-Disclaimer: 1
X-NAIMIME-Modified: 1

Hi,

Could someone clarify something for me please? 

Coma is identified as being for the Management of Constrained Networks
and Devices, yet the discussion to date seems to have just focused on
constrained devices. So is the "and" a boolean, meaning neither
"Unconstrained Devices on Constrained Networks" nor "Constrained Devices
on Unconstrained Networks" are included? For example, manpack HF radios
may not be constrained devices but do exist on a constrained network and
may need to be remotely managed. Should they be included?

Thanks,

Jonathan

This email and any files attached are intended for the addressee and may contain information of a confidential nature. If you are not the intended recipient, be aware that this email was sent to you in error and you should not disclose, distribute, print, copy or make other use of this email or its attachments. Such actions, in fact, may be unlawful. In compliance with the various Regulations and Acts, General Dynamics United Kingdom Limited reserves the right to monitor (and examine for viruses) all emails and email attachments, both inbound and outbound. Email communications and their attachments may not be secure or error- or virus-free and the company does not accept liability or responsibility for such matters or the consequences thereof. General Dynamics United Kingdom Limited, Registered Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and Wales No: 1911653. 

------_=_NextPart_001_01CD44BE.3A13195F
Content-Type: text/HTML;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-NAIMIME-Disclaimer: 1
X-NAIMIME-Modified: 1

<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle19
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=EN-GB link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Hi,<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Could someone clarify something for me please? <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Coma is identified as being for the Management of
Constrained Networks and Devices, yet the discussion to date seems to have just
focused on constrained devices. So is the &#8220;and&#8221; a boolean, meaning neither
&#8220;Unconstrained Devices on Constrained Networks&#8221; nor &#8220;Constrained
Devices on Unconstrained Networks&#8221; are included? For example, manpack HF
radios may not be constrained devices but do exist on a constrained network and
may need to be remotely managed. Should they be included?<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Thanks,<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Jonathan<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

<DIV><P><HR>
This email and any files attached are intended for the addressee and may contain information of a confidential nature. If you are not the intended recipient, be aware that this email was sent to you in error and you should not disclose, distribute, print, copy or make other use of this email or its attachments. Such actions, in fact, may be unlawful. In compliance with the various Regulations and Acts, General Dynamics United Kingdom Limited reserves the right to monitor (and examine for viruses) all emails and email attachments, both inbound and outbound. Email communications and their attachments may not be secure or error- or virus-free and the company does not accept liability or responsibility for such matters or the consequences thereof. General Dynamics United Kingdom Limited, Registered Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and Wales No: 1911653. 
</P></DIV>
</body>

</html>

------_=_NextPart_001_01CD44BE.3A13195F--

From: Rares Ivan <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 6 Jun 2012 17:20:40 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [Coma] Constrained Device Classes 0, 1 and 2 and their need for Management

Hello,

In my opinion the classification should not be directly connected to the hardware capabilities of devices (like processing power, RAM, flash) just because same functional features can be supported on devices with very different hardware capabilities and architecture. There shouldn't be any mention of hardware resources.

The classification shall be based on various sets of features supported by a device. Therefore the complete list of features can be divided in subsets where Class-0 (C0) is the smallest set of supported features, Class-1 (C1) adds more features on top of C0, Class-2 (C2) adds more features on top of C1, and so on. A Class-2 device is implicitly compliant with Class-1 and Class-0, therefore a network manager that can manage Class-2 can also manage the lower classes; a manager that can only manage Class-1 devices could only manage Class-2 devices based on features specific to Class-1, which is the manager's limitation.

The higher the class, the more features a device supports, and based on this classification a manager would know what the capabilities of a device shall be. There wouldn't be any in-between classes specs allowed, and a device cannot be claimed as Class-2 compliant unless it supports ALL the features required by that category.

Regards,
  Rares

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Wednesday, June 06, 2012 5:22 AM
To: Ersue, Mehmet (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [Coma] Constrained Device Classes 0, 1 and 2 and their need for Management

On Wed, Jun 06, 2012 at 10:42:13AM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote:
> Hi All,
> 
> following is an attempt to define the device classes in constrained 
> networks a bit more in detail. The text below follows the definition 
> of the three device classes provided by Carsten.
> 
> Class-0 (C0) devices are very constrained sensor-like motes. They will 
> most likely not have the possibility to have a direct communications 
> with the Internet in a secure manner. These class-0 devices will 
> participate in Internet communications with the help of larger devices 
> acting as proxy or gateways.
> 
> Class-1 (C1) devices are assumed to have about 10 Kbytes of RAM and 
> roughly 100 Kbytes of code space (e.g. Flash). For example, this could 
> be an AVR Raven mote (http://www.atmel.com/tools/AVRRAVEN.aspx). 
> Class-1 devices can't easily talk to other Internet nodes with a full 
> protocol stack using HTTP, TLS and related security protocols, and 
> XML-based data representations. However, they have enough power to use 
> a reduced or lightweight protocol stack (e.g. with CoAP and UDP) and 
> participate in meaningful conversations without the help of a gateway 
> node. So they can be integrated into the IoT network in one way or the 
> other but need to spare with memory for the protocol and application usage.
> 
> Class-2 (C2) devices are embedded devices with around 50 Kbytes of RAM 
> and maybe 250 Kbytes of code space and can support mostly the same 
> protocol stack as used on notebooks or servers. However, even these 
> devices can benefit from lightweight and energy-efficient protocols 
> and producing less bandwidth on air. Furthermore, using less network 
> resources would leave more resources available to applications. As 
> such using the same protocol stack on Class 1 and 2 devices might be 
> beneficial.
> 
> I assume we cannot do much for the management on C0 devices. They will 
> be most likely preconfigured and if ever will be reconfigured seldomly 
> with a very small data set.
> 
> For C1 devices it is indeed subject for discussion and to understand 
> what type of applications they could run and which management 
> mechanisms would be most suitable.
> Even though they have some more functionality available we need to 
> assess C2 devices for the type of applications they will be running 
> and the management they would need. To be able to derive the 
> requirements we need to discuss the uses cases and how the devices are 
> involved in the management scenario. The use cases where C1 or C2 
> devices build a cluster or are part of a hierarchy as well as the 
> assumed degree of automation might be essentially important.
> 
> Comments are welcome.

This classification is very rough since devices differ in their architecture. For example, some devices can run their software right out of flash memory and hence their RAM is really only used for the storage of variables and the stack. Other devices have to copy the machine code from flash to RAM before they can execute it. Such devices have relatively large amounts of RAM but most of it is used to store machine code.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
Coma mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/coma

From: <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 6 Jun 2012 20:04:43 +0000
Accept-Language: fr-FR, en-US
Subject: [Coma] (no subject)

--_000_11027135CD0DCE41B9C193E3D7257738EE73PEXCVZYM12corporate_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear all,

It's an excellent idea to investigate this domain. From my perspective, the first requirements related to the management aspect of such devices in their particular environment are auto-configuration which is addressed by design. When it comes to standardization for sure there is some work to do accordingly.

Within operator's environment, could be Fixed or Mobile networks, the Home Gateway and its attached devices, BBF protocol TR-69 is adopted and used for managing (configuration) of HomeNodeB and HomeeNodeBs. Netconf and its associated modeling language Yang have reached a maturity and are implemented in vendors' solutions. Some extensions are considered in order to address management aspects beyond simple configuration.

The requirements and associated solutions should be business driven, and then we address the technical solutions. That means, we should look at the vertical market needs (Health, Digital Home, ...) in terms of expectation of SLAs. Then the question is how to translate these SLAs into SLOs, metrics and how to track, measure, collect and report them (the needed management models and tools) in order to meet the SLAs.

The question related to the management is 3-fold:

- Which protocol: should we adapt the existing ones (TR-69, Netconf, ) to this constrained devices and network, or should designnew ones as IETF did for routing protocols.

- Which interface:  We should not re-invente the wheel

- Which Data model:  We should not re-invente the wheel.

So, this first draft should contain at least the following sections

-    Problem statement

-    Business needs and requirements

-    Technical requirements

-    Gap analysis: missing pieces to be covered by IETF and other SDOs

-    New topics to be investigated

Regards

Tayeb

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

--_000_11027135CD0DCE41B9C193E3D7257738EE73PEXCVZYM12corporate_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Texte brut Car";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Consolas;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.TextebrutCar
	{mso-style-name:"Texte brut Car";
	mso-style-priority:99;
	mso-style-link:"Texte brut";
	font-family:Consolas;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:914048466;
	mso-list-type:hybrid;
	mso-list-template-ids:-1438196870 1601317376 67895299 67895301 67895297 67895299 67895301 67895297 67895299 67895301;}
@list l0:level1
	{mso-level-start-at:0;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Consolas;
	mso-fareast-font-family:SimSun;
	mso-bidi-font-family:Arial;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="FR" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Dear all,<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoPlainText"><span lang="EN-US">It&#8217;s an excellent idea to investigate this domain. From my perspective, the first requirements related to the management aspect of such devices in their particular environment are auto-configuration which is addressed
 by design. When it comes to standardization for sure there is some work to do accordingly.<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US"><o:p>&nbsp;</o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US">Within operator's environment, could be Fixed or Mobile networks, the Home Gateway and its attached devices, BBF protocol TR-69 is adopted and used for managing (configuration) of HomeNodeB and HomeeNodeBs. Netconf
 and its associated modeling language Yang have reached a maturity and are implemented in vendors' solutions. Some extensions are considered in order to address management aspects beyond simple configuration.
<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US"><o:p>&nbsp;</o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US">The requirements and associated solutions should be business driven, and then we address the technical solutions. That means, we should look at the vertical market needs (Health, Digital Home, ...) in terms of expectation
 of SLAs. Then the question is how to translate these SLAs into SLOs, metrics and how to track, measure, collect and report them (the needed management models and tools) in order to meet the SLAs.<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US"><o:p>&nbsp;</o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US">The question related to the management is 3-fold:<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US">- Which protocol: should we adapt the existing ones (TR-69, Netconf, ) to this constrained devices and network, or should designnew ones as IETF did for routing protocols.<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US">- Which interface: &nbsp;We should not re-invente the wheel<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US">- Which Data model: &nbsp;We should not re-invente the wheel.
<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US"><o:p>&nbsp;</o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US">So, this first draft should contain at least the following sections<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 lfo1">
<![if !supportLists]><span lang="EN-US"><span style="mso-list:Ignore">-<span style="font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span dir="LTR"></span><span lang="EN-US">Problem statement<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 lfo1">
<![if !supportLists]><span lang="EN-US"><span style="mso-list:Ignore">-<span style="font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span dir="LTR"></span><span lang="EN-US">Business needs and requirements<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 lfo1">
<![if !supportLists]><span lang="EN-US"><span style="mso-list:Ignore">-<span style="font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span dir="LTR"></span><span lang="EN-US">Technical requirements<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 lfo1">
<![if !supportLists]><span lang="EN-US"><span style="mso-list:Ignore">-<span style="font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span dir="LTR"></span><span lang="EN-US">Gap analysis: missing pieces to be covered by IETF and other SDOs<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 lfo1">
<![if !supportLists]><span lang="EN-US"><span style="mso-list:Ignore">-<span style="font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span dir="LTR"></span><span lang="EN-US">New topics to be investigated<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US"><o:p>&nbsp;</o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US"><o:p>&nbsp;</o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US">Regards<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US"><o:p>&nbsp;</o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US">Tayeb<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p>&nbsp;</o:p></span></p>
</div>
<PRE>_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
</PRE></body>
</html>

--_000_11027135CD0DCE41B9C193E3D7257738EE73PEXCVZYM12corporate_--

Date: Wed, 6 Jun 2012 11:22:17 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: Re: [Coma] Constrained Device Classes 0, 1 and 2 and their need for Management
Reply-To: Juergen Schoenwaelder <[email-masked]>

On Wed, Jun 06, 2012 at 10:42:13AM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote:
> Hi All,
> 
> following is an attempt to define the device classes in constrained
> networks a bit more in detail. The text below follows the definition of
> the three device classes provided by Carsten.
> 
> Class-0 (C0) devices are very constrained sensor-like motes. They will
> most likely not have the possibility to have a direct communications
> with the Internet in a secure manner. These class-0 devices will
> participate in Internet communications with the help of larger devices
> acting as proxy or gateways. 
> 
> Class-1 (C1) devices are assumed to have about 10 Kbytes of RAM and
> roughly 100 Kbytes of code space (e.g. Flash). For example, this could
> be an AVR Raven mote (http://www.atmel.com/tools/AVRRAVEN.aspx). Class-1
> devices can't easily talk to other Internet nodes with a full protocol
> stack using HTTP, TLS and related security protocols, and XML-based data
> representations. However, they have enough power to use a reduced or
> lightweight protocol stack (e.g. with CoAP and UDP) and participate in
> meaningful conversations without the help of a gateway node. So they can
> be integrated into the IoT network in one way or the other but need to
> spare with memory for the protocol and application usage.
> 
> Class-2 (C2) devices are embedded devices with around 50 Kbytes of RAM
> and maybe 250 Kbytes of code space and can support mostly the same
> protocol stack as used on notebooks or servers. However, even these
> devices can benefit from lightweight and energy-efficient protocols and
> producing less bandwidth on air. Furthermore, using less network
> resources would leave more resources available to applications. As such
> using the same protocol stack on Class 1 and 2 devices might be
> beneficial.
> 
> I assume we cannot do much for the management on C0 devices. They will
> be most likely preconfigured and if ever will be reconfigured seldomly
> with a very small data set.
> 
> For C1 devices it is indeed subject for discussion and to understand
> what type of applications they could run and which management mechanisms
> would be most suitable.
> Even though they have some more functionality available we need to
> assess C2 devices for the type of applications they will be running and
> the management they would need. To be able to derive the requirements we
> need to discuss the uses cases and how the devices are involved in the
> management scenario. The use cases where C1 or C2 devices build a
> cluster or are part of a hierarchy as well as the assumed degree of
> automation might be essentially important.
> 
> Comments are welcome.

This classification is very rough since devices differ in their
architecture. For example, some devices can run their software right
out of flash memory and hence their RAM is really only used for the
storage of variables and the stack. Other devices have to copy the
machine code from flash to RAM before they can execute it. Such
devices have relatively large amounts of RAM but most of it is used to
store machine code.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

Content-class: urn:content-classes:message
Date: Wed, 6 Jun 2012 10:52:10 +0200
From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
To: "Juergen Schoenwaelder" <[email-masked]>
Cc: ext Antonio Jara <[email-masked]>, Zach Shelby <[email-masked]>, [email-masked]
Subject: Re: [Coma] New Maillist for the discussion on the Management of Constrained Networks and Devices

Hi Juergen,

> I think device classes are one dimension but there are others. Lets
> think also about "application scenarios or classes" (there might be
> better terms): there will be applications and corresponding devices
> where there simply is no explicit management ever (the device either
> works or it is thrown away). Other scenarios may involve the need to
> integrate constrained devices into a system also comprising more
> traditionally managed devices. Other scenarios may be fully
> application driven and any necessary management functions must become
> part of that application.

Agree. Matching device classes to possible applications in use might not
be sufficient. A top down view for application driven scenarios would be
useful.

Could you describe the application classes and the list of relevant
scenarios you have in mind. Some draft text would be helpful.

Cheers,
Mehmet

Content-class: urn:content-classes:message
Date: Wed, 6 Jun 2012 10:42:13 +0200
From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
To: <[email-masked]>
Subject: [Coma] Constrained Device Classes 0, 1 and 2 and their need for Management

Hi All,

following is an attempt to define the device classes in constrained
networks a bit more in detail. The text below follows the definition of
the three device classes provided by Carsten.

Class-0 (C0) devices are very constrained sensor-like motes. They will
most likely not have the possibility to have a direct communications
with the Internet in a secure manner. These class-0 devices will
participate in Internet communications with the help of larger devices
acting as proxy or gateways. 

Class-1 (C1) devices are assumed to have about 10 Kbytes of RAM and
roughly 100 Kbytes of code space (e.g. Flash). For example, this could
be an AVR Raven mote (http://www.atmel.com/tools/AVRRAVEN.aspx). Class-1
devices can't easily talk to other Internet nodes with a full protocol
stack using HTTP, TLS and related security protocols, and XML-based data
representations. However, they have enough power to use a reduced or
lightweight protocol stack (e.g. with CoAP and UDP) and participate in
meaningful conversations without the help of a gateway node. So they can
be integrated into the IoT network in one way or the other but need to
spare with memory for the protocol and application usage.

Class-2 (C2) devices are embedded devices with around 50 Kbytes of RAM
and maybe 250 Kbytes of code space and can support mostly the same
protocol stack as used on notebooks or servers. However, even these
devices can benefit from lightweight and energy-efficient protocols and
producing less bandwidth on air. Furthermore, using less network
resources would leave more resources available to applications. As such
using the same protocol stack on Class 1 and 2 devices might be
beneficial.

I assume we cannot do much for the management on C0 devices. They will
be most likely preconfigured and if ever will be reconfigured seldomly
with a very small data set.

For C1 devices it is indeed subject for discussion and to understand
what type of applications they could run and which management mechanisms
would be most suitable.
Even though they have some more functionality available we need to
assess C2 devices for the type of applications they will be running and
the management they would need. To be able to derive the requirements we
need to discuss the uses cases and how the devices are involved in the
management scenario. The use cases where C1 or C2 devices build a
cluster or are part of a hierarchy as well as the assumed degree of
automation might be essentially important.

Comments are welcome.

Cheers, 
Mehmet 

Date: Tue, 5 Jun 2012 14:05:05 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>, ext Antonio Jara <[email-masked]>, Zach Shelby <[email-masked]>, Benoit Claise <[email-masked]>, Ron Bonica <[email-masked]>, [email-masked]
Cc: Benoit Claise <[email-masked]>, Ron Bonica <[email-masked]>, ext Antonio Jara <[email-masked]>, Zach Shelby <[email-masked]>, [email-masked]
Subject: Re: [Coma] New Maillist for the discussion on the Management of Constrained Networks and Devices
Reply-To: Juergen Schoenwaelder <[email-masked]>

On Tue, Jun 05, 2012 at 01:58:24PM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote:
> Hi Antonio,
> 
> there is no final ToC or text available right now.
> All is open to your comment and suggestions.
> 
> I can imagine a ToC could possibly contain following:
> 
>    1. Introduction 
>      1.1.  Overview
>      1.2.  Basic scenarios in discussion
>      1.4.  Constrained Device Classes 
>    2. Terminology 
>    3. Problem Statement 
>    4. Requirements per Device Class 
>    5. Security Considerations 
>    6. Acknowledgments 
>    7. References 

I think device classes are one dimension but there are others. Lets
think also about "application scenarios or classes" (there might be
better terms): there will be applications and corresponding devices
where there simply is no explicit management ever (the device either
works or it is thrown away). Other scenarios may involve the need to
integrate constrained devices into a system also comprising more
traditionally managed devices. Other scenarios may be fully
application driven and any necessary management functions must become
part of that application.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

Content-class: urn:content-classes:message
Date: Tue, 5 Jun 2012 13:58:24 +0200
From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
To: "ext Antonio Jara" <[email-masked]>, "Zach Shelby" <[email-masked]>
Cc: Benoit Claise <[email-masked]>, Ron Bonica <[email-masked]>, [email-masked]
Subject: Re: [Coma] New Maillist for the discussion on the Management of Constrained Networks and Devices

Hi Antonio,

there is no final ToC or text available right now.
All is open to your comment and suggestions.

I can imagine a ToC could possibly contain following:

   1. Introduction 
     1.1.  Overview
     1.2.  Basic scenarios in discussion
     1.4.  Constrained Device Classes 
   2. Terminology 
   3. Problem Statement 
   4. Requirements per Device Class 
   5. Security Considerations 
   6. Acknowledgments 
   7. References 

Cheers, 
Mehmet 

> -----Original Message-----
> From: ext Antonio Jara [mailto:[email-masked]]
> Sent: Friday, June 01, 2012 4:33 PM
> To: Zach Shelby
> Cc: Benoit Claise; Ersue, Mehmet (NSN - DE/Munich); Ron Bonica; [email-masked]
> Subject: Re: [Coma] New Maillist for the discussion on the Management of Constrained
> Networks and Devices
> 
> So..., any ToC in mind?, where we can see that parts we can provide
> some text and relevant information.
> 
> 
> On Fri, Jun 1, 2012 at 4:24 PM, Zach Shelby <[email-masked]> wrote:
> > Hi,
> >
> > (constrained guy hat on)
> >
> > Sounds like a reasonable way forward to me.
> >
> > Zach
> >
> > On Jun 1, 2012, at 5:21 PM, Benoit Claise wrote:
> >
> >> Dear all,
> >>
> >> [reducing the mailing lists to coma only]
> >>
> >> I believe it is time to think on what is needed for the management of constrained
> devices and how the OPS area could address the requirements.
> >>
> >> What would be nice is a �"constrained devices management: problem statement"
> draft so that
> >> 1. the requirements are clearly written down
> >> 2. the OPS area could, if required, work on the protocol/data model language/data
> model modules/encoding mapping
> >>
> >>
> >> IMHO,
> >> 1. we should NOT put the proposed solutions in that draft, i.e. "if you want to do X,
> then use Y". My fear is that the requirements will be tweaked if people don't like the
> protocol/data model language.
> >> 2. the feedback must come from the constrained device experts. OPS should not
> be building a solution for a problem that we, OPS, think that the constrained devices
> experts have.
> >>
> >> Regards, Benoit.
> >>
> >>> Hi All,
> >>>
> >>> as noted in the maillist announcement of IETF secretary "coma" maillist
> >>> is for the discussion on the management of constrained networks and
> >>> devices. The mailing list will discuss and identify the issues and
> >>> requirements and objectives for the management of devices in such an
> >>> environment with a special focus on and differentiation of device
> >>> classes.
> >>>
> >>> The idea and trigger for the maillist creation came from a discussion in
> >>> the OPS directorate during IETF #82. As
> >>> draft-ietf-opsawg-management-stds-07 states IETF so far has not
> >>> developed specific technologies for the management of constrained
> >>> networks. OPS directorate members stated in IETF #82 that there is a
> >>> need to understand the requirements and the necessary solutions for the
> >>> management of such a constrained network and its devices. The assumption
> >>> people had was that we need a comprehensive management approach to be
> >>> able to address the diverse needs of different device classes.
> >>>
> >>> Although the OPS area was doing already standardization work for network
> >>> management, the Core WG is one of the essential WGs at IETF interested
> >>> in the management of constrained devices.
> >>>
> >>> Following are some of the questions which have been raised in the OPS
> >>> directorate meeting, which are for sure subject to extend from Core WG
> >>> pov.:
> >>>
> >>> * � �Do we need a new development for IoT management (i.e.
> >>> constrained devices) at all?
> >>> - � �If yes, what is really needed as standard and what is an
> >>> overkill?
> >>> * � �What type of devices can we support?
> >>> * � �How are the classes 0-2 for constrained devices defined in
> >>> detail?
> >>> * � �Is some simple configuration management already sufficient?
> >>> - � �Or do we need also a simple fault management and monitoring?
> >>> * � �What type of data model modules do we need to standardize?
> >>> - � �Just a few core models like ip-cfg, interface?
> >>> - � �or also other specific models for monitoring?
> >>> * � �Can we use available management standards and data models as a
> >>> starting point and simplify them?
> >>> * � �Concerning the encoding (JSON, XML, or binary) we seem to be
> >>> flexible with tools.
> >>> - � �Concerning a normative data modeling language, we need to choose
> >>> a suitable language capable to prepare structured models.
> >>> - � �Is JSON sufficient for this purpose, or should YANG or any other
> >>> modeling language be used?
> >>> * � �What is appropriate as message transport?
> >>> - � �CoAP over UDP with soft-transactions?
> >>> - � �Netconf-Light over TCP?
> >>>
> >>> Obviously the list of the questions above is not exhaustive.
> >>>
> >>> Carsten kindfully provided already in the Prague meeting the definition
> >>> of device classes 0-2
> >>> (http://www.ietf.org/proceedings/80/slides/core-0.pdf). I think it would
> >>> be useful to start a discussion first on the detailed definition of
> >>> these device classes 0-2 in constrained networks and based on their
> >>> capabilities which functionality they will be able to support. This can
> >>> be then used as a guideline for further discussion on the requirements
> >>> or objectives for management of such devices.
> >>>
> >>> As noted in the announcement the result of the coma discussion can lead
> >>> to a taxonomy document and a problem statement highlighting the need for
> >>> new work.
> >>>
> >>> Please send your opinions/comments to the coma maillist ([email-masked]).
> >>> To subscribe pls go to: https://www.ietf.org/mailman/listinfo/coma
> >>>
> >>> Cheers,
> >>> Mehmet
> >>>
> >>>
> >>> BTW: Coma has been chosen as the maillist name following the definition
> >>> below:
> >>>
> >>> Coma \Co"ma\, n. [L., hair, fr. Gr. ko`mh.]
> >>> � �1. (Astron.) The envelope of a comet; a nebulous covering,
> >>> � � � which surrounds the nucleus or body of a comet.
> >>> � � � [1913 Webster]
> >>>
> >>>
> >>>
> >>
> >> _______________________________________________
> >> Coma mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/coma
> >
> > --
> > Zach Shelby, Chief Nerd, Sensinode Ltd.
> > http://www.sensinode.com
> > http://zachshelby.org �- My blog "On the Internet of Things"
> > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
> > Mobile: +358 40 7796297
> >
> > _______________________________________________
> > Coma mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/coma

From: Antonio Jara <[email-masked]>
Date: Fri, 1 Jun 2012 16:33:08 +0200
To: Zach Shelby <[email-masked]>
Cc: Benoit Claise <[email-masked]>, "Ersue, Mehmet \(NSN - DE/Munich\)" <[email-masked]>, [email-masked], Ron Bonica <[email-masked]>
Subject: Re: [Coma] New Maillist for the discussion on the Management of Constrained Networks and Devices

So..., any ToC in mind?, where we can see that parts we can provide
some text and relevant information.

On Fri, Jun 1, 2012 at 4:24 PM, Zach Shelby <[email-masked]> wrote:
> Hi,
>
> (constrained guy hat on)
>
> Sounds like a reasonable way forward to me.
>
> Zach
>
> On Jun 1, 2012, at 5:21 PM, Benoit Claise wrote:
>
>> Dear all,
>>
>> [reducing the mailing lists to coma only]
>>
>> I believe it is time to think on what is needed for the management of constrained devices and how the OPS area could address the requirements.
>>
>> What would be nice is a �"constrained devices management: problem statement" draft so that
>> 1. the requirements are clearly written down
>> 2. the OPS area could, if required, work on the protocol/data model language/data model modules/encoding mapping
>>
>>
>> IMHO,
>> 1. we should NOT put the proposed solutions in that draft, i.e. "if you want to do X, then use Y". My fear is that the requirements will be tweaked if people don't like the protocol/data model language.
>> 2. the feedback must come from the constrained device experts. OPS should not be building a solution for a problem that we, OPS, think that the constrained devices experts have.
>>
>> Regards, Benoit.
>>
>>> Hi All,
>>>
>>> as noted in the maillist announcement of IETF secretary "coma" maillist
>>> is for the discussion on the management of constrained networks and
>>> devices. The mailing list will discuss and identify the issues and
>>> requirements and objectives for the management of devices in such an
>>> environment with a special focus on and differentiation of device
>>> classes.
>>>
>>> The idea and trigger for the maillist creation came from a discussion in
>>> the OPS directorate during IETF #82. As
>>> draft-ietf-opsawg-management-stds-07 states IETF so far has not
>>> developed specific technologies for the management of constrained
>>> networks. OPS directorate members stated in IETF #82 that there is a
>>> need to understand the requirements and the necessary solutions for the
>>> management of such a constrained network and its devices. The assumption
>>> people had was that we need a comprehensive management approach to be
>>> able to address the diverse needs of different device classes.
>>>
>>> Although the OPS area was doing already standardization work for network
>>> management, the Core WG is one of the essential WGs at IETF interested
>>> in the management of constrained devices.
>>>
>>> Following are some of the questions which have been raised in the OPS
>>> directorate meeting, which are for sure subject to extend from Core WG
>>> pov.:
>>>
>>> * � �Do we need a new development for IoT management (i.e.
>>> constrained devices) at all?
>>> - � �If yes, what is really needed as standard and what is an
>>> overkill?
>>> * � �What type of devices can we support?
>>> * � �How are the classes 0-2 for constrained devices defined in
>>> detail?
>>> * � �Is some simple configuration management already sufficient?
>>> - � �Or do we need also a simple fault management and monitoring?
>>> * � �What type of data model modules do we need to standardize?
>>> - � �Just a few core models like ip-cfg, interface?
>>> - � �or also other specific models for monitoring?
>>> * � �Can we use available management standards and data models as a
>>> starting point and simplify them?
>>> * � �Concerning the encoding (JSON, XML, or binary) we seem to be
>>> flexible with tools.
>>> - � �Concerning a normative data modeling language, we need to choose
>>> a suitable language capable to prepare structured models.
>>> - � �Is JSON sufficient for this purpose, or should YANG or any other
>>> modeling language be used?
>>> * � �What is appropriate as message transport?
>>> - � �CoAP over UDP with soft-transactions?
>>> - � �Netconf-Light over TCP?
>>>
>>> Obviously the list of the questions above is not exhaustive.
>>>
>>> Carsten kindfully provided already in the Prague meeting the definition
>>> of device classes 0-2
>>> (http://www.ietf.org/proceedings/80/slides/core-0.pdf). I think it would
>>> be useful to start a discussion first on the detailed definition of
>>> these device classes 0-2 in constrained networks and based on their
>>> capabilities which functionality they will be able to support. This can
>>> be then used as a guideline for further discussion on the requirements
>>> or objectives for management of such devices.
>>>
>>> As noted in the announcement the result of the coma discussion can lead
>>> to a taxonomy document and a problem statement highlighting the need for
>>> new work.
>>>
>>> Please send your opinions/comments to the coma maillist ([email-masked]).
>>> To subscribe pls go to: https://www.ietf.org/mailman/listinfo/coma
>>>
>>> Cheers,
>>> Mehmet
>>>
>>>
>>> BTW: Coma has been chosen as the maillist name following the definition
>>> below:
>>>
>>> Coma \Co"ma\, n. [L., hair, fr. Gr. ko`mh.]
>>> � �1. (Astron.) The envelope of a comet; a nebulous covering,
>>> � � � which surrounds the nucleus or body of a comet.
>>> � � � [1913 Webster]
>>>
>>>
>>>
>>
>> _______________________________________________
>> Coma mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/coma
>
> --
> Zach Shelby, Chief Nerd, Sensinode Ltd.
> http://www.sensinode.com
> http://zachshelby.org �- My blog "On the Internet of Things"
> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
> Mobile: +358 40 7796297
>
> _______________________________________________
> Coma mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/coma

From: Zach Shelby <[email-masked]>
Date: Fri, 1 Jun 2012 17:24:36 +0300
To: Benoit Claise <[email-masked]>
Cc: "Ersue, Mehmet \(NSN - DE/Munich\)" <[email-masked]>, Ron Bonica <[email-masked]>, [email-masked]
Subject: Re: [Coma] New Maillist for the discussion on the Management of Constrained Networks and Devices

Hi,

(constrained guy hat on)

Sounds like a reasonable way forward to me. 

Zach

On Jun 1, 2012, at 5:21 PM, Benoit Claise wrote:

> Dear all,
> 
> [reducing the mailing lists to coma only]
> 
> I believe it is time to think on what is needed for the management of constrained devices and how the OPS area could address the requirements.
> 
> What would be nice is a  "constrained devices management: problem statement" draft so that
> 1. the requirements are clearly written down
> 2. the OPS area could, if required, work on the protocol/data model language/data model modules/encoding mapping
> 
> 
> IMHO,
> 1. we should NOT put the proposed solutions in that draft, i.e. "if you want to do X, then use Y". My fear is that the requirements will be tweaked if people don't like the protocol/data model language.
> 2. the feedback must come from the constrained device experts. OPS should not be building a solution for a problem that we, OPS, think that the constrained devices experts have.
> 
> Regards, Benoit.
> 
>> Hi All,
>> 
>> as noted in the maillist announcement of IETF secretary "coma" maillist
>> is for the discussion on the management of constrained networks and
>> devices. The mailing list will discuss and identify the issues and
>> requirements and objectives for the management of devices in such an
>> environment with a special focus on and differentiation of device
>> classes.
>> 
>> The idea and trigger for the maillist creation came from a discussion in
>> the OPS directorate during IETF #82. As
>> draft-ietf-opsawg-management-stds-07 states IETF so far has not
>> developed specific technologies for the management of constrained
>> networks. OPS directorate members stated in IETF #82 that there is a
>> need to understand the requirements and the necessary solutions for the
>> management of such a constrained network and its devices. The assumption
>> people had was that we need a comprehensive management approach to be
>> able to address the diverse needs of different device classes.
>> 
>> Although the OPS area was doing already standardization work for network
>> management, the Core WG is one of the essential WGs at IETF interested
>> in the management of constrained devices.
>> 
>> Following are some of the questions which have been raised in the OPS
>> directorate meeting, which are for sure subject to extend from Core WG
>> pov.:
>> 
>> *	Do we need a new development for IoT management (i.e.
>> constrained devices) at all?
>> -	If yes, what is really needed as standard and what is an
>> overkill?
>> *	What type of devices can we support?
>> *	How are the classes 0-2 for constrained devices defined in
>> detail?
>> *	Is some simple configuration management already sufficient?
>> -	Or do we need also a simple fault management and monitoring?
>> *	What type of data model modules do we need to standardize?
>> -	Just a few core models like ip-cfg, interface?
>> -	or also other specific models for monitoring?
>> *	Can we use available management standards and data models as a
>> starting point and simplify them?
>> *	Concerning the encoding (JSON, XML, or binary) we seem to be
>> flexible with tools.
>> -	Concerning a normative data modeling language, we need to choose
>> a suitable language capable to prepare structured models.
>> -	Is JSON sufficient for this purpose, or should YANG or any other
>> modeling language be used?
>> *	What is appropriate as message transport?
>> -	CoAP over UDP with soft-transactions?
>> -	Netconf-Light over TCP?
>> 
>> Obviously the list of the questions above is not exhaustive.
>> 
>> Carsten kindfully provided already in the Prague meeting the definition
>> of device classes 0-2
>> (http://www.ietf.org/proceedings/80/slides/core-0.pdf). I think it would
>> be useful to start a discussion first on the detailed definition of
>> these device classes 0-2 in constrained networks and based on their
>> capabilities which functionality they will be able to support. This can
>> be then used as a guideline for further discussion on the requirements
>> or objectives for management of such devices.
>> 
>> As noted in the announcement the result of the coma discussion can lead
>> to a taxonomy document and a problem statement highlighting the need for
>> new work.
>> 
>> Please send your opinions/comments to the coma maillist ([email-masked]).
>> To subscribe pls go to: https://www.ietf.org/mailman/listinfo/coma
>> 
>> Cheers,
>> Mehmet
>> 
>> 
>> BTW: Coma has been chosen as the maillist name following the definition
>> below:
>> 
>> Coma \Co"ma\, n. [L., hair, fr. Gr. ko`mh.]
>>    1. (Astron.) The envelope of a comet; a nebulous covering,
>>       which surrounds the nucleus or body of a comet.
>>       [1913 Webster]
>> 
>> 
>> 
> 
> _______________________________________________
> Coma mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/coma

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

Date: Fri, 01 Jun 2012 16:21:31 +0200
From: Benoit Claise <[email-masked]>
To: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Cc: Ron Bonica <[email-masked]>, [email-masked]
Subject: Re: [Coma] New Maillist for the discussion on the Management of Constrained Networks and Devices

Dear all,

[reducing the mailing lists to coma only]

I believe it is time to think on what is needed for the management of 
constrained devices and how the OPS area could address the requirements.

What would be nice is a  "constrained devices management: problem 
statement" draft so that
1. the requirements are clearly written down
2. the OPS area could, if required, work on the protocol/data model 
language/data model modules/encoding mapping

IMHO,
1. we should NOT put the proposed solutions in that draft, i.e. "if you 
want to do X, then use Y". My fear is that the requirements will be 
tweaked if people don't like the protocol/data model language.
2. the feedback must come from the constrained device experts. OPS 
should not be building a solution for a problem that we, OPS, think that 
the constrained devices experts have.

Regards, Benoit.

> Hi All,
>
> as noted in the maillist announcement of IETF secretary "coma" maillist
> is for the discussion on the management of constrained networks and
> devices. The mailing list will discuss and identify the issues and
> requirements and objectives for the management of devices in such an
> environment with a special focus on and differentiation of device
> classes.
>
> The idea and trigger for the maillist creation came from a discussion in
> the OPS directorate during IETF #82. As
> draft-ietf-opsawg-management-stds-07 states IETF so far has not
> developed specific technologies for the management of constrained
> networks. OPS directorate members stated in IETF #82 that there is a
> need to understand the requirements and the necessary solutions for the
> management of such a constrained network and its devices. The assumption
> people had was that we need a comprehensive management approach to be
> able to address the diverse needs of different device classes.
>
> Although the OPS area was doing already standardization work for network
> management, the Core WG is one of the essential WGs at IETF interested
> in the management of constrained devices.
>
> Following are some of the questions which have been raised in the OPS
> directorate meeting, which are for sure subject to extend from Core WG
> pov.:
>
> *	Do we need a new development for IoT management (i.e.
> constrained devices) at all?
> -	If yes, what is really needed as standard and what is an
> overkill?
> *	What type of devices can we support?
> *	How are the classes 0-2 for constrained devices defined in
> detail?
> *	Is some simple configuration management already sufficient?
> -	Or do we need also a simple fault management and monitoring?
> *	What type of data model modules do we need to standardize?
> -	Just a few core models like ip-cfg, interface?
> -	or also other specific models for monitoring?
> *	Can we use available management standards and data models as a
> starting point and simplify them?
> *	Concerning the encoding (JSON, XML, or binary) we seem to be
> flexible with tools.
> -	Concerning a normative data modeling language, we need to choose
> a suitable language capable to prepare structured models.
> -	Is JSON sufficient for this purpose, or should YANG or any other
> modeling language be used?
> *	What is appropriate as message transport?
> -	CoAP over UDP with soft-transactions?
> -	Netconf-Light over TCP?
>
> Obviously the list of the questions above is not exhaustive.
>
> Carsten kindfully provided already in the Prague meeting the definition
> of device classes 0-2
> (http://www.ietf.org/proceedings/80/slides/core-0.pdf). I think it would
> be useful to start a discussion first on the detailed definition of
> these device classes 0-2 in constrained networks and based on their
> capabilities which functionality they will be able to support. This can
> be then used as a guideline for further discussion on the requirements
> or objectives for management of such devices.
>
> As noted in the announcement the result of the coma discussion can lead
> to a taxonomy document and a problem statement highlighting the need for
> new work.
>
> Please send your opinions/comments to the coma maillist ([email-masked]).
> To subscribe pls go to: https://www.ietf.org/mailman/listinfo/coma
>
> Cheers,
> Mehmet
>
>
> BTW: Coma has been chosen as the maillist name following the definition
> below:
>
> Coma \Co"ma\, n. [L., hair, fr. Gr. ko`mh.]
>     1. (Astron.) The envelope of a comet; a nebulous covering,
>        which surrounds the nucleus or body of a comet.
>        [1913 Webster]
>
>
>