MIB Doctor Review of draft-ietf-hubmib-rfc3636bis-05.txt

Greetings,

Since I have reviewed previous versions of this document (see, e.g.,
http://www1.ietf.org/mail-archive/web/hubmib/current/msg00759.html
and subsequent correspondence), Dan Romascanu and David Kessens have
requested that I perform the official MIB Doctor review for
draft-ietf-hubmib-rfc3636bis-05.txt before it is passed to the IESG.

After re-reading this version of the document, here is my bottom
line: apart from minor editorial issues that can easily be fixed by
the RFC Editor, I think that it is ready for publication as a
proposed standard, and I recommend that it be approved by the IESG.

Detailed review comments follow below.  As is my custom, I use the
checklist from Appendix A of the MIB review guidelines to organize
my comments.

1.) I-D Boilerplate -- OK

2.) Abstract -- OK

3.) MIB Boilerplate -- OK

4.) Security Considerations Section -- I would recommend the
following editorial change to 2nd paragraph:

s/There is a number of/There are a number of/

The section is otherwise OK (its content is basically unchanged from
RFC 3636).

5.) IANA Considerations Section -- OK

6.) References -- OK

7.) Copyright Notices -- OK

8.) IPR Notice -- OK

9.) Other issues -- I would recommend that the heading for Section
3.4 be changed from:

3.4.  Management of IEEE 802.3 Managed Objects

to:

3.4.  Mapping of IEEE 802.3 Managed Objects

as it was in RFC 3636.

The automated ID nits checker raises no issues with the document.
Based on that and on the statements in the submission note
(http://www1.ietf.org/mail-archive/web/hubmib/current/msg00951.html)
I think it's fair to assume that issues mentioned in
http://www.ietf.org/ID-Checklist.html have been taken care of.

10.) Technical content -- the changes in functionality relative to
RFC 3636 are relatively modest.  First, support has been added for
the following new standard MAU types:

    10GBASE-CX4
    2BASE-TL
    10PASS-TS
    100BASE-BX10D
    100BASE-BX10U
    100BASE-LX10
    1000BASE-BX10D
    1000BASE-BX10U
    1000BASE-LX10
    1000BASE-PX10D
    1000BASE-PX10U
    1000BASE-PX20D
    1000BASE-PX20U

For each of these there is a new OBJECT-IDENTITY definition that
provides a new standard value for ifMauType, and there is also a
corresponding named bit added to ifMauTypeListBits.

Second, a new enumerated value cx4 has been added to the type used
for ifJackType, in order to allow the connector used with
10GBASE-CX4 MAUs to be represented.

Third, new enumerated values availableReduced and ready have been
added to the type used for ifMauMediaAvailable in order to report
certain states associated with 2BASE-TL and 10PASS-TS MAUs to be
properly reported.

Beside these modest functional changes there has been a significant
reorganization, wherein the OBJECT-IDENTITY constructs that define
MAU type values and the TEXTUAL-CONVENTION constructs that define
jack type values, ifMauMediaAvailable values, and capability values
used in autonegotiation advertisements have been migrated to a
separate IANA-maintained MIB module in order to allow new values to
be added with only an Expert Review instead of the previously
required Standards Action.

The reorgnization is not entirely compliant with the MIB module
revision rules in STD 58 and BCP 111, but this fact is clearly
explained in the draft, and in the eyes of this reviewer the
improved ability to track changes to IEEE Std 802.3 in a timely
manner justifies bending the rules in this case.

The attachments contain the smilint and reports for the IANA-MAU-MIB
and MAU-MIB and the smidiff report for MAU-MIB.  I review these in
detail below, in order to explain why I am OK with the MIB modules
despite the presence of diagnostic messages from the tools (note
that the modules compile cleanly when I use SMICng), I won't comment
on the text portions of the draft since I'm satisfied with their
quality, both technically and editorially.

(a) From the smilint report for IANA-MAU-MIB:

