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

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Fri, 8 Sep 2006 19:39:36 +0300

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

---

From: "Clay Sikes" <[email-masked]>
Date: Fri, 08 Sep 2006 12:58:09 -0400

Hi,

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

- Clay

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

Dan

-----Original Message-----
From: Edward Beili [mailto:[email-masked]]
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

Dan,

Regards,
-E.

-----Original Message-----
From: C. M. Heard [mailto:[email-masked]]
Sent: Thursday, September 07, 2006 8:19 AM
To: IETF Hub MIB Working Group
Cc: Edward Beili
Subject: [Hubmib] Re: Compilation compatibility with

All,

appeared on the

the Hub MIB

module is a

least the

following options:

then there

required to do

manager code

3636bis MIB

occurrences of

now shut

Regards,

Mike

---

From: "C. M. Heard" <[email-masked]>
Date: Thu, 28 Sep 2006 00:59:10 -0700 (PDT)

>>>>> On Fri, 8 Sep 2006, Romascanu, Dan (Dan) wrote:
Dan> Unless we hear any convincing argument I would suggest
Dan> that the edits on this issue reflect this proposal.

>>>>> On Fri, 8 Sep 2006, Clay Sikes replied:
Clay> I'm ok with going forward with the ID version -05.

The I-D tracker still lists draft-ietf-hubmib-rfc3636bis-05
as being in state "I-D Exists" ... isn't it time to submit
it to the IESG for consideration as a proposed standard?

Mike