An Architecture for Network Management Using NETCONF and YANG
RFC 6244
Yes
No Objection
Note: This ballot was opened for revision 10 and is now closed.
Lars Eggert No Objection
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/
(Dan Romascanu; former steering group member) Yes
(Jari Arkko; former steering group member) Yes
(Ron Bonica; former steering group member) Yes
(Alexey Melnikov; former steering group member) No Objection
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="http://example.org/netconf/ospf">
<area>
<name>0.0.0.0</name>
<interface>
<name>ge-0/0/0.0</name>
<priority>30</priority>
<vendorx:no-neighbor-down-notification/>
</interface>
</area>
</ospf>
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).
(Gonzalo Camarillo; former steering group member) No Objection
(Peter Saint-Andre; former steering group member) No Objection
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?
(Ralph Droms; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Sean Turner; former steering group member) No Objection
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
(Tim Polk; former steering group member) No Objection
Extremely well written. Thanks. It would be helpful if the security considerations section pointed to [RFC4741], [RFCYANG], and [RFCYANGUSAGE].