Subject: RE: Decruft schedule (Re: [newtrk] updated newtrk agenda)

From: <[email-masked]>
Date: Mon, 1 Nov 2004 10:32:32 +0200

Harald,

> If the consensus of the room is the same as in San Diego and we should 
> decruft, I will propose to the room that we send out a Last Call for the 
> document right after the meeting, with no further changes or debate - 
> either for Experimental procedure under draft-klensin-process-july14 or for 
> straight-out BCP status.
> 
> I believe the value of getting this going is larger than the value of 
> further debate on the details.

I definately agree with you.

John

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

---

From: John C Klensin <[email-masked]>
Date: Mon, 01 Nov 2004 09:56:15 -0500

--On Monday, 01 November, 2004 06:47 -0600 Spencer Dawkins
<[email-masked]> wrote:

>> IMHO, we should issue a show-of-hands or some other kind of
>> consensus process on whether the people feel that the reasons
>> why  particular documents were considered 'crufty' should be
>> documented  in RFCs or not.
>
> I agree with Pekka that this seems like the remaining point of
> controversy/confusion in our discussions of the proposal, but
> have a counterproposal -
>
> Since the sense of the room in San Diego was that de-crufting
> was worth pursuing, and the post-meeting working group mailing
> list seemed (to me) to support this, howzabout we do a july14
> proposal that allows the IESG to pick one alternative on this
> detail, and submit it immediately after IETF 61?
>
> IIRC, the possible approaches are
>
> - one RFC per de-crufted standard (current informal practice,
> but no BCP documentation for this practice that I know about)
> - one RFC per de-cruft cycle
> - no RFC, with some other approval process
>
> What am I missing?

Spencer, while I don't want to bind the de-crufting question(s)
to the ISD-repurposing stuff, it has occurred to me several
times that those documents, with a more flexible and narrative
format than RFCs, might be a fourth alternative on your list of
three.

So, my instinct would be to launch a de-crufting process if the
community really wants it (see below), instructing the committee
to keep notes on what it is doing that could be turned into a
document, with the choice of document format and style being
deferred.  We then proceed to try to finish and decide upon the
ISD notion and, if it is accepted, add those documents to the
list of ways in which de-crufting can be documented in the short
term.  If the ISDs are adopted, they would certainly become the
de-crufting documentation model for anything on which an ISD is
first issued (i.e., many of today's bright ideas will be the
cruft of five years
hence).

One of the advantages of July14-type experiments is that one can
go into an experiment with more loose ends and deferred
decisions than are possible (or rational) with a BCP.

    john

p.s. I've still got some doubts as to whether putting resources
into de-crufting is desirable.   I wish it were possible to do a
marginal cost/loss function analysis on other ways in which
those resources could be used.   But, perhaps, given the nature
of the IETF community, the best way to get an answer to that
question is to go ahead and launch this on an experimental
basis, see who actually volunteers, whether they can produce
anything in finite time and with the resources they are willing
to invest, and then see whether their recommendations are
sufficiently well-documented and non-controversial that they can
be approved without significant use of community (including
especially IESG) resources that could better be spent in other
ways.

.