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. _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
