Subject: Re: AD review of: draft-ietf-atommib-rfc2495bis-05.txt

From: "C. M. Heard" <[email-masked]>
Date: Wed, 7 Jan 2004 01:08:23 -0800 (PST)

On Tue, 6 Jan 2004, Wijnen, Bert (Bert) wrote:
Bert> WG, author(s),
Bert> 
Bert> When I run SMICng against it, I get:
Bert> 
Bert>   W: f(rfc2495bis.mi2), (42,24) The first revision should
Bert>      match the last update for MODULE-IDENTITY ds1
Bert> 
Bert> Why is this?

I think this was just an oversight when the -05 drafts were spun,
and I noted it in my WG Last Call comments:

% These new drafts address the last outstanding MIB doctor issues that
% I raised regarding the -04 drafts, so I think they are ready to go
% to the IESG.  One minor issue that has cropped up with both drafts
% is that the dates on the LAST-UPDATED clauses and the most recent
% REVISION clauses don't match (the latter were not updated from -04),
% but I think this can be handled with an RFC Editor note (or careful
% inspection during the AUTH48 period) since those dates will be
% changed by the RFC Editor anyway as part of the final editing.

Bert>   W: f(rfc2495bis.mi2), (1147,35) Row "dsx1ChanMappingEntry" does not
Bert>      have a consistent indexing scheme - index item dsx1Ds1ChannelNumber
Bert>      from base row dsx1ConfigEntry is not defined as an index item
Bert>   W: f(rfc2495bis.mi2), (2404,11) OBJECT-GROUP "ds1DeprecatedGroup"
Bert>      is not used in a MODULE-COMPLIANCE in current module
Bert>   W: f(rfc2495bis.mi2), (2462,11) NOTIFICATION-GROUP
Bert>      "ds1NearEndOptionalTrapGroup" is not used in a MODULE-COMPLANCE
Bert>      in current module
Bert> 
Bert> I understand the above 3 already existed in rfc2496 iteself
Bert> I can live with it, but I would think we could fix the last 2,
Bert> can we not?

Bert, when I reviewed the -02 version of this document I made the
following comments about those last two warnings (or rather the
equivalent warnings from smilint):

% The unreferenced group warning for deprecated group `ds1DeprecatedGroup'
% is likewise not a problem, since it is reasonable for a deprecated
% group of deprecated objects to be unreferenced by any compliance
% statement.  The unreferenced group warning for current group
% `ds1NearEndOptionalTrapGroup' simply indicates that the group (as
% its name indicates) is optional.  In this reviewer's opinion the
% intent is sufficiently clear that there is no need to enforce the
% recommendation in <draft-ietf-ops-mib-review-guidelines-01.txt>
% Section 4.8 to mention this group in a GROUP clause.  (Note,
% however, that when it comes time to advance the specification it
% will be necessary either to provide evidence that this group is
% present in two implementations or else it must be deprecated.)

While admitting that the reasoning about the optional trap group may
be be open to debate -- although I don't really see any need for a
correction -- I do feel strongly that the warning for
ds1DeprecatedGroup should be ignored.  All of the objects in this
group are inherited from RFC 1406, which was an SMIv1 MIB module
(and so did not have any compliance statements).  Fixing this
warning would require writing a brand-new deprecated compliance
statement just to contain a deprecated group of deprecated objects.
That seems to me to be nothing but make-work that adds no value to
the specification, and I don't think that it would be right to
require it.  In fact if I had my way tools would not generate
warnings like that for deprecated groups (only for current ones).

