Barry,
The purpose of rules and precedents is to make a process more equitable and
predictable. The management of draft-ietf-dkim-rfc4871-errata[1] is failing to
conform to the IETF's rules and precedents.
This failure is more than an academic issue. The draft was developed to respond
to real-world concerns affecting the use of DKIM signing *now*. Those
concerns are being ignored, through the spontaneous invocation of undocumented
constraints that ensure delays and give no practical sense of how closure will
be achieved.
DKIM Chair wrote:
The first point is that while 2/3 of the working group prefer the stronger
and more extensive clarifications in the "Dave draft"
...
Since Dave's draft has a clear majority behind it, we'd like those who
disagree with some parts of it to help with making it more acceptable to
everyone -- or most of us, anyway -- so we can get it out as a 4871 update.
1. So, you are formally declaring that 2/3 is not rough consensus, in spite of
its typically being sufficient?
2. "to everyone" is never an IETF requirement. And "or most of us" is entirely
ambiguous; I've no idea what it means or what will satisfy it. Do you?
3. While it's always nice to get more support for a draft, a review of the
working group archive shows that none of those voting against
draft-ietf-dkim-rfc4871-errata engaged in anything that looks like negotiation;
they deny the problems that the draft addresses. In marked contrast, the draft
was produced through an incremental group process of discussion, debate and
revision. So your decision effectively hands a veto to those who disagree with
the draft, in spite of a 2/3 consensus in its favor, unless you have some plan
for a process that will produce real discussion and real compromise. Do you?
Dave's changes, in particular, introduce new terminology and make enough
changes in how the affected areas of the spec are worded that Pasi believes
-- and thinks the IESG as a whole will agree -- that it needs to go
To get this on the record explicitly and clearly:
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.
We're concerned, though, with the lack of visibility of errata, and we note
that some of these errata are important for people to see when they're
implementing 4871. That might make it worth taking one of these two paths
(and this is what we'd like the working group to decide):
An additional irony to the "visibility" argument -- beyond being invoked without
detailed justification and without prior discussion in the working group -- is
that the ultimate /in/-visibility is failure to make the changes available at
all.
The reason for pressing to develop and approve draft-ietf-dkim-rfc4871-errata as
an Errata is timeliness.
We are being repeatedly assured that the RFC path can be quick, but that is in
terms of numbers of months and it ignores the real-world timeline for RFCs (and
for this working group.) Immediate example: The Overview passed working group
last call almost 4 months ago and has not yet been submitted to the IESG. We
have only just received Area Director review comments, requiring problematic
changes that will take more time to resolve, especially since there is no
indication which changes are required and which are merely advisory. And
this is a common type of delay for RFC processing.
Your note appears to propose pursuing further revisions, through a quick
RFC4871bis effort, but it can only "quick" by making assumptions that are
probably wrong: We have not yet gotten working group discussion or agreement on
what the revision effort will cover and it could easily encompass more than
you've been assuming.
Both in terms of content and process, quick is likely not to be.
So here is a counter-proposal, with three steps we should pursue:
1. Declare draft-ietf-dkim-rfc4871-errata approved by the working group. Submit
it as an RFC Errata, containing text that indicates working group approval. The
question of IESG approval affects its status label in the Errata database, but
not whether it is available through the RFC Errata mechanism. While it would be
nice to have IESG approval, it's not a requirement for Errata distribution.
Whatever the deficiencies of Errata visibility, it's better than failure to
distribute. We also can promote it through other channels.
2. If the claim is that 2/3 is not rough consensus, the working group need to be
told why, told what /will/ qualify, and given a much more concrete basis for
understanding how progress is going to be made at reaching agreements. Some
groups naturally resolve issues through constructive debate, but this isn't one
of them. Discussion, here, needs far more active management than the group has
been getting.
3. Then we should follow your Option 2.
d/
[1] The best way to indicate that draft-ietf-dkim-rfc4871-errata is from a
group effort is to refer to it by its draft name.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html