On 8/4/23 2:29 PM, Murray S. Kucherawy wrote:
Colleagues,
On Fri, Aug 4, 2023 at 12:08 PM Michael Thomas <m...@mtcc.com> wrote:
Exactly. Any proposed modifications to DKIM should be based on DKIM
itself. Anything else is off-topic. It's not like you can't
propose the
ARC modifications to DKIM in terms of DKIM itself, though all of
those
modifications have nothing to do with the current charter.
Two things:
1) Please endeavor to lower the temperature on this thread.
2) If the chairs have decided, or decide in the future, that ARC has
been discussed and consensus is to consider that topic closed, that's
their purview. However, such a decision cannot be derived directly
from the charter text I'm looking at. In particular, this text:
"The DKIM working group will first develop and publish a clear problem
statement.
Then, it will produce one or more technical specifications that propose
replay-resistant mechanisms. The working group will prefer solutions
compatible
with DKIM's broad deployment, and there will be an expectation that
these solutions
will have been through implementation and interoperability testing
before publication."
...does not, to me, constrain the solution space to DKIM itself. If
there's a solution to DKIM replay outside of DKIM itself, then it's
fair game.
Well, for starters ARC doesn't have broad deployment. But the author
doesn't say why ARC is needed or relevant. That is the point here. *All*
changes need to be justified including any imported mechanisms. The less
rat holes the better. Same with the mailing list modification draft. Why
is that even relevant?
Mike
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
