[dmarc-ietf] Does EAI doc need to flag SPF macro implications more explicitly? (was: Proposed charter spiff ...)

I think that Seth is referring to Scott's "merely" designation:

It doesn't appear that it proposes any changes for SPF.  It merely
> documents that non-ascii local parts don't match the related macros.
> During the SPFbis working group we looked at this and explicitly decided on
> it.  It's not by accident.
> Since local part macros are very rarely used, it seemed like very much a
> corner case not worth it to break the installed base over.

rather than the charter change itself. I did not read this as something
that needed to change in the document unless Scott is looking for bold
flashing lights around it :-)

--Kurt

On Tue, Jan 22, 2019 at 9:17 AM Murray S. Kucherawy <superuser@gmail.com>
wrote:

> I'm pretty sure charter adjustments are independent of WGLC (which is to
> say don't hold up one with the other).
>
> -MSK
>
> On Tue, Jan 22, 2019 at 10:09 AM Seth Blank <seth@sethblank.com> wrote:
>
>> Scott, does this need to be addressed during WGLC for
>> draft-levine-eaiauth?
>>
>> ---------- Forwarded message ---------
>> From: Scott Kitterman <sklist@kitterman.com>
>> Date: Sun, Nov 4, 2018 at 9:14 PM
>> Subject: Re: [dmarc-ietf] Proposed charter spiff to accept EAI
>> clarification within email authentication stack
>> To: Kurt Andersen (b) <kboth@drkurt.com>
>> Cc: dmarc@ietf.org <dmarc@ietf.org>
>>
>>
>>
>>
>> On November 5, 2018 3:21:15 AM UTC, "Kurt Andersen (b)" <kboth@drkurt.com>
>> wrote:
>> >This came out of this morning's DISPATCH meeting at IETF103 (
>> >https://tools.ietf.org/wg/dispatch/agenda) to be able to accept
>> >http://tools.ietf.org/html?draft=draft-levine-appsarea-eaiauth into the
>> >WG
>> >for advancing it to an RFC (probably informational).
>>
>> Thanks.  It doesn't appear that it proposes any changes for SPF.  It
>> merely documents that non-ascii local parts don't match the related
>> macros.  During the SPFbis working group we looked at this and explicitly
>> decided on it.  It's not by accident.
>>
>> Since local part macros are very rarely used, it seemed like very much a
>> corner case not worth it to break the installed base over.
>>
>> If there's going to be a charter change around this, I think it needs
>> some words to constrain the work to limit interoperability implications.
>>
>> I know less about the implications for DKIM and DMARC, but would imagine
>> backward compatibility is important there too.
>>
>> Scott K
>>
>> _______________________________________________
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
>> _______________________________________________
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>