Radio Frequency (RF) Interface Management Information Base for Data over Cable Service Interface Specifications (DOCSIS) 2.0 Compliant RF Interfaces
draft-ietf-ipcdn-docs-rfmibv2-14

[Ballot comment]
The Abstract says:

Please see section 6
  for a description of the changes from RFC 2670.


This appears to be Section 5.3, in the current numbering.

[Ballot comment]
The Abstract says:

Please see section 6
  for a description of the changes from RFC 2670.


This appears to be Section 5, in the current numbering.

PROTO write-up from WG chair:

-----Original Message-----
From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com]
Sent: Tuesday, January 31, 2006 16:26
To: Wijnen, Bert (Bert); iesg-secretary@ietf.org
Cc: Eduardo Cardona; Ipcdn (E-mail)
Subject: Request for publication and PROTO writeup for
draft-ietf-ipcdn-docs-rfmibv2-14.txt on the standards track


Bert and all,

This note is the request for publication and proto write-up for the IPCDN DOCSIS RFIv2 MIB internet-draft, draft-ietf-ipcdn-docs-rfmibv2-14.txt, as a Proposed Standard.

If you have any questions or concerns with the above, please send email to the IPCDN list.

Thank you Eugene for your continued efforts and big thanks to Randy, Bert et al. for the detailed and constructive MIB doctor and expert reviews.

Richard Woundy
IPCDN Co-Chair


The PROTO process (cf. draft-ietf-proto-wgchair-doc-shepherding-05.txt) is being used for the IPCDN DOCSIS RFIv2 MIB internet-draft.

Here is the proposed PROTO writeup for:

Radio Frequency (RF) Interface Management Information Base for DOCSIS 2.0 compliant RF interfaces
(draft-ietf-ipcdn-docs-rfmibv2-14.txt)

http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-14.txt


Requested Publication Status: Proposed Standard
Obsoletes: RFC 2670
PROTO shepherd: Richard Woundy (IPCDN WG Co-Chair)
------------------------------------------------------------------------

  1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this ID is ready
        to forward to the IESG for publication?

Yes.

Both IPCDN co-chairs reviewed this version of the ID. Based on the WG comments, MIB doctors & AD review comments, we believe the ID is ready for publication.

  1.b) Has the document had adequate review from both key WG members
        and key non-WG members?

Yes, there have been reviews from both subject-matter experts that are WG members and MIB doctors who provided valuable comments to improve the quality of the MIB module.

        Do you have any concerns about the
        depth or breadth of the reviews that have been performed?

No, given the time this ID has been in existence and the number of revisions due to comments.

  1.c) Do you have concerns that the document needs more review from a
        particular (broader) perspective (e.g., security, operational
        complexity, someone familiar with AAA, etc.)?

No.

  1.d) Do you have any specific concerns/issues with this document that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of the
        document, or have concerns whether there really is a need for
        it.  In any event, if your issues have been discussed in the WG
        and the WG has indicated it that it still wishes to advance the
        document, detail those concerns in the write-up.

No. The internet-draft was produced prior to the IETF 64 meeting, based on comments from the AD review. No further issues were raised on this internet-draft at the IETF 64 meeting, nor subsequently on the WG mailing list. There are no other concerns from the PROTO shepherd.

  1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

This document represents the WG consensus as a whole: the WG as a whole understands and agrees with it.

  1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarise the areas of conflict in
        separate email to the Responsible Area Director.

No. An explicit request for intent to appeal was made on the list on January 10 2006.

  1.g) Have the chairs verified that the document adheres to all of the
        ID nits? (see http://www.ietf.org/ID-Checklist.html).

There are no ID nits issues per the automated ID nits check (version 1.82) at:


  1.h) Is the document split into normative and informative references?

Yes.

        Are there normative references to IDs, where the IDs are not
        also ready for advancement or are otherwise in an unclear state?
        (note here that the RFC editor will not publish an RFC with
        normative references to IDs, it will delay publication until all
        such IDs are also ready for publication as RFCs.)