IANA-MAU-MIB:10: [4] {module-identity-registration} warning: uncontrolled MODULE-IDENTITY registration

This warning has been issued because the MODULE-IDENTITY value is
registered below snmpDot3MauMgt, which is defined in MAU MIB as
{ mib-2 26 }, instead of being registered under a node that is
directly controlled in an IANA-maintained registry.  The hazard is
that future maintenance activities on the MIB modules might lead to
duplicate OID assignments if the maintainers are not careful.

At my request, the WG has put ASN.1 comments into the MAU-MIB to
indicate that { snmpDot3MauMgt 7 } is the MODULE-IDENTITY value for
the IANA-MAU-MIB, and also that OIDs under { snmpDot3MauMgt 4 } are
reserved for the IANA-MAU-MIB to assign as MAU type values. I
believe that these measures are adequate to mitigate the hazard.

(b) From the smilint report for MAU-MIB:

rfc3636bis.mi2:110: [5] {identifier-external-redefined} warning: redefinition of identifier `IANA-MAU-MIB::snmpDot3MauMgt'
IANA-MAU-MIB:65: [6] {previous-definition} info: previous definition of `snmpDot3MauMgt'
rfc3636bis.mi2:110: [5] {identifier-external-redefined} warning: redefinition of identifier `IANA-MAU-MIB::snmpDot3MauMgt'
IANA-MAU-MIB:412: [6] {previous-definition} info: previous definition of `snmpDot3MauMgt'

Note that the revised MAU-MIB (rfc3636bis.mi2) IMPORTs several
definitions from the IANA-MAU-MIB, and as a consequence the
IANA-MAU-MIB is parsed first so that its symbols are visible when
the MAU-MIB definitions are processed.  These warnings were issued
because the following definitions appear in the IANA-MAU-MIB

     ianaMauMIB MODULE-IDENTITY
       [ ... ]
       ::= { mib-2 snmpDot3MauMgt(26) 7 } -- mauMod+1

     dot3MauType OBJECT IDENTIFIER ::= { mib-2 snmpDot3MauMgt(26) 4 }

while the MAU-MIB contains the following definition:

      snmpDot3MauMgt OBJECT IDENTIFIER ::= { mib-2 26 }

In point of fact, only the last of these constructs constitutes a
definition for the descriptor 'snmpDot3MauMgt'.  In the first two
constructs 'snmpDot3MauMgt(26)' has exactly the same meaning as
would '26' ... in other words, the label snmpDot3MauMgt has the
status of a comment in those contexts.  So these warnings are
spurious and should be ignored.

rfc3636bis.mi2:20: [4] {module-identity-registration} warning: uncontrolled MODULE-IDENTITY registration

This warning has been issued because the MODULE-IDENTITY value is
registered below snmpDot3MauMgt OBJECT IDENTIFIER ::= { mib-2 26 }
instead of being registered under a node that is directly controlled
by the IANA.  The hazard is that future maintenance activities on
the MIB modules might lead to duplicate OID assignments if the
maintainers are not careful.

At my request, the WG has put an ASN.1 comment into the MAU-MIB to
remind maintainers that { snmpDot3MauMgt 6 } is the MODULE-IDENTITY
value for that MIB module, and I believe that this measure is
adequate to mitigate the hazard.

rfc3636bis.mi2:173: [5] {index-element-accessible} warning: index element `rpMauGroupIndex' of row `rpMauEntry' should be not-accessible in SMIv2 MIB
rfc3636bis.mi2:173: [5] {index-element-accessible} warning: index element `rpMauPortIndex' of row `rpMauEntry' should be not-accessible in SMIv2 MIB
rfc3636bis.mi2:173: [5] {index-element-accessible} warning: index element `rpMauIndex' of row `rpMauEntry' should be not-accessible in SMIv2 MIB
rfc3636bis.mi2:482: [5] {index-element-accessible} warning: index element `ifMauIfIndex' of row `ifMauEntry' should be not-accessible in SMIv2 MIB
rfc3636bis.mi2:482: [5] {index-element-accessible} warning: index element `ifMauIndex' of row `ifMauEntry' should be not-accessible in SMIv2 MIB
rfc3636bis.mi2:1253: [5] {index-element-accessible} warning: index element `broadMauIfIndex' of row `broadMauBasicEntry' should be not-accessible in SMIv2 MIB
rfc3636bis.mi2:1253: [5] {index-element-accessible} warning: index element `broadMauIndex' of row `broadMauBasicEntry' should be not-accessible in SMIv2 MIB

