[rfc-i] Errata process

Joe Touch touch at isi.edu
Mon Apr 22 15:09:09 PDT 2013


Hi, Nico,

On 4/22/2013 2:57 PM, Nico Williams wrote:
> A better example of a recent errata submission is this:
>
> http://www.ietf.org/mail-archive/web/dane/current/msg05604.html
> http://www.rfc-editor.org/errata_search.php?rfc=6698&eid=3594
>
> Here we have an example where a WG was being non-responsive about a
> significant problem in an RFC.  An implementor (who does not author
> RFCs, though perhaps we can change that) submitted an errata and this
> finally got attention.  The errata seems rather reasonable to me, but
> maybe you can examine it and tell me why it's not.  But even if it's
> not, the process was useful nonetheless.

The new text is:

---
  Since clients cannot
  be presumed to have their own copy of the trust-anchor certificate,
  when the TLSA association specifies a certificate digest, the TLS
  server MUST be configured to provide the trust-anchor certificate in
  its "certificate_list" TLS handshake message.
----

IMO, this is a very clear example of "Hold for update" based on:

7. Changes that modify the working of a protocol to something that might 
be different from the intended consensus when the document was approved 
should be either Hold for Document Update or Rejected. Deciding between 
these two depends on judgment. Changes that are clearly modifications to 
the intended consensus, or involve large textual changes, should be 
Rejected. In unclear situations, small changes can be Hold for Document 
Update.

----

It adds a new MUST that wasn't in the original document. Yes, the 
original doc had an omission of this case that severely impacts its 
implementation, and yes it's important to fix, but no, it's not merely 
an errata.

> Also, quite aside from whether the above errata submission is
> reasonable, what do you want the process to be, if you don't like it
> as it stands?

First, I want it to be a documented part of an RFC, not just an IESG 
assertion. Second, it seems important that only vetted and approved 
comments be posted; hold for doc update and especially rejected errata 
should not appear with the doc, even labeled as such. Finally, I would 
like the process to be more clear about how this works for 
non-IESG-stream docs (although it's fairly obvious how it should, that 
case should be explicitly noted).

Joe


More information about the rfc-interest mailing list