RE: idnits and smilint on Cable Device MIB Draft 09

Randy,

Thanks very much for the speedy review!  Regarding your 'not-so-good news',

    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.

we had actually discussed this previously and reached the following conclusion (this was per an "internal" discussion with Rich Woundy and others in response to the question of having compliance statements contain deprecated objects):

Hopefully the MIB doctors are OK with these compliance statements as-is.
Note the following text from the MIB guidelines, page 30 of
<http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-03
.txt>:

   - The status of a compliance statement is independent of the status
     of its members.  Thus, a current compliance statement MAY refer to
     deprecated object groups or notification groups.  This may be
     desirable in certain cases, e.g., a set of widely-deployed object
     or notification groups may be deprecated when they are replaced by
     a more up-to-date set of definitions, but compliance statements
     that refer to them may remain current in order to encourage
     continued implementation of the deprecated groups.

Please let me know if this is acceptable.  Thanks very much,

Kevin Marez
Motorola


-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Randy Presuhn
Sent: Friday, June 24, 2005 10:51 PM
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