Re: [netmod] type equivalence
Martin Björklund <mbj+ietf@4668.se> Mon, 22 February 2021 10:13 UTC
Return-Path: <mbj+ietf@4668.se>
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 E8F533A1245 for <netmod@ietfa.amsl.com>; Mon, 22 Feb 2021 02:13:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.099
X-Spam-Level:
X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_NAKED_TO_NUMERO=1.999, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=VJGzAeje; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=A/hvGYDm
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 HBjqL50XLRgI for <netmod@ietfa.amsl.com>; Mon, 22 Feb 2021 02:13:47 -0800 (PST)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F56D3A1243 for <netmod@ietf.org>; Mon, 22 Feb 2021 02:13:47 -0800 (PST)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 9B3895C0102; Mon, 22 Feb 2021 05:13:46 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Mon, 22 Feb 2021 05:13:46 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm1; bh= a4oaFzWCoS72hyKoGSrfdy52/RdN+ZjPrG4WtwGdiGA=; b=VJGzAejeUcVsqHbW I1K3/VrDnRtcSlLQ0wx1tUDYJI1vN2j3GbEIuces/yOSYaBD4IikOmkq1sKlcKOs g7Yw9cuSI97kavyjZujZV4GFA+n4DbH8xXIrEC0s1/yB96ptKOP9sOV8SvdVkz3a cpwWhrHJk0AWFCw/Mxu39dz6AR6FHVp+1XBd7IdkK7ZEp0YzkQlu/vyz8gdryrTJ 3eAMtcp9XQ3PrX1q9dEtOAHirMvR19NKxMtScAQRO2DtwjPZfDKdjqAByPfPi3uB P5PQkIwruOZXOBuE/Ll8R4Q7KY7M7FR7m4DBsMgSbX4iut7qPQPUZ2cdShy/IWV7 JKwFLQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=a4oaFzWCoS72hyKoGSrfdy52/RdN+ZjPrG4WtwGdi GA=; b=A/hvGYDmkgPt8oZfwA6icbDPtkkMVJ0vojMoX7NlQq68yhLSOkQP2pi6Y 6RihQLo0Iw35VH1gE0vtnzADVsdC3zr1u9a8ilObOqgffDVbzCHFEgyIESgXfbD2 S9EdljZ4eleDiiK4qfR2X0oYxTjDzXdpxq8XGhimO53bDC2HRaixY6G5a4LEBzK1 oz+v3/fN+Mtvq2kzd/wffCcNLv6MUO7Z8G2OkslLhY3gtD4zlWe2ZNXuWE2xjCLj 1jUV+3uOK7GYloqTMo9goCImdOo6/hPKQT8ODjtfVI4z5une477RO42bPnRNCONj aDT5ei7n0Oza7f04SFo3JTLcGU/+Q==
X-ME-Sender: <xms:2YMzYE9qp3YTTsmUKiPF6ZpSGLcbvluGoz4eAs42C5pI3GNkUt2waQ> <xme:2YMzYMtZlbmyLsnl1hbo-APiGEwufnsg1EIZjaYmsfTV_uR7i_sm-1TbYAEGjnWbi O9VbU8_3eFy19LemLw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrkeefgddufecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffkvffuhfgjfhfogggtgfesthhqre dtredtudenucfhrhhomhepofgrrhhtihhnuceujhpnrhhklhhunhguuceomhgsjhdoihgv thhfseegieeikedrshgvqeenucggtffrrghtthgvrhhnpeduieevjeduffdvvedugedvud ehiedvleefhfeuheffjeeuvdegiedvffejleevheenucffohhmrghinhepjhgrtghosghs qdhunhhivhgvrhhsihhthidruggvpdhivghtfhdrohhrghenucfkphepudehkedrudejge drgedrvdduheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhr ohhmpehmsghjodhivghtfhesgeeiieekrdhsvg
X-ME-Proxy: <xmx:2YMzYKD1x_ty6V1PW6JM0GH1GwRoP0JJcWVWgdpwM1c152XZbR9z8Q> <xmx:2YMzYEfBNE83SMh1004QjY9BhxnfWPv-PNQKJI_TJ1mq7nXu40fstA> <xmx:2YMzYJPZ0xozBQVuJv7CDxwybBD244o3SudjyHIEaymYioicv1wxRg> <xmx:2oMzYLUmwq7otHa66o1IQ7C4-wFov6BGRT0txRYQNNiKnTESdTC6Ig>
Received: from localhost (unknown [158.174.4.215]) by mail.messagingengine.com (Postfix) with ESMTPA id C546E240062; Mon, 22 Feb 2021 05:13:44 -0500 (EST)
Date: Mon, 22 Feb 2021 11:13:43 +0100
Message-Id: <20210222.111343.254950973345362316.id@4668.se>
To: j.schoenwaelder@jacobs-university.de
Cc: cabo@tzi.org, netmod@ietf.org
From: Martin Björklund <mbj+ietf@4668.se>
In-Reply-To: <20210222100857.ovetw7udo4ccbezx@anna.jacobs.jacobs-university.de>
References: <20210222092455.qupjm2d4lpm4ay4n@anna.jacobs.jacobs-university.de> <20210222.104938.680142326480637892.id@4668.se> <20210222100857.ovetw7udo4ccbezx@anna.jacobs.jacobs-university.de>
X-Mailer: Mew version 6.8 on Emacs 26.3
Mime-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/pN-Jgau-St7Z3P0fHiy551Lc8_g>
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: Mon, 22 Feb 2021 10:13:52 -0000
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: > Thanks Martin, > > so you are saying that > > int8 { range "1..10"; } > > is indeed different from > > uint8 { range "1..10"; } > > and > > int32 { range "1..10"; } Yes. > The use of the word "syntax" in the text you quote may be a left-over > from SMIv2 times [That's what I thought as well, but I couldn't find it in the SMIv2 RFCs. Perhaps it was from some sming text?] > , it does not really seem to be aligned with how the > term 'syntax' is used elsewhere in RFC 7950. Anyway, if the agreement > back then was that you can't change base types (regardless of type > restrictions), it would have been nice if the text would say this more > clearly. Agreed. /martin > > /js > > On Mon, Feb 22, 2021 at 10:49:38AM +0100, Martin Björklund wrote: > > Hi, > > > > Section 11 of RFC 7950 says: > > > > o A "type" statement may be replaced with another "type" statement > > that does not change the syntax or semantics of the type. For > > example, an inline type definition may be replaced with a typedef, > > but an int8 type cannot be replaced by an int16, since the syntax > > would change. > > > > If we're just considering XML, then the syntax or encoding wouldn't > > change if we went from > > > > type int64 { range "2..4"; } > > > > to > > > > type string { pattern "2|3|4"; } > > > > or > > > > type enumeration { > > enum 2; > > enum 3; > > enum 4; > > } > > > > or > > > > type union { > > type uint8 { range "2"; } > > type string { pattern "3"; } > > type enumeration { enum 4; } > > } > > > > > > But I don't think this is reasonable, and not the intention. I think > > that changing the base built-in type always should be considered > > non-backwards compatible (which the quoted text above seems to imply). > > > > > > /martin > > > > > > > > > > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: > > > On Fri, Feb 19, 2021 at 10:32:34PM +0100, Carsten Bormann wrote: > > > > > > > > > > > > > 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.) > > > > > > OK. The CBOR document indeed says: > > > > > > 6.1. The unsigned integer Types > > > > > > Leafs of type uint8, uint16, uint32 and uint64 MUST be encoded using > > > a CBOR unsigned integer data item (major type 0). > > > > > > 6.2. The integer Types > > > > > > Leafs of type int8, int16, int32 and int64 MUST be encoded using > > > either CBOR unsigned integer (major type 0) or CBOR negative integer > > > (major type 1), depending on the actual value. > > > > > > This means the type 'int8 { range 0..10; }' leads to the same > > > encodings as the type 'uint8 { range 0..10; }'. > > > > > > > > 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. > > > > > > > > > > Exactly. I think we never defined this. And of course, this can get > > > even more fun if you consider string based encodings. The type > > > > > > type string { pattern "1|2|3|4"; } > > > > > > yields the same _XML encoded_ value space as > > > > > > type int32 { range "1..4"; } > > > > > > but as far as I recall the JSON/CBOR encodings will treat these two > > > differently. So yes, ideally the YANG language would have clear rules > > > what YANG's type equivalences are. > > > > > > /js > > > > > > -- > > > 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/> > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > -- > 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/>
- [netmod] type equivalence Juergen Schoenwaelder
- Re: [netmod] type equivalence Carsten Bormann
- Re: [netmod] type equivalence Juergen Schoenwaelder
- Re: [netmod] type equivalence Carsten Bormann
- Re: [netmod] type equivalence Juergen Schoenwaelder
- Re: [netmod] type equivalence Martin Björklund
- Re: [netmod] type equivalence Ladislav Lhotka
- Re: [netmod] type equivalence Juergen Schoenwaelder
- Re: [netmod] type equivalence Juergen Schoenwaelder
- Re: [netmod] type equivalence Martin Björklund
- Re: [netmod] type equivalence Ladislav Lhotka
- Re: [netmod] type equivalence Carsten Bormann
- Re: [netmod] type equivalence Carsten Bormann
- Re: [netmod] type equivalence Juergen Schoenwaelder
- Re: [netmod] type equivalence Carsten Bormann
- Re: [netmod] type equivalence Juergen Schoenwaelder
- Re: [netmod] type equivalence Carsten Bormann
- Re: [netmod] type equivalence tom petch
- Re: [netmod] type equivalence Juergen Schoenwaelder
- Re: [netmod] type equivalence Rob Wilton (rwilton)
- Re: [netmod] type equivalence Juergen Schoenwaelder
- Re: [netmod] type equivalence Andy Bierman
- Re: [netmod] type equivalence Rob Wilton (rwilton)
- Re: [netmod] type equivalence Juergen Schoenwaelder
- Re: [netmod] type equivalence Rob Wilton (rwilton)
- Re: [netmod] type equivalence Juergen Schoenwaelder
- Re: [netmod] type equivalence Rob Wilton (rwilton)
- Re: [netmod] type equivalence Juergen Schoenwaelder
- Re: [netmod] type equivalence Andy Bierman
- Re: [netmod] type equivalence Martin Björklund
- Re: [netmod] type equivalence Rob Wilton (rwilton)
- Re: [netmod] type equivalence Andy Bierman
- Re: [netmod] type equivalence Martin Björklund
- Re: [netmod] type equivalence Rob Wilton (rwilton)
- Re: [netmod] type equivalence Martin Björklund
- Re: [netmod] type equivalence Andy Bierman
- Re: [netmod] type equivalence Rob Wilton (rwilton)
- Re: [netmod] type equivalence Rob Wilton (rwilton)
- Re: [netmod] [SUSPECTED SPAM] Re: type equivalence Rob Wilton (rwilton)
- Re: [netmod] type equivalence Juergen Schoenwaelder
- Re: [netmod] type equivalence Rob Wilton (rwilton)
- Re: [netmod] type equivalence Rob Wilton (rwilton)
- Re: [netmod] type equivalence Martin Björklund
- Re: [netmod] type equivalence Rob Wilton (rwilton)
- Re: [netmod] type equivalence Juergen Schoenwaelder
- Re: [netmod] type equivalence Juergen Schoenwaelder
- Re: [netmod] type equivalence Carsten Bormann