The above warnings are issued because the indicated INDEX elements
have a MAX-ACCESS value of read-only instead of not-accessible.  In
each case the reason why the access value is read-only is because
the object was originally defined in an SMIv1 MIB module (see RFC
1515), and SMIv1 rules did not require (or even allow) such objects
to have an access value of not-accessible.  SInce SMI revision rules
do not allow downgrading from read-only to not-accessible, these
access values remain read-only.  There are ASN.1 comments for all
these objects that note this fact.  So these warnings are all OK.

(c) From the smidiff report for MAU-MIB:

rfc3636bis.mi2:20 [5] {contact-changed} warning: contact of `MAU-MIB' changed
rfc3636bis.mi2:20 [5] {description-changed} warning: description of module identity definition `MAU-MIB' changed
rfc3636bis.mi2:67 [5] {revision-added} warning: revision `2006-07-25 00:00' added
/usr/local/share/mibs/ietf/MAU-MIB:15 [6] {previous-definition} info: previous definition of `MAU-MIB'

These are routine changes that are normally made when updating a MIB
module.

rfc3636bis.mi2:114 [5] {status-change} warning: legal status change from `current' to `deprecated' for `JackType'
rfc3636bis.mi2:114 [5] {description-changed} warning: description of textual convention definition `JackType' changed
/usr/local/share/mibs/ietf/MAU-MIB:107 [6] {previous-definition} info: previous definition of `JackType'

As noted in Section 3.5.5 of the draft and in the DESCRIPTION
clause, the JackType TC has been deprecated in favor of the
IANAifJackType TC.  The old definition remains in place, as required
by STD 58 and BCP 111, in order to maintain backward compatibility
with MIB modules that might reference it in an IMPORTS clause.

rfc3636bis.mi2:199 [5] {ref-changed} warning: reference of `rpMauGroupIndex' changed
/usr/local/share/mibs/ietf/MAU-MIB:466 [6] {previous-definition} info: previous definition of `rpMauGroupIndex'
rfc3636bis.mi2:220 [5] {ref-changed} warning: reference of `rpMauPortIndex' changed
/usr/local/share/mibs/ietf/MAU-MIB:487 [6] {previous-definition} info: previous definition of `rpMauPortIndex'

These are routine changes that are often made when updating a MIB
module.

rfc3636bis.mi2:243 [5] {description-changed} warning: description of object definition `rpMauType' changed
/usr/local/share/mibs/ietf/MAU-MIB:513 [6] {previous-definition} info: previous definition of `rpMauType'

The DESCRIPTION clause of this object was changed to reflect the
fact that the OBJECT-IDENTITY definitions for standard MAU types now
reside in the IANA-MAU-MIB instead of the MAU-MIB.

