RE: Consensus Call

Just to be clear, that was Juergen's mail, not Bert's.

dbh

> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:[email protected]] 
> Sent: Thursday, November 04, 2004 11:16 AM
> To: [email protected]; [email protected]
> 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
> > 
>