Re: [dmarc-ietf] "psd=" tag early assignment

[Scott Kitterman <[e-mail]>]

On July 10, 2022 11:17:13 AM UTC, Alessandro Vesely <[e-mail]> wrote:
>On Sun 10/Jul/2022 03:05:47 +0200 John Levine wrote:
>> It appears that Scott Kitterman  <[e-mail]> said:
>>> On July 9, 2022 5:07:43 PM UTC, Alessandro Vesely <[e-mail]> wrote:
>>>>>> Yeah, /should/!  The very fact that you yourself changed your mind about how it works, without going into the hassle of explaining your reasoning, ...>>>>
>>>>> Um, what?  Scott and I went through some rounds of debugging to be sure the tree walk handled some obscure edge cases in a reasonable way.  It was all on this very mailing list with examples.  I think what we have now is OK but if you find something in the tree walk that is unclear or gets an unreasonable result, let us know, preferably with a concrete example.>>>
>>>> I think I received all list messages (although I don't check against your weekly count) and I read all of them.  Perhaps I've been inattentive, but I don't recall the switch from stop on psd=y to continue on psd=y if it's the first lookup.  Any pointer?>>
>>> I don't recall having changed this.  If you can check the previous draft revisions to see when it changed, maybe I could  find it.  I'm confident that any changes to the way the tree walk works have been discussed on the list.> 
>> I changed it in a pull request a few weeks ago.
>> 
>> If you don't stop on the first psd=y that is not the original domain,
>> you get the wrong result if there are DMARC records above the psd=y.
>
>
>That's undoubtedly correct.  The point I'm raising is the one at point 2 (both sections).  For org discovery, it's in the hunk tagged @@ -720,13 +722,13 @@ in the same pull request, here:
>https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/pull/47/files#diff-758de98ab8f970604c5891fceb8cb498ffe212c02060fdbf0e6ee5bffbb0a3cbL720
>
>That affects messages From: psd@c.b.a, in John's example below.  In that case, the change sets the org domain at b.a (assuming that blah stands for a DMARC record) instead of c.b.a.  That is, a PSD domain itself is a regular subdomain of the org domain below.  Apart from slightly complicating the algorithm, that might be a reasonable position.  IIRC, it wasn't discussed on list.  More importantly, it isn't explained in the draft.
>
>
>> I sent this example on June 21, link is
>> https://mailarchive.ietf.org/arch/msg/dmarc/T-8NX63L8ilHPhHXMygKdTJ6zMM/
>> 
>> a NXDOMAIN (or psd=y, doesn't matter)
>> b.a blah
>> c.b.a psd=y
>> d.c.b.a blah
>> e.d.c.b.a NXDOMAIN
>> 
>> I think the org domain for e.d.c.b.a is d.c.b.a.
>> 
>> If you don't stop at the psd=y, you get b.a as the org domain which still looks wrong to me.
>> 
>> The description in the current draft gets d.c.b.a.
>
>
>Yes.

I don't understand what you want.  I think (and I might be wrong) you agree the current draft gets the correct results, but you think there was some kind of process foul about how it got fixed.

I don't think your assertion that it wasn't discussed is correct.

John posted a pointer to the changes [1] and asked for comment.  You participated in the thread.  I don't know what else you want.  If a document author provides proposed changes and no one asks questions about one of the changes, I don't think it's incumbent upon the author to point out not everything was discussed.

I also don't know what explanation you want in the draft.  In my experience, IETF documents focus on what to do and do not generally have significant expositions on why or all the potential implications of a particular design choice.

As I said in that thread, I think going too far into corner cases like this is likely to make the document more confusing.

Finally, I struggle to understand how this detail is relevant to the question of early assignment of psd=?

Please help me understand what the issue is here?  It might be useful for you to start a new thread with specific text you think nerds to be in the document?

Scott K 

[1] https://mailarchive.ietf.org/arch/msg/dmarc/OaaC-N1MV-JlnpdDm0HTMVeSQrs/