Return-Path: X-Original-To: coma@ietfa.amsl.com Delivered-To: coma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22DA121F866D for ; Sat, 30 Jun 2012 06:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyYhMHg+3slZ for ; Sat, 30 Jun 2012 06:29:45 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id DB1AE21F851E for ; Sat, 30 Jun 2012 06:29:44 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q5UDTaBC023832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 30 Jun 2012 15:29:36 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q5UDTVfV019386; Sat, 30 Jun 2012 15:29:33 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Sat, 30 Jun 2012 15:28:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 30 Jun 2012 15:28:59 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6403F7F8B6@DEMUEXC006.nsn-intra.net> In-Reply-To: <004701cd55f8$aae33600$00a9a200$@cn> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Coma] (no subject) Thread-Index: Ac1VQVaY6w8eFDCmSRGWO8JpmJw/nAAlj4TgAAg7WCAADpUgkA== References: <00b101cd5508$22e90bd0$68bb2370$@cn> <20120628151851.GD56180@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6403F7F5E4@DEMUEXC006.nsn-intra.net> <004701cd55f8$aae33600$00a9a200$@cn> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Yan Wang" X-OriginalArrivalTime: 30 Jun 2012 13:28:59.0399 (UTC) FILETIME=[4E7CC170:01CD56C4] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 4624 X-purgate-ID: 151667::1341062976-00003CDD-8DC0541E/0-0/0-0 Cc: coma@ietf.org Subject: Re: [Coma] (no subject) X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2012 13:29:46 -0000 Hi Yan, > Maybe we should propose several use cases of different kinds of networks.=20 > 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.=20 Cheers,=20 Mehmet=20 > -----Original Message----- > From: ext Yan Wang [mailto:ywang@cnnic.cn] > Sent: Friday, June 29, 2012 3:11 PM > To: Ersue, Mehmet (NSN - DE/Munich); 'Juergen Schoenwaelder' > Cc: coma@ietf.org > Subject: RE: [Coma] (no subject) >=20 > 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. >=20 >=20 > Best wishes, > Yan >=20 > > -----Original Message----- > > From: coma-bounces@ietf.org [mailto:coma-bounces@ietf.org] On Behalf Of > > Ersue, Mehmet (NSN - DE/Munich) > > Sent: Friday, June 29, 2012 5:15 PM > > To: Juergen Schoenwaelder; Yan Wang > > Cc: coma@ietf.org > > 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: coma-bounces@ietf.org [mailto:coma-bounces@ietf.org] On Behalf > > Of ext > > > Juergen Schoenwaelder > > > Sent: Thursday, June 28, 2012 5:19 PM > > > To: Yan Wang > > > Cc: coma@ietf.org > > > 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: > > > > > > > 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 > > > _______________________________________________ > > > Coma mailing list > > > Coma@ietf.org > > > https://www.ietf.org/mailman/listinfo/coma > > _______________________________________________ > > Coma mailing list > > Coma@ietf.org > > https://www.ietf.org/mailman/listinfo/coma Return-Path: X-Original-To: coma@ietfa.amsl.com Delivered-To: coma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 162E221F8759 for ; Fri, 29 Jun 2012 06:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tX8q20PdhF9S for ; Fri, 29 Jun 2012 06:11:24 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 6891F21F874C for ; Fri, 29 Jun 2012 06:11:21 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: ywang@cnnic.cn Received: from unknown127.0.0.1 (HELO cnnicpc) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 29 Jun 2012 21:11:11 +0800 From: "Yan Wang" To: "'Ersue, Mehmet \(NSN - DE/Munich\)'" , "'Juergen Schoenwaelder'" References: <00b101cd5508$22e90bd0$68bb2370$@cn> <20120628151851.GD56180@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6403F7F5E4@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6403F7F5E4@DEMUEXC006.nsn-intra.net> Date: Fri, 29 Jun 2012 21:11:09 +0800 Message-ID: <004701cd55f8$aae33600$00a9a200$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1VQVaY6w8eFDCmSRGWO8JpmJw/nAAlj4TgAAg7WCA= Content-Language: zh-cn Cc: coma@ietf.org Subject: Re: [Coma] (no subject) X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 13:11:25 -0000 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: coma-bounces@ietf.org [mailto:coma-bounces@ietf.org] On Behalf Of > Ersue, Mehmet (NSN - DE/Munich) > Sent: Friday, June 29, 2012 5:15 PM > To: Juergen Schoenwaelder; Yan Wang > Cc: coma@ietf.org > 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: coma-bounces@ietf.org [mailto:coma-bounces@ietf.org] On Behalf > Of ext > > Juergen Schoenwaelder > > Sent: Thursday, June 28, 2012 5:19 PM > > To: Yan Wang > > Cc: coma@ietf.org > > 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: > > > > > 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 > > _______________________________________________ > > Coma mailing list > > Coma@ietf.org > > https://www.ietf.org/mailman/listinfo/coma > _______________________________________________ > Coma mailing list > Coma@ietf.org > https://www.ietf.org/mailman/listinfo/coma Return-Path: X-Original-To: coma@ietfa.amsl.com Delivered-To: coma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90B8621F8716 for ; Fri, 29 Jun 2012 02:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.513 X-Spam-Level: X-Spam-Status: No, score=-106.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPnVBs3sNJn5 for ; Fri, 29 Jun 2012 02:15:24 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 6590D21F86F4 for ; Fri, 29 Jun 2012 02:15:24 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q5T9FIMC004364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Jun 2012 11:15:18 +0200 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q5T9FHQJ031542; Fri, 29 Jun 2012 11:15:17 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Jun 2012 11:15:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 29 Jun 2012 11:15:16 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6403F7F5E4@DEMUEXC006.nsn-intra.net> In-Reply-To: <20120628151851.GD56180@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Coma] (no subject) Thread-Index: Ac1VQVaY6w8eFDCmSRGWO8JpmJw/nAAlj4Tg References: <00b101cd5508$22e90bd0$68bb2370$@cn> <20120628151851.GD56180@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" , "Yan Wang" X-OriginalArrivalTime: 29 Jun 2012 09:15:17.0413 (UTC) FILETIME=[B3104550:01CD55D7] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2606 X-purgate-ID: 151667::1340961318-00003CDD-2BF1E29C/0-0/0-0 Cc: coma@ietf.org Subject: Re: [Coma] (no subject) X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 09:15:25 -0000 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,=20 Mehmet=20 > -----Original Message----- > From: coma-bounces@ietf.org [mailto:coma-bounces@ietf.org] On Behalf Of ext > Juergen Schoenwaelder > Sent: Thursday, June 28, 2012 5:19 PM > To: Yan Wang > Cc: coma@ietf.org > Subject: Re: [Coma] (no subject) >=20 > On Thu, Jun 28, 2012 at 04:29:29PM +0800, Yan Wang wrote: >=20 > > 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. >=20 > 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: >=20 > > What the relationship between coma and core, coma and lwig? >=20 > 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. >=20 > 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. >=20 > 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. ;-) >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Coma mailing list > Coma@ietf.org > https://www.ietf.org/mailman/listinfo/coma Return-Path: X-Original-To: coma@ietfa.amsl.com Delivered-To: coma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C27F121F85E4 for ; Thu, 28 Jun 2012 08:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.198 X-Spam-Level: X-Spam-Status: No, score=-103.198 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnGUySZB-48C for ; Thu, 28 Jun 2012 08:18:53 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id E7DB121F85C9 for ; Thu, 28 Jun 2012 08:18:52 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4952820C2D; Thu, 28 Jun 2012 17:18:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 41a5Jnr1VH6Q; Thu, 28 Jun 2012 17:18:52 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E341520C29; Thu, 28 Jun 2012 17:18:51 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 86B77202F439; Thu, 28 Jun 2012 17:18:51 +0200 (CEST) Date: Thu, 28 Jun 2012 17:18:51 +0200 From: Juergen Schoenwaelder To: Yan Wang Message-ID: <20120628151851.GD56180@elstar.local> Mail-Followup-To: Yan Wang , coma@ietf.org References: <00b101cd5508$22e90bd0$68bb2370$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00b101cd5508$22e90bd0$68bb2370$@cn> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: coma@ietf.org Subject: Re: [Coma] (no subject) X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 15:18:53 -0000 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: > 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 Return-Path: X-Original-To: coma@ietfa.amsl.com Delivered-To: coma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D65C321F84BD for ; Thu, 28 Jun 2012 06:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y+y+JQHywwIn for ; Thu, 28 Jun 2012 06:14:43 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 96D3821F84B9 for ; Thu, 28 Jun 2012 06:14:38 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: ywang@cnnic.cn Received: from unknown127.0.0.1 (HELO cnnicpc) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 28 Jun 2012 16:29:28 +0800 From: "Yan Wang" To: Date: Thu, 28 Jun 2012 16:29:29 +0800 Message-ID: <00b101cd5508$22e90bd0$68bb2370$@cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B2_01CD554B.310C4BD0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1VCCKf7pVbX/gNQSaDYC70MAfz6w== Content-Language: zh-cn Subject: [Coma] (no subject) X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 13:14:44 -0000 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

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-- Return-Path: X-Original-To: coma@ietfa.amsl.com Delivered-To: coma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8172B21F85AD for ; Tue, 19 Jun 2012 03:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.489 X-Spam-Level: X-Spam-Status: No, score=-106.489 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQ6UN7t+cIxE for ; Tue, 19 Jun 2012 03:22:08 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 6C56D21F85A8 for ; Tue, 19 Jun 2012 03:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q5JALxB5001978 for ; Tue, 19 Jun 2012 12:21:59 +0200 (CEST) Received: from [192.168.217.105] (p54894F25.dip.t-dialin.net [84.137.79.37]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5A87436E; Tue, 19 Jun 2012 12:21:59 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Jun 2012 12:21:58 +0200 To: coma@ietf.org Message-Id: <9E4373D9-7360-45D4-BF41-B3BBCAD804FD@tzi.org> Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [Coma] One venue to discuss coma... X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 10:22:09 -0000 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=C3=BC=C3=9Fe, 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 =E2=80=9Csmart objects=E2=80=9D= 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: =E2=97=8F Energy-efficient, self-organized access and routing = schemes for smart object systems =E2=97=8F Testbeds and experimental evaluation of services based on = smart objects =E2=97=8F Service and application management platforms for a = variety of applications, e.g. smart cities =E2=97=8F Autonomic network monitoring and management for smart = object networks =E2=97=8F 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=C3=BChleisen, Hamburg University of Technology, Germany Bernd-Ludwig Wenning, Cork Institute of Technology, Ireland=20 Steering Committee Ramon Aguero, University of Cantabria, Spain Carsten Bormann, Universit=C3=A4t 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= Return-Path: X-Original-To: coma@ietfa.amsl.com Delivered-To: coma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3AB21F8589 for ; Wed, 13 Jun 2012 15:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6swJClcyT-O1 for ; Wed, 13 Jun 2012 15:56:40 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id D3CAF21F8582 for ; Wed, 13 Jun 2012 15:56:40 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so2938739pbc.31 for ; Wed, 13 Jun 2012 15:56:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=3Ao5Siv3Fscox/Jmy892J+HToMZ62Rfzyv4nl8Izc/s=; b=f2pdw78rqpeOZ9Pkb4FXy0FyZUkWHORNqFgbwQf5uiuBx9qXY4XCyCIb9QHEgyRn// R/67Hqtn6iwoAnILSLVGiwxBltnWCDuM/Jicrai9xSCfoo16N4F5omS17qVclBy/FxN6 WMMz3U7kaDnUJ1pY5wSAasydL71HgBiyTgDiQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=3Ao5Siv3Fscox/Jmy892J+HToMZ62Rfzyv4nl8Izc/s=; b=ohEccwl2JBGhjrzhKc1bBC/pViaiMsDJtz7CerYtOm18LTiyEJ3BxbLGYfCV7Dnt+2 YsHUUnqmWs1U4t40/XnuEEExMy1m4nZ8UtoMIV9z1Fr8tmNAZHf0bcBSUReTvOxHv+69 mK9Gy8w6vugqkietwsM9jmsYaIJg8EWhkuMfFIJDM9aDepSw6TRghRHhg23uDx4z7OCK RL0OyycVigPAarUPMpQPsIgDq6C2a7EG7IiOFiBzekT9V3h1UuB43vu0o7TtO0I/SEKT ItytME5MP0tW1nXq/6cgAqGPPHtQhyKQ/+6neL+8+IzWgfY9g79pALUBLMpDkNFWBUJE uhLw== Received: by 10.68.131.101 with SMTP id ol5mr827913pbb.41.1339628200604; Wed, 13 Jun 2012 15:56:40 -0700 (PDT) Received: from [10.2.4.83] ([64.9.249.121]) by mx.google.com with ESMTPS id u5sm7194113pbu.76.2012.06.13.15.56.38 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Jun 2012 15:56:38 -0700 (PDT) References: <2806342D-A112-4727-A584-4295E141B3E0@iii.ca> <20120608072625.GA5539@blackbox> <80A0822C5E9A4440A5117C2F4CD36A6403E538DF@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6403E538DF@DEMUEXC006.nsn-intra.net> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (9B206) From: Ulrich Herberg Date: Wed, 13 Jun 2012 15:56:40 -0700 To: "Ersue, Mehmet (NSN - DE/Munich)" X-Gm-Message-State: ALoCoQnuT5jO5+0yBxoRU2mx007sQeq/VwimjExOzwlSBnyGf1nUENfAzFKNUHtkSZ8cKCDRa3+f Cc: ext Johannes Gilger , "coma@ietf.org" , Cullen Jennings Subject: Re: [Coma] If all you had was an LED ... X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 22:56:41 -0000 Hi, On Jun 13, 2012, at 11:20, "Ersue, Mehmet (NSN - DE/Munich)" wrote: > Hi Cullen, Johannes, > [...] >=20 >> 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. >=20 > I think the management of security should be in our focus. Though what man= agement of security covers is open for discussion. Right. What I wonder is if the network topology and the kind of link layer h= ave an influence, e.g., if keys for certain L2 are to be exchanged (or shoul= d we focus on layer 3+ only? But sometimes, they same keys could be used at m= ultiple layers...). The topology may matter, e.g., in case of MANETs, since a= t the time of bootstrapping security credentials, routing may not be establi= shed (chicken/egg problem). But in essence, managing security bootstrapping is interesting, and I believ= e in focus for this discussion. Best Ulrich >=20 > Cheers, > Mehmet >=20 >=20 >=20 > _______________________________________________ > Coma mailing list > Coma@ietf.org > https://www.ietf.org/mailman/listinfo/coma Return-Path: X-Original-To: coma@ietfa.amsl.com Delivered-To: coma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A656011E8098 for ; Wed, 13 Jun 2012 14:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pGRIMgYycMd for ; Wed, 13 Jun 2012 14:25:51 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 47A9311E8097 for ; Wed, 13 Jun 2012 14:25:51 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q5DHojlc015756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Jun 2012 19:50:47 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q5DHogxc019659; Wed, 13 Jun 2012 19:50:42 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Jun 2012 19:50:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Jun 2012 19:50:41 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6403E538D9@DEMUEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Coma] Possible topics? Thread-Index: Ac1Fvf8PlZIPOBZ1RBylmDZzEQiMcQC1xN+g References: <80A0822C5E9A4440A5117C2F4CD36A6403DFB85C@DEMUEXC006.nsn-intra.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Ulrich Herberg" , X-OriginalArrivalTime: 13 Jun 2012 17:50:42.0652 (UTC) FILETIME=[0D5541C0:01CD498D] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 7407 X-purgate-ID: 151667::1339609847-0000425E-0EB7CE75/0-0/0-0 Subject: Re: [Coma] Possible topics? X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 21:25:52 -0000 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. >=20 > 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. =20 > > > >> - 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. >=20 > 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. =20 > > > >> - Do we need efficient, reliable multicast (like NORM, but > >> lightweight) to distribute control traffic more efficiently? >=20 > 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. =20 > >> - Can we provide sufficient levels of security without putting too > >> much burden on constrained devices? Which authentication modes do we > >> need? >=20 > 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 , class devices 1 > MUST in addition support , ..."). 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? >=20 > 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. =20 > >> - Will there be a mapping to existing management protocols like SNMP > >> for border gateways? >=20 > 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?) >=20 > 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. =20 > > Good questions. It would be helpful if you could start a discussion by > > stating why you think these should be requirements on constrained > > networks. >=20 > 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. >=20 > 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. =20 > Best > Ulrich Cheers, Mehmet Return-Path: X-Original-To: coma@ietfa.amsl.com Delivered-To: coma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9921B21F846F for ; Wed, 13 Jun 2012 14:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nI1ewAMZ0Yir for ; Wed, 13 Jun 2012 14:22:48 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC7421F8472 for ; Wed, 13 Jun 2012 14:22:43 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q5DIKZ8N020453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Jun 2012 20:20:35 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q5DIKZmf032507; Wed, 13 Jun 2012 20:20:35 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Jun 2012 20:20:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 13 Jun 2012 20:20:34 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6403E538DF@DEMUEXC006.nsn-intra.net> In-Reply-To: <20120608072625.GA5539@blackbox> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Coma] If all you had was an LED ... Thread-Index: Ac1FSAVFmVbEbmXqTNSlufwv/LknwwAI77fQ References: <2806342D-A112-4727-A584-4295E141B3E0@iii.ca> <20120608072625.GA5539@blackbox> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Johannes Gilger" , "Cullen Jennings" X-OriginalArrivalTime: 13 Jun 2012 18:20:35.0060 (UTC) FILETIME=[39B10340:01CD4991] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1130 X-purgate-ID: 151667::1339611635-0000425E-0C5D4A20/0-0/0-0 Cc: coma@ietf.org Subject: Re: [Coma] If all you had was an LED ... X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 21:22:50 -0000 SGkgQ3VsbGVuLCBKb2hhbm5lcywNCg0KPiA+IExvdHMgb2YgZXhpc3Rpbmcgc3R1ZmYgYmxpbmtz IHRoZW0gaW4gdmFyaW91cyB3YXlzIHRvIGluZGljYXRlIGRpZmZlcmVudCBzdGF0ZXMgb2YgdGhl DQo+ID4gbmV0d29yayAobm8gY2FycmllciwgY29ubmVjdGVkIGJ1dCBubyBJUCwgZXRjKS4gV291 bGQgaXQgbWFrZSBzZW5zZSB0byBoYXZlIHNvbWUNCj4gPiBzdGFuZGFyZGl6ZWQgcmVjb21tZW5k YXRpb24gYWJvdXQgdGhpcz8NCg0KQmFzZWQgb24gdGhlIG1hbmlmb2xkIHNlbnNvciBkZXZpY2Vz IGFuZCB0aGUgbmVlZGVkIGludGVyb3BlcmFiaWxpdHkgZm9yIGRhdGEgZXhjaGFuZ2UsIGl0IHdv dWxkIGJlIHVzZWZ1bCB0byBoYXZlIGEgY29tbW9uIGludGVycHJldGF0aW9uIGZvciB0aGUgZGlm ZmVyZW50IHN0YXRlcyAoc3RhbmRhcmQgbW9kZWw/KSByZWxldmFudCB0byB0aGUgbWFuYWdlbWVu dCBvZiB0aGVzZSBkZXZpY2VzLiANCg0KPiBUaGlzIGFsc28gYnJpbmdzIG1lIHRvIHRoZSBxdWVz dGlvbiBvZiBob3cgbXVjaCB0aGlzIGxpc3QNCj4gd2lsbCB0b3VjaCBpbnRvIG1hbmFnZW1lbnQg b2Ygc2VjdXJpdHksIGkuZS4gYm9vdHN0cmFwcGluZyBvZiBzZWN1cml0eQ0KPiBhc3NvY2lhdGlv bnMsIHNldHRpbmcgb2YgYWNjZXNzIGNvbnRyb2wgcmlnaHRzLCBldGMuDQoNCkkgdGhpbmsgdGhl IG1hbmFnZW1lbnQgb2Ygc2VjdXJpdHkgc2hvdWxkIGJlIGluIG91ciBmb2N1cy4gVGhvdWdoIHdo YXQgbWFuYWdlbWVudCBvZiBzZWN1cml0eSBjb3ZlcnMgaXMgb3BlbiBmb3IgZGlzY3Vzc2lvbi4N Cg0KQ2hlZXJzLA0KTWVobWV0DQoNCg0KDQo= Return-Path: X-Original-To: coma@ietfa.amsl.com Delivered-To: coma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD37211E81A6 for ; Fri, 8 Jun 2012 14:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.396, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6ZRQPKfu5Tp for ; Fri, 8 Jun 2012 14:30:58 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id C61DF11E80AA for ; Fri, 8 Jun 2012 14:30:57 -0700 (PDT) Received: by yhq56 with SMTP id 56so1924143yhq.31 for ; Fri, 08 Jun 2012 14:30:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fQfEOd/vz40SBVney0bqBIk8L+hZX2IsrP/ZECk2E8s=; b=jTuOsX0qYaAW8jCXry1HhSXTxDUz1T/JoQIZSIs21oMt05ErgYUJYubsD9Gf8suSKk dldOoumlZtV2q17/O7aA9a2hOW3kZam5cMI9JL4kgXzbqYuvU7kBXtw/ijLuEYBsFYGP /eUhkzzTKbd2kjYtNgXXar8JJT/SsPp/R4KU4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=fQfEOd/vz40SBVney0bqBIk8L+hZX2IsrP/ZECk2E8s=; b=i6QLt/1uorlWhT4JVIlaEyqUHRgqB6aCnS1KSZTIy3P1b8PjAcQ3uFew/W9/+mQ3nS VFDydexW047jwdUeKyIKXR1hj2hFaQDz4QOScuEvb/GryXBUNGqZ9vcwvvF85pSBuEdq cbKEj4GnmBcbtljHJlsHoWX5icKicH31jck7wyXURVwjXuAS4mHXqCLeg5cvTT5n1iVc 2iPVpiwVQaKeFoCgOd0TFiAwngQqvtxOrhwyjklRTcUvnkBJBjiVc0DjPi6DYzJs+BMJ Hl5HNVxl2LrMgCvi/xSKs5wBJ3o6Qos6HmtjpZU7u0n6tpUIp6cQ6ajHiBTpHeNoZO8P xgNw== MIME-Version: 1.0 Received: by 10.236.190.104 with SMTP id d68mr9750856yhn.7.1339191057226; Fri, 08 Jun 2012 14:30:57 -0700 (PDT) Received: by 10.146.248.21 with HTTP; Fri, 8 Jun 2012 14:30:57 -0700 (PDT) In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6403DFB85C@DEMUEXC006.nsn-intra.net> References: <80A0822C5E9A4440A5117C2F4CD36A6403DFB85C@DEMUEXC006.nsn-intra.net> Date: Fri, 8 Jun 2012 14:30:57 -0700 Message-ID: From: Ulrich Herberg To: "Ersue, Mehmet (NSN - DE/Munich)" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnNEfP3+OdyIpvEeRPOZqh4VKbnwQ5r02b6sZD5QnpgHkfjTXM+qSq87KqTDcbJVJO98JZf Cc: coma@ietf.org Subject: Re: [Coma] Possible topics? X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 21:30:59 -0000 Hi Mehmet, please see my answer inline. On Fri, Jun 8, 2012 at 4:27 AM, Ersue, Mehmet (NSN - DE/Munich) 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 , class devices 1 MUST in addition support , ..."). >> - 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 Return-Path: X-Original-To: coma@ietfa.amsl.com Delivered-To: coma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7644921F889B for ; Fri, 8 Jun 2012 06:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.298 X-Spam-Level: X-Spam-Status: No, score=-106.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpphZs5fNDOk for ; Fri, 8 Jun 2012 06:02:10 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBF321F8872 for ; Fri, 8 Jun 2012 06:02:09 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q58D27Mj019432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Jun 2012 15:02:07 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q58D27Gi003863; Fri, 8 Jun 2012 15:02:07 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Jun 2012 15:02:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD4576.E839B4DF" Date: Fri, 8 Jun 2012 15:02:06 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6403DFB8BD@DEMUEXC006.nsn-intra.net> In-Reply-To: <83C941F7F59F3F42AC017AD1E650546206BFB090@GDUKADH850.uk1.r-org.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Coma] Reprogramming Protocols Thread-Index: Ac1Fc5UBo1X6J4eTSCi4A/yrOIdUnAAAlDEA References: <83C941F7F59F3F42AC017AD1E650546206BFB090@GDUKADH850.uk1.r-org.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: , X-OriginalArrivalTime: 08 Jun 2012 13:02:07.0367 (UTC) FILETIME=[E88DB170:01CD4576] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 8926 X-purgate-ID: 151667::1339160527-00003CDD-1CC9EC0F/0-0/0-0 Subject: Re: [Coma] Reprogramming Protocols X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 13:02:11 -0000 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, =20 this could be seen under the SW/firmware distribution, however reprogramming protocol code is a device specific logic and not a management task. =20 Cheers,=20 Mehmet=20 =20 From: coma-bounces@ietf.org [mailto:coma-bounces@ietf.org] On Behalf Of ext Jonathan.Hansford@generaldynamics.uk.com Sent: Friday, June 08, 2012 2:38 PM To: coma@ietf.org Subject: [Coma] Reprogramming Protocols =20 Hi, =20 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? =20 Thanks, =20 Jonathan =20 ________________________________ 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.=20 ------_=_NextPart_001_01CD4576.E839B4DF Content-Type: text/html; 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:= = coma-bounces@ietf.org [mailto:coma-bounces@ietf.org] On Behalf Of = ext Jonathan.Hansford@generaldynamics.uk.com
Sent: Friday, = June 08, 2012 2:38 PM
To: coma@ietf.org
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,<= /o:p>

 

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-- Return-Path: X-Original-To: coma@ietfa.amsl.com Delivered-To: coma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B495221F8711 for ; Fri, 8 Jun 2012 05:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.366 X-Spam-Level: X-Spam-Status: No, score=-4.366 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gyk+lx3b+g+d for ; Fri, 8 Jun 2012 05:43:38 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.98]) by ietfa.amsl.com (Postfix) with ESMTP id B6BF421F872E for ; Fri, 8 Jun 2012 05:43:37 -0700 (PDT) Received: from [194.106.220.51:30623] by server-4.bemta-14.messagelabs.com id AE/4D-27598-173F1DF4; Fri, 08 Jun 2012 12:43:29 +0000 X-Env-Sender: Jonathan.Hansford@generaldynamics.uk.com X-Msg-Ref: server-3.tower-92.messagelabs.com!1339159408!14020885!1 X-Originating-IP: [217.33.196.17] X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20285 invoked from network); 8 Jun 2012 12:43:28 -0000 Received: from unknown (HELO mail.generaldynamics.uk.com) (217.33.196.17) by server-3.tower-92.messagelabs.com with SMTP; 8 Jun 2012 12:43:28 -0000 Received: from mail.compd.com (HELO gdukadh864.uk1.r-org.net) ([172.16.40.142]) by mail.generaldynamics.uk.com with ESMTP; 08 Jun 2012 13:38:21 +0100 Received: from GDUKADH850.uk1.r-org.net ([172.16.40.138]) by gdukadh864.uk1.r-org.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Jun 2012 13:38:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD4573.955D1909" Date: Fri, 8 Jun 2012 13:38:18 +0100 Message-ID: <83C941F7F59F3F42AC017AD1E650546206BFB090@GDUKADH850.uk1.r-org.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reprogramming Protocols Thread-Index: Ac1Fc5UBo1X6J4eTSCi4A/yrOIdUnA== From: To: X-OriginalArrivalTime: 08 Jun 2012 12:38:20.0839 (UTC) FILETIME=[9646CB70:01CD4573] Subject: [Coma] Reprogramming Protocols X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 12:43:39 -0000 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, =20 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? =20 Thanks, =20 Jonathan =20 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 sho= uld not disclose, distribute, print, copy or make other use of this email= or its attachments. Such actions, in fact, may be unlawful. In complianc= e with the various Regulations and Acts, General Dynamics United Kingdom = Limited reserves the right to monitor (and examine for viruses) all email= s and email attachments, both inbound and outbound. Email communications = and their attachments may not be secure or error- or virus-free and the c= ompany does not accept liability or responsibility for such matters or th= e consequences thereof. General Dynamics United Kingdom Limited, Register= ed Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and= Wales No: 1911653.=20 ------_=_NextPart_001_01CD4573.955D1909 Content-Type: text/HTML; charset="us-ascii" Content-Transfer-Encoding: 7bit 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-- Return-Path: X-Original-To: coma@ietfa.amsl.com Delivered-To: coma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D456E21F8786 for ; Fri, 8 Jun 2012 04:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NiEjJy+z70Y for ; Fri, 8 Jun 2012 04:28:42 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE0321F86D0 for ; Fri, 8 Jun 2012 04:28:41 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q58BSbC2002290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Jun 2012 13:28:37 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q58BSaLg011250; Fri, 8 Jun 2012 13:28:37 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Jun 2012 13:28:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Jun 2012 13:28:20 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6403DFB85E@DEMUEXC006.nsn-intra.net> In-Reply-To: <67442429D9C35E4C975B89BE73BD33D02F22348F75@ATLEXCH02.nivis.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Coma] Constrained Device Classes 0, 1 and 2 and their need for Management Thread-Index: Ac1DxeGWM2hM7v/hS5e+E9As69z5CgAYdD+AAE8LYSA= References: <80A0822C5E9A4440A5117C2F4CD36A6403DFB0D5@DEMUEXC006.nsn-intra.net><20120606092217.GA89893@elstar.local> <67442429D9C35E4C975B89BE73BD33D02F22348F75@ATLEXCH02.nivis.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Rares Ivan" , X-OriginalArrivalTime: 08 Jun 2012 11:28:22.0590 (UTC) FILETIME=[CFECD5E0:01CD4569] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 6038 X-purgate-ID: 151667::1339154918-00003CDD-EFF1E4B3/0-0/0-0 Subject: Re: [Coma] Constrained Device Classes 0, 1 and 2 and their need for Management X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 11:28:44 -0000 Hi Rares, > Hello, >=20 > 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.=20 =20 > 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. >=20 > 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 =20 > Regards, > Rares > > -----Original Message----- > From: coma-bounces@ietf.org [mailto:coma-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Wednesday, June 06, 2012 5:22 AM > To: Ersue, Mehmet (NSN - DE/Munich) > Cc: coma@ietf.org > Subject: Re: [Coma] Constrained Device Classes 0, 1 and 2 and their need for > Management >=20 > 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. >=20 > 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. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Coma mailing list > Coma@ietf.org > https://www.ietf.org/mailman/listinfo/coma > _______________________________________________ > Coma mailing list > Coma@ietf.org > https://www.ietf.org/mailman/listinfo/coma Return-Path: X-Original-To: coma@ietfa.amsl.com Delivered-To: coma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C990521F86D0 for ; Fri, 8 Jun 2012 04:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kvm18Mb2XMl for ; Fri, 8 Jun 2012 04:27:13 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1F921F8786 for ; Fri, 8 Jun 2012 04:27:12 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q58BRA3Y015060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Jun 2012 13:27:10 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q58BRA2h032027; Fri, 8 Jun 2012 13:27:10 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Jun 2012 13:27:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Jun 2012 13:27:07 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6403DFB85C@DEMUEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Coma] Possible topics? Thread-Index: Ac1E9EMeYYi3Gq5ASv2jyh5hTEK4lgAaMPHQ References: From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Ulrich Herberg" , X-OriginalArrivalTime: 08 Jun 2012 11:27:10.0158 (UTC) FILETIME=[A4C096E0:01CD4569] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 3131 X-purgate-ID: 151667::1339154830-0000425E-1D5EE3FF/0-0/0-0 Subject: Re: [Coma] Possible topics? X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 11:27:14 -0000 Hi Ulrich, > I just discovered this mailing list. Some aspects I have in mind about > the topic of managing constrained devices and networks: >=20 > - 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 =20 >=20 >=20 > [Coma] Subject: New Non-WG Mailing List: coma -- Management of > Constrained Networks and Devices >=20 > From: IETF Secretariat > To: IETF Announcement List > 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 >=20 > A new IETF non-working group email list has been created. >=20 > List address: coma at ietf.org > Archive: http://www.ietf.org/mail-archive/web/coma/ > To subscribe: https://www.ietf.org/mailman/listinfo/coma >=20 > 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. >=20 > For additional information, please contact the list administrators. > _______________________________________________ > Coma mailing list > Coma@ietf.org > https://www.ietf.org/mailman/listinfo/coma Return-Path: X-Original-To: coma@ietfa.amsl.com Delivered-To: coma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2546E21F85E5 for ; Fri, 8 Jun 2012 04:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZWwUiiQiBri for ; Fri, 8 Jun 2012 04:06:57 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 0D98921F8582 for ; Fri, 8 Jun 2012 04:06:54 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q58B6r8E000830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Jun 2012 13:06:53 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q58B6rJI015855; Fri, 8 Jun 2012 13:06:53 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Jun 2012 13:06:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD4566.CD9E6095" Date: Fri, 8 Jun 2012 13:06:49 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6403DFB84E@DEMUEXC006.nsn-intra.net> In-Reply-To: <21853_1339013084_4FCFB7DC_21853_10870_1_11027135CD0DCE41B9C193E3D7257738EE73@PEXCVZYM12.corporate.adroot.infra.ftgroup> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Coma] (no subject) Thread-Index: Ac1EH5yYe7jjov2hS8OHDdlrqb9W9ABNz7dA References: <21853_1339013084_4FCFB7DC_21853_10870_1_11027135CD0DCE41B9C193E3D7257738EE73@PEXCVZYM12.corporate.adroot.infra.ftgroup> From: "Ersue, Mehmet (NSN - DE/Munich)" To: , X-OriginalArrivalTime: 08 Jun 2012 11:06:50.0916 (UTC) FILETIME=[CE070640:01CD4566] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 17047 X-purgate-ID: 151667::1339153613-0000425E-54A2173F/0-0/0-0 Subject: Re: [Coma] (no subject) X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 11:07:00 -0000 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, =20 your contribution as an operator is very valuable. =20 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. =20 Cheers,=20 Mehmet=20 =20 From: coma-bounces@ietf.org [mailto:coma-bounces@ietf.org] On Behalf Of ext tayeb.benmeriem@orange.com Sent: Wednesday, June 06, 2012 10:05 PM To: coma@ietf.org Subject: [Coma] (no subject) =20 Dear all, =20 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. =20 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.=20 =20 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. =20 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.=20 =20 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 =20 =20 Regards =20 Tayeb =20 =20 ________________________________________________________________________ _________________________________________________ =20 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. =20 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

= 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:= = coma-bounces@ietf.org [mailto:coma-bounces@ietf.org] = On Behalf Of ext tayeb.benmeriem@orange.com=
Sent: Wednesday, June 06, 2012 10:05 PM
To: coma@ietf.org
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-- Return-Path: X-Original-To: coma@ietfa.amsl.com Delivered-To: coma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 629E221F86B3 for ; Fri, 8 Jun 2012 00:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FUZZY_VLIUM=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hG3IlMhEE5Bw for ; Fri, 8 Jun 2012 00:26:23 -0700 (PDT) Received: from avalon.gnuzifer.de (avalon.gnuzifer.de [IPv6:2a01:4f8:121:43c1::a2:1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA7F21F85A2 for ; Fri, 8 Jun 2012 00:26:22 -0700 (PDT) Received: from [137.226.161.159] (port=59474 helo=localhost) by avalon.gnuzifer.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1SctaO-0004SK-It; Fri, 08 Jun 2012 09:26:20 +0200 Date: Fri, 8 Jun 2012 09:26:25 +0200 From: Johannes Gilger To: Cullen Jennings Message-ID: <20120608072625.GA5539@blackbox> References: <2806342D-A112-4727-A584-4295E141B3E0@iii.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2806342D-A112-4727-A584-4295E141B3E0@iii.ca> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: 137.226.161.159 X-SA-Exim-Mail-From: gilger@umic.rwth-aachen.de Cc: coma@ietf.org Subject: Re: [Coma] If all you had was an LED ... X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 07:26:24 -0000 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 Return-Path: X-Original-To: coma@ietfa.amsl.com Delivered-To: coma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9916111E8161 for ; Thu, 7 Jun 2012 17:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHe6wVY8Tlfz for ; Thu, 7 Jun 2012 17:38:27 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 22CCC11E8160 for ; Thu, 7 Jun 2012 17:38:27 -0700 (PDT) Received: from [10.86.252.76] (unknown [198.135.0.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6DEFC50A64 for ; Thu, 7 Jun 2012 20:38:20 -0400 (EDT) From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Jun 2012 11:40:12 -0700 Message-Id: <2806342D-A112-4727-A584-4295E141B3E0@iii.ca> To: coma@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [Coma] If all you had was an LED ... X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 00:38:27 -0000 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.=20 How would you use these 1 or two LEDs to help manage the device?=20 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?=20 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?=20 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.=20 Thoughts? Pointers to what existing systems do ? Thanks, Cullen Return-Path: X-Original-To: coma@ietfa.amsl.com Delivered-To: coma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4E621F873A for ; Thu, 7 Jun 2012 14:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.144 X-Spam-Level: X-Spam-Status: No, score=-101.144 tagged_above=-999 required=5 tests=[AWL=-0.959, BAYES_40=-0.185, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNEY+VjbhUdz for ; Thu, 7 Jun 2012 14:59:04 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACB621F8738 for ; Thu, 7 Jun 2012 14:58:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=R1iuvmdkk24t25DdSHE5fBMWgEoM2xw17F+O4ooX+WbSlRQ5eT5Q7HhOCmDhzm1W; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [76.254.48.130] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Sckj5-0004fX-QG for coma@ietf.org; Thu, 07 Jun 2012 17:58:44 -0400 Message-ID: <007301cd44f9$26170240$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <83C941F7F59F3F42AC017AD1E650546206BFAF43@GDUKADH850.uk1.r-org.net> Date: Thu, 7 Jun 2012 15:01:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8882951211ce6890f88dddcc0131caba89a440caaa94f0f5dea350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.48.130 Subject: Re: [Coma] Management of Constrained Networks and Devices X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 21:59:05 -0000 Hi - > From: > To: > 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 Return-Path: X-Original-To: coma@ietfa.amsl.com Delivered-To: coma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A65921F8625 for ; Thu, 7 Jun 2012 14:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoOxAFwuqkEY for ; Thu, 7 Jun 2012 14:26:49 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id DCCAE21F861E for ; Thu, 7 Jun 2012 14:26:48 -0700 (PDT) Received: by yhq56 with SMTP id 56so934649yhq.31 for ; Thu, 07 Jun 2012 14:26:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:date:message-id:subject:from:to:content-type; bh=V4PhLCeks/XdMeJBYuz1erdmsqd4+/VWF4FACA32SeI=; b=AxNGNpqI2OgDg2N+NVILUJSWsKeXIlvqNash+Er8nXxMKs87DSJCb4PZSsv65HAMQP 81s/XXYjHdkKUgJFHQxMXTYJzLODSPiThyN02xrAmEw0RiES1puIqNxhq+gZdoLD4zYe JJK3bXsRIdMJU8jIaBtmDIl3p/8gro7D8IZQ0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=V4PhLCeks/XdMeJBYuz1erdmsqd4+/VWF4FACA32SeI=; b=dc7y962u1gfznGPhd3pxDz8DWDYZ3CyKjyqM6FRk3CrOE4bgkqiLC8wWYhA5plCAN6 qNI+rM6y/3FBTj8wB2d3xaB/CJnPkiVwirzs5u9kewn2rfWIa5euJaAesh760Sq/1eW3 YZZsT0ZJCXT62Jr8BsRzv1CuPS+SKqcQYe2KDviPOhQ++pqXKxew+wciGW6AJkJGe6b0 /6esKSDZaSTIxylndhHSUZR6NTSxyTrWhH1e1PDzd1xRj/h4Rgq9LpCvOnrcMeXQnBD4 tr4owsOfXajJhCQm0gtHXGhjkPFRHxl3DhtyOay2KXAf5p4YnSUnQRakBxoPxanJwKpT zaGA== MIME-Version: 1.0 Received: by 10.236.165.74 with SMTP id d50mr3413109yhl.48.1339104408341; Thu, 07 Jun 2012 14:26:48 -0700 (PDT) Received: by 10.146.248.21 with HTTP; Thu, 7 Jun 2012 14:26:48 -0700 (PDT) Date: Thu, 7 Jun 2012 14:26:48 -0700 Message-ID: From: Ulrich Herberg To: coma@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlk9/p8dXfAF1CSvoqGk99mp7TJJgP8Pgn9lFIq06kJodk5rz9HSjQU0FCGlgFi85Kz1w70 Subject: [Coma] Possible topics? X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 21:26:50 -0000 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 To: IETF Announcement List 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 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. Return-Path: X-Original-To: coma@ietfa.amsl.com Delivered-To: coma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B30621F88BF for ; Thu, 7 Jun 2012 08:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E93tOoaLA8bg for ; Thu, 7 Jun 2012 08:07:00 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBA521F8683 for ; Thu, 7 Jun 2012 08:06:57 -0700 (PDT) Received: from [10.123.226.147] (pwlan.lfv.se [192.36.80.8] (may be forged)) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q57F6ppZ001751; Thu, 7 Jun 2012 18:06:53 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Zach Shelby In-Reply-To: <83C941F7F59F3F42AC017AD1E650546206BFAF43@GDUKADH850.uk1.r-org.net> Date: Thu, 7 Jun 2012 17:06:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <729E6954-094B-4795-BEDD-EE29D3EED2AB@sensinode.com> References: <83C941F7F59F3F42AC017AD1E650546206BFAF43@GDUKADH850.uk1.r-org.net> To: X-Mailer: Apple Mail (2.1084) Cc: coma@ietf.org Subject: Re: [Coma] Management of Constrained Networks and Devices X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 15:07:01 -0000 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.=20 So the discussion about Class 0, 1, 2 doesn't really explain the whole = story.=20 Zach On Jun 7, 2012, at 5:00 PM, = wrote: > Could someone clarify something for me please? > =20 > 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 =93and=94 a boolean, meaning neither = =93Unconstrained Devices on Constrained Networks=94 nor =93Constrained = Devices on Unconstrained Networks=94 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? --=20 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 Return-Path: X-Original-To: coma@ietfa.amsl.com Delivered-To: coma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2CC621F88FE for ; Thu, 7 Jun 2012 08:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.257 X-Spam-Level: X-Spam-Status: No, score=-4.257 tagged_above=-999 required=5 tests=[AWL=-0.674, BAYES_40=-0.185, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8yA+KhYXAgW for ; Thu, 7 Jun 2012 08:00:20 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.130]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3FF21F88F3 for ; Thu, 7 Jun 2012 08:00:19 -0700 (PDT) Received: from [85.158.136.35:25650] by server-3.bemta-5.messagelabs.com id 34/0B-17554-202C0DF4; Thu, 07 Jun 2012 15:00:18 +0000 X-Env-Sender: Jonathan.Hansford@generaldynamics.uk.com X-Msg-Ref: server-9.tower-125.messagelabs.com!1339081217!27663779!1 X-Originating-IP: [217.33.196.17] X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11478 invoked from network); 7 Jun 2012 15:00:17 -0000 Received: from unknown (HELO mail.generaldynamics.uk.com) (217.33.196.17) by server-9.tower-125.messagelabs.com with SMTP; 7 Jun 2012 15:00:17 -0000 Received: from mail.compd.com (HELO gdukadh864.uk1.r-org.net) ([172.16.40.142]) by mail.generaldynamics.uk.com with ESMTP; 07 Jun 2012 16:00:16 +0100 Received: from GDUKADH850.uk1.r-org.net ([172.16.40.138]) by gdukadh864.uk1.r-org.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Jun 2012 16:00:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD44BE.3A13195F" Date: Thu, 7 Jun 2012 16:00:16 +0100 Message-ID: <83C941F7F59F3F42AC017AD1E650546206BFAF43@GDUKADH850.uk1.r-org.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Management of Constrained Networks and Devices Thread-Index: Ac1Evj89LGW9yOuiRP6Y8q8jbEWSEQ== From: To: X-OriginalArrivalTime: 07 Jun 2012 15:00:17.0113 (UTC) FILETIME=[3FF55490:01CD44BE] Subject: [Coma] Management of Constrained Networks and Devices X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 15:00:22 -0000 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, =20 Could someone clarify something for me please?=20 =20 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? =20 Thanks, =20 Jonathan =20 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 sho= uld not disclose, distribute, print, copy or make other use of this email= or its attachments. Such actions, in fact, may be unlawful. In complianc= e with the various Regulations and Acts, General Dynamics United Kingdom = Limited reserves the right to monitor (and examine for viruses) all email= s and email attachments, both inbound and outbound. Email communications = and their attachments may not be secure or error- or virus-free and the c= ompany does not accept liability or responsibility for such matters or th= e consequences thereof. General Dynamics United Kingdom Limited, Register= ed Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and= Wales No: 1911653.=20 ------_=_NextPart_001_01CD44BE.3A13195F Content-Type: text/HTML; charset="us-ascii" Content-Transfer-Encoding: 7bit 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-- Return-Path: X-Original-To: coma@ietfa.amsl.com Delivered-To: coma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B2A21F864B for ; Wed, 6 Jun 2012 14:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6wuom+AmWql for ; Wed, 6 Jun 2012 14:20:41 -0700 (PDT) Received: from smtp.nivis.com (smtp.nivis.com [65.205.163.2]) by ietfa.amsl.com (Postfix) with ESMTP id D15E121F85A4 for ; Wed, 6 Jun 2012 14:20:40 -0700 (PDT) Received: from ATLEXCH02.nivis.com ([10.0.0.18]) by ATLEXCH02.nivis.com ([10.0.0.18]) with mapi; Wed, 6 Jun 2012 17:20:39 -0400 From: Rares Ivan To: "coma@ietf.org" Date: Wed, 6 Jun 2012 17:20:40 -0400 Thread-Topic: [Coma] Constrained Device Classes 0, 1 and 2 and their need for Management Thread-Index: Ac1DxeGWM2hM7v/hS5e+E9As69z5CgAYdD+A Message-ID: <67442429D9C35E4C975B89BE73BD33D02F22348F75@ATLEXCH02.nivis.com> References: <80A0822C5E9A4440A5117C2F4CD36A6403DFB0D5@DEMUEXC006.nsn-intra.net> <20120606092217.GA89893@elstar.local> In-Reply-To: <20120606092217.GA89893@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Coma] Constrained Device Classes 0, 1 and 2 and their need for Management X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 21:20:42 -0000 Hello, In my opinion the classification should not be directly connected to the ha= rdware capabilities of devices (like processing power, RAM, flash) just bec= ause same functional features can be supported on devices with very differe= nt hardware capabilities and architecture. There shouldn't be any mention o= f 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 C= lass-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 on= ly manage Class-2 devices based on features specific to Class-1, which is t= he manager's limitation. The higher the class, the more features a device supports, and based on thi= s classification a manager would know what the capabilities of a device sha= ll 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: coma-bounces@ietf.org [mailto:coma-bounces@ietf.org] On Behalf Of Jue= rgen Schoenwaelder Sent: Wednesday, June 06, 2012 5:22 AM To: Ersue, Mehmet (NSN - DE/Munich) Cc: coma@ietf.org Subject: Re: [Coma] Constrained Device Classes 0, 1 and 2 and their need fo= r Management On Wed, Jun 06, 2012 at 10:42:13AM +0200, Ersue, Mehmet (NSN - DE/Munich) w= rote: > Hi All, >=20 > following is an attempt to define the device classes in constrained=20 > networks a bit more in detail. The text below follows the definition=20 > of the three device classes provided by Carsten. >=20 > Class-0 (C0) devices are very constrained sensor-like motes. They will=20 > most likely not have the possibility to have a direct communications=20 > with the Internet in a secure manner. These class-0 devices will=20 > participate in Internet communications with the help of larger devices=20 > acting as proxy or gateways. >=20 > Class-1 (C1) devices are assumed to have about 10 Kbytes of RAM and=20 > roughly 100 Kbytes of code space (e.g. Flash). For example, this could=20 > be an AVR Raven mote (http://www.atmel.com/tools/AVRRAVEN.aspx).=20 > Class-1 devices can't easily talk to other Internet nodes with a full=20 > protocol stack using HTTP, TLS and related security protocols, and=20 > XML-based data representations. However, they have enough power to use=20 > a reduced or lightweight protocol stack (e.g. with CoAP and UDP) and=20 > participate in meaningful conversations without the help of a gateway=20 > node. So they can be integrated into the IoT network in one way or the=20 > other but need to spare with memory for the protocol and application usag= e. >=20 > Class-2 (C2) devices are embedded devices with around 50 Kbytes of RAM=20 > and maybe 250 Kbytes of code space and can support mostly the same=20 > protocol stack as used on notebooks or servers. However, even these=20 > devices can benefit from lightweight and energy-efficient protocols=20 > and producing less bandwidth on air. Furthermore, using less network=20 > resources would leave more resources available to applications. As=20 > such using the same protocol stack on Class 1 and 2 devices might be=20 > beneficial. >=20 > I assume we cannot do much for the management on C0 devices. They will=20 > be most likely preconfigured and if ever will be reconfigured seldomly=20 > with a very small data set. >=20 > For C1 devices it is indeed subject for discussion and to understand=20 > what type of applications they could run and which management=20 > mechanisms would be most suitable. > Even though they have some more functionality available we need to=20 > assess C2 devices for the type of applications they will be running=20 > and the management they would need. To be able to derive the=20 > requirements we need to discuss the uses cases and how the devices are=20 > involved in the management scenario. The use cases where C1 or C2=20 > devices build a cluster or are part of a hierarchy as well as the=20 > assumed degree of automation might be essentially important. >=20 > Comments are welcome. This classification is very rough since devices differ in their architectur= e. For example, some devices can run their software right out of flash memo= ry 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 b= efore they can execute it. Such devices have relatively large amounts of RA= M but most of it is used to store machine code. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Coma mailing list Coma@ietf.org https://www.ietf.org/mailman/listinfo/coma Return-Path: X-Original-To: coma@ietfa.amsl.com Delivered-To: coma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C2F21F84B6 for ; Wed, 6 Jun 2012 13:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.717 X-Spam-Level: X-Spam-Status: No, score=-1.717 tagged_above=-999 required=5 tests=[AWL=-0.881, BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_SUBJECT=1.762, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z80W1qL3x3TM for ; Wed, 6 Jun 2012 13:04:46 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0BC11E80B2 for ; Wed, 6 Jun 2012 13:04:46 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id ED69A2DC4CA for ; Wed, 6 Jun 2012 22:04:44 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id D2D8A35C045 for ; Wed, 6 Jun 2012 22:04:44 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Wed, 6 Jun 2012 22:04:44 +0200 From: To: "coma@ietf.org" Thread-Index: Ac1EH5yYe7jjov2hS8OHDdlrqb9W9A== Date: Wed, 6 Jun 2012 20:04:43 +0000 Message-ID: <21853_1339013084_4FCFB7DC_21853_10870_1_11027135CD0DCE41B9C193E3D7257738EE73@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: multipart/alternative; boundary="_000_11027135CD0DCE41B9C193E3D7257738EE73PEXCVZYM12corporate_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.6.192415 Subject: [Coma] (no subject) X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 20:04:48 -0000 --_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 the= ir particular environment are auto-configuration which is addressed by desi= gn. When it comes to standardization for sure there is some work to do acco= rdingly. 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 fo= r managing (configuration) of HomeNodeB and HomeeNodeBs. Netconf and its as= sociated 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 th= en we address the technical solutions. That means, we should look at the ve= rtical market needs (Health, Digital Home, ...) in terms of expectation of = SLAs. Then the question is how to translate these SLAs into SLOs, metrics a= nd how to track, measure, collect and report them (the needed management mo= dels 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 t= his constrained devices and network, or should designnew ones as IETF did f= or 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 confiden= tielles 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 el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. --_000_11027135CD0DCE41B9C193E3D7257738EE73PEXCVZYM12corporate_ Content-Type: text/html; 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 re= lated to the management aspect of such devices in their particular environm= ent 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 environmen= t, could be Fixed or Mobile networks, the Home Gateway and its attached dev= ices, BBF protocol TR-69 is adopted and used for managing (configuration) o= f 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 associa= ted 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, metri= cs and how to track, measure, collect and report them (the needed managemen= t 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 confiden=
tielles 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 el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation 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 dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.
--_000_11027135CD0DCE41B9C193E3D7257738EE73PEXCVZYM12corporate_-- Return-Path: X-Original-To: coma@ietfa.amsl.com Delivered-To: coma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96DC721F8873 for ; Wed, 6 Jun 2012 02:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z05nemZMsqhO for ; Wed, 6 Jun 2012 02:22:19 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE7421F8872 for ; Wed, 6 Jun 2012 02:22:19 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 538FE20C14; Wed, 6 Jun 2012 11:22:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id s3gM7jxlEUSn; Wed, 6 Jun 2012 11:22:18 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D086420AFE; Wed, 6 Jun 2012 11:22:17 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BBC431FB07C4; Wed, 6 Jun 2012 11:22:17 +0200 (CEST) Date: Wed, 6 Jun 2012 11:22:17 +0200 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20120606092217.GA89893@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , coma@ietf.org References: <80A0822C5E9A4440A5117C2F4CD36A6403DFB0D5@DEMUEXC006.nsn-intra.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6403DFB0D5@DEMUEXC006.nsn-intra.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: coma@ietf.org Subject: Re: [Coma] Constrained Device Classes 0, 1 and 2 and their need for Management X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 09:22:20 -0000 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 Return-Path: X-Original-To: coma@ietfa.amsl.com Delivered-To: coma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C6C21F85AF for ; Wed, 6 Jun 2012 01:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Ki3pYoB5ic7 for ; Wed, 6 Jun 2012 01:52:20 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id D7A8721F86BA for ; Wed, 6 Jun 2012 01:52:19 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q568qIMF020149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Jun 2012 10:52:18 +0200 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q568qBG3024165; Wed, 6 Jun 2012 10:52:18 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Jun 2012 10:52:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Jun 2012 10:52:10 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6403DFB0EE@DEMUEXC006.nsn-intra.net> In-Reply-To: <20120605120503.GA87941@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Coma] New Maillist for the discussion on the Management of Constrained Networks and Devices Thread-Index: Ac1DE3czJ33mESF7TOiYp7tkG5FBZQArNNVA References: <80A0822C5E9A4440A5117C2F4CD36A6403D56943@DEMUEXC006.nsn-intra.net> <4FC8CFEB.6040902@cisco.com> <341929CE-3341-41EC-A472-1213B6F8C320@sensinode.com> <80A0822C5E9A4440A5117C2F4CD36A6403D9AB54@DEMUEXC006.nsn-intra.net> <20120605120503.GA87941@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" X-OriginalArrivalTime: 06 Jun 2012 08:52:11.0692 (UTC) FILETIME=[A99BC6C0:01CD43C1] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 919 X-purgate-ID: 151667::1338972738-0000425E-C033978B/0-0/0-0 Cc: ext Antonio Jara , Zach Shelby , coma@ietf.org Subject: Re: [Coma] New Maillist for the discussion on the Management of Constrained Networks and Devices X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 08:52:21 -0000 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 Return-Path: X-Original-To: coma@ietfa.amsl.com Delivered-To: coma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B2F21F86AD for ; Wed, 6 Jun 2012 01:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byUlflpc9ZLx for ; Wed, 6 Jun 2012 01:42:20 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 91CBD21F86AA for ; Wed, 6 Jun 2012 01:42:20 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q568gF59026770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 6 Jun 2012 10:42:15 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q568gFt0020568 for ; Wed, 6 Jun 2012 10:42:15 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Jun 2012 10:42:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Jun 2012 10:42:13 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6403DFB0D5@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Constrained Device Classes 0, 1 and 2 and their need for Management Thread-Index: Ac1DwEUD8febgWegSgq+hs2ifloHKA== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 06 Jun 2012 08:42:14.0955 (UTC) FILETIME=[45ECEFB0:01CD43C0] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2591 X-purgate-ID: 151667::1338972136-00003CDD-95223929/0-0/0-0 Subject: [Coma] Constrained Device Classes 0, 1 and 2 and their need for Management X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 08:42:21 -0000 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.=20 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,=20 Mehmet=20 Return-Path: X-Original-To: coma@ietfa.amsl.com Delivered-To: coma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2305921F8528 for ; Tue, 5 Jun 2012 05:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+SyVgSAmCfS for ; Tue, 5 Jun 2012 05:05:09 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 148A121F85EE for ; Tue, 5 Jun 2012 05:05:09 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id DF2B820BE7; Tue, 5 Jun 2012 14:05:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 4tUPji-_wXWm; Tue, 5 Jun 2012 14:05:07 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 18B5820B6C; Tue, 5 Jun 2012 14:05:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1DFF11FAF873; Tue, 5 Jun 2012 14:05:05 +0200 (CEST) Date: Tue, 5 Jun 2012 14:05:05 +0200 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20120605120503.GA87941@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , ext Antonio Jara , Zach Shelby , Benoit Claise , Ron Bonica , coma@ietf.org References: <80A0822C5E9A4440A5117C2F4CD36A6403D56943@DEMUEXC006.nsn-intra.net> <4FC8CFEB.6040902@cisco.com> <341929CE-3341-41EC-A472-1213B6F8C320@sensinode.com> <80A0822C5E9A4440A5117C2F4CD36A6403D9AB54@DEMUEXC006.nsn-intra.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6403D9AB54@DEMUEXC006.nsn-intra.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Benoit Claise , Ron Bonica , ext Antonio Jara , Zach Shelby , coma@ietf.org Subject: Re: [Coma] New Maillist for the discussion on the Management of Constrained Networks and Devices X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 12:05:10 -0000 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 Return-Path: X-Original-To: coma@ietfa.amsl.com Delivered-To: coma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE9B021F8679 for ; Tue, 5 Jun 2012 04:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DO372XydKlHJ for ; Tue, 5 Jun 2012 04:58:39 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 1A63621F8683 for ; Tue, 5 Jun 2012 04:58:38 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q55BwVsE025175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Jun 2012 13:58:31 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q55BwEmq015356; Tue, 5 Jun 2012 13:58:28 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Jun 2012 13:58:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Jun 2012 13:58:24 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6403D9AB54@DEMUEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Coma] New Maillist for the discussion on the Management of Constrained Networks and Devices Thread-Index: Ac1AA5Mj+BALgXecTE6PR+6FRsnmRwDDmLxg References: <80A0822C5E9A4440A5117C2F4CD36A6403D56943@DEMUEXC006.nsn-intra.net> <4FC8CFEB.6040902@cisco.com> <341929CE-3341-41EC-A472-1213B6F8C320@sensinode.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Antonio Jara" , "Zach Shelby" X-OriginalArrivalTime: 05 Jun 2012 11:58:26.0151 (UTC) FILETIME=[83B12770:01CD4312] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 7036 X-purgate-ID: 151667::1338897513-00001F01-8FC6CE37/0-0/0-0 Cc: Benoit Claise , Ron Bonica , coma@ietf.org Subject: Re: [Coma] New Maillist for the discussion on the Management of Constrained Networks and Devices X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 11:58:40 -0000 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=20 1.1. Overview 1.2. Basic scenarios in discussion 1.4. Constrained Device Classes=20 2. Terminology=20 3. Problem Statement=20 4. Requirements per Device Class=20 5. Security Considerations=20 6. Acknowledgments=20 7. References=20 Cheers,=20 Mehmet=20 > -----Original Message----- > From: ext Antonio Jara [mailto:jara@um.es] > Sent: Friday, June 01, 2012 4:33 PM > To: Zach Shelby > Cc: Benoit Claise; Ersue, Mehmet (NSN - DE/Munich); Ron Bonica; = coma@ietf.org > Subject: Re: [Coma] New Maillist for the discussion on the Management = of Constrained > Networks and Devices >=20 > So..., any ToC in mind?, where we can see that parts we can provide > some text and relevant information. >=20 >=20 > On Fri, Jun 1, 2012 at 4:24 PM, Zach Shelby = 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 =A0"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.: > >>> > >>> * =A0 =A0Do we need a new development for IoT management (i.e. > >>> constrained devices) at all? > >>> - =A0 =A0If yes, what is really needed as standard and what is an > >>> overkill? > >>> * =A0 =A0What type of devices can we support? > >>> * =A0 =A0How are the classes 0-2 for constrained devices defined = in > >>> detail? > >>> * =A0 =A0Is some simple configuration management already = sufficient? > >>> - =A0 =A0Or do we need also a simple fault management and = monitoring? > >>> * =A0 =A0What type of data model modules do we need to = standardize? > >>> - =A0 =A0Just a few core models like ip-cfg, interface? > >>> - =A0 =A0or also other specific models for monitoring? > >>> * =A0 =A0Can we use available management standards and data models = as a > >>> starting point and simplify them? > >>> * =A0 =A0Concerning the encoding (JSON, XML, or binary) we seem to = be > >>> flexible with tools. > >>> - =A0 =A0Concerning a normative data modeling language, we need to = choose > >>> a suitable language capable to prepare structured models. > >>> - =A0 =A0Is JSON sufficient for this purpose, or should YANG or = any other > >>> modeling language be used? > >>> * =A0 =A0What is appropriate as message transport? > >>> - =A0 =A0CoAP over UDP with soft-transactions? > >>> - =A0 =A0Netconf-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 = (coma@ietf.org). > >>> 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.] > >>> =A0 =A01. (Astron.) The envelope of a comet; a nebulous covering, > >>> =A0 =A0 =A0 which surrounds the nucleus or body of a comet. > >>> =A0 =A0 =A0 [1913 Webster] > >>> > >>> > >>> > >> > >> _______________________________________________ > >> Coma mailing list > >> Coma@ietf.org > >> https://www.ietf.org/mailman/listinfo/coma > > > > -- > > Zach Shelby, Chief Nerd, Sensinode Ltd. > > http://www.sensinode.com > > http://zachshelby.org =A0- My blog "On the Internet of Things" > > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded = Internet" > > Mobile: +358 40 7796297 > > > > _______________________________________________ > > Coma mailing list > > Coma@ietf.org > > https://www.ietf.org/mailman/listinfo/coma Return-Path: X-Original-To: coma@ietfa.amsl.com Delivered-To: coma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32EDE11E8174 for ; Fri, 1 Jun 2012 07:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEb7SQTZLK79 for ; Fri, 1 Jun 2012 07:33:53 -0700 (PDT) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id D8AD111E80B0 for ; Fri, 1 Jun 2012 07:33:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 86FA7536FF for ; Fri, 1 Jun 2012 16:33:51 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5rTZ1-dvX9-X for ; Fri, 1 Jun 2012 16:33:51 +0200 (CEST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jara) by xenon11.um.es (Postfix) with ESMTPSA id E26EF535FB for ; Fri, 1 Jun 2012 16:33:50 +0200 (CEST) Received: by lagv3 with SMTP id v3so1719512lag.31 for ; Fri, 01 Jun 2012 07:33:49 -0700 (PDT) Received: by 10.152.112.138 with SMTP id iq10mr3359482lab.13.1338561229210; Fri, 01 Jun 2012 07:33:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.30.163 with HTTP; Fri, 1 Jun 2012 07:33:08 -0700 (PDT) In-Reply-To: <341929CE-3341-41EC-A472-1213B6F8C320@sensinode.com> References: <80A0822C5E9A4440A5117C2F4CD36A6403D56943@DEMUEXC006.nsn-intra.net> <4FC8CFEB.6040902@cisco.com> <341929CE-3341-41EC-A472-1213B6F8C320@sensinode.com> From: Antonio Jara Date: Fri, 1 Jun 2012 16:33:08 +0200 Message-ID: To: Zach Shelby Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Benoit Claise , "Ersue, Mehmet \(NSN - DE/Munich\)" , coma@ietf.org, Ron Bonica Subject: Re: [Coma] New Maillist for the discussion on the Management of Constrained Networks and Devices X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 14:33:54 -0000 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 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 co= nstrained devices and how the OPS area could address the requirements. >> >> What would be nice is a =A0"constrained devices management: problem stat= ement" draft so that >> 1. the requirements are clearly written down >> 2. the OPS area could, if required, work on the protocol/data model lang= uage/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 shoul= d not be building a solution for a problem that we, OPS, think that the con= strained 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 i= n >>> 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 assumptio= n >>> 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 networ= k >>> 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.: >>> >>> * =A0 =A0Do we need a new development for IoT management (i.e. >>> constrained devices) at all? >>> - =A0 =A0If yes, what is really needed as standard and what is an >>> overkill? >>> * =A0 =A0What type of devices can we support? >>> * =A0 =A0How are the classes 0-2 for constrained devices defined in >>> detail? >>> * =A0 =A0Is some simple configuration management already sufficient? >>> - =A0 =A0Or do we need also a simple fault management and monitoring? >>> * =A0 =A0What type of data model modules do we need to standardize? >>> - =A0 =A0Just a few core models like ip-cfg, interface? >>> - =A0 =A0or also other specific models for monitoring? >>> * =A0 =A0Can we use available management standards and data models as a >>> starting point and simplify them? >>> * =A0 =A0Concerning the encoding (JSON, XML, or binary) we seem to be >>> flexible with tools. >>> - =A0 =A0Concerning a normative data modeling language, we need to choo= se >>> a suitable language capable to prepare structured models. >>> - =A0 =A0Is JSON sufficient for this purpose, or should YANG or any oth= er >>> modeling language be used? >>> * =A0 =A0What is appropriate as message transport? >>> - =A0 =A0CoAP over UDP with soft-transactions? >>> - =A0 =A0Netconf-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 woul= d >>> 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 fo= r >>> new work. >>> >>> Please send your opinions/comments to the coma maillist (coma@ietf.org)= . >>> 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.] >>> =A0 =A01. (Astron.) The envelope of a comet; a nebulous covering, >>> =A0 =A0 =A0 which surrounds the nucleus or body of a comet. >>> =A0 =A0 =A0 [1913 Webster] >>> >>> >>> >> >> _______________________________________________ >> Coma mailing list >> Coma@ietf.org >> https://www.ietf.org/mailman/listinfo/coma > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://www.sensinode.com > http://zachshelby.org =A0- My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 > > _______________________________________________ > Coma mailing list > Coma@ietf.org > https://www.ietf.org/mailman/listinfo/coma Return-Path: X-Original-To: coma@ietfa.amsl.com Delivered-To: coma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7885821F8A9B for ; Fri, 1 Jun 2012 07:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e284NYp2CTyL for ; Fri, 1 Jun 2012 07:24:45 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id BBE9221F8A99 for ; Fri, 1 Jun 2012 07:24:43 -0700 (PDT) Received: from [172.20.10.4] (84-231-9-202.elisa-mobile.fi [84.231.9.202]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q51EOb3Y017681; Fri, 1 Jun 2012 17:24:37 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <4FC8CFEB.6040902@cisco.com> Date: Fri, 1 Jun 2012 17:24:36 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <341929CE-3341-41EC-A472-1213B6F8C320@sensinode.com> References: <80A0822C5E9A4440A5117C2F4CD36A6403D56943@DEMUEXC006.nsn-intra.net> <4FC8CFEB.6040902@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1084) Cc: "Ersue, Mehmet \(NSN - DE/Munich\)" , Ron Bonica , coma@ietf.org Subject: Re: [Coma] New Maillist for the discussion on the Management of Constrained Networks and Devices X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 14:24:47 -0000 Hi, (constrained guy hat on) Sounds like a reasonable way forward to me.=20 Zach On Jun 1, 2012, at 5:21 PM, Benoit Claise wrote: > Dear all, >=20 > [reducing the mailing lists to coma only] >=20 > 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. >=20 > 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 >=20 >=20 > 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. >=20 > Regards, Benoit. >=20 >> Hi All, >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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.: >>=20 >> * 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? >>=20 >> Obviously the list of the questions above is not exhaustive. >>=20 >> 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. >>=20 >> 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. >>=20 >> Please send your opinions/comments to the coma maillist = (coma@ietf.org). >> To subscribe pls go to: https://www.ietf.org/mailman/listinfo/coma >>=20 >> Cheers, >> Mehmet >>=20 >>=20 >> BTW: Coma has been chosen as the maillist name following the = definition >> below: >>=20 >> 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] >>=20 >>=20 >>=20 >=20 > _______________________________________________ > Coma mailing list > Coma@ietf.org > https://www.ietf.org/mailman/listinfo/coma --=20 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 Return-Path: X-Original-To: coma@ietfa.amsl.com Delivered-To: coma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2F021F8A9B for ; Fri, 1 Jun 2012 07:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.513 X-Spam-Level: X-Spam-Status: No, score=-10.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvyFk5KnLzx4 for ; Fri, 1 Jun 2012 07:21:35 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id ECD1621F8A99 for ; Fri, 1 Jun 2012 07:21:33 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q51ELWhD017690; Fri, 1 Jun 2012 16:21:32 +0200 (CEST) Received: from [10.60.67.90] (ams-bclaise-8919.cisco.com [10.60.67.90]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q51ELVMa003567; Fri, 1 Jun 2012 16:21:31 +0200 (CEST) Message-ID: <4FC8CFEB.6040902@cisco.com> Date: Fri, 01 Jun 2012 16:21:31 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" References: <80A0822C5E9A4440A5117C2F4CD36A6403D56943@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6403D56943@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ron Bonica , coma@ietf.org Subject: Re: [Coma] New Maillist for the discussion on the Management of Constrained Networks and Devices X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 14:21:40 -0000 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 (coma@ietf.org). > 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] > > >