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

"Romascanu, Dan \(Dan\)" <[email protected]> Fri, 8 Sep 2006 19:39:36 +0300
Newsgroups gmane.ietf.hubmib
Message-ID <AAB4B3D3CF0F454F98272CBE187FDE2F0B32D0B3@IS0004AVEXU1.global.avaya.com>
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
> > > 
> > 
>