On Fri, Feb 26, 2021 at 7:06 AM Martin Björklund <[email protected]> wrote:
> "Rob Wilton \(rwilton\)" <[email protected]> wrote: > > > > > > > -----Original Message----- > > > From: netmod <[email protected]> On Behalf Of Juergen > Schoenwaelder > > > Sent: 24 February 2021 20:39 > > > To: [email protected] > > > 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. 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. 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 > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > > netmod mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
