Subject: [newtrk] a crufty last call

From: [email-masked] (scott bradner)
Date: Tue, 12 Oct 2004 13:26:39 -0400 (EDT)

I'd like to do sort of a last call on the crufty ID
(draft-ietf-newtrk-cruft-00.txt)

I do not want to last call the document itself instead I'd like to last 
call the concept of this document

so the specific details of the process proposed in the ID are off-topic 
but the idea of having a process to perform "the downgrading of old
standards described in RFC 2026, as well as BCPs, without placing
an unreasonable load on groups charged with performing other tasks in
the IETF" is in-scope

consider this question
	"should this working group develop process(es) with the aims
	 described in the ID draft-ietf-newtrk-cruft-00.txt?"

please answer with "yes" "no" or "maybe"

please give a SHORT explanation of why for an answer of "yes" or "no"

if you answer "maybe" please state why you cannot answer "yes" or "no"

this sort-of-last-call will end in two weeks (Oct 26) at noon ET

if there is no clear consensus (or a consensus for "maybe") we can talk
about the question during the newtrk session in DC, if there is a clear 
consensus of "no" we will drop the idea, and if the clear consensus 
is "yes" we will then discuss the specifics of the proposal.

thanks

Scott
.
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, 13 Oct 2004 08:29:24 +0200

Um, Yes?

For the following reasons:

  - WGs don't stay around to clear out the cruft
  - Some ideas turn out to be bad
  - the IESG needs to allow for the fact that some ideas will
    turn out to be bad ideas
  - we need a light weight way to deal with ideas that have in fact
    turned out to be bad, as determined by lack of implementation
    or deployment
  - We say that this is how things should work in 2026 but it's not
    how they work

Eliot
.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Oct 2004 09:43:16 +0200

My answer is "yes" but with one qualification: although this
is a separable idea, I don't think we should finalize it
until we have something approaching a consensus on
what we will do to the standards track as a whole.

For example, if we did reduce the standards track to a single
maturity level, the details of the cruft committee's work
would need a little fine tuning.

As to why my answer is "yes", I think this is really a no-brainer.
Having cruft parked on the standards/BCP track is just another
way of confusing the users of IETF documents.

    Brian

.

---

From: Susan Harris <[email-masked]>
Date: Wed, 13 Oct 2004 10:23:41 -0400 (EDT)

>   - We say that this is how things should work in 2026 but it's not

Agreed - "yes."
.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 13 Oct 2004 06:53:56 -0700

Brian,

I have one disagreement with you.

> what we will do to the standards track as a whole.

I think that having the work started will give us valuable information, no 
matter what the final standards track is.

Question: Would you consider approving the document under the rules of 
draft-klensin-july14 (experimental process, to be reevaluated within a 
year) to be an appropriate way of "not finalizing" it?

                Harald

(PS: I was surprised to see this question last-called to the WG; I thought 
we had WG consensus on it before. The biggest discussion I've seen has been 
the issue of whether or not to publish cruft committee recommendations as 
RFCs - if the WG Chair wants to last-call a resolution that question before 
giving specific direction to the editor, that would help us move forward...)

.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 13 Oct 2004 15:08:22 -0700

Yes.  I believe there is far too much cruft on the
standards track and we find a non-burdensome way
to remove it.  The current practice, publish an
RFC to move RFC(s) to Historic, is simply too
burdensome in the case of cruft.  I think the
approach outlined in the cruft I-D is workable.

Kurt

.

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Wed, 13 Oct 2004 15:29:20 -0700

Yes. Take a look at <http://www.imc.org/rfcs.html> for plenty of 
reasons that rhyme with "yikes, that's a standard?".

And I disagree with Christian in that there are many times where the 
standard did not match any real-world need. We don't need better 
mousetraps there, were need fewer standards.

--Paul Hoffman, Director
--VPN Consortium
.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Oct 2004 11:46:12 +0200

Harald Tveit Alvestrand wrote:
> I think that having the work started will give us valuable information, 
> no matter what the final standards track is.
> 

