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.
Phill
________________________________
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org on behalf of Arvel Hathcock
Sent: Sun 09/10/2005 7:31 PM
To: ietf-dkim(_at_)mipassoc(_dot_)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
here,
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.
--
Arvel
_______________________________________________
ietf-dkim mailing list
http://dkim.org
_______________________________________________
ietf-dkim mailing list
http://dkim.org