Bert> smilint tells me:
Bert> 
Bert>   .\DS1-MIB:1776: [5] {} warning: implicit node definition
Bert> 
Bert> Same in original RFC2495. No problem.
Bert> 
Bert>   .\DS1-MIB:2404: [5] {group-unref} warning: deprecated group
Bert>      `ds1DeprecatedGroup' is not referenced in this module
Bert>   .\DS1-MIB:2462: [5] {group-unref} warning: current group
Bert>      `ds1NearEndOptionalTrapGroup' is not referenced in this module
Bert> 
Bert> See above under SMICng warnings.
Bert> 
Bert> This is the information I get when I run smidiff:
Bert> 
Bert> Note: .\DS1-MIB is the 2495bis version, 
Bert>       ..\ietf\DS1-MIB is the original 2495 version
Bert> 
Bert>   .\DS1-MIB:13 [5] {organization-changed} warning: organization 
Bert>     of `DS1-MIB' changed
Bert>   .\DS1-MIB:13 [5] {contact-changed} warning: contact of `DS1-MIB'
Bert>     changed
Bert>   .\DS1-MIB:13 [5] {description-changed} warning: description of
Bert>     module identity definition `DS1-MIB' changed
Bert>   .\DS1-MIB:45 [5] {revision-added} warning: revision
Bert>     `2003-10-19 00:00' added
Bert> is OK
Bert> 
Bert>   .\DS1-MIB:42 [5] {revision-added} warning: revision 
Bert>     `2003-08-17 00:00' added
Bert> Mmm... I guess it gets confused here because the
Bert> LAST-UPDATE and first REVISION dates differ.

Correct, and this is something that I agree should be fixed (as my
WG last call comments indicate).

Bert>   .\DS1-MIB:52 [5] {revision-added} warning: revision 
Bert>     `1993-01-25 20:28' added
Bert> OK
Bert> 
Bert>   ..\ietf\DS1-MIB:13 [6] {previous-definition} info: previous
Bert>     definition of `DS1-MIB'
Bert>   .\DS1-MIB:181 [5] {named-number-added} warning: named number
Bert>     `dsx1E1Q50' added to type used in `dsx1LineType'
Bert>   .\DS1-MIB:181 [5] {named-number-added} warning: named number
Bert>     `dsx1E1Q50CRC' added to type used in `dsx1LineType'
Bert>   .\DS1-MIB:181 [5] {description-changed} warning: description 
Bert>     of object definition `dsx1LineType' changed
Bert>   .\DS1-MIB:181 [5] {ref-added} warning: reference added to
Bert>     `dsx1LineType'
Bert>   ..\ietf\DS1-MIB:154 [6] {previous-definition} info: previous
Bert>     definition of `dsx1LineType'
Bert> Seems OK, given recycle at PS.
Bert> But should we not change the deprecated COMPLIANCE to exclude the 
Bert> new additions?

While it would not hurt to do so, it is not actually necessary since
the MIB-ACCESS for dsx1LineType is read-only in the deprecated
compliance statements (as indeed it is in all the compliance
statements except ds1Ds2Compliance).  Since an agent is obliged to
return (in a response to a GetRequest-PDU) only the line type values
corresponding to hardware it supports, expanding the repertoire of
values does not in this case silently impose extra requirements for
an agent to be minimally compliant.  Note that in the SONET-MIB we
did not revise the OBJECT clause for sonetPathCurrentWidth, even
though its value repertoire was expanded;  the reason was the same,
namely that its MIN-ACCESS was read-only.

I did miss the fact in my earlier reviews that ds1Ds2Compliance does
not have an object clause for dsx1LineType.  This is probably an
oversight that should be corrected ... it seems to me from the
DESCRIPTION clause of the compliance statement that the the only
line types that apply here are dsx1DS2M12(10) and dsx2E2(11).  Orly,
is that your understanding, too?

Bert>   .\DS1-MIB:344 [5] {ref-added} warning: reference added to
Bert>     `dsx1CircuitIdentifier'
Bert> fine
Bert> 
Bert>   .\DS1-MIB:474 [5] {named-number-added} warning: named number
Bert>     `adaptive' added to type used in `dsx1TransmitClockSource'
Bert>   .\DS1-MIB:474 [5] {description-changed} warning: description
Bert>     of object definition `dsx1TransmitClockSource' changed
Bert>   ..\ietf\DS1-MIB:431 [6] {previous-definition} info: previous
Bert>     definition of `dsx1TransmitClockSource'
Bert> Seems OK, given we recycle at PS,
Bert> But should we not exclude the new values from the deprecated 
Bert> COMPLIANCE statements?

