Re: [netmod] type equivalence

Carsten Bormann <cabo@tzi.org> Fri, 19 February 2021 21:32 UTC

Return-Path: <cabo@tzi.org>
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 5403D3A0964 for <netmod@ietfa.amsl.com>; Fri, 19 Feb 2021 13:32:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 aDcF9upfDBMv for <netmod@ietfa.amsl.com>; Fri, 19 Feb 2021 13:32:38 -0800 (PST)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C18C3A0977 for <netmod@ietf.org>; Fri, 19 Feb 2021 13:32:37 -0800 (PST)
Received: from [192.168.217.118] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Dj4YG5ZCVzyRY; Fri, 19 Feb 2021 22:32:34 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <20210219181858.arafmdtraq4ydir2@anna.jacobs.jacobs-university.de>
Date: Fri, 19 Feb 2021 22:32:34 +0100
Cc: netmod@ietf.org
X-Mao-Original-Outgoing-Id: 635463154.0789911-814451c107b4a51d4c68e043e5e72e80
Content-Transfer-Encoding: quoted-printable
Message-Id: <CD64BB41-E2BE-4B25-AA55-3B91D7C0D313@tzi.org>
References: <20210219165549.be7l2rbhdqfevhfl@anna.jacobs.jacobs-university.de> <4A8F7739-71AA-4CE0-B9D1-9F24C60B037D@tzi.org> <20210219181858.arafmdtraq4ydir2@anna.jacobs.jacobs-university.de>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/wDDclmERA6ogy1cUpeNbqDvbgzI>
Subject: Re: [netmod] type equivalence
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, 19 Feb 2021 21:32:42 -0000


> On 2021-02-19, at 19:18, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> 
> I think the CBOR encoding picks different tags depending on the
> signedness of the base type and this is why things are not that simple
> anymore.

(This is not the CBOR encoding, but the COMI encoding of keys in URIs.)

> For the XML and JSON encodings, all definitions lead to the
> same on-the-wire representation, hence the difference is more an
> implementation detail. I have no clue what the gnmi people do. The
> more diverse encodings we add, the more complex things get.

Well, if the equivalence expectation that I was trying to describe actually is ingrained, then whoever designs an encoding (COMI for its URI encoding included) needs to respect it.  That would be important to know.

Grüße, Carsten


> 
> /js
> 
> On Fri, Feb 19, 2021 at 06:24:02PM +0100, Carsten Bormann wrote:
>> On 2021-02-19, at 17:55, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
>>> 
>>> Hi,
>>> 
>>> can I safely replace
>>> 
>>>   leaf foo {
>>>     type int8 { range "0..100"; };
>>>   }
>>> 
>>> with
>>> 
>>>   leaf foo {
>>>     type uint8 { range "0..100"; };
>>>   }
>>> 
>>> or with
>>> 
>>>   leaf foo {
>>>     type int32 { range "0..100"; };
>>>   }
>>> 
>>> or are these a non-backwards compatible changes?
>> 
>> I don’t have an answer to that, but would like to point you to the table at the top of page 14 in draft-ietf-core-comi-11.txt [1], which would make the first replacement a non-backwards compatible change in the way we build URIs from that.
>> 
>> [1]: https://tools.ietf.org/html/draft-ietf-core-comi-11#page-14
>> 
>>> Note that the value
>>> set is always the same, however the underlying base type changes. Did
>>> we ever define type equivalence?
>> 
>> The way unions are handled in YANG gives me the impression that as long as the sets of XML representations generated by the two types are the same, they are equivalent.
>> 
>> Grüße, Carsten
>> 
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>