[coman] COMAN Discussion during IETF 84

"Ersue, Mehmet (NSN - DE/Munich)" <mehmet.ersue@nsn.com> Fri, 17 August 2012 08:41 UTC

Return-Path: <mehmet.ersue@nsn.com>
X-Original-To: coman@ietfa.amsl.com
Delivered-To: coman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0881421F852E for <coman@ietfa.amsl.com>; Fri, 17 Aug 2012 01:41:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.58
X-Spam-Level:
X-Spam-Status: No, score=-106.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KPoIf-4H6kr for <coman@ietfa.amsl.com>; Fri, 17 Aug 2012 01:41:08 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id D821121F852D for <coman@ietf.org>; Fri, 17 Aug 2012 01:41:07 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q7H8f4kR002678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <coman@ietf.org>; Fri, 17 Aug 2012 10:41:04 +0200
Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q7H8evIE016387 for <coman@ietf.org>; Fri, 17 Aug 2012 10:41:04 +0200
Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 Aug 2012 10:40:56 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 17 Aug 2012 10:40:54 +0200
Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6404219C0E@DEMUEXC006.nsn-intra.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: COMAN Discussion during IETF 84
Thread-Index: Ac18VAPguFEn2JwhS16POKnPq0WIkw==
From: "Ersue, Mehmet (NSN - DE/Munich)" <mehmet.ersue@nsn.com>
To: coman@ietf.org
X-OriginalArrivalTime: 17 Aug 2012 08:40:56.0923 (UTC) FILETIME=[052832B0:01CD7C54]
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 3960
X-purgate-ID: 151667::1345192864-00003184-070EED41/0-0/0-0
Subject: [coman] COMAN Discussion during IETF 84
X-BeenThere: coman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Management of Constrained Networks and Devices <coman.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/coman>, <mailto:coman-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/coman>
List-Post: <mailto:coman@ietf.org>
List-Help: <mailto:coman-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/coman>, <mailto:coman-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Aug 2012 08:41:09 -0000

Hi All,
Coman as an activity has been introduced at IETF 84 with a 1-slider in
the Core WG session (see slide 53, 54 in
http://www.ietf.org/proceedings/84/slides/slides-84-core-0.pdf). 
Coman document development has been also discussed in the OPS Area open
session (see
http://www.ietf.org/proceedings/84/slides/slides-84-opsawg-3.pptx). 
There was an ad-hoc discussion on the COnstrained MANanagement (Coman)
activity during IETF 84 on Wednesday, August 1, 2012. 
Participants: Dominique Barthel, Carsten Bormann, Martin Bjorklund, Zhen
Cao, Benoit Claise, Bob Cole, Mehmet Ersue, Ulrich Herberg, Dan
Romascanu, Juergen Schoenwaelder, Peter van der Stok 
*	The discussion on the scope of the work was concerning whether
it should be focused on the networks with constrained devices only or
should also cover the management of constrained networks with
non-constrained devices. The group agreed to describe the use case for
constrained networks but exclude it for the detailed requirements
discussion. The requirements for the constrained network use case can be
put into the annex. 
o	However the behavior of a constrained networks with constrained
devices is interesting to look at to understand how a constrained
network (the constrainedness) changes the requirements on the management
of constrained devices. Carsten Bormann proposed to address the
management of constrainedness. 
*	Currently the document gives a top-down application-view with
use case descriptions. Compared to the top-down view it has been
proposed to look at the use cases from the bottom-up view to understand
the requirements of very constrained devices. It would be useful to
understand the requirements on simplifying the management protocols for
very constrained devices. 
*	The deployment type should be discussed, e.g. HAN and AMI have
different requirements, depending on the size of the network there are
different requirements. 
*	Class of networks should be discussed, where different type of
radio and communication technologies are in use. 
*	Zach Shelby is interested in the M2M and cellular scenario. We
should also look at other SDOs and what they have been doing so far,
e.g. ETSI device model, OMA device management, or OBIX from OASIS. 
*	Chen Zao from China Mobile stated that he finds the cellular and
mobile network use case as important. Chen can possibly contribute to
the mobile application use case and requirements. 
*	One related draft is the configuration draft in the Core WG
(http://tools.ietf.org/html/draft-nieminen-core-service-discovery-02),
which defines the basic model for configuration and initial
authentication. The model in this draft has been integrated into the
IPSO configuration profile. 
*	It has been proposed to list requirements but also features per
use case. Furthermore the size of a network should be discussed per use
case. 
*	Classifying devices based on features: 
o	provide a list of management features and level of features to
be matched to device classes and use cases, 
o	different devices in a device class might use different subsets.

*	Matching use cases to device classes: 
o	agreed to list the device categories and the assumed network
size in a use case 
o	provide examples for device classes 
*	Giving specific requirements per use case and device class 
o	planned to address in section 4. 
o	series of requirements based on FCAPS 
*	It has been suggested to reference available work on constrained
networks/devices (e.g. FP7 EU project Butler-SmartLife). Note that
Levent Gurgen (cea.fr) kindly provided draft documents (not available
publicly) of the EU project Butler-SmartLife, which we will use as an
input for the next version. 
*	A conclusion section will summarize the gaps and highlight
potential need for new work. 
I would appreciate any comments. Thank you.

Cheers, 
Mehmet