Again, MIN-ACCESS is read-only (except for ds1Ds2Compliance;
correction is needed in that case, there should be an OBJECT
clause specifying only the old values).

Bert>   .\DS1-MIB:602 [5] {description-changed} warning: description
Bert>     of object definition `dsx1Ds1ChannelNumber' changed
Bert>   ..\ietf\DS1-MIB:557 [6] {previous-definition} info: previous
Bert>     definition of `dsx1Ds1ChannelNumber'
Bert> OK, fixes a lower case s to uppercase S
Bert> 
Bert>   .\DS1-MIB:1236 [5] {description-changed} warning: description
Bert>     of object definition `dsx1FarEndValidIntervals' changed
Bert>   ..\ietf\DS1-MIB:1160 [6] {previous-definition} info: previous
Bert>     definition of `dsx1FarEndValidIntervals'
Bert> Clarification, so OK
Bert> 
Bert>   .\DS1-MIB:1746 [3] {range-changed} range of type used in
Bert>     `dsx1FracIfIndex' changed from `(1..2147483647)'
Bert>     to `(0..2147483647)'
Bert> Seems to be fixing a bug, namely to get this in sync with dsx1LineIndex.
Bert> However, for dsx1LineIndex we use InterfaceIndex. Why don't we do that
Bert> here as well?

I made the following comment in my review of the -02 draft.  Note that
what would be needed here would be InterfaceIndexOrZero.

% (c) At the editor's discretion, the SYNTAX value of dsx1FracIfIndex
% could be changed from INTEGER (0..'7fffffff'h) to
% InterfaceIndexOrZero.  If this is done, then InterfaceIndexOrZero
% would need to be imported from IF-MIB.  This is not given a high
% priority since dsx1FracIfIndex is a deprecated object. 

My feeling was this changing the definition was not very important
since this is a deprecated object.

Bert>   .\DS1-MIB:633 [5] {node-added} warning: column `dsx1LineMode'
Bert>     has been added
Bert>   .\DS1-MIB:645 [5] {node-added} warning: column
Bert>     `dsx1LineBuildOut' has been added
Bert> OK since we stay at PS.
Bert> But they have been added to an existing Group, which is not allowed
Bert> See RFC2578 sect 7.1

I think you mean RFC 2580.  In any case, these objects were NOT added
to an existing conformance group.  There is a deprecated group called
ds1NearEndConfigGroup that does not contain these objects;  it is
referenced by the deprecated compliance statements.  There is also a
newly added current group called ds1NearEndConfigurationGroup that
does have these objects;  it is referenced by the new compliance
statements that replace the deprecated ones.  The only change to
ds1NearEndConfigGroup was a legal status change, so I think this is OK.

[ I seem to recall having a lengthy discussion with Orly about this
topis but I can't seem to find the discussion in my mail archive. ]

Bert>   .\DS1-MIB:2295 [5] {status-change} warning: legal status change
Bert>      from `current' to `deprecated' for `ds1NearEndConfigGroup'
Bert>   ..\ietf\DS1-MIB:1951 [6] {previous-definition} info: previous
Bert>     definition of `ds1NearEndConfigGroup'
Bert>   .\DS1-MIB:2478 [5] {node-added} warning: group
Bert>    `ds1NearEndConfigurationGroup' has been added
Bert>   .\DS1-MIB:1786 [5] {status-change} warning: legal status change
Bert>     from `current' to `deprecated' for `ds1Compliance'
Bert>   ..\ietf\DS1-MIB:1705 [6] {previous-definition} info: previous
Bert>     definition of `ds1Compliance'
Bert>   .\DS1-MIB:1880 [5] {status-change} warning: legal status change
Bert>     from `current' to `deprecated' for `ds1MibT1PriCompliance'
Bert>   ..\ietf\DS1-MIB:1799 [6] {previous-definition} info: previous
Bert>     definition of `ds1MibT1PriCompliance'
Bert>   .\DS1-MIB:1944 [5] {status-change} warning: legal status change
Bert>     from `current' to `deprecated' for `ds1MibE1PriCompliance'
Bert>   ..\ietf\DS1-MIB:1862 [6] {previous-definition} info: previous
Bert>     definition of `ds1MibE1PriCompliance'
Bert>   .\DS1-MIB:2031 [5] {node-added} warning: compliance
Bert>     `ds1NCompliance' has been added
Bert>   .\DS1-MIB:2135 [5] {node-added} warning: compliance
Bert>     `ds1MibT1PriNCompliance' has been added
Bert>   .\DS1-MIB:2211 [5] {node-added} warning: compliance
Bert>     `ds1MibE1PriNCompliance' has been added
Bert> Seems OK
Bert> 
Bert> So the basic question here is: Did anyone check that all changes
Bert> made to the existing MIB are withing the rules of SMIv2?

Yes, I audited the changes in my MIB Doctor review of -02 (May 2003) and
I found that all of the changes except one were OK.  The one error that
I found at that time has since been corrected.

Bert> Here is another programmatic check:
Bert> $ /bin/checkpage.awk < drafts/draft-ietf-atommib-rfc2495bis-05.txt
Bert> Long page at 59
Bert> Long line at 491 with 73 chars
Bert> Long line at 515 with 75 chars
Bert> Long line at 516 with 73 chars
Bert> Long line at 518 with 76 chars
Bert> Long line at 519 with 77 chars
Bert> Long line at 1156 with 76 chars
Bert> Long line at 1186 with 78 chars
Bert> Long line at 1204 with 78 chars
Bert> Long line at 1287 with 73 chars
Bert> Long line at 1288 with 73 chars
Bert> Long line at 1456 with 74 chars
Bert> Long line at 1458 with 75 chars
Bert> Long line at 1469 with 74 chars
Bert> Long line at 1720 with 78 chars
Bert> Long line at 1721 with 75 chars
Bert> Long line at 1724 with 76 chars
Bert> Long line at 1731 with 76 chars
Bert> Long line at 1732 with 74 chars
Bert> Long line at 1734 with 76 chars
Bert> Long line at 4356 with 77 chars
Bert> -: 20 lines longer than 72 characters, max 78
Bert> -: 1 pages longer than 58 lines, max 5414 lines
Bert> 
Bert> I know RFC editor can (and probably will fix it).
Bert> 
Bert> Further I see:
Bert> 1. header page in abstract it says:
Bert>       This document entirely replaces RFC 2495.
Bert>    s/entirely replaces/obsoletes/
Bert> 
Bert> 2. You removed the section: Changes from RFC1406
Bert>    I believe that we normally keep them for stds track RFCs, so people
Bert>    can quickly see what type of changes were made when the stds track
Bert>    doc gets revised.

Good point.  Oftentimes the change logs are placed in appendices
at the end;   see, e.g., RFC 3484 for a good example.

Bert> 3. The Revision clause for this revision says:
Bert>              REVISION "200308170000Z"
Bert>              DESCRIPTION
Bert>                   "The RFC yyyy version of this MIB module."
Bert>    It should also list the changes made to this revision.
Bert> 
Bert> 4. Same for the RFC2495 revision clause, it should list the
Bert>    changes made when going from 1406 to 2495

Hmm, it seems to me that this is asking the editor of this version
to correct editorial oversights left over from the previous version.
Is that really necessary, if the changelog from 2495 is restored?

Bert> 5. Reference to RFC1213
Bert>          dsx1IfIndex OBJECT-TYPE
Bert>               SYNTAX  InterfaceIndex
Bert>               MAX-ACCESS  read-only
Bert>               STATUS  deprecated
Bert>               DESCRIPTION
Bert>                      "This value for this object is equal to the value
Bert>                      of ifIndex from the Interfaces table of MIB II
Bert>                      (RFC 1213)."
Bert>    Would it not be better to just reference RFC2863, IF-MIB ?

From previous correspondence on this list (mainly about the DS3-MIB,
but addresses this document too):

% > > (c) there are two places in the document that refer to RFC 1213,
% > > one in the DESCRIPTION clause of the deprecated object dsx3IfIndex
% > > and one in Appendix A, which describes the historical (RFC 1407)
% > > usage of dsx3LineIndex/dsx3IfIndex.  It should therefore be listed
% > > as an informative reference.  So also should RFC 1407 itself.
% > > 
% > I would suggest to replace mentioning of rfc1213 with mentioning 
% > RFC2863. That is where current definition is for ifIndex. And it
% > seems to make sense for both places where RFc1213 is mentioned.
% 
% I considered suggesting that, but in the end figured that since the
% MIB object and the appendix where it is mentioned describe the
% historical usage defined in RFC 1407 _prior_ to the emergence of the
% IF-MIB (and the ifStackTable in particular) the reader will get a
% more accurate picture if the references to the original interfaces
% group in RFC 1213 are left in place.  Notice that RFC 1213 (and RFC
% 1407) would be listed as informative references, since the
% deprecated/historical stuff is not considered part of the standard.
% 
% In any case, notice that an exactly similar comment on the DS1-MIB
% document;  whatever resolution is agreed on should apply to it, too.

Notice that RFC 1213 and RFC 1406 are indeed listed as informative
references as I recommended above.  I'd like to suggest that in this
case the REFERENCE clause is correct as it stands.

Bert> 6. Reference to MIB II in DESCRTIPTION clause of dsx1LineStatusLastChange
Bert>    This may better be replaced with reference to current RFC3416.
Bert>    That is where current sysUpTime is defined.

In this case I agree (the object has a STATUS value of current).

Bert> 7. I think it would behoove us as WG to add to the ackbnowledgeemnt 
Bert>    section some thanks to   D. Fowler, Editor of RFC2495!
Bert>    Maybe even thank the authors/editors of 1406 as well.

Agreed.

//cmh

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 6 Jan 2004 17:56:48 +0100

WG, author(s),

When I run SMICng against it, I get:

  W: f(rfc2495bis.mi2), (42,24) The first revision should match the last
     update for MODULE-IDENTITY ds1

Why is this?

  W: f(rfc2495bis.mi2), (1147,35) Row "dsx1ChanMappingEntry" does not
     have a consistent indexing scheme - index item dsx1Ds1ChannelNumber
     from base row dsx1ConfigEntry is not defined as an index item
  W: f(rfc2495bis.mi2), (2404,11) OBJECT-GROUP "ds1DeprecatedGroup"
     is not used in a MODULE-COMPLIANCE in current module
  W: f(rfc2495bis.mi2), (2462,11) NOTIFICATION-GROUP
     "ds1NearEndOptionalTrapGroup" is not used in a MODULE-COMPLANCE
     in current module

I understand the above 3 already existed in rfc2496 iteself
I can live with it, but I would think we could fix the last 2, can we not?

smilint tells me:

  .\DS1-MIB:1776: [5] {} warning: implicit node definition

Same in original RFC2495. No problem.

  .\DS1-MIB:2404: [5] {group-unref} warning: deprecated group
     `ds1DeprecatedGroup' is not referenced in this module
  .\DS1-MIB:2462: [5] {group-unref} warning: current group
     `ds1NearEndOptionalTrapGroup' is not referenced in this module

See above under SMICng warnings.

This is the information I get when I run smidiff:

Note: .\DS1-MIB is the 2495bis version, 
      ..\ietf\DS1-MIB is the original 2495 version

  .\DS1-MIB:13 [5] {organization-changed} warning: organization 
    of `DS1-MIB' changed
  .\DS1-MIB:13 [5] {contact-changed} warning: contact of `DS1-MIB'
    changed
  .\DS1-MIB:13 [5] {description-changed} warning: description of
    module identity definition `DS1-MIB' changed
  .\DS1-MIB:45 [5] {revision-added} warning: revision
    `2003-10-19 00:00' added
is OK

  .\DS1-MIB:42 [5] {revision-added} warning: revision 
    `2003-08-17 00:00' added
