[rfc-i] Errata process
touch at isi.edu
Mon Apr 22 15:34:49 PDT 2013
On 4/22/2013 3:23 PM, Nico Williams wrote:
> 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 ...".
The key words to me are "or involve large textual changes". IMO, adding
a new sentence is large, esp. when it involves new content.
> 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.
I doubt there's often consensus to have a bug. However, the consensus
was the given text, and since this adds to the text with a fairly
substantive change, it clearly exceeds the consensus that occurred when
the doc was originally published.
I disagree with there being other reasons to publish a doc that violates
the basic requirements of errata; that's a good reason to encourage a
new doc, but not to do an end-run.
>> 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?
Sure, the onus is on me if that's what I want. However, there clearly
should not be an errata process until that happens, so maybe the onus is
really on the IESG.
Or do they just get to do whatever they want? (don't bother answering
that; we already know)
>> 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