An Architecture for Network Management Using NETCONF and YANG
draft-ietf-netmod-arch-10

[Ballot comment]
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

[Ballot comment]
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  element is then placed in the
  vendorx namespace:

     

       
          0.0.0.0

         
            ge-0/0/0.0
            30
           
         

       
     

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

[Ballot comment]
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?

[Ballot comment]
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/

Document write-up for draft-ietf-netmod-arch-07.txt

(1.a)  Who is the Document Shepherd for this document?

        David Partain, NETMOD WG co-chair

        Has the Document Shepherd personally reviewed this version
        of the document and, in particular, does he or she believe
        this version is ready for forwarding to the IESG for
        publication?

        Yes, I have reviewed this document and consider it
        ready for IESG review and publication as an Informational
        RFC.

(1.b)  Has the document had adequate review both from key WG members
        and from key non-WG members?

        Yes, we have had extensive review of the document by
        those involved in the working group and some in the wider
        O&M community.

        Does the Document Shepherd have any concerns about the
        depth or breadth of the reviews that have been performed?

        No, I do not.

(1.c)  Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization, or XML?

        I believe further review within the IETF O&M community
        would be helpful (and expect this to happen as a result
        of the IETF Last Call).

(1.d)  Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of?

        No.

        Has an IPR disclosure related to this document been filed?

        No IPR disclosures have been filed against this document.

(1.e)  How solid is the WG consensus behind this document?  Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

        I believe this document represents strong consensus of the
        working group after intense work over the last 18 months.

(1.f)  Has anyone threatened an appeal or otherwise indicated extreme
        discontent?

        No.

(1.g)  Has the Document Shepherd personally verified that the
        document satisfies all ID nits?  (See
        http://www.ietf.org/ID-Checklist.html and
        http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are
        not enough; this check needs to be thorough.

        Those issues pointed out by the tool are:

        1. The document has a disclaimer for pre-RFC5378 work,
        but was first submitted on or after 10 November 2008.
        Does it really need the disclaimer?

        Shepherd comment: While not necessary, it isn't a problem.

        2.  The document date (June 23, 2010) is 5 days in the
        past.  Is this intentional?

        Shepherd comment: No issue

        3. "Missing Reference: 'C' is mentioned on line 640, but
        not defined" and "Missing Reference: 'S' is mentioned on
        line 635, but not defined"

        Shepherd comment: No issue since neither of these are
        references

        4. "Outdated reference: A later version (-06) exists of
        draft-ietf-netmod-dsdl-map-05" and "Outdated reference: A
        later version (-07) exists of
        draft-ietf-netmod-yang-usage-05"

        Shepherd comment: These need to be corrected by the RFC
        Editor nonetheless when dealing with final edits.  If
        needed, the editor can easily provide a new revision
        correcting only this.

        Has the document met all formal review criteria it needs
        to, such as the MIB Doctor, media type, and URI type
        reviews?

        Yes.

(1.h)  Has the document split its references into normative and
        informative?
       
        No, there are only normative references.

        Are there normative references to documents that are not
        ready for advancement or are otherwise in an unclear
        state?

        The companion NETMOD documents (draft-ietf-netmod-yang,
        draft-ietf-netmod-yang-types, draft-ietf-netmod-dsdl-map,
        and draft-ietf-netmod-yang-usage) are all included but
        will be going to advancement in parallel.

        If such normative references exist, what is the strategy
        for their completion?

        They are being advanced in parallel.
       
        Are there normative references that are downward
        references, as described in [RFC3967]?

        No.

(1.i)  Has the Document Shepherd verified that the document's IANA
        Considerations section exists and is consistent with the body
        of the document?
       
        Yes.  There are no actions for IANA.

        If the document specifies protocol extensions, are
        reservations requested in appropriate IANA registries?
        Are the IANA registries clearly identified?
       
        No such extensions are defined.
       
        If the document creates a new registry, does it define
        the proposed initial contents of the registry and an
        allocation procedure for future registrations?

        No new registry is defined.
       
        Does it suggest a reasonable name for the new registry?

        No new registry is defined.

(1.j)  Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

        There are no such sections.

(1.k)  The IESG approval announcement includes a Document
        Announcement Write-Up.  Please provide such a Document
        Announcement Write-Up.  Recent examples can be found in the
        "Action" announcements for approved documents.  The approval
        announcement contains the following sections:

        Technical Summary

          NETCONF gives access to native capabilities of the
          devices within a network, defining methods for
          manipulating configuration databases, retrieving
          operational data, and invoking specific operations.
          YANG provides the means to define the content carried
          via NETCONF, both data and operations.  Using both
          technologies, standard modules can be defined to give
          interoperability and commonality to devices, while
          still allowing devices to express their unique
          capabilities.  This document describes how NETCONF and
          YANG help build network management applications that
          meet the needs of network operators.

        Working Group Summary

          Consensus was reached among all interested parties before
          requesting the publication of this document.

        Document Quality

          This document has been worked through very carefully
          by all key players in the working group.