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