An Architecture for Network Management Using NETCONF and YANG
RFC 6244

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

(Jari Arkko) Yes

(Ron Bonica) Yes

(Dan Romascanu) Yes

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Lars Eggert) No Objection

Comment (2010-09-22 for -)
No email
send info
Section 1.1., paragraph 0:
>  1.  Introduction
> 1.1.  Origins of NETCONF and YANG

  Section 1 only consists of Section 1.1 - why not move the content of
  Section 1.1 into Section 1? (Also, I wonder if this history was better
  placed in an appendix; just start with Section 2 directly.)

Section 1.1., paragraph 9:
>    hierarchies defined in other modules, seemlessly adding data at

  Nit: s/seemlessly/seamlessly/

Section 2.2.3., paragraph 12:
>    hierarchy for that area, complete with any augmentated data.

  Nit: s/augmentated/augmented/

(Russ Housley) No Objection

Alexey Melnikov No Objection

Comment (2010-09-23 for -)
No email
send info
This is a fine document, but I think it can be improved by inserting various Informative references, in particular:

2.2.1.  Constraints

The reference to XPath is missing.

2.2.3.  Extensibility Model

   The <no-neighbor-down-notification> element is then placed in the
   vendorx namespace:

       <ospf xmlns="">




I think the example is incomplete, as it is missing the "vendorx" namespace definition.

3.2.  Addressing Operator Requirements

   o  Full coverage: YANG modules can be defined that give full coverage
      to all the native abilities of the device.  Giving this access
      avoids the need to resort to the command line interface (CLI)
      using tools such as Expect.

I happen to know what Expect is, but maybe this needs an Informative Reference?

   o  Internationalization: YANG uses UTF-8 encoded unicode characters.

This needs an Informative reference to RFC that defines UTF-8.

 o  Security: NETCONF runs over transport protocols secured by SSH or
      TLS, allowing secure communications and authentication using well-
      trusted technology.  The secure transport can use existing key and
      credential management infrastructure, reducing deployment costs.

SSH and TLS need Informative references (actually they were referenced earlier in the document).

(Tim Polk) No Objection

Comment (2010-09-23 for -)
No email
send info
Extremely well written.  Thanks.

It would be helpful if the security considerations section pointed to [RFC4741], [RFCYANG], and [RFCYANGUSAGE].

(Peter Saint-Andre) No Objection

Comment (2010-09-22 for -)
No email
send info
1. I'm happy to see that we are "allowing devices to express their unique capabilities". :)

2. Section 1.1 states:

   Many of the
   observations give insight into the problems operators were having
   with existing network management solutions, such as the lack of full
   coverage of device capabilities and the ability to distinguish
   between configuration data and other types of data.

I think you mean "inability", not "ability".

3. Please add a reference to the XPath spec in Section 2.2.1.

4. Section 3.2 verges on marketing. Who is the audience for this text?

5. Section 4.3.1 states:

   It is necessary to make a clear distinction between
   configuration data, data that describes operational state
   and statistics.

Are there three kinds of data here or only two? If three, I think this wording is better:

   It is necessary to make clear distinctions among three
   different kinds of data: configuration data, operational
   state data, and statistical data.

However, Section 4.3.1 goes on to state:

   NETCONF does not follow the distinction formulated by the operators
   between configuration data, operational state data, and statistical
   data, since it considers state data to include both statistics and
   operational state data.

Which is it? Are the relevant distinctions supported or not? If NETCONF treats both operational state data and statistical data as state data, is that a problem?

6. Section 5 claims that "this document discusses an architecture for network management"; however, instead the document seems to provide an overview of NETCONF and YANG, along with guidelines for applying those technologies to the solution of common network management problems. Does the title need to be changed so that readers are not disappointed?

(Robert Sparks) No Objection

(Sean Turner) No Objection

Comment (2010-09-23 for -)
No email
send info
1) Expand NETCONF and YANG in abstract and XSD, DSDL, NG, 

2) Sec 3.2: Is "text-friendly" and "human friendly syntax" the same thing?

3) Sec 4.1: r/it's/its