From nobody Fri Aug 1 13:03:33 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9221B28B3; Fri, 1 Aug 2014 13:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 ZsEYoBOi2jpM; Fri, 1 Aug 2014 13:00:51 -0700 (PDT) Received: from fncnmp04.fnc.fujitsu.com (fncnmp04.fnc.fujitsu.com [168.127.0.57]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 899811A0467; Fri, 1 Aug 2014 13:00:50 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.01,781,1400043600"; d="scan'208,217"; a="54335056" Received: from rchexhcp2.fnc.net.local ([168.127.134.76]) by fncnmp02.fnc.fujitsu.com with ESMTP/TLS/AES128-SHA; 01 Aug 2014 15:00:49 -0500 Received: from RCHEXMBP1.fnc.net.local ([169.254.2.63]) by RCHEXHCP2.fnc.net.local ([168.127.134.76]) with mapi id 14.03.0181.006; Fri, 1 Aug 2014 15:00:48 -0500 From: "O'Connor, Don" To: Greg Mirsky Thread-Topic: [nvo3] YANG models for OAM Thread-Index: Ac+E3qlMyPi638vnRGmjYh75Wx+edAoWIbcAAAE6agAACU5iwP//xQ4A//8BvNA= Date: Fri, 1 Aug 2014 20:00:48 +0000 Message-ID: <7DFA7869D33BD44A9A84BA24AD75BDE6D9E46A72@RCHEXMBP1.fnc.net.local> References: <1406847186.16320.YahooMailNeo@web162805.mail.bf1.yahoo.com> <7DFA7869D33BD44A9A84BA24AD75BDE6D9E4645D@RCHEXMBP1.fnc.net.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [168.127.136.253] x-tm-as-product-ver: SMEX-10.2.0.3176-7.500.1018-20854.002 x-tm-as-result: No--56.649100-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_7DFA7869D33BD44A9A84BA24AD75BDE6D9E46A72RCHEXMBP1fncnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/K9ezkqALAvdriYlWP7yQgwNxJRM X-Mailman-Approved-At: Fri, 01 Aug 2014 13:03:30 -0700 Cc: "l2vpn@ietf.org" , "opsawg@ietf.org" , "nvo3@ietf.org" , "netmod@ietf.org" , "trill@ietf.org" Subject: Re: [OPSAWG] [nvo3] YANG models for OAM X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 20:00:57 -0000 --_000_7DFA7869D33BD44A9A84BA24AD75BDE6D9E46A72RCHEXMBP1fncnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R3JlZw0KDQpUaGUgc2NvcGUgb2YgdGhlIE1FRiBzcGVjaWZpY2F0aW9ucyBpcyB0aGUgRXRoZXJu ZXQgU2VydmljZSBMYXllciBmb3IgQ2FycmllciBFdGhlcm5ldCBTZXJ2aWNlcyDigJMgRmF1bHQg TWFuYWdlbWVudCBhbmQgUGVyZm9ybWFuY2UgTWFuYWdlbWVudA0KDQpSZWdhcmRzDQoNCkRvbg0K DQpGcm9tOiBMMnZwbiBbbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBHcmVnIE1pcnNreQ0KU2VudDogVGh1cnNkYXksIEp1bHkgMzEsIDIwMTQgNjo0OSBQTQ0KVG86 IE8nQ29ubm9yLCBEb24NCkNjOiBsMnZwbkBpZXRmLm9yZzsgbmV0bW9kQGlldGYub3JnOyBudm8z QGlldGYub3JnOyB0cmlsbEBpZXRmLm9yZzsgb3BzYXdnQGlldGYub3JnDQpTdWJqZWN0OiBSZTog W252bzNdIFlBTkcgbW9kZWxzIGZvciBPQU0NCg0KSGkgRG9uLA0KdGhhbmsgeW91IGZvciB0aGUg cmVmZXJlbmNlLiBBbmQgSSdkIHBvaW50IHRoYXQgSVRVIFNHMTUgaXMgd29ya2luZyBvbiBzdGFu ZGFyZGl6aW5nICJnZW5lcmljIHByb3RvY29sLW5ldXRyYWwgbWFuYWdlbWVudCBpbmZvcm1hdGlv biBtb2RlbCIgZm9yIHRyYW5zcG9ydCBuZXR3b3JrLCBpbmNsdWRpbmcgT0FNLiBIZW5jZSBteSBx dWVzdGlvbiwgV2hhdCBpcyB0aGUgc2NvcGUgb2YgdGhlc2UgZG9jdW1lbnRzPw0KUmVnYXJkcywN CkdyZWcNCg0KT24gVGh1LCBKdWwgMzEsIDIwMTQgYXQgNDozMSBQTSwgTydDb25ub3IsIERvbiA8 ZG9uLm9jb25ub3JAdXMuZnVqaXRzdS5jb208bWFpbHRvOmRvbi5vY29ubm9yQHVzLmZ1aml0c3Uu Y29tPj4gd3JvdGU6DQpUaXNzYSwgR3JlZywgYWxsDQoNCk1ldHJvIEV0aGVybmV0IEZvcnVtIGhh cyBhbHJlYWR5IHN0YW5kYXJkaXplZCBZYW5nIE1vZHVsZXMgZm9yIEV0aGVybmV0IFNlcnZpY2Ug T0FNIFBlcmZvcm1hbmNlIE1vbml0b3JpbmcgYW5kIEZhdWx0IE1hbmFnZW1lbnQuIFBsZWFzZSBz ZWUgTUVGIDM4IGFuZCAzOQ0KDQpodHRwOi8vbWV0cm9ldGhlcm5ldGZvcnVtLm9yZy9jYXJyaWVy LWV0aGVybmV0L3RlY2huaWNhbC1zcGVjaWZpY2F0aW9ucw0KDQpSZWdhcmRzDQoNCkRvbg0KDQpG cm9tOiBMMnZwbiBbbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmwydnBuLWJv dW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgVGlzc2EgU2VuZXZpcmF0aG5lDQpTZW50OiBU aHVyc2RheSwgSnVseSAzMSwgMjAxNCA1OjUzIFBNDQpUbzogR3JlZyBNaXJza3k7IFRpc3NhIFNl bmV2aXJhdGhuZSAodHNlbmV2aXIpDQoNCkNjOiBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5A aWV0Zi5vcmc+OyBvcHNhd2dAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Z0BpZXRmLm9yZz47IG52bzNA aWV0Zi5vcmc8bWFpbHRvOm52bzNAaWV0Zi5vcmc+OyBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5l dG1vZEBpZXRmLm9yZz47IHRyaWxsQGlldGYub3JnPG1haWx0bzp0cmlsbEBpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbbnZvM10gWUFORyBtb2RlbHMgZm9yIE9BTQ0KDQpHcmVnDQoNClllcyBpdCBp cywgZ2VuZXJpYyBZQU5HIG1vZGVsIHN0ZXVwIHRoZSBiYXNlIGZyYW1ld29yay4gSXQgY2FuIGJl IGV4dGVuZGVkIHRvIGFkZCB0b29scyBhcyB3ZWxsIGFzIG90aGVyIGVsZW1lbnRzIGFzIHdlbGwg dGVjaG5vbG9neSBkZXZpYXRpb25zLiBBbGFybXMgZXRjIGVpdGhlciBiZSBwYXJ0IG9mIHRoaXMg ZG9jdW1lbnQgd2lsbCBiZSBhIHNlcGFyYXRlIGRvY3VtZW50IHRoYXQgc3BlY2lmaWVzIHRoZW0u IFRoYXQgaXMgdGhlIHJlYXNvbiB3ZSBoYXZlIGRlc2lnbmVkIHRoZSBtb2RlbCBhcyBtb2R1bGFy IGFzIHBvc3NpYmxlIGFuZCBleHRlbnNpYmxlIGFzIHBvc3NpYmxlLg0KDQpQbGVhc2UgbGV0IHVz IGtub3cgaWYgYW55IG9mIHRoZSBwYXJ0cyBhcmUgbm90IGV4dGVuc2libGUgb3Igbm90IG1vZHVs YXIgZW5vdWdoLg0KDQpUaGFua3MNClRpc3NhDQoNCk9uIFRodXJzZGF5LCBKdWx5IDMxLCAyMDE0 IDM6MTcgUE0sIEdyZWcgTWlyc2t5IDxncmVnaW1pcnNreUBnbWFpbC5jb208bWFpbHRvOmdyZWdp bWlyc2t5QGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpIaSBUaXNzYSwgYXV0aG9ycywgZXQuIGFsLA0K SSd2ZSByZWFkIGRvY3VtZW50cyBhbmQgd291bGQgbGlrZSB0byBjbGFyaWZ5IHNjb3BlIG9mIHRo ZXNlIGRvY3VtZW50cy4gT0FNIGlzIG5vdCBsaW1pdGVkIHRvIHBpbmcgYW5kIHRyYWNlcm91dGUg ZnVuY3Rpb25zLiBJdCBldmVuIG5vdCBsaW1pdGVkIHRvIGNvbnRpbnVpdHkgY2hlY2suIEFuZCBp biBjb25uZWN0aW9ubGVzcyBuZXR3b3JrcyB0aGVyZSB3b3VsZCBub3QgYmUgY29ubmVjdGl2aXR5 IHZlcmlmaWNhdGlvbi4gQW5kIHRoZSBwZXJmb3JtYW5jZSBtZWFzdXJlbWVudCBpcyB0aGUgYmln IHBhcnQgb2YgT0FNIGFzIHdlbGwgYXMgcHJvdGVjdGlvbiBjb29yZGluYXRpb24sIGRlZmVjdCBh bGFybXMsIGFuZCBldGMuIEhlbmNlIG15IHF1ZXN0aW9uLCBpcyBpdCBpbiBwbGFucyBvZiB0aGUg YXV0aG9ycyB0byBhZGRyZXNzIGFsbCBvZiBPQU0gaW4gcmVzcGVjdGl2ZSBkb2N1bWVudHM/DQpS ZWdhcmRzLA0KR3JlZw0KDQpPbiBUdWUsIEp1biAxMCwgMjAxNCBhdCAxMjowMyBQTSwgVGlzc2Eg U2VuZXZpcmF0aG5lICh0c2VuZXZpcikgPHRzZW5ldmlyQGNpc2NvLmNvbTxtYWlsdG86dHNlbmV2 aXJAY2lzY28uY29tPj4gd3JvdGU6DQpBbGwNCg0KV2UgaGF2ZSBwdWJsaXNoZWQgWUFORyBtb2Rl bCBmb3IgT0FNLiAjMSBkcmFmdCBiZWxvdyBwbGFjZSB0aGUgZ2VuZXJpYyBmcmFtZXdvcmsgZm9y IE9BTSwgdGhhdCBjYW4gYmUgYXVnbWVudGVkIGZvciBkaWZmZXJlbnQgdGVjaG5vbG9naWVzLiAj MiBhbmQgIzMgYXJlIGFwcGxpY2F0aW9uIG9mIHRoZSBjb25jZXB0IHRvIE5WTzMgYW5kIFRSSUxM LA0KDQoxLiAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGlzc2Et bmV0bW9kLW9hbS8NCjIuICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC10aXNzYS1udm8zLXlhbmctb2FtLw0KMy4gICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LXRpc3NhLXRyaWxsLXlhbmctb2FtLw0KDQpQbGVhc2UgcmV2aWV3IGFuZCBz aGFyZSB5b3VyIGNvbW1lbnRzDQoNClRoYW5rcw0KVGlzc2ENCg0KDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpudm8zIG1haWxpbmcgbGlzdA0KbnZv M0BpZXRmLm9yZzxtYWlsdG86bnZvM0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbnZvMw0KDQoNCg0K --_000_7DFA7869D33BD44A9A84BA24AD75BDE6D9E46A72RCHEXMBP1fncnet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRp di5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi QmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7 fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24g VGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxT dHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7DQoJZm9udC13ZWlnaHQ6bm9ybWFs Ow0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5H cmVnPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlRoZSBzY29wZSBvZiB0aGUgTUVGIHNwZWNpZmljYXRpb25zIGlzIHRoZSBFdGhl cm5ldCBTZXJ2aWNlIExheWVyIGZvciBDYXJyaWVyIEV0aGVybmV0IFNlcnZpY2VzIOKAkyBGYXVs dCBNYW5hZ2VtZW50IGFuZCBQZXJmb3JtYW5jZSBNYW5hZ2VtZW50PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+RG9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4gTDJ2cG4gW21haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnXQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5HcmVnIE1pcnNreTxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2Rh eSwgSnVseSAzMSwgMjAxNCA2OjQ5IFBNPGJyPg0KPGI+VG86PC9iPiBPJ0Nvbm5vciwgRG9uPGJy Pg0KPGI+Q2M6PC9iPiBsMnZwbkBpZXRmLm9yZzsgbmV0bW9kQGlldGYub3JnOyBudm8zQGlldGYu b3JnOyB0cmlsbEBpZXRmLm9yZzsgb3BzYXdnQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbbnZvM10gWUFORyBtb2RlbHMgZm9yIE9BTTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgRG9uLDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPnRoYW5rIHlvdSBmb3IgdGhlIHJlZmVyZW5jZS4gQW5kIEknZCBwb2ludCB0aGF0 IElUVSBTRzE1IGlzIHdvcmtpbmcgb24gc3RhbmRhcmRpemluZyAmcXVvdDtnZW5lcmljIHByb3Rv Y29sLW5ldXRyYWwgbWFuYWdlbWVudCBpbmZvcm1hdGlvbiBtb2RlbCZxdW90OyBmb3IgdHJhbnNw b3J0IG5ldHdvcmssIGluY2x1ZGluZyBPQU0uIEhlbmNlIG15IHF1ZXN0aW9uLCBXaGF0IGlzIHRo ZQ0KIHNjb3BlIG9mIHRoZXNlIGRvY3VtZW50cz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+R3JlZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEp1bCAzMSwgMjAx NCBhdCA0OjMxIFBNLCBPJ0Nvbm5vciwgRG9uICZsdDs8YSBocmVmPSJtYWlsdG86ZG9uLm9jb25u b3JAdXMuZnVqaXRzdS5jb20iIHRhcmdldD0iX2JsYW5rIj5kb24ub2Nvbm5vckB1cy5mdWppdHN1 LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ VGlzc2EsIEdyZWcsIGFsbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWV0cm8gRXRoZXJuZXQgRm9ydW0gaGFzIGFscmVh ZHkgc3RhbmRhcmRpemVkIFlhbmcgTW9kdWxlcyBmb3IgRXRoZXJuZXQgU2VydmljZSBPQU0gUGVy Zm9ybWFuY2UgTW9uaXRvcmluZw0KIGFuZCBGYXVsdCBNYW5hZ2VtZW50LiBQbGVhc2Ugc2VlIE1F RiAzOCBhbmQgMzk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHA6Ly9tZXRyb2V0aGVybmV0Zm9ydW0u b3JnL2NhcnJpZXItZXRoZXJuZXQvdGVjaG5pY2FsLXNwZWNpZmljYXRpb25zIiB0YXJnZXQ9Il9i bGFuayI+aHR0cDovL21ldHJvZXRoZXJuZXRmb3J1bS5vcmcvY2Fycmllci1ldGhlcm5ldC90ZWNo bmljYWwtc3BlY2lmaWNhdGlvbnM8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Eb248 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEwydnBuIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmwydnBu LWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5sMnZwbi1ib3VuY2VzQGlldGYub3Jn PC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+VGlzc2EgU2VuZXZpcmF0aG5lPGJyPg0KPGI+U2Vu dDo8L2I+IFRodXJzZGF5LCBKdWx5IDMxLCAyMDE0IDU6NTMgUE08YnI+DQo8Yj5Ubzo8L2I+IEdy ZWcgTWlyc2t5OyBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8Yj5DYzo8L2I+IDxhIGhy ZWY9Im1haWx0bzpsMnZwbkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmwydnBuQGlldGYub3Jn PC9hPjsgPGEgaHJlZj0ibWFpbHRvOm9wc2F3Z0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0K b3BzYXdnQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOm52bzNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5udm8zQGlldGYub3JnPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5uZXRtb2RAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWls dG86dHJpbGxAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCnRyaWxsQGlldGYub3JnPC9hPjxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW252bzNdIFlBTkcgbW9kZWxzIGZvciBPQU08bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+R3JlZzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj5ZZXMgaXQgaXMsIGdlbmVyaWMgWUFORyBtb2RlbCBzdGV1cCB0 aGUgYmFzZSBmcmFtZXdvcmsuIEl0IGNhbiBiZSBleHRlbmRlZCB0byBhZGQgdG9vbHMgYXMgd2Vs bCBhcyBvdGhlciBlbGVtZW50cw0KIGFzIHdlbGwgdGVjaG5vbG9neSBkZXZpYXRpb25zLiBBbGFy bXMgZXRjIGVpdGhlciBiZSBwYXJ0IG9mIHRoaXMgZG9jdW1lbnQgd2lsbCBiZSBhIHNlcGFyYXRl IGRvY3VtZW50IHRoYXQgc3BlY2lmaWVzIHRoZW0uIFRoYXQgaXMgdGhlIHJlYXNvbiB3ZSBoYXZl IGRlc2lnbmVkIHRoZSBtb2RlbCBhcyBtb2R1bGFyIGFzIHBvc3NpYmxlIGFuZCBleHRlbnNpYmxl IGFzIHBvc3NpYmxlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+UGxlYXNlIGxldCB1cyBrbm93IGlmIGFueSBvZiB0aGUg cGFydHMgYXJlIG5vdCBleHRlbnNpYmxlIG9yIG5vdCBtb2R1bGFyIGVub3VnaC48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PlRoYW5rczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaXNzYTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRl Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+T24gVGh1cnNkYXksIEp1bHkgMzEsIDIwMTQgMzoxNyBQTSwgR3JlZyBNaXJza3kgJmx0 OzxhIGhyZWY9Im1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5n cmVnaW1pcnNreUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SGkgVGlzc2Es IGF1dGhvcnMsIGV0LiBhbCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9t OjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SSd2 ZSByZWFkIGRvY3VtZW50cyBhbmQgd291bGQgbGlrZSB0byBjbGFyaWZ5IHNjb3BlIG9mIHRoZXNl IGRvY3VtZW50cy4gT0FNIGlzIG5vdCBsaW1pdGVkIHRvIHBpbmcgYW5kIHRyYWNlcm91dGUgZnVu Y3Rpb25zLiBJdCBldmVuIG5vdCBsaW1pdGVkIHRvIGNvbnRpbnVpdHkgY2hlY2suIEFuZCBpbiBj b25uZWN0aW9ubGVzcyBuZXR3b3Jrcw0KIHRoZXJlIHdvdWxkIG5vdCBiZSBjb25uZWN0aXZpdHkg dmVyaWZpY2F0aW9uLiBBbmQgdGhlIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50IGlzIHRoZSBiaWcg cGFydCBvZiBPQU0gYXMgd2VsbCBhcyBwcm90ZWN0aW9uIGNvb3JkaW5hdGlvbiwgZGVmZWN0IGFs YXJtcywgYW5kIGV0Yy4gSGVuY2UgbXkgcXVlc3Rpb24sIGlzIGl0IGluIHBsYW5zIG9mIHRoZSBh dXRob3JzIHRvIGFkZHJlc3MgYWxsIG9mIE9BTSBpbiByZXNwZWN0aXZlIGRvY3VtZW50cz88L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3Jv dW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+UmVnYXJkcyw8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndo aXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+R3JlZzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj4NCjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+T24gVHVlLCBKdW4gMTAsIDIwMTQgYXQgMTI6MDMgUE0sIFRpc3NhIFNl bmV2aXJhdGhuZSAodHNlbmV2aXIpICZsdDs8YSBocmVmPSJtYWlsdG86dHNlbmV2aXJAY2lzY28u Y29tIiB0YXJnZXQ9Il9ibGFuayI+dHNlbmV2aXJAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+QWxsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPldl IGhhdmUgcHVibGlzaGVkIFlBTkcgbW9kZWwgZm9yIE9BTS4gIzEgZHJhZnQgYmVsb3cgcGxhY2Ug dGhlIGdlbmVyaWMgZnJhbWV3b3JrIGZvciBPQU0sIHRoYXQgY2FuIGJlIGF1Z21lbnRlZCBmb3Ig ZGlmZmVyZW50IHRlY2hub2xvZ2llcy4gIzIgYW5kICMzIGFyZSBhcHBsaWNhdGlvbiBvZiB0aGUg Y29uY2VwdCB0byBOVk8zIGFuZCBUUklMTCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+MS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LXRpc3NhLW5ldG1vZC1vYW0vIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10aXNzYS1uZXRtb2Qtb2FtLzwvYT48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dy b3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjIuPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cDov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10aXNzYS1udm8zLXlhbmctb2FtLyIgdGFy Z2V0PSJfYmxhbmsiPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGlzc2Et bnZvMy15YW5nLW9hbS88L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj4zLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtdGlzc2EtdHJpbGwteWFuZy1vYW0vIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC10aXNzYS10cmlsbC15YW5nLW9hbS88L2E+PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tn cm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dy b3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlBsZWFzZSByZXZpZXcgYW5k IHNoYXJlIHlvdXIgY29tbWVudHM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+VGhhbmtzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj5UaXNzYTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpudm8zIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzpudm8zQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bnZvM0BpZXRmLm9yZzwvYT48YnI+DQo8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL252bzMiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL252bzM8L2E+ PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFj a2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdDti YWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_7DFA7869D33BD44A9A84BA24AD75BDE6D9E46A72RCHEXMBP1fncnet_-- From nobody Fri Aug 1 13:53:24 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAFA71ABC74; Fri, 1 Aug 2014 13:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 g7eXYO4DbZTr; Fri, 1 Aug 2014 13:08:24 -0700 (PDT) Received: from fncnmp03.fnc.fujitsu.com (fncnmp03.fnc.fujitsu.com [168.127.0.56]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5F201A0467; Fri, 1 Aug 2014 13:08:23 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.01,781,1400043600"; d="scan'208,217"; a="52769688" Received: from rchexhcp1.fnc.net.local ([168.127.134.75]) by fncnmp01.fnc.fujitsu.com with ESMTP/TLS/AES128-SHA; 01 Aug 2014 15:08:23 -0500 Received: from RCHEXMBP1.fnc.net.local ([169.254.2.63]) by RCHEXHCP1.fnc.net.local ([168.127.134.75]) with mapi id 14.03.0181.006; Fri, 1 Aug 2014 15:08:22 -0500 From: "O'Connor, Don" To: "Tissa Senevirathne (tsenevir)" , Tissa Senevirathne , Greg Mirsky Thread-Topic: [nvo3] YANG models for OAM Thread-Index: Ac+E3qlMyPi638vnRGmjYh75Wx+edAoWIbcAAAE6agAACU5iwAAR6gcAAAadH3A= Date: Fri, 1 Aug 2014 20:08:22 +0000 Message-ID: <7DFA7869D33BD44A9A84BA24AD75BDE6D9E46AA6@RCHEXMBP1.fnc.net.local> References: <1406847186.16320.YahooMailNeo@web162805.mail.bf1.yahoo.com> <7DFA7869D33BD44A9A84BA24AD75BDE6D9E4645D@RCHEXMBP1.fnc.net.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [168.127.136.253] x-tm-as-product-ver: SMEX-10.2.0.3176-7.500.1018-20854.002 x-tm-as-result: No--51.982500-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_7DFA7869D33BD44A9A84BA24AD75BDE6D9E46AA6RCHEXMBP1fncnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/Xdj539jH-kw_vE1YF0IixH4N3gs X-Mailman-Approved-At: Fri, 01 Aug 2014 13:53:20 -0700 Cc: "l2vpn@ietf.org" , "opsawg@ietf.org" , "nvo3@ietf.org" , "netmod@ietf.org" , "trill@ietf.org" Subject: Re: [OPSAWG] [nvo3] YANG models for OAM X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 20:08:27 -0000 --_000_7DFA7869D33BD44A9A84BA24AD75BDE6D9E46AA6RCHEXMBP1fncnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tissa The MEF standards apply to the Ethernet Service Layer of Carrier Ethernet S= ervices. Are the IDs in your email constrained to layers below the Ethernet= Service Layer for Carrier Ethernet Service? Or are they not applicable to = Carrier Ethernet Service? Regards Don From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Tissa Senevirathne= (tsenevir) Sent: Thursday, July 31, 2014 6:49 PM To: O'Connor, Don; Tissa Senevirathne; Greg Mirsky Cc: l2vpn@ietf.org; opsawg@ietf.org; nvo3@ietf.org; netmod@ietf.org; trill@= ietf.org Subject: RE: [nvo3] YANG models for OAM Don I am aware of that, but this is different, MEF YANG model is specifically f= or Ethernet and structure does not allow to bring different addressing sche= mes other than MAC address. Additionally the proposed standard allow to add= flow entropies and facilitate nested OAM between different technologies. Y= ou may have to read in to the details to see the actual differences. From: O'Connor, Don [mailto:don.oconnor@us.fujitsu.com] Sent: Thursday, July 31, 2014 4:32 PM To: Tissa Senevirathne; Greg Mirsky; Tissa Senevirathne (tsenevir) Cc: l2vpn@ietf.org; opsawg@ietf.org; nvo3@ietf.org; netmod@ietf.org; trill@ietf.org Subject: RE: [nvo3] YANG models for OAM Tissa, Greg, all Metro Ethernet Forum has already standardized Yang Modules for Ethernet Ser= vice OAM Performance Monitoring and Fault Management. Please see MEF 38 and= 39 http://metroethernetforum.org/carrier-ethernet/technical-specifications Regards Don From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Tissa Senevirathne Sent: Thursday, July 31, 2014 5:53 PM To: Greg Mirsky; Tissa Senevirathne (tsenevir) Cc: l2vpn@ietf.org; opsawg@ietf.org; nvo3@ietf.org; netmod@ietf.org; trill@ietf.org Subject: Re: [nvo3] YANG models for OAM Greg Yes it is, generic YANG model steup the base framework. It can be extended = to add tools as well as other elements as well technology deviations. Alarm= s etc either be part of this document will be a separate document that spec= ifies them. That is the reason we have designed the model as modular as pos= sible and extensible as possible. Please let us know if any of the parts are not extensible or not modular en= ough. Thanks Tissa On Thursday, July 31, 2014 3:17 PM, Greg Mirsky > wrote: Hi Tissa, authors, et. al, I've read documents and would like to clarify scope of these documents. OAM= is not limited to ping and traceroute functions. It even not limited to co= ntinuity check. And in connectionless networks there would not be connectiv= ity verification. And the performance measurement is the big part of OAM as= well as protection coordination, defect alarms, and etc. Hence my question= , is it in plans of the authors to address all of OAM in respective documen= ts? Regards, Greg On Tue, Jun 10, 2014 at 12:03 PM, Tissa Senevirathne (tsenevir) > wrote: All We have published YANG model for OAM. #1 draft below place the generic fram= ework for OAM, that can be augmented for different technologies. #2 and #3 = are application of the concept to NVO3 and TRILL, 1. http://datatracker.ietf.org/doc/draft-tissa-netmod-oam/ 2. http://datatracker.ietf.org/doc/draft-tissa-nvo3-yang-oam/ 3. http://datatracker.ietf.org/doc/draft-tissa-trill-yang-oam/ Please review and share your comments Thanks Tissa _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 --_000_7DFA7869D33BD44A9A84BA24AD75BDE6D9E46AA6RCHEXMBP1fncnet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tissa

 

The MEF standards apply to = the Ethernet Service Layer of Carrier Ethernet Services. Are the IDs in you= r email constrained to layers below the Ethernet Service Layer for Carrier Ethernet Service? Or are they not applicable to Carrier = Ethernet Service?

 

Regards

 

Don

 

From: L2vpn [m= ailto:l2vpn-bounces@ietf.org] On Behalf Of Tissa Senevirathne (tsenevir)
Sent: Thursday, July 31, 2014 6:49 PM
To: O'Connor, Don; Tissa Senevirathne; Greg Mirsky
Cc: l2vpn@ietf.org; opsawg@ietf.org; nvo3@ietf.org; netmod@ietf.org;= trill@ietf.org
Subject: RE: [nvo3] YANG models for OAM

 

Don


I am aware of that, but this is different, MEF YANG model is specifically f= or Ethernet and structure does not allow to bring different addressing sche= mes other than MAC address. Additionally the proposed standard allow to add= flow entropies and facilitate nested OAM between different technologies. You may have to read in to the details= to see the actual differences.

 <= /p>

From: O'Connor= , Don [mailto:don.oconnor@us.= fujitsu.com]
Sent: Thursday, July 31, 2014 4:32 PM
To: Tissa Senevirathne; Greg Mirsky; Tissa Senevirathne (tsenevir) Cc: l2vpn@ietf.org; opsawg@ietf.org; nvo3@ietf.org; netmod@ietf.org; trill@ietf.org Subject: RE: [nvo3] YANG models for OAM

 

Tissa, Greg, all=

 

Metro Ethernet Forum has al= ready standardized Yang Modules for Ethernet Service OAM Performance Monito= ring and Fault Management. Please see MEF 38 and 39

 

http://metroethern= etforum.org/carrier-ethernet/technical-specifications=

 

Regards

 

Don

 

From: L2vpn [<= a href=3D"mailto:l2vpn-bounces@ietf.org">mailto:l2vpn-bounces@ietf.org] On Behalf Of Tissa Senevirathne
Sent: Thursday, July 31, 2014 5:53 PM
To: Greg Mirsky; Tissa Senevirathne (tsenevir)
Cc: l2vpn@ietf.org; opsawg@ietf.org; nvo3@ietf.org; netmod@ietf.org; trill@ietf.org Subject: Re: [nvo3] YANG models for OAM

 

Greg=

 

Yes it is, generic YANG model steup the ba= se framework. It can be extended to add tools as well as other elements as = well technology deviations. Alarms etc either be part of this document will be a separate document that specifies them. That is the= reason we have designed the model as modular as possible and extensible as= possible.

 

Please let us know if any of the parts are= not extensible or not modular enough.

 

Thanks

Tissa

 

On= Thursday, July 31, 2014 3:17 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:<= /o:p>

 

Hi Tissa, autho= rs, et. al,

I've read documents and would like to clarify scope of these document= s. OAM is not limited to ping and traceroute functions. It even not limited to continuity check. And in connectionless networks there= would not be connectivity verification. And the performance measurement is= the big part of OAM as well as protection coordination, defect alarms, and= etc. Hence my question, is it in plans of the authors to address all of OAM in respective documents?

Regards,

Greg=

 

On Tue, Jun 10,= 2014 at 12:03 PM, Tissa Senevirathne (tsenevir) <tsenevir@cisco.com> wrote:

All<= /span>

 

We have publish= ed YANG model for OAM. #1 draft below place the generic framework for OAM, = that can be augmented for different technologies. #2 and #3 are application of the concept to NVO3 and TRILL,

 

 

Please review a= nd share your comments

 

Thanks

Tissa

 

 


_______________________________________________
nvo3 mailing list
nvo3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/nvo3

 

 

--_000_7DFA7869D33BD44A9A84BA24AD75BDE6D9E46AA6RCHEXMBP1fncnet_-- From nobody Wed Aug 6 13:49:03 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 154C01A01E2 for ; Wed, 6 Aug 2014 13:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 UL1EDCFs8hk8 for ; Wed, 6 Aug 2014 13:48:59 -0700 (PDT) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6AA01A01BD for ; Wed, 6 Aug 2014 13:48:58 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id y10so3904107pdj.21 for ; Wed, 06 Aug 2014 13:48:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:subject:content-type:content-transfer-encoding; bh=r4t3iRnDFhH8bJ0tPlAXctkGYi9fp+Sm02lh2rT9S9A=; b=mvRdMP55LDsPKM4H5InvJbT+B4U2dH5zGYetLvxA+bIFhQQOg5hrGQSwidXBmAPb46 S2jW568RTQyMEBCkA3gtuZRpukWjifCW4OasGt99G6+8q0zowtfQ/iXwmCEF4ebY/+kh erpD9ZKeRKm7cwJqLlcrxDiU3k8PDi82mBgkiyB7LR++Z2BMiTsPx6oJVyUcZtY4tDOf CZkKeeKBttDnZx85uSiQ4uRCVKcfsvCY9E6SttSsOJZpaS5u8GshuMdTpNsEIxIOKtv5 /L8T7cNoFUPbPGMcu27aOwcg28V7/A0X4BJsuj251yz8MuR6sC95GH9xENhqnhTFU4J9 ytXA== X-Received: by 10.70.88.237 with SMTP id bj13mr13420197pdb.57.1407358138594; Wed, 06 Aug 2014 13:48:58 -0700 (PDT) Received: from [192.168.178.23] (44.197.69.111.dynamic.snap.net.nz. [111.69.197.44]) by mx.google.com with ESMTPSA id bu2sm2208241pbc.19.2014.08.06.13.48.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Aug 2014 13:48:57 -0700 (PDT) Message-ID: <53E294BE.4040904@gmail.com> Date: Thu, 07 Aug 2014 08:49:02 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: opsawg@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/tl9TSpWsZMiGI5poHP3qJQBNw8Q Subject: [OPSAWG] [Fwd: [Anima] ANIMA draft charter] X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: anima@ietf.org List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 20:49:01 -0000 FYI. Discussion over on the Anima list please. Brian -------- Original Message -------- Subject: [Anima] ANIMA draft charter Date: Tue, 5 Aug 2014 08:19:15 +0000 From: Michael Behringer (mbehring) To: anima@ietf.org At the BoF in Toronto there was rough consensus to continue the work on an autonomic infrastructure. Brian, Sheng, Toerless, Laurent and I have now drafted a potential WG charter with the input of our ADs. Note that this is not yet a formal charter proposal, it's for discussion only so far. The assumption is that more general aspects of autonomics will continue to be discussed in the NMRG group. If we were to go ahead with a WG, the goal would be to focus on realistic deliverables. So the plan is to start with a small, achievable set of deliverables, and, if successful and useful, expand after re-chartering. Please comment here on this draft charter proposal. Thanks, Michael Autonomic Networking Integrated Model and Approach (ANIMA) WG Description of Working Group Autonomic Networking focuses on self-management of network elements. An autonomic function works in a distributed way across various network elements, allowing however central guidance and reporting. Autonomic functions already exist today, for example IGP routing protocols such as OSPF. However, all such functions have their own discovery, transport, messaging and security mechanisms. To transform the somewhat abstract Autonomic Networking concept into concrete, realisable requirements, the first stage, undertaken in the Network Management Research Group (NMRG) of the IRTF, was to define terminology and design goals, and to derive a high-level gap analysis. The definitions and design goals, as well as a simple architecture model are defined in draft-irtf-nmrg-autonomic-network-definitions; the gap analysis for AN is described in draft-irtf-nmrg-an-gap-analysis. The UCAN BoF at IETF 90 discussed use cases and some existing solutions. All the above work serves as a baseline for this working group. This working group defines solutions for an initial set of components of an autonomic networking infrastructure, based on the simple architecture and design goals defined in draft-irtf-nmrg-autonomic-network-definitions. Future work may include a more detailed systems architecture to support the development of autonomic service agents. The Anima working group will initially focus on enterprise, ISP networks and IoT. The solutions target to cover the following areas: o identity of nodes o common security model o discovery model o negotiation model o a secure and logically separated communications channel o an example for an autonomic management model The goals of this working group are: o Definition of a generic discovery and negotiation protocol for autonomic functions Starting point: draft-jiang-config-negotiation-protocol o Definition of a mechanism to bootstrap a trust infrastructure Starting point: draft-pritikin-bootstrapping-keyinfrastructures o Definition of an logically separated Autonomic Control Plane Starting point: draft-behringer-autonomic-control-plane In addition, autonomic service agents will need to be defined for specific use cases. The working group will initially consider one simple example as a test case for further work. o Definition of Starting point: draft-use-case-tbd The initial set of work items is limited to the above list to stay focused and avoid "boiling the ocean". Additional documents concerning policy intent, other autonomic infrastructure components, use cases or autonomic service agents are strongly encouraged, as individual submissions, but are not planned as working group deliverables for now. No additional work items will be accepted in the working group without re-chartering. Milestones Nov 2014 - WG formation and adoption of drafts - Mar IETF - Jun 2015 - WGLC for draft-generic-discovery-negotiation-protocol - Jul IETF - Aug 2015 - submit draft-generic-discovery-negotiation-protocol to IESG (standards track) Oct 2015 - WGLC draft-keyinfrastructure-bootstrap Oct 2015 - WGLC draft-use-case-tbd - Nov IETF - Dec 2015 - submit draft-keyinfrastructure-bootstrap to IESG (standards track) Dec 2015 - submit draft-use-case-tbd to IESG (standards track) Jan 2016 - WGLC draft-autonomic-common-control-plane - Mar IETF - Apr 2016 - submit draft-autonomic-common-control-plane to IESG (standards track) Jul 2016 - recharter if needed, or close -- _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima From nobody Thu Aug 7 04:11:20 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40CDB1B2A75 for ; Thu, 7 Aug 2014 04:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 27mR6T3BVw3A for ; Thu, 7 Aug 2014 04:11:13 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lrp0019.outbound.protection.outlook.com [213.199.154.19]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84C871B2A6D for ; Thu, 7 Aug 2014 04:11:12 -0700 (PDT) Received: from pc6 (109.147.210.26) by DB3PR07MB059.eurprd07.prod.outlook.com (10.242.137.149) with Microsoft SMTP Server (TLS) id 15.0.995.14; Thu, 7 Aug 2014 11:11:10 +0000 Message-ID: <005601cfb22f$b1cad1e0$4001a8c0@gateway.2wire.net> From: t.petch To: Date: Thu, 7 Aug 2014 10:51:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [109.147.210.26] X-ClientProxiedBy: DB4PR02CA0050.eurprd02.prod.outlook.com (10.242.174.178) To DB3PR07MB059.eurprd07.prod.outlook.com (10.242.137.149) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 029651C7A1 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(13464003)(377454003)(189002)(377424004)(199002)(51704005)(66066001)(50466002)(80022001)(50226001)(61296003)(81342001)(44736004)(23756003)(19580395003)(79102001)(64706001)(107046002)(44716002)(42186005)(4396001)(20776003)(84392001)(83322001)(21056001)(2351001)(62236002)(76482001)(77982001)(15975445006)(110136001)(107886001)(46102001)(81542001)(19580405001)(33646002)(77096002)(14496001)(81686999)(77156001)(95666004)(104166001)(101416001)(86362001)(99396002)(87976001)(81816999)(62966002)(47776003)(105586002)(102836001)(93916002)(85852003)(15202345003)(83072002)(31966008)(74502001)(89996001)(74662001)(85306004)(92726001)(87286001)(50986999)(92566001)(106356001)(88136002)(74416001)(7726001); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR07MB059; H:pc6; FPR:; MLV:nov; PTR:InfoNoRecords; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/nueFfoDTGsBnlBmdVzFvW9WDijc Subject: [OPSAWG] Fw: I-D Action: draft-hartman-snmp-sha2-02.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 11:11:18 -0000 I am not sure where this should be discussed but I note that it creates a new SnmpAuthProtocols but it contains no request to IANA to register a name and is Experimental whereas the update procedure for the registry is Standards Track. And if this seems familiar, it may be because I made similar comments about http://tools.ietf.org/html/draft-hmac-sha-2-usm-snmp-00 back in March this year Tom Petch ----- Original Message ----- From: To: Sent: Thursday, July 31, 2014 7:41 AM > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Authenticating version 3 of the Simple Network Management Protocol (SNMPv3) using HMAC-SHA-2 procedures > Authors : Sam Hartman > Margaret Wasserman > Dacheng Zhang > Manav Bhatia > Danping He > Filename : draft-hartman-snmp-sha2-02.txt > Pages : 10 > Date : 2014-07-30 > > Abstract: > This document describes the mechanism to authenticate SNMPv3 protocol > packets using Hashed Message Authentication Mode (HMAC) with the SHA- > 256, SHA-384, and SHA-512 algorithms. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-hartman-snmp-sha2/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-hartman-snmp-sha2-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-hartman-snmp-sha2-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Fri Aug 8 11:19:39 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F01A1A002C for ; Fri, 8 Aug 2014 11:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 e1C459Epu76y for ; Fri, 8 Aug 2014 11:11:34 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0F6B1A002A for ; Fri, 8 Aug 2014 11:10:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9914; q=dns/txt; s=iport; t=1407521446; x=1408731046; h=from:to:cc:subject:date:message-id:mime-version; bh=ivcK9iXcg6SaeiTBwkiAvYz2YQpRcGzke0e/0MYPor4=; b=LQcpBfLvBTdj5CL3r1MfkjyXUauKQfu4Vjylm9WsJhwBv0aUU4iUUjIF 5sQpJfnMc7fIZ7iBfk/iRp3wSHrRafKm0wfJNxac+APtLQ2eF/ogqYSEq qUYwnS4m+xiAlN/kk1XdxKTZZtTet6F3CZ2W4sHk+rCDTsHYwqJMLl/4z Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsFAJoR5VOtJA2N/2dsb2JhbABagkdGUlcEywmBWQEJhnVTAYEVFneEAwEBAQQBAQFrCxIBGQMBAiguCxQJCgQOBQmIOQ3FWheOewEBPg0EBgeCMlOBQAWGDYh2ghOEJYZugVaTIoNXbAGBDTk X-IronPort-AV: E=Sophos;i="5.01,826,1400025600"; d="scan'208,217";a="346096363" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-2.cisco.com with ESMTP; 08 Aug 2014 18:10:46 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s78IAjuP020558 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Aug 2014 18:10:45 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.176]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Fri, 8 Aug 2014 13:10:45 -0500 From: "Raghuram Sudhaakar (rsudhaak)" To: "opsawg@ietf.org" Thread-Topic: [OPSAWG] Coman Drafts v02 Thread-Index: AQHPszQS4Abi5UfSxEGyzCCjcnfBlQ== Date: Fri, 8 Aug 2014 18:10:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.21.126.38] Content-Type: multipart/alternative; boundary="_000_D00A60758C6Brsudhaakciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/Qd7OBvTWHDT9fLpNDsQz-LTJNBI X-Mailman-Approved-At: Fri, 08 Aug 2014 11:19:33 -0700 Cc: "Pascal Thubert \(pthubert\)" , "P.Zand@utwente.nl" Subject: [OPSAWG] Coman Drafts v02 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 18:11:38 -0000 --_000_D00A60758C6Brsudhaakciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear ML users, I read both the documents your mentioned below. Both are well written and a= ddress their scope quite well. Only a few minor typos here and there. On a general note, both these documents do not address the actual managemen= t protocol. It seems to me that these documents will typically be reference= d by some other drafts (like our draft-ietf-6tisch-coap) that specify the p= rotocol. -raghuram From: Thomas Watteyne > Date: Tuesday, August 5, 2014 at 11:15 PM To: raghuram sudhaakar > Subject: Fwd: [6lo] Fwd: [OPSAWG] Coman Drafts v02 Raghuram, These drafts, which introduce the use cases and problem statement for const= rained management, are very related to the CoAP draft you co-authored. I be= lieve it would be very useful if you could review them and submit your revi= ew to the OPSAWG ML, as detailed below. Would that be possible? Thomas ---------- Forwarded message ---------- From: Thomas Watteyne > Date: Sat, Jul 26, 2014 at 10:32 PM Subject: Fwd: [6lo] Fwd: [OPSAWG] Coman Drafts v02 To: "6tisch@ietf.org" <6tisch@ietf.org> All, The OPSWAG chairs have kindly agreed to extend the WGLC period for the foll= owing drafts [1] to August 11: http://tools.ietf.org/html/draft-ietf-opsawg-coman-use-cases-02 http://tools.ietf.org/html/draft-ietf-opsawg-coman-probstate-reqs-01 Pascal and myself believe those two drafts to be important for the ongoing = work on managing a 6TiSCH network, and directly in line with e.g. draft-iet= f-6tisch-coap. We therefore ask authors of draft-ietf-6tisch-coap, draft-ie= tf-6tisch-6top-interface, and any other 6TiSCH WG member to send reviews of= this document to OPSAWG ML [2]. Thomas [1] http://www.ietf.org/mail-archive/web/6tisch/current/msg02465.html [2] https://www.ietf.org/mailman/listinfo/opsawg ---------- Forwarded message ---------- From: Warren Kumari > Date: Fri, Jul 25, 2014 at 3:03 PM Subject: Re: [coman] FW: [OPSAWG] Coman Drafts v02 To: "Ersue, Mehmet (NSN - DE/Munich)" > Cc: "coman@ietf.org" >, "opsawg-chairs@tools.ietf.org" > Hi all. With apologies to the authors... The chairs of 6LoWPAN and 6TSCH have asked if we can delay the end of this WGLC so that their communities can review and comment on these 2 documents. As we have not received very much feedback, this seems relevant to their WGs, and they asked nicely, we have decided to extend the deadline to August 11th. Now, many folk will be traveling back to their homes over the next few days - this probably means a few, or many hours on an airplane. May I suggest copying these documents on your computer or reading device of choice and reviewing the documents on the way home? Thanks, W _______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo --_000_D00A60758C6Brsudhaakciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Dear ML users,
I read both the documents your mentioned below. Both are well written = and address their scope quite well. 
Only a few minor typos here and there.

On a general note, both these documents do not address the actual mana= gement protocol. It seems to me that these documents will typically be refe= renced by some other drafts (like our draft-ietf-6tisch-coap) that spe= cify the protocol. 


-raghuram

From: Thomas Watteyne <watteyne@eecs.berkeley.edu> Date: Tuesday, August 5, 2014 at 11= :15 PM
To: raghuram sudhaakar <rsudhaak@cisco.com>
Subject: Fwd: [6lo] Fwd: [OPSAWG] C= oman Drafts v02

Raghuram,
These drafts, which introduce the use cases and problem statement for = constrained management, are very related to the CoAP draft you co-authored.= I believe it would be very useful if you could review them and submit your= review to the OPSAWG ML, as detailed below. Would that be possible?
Thomas

---------- Forwarded message ----------
From: Thomas Watteyne &= lt;watteyne@eecs.berkeley.edu= >
Date: Sat, Jul 26, 2014 at 10:32 PM
Subject: Fwd: [6lo] Fwd: [OPSAWG] Coman Drafts v02
To: "6tisch@ietf.org" <= 6tisch@ietf.org>


All,

The OPSWAG chairs have kindly agreed to extend the WGLC period for the= following drafts [1] to August 11:


Pascal and myself believe those two drafts to be important for the ong= oing work on managing a 6TiSCH network, and directly in line with e.g. = ;draft-ietf-6tisch-coap. We therefore ask authors of draft-ietf-6tisch= -coap, draft-ietf-6tisch-6top-interface, and any other 6TiSCH WG member to send reviews of this document to OPSAWG ML [= 2].

Thomas

[2] https://www.ietf.org/mailman/listinfo/opsawg


---------- Forwarded message ----------
From: Warren Kumari <warren@kumari.net>
Date: Fri, Jul 25, 2014 at 3:03 PM
Subject: Re: [coman] FW: [OPSAWG] Coman Drafts v02
To: "Ersue, Mehmet (NSN - DE/Munich)" <mehmet.ersue@nsn.com>
Cc: "coman@ietf.or= g" <coman@i= etf.org>, "opsawg-chairs@tools.ietf.org"
<opsaw= g-chairs@tools.ietf.org>


Hi all.

With apologies to the authors...

The chairs of 6LoWPAN and 6TSCH have asked if we can delay the end of
this WGLC so that their communities can review and comment on these 2
documents.

As we have not received very much feedback, this seems relevant to
their WGs, and they asked nicely, we have decided to extend the
deadline to August 11th.

Now, many folk will be traveling back to their homes over the next few
days - this probably means a few, or many hours on an airplane. May I
suggest copying these documents on your computer or reading device of
choice and reviewing the documents on the way home?

Thanks,
W

_______________________________________________
6lo mailing list
6lo@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/6lo


--_000_D00A60758C6Brsudhaakciscocom_-- From nobody Fri Aug 8 17:58:11 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1F81A02E8 for ; Fri, 8 Aug 2014 17:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 8IGbgPGbRfsZ for ; Fri, 8 Aug 2014 17:58:08 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E38A01A02E3 for ; Fri, 8 Aug 2014 17:58:07 -0700 (PDT) Received: by mail-ig0-f179.google.com with SMTP id h18so1864443igc.6 for ; Fri, 08 Aug 2014 17:58:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=/GaPP2xl7slK1Qeqbkj0vjnCocAwgKF5TDLiOmrtNyE=; b=Fqcl4i4Wjqhd16blJGvn8TqBgauXoefjUFwE0MpEv5X+c23URQjtrXs17/57UC0g8i xsq6YM7ABYcRkrZXklZ4CGvJg38LAO+ekxHJhN2Vv87jeldb4XbX1ZFyHu+rLIQzyZFo y3gwk+N4kiuEWtFTkmgiH5HdpLIL7qPAFxxDqHjPCSRGmMTwG7pM8w8IJmjrfigdKO7F Q18W144dB0IK4H1Kx+etRBC7zNpQjrhI/xQRiu/9TNA/yCqae63/ml5j1RSd3Zo+GT8m K7CdE0hgOXQhUCEaPIUfMfmxGUoSL9wGYBQm2ZbRZH6W9j4csUlF+cBY1izJGu0+O9Lr 83rw== X-Received: by 10.50.4.9 with SMTP id g9mr9836714igg.42.1407545887286; Fri, 08 Aug 2014 17:58:07 -0700 (PDT) Received: from [192.168.97.219] ([67.210.160.130]) by mx.google.com with ESMTPSA id i3sm15461067igu.14.2014.08.08.17.58.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Aug 2014 17:58:07 -0700 (PDT) Message-ID: <53E5721F.3030701@gmail.com> Date: Fri, 08 Aug 2014 20:58:07 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, opsawg@ietf.org References: <063301cfa832$aaa8e3e0$fffaaba0$@olddog.co.uk> In-Reply-To: <063301cfa832$aaa8e3e0$fffaaba0$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/dt8lOfFWIbbuh9rZnUMmsFHmCk0 Cc: draft-farrkingel-pce-abno-architecture@tools.ietf.org, 'Quintin zhao' Subject: Re: [OPSAWG] Call for review draft-farrkingel-pce-abno-architecture X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 00:58:10 -0000 The document looks reasonable, but I have no idea how much it fits with current product plans. I can see potential for SFC to be an application of the system. OpenV6/SUPA could be a part of it. There are editorials and nits, but I figured it was a bit early to call those out. Tom Taylor On 25/07/2014 2:02 PM, Adrian Farrel wrote: > Hi, > > The authors of draft-farrkingel-pce-abno-architecture are in the process of > requesting AD-sponsored publication of draft-farrkingel-pce-abno-architecture > > This I-D is a bit of an architecture and a bit an applicability statement. It is > also significantly about how to build and operate networks. > > The last call will obviously pop out sometime, but it would be nice to have > review comments before then. > > Thanks, > Adrian > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From nobody Fri Aug 8 23:30:23 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78ED31A0319 for ; Fri, 8 Aug 2014 23:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.433 X-Spam-Level: * X-Spam-Status: No, score=1.433 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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, T_FILL_THIS_FORM_SHORT=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 R1gVPlE2kTDR for ; Fri, 8 Aug 2014 23:30:05 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 410C91A02DA for ; Fri, 8 Aug 2014 23:30:05 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id lf10so8404767pab.15 for ; Fri, 08 Aug 2014 23:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=roa99K4iKU885OH4JRKKyModC8lReMchV3hwU5xoNfc=; b=lt1zaAXjAyjJ9GCF3Ecd5n1O9Clma+Fy9gkkjwFD1ycKtfOByLnNvsabIzeR4PXTxI QWZA8ka+5b8GPzLOf8LfIhNrdAeeBLXvN/wZ9BypOxLASnYrgzCzmdsyqkBXYXP9qKoK emJtqPIkM4ZYZZq/Boii01Y+r+mEq0/haKH3LZDAHe1s0DglZgsiEVSXdV+aNbqanjxM 7NGrBKYSdb0Wp0oPuVkqO9CAIySgbi60Z9zG3qZWEHs0vb1HCNSp2m4UKE3V2L0zwf/d 6ts+/LmIHxMkME3WsfELZCXW5QjjMotm58X9a78xIfllmj9S5EbrNDuVKc7oNW2Pyc/X MxNQ== X-Received: by 10.69.18.234 with SMTP id gp10mr28547755pbd.11.1407565804843; Fri, 08 Aug 2014 23:30:04 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.144.1 with HTTP; Fri, 8 Aug 2014 23:29:44 -0700 (PDT) From: Thomas Watteyne Date: Fri, 8 Aug 2014 23:29:44 -0700 X-Google-Sender-Auth: _E9VHE3-UyNXGsBwaTHSFMJ5n9s Message-ID: To: opsawg@ietf.org Content-Type: multipart/alternative; boundary=001a11364faccbbad205002c7345 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/wZNQaM0sdxp442sP5jb9UK0jWiU Subject: [OPSAWG] Thomas's review of draft-ietf-opsawg-coman-use-cases-02 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 06:30:22 -0000 --001a11364faccbbad205002c7345 Content-Type: text/plain; charset=UTF-8 I was asked to do a detailed review of draft-ietf-opsawg-coman-use-cases-02. Constrained management is important for the 6TiSCH WG. I am really happy to see that the COMAN work has been able to progress in OPSAWG. I wasn't aware of the progress on this document in OPS until IETF90 (my fault...); but have since announced it to the 6TiSCH WG. The 6TiSCH architecture supports a mode in which a central entity manages the communication schedule of the nodes. Typically, the node form a constrained network (very little bandwidth, energy constraints, etc), and the (possible less constrained) management entity sits on the edge of that network. This management entity need to (1) set a number of parameters on the motes and (2) monitor some statistics to possibly trigger some action. Nothing particularly surprising, indeed. So far, we have been defined our own "home brew" management protocol on top of CoAP (draft-ietf-6tisch-coap-01). There is really nothing specific to 6TiSCH in that solution, and we'd love to be able to reuse any more generic management solution for constrained environments. Ideally, this management solution would be shared by other software pieces running on the constrained device, e.g. the 6LoWPAN layer. I am also reading draft-ietf-opsawg-coman-probstate-reqs-02, the review of which I will send in a separate e-mail to keep things clean. Thomas GENERAL -------------- The different sections are very "independent", and the draft would benefit from some text at the beginning which would glue those together. Ideas are: - enforce the same structure for each use case section, possibly by grouping the paragraphs under a title, e.g. "description of the use case", "expectation from management solution", etc. - add a table/list at the beginning which summarizes the different features one can expect from a management system, for each of the use cases (e.g. "privacy" in Medical Applications). This would give the reader a one-page overview, allowing him/her to more easily go back to the text. In some use cases, while the use case is very clearly described, it's hard to see what the use case is *for the management*. This is particularly true in "Building Automation", and somewhat in "Industrial Applications". It might be interesting, for each use case, to describe how the management changes over the lifetime of the system. For example, some security aspect (authentication, authorization) only exist during commissioning. It would be good, although maybe hard, to have common metrics across all uses cases, allowing for an easier comparison. For example, the approx. amount of management data, generation rate of this management data (and associated size). It would be good to order the use cases logically, and highlight in the intro text what the extremes are. For example (and I'm making this up), management in the Field Operations use cases involves the most frequent exchange of data, and hence a large overhead, than a Home Automation application in which most management is done during commissioning. DETAILED --------------- please find my comments below, prefixed by "^TW>" Internet Engineering Task Force M. Ersue, Ed. Internet-Draft Nokia Networks Intended status: Informational D. Romascanu Expires: January 5, 2015 Avaya J. Schoenwaelder A. Sehgal Jacobs University Bremen July 4, 2014 Management of Networks with Constrained Devices: Use Cases draft-ietf-opsawg-coman-use-cases-02 Abstract This document discusses use cases concerning the management of networks, where constrained devices are involved. A problem statement, deployment options and the requirements on the networks with constrained devices can be found in the companion document on "Management of Networks with Constrained Devices: Problem Statement and Requirements". Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 5, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Ersue, et al. Expires January 5, 2015 [Page 1] Internet-Draft Constrained Management: Use Cases July 2014 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Access Technologies . . . . . . . . . . . . . . . . . . . . . 4 2.1. Constrained Access Technologies . . . . . . . . . . . . . 4 2.2. Cellular Access Technologies . . . . . . . . . . . . . . 4 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Environmental Monitoring . . . . . . . . . . . . . . . . 6 3.2. Infrastructure Monitoring . . . . . . . . . . . . . . . . 6 3.3. Industrial Applications . . . . . . . . . . . . . . . . . 7 3.4. Energy Management . . . . . . . . . . . . . . . . . . . . 9 3.5. Medical Applications . . . . . . . . . . . . . . . . . . 11 3.6. Building Automation . . . . . . . . . . . . . . . . . . . 12 3.7. Home Automation . . . . . . . . . . . . . . . . . . . . . 13 3.8. Transport Applications . . . . . . . . . . . . . . . . . 14 3.9. Community Network Applications . . . . . . . . . . . . . 16 3.10. Field Operations . . . . . . . . . . . . . . . . . . . . 18 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 8. Informative References . . . . . . . . . . . . . . . . . . . 20 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 21 A.1. draft-ietf-opsawg-coman-use-cases-01 - draft-ietf-opsawg- coman-use-cases-02 . . . . . . . . . . . . . . . . . . . 21 A.2. draft-ietf-opsawg-coman-use-cases-00 - draft-ietf-opsawg- coman-use-cases-01 . . . . . . . . . . . . . . . . . . . 22 A.3. draft-ersue-constrained-mgmt-03 - draft-ersue-opsawg- coman-use-cases-00 . . . . . . . . . . . . . . . . . . . 23 A.4. draft-ersue-constrained-mgmt-02-03 . . . . . . . . . . . 23 A.5. draft-ersue-constrained-mgmt-01-02 . . . . . . . . . . . 24 A.6. draft-ersue-constrained-mgmt-00-01 . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction Small devices with limited CPU, memory, and power resources, so called constrained devices (aka. sensor, smart object, or smart device) can be connected to a network. Such a network of constrained devices itself may be constrained or challenged, e.g., with unreliable or lossy channels, wireless technologies with limited bandwidth and a dynamic topology, needing the service of a gateway or Ersue, et al. Expires January 5, 2015 [Page 2] Internet-Draft Constrained Management: Use Cases July 2014 proxy to connect to the Internet. In other scenarios, the constrained devices can be connected to a non-constrained network using off-the-shelf protocol stacks. Constrained devices might be in charge of gathering information in diverse settings including natural ecosystems, buildings, and factories and send the information to one or more server stations. Network management is characterized by monitoring network status, detecting faults, and inferring their causes, setting network parameters, and carrying out actions to remove faults, maintain normal operation, and improve network efficiency and application performance. The traditional network management application periodically collects information from a set of elements that are needed to manage, processes the data, and presents them to the network management users. Constrained devices, however, often have limited power, low transmission range, and might be unreliable TW> I don't understand what you mean by "be unreliable". Do you mean that the TW> device itself is unreliable (what exactly does that mean?), or that the TW> communication with that device is unreliable? TW> I would add that such networks most often have low capacity. TW> I would add that such networks most often have high latency. They might also need to work in hostile environments with advanced security requirements or need to be used in harsh environments for a long time without supervision. Due to such constraints, the management of a network with constrained devices offers different type of challenges compared to the management of a traditional IP network. This document aims to understand use cases for the management of a network, where constrained devices are involved. The document lists and discusses diverse use cases for the management from the network as well as from the application point of view. The list of discussed use cases is not an exhaustive one since other scenarios, currently unknown to the authors, are possible. TW> Typo below, remove "are". are The application scenarios discussed aim to show where networks of constrained devices are expected to be deployed. For each application scenario, we first briefly describe the characteristics followed by a discussion on how network management can be provided, who is likely going to be responsible for it, and on which time-scale management operations are likely to be carried out. A problem statement, deployment and management topology options as well as the requirements on the networks with constrained devices can be found in the companion document [COM-REQ]. This documents builds on the terminology defined in [RFC7228] and [COM-REQ]. [RFC7228] is a base document for the terminology concerning constrained devices and constrained networks. Some use cases specific to IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) can be found in [RFC6568]. Ersue, et al. Expires January 5, 2015 [Page 3] Internet-Draft Constrained Management: Use Cases July 2014 2. Access Technologies Besides the management requirements imposed by the different use cases, the access technologies used by constrained devices can impose restrictions and requirements upon the Network Management System (NMS) and protocol of choice. It is possible that some networks of constrained devices might utilize traditional non-constrained access technologies for network access, e.g., local area networks with plenty of capacity. In such scenarios, the constrainedness of the device presents special management restrictions and requirements rather than the access technology utilized. However, in other situations constrained or cellular access technologies might be used for network access, thereby causing management restrictions and requirements to arise as a result of the underlying access technologies. 2.1. Constrained Access Technologies Due to resource restrictions, embedded devices deployed as sensors and actuators in the various use cases utilize low-power low data- rate wireless access technologies such as IEEE 802.15.4, DECT ULE or BT-LE for network connectivity. In such scenarios, it is important for the NMS to be aware of the restrictions imposed by these access technologies to efficiently manage these constrained devices. Specifically, such low-power low data-rate access technologies typically have small frame sizes. So it would be important for the NMS and management protocol of choice to craft packets in a way that avoids fragmentation and reassembly of packets since this can use valuable memory on constrained devices. Devices using such access technologies might operate via a gateway that translates between these access technologies and more traditional Internet protocols. A hierarchical approach to device management in such a situation might be useful, wherein the gateway device is in-charge of devices connected to it, while the NMS conducts management operations only to the gateway. 2.2. Cellular Access Technologies Machine to machine (M2M) services are increasingly provided by mobile service providers as numerous devices, home appliances, utility meters, cars, video surveillance cameras, and health monitors, are connected with mobile broadband technologies. Different applications, e.g., in a home appliance or in-car network, use Ersue, et al. Expires January 5, 2015 [Page 4] Internet-Draft Constrained Management: Use Cases July 2014 TW> typo, Zigbee -> ZigBee (throughout doc) Bluetooth, Wi-Fi or Zigbee locally and connect to a cellular module acting as a gateway between the constrained environment and the mobile cellular network. Such a gateway might provide different options for the connectivity of mobile networks and constrained devices: TW> BT-LE --> Bluetooth Low-Energy (BT-LE) o a smart phone with 3G/4G and WLAN radio might use BT-LE to connect to the devices in a home area network, o a femtocell might be combined with home gateway functionality acting as a low-power cellular base station connecting smart devices to the application server of a mobile service provider, o an embedded cellular module with LTE radio connecting the devices in the car network with the server running the telematics service, o an M2M gateway connected to the mobile operator network supporting diverse IoT connectivity technologies including ZigBee and CoAP over 6LoWPAN over IEEE 802.15.4. Common to all scenarios above is that they are embedded in a service and connected to a network provided by a mobile service provider. Usually there is a hierarchical deployment and management topology in place where different parts of the network are managed by different management entities and the count of devices to manage is high (e.g. many thousands). In general, the network is comprised by manifold type and size of devices matching to different device classes. As such, the managing entity needs to be prepared to manage devices with diverse capabilities using different communication or management protocols. In case the devices are directly connected to a gateway they most likely are managed by a management entity integrated with the gateway, which itself is part of the Network Management System (NMS) run by the mobile operator. Smart phones or embedded modules connected to a gateway might be themselves in charge to manage the devices on their level. The initial and subsequent configuration of such a device is mainly based on self-configuration and is triggered by the device itself. The gateway might be in charge of filtering and aggregating the data received from the device as the information sent by the device might be mostly redundant. 3. Use Cases Ersue, et al. Expires January 5, 2015 [Page 5] Internet-Draft Constrained Management: Use Cases July 2014 3.1. Environmental Monitoring Environmental monitoring applications are characterized by the deployment of a number of sensors to monitor emissions, water quality, or even the movements and habits of wildlife. Other applications in this category include earthquake or tsunami early- warning systems. The sensors often span a large geographic area, they can be mobile, and they are often difficult to replace. Furthermore, the sensors are usually not protected against tampering. Management of environmental monitoring applications is largely concerned with the monitoring whether the system is still functional and the roll-out of new constrained devices in case the system looses too much of its structure. The constrained devices themselves need to be able to establish connectivity (auto-configuration) and they need to be able to deal with events such as loosing neighbors or being moved to other locations. Management responsibility typically rests with the organization running the environmental monitoring application. Since these monitoring applications must be designed to tolerate a number of failures, the time scale for detecting and recording failures is for some of these applications likely measured in hours and repairs might easily take days. In fact, in some scenarios it might be more cost- and time-effective to not repair such devices at all. However, for certain environmental monitoring applications, much tighter time scales may exist and might be enforced by regulations (e.g., monitoring of nuclear radiation). 3.2. Infrastructure Monitoring Infrastructure monitoring is concerned with the monitoring of infrastructures such as bridges, railway tracks, or (offshore) windmills. The primary goal is usually to detect any events or changes of the structural conditions that can impact the risk and safety of the infrastructure being monitored. Another secondary goal is to schedule repair and maintenance activities in a cost effective manner. The infrastructure to monitor might be in a factory or spread over a wider area but difficult to access. As such, the network in use might be based on a combination of fixed and wireless technologies, which use robust networking equipment and support reliable communication via application layer transactions. It is likely that constrained devices in such a network are mainly C2 >TW please define "C2", and provide RFC devices and have to be controlled centrally by an application running on a server. In case such a distributed network is widely spread, the wireless devices might use diverse long-distance wireless technologies such as Ersue, et al. Expires January 5, 2015 [Page 6] Internet-Draft Constrained Management: Use Cases July 2014 TW> I don't fully understand what you mean by "e.g. based on embedded hardware TW> modules", in partcular the "e.g." part. Maybe write the idea out in a TW> separate sentence? WiMAX, or 3G/LTE, e.g. based on embedded hardware modules. In cases, where an in-building network is involved, the network can be based on Ethernet or wireless technologies suitable for in-building usage. The management of infrastructure monitoring applications is primarily concerned with the monitoring of the functioning of the system. Infrastructure monitoring devices are typically rolled out and installed by dedicated experts and changes are rare since the infrastructure itself changes rarely. However, monitoring devices are often deployed in unsupervised environments and hence special attention must be given to protecting the devices from being modified. Management responsibility typically rests with the organization owning the infrastructure or responsible for its operation. The time scale for detecting and recording failures is likely measured in hours and repairs might easily take days. However, certain events (e.g., natural disasters) may require that status information be obtained much more quickly and that replacements of failed sensors can be rolled out quickly (or redundant sensors are activated quickly). In case the devices are difficult to access, a self- healing feature on the device might become necessary. 3.3. Industrial Applications Industrial Applications and smart manufacturing refer to tasks such as networked control and monitoring of manufacturing equipment, asset and situation management, or manufacturing process control. For the management of a factory it is becoming essential to implement smart capabilities. From an engineering standpoint, industrial applications are intelligent systems enabling rapid manufacturing of new products, dynamic response to product demands, and real-time optimization of manufacturing production and supply chain networks. Potential industrial applications (e.g., for smart factories and smart manufacturing) are: o Digital control systems with embedded, automated process controls, operator tools, as well as service information systems optimizing plant operations and safety. o Asset management using predictive maintenance tools, statistical evaluation, and measurements maximizing plant reliability. o Smart sensors detecting anomalies to avoid abnormal or catastrophic events. Ersue, et al. Expires January 5, 2015 [Page 7] Internet-Draft Constrained Management: Use Cases July 2014 o Smart systems integrated within the industrial energy management system and externally with the smart grid enabling real-time energy optimization. TW> I don't understand what the "management" part here refers to in this TW> section. I expect the draft to deal exclusively with the management needs TW> for the constrained network (e.g. monitoring 6LoWPAN counters). This TW> section seems to deal with the management of a smart plant. Management of Industrial Applications and smart manufacturing may in some situations involve Building Automation tasks such as control of energy, HVAC (heating, ventilation, and air conditioning), lighting, or access control. Interacting with management systems from other application areas might be important in some cases (e.g., environmental monitoring for electric energy production, energy management for dynamically scaling manufacturing, vehicular networks for mobile asset tracking). Sensor networks are an essential technology used for smart manufacturing. Measurements, automated controls, plant optimization, health and safety management, and other functions are provided by a large number of networked sectors. Data interoperability and seamless exchange of product, process, and project data are enabled through interoperable data systems used by collaborating divisions or business systems. Intelligent automation and learning systems are vital to smart manufacturing but must be effectively integrated with the decision environment. Wireless sensor networks (WSN) have been developed for machinery Condition-based Maintenance (CBM) as they offer significant cost savings and enable new functionalities. Inaccessible locations, rotating machinery, hazardous areas, and mobile assets can be reached with wireless sensors. WSNs can provide today wireless link reliability, real-time capabilities, and quality- of-service and enable industrial and related wireless sense and control applications. Management of industrial and factory applications is largely focused on the monitoring whether the system is still functional, real-time continuous performance monitoring, and optimization as necessary. The factory network might be part of a campus network or connected to the Internet. The constrained devices in such a network need to be able to establish configuration themselves (auto-configuration) and might need to deal with error conditions as much as possible locally. Access control has to be provided with multi-level administrative access and security. Support and diagnostics can be provided through remote monitoring access centralized outside of the factory. Management responsibility is typically owned by the organization running the industrial application. Since the monitoring applications must handle a potentially large number of failures, the time scale for detecting and recording failures is for some of these applications likely measured in minutes. However, for certain industrial applications, much tighter time scales may exist, e.g. in Ersue, et al. Expires January 5, 2015 [Page 8] Internet-Draft Constrained Management: Use Cases July 2014 real-time, which might be enforced by the manufacturing process or the use of critical material. 3.4. Energy Management The EMAN working group developed an energy management framework [I-D.ietf-eman-framework] for devices and device components within or connected to communication networks. This document observes that one of the challenges of energy management is that a power distribution network is responsible for the supply of energy to various devices and components, while a separate communication network is typically used to monitor and control the power distribution network. Devices in the context of energy management can be monitored for parameters like Power, Energy, Demand and Power Quality. If a device contains batteries, they can be also monitored and managed. Energy devices differ in complexity and may include basic sensors or switches, specialized electrical meters, or power distribution units (PDU), and subsystems inside the network devices (routers, network switches) or home or industrial appliances. The operators of an Energy Management System are either the utility providers or customers that aim to control and reduce the energy consumption and the associated costs. The topology in use differs and the deployment can cover areas from small surfaces (individual homes) to large geographical areas. The EMAN requirements document [RFC6988] discusses the requirements for energy management concerning monitoring and control functions. It is assumed that Energy Management will apply to a large range of devices of all classes and networks topologies. Specific resource monitoring like battery utilization and availability may be specific to devices with lower physical resources (device classes C0 or C1). Energy Management is especially relevant to the Smart Grid. A Smart Grid is an electrical grid that uses data networks to gather and to act on energy and power-related information in an automated fashion with the goal to improve the efficiency, reliability, economics, and sustainability of the production and distribution of electricity. Smart Metering is a good example of Smart Grid based Energy Management applications. Different types of possibly wireless small meters produce all together a large amount of data, which is collected by a central entity and processed by an application server, which may be located within the customer's residence or off-site in a data-center. The communication infrastructure can be provided by a mobile network operator as the meters in urban areas will have most likely a cellular or WiMAX radio. In case the application server is Ersue, et al. Expires January 5, 2015 [Page 9] Internet-Draft Constrained Management: Use Cases July 2014 located within the residence, such meters are more likely to use WiFi protocols to interconnect with an existing network. An Advanced Metering Infrastructure (AMI) network is another example of the Smart Grid that enables an electric utility to retrieve frequent electric usage data from each electric meter installed at a customer's home or business. Unlike Smart Metering, in which case the customer or their agents install appliance level meters, an AMI infrastructure is typically managed by the utility providers and could also include other distribution automation devices like transformers and reclosers. Meters in AMI networks typically contain constrained devices that connect to mesh networks with a low- bandwidth radio. Usage data and outage notifications can be sent by these meters to the utility's headend systems, via aggregation points of higher-end router devices that bridge the constrained network to a less constrained network via cellular, WiMAX, or Ethernet. Unlike meters, these higher-end devices might be installed on utility poles owned and operated by a separate entity. It thereby becomes important for a management application to not only be able to work with diverse types of devices, but also over multiple links that might be operated and managed by separate entities, each having divergent policies for their own devices and network segments. During management operations, like firmware updates, it is important that the management system performs robustly in order to avoid accidental outages of critical power systems that could be part of AMI networks. In fact, since AMI networks must also report on outages, the management system might have to manage the energy properties of battery operated AMI devices themselves as well. A management system for home based Smart Metering solutions is likely to have few devices laid out in a simple topology. TW> how many are few? what's a simple topology? While (I think) I have a good TW> of what that might be, proposing a range might help with scope However, AMI networks installations could have thousands of nodes per router, i.e., higher-end device, which organize themselves in an ad-hoc manner. As such, a management system for AMI networks will need to discover and operate over complex topologies as well. In some situations, it is possible that the management system might also have to setup and manage the topology of nodes, especially critical routers. Encryption key management and sharing in both types of network TW> typo network*s* is also likely to be important for providing confidentiality for all data traffic. In AMI networks the key may be obtained by a meter only after an end-to-end authentication process based on certificates. Smart Metering solution could adopt a similar approach or the security may be implied due to the encrypted WiFi networks they become part of. TW> Please use either Wi-Fi or WiFi. There must be an official one? The management of such a network requires end-to-end management of and information exchange through different types of networks. Ersue, et al. Expires January 5, 2015 [Page 10] Internet-Draft Constrained Management: Use Cases July 2014 However, as of today there is no integrated energy management approach and no common information model available. Specific energy management applications or network islands use their own management mechanisms. 3.5. Medical Applications Constrained devices can be seen as an enabling technology for advanced and possibly remote health monitoring and emergency notification systems, ranging from blood pressure and heart rate monitors to advanced devices capable to monitor TW> rephrase to "capable of monitoring"? implanted technologies, such as pacemakers or advanced hearing aids. Medical sensors may not only be attached to human bodies, they might also exist in the infrastructure used by humans such as bathrooms or kitchens. Medical applications will also be used to ensure treatments are being applied properly and they might guide people losing orientation. Fitness and wellness applications, such as connected scales or wearable heart monitors, encourage consumers to exercise and empower self-monitoring of key fitness indicators. Different applications use Bluetooth, Wi-Fi or Zigbee connections to access the patient's smartphone or home cellular connection to access the Internet. Constrained devices that are part of medical applications are managed either by the users of those devices or by an organization providing medical (monitoring) services for physicians. In the first case, management must be automatic and or TW> "and/or"? easy to install and setup by average people. In the second case, it can be expected that devices be controlled by specially trained people. In both cases, however, it is crucial to protect the privacy of the people to which medical devices are attached. Even though the data collected by a heart beat monitor might be protected, the pure fact that someone carries such a device may need protection. As such, certain medical appliances may not want to participate in discovery and self-configuration protocols in order to remain invisible. Many medical devices are likely to be used (and relied upon) to provide data to physicians in critical situations since the biggest market is likely elderly and handicapped people. Timely delivery of data can be quite important in certain applications like patient mobility monitoring in oldage homes. Data must reach the physician and/or emergency services within specified limits of time in order to be useful. As such, fault detection of the communication network or the constrained devices becomes a crucial function of the management system that must be carried out with high reliability and, depending on the medical appliance and its application, within seconds. Ersue, et al. Expires January 5, 2015 [Page 11] Internet-Draft Constrained Management: Use Cases July 2014 3.6. Building Automation Building automation comprises the distributed systems designed and deployed to monitor and control the mechanical, electrical and electronic systems inside buildings with various destinations (e.g., public and private, industrial, institutions, or residential). Advanced Building Automation Systems (BAS) may be deployed concentrating the various functions of safety, environmental control, occupancy, security. More and more the deployment of the various functional systems is connected to the same communication infrastructure (possibly Internet Protocol based), which may involve wired or wireless communications networks inside the building. Building automation requires the deployment of a large number (10-100.000) of sensors that monitor the status of devices, and parameters inside the building and controllers with different specialized functionality for areas within the building or the totality of the building. Inter-node distances between neighboring nodes vary between 1 to 20 meters. Contrary to home automation, in building management the devices are expected to be managed assets and known to a set of commissioning tools and a data storage, such that every connected device has a known origin. The management includes verifying the presence of the expected devices and detecting the presence of unwanted devices. Examples of functions performed by such controllers are regulating the quality, humidity, and temperature of the air inside the building and lighting. Other systems may report the status of the machinery inside the building like elevators, or inside the rooms like projectors in meeting rooms. Security cameras and sensors may be deployed and operated on separate dedicated infrastructures connected to the common backbone. The deployment area of a BAS is typically inside one building (or part of it) or several buildings geographically grouped in a campus. A building network can be composed of network segments, where a network segment covers a floor, an area on the floor, or a given functionality (e.g., security cameras). Some of the sensors in Building Automation Systems (for example fire alarms or security systems) register, record and transfer critical alarm information and therefore must be resilient to events like loss of power or security attacks. This leads to the need to certify components and subsystems operating in such constrained conditions based on specific requirements. Also in some environments, the malfunctioning of a control system (like temperature control) needs to be reported in the shortest possible time. Complex control systems can misbehave, and their critical status reporting and safety Ersue, et al. Expires January 5, 2015 [Page 12] Internet-Draft Constrained Management: Use Cases July 2014 algorithms need to be basic and robust and perform even in critical conditions. Building Automation solutions are deployed in some cases in newly designed buildings, in other cases it might be over existing infrastructures. In the first case, there is a broader range of possible solutions, which can be planned for the infrastructure of the building. In the second case the solution needs to be deployed over an existing infrastructure taking into account factors like existing wiring, distance limitations, the propagation of radio signals over walls and floors, thereby making deployment difficult. As a result, some of the existing WLAN solutions (e.g., IEEE 802.11 or IEEE 802.15) may be deployed. In mission-critical or security sensitive environments and in cases where link failures happen often, topologies that allow for reconfiguration of the network and connection continuity may be required. Some of the sensors deployed in building automation may be very simple constrained devices for which class 0 or class 1 may be assumed. TW> you use "C1" and "C0" above. Please homogenize. For lighting applications, groups of lights must be defined and managed. Commands to a group of light must arrive within 200 ms at all destinations. The installation and operation of a building network has different requirements. During the installation, many stand-alone networks of a few to 100 nodes co-exist without a connection to the backbone. During this phase, the nodes are identified with a network identifier related to their physical location. Devices are accessed from an installation tool to connect them to the network in a secure fashion. During installation, the setting of parameters of common values to enable interoperability may be required. During operation, the networks are connected to the backbone while maintaining the network identifier to physical location relation. Network parameters like address and name are stored in DNS. The names can assist in determining the physical location of the device. 3.7. Home Automation Home automation includes the control of lighting, heating, ventilation, air conditioning, appliances, entertainment and home TW> The word "security" appears twice security devices to improve convenience, comfort, energy efficiency, and security. It can be seen as a residential extension of building automation. However, unlike a building automation system, the infrastructure in a home is operated in a considerably more ad-hoc manner. While in some installations it is likely that there is no centralized management system, akin to a Building Automation System (BAS), available, in other situations outsourced and cloud based systems responsible for managing devices in the home might be used. Ersue, et al. Expires January 5, 2015 [Page 13] Internet-Draft Constrained Management: Use Cases July 2014 Home automation networks need a certain amount of configuration TW> actors -> actuators ? (associating switches or sensors to actors) that is either provided by electricians deploying home automation solutions, by third party home automation service providers (e.g., small specialized companies or home automation device manufacturers) or by residents by using the application user interface provided by home automation devices to configure (parts of) the home automation solution. Similarly, failures may be reported via suitable interfaces to residents or they might be recorded and made available to services providers in charge of the maintenance of the home automation infrastructure. The management responsibility lies either with the residents or it may be outsourced to electricians and/or third parties providing management of home automation solutions as a service. A varying combination of electricians, service providers or the residents may be responsible for different aspects of managing the infrastructure. The time scale for failure detection and resolution is in many cases likely counted in hours to days. 3.8. Transport Applications Transport Application is a generic term for the integrated application of communications, control, and information processing in a transportation system. Transport telematics or vehicle telematics are used as a term for the group of technologies that support transportation systems. Transport applications running on such a transportation system cover all modes of the transport and consider all elements of the transportation system, i.e. the vehicle, the infrastructure, and the driver or user, interacting together dynamically. Examples for transport applications are inter and intra vehicular communication, smart traffic control, smart parking, electronic toll collection systems, logistic and fleet management, vehicle control, and safety and road assistance. As a distributed system, transport applications require an end-to-end management of different types of networks. It is likely that constrained devices in a network (e.g. a moving in-car network) have to be controlled by an application running on an application server in the network of a service provider. Such a highly distributed network including cellular devices on vehicles is assumed to include a wireless access network using diverse long distance wireless technologies such as WiMAX, 3G/LTE or satellite communication, e.g. based on an embedded hardware module. As a result, the management of constrained devices in the transport system might be necessary to plan top-down and might need to use data models obliged from and defined on the application layer. The assumed device classes in use are mainly C2 devices. In cases, where an in-vehicle network is involved, C1 devices with limited capabilities and a short-distance Ersue, et al. Expires January 5, 2015 [Page 14] Internet-Draft Constrained Management: Use Cases July 2014 constrained radio network, e.g. IEEE 802.15.4 might be used additionally. All Transport Applications will require an IT infrastructure to run on top of, e.g., in public transport scenarios like trains, bus or metro network infrastructure might be provided, maintained and operated by third parties like mobile network or satellite network operators. However, the management responsibility of the transport application typically rests within the organization running the transport application (in the public transport scenario, this would typically be the public transport operator). Different aspects of the infrastructure might also be managed by different entities. For example, the in-car devices are likely to be installed and managed by the manufacturer, while the public works might be responsible for the on-road vehicular communication infrastructure used by these devices. The back-end infrastructure is also likely to be maintained by third party operators. As such, the NMS must be able to deal with different network segments, each being operated and controlled by separate entities, and enable appropriate access control and security as well. Depending on the type of application domain (vehicular or stationary) and service being provided, it would be important for the NMS to be able to function with different architectures, since different manufacturers might have their own proprietary systems relying on a specific Management Topology Option, as described in [COM-REQ]. Moreover, constituents of the network can be either private, belonging to individuals or private companies, or owned by public institutions leading to different legal and organization requirements. Across the entire infrastructure, a variety of constrained devices are likely to be used, and must be individually managed. The NMS must be able to either work directly with different types of devices, or have the ability to interoperate with multiple different systems. The challenges in the management of vehicles in a mobile transport application are manifold. The up-to-date position of each node in the network should be reported to the corresponding management entities, since the nodes could be moving within or roaming between different networks. Secondly, a variety of troubleshooting information, including sensitive location information, needs to be reported to the management system in order to provide accurate service to the customer. Management systems dealing with mobile nodes could possibly exploit specific patterns in the mobility of the nodes. These patterns emerge due to repetitive vehicular usage in scenarios like people commuting to work, logistics supply vehicles transporting shipments between warehouses and etc. The NMS must also be able to handle partitioned networks, which would arise due to the Ersue, et al. Expires January 5, 2015 [Page 15] Internet-Draft Constrained Management: Use Cases July 2014 dynamic nature of traffic resulting in large inter-vehicle gaps in sparsely populated scenarios. Since mobile nodes might roam in remote networks, the NMS should be able to provide operating configuration updates regardless of node location. The constrained devices in a moving transport network might be initially configured in a factory and a reconfiguration might be needed only rarely. New devices might be integrated in an ad-hoc manner based on self-management and -configuration capabilities. Monitoring and data exchange might be necessary to do via a gateway entity connected to the back-end transport infrastructure. The devices and entities in the transport infrastructure need to be monitored more frequently and can be able to communicate with a higher data rate. The connectivity of such entities does not necessarily need to be wireless. The time scale for detecting and recording failures in a moving transport network is likely measured in hours and repairs might easily take days. It is likely that a self-healing feature would be used locally. On the other hand, failures in fixed transport application infrastructure (e.g., traffic-lights, digital signage displays) is likely to be measured in minutes so as to avoid untoward traffic incidents. As such, the NMS must be able to deal with differing timeliness requirements based on the type of devices. 3.9. Community Network Applications Community networks are comprised of constrained routers in a multi- hop mesh topology, communicating over a lossy, and often wireless TW> typo: channel*s* channel. While the routers are mostly non-mobile, the topology may be very dynamic because of fluctuations in link quality of the (wireless) channel caused by, e.g., obstacles, or other nearby radio transmissions. Depending on the routers that are used in the community network, the resources of the routers (memory, CPU) may be more or less constrained - available resources may range from only a few kilobytes of RAM to several megabytes or more, and CPUs may be small and embedded, or more powerful general-purpose processors. Examples of such community networks are the FunkFeuer network (Vienna, Austria), FreiFunk (Berlin, Germany), Seattle Wireless (Seattle, USA), and AWMN (Athens, Greece). These community networks are public and non-regulated, allowing their users to connect to each other and - through an uplink to an ISP - to the Internet. No fee, other than the initial purchase of a wireless router, is charged for these services. Applications of these community networks can be diverse, e.g., location based services, free Internet access, file sharing between users, distributed chat services, social networking etc, video sharing etc. TW> One "etc" too many above. Ersue, et al. Expires January 5, 2015 [Page 16] Internet-Draft Constrained Management: Use Cases July 2014 As an example of a community network, the FunkFeuer network comprises several hundred routers, many of which have several radio interfaces (with omnidirectional and some directed antennas). The routers of the network are small-sized wireless routers, such as the Linksys WRT54GL, available in 2011 for less than 50 Euros. These routers, with 16 MB of RAM and 264 MHz of CPU power, are mounted on the rooftops of the users. When new users want to connect to the network, they acquire a wireless router, install the appropriate firmware and routing protocol, and mount the router on the rooftop. IP addresses for the router are assigned manually from a list of addresses (because of the lack of autoconfiguration standards for TW> autoconfiguration -> auto-configuration? mesh networks in the IETF). While the routers are non-mobile, fluctuations in link quality require an ad hoc routing protocol that allows for quick convergence to reflect the effective topology of the network (such as NHDP [RFC6130] and OLSRv2 [RFC7181] developed in the MANET WG). Usually, no human interaction is required for these protocols, as all variable parameters required by the routing protocol are either negotiated in the control traffic exchange, or are only of local importance to each router (i.e. do not influence interoperability). However, external management and monitoring of an ad hoc routing protocol may be desirable to optimize parameters of the routing protocol. Such an optimization may lead to a more stable perceived topology and to a lower control traffic overhead, and therefore to a higher delivery success ratio of data packets, a lower end-to-end delay, and less unnecessary bandwidth and energy usage. Different use cases for the management of community networks are possible: o One single Network Management Station, e.g. a border gateway providing connectivity to the Internet, requires managing or monitoring routers in the community network, in order to investigate problems (monitoring) or to improve performance by changing parameters (managing). As the topology of the network is dynamic, constant connectivity of each router towards the management station cannot be guaranteed. Current network TW> Netconf -> NETCONF (see RFC4741) management protocols, such as SNMP and Netconf, may be used (e.g., using interfaces such as the NHDP-MIB [RFC6779]). However, when routers in the community network are constrained, existing protocols may require too many resources in terms of memory and CPU; and more importantly, the bandwidth requirements may exceed the available channel capacity in wireless mesh networks. Moreover, management and monitoring may be unfeasible if the connection between the network management station and the routers is frequently interrupted. Ersue, et al. Expires January 5, 2015 [Page 17] Internet-Draft Constrained Management: Use Cases July 2014 TW> I would remove "A" o A distributed network monitoring, in which more than one management station monitors or manages other routers. Because connectivity to a server cannot be guaranteed at all times, a distributed approach may provide a higher reliability, at the cost of increased complexity. Currently, no IETF standard exists for distributed monitoring and management. o Monitoring and management of a whole network or a group of routers. Monitoring the performance of a community network may require more information than what can be acquired from a single router using a network management protocol. Statistics, such as topology changes over time, data throughput along certain routing paths, congestion etc., are of interest for a group of routers (or TW> update to 2014? the routing domain) as a whole. As of 2012, no IETF standard allows for monitoring or managing whole networks, instead of single routers. 3.10. Field Operations The challenges of configuration and monitoring of networks operated in the field by rescue and security agencies can be different from the other use cases since the requirements and operating conditions of such networks are quite different. TW> typo: becomeing -> becoming With technology advancements, field networks operated nowadays are becomeing large and can consist of varieties of different types of equipment that run different protocols and tools that obviously TW> "mission-critical"? increase complexity of these mission critical networks. In many scenarios, configurations are, most likely, manually performed. Furthermore, some legacy and even modern devices do not even support TW> "*A* majority"? TW> proprietary*,* which IP networking. Majority of protocols and tools developed by vendors that are being used are proprietary which makes integration more difficult. The main reason for this disjoint operation scenario is that most equipment is developed with specific task requirements in mind, rather than interoperability of the varied equipment types. For example, the operating conditions experienced by high altitude security equipment is significantly different from that used in desert conditions. Similarly, search and rescue operations equipment used in case of fire rescue has different requirements than flood TW> "inter-operation"? relief equipment. Furthermore, interoperation of equipment with telecommunication equipment was not an expected outcome or in some scenarios this may not even be desirable. Currently, field networks operate with a fixed Network Operations Center (NOC) that physically manages the configuration and evaluation of all field devices. Once configured, the devices might be deployed Ersue, et al. Expires January 5, 2015 [Page 18] Internet-Draft Constrained Management: Use Cases July 2014 in fixed or mobile scenarios. Any configuration changes required would need to be appropriately encrypted and authenticated to prevent unauthorized access. Hierarchical management of devices is a common requirement in such scenarios since local managers or operators may need to respond to changing conditions within their purview. The level of configuration management available at each hierarchy must also be closely governed. Since many field operation devices are used in hostile environments, a high failure and disconnection rate should be tolerated by the NMS, which must also be able to deal with multiple gateways and disjoint management protocols. TW> typo: invloving TW> requiring the interoperation -> requiring inter-operation? Multi-national field operations invloving search, rescue and security are becoming increasingly common, requiring the interoperation of a diverse set of equipment designed with different operating conditions in mind. Furthermore, different intra- and inter-governmental agencies are likely to have a different set of standards, best practices, rules and regulation, and implementation approaches that may contradict or conflict with each other. The NMS should be able to detect these and handle them in an acceptable manner, which may require human intervention. 4. IANA Considerations This document does not introduce any new code-points or namespaces for registration with IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 5. Security Considerations This document discusses use cases for Management of Networks with Constrained Devices. The security considerations described throughout the companion document [COM-REQ] apply here as well. 6. Contributors Following persons made significant contributions to and reviewed this document: o Ulrich Herberg (Fujitsu Laboratories of America) contributed the Section 3.9 on Community Network Applications. o Peter van der Stok contributed to Section 3.6 on Building Automation. Ersue, et al. Expires January 5, 2015 [Page 19] Internet-Draft Constrained Management: Use Cases July 2014 o Zhen Cao contributed to Section 2.2 Cellular Access Technologies. o Gilman Tolle contributed the Section 3.4 on Automated Metering Infrastructure. o James Nguyen and Ulrich Herberg contributed to Section 3.10 on Military operations. 7. Acknowledgments Following persons reviewed and provided valuable comments to different versions of this document: Dominique Barthel, Carsten Bormann, Zhen Cao, Benoit Claise, Bert Greevenbosch, Ulrich Herberg, James Nguyen, Zach Shelby, and Peter van der Stok. The editors would like to thank the reviewers and the participants on the Coman maillist for their valuable contributions and comments. 8. Informative References [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 6130, April 2011. [RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and Application Spaces for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6568, April 2012. [RFC6779] Herberg, U., Cole, R., and I. Chakeres, "Definition of Managed Objects for the Neighborhood Discovery Protocol", RFC 6779, October 2012. [RFC6988] Quittek, J., Chandramouli, M., Winter, R., Dietz, T., and B. Claise, "Requirements for Energy Management", RFC 6988, September 2013. [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, "The Optimized Link State Routing Protocol Version 2", RFC 7181, April 2014. [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, May 2014. Ersue, et al. Expires January 5, 2015 [Page 20] Internet-Draft Constrained Management: Use Cases July 2014 [I-D.ietf-eman-framework] Claise, B., Schoening, B., and J. Quittek, "Energy Management Framework", draft-ietf-eman-framework-19 (work in progress), April 2014. [COM-REQ] Ersue, M., Romascanu, D., and J. Schoenwaelder, "Management of Networks with Constrained Devices: Problem Statement and Requirements", draft-ietf-opsawg-coman- probstate-reqs (work in progress), February 2014. Appendix A. Change Log A.1. draft-ietf-opsawg-coman-use-cases-01 - draft-ietf-opsawg-coman- use-cases-02 o Renamed Mobile Access Technologies section to Cellular Access Technologies o Changed references to mobile access technologies to now read cellular access technologies. o Added text to the introduction to point out that the list of use cases is not exhaustive since others unknown to the authors might exist. o Updated references to take into account RFCs that have been now published. o Updated Environmental Monitoring section to make it clear that in some scenarios it may not be prudent to repair devices. o Added clarification in Infrastructure Monitoring section that reliable communication is achieved via application layer transactions o Removed reference to Energy Devices from Energy Management section, instead labeling them as devices within the context of energy management. o Reduced descriptive content in Energy Management section. o Rewrote text in Energy Management section to highlight management characteristics of Smart Meter and AMI networks. o Added text regarding timely delivery of information, and related management system characteristic, to the Medical Applications section Ersue, et al. Expires January 5, 2015 [Page 21] Internet-Draft Constrained Management: Use Cases July 2014 o Changed subnets to network segment in Building Automation section. o Changed structure to infrastructure in Building Automation section, and added text to highlight associated deployment difficulties. o Removed Trickle timer as example of common values to be set in Building Automation section. o Added text regarding the possible availability of outsourced and cloud based management systems for Home Automation. o Added text to Transport Applications section to highlight the requirement of IT infrastructure for such applications to function on top of. o Merged the Transport Applications and Vehicular Networks section together. Following changes to the Vehicular Networks section were merged back into Transport Applications * Replaced wireless last hops with wireless access to vehicles in Vehicular Networks. * Expanded proprietary systems to "systems relying on a specific Management Topology Option, as described in [COM-REQ]." within Vehicular Networks section. * Added text regarding mobility patterns to Vehicular Networks. o Changed the Military Operations use case to Field Operations and edited the text to be suitable to such scenarios. A.2. draft-ietf-opsawg-coman-use-cases-00 - draft-ietf-opsawg-coman- use-cases-01 o Reordered some use cases to improve the flow. o Added "Vehicular Networks". o Shortened the Military Operations use case. o Started adding substance to the security considerations section. Ersue, et al. Expires January 5, 2015 [Page 22] Internet-Draft Constrained Management: Use Cases July 2014 A.3. draft-ersue-constrained-mgmt-03 - draft-ersue-opsawg-coman-use- cases-00 o Reduced the terminology section for terminology addressed in the LWIG and Coman Requirements drafts. Referenced the other drafts. o Checked and aligned all terminology against the LWIG terminology draft. o Spent some effort to resolve the intersection between the Industrial Application, Home Automation and Building Automation use cases. o Moved section section 3. Use Cases from the companion document [COM-REQ] to this draft. o Reformulation of some text parts for more clarity. A.4. draft-ersue-constrained-mgmt-02-03 o Extended the terminology section and removed some of the terminology addressed in the new LWIG terminology draft. Referenced the LWIG terminology draft. o Moved Section 1.3. on Constrained Device Classes to the new LWIG terminology draft. o Class of networks considering the different type of radio and communication technologies in use and dimensions extended. o Extended the Problem Statement in Section 2. following the requirements listed in Section 4. o Following requirements, which belong together and can be realized with similar or same kind of solutions, have been merged. * Distributed Management and Peer Configuration, * Device status monitoring and Neighbor-monitoring, * Passive Monitoring and Reactive Monitoring, * Event-driven self-management - Self-healing and Periodic self- management, * Authentication of management systems and Authentication of managed devices, Ersue, et al. Expires January 5, 2015 [Page 23] Internet-Draft Constrained Management: Use Cases July 2014 * Access control on devices and Access control on management systems, * Management of Energy Resources and Data models for energy management, * Software distribution (group-based firmware update) and Group- based provisioning. o Deleted the empty section on the gaps in network management standards, as it will be written in a separate draft. o Added links to mentioned external pages. o Added text on OMA M2M Device Classification in appendix. A.5. draft-ersue-constrained-mgmt-01-02 o Extended the terminology section. o Added additional text for the use cases concerning deployment type, network topology in use, network size, network capabilities, radio technology, etc. o Added examples for device classes in a use case. o Added additional text provided by Cao Zhen (China Mobile) for Mobile Applications and by Peter van der Stok for Building Automation. o Added the new use cases 'Advanced Metering Infrastructure' and 'MANET Concept of Operations in Military'. o Added the section 'Managing the Constrainedness of a Device or Network' discussing the needs of very constrained devices. o Added a note that the requirements in [COM-REQ] need to be seen as standalone requirements and the current document does not recommend any profile of requirements. o Added a section in [COM-REQ] for the detailed requirements on constrained management matched to management tasks like fault, monitoring, configuration management, Security and Access Control, Energy Management, etc. o Solved nits and added references. o Added Appendix A on the related development in other bodies. Ersue, et al. Expires January 5, 2015 [Page 24] Internet-Draft Constrained Management: Use Cases July 2014 o Added Appendix B on the work in related research projects. A.6. draft-ersue-constrained-mgmt-00-01 o Splitted the section on 'Networks of Constrained Devices' into the sections 'Network Topology Options' and 'Management Topology Options'. o Added the use case 'Community Network Applications' and 'Mobile Applications'. o Provided a Contributors section. o Extended the section on 'Medical Applications'. o Solved nits and added references. Authors' Addresses Mehmet Ersue (editor) Nokia Networks Email: mehmet.ersue@nsn.com Dan Romascanu Avaya Email: dromasca@avaya.com Juergen Schoenwaelder Jacobs University Bremen Email: j.schoenwaelder@jacobs-university.de Anuj Sehgal Jacobs University Bremen Email: s.anuj@jacobs-university.de Ersue, et al. Expires January 5, 2015 [Page 25] --001a11364faccbbad205002c7345 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I was asked to do a detailed review of=C2=A0draft-iet= f-opsawg-coman-use-cases-02.

Constrained manag= ement is important for the 6TiSCH WG. I am really happy to see that the COM= AN work has been able to progress in OPSAWG. I wasn't aware of the prog= ress on this document in OPS until IETF90 (my fault...); but have since ann= ounced it to the 6TiSCH WG.

The 6TiSCH architecture supports a mode in which a cent= ral entity manages the communication schedule of the nodes. Typically, the = node form a constrained network (very little bandwidth, energy constraints,= etc), and the (possible less constrained) management entity sits on the ed= ge of that network. This management entity need to (1) set a number of para= meters on the motes and (2) monitor some statistics to possibly trigger som= e action. Nothing particularly surprising, indeed.

So far, we have been defined our own "home brew&qu= ot; management protocol on top of CoAP (draft-ietf-6tisch-coap-01). There i= s really nothing specific to 6TiSCH in that solution, and we'd love to = be able to reuse any more generic management solution for constrained envir= onments. Ideally, this management solution would be shared by other softwar= e pieces running on the constrained device, e.g. the 6LoWPAN layer.

I am also reading draft-ietf-opsawg-coman-probstate-req= s-02, the review of which I will send in a separate e-mail to keep things c= lean.

Thomas

GENERAL<= /div>
--------------

The different sections are ver= y "independent", and the draft would benefit from some text at th= e beginning which would glue those together. Ideas are:
- enforce= the same structure for each use case section, possibly by grouping the par= agraphs under a title, e.g. "description of the use case", "= expectation from management solution", etc.
- add a table/list at the beginning which summarizes the different fea= tures one can expect from a management system, for each of the use cases (e= .g. "privacy" in=C2=A0Medical Applications). This would give the = reader a one-page overview, allowing him/her to more easily go back to the = text.

In some use cases, while the use case is very clearly d= escribed, it's hard to see what the use case is *for the management*. T= his is particularly true in "Building Automation", and somewhat i= n "Industrial Applications".

It might be interesting, for each use case, to describe= how the management changes over the lifetime of the system. For example, s= ome security aspect (authentication, authorization) only exist during commi= ssioning.

It would be good, although maybe hard, to have common m= etrics across all uses cases, allowing for an easier comparison. For exampl= e, the approx. amount of management data, generation rate of this managemen= t data (and associated size).

It would be good to order the use cases logically, and = highlight in the intro text what the extremes are. For example (and I'm= making this up), management in the Field Operations use cases involves the= most frequent exchange of data, and hence a large overhead, than a=C2=A0Ho= me Automation application in which most management is done during commissio= ning.

DETAILED
---------------

=
please find my comments below, prefixed by "^TW>"


Internet Engineering Task Force =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0M. Ersue, Ed.
Internet-Draft =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0No= kia Networks
Intended status: Informational = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0D. Romascanu
Expires: January 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Avaya
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 J. Schoenwaelder
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0A. Sehgal
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jacobs Unive= rsity Bremen
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 July 4, 2014=


=C2=A0 =C2=A0 =C2=A0 =C2=A0Management of Networks with Constra= ined Devices: Use Cases
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-opsawg-coman-use-cases-02=

Abstract

=C2=A0 =C2=A0This document discusses use cases = concerning the management of
=C2=A0 =C2=A0networks, where constrained devices are involved. =C2= =A0A problem
=C2=A0 =C2=A0statement, deployme= nt options and the requirements on the networks
=C2=A0 =C2=A0with constrained devices can be fo= und in the companion document on
=C2=A0 =C2=A0"Management of= Networks with Constrained Devices: Problem Statement
=C2=A0 =C2=A0and Requirements".

Status of This Memo=

=C2=A0 =C2=A0This Internet-Draft i= s submitted in full conformance with the
=C2=A0 =C2=A0provisions of BCP 7= 8 and BCP 79.

=C2=A0 =C2=A0Internet= -Drafts are working documents of the Internet Engineering
=C2=A0 =C2=A0Task Force (IETF). = =C2=A0Note that other groups may also distribute
=C2=A0 =C2=A0working documents as Internet-Dra= fts. =C2=A0The list of current Internet-

=C2=A0 =C2=A0Internet-Drafts are= draft documents valid for a maximum of six months
=C2=A0 =C2=A0and may be updated, replaced, o= r obsoleted by other documents at any
=C2=A0 =C2=A0time. =C2=A0It is i= nappropriate to use Internet-Drafts as reference
=C2=A0 =C2=A0material or to cite them other th= an as "work in progress."

=C2=A0 =C2=A0This Internet-Draft will expire on= January 5, 2015.
Copyright Notice

=C2=A0 =C2=A0Copyright (c) 2014 IETF Trust and the= persons identified as the
=C2=A0 =C2=A0document authors. = =C2=A0All rights reserved.

=C2=A0 = =C2=A0This document is subject to BCP 78 and the IETF Trust's Legal
=C2=A0 =C2=A0Provisions Relating= to IETF Documents
= =C2=A0 =C2=A0(http://trust= ee.ietf.org/license-info) in effect on the date of
=C2=A0 =C2=A0publication of this= document. =C2=A0Please review these documents



Ersue, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0[Page 1]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0Constrained Management:= Use Cases =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0July 2014


=C2=A0 =C2=A0carefully, as they describe your rights and restr= ictions with respect
=C2=A0 =C2=A0to this document. = =C2=A0Code Components extracted from this document must
=C2=A0 =C2=A0include Simplified BSD Lic= ense text as described in Section 4.e of
=C2=A0 =C2=A0the Trust Legal Pro= visions and are provided without warranty as
=C2=A0 =C2=A0described in the Simplified BSD Licen= se.

Table of Contents

=C2=A0 =C2=A01. =C2=A0Introduction =C2=A0. . . . . . . . . . . . . . = . . . . . . . . . . =C2=A0 2
=C2=A0 =C2=A02. =C2=A0Access Tec= hnologies . . . . . . . . . . . . . . . . . . . . . =C2=A0 4
=C2=A0 =C2=A0 =C2=A02.1. =C2=A0Con= strained Access Technologies . . . . . . . . . . . . . =C2=A0 4
=C2=A0 =C2=A0 =C2=A02.2. =C2=A0C= ellular Access Technologies =C2=A0. . . . . . . . . . . . . . =C2=A0 4
=C2=A0 =C2=A03. =C2=A0Us= e Cases . . . . . . . . . . . . . . . . . . . . . . . . . . =C2=A0 5=
=C2=A0 =C2=A0 =C2=A03.1. =C2=A0E= nvironmental Monitoring =C2=A0. . . . . . . . . . . . . . . . =C2=A0 6
=C2=A0 =C2=A0 =C2=A03.2.= =C2=A0Infrastructure Monitoring . . . . . . . . . . . . . . . . =C2=A0 6
=C2=A0 =C2=A0 =C2=A03.3. =C2=A0I= ndustrial Applications . . . . . . . . . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A0 =C2=A03.4. =C2= =A0Energy Management . . . . . . . . . . . . . . . . . . . . =C2=A0 9
=C2=A0 =C2=A0 =C2=A03.5. =C2=A0M= edical Applications =C2=A0. . . . . . . . . . . . . . . . . . =C2=A011
=C2=A0 =C2=A0 =C2=A03.6.= =C2=A0Building Automation . . . . . . . . . . . . . . . . . . . =C2=A012
=C2=A0 =C2=A0 =C2=A03.7. =C2=A0H= ome Automation . . . . . . . . . . . . . . . . . . . . . =C2=A013
=C2=A0 =C2=A0 =C2=A03.8. =C2= =A0Transport Applications =C2=A0. . . . . . . . . . . . . . . . . =C2=A014<= /font>
=C2=A0 =C2=A0 =C2=A03.9. =C2=A0C= ommunity Network Applications =C2=A0. . . . . . . . . . . . . =C2=A016
=C2=A0 =C2=A0 =C2=A03.10= . Field Operations =C2=A0. . . . . . . . . . . . . . . . . . . . =C2=A018
=C2=A0 =C2=A04. =C2=A0IANA Consi= derations . . . . . . . . . . . . . . . . . . . . . =C2=A019
=C2=A0 =C2=A05. =C2=A0Security Con= siderations . . . . . . . . . . . . . . . . . . . =C2=A019
=C2=A0 =C2=A06. =C2=A0Contributo= rs =C2=A0. . . . . . . . . . . . . . . . . . . . . . . . =C2=A019
=C2=A0 =C2=A07. =C2=A0Acknowl= edgments . . . . . . . . . . . . . . . . . . . . . . . =C2=A020
=C2=A0 =C2=A08. =C2=A0Informativ= e References =C2=A0. . . . . . . . . . . . . . . . . . . =C2=A020
=C2=A0 =C2=A0Appendix A. =C2= =A0Change Log . . . . . . . . . . . . . . . . . . . . . =C2=A021
=C2=A0 =C2=A0 =C2=A0A.1. =C2=A0d= raft-ietf-opsawg-coman-use-cases-01 - draft-ietf-opsawg-
<= font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0coman-use-cases-02 =C2=A0. . . . . . . . . . . . . . . . . . . =C2=A021<= /font>
=C2=A0 =C2=A0 =C2=A0A.2. =C2=A0d= raft-ietf-opsawg-coman-use-cases-00 - draft-ietf-opsawg-
<= font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0coman-use-cases-01 =C2=A0. . . . . . . . . . . . . . . . . . . =C2=A022<= /font>
=C2=A0 =C2=A0 =C2=A0A.3. =C2=A0d= raft-ersue-constrained-mgmt-03 - draft-ersue-opsawg-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0c= oman-use-cases-00 =C2=A0. . . . . . . . . . . . . . . . . . . =C2=A023
=C2=A0 =C2=A0 =C2=A0A.4. =C2=A0d= raft-ersue-constrained-mgmt-02-03 =C2=A0. . . . . . . . . . . =C2=A023
=C2=A0 =C2=A0 =C2=A0A.5.= =C2=A0draft-ersue-constrained-mgmt-01-02 =C2=A0. . . . . . . . . . . =C2= =A024
=C2=A0 =C2=A0 =C2=A0A.6. =C2=A0d= raft-ersue-constrained-mgmt-00-01 =C2=A0. . . . . . . . . . . =C2=A025
=C2=A0 =C2=A0Authors'= ; Addresses =C2=A0. . . . . . . . . . . . . . . . . . . . . . . =C2=A025

1. =C2=A0Introduction

=C2=A0 =C2=A0Small devices with limited CPU, memory, and pow= er resources, so
=C2=A0 =C2=A0called constrained = devices (aka. sensor, smart object, or smart
=C2=A0 =C2=A0device) can be connected to a network= . =C2=A0Such a network of constrained
=C2=A0 =C2=A0devices itself may = be constrained or challenged, e.g., with
=C2=A0 =C2=A0unreliable or lossy channels, wireless te= chnologies with limited
=C2=A0 =C2=A0bandwidth and a dyn= amic topology, needing the service of a gateway or



Ersue, et al. =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 2]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0Constraine= d Management: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0July 2014<= /div>


=C2=A0 =C2=A0proxy to connect to the Internet. =C2=A0In other = scenarios, the
=C2=A0 =C2=A0constrained devices= can be connected to a non-constrained network
=C2=A0 =C2=A0using off-the-shelf protocol stack= s. =C2=A0Constrained devices might be in
=C2=A0 =C2=A0charge of gathering= information in diverse settings including natural
=C2=A0 =C2=A0ecosystems, buildings, and fact= ories and send the information to one
=C2=A0 =C2=A0or more server stat= ions.

=C2=A0 =C2=A0Network manageme= nt is characterized by monitoring network status,
=C2=A0 =C2=A0detecting faults, a= nd inferring their causes, setting network
=C2=A0 =C2=A0parameters, and carrying out actions to= remove faults, maintain
=C2=A0 =C2=A0normal operation, a= nd improve network efficiency and application
=C2=A0 =C2=A0performance. =C2=A0The traditional= network management application
=C2=A0 =C2=A0periodically collec= ts information from a set of elements that are
=C2=A0 =C2=A0needed to manage, processes the da= ta, and presents them to the
=C2=A0 =C2=A0network management = users. =C2=A0Constrained devices, however, often have
=C2=A0 =C2=A0limited power, low transmiss= ion range, and might be unreliable
=C2=A0 =C2=A0
<= font face=3D"courier new, monospace">TW> I don't understand what you= mean by "be unreliable". Do you mean that the=C2=A0
=
TW> device itself is unreliab= le (what exactly does that mean?), or that the
TW> communication with that d= evice is unreliable?
TW> I would add that such networks most often have low capacity.=
TW> I would add that such net= works most often have high latency.
=C2=A0 =C2=A0
=C2=A0 =C2=A0They
=C2=A0 =C2=A0might also need to = work in hostile environments with advanced
=C2=A0 =C2=A0security requirements or need to be use= d in harsh environments for a
=C2=A0 =C2=A0long time without s= upervision. =C2=A0Due to such constraints, the
=C2=A0 =C2=A0management of a network with const= rained devices offers different
=C2=A0 =C2=A0type of challenges = compared to the management of a traditional IP
=C2=A0 =C2=A0network.

=C2=A0 =C2=A0This d= ocument aims to understand use cases for the management of a
=C2=A0 =C2=A0network, where constr= ained devices are involved. =C2=A0The document lists
=C2=A0 =C2=A0and discusses diver= se use cases for the management from the network
=C2=A0 =C2=A0as well as from the application p= oint of view. =C2=A0The list of discussed
=C2=A0 =C2=A0use cases is not an= exhaustive one since other scenarios, currently
=C2=A0 =C2=A0unknown to the authors, are possi= ble.

TW> Typo below, remove "are".

=C2=A0 =C2=A0are The application scenarios
=C2=A0 =C2=A0discussed aim to sh= ow where networks of constrained devices are
=C2=A0 =C2=A0expected to be deployed. =C2=A0For ea= ch application scenario, we first
=C2=A0 =C2=A0briefly describe th= e characteristics followed by a discussion on how
=C2=A0 =C2=A0network management can be provid= ed, who is likely going to be
=C2=A0 =C2=A0responsible for it,= and on which time-scale management operations are
=C2=A0 =C2=A0likely to be carried out.

=C2=A0 =C2=A0A prob= lem statement, deployment and management topology options as
=C2=A0 =C2=A0well as the requireme= nts on the networks with constrained devices can
=C2=A0 =C2=A0be found in the com= panion document [COM-REQ].

=C2=A0 = =C2=A0This documents builds on the terminology defined in [RFC7228] and
=C2=A0 =C2=A0[COM-REQ]. =C2=A0[R= FC7228] is a base document for the terminology
=C2=A0 =C2=A0concerning constrained devices and= constrained networks. =C2=A0Some use
=C2=A0 =C2=A0cases specific to I= Pv6 over Low-Power Wireless Personal Area Networks
=C2=A0 =C2=A0(6LoWPANs) can be found in [RFC= 6568].






Ersue, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires= January 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Pa= ge 3]
=0C
Internet-Draft =C2= =A0 =C2=A0 =C2=A0Constrained Management: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0July 2014
=

2. =C2=A0Access Tec= hnologies

=C2=A0 =C2=A0Besides the = management requirements imposed by the different use
=C2=A0 =C2=A0cases, the access t= echnologies used by constrained devices can impose
=C2=A0 =C2=A0restrictions and requirements u= pon the Network Management System
=C2=A0 =C2=A0(NMS) and protocol = of choice.

=C2=A0 =C2=A0It is possi= ble that some networks of constrained devices might
=C2=A0 =C2=A0utilize traditional= non-constrained access technologies for network
=C2=A0 =C2=A0access, e.g., local area networks= with plenty of capacity. =C2=A0In such
=C2=A0 =C2=A0scenarios, the cons= trainedness of the device presents special
=C2=A0 =C2=A0management restrictions and requirement= s rather than the access
=C2=A0 =C2=A0technology utilized= .

<= div>=C2=A0 =C2=A0However, in other si= tuations constrained or cellular access
=C2=A0 =C2=A0technologies might = be used for network access, thereby causing
=C2=A0 =C2=A0management restrictions and requiremen= ts to arise as a result of the
=C2=A0 =C2=A0underlying access t= echnologies.

2.1. =C2=A0Constrained= Access Technologies

=C2=A0 =C2=A0Due to resource restrictions, embe= dded devices deployed as sensors
=C2=A0 =C2=A0and actuators in the various use cases utilize lo= w-power low data-
=C2=A0 =C2=A0rate wireless acces= s technologies such as IEEE 802.15.4, DECT ULE or
=C2=A0 =C2=A0BT-LE for network connectivity.<= /font>

=C2=A0 =C2=A0In suc= h scenarios, it is important for the NMS to be aware of the
=C2=A0 =C2=A0restrictions imposed b= y these access technologies to efficiently
=C2=A0 =C2=A0manage these constr= ained devices. =C2=A0Specifically, such low-power low
=C2=A0 =C2=A0data-rate access technologie= s typically have small frame sizes. =C2=A0So
=C2=A0 =C2=A0it would be importa= nt for the NMS and management protocol of choice
=C2=A0 =C2=A0to craft packets in a way that av= oids fragmentation and reassembly of
=C2=A0 =C2=A0packets since this = can use valuable memory on constrained devices.

=C2=A0 =C2=A0Devices using such access technologies might oper= ate via a gateway
=C2=A0 =C2=A0that translates bet= ween these access technologies and more
=C2=A0 =C2=A0traditional Internet protocols. =C2=A0A hi= erarchical approach to device
=C2=A0 =C2=A0management in such = a situation might be useful, wherein the gateway
=C2=A0 =C2=A0device is in-charge of devices co= nnected to it, while the NMS
=C2=A0 =C2=A0conducts management= operations only to the gateway.

2.= 2. =C2=A0Cellular Access Technologies

=C2=A0 =C2=A0Machine to machine (M2M) services = are increasingly provided by mobile
=C2=A0 =C2=A0service providers as numerous devices, home ap= pliances, utility
=C2=A0 =C2=A0meters, cars, video= surveillance cameras, and health monitors, are
=C2=A0 =C2=A0connected with mobile broadband te= chnologies. =C2=A0Different
=C2=A0 =C2=A0applications, e.g.,= in a home appliance or in-car network, use



Ersue, et al. =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 4]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0Constraine= d Management: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0July 2014<= /div>



TW= > typo, Zigbee -> ZigBee (throughout doc)

=C2=A0 =C2=A0Bluetooth, Wi-Fi or Zigbee locally= and connect to a cellular module
=C2=A0 =C2=A0acting as a gateway between the constrained envi= ronment and the
=C2=A0 =C2=A0mobile cellular net= work.

=C2=A0 =C2=A0Such a gateway m= ight provide different options for the connectivity
=C2=A0 =C2=A0of mobile networks = and constrained devices:

TW> BT-= LE --> Bluetooth Low-Energy (BT-LE)

=C2=A0 =C2=A0o =C2=A0a smart phone with 3G/4G a= nd WLAN radio might use BT-LE to connect
=C2=A0 =C2=A0 =C2=A0 to the devices in a home area net= work,

=C2=A0 =C2=A0o =C2=A0a femtocell might be combi= ned with home gateway functionality
=C2=A0 =C2=A0 =C2=A0 acting as a low-power cellular base st= ation connecting smart
=C2=A0 =C2=A0 =C2=A0 devices to = the application server of a mobile service provider,

=C2=A0 =C2=A0o =C2=A0an embedded cellular module with LTE= radio connecting the devices
=C2=A0 =C2=A0 =C2=A0 in the car = network with the server running the telematics service,

=C2=A0 =C2=A0o =C2=A0an M2M gateway connected to the m= obile operator network supporting
=C2=A0 =C2=A0 =C2=A0 diverse IoT= connectivity technologies including ZigBee and CoAP
=C2=A0 =C2=A0 =C2=A0 over 6LoWPAN over IEE= E 802.15.4.

=C2=A0 =C2=A0Common= to all scenarios above is that they are embedded in a service
=
=C2=A0 =C2=A0and connected to a = network provided by a mobile service provider.
=C2=A0 =C2=A0Usually there is a = hierarchical deployment and management topology in
=C2=A0 =C2=A0place where different parts of = the network are managed by different
=C2=A0 =C2=A0management entities= and the count of devices to manage is high (e.g.
=C2=A0 =C2=A0many thousands). =C2=A0In genera= l, the network is comprised by manifold
=C2=A0 =C2=A0type and size of de= vices matching to different device classes. =C2=A0As
=C2=A0 =C2=A0such, the managing entity nee= ds to be prepared to manage devices with
=C2=A0 =C2=A0diverse capabilitie= s using different communication or management
=C2=A0 =C2=A0protocols. =C2=A0In case the devic= es are directly connected to a gateway
=C2=A0 =C2=A0they most likely ar= e managed by a management entity integrated with
=C2=A0 =C2=A0the gateway, which itself is part= of the Network Management System
=C2=A0 =C2=A0(NMS) run by the mo= bile operator. =C2=A0Smart phones or embedded modules
=C2=A0 =C2=A0connected to a gateway might= be themselves in charge to manage the
=C2=A0 =C2=A0devices on their le= vel. =C2=A0The initial and subsequent configuration of
=C2=A0 =C2=A0such a device is mainly bas= ed on self-configuration and is triggered
=C2=A0 =C2=A0by the device itsel= f.

=
=C2=A0 =C2=A0The gateway might b= e in charge of filtering and aggregating the data
=C2=A0 =C2=A0received from the d= evice as the information sent by the device might
=C2=A0 =C2=A0be mostly redundant.

3. =C2=A0Use Cases<= /font>







Ersue, et al. =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 5]
=0C
Internet-Draft =C2=A0 =C2=A0 = =C2=A0Constrained Management: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0J= uly 2014


3.1. =C2=A0Environmental Monitoring

=C2=A0 =C2=A0Enviro= nmental monitoring applications are characterized by the
<= font face=3D"courier new, monospace">=C2=A0 =C2=A0deployment of a number of= sensors to monitor emissions, water
=C2=A0 =C2=A0quality, or even th= e movements and habits of wildlife. =C2=A0Other
=C2=A0 =C2=A0applications in this category incl= ude earthquake or tsunami early-
=C2=A0 =C2=A0warning systems. = =C2=A0The sensors often span a large geographic area,
=C2=A0 =C2=A0they can be mobile, and they= are often difficult to replace.
=C2=A0 =C2=A0Furthermore, the se= nsors are usually not protected against tampering.

=C2=A0 =C2=A0Management of environmental monitoring applica= tions is largely
=C2=A0 =C2=A0concerned with the = monitoring whether the system is still functional
=C2=A0 =C2=A0and the roll-out of new constrai= ned devices in case the system looses
=C2=A0 =C2=A0too much of its str= ucture. =C2=A0The constrained devices themselves need
=C2=A0 =C2=A0to be able to establish conn= ectivity (auto-configuration) and they
=C2=A0 =C2=A0need to be able to = deal with events such as loosing neighbors or
=C2=A0 =C2=A0being moved to other locations.

=C2=A0 =C2=A0Manage= ment responsibility typically rests with the organization
= =C2=A0 =C2=A0running the environmenta= l monitoring application. =C2=A0Since these
=C2=A0 =C2=A0monitoring applicat= ions must be designed to tolerate a number of
=C2=A0 =C2=A0failures, the time scale for detec= ting and recording failures is for
=C2=A0 =C2=A0some of these appli= cations likely measured in hours and repairs might
=C2=A0 =C2=A0easily take days. =C2=A0In fact= , in some scenarios it might be more cost-
=C2=A0 =C2=A0and time-effective = to not repair such devices at all. =C2=A0However, for
=C2=A0 =C2=A0certain environmental monito= ring applications, much tighter time
=C2=A0 =C2=A0scales may exist an= d might be enforced by regulations (e.g.,
=C2=A0 =C2=A0monitoring of nuclear radiation).=

3.2. =C2=A0Infrastr= ucture Monitoring
=C2=A0 =C2=A0Infr= astructure monitoring is concerned with the monitoring of
=C2=A0 =C2=A0infrastructures suc= h as bridges, railway tracks, or (offshore)
=C2=A0 =C2=A0windmills. =C2=A0The primary goal is u= sually to detect any events or
=C2=A0 =C2=A0changes of the stru= ctural conditions that can impact the risk and
=C2=A0 =C2=A0safety of the infrastructure being= monitored. =C2=A0Another secondary goal
=C2=A0 =C2=A0is to schedule repa= ir and maintenance activities in a cost effective
=C2=A0 =C2=A0manner.

=C2=A0 =C2=A0The in= frastructure to monitor might be in a factory or spread over a
=
=C2=A0 =C2=A0wider area but diff= icult to access. =C2=A0As such, the network in use
=C2=A0 =C2=A0might be based on a= combination of fixed and wireless technologies,
=C2=A0 =C2=A0which use robust networking equip= ment and support reliable
=C2=A0 =C2=A0communication via a= pplication layer transactions. =C2=A0It is likely that
=C2=A0 =C2=A0constrained devices in such= a network are mainly C2
=C2=A0 =C2=A0
<= font face=3D"courier new, monospace">>TW please define "C2", a= nd provide RFC
=C2= =A0 =C2=A0
=C2=A0 =C2=A0devices and have<= /div>
=C2=A0 =C2=A0to be controll= ed centrally by an application running on a server. =C2=A0In
=C2=A0 =C2=A0case such a distribut= ed network is widely spread, the wireless
=C2=A0 =C2=A0devices might use d= iverse long-distance wireless technologies such as



Ersue, et al. =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 6]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0Constraine= d Management: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0July 2014<= /div>

TW> I don't fully understand what you me= an by "e.g. based on embedded hardware
TW> modules", in partcular the "e.g.&q= uot; part. Maybe write the idea out in a
TW> separate sentence?=

=C2=A0 =C2=A0WiMAX, or 3G/LTE, e.g. based= on embedded hardware modules. =C2=A0In cases,
=C2=A0 =C2=A0where an in-buildin= g network is involved, the network can be based on
=C2=A0 =C2=A0Ethernet or wireless technologi= es suitable for in-building usage.

=C2=A0 =C2=A0The management of infrastructure m= onitoring applications is primarily
=C2=A0 =C2=A0concerned with the monitoring of the functioni= ng of the system.
=C2=A0 =C2=A0Infrastructure moni= toring devices are typically rolled out and
=C2=A0 =C2=A0installed by dedicated experts and cha= nges are rare since the
=C2=A0 =C2=A0infrastructure itse= lf changes rarely. =C2=A0However, monitoring devices
=C2=A0 =C2=A0are often deployed in unsuper= vised environments and hence special
=C2=A0 =C2=A0attention must be g= iven to protecting the devices from being
=C2=A0 =C2=A0modified.

=C2=A0 =C2=A0Manage= ment responsibility typically rests with the organization
= =C2=A0 =C2=A0owning the infrastructur= e or responsible for its operation. =C2=A0The time
=C2=A0 =C2=A0scale for detecting= and recording failures is likely measured in
=C2=A0 =C2=A0hours and repairs might easily tak= e days. =C2=A0However, certain events
=C2=A0 =C2=A0(e.g., natural disa= sters) may require that status information be
=C2=A0 =C2=A0obtained much more quickly and tha= t replacements of failed sensors
=C2=A0 =C2=A0can be rolled out q= uickly (or redundant sensors are activated
=C2=A0 =C2=A0quickly). =C2=A0In case the devices are= difficult to access, a self-
=C2=A0 =C2=A0healing feature on = the device might become necessary.

= 3.3. =C2=A0Industrial Applications

=C2=A0 =C2=A0Industrial Applications and smart = manufacturing refer to tasks such
=C2=A0 =C2=A0as networked control and monitoring of manufactu= ring equipment, asset
=C2=A0 =C2=A0and situation manag= ement, or manufacturing process control. =C2=A0For the
=C2=A0 =C2=A0management of a factory it = is becoming essential to implement smart
=C2=A0 =C2=A0capabilities. =C2= =A0From an engineering standpoint, industrial
=C2=A0 =C2=A0applications are intelligent syste= ms enabling rapid manufacturing of
=C2=A0 =C2=A0new products, dynam= ic response to product demands, and real-time
=C2=A0 =C2=A0optimization of manufacturing prod= uction and supply chain networks.
=C2=A0 =C2=A0Potential industria= l applications (e.g., for smart factories and
=C2=A0 =C2=A0smart manufacturing) are:

=C2=A0 =C2=A0o =C2= =A0Digital control systems with embedded, automated process controls,
=C2=A0 =C2=A0 =C2=A0 oper= ator tools, as well as service information systems optimizing
=C2=A0 =C2=A0 =C2=A0 plant opera= tions and safety.
=C2=A0 =C2=A0o = =C2=A0Asset management using predictive maintenance tools, statistical
=C2=A0 =C2=A0 =C2=A0 evaluation,= and measurements maximizing plant reliability.

=C2=A0 =C2=A0o =C2=A0Smart sensors detecting anomalies to avoi= d abnormal or
=C2=A0 =C2=A0 =C2=A0 catastrophi= c events.






Ersue, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires= January 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Pa= ge 7]
=0C
Internet-Draft =C2= =A0 =C2=A0 =C2=A0Constrained Management: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0July 2014
=

=C2=A0 =C2=A0o =C2= =A0Smart systems integrated within the industrial energy management<= /div>
=C2=A0 =C2=A0 =C2=A0 system= and externally with the smart grid enabling real-time
=C2=A0 =C2=A0 =C2=A0 energy opti= mization.

TW> I don't unders= tand what the "management" part here refers to in this
TW> section. I expect the dra= ft to deal exclusively with the management needs
TW> for the constrained network (e.g. monit= oring 6LoWPAN counters). This
TW> section seems to deal wit= h the management of a smart plant.

= =C2=A0 =C2=A0Management of Industrial Applications and smart manufacturing = may in
=C2=A0 =C2=A0some situations inv= olve Building Automation tasks such as control of
=C2=A0 =C2=A0energy, HVAC (heating, ventilati= on, and air conditioning), lighting,
=C2=A0 =C2=A0or access control. = =C2=A0Interacting with management systems from other
=C2=A0 =C2=A0application areas might be im= portant in some cases (e.g.,
=C2=A0 =C2=A0environmental monit= oring for electric energy production, energy
=C2=A0 =C2=A0management for dynamically scaling ma= nufacturing, vehicular networks
=C2=A0 =C2=A0for mobile asset tr= acking).

=
=C2=A0 =C2=A0Sensor networ= ks are an essential technology used for smart
=C2=A0 =C2=A0manufacturing. =C2= =A0Measurements, automated controls, plant optimization,
<= font face=3D"courier new, monospace">=C2=A0 =C2=A0health and safety managem= ent, and other functions are provided by a
=C2=A0 =C2=A0large number of net= worked sectors. =C2=A0Data interoperability and
=C2=A0 =C2=A0seamless exchange of product, proc= ess, and project data are enabled
=C2=A0 =C2=A0through interoperab= le data systems used by collaborating divisions or
=C2=A0 =C2=A0business systems. =C2=A0Intelli= gent automation and learning systems are
=C2=A0 =C2=A0vital to smart manu= facturing but must be effectively integrated with
=C2=A0 =C2=A0the decision environment. =C2=A0= Wireless sensor networks (WSN) have been
=C2=A0 =C2=A0developed for machi= nery Condition-based Maintenance (CBM) as they
=C2=A0 =C2=A0offer significant cost savings and= enable new functionalities.
=C2=A0 =C2=A0Inaccessible locati= ons, rotating machinery, hazardous areas, and
=C2=A0 =C2=A0mobile assets can be reached with = wireless sensors. =C2=A0WSNs can provide
=C2=A0 =C2=A0today wireless link= reliability, real-time capabilities, and quality-
=C2=A0 =C2=A0of-service and enable industria= l and related wireless sense and
=C2=A0 =C2=A0control application= s.

=
=C2=A0 =C2=A0Management of indus= trial and factory applications is largely focused
=C2=A0 =C2=A0on the monitoring w= hether the system is still functional, real-time
=C2=A0 =C2=A0continuous performance monitoring= , and optimization as necessary.
=C2=A0 =C2=A0The factory network= might be part of a campus network or connected to
=C2=A0 =C2=A0the Internet. =C2=A0The constra= ined devices in such a network need to be
=C2=A0 =C2=A0able to establish c= onfiguration themselves (auto-configuration) and
=C2=A0 =C2=A0might need to deal with error con= ditions as much as possible locally.
=C2=A0 =C2=A0Access control has = to be provided with multi-level administrative
=C2=A0 =C2=A0access and security. =C2=A0Support= and diagnostics can be provided through
=C2=A0 =C2=A0remote monitoring a= ccess centralized outside of the factory.

=C2=A0 =C2=A0Management responsibility is typically owned by the org= anization
=C2=A0 =C2=A0running the industr= ial application. =C2=A0Since the monitoring
=C2=A0 =C2=A0applications must handle a potentially= large number of failures, the
=C2=A0 =C2=A0time scale for dete= cting and recording failures is for some of these
=C2=A0 =C2=A0applications likely measured in = minutes. =C2=A0However, for certain
=C2=A0 =C2=A0industrial applicat= ions, much tighter time scales may exist, e.g. in




Ersue, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0[Page 8]
=0C
Internet-Draft =C2= =A0 =C2=A0 =C2=A0Constrained Management: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0July 2014
=

=C2=A0 =C2=A0real-t= ime, which might be enforced by the manufacturing process or
=C2=A0 =C2=A0the use of critical m= aterial.

3.4. =C2=A0Energy Management
<= font face=3D"courier new, monospace">
=C2=A0 =C2=A0The EMAN working group developed an ener= gy management framework
=C2=A0 =C2=A0[I-D.ietf-eman-fram= ework] for devices and device components within or
=C2=A0 =C2=A0connected to communication netw= orks. =C2=A0This document observes that one
=C2=A0 =C2=A0of the challenges o= f energy management is that a power distribution
=C2=A0 =C2=A0network is responsible for the su= pply of energy to various devices
=C2=A0 =C2=A0and components, whi= le a separate communication network is typically
=C2=A0 =C2=A0used to monitor and control the p= ower distribution network. =C2=A0Devices
=C2=A0 =C2=A0in the context of e= nergy management can be monitored for parameters
=C2=A0 =C2=A0like Power, Energy, Demand and Po= wer Quality. =C2=A0If a device contains
=C2=A0 =C2=A0batteries, they can= be also monitored and managed.

=C2= =A0 =C2=A0Energy devices differ in complexity and may include basic sensors= or
=C2=A0 =C2=A0switches, specializ= ed electrical meters, or power distribution units
=C2=A0 =C2=A0(PDU), and subsystems inside the= network devices (routers, network
=C2=A0 =C2=A0switches) or home o= r industrial appliances. =C2=A0The operators of an
=C2=A0 =C2=A0Energy Management System are ei= ther the utility providers or
=C2=A0 =C2=A0customers that aim = to control and reduce the energy consumption and
=C2=A0 =C2=A0the associated costs. =C2=A0The t= opology in use differs and the deployment
=C2=A0 =C2=A0can cover areas fro= m small surfaces (individual homes) to large
=C2=A0 =C2=A0geographical areas. =C2=A0The EMAN re= quirements document [RFC6988]
=C2=A0 =C2=A0discusses the requi= rements for energy management concerning
=C2=A0 =C2=A0monitoring and control functions.<= /div>

=C2=A0 =C2=A0It is = assumed that Energy Management will apply to a large range of
<= div>=C2=A0 =C2=A0devices of all class= es and networks topologies. =C2=A0Specific resource
=C2=A0 =C2=A0monitoring like bat= tery utilization and availability may be specific
=C2=A0 =C2=A0to devices with lower physical r= esources (device classes C0 or C1).

=C2=A0 =C2=A0Energy Management is especially re= levant to the Smart Grid. =C2=A0A Smart
=C2=A0 =C2=A0Grid is an electrical grid that uses data = networks to gather and to
=C2=A0 =C2=A0act on energy and p= ower-related information in an automated fashion
=C2=A0 =C2=A0with the goal to improve the effi= ciency, reliability, economics, and
=C2=A0 =C2=A0sustainability of t= he production and distribution of electricity.

=C2=A0 =C2=A0Smart Metering is a good example of Smart Grid ba= sed Energy
=C2=A0 =C2=A0Management applicat= ions. =C2=A0Different types of possibly wireless small
=C2=A0 =C2=A0meters produce all together= a large amount of data, which is
=C2=A0 =C2=A0collected by a cent= ral entity and processed by an application server,
=C2=A0 =C2=A0which may be located within the= customer's residence or off-site in a
=C2=A0 =C2=A0data-center. =C2=A0= The communication infrastructure can be provided by a
=C2=A0 =C2=A0mobile network operator as t= he meters in urban areas will have most
=C2=A0 =C2=A0likely a cellular o= r WiMAX radio. =C2=A0In case the application server is




Ersue, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0[Page 9]
=0C
Internet-Draft =C2= =A0 =C2=A0 =C2=A0Constrained Management: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0July 2014
=

=C2=A0 =C2=A0locate= d within the residence, such meters are more likely to use WiFi
=C2=A0 =C2=A0protocols to inter= connect with an existing network.

=C2=A0 =C2=A0An Advanced Metering Infrastructur= e (AMI) network is another example
=C2=A0 =C2=A0of the Smart Grid that enables an electric util= ity to retrieve
=C2=A0 =C2=A0frequent electric u= sage data from each electric meter installed at a
=C2=A0 =C2=A0customer's home or business.= =C2=A0Unlike Smart Metering, in which case
=C2=A0 =C2=A0the customer or the= ir agents install appliance level meters, an AMI
=C2=A0 =C2=A0infrastructure is typically manag= ed by the utility providers and
=C2=A0 =C2=A0could also include = other distribution automation devices like
=C2=A0 =C2=A0transformers and reclosers. =C2=A0Meter= s in AMI networks typically contain
=C2=A0 =C2=A0constrained devices= that connect to mesh networks with a low-
=C2=A0 =C2=A0bandwidth radio. =C2=A0Usage data and o= utage notifications can be sent by
=C2=A0 =C2=A0these meters to the= utility's headend systems, via aggregation points
=C2=A0 =C2=A0of higher-end router device= s that bridge the constrained network to a
=C2=A0 =C2=A0less constrained ne= twork via cellular, WiMAX, or Ethernet. =C2=A0Unlike
=C2=A0 =C2=A0meters, these higher-end devi= ces might be installed on utility poles
=C2=A0 =C2=A0owned and operated = by a separate entity.
=C2=A0 =C2=A0= It thereby becomes important for a management application to not only
=C2=A0 =C2=A0be able to work wit= h diverse types of devices, but also over multiple
=C2=A0 =C2=A0links that might be operated an= d managed by separate entities, each
=C2=A0 =C2=A0having divergent po= licies for their own devices and network segments.
=C2=A0 =C2=A0During management operations, l= ike firmware updates, it is important
=C2=A0 =C2=A0that the management= system performs robustly in order to avoid
=C2=A0 =C2=A0accidental outages of critical power s= ystems that could be part of
=C2=A0 =C2=A0AMI networks. =C2= =A0In fact, since AMI networks must also report on
=C2=A0 =C2=A0outages, the management system = might have to manage the energy
=C2=A0 =C2=A0properties of batte= ry operated AMI devices themselves as well.

=C2=A0 =C2=A0A management system for home based Smart Metering sol= utions is likely
=C2=A0 =C2=A0to have few devices= laid out in a simple topology.
TW> how many are few? what's a simple topology? While (I= think) I have a good
TW> of what that might be, pr= oposing a range might help with scope
=C2=A0 =C2=A0However, AMI
=C2=A0 =C2=A0networks installations could have thou= sands of nodes per router,
=C2=A0 =C2=A0i.e., higher-end de= vice, which organize themselves in an ad-hoc
=C2=A0 =C2=A0manner. =C2=A0As such, a management s= ystem for AMI networks will need to
=C2=A0 =C2=A0discover and operat= e over complex topologies as well. =C2=A0In some
=C2=A0 =C2=A0situations, it is possible that t= he management system might also have
=C2=A0 =C2=A0to setup and manage= the topology of nodes, especially critical
=C2=A0 =C2=A0routers. =C2=A0Encryption key manageme= nt and sharing in both types of
=C2=A0 =C2=A0network
TW> typo network*s*
=C2=A0 =C2=A0is also likely = to be important for providing confidentiality
=C2=A0 =C2=A0for all data traffi= c. =C2=A0In AMI networks the key may be obtained by a
=C2=A0 =C2=A0meter only after an end-to-e= nd authentication process based on
=C2=A0 =C2=A0certificates. =C2= =A0Smart Metering solution could adopt a similar approach
= =C2=A0 =C2=A0or the security may be i= mplied due to the encrypted WiFi networks
=C2=A0 =C2=A0they become part of= .

<= div>TW> Please use either Wi-Fi or= WiFi. There must be an official one?

=C2=A0 =C2=A0The management of such a network r= equires end-to-end management of
=C2=A0 =C2=A0and information exchange through different types = of networks.



Er= sue, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 201= 5 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 10]
=0C
Internet-Draft =C2= =A0 =C2=A0 =C2=A0Constrained Management: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0July 2014
=

=C2=A0 =C2=A0Howeve= r, as of today there is no integrated energy management
=C2=A0 =C2=A0approach and no common inf= ormation model available. =C2=A0Specific energy
=C2=A0 =C2=A0management applicat= ions or network islands use their own management
=C2=A0 =C2=A0mechanisms.

3.5. =C2=A0Medical = Applications

=C2=A0 =C2=A0Constrain= ed devices can be seen as an enabling technology for
=C2=A0 =C2=A0advanced and possib= ly remote health monitoring and emergency
=C2=A0 =C2=A0notification systems, ranging from blood= pressure and heart rate
=C2=A0 =C2=A0monitors to advance= d devices capable to monitor
TW> rephrase to "capable of monitoring"?
=
=C2=A0 =C2=A0implanted
=C2=A0 =C2=A0technologies, such = as pacemakers or advanced hearing aids. =C2=A0Medical
=C2=A0 =C2=A0sensors may not only be atta= ched to human bodies, they might also
=C2=A0 =C2=A0exist in the infras= tructure used by humans such as bathrooms or
=C2=A0 =C2=A0kitchens. =C2=A0Medical applications = will also be used to ensure
=C2=A0 =C2=A0treatments are bein= g applied properly and they might guide people
=C2=A0 =C2=A0losing orientation. =C2=A0Fitness = and wellness applications, such as
=C2=A0 =C2=A0connected scales or= wearable heart monitors, encourage consumers to
=C2=A0 =C2=A0exercise and empower self-monitor= ing of key fitness indicators.
=C2=A0 =C2=A0Different applicati= ons use Bluetooth, Wi-Fi or Zigbee connections to
=C2=A0 =C2=A0access the patient's smartph= one or home cellular connection to access
=C2=A0 =C2=A0the Internet.

=C2=A0 =C2=A0Constrained devices that ar= e part of medical applications are managed
=C2=A0 =C2=A0either by the users= of those devices or by an organization providing
=C2=A0 =C2=A0medical (monitoring) services fo= r physicians. =C2=A0In the first case,
=C2=A0 =C2=A0management must be = automatic and or
TW&= gt; "and/or"?
=C2=A0 =C2=A0easy to install and setup by
=C2=A0 =C2=A0average people. =C2= =A0In the second case, it can be expected that devices
=C2=A0 =C2=A0be controlled by specially = trained people. =C2=A0In both cases, however,
=C2=A0 =C2=A0it is crucial to pr= otect the privacy of the people to which medical
=C2=A0 =C2=A0devices are attached. =C2=A0Even = though the data collected by a heart beat
=C2=A0 =C2=A0monitor might be pr= otected, the pure fact that someone carries such a
=C2=A0 =C2=A0device may need protection. =C2= =A0As such, certain medical appliances may
=C2=A0 =C2=A0not want to partici= pate in discovery and self-configuration protocols
=C2=A0 =C2=A0in order to remain invisible.

=C2=A0 =C2=A0Many m= edical devices are likely to be used (and relied upon) to
= =C2=A0 =C2=A0provide data to physicia= ns in critical situations since the biggest
=C2=A0 =C2=A0market is likely el= derly and handicapped people. =C2=A0Timely delivery of
=C2=A0 =C2=A0data can be quite important= in certain applications like patient
=C2=A0 =C2=A0mobility monitoring= in oldage homes. =C2=A0Data must reach the physician
=C2=A0 =C2=A0and/or emergency services wi= thin specified limits of time in order to
=C2=A0 =C2=A0be useful. =C2=A0As= such, fault detection of the communication network or
=C2=A0 =C2=A0the constrained devices bec= omes a crucial function of the management
=C2=A0 =C2=A0system that must be= carried out with high reliability and, depending
=C2=A0 =C2=A0on the medical appliance and its= application, within seconds.




Ersue, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 [Page 11]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0Constrained Management: Use = Cases =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0July 2014


3.6. =C2=A0Building Automation

=C2=A0 =C2=A0Buildi= ng automation comprises the distributed systems designed and
=C2=A0 =C2=A0deployed to monitor a= nd control the mechanical, electrical and
=C2=A0 =C2=A0electronic systems = inside buildings with various destinations (e.g.,
=C2=A0 =C2=A0public and private, industrial, = institutions, or residential).
=C2=A0 =C2=A0Advanced Building A= utomation Systems (BAS) may be deployed
=C2=A0 =C2=A0concentrating the various functions of saf= ety, environmental control,
=C2=A0 =C2=A0occupancy, security= . =C2=A0More and more the deployment of the various
=C2=A0 =C2=A0functional systems is connecte= d to the same communication
=C2=A0 =C2=A0infrastructure (pos= sibly Internet Protocol based), which may involve
=C2=A0 =C2=A0wired or wireless communications= networks inside the building.

=C2=A0 =C2=A0Building automation requires the d= eployment of a large number
=C2=A0 =C2=A0(10-100.000) of sensors that monitor the status of dev= ices, and
=C2=A0 =C2=A0parameters inside t= he building and controllers with different
=C2=A0 =C2=A0specialized functionality for areas wit= hin the building or the
=C2=A0 =C2=A0totality of the bui= lding. =C2=A0Inter-node distances between neighboring
=C2=A0 =C2=A0nodes vary between 1 to 20 m= eters. =C2=A0Contrary to home automation, in
=C2=A0 =C2=A0building management= the devices are expected to be managed assets and
=C2=A0 =C2=A0known to a set of commissioning= tools and a data storage, such that
=C2=A0 =C2=A0every connected dev= ice has a known origin. =C2=A0The management includes
=C2=A0 =C2=A0verifying the presence of th= e expected devices and detecting the
=C2=A0 =C2=A0presence of unwante= d devices.

=C2=A0 =C2=A0Examples of= functions performed by such controllers are regulating
=C2=A0 =C2=A0the quality, humidi= ty, and temperature of the air inside the building
=C2=A0 =C2=A0and lighting. =C2=A0Other syste= ms may report the status of the machinery
=C2=A0 =C2=A0inside the building= like elevators, or inside the rooms like
=C2=A0 =C2=A0projectors in meeting rooms. =C2=A0Secur= ity cameras and sensors may be
=C2=A0 =C2=A0deployed and operat= ed on separate dedicated infrastructures connected
=C2=A0 =C2=A0to the common backbone. =C2=A0T= he deployment area of a BAS is typically
=C2=A0 =C2=A0inside one building= (or part of it) or several buildings
=C2=A0 =C2=A0geographically grouped in a campus. =C2=A0A = building network can be
=C2=A0 =C2=A0composed of network= segments, where a network segment covers a floor,
=C2=A0 =C2=A0an area on the floor, or a give= n functionality (e.g., security
=C2=A0 =C2=A0cameras).

=C2=A0 =C2=A0Some of the sensors in Building= Automation Systems (for example fire
=C2=A0 =C2=A0alarms or security = systems) register, record and transfer critical
=C2=A0 =C2=A0alarm information and therefore mu= st be resilient to events like loss
=C2=A0 =C2=A0of power or securit= y attacks. =C2=A0This leads to the need to certify
=C2=A0 =C2=A0components and subsystems opera= ting in such constrained conditions
=C2=A0 =C2=A0based on specific r= equirements. =C2=A0Also in some environments, the
=C2=A0 =C2=A0malfunctioning of a control syst= em (like temperature control) needs
=C2=A0 =C2=A0to be reported in t= he shortest possible time. =C2=A0Complex control
=C2=A0 =C2=A0systems can misbehave, and their = critical status reporting and safety



Ersue, et al. =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 [Page 12]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0Constrained = Management: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0July 2014


=C2=A0 =C2=A0algorithms need to be basic and robust and perfor= m even in critical
=C2=A0 =C2=A0conditions.<= /div>

=C2=A0 =C2=A0Building Automation solutions= are deployed in some cases in newly
=C2=A0 =C2=A0designed buildings,= in other cases it might be over existing
=C2=A0 =C2=A0infrastructures. =C2=A0In the first case= , there is a broader range of
=C2=A0 =C2=A0possible solutions,= which can be planned for the infrastructure of
=C2=A0 =C2=A0the building. =C2=A0In the second = case the solution needs to be deployed
=C2=A0 =C2=A0over an existing in= frastructure taking into account factors like
=C2=A0 =C2=A0existing wiring, distance limitati= ons, the propagation of radio
=C2=A0 =C2=A0signals over walls = and floors, thereby making deployment difficult.
=C2=A0 =C2=A0As a result, some of the existing= WLAN solutions (e.g., IEEE 802.11
=C2=A0 =C2=A0or IEEE 802.15) may= be deployed. =C2=A0In mission-critical or security
=C2=A0 =C2=A0sensitive environments and in = cases where link failures happen often,
=C2=A0 =C2=A0topologies that all= ow for reconfiguration of the network and
=C2=A0 =C2=A0connection continuity may be required. = =C2=A0Some of the sensors deployed
=C2=A0 =C2=A0in building automat= ion may be very simple constrained devices for
=C2=A0 =C2=A0which class 0 or class 1 may be as= sumed.

TW> you use "C1" and "C0" abo= ve. Please homogenize.
=C2=A0 =C2=A0
=C2=A0 =C2=A0For lighting applic= ations, groups of lights must be defined and
=C2=A0 =C2=A0managed. =C2=A0Commands to a group of= light must arrive within 200 ms at
=C2=A0 =C2=A0all destinations. = =C2=A0The installation and operation of a building
=C2=A0 =C2=A0network has different requireme= nts. =C2=A0During the installation, many
=C2=A0 =C2=A0stand-alone network= s of a few to 100 nodes co-exist without a
=C2=A0 =C2=A0connection to the backbone. =C2=A0Durin= g this phase, the nodes are
=C2=A0 =C2=A0identified with a n= etwork identifier related to their physical
=C2=A0 =C2=A0location. =C2=A0Devices are accessed f= rom an installation tool to connect
=C2=A0 =C2=A0them to the network= in a secure fashion. =C2=A0During installation, the
=C2=A0 =C2=A0setting of parameters of comm= on values to enable interoperability may
=C2=A0 =C2=A0be required. =C2=A0= During operation, the networks are connected to the
=C2=A0 =C2=A0backbone while maintaining the= network identifier to physical
=C2=A0 =C2=A0location relation. = =C2=A0Network parameters like address and name are
=C2=A0 =C2=A0stored in DNS. =C2=A0The names = can assist in determining the physical
=C2=A0 =C2=A0location of the dev= ice.

3.7. =C2=A0Home Automation

=C2=A0 =C2=A0Home a= utomation includes the control of lighting, heating,
=C2=A0 =C2=A0ventilation, air conditioning= , appliances, entertainment and home
TW> The word "security&q= uot; appears twice
= =C2=A0 =C2=A0security devices to improve convenience, comfort, energy effic= iency,
=C2=A0 =C2=A0and security. =C2= =A0It can be seen as a residential extension of building
<= font face=3D"courier new, monospace">=C2=A0 =C2=A0automation. =C2=A0However= , unlike a building automation system, the
=C2=A0 =C2=A0infrastructure in a= home is operated in a considerably more ad-hoc
=C2=A0 =C2=A0manner. =C2=A0While in some instal= lations it is likely that there is no
=C2=A0 =C2=A0centralized managem= ent system, akin to a Building Automation System
=C2=A0 =C2=A0(BAS), available, in other situat= ions outsourced and cloud based
=C2=A0 =C2=A0systems responsible= for managing devices in the home might be used.




Ersue, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 [Page 13]
=0C
Internet-Draft =C2= =A0 =C2=A0 =C2=A0Constrained Management: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0July 2014
=

=C2=A0 =C2=A0Home a= utomation networks need a certain amount of configuration
= TW> actors -> actuators ?
=C2=A0 =C2=A0(associating switches or= sensors to actors) that is either provided
=C2=A0 =C2=A0by electricians deploying home automat= ion solutions, by third party
=C2=A0 =C2=A0home automation ser= vice providers (e.g., small specialized companies
=C2=A0 =C2=A0or home automation device manufa= cturers) or by residents by using the
=C2=A0 =C2=A0application user in= terface provided by home automation devices to
=C2=A0 =C2=A0configure (parts of) the home auto= mation solution. =C2=A0Similarly,
=C2=A0 =C2=A0failures may be rep= orted via suitable interfaces to residents or they
=C2=A0 =C2=A0might be recorded and made avai= lable to services providers in charge
=C2=A0 =C2=A0of the maintenance = of the home automation infrastructure.

=C2=A0 =C2=A0The management responsibility lies either with the residen= ts or it
=C2=A0 =C2=A0may be outsourced t= o electricians and/or third parties providing
=C2=A0 =C2=A0management of home automation solu= tions as a service. =C2=A0A varying
=C2=A0 =C2=A0combination of elec= tricians, service providers or the residents may
=C2=A0 =C2=A0be responsible for different aspe= cts of managing the infrastructure.
=C2=A0 =C2=A0The time scale for = failure detection and resolution is in many cases
=C2=A0 =C2=A0likely counted in hours to days.=

3.8. =C2=A0Transpor= t Applications

<= /font>
=C2=A0 =C2=A0Transpo= rt Application is a generic term for the integrated
=C2=A0 =C2=A0application of comm= unications, control, and information processing in
=C2=A0 =C2=A0a transportation system. =C2=A0= Transport telematics or vehicle telematics
=C2=A0 =C2=A0are used as a term = for the group of technologies that support
=C2=A0 =C2=A0transportation systems. =C2=A0Transport= applications running on such a
=C2=A0 =C2=A0transportation syst= em cover all modes of the transport and consider
=C2=A0 =C2=A0all elements of the transportatio= n system, i.e. the vehicle, the
=C2=A0 =C2=A0infrastructure, and= the driver or user, interacting together
=C2=A0 =C2=A0dynamically. =C2=A0Examples for transpor= t applications are inter and intra
=C2=A0 =C2=A0vehicular communica= tion, smart traffic control, smart parking,
=C2=A0 =C2=A0electronic toll collection systems, lo= gistic and fleet management,
=C2=A0 =C2=A0vehicle control, an= d safety and road assistance.

=C2= =A0 =C2=A0As a distributed system, transport applications require an end-to= -end
=C2=A0 =C2=A0management of diffe= rent types of networks. =C2=A0It is likely that
=C2=A0 =C2=A0constrained devices in a network (= e.g. a moving in-car network) have
=C2=A0 =C2=A0to be controlled by= an application running on an application server
=C2=A0 =C2=A0in the network of a service provi= der. =C2=A0Such a highly distributed
=C2=A0 =C2=A0network including c= ellular devices on vehicles is assumed to include
=C2=A0 =C2=A0a wireless access network using = diverse long distance wireless
=C2=A0 =C2=A0technologies such a= s WiMAX, 3G/LTE or satellite communication, e.g.
=C2=A0 =C2=A0based on an embedded hardware mod= ule. =C2=A0As a result, the management of
=C2=A0 =C2=A0constrained devices= in the transport system might be necessary to
=C2=A0 =C2=A0plan top-down and might need to us= e data models obliged from and
=C2=A0 =C2=A0defined on the appl= ication layer. =C2=A0The assumed device classes in use
=C2=A0 =C2=A0are mainly C2 devices. =C2= =A0In cases, where an in-vehicle network is
=C2=A0 =C2=A0involved, C1 device= s with limited capabilities and a short-distance



Ersue, et al. =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 [Page 14]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0Constrained Man= agement: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0July 2014


=C2=A0 =C2=A0constrained radio network, e.g. =C2=A0IEEE 802.15= .4 might be used
=C2=A0 =C2=A0additionally.

=C2=A0 =C2=A0All Transport Applications = will require an IT infrastructure to run
=C2=A0 =C2=A0on top of, e.g., in= public transport scenarios like trains, bus or
=C2=A0 =C2=A0metro network infrastructure might= be provided, maintained and
=C2=A0 =C2=A0operated by third p= arties like mobile network or satellite network
=C2=A0 =C2=A0operators. =C2=A0However, the mana= gement responsibility of the transport
=C2=A0 =C2=A0application typical= ly rests within the organization running the
=C2=A0 =C2=A0transport application (in the public = transport scenario, this would
=C2=A0 =C2=A0typically be the pu= blic transport operator). =C2=A0Different aspects of
=C2=A0 =C2=A0the infrastructure might also= be managed by different entities. =C2=A0For
=C2=A0 =C2=A0example, the in-car= devices are likely to be installed and managed by
=C2=A0 =C2=A0the manufacturer, while the pub= lic works might be responsible for the
=C2=A0 =C2=A0on-road vehicular c= ommunication infrastructure used by these devices.
=C2=A0 =C2=A0The back-end infrastructure is = also likely to be maintained by third
=C2=A0 =C2=A0party operators. = =C2=A0As such, the NMS must be able to deal with
=C2=A0 =C2=A0different network segments, each = being operated and controlled by
=C2=A0 =C2=A0separate entities, = and enable appropriate access control and security
=C2=A0 =C2=A0as well.

=C2=A0 =C2=A0Depend= ing on the type of application domain (vehicular or stationary)
=C2=A0 =C2=A0and service being = provided, it would be important for the NMS to be
=C2=A0 =C2=A0able to function wi= th different architectures, since different
=C2=A0 =C2=A0manufacturers might have their own pro= prietary systems relying on a
=C2=A0 =C2=A0specific Management= Topology Option, as described in [COM-REQ].
=C2=A0 =C2=A0Moreover, constituents of the network= can be either private,
=C2=A0 =C2=A0belonging to indivi= duals or private companies, or owned by public
=C2=A0 =C2=A0institutions leading to different = legal and organization
=C2=A0 =C2=A0requirements. =C2= =A0Across the entire infrastructure, a variety of
=C2=A0 =C2=A0constrained devices are likely t= o be used, and must be individually
=C2=A0 =C2=A0managed. =C2=A0The = NMS must be able to either work directly with different
=C2=A0 =C2=A0types of devices, or have = the ability to interoperate with multiple
=C2=A0 =C2=A0different systems.<= /font>

=C2=A0 =C2=A0The challenges in the = management of vehicles in a mobile transport
=C2=A0 =C2=A0application are man= ifold. =C2=A0The up-to-date position of each node in
=C2=A0 =C2=A0the network should be reporte= d to the corresponding management
=C2=A0 =C2=A0entities, since the= nodes could be moving within or roaming between
=C2=A0 =C2=A0different networks. =C2=A0Secondl= y, a variety of troubleshooting
=C2=A0 =C2=A0information, includ= ing sensitive location information, needs to be
=C2=A0 =C2=A0reported to the management system = in order to provide accurate
=C2=A0 =C2=A0service to the cust= omer. =C2=A0Management systems dealing with mobile
=C2=A0 =C2=A0nodes could possibly exploit sp= ecific patterns in the mobility of the
=C2=A0 =C2=A0nodes. =C2=A0These = patterns emerge due to repetitive vehicular usage in
=C2=A0 =C2=A0scenarios like people commuti= ng to work, logistics supply vehicles
=C2=A0 =C2=A0transporting shipme= nts between warehouses and etc. =C2=A0The NMS must also
=C2=A0 =C2=A0be able to handle partitio= ned networks, which would arise due to the



Er= sue, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 201= 5 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 15]
=0C
Internet-Draft =C2= =A0 =C2=A0 =C2=A0Constrained Management: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0July 2014
=

=C2=A0 =C2=A0dynami= c nature of traffic resulting in large inter-vehicle gaps in
=C2=A0 =C2=A0sparsely populated sc= enarios. =C2=A0Since mobile nodes might roam in
=C2=A0 =C2=A0remote networks, th= e NMS should be able to provide operating
=C2=A0 =C2=A0configuration updates regardless of node= location.

=C2=A0 =C2=A0The constrained devices in a movin= g transport network might be
=C2=A0 =C2=A0initially configured in a factory and a reconfigurati= on might be
=C2=A0 =C2=A0needed only rarely.= =C2=A0New devices might be integrated in an ad-hoc
=C2=A0 =C2=A0manner based on self-managemen= t and -configuration capabilities.
=C2=A0 =C2=A0Monitoring and data= exchange might be necessary to do via a gateway
=C2=A0 =C2=A0entity connected to the back-end = transport infrastructure. =C2=A0The
=C2=A0 =C2=A0devices and entitie= s in the transport infrastructure need to be
=C2=A0 =C2=A0monitored more frequently and can be = able to communicate with a
=C2=A0 =C2=A0higher data rate. = =C2=A0The connectivity of such entities does not
=C2=A0 =C2=A0necessarily need to be wireless. = =C2=A0The time scale for detecting and
=C2=A0 =C2=A0recording failures = in a moving transport network is likely measured
=C2=A0 =C2=A0in hours and repairs might easily= take days. =C2=A0It is likely that a
=C2=A0 =C2=A0self-healing featur= e would be used locally. =C2=A0On the other hand,
=C2=A0 =C2=A0failures in fixed transport appl= ication infrastructure (e.g.,
=C2=A0 =C2=A0traffic-lights, dig= ital signage displays) is likely to be measured in
=C2=A0 =C2=A0minutes so as to avoid untoward= traffic incidents. =C2=A0As such, the NMS
=C2=A0 =C2=A0must be able to dea= l with differing timeliness requirements based on
=C2=A0 =C2=A0the type of devices.

3.9. =C2=A0Communit= y Network Applications

=C2=A0 =C2= =A0Community networks are comprised of constrained routers in a multi-
=C2=A0 =C2=A0hop mesh topology, = communicating over a lossy, and often wireless
TW> typo: channel*s*
=C2=A0 =C2=A0channel. =C2=A0While the route= rs are mostly non-mobile, the topology may
=C2=A0 =C2=A0be very dynamic bec= ause of fluctuations in link quality of the
=C2=A0 =C2=A0(wireless) channel caused by, e.g., ob= stacles, or other nearby radio
=C2=A0 =C2=A0transmissions. =C2= =A0Depending on the routers that are used in the
=C2=A0 =C2=A0community network, the resources = of the routers (memory, CPU) may be
=C2=A0 =C2=A0more or less constr= ained - available resources may range from only a
=C2=A0 =C2=A0few kilobytes of RAM to several = megabytes or more, and CPUs may be
=C2=A0 =C2=A0small and embedded,= or more powerful general-purpose processors.
=C2=A0 =C2=A0Examples of such community network= s are the FunkFeuer network
=C2=A0 =C2=A0(Vienna, Austria), = FreiFunk (Berlin, Germany), Seattle Wireless
=C2=A0 =C2=A0(Seattle, USA), and AWMN (Athens, Gre= ece). =C2=A0These community networks
=C2=A0 =C2=A0are public and non-= regulated, allowing their users to connect to each
=C2=A0 =C2=A0other and - through an uplink t= o an ISP - to the Internet. =C2=A0No fee,
=C2=A0 =C2=A0other than the init= ial purchase of a wireless router, is charged for
=C2=A0 =C2=A0these services. =C2=A0Applicatio= ns of these community networks can be
=C2=A0 =C2=A0diverse, e.g., loca= tion based services, free Internet access, file
=C2=A0 =C2=A0sharing between users, distributed= chat services, social networking
=C2=A0 =C2=A0etc, video sharing = etc.

TW> One "etc" too= many above.



Ersue, et al. =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 [Page 16]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0Constrained = Management: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0July 2014


=C2=A0 =C2=A0As an example of a community network, the FunkFeu= er network comprises
=C2=A0 =C2=A0several hundred rou= ters, many of which have several radio interfaces
=C2=A0 =C2=A0(with omnidirectional and some d= irected antennas). =C2=A0The routers of
=C2=A0 =C2=A0the network are sma= ll-sized wireless routers, such as the Linksys
=C2=A0 =C2=A0WRT54GL, available in 2011 for les= s than 50 Euros. =C2=A0These routers,
=C2=A0 =C2=A0with 16 MB of RAM a= nd 264 MHz of CPU power, are mounted on the
=C2=A0 =C2=A0rooftops of the users. =C2=A0When new = users want to connect to the
=C2=A0 =C2=A0network, they acqui= re a wireless router, install the appropriate
=C2=A0 =C2=A0firmware and routing protocol, and= mount the router on the rooftop.
=C2=A0 =C2=A0IP addresses for th= e router are assigned manually from a list of
=C2=A0 =C2=A0addresses (because of the lack of = autoconfiguration standards for
TW> autoconfiguration -> a= uto-configuration?
= =C2=A0 =C2=A0mesh networks in the IETF).

=C2=A0 =C2=A0While = the routers are non-mobile, fluctuations in link quality
<= font face=3D"courier new, monospace">=C2=A0 =C2=A0require an ad hoc routing= protocol that allows for quick convergence
=C2=A0 =C2=A0to reflect the effe= ctive topology of the network (such as NHDP
=C2=A0 =C2=A0[RFC6130] and OLSRv2 [RFC7181] develop= ed in the MANET WG). =C2=A0Usually,
=C2=A0 =C2=A0no human interactio= n is required for these protocols, as all variable
=C2=A0 =C2=A0parameters required by the rout= ing protocol are either negotiated in
=C2=A0 =C2=A0the control traffic= exchange, or are only of local importance to each
=C2=A0 =C2=A0router (i.e. do not influence i= nteroperability). =C2=A0However, external
=C2=A0 =C2=A0management and moni= toring of an ad hoc routing protocol may be
=C2=A0 =C2=A0desirable to optimize parameters of th= e routing protocol. =C2=A0Such an
=C2=A0 =C2=A0optimization may le= ad to a more stable perceived topology and to a
=C2=A0 =C2=A0lower control traffic overhead, an= d therefore to a higher delivery
=C2=A0 =C2=A0success ratio of da= ta packets, a lower end-to-end delay, and less
=C2=A0 =C2=A0unnecessary bandwidth and energy u= sage.

=C2=A0 =C2=A0Different use cases for the management = of community networks are
=C2=A0 =C2=A0possible:

=C2=A0 =C2=A0o =C2=A0One single Network Managem= ent Station, e.g. a border gateway
=C2=A0 =C2=A0 =C2=A0 providing connectivity to the Internet,= requires managing or
=C2=A0 =C2=A0 =C2=A0 monitoring = routers in the community network, in order to
=C2=A0 =C2=A0 =C2=A0 investigate problems (moni= toring) or to improve performance by
=C2=A0 =C2=A0 =C2=A0 changing pa= rameters (managing). =C2=A0As the topology of the network is
=C2=A0 =C2=A0 =C2=A0 dynamic, cons= tant connectivity of each router towards the
=C2=A0 =C2=A0 =C2=A0 management = station cannot be guaranteed. =C2=A0Current network
TW> Netconf -> NETCONF (see RFC4741)<= /font>
=C2=A0 =C2=A0 =C2=A0= management protocols, such as SNMP and Netconf, may be used (e.g.,<= /div>
=C2=A0 =C2=A0 =C2=A0 using inter= faces such as the NHDP-MIB [RFC6779]). =C2=A0However, when
=C2=A0 =C2=A0 =C2=A0 routers in the = community network are constrained, existing
=C2=A0 =C2=A0 =C2=A0 protocols m= ay require too many resources in terms of memory and
=C2=A0 =C2=A0 =C2=A0 CPU; and more importa= ntly, the bandwidth requirements may exceed
=C2=A0 =C2=A0 =C2=A0 the availab= le channel capacity in wireless mesh networks.
=C2=A0 =C2=A0 =C2=A0 Moreover, management and m= onitoring may be unfeasible if the
=C2=A0 =C2=A0 =C2=A0 connection = between the network management station and the routers
=C2=A0 =C2=A0 =C2=A0 is frequently inter= rupted.




Ersue, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires= January 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 17]=
=0C
Internet-Draft =C2= =A0 =C2=A0 =C2=A0Constrained Management: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0July 2014
=

TW> I would remo= ve "A"
=C2= =A0 =C2=A0o =C2=A0A distributed network monitoring, in which more than one<= /font>
=C2=A0 =C2=A0 =C2=A0 management stati= on monitors or manages other routers. =C2=A0Because
=C2=A0 =C2=A0 =C2=A0 connectivity to a serv= er cannot be guaranteed at all times, a
=C2=A0 =C2=A0 =C2=A0 distributed= approach may provide a higher reliability, at the cost
=C2=A0 =C2=A0 =C2=A0 of increased compl= exity. =C2=A0Currently, no IETF standard exists for
=C2=A0 =C2=A0 =C2=A0 distributed= monitoring and management.

=C2=A0 = =C2=A0o =C2=A0Monitoring and management of a whole network or a group of
=C2=A0 =C2=A0 =C2=A0 routers. = =C2=A0Monitoring the performance of a community network may
=C2=A0 =C2=A0 =C2=A0 require more i= nformation than what can be acquired from a single
=C2=A0 =C2=A0 =C2=A0 router usin= g a network management protocol. =C2=A0Statistics, such as
=C2=A0 =C2=A0 =C2=A0 topology change= s over time, data throughput along certain routing
=C2=A0 =C2=A0 =C2=A0 paths, cong= estion etc., are of interest for a group of routers (or
TW> update to 2014?
=C2=A0 =C2=A0 =C2=A0 the routing dom= ain) as a whole. =C2=A0As of 2012, no IETF standard
=C2=A0 =C2=A0 =C2=A0 allows for = monitoring or managing whole networks, instead of
=C2=A0 =C2=A0 =C2=A0 single routers.

3.10. =C2=A0Field O= perations

=C2=A0 =C2=A0The challeng= es of configuration and monitoring of networks operated
=C2=A0 =C2=A0in the field by res= cue and security agencies can be different from
=C2=A0 =C2=A0the other use cases since the requ= irements and operating conditions
=C2=A0 =C2=A0of such networks ar= e quite different.
<= br>
TW> typo: bec= omeing -> becoming

=C2=A0 =C2=A0With technology advancements, fiel= d networks operated nowadays are
=C2=A0 =C2=A0becomeing large and can consist of varieties of d= ifferent types of
=C2=A0 =C2=A0equipment that run = different protocols and tools that obviously
TW> "mission-critical"?
<= div>=C2=A0 =C2=A0increase complexity = of these mission critical networks. =C2=A0In many
=C2=A0 =C2=A0scenarios, configur= ations are, most likely, manually performed.
=C2=A0 =C2=A0Furthermore, some legacy and even mod= ern devices do not even support
TW> "*A* majority"?=
TW> proprietary*= ,* which
=C2=A0 =C2= =A0IP networking. =C2=A0Majority of protocols and tools developed by vendor= s
=C2=A0 =C2=A0that are being used= are proprietary which makes integration more
=C2=A0 =C2=A0difficult.

=C2=A0 =C2=A0The ma= in reason for this disjoint operation scenario is that most
=C2=A0 =C2=A0equipment is developed= with specific task requirements in mind,
=C2=A0 =C2=A0rather than interop= erability of the varied equipment types. =C2=A0For
=C2=A0 =C2=A0example, the operating conditio= ns experienced by high altitude
=C2=A0 =C2=A0security equipment = is significantly different from that used in
=C2=A0 =C2=A0desert conditions. =C2=A0Similarly, s= earch and rescue operations equipment
=C2=A0 =C2=A0used in case of fir= e rescue has different requirements than flood
TW> "inter-operation"?
=C2=A0 =C2=A0relief equipment. = =C2=A0Furthermore, interoperation of equipment with
=C2=A0 =C2=A0telecommunication e= quipment was not an expected outcome or in some
=C2=A0 =C2=A0scenarios this may not even be des= irable.

=C2=A0 =C2=A0Currently, field networks operate = with a fixed Network Operations
=C2=A0 =C2=A0Center (NOC) that physically manages the configura= tion and evaluation
=C2=A0 =C2=A0of all field device= s. =C2=A0Once configured, the devices might be deployed



Ersue, et al. =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 [Page 18]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0Constrained Man= agement: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0July 2014


=C2=A0 =C2=A0in fixed or mobile scenarios. =C2=A0Any configura= tion changes required
=C2=A0 =C2=A0would need to be ap= propriately encrypted and authenticated to prevent
=C2=A0 =C2=A0unauthorized access.

=C2=A0 =C2=A0Hierar= chical management of devices is a common requirement in such
=C2=A0 =C2=A0scenarios since local= managers or operators may need to respond to
=C2=A0 =C2=A0changing conditions= within their purview. =C2=A0The level of configuration
=C2=A0 =C2=A0management available at ea= ch hierarchy must also be closely governed.

=C2=A0 =C2=A0Since many field operation devices= are used in hostile environments,
=C2=A0 =C2=A0a high failure and disconnection rate should be= tolerated by the NMS,
=C2=A0 =C2=A0which must also be = able to deal with multiple gateways and disjoint
=C2=A0 =C2=A0management protocols.

TW> typo: invlov= ing
TW> requiring= the interoperation -> requiring inter-operation?

=C2=A0 =C2=A0Multi-= national field operations invloving search, rescue and security
=C2=A0 =C2=A0are becoming incre= asingly common, requiring the interoperation of a
=C2=A0 =C2=A0diverse set of equi= pment designed with different operating conditions
=C2=A0 =C2=A0in mind. =C2=A0Furthermore, dif= ferent intra- and inter-governmental
=C2=A0 =C2=A0agencies are likely= to have a different set of standards, best
=C2=A0 =C2=A0practices, rules and regulation, and i= mplementation approaches that
=C2=A0 =C2=A0may contradict or c= onflict with each other. =C2=A0The NMS should be able
=C2=A0 =C2=A0to detect these and handle t= hem in an acceptable manner, which may
=C2=A0 =C2=A0require human inter= vention.

=
4. =C2=A0IANA Consideratio= ns

=C2=A0 =C2=A0This document does not introduce any ne= w code-points or namespaces
=C2=A0 =C2=A0for registration with IANA.

=C2=A0 =C2=A0Note to RFC Editor: this section m= ay be removed on publication as an
=C2=A0 =C2=A0RFC.

5. =C2=A0Security Considerations

=C2=A0 =C2=A0This document discusses use cases = for Management of Networks with
=C2=A0 =C2=A0Constrained Devices= . =C2=A0The security considerations described
=C2=A0 =C2=A0throughout the companion document = [COM-REQ] apply here as well.

6. =C2=A0Contributors

=C2=A0 =C2=A0Following persons made significant contribution= s to and reviewed this
=C2=A0 =C2=A0document:

=C2=A0 =C2=A0o =C2=A0Ulrich Herberg (Fujitsu= Laboratories of America) contributed the
=C2=A0 =C2=A0 =C2=A0 Section 3.9= on Community Network Applications.

=C2=A0 =C2=A0o =C2=A0Peter van der Stok contributed to Section 3.6 on Buil= ding
=C2=A0 =C2=A0 =C2=A0 Automation.=



Ersue, et al. =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 19]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0= Constrained Management: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0July 20= 14


=C2=A0 =C2=A0o =C2=A0Zhen Cao contributed to Section 2.2 Cellu= lar Access Technologies.

=C2=A0 =C2=A0o =C2=A0Gilman Tolle contributed t= he Section 3.4 on Automated Metering
=C2=A0 =C2=A0 =C2=A0 Infrastructure.

=C2=A0 =C2=A0o =C2=A0James Nguyen and Ulrich He= rberg contributed to Section 3.10 on
=C2=A0 =C2=A0 =C2=A0 Military operations.

7. =C2=A0Acknowledgments

=C2=A0 =C2=A0Following persons reviewed and provided valu= able comments to
=C2=A0 =C2=A0different versions = of this document:
=C2=A0 =C2=A0Domi= nique Barthel, Carsten Bormann, Zhen Cao, Benoit Claise, Bert
=C2=A0 =C2=A0Greevenbosch, Ulric= h Herberg, James Nguyen, Zach Shelby, and Peter
=C2=A0 =C2=A0van der Stok.

=C2=A0 =C2=A0The ed= itors would like to thank the reviewers and the participants on
=C2=A0 =C2=A0the Coman maillist= for their valuable contributions and comments.

8. =C2=A0Informative References

=C2=A0 =C2=A0[RFC6130] =C2=A0Clausen, T., Dearlove= , C., and J. Dean, "Mobile Ad Hoc
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Network (MANET) Neighborhood Discovery Protocol (NHDP)&qu= ot;,
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC 6130, April 2011.

=C2=A0 =C2=A0[RFC6568] =C2=A0Kim, E., Kaspar, D., an= d JP. Vasseur, "Design and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Application Sp= aces for IPv6 over Low-Power Wireless
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Personal Area Networks (6LoWPANs)", RFC 6568, April = 2012.

=C2=A0 =C2=A0[RFC6779] =C2=A0= Herberg, U., Cole, R., and I. Chakeres, "Definition of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Managed Objects for the Neighborhood Discovery Protocol&q= uot;,
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC 6779, October 2012.

=C2=A0 =C2=A0[RFC6988] =C2=A0Quittek, J., Chand= ramouli, M., Winter, R., Dietz, T., and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 B. Cla= ise, "Requirements for Energy Management", RFC 6988,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 September 2013.

= =C2=A0 =C2=A0[RFC7181] =C2=A0Clausen, T., Dearlove, C., Jacquet, P., and U.= Herberg,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 "The Optimized Link State Routing Protocol Version 2= ", RFC
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7181, April 2014.

=C2=A0 =C2=A0[RFC7228] =C2=A0Bormann, C., Ersue= , M., and A. Keranen, "Terminology for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Co= nstrained-Node Networks", RFC 7228, May 2014.






Er= sue, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 201= 5 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 20]
=0C
Internet-Draft =C2= =A0 =C2=A0 =C2=A0Constrained Management: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0July 2014
=

=C2=A0 =C2=A0[I-D.i= etf-eman-framework]
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Claise, B., Schoening, B.,= and J. Quittek, "Energy
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Management Framework", draft-ietf-eman-framework-19 (wor= k
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in progress), April 2014.

=C2=A0 =C2=A0[COM-REQ] =C2=A0Ersue, M., Romascanu, D= ., and J. Schoenwaelder,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Management of N= etworks with Constrained Devices: Problem
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Statement and Requirements", draft-ietf-opsawg-coman= -
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 probstate-reqs (work in progress), February= 2014.

Appendix A. =C2=A0Change Log
<= font face=3D"courier new, monospace">
A.1. =C2=A0draft-ietf-opsawg-coman-use-cases-01 - dra= ft-ietf-opsawg-coman-
=C2=A0 =C2=A0 =C2=A0 use-cases-0= 2

<= div>=C2=A0 =C2=A0o =C2=A0Renamed Mobi= le Access Technologies section to Cellular Access
=C2=A0 =C2=A0 =C2=A0 Technologie= s

<= div>=C2=A0 =C2=A0o =C2=A0Changed refe= rences to mobile access technologies to now read
=C2=A0 =C2=A0 =C2=A0 cellular ac= cess technologies.
<= br>
=C2=A0 =C2=A0o = =C2=A0Added text to the introduction to point out that the list of use
=C2=A0 =C2=A0 =C2=A0 cases is no= t exhaustive since others unknown to the authors might
=C2=A0 =C2=A0 =C2=A0 exist.
=

=C2=A0 =C2=A0o =C2= =A0Updated references to take into account RFCs that have been now
=C2=A0 =C2=A0 =C2=A0 publish= ed.

=C2=A0 =C2=A0o =C2= =A0Updated Environmental Monitoring section to make it clear that in=
=C2=A0 =C2=A0 =C2=A0 some = scenarios it may not be prudent to repair devices.

=C2=A0 =C2=A0o =C2=A0Added clarification in Inf= rastructure Monitoring section that
=C2=A0 =C2=A0 =C2=A0 reliable communication is achieved via= application layer
=C2=A0 =C2=A0 =C2=A0 transaction= s

<= div>=C2=A0 =C2=A0o =C2=A0Removed refe= rence to Energy Devices from Energy Management
=C2=A0 =C2=A0 =C2=A0 section, in= stead labeling them as devices within the context of
=C2=A0 =C2=A0 =C2=A0 energy management.

=C2=A0 =C2=A0o =C2= =A0Reduced descriptive content in Energy Management section.

=C2=A0 =C2=A0o =C2=A0Rewrote text in Energy Man= agement section to highlight management
=C2=A0 =C2=A0 =C2=A0 characteris= tics of Smart Meter and AMI networks.

=C2=A0 =C2=A0o =C2=A0Added text regarding timely delivery of information= , and related
=C2=A0 =C2=A0 =C2=A0 management = system characteristic, to the Medical Applications
=C2=A0 =C2=A0 =C2=A0 section




Ersue, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires= January 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 21]=
=0C
Internet-Draft =C2= =A0 =C2=A0 =C2=A0Constrained Management: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0July 2014
=

=C2=A0 =C2=A0o =C2= =A0Changed subnets to network segment in Building Automation section.

=C2=A0 =C2=A0o =C2=A0Changed structure t= o infrastructure in Building Automation
=C2=A0 =C2=A0 =C2=A0 section, an= d added text to highlight associated deployment
=C2=A0 =C2=A0 =C2=A0 difficulties.
=

=C2=A0 =C2=A0o =C2= =A0Removed Trickle timer as example of common values to be set in
=C2=A0 =C2=A0 =C2=A0 Building= Automation section.

=C2=A0 =C2=A0o =C2=A0Added text regarding the p= ossible availability of outsourced and
=C2=A0 =C2=A0 =C2=A0 cloud based management systems for = Home Automation.

=C2=A0 =C2=A0o =C2=A0Added text to Transport Ap= plications section to highlight the
=C2=A0 =C2=A0 =C2=A0 requirement of IT infrastructure for s= uch applications to function
=C2=A0 =C2=A0 =C2=A0 on top of.<= /font>

=C2=A0 =C2=A0o =C2=A0Merged the Tra= nsport Applications and Vehicular Networks section
=C2=A0 =C2=A0 =C2=A0 together. = =C2=A0Following changes to the Vehicular Networks section
= =C2=A0 =C2=A0 =C2=A0 were merged back= into Transport Applications

=C2=A0 =C2=A0 =C2=A0 * =C2=A0Replaced wireless = last hops with wireless access to vehicles in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Vehicular Net= works.

=C2=A0 =C2=A0 =C2=A0 * =C2=A0Expanded proprieta= ry systems to "systems relying on a specific
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Management = Topology Option, as described in [COM-REQ]." within
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Vehicular Networks section.

=C2= =A0 =C2=A0 =C2=A0 * =C2=A0Added text regarding mobility patterns to Vehicul= ar Networks.

=C2=A0 =C2=A0o =C2=A0Changed the Military Opera= tions use case to Field Operations and
=C2=A0 =C2=A0 =C2=A0 edited the text to be suitable to s= uch scenarios.

A.2. =C2=A0draft-ietf-opsawg-coman-use-cases-00= - draft-ietf-opsawg-coman-
=C2=A0 =C2=A0 =C2=A0 use-cases-01

=C2=A0 =C2=A0o =C2=A0Reordered some use cases t= o improve the flow.
=
=C2=A0 =C2=A0o =C2=A0Added "= ;Vehicular Networks".

=C2=A0 = =C2=A0o =C2=A0Shortened the Military Operations use case.

=C2=A0 =C2=A0o =C2=A0Started adding substance t= o the security considerations section.









Ersue, et al. =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 22]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0= Constrained Management: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0July 20= 14


A.3. =C2=A0draft-ersue-constrained-mgmt-03 - draft-ersue-opsaw= g-coman-use-
=C2=A0 =C2=A0 =C2=A0 cases-00

= =C2=A0 =C2=A0o =C2=A0Reduced the term= inology section for terminology addressed in the
=C2=A0 =C2=A0 =C2=A0 LWIG and Co= man Requirements drafts. =C2=A0Referenced the other drafts.

=C2=A0 =C2=A0o =C2=A0Checked and aligned all termi= nology against the LWIG terminology
=C2=A0 =C2=A0 =C2=A0 draft.

=C2=A0 =C2=A0o =C2=A0Spent some effort = to resolve the intersection between the
=C2=A0 =C2=A0 =C2=A0 Industrial = Application, Home Automation and Building Automation
=C2=A0 =C2=A0 =C2=A0 use cases.

=C2=A0 =C2=A0o =C2= =A0Moved section section 3. =C2=A0Use Cases from the companion document
=C2=A0 =C2=A0 =C2=A0 [C= OM-REQ] to this draft.

=C2=A0 =C2=A0o =C2=A0Reformulation of some text part= s for more clarity.
=
A.4. =C2=A0draft-ersue-constrain= ed-mgmt-02-03

=C2=A0 =C2=A0o =C2=A0= Extended the terminology section and removed some of the
=C2=A0 =C2=A0 =C2=A0 terminology= addressed in the new LWIG terminology draft.
=C2=A0 =C2=A0 =C2=A0 Referenced the LWIG termin= ology draft.

=C2=A0 =C2=A0o =C2= =A0Moved Section 1.3. on Constrained Device Classes to the new LWIG<= /div>
=C2=A0 =C2=A0 =C2=A0 termin= ology draft.

=C2=A0 =C2=A0o =C2= =A0Class of networks considering the different type of radio and
=C2=A0 =C2=A0 =C2=A0 communica= tion technologies in use and dimensions extended.

=C2=A0 =C2=A0o =C2=A0Extended the Problem State= ment in Section 2. following the
=C2=A0 =C2=A0 =C2=A0 requirements listed in Section 4.<= /div>

=C2=A0 =C2=A0o =C2=A0Following requirements, wh= ich belong together and can be realized
=C2=A0 =C2=A0 =C2=A0 with similar or same kind of solut= ions, have been merged.

=C2=A0 =C2=A0 =C2=A0 * =C2=A0Distributed Manage= ment and Peer Configuration,

=C2=A0 =C2=A0 =C2=A0 * =C2=A0Dev= ice status monitoring and Neighbor-monitoring,

=C2=A0 =C2=A0 =C2=A0 * =C2=A0Passive Monitoring and Reactive M= onitoring,

=C2=A0 =C2=A0 =C2=A0 * =C2=A0Event-driven self-= management - Self-healing and Periodic self-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0management,

=C2=A0 =C2=A0 =C2=A0 * =C2=A0Authentication of = management systems and Authentication of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0managed devices,



Ersue, et al. =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 [Page 23]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0Constrained = Management: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0July 2014


=C2=A0 =C2=A0 =C2=A0 * =C2=A0Access control on devices and Acc= ess control on management
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0systems,

=C2=A0 =C2=A0 =C2=A0 * = =C2=A0Management of Energy Resources and Data models for energy
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0management,

<= /font>
=C2=A0 =C2=A0 =C2=A0= * =C2=A0Software distribution (group-based firmware update) and Group-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0based provisioning.

=C2=A0 =C2= =A0o =C2=A0Deleted the empty section on the gaps in network management
=C2=A0 =C2=A0 =C2=A0 standards, = as it will be written in a separate draft.

=C2=A0 =C2=A0o =C2=A0Added links to mentioned external pages.

=C2=A0 =C2=A0o =C2=A0Added text on OMA M2M Devi= ce Classification in appendix.

A.5. =C2=A0draft-ersue-constrain= ed-mgmt-01-02

=C2=A0 =C2=A0o =C2=A0= Extended the terminology section.

=C2=A0 =C2=A0o =C2=A0Added additional text for = the use cases concerning deployment
=C2=A0 =C2=A0 =C2=A0 type, network topology in use, network= size, network capabilities,
=C2=A0 =C2=A0 =C2=A0 radio techn= ology, etc.

=C2=A0 =C2=A0o =C2=A0Ad= ded examples for device classes in a use case.

=C2=A0 =C2=A0o =C2=A0Added additional text prov= ided by Cao Zhen (China Mobile) for
=C2=A0 =C2=A0 =C2=A0 Mobile Applications and by Peter van d= er Stok for Building
=C2=A0 =C2=A0 =C2=A0 Automation.=

=C2=A0 =C2=A0o =C2=A0Added the new= use cases 'Advanced Metering Infrastructure' and
=C2=A0 =C2=A0 =C2=A0 'MANET = Concept of Operations in Military'.

=C2=A0 =C2=A0o =C2=A0Added the section 'Managing the Constrainedne= ss of a Device or
=C2=A0 =C2=A0 =C2=A0 Network'= ; discussing the needs of very constrained devices.

=C2=A0 =C2=A0o =C2=A0Added a note that the requirements in= [COM-REQ] need to be seen as
=C2=A0 =C2=A0 =C2=A0 standalone = requirements and the current document does not
=C2=A0 =C2=A0 =C2=A0 recommend any profile of r= equirements.

=C2=A0 =C2=A0o =C2= =A0Added a section in [COM-REQ] for the detailed requirements on
=C2=A0 =C2=A0 =C2=A0 constrain= ed management matched to management tasks like fault,
=C2=A0 =C2=A0 =C2=A0 monitoring,= configuration management, Security and Access Control,
=C2=A0 =C2=A0 =C2=A0 Energy Management,= etc.

=C2=A0 =C2=A0o =C2= =A0Solved nits and added references.




Er= sue, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 201= 5 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 24]
=0C
Internet-Draft =C2= =A0 =C2=A0 =C2=A0Constrained Management: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0July 2014
=

=C2=A0 =C2=A0o =C2= =A0Added Appendix B on the work in related research projects.
<= div>
A.6. =C2=A0draft-ersue-constrained-mgmt-00-01

=C2=A0 =C2=A0o =C2=A0Splitted the section on &#= 39;Networks of Constrained Devices' into the
=C2=A0 =C2=A0 =C2=A0 sections 'Network Top= ology Options' and 'Management Topology
=C2=A0 =C2=A0 =C2=A0 Options'= ;.

=
=C2=A0 =C2=A0o =C2=A0Added the u= se case 'Community Network Applications' and 'Mobile
=C2=A0 =C2=A0 =C2=A0 Application= s'.

<= /div>
=C2=A0 =C2=A0o =C2=A0Provid= ed a Contributors section.

=C2=A0 =C2=A0o =C2=A0Extended the section on &#= 39;Medical Applications'.

=C2=A0 =C2=A0o =C2=A0Solved nits= and added references.

Authors'= Addresses

=C2=A0 =C2=A0Mehmet Ersue (editor)
=
=C2=A0 =C2=A0Nokia Networks

=C2=A0 =C2=A0Email:= mehmet.ersue@nsn.com


=C2=A0 =C2=A0Dan Ro= mascanu
=C2=A0 =C2= =A0Avaya

=
=C2=A0 =C2=A0Email: dromasca@avaya.com


=C2=A0 =C2=A0Juergen Schoenwaelder
=C2=A0 =C2=A0Jacobs University Bremen



=C2=A0 =C2=A0Anuj Sehgal
=C2=A0 =C2=A0Jacobs University Bremen

=C2=A0 =C2=A0Email: s.anuj@jacobs-university.de










Ersue, et al. =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 [Page 25]

--001a11364faccbbad205002c7345-- From nobody Sat Aug 9 03:58:58 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7EA41B279B for ; Sat, 9 Aug 2014 03:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 OctifQd5byvZ for ; Sat, 9 Aug 2014 03:58:51 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89EE51A0944 for ; Sat, 9 Aug 2014 03:58:50 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s79Awiaa001927; Sat, 9 Aug 2014 11:58:44 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s79Awgm6001869 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 9 Aug 2014 11:58:43 +0100 From: "Adrian Farrel" To: "'Tom Taylor'" , References: <063301cfa832$aaa8e3e0$fffaaba0$@olddog.co.uk> <53E5721F.3030701@gmail.com> In-Reply-To: <53E5721F.3030701@gmail.com> Date: Sat, 9 Aug 2014 11:58:41 +0100 Message-ID: <04cc01cfb3c0$e2195f00$a64c1d00$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHma4SOXq3idnqGnmfbUZYYt9W/0ALHmWmDm4RsD1A= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20868.006 X-TM-AS-Result: No--20.108-10.0-31-10 X-imss-scan-details: No--20.108-10.0-31-10 X-TMASE-MatchedRID: 6otD/cJAac1fsB4HYR80ZuYAh37ZsBDC0nXvwjW2mSW638ZUY6gSdyF3 3XCcOZqHFChugkaPtsrbOOxEG5SsnaX2s5Nec6ilttAWxuM5sl41G/3YRqERwdJgDNnoqapaNQH StcyHQlrWYeAcryogDRM1yubxgLEE1xQ2OgXti5XgSmtKVCYWoBmyTBaqiJvcxSZxKZrfThOFDj mu9JFekOj8FFpGu78xpX1c04mAgVH5V22kT3/19uyNEc7z2JzC3E5VFJRbiIRrE1c4mB5UmnMSv PRTWdjY04SxjUhEWr3q/6N6YTIQe2FqPXSLpNdAQr2qXCJMSV91k+gP1XamtJsoi2XrUn/JyeMt MD9QOgDGlDvsLUDW2o6HM5rqDwqtlExlQIQeRG0= Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/4POx-L5syEzheIUfJyeXNXpAGKg Cc: draft-farrkingel-pce-abno-architecture@tools.ietf.org, 'Quintin zhao' Subject: Re: [OPSAWG] Call for review draft-farrkingel-pce-abno-architecture X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 10:58:56 -0000 Thanks Tom, Useful to have an extra pair of eyes. Our intent in writing the document was to show that most (but not all) building blocks are in place and just need to be arranged in the right order. We were a little frustrated to see folk out in the woods trying to invent wheels. Somewhat to the authors' surprise (but not to our objection) we have become aware of two service providers who have implemented experimental network management systems based on this architecture. One of them did a public demo of an integrated packet/optical system using hardware from a packet vendor and an optical vendor. We are also aware of a third service provider planning to resource an experimental platform also based on the architecture. Additionally, there are some academic papers indicating university researchers are putting together systems with this architecture in mind. Cheers, Adrian PS Editorial nits are always welcome. > -----Original Message----- > From: Tom Taylor [mailto:tom.taylor.stds@gmail.com] > Sent: 09 August 2014 01:58 > To: adrian@olddog.co.uk; opsawg@ietf.org > Cc: draft-farrkingel-pce-abno-architecture@tools.ietf.org; 'Quintin zhao' > Subject: Re: [OPSAWG] Call for review draft-farrkingel-pce-abno-architecture > > The document looks reasonable, but I have no idea how much it fits with > current product plans. I can see potential for SFC to be an application > of the system. OpenV6/SUPA could be a part of it. > > There are editorials and nits, but I figured it was a bit early to call > those out. > > Tom Taylor > > On 25/07/2014 2:02 PM, Adrian Farrel wrote: > > Hi, > > > > The authors of draft-farrkingel-pce-abno-architecture are in the process of > > requesting AD-sponsored publication of draft-farrkingel-pce-abno-architecture > > > > This I-D is a bit of an architecture and a bit an applicability statement. It is > > also significantly about how to build and operate networks. > > > > The last call will obviously pop out sometime, but it would be nice to have > > review comments before then. > > > > Thanks, > > Adrian > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > > From nobody Sat Aug 9 05:43:15 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4B351A03A1 for ; Sat, 9 Aug 2014 05:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 lF1uDBjDiqZm for ; Sat, 9 Aug 2014 05:42:22 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC4101A0394 for ; Sat, 9 Aug 2014 05:42:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12375; q=dns/txt; s=iport; t=1407588142; x=1408797742; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=f+gNV5t0wSTuHvCu2c6q120GgQaQ8sCyCB5Rump8LGg=; b=DtLD/WolbSqI8ma/l1YuOzQnsotr05DbEiTp2T6MWLRI4MzDfmYT46/T uJYqrxoWOE92aWUZ+9wfFk9Zac4CKXXnh6Ge47Gg6JQCMv+ve8bfizT8d hKzprP4fLPhSjBV86AnbBtXLnC/EzwDTDrOZXcV4tgyGb57uI6jAJOKtu c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAPsV5lOtJV2Y/2dsb2JhbABZgkdGUk3LOIFZAQmGdVMBgQsWd4QDAQEBBAEBAWsLEAIBCBEDAQIoBycLFAkIAgQOBQmIOQ3FFReOewEBPg0EBgEGgymBHQWGD4RQhCeCE4QlhnGBV5Mkg1xsAYEN X-IronPort-AV: E=Sophos;i="5.01,832,1400025600"; d="scan'208,217";a="346361442" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 09 Aug 2014 12:42:20 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s79CgKmC030850 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 9 Aug 2014 12:42:20 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.109]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Sat, 9 Aug 2014 07:42:19 -0500 From: "Pascal Thubert (pthubert)" To: "Raghuram Sudhaakar (rsudhaak)" Thread-Topic: [OPSAWG] Coman Drafts v02 Thread-Index: AQHPszQS4Abi5UfSxEGyzCCjcnfBlZvIOE5W Date: Sat, 9 Aug 2014 12:42:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_FDF761D6A96B41929FF651224F9123FAciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/0esbRxQc2xeZoRTMD38C_zZKqBU X-Mailman-Approved-At: Sat, 09 Aug 2014 05:43:14 -0700 Cc: "opsawg@ietf.org" , "P.Zand@utwente.nl" Subject: Re: [OPSAWG] Coman Drafts v02 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 12:42:25 -0000 --_000_FDF761D6A96B41929FF651224F9123FAciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all: On coman use cases 02 Really excellent work! Fits my own understanding in every scenario I am fam= iliar with. Issues: The security section is absent yet security concerns are correctly discusse= d throughout. As it goes, security concerns for management flows are correc= tly expressed but often apply to many other use cases where the question is= not discussed. Maybe a table in the security section could summarize case = by case who manages the network and the devices, and what kind of security = is in place. There is a great discussion on light bulbs commissioning in the building se= ction. I was actually missing that same discussion in the factory automatio= n section. Who manages the network during the factory setup/commissioning? Specific th= reats are associated to the transition to operational/trusted, and the proc= ess of handover exists in multiple scenarios. Thanks again for this great document. Really useful, and I support its publ= ication. Pascal Le 8 ao=FBt 2014 =E0 20:10, "Raghuram Sudhaakar (rsudhaak)" > a =E9crit : Dear ML users, I read both the documents your mentioned below. Both are well written and a= ddress their scope quite well. Only a few minor typos here and there. On a general note, both these documents do not address the actual managemen= t protocol. It seems to me that these documents will typically be reference= d by some other drafts (like our draft-ietf-6tisch-coap) that specify the p= rotocol. -raghuram From: Thomas Watteyne > Date: Tuesday, August 5, 2014 at 11:15 PM To: raghuram sudhaakar > Subject: Fwd: [6lo] Fwd: [OPSAWG] Coman Drafts v02 Raghuram, These drafts, which introduce the use cases and problem statement for const= rained management, are very related to the CoAP draft you co-authored. I be= lieve it would be very useful if you could review them and submit your revi= ew to the OPSAWG ML, as detailed below. Would that be possible? Thomas ---------- Forwarded message ---------- From: Thomas Watteyne > Date: Sat, Jul 26, 2014 at 10:32 PM Subject: Fwd: [6lo] Fwd: [OPSAWG] Coman Drafts v02 To: "6tisch@ietf.org" <6tisch@ietf.org> All, The OPSWAG chairs have kindly agreed to extend the WGLC period for the foll= owing drafts [1] to August 11: http://tools.ietf.org/html/draft-ietf-opsawg-coman-use-cases-02 http://tools.ietf.org/html/draft-ietf-opsawg-coman-probstate-reqs-01 Pascal and myself believe those two drafts to be important for the ongoing = work on managing a 6TiSCH network, and directly in line with e.g. draft-iet= f-6tisch-coap. We therefore ask authors of draft-ietf-6tisch-coap, draft-ie= tf-6tisch-6top-interface, and any other 6TiSCH WG member to send reviews of= this document to OPSAWG ML [2]. Thomas [1] http://www.ietf.org/mail-archive/web/6tisch/current/msg02465.html [2] https://www.ietf.org/mailman/listinfo/opsawg ---------- Forwarded message ---------- From: Warren Kumari > Date: Fri, Jul 25, 2014 at 3:03 PM Subject: Re: [coman] FW: [OPSAWG] Coman Drafts v02 To: "Ersue, Mehmet (NSN - DE/Munich)" > Cc: "coman@ietf.org" >, "opsawg-chairs@tools.ietf.org" > Hi all. With apologies to the authors... The chairs of 6LoWPAN and 6TSCH have asked if we can delay the end of this WGLC so that their communities can review and comment on these 2 documents. As we have not received very much feedback, this seems relevant to their WGs, and they asked nicely, we have decided to extend the deadline to August 11th. Now, many folk will be traveling back to their homes over the next few days - this probably means a few, or many hours on an airplane. May I suggest copying these documents on your computer or reading device of choice and reviewing the documents on the way home? Thanks, W _______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo --_000_FDF761D6A96B41929FF651224F9123FAciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear all:

On coman use cases 02

Really excellent work! Fits my own understanding in every scenario I a= m familiar with.

Issues:

The security section is absent yet security concerns are correctly dis= cussed throughout. As it goes, security concerns for management flows are c= orrectly expressed but often apply to many other use cases where the questi= on is not discussed. Maybe a table in the security section could summarize case by case who manages the netwo= rk and the devices, and what kind of security is in place.

There is a great discussion on light bulbs commissioning in the buildi= ng section. I was actually missing that same discussion in the factory auto= mation section. 

Who manages the network during the factory setup/commissioning? Specif= ic threats are associated to the transition to operational/trusted, and the= process of handover exists in multiple scenarios.

Thanks again for this great document. Really useful, and I support its= publication.

Pascal

Le 8 ao=FBt 2014 =E0 20:10, "Raghuram Sudhaakar (rsudhaak)" <<= a href=3D"mailto:rsudhaak@cisco.com">rsudhaak@cisco.com> a =E9crit&n= bsp;:

Dear ML users,
I read both the documents your mentioned below. Both are well written = and address their scope quite well. 
Only a few minor typos here and there.

On a general note, both these documents do not address the actual mana= gement protocol. It seems to me that these documents will typically be refe= renced by some other drafts (like our draft-ietf-6tisch-coap) that spe= cify the protocol. 


-raghuram

From: Thomas Watteyne <watteyne@eecs.berkeley.edu> Date: Tuesday, August 5, 2014 at 11= :15 PM
To: raghuram sudhaakar <rsudhaak@cisco.com>
Subject: Fwd: [6lo] Fwd: [OPSAWG] C= oman Drafts v02

Raghuram,
These drafts, which introduce the use cases and problem statement for = constrained management, are very related to the CoAP draft you co-authored.= I believe it would be very useful if you could review them and submit your= review to the OPSAWG ML, as detailed below. Would that be possible?
Thomas

---------- Forwarded message ----------
From: Thomas Watteyne &= lt;watteyne@eecs.berkeley.edu= >
Date: Sat, Jul 26, 2014 at 10:32 PM
Subject: Fwd: [6lo] Fwd: [OPSAWG] Coman Drafts v02
To: "6tisch@ietf.org" <= 6tisch@ietf.org>


All,

The OPSWAG chairs have kindly agreed to extend the WGLC period for the= following drafts [1] to August 11:


Pascal and myself believe those two drafts to be important for the ong= oing work on managing a 6TiSCH network, and directly in line with e.g. = ;draft-ietf-6tisch-coap. We therefore ask authors of draft-ietf-6tisch= -coap, draft-ietf-6tisch-6top-interface, and any other 6TiSCH WG member to send reviews of this document to OPSAWG ML [= 2].

Thomas

[2] https://www.ietf.org/mailman/listinfo/opsawg


---------- Forwarded message ----------
From: Warren Kumari <warren@kumari.net>
Date: Fri, Jul 25, 2014 at 3:03 PM
Subject: Re: [coman] FW: [OPSAWG] Coman Drafts v02
To: "Ersue, Mehmet (NSN - DE/Munich)" <mehmet.ersue@nsn.com>
Cc: "coman@ietf.or= g" <coman@i= etf.org>, "opsawg-chairs@tools.ietf.org"
<opsaw= g-chairs@tools.ietf.org>


Hi all.

With apologies to the authors...

The chairs of 6LoWPAN and 6TSCH have asked if we can delay the end of
this WGLC so that their communities can review and comment on these 2
documents.

As we have not received very much feedback, this seems relevant to
their WGs, and they asked nicely, we have decided to extend the
deadline to August 11th.

Now, many folk will be traveling back to their homes over the next few
days - this probably means a few, or many hours on an airplane. May I
suggest copying these documents on your computer or reading device of
choice and reviewing the documents on the way home?

Thanks,
W

_______________________________________________
6lo mailing list
6lo@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/6lo


--_000_FDF761D6A96B41929FF651224F9123FAciscocom_-- From nobody Sun Aug 10 00:18:38 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34AD91A067E for ; Sun, 10 Aug 2014 00:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.433 X-Spam-Level: **** X-Spam-Status: No, score=4.433 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, MANGLED_TOOL=2.3, SPF_PASS=-0.001, T_DKIM_INVALID=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 u5hY6Y8dnTzL for ; Sun, 10 Aug 2014 00:18:24 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F2B71A067D for ; Sun, 10 Aug 2014 00:18:24 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id y13so3187754pdi.17 for ; Sun, 10 Aug 2014 00:18:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=Dl1gWYUqh8tFXSqQkJkO8yNn+qjc5kzcc5QkR6wQIUI=; b=omJ+aHPZLSE1LurZ6Zhygm8DKvDCCCeqrqHpm9oeC66bCX5j26305QX9iNXUZzxUYs t0WlmP66TQC0+dFklJHlMPtwHhgrOf+yIzuTBHH0kY8qlWBrLU8BkiQTiDRuqOuip6Re +moRV2VivhRYYKpR+Xo1FPXobey9lh6qXVllsx8h8F2m/B7g1DsNfwmI24maAj5J9gRs K8AzXVsStYOrBu431YcwFInn0u81AScr+pvYZymgekelAky5DtrPN75zvIyl+Vu3Nm9B mqHg5g1VfpZqIPGOxPp5ziN9UqvLm5eSAb09ikYsIlD2gCtcoiuxFqjTCzcwqoh1yejx MuJg== X-Received: by 10.70.87.199 with SMTP id ba7mr1055242pdb.121.1407655103770; Sun, 10 Aug 2014 00:18:23 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.144.1 with HTTP; Sun, 10 Aug 2014 00:18:03 -0700 (PDT) From: Thomas Watteyne Date: Sun, 10 Aug 2014 00:18:03 -0700 X-Google-Sender-Auth: u20oBZOWssQbdoxitkEJrZ9OS30 Message-ID: To: opsawg Content-Type: multipart/alternative; boundary=001a11c20cc86d38ee0500413e08 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/UkfPoS89LN7Ci6dePwFVsrxUbJk Subject: [OPSAWG] Thomas' review of draft-ietf-opsawg-coman-probstate-reqs-02 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2014 07:18:36 -0000 --001a11c20cc86d38ee0500413e08 Content-Type: text/plain; charset=UTF-8 I was asked to do a detailed review of draft-ietf-opsawg-coman-probstate-reqs-02. This is related to my review of draft-ietf-opsawg-coman-use-cases-02, see http://www.ietf.org/mail-archive/web/opsawg/current/msg03486.html. Thomas GENERAL --------------- In general, I believe that this is a very useful document to have, and it provides a very clear list of "possible requirements". As such, it is not a traditional requirement document, as does not list requirements as MUSTs and SHOULDs, but rather gives a clear overview of what those requirements might be. In that sense, I would suggest to not use the term "Requirements" in the title, but maybe "potential requirements". I imagine that, when the time comes to design a management protocol for constrained devices (CoAP-based RESTCONF?), there will be a "formal" requirements draft for that full of MUSTs and SHOULDs? I would certainly recommend to indicate this clearly in the text. DETAILED --------------- please find my comments below, prefixed by "^TW>" Internet Engineering Task Force M. Ersue, Ed. Internet-Draft Nokia Networks Intended status: Informational D. Romascanu Expires: January 5, 2015 Avaya J. Schoenwaelder Jacobs University Bremen July 4, 2014 TW> you could put some newlines in the title Management of Networks with Constrained Devices: Problem Statement and Requirements draft-ietf-opsawg-coman-probstate-reqs-02 Abstract This document provides a problem statement, deployment and management topology options as well as the requirements for the management of TW> why not simple networks of constrained devices? networks where constrained devices are involved. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 5, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Ersue, et al. Expires January 5, 2015 [Page 1] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Network Types and Characteristics in Focus . . . . . . . 5 1.4. Constrained Device Deployment Options . . . . . . . . . . 9 1.5. Management Topology Options . . . . . . . . . . . . . . . 9 1.6. Managing the Constrainedness of a Device or Network . . . 10 1.7. Configuration and Monitoring Functionality Levels . . . . 13 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 14 3. Requirements on the Management of Networks with Constrained Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.1. Management Architecture/System . . . . . . . . . . . . . 17 3.2. Management protocols and data model . . . . . . . . . . . 21 3.3. Configuration management . . . . . . . . . . . . . . . . 24 3.4. Monitoring functionality . . . . . . . . . . . . . . . . 26 3.5. Self-management . . . . . . . . . . . . . . . . . . . . . 31 3.6. Security and Access Control . . . . . . . . . . . . . . . 31 3.7. Energy Management . . . . . . . . . . . . . . . . . . . . 33 3.8. SW Distribution . . . . . . . . . . . . . . . . . . . . . 35 3.9. Traffic management . . . . . . . . . . . . . . . . . . . 36 3.10. Transport Layer . . . . . . . . . . . . . . . . . . . . . 37 3.11. Implementation Requirements . . . . . . . . . . . . . . . 39 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 5. Security Considerations . . . . . . . . . . . . . . . . . . . 40 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 41 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41 8. Informative References . . . . . . . . . . . . . . . . . . . 41 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 42 A.1. draft-ietf-opsawg-coman-probstate-reqs-01 - draft-ietf- opsawg-coman-probstate-reqs-02 . . . . . . . . . . . . . 42 A.2. draft-ietf-opsawg-coman-probstate-reqs-00 - draft-ietf- opsawg-coman-probstate-reqs-01 . . . . . . . . . . . . . 42 A.3. draft-ersue-constrained-mgmt-03 - draft-ietf-opsawg- coman-probstate-reqs-00 . . . . . . . . . . . . . . . . . 43 A.4. draft-ersue-constrained-mgmt-02-03 . . . . . . . . . . . 43 A.5. draft-ersue-constrained-mgmt-01-02 . . . . . . . . . . . 44 A.6. draft-ersue-constrained-mgmt-00-01 . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 Ersue, et al. Expires January 5, 2015 [Page 2] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 1. Introduction 1.1. Overview Constrained devices, aka. sensor, smart object, or smart device, with limited CPU, memory, and power resources, can constitute a network. Such a network of constrained devices itself may be constrained or challenged, e.g., with unreliable or lossy channels, wireless technologies with limited bandwidth and a dynamic topology, needing TW> please add energy limitations the service of a gateway or proxy to connect to the Internet. In other scenarios, the constrained devices can be connected to a non- constrained network using off-the-shelf protocol stacks. Constrained devices might be in charge of gathering information in diverse settings including natural ecosystems, buildings, and TW> factories*,* and factories and send the information to one or more server stations. Constrained devices may also work under severe resource constraints such as limited battery and computing power, little memory and insufficient wireless bandwidth, and communication capabilities. A central entity, e.g., a base station or controlling server, might have more computational and communication resources and can act as a gateway between the constrained devices and the application logic in the core network. Today diverse size of constrained devices with different resources and capabilities are being connected. Mobile personal gadgets, building-automation devices, cellular phones, Machine-to-machine (M2M) devices, etc. benefit from interacting with other "things" in the near or somewhere in the Internet. With this the Internet of TW> reality build -> reality, built Things (IoT) becomes a reality build up of uniquely identifiable objects (things). And over the next decade, this could grow to TW> wow, that's 3 orders of magnitude more than people. I see wild predictions TW> going to tens of billions, but not thousands. Maybe "billions"? trillions of constrained devices and will greatly increase the Internet's size and scope. Network management is characterized by monitoring network status, detecting faults, and inferring their causes, setting network parameters, and carrying out actions to remove faults, maintain normal operation, and improve network efficiency and application performance. The traditional network monitoring application periodically collects information from a set of elements that are TW> to manage, to process [...] to present needed to manage, processes the data, and presents them to the network management users. Constrained devices, however, often have TW> please specify unreliable. I would say that they may be inter-connected TW> through unreliable links to one another, and to the Internet limited power, low transmission range, and might be unreliable. They might also need to work in hostile environments with advanced security requirements or need to be used in harsh environments for a long time without supervision. Due to such constraints, the TW> typo type*s* management of a network with constrained devices faces different type of challenges compared to the management of a traditional IP network. Ersue, et al. Expires January 5, 2015 [Page 3] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 The IETF has already done substantial standardization work to enable the communication in IP networks and to manage such networks as well as the manifold type of nodes in these networks [RFC6632]. However, the IETF so far has not developed any specific technologies for the management of constrained devices and the networks comprised by constrained devices. IP-based sensors or constrained devices in such an environment, i.e., devices with very limited memory and CPU TW> please add energy TW> use today*'s* resources, use today application-layer protocols in an ad-hoc manner to do simple resource management and monitoring. This document provides a problem statement and lists the requirements for the management of a network with constrained devices. Section 1.3 and Section 1.5 describe different topology options for the networking and management of constrained devices. Section 2 provides a problem statement on the issue of the management of networked constrained devices. Section 3 lists requirements on the management of applications and networks with constrained devices. Note that the requirements listed in Section 3 have been separated from the context in which they may appear. TW> Hmm. poipoi TODO Depending on the concrete circumstances, an implementer may decide to address a certain relevant subset of the requirements. The use cases in the context of networks with constrained devices can be found in the companion document [COM-USE]. 1.2. Terminology Concerning constrained devices and networks this document generally builds on the terminology defined in [RFC7228], where the terms Constrained Device, Constrained Network, etc. are defined. The following terms are additionally used throughout this documentation: AMI: (Advanced Metering Infrastructure) A system including hardware, software, and networking technologies that measures, collects, and analyzes energy usage, and communicates with a hierarchically deployed network of metering devices, either on request or on a schedule. C0: Class 0 constrained device as defined in Section 3. of [RFC7228]. C1: Class 1 constrained device as defined in Section 3. of [RFC7228]. C2: Class 2 constrained device as defined in Section 3. of [RFC7228]. Ersue, et al. Expires January 5, 2015 [Page 4] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 Network of Constrained Devices: A network to which constrained devices are connected that may or may not be a Constrained Network (see [RFC7228] for the definition of the term Constrained Network). M2M: (Machine to Machine) stands for the automatic data transfer between devices of different kind. In M2M scenarios a device (such as a sensor or meter) captures an event, which is relayed through a network (wireless, wired or hybrid) to an application. MANET: Mobile Ad-hoc Networks [RFC2501], a self-configuring and infrastructureless network of mobile devices connected by wireless technologies. Smart Grid: An electrical grid that uses communication technologies to gather and act on information in an automated fashion to improve the efficiency, reliability and sustainability of the production and distribution of electricity. Smart Meter: An electrical meter in the context of a Smart Grid. For a detailed discussion on the constrained networks as well as classes of constrained devices and their capabilities please see [RFC7228]. 1.3. Network Types and Characteristics in Focus In this document we differentiate following types of networks concerning their transport and communication technologies: (Note that a network in general can involve constrained and non- constrained devices.) 1. Wireline non-constrained networks, e.g., an Ethernet-LAN with constrained and non-constrained devices involved. 2. A combination of wireline and wireless networks, possibly with a multi-hop connectivity between constrained devices, utilizing dynamic routing in both the wireless and wireline portions of the network. Such networks usually support highly distributed applications with many nodes (e.g., environmental monitoring) and tend to deal with large-scale multipoint-to-point systems. Wireless Mesh Networks (WMN), as a specific variant, use off-the- shelf radio technology such as Wi-Fi, WiMax, and cellular 3G/4G. WMNs are reliable based on the redundancy they offer and have often a more planned deployment to provide dynamic and cost effective connectivity over a certain geographic area. Ersue, et al. Expires January 5, 2015 [Page 5] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 3. A combination of wireline and wireless networks with point-to- point or point-to-multipoint communication generally with single- TW> Hmm. The statement that IEEE802.15.4 networks are generally single-hop and TW> involve static routing contradicts the work done in ROLL and 6LoWPAN, 6lo TW> and 6TiSCH. Consider removing? hop connectivity to constrained devices, utilizing static routing over the wireless network. Such networks support short-range, point-to-point, low-data-rate, source-to-sink type of applications such as RFID systems, light switches, fire and smoke detectors, and home appliances. This type of networks also support confined short-range spaces such as a home, a factory, a building, or the human body. IEEE 802.15.1 (Bluetooth) and IEEE 802.15.4 are well-known examples of applicable standards for such networks. 4. Self-configuring infrastructureless networks of mobile devices (e.g., Mobile Adhoc networks, MANET) are a particular type of network connected by wireless technologies. Infrastructureless networks are mostly based on point-to-point communications of devices moving independently in any direction and changing the links to other devices frequently. Such devices do act as a router to forward traffic unrelated to their own use. Wireline non-constrained networks with constrained and non- constrained devices are mainly used for specific applications like Building Automation or Infrastructure Monitoring. Wireline and wireless networks with multi-hop or point-to-multipoint connectivity are used e.g., for environmental monitoring as well as transport and mobile applications. TW> add industrial applications for the latter (e.g. WirelessHART, 6TiSCH) Furthermore different network characteristics are determined by multiple dimensions: dynamicity of the topology, bandwidth, and loss rate. In the following, each dimension is explained, and networks in scope for this document are outlined: TW> I don't quite understand why this draft introduces so many terms, TW> networking topologies, etc. Can it not simply references a number of RFCs? TW> RFC5867, RFC5826, RFC5673, RFC5548 seem to give a good overview of LLN TW> use cases Network Topology: The topology of a network can be represented as a graph, with edges (i.e., links) and vertices (routers and hosts). Examples of different topologies include "star" topologies (with one central node and multiple nodes in one hop distance), tree structures (with each node having exactly one parent), directed acyclic graphs (with each node having one or more parents), clustered topologies (where one or more "cluster heads" are responsible for a certain area of the network), mesh topologies (fully distributed), etc. Management protocols may take advantage of specific network topologies, for example by distributing large-scale management tasks amongst multiple distributed network management stations (e.g., in TW> wouldn't cluster-based topologies not be a better fit here? case of a mesh topology), or by using a hierarchical management Ersue, et al. Expires January 5, 2015 [Page 6] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 approach (e.g., in case of a tree topology). These different management topology options are described in Section 1.6. Note that in certain network deployments, such as community ad hoc networks (see the use case "Community Network Applications" in [COM- USE]), the topology is not pre-planned, and thus may be unknown for management purposes. In other use cases, such as industrial applications (see the use case "Industrial Applications" in [COM- USE]), the topology may be designed in advance and therefore taken advantage of when managing the network. Dynamicity of the network topology: The dynamicity of the network topology determines the rate of change TW> per time -> as a function of time of the graph per time. Such changes can occur due to different factors, such as mobility of nodes (e.g., in MANETs or cellular networks), duty cycles (for low-power devices enabling their network interface only periodically to transmit or receive packets), or unstable links (in particular wireless links with strongly fluctuating link quality). Examples of different levels of dynamicity of the topology are Ethernets (with typically a very static topology) on the one side, and low-power and lossy networks (LLNs) on the other side. LLNs TW> LLN nodes often using duty cycles -> LLN nodes are often duty-cycled nodes often using duty cycles, operate on unreliable wireless links and are potentially mobile (e.g., for sensor networks). TW> "The more dynamic the topology is" The more the topology is dynamic, the more routing, transport and application layer protocols have to cope with interrupted connectivity and/or longer delays. For example, management protocols (with a given underlying transport protocol) that expect continuous session flows without changes of routes during a communication flow, may fail to operate. Networks with a very low dynamicity (e.g., Ethernet) with no or infrequent topology changes (e.g., less than once every 30 minutes), are in-scope of this document if they are used with constrained devices (see e.g., the use case "Building Automation" in [COM-USE]). Traffic flows: The traffic flow in a network determines from which sources data traffic is sent to which destinations in the network. Several different traffic flows are defined in [RFC7102], including "point- to-point" (P2P), "multipoint-to-point" (MP2P), and "point-to- multipoint" (P2MP) flows as: Ersue, et al. Expires January 5, 2015 [Page 7] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 TW> add dashes, i.e. "Point-To-Point"? o P2P: Point To Point. This refers to traffic exchanged between two nodes (regardless of the number of hops between the two nodes). o P2MP: Point-to-Multipoint traffic refers to traffic between one node and a set of nodes. This is similar to the P2MP concept in Multicast or MPLS Traffic Engineering. o MP2P: Multipoint-to-Point is used to describe a particular traffic pattern (e.g., MP2P flows collecting information from many nodes flowing inwards towards a collecting sink). If one of these traffic patterns is predominant in a network, protocols (routing, transport, application) may be optimized for the specific traffic flow. For example, in a network with a tree topology and MP2P traffic, collection tree protocols are efficient to send data from the leaves of the tree to the root of the tree, via each node's parent. Bandwidth: The bandwidth of the network is the amount of data that can be sent TW> per *unit of* time? per time between two communication end-points. It is usually determined by the link with the minimum bandwidth on the path from the source to the destination of data packets. The bandwidth in networks can range from a few Kilobytes per second (such as on some 802.15.4 link layers) to many Gigabytes per second (e.g., on fiber optics). For management purposes, the management protocol typically requires to send information between the network management station and the clients, for monitoring or control purposes. If the available bandwidth is insufficient for the management protocol, packets will be buffered and eventually dropped, and thus management is not possible with such a protocol. Networks without bandwidth limitation (e.g., Ethernet) are in-scope of this document if they are used with constrained devices (see the use case "Building Automation" in [COM-USE]). Loss rate: The loss rate (or bit error rate) is the number of bit errors divided by the total number of bits transmitted. For wired networks, loss rates are typically extremely low, e.g., around 10^-12 or 10^-13 for the latest 10Gbit Ethernet. For wireless networks, such as 802.15.4, the bit error rate can be as high as 10^-1 to 10^-0 in case of TW> missing space below interferences.Even when using a reliable transport protocol, Ersue, et al. Expires January 5, 2015 [Page 8] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 management operations can fail if the loss rate is too high, unless they are specifically designed to cope with these situations. 1.4. Constrained Device Deployment Options We differentiate following deployment options for the constrained devices: o A network of constrained devices that communicate with each other, o Constrained devices, which are connected directly to an IP network, o A network of constrained devices which communicate with a gateway or proxy with more communication capabilities acting possibly as a representative of the device to entities in the non-constrained network o Constrained devices, which are connected to the Internet or an IP network via a gateway/proxy o A hierarchy of constrained devices, e.g., a network of C0 devices connected to one or more C1 devices - connected to one or more C2 devices - connected to one or more gateways - connected to some application servers or NMS system o The possibility of device grouping (possibly in a dynamic manner) such as that the grouped devices can act as one logical device at the edge of the network and one device in this group can act as the managing entity 1.5. Management Topology Options We differentiate following options for the management of networks of constrained devices: o A network of constrained devices managed by one central manager. A logically centralized management might be implemented in a hierarchical fashion for scalability and robustness reasons. The manager and the management application logic might have a gateway/ proxy in between or might be on different nodes in different networks, e.g., management application running on a cloud server. o Distributed management, where a network of constrained devices is managed by more than one manager. Each manager controls a TW> subnet is a very loaded word. Maybe refer to "a portion of the network"? subnetwork and may communicate directly with other manager stations in a cooperative fashion. The distributed management may be weakly distributed, where functions are broken down and Ersue, et al. Expires January 5, 2015 [Page 9] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 assigned to many managers dynamically, or strongly distributed, where almost all managed things have embedded management functionality and explicit management disappears, which usually comes with the price that the strongly distributed management logic now needs to be managed. o Hierarchical management, where a hierarchy of networks with constrained devices are managed by the managers at their corresponding hierarchy level. I.e., each manager is responsible for managing the nodes in its sub-network. It passes information from its sub-network to its higher-level manager, and disseminates management functions received from the higher-level manager to its sub-network. Hierarchical management is essentially a scalability mechanism, logically the decision-making may be still centralized. poipoipoi 1.6. Managing the Constrainedness of a Device or Network The capabilities of a constrained device or network and the constrainedness thereof influence and have an impact on the requirements for the management of such network or devices. Note that the list below gives examples and does not claim completeness. A constrained device: TW> Strictly speaking, the radios are reliable, but the links are lossy TW> Maybe rephrase to "are connected by radio links which are unreliably in TW> nature" o might only support an unreliable radio with lossy links, i.e., the client and server of a management protocol need to gracefully TW> In my experience, packet corruption is caught at several layers throughout TW> the stack, and I doubt it is possible for the management protocol to TW> receive "incomplete" commands. Maybe I'm missing something. TW> With unreliable links, I believe the management protocol needs to TW> gracefully handle changes in latency, timeouts and retransmissions. ignore incomplete commands or repeat commands as necessary. o might only be able to go online from time-to-time, where it is reachable, i.e., a command might be necessary to repeat after a longer timeout or the timeout value with which one endpoint waits on a response needs to be sufficiently high. o might only be able to support a limited operating time (e.g., based on the available battery), or may behave as 'sleepy endpoints' setting their network links to a disconnected state during long periods of time i.e., the devices need to economize their energy usage with suitable mechanisms and the managing entity needs to monitor and control the energy status of the constrained devices it manages. o might only be able to support one simple communication protocol, i.e., the management protocol needs to be possible to downscale from constrained (C2) to very constrained (C0) devices with modular implementation and a very basic version with just a few simple commands. Ersue, et al. Expires January 5, 2015 [Page 10] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 o might only be able to support limited or no user and/or transport security, i.e., the management system needs to support a less- costly and simple but sufficiently secure authentication mechanism. o might not be able to support compression and decompression of exchanged data based on limited CPU power, i.e., an intermediary entity which is capable of data compression should be able to communicate with both, devices that support data compression (e.g., C2) and devices that do not support data compression (e.g., C1 and C0). o might only be able to support a simple encryption, i.e., it would be beneficial if the devices use cryptographic algorithms that are supported in hardware and the encryption used is efficient in TW> typo memeory -> memory terms of memeory and CPU usage. o might only be able to communicate with one single managing entity and cannot support the parallel access of many managing entities. o might depend on a self-configuration feature, i.e., the managing entity might not know all devices in a network and the device needs to be able to initiate connection setup for the device configuration. o might depend on self- or neighbor-monitoring feature, i.e., the managing entity might not be able to monitor all devices in a network continuously. o might only be able to communicate with its neighbors, i.e., the device should be able to get its configuration from a neighbor. o might only be able to support parsing of data models with limited size, i.e., the device data models need to be compact containing the most necessary data and if possible parsable as a stream. o might only be able to support a limited or no failure detection, i.e., the managing entity needs to handle the situation, where a failure does not get detected or gets detected late gracefully e.g., with asking repeatedly. o might only be able to support the reporting of just one or a limited set failure types. o might only be able to support a limited set of notifications, possible only an "I-am-alive" message. o might only be able to support a soft-reset from failure recovery. Ersue, et al. Expires January 5, 2015 [Page 11] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 o might possibly generate a large amount of redundant reporting data, i.e., the intermediary management entity (see [RFC7252]) should be able to filter and aggregate redundant data. A network of constrained devices: TW> same discussion about the term "unreliable radio" applies here o might only support an unreliable radio with lossy links, i.e., the client and server of a management protocol need to repeat commands as necessary or gracefully ignore incomplete commands. o might be necessary to manage based on multicast communication, i.e., the managing entity needs to be prepared to configure many devices at once based on the same data model. o might have a very large topology supporting 10,000 or more nodes for some applications and as such node naming is a specific issue for constrained networks. o must be able to self-organize, i.e., given the large number of nodes and their potential placement in hostile locations and frequently changing topology, manual configuration of nodes is TW> As such*,* typically not feasible. As such the network must be able to reconfigure itself so that it can continue to operate properly and support reliable connectivity. o needs a management solution that is energy-efficient, using as little wireless bandwidth as possible since communication is highly energy demanding. TW> while very important in some cases, this seems not to be the general case. TW> maybe prefix by "In some cases,"? o needs to support localization schemes to determine the location of devices since the devices might be moving and location information is important for some applications. o needs a management solution that is scalable as the network may consist of thousands of nodes and may need to be extended continuously. o needs to provide fault tolerance. Faults in network operation including hardware and software errors or failures detected by the TW> I don't understand "should be handled smoothly enabling" transport protocol should be handled smoothly enabling. In such a case it should be possible to run the protocol possibly at a reduced level but avoiding to fail completely. E.g., self- monitoring mechanisms or graceful degradation of features can be used to provide fault tolerance. o might require new management capabilities: for example, network coverage information and a constrained device power-distribution- map. Ersue, et al. Expires January 5, 2015 [Page 12] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 o might require a new management function for data management, since the type and amount of data collected in constrained networks is different from those of the traditional networks. o might also need energy-efficient key management. 1.7. Configuration and Monitoring Functionality Levels Devices often differ significantly on the level of configuration management support they provide. This document classifies the configuration management functionality as follows: TW> I have two low-end cases in mind which are believe are commonplace, but TW> I don't know in which category it fits: TW> - the device can only bec configured by physically connecting a device to TW> it and changing the configuration. This might be a handheld with a serial TW> cable. TW> - the device's configuration is contained in some flash memory card. An TW> operate reconfigures a device by swapping its configuration card. CL0: Devices are pre-configured and allow no runtime configuration TW> hard coded -> hard-coded? changes. Configuration parameters are often hard coded and compiled directly into the firmware image. CL1: Devices have explicit configuration objects. However, changes require a restart of the device to take effect. CL2: Devices allow management systems to replace the entire configuration (or pre-determined subsets) in bulk. Configuration changes take effect by soft-restarts of the system (or subsystems). CL3: Devices allow management systems to modify configuration objects without bulk replacements and changes take effect immediately. CL4: Devices support multiple configuration datastores and they might distinguish between the currently running and the next startup configuration. CL5: Devices support configuration datastore locking and device- local configuration change transactions, i.e., either all configuration changes are applied or none of them. CL6: Devices support configuration change transactions across devices. This document defines a classification of devices with regards to different levels of monitoring support. In general a device may be in several of the levels listed below: TW> I have a monitoring use case which I believe to be common, but I TW> have a hard time seeing to which category it belongs: TW> - a device logs noteworthy event to a flash drive connected to it. An TW> operator collects those, and analyzes those logs, possibly much later. ML0: Devices push pre-defined monitoring data. ML1: Devices allow management systems to pull pre-defined monitoring data. Ersue, et al. Expires January 5, 2015 [Page 13] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 ML2: Devices allow management systems to pull user-defined filtered subsets of monitoring data. ML3: Devices are able to locally process monitoring data in order to detect threshold crossings or to aggregate data. At the time of this writing, constrained devices often implement a combination of one of CL0-CL2 with one of ML0-ML1. 2. Problem Statement The terminology for the "Internet of Things" is still nascent, and depending on the network type or layer in focus diverse technologies and terms are in use. Common to all these considerations is the "Things" or "Objects" are supposed to have physical or virtual identities using interfaces to communicate. In this context, we need to differentiate between the Constrained and Smart Devices identified by an IP address compared to virtual entities such as Smart Objects, which can be identified as a resource or a virtual object by using a unique identifier. Furthermore, the smart devices usually have a limited memory and CPU power as well as aim to be self-configuring and easy to deploy. However, the constraints of the network nodes requires a rethinking of the protocol characteristics concerning power consumption, TW> please add network bandwidth performance, memory, and CPU usage. As such, there is a demand for protocol simplification, energy-efficient communication, less CPU TW> small*er*? usage and small memory footprint. On the application layer the IETF is already developing protocols like the Constrained Application Protocol (CoAP) [RFC7252] enabling the communication of constrained devices and networks e.g., for smart energy applications or home automation environments. The deployment of such an environment involves in fact many, in some scenarios up to million constrained devices (e.g., smart meters), which produce a large amount of data. This data needs to be collected, filtered, and pre-processed for further use in diverse services. TW> think on -> think about? Considering the high number of nodes to deploy, one has to think on the manageability aspects of the smart devices and plan for easy deployment, configuration, and management of the networks of constrained devices as well as the devices themselves. Consequently, seamless monitoring and self-configuration of such network nodes becomes more and more imperative. Self-configuration and self- management is already a reality in the standards of some of the bodies such as 3GPP. To introduce self-configuration of smart devices successfully a device-initiated connection establishment is required. TW> In some cases, the management entity might establish connection with a TW> joining device during commisionning (i.e. wake-up). I don't have a good TW> example, and I certainly agree that the devices should establish a TW> connection in most cases, but I would no sat "is required". Maybe "is often TW> required"? Ersue, et al. Expires January 5, 2015 [Page 14] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 A simple and efficient application layer protocol, such as CoAP, is essential to address the issue of efficient object-to-object communication and information exchange. Such an information exchange should be done based on interoperable data models to enable the exchange and interpretation of diverse application and management related data. In an ideal world, we would have only one network management protocol for monitoring, configuration, and exchanging management data, independently of the type of the network (e.g., Smart Grid, wireless access, or core network). Furthermore, it would be desirable to derive the basic data models for constrained devices from the core models used today to enable reuse of functionality and end-to-end information exchange. However, the current management protocols seem to be too heavyweight compared to the capabilities the constrained devices have and are not applicable directly for the use in a network of constrained devices. Furthermore, the data models addressing the requirements of such smart devices need yet to be designed. The IETF so far has not developed any specific technologies for the management of constrained devices and the networks comprised by constrained devices. IP-based sensors or constrained devices in such an environment, i.e., devices with very limited memory and CPU resources, use today, e.g., application-layer protocols to do simple resource management and monitoring. This might be sufficient for some basic cases, however, there is a need to reconsider the network management mechanisms based on the new, changed, as well as reduced requirements coming from smart devices and the network of such constrained devices. Albeit it is questionable whether we can take the same comprehensive approach we use in an IP network also for the management of constrained devices. Hence, the management of a network with constrained devices is necessary to design in a simplified and less complex manner. TW> typo characterists -> characteristics As Section 1.6 highlights, there are diverse characterists of constrained devices or networks, which stem from their constrainedness and therefore have an impact on the requirements for the management of such a network with constrained devices. The use cases discussed in [COM-USE] show that the requirements on constrained networks are manifold and need to be analyzed from different angles, e.g., concerning the design of the management architecture, the selection of the appropriate protocol features as well as the specific issues which are new in the context of constrained devices. Examples of such issues are e.g., the careful management of the scarce energy resources, the necessity for self- organization and self-management of such devices but also the implementation considerations to enable the use of common communication technologies on a constrained hardware in an efficient Ersue, et al. Expires January 5, 2015 [Page 15] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 manner. For an exhaustive list of issues and requirements that need to be addressed for the management of a network with constrained devices please see Section 1.6 and Section 3. 3. Requirements on the Management of Networks with Constrained Devices This section describes the requirements categorized by management areas listed in subsections. Note that the requirements listed in this section have been separated from the context in which they may appear. This document in general does not recommend the realization of any subset of the described requirements. As such this document avoids selecting any of the requirements as mandatory to implement. A device might be able to provide only a particular selected set of requirements and might not be capable to provide all requirements in this document. On the other hand a device vendor might select a specific relevant subset of the requirements to implement. TW> *The* following? Following template is used for the definition of the requirements. TW> "An ID uniquely identified" reads strange. Rephrase to "A unique 3-digit TW> identifier"? Req-ID: An ID uniquely identified by a three-digit number Title: The title of the requirement. Description: The rational and description of the requirement. Source: The origin of the requirement and the matching use case or application. For the discussion of referred use cases for constrained management please see [COM-USE]. Requirement Type: Functional Requirement, Non-Functional Requirement. A functional requirement is related to a function or component. As such functional requirements may be technical details, or specific functionality that define what a system is supposed to accomplish. Non-functional requirements (also known as design constraints or quality requirements) impose TW> implementation-related? implementation related considerations such as performance requirements, security, or reliability. TW> please add RFC reference Device type: The device types by which this requirement can be supported: C0, C1 and/or C2. TW> I'm a bit surprised the priority depends on the class of device. In my mind TW> some requirement are of high priority because they are really needed. TW> Whether it's implemented on a C0 or C2 shouldn't matter. At the most, some TW> requirements cannot be satisfied by low-end devices. Priority: The priority of the requirement showing its importance for a particular type of device: High, Medium, and Low. The priority of a requirement can be High e.g., for a C2 device but Low for a C1 or C0 device as the realization of complex features in a C1 device is in many cases not possible. Ersue, et al. Expires January 5, 2015 [Page 16] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 3.1. Management Architecture/System Req-ID: 1.001 Title: Support multiple device classes within a single network. Description: Larger networks usually consist of devices belonging to different device classes (e.g., constrained mesh endpoints and less constrained routers) communicating with each other. Hence, the management architecture must be applicable to networks that have a mix of different device classes. See Section 3. of [RFC7228] for the definition of Constrained Device Classes. Source: All use cases. Requirement Type: Non-Functional Requirement Device type: C1 and/or C2 Priority: High --- Req-ID: 1.002 Title: Management scalability. Description: The management architecture must be able to scale with the number of devices involved and operate efficiently in any network size and topology. This implies that e.g., the managing entity is able to handle large amounts of device monitoring data and the management protocol is not sensitive to the decrease of the time between two client requests. To achieve good scalability, caching techniques, in-network data aggregation techniques, hierarchical management models may be used. Source: General requirement for all use cases to enable large scale networks. Requirement Type: Non-Functional Requirement Device type: C0, C1, and C2 Priority: High --- Req-ID: 1.003 Ersue, et al. Expires January 5, 2015 [Page 17] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 Title: Hierarchical management Description: Provide a means of hierarchical management, i.e., provide intermediary management entities on different levels, which can take over the responsibility for the management of a sub-hierarchy of the network of constraint devices. The intermediary management entity can e.g., support management data aggregation to handle e.g., high-frequent monitoring data or TW> RFC6550 uses the terms "upward" and "downward". Maybe use those here too? provide a caching mechanism for the uplink and downlink communication. Hierarchical management contributes to management scalability. Source: Use cases where a large amount of devices are deployed with a hierarchical topology. Requirement Type: Non-Functional Requirement Device type: Managing and intermediary entities. Priority: Medium --- Req-ID: 1.004 Title: Minimize state maintained on constrained devices. Description: The amount of state that needs to be maintained on constrained devices should be minimized. This is important in order to save memory (especially relevant for C0 and C1 devices) and in order to allow devices to restart for example to apply configuration changes or to recover from extended periods of inactivity. Note: One way to achieve this is to adopt a RESTful architecture that minimizes the amount of state maintained by managed constrained devices and that makes resources of a device addressable via URIs. Source: Basic requirement which concerns all use cases. Requirement Type: Functional Requirement Device type: C0, C1, and C2 Priority: High --- Ersue, et al. Expires January 5, 2015 [Page 18] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 Req-ID: 1.005 Title: Automatic re-synchronization with eventual consistency. Description: To support large scale networks, where some constrained devices may be offline at any point in time, it is necessary to distribute configuration parameters in a way that allows temporary inconsistencies but eventually converges, after a sufficiently long period of time without further changes, towards global consistency. Source: Use cases with large scale networks with many devices. Requirement Type: Functional Requirement Device type: C0, C1, and C2 Priority: High --- Req-ID: 1.006 Title: Support for lossy links and unreachable devices. Description: Some constrained devices will only be able to support lossy and unreliable links characterized by a limited data rate, a TW> Furthermore*,* high latency, and a high transmission error rate. Furthermore constrained devices often duty cycle their radio or the whole TW> labelled -> labeled device in order to save energy. Some classes of devices labelled as 'sleepy endpoints' set their network links to a disconnected state during long periods of time. In all cases the management system must not assume that constrained devices are always reachable. Source: Basic requirement for networks of constrained devices with unreliable links and constrained devices that sleep to save energy. Requirement Type: Non-Functional Requirement Device type: C0, C1, and C2 Priority: High --- Req-ID: 1.007 Ersue, et al. Expires January 5, 2015 [Page 19] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 Title: Network-wide configuration Description: Provide means by which the behavior of the network can be specified at a level of abstraction (network-wide configuration) higher than a set of configuration information specific to individual devices. It is useful to derive the device specific configuration from the network-wide configuration. Such a repository can be used to configure pre-defined device or protocol parameters for the whole network. Furthermore, such a network-wide view can be used to monitor and manage a group of routers or a whole network. E.g., monitoring the performance of a network requires additional information other than what can be acquired from a single router using a management protocol. Note: The identification of the relevant subset of the policies to be provisioned is according to the capabilities of each device and can be obtained from a pre-configured data-repository. Source: In general all use cases of network and device configuration based on a network view in a top-down manner. Requirement Type: Non-Functional Requirement Device type: C0, C1, and C2 Priority: Medium --- Req-ID: 1.008 Title: Distributed Management Description: Provide a means of simple distributed management, where a network of constrained devices can be managed or monitored by more than one manager. Since the connectivity to a server cannot be guaranteed at all times, a distributed approach may provide a higher reliability, at the cost of increased complexity. This requirement implies the handling of data consistency in case of concurrent read and write access to the device datastore. It might also happen that no management (configuration) server is accessible and the only reachable node is a peer device. In this case the device should be able to obtain its configuration from peer devices. Source: Use cases where the count of devices to manage is high. Requirement Type: Non-Functional Requirement Ersue, et al. Expires January 5, 2015 [Page 20] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 Device type: C1 and C2 Priority: Medium 3.2. Management protocols and data model Req-ID: 2.001 Title: Modular implementation of management protocols Description: Management protocols should be specified to allow for modular implementations, i.e., it should be possible to implement only a basic set of protocol primitives on highly constrained devices while devices with additional resources may provide more support for additional protocol primitives. See Section 1.7 for a discussion on the level of configuration management and monitoring support constrained devices may provide. Source: Basic requirement interesting for all use cases. Requirement Type: Non-Functional Requirement Device type: C0, C1, and C2 Priority: High --- Req-ID: 2.002 Title: Compact encoding of management data Description: The encoding of management data should be compact and space efficient, enabling small message sizes. Source: General requirement to save memory for the receiver buffer and on-air bandwidth. Requirement Type: Functional Requirement Device type: C0, C1, and C2 Priority: High --- Req-ID: 2.003 Ersue, et al. Expires January 5, 2015 [Page 21] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 Title: Compression of management data or complete messages Description: Management data exchanges can be further optimized by applying data compression techniques or delta encoding techniques. Compression typically requires additional code size and some additional buffers and/or the maintenance of some additional state information. For C0 devices compression may not be feasible. Source: Use cases where it is beneficial to reduce transmission time and bandwidth, e.g., mobile applications which require to save on- air bandwidth. Requirement Type: Functional Requirement Device type: C1 and C2 Priority: Medium --- Req-ID: 2.004 Title: Mapping of management protocol interactions. Description: It is desirable to have a loss-less automated mapping between the management protocol used to manage constrained devices and the management protocols used to manage regular devices. In the ideal case, the same core management protocol can be used with certain restrictions taking into account the resource limitations of constrained devices. However, for very resource constrained devices, this goal might not be achievable. Source: Use cases where high-frequent interaction with the management system of a non-constrained network is required. Requirement Type: Functional Requirement Device type: C1 and C2 Priority: Medium --- Req-ID: 2.005 Title: Consistency of data models with the underlying information model. Ersue, et al. Expires January 5, 2015 [Page 22] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 Description: The data models used by the management protocol must be consistent with the information model used to define data models for non-constrained networks. This is essential to facilitate the integration of the management of constrained networks with the management of non-constrained networks. Using an underlying information model for future data model design enables furthermore top-down model design and model reuse as well as data interoperability (i.e., exchange of management information between the constrained and non-constrained networks). This is a strong requirement, even despite the fact that the underlying information models are often not explicitly documented in the IETF. Source: General requirement to support data interoperability, consistency and model reuse. Requirement Type: Non-Functional Requirement Device type: C0, C1, and C2 Priority: High --- Req-ID: 2.006 TW> I believe "Lossless" can be a single word Title: Loss-less mapping of management data models. Description: It is desirable to have a loss-less automated mapping between the management data models used to manage regular devices and the management data models used for managing constrained devices. In the ideal case, the same core data models can be used with certain restrictions taking into account the resource limitations of constrained devices. However, for very resource constrained devices, this goal might not be achievable. Source: Use cases where consistent data exchange with the management system of a non-constrained network is required. Requirement Type: Functional Requirement Device type: C2 Priority: Medium --- Req-ID: 2.007 Ersue, et al. Expires January 5, 2015 [Page 23] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 Title: Protocol extensibility Description: Provide means of extensibility for the management protocol, i.e., by adding new protocol messages or mechanisms that TW> deal with the changing requirements -> deal with changing requirements can deal with the changing requirements on a supported message and TW> inter-operability -> interoperability data types effectively, without causing inter-operability problems or having to replace/update large amount of deployed devices. Source: Basic requirement useful for all use cases. Requirement Type: Functional Requirement Device type: C0, C1, and C2 Priority: High 3.3. Configuration management Req-ID: 3.001 Title: Self-configuration capability Description: Automatic configuration and re-configuration of devices without manual intervention. Compared to the traditional management of devices where the management application is the central entity configuring the devices, in the auto-configuration scenario the device is the active part and initiates the configuration process. Self-configuration can be initiated during the initial configuration or for subsequent configurations, where the configuration data needs to be refreshed. Self-configuration should be also supported during the initialization phase or in the event of failures, where prior knowledge of the network topology is not available or the topology of the network is uncertain. Source: In general all use cases requiring easy deployment and plug&play behavior as well as easy maintenance of many constrained devices. Requirement Type: Functional Requirement Device type: C0, C1, and C2 Priority: High for device categories C0 and C1, Medium for C2. --- Req-ID: 3.002 Ersue, et al. Expires January 5, 2015 [Page 24] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 Title: Capability Discovery Description: Enable the discovery of supported optional management capabilities of a device and their exposure via at least one protocol and/or data model. Source: Use cases where the device interaction with other devices or applications is a function of the level of support for its capabilities. Requirement Type: Functional Requirement Device type: C1 and C2 Priority: Medium --- Req-ID: 3.003 Title: Asynchronous Transaction Support Description: Provide configuration management with asynchronous (event-driven) transaction support. Configuration operations must support a transactional model, with asynchronous indications that the transaction was completed. Source: Use cases that require transaction-oriented processing because of reliability or distributed architecture functional requirements. Requirement Type: Functional Requirement Device type: C1 and C2 Priority: Medium --- Req-ID: 3.004 Title: Network reconfiguration Description: Provide a means of iterative network reconfiguration in TW> did you mean "fault" or "failure"? order to recover the network from node and communication faults. The network reconfiguration can be failure-driven and self- initiated (automatic reconfiguration). The network Ersue, et al. Expires January 5, 2015 [Page 25] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 reconfiguration can be also performed on the whole hierarchical structure of a network (network topology). Source: Practically all use cases, as network connectivity is a basic requirement. Requirement Type: Functional Requirement Device type: C0, C1, and C2 Priority: Medium 3.4. Monitoring functionality Req-ID: 4.001 Title: Device status monitoring Description: Provide a monitoring function to collect and expose information about device status and exposing it via at least one management interface. The device monitoring might make use of the hierarchical management through the intermediary entities and the caching mechanism. The device monitoring might also make use of neighbor-monitoring (fault detection in local network) to support fast fault detection and recovery, e.g., in a scenario where a managing entity is unreachable and a neighbor can take over the monitoring responsibility. Source: All use cases Requirement Type: Functional Requirement Device type: C0, C1, and C2 Priority: High, Medium for neighbor-monitoring. --- Req-ID: 4.002 Title: Energy status monitoring Description: Provide a monitoring function to collect and expose information about device energy parameters and usage (e.g., TW> I would suggest to replace "communication power" by "average power TW> consumption" battery level and communication power). Source: Use case Energy Management Ersue, et al. Expires January 5, 2015 [Page 26] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 Requirement Type: Functional Requirement Device type: C0, C1, and C2 Priority: High for energy reporting devices, Low for others. --- Req-ID: 4.003 Title: Monitoring of current and estimated device availability Description: Provide a monitoring function to collect and expose information about current device availability (energy, memory, computing power, forwarding plane utilization, queue buffers, etc.) and estimation of remaining available resources. Source: All use cases. Note that monitoring energy resources (like battery status) may be required on all kinds of devices. Requirement Type: Functional Requirement Device type: C0, C1, and C2 Priority: Medium --- Req-ID: 4.004 Title: Network status monitoring TW> typo analyse -> analyze Description: Provide a monitoring function to collect, analyse and expose information related to the status of a network or network segments connected to the interface of the device. Source: All use cases. Requirement Type: Functional Requirement Device type: C1 and C2 Priority: Low, based on the realization complexity. --- Req-ID: 4.005 Ersue, et al. Expires January 5, 2015 [Page 27] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 Title: Self-monitoring Description: Provide self-monitoring (local fault detection) feature for fast fault detection and recovery. Source: Use cases where the devices cannot be monitored centrally in appropriate manner, e.g., self-healing is required. Requirement Type: Functional Requirement Device type: C1 and C2 Priority: High for C2, Medium for C1 --- Req-ID: 4.006 Title: Performance Monitoring Description: The device will provide a monitoring function to collect and expose information about the basic performance parameter of the device. The performance management functionality might make use of the hierarchical management through the intermediary devices. Source: Use cases Building automation, and Transport applications Requirement Type: Functional Requirement Device type: C1 and C2 Priority: Low --- Req-ID: 4.007 Title: Fault detection monitoring Description: The device will provide fault detection monitoring. The system collects information about network states in order to identify whether faults have occurred. In some cases the detection of the faults might be based on the processing and analysis of the parameters retrieved from the network or other devices. In case of C0 devices the monitoring might be limited to the check whether the device is alive or not. Ersue, et al. Expires January 5, 2015 [Page 28] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 Source: Use cases Environmental Monitoring, Building Automation, Energy Management, Infrastructure Monitoring Requirement Type: Functional Requirement Device type: C0, C1 and C2 Priority: Medium --- Req-ID: 4.008 Title: Passive and Reactive Monitoring Description: The device will provide passive and reactive monitoring capabilities. The system or manager collects information about device components and network states (passive monitoring) and may perform postmortem analysis of collected data. In case events of interest have occurred the system or manager can adaptively react (reactive monitoring), e.g., reconfigure the network. Typically actions (re-actions) will be executed or sent as commands by the management applications. Source: Diverse use cases relevant for device status and network state monitoring Requirement Type: Functional Requirement Device type: C2 Priority: Medium --- Req-ID: 4.009 Title: Recovery Description: Provide local, central and hierarchical recovery mechanisms (recovery is in some cases achieved by recovering the whole network of constrained devices). Source: Use cases Industrial applications, Home and Building Automation, Mobile Applications that involve different forms of clustering or area managers. Requirement Type: Functional Requirement Ersue, et al. Expires January 5, 2015 [Page 29] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 Device type: C2 Priority: Medium --- Req-ID: 4.010 Title: Network topology discovery Description: Provide a network topology discovery capability (e.g., use of topology extraction algorithms to retrieve the network state) and a monitoring function to collect and expose information about the network topology. Source: Use cases Community Network Applications and Mobile Applications Requirement Type: Functional Requirement Device type: C1 and C2 Priority: Low, based on the realization complexity. --- Req-ID: 4.011 Title: Notifications Description: The device will provide the capability of sending notifications on critical events and faults. Source: All use cases. Requirement Type: Functional Requirement Device type: C0, C1, and C2 Priority: Medium for C2, Low for C0 and C1 --- Req-ID: 4.012 Title: Logging Ersue, et al. Expires January 5, 2015 [Page 30] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 Description: The device will provide the capability of building, keeping, and allowing retrieval of logs of events (including but not limited to critical faults and alarms). Source: Use cases Industrial Applications, Building Automation, Infrastructure monitoring Requirement Type: Functional Requirement Device type: C2 Priority: High for some medical or industrial applications, Medium otherwise 3.5. Self-management Req-ID: 5.001 Title: Self-management - Self-healing Description: Enable event-driven and/or periodic self-management functionality in a device. The device should be able to react in case of a failure e.g., by initiating a fully or partly reset and initiate a self-configuration or management data update as necessary. A device might be further able to check for failures cyclically or schedule-controlled to trigger self-management as necessary. It is a matter of device design and subject for discussion how much self-management a C1 device can support. A minimal failure detection and self-management logic is assumed to be generally useful for the self-healing of a device. Source: The requirement generally relates to all use cases in this document. Requirement Type: Functional Requirement Device type: C1 and C2 Priority: High for C2, Medium for C1 3.6. Security and Access Control Req-ID: 6.001 Title: Authentication of management system and devices. Description: Systems having a management role must be properly authenticated to the device such that the device can exercise Ersue, et al. Expires January 5, 2015 [Page 31] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 proper access control and in particular distinguish rightful management systems from rogue systems. On the other hand managed devices must authenticate themselves to systems having a management role such that management systems can protect themselves from rogue devices. In certain application scenarios, it is possible that a large number of devices need to be (re)started at about the same time. Protocols and authentication systems should be designed such that a large number of devices (re)starting simultaneously does not negatively impact the device authentication process. Source: Basic security requirement for all use cases. Requirement Type: Functional Requirement Device type: C0, C1, and C2 Priority: High, Medium for the (re)start of a large number of devices --- Req-ID: 6.002 Title: Support suitable security bootstrapping mechanisms Description: Mechanisms should be supported that simplify the bootstrapping of device that is the discovery of newly deployed devices in order to provide them with appropriate access control permissions. Source: Basic security requirement for all use cases. Requirement Type: Functional Requirement Device type: C0, C1, and C2 Priority: High --- TW> in some cases, different entities should have access to different sets of TW> resources. This is not captured in the text below. Req-ID: 6.003 Title: Access control on management system and devices Description: Systems acting in a management role must provide an access control mechanism that allows the security administrator to restrict which devices can access the managing system (e.g., using Ersue, et al. Expires January 5, 2015 [Page 32] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 an access control white list of known devices). On the other hand managed constrained devices must provide an access control mechanism that allows the security administrator to restrict how systems in a management role can access the device (e.g., no- access, read-only access, and read-write access). Source: Basic security requirement for use cases where access control is essential. Requirement Type: Functional Requirement Device type: C0, C1, and C2 Priority: High --- Req-ID: 6.004 Title: Select cryptographic algorithms that are efficient in both code space and execution time. Description: Cryptographic algorithms have a major impact in terms of both code size and overall execution time. It is therefore necessary to select mandatory to implement cryptographic algorithms that are reasonable to implement with the available code space and that have a small impact at runtime. Furthermore some wireless technologies (e.g., IEEE 802.15.4) require the support of certain cryptographic algorithms. It might be useful to choose algorithms that are likely to be supported in wireless chipsets for certain wireless technologies. Source: Generic requirement to reduce the footprint and CPU usage of a constrained device. Requirement Type: Non-Functional Requirement Device type: C0, C1, and C2 Priority: High, Medium for hardware-supported algorithms. 3.7. Energy Management Req-ID: 7.001 Title: Management of Energy Resources Ersue, et al. Expires January 5, 2015 [Page 33] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 Description: Enable managing power resources in the network, e.g., reduce the sampling rate of nodes with critical battery and reduce node transmission power, put nodes to sleep, put single interfaces to sleep, reject a management job based on available energy, criteria e.g., importance levels pre-defined by the management application, etc. (e.g., a task marked as essential can be executed even if the energy level is low). The device may further implement standard data models for energy management and expose it through a management protocol interface, e.g., EMAN MIB modules and extensions (work ongoing). It might be necessary to use a subset of EMAN MIBs for C1 and C2 devices. Source: Use case Energy Management Requirement Type: Functional Requirement Device type: C0, C1, and C2 Priority: Medium for the use case Energy Management, Low otherwise. --- Req-ID: 7.002 Title: Support of energy-optimized communication protocols Description: Use of an optimized communication protocol to minimize energy usage for the device (radio) receiver/transmitter, on-air bandwidth (protocol efficiency), reduced amount of data communication between nodes (implies data aggregation and filtering but also a compact format for the transferred data). Source: Use cases Energy Management and Mobile Applications. Requirement Type: Non-Functional Requirement Device type: C2 Priority: Medium --- Req-ID: 7.003 Title: Support for layer 2 energy-aware protocols Ersue, et al. Expires January 5, 2015 [Page 34] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 Description: The device will support layer 2 energy management protocols (e.g., energy-efficient Ethernet IEEE 802.3az) and be able to report on these. Source: Use case Energy Management Requirement Type: Non-Functional Requirement Device type: C0, C1, and C2 Priority: Medium --- Req-ID: 7.004 Title: Dying gasp Description: When energy resources draw below the red line level, the device will send a dying gasp notification and perform if still possible a graceful shutdown including conservation of critical device configuration and status information. Source: Use case Energy Management Requirement Type: Functional Requirement Device type: C0, C1, and C2 Priority: Medium 3.8. SW Distribution Req-ID: 8.001 Title: Group-based provisioning Description: Support group-based provisioning, i.e., firmware update and configuration management, of a large set of constrained devices with eventual consistency and coordinated reload times. The device should accept group-based configuration management based on bulk commands, which aim similar configurations of a large set of constrained devices of the same type in a given group, and which may share a common data model. Activation of configuration may be based on pre-loaded sets of default values. Source: All use cases Ersue, et al. Expires January 5, 2015 [Page 35] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 Requirement Type: Non-Functional Requirement Device type: C0, C1, and C2 Priority: Medium 3.9. Traffic management Req-ID: 9.001 Title: Congestion avoidance Description: Support congestion control principles as defined in [RFC2914], e.g., the ability to avoid congestion by modifying the device's reporting rate for periodical data (which is usually redundant) based on the importance and reliability level of the management data. This functionality is usually controlled by the managing entity, where the managing entity marks the data as TW> However*,* reducing important or relevant for reliability. However reducing a device's reporting rate can also be initiated by a device if it is able to detect congestion or has insufficient buffer memory. Source: Use cases with high reporting rate and traffic e.g., AMI or M2M. Requirement Type: Non-Functional Requirement Device type: C1 and C2 Priority: Medium --- Req-ID: 9.002 Title: Reroute traffic Description: Provide the ability for network nodes to redirect traffic from overloaded intermediary nodes in a network to another path in order to prevent congestion on a central server and in the primary network. Source: Use cases with high reporting rate and traffic e.g., AMI or M2M. Requirement Type: Non-Functional Requirement Device type: Intermediary entity in the network. Ersue, et al. Expires January 5, 2015 [Page 36] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 Priority: Medium --- Req-ID: 9.003 Title: Traffic Shaping. Description: Provide the ability to apply traffic shaping policies to incoming and outgoing links on an overloaded intermediary node as necessary in order to reduce the amount of traffic in the network. Source: Use cases with high reporting rate and traffic e.g., AMI or M2M. Requirement Type: Non-Functional Requirement Device type: Intermediary entity in the network. Priority: Medium 3.10. Transport Layer Req-ID: 10.001 Title: Scalable transport layer Description: Enable the use of a scalable transport layer, i.e., not sensitive to a high rate of incoming client requests, which is useful for applications requiring frequent access to device data. Source: Applications with high frequent access to the device data. Requirement Type: Non-Functional Requirement Device type: C0, C1 and C2 Priority: Medium --- Req-ID: 10.002 Title: Reliable unicast transport of messages Description: Diverse applications need a reliable transport of messages. The reliability might be achieved based on a transport Ersue, et al. Expires January 5, 2015 [Page 37] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 protocol such as TCP or can be supported based on message TW> acknowledgement -> acknowledgment repetition if an acknowledgement is missing. Source: Generally applications benefit from the reliability of the message transport. Requirement Type: Functional Requirement Device type: C0, C1, and C2 Priority: High --- Req-ID: 10.003 Title: Best-effort multicast Description: Provide best-effort multicast of messages, which is generally useful when devices need to discover a service provided by a server or many devices need to be configured by a managing entity at once based on the same data model. Source: Use cases where a device needs to discover services as well as use cases with high amount of devices to manage, which are hierarchically deployed, e.g., AMI or M2M. Requirement Type: Functional Requirement Device type: C0, C1, and C2 Priority: Medium --- Req-ID: 10.004 Title: Secure message transport. Description: Enable secure message transport providing authentication, data integrity, confidentiality by using existing transport layer technologies with small footprint such as TLS/ DTLS. Source: All use cases. Requirement Type: Non-Functional Requirements Ersue, et al. Expires January 5, 2015 [Page 38] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 Device type: C1 and C2 Priority: High 3.11. Implementation Requirements Req-ID: 11.001 Title: Avoid complex application layer transactions requiring large application layer messages. Description: Complex application layer transactions tend to require large memory buffers that are typically not available on C0 or C1 devices and only by limiting functionality on C2 devices. Furthermore, the failure of a single large transaction requires repeating the whole transaction. On constrained devices, it is TW> "to a large transaction down" verb missing? often more desirable to a large transaction down into a sequence of smaller transactions that require less resources and allow to make progress using a sequence of smaller steps. Source: Basic requirement which concerns all use cases with memory constrained devices. Requirement Type: Non-Functional Requirement Device type: C0, C1, and C2 Priority: High --- Req-ID: 11.002 Title: Avoid reassembly of messages at multiple layers in the protocol stack. Description: Reassembly of messages at multiple layers in the protocol stack requires buffers at multiple layers, which leads to inefficient use of memory resources. This can be avoided by making sure the application layer, the security layer, the transport layer, the IPv6 layer and any adaptation layers are aware of the limitations of each other such that unnecessary fragmentation and reassembly can be avoided. In addition, message size constraints must be announced to protocol peers such that they can adapt and avoid sending messages that can't be processed due to resource constraints on the receiving device. Ersue, et al. Expires January 5, 2015 [Page 39] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 Source: Basic requirement which concerns all use cases with memory constrained devices. Requirement Type: Non-Functional Requirement Device type: C0, C1, and C2 Priority: High 4. IANA Considerations This document does not introduce any new code-points or namespaces for registration with IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 5. Security Considerations This document discusses the problem statement and requirements on networks of constrained devices. Section 1.6 mentions a number of limitations that could prevent the implementation of strong cryptographic algorithms. Requirements for security and access control are listed in Section 3.6. Constrained devices might be deployed often in unsafe environments, where attackers can gain physical access to the devices. As a consequence, it is crucial to properly protect any security credentials that may be stored on the device (e.g., by using hardware protection mechanisms). Furthermore, it is important that any TW> leeking -> leaking credentials leeking from a single device do not simplify the attack on other (similar) devices. In particular, security credentials should never be shared. Since constrained devices often have limited computational resources, care should be taken in choosing efficient but cryptographically TW> crytographic -> cryptographic strong crytographic algorithms. Designers of constrained devices that have a long expected lifetime need to ensure that cryptographic algorithms can be updated once devices have been deployed. The ability to perform secure firmware and software updates is an important management requirement. Constrained devices might also generate sensitive data or require the processing of sensitive data. It is therefore an important requirement to properly protect access to the data in order to protect the privacy of humans using Internet-enabled devices. For certain types of data, protection during the transmission over the network may not be sufficient and methods should be investigated that Ersue, et al. Expires January 5, 2015 [Page 40] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 provide protection of data while it is cached or stored (e.g., when using a store-and-forward transport mechanism). 6. Contributors Ulrich Herberg (Fujitsu Laboratories of America) contributed to the Section 1.3 on Networks Types and Characteristics in Focus. 7. Acknowledgments Following persons reviewed and provided valuable comments to different versions of this document: Dominique Barthel, Andy Bierman, Carsten Bormann, Zhen Cao, Benoit Claise, Hui Deng, Bert Greevenbosch, Ulrich Herberg, James Nguyen, Anuj Sehgal, Zach Shelby, Peter van der Stok and Bert Wijnen. The editors would like to thank the reviewers and the participants on the Coman and OPSAWG mailing lists for their valuable contributions and comments. 8. Informative References [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000. [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations", RFC 2501, January 1999. [RFC6632] Ersue, M. and B. Claise, "An Overview of the IETF Network Management Standards", RFC 6632, June 2012. [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and Lossy Networks", RFC 7102, January 2014. [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, May 2014. [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, June 2014. [COM-USE] Ersue, M., "Constrained Management: Use Cases", draft- ietf-opsawg-coman-use-cases (work in progress), October 2013. Ersue, et al. Expires January 5, 2015 [Page 41] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 Appendix A. Change Log A.1. draft-ietf-opsawg-coman-probstate-reqs-01 - draft-ietf-opsawg- coman-probstate-reqs-02 o General bug fixing. o Resolved the use of the term profile of requirements. o Changed requirement title from Redirect traffic to Reroute traffic and the description accordingly. o Changed requirement title from Traffic delay schemes to Traffic Shaping and the description accordingly. o Extended Security Considerations section. o Deleted empty section on Normative References. A.2. draft-ietf-opsawg-coman-probstate-reqs-00 - draft-ietf-opsawg- coman-probstate-reqs-01 o General bug fixing. o Added Section 1.7. on Configuration and Monitoring Functionality Levels. o Changed diverse occurences of "networks" to "networks with/of constrained devices". o Introduced the term "Self-configuring infrastructureless networks" instead of MANET as it is a superset. o Introduced the term 'sleepy endpoints'. o Changed requirement IDs to be independent of section number. o Introduced notes for parts of the requirements text if it is focusing on implementation or solution. o Extended Security Considerations section. o Deleted Appendix A and B on other SDO's work and related projects as they provided dynamic information and couldn't be kept up-to- date. Ersue, et al. Expires January 5, 2015 [Page 42] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 A.3. draft-ersue-constrained-mgmt-03 - draft-ietf-opsawg-coman- probstate-reqs-00 o Reduced the terminology section for terminology addressed in the LWIG terminology draft. Referenced the LWIG terminology draft. o Checked and aligned all terminology against the LWIG terminology draft. o Moved section 1.4. Constrained Device Deployment Options and section 3. Use Cases to the companion document [COM-USE]. o Renamed Section 1.3. Class of Networks in Focus to "Network Types in Focus" and removed abbreviations C0, C1 and C2 for network classes as they have not been used. o Changed requirement priority classes to be High, Medium and Low. o Changed requirement types to be Functional and Non-Functional and added text to explain the requirement types. o Reformulation of some text parts for more clarity. A.4. draft-ersue-constrained-mgmt-02-03 o Extended the terminology section and removed some of the terminology addressed in the new LWIG terminology draft. Referenced the LWIG terminology draft. o Moved Section 1.3. on Constrained Device Classes to the new LWIG terminology draft. o Class of networks considering the different type of radio and communication technologies in use and dimensions extended. o Extended the Problem Statement in Section 2. following the requirements listed in Section 4. o Following requirements, which belong together and can be realized with similar or same kind of solutions, have been merged. * Distributed Management and Peer Configuration, * Device status monitoring and Neighbor-monitoring, * Passive Monitoring and Reactive Monitoring, Ersue, et al. Expires January 5, 2015 [Page 43] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 * Event-driven self-management - Self-healing and Periodic self- management, * Authentication of management systems and Authentication of managed devices, * Access control on devices and Access control on management systems, * Management of Energy Resources and Data models for energy management, * Software distribution (group-based firmware update) and Group- based provisioning. o Deleted the empty section on the gaps in network management standards, as it will be written in a separate draft. o Added links to mentioned external pages. o Added text on OMA M2M Device Classification in appendix. A.5. draft-ersue-constrained-mgmt-01-02 o Extended the terminology section. o Added additional text for the use cases concerning deployment type, network topology in use, network size, network capabilities, radio technology, etc. o Added examples for device classes in a use case. o Added additional text provided by Cao Zhen (China Mobile) for Mobile Applications and by Peter van der Stok for Building Automation. o Added the new use cases 'Advanced Metering Infrastructure' and 'MANET Concept of Operations in Military'. o Added the section 'Managing the Constrainedness of a Device or Network' discussing the needs of very constrained devices. o Added a note that the requirements in Section 3 need to be seen as standalone requirements and the current document does not recommend any profile of requirements. o Added Section 3 on the detailed requirements on constrained management matched to management tasks like fault, monitoring, Ersue, et al. Expires January 5, 2015 [Page 44] Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 configuration management, Security and Access Control, Energy Management, etc. o Solved nits and added references. o Added Appendix A on the related development in other bodies. o Added Appendix B on the work in related research projects. A.6. draft-ersue-constrained-mgmt-00-01 o Splitted the section on 'Networks of Constrained Devices' into the sections 'Network Topology Options' and 'Management Topology Options'. o Added the use case 'Community Network Applications' and 'Mobile Applications'. o Provided a Contributors section. o Extended the section on 'Medical Applications'. o Solved nits and added references. Authors' Addresses Mehmet Ersue (editor) Nokia Networks Email: mehmet.ersue@nsn.com Dan Romascanu Avaya Email: dromasca@avaya.com Juergen Schoenwaelder Jacobs University Bremen Email: j.schoenwaelder@jacobs-university.de Ersue, et al. Expires January 5, 2015 [Page 45] --001a11c20cc86d38ee0500413e08 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I was asked to do a detailed review of=C2=A0draft-ietf-ops= awg-coman-probstate-reqs-02.

This is related to my revie= w of draft-ietf-opsawg-coman-use-cases-02, see http://= www.ietf.org/mail-archive/web/opsawg/current/msg03486.html.

Thomas

GENERAL
-----= ----------

In general, I believe that this is a ve= ry useful document to have, and it provides a very clear list of "poss= ible requirements".

As such, it is not a traditional requirement document, = as does not list requirements as MUSTs and SHOULDs, but rather gives a clea= r overview of what those requirements might be. In that sense, I would sugg= est to not use the term "Requirements" in the title, but maybe &q= uot;potential requirements".

I imagine that, when the time comes to design a managem= ent protocol for constrained devices (CoAP-based RESTCONF?), there will be = a "formal" requirements draft for that full of MUSTs and SHOULDs?= I would certainly recommend to indicate this clearly in the text.

DETAILED
---------------

=
please find my comments below, prefixed by "^TW>&= quot;




<= br>
Internet-Draft= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Nokia Networks
Intended status: Informational =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0D. Romascanu
Expires: Janua= ry 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Avaya
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 J. Schoenwae= lder
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Jacobs University Bremen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 July 4, 2014


=
TW> y= ou could put some newlines in the title

=C2=A0Manag= ement of Networks with Constrained Devices: Problem Statement and
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Requirements
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-opsawg-coman-probstate-= reqs-02

Abstract

=C2=A0 =C2= =A0This document provides a problem statement, deployment and management
=C2=A0 =C2=A0topolo= gy options as well as the requirements for the management of
TW> why not s= imple networks of constrained devices?
=C2=A0 =C2=A0n= etworks where constrained devices are involved.

Status of This Memo=

=C2=A0 =C2= =A0This Internet-Draft is submitted in full conformance with the
=C2=A0 =C2= =A0provisions of BCP 78 and BCP 79.

=C2=A0 =C2= =A0Internet-Drafts are working documents of the Internet Engineering=
=C2=A0 = =C2=A0Task Force (IETF). =C2=A0Note that other groups may also distribute
=C2=A0 =C2=A0w= orking documents as Internet-Drafts. =C2=A0The list of current Internet-
=C2= =A0 =C2=A0Drafts is at http://datatracker.ietf.org/drafts/current/.

=C2=A0 =C2= =A0Internet-Drafts are draft documents valid for a maximum of six months
=C2=A0 =C2=A0and ma= y be updated, replaced, or obsoleted by other documents at any
=
=C2=A0 =C2=A0t= ime. =C2=A0It is inappropriate to use Internet-Drafts as reference
=C2=A0 =C2=A0m= aterial or to cite them other than as "work in progress."<= /div>

=C2=A0 =C2=A0This I= nternet-Draft will expire on January 5, 2015.

Copyright N= otice

= =C2=A0 =C2=A0Copyright (c) 2014 IETF Trust and the persons identified as th= e
= =C2=A0 =C2=A0document authors. =C2=A0All rights reserved.

=C2=A0 =C2= =A0This document is subject to BCP 78 and the IETF Trust's Legal=
=C2=A0 = =C2=A0Provisions Relating to IETF Documents
=C2=A0 =C2=A0(= http://trustee.ietf.org/li= cense-info) in effect on the date of
=C2=A0 =C2=A0publication of this doc= ument. =C2=A0Please review these documents
=C2=A0 =C2=A0c= arefully, as they describe your rights and restrictions with respect=
=C2=A0 = =C2=A0to this document. =C2=A0Code Components extracted from this document = must
=C2=A0 =C2=A0i= nclude Simplified BSD License text as described in Section 4.e of

=

<= br>
= Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 July 2014


=C2=A0 =C2= =A0the Trust Legal Provisions and are provided without warranty as
=C2=A0 =C2= =A0described in the Simplified BSD License.

Table of Co= ntents

= =C2=A0 =C2=A01. =C2=A0Introduction =C2=A0. . . . . . . . . . . . . . . . . = . . . . . . . =C2=A0 3
=C2=A0 =C2=A0 =C2=A01.1. =C2=A0Overview =C2=A0. . . . = . . . . . . . . . . . . . . . . . . . . =C2=A0 3
=C2=A0 =C2=A0 = =C2=A01.2. =C2=A0Terminology . . . . . . . . . . . . . . . . . . . . . . . = =C2=A0 4
=C2=A0 =C2=A0 =C2=A01.3. =C2=A0Network Types and Characteristics in = Focus =C2=A0. . . . . . . =C2=A0 5
=C2=A0 =C2=A0 = =C2=A01.4. =C2=A0Constrained Device Deployment Options . . . . . . . . . . = =C2=A0 9
=C2=A0 =C2=A0 =C2=A01.5. =C2=A0Management Topology Options . . . . .= . . . . . . . . . . =C2=A0 9
=C2=A0 =C2=A0 = =C2=A01.6. =C2=A0Managing the Constrainedness of a Device or Network . . . = =C2=A010
=C2=A0 =C2=A0 =C2=A01.7. =C2=A0Configuration and Monitoring Function= ality Levels . . . . =C2=A013
=C2=A0 =C2=A02= . =C2=A0Problem Statement . . . . . . . . . . . . . . . . . . . . . . =C2= =A014
=C2=A0 =C2=A03. =C2=A0Requirements on the Management of Networks with C= onstrained
=C2=A0 =C2=A0 = =C2=A0 =C2=A0Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . = =C2=A016
=C2=A0 =C2=A0 =C2=A03.1. =C2=A0Management Architecture/System =C2=A0= . . . . . . . . . . . . . =C2=A017
=C2=A0 =C2=A0 = =C2=A03.2. =C2=A0Management protocols and data model . . . . . . . . . . . = =C2=A021
=C2=A0 =C2=A0 =C2=A03.3. =C2=A0Configuration management =C2=A0. . . = . . . . . . . . . . . . . =C2=A024
=C2=A0 =C2=A0 = =C2=A03.4. =C2=A0Monitoring functionality =C2=A0. . . . . . . . . . . . . .= . . =C2=A026
=C2=A0 =C2=A0 =C2=A03.5. =C2=A0Self-management . . . . . . . . = . . . . . . . . . . . . . =C2=A031
=C2=A0 =C2=A0 = =C2=A03.6. =C2=A0Security and Access Control . . . . . . . . . . . . . . . = =C2=A031
=C2=A0 =C2=A0 =C2=A03.7. =C2=A0Energy Management . . . . . . . . . .= . . . . . . . . . . =C2=A033
=C2=A0 =C2=A0 = =C2=A03.8. =C2=A0SW Distribution . . . . . . . . . . . . . . . . . . . . . = =C2=A035
=C2=A0 =C2=A0 =C2=A03.9. =C2=A0Traffic management =C2=A0. . . . . . = . . . . . . . . . . . . . =C2=A036
=C2=A0 =C2=A0 = =C2=A03.10. Transport Layer . . . . . . . . . . . . . . . . . . . . . =C2= =A037
=C2=A0 =C2=A0 =C2=A03.11. Implementation Requirements . . . . . . . . .= . . . . . . =C2=A039
=C2=A0 =C2=A04= . =C2=A0IANA Considerations . . . . . . . . . . . . . . . . . . . . . =C2= =A040
=C2=A0 =C2=A05. =C2=A0Security Considerations . . . . . . . . . . . . .= . . . . . . =C2=A040
=C2=A0 =C2=A06= . =C2=A0Contributors =C2=A0. . . . . . . . . . . . . . . . . . . . . . . . = =C2=A041
=C2=A0 =C2=A07. =C2=A0Acknowledgments . . . . . . . . . . . . . . . = . . . . . . . . =C2=A041
=C2=A0 =C2=A08= . =C2=A0Informative References =C2=A0. . . . . . . . . . . . . . . . . . . = =C2=A041
=C2=A0 =C2=A0Appendix A. =C2=A0Change Log . . . . . . . . . . . . . = . . . . . . . . =C2=A042
=C2=A0 =C2=A0 = =C2=A0A.1. =C2=A0draft-ietf-opsawg-coman-probstate-reqs-01 - draft-ietf-
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opsawg-coman-probstate-reqs-02 =C2=A0= . . . . . . . . . . . . . =C2=A042
=C2=A0 =C2=A0 = =C2=A0A.2. =C2=A0draft-ietf-opsawg-coman-probstate-reqs-00 - draft-ietf-
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opsawg-coman-probstate-reqs-01 =C2=A0= . . . . . . . . . . . . . =C2=A042
=C2=A0 =C2=A0 = =C2=A0A.3. =C2=A0draft-ersue-constrained-mgmt-03 - draft-ietf-opsawg-
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0coman-probstate-reqs-00 . . . . . . . . .= . . . . . . . . =C2=A043
=C2=A0 =C2=A0 = =C2=A0A.4. =C2=A0draft-ersue-constrained-mgmt-02-03 =C2=A0. . . . . . . . .= . . =C2=A043
=C2=A0 =C2=A0 =C2=A0A.5. =C2=A0draft-ersue-constrained-mgmt-01-= 02 =C2=A0. . . . . . . . . . . =C2=A044
=C2=A0 =C2=A0 = =C2=A0A.6. =C2=A0draft-ersue-constrained-mgmt-00-01 =C2=A0. . . . . . . . .= . . =C2=A045
=C2=A0 =C2=A0Authors' Addresses =C2=A0. . . . . . . . . . .= . . . . . . . . . . . . =C2=A045


=



=



=
Ersue, e= t al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 2]
=0C
= Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 July 2014


1. =C2=A0In= troduction

1= .1. =C2=A0Overview

=C2=A0 =C2=A0Constrained devices, aka. sensor, smart ob= ject, or smart device, with
=C2=A0 =C2=A0l= imited CPU, memory, and power resources, can constitute a network.
=C2=A0 =C2= =A0Such a network of constrained devices itself may be constrained or
=C2=A0 =C2=A0c= hallenged, e.g., with unreliable or lossy channels, wireless
=C2=A0 =C2=A0tec= hnologies with limited bandwidth and a dynamic topology, needing
TW> please = add energy limitations
=C2=A0 =C2=A0the service of a gateway or proxy to conn= ect to the Internet. =C2=A0In
=C2=A0 =C2=A0o= ther scenarios, the constrained devices can be connected to a non-
=C2=A0 =C2= =A0constrained network using off-the-shelf protocol stacks.

=C2=A0 =C2= =A0Constrained devices might be in charge of gathering information in
=C2=A0 = =C2=A0diverse settings including natural ecosystems, buildings, and<= /div>
TW> factori= es*,* and
=C2=A0 =C2=A0factories and send the information to one or more serv= er stations.
=C2=A0 =C2=A0C= onstrained devices may also work under severe resource constraints
=C2=A0 =C2= =A0such as limited battery and computing power, little memory and
=C2=A0 =C2=A0i= nsufficient wireless bandwidth, and communication capabilities. =C2=A0A
=C2= =A0 =C2=A0central entity, e.g., a base station or controlling server, might=
=C2=A0 =C2=A0h= ave more computational and communication resources and can act as a<= /div>
=C2=A0 = =C2=A0gateway between the constrained devices and the application logic in<= /font>
=C2=A0 =C2=A0t= he core network.

=C2=A0 =C2=A0Today diverse size of constrained devices wi= th different resources
=C2=A0 =C2=A0a= nd capabilities are being connected. =C2=A0Mobile personal gadgets,<= /div>
=C2=A0 = =C2=A0building-automation devices, cellular phones, Machine-to-machine
=C2=A0 =C2=A0(= M2M) devices, etc. benefit from interacting with other "things" i= n
= =C2=A0 =C2=A0the near or somewhere in the Internet. =C2=A0With this the Int= ernet of
TW> reality= build -> reality, built
=C2=A0 =C2=A0Things (IoT) becomes a reality bui= ld up of uniquely identifiable
=C2=A0 =C2=A0o= bjects (things). =C2=A0And over the next decade, this could grow to<= /div>
TW> wo= w, that's 3 orders of magnitude more than people. I see wild prediction= s
TW> going t= o tens of billions, but not thousands. Maybe "billions"?
=C2=A0 =C2= =A0trillions of constrained devices and will greatly increase the
=C2=A0 =C2=A0I= nternet's size and scope.

=C2=A0 =C2=A0Network management is character= ized by monitoring network status,
=C2=A0 =C2=A0d= etecting faults, and inferring their causes, setting network
=C2=A0 =C2=A0par= ameters, and carrying out actions to remove faults, maintain
=C2=A0 =C2=A0n= ormal operation, and improve network efficiency and application
=C2=A0 =C2=A0= performance. =C2=A0The traditional network monitoring application
=C2=A0 =C2=A0p= eriodically collects information from a set of elements that are
TW> to ma= nage, to process [...] to present
=C2=A0 =C2=A0n= eeded to manage, processes the data, and presents them to the
<= div>=C2=A0 =C2=A0ne= twork management users. =C2=A0Constrained devices, however, often have
TW> please = specify unreliable. I would say that they may be inter-connected
TW> throu= gh unreliable links to one another, and to the Internet
=C2=A0 =C2=A0l= imited power, low transmission range, and might be unreliable. =C2=A0They
=C2= =A0 =C2=A0might also need to work in hostile environments with advanced
=C2=A0 =C2=A0s= ecurity requirements or need to be used in harsh environments for a<= /div>
=C2=A0 = =C2=A0long time without supervision. =C2=A0Due to such constraints, the
TW> typo ty= pe*s*
=C2=A0 =C2=A0management of a network with constrained devices faces dif= ferent type
=C2=A0 =C2=A0o= f challenges compared to the management of a traditional IP network.=



Ersue, et al.= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 3]
=0C
= Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 July 2014


=C2=A0 =C2= =A0The IETF has already done substantial standardization work to enable
=C2=A0 =C2=A0the co= mmunication in IP networks and to manage such networks as well
=C2=A0 =C2=A0a= s the manifold type of nodes in these networks [RFC6632]. =C2=A0However,
=C2= =A0 =C2=A0the IETF so far has not developed any specific technologies for t= he
=C2=A0 =C2=A0m= anagement of constrained devices and the networks comprised by
=
=C2=A0 =C2=A0c= onstrained devices. =C2=A0IP-based sensors or constrained devices in such
=C2=A0 =C2=A0a= n environment, i.e., devices with very limited memory and CPU
<= div>TW> please a= dd energy
TW> use tod= ay*'s*
=C2=A0 =C2=A0resources, use today application-layer protocols in a= n ad-hoc manner
=C2=A0 =C2=A0t= o do simple resource management and monitoring.

=C2=A0 =C2=A0This document= provides a problem statement and lists the requirements
=C2=A0 =C2=A0f= or the management of a network with constrained devices.
<= font color=3D"#000000" face=3D"courier new, monospace">=C2=A0 =C2=A0Section= 1.3 and Section 1.5 describe different topology options for
=C2=A0 =C2=A0t= he networking and management of constrained devices. =C2=A0Section 2=
=C2=A0 = =C2=A0provides a problem statement on the issue of the management of=
=C2=A0 =C2=A0n= etworked constrained devices. =C2=A0Section 3 lists requirements on the
=C2= =A0 =C2=A0management of applications and networks with constrained devices.=
=C2=A0 =C2=A0N= ote that the requirements listed in Section 3 have been separated
=C2=A0 =C2= =A0from the context in which they may appear.
TW> Hmm. po= ipoi TODO
=C2=A0 =C2=A0Depending on the concrete
=C2=A0 =C2=A0circumstances, an= implementer may decide to address a certain
=C2=A0 =C2=A0r= elevant subset of the requirements.

=C2=A0 =C2=A0The use cases in the cont= ext of networks with constrained devices can
=C2=A0 =C2=A0b= e found in the companion document [COM-USE].

1.2. =C2=A0Terminology

=C2=A0 =C2= =A0Concerning constrained devices and networks this document generally
=C2=A0= =C2=A0builds on the terminology defined in [RFC7228], where the terms
=C2=A0 =C2=A0C= onstrained Device, Constrained Network, etc. are defined.
=
=C2=A0 =C2=A0The= following terms are additionally used throughout this
=C2=A0 =C2=A0d= ocumentation:

=C2=A0 =C2=A0AMI: =C2=A0(Advanced Metering Infrastructure) A= system including hardware,
=C2=A0 =C2=A0 = =C2=A0 software, and networking technologies that measures, collects, and
=C2= =A0 =C2=A0 =C2=A0 analyzes energy usage, and communicates with a hierarchic= ally
=C2=A0 =C2=A0 = =C2=A0 deployed network of metering devices, either on request or on a
=C2=A0= =C2=A0 =C2=A0 schedule.

=C2=A0 =C2= =A0C0: =C2=A0Class 0 constrained device as defined in Section 3. of<= /div>
=C2=A0 = =C2=A0 =C2=A0 [RFC7228].

=C2=A0 =C2= =A0C1: =C2=A0Class 1 constrained device as defined in Section 3. of<= /div>
=C2=A0 = =C2=A0 =C2=A0 [RFC7228].

=C2=A0 =C2= =A0C2: =C2=A0Class 2 constrained device as defined in Section 3. of<= /div>
=C2=A0 = =C2=A0 =C2=A0 [RFC7228].


=

Ersue, et al. = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 4]
=0C<= /div>
Internet-= Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 July 2014


=
=C2=A0 = =C2=A0Network of Constrained Devices: =C2=A0A network to which constrained<= /font>
=C2=A0 =C2=A0 = =C2=A0 devices are connected that may or may not be a Constrained Network
=C2= =A0 =C2=A0 =C2=A0 (see [RFC7228] for the definition of the term Constrained=
=C2=A0 =C2=A0 = =C2=A0 Network).

=C2=A0 =C2=A0M2M: =C2=A0(Machine to Machine) stands for t= he automatic data transfer
=C2=A0 =C2=A0 = =C2=A0 between devices of different kind. =C2=A0In M2M scenarios a device
=C2= =A0 =C2=A0 =C2=A0 (such as a sensor or meter) captures an event, which is r= elayed
=C2=A0 =C2=A0 = =C2=A0 through a network (wireless, wired or hybrid) to an application.

<= /font>
= =C2=A0 =C2=A0MANET: =C2=A0Mobile Ad-hoc Networks [RFC2501], a self-configur= ing and
=C2=A0 =C2=A0 = =C2=A0 infrastructureless network of mobile devices connected by wireless
=C2= =A0 =C2=A0 =C2=A0 technologies.

=C2=A0 =C2= =A0Smart Grid: =C2=A0An electrical grid that uses communication technologie= s
=C2=A0 =C2=A0 =C2= =A0 to gather and act on information in an automated fashion to
=C2=A0 =C2=A0 = =C2=A0 improve the efficiency, reliability and sustainability of the=
=C2=A0 = =C2=A0 =C2=A0 production and distribution of electricity.

=C2=A0 =C2= =A0Smart Meter: =C2=A0An electrical meter in the context of a Smart Grid.
= =C2=A0 =C2=A0 =C2=A0 For a detailed discussion on the constrained networks = as well as
=C2=A0 =C2=A0 =C2=A0 classes of constrained devices and their capa= bilities please see
=C2=A0 =C2=A0 = =C2=A0 [RFC7228].

1.3. =C2=A0Network Types and Characteristics in Focus

=C2=A0 =C2= =A0In this document we differentiate following types of networks
=C2=A0 =C2= =A0concerning their transport and communication technologies:

=C2=A0 =C2= =A0(Note that a network in general can involve constrained and non-<= /div>
=C2=A0 = =C2=A0constrained devices.)

=C2=A0 =C2= =A01. =C2=A0Wireline non-constrained networks, e.g., an Ethernet-LAN with
=C2= =A0 =C2=A0 =C2=A0 =C2=A0constrained and non-constrained devices involved.

=C2=A0 =C2= =A02. =C2=A0A combination of wireline and wireless networks, possibly with = a
=C2=A0 =C2=A0 =C2= =A0 =C2=A0multi-hop connectivity between constrained devices, utilizing
=C2=A0 =C2=A0 = =C2=A0 =C2=A0dynamic routing in both the wireless and wireline portions of = the
=C2=A0 =C2=A0 = =C2=A0 =C2=A0applications with many nodes (e.g., environmental monitoring) = and
=C2=A0 =C2=A0 = =C2=A0 =C2=A0Wireless Mesh Networks (WMN), as a specific variant, use off-t= he-
=C2=A0 =C2=A0 = =C2=A0 =C2=A0WMNs are reliable based on the redundancy they offer and have<= /font>
= =C2=A0 =C2=A0 =C2=A0 =C2=A0often a more planned deployment to provide dynam= ic and cost
=C2=A0 =C2=A0 = =C2=A0 =C2=A0effective connectivity over a certain geographic area.<= /div>


<= br>
Ersue, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January= 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 5]
=0C
= Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 July 2014


=C2=A0 =C2= =A03. =C2=A0A combination of wireline and wireless networks with point-to-<= /font>
= =C2=A0 =C2=A0 =C2=A0 =C2=A0point or point-to-multipoint communication gener= ally with single-
TW> Hmm. Th= e statement that IEEE802.15.4 networks are generally single-hop and<= /div>
TW> in= volve static routing contradicts the work done in ROLL and 6LoWPAN, 6lo
TW> and 6Ti= SCH. Consider removing?
=C2=A0 =C2=A0 =C2=A0 =C2=A0hop connectivity to constr= ained devices, utilizing static routing
=C2=A0 =C2=A0 = =C2=A0 =C2=A0over the wireless network. =C2=A0Such networks support short-r= ange,
=C2=A0 =C2=A0 =C2=A0 =C2=A0point-to-point, low-data-rate, source-to-sin= k type of
=C2=A0 =C2=A0 = =C2=A0 =C2=A0applications such as RFID systems, light switches, fire and sm= oke
=C2=A0 =C2=A0 = =C2=A0 =C2=A0support confined short-range spaces such as a home, a factory,= a
=C2=A0 =C2=A0 =C2=A0 =C2=A0building, or the human body. =C2=A0IEEE 802.15.= 1 (Bluetooth) and IEEE
=C2=A0 =C2=A0 = =C2=A0 =C2=A0802.15.4 are well-known examples of applicable standards for s= uch

=C2=A0 =C2= =A04. =C2=A0Self-configuring infrastructureless networks of mobile devices<= /font>
= =C2=A0 =C2=A0 =C2=A0 =C2=A0(e.g., Mobile Adhoc networks, MANET) are a parti= cular type of
=C2=A0 =C2=A0 = =C2=A0 =C2=A0network connected by wireless technologies. =C2=A0Infrastructu= reless
=C2=A0 =C2=A0 =C2=A0 =C2=A0networks are mostly based on point-to-point= communications of
=C2=A0 =C2=A0 = =C2=A0 =C2=A0devices moving independently in any direction and changing the=
= =C2=A0 =C2=A0 =C2=A0 =C2=A0links to other devices frequently. =C2=A0Such de= vices do act as a
=C2=A0 =C2=A0 = =C2=A0 =C2=A0router to forward traffic unrelated to their own use.

=C2=A0 = =C2=A0Wireline non-constrained networks with constrained and non-
=C2=A0 =C2=A0c= onstrained devices are mainly used for specific applications like
=C2=A0 =C2= =A0Building Automation or Infrastructure Monitoring. =C2=A0Wireline and
=C2=A0 =C2=A0w= ireless networks with multi-hop or point-to-multipoint connectivity<= /div>
=C2=A0 = =C2=A0are used e.g., for environmental monitoring as well as transport and<= /font>
=C2=A0 =C2=A0m= obile applications.
TW> add industrial applications for the latter (e.g. W= irelessHART, 6TiSCH)

=C2=A0 =C2= =A0Furthermore different network characteristics are determined by
=C2=A0 =C2= =A0multiple dimensions: dynamicity of the topology, bandwidth, and loss
=C2=A0 =C2=A0r= ate. =C2=A0In the following, each dimension is explained, and networks in
=C2= =A0 =C2=A0scope for this document are outlined:

TW> I do= n't quite understand why this draft introduces so many terms,
TW> networking t= opologies, etc. Can it not simply references a number of RFCs?
=
TW> RFC5867= , RFC5826, RFC5673, RFC5548 seem to give a good overview of LLN
TW> use cas= es

=C2=A0 =C2=A0Network Topology:

=C2=A0 =C2= =A0The topology of a network can be represented as a graph, with edges
=C2=A0= =C2=A0(i.e., links) and vertices (routers and hosts). =C2=A0Examples of
=C2=A0 =C2=A0d= ifferent topologies include "star" topologies (with one central n= ode
=C2=A0 =C2=A0n= ode having exactly one parent), directed acyclic graphs (with each
=C2=A0 =C2= =A0node having one or more parents), clustered topologies (where one or
=C2=A0 =C2=A0m= ore "cluster heads" are responsible for a certain area of the
=C2= =A0 =C2=A0network), mesh topologies (fully distributed), etc.

=C2=A0 =C2= =A0Management protocols may take advantage of specific network
=
=C2=A0 =C2=A0t= opologies, for example by distributing large-scale management tasks<= /div>
=C2=A0 =C2=A0a= mongst multiple distributed network management stations (e.g., in
TW> woul= dn't cluster-based topologies not be a better fit here?
=C2=A0 =C2=A0c= ase of a mesh topology), or by using a hierarchical management
=


<= br>
Ersue, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January= 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 6]
=0C
= Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 July 2014


=C2=A0 =C2= =A0approach (e.g., in case of a tree topology). =C2=A0These different
=C2=A0 = =C2=A0management topology options are described in Section 1.6.

=C2=A0 =C2= =A0Note that in certain network deployments, such as community ad hoc
=C2=A0 = =C2=A0networks (see the use case "Community Network Applications"= in [COM-
=C2=A0 =C2=A0U= SE]), the topology is not pre-planned, and thus may be unknown for
=C2=A0 =C2= =A0management purposes. =C2=A0In other use cases, such as industrial=
=C2=A0 =C2=A0a= pplications (see the use case "Industrial Applications" in [COM-<= /font>
= =C2=A0 =C2=A0USE]), the topology may be designed in advance and therefore t= aken
=C2=A0 =C2=A0a= dvantage of when managing the network.

=C2=A0 =C2=A0Dynamicity of the netw= ork topology:

=C2=A0 =C2= =A0The dynamicity of the network topology determines the rate of change
TW> per time -&g= t; as a function of time
=C2=A0 =C2=A0o= f the graph per time. =C2=A0Such changes can occur due to different<= /div>
=C2=A0 = =C2=A0factors, such as mobility of nodes (e.g., in MANETs or cellular
=C2=A0 =C2=A0n= etworks), duty cycles (for low-power devices enabling their network<= /div>
=C2=A0 = =C2=A0interface only periodically to transmit or receive packets), or
=C2=A0 =C2=A0u= nstable links (in particular wireless links with strongly
= =C2=A0 =C2=A0fluctu= ating link quality).

=C2=A0 =C2= =A0Examples of different levels of dynamicity of the topology are
=C2=A0 =C2= =A0Ethernets (with typically a very static topology) on the one side,
=C2=A0 =C2=A0a= nd low-power and lossy networks (LLNs) on the other side. =C2=A0LLNs=
TW> L= LN nodes often using duty cycles -> LLN nodes are often duty-cycled
=C2=A0 =C2=A0n= odes often using duty cycles, operate on unreliable wireless links
=C2=A0 =C2= =A0and are potentially mobile (e.g., for sensor networks).

TW> &quo= t;The more dynamic the topology is"
=C2=A0 =C2=A0The more the topology i= s dynamic, the more routing, transport and
=C2=A0 =C2=A0a= pplication layer protocols have to cope with interrupted
<= font color=3D"#000000" face=3D"courier new, monospace">=C2=A0 =C2=A0connect= ivity and/or longer delays. =C2=A0For example, management protocols<= /div>
=C2=A0 =C2=A0(= with a given underlying transport protocol) that expect continuous
=C2=A0 =C2= =A0session flows without changes of routes during a communication flow,
=C2=A0 =C2=A0m= ay fail to operate.

=C2=A0 =C2=A0Networks with a very low dynamicity (e.g.= , Ethernet) with no or
=C2=A0 =C2=A0i= nfrequent topology changes (e.g., less than once every 30 minutes),<= /div>
=C2=A0 = =C2=A0are in-scope of this document if they are used with constrained
=C2=A0 =C2=A0d= evices (see e.g., the use case "Building Automation" in [COM-USE]= ).

=C2=A0 =C2=A0T= raffic flows:

=C2=A0 =C2=A0The traffic flow in a network determines from w= hich sources data
=C2=A0 =C2=A0t= raffic is sent to which destinations in the network. =C2=A0Several
=C2=A0 =C2= =A0different traffic flows are defined in [RFC7102], including "point-=
=C2=A0 =C2=A0t= o-point" (P2P), "multipoint-to-point" (MP2P), and "poin= t-to-
=C2=A0 =C2=A0multipoint" (P2MP) flows as:


=



=
Ersue, e= t al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 7]
=0C
= Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 July 2014

TW> add das= hes, i.e. "Point-To-Point"?
=C2=A0 =C2=A0o =C2=A0P2P: Point To Poin= t. =C2=A0This refers to traffic exchanged between two
=C2=A0 =C2=A0 = =C2=A0 nodes (regardless of the number of hops between the two nodes).

=C2= =A0 =C2=A0o =C2=A0P2MP: Point-to-Multipoint traffic refers to traffic betwe= en one
=C2=A0 =C2=A0 = =C2=A0 node and a set of nodes. =C2=A0This is similar to the P2MP concept i= n
= =C2=A0 =C2=A0 =C2=A0 Multicast or MPLS Traffic Engineering.

=C2=A0 =C2= =A0o =C2=A0MP2P: Multipoint-to-Point is used to describe a particular traff= ic
=C2=A0 =C2=A0 =C2= =A0 pattern (e.g., MP2P flows collecting information from many nodes=
=C2=A0 = =C2=A0 =C2=A0 flowing inwards towards a collecting sink).

=C2=A0 =C2= =A0If one of these traffic patterns is predominant in a network,
=C2=A0 =C2= =A0protocols (routing, transport, application) may be optimized for the
=C2=A0 =C2=A0s= pecific traffic flow. =C2=A0For example, in a network with a tree
=C2=A0 =C2= =A0topology and MP2P traffic, collection tree protocols are efficient to
=C2=A0 =C2=A0s= end data from the leaves of the tree to the root of the tree, via
=C2=A0 =C2= =A0each node's parent.

=C2=A0 =C2= =A0Bandwidth:

=C2=A0 =C2=A0T= he bandwidth of the network is the amount of data that can be sent
TW> per= *unit of* time?
=C2=A0 =C2=A0p= er time between two communication end-points. =C2=A0It is usually
=C2=A0 =C2= =A0determined by the link with the minimum bandwidth on the path from
=C2=A0 =C2=A0t= he source to the destination of data packets. =C2=A0The bandwidth in=
=C2=A0 = =C2=A0networks can range from a few Kilobytes per second (such as on some
=C2=A0 =C2=A08= 02.15.4 link layers) to many Gigabytes per second (e.g., on fiber
=C2=A0 =C2= =A0optics).

=C2=A0 =C2=A0For= management purposes, the management protocol typically requires
=C2=A0 =C2= =A0to send information between the network management station and the
=C2=A0 =C2=A0c= lients, for monitoring or control purposes. =C2=A0If the available
=C2=A0 =C2= =A0bandwidth is insufficient for the management protocol, packets will
=C2=A0 =C2=A0b= e buffered and eventually dropped, and thus management is not
<= div>=C2=A0 =C2=A0po= ssible with such a protocol.

=C2=A0 =C2= =A0Networks without bandwidth limitation (e.g., Ethernet) are in-scope
=C2=A0= =C2=A0of this document if they are used with constrained devices (see the<= /font>
=C2=A0 =C2=A0u= se case "Building Automation" in [COM-USE]).

= =C2=A0 =C2=A0Loss r= ate:

=C2=A0 =C2= =A0The loss rate (or bit error rate) is the number of bit errors divided
=C2=A0 =C2=A0by the= total number of bits transmitted. =C2=A0For wired networks, loss
=C2=A0 =C2= =A0rates are typically extremely low, e.g., around 10^-12 or 10^-13 for
=C2=A0 =C2=A0t= he latest 10Gbit Ethernet. =C2=A0For wireless networks, such as 802.15.4,
=C2= =A0 =C2=A0the bit error rate can be as high as 10^-1 to 10^-0 in case of
TW> missing= space below
=C2=A0 =C2=A0interferences.Even when using a reliable transport = protocol,


=


Ersue, et a= l. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 8]
=0C
Inter= net-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 July 2014


=C2=A0 =C2= =A0management operations can fail if the loss rate is too high, unless
=C2=A0= =C2=A0they are specifically designed to cope with these situations.=

1.4. =C2=A0= Constrained Device Deployment Options

= =C2=A0 =C2=A0We differentiate following deployment options for the constrai= ned

=C2=A0 =C2= =A0o =C2=A0A network of constrained devices that communicate with each othe= r,

=C2=A0 =C2=A0o = =C2=A0Constrained devices, which are connected directly to an IP
=C2=A0 =C2= =A0 =C2=A0 network,

=C2=A0 =C2= =A0o =C2=A0A network of constrained devices which communicate with a gatewa= y
=C2=A0 =C2=A0 =C2= =A0 or proxy with more communication capabilities acting possibly as a
=C2=A0 =C2=A0 = =C2=A0 representative of the device to entities in the non-constrained
=C2=A0= =C2=A0 =C2=A0 network

=C2=A0 =C2= =A0o =C2=A0Constrained devices, which are connected to the Internet or an I= P
=C2=A0 =C2=A0 =C2= =A0 network via a gateway/proxy

=C2=A0 =C2= =A0o =C2=A0A hierarchy of constrained devices, e.g., a network of C0 device= s
=C2=A0 =C2=A0 =C2= =A0 connected to one or more C1 devices - connected to one or more C2
=C2=A0 =C2=A0 = =C2=A0 devices - connected to one or more gateways - connected to some
=C2=A0= =C2=A0 =C2=A0 application servers or NMS system

=C2=A0 =C2= =A0o =C2=A0The possibility of device grouping (possibly in a dynamic manner= )
=C2=A0 =C2=A0 =C2= =A0 such as that the grouped devices can act as one logical device at
=C2=A0 =C2=A0 = =C2=A0 the edge of the network and one device in this group can act as
=C2=A0= =C2=A0 =C2=A0 the managing entity

1.5. =C2=A0= Management Topology Options

= =C2=A0 =C2=A0We differentiate following options for the management of netwo= rks of
=C2=A0 =C2=A0constrained devices:

=C2=A0 =C2= =A0o =C2=A0A network of constrained devices managed by one central manager.=
= =C2=A0 =C2=A0 =C2=A0 A logically centralized management might be implemente= d in a
=C2=A0 =C2=A0 = =C2=A0 hierarchical fashion for scalability and robustness reasons. =C2=A0T= he
=C2=A0 =C2=A0 =C2=A0 manager and the management application logic might ha= ve a gateway/
=C2=A0 =C2=A0 = =C2=A0 proxy in between or might be on different nodes in different<= /div>
=C2=A0 = =C2=A0 =C2=A0 networks, e.g., management application running on a cloud ser= ver.

=C2=A0 =C2= =A0o =C2=A0Distributed management, where a network of constrained devices i= s
=C2=A0 =C2=A0 =C2= =A0 managed by more than one manager. =C2=A0Each manager controls a<= /div>
TW> subnet = is a very loaded word. Maybe refer to "a portion of the network"?=
= =C2=A0 =C2=A0 =C2=A0 subnetwork and may communicate directly with other man= ager
=C2=A0 =C2=A0 = =C2=A0 stations in a cooperative fashion. =C2=A0The distributed management = may


=

Ersue, et al. = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 9]
=0C<= /div>
Internet-= Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 July 2014


=
=C2=A0 = =C2=A0 =C2=A0 assigned to many managers dynamically, or strongly distribute= d,
=C2=A0 =C2=A0 = =C2=A0 where almost all managed things have embedded management
=C2=A0 =C2=A0= =C2=A0 functionality and explicit management disappears, which usually
=C2=A0 =C2=A0 = =C2=A0 comes with the price that the strongly distributed management=
=C2=A0 = =C2=A0 =C2=A0 logic now needs to be managed.

=C2=A0 =C2= =A0o =C2=A0Hierarchical management, where a hierarchy of networks with
=C2=A0= =C2=A0 =C2=A0 constrained devices are managed by the managers at their
=C2=A0 =C2=A0 = =C2=A0 corresponding hierarchy level. =C2=A0I.e., each manager is responsib= le
=C2=A0 =C2=A0 =C2=A0 for managing the nodes in its sub-network. =C2=A0It p= asses information
=C2=A0 =C2=A0 = =C2=A0 from its sub-network to its higher-level manager, and disseminates
=C2= =A0 =C2=A0 =C2=A0 management functions received from the higher-level manag= er to its
=C2=A0 =C2=A0 = =C2=A0 sub-network. =C2=A0Hierarchical management is essentially a scalabil= ity

poipoipoi
1.6. =C2=A0Man= aging the Constrainedness of a Device or Network

=C2=A0 =C2=A0The capabili= ties of a constrained device or network and the
=C2=A0 =C2=A0c= onstrainedness thereof influence and have an impact on the
=C2=A0 =C2=A0requi= rements for the management of such network or devices.

=C2=A0 =C2= =A0Note that the list below gives examples and does not claim
<= div>=C2=A0 =C2=A0co= mpleteness.

=C2=A0 =C2= =A0A constrained device:

T= W> Strictly speaking, the radios are reliable, but the links are lossy= =C2=A0
TW> Maybe rephrase to "are connected by radio links which are = unreliably in
TW> nature&= quot;
=C2=A0 =C2=A0o =C2=A0might only support an unreliable radio with lossy = links, i.e., the
=C2=A0 =C2=A0 = =C2=A0 client and server of a management protocol need to gracefully=
TW> I= n my experience, packet corruption is caught at several layers throughout
TW> the sta= ck, and I doubt it is possible for the management protocol to
<= div>TW> receive = "incomplete" commands. Maybe I'm missing something.
TW> With un= reliable links, I believe the management protocol needs to
TW> gracefully = handle changes in latency, timeouts and retransmissions.
=C2=A0 =C2=A0 = =C2=A0 ignore incomplete commands or repeat commands as necessary.

=C2=A0 = =C2=A0o =C2=A0might only be able to go online from time-to-time, where it i= s
=C2=A0 =C2=A0 = =C2=A0 reachable, i.e., a command might be necessary to repeat after a
=C2=A0= =C2=A0 =C2=A0 longer timeout or the timeout value with which one endpoint = waits
=C2=A0 =C2=A0 = =C2=A0 on a response needs to be sufficiently high.

=C2=A0 =C2=A0o =C2=A0m= ight only be able to support a limited operating time (e.g.,
=C2=A0 =C2=A0 = =C2=A0 based on the available battery), or may behave as 'sleepy=
=C2=A0 = =C2=A0 =C2=A0 endpoints' setting their network links to a disconnected = state
=C2=A0 =C2=A0 = =C2=A0 during long periods of time i.e., the devices need to economize
=C2=A0= =C2=A0 =C2=A0 their energy usage with suitable mechanisms and the managing=
=C2=A0 =C2=A0 = =C2=A0 entity needs to monitor and control the energy status of the<= /div>
=C2=A0 = =C2=A0 =C2=A0 constrained devices it manages.

=C2=A0 =C2= =A0o =C2=A0might only be able to support one simple communication protocol,=
= =C2=A0 =C2=A0 =C2=A0 i.e., the management protocol needs to be possible to = downscale
=C2=A0 =C2=A0 = =C2=A0 from constrained (C2) to very constrained (C0) devices with
=C2=A0 =C2= =A0 =C2=A0 modular implementation and a very basic version with just a few<= /font>
=C2=A0 =C2=A0 = =C2=A0 simple commands.


<= br>
= Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 July 2014


=C2=A0 =C2= =A0o =C2=A0might only be able to support limited or no user and/or transpor= t
=C2=A0 =C2=A0 =C2= =A0 security, i.e., the management system needs to support a less-
=C2=A0 =C2=A0 = =C2=A0 costly and simple but sufficiently secure authentication
=C2=A0 =C2=A0= =C2=A0 mechanism.

=C2=A0 =C2=A0o = =C2=A0might not be able to support compression and decompression of<= /div>
=C2=A0 = =C2=A0 =C2=A0 exchanged data based on limited CPU power, i.e., an intermedi= ary
=C2=A0 =C2=A0 = =C2=A0 entity which is capable of data compression should be able to=
=C2=A0 = =C2=A0 =C2=A0 communicate with both, devices that support data compression<= /font>
=C2=A0 =C2=A0 = =C2=A0 (e.g., C2) and devices that do not support data compression (e.g.,
=C2= =A0 =C2=A0 =C2=A0 C1 and C0).

=C2=A0 =C2= =A0o =C2=A0might only be able to support a simple encryption, i.e., it woul= d
=C2=A0 =C2=A0 =C2= =A0 be beneficial if the devices use cryptographic algorithms that are
=C2=A0 =C2=A0 = =C2=A0 supported in hardware and the encryption used is efficient in=
TW> t= ypo memeory -> memory
=C2=A0 =C2=A0 = =C2=A0 terms of memeory and CPU usage.

=C2=A0 =C2=A0o =C2=A0might only be = able to communicate with one single managing entity
=C2=A0 =C2=A0 = =C2=A0 and cannot support the parallel access of many managing entities.

=
=C2=A0 =C2=A0o =C2= =A0might depend on a self-configuration feature, i.e., the managing<= /div>
=C2=A0 =C2=A0 = =C2=A0 entity might not know all devices in a network and the device=
=C2=A0 = =C2=A0 =C2=A0 needs to be able to initiate connection setup for the device<= /font>
=C2=A0 =C2=A0 = =C2=A0 configuration.

=C2=A0 =C2=A0o =C2=A0might depend on self- or neighb= or-monitoring feature, i.e., the
=C2=A0 =C2=A0 = =C2=A0 managing entity might not be able to monitor all devices in a=
=C2=A0 = =C2=A0 =C2=A0 network continuously.

=C2=A0 =C2= =A0o =C2=A0might only be able to communicate with its neighbors, i.e., the<= /font>
= =C2=A0 =C2=A0 =C2=A0 device should be able to get its configuration from a = neighbor.

=C2=A0 =C2= =A0o =C2=A0might only be able to support parsing of data models with limite= d
=C2=A0 =C2=A0 =C2= =A0 size, i.e., the device data models need to be compact containing=
=C2=A0 =C2=A0 = =C2=A0 the most necessary data and if possible parsable as a stream.=

=C2= =A0 =C2=A0o =C2=A0might only be able to support a limited or no failure det= ection,
=C2=A0 =C2=A0 = =C2=A0 i.e., the managing entity needs to handle the situation, where a
=C2= =A0 =C2=A0 =C2=A0 failure does not get detected or gets detected late grace= fully
=C2=A0 =C2=A0 = =C2=A0 e.g., with asking repeatedly.

=C2=A0 =C2=A0o =C2=A0might only be ab= le to support the reporting of just one or a
=C2=A0 =C2=A0 = =C2=A0 limited set failure types.

=C2=A0 =C2=A0o =C2=A0might only be able = to support a limited set of notifications,
=C2=A0 =C2=A0 = =C2=A0 possible only an "I-am-alive" message.

=C2=A0 =C2=A0o =C2= =A0might only be able to support a soft-reset from failure recovery.=


=

Ersue, et al. = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 11]
=0C
=
Internet-Draft= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 July 2014


=
=C2=A0 = =C2=A0o =C2=A0might possibly generate a large amount of redundant reporting=
=C2=A0 =C2=A0 = =C2=A0 data, i.e., the intermediary management entity (see [RFC7252])
=C2=A0 = =C2=A0 =C2=A0 should be able to filter and aggregate redundant data.=

=C2=A0 =C2= =A0A network of constrained devices:

T= W> same discussion about the term "unreliable radio" applies h= ere
=C2=A0 =C2=A0 = =C2=A0 client and server of a management protocol need to repeat commands
=C2= =A0 =C2=A0 =C2=A0 as necessary or gracefully ignore incomplete commands.

=C2=A0 =C2= =A0o =C2=A0might be necessary to manage based on multicast communication,
=C2= =A0 =C2=A0 =C2=A0 i.e., the managing entity needs to be prepared to configu= re many
=C2=A0 =C2=A0 = =C2=A0 devices at once based on the same data model.

=C2=A0 =C2=A0o =C2=A0= might have a very large topology supporting 10,000 or more nodes
=C2=A0 =C2=A0 = =C2=A0 for some applications and as such node naming is a specific issue
=C2= =A0 =C2=A0 =C2=A0 for constrained networks.

=C2=A0 =C2= =A0o =C2=A0must be able to self-organize, i.e., given the large number of
=C2= =A0 =C2=A0 =C2=A0 nodes and their potential placement in hostile locations = and
=C2=A0 =C2=A0 = =C2=A0 frequently changing topology, manual configuration of nodes is
TW> = As such*,*
=C2=A0 =C2=A0 = =C2=A0 typically not feasible. =C2=A0As such the network must be able to
=C2= =A0 =C2=A0 =C2=A0 reconfigure itself so that it can continue to operate pro= perly and
=C2=A0 =C2=A0 = =C2=A0 support reliable connectivity.

=C2=A0 =C2=A0o =C2=A0needs a managem= ent solution that is energy-efficient, using as
=C2=A0 =C2=A0 = =C2=A0 little wireless bandwidth as possible since communication is<= /div>
=C2=A0 = =C2=A0 =C2=A0 highly energy demanding.

TW> whil= e very important in some cases, this seems not to be the general case.
TW> maybe p= refix by "In some cases,"?
=C2=A0 =C2=A0o =C2=A0needs to support lo= calization schemes to determine the location of
=C2=A0 =C2=A0 = =C2=A0 devices since the devices might be moving and location information
=C2= =A0 =C2=A0 =C2=A0 is important for some applications.

=C2=A0 =C2= =A0o =C2=A0needs a management solution that is scalable as the network may<= /font>
= =C2=A0 =C2=A0 =C2=A0 consist of thousands of nodes and may need to be exten= ded
=C2=A0 =C2=A0 = =C2=A0 continuously.

=C2=A0 =C2=A0o =C2=A0needs to provide fault tolerance= . =C2=A0Faults in network operation
=C2=A0 =C2=A0 = =C2=A0 including hardware and software errors or failures detected by the
TW&= gt; I don't understand "should be handled smoothly enabling"<= /font>
=C2=A0 =C2=A0 = =C2=A0 transport protocol should be handled smoothly enabling. =C2=A0In suc= h a
=C2=A0 =C2=A0 = =C2=A0 reduced level but avoiding to fail completely. =C2=A0E.g., self-
=C2= =A0 =C2=A0 =C2=A0 monitoring mechanisms or graceful degradation of features= can be
=C2=A0 =C2=A0 = =C2=A0 used to provide fault tolerance.

=C2=A0 =C2=A0o =C2=A0might require= new management capabilities: for example, network
=C2=A0 =C2=A0 = =C2=A0 coverage information and a constrained device power-distribution-
=C2= =A0 =C2=A0 =C2=A0 map.


=

Ersue, et al. = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 12]
=0C
=
Internet-Draft= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 July 2014


=
=C2=A0 = =C2=A0o =C2=A0might require a new management function for data management, = since
=C2=A0 =C2=A0 = =C2=A0 the type and amount of data collected in constrained networks is
=C2= =A0 =C2=A0 =C2=A0 different from those of the traditional networks.<= /div>

=C2=A0 =C2= =A0o =C2=A0might also need energy-efficient key management.

1= .7. =C2=A0Configuration and Monitoring Functionality Levels

=
=C2=A0 =C2=A0D= evices often differ significantly on the level of configuration
=C2=A0 =C2=A0m= anagement support they provide. =C2=A0This document classifies the
=C2=A0 =C2= =A0configuration management functionality as follows:

TW> I ha= ve two low-end cases in mind which are believe are commonplace, but<= /div>
TW> I don&#= 39;t know in which category it fits:
TW> - the device can only bec configu= red by physically connecting a device to
TW> =C2=A0 = it and changing the configuration. This might be a handheld with a serial
TW&= gt; =C2=A0 cable.
TW> - the d= evice's configuration is contained in some flash memory card. An=
TW> = =C2=A0 operate reconfigures a device by swapping its configuration card.
=C2=A0 =C2=A0<= /font>
= =C2=A0 =C2=A0CL0: =C2=A0Devices are pre-configured and allow no runtime con= figuration
TW> hard coded -> hard-coded?
=C2=A0 =C2=A0 = =C2=A0 changes. =C2=A0Configuration parameters are often hard coded and
=C2= =A0 =C2=A0 =C2=A0 compiled directly into the firmware image.

=C2=A0 =C2= =A0CL1: =C2=A0Devices have explicit configuration objects. =C2=A0However, c= hanges
=C2=A0 =C2=A0 =C2= =A0 require a restart of the device to take effect.

=C2=A0 =C2= =A0CL2: =C2=A0Devices allow management systems to replace the entire=
=C2=A0 = =C2=A0 =C2=A0 configuration (or pre-determined subsets) in bulk. =C2=A0Conf= iguration
=C2=A0 =C2=A0 = =C2=A0 changes take effect by soft-restarts of the system (or
<= div>=C2=A0 =C2=A0 = =C2=A0 subsystems).

=C2=A0 =C2=A0CL3= : =C2=A0Devices allow management systems to modify configuration
=C2=A0 =C2= =A0 =C2=A0 objects without bulk replacements and changes take effect=
=C2=A0 =C2=A0 = =C2=A0 immediately.

=C2=A0 =C2=A0CL4: =C2=A0Devices support multiple confi= guration datastores and they
=C2=A0 =C2=A0 = =C2=A0 might distinguish between the currently running and the next<= /div>
=C2=A0 = =C2=A0 =C2=A0 startup configuration.

=C2=A0 =C2= =A0CL5: =C2=A0Devices support configuration datastore locking and device-
=C2= =A0 =C2=A0 =C2=A0 local configuration change transactions, i.e., either all=
=C2=A0 =C2=A0 = =C2=A0 configuration changes are applied or none of them.
=
=C2=A0 =C2=A0CL6= : =C2=A0Devices support configuration change transactions across
=C2=A0 =C2=A0 = =C2=A0 devices.

=C2=A0 =C2=A0This document defines a classification of dev= ices with regards to
=C2=A0 =C2=A0d= ifferent levels of monitoring support. =C2=A0In general a device may be
=C2= =A0 =C2=A0in several of the levels listed below:

TW> I ha= ve a monitoring use case which I believe to be common, but I
TW> have a hard = time seeing to which category it belongs:
TW> - a dev= ice logs noteworthy event to a flash drive connected to it. An
=
TW> =C2=A0 = operator collects those, and analyzes those logs, possibly much later.


=
=C2=A0 = =C2=A0ML0: =C2=A0Devices push pre-defined monitoring data.

=C2=A0 =C2= =A0ML1: =C2=A0Devices allow management systems to pull pre-defined monitori= ng
=C2=A0 =C2=A0 =C2= =A0 data.




=
Ersue, e= t al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 13]
=0C
= Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 July 2014


=C2=A0 =C2= =A0ML2: =C2=A0Devices allow management systems to pull user-defined filtere= d
=C2=A0 =C2=A0 =C2= =A0 subsets of monitoring data.

=C2=A0 =C2= =A0ML3: =C2=A0Devices are able to locally process monitoring data in order = to
=C2=A0 =C2=A0 =C2= =A0 detect threshold crossings or to aggregate data.

=C2=A0 =C2=A0At the t= ime of this writing, constrained devices often implement a
=C2=A0 =C2=A0c= ombination of one of CL0-CL2 with one of ML0-ML1.

2. =C2=A0Problem Stateme= nt

=C2=A0 =C2= =A0The terminology for the "Internet of Things" is still nascent,= and
=C2=A0 =C2=A0d= epending on the network type or layer in focus diverse technologies<= /div>
=C2=A0 = =C2=A0and terms are in use. =C2=A0Common to all these considerations is the=
=C2=A0 =C2=A0&= quot;Things" or "Objects" are supposed to have physical or v= irtual
=C2=A0 =C2=A0identities using interfaces to communicate. =C2=A0In this= context, we need
=C2=A0 =C2=A0t= o differentiate between the Constrained and Smart Devices identified=
=C2=A0 = =C2=A0by an IP address compared to virtual entities such as Smart Objects,<= /font>
=C2=A0 =C2=A0w= hich can be identified as a resource or a virtual object by using a<= /div>
=C2=A0 = =C2=A0unique identifier. =C2=A0Furthermore, the smart devices usually have = a
=C2=A0 =C2=A0l= imited memory and CPU power as well as aim to be self-configuring
=C2=A0 =C2= =A0and easy to deploy.

=C2=A0 =C2= =A0However, the constraints of the network nodes requires a rethinking
=C2=A0= =C2=A0of the protocol characteristics concerning power consumption,=
TW> please = add network bandwidth
=C2=A0 =C2=A0performance, memory, and CPU usage. =C2=A0= As such, there is a demand for
=C2=A0 =C2=A0p= rotocol simplification, energy-efficient communication, less CPU
TW> small= *er*?
=C2=A0 =C2=A0u= sage and small memory footprint.

=C2=A0 =C2=A0On the application layer the= IETF is already developing protocols
=C2=A0 =C2=A0l= ike the Constrained Application Protocol (CoAP) [RFC7252] enabling
=C2=A0 =C2= =A0the communication of constrained devices and networks e.g., for smart
=C2=A0 =C2=A0e= nergy applications or home automation environments. =C2=A0The deployment
=C2= =A0 =C2=A0of such an environment involves in fact many, in some scenarios u= p to
=C2=A0 =C2=A0m= illion constrained devices (e.g., smart meters), which produce a
=C2=A0 =C2= =A0large amount of data. =C2=A0This data needs to be collected, filtered, a= nd
=C2=A0 =C2=A0p= re-processed for further use in diverse services.

TW> think on -> th= ink about?
=C2=A0 =C2=A0C= onsidering the high number of nodes to deploy, one has to think on
=C2=A0 =C2= =A0the manageability aspects of the smart devices and plan for easy<= /div>
=C2=A0 =C2=A0d= eployment, configuration, and management of the networks of
=C2=A0 =C2=A0cons= trained devices as well as the devices themselves. =C2=A0Consequently,
=C2=A0 =C2=A0s= eamless monitoring and self-configuration of such network nodes
=C2=A0 =C2=A0= becomes more and more imperative. =C2=A0Self-configuration and self-=
=C2=A0 =C2=A0m= anagement is already a reality in the standards of some of the
=
=C2=A0 =C2=A0b= odies such as 3GPP. =C2=A0To introduce self-configuration of smart
=C2=A0 =C2=A0d= evices successfully a device-initiated connection establishment is
=C2=A0 =C2= =A0required.

TW> In s= ome cases, the management entity might establish connection with a
TW> joining= device during commisionning (i.e. wake-up). I don't have a good=
TW> e= xample, and I certainly agree that the devices should establish a
TW> connect= ion in most cases, but I would no sat "is required". Maybe "= is often
TW> required"?


=

Ersue, et al. = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 14]
=0C
=
Internet-Draft= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 July 2014


=
=C2=A0 = =C2=A0A simple and efficient application layer protocol, such as CoAP, is
=C2=A0 =C2=A0e= ssential to address the issue of efficient object-to-object
=C2=A0 =C2=A0comm= unication and information exchange. =C2=A0Such an information exchange
=C2=A0 =C2=A0s= hould be done based on interoperable data models to enable the
=
=C2=A0 =C2=A0e= xchange and interpretation of diverse application and management
=C2=A0 =C2=A0r= elated data.

=C2=A0 =C2=A0In an ideal world, we would have only one networ= k management protocol
=C2=A0 =C2=A0f= or monitoring, configuration, and exchanging management data,
<= div>=C2=A0 =C2=A0in= dependently of the type of the network (e.g., Smart Grid, wireless
=C2=A0 =C2=A0a= ccess, or core network). =C2=A0Furthermore, it would be desirable to=
=C2=A0 = =C2=A0derive the basic data models for constrained devices from the core
=C2=A0 =C2=A0m= odels used today to enable reuse of functionality and end-to-end
=C2=A0 =C2= =A0information exchange. =C2=A0However, the current management protocols se= em
=C2=A0 =C2=A0t= o be too heavyweight compared to the capabilities the constrained
=C2=A0 =C2= =A0devices have and are not applicable directly for the use in a network
=C2=A0 =C2=A0o= f constrained devices. =C2=A0Furthermore, the data models addressing the
=C2= =A0 =C2=A0requirements of such smart devices need yet to be designed.

=C2=A0 =C2= =A0The IETF so far has not developed any specific technologies for the
=C2=A0= =C2=A0management of constrained devices and the networks comprised by
=C2=A0 =C2=A0c= onstrained devices. =C2=A0IP-based sensors or constrained devices in such
=C2= =A0 =C2=A0an environment, i.e., devices with very limited memory and CPU
=C2=A0 =C2=A0r= esources, use today, e.g., application-layer protocols to do simple<= /div>
=C2=A0 = =C2=A0resource management and monitoring. =C2=A0This might be sufficient fo= r
=C2=A0 =C2=A0s= ome basic cases, however, there is a need to reconsider the network<= /div>
=C2=A0 = =C2=A0management mechanisms based on the new, changed, as well as reduced
=C2=A0 =C2=A0r= equirements coming from smart devices and the network of such
<= div>=C2=A0 =C2=A0co= nstrained devices. =C2=A0Albeit it is questionable whether we can take
=C2=A0 =C2=A0t= he same comprehensive approach we use in an IP network also for the<= /div>
=C2=A0 = =C2=A0management of constrained devices. =C2=A0Hence, the management of a
=C2=A0 =C2=A0n= etwork with constrained devices is necessary to design in a
=C2=A0 =C2=A0simp= lified and less complex manner.

TW> typo= characterists -> characteristics
=C2=A0 =C2=A0As Section 1.6 highlights, = there are diverse characterists of
=C2=A0 =C2=A0c= onstrained devices or networks, which stem from their
=C2=A0 =C2=A0constraine= dness and therefore have an impact on the requirements for
=C2=A0 =C2=A0t= he management of such a network with constrained devices. =C2=A0The use
=C2= =A0 =C2=A0cases discussed in [COM-USE] show that the requirements on=
=C2=A0 =C2=A0c= onstrained networks are manifold and need to be analyzed from
<= div>=C2=A0 =C2=A0di= fferent angles, e.g., concerning the design of the management
=C2=A0 =C2=A0a= rchitecture, the selection of the appropriate protocol features as
=C2=A0 =C2= =A0well as the specific issues which are new in the context of
=C2=A0 =C2=A0c= onstrained devices. =C2=A0Examples of such issues are e.g., the careful
=C2= =A0 =C2=A0management of the scarce energy resources, the necessity for self= -
=C2=A0 =C2=A0o= rganization and self-management of such devices but also the
=C2=A0 =C2=A0imp= lementation considerations to enable the use of common
=C2=A0 =C2=A0c= ommunication technologies on a constrained hardware in an efficient<= /div>


<= br>
= Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 July 2014


=C2=A0 =C2= =A0manner. =C2=A0For an exhaustive list of issues and requirements that nee= d
=C2=A0 =C2=A0to be = addressed for the management of a network with constrained
=C2=A0 =C2=A0d= evices please see Section 1.6 and Section 3.

3. =C2=A0Requirements on th= e Management of Networks with Constrained Devices

=C2=A0 =C2= =A0This section describes the requirements categorized by management=
=C2=A0 = =C2=A0areas listed in subsections.

=C2=A0 =C2= =A0Note that the requirements listed in this section have been separated
=C2=A0 =C2=A0from t= he context in which they may appear. =C2=A0This document in general<= /div>
=C2=A0 = =C2=A0does not recommend the realization of any subset of the described
=C2=A0 =C2=A0r= equirements. =C2=A0As such this document avoids selecting any of the=
=C2=A0 = =C2=A0requirements as mandatory to implement. =C2=A0A device might be able = to
=C2=A0 =C2=A0p= rovide only a particular selected set of requirements and might not<= /div>
=C2=A0 = =C2=A0be capable to provide all requirements in this document. =C2=A0On the=
=C2=A0 =C2=A0o= ther hand a device vendor might select a specific relevant subset of=
=C2=A0 = =C2=A0the requirements to implement.

TW> *The= * following?
=C2=A0 =C2=A0Following template is used for the definition of th= e requirements.

TW> &quo= t;An ID uniquely identified" reads strange. Rephrase to "A unique= 3-digit
TW> identif= ier"?
=C2=A0 =C2=A0Req-ID: =C2=A0An ID uniquely identified by a three-di= git number

=C2=A0 =C2= =A0Title: =C2=A0The title of the requirement.

= =C2=A0 =C2=A0Description: =C2=A0The rational and description of the require= ment.

=C2=A0 =C2=A0S= ource: =C2=A0The origin of the requirement and the matching use case or
=C2= =A0 =C2=A0 =C2=A0 application. =C2=A0For the discussion of referred use cas= es for
=C2=A0 =C2=A0 = =C2=A0 constrained management please see [COM-USE].

=C2=A0 =C2=A0Requireme= nt Type: =C2=A0Functional Requirement, Non-Functional
=C2=A0 =C2=A0 = =C2=A0 Requirement. =C2=A0A functional requirement is related to a function= or
=C2=A0 =C2=A0 = =C2=A0 details, or specific functionality that define what a system is
=C2=A0= =C2=A0 =C2=A0 supposed to accomplish. =C2=A0Non-functional requirements (a= lso known
=C2=A0 =C2=A0 = =C2=A0 as design constraints or quality requirements) impose
TW> implement= ation-related?
=C2=A0 =C2=A0 = =C2=A0 implementation related considerations such as performance
=C2=A0 =C2= =A0 =C2=A0 requirements, security, or reliability.

TW> plea= se add RFC reference
=C2=A0 =C2=A0Device type: =C2=A0The device types by whic= h this requirement can be
=C2=A0 =C2=A0 = =C2=A0 supported: C0, C1 and/or C2.

TW> I'm a bit surprised the pri= ority depends on the class of device. In my mind
TW> some re= quirement are of high priority because they are really needed.
=
TW> Whether= it's implemented on a C0 or C2 shouldn't matter. At the most, some=
TW> require= ments cannot be satisfied by low-end devices.
=C2=A0 =C2=A0Priority: =C2=A0T= he priority of the requirement showing its importance for
=C2=A0 =C2=A0 = =C2=A0 a particular type of device: High, Medium, and Low. The priority
=C2= =A0 =C2=A0 =C2=A0 of a requirement can be High e.g., for a C2 device but Lo= w for a
=C2=A0 =C2=A0 = =C2=A0 C1 or C0 device as the realization of complex features in a C1
=C2=A0 = =C2=A0 =C2=A0 device is in many cases not possible.


=

Ersue, et al. = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 16]
=0C
=
Internet-Draft= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 July 2014


=
3.1. =C2= =A0Management Architecture/System

=C2=A0 =C2= =A0Req-ID: =C2=A01.001

= =C2=A0 =C2=A0Title: =C2=A0Support multiple device classes within a single n= etwork.

=C2=A0 =C2=A0D= escription: =C2=A0Larger networks usually consist of devices belonging to
=C2= =A0 =C2=A0 =C2=A0 different device classes (e.g., constrained mesh endpoint= s and
=C2=A0 =C2=A0 = =C2=A0 less constrained routers) communicating with each other. =C2=A0Hence= ,
= =C2=A0 =C2=A0 =C2=A0 the management architecture must be applicable to netw= orks that
=C2=A0 =C2=A0 = =C2=A0 have a mix of different device classes. =C2=A0See Section 3. of
=C2=A0= =C2=A0 =C2=A0 [RFC7228] for the definition of Constrained Device Classes.<= /font>

=C2=A0 =C2= =A0Source: =C2=A0All use cases.

= =C2=A0 =C2=A0Requirement Type: =C2=A0Non-Functional Requirement

=C2=A0 =C2= =A0Device type: =C2=A0C1 and/or C2

=C2=A0 =C2= =A0Priority: =C2=A0High

= =C2=A0 =C2=A0---

=C2=A0 =C2=A0Req-ID: =C2=A01.002

=C2=A0 =C2= =A0Title: =C2=A0Management scalability.

= =C2=A0 =C2=A0Description: =C2=A0The management architecture must be able to= scale with
=C2=A0 =C2=A0 =C2=A0 the number of devices involved and operate e= fficiently in any
=C2=A0 =C2=A0 = =C2=A0 network size and topology. =C2=A0This implies that e.g., the managin= g
= =C2=A0 =C2=A0 =C2=A0 entity is able to handle large amounts of device monit= oring data
=C2=A0 =C2=A0 = =C2=A0 and the management protocol is not sensitive to the decrease of
=C2=A0= =C2=A0 =C2=A0 the time between two client requests. =C2=A0To achieve good<= /font>
=C2=A0 =C2=A0 = =C2=A0 scalability, caching techniques, in-network data aggregation<= /div>
=C2=A0 = =C2=A0 =C2=A0 techniques, hierarchical management models may be used.

=C2=A0 =C2= =A0Source: =C2=A0General requirement for all use cases to enable large scal= e
=C2=A0 =C2=A0 =C2= =A0 networks.

=C2=A0 =C2= =A0Requirement Type: =C2=A0Non-Functional Requirement

= =C2=A0 =C2=A0Device type: =C2=A0C0, C1, and C2

=C2=A0 =C2=A0Priority: =C2= =A0High

=C2=A0 =C2= =A0---

=C2=A0 =C2=A0R= eq-ID: =C2=A01.003


<= br>
= Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 July 2014


=C2=A0 =C2= =A0Title: =C2=A0Hierarchical management

= =C2=A0 =C2=A0Description: =C2=A0Provide a means of hierarchical management,= i.e.,
=C2=A0 =C2=A0 =C2=A0 provide intermediary management entities on diffe= rent levels,
=C2=A0 =C2=A0 = =C2=A0 which can take over the responsibility for the management of a
=C2=A0 = =C2=A0 =C2=A0 sub-hierarchy of the network of constraint devices. =C2=A0The=
=C2=A0 =C2=A0 = =C2=A0 intermediary management entity can e.g., support management data
=C2= =A0 =C2=A0 =C2=A0 aggregation to handle e.g., high-frequent monitoring data= or
TW> RFC6550= uses the terms "upward" and "downward". Maybe use thos= e here too?
=C2=A0 =C2=A0 =C2=A0 provide a caching mechanism for the uplink a= nd downlink
=C2=A0 =C2=A0 = =C2=A0 communication. =C2=A0Hierarchical management contributes to manageme= nt
=C2=A0 =C2=A0 =C2=A0 scalability.

=C2=A0 =C2= =A0Source: =C2=A0Use cases where a large amount of devices are deployed wit= h
=C2=A0 =C2=A0 =C2= =A0 a hierarchical topology.

=C2=A0 =C2= =A0Requirement Type: =C2=A0Non-Functional Requirement

= =C2=A0 =C2=A0Device type: =C2=A0Managing and intermediary entities.<= /div>

=C2=A0= =C2=A0Priority: =C2=A0Medium

=C2=A0 =C2= =A0---

=C2=A0 =C2=A0R= eq-ID: =C2=A01.004

=C2=A0 =C2=A0Title: =C2=A0Minimize state maintained on = constrained devices.

=C2=A0 =C2= =A0Description: =C2=A0The amount of state that needs to be maintained on
=C2= =A0 =C2=A0 =C2=A0 constrained devices should be minimized. =C2=A0This is im= portant in
=C2=A0 =C2=A0 = =C2=A0 order to save memory (especially relevant for C0 and C1 devices)
=C2= =A0 =C2=A0 =C2=A0 and in order to allow devices to restart for example to a= pply
=C2=A0 =C2=A0 = =C2=A0 configuration changes or to recover from extended periods of<= /div>
=C2=A0 = =C2=A0 =C2=A0 inactivity.

=C2=A0 =C2= =A0Note: =C2=A0One way to achieve this is to adopt a RESTful architecture
=C2= =A0 =C2=A0 =C2=A0 that minimizes the amount of state maintained by managed<= /font>
=C2=A0 =C2=A0 = =C2=A0 constrained devices and that makes resources of a device
=C2=A0 =C2=A0= =C2=A0 addressable via URIs.

=C2=A0 =C2= =A0Source: =C2=A0Basic requirement which concerns all use cases.

= =C2=A0 =C2=A0Requirement Type: =C2=A0Functional Requirement

=
=C2=A0 =C2=A0D= evice type: =C2=A0C0, C1, and C2

=C2=A0 =C2= =A0Priority: =C2=A0High

= =C2=A0 =C2=A0---


<= br>
= Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 July 2014


=C2=A0 =C2= =A0Req-ID: =C2=A01.005

= =C2=A0 =C2=A0Title: =C2=A0Automatic re-synchronization with eventual consis= tency.

=C2=A0 =C2=A0D= escription: =C2=A0To support large scale networks, where some constrained
=C2= =A0 =C2=A0 =C2=A0 devices may be offline at any point in time, it is necess= ary to
=C2=A0 =C2=A0 = =C2=A0 distribute configuration parameters in a way that allows temporary
=C2= =A0 =C2=A0 =C2=A0 inconsistencies but eventually converges, after a suffici= ently
=C2=A0 =C2=A0 = =C2=A0 long period of time without further changes, towards global
=C2=A0 =C2= =A0 =C2=A0 consistency.

=C2=A0 =C2= =A0Source: =C2=A0Use cases with large scale networks with many devices.

= =C2=A0 =C2=A0Requirement Type: =C2=A0Functional Requirement

=
=C2=A0 =C2=A0D= evice type: =C2=A0C0, C1, and C2

=C2=A0 =C2= =A0Priority: =C2=A0High

= =C2=A0 =C2=A0---

=C2=A0 =C2=A0Req-ID: =C2=A01.006

=C2=A0 =C2= =A0Title: =C2=A0Support for lossy links and unreachable devices.

= =C2=A0 =C2=A0Description: =C2=A0Some constrained devices will only be able = to support
=C2=A0 =C2=A0 =C2=A0 lossy and unreliable links characterized by a= limited data rate, a
TW> Further= more*,*
=C2=A0 =C2=A0 =C2=A0 high latency, and a high transmission error rate= . =C2=A0Furthermore
=C2=A0 =C2=A0 = =C2=A0 constrained devices often duty cycle their radio or the whole=
TW> l= abelled -> labeled
=C2=A0 =C2=A0 = =C2=A0 device in order to save energy. =C2=A0Some classes of devices labell= ed
=C2=A0 =C2=A0 =C2=A0 as 'sleepy endpoints' set their network links= to a disconnected
=C2=A0 =C2=A0 = =C2=A0 state during long periods of time. =C2=A0In all cases the management=
= =C2=A0 =C2=A0 =C2=A0 system must not assume that constrained devices are al= ways
=C2=A0 =C2=A0 = =C2=A0 reachable.

=C2=A0 =C2=A0Source: =C2=A0Basic requirement for network= s of constrained devices with
=C2=A0 =C2=A0 = =C2=A0 unreliable links and constrained devices that sleep to save
=C2=A0 =C2= =A0 =C2=A0 energy.

=C2=A0 =C2=A0Req= uirement Type: =C2=A0Non-Functional Requirement

= =C2=A0 =C2=A0Device type: =C2=A0C0, C1, and C2

=C2=A0 =C2=A0Priority: =C2= =A0High

=C2=A0 =C2= =A0---

=C2=A0 =C2=A0R= eq-ID: =C2=A01.007


<= br>
= Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 July 2014


=C2=A0 =C2= =A0Title: =C2=A0Network-wide configuration

= =C2=A0 =C2=A0Description: =C2=A0Provide means by which the behavior of the = network can
=C2=A0 =C2=A0 =C2=A0 be specified at a level of abstraction (netw= ork-wide
=C2=A0 =C2=A0 = =C2=A0 configuration) higher than a set of configuration information=
=C2=A0 = =C2=A0 =C2=A0 specific to individual devices. =C2=A0It is useful to derive = the device
=C2=A0 =C2=A0 = =C2=A0 specific configuration from the network-wide configuration. =C2=A0Su= ch
=C2=A0 =C2=A0 =C2=A0 a repository can be used to configure pre-defined dev= ice or
=C2=A0 =C2=A0 = =C2=A0 protocol parameters for the whole network. =C2=A0Furthermore, such a=
= =C2=A0 =C2=A0 =C2=A0 network-wide view can be used to monitor and manage a = group of
=C2=A0 =C2=A0 = =C2=A0 routers or a whole network. =C2=A0E.g., monitoring the performance o= f a
=C2=A0 =C2=A0 = =C2=A0 acquired from a single router using a management protocol.

=
=C2=A0 = =C2=A0Note: =C2=A0The identification of the relevant subset of the policies= to
=C2=A0 =C2=A0 = =C2=A0 be provisioned is according to the capabilities of each device and
=C2= =A0 =C2=A0 =C2=A0 can be obtained from a pre-configured data-repository.

=C2=A0 =C2= =A0Source: =C2=A0In general all use cases of network and device configurati= on
=C2=A0 =C2=A0 =C2= =A0 based on a network view in a top-down manner.

=C2=A0 =C2=A0Requirement= Type: =C2=A0Non-Functional Requirement

=C2=A0 =C2= =A0Device type: =C2=A0C0, C1, and C2

= =C2=A0 =C2=A0Priority: =C2=A0Medium

=C2=A0 =C2=A0---

=C2=A0 =C2= =A0Req-ID: =C2=A01.008

= =C2=A0 =C2=A0Title: =C2=A0Distributed Management

=C2=A0 =C2=A0Description:= =C2=A0Provide a means of simple distributed management, where
=C2=A0 =C2=A0 = =C2=A0 a network of constrained devices can be managed or monitored by
=C2=A0= =C2=A0 =C2=A0 more than one manager. =C2=A0Since the connectivity to a ser= ver cannot
=C2=A0 =C2=A0 = =C2=A0 be guaranteed at all times, a distributed approach may provide a
=C2= =A0 =C2=A0 =C2=A0 higher reliability, at the cost of increased complexity. = =C2=A0This
=C2=A0 =C2=A0 = =C2=A0 requirement implies the handling of data consistency in case of
=C2=A0= =C2=A0 =C2=A0 concurrent read and write access to the device datastore. = =C2=A0It
=C2=A0 =C2=A0 = =C2=A0 might also happen that no management (configuration) server is
=C2=A0 = =C2=A0 =C2=A0 accessible and the only reachable node is a peer device. =C2= =A0In this
=C2=A0 =C2=A0 = =C2=A0 case the device should be able to obtain its configuration from
=C2=A0= =C2=A0 =C2=A0 peer devices.

=C2=A0 =C2= =A0Source: =C2=A0Use cases where the count of devices to manage is high.

= =C2=A0 =C2=A0Requirement Type: =C2=A0Non-Functional Requirement


<= br>
= Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 July 2014


=C2=A0 =C2= =A0Device type: =C2=A0C1 and C2

= =C2=A0 =C2=A0Priority: =C2=A0Medium

3.2. =C2=A0Management protocols and da= ta model

=C2=A0 =C2= =A0Req-ID: =C2=A02.001

= =C2=A0 =C2=A0Title: =C2=A0Modular implementation of management protocols

=
= =C2=A0 =C2=A0Description: =C2=A0Management protocols should be specified to= allow for
=C2=A0 =C2=A0 = =C2=A0 modular implementations, i.e., it should be possible to implement
=C2= =A0 =C2=A0 =C2=A0 only a basic set of protocol primitives on highly constra= ined
=C2=A0 =C2=A0 = =C2=A0 devices while devices with additional resources may provide more
=C2= =A0 =C2=A0 =C2=A0 support for additional protocol primitives. =C2=A0See Sec= tion 1.7 for a
=C2=A0 =C2=A0 = =C2=A0 discussion on the level of configuration management and monitoring
=C2= =A0 =C2=A0 =C2=A0 support constrained devices may provide.

=C2=A0 =C2= =A0Source: =C2=A0Basic requirement interesting for all use cases.

= =C2=A0 =C2=A0Requirement Type: =C2=A0Non-Functional Requirement

=C2=A0 =C2= =A0Device type: =C2=A0C0, C1, and C2

=C2=A0 =C2= =A0Priority: =C2=A0High

= =C2=A0 =C2=A0---

=C2=A0 =C2=A0Req-ID: =C2=A02.002

=C2=A0 =C2= =A0Title: =C2=A0Compact encoding of management data

= =C2=A0 =C2=A0Description: =C2=A0The encoding of management data should be c= ompact and
=C2=A0 =C2=A0 =C2=A0 space efficient, enabling small message sizes= .

=C2=A0 =C2= =A0Source: =C2=A0General requirement to save memory for the receiver buffer=
= =C2=A0 =C2=A0 =C2=A0 and on-air bandwidth.

=C2=A0 =C2= =A0Requirement Type: =C2=A0Functional Requirement

= =C2=A0 =C2=A0Device type: =C2=A0C0, C1, and C2

=C2=A0 =C2=A0Priority: =C2= =A0High

=C2=A0 =C2= =A0---

=C2=A0 =C2=A0R= eq-ID: =C2=A02.003


<= br>
Ersue, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January= 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 21]<= /div>
=0C
= Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 July 2014


=C2=A0 =C2= =A0Title: =C2=A0Compression of management data or complete messages<= /div>

= =C2=A0 =C2=A0Description: =C2=A0Management data exchanges can be further op= timized by
=C2=A0 =C2=A0 =C2=A0 applying data compression techniques or delta= encoding techniques.
=C2=A0 =C2=A0 = =C2=A0 Compression typically requires additional code size and some<= /div>
=C2=A0 = =C2=A0 =C2=A0 additional buffers and/or the maintenance of some additional = state
=C2=A0 =C2=A0 = =C2=A0 information. =C2=A0For C0 devices compression may not be feasible.
= =C2=A0 =C2=A0Source: =C2=A0Use cases where it is beneficial to reduce trans= mission time
=C2=A0 =C2=A0 = =C2=A0 and bandwidth, e.g., mobile applications which require to save on-
=C2= =A0 =C2=A0 =C2=A0 air bandwidth.

=C2=A0 =C2= =A0Requirement Type: =C2=A0Functional Requirement

= =C2=A0 =C2=A0Device type: =C2=A0C1 and C2

=C2=A0 =C2=A0Priority: =C2=A0M= edium

=C2=A0 =C2= =A0---

=C2=A0 =C2=A0R= eq-ID: =C2=A02.004

=C2=A0 =C2=A0Title: =C2=A0Mapping of management protoco= l interactions.

=C2=A0 =C2= =A0Description: =C2=A0It is desirable to have a loss-less automated mapping=
= =C2=A0 =C2=A0 =C2=A0 between the management protocol used to manage constra= ined devices
=C2=A0 =C2=A0 = =C2=A0 and the management protocols used to manage regular devices. =C2=A0I= n
= =C2=A0 =C2=A0 =C2=A0 the ideal case, the same core management protocol can = be used with
=C2=A0 =C2=A0 = =C2=A0 certain restrictions taking into account the resource limitations
=C2= =A0 =C2=A0 =C2=A0 of constrained devices. =C2=A0However, for very resource = constrained
=C2=A0 =C2=A0 = =C2=A0 devices, this goal might not be achievable.

=C2=A0 =C2=A0Source: = =C2=A0Use cases where high-frequent interaction with the
=C2=A0 =C2=A0 = =C2=A0 management system of a non-constrained network is required.

=C2=A0 = =C2=A0Requirement Type: =C2=A0Functional Requirement

=C2=A0 =C2= =A0Device type: =C2=A0C1 and C2

= =C2=A0 =C2=A0Priority: =C2=A0Medium

=C2=A0 =C2=A0---

=C2=A0 =C2= =A0Req-ID: =C2=A02.005

= =C2=A0 =C2=A0Title: =C2=A0Consistency of data models with the underlying in= formation
=C2=A0 =C2=A0 =C2=A0 model.


=


Ersue, et a= l. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 22]
=0C
Inter= net-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 July 2014


=C2=A0 =C2= =A0Description: =C2=A0The data models used by the management protocol must = be
=C2=A0 =C2=A0 =C2= =A0 consistent with the information model used to define data models=
=C2=A0 = =C2=A0 =C2=A0 for non-constrained networks. =C2=A0This is essential to faci= litate the
=C2=A0 =C2=A0 = =C2=A0 integration of the management of constrained networks with the
=C2=A0 = =C2=A0 =C2=A0 management of non-constrained networks. =C2=A0Using an underl= ying
=C2=A0 =C2=A0 = =C2=A0 information model for future data model design enables furthermore
=C2= =A0 =C2=A0 =C2=A0 top-down model design and model reuse as well as data
=C2=A0 =C2=A0 = =C2=A0 interoperability (i.e., exchange of management information between
=C2= =A0 =C2=A0 =C2=A0 the constrained and non-constrained networks). =C2=A0This= is a strong
=C2=A0 =C2=A0 = =C2=A0 requirement, even despite the fact that the underlying information
=C2= =A0 =C2=A0 =C2=A0 models are often not explicitly documented in the IETF.

=C2=A0 =C2= =A0Source: =C2=A0General requirement to support data interoperability,
=C2=A0= =C2=A0 =C2=A0 consistency and model reuse.

=C2=A0 =C2= =A0Requirement Type: =C2=A0Non-Functional Requirement

= =C2=A0 =C2=A0Device type: =C2=A0C0, C1, and C2

=C2=A0 =C2=A0Priority: =C2= =A0High

=C2=A0 =C2= =A0---

=C2=A0 =C2=A0R= eq-ID: =C2=A02.006
TW> I believe "Lossless" can be a single word=
=C2=A0 =C2=A0Title:= =C2=A0Loss-less mapping of management data models.

=C2=A0 =C2= =A0Description: =C2=A0It is desirable to have a loss-less automated mapping=
= =C2=A0 =C2=A0 =C2=A0 between the management data models used to manage regu= lar devices
=C2=A0 =C2=A0 = =C2=A0 and the management data models used for managing constrained<= /div>
=C2=A0 = =C2=A0 =C2=A0 devices. =C2=A0In the ideal case, the same core data models c= an be used
=C2=A0 =C2=A0 = =C2=A0 with certain restrictions taking into account the resource
=C2=A0 =C2= =A0 =C2=A0 limitations of constrained devices. =C2=A0However, for very reso= urce
=C2=A0 =C2=A0 = =C2=A0 constrained devices, this goal might not be achievable.
=

=C2=A0 =C2= =A0Source: =C2=A0Use cases where consistent data exchange with the manageme= nt
=C2=A0 =C2=A0 = =C2=A0 system of a non-constrained network is required.

=C2=A0 =C2=A0Requi= rement Type: =C2=A0Functional Requirement

=C2=A0 =C2= =A0Device type: =C2=A0C2

= =C2=A0 =C2=A0Priority: =C2=A0Medium

=C2=A0 =C2=A0---

=C2=A0 =C2= =A0Req-ID: =C2=A02.007

<= br>

E= rsue, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 20= 15 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 23]
<= div>=0C
I= nternet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 July 2014


=
=C2=A0 = =C2=A0Title: =C2=A0Protocol extensibility

=C2=A0 =C2= =A0Description: =C2=A0Provide means of extensibility for the management
=C2= =A0 =C2=A0 =C2=A0 protocol, i.e., by adding new protocol messages or mechan= isms that
TW> deal wi= th the changing requirements -> deal with changing requirements
=C2=A0 =C2= =A0 =C2=A0 can deal with the changing requirements on a supported message a= nd
TW> inter-o= perability -> interoperability
=C2=A0 =C2=A0 =C2=A0 data types effectively= , without causing inter-operability problems
=C2=A0 =C2=A0 = =C2=A0 or having to replace/update large amount of deployed devices.=

=C2= =A0 =C2=A0Source: =C2=A0Basic requirement useful for all use cases.<= /div>

=C2=A0 =C2= =A0Requirement Type: =C2=A0Functional Requirement

= =C2=A0 =C2=A0Device type: =C2=A0C0, C1, and C2

=C2=A0 =C2=A0Priority: =C2= =A0High

3.3. =C2=A0= Configuration management

= =C2=A0 =C2=A0Req-ID: =C2=A03.001

=C2=A0 =C2=A0Title: =C2=A0Self-configurat= ion capability

=C2=A0 =C2= =A0Description: =C2=A0Automatic configuration and re-configuration of devic= es
=C2=A0 =C2=A0 =C2= =A0 without manual intervention. =C2=A0Compared to the traditional
=C2=A0 =C2= =A0 =C2=A0 management of devices where the management application is the
=C2=A0 =C2=A0 = =C2=A0 central entity configuring the devices, in the auto-configuration
=C2= =A0 =C2=A0 =C2=A0 scenario the device is the active part and initiates the<= /font>
=C2=A0 =C2=A0 = =C2=A0 configuration process. =C2=A0Self-configuration can be initiated dur= ing
=C2=A0 =C2=A0 = =C2=A0 the configuration data needs to be refreshed. =C2=A0Self-configurati= on
=C2=A0 =C2=A0 =C2=A0 should be also supported during the initialization ph= ase or in the
=C2=A0 =C2=A0 = =C2=A0 event of failures, where prior knowledge of the network topology
=C2= =A0 =C2=A0 =C2=A0 is not available or the topology of the network is uncert= ain.

=C2=A0 =C2= =A0Source: =C2=A0In general all use cases requiring easy deployment and
=C2= =A0 =C2=A0 =C2=A0 plug&play behavior as well as easy maintenance of man= y constrained
=C2=A0 =C2=A0 = =C2=A0 devices.

=C2=A0 =C2=A0Requirement Type: =C2=A0Functional Requiremen= t

=C2=A0 =C2= =A0Device type: =C2=A0C0, C1, and C2

= =C2=A0 =C2=A0Priority: =C2=A0High for device categories C0 and C1, Medium f= or C2.

=C2=A0 =C2=A0-= --

=C2=A0 =C2=A0Req-ID: =C2=A03.002


=


Ersue, et a= l. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 24]
=0C
Inter= net-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 July 2014


=C2=A0 =C2= =A0Title: =C2=A0Capability Discovery

= =C2=A0 =C2=A0Description: =C2=A0Enable the discovery of supported optional = management
=C2=A0 =C2=A0 =C2=A0 capabilities of a device and their exposure v= ia at least one
=C2=A0 =C2=A0 = =C2=A0 protocol and/or data model.

=C2=A0 =C2=A0Source: =C2=A0Use cases wh= ere the device interaction with other devices or
=C2=A0 =C2=A0 = =C2=A0 applications is a function of the level of support for its
=C2=A0 =C2= =A0 =C2=A0 capabilities.

=C2=A0 =C2= =A0Requirement Type: =C2=A0Functional Requirement

= =C2=A0 =C2=A0Device type: =C2=A0C1 and C2

=C2=A0 =C2=A0Priority: =C2=A0M= edium

=C2=A0 =C2= =A0---

=C2=A0 =C2=A0R= eq-ID: =C2=A03.003

=C2=A0 =C2=A0Title: =C2=A0Asynchronous Transaction Supp= ort

=C2=A0 =C2= =A0Description: =C2=A0Provide configuration management with asynchronous
=C2= =A0 =C2=A0 =C2=A0 (event-driven) transaction support. =C2=A0Configuration o= perations must
=C2=A0 =C2=A0 = =C2=A0 support a transactional model, with asynchronous indications that
=C2= =A0 =C2=A0 =C2=A0 the transaction was completed.

=C2=A0 =C2= =A0Source: =C2=A0Use cases that require transaction-oriented processing
=C2= =A0 =C2=A0 =C2=A0 because of reliability or distributed architecture functi= onal
=C2=A0 =C2=A0 = =C2=A0 requirements.

=C2=A0 =C2=A0Requirement Type: =C2=A0Functional Requi= rement

=C2=A0 =C2= =A0Device type: =C2=A0C1 and C2

= =C2=A0 =C2=A0Priority: =C2=A0Medium

=C2=A0 =C2=A0---

=C2=A0 =C2= =A0Req-ID: =C2=A03.004

= =C2=A0 =C2=A0Title: =C2=A0Network reconfiguration

=C2=A0 =C2=A0Description= : =C2=A0Provide a means of iterative network reconfiguration in
TW> did you= mean "fault" or "failure"?
=C2=A0 =C2=A0 =C2=A0 order to= recover the network from node and communication faults.
=C2=A0 =C2=A0 = =C2=A0 The network reconfiguration can be failure-driven and self-
=C2=A0 =C2= =A0 =C2=A0 initiated (automatic reconfiguration). =C2=A0The network<= /div>


=


Ersue, et a= l. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 25]
=0C
Inter= net-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 July 2014


=C2=A0 =C2= =A0 =C2=A0 reconfiguration can be also performed on the whole hierarchical<= /font>
= =C2=A0 =C2=A0 =C2=A0 structure of a network (network topology).

=C2=A0 =C2= =A0Source: =C2=A0Practically all use cases, as network connectivity is a
=C2= =A0 =C2=A0 =C2=A0 basic requirement.

=C2=A0 =C2= =A0Requirement Type: =C2=A0Functional Requirement

= =C2=A0 =C2=A0Device type: =C2=A0C0, C1, and C2

=C2=A0 =C2=A0Priority: =C2= =A0Medium

3.4. =C2=A0= Monitoring functionality

= =C2=A0 =C2=A0Req-ID: =C2=A04.001

=C2=A0 =C2=A0Title: =C2=A0Device status m= onitoring

=C2=A0 =C2= =A0Description: =C2=A0Provide a monitoring function to collect and expose
=C2= =A0 =C2=A0 =C2=A0 information about device status and exposing it via at le= ast one
=C2=A0 =C2=A0 = =C2=A0 management interface. =C2=A0The device monitoring might make use of = the
=C2=A0 =C2=A0 = =C2=A0 caching mechanism. =C2=A0The device monitoring might also make use o= f
= =C2=A0 =C2=A0 =C2=A0 neighbor-monitoring (fault detection in local network)= to support
=C2=A0 =C2=A0 = =C2=A0 fast fault detection and recovery, e.g., in a scenario where a
=C2=A0 = =C2=A0 =C2=A0 managing entity is unreachable and a neighbor can take over t= he
=C2=A0 =C2=A0 = =C2=A0 monitoring responsibility.

=C2=A0 =C2=A0Source: =C2=A0All use cases=

=C2=A0 =C2= =A0Requirement Type: =C2=A0Functional Requirement

= =C2=A0 =C2=A0Device type: =C2=A0C0, C1, and C2

=C2=A0 =C2=A0Priority: =C2= =A0High, Medium for neighbor-monitoring.

=C2=A0 =C2= =A0---

=C2=A0 =C2=A0R= eq-ID: =C2=A04.002

=C2=A0 =C2=A0Title: =C2=A0Energy status monitoring

=C2=A0 =C2= =A0Description: =C2=A0Provide a monitoring function to collect and expose
=C2= =A0 =C2=A0 =C2=A0 information about device energy parameters and usage (e.g= .,
TW> I would= suggest to replace "communication power" by "average power<= /font>
TW= > consumption"
=C2=A0 =C2=A0 = =C2=A0 battery level and communication power).

=C2=A0 =C2=A0Source: =C2=A0= Use case Energy Management


=


Ersue, et a= l. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 26]
=0C
Inter= net-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 July 2014


=C2=A0 =C2= =A0Requirement Type: =C2=A0Functional Requirement

= =C2=A0 =C2=A0Device type: =C2=A0C0, C1, and C2

=C2=A0 =C2=A0Priority: =C2= =A0High for energy reporting devices, Low for others.

=C2=A0 =C2= =A0---

=C2=A0 =C2=A0R= eq-ID: =C2=A04.003

=C2=A0 =C2=A0Title: =C2=A0Monitoring of current and est= imated device availability

=C2=A0 =C2= =A0Description: =C2=A0Provide a monitoring function to collect and expose
=C2= =A0 =C2=A0 =C2=A0 information about current device availability (energy, me= mory,
=C2=A0 =C2=A0 = =C2=A0 computing power, forwarding plane utilization, queue buffers,=
=C2=A0 = =C2=A0 =C2=A0 etc.) and estimation of remaining available resources.=

=C2=A0 =C2= =A0Source: =C2=A0All use cases. =C2=A0Note that monitoring energy resources= (like
=C2=A0 =C2=A0 =C2= =A0 battery status) may be required on all kinds of devices.

=C2=A0 =C2= =A0Requirement Type: =C2=A0Functional Requirement

= =C2=A0 =C2=A0Device type: =C2=A0C0, C1, and C2

=C2=A0 =C2=A0Priority: =C2= =A0Medium

=C2=A0 =C2= =A0---

=C2=A0 =C2=A0R= eq-ID: =C2=A04.004

=C2=A0 =C2=A0Title: =C2=A0Network status monitoring

TW> typo= analyse -> analyze
=C2=A0 =C2=A0Description: =C2=A0Provide a monitoring f= unction to collect, analyse and
=C2=A0 =C2=A0 = =C2=A0 expose information related to the status of a network or network
=C2= =A0 =C2=A0 =C2=A0 segments connected to the interface of the device.=

=C2=A0 =C2= =A0Source: =C2=A0All use cases.

= =C2=A0 =C2=A0Requirement Type: =C2=A0Functional Requirement

=
=C2=A0 =C2=A0D= evice type: =C2=A0C1 and C2

=C2=A0 =C2= =A0Priority: =C2=A0Low, based on the realization complexity.

= =C2=A0 =C2=A0---

=C2=A0 =C2=A0Req-ID: =C2=A04.005


=


Ersue, et a= l. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 27]
=0C
Inter= net-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 July 2014


=C2=A0 =C2= =A0Title: =C2=A0Self-monitoring

= =C2=A0 =C2=A0Description: =C2=A0Provide self-monitoring (local fault detect= ion) feature
=C2=A0 =C2=A0 =C2=A0 for fast fault detection and recovery.

=C2=A0 =C2= =A0Source: =C2=A0Use cases where the devices cannot be monitored centrally = in
=C2=A0 =C2=A0 =C2= =A0 appropriate manner, e.g., self-healing is required.

=C2=A0 =C2=A0Requi= rement Type: =C2=A0Functional Requirement

=C2=A0 =C2= =A0Device type: =C2=A0C1 and C2

= =C2=A0 =C2=A0Priority: =C2=A0High for C2, Medium for C1

=C2=A0 =C2=A0---

=C2=A0 =C2= =A0Req-ID: =C2=A04.006

= =C2=A0 =C2=A0Title: =C2=A0Performance Monitoring

=C2=A0 =C2=A0Description:= =C2=A0The device will provide a monitoring function to
=C2=A0 =C2=A0 = =C2=A0 collect and expose information about the basic performance
=C2=A0 =C2= =A0 =C2=A0 parameter of the device. =C2=A0The performance management functi= onality
=C2=A0 =C2=A0 = =C2=A0 might make use of the hierarchical management through the
=C2=A0 =C2= =A0 =C2=A0 intermediary devices.

=C2=A0 =C2= =A0Source: =C2=A0Use cases Building automation, and Transport applications<= /font>
= =C2=A0 =C2=A0Requirement Type: =C2=A0Functional Requirement

=
=C2=A0 =C2=A0D= evice type: =C2=A0C1 and C2

=C2=A0 =C2= =A0Priority: =C2=A0Low

= =C2=A0 =C2=A0---

=C2=A0 =C2=A0Req-ID: =C2=A04.007

=C2=A0 =C2= =A0Title: =C2=A0Fault detection monitoring

= =C2=A0 =C2=A0Description: =C2=A0The device will provide fault detection mon= itoring.
=C2=A0 =C2=A0 =C2=A0 The system collects information about network s= tates in order to
=C2=A0 =C2=A0 = =C2=A0 identify whether faults have occurred. =C2=A0In some cases the
=C2=A0 = =C2=A0 =C2=A0 detection of the faults might be based on the processing and<= /font>
=C2=A0 =C2=A0 = =C2=A0 analysis of the parameters retrieved from the network or other
=C2=A0 = =C2=A0 =C2=A0 devices. =C2=A0In case of C0 devices the monitoring might be = limited to
=C2=A0 =C2=A0 = =C2=A0 the check whether the device is alive or not.


<= br>
Ersue, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January= 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 28]<= /div>
=0C
= Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 July 2014


=C2=A0 =C2= =A0Source: =C2=A0Use cases Environmental Monitoring, Building Automation,
=C2= =A0 =C2=A0 =C2=A0 Energy Management, Infrastructure Monitoring

=C2=A0 =C2= =A0Requirement Type: =C2=A0Functional Requirement

= =C2=A0 =C2=A0Device type: =C2=A0C0, C1 and C2

=C2=A0 =C2=A0Priority: =C2= =A0Medium

=C2=A0 =C2= =A0---

=C2=A0 =C2=A0R= eq-ID: =C2=A04.008

=C2=A0 =C2=A0Title: =C2=A0Passive and Reactive Monitori= ng

=C2=A0 =C2= =A0Description: =C2=A0The device will provide passive and reactive monitori= ng
=C2=A0 =C2=A0 =C2= =A0 capabilities. =C2=A0The system or manager collects information about
=C2= =A0 =C2=A0 =C2=A0 device components and network states (passive monitoring)= and may
=C2=A0 =C2=A0 = =C2=A0 perform postmortem analysis of collected data. =C2=A0In case events = of
=C2=A0 =C2=A0 =C2=A0 interest have occurred the system or manager can adap= tively react
=C2=A0 =C2=A0 = =C2=A0 (reactive monitoring), e.g., reconfigure the network. =C2=A0Typicall= y
= =C2=A0 =C2=A0 =C2=A0 actions (re-actions) will be executed or sent as comma= nds by the
=C2=A0 =C2=A0 = =C2=A0 management applications.

=C2=A0 =C2=A0Source: =C2=A0Diverse use cas= es relevant for device status and network
=C2=A0 =C2=A0 = =C2=A0 state monitoring

=C2=A0 =C2=A0Requirement Type: =C2=A0Functional Re= quirement

=C2=A0 =C2= =A0Device type: =C2=A0C2

= =C2=A0 =C2=A0Priority: =C2=A0Medium

=C2=A0 =C2=A0---

=C2=A0 =C2= =A0Req-ID: =C2=A04.009

= =C2=A0 =C2=A0Title: =C2=A0Recovery

=C2=A0 =C2=A0Description: =C2=A0Provide= local, central and hierarchical recovery
=C2=A0 =C2=A0 = =C2=A0 mechanisms (recovery is in some cases achieved by recovering the
=C2= =A0 =C2=A0 =C2=A0 whole network of constrained devices).

=C2=A0 =C2= =A0Source: =C2=A0Use cases Industrial applications, Home and Building
=C2=A0 = =C2=A0 =C2=A0 Automation, Mobile Applications that involve different forms = of
=C2=A0 =C2=A0 = =C2=A0 clustering or area managers.

=C2=A0 =C2=A0Requirement Type: =C2=A0F= unctional Requirement


=

Ersue, et al. = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 29]
=0C
=
Internet-Draft= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 July 2014


=
=C2=A0 = =C2=A0Device type: =C2=A0C2

=C2=A0 =C2= =A0Priority: =C2=A0Medium

= =C2=A0 =C2=A0---

=C2=A0 =C2=A0Req-ID: =C2=A04.010

=C2=A0 =C2= =A0Title: =C2=A0Network topology discovery

= =C2=A0 =C2=A0Description: =C2=A0Provide a network topology discovery capabi= lity (e.g.,
=C2=A0 =C2=A0 =C2=A0 use of topology extraction algorithms to ret= rieve the network
=C2=A0 =C2=A0 = =C2=A0 state) and a monitoring function to collect and expose information
=C2= =A0 =C2=A0 =C2=A0 about the network topology.

=C2=A0 =C2= =A0Source: =C2=A0Use cases Community Network Applications and Mobile=
=C2=A0 = =C2=A0 =C2=A0 Applications

=C2=A0 =C2= =A0Requirement Type: =C2=A0Functional Requirement

= =C2=A0 =C2=A0Device type: =C2=A0C1 and C2

=C2=A0 =C2=A0Priority: =C2=A0L= ow, based on the realization complexity.

=C2=A0 =C2= =A0---

=C2=A0 =C2=A0R= eq-ID: =C2=A04.011

=C2=A0 =C2=A0Title: =C2=A0Notifications

=C2=A0 =C2= =A0Description: =C2=A0The device will provide the capability of sending
=C2= =A0 =C2=A0 =C2=A0 notifications on critical events and faults.

=C2=A0 =C2= =A0Source: =C2=A0All use cases.

= =C2=A0 =C2=A0Requirement Type: =C2=A0Functional Requirement

=
=C2=A0 =C2=A0D= evice type: =C2=A0C0, C1, and C2

=C2=A0 =C2= =A0Priority: =C2=A0Medium for C2, Low for C0 and C1

= =C2=A0 =C2=A0---

=C2=A0 =C2=A0Req-ID: =C2=A04.012

=C2=A0 =C2= =A0Title: =C2=A0Logging

<= br>

<= br>
= Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 July 2014


=C2=A0 =C2= =A0Description: =C2=A0The device will provide the capability of building,
=C2= =A0 =C2=A0 =C2=A0 keeping, and allowing retrieval of logs of events (includ= ing but
=C2=A0 =C2=A0 = =C2=A0 not limited to critical faults and alarms).

=C2=A0 =C2=A0Source: = =C2=A0Use cases Industrial Applications, Building Automation,
=C2=A0 =C2=A0 = =C2=A0 Infrastructure monitoring

=C2=A0 =C2=A0Requirement Type: =C2=A0Func= tional Requirement

=C2=A0 =C2= =A0Device type: =C2=A0C2

= =C2=A0 =C2=A0Priority: =C2=A0High for some medical or industrial applicatio= ns, Medium
=C2=A0 =C2=A0 =C2=A0 otherwise

3.5. =C2=A0= Self-management

= =C2=A0 =C2=A0Req-ID: =C2=A05.001

=C2=A0 =C2=A0Title: =C2=A0Self-management= - Self-healing

=C2=A0 =C2= =A0Description: =C2=A0Enable event-driven and/or periodic self-management
=C2= =A0 =C2=A0 =C2=A0 functionality in a device. =C2=A0The device should be abl= e to react in
=C2=A0 =C2=A0 = =C2=A0 case of a failure e.g., by initiating a fully or partly reset and
=C2= =A0 =C2=A0 =C2=A0 initiate a self-configuration or management data update a= s
=C2=A0 =C2=A0 = =C2=A0 necessary. =C2=A0A device might be further able to check for failure= s
= =C2=A0 =C2=A0 =C2=A0 cyclically or schedule-controlled to trigger self-mana= gement as
=C2=A0 =C2=A0 = =C2=A0 necessary. =C2=A0It is a matter of device design and subject for
=C2= =A0 =C2=A0 =C2=A0 discussion how much self-management a C1 device can suppo= rt. =C2=A0A
=C2=A0 =C2=A0 = =C2=A0 minimal failure detection and self-management logic is assumed to
=C2= =A0 =C2=A0 =C2=A0 be generally useful for the self-healing of a device.

=C2=A0 =C2= =A0Source: =C2=A0The requirement generally relates to all use cases in this=
= =C2=A0 =C2=A0 =C2=A0 document.

=C2=A0 =C2= =A0Requirement Type: =C2=A0Functional Requirement

= =C2=A0 =C2=A0Device type: =C2=A0C1 and C2

=C2=A0 =C2=A0Priority: =C2=A0H= igh for C2, Medium for C1

3.6. =C2=A0= Security and Access Control

= =C2=A0 =C2=A0Req-ID: =C2=A06.001

=C2=A0 =C2=A0Title: =C2=A0Authentication = of management system and devices.

=C2=A0 =C2= =A0Description: =C2=A0Systems having a management role must be properly
=C2= =A0 =C2=A0 =C2=A0 authenticated to the device such that the device can exer= cise


=

Ersue, et al. = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 31]
=0C
=
Internet-Draft= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 July 2014


=
=C2=A0 = =C2=A0 =C2=A0 proper access control and in particular distinguish rightful<= /font>
=C2=A0 =C2=A0 = =C2=A0 management systems from rogue systems. =C2=A0On the other hand manag= ed
=C2=A0 =C2=A0 =C2=A0 devices must authenticate themselves to systems havin= g a
=C2=A0 =C2=A0 = =C2=A0 management role such that management systems can protect
=C2=A0 =C2=A0= =C2=A0 themselves from rogue devices. =C2=A0In certain application scenari= os,
=C2=A0 =C2=A0 = =C2=A0 it is possible that a large number of devices need to be
=C2=A0 =C2=A0= =C2=A0 (re)started at about the same time. =C2=A0Protocols and authenticat= ion
=C2=A0 =C2=A0 = =C2=A0 systems should be designed such that a large number of devices
=C2=A0 = =C2=A0 =C2=A0 (re)starting simultaneously does not negatively impact the de= vice
=C2=A0 =C2=A0 = =C2=A0 authentication process.

=C2=A0 =C2=A0Source: =C2=A0Basic security r= equirement for all use cases.

=C2=A0 =C2= =A0Requirement Type: =C2=A0Functional Requirement

= =C2=A0 =C2=A0Device type: =C2=A0C0, C1, and C2

=C2=A0 =C2=A0Priority: =C2= =A0High, Medium for the (re)start of a large number of
=C2=A0 =C2=A0 = =C2=A0 devices

=C2=A0 =C2=A0---

=C2=A0 =C2= =A0Req-ID: =C2=A06.002

= =C2=A0 =C2=A0Title: =C2=A0Support suitable security bootstrapping mechanism= s
=
=C2=A0 =C2=A0Descri= ption: =C2=A0Mechanisms should be supported that simplify the
<= div>=C2=A0 =C2=A0 = =C2=A0 bootstrapping of device that is the discovery of newly deployed
=C2=A0 =C2=A0 = =C2=A0 devices in order to provide them with appropriate access control
=C2= =A0 =C2=A0 =C2=A0 permissions.

=C2=A0 =C2= =A0Source: =C2=A0Basic security requirement for all use cases.
=

= =C2=A0 =C2=A0Requirement Type: =C2=A0Functional Requirement

=
=C2=A0 =C2=A0D= evice type: =C2=A0C0, C1, and C2

=C2=A0 =C2= =A0Priority: =C2=A0High

= =C2=A0 =C2=A0---

TW> in some cases, different entities should have acce= ss to different sets of
TW> resourc= es. This is not captured in the text below.

=C2=A0 =C2=A0Req-ID: =C2=A06.0= 03

=C2=A0 =C2= =A0Title: =C2=A0Access control on management system and devices

= =C2=A0 =C2=A0Description: =C2=A0Systems acting in a management role must pr= ovide an
=C2=A0 =C2=A0 =C2=A0 access control mechanism that allows the securi= ty administrator to
=C2=A0 =C2=A0 = =C2=A0 restrict which devices can access the managing system (e.g., using


Ersue, et al.= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 32]
=0C
= Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 July 2014


=C2=A0 =C2= =A0 =C2=A0 an access control white list of known devices). =C2=A0On the oth= er hand
=C2=A0 =C2=A0 =C2= =A0 managed constrained devices must provide an access control
=
=C2=A0 =C2=A0 = =C2=A0 mechanism that allows the security administrator to restrict how
=C2=A0 =C2=A0 = =C2=A0 systems in a management role can access the device (e.g., no-=
=C2=A0 = =C2=A0 =C2=A0 access, read-only access, and read-write access).

=C2=A0 =C2= =A0Source: =C2=A0Basic security requirement for use cases where access
=C2=A0= =C2=A0 =C2=A0 control is essential.

=C2=A0 =C2= =A0Requirement Type: =C2=A0Functional Requirement

= =C2=A0 =C2=A0Device type: =C2=A0C0, C1, and C2

=C2=A0 =C2=A0Priority: =C2= =A0High

=C2=A0 =C2= =A0---

=C2=A0 =C2=A0R= eq-ID: =C2=A06.004

=C2=A0 =C2=A0Title: =C2=A0Select cryptographic algorith= ms that are efficient in both
=C2=A0 =C2=A0 = =C2=A0 code space and execution time.

=C2=A0 =C2=A0Description: =C2=A0Cryp= tographic algorithms have a major impact in terms
=C2=A0 =C2=A0 = =C2=A0 of both code size and overall execution time. =C2=A0It is therefore<= /font>
= =C2=A0 =C2=A0 =C2=A0 necessary to select mandatory to implement cryptograph= ic
=C2=A0 =C2=A0 = =C2=A0 algorithms that are reasonable to implement with the available
=C2=A0 = =C2=A0 =C2=A0 code space and that have a small impact at runtime. =C2=A0Fur= thermore
=C2=A0 =C2=A0 = =C2=A0 some wireless technologies (e.g., IEEE 802.15.4) require the<= /div>
=C2=A0 = =C2=A0 =C2=A0 support of certain cryptographic algorithms. =C2=A0It might b= e useful
=C2=A0 =C2=A0 = =C2=A0 to choose algorithms that are likely to be supported in wireless
=C2= =A0 =C2=A0 =C2=A0 chipsets for certain wireless technologies.

=C2=A0 =C2= =A0Source: =C2=A0Generic requirement to reduce the footprint and CPU usage = of
=C2=A0 =C2=A0 =C2= =A0 a constrained device.

=C2=A0 =C2=A0Requirement Type: =C2=A0Non-Functi= onal Requirement

=C2=A0 =C2= =A0Device type: =C2=A0C0, C1, and C2

= =C2=A0 =C2=A0Priority: =C2=A0High, Medium for hardware-supported algorithms= .
=
3.7. =C2=A0Energy M= anagement

=C2=A0 =C2=A0Req-ID: =C2=A07.001

=C2=A0 =C2= =A0Title: =C2=A0Management of Energy Resources

<= br>

<= br>
= Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 July 2014


=C2=A0 =C2= =A0Description: =C2=A0Enable managing power resources in the network, e.g.,=
= =C2=A0 =C2=A0 =C2=A0 reduce the sampling rate of nodes with critical batter= y and reduce
=C2=A0 =C2=A0 = =C2=A0 node transmission power, put nodes to sleep, put single interfaces
=C2= =A0 =C2=A0 =C2=A0 to sleep, reject a management job based on available ener= gy,
=C2=A0 =C2=A0 = =C2=A0 criteria e.g., importance levels pre-defined by the management
=C2=A0 = =C2=A0 =C2=A0 application, etc. (e.g., a task marked as essential can be
=C2=A0 =C2=A0 = =C2=A0 executed even if the energy level is low). =C2=A0The device may furt= her
=C2=A0 =C2=A0 = =C2=A0 through a management protocol interface, e.g., EMAN MIB modules
=C2=A0= =C2=A0 =C2=A0 and extensions (work ongoing). =C2=A0It might be necessary t= o use a
=C2=A0 =C2=A0 = =C2=A0 subset of EMAN MIBs for C1 and C2 devices.

=C2=A0 =C2=A0Source: =C2= =A0Use case Energy Management

=C2=A0 =C2= =A0Requirement Type: =C2=A0Functional Requirement

= =C2=A0 =C2=A0Device type: =C2=A0C0, C1, and C2

=C2=A0 =C2=A0Priority: =C2= =A0Medium for the use case Energy Management, Low otherwise.

=C2=A0 =C2= =A0---

=C2=A0 =C2=A0R= eq-ID: =C2=A07.002

=C2=A0 =C2=A0Title: =C2=A0Support of energy-optimized c= ommunication protocols

=C2=A0 =C2= =A0Description: =C2=A0Use of an optimized communication protocol to minimiz= e
=C2=A0 =C2=A0 =C2= =A0 energy usage for the device (radio) receiver/transmitter, on-air=
=C2=A0 =C2=A0 = =C2=A0 bandwidth (protocol efficiency), reduced amount of data
=
=C2=A0 =C2=A0 = =C2=A0 communication between nodes (implies data aggregation and
=C2=A0 =C2=A0 = =C2=A0 filtering but also a compact format for the transferred data).

=C2= =A0 =C2=A0Source: =C2=A0Use cases Energy Management and Mobile Applications= .

=C2=A0 =C2= =A0Requirement Type: =C2=A0Non-Functional Requirement

= =C2=A0 =C2=A0Device type: =C2=A0C2

=C2=A0 =C2=A0Priority: =C2=A0Medium

=C2=A0 =C2= =A0---

=C2=A0 =C2=A0R= eq-ID: =C2=A07.003

=C2=A0 =C2=A0Title: =C2=A0Support for layer 2 energy-aw= are protocols


=



=

Ersue, et al. = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 34]
=0C
=
Internet-Draft= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 July 2014


=
=C2=A0 = =C2=A0Description: =C2=A0The device will support layer 2 energy management<= /font>
=C2=A0 =C2=A0 = =C2=A0 protocols (e.g., energy-efficient Ethernet IEEE 802.3az) and be
=C2=A0= =C2=A0 =C2=A0 able to report on these.

=C2=A0 =C2= =A0Source: =C2=A0Use case Energy Management

= =C2=A0 =C2=A0Requirement Type: =C2=A0Non-Functional Requirement

=C2=A0 =C2= =A0Device type: =C2=A0C0, C1, and C2

=C2=A0 =C2= =A0Priority: =C2=A0Medium

= =C2=A0 =C2=A0---

=C2=A0 =C2=A0Req-ID: =C2=A07.004

=C2=A0 =C2= =A0Title: =C2=A0Dying gasp

= =C2=A0 =C2=A0Description: =C2=A0When energy resources draw below the red li= ne level,
=C2=A0 =C2=A0 =C2=A0 the device will send a dying gasp notification= and perform if
=C2=A0 =C2=A0 = =C2=A0 still possible a graceful shutdown including conservation of<= /div>
=C2=A0 = =C2=A0 =C2=A0 critical device configuration and status information.<= /div>

=C2=A0 =C2= =A0Source: =C2=A0Use case Energy Management

= =C2=A0 =C2=A0Requirement Type: =C2=A0Functional Requirement

=
=C2=A0 =C2=A0D= evice type: =C2=A0C0, C1, and C2

=C2=A0 =C2= =A0Priority: =C2=A0Medium

3= .8. =C2=A0SW Distribution

=C2=A0 =C2=A0Req-ID: =C2=A08.001

=C2=A0 =C2= =A0Title: =C2=A0Group-based provisioning

= =C2=A0 =C2=A0Description: =C2=A0Support group-based provisioning, i.e., fir= mware update
=C2=A0 =C2=A0 =C2=A0 and configuration management, of a large se= t of constrained
=C2=A0 =C2=A0 = =C2=A0 devices with eventual consistency and coordinated reload times.
=C2=A0= =C2=A0 =C2=A0 The device should accept group-based configuration managemen= t
=C2=A0 =C2=A0 = =C2=A0 based on bulk commands, which aim similar configurations of a=
=C2=A0 = =C2=A0 =C2=A0 large set of constrained devices of the same type in a given<= /font>
=C2=A0 =C2=A0 = =C2=A0 group, and which may share a common data model. =C2=A0Activation of<= /font>
= =C2=A0 =C2=A0 =C2=A0 configuration may be based on pre-loaded sets of defau= lt values.

=C2=A0 =C2= =A0Source: =C2=A0All use cases

<= br>

E= rsue, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 20= 15 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 35]
<= div>=0C
I= nternet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 July 2014


=
=C2=A0 = =C2=A0Requirement Type: =C2=A0Non-Functional Requirement

=C2=A0 =C2= =A0Device type: =C2=A0C0, C1, and C2

= =C2=A0 =C2=A0Priority: =C2=A0Medium

3.9. =C2=A0Traffic management

=C2=A0 =C2= =A0Req-ID: =C2=A09.001

= =C2=A0 =C2=A0Title: =C2=A0Congestion avoidance

=C2=A0 =C2=A0Description: = =C2=A0Support congestion control principles as defined in
=C2=A0 =C2=A0 = =C2=A0 [RFC2914], e.g., the ability to avoid congestion by modifying the
=C2= =A0 =C2=A0 =C2=A0 device's reporting rate for periodical data (which is= usually
=C2=A0 =C2=A0 = =C2=A0 redundant) based on the importance and reliability level of the
=C2=A0= =C2=A0 =C2=A0 management data. =C2=A0This functionality is usually control= led by the
=C2=A0 =C2=A0 = =C2=A0 managing entity, where the managing entity marks the data as<= /div>
TW> Ho= wever*,* reducing
=C2=A0 =C2=A0 = =C2=A0 important or relevant for reliability. =C2=A0However reducing a
=C2=A0= =C2=A0 =C2=A0 device's reporting rate can also be initiated by a devic= e if it is
=C2=A0 =C2=A0 = =C2=A0 able to detect congestion or has insufficient buffer memory.<= /div>

=C2=A0= =C2=A0Source: =C2=A0Use cases with high reporting rate and traffic e.g., A= MI or
=C2=A0 =C2=A0 = =C2=A0 M2M.

=C2=A0 =C2=A0Requirement Type: =C2=A0Non-Functional Requiremen= t

=C2=A0 =C2= =A0Device type: =C2=A0C1 and C2

= =C2=A0 =C2=A0Priority: =C2=A0Medium

=C2=A0 =C2=A0---

=C2=A0 =C2= =A0Req-ID: =C2=A09.002

= =C2=A0 =C2=A0Title: =C2=A0Reroute traffic

=C2=A0 =C2=A0Description: =C2= =A0Provide the ability for network nodes to redirect
=C2=A0 =C2=A0 = =C2=A0 traffic from overloaded intermediary nodes in a network to another
=C2= =A0 =C2=A0 =C2=A0 path in order to prevent congestion on a central server a= nd in the
=C2=A0 =C2=A0 = =C2=A0 primary network.

=C2=A0 =C2=A0Source: =C2=A0Use cases with high rep= orting rate and traffic e.g., AMI or
=C2=A0 =C2=A0 = =C2=A0 M2M.

=C2=A0 =C2=A0Requirement Type: =C2=A0Non-Functional Requiremen= t

=C2=A0 =C2= =A0Device type: =C2=A0Intermediary entity in the network.
=
<= br>
Ersue, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January= 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 36]<= /div>
=0C
= Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 July 2014


=C2=A0 =C2= =A0Priority: =C2=A0Medium

= =C2=A0 =C2=A0---

=C2=A0 =C2=A0Req-ID: =C2=A09.003

=C2=A0 =C2= =A0Title: =C2=A0Traffic Shaping.

= =C2=A0 =C2=A0Description: =C2=A0Provide the ability to apply traffic shapin= g policies
=C2=A0 =C2=A0 =C2=A0 to incoming and outgoing links on an overload= ed intermediary node
=C2=A0 =C2=A0 = =C2=A0 as necessary in order to reduce the amount of traffic in the<= /div>
=C2=A0 = =C2=A0 =C2=A0 network.

=C2=A0 =C2=A0Sou= rce: =C2=A0Use cases with high reporting rate and traffic e.g., AMI or
=C2=A0= =C2=A0 =C2=A0 M2M.

=C2=A0 =C2= =A0Requirement Type: =C2=A0Non-Functional Requirement

= =C2=A0 =C2=A0Device type: =C2=A0Intermediary entity in the network.<= /div>

=C2=A0= =C2=A0Priority: =C2=A0Medium

3.10. =C2= =A0Transport Layer

= =C2=A0 =C2=A0Req-ID: =C2=A010.001

=C2=A0 =C2=A0Title: =C2=A0Scalable trans= port layer

=C2=A0 =C2= =A0Description: =C2=A0Enable the use of a scalable transport layer, i.e., n= ot
=C2=A0 =C2=A0 =C2= =A0 sensitive to a high rate of incoming client requests, which is
=C2=A0 =C2= =A0 =C2=A0 useful for applications requiring frequent access to device data= .

=C2=A0 =C2= =A0Source: =C2=A0Applications with high frequent access to the device data.=
<= br>
= =C2=A0 =C2=A0Requirement Type: =C2=A0Non-Functional Requirement

=C2=A0 =C2= =A0Device type: =C2=A0C0, C1 and C2

=C2=A0 =C2= =A0Priority: =C2=A0Medium

= =C2=A0 =C2=A0---

=C2=A0 =C2=A0Req-ID: =C2=A010.002

=C2=A0 =C2= =A0Title: =C2=A0Reliable unicast transport of messages

= =C2=A0 =C2=A0Description: =C2=A0Diverse applications need a reliable transp= ort of
=C2=A0 =C2=A0 =C2=A0 messages. =C2=A0The reliability might be achieved= based on a transport


=

Ersue, et al. = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 37]
=0C
=
Internet-Draft= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 July 2014


=
=C2=A0 = =C2=A0 =C2=A0 protocol such as TCP or can be supported based on message
TW> acknowl= edgement -> acknowledgment
=C2=A0 =C2=A0 =C2=A0 repetition if an acknowled= gement is missing.

=C2=A0 =C2= =A0Source: =C2=A0Generally applications benefit from the reliability of the=
= =C2=A0 =C2=A0 =C2=A0 message transport.

=C2=A0 =C2= =A0Requirement Type: =C2=A0Functional Requirement

= =C2=A0 =C2=A0Device type: =C2=A0C0, C1, and C2

=C2=A0 =C2=A0Priority: =C2= =A0High

=C2=A0 =C2= =A0---

=C2=A0 =C2=A0R= eq-ID: =C2=A010.003

=C2=A0 =C2=A0Title: =C2=A0Best-effort multicast=

=C2=A0 =C2= =A0Description: =C2=A0Provide best-effort multicast of messages, which is
=C2= =A0 =C2=A0 =C2=A0 generally useful when devices need to discover a service = provided
=C2=A0 =C2=A0 = =C2=A0 by a server or many devices need to be configured by a managing
=C2=A0= =C2=A0 =C2=A0 entity at once based on the same data model.

=C2=A0 =C2= =A0Source: =C2=A0Use cases where a device needs to discover services as wel= l
=C2=A0 =C2=A0 =C2= =A0 as use cases with high amount of devices to manage, which are
=C2=A0 =C2=A0 = =C2=A0 hierarchically deployed, e.g., AMI or M2M.

=C2=A0 =C2=A0Requirement= Type: =C2=A0Functional Requirement

=C2=A0 =C2= =A0Device type: =C2=A0C0, C1, and C2

= =C2=A0 =C2=A0Priority: =C2=A0Medium

=C2=A0 =C2=A0---

=C2=A0 =C2= =A0Req-ID: =C2=A010.004

= =C2=A0 =C2=A0Title: =C2=A0Secure message transport.

=C2=A0 =C2=A0Descripti= on: =C2=A0Enable secure message transport providing
=C2=A0 =C2=A0 = =C2=A0 authentication, data integrity, confidentiality by using existing
=C2= =A0 =C2=A0 =C2=A0 transport layer technologies with small footprint such as= TLS/
=C2=A0 =C2=A0 = =C2=A0 DTLS.

=C2=A0 =C2=A0Source: =C2=A0All use cases.

=C2=A0 =C2= =A0Requirement Type: =C2=A0Non-Functional Requirements

<= br>

E= rsue, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 20= 15 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 38]
<= div>=0C
I= nternet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 July 2014


=
=C2=A0 = =C2=A0Device type: =C2=A0C1 and C2

=C2=A0 =C2= =A0Priority: =C2=A0High

3= .11. =C2=A0Implementation Requirements

=C2=A0 =C2=A0Req-ID: =C2=A011.001

=C2=A0 =C2= =A0Title: =C2=A0Avoid complex application layer transactions requiring larg= e
=C2=A0 =C2=A0 =C2= =A0 application layer messages.

=C2=A0 =C2= =A0Description: =C2=A0Complex application layer transactions tend to requir= e
=C2=A0 =C2=A0 =C2= =A0 large memory buffers that are typically not available on C0 or C1
=C2=A0 =C2=A0 = =C2=A0 devices and only by limiting functionality on C2 devices.
=C2=A0 =C2= =A0 =C2=A0 Furthermore, the failure of a single large transaction requires<= /font>
=C2=A0 =C2=A0 = =C2=A0 repeating the whole transaction. =C2=A0On constrained devices, it is=
T= W> "to a large transaction down" verb missing?
=C2=A0 =C2=A0 = =C2=A0 often more desirable to a large transaction down into a sequence
=C2= =A0 =C2=A0 =C2=A0 of smaller transactions that require less resources and a= llow to
=C2=A0 =C2=A0 = =C2=A0 make progress using a sequence of smaller steps.

=C2=A0 =C2=A0Sourc= e: =C2=A0Basic requirement which concerns all use cases with memory<= /div>
=C2=A0 =C2=A0 = =C2=A0 constrained devices.

=C2=A0 =C2=A0Requirement Type: =C2=A0Non-Fun= ctional Requirement

=C2=A0 =C2= =A0Device type: =C2=A0C0, C1, and C2

= =C2=A0 =C2=A0Priority: =C2=A0High

=C2=A0 =C2=A0---

=C2=A0 =C2= =A0Req-ID: =C2=A011.002

= =C2=A0 =C2=A0Title: =C2=A0Avoid reassembly of messages at multiple layers i= n the
=C2=A0 =C2=A0 =C2=A0 protocol stack.

=C2=A0 =C2= =A0Description: =C2=A0Reassembly of messages at multiple layers in the
=C2=A0= =C2=A0 =C2=A0 protocol stack requires buffers at multiple layers, which le= ads to
=C2=A0 =C2=A0 = =C2=A0 inefficient use of memory resources. =C2=A0This can be avoided by
=C2= =A0 =C2=A0 =C2=A0 making sure the application layer, the security layer, th= e
=C2=A0 =C2=A0 = =C2=A0 transport layer, the IPv6 layer and any adaptation layers are=
=C2=A0 = =C2=A0 =C2=A0 aware of the limitations of each other such that unnecessary<= /font>
=C2=A0 =C2=A0 = =C2=A0 fragmentation and reassembly can be avoided. =C2=A0In addition, mess= age
=C2=A0 =C2=A0 = =C2=A0 they can adapt and avoid sending messages that can't be processe= d
= =C2=A0 =C2=A0 =C2=A0 due to resource constraints on the receiving device.


=



=
Ersue, e= t al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 39]
=0C
= Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 July 2014


=C2=A0 =C2= =A0Source: =C2=A0Basic requirement which concerns all use cases with memory=
= =C2=A0 =C2=A0 =C2=A0 constrained devices.

=C2=A0 =C2= =A0Requirement Type: =C2=A0Non-Functional Requirement

= =C2=A0 =C2=A0Device type: =C2=A0C0, C1, and C2

=C2=A0 =C2=A0Priority: =C2= =A0High

4. =C2=A0IA= NA Considerations

= =C2=A0 =C2=A0This document does not introduce any new code-points or namesp= aces
=C2=A0 =C2=A0for registration with IANA.

=C2=A0 =C2= =A0Note to RFC Editor: this section may be removed on publication as an
=C2=A0 =C2=A0RFC.

5. =C2=A0Se= curity Considerations

= =C2=A0 =C2=A0This document discusses the problem statement and requirements= on
=C2=A0 =C2=A0l= imitations that could prevent the implementation of strong
=C2=A0 =C2=A0crypt= ographic algorithms. =C2=A0Requirements for security and access
=C2=A0 =C2=A0c= ontrol are listed in Section 3.6.

=C2=A0 =C2=A0Constrained devices might b= e deployed often in unsafe environments,
=C2=A0 =C2=A0w= here attackers can gain physical access to the devices. =C2=A0As a
=C2=A0 =C2= =A0consequence, it is crucial to properly protect any security
=C2=A0 =C2=A0c= redentials that may be stored on the device (e.g., by using hardware=
=C2=A0 = =C2=A0protection mechanisms). =C2=A0Furthermore, it is important that any
TW> leeking= -> leaking
=C2=A0 =C2=A0credentials leeking from a single device do not s= implify the attack
=C2=A0 =C2=A0o= n other (similar) devices. =C2=A0In particular, security credentials=
=C2=A0 = =C2=A0should never be shared.

=C2=A0 =C2= =A0Since constrained devices often have limited computational resources,
=C2=A0 =C2=A0care s= hould be taken in choosing efficient but cryptographically
TW> crytographi= c -> cryptographic
=C2=A0 =C2=A0s= trong crytographic algorithms. =C2=A0Designers of constrained devices
=C2=A0 = =C2=A0that have a long expected lifetime need to ensure that cryptographic<= /font>
=C2=A0 =C2=A0a= lgorithms can be updated once devices have been deployed. =C2=A0The<= /div>
=C2=A0 = =C2=A0ability to perform secure firmware and software updates is an<= /div>
=C2=A0 =C2=A0i= mportant management requirement.

=C2=A0 =C2=A0Constrained devices might al= so generate sensitive data or require the
=C2=A0 =C2=A0p= rocessing of sensitive data. =C2=A0It is therefore an important
=C2=A0 =C2=A0= requirement to properly protect access to the data in order to
=C2=A0 =C2=A0p= rotect the privacy of humans using Internet-enabled devices. =C2=A0For
=C2=A0= =C2=A0certain types of data, protection during the transmission over the
=C2=A0 =C2=A0n= etwork may not be sufficient and methods should be investigated that=



Ersue, et al.= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 40]
=0C
= Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 July 2014


=C2=A0 =C2= =A0provide protection of data while it is cached or stored (e.g., when
=C2=A0= =C2=A0using a store-and-forward transport mechanism).

6. =C2=A0Co= ntributors

= =C2=A0 =C2=A0Ulrich Herberg (Fujitsu Laboratories of America) contributed t= o the
=C2=A0 =C2=A0Section 1.3 on Networks Types and Characteristics in Focus= .

7. =C2=A0Ac= knowledgments

= =C2=A0 =C2=A0Following persons reviewed and provided valuable comments to
=C2= =A0 =C2=A0different versions of this document:

=C2=A0 =C2= =A0Dominique Barthel, Andy Bierman, Carsten Bormann, Zhen Cao, Benoit
=C2=A0 = =C2=A0Claise, Hui Deng, Bert Greevenbosch, Ulrich Herberg, James Nguyen,
=C2=A0 =C2=A0A= nuj Sehgal, Zach Shelby, Peter van der Stok and Bert Wijnen.

=C2=A0 =C2=A0= The editors would like to thank the reviewers and the participants on
=C2=A0 =C2=A0t= he Coman and OPSAWG mailing lists for their valuable contributions
=C2=A0 =C2= =A0and comments.

8. =C2=A0In= formative References

= =C2=A0 =C2=A0[RFC2914] =C2=A0Floyd, S., "Congestion Control Principles= ", BCP 41, RFC
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2914, Se= ptember 2000.

=C2=A0 =C2= =A0[RFC2501] =C2=A0Corson, M. and J. Macker, "Mobile Ad hoc Networking=
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (MANET): Routing Protocol = Performance Issues and
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Evaluation Considerations", RFC 250= 1, January 1999.

=C2=A0 =C2=A0[RFC6632] =C2=A0Ersue, M. and B. Claise, &qu= ot;An Overview of the IETF Network
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Management Standards", RFC 6632, Ju= ne 2012.

=C2=A0 =C2=A0[RFC7102] =C2=A0Vasseur, JP., "Terms Used in Ro= uting for Low-Power and
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Lossy Networks", RFC 7102, January = 2014.

=C2=A0 =C2=A0[RFC7228] =C2=A0Bormann, C., Ersue, M., and A. Keranen,= "Terminology for
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained-Node Networks", RFC 722= 8, May 2014.

=C2=A0 =C2=A0[RFC7252] =C2=A0Shelby, Z., Hartke, K., and C. B= ormann, "The Constrained
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Application Protocol (CoAP)", RFC 7= 252, June 2014.

=C2=A0 =C2=A0[COM-USE] =C2=A0Ersue, M., "Constrained = Management: Use Cases", draft-
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ietf-opsawg-coman-use-cases (work in pro= gress), October
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2013.=


=



=

Ersue, et al. = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 41]
=0C
=
Internet-Draft= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 July 2014


=
Appendix= A. =C2=A0Change Log

A.1. =C2=A0= draft-ietf-opsawg-coman-probstate-reqs-01 - draft-ietf-opsawg-
=
=C2=A0 =C2=A0 = =C2=A0 coman-probstate-reqs-02

=C2=A0 =C2= =A0o =C2=A0General bug fixing.

= =C2=A0 =C2=A0o =C2=A0Resolved the use of the term profile of requirements.<= /font>
=C2=A0 =C2=A0o =C2= =A0Changed requirement title from Redirect traffic to Reroute traffic
=C2=A0 = =C2=A0 =C2=A0 and the description accordingly.

=C2=A0 =C2= =A0o =C2=A0Changed requirement title from Traffic delay schemes to Traffic<= /font>
= =C2=A0 =C2=A0 =C2=A0 Shaping and the description accordingly.

=C2=A0 =C2= =A0o =C2=A0Extended Security Considerations section.

= =C2=A0 =C2=A0o =C2=A0Deleted empty section on Normative References.<= /div>

A.2. = =C2=A0draft-ietf-opsawg-coman-probstate-reqs-00 - draft-ietf-opsawg-=
=C2=A0 =C2=A0 = =C2=A0 coman-probstate-reqs-01

=C2=A0 =C2=A0o =C2=A0General bug fixing.

=C2=A0 =C2= =A0o =C2=A0Added Section 1.7. on Configuration and Monitoring Functionality=
= =C2=A0 =C2=A0 =C2=A0 Levels.

=C2=A0 =C2= =A0o =C2=A0Changed diverse occurences of "networks" to "netw= orks with/of
=C2=A0 =C2=A0 = =C2=A0 constrained devices".

=C2=A0 =C2=A0o =C2=A0Introduced the term= "Self-configuring infrastructureless networks"
=C2=A0 =C2=A0 = =C2=A0 instead of MANET as it is a superset.

=C2=A0 =C2=A0o =C2=A0Introd= uced the term 'sleepy endpoints'.

=C2=A0 =C2= =A0o =C2=A0Changed requirement IDs to be independent of section number.

= =C2=A0 =C2=A0o =C2=A0Introduced notes for parts of the requirements text if= it is
=C2=A0 =C2=A0 =C2=A0 focusing on implementation or solution.

=C2=A0 =C2= =A0o =C2=A0Extended Security Considerations section.

= =C2=A0 =C2=A0o =C2=A0Deleted Appendix A and B on other SDO's work and r= elated projects
=C2=A0 =C2=A0 =C2=A0 as they provided dynamic information and= couldn't be kept up-to-
=C2=A0 =C2=A0 = =C2=A0 date.




=


Ersue, et a= l. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 42]
=0C
Inter= net-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 July 2014


A.3. =C2=A0= draft-ersue-constrained-mgmt-03 - draft-ietf-opsawg-coman-
=C2=A0 =C2=A0 =C2= =A0 probstate-reqs-00

=C2=A0 =C2= =A0o =C2=A0Reduced the terminology section for terminology addressed in the=
= =C2=A0 =C2=A0 =C2=A0 LWIG terminology draft. =C2=A0Referenced the LWIG term= inology draft.

=C2=A0 =C2= =A0o =C2=A0Checked and aligned all terminology against the LWIG terminology=
= =C2=A0 =C2=A0 =C2=A0 draft.

=C2=A0 =C2= =A0o =C2=A0Moved section 1.4. =C2=A0Constrained Device Deployment Options a= nd
=C2=A0 =C2=A0 =C2=A0 section 3. =C2=A0Use Cases to the companion document = [COM-USE].

=C2=A0 =C2= =A0o =C2=A0Renamed Section 1.3. =C2=A0Class of Networks in Focus to "N= etwork Types
=C2=A0 =C2=A0 = =C2=A0 in Focus" and removed abbreviations C0, C1 and C2 for network
=C2= =A0 =C2=A0 =C2=A0 classes as they have not been used.

=C2=A0 =C2= =A0o =C2=A0Changed requirement priority classes to be High, Medium and Low.=
<= br>
= =C2=A0 =C2=A0o =C2=A0Changed requirement types to be Functional and Non-Fun= ctional and
=C2=A0 =C2=A0 =C2=A0 added text to explain the requirement types.=

=C2=A0 =C2= =A0o =C2=A0Reformulation of some text parts for more clarity.
<= div>
A= .4. =C2=A0draft-ersue-constrained-mgmt-02-03

=C2=A0 =C2=A0o =C2=A0Extend= ed the terminology section and removed some of the
=C2=A0 =C2=A0 = =C2=A0 terminology addressed in the new LWIG terminology draft.
=C2=A0 =C2=A0= =C2=A0 Referenced the LWIG terminology draft.

=C2=A0 =C2= =A0o =C2=A0Moved Section 1.3. on Constrained Device Classes to the new LWIG=
= =C2=A0 =C2=A0 =C2=A0 terminology draft.

=C2=A0 =C2= =A0o =C2=A0Class of networks considering the different type of radio and
=C2= =A0 =C2=A0 =C2=A0 communication technologies in use and dimensions extended= .

=C2=A0 =C2= =A0o =C2=A0Extended the Problem Statement in Section 2. following the
=C2=A0 = =C2=A0 =C2=A0 requirements listed in Section 4.

=C2=A0 =C2= =A0o =C2=A0Following requirements, which belong together and can be realize= d
=C2=A0 =C2=A0 =C2= =A0 with similar or same kind of solutions, have been merged.

=C2=A0 =C2= =A0 =C2=A0 * =C2=A0Distributed Management and Peer Configuration,

= =C2=A0 =C2=A0 =C2=A0 * =C2=A0Device status monitoring and Neighbor-monitori= ng,
=C2=A0 =C2=A0 =C2= =A0 * =C2=A0Passive Monitoring and Reactive Monitoring,


=



=
Ersue, e= t al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 43]
=0C
= Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 July 2014


=C2=A0 =C2= =A0 =C2=A0 * =C2=A0Event-driven self-management - Self-healing and Periodic= self-
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0management,

=C2=A0 =C2= =A0 =C2=A0 * =C2=A0Authentication of management systems and Authentication = of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0managed devices,

=C2=A0 =C2= =A0 =C2=A0 * =C2=A0Access control on devices and Access control on manageme= nt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0systems,

=C2=A0 =C2= =A0 =C2=A0 * =C2=A0Management of Energy Resources and Data models for energ= y
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0management,

=C2=A0 =C2= =A0 =C2=A0 * =C2=A0Software distribution (group-based firmware update) and = Group-
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0based provisioning.

=C2=A0 =C2= =A0o =C2=A0Deleted the empty section on the gaps in network management
=C2=A0= =C2=A0 =C2=A0 standards, as it will be written in a separate draft.=

=C2=A0 =C2= =A0o =C2=A0Added links to mentioned external pages.

= =C2=A0 =C2=A0o =C2=A0Added text on OMA M2M Device Classification in appendi= x.

A.5. =C2=A0draft-er= sue-constrained-mgmt-01-02

=C2=A0 =C2=A0o =C2=A0Extended the terminology s= ection.

=C2=A0 =C2= =A0o =C2=A0Added additional text for the use cases concerning deployment
=C2= =A0 =C2=A0 =C2=A0 type, network topology in use, network size, network capa= bilities,
=C2=A0 =C2=A0 = =C2=A0 radio technology, etc.

=C2=A0 =C2=A0o =C2=A0Added examples for devi= ce classes in a use case.

=C2=A0 =C2= =A0o =C2=A0Added additional text provided by Cao Zhen (China Mobile) for
=C2= =A0 =C2=A0 =C2=A0 Mobile Applications and by Peter van der Stok for Buildin= g
=C2=A0 =C2=A0 = =C2=A0 Automation.

=C2=A0 =C2=A0o =C2=A0Added the new use cases 'Advan= ced Metering Infrastructure' and
=C2=A0 =C2=A0 = =C2=A0 'MANET Concept of Operations in Military'.
=
=C2=A0 =C2=A0o = =C2=A0Added the section 'Managing the Constrainedness of a Device or
=C2=A0 =C2=A0 = =C2=A0 Network' discussing the needs of very constrained devices.

=C2= =A0 =C2=A0o =C2=A0Added a note that the requirements in Section 3 need to b= e seen as
=C2=A0 =C2=A0 = =C2=A0 standalone requirements and the current document does not
=C2=A0 =C2= =A0 =C2=A0 recommend any profile of requirements.

=C2=A0 =C2= =A0o =C2=A0Added Section 3 on the detailed requirements on constrained
=C2=A0= =C2=A0 =C2=A0 management matched to management tasks like fault, monitorin= g,


=

Ersue, et al. = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 44]
=0C
=
Internet-Draft= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Constrained Mgmt: PS, Rqmts =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 July 2014


=
=C2=A0 = =C2=A0 =C2=A0 configuration management, Security and Access Control, Energy=
=C2=A0 =C2=A0 = =C2=A0 Management, etc.

=C2=A0 =C2=A0o =C2=A0Solved nits and added referen= ces.

=C2=A0 =C2= =A0o =C2=A0Added Appendix A on the related development in other bodies.

= =C2=A0 =C2=A0o =C2=A0Added Appendix B on the work in related research proje= cts.

A.6. =C2=A0dra= ft-ersue-constrained-mgmt-00-01

=C2=A0 =C2=A0o =C2=A0Splitted the section = on 'Networks of Constrained Devices' into the
=C2=A0 =C2=A0 = =C2=A0 sections 'Network Topology Options' and 'Management Topo= logy
=C2=A0 =C2=A0 =C2=A0 Options'.

=C2=A0 =C2= =A0o =C2=A0Added the use case 'Community Network Applications' and = 'Mobile
=C2=A0 =C2=A0 = =C2=A0 Applications'.

=C2=A0 =C2=A0o =C2=A0Provided a Contributors se= ction.

=C2=A0 =C2= =A0o =C2=A0Extended the section on 'Medical Applications'.

= =C2=A0 =C2=A0o =C2=A0Solved nits and added references.

= Authors' Addres= ses

=C2=A0 =C2= =A0Mehmet Ersue (editor)
=C2=A0 =C2=A0Nokia Networks

=C2=A0 =C2= =A0Email: mehmet.ersue@nsn.com<= /font>


=C2=A0 =C2=A0= Dan Romascanu
=C2=A0 =C2=A0A= vaya

=C2=A0 =C2=A0Email: dromasca@av= aya.com


=
=C2=A0 = =C2=A0Juergen Schoenwaelder
=C2=A0 =C2=A0J= acobs University Bremen

=C2=A0 =C2=A0Email: j.schoenwaelder@jacobs-university.de


=



=



=

Ersue, et al. = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 45]

--001a11c20cc86d38ee0500413e08-- From nobody Sun Aug 10 11:11:34 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6B11A0470 for ; Sun, 10 Aug 2014 09:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.033 X-Spam-Level: X-Spam-Status: No, score=0.033 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=unavailable 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 f-SwMuv-f4WW for ; Sun, 10 Aug 2014 09:32:26 -0700 (PDT) Received: from nm36-vm2.bullet.mail.bf1.yahoo.com (nm36-vm2.bullet.mail.bf1.yahoo.com [72.30.238.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1C0D1A046C for ; Sun, 10 Aug 2014 09:32:25 -0700 (PDT) Received: from [98.139.212.149] by nm36.bullet.mail.bf1.yahoo.com with NNFMP; 10 Aug 2014 16:32:24 -0000 Received: from [98.139.212.238] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 10 Aug 2014 16:32:24 -0000 Received: from [127.0.0.1] by omp1047.mail.bf1.yahoo.com with NNFMP; 10 Aug 2014 16:32:24 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 831354.78013.bm@omp1047.mail.bf1.yahoo.com Received: (qmail 69732 invoked by uid 60001); 10 Aug 2014 16:32:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1407688344; bh=R+mkRKk/gNthuNm+9sV1dxt9kZXT+YC7eau1yGU1Y0k=; h=Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=VvaIZenSYBDUtj6MI0vHN4BM+klp/owy+IRdux8jeykKj59sj83aNi19/fquk+DydVukjis+M4aHW096eFQFPvru/cvvSBbtZVqz5oV9CQioKw+Y7wKTFnDAfFaZE/dr84UhtwoNdJ0LSyuYslXkKXXTbrbkdIWa3TsDVDPnbEA= X-YMail-OSG: .HKTyWQVM1kH307FnrTOWb4RT2dEmlm1wyOFfID5tg0cQC9 BqHpgaMblS77YRoEW5kHV7jMk1wjQDz3Aj6vra3sga633YvmP0JtpHuBgOas l22vhHFpmNm1pAs6p2PsBp5okLe4Gp.jv_0G0PY2AIP73yE2vUaG6ORaIPvj lpqSLWDhe2ZkHh0.e4hz.SeVyuJCbXqqrws7Q0Wn_R9k4YwLJJhvBKApk7f4 AzEv5IuK4vfFWiWiJBou32nc8loKOhY8ZpJjUTdPZgEbAU2BZ1qIgZ1.LvOW q6jS2YXYIMV6zQHWFjU06UDAGM8hkzktg7JPAgydsBXGXtAjz9eV8gYfJwz8 zKW6oCPEb4jDJlvVMTZt.B1OYc_aQKVLBZYlmUI7_f3aRlXYaWVapnTHcjmK gRLd4LK4k_hcOC9wrj.pfR8G4SGnjgo8ZKSsz84vZtdxH4F2sBuYKoWUI.4B 8E5WZTBdVuV2cT2W7RjPOMILYV9ORGy6Ksh557o.O9fBf.KjNF0AQrHQk Received: from [71.162.250.15] by web140204.mail.bf1.yahoo.com via HTTP; Sun, 10 Aug 2014 09:32:24 PDT X-Rocket-MIMEInfo: 002.001, RGVhciBhdXRob3JzLAoKSSdtIHdvcmtpbmcgaW4gNlRpU0NIIFdHLiBJIGJlbGlldmUgbWFueSBvZiB0aGUgdXNlIGNhc2VzIGRlc2NyaWJlZCBpbgpkcmFmdC1pZXRmLW9wc2F3Zy1jb21hbi11c2UtY2FzZXMtMDIgd2lsbCBlbXBsb3kgVFNDSCBvZiBJRUVFODAyLjE1LjQsIGFuZAp0aGVyZWZvcmUgNnRvcCBzdWJsYXllciBkZWZpbmVkIGJ5IDZUaVNDSCBXRy4gVGh1cywgSU1ITywgaXQgaXMgbmVjZXNzYXJ5IHRvCnRha2Ugbm90IG9ubHkgdGhlIG1hbmFnZW1lbnQgcmVxdWlyZW1lbnRzIGZyb20gdGhvc2UBMAEBAQE- X-Mailer: YahooMailWebService/0.8.198.689 Message-ID: <1407688344.30677.YahooMailNeo@web140204.mail.bf1.yahoo.com> Date: Sun, 10 Aug 2014 09:32:24 -0700 From: Qin Wang To: "opsawg@ietf.org" , Tisch <6tisch@ietf.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="875636525-649252228-1407688344=:30677" Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/N3pXAyqH7jNm4CiCmsXoPRJnqs0 X-Mailman-Approved-At: Sun, 10 Aug 2014 11:11:30 -0700 Subject: [OPSAWG] review draft-ietf-opsawg-coman-use-cases-02 and draft-ietf-opsawg-coman-probstate-reqs-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Qin Wang List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2014 16:32:27 -0000 --875636525-649252228-1407688344=:30677 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear authors,=0A=0AI'm working in 6TiSCH WG. I believe many of the use case= s described in=0Adraft-ietf-opsawg-coman-use-cases-02 will employ TSCH of I= EEE802.15.4, and=0Atherefore 6top sublayer defined by 6TiSCH WG. Thus, IMHO= , it is necessary to=0Atake not only the management requirements from those= use cases, but also the management=0Afunctionality of these protocols into= consideration.=0A=C2=A0=0ABasically, there are two management modes=0Ain 6= TiSCH networks, i.e. centralized, decentralized. Under decentralized mode,= =0Aneighbor nodes need to exchange management data, such as the neighbor=E2= =80=99s=0Aschedules, specifying which timeslots and which channels have be = used, so as to allocate new communication resource collaboratively.=C2=A0= =0A=0AAccording=0Ato my understanding, the current management architecture/= system (section 3.1) will support centralized management, hierarchical mana= gement, and distributed management (i.e multi local managers), but does not= support this kind of peer-to-peer management, which also results in that = =E2=80=9CSecurity and Access Control=E2=80=9D does not cover the peer-to-pe= er management. If=0Ait is true, I would suggest to add the peer-to-peer man= agement into management architecture/system,=0Aand also consider it in othe= r related sections. What do you think?=0A=C2=A0=0ATypo in draft-ietf-opsawg= -coman-probstate-reqs-01=0AP14. =E2=80=9CConstrained devices often implemen= t a combination of one=0Aof FL0-FL2=0Awith one of ML0-ML1.=E2=80=9D Should= =0A=E2=80=9CFL0-FL2=E2=80=9D be =E2=80=9CCL0-CL2=E2=80=9D?=0A=0AThanks=0AQi= n=0A --875636525-649252228-1407688344=:30677 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Dear authors,

I'm working in 6TiSCH WG. I believe = many of the use cases described in=0Adraft-ietf-opsawg-coman-use-cases-02 w= ill employ TSCH of IEEE802.15.4, and=0Atherefore 6top sublayer defined by 6= TiSCH WG. Thus, IMHO, it is necessary to=0Atake not only the management req= uirements from those use cases, but also the management=0Afunctionality of = these protocols into consideration.=
 
Basically, there are two management modes=0Ain 6TiSCH netw= orks, i.e. centralized, decentralized. Under decentralized mode,=0Aneighbor= nodes need to exchange management data, such as the neighbor=E2=80=99s=0As= chedules, specifying which timeslots and which channels have be used, so as= to allocate new communication resource collaboratively. 
=

According=0Ato my understanding, the current management ar= chitecture/system (section 3.1) will support centralized management, hierar= chical management, and distributed management (i.e multi local managers), b= ut does not support this kind of peer-to-peer management, which also result= s in that =E2=80=9CSecurity and Access Control=E2=80=9D does not cover the = peer-to-peer management. If=0Ait is true, I would suggest to add the peer-t= o-peer management into management architecture/system,=0Aand also consider = it in other related sections. What do you think?=
 
Typo in draft-ietf-opsawg-coman-probstate-reqs-= 01
P14. =E2=80=9CConstrained de= vices often implement a combination of one=0Aof FL0-FL2
=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A
with one of ML0-ML1.= =E2=80=9D Should=0A=E2=80=9CFL0-FL2=E2=80=9D be =E2=80=9CCL0-CL2=E2=80=9D?<= /span>

Thanks<= /span>
<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:Courier;=0Amso-bi= di-font-family:Courier;mso-font-kerning:0pt" class=3D"">Qin

--875636525-649252228-1407688344=:30677-- From nobody Sun Aug 10 11:11:36 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A4B1A07A7 for ; Sun, 10 Aug 2014 09:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 3vMF0QPFMHJU for ; Sun, 10 Aug 2014 09:47:32 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 494541A07A2 for ; Sun, 10 Aug 2014 09:47:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12465; q=dns/txt; s=iport; t=1407689252; x=1408898852; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zsqHqxFVprZl05vubbDAfLsnrs3wgdjSFLEW/2p+onk=; b=ZVU6W5jaHktKyTzjBuJEhbZ2T0pM05R1gN6Gy7kCOEHeJr/0pEpDO4Ke xjKlvSt71VAUOFcZ3VeExK2FDaJbi9+XSYd8FjbqCv+AHsesvXzKl2Miz TkXexzCPhMRqJ4pgp25iDZXsur9YFfRmsTou4y/U7ECwnbILsXGxdiEFz E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FANah51OtJV2d/2dsb2JhbABagkdGUlfLDIFZAQmGdVMBgQcWd4QDAQEBBAEBAWsLEAIBCBEDAQIoBycLFAkIAgQOBQmIOQ3BHxeOewEBPg0EBgEGgjJTJIEdBYYPhFCEJ4IThCWBboUDgVeTJINcbAGBDQ X-IronPort-AV: E=Sophos;i="5.01,837,1400025600"; d="scan'208,217";a="346228294" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 10 Aug 2014 16:47:31 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s7AGlVDB014599 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 10 Aug 2014 16:47:31 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.109]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Sun, 10 Aug 2014 11:47:30 -0500 From: "Pascal Thubert (pthubert)" To: "opsawg@ietf.org" Thread-Topic: [OPSAWG] Coman Drafts v02 Thread-Index: AQHPszQS4Abi5UfSxEGyzCCjcnfBlZvKDyWt Date: Sun, 10 Aug 2014 16:47:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_B8AF2D35C52942F2AFAB2FAEF9919ACAciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/RzE9T32FASJuBB4KonSDGbgnXYs X-Mailman-Approved-At: Sun, 10 Aug 2014 11:11:30 -0700 Cc: "Raghuram Sudhaakar \(rsudhaak\)" Subject: Re: [OPSAWG] Coman Drafts v02 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2014 16:47:34 -0000 --_000_B8AF2D35C52942F2AFAB2FAEF9919ACAciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all: About probstate/req. This is a very complete and well written document, and I agree it is ripe f= or IESG. Before submittung, though, I'd suggest to add text relevant to (radio) link= and resources management. The draft only discusses reporting a topology. In a radio mesh, it is impor= tant to assess reachability and interference domains so as to allow spatial= reuse of. Because some resources are shared there is a need to claim some and a need = for arbitration/push from the network management down to the frequencies an= d in the case of TSCH, time slots. 6TiSCH has also isolated the need for traffic engineering (eg for industria= l control loops) and though the network component is a PCE, I'd think that = the requirement is still a management one. Finally I'm not sure there is enough text on operator IoT networks (multi t= enant management) eg a citywide IoAt backbone operated by an ISP or the cit= y itself, or a home network with share mesh resources but multiple sinks fo= r various utilities. Cheers, Pascal Le 8 ao=FBt 2014 =E0 20:10, "Raghuram Sudhaakar (rsudhaak)" > a =E9crit : Dear ML users, I read both the documents your mentioned below. Both are well written and a= ddress their scope quite well. Only a few minor typos here and there. On a general note, both these documents do not address the actual managemen= t protocol. It seems to me that these documents will typically be reference= d by some other drafts (like our draft-ietf-6tisch-coap) that specify the p= rotocol. -raghuram From: Thomas Watteyne > Date: Tuesday, August 5, 2014 at 11:15 PM To: raghuram sudhaakar > Subject: Fwd: [6lo] Fwd: [OPSAWG] Coman Drafts v02 Raghuram, These drafts, which introduce the use cases and problem statement for const= rained management, are very related to the CoAP draft you co-authored. I be= lieve it would be very useful if you could review them and submit your revi= ew to the OPSAWG ML, as detailed below. Would that be possible? Thomas ---------- Forwarded message ---------- From: Thomas Watteyne > Date: Sat, Jul 26, 2014 at 10:32 PM Subject: Fwd: [6lo] Fwd: [OPSAWG] Coman Drafts v02 To: "6tisch@ietf.org" <6tisch@ietf.org> All, The OPSWAG chairs have kindly agreed to extend the WGLC period for the foll= owing drafts [1] to August 11: http://tools.ietf.org/html/draft-ietf-opsawg-coman-use-cases-02 http://tools.ietf.org/html/draft-ietf-opsawg-coman-probstate-reqs-01 Pascal and myself believe those two drafts to be important for the ongoing = work on managing a 6TiSCH network, and directly in line with e.g. draft-iet= f-6tisch-coap. We therefore ask authors of draft-ietf-6tisch-coap, draft-ie= tf-6tisch-6top-interface, and any other 6TiSCH WG member to send reviews of= this document to OPSAWG ML [2]. Thomas [1] http://www.ietf.org/mail-archive/web/6tisch/current/msg02465.html [2] https://www.ietf.org/mailman/listinfo/opsawg ---------- Forwarded message ---------- From: Warren Kumari > Date: Fri, Jul 25, 2014 at 3:03 PM Subject: Re: [coman] FW: [OPSAWG] Coman Drafts v02 To: "Ersue, Mehmet (NSN - DE/Munich)" > Cc: "coman@ietf.org" >, "opsawg-chairs@tools.ietf.org" > Hi all. With apologies to the authors... The chairs of 6LoWPAN and 6TSCH have asked if we can delay the end of this WGLC so that their communities can review and comment on these 2 documents. As we have not received very much feedback, this seems relevant to their WGs, and they asked nicely, we have decided to extend the deadline to August 11th. Now, many folk will be traveling back to their homes over the next few days - this probably means a few, or many hours on an airplane. May I suggest copying these documents on your computer or reading device of choice and reviewing the documents on the way home? Thanks, W _______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo --_000_B8AF2D35C52942F2AFAB2FAEF9919ACAciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear all:

About probstate/req.

This is a very complete and well written document, and I agree it is r= ipe for IESG.

Before submittung, though, I'd suggest to add text relevant to (radio)= link and resources management.

The draft only discusses reporting a topology. In a radio mesh, it is = important to assess reachability and interference domains so as to allow sp= atial reuse of.

Because some resources are shared there is a need to claim some and a = need for arbitration/push from the network management down to the frequenci= es and in the case of TSCH, time slots.

6TiSCH has also isolated the need for traffic engineering (eg for industria= l control loops) and though the network component is a PCE, I'd think that = the requirement is still a management one.

Finally I'm not sure there is enough text on operator IoT networks (multi t= enant management) eg a citywide IoAt backbone operated by an ISP or the cit= y itself, or a home network with share mesh resources but multiple sinks fo= r various utilities.

Cheers,

Pascal

Le 8 ao=FBt 2014 =E0 20:10, "Raghuram Sudhaakar (rsudhaak)" <<= a href=3D"mailto:rsudhaak@cisco.com">rsudhaak@cisco.com> a =E9crit&n= bsp;:

Dear ML users,
I read both the documents your mentioned below. Both are well written = and address their scope quite well. 
Only a few minor typos here and there.

On a general note, both these documents do not address the actual mana= gement protocol. It seems to me that these documents will typically be refe= renced by some other drafts (like our draft-ietf-6tisch-coap) that spe= cify the protocol. 


-raghuram

From: Thomas Watteyne <watteyne@eecs.berkeley.edu> Date: Tuesday, August 5, 2014 at 11= :15 PM
To: raghuram sudhaakar <rsudhaak@cisco.com>
Subject: Fwd: [6lo] Fwd: [OPSAWG] C= oman Drafts v02

Raghuram,
These drafts, which introduce the use cases and problem statement for = constrained management, are very related to the CoAP draft you co-authored.= I believe it would be very useful if you could review them and submit your= review to the OPSAWG ML, as detailed below. Would that be possible?
Thomas

---------- Forwarded message ----------
From: Thomas Watteyne &= lt;watteyne@eecs.berkeley.edu= >
Date: Sat, Jul 26, 2014 at 10:32 PM
Subject: Fwd: [6lo] Fwd: [OPSAWG] Coman Drafts v02
To: "6tisch@ietf.org" <= 6tisch@ietf.org>


All,

The OPSWAG chairs have kindly agreed to extend the WGLC period for the= following drafts [1] to August 11:


Pascal and myself believe those two drafts to be important for the ong= oing work on managing a 6TiSCH network, and directly in line with e.g. = ;draft-ietf-6tisch-coap. We therefore ask authors of draft-ietf-6tisch= -coap, draft-ietf-6tisch-6top-interface, and any other 6TiSCH WG member to send reviews of this document to OPSAWG ML [= 2].

Thomas

[2] https://www.ietf.org/mailman/listinfo/opsawg


---------- Forwarded message ----------
From: Warren Kumari <warren@kumari.net>
Date: Fri, Jul 25, 2014 at 3:03 PM
Subject: Re: [coman] FW: [OPSAWG] Coman Drafts v02
To: "Ersue, Mehmet (NSN - DE/Munich)" <mehmet.ersue@nsn.com>
Cc: "coman@ietf.or= g" <coman@i= etf.org>, "opsawg-chairs@tools.ietf.org"
<opsaw= g-chairs@tools.ietf.org>


Hi all.

With apologies to the authors...

The chairs of 6LoWPAN and 6TSCH have asked if we can delay the end of
this WGLC so that their communities can review and comment on these 2
documents.

As we have not received very much feedback, this seems relevant to
their WGs, and they asked nicely, we have decided to extend the
deadline to August 11th.

Now, many folk will be traveling back to their homes over the next few
days - this probably means a few, or many hours on an airplane. May I
suggest copying these documents on your computer or reading device of
choice and reviewing the documents on the way home?

Thanks,
W

_______________________________________________
6lo mailing list
6lo@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/6lo


--_000_B8AF2D35C52942F2AFAB2FAEF9919ACAciscocom_-- From nobody Sun Aug 10 13:37:26 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9A001A0143 for ; Sun, 10 Aug 2014 13:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 WO2C1HkAvkCo for ; Sun, 10 Aug 2014 13:31:17 -0700 (PDT) Received: from out24-ams.mf.surf.net (out24-ams.mf.surf.net [145.0.1.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17BE81A000E for ; Sun, 10 Aug 2014 13:31:16 -0700 (PDT) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by outgoing1-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s7AKUxMl007820; Sun, 10 Aug 2014 22:30:59 +0200 Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sun, 10 Aug 2014 22:31:13 +0200 Received: from EXMBX24.ad.utwente.nl ([169.254.4.146]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.03.0181.006; Sun, 10 Aug 2014 22:30:59 +0200 From: To: Thread-Topic: [6lo] Fwd: [OPSAWG] Coman Drafts v02 Thread-Index: AQHPsT2oldfM69TBj0K71rft6/J6yZvKUQNA Date: Sun, 10 Aug 2014 20:30:57 +0000 Message-ID: <76EA352C3C95BB42A2C4F2EE6493AD6E5BCD42DC@EXMBX24.ad.utwente.nl> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.89.9.237] Content-Type: multipart/alternative; boundary="_000_76EA352C3C95BB42A2C4F2EE6493AD6E5BCD42DCEXMBX24adutwent_" MIME-Version: 1.0 X-Bayes-Prob: 0.0001 (Score 0, tokens from: utwente-out:default, base:default, @@RPTN) X-CanIt-Geo: ip=130.89.5.49; country=NL; region=Provincie Overijssel; city=Enschede; latitude=52.2195; longitude=6.8912; http://maps.google.com/maps?q=52.2195,6.8912&z=6 X-CanItPRO-Stream: utwente-out:default (inherits from utwente:default, base:default) X-Canit-Stats-ID: 0uMB8uXP7 - 776ff2026494 - 20140810 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/n0TQGlK4jOowzncyxZ0iqdYRg_g X-Mailman-Approved-At: Sun, 10 Aug 2014 13:37:18 -0700 Cc: pascal.thubert@gmail.com, rsudhaak@cisco.com Subject: Re: [OPSAWG] [6lo] Fwd: Coman Drafts v02 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2014 20:31:19 -0000 --_000_76EA352C3C95BB42A2C4F2EE6493AD6E5BCD42DCEXMBX24adutwent_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBBbGwsDQoNCkknbSB3b3JraW5nIGluIDZUaVNDSCBXRy4gSSByZWFkIGJvdGggeW91ciBk b2N1bWVudHMuIFRoZXkgYXJlIHdlbGwgd3JpdHRlbiBhbmQgYWRkcmVzcyB0aGUgc2NvcGUgcXVp dGUgd2VsbC4NCg0KVGhlc2UgYXJlIG15IG1pbm9yIGNvbW1lbnRzOg0KQm90aCBvZiB0aGVzZSB0 d28gZG9jdW1lbnRzIGRvIG5vdCBzcGVjaWZ5IHRoZSBwcm90b2NvbCB0aGF0IGNhbiBiZSB1c2Vk IGJ5IHRoZSBjZW50cmFsIG1hbmFnZXIgdG8gYWNjZXNzIHRoZSBub2RlcyBpbiB0aGUgbmV0d29y ayBhbmQgbWFuaXB1bGF0ZSB0aGVpciBtYW5hZ2VtZW50IGluZm9ybWF0aW9uIGJhc2UuDQoNCi1Q b3VyaWENCi0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tLQ0KRnJvbTogVGhv bWFzIFdhdHRleW5lIDx3YXR0ZXluZUBlZWNzLmJlcmtlbGV5LmVkdTxtYWlsdG86d2F0dGV5bmVA ZWVjcy5iZXJrZWxleS5lZHU+Pg0KRGF0ZTogU2F0LCBKdWwgMjYsIDIwMTQgYXQgMTA6MzIgUE0N ClN1YmplY3Q6IEZ3ZDogWzZsb10gRndkOiBbT1BTQVdHXSBDb21hbiBEcmFmdHMgdjAyDQpUbzog IjZ0aXNjaEBpZXRmLm9yZzxtYWlsdG86NnRpc2NoQGlldGYub3JnPiIgPDZ0aXNjaEBpZXRmLm9y ZzxtYWlsdG86NnRpc2NoQGlldGYub3JnPj4NCg0KQWxsLA0KDQpUaGUgT1BTV0FHIGNoYWlycyBo YXZlIGtpbmRseSBhZ3JlZWQgdG8gZXh0ZW5kIHRoZSBXR0xDIHBlcmlvZCBmb3IgdGhlIGZvbGxv d2luZyBkcmFmdHMgWzFdIHRvIEF1Z3VzdCAxMToNCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1vcHNhd2ctY29tYW4tdXNlLWNhc2VzLTAyDQpodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9wc2F3Zy1jb21hbi1wcm9ic3RhdGUtcmVxcy0wMQ0KDQpQ YXNjYWwgYW5kIG15c2VsZiBiZWxpZXZlIHRob3NlIHR3byBkcmFmdHMgdG8gYmUgaW1wb3J0YW50 IGZvciB0aGUgb25nb2luZyB3b3JrIG9uIG1hbmFnaW5nIGEgNlRpU0NIIG5ldHdvcmssIGFuZCBk aXJlY3RseSBpbiBsaW5lIHdpdGggZS5nLiBkcmFmdC1pZXRmLTZ0aXNjaC1jb2FwLiBXZSB0aGVy ZWZvcmUgYXNrIGF1dGhvcnMgb2YgZHJhZnQtaWV0Zi02dGlzY2gtY29hcCwgZHJhZnQtaWV0Zi02 dGlzY2gtNnRvcC1pbnRlcmZhY2UsIGFuZCBhbnkgb3RoZXIgNlRpU0NIIFdHIG1lbWJlciB0byBz ZW5kIHJldmlld3Mgb2YgdGhpcyBkb2N1bWVudCB0byBPUFNBV0cgTUwgWzJdLg0KDQpUaG9tYXMN Cg0KWzFdIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi82dGlzY2gvY3VycmVu dC9tc2cwMjQ2NS5odG1sDQpbMl0gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vcHNhd2cNCg0KDQotLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS0NCkZy b206IFdhcnJlbiBLdW1hcmkgPHdhcnJlbkBrdW1hcmkubmV0PG1haWx0bzp3YXJyZW5Aa3VtYXJp Lm5ldD4+DQpEYXRlOiBGcmksIEp1bCAyNSwgMjAxNCBhdCAzOjAzIFBNDQpTdWJqZWN0OiBSZTog W2NvbWFuXSBGVzogW09QU0FXR10gQ29tYW4gRHJhZnRzIHYwMg0KVG86ICJFcnN1ZSwgTWVobWV0 IChOU04gLSBERS9NdW5pY2gpIiA8bWVobWV0LmVyc3VlQG5zbi5jb208bWFpbHRvOm1laG1ldC5l cnN1ZUBuc24uY29tPj4NCkNjOiAiY29tYW5AaWV0Zi5vcmc8bWFpbHRvOmNvbWFuQGlldGYub3Jn PiIgPGNvbWFuQGlldGYub3JnPG1haWx0bzpjb21hbkBpZXRmLm9yZz4+LCAib3BzYXdnLWNoYWly c0B0b29scy5pZXRmLm9yZzxtYWlsdG86b3BzYXdnLWNoYWlyc0B0b29scy5pZXRmLm9yZz4iDQo8 b3BzYXdnLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86b3BzYXdnLWNoYWlyc0B0b29scy5p ZXRmLm9yZz4+DQoNCg0KSGkgYWxsLg0KDQpXaXRoIGFwb2xvZ2llcyB0byB0aGUgYXV0aG9ycy4u Lg0KDQpUaGUgY2hhaXJzIG9mIDZMb1dQQU4gYW5kIDZUU0NIIGhhdmUgYXNrZWQgaWYgd2UgY2Fu IGRlbGF5IHRoZSBlbmQgb2YNCnRoaXMgV0dMQyBzbyB0aGF0IHRoZWlyIGNvbW11bml0aWVzIGNh biByZXZpZXcgYW5kIGNvbW1lbnQgb24gdGhlc2UgMg0KZG9jdW1lbnRzLg0KDQpBcyB3ZSBoYXZl IG5vdCByZWNlaXZlZCB2ZXJ5IG11Y2ggZmVlZGJhY2ssIHRoaXMgc2VlbXMgcmVsZXZhbnQgdG8N CnRoZWlyIFdHcywgYW5kIHRoZXkgYXNrZWQgbmljZWx5LCB3ZSBoYXZlIGRlY2lkZWQgdG8gZXh0 ZW5kIHRoZQ0KZGVhZGxpbmUgdG8gQXVndXN0IDExdGguDQoNCk5vdywgbWFueSBmb2xrIHdpbGwg YmUgdHJhdmVsaW5nIGJhY2sgdG8gdGhlaXIgaG9tZXMgb3ZlciB0aGUgbmV4dCBmZXcNCmRheXMg LSB0aGlzIHByb2JhYmx5IG1lYW5zIGEgZmV3LCBvciBtYW55IGhvdXJzIG9uIGFuIGFpcnBsYW5l LiBNYXkgSQ0Kc3VnZ2VzdCBjb3B5aW5nIHRoZXNlIGRvY3VtZW50cyBvbiB5b3VyIGNvbXB1dGVy IG9yIHJlYWRpbmcgZGV2aWNlIG9mDQpjaG9pY2UgYW5kIHJldmlld2luZyB0aGUgZG9jdW1lbnRz IG9uIHRoZSB3YXkgaG9tZT8NCg0KVGhhbmtzLA0KVw0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCjZsbyBtYWlsaW5nIGxpc3QNCjZsb0BpZXRmLm9yZzxt YWlsdG86NmxvQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by82bG8NCg0KDQo= --_000_76EA352C3C95BB42A2C4F2EE6493AD6E5BCD42DCEXMBX24adutwent_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5EZWFyIEFsbCw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkknbSB3b3JraW5nIGluIDZUaVNDSCBXRy4gSSByZWFkIGJvdGggeW91ciBkb2N1bWVudHMu IFRoZXkgYXJlIHdlbGwgd3JpdHRlbiBhbmQgYWRkcmVzcyB0aGUgc2NvcGUgcXVpdGUgd2VsbC4N CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+VGhlc2UgYXJlIG15IG1pbm9yIGNvbW1lbnRzOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5Cb3RoIG9mIHRoZXNlIHR3byBkb2N1bWVudHMgZG8gbm90IHNwZWNpZnkg dGhlIHByb3RvY29sIHRoYXQgY2FuIGJlIHVzZWQgYnkgdGhlIGNlbnRyYWwgbWFuYWdlciB0byBh Y2Nlc3MgdGhlIG5vZGVzIGluIHRoZSBuZXR3b3JrIGFuZCBtYW5pcHVsYXRlIHRoZWlyIG1hbmFn ZW1lbnQNCiBpbmZvcm1hdGlvbiBiYXNlLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi1Qb3VyaWE8L3NwYW4+PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij4tLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS08YnI+DQpG cm9tOiA8Yj5UaG9tYXMgV2F0dGV5bmU8L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86d2F0dGV5bmVA ZWVjcy5iZXJrZWxleS5lZHUiPndhdHRleW5lQGVlY3MuYmVya2VsZXkuZWR1PC9hPiZndDs8YnI+ DQpEYXRlOiBTYXQsIEp1bCAyNiwgMjAxNCBhdCAxMDozMiBQTTxicj4NClN1YmplY3Q6IEZ3ZDog WzZsb10gRndkOiBbT1BTQVdHXSBDb21hbiBEcmFmdHMgdjAyPGJyPg0KVG86ICZxdW90OzxhIGhy ZWY9Im1haWx0bzo2dGlzY2hAaWV0Zi5vcmciPjZ0aXNjaEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0 OzxhIGhyZWY9Im1haWx0bzo2dGlzY2hAaWV0Zi5vcmciPjZ0aXNjaEBpZXRmLm9yZzwvYT4mZ3Q7 PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ QWxsLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIE9Q U1dBRyBjaGFpcnMgaGF2ZSBraW5kbHkgYWdyZWVkIHRvIGV4dGVuZCB0aGUgV0dMQyBwZXJpb2Qg Zm9yIHRoZSBmb2xsb3dpbmcgZHJhZnRzIFsxXSB0byBBdWd1c3QgMTE6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb3BzYXdnLWNvbWFuLXVzZS1jYXNlcy0wMiIg dGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb3Bz YXdnLWNvbWFuLXVzZS1jYXNlcy0wMjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtb3BzYXdnLWNvbWFuLXByb2JzdGF0ZS1yZXFzLTAxIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vcHNhd2ctY29tYW4tcHJv YnN0YXRlLXJlcXMtMDE8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlBhc2NhbCBhbmQgbXlzZWxmIGJlbGlldmUgdGhvc2UgdHdvIGRyYWZ0 cyB0byBiZSBpbXBvcnRhbnQgZm9yIHRoZSBvbmdvaW5nIHdvcmsgb24gbWFuYWdpbmcgYSA2VGlT Q0ggbmV0d29yaywgYW5kIGRpcmVjdGx5IGluIGxpbmUgd2l0aCBlLmcuJm5ic3A7ZHJhZnQtaWV0 Zi02dGlzY2gtY29hcC4gV2UgdGhlcmVmb3JlIGFzayBhdXRob3JzIG9mJm5ic3A7ZHJhZnQtaWV0 Zi02dGlzY2gtY29hcCwmbmJzcDtkcmFmdC1pZXRmLTZ0aXNjaC02dG9wLWludGVyZmFjZSwNCiBh bmQgYW55IG90aGVyIDZUaVNDSCBXRyBtZW1iZXIgdG8gc2VuZCByZXZpZXdzIG9mIHRoaXMgZG9j dW1lbnQgdG8gT1BTQVdHIE1MIFsyXS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhvbWFzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlsxXSZuYnNwOzxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi82dGlzY2gvY3VycmVudC9tc2cwMjQ2NS5odG1sIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViLzZ0aXNjaC9j dXJyZW50L21zZzAyNDY1Lmh0bWw8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5bMl0mbmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29wc2F3ZyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BzYXdnPC9hPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48YnI+DQotLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS08YnI+DQpGcm9t OiBXYXJyZW4gS3VtYXJpICZsdDs8YSBocmVmPSJtYWlsdG86d2FycmVuQGt1bWFyaS5uZXQiIHRh cmdldD0iX2JsYW5rIj53YXJyZW5Aa3VtYXJpLm5ldDwvYT4mZ3Q7PGJyPg0KRGF0ZTogRnJpLCBK dWwgMjUsIDIwMTQgYXQgMzowMyBQTTxicj4NClN1YmplY3Q6IFJlOiBbY29tYW5dIEZXOiBbT1BT QVdHXSBDb21hbiBEcmFmdHMgdjAyPGJyPg0KVG86ICZxdW90O0Vyc3VlLCBNZWhtZXQgKE5TTiAt IERFL011bmljaCkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzptZWhtZXQuZXJzdWVAbnNuLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPm1laG1ldC5lcnN1ZUBuc24uY29tPC9hPiZndDs8YnI+DQpDYzog JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmNvbWFuQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Y29t YW5AaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Y29tYW5AaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5jb21hbkBpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJt YWlsdG86b3BzYXdnLWNoYWlyc0B0b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9wc2F3 Zy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8L2E+JnF1b3Q7PGJyPg0KJmx0OzxhIGhyZWY9Im1haWx0 bzpvcHNhd2ctY2hhaXJzQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b3BzYXdnLWNo YWlyc0B0b29scy5pZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGJyPg0KPGJyPg0KSGkgYWxsLjxicj4N Cjxicj4NCldpdGggYXBvbG9naWVzIHRvIHRoZSBhdXRob3JzLi4uPGJyPg0KPGJyPg0KVGhlIGNo YWlycyBvZiA2TG9XUEFOIGFuZCA2VFNDSCBoYXZlIGFza2VkIGlmIHdlIGNhbiBkZWxheSB0aGUg ZW5kIG9mPGJyPg0KdGhpcyBXR0xDIHNvIHRoYXQgdGhlaXIgY29tbXVuaXRpZXMgY2FuIHJldmll dyBhbmQgY29tbWVudCBvbiB0aGVzZSAyPGJyPg0KZG9jdW1lbnRzLjxicj4NCjxicj4NCkFzIHdl IGhhdmUgbm90IHJlY2VpdmVkIHZlcnkgbXVjaCBmZWVkYmFjaywgdGhpcyBzZWVtcyByZWxldmFu dCB0bzxicj4NCnRoZWlyIFdHcywgYW5kIHRoZXkgYXNrZWQgbmljZWx5LCB3ZSBoYXZlIGRlY2lk ZWQgdG8gZXh0ZW5kIHRoZTxicj4NCmRlYWRsaW5lIHRvIEF1Z3VzdCAxMXRoLjxicj4NCjxicj4N Ck5vdywgbWFueSBmb2xrIHdpbGwgYmUgdHJhdmVsaW5nIGJhY2sgdG8gdGhlaXIgaG9tZXMgb3Zl ciB0aGUgbmV4dCBmZXc8YnI+DQpkYXlzIC0gdGhpcyBwcm9iYWJseSBtZWFucyBhIGZldywgb3Ig bWFueSBob3VycyBvbiBhbiBhaXJwbGFuZS4gTWF5IEk8YnI+DQpzdWdnZXN0IGNvcHlpbmcgdGhl c2UgZG9jdW1lbnRzIG9uIHlvdXIgY29tcHV0ZXIgb3IgcmVhZGluZyBkZXZpY2Ugb2Y8YnI+DQpj aG9pY2UgYW5kIHJldmlld2luZyB0aGUgZG9jdW1lbnRzIG9uIHRoZSB3YXkgaG9tZT88YnI+DQo8 YnI+DQpUaGFua3MsPGJyPg0KVzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCjZsbyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86NmxvQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+NmxvQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vNmxvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82bG88L2E+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_76EA352C3C95BB42A2C4F2EE6493AD6E5BCD42DCEXMBX24adutwent_-- From nobody Sun Aug 10 13:59:24 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E76A21A00A5 for ; Sun, 10 Aug 2014 13:59:21 -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 qmmIc_l585sZ for ; Sun, 10 Aug 2014 13:59:21 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99AC31A009E for ; Sun, 10 Aug 2014 13:59:20 -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 s7AKx30r020731; Sun, 10 Aug 2014 22:59:03 +0200 (CEST) Received: from [192.168.217.106] (p54891B01.dip0.t-ipconnect.de [84.137.27.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 878D926E; Sun, 10 Aug 2014 22:59:02 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: Date: Sun, 10 Aug 2014 22:59:00 +0200 X-Mao-Original-Outgoing-Id: 429397140.586196-e904e2c898e3e8889125e99aeffcdb64 Content-Transfer-Encoding: quoted-printable Message-Id: <59DBFA6B-93BD-4675-9DC6-580598517EC8@tzi.org> References: To: Thomas Watteyne X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/tBBpU4uweS6D8LMDR2O1Q9fwdyA Cc: opsawg Subject: Re: [OPSAWG] Thomas' review of draft-ietf-opsawg-coman-probstate-reqs-02 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2014 20:59:22 -0000 On 10 Aug 2014, at 09:18, Thomas Watteyne = wrote: > As such, it is not a traditional requirement document, as does not = list requirements as MUSTs and SHOULDs, but rather gives a clear = overview of what those requirements might be. In that sense, I would = suggest to not use the term "Requirements" in the title, but maybe = "potential requirements=94. Objectives? (That is a term that has turned out useful in other IETF work.) Desiderata? (A term that seems to be popular in CFRG right now, which also is trying = to collect some soft form of requirements.) Gr=FC=DFe, Carsten From nobody Sun Aug 10 15:02:16 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13D0D1A0100 for ; Sun, 10 Aug 2014 15:02:15 -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 IEJUuddfI4bn for ; Sun, 10 Aug 2014 15:02:14 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1C231A00E7 for ; Sun, 10 Aug 2014 15:02:13 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id r10so9727015pdi.34 for ; Sun, 10 Aug 2014 15:02:13 -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=RlBdY+gFSovn4IV16ERV73moW9W4eM6Xb3lg9dcSnHs=; b=Xu63/HUvElKGjmrUj+gPa1K8GZ8JisTdXTKcVH3pJNaZava8NbTeJcnwHL3+OV4qg2 guOJDputvU5VGE63atS1ugbmdeHvljbEM0WUOi4OpONZFeTRoJ3DM8Wtw0cpobPpcfXl dx3bs6CTxWelIAKNGpxt9ugB0aPKvO62H8Z4oLAHyUmy5NnawClY1+kdNlCMHgb0DV0i eC+FKoXwWjxM84pLFcaJgDxHPofGKTZGVTZT4AJOx0V9XKetiXkCTpG5EZfPa9NPLanr RnYaJEGib74cBq4kxeqsVzLoHUyoPtku8bjF/WJVJ6/dA3QCyPw7g/ut9AXHOGYuzhwj zcBg== X-Received: by 10.69.26.33 with SMTP id iv1mr11796630pbd.62.1407708133521; Sun, 10 Aug 2014 15:02:13 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.144.1 with HTTP; Sun, 10 Aug 2014 15:01:53 -0700 (PDT) In-Reply-To: <59DBFA6B-93BD-4675-9DC6-580598517EC8@tzi.org> References: <59DBFA6B-93BD-4675-9DC6-580598517EC8@tzi.org> From: Thomas Watteyne Date: Sun, 10 Aug 2014 15:01:53 -0700 X-Google-Sender-Auth: 0e7KFL33TnsaNpqlakgNDCqV70M Message-ID: To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a1134b6bc3eff4b05004d9736 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/AinpSWv6BfBuQ934Z1sqPuefWD4 Cc: opsawg Subject: Re: [OPSAWG] Thomas' review of draft-ietf-opsawg-coman-probstate-reqs-02 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2014 22:02:15 -0000 --001a1134b6bc3eff4b05004d9736 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 Thanks Carsten for the suggestions. On Sun, Aug 10, 2014 at 1:59 PM, Carsten Bormann wrote: > On 10 Aug 2014, at 09:18, Thomas Watteyne > wrote: > > > As such, it is not a traditional requirement document, as does not list > requirements as MUSTs and SHOULDs, but rather gives a clear overview of > what those requirements might be. In that sense, I would suggest to not u= se > the term "Requirements" in the title, but maybe "potential requirements= =E2=80=9D. > > Objectives? > (That is a term that has turned out useful in other IETF work.) > > Desiderata? > (A term that seems to be popular in CFRG right now, which also is trying > to collect some soft form of requirements.) > > Gr=C3=BC=C3=9Fe, Carsten > > --001a1134b6bc3eff4b05004d9736 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

Thanks Carsten for the suggestions.<= /div>


On= Sun, Aug 10, 2014 at 1:59 PM, Carsten Bormann <cabo@tzi.org> wro= te:
On 10 Aug 2014, at 09:18, Th= omas Watteyne <watteyne@ee= cs.berkeley.edu> wrote:

> As such, it is not a traditional requirement document, as does not lis= t requirements as MUSTs and SHOULDs, but rather gives a clear overview of w= hat those requirements might be. In that sense, I would suggest to not use = the term "Requirements" in the title, but maybe "potential r= equirements=E2=80=9D.

Objectives?
(That is a term that has turned out useful in other IETF work.)

Desiderata?
(A term that seems to be popular in CFRG right now, which also is trying to= collect some soft form of requirements.)

Gr=C3=BC=C3=9Fe, Carsten


--001a1134b6bc3eff4b05004d9736-- From nobody Sun Aug 10 16:08:33 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 541121A0178; Sun, 10 Aug 2014 16:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.433 X-Spam-Level: * X-Spam-Status: No, score=1.433 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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, T_FILL_THIS_FORM_SHORT=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 RHp9n6rsntZ3; Sun, 10 Aug 2014 16:08:20 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 275841A0176; Sun, 10 Aug 2014 16:08:20 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id r10so9731492pdi.20 for ; Sun, 10 Aug 2014 16:08:19 -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=p3/riG8Z++Rtpr8UK41KZAsHgWAl0nC2TwVouBpiftY=; b=tS85AxgMP4cP03fSykp2DzJ2HKogxLF7kVXl6IZckukcWbfS7EJJ+JN1n/hSDf1VfS 5bWt5BtGAYsgsFMuOhcWokCbuRMRUVfk+eZKyTu33w44B+uanRrbdeC6R7kABSpXhc67 qayPybF+/mcnecT0jEZBCUsuGZ/eJfotF8PWY1a/+fnOArAUUrsmoLpa7aoqedBkQ31j zkWfFPFRID5d6Hc+0HZtxwtovwp2egiADWR+qQPdBmcSS7taLLB8I+7EDyOHJTKUmr91 tglOS9C7z6juJDXBg3hJ2oD4/9ueQONpK1ePVjiySv2TbQ3A4GcgtrY4B+OAH+y4FzX2 kP0w== X-Received: by 10.70.36.239 with SMTP id t15mr19665766pdj.83.1407712099628; Sun, 10 Aug 2014 16:08:19 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.144.1 with HTTP; Sun, 10 Aug 2014 16:07:59 -0700 (PDT) In-Reply-To: References: From: Thomas Watteyne Date: Sun, 10 Aug 2014 16:07:59 -0700 X-Google-Sender-Auth: q7-DCKFwG2ynVSg0E7bMcP9nLaI Message-ID: To: opsawg , "6tisch@ietf.org" <6tisch@ietf.org> Content-Type: multipart/alternative; boundary=089e0103ed82a4fcc505004e8335 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/S_rbzPnFWkyigy-LVQ6y0xXkUZI Subject: Re: [OPSAWG] Thomas's review of draft-ietf-opsawg-coman-use-cases-02 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2014 23:08:31 -0000 --089e0103ed82a4fcc505004e8335 Content-Type: text/plain; charset=UTF-8 [resend'ing CC'ing 6TiSCH ML] On Fri, Aug 8, 2014 at 11:29 PM, Thomas Watteyne wrote: > I was asked to do a detailed review > of draft-ietf-opsawg-coman-use-cases-02. > > Constrained management is important for the 6TiSCH WG. I am really happy > to see that the COMAN work has been able to progress in OPSAWG. I wasn't > aware of the progress on this document in OPS until IETF90 (my fault...); > but have since announced it to the 6TiSCH WG. > > The 6TiSCH architecture supports a mode in which a central entity manages > the communication schedule of the nodes. Typically, the node form a > constrained network (very little bandwidth, energy constraints, etc), and > the (possible less constrained) management entity sits on the edge of that > network. This management entity need to (1) set a number of parameters on > the motes and (2) monitor some statistics to possibly trigger some action. > Nothing particularly surprising, indeed. > > So far, we have been defined our own "home brew" management protocol on > top of CoAP (draft-ietf-6tisch-coap-01). There is really nothing specific > to 6TiSCH in that solution, and we'd love to be able to reuse any more > generic management solution for constrained environments. Ideally, this > management solution would be shared by other software pieces running on the > constrained device, e.g. the 6LoWPAN layer. > > I am also reading draft-ietf-opsawg-coman-probstate-reqs-02, the review of > which I will send in a separate e-mail to keep things clean. > > Thomas > > GENERAL > -------------- > > The different sections are very "independent", and the draft would benefit > from some text at the beginning which would glue those together. Ideas are: > - enforce the same structure for each use case section, possibly by > grouping the paragraphs under a title, e.g. "description of the use case", > "expectation from management solution", etc. > - add a table/list at the beginning which summarizes the different > features one can expect from a management system, for each of the use cases > (e.g. "privacy" in Medical Applications). This would give the reader a > one-page overview, allowing him/her to more easily go back to the text. > > In some use cases, while the use case is very clearly described, it's hard > to see what the use case is *for the management*. This is particularly true > in "Building Automation", and somewhat in "Industrial Applications". > > It might be interesting, for each use case, to describe how the management > changes over the lifetime of the system. For example, some security aspect > (authentication, authorization) only exist during commissioning. > > It would be good, although maybe hard, to have common metrics across all > uses cases, allowing for an easier comparison. For example, the approx. > amount of management data, generation rate of this management data (and > associated size). > > It would be good to order the use cases logically, and highlight in the > intro text what the extremes are. For example (and I'm making this up), > management in the Field Operations use cases involves the most frequent > exchange of data, and hence a large overhead, than a Home Automation > application in which most management is done during commissioning. > > DETAILED > --------------- > > please find my comments below, prefixed by "^TW>" > > > Internet Engineering Task Force M. Ersue, Ed. > Internet-Draft Nokia Networks > Intended status: Informational D. Romascanu > Expires: January 5, 2015 Avaya > J. Schoenwaelder > A. Sehgal > Jacobs University Bremen > July 4, 2014 > > > Management of Networks with Constrained Devices: Use Cases > draft-ietf-opsawg-coman-use-cases-02 > > Abstract > > This document discusses use cases concerning the management of > networks, where constrained devices are involved. A problem > statement, deployment options and the requirements on the networks > with constrained devices can be found in the companion document on > "Management of Networks with Constrained Devices: Problem Statement > and Requirements". > > Status of This Memo > > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is at http://datatracker.ietf.org/drafts/current/. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > This Internet-Draft will expire on January 5, 2015. > > Copyright Notice > > Copyright (c) 2014 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > > > > Ersue, et al. Expires January 5, 2015 [Page 1] > Internet-Draft Constrained Management: Use Cases July 2014 > > > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the Simplified BSD License. > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 > 2. Access Technologies . . . . . . . . . . . . . . . . . . . . . 4 > 2.1. Constrained Access Technologies . . . . . . . . . . . . . 4 > 2.2. Cellular Access Technologies . . . . . . . . . . . . . . 4 > 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 > 3.1. Environmental Monitoring . . . . . . . . . . . . . . . . 6 > 3.2. Infrastructure Monitoring . . . . . . . . . . . . . . . . 6 > 3.3. Industrial Applications . . . . . . . . . . . . . . . . . 7 > 3.4. Energy Management . . . . . . . . . . . . . . . . . . . . 9 > 3.5. Medical Applications . . . . . . . . . . . . . . . . . . 11 > 3.6. Building Automation . . . . . . . . . . . . . . . . . . . 12 > 3.7. Home Automation . . . . . . . . . . . . . . . . . . . . . 13 > 3.8. Transport Applications . . . . . . . . . . . . . . . . . 14 > 3.9. Community Network Applications . . . . . . . . . . . . . 16 > 3.10. Field Operations . . . . . . . . . . . . . . . . . . . . 18 > 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 > 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 > 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 > 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 > 8. Informative References . . . . . . . . . . . . . . . . . . . 20 > Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 21 > A.1. draft-ietf-opsawg-coman-use-cases-01 - draft-ietf-opsawg- > coman-use-cases-02 . . . . . . . . . . . . . . . . . . . 21 > A.2. draft-ietf-opsawg-coman-use-cases-00 - draft-ietf-opsawg- > coman-use-cases-01 . . . . . . . . . . . . . . . . . . . 22 > A.3. draft-ersue-constrained-mgmt-03 - draft-ersue-opsawg- > coman-use-cases-00 . . . . . . . . . . . . . . . . . . . 23 > A.4. draft-ersue-constrained-mgmt-02-03 . . . . . . . . . . . 23 > A.5. draft-ersue-constrained-mgmt-01-02 . . . . . . . . . . . 24 > A.6. draft-ersue-constrained-mgmt-00-01 . . . . . . . . . . . 25 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 > > 1. Introduction > > Small devices with limited CPU, memory, and power resources, so > called constrained devices (aka. sensor, smart object, or smart > device) can be connected to a network. Such a network of constrained > devices itself may be constrained or challenged, e.g., with > unreliable or lossy channels, wireless technologies with limited > bandwidth and a dynamic topology, needing the service of a gateway or > > > > Ersue, et al. Expires January 5, 2015 [Page 2] > Internet-Draft Constrained Management: Use Cases July 2014 > > > proxy to connect to the Internet. In other scenarios, the > constrained devices can be connected to a non-constrained network > using off-the-shelf protocol stacks. Constrained devices might be in > charge of gathering information in diverse settings including natural > ecosystems, buildings, and factories and send the information to one > or more server stations. > > Network management is characterized by monitoring network status, > detecting faults, and inferring their causes, setting network > parameters, and carrying out actions to remove faults, maintain > normal operation, and improve network efficiency and application > performance. The traditional network management application > periodically collects information from a set of elements that are > needed to manage, processes the data, and presents them to the > network management users. Constrained devices, however, often have > limited power, low transmission range, and might be unreliable > > TW> I don't understand what you mean by "be unreliable". Do you mean that > the > TW> device itself is unreliable (what exactly does that mean?), or that the > TW> communication with that device is unreliable? > TW> I would add that such networks most often have low capacity. > TW> I would add that such networks most often have high latency. > > They > might also need to work in hostile environments with advanced > security requirements or need to be used in harsh environments for a > long time without supervision. Due to such constraints, the > management of a network with constrained devices offers different > type of challenges compared to the management of a traditional IP > network. > > This document aims to understand use cases for the management of a > network, where constrained devices are involved. The document lists > and discusses diverse use cases for the management from the network > as well as from the application point of view. The list of discussed > use cases is not an exhaustive one since other scenarios, currently > unknown to the authors, are possible. > > TW> Typo below, remove "are". > > are The application scenarios > discussed aim to show where networks of constrained devices are > expected to be deployed. For each application scenario, we first > briefly describe the characteristics followed by a discussion on how > network management can be provided, who is likely going to be > responsible for it, and on which time-scale management operations are > likely to be carried out. > > A problem statement, deployment and management topology options as > well as the requirements on the networks with constrained devices can > be found in the companion document [COM-REQ]. > > This documents builds on the terminology defined in [RFC7228] and > [COM-REQ]. [RFC7228] is a base document for the terminology > concerning constrained devices and constrained networks. Some use > cases specific to IPv6 over Low-Power Wireless Personal Area Networks > (6LoWPANs) can be found in [RFC6568]. > > > > > > > Ersue, et al. Expires January 5, 2015 [Page 3] > Internet-Draft Constrained Management: Use Cases July 2014 > > > 2. Access Technologies > > Besides the management requirements imposed by the different use > cases, the access technologies used by constrained devices can impose > restrictions and requirements upon the Network Management System > (NMS) and protocol of choice. > > It is possible that some networks of constrained devices might > utilize traditional non-constrained access technologies for network > access, e.g., local area networks with plenty of capacity. In such > scenarios, the constrainedness of the device presents special > management restrictions and requirements rather than the access > technology utilized. > > However, in other situations constrained or cellular access > technologies might be used for network access, thereby causing > management restrictions and requirements to arise as a result of the > underlying access technologies. > > 2.1. Constrained Access Technologies > > Due to resource restrictions, embedded devices deployed as sensors > and actuators in the various use cases utilize low-power low data- > rate wireless access technologies such as IEEE 802.15.4, DECT ULE or > BT-LE for network connectivity. > > In such scenarios, it is important for the NMS to be aware of the > restrictions imposed by these access technologies to efficiently > manage these constrained devices. Specifically, such low-power low > data-rate access technologies typically have small frame sizes. So > it would be important for the NMS and management protocol of choice > to craft packets in a way that avoids fragmentation and reassembly of > packets since this can use valuable memory on constrained devices. > > Devices using such access technologies might operate via a gateway > that translates between these access technologies and more > traditional Internet protocols. A hierarchical approach to device > management in such a situation might be useful, wherein the gateway > device is in-charge of devices connected to it, while the NMS > conducts management operations only to the gateway. > > 2.2. Cellular Access Technologies > > Machine to machine (M2M) services are increasingly provided by mobile > service providers as numerous devices, home appliances, utility > meters, cars, video surveillance cameras, and health monitors, are > connected with mobile broadband technologies. Different > applications, e.g., in a home appliance or in-car network, use > > > > Ersue, et al. Expires January 5, 2015 [Page 4] > Internet-Draft Constrained Management: Use Cases July 2014 > > > > TW> typo, Zigbee -> ZigBee (throughout doc) > > Bluetooth, Wi-Fi or Zigbee locally and connect to a cellular module > acting as a gateway between the constrained environment and the > mobile cellular network. > > Such a gateway might provide different options for the connectivity > of mobile networks and constrained devices: > > TW> BT-LE --> Bluetooth Low-Energy (BT-LE) > > o a smart phone with 3G/4G and WLAN radio might use BT-LE to connect > to the devices in a home area network, > > o a femtocell might be combined with home gateway functionality > acting as a low-power cellular base station connecting smart > devices to the application server of a mobile service provider, > > o an embedded cellular module with LTE radio connecting the devices > in the car network with the server running the telematics service, > > o an M2M gateway connected to the mobile operator network supporting > diverse IoT connectivity technologies including ZigBee and CoAP > over 6LoWPAN over IEEE 802.15.4. > > Common to all scenarios above is that they are embedded in a service > and connected to a network provided by a mobile service provider. > Usually there is a hierarchical deployment and management topology in > place where different parts of the network are managed by different > management entities and the count of devices to manage is high (e.g. > many thousands). In general, the network is comprised by manifold > type and size of devices matching to different device classes. As > such, the managing entity needs to be prepared to manage devices with > diverse capabilities using different communication or management > protocols. In case the devices are directly connected to a gateway > they most likely are managed by a management entity integrated with > the gateway, which itself is part of the Network Management System > (NMS) run by the mobile operator. Smart phones or embedded modules > connected to a gateway might be themselves in charge to manage the > devices on their level. The initial and subsequent configuration of > such a device is mainly based on self-configuration and is triggered > by the device itself. > > The gateway might be in charge of filtering and aggregating the data > received from the device as the information sent by the device might > be mostly redundant. > > 3. Use Cases > > > > > > > > Ersue, et al. Expires January 5, 2015 [Page 5] > Internet-Draft Constrained Management: Use Cases July 2014 > > > 3.1. Environmental Monitoring > > Environmental monitoring applications are characterized by the > deployment of a number of sensors to monitor emissions, water > quality, or even the movements and habits of wildlife. Other > applications in this category include earthquake or tsunami early- > warning systems. The sensors often span a large geographic area, > they can be mobile, and they are often difficult to replace. > Furthermore, the sensors are usually not protected against tampering. > > Management of environmental monitoring applications is largely > concerned with the monitoring whether the system is still functional > and the roll-out of new constrained devices in case the system looses > too much of its structure. The constrained devices themselves need > to be able to establish connectivity (auto-configuration) and they > need to be able to deal with events such as loosing neighbors or > being moved to other locations. > > Management responsibility typically rests with the organization > running the environmental monitoring application. Since these > monitoring applications must be designed to tolerate a number of > failures, the time scale for detecting and recording failures is for > some of these applications likely measured in hours and repairs might > easily take days. In fact, in some scenarios it might be more cost- > and time-effective to not repair such devices at all. However, for > certain environmental monitoring applications, much tighter time > scales may exist and might be enforced by regulations (e.g., > monitoring of nuclear radiation). > > 3.2. Infrastructure Monitoring > > Infrastructure monitoring is concerned with the monitoring of > infrastructures such as bridges, railway tracks, or (offshore) > windmills. The primary goal is usually to detect any events or > changes of the structural conditions that can impact the risk and > safety of the infrastructure being monitored. Another secondary goal > is to schedule repair and maintenance activities in a cost effective > manner. > > The infrastructure to monitor might be in a factory or spread over a > wider area but difficult to access. As such, the network in use > might be based on a combination of fixed and wireless technologies, > which use robust networking equipment and support reliable > communication via application layer transactions. It is likely that > constrained devices in such a network are mainly C2 > > >TW please define "C2", and provide RFC > > devices and have > to be controlled centrally by an application running on a server. In > case such a distributed network is widely spread, the wireless > devices might use diverse long-distance wireless technologies such as > > > > Ersue, et al. Expires January 5, 2015 [Page 6] > Internet-Draft Constrained Management: Use Cases July 2014 > > TW> I don't fully understand what you mean by "e.g. based on embedded > hardware > TW> modules", in partcular the "e.g." part. Maybe write the idea out in a > TW> separate sentence? > > WiMAX, or 3G/LTE, e.g. based on embedded hardware modules. In cases, > where an in-building network is involved, the network can be based on > Ethernet or wireless technologies suitable for in-building usage. > > The management of infrastructure monitoring applications is primarily > concerned with the monitoring of the functioning of the system. > Infrastructure monitoring devices are typically rolled out and > installed by dedicated experts and changes are rare since the > infrastructure itself changes rarely. However, monitoring devices > are often deployed in unsupervised environments and hence special > attention must be given to protecting the devices from being > modified. > > Management responsibility typically rests with the organization > owning the infrastructure or responsible for its operation. The time > scale for detecting and recording failures is likely measured in > hours and repairs might easily take days. However, certain events > (e.g., natural disasters) may require that status information be > obtained much more quickly and that replacements of failed sensors > can be rolled out quickly (or redundant sensors are activated > quickly). In case the devices are difficult to access, a self- > healing feature on the device might become necessary. > > 3.3. Industrial Applications > > Industrial Applications and smart manufacturing refer to tasks such > as networked control and monitoring of manufacturing equipment, asset > and situation management, or manufacturing process control. For the > management of a factory it is becoming essential to implement smart > capabilities. From an engineering standpoint, industrial > applications are intelligent systems enabling rapid manufacturing of > new products, dynamic response to product demands, and real-time > optimization of manufacturing production and supply chain networks. > Potential industrial applications (e.g., for smart factories and > smart manufacturing) are: > > o Digital control systems with embedded, automated process controls, > operator tools, as well as service information systems optimizing > plant operations and safety. > > o Asset management using predictive maintenance tools, statistical > evaluation, and measurements maximizing plant reliability. > > o Smart sensors detecting anomalies to avoid abnormal or > catastrophic events. > > > > > > > Ersue, et al. Expires January 5, 2015 [Page 7] > Internet-Draft Constrained Management: Use Cases July 2014 > > > o Smart systems integrated within the industrial energy management > system and externally with the smart grid enabling real-time > energy optimization. > > TW> I don't understand what the "management" part here refers to in this > TW> section. I expect the draft to deal exclusively with the management > needs > TW> for the constrained network (e.g. monitoring 6LoWPAN counters). This > TW> section seems to deal with the management of a smart plant. > > Management of Industrial Applications and smart manufacturing may in > some situations involve Building Automation tasks such as control of > energy, HVAC (heating, ventilation, and air conditioning), lighting, > or access control. Interacting with management systems from other > application areas might be important in some cases (e.g., > environmental monitoring for electric energy production, energy > management for dynamically scaling manufacturing, vehicular networks > for mobile asset tracking). > > Sensor networks are an essential technology used for smart > manufacturing. Measurements, automated controls, plant optimization, > health and safety management, and other functions are provided by a > large number of networked sectors. Data interoperability and > seamless exchange of product, process, and project data are enabled > through interoperable data systems used by collaborating divisions or > business systems. Intelligent automation and learning systems are > vital to smart manufacturing but must be effectively integrated with > the decision environment. Wireless sensor networks (WSN) have been > developed for machinery Condition-based Maintenance (CBM) as they > offer significant cost savings and enable new functionalities. > Inaccessible locations, rotating machinery, hazardous areas, and > mobile assets can be reached with wireless sensors. WSNs can provide > today wireless link reliability, real-time capabilities, and quality- > of-service and enable industrial and related wireless sense and > control applications. > > Management of industrial and factory applications is largely focused > on the monitoring whether the system is still functional, real-time > continuous performance monitoring, and optimization as necessary. > The factory network might be part of a campus network or connected to > the Internet. The constrained devices in such a network need to be > able to establish configuration themselves (auto-configuration) and > might need to deal with error conditions as much as possible locally. > Access control has to be provided with multi-level administrative > access and security. Support and diagnostics can be provided through > remote monitoring access centralized outside of the factory. > > Management responsibility is typically owned by the organization > running the industrial application. Since the monitoring > applications must handle a potentially large number of failures, the > time scale for detecting and recording failures is for some of these > applications likely measured in minutes. However, for certain > industrial applications, much tighter time scales may exist, e.g. in > > > > > Ersue, et al. Expires January 5, 2015 [Page 8] > Internet-Draft Constrained Management: Use Cases July 2014 > > > real-time, which might be enforced by the manufacturing process or > the use of critical material. > > 3.4. Energy Management > > The EMAN working group developed an energy management framework > [I-D.ietf-eman-framework] for devices and device components within or > connected to communication networks. This document observes that one > of the challenges of energy management is that a power distribution > network is responsible for the supply of energy to various devices > and components, while a separate communication network is typically > used to monitor and control the power distribution network. Devices > in the context of energy management can be monitored for parameters > like Power, Energy, Demand and Power Quality. If a device contains > batteries, they can be also monitored and managed. > > Energy devices differ in complexity and may include basic sensors or > switches, specialized electrical meters, or power distribution units > (PDU), and subsystems inside the network devices (routers, network > switches) or home or industrial appliances. The operators of an > Energy Management System are either the utility providers or > customers that aim to control and reduce the energy consumption and > the associated costs. The topology in use differs and the deployment > can cover areas from small surfaces (individual homes) to large > geographical areas. The EMAN requirements document [RFC6988] > discusses the requirements for energy management concerning > monitoring and control functions. > > It is assumed that Energy Management will apply to a large range of > devices of all classes and networks topologies. Specific resource > monitoring like battery utilization and availability may be specific > to devices with lower physical resources (device classes C0 or C1). > > Energy Management is especially relevant to the Smart Grid. A Smart > Grid is an electrical grid that uses data networks to gather and to > act on energy and power-related information in an automated fashion > with the goal to improve the efficiency, reliability, economics, and > sustainability of the production and distribution of electricity. > > Smart Metering is a good example of Smart Grid based Energy > Management applications. Different types of possibly wireless small > meters produce all together a large amount of data, which is > collected by a central entity and processed by an application server, > which may be located within the customer's residence or off-site in a > data-center. The communication infrastructure can be provided by a > mobile network operator as the meters in urban areas will have most > likely a cellular or WiMAX radio. In case the application server is > > > > > Ersue, et al. Expires January 5, 2015 [Page 9] > Internet-Draft Constrained Management: Use Cases July 2014 > > > located within the residence, such meters are more likely to use WiFi > protocols to interconnect with an existing network. > > An Advanced Metering Infrastructure (AMI) network is another example > of the Smart Grid that enables an electric utility to retrieve > frequent electric usage data from each electric meter installed at a > customer's home or business. Unlike Smart Metering, in which case > the customer or their agents install appliance level meters, an AMI > infrastructure is typically managed by the utility providers and > could also include other distribution automation devices like > transformers and reclosers. Meters in AMI networks typically contain > constrained devices that connect to mesh networks with a low- > bandwidth radio. Usage data and outage notifications can be sent by > these meters to the utility's headend systems, via aggregation points > of higher-end router devices that bridge the constrained network to a > less constrained network via cellular, WiMAX, or Ethernet. Unlike > meters, these higher-end devices might be installed on utility poles > owned and operated by a separate entity. > > It thereby becomes important for a management application to not only > be able to work with diverse types of devices, but also over multiple > links that might be operated and managed by separate entities, each > having divergent policies for their own devices and network segments. > During management operations, like firmware updates, it is important > that the management system performs robustly in order to avoid > accidental outages of critical power systems that could be part of > AMI networks. In fact, since AMI networks must also report on > outages, the management system might have to manage the energy > properties of battery operated AMI devices themselves as well. > > A management system for home based Smart Metering solutions is likely > to have few devices laid out in a simple topology. > TW> how many are few? what's a simple topology? While (I think) I have a > good > TW> of what that might be, proposing a range might help with scope > However, AMI > networks installations could have thousands of nodes per router, > i.e., higher-end device, which organize themselves in an ad-hoc > manner. As such, a management system for AMI networks will need to > discover and operate over complex topologies as well. In some > situations, it is possible that the management system might also have > to setup and manage the topology of nodes, especially critical > routers. Encryption key management and sharing in both types of > network > TW> typo network*s* > is also likely to be important for providing confidentiality > for all data traffic. In AMI networks the key may be obtained by a > meter only after an end-to-end authentication process based on > certificates. Smart Metering solution could adopt a similar approach > or the security may be implied due to the encrypted WiFi networks > they become part of. > > TW> Please use either Wi-Fi or WiFi. There must be an official one? > > The management of such a network requires end-to-end management of > and information exchange through different types of networks. > > > > Ersue, et al. Expires January 5, 2015 [Page 10] > Internet-Draft Constrained Management: Use Cases July 2014 > > > However, as of today there is no integrated energy management > approach and no common information model available. Specific energy > management applications or network islands use their own management > mechanisms. > > 3.5. Medical Applications > > Constrained devices can be seen as an enabling technology for > advanced and possibly remote health monitoring and emergency > notification systems, ranging from blood pressure and heart rate > monitors to advanced devices capable to monitor > TW> rephrase to "capable of monitoring"? > implanted > technologies, such as pacemakers or advanced hearing aids. Medical > sensors may not only be attached to human bodies, they might also > exist in the infrastructure used by humans such as bathrooms or > kitchens. Medical applications will also be used to ensure > treatments are being applied properly and they might guide people > losing orientation. Fitness and wellness applications, such as > connected scales or wearable heart monitors, encourage consumers to > exercise and empower self-monitoring of key fitness indicators. > Different applications use Bluetooth, Wi-Fi or Zigbee connections to > access the patient's smartphone or home cellular connection to access > the Internet. > > Constrained devices that are part of medical applications are managed > either by the users of those devices or by an organization providing > medical (monitoring) services for physicians. In the first case, > management must be automatic and or > TW> "and/or"? > easy to install and setup by > average people. In the second case, it can be expected that devices > be controlled by specially trained people. In both cases, however, > it is crucial to protect the privacy of the people to which medical > devices are attached. Even though the data collected by a heart beat > monitor might be protected, the pure fact that someone carries such a > device may need protection. As such, certain medical appliances may > not want to participate in discovery and self-configuration protocols > in order to remain invisible. > > Many medical devices are likely to be used (and relied upon) to > provide data to physicians in critical situations since the biggest > market is likely elderly and handicapped people. Timely delivery of > data can be quite important in certain applications like patient > mobility monitoring in oldage homes. Data must reach the physician > and/or emergency services within specified limits of time in order to > be useful. As such, fault detection of the communication network or > the constrained devices becomes a crucial function of the management > system that must be carried out with high reliability and, depending > on the medical appliance and its application, within seconds. > > > > > > Ersue, et al. Expires January 5, 2015 [Page 11] > Internet-Draft Constrained Management: Use Cases July 2014 > > > 3.6. Building Automation > > Building automation comprises the distributed systems designed and > deployed to monitor and control the mechanical, electrical and > electronic systems inside buildings with various destinations (e.g., > public and private, industrial, institutions, or residential). > Advanced Building Automation Systems (BAS) may be deployed > concentrating the various functions of safety, environmental control, > occupancy, security. More and more the deployment of the various > functional systems is connected to the same communication > infrastructure (possibly Internet Protocol based), which may involve > wired or wireless communications networks inside the building. > > Building automation requires the deployment of a large number > (10-100.000) of sensors that monitor the status of devices, and > parameters inside the building and controllers with different > specialized functionality for areas within the building or the > totality of the building. Inter-node distances between neighboring > nodes vary between 1 to 20 meters. Contrary to home automation, in > building management the devices are expected to be managed assets and > known to a set of commissioning tools and a data storage, such that > every connected device has a known origin. The management includes > verifying the presence of the expected devices and detecting the > presence of unwanted devices. > > Examples of functions performed by such controllers are regulating > the quality, humidity, and temperature of the air inside the building > and lighting. Other systems may report the status of the machinery > inside the building like elevators, or inside the rooms like > projectors in meeting rooms. Security cameras and sensors may be > deployed and operated on separate dedicated infrastructures connected > to the common backbone. The deployment area of a BAS is typically > inside one building (or part of it) or several buildings > geographically grouped in a campus. A building network can be > composed of network segments, where a network segment covers a floor, > an area on the floor, or a given functionality (e.g., security > cameras). > > Some of the sensors in Building Automation Systems (for example fire > alarms or security systems) register, record and transfer critical > alarm information and therefore must be resilient to events like loss > of power or security attacks. This leads to the need to certify > components and subsystems operating in such constrained conditions > based on specific requirements. Also in some environments, the > malfunctioning of a control system (like temperature control) needs > to be reported in the shortest possible time. Complex control > systems can misbehave, and their critical status reporting and safety > > > > > Ersue, et al. Expires January 5, 2015 [Page 12] > Internet-Draft Constrained Management: Use Cases July 2014 > > > algorithms need to be basic and robust and perform even in critical > conditions. > > Building Automation solutions are deployed in some cases in newly > designed buildings, in other cases it might be over existing > infrastructures. In the first case, there is a broader range of > possible solutions, which can be planned for the infrastructure of > the building. In the second case the solution needs to be deployed > over an existing infrastructure taking into account factors like > existing wiring, distance limitations, the propagation of radio > signals over walls and floors, thereby making deployment difficult. > As a result, some of the existing WLAN solutions (e.g., IEEE 802.11 > or IEEE 802.15) may be deployed. In mission-critical or security > sensitive environments and in cases where link failures happen often, > topologies that allow for reconfiguration of the network and > connection continuity may be required. Some of the sensors deployed > in building automation may be very simple constrained devices for > which class 0 or class 1 may be assumed. > > TW> you use "C1" and "C0" above. Please homogenize. > > For lighting applications, groups of lights must be defined and > managed. Commands to a group of light must arrive within 200 ms at > all destinations. The installation and operation of a building > network has different requirements. During the installation, many > stand-alone networks of a few to 100 nodes co-exist without a > connection to the backbone. During this phase, the nodes are > identified with a network identifier related to their physical > location. Devices are accessed from an installation tool to connect > them to the network in a secure fashion. During installation, the > setting of parameters of common values to enable interoperability may > be required. During operation, the networks are connected to the > backbone while maintaining the network identifier to physical > location relation. Network parameters like address and name are > stored in DNS. The names can assist in determining the physical > location of the device. > > 3.7. Home Automation > > Home automation includes the control of lighting, heating, > ventilation, air conditioning, appliances, entertainment and home > TW> The word "security" appears twice > security devices to improve convenience, comfort, energy efficiency, > and security. It can be seen as a residential extension of building > automation. However, unlike a building automation system, the > infrastructure in a home is operated in a considerably more ad-hoc > manner. While in some installations it is likely that there is no > centralized management system, akin to a Building Automation System > (BAS), available, in other situations outsourced and cloud based > systems responsible for managing devices in the home might be used. > > > > > Ersue, et al. Expires January 5, 2015 [Page 13] > Internet-Draft Constrained Management: Use Cases July 2014 > > > Home automation networks need a certain amount of configuration > TW> actors -> actuators ? > (associating switches or sensors to actors) that is either provided > by electricians deploying home automation solutions, by third party > home automation service providers (e.g., small specialized companies > or home automation device manufacturers) or by residents by using the > application user interface provided by home automation devices to > configure (parts of) the home automation solution. Similarly, > failures may be reported via suitable interfaces to residents or they > might be recorded and made available to services providers in charge > of the maintenance of the home automation infrastructure. > > The management responsibility lies either with the residents or it > may be outsourced to electricians and/or third parties providing > management of home automation solutions as a service. A varying > combination of electricians, service providers or the residents may > be responsible for different aspects of managing the infrastructure. > The time scale for failure detection and resolution is in many cases > likely counted in hours to days. > > 3.8. Transport Applications > > Transport Application is a generic term for the integrated > application of communications, control, and information processing in > a transportation system. Transport telematics or vehicle telematics > are used as a term for the group of technologies that support > transportation systems. Transport applications running on such a > transportation system cover all modes of the transport and consider > all elements of the transportation system, i.e. the vehicle, the > infrastructure, and the driver or user, interacting together > dynamically. Examples for transport applications are inter and intra > vehicular communication, smart traffic control, smart parking, > electronic toll collection systems, logistic and fleet management, > vehicle control, and safety and road assistance. > > As a distributed system, transport applications require an end-to-end > management of different types of networks. It is likely that > constrained devices in a network (e.g. a moving in-car network) have > to be controlled by an application running on an application server > in the network of a service provider. Such a highly distributed > network including cellular devices on vehicles is assumed to include > a wireless access network using diverse long distance wireless > technologies such as WiMAX, 3G/LTE or satellite communication, e.g. > based on an embedded hardware module. As a result, the management of > constrained devices in the transport system might be necessary to > plan top-down and might need to use data models obliged from and > defined on the application layer. The assumed device classes in use > are mainly C2 devices. In cases, where an in-vehicle network is > involved, C1 devices with limited capabilities and a short-distance > > > > Ersue, et al. Expires January 5, 2015 [Page 14] > Internet-Draft Constrained Management: Use Cases July 2014 > > > constrained radio network, e.g. IEEE 802.15.4 might be used > additionally. > > All Transport Applications will require an IT infrastructure to run > on top of, e.g., in public transport scenarios like trains, bus or > metro network infrastructure might be provided, maintained and > operated by third parties like mobile network or satellite network > operators. However, the management responsibility of the transport > application typically rests within the organization running the > transport application (in the public transport scenario, this would > typically be the public transport operator). Different aspects of > the infrastructure might also be managed by different entities. For > example, the in-car devices are likely to be installed and managed by > the manufacturer, while the public works might be responsible for the > on-road vehicular communication infrastructure used by these devices. > The back-end infrastructure is also likely to be maintained by third > party operators. As such, the NMS must be able to deal with > different network segments, each being operated and controlled by > separate entities, and enable appropriate access control and security > as well. > > Depending on the type of application domain (vehicular or stationary) > and service being provided, it would be important for the NMS to be > able to function with different architectures, since different > manufacturers might have their own proprietary systems relying on a > specific Management Topology Option, as described in [COM-REQ]. > Moreover, constituents of the network can be either private, > belonging to individuals or private companies, or owned by public > institutions leading to different legal and organization > requirements. Across the entire infrastructure, a variety of > constrained devices are likely to be used, and must be individually > managed. The NMS must be able to either work directly with different > types of devices, or have the ability to interoperate with multiple > different systems. > > The challenges in the management of vehicles in a mobile transport > application are manifold. The up-to-date position of each node in > the network should be reported to the corresponding management > entities, since the nodes could be moving within or roaming between > different networks. Secondly, a variety of troubleshooting > information, including sensitive location information, needs to be > reported to the management system in order to provide accurate > service to the customer. Management systems dealing with mobile > nodes could possibly exploit specific patterns in the mobility of the > nodes. These patterns emerge due to repetitive vehicular usage in > scenarios like people commuting to work, logistics supply vehicles > transporting shipments between warehouses and etc. The NMS must also > be able to handle partitioned networks, which would arise due to the > > > > Ersue, et al. Expires January 5, 2015 [Page 15] > Internet-Draft Constrained Management: Use Cases July 2014 > > > dynamic nature of traffic resulting in large inter-vehicle gaps in > sparsely populated scenarios. Since mobile nodes might roam in > remote networks, the NMS should be able to provide operating > configuration updates regardless of node location. > > The constrained devices in a moving transport network might be > initially configured in a factory and a reconfiguration might be > needed only rarely. New devices might be integrated in an ad-hoc > manner based on self-management and -configuration capabilities. > Monitoring and data exchange might be necessary to do via a gateway > entity connected to the back-end transport infrastructure. The > devices and entities in the transport infrastructure need to be > monitored more frequently and can be able to communicate with a > higher data rate. The connectivity of such entities does not > necessarily need to be wireless. The time scale for detecting and > recording failures in a moving transport network is likely measured > in hours and repairs might easily take days. It is likely that a > self-healing feature would be used locally. On the other hand, > failures in fixed transport application infrastructure (e.g., > traffic-lights, digital signage displays) is likely to be measured in > minutes so as to avoid untoward traffic incidents. As such, the NMS > must be able to deal with differing timeliness requirements based on > the type of devices. > > 3.9. Community Network Applications > > Community networks are comprised of constrained routers in a multi- > hop mesh topology, communicating over a lossy, and often wireless > TW> typo: channel*s* > channel. While the routers are mostly non-mobile, the topology may > be very dynamic because of fluctuations in link quality of the > (wireless) channel caused by, e.g., obstacles, or other nearby radio > transmissions. Depending on the routers that are used in the > community network, the resources of the routers (memory, CPU) may be > more or less constrained - available resources may range from only a > few kilobytes of RAM to several megabytes or more, and CPUs may be > small and embedded, or more powerful general-purpose processors. > Examples of such community networks are the FunkFeuer network > (Vienna, Austria), FreiFunk (Berlin, Germany), Seattle Wireless > (Seattle, USA), and AWMN (Athens, Greece). These community networks > are public and non-regulated, allowing their users to connect to each > other and - through an uplink to an ISP - to the Internet. No fee, > other than the initial purchase of a wireless router, is charged for > these services. Applications of these community networks can be > diverse, e.g., location based services, free Internet access, file > sharing between users, distributed chat services, social networking > etc, video sharing etc. > > TW> One "etc" too many above. > > > > > Ersue, et al. Expires January 5, 2015 [Page 16] > Internet-Draft Constrained Management: Use Cases July 2014 > > > As an example of a community network, the FunkFeuer network comprises > several hundred routers, many of which have several radio interfaces > (with omnidirectional and some directed antennas). The routers of > the network are small-sized wireless routers, such as the Linksys > WRT54GL, available in 2011 for less than 50 Euros. These routers, > with 16 MB of RAM and 264 MHz of CPU power, are mounted on the > rooftops of the users. When new users want to connect to the > network, they acquire a wireless router, install the appropriate > firmware and routing protocol, and mount the router on the rooftop. > IP addresses for the router are assigned manually from a list of > addresses (because of the lack of autoconfiguration standards for > TW> autoconfiguration -> auto-configuration? > mesh networks in the IETF). > > While the routers are non-mobile, fluctuations in link quality > require an ad hoc routing protocol that allows for quick convergence > to reflect the effective topology of the network (such as NHDP > [RFC6130] and OLSRv2 [RFC7181] developed in the MANET WG). Usually, > no human interaction is required for these protocols, as all variable > parameters required by the routing protocol are either negotiated in > the control traffic exchange, or are only of local importance to each > router (i.e. do not influence interoperability). However, external > management and monitoring of an ad hoc routing protocol may be > desirable to optimize parameters of the routing protocol. Such an > optimization may lead to a more stable perceived topology and to a > lower control traffic overhead, and therefore to a higher delivery > success ratio of data packets, a lower end-to-end delay, and less > unnecessary bandwidth and energy usage. > > Different use cases for the management of community networks are > possible: > > o One single Network Management Station, e.g. a border gateway > providing connectivity to the Internet, requires managing or > monitoring routers in the community network, in order to > investigate problems (monitoring) or to improve performance by > changing parameters (managing). As the topology of the network is > dynamic, constant connectivity of each router towards the > management station cannot be guaranteed. Current network > TW> Netconf -> NETCONF (see RFC4741) > management protocols, such as SNMP and Netconf, may be used (e.g., > using interfaces such as the NHDP-MIB [RFC6779]). However, when > routers in the community network are constrained, existing > protocols may require too many resources in terms of memory and > CPU; and more importantly, the bandwidth requirements may exceed > the available channel capacity in wireless mesh networks. > Moreover, management and monitoring may be unfeasible if the > connection between the network management station and the routers > is frequently interrupted. > > > > > Ersue, et al. Expires January 5, 2015 [Page 17] > Internet-Draft Constrained Management: Use Cases July 2014 > > > TW> I would remove "A" > o A distributed network monitoring, in which more than one > management station monitors or manages other routers. Because > connectivity to a server cannot be guaranteed at all times, a > distributed approach may provide a higher reliability, at the cost > of increased complexity. Currently, no IETF standard exists for > distributed monitoring and management. > > o Monitoring and management of a whole network or a group of > routers. Monitoring the performance of a community network may > require more information than what can be acquired from a single > router using a network management protocol. Statistics, such as > topology changes over time, data throughput along certain routing > paths, congestion etc., are of interest for a group of routers (or > TW> update to 2014? > the routing domain) as a whole. As of 2012, no IETF standard > allows for monitoring or managing whole networks, instead of > single routers. > > 3.10. Field Operations > > The challenges of configuration and monitoring of networks operated > in the field by rescue and security agencies can be different from > the other use cases since the requirements and operating conditions > of such networks are quite different. > > TW> typo: becomeing -> becoming > > With technology advancements, field networks operated nowadays are > becomeing large and can consist of varieties of different types of > equipment that run different protocols and tools that obviously > TW> "mission-critical"? > increase complexity of these mission critical networks. In many > scenarios, configurations are, most likely, manually performed. > Furthermore, some legacy and even modern devices do not even support > TW> "*A* majority"? > TW> proprietary*,* which > IP networking. Majority of protocols and tools developed by vendors > that are being used are proprietary which makes integration more > difficult. > > The main reason for this disjoint operation scenario is that most > equipment is developed with specific task requirements in mind, > rather than interoperability of the varied equipment types. For > example, the operating conditions experienced by high altitude > security equipment is significantly different from that used in > desert conditions. Similarly, search and rescue operations equipment > used in case of fire rescue has different requirements than flood > TW> "inter-operation"? > relief equipment. Furthermore, interoperation of equipment with > telecommunication equipment was not an expected outcome or in some > scenarios this may not even be desirable. > > Currently, field networks operate with a fixed Network Operations > Center (NOC) that physically manages the configuration and evaluation > of all field devices. Once configured, the devices might be deployed > > > > Ersue, et al. Expires January 5, 2015 [Page 18] > Internet-Draft Constrained Management: Use Cases July 2014 > > > in fixed or mobile scenarios. Any configuration changes required > would need to be appropriately encrypted and authenticated to prevent > unauthorized access. > > Hierarchical management of devices is a common requirement in such > scenarios since local managers or operators may need to respond to > changing conditions within their purview. The level of configuration > management available at each hierarchy must also be closely governed. > > Since many field operation devices are used in hostile environments, > a high failure and disconnection rate should be tolerated by the NMS, > which must also be able to deal with multiple gateways and disjoint > management protocols. > > TW> typo: invloving > TW> requiring the interoperation -> requiring inter-operation? > > Multi-national field operations invloving search, rescue and security > are becoming increasingly common, requiring the interoperation of a > diverse set of equipment designed with different operating conditions > in mind. Furthermore, different intra- and inter-governmental > agencies are likely to have a different set of standards, best > practices, rules and regulation, and implementation approaches that > may contradict or conflict with each other. The NMS should be able > to detect these and handle them in an acceptable manner, which may > require human intervention. > > 4. IANA Considerations > > This document does not introduce any new code-points or namespaces > for registration with IANA. > > Note to RFC Editor: this section may be removed on publication as an > RFC. > > 5. Security Considerations > > This document discusses use cases for Management of Networks with > Constrained Devices. The security considerations described > throughout the companion document [COM-REQ] apply here as well. > > 6. Contributors > > Following persons made significant contributions to and reviewed this > document: > > o Ulrich Herberg (Fujitsu Laboratories of America) contributed the > Section 3.9 on Community Network Applications. > > o Peter van der Stok contributed to Section 3.6 on Building > Automation. > > > > Ersue, et al. Expires January 5, 2015 [Page 19] > Internet-Draft Constrained Management: Use Cases July 2014 > > > o Zhen Cao contributed to Section 2.2 Cellular Access Technologies. > > o Gilman Tolle contributed the Section 3.4 on Automated Metering > Infrastructure. > > o James Nguyen and Ulrich Herberg contributed to Section 3.10 on > Military operations. > > 7. Acknowledgments > > Following persons reviewed and provided valuable comments to > different versions of this document: > > Dominique Barthel, Carsten Bormann, Zhen Cao, Benoit Claise, Bert > Greevenbosch, Ulrich Herberg, James Nguyen, Zach Shelby, and Peter > van der Stok. > > The editors would like to thank the reviewers and the participants on > the Coman maillist for their valuable contributions and comments. > > 8. Informative References > > [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc > Network (MANET) Neighborhood Discovery Protocol (NHDP)", > RFC 6130, April 2011. > > [RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and > Application Spaces for IPv6 over Low-Power Wireless > Personal Area Networks (6LoWPANs)", RFC 6568, April 2012. > > [RFC6779] Herberg, U., Cole, R., and I. Chakeres, "Definition of > Managed Objects for the Neighborhood Discovery Protocol", > RFC 6779, October 2012. > > [RFC6988] Quittek, J., Chandramouli, M., Winter, R., Dietz, T., and > B. Claise, "Requirements for Energy Management", RFC 6988, > September 2013. > > [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, > "The Optimized Link State Routing Protocol Version 2", RFC > 7181, April 2014. > > [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for > Constrained-Node Networks", RFC 7228, May 2014. > > > > > > > > Ersue, et al. Expires January 5, 2015 [Page 20] > Internet-Draft Constrained Management: Use Cases July 2014 > > > [I-D.ietf-eman-framework] > Claise, B., Schoening, B., and J. Quittek, "Energy > Management Framework", draft-ietf-eman-framework-19 (work > in progress), April 2014. > > [COM-REQ] Ersue, M., Romascanu, D., and J. Schoenwaelder, > "Management of Networks with Constrained Devices: Problem > Statement and Requirements", draft-ietf-opsawg-coman- > probstate-reqs (work in progress), February 2014. > > Appendix A. Change Log > > A.1. draft-ietf-opsawg-coman-use-cases-01 - draft-ietf-opsawg-coman- > use-cases-02 > > o Renamed Mobile Access Technologies section to Cellular Access > Technologies > > o Changed references to mobile access technologies to now read > cellular access technologies. > > o Added text to the introduction to point out that the list of use > cases is not exhaustive since others unknown to the authors might > exist. > > o Updated references to take into account RFCs that have been now > published. > > o Updated Environmental Monitoring section to make it clear that in > some scenarios it may not be prudent to repair devices. > > o Added clarification in Infrastructure Monitoring section that > reliable communication is achieved via application layer > transactions > > o Removed reference to Energy Devices from Energy Management > section, instead labeling them as devices within the context of > energy management. > > o Reduced descriptive content in Energy Management section. > > o Rewrote text in Energy Management section to highlight management > characteristics of Smart Meter and AMI networks. > > o Added text regarding timely delivery of information, and related > management system characteristic, to the Medical Applications > section > > > > > Ersue, et al. Expires January 5, 2015 [Page 21] > Internet-Draft Constrained Management: Use Cases July 2014 > > > o Changed subnets to network segment in Building Automation section. > > o Changed structure to infrastructure in Building Automation > section, and added text to highlight associated deployment > difficulties. > > o Removed Trickle timer as example of common values to be set in > Building Automation section. > > o Added text regarding the possible availability of outsourced and > cloud based management systems for Home Automation. > > o Added text to Transport Applications section to highlight the > requirement of IT infrastructure for such applications to function > on top of. > > o Merged the Transport Applications and Vehicular Networks section > together. Following changes to the Vehicular Networks section > were merged back into Transport Applications > > * Replaced wireless last hops with wireless access to vehicles in > Vehicular Networks. > > * Expanded proprietary systems to "systems relying on a specific > Management Topology Option, as described in [COM-REQ]." within > Vehicular Networks section. > > * Added text regarding mobility patterns to Vehicular Networks. > > o Changed the Military Operations use case to Field Operations and > edited the text to be suitable to such scenarios. > > A.2. draft-ietf-opsawg-coman-use-cases-00 - draft-ietf-opsawg-coman- > use-cases-01 > > o Reordered some use cases to improve the flow. > > o Added "Vehicular Networks". > > o Shortened the Military Operations use case. > > o Started adding substance to the security considerations section. > > > > > > > > > > Ersue, et al. Expires January 5, 2015 [Page 22] > Internet-Draft Constrained Management: Use Cases July 2014 > > > A.3. draft-ersue-constrained-mgmt-03 - draft-ersue-opsawg-coman-use- > cases-00 > > o Reduced the terminology section for terminology addressed in the > LWIG and Coman Requirements drafts. Referenced the other drafts. > > o Checked and aligned all terminology against the LWIG terminology > draft. > > o Spent some effort to resolve the intersection between the > Industrial Application, Home Automation and Building Automation > use cases. > > o Moved section section 3. Use Cases from the companion document > [COM-REQ] to this draft. > > o Reformulation of some text parts for more clarity. > > A.4. draft-ersue-constrained-mgmt-02-03 > > o Extended the terminology section and removed some of the > terminology addressed in the new LWIG terminology draft. > Referenced the LWIG terminology draft. > > o Moved Section 1.3. on Constrained Device Classes to the new LWIG > terminology draft. > > o Class of networks considering the different type of radio and > communication technologies in use and dimensions extended. > > o Extended the Problem Statement in Section 2. following the > requirements listed in Section 4. > > o Following requirements, which belong together and can be realized > with similar or same kind of solutions, have been merged. > > * Distributed Management and Peer Configuration, > > * Device status monitoring and Neighbor-monitoring, > > * Passive Monitoring and Reactive Monitoring, > > * Event-driven self-management - Self-healing and Periodic self- > management, > > * Authentication of management systems and Authentication of > managed devices, > > > > > Ersue, et al. Expires January 5, 2015 [Page 23] > Internet-Draft Constrained Management: Use Cases July 2014 > > > * Access control on devices and Access control on management > systems, > > * Management of Energy Resources and Data models for energy > management, > > * Software distribution (group-based firmware update) and Group- > based provisioning. > > o Deleted the empty section on the gaps in network management > standards, as it will be written in a separate draft. > > o Added links to mentioned external pages. > > o Added text on OMA M2M Device Classification in appendix. > > A.5. draft-ersue-constrained-mgmt-01-02 > > o Extended the terminology section. > > o Added additional text for the use cases concerning deployment > type, network topology in use, network size, network capabilities, > radio technology, etc. > > o Added examples for device classes in a use case. > > o Added additional text provided by Cao Zhen (China Mobile) for > Mobile Applications and by Peter van der Stok for Building > Automation. > > o Added the new use cases 'Advanced Metering Infrastructure' and > 'MANET Concept of Operations in Military'. > > o Added the section 'Managing the Constrainedness of a Device or > Network' discussing the needs of very constrained devices. > > o Added a note that the requirements in [COM-REQ] need to be seen as > standalone requirements and the current document does not > recommend any profile of requirements. > > o Added a section in [COM-REQ] for the detailed requirements on > constrained management matched to management tasks like fault, > monitoring, configuration management, Security and Access Control, > Energy Management, etc. > > o Solved nits and added references. > > o Added Appendix A on the related development in other bodies. > > > > Ersue, et al. Expires January 5, 2015 [Page 24] > Internet-Draft Constrained Management: Use Cases July 2014 > > > o Added Appendix B on the work in related research projects. > > A.6. draft-ersue-constrained-mgmt-00-01 > > o Splitted the section on 'Networks of Constrained Devices' into the > sections 'Network Topology Options' and 'Management Topology > Options'. > > o Added the use case 'Community Network Applications' and 'Mobile > Applications'. > > o Provided a Contributors section. > > o Extended the section on 'Medical Applications'. > > o Solved nits and added references. > > Authors' Addresses > > Mehmet Ersue (editor) > Nokia Networks > > Email: mehmet.ersue@nsn.com > > > Dan Romascanu > Avaya > > Email: dromasca@avaya.com > > > Juergen Schoenwaelder > Jacobs University Bremen > > Email: j.schoenwaelder@jacobs-university.de > > > Anuj Sehgal > Jacobs University Bremen > > Email: s.anuj@jacobs-university.de > > > > > > > > > > > Ersue, et al. Expires January 5, 2015 [Page 25] > > --089e0103ed82a4fcc505004e8335 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[resend'ing CC'ing 6TiSCH ML]


On Fri, Aug 8, 2014 at 11:29= PM, Thomas Watteyne <watteyne@eecs.berkeley.edu> w= rote:
I was asked to do a de= tailed review of=C2=A0draft-ietf-opsawg-coman-use-cases-02.
<= br>
Constrained management is important for the 6TiSCH WG. I am really hap= py to see that the COMAN work has been able to progress in OPSAWG. I wasn&#= 39;t aware of the progress on this document in OPS until IETF90 (my fault..= .); but have since announced it to the 6TiSCH WG.

The 6TiSCH architecture supports a mode in which a cent= ral entity manages the communication schedule of the nodes. Typically, the = node form a constrained network (very little bandwidth, energy constraints,= etc), and the (possible less constrained) management entity sits on the ed= ge of that network. This management entity need to (1) set a number of para= meters on the motes and (2) monitor some statistics to possibly trigger som= e action. Nothing particularly surprising, indeed.

So far, we have been defined our own "home brew&qu= ot; management protocol on top of CoAP (draft-ietf-6tisch-coap-01). There i= s really nothing specific to 6TiSCH in that solution, and we'd love to = be able to reuse any more generic management solution for constrained envir= onments. Ideally, this management solution would be shared by other softwar= e pieces running on the constrained device, e.g. the 6LoWPAN layer.

I am also reading draft-ietf-opsawg-coman-probstate-req= s-02, the review of which I will send in a separate e-mail to keep things c= lean.

Thomas

GENERAL<= /div>
--------------

The different sections are ver= y "independent", and the draft would benefit from some text at th= e beginning which would glue those together. Ideas are:
- enforce= the same structure for each use case section, possibly by grouping the par= agraphs under a title, e.g. "description of the use case", "= expectation from management solution", etc.
- add a table/list at the beginning which summarizes the different fea= tures one can expect from a management system, for each of the use cases (e= .g. "privacy" in=C2=A0Medical Applications). This would give the = reader a one-page overview, allowing him/her to more easily go back to the = text.

In some use cases, while the use case is very clearly d= escribed, it's hard to see what the use case is *for the management*. T= his is particularly true in "Building Automation", and somewhat i= n "Industrial Applications".

It might be interesting, for each use case, to describe= how the management changes over the lifetime of the system. For example, s= ome security aspect (authentication, authorization) only exist during commi= ssioning.

It would be good, although maybe hard, to have common m= etrics across all uses cases, allowing for an easier comparison. For exampl= e, the approx. amount of management data, generation rate of this managemen= t data (and associated size).

It would be good to order the use cases logically, and = highlight in the intro text what the extremes are. For example (and I'm= making this up), management in the Field Operations use cases involves the= most frequent exchange of data, and hence a large overhead, than a=C2=A0Ho= me Automation application in which most management is done during commissio= ning.

DETAILED
---------------

=
please find my comments below, prefixed by "^TW>"


Internet Engineering Task Force =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0M. Ersue, Ed.
Internet-Draft =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0No= kia Networks
Intended status: Informational = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0D. Romascanu
Expires: January 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Avaya
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 J. Schoenwaelder
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0A. Sehgal
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jacobs Unive= rsity Bremen
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 July 4, 2014=


=C2=A0 =C2=A0 =C2=A0 =C2=A0Management of Networks with Constra= ined Devices: Use Cases
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-opsawg-coman-use-cases-02=

Abstract

=C2=A0 =C2=A0This document discusses use cases = concerning the management of
=C2=A0 =C2=A0networks, where constrained devices are involved. =C2= =A0A problem
=C2=A0 =C2=A0statement, deployme= nt options and the requirements on the networks
=C2=A0 =C2=A0with constrained devices can be fo= und in the companion document on
=C2=A0 =C2=A0"Management of= Networks with Constrained Devices: Problem Statement
=C2=A0 =C2=A0and Requirements".

Status of This Memo=

=C2=A0 =C2=A0This Internet-Draft i= s submitted in full conformance with the
=C2=A0 =C2=A0provisions of BCP 7= 8 and BCP 79.

=C2=A0 =C2=A0Internet= -Drafts are working documents of the Internet Engineering
=C2=A0 =C2=A0Task Force (IETF). = =C2=A0Note that other groups may also distribute
=C2=A0 =C2=A0working documents as Internet-Dra= fts. =C2=A0The list of current Internet-

=C2=A0 =C2=A0Internet-Drafts are= draft documents valid for a maximum of six months
=C2=A0 =C2=A0and may be updated, replaced, o= r obsoleted by other documents at any
=C2=A0 =C2=A0time. =C2=A0It is i= nappropriate to use Internet-Drafts as reference
=C2=A0 =C2=A0material or to cite them other th= an as "work in progress."

=C2=A0 =C2=A0This Internet-Draft will expire on= January 5, 2015.
Copyright Notice

=C2=A0 =C2=A0Copyright (c) 2014 IETF Trust and the= persons identified as the
=C2=A0 =C2=A0document authors. = =C2=A0All rights reserved.

=C2=A0 = =C2=A0This document is subject to BCP 78 and the IETF Trust's Legal
=C2=A0 =C2=A0Provisions Relating= to IETF Documents
= =C2=A0 =C2=A0(http://trustee.ietf.org/license-info) in effect on the date of
=C2=A0 =C2=A0publication of this= document. =C2=A0Please review these documents



Ersue, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0[Page 1]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0Constrained Management:= Use Cases =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0July 2014


=C2=A0 =C2=A0carefully, as they describe your rights and restr= ictions with respect
=C2=A0 =C2=A0to this document. = =C2=A0Code Components extracted from this document must
=C2=A0 =C2=A0include Simplified BSD Lic= ense text as described in Section 4.e of
=C2=A0 =C2=A0the Trust Legal Pro= visions and are provided without warranty as
=C2=A0 =C2=A0described in the Simplified BSD Licen= se.

Table of Contents

=C2=A0 =C2=A01. =C2=A0Introduction =C2=A0. . . . . . . . . . . . . . = . . . . . . . . . . =C2=A0 2
=C2=A0 =C2=A02. =C2=A0Access Tec= hnologies . . . . . . . . . . . . . . . . . . . . . =C2=A0 4
=C2=A0 =C2=A0 =C2=A02.1. =C2=A0Con= strained Access Technologies . . . . . . . . . . . . . =C2=A0 4
=C2=A0 =C2=A0 =C2=A02.2. =C2=A0C= ellular Access Technologies =C2=A0. . . . . . . . . . . . . . =C2=A0 4
=C2=A0 =C2=A03. =C2=A0Us= e Cases . . . . . . . . . . . . . . . . . . . . . . . . . . =C2=A0 5=
=C2=A0 =C2=A0 =C2=A03.1. =C2=A0E= nvironmental Monitoring =C2=A0. . . . . . . . . . . . . . . . =C2=A0 6
=C2=A0 =C2=A0 =C2=A03.2.= =C2=A0Infrastructure Monitoring . . . . . . . . . . . . . . . . =C2=A0 6
=C2=A0 =C2=A0 =C2=A03.3. =C2=A0I= ndustrial Applications . . . . . . . . . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A0 =C2=A03.4. =C2= =A0Energy Management . . . . . . . . . . . . . . . . . . . . =C2=A0 9
=C2=A0 =C2=A0 =C2=A03.5. =C2=A0M= edical Applications =C2=A0. . . . . . . . . . . . . . . . . . =C2=A011
=C2=A0 =C2=A0 =C2=A03.6.= =C2=A0Building Automation . . . . . . . . . . . . . . . . . . . =C2=A012
=C2=A0 =C2=A0 =C2=A03.7. =C2=A0H= ome Automation . . . . . . . . . . . . . . . . . . . . . =C2=A013
=C2=A0 =C2=A0 =C2=A03.8. =C2= =A0Transport Applications =C2=A0. . . . . . . . . . . . . . . . . =C2=A014<= /font>
=C2=A0 =C2=A0 =C2=A03.9. =C2=A0C= ommunity Network Applications =C2=A0. . . . . . . . . . . . . =C2=A016
=C2=A0 =C2=A0 =C2=A03.10= . Field Operations =C2=A0. . . . . . . . . . . . . . . . . . . . =C2=A018
=C2=A0 =C2=A04. =C2=A0IANA Consi= derations . . . . . . . . . . . . . . . . . . . . . =C2=A019
=C2=A0 =C2=A05. =C2=A0Security Con= siderations . . . . . . . . . . . . . . . . . . . =C2=A019
=C2=A0 =C2=A06. =C2=A0Contributo= rs =C2=A0. . . . . . . . . . . . . . . . . . . . . . . . =C2=A019
=C2=A0 =C2=A07. =C2=A0Acknowl= edgments . . . . . . . . . . . . . . . . . . . . . . . =C2=A020
=C2=A0 =C2=A08. =C2=A0Informativ= e References =C2=A0. . . . . . . . . . . . . . . . . . . =C2=A020
=C2=A0 =C2=A0Appendix A. =C2= =A0Change Log . . . . . . . . . . . . . . . . . . . . . =C2=A021
=C2=A0 =C2=A0 =C2=A0A.1. =C2=A0d= raft-ietf-opsawg-coman-use-cases-01 - draft-ietf-opsawg-
<= font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0coman-use-cases-02 =C2=A0. . . . . . . . . . . . . . . . . . . =C2=A021<= /font>
=C2=A0 =C2=A0 =C2=A0A.2. =C2=A0d= raft-ietf-opsawg-coman-use-cases-00 - draft-ietf-opsawg-
<= font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0coman-use-cases-01 =C2=A0. . . . . . . . . . . . . . . . . . . =C2=A022<= /font>
=C2=A0 =C2=A0 =C2=A0A.3. =C2=A0d= raft-ersue-constrained-mgmt-03 - draft-ersue-opsawg-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0c= oman-use-cases-00 =C2=A0. . . . . . . . . . . . . . . . . . . =C2=A023
=C2=A0 =C2=A0 =C2=A0A.4. =C2=A0d= raft-ersue-constrained-mgmt-02-03 =C2=A0. . . . . . . . . . . =C2=A023
=C2=A0 =C2=A0 =C2=A0A.5.= =C2=A0draft-ersue-constrained-mgmt-01-02 =C2=A0. . . . . . . . . . . =C2= =A024
=C2=A0 =C2=A0 =C2=A0A.6. =C2=A0d= raft-ersue-constrained-mgmt-00-01 =C2=A0. . . . . . . . . . . =C2=A025
=C2=A0 =C2=A0Authors'= ; Addresses =C2=A0. . . . . . . . . . . . . . . . . . . . . . . =C2=A025

1. =C2=A0Introduction

=C2=A0 =C2=A0Small devices with limited CPU, memory, and pow= er resources, so
=C2=A0 =C2=A0called constrained = devices (aka. sensor, smart object, or smart
=C2=A0 =C2=A0device) can be connected to a network= . =C2=A0Such a network of constrained
=C2=A0 =C2=A0devices itself may = be constrained or challenged, e.g., with
=C2=A0 =C2=A0unreliable or lossy channels, wireless te= chnologies with limited
=C2=A0 =C2=A0bandwidth and a dyn= amic topology, needing the service of a gateway or



Ersue, et al. =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 2]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0Constraine= d Management: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0July 2014<= /div>


=C2=A0 =C2=A0proxy to connect to the Internet. =C2=A0In other = scenarios, the
=C2=A0 =C2=A0constrained devices= can be connected to a non-constrained network
=C2=A0 =C2=A0using off-the-shelf protocol stack= s. =C2=A0Constrained devices might be in
=C2=A0 =C2=A0charge of gathering= information in diverse settings including natural
=C2=A0 =C2=A0ecosystems, buildings, and fact= ories and send the information to one
=C2=A0 =C2=A0or more server stat= ions.

=C2=A0 =C2=A0Network manageme= nt is characterized by monitoring network status,
=C2=A0 =C2=A0detecting faults, a= nd inferring their causes, setting network
=C2=A0 =C2=A0parameters, and carrying out actions to= remove faults, maintain
=C2=A0 =C2=A0normal operation, a= nd improve network efficiency and application
=C2=A0 =C2=A0performance. =C2=A0The traditional= network management application
=C2=A0 =C2=A0periodically collec= ts information from a set of elements that are
=C2=A0 =C2=A0needed to manage, processes the da= ta, and presents them to the
=C2=A0 =C2=A0network management = users. =C2=A0Constrained devices, however, often have
=C2=A0 =C2=A0limited power, low transmiss= ion range, and might be unreliable
=C2=A0 =C2=A0
<= font face=3D"courier new, monospace">TW> I don't understand what you= mean by "be unreliable". Do you mean that the=C2=A0
=
TW> device itself is unreliab= le (what exactly does that mean?), or that the
TW> communication with that d= evice is unreliable?
TW> I would add that such networks most often have low capacity.=
TW> I would add that such net= works most often have high latency.
=C2=A0 =C2=A0
=C2=A0 =C2=A0They
=C2=A0 =C2=A0might also need to = work in hostile environments with advanced
=C2=A0 =C2=A0security requirements or need to be use= d in harsh environments for a
=C2=A0 =C2=A0long time without s= upervision. =C2=A0Due to such constraints, the
=C2=A0 =C2=A0management of a network with const= rained devices offers different
=C2=A0 =C2=A0type of challenges = compared to the management of a traditional IP
=C2=A0 =C2=A0network.

=C2=A0 =C2=A0This d= ocument aims to understand use cases for the management of a
=C2=A0 =C2=A0network, where constr= ained devices are involved. =C2=A0The document lists
=C2=A0 =C2=A0and discusses diver= se use cases for the management from the network
=C2=A0 =C2=A0as well as from the application p= oint of view. =C2=A0The list of discussed
=C2=A0 =C2=A0use cases is not an= exhaustive one since other scenarios, currently
=C2=A0 =C2=A0unknown to the authors, are possi= ble.

TW> Typo below, remove "are".

=C2=A0 =C2=A0are The application scenarios
=C2=A0 =C2=A0discussed aim to sh= ow where networks of constrained devices are
=C2=A0 =C2=A0expected to be deployed. =C2=A0For ea= ch application scenario, we first
=C2=A0 =C2=A0briefly describe th= e characteristics followed by a discussion on how
=C2=A0 =C2=A0network management can be provid= ed, who is likely going to be
=C2=A0 =C2=A0responsible for it,= and on which time-scale management operations are
=C2=A0 =C2=A0likely to be carried out.

=C2=A0 =C2=A0A prob= lem statement, deployment and management topology options as
=C2=A0 =C2=A0well as the requireme= nts on the networks with constrained devices can
=C2=A0 =C2=A0be found in the com= panion document [COM-REQ].

=C2=A0 = =C2=A0This documents builds on the terminology defined in [RFC7228] and
=C2=A0 =C2=A0[COM-REQ]. =C2=A0[R= FC7228] is a base document for the terminology
=C2=A0 =C2=A0concerning constrained devices and= constrained networks. =C2=A0Some use
=C2=A0 =C2=A0cases specific to I= Pv6 over Low-Power Wireless Personal Area Networks
=C2=A0 =C2=A0(6LoWPANs) can be found in [RFC= 6568].






Ersue, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires= January 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Pa= ge 3]
=0C
Internet-Draft =C2= =A0 =C2=A0 =C2=A0Constrained Management: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0July 2014
=

2. =C2=A0Access Tec= hnologies

=C2=A0 =C2=A0Besides the = management requirements imposed by the different use
=C2=A0 =C2=A0cases, the access t= echnologies used by constrained devices can impose
=C2=A0 =C2=A0restrictions and requirements u= pon the Network Management System
=C2=A0 =C2=A0(NMS) and protocol = of choice.

=C2=A0 =C2=A0It is possi= ble that some networks of constrained devices might
=C2=A0 =C2=A0utilize traditional= non-constrained access technologies for network
=C2=A0 =C2=A0access, e.g., local area networks= with plenty of capacity. =C2=A0In such
=C2=A0 =C2=A0scenarios, the cons= trainedness of the device presents special
=C2=A0 =C2=A0management restrictions and requirement= s rather than the access
=C2=A0 =C2=A0technology utilized= .

<= div>=C2=A0 =C2=A0However, in other si= tuations constrained or cellular access
=C2=A0 =C2=A0technologies might = be used for network access, thereby causing
=C2=A0 =C2=A0management restrictions and requiremen= ts to arise as a result of the
=C2=A0 =C2=A0underlying access t= echnologies.

2.1. =C2=A0Constrained= Access Technologies

=C2=A0 =C2=A0Due to resource restrictions, embe= dded devices deployed as sensors
=C2=A0 =C2=A0and actuators in the various use cases utilize lo= w-power low data-
=C2=A0 =C2=A0rate wireless acces= s technologies such as IEEE 802.15.4, DECT ULE or
=C2=A0 =C2=A0BT-LE for network connectivity.<= /font>

=C2=A0 =C2=A0In suc= h scenarios, it is important for the NMS to be aware of the
=C2=A0 =C2=A0restrictions imposed b= y these access technologies to efficiently
=C2=A0 =C2=A0manage these constr= ained devices. =C2=A0Specifically, such low-power low
=C2=A0 =C2=A0data-rate access technologie= s typically have small frame sizes. =C2=A0So
=C2=A0 =C2=A0it would be importa= nt for the NMS and management protocol of choice
=C2=A0 =C2=A0to craft packets in a way that av= oids fragmentation and reassembly of
=C2=A0 =C2=A0packets since this = can use valuable memory on constrained devices.

=C2=A0 =C2=A0Devices using such access technologies might oper= ate via a gateway
=C2=A0 =C2=A0that translates bet= ween these access technologies and more
=C2=A0 =C2=A0traditional Internet protocols. =C2=A0A hi= erarchical approach to device
=C2=A0 =C2=A0management in such = a situation might be useful, wherein the gateway
=C2=A0 =C2=A0device is in-charge of devices co= nnected to it, while the NMS
=C2=A0 =C2=A0conducts management= operations only to the gateway.

2.= 2. =C2=A0Cellular Access Technologies

=C2=A0 =C2=A0Machine to machine (M2M) services = are increasingly provided by mobile
=C2=A0 =C2=A0service providers as numerous devices, home ap= pliances, utility
=C2=A0 =C2=A0meters, cars, video= surveillance cameras, and health monitors, are
=C2=A0 =C2=A0connected with mobile broadband te= chnologies. =C2=A0Different
=C2=A0 =C2=A0applications, e.g.,= in a home appliance or in-car network, use



Ersue, et al. =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 4]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0Constraine= d Management: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0July 2014<= /div>



TW= > typo, Zigbee -> ZigBee (throughout doc)

=C2=A0 =C2=A0Bluetooth, Wi-Fi or Zigbee locally= and connect to a cellular module
=C2=A0 =C2=A0acting as a gateway between the constrained envi= ronment and the
=C2=A0 =C2=A0mobile cellular net= work.

=C2=A0 =C2=A0Such a gateway m= ight provide different options for the connectivity
=C2=A0 =C2=A0of mobile networks = and constrained devices:

TW> BT-= LE --> Bluetooth Low-Energy (BT-LE)

=C2=A0 =C2=A0o =C2=A0a smart phone with 3G/4G a= nd WLAN radio might use BT-LE to connect
=C2=A0 =C2=A0 =C2=A0 to the devices in a home area net= work,

=C2=A0 =C2=A0o =C2=A0a femtocell might be combi= ned with home gateway functionality
=C2=A0 =C2=A0 =C2=A0 acting as a low-power cellular base st= ation connecting smart
=C2=A0 =C2=A0 =C2=A0 devices to = the application server of a mobile service provider,

=C2=A0 =C2=A0o =C2=A0an embedded cellular module with LTE= radio connecting the devices
=C2=A0 =C2=A0 =C2=A0 in the car = network with the server running the telematics service,

=C2=A0 =C2=A0o =C2=A0an M2M gateway connected to the m= obile operator network supporting
=C2=A0 =C2=A0 =C2=A0 diverse IoT= connectivity technologies including ZigBee and CoAP
=C2=A0 =C2=A0 =C2=A0 over 6LoWPAN over IEE= E 802.15.4.

=C2=A0 =C2=A0Common= to all scenarios above is that they are embedded in a service
=
=C2=A0 =C2=A0and connected to a = network provided by a mobile service provider.
=C2=A0 =C2=A0Usually there is a = hierarchical deployment and management topology in
=C2=A0 =C2=A0place where different parts of = the network are managed by different
=C2=A0 =C2=A0management entities= and the count of devices to manage is high (e.g.
=C2=A0 =C2=A0many thousands). =C2=A0In genera= l, the network is comprised by manifold
=C2=A0 =C2=A0type and size of de= vices matching to different device classes. =C2=A0As
=C2=A0 =C2=A0such, the managing entity nee= ds to be prepared to manage devices with
=C2=A0 =C2=A0diverse capabilitie= s using different communication or management
=C2=A0 =C2=A0protocols. =C2=A0In case the devic= es are directly connected to a gateway
=C2=A0 =C2=A0they most likely ar= e managed by a management entity integrated with
=C2=A0 =C2=A0the gateway, which itself is part= of the Network Management System
=C2=A0 =C2=A0(NMS) run by the mo= bile operator. =C2=A0Smart phones or embedded modules
=C2=A0 =C2=A0connected to a gateway might= be themselves in charge to manage the
=C2=A0 =C2=A0devices on their le= vel. =C2=A0The initial and subsequent configuration of
=C2=A0 =C2=A0such a device is mainly bas= ed on self-configuration and is triggered
=C2=A0 =C2=A0by the device itsel= f.

=
=C2=A0 =C2=A0The gateway might b= e in charge of filtering and aggregating the data
=C2=A0 =C2=A0received from the d= evice as the information sent by the device might
=C2=A0 =C2=A0be mostly redundant.

3. =C2=A0Use Cases<= /font>







Ersue, et al. =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 5]
=0C
Internet-Draft =C2=A0 =C2=A0 = =C2=A0Constrained Management: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0J= uly 2014


3.1. =C2=A0Environmental Monitoring

=C2=A0 =C2=A0Enviro= nmental monitoring applications are characterized by the
<= font face=3D"courier new, monospace">=C2=A0 =C2=A0deployment of a number of= sensors to monitor emissions, water
=C2=A0 =C2=A0quality, or even th= e movements and habits of wildlife. =C2=A0Other
=C2=A0 =C2=A0applications in this category incl= ude earthquake or tsunami early-
=C2=A0 =C2=A0warning systems. = =C2=A0The sensors often span a large geographic area,
=C2=A0 =C2=A0they can be mobile, and they= are often difficult to replace.
=C2=A0 =C2=A0Furthermore, the se= nsors are usually not protected against tampering.

=C2=A0 =C2=A0Management of environmental monitoring applica= tions is largely
=C2=A0 =C2=A0concerned with the = monitoring whether the system is still functional
=C2=A0 =C2=A0and the roll-out of new constrai= ned devices in case the system looses
=C2=A0 =C2=A0too much of its str= ucture. =C2=A0The constrained devices themselves need
=C2=A0 =C2=A0to be able to establish conn= ectivity (auto-configuration) and they
=C2=A0 =C2=A0need to be able to = deal with events such as loosing neighbors or
=C2=A0 =C2=A0being moved to other locations.

=C2=A0 =C2=A0Manage= ment responsibility typically rests with the organization
= =C2=A0 =C2=A0running the environmenta= l monitoring application. =C2=A0Since these
=C2=A0 =C2=A0monitoring applicat= ions must be designed to tolerate a number of
=C2=A0 =C2=A0failures, the time scale for detec= ting and recording failures is for
=C2=A0 =C2=A0some of these appli= cations likely measured in hours and repairs might
=C2=A0 =C2=A0easily take days. =C2=A0In fact= , in some scenarios it might be more cost-
=C2=A0 =C2=A0and time-effective = to not repair such devices at all. =C2=A0However, for
=C2=A0 =C2=A0certain environmental monito= ring applications, much tighter time
=C2=A0 =C2=A0scales may exist an= d might be enforced by regulations (e.g.,
=C2=A0 =C2=A0monitoring of nuclear radiation).=

3.2. =C2=A0Infrastr= ucture Monitoring
=C2=A0 =C2=A0Infr= astructure monitoring is concerned with the monitoring of
=C2=A0 =C2=A0infrastructures suc= h as bridges, railway tracks, or (offshore)
=C2=A0 =C2=A0windmills. =C2=A0The primary goal is u= sually to detect any events or
=C2=A0 =C2=A0changes of the stru= ctural conditions that can impact the risk and
=C2=A0 =C2=A0safety of the infrastructure being= monitored. =C2=A0Another secondary goal
=C2=A0 =C2=A0is to schedule repa= ir and maintenance activities in a cost effective
=C2=A0 =C2=A0manner.

=C2=A0 =C2=A0The in= frastructure to monitor might be in a factory or spread over a
=
=C2=A0 =C2=A0wider area but diff= icult to access. =C2=A0As such, the network in use
=C2=A0 =C2=A0might be based on a= combination of fixed and wireless technologies,
=C2=A0 =C2=A0which use robust networking equip= ment and support reliable
=C2=A0 =C2=A0communication via a= pplication layer transactions. =C2=A0It is likely that
=C2=A0 =C2=A0constrained devices in such= a network are mainly C2
=C2=A0 =C2=A0
<= font face=3D"courier new, monospace">>TW please define "C2", a= nd provide RFC
=C2= =A0 =C2=A0
=C2=A0 =C2=A0devices and have<= /div>
=C2=A0 =C2=A0to be controll= ed centrally by an application running on a server. =C2=A0In
=C2=A0 =C2=A0case such a distribut= ed network is widely spread, the wireless
=C2=A0 =C2=A0devices might use d= iverse long-distance wireless technologies such as



Ersue, et al. =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 6]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0Constraine= d Management: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0July 2014<= /div>

TW> I don't fully understand what you me= an by "e.g. based on embedded hardware
TW> modules", in partcular the "e.g.&q= uot; part. Maybe write the idea out in a
TW> separate sentence?=

=C2=A0 =C2=A0WiMAX, or 3G/LTE, e.g. based= on embedded hardware modules. =C2=A0In cases,
=C2=A0 =C2=A0where an in-buildin= g network is involved, the network can be based on
=C2=A0 =C2=A0Ethernet or wireless technologi= es suitable for in-building usage.

=C2=A0 =C2=A0The management of infrastructure m= onitoring applications is primarily
=C2=A0 =C2=A0concerned with the monitoring of the functioni= ng of the system.
=C2=A0 =C2=A0Infrastructure moni= toring devices are typically rolled out and
=C2=A0 =C2=A0installed by dedicated experts and cha= nges are rare since the
=C2=A0 =C2=A0infrastructure itse= lf changes rarely. =C2=A0However, monitoring devices
=C2=A0 =C2=A0are often deployed in unsuper= vised environments and hence special
=C2=A0 =C2=A0attention must be g= iven to protecting the devices from being
=C2=A0 =C2=A0modified.

=C2=A0 =C2=A0Manage= ment responsibility typically rests with the organization
= =C2=A0 =C2=A0owning the infrastructur= e or responsible for its operation. =C2=A0The time
=C2=A0 =C2=A0scale for detecting= and recording failures is likely measured in
=C2=A0 =C2=A0hours and repairs might easily tak= e days. =C2=A0However, certain events
=C2=A0 =C2=A0(e.g., natural disa= sters) may require that status information be
=C2=A0 =C2=A0obtained much more quickly and tha= t replacements of failed sensors
=C2=A0 =C2=A0can be rolled out q= uickly (or redundant sensors are activated
=C2=A0 =C2=A0quickly). =C2=A0In case the devices are= difficult to access, a self-
=C2=A0 =C2=A0healing feature on = the device might become necessary.

= 3.3. =C2=A0Industrial Applications

=C2=A0 =C2=A0Industrial Applications and smart = manufacturing refer to tasks such
=C2=A0 =C2=A0as networked control and monitoring of manufactu= ring equipment, asset
=C2=A0 =C2=A0and situation manag= ement, or manufacturing process control. =C2=A0For the
=C2=A0 =C2=A0management of a factory it = is becoming essential to implement smart
=C2=A0 =C2=A0capabilities. =C2= =A0From an engineering standpoint, industrial
=C2=A0 =C2=A0applications are intelligent syste= ms enabling rapid manufacturing of
=C2=A0 =C2=A0new products, dynam= ic response to product demands, and real-time
=C2=A0 =C2=A0optimization of manufacturing prod= uction and supply chain networks.
=C2=A0 =C2=A0Potential industria= l applications (e.g., for smart factories and
=C2=A0 =C2=A0smart manufacturing) are:

=C2=A0 =C2=A0o =C2= =A0Digital control systems with embedded, automated process controls,
=C2=A0 =C2=A0 =C2=A0 oper= ator tools, as well as service information systems optimizing
=C2=A0 =C2=A0 =C2=A0 plant opera= tions and safety.
=C2=A0 =C2=A0o = =C2=A0Asset management using predictive maintenance tools, statistical
=C2=A0 =C2=A0 =C2=A0 evaluation,= and measurements maximizing plant reliability.

=C2=A0 =C2=A0o =C2=A0Smart sensors detecting anomalies to avoi= d abnormal or
=C2=A0 =C2=A0 =C2=A0 catastrophi= c events.






Ersue, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires= January 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Pa= ge 7]
=0C
Internet-Draft =C2= =A0 =C2=A0 =C2=A0Constrained Management: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0July 2014
=

=C2=A0 =C2=A0o =C2= =A0Smart systems integrated within the industrial energy management<= /div>
=C2=A0 =C2=A0 =C2=A0 system= and externally with the smart grid enabling real-time
=C2=A0 =C2=A0 =C2=A0 energy opti= mization.

TW> I don't unders= tand what the "management" part here refers to in this
TW> section. I expect the dra= ft to deal exclusively with the management needs
TW> for the constrained network (e.g. monit= oring 6LoWPAN counters). This
TW> section seems to deal wit= h the management of a smart plant.

= =C2=A0 =C2=A0Management of Industrial Applications and smart manufacturing = may in
=C2=A0 =C2=A0some situations inv= olve Building Automation tasks such as control of
=C2=A0 =C2=A0energy, HVAC (heating, ventilati= on, and air conditioning), lighting,
=C2=A0 =C2=A0or access control. = =C2=A0Interacting with management systems from other
=C2=A0 =C2=A0application areas might be im= portant in some cases (e.g.,
=C2=A0 =C2=A0environmental monit= oring for electric energy production, energy
=C2=A0 =C2=A0management for dynamically scaling ma= nufacturing, vehicular networks
=C2=A0 =C2=A0for mobile asset tr= acking).

=
=C2=A0 =C2=A0Sensor networ= ks are an essential technology used for smart
=C2=A0 =C2=A0manufacturing. =C2= =A0Measurements, automated controls, plant optimization,
<= font face=3D"courier new, monospace">=C2=A0 =C2=A0health and safety managem= ent, and other functions are provided by a
=C2=A0 =C2=A0large number of net= worked sectors. =C2=A0Data interoperability and
=C2=A0 =C2=A0seamless exchange of product, proc= ess, and project data are enabled
=C2=A0 =C2=A0through interoperab= le data systems used by collaborating divisions or
=C2=A0 =C2=A0business systems. =C2=A0Intelli= gent automation and learning systems are
=C2=A0 =C2=A0vital to smart manu= facturing but must be effectively integrated with
=C2=A0 =C2=A0the decision environment. =C2=A0= Wireless sensor networks (WSN) have been
=C2=A0 =C2=A0developed for machi= nery Condition-based Maintenance (CBM) as they
=C2=A0 =C2=A0offer significant cost savings and= enable new functionalities.
=C2=A0 =C2=A0Inaccessible locati= ons, rotating machinery, hazardous areas, and
=C2=A0 =C2=A0mobile assets can be reached with = wireless sensors. =C2=A0WSNs can provide
=C2=A0 =C2=A0today wireless link= reliability, real-time capabilities, and quality-
=C2=A0 =C2=A0of-service and enable industria= l and related wireless sense and
=C2=A0 =C2=A0control application= s.

=
=C2=A0 =C2=A0Management of indus= trial and factory applications is largely focused
=C2=A0 =C2=A0on the monitoring w= hether the system is still functional, real-time
=C2=A0 =C2=A0continuous performance monitoring= , and optimization as necessary.
=C2=A0 =C2=A0The factory network= might be part of a campus network or connected to
=C2=A0 =C2=A0the Internet. =C2=A0The constra= ined devices in such a network need to be
=C2=A0 =C2=A0able to establish c= onfiguration themselves (auto-configuration) and
=C2=A0 =C2=A0might need to deal with error con= ditions as much as possible locally.
=C2=A0 =C2=A0Access control has = to be provided with multi-level administrative
=C2=A0 =C2=A0access and security. =C2=A0Support= and diagnostics can be provided through
=C2=A0 =C2=A0remote monitoring a= ccess centralized outside of the factory.

=C2=A0 =C2=A0Management responsibility is typically owned by the org= anization
=C2=A0 =C2=A0running the industr= ial application. =C2=A0Since the monitoring
=C2=A0 =C2=A0applications must handle a potentially= large number of failures, the
=C2=A0 =C2=A0time scale for dete= cting and recording failures is for some of these
=C2=A0 =C2=A0applications likely measured in = minutes. =C2=A0However, for certain
=C2=A0 =C2=A0industrial applicat= ions, much tighter time scales may exist, e.g. in




Ersue, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0[Page 8]
=0C
Internet-Draft =C2= =A0 =C2=A0 =C2=A0Constrained Management: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0July 2014
=

=C2=A0 =C2=A0real-t= ime, which might be enforced by the manufacturing process or
=C2=A0 =C2=A0the use of critical m= aterial.

3.4. =C2=A0Energy Management
<= font face=3D"courier new, monospace">
=C2=A0 =C2=A0The EMAN working group developed an ener= gy management framework
=C2=A0 =C2=A0[I-D.ietf-eman-fram= ework] for devices and device components within or
=C2=A0 =C2=A0connected to communication netw= orks. =C2=A0This document observes that one
=C2=A0 =C2=A0of the challenges o= f energy management is that a power distribution
=C2=A0 =C2=A0network is responsible for the su= pply of energy to various devices
=C2=A0 =C2=A0and components, whi= le a separate communication network is typically
=C2=A0 =C2=A0used to monitor and control the p= ower distribution network. =C2=A0Devices
=C2=A0 =C2=A0in the context of e= nergy management can be monitored for parameters
=C2=A0 =C2=A0like Power, Energy, Demand and Po= wer Quality. =C2=A0If a device contains
=C2=A0 =C2=A0batteries, they can= be also monitored and managed.

=C2= =A0 =C2=A0Energy devices differ in complexity and may include basic sensors= or
=C2=A0 =C2=A0switches, specializ= ed electrical meters, or power distribution units
=C2=A0 =C2=A0(PDU), and subsystems inside the= network devices (routers, network
=C2=A0 =C2=A0switches) or home o= r industrial appliances. =C2=A0The operators of an
=C2=A0 =C2=A0Energy Management System are ei= ther the utility providers or
=C2=A0 =C2=A0customers that aim = to control and reduce the energy consumption and
=C2=A0 =C2=A0the associated costs. =C2=A0The t= opology in use differs and the deployment
=C2=A0 =C2=A0can cover areas fro= m small surfaces (individual homes) to large
=C2=A0 =C2=A0geographical areas. =C2=A0The EMAN re= quirements document [RFC6988]
=C2=A0 =C2=A0discusses the requi= rements for energy management concerning
=C2=A0 =C2=A0monitoring and control functions.<= /div>

=C2=A0 =C2=A0It is = assumed that Energy Management will apply to a large range of
<= div>=C2=A0 =C2=A0devices of all class= es and networks topologies. =C2=A0Specific resource
=C2=A0 =C2=A0monitoring like bat= tery utilization and availability may be specific
=C2=A0 =C2=A0to devices with lower physical r= esources (device classes C0 or C1).

=C2=A0 =C2=A0Energy Management is especially re= levant to the Smart Grid. =C2=A0A Smart
=C2=A0 =C2=A0Grid is an electrical grid that uses data = networks to gather and to
=C2=A0 =C2=A0act on energy and p= ower-related information in an automated fashion
=C2=A0 =C2=A0with the goal to improve the effi= ciency, reliability, economics, and
=C2=A0 =C2=A0sustainability of t= he production and distribution of electricity.

=C2=A0 =C2=A0Smart Metering is a good example of Smart Grid ba= sed Energy
=C2=A0 =C2=A0Management applicat= ions. =C2=A0Different types of possibly wireless small
=C2=A0 =C2=A0meters produce all together= a large amount of data, which is
=C2=A0 =C2=A0collected by a cent= ral entity and processed by an application server,
=C2=A0 =C2=A0which may be located within the= customer's residence or off-site in a
=C2=A0 =C2=A0data-center. =C2=A0= The communication infrastructure can be provided by a
=C2=A0 =C2=A0mobile network operator as t= he meters in urban areas will have most
=C2=A0 =C2=A0likely a cellular o= r WiMAX radio. =C2=A0In case the application server is




Ersue, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0[Page 9]
=0C
Internet-Draft =C2= =A0 =C2=A0 =C2=A0Constrained Management: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0July 2014
=

=C2=A0 =C2=A0locate= d within the residence, such meters are more likely to use WiFi
=C2=A0 =C2=A0protocols to inter= connect with an existing network.

=C2=A0 =C2=A0An Advanced Metering Infrastructur= e (AMI) network is another example
=C2=A0 =C2=A0of the Smart Grid that enables an electric util= ity to retrieve
=C2=A0 =C2=A0frequent electric u= sage data from each electric meter installed at a
=C2=A0 =C2=A0customer's home or business.= =C2=A0Unlike Smart Metering, in which case
=C2=A0 =C2=A0the customer or the= ir agents install appliance level meters, an AMI
=C2=A0 =C2=A0infrastructure is typically manag= ed by the utility providers and
=C2=A0 =C2=A0could also include = other distribution automation devices like
=C2=A0 =C2=A0transformers and reclosers. =C2=A0Meter= s in AMI networks typically contain
=C2=A0 =C2=A0constrained devices= that connect to mesh networks with a low-
=C2=A0 =C2=A0bandwidth radio. =C2=A0Usage data and o= utage notifications can be sent by
=C2=A0 =C2=A0these meters to the= utility's headend systems, via aggregation points
=C2=A0 =C2=A0of higher-end router device= s that bridge the constrained network to a
=C2=A0 =C2=A0less constrained ne= twork via cellular, WiMAX, or Ethernet. =C2=A0Unlike
=C2=A0 =C2=A0meters, these higher-end devi= ces might be installed on utility poles
=C2=A0 =C2=A0owned and operated = by a separate entity.
=C2=A0 =C2=A0= It thereby becomes important for a management application to not only
=C2=A0 =C2=A0be able to work wit= h diverse types of devices, but also over multiple
=C2=A0 =C2=A0links that might be operated an= d managed by separate entities, each
=C2=A0 =C2=A0having divergent po= licies for their own devices and network segments.
=C2=A0 =C2=A0During management operations, l= ike firmware updates, it is important
=C2=A0 =C2=A0that the management= system performs robustly in order to avoid
=C2=A0 =C2=A0accidental outages of critical power s= ystems that could be part of
=C2=A0 =C2=A0AMI networks. =C2= =A0In fact, since AMI networks must also report on
=C2=A0 =C2=A0outages, the management system = might have to manage the energy
=C2=A0 =C2=A0properties of batte= ry operated AMI devices themselves as well.

=C2=A0 =C2=A0A management system for home based Smart Metering sol= utions is likely
=C2=A0 =C2=A0to have few devices= laid out in a simple topology.
TW> how many are few? what's a simple topology? While (I= think) I have a good
TW> of what that might be, pr= oposing a range might help with scope
=C2=A0 =C2=A0However, AMI
=C2=A0 =C2=A0networks installations could have thou= sands of nodes per router,
=C2=A0 =C2=A0i.e., higher-end de= vice, which organize themselves in an ad-hoc
=C2=A0 =C2=A0manner. =C2=A0As such, a management s= ystem for AMI networks will need to
=C2=A0 =C2=A0discover and operat= e over complex topologies as well. =C2=A0In some
=C2=A0 =C2=A0situations, it is possible that t= he management system might also have
=C2=A0 =C2=A0to setup and manage= the topology of nodes, especially critical
=C2=A0 =C2=A0routers. =C2=A0Encryption key manageme= nt and sharing in both types of
=C2=A0 =C2=A0network
TW> typo network*s*
=C2=A0 =C2=A0is also likely = to be important for providing confidentiality
=C2=A0 =C2=A0for all data traffi= c. =C2=A0In AMI networks the key may be obtained by a
=C2=A0 =C2=A0meter only after an end-to-e= nd authentication process based on
=C2=A0 =C2=A0certificates. =C2= =A0Smart Metering solution could adopt a similar approach
= =C2=A0 =C2=A0or the security may be i= mplied due to the encrypted WiFi networks
=C2=A0 =C2=A0they become part of= .

<= div>TW> Please use either Wi-Fi or= WiFi. There must be an official one?

=C2=A0 =C2=A0The management of such a network r= equires end-to-end management of
=C2=A0 =C2=A0and information exchange through different types = of networks.



Er= sue, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 201= 5 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 10]
=0C
Internet-Draft =C2= =A0 =C2=A0 =C2=A0Constrained Management: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0July 2014
=

=C2=A0 =C2=A0Howeve= r, as of today there is no integrated energy management
=C2=A0 =C2=A0approach and no common inf= ormation model available. =C2=A0Specific energy
=C2=A0 =C2=A0management applicat= ions or network islands use their own management
=C2=A0 =C2=A0mechanisms.

3.5. =C2=A0Medical = Applications

=C2=A0 =C2=A0Constrain= ed devices can be seen as an enabling technology for
=C2=A0 =C2=A0advanced and possib= ly remote health monitoring and emergency
=C2=A0 =C2=A0notification systems, ranging from blood= pressure and heart rate
=C2=A0 =C2=A0monitors to advance= d devices capable to monitor
TW> rephrase to "capable of monitoring"?
=
=C2=A0 =C2=A0implanted
=C2=A0 =C2=A0technologies, such = as pacemakers or advanced hearing aids. =C2=A0Medical
=C2=A0 =C2=A0sensors may not only be atta= ched to human bodies, they might also
=C2=A0 =C2=A0exist in the infras= tructure used by humans such as bathrooms or
=C2=A0 =C2=A0kitchens. =C2=A0Medical applications = will also be used to ensure
=C2=A0 =C2=A0treatments are bein= g applied properly and they might guide people
=C2=A0 =C2=A0losing orientation. =C2=A0Fitness = and wellness applications, such as
=C2=A0 =C2=A0connected scales or= wearable heart monitors, encourage consumers to
=C2=A0 =C2=A0exercise and empower self-monitor= ing of key fitness indicators.
=C2=A0 =C2=A0Different applicati= ons use Bluetooth, Wi-Fi or Zigbee connections to
=C2=A0 =C2=A0access the patient's smartph= one or home cellular connection to access
=C2=A0 =C2=A0the Internet.

=C2=A0 =C2=A0Constrained devices that ar= e part of medical applications are managed
=C2=A0 =C2=A0either by the users= of those devices or by an organization providing
=C2=A0 =C2=A0medical (monitoring) services fo= r physicians. =C2=A0In the first case,
=C2=A0 =C2=A0management must be = automatic and or
TW&= gt; "and/or"?
=C2=A0 =C2=A0easy to install and setup by
=C2=A0 =C2=A0average people. =C2= =A0In the second case, it can be expected that devices
=C2=A0 =C2=A0be controlled by specially = trained people. =C2=A0In both cases, however,
=C2=A0 =C2=A0it is crucial to pr= otect the privacy of the people to which medical
=C2=A0 =C2=A0devices are attached. =C2=A0Even = though the data collected by a heart beat
=C2=A0 =C2=A0monitor might be pr= otected, the pure fact that someone carries such a
=C2=A0 =C2=A0device may need protection. =C2= =A0As such, certain medical appliances may
=C2=A0 =C2=A0not want to partici= pate in discovery and self-configuration protocols
=C2=A0 =C2=A0in order to remain invisible.

=C2=A0 =C2=A0Many m= edical devices are likely to be used (and relied upon) to
= =C2=A0 =C2=A0provide data to physicia= ns in critical situations since the biggest
=C2=A0 =C2=A0market is likely el= derly and handicapped people. =C2=A0Timely delivery of
=C2=A0 =C2=A0data can be quite important= in certain applications like patient
=C2=A0 =C2=A0mobility monitoring= in oldage homes. =C2=A0Data must reach the physician
=C2=A0 =C2=A0and/or emergency services wi= thin specified limits of time in order to
=C2=A0 =C2=A0be useful. =C2=A0As= such, fault detection of the communication network or
=C2=A0 =C2=A0the constrained devices bec= omes a crucial function of the management
=C2=A0 =C2=A0system that must be= carried out with high reliability and, depending
=C2=A0 =C2=A0on the medical appliance and its= application, within seconds.




Ersue, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 [Page 11]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0Constrained Management: Use = Cases =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0July 2014


3.6. =C2=A0Building Automation

=C2=A0 =C2=A0Buildi= ng automation comprises the distributed systems designed and
=C2=A0 =C2=A0deployed to monitor a= nd control the mechanical, electrical and
=C2=A0 =C2=A0electronic systems = inside buildings with various destinations (e.g.,
=C2=A0 =C2=A0public and private, industrial, = institutions, or residential).
=C2=A0 =C2=A0Advanced Building A= utomation Systems (BAS) may be deployed
=C2=A0 =C2=A0concentrating the various functions of saf= ety, environmental control,
=C2=A0 =C2=A0occupancy, security= . =C2=A0More and more the deployment of the various
=C2=A0 =C2=A0functional systems is connecte= d to the same communication
=C2=A0 =C2=A0infrastructure (pos= sibly Internet Protocol based), which may involve
=C2=A0 =C2=A0wired or wireless communications= networks inside the building.

=C2=A0 =C2=A0Building automation requires the d= eployment of a large number
=C2=A0 =C2=A0(10-100.000) of sensors that monitor the status of dev= ices, and
=C2=A0 =C2=A0parameters inside t= he building and controllers with different
=C2=A0 =C2=A0specialized functionality for areas wit= hin the building or the
=C2=A0 =C2=A0totality of the bui= lding. =C2=A0Inter-node distances between neighboring
=C2=A0 =C2=A0nodes vary between 1 to 20 m= eters. =C2=A0Contrary to home automation, in
=C2=A0 =C2=A0building management= the devices are expected to be managed assets and
=C2=A0 =C2=A0known to a set of commissioning= tools and a data storage, such that
=C2=A0 =C2=A0every connected dev= ice has a known origin. =C2=A0The management includes
=C2=A0 =C2=A0verifying the presence of th= e expected devices and detecting the
=C2=A0 =C2=A0presence of unwante= d devices.

=C2=A0 =C2=A0Examples of= functions performed by such controllers are regulating
=C2=A0 =C2=A0the quality, humidi= ty, and temperature of the air inside the building
=C2=A0 =C2=A0and lighting. =C2=A0Other syste= ms may report the status of the machinery
=C2=A0 =C2=A0inside the building= like elevators, or inside the rooms like
=C2=A0 =C2=A0projectors in meeting rooms. =C2=A0Secur= ity cameras and sensors may be
=C2=A0 =C2=A0deployed and operat= ed on separate dedicated infrastructures connected
=C2=A0 =C2=A0to the common backbone. =C2=A0T= he deployment area of a BAS is typically
=C2=A0 =C2=A0inside one building= (or part of it) or several buildings
=C2=A0 =C2=A0geographically grouped in a campus. =C2=A0A = building network can be
=C2=A0 =C2=A0composed of network= segments, where a network segment covers a floor,
=C2=A0 =C2=A0an area on the floor, or a give= n functionality (e.g., security
=C2=A0 =C2=A0cameras).

=C2=A0 =C2=A0Some of the sensors in Building= Automation Systems (for example fire
=C2=A0 =C2=A0alarms or security = systems) register, record and transfer critical
=C2=A0 =C2=A0alarm information and therefore mu= st be resilient to events like loss
=C2=A0 =C2=A0of power or securit= y attacks. =C2=A0This leads to the need to certify
=C2=A0 =C2=A0components and subsystems opera= ting in such constrained conditions
=C2=A0 =C2=A0based on specific r= equirements. =C2=A0Also in some environments, the
=C2=A0 =C2=A0malfunctioning of a control syst= em (like temperature control) needs
=C2=A0 =C2=A0to be reported in t= he shortest possible time. =C2=A0Complex control
=C2=A0 =C2=A0systems can misbehave, and their = critical status reporting and safety



Ersue, et al. =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 [Page 12]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0Constrained = Management: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0July 2014


=C2=A0 =C2=A0algorithms need to be basic and robust and perfor= m even in critical
=C2=A0 =C2=A0conditions.<= /div>

=C2=A0 =C2=A0Building Automation solutions= are deployed in some cases in newly
=C2=A0 =C2=A0designed buildings,= in other cases it might be over existing
=C2=A0 =C2=A0infrastructures. =C2=A0In the first case= , there is a broader range of
=C2=A0 =C2=A0possible solutions,= which can be planned for the infrastructure of
=C2=A0 =C2=A0the building. =C2=A0In the second = case the solution needs to be deployed
=C2=A0 =C2=A0over an existing in= frastructure taking into account factors like
=C2=A0 =C2=A0existing wiring, distance limitati= ons, the propagation of radio
=C2=A0 =C2=A0signals over walls = and floors, thereby making deployment difficult.
=C2=A0 =C2=A0As a result, some of the existing= WLAN solutions (e.g., IEEE 802.11
=C2=A0 =C2=A0or IEEE 802.15) may= be deployed. =C2=A0In mission-critical or security
=C2=A0 =C2=A0sensitive environments and in = cases where link failures happen often,
=C2=A0 =C2=A0topologies that all= ow for reconfiguration of the network and
=C2=A0 =C2=A0connection continuity may be required. = =C2=A0Some of the sensors deployed
=C2=A0 =C2=A0in building automat= ion may be very simple constrained devices for
=C2=A0 =C2=A0which class 0 or class 1 may be as= sumed.

TW> you use "C1" and "C0" abo= ve. Please homogenize.
=C2=A0 =C2=A0
=C2=A0 =C2=A0For lighting applic= ations, groups of lights must be defined and
=C2=A0 =C2=A0managed. =C2=A0Commands to a group of= light must arrive within 200 ms at
=C2=A0 =C2=A0all destinations. = =C2=A0The installation and operation of a building
=C2=A0 =C2=A0network has different requireme= nts. =C2=A0During the installation, many
=C2=A0 =C2=A0stand-alone network= s of a few to 100 nodes co-exist without a
=C2=A0 =C2=A0connection to the backbone. =C2=A0Durin= g this phase, the nodes are
=C2=A0 =C2=A0identified with a n= etwork identifier related to their physical
=C2=A0 =C2=A0location. =C2=A0Devices are accessed f= rom an installation tool to connect
=C2=A0 =C2=A0them to the network= in a secure fashion. =C2=A0During installation, the
=C2=A0 =C2=A0setting of parameters of comm= on values to enable interoperability may
=C2=A0 =C2=A0be required. =C2=A0= During operation, the networks are connected to the
=C2=A0 =C2=A0backbone while maintaining the= network identifier to physical
=C2=A0 =C2=A0location relation. = =C2=A0Network parameters like address and name are
=C2=A0 =C2=A0stored in DNS. =C2=A0The names = can assist in determining the physical
=C2=A0 =C2=A0location of the dev= ice.

3.7. =C2=A0Home Automation

=C2=A0 =C2=A0Home a= utomation includes the control of lighting, heating,
=C2=A0 =C2=A0ventilation, air conditioning= , appliances, entertainment and home
TW> The word "security&q= uot; appears twice
= =C2=A0 =C2=A0security devices to improve convenience, comfort, energy effic= iency,
=C2=A0 =C2=A0and security. =C2= =A0It can be seen as a residential extension of building
<= font face=3D"courier new, monospace">=C2=A0 =C2=A0automation. =C2=A0However= , unlike a building automation system, the
=C2=A0 =C2=A0infrastructure in a= home is operated in a considerably more ad-hoc
=C2=A0 =C2=A0manner. =C2=A0While in some instal= lations it is likely that there is no
=C2=A0 =C2=A0centralized managem= ent system, akin to a Building Automation System
=C2=A0 =C2=A0(BAS), available, in other situat= ions outsourced and cloud based
=C2=A0 =C2=A0systems responsible= for managing devices in the home might be used.




Ersue, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 [Page 13]
=0C
Internet-Draft =C2= =A0 =C2=A0 =C2=A0Constrained Management: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0July 2014
=

=C2=A0 =C2=A0Home a= utomation networks need a certain amount of configuration
= TW> actors -> actuators ?
=C2=A0 =C2=A0(associating switches or= sensors to actors) that is either provided
=C2=A0 =C2=A0by electricians deploying home automat= ion solutions, by third party
=C2=A0 =C2=A0home automation ser= vice providers (e.g., small specialized companies
=C2=A0 =C2=A0or home automation device manufa= cturers) or by residents by using the
=C2=A0 =C2=A0application user in= terface provided by home automation devices to
=C2=A0 =C2=A0configure (parts of) the home auto= mation solution. =C2=A0Similarly,
=C2=A0 =C2=A0failures may be rep= orted via suitable interfaces to residents or they
=C2=A0 =C2=A0might be recorded and made avai= lable to services providers in charge
=C2=A0 =C2=A0of the maintenance = of the home automation infrastructure.

=C2=A0 =C2=A0The management responsibility lies either with the residen= ts or it
=C2=A0 =C2=A0may be outsourced t= o electricians and/or third parties providing
=C2=A0 =C2=A0management of home automation solu= tions as a service. =C2=A0A varying
=C2=A0 =C2=A0combination of elec= tricians, service providers or the residents may
=C2=A0 =C2=A0be responsible for different aspe= cts of managing the infrastructure.
=C2=A0 =C2=A0The time scale for = failure detection and resolution is in many cases
=C2=A0 =C2=A0likely counted in hours to days.=

3.8. =C2=A0Transpor= t Applications

<= /font>
=C2=A0 =C2=A0Transpo= rt Application is a generic term for the integrated
=C2=A0 =C2=A0application of comm= unications, control, and information processing in
=C2=A0 =C2=A0a transportation system. =C2=A0= Transport telematics or vehicle telematics
=C2=A0 =C2=A0are used as a term = for the group of technologies that support
=C2=A0 =C2=A0transportation systems. =C2=A0Transport= applications running on such a
=C2=A0 =C2=A0transportation syst= em cover all modes of the transport and consider
=C2=A0 =C2=A0all elements of the transportatio= n system, i.e. the vehicle, the
=C2=A0 =C2=A0infrastructure, and= the driver or user, interacting together
=C2=A0 =C2=A0dynamically. =C2=A0Examples for transpor= t applications are inter and intra
=C2=A0 =C2=A0vehicular communica= tion, smart traffic control, smart parking,
=C2=A0 =C2=A0electronic toll collection systems, lo= gistic and fleet management,
=C2=A0 =C2=A0vehicle control, an= d safety and road assistance.

=C2= =A0 =C2=A0As a distributed system, transport applications require an end-to= -end
=C2=A0 =C2=A0management of diffe= rent types of networks. =C2=A0It is likely that
=C2=A0 =C2=A0constrained devices in a network (= e.g. a moving in-car network) have
=C2=A0 =C2=A0to be controlled by= an application running on an application server
=C2=A0 =C2=A0in the network of a service provi= der. =C2=A0Such a highly distributed
=C2=A0 =C2=A0network including c= ellular devices on vehicles is assumed to include
=C2=A0 =C2=A0a wireless access network using = diverse long distance wireless
=C2=A0 =C2=A0technologies such a= s WiMAX, 3G/LTE or satellite communication, e.g.
=C2=A0 =C2=A0based on an embedded hardware mod= ule. =C2=A0As a result, the management of
=C2=A0 =C2=A0constrained devices= in the transport system might be necessary to
=C2=A0 =C2=A0plan top-down and might need to us= e data models obliged from and
=C2=A0 =C2=A0defined on the appl= ication layer. =C2=A0The assumed device classes in use
=C2=A0 =C2=A0are mainly C2 devices. =C2= =A0In cases, where an in-vehicle network is
=C2=A0 =C2=A0involved, C1 device= s with limited capabilities and a short-distance



Ersue, et al. =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 [Page 14]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0Constrained Man= agement: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0July 2014


=C2=A0 =C2=A0constrained radio network, e.g. =C2=A0IEEE 802.15= .4 might be used
=C2=A0 =C2=A0additionally.

=C2=A0 =C2=A0All Transport Applications = will require an IT infrastructure to run
=C2=A0 =C2=A0on top of, e.g., in= public transport scenarios like trains, bus or
=C2=A0 =C2=A0metro network infrastructure might= be provided, maintained and
=C2=A0 =C2=A0operated by third p= arties like mobile network or satellite network
=C2=A0 =C2=A0operators. =C2=A0However, the mana= gement responsibility of the transport
=C2=A0 =C2=A0application typical= ly rests within the organization running the
=C2=A0 =C2=A0transport application (in the public = transport scenario, this would
=C2=A0 =C2=A0typically be the pu= blic transport operator). =C2=A0Different aspects of
=C2=A0 =C2=A0the infrastructure might also= be managed by different entities. =C2=A0For
=C2=A0 =C2=A0example, the in-car= devices are likely to be installed and managed by
=C2=A0 =C2=A0the manufacturer, while the pub= lic works might be responsible for the
=C2=A0 =C2=A0on-road vehicular c= ommunication infrastructure used by these devices.
=C2=A0 =C2=A0The back-end infrastructure is = also likely to be maintained by third
=C2=A0 =C2=A0party operators. = =C2=A0As such, the NMS must be able to deal with
=C2=A0 =C2=A0different network segments, each = being operated and controlled by
=C2=A0 =C2=A0separate entities, = and enable appropriate access control and security
=C2=A0 =C2=A0as well.

=C2=A0 =C2=A0Depend= ing on the type of application domain (vehicular or stationary)
=C2=A0 =C2=A0and service being = provided, it would be important for the NMS to be
=C2=A0 =C2=A0able to function wi= th different architectures, since different
=C2=A0 =C2=A0manufacturers might have their own pro= prietary systems relying on a
=C2=A0 =C2=A0specific Management= Topology Option, as described in [COM-REQ].
=C2=A0 =C2=A0Moreover, constituents of the network= can be either private,
=C2=A0 =C2=A0belonging to indivi= duals or private companies, or owned by public
=C2=A0 =C2=A0institutions leading to different = legal and organization
=C2=A0 =C2=A0requirements. =C2= =A0Across the entire infrastructure, a variety of
=C2=A0 =C2=A0constrained devices are likely t= o be used, and must be individually
=C2=A0 =C2=A0managed. =C2=A0The = NMS must be able to either work directly with different
=C2=A0 =C2=A0types of devices, or have = the ability to interoperate with multiple
=C2=A0 =C2=A0different systems.<= /font>

=C2=A0 =C2=A0The challenges in the = management of vehicles in a mobile transport
=C2=A0 =C2=A0application are man= ifold. =C2=A0The up-to-date position of each node in
=C2=A0 =C2=A0the network should be reporte= d to the corresponding management
=C2=A0 =C2=A0entities, since the= nodes could be moving within or roaming between
=C2=A0 =C2=A0different networks. =C2=A0Secondl= y, a variety of troubleshooting
=C2=A0 =C2=A0information, includ= ing sensitive location information, needs to be
=C2=A0 =C2=A0reported to the management system = in order to provide accurate
=C2=A0 =C2=A0service to the cust= omer. =C2=A0Management systems dealing with mobile
=C2=A0 =C2=A0nodes could possibly exploit sp= ecific patterns in the mobility of the
=C2=A0 =C2=A0nodes. =C2=A0These = patterns emerge due to repetitive vehicular usage in
=C2=A0 =C2=A0scenarios like people commuti= ng to work, logistics supply vehicles
=C2=A0 =C2=A0transporting shipme= nts between warehouses and etc. =C2=A0The NMS must also
=C2=A0 =C2=A0be able to handle partitio= ned networks, which would arise due to the



Er= sue, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 201= 5 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 15]
=0C
Internet-Draft =C2= =A0 =C2=A0 =C2=A0Constrained Management: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0July 2014
=

=C2=A0 =C2=A0dynami= c nature of traffic resulting in large inter-vehicle gaps in
=C2=A0 =C2=A0sparsely populated sc= enarios. =C2=A0Since mobile nodes might roam in
=C2=A0 =C2=A0remote networks, th= e NMS should be able to provide operating
=C2=A0 =C2=A0configuration updates regardless of node= location.

=C2=A0 =C2=A0The constrained devices in a movin= g transport network might be
=C2=A0 =C2=A0initially configured in a factory and a reconfigurati= on might be
=C2=A0 =C2=A0needed only rarely.= =C2=A0New devices might be integrated in an ad-hoc
=C2=A0 =C2=A0manner based on self-managemen= t and -configuration capabilities.
=C2=A0 =C2=A0Monitoring and data= exchange might be necessary to do via a gateway
=C2=A0 =C2=A0entity connected to the back-end = transport infrastructure. =C2=A0The
=C2=A0 =C2=A0devices and entitie= s in the transport infrastructure need to be
=C2=A0 =C2=A0monitored more frequently and can be = able to communicate with a
=C2=A0 =C2=A0higher data rate. = =C2=A0The connectivity of such entities does not
=C2=A0 =C2=A0necessarily need to be wireless. = =C2=A0The time scale for detecting and
=C2=A0 =C2=A0recording failures = in a moving transport network is likely measured
=C2=A0 =C2=A0in hours and repairs might easily= take days. =C2=A0It is likely that a
=C2=A0 =C2=A0self-healing featur= e would be used locally. =C2=A0On the other hand,
=C2=A0 =C2=A0failures in fixed transport appl= ication infrastructure (e.g.,
=C2=A0 =C2=A0traffic-lights, dig= ital signage displays) is likely to be measured in
=C2=A0 =C2=A0minutes so as to avoid untoward= traffic incidents. =C2=A0As such, the NMS
=C2=A0 =C2=A0must be able to dea= l with differing timeliness requirements based on
=C2=A0 =C2=A0the type of devices.

3.9. =C2=A0Communit= y Network Applications

=C2=A0 =C2= =A0Community networks are comprised of constrained routers in a multi-
=C2=A0 =C2=A0hop mesh topology, = communicating over a lossy, and often wireless
TW> typo: channel*s*
=C2=A0 =C2=A0channel. =C2=A0While the route= rs are mostly non-mobile, the topology may
=C2=A0 =C2=A0be very dynamic bec= ause of fluctuations in link quality of the
=C2=A0 =C2=A0(wireless) channel caused by, e.g., ob= stacles, or other nearby radio
=C2=A0 =C2=A0transmissions. =C2= =A0Depending on the routers that are used in the
=C2=A0 =C2=A0community network, the resources = of the routers (memory, CPU) may be
=C2=A0 =C2=A0more or less constr= ained - available resources may range from only a
=C2=A0 =C2=A0few kilobytes of RAM to several = megabytes or more, and CPUs may be
=C2=A0 =C2=A0small and embedded,= or more powerful general-purpose processors.
=C2=A0 =C2=A0Examples of such community network= s are the FunkFeuer network
=C2=A0 =C2=A0(Vienna, Austria), = FreiFunk (Berlin, Germany), Seattle Wireless
=C2=A0 =C2=A0(Seattle, USA), and AWMN (Athens, Gre= ece). =C2=A0These community networks
=C2=A0 =C2=A0are public and non-= regulated, allowing their users to connect to each
=C2=A0 =C2=A0other and - through an uplink t= o an ISP - to the Internet. =C2=A0No fee,
=C2=A0 =C2=A0other than the init= ial purchase of a wireless router, is charged for
=C2=A0 =C2=A0these services. =C2=A0Applicatio= ns of these community networks can be
=C2=A0 =C2=A0diverse, e.g., loca= tion based services, free Internet access, file
=C2=A0 =C2=A0sharing between users, distributed= chat services, social networking
=C2=A0 =C2=A0etc, video sharing = etc.

TW> One "etc" too= many above.



Ersue, et al. =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 [Page 16]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0Constrained = Management: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0July 2014


=C2=A0 =C2=A0As an example of a community network, the FunkFeu= er network comprises
=C2=A0 =C2=A0several hundred rou= ters, many of which have several radio interfaces
=C2=A0 =C2=A0(with omnidirectional and some d= irected antennas). =C2=A0The routers of
=C2=A0 =C2=A0the network are sma= ll-sized wireless routers, such as the Linksys
=C2=A0 =C2=A0WRT54GL, available in 2011 for les= s than 50 Euros. =C2=A0These routers,
=C2=A0 =C2=A0with 16 MB of RAM a= nd 264 MHz of CPU power, are mounted on the
=C2=A0 =C2=A0rooftops of the users. =C2=A0When new = users want to connect to the
=C2=A0 =C2=A0network, they acqui= re a wireless router, install the appropriate
=C2=A0 =C2=A0firmware and routing protocol, and= mount the router on the rooftop.
=C2=A0 =C2=A0IP addresses for th= e router are assigned manually from a list of
=C2=A0 =C2=A0addresses (because of the lack of = autoconfiguration standards for
TW> autoconfiguration -> a= uto-configuration?
= =C2=A0 =C2=A0mesh networks in the IETF).

=C2=A0 =C2=A0While = the routers are non-mobile, fluctuations in link quality
<= font face=3D"courier new, monospace">=C2=A0 =C2=A0require an ad hoc routing= protocol that allows for quick convergence
=C2=A0 =C2=A0to reflect the effe= ctive topology of the network (such as NHDP
=C2=A0 =C2=A0[RFC6130] and OLSRv2 [RFC7181] develop= ed in the MANET WG). =C2=A0Usually,
=C2=A0 =C2=A0no human interactio= n is required for these protocols, as all variable
=C2=A0 =C2=A0parameters required by the rout= ing protocol are either negotiated in
=C2=A0 =C2=A0the control traffic= exchange, or are only of local importance to each
=C2=A0 =C2=A0router (i.e. do not influence i= nteroperability). =C2=A0However, external
=C2=A0 =C2=A0management and moni= toring of an ad hoc routing protocol may be
=C2=A0 =C2=A0desirable to optimize parameters of th= e routing protocol. =C2=A0Such an
=C2=A0 =C2=A0optimization may le= ad to a more stable perceived topology and to a
=C2=A0 =C2=A0lower control traffic overhead, an= d therefore to a higher delivery
=C2=A0 =C2=A0success ratio of da= ta packets, a lower end-to-end delay, and less
=C2=A0 =C2=A0unnecessary bandwidth and energy u= sage.

=C2=A0 =C2=A0Different use cases for the management = of community networks are
=C2=A0 =C2=A0possible:

=C2=A0 =C2=A0o =C2=A0One single Network Managem= ent Station, e.g. a border gateway
=C2=A0 =C2=A0 =C2=A0 providing connectivity to the Internet,= requires managing or
=C2=A0 =C2=A0 =C2=A0 monitoring = routers in the community network, in order to
=C2=A0 =C2=A0 =C2=A0 investigate problems (moni= toring) or to improve performance by
=C2=A0 =C2=A0 =C2=A0 changing pa= rameters (managing). =C2=A0As the topology of the network is
=C2=A0 =C2=A0 =C2=A0 dynamic, cons= tant connectivity of each router towards the
=C2=A0 =C2=A0 =C2=A0 management = station cannot be guaranteed. =C2=A0Current network
TW> Netconf -> NETCONF (see RFC4741)<= /font>
=C2=A0 =C2=A0 =C2=A0= management protocols, such as SNMP and Netconf, may be used (e.g.,<= /div>
=C2=A0 =C2=A0 =C2=A0 using inter= faces such as the NHDP-MIB [RFC6779]). =C2=A0However, when
=C2=A0 =C2=A0 =C2=A0 routers in the = community network are constrained, existing
=C2=A0 =C2=A0 =C2=A0 protocols m= ay require too many resources in terms of memory and
=C2=A0 =C2=A0 =C2=A0 CPU; and more importa= ntly, the bandwidth requirements may exceed
=C2=A0 =C2=A0 =C2=A0 the availab= le channel capacity in wireless mesh networks.
=C2=A0 =C2=A0 =C2=A0 Moreover, management and m= onitoring may be unfeasible if the
=C2=A0 =C2=A0 =C2=A0 connection = between the network management station and the routers
=C2=A0 =C2=A0 =C2=A0 is frequently inter= rupted.




Ersue, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires= January 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 17]=
=0C
Internet-Draft =C2= =A0 =C2=A0 =C2=A0Constrained Management: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0July 2014
=

TW> I would remo= ve "A"
=C2= =A0 =C2=A0o =C2=A0A distributed network monitoring, in which more than one<= /font>
=C2=A0 =C2=A0 =C2=A0 management stati= on monitors or manages other routers. =C2=A0Because
=C2=A0 =C2=A0 =C2=A0 connectivity to a serv= er cannot be guaranteed at all times, a
=C2=A0 =C2=A0 =C2=A0 distributed= approach may provide a higher reliability, at the cost
=C2=A0 =C2=A0 =C2=A0 of increased compl= exity. =C2=A0Currently, no IETF standard exists for
=C2=A0 =C2=A0 =C2=A0 distributed= monitoring and management.

=C2=A0 = =C2=A0o =C2=A0Monitoring and management of a whole network or a group of
=C2=A0 =C2=A0 =C2=A0 routers. = =C2=A0Monitoring the performance of a community network may
=C2=A0 =C2=A0 =C2=A0 require more i= nformation than what can be acquired from a single
=C2=A0 =C2=A0 =C2=A0 router usin= g a network management protocol. =C2=A0Statistics, such as
=C2=A0 =C2=A0 =C2=A0 topology change= s over time, data throughput along certain routing
=C2=A0 =C2=A0 =C2=A0 paths, cong= estion etc., are of interest for a group of routers (or
TW> update to 2014?
=C2=A0 =C2=A0 =C2=A0 the routing dom= ain) as a whole. =C2=A0As of 2012, no IETF standard
=C2=A0 =C2=A0 =C2=A0 allows for = monitoring or managing whole networks, instead of
=C2=A0 =C2=A0 =C2=A0 single routers.

3.10. =C2=A0Field O= perations

=C2=A0 =C2=A0The challeng= es of configuration and monitoring of networks operated
=C2=A0 =C2=A0in the field by res= cue and security agencies can be different from
=C2=A0 =C2=A0the other use cases since the requ= irements and operating conditions
=C2=A0 =C2=A0of such networks ar= e quite different.
<= br>
TW> typo: bec= omeing -> becoming

=C2=A0 =C2=A0With technology advancements, fiel= d networks operated nowadays are
=C2=A0 =C2=A0becomeing large and can consist of varieties of d= ifferent types of
=C2=A0 =C2=A0equipment that run = different protocols and tools that obviously
TW> "mission-critical"?
<= div>=C2=A0 =C2=A0increase complexity = of these mission critical networks. =C2=A0In many
=C2=A0 =C2=A0scenarios, configur= ations are, most likely, manually performed.
=C2=A0 =C2=A0Furthermore, some legacy and even mod= ern devices do not even support
TW> "*A* majority"?=
TW> proprietary*= ,* which
=C2=A0 =C2= =A0IP networking. =C2=A0Majority of protocols and tools developed by vendor= s
=C2=A0 =C2=A0that are being used= are proprietary which makes integration more
=C2=A0 =C2=A0difficult.

=C2=A0 =C2=A0The ma= in reason for this disjoint operation scenario is that most
=C2=A0 =C2=A0equipment is developed= with specific task requirements in mind,
=C2=A0 =C2=A0rather than interop= erability of the varied equipment types. =C2=A0For
=C2=A0 =C2=A0example, the operating conditio= ns experienced by high altitude
=C2=A0 =C2=A0security equipment = is significantly different from that used in
=C2=A0 =C2=A0desert conditions. =C2=A0Similarly, s= earch and rescue operations equipment
=C2=A0 =C2=A0used in case of fir= e rescue has different requirements than flood
TW> "inter-operation"?
=C2=A0 =C2=A0relief equipment. = =C2=A0Furthermore, interoperation of equipment with
=C2=A0 =C2=A0telecommunication e= quipment was not an expected outcome or in some
=C2=A0 =C2=A0scenarios this may not even be des= irable.

=C2=A0 =C2=A0Currently, field networks operate = with a fixed Network Operations
=C2=A0 =C2=A0Center (NOC) that physically manages the configura= tion and evaluation
=C2=A0 =C2=A0of all field device= s. =C2=A0Once configured, the devices might be deployed



Ersue, et al. =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 [Page 18]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0Constrained Man= agement: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0July 2014


=C2=A0 =C2=A0in fixed or mobile scenarios. =C2=A0Any configura= tion changes required
=C2=A0 =C2=A0would need to be ap= propriately encrypted and authenticated to prevent
=C2=A0 =C2=A0unauthorized access.

=C2=A0 =C2=A0Hierar= chical management of devices is a common requirement in such
=C2=A0 =C2=A0scenarios since local= managers or operators may need to respond to
=C2=A0 =C2=A0changing conditions= within their purview. =C2=A0The level of configuration
=C2=A0 =C2=A0management available at ea= ch hierarchy must also be closely governed.

=C2=A0 =C2=A0Since many field operation devices= are used in hostile environments,
=C2=A0 =C2=A0a high failure and disconnection rate should be= tolerated by the NMS,
=C2=A0 =C2=A0which must also be = able to deal with multiple gateways and disjoint
=C2=A0 =C2=A0management protocols.

TW> typo: invlov= ing
TW> requiring= the interoperation -> requiring inter-operation?

=C2=A0 =C2=A0Multi-= national field operations invloving search, rescue and security
=C2=A0 =C2=A0are becoming incre= asingly common, requiring the interoperation of a
=C2=A0 =C2=A0diverse set of equi= pment designed with different operating conditions
=C2=A0 =C2=A0in mind. =C2=A0Furthermore, dif= ferent intra- and inter-governmental
=C2=A0 =C2=A0agencies are likely= to have a different set of standards, best
=C2=A0 =C2=A0practices, rules and regulation, and i= mplementation approaches that
=C2=A0 =C2=A0may contradict or c= onflict with each other. =C2=A0The NMS should be able
=C2=A0 =C2=A0to detect these and handle t= hem in an acceptable manner, which may
=C2=A0 =C2=A0require human inter= vention.

=
4. =C2=A0IANA Consideratio= ns

=C2=A0 =C2=A0This document does not introduce any ne= w code-points or namespaces
=C2=A0 =C2=A0for registration with IANA.

=C2=A0 =C2=A0Note to RFC Editor: this section m= ay be removed on publication as an
=C2=A0 =C2=A0RFC.

5. =C2=A0Security Considerations

=C2=A0 =C2=A0This document discusses use cases = for Management of Networks with
=C2=A0 =C2=A0Constrained Devices= . =C2=A0The security considerations described
=C2=A0 =C2=A0throughout the companion document = [COM-REQ] apply here as well.

6. =C2=A0Contributors

=C2=A0 =C2=A0Following persons made significant contribution= s to and reviewed this
=C2=A0 =C2=A0document:

=C2=A0 =C2=A0o =C2=A0Ulrich Herberg (Fujitsu= Laboratories of America) contributed the
=C2=A0 =C2=A0 =C2=A0 Section 3.9= on Community Network Applications.

=C2=A0 =C2=A0o =C2=A0Peter van der Stok contributed to Section 3.6 on Buil= ding
=C2=A0 =C2=A0 =C2=A0 Automation.=



Ersue, et al. =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 19]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0= Constrained Management: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0July 20= 14


=C2=A0 =C2=A0o =C2=A0Zhen Cao contributed to Section 2.2 Cellu= lar Access Technologies.

=C2=A0 =C2=A0o =C2=A0Gilman Tolle contributed t= he Section 3.4 on Automated Metering
=C2=A0 =C2=A0 =C2=A0 Infrastructure.

=C2=A0 =C2=A0o =C2=A0James Nguyen and Ulrich He= rberg contributed to Section 3.10 on
=C2=A0 =C2=A0 =C2=A0 Military operations.

7. =C2=A0Acknowledgments

=C2=A0 =C2=A0Following persons reviewed and provided valu= able comments to
=C2=A0 =C2=A0different versions = of this document:
=C2=A0 =C2=A0Domi= nique Barthel, Carsten Bormann, Zhen Cao, Benoit Claise, Bert
=C2=A0 =C2=A0Greevenbosch, Ulric= h Herberg, James Nguyen, Zach Shelby, and Peter
=C2=A0 =C2=A0van der Stok.

=C2=A0 =C2=A0The ed= itors would like to thank the reviewers and the participants on
=C2=A0 =C2=A0the Coman maillist= for their valuable contributions and comments.

8. =C2=A0Informative References

=C2=A0 =C2=A0[RFC6130] =C2=A0Clausen, T., Dearlove= , C., and J. Dean, "Mobile Ad Hoc
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Network (MANET) Neighborhood Discovery Protocol (NHDP)&qu= ot;,
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC 6130, April 2011.

=C2=A0 =C2=A0[RFC6568] =C2=A0Kim, E., Kaspar, D., an= d JP. Vasseur, "Design and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Application Sp= aces for IPv6 over Low-Power Wireless
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Personal Area Networks (6LoWPANs)", RFC 6568, April = 2012.

=C2=A0 =C2=A0[RFC6779] =C2=A0= Herberg, U., Cole, R., and I. Chakeres, "Definition of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Managed Objects for the Neighborhood Discovery Protocol&q= uot;,
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC 6779, October 2012.

=C2=A0 =C2=A0[RFC6988] =C2=A0Quittek, J., Chand= ramouli, M., Winter, R., Dietz, T., and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 B. Cla= ise, "Requirements for Energy Management", RFC 6988,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 September 2013.

= =C2=A0 =C2=A0[RFC7181] =C2=A0Clausen, T., Dearlove, C., Jacquet, P., and U.= Herberg,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 "The Optimized Link State Routing Protocol Version 2= ", RFC
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7181, April 2014.

=C2=A0 =C2=A0[RFC7228] =C2=A0Bormann, C., Ersue= , M., and A. Keranen, "Terminology for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Co= nstrained-Node Networks", RFC 7228, May 2014.






Er= sue, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 201= 5 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 20]
=0C
Internet-Draft =C2= =A0 =C2=A0 =C2=A0Constrained Management: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0July 2014
=

=C2=A0 =C2=A0[I-D.i= etf-eman-framework]
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Claise, B., Schoening, B.,= and J. Quittek, "Energy
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Management Framework", draft-ietf-eman-framework-19 (wor= k
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in progress), April 2014.

=C2=A0 =C2=A0[COM-REQ] =C2=A0Ersue, M., Romascanu, D= ., and J. Schoenwaelder,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Management of N= etworks with Constrained Devices: Problem
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Statement and Requirements", draft-ietf-opsawg-coman= -
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 probstate-reqs (work in progress), February= 2014.

Appendix A. =C2=A0Change Log
<= font face=3D"courier new, monospace">
A.1. =C2=A0draft-ietf-opsawg-coman-use-cases-01 - dra= ft-ietf-opsawg-coman-
=C2=A0 =C2=A0 =C2=A0 use-cases-0= 2

<= div>=C2=A0 =C2=A0o =C2=A0Renamed Mobi= le Access Technologies section to Cellular Access
=C2=A0 =C2=A0 =C2=A0 Technologie= s

<= div>=C2=A0 =C2=A0o =C2=A0Changed refe= rences to mobile access technologies to now read
=C2=A0 =C2=A0 =C2=A0 cellular ac= cess technologies.
<= br>
=C2=A0 =C2=A0o = =C2=A0Added text to the introduction to point out that the list of use
=C2=A0 =C2=A0 =C2=A0 cases is no= t exhaustive since others unknown to the authors might
=C2=A0 =C2=A0 =C2=A0 exist.
=

=C2=A0 =C2=A0o =C2= =A0Updated references to take into account RFCs that have been now
=C2=A0 =C2=A0 =C2=A0 publish= ed.

=C2=A0 =C2=A0o =C2= =A0Updated Environmental Monitoring section to make it clear that in=
=C2=A0 =C2=A0 =C2=A0 some = scenarios it may not be prudent to repair devices.

=C2=A0 =C2=A0o =C2=A0Added clarification in Inf= rastructure Monitoring section that
=C2=A0 =C2=A0 =C2=A0 reliable communication is achieved via= application layer
=C2=A0 =C2=A0 =C2=A0 transaction= s

<= div>=C2=A0 =C2=A0o =C2=A0Removed refe= rence to Energy Devices from Energy Management
=C2=A0 =C2=A0 =C2=A0 section, in= stead labeling them as devices within the context of
=C2=A0 =C2=A0 =C2=A0 energy management.

=C2=A0 =C2=A0o =C2= =A0Reduced descriptive content in Energy Management section.

=C2=A0 =C2=A0o =C2=A0Rewrote text in Energy Man= agement section to highlight management
=C2=A0 =C2=A0 =C2=A0 characteris= tics of Smart Meter and AMI networks.

=C2=A0 =C2=A0o =C2=A0Added text regarding timely delivery of information= , and related
=C2=A0 =C2=A0 =C2=A0 management = system characteristic, to the Medical Applications
=C2=A0 =C2=A0 =C2=A0 section




Ersue, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires= January 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 21]=
=0C
Internet-Draft =C2= =A0 =C2=A0 =C2=A0Constrained Management: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0July 2014
=

=C2=A0 =C2=A0o =C2= =A0Changed subnets to network segment in Building Automation section.

=C2=A0 =C2=A0o =C2=A0Changed structure t= o infrastructure in Building Automation
=C2=A0 =C2=A0 =C2=A0 section, an= d added text to highlight associated deployment
=C2=A0 =C2=A0 =C2=A0 difficulties.
=

=C2=A0 =C2=A0o =C2= =A0Removed Trickle timer as example of common values to be set in
=C2=A0 =C2=A0 =C2=A0 Building= Automation section.

=C2=A0 =C2=A0o =C2=A0Added text regarding the p= ossible availability of outsourced and
=C2=A0 =C2=A0 =C2=A0 cloud based management systems for = Home Automation.

=C2=A0 =C2=A0o =C2=A0Added text to Transport Ap= plications section to highlight the
=C2=A0 =C2=A0 =C2=A0 requirement of IT infrastructure for s= uch applications to function
=C2=A0 =C2=A0 =C2=A0 on top of.<= /font>

=C2=A0 =C2=A0o =C2=A0Merged the Tra= nsport Applications and Vehicular Networks section
=C2=A0 =C2=A0 =C2=A0 together. = =C2=A0Following changes to the Vehicular Networks section
= =C2=A0 =C2=A0 =C2=A0 were merged back= into Transport Applications

=C2=A0 =C2=A0 =C2=A0 * =C2=A0Replaced wireless = last hops with wireless access to vehicles in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Vehicular Net= works.

=C2=A0 =C2=A0 =C2=A0 * =C2=A0Expanded proprieta= ry systems to "systems relying on a specific
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Management = Topology Option, as described in [COM-REQ]." within
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Vehicular Networks section.

=C2= =A0 =C2=A0 =C2=A0 * =C2=A0Added text regarding mobility patterns to Vehicul= ar Networks.

=C2=A0 =C2=A0o =C2=A0Changed the Military Opera= tions use case to Field Operations and
=C2=A0 =C2=A0 =C2=A0 edited the text to be suitable to s= uch scenarios.

A.2. =C2=A0draft-ietf-opsawg-coman-use-cases-00= - draft-ietf-opsawg-coman-
=C2=A0 =C2=A0 =C2=A0 use-cases-01

=C2=A0 =C2=A0o =C2=A0Reordered some use cases t= o improve the flow.
=
=C2=A0 =C2=A0o =C2=A0Added "= ;Vehicular Networks".

=C2=A0 = =C2=A0o =C2=A0Shortened the Military Operations use case.

=C2=A0 =C2=A0o =C2=A0Started adding substance t= o the security considerations section.









Ersue, et al. =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 22]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0= Constrained Management: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0July 20= 14


A.3. =C2=A0draft-ersue-constrained-mgmt-03 - draft-ersue-opsaw= g-coman-use-
=C2=A0 =C2=A0 =C2=A0 cases-00

= =C2=A0 =C2=A0o =C2=A0Reduced the term= inology section for terminology addressed in the
=C2=A0 =C2=A0 =C2=A0 LWIG and Co= man Requirements drafts. =C2=A0Referenced the other drafts.

=C2=A0 =C2=A0o =C2=A0Checked and aligned all termi= nology against the LWIG terminology
=C2=A0 =C2=A0 =C2=A0 draft.

=C2=A0 =C2=A0o =C2=A0Spent some effort = to resolve the intersection between the
=C2=A0 =C2=A0 =C2=A0 Industrial = Application, Home Automation and Building Automation
=C2=A0 =C2=A0 =C2=A0 use cases.

=C2=A0 =C2=A0o =C2= =A0Moved section section 3. =C2=A0Use Cases from the companion document
=C2=A0 =C2=A0 =C2=A0 [C= OM-REQ] to this draft.

=C2=A0 =C2=A0o =C2=A0Reformulation of some text part= s for more clarity.
=
A.4. =C2=A0draft-ersue-constrain= ed-mgmt-02-03

=C2=A0 =C2=A0o =C2=A0= Extended the terminology section and removed some of the
=C2=A0 =C2=A0 =C2=A0 terminology= addressed in the new LWIG terminology draft.
=C2=A0 =C2=A0 =C2=A0 Referenced the LWIG termin= ology draft.

=C2=A0 =C2=A0o =C2= =A0Moved Section 1.3. on Constrained Device Classes to the new LWIG<= /div>
=C2=A0 =C2=A0 =C2=A0 termin= ology draft.

=C2=A0 =C2=A0o =C2= =A0Class of networks considering the different type of radio and
=C2=A0 =C2=A0 =C2=A0 communica= tion technologies in use and dimensions extended.

=C2=A0 =C2=A0o =C2=A0Extended the Problem State= ment in Section 2. following the
=C2=A0 =C2=A0 =C2=A0 requirements listed in Section 4.<= /div>

=C2=A0 =C2=A0o =C2=A0Following requirements, wh= ich belong together and can be realized
=C2=A0 =C2=A0 =C2=A0 with similar or same kind of solut= ions, have been merged.

=C2=A0 =C2=A0 =C2=A0 * =C2=A0Distributed Manage= ment and Peer Configuration,

=C2=A0 =C2=A0 =C2=A0 * =C2=A0Dev= ice status monitoring and Neighbor-monitoring,

=C2=A0 =C2=A0 =C2=A0 * =C2=A0Passive Monitoring and Reactive M= onitoring,

=C2=A0 =C2=A0 =C2=A0 * =C2=A0Event-driven self-= management - Self-healing and Periodic self-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0management,

=C2=A0 =C2=A0 =C2=A0 * =C2=A0Authentication of = management systems and Authentication of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0managed devices,



Ersue, et al. =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 [Page 23]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0Constrained = Management: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0July 2014


=C2=A0 =C2=A0 =C2=A0 * =C2=A0Access control on devices and Acc= ess control on management
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0systems,

=C2=A0 =C2=A0 =C2=A0 * = =C2=A0Management of Energy Resources and Data models for energy
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0management,

<= /font>
=C2=A0 =C2=A0 =C2=A0= * =C2=A0Software distribution (group-based firmware update) and Group-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0based provisioning.

=C2=A0 =C2= =A0o =C2=A0Deleted the empty section on the gaps in network management
=C2=A0 =C2=A0 =C2=A0 standards, = as it will be written in a separate draft.

=C2=A0 =C2=A0o =C2=A0Added links to mentioned external pages.

=C2=A0 =C2=A0o =C2=A0Added text on OMA M2M Devi= ce Classification in appendix.

A.5. =C2=A0draft-ersue-constrain= ed-mgmt-01-02

=C2=A0 =C2=A0o =C2=A0= Extended the terminology section.

=C2=A0 =C2=A0o =C2=A0Added additional text for = the use cases concerning deployment
=C2=A0 =C2=A0 =C2=A0 type, network topology in use, network= size, network capabilities,
=C2=A0 =C2=A0 =C2=A0 radio techn= ology, etc.

=C2=A0 =C2=A0o =C2=A0Ad= ded examples for device classes in a use case.

=C2=A0 =C2=A0o =C2=A0Added additional text prov= ided by Cao Zhen (China Mobile) for
=C2=A0 =C2=A0 =C2=A0 Mobile Applications and by Peter van d= er Stok for Building
=C2=A0 =C2=A0 =C2=A0 Automation.=

=C2=A0 =C2=A0o =C2=A0Added the new= use cases 'Advanced Metering Infrastructure' and
=C2=A0 =C2=A0 =C2=A0 'MANET = Concept of Operations in Military'.

=C2=A0 =C2=A0o =C2=A0Added the section 'Managing the Constrainedne= ss of a Device or
=C2=A0 =C2=A0 =C2=A0 Network'= ; discussing the needs of very constrained devices.

=C2=A0 =C2=A0o =C2=A0Added a note that the requirements in= [COM-REQ] need to be seen as
=C2=A0 =C2=A0 =C2=A0 standalone = requirements and the current document does not
=C2=A0 =C2=A0 =C2=A0 recommend any profile of r= equirements.

=C2=A0 =C2=A0o =C2= =A0Added a section in [COM-REQ] for the detailed requirements on
=C2=A0 =C2=A0 =C2=A0 constrain= ed management matched to management tasks like fault,
=C2=A0 =C2=A0 =C2=A0 monitoring,= configuration management, Security and Access Control,
=C2=A0 =C2=A0 =C2=A0 Energy Management,= etc.

=C2=A0 =C2=A0o =C2= =A0Solved nits and added references.




Er= sue, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires January 5, 201= 5 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 24]
=0C
Internet-Draft =C2= =A0 =C2=A0 =C2=A0Constrained Management: Use Cases =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0July 2014
=

=C2=A0 =C2=A0o =C2= =A0Added Appendix B on the work in related research projects.
<= div>
A.6. =C2=A0draft-ersue-constrained-mgmt-00-01

=C2=A0 =C2=A0o =C2=A0Splitted the section on &#= 39;Networks of Constrained Devices' into the
=C2=A0 =C2=A0 =C2=A0 sections 'Network Top= ology Options' and 'Management Topology
=C2=A0 =C2=A0 =C2=A0 Options'= ;.

=
=C2=A0 =C2=A0o =C2=A0Added the u= se case 'Community Network Applications' and 'Mobile
=C2=A0 =C2=A0 =C2=A0 Application= s'.

<= /div>
=C2=A0 =C2=A0o =C2=A0Provid= ed a Contributors section.

=C2=A0 =C2=A0o =C2=A0Extended the section on &#= 39;Medical Applications'.

=C2=A0 =C2=A0o =C2=A0Solved nits= and added references.

Authors'= Addresses

=C2=A0 =C2=A0Mehmet Ersue (editor)
=
=C2=A0 =C2=A0Nokia Networks

=C2=A0 =C2=A0Email:= mehmet.ersue@nsn= .com

=

=C2=A0 =C2=A0Dan Ro= mascanu
=C2=A0 =C2= =A0Avaya

=
=C2=A0 =C2=A0Email: dromasca@avaya.com


=C2=A0 =C2=A0Juergen Schoenwaelder
=C2=A0 =C2=A0Jacobs University Bremen



=C2=A0 =C2=A0Anuj Sehgal
=C2=A0 =C2=A0Jacobs University Bremen

=C2=A0 =C2=A0Email: s.anuj@jacobs-university.de










Ersue, et al. =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0Expires January 5, 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 [Page 25]


--089e0103ed82a4fcc505004e8335-- From nobody Sun Aug 10 16:09:18 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B761A0176; Sun, 10 Aug 2014 16:08:55 -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 JAHbMpvELfTE; Sun, 10 Aug 2014 16:08:54 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 037961A0184; Sun, 10 Aug 2014 16:08:53 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id y10so9768172pdj.14 for ; Sun, 10 Aug 2014 16:08:53 -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=iHHEOM4DmLGstsKK4DUk88loMo24SrB7Tet3JZMDEgU=; b=tOHf6iP7TN5zTAG4/y+g2PsG7dAayX02X6XgwhmnTJkA3ra5hWvDKdcUvi+Aa03+pb MHkZ5/xApkHagPKCfzEx9oI72Kk8XUgm7666IMMAPQqXaCwMt6zBVVjc3CWya2U9fmFk stq/TQ7fatIhbVNkSSDxDDiWqryg2uxrVhUmVclE+iwjE9+xavyGbdlsbtYMQqhTZwiz tUY0CCu9VksVODw9DfqFNuOf749dLUiAr5NR7fJiVfU6ZEn448ouUkBMeaIz3NyBEJZD uiSWejYtDuXHzZDR3jbEP9MKwM+KEBWH6p8eOCeYL8238UFTTxBp4mMyW6D3RWHpuczd ajlA== X-Received: by 10.70.88.15 with SMTP id bc15mr18583913pdb.63.1407712133603; Sun, 10 Aug 2014 16:08:53 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.144.1 with HTTP; Sun, 10 Aug 2014 16:08:33 -0700 (PDT) In-Reply-To: References: <59DBFA6B-93BD-4675-9DC6-580598517EC8@tzi.org> From: Thomas Watteyne Date: Sun, 10 Aug 2014 16:08:33 -0700 X-Google-Sender-Auth: xtMF9OgJ-Nak-Q2YG9YTxBCY-5I Message-ID: To: opsawg , "6tisch@ietf.org" <6tisch@ietf.org> Content-Type: multipart/alternative; boundary=001a11c21f0eab679d05004e851e Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/OXo-INk5GV_Y_VmELVIhBFmqGqw Subject: Re: [OPSAWG] Thomas' review of draft-ietf-opsawg-coman-probstate-reqs-02 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2014 23:08:55 -0000 --001a11c21f0eab679d05004e851e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable [resending CC'ing 6TiSCH ML] On Sun, Aug 10, 2014 at 3:01 PM, Thomas Watteyne wrote: > +1 > > Thanks Carsten for the suggestions. > > > On Sun, Aug 10, 2014 at 1:59 PM, Carsten Bormann wrote: > >> On 10 Aug 2014, at 09:18, Thomas Watteyne >> wrote: >> >> > As such, it is not a traditional requirement document, as does not lis= t >> requirements as MUSTs and SHOULDs, but rather gives a clear overview of >> what those requirements might be. In that sense, I would suggest to not = use >> the term "Requirements" in the title, but maybe "potential requirements= =E2=80=9D. >> >> Objectives? >> (That is a term that has turned out useful in other IETF work.) >> >> Desiderata? >> (A term that seems to be popular in CFRG right now, which also is trying >> to collect some soft form of requirements.) >> >> Gr=C3=BC=C3=9Fe, Carsten >> >> > --001a11c21f0eab679d05004e851e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[resending CC'ing 6TiSCH ML]


On Sun, Aug 10, 2014 at 3:01 = PM, Thomas Watteyne <watteyne@eecs.berkeley.edu> wr= ote:
+1

Thank= s Carsten for the suggestions.


On Sun, Aug 1= 0, 2014 at 1:59 PM, Carsten Bormann <cabo@tzi.org> wrote:
On 10 Aug 2014, at 09:18, Thomas Wattey= ne <watt= eyne@eecs.berkeley.edu> wrote:

> As such, it is not a traditional requirement document, as does not lis= t requirements as MUSTs and SHOULDs, but rather gives a clear overview of w= hat those requirements might be. In that sense, I would suggest to not use = the term "Requirements" in the title, but maybe "potential r= equirements=E2=80=9D.

Objectives?
(That is a term that has turned out useful in other IETF work.)

Desiderata?
(A term that seems to be popular in CFRG right now, which also is trying to= collect some soft form of requirements.)

Gr=C3=BC=C3=9Fe, Carsten



--001a11c21f0eab679d05004e851e-- From nobody Sun Aug 10 20:21:36 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4E5C1A0298 for ; Sun, 10 Aug 2014 20:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.222 X-Spam-Level: **** X-Spam-Status: No, score=4.222 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_44=0.6, MANGLED_TOOL=2.3] 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 sqS5mmqvoOhc for ; Sun, 10 Aug 2014 20:21:25 -0700 (PDT) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F0BA1A0296 for ; Sun, 10 Aug 2014 20:21:25 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id lf12so10741195vcb.40 for ; Sun, 10 Aug 2014 20:21:24 -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=VykNLPkmHHvM5bJJDZ/M0Uvz1iT7BFE+T1ZUkMHJ3BE=; b=cspQfOlLuDjP8zaDT6YxbdUHGI+PjcSO7nOlStf2nA+s9ACUEjn6CipibNMAZbyh8M fCLcFH9pYVDBincmbwU5U5h8Hx/RGte+PO4Q3SFUtBhb652FuPbb2b7iGFmeCWMU4i42 GRb9XBrST3GJRZei+poUcvNub1vPMX/ndvlsA= 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=VykNLPkmHHvM5bJJDZ/M0Uvz1iT7BFE+T1ZUkMHJ3BE=; b=W0gMCuuCw+NsRCtt4sN1A5bHsDfUxX9XmqqwicGJeYa1BGhUqhxVgdFzAZ2fehokk3 fKIgtPB3ueKxtmOvxR1x57QRQuouopbmN+8aUtwPrbJa0E5+oWa9iKLZu4sQbSpa6+at JgkTbR5po0b1Un1TE5DlVKsn0CpE5eajXqgWUs8+TbBPsJ9J7z/nJ9DTJN+P4unvLlTt P1P1SrAILxna5utaASnfN8e+WS7WCvIAQso4OVDZ2/cOQYZOM0tSvLvx9fAjup6q9c7F B+reZr2ycehnyLZ6vdlwp27gYsLFIvnE8ARtTezwiUMgfF9rOdY7cDnOOAOO4QkA69iY 5cKg== X-Gm-Message-State: ALoCoQkFh4z9HkKi+C22rHqw6/iwqh9Hn6ZDK+c+1GGUWUQ0nPXiBuLVVHIxTtXS1lqnGMI/Zq40 MIME-Version: 1.0 X-Received: by 10.220.74.10 with SMTP id s10mr3019595vcj.61.1407727284109; Sun, 10 Aug 2014 20:21:24 -0700 (PDT) Received: by 10.220.70.196 with HTTP; Sun, 10 Aug 2014 20:21:23 -0700 (PDT) In-Reply-To: References: Date: Sun, 10 Aug 2014 20:21:23 -0700 Message-ID: From: Ulrich Herberg To: Thomas Watteyne Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/6H-pJPDVKpRGrCZ9YiKnfZSqmZs Cc: opsawg Subject: Re: [OPSAWG] Thomas' review of draft-ietf-opsawg-coman-probstate-reqs-02 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 03:21:34 -0000 Thomas and others have provided very good reviews of both "COMAN" drafts, and I agree with many of the comments (in particular with Thomas' suggestion to stress that this is not a "formal" requirements draft). I support publication of both drafts after the reviews have been sufficiently addressed. Regards Ulrich On Sun, Aug 10, 2014 at 12:18 AM, Thomas Watteyne wrote: > I was asked to do a detailed review of > draft-ietf-opsawg-coman-probstate-reqs-02. > > This is related to my review of draft-ietf-opsawg-coman-use-cases-02, see > http://www.ietf.org/mail-archive/web/opsawg/current/msg03486.html. > > Thomas > > GENERAL > --------------- > > In general, I believe that this is a very useful document to have, and it > provides a very clear list of "possible requirements". > > As such, it is not a traditional requirement document, as does not list > requirements as MUSTs and SHOULDs, but rather gives a clear overview of what > those requirements might be. In that sense, I would suggest to not use the > term "Requirements" in the title, but maybe "potential requirements". > > I imagine that, when the time comes to design a management protocol for > constrained devices (CoAP-based RESTCONF?), there will be a "formal" > requirements draft for that full of MUSTs and SHOULDs? I would certainly > recommend to indicate this clearly in the text. > > DETAILED > --------------- > > please find my comments below, prefixed by "^TW>" > > > > > > Internet Engineering Task Force M. Ersue, Ed. > Internet-Draft Nokia Networks > Intended status: Informational D. Romascanu > Expires: January 5, 2015 Avaya > J. Schoenwaelder > Jacobs University Bremen > July 4, 2014 > > > TW> you could put some newlines in the title > > Management of Networks with Constrained Devices: Problem Statement and > Requirements > draft-ietf-opsawg-coman-probstate-reqs-02 > > Abstract > > This document provides a problem statement, deployment and management > topology options as well as the requirements for the management of > TW> why not simple networks of constrained devices? > networks where constrained devices are involved. > > Status of This Memo > > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is at http://datatracker.ietf.org/drafts/current/. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > This Internet-Draft will expire on January 5, 2015. > > Copyright Notice > > Copyright (c) 2014 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > > > > Ersue, et al. Expires January 5, 2015 [Page 1] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > the Trust Legal Provisions and are provided without warranty as > described in the Simplified BSD License. > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 > 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 > 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 > 1.3. Network Types and Characteristics in Focus . . . . . . . 5 > 1.4. Constrained Device Deployment Options . . . . . . . . . . 9 > 1.5. Management Topology Options . . . . . . . . . . . . . . . 9 > 1.6. Managing the Constrainedness of a Device or Network . . . 10 > 1.7. Configuration and Monitoring Functionality Levels . . . . 13 > 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 14 > 3. Requirements on the Management of Networks with Constrained > Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 > 3.1. Management Architecture/System . . . . . . . . . . . . . 17 > 3.2. Management protocols and data model . . . . . . . . . . . 21 > 3.3. Configuration management . . . . . . . . . . . . . . . . 24 > 3.4. Monitoring functionality . . . . . . . . . . . . . . . . 26 > 3.5. Self-management . . . . . . . . . . . . . . . . . . . . . 31 > 3.6. Security and Access Control . . . . . . . . . . . . . . . 31 > 3.7. Energy Management . . . . . . . . . . . . . . . . . . . . 33 > 3.8. SW Distribution . . . . . . . . . . . . . . . . . . . . . 35 > 3.9. Traffic management . . . . . . . . . . . . . . . . . . . 36 > 3.10. Transport Layer . . . . . . . . . . . . . . . . . . . . . 37 > 3.11. Implementation Requirements . . . . . . . . . . . . . . . 39 > 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 > 5. Security Considerations . . . . . . . . . . . . . . . . . . . 40 > 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 41 > 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41 > 8. Informative References . . . . . . . . . . . . . . . . . . . 41 > Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 42 > A.1. draft-ietf-opsawg-coman-probstate-reqs-01 - draft-ietf- > opsawg-coman-probstate-reqs-02 . . . . . . . . . . . . . 42 > A.2. draft-ietf-opsawg-coman-probstate-reqs-00 - draft-ietf- > opsawg-coman-probstate-reqs-01 . . . . . . . . . . . . . 42 > A.3. draft-ersue-constrained-mgmt-03 - draft-ietf-opsawg- > coman-probstate-reqs-00 . . . . . . . . . . . . . . . . . 43 > A.4. draft-ersue-constrained-mgmt-02-03 . . . . . . . . . . . 43 > A.5. draft-ersue-constrained-mgmt-01-02 . . . . . . . . . . . 44 > A.6. draft-ersue-constrained-mgmt-00-01 . . . . . . . . . . . 45 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 > > > > > > > > > Ersue, et al. Expires January 5, 2015 [Page 2] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > 1. Introduction > > 1.1. Overview > > Constrained devices, aka. sensor, smart object, or smart device, with > limited CPU, memory, and power resources, can constitute a network. > Such a network of constrained devices itself may be constrained or > challenged, e.g., with unreliable or lossy channels, wireless > technologies with limited bandwidth and a dynamic topology, needing > TW> please add energy limitations > the service of a gateway or proxy to connect to the Internet. In > other scenarios, the constrained devices can be connected to a non- > constrained network using off-the-shelf protocol stacks. > > Constrained devices might be in charge of gathering information in > diverse settings including natural ecosystems, buildings, and > TW> factories*,* and > factories and send the information to one or more server stations. > Constrained devices may also work under severe resource constraints > such as limited battery and computing power, little memory and > insufficient wireless bandwidth, and communication capabilities. A > central entity, e.g., a base station or controlling server, might > have more computational and communication resources and can act as a > gateway between the constrained devices and the application logic in > the core network. > > Today diverse size of constrained devices with different resources > and capabilities are being connected. Mobile personal gadgets, > building-automation devices, cellular phones, Machine-to-machine > (M2M) devices, etc. benefit from interacting with other "things" in > the near or somewhere in the Internet. With this the Internet of > TW> reality build -> reality, built > Things (IoT) becomes a reality build up of uniquely identifiable > objects (things). And over the next decade, this could grow to > TW> wow, that's 3 orders of magnitude more than people. I see wild > predictions > TW> going to tens of billions, but not thousands. Maybe "billions"? > trillions of constrained devices and will greatly increase the > Internet's size and scope. > > Network management is characterized by monitoring network status, > detecting faults, and inferring their causes, setting network > parameters, and carrying out actions to remove faults, maintain > normal operation, and improve network efficiency and application > performance. The traditional network monitoring application > periodically collects information from a set of elements that are > TW> to manage, to process [...] to present > needed to manage, processes the data, and presents them to the > network management users. Constrained devices, however, often have > TW> please specify unreliable. I would say that they may be inter-connected > TW> through unreliable links to one another, and to the Internet > limited power, low transmission range, and might be unreliable. They > might also need to work in hostile environments with advanced > security requirements or need to be used in harsh environments for a > long time without supervision. Due to such constraints, the > TW> typo type*s* > management of a network with constrained devices faces different type > of challenges compared to the management of a traditional IP network. > > > > Ersue, et al. Expires January 5, 2015 [Page 3] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > The IETF has already done substantial standardization work to enable > the communication in IP networks and to manage such networks as well > as the manifold type of nodes in these networks [RFC6632]. However, > the IETF so far has not developed any specific technologies for the > management of constrained devices and the networks comprised by > constrained devices. IP-based sensors or constrained devices in such > an environment, i.e., devices with very limited memory and CPU > TW> please add energy > TW> use today*'s* > resources, use today application-layer protocols in an ad-hoc manner > to do simple resource management and monitoring. > > This document provides a problem statement and lists the requirements > for the management of a network with constrained devices. > Section 1.3 and Section 1.5 describe different topology options for > the networking and management of constrained devices. Section 2 > provides a problem statement on the issue of the management of > networked constrained devices. Section 3 lists requirements on the > management of applications and networks with constrained devices. > Note that the requirements listed in Section 3 have been separated > from the context in which they may appear. > TW> Hmm. poipoi TODO > Depending on the concrete > circumstances, an implementer may decide to address a certain > relevant subset of the requirements. > > The use cases in the context of networks with constrained devices can > be found in the companion document [COM-USE]. > > 1.2. Terminology > > Concerning constrained devices and networks this document generally > builds on the terminology defined in [RFC7228], where the terms > Constrained Device, Constrained Network, etc. are defined. > > The following terms are additionally used throughout this > documentation: > > AMI: (Advanced Metering Infrastructure) A system including hardware, > software, and networking technologies that measures, collects, and > analyzes energy usage, and communicates with a hierarchically > deployed network of metering devices, either on request or on a > schedule. > > C0: Class 0 constrained device as defined in Section 3. of > [RFC7228]. > > C1: Class 1 constrained device as defined in Section 3. of > [RFC7228]. > > C2: Class 2 constrained device as defined in Section 3. of > [RFC7228]. > > > > Ersue, et al. Expires January 5, 2015 [Page 4] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > Network of Constrained Devices: A network to which constrained > devices are connected that may or may not be a Constrained Network > (see [RFC7228] for the definition of the term Constrained > Network). > > M2M: (Machine to Machine) stands for the automatic data transfer > between devices of different kind. In M2M scenarios a device > (such as a sensor or meter) captures an event, which is relayed > through a network (wireless, wired or hybrid) to an application. > > MANET: Mobile Ad-hoc Networks [RFC2501], a self-configuring and > infrastructureless network of mobile devices connected by wireless > technologies. > > Smart Grid: An electrical grid that uses communication technologies > to gather and act on information in an automated fashion to > improve the efficiency, reliability and sustainability of the > production and distribution of electricity. > > Smart Meter: An electrical meter in the context of a Smart Grid. > > For a detailed discussion on the constrained networks as well as > classes of constrained devices and their capabilities please see > [RFC7228]. > > 1.3. Network Types and Characteristics in Focus > > In this document we differentiate following types of networks > concerning their transport and communication technologies: > > (Note that a network in general can involve constrained and non- > constrained devices.) > > 1. Wireline non-constrained networks, e.g., an Ethernet-LAN with > constrained and non-constrained devices involved. > > 2. A combination of wireline and wireless networks, possibly with a > multi-hop connectivity between constrained devices, utilizing > dynamic routing in both the wireless and wireline portions of the > network. Such networks usually support highly distributed > applications with many nodes (e.g., environmental monitoring) and > tend to deal with large-scale multipoint-to-point systems. > Wireless Mesh Networks (WMN), as a specific variant, use off-the- > shelf radio technology such as Wi-Fi, WiMax, and cellular 3G/4G. > WMNs are reliable based on the redundancy they offer and have > often a more planned deployment to provide dynamic and cost > effective connectivity over a certain geographic area. > > > > > Ersue, et al. Expires January 5, 2015 [Page 5] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > 3. A combination of wireline and wireless networks with point-to- > point or point-to-multipoint communication generally with single- > TW> Hmm. The statement that IEEE802.15.4 networks are generally single-hop > and > TW> involve static routing contradicts the work done in ROLL and 6LoWPAN, > 6lo > TW> and 6TiSCH. Consider removing? > hop connectivity to constrained devices, utilizing static routing > over the wireless network. Such networks support short-range, > point-to-point, low-data-rate, source-to-sink type of > applications such as RFID systems, light switches, fire and smoke > detectors, and home appliances. This type of networks also > support confined short-range spaces such as a home, a factory, a > building, or the human body. IEEE 802.15.1 (Bluetooth) and IEEE > 802.15.4 are well-known examples of applicable standards for such > networks. > > 4. Self-configuring infrastructureless networks of mobile devices > (e.g., Mobile Adhoc networks, MANET) are a particular type of > network connected by wireless technologies. Infrastructureless > networks are mostly based on point-to-point communications of > devices moving independently in any direction and changing the > links to other devices frequently. Such devices do act as a > router to forward traffic unrelated to their own use. > > Wireline non-constrained networks with constrained and non- > constrained devices are mainly used for specific applications like > Building Automation or Infrastructure Monitoring. Wireline and > wireless networks with multi-hop or point-to-multipoint connectivity > are used e.g., for environmental monitoring as well as transport and > mobile applications. > TW> add industrial applications for the latter (e.g. WirelessHART, 6TiSCH) > > Furthermore different network characteristics are determined by > multiple dimensions: dynamicity of the topology, bandwidth, and loss > rate. In the following, each dimension is explained, and networks in > scope for this document are outlined: > > TW> I don't quite understand why this draft introduces so many terms, > TW> networking topologies, etc. Can it not simply references a number of > RFCs? > TW> RFC5867, RFC5826, RFC5673, RFC5548 seem to give a good overview of LLN > TW> use cases > > Network Topology: > > The topology of a network can be represented as a graph, with edges > (i.e., links) and vertices (routers and hosts). Examples of > different topologies include "star" topologies (with one central node > and multiple nodes in one hop distance), tree structures (with each > node having exactly one parent), directed acyclic graphs (with each > node having one or more parents), clustered topologies (where one or > more "cluster heads" are responsible for a certain area of the > network), mesh topologies (fully distributed), etc. > > Management protocols may take advantage of specific network > topologies, for example by distributing large-scale management tasks > amongst multiple distributed network management stations (e.g., in > TW> wouldn't cluster-based topologies not be a better fit here? > case of a mesh topology), or by using a hierarchical management > > > > > Ersue, et al. Expires January 5, 2015 [Page 6] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > approach (e.g., in case of a tree topology). These different > management topology options are described in Section 1.6. > > Note that in certain network deployments, such as community ad hoc > networks (see the use case "Community Network Applications" in [COM- > USE]), the topology is not pre-planned, and thus may be unknown for > management purposes. In other use cases, such as industrial > applications (see the use case "Industrial Applications" in [COM- > USE]), the topology may be designed in advance and therefore taken > advantage of when managing the network. > > Dynamicity of the network topology: > > The dynamicity of the network topology determines the rate of change > TW> per time -> as a function of time > of the graph per time. Such changes can occur due to different > factors, such as mobility of nodes (e.g., in MANETs or cellular > networks), duty cycles (for low-power devices enabling their network > interface only periodically to transmit or receive packets), or > unstable links (in particular wireless links with strongly > fluctuating link quality). > > Examples of different levels of dynamicity of the topology are > Ethernets (with typically a very static topology) on the one side, > and low-power and lossy networks (LLNs) on the other side. LLNs > TW> LLN nodes often using duty cycles -> LLN nodes are often duty-cycled > nodes often using duty cycles, operate on unreliable wireless links > and are potentially mobile (e.g., for sensor networks). > > TW> "The more dynamic the topology is" > The more the topology is dynamic, the more routing, transport and > application layer protocols have to cope with interrupted > connectivity and/or longer delays. For example, management protocols > (with a given underlying transport protocol) that expect continuous > session flows without changes of routes during a communication flow, > may fail to operate. > > Networks with a very low dynamicity (e.g., Ethernet) with no or > infrequent topology changes (e.g., less than once every 30 minutes), > are in-scope of this document if they are used with constrained > devices (see e.g., the use case "Building Automation" in [COM-USE]). > > Traffic flows: > > The traffic flow in a network determines from which sources data > traffic is sent to which destinations in the network. Several > different traffic flows are defined in [RFC7102], including "point- > to-point" (P2P), "multipoint-to-point" (MP2P), and "point-to- > multipoint" (P2MP) flows as: > > > > > > Ersue, et al. Expires January 5, 2015 [Page 7] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > TW> add dashes, i.e. "Point-To-Point"? > o P2P: Point To Point. This refers to traffic exchanged between two > nodes (regardless of the number of hops between the two nodes). > > o P2MP: Point-to-Multipoint traffic refers to traffic between one > node and a set of nodes. This is similar to the P2MP concept in > Multicast or MPLS Traffic Engineering. > > o MP2P: Multipoint-to-Point is used to describe a particular traffic > pattern (e.g., MP2P flows collecting information from many nodes > flowing inwards towards a collecting sink). > > If one of these traffic patterns is predominant in a network, > protocols (routing, transport, application) may be optimized for the > specific traffic flow. For example, in a network with a tree > topology and MP2P traffic, collection tree protocols are efficient to > send data from the leaves of the tree to the root of the tree, via > each node's parent. > > Bandwidth: > > The bandwidth of the network is the amount of data that can be sent > TW> per *unit of* time? > per time between two communication end-points. It is usually > determined by the link with the minimum bandwidth on the path from > the source to the destination of data packets. The bandwidth in > networks can range from a few Kilobytes per second (such as on some > 802.15.4 link layers) to many Gigabytes per second (e.g., on fiber > optics). > > For management purposes, the management protocol typically requires > to send information between the network management station and the > clients, for monitoring or control purposes. If the available > bandwidth is insufficient for the management protocol, packets will > be buffered and eventually dropped, and thus management is not > possible with such a protocol. > > Networks without bandwidth limitation (e.g., Ethernet) are in-scope > of this document if they are used with constrained devices (see the > use case "Building Automation" in [COM-USE]). > > Loss rate: > > The loss rate (or bit error rate) is the number of bit errors divided > by the total number of bits transmitted. For wired networks, loss > rates are typically extremely low, e.g., around 10^-12 or 10^-13 for > the latest 10Gbit Ethernet. For wireless networks, such as 802.15.4, > the bit error rate can be as high as 10^-1 to 10^-0 in case of > TW> missing space below > interferences.Even when using a reliable transport protocol, > > > > > Ersue, et al. Expires January 5, 2015 [Page 8] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > management operations can fail if the loss rate is too high, unless > they are specifically designed to cope with these situations. > > 1.4. Constrained Device Deployment Options > > We differentiate following deployment options for the constrained > devices: > > o A network of constrained devices that communicate with each other, > > o Constrained devices, which are connected directly to an IP > network, > > o A network of constrained devices which communicate with a gateway > or proxy with more communication capabilities acting possibly as a > representative of the device to entities in the non-constrained > network > > o Constrained devices, which are connected to the Internet or an IP > network via a gateway/proxy > > o A hierarchy of constrained devices, e.g., a network of C0 devices > connected to one or more C1 devices - connected to one or more C2 > devices - connected to one or more gateways - connected to some > application servers or NMS system > > o The possibility of device grouping (possibly in a dynamic manner) > such as that the grouped devices can act as one logical device at > the edge of the network and one device in this group can act as > the managing entity > > 1.5. Management Topology Options > > We differentiate following options for the management of networks of > constrained devices: > > o A network of constrained devices managed by one central manager. > A logically centralized management might be implemented in a > hierarchical fashion for scalability and robustness reasons. The > manager and the management application logic might have a gateway/ > proxy in between or might be on different nodes in different > networks, e.g., management application running on a cloud server. > > o Distributed management, where a network of constrained devices is > managed by more than one manager. Each manager controls a > TW> subnet is a very loaded word. Maybe refer to "a portion of the network"? > subnetwork and may communicate directly with other manager > stations in a cooperative fashion. The distributed management may > be weakly distributed, where functions are broken down and > > > > Ersue, et al. Expires January 5, 2015 [Page 9] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > assigned to many managers dynamically, or strongly distributed, > where almost all managed things have embedded management > functionality and explicit management disappears, which usually > comes with the price that the strongly distributed management > logic now needs to be managed. > > o Hierarchical management, where a hierarchy of networks with > constrained devices are managed by the managers at their > corresponding hierarchy level. I.e., each manager is responsible > for managing the nodes in its sub-network. It passes information > from its sub-network to its higher-level manager, and disseminates > management functions received from the higher-level manager to its > sub-network. Hierarchical management is essentially a scalability > mechanism, logically the decision-making may be still centralized. > > poipoipoi > > 1.6. Managing the Constrainedness of a Device or Network > > The capabilities of a constrained device or network and the > constrainedness thereof influence and have an impact on the > requirements for the management of such network or devices. > > Note that the list below gives examples and does not claim > completeness. > > A constrained device: > > TW> Strictly speaking, the radios are reliable, but the links are lossy > TW> Maybe rephrase to "are connected by radio links which are unreliably in > TW> nature" > o might only support an unreliable radio with lossy links, i.e., the > client and server of a management protocol need to gracefully > TW> In my experience, packet corruption is caught at several layers > throughout > TW> the stack, and I doubt it is possible for the management protocol to > TW> receive "incomplete" commands. Maybe I'm missing something. > TW> With unreliable links, I believe the management protocol needs to > TW> gracefully handle changes in latency, timeouts and retransmissions. > ignore incomplete commands or repeat commands as necessary. > > o might only be able to go online from time-to-time, where it is > reachable, i.e., a command might be necessary to repeat after a > longer timeout or the timeout value with which one endpoint waits > on a response needs to be sufficiently high. > > o might only be able to support a limited operating time (e.g., > based on the available battery), or may behave as 'sleepy > endpoints' setting their network links to a disconnected state > during long periods of time i.e., the devices need to economize > their energy usage with suitable mechanisms and the managing > entity needs to monitor and control the energy status of the > constrained devices it manages. > > o might only be able to support one simple communication protocol, > i.e., the management protocol needs to be possible to downscale > from constrained (C2) to very constrained (C0) devices with > modular implementation and a very basic version with just a few > simple commands. > > > > Ersue, et al. Expires January 5, 2015 [Page 10] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > o might only be able to support limited or no user and/or transport > security, i.e., the management system needs to support a less- > costly and simple but sufficiently secure authentication > mechanism. > > o might not be able to support compression and decompression of > exchanged data based on limited CPU power, i.e., an intermediary > entity which is capable of data compression should be able to > communicate with both, devices that support data compression > (e.g., C2) and devices that do not support data compression (e.g., > C1 and C0). > > o might only be able to support a simple encryption, i.e., it would > be beneficial if the devices use cryptographic algorithms that are > supported in hardware and the encryption used is efficient in > TW> typo memeory -> memory > terms of memeory and CPU usage. > > o might only be able to communicate with one single managing entity > and cannot support the parallel access of many managing entities. > > o might depend on a self-configuration feature, i.e., the managing > entity might not know all devices in a network and the device > needs to be able to initiate connection setup for the device > configuration. > > o might depend on self- or neighbor-monitoring feature, i.e., the > managing entity might not be able to monitor all devices in a > network continuously. > > o might only be able to communicate with its neighbors, i.e., the > device should be able to get its configuration from a neighbor. > > o might only be able to support parsing of data models with limited > size, i.e., the device data models need to be compact containing > the most necessary data and if possible parsable as a stream. > > o might only be able to support a limited or no failure detection, > i.e., the managing entity needs to handle the situation, where a > failure does not get detected or gets detected late gracefully > e.g., with asking repeatedly. > > o might only be able to support the reporting of just one or a > limited set failure types. > > o might only be able to support a limited set of notifications, > possible only an "I-am-alive" message. > > o might only be able to support a soft-reset from failure recovery. > > > > Ersue, et al. Expires January 5, 2015 [Page 11] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > o might possibly generate a large amount of redundant reporting > data, i.e., the intermediary management entity (see [RFC7252]) > should be able to filter and aggregate redundant data. > > A network of constrained devices: > > TW> same discussion about the term "unreliable radio" applies here > o might only support an unreliable radio with lossy links, i.e., the > client and server of a management protocol need to repeat commands > as necessary or gracefully ignore incomplete commands. > > o might be necessary to manage based on multicast communication, > i.e., the managing entity needs to be prepared to configure many > devices at once based on the same data model. > > o might have a very large topology supporting 10,000 or more nodes > for some applications and as such node naming is a specific issue > for constrained networks. > > o must be able to self-organize, i.e., given the large number of > nodes and their potential placement in hostile locations and > frequently changing topology, manual configuration of nodes is > TW> As such*,* > typically not feasible. As such the network must be able to > reconfigure itself so that it can continue to operate properly and > support reliable connectivity. > > o needs a management solution that is energy-efficient, using as > little wireless bandwidth as possible since communication is > highly energy demanding. > > TW> while very important in some cases, this seems not to be the general > case. > TW> maybe prefix by "In some cases,"? > o needs to support localization schemes to determine the location of > devices since the devices might be moving and location information > is important for some applications. > > o needs a management solution that is scalable as the network may > consist of thousands of nodes and may need to be extended > continuously. > > o needs to provide fault tolerance. Faults in network operation > including hardware and software errors or failures detected by the > TW> I don't understand "should be handled smoothly enabling" > transport protocol should be handled smoothly enabling. In such a > case it should be possible to run the protocol possibly at a > reduced level but avoiding to fail completely. E.g., self- > monitoring mechanisms or graceful degradation of features can be > used to provide fault tolerance. > > o might require new management capabilities: for example, network > coverage information and a constrained device power-distribution- > map. > > > > Ersue, et al. Expires January 5, 2015 [Page 12] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > o might require a new management function for data management, since > the type and amount of data collected in constrained networks is > different from those of the traditional networks. > > o might also need energy-efficient key management. > > 1.7. Configuration and Monitoring Functionality Levels > > Devices often differ significantly on the level of configuration > management support they provide. This document classifies the > configuration management functionality as follows: > > TW> I have two low-end cases in mind which are believe are commonplace, but > TW> I don't know in which category it fits: > TW> - the device can only bec configured by physically connecting a device > to > TW> it and changing the configuration. This might be a handheld with a > serial > TW> cable. > TW> - the device's configuration is contained in some flash memory card. An > TW> operate reconfigures a device by swapping its configuration card. > > CL0: Devices are pre-configured and allow no runtime configuration > TW> hard coded -> hard-coded? > changes. Configuration parameters are often hard coded and > compiled directly into the firmware image. > > CL1: Devices have explicit configuration objects. However, changes > require a restart of the device to take effect. > > CL2: Devices allow management systems to replace the entire > configuration (or pre-determined subsets) in bulk. Configuration > changes take effect by soft-restarts of the system (or > subsystems). > > CL3: Devices allow management systems to modify configuration > objects without bulk replacements and changes take effect > immediately. > > CL4: Devices support multiple configuration datastores and they > might distinguish between the currently running and the next > startup configuration. > > CL5: Devices support configuration datastore locking and device- > local configuration change transactions, i.e., either all > configuration changes are applied or none of them. > > CL6: Devices support configuration change transactions across > devices. > > This document defines a classification of devices with regards to > different levels of monitoring support. In general a device may be > in several of the levels listed below: > > TW> I have a monitoring use case which I believe to be common, but I > TW> have a hard time seeing to which category it belongs: > TW> - a device logs noteworthy event to a flash drive connected to it. An > TW> operator collects those, and analyzes those logs, possibly much later. > > > ML0: Devices push pre-defined monitoring data. > > ML1: Devices allow management systems to pull pre-defined monitoring > data. > > > > > Ersue, et al. Expires January 5, 2015 [Page 13] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > ML2: Devices allow management systems to pull user-defined filtered > subsets of monitoring data. > > ML3: Devices are able to locally process monitoring data in order to > detect threshold crossings or to aggregate data. > > At the time of this writing, constrained devices often implement a > combination of one of CL0-CL2 with one of ML0-ML1. > > 2. Problem Statement > > The terminology for the "Internet of Things" is still nascent, and > depending on the network type or layer in focus diverse technologies > and terms are in use. Common to all these considerations is the > "Things" or "Objects" are supposed to have physical or virtual > identities using interfaces to communicate. In this context, we need > to differentiate between the Constrained and Smart Devices identified > by an IP address compared to virtual entities such as Smart Objects, > which can be identified as a resource or a virtual object by using a > unique identifier. Furthermore, the smart devices usually have a > limited memory and CPU power as well as aim to be self-configuring > and easy to deploy. > > However, the constraints of the network nodes requires a rethinking > of the protocol characteristics concerning power consumption, > TW> please add network bandwidth > performance, memory, and CPU usage. As such, there is a demand for > protocol simplification, energy-efficient communication, less CPU > TW> small*er*? > usage and small memory footprint. > > On the application layer the IETF is already developing protocols > like the Constrained Application Protocol (CoAP) [RFC7252] enabling > the communication of constrained devices and networks e.g., for smart > energy applications or home automation environments. The deployment > of such an environment involves in fact many, in some scenarios up to > million constrained devices (e.g., smart meters), which produce a > large amount of data. This data needs to be collected, filtered, and > pre-processed for further use in diverse services. > > TW> think on -> think about? > Considering the high number of nodes to deploy, one has to think on > the manageability aspects of the smart devices and plan for easy > deployment, configuration, and management of the networks of > constrained devices as well as the devices themselves. Consequently, > seamless monitoring and self-configuration of such network nodes > becomes more and more imperative. Self-configuration and self- > management is already a reality in the standards of some of the > bodies such as 3GPP. To introduce self-configuration of smart > devices successfully a device-initiated connection establishment is > required. > > TW> In some cases, the management entity might establish connection with a > TW> joining device during commisionning (i.e. wake-up). I don't have a good > TW> example, and I certainly agree that the devices should establish a > TW> connection in most cases, but I would no sat "is required". Maybe "is > often > TW> required"? > > > > Ersue, et al. Expires January 5, 2015 [Page 14] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > A simple and efficient application layer protocol, such as CoAP, is > essential to address the issue of efficient object-to-object > communication and information exchange. Such an information exchange > should be done based on interoperable data models to enable the > exchange and interpretation of diverse application and management > related data. > > In an ideal world, we would have only one network management protocol > for monitoring, configuration, and exchanging management data, > independently of the type of the network (e.g., Smart Grid, wireless > access, or core network). Furthermore, it would be desirable to > derive the basic data models for constrained devices from the core > models used today to enable reuse of functionality and end-to-end > information exchange. However, the current management protocols seem > to be too heavyweight compared to the capabilities the constrained > devices have and are not applicable directly for the use in a network > of constrained devices. Furthermore, the data models addressing the > requirements of such smart devices need yet to be designed. > > The IETF so far has not developed any specific technologies for the > management of constrained devices and the networks comprised by > constrained devices. IP-based sensors or constrained devices in such > an environment, i.e., devices with very limited memory and CPU > resources, use today, e.g., application-layer protocols to do simple > resource management and monitoring. This might be sufficient for > some basic cases, however, there is a need to reconsider the network > management mechanisms based on the new, changed, as well as reduced > requirements coming from smart devices and the network of such > constrained devices. Albeit it is questionable whether we can take > the same comprehensive approach we use in an IP network also for the > management of constrained devices. Hence, the management of a > network with constrained devices is necessary to design in a > simplified and less complex manner. > > TW> typo characterists -> characteristics > As Section 1.6 highlights, there are diverse characterists of > constrained devices or networks, which stem from their > constrainedness and therefore have an impact on the requirements for > the management of such a network with constrained devices. The use > cases discussed in [COM-USE] show that the requirements on > constrained networks are manifold and need to be analyzed from > different angles, e.g., concerning the design of the management > architecture, the selection of the appropriate protocol features as > well as the specific issues which are new in the context of > constrained devices. Examples of such issues are e.g., the careful > management of the scarce energy resources, the necessity for self- > organization and self-management of such devices but also the > implementation considerations to enable the use of common > communication technologies on a constrained hardware in an efficient > > > > Ersue, et al. Expires January 5, 2015 [Page 15] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > manner. For an exhaustive list of issues and requirements that need > to be addressed for the management of a network with constrained > devices please see Section 1.6 and Section 3. > > 3. Requirements on the Management of Networks with Constrained Devices > > This section describes the requirements categorized by management > areas listed in subsections. > > Note that the requirements listed in this section have been separated > from the context in which they may appear. This document in general > does not recommend the realization of any subset of the described > requirements. As such this document avoids selecting any of the > requirements as mandatory to implement. A device might be able to > provide only a particular selected set of requirements and might not > be capable to provide all requirements in this document. On the > other hand a device vendor might select a specific relevant subset of > the requirements to implement. > > TW> *The* following? > Following template is used for the definition of the requirements. > > TW> "An ID uniquely identified" reads strange. Rephrase to "A unique 3-digit > TW> identifier"? > Req-ID: An ID uniquely identified by a three-digit number > > Title: The title of the requirement. > > Description: The rational and description of the requirement. > > Source: The origin of the requirement and the matching use case or > application. For the discussion of referred use cases for > constrained management please see [COM-USE]. > > Requirement Type: Functional Requirement, Non-Functional > Requirement. A functional requirement is related to a function or > component. As such functional requirements may be technical > details, or specific functionality that define what a system is > supposed to accomplish. Non-functional requirements (also known > as design constraints or quality requirements) impose > TW> implementation-related? > implementation related considerations such as performance > requirements, security, or reliability. > > TW> please add RFC reference > Device type: The device types by which this requirement can be > supported: C0, C1 and/or C2. > > TW> I'm a bit surprised the priority depends on the class of device. In my > mind > TW> some requirement are of high priority because they are really needed. > TW> Whether it's implemented on a C0 or C2 shouldn't matter. At the most, > some > TW> requirements cannot be satisfied by low-end devices. > Priority: The priority of the requirement showing its importance for > a particular type of device: High, Medium, and Low. The priority > of a requirement can be High e.g., for a C2 device but Low for a > C1 or C0 device as the realization of complex features in a C1 > device is in many cases not possible. > > > > Ersue, et al. Expires January 5, 2015 [Page 16] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > 3.1. Management Architecture/System > > Req-ID: 1.001 > > Title: Support multiple device classes within a single network. > > Description: Larger networks usually consist of devices belonging to > different device classes (e.g., constrained mesh endpoints and > less constrained routers) communicating with each other. Hence, > the management architecture must be applicable to networks that > have a mix of different device classes. See Section 3. of > [RFC7228] for the definition of Constrained Device Classes. > > Source: All use cases. > > Requirement Type: Non-Functional Requirement > > Device type: C1 and/or C2 > > Priority: High > > --- > > Req-ID: 1.002 > > Title: Management scalability. > > Description: The management architecture must be able to scale with > the number of devices involved and operate efficiently in any > network size and topology. This implies that e.g., the managing > entity is able to handle large amounts of device monitoring data > and the management protocol is not sensitive to the decrease of > the time between two client requests. To achieve good > scalability, caching techniques, in-network data aggregation > techniques, hierarchical management models may be used. > > Source: General requirement for all use cases to enable large scale > networks. > > Requirement Type: Non-Functional Requirement > > Device type: C0, C1, and C2 > > Priority: High > > --- > > Req-ID: 1.003 > > > > Ersue, et al. Expires January 5, 2015 [Page 17] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > Title: Hierarchical management > > Description: Provide a means of hierarchical management, i.e., > provide intermediary management entities on different levels, > which can take over the responsibility for the management of a > sub-hierarchy of the network of constraint devices. The > intermediary management entity can e.g., support management data > aggregation to handle e.g., high-frequent monitoring data or > TW> RFC6550 uses the terms "upward" and "downward". Maybe use those here > too? > provide a caching mechanism for the uplink and downlink > communication. Hierarchical management contributes to management > scalability. > > Source: Use cases where a large amount of devices are deployed with > a hierarchical topology. > > Requirement Type: Non-Functional Requirement > > Device type: Managing and intermediary entities. > > Priority: Medium > > --- > > Req-ID: 1.004 > > Title: Minimize state maintained on constrained devices. > > Description: The amount of state that needs to be maintained on > constrained devices should be minimized. This is important in > order to save memory (especially relevant for C0 and C1 devices) > and in order to allow devices to restart for example to apply > configuration changes or to recover from extended periods of > inactivity. > > Note: One way to achieve this is to adopt a RESTful architecture > that minimizes the amount of state maintained by managed > constrained devices and that makes resources of a device > addressable via URIs. > > Source: Basic requirement which concerns all use cases. > > Requirement Type: Functional Requirement > > Device type: C0, C1, and C2 > > Priority: High > > --- > > > > Ersue, et al. Expires January 5, 2015 [Page 18] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > Req-ID: 1.005 > > Title: Automatic re-synchronization with eventual consistency. > > Description: To support large scale networks, where some constrained > devices may be offline at any point in time, it is necessary to > distribute configuration parameters in a way that allows temporary > inconsistencies but eventually converges, after a sufficiently > long period of time without further changes, towards global > consistency. > > Source: Use cases with large scale networks with many devices. > > Requirement Type: Functional Requirement > > Device type: C0, C1, and C2 > > Priority: High > > --- > > Req-ID: 1.006 > > Title: Support for lossy links and unreachable devices. > > Description: Some constrained devices will only be able to support > lossy and unreliable links characterized by a limited data rate, a > TW> Furthermore*,* > high latency, and a high transmission error rate. Furthermore > constrained devices often duty cycle their radio or the whole > TW> labelled -> labeled > device in order to save energy. Some classes of devices labelled > as 'sleepy endpoints' set their network links to a disconnected > state during long periods of time. In all cases the management > system must not assume that constrained devices are always > reachable. > > Source: Basic requirement for networks of constrained devices with > unreliable links and constrained devices that sleep to save > energy. > > Requirement Type: Non-Functional Requirement > > Device type: C0, C1, and C2 > > Priority: High > > --- > > Req-ID: 1.007 > > > > Ersue, et al. Expires January 5, 2015 [Page 19] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > Title: Network-wide configuration > > Description: Provide means by which the behavior of the network can > be specified at a level of abstraction (network-wide > configuration) higher than a set of configuration information > specific to individual devices. It is useful to derive the device > specific configuration from the network-wide configuration. Such > a repository can be used to configure pre-defined device or > protocol parameters for the whole network. Furthermore, such a > network-wide view can be used to monitor and manage a group of > routers or a whole network. E.g., monitoring the performance of a > network requires additional information other than what can be > acquired from a single router using a management protocol. > > Note: The identification of the relevant subset of the policies to > be provisioned is according to the capabilities of each device and > can be obtained from a pre-configured data-repository. > > Source: In general all use cases of network and device configuration > based on a network view in a top-down manner. > > Requirement Type: Non-Functional Requirement > > Device type: C0, C1, and C2 > > Priority: Medium > > --- > > Req-ID: 1.008 > > Title: Distributed Management > > Description: Provide a means of simple distributed management, where > a network of constrained devices can be managed or monitored by > more than one manager. Since the connectivity to a server cannot > be guaranteed at all times, a distributed approach may provide a > higher reliability, at the cost of increased complexity. This > requirement implies the handling of data consistency in case of > concurrent read and write access to the device datastore. It > might also happen that no management (configuration) server is > accessible and the only reachable node is a peer device. In this > case the device should be able to obtain its configuration from > peer devices. > > Source: Use cases where the count of devices to manage is high. > > Requirement Type: Non-Functional Requirement > > > > Ersue, et al. Expires January 5, 2015 [Page 20] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > Device type: C1 and C2 > > Priority: Medium > > 3.2. Management protocols and data model > > Req-ID: 2.001 > > Title: Modular implementation of management protocols > > Description: Management protocols should be specified to allow for > modular implementations, i.e., it should be possible to implement > only a basic set of protocol primitives on highly constrained > devices while devices with additional resources may provide more > support for additional protocol primitives. See Section 1.7 for a > discussion on the level of configuration management and monitoring > support constrained devices may provide. > > Source: Basic requirement interesting for all use cases. > > Requirement Type: Non-Functional Requirement > > Device type: C0, C1, and C2 > > Priority: High > > --- > > Req-ID: 2.002 > > Title: Compact encoding of management data > > Description: The encoding of management data should be compact and > space efficient, enabling small message sizes. > > Source: General requirement to save memory for the receiver buffer > and on-air bandwidth. > > Requirement Type: Functional Requirement > > Device type: C0, C1, and C2 > > Priority: High > > --- > > Req-ID: 2.003 > > > > > Ersue, et al. Expires January 5, 2015 [Page 21] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > Title: Compression of management data or complete messages > > Description: Management data exchanges can be further optimized by > applying data compression techniques or delta encoding techniques. > Compression typically requires additional code size and some > additional buffers and/or the maintenance of some additional state > information. For C0 devices compression may not be feasible. > > Source: Use cases where it is beneficial to reduce transmission time > and bandwidth, e.g., mobile applications which require to save on- > air bandwidth. > > Requirement Type: Functional Requirement > > Device type: C1 and C2 > > Priority: Medium > > --- > > Req-ID: 2.004 > > Title: Mapping of management protocol interactions. > > Description: It is desirable to have a loss-less automated mapping > between the management protocol used to manage constrained devices > and the management protocols used to manage regular devices. In > the ideal case, the same core management protocol can be used with > certain restrictions taking into account the resource limitations > of constrained devices. However, for very resource constrained > devices, this goal might not be achievable. > > Source: Use cases where high-frequent interaction with the > management system of a non-constrained network is required. > > Requirement Type: Functional Requirement > > Device type: C1 and C2 > > Priority: Medium > > --- > > Req-ID: 2.005 > > Title: Consistency of data models with the underlying information > model. > > > > > Ersue, et al. Expires January 5, 2015 [Page 22] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > Description: The data models used by the management protocol must be > consistent with the information model used to define data models > for non-constrained networks. This is essential to facilitate the > integration of the management of constrained networks with the > management of non-constrained networks. Using an underlying > information model for future data model design enables furthermore > top-down model design and model reuse as well as data > interoperability (i.e., exchange of management information between > the constrained and non-constrained networks). This is a strong > requirement, even despite the fact that the underlying information > models are often not explicitly documented in the IETF. > > Source: General requirement to support data interoperability, > consistency and model reuse. > > Requirement Type: Non-Functional Requirement > > Device type: C0, C1, and C2 > > Priority: High > > --- > > Req-ID: 2.006 > TW> I believe "Lossless" can be a single word > Title: Loss-less mapping of management data models. > > Description: It is desirable to have a loss-less automated mapping > between the management data models used to manage regular devices > and the management data models used for managing constrained > devices. In the ideal case, the same core data models can be used > with certain restrictions taking into account the resource > limitations of constrained devices. However, for very resource > constrained devices, this goal might not be achievable. > > Source: Use cases where consistent data exchange with the management > system of a non-constrained network is required. > > Requirement Type: Functional Requirement > > Device type: C2 > > Priority: Medium > > --- > > Req-ID: 2.007 > > > > > Ersue, et al. Expires January 5, 2015 [Page 23] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > Title: Protocol extensibility > > Description: Provide means of extensibility for the management > protocol, i.e., by adding new protocol messages or mechanisms that > TW> deal with the changing requirements -> deal with changing requirements > can deal with the changing requirements on a supported message and > TW> inter-operability -> interoperability > data types effectively, without causing inter-operability problems > or having to replace/update large amount of deployed devices. > > Source: Basic requirement useful for all use cases. > > Requirement Type: Functional Requirement > > Device type: C0, C1, and C2 > > Priority: High > > 3.3. Configuration management > > Req-ID: 3.001 > > Title: Self-configuration capability > > Description: Automatic configuration and re-configuration of devices > without manual intervention. Compared to the traditional > management of devices where the management application is the > central entity configuring the devices, in the auto-configuration > scenario the device is the active part and initiates the > configuration process. Self-configuration can be initiated during > the initial configuration or for subsequent configurations, where > the configuration data needs to be refreshed. Self-configuration > should be also supported during the initialization phase or in the > event of failures, where prior knowledge of the network topology > is not available or the topology of the network is uncertain. > > Source: In general all use cases requiring easy deployment and > plug&play behavior as well as easy maintenance of many constrained > devices. > > Requirement Type: Functional Requirement > > Device type: C0, C1, and C2 > > Priority: High for device categories C0 and C1, Medium for C2. > > --- > > Req-ID: 3.002 > > > > > Ersue, et al. Expires January 5, 2015 [Page 24] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > Title: Capability Discovery > > Description: Enable the discovery of supported optional management > capabilities of a device and their exposure via at least one > protocol and/or data model. > > Source: Use cases where the device interaction with other devices or > applications is a function of the level of support for its > capabilities. > > Requirement Type: Functional Requirement > > Device type: C1 and C2 > > Priority: Medium > > --- > > Req-ID: 3.003 > > Title: Asynchronous Transaction Support > > Description: Provide configuration management with asynchronous > (event-driven) transaction support. Configuration operations must > support a transactional model, with asynchronous indications that > the transaction was completed. > > Source: Use cases that require transaction-oriented processing > because of reliability or distributed architecture functional > requirements. > > Requirement Type: Functional Requirement > > Device type: C1 and C2 > > Priority: Medium > > --- > > Req-ID: 3.004 > > Title: Network reconfiguration > > Description: Provide a means of iterative network reconfiguration in > TW> did you mean "fault" or "failure"? > order to recover the network from node and communication faults. > The network reconfiguration can be failure-driven and self- > initiated (automatic reconfiguration). The network > > > > > Ersue, et al. Expires January 5, 2015 [Page 25] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > reconfiguration can be also performed on the whole hierarchical > structure of a network (network topology). > > Source: Practically all use cases, as network connectivity is a > basic requirement. > > Requirement Type: Functional Requirement > > Device type: C0, C1, and C2 > > Priority: Medium > > 3.4. Monitoring functionality > > Req-ID: 4.001 > > Title: Device status monitoring > > Description: Provide a monitoring function to collect and expose > information about device status and exposing it via at least one > management interface. The device monitoring might make use of the > hierarchical management through the intermediary entities and the > caching mechanism. The device monitoring might also make use of > neighbor-monitoring (fault detection in local network) to support > fast fault detection and recovery, e.g., in a scenario where a > managing entity is unreachable and a neighbor can take over the > monitoring responsibility. > > Source: All use cases > > Requirement Type: Functional Requirement > > Device type: C0, C1, and C2 > > Priority: High, Medium for neighbor-monitoring. > > --- > > Req-ID: 4.002 > > Title: Energy status monitoring > > Description: Provide a monitoring function to collect and expose > information about device energy parameters and usage (e.g., > TW> I would suggest to replace "communication power" by "average power > TW> consumption" > battery level and communication power). > > Source: Use case Energy Management > > > > > Ersue, et al. Expires January 5, 2015 [Page 26] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > Requirement Type: Functional Requirement > > Device type: C0, C1, and C2 > > Priority: High for energy reporting devices, Low for others. > > --- > > Req-ID: 4.003 > > Title: Monitoring of current and estimated device availability > > Description: Provide a monitoring function to collect and expose > information about current device availability (energy, memory, > computing power, forwarding plane utilization, queue buffers, > etc.) and estimation of remaining available resources. > > Source: All use cases. Note that monitoring energy resources (like > battery status) may be required on all kinds of devices. > > Requirement Type: Functional Requirement > > Device type: C0, C1, and C2 > > Priority: Medium > > --- > > Req-ID: 4.004 > > Title: Network status monitoring > > TW> typo analyse -> analyze > Description: Provide a monitoring function to collect, analyse and > expose information related to the status of a network or network > segments connected to the interface of the device. > > Source: All use cases. > > Requirement Type: Functional Requirement > > Device type: C1 and C2 > > Priority: Low, based on the realization complexity. > > --- > > Req-ID: 4.005 > > > > > Ersue, et al. Expires January 5, 2015 [Page 27] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > Title: Self-monitoring > > Description: Provide self-monitoring (local fault detection) feature > for fast fault detection and recovery. > > Source: Use cases where the devices cannot be monitored centrally in > appropriate manner, e.g., self-healing is required. > > Requirement Type: Functional Requirement > > Device type: C1 and C2 > > Priority: High for C2, Medium for C1 > > --- > > Req-ID: 4.006 > > Title: Performance Monitoring > > Description: The device will provide a monitoring function to > collect and expose information about the basic performance > parameter of the device. The performance management functionality > might make use of the hierarchical management through the > intermediary devices. > > Source: Use cases Building automation, and Transport applications > > Requirement Type: Functional Requirement > > Device type: C1 and C2 > > Priority: Low > > --- > > Req-ID: 4.007 > > Title: Fault detection monitoring > > Description: The device will provide fault detection monitoring. > The system collects information about network states in order to > identify whether faults have occurred. In some cases the > detection of the faults might be based on the processing and > analysis of the parameters retrieved from the network or other > devices. In case of C0 devices the monitoring might be limited to > the check whether the device is alive or not. > > > > > Ersue, et al. Expires January 5, 2015 [Page 28] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > Source: Use cases Environmental Monitoring, Building Automation, > Energy Management, Infrastructure Monitoring > > Requirement Type: Functional Requirement > > Device type: C0, C1 and C2 > > Priority: Medium > > --- > > Req-ID: 4.008 > > Title: Passive and Reactive Monitoring > > Description: The device will provide passive and reactive monitoring > capabilities. The system or manager collects information about > device components and network states (passive monitoring) and may > perform postmortem analysis of collected data. In case events of > interest have occurred the system or manager can adaptively react > (reactive monitoring), e.g., reconfigure the network. Typically > actions (re-actions) will be executed or sent as commands by the > management applications. > > Source: Diverse use cases relevant for device status and network > state monitoring > > Requirement Type: Functional Requirement > > Device type: C2 > > Priority: Medium > > --- > > Req-ID: 4.009 > > Title: Recovery > > Description: Provide local, central and hierarchical recovery > mechanisms (recovery is in some cases achieved by recovering the > whole network of constrained devices). > > Source: Use cases Industrial applications, Home and Building > Automation, Mobile Applications that involve different forms of > clustering or area managers. > > Requirement Type: Functional Requirement > > > > Ersue, et al. Expires January 5, 2015 [Page 29] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > Device type: C2 > > Priority: Medium > > --- > > Req-ID: 4.010 > > Title: Network topology discovery > > Description: Provide a network topology discovery capability (e.g., > use of topology extraction algorithms to retrieve the network > state) and a monitoring function to collect and expose information > about the network topology. > > Source: Use cases Community Network Applications and Mobile > Applications > > Requirement Type: Functional Requirement > > Device type: C1 and C2 > > Priority: Low, based on the realization complexity. > > --- > > Req-ID: 4.011 > > Title: Notifications > > Description: The device will provide the capability of sending > notifications on critical events and faults. > > Source: All use cases. > > Requirement Type: Functional Requirement > > Device type: C0, C1, and C2 > > Priority: Medium for C2, Low for C0 and C1 > > --- > > Req-ID: 4.012 > > Title: Logging > > > > > > Ersue, et al. Expires January 5, 2015 [Page 30] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > Description: The device will provide the capability of building, > keeping, and allowing retrieval of logs of events (including but > not limited to critical faults and alarms). > > Source: Use cases Industrial Applications, Building Automation, > Infrastructure monitoring > > Requirement Type: Functional Requirement > > Device type: C2 > > Priority: High for some medical or industrial applications, Medium > otherwise > > 3.5. Self-management > > Req-ID: 5.001 > > Title: Self-management - Self-healing > > Description: Enable event-driven and/or periodic self-management > functionality in a device. The device should be able to react in > case of a failure e.g., by initiating a fully or partly reset and > initiate a self-configuration or management data update as > necessary. A device might be further able to check for failures > cyclically or schedule-controlled to trigger self-management as > necessary. It is a matter of device design and subject for > discussion how much self-management a C1 device can support. A > minimal failure detection and self-management logic is assumed to > be generally useful for the self-healing of a device. > > Source: The requirement generally relates to all use cases in this > document. > > Requirement Type: Functional Requirement > > Device type: C1 and C2 > > Priority: High for C2, Medium for C1 > > 3.6. Security and Access Control > > Req-ID: 6.001 > > Title: Authentication of management system and devices. > > Description: Systems having a management role must be properly > authenticated to the device such that the device can exercise > > > > Ersue, et al. Expires January 5, 2015 [Page 31] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > proper access control and in particular distinguish rightful > management systems from rogue systems. On the other hand managed > devices must authenticate themselves to systems having a > management role such that management systems can protect > themselves from rogue devices. In certain application scenarios, > it is possible that a large number of devices need to be > (re)started at about the same time. Protocols and authentication > systems should be designed such that a large number of devices > (re)starting simultaneously does not negatively impact the device > authentication process. > > Source: Basic security requirement for all use cases. > > Requirement Type: Functional Requirement > > Device type: C0, C1, and C2 > > Priority: High, Medium for the (re)start of a large number of > devices > > --- > > Req-ID: 6.002 > > Title: Support suitable security bootstrapping mechanisms > > Description: Mechanisms should be supported that simplify the > bootstrapping of device that is the discovery of newly deployed > devices in order to provide them with appropriate access control > permissions. > > Source: Basic security requirement for all use cases. > > Requirement Type: Functional Requirement > > Device type: C0, C1, and C2 > > Priority: High > > --- > > TW> in some cases, different entities should have access to different sets > of > TW> resources. This is not captured in the text below. > > Req-ID: 6.003 > > Title: Access control on management system and devices > > Description: Systems acting in a management role must provide an > access control mechanism that allows the security administrator to > restrict which devices can access the managing system (e.g., using > > > > Ersue, et al. Expires January 5, 2015 [Page 32] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > an access control white list of known devices). On the other hand > managed constrained devices must provide an access control > mechanism that allows the security administrator to restrict how > systems in a management role can access the device (e.g., no- > access, read-only access, and read-write access). > > Source: Basic security requirement for use cases where access > control is essential. > > Requirement Type: Functional Requirement > > Device type: C0, C1, and C2 > > Priority: High > > --- > > Req-ID: 6.004 > > Title: Select cryptographic algorithms that are efficient in both > code space and execution time. > > Description: Cryptographic algorithms have a major impact in terms > of both code size and overall execution time. It is therefore > necessary to select mandatory to implement cryptographic > algorithms that are reasonable to implement with the available > code space and that have a small impact at runtime. Furthermore > some wireless technologies (e.g., IEEE 802.15.4) require the > support of certain cryptographic algorithms. It might be useful > to choose algorithms that are likely to be supported in wireless > chipsets for certain wireless technologies. > > Source: Generic requirement to reduce the footprint and CPU usage of > a constrained device. > > Requirement Type: Non-Functional Requirement > > Device type: C0, C1, and C2 > > Priority: High, Medium for hardware-supported algorithms. > > 3.7. Energy Management > > Req-ID: 7.001 > > Title: Management of Energy Resources > > > > > > Ersue, et al. Expires January 5, 2015 [Page 33] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > Description: Enable managing power resources in the network, e.g., > reduce the sampling rate of nodes with critical battery and reduce > node transmission power, put nodes to sleep, put single interfaces > to sleep, reject a management job based on available energy, > criteria e.g., importance levels pre-defined by the management > application, etc. (e.g., a task marked as essential can be > executed even if the energy level is low). The device may further > implement standard data models for energy management and expose it > through a management protocol interface, e.g., EMAN MIB modules > and extensions (work ongoing). It might be necessary to use a > subset of EMAN MIBs for C1 and C2 devices. > > Source: Use case Energy Management > > Requirement Type: Functional Requirement > > Device type: C0, C1, and C2 > > Priority: Medium for the use case Energy Management, Low otherwise. > > --- > > Req-ID: 7.002 > > Title: Support of energy-optimized communication protocols > > Description: Use of an optimized communication protocol to minimize > energy usage for the device (radio) receiver/transmitter, on-air > bandwidth (protocol efficiency), reduced amount of data > communication between nodes (implies data aggregation and > filtering but also a compact format for the transferred data). > > Source: Use cases Energy Management and Mobile Applications. > > Requirement Type: Non-Functional Requirement > > Device type: C2 > > Priority: Medium > > --- > > Req-ID: 7.003 > > Title: Support for layer 2 energy-aware protocols > > > > > > > Ersue, et al. Expires January 5, 2015 [Page 34] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > Description: The device will support layer 2 energy management > protocols (e.g., energy-efficient Ethernet IEEE 802.3az) and be > able to report on these. > > Source: Use case Energy Management > > Requirement Type: Non-Functional Requirement > > Device type: C0, C1, and C2 > > Priority: Medium > > --- > > Req-ID: 7.004 > > Title: Dying gasp > > Description: When energy resources draw below the red line level, > the device will send a dying gasp notification and perform if > still possible a graceful shutdown including conservation of > critical device configuration and status information. > > Source: Use case Energy Management > > Requirement Type: Functional Requirement > > Device type: C0, C1, and C2 > > Priority: Medium > > 3.8. SW Distribution > > Req-ID: 8.001 > > Title: Group-based provisioning > > Description: Support group-based provisioning, i.e., firmware update > and configuration management, of a large set of constrained > devices with eventual consistency and coordinated reload times. > The device should accept group-based configuration management > based on bulk commands, which aim similar configurations of a > large set of constrained devices of the same type in a given > group, and which may share a common data model. Activation of > configuration may be based on pre-loaded sets of default values. > > Source: All use cases > > > > > Ersue, et al. Expires January 5, 2015 [Page 35] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > Requirement Type: Non-Functional Requirement > > Device type: C0, C1, and C2 > > Priority: Medium > > 3.9. Traffic management > > Req-ID: 9.001 > > Title: Congestion avoidance > > Description: Support congestion control principles as defined in > [RFC2914], e.g., the ability to avoid congestion by modifying the > device's reporting rate for periodical data (which is usually > redundant) based on the importance and reliability level of the > management data. This functionality is usually controlled by the > managing entity, where the managing entity marks the data as > TW> However*,* reducing > important or relevant for reliability. However reducing a > device's reporting rate can also be initiated by a device if it is > able to detect congestion or has insufficient buffer memory. > > Source: Use cases with high reporting rate and traffic e.g., AMI or > M2M. > > Requirement Type: Non-Functional Requirement > > Device type: C1 and C2 > > Priority: Medium > > --- > > Req-ID: 9.002 > > Title: Reroute traffic > > Description: Provide the ability for network nodes to redirect > traffic from overloaded intermediary nodes in a network to another > path in order to prevent congestion on a central server and in the > primary network. > > Source: Use cases with high reporting rate and traffic e.g., AMI or > M2M. > > Requirement Type: Non-Functional Requirement > > Device type: Intermediary entity in the network. > > > > Ersue, et al. Expires January 5, 2015 [Page 36] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > Priority: Medium > > --- > > Req-ID: 9.003 > > Title: Traffic Shaping. > > Description: Provide the ability to apply traffic shaping policies > to incoming and outgoing links on an overloaded intermediary node > as necessary in order to reduce the amount of traffic in the > network. > > Source: Use cases with high reporting rate and traffic e.g., AMI or > M2M. > > Requirement Type: Non-Functional Requirement > > Device type: Intermediary entity in the network. > > Priority: Medium > > 3.10. Transport Layer > > Req-ID: 10.001 > > Title: Scalable transport layer > > Description: Enable the use of a scalable transport layer, i.e., not > sensitive to a high rate of incoming client requests, which is > useful for applications requiring frequent access to device data. > > Source: Applications with high frequent access to the device data. > > Requirement Type: Non-Functional Requirement > > Device type: C0, C1 and C2 > > Priority: Medium > > --- > > Req-ID: 10.002 > > Title: Reliable unicast transport of messages > > Description: Diverse applications need a reliable transport of > messages. The reliability might be achieved based on a transport > > > > Ersue, et al. Expires January 5, 2015 [Page 37] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > protocol such as TCP or can be supported based on message > TW> acknowledgement -> acknowledgment > repetition if an acknowledgement is missing. > > Source: Generally applications benefit from the reliability of the > message transport. > > Requirement Type: Functional Requirement > > Device type: C0, C1, and C2 > > Priority: High > > --- > > Req-ID: 10.003 > > Title: Best-effort multicast > > Description: Provide best-effort multicast of messages, which is > generally useful when devices need to discover a service provided > by a server or many devices need to be configured by a managing > entity at once based on the same data model. > > Source: Use cases where a device needs to discover services as well > as use cases with high amount of devices to manage, which are > hierarchically deployed, e.g., AMI or M2M. > > Requirement Type: Functional Requirement > > Device type: C0, C1, and C2 > > Priority: Medium > > --- > > Req-ID: 10.004 > > Title: Secure message transport. > > Description: Enable secure message transport providing > authentication, data integrity, confidentiality by using existing > transport layer technologies with small footprint such as TLS/ > DTLS. > > Source: All use cases. > > Requirement Type: Non-Functional Requirements > > > > > Ersue, et al. Expires January 5, 2015 [Page 38] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > Device type: C1 and C2 > > Priority: High > > 3.11. Implementation Requirements > > Req-ID: 11.001 > > Title: Avoid complex application layer transactions requiring large > application layer messages. > > Description: Complex application layer transactions tend to require > large memory buffers that are typically not available on C0 or C1 > devices and only by limiting functionality on C2 devices. > Furthermore, the failure of a single large transaction requires > repeating the whole transaction. On constrained devices, it is > TW> "to a large transaction down" verb missing? > often more desirable to a large transaction down into a sequence > of smaller transactions that require less resources and allow to > make progress using a sequence of smaller steps. > > Source: Basic requirement which concerns all use cases with memory > constrained devices. > > Requirement Type: Non-Functional Requirement > > Device type: C0, C1, and C2 > > Priority: High > > --- > > Req-ID: 11.002 > > Title: Avoid reassembly of messages at multiple layers in the > protocol stack. > > Description: Reassembly of messages at multiple layers in the > protocol stack requires buffers at multiple layers, which leads to > inefficient use of memory resources. This can be avoided by > making sure the application layer, the security layer, the > transport layer, the IPv6 layer and any adaptation layers are > aware of the limitations of each other such that unnecessary > fragmentation and reassembly can be avoided. In addition, message > size constraints must be announced to protocol peers such that > they can adapt and avoid sending messages that can't be processed > due to resource constraints on the receiving device. > > > > > > Ersue, et al. Expires January 5, 2015 [Page 39] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > Source: Basic requirement which concerns all use cases with memory > constrained devices. > > Requirement Type: Non-Functional Requirement > > Device type: C0, C1, and C2 > > Priority: High > > 4. IANA Considerations > > This document does not introduce any new code-points or namespaces > for registration with IANA. > > Note to RFC Editor: this section may be removed on publication as an > RFC. > > 5. Security Considerations > > This document discusses the problem statement and requirements on > networks of constrained devices. Section 1.6 mentions a number of > limitations that could prevent the implementation of strong > cryptographic algorithms. Requirements for security and access > control are listed in Section 3.6. > > Constrained devices might be deployed often in unsafe environments, > where attackers can gain physical access to the devices. As a > consequence, it is crucial to properly protect any security > credentials that may be stored on the device (e.g., by using hardware > protection mechanisms). Furthermore, it is important that any > TW> leeking -> leaking > credentials leeking from a single device do not simplify the attack > on other (similar) devices. In particular, security credentials > should never be shared. > > Since constrained devices often have limited computational resources, > care should be taken in choosing efficient but cryptographically > TW> crytographic -> cryptographic > strong crytographic algorithms. Designers of constrained devices > that have a long expected lifetime need to ensure that cryptographic > algorithms can be updated once devices have been deployed. The > ability to perform secure firmware and software updates is an > important management requirement. > > Constrained devices might also generate sensitive data or require the > processing of sensitive data. It is therefore an important > requirement to properly protect access to the data in order to > protect the privacy of humans using Internet-enabled devices. For > certain types of data, protection during the transmission over the > network may not be sufficient and methods should be investigated that > > > > Ersue, et al. Expires January 5, 2015 [Page 40] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > provide protection of data while it is cached or stored (e.g., when > using a store-and-forward transport mechanism). > > 6. Contributors > > Ulrich Herberg (Fujitsu Laboratories of America) contributed to the > Section 1.3 on Networks Types and Characteristics in Focus. > > 7. Acknowledgments > > Following persons reviewed and provided valuable comments to > different versions of this document: > > Dominique Barthel, Andy Bierman, Carsten Bormann, Zhen Cao, Benoit > Claise, Hui Deng, Bert Greevenbosch, Ulrich Herberg, James Nguyen, > Anuj Sehgal, Zach Shelby, Peter van der Stok and Bert Wijnen. > > The editors would like to thank the reviewers and the participants on > the Coman and OPSAWG mailing lists for their valuable contributions > and comments. > > 8. Informative References > > [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC > 2914, September 2000. > > [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking > (MANET): Routing Protocol Performance Issues and > Evaluation Considerations", RFC 2501, January 1999. > > [RFC6632] Ersue, M. and B. Claise, "An Overview of the IETF Network > Management Standards", RFC 6632, June 2012. > > [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and > Lossy Networks", RFC 7102, January 2014. > > [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for > Constrained-Node Networks", RFC 7228, May 2014. > > [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained > Application Protocol (CoAP)", RFC 7252, June 2014. > > [COM-USE] Ersue, M., "Constrained Management: Use Cases", draft- > ietf-opsawg-coman-use-cases (work in progress), October > 2013. > > > > > > > Ersue, et al. Expires January 5, 2015 [Page 41] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > Appendix A. Change Log > > A.1. draft-ietf-opsawg-coman-probstate-reqs-01 - draft-ietf-opsawg- > coman-probstate-reqs-02 > > o General bug fixing. > > o Resolved the use of the term profile of requirements. > > o Changed requirement title from Redirect traffic to Reroute traffic > and the description accordingly. > > o Changed requirement title from Traffic delay schemes to Traffic > Shaping and the description accordingly. > > o Extended Security Considerations section. > > o Deleted empty section on Normative References. > > A.2. draft-ietf-opsawg-coman-probstate-reqs-00 - draft-ietf-opsawg- > coman-probstate-reqs-01 > > o General bug fixing. > > o Added Section 1.7. on Configuration and Monitoring Functionality > Levels. > > o Changed diverse occurences of "networks" to "networks with/of > constrained devices". > > o Introduced the term "Self-configuring infrastructureless networks" > instead of MANET as it is a superset. > > o Introduced the term 'sleepy endpoints'. > > o Changed requirement IDs to be independent of section number. > > o Introduced notes for parts of the requirements text if it is > focusing on implementation or solution. > > o Extended Security Considerations section. > > o Deleted Appendix A and B on other SDO's work and related projects > as they provided dynamic information and couldn't be kept up-to- > date. > > > > > > > Ersue, et al. Expires January 5, 2015 [Page 42] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > A.3. draft-ersue-constrained-mgmt-03 - draft-ietf-opsawg-coman- > probstate-reqs-00 > > o Reduced the terminology section for terminology addressed in the > LWIG terminology draft. Referenced the LWIG terminology draft. > > o Checked and aligned all terminology against the LWIG terminology > draft. > > o Moved section 1.4. Constrained Device Deployment Options and > section 3. Use Cases to the companion document [COM-USE]. > > o Renamed Section 1.3. Class of Networks in Focus to "Network Types > in Focus" and removed abbreviations C0, C1 and C2 for network > classes as they have not been used. > > o Changed requirement priority classes to be High, Medium and Low. > > o Changed requirement types to be Functional and Non-Functional and > added text to explain the requirement types. > > o Reformulation of some text parts for more clarity. > > A.4. draft-ersue-constrained-mgmt-02-03 > > o Extended the terminology section and removed some of the > terminology addressed in the new LWIG terminology draft. > Referenced the LWIG terminology draft. > > o Moved Section 1.3. on Constrained Device Classes to the new LWIG > terminology draft. > > o Class of networks considering the different type of radio and > communication technologies in use and dimensions extended. > > o Extended the Problem Statement in Section 2. following the > requirements listed in Section 4. > > o Following requirements, which belong together and can be realized > with similar or same kind of solutions, have been merged. > > * Distributed Management and Peer Configuration, > > * Device status monitoring and Neighbor-monitoring, > > * Passive Monitoring and Reactive Monitoring, > > > > > > Ersue, et al. Expires January 5, 2015 [Page 43] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > * Event-driven self-management - Self-healing and Periodic self- > management, > > * Authentication of management systems and Authentication of > managed devices, > > * Access control on devices and Access control on management > systems, > > * Management of Energy Resources and Data models for energy > management, > > * Software distribution (group-based firmware update) and Group- > based provisioning. > > o Deleted the empty section on the gaps in network management > standards, as it will be written in a separate draft. > > o Added links to mentioned external pages. > > o Added text on OMA M2M Device Classification in appendix. > > A.5. draft-ersue-constrained-mgmt-01-02 > > o Extended the terminology section. > > o Added additional text for the use cases concerning deployment > type, network topology in use, network size, network capabilities, > radio technology, etc. > > o Added examples for device classes in a use case. > > o Added additional text provided by Cao Zhen (China Mobile) for > Mobile Applications and by Peter van der Stok for Building > Automation. > > o Added the new use cases 'Advanced Metering Infrastructure' and > 'MANET Concept of Operations in Military'. > > o Added the section 'Managing the Constrainedness of a Device or > Network' discussing the needs of very constrained devices. > > o Added a note that the requirements in Section 3 need to be seen as > standalone requirements and the current document does not > recommend any profile of requirements. > > o Added Section 3 on the detailed requirements on constrained > management matched to management tasks like fault, monitoring, > > > > Ersue, et al. Expires January 5, 2015 [Page 44] > Internet-Draft Constrained Mgmt: PS, Rqmts July 2014 > > > configuration management, Security and Access Control, Energy > Management, etc. > > o Solved nits and added references. > > o Added Appendix A on the related development in other bodies. > > o Added Appendix B on the work in related research projects. > > A.6. draft-ersue-constrained-mgmt-00-01 > > o Splitted the section on 'Networks of Constrained Devices' into the > sections 'Network Topology Options' and 'Management Topology > Options'. > > o Added the use case 'Community Network Applications' and 'Mobile > Applications'. > > o Provided a Contributors section. > > o Extended the section on 'Medical Applications'. > > o Solved nits and added references. > > Authors' Addresses > > Mehmet Ersue (editor) > Nokia Networks > > Email: mehmet.ersue@nsn.com > > > Dan Romascanu > Avaya > > Email: dromasca@avaya.com > > > Juergen Schoenwaelder > Jacobs University Bremen > > Email: j.schoenwaelder@jacobs-university.de > > > > > > > > > > Ersue, et al. Expires January 5, 2015 [Page 45] > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From nobody Mon Aug 11 08:31:47 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 783B11A064D for ; Mon, 11 Aug 2014 08:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.268 X-Spam-Level: X-Spam-Status: No, score=-3.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] 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 omOeqdpw_Tct for ; Mon, 11 Aug 2014 08:31:45 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id 553EE1A05C0 for ; Mon, 11 Aug 2014 08:31:45 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id C0BCC343CC; Mon, 11 Aug 2014 08:31:44 -0700 (PDT) From: Wes Hardaker To: t.petch References: <005601cfb22f$b1cad1e0$4001a8c0@gateway.2wire.net> Date: Mon, 11 Aug 2014 08:31:44 -0700 In-Reply-To: <005601cfb22f$b1cad1e0$4001a8c0@gateway.2wire.net> (t. petch's message of "Thu, 7 Aug 2014 10:51:24 +0100") Message-ID: <0l1tsnkppb.fsf@wjh.hardakers.net> User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/1wCYNihlMNC6n73cW0jMknOfv9U Cc: opsawg@ietf.org Subject: Re: [OPSAWG] OPSAWGFw: I-D Action: draft-hartman-snmp-sha2-02.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 15:31:46 -0000 t.petch writes: > I am not sure where this should be discussed but I note that it creates > a new SnmpAuthProtocols but it contains no request to IANA to register a > name and is Experimental whereas the update procedure for the registry > is Standards Track. It's certainly not implementable as-is. It'd need to use a private registration, both for in-packet identifiers and for oid identifiers. -- Wes Hardaker Parsons From nobody Mon Aug 11 11:51:14 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F781A002E for ; Mon, 11 Aug 2014 11:51:14 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 BR-s7-mYm_DM for ; Mon, 11 Aug 2014 11:51:12 -0700 (PDT) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 905A01A0025 for ; Mon, 11 Aug 2014 11:51:09 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id k14so8833040wgh.8 for ; Mon, 11 Aug 2014 11:51:08 -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:date:message-id:subject:from:to :content-type; bh=rJNXk3I+fVLODS8mJMWmNLwH4zazVbCtQGtxzLdPhDE=; b=RgvYtrIodNzCnclkVj+R+cOeyl3wcnJ6EUQzIhvVvQ270hsq/cop+1SCq6Li/CgOR+ 0MQoj65/OuUM1vlCbx7zU7S0jRTQgZQhmXN4i79qMMa/hoju8DpHUNyhfQp6G0kGVipE fxQiNjrVNPFLMMBf8qyIgZLh8jkky6+fZ13iiVcAf6wZLZ86S9qriTY9Plyu+U0GMFhD ajqovq9tex9r5jgV+BtaCzLoKyc90Lu3CKLyI5MKMCCNAzSyOXavPW2001fqIsHiTB/8 WBzZ3qVQHM1cbVG+9KMKp5a37WzMrx423u04oP8yaT+Z63dLawoj5zg6fSVwJKCf/1Ar 7X3g== X-Gm-Message-State: ALoCoQmaX/9mwQxYqY4Kewlzo0JzKA4K13pi9FrR8lU3GzrRseHK4e6Gc1pGiTIAgivPI8gA2+5X MIME-Version: 1.0 X-Received: by 10.194.205.196 with SMTP id li4mr55189599wjc.46.1407783068084; Mon, 11 Aug 2014 11:51:08 -0700 (PDT) Received: by 10.194.62.39 with HTTP; Mon, 11 Aug 2014 11:51:08 -0700 (PDT) Date: Mon, 11 Aug 2014 14:51:08 -0400 Message-ID: From: Warren Kumari To: "opsawg@ietf.org" , draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org, "opsawg-chairs@tools.ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/OnjpzakpwwkxOTWahTkzZAwy3DE Subject: [OPSAWG] Start of WGLC for draft-ietf-opsawg-capwap-alt-tunnel X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 18:51:14 -0000 Dear OpsAWG WG, The authors of draft-ietf-opsawg-capwap-alt-tunnel have indicated that they believe that the document is ready, and have asked for Working Group Last Call[0]. The draft is available here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ Please review this draft to see if you think it is ready for publication and send comments to the list, clearly stating your view. This WGLC ends Mon 25-Aug-2014. In addition, to satisfy RFC 6702 "Promoting Compliance with Intellectual Property Rights (IPR)": Are you personally aware of any IPR that applies to draft-ietf-opsawg-capwap-alt-tunnel? If so, has this IPR been disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) Thanks, Warren Kumari (as OpsAWG WG co-chair) [0]: Actually, they asked a while back, but it slipped through the cracks. From nobody Mon Aug 11 14:29:09 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315E31A0002 for ; Mon, 11 Aug 2014 14:29: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, RCVD_IN_DNSWL_LOW=-0.7] 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 PMn8NFcUSKjL for ; Mon, 11 Aug 2014 14:29:03 -0700 (PDT) Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 717481A0137 for ; Mon, 11 Aug 2014 14:29:00 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id u56so9230176wes.0 for ; Mon, 11 Aug 2014 14:28: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:date:message-id:subject:from:to :content-type; bh=9rUQ5nkC7huTjRueQu1WbwFlHASFhesiEDpVBm9MwzA=; b=DICPwsq96r2GWkGYnWqTr6FDIj4g7yZs3QFliuDGh4/zgK6VXHt3UeroIgjqUkH2kA GvQ3ifQoO4BjoEcBPbajO5JSYOCz8kcj5IqYWS8GVEdtTnNlll6nyhJayLcXuDZyPhdG ZHwFnnrdFzpKSjc6gLfHhDomhnEarWdUZGGVzr/+IYjw5WlQ/zyTAaqCmcQJ/zGMq200 E1dMBuis3DvaJsVSL8IKOoQyQ8WopDPBJ3qn6lCeZOZgh6XtSPg1OEPlc13BSZC/20ih IMHXR7egiYIFUqvHX3NNzKoKXyUhJHz6iHNcQ/6cCSvw81VQ8jjVoMa6Tbh2Nxar7Zkg vPnw== X-Gm-Message-State: ALoCoQlXoJkEf9W7dgT2Y/0nM29MD27c1GHyaEtTucOfqi0hxJKg6qxuvVBNGmSSehCGjBQhe2vI MIME-Version: 1.0 X-Received: by 10.180.210.231 with SMTP id mx7mr22361416wic.42.1407792538953; Mon, 11 Aug 2014 14:28:58 -0700 (PDT) Received: by 10.194.62.39 with HTTP; Mon, 11 Aug 2014 14:28:58 -0700 (PDT) Date: Mon, 11 Aug 2014 17:28:58 -0400 Message-ID: From: Warren Kumari To: "opsawg@ietf.org" , draft-hmac-sha-2-usm-snmp@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/npBIgRAzrtj9NV2reFDMb7SeR_k Subject: [OPSAWG] Call for Adoption: draft-hmac-sha-2-usm-snmp X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 21:29:06 -0000 Dear OpsAWG WG, This starts a Call for Adoption for draft-hmac-sha-2-usm-snmp. The draft is available here: https://datatracker.ietf.org/doc/draft-hmac-sha-2-usm-snmp/ Please review this draft to see if you think it is suitable for adoption by OpsAWG, and comments to the list, clearly stating your view. Please also indicate if you are willing to contribute text, review, etc. This call for adoption ends Mon 25-Aug-2014. In addition, to satisfy RFC 6702 ("Promoting Compliance with Intellectual Property Rights (IPR)"): If you are personally aware of any IPR that applies to draft-hmac-sha-2-usm-snmp, has this IPR been disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) Thanks, Warren Kumari (as OpsAWG WG co-chair) From nobody Mon Aug 11 15:36:55 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9BD01A06D9 for ; Mon, 11 Aug 2014 15:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 HfNnJlN7Vm9P for ; Mon, 11 Aug 2014 15:36:52 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF4F11A0205 for ; Mon, 11 Aug 2014 15:36:51 -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 s7BMafG7023408; Tue, 12 Aug 2014 00:36:41 +0200 (CEST) Received: from [192.168.217.106] (p54890742.dip0.t-ipconnect.de [84.137.7.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 62884945; Tue, 12 Aug 2014 00:36:40 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: Date: Tue, 12 Aug 2014 00:36:38 +0200 X-Mao-Original-Outgoing-Id: 429489398.52132-11c05bf3b7cd9dcb826f539317cded80 Content-Transfer-Encoding: quoted-printable Message-Id: <570A9DD4-87F4-4255-B8F5-83FAD69574F6@tzi.org> References: To: "opsawg@ietf.org" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/tgfI2o1p5s_Frr8XdpKsG0KIh6g Cc: draft-ietf-opsawg-coman-use-cases@tools.ietf.org, draft-ietf-opsawg-coman-probstate-reqs@tools.ietf.org, "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] Coman Drafts v02 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 22:36:54 -0000 I did a cursory review of the Coman drafts. These consolidate a rather useful body of knowledge, even if it is still = in flux in many areas. It may be more important to get them published in some state, with an = explicit qualification of being somewhat work in progress, than trying = to further polish them until nothing of substance is left. My strong = recommendation here would be: if in doubt, publish. The most important aspect that probably needs to be expanded is the = security considerations, with a view to resiliency. Not having a = management interface is a security liability. Adding one is an even = greater security liability. Instead of trying to say what is needed here in my imperfect words, I=92d = like to refer to the discussion under number (5) in = http://geer.tinho.net/geer.blackhat.6viii14.txt In a related vein, many of the coman-specific management issues stem = from the peculiar lifecycles the devices go through. draft-garcia-core-security is the best document we have about this = aspect, and the two coman documents probably should be developed in = unison with this one. It is not always easy to separate =93constrained network=94 = considerations from =93constrained node network=94 considerations, and = probstate might benefit from one more editing round to get the right = focus in the right places. (Adding another unfocused term, LLN, and = alternating back and forth, does not help.) A related editorial problem = is the usage =93non-constrained=94 (which of course is physically = impossible) =97 in RFC 7228 we missed coming up with good terminology = for what we mean by less-constrained or affluent systems. But these are more general editorial problems, and it is maybe too much = to expect them being solved here. I support Thomas=92 comment on the use of the term =93requirement=94. The definition of =93Priority=94 in Section 3 of probstate, where a = requirement suddenly becomes less important just because it happens to = be impossible to fulfill, is a symptom of this. Editorially, the requirements list would become less tedious if = Requirement Type, Device Type, and Priority could be put into tabular = form, maybe together with Req-ID. 2.002 does not mention the cost of copying and maybe should. 2.003 may be a bit optimistic about =93compression=94 (as opposed to = concise representation in the first place), but then this term isn=92t = really defined anyway. A major problem with using classical network management thinking for = constrained devices is that, for these, there may be little difference = between network and application configuration, including firmware = updating. There are some actual =93requirements=94 (6.*, 9.001 =97 which is = =93medium=94 priority???); it may be worth calling them out. I don=92t understand 10.004 vs. 6.* =97 while secure message transport = is a good choice in many cases, it is ultimately there to support = security objectives. A great aspect of the use-case document is that it calls out the = management responsibility for some of the use cases; this should always = be done. It would be good to know in which cases that responsibility is = clearly separable from the application responsibilities (in the way = network management has been traditionally). =93Medical Applications=94 is not a use case, it is a whole universe of = use cases, and one or two should be included as their own use cases = (e.g., separating a BYOD/personal interest case from a = professional/healthcare use case). I=92m sorry for throwing out all these observations in front of the = authors; again, if in doubt: publish, but maybe expand on some of these = observations in a =93future work=94 section. Gr=FC=DFe, Carsten From nobody Mon Aug 11 16:03:00 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E4E1A0720; Mon, 11 Aug 2014 16:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 PxSFZjCLYg1B; Mon, 11 Aug 2014 16:02:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AAE601A071B; Mon, 11 Aug 2014 16:02:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140811230254.5216.78858.idtracker@ietfa.amsl.com> Date: Mon, 11 Aug 2014 16:02:54 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/6_pIWGJc3fZgIDsLeqRaxq5RmjA Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-capwap-hybridmac-06.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 23:02:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. Title : IEEE 802.11 MAC Profile for CAPWAP Authors : Chunju Shao Hui Deng Rajesh S. Pazhyannur Farooq Bari Rong Zhang Satoru Matsushima Filename : draft-ietf-opsawg-capwap-hybridmac-06.txt Pages : 10 Date : 2014-08-11 Abstract: The CAPWAP protocol defines two entities: a Wireless Transmission Point (WTP) and an Access Controller (AC). The CAPWAP protocol binding for IEEE 802.11 defines two MAC (Medium Access Control) modes for IEEE 802.11 WTP: Split and Local MAC, and describes the required functionality split between the WTP and AC for each mode. However, in the split MAC mode, the partitioning of encryption/decryption functions are not been clearly clearly defined. In the Split MAC mode description, IEEE 802.11 encryption is specified as located in either at the AC or the WTP, with no clear way for the AC to inform the WTP of where the encryption functionality should be located. This lack of specification leads to interoperability issues, especially when the AC and WTP come from different vendors. To prevent interoperability issues, this specification defines an IEEE 802.11 MAC profile message element in which each profile specifies an unambiguous division of encryption functionality between the WTP and AC. The IEEE 802.11 MAC profile is used as follows: the WTP informs the AC of the supported profiles during the discovery or join process and the AC configures the WTP with one of the supported profiles when configuring the WLAN. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-capwap-hybridmac-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-capwap-hybridmac-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 12 01:44:55 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 329D51A07A0 for ; Tue, 12 Aug 2014 01:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 r8_YDpwIzUtB for ; Tue, 12 Aug 2014 01:44:52 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lrp0077.outbound.protection.outlook.com [213.199.154.77]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63D341A0799 for ; Tue, 12 Aug 2014 01:44:51 -0700 (PDT) Received: from DB3PR07MB058.eurprd07.prod.outlook.com (10.242.137.148) by DB3PR07MB0665.eurprd07.prod.outlook.com (25.160.50.19) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Tue, 12 Aug 2014 08:44:43 +0000 Received: from pc6 (109.147.210.26) by DB3PR07MB058.eurprd07.prod.outlook.com (10.242.137.148) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Tue, 12 Aug 2014 08:44:42 +0000 Message-ID: <00b401cfb609$8e6b6ec0$4001a8c0@gateway.2wire.net> From: t.petch To: Warren Kumari , "opsawg@ietf.org" , References: Date: Tue, 12 Aug 2014 09:43:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [109.147.210.26] X-ClientProxiedBy: DB4PR03CA0025.eurprd03.prod.outlook.com (25.160.39.163) To DB3PR07MB058.eurprd07.prod.outlook.com (10.242.137.148) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:;UriScan:; X-Forefront-PRVS: 0301360BF5 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(377454003)(13464003)(189002)(51704005)(51444003)(164054003)(199003)(106356001)(105586002)(31966008)(50466002)(85852003)(107886001)(21056001)(81542001)(74502001)(66066001)(33646002)(19580405001)(86362001)(42186005)(104166001)(95666004)(19580395003)(92566001)(83322001)(93916002)(20776003)(47776003)(102836001)(85306004)(61296003)(107046002)(116806002)(92726001)(62966002)(14496001)(77096002)(74662001)(83072002)(99396002)(87976001)(76176999)(81686999)(50986999)(87286001)(50226001)(101416001)(89996001)(81816999)(4396001)(88136002)(77156001)(15975445006)(84392001)(64706001)(80022001)(44736004)(2201001)(44716002)(79102001)(46102001)(62236002)(23756003)(76482001)(77982001)(81342001)(74416001)(2501001)(7726001); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR07MB058; H:pc6; FPR:; MLV:nov; PTR:InfoNoRecords; MX:1; A:0; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/tZvPXN8iTONkdz4IzdBag1KM5Qw Subject: Re: [OPSAWG] Call for Adoption: draft-hmac-sha-2-usm-snmp X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 08:44:54 -0000 I support adoption. It brings USM up-to-date. However, I am aware of https://datatracker.ietf.org/doc/draft-hartman-snmp-sha2/ which looks remarkable similar in scope but different in detail. I regard https://datatracker.ietf.org/doc/draft-hmac-sha-2-usm-snmp/ as the superior I-D but am surprised at the existence of the other, with its distinguished list of editors. Any ideas what their intentions are? I would not want to see a merger of the two I-Ds, I think that that would be the worst outcome, although having both become RFC would also be a bad result. Tom Petch ----- Original Message ----- From: "Warren Kumari" To: "opsawg@ietf.org" ; Sent: Monday, August 11, 2014 10:28 PM Subject: [OPSAWG] Call for Adoption: draft-hmac-sha-2-usm-snmp > Dear OpsAWG WG, > > This starts a Call for Adoption for draft-hmac-sha-2-usm-snmp. > > The draft is available here: > https://datatracker.ietf.org/doc/draft-hmac-sha-2-usm-snmp/ > > Please review this draft to see if you think it is suitable for > adoption by OpsAWG, > and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends Mon 25-Aug-2014. > > In addition, to satisfy RFC 6702 ("Promoting Compliance with > Intellectual Property Rights (IPR)"): > If you are personally aware of any IPR that applies to > draft-hmac-sha-2-usm-snmp, has this IPR been disclosed in compliance > with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more > details.) > > > > Thanks, > Warren Kumari > (as OpsAWG WG co-chair) > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Tue Aug 12 07:58:39 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72B0F1A092C for ; Tue, 12 Aug 2014 07:58:37 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 hly1DiwsiRdQ for ; Tue, 12 Aug 2014 07:58:36 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 506F11A0925 for ; Tue, 12 Aug 2014 07:58:19 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id n3so5991343wiv.17 for ; Tue, 12 Aug 2014 07:58:17 -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:date:message-id:subject:from:to :content-type; bh=++Anx8gEMuSpe8TvBYM9KF6Uz5OFmhdYP2k+/gTq8aU=; b=Zp7yjApX5OuCm2BrcoGNlLT14i4Z9gZoXsUwDEFWyaf5J16rcDaMoQt+Yz9Pmr9JCC azqhorvJ0DrOYDqIGKYjL+Jq1dEHZLB5M58JLHMSqyhjV7z2UPqpWgC/arehTNP639cR 7FVgHivaBaZOFbLpzuSeThpXkMecgO8hyUPO8p8xyUWVA8de0WNiKSUWkp9jTEmnPbB+ mZQGoIlbhDdnrFF3hDKx8itF0ykE4snmTzG5O7YNzUBFN9oiPH6tqzFyTXHLmxYZJIZX TvlEch2KZPdxOLRpxu1ppphtF8FziEsDsayS6jPCXk7Tqblm8canhaztct6kNhZQcRD4 n4kA== X-Gm-Message-State: ALoCoQncG1Wn/wXeRXAzZM+26OYgbnO+giCCAWlfZ20JfJqsw04euBzT9by/rX1y/SMzNVuN32M7 MIME-Version: 1.0 X-Received: by 10.194.222.230 with SMTP id qp6mr5779383wjc.23.1407855497825; Tue, 12 Aug 2014 07:58:17 -0700 (PDT) Received: by 10.194.62.39 with HTTP; Tue, 12 Aug 2014 07:58:17 -0700 (PDT) Date: Tue, 12 Aug 2014 10:58:17 -0400 Message-ID: From: Warren Kumari To: "opsawg@ietf.org" , "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org>, "6tisch-chairs@tools.ietf.org" <6tisch-chairs@tools.ietf.org> Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/CLPZsP1Z6uhGK1ZrMLUaDuL2pmM Subject: [OPSAWG] Calling consensus on the -coman- documents. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 14:58:37 -0000 Hi there all, Scott and myself chatted about these documents yesterday. Constrained networks and devices is not the core focus of this WG, and so getting review and feedback on the documents has been somewhat tricky. During IETF90 Thomas Watteyne asked for the WGLC to be extended so that 6Lo and 6TiSCH could review and provide comments -- and we got a significant amount of feedback from these groups. We have reviewed this feedback, and, while the reviews suggest some changes and additions, we find there to be consensus for publishing the document. We are requesting the authors to incorporate the suggestions / changes, confirm with the reviewers that their comments are addressed, and then will give the WG one last, short opportunity to comment, and then send it over to the IESG. Thank you everyone who commented and provided feedback, Warren (as OpsAWG chair) From nobody Tue Aug 12 15:39:43 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 646FD1A0A88 for ; Tue, 12 Aug 2014 15:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.268 X-Spam-Level: X-Spam-Status: No, score=-3.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] 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 O3xxMjul3u3I for ; Tue, 12 Aug 2014 15:39:41 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id 33C271A0A82 for ; Tue, 12 Aug 2014 15:39:41 -0700 (PDT) Received: from localhost (50-1-19-226.dsl.dynamic.sonic.net [50.1.19.226]) by mail.hardakers.net (Postfix) with ESMTPSA id 42B8121C55; Tue, 12 Aug 2014 15:39:38 -0700 (PDT) From: Wes Hardaker To: Warren Kumari References: Date: Tue, 12 Aug 2014 15:39:37 -0700 In-Reply-To: (Warren Kumari's message of "Mon, 11 Aug 2014 17:28:58 -0400") Message-ID: <0llhqte3iu.fsf@wjh.hardakers.net> User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/02D4AuiFX3Dfh_xtKzxDAlF8xpg Cc: "opsawg@ietf.org" , draft-hmac-sha-2-usm-snmp@tools.ietf.org Subject: Re: [OPSAWG] OPSAWGCall for Adoption: draft-hmac-sha-2-usm-snmp X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 22:39:42 -0000 Warren Kumari writes: > This starts a Call for Adoption for draft-hmac-sha-2-usm-snmp. I'm up for it being adopted. However, it needs work before going forward (but hey, that's what a WG is for). -- Wes Hardaker Parsons From nobody Tue Aug 12 17:35:43 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4871A07DC for ; Tue, 12 Aug 2014 17:35:42 -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 U2HgO4sCaThT for ; Tue, 12 Aug 2014 17:35:41 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EC671A0720 for ; Tue, 12 Aug 2014 17:35:41 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id eu11so13893320pac.18 for ; Tue, 12 Aug 2014 17:35:40 -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:date:message-id:subject :from:to:cc:content-type; bh=7Z5VmgANZb4c/PJjqC7aTanjuNqzGHnjZJQEQUKYoBs=; b=WjBh8rDJgul4rT5HtoHOrXXhEpDxb1ga5h+BFp3uhM6fUp8ZMSBBk1HWSye4SHyXrJ 16XWnkJncLl6egY+jaCGsZCLRPjEucPL6VA64guEwf5GhPPKEP9G90GiuZuzXs8KJmhc ObJVXHZ7gXw0DCQzWhs0akNxt3DlJdcIUGdJxgrGog1A905xxdNSXw4/1pYxqWgcT58k 5hBiIDy1KZcntB1OEjGz983Y1DuPrCAXTl4aGTp0X3nicmgnxD6YROnzhZmSkEA3sNn/ Ww2WZkDZoPMqTB4Rxi3vIJaGyz/73tYTvmHH7FKdMZD/h0aixcIzq73agmTkVy3CoZar xH0Q== MIME-Version: 1.0 X-Received: by 10.68.250.3 with SMTP id yy3mr1039317pbc.56.1407890140762; Tue, 12 Aug 2014 17:35:40 -0700 (PDT) Sender: twatteyne@gmail.com Received: by 10.66.144.1 with HTTP; Tue, 12 Aug 2014 17:35:40 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 Aug 2014 17:35:40 -0700 X-Google-Sender-Auth: eD9MzQ0n0pfEBvHIHBSIQgwJHJo Message-ID: From: Thomas Watteyne To: Warren Kumari Content-Type: multipart/alternative; boundary=047d7b6721b0b9184d050077f79e Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/VyMQNf2mZUUM6gIShXaFsSRQodY Cc: "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org>, "opsawg@ietf.org" , "6tisch-chairs@tools.ietf.org" <6tisch-chairs@tools.ietf.org> Subject: Re: [OPSAWG] Calling consensus on the -coman- documents. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 00:35:42 -0000 --047d7b6721b0b9184d050077f79e Content-Type: text/plain; charset=UTF-8 Warren, This has been a constructive process, thank you for agreeing to extend the WGLC period. Thomas On Tuesday, August 12, 2014, Warren Kumari wrote: > Hi there all, > > Scott and myself chatted about these documents yesterday. > > Constrained networks and devices is not the core focus of this WG, and > so getting review and feedback on the documents has been somewhat > tricky. During IETF90 Thomas Watteyne asked for the WGLC to be > extended so that 6Lo and 6TiSCH could review and provide comments -- > and we got a significant amount of feedback from these groups. > > We have reviewed this feedback, and, while the reviews suggest some > changes and additions, we find there to be consensus for publishing > the document. > We are requesting the authors to incorporate the suggestions / > changes, confirm with the reviewers that their comments are addressed, > and then will give the WG one last, short opportunity to comment, and > then send it over to the IESG. > > Thank you everyone who commented and provided feedback, > Warren (as OpsAWG chair) > --047d7b6721b0b9184d050077f79e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Warren,
This has been a constructive process,=C2=A0=C2=A0t= hank you for agreeing to extend the WGLC period.
Thomas

On= Tuesday, August 12, 2014, Warren Kumari <warren@kumari.net> wrote:
Hi there all,

Scott and myself chatted about these documents yesterday.

Constrained networks and devices is not the core focus of this WG, and
so getting review and feedback on the documents has been somewhat
tricky. During IETF90 Thomas Watteyne asked for the WGLC to be
extended so that 6Lo and 6TiSCH could review and provide comments --
and we got a significant amount of feedback from these groups.

We have reviewed this feedback, and, while the reviews suggest some
changes and additions, we find there to be consensus for publishing
the document.
We are requesting the authors to incorporate the suggestions /
changes, confirm with the reviewers that their comments are addressed,
and then will give the WG one last, short opportunity to comment, and
then send it over to the IESG.

Thank you everyone who commented and provided feedback,
Warren (as OpsAWG chair)
--047d7b6721b0b9184d050077f79e-- From nobody Wed Aug 13 04:39:39 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD2F1A8702 for ; Wed, 13 Aug 2014 04:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 ck5kdZRHV8uh for ; Wed, 13 Aug 2014 04:39:35 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0184.outbound.protection.outlook.com [207.46.163.184]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16DEB1A0464 for ; Wed, 13 Aug 2014 04:39:35 -0700 (PDT) Received: from BY2PR07MB599.namprd07.prod.outlook.com (10.141.222.19) by BY2PR07MB598.namprd07.prod.outlook.com (10.141.222.16) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Wed, 13 Aug 2014 11:39:33 +0000 Received: from BY2PR07MB599.namprd07.prod.outlook.com ([10.141.222.19]) by BY2PR07MB599.namprd07.prod.outlook.com ([10.141.222.19]) with mapi id 15.00.1005.008; Wed, 13 Aug 2014 11:39:33 +0000 From: "Bradner, Scott" To: "opsawg@ietf.org" , "ops-ads@tools.ietf.org" Thread-Topic: draft minutes of the opsarea & opsawg session in Toronto posted Thread-Index: AQHPtus/BL33dQWp5k2CeSF+9bYJpA== Date: Wed, 13 Aug 2014 11:39:32 +0000 Message-ID: <071170A9-8DB5-4656-96A3-D67AB6E47B7B@harvard.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.103.229.199] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 0302D4F392 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199003)(189002)(2656002)(86362001)(85852003)(92566001)(79102001)(82746002)(101416001)(85306004)(15975445006)(76482001)(66066001)(80022001)(88552001)(83072002)(92726001)(558084003)(87936001)(4396001)(64706001)(99286002)(75432001)(74662001)(229853001)(31966008)(83716003)(74502001)(89122001)(19580395003)(107886001)(83322001)(107046002)(106356001)(106116001)(33656002)(105586002)(15202345003)(77982001)(95666004)(81542001)(20776003)(36756003)(21056001)(54356999)(81342001)(46102001)(50986999)(99396002)(93376004)(104396001)(2501001)(15302535012); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR07MB598; H:BY2PR07MB599.namprd07.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <5C999B2AE6C5A7478A44636FEDFC7BCB@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: harvard.edu Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/3JqbbExLC3iJ9bEUFA2lA68GZWs Subject: [OPSAWG] draft minutes of the opsarea & opsawg session in Toronto posted X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 11:39:37 -0000 I uploaded draft minutes for the joint opsarea and opsawg Toronto session t= o the proceedings http://www.ietf.org/proceedings/90/minutes/minutes-90-opsawg Thanks to Tom Taylor for doing these! please check to see that the minutes are accurate from your point of view Scott From nobody Wed Aug 13 06:29:53 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 825771A0166 for ; Wed, 13 Aug 2014 06:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, 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 sMDXI3sFK-gv for ; Wed, 13 Aug 2014 06:29:49 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4F60E1A0164 for ; Wed, 13 Aug 2014 06:29:48 -0700 (PDT) Received: from ncfs.snmp.com (ncfs.snmp.com [192.147.142.24]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id JAA27773; Wed, 13 Aug 2014 09:29:39 -0400 (EDT) Received: from ncfs.snmp.com (localhost.snmp.com [127.0.0.1]) by ncfs.snmp.com (8.14.5/8.14.5) with ESMTP id s7DDTc6k016127; Wed, 13 Aug 2014 09:29:38 -0400 (EDT) (envelope-from reid@snmp.com) Message-Id: <201408131329.s7DDTc6k016127@ncfs.snmp.com> To: Warren Kumari From: David Reid In-reply-to: Your message of Mon, 11 Aug 2014 17:28:58 -0400. Date: Wed, 13 Aug 2014 09:29:38 -0400 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/XvXDFxlUbRjGuVVD94ZAX20go8c Cc: "opsawg@ietf.org" , draft-hmac-sha-2-usm-snmp@tools.ietf.org Subject: Re: [OPSAWG] Call for Adoption: draft-hmac-sha-2-usm-snmp X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Reid List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 13:29:51 -0000 I support adoption by the working group. I'm willing to review the document and I also plan to implement it. -David Reid > Dear OpsAWG WG, > > This starts a Call for Adoption for draft-hmac-sha-2-usm-snmp. > > The draft is available here: > https://datatracker.ietf.org/doc/draft-hmac-sha-2-usm-snmp/ > > Please review this draft to see if you think it is suitable for > adoption by OpsAWG, > and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends Mon 25-Aug-2014. > > In addition, to satisfy RFC 6702 ("Promoting Compliance with > Intellectual Property Rights (IPR)"): > If you are personally aware of any IPR that applies to > draft-hmac-sha-2-usm-snmp, has this IPR been disclosed in compliance > with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more > details.) > > > > Thanks, > Warren Kumari > (as OpsAWG WG co-chair) > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Fri Aug 15 03:12:45 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE6E1A8A2D for ; Fri, 15 Aug 2014 03:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.268 X-Spam-Level: X-Spam-Status: No, score=-3.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] 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 1hePSKwpPDG5 for ; Fri, 15 Aug 2014 03:12:39 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6535D1A8A2E for ; Fri, 15 Aug 2014 03:12:39 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 277061A0071; Fri, 15 Aug 2014 12:12:35 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id uwjhr1LS2db2; Fri, 15 Aug 2014 12:12:31 +0200 (CEST) Received: from mail-essen-01.secunet.de (unknown [10.53.40.204]) by a.mx.secunet.com (Postfix) with ESMTP id 2566D1A0076; Fri, 15 Aug 2014 12:12:31 +0200 (CEST) Received: from [172.16.40.201] (172.16.40.201) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 15 Aug 2014 12:12:33 +0200 Message-ID: <53EDDD10.6080908@secunet.com> Date: Fri, 15 Aug 2014 12:12:32 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: t.petch , Warren Kumari , "opsawg@ietf.org" , References: <00b401cfb609$8e6b6ec0$4001a8c0@gateway.2wire.net> In-Reply-To: <00b401cfb609$8e6b6ec0$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Originating-IP: [172.16.40.201] Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/84tbVaeXF-RJeFZOFrsmhMXWDpY Subject: Re: [OPSAWG] Call for Adoption: draft-hmac-sha-2-usm-snmp X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 10:12:42 -0000 t.petch wrote on 12.08.2014 10:43: > However, I am aware of > https://datatracker.ietf.org/doc/draft-hartman-snmp-sha2/ > which looks remarkable similar in scope but different in detail. We were not aware of this draft. Indeed, at first glance it seems quite similar. Apart from formal (e.g. missing code point request, descriptions of MIB module and relationship to other MIB modules, and security considerations) and editorial aspects (our description seems more aligned with RFC 3414), I spotted the following major differences - draft-hartman-snmp-sha2 defines 3 protocols whereas our draft defines 6 protocols - draft-hartman-snmp-sha2 does not use any HMAC truncation, whereas in our draft, all HMACs are truncated. (For a discussion of HMAC truncation see our security consideration) - in draft-hartman-snmp-sha2, the length of the authentication key K is only a SHOULD, while in our draft it is fixed. - our draft defines methods for key localization and key change using the same hash function as the authentication protocol. > its distinguished list of editors. Any ideas what their intentions are? > I have no clue. Johannes > > Tom Petch > > ----- Original Message ----- > From: "Warren Kumari" > To: "opsawg@ietf.org" ; > > Sent: Monday, August 11, 2014 10:28 PM > Subject: [OPSAWG] Call for Adoption: draft-hmac-sha-2-usm-snmp > > >> Dear OpsAWG WG, >> >> This starts a Call for Adoption for draft-hmac-sha-2-usm-snmp. >> >> The draft is available here: >> https://datatracker.ietf.org/doc/draft-hmac-sha-2-usm-snmp/ >> >> Please review this draft to see if you think it is suitable for >> adoption by OpsAWG, >> and comments to the list, clearly stating your view. >> >> Please also indicate if you are willing to contribute text, review, > etc. >> >> This call for adoption ends Mon 25-Aug-2014. >> >> In addition, to satisfy RFC 6702 ("Promoting Compliance with >> Intellectual Property Rights (IPR)"): >> If you are personally aware of any IPR that applies to >> draft-hmac-sha-2-usm-snmp, has this IPR been disclosed in compliance >> with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more >> details.) >> >> >> >> Thanks, >> Warren Kumari >> (as OpsAWG WG co-chair) >> >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > -- Mit freundlichen Grüßen, Dr. Johannes Merkle Principal Beratung, Elektronische Identitäten Public Sector secunet Security Networks AG Mergenthaler Allee 77 65760 Eschborn Germany Telefon +49 201 54 54-3091 Telefax +49 201 54 54-1325 Mobil +49 175 2224439 johannes.merkle@secunet.com www.secunet.com From nobody Fri Aug 15 04:13:03 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40071A8A40 for ; Fri, 15 Aug 2014 04:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 KeacXemNErNB for ; Fri, 15 Aug 2014 04:12:59 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lrp0013.outbound.protection.outlook.com [213.199.154.13]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47D831A09D7 for ; Fri, 15 Aug 2014 04:12:59 -0700 (PDT) Received: from pc6 (109.147.210.26) by AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) with Microsoft SMTP Server (TLS) id 15.0.1010.18; Fri, 15 Aug 2014 11:12:56 +0000 Message-ID: <023801cfb879$c0c93880$4001a8c0@gateway.2wire.net> From: t.petch To: Johannes Merkle , Warren Kumari , "opsawg@ietf.org" , References: <00b401cfb609$8e6b6ec0$4001a8c0@gateway.2wire.net> <53EDDD10.6080908@secunet.com> Date: Fri, 15 Aug 2014 12:12:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [109.147.210.26] X-ClientProxiedBy: DB4PR03CA0004.eurprd03.prod.outlook.com (25.160.39.142) To AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-Forefront-PRVS: 0304E36CA3 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(979002)(6009001)(199003)(51704005)(13464003)(164054003)(189002)(377454003)(15975445006)(104166001)(15974865002)(80022001)(31966008)(74502001)(21056001)(46102001)(14496001)(95666004)(106356001)(2201001)(66066001)(50226001)(64706001)(88136002)(102836001)(47776003)(20776003)(62236002)(44716002)(101416001)(79102001)(87286001)(74662001)(76482001)(4396001)(77982001)(44736004)(61296003)(85306004)(33646002)(107046002)(107886001)(86362001)(93916002)(81816999)(77156001)(77096002)(230783001)(50466002)(42186005)(92726001)(116806002)(84392001)(92566001)(105586002)(83072002)(23756003)(81542001)(99396002)(50986999)(87976001)(85852003)(89996001)(81342001)(62966002)(81686999)(19580395003)(19580405001)(83322001)(76176999)(2501001)(74416001)(7726001)(18886075002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:; SCL:1; SRVR:AMXPR07MB054; H:pc6; FPR:; MLV:ovrnspm; PTR:InfoNoRecords; A:0; MX:1; LANG:en; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/_sS6wSOFrTZhwyFIBCeaXhABMwc Subject: Re: [OPSAWG] Call for Adoption: draft-hmac-sha-2-usm-snmp X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 11:13:01 -0000 Johannes As I said before, it is your I-D that I want to see adopted:-) I am just worried that this other one will muddy the waters at some later stage of the process, so want it out in the open now, so that this adoption call by the WG is made with full knowledge of the existence of the other one (which I hope I have achieved). Tom Petch ----- Original Message ----- From: "Johannes Merkle" To: "t.petch" ; "Warren Kumari" ; "opsawg@ietf.org" ; Sent: Friday, August 15, 2014 11:12 AM > > t.petch wrote on 12.08.2014 10:43: > > However, I am aware of > > https://datatracker.ietf.org/doc/draft-hartman-snmp-sha2/ > > which looks remarkable similar in scope but different in detail. > > We were not aware of this draft. Indeed, at first glance > it seems quite similar. Apart from formal (e.g. missing code point request, descriptions of MIB module and relationship > to other MIB modules, and security considerations) and editorial aspects (our description seems more aligned with RFC > 3414), I spotted the following major differences > > - draft-hartman-snmp-sha2 defines 3 protocols whereas our draft defines 6 protocols > > - draft-hartman-snmp-sha2 does not use any HMAC truncation, whereas in our draft, all HMACs are truncated. (For a > discussion of HMAC truncation see our security consideration) > > - in draft-hartman-snmp-sha2, the length of the authentication key K is only a SHOULD, while in our draft it is fixed. > > - our draft defines methods for key localization and key change using the same hash function as the authentication protocol. > > > > > its distinguished list of editors. Any ideas what their intentions are? > > > > I have no clue. > > Johannes > > > > > Tom Petch > > > > ----- Original Message ----- > > From: "Warren Kumari" > > To: "opsawg@ietf.org" ; > > > > Sent: Monday, August 11, 2014 10:28 PM > > Subject: [OPSAWG] Call for Adoption: draft-hmac-sha-2-usm-snmp > > > > > >> Dear OpsAWG WG, > >> > >> This starts a Call for Adoption for draft-hmac-sha-2-usm-snmp. > >> > >> The draft is available here: > >> https://datatracker.ietf.org/doc/draft-hmac-sha-2-usm-snmp/ > >> > >> Please review this draft to see if you think it is suitable for > >> adoption by OpsAWG, > >> and comments to the list, clearly stating your view. > >> > >> Please also indicate if you are willing to contribute text, review, > > etc. > >> > >> This call for adoption ends Mon 25-Aug-2014. > >> > >> In addition, to satisfy RFC 6702 ("Promoting Compliance with > >> Intellectual Property Rights (IPR)"): > >> If you are personally aware of any IPR that applies to > >> draft-hmac-sha-2-usm-snmp, has this IPR been disclosed in compliance > >> with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more > >> details.) > >> > >> > >> > >> Thanks, > >> Warren Kumari > >> (as OpsAWG WG co-chair) > >> > >> _______________________________________________ > >> OPSAWG mailing list > >> OPSAWG@ietf.org > >> https://www.ietf.org/mailman/listinfo/opsawg > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > > > > > -- > Mit freundlichen Grüßen, > Dr. Johannes Merkle > Principal Beratung, Elektronische Identitäten > Public Sector > secunet Security Networks AG > Mergenthaler Allee 77 > 65760 Eschborn > Germany > Telefon +49 201 54 54-3091 > Telefax +49 201 54 54-1325 > Mobil +49 175 2224439 > johannes.merkle@secunet.com > www.secunet.com From nobody Tue Aug 19 07:44:52 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD121A042D for ; Tue, 19 Aug 2014 07:44:51 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 vrSZ36x1imDL for ; Tue, 19 Aug 2014 07:44:49 -0700 (PDT) Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 895E51A8922 for ; Tue, 19 Aug 2014 07:44:49 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w62so6587846wes.15 for ; Tue, 19 Aug 2014 07:44:48 -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:content-type; bh=Pd0FSAZx+JNd4OlB4qQoUb6iv32WoZo4SdCYhdHOrLQ=; b=d5KZJz7FFrFby2R0W4Hpu9QgROgO1fxxWeRFj0LG2xeDrFew+jIW5adpgKO81CjXed gVWFzG7mc8oIJ12y1Eo3uYi4fnyAPqSxzebv0KTUGQ7H74RO4HJueGZq2O81B3qCmk5T zEpx0YbSSrAdUam/3uCyou75qEaAG4xzSVZ+3sYiOIcT+gPT1Dh/MpTolVrCX3UksQkk Tu8x+zHnlm1Edf26MSEDphYEIKBMHfHV76pTtBANkVuBAorE25FJq9KHt3n67lIapB+a 031/Kvo+jfuQ0TXdBpkR280h3cbN0uD917BZgYyZjHM+tzgakYXMeAJDKDUQct8UMC6+ jVXQ== X-Gm-Message-State: ALoCoQnjkJCUpEKXQ+29QmA5IElV5mbeFGXAO29WaDddC0Qrqr4Jv6QEvBPIKKiwjRl0KRRvfF+j MIME-Version: 1.0 X-Received: by 10.194.119.41 with SMTP id kr9mr18008899wjb.114.1408459488187; Tue, 19 Aug 2014 07:44:48 -0700 (PDT) Received: by 10.194.62.39 with HTTP; Tue, 19 Aug 2014 07:44:48 -0700 (PDT) In-Reply-To: References: Date: Tue, 19 Aug 2014 07:44:48 -0700 Message-ID: From: Warren Kumari To: "opsawg@ietf.org" , draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org, "opsawg-chairs@tools.ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/OozzSr3ZLVJ2MIwvbmwt88Q8MBE Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-capwap-alt-tunnel X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 14:44:51 -0000 On Mon, Aug 11, 2014 at 11:51 AM, Warren Kumari wrote: > Dear OpsAWG WG, > > The authors of draft-ietf-opsawg-capwap-alt-tunnel have indicated that > they believe that the document is ready, and have asked for Working > Group Last Call[0]. > > The draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ > > Please review this draft to see if you think it is ready for > publication and send comments to the list, clearly stating your view. > > This WGLC ends Mon 25-Aug-2014. One week has passed, and I haven't seen any feedback / review. This document is 12 pages, 8 if you remove the boilerplate / whitespace. Much if the rest of it is diagrams and such. It is, IMO, a quick and easy read, shouldn't take more than 10-15 minutes. Go on, try it. You might like it... W > > > > In addition, to satisfy RFC 6702 "Promoting Compliance with > Intellectual Property Rights (IPR)": > Are you personally aware of any IPR that applies to > draft-ietf-opsawg-capwap-alt-tunnel? If so, has this IPR been > disclosed in compliance with IETF IPR rules? > (See RFCs 3979, 4879, 3669, and 5378 for more details.) > > > Thanks, > Warren Kumari > (as OpsAWG WG co-chair) > > [0]: Actually, they asked a while back, but it slipped through the cracks. -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Tue Aug 19 13:11:26 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688DE1A6EEE for ; Tue, 19 Aug 2014 13:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 kRsG9I5yq7UW for ; Tue, 19 Aug 2014 13:11:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07D7A1A6EE8 for ; Tue, 19 Aug 2014 13:11:08 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLL21463; Tue, 19 Aug 2014 20:11:07 +0000 (GMT) Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 19 Aug 2014 21:11:06 +0100 Received: from DFWEML703-CHM.china.huawei.com ([10.193.5.130]) by dfweml706-chm ([10.193.5.225]) with mapi id 14.03.0158.001; Tue, 19 Aug 2014 13:11:01 -0700 From: John Kaippallimalil To: Warren Kumari , "opsawg@ietf.org" , "draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org" , "opsawg-chairs@tools.ietf.org" Thread-Topic: [OPSAWG] Start of WGLC for draft-ietf-opsawg-capwap-alt-tunnel Thread-Index: AQHPtZVARRFzYPArj0mVx4oJRiHW85vYgm0A///I+4A= Date: Tue, 19 Aug 2014 20:11:00 +0000 Message-ID: <6561EABF52675C45BCDACA1B4D7AA1171DA1289C@dfweml703-chm.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.64] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/aoPujGj1_fUHqXgS6iix5_AwhSI Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-capwap-alt-tunnel X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 20:11:21 -0000 Hi, I have reviewed this draft and think that the problem and descriptions are = clear. A couple of comments: 1. In Section 2.1,=20 Alternate tunnel failure handling description is good.=20 However it does not describe what happens to alternate tunnel if there is a= CAPWAP control channel keep alive failure.=20 A sentence to clarify this would be good. 2. In section 3, A general note that the message elements correspond to RFC 5415, section 4= .6 (CAPWAP Protocol Message Elements). This would make it easier to read. With these (mainly 1) addressed, I think the draft is ready. John=20 > -----Original Message----- > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Warren > Kumari > Sent: Tuesday, August 19, 2014 9:45 AM > To: opsawg@ietf.org; draft-ietf-opsawg-capwap-alt- > tunnel@tools.ietf.org; opsawg-chairs@tools.ietf.org > Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-capwap-alt- > tunnel >=20 > On Mon, Aug 11, 2014 at 11:51 AM, Warren Kumari > wrote: > > Dear OpsAWG WG, > > > > The authors of draft-ietf-opsawg-capwap-alt-tunnel have indicated > that > > they believe that the document is ready, and have asked for Working > > Group Last Call[0]. > > > > The draft is available here: > > https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ > > > > Please review this draft to see if you think it is ready for > > publication and send comments to the list, clearly stating your view. > > > > This WGLC ends Mon 25-Aug-2014. >=20 > One week has passed, and I haven't seen any feedback / review. > This document is 12 pages, 8 if you remove the boilerplate / > whitespace. Much if the rest of it is diagrams and such. It is, IMO, a > quick and easy read, shouldn't take more than 10-15 minutes. >=20 > Go on, try it. You might like it... >=20 > W >=20 >=20 >=20 > > > > > > > > In addition, to satisfy RFC 6702 "Promoting Compliance with > > Intellectual Property Rights (IPR)": > > Are you personally aware of any IPR that applies to > > draft-ietf-opsawg-capwap-alt-tunnel? If so, has this IPR been > > disclosed in compliance with IETF IPR rules? > > (See RFCs 3979, 4879, 3669, and 5378 for more details.) > > > > > > Thanks, > > Warren Kumari > > (as OpsAWG WG co-chair) > > > > [0]: Actually, they asked a while back, but it slipped through the > cracks. >=20 >=20 >=20 > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair of > pants. > ---maf >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Tue Aug 19 20:58:46 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 404671A0BEC for ; Tue, 19 Aug 2014 20:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 kkO2hKExfDLk for ; Tue, 19 Aug 2014 20:58:39 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 051AA1A0B82 for ; Tue, 19 Aug 2014 20:58:38 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id bj1so11507571pad.11 for ; Tue, 19 Aug 2014 20:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=xlPHPVGrAdOBYeZ8b09l00kBezn+DdPQGhTKp+PEGlg=; b=mQkvQqSJICPJSa3aHhUubSrti1yxL/6jjBUPm8TgY93MTPlOGsiQjMBuyR/MGA0iQq ikaWBG4B816+CAX1q6fMnwnuvaG2i24V9+tbKtBwJ2Hc8yBZs5yJ1u6xsuuHtcfzZYPk V0J8maswZlOA1Vzx3qvTH9VQRfFkpAQl5F8+87FT8lTNAze0/nx7OmjUiI0VgfF9hxHq o3t8Zkgzvb5oPLkzDtlXhJmVxKyIXK4PyyxIIo1MYMs1BGNiyZN4Qe8vDmj8hcrUNh8f 1zD/b2NMnOXDrI7G1ZZdfcVUsJ3Fm17Zhz5djOe4/RI99PZ5LbwaTLWUU07dPjlivAjx oNzA== X-Received: by 10.66.235.70 with SMTP id uk6mr27078390pac.49.1408507117542; Tue, 19 Aug 2014 20:58:37 -0700 (PDT) Received: from [183.244.208.34] ([183.244.208.34]) by mx.google.com with ESMTPSA id fq4sm31943914pdb.71.2014.08.19.20.58.34 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 19 Aug 2014 20:58:36 -0700 (PDT) Date: Wed, 20 Aug 2014 12:00:51 +0800 From: Max To: Warren Kumari Message-ID: <3E0EDE6F6E2247A9A2C0CEB4FD465B03@gmail.com> In-Reply-To: References: X-Mailer: sparrow 1.6.3 (build 1173) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="53f41d73_2443a858_3bc" Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/uwRVBQSNIYqy7BEorw_OvsVW6Cc Cc: "=?utf-8?Q?opsawg=40ietf.org?=" , draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org, "=?utf-8?Q?opsawg-chairs=40tools.ietf.org?=" Subject: [OPSAWG] =?utf-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A_?= Start of WGLC for draft-ietf-opsawg-capwap-alt-tunnel X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 03:58:43 -0000 --53f41d73_2443a858_3bc Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello all, =20 I have reviewed this document. In general, the problem and use case descr= ibed in this draft is clear and the draft is in a good shape. comments: In page 9, the Tunnel-Type definition does not have GRE tunnel type. Shou= ld this be included as one tunnel type=3F Thanks, -- =20 Dapeng Liu =E5=9C=A8 2014=E5=B9=B48=E6=9C=8819=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=BA=8C=EF= =BC=8C22:44=EF=BC=8CWarren Kumari =E5=86=99=E9=81=93=EF=BC=9A > On Mon, Aug 11, 2014 at 11:51 AM, Warren Kumari wrote: > > Dear OpsAWG WG, > > =20 > > The authors of draft-ietf-opsawg-capwap-alt-tunnel have indicated tha= t > > they believe that the document is ready, and have asked for Working > > Group Last Call=5B0=5D. > > =20 > > The draft is available here: > > https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/= > > =20 > > Please review this draft to see if you think it is ready for > > publication and send comments to the list, clearly stating your view.= > > =20 > > This WGLC ends Mon 25-Aug-2014. > =20 > One week has passed, and I haven't seen any feedback / review. > This document is 12 pages, 8 if you remove the boilerplate / > whitespace. Much if the rest of it is diagrams and such. It is, IMO, a > quick and easy read, shouldn't take more than 10-15 minutes. > =20 > Go on, try it. You might like it... > =20 > W > =20 > =20 > =20 > > =20 > > =20 > > =20 > > In addition, to satisfy R=46C 6702 =22Promoting Compliance with > > Intellectual Property Rights (IPR)=22: > > Are you personally aware of any IPR that applies to > > draft-ietf-opsawg-capwap-alt-tunnel=3F If so, has this IPR been > > disclosed in compliance with IET=46 IPR rules=3F > > (See R=46Cs 3979, 4879, 3669, and 5378 for more details.) > > =20 > > =20 > > Thanks, > > Warren Kumari > > (as OpsAWG WG co-chair) > > =20 > > =5B0=5D: Actually, they asked a while back, but it slipped through th= e cracks. > =20 > =20 > =20 > -- =20 > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > =20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > OPSAWG mailing list > OPSAWG=40ietf.org (mailto:OPSAWG=40ietf.org) > https://www.ietf.org/mailman/listinfo/opsawg > =20 > =20 --53f41d73_2443a858_3bc Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hello all,

I have reviewed this document. = In general, the problem and use case described in this draft is clear and= the draft is in a good shape.

comments:
In page 9, the Tunnel-Type definition does not have GRE tunnel type. S= hould this be included as one tunnel type=3F

Thanks,
-- 
Dapeng Liu=

=20

=E5=9C=A8 2014=E5=B9=B4= 8=E6=9C=8819=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=BA=8C=EF=BC=8C22:44=EF=BC=8CW= arren Kumari =E5=86=99=E9=81=93=EF=BC=9A

On Mon, Aug 11, 2014 at 11:51 AM= , Warren Kumari <warren=40k= umari.net> wrote:
Dea= r OpsAWG WG,

The authors of draft-ietf-opsawg-ca= pwap-alt-tunnel have indicated that
they believe that the docum= ent is ready, and have asked for Working
Group Last Call=5B0=5D= .

The draft is available here:

Please review this draft to see if you th= ink it is ready for
publication and send comments to the list, = clearly stating your view.

This WGLC ends Mon 25= -Aug-2014.

One week has passe= d, and I haven't seen any feedback / review.
This document is 1= 2 pages, 8 if you remove the boilerplate /
whitespace. Much if = the rest of it is diagrams and such. It is, IMO, a
quick and ea= sy read, shouldn't take more than 10-15 minutes.

Go on, try it. You might like it...

W






In addition, to sati= sfy R=46C 6702 =22Promoting Compliance with
Intellectual Proper= ty Rights (IPR)=22:
Are you personally aware of any IPR that ap= plies to
draft-ietf-opsawg-capwap-alt-tunnel=3F If so, has thi= s IPR been
disclosed in compliance with IET=46 IPR rules=3F
(See R=46Cs 3979, 4879, 3669, and 5378 for more details.)


Thanks,
Warren Kumari
(as OpsAWG WG co-chair)

=5B0=5D: Actually, they= asked a while back, but it slipped through the cracks.



--
I = don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels = in your pants, and later expressing
regret at having chosen tho= se particular rabid weasels and that pair
of pants.
= ---maf

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F
OPSAWG mailing list
=20 =20 =20 =20 =20

--53f41d73_2443a858_3bc-- From nobody Wed Aug 20 10:49:53 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33C871A0685 for ; Wed, 20 Aug 2014 10:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 t7NetSgKuAOk for ; Wed, 20 Aug 2014 10:49:48 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02A1B1A065E for ; Wed, 20 Aug 2014 10:49:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2269; q=dns/txt; s=iport; t=1408556984; x=1409766584; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=kfHJD+NkGbLWrHM4y9K9kGskYJ/4OFYvRySdSI37H3Y=; b=huI8GQJHWOJeQ+1W9f8QlzCxQjZ8dc9JZSdHcLq7CTzoYqwvIKLWIJaH zYKh0Bqsj4DG+R3aNikqeCD/on3QZ1Vg5iiuOrs4tlfgRoQ4EzR+yhNs0 W3NdZMlOiArF5IZ/BjZ+lgaJVMBHYp2IgW6fx41dP+mbf0bQ4ME0/mgFq Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4FAP3e9FOtJV2Z/2dsb2JhbABZgw1TVwTMPwqHBlMBgREWd4QDAQEBBAEBATc0CxACAQgRBAEBHxAnCxsBAQUDAgQOBYhCDcMAEwSPTAeETAWRJYQmhnmVCoNdbIFIgQcBAQE X-IronPort-AV: E=Sophos;i="5.01,903,1400025600"; d="scan'208";a="349010142" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 20 Aug 2014 17:49:43 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s7KHnhjK015704 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Aug 2014 17:49:43 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.173]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Wed, 20 Aug 2014 12:49:43 -0500 From: "Mark Grayson (mgrayson)" To: "warren@kumari.net" Thread-Topic: [OPSAWG] Start of WGLC for draft-ietf-opsawg-capwap-alt-tunnel Thread-Index: AQHPtZU+BoekG43POU+427O1DJH0B5vYYOYAgAA2Y+2AAPdbAIAAK1rbgABzuYD//5wXjYAAadOA//+cyZeAAGcRAA== Date: Wed, 20 Aug 2014 17:49:42 +0000 Message-ID: References: <4ED2E36A22261145861BAB2C24088B43217F4DF6@xmb-aln-x09.cisco.com> <4ED2E36A22261145861BAB2C24088B43217F5874@xmb-aln-x09.cisco.com> <4ED2E36A22261145861BAB2C24088B43217F58FE@xmb-aln-x09.cisco.com> <4ED2E36A22261145861BAB2C24088B43217F594E@xmb-aln-x09.cisco.com> In-Reply-To: <4ED2E36A22261145861BAB2C24088B43217F594E@xmb-aln-x09.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.60.160.21] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/Nxbt5uwbmovbbJKFrOKbao4_5DI Cc: "opsawg@ietf.org" , "draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org" , "opsawg-chairs@tools.ietf.org" Subject: [OPSAWG] FW: Start of WGLC for draft-ietf-opsawg-capwap-alt-tunnel X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 17:49:50 -0000 Hi all Have also taken the time to read the draft and it looks in good shape. Bes regards, Mark Grayson >_______________________________________ >From: OPSAWG [opsawg-bounces@ietf.org] on behalf of Warren Kumari >[warren@kumari.net] >Sent: Tuesday, August 19, 2014 7:44 AM >To: opsawg@ietf.org; draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org; >opsawg-chairs@tools.ietf.org >Subject: Re: [OPSAWG] Start of WGLC for >draft-ietf-opsawg-capwap-alt-tunnel > >On Mon, Aug 11, 2014 at 11:51 AM, Warren Kumari >wrote: >>Dear OpsAWG WG, >> >>The authors of draft-ietf-opsawg-capwap-alt-tunnel have indicated that >>they believe that the document is ready, and have asked for Working >>Group Last Call[0]. >> >>The draft is available here: >>https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ >> >>Please review this draft to see if you think it is ready for >>publication and send comments to the list, clearly stating your view. >> >>This WGLC ends Mon 25-Aug-2014. > >One week has passed, and I haven't seen any feedback / review. >This document is 12 pages, 8 if you remove the boilerplate / >whitespace. Much if the rest of it is diagrams and such. It is, IMO, a >quick and easy read, shouldn't take more than 10-15 minutes. > >Go on, try it. You might like it... > >W > > > >> >> >> >>In addition, to satisfy RFC 6702 "Promoting Compliance with >>Intellectual Property Rights (IPR)": >>Are you personally aware of any IPR that applies to >>draft-ietf-opsawg-capwap-alt-tunnel? If so, has this IPR been >>disclosed in compliance with IETF IPR rules? >>(See RFCs 3979, 4879, 3669, and 5378 for more details.) >> >> >>Thanks, >>Warren Kumari >>(as OpsAWG WG co-chair) >> >>[0]: Actually, they asked a while back, but it slipped through the >>cracks. > > > >-- >I don't think the execution is relevant when it was obviously a bad >idea in the first place. >This is like putting rabid weasels in your pants, and later expressing >regret at having chosen those particular rabid weasels and that pair >of pants. > ---maf > >_______________________________________________ >OPSAWG mailing list >OPSAWG@ietf.org >https://www.ietf.org/mailman/listinfo/opsawg From nobody Mon Aug 25 10:54:47 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4B7C1A01A8 for ; Mon, 25 Aug 2014 10:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.722 X-Spam-Level: X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 ddNlqbcqzw0c for ; Mon, 25 Aug 2014 10:54:44 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1A9D1A01E8 for ; Mon, 25 Aug 2014 10:53:15 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id f8so4056945wiw.5 for ; Mon, 25 Aug 2014 10:53:14 -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:content-type; bh=BSQRJJbqCgEKmSQTnHBMUpZE9YNGGhPXalz2RRFaZUU=; b=nNYBbSMY1YRHq8iZK7XPewhJE1oXohrptdZCnhXX77gT11s1i33hkj7IXPYM7Ryi9Q OdN5SAL7HsqEuMPT4t4URN2ALlKWUdPUGD62tKRBJuE+QXYtO4OTglyj1E/W7ZfcNu1i KzPqgc6mg7gvsN2Z8+jvIy90rPX5FXRrWFEYYnztlNjA5KFsj64a9LSSIsWonrJpPgge iA2P7itEronRKSvAORRzhTTRd8zJhqS8XxKiAXXl3db9BA6jAHN+5a3Szz3retiwQ3Rx oOYvJA1QknSZboNAY04GOKFRXCrZSMP8HOuqhp4us3qGgzck5eFzTIS4D02/sUhDmost JfYg== X-Gm-Message-State: ALoCoQm8ZDxvmJTviuU0Mx3LyUhSuZCTNBmvZEdC9G1s+ie508DlK7YAgoFsgLDV1Vy+q2zOX+Jt MIME-Version: 1.0 X-Received: by 10.194.86.34 with SMTP id m2mr3114445wjz.23.1408989194573; Mon, 25 Aug 2014 10:53:14 -0700 (PDT) Received: by 10.194.62.39 with HTTP; Mon, 25 Aug 2014 10:53:14 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Aug 2014 10:53:14 -0700 Message-ID: From: Warren Kumari To: "opsawg@ietf.org" , draft-hmac-sha-2-usm-snmp@tools.ietf.org, draft-hartman-snmp-sha2@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/HzcMkVHhVheVWF2dsOSbX9ePy90 Subject: Re: [OPSAWG] Call for Adoption: draft-hmac-sha-2-usm-snmp X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 17:54:45 -0000 With huge apologies to everyone involved, I'm going to extend this call for adoption for 2 days (till the 27th). After Tom found https://datatracker.ietf.org/doc/draft-hartman-snmp-sha2/ and made us aware, Scott and I chatted. We decided that we should make the authors of draft-hartman-snmp-sha2 aware of this CfA so that they could chime in, and I took it on as an action item to inform them -- and then I went off to USENIX Security / WOOT and completely forgot (it was a good conference!). So, in order to give draft-hartman-snmp-sha2 time to respond, I'm extending htis. Apologies to everyone involved. W On Mon, Aug 11, 2014 at 2:28 PM, Warren Kumari wrote: > Dear OpsAWG WG, > > This starts a Call for Adoption for draft-hmac-sha-2-usm-snmp. > > The draft is available here: > https://datatracker.ietf.org/doc/draft-hmac-sha-2-usm-snmp/ > > Please review this draft to see if you think it is suitable for > adoption by OpsAWG, > and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends Mon 25-Aug-2014. > > In addition, to satisfy RFC 6702 ("Promoting Compliance with > Intellectual Property Rights (IPR)"): > If you are personally aware of any IPR that applies to > draft-hmac-sha-2-usm-snmp, has this IPR been disclosed in compliance > with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more > details.) > > > > Thanks, > Warren Kumari > (as OpsAWG WG co-chair) -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Tue Aug 26 13:28:56 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C8D1A02A3 for ; Tue, 26 Aug 2014 13:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.132 X-Spam-Level: X-Spam-Status: No, score=0.132 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.668] 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 uVB-qdiEpW0F for ; Tue, 26 Aug 2014 13:26:27 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 637F51A882A for ; Tue, 26 Aug 2014 13:26:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 790B62017A; Tue, 26 Aug 2014 16:26:10 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydhz6-UVqQ6R; Tue, 26 Aug 2014 16:26:09 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (host-244-79.pubnet.pdx.edu [131.252.244.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 26 Aug 2014 16:26:09 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E4EA783520; Tue, 26 Aug 2014 16:26:19 -0400 (EDT) From: Sam Hartman To: Warren Kumari References: Date: Tue, 26 Aug 2014 16:26:19 -0400 In-Reply-To: (Warren Kumari's message of "Mon, 25 Aug 2014 10:53:14 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/aGMSrQfQf0YpaChOPtEADJcKIzs X-Mailman-Approved-At: Tue, 26 Aug 2014 13:28:55 -0700 Cc: "opsawg@ietf.org" , draft-hmac-sha-2-usm-snmp@tools.ietf.org, draft-hartman-snmp-sha2@tools.ietf.org Subject: Re: [OPSAWG] Call for Adoption: draft-hmac-sha-2-usm-snmp X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 20:26:28 -0000 Hi. I've reviewed both draft-hartman-snmp-sha2 and draft-hmac-sha-2-usm-snmp. In general, I believe that draft-hartman-snmp-sha2 provides a better starting point for a SHA2 authentication algorithm for USM. draft-hmac-sha-2-usm-snmp provides differences between the MD5 algorithm described in RFC 3414 and the SHa2 algorithm. In general I've found that describing a specification in terms of differences in cases where there is not a clear abstraction present is problematic. It tends to lead to implementation errors by focusing on the steps that are different rather than on all the steps that need to be performed. In this case, I think that we'll tend to see key derivation and to a lesser extent messaging processing errors because of the brief text pointing at these issues. In our draft (draft-hartman), we create an abstraction for an HMAC-based hash authentication in USM and plug sha-2 into that abstraction. I think that's a cleaner approach that will lead to higher implementation quality than the draft-hmac-sha-2-usm-snmp approach. In addition, I'm not convinced that truncating the HMAC is a good idea in this instance. If the WG decides that truncation of the HMAC is desirable, we should add a description of why that's the case and a security discussion. (I don't think the truncation proposed has significant security problems) My recommendation would be that the WG start with draft-hartman-snmp-sha2 as a basis for this work, but that the authors of draft-hmac and draft-hartman work together to make sure that all the best ideas from both proposals make their way into the final product. From nobody Tue Aug 26 19:06:15 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8591A0357 for ; Tue, 26 Aug 2014 19:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.469 X-Spam-Level: X-Spam-Status: No, score=-3.469 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 FudPtE-53iqv for ; Tue, 26 Aug 2014 19:06:09 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64C621A0326 for ; Tue, 26 Aug 2014 19:06:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLU74171; Wed, 27 Aug 2014 02:06:05 +0000 (GMT) Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 27 Aug 2014 03:06:04 +0100 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.44]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.03.0158.001; Wed, 27 Aug 2014 10:06:01 +0800 From: "Hedanping (Ana)" To: Sam Hartman , Warren Kumari Thread-Topic: Call for Adoption: draft-hmac-sha-2-usm-snmp Thread-Index: AQHPwWv+lJwQyC9oaUG7g1e786tgHJvjqQ8g Date: Wed, 27 Aug 2014 02:06:00 +0000 Message-ID: <77FA386512F0D748BC7C02C36EB1106D8D5A78@szxeml557-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.95.23] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/dbNfvEu11fC7oPUaQ7Pw-NfgPYI Cc: "opsawg@ietf.org" , "draft-hmac-sha-2-usm-snmp@tools.ietf.org" , "draft-hartman-snmp-sha2@tools.ietf.org" Subject: Re: [OPSAWG] Call for Adoption: draft-hmac-sha-2-usm-snmp X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 02:06:13 -0000 Hi all, Please see my comments between [Danping----->>]...[<<-----Danping]. -----Original Message----- From: Sam Hartman [mailto:hartmans@painless-security.com]=20 Sent: Wednesday, August 27, 2014 4:26 AM To: Warren Kumari Cc: opsawg@ietf.org; draft-hmac-sha-2-usm-snmp@tools.ietf.org; draft-hartma= n-snmp-sha2@tools.ietf.org Subject: Re: Call for Adoption: draft-hmac-sha-2-usm-snmp Hi. I've reviewed both draft-hartman-snmp-sha2 and draft-hmac-sha-2-usm-snmp. In general, I believe that draft-hartman-snmp-sha2 provides a better starti= ng point for a SHA2 authentication algorithm for USM. draft-hmac-sha-2-usm-snmp provides differences between the MD5 algorithm de= scribed in RFC 3414 and the SHa2 algorithm. In general I've found that describing a specification in terms of differen= ces in cases where there is not a clear abstraction present is problematic.= It tends to lead to implementation errors by focusing on the steps that a= re different rather than on all the steps that need to be performed. In this case, I think that we'll tend to see key derivation and to a lesser= extent messaging processing errors because of the brief text pointing at t= hese issues. In our draft (draft-hartman), we create an abstraction for an HMAC-based ha= sh authentication in USM and plug sha-2 into that abstraction. I think that= 's a cleaner approach that will lead to higher implementation quality than = the draft-hmac-sha-2-usm-snmp approach. [Danping----->>]=20 Agree. The complexity of implementing the 'draft-hmac' would tend to result= in confusions and missing steps related to the key derivation etc. 'draft-= hartman' has a better explanation of how the protocol fits into USM and SNM= P, as well as a clearer explanation of how the overall system works. It see= ms that this document is more likely to provide good long-term implementati= on results. [<<-----Danping] In addition, I'm not convinced that truncating the HMAC is a good idea in t= his instance. If the WG decides that truncation of the HMAC is desirable, = we should add a description of why that's the case and a security discussio= n. (I don't think the truncation proposed has significant security problem= s) [Danping----->>]=20 Agree. Although truncation is fairly well analyzed, there are security disa= dvantages to do it, and I don't really see significant advantages to trunca= tion. I've searched the mailing list about comments on 'draft-hmac', severa= l members who contributed to improve it, still had doubts and confusions on= the truncation to various output lengths.=20 [<<-----Danping] My recommendation would be that the WG start with draft-hartman-snmp-sha2 as a basis for this work, but that the authors of d= raft-hmac and draft-hartman work together to make sure that all the best id= eas from both proposals make their way into the final product. [Danping----->>] I support 'draft-hartman' as a basis and a proper direction towards enhanci= ng USM of SNMP. [<<-----Danping] From nobody Wed Aug 27 04:46:00 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB9471A03FF for ; Wed, 27 Aug 2014 04:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.268 X-Spam-Level: X-Spam-Status: No, score=-3.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] 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 A77ABPkcWbgv for ; Wed, 27 Aug 2014 04:45:56 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE6331A001D for ; Wed, 27 Aug 2014 04:45:55 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id B26C61A0078; Wed, 27 Aug 2014 13:45:49 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Sxm8p7bkexbU; Wed, 27 Aug 2014 13:45:41 +0200 (CEST) Received: from mail-essen-01.secunet.de (unknown [10.53.40.204]) by a.mx.secunet.com (Postfix) with ESMTP id 0BE151A0076; Wed, 27 Aug 2014 13:45:41 +0200 (CEST) Received: from [10.208.1.76] (10.208.1.76) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 27 Aug 2014 13:45:44 +0200 Message-ID: <53FDC4E7.3060406@secunet.com> Date: Wed, 27 Aug 2014 13:45:43 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Sam Hartman , Warren Kumari References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.208.1.76] Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/t9lHnWRnIMuM9SNK7D1u7cwyaVQ Cc: "opsawg@ietf.org" , draft-hmac-sha-2-usm-snmp@tools.ietf.org, draft-hartman-snmp-sha2@tools.ietf.org Subject: Re: [OPSAWG] Call for Adoption: draft-hmac-sha-2-usm-snmp X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 11:45:59 -0000 Sam Hartman wrote on 26.08.2014 22:26: > I've reviewed both draft-hartman-snmp-sha2 and > draft-hmac-sha-2-usm-snmp. > > In general, I believe that draft-hartman-snmp-sha2 provides a better > starting point for a SHA2 authentication algorithm for USM. In general, I would have no objections with this proposal (saves me some work, I guess) - if your draft really was a better starting point. However, I do not agree with this. > > draft-hmac-sha-2-usm-snmp provides differences between the MD5 algorithm > described in RFC 3414 and the SHa2 algorithm. > > In general I've found that describing a specification in terms of > differences in cases where there is not a clear abstraction present is > problematic. It tends to lead to implementation errors by focusing on > the steps that are different rather than on all the steps that need to > be performed. > The purpose of our delta-description was to make clear that the basic protocol design of RFC 3414 does not change (only the hash function and the lengths of some data) and to facilitate implementation. Existing implementations of the RFC 3414 auth protocols can be easily modified. No need to implement the protocol from scratch. In contrast, your description is very different from that in RFC 3414. So an implementor would need to re-implement the protocol from your description. I don't see why this should be less error-prone. But I am open to the approach of providing both types of description. > > In addition, I'm not convinced that truncating the HMAC is a good idea Many well-reputed cryptographers (e.g. Preneel and van Oorschot) advocate HMAC truncation. Could you please elaborate on why you think that truncation is not a good idea? > in this instance. If the WG decides that truncation of the HMAC is > desirable, we should add a description of why that's the case and a > security discussion. (I don't think the truncation proposed has > significant security problems) We have included a detailed discussion in Security Considerations. > > My recommendation would be that the WG start with > draft-hartman-snmp-sha2 as a basis for this work, but that the authors > of draft-hmac and draft-hartman work together to make sure that all the > best ideas from both proposals make their way into the final product. > I suggest that others on the list speak up and declare their preference. -- Johannes From nobody Wed Aug 27 05:04:58 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE3C1A065F for ; Wed, 27 Aug 2014 05:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] 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 B2gRNxmf2FSi for ; Wed, 27 Aug 2014 05:04:54 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B3FA1A0494 for ; Wed, 27 Aug 2014 05:04: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 5CD09120E; Wed, 27 Aug 2014 14:04:53 +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 PjNP7W139eZ1; Wed, 27 Aug 2014 14:04:50 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 27 Aug 2014 14:04:52 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id BD36F20036; Wed, 27 Aug 2014 14:04:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id kP4-lwSgTAWO; Wed, 27 Aug 2014 14:04:52 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 927B920033; Wed, 27 Aug 2014 14:04:51 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9E9842E51A95; Wed, 27 Aug 2014 14:04:50 +0200 (CEST) Date: Wed, 27 Aug 2014 14:04:50 +0200 From: Juergen Schoenwaelder To: "opsawg@ietf.org" Message-ID: <20140827120448.GA58897@elstar.local> Mail-Followup-To: "opsawg@ietf.org" , draft-hmac-sha-2-usm-snmp@tools.ietf.org, draft-hartman-snmp-sha2@tools.ietf.org References: <53FDC4E7.3060406@secunet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53FDC4E7.3060406@secunet.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/GLegcOAxJNfL9i8faHR7kPJCsP8 Cc: draft-hmac-sha-2-usm-snmp@tools.ietf.org, draft-hartman-snmp-sha2@tools.ietf.org Subject: Re: [OPSAWG] Call for Adoption: draft-hmac-sha-2-usm-snmp X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 12:04:57 -0000 On Wed, Aug 27, 2014 at 01:45:43PM +0200, Johannes Merkle wrote: > Sam Hartman wrote on 26.08.2014 22:26: > > I've reviewed both draft-hartman-snmp-sha2 and > > draft-hmac-sha-2-usm-snmp. > > > > I suggest that others on the list speak up and declare their preference. > I can't declare a clear preference since I have not time at the moment to study whether there are any real technical differences. One thing I note, however, is that draft-hartman-snmp-sha2 lacks a MIB module and thus is incomplete. In contrast, draft-hmac-sha-2-usm-snmp includes a MIB module but it surely requires some editing work to make it look nice. Note that a MIB module is needed to define the necessary object identities for the new authentication protocols. Since both documents claim to be identical to the authentication protocols proposed in [RFC3414] except the authentication algorithms used in generating digests (quoting almost literally draft-hartman-snmp-sha2), I think short and incremental text is a feature and not a bug. /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 Aug 27 12:11:16 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7C31A011E for ; Wed, 27 Aug 2014 12:11:13 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 7_rdjU75qg8n for ; Wed, 27 Aug 2014 12:11:11 -0700 (PDT) Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com [209.85.218.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D31291A010F for ; Wed, 27 Aug 2014 12:11:11 -0700 (PDT) Received: by mail-oi0-f51.google.com with SMTP id v63so495638oia.24 for ; Wed, 27 Aug 2014 12:11:11 -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:content-type; bh=f+ckNsnG8Ie2MhhdBzV0oAJmm0GJkRi/l2dLivepBuo=; b=jBZ7D1TP3RWyAvjj0tZa4K/9xrbYCuiVVYabXwtUdkDF/Gjt1PO6Nz5F8RCzq6zrFd wLSntt5Hr2jZeNUvi1hvITrVARZIIJHnxrOfIxyniNEyPRypW0DuRtb3rbEH45XZ21Rx bz+Jad8omdj6eHpEzE6Wq07w8NfIfSN4GMrjUATIxuBGYD5F/xmH3S7mr3lxcph44jIJ bC0a8lR/vB/Sh5vXDRn5OSSEjsqeN44g1o+VsZosGr+hobgVK8eYHdIhWuLX4jFgUJmW sLlQVEGZoqult1/ioefaN9PTHcOOiX1eOjvfKup0397qTd+ZQj7xkPlVJjKq7EdFxoBs Q3kQ== X-Gm-Message-State: ALoCoQm8DQO9/sj45T91W0UmGtV7v0GhEt5/9ZWvo1L91Qlqy98jglKPh1Z9f/w5/nP+4omzcJul MIME-Version: 1.0 X-Received: by 10.182.118.193 with SMTP id ko1mr35701941obb.45.1409166671136; Wed, 27 Aug 2014 12:11:11 -0700 (PDT) Received: by 10.202.172.195 with HTTP; Wed, 27 Aug 2014 12:11:11 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 Aug 2014 15:11:11 -0400 Message-ID: From: Warren Kumari To: "opsawg@ietf.org" , draft-hmac-sha-2-usm-snmp@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/xhZooFM-b_ATJ0Eow1uxe2mqRB0 Subject: Re: [OPSAWG] Call for Adoption: draft-hmac-sha-2-usm-snmp X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 19:11:13 -0000 Hi all, Scott and I just chatted about this. We see that there is interest in this topic, we think it is an important topic, and we would like to adopt /a/ document that addresses this. We'd appreciate it if the authors of draft-hmac-sha-2-usm-snmp and draft-hartman-snmp-sha2 can discuss how to move forward, possibly by combining the documents into one, or selecting one and folding in comments from the other. Again, we think that this is an important topic, and would like to get the best possible document adopted. Warren and Scott. On Mon, Aug 11, 2014 at 5:28 PM, Warren Kumari wrote: > Dear OpsAWG WG, > > This starts a Call for Adoption for draft-hmac-sha-2-usm-snmp. > > The draft is available here: > https://datatracker.ietf.org/doc/draft-hmac-sha-2-usm-snmp/ > > Please review this draft to see if you think it is suitable for > adoption by OpsAWG, > and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends Mon 25-Aug-2014. > > In addition, to satisfy RFC 6702 ("Promoting Compliance with > Intellectual Property Rights (IPR)"): > If you are personally aware of any IPR that applies to > draft-hmac-sha-2-usm-snmp, has this IPR been disclosed in compliance > with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more > details.) > > > > Thanks, > Warren Kumari > (as OpsAWG WG co-chair) -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Wed Aug 27 12:49:37 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F561A0080 for ; Wed, 27 Aug 2014 12:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, 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 8LZzv643aVKV for ; Wed, 27 Aug 2014 12:49:33 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 39E491A006C for ; Wed, 27 Aug 2014 12:49:30 -0700 (PDT) Received: from ncfs.snmp.com (ncfs.snmp.com [192.147.142.24]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id PAA10263; Wed, 27 Aug 2014 15:49:08 -0400 (EDT) Received: from ncfs.snmp.com (localhost.snmp.com [127.0.0.1]) by ncfs.snmp.com (8.14.5/8.14.5) with ESMTP id s7RJn28v069932; Wed, 27 Aug 2014 15:49:04 -0400 (EDT) (envelope-from reid@snmp.com) Message-Id: <201408271949.s7RJn28v069932@ncfs.snmp.com> To: Warren Kumari From: David Reid In-reply-to: Your message of Wed, 27 Aug 2014 15:11:11 -0400. Date: Wed, 27 Aug 2014 15:49:02 -0400 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/mDdkzd8pxT2s-_ymaPVpUX1_cg0 Cc: "opsawg@ietf.org" , draft-hmac-sha-2-usm-snmp@tools.ietf.org Subject: Re: [OPSAWG] Call for Adoption: draft-hmac-sha-2-usm-snmp X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Reid List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 19:49:35 -0000 There was a fair amount of working group discussion around draft-hmac-sha-2-usm-snmp. That feedback was incorporated into the latest version of the draft (things like adding a MIB module, deciding how many and which hmac authentication protocols to use, what descriptor names to use, mac truncation, etc). It is important that we not lose that collective input. For that reason, I prefer draft-hmac-sha-2-usm-snmp as the starting point. I think it is already pretty close to what we want. I would like to see this move quickly since there is market demand now. -David Reid > Hi all, > > Scott and I just chatted about this. > We see that there is interest in this topic, we think it is an > important topic, and we would like to adopt /a/ document that > addresses this. > > We'd appreciate it if the authors of draft-hmac-sha-2-usm-snmp and > draft-hartman-snmp-sha2 can discuss how to move forward, possibly by > combining the documents into one, or selecting one and folding in > comments from the other. > > Again, we think that this is an important topic, and would like to get > the best possible document adopted. > > Warren and Scott. > > > > On Mon, Aug 11, 2014 at 5:28 PM, Warren Kumari wrote: > > Dear OpsAWG WG, > > > > This starts a Call for Adoption for draft-hmac-sha-2-usm-snmp. > > > > The draft is available here: > > https://datatracker.ietf.org/doc/draft-hmac-sha-2-usm-snmp/ > > > > Please review this draft to see if you think it is suitable for > > adoption by OpsAWG, > > and comments to the list, clearly stating your view. > > > > Please also indicate if you are willing to contribute text, review, etc. > > > > This call for adoption ends Mon 25-Aug-2014. > > > > In addition, to satisfy RFC 6702 ("Promoting Compliance with > > Intellectual Property Rights (IPR)"): > > If you are personally aware of any IPR that applies to > > draft-hmac-sha-2-usm-snmp, has this IPR been disclosed in compliance > > with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more > > details.) > > > > Thanks, > > Warren Kumari > > (as OpsAWG WG co-chair) From nobody Wed Aug 27 13:10:18 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFCB21A02E6 for ; Wed, 27 Aug 2014 13:10:13 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 qeZq_EZ4n8iV for ; Wed, 27 Aug 2014 13:10:12 -0700 (PDT) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 183551A01FF for ; Wed, 27 Aug 2014 13:10:11 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id x12so702870wgg.28 for ; Wed, 27 Aug 2014 13:10:09 -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:content-type; bh=/IWqUi7Xg4S50f5iiG3tH8d/WYxeqLUawL8rK8Ds5eQ=; b=FfXDki3uZDQQlIoREHpOEDXEntWJT1wmyUhMS/rs3CrKAuYCo7eIcWFS0cKZHyTDeW oXWLpPObeohrTDAc4GOtdl1Vb6KU5SKt9saOoZEHPRKh4pExtPRn+7oFTZ/VeOJ3VIow fUCSpaqORV4XenvUeGwTiy3k38Lx8pZvtXuilFRBcCobNP1RsYmLJFu3y/EzCKrNZpA6 FkrPcpJdwIIlL/3RdsPGiYxeoKo5GOlwHhEMtKQKrJE7ZKrZaTSrtpikAeBZWzdeiVPP kROEJ62BsL5J/sOUXw8KB06PXggn8gAPkIOPtHJW4VwKQVHCW3GLC3xGJaPelpYgzIOn dmhA== X-Gm-Message-State: ALoCoQlvFTN+Ma0rEv4d1pGHeroSs643gqRxSH6tMocVT0HUFVvBDZmHCiNOiLxRy94WMJAcUBQs MIME-Version: 1.0 X-Received: by 10.180.212.77 with SMTP id ni13mr30881958wic.42.1409170209697; Wed, 27 Aug 2014 13:10:09 -0700 (PDT) Received: by 10.194.62.39 with HTTP; Wed, 27 Aug 2014 13:10:09 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 Aug 2014 16:10:09 -0400 Message-ID: From: Warren Kumari To: "opsawg@ietf.org" , "draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org" , "opsawg-chairs@tools.ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/27atLyoZFniqCwPdH1HtQrcatPs Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-capwap-alt-tunnel X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 20:10:13 -0000 Scott and I met earlier today. We see there as being consensus for this document to proceed - there was not a huge amount of feedback, but that is somewhat (in our opinion) simply that nature of this work. Dear authors, please fold in / address the comments below and we can move this along. Also, we are still waiting on confirmation from Z. Cao on IPR... W On Mon, Aug 11, 2014 at 2:51 PM, Warren Kumari wrote: > Dear OpsAWG WG, > > The authors of draft-ietf-opsawg-capwap-alt-tunnel have indicated that > they believe that the document is ready, and have asked for Working > Group Last Call[0]. > > The draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ > > Please review this draft to see if you think it is ready for > publication and send comments to the list, clearly stating your view. > > This WGLC ends Mon 25-Aug-2014. > > > > In addition, to satisfy RFC 6702 "Promoting Compliance with > Intellectual Property Rights (IPR)": > Are you personally aware of any IPR that applies to > draft-ietf-opsawg-capwap-alt-tunnel? If so, has this IPR been > disclosed in compliance with IETF IPR rules? > (See RFCs 3979, 4879, 3669, and 5378 for more details.) > > > Thanks, > Warren Kumari > (as OpsAWG WG co-chair) > > [0]: Actually, they asked a while back, but it slipped through the cracks. -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Wed Aug 27 13:17:00 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B67B41A0B75 for ; Wed, 27 Aug 2014 13:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 M6WeCL8nH2lj for ; Wed, 27 Aug 2014 13:16:53 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB1E51A2130 for ; Wed, 27 Aug 2014 13:16:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2367; q=dns/txt; s=iport; t=1409170604; x=1410380204; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=nBcm2/AWI6BH8NTE+FxS1tJgeKJ3PLBT60/cHqbzGL0=; b=V4UXajfFz4bj8/+AIpNDLXdQatGwd/UZ3aQgEEnybhfI0KjkpnYS+TnZ /vM085eWeDU8F0ZSww9PeXA+aqEXKnrt1Z6mntVx4zWjt+F6Mmt1mnu3V 56Kb/RHTOG7MUw4IAHo02tVHJwHivvPryAH18AOTCM5ojRnIENiXEm2ub k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAF47/lOtJA2H/2dsb2JhbABbgw1TVwTMJIdPAYESFneEAwEBAQQ6TwIBCBEEAQEBChQQMh0IAgQBEgiIOQENv0oTBI8bOIMvgR0BBI8bghSELZwWg15sgUiBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,413,1406592000"; d="scan'208";a="347679856" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-9.cisco.com with ESMTP; 27 Aug 2014 20:16:43 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s7RKGhAH014028 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Aug 2014 20:16:43 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.176]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Wed, 27 Aug 2014 15:16:43 -0500 From: "Rajesh Pazhyannur (rpazhyan)" To: Warren Kumari , "opsawg@ietf.org" , "draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org" , "opsawg-chairs@tools.ietf.org" Thread-Topic: Start of WGLC for draft-ietf-opsawg-capwap-alt-tunnel Thread-Index: AQHPtZU+BoekG43POU+427O1DJH0B5vlTnSA//+tw1U= Date: Wed, 27 Aug 2014 20:16:42 +0000 Message-ID: <4ED2E36A22261145861BAB2C24088B43217F78EE@xmb-aln-x09.cisco.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.70.241.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/4LuP0N2IMkbRmLNaVQeP6S0jajQ Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-capwap-alt-tunnel X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 20:16:56 -0000 Hello Warren=0A= =0A= Thank for your support.=0A= I will post an updated version with comments this week.=0A= =0A= regards=0A= =0A= Rajesh=0A= ________________________________________=0A= From: Warren Kumari [warren@kumari.net]=0A= Sent: Wednesday, August 27, 2014 1:10 PM=0A= To: opsawg@ietf.org; draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org; op= sawg-chairs@tools.ietf.org=0A= Subject: Re: Start of WGLC for draft-ietf-opsawg-capwap-alt-tunnel=0A= =0A= Scott and I met earlier today.=0A= =0A= We see there as being consensus for this document to proceed - there=0A= was not a huge amount of feedback, but that is somewhat (in our=0A= opinion) simply that nature of this work.=0A= =0A= Dear authors, please fold in / address the comments below and we can=0A= move this along.=0A= Also, we are still waiting on confirmation from Z. Cao on IPR...=0A= =0A= W=0A= =0A= On Mon, Aug 11, 2014 at 2:51 PM, Warren Kumari wrote:= =0A= > Dear OpsAWG WG,=0A= >=0A= > The authors of draft-ietf-opsawg-capwap-alt-tunnel have indicated that=0A= > they believe that the document is ready, and have asked for Working=0A= > Group Last Call[0].=0A= >=0A= > The draft is available here:=0A= > https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/=0A= >=0A= > Please review this draft to see if you think it is ready for=0A= > publication and send comments to the list, clearly stating your view.=0A= >=0A= > This WGLC ends Mon 25-Aug-2014.=0A= >=0A= >=0A= >=0A= > In addition, to satisfy RFC 6702 "Promoting Compliance with=0A= > Intellectual Property Rights (IPR)":=0A= > Are you personally aware of any IPR that applies to=0A= > draft-ietf-opsawg-capwap-alt-tunnel? If so, has this IPR been=0A= > disclosed in compliance with IETF IPR rules?=0A= > (See RFCs 3979, 4879, 3669, and 5378 for more details.)=0A= >=0A= >=0A= > Thanks,=0A= > Warren Kumari=0A= > (as OpsAWG WG co-chair)=0A= >=0A= > [0]: Actually, they asked a while back, but it slipped through the cracks= .=0A= =0A= =0A= =0A= --=0A= I don't think the execution is relevant when it was obviously a bad=0A= idea in the first place.=0A= This is like putting rabid weasels in your pants, and later expressing=0A= regret at having chosen those particular rabid weasels and that pair=0A= of pants.=0A= ---maf=0A= From nobody Wed Aug 27 21:41:12 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B85C71A0353 for ; Wed, 27 Aug 2014 21:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 RmZUrMk7RO8b for ; Wed, 27 Aug 2014 21:40:57 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 248D01A0352 for ; Wed, 27 Aug 2014 21:40:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIU79430; Thu, 28 Aug 2014 04:40:52 +0000 (GMT) Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 28 Aug 2014 05:40:51 +0100 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.44]) by szxeml415-hub.china.huawei.com ([10.82.67.154]) with mapi id 14.03.0158.001; Thu, 28 Aug 2014 12:40:48 +0800 From: "Hedanping (Ana)" To: Johannes Merkle , Sam Hartman , Warren Kumari Thread-Topic: [OPSAWG] Call for Adoption: draft-hmac-sha-2-usm-snmp Thread-Index: AQHPwWv+lJwQyC9oaUG7g1e786tgHJvjz+mAgAGQtHA= Date: Thu, 28 Aug 2014 04:40:47 +0000 Message-ID: <77FA386512F0D748BC7C02C36EB1106D8D5C26@szxeml557-mbs.china.huawei.com> References: <53FDC4E7.3060406@secunet.com> In-Reply-To: <53FDC4E7.3060406@secunet.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.95.23] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/0yZbvDB_VKHgTL2RbWoa0h1RPUM Cc: "opsawg@ietf.org" , "draft-hmac-sha-2-usm-snmp@tools.ietf.org" , "draft-hartman-snmp-sha2@tools.ietf.org" Subject: Re: [OPSAWG] Call for Adoption: draft-hmac-sha-2-usm-snmp X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 04:41:06 -0000 > Johannes wrote on 27.08.2014 19:46: >=20 > The purpose of our delta-description was to make clear that the basic pro= tocol > design of RFC 3414 does not change (only the hash function and the length= s of > some data) and to facilitate implementation. Existing implementations of = the > RFC > 3414 auth protocols can be easily modified. No need to implement the prot= ocol > from scratch. >=20 > In contrast, your description is very different from that in RFC 3414. So= an > implementor would need to re-implement the protocol from your description= . I > don't see why this should be less error-prone. =20 Being different from RFC3414 doesn't mean that our method (draft-hartman) n= eeds a re-implementation. Actually both drafts are quite different from RFC= 3414, 'draft-hartman' describes the SHA2 for USM in terms of key selection,= outgoing message generation, incoming message processing, which concisely = and clearly follows the logic of USM. But ' draft-hmac' makes diversion to = the truncation issue and its definition to MIB.=20 What really matters here is whether the mechanism is fit for USM and as you= agree, whether the mechanism is easy and practical to be implemented. > But I am open to the approach of providing both types of description. >=20 >=20 > > > > In addition, I'm not convinced that truncating the HMAC is a good idea >=20 > Many well-reputed cryptographers (e.g. Preneel and van Oorschot) advocate > HMAC truncation. Could you please elaborate on why you think that truncat= ion > is not a good idea? >=20 Truncation is advocated doesn't mean that it is convinced to be freely appl= ied anywhere. Truncation is actually a weighted trade-off decision, it is o= pen to discuss and will not end up with a best conclusion. Normally the unc= ertainty of the parameter selection should be out of the scope of a draft. Although I admit that by truncating the output length the 'attacker can lea= rn less about the output of the compression function', it actually increase= s the risk of security and the complexity of the implementation. =20 Both of the drafts use SHA2 as an enhancement due to the already known disa= dvantage of SHA1 and MD5. Implementing SHA2 means that the output length wi= ll definitely exceed the 12 octets reserved for msgAuthenticationParameters= and we can foresee a modification of the SNMP packet format. I didn't see= the advantages by truncating SHA2 to different confusing output lengths an= d increase the risk of the security and complexity of implementation. > > in this instance. If the WG decides that truncation of the HMAC is > > desirable, we should add a description of why that's the case and a > > security discussion. (I don't think the truncation proposed has > > significant security problems) >=20 > We have included a detailed discussion in Security Considerations. >=20 It would be better when truncation length be discussed only in the security= considerations, truncation issue is more academia and might not be suitabl= e to be proposed as a formal mechanism in the main content of the draft.=20 From nobody Thu Aug 28 04:02:05 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 728081A0102 for ; Thu, 28 Aug 2014 04:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.268 X-Spam-Level: X-Spam-Status: No, score=-3.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] 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 vTofkImQWeza for ; Thu, 28 Aug 2014 04:01:58 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B61001A6F72 for ; Thu, 28 Aug 2014 04:01:57 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 4D1941A0076; Thu, 28 Aug 2014 13:01:52 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RG-KueQ70xF2; Thu, 28 Aug 2014 13:01:45 +0200 (CEST) Received: from mail-essen-01.secunet.de (unknown [10.53.40.204]) by a.mx.secunet.com (Postfix) with ESMTP id 7D2291A0071; Thu, 28 Aug 2014 13:01:45 +0200 (CEST) Received: from [10.208.1.76] (10.208.1.76) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 28 Aug 2014 13:01:48 +0200 Message-ID: <53FF0C1B.6000508@secunet.com> Date: Thu, 28 Aug 2014 13:01:47 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Hedanping (Ana)" , Sam Hartman , Warren Kumari References: <53FDC4E7.3060406@secunet.com> <77FA386512F0D748BC7C02C36EB1106D8D5C26@szxeml557-mbs.china.huawei.com> In-Reply-To: <77FA386512F0D748BC7C02C36EB1106D8D5C26@szxeml557-mbs.china.huawei.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.208.1.76] Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/2r48ryyP8yvNvwyF2OWXyiTYuNE Cc: "opsawg@ietf.org" , "draft-hmac-sha-2-usm-snmp@tools.ietf.org" , "draft-hartman-snmp-sha2@tools.ietf.org" Subject: Re: [OPSAWG] Call for Adoption: draft-hmac-sha-2-usm-snmp X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 11:02:01 -0000 Hedanping (Ana) wrote on 28.08.2014 06:40: > >> Johannes wrote on 27.08.2014 19:46: >> >> The purpose of our delta-description was to make clear that the basic protocol >> design of RFC 3414 does not change (only the hash function and the lengths of >> some data) and to facilitate implementation. Existing implementations of the >> RFC >> 3414 auth protocols can be easily modified. No need to implement the protocol >> from scratch. >> >> In contrast, your description is very different from that in RFC 3414. So an >> implementor would need to re-implement the protocol from your description. I >> don't see why this should be less error-prone. > > > Being different from RFC3414 doesn't mean that our method (draft-hartman) needs a re-implementation. Actually both drafts are quite different from RFC3414, 'draft-hartman' describes the SHA2 for USM in terms of key selection, outgoing message generation, incoming message processing, which concisely and clearly follows the logic of USM. But ' draft-hmac' makes diversion to the truncation issue and its definition to MIB. What do you mean by "' draft-hmac' makes diversion to the truncation issue"? RFC 3414 also uses truncated HMACS, so there is no deviation in this. > > What really matters here is whether the mechanism is fit for USM and as you agree, whether the mechanism is easy and practical to be implemented. > >> But I am open to the approach of providing both types of description. >> >> >>> >>> In addition, I'm not convinced that truncating the HMAC is a good idea >> >> Many well-reputed cryptographers (e.g. Preneel and van Oorschot) advocate >> HMAC truncation. Could you please elaborate on why you think that truncation >> is not a good idea? >> > > Truncation is advocated doesn't mean that it is convinced to be freely applied anywhere. Truncation is actually a weighted trade-off decision, it is open to discuss and will not end up with a best conclusion. Normally the uncertainty of the parameter selection should be out of the scope of a draft. > > Although I admit that by truncating the output length the 'attacker can learn less about the output of the compression function', it actually increases the risk of security and the complexity of the implementation. > We should not mix up these two topics: 1) Should we use truncation and, if yes, to what extend (50% or 75%)? 2) How many protocols should we specify? As to 1), I have already elaborated on the reasoning for truncation http://permalink.gmane.org/gmane.ietf.opsawg/3244 and there was some discussion on this, where most participants expressed their preference for truncation. Your statement that truncation "increases the risk of security" probably refers to the reduction of strength against collision attacks, which require n^(1/2) collected messages. At least for the protocols with HMAC output length of 192 bits or greater, we can safely consider such attacks as impractical in the foreseeable future. Just to be sure that there is no misunderstanding: The security issues of TLS with HMC truncation are caused by the MAC-then-PAD-then-Encrypt construction of TLS, see http://web.archiveorange.com/archive/v/aFZ9KRJi4JLUvLRo8Ek7#HF6Jnaf1plca1DC Are you strictly objecting to truncation or is it just not your preference? As to 2), there was already some discussion on this list where, and many expressed a preference for cutting down the list. You can find the thread here: http://comments.gmane.org/gmane.ietf.opsawg/3237 I am open to reducing the number of protocols, we just need to agree on how many and which protocols we want. If there is consensus on this list for a set of protocols, even if they do not use truncation, I will not object. > Both of the drafts use SHA2 as an enhancement due to the already known disadvantage of SHA1 and MD5. Implementing SHA2 means that the output length will definitely exceed the 12 octets reserved for msgAuthenticationParameters and we can foresee a modification of the SNMP packet format. I didn't see the advantages by truncating SHA2 to different confusing output lengths and increase the risk of the security and complexity of implementation. > >>> in this instance. If the WG decides that truncation of the HMAC is >>> desirable, we should add a description of why that's the case and a >>> security discussion. (I don't think the truncation proposed has >>> significant security problems) >> >> We have included a detailed discussion in Security Considerations. >> > > It would be better when truncation length be discussed only in the security considerations, truncation issue is more academia and might not be suitable to be proposed as a formal mechanism in the main content of the draft. > I don't get it: truncation length _is_ discussed only in the security considerations. What exactly are you objecting to? -- Johannes From nobody Thu Aug 28 12:25:36 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF22E1A889D for ; Thu, 28 Aug 2014 10:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 oUjtPWGVTI4X for ; Thu, 28 Aug 2014 10:33:59 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 379701A88A2 for ; Thu, 28 Aug 2014 10:33:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 02C1920195; Thu, 28 Aug 2014 13:33:39 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJvXOT2dizEC; Thu, 28 Aug 2014 13:33:38 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (host-244-173.pubnet.pdx.edu [131.252.244.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Thu, 28 Aug 2014 13:33:38 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 530698885A; Thu, 28 Aug 2014 13:33:54 -0400 (EDT) From: Sam Hartman To: Johannes Merkle References: <53FDC4E7.3060406@secunet.com> <77FA386512F0D748BC7C02C36EB1106D8D5C26@szxeml557-mbs.china.huawei.com> <53FF0C1B.6000508@secunet.com> Date: Thu, 28 Aug 2014 13:33:54 -0400 In-Reply-To: <53FF0C1B.6000508@secunet.com> (Johannes Merkle's message of "Thu, 28 Aug 2014 13:01:47 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/sdYBCEDeOlHljdC-i2F9P2LeqMM X-Mailman-Approved-At: Thu, 28 Aug 2014 12:25:34 -0700 Cc: "opsawg@ietf.org" , "draft-hmac-sha-2-usm-snmp@tools.ietf.org" , "draft-hartman-snmp-sha2@tools.ietf.org" Subject: Re: [OPSAWG] Call for Adoption: draft-hmac-sha-2-usm-snmp X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 17:34:01 -0000 Hi. My concern in describing things as diffs to the md5 algorithm in 3414 s that there's not a well defined abstraction there at that layer. The SNMP community has been very careful to define rules of procedure and very well-defined interfaces afor extension and for variability in SNMP. When we started work on the transport security model we considered providing differences to the existing SNMP processing. It would have been a lot less text. However, we were not using proper SNMP extension points in doing so. Extending SNMP only at its proper extension points helps in reasoning about SNMP correctness, security, etc. For the same reason abstraction helps you when coding, it helps you when working on specifications for large complex systems. Authentication algorithms in USM are a valid extension point today. However, as I read 3414, HMAC-based algorithms that work approximately like hmac-md5 are *not* a well-defined extension point. I think it is important to create a new extension point that plugs into the existing extension point of USM authentication algorithm and provides hmac-based authentication with an extensible hash function. draft-hartman tries to do that today. draft-hmac does not. I think it is important for SNMP forward evolution that we do that and only extend at maintainable extension points. For that reason, regardless of which draft the working group chooses, I believe it is important to first define a new extension point for generic hmac-based authentication algorithms that plug into the USM authentication algorithm extension point in 3414, and then to plug sha-2 into that newly created extension point. --Sam From nobody Thu Aug 28 16:19:27 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFD2D1A00F1; Thu, 28 Aug 2014 16:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 84X8LqHGkeu8; Thu, 28 Aug 2014 16:19:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 736401A0085; Thu, 28 Aug 2014 16:19:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140828231921.17791.61037.idtracker@ietfa.amsl.com> Date: Thu, 28 Aug 2014 16:19:21 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/3DMPC43xc-ve3d8h32Ii7XXxxRg Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-capwap-alt-tunnel-02.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 23:19:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. Title : Alternate Tunnel Encapsulation for Data Frames in CAPWAP Authors : Rong Zhang Zhen Cao Hui Deng Rajesh S. Pazhyannur Sri Gundavelli Li Xue Filename : draft-ietf-opsawg-capwap-alt-tunnel-02.txt Pages : 14 Date : 2014-08-28 Abstract: CAPWAP defines a specification to encapsulate a station's data frames between the Wireless Transmission Point (WTP) and Access Controller (AC) using CAPWAP. Specifically, the station's IEEE 802.11 data frames can be either locally bridged or tunneled to the AC. When tunneled, a CAPWAP data channel is used for tunneling. In many deployments it is desirable to encapsulate date frames to an entity different from the AC for example to an Access Router (AR). Further, it may also be desirable to use different tunnel encapsulations to carry the stations' data frames. This document provides a specification for this and refers to it as Alternate tunnel encapsulation. The Alternate tunnel encapsulation allows 1) the WTP to tunnel non-management data frames to an endpoint different from the AC and 2) the WTP to tunnel using one of many known encapsulation types such as IP-IP, IP-GRE, CAPWAP. The WTP may advertise support for Alternate tunnel encapsulation during the discovery or join process and AC may select one of the supported Alternate Tunnel encapsulation types while configuring the WTP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-capwap-alt-tunnel-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-capwap-alt-tunnel-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 28 23:52:05 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 579E51A0655 for ; Thu, 28 Aug 2014 23:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] 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 F0WzkyQX9jc8 for ; Thu, 28 Aug 2014 23:52:02 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8630A1A0657 for ; Thu, 28 Aug 2014 23:52:01 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 577D013FA; Fri, 29 Aug 2014 08:52: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 0sCAWMRAf5rX; Fri, 29 Aug 2014 08:51:48 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 29 Aug 2014 08:51:59 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7E3F420035; Fri, 29 Aug 2014 08:51:59 +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 eQ6Wrn0qx5MJ; Fri, 29 Aug 2014 08:51:58 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D345420033; Fri, 29 Aug 2014 08:51:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BC8252E52F6C; Fri, 29 Aug 2014 08:51:57 +0200 (CEST) Date: Fri, 29 Aug 2014 08:51:57 +0200 From: Juergen Schoenwaelder To: Sam Hartman Message-ID: <20140829065157.GB63316@elstar.local> Mail-Followup-To: Sam Hartman , Johannes Merkle , "opsawg@ietf.org" , "draft-hmac-sha-2-usm-snmp@tools.ietf.org" , "draft-hartman-snmp-sha2@tools.ietf.org" References: <53FDC4E7.3060406@secunet.com> <77FA386512F0D748BC7C02C36EB1106D8D5C26@szxeml557-mbs.china.huawei.com> <53FF0C1B.6000508@secunet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/syPVpFnEqGmXN73UlviVthWBNqE Cc: "draft-hartman-snmp-sha2@tools.ietf.org" , "opsawg@ietf.org" , "draft-hmac-sha-2-usm-snmp@tools.ietf.org" Subject: Re: [OPSAWG] Call for Adoption: draft-hmac-sha-2-usm-snmp X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 06:52:03 -0000 The SNMP architecture in RFC3411 has 'Abstract Service Interfaces' between 'Subsystems'. What we are talking about here is a possible 'extension point' within a specific Model implementing a specific Subsystem. I think these are different things and it remains unclear whether it is worth to define 'extension points' of Models (USM is a Model implementing the Security Subsystem Abstract Service Interface). At least, we should not confuse 'Abstract Service Interfaces', 'Subsystems', 'Models' and 'extension points' (which is a new concept since so far Models do not have such plugin extension points). /js On Thu, Aug 28, 2014 at 01:33:54PM -0400, Sam Hartman wrote: > Hi. > > My concern in describing things as diffs to the md5 algorithm in 3414 s > that there's not a well defined abstraction there at that layer. > > The SNMP community has been very careful to define rules of procedure > and very well-defined interfaces afor extension and for variability in > SNMP. When we started work on the transport security model we > considered providing differences to the existing SNMP processing. > It would have been a lot less text. > However, we were not using proper SNMP extension points in doing so. > Extending SNMP only at its proper extension points helps in reasoning > about SNMP correctness, security, etc. > For the same reason abstraction helps you when coding, it helps you when > working on specifications for large complex systems. > > Authentication algorithms in USM are a valid extension point today. > However, as I read 3414, HMAC-based algorithms that work approximately > like hmac-md5 are *not* a well-defined extension point. > > I think it is important to create a new extension point that plugs into > the existing extension point of USM authentication algorithm and > provides hmac-based authentication with an extensible hash function. > > draft-hartman tries to do that today. draft-hmac does not. > > I think it is important for SNMP forward evolution that we do that and > only extend at maintainable extension points. > For that reason, regardless of which draft the working group chooses, I > believe it is important to first define a new extension point for > generic hmac-based authentication algorithms that plug into the USM > authentication algorithm extension point in 3414, and then to plug sha-2 > into that newly created extension point. > > --Sam > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg -- 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 Aug 29 03:31:23 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467E31A0072 for ; Fri, 29 Aug 2014 03:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 9ejrIbtBLSmX for ; Fri, 29 Aug 2014 03:31:20 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lrp0013.outbound.protection.outlook.com [213.199.154.13]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAE831A005B for ; Fri, 29 Aug 2014 03:31:19 -0700 (PDT) Received: from pc6 (109.147.210.26) by AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) with Microsoft SMTP Server (TLS) id 15.0.1015.19; Fri, 29 Aug 2014 10:31:17 +0000 Message-ID: <02c501cfc374$35c10aa0$4001a8c0@gateway.2wire.net> From: t.petch To: Warren Kumari References: <201408271949.s7RJn28v069932@ncfs.snmp.com> Date: Fri, 29 Aug 2014 11:28:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [109.147.210.26] X-ClientProxiedBy: AM3PR01CA042.eurprd01.prod.exchangelabs.com (10.141.191.32) To AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-Forefront-PRVS: 0318501FAE X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(24454002)(189002)(13464003)(53754006)(164054003)(377454003)(52544003)(199003)(51704005)(80022001)(66066001)(104166001)(106356001)(95666004)(77096002)(81542001)(64706001)(230783001)(81342001)(116806002)(101416001)(87286001)(105586002)(85306004)(50226001)(23756003)(4396001)(110136001)(61296003)(33646002)(42186005)(20776003)(47776003)(44736004)(107046002)(76482001)(31966008)(74502001)(74662001)(46102001)(86362001)(14496001)(77982001)(90102001)(62966002)(62236002)(44716002)(79102001)(76176999)(81816999)(21056001)(50466002)(81686999)(15975445006)(50986999)(84392001)(19580405001)(89996001)(19580395003)(83072002)(85852003)(99396002)(87976001)(83322001)(77156001)(92726001)(92566001)(74416001)(7726001); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR07MB052; H:pc6; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/Kw1IDl9CbkmkJWCCpBmmDfx9FZU Cc: "opsawg@ietf.org" , draft-hmac-sha-2-usm-snmp@tools.ietf.org Subject: Re: [OPSAWG] Call for Adoption: draft-hmac-sha-2-usm-snmp X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 10:31:22 -0000 I would like to see draft-hmac proceed, pretty much as is. I find draft-hartman more complex to follow with its elements of procedure. draft-hmac is a delta to the existing USM which is what it it intending to be; you need to understand USM in order to implement it, in which case, all you need is in draft-hmac. draft-hartman contains additional information that seems extraneous and likely to confuse. Tom Petch ----- Original Message ----- From: "David Reid" To: "Warren Kumari" Cc: "opsawg@ietf.org" ; Sent: Wednesday, August 27, 2014 8:49 PM Subject: Re: [OPSAWG] Call for Adoption: draft-hmac-sha-2-usm-snmp > There was a fair amount of working group discussion around > draft-hmac-sha-2-usm-snmp. That feedback was incorporated > into the latest version of the draft (things like adding a MIB > module, deciding how many and which hmac authentication protocols > to use, what descriptor names to use, mac truncation, etc). > It is important that we not lose that collective input. For > that reason, I prefer draft-hmac-sha-2-usm-snmp as the starting > point. I think it is already pretty close to what we want. > > I would like to see this move quickly since there is market demand now. > > -David Reid > > > Hi all, > > > > Scott and I just chatted about this. > > We see that there is interest in this topic, we think it is an > > important topic, and we would like to adopt /a/ document that > > addresses this. > > > > We'd appreciate it if the authors of draft-hmac-sha-2-usm-snmp and > > draft-hartman-snmp-sha2 can discuss how to move forward, possibly by > > combining the documents into one, or selecting one and folding in > > comments from the other. > > > > Again, we think that this is an important topic, and would like to get > > the best possible document adopted. > > > > Warren and Scott. > > > > > > > > On Mon, Aug 11, 2014 at 5:28 PM, Warren Kumari wrote: > > > Dear OpsAWG WG, > > > > > > This starts a Call for Adoption for draft-hmac-sha-2-usm-snmp. > > > > > > The draft is available here: > > > https://datatracker.ietf.org/doc/draft-hmac-sha-2-usm-snmp/ > > > > > > Please review this draft to see if you think it is suitable for > > > adoption by OpsAWG, > > > and comments to the list, clearly stating your view. > > > > > > Please also indicate if you are willing to contribute text, review, etc. > > > > > > This call for adoption ends Mon 25-Aug-2014. > > > > > > In addition, to satisfy RFC 6702 ("Promoting Compliance with > > > Intellectual Property Rights (IPR)"): > > > If you are personally aware of any IPR that applies to > > > draft-hmac-sha-2-usm-snmp, has this IPR been disclosed in compliance > > > with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more > > > details.) > > > > > > Thanks, > > > Warren Kumari > > > (as OpsAWG WG co-chair) > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Fri Aug 29 05:03:46 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DADE1A0176 for ; Fri, 29 Aug 2014 05:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 wppU5TS0pzmv for ; Fri, 29 Aug 2014 05:01:37 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 789841A0172 for ; Fri, 29 Aug 2014 05:01:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 8A9A320199; Fri, 29 Aug 2014 08:01:15 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgMJuwjFjW7o; Fri, 29 Aug 2014 08:01:15 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [206.29.182.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Fri, 29 Aug 2014 08:01:15 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 53211833EC; Fri, 29 Aug 2014 08:01:32 -0400 (EDT) From: Sam Hartman To: Johannes Merkle References: <53FDC4E7.3060406@secunet.com> <77FA386512F0D748BC7C02C36EB1106D8D5C26@szxeml557-mbs.china.huawei.com> <53FF0C1B.6000508@secunet.com> <20140829065157.GB63316@elstar.local> Date: Fri, 29 Aug 2014 08:01:32 -0400 In-Reply-To: <20140829065157.GB63316@elstar.local> (Juergen Schoenwaelder's message of "Fri, 29 Aug 2014 08:51:57 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/-h3bFQEnTVXJcskYaq-T3M4PBI8 X-Mailman-Approved-At: Fri, 29 Aug 2014 05:03:46 -0700 Cc: "opsawg@ietf.org" , "draft-hmac-sha-2-usm-snmp@tools.ietf.org" , "draft-hartman-snmp-sha2@tools.ietf.org" Subject: Re: [OPSAWG] Call for Adoption: draft-hmac-sha-2-usm-snmp X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 12:01:42 -0000 >>>>> "Juergen" == Juergen Schoenwaelder writes: Juergen> At least, we should not confuse 'Abstract Service Juergen> Interfaces', 'Subsystems', 'Models' and 'extension points' Juergen> (which is a new concept since so far Models do not have Juergen> such plugin extension points). Hmm, I actually do think USM has several such extension points. There does seem to be an extension point for an authentication algorithm in the model already. It's been my experience that adding security algorithms without such extension points does tend to cause problems both in interoperability because you tend to use much less pprecision when you don't need to define a clear extension point and in security because that lack of precision tends to lead to security analysis problems. I've seen this both in the routing area and with core security protocols. I don't have enough SNMP experience to figure out whether the results will be different here. From nobody Fri Aug 29 05:25:34 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96CE31A0188 for ; Fri, 29 Aug 2014 05:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] 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 VK8Tdoai2gnh for ; Fri, 29 Aug 2014 05:25:30 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59F8A1A01F3 for ; Fri, 29 Aug 2014 05:25:30 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2B3E9747; Fri, 29 Aug 2014 14:25:29 +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 r6BDlWKlUtqo; Fri, 29 Aug 2014 14:25:27 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 29 Aug 2014 14:25:28 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6EE6320035; Fri, 29 Aug 2014 14:25:28 +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 MTe5QTX7VG7L; Fri, 29 Aug 2014 14:25:27 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1E83820033; Fri, 29 Aug 2014 14:25:27 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EA9A72E53946; Fri, 29 Aug 2014 14:25:26 +0200 (CEST) Date: Fri, 29 Aug 2014 14:25:26 +0200 From: Juergen Schoenwaelder To: Sam Hartman Message-ID: <20140829122526.GB64311@elstar.local> Mail-Followup-To: Sam Hartman , Johannes Merkle , "opsawg@ietf.org" , "draft-hmac-sha-2-usm-snmp@tools.ietf.org" , "draft-hartman-snmp-sha2@tools.ietf.org" References: <53FDC4E7.3060406@secunet.com> <77FA386512F0D748BC7C02C36EB1106D8D5C26@szxeml557-mbs.china.huawei.com> <53FF0C1B.6000508@secunet.com> <20140829065157.GB63316@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/Or1uStMYxb7G225iJK5BQgj9Drw Cc: "draft-hartman-snmp-sha2@tools.ietf.org" , "opsawg@ietf.org" , "draft-hmac-sha-2-usm-snmp@tools.ietf.org" Subject: Re: [OPSAWG] Call for Adoption: draft-hmac-sha-2-usm-snmp X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 12:25:32 -0000 On Fri, Aug 29, 2014 at 08:01:32AM -0400, Sam Hartman wrote: > >>>>> "Juergen" == Juergen Schoenwaelder writes: > > Juergen> At least, we should not confuse 'Abstract Service > Juergen> Interfaces', 'Subsystems', 'Models' and 'extension points' > Juergen> (which is a new concept since so far Models do not have > Juergen> such plugin extension points). > > Hmm, I actually do think USM has several such extension points. > There does seem to be an extension point for an authentication algorithm > in the model already. > > It's been my experience that adding security algorithms without such > extension points does tend to cause problems both in interoperability > because you tend to use much less pprecision when you don't need to > define a clear extension point and in security because that lack of > precision tends to lead to security analysis problems. I've seen this > both in the routing area and with core security protocols. > > I don't have enough SNMP experience to figure out whether the results > will be different here. > Let me try to clarify my statement. I was trying to say is that we should not use references to RFC 3011 architectural modularity in this discussion since the RFC 3011 modularity concerns subsystems not what happens in modules implementing subsystems. In particular, ISMS was struggling with the fact that the subsystems did not forsee security provided by the transport. What we are discussing here is different from that. /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 Aug 29 06:36:44 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2794B1A035E for ; Fri, 29 Aug 2014 06:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.671 X-Spam-Level: X-Spam-Status: No, score=-0.671 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, 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 5ieeTgVYXyTD for ; Fri, 29 Aug 2014 06:36:39 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 567EA1A0312 for ; Fri, 29 Aug 2014 06:36:38 -0700 (PDT) Received: from ncfs.snmp.com (ncfs.snmp.com [192.147.142.24]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id JAA14437; Fri, 29 Aug 2014 09:36:29 -0400 (EDT) Received: from ncfs.snmp.com (localhost.snmp.com [127.0.0.1]) by ncfs.snmp.com (8.14.5/8.14.5) with ESMTP id s7TDaR2H077295; Fri, 29 Aug 2014 09:36:28 -0400 (EDT) (envelope-from reid@snmp.com) Message-Id: <201408291336.s7TDaR2H077295@ncfs.snmp.com> To: "t.petch" From: David Reid In-reply-to: Your message of Fri, 29 Aug 2014 11:28:50 +0100. <02c501cfc374$35c10aa0$4001a8c0@gateway.2wire.net> Date: Fri, 29 Aug 2014 09:36:27 -0400 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/NYVMtFU_ZQaBX20qStVU_m9xaoM Cc: "opsawg@ietf.org" , draft-hmac-sha-2-usm-snmp@tools.ietf.org Subject: Re: [OPSAWG] Call for Adoption: draft-hmac-sha-2-usm-snmp X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Reid List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 13:36:41 -0000 > I would like to see draft-hmac proceed, pretty much as is. +1 -David Reid From nobody Fri Aug 29 11:34:29 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381E11A6F1F for ; Fri, 29 Aug 2014 11:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 mcmXGBf4fj7U for ; Fri, 29 Aug 2014 11:33:55 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 273CF1A6F72 for ; Fri, 29 Aug 2014 11:30:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id A274A201A1; Fri, 29 Aug 2014 14:30:36 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Nh2bmzfiMjz; Fri, 29 Aug 2014 14:30:36 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [172.56.13.160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Fri, 29 Aug 2014 14:30:36 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id AF11983F2A; Fri, 29 Aug 2014 14:30:54 -0400 (EDT) From: Sam Hartman To: Johannes Merkle References: <53FDC4E7.3060406@secunet.com> <77FA386512F0D748BC7C02C36EB1106D8D5C26@szxeml557-mbs.china.huawei.com> <53FF0C1B.6000508@secunet.com> <20140829065157.GB63316@elstar.local> <20140829122526.GB64311@elstar.local> Date: Fri, 29 Aug 2014 14:30:54 -0400 In-Reply-To: <20140829122526.GB64311@elstar.local> (Juergen Schoenwaelder's message of "Fri, 29 Aug 2014 14:25:26 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/_U4SkrAWWn8ZI_Sn8dYpEV4ZEbc X-Mailman-Approved-At: Fri, 29 Aug 2014 11:34:26 -0700 Cc: "opsawg@ietf.org" , "draft-hmac-sha-2-usm-snmp@tools.ietf.org" , "draft-hartman-snmp-sha2@tools.ietf.org" Subject: Re: [OPSAWG] Call for Adoption: draft-hmac-sha-2-usm-snmp X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 18:33:56 -0000 Thanks for your clarification. At this point I think we understand each other, and it is up to the WG to form an opinion. --Sam