Subject: RE: [newtrk] question one for newtrk

From: Alex Rousskov <[email-masked]>
Date: Tue, 1 Jun 2004 10:02:08 -0600 (MDT)

On Mon, 31 May 2004, Larry Masinter wrote:

> I think the internet community would be best served if NEWTRK would
> make the fewest number of changes to standards track as possible

Making no more changes than necessary is highly desirable, of course.
Changes depend on what problem we are trying to solve. If we believe
that one of the problems is wrong perception that all RFCs are equally
stable, then the only practical way to fix that in IETF context is
stop calling less stable documents "RFCs".

> whenever you change the process, you wind up with some of your
> documents under the old process and some under the new process, with
> even more confusion.

I am not sure whether the correct fix will result in more long-term
confusion, especially if we can semi-automatically assign new labels
to existing RFCs so that the new namespace covers all published IETF
documents. But this is an abstract discussion; we need to compare
specific alternatives to find the one that causes less confusion.

> If people can't tell which RFCs are stable and which ones
> aren't, it isn't really necessary to change the titles,
> add version numbers, etc.
>
> You could give people more information by annotating every
> RFC (even the old ones!) with
>
>  See http://www.ietf.org/status/rfcNNNN.html for more information.

This is already done and it is not working, apparently. Most (all?)
RFCs are carrying "Status of this Memo" section. A careful read of the
referenced STD 1 would tell the reader that Proposed Standards may not
be very stable, etc. Apparently, very few people who make
implementation and deployment decisions read that section (so it does
not matter how current it is).

> and then providing more information: has it been implemented,
> are there open issues that haven't been resolved, is it believed
> to be obsolete, etc.

Errata and "obsolete" information is also already provided for each
RFC. The core problem, as we are being told, is not the lack of
information but wrong perception that "RFC" means "stable" and all
other labels are not really meaningful.

> I'm puzzled why people are so eager to change the current
> standards track rather than work on ways to make it work better
> first, and changing it only when absolutely necessary.

To make something work better, you have to change it. You may be
surprised that some folks propose "bigger" changes than what you think
is sufficient. Those folks probably do not think that smaller changes
are going to work as well or at all.

> > Yes, majority of RFC users believe that all RFCs are "stable".  That
> > belief cannot be changed by new cycling system or deletion of expired
> > documents from some repository. It can only be changed by not using
> > the term "RFC" with something that we believe is not mature, stable,
> > and endorsed enough.
>
> I disagree "it can only be changed".  If it were easy to determine
> the status of an RFC in an obvious way, we wouldn't have as much
> trouble. The problem right now is that the status of the RFC that
> is *in* the RFC doesn't change over time, and so nobody can trust
> it. It says "Proposed Standard" and you have no idea how many
> people use it, and whether errors have been discovered.

While I am all for documenting current state, and while I agree that
current implementation reporting and errata management processes need
a lot of improvement, I disagree that more-up-to-date and
easier-to-find information is going to solve the problem. The people
who are calling the shots are not going to dig through all that
information.

Decision makers need a simple labeling system that tells them whether
something is a stable IETF standard or not. Letting them know that
there are 10 errata entries and 3 implementations is not good enough.
It's not the kind of information they can use. They need a yes/no
answer, or a close approximation of that. And they want that answer
officially coming from IETF, not their own engineers (their opinions
may vary).

As of today, that answer is available to them in a form of the "RFC"
word. If it is an RFC, then it is perceived as good enough.

> I don't think we can fix things merely by applying new words,
> because no one pays any attention to the status of a document
> when the status itself doesn't track over time.

I agree. It seems to be that both using "new words" and keeping
assigned words current are needed.

> You can't really tell if a 'proposed standard' is stable WHEN
> IT ISSUES.

I can. It is not stable when it is published. See previous discussion
on iterations/revisions: We cannot make error-free standards on the
first try. We need iteration. (This assumes that IETF strives for
quality and, hence, fixes or removes broken standards).

> You can only tell after some time. I don't think
> the nomenclature for software releases is applicable for standards,
> because software updates are (appropriately, I think) more frequent
> than standards updates.

I do not see how relative frequency of updates changes anything. If we
assume no updates, then software analogy would not be applicable. If
we assume that IETF fixes/removes broken documents, then I do not see
any essential differences with software world. Why does it matter how
frequent updates are?

> A software 'release' need only be stable until the next release.
> This isn't the case with standards.

Not sure what you mean, both for software and standards. Mature
software often has several stable releases available and deployed at
the same time. So can standards. When there is a choice, the latest
stable release should be used, of course.

> I think it's inappropriate because the entire system proposed is
> predicated on assigning release 'numbers' when the documents are
> finished, while what we mainly need is retrospective information on
> older specifications about whether they remain valid after they've
> been issued.

Release numbers is simply how you reference a published version of a
document. What you do with that reference (declare that version
obsolete, stable, invalid, etc.) and how often you do that is a
higher-level question that we still have to address.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 02 Jun 2004 08:41:18 +0200

This all seems very familiar, and the relevant parts of RFC
3774 are the result of previous iterations of this discussion.

Could people focus by

a) suggesting missing options for inclusion in section 2
of draft-black-newtrk-proposals-00.txt?

and

b) suggesting pro and con arguments to be put in section 3
of draft-black-newtrk-proposals-00.txt?

     Brian

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 2 Jun 2004 20:53:00 -0500

Hi, Brian and David,

Thanks to both of you for taking this on.

Yes, we have been here before.

> of draft-black-newtrk-proposals-00.txt?

This isn't exactly what you asked for, but...

- one option, obviously missing, is changing our documented process to
match the process we're actually using. Maybe what we have now is the
best we can get, given where we are, and we haven't actually changed
anything yet. If we don't change anything, we should write down what
we do so everyone will know.

- It was obvious to Scott that a snapshot, should such a thing exist,
was part of the standards track, but it was obvious to me that
snapshots were orthogonal. If we're going to talk about snapshots as
part of the standards track, it might be useful to include the
decision points I put up in
http://www.ietf.org/proceedings/04mar/slides/newtrk-1/sld5.htm.

But my experience since Minneapolis was that snapshots sucked all the
oxygen out of the standards track discussion, and I would rather have
a standards track that worked, and worked as documented, than
snapshots, if I could only have one.

> of draft-black-newtrk-proposals-00.txt?

Actually, I would suggest at least one pass on section 2, to make sure
we've characterized the proposals, before we spend a lot of time on
section 3. This draft is trying to summarize an ocean of minutia from
IDs and mailing list postings - for instance, we've discussed not
calling anything "XXX Standard" until "the final stage", so Proposed
Standard became Proposed Specification, etc. Let's focus on getting
our choices down clearly, and then focus on pros and cons.

And, just a note - Brian has spoken persuasively in favor of one-stage
standards a couple of times, and I like what he says, so I'm thinking
"slash and burn" is too perjorative. "bonsai", maybe? like, it's as
small as it can get and still be a tree, if you keep the horticultural
metaphor...

Spencer

.

---

From: Keith Moore <[email-masked]>
Date: Wed, 2 Jun 2004 23:35:59 -0400

> snapshots were orthogonal.

and it's been obvious to me all along that merely including snapshots 
is insufficient - we need to at least have some shared notion of how to 
produce the (perhaps even more ephemeral) drafts that logically precede 
"snapshots".

Keith

.