YANG Library

Note: This ballot was opened for revision 06 and is now closed.

(Ignas Bagdonas) Yes

Deborah Brungard No Objection

(Ben Campbell) No Objection

Comment (2018-10-10 for -06)
Just a few minor comments:

Substantive Comments:

§2, 2nd bullet: "Each YANG module and submodule within the library SHOULD have a revision."
Why not MUST? Does it ever make sense not to have a revision? What are the consequences?

Editorial Comments:

§1, last paragraph: Missing article before "YANG Library" in first sentence.

§2, list item 1: "Efficient for a client to consume." - sentence fragment.
-- List item 3: Why is "NOT" in all-caps?
-- List item 6: The first sentence, while not technically a fragment, seems to use an understood "you" as the subject. I doubt that is the intent.

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

Benjamin Kaduk No Objection

Comment (2018-10-08 for -06)
No email
send info
It's interesting that multiple entries for full-fledged module
implementation are forbidden, but import-only modules can have multiple
(different) entries.  I'm not familiar enough with the YANG ecosystem to
understand why one is more common or more reasonable to permit than the

(Suresh Krishnan) No Objection

(Mirja Kühlewind) No Objection

(Alexey Melnikov) No Objection

(Eric Rescorla) No Objection

Alvaro Retana No Objection

(Adam Roach) No Objection

Comment (2018-10-10 for -06)
No email
send info
Thanks for the work everyone did on this document.

ID Nits reports:

  ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446)
  ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341)


Page 16:

>      leaf checksum {
>        type string;
>        mandatory true;
>        description
>          "A server-generated checksum of the contents of the
>           'yang-library' tree.  The server MUST change the value of
>           this leaf if the information represented by the
>           'yang-library' tree, except 'yang-library/checksum', has
>           changed.";

I suspect that changing the name of this node in the tree would be disruptive
at this point in time, but this is clearly not a checksum ("There is no
requirement that the same information always results in the same 'checksum'
value"). I would suggest updating the description to use the term "version
identifier" or something similar.



>  [RFC8340]  Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
>             BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
>             <https://www.rfc-editor.org/info/rfc8340>.

Since RFC 8340 is required to understand the syntax used in the tree diagrams
used by draft-ietf-netconf-rfc7895bis, RFC 8340 should be normative rather
than informative.

Martin Vigoureux No Objection