Subject: [netmod] type equivalence

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 19 Feb 2021 17:55:49 +0100

Hi,

can I safely replace

    leaf foo {
      type int8 { range "0..100"; };
    }

with

    leaf foo {
      type uint8 { range "0..100"; };
    }

or with

    leaf foo {
      type int32 { range "0..100"; };
    }

or are these a non-backwards compatible changes? Note that the value
set is always the same, however the underlying base type changes. Did
we ever define type equivalence?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 19 Feb 2021 18:24:02 +0100

On 2021-02-19, at 17:55, Juergen Schoenwaelder <[email-masked]> wrote:
> or are these a non-backwards compatible changes?

I don’t have an answer to that, but would like to point you to the table at the top of page 14 in draft-ietf-core-comi-11.txt [1], which would make the first replacement a non-backwards compatible change in the way we build URIs from that.

[1]: https://tools.ietf.org/html/draft-ietf-core-comi-11#page-14

> Note that the value

The way unions are handled in YANG gives me the impression that as long as the sets of XML representations generated by the two types are the same, they are equivalent.

Grüße, Carsten

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 19 Feb 2021 19:18:58 +0100

I think the CBOR encoding picks different tags depending on the
signedness of the base type and this is why things are not that simple
anymore. For the XML and JSON encodings, all definitions lead to the
same on-the-wire representation, hence the difference is more an
implementation detail. I have no clue what the gnmi people do. The
more diverse encodings we add, the more complex things get.

/js

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 19 Feb 2021 22:32:34 +0100

> On 2021-02-19, at 19:18, Juergen Schoenwaelder <[email-masked]> wrote:
> 
> anymore.

(This is not the CBOR encoding, but the COMI encoding of keys in URIs.)

> For the XML and JSON encodings, all definitions lead to the

Well, if the equivalence expectation that I was trying to describe actually is ingrained, then whoever designs an encoding (COMI for its URI encoding included) needs to respect it.  That would be important to know.

Grüße, Carsten

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 22 Feb 2021 10:24:55 +0100

> (This is not the CBOR encoding, but the COMI encoding of keys in URIs.)

OK. The CBOR document indeed says:

6.1.  The unsigned integer Types

   Leafs of type uint8, uint16, uint32 and uint64 MUST be encoded using
   a CBOR unsigned integer data item (major type 0).

6.2.  The integer Types

   Leafs of type int8, int16, int32 and int64 MUST be encoded using
   either CBOR unsigned integer (major type 0) or CBOR negative integer
   (major type 1), depending on the actual value.

This means the type 'int8 { range 0..10; }' leads to the same
encodings as the type 'uint8 { range 0..10; }'.

> Well, if the equivalence expectation that I was trying to describe actually is ingrained, then whoever designs an encoding (COMI for its URI encoding included) needs to respect it.  That would be i…

Exactly. I think we never defined this. And of course, this can get
even more fun if you consider string based encodings. The type

   type string { pattern "1|2|3|4"; }

yields the same _XML encoded_ value space as

   type int32 { range "1..4"; }

but as far as I recall the JSON/CBOR encodings will treat these two
differently. So yes, ideally the YANG language would have clear rules
what YANG's type equivalences are.

/js

---

From: Martin Björklund <[email-masked]>
Date: Mon, 22 Feb 2021 10:49:38 +0100 (CET)

Hi,

Section 11 of RFC 7950 says:

   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.

If we're just considering XML, then the syntax or encoding wouldn't
change if we went from

  type int64 { range "2..4"; }

to

  type string { pattern "2|3|4"; }

or

  type enumeration {
    enum 2;
    enum 3;
    enum 4;
  }

or

  type union {
    type uint8 { range "2"; }
    type string { pattern "3"; }
    type enumeration { enum 4; }
  }

But I don't think this is reasonable, and not the intention.  I think
that changing the base built-in type always should be considered
non-backwards compatible (which the quoted text above seems to imply).

