Yes, PSD is still the appropriate term for a PSO-controlled domain. We need an additional definition for a "Private Registry Domain" (optionally "PRD" if we want to create another acronym.) Collectively, PSDs and PRDs are "registry domains". We intend to use a single DNS token for both PSD and PRD policies, so the token definition needs to be clear on this point.
RFC 7489 was amiss by not defining private registries, and that has created confusion about how to interpret the PSL. But as long as the PSL had correct information, the distinction did not affect DMARC accuracy. With the tree walk, the possibility of multiple registry domains in a single DNS path creates some challenges, and these need to be explained. We can resolve an ongoing dispute by providing two approaches to implementing the tree walk. John's approach makes some simplifying assumptions in order to replace the entire PSL immediately. My approach is more cautious and is inclined to use the PSL when explicit tagging is not available. Evaluators can chose which to use based on their perception of the tradeoffs. Domain owners can solve the problem by providing explicit tags to ensure that both approaches obtain the same result. DF Then the text needs to be clear about when PSDs and PRDs are similar, and when the differences are noteworthy. On Sat, Jul 2, 2022 at 7:32 AM Barry Leiba <barryle...@computer.org> wrote: > That's true, while we won't have the PSL in the algorithm, we will > still be talking about PSDs, so the term will remain defined. OK, > that makes sense, Scott; thanks. > > Barry > > On Mon, Jun 27, 2022 at 9:46 AM Scott Kitterman <skl...@kitterman.com> > wrote: > > > > If we use a different term, we'll need to define it. Fundamentally, I > think changing the name only adds a level of indirection (and thus > complexity). > > > > Current: > > > > PSD (which is defined in the document) yes or no or use tree walk. > > > > Proposed: > > > > Role (needs a definition) PSD (defined), Org (defined as not a PSD), and > Subdomain (which isn't defined and is technically wrong - all three might > be subdomains). > > > > Whether you directly use psd as the tag or not, the question is still is > it a PSD or not. The suggested change doesn't do anything towards getting > away from PSD as a concept or a defined term. > > > > I think that by hiding it in the definitions, it will be more confusing, > not less. > > > > Scott K > > > > On June 27, 2022 1:27:37 PM UTC, Barry Leiba <barryle...@computer.org> > wrote: > > >I have to say, as a participant, that I have more than a little > > >sympathy for this suggestion or some derivative of it. Using "psd" as > > >the tag name is rooted in history that will be lost as we move away > > >from using a public suffix list. > > > > > >Barry > > > > > >On Mon, Jun 27, 2022 at 6:20 AM Alessandro Vesely <ves...@tana.it> > wrote: > > >> > > >> On Sun 26/Jun/2022 18:05:44 +0200 Barry Leiba wrote: > > >> > > > >> > Please comment in this thread about whether you agree with making > the > > >> > registration now, or whether you do not agree and why. > > >> > > >> > > >> I'd like to make a last appeal to use more intuitive symbols to be > used instead > > >> of the current ones: > > >> > > >> instead of | use | to mean > > >> > -----------+----------+----------------------------------------------------- > > >> psd=u | role=sub | the default subdomain role (never needed) > > >> psd=n | role=org | the org domain (only needed with non > compliant PSDs) > > >> psd=y | role=psd | a PSD (needed if PSD published DMARC record.) > > >> > > >> > > >> The reason to use cryptic symbols seems to be to discourage their > usage, which > > >> I can hardly understand. I'd be OK with the current symbols if the > WG can > > >> explain somewhat better, possibly as part of the spec itself, the > rationale of > > >> using counter-intuitive yes/ no/ undefined to express that > three-valued value. > > >> > > >> > > >> Best > > >> Ale > > >> -- > > >> > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> 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 > > _______________________________________________ > 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
