From nobody Tue Apr 1 06:54:00 2014 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C34F1A070F for ; Tue, 1 Apr 2014 06:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4IKqICADj4DW for ; Tue, 1 Apr 2014 06:53:56 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id CDD5E1A06DE for ; Tue, 1 Apr 2014 06:53:55 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s31Drpcd024988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 1 Apr 2014 13:53:51 GMT Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s31Droof018566 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 1 Apr 2014 15:53:50 +0200 Received: from DEMUHTC011.nsn-intra.net (10.159.42.42) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 1 Apr 2014 15:53:50 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.10]) by DEMUHTC011.nsn-intra.net ([10.159.42.42]) with mapi id 14.03.0123.003; Tue, 1 Apr 2014 15:53:50 +0200 From: "Ersue, Mehmet (NSN - DE/Munich)" To: ext Hannes Tschofenig , "coman@ietf.org" Thread-Topic: [coman] Purpose of this list? Thread-Index: AQHPTOYi3NVjIWVGMUSSxYL7wEwZoJr7v7Xg Date: Tue, 1 Apr 2014 13:53:50 +0000 Message-ID: References: <53396D11.8040508@gmx.net> In-Reply-To: <53396D11.8040508@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: 817 X-purgate-ID: 151667::1396360431-00001564-A9BA6223/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/coman/y67trTT8wy3rfRHgsOTkyLT9aN0 Subject: Re: [coman] Purpose of this list? X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.15 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, 01 Apr 2014 13:53:58 -0000 Hannes, I think it is still beneficial to keep the Coman maillist. The Coman community discusses from time to time issues related to the manag= ement of constrained devices. Cheers,=20 Mehmet=20 > -----Original Message----- > From: coman [mailto:coman-bounces@ietf.org] On Behalf Of ext Hannes > Tschofenig > Sent: Monday, March 31, 2014 3:27 PM > To: coman@ietf.org > Subject: [coman] Purpose of this list? >=20 > Hi all, >=20 > I was wondering what the purpose of this list is given that some of the > documents have been moved over to the opsawg group. >=20 > The mailing list overview page at > https://www.ietf.org/mailman/listinfo/coman does not provide a lot of > details about the purpose of the group either. >=20 > Is it time to close this list? >=20 > Ciao > Hannes >=20 From nobody Tue Apr 1 07:08:51 2014 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3F6A1A0737 for ; Tue, 1 Apr 2014 07:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.585 X-Spam-Level: * X-Spam-Status: No, score=1.585 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y23CXGn7ikQT for ; Tue, 1 Apr 2014 07:08:46 -0700 (PDT) Received: from smtp-vbr1.xs4all.nl (smtp-vbr1.xs4all.nl [194.109.24.21]) by ietfa.amsl.com (Postfix) with ESMTP id 42DDA1A084C for ; Tue, 1 Apr 2014 07:08:46 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube8.xs4all.net [194.109.20.206]) by smtp-vbr1.xs4all.nl (8.13.8/8.13.8) with ESMTP id s31E8fpj058281 for ; Tue, 1 Apr 2014 16:08:42 +0200 (CEST) (envelope-from stokcons@xs4all.nl) Received: from a82-95-140-48.adsl.xs4all.nl ([82.95.140.48]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 01 Apr 2014 16:08:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 01 Apr 2014 16:08:41 +0200 From: peter van der Stok To: coman@ietf.org Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <53396D11.8040508@gmx.net> Message-ID: X-Sender: stokcons@xs4all.nl (4YjWnTMo4YHY0j6mXHWz8ju1K1yPWqTT) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Archived-At: http://mailarchive.ietf.org/arch/msg/coman/l5TLUIEDumUBz00Mp_r1k7bq_V4 Subject: Re: [coman] =?utf-8?q?Purpose_of_this_list=3F?= X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 14:08:48 -0000 Hannes, given that we wil have a meeting on management in Toronto, led by Juergen, the list may turn out to be useful. Peter Ersue, Mehmet (NSN - DE/Munich) schreef op 2014-04-01 15:53: > Hannes, > > I think it is still beneficial to keep the Coman maillist. > The Coman community discusses from time to time issues related to the > management of constrained devices. > > Cheers, > Mehmet > >> -----Original Message----- >> From: coman [mailto:coman-bounces@ietf.org] On Behalf Of ext Hannes >> Tschofenig >> Sent: Monday, March 31, 2014 3:27 PM >> To: coman@ietf.org >> Subject: [coman] Purpose of this list? >> >> Hi all, >> >> I was wondering what the purpose of this list is given that some of >> the >> documents have been moved over to the opsawg group. >> >> The mailing list overview page at >> https://www.ietf.org/mailman/listinfo/coman does not provide a lot of >> details about the purpose of the group either. >> >> Is it time to close this list? >> >> Ciao >> Hannes >> > > _______________________________________________ > coman mailing list > coman@ietf.org > https://www.ietf.org/mailman/listinfo/coman From nobody Tue Apr 1 07:13:02 2014 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D12FE1A06C4 for ; Tue, 1 Apr 2014 07:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VredKldBLTnY for ; Tue, 1 Apr 2014 07:12:56 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id AA0061A06BE for ; Tue, 1 Apr 2014 07:12:56 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAErIOlPGmAcV/2dsb2JhbABZgmUhO1e7eSCHNYEaFnSCJQEBAQEDAQEBDyg0FwQCAQgNBAQBAQsUCQcnCxQJCAIEARIIDA6HVwEMpCutNhMEjj84BoMegRQEn02LQoMwgis X-IronPort-AV: E=Sophos;i="4.97,772,1389762000"; d="scan'208";a="56054207" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 01 Apr 2014 10:12:52 -0400 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 01 Apr 2014 09:58:41 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Tue, 1 Apr 2014 10:12:51 -0400 From: "Romascanu, Dan (Dan)" To: "consultancy@vanderstok.org" , "coman@ietf.org" Thread-Topic: [coman] Purpose of this list? Thread-Index: AQHPTOYi3NVjIWVGMUSSxYL7wEwZoJr7v7XggADsvICAACI5IA== Date: Tue, 1 Apr 2014 14:12:50 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E46D995@AZ-FFEXMB04.global.avaya.com> References: <53396D11.8040508@gmx.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/coman/JBCkWl8MLOAhd1NXNQcwd_UDE68 Subject: Re: [coman] Purpose of this list? X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.15 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, 01 Apr 2014 14:12:59 -0000 Hi Peter, What is the ' meeting on management in Toronto' that you refer to?=20 I agree that it would be useful to keep this list open for a while at least= .=20 Thanks and Regards, Dan > -----Original Message----- > From: coman [mailto:coman-bounces@ietf.org] On Behalf Of peter van der > Stok > Sent: Tuesday, April 01, 2014 5:09 PM > To: coman@ietf.org > Subject: Re: [coman] Purpose of this list? >=20 > Hannes, >=20 > given that we wil have a meeting on management in Toronto, led by Juergen= , > the list may turn out to be useful. >=20 > Peter >=20 > Ersue, Mehmet (NSN - DE/Munich) schreef op 2014-04-01 15:53: > > Hannes, > > > > I think it is still beneficial to keep the Coman maillist. > > The Coman community discusses from time to time issues related to the > > management of constrained devices. > > > > Cheers, > > Mehmet > > > >> -----Original Message----- > >> From: coman [mailto:coman-bounces@ietf.org] On Behalf Of ext Hannes > >> Tschofenig > >> Sent: Monday, March 31, 2014 3:27 PM > >> To: coman@ietf.org > >> Subject: [coman] Purpose of this list? > >> > >> Hi all, > >> > >> I was wondering what the purpose of this list is given that some of > >> the documents have been moved over to the opsawg group. > >> > >> The mailing list overview page at > >> https://www.ietf.org/mailman/listinfo/coman does not provide a lot of > >> details about the purpose of the group either. > >> > >> Is it time to close this list? > >> > >> Ciao > >> Hannes > >> > > > > _______________________________________________ > > coman mailing list > > coman@ietf.org > > https://www.ietf.org/mailman/listinfo/coman >=20 > _______________________________________________ > coman mailing list > coman@ietf.org > https://www.ietf.org/mailman/listinfo/coman From nobody Tue Apr 1 07:19:57 2014 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 409F81A0737 for ; Tue, 1 Apr 2014 07:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.185 X-Spam-Level: X-Spam-Status: No, score=0.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxzGQeg0GxBW for ; Tue, 1 Apr 2014 07:19:52 -0700 (PDT) Received: from smtp-vbr8.xs4all.nl (smtp-vbr8.xs4all.nl [194.109.24.28]) by ietfa.amsl.com (Postfix) with ESMTP id 720501A06BE for ; Tue, 1 Apr 2014 07:19:52 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube8.xs4all.net [194.109.20.206]) by smtp-vbr8.xs4all.nl (8.13.8/8.13.8) with ESMTP id s31EJebq025527; Tue, 1 Apr 2014 16:19:41 +0200 (CEST) (envelope-from stokcons@xs4all.nl) Received: from a82-95-140-48.adsl.xs4all.nl ([82.95.140.48]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 01 Apr 2014 16:19:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 01 Apr 2014 16:19:40 +0200 From: peter van der Stok To: "Romascanu, Dan (Dan)" Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA2E46D995@AZ-FFEXMB04.global.avaya.com> References: <53396D11.8040508@gmx.net> <9904FB1B0159DA42B0B887B7FA8119CA2E46D995@AZ-FFEXMB04.global.avaya.com> Message-ID: X-Sender: stokcons@xs4all.nl (b88M3oUD34dxzjO9xg+Amglx/P7uchHd) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Archived-At: http://mailarchive.ietf.org/arch/msg/coman/PO1tcd1BSFvt6aW8a13T-pIV1Lg Cc: coman@ietf.org, consultancy@vanderstok.org Subject: Re: [coman] =?utf-8?q?Purpose_of_this_list=3F?= X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 14:19:54 -0000 Hi Dan, During the Core meeting it was decided that we needed a special meeting on management to look at the ongoing initiatives. Peter Romascanu, Dan (Dan) schreef op 2014-04-01 16:12: > Hi Peter, > > What is the ' meeting on management in Toronto' that you refer to? > > I agree that it would be useful to keep this list open for a while at > least. > > Thanks and Regards, > > Dan > > >> -----Original Message----- >> From: coman [mailto:coman-bounces@ietf.org] On Behalf Of peter van der >> Stok >> Sent: Tuesday, April 01, 2014 5:09 PM >> To: coman@ietf.org >> Subject: Re: [coman] Purpose of this list? >> >> Hannes, >> >> given that we wil have a meeting on management in Toronto, led by >> Juergen, >> the list may turn out to be useful. >> >> Peter >> >> Ersue, Mehmet (NSN - DE/Munich) schreef op 2014-04-01 15:53: >> > Hannes, >> > >> > I think it is still beneficial to keep the Coman maillist. >> > The Coman community discusses from time to time issues related to the >> > management of constrained devices. >> > >> > Cheers, >> > Mehmet >> > >> >> -----Original Message----- >> >> From: coman [mailto:coman-bounces@ietf.org] On Behalf Of ext Hannes >> >> Tschofenig >> >> Sent: Monday, March 31, 2014 3:27 PM >> >> To: coman@ietf.org >> >> Subject: [coman] Purpose of this list? >> >> >> >> Hi all, >> >> >> >> I was wondering what the purpose of this list is given that some of >> >> the documents have been moved over to the opsawg group. >> >> >> >> The mailing list overview page at >> >> https://www.ietf.org/mailman/listinfo/coman does not provide a lot of >> >> details about the purpose of the group either. >> >> >> >> Is it time to close this list? >> >> >> >> Ciao >> >> Hannes >> >> >> > >> > _______________________________________________ >> > coman mailing list >> > coman@ietf.org >> > https://www.ietf.org/mailman/listinfo/coman >> >> _______________________________________________ >> coman mailing list >> coman@ietf.org >> https://www.ietf.org/mailman/listinfo/coman From nobody Tue Apr 1 08:38:12 2014 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7311A07F5 for ; Tue, 1 Apr 2014 08:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssUIFx6wJmp3 for ; Tue, 1 Apr 2014 08:38:08 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id F2BEB1A06F4 for ; Tue, 1 Apr 2014 08:38:07 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s31FbxJQ032033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 1 Apr 2014 15:37:59 GMT Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s31FbxYR017176 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 1 Apr 2014 17:37:59 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.10]) by DEMUHTC002.nsn-intra.net ([10.159.42.33]) with mapi id 14.03.0123.003; Tue, 1 Apr 2014 17:37:59 +0200 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "consultancy@vanderstok.org" , "Romascanu, Dan (Dan)" Thread-Topic: [coman] Purpose of this list? Thread-Index: AQHPTOYi3NVjIWVGMUSSxYL7wEwZoJr7v7XggAERaS+AABWzoA== Date: Tue, 1 Apr 2014 15:37:58 +0000 Message-ID: References: <53396D11.8040508@gmx.net> <9904FB1B0159DA42B0B887B7FA8119CA2E46D995@AZ-FFEXMB04.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: 2745 X-purgate-ID: 151667::1396366679-00001326-47FA236C/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/coman/EvF4RIPo-pnjg3yuWWRxlLukCgs Cc: "coman@ietf.org" Subject: Re: [coman] Purpose of this list? X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.15 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, 01 Apr 2014 15:38:11 -0000 Will this be a Core WG session? Cheers,=20 Mehmet=20 > -----Original Message----- > From: coman [mailto:coman-bounces@ietf.org] On Behalf Of ext peter van > der Stok > Sent: Tuesday, April 01, 2014 4:20 PM > To: Romascanu, Dan (Dan) > Cc: coman@ietf.org; consultancy@vanderstok.org > Subject: Re: [coman] Purpose of this list? >=20 > Hi Dan, >=20 > During the Core meeting it was decided that we needed a special meeting > on management to look at the ongoing initiatives. >=20 > Peter >=20 > Romascanu, Dan (Dan) schreef op 2014-04-01 16:12: > > Hi Peter, > > > > What is the ' meeting on management in Toronto' that you refer to? > > > > I agree that it would be useful to keep this list open for a while at > > least. > > > > Thanks and Regards, > > > > Dan > > > > > >> -----Original Message----- > >> From: coman [mailto:coman-bounces@ietf.org] On Behalf Of peter van > der > >> Stok > >> Sent: Tuesday, April 01, 2014 5:09 PM > >> To: coman@ietf.org > >> Subject: Re: [coman] Purpose of this list? > >> > >> Hannes, > >> > >> given that we wil have a meeting on management in Toronto, led by > >> Juergen, > >> the list may turn out to be useful. > >> > >> Peter > >> > >> Ersue, Mehmet (NSN - DE/Munich) schreef op 2014-04-01 15:53: > >> > Hannes, > >> > > >> > I think it is still beneficial to keep the Coman maillist. > >> > The Coman community discusses from time to time issues related to > the > >> > management of constrained devices. > >> > > >> > Cheers, > >> > Mehmet > >> > > >> >> -----Original Message----- > >> >> From: coman [mailto:coman-bounces@ietf.org] On Behalf Of ext > Hannes > >> >> Tschofenig > >> >> Sent: Monday, March 31, 2014 3:27 PM > >> >> To: coman@ietf.org > >> >> Subject: [coman] Purpose of this list? > >> >> > >> >> Hi all, > >> >> > >> >> I was wondering what the purpose of this list is given that some > of > >> >> the documents have been moved over to the opsawg group. > >> >> > >> >> The mailing list overview page at > >> >> https://www.ietf.org/mailman/listinfo/coman does not provide a > lot of > >> >> details about the purpose of the group either. > >> >> > >> >> Is it time to close this list? > >> >> > >> >> Ciao > >> >> Hannes > >> >> > >> > > >> > _______________________________________________ > >> > coman mailing list > >> > coman@ietf.org > >> > https://www.ietf.org/mailman/listinfo/coman > >> > >> _______________________________________________ > >> coman mailing list > >> coman@ietf.org > >> https://www.ietf.org/mailman/listinfo/coman >=20 > _______________________________________________ > coman mailing list > coman@ietf.org > https://www.ietf.org/mailman/listinfo/coman From nobody Tue Apr 1 09:56:28 2014 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262241A0892 for ; Tue, 1 Apr 2014 09:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGjjHI2Do8Om for ; Tue, 1 Apr 2014 09:56:25 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id D40E51A099C for ; Tue, 1 Apr 2014 09:56:24 -0700 (PDT) Received: from [192.168.131.137] ([80.92.119.215]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Lcjgd-1Ww4eu2aD1-00k5bN; Tue, 01 Apr 2014 18:56:15 +0200 Message-ID: <533AECB9.2020709@gmx.net> Date: Tue, 01 Apr 2014 18:43:37 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: consultancy@vanderstok.org, "Romascanu, Dan (Dan)" References: <53396D11.8040508@gmx.net> <9904FB1B0159DA42B0B887B7FA8119CA2E46D995@AZ-FFEXMB04.global.avaya.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="OcaPHoePvm5pcwbpax6tG5EoGh6GhE2Um" X-Provags-ID: V03:K0:gTOkU2XZYlL7/oLiG8qs2n9U2kMGoaV/f+Hue0ITAqbBLDZ1OHU zzKdCftVAYRqvUN/33/EhNB0o67niaI+ituxq9PXbuUG+GQYr4y7y4N2zAkrnFNpMsJDwrt TzACi1SOoXjnRukYHEZEWAX0UY3FhNFPx+hsmBv2bk3M0D+5xfcThqS/vIARe/f33QGhvHX 37OxjkyhojbdmSkBx495w== Archived-At: http://mailarchive.ietf.org/arch/msg/coman/WMwJNghH2jFENlemZZa8Sq71NhE Cc: coman@ietf.org Subject: Re: [coman] Purpose of this list? X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.15 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, 01 Apr 2014 16:56:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OcaPHoePvm5pcwbpax6tG5EoGh6GhE2Um Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Peter, Dan, Mehmet, given that some of the work moved over to the opsawg group what remains left here to be discussed? I heard you saying that this list is useful but not for *what*. For announcing this special meeting on management you might reach a wider audience with posts on other lists. Just a suggestion. Ciao Hannes On 04/01/2014 04:19 PM, peter van der Stok wrote: > Hi Dan, >=20 > During the Core meeting it was decided that we needed a special meeting= > on management to look at the ongoing initiatives. >=20 > Peter >=20 > Romascanu, Dan (Dan) schreef op 2014-04-01 16:12: >> Hi Peter, >> >> What is the ' meeting on management in Toronto' that you refer to? >> >> I agree that it would be useful to keep this list open for a while at >> least. >> >> Thanks and Regards, >> >> Dan >> >> >>> -----Original Message----- >>> From: coman [mailto:coman-bounces@ietf.org] On Behalf Of peter van de= r >>> Stok >>> Sent: Tuesday, April 01, 2014 5:09 PM >>> To: coman@ietf.org >>> Subject: Re: [coman] Purpose of this list? >>> >>> Hannes, >>> >>> given that we wil have a meeting on management in Toronto, led by >>> Juergen, >>> the list may turn out to be useful. >>> >>> Peter >>> >>> Ersue, Mehmet (NSN - DE/Munich) schreef op 2014-04-01 15:53: >>> > Hannes, >>> > >>> > I think it is still beneficial to keep the Coman maillist. >>> > The Coman community discusses from time to time issues related to t= he >>> > management of constrained devices. >>> > >>> > Cheers, >>> > Mehmet >>> > >>> >> -----Original Message----- >>> >> From: coman [mailto:coman-bounces@ietf.org] On Behalf Of ext Hanne= s >>> >> Tschofenig >>> >> Sent: Monday, March 31, 2014 3:27 PM >>> >> To: coman@ietf.org >>> >> Subject: [coman] Purpose of this list? >>> >> >>> >> Hi all, >>> >> >>> >> I was wondering what the purpose of this list is given that some o= f >>> >> the documents have been moved over to the opsawg group. >>> >> >>> >> The mailing list overview page at >>> >> https://www.ietf.org/mailman/listinfo/coman does not provide a lot= of >>> >> details about the purpose of the group either. >>> >> >>> >> Is it time to close this list? >>> >> >>> >> Ciao >>> >> Hannes >>> >> >>> > >>> > _______________________________________________ >>> > coman mailing list >>> > coman@ietf.org >>> > https://www.ietf.org/mailman/listinfo/coman >>> >>> _______________________________________________ >>> coman mailing list >>> coman@ietf.org >>> https://www.ietf.org/mailman/listinfo/coman >=20 > _______________________________________________ > coman mailing list > coman@ietf.org > https://www.ietf.org/mailman/listinfo/coman --OcaPHoePvm5pcwbpax6tG5EoGh6GhE2Um Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTOuy5AAoJEGhJURNOOiAt788H/3nInk1IvRzxRN46APS4MQ2w UVkUWD0Zrwq1rTPkUYujZpnHjG/LZQ+vkR7AxlFiNyhAnTiKUgSDFHQvbNCPFt56 m+0h4zHBgAWbfvrj9FEcwzDOsGX/Sj8etTqruXoaJWQaV1kPlr7b0gOtamDF/9jk uANuNCk/3uVIYYK1XqTYpPHJiu0g5MW4radlH12sA7Inp3LFg3pRTj5uc9q+HhH8 YA2xcM9m1QGlrWCtKCxyalaw5lhhe6wLCY8PvVeiLIG8wJneF8xX5djOlMuQnp9Q DVf3X2XP1hdfaK5mzDHyQwXN78GUSOkF2vTFTdCN88Ae7xcLCGA/pf1FjOBs4Gg= =vNhr -----END PGP SIGNATURE----- --OcaPHoePvm5pcwbpax6tG5EoGh6GhE2Um-- From nobody Tue Apr 1 10:33:16 2014 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A81D1A08A3 for ; Tue, 1 Apr 2014 10:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ai-3mD0KiVEl for ; Tue, 1 Apr 2014 10:33:12 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 995481A0895 for ; Tue, 1 Apr 2014 10:33:12 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id hz1so10155217pad.21 for ; Tue, 01 Apr 2014 10:33:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=76KN07j6jiDF4ouc0dfXl5bYHMtAbQUIBWB1WbTGNBI=; b=Ev0QAHThcVdFaJ6CqxdExFfrCcCe3kgT1RxycgBngYT1QxRKfEgfSDKujSGNNfQvyP 9KKq37WsiziqVw/VJLkpsOKA0dxjz+SzEkO+2jGDqZHNd3cKNqhQnLtQEuBDVdzb9cAb dSt3UzETNmVMNgnItFb1mFOok3Z4XhqXBriC58CVJIyreU9FD4mtOpMJrut60gZ4PYzV 7QI0NcQlPa9Uox7L2nScRsD5KuVWxbuPB520dvAAt+tVbgHbjfSL0N2TQkuGWFh45pvw MxGFBrXw7n6FwpusrHnJk3YfESklzHyyB1Pr1YgMjeGNGo3wr5sn6zUidMOIZRFz2z6I 2yqw== X-Received: by 10.67.30.168 with SMTP id kf8mr4695946pad.84.1396373589138; Tue, 01 Apr 2014 10:33:09 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.154.130 with HTTP; Tue, 1 Apr 2014 10:32:49 -0700 (PDT) In-Reply-To: <533AECB9.2020709@gmx.net> References: <53396D11.8040508@gmx.net> <9904FB1B0159DA42B0B887B7FA8119CA2E46D995@AZ-FFEXMB04.global.avaya.com> <533AECB9.2020709@gmx.net> From: Thomas Watteyne Date: Tue, 1 Apr 2014 10:32:49 -0700 X-Google-Sender-Auth: mUxouY5YQk-rINFVSLWxV9y1UUk Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a1134183ac124cd04f5fe8f5e Archived-At: http://mailarchive.ietf.org/arch/msg/coman/4Z0XDxvbDDQW0XaI9vLHXy-JJnc Cc: coman@ietf.org, "Romascanu, Dan \(Dan\)" , "consultancy@vanderstok.org" Subject: Re: [coman] Purpose of this list? X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.15 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, 01 Apr 2014 17:33:14 -0000 --001a1134183ac124cd04f5fe8f5e Content-Type: text/plain; charset=ISO-8859-1 Peter, I would be very interested in attending this meeting, since we are doing lots of very related work in 6TiSCH. If there was any, I must have missed the announcement e-mail. Could you point me to it? Thomas On Tue, Apr 1, 2014 at 9:43 AM, Hannes Tschofenig wrote: > Peter, Dan, Mehmet, > > given that some of the work moved over to the opsawg group what remains > left here to be discussed? > > I heard you saying that this list is useful but not for *what*. > > For announcing this special meeting on management you might reach a > wider audience with posts on other lists. Just a suggestion. > > Ciao > Hannes > > > > On 04/01/2014 04:19 PM, peter van der Stok wrote: > > Hi Dan, > > > > During the Core meeting it was decided that we needed a special meeting > > on management to look at the ongoing initiatives. > > > > Peter > > > > Romascanu, Dan (Dan) schreef op 2014-04-01 16:12: > >> Hi Peter, > >> > >> What is the ' meeting on management in Toronto' that you refer to? > >> > >> I agree that it would be useful to keep this list open for a while at > >> least. > >> > >> Thanks and Regards, > >> > >> Dan > >> > >> > >>> -----Original Message----- > >>> From: coman [mailto:coman-bounces@ietf.org] On Behalf Of peter van der > >>> Stok > >>> Sent: Tuesday, April 01, 2014 5:09 PM > >>> To: coman@ietf.org > >>> Subject: Re: [coman] Purpose of this list? > >>> > >>> Hannes, > >>> > >>> given that we wil have a meeting on management in Toronto, led by > >>> Juergen, > >>> the list may turn out to be useful. > >>> > >>> Peter > >>> > >>> Ersue, Mehmet (NSN - DE/Munich) schreef op 2014-04-01 15:53: > >>> > Hannes, > >>> > > >>> > I think it is still beneficial to keep the Coman maillist. > >>> > The Coman community discusses from time to time issues related to the > >>> > management of constrained devices. > >>> > > >>> > Cheers, > >>> > Mehmet > >>> > > >>> >> -----Original Message----- > >>> >> From: coman [mailto:coman-bounces@ietf.org] On Behalf Of ext Hannes > >>> >> Tschofenig > >>> >> Sent: Monday, March 31, 2014 3:27 PM > >>> >> To: coman@ietf.org > >>> >> Subject: [coman] Purpose of this list? > >>> >> > >>> >> Hi all, > >>> >> > >>> >> I was wondering what the purpose of this list is given that some of > >>> >> the documents have been moved over to the opsawg group. > >>> >> > >>> >> The mailing list overview page at > >>> >> https://www.ietf.org/mailman/listinfo/coman does not provide a lot > of > >>> >> details about the purpose of the group either. > >>> >> > >>> >> Is it time to close this list? > >>> >> > >>> >> Ciao > >>> >> Hannes > >>> >> > >>> > > >>> > _______________________________________________ > >>> > coman mailing list > >>> > coman@ietf.org > >>> > https://www.ietf.org/mailman/listinfo/coman > >>> > >>> _______________________________________________ > >>> coman mailing list > >>> coman@ietf.org > >>> https://www.ietf.org/mailman/listinfo/coman > > > > _______________________________________________ > > coman mailing list > > coman@ietf.org > > https://www.ietf.org/mailman/listinfo/coman > > > _______________________________________________ > coman mailing list > coman@ietf.org > https://www.ietf.org/mailman/listinfo/coman > > --001a1134183ac124cd04f5fe8f5e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Peter,
I would be very interested in attending t= his meeting, since we are doing lots of very related work in 6TiSCH. If the= re was any, I must have missed the announcement e-mail. Could you point me = to it?
Thomas


