In summary, +1 to moving forward with the suggested changes. I don't have any great suggestions for the first three items below but some comments on the fourth and fith.
On Sat, Jan 11, 2025 at 11:56 AM Murray S. Kucherawy <superu...@gmail.com> wrote: > After watching and even engaging in the discussion about the charter for > this new effort, I think a few things have fallen out that can help us > narrow the proposed charter further. This is not to discard or bypass the > broader feedback from Dave or Pete or others, just to acknowledge a few > themes I'm seeing. > > If I have these right, great; the next revision of the charter gets > tighter. If not, please correct me where I'm wrong and we'll try again. > > First, and probably the most important: We're not updating DKIM. While > this uses many of the core mechanisms of DKIM, this is doing something > quite different and is not itself DKIM. Thus, we should plan to remove any > language from the charter that suggests modifying, extending, or otherwise > touching DKIM directly. Moreover, I don't think we anticipate, nor do we > need to allow, any changes to the stuff EMAILCORE is currently working on. > > Second, a corollary to the first: We probably should call this something > else. I'm fine if we take a bit of time to figure this out and continue > the discussion here -- for that matter, the name of the thing we want to > build here and the name of its working group don't need to coincide -- but > let's at least agree on this point. > > Third, we need to acknowledge that there is a lot of new stuff here. DKIM > has a long and well understood deployment history, but ARC doesn't, and > although we've toyed with the ideas many times over the years, the notions > of reversible mutations and signing a single envelope recipient per > signature are almost completely untested. Now, I don't agree that this > rises to the level of dispatching the work to the IRTF (and if I recall > past conversations with them, I think they would agree), but we should be > prepared for the idea that this is going to take a non-trivial amount of > testing and iteration to ensure it doesn't fracture the ecosystem when > deployed at scale. We're in the territory of the Great Debate(tm) around > setting a high bar for Proposed Standard versus underscoring the word > "Proposed" and letting things go while there may still be some rough edges. > > Fourth, while I agree that the terminology we use really ought to be > precise, I don't think we should let perfect be the enemy of the good > enough. I think we can move forward by simply saying somewhat less than > the current text does. > Following the language from Bron's doc: https://notes.ietf.org/YGynIPpYS7yqg5G7ZeSQeA?both, my guess is that the language here: "To achieve its goals, this work requires a wide scope. The group may need to supersede, modify, or replace many parts of the current email infrastructure and associated reporting mechanisms" worries people because on its own sounds so broad. Based on the language indicating "interoperability with existing mechanisms needs to be maintained", I don't think the intent was to change everything and in fact the intent is more scoped. I suspect this issue can be reconciled by restricting these changes to the new authentication and related reporting mechanism. How about language like: "To achieve its goals, this work requires a wide scope for change in the context of the new authentication mechanism. This working group may reinterpret many parts of email infrastructure and associated reporting mechanisms in the evaluation of the new mechanism, however legacy authentication standards will not be changed."? > > Have I got any of this seriously wrong? If you think so, have at it. Or > if this is on the right track, then let's iterate the charter within these > guidelines and see if we can get something started here. I'm happy to take > up the pen on the next iteration myself. > +1. This will probably get the best result here. -Wei > > To be safe, I'm going to file a BoF request for IETF 122 as a placeholder, > since the deadline is this coming Friday. If we manage to charter before > Bangkok, we won't need this, but I'd rather have the time reserved to have > this discussion formally if necessary. > > -MSK, ART AD > _______________________________________________ > Ietf-dkim mailing list -- ietf-dkim@ietf.org > To unsubscribe send an email to ietf-dkim-le...@ietf.org >
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org