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

Reply via email to