Skip to main content

An Architecture for Network Management Using NETCONF and YANG
RFC 6244

Yes

(Dan Romascanu)
(Jari Arkko)
(Ron Bonica)

No Objection

(Gonzalo Camarillo)
(Ralph Droms)
(Robert Sparks)
(Russ Housley)

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

Lars Eggert No Objection

Comment (2010-09-22)
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

Yes ()

                            

(Jari Arkko; former steering group member) Yes

Yes ()

                            

(Ron Bonica; former steering group member) Yes

Yes ()

                            

(Alexey Melnikov; former steering group member) No Objection

No Objection (2010-09-23)
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

No Objection ()

                            

(Peter Saint-Andre; former steering group member) No Objection

No Objection (2010-09-22)
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

No Objection ()

                            

(Robert Sparks; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) No Objection

No Objection ()

                            

(Sean Turner; former steering group member) No Objection

No Objection (2010-09-23)
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

No Objection (2010-09-23)
Extremely well written.  Thanks.

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