ietf
[Top] [All Lists]

[ietf-dkim] RE: WG Review: Domain Keys Identified Mail (dkim)

2005-12-23 18:21:54
I have for some time become aware that the problem of deploying a protocol is 
considerably more challenging and difficult than the problem of developing a 
protocol.

That is the reason that only two protocols were submitted as input documents 
into this process rather then four. It is no longer a secret that VeriSign 
designed, developed and implemented a scheme essentially identical in all 
architectural respects to DKIM and demonstrated it under NDA terms several 
years ago. The reason that we did not go forward with the protocol proposal is 
that to do so would not help the creation of an environment where deployment 
could take place. Others made the same decision.

I agree with Keith, no industrial consortium should dictate the terms under 
which the IETF accepts a specification. Most of the criteria applied by the 
IETF are pretty clear, copyright and change control is passed to the IETF (or 
this strange trustee thing). I would like the IETF to be equally uncompromising 
about IPR and set out a limited number of choices for IPR terms. There is no 
shortage of standards forums, if a consortium wants to write a closed protocol 
that it keeps change control over or control through an discriminatory IPR 
regime then it can and should go elsewhere. It is a commercial choice, not a 
moral one. I have written proprietary code and open code, proprietary standards 
and open ones. I think that it would be better for the IETF and the 
constituencies it serves if it recognized that it is not a useful forum for 
developing closed standards but that is a different argument.


What does matter is deployment. I think that every group that comes to the IETF 
with a deployed, reasonably complete protocol has the right to expect that the 
standards process will respect the deployment imperative and avoid changes that 
are unnecessary or capricious. For example I still think it was a damn fool 
thing for folk in the URI group to try to require that all URIs be written in 
angle brackets, thus breaking millions of deployed clients with zero benefit. 
There are plenty of similar cases, unnecessary name changes to tags - if you 
think the referer tag is spelt wrong then wait for the next version of the OED, 
you will find that my way is now the right way.

Building on top of a legacy deployed base is often the best way to start 
deployment. I agree that some explanation is owed to explain why we are not 
using S/MIME here. The answer is simple, S/MIME is a technical success that 
meets 95% of the intended use cases. Our use case is not one of the original 
intended use cases and the design of S/MIME breaks our overriding design 
requirement that no legacy clients see a worse user interface. 

The fact that we need a new signature standard does not mean that we are 
rendering S/MIME and PGP obsolete. On the contrary I view DKIM as being a 
bootstrap for the S/MIME and PGP deployment process that stalled about five 
years ago. 


I do not see that the proposed charter wording changes to make it clear that 
change control is passed to the IETF and that the group works with the rest of 
the IETF need to be a show stopper.

People often worry more about what cannot possibly happen than what can. Let us 
imagine that the worst case scenario were to happen and the IETF was to agree 
to host the DKIM WG but then decide to insist that the entire specification be 
reworked as a version of S/MIME or use PKIX for key distribution or some other 
scheme that eliminates the advantages DKIM brings to the table and breaks the 
legacy base. All that happens is that the people who want to actually deploy 
something useful and meaningful walk out and a technical note appears shortly 
afterwards in another forum.

That scenario is a possibility in every IETF working group but it very rarely 
happens because most of us are here to get something to happen. It is only in 
rare cases such as when the WG chair is the noisy faction determined on their 
way at all costs and the AD is not inclinded to remove him because he is also 
an AD of another area and they have to work together that things start to fly 
apart, and even then there is a meta-level of accountability that can in theory 
be brought into play.

Equally passing change control does not and cannot prevent a fork in the 
specification - and even the new trustee scheme will not change that in 
practice.


Bad things can sometimes happen when you surrender control, but that is the 
whole purpose of the process. There are many people who are not going to 
implement anything until they know that it is open, unencumbered and fixed. Its 
the last point that is important, will the spec be tweaked endlessly or forked 
by numerous would be improvers as happened to RSS? 

-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org on behalf of Keith Moore
Sent: Fri 23/12/2005 1:53 AM
To: dcrocker(_at_)bbiw(_dot_)net
Cc: John C Klensin; ietf-dkim(_at_)mipassoc(_dot_)org; 
iesg(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
Subject: Re: WG Review: Domain Keys Identified Mail (dkim)
 
Apparently you expect the extensive, open group consensus process that 
was pursued TWICE on this matter to have no import, but the last-minute, 
vague whim of a few posters instead should hold sway.

Dave,

Unless you can cite an IETF BCP RFC that authorizes unchartered, 
self-appointed, ad hoc groups to dictate the terms of their charters, 
constrain the behavior of chartered IETF working groups, or overrule the 
decisions of IESG in chartering a group, please rest your case.

Keith

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
ietf-dkim mailing list
http://dkim.org
<Prev in Thread] Current Thread [Next in Thread>