rfc3636bis.mi2:318 [5] {from-implicit} warning: type `IANAifMauMediaAvailable' replaces implicit type for `rpMauMediaAvailable'
/usr/local/share/mibs/ietf/MAU-MIB:599 [6] {previous-definition} info: previous definition of `rpMauMediaAvailable'
rfc3636bis.mi2:318 [5] {named-number-added} warning: named number `pmdLinkFault' added to type used in `rpMauMediaAvailable'
rfc3636bis.mi2:318 [5] {named-number-added} warning: named number `wisFrameLoss' added to type used in `rpMauMediaAvailable'
rfc3636bis.mi2:318 [5] {named-number-added} warning: named number `wisSignalLoss' added to type used in `rpMauMediaAvailable'
rfc3636bis.mi2:318 [5] {named-number-added} warning: named number `pcsLinkFault' added to type used in `rpMauMediaAvailable'
rfc3636bis.mi2:318 [5] {named-number-added} warning: named number `excessiveBER' added to type used in `rpMauMediaAvailable'
rfc3636bis.mi2:318 [5] {named-number-added} warning: named number `dxsLinkFault' added to type used in `rpMauMediaAvailable'
rfc3636bis.mi2:318 [5] {named-number-added} warning: named number `pxsLinkFault' added to type used in `rpMauMediaAvailable'
rfc3636bis.mi2:318 [5] {named-number-added} warning: named number `availableReduced' added to type used in `rpMauMediaAvailable'
rfc3636bis.mi2:318 [5] {named-number-added} warning: named number `ready' added to type used in `rpMauMediaAvailable'
rfc3636bis.mi2:318 [5] {description-changed} warning: description of object definition `rpMauMediaAvailable' changed
/usr/local/share/mibs/ietf/MAU-MIB:599 [6] {previous-definition} info: previous definition of `rpMauMediaAvailable'

These diagnostics result from changing the SYNTAX value of
rpMauMediaAvailable from enumerated INTEGER to
IANAifMauMediaAvailable. The extra values come in because the TC
contains all the values needed for ifMauMediaAvailable, and the
definition of rpMauMediaAvailable in RFC 3636 left out some values
that did not apply to repeaters.  I think that this change is OK,
since it does not change semantics (the object is read-only) and
makes maintenance much easier.

rfc3636bis.mi2:462 [5] {named-number-added} warning: named number `cx4' added to type used in `rpJackType'

This diagnostic results from changing the SYNTAX value of rpJackType
from JackType to IANAifJackType, which has the new value cx4 added,
as required to support 10GBASE-CX4. Although the cx4 jack type does
not apply to repeaters, I think that this change is OK, since it
does not change semantics (the object is read-only) and makes
maintenance much easier.

rfc3636bis.mi2:533 [5] {description-changed} warning: description of object definition `ifMauType' changed
/usr/local/share/mibs/ietf/MAU-MIB:908 [6] {previous-definition} info: previous definition of `ifMauType'

The DESCRIPTION clause of this object was changed to reflect the
fact that the OBJECT-IDENTITY definitions for standard MAU types now
reside in the IANA-MAU-MIB instead of the MAU-MIB.

rfc3636bis.mi2:617 [5] {from-implicit} warning: type `IANAifMauMediaAvailable' replaces implicit type for `ifMauMediaAvailable'
/usr/local/share/mibs/ietf/MAU-MIB:1003 [6] {previous-definition} info: previous definition of `ifMauMediaAvailable'
rfc3636bis.mi2:617 [5] {named-number-added} warning: named number `availableReduced' added to type used in `ifMauMediaAvailable'
rfc3636bis.mi2:617 [5] {named-number-added} warning: named number `ready' added to type used in `ifMauMediaAvailable'
rfc3636bis.mi2:617 [5] {description-changed} warning: description of object definition `ifMauMediaAvailable' changed
/usr/local/share/mibs/ietf/MAU-MIB:1003 [6] {previous-definition} info: previous definition of `ifMauMediaAvailable'

These diagnostics result from changing the SYNTAX value of
ifMauMediaAvailable from enumerated INTEGER to
IANAifMauMediaAvailable.  The additional values come in because the
new TC contains values needed to support Ethernet in the First Mile.

