ietf-dkim
[Top] [All Lists]

[ietf-dkim] Handling the errata after the consensus call

2009-03-06 09:17:42
Pasi, Stephen, and I had a conference call to sort out where we can go with the 
errata, the idea of a 4871-bis, and so on.  This summarizes what we think, 
where 
we'd like the working group to go, and what the working group needs to decide.

The first point is that while 2/3 of the working group prefer the stronger and 
more extensive clarifications in the "Dave draft" (realizing that he's the 
editor, and that others were involved in drafting this; it's a convenient way 
to 
refer to it) to the more minimal, more "errata-type" update of the "modified 
Eliot draft", Pasi thinks the discussion shows neither text is probably 
appropriate as an RFC Editor errata (that skips the usual IETF consensus 
process).  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 
through the full process of getting community input and rough IETF consensus.

He is sure, though, that the IESG will be happy to handle this expeditiously, 
and 
so we recommend that Dave's draft be processed as an RFC that updates RFC 4871. 
This will mean that we have come to agreement on the text, but there are less 
constraints about the length, and the outcome can include text that some folks 
would interpret as changes to RFC 4871.  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.

Next is the question of how to put it out and what to do with the other errata, 
which are non-controversial.  We could handle them as normal errata, put Dave's 
draft out as an update that resolves that item, and then start work on whatever 
4871-bis would be.  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):

1. Include the other errata into Dave's draft, leave the whole thing as "old 
text 
/ new text" format, and put it out as an RFC that updates 4871.  There would be 
no rev of 4871, and implementors would need to use both documents.  Work on 
4871-bis from there.

2. Include the other errata and Dave's draft into a 4871-bis, which would 
obsolete 4871 and make sure that implementors get the right version.  Nothing 
would go out as "old / new"; the merged document would be a rev of 4871.  Work 
on 
4871-ter from there.

Then there's the question of where ADSP stands, and whether it can proceed as 
is, 
or needs to be changed in light of the "errata".  Pasi may have some comments 
on 
this, and I know the working group will.  We've been holding ADSP up for a 
while, 
and we need to release it and move it forward.

We would like to get the decisions of how to proceed sorted out before the San 
Francisco meeting, and to use the meeting time in San Francisco to 
<strike>shout 
at each other</strike> come to the agreements and compromises that we need to 
get 
this done.  We'd like to be able to confirm these decisions on the mailing list 
and move ahead shortly after the San Francisco meeting.

Responses to this message should stay in this thread, until we decide to split 
sub-threads off.

Barry

--
Barry Leiba, DKIM working group chair  (barryleiba(_at_)computer(_dot_)org)
http://internetmessagingtechnology.org/


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