/martin

Juergen Schoenwaelder <[email-masked]> wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 22 Feb 2021 11:00:36 +0100

> non-backwards compatible (which the quoted text above seems to imply).

Agreed. Another problem related to sec. 11 is that it permits to update
a module so that the range specification is extended, which may then
expose the incompatibility of e.g. uint8 and int8.

But I thought that Jürgen's question was directed to the definition of
backward compatibility in the semver context.

Lada

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 22 Feb 2021 11:08:57 +0100

Thanks Martin,

so you are saying that

  int8 { range "1..10"; }

is indeed different from

  uint8 { range "1..10"; }

and

  int32 { range "1..10"; }

The use of the word "syntax" in the text you quote may be a left-over
from SMIv2 times, it does not really seem to be aligned with how the
term 'syntax' is used elsewhere in RFC 7950. Anyway, if the agreement
back then was that you can't change base types (regardless of type
restrictions), it would have been nice if the text would say this more
clearly.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 22 Feb 2021 11:11:26 +0100

> backward compatibility in the semver context.

No, the background is not semver here, it is "can we harmonize N
different existing definition of "0..100" to one. And it seems the
answer is "no", at least not in a backwards compatible way if people
picked different base types.

/js

---

From: Martin Björklund <[email-masked]>
Date: Mon, 22 Feb 2021 11:13:43 +0100 (CET)

>   int32 { range "1..10"; }

Yes.

> from SMIv2 times

[That's what I thought as well, but I couldn't find it in the SMIv2
RFCs.  Perhaps it was from some sming text?]

> , it does not really seem to be aligned with how the

Agreed.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 22 Feb 2021 11:21:54 +0100

> picked different base types.

+1

Lada

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 22 Feb 2021 11:47:05 +0100

> On 2021-02-22, at 11:13, Martin Björklund <[email-masked]> wrote:
> 

Oh.  People often choose uint8 etc. with an intention to set a range.
I don’t think they know that they are setting themselves up for NBC if that range needs to be extended later.
So I would have expected that there is a common base type these are all derived from.

RFC 7950 does not use "base type" as an absolute term; it only can be used relative to “derived type”.
I don’t know which of the built-in types are “absolute base types” in the sense you would need it to define the rule.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 22 Feb 2021 11:50:41 +0100

On 2021-02-22, at 10:24, Juergen Schoenwaelder <[email-masked]> wrote:
> differently.

We certainly called this out as expected collateral damage when we developed YANG-CBOR.

So my “deductive rule of type equivalence” is not faithfully respected by YANG-CBOR.  We did see a need to bow to it for unions, though.

> So yes, ideally the YANG language would have clear rules

For a value of “ideal” that is closer to “fundamentally necessary” :-)

Grüße, Carsten

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 22 Feb 2021 14:53:33 +0100

> I don’t know which of the built-in types are “absolute base types” in the sense you would need it to define the rule.

Yes, "base type" is the wrong term, I think we talk about what RFC
7950 calls "build-in types".

/js

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 22 Feb 2021 14:55:57 +0100

On 2021-02-22, at 14:53, Juergen Schoenwaelder <[email-masked]> wrote:
> 7950 calls "build-in types”.

OK, so rephrasing my question:

Are all built-in types incompatible in the sense that moving from one to the other is NBC, or are there clusters where moving within is innocuous?

Grüße, Carsten

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 22 Feb 2021 15:17:15 +0100

> Are all built-in types incompatible in the sense that moving from one to the other is NBC, or are there clusters where moving within is innocuous?

I do not think we ever had the notion of "clusters" (or something like
the universal unlimited INTEGER in ASN.1, a common root of all fixed
precision integer types).

Martin and Lada seem to say that all built-in types are incompatible.
Lada made the point that range restrictions can be expanded and hence
the differences of the size or the signedness of the underlying
built-in type may eventually matter.