On Tue, Apr 1, 2014 at 9:43 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Peter, Dan, Mehmet,

given that some of the work moved over to the opsawg group what remains
left here to be discussed?

I heard you saying that this list is useful but not for *what*.

For announcing this special meeting on management you might reach a
wider audience with posts on other lists. Just a suggestion.

Ciao
Hannes



On 04/01/2014 04:19 PM, peter van der Stok wrote:
> Hi Dan,
>
> During the Core meeting it was decided that we needed a special meetin= g
> on management to look at the ongoing initiatives.
>
> Peter
>
> Romascanu, Dan (Dan) schreef op 2014-04-01 16:12:
>> Hi Peter,
>>
>> What is the ' meeting on management in Toronto' that you r= efer to?
>>
>> I agree that it would be useful to keep this list open for a while= at
>> least.
>>
>> Thanks and Regards,
>>
>> Dan
>>
>>
>>> -----Original Message-----
>>> From: coman [mailto:= coman-bounces@ietf.org] On Behalf Of peter van der
>>> Stok
>>> Sent: Tuesday, April 01, 2014 5:09 PM
>>> To: coman@ietf.org
>>> Subject: Re: [coman] Purpose of this list?
>>>
>>> Hannes,
>>>
>>> given that we wil have a meeting on management in Toronto, led= by
>>> Juergen,
>>> the list may turn out to be useful.
>>>
>>> Peter
>>>
>>> Ersue, Mehmet (NSN - DE/Munich) schreef op 2014-04-01 15:53: >>> > Hannes,
>>> >
>>> > I think it is still beneficial to keep the Coman maillist= .
>>> > The Coman community discusses from time to time issues re= lated to the
>>> > management of constrained devices.
>>> >
>>> > Cheers,
>>> > Mehmet
>>> >
>>> >> -----Original Message-----
>>> >> From: coman [mailto:coman-bounces@ietf.org] On Behalf Of ext Hannes
>>> >> Tschofenig
>>> >> Sent: Monday, March 31, 2014 3:27 PM
>>> >> To: coman@ietf.org<= /a>
>>> >> Subject: [coman] Purpose of this list?
>>> >>
>>> >> Hi all,
>>> >>
>>> >> I was wondering what the purpose of this list is give= n that some of
>>> >> the documents have been moved over to the opsawg grou= p.
>>> >>
>>> >> The mailing list overview page at
>>> >> https://www.ietf.org/mailman/listinfo/coman does n= ot provide a lot of
>>> >> details about the purpose of the group either.
>>> >>
>>> >> Is it time to close this list?
>>> >>
>>> >> Ciao
>>> >> Hannes
>>> >>
>>> >
>>> > _______________________________________________
>>> > coman mailing list
>>> > coman@ietf.org
>>> > https://www.ietf.org/mailman/listinfo/coman
>>>
>>> _______________________________________________
>>> coman mailing list
>>> coman@ietf.org
>>> https://www.ietf.org/mailman/listinfo/coman
>
> _______________________________________________
> coman mailing list
> coman@ietf.org
> https://www.ietf.org/mailman/listinfo/coman


_______________________________________________
coman mailing list
coman@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/coman


--001a1134183ac124cd04f5fe8f5e-- From nobody Tue Apr 1 11:02:45 2014 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E758B1A089B for ; Tue, 1 Apr 2014 11:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSB3AD6sW7Vh for ; Tue, 1 Apr 2014 11:02:41 -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 459CC1A0705 for ; Tue, 1 Apr 2014 11:02:40 -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.5/8.14.5) with ESMTP id s31I2RXR020607; Tue, 1 Apr 2014 20:02:27 +0200 (CEST) Received: from alma.local (eduroam-pool7-1657.wlan.uni-bremen.de [134.102.118.121]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id F0A91B9E; Tue, 1 Apr 2014 20:02:26 +0200 (CEST) Date: Tue, 1 Apr 2014 20:02:24 +0200 From: Carsten Bormann To: "Mehmet (NSN - DE/Munich) Ersue" Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="533aff30_19495cff_11861" Archived-At: http://mailarchive.ietf.org/arch/msg/coman/zN6SlmrajBXLwVNBfx3GLxnxTUk Cc: "=?utf-8?Q?coman=40ietf.org?=" , "Dan \(Dan\) Romascanu" , "=?utf-8?Q?consultancy=40vanderstok.org?=" Subject: Re: [coman] Purpose of this list? X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.15 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, 01 Apr 2014 18:02:43 -0000 --533aff30_19495cff_11861 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > Will this be a Core WG session=3F =20 Reserving time on the CoRE agenda is certainly one way to do this. =20 If there is a better way to make progress on a cross-area outlook on the = subject, I=E2=80=99m certainly open to suggestions. (And the intention certainly is to build on the work that is completing i= n OPSAWG now.) Gr=C3=BC=C3=9Fe, Carsten --533aff30_19495cff_11861 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > Will this be a Core WG s= ession=3F 

Rese= rving time on the CoRE agenda is certainly one way to do this.
If there is a= better way to make progress on a cross-area outlook on the subject,= I=E2=80=99m certainly open to suggestions.
= (And the intention cer= tainly is to build on the work that is completing in OPSAWG now.)<= /font>

Gr=C3=BC=C3=9Fe, Carsten
--533aff30_19495cff_11861-- From nobody Tue Apr 1 11:55:10 2014 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AFF01A09E3 for ; Tue, 1 Apr 2014 11:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlNn4NYOdlOp for ; Tue, 1 Apr 2014 11:55:03 -0700 (PDT) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) by ietfa.amsl.com (Postfix) with ESMTP id 7F70B1A09E2 for ; Tue, 1 Apr 2014 11:55:03 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id i17so11273469qcy.28 for ; Tue, 01 Apr 2014 11:54:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4JhuMcR5H9LNHbcJWF4N80dnN/AuzSE235prykBtT0A=; b=GAHSBFEu03k8a6yhWmUKKYhM85qnJLfJL9qAMwPaGK1X/kIF3G9+6FTobGeyV3glFq KWIVmtuhJG09gRHdzaU/s/XwWv2XAW9WdnRkc/98h6lHtQC9fMVtGNtjPdXSdSJk0RVm NXT9pitU6PCEv6PJdYTSq6INMEUfmvnpwDmqldov8crRJkenvEinIuDTHaHjeKcsiyvh DFpW/eKRVzfOHpiaHQ0LYRxGPt6SFYCXM7jLPSroOHunWgyXJzO14SyyVPyNlSXjPn/Z gfjli9KTZLmcN7qvKEyaL7Q1HHb/96kZyNA2EjVWFqzvzSfy/g1ZC8g6gAEGxRPzrwFX F+PA== X-Gm-Message-State: ALoCoQlMRxeqCLLg8JpWNNr6psFuePYEncVMOaeo6suH2eIjqkFvR4NCIUkmDa00DPvr2ykd6REb MIME-Version: 1.0 X-Received: by 10.140.92.6 with SMTP id a6mr34847050qge.34.1396378499666; Tue, 01 Apr 2014 11:54:59 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Tue, 1 Apr 2014 11:54:59 -0700 (PDT) In-Reply-To: References: Date: Tue, 1 Apr 2014 11:54:59 -0700 Message-ID: From: Andy Bierman To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a1139a97071f4db04f5ffb45c Archived-At: http://mailarchive.ietf.org/arch/msg/coman/kwvC-Iqx--R0gvwc3RZZiG2b0cE Cc: "Mehmet \(NSN - DE/Munich\) Ersue" , "coman@ietf.org" , "consultancy@vanderstok.org" , "Dan \(Dan\) Romascanu" Subject: Re: [coman] Purpose of this list? X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.15 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, 01 Apr 2014 18:55:06 -0000 --001a1139a97071f4db04f5ffb45c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Apr 1, 2014 at 11:02 AM, Carsten Bormann wrote: > > Will this be a Core WG session? > > Reserving time on the CoRE agenda is certainly one way to do this. > If there is a better way to make progress on a cross-area outlook on the > subject, I'm certainly open to suggestions. > (And the intention certainly is to build on the work that is completing i= n > OPSAWG now.) > > I am very interested in attending this meeting as well. I have been doing a bit of research on how to adapt/optimize RESTCONF for CoAP. I think there might be enough interest in this meeting to justify a 1 hour time-slot of its own. (Scheduling without cross-area conflicts is another matter). Gr=FC=DFe, Carsten > > Andy --001a1139a97071f4db04f5ffb45c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Apr 1, 2014 at 11:02 AM, Carsten Bormann = <cabo@tzi.org><= /span> wrote:
> Will this be a Core W= G session? 

Rese= rving time on the CoRE agenda is certainly one way to do this.
If there is a better way to make progress= on a cross-area outlook on the subject, I’m certainly open to s= uggestions.
(And the intention certainly is to build = on the work that is completing in OPSAWG now.)


I am very interested i= n attending this meeting as well. I have been doing
a bit of rese= arch on how to adapt/optimize RESTCONF for CoAP.
I think there mi= ght be enough interest in this meeting to justify a 1 hour time-slot
of its own. (Scheduling without cross-area conflicts is another matter= ).



Gr=FC=DFe, Carst= en


Andy

--001a1139a97071f4db04f5ffb45c-- From nobody Tue Apr 1 12:01:07 2014 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A57A1A09E9 for ; Tue, 1 Apr 2014 12:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yp_T_D11Eai0 for ; Tue, 1 Apr 2014 12:01:00 -0700 (PDT) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 37C4F1A0A27 for ; Tue, 1 Apr 2014 12:00:58 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id lc6so10145267vcb.21 for ; Tue, 01 Apr 2014 12:00:54 -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=8h/a3PQ3vgQiPSByBw0nBAt/DOZo8fDu2d5N0FWHNwc=; b=QTw+U79w9070EAeQNbYEAtjY8lqC09+8kjBbdwAXN1AjnmUKZWDIdKF2KhFULYcprz W2fLAkHEREiDOpOiKjSZmaBfgfTPdnUygTSWMZVn51TBikn3yhAbxVxoGvs/f+ZcsrQI rtur6DgA/roqrzgJDdxKYJWh0WULOyUH0X+KQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8h/a3PQ3vgQiPSByBw0nBAt/DOZo8fDu2d5N0FWHNwc=; b=iKMSf2n5/HL1q+0iBe0xboqeQBdc3W88qSPOXserhzu67DTeatyN2blkATaj5644S8 rLHeDOae+jGqfiE431R2w3UKO1Cs3d/VIHHWb6F5Dh8iVFHz+5K5oIgxkRY3LVLdyjBX SZHILSHwwy4feA1+4qZqB7dJjjiCGSfAg6ZB9Tp8w/glhiQcnmyDacoH3wCGqX+uFleS 0NxEe1kv8l/sjsyvaMn8/90r1oYxeQssVaphbVepMO1rDUhwxqMxnZj7TWowrjujheGI rGw+xix5ILvWor1sjZfc4QfdqC0NYBMZMMzgMSAXbtYXqEg3BJsaidLLSUEDeiCnYhfj euZw== X-Gm-Message-State: ALoCoQmK+3zyj9FTnjsrxAaw6HG5e3JPyjLzVSEY1N/PSdqtqmf3Y2gMuapwnN4uiDY6MP1sIc5d MIME-Version: 1.0 X-Received: by 10.52.7.69 with SMTP id h5mr496122vda.68.1396378854067; Tue, 01 Apr 2014 12:00:54 -0700 (PDT) Received: by 10.221.21.129 with HTTP; Tue, 1 Apr 2014 12:00:53 -0700 (PDT) In-Reply-To: References: Date: Tue, 1 Apr 2014 22:00:53 +0300 Message-ID: From: Ulrich Herberg To: Andy Bierman Content-Type: multipart/alternative; boundary=20cf3030c26191aa7304f5ffc9f1 Archived-At: http://mailarchive.ietf.org/arch/msg/coman/M9dK8_mQumRlc5RI3744QmWNht8 Cc: "Mehmet \(NSN - DE/Munich\) Ersue" , "coman@ietf.org" , Carsten Bormann , "consultancy@vanderstok.org" , "Dan \(Dan\) Romascanu" Subject: Re: [coman] Purpose of this list? X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.15 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, 01 Apr 2014 19:01:02 -0000 --20cf3030c26191aa7304f5ffc9f1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am also interested in this meeting. RESTCONF for COAP is an interesting option that we have discussed in COMAN before. I'd be interested in continuing this discussion. Regards Ulrich On Tue, Apr 1, 2014 at 9:54 PM, Andy Bierman wrote: > > > > On Tue, Apr 1, 2014 at 11:02 AM, Carsten Bormann wrote: > >> > Will this be a Core WG session? >> >> Reserving time on the CoRE agenda is certainly one way to do this. >> If there is a better way to make progress on a cross-area outlook on the >> subject, I'm certainly open to suggestions. >> (And the intention certainly is to build on the work that is completing >> in OPSAWG now.) >> >> > I am very interested in attending this meeting as well. I have been doing > a bit of research on how to adapt/optimize RESTCONF for CoAP. > I think there might be enough interest in this meeting to justify a 1 hou= r > time-slot > of its own. (Scheduling without cross-area conflicts is another matter). > > > > Gr=FC=DFe, Carsten >> >> > Andy > > > _______________________________________________ > coman mailing list > coman@ietf.org > https://www.ietf.org/mailman/listinfo/coman > > --20cf3030c26191aa7304f5ffc9f1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I am also interested in this meeting. RESTCONF f= or COAP is an interesting option that we have discussed in COMAN before. I&= #39;d be interested in continuing this discussion.

Regards
Ulrich


On Tue, Apr 1, 2014 at 9:54 PM, Andy Bierman <= ;andy@yumaworks.com= > wrote:



On Tue, Apr 1= , 2014 at 11:02 AM, Carsten Bormann <cabo@tzi.org> wrote:
> Will this be a Core W= G session? 

Rese= rving time on the CoRE agenda is certainly one way to do this.
If there is a better way to make progress= on a cross-area outlook on the subject, I’m certainly open to s= uggestions.
(And the intention certainly is to build = on the work that is completing in OPSAWG now.)


I am very = interested in attending this meeting as well. I have been doing
a= bit of research on how to adapt/optimize RESTCONF for CoAP.
I think there might be enough interest in this meeting to justify a 1 hour = time-slot
of its own. (Scheduling without cross-area conflicts is another matter= ).



Gr=FC=DFe, Carst= en


Andy


_______________________________________________
coman mailing list
coman@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/coman


