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

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 01 Nov 2004 09:23:48 +0100

One note (speaking as WG participant):

--On lørdag, oktober 30, 2004 19:40:21 -0400 scott bradner 
<[email-masked]> wrote:

> cruft
>         should we decruft - chair                               10
>         decrufting details - Lear/Alvestrand                    25
>         reading: draft-ietf-newtrk-cruft-00.txt

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.

                 Harald, pusher-for-change

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

---

From: Pekka Savola <[email-masked]>
Date: Mon, 1 Nov 2004 12:40:02 +0200 (EET)

On Mon, 1 Nov 2004, Harald Tveit Alvestrand wrote:
> 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.

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.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 01 Nov 2004 13:24:15 +0100

--On mandag, november 01, 2004 12:40:02 +0200 Pekka Savola 
<[email-masked]> wrote:

> documents were considered 'crufty' should be documented in RFCs or not.

Suits me.
I guess there are more people who can be persuaded to voice an opinion on 
that in the room than on the list.

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 1 Nov 2004 06:47:04 -0600

> 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

p.s. My impression of NEWTRK progress to date is that we have 
addressed important and useful topics, but that we still haven't taken 
a serious swing at an update to 2026, and we were chartered nearly two 
full IETF cycles ago. If we can avoid reopening discussions at 
3/4-month intervals, that's got to help us get to the major 
deliverable we were chartered for... 

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 1 Nov 2004 07:07:19 -0600

Just following up to Harald's original followup -

> I believe the value of getting this going is larger than the value 
> of further debate on the details.
>

Since we now have RFC 3933 approved, even if we're still figuring out 
exactly what some of the text says, my suggestion would be that we use 
Experimental documents for process changes unless we are very sure 
that we'll get all of the details right the first time around. Since 
we still have alternative viewpoints from reasonable people, we may be 
revisiting at least one detail :-)

So, given a choice between "Experimental procedure" and "straight-out 
BCP status", I'd suggest the first choice.

Spencer 

.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 01 Nov 2004 14:29:41 +0100

Let me hum:

> - one RFC per de-crufted standard (current informal practice, but no BCP 
> documentation for this practice that I know about)
too much work for small results

> - one RFC per de-cruft cycle
HMMMMMMM
Rationale: efficient, no new infrastructure needed, can just be
done starting tomorrow

> - no RFC, with some other approval process
creates redundant process

     Brian
.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 3 Nov 2004 09:26:37 +0200 (EET)

> Let me hum:

I'll hum exactly the same way, for exactly the same reasons :)