Re: [Cbor] CBOR-YANG representation of common types

Carsten Bormann <cabo@tzi.org> Tue, 14 November 2023 18:03 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC196C1524BC for <cbor@ietfa.amsl.com>; Tue, 14 Nov 2023 10:03:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EedDtyk434FD for <cbor@ietfa.amsl.com>; Tue, 14 Nov 2023 10:02:58 -0800 (PST)
Received: from smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [134.102.50.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69BBCC1522DB for <cbor@ietf.org>; Tue, 14 Nov 2023 10:02:57 -0800 (PST)
Received: from [192.168.217.145] (p548dcbf2.dip0.t-ipconnect.de [84.141.203.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4SVDfk4pXqzDCdP; Tue, 14 Nov 2023 19:02:54 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <77159997-0cc1-4b5d-9a1d-cc61f3d0be73@nic.cz>
Date: Tue, 14 Nov 2023 19:02:54 +0100
Cc: cbor@ietf.org, Kateřina Kubecová <katerina.kubecova@nic.cz>, vojtech.vilimek@nic.cz, Laurent Toutain <laurent.toutain@imt-atlantique.fr>
X-Mao-Original-Outgoing-Id: 721677774.199805-fbebb6096b6ee759fec20b339ea99be9
Content-Transfer-Encoding: quoted-printable
Message-Id: <D2E0DEDC-F078-4430-B54B-29BAFBAEDAD1@tzi.org>
References: <77159997-0cc1-4b5d-9a1d-cc61f3d0be73@nic.cz>
To: Maria Matejka <maria.matejka=40nic.cz@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/NPKZpnYCgaBsn46f1OVn7UnB0rg>
Subject: Re: [Cbor] CBOR-YANG representation of common types
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Nov 2023 18:03:01 -0000

Hi Maria,

On 2023-11-14, at 17:54, Maria Matejka <maria.matejka=40nic.cz@dmarc.ietf.org> wrote:
> 
> Dear CBOR WG,
> 
> we're currently trying to embrace the CBOR described by YANG in BIRD interface and we're struggling with the representation of certain types like date, time, IP address or prefix. We would assume that if there is RFC 9164 or RFC 8943, we shall then encode dates or IP addresses in these defined formats in CBOR and they shall get converted between CBOR and JSON/XML appropriately. But I can't find any RFC on this, nor any implementation of CBOR-JSON convertor.

These types are all defined as text string types in RFC 6991 etc. (and RFC 6991bis does not change anything about this).
RFC 9254 defines a basic representation of YANG in CBOR, not trying to change this.

> Thus, these questions arise:
> 
> 	• Is there any discussion on this topic, regarding interoperability between CBOR and JSON/XML?

This is a timely question.
There definitely is discussion, as the representation of these types as a CBOR text string is inefficient (with respect to both space and CPU time).

> 	• Is there any RFC on draft on this? If not, we're probably gonna create one. We need it

Writing up a proposal is on my to do list.
Right now I’m looking at:

     typedef object-identifier {
       type string {
     typedef object-identifier-128 {
       type object-identifier {
         pattern '\d*(\.\d*){1,127}';
     typedef date-and-time {
       type string {
     typedef phys-address {
       type string {
     typedef mac-address {
       type string {
     typedef hex-string {
       type string {
     typedef uuid {
       type string {
     typedef dotted-quad {
       type string {
     typedef ip-address {
       type union {
         type inet:ipv4-address;
         type inet:ipv6-address;
     typedef ipv4-address {
       type string {
     typedef ipv6-address {
       type string {
     typedef ip-address-no-zone {
       type union {
         type inet:ipv4-address-no-zone;
         type inet:ipv6-address-no-zone;
     typedef ipv4-address-no-zone {
       type inet:ipv4-address {
     typedef ipv6-address-no-zone {
       type inet:ipv6-address {
     typedef ip-prefix {
       type union {
         type inet:ipv4-prefix;
         type inet:ipv6-prefix;
       }
     typedef ipv4-prefix {
       type string {
     typedef ipv6-prefix {
       type string {

This can use tags from RFC 8949, RFC 9164, RFC 9090; we probably need to discuss little details such as whether tag 23 can be used for hex-string.

> 	• Is there any implementation of YANG-ed converter between CBOR and JSON? If not, we're probably gonna create one. We need it.

Laurent Toutain has a tool that extracts from a YANG module the parameter information needed for such a YANG-CBOR ⬌ YANG-JSON converter today.
This tool uses base types, so it cannot quite address the above list.
But the idea should be transferable.

Grüße, Carsten