I am finding this discussion difficult to parse. Here we have a post that says 'I can't understand the purpose of this proposal', then suggests solving a completely different problem and declares the proposal irrelevant.
There are multiple reasons for the two step proposal, we do not all have to agree on them all. But it should be fairly obvious that the problem two track is intended to address is the number of times a document is required to go through the RFC process. It is not an attempt to address the length of time the process takes. I have yet to see a single poster state that they think that the three step process is working. On the other hand we are managing to issue RFCs. On Fri, Oct 29, 2010 at 4:54 AM, t.petch <daedu...@btconnect.com> wrote: > As an engineer, I do like to know what problem I am required to solve > before > proposing a solution:-) My reading of this thread is that the problem is > the > length of time it takes to produce an RFC of any kind, that vendors are off > to > the races at the fifth or tenth version of an I-D stage because the market > will > not wait for the machinations of the IETF (and as a consequence, to most > people, > the differences between PS, DS and FS are irrelevant). > > As such, draft-housley-two-maturity-levels seems an irrelevance, a > distraction > from the issues facing the IETF. If there is a problem worth solving in > the > space occupied by draft-housley-two-maturity-levels, then Keith's proposal > for > an orthogonal set of measurements of document quality seem far more apt. > > By contrast, the delays in producing an RFC seem to revolve around WG > process, > where Last Call causes people to come out of the woodwork with delaying > suggestions, something a good chair or AD would stamp on, and IESG process, > where certain hot buttons - eg security, flow control - produce some > ludicrous > DISCUSS' which delay the process for months. > Tom Petch > > ----- Original Message ----- > From: "Keith Moore" <mo...@network-heretics.com> > To: "Yoav Nir" <y...@checkpoint.com> > Cc: <ietf@ietf.org> > Sent: Thursday, October 28, 2010 3:57 AM > Subject: Re: what is the problem bis > > > > On Oct 27, 2010, at 8:58 AM, Yoav Nir wrote: > > > This comes back to the question or why have maturity levels at all. > Ideally, > an implementer should prefer to implement a mature standard over a > less-mature > one. In practice, adopting the more advanced standard may give you an > obsolete > protocol, rather than a more stable one. IOW the standardization level of a > document does not give a potential implementer any signal as to whether or > not > this standard is in any sense of the word "good". > > Mostly agree. The distinction between an older, well-tested, > widely-deployed > version of a protocol vs. a newer less-tested, less-widely-deployed version > with > more features is a useful distinction to make. but the difference between > (RFC > X, full) and (RFC Y, proposed) where Y >> X only conveys the barest hint of > that, and even less in the way of guidance. I'm thinking specifically of > email > standards here, where in practice you need to be able to accept RFC 822 > messages > (because even new mail readers have to be able to deal with old messages) > but > you should generate messages that conform to 5322 and MIME. > > > And if it doesn't signal anything to the "customers" of the documents, > what's > the point of having these levels at all? > > That's why I think we need a different set of labels, e.g. > > Protocol-Quality. We need a statement about the perceived quality of the > protocol described in the document. (Is this protocol well-designed for > the > anticipated use cases, or does it have significant flaws (including > security > flaws)?) > Applicability. We need a statement about the current applicability of the > protocol described in the document. (Is this protocol recommended for > general > use, not recommended except in specific corner cases, not recommended at > all, or > strongly discouraged?) > Document-Quality. We need a statement about the perceived quality of the > document itself and whether the protocol description seems to be > sufficiently > precise to permit implementations to interoperate. (along with a pointer > to > errata.) > Maturity. We need a statement about the amount of actual implementation > and > deployment experience that the protocol enjoys. > Completeness. We need a statement about how accurately the document > reflects > what is currently believed to be good practice for implementation/use of > that > protocol, or whether effective implementation requires information not > included > or referenced in the document. (e.g. effective implementation of SMTP > generally > requires some expertise in dealing with heavy loads caused by spam, > looping, and > denial-of-service attacks which aren't really dealt with in any of the > relevant > RFCs). > Last-Review-Date. Date of the last review of these labels for this > document. > > These would go alongside the existing Updates and Obsoletes labels. An > Applicability-Statement could also be included. > > It strikes me that we could establish such a set of labels on an > experimental > basis, using some sort of community review process for existing RFCs, > without > making any immediate changes to our proposed/draft/full system of labeling > of > standards. IESG could assign the initial labels for new RFCs - the > document > reviewers are almost doing that anyway. The existing errata process could > be > extended to allow (moderated) user comments on these labels, and the labels > could be subject to periodic review based on those comments. > > If that labeling system turned out to be adequate or could be fixed with > some > tweaking, we could maybe drop back to two document classes: Informational, > and > Standards-Track. Standards-track would encompass any former proposed, > draft, > or full standard which was still in use and for which periodic reviews were > still being done. Former Experimental documents would be reclassified as > Informational with appropriate descriptive labels. Former Historic > documents > would be reclassified as Informational with Applicability set to Historic. > Standards-track documents would expected to have periodic review of these > labels; Informational documents could have some of those labels set to > "Undetermined". > > Keith > > > > > > -------------------------------------------------------------------------------- > > > > _______________________________________________ > > Ietf mailing list > > Ietf@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > -- Website: http://hallambaker.com/
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