--20cf3030c26191aa7304f5ffc9f1-- From nobody Tue Apr 1 12:07:54 2014 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 434171A09CD; Tue, 1 Apr 2014 12:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoRwAcFfVPXg; Tue, 1 Apr 2014 12:07:50 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE0F1A09C5; Tue, 1 Apr 2014 12:07:50 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id kq14so10217167pab.24 for ; Tue, 01 Apr 2014 12:07:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=AWlIEvmy2wm5jE67QLUWFlQqa/igf9IXnsaPFqt5Vjg=; b=csHR1TCtFd2kVp2gOlUFHzm7ZUfrmHVYtpKcRhYkBc4kwZPVCYwxzyXKJmlKMRtm0/ 4CJR1tf3hFqH7lYx+pJOuXIVOwbrUi8FagJKOF7q2Fg1lSMsowYwF47oW+gxUcczmZvE e7ZfHQguHAhvZ4aFvbjqNdYNQkyqg85tx0i4qJS2+Gg8jnF57gxEhIbURTBkP95n2BJ9 cvQKDQOLQCBa16AuM99gReb6BlZo4u1HeA8DWZPuXtV3MfZ8vFOEWCZpEzDCbiKX2ayP 4FqBEMtNJCPzqLY9an+qsYMVeEIzkd5DDosEEKxA4ZrjefY7tDGwSXnD+dlODb9pwWYp Lr2g== X-Received: by 10.68.178.131 with SMTP id cy3mr11506220pbc.146.1396379267098; Tue, 01 Apr 2014 12:07:47 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.154.130 with HTTP; Tue, 1 Apr 2014 12:07:26 -0700 (PDT) In-Reply-To: References: From: Thomas Watteyne Date: Tue, 1 Apr 2014 12:07:26 -0700 X-Google-Sender-Auth: 6nO20zgVFlS1ztGdjeG488vORE0 Message-ID: To: "coman@ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org> Content-Type: multipart/alternative; boundary=047d7b6735ea2fee4604f5ffe2ca Archived-At: http://mailarchive.ietf.org/arch/msg/coman/ZTNtMB7_lUXBIlJhhITjUFebgXY Subject: Re: [coman] Purpose of this list? X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.15 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, 01 Apr 2014 19:07:52 -0000 --047d7b6735ea2fee4604f5ffe2ca Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable [CC'ing 6TiSCH ML] Andy, +1. This is an important topic for 6TiSCH. We went through the exercise of defining the interface of the 6top management sublayer in YANG [1], and there is a draft explaining how to access this interface through CoAP [2]. Similar efforts on monitoring and management are going on several WGs [3-4]; we need some federating mechanism. Thomas [1] http://tools.ietf.org/html/draft-ietf-6tisch-6top-interface [2] http://tools.ietf.org/html/draft-sudhaakar-6tisch-coap-01 [3] http://tools.ietf.org/html/draft-ietf-6lo-lowpan-mib [4] http://tools.ietf.org/html/draft-vanderstok-core-comi-03 On Tue, Apr 1, 2014 at 11:54 AM, Andy Bierman wrote: > > > > On Tue, Apr 1, 2014 at 11:02 AM, Carsten Bormann wrote: > >> > Will this be a Core WG session? >> >> Reserving time on the CoRE agenda is certainly one way to do this. >> If there is a better way to make progress on a cross-area outlook on the >> subject, I'm certainly open to suggestions. >> (And the intention certainly is to build on the work that is completing >> in OPSAWG now.) >> >> > I am very interested in attending this meeting as well. I have been doing > a bit of research on how to adapt/optimize RESTCONF for CoAP. > I think there might be enough interest in this meeting to justify a 1 hou= r > time-slot > of its own. (Scheduling without cross-area conflicts is another matter). > > > > Gr=FC=DFe, Carsten >> >> > Andy > > > _______________________________________________ > coman mailing list > coman@ietf.org > https://www.ietf.org/mailman/listinfo/coman > > --047d7b6735ea2fee4604f5ffe2ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
[CC'ing 6TiSCH ML]

Andy= ,

+1. This is an important topic for 6TiSCH.=

We went through the exercise of defin= ing the interface of the 6top management sublayer in YANG [1], and there is= a draft explaining how to access this interface through CoAP [2].

Similar efforts on monitoring and managemen= t are going on several WGs [3-4]; we need some federating mechanism.
<= div style>
Thomas

<= div style>[2] http://tools.ietf.org/html/draft-sudhaakar-6tisch-coap-01=
[4] http://tools.ietf.org/html/draft-vanderstok-core-comi-03


On Tue,= Apr 1, 2014 at 11:54 AM, Andy Bierman <andy@yumaworks.com>= wrote:



On Tue, Apr 1= , 2014 at 11:02 AM, Carsten Bormann <cabo@tzi.org> wrote:
> Will this be a Core W= G session? 

Rese= rving time on the CoRE agenda is certainly one way to do this.
If there is a better way to make progress= on a cross-area outlook on the subject, I’m certainly open to s= uggestions.
(And the intention certainly is to build = on the work that is completing in OPSAWG now.)


I am very = interested in attending this meeting as well. I have been doing
a= bit of research on how to adapt/optimize RESTCONF for CoAP.
I think there might be enough interest in this meeting to justify a 1 hour = time-slot
of its own. (Scheduling without cross-area conflicts is another matter= ).



Gr=FC=DFe, Carst= en


Andy


_______________________________________________
coman mailing list
coman@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/coman


--047d7b6735ea2fee4604f5ffe2ca-- From nobody Tue Apr 1 14:45:37 2014 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2791A089A for ; Tue, 1 Apr 2014 14:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWZoj5c46vOM for ; Tue, 1 Apr 2014 14:45:29 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2EA1A0A0A for ; Tue, 1 Apr 2014 14:45:29 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s31LjLvl011985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 1 Apr 2014 21:45:21 GMT Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s31LjLA5027431 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 1 Apr 2014 23:45:21 +0200 Received: from DEMUHTC009.nsn-intra.net (10.159.42.40) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 1 Apr 2014 23:45:20 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.10]) by DEMUHTC009.nsn-intra.net ([10.159.42.40]) with mapi id 14.03.0123.003; Tue, 1 Apr 2014 23:45:20 +0200 From: "Ersue, Mehmet (NSN - DE/Munich)" To: ext Hannes Tschofenig , "consultancy@vanderstok.org" , "Romascanu, Dan (Dan)" Thread-Topic: [coman] Purpose of this list? Thread-Index: AQHPTOYi3NVjIWVGMUSSxYL7wEwZoJr7v7XggAE9I+eAAFAM4A== Date: Tue, 1 Apr 2014 21:45:20 +0000 Message-ID: References: <53396D11.8040508@gmx.net> <9904FB1B0159DA42B0B887B7FA8119CA2E46D995@AZ-FFEXMB04.global.avaya.com> <533AECB9.2020709@gmx.net> In-Reply-To: <533AECB9.2020709@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: 3402 X-purgate-ID: 151667::1396388721-00001326-DE58C7DE/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/coman/EStq8dXmIaxPdrXBJZdnXt3NgPg Cc: "coman@ietf.org" Subject: Re: [coman] Purpose of this list? X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.15 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, 01 Apr 2014 21:45:34 -0000 As you see there is a discussion already on RESTCONF for CoAP. Mainly topics on management of networks with constrained devices, which do not have a home. Cheers,=20 Mehmet=20 > -----Original Message----- > From: coman [mailto:coman-bounces@ietf.org] On Behalf Of ext Hannes > Tschofenig > Sent: Tuesday, April 01, 2014 6:44 PM > To: consultancy@vanderstok.org; Romascanu, Dan (Dan) > Cc: coman@ietf.org > Subject: Re: [coman] Purpose of this list? >=20 > Peter, Dan, Mehmet, >=20 > given that some of the work moved over to the opsawg group what remains > left here to be discussed? >=20 > I heard you saying that this list is useful but not for *what*. >=20 > For announcing this special meeting on management you might reach a > wider audience with posts on other lists. Just a suggestion. >=20 > Ciao > Hannes >=20 >=20 >=20 > On 04/01/2014 04:19 PM, peter van der Stok wrote: > > Hi Dan, > > > > During the Core meeting it was decided that we needed a special > meeting > > on management to look at the ongoing initiatives. > > > > Peter > > > > Romascanu, Dan (Dan) schreef op 2014-04-01 16:12: > >> Hi Peter, > >> > >> What is the ' meeting on management in Toronto' that you refer to? > >> > >> I agree that it would be useful to keep this list open for a while > at > >> least. > >> > >> Thanks and Regards, > >> > >> Dan > >> > >> > >>> -----Original Message----- > >>> From: coman [mailto:coman-bounces@ietf.org] On Behalf Of peter van > der > >>> Stok > >>> Sent: Tuesday, April 01, 2014 5:09 PM > >>> To: coman@ietf.org > >>> Subject: Re: [coman] Purpose of this list? > >>> > >>> Hannes, > >>> > >>> given that we wil have a meeting on management in Toronto, led by > >>> Juergen, > >>> the list may turn out to be useful. > >>> > >>> Peter > >>> > >>> Ersue, Mehmet (NSN - DE/Munich) schreef op 2014-04-01 15:53: > >>> > Hannes, > >>> > > >>> > I think it is still beneficial to keep the Coman maillist. > >>> > The Coman community discusses from time to time issues related to > the > >>> > management of constrained devices. > >>> > > >>> > Cheers, > >>> > Mehmet > >>> > > >>> >> -----Original Message----- > >>> >> From: coman [mailto:coman-bounces@ietf.org] On Behalf Of ext > Hannes > >>> >> Tschofenig > >>> >> Sent: Monday, March 31, 2014 3:27 PM > >>> >> To: coman@ietf.org > >>> >> Subject: [coman] Purpose of this list? > >>> >> > >>> >> Hi all, > >>> >> > >>> >> I was wondering what the purpose of this list is given that some > of > >>> >> the documents have been moved over to the opsawg group. > >>> >> > >>> >> The mailing list overview page at > >>> >> https://www.ietf.org/mailman/listinfo/coman does not provide a > lot of > >>> >> details about the purpose of the group either. > >>> >> > >>> >> Is it time to close this list? > >>> >> > >>> >> Ciao > >>> >> Hannes > >>> >> > >>> > > >>> > _______________________________________________ > >>> > coman mailing list > >>> > coman@ietf.org > >>> > https://www.ietf.org/mailman/listinfo/coman > >>> > >>> _______________________________________________ > >>> coman mailing list > >>> coman@ietf.org > >>> https://www.ietf.org/mailman/listinfo/coman > > > > _______________________________________________ > > coman mailing list > > coman@ietf.org > > https://www.ietf.org/mailman/listinfo/coman From nobody Tue Apr 1 23:03:23 2014 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F00671A013A for ; Tue, 1 Apr 2014 23:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rc-tpywrr48 for ; Tue, 1 Apr 2014 23:03:15 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id CA6A41A0137 for ; Tue, 1 Apr 2014 23:03:14 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D2424FDF; Wed, 2 Apr 2014 08:03:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id shriGFxVl9Ej; Wed, 2 Apr 2014 08:03:10 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 2 Apr 2014 08:03:10 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 49F3A2002F; Wed, 2 Apr 2014 08:03:10 +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 zpfbn8t25kzo; Wed, 2 Apr 2014 08:03:09 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C0AA72002C; Wed, 2 Apr 2014 08:03:08 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 828B02C208AD; Wed, 2 Apr 2014 08:03:07 +0200 (CEST) Date: Wed, 2 Apr 2014 08:03:07 +0200 From: Juergen Schoenwaelder To: Carsten Bormann Message-ID: <20140402060307.GA75936@elstar.local> Mail-Followup-To: Carsten Bormann , "Mehmet (NSN - DE/Munich) Ersue" , "coman@ietf.org" , "Dan (Dan) Romascanu" , "consultancy@vanderstok.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/coman/Lfwc5CFQll7u1IcGHv_0TnjClSg Cc: "Mehmet \(NSN - DE/Munich\) Ersue" , "coman@ietf.org" , "consultancy@vanderstok.org" , "Dan \(Dan\) Romascanu" Subject: Re: [coman] Purpose of this list? X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.15 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, 02 Apr 2014 06:03:19 -0000 On Tue, Apr 01, 2014 at 08:02:24PM +0200, Carsten Bormann wrote: > > Will this be a Core WG session? > > Reserving time on the CoRE agenda is certainly one way to do this. > If there is a better way to make progress on a cross-area outlook on the subject, I’m certainly open to suggestions. > (And the intention certainly is to build on the work that is completing in OPSAWG now.) > As far as I recall, the idea in London was to have a meeting of interested people outside the official CORE WG meeting, e.g., on Sunday. It seems we would need more time to get an understanding what people are working on in various places and how to converge to something that can become actionable work within the IETF. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Apr 2 00:45:33 2014 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7322B1A00C9 for ; Wed, 2 Apr 2014 00:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qy5xVajR6b4v for ; Wed, 2 Apr 2014 00:45:28 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 03EA91A001B for ; Wed, 2 Apr 2014 00:45:28 -0700 (PDT) Received: from [192.168.131.137] ([80.92.119.215]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LxcbX-1X5gZ01WId-017Gg3; Wed, 02 Apr 2014 09:45:21 +0200 Message-ID: <533BBF75.3080206@gmx.net> Date: Wed, 02 Apr 2014 09:42:45 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" , "consultancy@vanderstok.org" , "Romascanu, Dan (Dan)" References: <53396D11.8040508@gmx.net> <9904FB1B0159DA42B0B887B7FA8119CA2E46D995@AZ-FFEXMB04.global.avaya.com> <533AECB9.2020709@gmx.net> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DC7aVO5SrCO42gqoOVJr0f6lcMJ0vVelT" X-Provags-ID: V03:K0:sQ2U7Fxpw4eB5LNFsQWnr43rwLK5h/NH0mMeeBpvZwYtvM6iLcG DHNuqO2egtMV9s+5KmZBn6XVVFdFrmAEA0BoFkOnHcDesZ/PxCds9/1hSgtIRQtAGzt02VF csEbSgAd+5pal8FApuQFeJwihWyrEe3uTMM5aclX8ZoSBR2+2pD/iRf/5JvLwQ4RPtSG6ri CDBYBj1x6fyDqNBCBQWFw== Archived-At: http://mailarchive.ietf.org/arch/msg/coman/AET62fYxLKu_cXg6JFXlvt4U1Lw Cc: "coman@ietf.org" Subject: Re: [coman] Purpose of this list? X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.15 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, 02 Apr 2014 07:45:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DC7aVO5SrCO42gqoOVJr0f6lcMJ0vVelT Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/01/2014 11:45 PM, Ersue, Mehmet (NSN - DE/Munich) wrote:> As you see there is a discussion already on RESTCONF for CoAP. > Mainly topics on management of networks with constrained devices, > which do not have a home. Are there specific documents to look at? Ciao Hannes >=20 > Cheers,=20 > Mehmet=20 >=20 >> -----Original Message----- >> From: coman [mailto:coman-bounces@ietf.org] On Behalf Of ext Hannes >> Tschofenig >> Sent: Tuesday, April 01, 2014 6:44 PM >> To: consultancy@vanderstok.org; Romascanu, Dan (Dan) >> Cc: coman@ietf.org >> Subject: Re: [coman] Purpose of this list? >> >> Peter, Dan, Mehmet, >> >> given that some of the work moved over to the opsawg group what remain= s >> left here to be discussed? >> >> I heard you saying that this list is useful but not for *what*. >> >> For announcing this special meeting on management you might reach a >> wider audience with posts on other lists. Just a suggestion. >> >> Ciao >> Hannes >> >> >> >> On 04/01/2014 04:19 PM, peter van der Stok wrote: >>> Hi Dan, >>> >>> During the Core meeting it was decided that we needed a special >> meeting >>> on management to look at the ongoing initiatives. >>> >>> Peter >>> >>> Romascanu, Dan (Dan) schreef op 2014-04-01 16:12: >>>> Hi Peter, >>>> >>>> What is the ' meeting on management in Toronto' that you refer to? >>>> >>>> I agree that it would be useful to keep this list open for a while >> at >>>> least. >>>> >>>> Thanks and Regards, >>>> >>>> Dan >>>> >>>> >>>>> -----Original Message----- >>>>> From: coman [mailto:coman-bounces@ietf.org] On Behalf Of peter van >> der >>>>> Stok >>>>> Sent: Tuesday, April 01, 2014 5:09 PM >>>>> To: coman@ietf.org >>>>> Subject: Re: [coman] Purpose of this list? >>>>> >>>>> Hannes, >>>>> >>>>> given that we wil have a meeting on management in Toronto, led by >>>>> Juergen, >>>>> the list may turn out to be useful. >>>>> >>>>> Peter >>>>> >>>>> Ersue, Mehmet (NSN - DE/Munich) schreef op 2014-04-01 15:53: >>>>>> Hannes, >>>>>> >>>>>> I think it is still beneficial to keep the Coman maillist. >>>>>> The Coman community discusses from time to time issues related to >> the >>>>>> management of constrained devices. >>>>>> >>>>>> Cheers, >>>>>> Mehmet >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: coman [mailto:coman-bounces@ietf.org] On Behalf Of ext >> Hannes >>>>>>> Tschofenig >>>>>>> Sent: Monday, March 31, 2014 3:27 PM >>>>>>> To: coman@ietf.org >>>>>>> Subject: [coman] Purpose of this list? >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> I was wondering what the purpose of this list is given that some >> of >>>>>>> the documents have been moved over to the opsawg group. >>>>>>> >>>>>>> The mailing list overview page at >>>>>>> https://www.ietf.org/mailman/listinfo/coman does not provide a >> lot of >>>>>>> details about the purpose of the group either. >>>>>>> >>>>>>> Is it time to close this list? >>>>>>> >>>>>>> Ciao >>>>>>> Hannes >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> coman mailing list >>>>>> coman@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/coman >>>>> >>>>> _______________________________________________ >>>>> coman mailing list >>>>> coman@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/coman >>> >>> _______________________________________________ >>> coman mailing list >>> coman@ietf.org >>> https://www.ietf.org/mailman/listinfo/coman >=20 --DC7aVO5SrCO42gqoOVJr0f6lcMJ0vVelT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTO791AAoJEGhJURNOOiAtC38H/0MPrDwcKfRCKu2ezBk6Y5AU K0dNgNCqD78vIbIxPRLep1kZZ8qUudALQY0ZgsYtSoYyIdtvCAbg/qaVG4v7If/P mOnQ7fb2erTI6QsSplCLIb9hhDcpocoYCpCINh8nYhH0emNliJ4ynFqZ414BOIfZ 0/HfxzIupCUJ+KaFJSjJVkW2HC+Fx6gsjLXlmyjXZv/9/zQ677MulyEIUCI4h4Rn FczgYUFI9DLKunUeLLmbpjSIVwppHWegv0nLROPtjwLckgsSsYlyfdP1D+LDuWHV dXmg/+FDdkI3V3KavVvhAG94yp6nlxAbFNdemluo/2EwTvm7v6Jl71bq52OOqRI= =ICbD -----END PGP SIGNATURE----- --DC7aVO5SrCO42gqoOVJr0f6lcMJ0vVelT-- From nobody Wed Apr 2 00:46:38 2014 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A261A00CF for ; Wed, 2 Apr 2014 00:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RETctgB4TtXP for ; Wed, 2 Apr 2014 00:46:32 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 165871A00C9 for ; Wed, 2 Apr 2014 00:46:32 -0700 (PDT) Received: from [192.168.131.137] ([80.92.119.215]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MJFBe-1WSW3V29f8-002lzq for ; Wed, 02 Apr 2014 09:46:27 +0200 Message-ID: <533BBFB7.2000100@gmx.net> Date: Wed, 02 Apr 2014 09:43:51 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "coman@ietf.org" X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ACnF36Oi7btDdXK0IP1borrNkkTgAvp0n" X-Provags-ID: V03:K0:AS+5c5An0jnxHVXJbVMRLaHu6IrisBLr1wsyALguKKjFLSUFJn2 31V9L+w7VGaJblAAieYErkU8V4NWzycs9XSf6V89eqarIQLYEXaq9J+8qtYuvjvyznFzhSd SSc2510VmokkCARuNkknEpZu0hfTLuQ8/HLD50fIJbpVUmJVVNXKKCE0p+beE3C5K4Y9Mjt /hlcFsi9E7HHRrZPN8WRA== Archived-At: http://mailarchive.ietf.org/arch/msg/coman/FyMxJbt_yZEAnaDY4BsWth8Ud6o Subject: [coman] Device Classes? X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.15 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, 02 Apr 2014 07:46:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ACnF36Oi7btDdXK0IP1borrNkkTgAvp0n Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable A question out of curiosity: The LWIG terminology document defines classes of devices and makes statements about what can and cannot be done for each class. IMHO these classes are about end devices rather than constrained routers and switches. Guys in the network management environment seem to care a lot about the management of network nodes. What are the expectations about RAM, flash size, CPU requirements, etc. for these constrained routers/switches? Ciao Hannes --ACnF36Oi7btDdXK0IP1borrNkkTgAvp0n Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTO7+3AAoJEGhJURNOOiAtfYgH/RZa9zVh7mWq3lRBX9bHmnTf B87JcvzN73HLF8mFTwWJR/NgUOp0glD8VxVuhD5YtF8ih+rhJCxGetodqQNn1/Td QX6oI5s4XmRlXnt6FSEm2OFkm1WRoF2xLr6WCVoqehzKwJjgG3WgFk38J9uPlRUm jKdhIMVm6Mk//5OgfrCNYqNg5I/87Ko5Hf4d+UUq+wgJiVXzPXZFsQXHA42U+Kvh blzWj41BfoxLl/Sb6LyMn5ik8PGjDwTlF2X+O6sDKQVARFglzy3Pk5i0I4MG8qdO qWlaIAlmAKvZLDDJFSwRpO+QpkM3OuqEMb7vURdPZITDHMeZjLincYcD7jywis8= =M+/B -----END PGP SIGNATURE----- --ACnF36Oi7btDdXK0IP1borrNkkTgAvp0n-- From nobody Thu Apr 3 22:47:45 2014 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC3E81A02F9 for ; Thu, 3 Apr 2014 22:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdxbvzMUhA9F for ; Thu, 3 Apr 2014 22:47:40 -0700 (PDT) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id A313E1A02BE for ; Thu, 3 Apr 2014 22:47:40 -0700 (PDT) Received: by mail-pb0-f43.google.com with SMTP id um1so2958041pbc.2 for ; Thu, 03 Apr 2014 22:47:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=HN7Ft7wLvhCKixPVyHQJ/gHKui0UlEgE2LTBQEiI/PE=; b=izHZn6CH87MXBP2a3NCtiudIqoQbj5MCAnEdEKLAVos2XtHVbWwa2w9YQOGvSjRYgL rxn3ue369MB8LrgVmdKVHkoFmTt/2DMXqhRNQsZxn4rPWyPgVc44g9B7wALk5xECb1oI FmoU1vofdEOzrZo1DT2O+CVXz1/Z8hOCR5KEKDrigz59YBlxcR+7VCnq/Y/P2R/GSPTi SJYbiBhJuXq3Rizib7I2gBXhM8+EVENCEskzURlkn38dLFNR+11N0PwXiMP0FIg3kXj2 X+8jAhbmCPeTxTAYAgg1YBe1gamYwWbZ1XinimP0a+7dvPr7is9m5JtLMhw6z9s9aOqc Lgng== X-Received: by 10.68.254.5 with SMTP id ae5mr12397315pbd.83.1396590456329; Thu, 03 Apr 2014 22:47:36 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.154.130 with HTTP; Thu, 3 Apr 2014 22:47:16 -0700 (PDT) In-Reply-To: <533BBFB7.2000100@gmx.net> References: <533BBFB7.2000100@gmx.net> From: Thomas Watteyne Date: Thu, 3 Apr 2014 22:47:16 -0700 X-Google-Sender-Auth: Tvyh0PkDVgW7mhp-lc6qlY6iFuU Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=047d7b2e0a8b0bdbfa04f6310ed3 Archived-At: http://mailarchive.ietf.org/arch/msg/coman/QEiiVJTRK8zUp95hwbYulHMfRyQ Cc: "coman@ietf.org" Subject: Re: [coman] Device Classes? X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.15 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, 04 Apr 2014 05:47:45 -0000 --047d7b2e0a8b0bdbfa04f6310ed3 Content-Type: text/plain; charset=ISO-8859-1 Hannes, I would really like a solution which allows monitoring and management of C1 devices [1]. If built around protocols which have been designed for these types of devices (e.g. CoAP), I don't believe adding this functionality to a node will have a large impact on code footprint. What do others think? Thomas [1] http://tools.ietf.org/html/draft-ietf-lwig-terminology-07#section-3 On Wed, Apr 2, 2014 at 12:43 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > A question out of curiosity: > > The LWIG terminology document defines classes of devices and makes > statements about what can and cannot be done for each class. > > IMHO these classes are about end devices rather than constrained routers > and switches. Guys in the network management environment seem to care a > lot about the management of network nodes. > > What are the expectations about RAM, flash size, CPU requirements, etc. > for these constrained routers/switches? > > Ciao > Hannes > > > _______________________________________________ > coman mailing list > coman@ietf.org > https://www.ietf.org/mailman/listinfo/coman > > --047d7b2e0a8b0bdbfa04f6310ed3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hannes,

I would really like a solution = which allows monitoring and management of C1 devices [1]. If built around p= rotocols which have been designed for these types of devices (e.g. CoAP), I= don't believe adding this functionality to a node will have a large im= pact on code footprint.

What do others think?



On Wed,= Apr 2, 2014 at 12:43 AM, Hannes Tschofenig <hannes.tschofenig@g= mx.net> wrote:
A question out of curiosity:

The LWIG terminology document defines classes of devices and makes
statements about what can and cannot be done for each class.

IMHO these classes are about end devices rather than constrained routers and switches. Guys in the network management environment seem to care a
lot about the management of network nodes.

What are the expectations about RAM, flash size, CPU requirements, etc.
for these constrained routers/switches?

