Re: WGLC - http://www.ietf.org/internet-drafts/draft-ietf-hubmib-rfc3636bis-03.txt
"C. M. Heard" <[email protected]> Mon, 12 Jun 2006 22:44:22 -0700 (PDT)
| Newsgroups | gmane.ietf.hubmib |
|---|---|
| Message-ID | <[email protected]> |
>>>>> On Thu, 8 Jun 2006, Dan Romascanu wrote:
Dan> This is a Working Group Last Call announcement for the
Dan> 'Definitions of Managed Objects for IEEE 802.3 Medium Attachment
Dan> Units (MAUs)' Internet-Draft -
Dan> http://www.ietf.org/internet-drafts/draft-ietf-hubmib-rfc3636bis-03.txt.
Dan> We plan to forward this I-D to the IESG for consideration as
Dan> Proposed Standard. Please let the WG know if there are any
Dan> concerns or issues with this draft by sending a mail at hubmib
Dan> at ietf.org before Thursday 22, 2006, COB.
With the exception of one thing that is noted below, I think this
document is ready to go. For the benefit of the WG, I have attached
reports from smilint on the two MIB modules in the document, and I
have also attached a report from smidiff on the differences between
the rfc3636bis MAU-MIB update and the current version in RFC 3636.
Here are the differences (ignoring line numbers) between the -02
smidiff report and the one that is attached:
*** MAU-MIB-smidiff-report-02.txt Sun Jun 11 08:43:06 2006
--- MAU-MIB-smidiff-report-03.txt Sun Jun 11 08:43:24 2006
***************
*** 6 ****
! The program smidiff 0.4.3, as of Thu Jun 23 10:41:27 2005
--- 6 ----
! The program smidiff 0.4.3, as of Mon May 15 15:53:48 2006
***************
*** 33 ****
! rfc3636bis.mib: [5] {revision-added} warning: revision `2005-10-24 00:00' added
--- 33 ----
! rfc3636bis.mib: [5] {revision-added} warning: revision `2006-06-04 00:00' added
***************
*** 39 ****
--- 40,52 ----
+ rfc3636bis.mib: [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.mib: [5] {named-number-added} warning: named number `pmdLinkFault' added to type used in `rpMauMediaAvailable'
+ rfc3636bis.mib: [5] {named-number-added} warning: named number `wisFrameLoss' added to type used in `rpMauMediaAvailable'
+ rfc3636bis.mib: [5] {named-number-added} warning: named number `wisSignalLoss' added to type used in `rpMauMediaAvailable'
+ rfc3636bis.mib: [5] {named-number-added} warning: named number `pcsLinkFault' added to type used in `rpMauMediaAvailable'
+ rfc3636bis.mib: [5] {named-number-added} warning: named number `excessiveBER' added to type used in `rpMauMediaAvailable'
+ rfc3636bis.mib: [5] {named-number-added} warning: named number `dxsLinkFault' added to type used in `rpMauMediaAvailable'
+ rfc3636bis.mib: [5] {named-number-added} warning: named number `pxsLinkFault' added to type used in `rpMauMediaAvailable'
+ rfc3636bis.mib: [5] {named-number-added} warning: named number `availableReduced' added to type used in `rpMauMediaAvailable'
+ rfc3636bis.mib: [5] {named-number-added} warning: named number `ready' added to type used in `rpMauMediaAvailable'
+ rfc3636bis.mib: [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'
The above reflects the result of 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.
***************
*** 42 ****
--- 56,61 ----
+ rfc3636bis.mib: [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.mib: [5] {named-number-added} warning: named number `availableReduced' added to type used in `ifMauMediaAvailable'
+ rfc3636bis.mib: [5] {named-number-added} warning: named number `ready' added to type used in `ifMauMediaAvailable'
+ rfc3636bis.mib: [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'
The above reflects the result of changing the SYNTAX value of
ifMauMediaAvailable from enumerated INTEGER to IANAifMauMediaAvailable.
The new values are those added by Edward. All OK, in my opinion.
***************
*** 101 ****
--- 121,136 ----
+ rfc3636bis.mib: [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.mib: [5] {named-number-changed} warning: named number `bfdxPause' changed to `bFdxPause' at type used in `ifMauAutoNegCapabilityBits'
+ rfc3636bis.mib: [5] {named-number-changed} warning: named number `bfdxAPause' changed to `bFdxAPause' at type used in `ifMauAutoNegCapabilityBits'
+ rfc3636bis.mib: [5] {named-number-changed} warning: named number `bfdxSPause' changed to `bFdxSPause' at type used in `ifMauAutoNegCapabilityBits'
+ rfc3636bis.mib: [5] {named-number-changed} warning: named number `bfdxBPause' changed to `bFdxBPause' at type used in `ifMauAutoNegCapabilityBits'
+ rfc3636bis.mib: [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'
+ rfc3636bis.mib: [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.mib: [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'
+ rfc3636bis.mib: [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.mib: [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'
The above reflects the result of changing the SYNTAX value of
ifMauAutoNegCapabilityBits from enumerated INTEGER to
IANAifMauAutoNegCapBits. This is all OK __except__ for
the changes to the enum labels. Such changes are contrary
to the advice in RFC 4181 Section 4.9. I recommend that a
new version of the document be spun before forwarding to
the IESG that rolls back those changes. Specifically, in
the definition of ifMauAutoNegCapabilityBit in the IANA-MAU-MIB:
s/bFdxPause/bfdxPause/
s/bFdxAPause/bfdxAPause/
s/bFdxSPause/bfdxSPause/
s/bFdxBPause/bfdxBPause/
>>>>> On Mon, 5 Jun 2006, Edward Beili wrote:
Edward> Here is the list of the changes between version -02 and -03:
Edward>
Edward> - Created new IANAifMauMediaAvailable, IANAifMauAutoNegCapBits
Edward> TCs in IANA-MAU-MIB and changed the syntax of
Edward> ifMauMediaAvailable / rpMauMediaAvailable,
Edward> ifMauAutoNegCapabilityBits / ifMauAutoNegCapAdvertisedBits /
Edward> ifMauAutoNegCapReceivedBits to use these new TCs.
Edward>
Edward> - In IANAifMauMediaAvailable, modify the text a bit to reflect
Edward> changes done in IEEE 802.3ah-2004, [and add] add two new values
Edward> defined in the 802.3ah, clause 30.5.1.1.4:
Edward> - availableReduced - link normal, reduced bandwidth,
Edward> applies only to 2BASE-TL and 10PASS-TS
Edward> - ready - at least one PME available, applies
Edward> only to 2BASE-TL and 10PASS-TS
Edward> In addition a clarification was added to 'pmdLinkFault' that
Edward> all PMA/PMDs in the aggregation group must detect a fault.
OK except as noted above.
Edward> - Note that I left ianaMauMIB and dot3MauType location as it was
Edward> in v02. Mike Heard in the past has suggested to move ianaMauMIB
Edward> under mib-2 (and subsequently dot3MauType under ianaMauMIB).
Since there are ASN.1 comments to clearly document the usage of the nodes
immediately subordinate to snmpDot3MauMgt, I am OK with this.
Thanks,
Mike Heard
_______________________________________________
Hubmib mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/hubmib
(unnamed)
(message/rfc822, 1.3 KB) - not displayed
(unnamed)
(message/rfc822, 2.7 KB) - not displayed
(unnamed)
(message/rfc822, 15.1 KB) - not displayed