No.

  1.i) For Standards Track and BCP documents, the IESG approval
        announcement includes a write-up section with the following
        sections:

        *    Technical Summary

        *    Working Group Summary

        *    Protocol Quality

  1.j) Please provide such a write-up.  Recent examples can be found in
        the "protocol action" announcements for approved documents.

--- Technical Summary

  This document is a revision of the standards track RFC 2670, and
  defines a portion of the Management Information Base (MIB) for
  use with network management protocols in the Internet community.
  In particular, it defines a set of managed objects for SNMP-based
  management of the Radio Frequency (RF) interfaces for systems
  compliant with the Data Over Cable Service Interface Specifications
  (DOCSIS).

--- Working Group Summary

  The Working Group has consensus to publish this document as a
  Proposed Standard.

--- Protocol Quality
 
  The MIB module has been reviewed by Randy Presuhn. The overall quality
  with respect to DOCSIS functionality has been reviewed by many
  IPCDN technical experts. This document has been reviewed for the IESG by
  Bert Wijnen.

New revision expected. In fact AD is already doing MIB doctor review and an early copy of it. And discussing it with authors and WG chairs. Needs to go to WG list soon.

AD review of rev 13 posted to authors/editors and WG list.

Waiting for WG chairs/authors to decide if they want to do one
more revision first or if they want to haev IETF Last Call now.

-----Original Message-----
From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org]On Behalf Of
Wijnen, Bert (Bert)
Sent: Wednesday, August 17, 2005 16:51
To: Eduardo Cardona (E-mail); david.raftus@terayon.com
Cc: Ipcdn (E-mail)
Subject: [ipcdn] AD re-review: draft-ietf-ipcdn-docs-rfmibv2-13.txt


Summary:
- No showstoppers as far as I can see now.
- We can do an IETF Last Call now and you consider the below
  as initial IETF Last Call comments. So after IETF Last Call
  completes you would address the below plus whatever comes
  up from IETF Last Call and only after that will I put it
  on IESG agenda.
- Or you can go do a quick new rev to address the below.
  If you can do so in the next few days, then I prefer that.

Here are my review comments:

- In the MODULE-COMPLIANCE statement(s) I see

  OBJECT  docsIfUpChannelStatus
        SYNTAX      RowStatus {active(1), notReady(3)}
        WRITE-SYNTAX RowStatus {createAndWait(5), destroy(6)}

  That seems weird. I think that active(1) also needs to
  be included in the WRITE-SYNTAX, otherwise, when somebody
  does a createAndWait, and that results in a notRady, how
  are you then ever going to get the row in active(1) if you
  cannot write that value? But then I see in the DESCRIPTION
  clause of docsIfUpChannelStatus that one should not (never?)
  set a row to active.
  I do see that notInservice is possible in the description
  clause. So I am confused.
  Are you also aware that agents may remove non-active rows
  after some implementation-specific time? See RFC2579 for
  details.
  Just want to be sure you have specified things as intended.
  I find them strange.... but who is me.
  It has to do with the "complexity" of your cloning mechanism
  that both Randy and I have brought up.
  I do not have a quick alternative available. Would take
  serious time I guess, cause I would need to better understand
  your requirements and constraints first.

  I guess if the WG is OK with whatyou have then we can probably
  leave it. The WG members (at least some of them I assume) will
  have to implement it!

