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

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Tue, 24 September 2013 14:11 UTC

Return-Path: <dromasca@avaya.com>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 604B421E805F; Tue, 24 Sep 2013 07:11:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.778
X-Spam-Level:
X-Spam-Status: No, score=-102.778 tagged_above=-999 required=5 tests=[AWL=-0.179, BAYES_00=-2.599, 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 vfs3U84mJ18a; Tue, 24 Sep 2013 07:11:17 -0700 (PDT)
Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 89D8E11E812B; Tue, 24 Sep 2013 07:11:17 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvkKAN+cQVLGmAcV/2dsb2JhbABQCoJmIThSrAUHlEOBHRZ0giUBAQEBAxIoNBcEAgEIDQEDBAEBAQoUCQcyFAkIAgQBEggTB4djAQugGJxoF44OgRI4BoMXgQADmSuFKosegWaBPoIq
X-IronPort-AV: E=Sophos;i="4.90,970,1371096000"; d="scan'208";a="29640602"
Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 24 Sep 2013 10:11:16 -0400
Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 24 Sep 2013 10:08:14 -0400
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0146.000; Tue, 24 Sep 2013 16:11:14 +0200
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: Benoit Claise <bclaise@cisco.com>, "coman@ietf.org" <coman@ietf.org>, The IESG <iesg@ietf.org>, 6lo WG <6lo@ietf.org>
Thread-Topic: [6lo] [coman] WG Review: IPv6 over Networks of Resource-constrained Nodes (6lo)
Thread-Index: AQHOuSvTdpOBsM0FNUaX415I1ZVXXpnUxd+AgAAFAICAACJsQA==
Date: Tue, 24 Sep 2013 14:11:13 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128E777A@AZ-FFEXMB04.global.avaya.com>
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>
In-Reply-To: <52419C92.9040807@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.64.58.45]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [6lo] [coman] WG Review: IPv6 over Networks of Resource-constrained Nodes (6lo)
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Mailing list for discussion of a WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6lo>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Sep 2013 14:11:23 -0000

Exactly. The charter talks about 'related MIB modules'. Does this mean that the 'IPv6 over 6LoWPAN' MIB module applies to all 'link layer technologies of interest' and is all that is needed? 

Maybe all these aspects were discussed. However, when I see 'development of MIB modules' in the charter I feel we need to ask - is this what is required? 

Regards,

Dan



> -----Original Message-----
> From: Benoit Claise [mailto:bclaise@cisco.com]
> Sent: Tuesday, September 24, 2013 5:07 PM
> To: Romascanu, Dan (Dan); coman@ietf.org; The IESG; 6lo WG
> Subject: Re: [6lo] [coman] WG Review: IPv6 over Networks of Resource-
> constrained Nodes (6lo)
> 
> On 24/09/2013 15:49, Juergen Schoenwaelder wrote:
> > On Tue, Sep 24, 2013 at 03:41:38PM +0200, Benoit Claise wrote:
> >> Hi,
> >>> Hi,
> >>>
> >>> I have a couple of issues with the way this charter is worded at
> this point, which makes the scope of the proposed WG unclear to me on
> some respects.
> >>>
> >>> 1. There is careful wording about 'link layer technologies of
> interest' and about 'Security and management work that is not specific
> to the link layers being worked on is out of scope' - but no indication
> what are the criteria to identify these, or a list of initial such layer
> technologies. Is this completely open by now? Is there a process to
> discuss and select those?
> >>>
> >>> 2. 'Selected MIB modules' - Did the team working on this proposal
> make any preparation work and determine that writing MIB modules is the
> appropriate way of meeting the manageability requirements for 6lo? If
> yes, where is this documented? If no, maybe this item should be worded
> in a more general manner and talk about requirements for managing the
> IP-over-foo specifications, followed by development of the appropriate
> information models and data models (the latest may be MIB modules, or
> may be something else).
> >> I would add, for the 6lo people benefits, that
> >> http://tools.ietf.org/html/draft-ersue-constrained-mgmt-03 would be a
> >> good start.
> >> Disclaimer: maybe this draft was mentioned already. I'm not following
> >> the 6lo mailing list.
> > My understanding is that the charter refers to
> >
> > http://tools.ietf.org/html/draft-schoenw-6lowpan-mib-03
> >
> > and that it not aims at a general discussion about network management
> > of constrained devices. That is, it refers to concrete work instead of
> > abstract work.
> That's actually my point. Should we focus on developing a MIB module,
> taking for granting that SNMP is THE way to manage constrained nodes? Or
> should we ask ourselves: based on the collected management requirements,
> let's see what is more appropriate?
> You know, like I2RS is currently doing, instead of jumping to
> NETCONF/YANG directly because it seemed like the solution.
> 
> Regards, Bneoit
> 
> >
> > /js
> >