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

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

MIB Doctors,

Here is an explanation of the problem that Clay Sikes had.  Given
that RFC 2578 and RFC 2579 have always allowed labels of named
numbers and named bits to be changed, one could make the case that
the problem is with the tool.  RFC 4181 advocates a more restrictive
policy than do the SMv2 documents, but the purpose was to avoid
problems with actual MIB module syntax and not with code generation
tools.  I'm not sure that it's our problem to worry about code
generation tools.

Comments?

Mike

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

Hi Mike,

Below is a snippet of what our MIB compiler generates for definitions
for our implementation of RFC 2668.   When I replace RFC 2668 with the
ID, the compiler failed because code used D_ifMauAutoNegCapabilityBits_bfdxPause,  D_ifMauAutoNegCapabilityBits_bfdxAPause,
D_ifMauAutoNegCapabilityBits_bfdxSPause,
and /or D_ifMauAutoNegCapabilityBits_bfdxBPause.

I have replace RFC 2668 with RFC 3636 and there are not compatibility
issues.

Since I have a definite compilation compatibility failure, then could
others face the same situation?  And if so, does this group really want
to create that kind of a situation?

/* enumerated values for ifMauAutoNegCapabilityBits */

#define D_ifMauAutoNegCapabilityBits_bOther 0

#define D_ifMauAutoNegCapabilityBits_b10baseT 1

#define D_ifMauAutoNegCapabilityBits_b10baseTFD 2

#define D_ifMauAutoNegCapabilityBits_b100baseT4 3

#define D_ifMauAutoNegCapabilityBits_b100baseTX 4

#define D_ifMauAutoNegCapabilityBits_b100baseTXFD 5

#define D_ifMauAutoNegCapabilityBits_b100baseT2 6

#define D_ifMauAutoNegCapabilityBits_b100baseT2FD 7

#define D_ifMauAutoNegCapabilityBits_bfdxPause
8

#define D_ifMauAutoNegCapabilityBits_bfdxAPause
9

#define D_ifMauAutoNegCapabilityBits_bfdxSPause
10

#define D_ifMauAutoNegCapabilityBits_bfdxBPause
11

#define D_ifMauAutoNegCapabilityBits_b1000baseX 12

#define D_ifMauAutoNegCapabilityBits_b1000baseXFD 13

#define D_ifMauAutoNegCapabilityBits_b1000baseT 14

#define D_ifMauAutoNegCapabilityBits_b1000baseTFD 15

/* enumerated values for ifMauAutoNegCapAdvertisedBits */

#define D_ifMauAutoNegCapAdvertisedBits_bOther 0

#define D_ifMauAutoNegCapAdvertisedBits_b10baseT 1

#define D_ifMauAutoNegCapAdvertisedBits_b10baseTFD 2

#define D_ifMauAutoNegCapAdvertisedBits_b100baseT4 3

#define D_ifMauAutoNegCapAdvertisedBits_b100baseTX 4

#define D_ifMauAutoNegCapAdvertisedBits_b100baseTXFD 5

#define D_ifMauAutoNegCapAdvertisedBits_b100baseT2 6

#define D_ifMauAutoNegCapAdvertisedBits_b100baseT2FD 7

#define D_ifMauAutoNegCapAdvertisedBits_bFdxPause
8

#define D_ifMauAutoNegCapAdvertisedBits_bFdxAPause
9

#define D_ifMauAutoNegCapAdvertisedBits_bFdxSPause
10

#define D_ifMauAutoNegCapAdvertisedBits_bFdxBPause
11

#define D_ifMauAutoNegCapAdvertisedBits_b1000baseX 12

#define D_ifMauAutoNegCapAdvertisedBits_b1000baseXFD 13

#define D_ifMauAutoNegCapAdvertisedBits_b1000baseT 14

#define D_ifMauAutoNegCapAdvertisedBits_b1000baseTFD 15

/* enumerated values for ifMauAutoNegCapReceivedBits */

#define D_ifMauAutoNegCapReceivedBits_bOther 0

#define D_ifMauAutoNegCapReceivedBits_b10baseT 1

#define D_ifMauAutoNegCapReceivedBits_b10baseTFD 2

#define D_ifMauAutoNegCapReceivedBits_b100baseT4 3

#define D_ifMauAutoNegCapReceivedBits_b100baseTX 4

#define D_ifMauAutoNegCapReceivedBits_b100baseTXFD 5

#define D_ifMauAutoNegCapReceivedBits_b100baseT2 6

#define D_ifMauAutoNegCapReceivedBits_b100baseT2FD 7

#define D_ifMauAutoNegCapReceivedBits_bFdxPause
8

#define D_ifMauAutoNegCapReceivedBits_bFdxAPause
9

#define D_ifMauAutoNegCapReceivedBits_bFdxSPause
10

#define D_ifMauAutoNegCapReceivedBits_bFdxBPause
11

#define D_ifMauAutoNegCapReceivedBits_b1000baseX 12

#define D_ifMauAutoNegCapReceivedBits_b1000baseXFD 13

#define D_ifMauAutoNegCapReceivedBits_b1000baseT 14

#define D_ifMauAutoNegCapReceivedBits_b1000baseTFD 15

Thanks,

Clay

C. M. Heard wrote:

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 5 Sep 2006 19:40:34 -0700

Hi -

> From: "C. M. Heard" <[email-masked]>
> To: "MIB Doctors" <[email-masked]>
> Sent: Tuesday, September 05, 2006 2:02 PM
> Subject: [MIB-DOCTORS] Re: Compilation compatibility with draft-ietf-hubmib-rfc3636bis-05 (fwd)
...
>  RFC 4181 advocates a more restrictive
...

I think the motivations for discouraging the changing of labels were
broader than that.  Changing labels causes problems for documentation
and for tools where those labels can appear at the user interface, if only
as a fallback because something more human friendly / better localized
hasn't been supplied.  I also know of tools where there this change could
cause problems at the boundary between user- and automatically-generated
code, but I don't know whether those tools are in use with this module.

RFC 4181 says "MUST NOT".  The argument that the change corrects
a typo would be more plausible if the labels' original names weren't
so consistent.  I'd go along with the change, but only if none of the
implementors objected.

Just my $0.02

Randy

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 6 Sep 2006 10:18:21 -0700 (PDT)

> code, but I don't know whether those tools are in use with this module.

Point taken.

> so consistent.  I'd go along with the change, but only if none of the

But the labels' original names were NOT in fact consistent.  In both
RFC 2668 and RFC 3636 the definition of ifMauAutoNegCapAdvertisedBits
used one spelling for the labels assigned to bits 8-11 -- bfdxPause(8),
bfdxAPause(9), bfdxSPause(10), and bfdxBPause(11) -- while the
definitions of ifMauAutoNegCapAdvertisedBits and fMauAutoNegCapReceivedBits
used a different one -- bFdxPause(8), bFdxAPause(9), bFdxSPause(10),
and bFdxBPause(11) -- as shown below.  To me that looks like a typo.

This became an issue because 3636bis proposes to replace the SYNTAX
value for all three objects with a TC from an IANA-maintained module.
Preserving the original spelling for ifMauAutoNegCapabilityBits would
require maintaining two TCs in the IANA module.

Rebuttals/comments/other opinions welcome.

Thanks

Mike