Sure, why not? The final adjustments would be quite small, I think.
The only complication I could imagine is if we decide to split the
"historic" class of RFCs into multiple classes (e.g. "obsolete"
and "deprecated") which would create multiple types of cruft.

    Brian

> 
>                Harald
> 
> (PS: I was surprised to see this question last-called to the WG; I 
> thought we had WG consensus on it before. The biggest discussion I've 
> seen has been the issue of whether or not to publish cruft committee 
> recommendations as RFCs - if the WG Chair wants to last-call a 
> resolution that question before giving specific direction to the editor, 
> that would help us move forward...)
> 
> 
> 
> 
.

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 14 Oct 2004 08:58:18 -0400

Hi All,

>	 described in the ID draft-ietf-newtrk-cruft-00.txt?"

I'll go against the grain with a "no" vote.

I am not against the idea of moving documents that shouldn't be on 
the standards track to Historic, but I don't see any reason why we 
need a WG to develop processes to do that.  Nor do I understand why 
we need an officially constituted committee.

It is my opinion that if the main advocates of this work had chosen 
to spend their time and effort doing the actual work of moving crufty 
drafts to Historic instead of arguing about an official "procedure" 
for doing it, we'd be done now.

Margaret
.

---

From: Larry Masinter <[email-masked]>
Date: Thu, 14 Oct 2004 09:29:24 -0700

I wish the proposal were expressed in the positive sense rather
than negative.  Rather than a "Decommissioning Procedure",
talk about a "Retention Procedure".

The result may be the similar, but the sense of movement
and the purpose of the committee would be different. The
committee's job is to solicit someone making the case that
a document should not be moved to Historic, and, to some degree,
to evaluate the cases made.

Once the committee's charter is seen as a positive
progression rather than a negative, other activities
come to mind.

I'd like to see the committee not just solicit cases
of implementation experience and active use, but also
look for documents where the actual implementations and
use diverge from the document actually published, and to
solicit active work to update the specification to match
practice, or at least gather errata.

I'd like to see the documentation of active use and
implementation experience gathered, edited, and published
as a positive contribution that will improve the value
of the IETF's output.

If the work product is "some documents now classified
as Historic", that's not very valuable. If the work product
is "some documents' current status and use published,
others left to go to Historic", that's much more valuable
to the community.

Larry

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Margaret 
> Wasserman
> Sent: Thursday, October 14, 2004 5:58 AM
> To: scott bradner; [email-masked]
> Subject: Re: [newtrk] a crufty last call
> 
> 
> Hi All,
> 
> >consider this question
> mhonarc archive: 
> http://darkwing.uoregon.edu/~llynch/newtrk/index.html

.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 14 Oct 2004 19:12:15 +0200

> others left to go to Historic", that's much more valuable

I think the latter is pretty close to what you get with the current 
draft, although if there is a bias it is to leave the document status 
alone.  A record of use comes with.  In fact we go on to say that 
anything we leave alone really does require work.  What you're asking 
for is guidance on what work remains to be done.  There a change would 
be required.  It would basically demand that the Cruft Committee go 
check with experts to get their opinions on just that.  I think that's 
an improvement.

Eliot
.

---

From: "Alex Rousskov" <[email-masked]>
Date: Thu, 14 Oct 2004 11:15:38 -0600

>  described in the ID draft-ietf-newtrk-cruft-00.txt?"

"No" because, IMHO, we need to move away from placing each document
into a single box/folder to a model where each document may have
multiple labels/attributes attached, and where many "views" of the
IETF document set co-exist.

The failure of the current rigid one-document/one-label model is clear (to
me). Moving documents from one box to another is a waste of resources in
most trivial cases and a mistake in non-trivial cases (where neither of the
two boxes can be the only right place).

I hope that the multiple-attributes approach will help provide the
"right" information to IETF clients (where the definition of the
"right view" is often client-specific!).

If the Cruft proposal can be morphed into a "Let's document what folks
claim about each standard" proposal, I would support it (along with
a good interface to create and access claims).

Thank you,

