Re: [dmarc-ietf] Lars Eggert's No Objection on draft-ietf-dmarc-psd-12: (with COMMENT)

Tim Wicinski <tjw.ietf@gmail.com> Thu, 15 April 2021 23:45 UTC

Return-Path: <tjw.ietf@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 A10FE3A34B8; Thu, 15 Apr 2021 16:45:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
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: 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 tHj2cgLvOF3s; Thu, 15 Apr 2021 16:45:16 -0700 (PDT)
Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 80D123A34B6; Thu, 15 Apr 2021 16:45:15 -0700 (PDT)
Received: by mail-il1-x132.google.com with SMTP id c15so21673413ilj.1; Thu, 15 Apr 2021 16:45:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=of5/Qpp3otPM/ENd8na2UfHALUqlp1WgvCgLutlh63g=; b=vVRcKY5b5fSUNaucvUaoLaT5/Ags3w0hjueMnV2sL6VEeSD6UEp2MX00ZEt/xTHg/b uZpFL6wYDzOf7X7ljZQcSxbqY0+18TeoflUJk/ylsZL7un30JgI0xRVBukV+FhqM0MRz vLyxVfzTMoW4He7CTCFREnl4JWmg6MNM2qxqZLWVyGzMkcmLL5HfgGl9vDccDcAC7AYc mkYG3Xs+3uiIgw5U17bm/OFFshN3iteqxHat93YRolgcoUmRM+kaKR04OoyLBzrLNYPp j3VeLYNyGepwJHCmyhydauB6BOIz0g2YGr4bZ4Rr+xtT9IywBP2VZ8Nns5KYriY/M2ur 0QiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=of5/Qpp3otPM/ENd8na2UfHALUqlp1WgvCgLutlh63g=; b=VXJ5++L5oWOgMa3yjiJ1mpEhSuOUTlVJbKtQEPqXLqoCvNcg9NnESSW8b1c/rtD09u fm7lzLdpwtTXV28O6Pd0dWcDII9SVjAbVTIXGcCB1/V6NiLUm2NfngJ/a1YXiLdwo8l8 WcuyGuXwEJvrk0E0rfMLQL7Ff/suPNm0Ap+JS3jdNxa/e9uDYsCef1m1ehY7/GuDNPb7 QpbAcopWEJckkYQ1FsdGNeCOCiruWC1esEvlLRh75AtasOuaMJzwyFsd804IOgavnsOL ZDvThGNMVSi5z1/sfCUsmaH8MgCtGticMKtHL3Jc+weKjPP72Qxs1C3c1afQIlu3vdsW gI4w==
X-Gm-Message-State: AOAM533lWhzWUqhfRCXe6Q3NEOwcDtuDPHYqVnnUBaNRwB/KtwBFZ7DR OX1ihrd5k+nV/HDY0DOMQjdsWBHDq7IkpXhIMZw=
X-Google-Smtp-Source: ABdhPJxN+sVvegI+zu80lQadSicJyHvjlK69+e8dptPQYAecQ2/W1g2085/kBbzEDzu9sK4WFm0nGNoiwG3DHkscyK4=
X-Received: by 2002:a05:6e02:1e08:: with SMTP id g8mr4799200ila.176.1618530312495; Thu, 15 Apr 2021 16:45:12 -0700 (PDT)
MIME-Version: 1.0
References: <161838987873.7792.14994930450767048926@ietfa.amsl.com>
In-Reply-To: <161838987873.7792.14994930450767048926@ietfa.amsl.com>
From: Tim Wicinski <tjw.ietf@gmail.com>
Date: Thu, 15 Apr 2021 19:45:00 -0400
Message-ID: <CADyWQ+GbS7p6wGrYz-ThbmoxXfvU2wExUN+e35J=FVpPJF6_3A@mail.gmail.com>
To: Lars Eggert <lars@eggert.org>
Cc: The IESG <iesg@ietf.org>, draft-ietf-dmarc-psd@ietf.org, dmarc-chairs@ietf.org, IETF DMARC WG <dmarc@ietf.org>, Alexey Melnikov <alexey.melnikov@isode.com>
Content-Type: multipart/alternative; boundary="00000000000055a5aa05c00b74d0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/tbCTb_lk5AlKxFZx9hC9U3rqk_A>
Subject: Re: [dmarc-ietf] Lars Eggert's No Objection on draft-ietf-dmarc-psd-12: (with COMMENT)
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: Thu, 15 Apr 2021 23:45:21 -0000

Lars

