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

Dave Crocker <dcrocker@gmail.com> Sat, 20 February 2021 04:12 UTC

Return-Path: <dcrocker@gmail.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEC1D3A111A for <dmarc@ietfa.amsl.com>; Fri, 19 Feb 2021 20:12:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oY4gWxFrwEPp for <dmarc@ietfa.amsl.com>; Fri, 19 Feb 2021 20:12:25 -0800 (PST)
Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEC293A1117 for <dmarc@ietf.org>; Fri, 19 Feb 2021 20:12:24 -0800 (PST)
Received: by mail-oi1-x22d.google.com with SMTP id v193so8138601oie.8 for <dmarc@ietf.org>; Fri, 19 Feb 2021 20:12:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=4X0v5oxL/GzS74yoqiNLpND1RqCwBCu5Foq+nipLNyg=; b=fbJhRWvZTi1OUFoOXi/fnZC2QK3a6G7L6/2+EnlW34h5NBcFB8+6oC9ESYlsOLn16B hVeh2wta5YcuWZYuZ5QSJ4/cEO0ig6NC4p0DDwKA/Z3mfSkK/4HmyoIvxz2b1YGzU3+9 bFtDTq6ULmiMcxsXjimCNFgOwdqj0b9DptWUvVKKfrEAkk2HtTN3DJjqiR9t6ksDfgp0 W3nBtOk+i2GhtY3QtyOdhq3R0DyhfwLZJLAtvCIKo4JLnii90qre9jC60ZE56gvM9q6R MK7X5kmuKoh3JN2iIkypR9XUu69Yiy59T8+QDp5zTE5RAiq2Si1Z7QsPmE/2FEuI0QEY 8bdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=4X0v5oxL/GzS74yoqiNLpND1RqCwBCu5Foq+nipLNyg=; b=MqmtRzeCvwExi9TerTTe1QY+faaQa5oVO0xwCQAreXl9lugnWSM6KGdLmLGMspGTAt tSpGDiRur1jH/UhlsLWwxEekq79nKZNMhurUa9yYY6PMCnx1T3gJF7Tuxmb5W23GVziJ np0TRx/7s00FlPtnz1NXIaR/SyrIIsssC5pW/a4b5eWXzjllTQnvHDrEgaFreEOsBcBA 4lgKj/Q0ZkjuMsFtpkRsTacMiKT5WsJpdnLIQkpXNi7VWj8DSPOPOcQIVehxdWI37DZn 8fmwLlI1Z7SRAaJ1ipcNoRvIEHNtSk4K8LX8mx5cd7kZvA/PPPFxOkoDmd8GZsdIniP4 mCDA==
X-Gm-Message-State: AOAM5306weaiLPvoZ9h2GOmyISnjTqhmAs24+e0QTbUO5uGwrb2HXrqb Stq3pRzdVYqjEwcX2+9jj6Ks6UpV4lT6VQ==
X-Google-Smtp-Source: ABdhPJyeLMxQ6UEltO6mg6nurgOuDg8xfVe0Fh+EqV6cvEyPQnpQoF7INnkA6sRmAY9EU4xd/5dmJQ==
X-Received: by 2002:a54:4710:: with SMTP id k16mr4957917oik.67.1613794344109; Fri, 19 Feb 2021 20:12:24 -0800 (PST)
Received: from [192.168.0.109] (108-226-162-63.lightspeed.sntcca.sbcglobal.net. [108.226.162.63]) by smtp.gmail.com with ESMTPSA id r205sm2299262oib.15.2021.02.19.20.12.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 19 Feb 2021 20:12:23 -0800 (PST)
To: "Murray S. Kucherawy" <superuser@gmail.com>
Cc: IETF DMARC WG <dmarc@ietf.org>
References: <161144436332.13490.10651420808048876097@ietfa.amsl.com> <CADyWQ+EhD0nz71dLtUFwb9V_6uuen-k6E5fpvrCg3ZYzfr2JSw@mail.gmail.com> <ba38a9e4-7f43-c747-2d90-f35de22a8399@gmail.com> <CAL0qLwZJaEBrXdE9JOZNOJAgR7iEzfMA86Csi2sNtE5JC7ROUQ@mail.gmail.com> <c5cd9239-b204-255a-48a3-1cdccf18464a@gmail.com> <CAL0qLwYrcg__sewPO+EWfJf-5uoHcnQpFqtw-QoXxngHTJvkAA@mail.gmail.com>
From: Dave Crocker <dcrocker@gmail.com>
Message-ID: <e0a4c5eb-b047-67fe-8d76-e5beb921e5ae@gmail.com>
Date: Fri, 19 Feb 2021 20:12:22 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <CAL0qLwYrcg__sewPO+EWfJf-5uoHcnQpFqtw-QoXxngHTJvkAA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------698E0BE8366B8791B8C4BF25"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/cTqBIQnVJrRPgbGkrVtztSGcPDI>
Subject: Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Feb 2021 04:12:27 -0000

On 2/18/2021 9:10 AM, Murray S. Kucherawy wrote:
> Circling back to this:
>
> On Fri, Jan 29, 2021 at 12:56 PM Dave Crocker <dcrocker@gmail.com 
> <mailto:dcrocker@gmail.com>> wrote:
>
>     On 1/29/2021 12:15 PM, Murray S. Kucherawy wrote:
>>     On Fri, Jan 29, 2021 at 7:51 AM Dave Crocker <dcrocker@gmail.com
>>     <mailto:dcrocker@gmail.com>> wrote:
>>
>>>             organization can use to improve mail handling.  The design of DMARC
>>>             presumes that domain names represent either nodes in the tree below
>>>             which registrations occur, or nodes where registrations have
>>         DMARC does not have 'registrations'.
>>
>>
>>     ...
>
> I'm struggling to understand the concern here.  I think we all know 
> what it means to register a domain, and that the namespace is arranged 
> as a tree,


With the intent of building upon Barry's note:

<pedanty> Specification writing requires clarity of who the reader is 
and empathy with the experience they will have reading the document.  
</pedantry>

In that context "we all know" is automatically a red flag for requiring 
overly insider expertise.

However in this case, I think the problem is worse.

Simply put, I believe the text does not say what it means to 
distinguish, even for an expert reader.  So, yes, we all know what you 
say we know.

But in fact that's not the point of the text.  It's trying to make some 
other point,  I assume it's about a type of boundary status, but it 
doesn't say that, nevermind saying it clearly and with enough technical 
and semantic detail to distinguish it.

The text you offer:

> Maybe this is better, just for the sake of having something else to 
> look at?
>
>     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.  The design of DMARC
>     presumes that domain names represent nodes in the DNS tree that are either
>     reserved as points below which new domain name registrations are made, or are
>     the results of those registrations; it does not permit a node to have both of these
>     properties simultaneously.  Since its deployment in 2015, use of
>     DMARC has shown a clear need for the ability to express policy for
>     these domains as well.
moves closer to the mark, I think, but still doesn't get there.

EVERY node can have sub-nodes registered.  So it isn't clear what 
'reserved' means.

Worse is that:

    reserved as points below which new domain name registrations are made, or are
    the results of those registrations; it does not permit a node to have both of these
    properties simultaneously.

doesn't make sense to me.  I suspect an average technical reader will be 
at least as confused as I am.

d/


-- 

Dave Crocker
dcrocker@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crocker2@redcross.org