RE: WGLC -http://www.ietf.org/internet-drafts/draft-ietf-hubmib-rfc3636bis-03.txt

"Edward Beili" <[email protected]> Sat, 17 Jun 2006 23:22:23 +0300
Newsgroups gmane.ietf.hubmib
Message-ID <[email protected]>
Mike,
Thanks for such a quick and thorough review.

About the changes to the enum labels in IANAifMauAutoNegCapBits - in the original RFC 3636, the labels for the bit values of ifMauAutoNegCapabilityBits, ifMauAutoNegCapAdvertisedBits and ifMauAutoNegCapReceivedBits objects are all the same, with the exception of 4 labels: bFdxPause(8), bFdxAPause(9), bFdxSPause(10), bFdxBPause(11). These labels have a capital 'F' in ifMauAutoNegCapAdvertisedBits and ifMauAutoNegCapReceivedBits objects, while having a small 'f' in ifMauAutoNegCapReceivedBits. Since all the other labels are exactly the same with the same meaning, I have assumed this to be a typo in the original rfc3636 and fixed it by defining a single IANAifMauAutoNegCapBits TC, common to all the ifMauAutoNegCap*Bits objects.
I just looked in the RFC 4181, it allows for the names of the named numbers and named bits to be changed to correct typographical errors, which I believe is the case here.

Regards,
-E.


-----Original Message-----
From: C. M. Heard [mailto:[email protected]] 
Sent: Tuesday, June 13, 2006 8:44
To: Hub Mib
Subject: Re: [Hubmib] WGLC -http://www.ietf.org/internet-drafts/draft-ietf-hubmib-rfc3636bis-03.txt

>>>>> On Thu, 8 Jun 2006, Dan Romascanu wrote:
Dan> This is a Working Group Last Call announcement for the 'Definitions 
Dan> of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)' 
Dan> 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 concerns 
Dan> or issues with this draft by sending a mail at hubmib at ietf.org 
Dan> 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 In 
Edward> addition a clarification was added to 'pmdLinkFault' that all 
Edward> 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