Of course, if we go down this route, then encodings may take advantage
of this. I have no clue what code generators do, if they indeed map

    type int32 { range "0..10"; }

to a 32-bit signed number (to be prepared that someone may enlarge the
range) or whether they go for more space efficient representations
(and then versioning issues may arise or you live with implicit
integer conversions if your programming language does them).

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.

/js

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 22 Feb 2021 15:20:02 +0100

> 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

---

From: tom petch <[email-masked]>
Date: Wed, 24 Feb 2021 11:52:40 +0000

From: netmod <[email-masked]> on behalf of Martin Björklund <[email-masked]>
Sent: 22 February 2021 10:13

Yes.

<tp>
When asked about SNMP/SMI, I always say to start with RFC1155/1156/1157.  Either of the first two gives, for me, a clear exposition of the meaning of 'syntax' which I have always taken as read in YANG.

Going back, well, ASN.1, ISO etc etc

Tom Petch

Agreed.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 24 Feb 2021 21:39:15 +0100

Here is an attempt to come up with better wording. If people agree on
a new wording, I volunteer to submit an errata.

OLD

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.

/js

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 25 Feb 2021 17:10:21 +0000

> -----Original Message-----
> From: netmod <[email-masked]> On Behalf Of Martin Björklund
> Sent: 22 February 2021 10:14
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [netmod] type equivalence
> 
[RW] 

Since the YANG module versioning draft clarifies the BC/NBC rules, perhaps we could add text to clarify this in that draft?

I.e., perhaps something for section 3.1.3 of https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-versioning/

Regards,
Rob

// As a contributor.

> > > > > > On 2021-02-19, at 19:18, Juergen Schoenwaelder
> <[email-masked]> wrote:
> > > > > >
> > > > > Well, if the equivalence expectation that I was trying to describe
> actually is ingrained, then whoever designs an encoding (COMI for its URI
> encoding included) needs to respect it.  That would be important to know.
> > > > >
> > > >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 25 Feb 2021 19:00:31 +0100

> I.e., perhaps something for section 3.1.3 of https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-versioning/

I rather have this fixed (or clarified) in RC 7950, as far as I
understand I can choose to ignore the versioning extensions and
simply use YANG 1.1, no?

That said, draft-ietf-netmod-yang-module-versioning-02.txt says
in 3.1.2.:

   o  Modifying the type of a leaf or leaf-list is NBC

This seems to be way more restrictive than the existing YANG 1.1 rules
we have today. Perhaps that is what the versioning people want, but
then we better keep the YANG 1.1 rules and the YANG + versioning rules
separate.

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 25 Feb 2021 10:33:10 -0800

On Thu, Feb 25, 2021 at 10:00 AM Juergen Schoenwaelder <
[email-masked]> wrote:

> > Since the YANG module versioning draft clarifies the BC/NBC rules,
> perhaps we could add text to clarify this in that draft?
> >
> > I.e., perhaps something for section 3.1.3 of
> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-versioning/
> >
>
+1

This data types update does not need any new external dependencies.

> /js
Andy

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 25 Feb 2021 19:22:27 +0000

> From: Juergen Schoenwaelder <[email-masked]>
> Sent: 25 February 2021 18:01
> To: Rob Wilton (rwilton) <[email-masked]>
> Cc: [email-masked]
[RW] 

As a contributor:
I presume so.

As an AD:
Whether this can be done as a verified errata isn't so clear, but would obviously depend on the proposed text.

[RW] 

As a contributor:
That is just new text recently added for the config false nodes.  I think that it just needs some worth smithing, possibly along with the rest of that section.

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 25 Feb 2021 21:01:39 +0100

> Whether this can be done as a verified errata isn't so clear, but would obviously depend on the proposed text.

I have proposed text that tries to fix the unfortunate use of
'syntax'. Does the AD see an issue with the proposed text?

/js

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 26 Feb 2021 11:31:58 +0000

Hi Juergen,

