Re: [dmarc-ietf] Are Evaluators motivated to switch to Tree Walk?

[Scott Kitterman <[e-mail]>]

On June 18, 2022 2:35:07 PM UTC, "Murray S. Kucherawy" <[e-mail]> wrote:
>On Sat, Jun 18, 2022 at 6:48 AM Scott Kitterman <[e-mail]>
>wrote:
>
>> On Saturday, June 18, 2022 8:42:23 AM EDT Douglas Foster wrote:
>> > Let's talk through the selling process for the Tree Walk algorithm.
>> ...
>> > In sum, why should an Evaluator make the switch?
>>
>> I think there are some good points in here.  Fundamentally, I agree that
>> there
>> needs to be a value proposition associated with investing the resources
>> required to update a DMARC implementation from RFC 7489 to DMARCbis.
>>
>
>+1.
>
>1.  Does not use the PSL for something it was not intended for.  As has
>> been
>> mentioned many times, the PSL is designed for browser use cases, not
>> email.
>> In their words:
>> [...]
>>
>
>This has been the biggest motivator for me.  Today we're relying on
>something not intended for the purpose for which we are using it, with
>maintenance practices that make us nervous.  Whatever delta may exist
>between the PSL and tree walk approaches, I'd be willing to accept some of
>that conversion cost in the name of a more solid and defensible engineering
>and operational choice.
>
>I also still like the notion of decoupling the mechanism of identifying the
>OD from DMARC itself, which I think Dave suggested.  Have we fully
>dismissed that idea?

Given that the mechanism we've defined uses DMARC records to make the determination, I don't think it would be useful to separate it into a different document.  If we ever get an approach that's not DMARC specific, then I think it would make sense to document it independently.  

I see there's some sort of activity on the DBOUND list again.  If this ever produces a useful output, it would be useful to consider its potential applicability to DMARC.  I don't think we should worry about it now.

I think we have a good design that will provide what DMARC needs and we should get on with it.

Scott K