--On 9. mars 2004 19:54 -0800 Randy Presuhn <randy_presuhn(_at_)mindspring(_dot_)com>
wrote:
I made the comment that I thought we should apply RFC 2026 and force
things to either advance or go historic. Our AD advised us in one case
that if our WG wanted one of its RFCs to go historic, we had to write
another RFC explaining why. The procedure in RFC 2026 section 6.2
(last paragraph) seems very reasonable, and I like Harald's suggested
approach to cleaning up the cruft.
backpedalling somewhat.... I didn't intend to indicate that I had a
"suggested approach" yet - there are lots of details that should be worked
out before we start, such as:
- who should do it?
- what criteria should they use?
- which way should they be biased when in doubt?
- how much workload is created by doing this?
- who does something about the docs that do NOT go to Historic?
- how do we document the evaluations
- how do we challenge them?
The 2026 section 6.2 procedure, with no adjustments, says "IESG", "judgment
about likelyhood of progressing on track", "downgrade", "don't care about
workload", "WG if existing, otherwise don't care", "IETF-announce list
message", "appeals procedure".
I don't think those are necessarily the answers that can be made to work.
that's just a start.... some thinking about these things can probably go a
long way towards reducing the number of un-intended side effects we
cause....
Harald