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. 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. 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