- SYNTAX check with SMICng:

    W: f(rfmibv2.mi2), (1488,21) Item "docsIfCmStatusCode" should
        have SIZE specified

  I understand this was already the case in RFC2670.
  If we can add a size such that a compliant implementation of RFC2670
  is still compliant, then I suggest we do so. If not, then leave as is.
  I see that you had a SIZE (0..16) in revision 12, and then Randy
  commented that that did not fit with the DESCRIPTION clause:
        DESCRIPTION
            "Status code for this Cable Modem as defined in the
            OSSI Specification.  The status code consists
            of a single character indicating error groups, followed
            by a two- or three-digit number indicating the status
            condition, followed by a decimal."
  Which is true. In fact, I am not sure what the content is.
  Is it
    - either 3 octets (1 for error group, 2 for a number, no decimal)
      or 4 octets (1 for error group, 2 for a number, 1 decimal)
    - either 3 octets (1 for error group, 1 for number, 1 decimal)
      or 4 octets (1 for error group, 2 for a number, 1 decimal)
    - either 4 octets (1 for error group, 2 for number, 1 decimal)
      or 5 octets (1 for error group, 3 for a number, 1 decimal)
  See why we wonder??
  And in any case, the way I read it, MIN length would be 3 or 4
  and the MAX length 4 or 5, depending on the above interpretations.

  I see that Eduardo posted a response, and no-one reacted (at least
  I cannot quickly find it). So ??


    W: f(rfmibv2.mi2), (5036,4) OBJECT-GROUP "docsIfObsoleteGroup"
        is not used in a MODULE-COMPLIANCE in current module

  I understand this was already the case in RFC2670.
  So I am OK to leave it as is. I had suggested (in y review of Dec 2004)
      Might be good to add a ASN.1 comment about it so we know
      it has existed for a long time.
  Seems that was not done. Eduardo responded:
          >> will add after :
          -- conditionally mandatory group
          GROUP docsIfCmtsGroup

          The group reference,

          -- obsolete group
          -- RFC 2670 already had a obsolete group, even though RFC2670
          -- was the first version of this MIB Module

          GROUP docsIfObsoleteGroup
              DESCRIPTION
                  "This group contains obsolete objects."
  But I cannot fond any of that addition?
  Am I missing something?

- There was discussion/question
  Bert commented:
    5. ./DOCS-IF-MIB:2400 [3] {range-added} size `(0..512)' added to
      type used in `docsIfCmtsCmStatusEqualizationData'

      Probably OK. Can you add some text to explain why this is OK?
  Eduardo answered:
      >>(*)
      I do not have other explanation than "enough" room, probably
      for future enhancements (?)
      Current DOCSIS MAC may constrain to 256 bytes total the
      equalizer data maps.

      Does anyone recall the reasons for the number selection?

  So where are we with this?

  Same question for:
        ./DOCS-IF-MIB:1167 [3] {range-added} size `(0..512)' added to
          type used in `docsIfSigQEqualizationData'

