Re: [netmod] type equivalence

[Juergen Schoenwaelder <[e-mail]>]

On Fri, Feb 26, 2021 at 12:21:26PM +0000, Rob Wilton (rwilton) 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.
> [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,
>         ...

Perhaps - but it is not just the built-in type that matters...
 
> What does "semantics of the type" cover?
> 
> 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";
>   }

This example seems to be constructed since "in any format" is already
broken to begin with. A more perhaps better example: If you have

    type inet:ipv4-address;

then you can't replace that with

    type inet:ipv6-address;

since that changes the semantics of the type. If you have a counter
that only counts upwards (until it wraps or latches), then you can't
replace it with a gauge that goes up and down. The point is that you
break expectations about the semantics of a value of existing
applications.

In your example, if you have time in any format, then well
interoperability does not seem to be expected in the first place and
then you can start a philosophical discussion whether making something
non-interoperable even more non-interoperable is not just leading to
non-interoperable.

Anyway, the "semantics" part was not the question that triggered this
thread, the question was whether changing built-in types is allowed or
not.
 
> 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.

Perhaps this requires a separate thread. Perhaps 'syntactic
constraints' was not a good choice and yes different people might
understand 'type-based constraints' differently. RFC 7950 says:

   The following properties are true in all data trees:

   o  All leaf data values MUST match the type constraints for the leaf,
      including those defined in the type's "range", "length", and
      "pattern" properties.

So I am not sure about returning 11 for a range 1..10.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>