I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-netconf-monitoring-12.txt
Reviewer: Miguel Garcia <[email protected]>
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.
/Miguel
--
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
