Re: [core] CBOR Encoding of Data Modeled with YANG
Michel Veillette <Michel.Veillette@trilliantinc.com> Fri, 11 December 2015 19:19 UTC
Return-Path: <Michel.Veillette@trilliantinc.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA8A81A0113 for <core@ietfa.amsl.com>; Fri, 11 Dec 2015 11:19:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 RL-vLU5KAaQN for <core@ietfa.amsl.com>; Fri, 11 Dec 2015 11:19:22 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0144.outbound.protection.outlook.com [65.55.169.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4D9D1A011D for <core@ietf.org>; Fri, 11 Dec 2015 11:19:12 -0800 (PST)
Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) with Microsoft SMTP Server (TLS) id 15.1.355.16; Fri, 11 Dec 2015 19:19:09 +0000
Received: from BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) by BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) with mapi id 15.01.0355.012; Fri, 11 Dec 2015 19:19:09 +0000
From: Michel Veillette <Michel.Veillette@trilliantinc.com>
To: Ladislav Lhotka <lhotka@nic.cz>
Thread-Topic: [core] CBOR Encoding of Data Modeled with YANG
Thread-Index: AdEtPHYWp5+Kr9OtQ0Oj//Irn0p12QGuw2eAAAChYQAACegR0AAA6emAAABLczAAAKQDAAABDzOQAAIMFIAABF3OYA==
Date: Fri, 11 Dec 2015 19:19:09 +0000
Message-ID: <BLUPR06MB1763A8D2C6AC7551361AB35CFEEA0@BLUPR06MB1763.namprd06.prod.outlook.com>
References: <BLUPR06MB176391F16B5E9D6CCC531771FE0E0@BLUPR06MB1763.namprd06.prod.outlook.com> <m2zixhwcl2.fsf@birdie.labs.nic.cz> <566A9D84.8020809@tzi.org> <BLUPR06MB1763219CCE11D928B2168FFBFEEA0@BLUPR06MB1763.namprd06.prod.outlook.com> <E1492607-F3BA-4FA5-9BD4-4F7746171747@nic.cz> <BLUPR06MB1763FBE41C0F67D60F4C6CBDFEEA0@BLUPR06MB1763.namprd06.prod.outlook.com> <88AA67DA-65ED-445A-9BD6-C06DCC270E54@nic.cz> <BLUPR06MB176364D96547D78292F89BCEFEEA0@BLUPR06MB1763.namprd06.prod.outlook.com> <FE8ADE3A-D6E5-41E3-8A31-B160B1D2C05F@nic.cz>
In-Reply-To: <FE8ADE3A-D6E5-41E3-8A31-B160B1D2C05F@nic.cz>
Accept-Language: fr-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com;
x-originating-ip: [24.225.215.88]
x-microsoft-exchange-diagnostics: 1; BLUPR06MB1763; 5:lnB2fp2440SGvBn+cBj3zH7jMJbkcHsVYuQYl0XATDhp0ombMSyYZs4fdNlf2GRZnEnRt27TPrkkC+yrHtn0ZY3JpRoNyvYcRHUDhruD08OOpI2pCdPAX8re7+ck5AioaUovPkpVKIkfScISTYZ2tw==; 24:M90on4rW5/aTrKS5mSWbTvcuh/WSt7oXf6jqjdIrQW27K587IcyfEGNscyOMdpA1UCdcSwMU0DkdhN9u1WGU1yZGI9dm45gCQK2MhgHMl2I=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1763;
x-microsoft-antispam-prvs: <BLUPR06MB17638F57415FD29AB36ACE99FEEA0@BLUPR06MB1763.namprd06.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(256376046250027);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:BLUPR06MB1763; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1763;
x-forefront-prvs: 0787459938
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(189002)(40764003)(199003)(377454003)(40100003)(11100500001)(15395725005)(5008740100001)(102836003)(3846002)(1220700001)(110136002)(5003600100002)(6116002)(189998001)(54356999)(5001960100002)(19580395003)(92566002)(1096002)(50986999)(19580405001)(586003)(76176999)(76576001)(87936001)(93886004)(575784001)(2900100001)(74316001)(99286002)(2950100001)(77096005)(15975445007)(122556002)(86362001)(66066001)(97736004)(106356001)(81156007)(5004730100002)(101416001)(105586002)(5002640100001)(10400500002)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1763; H:BLUPR06MB1763.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: trilliantinc.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Dec 2015 19:19:09.0905 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1763
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/PMwlMFf7-ZxjX48kCT9nZ5RDgpM>
Cc: Core <core@ietf.org>
Subject: Re: [core] CBOR Encoding of Data Modeled with YANG
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 11 Dec 2015 19:19:25 -0000
Hi Lada A possible solution is the assignment of an unique ID to each identify. We already assign IDs to: - Data nodes - RPCs - Input parameters - Output parameters - Notifications - Notification parameters Adding an other type of object doesn’t seem to be a big issue. Each type of objects are managed using a different name space. For example, with 1024 IDs assigned to a module, we can support: - 1024 data nodes - 1024 RPCs - unlimited number of Input parameters (local name space always allocated from 1) - unlimited number of Output parameters (local name space always allocated from 1) - 1024 Notifications - unlimited number of Notification parameters (local name space always allocated from 1) - 1024 Identities We can also allocate consecutive or disjoint ranges of IDs to the same module which avoid the issue of establishing a hard limit of objects within a module. Regards, Michel -----Original Message----- From: Ladislav Lhotka [mailto:lhotka@nic.cz] Sent: December-11-15 12:01 PM To: Michel Veillette <Michel.Veillette@trilliantinc.com> Subject: Re: [core] CBOR Encoding of Data Modeled with YANG Hi Michel, > On 11 Dec 2015, at 17:24, Michel Veillette <Michel.Veillette@trilliantinc.com> wrote: > > Hi Lada > > I things I will need some help with identity ref. > > If I take the example in RFC6020: > > "des3" identity defined in the "des" module is encoded as follow: > <crypto xmlns:des="http://example.com/des">des:des3</crypto> > > What is the corresponding encoding in JSON? > > Is it "des:des3" ? Yes, but the example is in fact quite confusing because "des" is the the module name, prefix and identity name. So the XML encoding is in fact "des-prefix:des3", and JSON encoding is "des-module-name:des3" > > What is the impacts of not encoding the chain of identity derivations on the target device? The device has to look up in the data model whether the identityref value is an identity that is derived (transitively) from the base identity specified for that identityref leaf. In the crypto example, if we have leaf algorithm { type identityref { base "crypto:crypto-alg"; } } then permissible values for an "algorithm" instance are: "des", "des3" and "aes", provided that the server advertised all three modules. Note also that in YANG 1.1 "multiple inheritance" of identities is allowed, so in general it won't be a linear chain but a directed acyclic graph. > Why we have this chain of identity derivations at the first place? It enables some kind of object-orientation with inheritance. > Is it require only by the source device to known the list of available identities? Available identities are those defined in modules advertised by the server/device. Cheers, Lada > > Thanks for your help > Regards, > Michel > > ============================================================ > > module crypto-base { > namespace "http://example.com/crypto-base"; prefix "crypto"; > > identity crypto-alg { > description "Base identity from which all crypto algorithms are > derived."; } } > > module des { > namespace "http://example.com/des"; > prefix "des"; > import "crypto-base" { > prefix "crypto"; > } > > identity des { > base "crypto:crypto-alg"; > description "DES crypto algorithm"; } > > identity des3 { > base "crypto:crypto-alg"; > description "Triple DES crypto algorithm"; } } > > module my-crypto { > namespace "http://example.com/my-crypto"; prefix mc; import > "crypto-base" { > prefix "crypto"; > } > > identity aes { > base "crypto:crypto-alg"; > } > leaf crypto { > type identityref { > base "crypto:crypto-alg"; > } > } > } > > ============================================================ > > -----Original Message----- > From: Ladislav Lhotka [mailto:lhotka@nic.cz] > Sent: December-11-15 10:32 AM > To: Michel Veillette <Michel.Veillette@trilliantinc.com> > Cc: Carsten Bormann <cabo@tzi.org>; Core <core@ietf.org> > Subject: Re: [core] CBOR Encoding of Data Modeled with YANG > > >> On 11 Dec 2015, at 16:22, Michel Veillette <Michel.Veillette@trilliantinc.com> wrote: >> >> I plan to propose an update to section 3.1.7 based on the text of draft-ietf-netmod-yang-json-06 section 6.8. >> I can either use the module name or the module ID as namespace identifier. >> For compactness, I intent to initially propose the module ID. >> >> For example, if the module ID registered for iana-if-type is 72, we will have "72:ethernetCsmacd". > > Sure, but my impression from sec. 3.1.7 is that the encoding attempts to alleviate the need for determining the chain of identity derivations from a data model and simply encode the chain in the identityref value. But maybe I am just confused. > > Cheers, Lada > >> >> Is this make sense? >> >> Regards, >> Michel >> >> -----Original Message----- >> From: Ladislav Lhotka [mailto:lhotka@nic.cz] >> Sent: December-11-15 10:05 AM >> To: Michel Veillette <Michel.Veillette@trilliantinc.com> >> Cc: Carsten Bormann <cabo@tzi.org>; Core <core@ietf.org> >> Subject: Re: [core] CBOR Encoding of Data Modeled with YANG >> >> >>> On 11 Dec 2015, at 15:50, Michel Veillette <Michel.Veillette@trilliantinc.com> wrote: >>> >>> Hi Ladislav >>> >>> About tagging and tag 4 specifically, the overhead require by them will need to be justified. >>> We need to identify which specific applications require schemaless processing of unknown data nodes. >> >> Fair enough. >> >>> >>> About identitities >>> This issue have already been mentioned by Juergen and the current >>> intent is to adopt the same representation as >>> draft-ietf-netmod-yang-json-06 >> >> Juergen questioned the need for a new namespace notation but if I >> understand correctly the example in sec. 3.1.7, in >> >> iana-interface-type.ethernetCsmacd >> >> there is no namespace at all: iana-interface-type is an identity, and so is ethernetCsmacd. >> >> Lada >> >>> >>> Regards, >>> Michel >>> >>> -----Original Message----- >>> From: Carsten Bormann [mailto:cabo@tzi.org] >>> Sent: December-11-15 4:55 AM >>> To: Ladislav Lhotka <lhotka@nic.cz> >>> Cc: Michel Veillette <Michel.Veillette@trilliantinc.com>; Core >>> <core@ietf.org> >>> Subject: Re: [core] CBOR Encoding of Data Modeled with YANG >>> >>> my 2 µJ for now... >>> >>>> 1. Would it make sense to use semantic tagging (major type 6) to >>>> distinguish numbers or strings with special semantics? Possible >>>> candidates that come to my mind are instance-identifier and >>>> identityref values. >>> >>> In general, the assumption has been that semantic information would come out of the YANG schema. Is there a case where that is not so, and we need to represent it at the representation level? >>> >>>> 2. Why is the "decimal64" type encoded as an integer and not as >>>> "decimal fraction" (major type 6, tag 4)? Whilst the decimal value >>>> can be obtained by using the leaf's definition, >>> >>> Because we can get the exponent value out of the schema, we don't need to transmit it. >>> >>>> perhaps it may simetimes be >>>> useful to be able to correctly interpret the values without using a >>>> schema. >>> >>> Right. We probably have to make up our mind how useful YANG-based information should be in a schemaless environment. If we want to make it useful, that requires quite some different thinking than what we have now. >>> >>>> 3. I think it is necessary to include namespaces/module names in >>>> the encoding of identitities (sec 3.1.7). It is probably not very >>>> likely in that particular example, but somebody could define >>>> another "iana-interface-type" identity in another module. >>>> Identities were designed to be extensible in a decentralised >>>> fashion, so the CBOR encoding should IMO also represent the namespace. >>> >>> We should take note of this problem and put it as one more objective for the identifier discussion (the hashes vs. structured IDs vs. ... one). >>> >>> Grüße, Carsten >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C
- [core] CBOR Encoding of Data Modeled with YANG Michel Veillette
- Re: [core] CBOR Encoding of Data Modeled with YANG Juergen Schoenwaelder
- Re: [core] CBOR Encoding of Data Modeled with YANG weigengyu
- Re: [core] CBOR Encoding of Data Modeled with YANG Kepeng Li
- Re: [core] CBOR Encoding of Data Modeled with YANG Michel Veillette
- Re: [core] CBOR Encoding of Data Modeled with YANG Juergen Schoenwaelder
- Re: [core] CBOR Encoding of Data Modeled with YANG Michel Veillette
- Re: [core] CBOR Encoding of Data Modeled with YANG Juergen Schoenwaelder
- Re: [core] CBOR Encoding of Data Modeled with YANG Michel Veillette
- Re: [core] CBOR Encoding of Data Modeled with YANG Juergen Schoenwaelder
- Re: [core] CBOR Encoding of Data Modeled with YANG Alexander Pelov
- Re: [core] CBOR Encoding of Data Modeled with YANG Juergen Schoenwaelder
- Re: [core] CBOR Encoding of Data Modeled with YANG Juergen Schoenwaelder
- Re: [core] CBOR Encoding of Data Modeled with YANG Alexander Pelov
- Re: [core] CBOR Encoding of Data Modeled with YANG Carsten Bormann
- Re: [core] CBOR Encoding of Data Modeled with YANG Juergen Schoenwaelder
- Re: [core] CBOR Encoding of Data Modeled with YANG Alexander Pelov
- Re: [core] CBOR Encoding of Data Modeled with YANG Juergen Schoenwaelder
- Re: [core] CBOR Encoding of Data Modeled with YANG Andy Bierman
- Re: [core] CBOR Encoding of Data Modeled with YANG Alexander Pelov
- Re: [core] CBOR Encoding of Data Modeled with YANG Andy Bierman
- Re: [core] CBOR Encoding of Data Modeled with YANG Alexander Pelov
- Re: [core] CBOR Encoding of Data Modeled with YANG Juergen Schoenwaelder
- Re: [core] CBOR Encoding of Data Modeled with YANG Andy Bierman
- Re: [core] CBOR Encoding of Data Modeled with YANG Ladislav Lhotka
- Re: [core] CBOR Encoding of Data Modeled with YANG Andy Bierman
- Re: [core] CBOR Encoding of Data Modeled with YANG Michel Veillette
- Re: [core] CBOR Encoding of Data Modeled with YANG Carsten Bormann
- Re: [core] CBOR Encoding of Data Modeled with YANG Ladislav Lhotka
- Re: [core] CBOR Encoding of Data Modeled with YANG Andy Bierman
- Re: [core] CBOR Encoding of Data Modeled with YANG Michel Veillette
- Re: [core] CBOR Encoding of Data Modeled with YANG Michel Veillette
- Re: [core] CBOR Encoding of Data Modeled with YANG Michel Veillette
- Re: [core] CBOR Encoding of Data Modeled with YANG Ladislav Lhotka
- Re: [core] CBOR Encoding of Data Modeled with YANG Ladislav Lhotka
- Re: [core] CBOR Encoding of Data Modeled with YANG peter van der Stok
- Re: [core] CBOR Encoding of Data Modeled with YANG Juergen Schoenwaelder
- Re: [core] CBOR Encoding of Data Modeled with YANG peter van der Stok
- Re: [core] CBOR Encoding of Data Modeled with YANG Andy Bierman
- Re: [core] CBOR Encoding of Data Modeled with YANG Michel Veillette
- Re: [core] CBOR Encoding of Data Modeled with YANG Andy Bierman
- Re: [core] CBOR Encoding of Data Modeled with YANG Michel Veillette
- Re: [core] CBOR Encoding of Data Modeled with YANG Juergen Schoenwaelder
- Re: [core] CBOR Encoding of Data Modeled with YANG Andy Bierman
- Re: [core] CBOR Encoding of Data Modeled with YANG Michel Veillette
- Re: [core] CBOR Encoding of Data Modeled with YANG Michel Veillette
- Re: [core] CBOR Encoding of Data Modeled with YANG Ladislav Lhotka
- Re: [core] CBOR Encoding of Data Modeled with YANG Carsten Bormann
- Re: [core] CBOR Encoding of Data Modeled with YANG Michel Veillette
- Re: [core] CBOR Encoding of Data Modeled with YANG Ladislav Lhotka
- Re: [core] CBOR Encoding of Data Modeled with YANG Michel Veillette
- Re: [core] CBOR Encoding of Data Modeled with YANG Ladislav Lhotka
- Re: [core] CBOR Encoding of Data Modeled with YANG Michel Veillette
- Re: [core] CBOR Encoding of Data Modeled with YANG Andy Bierman
- Re: [core] CBOR Encoding of Data Modeled with YANG peter van der Stok