> -----Original Message-----
> From: Martin Björklund <mbj+i...@4668.se>
> Sent: 26 February 2021 16:37
> To: Rob Wilton (rwilton) <rwil...@cisco.com>
> Cc: a...@yumaworks.com; netmod@ietf.org
> Subject: Re: [netmod] type equivalence
>
> "Rob Wilton (rwilton)" <rwil...@cisco.com> wrote:
> >
> >
> > > -----Original Message-----
> > > From: Martin Björklund <mbj+i...@4668.se>
> > > Sent: 26 February 2021 16:30
> > > To: a...@yumaworks.com
> > > Cc: Rob Wilton (rwilton) <rwil...@cisco.com>; netmod@ietf.org
> > > Subject: Re: [netmod] type equivalence
> > >
> > > Andy Bierman <a...@yumaworks.com> wrote:
> > > > On Fri, Feb 26, 2021 at 7:06 AM Martin Björklund <mbj+i...@4668.se>
> > > wrote:
> > > >
> > > > > "Rob Wilton \(rwilton\)" <rwilton=40cisco....@dmarc.ietf.org>
> wrote:
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: netmod <netmod-boun...@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.
> > [RW]
> >
> > But the proposed errata removes the text about not changing the
> > syntax, or are you referring to other text?
>
> The new text says that the built-in type cannot change, which it does
> if we add a type to a union. Hmm, perhaps this isn't clear.
[RW]
Not sure. I think that it is reasonable clear, as long as you don't talk about
changes in the syntax ;-)
But, it might be worth explicitly pulling out that union type is a change,
otherwise someone might try and fudge this by changing uint32 to a union of
uint32 and uint64.
Rob
>
>
> /martin
>
>
> >
> > Rob
> >
> >
> > >
> > >
> > > /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 mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
