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

[Alexey Melnikov <[e-mail]>]

Hi Alissa,

On Tue, Nov 20, 2018, at 9:03 PM, Alissa Cooper wrote:
> 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.

Done.

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

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.

?

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