Re: Consensus Call

David

I think you pose the wrong question.  For me, the issue is more about how
long do we go on doing this for with what end in view?

I prefer option a' where we arrive at FS because I think anything else is,
at least technically, an unstable state within the IETF.  I do not believe
that most MIB users/implementors comprehend the difference between the
various ,S that the IETF has defined.

And while it is technically satisfying to get 32 bit path cost right, this
is just the current of what could be a never ending list of changes coming
up in the future and we already decided that the future of this work
belongs with IEEE not IETF.

Tom Petch

-----Original Message-----
From: David B Harrington <[email protected]>
To: [email protected] <[email protected]>
Date: 04 November 2004 15:48
Subject: [Bridge-mib] Consensus Call


>OK, Let me start a discussion here. This is important for a consensus
>check, so please read and respond.
>
<snip>
>
>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:
>>
>> 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 ideas how to select the winner?

Rough consensus?

>>
>> Juergen Schoenwaelder     International University Bremen
>> <http://www.eecs.iu-bremen.de/>     P.O. Box 750 561,
>> 28725 Bremen, Germany