rfc3636bis.mi2:822 [5] {from-implicit} warning: type `IANAifMauTypeListBits' replaces implicit type for `ifMauTypeListBits'
/usr/local/share/mibs/ietf/MAU-MIB:1337 [6] {previous-definition} info: previous definition of `ifMauTypeListBits'
rfc3636bis.mi2:822 [3] {named-bit-added-old-byte} named bit `b10GbaseCX4' added without starting in a new byte in type used in `ifMauTypeListBits'
rfc3636bis.mi2:822 [3] {named-bit-added-old-byte} named bit `b2BaseTL' added without starting in a new byte in type used in `ifMauTypeListBits'
rfc3636bis.mi2:822 [3] {named-bit-added-old-byte} named bit `b10PassTS' added without starting in a new byte in type used in `ifMauTypeListBits'
rfc3636bis.mi2:822 [3] {named-bit-added-old-byte} named bit `b100BaseBX10D' added without starting in a new byte in type used in `ifMauTypeListBits'
rfc3636bis.mi2:822 [3] {named-bit-added-old-byte} named bit `b100BaseBX10U' added without starting in a new byte in type used in `ifMauTypeListBits'
rfc3636bis.mi2:822 [3] {named-bit-added-old-byte} named bit `b100BaseLX10' added without starting in a new byte in type used in `ifMauTypeListBits'
rfc3636bis.mi2:822 [3] {named-bit-added-old-byte} named bit `b1000BaseBX10D' added without starting in a new byte in type used in `ifMauTypeListBits'
rfc3636bis.mi2:822 [5] {named-number-added} warning: named number `b1000BaseBX10U' added to type used in `ifMauTypeListBits'
rfc3636bis.mi2:822 [5] {named-number-added} warning: named number `b1000BaseLX10' added to type used in `ifMauTypeListBits'
rfc3636bis.mi2:822 [5] {named-number-added} warning: named number `b1000BasePX10D' added to type used in `ifMauTypeListBits'
rfc3636bis.mi2:822 [5] {named-number-added} warning: named number `b1000BasePX10U' added to type used in `ifMauTypeListBits'
rfc3636bis.mi2:822 [5] {named-number-added} warning: named number `b1000BasePX20D' added to type used in `ifMauTypeListBits'
rfc3636bis.mi2:822 [5] {named-number-added} warning: named number `b1000BasePX20U' added to type used in `ifMauTypeListBits'
rfc3636bis.mi2:822 [5] {description-changed} warning: description of object definition `ifMauTypeListBits' changed
/usr/local/share/mibs/ietf/MAU-MIB:1337 [6] {previous-definition} info: previous definition of `ifMauTypeListBits'

These diagnostics result from changing the SYNTAX value of
ifMauTypeListBits from the explicit BITS type used in RFC 3636 to
IANAifMauTypeListBits, which contains enumerated bits to represent
the thirteen MAU types added since RFC 3636 was published.

Although smilint seems to insist that it is an error for bit
positions to be added without starting a new byte, there is no
reason to do so in this case.  If a management application retrieves
ifMauTypeListBits from an implementation based on the RFC 3636
version of the MAU-MIB, then the bit positions that correspond to
b10GbaseCX4, b2BaseTL, b10PassTS, b100BaseBX10D, b100BaseBX10U,
b100BaseLX10, and b1000BaseBX10D will be set to zero, which
indicates that the agent does not support those MAU types.  Since
this is in fact semantically correct, starting a new byte for the
new values is unnecessary.

rfc3636bis.mi2:903 [5] {named-number-added} warning: named number `cx4' added to type used in `ifJackType'

This diagnostic results from changing the SYNTAX value of ifJackType
from JackType to IANAifJackType, which has the new value cx4 added,
as required to support 10GBASE-CX4.

rfc3636bis.mi2:1275 [5] {ref-changed} warning: reference of `broadMauIfIndex' changed
/usr/local/share/mibs/ietf/MAU-MIB:1934 [6] {previous-definition} info: previous definition of `broadMauIfIndex'

This is a routine change that is often made when updating a MIB
module.

