On Saturday, January 29, 2022 11:25:30 PM EST Dave Crocker wrote: > On 1/29/2022 7:53 PM, Scott Kitterman wrote: > >> 1. Using 7489 or 9091 as fixed, controlling documents is problematic, as > >> I've noted. So, 'consistency' with them is frankly irrelevant. > > > > The WG charter doesn't say that they are irrelevant. I don't think we > > should be redefining terms for the sake of redefining terms. You've > > given no rationale for there being a problem with the current definition, > > so I don't think it's up to me to make the case for why things shouldn't > > change. > > 1. For this topic, they are irrelevant. There is nothing in the charter > that says terminology must be preserved. Interoperability is not > endangered by changes in terminology.
I disagree. Having the same term mean two different things in different DMARC RFCs is a recipe for confusion. Confusion leads to programming and configuration errors, which definitely impact interoperability. I think the current definition of Organizational Domain is fine. If you think there is a problem with it, I would encourage you to come up with a different term to use in DMARCbis (and whatever other documents it's relevant to) and make your case. > 2. Your 'for the sake of' is uncalled for and dismissive. Please stop > doing that. Attempts to be dismissive are a popular debating technique > in the IETF, but they are counter-productive, as well as > unprofessional. (And no, this comment is not just meant for you. You're > just lucky, tonight.) I agree they are unfortunately common, but you've made no case for the change beyond that fact that you proposed it. You may, in fact, have a good reason for it, but I have no idea what it is. That's my opinion based on what I know. If I missed something about why you think this is worth spending time on, please point me at the reference or explain it. > 3. As for giving no rationale, 'tree walk' posting set the stage. > > a) Today's posting specifically noted: > > "the move towards supporting (at least) two very different methods > of finding it." \ > > b) Again: for DMARC, the semantics of the different mechanisms is > the same. Hence a single term. > > There is quite a bit of benefit in having a single term to cover > different means of achieving the same goal. > > So now I'll again ask: what are the semantic differences that are > relevant to DMARC, and what is the benefit of having DMARC use different > terms, given that DMARC does not care about which mechanism is used? Since relaxed mode alignment in RFC 7489 Section 3.1 is referenced to the organizational domain, changing the definition of organizational domain to include PSDs would have a huge impact on DMARC. DMARC may not care about the mechanism (I agree with that), but it certainly cares about the result. With your proposed change maryland.gov could send mail with a DMARC pass from virignia.gov. While that's not particularly catastrophic, as soon as a non- governmental PSD publishes a record, it would be. > >> 2. To the extent that the text I've proposed does not accurately reflect > >> the semantics of what DMARC needs, please explain what, specifically, > >> are the issues. > > > > I'm not aware of any related to a need for this new text. I think that's > > up to you. > > Sorry no. It's not my job to guess at your objections. I'm pretty sure > it's your job to explain them. I've made my objections pretty clear, I think. I don't see any problems with the RFC 7489 definition. If you want to change something, surely it's not my job to read your mind. To the extend I understand your reasoning (see above), I think it's factually incorrect. > >> 3. The role of the function that uses the PSD and the role of the > >> function that does a tree walk are identical. Since you apparently feel > >> otherwise, please explain. > > > > A PSD is potentially useful for DMARC policy determination if no policy > > exists for the exact domain or the organizational domain. It is not > > useful for evaluating relaxed alignment. Only the organizational domain > > can be used for that. So I do not think you are correct. > > The RFC 9091 does not contain the word 'relaxed', so I'm curious about > the basis for your assertion of the limitation. Because relaxed mode alignment is defined in RFC 7489, as defined in RFC 7489 explicitly excludes PSDs (although not using that term, since you hadn't come up with it yet), and RFC 9091 makes no changes to it. This is just one of the many things about RFC 7489 that RFC 9091 neither changes nor mentions. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
