Subject: Re: what is the problem bis

From: "t.petch" <[email-masked]>
Date: Mon, 1 Nov 2010 11:11:42 +0100

----- Original Message -----
From: "Phillip Hallam-Baker" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Keith Moore" <[email-masked]>; <[email-masked]>
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 <[email-masked]> 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" <[email-masked]>
> > To: "Yoav Nir" <[email-masked]>
> > Cc: <[email-masked]>
> > 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
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/ietf
> > >
> >
> > _______________________________________________
> > Ietf mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/ietf
> >
>
>
>
> --
> Website: http://hallambaker.com/
>

---

From: John C Klensin <[email-masked]>
Date: Fri, 29 Oct 2010 16:05:09 -0400

--On Friday, October 29, 2010 12:20 -0400 Hadriel Kaplan
<[email-masked]> wrote:

> 
> On Oct 27, 2010, at 9:57 PM, Keith Moore wrote:
> 
> 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
>...

Hi.  

It is difficult to imagine how these sorts of idea would work in
conjunction with RFCs given that those are explicitly archival,
never-changing documents and your suggestions seem to imply
evolving classification and comment systems.

However, a number of similar ideas --including effectively
replacing Standards-Track Maturity levels with more descriptive
text and finer-grained comments were incorporated into a
proposal to the NEWTRK WG in 2005-2006.   I think it is safe to
suggest that the reasons why the proposal never went anywhere
remain controversial, but you might find it interesting
recreational reading:

https://datatracker.ietf.org/doc/draft-ietf-newtrk-repurposing-isd/

     john