Subject: [MIB-DOCTORS] RE: Compilation compatibility with draft-ietf-hubmib-rfc3636bis-05 (fwd)

From: "C. M. Heard" <[email-masked]>
Date: Tue, 5 Sep 2006 12:48:07 -0700 (PDT)

MIB Doctors,

The attached e-mail messages document a case where changing named
bit labels broke someone's application.  I've sent these along to
provide background on a message to follow.

Mike Heard

Subject: RE: Compilation compatibiltiy with draft-ietf-hubmib-rfc3636bis-05
From: "Edward Beili" <[email-masked]>
To: <[email-masked]>
Cc: "IETF Hub MIB Working Group" <[email-masked]>, "C. M. Heard" <[email-masked]>
Date: Mon, 4 Sep 2006 02:01:47 +0300

Clay,
 
Here is the last email on that subject, explaining the reasoning and justification for this change.
Regards,
-E.

-----Original Message-----

From: C. M. Heard [mailto:[email-masked] <mailto:[email-masked]> ] 

Sent: Sunday, June 18, 2006 19:29

To: Edward Beili

Cc: Hub Mib

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

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

  _____  

From: Clay Sikes [mailto:[email-masked]] 
Sent: Friday, September 01, 2006 17:24
To: Edward Beili
Cc: IETF Hub MIB Working Group; C. M. Heard
Subject: Compilation compatibiltiy with draft-ietf-hubmib-rfc3636bis-05

Hi Edward,

First, thanks for all the editor work you are doing on the MIB modules.

I attempted to update an implementation of the MAU-MIB from RFC 2668 to that which is specified in this ID and ran into a compilation compatibility issue.  An update from RFC 2668 to RFC 3636 does not have this compilation compatibility issue.

In this ID, the ifMauAutoNegCapabilityBits, ifMauAutoNegCapAdvertisedBits, and ifMauAutoNegCapReceivedBits have their syntax changed to use the IANAifMauAutoNegCapBits TC.  I strongly support this change.  However, RFC 2668 and RFC 3636 have different labels for the following named bits for the ifMauAutoNegCapabilityBits object's syntax:

1.	Bit 8  -- 2668/3636 bfdxPause(8), this ID bFdxPause(8) 
2.	Bit 9  -- 2668/3636 bfdxAPause(9), this ID bFdxAPause(9) 
3.	Bit 10 -- 2668/3636 bfdxSPause(10), this ID bFdxSPause(10) 
4.	Bit 11 -- 2668/3636 bfdxBPause(11), this ID bFdxBPause(11) 

Compilation of the ID fails because some these labels changed from 2668/3636 to this ID.

Although the RFC 2578 Section 10.2 allows the labels of named bits to change, this is generally not a good idea.  In the case of this ID, "over the wire" operation is not effected, but compilation compatibility has been broken.  Please refer to RFC 4181 Section 4.9 top of page 29 for a discussion on changing labels for named bits.

Given the fact that back in RFC 2668 ifMauAutoNegCapabilityBits have different labels for bits 8 through 11 then ifMauAutoNegCapAdvertisedBits and ifMauAutoNegCapReceivedBits, it would seem like there needs to be a different TC in the proposed IANA-MAU-MIB for ifMauAutoNegCapabilityBits to use then what ifMauAutoNegCapAdvertisedBits and ifMauAutoNegCapReceivedBits use to maintain compilation compatibility.

I hope this has not already been discussed.  I did a quick glance in the list and didn't see anything.

Thoughts?

Best Regards,
Clay Sikes

Subject: Re: Compilation compatibiltiy with draft-ietf-hubmib-rfc3636bis-05
From: "Clay Sikes" <[email-masked]>
To: Edward Beili <[email-masked]>
Cc: [email-masked], IETF Hub MIB Working Group <[email-masked]>, "C. M. Heard" <[email-masked]>
Date: Tue, 05 Sep 2006 10:57:20 -0400

Edward,

Wow!  I'm extremely surprised that correcting a typo and breaking
compilation compatibility is ok.

- Clay

On 9/3/2006 7:01 PM, Edward Beili wrote:

Clay,

Here is the last email on that
subject, explaining the reasoning and justification for this change.

Regards,

-E.

-----Original Message-----

From: C. M. Heard [mailto:[email-masked]]

Sent: Sunday, June 18, 2006 19:29

To: Edward Beili

Cc: Hub Mib

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

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

From: Clay
Sikes [mailto:[email-masked]]

Sent: Friday, September 01, 2006 17:24

To: Edward Beili

Cc: IETF Hub MIB Working Group; C. M. Heard

Subject: Compilation compatibiltiy with
draft-ietf-hubmib-rfc3636bis-05

Hi Edward,

First, thanks for all the editor work you are doing on the MIB modules.

I attempted to update an implementation of the MAU-MIB from RFC 2668 to
that which is specified in this ID and ran into a compilation
compatibility issue.  An update from RFC 2668 to RFC 3636 does not have
this compilation compatibility issue.

In this ID, the ifMauAutoNegCapabilityBits,
ifMauAutoNegCapAdvertisedBits, and ifMauAutoNegCapReceivedBits have
their syntax changed to use the IANAifMauAutoNegCapBits TC.  I strongly
support this change.  However, RFC 2668 and RFC 3636 have different
labels for the following named bits for the ifMauAutoNegCapabilityBits
object's syntax:

Bit 8  -- 2668/3636 bfdxPause(8),
this ID bFdxPause(8)

Bit 9  -- 2668/3636 bfdxAPause(9),
this ID bFdxAPause(9)

