Re: Proposed IESG Statement Regarding RFC Errata for IETF Sream RFCs

[John C Klensin <[e-mail]>]

--On Thursday, 17 April, 2008 08:45 -0700 Lisa Dusseault
<[e-mail]> wrote:

> I can assure you, I at least was anticipating that the IESG
> (and other   people handling errata) would be doing *more*
> work in classifying   errata if we have the three categories.
> The goal as I see it is to   avoid presenting 50 errata on an
> RFC to a user, without any sorting or   focus, when only three
> of them are crucial to interoperability.  If we   overwhelm
> implementors with more than a page worth of errata, most of  
> which are junk, implementors will be well justified in
> ignoring errata.
> 
> An important part of the errata handling, therefore, is to
> make the   difference clear to the implementor.  When an
> implementor clicks   "Errata" for an RFC, they should see the
> short-list of crucial errata   and at the end, a link to
> "Other possible errata" (or other wording). 
>...

--On Thursday, 17 April, 2008 10:39 +0300 Jari Arkko
<[e-mail]> wrote:

>> change proposals. That procedure needs to be separate from
>> the errata process, and it the best place for it would
>> probably be at @ietf.org. 
> 
> Indeed. But please note that the satement is not to be taken
> as a recommendation that substantial change proposals be
> submitted as errata. You are quite correct that they should be
> pursued as WG work, as BOFs, drafts be written, etc. However,
> in the event that someone does send an errata about the
> redesign of the protocol we need to know how to deal with it
> :-)

Hi.  I had planned to just let this go by on the assumptions
that it was not likely to be terribly harmful and that it could
be fixed later if it turned out to not work.  However, your two
sets of comments have convinced me otherwise.

For standards-track materials, errata are part of the much more
general problem of "what do I need to know to implement and
understand this?"  The answer to that question includes several
types of complaints about putative errors in the text, related
documents and their relationships, statements about protocol
maturity (and implementations and deployment), comments about
how much particular provisions can be believed relative to
others, suggestions for a queue of possible changes to be
examined when the document is reopened, and so on.  

Each time we have looked closely at the broader problem, we have
concluded that trying to make a small list of categories and
then force things into them creates a lot of work, ties people
in knots about edge cases in the categories, and often doesn't
really help illuminate the situation.   We've seen that problem
with categories of "Standard", "Draft Standard", "Proposed
Standard", "BCP", etc. I predict that we will see it for
"Approved", "Rejected", and "Archived" and that the number of
"will X be available" and "what does Y mean" questions on the
list point strongly to that conclusion.

The last time we tried for a comprehensive solution to this
problem, the IESG declined to consider it, partially on the
grounds that it would be too much work for the IESG.  Now the
IESG has posted a proposal that is less clear about the
framework and how the pieces are put together, addresses only
one part of the issues, but that calls for the IESG to do a very
large fraction of the work  that was the putative cause of the
dead end we got into the last time.

Give that, I suggest that you consider two options:

(1) Divide recommended errata into only two categories:

(i) Changes that would affect the protocol definition in a
substantive way, even if they appear to be correcting a known
error and to already be reflected in deployed practice.  My
preference, in the current environment, is that this type of
change be reflected in a conventional, "updating" RFCs that is
processed according to the normal standards-track rules.  I can
see reasons for not doing that.  If the IESG does, then this
category should be described in a way that clearly makes it an
"interim update".  I also believe that such changes should be
subject to IETF Last Call for reasons I hope are obvious.

(ii) Everything else.  Like Paul Hoffman, I don't believe that a
major effort to classify things is likely to be worth the
trouble it would take, at least if we are viewing all of this as
"errata".  Whether you just lose the protocol changes that don't
qualify for (i) or identify them as "not considered as a
candidate" or "considered and rejected as a candidate" is up to
you.  Either way, there is a strong hint to the reader that
there is no demonstrated community consensus that the proposed
change has merit and that the specification should be followed
as written.

    --or--

(2) We reopen the broader question, figure out which parts of it
are important to attack first, and move forward.  I suspect
someone could even be found to post the most recent version of
the spec that covered this as an I-D if the IESG were interested.


Good luck in either event.
        john






_______________________________________________
IETF mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf