Re: [netmod] type equivalence

[Juergen Schoenwaelder <[e-mail]>]

On Fri, Feb 26, 2021 at 03:27:39PM +0000, Rob Wilton (rwilton) wrote:
> 
> 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.
>

This is where the IETF shines, there is an attempt to fix a minor
problem and the result is N additional possible problems are put on
the table to be considered as well before the minor problem can be
fixed. My interest was the original question since I did run into it,
my interest is low in fixing all other possible problems that people
can think of.

Note, there are other places in RFC 7950 where the phrase 'semantics
of a definition' is used, e.g.,

   Otherwise, if the semantics of any previous definition are changed
   (i.e., if a non-editorial change is made to any definition other than
   those specifically allowed above), then this MUST be achieved by a
   new definition with a new identifier.

and this wording goes back to RFC 2578 and I am not aware that many
people had a problem with that, i.e., it seems to have worked 20+
years.

> 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.

I believe 'semantics of a definition' is likely as good as it gets.
 
> 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.
>

If 'semantics of a definition' is a problem, then someone should come
up with a separate proposal to fix this new problem (and as outlined
above, this phrase goes beyond the paragraph I suggested to clarify).
I am not interested in that can of worms and I assume most technical
people will know when they change the semantics of a definition.

I started this thread because

  type int8 { range "1..10"; description "a number between 1 and 10"; }

  type uint8 { range "1..10"; description "a number between 1 and 10"; }

can appear to be the same type but it is actually not due to the
change of the underlying built-in type and this is what I considered
worth to clarify. This is relevant for people writing YANG modules and
also for people working on encodings of YANG data where it matters
whether they can rely on underlying built-in types not changing.

Anyway, if this leads to N additional problems that can be considered
to be fixed, then I rather leave things as they are.

/js

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