Re: [netmod] type equivalence
Martin Björklund <mbj+ietf@4668.se> Fri, 26 February 2021 16:30 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 A8EFF3A0FCA for <netmod@ietfa.amsl.com>; Fri, 26 Feb 2021 08:30:17 -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_H4=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=Ko5wUfLI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qXiwsfHH
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 80eM9pYRcNis for <netmod@ietfa.amsl.com>; Fri, 26 Feb 2021 08:30:15 -0800 (PST)
Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF8293A0FC4 for <netmod@ietf.org>; Fri, 26 Feb 2021 08:30:15 -0800 (PST)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id BE565C66; Fri, 26 Feb 2021 11:30:14 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Fri, 26 Feb 2021 11:30:14 -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= vbrA7cmv1lKQF92btfdN2jrH0kuK2uuEZzp3QhexFwM=; b=Ko5wUfLIeScIJDso l/6TDbJI0RMD27CA2llUoBqfyHxqPO7TnwpAfXIpb8Xh/BzoErrkb1MHmEFFTE0P r4GhFENOc6NK9qhWML0TINIZiJqY5JvnO4QpnnFMkFqsiKD+n26oszDe0ICS7v1x oNpBuTPB7YjkYfrW3hV96YLfxPT0qVeDtRd4B3ki2wglxHioLB03asn9ULT1Fnk/ 9U8XVxzfb7Ka7AMgIGy6cWPBzDmNeUwPPj5neL6f4XtIz/wDnQ+c1b93y3ega1LO P7Q0w9oRXelrolEb49w4GO5OzRNDOIpofa3HPXMkvJK6ar8/lnkti+oEu81Ztg5U 2JRcYg==
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=vbrA7cmv1lKQF92btfdN2jrH0kuK2uuEZzp3QhexF wM=; b=qXiwsfHHri1jhX5pwCxbKEu3Oz07pmR+VTSi9h7/F5L+WMDGEcq5AlSRv gTQ4h1G/miqKe2k1um5PM4a640vSQ95F4dwqBFPTQ3hPo6fvUE6Uc613Atc7KM9B vlUwMNva2TwlpmSoxXpblpdMwQ9nwitYowkOyH0r5656zioBn2q2sIhNGIBmZwR4 Io87G65yd/OD0ABzxHm/wCzo22tTFRgtQq8OmD/P2ZirZeDLa8l02PLEKGEhRDCI sAXOcyqFBIcIe1ZuhH5b3/43K80tz/OuGKcjTp3WowEq/ASZoVLH+FyUfkBrH8KI o84UFUFckb/endi7/aeASaeoHMT/g==
X-ME-Sender: <xms:FCI5YFOekszrXQXVzV6BfBLX8j7hNIK7lfP8a3ZXQYJU4Vg11pFyJg> <xme:FCI5YH8XJgt_-1jRJDukWZBpewPax5568mlnpU6jgfgihXFLGkewv4gO8KMnHfKqQ bseFsbmUETTpcLHCMI>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrledugdeltdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffkvffuhfgjfhfogggtgfesthhqre dtredtudenucfhrhhomhepofgrrhhtihhnuceujhpnrhhklhhunhguuceomhgsjhdoihgv thhfseegieeikedrshgvqeenucggtffrrghtthgvrhhnpeduieevjeduffdvvedugedvud ehiedvleefhfeuheffjeeuvdegiedvffejleevheenucffohhmrghinhepjhgrtghosghs qdhunhhivhgvrhhsihhthidruggvpdhivghtfhdrohhrghenucfkphepudehkedrudejge drgedrvdduheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhr ohhmpehmsghjodhivghtfhesgeeiieekrdhsvg
X-ME-Proxy: <xmx:FCI5YERzyLrxHHO5LDr4Br6v_QhABJB3DYy2J3h_8DofJgOgHbnC4A> <xmx:FCI5YBuYex6wwsro0n7ebIjkIddGkaPaHBSCswQFdnOSFojZn9s0rA> <xmx:FCI5YNfJb-SMedx7nD7P-jNDNyE0J9AsfMQf6cDUSAcs529hJig9GA> <xmx:FiI5YNk0j6BpUrtHmNk2_JY75hiOSxOOnfTOAaOHSW2bWCTYogWSNw>
Received: from localhost (unknown [158.174.4.215]) by mail.messagingengine.com (Postfix) with ESMTPA id 2EA4124005D; Fri, 26 Feb 2021 11:30:12 -0500 (EST)
Date: Fri, 26 Feb 2021 17:30:10 +0100
Message-Id: <20210226.173010.2304782771110060094.id@4668.se>
To: andy@yumaworks.com
Cc: rwilton=40cisco.com@dmarc.ietf.org, netmod@ietf.org
From: Martin Björklund <mbj+ietf@4668.se>
In-Reply-To: <CABCOCHSeMpgjmws0X5HStsbjvr8h=8tP3-qwAdjYfqcX3=-P5g@mail.gmail.com>
References: <MN2PR11MB4366BD4F7DE5297B38488749B59D9@MN2PR11MB4366.namprd11.prod.outlook.com> <20210226.160616.1276834419454673357.id@4668.se> <CABCOCHSeMpgjmws0X5HStsbjvr8h=8tP3-qwAdjYfqcX3=-P5g@mail.gmail.com>
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/VzeHjcSLhYmljQbnFYIvSzEf65Y>
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, 26 Feb 2021 16:30:18 -0000
Andy Bierman <andy@yumaworks.com> wrote: > On Fri, Feb 26, 2021 at 7:06 AM Martin Björklund <mbj+ietf@4668.se> wrote: > > > "Rob Wilton \(rwilton\)" <rwilton=40cisco.com@dmarc.ietf.org> wrote: > > > > > > > > > > -----Original Message----- > > > > From: netmod <netmod-bounces@ietf.org> On Behalf Of Juergen > > Schoenwaelder > > > > Sent: 24 February 2021 20:39 > > > > To: netmod@ietf.org > > > > Subject: Re: [netmod] type equivalence > > > > > > > > Here is an attempt to come up with better wording. If people agree on > > > > a new wording, I volunteer to submit an errata. > > > > > > > > OLD > > > > > > > > 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. > > > > > > > > NEW > > > > > > > > o A "type" statement may be replaced with another "type" statement > > > > that does not change the semantics of the type or the underlying > > > > built-in type. For example, an inline type definition may be > > > > replaced with a semantically equivalent typedef derived from the > > > > same built-in type, but an int8 type cannot be replaced by an > > > > int16, since the underlying built-in type would change. > > > > > I think the NEW text captures the original intent and is OK for an errata. +1 > I believe the use-case discussed at the time of writing was simply > replacing an inline > type with the identical type but within a typedef-stmt instead of inline > within a leaf or leaf-list. > > Perhaps this rule is too strict. > There is a simple way to defeat it: > > Change all > type foo { ... } > to > type union { > type foo { ... } > } > > Now you can add new values and semantics without taking away the original > syntax and semantics. > > type union { > type foo { ... } > type bar { ... } // note new member types added at end of list > } > > But it is not clear that this would be legal or completely BC. It certainly > could change the encoding in JSON and CBOR. It is not allowed by sec 11 in 7950, since it changes the syntax of the type. /martin > > > Andy > > > > [RW] > > > > > > Would the text be more clear it is just specified what is allowed, e.g., > > > > > > o A "type" statement may be replaced with another "type" statement > > > that resolves to the same underlying built-in type. For example, > > > ... > > > > > > > > > What does "semantics of the type" cover? > > > > Suppose you have: > > > > typedef "timestamp" { > > type yang:date-time; > > description > > "The time that an event occurred"; > > } > > > > then you can't change it to: > > > > typedef "timestamp" { > > type yang:date-time; > > description > > "The time that an event was received."; > > } > > > > The syntax is the same, but the semantics are different. > > > > > > /martin > > > > > > > > > > > > > > If I have this type: > > > > > > typedef "timestamp" { > > > type "string"; > > > description > > > "The time of day that an event occurred, in any format"; > > > } > > > > > > then can I replace it with this definition: > > > > > > typedef "timestamp" { > > > type "string"; > > > description > > > "The time of day, and optionally date, that an event > > > occurred, in any format"; > > > } > > > > > > > > > > > > Tangentially, it is worth noting the RFC 8342 also writes about syntactic > > > constraints covering types: > > > > > > 5.3. The Operational State Datastore (<operational>) > > > > > > Syntactic constraints MUST NOT be violated, including hierarchical > > > organization, identifiers, and type-based constraints. If a node in > > > <operational> does not meet the syntactic constraints, then it > > > MUST NOT be returned, and some other mechanism should be used to flag > > > the error. > > > > > > I'm not sure how clear RFC 8342 section 5.3 is about returning values > > > that can be represented by the underlying built-in-type, but are outside > > > the value space defined by a range, length, or pattern statement. > > > > > > My memory during the discussions was that it is allowed to return a value > > > outside arange, length, pattern statement, as long as it is contained > > > in the value space of the built-in-type. E.g., cannot return 257 in a > > > uint8, but can return 11 even if the type range is 1..10. > > > > > > But, I'm not sure that is what the text actually states. > > > > > > Regards, > > > Rob > > > > > > > > > > > > > > /js > > > > > > > > On Mon, Feb 22, 2021 at 03:20:02PM +0100, Carsten Bormann wrote: > > > > > On 2021-02-22, at 15:17, Juergen Schoenwaelder > > <j.schoenwaelder@jacobs- > > > > university.de> wrote: > > > > > > > > > > > > I guess considering the built-in types as incompatible is the most > > > > > > robust approach. If we agree that RFC 7950 tried to say this, we > > could > > > > > > file an errata and propose clearer language. > > > > > > > > > > Right. And we can keep the COMI key-to-URL mapping as is, as this > > > > clarification is necessary for its correct functioning. > > > > > > > > > > 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/> > > > > > > > > _______________________________________________ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > >
- [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