Subject: [Emailcore] IETF conflict review for draft-crocker-email-author

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 6 Apr 2021 10:17:57 -0700

This document is being processed via the ISE and thus is slotted to be
evaluated by the IESG for conflict with existing work.  I'm confident that
EMAILCORE is not chartered to take this up, and I've already submitted a
position that it is somewhat related to what's going on in EMAILCORE (and
in DMARC, which is more of a direct hit) but that its progress through the
ISE will not interfere with the work being done here.

If I've got that wrong, please let me know soon.

Thanks,

-MSK

---

From: John C Klensin <[email-masked]>
Date: Wed, 07 Apr 2021 14:58:40 -0400

--On Tuesday, April 6, 2021 10:17 -0700 "Murray S. Kucherawy"
<[email-masked]> wrote:

> This document is being processed via the ISE and thus is
> slotted to be evaluated by the IESG for conflict with existing
> work.  I'm confident that EMAILCORE is not chartered to take
> this up, and I've already submitted a position that it is
> somewhat related to what's going on in EMAILCORE (and in
> DMARC, which is more of a direct hit) but that its progress
> through the ISE will not interfere with the work being done
> here.
> 

Murray,

While I agree with your analysis and conclusion above, I'd
encourage you think about a closely-related problem.  There is a
long-time principle about email protocols [1], most explicitly
first expressed in RFC 1425 but predating it, that complexity is
the enemy of interoperability and protocols that work well and
often the friend of those looking for opportunities for attacks.
While there are many advantages of splitting email work up into
multiple WGs, some even not in ART, one disadvantage is that we
may end up with no good place for someone to argue that, what a
particular proposal can be implemented and might work as
claimed, it just is not worth the added overall complexity.
Those are special concerns when we either change the semantics
of an existing feature or consider adding a new feature that
does what an older one was expected to do (or did do for a
while) without deprecating the original feature.

I don't have a good idea how to address that issue or parsimony
in our feature set.  Perhaps the IETF is in need of a Devil's
Advocate for changes/ enhancements/ additions to existing
protocols [2].

best,
   john

[1] It has been suggested many times that the same principle
should apply to all Internet-related protocols or at least those
of which the IETF has any influence, but I'd prefer to avoid
boiling that ocean today.

[2] Anyone not knowing the origins of that term/role might want
to look it up before jumping to conclusions about what I'm
suggesting.