On 2/2/23 2:16 PM, Tim Wicinski wrote:
On Thu, Feb 2, 2023 at 5:07 PM Michael Thomas <[email protected]> wrote:
So here is what sticks in my craw. I think I brought up the problem
statement, but maybe somebody else did before me. It's easy to say
"here
is the problem, fix it!" without any context to what any proposed
fixes
might break. It would be really bad imo to slap out a minimal problem
statement and then proceed to solutions without any analysis of
what any
solution space should and should not do at a protocol level. I guess
that's a little bit more requirement-y, but I'm not exactly sure what
process-wise I'm asking for. DKIM is extremely widely deployed so we
need to be really careful about not breaking existing practices or
doing
unnatural acts that have implications to the wider email community.
My feeling part of the problem statement will be to document various
solutions
and how testing should be done and what to look for (breaking existing
practice would
be key).
It may be that one solution is protocol rev which works outside of
current dkim.
We wrestled with this in the early days of DPRIVE - adding additional
encryption onto
DNS was viewed in a similar manner.
I don't know if there is a formal IETF definitely of what constitutes a
problem statement but it's easy to imagine a problem statement that...
just states the problem. I don't think we have discussed what should
actually be in scope for this problem statement. I guess we could suss
that out before there are chairs, but obviously we'd need them to make
consensus calls.
Mike
_______________________________________________
Ietf-dkim mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-dkim
