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 ([email protected]) http://internetmessagingtechnology.org/ _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
