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

[Douglas Foster <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> 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 <[e-mail]>
> 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 <[e-mail]>
> 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
> > >> [e-mail]
> > >> https://www.ietf.org/mailman/listinfo/dmarc
> > >
> > >_______________________________________________
> > >dmarc mailing list
> > >[e-mail]
> > >https://www.ietf.org/mailman/listinfo/dmarc
> >
> > _______________________________________________
> > dmarc mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dmarc
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>