Consensus Call

OK, Let me start a discussion here. This is important for a consensus
check, so please read and respond.

My experience has been working for an equipment vendor. I have worked
in both the embedded system space and the pure vendor-neutral software
solution space. Here is what I have learned from that experience.

Mib module official status becomes important on the agent side first;
once a mib hits PS it's a valid target for inclusion in project plans
(for those products that include the managed functionality). While
some mib modules get implemented from an I-D, the RFC publication
finalizes the design and an RFC# is marketable. Advancement to DS or
FS makes little difference - if the functionality is in the box, the
mib module should be done fairly soon after the functionality is
available, and if there is an RFC-level standard, that's good. The
tweaking that occurs between PS and DS and between DS and FS makes
little difference to an equipment vendor (except as non-marketable
maintenance work).

MIB modules become important to vendor-neutral software developers
when enough equipment vendors support the MIB module to make it
worthwhile directly supporting it, and there is customer demand for
consistent management of the functionality. Most vendor-neutral
software vendors use table-driven or model-driven designs that largely
hide whether the implementation is the industry standard MIB module or
a proprietary MIB module with similar capabilites. The status of a MIB
module standard is largely irrelevant; the customer demand exists or
it doesn't.

So, we are now faced with a decision to publish the SMIv2 version of
RFC1493 **with no semantic changes** or to publish an updated MIB
module that reflects the current underlying IEEE standard better, by
supporting 32-bit PathCost rather than only the 16-bit PathCost.

How many people on this list actually care whether the standard status
is at PS or DS or FS, and why? Will advancing the standards level have
an **actual** impact on whether the implementation is done by your
company? Would recycling the MIB module at PS have a negative effect
on your company and its revenue stream? Would the benefit of having a
MIB module that is more current with IEEE standards offset any
negatives of recycling at PS?

If you are not associated with a company, but rather a university or
an open-source product or whatever, will the status level have a real
impact on what you do?

Ultimately the question to be answered is: Should we diminish the
functionality in order to advance the document in the standards track,
or should we add the 32-bit functionality even if we have to recycle
at Proposed?

Thanks,
David Harrington
[email protected]
Bridge-mib co-chair
 

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[email protected]] On 
> Behalf Of Juergen Schoenwaelder
> Sent: Tuesday, November 02, 2004 3:23 PM
> To: David B Harrington
> Cc: [email protected]; 'Les Bell'; [email protected]
> Subject: Re: [Bridge-mib] dot1dStpPortPathCost32
> 
> On Tue, Nov 02, 2004 at 02:47:11PM -0500, David B Harrington wrote:
>  
> > Can we resolve this (and any other issues) on the mailing 
> list before 
> > IETF61, please?
> 
> Will be hard, but we can try.
>  
> > These mib modules are already three years behind the 
> charter schedule.
> 
> Yes. But since the IETF meeting is next week, I would say 
> that this week does not cause any significant delay.
>  
> > We want to start the WG last call before IETF61, not wait 
> until IETF61 
> > to start discussing possible solutions.
> 
> Lets try to collect possible solutions:
> 
> a) We remove the 32-bit path cost, move the BRIDGE-MIB to Standard
and
>    start a new MIB module which defines the new object.
> 
> a') We remove the 32-bit path cost, move the BRIDGE-MIB to 
> Standard and
>    tell the IEEE or who cares that they have to address this issue.
> 
> b) We agree to change the range restriction by declaring that an
error
>    or bug fix (even though it really is not, well yeah ...). We
don't
>    introduce a new object, stepping of course formally on SMIv2
rules.
> 
> c) We do what the document currently does (introducing a new object)

>    and move the whole MIB module back to Proposed.
> 
> d) We do what the document currently does and move forward, 
> looking for 
>    the IESG feedback. Note that RFC 2026 says that a Draft 
> standard "is 
>    normally considered to be a final specification, and changes are 
>    likely to be made only to solve specific problems encountered." 
>    Perhaps this is a specific problem encountered...
> 
> e) We drop the whole document and just stick to RFC 1493.
> 
> Any options I did forget?
> 
> Any ideas how to select the winner?
> 
> /js
> 
> -- 
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 
> 28725 Bremen, Germany
>