- For object docsIfCmtsQosProfilePermissions I still see in
  the DESCRIPTION clause:
            Either createByManagement(0) or updateByManagement(2)
            MUST be set when writing to this object.
  while I see
        SYNTAX      BITS {
            createByManagement(0),
            updateByManagement(1),
            createByModems(2)
  So that is inconsistent (still).
  I think you mean
            Either createByManagement(0) or updateByManagement(1)
 
- Eduardo changed (after my questioning why we have a deprecated value
  added):
  docsIfCmtsCmStatusValue OBJECT-TYPE
        SYNTAX      INTEGER {
            other(1),
            ranging(2),
            rangingAborted(3),
            rangingComplete(4),
            ipComplete(5),
            registrationComplete(6),
            accessDenied(7),
            operational(8),  -- deprecated
            registeredBPIInitializing(9)
        }
  to
  docsIfCmtsCmStatusValue OBJECT-TYPE
        SYNTAX      INTEGER {
            other(1),
            ranging(2),
            rangingAborted(3),
            rangingComplete(4),
            ipComplete(5),
            registrationComplete(6),
            accessDenied(7),
            -- value 8 not used
            registeredBPIInitializing(9)
        }
  Not sure the new thing is better. I much more wanted to see
  an explanation as to why the deprecated value was added.
  If some implementations do use it, then better to add it
  in deprecated form, so we understand that it may indeed
  be encountered in real life and if so waht it meant.
  At same time we see it is depreacted, and we have an
  explantion as to why (and best to have it in the
  DESCRIPTION clause). See... it is all not only about
  being pure, but also about representaing realistic
  behaviour and explaining to the readers of this doc
  or MIB module what exactly to expect and why.
 
- There was discussion on list:
  Randy:
    docsIfUpChannelScdmaActiveCodes - since the primes can never be set and
    can never be returned, they should be excluded in the SYNTAX
  Eduardo:
  (*)
    >> I am not sure if this is appropiate or will breaks the regular
      applications,
      To exclude prime numbers 67,71,73,79,83,89,97,101,103,107,109,
      113,127,the SYNTAX clause will be
          SYNTAX    Unsigned32
          (0|64..66|68..70|72|74..78|80..82|84..88|90..96|98..100|102
          |104..106|108|110..112|114..126|128)
      Do you prefer this?
      How do you break this for the 72 columns ID text file format?
  Bert:
  I tried this and broke the line after the 102, and both smicng and
  smilint are happy. So it can be done and it would make the valid
  values machine readable instead of just being in the DESCRIPTION
  clause.

- Reference/citation problem:
    !! Missing citation for Normative reference:
    P139 L016:    [IANA]    Internet Assigned Numbers Authority, "Data-Over-Cable
  An easy fix would be:
  OLD:
        IANAifType
                FROM IANAifType-MIB;
  NEW:
        IANAifType
                FROM IANAifType-MIB;  -- [IANA]

  If we're going to do a new revision, then pls update all citations
  and reference to RFC3291 into one for RFC4001.

NITS/Editorial

- From an earlier review (6 Jan 2005) by Randy and not yet
  addressed:
    5) EDITORIAL: "reinit" -> "reinitialization"
    6) EDITORIAL: "ie" -> "i.e.", or better "that is"
    12) EDITORIAL: "head-end" or "headend"?  pick one,
        preferably the former.
    13) EDITORIAL: there are some strange capitalizations:
        "Lineup" in 2.11
        "Addressed" in 3.2  (although that is fixed now,
                              now it is in 3.1.4)
        I checked the above 2. Not the next ones. But did you?
        "Downstream" in 3.2.5.1 and elsewhere
        "Cable" in 3.2.5.1.2
        "Unicast" on page 12 & 14 & more
        "Multicast" on page 12 & 14 & more
        "Broadcast" on page 12 & 14 & more
        "Upstream" in 3.2.5.2.1
        "Contributions" in 5
    15) EDITORIAL: "empty string" would be more precise as
        "zero length string"
        (This could potentially be technical.)

  I really wonder why the editors do not take such comments
  of a carefull review into account when they do a new rev.


For completeness, if you do a new rev:

$ idnits draft-ietf-ipcdn-docs-rfmibv2-13.txt
idnits 1.74

draft-ietf-ipcdn-docs-rfmibv2-13.txt:


  Checking nits according to http://www.ietf.org/ID-Checklist.html:
    Checking conformance with RFC 3978/3979 boilerplate...
  * The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
    Acknowledgement.
    (The document uses RFC 3667 boilerplate or RFC 3978-like
    boilerplate instead of verbatim RFC 3978 boilerplate.  After 6 May 2005,
    submission of drafts without verbatim RFC 3978 boilerplate is not
    accepted.)

  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.

    Run idnits with the --verbose option for more detailed information.

Bert

State Change Notice email list have been change to Richard_Woundy@cable.comcast.com, RWoundy@broadband.att.com, jf.mule@cablelabs.com, Randy_Presuhn@mindspring.com, david.raftus@terayon.com, e.cardona@CableLabs.com from Richard_Woundy@cable.comcast.com, RWoundy@broadband.att.com, jf.mule@cablelabs.com

AD review posted to WG mailing list

-----Original Message-----
From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org]On Behalf Of
Wijnen, Bert (Bert)
Sent: Wednesday, December 29, 2004 17:30
To: Jean-Francois Mule; Richard Woundy @ Comcast;
david.raftus@terayon.com; Eduardo Cardona
Cc: Ipcdn (E-mail)
Subject: RE: [ipcdn] request for ID publication: DOCSIS RFIv2 mib -
2670b is


Sorry that it took a (long) while to do AD review.

