YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)
RFC 6020

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

(Ron Bonica) Yes

(Alexey Melnikov) (was Discuss) Yes

Comment (2010-06-08)
No email
send info
Formerly a DISCUSS item:

5.1.  Modules and Submodules

   The names of all standard modules and submodules MUST be unique.
   Developers of enterprise modules are RECOMMENDED to choose names for

(Similar text in several other sections, e.g. 7.1, 7.2)
Why RECOMMENDED and not a MUST here?
I.e. what is a good reason to violate this and to choose conflicting names?

   their modules that will have a low probability of colliding with
   standard or other enterprise modules, e.g., by using the enterprise
   or organization name as a prefix for the module name.

7.10.2.  XML Mapping Rules

   An anyxml node is encoded as an XML element.  The element's local
   name is the anyxml's identifier, and its namespace is the module's
   XML namespace (see Section 7.1.3).  The value of the anyxml node is
   encoded as XML content of this element.


7.10.4.  Usage Example

   Given the following anyxml statement:

     anyxml data;

   The following are two valid encodings of the same anyxml value:

     <data xmlns:if="http://example.com/ns/interface">

DISCUSS DISCUSS: I don't see where the payload ("<if:interface>...") is coming from.
<<I might be misunderstanding something, clear this item if that is the case.>>

7.19.3.  The description Statement

   The "description" statement takes as an argument a string which
   contains a high-level textual description of this definition.

As this field is human readable, I think BCP 18 (RFC 2277), Section 4.2 applies. So this would need ability to tag language of the description.
(YIN should be using xml:lang attribute.)

You can find a bit more information on <http://trac.tools.ietf.org/group/iesg/trac/wiki/TypicalAppsAreaIssues>


9.4.  The string Built-in Type

   The string built-in type represents human readable strings in YANG.
   Legal characters are tab, carriage return, line feed, and the legal
   characters of Unicode and ISO/IEC 10646 [ISO.10646]:

     ;; any Unicode character, excluding the surrogate blocks,
     ;; FFFE, and FFFF.

This comment is not quite correct - it doesn't mention excluded ASCII control characters (at least some of them).

(Dan Romascanu) Yes

(Jari Arkko) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

Comment (2010-04-22 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
The acronym NETCONF should be expanded in the Abstract.

(Ralph Droms) No Objection

(Adrian Farrel) No Objection

(Russ Housley) No Objection

(Tim Polk) (was No Record, Discuss) No Objection

Comment (2010-05-25 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I have cleared - I believe that this issue can be more appropriately addressed in yang-usage.

[The issue is how to identify elements that are required to be supported.  That is, which elements
can not be deviations (especially for omitted...)]

(Peter Saint-Andre) (was Discuss) No Objection

Comment (2010-06-08)
No email
send info
1. [Addressed in -13.]

2. [Addressed in -13.]

3. [Redacted.]

4. [Explained by authors.]

5. [Addressed in -13.]

6. [Addressed in -13.]

7. [Addressed in -13.]

8. [Explained by authors.]

9. In Section 13, the "unknown-element" referred to under Section 8.3.1 is not defined.

(Robert Sparks) (was Discuss) No Objection

Comment (2010-05-06)
No email
send info

Consider deleting the sentence "A list is similar to a
table where each list entry is a row in the table." The
document defines a list. A table is not defined in this
document. Appealing to a common-sense notion of what a
table might be is not much more useful than just appealing
to the common-sense notion of a list, and the statement
might introduce confusion if the reader makes assumptions
about tables that you didn't intend.

(Sean Turner) (was Discuss) No Objection

(David Harrington) Recuse