IETF Logo Mail Archive

Re: [core] yang cbor encoding without SID

Alexander Pelov <a@ackl.io> Fri, 21 July 2017 10:48 UTC

Return-Path: <a@ackl.io>
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 4622C12EB5D for <core@ietfa.amsl.com>; Fri, 21 Jul 2017 03:48:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=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 9Vk5ectMxrQN for <core@ietfa.amsl.com>; Fri, 21 Jul 2017 03:48:32 -0700 (PDT)
Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [IPv6:2001:4b98:c:538::194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E8C2127337 for <core@ietf.org>; Fri, 21 Jul 2017 03:48:32 -0700 (PDT)
Received: from [IPv6:2001:67c:370:128:517a:b55:84e2:6264] (unknown [IPv6:2001:67c:370:128:517a:b55:84e2:6264]) (Authenticated sender: alex@ackl.io) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id EC621C5A76; Fri, 21 Jul 2017 12:48:29 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Alexander Pelov <a@ackl.io>
In-Reply-To: <BN6PR06MB2308E4502A312B268599C60FFEA40@BN6PR06MB2308.namprd06.prod.outlook.com>
Date: Fri, 21 Jul 2017 12:48:28 +0200
Cc: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Core <core@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C85F698D-50F9-4C20-ABA5-05251B8E3A6E@ackl.io>
References: <20170720084234.GB20950@elstar.local> <9835E0B2-4B7F-4266-AD05-292B388B41AB@tzi.org> <20170720085743.GC20950@elstar.local> <26C20912-6896-4240-B7E9-79F5579F1686@tzi.org> <20170720094047.GF20950@elstar.local> <CABCOCHSgF7PuTpfuZ5n-pUW7kipLWGggoEoCHrXOPrrkUchPxg@mail.gmail.com> <E0C3BBA9-EE10-4AAF-9937-478F189E38D4@tzi.org> <MWHPR06MB2317B38A39779C05D9E75485FEA40@MWHPR06MB2317.namprd06.prod.outlook.com> <20170721095524.GD22027@elstar.local> <BAE0ED45-F319-471F-B91F-A60EFC943AB4@ackl.io> <20170721102919.GA22212@elstar.local> <BN6PR06MB2308E4502A312B268599C60FFEA40@BN6PR06MB2308.namprd06.prod.outlook.com>
To: Michel Veillette <Michel.Veillette@trilliantinc.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/imSscmjpC4j3yMVhRUW58FvSNok>
Subject: Re: [core] yang cbor encoding without SID
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
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, 21 Jul 2017 10:48:34 -0000

Oh, thanks for the reminder, Michel !

I remember having long discussions on removing the member names from the spec.. and then we had the decision to keep them and leave to the implementers. 

So, it’s solved then?

Alexander


> Le 21 juil. 2017 à 12:38, Michel Veillette <Michel.Veillette@trilliantinc.com> a écrit :
> 
> Hi Juergen, Hi Alexander
> 
> I just want to mention that the following text relative to this topic
> is already present In the YANG to CBOR draft.
> 
> https://tools.ietf.org/html/draft-ietf-core-yang-cbor-04#section-3
> 
>   This specification supports two type of CBOR keys; YANG
>   Schema Item iDentifier (SID) as defined in Section 2.1 and member
>   names as defined in [RFC7951].  Each of these key types is encoded
>   using a specific CBOR type which allows their interpretation during
>   the deserialization process.  The end user of this mapping
>   specification (e.g.  RESTCONF [RFC8040], CoMI [I-D.ietf-core-comi])
>   can mandate the use of a specific key type.
> 
> Regards,
> Michel
> 
> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] 
> Sent: Friday, July 21, 2017 12:29 PM
> To: Alexander Pelov <a@ackl.io>
> Cc: Michel Veillette <Michel.Veillette@trilliantinc.com>; Core <core@ietf.org>
> Subject: Re: [core] yang cbor encoding without SID
> 
> On Fri, Jul 21, 2017 at 12:15:52PM +0200, Alexander Pelov wrote:
>> 
>> If you are having a NETCONF/RESTCONF server anyway, and just want an efficient CBOR representation, then you could do it more simply than following the YANG-CBOR draft. Get your JSON, convert to CBOR, then on the receiver side convert back to JSON and process it. 
>> 
> 
> So does the YANG-CBOR draft exist only so that we have SID? Or are there any other differences between [1] YANG->JSON->CBOR (RFC 7951 + RFC 7049 section 4) and [2] YANG->CBOR (draft-ietf-core-yang-cbor-04)?
> 
> I understand that I can implement [1] without having to generate JSON first. Perhaps a discussion of this would be a nice addition to draft-ietf-core-yang-cbor-04.
> 
> /js
> 
> -- 
> 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/>

v2.23.0 | Report a Bug | By Email