[rfc-i] Errata process
nico at cryptonector.com
Mon Apr 22 15:23:59 PDT 2013
On Mon, Apr 22, 2013 at 5:09 PM, Joe Touch <touch at isi.edu> wrote:
> On 4/22/2013 2:57 PM, Nico Williams wrote:
>> A better example of a recent errata submission is this:
> 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:
It's a plausible and reasonable outcome. Even if that is the outcome
though, the errata process will have been useful.
> 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.
The key words here are "... that might be different from the intended
consensus ...". It's not at all clear that there was a consensus to
have this bug, so IMO you're jumping to conclusions. Clearly we need
to evaluate this. And even if there's no issue of changing consensus
we might still want to publish an update for various reasons.
> 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.
I think that's irrelevant [that a MUST is added]. It's perfectly
reasonable to have such a thing in an errata if it's utterly clear
that the missing MUST is required and intended (possibly only in
retrospect, but good enough).
>> 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
OK, now we're getting somewhere. Maybe you should submit an I-D?
> assertion. Second, it seems important that only vetted and approved comments
> be posted; hold for doc update and especially rejected errata should not
Errata already have an unverified status.
> appear with the doc, even labeled as such. Finally, I would like the process
I certainly agree that spam errata should be removed. I'm not sure I
agree that rejected errata should not be listed: I like history. (But
if they should be listed then they should be listed as rejected, of
course, and clearly so. Ditto withdrawn, I think, since an errata
submission may well have led to much discussion, and it's useful to be
able to find that.)
> 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).
More information about the rfc-interest