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

Hannes Tschofenig <hannes.tschofenig@gmx.net> Mon, 25 April 2016 10:20 UTC

Return-Path: <hannes.tschofenig@gmx.net>
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 381DE12D12A for <core@ietfa.amsl.com>; Mon, 25 Apr 2016 03:20:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.597
X-Spam-Level:
X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 8_OkkzWpQymu for <core@ietfa.amsl.com>; Mon, 25 Apr 2016 03:20:01 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BBE612D093 for <core@ietf.org>; Mon, 25 Apr 2016 03:20:00 -0700 (PDT)
Received: from [192.168.10.140] ([195.149.223.228]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MHX0m-1arKEZ1Gv6-003KQ1; Mon, 25 Apr 2016 12:19:47 +0200
To: Carsten Bormann <cabo@tzi.org>, j.schoenwaelder@jacobs-university.de
References: <570A4583.2030100@tzi.org> <5718A09E.7040607@gmx.net> <BLUPR06MB1763F3B6BDE5240402576758FE6E0@BLUPR06MB1763.namprd06.prod.outlook.com> <20160421174806.GA8710@elstar.local> <571D1E63.9090003@tzi.org>
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
X-Enigmail-Draft-Status: N1110
Message-ID: <571DEF4A.50506@gmx.net>
Date: Mon, 25 Apr 2016 12:19:54 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <571D1E63.9090003@tzi.org>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="pf06uxjxWswAHbPsq0qSXg7BbJjcuSUN3"
X-Provags-ID: V03:K0:kFpEv21NBVGz0OdvPqIFx28stY/WGftprKvtuChQUm4P5MVMhcN dZje02kGLpsqFb6lfk3R9JBRSXRdhujwT3yW72pDwm7dfv2TJlAWbUkfI5S2lFQovI91Bsr EHk+csKV5Q/oOo/g5PIy2frmJtsoHGbAolgR7maj/koaEiQDLiviCBynGWSJ9BUUjTIbKKZ 2nfczfS3KhMwqMF6ar6Qg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:2Ul0nCKle/w=:oSObIPP4D0HSh+eHw1vwTK BjFLz0CiPgTxabogpx3xh0g0ItTsLGfqrq7d+rHEGBPSlKxNgI50RCeh7SkwdNoCOs55Gp50B N7QO3FlivWuapIbuygFUkQFSWkR8mZmQrPYq4S5Womm2ixUCXzWEBHe8CUCD1R2n4FZbOAgCQ LRZTlr/8fdY296RRTOp3uzfg11wh0hi+7c774DXrarKYPGLZGBfL/CqZ8Ap8Se0eeiK4KLAOA Rxi7g4JVG3Ka2BuMnMDe9jju44ho+8xFlNRUuIsZ4jWBfRdJ0PbiEV4MVQjaz0+v4+Hlaet1N ytnvFQD9m8eKe5NO61y80H+7v9qni80RxM+wwlBbiMGXfvUa0OlWjjNaHjc7x6t3vsNMmzOpf X6gJpfdGDMlhun+QgcdpLix6URUogD3rz9pmFqlhguj2HfM0eod7pE/hyo9X+BqNCy6HSNIaW 0gDWiQXxnuxqf4khbBiz/fFsFxXI6WtcWkOqObeY2ISIJGZhmOhRjpLIXmwjiNBJ1sKDIniKo KcNUWWAny4TaCKDCoBjeL3E3xZNL3WNM+iSpfKMvzdh5kEkXeWRDLJf7x2EfuaOFj07xwPY/q JhFd0zzVh0RQeiUJAXDyQB4Waj/cWuI7WPA5MEY6AXpDczeXCPUmJaP6XhZfjJdM9hYU9znd0 XOQofszDZse/rQCmR3CBIM2+f0VFBiYVJ5YiW8LI+o5Vs2AwUUHFyMkgpWUVzbaa29SidXeUB u1/s2DZ5rF9Iz4mtPZz9mcewaE0azwfnkBFcUbIFqP9akM1zn+yKcQf6XT4=
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/1tc5VSc-HiYA8Lu2i5oHLB5O0Tk>
Cc: "core@ietf.org WG" <core@ietf.org>
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: Mon, 25 Apr 2016 10:20:03 -0000

Hi Juergen, Hi Carsten,

The data modelling language used by OMA LWM2M is an XML schema and the
OMA only uses it for two purposes:

 * Adding new objects and resources to the registry allows automatic
validation (of the XML instance documents against the XML schema).

 * The XML schema really only models the data and does not attempt to
describe the interaction.

There has been no attempt to generate code from the XML instance
documents (as far as I know).

I have tried to take a subset of the device object and to describe it in
Yang. To my knowledge nobody has tried to describe all currently
registered objects with Yang.

In any case, here is what I have tried:

----

module LWM2M_Device {
	// header information
	yang-version "1";
	namespace "foobar1";			
	prefix "LWM2M_Device";
	
	// linkage statements
	import extensions {
		prefix extensions;
		ietf-yang-types@2013-07-15.yang;
	}
	
	// meta information
	organization "OMA";
	contact "foobar2";
	description
		"This object provides a range of device related information which can
be queried by the LWM2M Server, and a device reboot and factory reset
function.";
	reference
"http://technical.openmobilealliance.org/tech/profiles/LWM2M_Device-v1_0.xml";
	
	// revision history
	revision 2016-04-20 {
		description "Initial revision.";
		reference "";
	}
	
	// module definitions
	extensions:LWM2M_Object_ID "3";
	
	// typedef statements
	
	// data statements
	
	leaf Manufacturer {
		extensions:LWM2M_Resource_ID "0";
        type string;
		config true;
		description "Human readable manufacturer name";
	}
	
	leaf ModelNumber {
		extensions:LWM2M_Resource_ID "1";
		type String;
		config true;
		description "A model identifier
                (manufacturer specified string).";
	}
	
	leaf SerialNumber {
		extensions:LWM2M_Resource_ID "2";
		type String;
		config true;
		description "Serial Number.";
	}
	
	leaf AvailablePowerSources {
		extensions:LWM2M_Resource_ID "6";
		type int32 {
                  range "0..7";
                };		
		config true;
		description "
 0 – DC power
 1 – Internal Battery
 2 – External Battery
 4 – Power over Ethernet
 5 – USB
 6 – AC (Mains) power
 7 – Solar";
	}
	
	leaf BatteryLevel {
		extensions:LWM2M_Resource_ID "9";
		type int32 {
            range "0..100";
        };
		units percent;
		config false;
		description "Contains the current battery level as a percentage (with
a range from 0 to 100). This value is only valid when the value of
Available Power Sources Resource is 1.";
	}
	
	leaf MemoryFree {
		extensions:LWM2M_Resource_ID "10";
		type int32;
		units KB;
		config false;
		description "Estimated current available amount of storage space which
can store data and software in the LWM2M Device (expressed in kilobytes).";
	}
	
	leaf CurrentTime {
		extensions:LWM2M_Resource_ID "13";
		type timestamp;
		units KB;
		config false;
		description "Current UNIX time of the LWM2M Client. The LWM2M Client
should be responsible to increase this time value as every second
elapses. The LWM2M Server is able to write this Resource to make the
LWM2M Client synchronized with the LWM2M Server.";
	}
	
}

----

The problem I have is to find out whether Yang is able to also describe
the interaction model of OMA LWM2M. I believe the current understanding
is that this is not possible without some extensions. Please correct me.

Ciao
Hannes


On 04/24/2016 09:28 PM, Carsten Bormann wrote:
> Hi Juergen,
> 
> trying to read your message -- are you just commenting on the side
> conversation here or is this also a comment on the adoption call?
> 
> Grüße, Carsten
> 
> 
> Juergen Schoenwaelder wrote:
>> On Thu, Apr 21, 2016 at 05:34:50PM +0000, Michel Veillette wrote:
>>> First, LWM2M have its own modeling language encoded in xml.
>>> A file like "OMA-SUP-XML_LWM2M_Security-V1_0-20131210-C" is not fundamentally different than something than can be named security.yang.
>>> A simple xml transform can probably do the conversion between the two without any lost.
>>> LWM2M just have a simpler (subset) modeling language.
>>>
>>
>> These are pretty bold statements. Claiming something is simple and
>> knowing something is simple are sometimes different things. Have you
>> worked throught the details? Is there a decent public definition of
>> the 'simpler (subset) modeling language'? And with public I mean
>> public, not hidden behind all sorts of registration walls.
>>
>> /js
>>
> 
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>