Having a contract with ICANN rather than someone else is not much
relevant. The point of "private" PSDs is that they can be stacked
below a regular DMARC PSD. ("Private" is not the right term IMHO, as
it may sound like "within an org".)
Stacks deeper than two are unlikely because of the five label limit.
We set it because we found no domains deeper than that. That way,
we're imposing that the Internet topology cannot reach such shapes, or
that DMARC will have been forgotten by then.
Anyway, we need an appendix with an example of private (or should we
call them secondary?) registry, to illustrate both the algorithm and
the setting of psd='s.
Best
Ale
On Wed 06/Jul/2022 20:00:42 +0200 Douglas Foster wrote:
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 <[email protected]> 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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
