Re: [netmod] [SUSPECTED SPAM] Re: type equivalence

["Rob Wilton (rwilton)" <[e-mail]>]

For a config false leaf, I suspect that would likely break clients, e.g., if their data structures were generated from the YANG.  They would start received values that they are unable to handle.

Regards,
Rob


From: Andy Bierman <[e-mail]>
Sent: 26 February 2021 16:45
To: Martin Björklund <[e-mail]>
Cc: Rob Wilton (rwilton) <[e-mail]>; NetMod WG <[e-mail]>
Subject: [SUSPECTED SPAM] Re: [netmod] type equivalence



On Fri, Feb 26, 2021 at 8:36 AM Martin Björklund <[e-mail]<mailto:[e-mail]>> wrote:
"Rob Wilton (rwilton)" <[e-mail]<mailto:[e-mail]>> wrote:
>
>
> > -----Original Message-----
> > From: Martin Björklund <[e-mail]<mailto:[e-mail]>>
> > Sent: 26 February 2021 16:30
> > To: [e-mail]<mailto:[e-mail]>
> > Cc: Rob Wilton (rwilton) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
> > Subject: Re: [netmod] type equivalence
> >
> > Andy Bierman <[e-mail]<mailto:[e-mail]>> wrote:
> > > On Fri, Feb 26, 2021 at 7:06 AM Martin Björklund <[e-mail]<mailto:[e-mail]>>
> > wrote:
> > >
> > > > "Rob Wilton \(rwilton\)" <rwilton=[e-mail]<mailto:[e-mail]>> wrote:
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: netmod <[e-mail]<mailto:[e-mail]>> On Behalf Of Juergen
> > > > Schoenwaelder
> > > > > > Sent: 24 February 2021 20:39
> > > > > > To: [e-mail]<mailto:[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.
> >
> > +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.


We do not want to see all types defined with union type wrappers from the start,
just in case.


I do not know if this change is legal in YANG 1.1 but it should be considered

  existing:
     type foo {}

  update:
     type union {
        type foo {}
        type bar {}
     }


This specifically implies that all values that used to be accepted are still accepted with
the exact same syntax and semantics as before.  An old client will not know about the type bar syntax
or semantics, which means it could read values of type bar set by the server or new clients.
Not great, but not a disaster either.




/martin


Andy


>
> 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-
<mailto:j.schoenwaelder@jacobs-%0b>> > > > > > university.de<http://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/<http://university.de/>>
> > > > > >
> > > > > > _______________________________________________
> > > > > > netmod mailing list
> > > > > > [e-mail]<mailto:[e-mail]>
> > > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > >
> > > > > _______________________________________________
> > > > > netmod mailing list
> > > > > [e-mail]<mailto:[e-mail]>
> > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > >
> > > > _______________________________________________
> > > > netmod mailing list
> > > > [e-mail]<mailto:[e-mail]>
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > > >