Subject: Re: [Bridge-mib] Consensus Call

From: "Tom Petch" <[email-masked]>
Date: Thu, 4 Nov 2004 21:30:59 -0000

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-masked]>
To: [email-masked] <[email-masked]>
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-masked]
>Bridge-mib co-chair
>
>
>> -----Original Message-----
>> From: Juergen Schoenwaelder [mailto:[email-masked]] On
>> Behalf Of Juergen Schoenwaelder
>> Sent: Tuesday, November 02, 2004 3:23 PM
>> To: David B Harrington
>> Cc: [email-masked]; 'Les Bell'; [email-masked]
>> 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

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

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 4 Nov 2004 17:25:02 -0500

Hi Tom,

My goal, to make it clear, is to get the documents finished. I don't
want to have to re-edit the documents to remove the PathCost32 because
that will take another four to six months to a year at the glacial
rate of this working group. I would like to simply last call the three
documents as they currently stand and be done. 

The documents will be published as RFCs, which are by definition
stable **documents** within the IETF, even though -- technically --
they are in an unstable **state**. The only difference is that, with
PathCost32 present, we would need to submit the documents at Proposed
rather than FS, and "most MIB users/implementors [do not] comprehend
the difference between the various ,S that the IETF has defined." 

I see no benefit to be gained from advancing three-year-old mib
modules in the standards track and then having the IEEE immediately
start to write new documents to replace them. The PAR for an
802.1Q-REV has already been granted, and it is well understood in both
the IEEE and the IETF that the Bridge MIB modules are out-of-date
relative to 802.1D-2004 and needs to be updated.

It may not have been obvious, but I posed the question relative only
to this editing cycle - the last planned editing cycle for this
document in the IETF. There would be no more additions to the three
documents currently in last call. Any further work would be done in
the IEEE as part of their next update. I was not suggesting that we
reopen the document for even more additions now, or ever.

I think I did pose the correct question though. Given that the
compliance statement for RFC1493 is still valid, so you only need to
do an upodate if you want the PathCost32 in your implementation, if we
publish the documents with the PathCost32 in them, and therefore have
to start the updated document at Proposed, will that impact your
company's implementation schedule? If we re-edit the documents and
then advance them to FS and DS, will that change your company's
implementation schedule and generate addition revenue for your
company?

Or does the advancement only impact its "technical" status within the
IETF, and not **really** impact users and implementors of the MIB
module? I think we are in agreement that the advancement has only a
technical impact within the IETF, not a practical impact to the
industry.

dbh

> From: Tom Petch [mailto:[email-masked]] 
> Sent: Thursday, November 04, 2004 4:31 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [Bridge-mib] 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 
> 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
> 
> >or should we add the 32-bit functionality even if we have to 
> recycle at 
> >Proposed?
> >
> >Thanks,
> >David Harrington
> >[email-masked]
> >Bridge-mib co-chair
> >
> >
> >> From: Juergen Schoenwaelder [mailto:[email-masked]] 
> On Behalf 
> >> Of Juergen Schoenwaelder
> Standard 
> >> d) We do what the document currently does and move 
> forward, looking 
> >> for
> standard 
> >> "is

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 5 Nov 2004 21:43:52 +0100

> documents as they currently stand and be done. 

Any editing regarding the PathCost32 issue should be rather easy once 
we have formed an opinion. I now hold the editing token and I am fine
to update the document on Friday or Saturday after the IETF if there
is a final decision reached next week. From my point of view, all
possible solutions (removing or keeping or changing) have more or 
less the same editing costs.

/js

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

---

From: "David B Harrington" <[email-masked]>
Date: Fri, 5 Nov 2004 16:11:54 -0500

Note that the RSTP-MIB has dependencies on PathCost32. This makes
editing just a touch more difficultt, but not seriously so.

dbh

> Sent: Friday, November 05, 2004 3:44 PM
> To: David B Harrington
> Cc: 'Tom Petch'; [email-masked]

> Any editing regarding the PathCost32 issue should be rather 
> easy once we have formed an opinion. I now hold the editing 
> token and I am fine to update the document on Friday or 
> Saturday after the IETF if there is a final decision reached 
> next week. From my point of view, all possible solutions 
> (removing or keeping or changing) have more or less the same 
> editing costs.
> 
> /js
> 
> --