Re: Re: Compilation compatibility with draft-ietf-hubmib-rfc3636bis-05 (fwd)

Hi,

I'm ok with going forward with the ID version -05.

- Clay

On 9/8/2006 12:39 PM, Romascanu, Dan (Dan) wrote:

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:[email protected] ]
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:[email protected] ]
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:[email protected] ]
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
[email protected]
https://www1.ietf.org/mailman/listinfo/hubmib

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