Subject: RE: [ipcdn] request for ID publication: DOCSIS RFIv2 mib - 2670b is

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 29 Dec 2004 17:30:29 +0100

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:\bwijnen\smicng\work>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 ..\ietf\DOCS-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
> -----Original Message-----
> From: Jean-Francois Mule [mailto:[email-masked]]
> Sent: Friday, October 29, 2004 22:51
> To: [email-masked]; [email-masked]
> Cc: Richard Woundy @ Comcast
> Subject: [ipcdn] request for ID publication: DOCSIS RFIv2 mib 
> - 2670bis
> 
> 
> We would like to request formal publication for the ID 
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmib
> v2-11.txt.
> 
> Bert, please approve - see status below.
> 
> Jean-François 
> 
> > -----Original Message-----
> > From: Jean-Francois Mule 
> > Sent: Thursday, October 28, 2004 3:55 PM
> > To: [email-masked]
> > Cc: Eduardo Cardona; [email-masked]; [email-masked]
> > Subject: RE: [ipcdn] status of ipcdn DOCSIS RFIv2 mib - 2670bis
> > 
> > 
> > Just to close the loop on this mib, we received no comments 
> > on this post. It is therefore our intent to request its publication.
> > 
> > -- Rich and Jean-Francois.
> > 
> > > -----Original Message-----
> > > From: Jean-Francois Mule
> > > Sent: Wednesday, October 06, 2004 1:57 PM
> > > To: [email-masked]
> > > Cc: Eduardo Cardona; [email-masked]
> > > Subject: [ipcdn] status of ipcdn DOCSIS RFIv2 mib - 2670bis
> > > 
> > > 
> > > 
> > >    This note provides a brief status update on the ipcdn 
> > DOCSIS RFIv2 
> > > mib Internet-Draft. It is also a follow-up from the IETF 
> > meeting #60 
> > > in San Diego.
> > > 
> > > --- Brief status
> > > The current ID is draft-ietf-ipcdn-docs-rfmibv2-11.
> > >  
> > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmib
> v2-11.txt
> A working group last call was issued on 1/23/2004 and ended 
> on 2/6/2004. The authors believe that draft 11 does address 
> all the wg comments as well as AD review comments from Bert. 
> Based on the input received this week from the authors and 
> the current editor Eduardo, no new comments have been 
> received since the ID was revised at the end of July 2004.
> 
> --- San Diego wg meeting follow-up
> Based on our meeting minutes at 
http://www.ietf.org/proceedings/04aug/171.htm#rfimib , we wanted to ping the mailing list to see if another WGLC is needed. If you think a second WGLC should be issued, please let the ipcdn wg know by sending an email to the list by Wednesday October 13, 5pm ET.

--- Next steps
Pending wg consensus that a new WGLC is not needed and no objection to move this ID forward, it is the wg chairs intent to submit the ID for publication/IESG review to Bert.

Rich and Jean-Francois.
IPCDN co-chairs

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn