Miguel, Here is an update to some of your specific questions/comments below:
1. Yang usage guidelines (draft-ietf-netmod-yang-usage-xx) no longer recommend 'draft-x' and 'rfcxxxx' in the namespace assignments. The namespace and IANA request in this draft has been updated accordingly. 2. Inclusion of 'modules' in yang module namespace was discussed and the decision was not to include. Rationale for this decision included: - the base URI is already in use - Yang already differentiates module namespaces from the Yang XML namespace as described in sec 5.3.1 of draft-ietf-netmod-yang-12. The latter uses a revision number in the namespace which would result in an invalid module name (ie. urn:ietf:params:xml:ns:yang:1) whereas Yang uses its own versioning mechanism. A new version of the draft (v14) which addresses your other comments and others from WGLC has been posted. Thank you again for your comments. cheers, Mark -----Original Message----- From: Mark Scott Sent: May-07-10 4:40 PM To: Miguel Garcia A; Martin Bjorklund; Mehmet Ersue; Dan Romascanu; Bert Wijnen Cc: General Area Review Team Subject: RE: Gen-ART review of draft-ietf-netconf-monitoring-12.txt Miguel, Thank you for your comments. We will update the draft to address your comments along with some others received. On the namespace question: Yang usage guidelines currently define this use of 'DRAFT-x' or 'rfcXXXX' in the namespace. However a recent discussion on netmod ML suggests this guideline will be modified. I will confirm the current guideline with netmod, raise your suggestion to include 'modules' and let you know the outcome. Mark -----Original Message----- From: Miguel Garcia A Sent: May-07-10 7:32 AM To: Mark Scott; Martin Bjorklund; Mehmet Ersue; Dan Romascanu; Bert Wijnen Cc: General Area Review Team Subject: Gen-ART review of draft-ietf-netconf-monitoring-12.txt 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
