I believe that the most recent charter as drafted by Murray is reasonable to get started. Some (minor) tweaks are fine, but I honestly think we’re working at the margins and the time / effort to continue refining it has reached the point of diminishing returns as I don’t believe they’re going to move the needle in any meaningful way.
I suggest adopting the v4 Charter and move forward... I know a handful of engineers who are waiting on the sidelines warming up to get on the field. - Trent From: Emil Gustafsson <emgu=40google....@dmarc.ietf.org> Date: Friday, January 24, 2025 at 4:14 PM To: Allen Robinson <arobins=40google....@dmarc.ietf.org> Cc: John R. Levine <jo...@iecc.com>, ietf-dkim@ietf.org <Ietf-dkim@ietf.org>, Richard Clayton <rich...@highwayman.com> Subject: [Ietf-dkim] Re: Charter #4? +1 to not constraining the workgroup too much at this point. I think there are many details that need to be discussed before we know what is the best option. I'm not opposed to making some o the tweaks Dave suggested to more accurately describe +1 to not constraining the workgroup too much at this point. I think there are many details that need to be discussed before we know what is the best option. I'm not opposed to making some o the tweaks Dave suggested to more accurately describe the problem and the goal as long as we focus on what we want to solve rather than how we want to solve it. /E On Fri, Jan 24, 2025 at 3:06 PM Allen Robinson <arobins=40google....@dmarc.ietf.org<mailto:40google....@dmarc.ietf.org>> wrote: I think the charter sufficiently describes problems that exist in today's ecosystem, and is enough to get us started on work toward resolving them. On the topic of adding new vs extending DKIM, I think the relevant part of the charter is: > The working group will strongly prefer output that, when deployed, does not > disturb the deployed ecosystem. It may, however, through the normal course of > evolution, replace technologies such as DKIM and ARC. To avoid constraining the WGs direction too much ahead of time, maybe we could change the wording to "extend or replace technologies"? This would allow for both adding new things to existing protocols (DKIM) and adding an independent authentication mechanism. It would then be up to the WG to demonstrate that solving the problem through extensions to DKIM can satisfy the requirement that the changes do not disrupt deployed systems, or that extensions to DKIM can't do this and that a new thing is necessary. For what it's worth, I personally think that the add new vs extend existing discussion is a very valuable one for the WG to have (and document) at some point. I'm not currently of the opinion that we can safely add all of the proposed functionality to DKIM without causing problems for unaware consumers of the extended signature headers, even though the protocol says they should be fine. On Fri, Jan 24, 2025 at 4:19 PM John R. Levine <jo...@iecc.com<mailto:jo...@iecc.com>> wrote: On Thu, 23 Jan 2025, Richard Clayton wrote: > which I found at > > > https://datatracker.ietf.org/doc/charter-ietf-dkim/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/charter-ietf-dkim/__;!!ORgEfCBsr282Fw!t_11IcmT3ZF1vPO_igsQyQZuq26yBWHzIXHNOfOVpHtCXqMJ90Xe78I2oP_egSet9KdBD3XxnptPrhXHBkxYeAfY5HcMgCeS$> > > for the record, I think this is suitable for moving forward Same here. It's a lot of work but it solves real longstanding problems. Regards, John Levine, jo...@taugh.com<mailto:jo...@taugh.com>, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly<https://urldefense.com/v3/__https:/jl.ly__;!!ORgEfCBsr282Fw!t_11IcmT3ZF1vPO_igsQyQZuq26yBWHzIXHNOfOVpHtCXqMJ90Xe78I2oP_egSet9KdBD3XxnptPrhXHBkxYeAfY5Hfe_Hn7$> _______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org<mailto:ietf-dkim@ietf.org> To unsubscribe send an email to ietf-dkim-le...@ietf.org<mailto:ietf-dkim-le...@ietf.org> _______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org<mailto:ietf-dkim@ietf.org> To unsubscribe send an email to ietf-dkim-le...@ietf.org<mailto:ietf-dkim-le...@ietf.org>
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
