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

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