Re: [netmod] type equivalence

Carsten Bormann <cabo@tzi.org> Fri, 19 February 2021 17:25 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 A1E603A1555 for <netmod@ietfa.amsl.com>; Fri, 19 Feb 2021 09:25:33 -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 TXqXkFJ_wxNr for <netmod@ietfa.amsl.com>; Fri, 19 Feb 2021 09:25:30 -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 2BA693A159E for <netmod@ietf.org>; Fri, 19 Feb 2021 09:24:05 -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 4Dhz2W1BvszyTm; Fri, 19 Feb 2021 18:24:03 +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: <20210219165549.be7l2rbhdqfevhfl@anna.jacobs.jacobs-university.de>
Date: Fri, 19 Feb 2021 18:24:02 +0100
Cc: netmod@ietf.org
X-Mao-Original-Outgoing-Id: 635448242.378456-a54bddd17ed7271997b401600ea9349d
Content-Transfer-Encoding: quoted-printable
Message-Id: <4A8F7739-71AA-4CE0-B9D1-9F24C60B037D@tzi.org>
References: <20210219165549.be7l2rbhdqfevhfl@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/3W8hIMAscIq4Youmd1U9oV1BTfI>
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 17:25:40 -0000

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