RE: Consensus Call

I agree with Dan.

Les...





"Romascanu, Dan \(Dan\)" <[email protected]>@ietf.org on 04/11/2004 16:15:56

Sent by:  [email protected]


To:   <[email protected]>, <[email protected]>
cc:
Subject:  RE: [Bridge-mib] Consensus Call


Speaking as a contributor - I always favored the approach that we should rather
update the standard and recycle at Proposed, than progress MIB modules on the
standard track, while they are not exactly in synch with the IEEE standard. This
is the line they we also took in the Ethernet MIB WG.

My employer is a mostly enterprise space vendor. I am not official speaker for
the company, but I could cautiously say that my impression is that our customers
do not care too much about the IETF Standards Status.  If a standard does its
job and ensures interoperability between vendors its fine with them.

Only a small category of customers would look at the standards status before
entering it in an RFP. However, my impression is that these customers will first
include the IEEE 802.1 standard, and only second the MIB standard. What is the
good of having a Full Standard with a MIB that is not in synch with the IEEE
specification?

In conclusion I personally favor option c in Bert's mail.

Regards,

Dan



> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of David B Harrington
> Sent: 04 November, 2004 5:33 PM
> To: [email protected]
> Subject: [Bridge-mib] 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
> >
>
>
>
> _______________________________________________
> Bridge-mib mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/bridge-mib
>

_______________________________________________
Bridge-mib mailing list
[email protected]
 https://www1.ietf.org/mailman/listinfo/bridge-mib