Document: draft-ietf-netconf-monitoring-12.txt
Reviewer: Miguel Garcia <miguel.a.garcia@ericsson.com>
Review Date: 07-May-2010
IETF LC End Date: 12-May-2010

Summary: The document is ready for publication as a standards track RFC.

Major issues: none

Minor issues: none

Nits/editorial comments:

- In Section 2, the sentence reads:

   "An overview
   of the specific monitoring data defined in this document which MUST
   be present follows. "

  I don't think it is correct to embed a normative word (MUST) in a 
relative clause. I suggest to split the sentence into two:

    "This document defines an overview of the specific monitoring data. This 
specific monitoring data MUST be always present in the data model, as 
described in the following sections."

- Section 8 (IANA). The registration fails to explicitly mention that the YANG 
Module Names registry is established by draft-ietf-netmod-yang. Without 
this information, it might be difficult to IANA to find that registry, 
because it does not exist yet.

Also, I am not sure if draft-ietf-netmod-yang proposes a namespace prefix 
for registering modules, but I would suggest, if possible, to include 
the term "modules" in the namespace name. This would easily differentiate 
namespaces of modules from other YANG parameters different than modules. In 
your case, this namespace would be:

urn:ietf.params.xml:ns:yang:modules:ietf-netconf-monitoring:rfcXXXX
                            ^^^^^^^^

- One last thing, also related to the module namespace. I noticed the 
presence of "rfcXXXX" (which will have a real number soon) in the namespace. 
Experience tells me that at some point in time, someone may want to create 
an extension to this module, but still use the same space (it would be 
an extension, not a module by itself). Then, you will get that a module 
with "rfcXXXX" includes elements defined in RFCYYYY (the extension), which is 
confusing. Or the extension might be force to create its own namespace, 
which is not desirable either. So, the question here is: do you really need 
the "rfcXXXX" to be part of the namespace name?

- idnits reveals a few unused reference warnings, however most of them are 
false positives. Here is one that is not really used and could be safely 
removed: [RFC5277]. Besides, the URL in this reference points to another 
RFC, so, delete it.