Mmm... I guess it gets confused here because the
LAST-UPDATE and first REVISION dates differ.

  .\DS1-MIB:52 [5] {revision-added} warning: revision 
    `1993-01-25 20:28' added
OK

  ..\ietf\DS1-MIB:13 [6] {previous-definition} info: previous
    definition of `DS1-MIB'
  .\DS1-MIB:181 [5] {named-number-added} warning: named number
    `dsx1E1Q50' added to type used in `dsx1LineType'
  .\DS1-MIB:181 [5] {named-number-added} warning: named number
    `dsx1E1Q50CRC' added to type used in `dsx1LineType'
  .\DS1-MIB:181 [5] {description-changed} warning: description 
    of object definition `dsx1LineType' changed
  .\DS1-MIB:181 [5] {ref-added} warning: reference added to
    `dsx1LineType'
  ..\ietf\DS1-MIB:154 [6] {previous-definition} info: previous
    definition of `dsx1LineType'
Seems OK, given recycle at PS.
But should we not change the deprecated COMPLIANCE to exclude the 
new additions?

  .\DS1-MIB:344 [5] {ref-added} warning: reference added to
    `dsx1CircuitIdentifier'
fine

  .\DS1-MIB:474 [5] {named-number-added} warning: named number
    `adaptive' added to type used in `dsx1TransmitClockSource'
  .\DS1-MIB:474 [5] {description-changed} warning: description
    of object definition `dsx1TransmitClockSource' changed
  ..\ietf\DS1-MIB:431 [6] {previous-definition} info: previous
    definition of `dsx1TransmitClockSource'
