RE: 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
> > 
>