Subject: RFC Errata proposals -- a missing piece

From: John C Klensin <[email-masked]>
Date: Mon, 02 Jun 2008 06:51:15 -0400

Hi.

Mark Andrews's recent note "RFC 3484 Section 6 Rule 9" suggests
to me that there is a missing piece in the recent IESG and RFC
Editor errata-handling proposals.  

Without taking a position on whether his particular change
should be made, there is a potential problem when maklng a
substantive change quickly is important.

I suggest that it would be useful to add an additional explicit
state category to the the RFC Editor's list, one that would
presumably be handed out of band (although I'd have no objection
to having it automated).   The description would read something
like the following:

	5. Standards change: When a document has been approved
	(via Protocol Action Notice or equivalent) that updates
	or obsoletes an existing Standards Track or BCP
	document, an erratum entry may be added that points to
	the action notice and the approved Internet-Draft.  This
	is intended to be a short-lived entry, providing
	information to the community for important cases during
	the period between IESG approval and publication of the
	new RFC.  These notices are intended to exceptional
	circumstances and will be added at the discretion of the
	RFC Editor (e.g., in circumstances when it appears that
	RFC publication of the new document will be delayed) or
	at the request of the IESG or a relevant Area Director.

In other words, while I agree that errata are an undesirable way
to  make a substantive technical change to a standards-track
document, I'm sympathetic to Mark's concern that the process of
getting consensus on, and publishing, an RFC may take too long,
especially given notions of 60 day publication holds to allow
for appeals.  This change would provide an errata-based
mechanism for warning the community that one or more provisions
of a standards-track document were already considered
inappropriate or obsolete, thereby largely cutting publication
delay out of the timeline, without introducing additional
process mechanisms or using errata inappropriately.

   john

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

---

From: SM <[email-masked]>
Date: Mon, 02 Jun 2008 08:40:04 -0700

Hi John,
>         at the request of the IESG or a relevant Area Director.

I suggest a minor change to the last sentence to emphasize the 
exceptional circumstances.  Instead of "These notices ...":

   This state is intended for exceptional circumstances.  The erratum 
entry will be
   added at the discretion of the RFC Editor (e.g., in circumstances 
when it appears
   that  RFC publication of the new document will be delayed) or at 
the request of the
   IESG or a relevant Area Director.

Regards,
-sm

---

From: John C Klensin <[email-masked]>
Date: Mon, 02 Jun 2008 12:39:57 -0400

--On Monday, 02 June, 2008 08:40 -0700 SM <[email-masked]>
wrote:

>> I suggest that it would be useful to add an additional
>> explicit state category to the the RFC Editor's list, one
>> that would presumably be handed out of band (although I'd
>> have no objection to having it automated).   The description
>> would read something like the following:
>> 
>>         (via Protocol Action Notice or equivalent) that
>>         updates or obsoletes an existing Standards Track or
>>         BCP document, an erratum entry may be added that
>>         points to the action notice and the approved
>>         Internet-Draft.  This is intended to be a short-lived
>>         entry, providing information to the community for
>>         important cases during the period between IESG
>>         approval and publication of the new RFC.  These
>>         notices are intended to exceptional circumstances and
>>         will be added at the discretion of the RFC Editor
>>         (e.g., in circumstances when it appears that RFC
>>         publication of the new document will be delayed) or
>    This state is intended for exceptional circumstances.  The
> erratum entry will be
>    added at the discretion of the RFC Editor (e.g., in
> circumstances when it appears
>    that  RFC publication of the new document will be delayed)
> or at the request of the

I have no strong preference.  The advantage of treating it as
"exceptional circumstances" is that it would not impose any
workload on the more normal cases in which getting word about
the change out was non-critical.    On the other hand, were it
not for whatever marginal resources that might be needed, having
a forward pointer in errata any time a document or major part of
it was about to be superceded  would certainly not be harmful.

   john

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 2 Jun 2008 13:34:44 -0700

>	at the request of the IESG or a relevant Area Director.

The idea that updates appear in the Errata database is a good one. As 
to your proposal: why make it temporary? In normal publishing, errata 
are for corrections of errors *and other changes*. Clearly, an update 
to an RFC is a change worth noting forever.

Right now, someone who wants to know what has changed in an RFC has 
to read the errata list *and* look at some view of the the RFC 
database to determine if the RFC has been updated, obsoleted, made 
historic, and so on. Having that notation in the errata list will 
help more readers, and hurt no one.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 2 Jun 2008 23:37:40 +0200

> The idea that updates appear in the Errata database is a
> good one.  As to your proposal: why make it temporary?

I don't see the point.  Folks often find an RFC on the IETF
tools server, the HTML version has any obsoleted / updated
by info.  Additionally it has a link to any errata, but for
this discovery method errata are not necessary to find the
obsoleted by / updated by info.

They might also find the RFC meta data with the RFC editor 
search engine, e.g., <http://purl.net/net/rfc/3700> or in
some Wikis [[purlnet:rfc/3700|RFC 3700]].  Same situation
as above, the RFC meta data directly offers any available
obsoleted by / updated by / errata info.

If what you propose boils down to "the errata should have a
backlink to the HTML version and/or to the RFC meta data"
it is of course fine, that is one simple global fix to the
errata user interface.

Apparently John's proposal was about the at least 60 days
between the approval of an obsoleting / updating RFC, and
the time when it gets its number.  For RFCs blocked by a
MISSREF that could be years or forever.  For RFCs killed
by an appeal it is forever, intentionally.

In both cases abusing the errata procedure to circumvent
RFC 2026 would be just that, net abuse.  And it is already
easy enough for folks risking it anyway, for an example see
the 1123 RFC errata - hopefully IDNAbis will sanction this
stunt in a real standards track RFC.

 Frank

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 2 Jun 2008 15:18:30 -0700

>it is of course fine, that is one simple global fix to the

That works for me.

>by an appeal it is forever, intentionally.

The RFC metadata referred to above could be updated at the time a new 
RFC is approved in its stream, not at the time the RFC itself is 
published.

--Paul Hoffman, Director
--VPN Consortium