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
