Barry Leiba wrote:
The IESG has Errata rules that cover the qualities required or
prohibited for an Errata entry that applies to a standards track
document. By all appearances, those rules are being invoked but
not followed. They say nothing about the length of an entry and
they say nothing about introduction of terminology, yet those are
the two factors being cited for not issuing the Errata draft. If
the IESG is creating new Errata rules, it needs to document them.
What is happening here, however appears to be an ad hoc,
undocumented modification of the rules.
In spite of multiple requests, we have not yet been told what
specific IESG Errata rule justifies refusing to publish the draft
as an Errata entry and how, exactly, the rule applies to
draft-ietf-dkim-rfc4871-errata.
Pasi, can you, or the IESG as a whole, give Dave and the rest of the
working group a more clear answer about what criteria would cause
draft-ietf-dkim-rfc4871 to be rejected, and how a working group
would know that as it develops fixes for errata.
The relevant criteria was quoted in my email on 2009-03-06:
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.
Note that most of the criteria listed in the IESG statement, including
this one, include exercising judgment.
(By the way: If someone thinks the IESG should replace these rules
with something that involves less judgment (a more mechanical process
that would produce the same outcome independent of the persons
involved), there's nothing stopping folks from proposing changes to
the rules. But this is not in scope of DKIM WG, and I respectfully
request that it happens on some other mailing list.)
In some earlier emails, I tried to explain my thought processes when
exercising this judgment, but apparently I wasn't very clear in making
the distinction between, for example, "I considered X when making the
judgment" and "the rules prohibit X" (and certainly my intent was not
to start creating any new rules here).
I'll try to be clearer this time (but let's see how succesfully...):
I do not think the changes in draft-ietf-dkim-rfc4871-errata-02 should
be marked "Approved" using the errata process, because of criteria 7:
they might (with reasonable probability, in my judgment) be different
from the intended consensus when the document was approved.
An informal explanation of things I considered in making this judgment
follows:
The key word here is "might", and it involves exercising judgment,
since the answer (was this the intended consensus several years ago)
in general cannot ever be known with 100% certainty. The questions I
asked myself included e.g. "is this any bit controversial?" and "is it
obvious that we don't need to go through the normal IETF consensus
process?". Based on the mailing list discussions so far, my judgment
was that I would not call this totally uncontroversial, and it is not
obvious to me that going through the normal IETF consensus process
(which is not the same as DKIM WG consensus) could be skipped.
Someone else might have answered these questions differently, and
these questions certainly are not intended to be any new rules or
criteria, but rather explain why in this particular case I considered
"might be different from the intended consensus" to apply.
Going forward, let's just get the changes through the normal IETF
consensus process, and published using the normal mechanisms we use
for publishing updates to IETF work.
Best regards,
Pasi
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html