Subject: [netmod] review of state NBC rules in yang-module-versioning-02

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 30 Mar 2021 01:55:18 +0000

Hi all,

I took a look at section "3.1.2 Backwards-compatibility rules for config false and output data" of https://tools.ietf.org/html/draft-ietf-netmod-yang-module-versioning-02.

Here are some suggestions (mostly just editorial - I agree with the general spirit of what's in here).

(A) Valuespace

Valuespace is defined in module versioning 02:
   o  Valuespace: The valuespace of a leaf or leaf-list is the set of
      values that the schema node may have according to the type and
      constraint statements of the YANG model.

It seems to be a more complete definition than "value space" in RFC7950 (which doesn't seem to take into account "range", "pattern", etc statements):

   o  value space: For a data type; the set of values permitted by the

      data type.  For a leaf or leaf-list instance; the value space of

      its data type.

Should we mention that this definition replaces/supercedes that of 7950 (at least for the scope of the module versioning doc) ?

I'd also recommend we call it "value space" rather than "valuespace".

(B)
replace "an additional state leaf can easily be discarded" with "the presence of an unexpected state leaf is not typically a problem for a client and can be ignored"

(C)
replace "config=false data" in the 1st paragraph with the following (and keep the quotes - that is how RFC8342 presents it):
                "config false" data

(D)
replace this:
   o  A client SHOULD be able to handle data that is outside the
      valuespace defined, as long as it is of the same basic type.
with this:

   o  A client SHOULD be able to handle instance data that is outside the defined

      value space of a schema node, as long as the data matches the base type of the schema node.

(E)
I don't think we should try to exhaustively list (and limit) all the factors that can change the value space of a schema node. So instead of this:

   o  Expanding the valuespace of a leaf or leaf-list is BC.  Change of

      the valuespace may be the result of a change to a range, length,

      pattern, base, enum, bit, require-instance or must statements.
how about this:

   o  Expanding the value space of a leaf or leaf-list schema node is BC (for example, a change, addition or removal of a range or length statement).

(F)

replace this:

  o  Changing min-elements to a lower value is NBC (it is like removing

      mandatory)

with this:

  o  Decreasing min-elements is NBC (it is similar to removing a mandatory statement)

(G)

There isn't really a "catch all" rule for everything else that isn't mentioned in section 3.1.2.  Should we have some sort of statement that state rules are the same as config rules (section 3.1.1) except where explicitly updated by this section 3.1.2 ?

Jason

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 30 Mar 2021 07:38:01 +0200

> Should we mention that this definition replaces/supercedes that of 7950 (at least for the scope of the module versioning doc) ?

Please no. RFC 7950 says data type and for me this includes everything
that defines a type, including the semantics carried in the type's
description statement.

We do not need to fix what is not broken. Why do we need a new
definition at all?  If definitions in RFC 7950 are broken, then we
need to fix it in YANG next.
 
/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: Martin Björklund <[email-masked]>
Date: Tue, 30 Mar 2021 08:10:15 +0200 (CEST)

> need to fix it in YANG next.

+1.  I don't think the text in RFC 7950 is broken.  It is better if
the new document refers to the defintion in RFC 7950, rather than
providing its own defintion with new words.

/martin

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

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 30 Mar 2021 12:13:18 +0000

Hi guys,

The text in 7950 doesn't mention anything about semantics in the description. That is part of what made me feel it isn't accurate or complete.

It also doesn't mention constraints like range or pattern. It only mentions the type.

Jason

> -----Original Message-----
> From: Martin Björklund <[email-masked]>
> Sent: Tuesday, March 30, 2021 2:10 AM
> To: [email-masked]
> Cc: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>;
> [email-masked]
> Subject: Re: [netmod] review of state NBC rules in yang-module-versioning-
> 02
> 
> > > I took a look at section "3.1.2 Backwards-compatibility rules for config
> false and output data" of https://tools.ietf.org/html/draft-ietf-netmod-
> yang-module-versioning-02.
> > >
> > > It seems to be a more complete definition than "value space" in RFC7950
> (which doesn't seem to take into account "range", "pattern", etc
> statements):
> > >
> > > Should we mention that this definition replaces/supercedes that of 7950
> (at least for the scope of the module versioning doc) ?
> >

---

From: tom petch <[email-masked]>
Date: Tue, 30 Mar 2021 15:51:15 +0000

From: netmod <[email-masked]> on behalf of Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>
Sent: 30 March 2021 13:13
Subject: Re: [netmod] review of state NBC rules in yang-module-versioning-02

Hi guys,

<tp>
I am with Martin and Juergen on this one.  You pick on two of the ten substatements for type but all are part of the definition of a type and are relevant in defining the value space; and elsewhere in the RFC, e.g. decimal64, there are explicit descriptions of the value space.  Whereas if you take, say, uint32 what more do you need to say to describe the value space?

Tom Petch

Jason

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 30 Mar 2021 16:15:40 +0000

Hi guys,

Let's take this model for a leaf (line numbers for reference):

10 leaf foo {
20      type uint8 {
30        range "5..101";
40      }
50 }

When I've been talking about "type" I've only been talking about line 20.  The base type of the leaf.

But are you guys considering that the term "type" includes 20 and 30 ?

I'm not sure that RFC7950 is terribly clear when it mentions "data type" below. Isn't that a bit ambiguous as to whether it includes line 30 or not?

In the example above I think the value space is 5..101. Is that correct?

But what about a description like this ?

10 leaf bar {
20      type uint8 {
30        range "5..101";
40      }
50      description "actually only takes values 5..88 in all current supported implementations";
60 }

That description isn't a substatement of the "type" statement. Is the value space 5..101 or 5..88 ?

Jason

> From: tom petch <[email-masked]>
> Sent: Tuesday, March 30, 2021 11:51 AM
> To: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>; Martin
> Björklund <[email-masked]>; [email-masked]
> Cc: [email-masked]
> From: netmod <[email-masked]> on behalf of Sterne, Jason
> (Nokia - CA/Ottawa) <[email-masked]>
> The text in 7950 doesn't mention anything about semantics in the
> description. That is part of what made me feel it isn't accurate or complete.
> 
> I am with Martin and Juergen on this one.  You pick on two of the ten
> substatements for type but all are part of the definition of a type and are
> relevant in defining the value space; and elsewhere in the RFC, e.g.
> decimal64, there are explicit descriptions of the value space.  Whereas if you
> take, say, uint32 what more do you need to say to describe the value space?
> 
> Tom Petch
> 
> Jason
>

---

From: Martin Björklund <[email-masked]>
Date: Tue, 30 Mar 2021 19:22:10 +0200 (CEST)

Hi,

> But are you guys considering that the term "type" includes 20 and 30

Yes; the definition in RFC 7950 is:

So line 20 and 30 together defines the set of values permitted byu
this type.

> I'm not sure that RFC7950 is terribly clear when it mentions "data
> type" below. Isn't that a bit ambiguous as to whether it includes
> line 30 or not?
> 

Yes.

> the value space 5..101 or 5..88 ?

Perhaps a better example is inet:uri from RFC 6991, which is defined
as:

     typedef uri {
       type string;
       description
        "The uri type represents a Uniform Resource Identifier
         (URI) as defined by STD 66.

         Objects using the uri type MUST be in US-ASCII encoding,
         and MUST be normalized as described by RFC 3986 Sections
         6.2.1, 6.2.2.1, and 6.2.2.2.  All unnecessary
         percent-encoding is removed, and all case-insensitive
         characters are set to lowercase except for hexadecimal
         digits, which are normalized to uppercase as described in
         Section 6.2.2.1.

         The purpose of this normalization is to help provide
         unique URIs.  Note that this normalization is not
         sufficient to provide uniqueness.  Two URIs that are
         textually distinct after this normalization may still be
         equivalent.

         Objects using the uri type may restrict the schemes that
         they permit.  For example, 'data:' and 'urn:' schemes
         might not be appropriate.

         A zero-length URI is not a valid URI.  This can be used to
         express 'URI absent' where required.

         In the value set and its semantics, this type is equivalent
         to the Uri SMIv2 textual convention defined in RFC 5017.";
       reference
        "RFC 3986: Uniform Resource Identifier (URI): Generic Syntax
         RFC 3305: Report from the Joint W3C/IETF URI Planning Interest
                   Group: Uniform Resource Identifiers (URIs), URLs,
                   and Uniform Resource Names (URNs): Clarifications
                   and Recommendations
         RFC 5017: MIB Textual Conventions for Uniform Resource
                   Identifiers (URIs)";
     }

The value space is all legal URIs, even though there is no pattern
defined.  An implementation may hook up a standard uri parser to
objects of this type.

Are we discussing a real problem here?

/martin

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 30 Mar 2021 18:47:35 +0000

Thanks Martin.

Maybe I'm in the minority thinking the definition in RFC7950 is slightly ambiguous. If anyone else thinks it might be, then let us know. Otherwise I'm fine to just stick with the 7950 definition.

That example in 6991 is a typedef which has a description statement. But a leaf that doesn't use a typedef may have a description for the leaf (not part of the type) that affects the value space. 

Jason

> Sent: Tuesday, March 30, 2021 1:22 PM
> To: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>
> Cc: [email-masked]; [email-masked]; j.schoenwaelder@jacobs-
> university.de; [email-masked]
> > > It also doesn't mention constraints like range or pattern. It only mentions
> the
> > > type.
> > >
> > > <tp>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 30 Mar 2021 12:06:30 -0700

> So line 20 and 30 together defines the set of values permitted byu

I think RFC 7950 is clear in this regard.

What concerns me is the idea that a "new YANG" can be defined that
overrides RFC 7950  (in any way) without actually updating the YANG
version number, or without any formal development of a new YANG language
version.

> Are we discussing a real problem here?

No, because it is clear that description-stmt semantics are just as
normative
as a pattern-stmt semantics or range-stmt semantics, etc.

> /martin

Andy

> > > It also doesn't mention constraints like range or pattern. It only
> mentions the
> > > type.
> > >
> > > <tp>
> > > > false and output data" of
> https://tools.ietf.org/html/draft-ietf-netmod-
> > > > > > Here are some suggestions (mostly just editorial - I agree with
> the
> > > > general spirit of what's in here).
> > > > > >
> > > > > > (A) Valuespace
> > > > > >
> > > > > > Should we mention that this definition replaces/supercedes that
> of
> > > 7950
> > > > > Fax:   +49 421 200 3103         <https://www.jacobs-university.de/
> >
> > > > >

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 30 Mar 2021 12:20:49 -0700

Hi -

> But are you guys considering that the term "type" includes 20 and 30 ?

Like others, I'm in the "20 and 30" camp.  But it's worth noting
that this was an area that frequently caused problems for modelers
new to GDMO.  GDMO had very strict rules about subclassing / subtyping
and compatibility, and the unwary would inadvertently overspecify
base classes' attributes, putting in ranges that would be narrower
than those eventually needed for future versions of products, and
preventing what would otherwise be great opportunities for reuse
and "automatic" interoperability.  It feels like an analogous
situation may underlie the concerns here.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 30 Mar 2021 21:39:33 +0200

Jason,

the type defined below has a value space that consists of the set of
prime numbers in the range 0 to 4294967295.

 typedef prime {
   type uint32;
   description
     "The set of prime numbers that can be represented in the 
      uint32 range".;
 }

People are way too focused on machine readable constructs but these
constructs often only capture a small part of the story. Yes, I can
inline this into a leaf definition, but this does not change the
value space of the (unnamed) type used by the leaf.

  leaf prime {
    type uint32;
    description
      "This leaf holds a prime number in the uint32 range";
  }

/js