Dave Crocker wrote:
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
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
NOTE WELL: This list operates according to