Subject: [newtrk] Erata in ISDs problematic

From: Sam Hartman <[email-masked]>
Date: Tue, 10 May 2005 11:08:05 -0400

Hi.  I have some personal comments beyond what the IESG came to
consensus on.  There may be some people on the IESG who disagree with
me on these comments; there are certainly people who agree.  The
discussion at the retreat focused on other issues we all felt were
more important and so we did not fully explore our position on these
issues.

I think including erata to published RFCs in ISDs is very problematic
and strongly oppose doing so.  I am even more opposed to using ISDs as
a mechanism for removing features from standards that have not been
widely implemented.

As an implementer of IETF standards documents and someone who has
engaged in interoperability testing, I find that as the number of
documents involved increases, the clarity of implementers'
understanding decreases.

I don't find implementers are generally in the habit of checking RFC
erata.  I don't think ISDs will tend to be consulted more often.

Also, the approval process required for an ISD will be approximately
the same for a new RFC.  If the problems have been identified and
sufficient text written and we're going through a full approval
process then just publish a new document.  If RFC publication is too
slow, work on that problem not on creating new infrastructure.

My concern is also based on hundreds of years of experience with a
similar system: acts of legislative bodiies.  AT least in the United
States, legislatures tend to pass diffs rather than passing new laws.
This is easy for the legislatures but is difficult for those trying to
use the law.  It's sufficiently difficult that an entire office in the
US federal government has been developed to apply these diffs to the
US Code and produce a current
(presumed-authoritative-until-evidenc-presented) set of laws.

I think all the pressures that make amendments problematic for the
legislative system would apply to ISDs for all the same reasons.  I
hope we'll be approving a lot fewer ISDs than the US government
approves laws.  Even so I think the same problems would apply to us.
Without a similar mechanism to keep patched copies of RFCs around I
believe the proposal of erata in ISDs is unacceptable.

--Sam

.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Joe Touch <[email-masked]>
Date: Tue, 10 May 2005 10:27:18 -0700

> a mechanism for removing features from standards that have not been

The alternative would be to reissue the RFC with the correction
included. Instead of a primary document and an errata, this results in a
new RFC.

Since RFCs don't disappear, it's entirely possible that an unclueful
implementer will implement the earlier RFC. We're comfortable addressing
this situation by modifying the header of the earlier RFC to say
"obsoleted by".

Why isn't it equally useful to say "See errata #XXX for required
corrections"?

It seems that both are equally well-labelled, and both have some
probability of implementers missing the mods. The errata version has the
benefit of not issuing unnecessary RFCs just to fix typos, and reduces
the probability of incurring a typo in the new RFC.

Note that I'm referring to errata; changes in content that are not
accidental should not be listed as errata, but new RFCs should be
issued, as you noted.

...
> (presumed-authoritative-until-evidenc-presented) set of laws.

One question to ask is WHY they do diffs; IMO, it's to avoid
modifications other than the diffs. Once you rewrite, you open the whole
document to revision. That's what lawmakers try to avoid, and we should too.

Joe
.

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 10 May 2005 14:29:39 -0400

> documents involved increases, the clarity of implementers'

Good observation, but what's the solution?  Consider MIME; the core
MIME specification reserves the header field prefix "Content-" for
MIME extension fields (RFC 2045).  Many such fields have been
specified, e.g. Content-Language (which is certainly applicable to
text and audio media, but probably not image media), Content-Duration
(applicable to audio and video, but not text or image), etc.  Given
the specialist nature of some of these extensions, surely the answer
isn't to lump everything into a single 300-page document.
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Sam Hartman <[email-masked]>
Date: Tue, 10 May 2005 14:56:00 -0400

>>>>> "Bruce" == Bruce Lilly <[email-masked]> writes:

    Bruce> On Tue May 10 2005 11:08, Sam Hartman wrote:
    >> As an implementer of IETF standards documents and someone who
    >> has engaged in interoperability testing, I find that as the
    >> number of documents involved increases, the clarity of
    >> implementers' understanding decreases.

    Bruce> Good observation, but what's the solution?  Consider MIME;
    Bruce> the core MIME specification reserves the header field
    Bruce> prefix "Content-" for MIME extension fields (RFC 2045).
    Bruce> Many such fields have been specified, e.g. Content-Language
    Bruce> (which is certainly applicable to text and audio media, but
    Bruce> probably not image media), Content-Duration (applicable to
    Bruce> audio and video, but not text or image), etc.  Given the
    Bruce> specialist nature of some of these extensions, surely the
    Bruce> answer isn't to lump everything into a single 300-page
    Bruce> 

The answer as always is to do good engineering and to balance
tradeoffs.

I'm specifically arguing that having ISDs make changes to the RFCs
they reference does not strike an appropriate balance on that issue.

In other words, I used a general observation to support a specific
argument.  I was not trying to solve the general problem I brought up.

.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 10 May 2005 22:02:06 +0300 (EEST)

> this situation by modifying the header of the earlier RFC to say

Not true; existing RFCs are never modified, only the RFC index.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Joe Touch <[email-masked]>
Date: Tue, 10 May 2005 13:12:04 -0700

> Not true; existing RFCs are never modified, only the RFC index.

Sorry - I was thinking "Obsoletes"; this makes old RFCs even harder to
distinguish. Anything that indexes the new version can just as easily
index the combination of the new and errata; IMO, checking errata should
be common practice anyway.