Ciao
Hannes


_______________________________________________
coman mailing list
coman@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/coman


--047d7b2e0a8b0bdbfa04f6310ed3-- From nobody Fri Apr 4 00:24:45 2014 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7411A00FD for ; Fri, 4 Apr 2014 00:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4_WJlD35Tj3 for ; Fri, 4 Apr 2014 00:24:39 -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 96F6A1A0019 for ; Fri, 4 Apr 2014 00:24:39 -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.5/8.14.5) with ESMTP id s347OTvU011811; Fri, 4 Apr 2014 09:24:29 +0200 (CEST) Received: from [134.102.116.173] (unknown [134.102.116.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C135FA26; Fri, 4 Apr 2014 09:24:28 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann In-Reply-To: <533BBFB7.2000100@gmx.net> Date: Fri, 4 Apr 2014 09:24:27 +0200 X-Mao-Original-Outgoing-Id: 418289067.161595-bff6f4929a91806148159107d3fab348 Content-Transfer-Encoding: quoted-printable Message-Id: <893C4FAC-437D-4140-9832-A9ABA2D1518A@tzi.org> References: <533BBFB7.2000100@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/coman/idgF1MVFrdCVj945xQisXGP8_9E Cc: "coman@ietf.org" Subject: Re: [coman] Device Classes? X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.15 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, 04 Apr 2014 07:24:44 -0000 On 02 Apr 2014, at 09:43, Hannes Tschofenig = wrote: > IMHO these classes are about end devices rather than constrained = routers > and switches. Actually, the device classes are about nodes in general (hosts and = routers). The document then goes on to say: (An alternative name, when the properties as a network node are not in focus, is "constrained device=94.) Protocols such as RPL take great care to enable the use of class-1 = devices as routers (non-storing mode). Constrained management will need to match that. A more important dichotomy than host vs. router may be monitoring vs. = configuration. Gr=FC=DFe, Carsten From nobody Fri Apr 4 02:30:30 2014 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E84791A03D1 for ; Fri, 4 Apr 2014 02:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqT_YyvgHswy for ; Fri, 4 Apr 2014 02:30:24 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 592171A001D for ; Fri, 4 Apr 2014 02:30:24 -0700 (PDT) Received: from [192.168.131.138] ([80.92.119.215]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LZiLk-1WtCdy1W0q-00lVna; Fri, 04 Apr 2014 11:30:18 +0200 Message-ID: <533E75A9.5080003@gmx.net> Date: Fri, 04 Apr 2014 11:04:41 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Carsten Bormann References: <533BBFB7.2000100@gmx.net> <893C4FAC-437D-4140-9832-A9ABA2D1518A@tzi.org> In-Reply-To: <893C4FAC-437D-4140-9832-A9ABA2D1518A@tzi.org> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="XinSuwXHU2jAt9IA6nToWthR4ABfXcqtt" X-Provags-ID: V03:K0:xUvx6YFEiw20WTtK7z3HuW3OJ7/RqY/k1qAZ9CsKe8xXn4mviO3 c0rlf+oleDm1o14Jes8ZpULLeHj+nkzqZ3NxjAU1xOesmmQESNxDwzgDGwxE4ZXD37QoT8S QySkMMDldHyAUocGnDSHkYsaH1ek5WMKtyBvZKZiEgjaI961evKT7rcn2EOs3mOvtIQMuci fPAhq/iIsqQkm/xWShTdw== Archived-At: http://mailarchive.ietf.org/arch/msg/coman/FFqppN3oBZ0We0skIpl85UexnNk Cc: "coman@ietf.org" Subject: Re: [coman] Device Classes? X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.15 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, 04 Apr 2014 09:30:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XinSuwXHU2jAt9IA6nToWthR4ABfXcqtt Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Carsten, I am getting more and more uncomfortable with these classes due to the fuzzy definition. I wonder whether someone has tried to implement a router with * an IPv6 stack * RPL * security stuff (such as DTLS, EAP, PANA) * network management protocol (as Thomas was asking for) * CoAP * DNS * software update mechanism * + the actual application on a class 1 device. Ciao Hannes On 04/04/2014 09:24 AM, Carsten Bormann wrote: > On 02 Apr 2014, at 09:43, Hannes Tschofenig = wrote: >=20 >> IMHO these classes are about end devices rather than constrained route= rs >> and switches. >=20 > Actually, the device classes are about nodes in general (hosts and rout= ers). The document then goes on to say: >=20 > (An alternative name, when the properties as a network node are not > in focus, is "constrained device=94.) >=20 > Protocols such as RPL take great care to enable the use of class-1 devi= ces as routers (non-storing mode). > Constrained management will need to match that. >=20 > A more important dichotomy than host vs. router may be monitoring vs. c= onfiguration. >=20 > Gr=FC=DFe, Carsten >=20 > _______________________________________________ > coman mailing list > coman@ietf.org > https://www.ietf.org/mailman/listinfo/coman >=20 --XinSuwXHU2jAt9IA6nToWthR4ABfXcqtt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTPnWpAAoJEGhJURNOOiAtXrYH/jkmy/YyVZ+NIeS7BsxQ0gay LZC7ibR+qKuu8wDhr7o0r04/xl83hunnp8MU8RRBLWc3kdiIOOLrREYIWa2QyQOA Y34Ul9hyKpEewujpAfevLzddVKYnTE4CwiMPAcQUgyGTE+zjZqbWHg6rYEkUvbax uIlfpO2PaWklGNn2AKhuQ251AX+E7QwsuNxlg/FQwU1azI9095d49WY4xfxgT6sb CGfpVZdhXjcEkNbZZe4wdmjokK3tqABYmX4HyXX43PKvNsHoiZOOs7eIOTuFuedg L3H9tC/X00vQzyvVyCj4ie/1xryvu/1qRSaFr3uf3gY0lNnzTsfLzKMDZEFIY78= =vsb8 -----END PGP SIGNATURE----- --XinSuwXHU2jAt9IA6nToWthR4ABfXcqtt-- From nobody Fri Apr 4 02:56:10 2014 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 743F61A0137 for ; Fri, 4 Apr 2014 02:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2Raw3ruUw8Q for ; Fri, 4 Apr 2014 02:56:05 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 352931A004D for ; Fri, 4 Apr 2014 02:56:05 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7E40A1054; Fri, 4 Apr 2014 11:56:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 0unreYd32_xP; Fri, 4 Apr 2014 11:55:59 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 4 Apr 2014 11:55:58 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id CFED02002F; Fri, 4 Apr 2014 11:55:57 +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 M3pP4c7gohuT; Fri, 4 Apr 2014 11:55:57 +0200 (CEST) Received: from exchange.jacobs-university.de (shubcas03.jacobs.jacobs-university.de [10.70.0.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.jacobs-university.de (Postfix) with ESMTPS id 0DFED2002C; Fri, 4 Apr 2014 11:55:57 +0200 (CEST) Received: from SXCHMB01.jacobs.jacobs-university.de ([fe80::c1f:c30f:99ac:df0c]) by SHUBCAS05.jacobs.jacobs-university.de ([::1]) with mapi id 14.03.0181.006; Fri, 4 Apr 2014 11:55:56 +0200 From: "Sehgal, Anuj" To: Hannes Tschofenig Thread-Topic: [coman] Device Classes? Thread-Index: AQHPTketD8PYZfapr0ukiqo6WmJRuZsA77uAgAAcAoCAAA5SgA== Date: Fri, 4 Apr 2014 09:55:55 +0000 Message-ID: <466C8694-13D0-45B2-8BC6-BEA22C9D85B6@jacobs-university.de> References: <533BBFB7.2000100@gmx.net> <893C4FAC-437D-4140-9832-A9ABA2D1518A@tzi.org> <533E75A9.5080003@gmx.net> In-Reply-To: <533E75A9.5080003@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.50.244.234] Content-Type: text/plain; charset="Windows-1252" Content-ID: <09F7A325916F0A42992D03096B684A96@jacobs.jacobs-university.de> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/coman/dgUg_p8-JrOiXkNgyDWiVIXlwgM Cc: "coman@ietf.org" , Carsten Bormann Subject: Re: [coman] Device Classes? X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.15 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, 04 Apr 2014 09:56:09 -0000 Hi, I have on several occasions used Contiki to implement applications using so= me combination of the following stack on Class 1 devices (TelosB): > I wonder whether someone has tried to implement a router with > * an IPv6 stack > * RPL > * network management protocol (as Thomas was asking for) > * CoAP > * + the actual application After fitting all this in, there really is no space left for security (DTLS= , etc.).=20 Fitting DNS should not be too complicated provided we knock off something f= rom this list (either CoAP or network management protocol, SNMP in our case= ), but I say this based on experience with an mDNS implementation we did a = few years ago that works on AVR Raven devices (closer to Class 2).=20 In general, a basic Contiki 2.6 system (minus CoAP from above) takes up abo= ut 85% of Flash and statically allocated RAM on a TelosB (Class 1). Adding = CoAP and a network management protocol will push this further, with nearly = no space left. In fact, if the data model is too large or complicated for t= he network management protocol, then chances are that it too would not fit = either. Similar constraints apply to CoAP as well. Working with CoAP up to = Contiki 2.6, while using TelosB (Class 1), was also quite a struggle. At be= st we were able to work with a handful of resources, since the amount of me= mory left over was not too much. I have not checked while writing this email, but at least in the past it wa= s the RPL implementation that would take a significant amount of resources.= This was largely due to non-storing mode not being implemented, but it wou= ld seem that Contiki 2.7 does have the option to enable non-storing mode. T= his might help reduce resource consumption further. When we attempted an implementation of DTLS, we used the AVR Raven (Class 2= ) because TelosB (Class 1) did not have enough resources to function with i= t. Regards, Anuj > On 04/04/2014 09:24 AM, Carsten Bormann wrote: >> On 02 Apr 2014, at 09:43, Hannes Tschofenig = wrote: >>=20 >>> IMHO these classes are about end devices rather than constrained router= s >>> and switches. >>=20 >> Actually, the device classes are about nodes in general (hosts and route= rs). The document then goes on to say: >>=20 >> (An alternative name, when the properties as a network node are not >> in focus, is "constrained device=94.) >>=20 >> Protocols such as RPL take great care to enable the use of class-1 devic= es as routers (non-storing mode). >> Constrained management will need to match that. >>=20 >> A more important dichotomy than host vs. router may be monitoring vs. co= nfiguration. >>=20 >> Gr=FC=DFe, Carsten >>=20 >> _______________________________________________ >> coman mailing list >> coman@ietf.org >> https://www.ietf.org/mailman/listinfo/coman >>=20 >=20 > _______________________________________________ > coman mailing list > coman@ietf.org > https://www.ietf.org/mailman/listinfo/coman From nobody Fri Apr 4 03:25:38 2014 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B60AC1A00D8 for ; Fri, 4 Apr 2014 03:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntYmec4ivwpW for ; Fri, 4 Apr 2014 03:25:32 -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 E5D221A012B for ; Fri, 4 Apr 2014 03:25:31 -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.5/8.14.5) with ESMTP id s34APLYX002893; Fri, 4 Apr 2014 12:25:21 +0200 (CEST) Received: from eduroam-pool7-1021.wlan.uni-bremen.de (eduroam-pool7-1021.wlan.uni-bremen.de [134.102.115.253]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A23ABBE4; Fri, 4 Apr 2014 12:25:21 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann In-Reply-To: <533E75A9.5080003@gmx.net> Date: Fri, 4 Apr 2014 12:25:18 +0200 X-Mao-Original-Outgoing-Id: 418299918.213122-eb3cfca7eecc3ab33de22819e927f9e3 Content-Transfer-Encoding: quoted-printable Message-Id: <8D653B3C-E678-4A66-9798-978950977694@tzi.org> References: <533BBFB7.2000100@gmx.net> <893C4FAC-437D-4140-9832-A9ABA2D1518A@tzi.org> <533E75A9.5080003@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/coman/7LuTCoNn6DOcfwNcj3k1sPs81VU Cc: "coman@ietf.org" Subject: Re: [coman] Device Classes? X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.15 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, 04 Apr 2014 10:25:36 -0000 On 04 Apr 2014, at 11:04, Hannes Tschofenig = wrote: > Hi Carsten, >=20 >=20 > I am getting more and more uncomfortable with these classes due to the > fuzzy definition. >=20 > I wonder whether someone has tried to implement a router with > * an IPv6 stack > * RPL > * security stuff (such as DTLS, EAP, PANA) > * network management protocol (as Thomas was asking for) > * CoAP > * DNS > * software update mechanism > * + the actual application >=20 > on a class 1 device. Well, that exactly is the problem. The biggest issue here is the software update mechanism, if you want = that to work over the air. (Generally, to make a full over the air software update work on a system = with in-place execution from Flash and very small amounts of RAM you = need to structure the Flash-based code in a very special way.) Apart from that, leave out EAP/PANA, DNS, and this is doable. Gr=FC=DFe, Carsten From nobody Fri Apr 4 05:01:12 2014 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF231A0144 for ; Fri, 4 Apr 2014 05:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8UU8QOKR728 for ; Fri, 4 Apr 2014 05:01:06 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id B1F991A0141 for ; Fri, 4 Apr 2014 05:01:05 -0700 (PDT) Received: from [192.168.131.138] ([80.92.119.215]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MLfLH-1WVlge15jH-000tPz; Fri, 04 Apr 2014 14:00:59 +0200 Message-ID: <533E9864.4060806@gmx.net> Date: Fri, 04 Apr 2014 13:32:52 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Carsten Bormann References: <533BBFB7.2000100@gmx.net> <893C4FAC-437D-4140-9832-A9ABA2D1518A@tzi.org> <533E75A9.5080003@gmx.net> <8D653B3C-E678-4A66-9798-978950977694@tzi.org> In-Reply-To: <8D653B3C-E678-4A66-9798-978950977694@tzi.org> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="F3vArnQIS59fPRUlqvk3cqc1A0Xc1nEM4" X-Provags-ID: V03:K0:CNBlRxdz1EVqxdESwlrd9JyM6Edekm6A6QjBs1u5tLx8nxsTjKK U5kjNhBB3FYwxq/+jbgVI6spa5kd9xVIIdnVSXDi8aklb0czEPThxU9qV5SGXUVU6veUIBI JUFxfOyloRaCwgw6QmBVPFqeIz4KWm1CUgmYG+lb7fGeXkjZnx3YsMHOxg2RvSPMYgo2lNO LdvyErR+bNp0o0vbLjveA== Archived-At: http://mailarchive.ietf.org/arch/msg/coman/bEifiFLdEOflS6SiA3MRx0wOaFM Cc: "coman@ietf.org" Subject: Re: [coman] Device Classes? X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.15 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, 04 Apr 2014 12:01:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --F3vArnQIS59fPRUlqvk3cqc1A0Xc1nEM4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable For me the software update mechanism is extremely important since it is not just a way to replace the entire firmware but also to provision certain protocol parameters. For example, in the DICE DTLS Profile document there are various information elements that may need to be changed over the lifetime of the device, such as trust anchors and CRL-related information. You also cannot omit EAP/PANA from that list since many devices will likely need to have a way to authenticate to the network. Of course, with a properly chosen EAP method the additional code requirements can be kept fairly small but it will not be zero. Ciao Hannes On 04/04/2014 12:25 PM, Carsten Bormann wrote: > On 04 Apr 2014, at 11:04, Hannes Tschofenig = wrote: >=20 >> Hi Carsten, >> >> >> I am getting more and more uncomfortable with these classes due to the= >> fuzzy definition. >> >> I wonder whether someone has tried to implement a router with >> * an IPv6 stack >> * RPL >> * security stuff (such as DTLS, EAP, PANA) >> * network management protocol (as Thomas was asking for) >> * CoAP >> * DNS >> * software update mechanism >> * + the actual application >> >> on a class 1 device. >=20 > Well, that exactly is the problem. > The biggest issue here is the software update mechanism, if you want th= at to work over the air. > (Generally, to make a full over the air software update work on a syste= m with in-place execution from Flash and very small amounts of RAM you ne= ed to structure the Flash-based code in a very special way.) > Apart from that, leave out EAP/PANA, DNS, and this is doable. >=20 > Gr=FC=DFe, Carsten >=20 --F3vArnQIS59fPRUlqvk3cqc1A0Xc1nEM4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTPphkAAoJEGhJURNOOiAteGgH+gNt5Y39BLbxKOvM+aeFY2WF pamWzGSSJCXFORinG/zDQCJYNssRKv2TK6scnwptM0EXTKUxvnVPpXCYP9jdMVix QmbU0QqB0NEZl71podOsSrPN5eznxBNZGIpwMFICdnnmTRla8LdHazbvOYciQFSc WQIglAT3SSARvBKdoTvQOwYrkv6dkyPMM7UQQHb0PtSd7Pw67ZeeIYKE/ijXlZIn ccoOBi++6VBuEQ71bENz4S8ZETuHwjpYSlS6T3VDIpIn8nNGiQhtZs80xRe8aDue 9BBD33mrMC1HrVqSz+7G7Kmta4f4hLvX6CBv+n39hRRzuUhPm93xRXffGcH924Y= =bil9 -----END PGP SIGNATURE----- --F3vArnQIS59fPRUlqvk3cqc1A0Xc1nEM4-- From nobody Fri Apr 4 05:09:03 2014 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD6D1A0037 for ; Fri, 4 Apr 2014 05:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTMjUCZ947hm for ; Fri, 4 Apr 2014 05:08:57 -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 F18CD1A0141 for ; Fri, 4 Apr 2014 05:08:56 -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.5/8.14.5) with ESMTP id s34C8j42022832; Fri, 4 Apr 2014 14:08:45 +0200 (CEST) Received: from eduroam-pool7-1021.wlan.uni-bremen.de (eduroam-pool7-1021.wlan.uni-bremen.de [134.102.115.253]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 097E9C8F; Fri, 4 Apr 2014 14:08:39 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann In-Reply-To: <533E9864.4060806@gmx.net> Date: Fri, 4 Apr 2014 14:08:38 +0200 X-Mao-Original-Outgoing-Id: 418306118.175786-8f940eed4fea34b9fb7ef8fa0d6759ef Content-Transfer-Encoding: quoted-printable Message-Id: References: <533BBFB7.2000100@gmx.net> <893C4FAC-437D-4140-9832-A9ABA2D1518A@tzi.org> <533E75A9.5080003@gmx.net> <8D653B3C-E678-4A66-9798-978950977694@tzi.org> <533E9864.4060806@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/coman/nD07CzH197CcTMskkjKstchRyBM Cc: "coman@ietf.org" Subject: Re: [coman] Device Classes? X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.15 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, 04 Apr 2014 12:09:02 -0000 On 04 Apr 2014, at 13:32, Hannes Tschofenig = wrote: > For me the software update mechanism is extremely important since it = is > not just a way to replace the entire firmware but also to provision > certain protocol parameters. Provisioning protocol parameters is one CoAP PUT to the right resource. = Cf. OMA LWM2M. (They also do define a firmware update mechanism, but that seems to = presume the device has space for a complete firmware image.) Replacing the software that is running during the software update is the = fun part, and that is somewhat expensive to support (add the requirement = for a rollback capability for a realistic scenario). > You also cannot omit EAP/PANA from that list since many devices will > likely need to have a way to authenticate to the network. If you want to do this the SEP2.0 way, you need EAP/PANA. (SEP2.0 is targeting class-2+, not class-1.) Gr=FC=DFe, Carsten From nobody Fri Apr 4 05:14:20 2014 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA981A0037 for ; Fri, 4 Apr 2014 05:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mjxYZjio01I for ; Fri, 4 Apr 2014 05:14:13 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 47FC01A0150 for ; Fri, 4 Apr 2014 05:14:13 -0700 (PDT) Received: from [192.168.131.138] ([80.92.119.215]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MGjL7-1WJ6is21oX-00DULf; Fri, 04 Apr 2014 14:14:07 +0200 Message-ID: <533E9B6B.1080602@gmx.net> Date: Fri, 04 Apr 2014 13:45:47 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Carsten Bormann References: <533BBFB7.2000100@gmx.net> <893C4FAC-437D-4140-9832-A9ABA2D1518A@tzi.org> <533E75A9.5080003@gmx.net> <8D653B3C-E678-4A66-9798-978950977694@tzi.org> <533E9864.4060806@gmx.net> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7fKAlivN7n0LVR3IGprn3lPBiHxBQCS5C" X-Provags-ID: V03:K0:g2T+Zct0AIyycgd+dd4tarIBmRZ8Lgi3fpXPoyo6jzns0VEPP68 RDL0ykU8g/LZYlYWvrJR9FzGIuTF2xheZoZYxIbvqKzHkyoLI3C4hCeAxb74bdAvJ+tsYxU UGR35lmop/lDPkM0fzlrzPQjp1UKijmMbj0tIRFDF6tTBPdNkKL6/umMaH8Wy+cY67O2oI0 ufRhJmpF2aoKWBDNcBzCg== Archived-At: http://mailarchive.ietf.org/arch/msg/coman/Yn3cHoR4a-Q5qXkTqTruFEsfq8M Cc: "coman@ietf.org" Subject: Re: [coman] Device Classes? X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.15 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, 04 Apr 2014 12:14:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7fKAlivN7n0LVR3IGprn3lPBiHxBQCS5C Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Carsten. On 04/04/2014 02:08 PM, Carsten Bormann wrote: > On 04 Apr 2014, at 13:32, Hannes Tschofenig = wrote: >=20 >> For me the software update mechanism is extremely important since it i= s >> not just a way to replace the entire firmware but also to provision >> certain protocol parameters. >=20 > Provisioning protocol parameters is one CoAP PUT to the right resource.= Cf. OMA LWM2M. > (They also do define a firmware update mechanism, but that seems to pre= sume the device has space for a complete firmware image.) That is exactly the question I raised when it comes to network management= =2E I don't understand what network management protocol add beyond what is already there with CoAP. Of course, you could replace CoAP entirely with SNMP (as Juergen had suggested). >=20 > Replacing the software that is running during the software update is th= e fun part, and that is somewhat expensive to support (add the requiremen= t for a rollback capability for a realistic scenario). >=20 Sure. Software updates are not fun. >> You also cannot omit EAP/PANA from that list since many devices will >> likely need to have a way to authenticate to the network. >=20 > If you want to do this the SEP2.0 way, you need EAP/PANA. > (SEP2.0 is targeting class-2+, not class-1.) With devices that are in direct connection with each other you could argue that there is no need for DTLS and alike since you will have to deal with the pairing procedure at the lower layer. Many devices fall into that category. If that's not the case I believe you cannot assume that no network access authentication will be needed. Ciao Hannes >=20 > Gr=FC=DFe, Carsten >=20 --7fKAlivN7n0LVR3IGprn3lPBiHxBQCS5C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTPptrAAoJEGhJURNOOiAtEnYH/ine/66sEefXJJlirfAZFOM8 TQYpFHmPqV0Z2oJGusFSMNjzqnUAT5Z2DgbEpKkCi7RJK+c0+qRxu6j7f3FZPDKG PY8QODxjL9y8FSQhA9zvhmEfrlAP0bVLYTqJH4o4OFaxif0F0Mo4v2DXjVg7IgAb G8/jMCVixL1da+GFjTDcd79WTnfKWy3UTZEsIzZAhMfl4Ay1VUdoXdmpYXcJQVzk TGW2BuUbk0pKkmApWy0yHqBxjQAhC3Ce2+MTjnbB3tUEgeifr3FaRHR0nK2pnJGP jsL2pLy0Roat1B3b4tfAOOARdU9WqIjYAz7R5DzdYkWrfO5z9NUMtSkRIUFEy90= =lnM5 -----END PGP SIGNATURE----- --7fKAlivN7n0LVR3IGprn3lPBiHxBQCS5C-- From nobody Fri Apr 4 05:17:20 2014 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF191A0150 for ; Fri, 4 Apr 2014 05:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXZQvSftkAnn for ; Fri, 4 Apr 2014 05:17:13 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0371A0037 for ; Fri, 4 Apr 2014 05:17:13 -0700 (PDT) Received: from [192.168.131.138] ([80.92.119.215]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MFMEG-1WHjhO0fhc-00EQR3; Fri, 04 Apr 2014 14:16:58 +0200 Message-ID: <533E9C14.3080006@gmx.net> Date: Fri, 04 Apr 2014 13:48:36 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Sehgal, Anuj" References: <533BBFB7.2000100@gmx.net> <893C4FAC-437D-4140-9832-A9ABA2D1518A@tzi.org> <533E75A9.5080003@gmx.net> <466C8694-13D0-45B2-8BC6-BEA22C9D85B6@jacobs-university.de> In-Reply-To: <466C8694-13D0-45B2-8BC6-BEA22C9D85B6@jacobs-university.de> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="SkSg5P9UeuRNmCMVkVgwgNSiOWTlxWrfj" X-Provags-ID: V03:K0:WIPOUErgoITpSC5UvEPMgnGHJEEww3jNQSNN02sEjtPwdTuXS+9 tNY8PJb8Bus2s8Pn2iWHRhwtnGun7lZJXAFhmWCzokZHwr/XThyegWOHjeSYFG4uHGhoTAN i3cOPLF61Tr9otBwM3K1n5LjSTZMvWpvJAeDRZXt8P1/mg9WvsiQKbkNFZYAAmgPy2rSo2h 37+FpCLwjdrDMmiW0DWnw== Archived-At: http://mailarchive.ietf.org/arch/msg/coman/NxrzdkP112FiWrOLP_iCBnKcljs Cc: "coman@ietf.org" , Carsten Bormann Subject: Re: [coman] Device Classes? X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.15 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, 04 Apr 2014 12:17:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SkSg5P9UeuRNmCMVkVgwgNSiOWTlxWrfj Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Anuj, Thanks for the feedback. Your data confirmed my guess. To me it would make sense to make different assumptions about end devices and routers since they have different requirements. For a router I might even be convinced that network management protocols are useful but I am not at all convinced that end devices should run them. Also, as I argued on other lists before I see a lot of overlap between * network management when also used to retrieve the actual data of the application (+ the management of the software) * CoAP (when a software update mechanism has to be implemented anyway). If we ever want any interoperability then the approach of letting thousand flowers bloom isn't going to work very well. Sometimes saying "no" to some protocols is a good thing. (Btw, I am also included to say no to all the IPsec/IKEv2 efforts for constrained devices= =2E) Ciao Hannes On 04/04/2014 11:55 AM, Sehgal, Anuj wrote: > Hi, >=20 > I have on several occasions used Contiki to implement applications usin= g some combination of the following stack on Class 1 devices (TelosB): >=20 >> I wonder whether someone has tried to implement a router with >> * an IPv6 stack >> * RPL >> * network management protocol (as Thomas was asking for) >> * CoAP >> * + the actual application >=20 > After fitting all this in, there really is no space left for security (= DTLS, etc.).=20 >=20 > Fitting DNS should not be too complicated provided we knock off somethi= ng from this list (either CoAP or network management protocol, SNMP in ou= r case), but I say this based on experience with an mDNS implementation w= e did a few years ago that works on AVR Raven devices (closer to Class 2)= =2E=20 >=20 > In general, a basic Contiki 2.6 system (minus CoAP from above) takes up= about 85% of Flash and statically allocated RAM on a TelosB (Class 1). A= dding CoAP and a network management protocol will push this further, with= nearly no space left. In fact, if the data model is too large or complic= ated for the network management protocol, then chances are that it too wo= uld not fit either. Similar constraints apply to CoAP as well. Working wi= th CoAP up to Contiki 2.6, while using TelosB (Class 1), was also quite a= struggle. At best we were able to work with a handful of resources, sinc= e the amount of memory left over was not too much. >=20 > I have not checked while writing this email, but at least in the past i= t was the RPL implementation that would take a significant amount of reso= urces. This was largely due to non-storing mode not being implemented, bu= t it would seem that Contiki 2.7 does have the option to enable non-stori= ng mode. This might help reduce resource consumption further. >=20 > When we attempted an implementation of DTLS, we used the AVR Raven (Cla= ss 2) because TelosB (Class 1) did not have enough resources to function = with it. >=20 > Regards, > Anuj >=20 >> On 04/04/2014 09:24 AM, Carsten Bormann wrote: >>> On 02 Apr 2014, at 09:43, Hannes Tschofenig wrote: >>> >>>> IMHO these classes are about end devices rather than constrained rou= ters >>>> and switches. >>> >>> Actually, the device classes are about nodes in general (hosts and ro= uters). The document then goes on to say: >>> >>> (An alternative name, when the properties as a network node are not= >>> in focus, is "constrained device=94.) >>> >>> Protocols such as RPL take great care to enable the use of class-1 de= vices as routers (non-storing mode). >>> Constrained management will need to match that. >>> >>> A more important dichotomy than host vs. router may be monitoring vs.= configuration. >>> >>> Gr=FC=DFe, Carsten >>> >>> _______________________________________________ >>> coman mailing list >>> coman@ietf.org >>> https://www.ietf.org/mailman/listinfo/coman >>> >> >> _______________________________________________ >> coman mailing list >> coman@ietf.org >> https://www.ietf.org/mailman/listinfo/coman >=20 --SkSg5P9UeuRNmCMVkVgwgNSiOWTlxWrfj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTPpwUAAoJEGhJURNOOiAt4e4IAIKu/ADtzBNX1WQAGnKFWmNa aZ6rzmiCFdmLvB8ZETV++/FkTvKJQ6v69XPX7NwqStnldIJk6AiJnbLgES4ya1sj +1QrUW7IyRk1Z9xmdJ4g8Id1CzlCgl+AGa55q26UvWyPjT+mB3mmoFutKhwdpGk+ MErjfx98ph+lJ84+Ik3ODlllXPAs/bWy0QqiamK3MNDvg1xRdn4LcH5MLIJ28SyD Iip7TM3Vp+93EBLzupLKSmPRK7q472ZwI//KJh8o8Pa1IkX9PRJ+KTb6uAGnxpcs ZgW82ml808mJsLSJUzFajG/0Ah1ZhBK4MtdEC/dY6ENKqjdL0EFM6Ch1HwrJikw= =+/pg -----END PGP SIGNATURE----- --SkSg5P9UeuRNmCMVkVgwgNSiOWTlxWrfj-- From nobody Fri Apr 4 06:04:23 2014 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9401A0175 for ; Fri, 4 Apr 2014 06:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtnSwYxJ3AOy for ; Fri, 4 Apr 2014 06:04:17 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id A74DE1A016E for ; Fri, 4 Apr 2014 06:04:16 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DB7C4F85; Fri, 4 Apr 2014 15:04:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id An7A3ZotIwmo; Fri, 4 Apr 2014 15:04:11 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 4 Apr 2014 15:04:11 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4F0B42002C; Fri, 4 Apr 2014 15:04:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id TvsVBdbMyEyh; Fri, 4 Apr 2014 15:04:11 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 59FEB2002F; Fri, 4 Apr 2014 15:04:10 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 68A4C2C25175; Fri, 4 Apr 2014 15:04:09 +0200 (CEST) Date: Fri, 4 Apr 2014 15:04:09 +0200 From: Juergen Schoenwaelder To: Hannes Tschofenig Message-ID: <20140404130409.GB81513@elstar.local> Mail-Followup-To: Hannes Tschofenig , Carsten Bormann , "coman@ietf.org" References: <533BBFB7.2000100@gmx.net> <893C4FAC-437D-4140-9832-A9ABA2D1518A@tzi.org> <533E75A9.5080003@gmx.net> <8D653B3C-E678-4A66-9798-978950977694@tzi.org> <533E9864.4060806@gmx.net> <533E9B6B.1080602@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <533E9B6B.1080602@gmx.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/coman/6U6j5IwlBmsm0N-B7kE_Xz_9PQk Cc: "coman@ietf.org" , Carsten Bormann Subject: Re: [coman] Device Classes? X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 04 Apr 2014 13:04:22 -0000 On Fri, Apr 04, 2014 at 01:45:47PM +0200, Hannes Tschofenig wrote: > > Of course, you could replace CoAP entirely with SNMP (as Juergen had > suggested). > I did not suggest to replace CoAP with SNMP. What I said is: 1) We have done an SNMP only implementation and we know it works and what the resource consumption is. 2) I see potential in a RESTCONF to CoAP mapping for devices that do CoAP. 3) I agree with the desire to keep code down to a minimum and thus to keep the number of protocols needed to a minimum. 4) In our experience, the biggest chunk of code and memory goes to security and in particular crypto algorithms. Being able to exploit crypto hardware is a major plus as is using the same security and crypto mechanisms for all protocols supported. It would be really nice if we would all have a common understanding of what roughly the code and storage requirements of the various protocols involved are. Is LWIG producing something a kind of a survey like this? If so, this would be great I think. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Apr 4 06:49:27 2014 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D3E1A018D for ; Fri, 4 Apr 2014 06:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asBUtu0-6wXh for ; Fri, 4 Apr 2014 06:49:21 -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 BE5DA1A018B for ; Fri, 4 Apr 2014 06:49:19 -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.5/8.14.5) with ESMTP id s34DnAM8007266; Fri, 4 Apr 2014 15:49:10 +0200 (CEST) Received: from eduroam-pool7-1021.wlan.uni-bremen.de (eduroam-pool7-1021.wlan.uni-bremen.de [134.102.115.253]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E8C31D0F; Fri, 4 Apr 2014 15:49:09 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann In-Reply-To: <533E9B6B.1080602@gmx.net> Date: Fri, 4 Apr 2014 15:49:08 +0200 X-Mao-Original-Outgoing-Id: 418312148.618867-5cd400e9dc3218182ff0cb04334063b5 Content-Transfer-Encoding: quoted-printable Message-Id: References: <533BBFB7.2000100@gmx.net> <893C4FAC-437D-4140-9832-A9ABA2D1518A@tzi.org> <533E75A9.5080003@gmx.net> <8D653B3C-E678-4A66-9798-978950977694@tzi.org> <533E9864.4060806@gmx.net> <533E9B6B.1080602@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/coman/vFAsr_xE5Apo3UZtOTLDQW2DZE4 Cc: "coman@ietf.org" Subject: Re: [coman] Device Classes? X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.15 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, 04 Apr 2014 13:49:25 -0000 On 04 Apr 2014, at 13:45, Hannes Tschofenig = wrote: > Hi Carsten. >=20 >=20 > On 04/04/2014 02:08 PM, Carsten Bormann wrote: >> On 04 Apr 2014, at 13:32, Hannes Tschofenig = wrote: >>=20 >>> For me the software update mechanism is extremely important since it = is >>> not just a way to replace the entire firmware but also to provision >>> certain protocol parameters. >>=20 >> Provisioning protocol parameters is one CoAP PUT to the right = resource. Cf. OMA LWM2M. >> (They also do define a firmware update mechanism, but that seems to = presume the device has space for a complete firmware image.) >=20 > That is exactly the question I raised when it comes to network = management. >=20 > I don't understand what network management protocol add beyond what is > already there with CoAP. Assuming we continue to use the client-server model of network = management, to use CoAP for this we need to define 1) What are the URIs that can be used for management? How does the = client learn them (combination of discovery, URI templates, HATEOAS)? 2) What are the representations being exchanged (data format, data = modeling method). 3) What is the security model. There has been a strong argument that we should not start from scratch = with (2) (and probably not entirely with (1) either), even if we are not = using the other parts of existing management protocols. Proposals to address (1) and (2) are, for instance: http://tools.ietf.org/html/draft-vanderstok-core-comi-03 http://www.tzi.de/~cabo/noms2014.pdf (My assumption is that ACE will be good enough to cover (3); we=92ll = have to make sure the lessons learned from management security go into = ACE.) > Of course, you could replace CoAP entirely with SNMP SNMP is a bit more specialized and will not fit all applications that = CoAP is designed to cover. But, yes, SNMP has been used successfully as an application protocol in = certain environments. >> If you want to do this the SEP2.0 way, you need EAP/PANA. >> (SEP2.0 is targeting class-2+, not class-1.) >=20 > With devices that are in direct connection with each other you could > argue that there is no need for DTLS and alike since you will have to > deal with the pairing procedure at the lower layer. Many devices fall > into that category. (Defining single-hop security only is not very useful for the Internet = of Things.) > If that's not the case I believe you cannot assume that no network > access authentication will be needed. Indeed, most wireless networks will need network access control. =20 Maybe there are ways to authorize (!) access to a network that are more = appropriate for the Internet of Things. But this is outside the scope of COMAN. Gr=FC=DFe, Carsten From nobody Fri Apr 4 17:17:00 2014 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80CBC1A034D for ; Fri, 4 Apr 2014 17:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvr4OWkZ1VxB for ; Fri, 4 Apr 2014 17:16:53 -0700 (PDT) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) by ietfa.amsl.com (Postfix) with ESMTP id EF01F1A0336 for ; Fri, 4 Apr 2014 17:16:48 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id i8so4208964qcq.23 for ; Fri, 04 Apr 2014 17:16:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Qy8UJIE7Fsi3ohBuOT7MCHM2hcvNu1oMoMjvdQ0EBVA=; b=ECYeCU2hd7k6zxl+4xBaFinBoeWBkEZG6hCPuYXL0uW5PjL/hc75qrTqwFKFaMlQkz 1WxAmkqkhit6gsZu2oXmRpWoWuCTlHk22ZQDNPwrd2XaQKSMvRqIhW76LAAw/Jxolby5 MA7LreBoFY/TBi0xcBalgjat/1CoD860NzBSy+eogxZMuhd3Zl/OgORgqp8vNmxyMQp+ 9vkMRCR+GzOmU/nz8r3w/zYzlZf1tGzXydAPnat5vegBRRoIPlzrIfTDADNFbMGF2lxI FE+lsbIVznGL5BKmNKYe8lZ9vM0l2Xb2MAd4EPbXUVIILeo6TdjhWiNNN6BkeoM+MhUa YRzw== X-Gm-Message-State: ALoCoQkifoB4iJ3JO4wK4r5pIy1nSwW5H+8mnCvo0gbtO+I65tm4dJ27afuZl3GpygYuyIXYxhBO MIME-Version: 1.0 X-Received: by 10.140.17.81 with SMTP id 75mr17289713qgc.35.1396657003916; Fri, 04 Apr 2014 17:16:43 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Fri, 4 Apr 2014 17:16:43 -0700 (PDT) In-Reply-To: References: <533BBFB7.2000100@gmx.net> <893C4FAC-437D-4140-9832-A9ABA2D1518A@tzi.org> <533E75A9.5080003@gmx.net> <8D653B3C-E678-4A66-9798-978950977694@tzi.org> <533E9864.4060806@gmx.net> <533E9B6B.1080602@gmx.net> Date: Fri, 4 Apr 2014 17:16:43 -0700 Message-ID: From: Andy Bierman To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a11c0f5f6979d8004f6408c1e Archived-At: http://mailarchive.ietf.org/arch/msg/coman/bphdJB7PlQ1GwlNlbi2jfvH8-NE Cc: "coman@ietf.org" , Hannes Tschofenig Subject: Re: [coman] Device Classes? X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.15 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, 05 Apr 2014 00:16:57 -0000 --001a11c0f5f6979d8004f6408c1e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Apr 4, 2014 at 6:49 AM, Carsten Bormann wrote: > > On 04 Apr 2014, at 13:45, Hannes Tschofenig > wrote: > > > Hi Carsten. > > > > > > On 04/04/2014 02:08 PM, Carsten Bormann wrote: > >> On 04 Apr 2014, at 13:32, Hannes Tschofenig > wrote: > >> > >>> For me the software update mechanism is extremely important since it = is > >>> not just a way to replace the entire firmware but also to provision > >>> certain protocol parameters. > >> > >> Provisioning protocol parameters is one CoAP PUT to the right resource= . > Cf. OMA LWM2M. > >> (They also do define a firmware update mechanism, but that seems to > presume the device has space for a complete firmware image.) > > > > That is exactly the question I raised when it comes to network > management. > > > > I don't understand what network management protocol add beyond what is > > already there with CoAP. > > Assuming we continue to use the client-server model of network management= , > to use CoAP for this we need to define > > 1) What are the URIs that can be used for management? How does the clien= t > learn them (combination of discovery, URI templates, HATEOAS)? > > 2) What are the representations being exchanged (data format, data > modeling method). > > RESTCONF addresses (1) and (2). It replaces HATEOAS with YANG in order to be extensible, modular, and predictable. The target use-case is programmatic control. HATEOAS seems more appropriate when human eyeballs and brain power are part of the state machine. IMO YANG would be a better long-term decision than SMIv2. It may seem that features like custom operations are too heavy-weight and over-kill for constrained networks, but it could be just the opposite. Custom operations allow expensive generic operations to be condensed and 'packaged' to be as small as possible. > 3) What is the security model. > > There has been a strong argument that we should not start from scratch > with (2) (and probably not entirely with (1) either), even if we are not > using the other parts of existing management protocols. > > Proposals to address (1) and (2) are, for instance: > http://tools.ietf.org/html/draft-vanderstok-core-comi-03 > http://www.tzi.de/~cabo/noms2014.pdf > > (My assumption is that ACE will be good enough to cover (3); we'll have t= o > make sure the lessons learned from management security go into ACE.) > > > Of course, you could replace CoAP entirely with SNMP > > SNMP is a bit more specialized and will not fit all applications that CoA= P > is designed to cover. > But, yes, SNMP has been used successfully as an application protocol in > certain environments. > > >> If you want to do this the SEP2.0 way, you need EAP/PANA. > >> (SEP2.0 is targeting class-2+, not class-1.) > > > > With devices that are in direct connection with each other you could > > argue that there is no need for DTLS and alike since you will have to > > deal with the pairing procedure at the lower layer. Many devices fall > > into that category. > > (Defining single-hop security only is not very useful for the Internet of > Things.) > > > If that's not the case I believe you cannot assume that no network > > access authentication will be needed. > > Indeed, most wireless networks will need network access control. > Maybe there are ways to authorize (!) access to a network that are more > appropriate for the Internet of Things. > But this is outside the scope of COMAN. > > Gr=FC=DFe, Carsten > > Andy --001a11c0f5f6979d8004f6408c1e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Apr 4, 2014 at 6:49 AM, Carsten Bormann &= lt;cabo@tzi.org> wrote:

On 04 Apr 2014, at 13:45, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

> Hi Carsten.
>
>
> On 04/04/2014 02:08 PM, Carsten Bormann wrote:
>> On 04 Apr 2014, at 13:32, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>>
>>> For me the software update mechanism is extremely important si= nce it is
>>> not just a way to replace the entire firmware but also to prov= ision
>>> certain protocol parameters.
>>
>> Provisioning protocol parameters is one CoAP PUT to the right reso= urce.  Cf. OMA LWM2M.
>> (They also do define a firmware update mechanism, but that seems t= o presume the device has space for a complete firmware image.)
>
> That is exactly the question I raised when it comes to network managem= ent.
>
> I don't understand what network management protocol add beyond wha= t is
> already there with CoAP.

Assuming we continue to use the client-server model of network management, = to use CoAP for this we need to define

1) What are the URIs that can be used for management?  How does the cl= ient learn them (combination of discovery, URI templates, HATEOAS)?

2) What are the representations being exchanged (data format, data modeling= method).


