Re: [dmarc-ietf] what to document about the tree walk

[Dotzero <[e-mail]>]

On Thu, Jul 14, 2022 at 11:12 AM Murray S. Kucherawy <[e-mail]>
wrote:

> On Thu, Jul 14, 2022 at 6:13 AM Scott Kitterman <[e-mail]>
> wrote:
>
>> >> I think a choice within DMARCbis is a bad idea.  Effectively the
>> choice exists.  Evaluators will have the choice to stay with an RFC 7489
>> design or to upgrade to DMARCbis.
>> >
>> >The incentive to upgrade is not clear.  DMARC filters can run based on
>> an obsolete version of the PSL with no inconvenience, for a different
>> flavor of "upgrade".  Indeed, according to John's figures, we could have
>> done without any psd= tag.
>> >
>> Using obsolete data is a bug, not a feature.
>>
>
> Or using data that is accidentally correct most of the time, where
> alternatives are available.  Either way, +1.
>
> >Doug's idea of checking the results is a means to draw the attention of
>> operators on both the PSL version they use and its agreement with the DNS
>> at large.  New implementations could be encouraged to track the differences
>> and produce some kind of report about them.  IME, although running a very
>> small mail site, it does happen to hit some PSL entry, a fact which I
>> realized by chance —browsing the logs— so I cannot tell figures.
>>
>
>> What would operators do with such a report?  Receivers tracking sender
>> configuration issues and reporting issues back to them is a very 1990s
>> approach to making the Internet work. I don't think it's relevant to
>> anything useful these days.
>>
>
> If we think this is important data to put in front of people, this WG
> could do that sort of survey once there are implementations and include the
> result in an appendix, or put it in the WG's wiki or in the IETF's
> collection of implementation reports:
> https://www.ietf.org/how/runningcode/implementation-reports/
>
> It sounds like we're mostly there already given the analysis John did
> previously.
>
> >> We can't get rid of the PSL without getting rid of the PSL.
>> >>
>> >> There's no way to constrain it within the document.  If we have a
>> 'choice', we are essentially signing up the IETF to a future effort to
>> produce an update to actually get rid of it.
>> >
>> >Right, that would be the Internet Standard.
>>
>> Not really.  To drop functionality going to Internet Standard, don't you
>> have to show it's not used?  How would that even work?
>>
>
> RFC 2026 lays out the criteria for progressing a Proposed Standard to a
> Draft Standard and then to Internet Standard, and RFC 6410 later
> consolidated the latter two.  The criterion to which I think you're
> referring asserts that any unused features need to be removed before a
> protocol can advance.  However, RFC 7489 is not a Proposed Standard, so
> we're not constrained by that here.
>
> In any case, I agree that the longer the PSL remains in the equation, the
> longer we have to keep it, due to both inertia and growth of the deployed
> base.
>
> My understanding is that the IETF, based on past experiences, doesn't do
>> flag days where everyone has to switch to some new thing by a specific date.
>>
>
> I think that's right, though Barry's memory on this might be better than
> mine.  At a minimum, they're exceedingly rare.  A working group or other
> community pushing for a flag day needs to have quite a bit of momentum to
> make it work.
>
>
>> Currently we don't have any procedural requirement for backward
>> compatibility, since RFC 7489 isn't an IETF document.  Based on the working
>> group charter and good engineering practice we should limit changes that
>> affect existing deployments, but we have more flexibility now than we will
>> ever have again.
>>
>> In my view, standardizing two ways to do policy discovery and alignment
>> would be a substantial danger to interoperability and we'd be stuck with it
>> approximately forever.
>>
>
> +1 to this, for the reasons John gave in the email right below this one
> that just came in.
>
> Bite the bullet and mark use of the PSL historical for DMARC. As has been
pointed out, there will always be a long tail but we are talking rare
corner cases where the results from the two approaches diverge.

Michael Hammer