Subject: RE: [newtrk] question one for newtrk

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Wed, 2 Jun 2004 14:34:05 +0200

I am not sure I really believe our problems to address is
about how "externals" interpret our standards and their
expectations on our standard publications, as those are just
reflections of our own expectations and interpretations.
The problem that implementers around the world interpret
all RFC's to be "stable standards", and expect them not to
change is just natural as that is also the way we in the
IETF mostly handle our standards. As long as we do not
follow our own standards processes, we can not expect
others to believe in them as they were intended to work. 

So, I do not think it really matters if we for example
use new terminology or not, but what we must change is
our own interpretations of the standards track levels,
and our expectations on stability and completeness for
each level. It is not easily done, but I believe that
is where we must start, which is also what Scott's
question one is about.

/L-E

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Alex Rousskov
> Sent: den 1 juni 2004 18:02
> To: Larry Masinter
> Cc: [email-masked]
> Subject: RE: [newtrk] question one for newtrk
> 
> 
> 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: Keith Moore <[email-masked]>
Date: Wed, 2 Jun 2004 11:38:21 -0400

> is where we must start, which is also what Scott's

Scott's question one hinged on IESG review.  My problem with that
question is that it seems to presume a model in which IESG review
is only involved late in the process of developing a specification,
and I'm firmly convinced that IESG needs to be involved earlier.

I think a more appropriate question is what should be the requirements
for the first stable specification that we publish - that is, the first
specification that is going to be accessible from a well-known source,
and have a well-known name, indefinitely.
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html