Bert,

I believe I have addressed all of your comments on DOCSIS Cable Device MIB -09 in <http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-10.txt>.

I checked the new draft against the online idnits tool, <http://tools.ietf.org/tools/idnits/idnits.pyht>, and got the following feedback:

  Checking nits according to http://www.ietf.org/ID-Checklist.html:
    
    Checking conformance with RFC 3978/3979 boilerplate...

    the boilerplate looks good.
    No nits found.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
    Nothing found here (but these checks do not cover all of
    1id-guidelines.txt yet).

  Miscellaneous warnings:
    None.

    No nits found.


I used the online xml2rfc validator tool, <http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/>, against the XML source, and got the following feedback:


Processing...

Validating document...
Validation succeeded
Performing additional checks...
...done

(I put the XML source for -10 at <http://www.ipcdn.org/drafts/draft-ietf-ipcdn-device-mibv2-10.xml>.)

I used the smilint email service and got the following feedback:

mailbody:2297: [5] {index-exceeds-too-large} warning: index of row `docsDevCpeInetEntry' can exceed OID size limit by 141 subidentifier(s)
mailbody:3003: [5] {group-unref} warning: deprecated group `docsDevNmAccessExtGroup' is not referenced in this module

(These are identical to some of the MIB compiler errors that you noted below.)

My responses to your comments below are marked [RW].

-- Rich

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] 
Sent: Tuesday, August 16, 2005 4:34 PM
To: Woundy, Richard; Jean-Francois Mule
Cc: Ipcdn (E-mail)
Subject: AD review: draft-ietf-ipcdn-device-mibv2-09.txt


In fact I did a review of a somewhat updated document:
     draft-ietf-ipcdn-device-mibv2-10-discussion.txt. 
as per below email exchange between AD and WG chairs.

Note that I did not re-review the decisions we took
(and that are being verified by Jean Francois on the list)
in Paris. The changes resulting from that should also go in.

So here we go:

- ID-Checklist - OK
  no nits found

- References - NOK
  I find:
      !! Missing citation for Normative reference:
      P088 L036:    [OSSI1.1]  CableLabs, "Data-Over-Cable Service Interface

      !! Missing citation for Normative reference:
      P088 L041:    [OSSI2.0]  CableLabs, "Data-Over-Cable Service Interface

   Also:
     !! Missing citation for Normative reference:
     P090 L008:    [RFC3411]  Harrington, D., Presuhn, R., and B. Wijnen, "An
   You have it in the IMPORTS clause.
   Possible solution
   OLD:
           SnmpAdminString
                   FROM SNMP-FRAMEWORK-MIB   -- RFC 3411
   NEW:
           SnmpAdminString
                   FROM SNMP-FRAMEWORK-MIB   -- [RFC3411]
   Also:
     !! Missing citation for Normative reference:
     P089 L036:    [RFC2863]  McCloghrie, K. and F. Kastenholz, "The Interfaces Group
   Possible solution
   OLD:
           InterfaceIndexOrZero
                   FROM IF-MIB               -- RFC 2863
   NEW:
           InterfaceIndexOrZero
                   FROM IF-MIB               -- [RFC2863]
   Also:
     !! Missing citation for Normative reference:
     P089 L008:    [RFC2021]  Waldbusser, S., "Remote Network Monitoring Management
   Similar solution possible
   Also:
     !! Missing citation for Normative reference:
     P090 L035:    [RFC3617]  Lear, E., "Uniform Resource Identifier (URI) Scheme and
   It is listed in he REFERENCE clause of docsDevServerConfigTftpAddress.
   A possible solution:
   OLD:
           REFERENCE
               "RFC 3617, Section 5"
   NEW:
           REFERENCE
               "RFC 3617, Section 5"   -- [RFC3617]

   Another way to solve it is to put some text just before the MIB Module
   that states something aka:

       This MIB Module IMPORTS (normatively) from [RFC2580], [RFCxxxx], etc
       It also has REFERENCE Clauses that refer to [RFCxxxx]. etc

   That way you will also be covered.

[RW] I chose the latter approach, because it is also recommended in section 3.2 (Narrative Sections) of RFC 4181. (Thanks Randy for pointing it out.) Here is the new text:

3.1.1.  IMPORTed MIB Modules and REFERENCE Clauses

   This MIB module IMPORTs definitions normatively from the following
   MIB modules, beyond [RFC2578], [RFC2579] and [RFC2580]: INET-ADDRESS-
   MIB [RFC4001], SNMP-FRAMEWORK-MIB [RFC3411], IF-MIB [RFC2863], RMON2-
   MIB [RFC2021], and DIFFSERV-MIB [RFC3289].

   This MIB module also includes REFERENCE clauses that normatively
   refer to [RFC3617], [RFI1.0], [RFI1.1], [RFI2.0], [OSSI1.1], and
   [OSSI2.0].

[RW end]

   Further, you may want to update refrence to RFC3291 with reference to RFC4001.
   Pls make sure to also correct the citations.

[RW] All references to RFC3291 have been replaced by RFC4001.

- MIB Module contents - SYNTAX check:

   docsDevEvReporting OBJECT-TYPE
           SYNTAX BITS {
               local(0),
               traps(1),
               syslog(2),
               localVolatile(8),
               stdInterface(9)
           }

   causes SMICng to bark:

       E: f(ipcdndevice.mi2), (1196,16) Named bits for BITS must be in
          contiguous positions
   
   I guess you do this to not cause backward compatibility problems?
   Would it be good to do something aka:

    docsDevEvReporting OBJECT-TYPE
           SYNTAX BITS {
               local(0),
               traps(1),
               syslog(2),
               -- the following are extensions to the original set of
               -- labels. The extensions start at octet boundary. So 
               -- for bits 3-7, one MUST set them to zero on send and
               -- one MUST ignore them on receipt.
               localVolatile(8),
               stdInterface(9)
           }

[RW] Done exactly as suggested.

- More module syntax checking:

      W: f(ipcdndevice.mi2), (427,24) Item "docsDevNmAccessCommunity" 
               should have SIZE specified
  I guess theoretically we could specify a size of (0..255) because
  that must have been the intention all along (a community name 
  is limited to that size).
  But since object is deprecated I won't mind to leave as is

[RW] I made no changes.

      W: f(ipcdndevice.mi2), (2428,4) Row "docsDevCpeInetEntry" has
         indexing that may create variables with more than 128 sub-ids

  I see that the InetAddress object DESCRIPTION clause instructs 
  implementors. So no problem.

[RW] I made no changes.

      E: f(ipcdndevice.mi2), (2801,11) Item "diffServDataPathStatus"
         should be IMPORTed
      E: f(ipcdndevice.mi2), (2808,11) Item "diffServClfrStatus" should
         be IMPORTed
      E: f(ipcdndevice.mi2), (2815,11) Item "diffServClfrElementStatus"
         should be IMPORTed
      E: f(ipcdndevice.mi2), (2822,11) Item "diffServMultiFieldClfrAddrType"
         should be IMPORTed
      E: f(ipcdndevice.mi2), (2829,11) Item "diffServMultiFieldClfrSrcAddr"
         should beIMPORTed
      E: f(ipcdndevice.mi2), (2835,11) Item "diffServMultiFieldClfrDstAddr"
         should beIMPORTed
      E: f(ipcdndevice.mi2), (2841,11) Item "diffServAlgDropStatus" should
         be IMPORTed
      E: f(ipcdndevice.mi2), (2848,11) Item "diffServDataPathStorage" should
         be IMPORTed
      E: f(ipcdndevice.mi2), (2854,11) Item "diffServClfrStorage" should
         be IMPORTed
      E: f(ipcdndevice.mi2), (2860,11) Item "diffServClfrElementStorage"
         should be IMPORTed
      E: f(ipcdndevice.mi2), (2866,11) Item "diffServMultiFieldClfrStorage"
         should beIMPORTed
      E: f(ipcdndevice.mi2), (2872,11) Item "diffServActionStorage" should
         be IMPORTed
      E: f(ipcdndevice.mi2), (2879,11) Item "diffServCountActStorage" should
         be IMPORTed
      E: f(ipcdndevice.mi2), (2885,11) Item "diffServAlgDropStorage" should
         be IMPORTed
      E: f(ipcdndevice.mi2), (2891,11) Item "diffServAlgDropType" should
         be IMPORTed

   Most of those were also imported in the subscriber MIB, so it seems to me
   we have dealth with this before in that other MIB module.

[RW] Done. All of these objects are now IMPORTed.

      W: f(ipcdndevice.mi2), (3140,4) OBJECT-GROUP "docsDevNmAccessExtGroup"
         is not used in a MODULE-COMPLIANCE in current module

   I am kind of surprised to see this Group at all.
   It is deprecated, and it contains one object docsDevNmAccessTrapVersion
   which is also deprecated. The object nor the Group existed in RFC 2669
   (which this doc obsoletes). So why are we having this deprecated
   object and object group at all? 
   OK, OK, I see in DESCRIPTION clause why it was added.
   Mmm... Not exactly right... maybe I can live with it.
   But possibly this would be added to some (new) deprecated MODULE-COMPLIANCE.
   I guess it could even be added as optional group to the
   deprecated docsDevBasicCompliance, since it does not make old claims
   for that MODULE-COMPLIANCE invalid.... (borderline I think)
   So maybe accept the warning that the group is not used.

