Michael,
Since I believe that, whatever else happens, it is better than
those who are interested in DKIM get on with the work rather
than spending more weeks or months splitting procedural hairs,
let me see if I can explain the distinction I see.
For context, I have a skeptical view of all spam-reduction
techniques that are based on giving the recipient better ability
to distinguish between good (or favored, or safer-than-most)
messages from less-good or actually-bad messages by
identification or classification of the point or origin (whether
by person, by domain, by address range or routing, etc.). So
I am not, in any way, opposed to DKIM because I favor some
slightly-similar method; I'm almost equally skeptical about all
of them, but believe that any plausible ideas are worth serious
exploration.
That said, I see three reasonable ways to pursue work in the
IETF and a possible fourth:
(1) One arrives with a more or less specific topic, and
probably some ideas, gets an ordinary WG chartered, and
then sorts things out and tries to end up with a
standards-track document. This approach assumes that
_all_ issues that fall within the problem definition in
the charter are on the table, even though a sensible WG
will prune options as quickly as possible. But any
input that arises from pre-WG efforts is input, as if
from a design team, and not binding on anyone, whether
the design team (or other prior work) has consensus or
not.
(2) One arrives with what is, in essence, a finished
product, ideally with claims of implementations,
interoperability, and general soundness. Taking such a
product to a WG is a waste of everyone's time. One
takes it to the IESG, convinces them and the community
that the work is appropriate for the IETF and as sound
as you think it is, and get a four-week last call for
standards track issued.
(3) One arrives with an approach that needs exploration
and exposure to the broader community. One gets a WG
chartered to explore that particular approach, but with
the target of producing experimental and informational
RFCs that document the approach and its apparent
strengths and weaknesses. Only after that process is
completed and the agreed-upon specification (not some
earlier version with some ideas about changes
pre-standardization)implemented and tested in "live"
situations is there a discussion about standardization.
That discussion would presumably take the second path
above unless there was still controversy about "best"
solutions. In the latter case, if the IETF decided
there was a reason to try to pick, we would probably
need a WG to explore that, but its charter would be far
different from a WG intended to do design, as in (1)
above.
In addition, there is, I think, one other approach that might be
appropriate, but only in very limited circumstances. That
approach applies where there is a well-thought-out approach with
design team consensus, evidence of implementation, and no
clearly-identified technical concerns. Then, and only then, I
think that an approach of "the WG gets to challenge the base
spec and assumptions, but to change them only if there is good
reason and consensus to do so" is plausible with a standards
track target. I think that XMPP, and the XMPP language,
probably is an instance of that case.
Now, for DKIM, there have been claims that it is widely deployed
and successful but still needs IETF consideration. If that is
the case, it would, by my typology, fall in the fourth category
(but with an XMPP-like constraint, not the much stronger prior
decision that seems to be implied by the current text. I
think it has also been claimed that it is sufficiently finished
and mature that IETF ratification and endorsement is needed, but
no real changes are required or desirable. If that is the case,
then the second option above would seem to be the right one.
Others have claimed that there are known, and serious, technical
deficiencies. If they are correct, then it seems to me that the
only reasonable possibilities are the first or third options,
i.e., either "no restrictions" or "not standards track at this
point".
Other than claims and counterclaims, I've seen little that would
permit the IETF community to form a consensus about exactly what
stage the DKIM work (and implementation, deployment, and
demonstrate that it accomplishes whatever is being claimed) is
really at, a consensus that seems to me to be necessary to
determine whether it should be chartered as a WG if there are
going to be any restrictions at all on what that WG can
consider. That strikes me as sad since, beyond philosophical
debates, it seems to me to be the key issue.
Just my opinion.
john
--On Thursday, 22 December, 2005 08:55 -0800 Michael Thomas
<mat@xxxxxxxxx> wrote:
> Cullen Jennings wrote:
>> My current understanding is that the deployments
>> are small enough that changes are still easy and that non
>> backwards compatible changes are already expected.
>
>...
> I'm not sure who Keith was talking about with his broad brush
> assertion -- there are probably about 30+ people who've had
> a hand in the creation of the current drafts before we ever
> brought it to IETF, but my concern is that given complete
> lattitude the resulting thrashing around will produce an
> extremely narrow intersection between compatible senders
> and receivers. Which will constitute failure in all likelihood.
>
> On the other hand, I think its really a stretch to say that
> we are unwilling to listen, or that we're looking for a rubber
> stamp. We have already agreed to -- and incorporated -- a
> substantial backward incompatible change (the canonicalization)
> due to feedback (and threats) we got. What I'm hoping for
>...
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf