Re: 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