RESTCONF addresses (1) and (2).
<= div>It replaces HATEOAS with YANG in order to be extensible,
modu= lar, and predictable. The target use-case is programmatic
control= .  HATEOAS seems more appropriate when human eyeballs and
brain power are part of the state machine.

IM= O YANG would be a better long-term decision than SMIv2.
It may se= em that features like custom operations are too
heavy-weight and = over-kill for constrained networks, but it
could be just the opposite.  Custom operations allow expensive
generic operations to be condensed and 'packaged' to be as<= /div>
small as possible.


 =
3) What is the security model.

There has been a strong argument that we should not start from scratch with= (2) (and probably not entirely with (1) either), even if we are not using = the other parts of existing management protocols.

Proposals to address (1) and (2) are, for instance:
http://tools.ietf.org/html/draft-vanderstok-core-comi-03 http://w= ww.tzi.de/~cabo/noms2014.pdf

(My assumption is that ACE will be good enough to cover (3); we’ll ha= ve to make sure the lessons learned from management security go into ACE.)<= br>
> Of course, you could replace CoAP entirely with SNMP

SNMP is a bit more specialized and will not fit all applications that CoAP = is designed to cover.
But, yes, SNMP has been used successfully as an application protocol in cer= tain environments.

>> If you want to do this the SEP2.0 way, you need EAP/PANA.
>> (SEP2.0 is targeting class-2+, not class-1.)
>
> With devices that are in direct connection with each other you could > argue that there is no need for DTLS and alike since you will have to<= br> > deal with the pairing procedure at the lower layer. Many devices fall<= br> > into that category.

(Defining single-hop security only is not very useful for the Internet of T= hings.)

> If that's not the case I believe you cannot assume that no network=
> access authentication will be needed.

Indeed, most wireless networks will need network access control.
Maybe there are ways to authorize (!) access to a network that are more app= ropriate for the Internet of Things.
But this is outside the scope of COMAN.

Gr=FC=DFe, Carsten



Andy

