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: [EMAIL PROTECTED] on behalf of Arvel Hathcock
Sent: Sun 09/10/2005 7:31 PM
To: [email protected]
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
