RE: Consensus Call

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

> -----Original Message-----
> From: Tom Petch [mailto:[email protected]] 
> Sent: Thursday, November 04, 2004 4:31 PM
> To: [email protected]; [email protected]
> 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 
> 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
> 
> 
>