--001a11c0f5f6979d8004f6408c1e-- From nobody Fri Apr 4 21:01:47 2014 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6AF1A024C for ; Fri, 4 Apr 2014 21:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWmF7ZJzUsGx for ; Fri, 4 Apr 2014 21:01:41 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 663851A0143 for ; Fri, 4 Apr 2014 21:01:41 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id v10so4167992pde.29 for ; Fri, 04 Apr 2014 21:01:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=ZAhbv484NBeTzZPhfyexRBCRKLFTQqSz/zV3vlp0JCc=; b=DP5mf5YxTdOTXcMj6th8FKGFq2RvmzCX4s1nMoGlfscd7vcRFg3h3GUS0n5UKIl9oy LBVO5QJVh4b9CuMr8pk6my2OzrkkEw1FQdGpHMUhV4wSkQNlMrfepuTUG5yooAjaw/EH zbLkvs0O7udLk4PScwYn1Oo+4I9R1kkm6fMwovLeAa6NZDZxSDVXz80JsM/cv8/BOv+w rpz3zQMd5cY/O9/QPzylyxDBQQKbuvKlFOGGL3kFrczEbl7DYIS9CSUoFGuH32H1a0/w BwVA4/devn0IzYWce6+8YK+EFgJ+oUxkzbmjDtfKW5fikR6Uf6Uml6nrubt6HEwJYJOs Vasw== X-Received: by 10.68.136.41 with SMTP id px9mr18777290pbb.14.1396670496540; Fri, 04 Apr 2014 21:01:36 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.154.130 with HTTP; Fri, 4 Apr 2014 21:01:16 -0700 (PDT) In-Reply-To: References: <533BBFB7.2000100@gmx.net> <893C4FAC-437D-4140-9832-A9ABA2D1518A@tzi.org> <533E75A9.5080003@gmx.net> <8D653B3C-E678-4A66-9798-978950977694@tzi.org> <533E9864.4060806@gmx.net> <533E9B6B.1080602@gmx.net> From: Thomas Watteyne Date: Fri, 4 Apr 2014 21:01:16 -0700 X-Google-Sender-Auth: I0vmgP9oCnIhJffvBGWsWoeMY1Y Message-ID: To: Andy Bierman Content-Type: multipart/alternative; boundary=047d7b15aac5d1ecdf04f643b0cd Archived-At: http://mailarchive.ietf.org/arch/msg/coman/aVpdU_FaABVyILPn1VYhB7djaWU Cc: "coman@ietf.org" , Carsten Bormann , Hannes Tschofenig Subject: Re: [coman] Device Classes? X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.15 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, 05 Apr 2014 04:01:45 -0000 --047d7b15aac5d1ecdf04f643b0cd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Andy, all, If CoAP is already in nodes for the applications running on, you have a monitoring/management solution almost for free. Want to monitoring the state of some attribute of your protocol? Use CoAP observe. Want to change a parameter of your protocol? CoAP PUT. On top of that, the work from CORE/DICE/DTLS/ACE, will ensure security, including authentication and authorization of management entities. For nodes where CoAP is present for the application, proposing an additional protocol will be a very hard sell. Of course, as pointed out by Carsten, we need to agree on the resources. What is the URI, what methods are supported, what's the payload format, etc. YANG is a data modeling language which enables exactly that. RESTCONF has a RESTful approach to monitoring/management which is aligned with CoAP. What we would need is a constrained version of RESTCONF. This could be (and should be) very simple. At 6TiSCH, we have started this work, with YANG based data model [1] and a CoAP-based protocol built around that [2], any URI starting with "/6t" is to monitoring and manage the 6top sublayer. I believe there would be a huge benefit to having a more general solution, to which we all agree, i.e. a CoAPified version of RESTCONF. COMAN looks like the right place to do this. Thomas [1] http://tools.ietf.org/html/draft-ietf-6tisch-6top-interface-00 [2] http://tools.ietf.org/html/draft-sudhaakar-6tisch-coap-01 On Fri, Apr 4, 2014 at 5:16 PM, Andy Bierman wrote: > > > > On Fri, Apr 4, 2014 at 6:49 AM, Carsten Bormann wrote: > >> >> On 04 Apr 2014, at 13:45, Hannes Tschofenig >> wrote: >> >> > Hi Carsten. >> > >> > >> > On 04/04/2014 02:08 PM, Carsten Bormann wrote: >> >> On 04 Apr 2014, at 13:32, Hannes Tschofenig >> wrote: >> >> >> >>> For me the software update mechanism is extremely important since it >> is >> >>> not just a way to replace the entire firmware but also to provision >> >>> certain protocol parameters. >> >> >> >> Provisioning protocol parameters is one CoAP PUT to the right >> resource. Cf. OMA LWM2M. >> >> (They also do define a firmware update mechanism, but that seems to >> presume the device has space for a complete firmware image.) >> > >> > That is exactly the question I raised when it comes to network >> management. >> > >> > I don't understand what network management protocol add beyond what is >> > already there with CoAP. >> >> Assuming we continue to use the client-server model of network >> management, to use CoAP for this we need to define >> >> 1) What are the URIs that can be used for management? How does the >> client learn them (combination of discovery, URI templates, HATEOAS)? >> >> 2) What are the representations being exchanged (data format, data >> modeling method). >> >> > RESTCONF addresses (1) and (2). > It replaces HATEOAS with YANG in order to be extensible, > modular, and predictable. The target use-case is programmatic > control. HATEOAS seems more appropriate when human eyeballs and > brain power are part of the state machine. > > IMO YANG would be a better long-term decision than SMIv2. > It may seem that features like custom operations are too > heavy-weight and over-kill for constrained networks, but it > could be just the opposite. Custom operations allow expensive > generic operations to be condensed and 'packaged' to be as > small as possible. > > > > >> 3) What is the security model. >> >> There has been a strong argument that we should not start from scratch >> with (2) (and probably not entirely with (1) either), even if we are not >> using the other parts of existing management protocols. >> >> Proposals to address (1) and (2) are, for instance: >> http://tools.ietf.org/html/draft-vanderstok-core-comi-03 >> http://www.tzi.de/~cabo/noms2014.pdf >> >> (My assumption is that ACE will be good enough to cover (3); we'll have >> to make sure the lessons learned from management security go into ACE.) >> >> > Of course, you could replace CoAP entirely with SNMP >> >> SNMP is a bit more specialized and will not fit all applications that >> CoAP is designed to cover. >> But, yes, SNMP has been used successfully as an application protocol in >> certain environments. >> >> >> If you want to do this the SEP2.0 way, you need EAP/PANA. >> >> (SEP2.0 is targeting class-2+, not class-1.) >> > >> > With devices that are in direct connection with each other you could >> > argue that there is no need for DTLS and alike since you will have to >> > deal with the pairing procedure at the lower layer. Many devices fall >> > into that category. >> >> (Defining single-hop security only is not very useful for the Internet o= f >> Things.) >> >> > If that's not the case I believe you cannot assume that no network >> > access authentication will be needed. >> >> Indeed, most wireless networks will need network access control. >> Maybe there are ways to authorize (!) access to a network that are more >> appropriate for the Internet of Things. >> But this is outside the scope of COMAN. >> >> Gr=FC=DFe, Carsten >> >> > > Andy > > > _______________________________________________ > coman mailing list > coman@ietf.org > https://www.ietf.org/mailman/listinfo/coman > > --047d7b15aac5d1ecdf04f643b0cd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Andy, all,

If CoAP is already in nodes = for the applications running on, you have a monitoring/management solution = almost for free. Want to monitoring the state of some attribute of your pro= tocol? Use CoAP observe. Want to change a parameter of your protocol? CoAP = PUT. On top of that, the work from CORE/DICE/DTLS/ACE, will ensure security= , including authentication and authorization of management entities.

For nodes where CoAP is present for the application, pr= oposing an additional protocol will be a very hard sell.

Of course, as pointed out by Carsten, we need to agree on the resour= ces. What is the URI, what methods are supported, what's the payload fo= rmat, etc. YANG is a data modeling language which enables exactly that. RES= TCONF has a RESTful approach to monitoring/management which is aligned with= CoAP. What we would need is a constrained version of RESTCONF. This could = be (and should be) very simple.

At 6TiSCH, we have started this work, with YANG based d= ata model [1] and a CoAP-based protocol built around that [2], any URI star= ting with "/6t" is to monitoring and manage the 6top sublayer. I = believe there would be a huge benefit to having a more general solution, to= which we all agree, i.e. a CoAPified version of RESTCONF. COMAN looks like= the right place to do this.

Thomas



On Fri,= Apr 4, 2014 at 5:16 PM, Andy Bierman <andy@yumaworks.com> = wrote:



On Fri, Apr 4, 2014 = at 6:49 AM, Carsten Bormann <cabo@tzi.org> wrote:

On 04 Apr 2014, at 13:45, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote= :

> Hi Carsten.
>
>
> On 04/04/2014 02:08 PM, Carsten Bormann wrote:
>> On 04 Apr 2014, at 13:32, Hannes Tschofenig <hannes.tschofenig@gmx.net&= gt; wrote:
>>
>>> For me the software update mechanism is extremely important si= nce it is
>>> not just a way to replace the entire firmware but also to prov= ision
>>> certain protocol parameters.
>>
>> Provisioning protocol parameters is one CoAP PUT to the right reso= urce.  Cf. OMA LWM2M.
>> (They also do define a firmware update mechanism, but that seems t= o presume the device has space for a complete firmware image.)
>
> That is exactly the question I raised when it comes to network managem= ent.
>
> I don't understand what network management protocol add beyond wha= t is
> already there with CoAP.

Assuming we continue to use the client-server model of network management, = to use CoAP for this we need to define

1) What are the URIs that can be used for management?  How does the cl= ient learn them (combination of discovery, URI templates, HATEOAS)?

2) What are the representations being exchanged (data format, data modeling= method).


RESTCONF addresses (1) and (2).<= /div>
It replaces HATEOAS with YANG in order to be extensible,
modular, and predictable. The target use-case is programmatic
control.  HATEOAS seems more appropriate when human eyeballs and
brain power are part of the state machine.

IM= O YANG would be a better long-term decision than SMIv2.
It may se= em that features like custom operations are too
heavy-weight and = over-kill for constrained networks, but it
could be just the opposite.  Custom operations allow expensive
generic operations to be condensed and 'packaged' to be as<= /div>
small as possible.


<= /div>
 
3) What is the security model.

There has been a strong argument that we should not start from scratch with= (2) (and probably not entirely with (1) either), even if we are not using = the other parts of existing management protocols.

Proposals to address (1) and (2) are, for instance:
http://tools.ietf.org/html/draft-vanderstok-core-comi-03 http://w= ww.tzi.de/~cabo/noms2014.pdf

(My assumption is that ACE will be good enough to cover (3); we’ll ha= ve to make sure the lessons learned from management security go into ACE.)<= br>
> Of course, you could replace CoAP entirely with SNMP

SNMP is a bit more specialized and will not fit all applications that CoAP = is designed to cover.
But, yes, SNMP has been used successfully as an application protocol in cer= tain environments.

>> If you want to do this the SEP2.0 way, you need EAP/PANA.
>> (SEP2.0 is targeting class-2+, not class-1.)
>
> With devices that are in direct connection with each other you could > argue that there is no need for DTLS and alike since you will have to<= br> > deal with the pairing procedure at the lower layer. Many devices fall<= br> > into that category.

(Defining single-hop security only is not very useful for the Internet of T= hings.)

> If that's not the case I believe you cannot assume that no network=
> access authentication will be needed.

Indeed, most wireless networks will need network access control.
Maybe there are ways to authorize (!) access to a network that are more app= ropriate for the Internet of Things.
But this is outside the scope of COMAN.

Gr=FC=DFe, Carsten



Andy

=

_______________________________________________
coman mailing list
coman@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/coman


--047d7b15aac5d1ecdf04f643b0cd-- From nobody Fri Apr 4 23:07:25 2014 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4641D1A0304 for ; Fri, 4 Apr 2014 23:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZybkYFfvw7m for ; Fri, 4 Apr 2014 23:07:17 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 39DF31A030C for ; Fri, 4 Apr 2014 23:07:17 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 08E84106C; Sat, 5 Apr 2014 08:07:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id dmE-WcvdUXci; Sat, 5 Apr 2014 08:07:11 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sat, 5 Apr 2014 08:07:11 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6E73820033; Sat, 5 Apr 2014 08:07:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id gOdKF38wCYme; Sat, 5 Apr 2014 08:07:11 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1C1392002C; Sat, 5 Apr 2014 08:07:09 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 356E02C27457; Sat, 5 Apr 2014 08:07:07 +0200 (CEST) Date: Sat, 5 Apr 2014 08:07:07 +0200 From: Juergen Schoenwaelder To: Thomas Watteyne Message-ID: <20140405060707.GA84694@elstar.local> Mail-Followup-To: Thomas Watteyne , Andy Bierman , "coman@ietf.org" , Carsten Bormann , Hannes Tschofenig References: <533BBFB7.2000100@gmx.net> <893C4FAC-437D-4140-9832-A9ABA2D1518A@tzi.org> <533E75A9.5080003@gmx.net> <8D653B3C-E678-4A66-9798-978950977694@tzi.org> <533E9864.4060806@gmx.net> <533E9B6B.1080602@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/coman/NP5_iuokJLOUgPD9IF1eZlkYrY0 Cc: "coman@ietf.org" , Carsten Bormann , Hannes Tschofenig , Andy Bierman Subject: Re: [coman] Device Classes? X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 05 Apr 2014 06:07:21 -0000 On Fri, Apr 04, 2014 at 09:01:16PM -0700, Thomas Watteyne wrote: > > At 6TiSCH, we have started this work, with YANG based data model [1] and a > CoAP-based protocol built around that [2], any URI starting with "/6t" is > to monitoring and manage the 6top sublayer. I believe there would be a huge > benefit to having a more general solution, to which we all agree, i.e. a > CoAPified version of RESTCONF. COMAN looks like the right place to do this. > Well, what you have in [1] is not really YANG and surely not RESTCONF either. I think [1] essentially illustrates that having no agreement (or standard) how to do NM in this space is a problem. Don't get me wrong, I appreciate the direction of this work but claiming it is a YANG based data model I think is not quite right. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Sat Apr 5 00:00:15 2014 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D959B1A00E4 for ; Sat, 5 Apr 2014 00:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGqm09n0yvFS for ; Sat, 5 Apr 2014 00:00:09 -0700 (PDT) Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id D2DDE1A0013 for ; Sat, 5 Apr 2014 00:00:09 -0700 (PDT) Received: by mail-pb0-f42.google.com with SMTP id rr13so4465330pbb.1 for ; Sat, 05 Apr 2014 00:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=YB6G0DWJtZC0raSx3rgfuNW6/zcU4+HuJYup8/zpBm4=; b=bTHcqueLmt9ZTo0w3J4BAYMQLwCyplBtBnNhO5jVWo+wGW1sTMSAuH5ey+SQCPRIEe WO6Sm8sauiYKhy4qwI0mVmKp6VHvQwxlim3As9hcTH3/pZun6TuJeDHZulXGr2ia0iP8 J5ICHbVfBtzz+mJ1DP5Ugb4qF262Jat7W1UPra2DkqvXYUWqp4dznV0MRdXP8JO1VBwl jOu0K6QJgkCMv+X3GVzz2TJd6kdR1tUG9I5DRqm7Ad4DufoemLiELu3SPpNwu46NIj/G yOp4lobXSQzHiYLlxDo27G6ETxXuGrzv7iT8vZBRiSQ3nx8FQqm8SZGY+0ZEzThcIQhE +kbg== X-Received: by 10.66.122.101 with SMTP id lr5mr392967pab.130.1396681204979; Sat, 05 Apr 2014 00:00:04 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.154.130 with HTTP; Fri, 4 Apr 2014 23:59:44 -0700 (PDT) In-Reply-To: <20140405060707.GA84694@elstar.local> References: <533BBFB7.2000100@gmx.net> <893C4FAC-437D-4140-9832-A9ABA2D1518A@tzi.org> <533E75A9.5080003@gmx.net> <8D653B3C-E678-4A66-9798-978950977694@tzi.org> <533E9864.4060806@gmx.net> <533E9B6B.1080602@gmx.net> <20140405060707.GA84694@elstar.local> From: Thomas Watteyne Date: Fri, 4 Apr 2014 23:59:44 -0700 X-Google-Sender-Auth: JklbyEw3TOnoNofVzSKVa-17CDM Message-ID: To: Juergen Schoenwaelder , Andy Bierman , "coman@ietf.org" , Carsten Bormann , Hannes Tschofenig , Qin Wang , Pascal Thubert , Xavi Vilajosana Content-Type: multipart/alternative; boundary=047d7b2e0ddf165d9d04f6462f3a Archived-At: http://mailarchive.ietf.org/arch/msg/coman/AQlDFmGXABGdeS9UAlV4oYqT8FM Subject: Re: [coman] Device Classes? X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.15 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, 05 Apr 2014 07:00:14 -0000 --047d7b2e0ddf165d9d04f6462f3a Content-Type: text/plain; charset=ISO-8859-1 Juergen, The goal of this -00 is to kick things off and spark interest beyond 6TiSCH, especially in COMAN. Glad to see this worked and that you agree with the general direction. One of 6TiSCH's milestones for August 2014 is to ask for help from "YANG people". Could I ask you to provide feedback to the authors or the 6TiSCH ML? The 6top authors are holding a ad-hoc webex discussion on Tuesday [1], maybe a good first venue for feedback. Please note that [2] was written specifically because there is no constrained version of RESTCONF. It doesn't claim to be that, and, if there were such a thing, we'd be more than happy to consider it. Thomas [1] http://www.ietf.org/mail-archive/web/6tisch/current/msg02114.html On Fri, Apr 4, 2014 at 11:07 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Fri, Apr 04, 2014 at 09:01:16PM -0700, Thomas Watteyne wrote: > > > > At 6TiSCH, we have started this work, with YANG based data model [1] and > a > > CoAP-based protocol built around that [2], any URI starting with "/6t" is > > to monitoring and manage the 6top sublayer. I believe there would be a > huge > > benefit to having a more general solution, to which we all agree, i.e. a > > CoAPified version of RESTCONF. COMAN looks like the right place to do > this. > > > > Well, what you have in [1] is not really YANG and surely not RESTCONF > either. I think [1] essentially illustrates that having no agreement > (or standard) how to do NM in this space is a problem. Don't get me > wrong, I appreciate the direction of this work but claiming it is a > YANG based data model I think is not quite right. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --047d7b2e0ddf165d9d04f6462f3a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Juergen,
The goal of this -00 is to kick th= ings off and spark interest beyond 6TiSCH, especially in COMAN. Glad to see= this worked and that you agree with the general direction.
One of 6TiSCH's milestones for August 2014 is to ask for help from &quo= t;YANG people". Could I ask you to provide feedback to the authors or = the 6TiSCH ML? The 6top authors are holding a ad-hoc webex discussion on Tu= esday [1], maybe a good first venue for feedback.
Please note that [2] was written specifically because there is n= o=A0constrained=A0version of RESTCONF. It doesn't claim to be that, and= , if there were such a thing, we'd be more than happy to consider it.
Thomas



On Fri, Apr 4= , 2014 at 11:07 PM, Juergen Schoenwaelder <j.schoenwael= der@jacobs-university.de> wrote:
On Fri, Apr 04, 2014 at 09:0= 1:16PM -0700, Thomas Watteyne wrote:
>
> At 6TiSCH, we have started this work, with YANG based data model [1] a= nd a
> CoAP-based protocol built around that [2], any URI starting with "= ;/6t" is
> to monitoring and manage the 6top sublayer. I believe there would be a= huge
> benefit to having a more general solution, to which we all agree, i.e.= a
> CoAPified version of RESTCONF. COMAN looks like the right place to do = this.
>

Well, what you have in [1] is not really YANG and surely not RESTCONF=
either. I think [1] essentially illustrates that having no agreement
(or standard) how to do NM in this space is a problem. Don't get me
wrong, I appreciate the direction of this work but claiming it is a
YANG based data model I think is not quite right.

/js

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

