Re: [netmod] type equivalence

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

> -----Original Message-----
> From: Juergen Schoenwaelder <[e-mail]>
> Sent: 26 February 2021 14:28
> To: Rob Wilton (rwilton) <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [netmod] type equivalence
> 
> 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
[RW] 

Constructed merely to have exactly the same type, but with different descriptions.

> 
>     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.
[RW] 

Sure, but if we are going to submit an errata for this definition, we want to ensure that updated definition is clear in all axes, not only the specific issue that was originally raised.

Hence, my question is really whether "semantics of the type" is intuitively obvious, or it requires further text that defines what is meant by that, specifically, that the description in the type (and probably parent types it's derived from) forms part of the semantics of a type definition.

Otherwise, it is possible that someone may think that it is pattern statement that defines the semantics of inet:ipv6-address, and not also the description.


> 
> > 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.
[RW] 

I'll split the rest into a separate thread.

Regards,
Rob