Subject: [dmarc-ietf] Alissa Cooper's Block on charter-ietf-dmarc-01-00: (with BLOCK and COMMENT)

From: Alissa Cooper <[email-masked]>
Date: Tue, 20 Nov 2018 13:03:24 -0800

Alissa Cooper has entered the following ballot position for
charter-ietf-dmarc-01-00: Block

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-dmarc/

----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

(1) I realize this re-charter is motivated by a small update, but it seems
confusing to maintain text that is out-of-date when publishing a re-charter.
Someone already pointed out the issue with RFC 7960; I would also argue that
the following change is needed:

OLD
The existing DMARC base specification has been submitted as an
   Independent Submission to become an Informational RFC.
NEW
The existing DMARC base specification has been published as RFC 7489 in the
Independent Stream.

(2) "Any issues related to the email authentication space ..." seems like a
rather broad charge. I understand the desire to work on
draft-levine-appsarea-eaiauth, but does that really justify this much wider
charter expansion? I feel like the point of the chartering process is to avoid
this kind of catch-all.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

"2. Reviewing and improving the base DMARC specification

   The working group will not develop additional mail authentication
   technologies, but may document authentication requirements that are
   desirable."

It's not clear how documenting authentication requirements implies directly
improving the base specification.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 21 Nov 2018 11:33:18 +0000

Hi Alissa,

> https://datatracker.ietf.org/doc/charter-ietf-dmarc/

Done.

> charter expansion? I feel like the point of the chartering process is to avoid

I was trying to clarify that this only meant things like SPF/DKIM/DMARC, and not, for example, SASL. But it looks like my attempt wasn't successful. How about something like this:

OLD:
   Any issues related to the email authentication space (SPF/DKIM/DMARC) that
   are large enough to mandate working group review but do not already fit under
   the charter of any existing working group can be considered for adoption by DMARC.

NEW:
   Extensions to SPF/DKIM/DMARC that do not already fit under
   the charter of any existing working group can be considered for adoption by DMARC.

?