Here are my comments:

- my findref tool (prelimenary, borrowed from RFC-Editor) says:

  !! Missing Reference for citation: [RFC2670]
    P122 L050:      interfaces" [RFC2670].

  !! Missing citation for Normative reference:
    P123 L048:    [RFC3291] Daniele, M., Haberman, B., Routhier, S., Schoenwaelder,

- my idnits tool, available from:
          http://ietf.levkowetz.com/tools/idnits/
  tells me:

  $ idnits draft-ietf-ipcdn-docs-rfmibv2-12.txt
  idnits 1.58

  draft-ietf-ipcdn-docs-rfmibv2-12.txt:

  Checking nits according to http://www.ietf.org/ID-Checklist.html :

  * The document seems to lack an IANA Considerations section.
    Checking conformance with RFC 3667/3668 boilerplate...
  * The document seems to lack an RFC 3668 Section 5, para 1 IPR Disclosure
    Acknowledgement --
    however, there's a paragraph with a matching beginning. Boilerplate error?
  * The document seems to lack an RFC 3668 Section 5, para 2 IPR Disclosure
    Acknowledgement.
  * There are 2 instances of lines with non-ascii characters in the document.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt :

    Nothing found here (but these checks does not cover all of
    1id-guidelines.txt yet).

  Miscellaneous warnings:

  - Line 501 has weird spacing: '...astPkts  inter...'
  - Line 561 has weird spacing: '...astPkts  inte...'
  - Line 772 has weird spacing: '...astPkts  inter...'
  - Line 843 has weird spacing: '...astPkts  inte...'
  - Line 919 has weird spacing: '...astPkts  inte...'
  - (1 more instance...)

    Run idnits with the --verbose option for more detailed information.
 
  The missing IANA considerations is not good.
  Section should say that there are no (new) IANA actions to be performed

  one of non-ascii characters are in the MIB MODULE. not good for compilation
    C:?wijnensmicngwork>smicmfm ipcdnDocsIfMIB.mi2
    E: f(ipcdnDocsIfMIB.mi2), (36,41) Syntax error
    ** 1 error and 0 warnings in parsing

  line 36 is the line
          LAST-UPDATED    "200411221700Z" xFB- November 22, 2004

  after fixing that, compile goes reasonably. except for

    W: f(rfmibv2.mi2), (4948,1) OBJECT-GROUP "docsIfObsoleteGroup" is not used
      in a MODULE-COMPLIANCE in current module

  now that was already the case in RFC2670. Strange but such is life.
  Might be good to add a ASN.1 comment about it so we know it has existed
  for a long time.

- Next I did run smidiff:

  $ smidiff -s -l 6 -m -inamelength-32 ..ietfDOCS-IF-MIB ./DOCS-IF-MIB
      >docs-if-mib-diff.txt

  I have attached the doc-if-mib-diff.txt file for your perusal... pls check
  in detail to make sure that all the changes are indeed intentional.

  What I find serious issues in there (and those that I checked in
  more detail) is the following:

1. You have removed and then re-added docsIfObsoleteGroup
  That was kind of OK if the OID that you used woul have been the same,
  but it changed from the last subid of 4 to 5.
  This is forbidden accoring to SMI rules. Why was this done?

2. ./DOCS-IF-MIB:2988 [3] {range-changed} range of type used in
  `docsIfCmtsModPreambleLen' changed from `(0..1024)' to `(0..1536)'

  That is acceptable, but since this is a read-create object, you must
  change the old MODULE-COMPLIANCE statement (i.e. the one you deprecated)
  to describe this OBJECT-TYPE with a limited range. For example:

    OBJECT  docsIfCmtsModPreambleLen
        SYNTAX Integer32 (0..1024)
        DESCRIPTION
            "The range of the values for this MODUL-COMPLIANCE is 0..1024."

  without it, old implementations claiming docsIfBasicCompliance would
  all of a sudden have to support the new values 1025..1536 as well.

