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

"C. M. Heard" <[email protected]> Sun, 18 Jun 2006 09:28:55 -0700 (PDT)
Newsgroups gmane.ietf.hubmib
Message-ID <[email protected]>
On Sat, 17 Jun 2006, Edward Beili wrote:
> 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