[ietf-dkim] New DKIM threat analysis draft
pbaker at verisign.com
Mon Oct 10 10:01:10 PDT 2005
I think that the only list worth keeping is a list of problems that people have proposed be solved in v 1.0 together with the reason for deferment.
In the light of prior history I would like the list to record who proposed postponing work to a later date and the conditions to be reached before proposals of that type are considered in the DKIM group. I think that a lot of the argument over what is in or out is largely due to the abuses of this procedure in MARID where certain people who vocally opposed work in a particular area later proposed work of the type people understoood to be excluded.
A decision to defer work to a later date must not be allowed to be used as a tactic to clear a path for a favored proposal.
Also note that a decision by the group not to proceed with a particular work item in DKIM is also a declaration that the group SHALL MAKE NO OBJECTION WHATSOEVER to a proposal to pursue that work item in a separate forum.
Think of it as a source code maintenance system. You should only reserve the code modules you intend to work on. Reserving a module is an undertaking to complete it. Reserving a module for the purpose of stopping another person working on it is not allowed.
From: ietf-dkim-bounces at mipassoc.org on behalf of Arvel Hathcock
Sent: Sun 09/10/2005 7:31 PM
To: ietf-dkim at mipassoc.org
Subject: Re: [ietf-dkim] New DKIM threat analysis draft
> If we're going to start adding problems we don't
> want to exclude solving, I have a rather long list
> Making such lists is not a productive use of
> anyone's time.
That's just what I was thinking also when reviewing this topic. There's no
need to add complexity.
ietf-dkim mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ietf-dkim