See below. Thanks for the comments


On Wed, Apr 14, 2021 at 4:44 AM Lars Eggert via Datatracker <
noreply@ietf.org> wrote:

> Lars Eggert has entered the following ballot position for
> draft-ietf-dmarc-psd-12: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Section 3, paragraph 2, comment:
> > 3.  PSD DMARC Updates to DMARC Requirements
> >
> >    This document updates DMARC as follows:
>
> If I understand things correctly, this document specifies an experiment
> that -
> if successful - would lead to an update of RFC7489. It's therefore
> confusing to
> see the text in Section 3 that is written as if that update was already
> being
> brought into effect. I'd much prefer text that said things like "to
> participate
> in this experiment, implementations should do X or Y or Z and/or interpret
> Section foo of RFC7489 as bar", etc.
>
>
"To participate in this experiment, implementations should nterept RFC7489
as follows"



> Section 7.3, paragraph 1, comment:
> > 7.3.  URIs


This appears to be some artifact of the XML as the URI is listed in the
Informative
Reference section.


>


> It's unusual for an RFC to have reference sections other than for
> normative and
> informative references, because it's not clear what category references
> here
> would fall into. Also, I'll note that [psddmarc.org] was cited as an
> informative
> reference in that section, so why not this one?
>
>
> -------------------------------------------------------------------------------
> All comments below are very minor change suggestions that you may choose to
> incorporate in some way (or ignore), as you see fit. There is no need to
> let me
> know what you did with these suggestions.
>
> Section 3.2, paragraph 3, nit:
> >       to that of the "p" tag defined below.  If the 'np' tag is absent,
>
> The document uses both single and double quotes throughput (above is an
> example), and it's not clear if this is deliberate (i.e., there is a
> meaning to
> this) or whether this is an editorial oversight that should be corrected.
>
>

I believe I've corrected all of these quote mismatches (that is, I've found
all the
single quoted mentions and have updated them to double quotes).


> Section 6.1, paragraph 5, nit:
> >    +----------+-----------+---------+-------------------------------+
> >    | Tag Name | Reference | Status  | Description                   |
> >    +----------+-----------+---------+-------------------------------+
> >    | np       | this      | current | Requested handling policy for |
> >    |          | document  |         | non-existent subdomains       |
> >    +----------+-----------+---------+-------------------------------+
> >
>
> You should add an RFC Editor Note instructing them to replace "this
> document"
> with the RFC number of this document (to make sure they are aware of the
> action).
>
>
Done


> Section 1, paragraph 2, nit:
> -    DMARC ([RFC7489]) provides a mechanism for publishing organizational
> -          -         -
> +    DMARC [RFC7489] provides a mechanism for publishing organizational
>
>
Fixed

> Section 1, paragraph 3, nit:
> -    found in Section 3.2 of the DMARC specification.  Currently the
> +    found in Section 3.2 of the DMARC specification.  Currently, the
> +                                                               +
>
> Section 1, paragraph 4, nit:
> -    In the basic DMARC model, PSDs are not organizational domains and are
> +    In the basic DMARC model, Public Suffix Domains (PSDs) are not
> organizational domains and are
> +                               +++++++++++++++++++++++   +
>
>
Fixed

> Section 1.2, paragraph 7, nit:
> -    handling policy for non-existent subdommains.  This is provided
> -                                           -
> +    handling policy for non-existent subdomains.  This is provided
>
>
Fixed

> Section 1.2, paragraph 7, nit:
> -    of requesting harsh policy treatment (e.g. reject) is lower.
> +    of requesting harsh policy treatment (e.g., reject) is lower.
> +                                              +
>
> Section 1.2, paragraph 8, nit:
> -    (i.e. if a DMARC record were published for 'example', then mail from
> +    (i.e., if a DMARC record were published for 'example', then mail from
> +         +
>
>
Fixed



> Section 2.7, paragraph 2, nit:
> -    is a broader definition than that in NXDOMAIN [RFC8020].
> -                                         ---------
> +    is a broader definition than that in [RFC8020].
>
> Fixed


> Section 4.1, paragraph 7, nit:
> -    not particpate in DMARC, any Feedback Reporting related to multi-
> +    not participate in DMARC, any Feedback Reporting related to multi-
> +              +
>
> Fixed


> "B.3.", paragraph 3, nit:
> -    supposed to be the output domain of the regular PSL lookup, i.e.  the
> +    supposed to be the output domain of the regular PSL lookup, i.e.,  the
> +                                                                    +
>
>
Fixed