Re: [coman] [6lo] WG Review: IPv6 over Networks of Resource-constrained Nodes (6lo)

Carsten Bormann <cabo@tzi.org> Fri, 27 September 2013 18:43 UTC

Return-Path: <cabo@tzi.org>
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 32A2C21F9F88; Fri, 27 Sep 2013 11:43:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.179
X-Spam-Level:
X-Spam-Status: No, score=-106.179 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HA6PaW+-VePf; Fri, 27 Sep 2013 11:43:23 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id EA66C11E8162; Fri, 27 Sep 2013 11:43:17 -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.4/8.14.4) with ESMTP id r8RIhCSK008873; Fri, 27 Sep 2013 20:43:12 +0200 (CEST)
Received: from [192.168.217.105] (p54894B0C.dip0.t-ipconnect.de [84.137.75.12]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 243C8100; Fri, 27 Sep 2013 20:43:12 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <5245C405.1070808@acm.org>
Date: Fri, 27 Sep 2013 20:43:11 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <6EDE84C3-AC13-4F84-B54F-4D789A9EA445@tzi.org>
References: <20130923180202.32168.94377.idtracker@ietfa.amsl.com> <9904FB1B0159DA42B0B887B7FA8119CA128E75E5@AZ-FFEXMB04.global.avaya.com> <52419692.7050903@cisco.com> <20130924134921.GA19673@elstar.local> <52419C92.9040807@cisco.com> <20130926132817.GB25326@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA128E9913@AZ-FFEXMB04.global.avaya.com> <20130926215221.GA26059@elstar.local> <CAK=bVC-TJ1+4O+gLHTEnNqd83fuEBgMC1gN_u_xeEHN9Oi5Vig@mail.gmail.com> <20130926221814.GE26059@elstar.local> <9DD59AEB-EF1B-47B2-B81C-00E38F1534F3@tzi.org> <5245C405.1070808@acm.org>
To: Erik Nordmark <nordmark@acm.org>
X-Mailer: Apple Mail (2.1510)
Cc: coman@ietf.org, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, The IESG <iesg@ietf.org>, 6lo WG <6lo@ietf.org>
Subject: Re: [coman] [6lo] WG Review: IPv6 over Networks of Resource-constrained Nodes (6lo)
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, 27 Sep 2013 18:43:29 -0000

On Sep 27, 2013, at 19:44, Erik Nordmark <nordmark@acm.org> wrote:

> On 9/26/13 11:58 PM, Carsten Bormann wrote:
> 
>> OLD:
>>> 2. Related MIB modules
>> 
>> Hmm:
>>> 2. Related interfaces for management applications (e.g., MIB modules)
>> 
>> NEW:
>>> 2. Related MIB modules (including, where applicable, management data models using other established IETF management data modeling schemes).
> 
> Carsten,
> 
> *If* the WG and the IESG want the broader scope, then I'd suggest explicitly mentioning Yang models instead of the "other established ..." wording.

Other management formats are out there, such as syslog, IPFIX, ...
Of course, we can recharter each time one of these becomes viable for constrained node networks.
I'm not qualified to say whether YANG will be our last data modeling scheme.
It seems more rational not to wire the specific set of management information models into the charter of one group that just happens to do some now and then.

> A key question would be whether such models would cover config and operational data.
> 
> A more radical approach would be to (gasp!), only do Yang even for operational data. It is easy to map Yang to a RESTful API (see draft-bierman-netconf-yang-api) which might fit nicely with CoAP.
> But not doing SMIv2 models might be too radical?

I think that is really something that needs to be discussed both in this WG and in a broader operations/management perspective.  (It might be worthwhile to add a pointer to OPSAWG here.)
I'm not sure we need decisions before chartering 6lo.  (I'm not even sure we know the question we want decided.)

Grüße, Carsten