Subject: Re: [Gen-art] Gen-ART review of draft-ietf-netconf-monitoring-12.txt

From: Mark Scott <[email-masked]>
Date: Thu, 3 Jun 2010 12:35:31 -0400

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-masked]>
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