--047d7b2e0ddf165d9d04f6462f3a-- From nobody Sat Apr 5 00:16:49 2014 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080F81A034B for ; Sat, 5 Apr 2014 00:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txgWsiv7dm3W for ; Sat, 5 Apr 2014 00:16:43 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id E970E1A0331 for ; Sat, 5 Apr 2014 00:16:42 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D0E53E73; Sat, 5 Apr 2014 09:16:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id sFQakiPpvpTl; Sat, 5 Apr 2014 09:16:37 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sat, 5 Apr 2014 09:16:37 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0066E2002F; Sat, 5 Apr 2014 09:16:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id IYkpiBM4HhGg; Sat, 5 Apr 2014 09:16:36 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A84AF2002C; Sat, 5 Apr 2014 09:16:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 97D3E2C27796; Sat, 5 Apr 2014 09:16:33 +0200 (CEST) Date: Sat, 5 Apr 2014 09:16:33 +0200 From: Juergen Schoenwaelder To: Thomas Watteyne Message-ID: <20140405071633.GA84960@elstar.local> Mail-Followup-To: Thomas Watteyne , Andy Bierman , "coman@ietf.org" , Carsten Bormann , Hannes Tschofenig , Qin Wang , Pascal Thubert , Xavi Vilajosana References: <533E75A9.5080003@gmx.net> <8D653B3C-E678-4A66-9798-978950977694@tzi.org> <533E9864.4060806@gmx.net> <533E9B6B.1080602@gmx.net> <20140405060707.GA84694@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/coman/BKCGX_OzWz97yt75QrVWfObWNJY Cc: Pascal Thubert , Andy Bierman , Xavi Vilajosana , "coman@ietf.org" , Carsten Bormann , Hannes Tschofenig , Qin Wang Subject: Re: [coman] Device Classes? X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 05 Apr 2014 07:16:47 -0000 Thomas, I know pretty much nothing about 6TiSCH. But you should definately write a complete YANG data model so that tools can be used. You need to distinguish configuration from state. The term "MIB" does not exist in the YANG world - or what is the 6top MIB? Since I do not have IEEE802154e, I can't really make much sense of things (descriptions like "Defined in IEEE802154e." don't help much). I am not understanding what 6top commands are (defined by IEEE?) and how they relate to the YANG fragments. Are you re-modeling command frames coming from IEEE? If so, what is the value of this? If there is value in this, why do you not use YANG defined rpcs? In short, I am confused what problem this document and the YANG fragment are trying to solve. To me, it looks like you are remodeling 6top and it is unclear what the value of this is. A section more clearly describing what the problem is to be solved and how the data model is intended to be used would be useful. I won't be able to join the Webex (and I have enough other things I am late with already...). /js On Fri, Apr 04, 2014 at 11:59:44PM -0700, Thomas Watteyne wrote: > Juergen, > The goal of this -00 is to kick things off and spark interest beyond > 6TiSCH, especially in COMAN. Glad to see this worked and that you agree > with the general direction. > One of 6TiSCH's milestones for August 2014 is to ask for help from "YANG > people". Could I ask you to provide feedback to the authors or the 6TiSCH > ML? The 6top authors are holding a ad-hoc webex discussion on Tuesday [1], > maybe a good first venue for feedback. > Please note that [2] was written specifically because there is > no constrained version of RESTCONF. It doesn't claim to be that, and, if > there were such a thing, we'd be more than happy to consider it. > Thomas > > [1] http://www.ietf.org/mail-archive/web/6tisch/current/msg02114.html > > > On Fri, Apr 4, 2014 at 11:07 PM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Fri, Apr 04, 2014 at 09:01:16PM -0700, Thomas Watteyne wrote: > > > > > > At 6TiSCH, we have started this work, with YANG based data model [1] and > > a > > > CoAP-based protocol built around that [2], any URI starting with "/6t" is > > > to monitoring and manage the 6top sublayer. I believe there would be a > > huge > > > benefit to having a more general solution, to which we all agree, i.e. a > > > CoAPified version of RESTCONF. COMAN looks like the right place to do > > this. > > > > > > > Well, what you have in [1] is not really YANG and surely not RESTCONF > > either. I think [1] essentially illustrates that having no agreement > > (or standard) how to do NM in this space is a problem. Don't get me > > wrong, I appreciate the direction of this work but claiming it is a > > YANG based data model I think is not quite right. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Sat Apr 5 00:37:38 2014 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE74B1A00FB for ; Sat, 5 Apr 2014 00:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WM37wONV18rc for ; Sat, 5 Apr 2014 00:37:32 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 74F661A035D for ; Sat, 5 Apr 2014 00:37:32 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id z10so4302807pdj.18 for ; Sat, 05 Apr 2014 00:37:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=vp3n4pP73kwDH+GA8B4B6XIh0p1Pi6u0A/flAsVWpXE=; b=Tk4XB7pZ68mXmBgQio0q6dinmYCeepK55VjAB2zoY3P1T63OtWlepblVTdCH0tVmcx yYQ0sNjmzO/wrbOaKQjz9p6n4HRTKwj+XrBk7XuqvSpY6y+/aCzHniCiyeKzDgW4hq+O Iy4HKZIgbqly5ITKzTjQiwmqoysMzyZcowjuN/NqP1AEASdlgqAZyFcj0xYXZRuJY7Pv BUtgIYcrH/ZNetAC4V9p5rb+OInQ1ibjMxbbRX8QJO0OMpQPBfZk8LdFG5nlPS43ZtR/ K4Xd0utY9/hyW/7W80FUdgJlAqUfuPOKk6QypLkrrZ175mFrVJPcSnNDIEFRzP7wDRch nezw== X-Received: by 10.66.123.5 with SMTP id lw5mr19352118pab.83.1396683447774; Sat, 05 Apr 2014 00:37:27 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.154.130 with HTTP; Sat, 5 Apr 2014 00:37:07 -0700 (PDT) In-Reply-To: <20140405071633.GA84960@elstar.local> References: <533E75A9.5080003@gmx.net> <8D653B3C-E678-4A66-9798-978950977694@tzi.org> <533E9864.4060806@gmx.net> <533E9B6B.1080602@gmx.net> <20140405060707.GA84694@elstar.local> <20140405071633.GA84960@elstar.local> From: Thomas Watteyne Date: Sat, 5 Apr 2014 00:37:07 -0700 X-Google-Sender-Auth: qzJi1ElCGfgEAUUCZZDZdKFSVo0 Message-ID: To: Juergen Schoenwaelder , Thomas Watteyne , Andy Bierman , "coman@ietf.org" , Carsten Bormann , Hannes Tschofenig , Qin Wang , Pascal Thubert , Xavi Vilajosana Content-Type: multipart/alternative; boundary=047d7bf0e7c8c4b46a04f646b49a Archived-At: http://mailarchive.ietf.org/arch/msg/coman/V5SMXGtSqQBcLWFiH2rkAobwA7A Subject: Re: [coman] Device Classes? X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.15 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, 05 Apr 2014 07:37:37 -0000 --047d7bf0e7c8c4b46a04f646b49a Content-Type: text/plain; charset=ISO-8859-1 Juergen, Thanks for the feedback. Thomas On Sat, Apr 5, 2014 at 12:16 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > Thomas, > > I know pretty much nothing about 6TiSCH. But you should definately > write a complete YANG data model so that tools can be used. You need > to distinguish configuration from state. The term "MIB" does not exist > in the YANG world - or what is the 6top MIB? Since I do not have > IEEE802154e, I can't really make much sense of things (descriptions > like "Defined in IEEE802154e." don't help much). > > I am not understanding what 6top commands are (defined by IEEE?) and > how they relate to the YANG fragments. Are you re-modeling command > frames coming from IEEE? If so, what is the value of this? If there is > value in this, why do you not use YANG defined rpcs? In short, I am > confused what problem this document and the YANG fragment are trying > to solve. To me, it looks like you are remodeling 6top and it is > unclear what the value of this is. A section more clearly describing > what the problem is to be solved and how the data model is intended > to be used would be useful. > > I won't be able to join the Webex (and I have enough other things I am > late with already...). > > /js > > On Fri, Apr 04, 2014 at 11:59:44PM -0700, Thomas Watteyne wrote: > > Juergen, > > The goal of this -00 is to kick things off and spark interest beyond > > 6TiSCH, especially in COMAN. Glad to see this worked and that you agree > > with the general direction. > > One of 6TiSCH's milestones for August 2014 is to ask for help from "YANG > > people". Could I ask you to provide feedback to the authors or the 6TiSCH > > ML? The 6top authors are holding a ad-hoc webex discussion on Tuesday > [1], > > maybe a good first venue for feedback. > > Please note that [2] was written specifically because there is > > no constrained version of RESTCONF. It doesn't claim to be that, and, if > > there were such a thing, we'd be more than happy to consider it. > > Thomas > > > > [1] http://www.ietf.org/mail-archive/web/6tisch/current/msg02114.html > > > > > > On Fri, Apr 4, 2014 at 11:07 PM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > On Fri, Apr 04, 2014 at 09:01:16PM -0700, Thomas Watteyne wrote: > > > > > > > > At 6TiSCH, we have started this work, with YANG based data model [1] > and > > > a > > > > CoAP-based protocol built around that [2], any URI starting with > "/6t" is > > > > to monitoring and manage the 6top sublayer. I believe there would be > a > > > huge > > > > benefit to having a more general solution, to which we all agree, > i.e. a > > > > CoAPified version of RESTCONF. COMAN looks like the right place to do > > > this. > > > > > > > > > > Well, what you have in [1] is not really YANG and surely not RESTCONF > > > either. I think [1] essentially illustrates that having no agreement > > > (or standard) how to do NM in this space is a problem. Don't get me > > > wrong, I appreciate the direction of this work but claiming it is a > > > YANG based data model I think is not quite right. > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > > Fax: +49 421 200 3103 > > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --047d7bf0e7c8c4b46a04f646b49a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Juergen,
Thanks for the feedback.
Thomas


On Sat, Apr 5, 2014 at 12:16 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
Thomas,

I know pretty much nothing about 6TiSCH. But you should definately
write a complete YANG data model so that tools can be used. You need
to distinguish configuration from state. The term "MIB" does not = exist
in the YANG world - or what is the 6top MIB? Since I do not have
IEEE802154e, I can't really make much sense of things (descriptions
like "Defined in IEEE802154e." don't help much).

I am not understanding what 6top commands are (defined by IEEE?) and
how they relate to the YANG fragments. Are you re-modeling command
frames coming from IEEE? If so, what is the value of this? If there is
value in this, why do you not use YANG defined rpcs? In short, I am
confused what problem this document and the YANG fragment are trying
to solve. To me, it looks like you are remodeling 6top and it is
unclear what the value of this is. A section more clearly describing
what the problem is to be solved and how the data model is intended
to be used would be useful.

I won't be able to join the Webex (and I have enough other things I am<= br> late with already...).

/js

On Fri, Apr 04, 2014 at 11:59:44PM -0700, Thomas Watteyne wrote:
> Juergen,
> The goal of this -00 is to kick things off and spark interest beyond > 6TiSCH, especially in COMAN. Glad to see this worked and that you agre= e
> with the general direction.
> One of 6TiSCH's milestones for August 2014 is to ask for help from= "YANG
> people". Could I ask you to provide feedback to the authors or th= e 6TiSCH
> ML? The 6top authors are holding a ad-hoc webex discussion on Tuesday = [1],
> maybe a good first venue for feedback.
> Please note that [2] was written specifically because there is
> no constrained version of RESTCONF. It doesn't claim to be that, a= nd, if
> there were such a thing, we'd be more than happy to consider it. > Thomas
>
> [1] http://www.ietf.org/mail-archive/web/6tisch/c= urrent/msg02114.html
>
>
> On Fri, Apr 4, 2014 at 11:07 PM, Juergen Schoenwaelder <
> j.schoenwaelde= r@jacobs-university.de> wrote:
>
> > On Fri, Apr 04, 2014 at 09:01:16PM -0700, Thomas Watteyne wrote:<= br> > > >
> > > At 6TiSCH, we have started this work, with YANG based data m= odel [1] and
> > a
> > > CoAP-based protocol built around that [2], any URI starting = with "/6t" is
> > > to monitoring and manage the 6top sublayer. I believe there = would be a
> > huge
> > > benefit to having a more general solution, to which we all a= gree, i.e. a
> > > CoAPified version of RESTCONF. COMAN looks like the right pl= ace to do
> > this.
> > >
> >
> > Well, what you have in [1] is not really YANG and surely not REST= CONF
> > either. I think [1] essentially illustrates that having no agreem= ent
> > (or standard) how to do NM in this space is a problem. Don't = get me
> > wrong, I appreciate the direction of this work but claiming it is= a
> > YANG based data model I think is not quite right.
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Breme= n gGmbH
> > Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Brem= en, Germany
> > Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de= />
> >

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

--047d7bf0e7c8c4b46a04f646b49a-- From nobody Sat Apr 5 10:09:01 2014 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF0711A01F8 for ; Sat, 5 Apr 2014 10:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veWcdWQhGapU for ; Sat, 5 Apr 2014 10:08:51 -0700 (PDT) Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) by ietfa.amsl.com (Postfix) with ESMTP id E986E1A016A for ; Sat, 5 Apr 2014 10:08:50 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id w8so4277210qac.40 for ; Sat, 05 Apr 2014 10:08:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HEcFCsA8IvLWY5JTCRPNrJflKbIFvZHgnP/UHQ5X2Gg=; b=ONepeIsjdCOOdtLB6Yna0yLez+MzHdtlxzEmrmxUu+iMan/OaQOit0zEJJldSTiIBh 8ly8IWxhHL5eTUzpDQbKrabcEGWmhYfrXrSKcvexweLuzUIYwa2vLHCcv3yX79WbtL+H pvstcHc5EGykwKFDL35KRB999g6CZpFQ+7KaIRFxmXsYrqC+aNRo+aSyUwfv8enGchnf ZzmtAaMNiqQMFh310GDgt2aC1E5dWMfUaLWg/ylhkBxes/w4yLwIwT+tfgZx4A05rfUm ll9dHvI/VKF3+HQI9pVkVkDkNieU8haofk+yRPPxiZhPRGiNBrz8vBWMmMWTL24GsaTm BjgA== X-Gm-Message-State: ALoCoQkQBkSA2XdgIQzyHgVa/sbhVlhh1tbhkQ8cFqEyfopBLjAYn31ZRVJKUk9WDWAXhJXufK3w MIME-Version: 1.0 X-Received: by 10.140.104.103 with SMTP id z94mr3280828qge.91.1396717725773; Sat, 05 Apr 2014 10:08:45 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Sat, 5 Apr 2014 10:08:45 -0700 (PDT) In-Reply-To: References: <533BBFB7.2000100@gmx.net> <893C4FAC-437D-4140-9832-A9ABA2D1518A@tzi.org> <533E75A9.5080003@gmx.net> <8D653B3C-E678-4A66-9798-978950977694@tzi.org> <533E9864.4060806@gmx.net> <533E9B6B.1080602@gmx.net> Date: Sat, 5 Apr 2014 10:08:45 -0700 Message-ID: From: Andy Bierman To: Thomas Watteyne Content-Type: multipart/alternative; boundary=001a1134f2bee577d004f64eaf4b Archived-At: http://mailarchive.ietf.org/arch/msg/coman/8ebZZBCe9bwbSF1Abr9BNnJpjTI Cc: "coman@ietf.org" , Carsten Bormann , Hannes Tschofenig Subject: Re: [coman] Device Classes? X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.15 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, 05 Apr 2014 17:08:57 -0000 --001a1134f2bee577d004f64eaf4b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Apr 4, 2014 at 9:01 PM, Thomas Watteyne wrote: > Andy, all, > > If CoAP is already in nodes for the applications running on, you have a > monitoring/management solution almost for free. Want to monitoring the > state of some attribute of your protocol? Use CoAP observe. Want to chang= e > a parameter of your protocol? CoAP PUT. On top of that, the work from > CORE/DICE/DTLS/ACE, will ensure security, including authentication and > authorization of management entities. > > For nodes where CoAP is present for the application, proposing an > additional protocol will be a very hard sell. > > It isn't another protocol. It is a mapping of the RESTCONF data model framework onto CoAP. A RESTCONF mapping would really just describe what the server was expected to do wrt/ the content layer. Andy > Of course, as pointed out by Carsten, we need to agree on the resources. > What is the URI, what methods are supported, what's the payload format, > etc. YANG is a data modeling language which enables exactly that. RESTCON= F > has a RESTful approach to monitoring/management which is aligned with CoA= P. > What we would need is a constrained version of RESTCONF. This could be (a= nd > should be) very simple. > > At 6TiSCH, we have started this work, with YANG based data model [1] and = a > CoAP-based protocol built around that [2], any URI starting with "/6t" is > to monitoring and manage the 6top sublayer. I believe there would be a hu= ge > benefit to having a more general solution, to which we all agree, i.e. a > CoAPified version of RESTCONF. COMAN looks like the right place to do thi= s. > > Thomas > > [1] http://tools.ietf.org/html/draft-ietf-6tisch-6top-interface-00 > [2] http://tools.ietf.org/html/draft-sudhaakar-6tisch-coap-01 > > > On Fri, Apr 4, 2014 at 5:16 PM, Andy Bierman wrote: > >> >> >> >> On Fri, Apr 4, 2014 at 6:49 AM, Carsten Bormann wrote: >> >>> >>> On 04 Apr 2014, at 13:45, Hannes Tschofenig >>> wrote: >>> >>> > Hi Carsten. >>> > >>> > >>> > On 04/04/2014 02:08 PM, Carsten Bormann wrote: >>> >> On 04 Apr 2014, at 13:32, Hannes Tschofenig < >>> hannes.tschofenig@gmx.net> wrote: >>> >> >>> >>> For me the software update mechanism is extremely important since i= t >>> is >>> >>> not just a way to replace the entire firmware but also to provision >>> >>> certain protocol parameters. >>> >> >>> >> Provisioning protocol parameters is one CoAP PUT to the right >>> resource. Cf. OMA LWM2M. >>> >> (They also do define a firmware update mechanism, but that seems to >>> presume the device has space for a complete firmware image.) >>> > >>> > That is exactly the question I raised when it comes to network >>> management. >>> > >>> > I don't understand what network management protocol add beyond what i= s >>> > already there with CoAP. >>> >>> Assuming we continue to use the client-server model of network >>> management, to use CoAP for this we need to define >>> >>> 1) What are the URIs that can be used for management? How does the >>> client learn them (combination of discovery, URI templates, HATEOAS)? >>> >>> 2) What are the representations being exchanged (data format, data >>> modeling method). >>> >>> >> RESTCONF addresses (1) and (2). >> It replaces HATEOAS with YANG in order to be extensible, >> modular, and predictable. The target use-case is programmatic >> control. HATEOAS seems more appropriate when human eyeballs and >> brain power are part of the state machine. >> >> IMO YANG would be a better long-term decision than SMIv2. >> It may seem that features like custom operations are too >> heavy-weight and over-kill for constrained networks, but it >> could be just the opposite. Custom operations allow expensive >> generic operations to be condensed and 'packaged' to be as >> small as possible. >> >> >> >> >>> 3) What is the security model. >>> >>> There has been a strong argument that we should not start from scratch >>> with (2) (and probably not entirely with (1) either), even if we are no= t >>> using the other parts of existing management protocols. >>> >>> Proposals to address (1) and (2) are, for instance: >>> http://tools.ietf.org/html/draft-vanderstok-core-comi-03 >>> http://www.tzi.de/~cabo/noms2014.pdf >>> >>> (My assumption is that ACE will be good enough to cover (3); we'll have >>> to make sure the lessons learned from management security go into ACE.) >>> >>> > Of course, you could replace CoAP entirely with SNMP >>> >>> SNMP is a bit more specialized and will not fit all applications that >>> CoAP is designed to cover. >>> But, yes, SNMP has been used successfully as an application protocol in >>> certain environments. >>> >>> >> If you want to do this the SEP2.0 way, you need EAP/PANA. >>> >> (SEP2.0 is targeting class-2+, not class-1.) >>> > >>> > With devices that are in direct connection with each other you could >>> > argue that there is no need for DTLS and alike since you will have to >>> > deal with the pairing procedure at the lower layer. Many devices fall >>> > into that category. >>> >>> (Defining single-hop security only is not very useful for the Internet >>> of Things.) >>> >>> > If that's not the case I believe you cannot assume that no network >>> > access authentication will be needed. >>> >>> Indeed, most wireless networks will need network access control. >>> Maybe there are ways to authorize (!) access to a network that are more >>> appropriate for the Internet of Things. >>> But this is outside the scope of COMAN. >>> >>> Gr=FC=DFe, Carsten >>> >>> >> >> Andy >> >> >> _______________________________________________ >> coman mailing list >> coman@ietf.org >> https://www.ietf.org/mailman/listinfo/coman >> >> > --001a1134f2bee577d004f64eaf4b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Apr 4, 2014 at 9:01 PM, Thomas Watteyne &= lt;watteyne= @eecs.berkeley.edu> wrote:
Andy, all,

If CoAP is already in nodes for the applications running on, you have a = monitoring/management solution almost for free. Want to monitoring the stat= e of some attribute of your protocol? Use CoAP observe. Want to change a pa= rameter of your protocol? CoAP PUT. On top of that, the work from CORE/DICE= /DTLS/ACE, will ensure security, including authentication and authorization= of management entities.

For nodes where CoAP is present for the application, pr= oposing an additional protocol will be a very hard sell.


It isn't another protocol.
It is a mapping of the RESTCONF data model framework onto CoAP.
<= div>
A RESTCONF mapping would really just describe what the s= erver was
expected to do wrt/ the content layer.


Andy

 
Of course, as poin= ted out by Carsten, we need to agree on the resources. What is the URI, wha= t methods are supported, what's the payload format, etc. YANG is a data= modeling language which enables exactly that. RESTCONF has a RESTful appro= ach to monitoring/management which is aligned with CoAP. What we would need= is a constrained version of RESTCONF. This could be (and should be) very s= imple.

At 6TiSCH, we have started this work, with YANG based d= ata model [1] and a CoAP-based protocol built around that [2], any URI star= ting with "/6t" is to monitoring and manage the 6top sublayer. I = believe there would be a huge benefit to having a more general solution, to= which we all agree, i.e. a CoAPified version of RESTCONF. COMAN looks like= the right place to do this.

Thomas



On Fri,= Apr 4, 2014 at 5:16 PM, Andy Bierman <andy@yumaworks.com> = wrote:



On Fri, Apr 4, 2014 at 6:49 AM,= Carsten Bormann <cabo@tzi.org> wrote:

On 04 Apr 2014, at 13:45, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote= :

> Hi Carsten.
>
>
> On 04/04/2014 02:08 PM, Carsten Bormann wrote:
>> On 04 Apr 2014, at 13:32, Hannes Tschofenig <hannes.tschofenig@gmx.net&= gt; wrote:
>>
>>> For me the software update mechanism is extremely important si= nce it is
>>> not just a way to replace the entire firmware but also to prov= ision
>>> certain protocol parameters.
>>
>> Provisioning protocol parameters is one CoAP PUT to the right reso= urce.  Cf. OMA LWM2M.
>> (They also do define a firmware update mechanism, but that seems t= o presume the device has space for a complete firmware image.)
>
> That is exactly the question I raised when it comes to network managem= ent.
>
> I don't understand what network management protocol add beyond wha= t is
> already there with CoAP.

Assuming we continue to use the client-server model of network management, = to use CoAP for this we need to define

1) What are the URIs that can be used for management?  How does the cl= ient learn them (combination of discovery, URI templates, HATEOAS)?

2) What are the representations being exchanged (data format, data modeling= method).


RESTCONF addresses (1) and (2).<= /div>
It replaces HATEOAS with YANG in order to be extensible,
modular, and predictable. The target use-case is programmatic
control.  HATEOAS seems more appropriate when human eyeballs and
brain power are part of the state machine.

IM= O YANG would be a better long-term decision than SMIv2.
It may se= em that features like custom operations are too
heavy-weight and = over-kill for constrained networks, but it
could be just the opposite.  Custom operations allow expensive
generic operations to be condensed and 'packaged' to be as<= /div>
small as possible.


 
3) What is the security model.

There has been a strong argument that we should not start from scratch with= (2) (and probably not entirely with (1) either), even if we are not using = the other parts of existing management protocols.

Proposals to address (1) and (2) are, for instance:
http://tools.ietf.org/html/draft-vanderstok-core-comi-03 http://w= ww.tzi.de/~cabo/noms2014.pdf

(My assumption is that ACE will be good enough to cover (3); we’ll ha= ve to make sure the lessons learned from management security go into ACE.)<= br>
> Of course, you could replace CoAP entirely with SNMP

SNMP is a bit more specialized and will not fit all applications that CoAP = is designed to cover.
But, yes, SNMP has been used successfully as an application protocol in cer= tain environments.

>> If you want to do this the SEP2.0 way, you need EAP/PANA.
>> (SEP2.0 is targeting class-2+, not class-1.)
>
> With devices that are in direct connection with each other you could > argue that there is no need for DTLS and alike since you will have to<= br> > deal with the pairing procedure at the lower layer. Many devices fall<= br> > into that category.

(Defining single-hop security only is not very useful for the Internet of T= hings.)

> If that's not the case I believe you cannot assume that no network=
> access authentication will be needed.

