Re: [Coma] New Maillist for the discussion on the Management of Constrained Networks and Devices

Antonio Jara <jara@um.es> Fri, 01 June 2012 14:33 UTC

Return-Path: <jara@um.es>
X-Original-To: coma@ietfa.amsl.com
Delivered-To: coma@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32EDE11E8174 for <coma@ietfa.amsl.com>; Fri, 1 Jun 2012 07:33:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.977
X-Spam-Level:
X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEb7SQTZLK79 for <coma@ietfa.amsl.com>; Fri, 1 Jun 2012 07:33:53 -0700 (PDT)
Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id D8AD111E80B0 for <coma@ietf.org>; Fri, 1 Jun 2012 07:33:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 86FA7536FF for <coma@ietf.org>; Fri, 1 Jun 2012 16:33:51 +0200 (CEST)
X-Virus-Scanned: by antispam in UMU at xenon11.um.es
Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5rTZ1-dvX9-X for <coma@ietf.org>; Fri, 1 Jun 2012 16:33:51 +0200 (CEST)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jara) by xenon11.um.es (Postfix) with ESMTPSA id E26EF535FB for <coma@ietf.org>; Fri, 1 Jun 2012 16:33:50 +0200 (CEST)
Received: by lagv3 with SMTP id v3so1719512lag.31 for <coma@ietf.org>; Fri, 01 Jun 2012 07:33:49 -0700 (PDT)
Received: by 10.152.112.138 with SMTP id iq10mr3359482lab.13.1338561229210; Fri, 01 Jun 2012 07:33:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.112.30.163 with HTTP; Fri, 1 Jun 2012 07:33:08 -0700 (PDT)
In-Reply-To: <341929CE-3341-41EC-A472-1213B6F8C320@sensinode.com>
References: <80A0822C5E9A4440A5117C2F4CD36A6403D56943@DEMUEXC006.nsn-intra.net> <4FC8CFEB.6040902@cisco.com> <341929CE-3341-41EC-A472-1213B6F8C320@sensinode.com>
From: Antonio Jara <jara@um.es>
Date: Fri, 01 Jun 2012 16:33:08 +0200
Message-ID: <CAOQrqOVgtLhqqkHCbjuCaNeQzozt8DMCU2Xvg=QRZTOXpYM1PA@mail.gmail.com>
To: Zach Shelby <zach@sensinode.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: Benoit Claise <bclaise@cisco.com>, "Ersue, Mehmet (NSN - DE/Munich)" <mehmet.ersue@nsn.com>, coma@ietf.org, Ron Bonica <rbonica@juniper.net>
Subject: Re: [Coma] New Maillist for the discussion on the Management of Constrained Networks and Devices
X-BeenThere: coma@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Management of Constrained Networks and Devices <coma.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/coma>, <mailto:coma-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/coma>
List-Post: <mailto:coma@ietf.org>
List-Help: <mailto:coma-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/coma>, <mailto:coma-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Jun 2012 14:33:54 -0000

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


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