ifMauAutoNegCapabilityBits OBJECT-TYPE
    SYNTAX      BITS {
        bOther(0),        -- other or unknown
        b10baseT(1),      -- 10BASE-T  half duplex mode
        b10baseTFD(2),    -- 10BASE-T  full duplex mode
        b100baseT4(3),    -- 100BASE-T4
        b100baseTX(4),    -- 100BASE-TX half duplex mode
        b100baseTXFD(5),  -- 100BASE-TX full duplex mode
        b100baseT2(6),    -- 100BASE-T2 half duplex mode
        b100baseT2FD(7),  -- 100BASE-T2 full duplex mode
|       bfdxPause(8),     -- PAUSE for full-duplex links
|       bfdxAPause(9),    -- Asymmetric PAUSE for full-duplex
                          --     links
|       bfdxSPause(10),   -- Symmetric PAUSE for full-duplex
                          --     links
|       bfdxBPause(11),   -- Asymmetric and Symmetric PAUSE for
                          --     full-duplex links
        b1000baseX(12),   -- 1000BASE-X, -LX, -SX, -CX half
                          --     duplex mode
        b1000baseXFD(13), -- 1000BASE-X, -LX, -SX, -CX full
                          --     duplex mode
        b1000baseT(14),   -- 1000BASE-T half duplex mode
        b1000baseTFD(15)  -- 1000BASE-T full duplex mode
    }
...
ifMauAutoNegCapAdvertisedBits OBJECT-TYPE
    SYNTAX      BITS {
        bOther(0),        -- other or unknown
        b10baseT(1),      -- 10BASE-T  half duplex mode
        b10baseTFD(2),    -- 10BASE-T  full duplex mode
        b100baseT4(3),    -- 100BASE-T4
        b100baseTX(4),    -- 100BASE-TX half duplex mode
        b100baseTXFD(5),  -- 100BASE-TX full duplex mode
        b100baseT2(6),    -- 100BASE-T2 half duplex mode
        b100baseT2FD(7),  -- 100BASE-T2 full duplex mode
|       bFdxPause(8),     -- PAUSE for full-duplex links
|       bFdxAPause(9),    -- Asymmetric PAUSE for full-duplex
                          --     links
|       bFdxSPause(10),   -- Symmetric PAUSE for full-duplex
                          --     links
|       bFdxBPause(11),   -- Asymmetric and Symmetric PAUSE for
                          --     full-duplex links
        b1000baseX(12),   -- 1000BASE-X, -LX, -SX, -CX half
                          --     duplex mode
        b1000baseXFD(13), -- 1000BASE-X, -LX, -SX, -CX full
                          --     duplex mode
        b1000baseT(14),   -- 1000BASE-T half duplex mode
        b1000baseTFD(15)  -- 1000BASE-T full duplex mode
    }
...
ifMauAutoNegCapReceivedBits OBJECT-TYPE
    SYNTAX      BITS {
         bOther(0),        -- other or unknown
         b10baseT(1),      -- 10BASE-T  half duplex mode
         b10baseTFD(2),    -- 10BASE-T  full duplex mode
         b100baseT4(3),    -- 100BASE-T4
         b100baseTX(4),    -- 100BASE-TX half duplex mode
         b100baseTXFD(5),  -- 100BASE-TX full duplex mode
         b100baseT2(6),    -- 100BASE-T2 half duplex mode
         b100baseT2FD(7),  -- 100BASE-T2 full duplex mode
|        bFdxPause(8),     -- PAUSE for full-duplex links
|        bFdxAPause(9),    -- Asymmetric PAUSE for full-duplex
                           --     links
|        bFdxSPause(10),   -- Symmetric PAUSE for full-duplex
                           --     links
|        bFdxBPause(11),   -- Asymmetric and Symmetric PAUSE for
                           --     full-duplex links
         b1000baseX(12),   -- 1000BASE-X, -LX, -SX, -CX half
                           --     duplex mode
         b1000baseXFD(13), -- 1000BASE-X, -LX, -SX, -CX full
                           --     duplex mode
         b1000baseT(14),   -- 1000BASE-T half duplex mode
         b1000baseTFD(15)  -- 1000BASE-T full duplex mode
    }
...

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 6 Sep 2006 15:04:55 -0700

Hi -

> Sent: Wednesday, September 06, 2006 10:18 AM
...
> bfdxAPause(9), bfdxSPause(10), and bfdxBPause(11) --

Looks pretty consistent to me.

>  while the
...

But those bits are in a different object's syntax.  That's why to me the
"typo" argument seems merely plausible, and not convincing, and why
I think that impact on implementations should be given some weight.
 
Randy