RE: idnits and smilint on Cable Device MIB Draft 09

Folks,

With respect to the discussion version of the Cable Device MIB -10:
<http://www.ipcdn.org/drafts/draft-ietf-ipcdn-device-mibv2-10-discussion
.txt>
<http://www.ipcdn.org/drafts/draft-ietf-ipcdn-device-mibv2-10-discussion
.xml>

I get the same clean output from idnits, and now much better output from
smilint.

The significant MIB compilation problem with version -09 was the
inclusion of deprecated groups in the current compliance statements
'docsDevCmCompliance' and 'docsDevCmtsCompliance'.

After further discussion among the authors, we decided that we should
remove the deprecated groups from the current compliance statement. The
key realization is that if a particular version of DOCSIS requires
implementation of a deprecated group, then that requirement can be
captured in a CableLabs specification, not in this internet-draft/RFC.
This internet-draft/RFC should be agnostic with regards to DOCSIS
versions and their (evolving) requirements.

The unfortunate consequence is that the group 'docsDevNmAccessExtGroup'
is no longer referenced by any compliance statement. This group consists
of a single MIB object that was invented by CableLabs after publication
of RFC 2669. We still include this MIB object (and group) for future
reference -- although it is immediately deprecated.

Note that we post-dated the MIB to August 8, hence the "future date"
warnings.

---

Here is the latest smilint output:

This is an automatically generated mail message in response to a mail
message you (or someone else who used your address) sent to
<[email protected]>. If you want to learn more about this mail
service, send a mail message with the "Subject: help" to
<[email protected]>.

The program smilint 0.4.3, as of Thu Jun 23 10:41:27 2005
has been used to process your request as follows:

smilint -m -s -e -l 6 mailbody

mailbody:43: [4] {date-in-future} warning: date specification
`200508080000Z' is in the future
mailbody:81: [4] {date-in-future} warning: date specification
`200508080000Z' is in the future
mailbody:2394: [5] {index-exceeds-too-large} warning: index of row
`docsDevCpeInetEntry' can exceed OID size limit by 141 subidentifier(s)
mailbody:3100: [5] {group-unref} warning: deprecated group
`docsDevNmAccessExtGroup' is not referenced in this module

-- Rich

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Randy Presuhn
Sent: Saturday, June 25, 2005 1:51 AM
To: Ipcdn (E-mail)
Subject: [ipcdn] idnits and smilint on Cable Device MIB Draft 09 


Hi -

Good news and not-so-good news.

On
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-09.txt,
I ran http://ietf.levkowetz.com/tools/idnits/idnits.pyht, and it gave
the -09 a clean bill of health:

idnits 1.74

tmp/draft-ietf-ipcdn-device-mibv2-09.txt:


  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.

When I ran smilint 0.4.3, things were a bit more interesting.  (I used
the [email protected] service) It identified two issues.

mailbody:2489: [5] {index-exceeds-too-large} warning: index of row
`docsDevCpeInetEntry' can exceed OID size limit by 141
subidentifier(s)

   This is OK,  the DESCRIPTION of docsDevCpeInetAddr explains the
situation
   in the spirit of the MBI review guidelines section 4.6.6

mailbody:3013: [4] {compliance-group-status} warning: current compliance
statement `docsDevCmCompliance' includes deprecated group
`docsDevNmAccessGroup'
mailbody:3031: [4] {compliance-group-status} warning: current compliance
statement `docsDevCmCompliance' includes deprecated group
`docsDevNmAccessExtGroup'
mailbody:3044: [4] {compliance-group-status} warning: current compliance
statement `docsDevCmCompliance' includes deprecated group
`docsDevFilterGroup'
mailbody:3195: [4] {compliance-group-status} warning: current compliance
statement `docsDevCmtsCompliance' includes deprecated group
`docsDevNmAccessGroup'
mailbody:3206: [4] {compliance-group-status} warning: current compliance
statement `docsDevCmtsCompliance' includes deprecated group
`docsDevNmAccessExtGroup'
mailbody:3235: [4] {compliance-group-status} warning: current compliance
statement `docsDevCmtsCompliance' includes deprecated group
`docsDevFilterGroup'
mailbody:3247: [4] {compliance-group-status} warning: current compliance
statement `docsDevCmtsCompliance' includes deprecated group
`docsDevCpeGroup'

    This doesn't look OK.

    I think what you wanted to say was that the old docsDevCmCompliance
    should be deprecated, and that there will be a
docDevCmComplianceRev1
    (or whatever a good name would be) that has only the "current" stuff
from
    docsDevCmCompliance.  Alternatively, you could keep the old
compliance
    stuff as-is, and just add a docDevCmComplianceRev1.  It depends on
the
    message you want to send.

I'll look at the smidiff output separately.

Randy




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