Re: [Ietf-dkim] Proposals for tolerating mailing list modifications

[Michael Thomas <[e-mail]>]

On 8/4/23 2:29 PM, Murray S. Kucherawy wrote:
> Colleagues,
>
> On Fri, Aug 4, 2023 at 12:08 PM Michael Thomas <[e-mail]> 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