Alex.
.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 14 Oct 2004 10:07:55 -0700

--On 14. oktober 2004 08:58 -0400 Margaret Wasserman 
<[email-masked]> wrote:

> I am not against the idea of moving documents that shouldn't be on the
> standards track to Historic, but I don't see any reason why we need a WG
> to develop processes to do that.  Nor do I understand why we need an
> officially constituted committee.
>
> It is my opinion that if the main advocates of this work had chosen to
> spend their time and effort doing the actual work of moving crufty drafts
> to Historic instead of arguing about an official "procedure" for doing
> it, we'd be done now.

If Eliot, by himself, had come up with a writeup to the IESG proposing to 
move 100 documents to Historic, without having had an IETF discussion that 
such was a good idea, would you have supported the action unconditionally?
Would the rest of the IESG?

I HOPE this is a rhetorical question - large shifts in how the IETF does 
business need community review before we put them into practice.

                        Harald

.

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 14 Oct 2004 13:34:14 -0400

At 10:07 AM -0700 10/14/04, Harald Tveit Alvestrand wrote:
>If Eliot, by himself, had come up with a writeup to the IESG 
>proposing to move 100 documents to Historic, without having had an 
>IETF discussion that such was a good idea, would you have supported 
>the action unconditionally?

No.  But I am not sure that I would support the same document from an 
official committee unconditionally, either.

I am not saying that Eliot should have done this alone.  At one time, 
you were talking about putting a more informal group together to do 
this work, and I would have rather seen you do that than having the 
newtrk WG do this work.  I don't think it is possible for a WG to 
manage a process, so I think you'll just end-up doing the same work 
to manage the process, anyway.

This WG has important work that I wish would receive the WG's full 
attention (standards track updates) and I see this cruft work as a 
distraction.  I raised that issue when the charter update came up 
around review, and I  was over-ruled.  So, clearly others disagree 
with me about this, which is okay.

Margaret
.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 14 Oct 2004 21:30:24 +0300 (EEST)

> Would the rest of the IESG?

Writing up a personal -00 draft, soliciting feedback on it on
appropriate public fora, iterating as necessary, and then asking e.g.
General Area AD to sponsor it for Informational RFC might not have
been treated too badly..  Just another document in the ballot..

But I agree that some kind of community discussion may be useful,
because to succeed, it takes more than one person to do the job.  
IMHO, no additional process is needed though, and we have been (IMHO)  
wasting a lot of time to try to get consensus on process changes when
any aren't needed.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 14 Oct 2004 11:07:27 -0700

> a good interface to create and access claims).

That is what the John/John proposal wants to do. I think it would be a 
mistake to make them depend on each other.

.

---

From: Larry Masinter <[email-masked]>
Date: Thu, 14 Oct 2004 13:53:18 -0700

I'm suggesting the name of the committee be changed
from the "cruft committee" to the "retention committee",
and the description of its charter changed from
"deciding what to throw out" to "deciding what to keep"
("save the baby committee", not "throw out the bath
water committee").

I don't have any objection to the process and actual
judgements to be made, I don't like the wording and
the criteria for success:

 A successful 'cruft' committee finds a lot of cruft.
 A successful 'retention' committee finds a lot
 of documents worth retaining.

The way I think of the work, we already have a standard
process that documents should move to Historic if they
have been at Proposed or Draft for too long, we've just
never implemented it because there was no process for
avoiding doing so in cases where it would be inappropriate.

So we don't need a new move-to-Historic process for
crufty documents, we need a progress-or-retain process,
so that we can finally implement what's already documented.

Larry

.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 15 Oct 2004 09:23:02 +0300 (EEST)

> so that we can finally implement what's already documented.

In a perfect world, I'd agree with you.  But as we don't live in a
perfect world, I think we have to look at how much work each direction
would require work to make our standards track base (or RFCs in more
general) to be more current.

I think making obvious stuff historic is much less work than trying to
figure everything to keep, or progressing some of those that should be
kept.

Both can be done, of course, if there are people willing to work on
this.

.