Dave Crocker wrote: > Pasi, > > Please reconsider your suggestion. > > This Errata effort developed out of real and immediate community > need. Your opening comment indicates an understanding that the > problem does exist. In other words, it does fix a specific, actual > problem with the current specification, and that's what Errata are > for. If you know of documentation that specifies a limit on the > scope of an Errata (erratum?), please point to it, because I could > not find one. We should not invent one on the fly.
While considering this, I tried to find exactly such documentation, but I did not find much. draft-rfc-editor-errata-process-02 has the following text: We note that allowing technical errata is a slippery slope: there may be a temptation to use errata to "fix" protocol design errors, rather than publishing new RFCs that update the erroneous documents. In general, an erratum is intended to report an error in a document, rather than an error in the design of the protocol or other entity defined in the document, but this distinction may be too imprecise to avoid hard choices. For the IETF stream, these choices should be made by the IESG, and are discussed in their proposed guidelines on errata processing [IESG-Err-Proc]. The distinction isn't very precise; you could consider rfc4871-errata-00 either an error (in this case, omission) in the design, or an error (omission) in the document. The IESG statement on IETF Stream errata (http://www.ietf.org/IESG/STATEMENTS/iesg-statement-07-30-2008.txt) has this: 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. This isn't much clearer, but it does suggest a possible test: if these changes had been proposed when the document was about to be approved, would they have been accepted? Most reported RFC Editor errata are simple errors in the document, where it's fairly obvious that if someone had pointed this out during e.g. AUTH48, the text would have been fixed. If someone had suggested the changes in rfc4871-errata-00 during AUTH48, would they have been accepted? Or would the person proposing them have been told "no, you're too late, maybe we can consider these when we do 4871bis"? I wasn't following DKIM when RFC 4871 came out, so I'm not in very good position to guess here. But educated guesses from folks who were around back then are welcome -- if most folks guess this would have been accepted, I'm willing to reconsider. > Coupling the publication fate of this one, specific change with an a > substantially larger -- and potentially much larger -- set of > additional changes ensures a delay of months, where 6 months is > optimistic. Adding arbitrary delay to the publication of an > approved Errata note is not helpful for community need. > > The specific clarification being attempted by the current draft > Errata is needed now, not months from now. Right -- but if it's a change that probably doesn't reflect community consensus at the time when RFC 4871 was approved, it needs to go through the process. We could craft the charter text on 4871bis to specifically include only the errata reported to RFC Editor as of today, plus the things in rfc4871-errata-00 -- and exclude everything else. It would still take some months, but I think less than six. > ps. Independent of the formal IETF publication barriers that we > encounter, the working group can still resolve the current topic, by > formulating working group consensus, and then post it to the > dkim.org web page. That's not the same as formal IETF publication > but can still declare it for community use. Yes, I think this could be indeed valuable. You could e.g. do a WGLC for the rfc4871-errata draft, reach rough DKIM WG consensus on that, and post a statement saying so. That's not the same as IETF consensus, but probably a good working assumption while 4871bis goes through the process. Best regards, Pasi _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
