Subject: RE: [newtrk] Session chair summary - Decruft

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 10 Aug 2005 14:38:00 +0200

Inline

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Harald Tveit
> Alvestrand
> Sent: Wednesday, August 10, 2005 13:32
> To: NEWTRK Mailing List
> Subject: [newtrk] Session chair summary - Decruft
> 
> 
> My summary (disclaimers apply):
> 
> - The sense of the room is that it wants the document sent to 
> the IESG for 
> a Last Call on a standards action that would move the 56 
> documents (or 
> whatever remains of them after Last Call comments) to Historic
> 
> - There is still fear that the Last Call will generate 
> significant noise 
> and work for the community, with little benefit
> 
> - We will learn whether that's true by trying it
> 

W.r.t. the last 2 bullet points, I did make a remark at the
NEWTRK session in Paris. I will repeat for the list members.
I have also done some  investigation, so I have a lot more 
meat/details. I am not claiming that I recall all correctly.
If anyone has records of more or different details, pls let
me know.

So here we go:

  I have done such an experiment in my early days as AD.
  At the time, Fred Baker (IETF Chair at that time) would send
  an email once in a while remining us (ADs) to see if there wer
  old PS level documents that needed to be reviewed.

  So I took such a document that I thought was a straight forward
  case to move it from PS to DS. Unfortunately the WG did not want
  to undertake the effort, so I then decided that we wanted to
  make it Informational. That caused quite a lot of discussion
  as and effort and aggrevation.

  This was long before we had the I-D tracker, and since then I 
  have lost my hard disk and my laptop a few times. I switched
  employers too. So unfortuenately I cannot dig into the details
  (or certainly not easily). I am browsing the web (with google) 
  to try and find proof. But others can try to do so too.

  Without having the archives as a proof (yet), I recal that:
  - it seemed to be a simple (I took a (in my view)simple MIB
    document, mamely UPS MIB, RFC1628), easy and quick work item.
  - it first cause refusion by the WG and vendors to spend 
    effort to go from PS to DS.
  - I then started the process to change from PS to Informational
  - it caused concerns at the author/editor level
  - it caused concern at the (old WG level)
  - it caused concern in the SNMP/MIB community
  - The community and myself had to spend quite a bit of time
  - the result is that it finally got deprecated from PS to Informational
    (as per below announcement, which I found in a web cache, but not
     (yet) on IETF archives).
  - it truns out that even today, the RFC-Editor may not even have
    seen the announcment from 1998, cause the RFC-Index still lists
    RFC1628 as PS.
  - looking back today (10 aug 2005) with the help of Harald,
    we find in a OPS area database that we kept on haralds machine
    an entry that makes me believe that I actually checked that 
    the RFC-index was updated with the new INFORMATIONAL tag.
    but it is no prove that such was indeed the case.
  - in any event, if the RFC-index was indeed updated back in 1999,
    then for some reason it now lists PS again.
  - so possibly I should follow up on that (again?)

Oh well... we wasted (in my view) a lot of energy/cycles. 
And I very much fear we may again waste cycles on something
that is too low priority compared to a lot of work that is
taking too long.

That is why I was in favor of the "do nothing" option when 
Harald asked at the meeting in Paris last Friday.

Here is the announcement I found (sorry, no date):
----------------
To: IETF-Announce:;
Cc: RFC Editor <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>
Cc: [email-masked]
From: The IESG <[email-masked]>
Subject: Protocol Action: UPS Management Information Base to Informational
-------------

The IESG has approved reclassifying 'UPS Management Information Base'
<RFC1628> as an Informational RFC.  This document is the product of the
Uninterruptible Power Supply Working Group.

The contact persons are Bert Wijnen and Randy Bush.

Technical/Working Group Summary

The document has been at Proposed Standard since 1994.
The UPSMIB WG mailing list was polled to see if there was any
interest to do the additional work for this MIB to advance on the
standards track. In order to do so, some fixes would
have to be made and some administrative text would have to be
added. Also an implementation report would have to be created that
demonstrates multiple interoperable implementations.
(See RFC 2026 and RFC 2438).

Various vendors have implemented this MIB, and the consensus
is that this MIB is "good enough".
Nobody is prepared to spend the extra effort required to advance
the MIB to the next level on the standards track.

As a result, the best course of action is te re-classify RFC 1628
from Proposed Standard to Informational.

--------- end of chached web content -------

--- start of records in OPS area data base back in 1999 --
//RFC 1628
method:www
name:RFC 1628
title:UPS Management Information Base
goal:Info
status:Dead
responsible:
ident:script=cgi-bin/update.cgi ip=195.212.29.100 host=195.212.29.10
0 user=

commentlog:
1999-04-13 0 Last Call issued to reclassify as Informational.
  UPSMIB WG does not want to do the work to advance to draft; they
  consider the MIB good enough.
1999-04-13  Last Call has been issued issued on 2 April 1999
1999-04-26  IESG approved to reclassify as Informational on 22 Apr 1999
1999-06-14  RFC has been reclassified as Informational in the RFC index

recdate:Mon Jun 14 10:02:40 1999
area:OPS
lastchange:1999-06-14
respname:Bert Wijnen

------ end of OPS area database content
Bert
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Eliot Lear <[email-masked]>
Date: Wed, 10 Aug 2005 16:33:46 +0200

Good afternoon Bert,

>   Without having the archives as a proof (yet), I recal that:[...]

[Although I wasn't part of the process, I could fully believe your
memory to be correct.  However...]

If we are to leave the text in 2026 and if we want our standards to
progress beyond PS we ought to encourage them to get there.  That having
been said, having a process failure with the RFC editor doesn't help,
and it seems to me that de-cruft won't matter to anyone if the RFC
Editor doesn't keep their pages accurate.

> that is too low priority compared to a lot of work that is

The criteria for removing something from the cruft list was VERY low.
Someone merely had to stand up and say "keep this one at PS".  I asked
for a one line reason but any reason was considered good enough in this
experiment.  The goal was to keep the process light weight.

> Harald asked at the meeting in Paris last Friday.

Yes, and I was confused by this.  Why not update 2026 to remove the
time-outs to document existing practice?

Eliot
.