Re: [core] YANG to CBOR mapping version 1

Michel Veillette <Michel.Veillette@trilliantinc.com> Wed, 13 July 2016 17:06 UTC

Return-Path: <Michel.Veillette@trilliantinc.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 E068812D0DC for <core@ietfa.amsl.com>; Wed, 13 Jul 2016 10:06:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.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 GfXQWXOyJPUc for <core@ietfa.amsl.com>; Wed, 13 Jul 2016 10:06:07 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0134.outbound.protection.outlook.com [104.47.33.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2BED12D0C9 for <core@ietf.org>; Wed, 13 Jul 2016 10:06:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fJILYpxZbvGgtX9dc3rY4YvYPb/fdPUDZCCuqwk6OnQ=; b=ZPyXuaW7tFMjmDEX7F2LHXWiNfp73RJaTNEBecxqxy6fDqeFF9A1g1J+dw2BSw0T/v6ebGMGtczfrAfcEWc0hu9d2vTExa3GDp8Fw8mXZgIYPU/f/MtjhEoGKhNS3NEYCWDIuYFeU/VfARUBjPZBluBVzTPS3FWOxYymEvOCQaw=
Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB1761.namprd06.prod.outlook.com (10.162.224.147) with Microsoft SMTP Server (TLS) id 15.1.539.14; Wed, 13 Jul 2016 17:06:04 +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.0539.019; Wed, 13 Jul 2016 17:06:04 +0000
From: Michel Veillette <Michel.Veillette@trilliantinc.com>
To: "consultancy@vanderstok.org" <consultancy@vanderstok.org>
Thread-Topic: [core] YANG to CBOR mapping version 1
Thread-Index: AQHR1qK2U/a50X7m60OAxt73Sipz+qAOmnXwgAYCugCAAFEisIABBZSAgACEZ/CAACjkgIAAAPZA
Date: Wed, 13 Jul 2016 17:06:04 +0000
Message-ID: <BLUPR06MB1763D6B8ADAE036D5E63FBA3FE310@BLUPR06MB1763.namprd06.prod.outlook.com>
References: <1ed9a5d16aca7d13412259e94afc1aa2@xs4all.nl> <BLUPR06MB17639739570760661AEC32C3FE3C0@BLUPR06MB1763.namprd06.prod.outlook.com> <e18f0f45bfae89fc55df444fdd957550@xs4all.nl> <BLUPR06MB17638EB4CCB4235B5101D540FE300@BLUPR06MB1763.namprd06.prod.outlook.com> <d58ca58bd8f89b9856a2e23290a18ba8@xs4all.nl> <BLUPR06MB1763A212CD1C3386722B88D9FE310@BLUPR06MB1763.namprd06.prod.outlook.com> <8aa9950d6b8ff0cfe8968276d18cad7d@xs4all.nl>
In-Reply-To: <8aa9950d6b8ff0cfe8968276d18cad7d@xs4all.nl>
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-ms-office365-filtering-correlation-id: aac46af9-8a45-44d5-5e08-08d3ab3ff9b1
x-microsoft-exchange-diagnostics: 1; BLUPR06MB1761; 6:J4YbpnybzR1RTip35qaEEVov4HFxvX+DFgmMQw9i02xd894lSIxW0tlvyS+mfpKMutLhRw3lEBQ1DgxTqCc96JxEMTjn3mOZO+6Rqh8zqOy5pB8pVLjbziwExvXHVH0q3HuDOopkVro3A58bY2eOO7A73xfCg6w/TUm6ENn/xsj6Y9QT/5ko/+DLIz4Slo30GzqY8L0r/5sDWWa/bU0UXVds79j2AdQFyNZgV88jQfb9a1zi3z+ORD/rcfRgW3Pgfn6X/P1NyaVTCPOurNJObdwt3JSq0S99Nz0I9Jysexo=; 5:RDwWy111wruaSAjpZ5iN6LcUlBXDk1R3Gb4kgpKevKDf1AfgTb8Zq5u8WpPJcv4quIi+FYybCZw/KGBid9NQx+kLoyu0G1WOrNJ7xId0ItJEr1uRiGJHfxQvtMiopJSTMFsWYNpQzkxnxwg8J0O/fw==; 24:b1Slx2s8474x968XTWJodFOnXLB6CLPgoWksNQlaoAkf7mR/1WZzdW6GzSQXvdggIaWHZSGukl4ZPL9zCVayG8Y0Or/8poVivmeQ+MpFPb0=; 7:j9WxyA4azqNaMZw9RBmBfp6zcVB8UCrHUOqgwybkbSQGFBvc6WV5VTLbR/CiG9SSrwx6fi62BIjHE9TgXiIs2ycjBOEy7QM16PjDEBFsRS8w9G451HNMTXJM9rjdNZyL9zrDkv7w5PTcgvCmRF/hSaZrv2eeViAKhhZkoJzZJQh60zrY8IrkYQIu5p5ed4MJjb6zTRODA/cATZzq1fdxA48NuWV0uOz9+ln41+XkKCV4StFhKc1Va9RcJx5LI8eW
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1761;
x-microsoft-antispam-prvs: <BLUPR06MB17613AF1DB7364184034B534FE310@BLUPR06MB1761.namprd06.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BLUPR06MB1761; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1761;
x-forefront-prvs: 000227DA0C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(377424004)(199003)(189002)(377454003)(93886004)(2900100001)(2906002)(92566002)(2950100001)(74316002)(99286002)(122556002)(50986999)(2501003)(3280700002)(3660700001)(8936002)(4326007)(3846002)(6116002)(81156014)(81166006)(5640700001)(2351001)(76576001)(102836003)(5002640100001)(586003)(15975445007)(11100500001)(19580395003)(66066001)(86362001)(8676002)(5003600100003)(68736007)(7736002)(1730700003)(87936001)(10400500002)(101416001)(106116001)(305945005)(106356001)(77096005)(1720100001)(105586002)(76176999)(54356999)(189998001)(7846002)(9686002)(19580405001)(110136002)(7696003)(33656002)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1761; H:BLUPR06MB1763.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: trilliantinc.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2016 17:06:04.7660 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1761
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/9p7vxSfepKImKcOfHNPUhMc2npc>
Cc: Core <core@ietf.org>
Subject: Re: [core] YANG to CBOR mapping version 1
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: Wed, 13 Jul 2016 17:06:09 -0000

Hi Peter

I'm not convinced that Including in the encoding which data nodes are the keys completely solve the issue.
If the client transmit a payload with one key and the server required two keys, the payload will be rejected.
If the client transmit a payload with two keys (marked as such) and the server require one key, the payload will be rejected.
To work, both sides need to known the number of keys used by the other side and only 'ietf-cool-library' can resolve that.

Also, not making which data nodes are keys might help during the migration.

Regards,
Michel

-----Original Message-----
From: peter van der Stok [mailto:stokcons@xs4all.nl] 
Sent: Wednesday, July 13, 2016 12:55 PM
To: Michel Veillette <Michel.Veillette@trilliantinc.com>
Cc: consultancy@vanderstok.org; Core <core@ietf.org>
Subject: RE: [core] YANG to CBOR mapping version 1

Hi Michel,

That looks pretty complex to me; while the keys can be elegantly expressed in the CBOR contents.

Peter

Michel Veillette schreef op 2016-07-13 16:36:
> Hi Peter
> 
> The scenario you described is part of the generic discovery problem.
> To perform its tasks, clients typically need to known the list of 
> modules, features, deviations implemented by a server and associated 
> versions.
> This problem is addressed in
> http://core-wg.github.io/yang-cbor/draft-veillette-core-cool-library-l
> atest.html
> which is the constrained version of
> https://datatracker.ietf.org/doc/rfc7895/
> 
> module: ietf-cool-library
>    +--ro modules-state
>       +--ro module-set-id    union
>       +--ro module* [sid revision]
>          +--ro sid                 sid
>          +--ro revision            revision
>          +--ro feature*            sid
>          +--ro deviation* [sid revision]
>          |  +--ro sid         sid
>          |  +--ro revision    revision
>          +--ro conformance-type    enumeration
>          +--ro submodules
>             +--ro submodule* [sid revision]
>                +--ro sid         sid
>                +--ro revision    revision
> notifications:
>    +---n yang-library-change
>       +--ro module-set-id    -> /modules-state/module-set-id
> 
> Regards
> Michel
> 
> -----Original Message-----
> From: peter van der Stok [mailto:stokcons@xs4all.nl]
> Sent: Wednesday, July 13, 2016 2:34 AM
> To: Michel Veillette <Michel.Veillette@trilliantinc.com>
> Cc: consultancy@vanderstok.org; Core <core@ietf.org>
> Subject: RE: [core] YANG to CBOR mapping version 1
> 
> Hi Michel,
> 
> When a specification changes it set of of keys, I don't think the SIDs 
> will change.
> It is for sure that the hashes are not affected by the attribution of 
> a key.
> 
> Therefore, what happens when client and server use different keys in 
> otherwise identical list specification?
> 
> Peter
> 
> Michel Veillette schreef op 2016-07-12 17:07:
>> Hi Peter
>> 
>> The validations performed by the entity which de-serialize the CBOR 
>> payload is based on the YANG schema.
>> This validation is based on all king of YANG statements such as:
>> key, unique, range, pattern, length, min-elements, max-elements, 
>> must, when, if-feature
>> 
>> The identification of which data nodes are keys is considered 
>> unnecessary meta-data since available in the schema.
>> Even more heavy weight representations such as xml and json don't 
>> include this meta-data in the encode payload.
>> 
>> Regards,
>> Michel
>> 
>> -----Original Message-----
>> From: peter van der Stok [mailto:stokcons@xs4all.nl]
>> Sent: Tuesday, July 12, 2016 6:08 AM
>> To: Michel Veillette <Michel.Veillette@trilliantinc.com>
>> Cc: consultancy@vanderstok.org; Core <core@ietf.org>
>> Subject: RE: [core] YANG to CBOR mapping version 1
>> 
>> Hi Michel,
>> 
>>> 
>>> However, I am missing how to transport a given list instance with 
>>> its key values in the CBOR encoding. Section 4.4 describes the 
>>> encoding of a complete list not a subset of its instances.
>>> 
>>> [MV] A list instance is a collection which is described in section 
>>> 4.2.
>>> ____________________________________________________________________
>>> _
>>> _
>>> _______________________
>> 
>> With the current text I don't see how you distinguish instances with 
>> the same key from instances with different keys.
>> 
>> Example:
>> 
>> list server {
>>       key name;
>> 
>>       leaf name {
>>         type string;
>>       }
>>       leaf iburst {
>>         type boolean;
>>         default false;
>>     }
>> 
>> How to distinguish that in the list below that two instances are 
>> identical (should not occur)
>>     [
>>       {
>>         1755 : "NRC TIC server",          # name (SID 1755)
>>         1754 : false,                     # iburst (SID 1754)
>>       },
>>       {
>>         1755 : "NRC TIC server",          # name (SID 1755)
>>         1754 : true,                     # iburst (SID 1754)
>>       }
>>     ]
>> 
>> And the following two instances are different  (valid array)
>> 
>>     [
>>       {
>>         1755 : "NRC TAC server",          # name (SID 1755)
>>         1754 : true,                      # iburst (SID 1754)
>>       },
>>       {
>>         1755 : "NRC TIC server",          # name (SID 1755)
>>         1754 : true,                     # iburst (SID 1754)
>>       }
>>     ]