Seems OK, given we recycle at PS,
But should we not exclude the new values from the deprecated 
COMPLIANCE statements?

  .\DS1-MIB:602 [5] {description-changed} warning: description
    of object definition `dsx1Ds1ChannelNumber' changed
  ..\ietf\DS1-MIB:557 [6] {previous-definition} info: previous
    definition of `dsx1Ds1ChannelNumber'
OK, fixes a lower case s to uppercase S

  .\DS1-MIB:1236 [5] {description-changed} warning: description
    of object definition `dsx1FarEndValidIntervals' changed
  ..\ietf\DS1-MIB:1160 [6] {previous-definition} info: previous
    definition of `dsx1FarEndValidIntervals'
Clarification, so OK

  .\DS1-MIB:1746 [3] {range-changed} range of type used in
    `dsx1FracIfIndex' changed from `(1..2147483647)'
    to `(0..2147483647)'
Seems to be fixing a bug, namely to get this in sync with dsx1LineIndex.
However, for dsx1LineIndex we use InterfaceIndex. Why don't we do that
here as well?

  .\DS1-MIB:633 [5] {node-added} warning: column `dsx1LineMode'
    has been added
  .\DS1-MIB:645 [5] {node-added} warning: column
    `dsx1LineBuildOut' has been added
OK since we stay at PS.
But they have been added to an existing Group, which is not allowed
See RFC2578 sect 7.1

  .\DS1-MIB:2295 [5] {status-change} warning: legal status change
     from `current' to `deprecated' for `ds1NearEndConfigGroup'
  ..\ietf\DS1-MIB:1951 [6] {previous-definition} info: previous
    definition of `ds1NearEndConfigGroup'
  .\DS1-MIB:2478 [5] {node-added} warning: group
   `ds1NearEndConfigurationGroup' has been added
  .\DS1-MIB:1786 [5] {status-change} warning: legal status change
    from `current' to `deprecated' for `ds1Compliance'
  ..\ietf\DS1-MIB:1705 [6] {previous-definition} info: previous
    definition of `ds1Compliance'
  .\DS1-MIB:1880 [5] {status-change} warning: legal status change
    from `current' to `deprecated' for `ds1MibT1PriCompliance'
  ..\ietf\DS1-MIB:1799 [6] {previous-definition} info: previous
    definition of `ds1MibT1PriCompliance'
  .\DS1-MIB:1944 [5] {status-change} warning: legal status change
    from `current' to `deprecated' for `ds1MibE1PriCompliance'
  ..\ietf\DS1-MIB:1862 [6] {previous-definition} info: previous
    definition of `ds1MibE1PriCompliance'
  .\DS1-MIB:2031 [5] {node-added} warning: compliance
    `ds1NCompliance' has been added
  .\DS1-MIB:2135 [5] {node-added} warning: compliance
    `ds1MibT1PriNCompliance' has been added
  .\DS1-MIB:2211 [5] {node-added} warning: compliance
    `ds1MibE1PriNCompliance' has been added
Seems OK

So the basic question here is: Did anyone check that all changes
made to the existing MIB are withing the rules of SMIv2?

Here is another programmatic check:
$ /bin/checkpage.awk < drafts/draft-ietf-atommib-rfc2495bis-05.txt
Long page at 59
Long line at 491 with 73 chars
Long line at 515 with 75 chars
Long line at 516 with 73 chars
Long line at 518 with 76 chars
Long line at 519 with 77 chars
Long line at 1156 with 76 chars
Long line at 1186 with 78 chars
Long line at 1204 with 78 chars
Long line at 1287 with 73 chars
Long line at 1288 with 73 chars
Long line at 1456 with 74 chars
Long line at 1458 with 75 chars
Long line at 1469 with 74 chars
Long line at 1720 with 78 chars
Long line at 1721 with 75 chars
Long line at 1724 with 76 chars
Long line at 1731 with 76 chars
Long line at 1732 with 74 chars
Long line at 1734 with 76 chars
Long line at 4356 with 77 chars
-: 20 lines longer than 72 characters, max 78
-: 1 pages longer than 58 lines, max 5414 lines

I know RFC editor can (and probably will fix it).

Further I see:
1. header page in abstract it says:
      This document entirely replaces RFC 2495.
   s/entirely replaces/obsoletes/

2. You removed the section: Changes from RFC1406
   I believe that we normally keep them for stds track RFCs, so people
   can quickly see what type of changes were made when the stds track
   doc gets revised.

3. The Revision clause for this revision says:
             REVISION "200308170000Z"
             DESCRIPTION
                  "The RFC yyyy version of this MIB module."
   It should also list the changes made to this revision.

4. Same for the RFC2495 revision clause, it should list the
   changes made when going from 1406 to 2495

5. Reference to RFC1213
         dsx1IfIndex OBJECT-TYPE
              SYNTAX  InterfaceIndex
              MAX-ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                     "This value for this object is equal to the value
                     of ifIndex from the Interfaces table of MIB II
                     (RFC 1213)."
   Would it not be better to just reference RFC2863, IF-MIB ?

6. Reference to MIB II in DESCRTIPTION clause of dsx1LineStatusLastChange
   This may better be replaced with reference to current RFC3416.
   That is where current sysUpTime is defined.

7. I think it would behoove us as WG to add to the ackbnowledgeemnt 
   section some thanks to   D. Fowler, Editor of RFC2495!
   Maybe even thank the authors/editors of 1406 as well.

Thanks,
Bert