/usr/local/share/mibs/ietf/MAU-MIB:145 [1] {node-removed} node `dot3MauType' has been deleted
/usr/local/share/mibs/ietf/MAU-MIB:147 [1] {node-removed} node `dot3MauTypeAUI' has been deleted
/usr/local/share/mibs/ietf/MAU-MIB:153 [1] {node-removed} node `dot3MauType10Base5' has been deleted
/usr/local/share/mibs/ietf/MAU-MIB:159 [1] {node-removed} node `dot3MauTypeFoirl' has been deleted
/usr/local/share/mibs/ietf/MAU-MIB:165 [1] {node-removed} node `dot3MauType10Base2' has been deleted
/usr/local/share/mibs/ietf/MAU-MIB:171 [1] {node-removed} node `dot3MauType10BaseT' has been deleted
/usr/local/share/mibs/ietf/MAU-MIB:185 [1] {node-removed} node `dot3MauType10BaseFP' has been deleted
/usr/local/share/mibs/ietf/MAU-MIB:191 [1] {node-removed} node `dot3MauType10BaseFB' has been deleted
/usr/local/share/mibs/ietf/MAU-MIB:197 [1] {node-removed} node `dot3MauType10BaseFL' has been deleted
/usr/local/share/mibs/ietf/MAU-MIB:209 [1] {node-removed} node `dot3MauType10Broad36' has been deleted
/usr/local/share/mibs/ietf/MAU-MIB:218 [1] {node-removed} node `dot3MauType10BaseTHD' has been deleted
/usr/local/share/mibs/ietf/MAU-MIB:224 [1] {node-removed} node `dot3MauType10BaseTFD' has been deleted
/usr/local/share/mibs/ietf/MAU-MIB:230 [1] {node-removed} node `dot3MauType10BaseFLHD' has been deleted
/usr/local/share/mibs/ietf/MAU-MIB:239 [1] {node-removed} node `dot3MauType10BaseFLFD' has been deleted
/usr/local/share/mibs/ietf/MAU-MIB:245 [1] {node-removed} node `dot3MauType100BaseT4' has been deleted
/usr/local/share/mibs/ietf/MAU-MIB:251 [1] {node-removed} node `dot3MauType100BaseTXHD' has been deleted
/usr/local/share/mibs/ietf/MAU-MIB:257 [1] {node-removed} node `dot3MauType100BaseTXFD' has been deleted
/usr/local/share/mibs/ietf/MAU-MIB:263 [1] {node-removed} node `dot3MauType100BaseFXHD' has been deleted
/usr/local/share/mibs/ietf/MAU-MIB:269 [1] {node-removed} node `dot3MauType100BaseFXFD' has been deleted
/usr/local/share/mibs/ietf/MAU-MIB:275 [1] {node-removed} node `dot3MauType100BaseT2HD' has been deleted
/usr/local/share/mibs/ietf/MAU-MIB:281 [1] {node-removed} node `dot3MauType100BaseT2FD' has been deleted
/usr/local/share/mibs/ietf/MAU-MIB:292 [1] {node-removed} node `dot3MauType1000BaseXHD' has been deleted
/usr/local/share/mibs/ietf/MAU-MIB:298 [1] {node-removed} node `dot3MauType1000BaseXFD' has been deleted
/usr/local/share/mibs/ietf/MAU-MIB:304 [1] {node-removed} node `dot3MauType1000BaseLXHD' has been deleted
/usr/local/share/mibs/ietf/MAU-MIB:311 [1] {node-removed} node `dot3MauType1000BaseLXFD' has been deleted
/usr/local/share/mibs/ietf/MAU-MIB:318 [1] {node-removed} node `dot3MauType1000BaseSXHD' has been deleted
/usr/local/share/mibs/ietf/MAU-MIB:325 [1] {node-removed} node `dot3MauType1000BaseSXFD' has been deleted
/usr/local/share/mibs/ietf/MAU-MIB:332 [1] {node-removed} node `dot3MauType1000BaseCXHD' has been deleted
/usr/local/share/mibs/ietf/MAU-MIB:342 [1] {node-removed} node `dot3MauType1000BaseCXFD' has been deleted
/usr/local/share/mibs/ietf/MAU-MIB:349 [1] {node-removed} node `dot3MauType1000BaseTHD' has been deleted
/usr/local/share/mibs/ietf/MAU-MIB:355 [1] {node-removed} node `dot3MauType1000BaseTFD' has been deleted
/usr/local/share/mibs/ietf/MAU-MIB:363 [1] {node-removed} node `dot3MauType10GigBaseX' has been deleted
/usr/local/share/mibs/ietf/MAU-MIB:369 [1] {node-removed} node `dot3MauType10GigBaseLX4' has been deleted
/usr/local/share/mibs/ietf/MAU-MIB:375 [1] {node-removed} node `dot3MauType10GigBaseR' has been deleted
/usr/local/share/mibs/ietf/MAU-MIB:381 [1] {node-removed} node `dot3MauType10GigBaseER' has been deleted
/usr/local/share/mibs/ietf/MAU-MIB:389 [1] {node-removed} node `dot3MauType10GigBaseLR' has been deleted
/usr/local/share/mibs/ietf/MAU-MIB:395 [1] {node-removed} node `dot3MauType10GigBaseSR' has been deleted
/usr/local/share/mibs/ietf/MAU-MIB:401 [1] {node-removed} node `dot3MauType10GigBaseW' has been deleted
/usr/local/share/mibs/ietf/MAU-MIB:407 [1] {node-removed} node `dot3MauType10GigBaseEW' has been deleted
/usr/local/share/mibs/ietf/MAU-MIB:413 [1] {node-removed} node `dot3MauType10GigBaseLW' has been deleted
/usr/local/share/mibs/ietf/MAU-MIB:419 [1] {node-removed} node `dot3MauType10GigBaseSW' has been deleted

The above diagnostics result from moving the MAU type
OBJECT-IDENTITY definitions out of the MAU-MIB and into the
IANA-MAU-MIB.  Both the motivation for and the ramifications of
these changes are clearly explained in the last paragraph of Section
3.1 of the draft (pp. 4 and 5).  In my opinion the WG's judgment
call on this matter is a reasonable one, and I think that it should
be respected.  This was also the rough consensus from a discussion
of this point on the MIB Doctors mailing list.

rfc3636bis.mi2:1136 [5] {from-implicit} warning: type `IANAifMauAutoNegCapBits' replaces implicit type for `ifMauAutoNegCapabilityBits'
/usr/local/share/mibs/ietf/MAU-MIB:1721 [6] {previous-definition} info: previous definition of `ifMauAutoNegCapabilityBits'
rfc3636bis.mi2:1136 [5] {named-number-changed} warning: named number `bfdxPause' changed to `bFdxPause' at type used in `ifMauAutoNegCapabilityBits'
rfc3636bis.mi2:1136 [5] {named-number-changed} warning: named number `bfdxAPause' changed to `bFdxAPause' at type used in `ifMauAutoNegCapabilityBits'
rfc3636bis.mi2:1136 [5] {named-number-changed} warning: named number `bfdxSPause' changed to `bFdxSPause' at type used in `ifMauAutoNegCapabilityBits'
rfc3636bis.mi2:1136 [5] {named-number-changed} warning: named number `bfdxBPause' changed to `bFdxBPause' at type used in `ifMauAutoNegCapabilityBits'
rfc3636bis.mi2:1136 [5] {description-changed} warning: description of object definition `ifMauAutoNegCapabilityBits' changed
/usr/local/share/mibs/ietf/MAU-MIB:1721 [6] {previous-definition} info: previous definition of `ifMauAutoNegCapabilityBits'

These diagnostics result from changing the SYNTAX value for
ifMauAutoNegCapabilityBits from the explicit BITS type used in RFC
3636 to IANAifMauAutoNegCapBits.  The change of spelling in the
labels results from the fact that in RFC 3636 the SYNTAX clause for
fMauAutoNegCapabilityBits used the spellings bfdxPause, bfdxAPause,
bfdxSPause, and bfdxBPause, while the SYNTAX clauses for
ifMauAutoNegCapAdvertisedBits and ifMauAutoNegCapReceivedBits used
the spellings bFdxPause, bFdxAPause, bFdxSPause, and bFdxBPause,
respectively.  In order to minimize both the amount of work and the
likelihood of error when adding support for new autonegotiation
capabilities, it is highly desirable to use a common TC for all of
these objects, which after all have the same underlying sets of
values.  Changing the named bit labels for
ifMauAutoNegCapabilityBits may cause some compilation compatibility
problems with various tools, but in its discussion the WG concluded
that the maintenance issue trumps this consideration.  I think that
the WG's judgment call is reasonable and urge that it be respected.

rfc3636bis.mi2:1157 [5] {from-implicit} warning: type `IANAifMauAutoNegCapBits' replaces implicit type for `ifMauAutoNegCapAdvertisedBits'
/usr/local/share/mibs/ietf/MAU-MIB:1762 [6] {previous-definition} info: previous definition of `ifMauAutoNegCapAdvertisedBits'
rfc3636bis.mi2:1157 [5] {description-changed} warning: description of object definition `ifMauAutoNegCapAdvertisedBits' changed
/usr/local/share/mibs/ietf/MAU-MIB:1762 [6] {previous-definition} info: previous definition of `ifMauAutoNegCapAdvertisedBits'

These diagnostics result from changing the SYNTAX value for
ifMauAutoNegCapAdvertisedBits from the explicit BITS type used in
RFC 3636 to IANAifMauAutoNegCapBits.

rfc3636bis.mi2:1179 [5] {from-implicit} warning: type `IANAifMauAutoNegCapBits' replaces implicit type for `ifMauAutoNegCapReceivedBits'
/usr/local/share/mibs/ietf/MAU-MIB:1808 [6] {previous-definition} info: previous definition of `ifMauAutoNegCapReceivedBits'
rfc3636bis.mi2:1179 [5] {description-changed} warning: description of object definition `ifMauAutoNegCapReceivedBits' changed
/usr/local/share/mibs/ietf/MAU-MIB:1808 [6] {previous-definition} info: previous definition of `ifMauAutoNegCapReceivedBits'

These diagnostics result from changing the SYNTAX value for
ifMauAutoNegCapReceivedBits from the explicit BITS type used in RFC
3636 to IANAifMauAutoNegCapBits.

NOTE: although no new autonegotiation capabilities were instroduced
in this draft, the comments made above for IANAifMauTypeListBits
stating that new bit positions need not start on a new byte applies
also to IANAifMauAutoNegCapBits.  There is never an ambiguity for
the read-only objects ifMauAutoNegCapabilityBits and
ifMauAutoNegCapReceivedBits, and a management station can always
update ifMauAutoNegCapAdvertisedBits by retrieving the value of
ifMauAutoNegCapabilityBits, resetting bits in the returned value
that correspond to capabilities that should not be advertised, and
then writing the result to ifMauAutoNegCapAdvertisedBits.

rfc3636bis.mi2:1356 [5] {ref-changed} warning: reference of `rpMauJabberTrap' changed
/usr/local/share/mibs/ietf/MAU-MIB:2021 [6] {previous-definition} info: previous definition of `rpMauJabberTrap'
rfc3636bis.mi2:1369 [5] {ref-changed} warning: reference of `ifMauJabberTrap' changed
/usr/local/share/mibs/ietf/MAU-MIB:2034 [6] {previous-definition} info: previous definition of `ifMauJabberTrap'

These are routine changes that are often made when updating a MIB
module.

This concludes the MIB Doctor review of
draft-ietf-hubmib-rfc3636bis-05.txt

Thanks & regards,

Mike Heard

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