3. ./DOCS-IF-MIB:3018 [3] {range-changed} range of type used in
  `docsIfCmtsModFECErrorCorrection' changed from `(0..10)' to `(0..16)'

  That is acceptable, but since this is a read-create object, you must
  change the old MODULE-COMPLIANCE statement (i.e. the one you deprecated)
  to describe this OBJECT-TYPE with a limited range. For example:

    OBJECT  docsIfCmtsModFECErrorCorrection
        SYNTAX Integer32 (0..10)
        DESCRIPTION
            "The range of the values for this MODUL-COMPLIANCE is 0..10."

  without it, old implementations claiming docsIfBasicCompliance would
  all of a sudden have to support the new values 11..16 as well.

4. I see that docsIfCmtsModType has a number of values/enumerations added.
  The old MODULE-COMPLIANCE statement has not changed, sofar sogood
  But the new MODULE-COMPLIANCE does not list this object. So can all values
  (including other(1)) be written ???

5. ./DOCS-IF-MIB:2400 [3] {range-added} size `(0..512)' added to type used
    in `docsIfCmtsCmStatusEqualizationData'

  Probably OK. Can you add some text to explain why this is OK?

6. ./DOCS-IF-MIB:2414 [5] {named-number-added} warning: named number `operational'
  added to type used in `docsIfCmtsCmStatusValue'
  ./DOCS-IF-MIB:2414 [5] {named-number-added} warning: named number
  `registeredBPIInitializing' added to type used in `docsIfCmtsCmStatusValue'

  That is OK sinmce it is a read-only object. So when an existing implementation
  does not return the new values, it is still compliant with old MODULE-COMPLIANCE

7. ./DOCS-IF-MIB:1167 [3] {range-added} size `(0..512)' added to type used in
  `docsIfSigQEqualizationData'

  you may want to add some text why the range change is OK

8. ./DOCS-IF-MIB:278 [5] {named-number-added} warning: named number
  `taps12increment17' added to type used in `docsIfDownChannelInterleave'

  is OK since it already has specific syntax in old MODULE-COMPLIANCE

9. ./DOCS-IF-MIB:457 [3] {range-changed} range of type used in
  `docsIfUpChannelWidth' changed from `(0..20000000)' to `(0..64000000)'

  is OK since there is already specific syntax in MODULE-COMPLIANCE
  statements

Other comments:

- for object: docsIfCmtsQosProfilePermissions I see:
            "This object specifies permitted methods of creating
            entries in docsIfQosProfileTable.
            CreateByManagement(0) is set if entries can be created
            using SNMP.  UpdateByManagement(1) is set if updating
            entries using SNMP is permitted.  CreateByModems(2)
            is set if entries can be created based on information
            in REG-REQ MAC messages received from Cable Modems.
            Information in this object is only applicable if
            docsIfQosProfileTable is implemented as read-create.
            Otherwise, this object is implemented as read-only
            and returns CreateByModems(2).
            Either CreateByManagement(0) or CreateByModems(1)
            MUST be set when writing to this object.
            Note that BITS objects are encoded most significant bit
            first.  For example, if bit 2 is set, the value of this
            object is the octet string '20'H."

  1. The values start with lowercase. So it would be better to be
    consistent when using the names/labels of the values.
  2. I see "Either CreateByManagement(0) or CreateByModems(1)"
    but the valie for "createByModems" is actually 2 and not 1.
    You either want to fix it to 2, but probably you mean
    "updateByManagement(1)" ??
  3. If the latter,m does that mean that one cannot do a SET for
    "createByModems" ?? If so, then a WRITE-SYNTAX in the
    MODULE-COMPLIANCE is the way to express that machine readable.

- docsIfCmtsModControl OBJECT-TYPE
        SYNTAX      RowStatus
        MAX-ACCESS  read-create
        STATUS      current
        DESCRIPTION
            "Controls and reflects the status of rows in this table."
        ::= { docsIfCmtsModulationEntry 3 }

  It would be good to add text to explain which (if any) objects can be
  changed when the row is active.

  Pls check if there are other RowStatus objects that lack that text as well.