Joe
.

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 10 May 2005 16:38:00 -0400

> included. Instead of a primary document and an errata, this results in a
[...]
> accidental should not be listed as errata, but new RFCs should be

RFC 2026 provided for issuing new RFCs.  It does not explicitly provide
for the RFC Editor errata page.  Nevertheless, you are correct in noting
that errata provide a lighter-weight mechanism than rewriting an RFC.
A rewrite involves:

1. production and publication of a new Internet-Draft
2. some review, typically a Last Call
3. IESG review and a decision
4. Editing
5. Publication

The first step might take only a day, if the author or editor has kept
some copy up to date, and has up-to-date production tools (current
boilerplate, etc.).  Conversely, just before an IETF meeting, it might
be delayed by 3 weeks due to blackout periods.

The duration of the second step depends on the type of document and
whether or not there is an active WG.  If we confine the discussion to
Standards Track and presume that the IESG continues to disband WGs, that
means that the revision would be treated as an individual submission
and would be in Last Call for a minimum of four weeks.

In steps 2 & 3, a reviewer, possibly an AD, might notice some flaw
unrelated to the correction and request a change.  Theoretically at least,
the process could drag on indefinitely.  Such changes might require a
change in document status, such as a reset to Proposed.

Step 4 should be simple, but even a one-word change can cause layout
changes to ripple through a document.

The most optimistic scenario is four weeks; realistically, probably
closer to four months.  Normally (pure errata) the status and time-to-review
would be unchanged at the end of the process.

In practice, when the standards process is working properly, as noted
in RFC 2026, such small changes are often batched at the time of the
next step on the Standards Track, except where there is some urgency.

In theory, the RFC Editor errata process is simpler (*in theory*). The
error is brought to the attention of the author, who approves the erratum,
notifying the RFC Editor, who updates the errata page.  In practice, some
authors or editors are unwilling to approve changes for various reasons.
Theoretically, a cognizant AD can approve errata in such a case.  The
process can sometimes be quick and painless; in other cases it can drag
out literally for years.

We could continue with a multi-step Standards Track and RFC Editor errata,
publishing critical errata via the RFC Editor and holding less serious
ones for the next stage.  It is true that the Errata page isn't always
consulted by implementors; some boilerplate pointing to the Errata page
in each RFC would help.  As the Errata page is in a (more-or-less) fixed
location, it *can* be referenced that way.

Errata in a separate document, however, does have the drawback that there
is no predefined place that an RFC can point to for updates.  That is a
problem with errata exclusively in an ISD document; avoiding that
problem means either continuing with the RFC Editor Errata page or
reissuing RFCs as errors are found.  If the Standards Track multi-stage
process is to be flushed down the drain, that means no "next stage" and
therefore republication (plus an ISD update) as each error is found. That
is hardly likely to improve efficiency, as that is a fairly heavyweight
process as outlined above.  I'm assuming that we don't want current
documents (as distinct from obsolete or Historic ones) to have outstanding
errata indefinitely.
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 May 2005 11:27:27 +0200

> is no predefined place that an RFC can point to for updates.

Actually there is no reason why all future RFCs can't include
boilerplate saying:

  If there are any known errata for this document, they can
  be found at http://www.rfc-editor.org/errata.html

    Brian

.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 11 May 2005 12:31:35 +0300 (EEST)

> be found at http://www.rfc-editor.org/errata.html

Or, "check the current status of this document at XXXX".

This might lessen the confusion in cases where e.g., standards track 
documents have been obsoleted or historicized, and there's no forward 
reference -- the readers would just need to go look from the RFC 
index, no the RFC itself.

That would possibly be a valid use for ISDs; however, as you point 
out, it'd be good to ask whether the same can be achieved using more 
light-weight mechanisms.

---

From: Bruce Lilly <[email-masked]>
Date: Wed, 11 May 2005 07:44:06 -0400

> > be found at http://www.rfc-editor.org/errata.html

Yes, but my point was that pointing to another document (as distinct
from the more-or-less stable location of the Errata page) is a
potential problem.  In particular, pointing to an ISD is a problem
unless the ISD is always published no later than the RFC. And it
would be a problem if, for whatever reason, a different ISD
document becomes applicable post-publication.
 
> index, no the RFC itself.

RFCs could also contain boilerplate such as "The status of published RFCs
may change and is maintained in the rfc-index, and errata may be published
from time to time.  More information is available at
http://www.rfc-editor.org/rfc.html.", which covers errata as well as
the rfc-index.
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 May 2005 17:22:14 +0200

> http://www.rfc-editor.org/rfc.html.", which covers errata as well as

I'm unhappy about pointing to the present structure at
http://www.rfc-editor.org/rfcxx00.html in particular, because
it fails to tell you that (for example) 822 is replaced by 2822.

    Brian

.

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 12 May 2005 13:27:58 -0400

> it fails to tell you that (for example) 822 is replaced by 2822.

N.B. "rfc" != "rfcxx00".

The page at the URI which I suggested provides links to the Errata page
as well as to the rfc-index.txt document (which does say that 822 is
"Obsoleted by RFC2822").

Other text or URIs might be possible. The key points, it seems to me, are:
o status is maintained in the rfc-index
o errata may appear
o the boilerplate should be reasonably brief and concise.
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html