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

From: "Edward Beili" <[email-masked]>
Date: Sat, 17 Jun 2006 23:22:23 +0300

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-masked]] 
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

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

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 18 Jun 2006 09:28:55 -0700 (PDT)

> Thanks for such a quick and thorough review.

Actually it wasn't terribly thorough but you are welcome anyway :-)

> 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.

Ah, I see what you mean -- ifMauAutoNegCapReceivedBits picks up
named bit label changes as a result of moving to the common
IANA-maintained TC for all of the auto-negotiation objects because
its bit labels were inconsistent with those for the other objects,
probably as the result of a typo.  That point escaped me because I
was not looking carefully at the MIB module, just at the smidiff
report.  I agree that the correct thing to do is to have a common TC
for all these objects and that the named bit labels you chose in the
-03 draft are the right ones.  So from my perspective this appears
to be ready to go to the IESG.

Mike