- WHen you deprecate/obsolete objects or groups or module compliance or
  whatever, then it is good practice to ADD a little text to the DESCRITPION
  clause to explain why the depraction/obsoletion occured and which (if any)
  other definition should be used instead.

- docsIfCmtsCmStatusValue OBJECT-TYPE
        SYNTAX      INTEGER {
            other(1),
            ranging(2),
            rangingAborted(3),
            rangingComplete(4),
            ipComplete(5),
            registrationComplete(6),
            accessDenied(7),
            operational(8), -- deprecated
            registeredBPIInitializing(9)

  I do not understand why a "deprecated" value gets added when upgrading from
  RFC2670 to this new document. ??

- I do not understand (page 104):

  --
  -- RFC XXXX Conformance definitions
  --
  --    ************************************************************
  --    * NOTES TO RFC Editor (to be removed prior to publication) *
  --    *                                                          *
  --    *  replace XXXX with the IANA assigned RFC number          *
  --      of this document                                        *
  --    *                                                          *
  --    ************************************************************

  docsIfCompliancesV2  OBJECT IDENTIFIER    ::= { docsIfConformance 3 }
  docsIfGroupsV2      OBJECT IDENTIFIER    ::= { docsIfConformance 4 }

  That is... why do you want to add an extra level here?
  The above 2 do not seem needed in my view. Not that it is an error,
  it is just extra "baggage" so to speak that (I think) serves no
  purpose. Or am I missing something?

  The following then is more a RFC2670 definition... if you really want
  to make reference to an RFC.

  docsIfBasicCompliance MODULE-COMPLIANCE
        STATUS      deprecated
        DESCRIPTION
            "The compliance statement for devices that implement
            MCNS/DOCSIS compliant Radio Frequency Interfaces."

- This: docsIfCmtsOptionalGroupV2 OBJECT-GROUP
  is really a bad name for an OBJECT-GROUP.
  The fact that a group is optional of not is something that you express
  in the MODULE-COMPLIANCE. The OBJECT-GROUP macro is just to logically
  group objects together. The DESCRIPTION clause is also weird:
      DESCRIPTION
          "Group of objects implemented optionally in Cable Modem
            Termination Systems."
  I would rather see you describe what "logical group of objects" it
  is. FOr example:
      "This is a group of counters to monitor mini-slots. These can
      be implemented in Cable Modem Termination Systems."
  Might even want to explain what mini-slots are (for the novice reader).
 
- doc header states:    Obsoletes: RFC 2670
  but abstract says:
  This document revises RFC 2670.  Please see section 10 for a
  description of the changes from RFC 2670.
  Make sure that the abstract also states that this doc obsoletes 2670.

- The MIB module states:

        REVISION        "200411221700Z"
        DESCRIPTION
            "Revision of the IETF RF MIB module for DOCSIS 2.0.
            This version published as RFC XXXX."

  You need to list (at least the major) changes to the MIB module.
  Pls realize that a lot of people extract the MIB module from the document
  and then the sect 10 is not always easily available/handy.

- I see in docsIfUpstreamChannelEntry

            For DOCSIS 1.x CM/CMTSs and DOCSIS 2.0 CMs, an entry in
            this table exists for each ifEntry with an ifType of
            docsCableUpstreamInterface (129)."

  while the real label in the IANAifType-MIB is docsCableUpstream (129)

- Can you explain why you need the compexity of clone from as described in
  docsIfUpChannelCloneFrom, docsIfUpChannelUpdate and docsIfUpChannelStatus
  I really do not understand why you have to make this so complex.

- your heading (page heading) dates are out of sync with the front page
  date.

- In Security COnsiderations:
          The table docsIfCmtsCmStatusTable also contain the MAC and IP
          addresses of the cable modems that cam be used of thief of
          service and IP spoofing.

  s/cam/can/
  "of thief of.." ??? is it "for theft of.." ??

I still need to sit down and try to understand all the MIB objects.

Bert