YANG Library
draft-ietf-netconf-rfc7895bis-07

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

Alvaro Retana 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
other.

Martin Vigoureux No Objection

(Ignas Bagdonas; former steering group member) Yes

Yes ( for -06)
No email
send info

(Adam Roach; former steering group member) No Objection

No Objection (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.

---------------------------------------------------------------------------

§8.2:

>  [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.

(Alexey Melnikov; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Alissa Cooper; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Ben Campbell; former steering group member) No Objection

No Objection (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.

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Eric Rescorla; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Mirja Kühlewind; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Spencer Dawkins; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Suresh Krishnan; former steering group member) No Objection

No Objection ( for -06)
No email
send info