Re: [netmod] type equivalence

[Andy Bierman <[e-mail]>]

On Fri, Feb 26, 2021 at 7:06 AM Martin Björklund <[e-mail]> wrote:

> "Rob Wilton \(rwilton\)" <rwilton=[e-mail]> wrote:
> >
> >
> > > -----Original Message-----
> > > From: netmod <[e-mail]> On Behalf Of Juergen
> Schoenwaelder
> > > Sent: 24 February 2021 20:39
> > > To: [e-mail]
> > > 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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> > > Fax:   [phone]         <https://www.jacobs-university.de/>
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/netmod
> >
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>