[ietf-dkim] Handling the errata after the consensus call
tony at att.com
Fri Mar 6 20:35:58 PST 2009
On the contrary, moving DKIM **forward in the standards process** sends
exactly the proper message: that DKIM *is* stable enough for us to
advance its standards level.
Remember, advancing along the standards track has serious constraints on
the types of changes permitted to the spec. It is *not* an indicator of
instability, but instead is an indicator of its stability.
If we were to come out with a 4871bis *without* also attempting to move
it forward on the standards track, then I agree that we'd be sending a
bad message to the industry. But I don't think doing a bis without
concurrent advancement is being seriously considered -- I'm certainly
advocating moving it to Draft Standard.
tony at att.com
Michael Thomas wrote:
> I frankly don't see the point of a -bis document, and so long as the errata
> shows up reasonably close to the top in a google search, I think that the
> dev front should be fine. Invoking another round of IETF process at this
> point sends exactly the wrong message: that DKIM is not stable. DKIM
> has been remarkable in its stability and interoperability, so sending that
> message would be a real shame.
> Mike, dev-by-google-consensus is the new "rough consensus
> and running code"
> DKIM Chair wrote:
>> 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 Leiba, DKIM working group chair (barryleiba at computer.org)
>> NOTE WELL: This list operates according to
> NOTE WELL: This list operates according to
More information about the ietf-dkim