Subject: [newtrk] Recycling at Proposed seems to document best current practice in the MIB module space

From: "C. M. Heard" <[email-masked]>
Date: Sun, 22 Jan 2006 18:48:25 -0800 (PST)

There was recently a discussion on the MIB Doctors list that
should be of interest to this WG, unless it is too exhausted
to continue working on its charter.  The discussion can be
viewed here:

http://ops.ietf.org/lists/mreview/mreview.2005/threads.html#00456

and the conclusion that I have quoted in the subject line is
accessible here:

http://ops.ietf.org/lists/mreview/mreview.2005/threads.html#00467

Happy reading.

//cmh

.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 23 Jan 2006 13:49:54 +0100

It isn't quite clear to me whether the argument is that MIBs
are a special case. The same issues (the need to invest
a lot of detailed effort and to remove features) apply to
all types of technical specification at the PS to DS transition.

    Brian

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 23 Jan 2006 07:55:17 -0600

> all types of technical specification at the PS to DS transition.

I should probably let the MIB doctors/Bert field this one, but since I did 
look at the entire thread, this is how it looks to me:

- MIBs actually ARE "special", because STATUS gives guidance about "you 
should be using this, you shouldn't be using this anymore", but

- MIBs aren't THAT "special", because (1) no one sees a lot of benefits to 
advancing a MIB ("either a device supports the MIB or it doesn't"), (2) no 
one seems to do any work to advance on the standards track (the experience 
in shaking out the "second implementation" for a MIB considered for Draft 
Standard sounds exactly like BGP 4-byte AS numbers hanging for a couple of 
years because no one bothered to do the implementation report for 
implementations which did exist), and (3) Bert has to choose between leaving 
WGs open for "a while" to advance a document and closing WGs "after they've 
done all their work" and then trying to spin up a revived working group to 
advance the documents on the standards track.

So I agree with Brian (I'm just providing a little more background on this 
decision).

The part that worries me is that now the MIB doctors are faced with either 
trying to write up a short document on what the standards track will be for 
MIBs, or just ignoring a significant portion of the existing standards track 
completely and telling new participants "we're special, so we don't follow 
the standards track BCPs".

I may have misunderstood (it does happen), but that's the way it looks to 
me.

Thanks,

Spencer

.

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 23 Jan 2006 08:44:55 -0800 (PST)

On Mon, 23 Jan 2006, Spencer Dawkins wrote:
> I should probably let the MIB doctors/Bert field this one, but since I
> did look at the entire thread, this is how it looks to me:
> 
> - MIBs actually ARE "special", because STATUS gives guidance about
> "you should be using this, you shouldn't be using this anymore", but
> 
> - MIBs aren't THAT "special", because (1) no one sees a lot of
> benefits to advancing a MIB ("either a device supports the MIB or it
> doesn't"), (2) no one seems to do any work to advance on the standards
> track (the experience in shaking out the "second implementation" for a
> MIB considered for Draft Standard sounds exactly like BGP 4-byte AS
> numbers hanging for a couple of years because no one bothered to do
> the implementation report for implementations which did exist), and
> (3) Bert has to choose between leaving WGs open for "a while" to
> advance a document and closing WGs "after they've done all their work"
> and then trying to spin up a revived working group to advance the
> documents on the standards track.

Thanks for reading the thread.  That's a good summary.  And I agree
that what holds for MIB documents pretty much holds for everything.

However, there is one other important point from the discussion that
I'd like people here to consider:  we concluded that in many cases
going through the hoops to ensure that a MIB module could be advanced
on the standards track ACTUALLY CAUSED HARM to the community.  The
specific harm was in the form either of unnaturally fragmenting a MIB
module into multiple pieces, just so that one part could advance, or
else omitting useful features altogether (which we would not otherwise
have done).  I suspect that this, too, is a general problem.

> So I agree with Brian (I'm just providing a little more background on
> this decision).
> 
> The part that worries me is that now the MIB doctors are faced with
> either trying to write up a short document on what the standards track
> will be for MIBs, or just ignoring a significant portion of the
> existing standards track completely and telling new participants
> "we're special, so we don't follow the standards track BCPs".
> I may have misunderstood (it does happen), but that's the way it looks
> to me.

Speaking for myself, what I'd really like is for newtrk to write up
a a short document on what the standards track will be for
everything. MIBs could then follow that. The document could be very
short indeed, if the newtrk WG would adopt the one-size-fits-all
approach which is pretty much de-facto practice.

I wanted newtrk folks to read the thread in hopes that it would help
motivate the the WG to finish its work.  If that does not happen
expect people to work out solutions of their own.

//cmh

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 23 Jan 2006 11:10:44 -0600

> have done).  I suspect that this, too, is a general problem.

Thank you for catching this - I had noticed it while reading and agreed that 
the current standards track does give one reason to write an additional 
specification, instead of modifying the current text and replacing the 
existing specification. But I left this point out of my summary (too little 
Diet Coke in the morning, I'm fixing this now).

This may actually be a little worse for MIBs, but I haven't seen a case 
where the current situation actually helps anything for either MIBs or the 
general case.

Thanks,

Spencer 

.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 23 Jan 2006 18:58:26 +0100

I do worry about one thing: the maturation process is a useful thing,
but it does take time.  And it could be that there will come a point
where quality beats quantity and a focus is given by one company or
another to advancing / repairing MIBs or other standards.

Eliot
.

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 23 Jan 2006 10:41:52 -0800 (PST)

> another to advancing / repairing MIBs or other standards.

My experience strongly suggests otherwise.

As I mentioned in the thread on the MIB Doctors list, it is my
opinion that the steps we took in the AToM MIB WG to advance the
SONET-MIB to DS simply had the effect of preventing some relatively
small but nonetheless operationally important additions to the MIB
from being made.  I think that was a big mistake.  We didn't go that
route for the DS1-MIB, instead deciding to recycle at PS.  That was
clearly the right decision for the community.

Also, consider the experience of the Ethernet Interfaces and Hub MIB
WG.  That group has recycled the EtherLike-MIB (RFC 3635) and the
MAU-MIB (RFC 3636) at PS several times since 1994, each time to add
support for new technologies standardized by the IEEE 802.3 WG.  In
the meantime we had an old SMIv1 version of the EtherLike-MIB in RFC
1643 that was an Internet Standard but nonetheless hoplessly out of
date.  What a ludicrous situation.  We finally moved it to Historic
to encourage folks to do the right thing (see RFC 3638 for details).

Mike

.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 27 Jan 2006 08:51:27 +0100

> My experience strongly suggests otherwise.

As does mine, but the focus for many companies up until now has been
"cram in more features".  I wonder at some point if the focus will shift.
> clearly the right decision for the community.

Right.  There is no shame in recycling to Proposed.

Eliot
.