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

Mike,
Thank you for a very thorough review of the draft.

I would make 2 editorial changes you specified  (s/There is a number of/There are a number of/ and s/Management of IEEE 802.3 Managed Objects/Mapping of IEEE 802.3 Managed Objects) and submit and updated draft shortly.

David/Bert,
Anything else I should do?

Regards,
-E.

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]]On Behalf Of C. M. Heard
> Sent: Sunday, October 15, 2006 6:22 AM
> To: Hub Mib
> Cc: Romascanu, Dan (Dan); David Kessens
> Subject: [Hubmib] 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
>