Benoit Claise <[email protected]> wrote:
> 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?
It means that it is treated as if it wasn't there.
> 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
Fixed.
> - 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.
Ok.
> 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.
Ok.
> - 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
I think the current text is fine, but I can live with:
NEW:
o during processing of the <edit-config> operation
> - 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.
Ok.
> 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.
Ok.
> - 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
Yes they are.
/martin
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
