Perhaps we could provide a material proof of what John is asking for if we published the other two schemes that are essentially identical to DKIM. I can certainly try to get the VeriSign spec released.
I think that if four independent high-level engineering teams come up with essentially the same idea at the same time then that is a pretty good reason to think that the approach is well founded and likely to be stable.
If people have a different view on how to solve the same problem let them start their own WG or submit an individual ID.
What we have here is not just a coalition of companies it is a coalition of many of the best known security specialists who work on protocol design. If we ever have the Internet crimewave under control some of us might be considered experts.
This is not about 'pre-picking one solution' as some claim. It is about recognizing the fact that four independent groups that came up with the same idea have agreed to pool their essentially similar ideas and bring a joint proposal to the IETF supported by an even larger group.
I do not think it is reasonable for the answer to that proposition to be 'go spend 12 months defending your idea against everyone with an opinion and a keyboard'.
-----Original Message-----
From: ietf-bounces@xxxxxxxx on behalf of Michael Thomas
Sent: Thu 22/12/2005 8:18 PM
To: John C Klensin
Cc: ietf@xxxxxxxx; iesg@xxxxxxxx; ietf-dkim@xxxxxxxxxxxx
Subject: Re: WG Review: Domain Keys Identified Mail (dkim)
John C Klensin wrote:
> 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.
>
> 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.
I obviously think it's closer to #4 than anything else. Note
I wasn't weighing in about whether this piece of word-smithy
vs that was better or not, just my concern that the lack of
negotiation/feedback make the backward compatibility problem
far more nettlesome than other protocols that have that
luxury. There is a substantial risk that a bunch of gratuitous
thrashing around -- or worse a greenfield makeover ala MEGACO --
will cause this effort to crater. Given MARID, I don't think
we get many chances and that this is really a situation where
the best is the enemy of the good.
As such, I think it's reasonable for the charter to limit the
scope of changes to those that will really tighten up the mature
parts of the specs instead of a, IMO, futile -- and destructive --
trip back to first principles. False dichotomy? Maybe, but not
out of the question if there is no limit at all, and that's
pretty bothersome for those of us who advocated taking this
to ietf and tried really hard to make this look like
something that would pass ietf muster.
Finally, I understand that for many people there are larger
principles at stake about the nature of ietf, etc, etc. I can't
tell you how thrilled I am that we are the posterboy for _that_
argument.
Mike
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf