Re: [dmarc-ietf] Opsdir last call review of draft-ietf-dmarc-psd-08

"Murray S. Kucherawy" <> Thu, 02 April 2020 01:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4C08B3A07BC; Wed, 1 Apr 2020 18:05:12 -0700 (PDT)
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 4HJh65QJfIEW; Wed, 1 Apr 2020 18:05:09 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::e31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7E4083A07B6; Wed, 1 Apr 2020 18:05:09 -0700 (PDT)
Received: by with SMTP id x206so1245628vsx.5; Wed, 01 Apr 2020 18:05:09 -0700 (PDT)
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=8XvWPwmbBKQT+oI985760Xhqv/Ws+iddhNeBt/lriTQ=; b=LuE5Y7MzjuEGEBlrXbMSakYR891aP3zzYlcBWFl33wc2GjyFMD2LBd89BosUzLyH+0 2vwuHq3lxN2HmPWYAEEt6O++QNljMGx/pqQ8ouydo4CP0UNl1u1ukzl+3zg6blUcK0Ss eTck99TkhI7lrcq49cbBxl2VZ57rBMSDeowD2n1cyH29msFl2zTS8QxPQdLxDrYdbOpK wvlJanx7WXHIq8/pqKQCNo/wK73xidzbG5S3HvqH2JKjsy+0/AWcnErE9+FIQ/4UXzZI 2h2f2MnJONAGiMuJIjJ0VwUyBlPrGEb//dZknrNejxE5aN7IU2Ckt+r2XHfYaYEfnhhB Ws2Q==
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=8XvWPwmbBKQT+oI985760Xhqv/Ws+iddhNeBt/lriTQ=; b=mig42+AlwM0wufmgP4rSLM/Fa2UGTNUx+dz013684G2xGvXrwX8taoaMd4TBSrxw2A bZsgBLfhFu4qSvUWupfKy2GA2QDrV8LdDnnkSEkAPQfrbG4UWVfA7E5fY+V+qkX0Urr+ /CWlyDkvH8D9rvXB2GQNDW7jUGZuovIIpj0vzdX2apBT92WGB73WJBcP9mfqT6ilkM4/ Y3dLTxcdgomiuFI8p5l5BKYaJvISnB8d9PQ3xBEeXtmB2SZOjNL09jJadbwmPkMSrez1 oGWCufvZaO9qy5SdmyY5Rki3lbRGo6K6L+1h4jbC9jgjC1dmWGySEmI9Xi/Vu6X7YVL5 vPDg==
X-Gm-Message-State: AGi0PuZ/xLF35LekBpE7NKTg4oZQYC9ru2sAnNCMx/pzZv3EGBQsy13o XWjOZawsqmNxaCkW6iNDk1j/RPd20KGzAiYjXqE=
X-Google-Smtp-Source: APiQypLWPT9qWkhbcAHdSwRMFBrE3/S6h46YxVsQJg0THFxDE6Dd+2I5rPMWkhRklIgct9+HQToMAyBELPUwqGWPcAk=
X-Received: by 2002:a67:f4d5:: with SMTP id s21mr480427vsn.8.1585789508261; Wed, 01 Apr 2020 18:05:08 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: "Murray S. Kucherawy" <>
Date: Wed, 1 Apr 2020 18:04:57 -0700
Message-ID: <>
To: Qin Wu <>
Content-Type: multipart/alternative; boundary="000000000000541bc505a2446433"
Archived-At: <>
Subject: Re: [dmarc-ietf] Opsdir last call review of draft-ietf-dmarc-psd-08
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: Thu, 02 Apr 2020 01:05:12 -0000

On the process questions raised:

On Wed, Apr 1, 2020 at 12:06 AM Qin Wu via Datatracker <>

> Minor issue:
> This document provide two registries, one is update of DMARC Tag Registry
> with
> one new element, requested from IANA, the other is DMARC PSD registry
> maintained by [] and following IANA registry style, I see one
> is
> standard registry, the other is non-standard registry, it is not clear to
> me
> non-standard registry should be discussed in this document, which introduce
> confusion, if we keep both, I am wondering why section 6 still requests to
> add
> an element to standard registry, which functionality we add is
> experimental,
> which functionality is not.

It's helpful here, I think, that the IANA Considerations section includes
the IANA stuff, and an Appendix contains the other stuff.  I don't think
this is particularly confusing; the two are well-separated.

Second related question, this draft updates informational RFC7489 with
> additional components and rules, should the front page of this
> Experimental RFC
> reflect this or not? Nits: Section 1 Somewhere subdommains is used,
> somewhere
> sub-dommains is used, please be consistent. Section 3.5 said:
> "Specifically,
> this is
>    not a mechanism to provide feedback addresses (RUA/RUF) when an
>    Organizational Domain has declined to do so.
> "
> Should a reference be added to RUA/RUF, RUA/RUF needs to be expanded or add
> abbreviation section in the terminology section.

This is an experiment to see if RFC7489 should be augmented, i.e., is the
experiment described here useful to DMARC?  If it turns out it is not, then
saying this updated the base specification wouldn't be such a good thing.
If it turns out that it is, then the DMARCbis work (which is about to start
up) will incorporate the experiment such that it becomes permanent.

Section 3.2
> "
> If the 'np' tag is absent, the policy specified by the "sp" tag (if the
> 'sp'
> tag is present) or the policy specified by the "p" tag, if the 'sp' tag is
> not
> present, MUST be applied for non-existent subdomains. " NEW TEXT: " If the
> 'np'
> tag is absent, the policy specified by the "sp" tag (if the 'sp' tag is
> present) or the policy specified by the "p" tag( if the 'sp' tag is not
> present
> and ‘p’tag is present), MUST be applied for non-existent subdomains. "
> Section
> 3.2 Change section 3.2 title from "3.2.  Section 6.3 General Record
> Format" To
> 3.2.  Changes in Section 6.3 "General Record Format" Similar changes can be
> applicable to other places.

I'll leave this bit to the authors and co-chairs to resolve.