Bit 10 -- 2668/3636 bfdxSPause(10),
this ID bFdxSPause(10)

Bit 11 -- 2668/3636 bfdxBPause(11),
this ID bFdxBPause(11)

Compilation of the ID fails because some these labels changed from
2668/3636 to this ID.

Although the RFC 2578 Section 10.2 allows the labels of named bits to
change, this is generally not a good idea.  In the case of this ID,
"over the wire" operation is not effected, but compilation
compatibility has been broken.  Please refer to RFC 4181 Section 4.9
top of page 29 for a discussion on changing labels for named bits.

Given the fact that back in RFC 2668 ifMauAutoNegCapabilityBits have
different labels for bits 8 through 11 then
ifMauAutoNegCapAdvertisedBits and ifMauAutoNegCapReceivedBits, it would
seem like there needs to be a different TC in the proposed IANA-MAU-MIB
for ifMauAutoNegCapabilityBits to use then what
ifMauAutoNegCapAdvertisedBits and ifMauAutoNegCapReceivedBits use to
maintain compilation compatibility.

I hope this has not already been discussed.  I did a quick glance in
the list and didn't see anything.

Thoughts?

Best Regards,

Clay Sikes

Subject: Re: Compilation compatibiltiy with draft-ietf-hubmib-rfc3636bis-05
From: "C. M. Heard" <[email-masked]>
To: Clay Sikes <[email-masked]>
Cc: Edward Beili <[email-masked]>, IETF Hub MIB Working Group <[email-masked]>
Date: Tue, 5 Sep 2006 11:54:42 -0700 (PDT)

On Tue, 5 Sep 2006, Clay Sikes wrote:
> Wow!  I'm extremely surprised that correcting a typo and breaking
> compilation compatibility is ok. 

Clay,

Here is the relevant excerpt from the MIB review guidelines --
specifically, RFC 4181 Section 4.9:

   RFC 2578 Section 10.2 specifies rules that apply to revisions of
   object definitions.  The following guidelines correct some errors in
   these rules and provide some clarifications:

   - Bullet (1) allows the labels of named numbers and named bits in
     SYNTAX clauses of type enumerated INTEGER or BITS to be changed.
     This can break compilation compatibility, since those labels may be
     used by DEFVAL clauses in modules that import the definitions of
     the affected objects.  Therefore, labels of named numbers and named
     bits MUST NOT be changed when revising IETF MIB modules (except to
     correct typographical errors), and they SHOULD NOT be changed when
     revising enterprise MIB modules.

The only potential compilation problem of which I am aware would
arise when a module containing an AGENT-CAPABILITIES definition
references ifMauAutoNegCapabilityBits in a VARIATION clause and
provides a DEFVAL for it.  Have you actually seen this problem?  Or
is there perhaps another problem of which the MIB Doctors were not
aware when they discussed this part of RFC 4181?

Thanks

Mike Heard

> __________________________________________________________________
> 
> From: Clay Sikes [mailto:[email-masked]]
> Sent: Friday, September 01, 2006 17:24
> To: Edward Beili
> Cc: IETF Hub MIB Working Group; C. M. Heard
> Subject: Compilation compatibiltiy with
> draft-ietf-hubmib-rfc3636bis-05
> 
>       Hi Edward,
> 
>       First, thanks for all the editor work you are doing on the
>       MIB modules.
> 
>       I attempted to update an implementation of the MAU-MIB from
>       RFC 2668 to that which is specified in this ID and ran into a
>       compilation compatibility issue.  An update from RFC 2668 to
>       RFC 3636 does not have this compilation compatibility issue.
> 
>       In this ID, the ifMauAutoNegCapabilityBits,
>       ifMauAutoNegCapAdvertisedBits, and
>       ifMauAutoNegCapReceivedBits have their syntax changed to use
>       the IANAifMauAutoNegCapBits TC.  I strongly support this
>       change.  However, RFC 2668 and RFC 3636 have different labels
>       for the following named bits for the
>       ifMauAutoNegCapabilityBits object's syntax:
>        1. Bit 8  -- 2668/3636 bfdxPause(8), this ID bFdxPause(8)
>        2. Bit 9  -- 2668/3636 bfdxAPause(9), this ID bFdxAPause(9)
>        3. Bit 10 -- 2668/3636 bfdxSPause(10), this ID
>           bFdxSPause(10)
>        4. Bit 11 -- 2668/3636 bfdxBPause(11), this ID
>           bFdxBPause(11)
>       Compilation of the ID fails because some these labels changed
>       from 2668/3636 to this ID.
> 
>       Although the RFC 2578 Section 10.2 allows the labels of named
>       bits to change, this is generally not a good idea.  In the
>       case of this ID, "over the wire" operation is not effected,
>       but compilation compatibility has been broken.  Please refer
>       to RFC 4181 Section 4.9 top of page 29 for a discussion on
>       changing labels for named bits.
> 
>       Given the fact that back in RFC 2668
>       ifMauAutoNegCapabilityBits have different labels for bits 8
>       through 11 then ifMauAutoNegCapAdvertisedBits and
>       ifMauAutoNegCapReceivedBits, it would seem like there needs
>       to be a different TC in the proposed IANA-MAU-MIB for
>       ifMauAutoNegCapabilityBits to use then what
>       ifMauAutoNegCapAdvertisedBits and ifMauAutoNegCapReceivedBits
>       use to maintain compilation compatibility.
> 
>       I hope this has not already been discussed.  I did a quick
>       glance in the list and didn't see anything.
> 
>       Thoughts?
> 
>       Best Regards,
>       Clay Sikes
_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mib-doctors