Subject: [netmod] LL review of 6020bis-04

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 11 Mar 2015 15:16:40 +0100

Hi,

here are my comments to the lastest revision of the 6020bis draft:

**** General
     Apart from "data node" and "schema node" that are defined in
     Sec. 3, the term "node" is used with at least two other meanings:
     - node in the data tree, i.e. an element in XML encoding,
     - XPath node.
     I have seen more than once that this confused people. Perhaps we
     should always use qualified terms such as "instance node" for the
     former and "XPath node" for the latter.

**** Sec. 5.1
     Circular includes are impossible because "include"
     statements in submodules are ignored.
      
     - OLD
       There MUST NOT be any circular chains of imports or includes.

     + NEW
       There MUST NOT be any circular chains of imports.

**** Sec. 7.1.6

     - OLD
       For backwards compatibility with YANG version 1, a submodule is
       allowed to include another submodule belonging to the same
       module, but this is not necessary in YANG version 1.1.

     + NEW
       For backwards compatibility with YANG version 1, "include"
       statements are permitted in submodules but they are ignored in
       YANG version 1.1.

     Also, s/backwards compatibility/backward compatibility/.

**** Sec. 7.2.2
     Can a submodule refer to definitions in the main module or other
     submodules without using a prefix?

**** Sec. 7.5.3
     
     - OLD
       When a datastore is validated, all "must" constraints are
       conceptually evaluated once for each data node in the
       accessible tree (see Section 6.4.1).

     + NEW When a datastore is validated, all "must" constraints are
       conceptually evaluated once for each instance node in the
       accessible tree (see Section 6.4.1).

**** Sec. 7.7.10
     If the definition of "cipher" leaf-list contained

       default "3des-cbc";

     and no instances of "cipher" existed in running, is the
     <edit-config> at the top of p. 70 still valid? If it is, what
     will be the final content of "cipher" leaf-list?

**** Sec. 9.6.4.2

     - OLD
       When an existing enumeration type is restricted, the "value"
       statement MUST either have the same value as the in the base
       type or not be present, in which case the value is the same as
       in the base type.

     + NEW
       When an existing enumeration type is restricted, the "value"
       statement MUST either have the same value as in the base type
       or not be present, in which case the value is the same as in
       the base type.

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 12 Mar 2015 11:07:38 +0100 (CET)

Hi Lada,

Thank you for reviewing this document!

>      former and "XPath node" for the latter.

Do you have an example of what you mean with "XPath node"?

>        There MUST NOT be any circular chains of imports.

See below.

>        statements are permitted in submodules but they are ignored in

I don't think they are ignored.  *If* they are present they must be
valid - the submodule that is included must belong to the same module,
and the revision date must match.

This is illegal in YANG 1.1 IMO:

  module x {
    ...
    include ietf-yang-types {
        revision-date 9999-04-01;
    }
    ...
 }

>      Also, s/backwards compatibility/backward compatibility/.

Fixed.

>      submodules without using a prefix?

Yes, and this hasn't changed from 6020.

>        accessible tree (see Section 6.4.1).

Ok, this is also unchanged from 6020.  But I agree that "data node" is
not correct here.

>        accessible tree (see Section 6.4.1).

I suggest just "each node in the accessible tree", which is the
language we use in all other places.

>      will be the final content of "cipher" leaf-list?

I think this depends on the with-default's basic-mode.

Hmm.  This is a very good observation!

Actually, basic-mode "trim" doesn't work well with defaults in
leaf-lists.  Suppose basic-mode is trim, and we have:

     leaf-list cipher  {
         type string;
         ordered-by user;
         default "3des-cbc";
         description "A list of ciphers";
     }

Now assume that the leaf-list is empty.  The client wants to set it
to:

   3des-cbc, blowfish-cbc

So the client sends:

  <cipher>3des-cbc</cipher>
  <cipher>blowfish-cbc</cipher>

When the server sees the first value for the cipher, chances are it
will just ignore it, since it matches the default value.

If we keep this new feature, we have to make sure implementors
understand that they must handle this.

Next, assume the implementation does handle this, and correctly stores
the two values in the leaf-list.  If the client removes blowfish-cbc,
a trimming server must now also delete the remaining leaf 3des-cbc.
Note that a server with basic-mode explicit would not do this.

So the basic-mode has quite large impact on the behavior in this
case.

>        or not be present, in which case the value is the same as in

Fixed.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 12 Mar 2015 12:07:06 +0100

> On 12 Mar 2015, at 11:07, Martin Bjorklund <[email-masked]> wrote:
> 
> Hi Lada,
> 
> Do you have an example of what you mean with "XPath node”?

In “context node” or “node set”, for example. But maybe in our case it is no different from “instance node”. From my experience, what’s really confusing for YANG newbies is that a data node is *not* a node in the data tree.

> and the revision date must match.

Such an include statement has no effect so what’s the point of performing these checks? Yes, it means that a YANG 1.1 submodule needn’t be valid in 1.0 but that doesn’t violate the charter.

> Yes, and this hasn't changed from 6020.

OK, then maybe the “prefix” statement under “belongs-to” could be made optional - except in very rare cases the same prefix could and should be used in the main module and all submodules.

> language we use in all other places.

OK. One alternative that just came to my mind would be to change “data/schema node” in the sense of Sec. 3 to “data/schema vertex”. Then “(data) node” could be freely used to denoted nodes in the data tree and XPath.
  
> I think this depends on the with-default's basic-mode.

It is the questionable what this statement really means:

   When the default values are in use, the server MUST operationally
   behave as if the leaf-list was present in the data tree with the
   default values as its values.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 12 Mar 2015 12:10:47 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> In “context node” or “node set”, for example. But maybe in our case it
> is no different from “instance node”. From my experience, what’s
> really confusing for YANG newbies is that a data node is *not* a node
> in the data tree.

I agree.  This is unfortunate.

> Such an include statement has no effect so what’s the point of
> performing these checks? Yes, it means that a YANG 1.1 submodule
> needn’t be valid in 1.0 but that doesn’t violate the charter.

If it is there it should make some sense IMO.  Otherwise it will just
be confusing to readers.

> OK, then maybe the “prefix” statement under “belongs-to” could be made
> optional - except in very rare cases the same prefix could and should
> be used in the main module and all submodules.

But we have the same rule for "prefix" under "module" - it is
mandatory to specify even if you don't use it in your module.

> OK. One alternative that just came to my mind would be to change
> “data/schema node” in the sense of Sec. 3 to “data/schema
> vertex”. Then “(data) node” could be freely used to denoted nodes in
> the data tree and XPath.
>   
> > 
> > 
> >> **** Sec. 7.7.10

Why is this questionable?

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 12 Mar 2015 12:55:26 +0100

> On 12 Mar 2015, at 12:10, Martin Bjorklund <[email-masked]> wrote:
> 

Well, writers shouldn’t use it in the first place. If it is a no-op, then insisting on any rules doesn’t make much sense to me. I assume it could be there only as a left-over from reused 1.0 submodules. 

> mandatory to specify even if you don't use it in your module.

Modules are different because “prefix” is also an information for other modules that’s not available elsewhere. Submodules are supposed to use the same prefix that’s defined in the main module - unless there is a collision with a prefix from an imported module.

> Why is this questionable?

It’s unclear what “operationally” means. It would seem that NETCONF is not part of operational behaviour, but then the term server in fact refers only to a NETCONF server (RFC 6241: "server: Executes protocol operations invoked by a client. In addition, a server can send notifications to a client.”).

Lada