Subject: [ietf-dkim] Errata vs "errata RFC"

From: DKIM Chair <[email-masked]>
Date: Tue, 10 Mar 2009 10:29:32 -0500

This thread has been split from Dave's long note.

Pasi, Dave and others continue to push for submitting 
draft-ietf-dkim-rfc4871-errata as "errata", rather than as an RFC with fresh IETF 
rough consensus.  Dave asks what I think is a fair question, looking for more 
guidance than "I know it when I see it," with regard to how extensive errata 
changes can get before they're no longer acceptable as errata.

Specifically:
>   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.

Barry

--
Barry Leiba, DKIM working group chair  ([email-masked])
http://internetmessagingtechnology.org/

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: <[email-masked]>
Date: Wed, 11 Mar 2009 14:57:18 +0100

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

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 11 Mar 2009 08:42:07 -0700

[email-masked] wrote:
>     Rejected. 
...
> from the intended consensus when the document was approved.

Pasi,

First, thank you for the clarification.  I believe I now do understand your 
logic and, sadly, I believe your interpretation of the implication of the 
"might" is a reasonable.

Unfortunately the simple, practical result of your interpretation and logic is: 
  Standards track Errata can only be "approved" if there is no controversy about 
them.  Since virtually no IETF activity is entirely without controversy, this 
effectively means that your (reasonable) interpretation of Rule #7 means that 
virtually no standards track Errata can get the "Approved" label.

And I hope my language makes clear that I think this describes a very large 
problem with the rule, and not your interpretation of it.  So, yes, there's work 
to be done, to improve the IESG's Errata criteria, but that's a matter for IESG 
and IETF discussion, not for DKIM working group discussion.

The task for the working group is to decide how to proceed, given the actual 
constraints in the various IETF processes.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Wed, 11 Mar 2009 10:58:49 -0700

> virtually no standards track Errata can get the "Approved" label.

   In this particular case, there was no controversy for any of the errata
   *except* what you've proposed.

> problem with the rule

   An easier explanation is that the scope and breadth semantic changes are
   the problem. Occam's Razor and all that.

		Mike