Menachem, · Menachem,

_______________________________________________
Adslmib =
mailing=20
  =
list
Adslmib@ietf.org
https://www1.ietf.org/mailman/listinfo/adslmi=
b

_______________________________________________

Adslmib mailing list

Adslmib@ietf.org

https://www1.ietf.org/mailman/listinfo/adslmib
_______________________________________________

Adslmib mailing list

Adslmib@ietf.org

https://www1.ietf.org/mailman/listinfo/adslmib

_______________________________________________

Adslmib mailing list

Adslmib@ietf.org

https://www1.ietf.org/mailman/listinfo/adslmib
_______________________________________________

Adslmib mailing list

Adslmib@ietf.org

https://www1.ietf.org/mailman/listinfo/adslmib

Hi -

From: "Edward Beili" <EdwardB@actelis.com>
To: <csikes@zhone.com>
Cc: "C. M. Heard" <heard@pobox.com>; "IETF Hub MIB Working Group" <hubmib@ietf.org>
Sent: Tuesday, September 05, 2006 11:08 AM
Subject: [Hubmib] RE: Compilation compatibiltiy withdraft-ietf-hubmib-rfc3636bis-05

Clay,
>From the RFC 4181 perspective this change is allowed and was approved by the working group.
I would invite other people on this list to provide their views on that matter.

Except for the "typo" loophole, RFC 4181 doesn't seem terribly supportive:

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

My (supporting) opinion is stated in the email exchange below.

A side-effect of using a common TC can be to fix a "typo"?...  I guess it depends
on how good one's imagination is.  Without descending into CLR-dom, I think
what's most important here is to consider whether there are any references
*anywhere* to the "mis-spelled" labels.  If there are, then that supports the
perspective that the change should not be made.  If there aren't, then the
change is OK even though technically forbidden, in my opinion.

Randy

_______________________________________________
Hubmib mailing list
Hubmib@ietf.org
https://www1.ietf.org/mailman/listinfo/hubmib

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:csikes@paradyne.com]
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

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:csikes@paradyne.com]
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

Unless we hear any convincing argument I would suggest that the edits on
this issue reflect this proposal. 

Dan

-----Original Message-----
From: Edward Beili [mailto:EdwardB@actelis.com] 
Sent: Thursday, September 07, 2006 1:08 PM
To: Romascanu, Dan (Dan); C. M. Heard; IETF Hub MIB Working Group
Subject: RE: [Hubmib] Re: Compilation compatibility with 
draft-ietf-hubmib-rfc3636bis-05 (fwd)

Dan,
In my opinion we should keep the unified named bits 
definitions, I agree with Mike: 
"the ongoing burden of carrying forward two parallel TCs in 
an IANA-maintained module is a bigger concern than the 
one-time issues with the cut-over."

Also from the IEEE 802.3 standard point of view the unified 
AutoNegCapabilityBits definition is correct, since all bits 
are defined in a single Clause 30 attribute 
aAutoNegLocalTechnologyAbility (30.6.1.1.5), with all the 
other attributes (aAutoNegAdvertisedTechnologyAbility, 
aAutoNegReceivedTechnologyAbility) pointing to the 
aAutoNegLocalTechnologyAbility for syntax.

Regards,
-E.

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
Sent: Thursday, September 07, 2006 10:21 AM
To: C. M. Heard; IETF Hub MIB Working Group
Cc: Edward Beili
Subject: RE: [Hubmib] Re: Compilation compatibility with
draft-ietf-hubmib-rfc3636bis-05 (fwd)

Thanks Mike. Ed, can you please make a recommendation? Dan

-----Original Message-----
From: C. M. Heard [mailto:heard@pobox.com]
Sent: Thursday, September 07, 2006 8:19 AM
To: IETF Hub MIB Working Group
Cc: Edward Beili
Subject: [Hubmib] Re: Compilation compatibility with
draft-ietf-hubmib-rfc3636bis-05 (fwd)

All,

Attached are some messages on this topic that have 

appeared on the 

MIB Doctors mailing list.  As you can see, opinions vary :-)

The bottom line, I think, is that this is a decision for 

the Hub MIB 

WG to make.  My personal opininion is that the ongoing burden of 
carrying forward two parallel TCs in an IANA-maintained 

module is a 

bigger concern than the one-time issues with the cut-over.  Note 
that people that have a problem similar to Clay's have at 

least the 

following options:

(a) if there is no need for the new features in 3636bis, 

then there 

is no need to do anything.  Existing agent or manager 
implementations can be compiled with the modules from 3636 or
2668 and will be over-the-wire compatible with manager or agent 
implementations that have been updated per 3636bis.

(b) if the new features in 3636bis are needed, then the 
implementation will need to use that version of the MIB module 
anyway, so there is no downside (apart from the work 

required to do

it) in updating the hand-written parts of the agent or 

manager code 

to be compatible with what one's tools generate from the 

3636bis MIB 

module.  In Clay's case that would mean replacing all 

occurrences of 

ifMauAutoNegCapabilityBits_bfdx by 

ifMauAutoNegCapabilityBits_bFdx.

In Clay's case there is also the following option:

(c) if there is a need to compile with both the 2669/3636 and the 
3636bis MIB modules, then add the following definitions to the 
hand-edited parts of the code:

#ifndef D_ifMauAutoNegCapabilityBits_bfdxPause
#define D_ifMauAutoNegCapabilityBits_bfdxPause \
            D_ifMauAutoNegCapabilityBits_bFdxPause
#endif

#ifndef D_ifMauAutoNegCapabilityBits_bfdxAPause
#define D_ifMauAutoNegCapabilityBits_bfdxAPause \
            D_ifMauAutoNegCapabilityBits_bFdxAPause
#endif

#ifndef D_ifMauAutoNegCapabilityBits_bfdxSPause \ #define 
D_ifMauAutoNegCapabilityBits_bfdxSPause \
            D_ifMauAutoNegCapabilityBits_bFdxSPause
#endif

#ifndef D_ifMauAutoNegCapabilityBits_bfdxBPause
#define D_ifMauAutoNegCapabilityBits_bfdxBPause \
            D_ifMauAutoNegCapabilityBits_bFdxBPause
#endif

I think I've probably spoken enough on this topic so I'll 

now shut 

up and let others have a turn.

Regards,

Mike

_______________________________________________
Hubmib mailing list
Hubmib@ietf.org
https://www1.ietf.org/mailman/listinfo/hubmib