[RW] I made no changes.

Nits:
-   "IPSec" (I  know it was incorrect in the mib security template too, I just fixed it)
    should be spelled "IPsec"

[RW] Done.

Bert

 -----Original Message-----
From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com]
Sent: Wednesday, August 10, 2005 16:29
To: Wijnen, Bert (Bert); Jean-Francois Mule
Cc: Woundy, Richard
Subject: RE: IPCDN wg - meeting minutes and dates for 3 AD reviews


OK, that would be terrific, thanks!

-- Rich
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] 
Sent: Wednesday, August 10, 2005 10:07 AM
To: Woundy, Richard; Wijnen, Bert (Bert); Jean-Francois Mule
Subject: RE: IPCDN wg - meeting minutes and dates for 3 AD reviews


So hwo about me reviewing 
   http://www.ipcdn.org/drafts/draft-ietf-ipcdn-device-mibv2-10-discussion.txt. 
and assuming you will fix the 4 issues we discussed at the WG session last week. If I indeed do keep my promise (I have a bda track record) then by the 15th you can incorporate all comments in to the next official revision.

Bert
-----Original Message-----
From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com]
Sent: Wednesday, August 10, 2005 15:24
To: Wijnen, Bert (Bert); Jean-Francois Mule
Cc: Woundy, Richard
Subject: RE: IPCDN wg - meeting minutes and dates for 3 AD reviews


Bert, Jean-Francois,

About this one review:

3.1/ DOCSIS Cable Device MIB version 2
     draft-ietf-ipcdn-device-mibv2-09.txt
     Editors: Kevin Marez & Rich Woundy http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-09.txt
 
# AD review by Bert due by August 15
As you know from last week's working group meeting, this draft is undergoing editing to address Randy's comments.

There are three versions that could undergo AD review:
The officially posted draft-ietf-ipcdn-device-mibv2-09 version. Randy sent a number of emails to the IPCDN mailing list with numerous MIB doctor comments against this version. 
I generated an interim version, http://www.ipcdn.org/drafts/draft-ietf-ipcdn-device-mibv2-10-discussion.txt. This is the draft version that was the basis of the review in the working group (e.g. the "four issues"). 
I would like to submit a real draft-ietf-ipcdn-device-mibv2-10 based on the working group meeting discussions, but I cannot finish this before August 15 at the earliest. This would be incompatible with your review being due on August 15. Bert, if you choose to review the posted -09 version, or the interim -10 "discussion", then I will wait for your review comments before I post the real -10 version.

If you want to review a posted -10 version, then I need to know soon, so that I hurry up on incorporating the working group comments (and Randy's email comments as well). Then we probably need to push back your review date a week or two.

For me, the ideal choice would be for you to review the interim version http://www.ipcdn.org/drafts/draft-ietf-ipcdn-device-mibv2-10-discussion.txt, and then I would incorporate your AD review comments into a posted -10 version.

-- Rich
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] 
Sent: Tuesday, August 09, 2005 5:21 AM
To: Jean-Francois Mule; bwijnen@lucent.com
Cc: Woundy, Richard
Subject: RE: IPCDN wg - meeting minutes and dates for 3 AD reviews


looks fine to me.

Bert
-----Original Message-----
From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]
Sent: Monday, August 08, 2005 18:17
To: bwijnen@lucent.com
Cc: Richard Woundy @ Comcast
Subject: IPCDN wg - meeting minutes and dates for 3 AD reviews


Bert,
 
   I'm finishing up the meeting minutes from ipcdn and I just want to make sure we have realistic dates for AD review. I snipped most of the text from the draft minutes except for AD review lines.
 
   Here's a recap, let me know what to change or if this still looks ok. Just want to make sure we're in sync.
 
Thanks,
Jean-François
 
 
3.1/ DOCSIS Cable Device MIB version 2
     draft-ietf-ipcdn-device-mibv2-09.txt
     Editors: Kevin Marez & Rich Woundy http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-09.txt
 
# AD review by Bert due by August 15
 
 
3.2/ RF MIB v2
     draft-ietf-ipcdn-docs-rfmibv2-13.txt
     Editor: Eduardo Cardona http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-13.txt
 
Not discussed due to time limit.
# AD review by Bert due by August 15
 
3.3/ IPCablecom/PacketCable MTA MIB
     draft-ietf-ipcdn-pktc-mtamib-06.txt
http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-mtamib-06.txt
Not discussed due to time limit.
# AD review by Bert due by August 15
 

_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn