----- Original Message ----- From: "Phillip Hallam-Baker" <hallam@xxxxxxxxx> To: "t.petch" <daedulus@xxxxxxxxxxxxx> Cc: "Keith Moore" <moore@xxxxxxxxxxxxxxxxxxxx>; <ietf@xxxxxxxx> Sent: Friday, October 29, 2010 11:54 PM > 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. Phillip One slight correction; I can and do understand the purpose of this proposal and consider it irrelevant to the problems I see posted on this list. I think that Ted's summary of the problem is a good one. Tom Petch > > 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 <daedulus@xxxxxxxxxxxxx> 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" <moore@xxxxxxxxxxxxxxxxxxxx> > > To: "Yoav Nir" <ynir@xxxxxxxxxxxxxx> > > Cc: <ietf@xxxxxxxx> > > 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@xxxxxxxx > > > https://www.ietf.org/mailman/listinfo/ietf > > > > > > > _______________________________________________ > > Ietf mailing list > > Ietf@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/ietf > > > > > > -- > Website: http://hallambaker.com/ > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf