Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

"Murray S. Kucherawy" <> Mon, 22 February 2021 07:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8B86E3A0C9A for <>; Sun, 21 Feb 2021 23:08:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QN0lnTkvIrFy for <>; Sun, 21 Feb 2021 23:08:51 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::e2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8DAE03A0C98 for <>; Sun, 21 Feb 2021 23:08:51 -0800 (PST)
Received: by with SMTP id t23so6011112vsk.2 for <>; Sun, 21 Feb 2021 23:08:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DOf2GNKQsNKKuLkh1T/EF3vMGwm+bnfvD5ht9mYx/ls=; b=jRI+83eUP074R+6uajLvC+C/qfsz83mVfAOM5Mw2lnOiB7JRPh14aB0HzjkNDXBwHH wQJThqARBU8pUtLKMpijgmImXAIyDRPvqSGhmCfD9JTMgJB6SbH6bRSZLN/OkcKjE/7L xyzGtlySrXmlq3EKH7eyZhQYeqXjfiCpi95V9ovq9lEgGHJUhpLPefQaergsFA3hIf/U /XT7/s5qu2sc62bxB7X5jZzCxBhAPvpmLYRs1f1rRpZzsEeSeitxV0OWelnpg8zGDrkw gIp4u8dottCIbAjRsenMgTlm/e9qDkbwWOgCtBxXf8FHOn+eoI/NIfTyer224zgaSrE8 YTVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DOf2GNKQsNKKuLkh1T/EF3vMGwm+bnfvD5ht9mYx/ls=; b=fx13fzveAT7ijiE/MBeOIScmjoIGdT11GDnkUKGNBHPIVUk7LFzrc5MHIfoXJBUYTK y9085quZXasEGB4I8KYmkJpaYTga1jqzRB5UEUe1YezUJWdgXeNXnjy1m2id9w6WgDc0 /4P9ilZetyjI1wLLaLpdghhlLTLoGkj52s1pDIvVnVg0P52DHh0YTZJXPpo+wwrVui/i XWsLKcshsnj+JE+a9uVmBP2tFqGJXzIR6m7aJg21h36/sGiokR5cp8LTRdcYahmKs9Jo MbjnuAZUsP3285tl7jQ0n76Ba0qojW3W7P0GlOj0GBHFRjfMhwmkBPW5LBcSWuoC7p/o fGEQ==
X-Gm-Message-State: AOAM53023z7h+OSanRgjVdFpSgikKJ1mleLseMmWDGyF1S2bGnIrfzrK O7RDGnT2crqX2TYsH/7WgnPKhN+praEZ/aBf5nI=
X-Google-Smtp-Source: ABdhPJwYqq+Aw494KM23BH9lO9HlATKm6oycb2CEF80oCyqC5wabkVtqZ8nqXAsOFy5ESLDm9ui6xBqx5FYT3CCFnJY=
X-Received: by 2002:a67:f7d0:: with SMTP id a16mr6633395vsp.15.1613977730460; Sun, 21 Feb 2021 23:08:50 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
From: "Murray S. Kucherawy" <>
Date: Sun, 21 Feb 2021 23:08:37 -0800
Message-ID: <>
To: Barry Leiba <>
Cc: Dave Crocker <>, IETF DMARC WG <>
Content-Type: multipart/alternative; boundary="0000000000004cb10405bbe7791f"
Archived-At: <>
Subject: Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 22 Feb 2021 07:08:54 -0000

On Fri, Feb 19, 2021 at 3:02 PM Barry Leiba <> wrote:

> I agree that the abstract is unclear.  This makes no sense to me:
>    domain names represent either nodes in the tree below
>    which registrations occur, or nodes where registrations have
>    occurred; it does not permit a domain name to have both of these
>    properties simultaneously.
> I don't understand the distinction that it's trying to make between
> the two possibilities.
> I also don't see the antecedent to "these domains" in the final
> sentence of that paragraph.
> Beyond that:
> > I'm at a loss to understand what's confusing.  I'm not convinced that
> "registrations" in the
> > context of domain names is unclear to a reader familiar with this space.
> I am absolutely convinced that it is.  Think of people in M3AAWG, for
> whom this is very relevant.  Many of them don't know much about
> registries, registrars, and such, and in general, the average reader
> won't understand the difference, from a "registration" standpoint,
> between (which is registered) and ""
> (which is not).  To the average reader, "" is registered
> under com, and "" is registered under facebook.  And
> the ones who don't think that will likely not understand why we can't
> just talk about second-level domains and be done with it.

Actually that's a community that I would expect to know exactly what all
those terms mean and how they are all related.

I think the use of "registered" seems to be the source of some of this
confusion.  To work with the example you gave here, I agree that "" is registered (under "com"), but disagree that "" is registered at all; "" was delegated to
some company that now "owns" that piece of the namespace tree and can
create whatever it wants under there without any external arrangement.  To
my mind, "register" involves a specific transaction, sometimes involving
money, with whoever gates access to make those delegations.

All that needs to be explained in the Introduction, not the Abstract.
> But the Abstract has to explain enough for a reader to understand why
> she might or might not be interested in getting the document and
> reading it.  So it's going to be tough to word it carefully and to
> keep it concise.  But we have to.
> Stressing a point:
> We very clearly do NOT want to explain this stuff in the Abstract.  In
> fact, we don't have to explain much at all in the Abstract.  What we
> have to do is make sure that the Abstract doesn't say stuff that's
> *wrong* or confusing.  So let's try to find some fifth-grade language
> that can suffice, and then make sure the Introduction has the right
> words to make it clear to people who know how to do email, but who
> don't already understand the issues involved here.

How's this?:

   DMARC (Domain-based Message Authentication, Reporting, and
   Conformance) is a scalable mechanism by which a mail-originating
   organization can express domain-level policies and preferences for
   message validation, disposition, and reporting, that a mail-receiving
   organization can use to improve mail handling.

   Within the Domain Name System (DNS) on the public Internet, which is

   organized as a tree, some nodes of that tree are reserved for use by

   registrars, who delegate sub-trees to other operators on request.
DMARC currently
   permits expression of policy only for such sub-trees.  There is a
marked desire to

   be able to express policy for the reserved nodes as well.  This document

   describes an experimental extension to DMARC to add that capability.

If we like that as a replacement Abstract, I'll carry on and propose a
revision to the Introduction.