Re: [netmod] [core] CBOR YANG encoding of union & bits [draft-ietf-core-yang-cbor-12]

Jim Schaad <ietf@augustcellars.com> Fri, 08 May 2020 17:48 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51AC73A0E6D; Fri, 8 May 2020 10:48:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 X9YtZCz2C4_H; Fri, 8 May 2020 10:48:45 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14F973A0F81; Fri, 8 May 2020 10:48:14 -0700 (PDT)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 8 May 2020 10:48:08 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'Andy Bierman' <andy@yumaworks.com>, 'Carsten Bormann' <cabo@tzi.org>
CC: core@ietf.org, netmod@ietf.org
References: <BY5PR11MB4355C26250C9CF46713C9956B5A40@BY5PR11MB4355.namprd11.prod.outlook.com> <D66596CE-7F5C-4562-89A4-48FCE96D0E18@tzi.org> <28486.1588785684@localhost> <CABCOCHRRDYDomEPctAHaHf+MxS2qXab1J4o=_LUEWcJ2=by5Ww@mail.gmail.com> <8F06BFE6-CE7C-4D10-AC61-24AAA2807E45@tzi.org> <CABCOCHRUCK_FpwSCnOOy8fBCX_HeAWQeFvJEyZy2hUL4L2WhrQ@mail.gmail.com> <CABCOCHQOWoPozsYOfVEDy_TYw-YF5H9TZ2eydcOpj-g2d3ysNQ@mail.gmail.com>
In-Reply-To: <CABCOCHQOWoPozsYOfVEDy_TYw-YF5H9TZ2eydcOpj-g2d3ysNQ@mail.gmail.com>
Date: Fri, 08 May 2020 10:48:06 -0700
Message-ID: <000701d62560$d681d790$838586b0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01D62526.2A23E9F0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGvOgo1j9qnmiUTiQ47GeqPTSRnBgJo+5o3AkgWSoMCnG1H8QJr3z1uAQLtspwCHJEHgaiFhoQQ
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/FPs3oIc_pTyOKxsRXV4BIq5E_H0>
Subject: Re: [netmod] [core] CBOR YANG encoding of union & bits [draft-ietf-core-yang-cbor-12]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 May 2020 17:48:50 -0000

Does yang consider that there is a difference between a bit being present and zero and a bit being absent?

 

From: core <core-bounces@ietf.org> On Behalf Of Andy Bierman
Sent: Friday, May 8, 2020 8:58 AM
To: Carsten Bormann <cabo@tzi.org>
Cc: core@ietf.org; netmod@ietf.org
Subject: Re: [core] [netmod] CBOR YANG encoding of union & bits [draft-ietf-core-yang-cbor-12]

 

 

 

On Fri, May 8, 2020 at 8:51 AM Andy Bierman <andy@yumaworks.com <mailto:andy@yumaworks.com> > wrote:

 

 

On Thu, May 7, 2020 at 11:22 PM Carsten Bormann <cabo@tzi.org <mailto:cabo@tzi.org> > wrote:

On 2020-05-08, at 05:27, Andy Bierman <andy@yumaworks.com <mailto:andy@yumaworks.com> > wrote:
> 
> Why is the bit position allowed to be a uint32 in YANG? Who knows, but it has to be supported.

If we think that is the way to go, I like Kio’s proposal over in the CBOR list:
<https://mailarchive.ietf.org/arch/msg/cbor/3sZ4YfWLzmVVnNnQbttkovgjTP8>

 

 

Yes -- this encoding should work well

 

We probably should arm that with some text that says (in nicer words) that this is an emergency representation and implementations should not invoke it for sane YANG models (with an operable definition of sane).

 

 

Not sure what this means.

Wouldn't this map approach be used all the time for a bits type?

The "normal" case would be a small number of octets representing all the bits present

 (e..g 0x7 for 3 bits : bit 0 to bit 2)

This would simply be 1 map entry with {offset=0,length=1,value=0x7}

 

The actual bitmap is conceptually constructed by starting with an array of zero bytes.

Overlapping offsets are allowed. Duplicate offsets are allowed.

There is no requirement to list offsets in ascending order.

There is no canonical representation.

 

Each map entry is added to the array using a "bit or" operator.

After all map entries are processed the full bits value is known.

This allows an implementation to encode bits serially (often done this way with YANG bit names)

 

So the same bitset 0x7 could be sent different ways including:

 

  { 0, 1, 0x1 }

  { 0, 1, 0x2 }

  { 0, 1, 0x4 }

 

If the position is really bit 4 million (bit 1 in byte 500,000)

 

  { 0, 500000, 0x1 }

 

 

oops: correction:  (bit 0 in byte 500000)

 

  { 500000, 1, 0x1 }

 

     

Grüße, Carsten

 

 

Andy