Seth is right here: Doug, your message doesn't comply with what I've asked people to do, in two ways: it's asking for a change to something we already have consensus on and it's not proposing specific text changes.
That said, there are two mitigating factors. For the latter, the request is specific enough that I think there's enough detail to discuss it. For the former, the PSD= feature is new enough, and our participation level has gotten low enough that it's difficult to say how strong the consensus is on that point, and I think it's reasonable to have another look. I've discussed this with Seth since his message below, and I'm allowing this issue to be opened for discussion, BUT... ...BUT let's keep the discussion focused and productive: I will cut it off at some point, so it's important that everyone in the discussion make their points clear and concise. John has replied that this is incompatible. Yes, but PSD= is also, at some level, incompatible... though far less so. So here's one thing I'd like to see discussed: - Doug, please clearly and concisely explain what benefit this has over the current PSD= tag that makes the incompatibility with existing implementations worth it. - If you disagree with Doug's proposal, please clearly and concisely explain why the benefit he is proposing is not useful enough to introduce the incompatibility. Barry On Sat, Aug 27, 2022 at 3:01 PM Seth Blank <s...@sethblank.com> wrote: > > Doug, Barry's email sent as Chair was clear and specific: > > On Fri, Aug 26, 2022 at 8:33 AM Barry Leiba <barryle...@computer.org> wrote: >> >> We have come to a point in our discussions of >> draft-ietf-dmarc-dmarcbis that the basic content and features of DMARC >> are stable and have rough consensus. Coupling that with the >> expectation, as in the working group's charter, that changes to the >> protocol that break interoperability with installed base need detailed >> justification, I think we need to be clear on how to go forward as we >> finish up. >> >> At this point, again, we consider the content and features to be >> stable, and changes to that are no longer in scope. > > > What you raise as alternative token design goes counter to this clean line. > > Further, we're at the point of the bis project, as Barry also points out, > where we expect comments to be accompanied by text suggestions, preferably in > an OLD/NEW format. > > Doug, if you believe there is an issue here within scope of the text I quoted > from Barry, please cite the section and text in the document and propose > updated language. > > Otherwise, the time for topics like these has come and gone. > > Seth, as Chair > > On Fri, Aug 26, 2022 at 8:08 PM Douglas Foster > <dougfoster.emailstanda...@gmail.com> wrote: >> >> Alternative token design. >> >> >> Boundary=A (Above only) >> >> Literal: The domain owner asserts that an organizational/administrative >> boundary exists between the current domain and its parent, meaning the >> domain and its parents are not aligned for relaxed authentication. No >> boundary exists immediately below this domain, so its child domains are >> aligned with it for relaxed authentication. >> Role: An Organizational Domain >> PSL Equivalent representation: The domain does not exist in the PSL, or is >> listed with negation. The parent domain is listed in the PSL, and without >> negation. >> Tree walk significance: The tree walk always stops on Boundary=A, as this >> domain is the organizational domain and provides the default policy. >> PSD=token equivalent: “psd=n” >> >> >> Boundary=N (None, Neither) >> >> Literal: That domain owner asserts that the domain does not have any >> adjacent organizational/administrative boundaries. >> Role: An organizational subdomain. >> PSL Equivalent representation: : The domain does not exist in the PSL. The >> parent domain is also not listed, or listed with negation. >> Tree walk significance: The domain owner has indicated awareness of >> DMARCbis. The tree walk will end on domain with a DMARC policy and a >> “Boundary=A” term. If an explicitly tagged organizational domain policy is >> not found, the result is PERMERROR and the evaluator is recommended to fall >> back to strict alignment. >> PSD=token equivalent: None >> >> >> Boundary=2 (Both above and below) >> >> Literal: The domain owner asserts that an organizational/administrative >> boundary exists both immediately above and immediately below this domain. >> Consequently, an exact match is required for alignment. >> Role: All Public Suffix Domains and many Private Registry domains. >> PSL Equivalent: Both the current domain and its parent are listed in the >> PSL, both without negation. >> Tree walk significance: The tree walks stops. If this is the exact-match >> domain, the organizational domain and default policy are from this record. >> If this domain is encountered subsequently during the tree walk, the walk >> stops, the current domain policy is the default policy but the immediately >> lower child domain is the organizational domain for relaxed alignment. >> PSD=token equivalent: Nothing provides a complete equivalence, but PSL=Y is >> used as an approximation. >> >> >> Boundary=B (Below only) >> >> Literal: The domain owner asserts that an organizational/administrative >> boundary exist between this domain and its child domains, so its child >> domains are not aligned for relaxed authentication. No >> organizational/administrative boundary exists above this domain, so this >> domain can participate in relaxed alignment with its immediate parent. >> Role: A private registry whose parent domain is in the same organization. >> PSL Equivalent: The current domain is listed in the “Private Registry” >> section of the PSL, without negation. The parent domain is not listed at all. >> Tree walk significance: If encountered on the exact-match domain, the domain >> is treated the same as “Boundary=N”, and the tree walk proceeds upward. If >> encountered subsequently during the tree walk, the domain is treated the >> same as “Boundary=2”: the Tree Walk stops, the current domain policy becomes >> the default policy but the immediately lower child domain is the >> organizational domain for relaxed alignment. >> PSD=token equivalent: : Nothing provides a complete equivalence, but PSL=Y >> is used as an approximation. >> >> >> DMARC policy with no Boundary=token term >> >> Literal: The domain owner has not added new information in support of >> DMARCbis to his policy. The presence or absence of >> organizational/administrative boundaries must be inferred. >> Role: Not stated and therefore not known with certainty. >> PSL Equivalent: None. The PSL lookup always returns a result. >> Tree Walk significance: Information about this policy is stored, the Tree >> Walk continues upward, and an inference is made when the Tree Walk is >> complete. >> PSD=token equivalent: “psd=u” >> >> >> Domain with no DMARC policy >> >> Literal: The domain owner has not attached a DMARC policy to the current >> domain. >> Role: Not stated and therefore not known with certainty. >> PSL Equivalent: None. The PSL lookup always returns a result. >> Tree Walk significance: Information about this policy is stored, the Tree >> Walk continues upward, and an inference is made when the Tree Walk is >> complete. >> PSD=token equivalent: Not applicable. Since no policy is present, no tokens >> are present in that policy. >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
