On July 13, 2022 3:10:38 PM UTC, "Murray S. Kucherawy" <superu...@gmail.com>
wrote:
>Once again, participating only:
>
>On Wed, Jul 13, 2022 at 3:43 AM Douglas Foster <
>dougfoster.emailstanda...@gmail.com> wrote:
>
>> [...]
>>
>
>> 2) I believe that the document needs a vigorous explanation of why the PSL
>> needs to be replaced. I made a stab at the effort in the text that I sent
>> Sunday night. Murray's text here is more comprehensive. But we need
>> something. We are asking evaluators to undertake a change which requires
>> effort and any change creates multiple risks.
>>
>
>I don't know about "vigorous", but I think some tutorial would be useful
>given the wide variability of experience in the ultimate audience. An
>appendix would suffice.
>
>
>> 3) The critical question is whether we can treat the PSL as replaced
>> without obtaining the markers first. On this issue, John and I have a
>> different assessment of the risk. I can accept a solution which lays out
>> the assumptions and risks to the evaluator, and lets them decide what to
>> do. This is what sections 4.7. and 4.8 in my text from Sunday night
>> attempted to do.
>>
>
>My suggestion would be that if we are going to offer a choice, there should
>be some eventual path toward convergence rather than an open-ended period
>of people doing either. Otherwise, the PSL will be a part of DMARC for far
>longer than we'd like.
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.
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.
Scott K
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
