Re: [core] ? WG adoption of draft-veillette-core-yang-cbor-mapping-00

Andy Bierman <andy@yumaworks.com> Thu, 21 April 2016 21:03 UTC

Return-Path: <andy@yumaworks.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 914E212E214 for <core@ietfa.amsl.com>; Thu, 21 Apr 2016 14:03:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
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 u3PmqYdLJiE5 for <core@ietfa.amsl.com>; Thu, 21 Apr 2016 14:03:17 -0700 (PDT)
Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0564312D9BC for <core@ietf.org>; Thu, 21 Apr 2016 14:03:17 -0700 (PDT)
Received: by mail-lb0-x234.google.com with SMTP id b1so29791643lbi.1 for <core@ietf.org>; Thu, 21 Apr 2016 14:03:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=N3cQ3H5+me0FS9IkcjSEJHpY0ad9W9dKWJ9QWGMrals=; b=dunSIoNKd5+mtdwoKLEDs2Z9p5pfcOjE468gHumLJrx4BPmzvobcympGvYjjJ7xLCu 9354zc2pW98kd0tV0c8nNn+wH2lat9oNjehvGhAvPrw3Y7R0YA1E+pE5KTlmfmkRnyB7 f7jq3cSjMfFK9pVOpbloFWmyGx2WpA/wNNsrQAI4qV89+oIkA9eHZ5C7GcoWFVZ7gla8 xvjbxaHNWfinEHachgQ3A+16vgEtrJnp110Uv3GjJpDMV1ZKu5FX0wEwtbJs7DwFqUJo fMXp0yz39ETIpep6GL1nAUhoDimMJ7PIdoiniTSyzOmYlrGXCuVAUyS9QFaQou+Vsozi THXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=N3cQ3H5+me0FS9IkcjSEJHpY0ad9W9dKWJ9QWGMrals=; b=h/ihg29iTMj4F4JUF03xbru+rGOSpXD9wMPCNAo/Yg79b6P2BCAJ939EMXElTOTMJM 93ykV4CdjRVlvfHETvKXLh5HRh7Phz0xhwVemd+S82xkAmEMS0ONEuCKdNYI0kk6FHqQ CJz96+P6PS6ne60OEZHHWofWTIhOnimwQvxlTr2svA/0ay3J17SyHwiVdtr4QkZnJQpv YqgRfoUTYtIzUZlV/Ka4YYfA114S5zGYycv6WpGFk30Z7hBUIEHn1YAbFyI/VKcor8Ui yPEQ8J3wM6tbzrk/bPrDgIhnud/ilj8PoQwnShoMncTwIDHctSdBMy4nOvInUBnnCu98 zklQ==
X-Gm-Message-State: AOPr4FWECPcYTpFtY3HliEBQLuVB2d0PPfv8G/HFowPMAb12b39fUcLdit8gcxOA3RSmrcBhXQfzKxrhHffJPA==
MIME-Version: 1.0
X-Received: by 10.112.147.101 with SMTP id tj5mr6156151lbb.119.1461272595260; Thu, 21 Apr 2016 14:03:15 -0700 (PDT)
Received: by 10.112.198.70 with HTTP; Thu, 21 Apr 2016 14:03:15 -0700 (PDT)
In-Reply-To: <20160421204630.GA8993@elstar.local>
References: <570A4583.2030100@tzi.org> <5718A09E.7040607@gmx.net> <BLUPR06MB1763F3B6BDE5240402576758FE6E0@BLUPR06MB1763.namprd06.prod.outlook.com> <20160421174806.GA8710@elstar.local> <BLUPR06MB1763C3A1543AAB909C95D20EFE6E0@BLUPR06MB1763.namprd06.prod.outlook.com> <20160421204630.GA8993@elstar.local>
Date: Thu, 21 Apr 2016 14:03:15 -0700
Message-ID: <CABCOCHQ3hXk6QN8RZmr_2O-6mdcfDBbv9huOpbGRAd-H-EdYHQ@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Michel Veillette <Michel.Veillette@trilliantinc.com>, Hannes Tschofenig <hannes.tschofenig@gmx.net>, "core@ietf.org WG" <core@ietf.org>
Content-Type: multipart/alternative; boundary="047d7b3a8bd2f601550531050902"
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/hP1QFL7q1Xl9EBSGtKM4NQTLZzY>
Subject: Re: [core] ? WG adoption of draft-veillette-core-yang-cbor-mapping-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2016 21:03:19 -0000

Hi,

I am not advocating a requirements document but it is helpful
to understand them before trying to agree on the details.
It is not just data model or nothing to consider, but what
data modeling features are really needed.

For example, YANG allows decentralized model extension.
Any module can augment another one, without any process
other than writing the module. YANG has many ways
(grouping, leafref, typedef, etc.) to easily reuse other modules.

YANG has the concept of a datastore, not just API input and output.
It has the notion of configuration vs. state, that is also relevant to NM.
Cross-object validation (e.g. must-stmt) and conditional usage (when-stmt)
is important for configuration management. It has advanced support
for module conformance (what is optional to implement? what is optional to
use?)

Is it OK if CoAP is used for purposes outside of IoT?
I think constrained networks are within the charter,
so real network management of  devices on constrained networks
seems relevant to this WG.



Andy




On Thu, Apr 21, 2016 at 1:46 PM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Thu, Apr 21, 2016 at 07:47:53PM +0000, Michel Veillette wrote:
> > Hi Juergen
> >
> > I'm not sure I can share a LWM2M definition files since peoples need
> fill a form to get access to them, see the following link.
> >
> >
> http://technical.openmobilealliance.org/Technical/technical-information/release-program/current-releases/oma-lightweightm2m-v1-0
>
> Then I can't help.
>
> > I didn't go through a formal mapping between these two modeling
> languages but following is what this mapping might look like:
> >
> > LWM2M                | YANG
> > ---------------------+---------------
> > <Object>             | module
> > <Name>               | module name
> > <Description1>       | description
> > <MultipleInstances>  | list if true, container if false
> > <Mandatory>          | mandatory
> > <Item>               | leaf if <MultipleInstances> is true, leaf-list if
> false
> >  <Name>              | leaf name
> >  <Operations>        | config
> >  <MultipleInstances> | See <Item>
> >  <Mandatory>         | mandatory
> >  <Type>              | type
> >  <RangeEnumeration>  | range or enum
> >  <Units>             | units
> >  <Description>       | description
> >
>
> The devil is usually in the details but since there is no public
> specification I do not know. It sounds somewhat surprising that an
> '<Object>' would equate a YANG module but then I simply do not know.
> Only someone who has access to the specifications and who can get
> clearance to write about a mapping according to IETF rules can work
> on this.
>
> /js
>
> PS: You shall [...] not [...] use all or any part of a Document as part
>     of a specification or standard not emanating from the Licensor
>     without the prior written consent of the Licensor [...]
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>