Indeed, most wireless networks will need network access control.
Maybe there are ways to authorize (!) access to a network that are more app= ropriate for the Internet of Things.
But this is outside the scope of COMAN.

Gr=FC=DFe, Carsten



Andy


_______________________________________________
coman mailing list
coman@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/coman



--001a1134f2bee577d004f64eaf4b-- From nobody Sat Apr 5 10:19:33 2014 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF0F1A03DA for ; Sat, 5 Apr 2014 10:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HaQ6bHH0nMHy for ; Sat, 5 Apr 2014 10:19:28 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 825AE1A02FC for ; Sat, 5 Apr 2014 10:19:28 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id fp1so4726776pdb.0 for ; Sat, 05 Apr 2014 10:19:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=5AUmF4Uoh68Mqk1BINwiq8fra3F+oK0zFLHFsypibmM=; b=QhVJ98U02WKkv7TPHcovprioPT3lC7Y6QbkMbWqxb/514xz4WuTQo/dOTolF+zFwi6 47m2N7ZMSmJNLCBAuBJ9Wu3DSbvaR+lxbllIPoRni6a6TXU4u24lujDm4znSX5Hwh7XV QwA9hW68CvzW5Xb0P+h+b8D1h1JucLPZPfPKa8Nm/b9+qOeMwvp1dPGSSNFqWFPrzW40 LBLbQavoMcxT2geHlVMljy1hs7ox2wbNVsRcw+1oOUhzUjA2giX5gHy4K6i+gUwo2TbQ 74LNewWSwqL31JhyVIgDd9YUjzpWD8FnUj4xEg/jiYjA10+SOThuZDCyxLW6xaB6Rq+a ZIXw== X-Received: by 10.66.254.166 with SMTP id aj6mr21779987pad.11.1396718363600; Sat, 05 Apr 2014 10:19:23 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.154.130 with HTTP; Sat, 5 Apr 2014 10:19:03 -0700 (PDT) In-Reply-To: References: <533BBFB7.2000100@gmx.net> <893C4FAC-437D-4140-9832-A9ABA2D1518A@tzi.org> <533E75A9.5080003@gmx.net> <8D653B3C-E678-4A66-9798-978950977694@tzi.org> <533E9864.4060806@gmx.net> <533E9B6B.1080602@gmx.net> From: Thomas Watteyne Date: Sat, 5 Apr 2014 10:19:03 -0700 X-Google-Sender-Auth: V2NLFJVDnvTwJMEne_lf4oPccSA Message-ID: To: Andy Bierman Content-Type: multipart/alternative; boundary=047d7b160007e9ed3604f64ed598 Archived-At: http://mailarchive.ietf.org/arch/msg/coman/KmgBGAlmPyW3Hsu7mVXO72UZI24 Cc: "coman@ietf.org" , Carsten Bormann , Hannes Tschofenig Subject: Re: [coman] Device Classes? X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.15 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, 05 Apr 2014 17:19:32 -0000 --047d7b160007e9ed3604f64ed598 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Andy, +1. I'm meant "proposing an additional protocol *not using CoAP* will be a very hard sell". I personally believe mapping RESTCONF onto CoAP is a good approach, sorry if that wasn't clear. Thomas On Sat, Apr 5, 2014 at 10:08 AM, Andy Bierman wrote: > > > > On Fri, Apr 4, 2014 at 9:01 PM, Thomas Watteyne < > watteyne@eecs.berkeley.edu> wrote: > >> Andy, all, >> >> If CoAP is already in nodes for the applications running on, you have a >> monitoring/management solution almost for free. Want to monitoring the >> state of some attribute of your protocol? Use CoAP observe. Want to chan= ge >> a parameter of your protocol? CoAP PUT. On top of that, the work from >> CORE/DICE/DTLS/ACE, will ensure security, including authentication and >> authorization of management entities. >> >> For nodes where CoAP is present for the application, proposing an >> additional protocol will be a very hard sell. >> >> > It isn't another protocol. > It is a mapping of the RESTCONF data model framework onto CoAP. > > A RESTCONF mapping would really just describe what the server was > expected to do wrt/ the content layer. > > > Andy > > > >> Of course, as pointed out by Carsten, we need to agree on the resources. >> What is the URI, what methods are supported, what's the payload format, >> etc. YANG is a data modeling language which enables exactly that. RESTCO= NF >> has a RESTful approach to monitoring/management which is aligned with Co= AP. >> What we would need is a constrained version of RESTCONF. This could be (= and >> should be) very simple. >> >> At 6TiSCH, we have started this work, with YANG based data model [1] and >> a CoAP-based protocol built around that [2], any URI starting with "/6t"= is >> to monitoring and manage the 6top sublayer. I believe there would be a h= uge >> benefit to having a more general solution, to which we all agree, i.e. a >> CoAPified version of RESTCONF. COMAN looks like the right place to do th= is. >> >> Thomas >> >> [1] http://tools.ietf.org/html/draft-ietf-6tisch-6top-interface-00 >> [2] http://tools.ietf.org/html/draft-sudhaakar-6tisch-coap-01 >> >> >> On Fri, Apr 4, 2014 at 5:16 PM, Andy Bierman wrote: >> >>> >>> >>> >>> On Fri, Apr 4, 2014 at 6:49 AM, Carsten Bormann wrote: >>> >>>> >>>> On 04 Apr 2014, at 13:45, Hannes Tschofenig >>>> wrote: >>>> >>>> > Hi Carsten. >>>> > >>>> > >>>> > On 04/04/2014 02:08 PM, Carsten Bormann wrote: >>>> >> On 04 Apr 2014, at 13:32, Hannes Tschofenig < >>>> hannes.tschofenig@gmx.net> wrote: >>>> >> >>>> >>> For me the software update mechanism is extremely important since >>>> it is >>>> >>> not just a way to replace the entire firmware but also to provisio= n >>>> >>> certain protocol parameters. >>>> >> >>>> >> Provisioning protocol parameters is one CoAP PUT to the right >>>> resource. Cf. OMA LWM2M. >>>> >> (They also do define a firmware update mechanism, but that seems to >>>> presume the device has space for a complete firmware image.) >>>> > >>>> > That is exactly the question I raised when it comes to network >>>> management. >>>> > >>>> > I don't understand what network management protocol add beyond what = is >>>> > already there with CoAP. >>>> >>>> Assuming we continue to use the client-server model of network >>>> management, to use CoAP for this we need to define >>>> >>>> 1) What are the URIs that can be used for management? How does the >>>> client learn them (combination of discovery, URI templates, HATEOAS)? >>>> >>>> 2) What are the representations being exchanged (data format, data >>>> modeling method). >>>> >>>> >>> RESTCONF addresses (1) and (2). >>> It replaces HATEOAS with YANG in order to be extensible, >>> modular, and predictable. The target use-case is programmatic >>> control. HATEOAS seems more appropriate when human eyeballs and >>> brain power are part of the state machine. >>> >>> IMO YANG would be a better long-term decision than SMIv2. >>> It may seem that features like custom operations are too >>> heavy-weight and over-kill for constrained networks, but it >>> could be just the opposite. Custom operations allow expensive >>> generic operations to be condensed and 'packaged' to be as >>> small as possible. >>> >>> >>> >>> >>>> 3) What is the security model. >>>> >>>> There has been a strong argument that we should not start from scratch >>>> with (2) (and probably not entirely with (1) either), even if we are n= ot >>>> using the other parts of existing management protocols. >>>> >>>> Proposals to address (1) and (2) are, for instance: >>>> http://tools.ietf.org/html/draft-vanderstok-core-comi-03 >>>> http://www.tzi.de/~cabo/noms2014.pdf >>>> >>>> (My assumption is that ACE will be good enough to cover (3); we'll hav= e >>>> to make sure the lessons learned from management security go into ACE.= ) >>>> >>>> > Of course, you could replace CoAP entirely with SNMP >>>> >>>> SNMP is a bit more specialized and will not fit all applications that >>>> CoAP is designed to cover. >>>> But, yes, SNMP has been used successfully as an application protocol i= n >>>> certain environments. >>>> >>>> >> If you want to do this the SEP2.0 way, you need EAP/PANA. >>>> >> (SEP2.0 is targeting class-2+, not class-1.) >>>> > >>>> > With devices that are in direct connection with each other you could >>>> > argue that there is no need for DTLS and alike since you will have t= o >>>> > deal with the pairing procedure at the lower layer. Many devices fal= l >>>> > into that category. >>>> >>>> (Defining single-hop security only is not very useful for the Internet >>>> of Things.) >>>> >>>> > If that's not the case I believe you cannot assume that no network >>>> > access authentication will be needed. >>>> >>>> Indeed, most wireless networks will need network access control. >>>> Maybe there are ways to authorize (!) access to a network that are mor= e >>>> appropriate for the Internet of Things. >>>> But this is outside the scope of COMAN. >>>> >>>> Gr=FC=DFe, Carsten >>>> >>>> >>> >>> Andy >>> >>> >>> _______________________________________________ >>> coman mailing list >>> coman@ietf.org >>> https://www.ietf.org/mailman/listinfo/coman >>> >>> >> > --047d7b160007e9ed3604f64ed598 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Andy,
+1. 
I'm meant "proposin= g an additional protocol *not using CoAP* will be a very hard sell". I= personally believe mapping RESTCONF onto CoAP is a good approach, sorry if= that wasn't clear.
Thomas


On Sat, Apr 5, 2014 at 10:08 AM, Andy Bierman &= lt;andy@yumaworks.c= om> wrote:



On Fri, Apr 4, 2014 = at 9:01 PM, Thomas Watteyne <watteyne@eecs.berkeley.edu> wrote:
Andy, all,

If CoAP is already in nodes for the applications running on, you have a = monitoring/management solution almost for free. Want to monitoring the stat= e of some attribute of your protocol? Use CoAP observe. Want to change a pa= rameter of your protocol? CoAP PUT. On top of that, the work from CORE/DICE= /DTLS/ACE, will ensure security, including authentication and authorization= of management entities.

For nodes where CoAP is present for the application, pr= oposing an additional protocol will be a very hard sell.


It isn't another protoco= l.
It is a mapping of the RESTCONF data model framework onto CoAP.
<= div>
A RESTCONF mapping would really just describe what the s= erver was
expected to do wrt/ the content layer.


Andy

 
Of course, as pointed out by Carsten, we need to agree on the re= sources. What is the URI, what methods are supported, what's the payloa= d format, etc. YANG is a data modeling language which enables exactly that.= RESTCONF has a RESTful approach to monitoring/management which is aligned = with CoAP. What we would need is a constrained version of RESTCONF. This co= uld be (and should be) very simple.

At 6TiSCH, we have started this work, with YANG based d= ata model [1] and a CoAP-based protocol built around that [2], any URI star= ting with "/6t" is to monitoring and manage the 6top sublayer. I = believe there would be a huge benefit to having a more general solution, to= which we all agree, i.e. a CoAPified version of RESTCONF. COMAN looks like= the right place to do this.

Thomas



On Fri,= Apr 4, 2014 at 5:16 PM, Andy Bierman <andy@yumaworks.com> = wrote:



On Fri, Apr 4, 2014 at 6:49 AM,= Carsten Bormann <cabo@tzi.org> wrote:

On 04 Apr 2014, at 13:45, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote= :

> Hi Carsten.
>
>
> On 04/04/2014 02:08 PM, Carsten Bormann wrote:
>> On 04 Apr 2014, at 13:32, Hannes Tschofenig <hannes.tschofenig@gmx.net&= gt; wrote:
>>
>>> For me the software update mechanism is extremely important si= nce it is
>>> not just a way to replace the entire firmware but also to prov= ision
>>> certain protocol parameters.
>>
>> Provisioning protocol parameters is one CoAP PUT to the right reso= urce.  Cf. OMA LWM2M.
>> (They also do define a firmware update mechanism, but that seems t= o presume the device has space for a complete firmware image.)
>
> That is exactly the question I raised when it comes to network managem= ent.
>
> I don't understand what network management protocol add beyond wha= t is
> already there with CoAP.

Assuming we continue to use the client-server model of network management, = to use CoAP for this we need to define

1) What are the URIs that can be used for management?  How does the cl= ient learn them (combination of discovery, URI templates, HATEOAS)?

2) What are the representations being exchanged (data format, data modeling= method).


RESTCONF addresses (1) and (2).<= /div>
It replaces HATEOAS with YANG in order to be extensible,
modular, and predictable. The target use-case is programmatic
control.  HATEOAS seems more appropriate when human eyeballs and
brain power are part of the state machine.

IM= O YANG would be a better long-term decision than SMIv2.
It may se= em that features like custom operations are too
heavy-weight and = over-kill for constrained networks, but it
could be just the opposite.  Custom operations allow expensive
generic operations to be condensed and 'packaged' to be as<= /div>
small as possible.


 
3) What is the security model.

There has been a strong argument that we should not start from scratch with= (2) (and probably not entirely with (1) either), even if we are not using = the other parts of existing management protocols.

Proposals to address (1) and (2) are, for instance:
http://tools.ietf.org/html/draft-vanderstok-core-comi-03 http://w= ww.tzi.de/~cabo/noms2014.pdf

(My assumption is that ACE will be good enough to cover (3); we’ll ha= ve to make sure the lessons learned from management security go into ACE.)<= br>
> Of course, you could replace CoAP entirely with SNMP

SNMP is a bit more specialized and will not fit all applications that CoAP = is designed to cover.
But, yes, SNMP has been used successfully as an application protocol in cer= tain environments.

>> If you want to do this the SEP2.0 way, you need EAP/PANA.
>> (SEP2.0 is targeting class-2+, not class-1.)
>
> With devices that are in direct connection with each other you could > argue that there is no need for DTLS and alike since you will have to<= br> > deal with the pairing procedure at the lower layer. Many devices fall<= br> > into that category.

(Defining single-hop security only is not very useful for the Internet of T= hings.)

> If that's not the case I believe you cannot assume that no network=
> access authentication will be needed.

Indeed, most wireless networks will need network access control.
Maybe there are ways to authorize (!) access to a network that are more app= ropriate for the Internet of Things.
But this is outside the scope of COMAN.

Gr=FC=DFe, Carsten



Andy


_______________________________________________
coman mailing list
coman@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/coman




--047d7b160007e9ed3604f64ed598-- From nobody Sun Apr 6 23:38:48 2014 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1D121A0679 for ; Sun, 6 Apr 2014 23:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.885 X-Spam-Level: ** X-Spam-Status: No, score=2.885 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id di0Cipr2iDCB for ; Sun, 6 Apr 2014 23:38:42 -0700 (PDT) Received: from smtp-vbr13.xs4all.nl (smtp-vbr13.xs4all.nl [194.109.24.33]) by ietfa.amsl.com (Postfix) with ESMTP id 591721A02CC for ; Sun, 6 Apr 2014 23:38:41 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube1.xs4all.net [194.109.20.195]) by smtp-vbr13.xs4all.nl (8.13.8/8.13.8) with ESMTP id s376cXZb010450; Mon, 7 Apr 2014 08:38:34 +0200 (CEST) (envelope-from stokcons@xs4all.nl) Received: from a82-95-140-48.adsl.xs4all.nl ([82.95.140.48]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 07 Apr 2014 08:38:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 07 Apr 2014 08:38:33 +0200 From: peter van der Stok To: Hannes Tschofenig , Carsten Bormann , coman@ietf.org Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <20140404130409.GB81513@elstar.local> References: <533BBFB7.2000100@gmx.net> <893C4FAC-437D-4140-9832-A9ABA2D1518A@tzi.org> <533E75A9.5080003@gmx.net> <8D653B3C-E678-4A66-9798-978950977694@tzi.org> <533E9864.4060806@gmx.net> <533E9B6B.1080602@gmx.net> <20140404130409.GB81513@elstar.local> Message-ID: X-Sender: stokcons@xs4all.nl (dj4RI8RGTKVizx5x+wwqssRs45CeExRl) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Archived-At: http://mailarchive.ietf.org/arch/msg/coman/RnFCCm0Kq8lrIqAGQiO0TTfeR0o Subject: Re: [coman] =?utf-8?q?Device_Classes=3F?= X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 06:38:47 -0000 > It would be really nice if we would all have a common understanding of > what roughly the code and storage requirements of the various > protocols involved are. Is LWIG producing something a kind of a survey > like this? If so, this would be great I think. > > /js +1 Peter van der Stok From nobody Mon Apr 7 08:57:43 2014 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC14B1A07D9 for ; Mon, 7 Apr 2014 08:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPGsT1wLLk6w for ; Mon, 7 Apr 2014 08:57:36 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 96BB81A0795 for ; Mon, 7 Apr 2014 08:57:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1245; q=dns/txt; s=iport; t=1396886251; x=1398095851; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=xWAUxAaINPSQJPQVOyyO2jtvANxqs2YfltsYqPvk3zg=; b=G4yGNQGbCQhnWuNFQT0My1vH4fqEOCWV+M89Z/2X6aGGgi8+viLjCbdm 0Gco7OSk8Gdu+1wGOOPoIoEzwkfwF3+NGVcXHMK1Hn972nJOF/OEMf9V1 m6vKEs60nnBPN4oveh4+5yEsKzKeid8w03xhg6VuqWac26lO32FGPxu0R c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAJzKQlOtJA2I/2dsb2JhbABZgwbFMIElFnSCJQEBAQMBGCBAEQsYCRYPCQMCAQIBRRMIAQGHbQivVJwuF44oUBaEIgEDmFuGUYtug0whgS0 X-IronPort-AV: E=Sophos;i="4.97,810,1389744000"; d="scan'208";a="33681371" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-3.cisco.com with ESMTP; 07 Apr 2014 15:57:08 +0000 Received: from [10.86.246.56] ([10.86.246.56]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s37Fv7qB001646 for ; Mon, 7 Apr 2014 15:57:07 GMT Message-ID: <5342CAD2.6050004@cisco.com> Date: Mon, 07 Apr 2014 11:57:06 -0400 From: Paul Duffy Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: coman@ietf.org References: <533BBFB7.2000100@gmx.net> <893C4FAC-437D-4140-9832-A9ABA2D1518A@tzi.org> <533E75A9.5080003@gmx.net> <8D653B3C-E678-4A66-9798-978950977694@tzi.org> <533E9864.4060806@gmx.net> <533E9B6B.1080602@gmx.net> <20140404130409.GB81513@elstar.local> In-Reply-To: <20140404130409.GB81513@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/coman/uaO43tpMSOLUzICfY0y7oCWWtvs Subject: Re: [coman] Device Classes? X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: paduffy@cisco.com List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 15:57:42 -0000 On 4/4/2014 9:04 AM, Juergen Schoenwaelder wrote: > On Fri, Apr 04, 2014 at 01:45:47PM +0200, Hannes Tschofenig wrote: >> Of course, you could replace CoAP entirely with SNMP (as Juergen had >> suggested). >> > I did not suggest to replace CoAP with SNMP. What I said is: > > 1) We have done an SNMP only implementation and we know it works and > what the resource consumption is. Please more detail? SNMP version? Security? Implemented MIBs, etc? > > 2) I see potential in a RESTCONF to CoAP mapping for devices that do > CoAP. > > 3) I agree with the desire to keep code down to a minimum and thus to > keep the number of protocols needed to a minimum. > > 4) In our experience, the biggest chunk of code and memory goes to > security and in particular crypto algorithms. Being able to exploit > crypto hardware is a major plus as is using the same security and > crypto mechanisms for all protocols supported. > > It would be really nice if we would all have a common understanding of > what roughly the code and storage requirements of the various > protocols involved are. Is LWIG producing something a kind of a survey > like this? If so, this would be great I think. > > /js > From nobody Mon Apr 7 10:29:07 2014 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447191A01E0 for ; Mon, 7 Apr 2014 10:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDobbldQrK-f for ; Mon, 7 Apr 2014 10:28:54 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id A882C1A07B6 for ; Mon, 7 Apr 2014 10:28:54 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id CA773EB2; Mon, 7 Apr 2014 19:28:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id wYFsyzpAhPBb; Mon, 7 Apr 2014 19:28:48 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 7 Apr 2014 19:28:48 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3BF6920033; Mon, 7 Apr 2014 19:28:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Y5_MWWDjZtna; Mon, 7 Apr 2014 19:28:47 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4513A2002F; Mon, 7 Apr 2014 19:28:47 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2EAB72C2AC59; Mon, 7 Apr 2014 19:28:46 +0200 (CEST) Date: Mon, 7 Apr 2014 19:28:46 +0200 From: Juergen Schoenwaelder To: Paul Duffy Message-ID: <20140407172845.GA2603@elstar.local> Mail-Followup-To: Paul Duffy , coman@ietf.org References: <533BBFB7.2000100@gmx.net> <893C4FAC-437D-4140-9832-A9ABA2D1518A@tzi.org> <533E75A9.5080003@gmx.net> <8D653B3C-E678-4A66-9798-978950977694@tzi.org> <533E9864.4060806@gmx.net> <533E9B6B.1080602@gmx.net> <20140404130409.GB81513@elstar.local> <5342CAD2.6050004@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5342CAD2.6050004@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/coman/G1dsBj2j272eZwnmgX9dGhBOdtE Cc: coman@ietf.org Subject: Re: [coman] Device Classes? X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 07 Apr 2014 17:28:59 -0000 On Mon, Apr 07, 2014 at 11:57:06AM -0400, Paul Duffy wrote: > On 4/4/2014 9:04 AM, Juergen Schoenwaelder wrote: > >On Fri, Apr 04, 2014 at 01:45:47PM +0200, Hannes Tschofenig wrote: > >>Of course, you could replace CoAP entirely with SNMP (as Juergen had > >>suggested). > >> > >I did not suggest to replace CoAP with SNMP. What I said is: > > > >1) We have done an SNMP only implementation and we know it works and > > what the resource consumption is. > > Please more detail? SNMP version? Security? Implemented MIBs, etc? > http://dx.doi.org/10.1109/MCOM.2012.6384464 http://dx.doi.org/10.1109/GreenCom.2012.21 http://dx.doi.org/10.1007/978-3-642-21484-4_13 In short, we implemented all three versions of SNMP including USM security. We also did our own DTLS implementation but did not find the time to integrate it into the SNMP code. Anyway, if you do security in software, this is a big hit - far bigger than the protocol stuff. Concerning MIBs, we did a bit of the IF-MIB, the LOWPAN-MIB and the RPL-MIB plus bits and pieced of the ENTITY-MIB and the ENTITY-SENSOR-MIB (the later we used to expose an energy sensor attached to a mote). Fitting all the MIB modules plus SNMPv3 on the modes is getting tough since RPL eats quite some resources (but things may have improved meanwhile). /js PS: No additional standards were needed to do any of the SNMP stuff. ;-) -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103