ietf
[Top] [All Lists]

Re: Work effort? (Re: Proposed Standard and Perfection)

2004-03-12 10:55:25


--On Monday, 08 March, 2004 13:26 -0500 Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu> wrote:

It's all well and good to try to retire Proposed Standard
documents that don't get implemented.  But I think it's even
more important to make it easier for documents that do meet
the criteria to advance to Draft Standard.  In my experience
the hardest part of getting a document advanced is to collect
the implementation report.

Interesting. I would have described the hardest part as lying in the documentation process itself, in particular...

        * When a document has been very controversial in getting
        to Proposed, at least partially because of very loud and
        continuing objections about specific points from those
        who disagreed with them, it is often hard for authors,
        editors, [former?] WG Chairs, etc., to get up the energy
        to deal with what is likely to be a renewed version of
        the unpleasantness.
        
        * When one or more IESG members have engaged in
        extensive, time-consuming, and unpleasant nit-picking or
        bickering about provisions of the original, Proposed,
        document, authors/ editors/ WG Chairs may have the
        reasonable expectation that they would do an even
        "better" (more extensive) job on a draft coming up for
        Draft.

and

        * Documents that are, themselves, perfectly ready to
        advance get stalled indefinitely because they make
        normative references to documents or protocols that, for
        one reason or another, less ready.

The discussion below does not address the third point; I don't know quite what to do about it.

Note that none of these issues is intrinsically related to the protocol quality or deployment of the specification. What the first two share with the "implementation report" issue is that the documentation issues are independent of the underlying reality.

Hence this modest proposal:

- For each standards-track document, create a web page that is
used to   keep track of bug reports, errata, implementation
reports, and test   reports.
...

My not-very-modest proposal (many details would need filling in, but, as an idea...):

        (1) We decouple "change maturity levels" from "write and
        publish an RFC" (this means that the listing of maturity
        levels must be current and authoritative).  This also
        meshes nicely with another proposal that was floated a
        few years ago, but never really written up (see below)
        
        (2) When a document comes up for review for
        Proposed->Draft, we look for implementations, etc.,
        perhaps following Keith's proposal outline.  If the
        implementations are there, we issue a Last Call for
        identification of serious technical/definitional flaws
        in the document as published, where "serious" is defined
        as "problematic enough to interfere with independent
        interoperable implementations".  If none are found, we
        advance the maturity level of the document, in place --
        no new RFC publication required and hence little or no
        opportunity to reopen old wounds that lack demonstrated
        interoperability impact.  If the document is about to
        time out in grade, we issue a Last Call, wait a
        reasonable period for protests and volunteers, and then
        downgrade it in place.  The notion of having to write an
        RFC, following all of today's complex rules, and get
        formal consensus in order to declare a Protocol obsolete
        that isn't implemented and won't operate in today's
        environment is one of the more astonishing triumphs of
        bureaucracy over rationality.  Similar rules would apply
        to Draft->Full (or whatever formula newtrk comes up
        with).
        
        (3) If a document is judged defective (which is
        difficult from judging a protocol defective), we try to
        find someone to fix it.  If a plan (and volunteer(s))
        cannot be readily found, we publish a description of the
        defect(s), presumably as an RFC, but, if that is
        unworkable, in some other way.   Minimize the fuss -- if
        our customers don't think an updated document is worth
        the trouble --enough trouble to invest people, dollars
        for professional editing, or whatever else is required--
        then we should stop losing sleep over it.

Principle: If we are going to spend as much time and energy as we do getting something to Proposed, then moving it to Draft or Full should usually require only identification of implementations, deployment, and desirability, not extensive and time-consuming document rewriting

      john

--------------

Footnote -- that other proposal: Some time ago, I noticed that the relationship between the STD definitions and the underlying RFCs had gotten a little too complicated for anyone to usefully understand. By being reserved to full standards, the STDs also did not help with hints about things advancing along the standards track (e.g., a Proposed document that has fairly wide consensus and that is intended to ultimately replace a full standard is a very funny state today). That produced some informal discussion of an idea of actually turning STDs into documents, rather than references in an index. A typical STD document, which could be issued for a Proposed Standard, under that proposal, would consist of

        * A title and abstract, which might differ from the
        underlying documents if there were several of them.
        
        * Any discussion of what made up the standard and why
        that was felt to be necessary.  If there is any useful
        content in, e.g., the IESG's Protocol Action notice, it
        could be included there as well.
        
        * Any short statements about applicability, maturity
        levels, recommendations (remember mandatory/
        recommended/ optional ?) that didn't justify publication
        elsewhere.  Note that this might be a place to correct
        significant errata and descriptions of deficiencies in
        the definition.
        
        * A change history, so that one could easily tell which
        RFCs were part of what standards at what times.

And, unlike RFCs, an STD document would change as standards evolved.

I don't know if it was a good idea, but it would mesh nicely with some of the other ideas that have been floating around. I can write it up if there is serious interest, but have no plan to do so at present.

   john