[6lo] Intended status of draft-ietf-6lo-lowpan-mib

Ulrich Herberg <ulrich@herberg.name> Wed, 23 July 2014 17:50 UTC

Return-Path: <ulrich@herberg.name>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F34341B2C0E for <6lo@ietfa.amsl.com>; Wed, 23 Jul 2014 10:50:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.378
X-Spam-Level:
X-Spam-Status: No, score=-0.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, GB_AFFORDABLE=1] 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 qYjW-PxxpXm6 for <6lo@ietfa.amsl.com>; Wed, 23 Jul 2014 10:50:22 -0700 (PDT)
Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BD531B27BA for <6lo@ietf.org>; Wed, 23 Jul 2014 10:49:44 -0700 (PDT)
Received: by mail-vc0-f169.google.com with SMTP id hu12so2864570vcb.0 for <6lo@ietf.org>; Wed, 23 Jul 2014 10:49:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=64Ta4s8FwPUh/rkziwqZRVyVSN0bxDzKscqqw612HQo=; b=eop7rfv4M8ByuTPwT2C7i+MBWerAPUnTn2LSSQbKCU2e7Ph5V/0dHFyq17z6EzM1yZ MfxvoGuLnJq6Uq6rcZWZdlWGpLXvMrRa60UonysWUxhnCvQNX74KF1NFuzdEf2Mt4Ejo qbz9/R0XnPmsdWChdJfPW+9O76wG0Ki78cP/E=
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:cc :content-type:content-transfer-encoding; bh=64Ta4s8FwPUh/rkziwqZRVyVSN0bxDzKscqqw612HQo=; b=m1mD5zZ5hzxDWhn7mbArSTjbPayAbeEIBRbpmU+1aerOxwrnee/OAue/23f1wOk+7A QNmFVcoNLIwAPUEHg7A2tkote3iQhzkBTQCKPBTjBbQMZJYdF0Jy6blo5nQTM6/SUbSX 8gi5dMYeBxOC8p9vgo+Kjitw9QfOwKwiU+uOD5R+H4z52aZTzJbmIBRJDO5NnIbNVTf+ 0E9pehEWVWswT4NmjkzB1dNY9hlsn6JRZ9AwxJEKcQzh0lLJqH/oeniO/kuz5kASLZHy QxVEPneiOvovz+0ZRKzaKTq7eJvZq3ZjtS8NKPqiwEEsnGAhyG34NIH0KrLTSSd8UMM8 pHTQ==
X-Gm-Message-State: ALoCoQlTnCTqGgPyl0xCCfX02f2xHelE0rZNou64t4DTPVFi+JlSm0++NNUMmxo7K8Yj54JlcAaO
MIME-Version: 1.0
X-Received: by 10.220.44.20 with SMTP id y20mr4571982vce.60.1406137783303; Wed, 23 Jul 2014 10:49:43 -0700 (PDT)
Received: by 10.220.70.196 with HTTP; Wed, 23 Jul 2014 10:49:43 -0700 (PDT)
Date: Wed, 23 Jul 2014 13:49:43 -0400
Message-ID: <CAK=bVC8ibiL58dK0CaCdmDk+mBQ9eTge7ATneQH5HX68UnSqLQ@mail.gmail.com>
From: Ulrich Herberg <ulrich@herberg.name>
To: "6lo@ietf.org" <6lo@ietf.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/6lo/E7icP8GwhtqyR3cfT94hFuQZasU
Cc: "Claise Benoit \(bclaise@cisco.com\)" <bclaise@cisco.com>, Brian Haberman <brian@innovationslab.net>, Barry Leiba <barryleiba@computer.org>
Subject: [6lo] Intended status of draft-ietf-6lo-lowpan-mib
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Mailing list for the 6lo 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: Wed, 23 Jul 2014 17:50:24 -0000

6lo WG,

(important: there is a question to the WG at the end of this email)

I put quite some thought on the intended status for the lowpan MIB
document in the last couple of weeks. I initially suggested it to be
Experimental
since it is unclear to me whether people will deploy it with SNMP. But
as Jürgen pointed out correctly to me, the MIB module itself is just
an API (similar to the IP MIB module), not necessarily tied to SNMP,
and the data model itself is useful. Jürgen's slides
(http://www.ietf.org/proceedings/90/slides/slides-90-6lo-3.pdf)
show the positioning in the stack well, and Jürgen demonstrated his
implementation on constrained nodes at the plugfest
(http://www.ietf.org/proceedings/90/slides/slides-90-6lo-8.pdf). The
real "experiment" could be whether it will be used with SNMP, or via
something else (e.g., using the upcoming drafts for accessing
management data models via
draft-vanderstok-core-comi-04 or draft-ietf-netconf-restconf-01), but
this is out of the scope of the MIB document itself.
I also don't think that there are competing ways for what
is in this draft, where an argument could be that it's unclear which
of multiple ways of solving the same problem. So the only reason for
going experimental would be (in my opinion) if the WG is unsure
whether the draft
reflects the right set of counters. I have not heard any concerns
about the selection of the counters during the WGLC.

My suggestion therefore would be to:
  - keep the draft Std. Track

  - add a caveat (e.g., in the introduction) that in constrained
networks SNMP may not always be affordable (although there is at least
one implementation showing that it may work in some cases), but that a
MIB module itself is just a data model and therefore not necessarily
tied to SNMP, and that it could be used with other protocols (and
perhaps an informative
reference to draft-vanderstok-core-comi?). Maybe one could also add
a description of how this MIB module fits into the IoT stack, describing
what Jürgen shows in his slides.

- update reference to the latest btle revision

- requesting publication shortly after Toronto

In addition, I also suggest to:
 - remove appendix A (JSON representation). This is non-normative, and
relies on an expired individual draft of how to represent JSON with
YANG. Either this should be normative (in which case it probably
should be its own RFC with proper normative references), or it should
not be part of this standards track document (in my opinion). Since
this is non-normative, I could live with this paragraph, but
I just don't see the value. Jürgen pointed out to me that the YANG to
JSON mapping is an active WG item in NETMOD these days, so maybe using
another reference would at least avoid the problem with the expired
individual reference.



My question to the WG is:
Does anyone object with publishing this as Std. Track?

During the meeting tomorrow, I will ask the same question, giving
everyone the opportunity to voice concerns with this.

Please also consider my proposal to add the caveat and to remove the appendix.


Best regards
Ulrich