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

[Alessandro Vesely <[e-mail]>]

On Sun 10/Jul/2022 19:04:08 +0200 Scott Kitterman wrote:

> 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 don't understand what you want.


An appendix exposing a walk through the algorithm.


>  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.


Well, we're discussing it now.  However, we're keeping on a meta-level 
above the matter.


> 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 reviewed the thread you cited.  I did ask questions about one of the 
changes when I replied.  John's answer, however, simply repeated the 
words of the draft.  He previously only said that if you are sending 
mail you are not really a PSD.  Then, one may wonder whether a filter 
should still consider a specific psd=y to be an error if it is going 
to meet it in subsequent steps, because once it received mail (or 
signatures) from that domain.


> 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.


We are proposing an alternative to the PSL without having any 
experience of it.  I think a Proposed Standard should give full 
explanations of design choices, so that possible, future amendments 
can be thoughtful and considered.


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


An appendix is usually not normative, and people not interested in 
delving into the specific detail just skip it.


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


It is not.  Neither suggests a better term.


> 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 needs to be in the document?


Hm... could do.


Best
Ale
-- 

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