> Sent: 25 February 2021 20:02
[RW] 

I apologise if you felt that I was trying to assert authority here, that was not my intent.  My aim was to be clear in what capacity I was commenting, but my efforts may have been clumsy.  Also, at the point that I wrote my email, I had not seen that you had sent proposed errata text, which I will comment on separately on that thread.

There is also an underlying background here is that the IESG is currently working on refining the rules for how errata are processed (e.g., it was discussed in yesterday's telechat).  And until those guidelines settle, which hopefully shouldn't be long, I'm not quite sure which way this errata would land, i.e., verified, hold for update, or rejected.

My specific concern is whether it was clear at the point that consensus was called on RFC 7950 that everyone had the same interpretation of the expected behaviour, even if that wasn't clear in the text.

I also note that draft-ietf-netmod-yang-module-versioning-02 states:

   This document updates [RFC7950] section 11.  Section 3 describes
   modifications to YANG revision handling and update rules, and
   Section 4 describes a YANG extension statement to do import by
   derived revision.

So, I'm still of the opinion that clarifying this behaviour in draft-ietf-netmod-yang-module-versioning-02, if the proposed change cannot be accepted as a verified errata, is a pragmatic solution.

Regards,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 26 Feb 2021 12:45:39 +0100

> So, I'm still of the opinion that clarifying this behaviour in draft-ietf-netmod-yang-module-versioning-02, if the proposed change cannot be accepted as a verified errata, is a pragmatic solution.

This document has a long way to go. I am not sure everybody agrees
with changing YANG 1.1 rules by an update (without changing YANG's
version number, i.e., it becomes upclear which rules apply to a given
YANG module).

/js

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 26 Feb 2021 12:21:26 +0000

> From: netmod <[email-masked]> On Behalf Of Juergen Schoenwaelder
> Sent: 24 February 2021 20:39
> To: [email-masked]
[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?

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

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 26 Feb 2021 15:27:49 +0100

>         that resolves to the same underlying built-in type.  For example,

Perhaps - but it is not just the built-in type that matters...
 
>        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.
 
> 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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 26 Feb 2021 06:56:39 -0800

On Fri, Feb 26, 2021 at 3:45 AM Juergen Schoenwaelder <
[email-masked]> wrote:

> > So, I'm still of the opinion that clarifying this behaviour in
> draft-ietf-netmod-yang-module-versioning-02, if the proposed change cannot
> be accepted as a verified errata, is a pragmatic solution.
> >
>

I do not think an update of any kind can brush aside MUST and MUST NOT
details
in the updated RFC.  It has also been established that YANG extensions are
optional
for a YANG 1.1 tool and MAY be skipped and ignored, so a new YANG language
version
cannot be introduced through the use of external statements.

We have not seen any demand whatsoever for "NBC automation tools".
Violations of sec. 11 rules are rare (and I prefer to keep them that way).
In any event, it would require a new YANG version to undo the YANG 1.1
update rules.

/js

Andy

---

From: Martin Björklund <[email-masked]>
Date: Fri, 26 Feb 2021 16:06:16 +0100 (CET)

> 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

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 26 Feb 2021 15:27:39 +0000

> Sent: 26 February 2021 14:28
[RW] 

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

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

> Perhaps this requires a separate thread.
[RW] 

I'll split the rest into a separate thread.

Regards,
Rob

---

From: Andy Bierman <[email-masked]>
Date: Fri, 26 Feb 2021 08:11:53 -0800

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

> > > > On 2021-02-22, at 15:17, Juergen Schoenwaelder
> <j.schoenwaelder@jacobs-
> > > university.de> wrote:
> > > > >

---

From: Martin Björklund <[email-masked]>
Date: Fri, 26 Feb 2021 17:30:10 +0100 (CET)

+1

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

/martin

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 26 Feb 2021 16:32:34 +0000

> From: Martin Björklund <[email-masked]>
> Sent: 26 February 2021 16:30
> To: [email-masked]
> Cc: Rob Wilton (rwilton) <[email-masked]>; [email-masked]
[RW] 

But the proposed errata removes the text about not changing the syntax, or are you referring to other text?

Rob

> > > > > > > robust approach. If we agree that RFC 7950 tried to say this,
> we
> > > could

---

From: Martin Björklund <[email-masked]>
Date: Fri, 26 Feb 2021 17:36:38 +0100 (CET)

"Rob Wilton (rwilton)" <[email-masked]> wrote:
> 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.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 26 Feb 2021 08:44:39 -0800

On Fri, Feb 26, 2021 at 8:36 AM Martin Björklund <[email-masked]> wrote:

> > > > > > > Here is an attempt to come up with better wording. If people
> agree
> > > on
> > > > > > >       but an int8 type cannot be replaced by an int16, since
> the
> > > syntax
> > > > > > >       would change.
> > > > > > >
> > > > > > > NEW
> > > > > > >
> > > > > > >       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

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.

Andy

> >
> > Rob
> >
> >
> > >
> > >
> > > /martin
> > >
> > >
> > >
> > > >
> > > >
> > > > Andy
> > > >
> > > >
> > > > > [RW]
> > > > > >
> > > > > > Would the text be more clear it is just specified what is
> allowed,
> > > e.g.,
> > > > > >
> > > > > >    organization, identifiers, and type-based constraints.  If a
> node
> > > in
> > > > > >    MUST NOT be returned, and some other mechanism should be used
> to
> > > flag
> > > > > >    the error.
> > > > > >
> > > > > > My memory during the discussions was that it is allowed to
> return a
> > > value
> > > > > > in the value space of the built-in-type.  E.g., cannot return
> 257 in
> > > a
> > > > > > > > > I guess considering the built-in types as incompatible is
> the
> > > most

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 26 Feb 2021 16:45:05 +0000

> Sent: 26 February 2021 16:37
> Cc: [email-masked]; [email-masked]
> > > > > > >       that does not change the syntax or semantics of the
> type.
> > > For
> > > > > > >       example, an inline type definition may be replaced with
> a
> > > > > typedef,
[RW] 

Not sure.  I think that it is reasonable clear, as long as you don't talk about changes in the syntax ;-)

But, it might be worth explicitly pulling out that union type is a change, otherwise someone might try and fudge this by changing uint32 to a union of uint32 and uint64.

Rob

> > > > > > > > Right.  And we can keep the COMI key-to-URL mapping as is,
> as
> > > this

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 26 Feb 2021 16:53:22 +0000

From: Andy Bierman <[email-masked]>
Sent: 26 February 2021 14:57
To: Juergen Schoenwaelder <[email-masked]>; Rob Wilton (rwilton) <[email-masked]>; [email-masked]
Subject: Re: [netmod] type equivalence

On Fri, Feb 26, 2021 at 3:45 AM Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:

I do not think an update of any kind can brush aside MUST and MUST NOT details
in the updated RFC.
[RW]
In the general case, I don’t believe this is correct.

E.g., some bits in a protocol header that are reserved for future use and are specified as the sender MUST set to 0, and receiver MUST ignore.  Then an extension comes along and wants to make use of those bits, updating, but not obsoleting, the base RFC.
Or a more recent case, not directly related to RFC 2119 language, is changing an existing IANA registry from Vendor Private Use to FCFS.  This was done by updating the base RFC.

Specifically, the module-versioning draft is not trying to create a new version of YANG but fix issues and make it better for clients:

E.g., in RFC 7950, a vendor is allowed to move from status current to obsolete immediately, at which point the server SHOULD NOT implement the node.  This would have pretty much the same impact on clients as just deleting the node.

I believe that draft-ietf-netmod-yang-module-versioning-02 improves on RFC 7950 by requiring this breaking change to be flagged in the module history as NBC, and gives serves the ability to advertise that they don’t implement obsolete nodes.

In addition, servers can implement or not implement status deprecated nodes, and they do not need to flag to clients whether or not that node is implemented:

E.g.
 leaf foo {
    type string;
   mandatory true;
   status deprecated;
}

leaf bar {
    type string;
   mandatory true;
   status deprecated;
}

Two RFC 7950 compliant servers:

  *   The first implements foo but not bar.  The second implements bar but not foo.  Clients do not know which leaves are implemented by the server, and implementing neither/both doesn’t help since it will always fail on one server.

draft-ietf-netmod-yang-module-versioning-02 aims on improving RFC 7950 by requiring that status deprecated nodes are always implemented or explicitly deprecated, so that API to the client is always well defined.

It also attempts to ensure that this information about deprecated leaves being implemented is communicated to clients in a backwards compatible way via an augmentation to YANG library.

Regards,
Rob

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 26 Feb 2021 16:57:03 +0000

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 <[email-masked]>
Sent: 26 February 2021 16:45
To: Martin Björklund <[email-masked]>
Cc: Rob Wilton (rwilton) <[email-masked]>; NetMod WG <[email-masked]>
Subject: [SUSPECTED SPAM] Re: [netmod] type equivalence

On Fri, Feb 26, 2021 at 8:36 AM Martin Björklund <[email-masked]<mailto:[email-masked]>> wrote:
"Rob Wilton (rwilton)" <[email-masked]<mailto:[email-masked]>> wrote:
> > From: Martin Björklund <[email-masked]<mailto:[email-masked]>>
> > To: [email-masked]<mailto:[email-masked]>
> > Cc: Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
> > Andy Bierman <[email-masked]<mailto:[email-masked]>> wrote:
> > > On Fri, Feb 26, 2021 at 7:06 AM Martin Björklund <[email-masked]<mailto:[email-masked]>>
> > wrote:
> > >
> > > > "Rob Wilton \(rwilton\)" <rwilton=[email-masked]<mailto:[email-masked]>> wrote:
> > > > >
> > > > >
> > > > > > From: netmod <[email-masked]<mailto:[email-masked]>> On Behalf Of Juergen
> > > > Schoenwaelder
> > > > > > To: [email-masked]<mailto:[email-masked]>

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

> > > > <j.schoenwaelder@jacobs-
<mailto:j.schoenwaelder@jacobs-%0b>> > > > > > university.de<http://university.de>> wrote:
> > > > > > Fax:   +49 421 200 3103         <https://www.jacobs-
> > university.de/<http://university.de/>>
> > > > > >
> > > > > > [email-masked]<mailto:[email-masked]>
> > > > > [email-masked]<mailto:[email-masked]>
> > > > [email-masked]<mailto:[email-masked]>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 26 Feb 2021 18:55:21 +0100

> 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 (…

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

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 26 Feb 2021 19:05:32 +0000

> Sent: 26 February 2021 17:55
> > 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.
> >
> 
[RW] 

I'm not convinced that accurately describes the situation.  

If it helps to clarify, I have three specific goals here:

(1) Check that the proposed corrected text doesn't contain further bugs that also need to be fixed.  After all you cannot file an errata on an errata, and it doesn't look great for me if I have to request that a verified errata is changed to rejected because it contains further issues in a two sentence paragraph.

(2) Workout whether the errata can be marked as verified, hold for update, or needs to be rejected.

(3) Check that the same bug doesn't exist in other places.  I agree that this is a tangential goal, and I have already forked this into a separate thread, as you had requested.

I am not asking you to generically fix or define "semantics", but I really would like our proposed replacement text to be entirely unambiguous, and contain no further issues.

E.g., I'm wondering, would your proposed new definition allow us to change from the IETF to IEEE MAC address definition?  The underlying type is the same (String), and arguably the semantics of both types is the same (i.e., they both represent an IEEE 802 MAC address), but the syntax of the two types clearly differs.

Regards,
Rob

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Sat, 27 Feb 2021 09:48:21 +0000

Sorry, but I wish to raise another question regarding changing types.

Are you allowed to change from one type to another type that 'contains' the first type.

typedef smallInt {

typedef biggerInt {
  type int8 { range "0..200"; };
}

Can I change leaf foo from:

    leaf foo {
      type smallInt;
    }

to:

    leaf foo {
      type biggerInt;
    }

I'm not sure that the chapter 11 rules in RFC 7950 formally allow this (either with or without the proposed errata), but intuitively I would expected this to be allowed by commutativity, since this change is clearly legal if you go via a third intermediate type.

E.g., you could change leaf foo from using smallInt to a new tempInt:

typedef tempInt {

Then, as a second update, change the range in tempInt:

typedef tempInt {
  type int8 { range "0..200"; };
}

And in the final step change leaf foo from using tempInt to use biggerInt.

Rob

> From: Rob Wilton (rwilton)
> Sent: 26 February 2021 19:06
> To: Juergen Schoenwaelder <[email-masked]>
> Cc: NetMod WG <[email-masked]>
> Subject: RE: [netmod] type equivalence
> 
> 
> 
> (1) Check that the proposed corrected text doesn't contain further bugs
> that also need to be fixed.  After all you cannot file an errata on an
> errata, and it doesn't look great for me if I have to request that a
> verified errata is changed to rejected because it contains further issues
> in a two sentence paragraph.
> 
> (3) Check that the same bug doesn't exist in other places.  I agree that
> this is a tangential goal, and I have already forked this into a separate
> thread, as you had requested.
> 
> I am not asking you to generically fix or define "semantics", but I really
> would like our proposed replacement text to be entirely unambiguous, and
> contain no further issues.
> 
> E.g., I'm wondering, would your proposed new definition allow us to change
> from the IETF to IEEE MAC address definition?  The underlying type is the
> same (String), and arguably the semantics of both types is the same (i.e.,
> they both represent an IEEE 802 MAC address), but the syntax of the two
> types clearly differs.
> 
> Regards,
> Rob

---

From: Martin Björklund <[email-masked]>
Date: Sat, 27 Feb 2021 15:46:53 +0100 (CET)

> Can I change leaf foo from:

Yes, this was clearly the intention.

We have these two rules:

   o  A "range", "length", or "pattern" statement may expand the allowed
      value space.

But I assume you mean that the second bullet doesn't allow an expanded
value space?

/martin

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Sun, 28 Feb 2021 18:21:27 +0000

Hi Martin,

> Sent: 27 February 2021 14:47
> Cc: [email-masked]; [email-masked]
[RW] 

Yes, not if you take a literal interpretation of it.

I think that the type can be replaced, if and only if:
  - it resolves to the same underlying base type, and
  - the semantics remains the same (as given by the description statement), and
  - the value space of the new type is the same as, or a superset of, the replaced type.

I don't think that syntax needs to be constrained if the base type and value space are already constrained.

Rob

> 
> 
> /martin
> 
> 
> 
> >
> > I'm not sure that the chapter 11 rules in RFC 7950 formally allow this
> (either with or without the proposed errata), but intuitively I would
> expected this to be allowed by commutativity, since this change is clearly
> legal if you go via a third intermediate type.
> >
> > > > want to ensure that updated definition is clear in all axes, not
> only
> > > the
> > > (2) Workout whether the errata can be marked as verified, hold for
> update,
> > > or needs to be rejected.
> > >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 28 Feb 2021 20:48:25 +0100

> E.g., I'm wondering, would your proposed new definition allow us to change from the IETF to IEEE MAC address definition?  The underlying type is the same (String), and arguably the semantics of bot…

If [1] is true, then the answer is obviously 'no' since the value spaces
of the two types are disjunct.

/js

[1] https://www.ieee802.org/1/files/public/docs2020/yangsters-smansfield-mac-address-format-0420-v01.pdf