Subject: [netmod] AD review draft-ietf-netmod-rfc6020bis-11 (part 2)

From: Benoit Claise <[email-masked]>
Date: Wed, 27 Apr 2016 11:53:46 +0200

Dear all,

Here is second and final part of my AD review.

-7.14.3.  The output Statement

    If a "config" statement is present for any node in the output tree,
    the "config" statement is ignored.

What does "ignored" mean?
We can't set a leaf as RPC output? If I take a the example in 7.15.3 ...

        yang-version 1.1;
        namespace "urn:example:server-farm";
        prefix "sfarm";

        import ietf-yang-types {
          prefix "yang";
        }

        list server {
          key name;
          leaf name {
            type string;
          }
          action reset {
            input {
              leaf reset-at {
                type yang:date-and-time;
                mandatory true;
               }
             }
             output {
               leaf reset-finished-at {
                 type yang:date-and-time;
                 mandatory true;
               }
             }
           }
         }
       }

I guess it means that reset-at is not instantiated, and only part of RPC-reply
It was not clear to me without investigation. A sentence around this would be welcome.

- section 7.17
Editorial:
        augment "/if:interfaces/if:interface" {
           when "if:type = 'mymod:some-new-iftype'";

           leaf mandatory-leaf {
              mandatory true;
              type string;
           }
        }
      }

Discussing with Martin, this example should be improved with derived-from (more flexible than equal), like in section 10.4.1.1

- Section8.2.  Configuration Data Modification
to be consistent with a previous comment (AD review part 1):

    - Section4.2.7.  Choices

    To be consistent with

        When a node from one case is created in the data tree, all nodes from
        all other cases are implicitly deleted.

    This text in section 7.9 should be updated.
    OLD:
        Since only one of the choice's cases can be valid at any time, the
        creation of a node from one case implicitly deletes all nodes from
        all other cases.  If a request creates a node from a case, the server
        will delete any existing nodes that are defined in other cases inside
        the choice.

    NEW:
        Since only one of the choice's cases can be valid at any time_in the data tree_, the
        creation of a node from one case implicitly deletes all nodes from
        all other cases.  If a request creates a node from a case, the server
        will delete any existing nodes that are defined in other cases inside
        the choice.

OLD:
    o  If a request creates configuration data nodes under a "choice",
       any existing nodes from other "case" branches are deleted by the
       server.
NEW:
    o  If a request creates configuration data nodes under a "choice",
       any existing nodes from other "case" branches_in the data tree_  are deleted by the
       server.

And also:
OLD:
    o  If a request modifies a configuration data node such that any
       node's "when" expression becomes false, then the node with the
       "when" expression is deleted by the server.

NEW:
    o  If a request modifies a configuration data node such that any
       node's "when" expression becomes false, then the node with the
       "when" expression_in the data tree_  is deleted by the server.

- section8.3.  NETCONF Constraint Enforcement Model

    For configuration data, there are three windows when constraints MUST
    be enforced:

    o  during parsing of RPC payloads

    o  during processing of NETCONF operations

    o  during validation

    Each of these scenarios is considered in the following sections.

Second bullet (why "s" on operations, btw), isn't "8.3.2.  NETCONF <edit-config> Processing"

OLD:

    o  during processing of NETCONF operations

NEW ?
    o  during processing of NETCONF <edit-config> Processing

- Section 9

Editorial proposal:

OLD: When a server sends _data encoded in XML_, it MUST use the 
canonical form defined in this section.

NEW:  When a server sends _XML encoded data___, it MUST use the canonical form defined in this section.

This would more in line with the text in 9:

   The lexical representation of a value of a certain type is used in
    the_XML encoding_  and when specifying default values and numerical
    ranges in YANG modules.

- section 10 XPath Functions

OLD:
    This document defines two generic XPath functions and four YANG type-
    specific XPath functions.

NEW:

    This document defines two generic XPath functions and five YANG type-
    specific XPath functions.

- I haven't checked, but I hope that all the RFC6020 errata are taken into account.
https://www.rfc-editor.org/errata_search.php?rfc=6020

Regards, Benoit

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 27 Apr 2016 12:38:00 +0200 (CEST)

> What does "ignored" mean?

It means that it is treated as if it wasn't there.

> Discussing with Martin, this example should be improved with
> derived-from (more flexible than equal), like in section 10.4.1.1

Fixed.

>       any existing nodes from other "case" branches_in the data tree_ are

Ok.

>       "when" expression_in the data tree_  is deleted by the server.

Ok.

>    o  during processing of NETCONF <edit-config> Processing

I think the current text is fine, but I can live with:

NEW:

  o  during processing of the <edit-config> operation

> canonical form defined in this section.

Ok.

>    specific XPath functions.

Ok.

> - I haven't checked, but I hope that all the RFC6020 errata are taken
> - into account.

Yes they are.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Apr 2016 14:52:53 +0200

> >       "when" expression_in the data tree_  is deleted by the server.

It is actually "the node in the data tree that corresponds to the
schema node with a when expression" since the when expression is a
property of the schema tree node, not a property of a data tree
node. Not sure this helps with readability though.

/js

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