Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-02.txt

"Murray S. Kucherawy" <superuser@gmail.com> Sat, 08 May 2021 18:05 UTC

Return-Path: <superuser@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 232203A0B40 for <dmarc@ietfa.amsl.com>; Sat, 8 May 2021 11:05:40 -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 2mJqnCbkJtBg for <dmarc@ietfa.amsl.com>; Sat, 8 May 2021 11:05:35 -0700 (PDT)
Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 4DE013A0B1C for <dmarc@ietf.org>; Sat, 8 May 2021 11:05:35 -0700 (PDT)
Received: by mail-vs1-xe34.google.com with SMTP id x188so757407vsx.12 for <dmarc@ietf.org>; Sat, 08 May 2021 11:05:35 -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; bh=KTFqnoaAavDhfax5G0kJjoAVl/NhnYs0BcDEOec47So=; b=FA5YOy077igaDN8F8OBw8AmKvv35GBIuJN6GKWWFbFy91mUZZLpd9x8rJ0k3UjiPFH k6hW1x5PlK+Mw6YmotyTfaanCRQT2OvMydahyhUBlOFHLa0ZsZc+XXVh/Ix5Jdwe/tmq gQCaccWCNcDtu2ZdMxJkt9umPWN+cG/XJIdjfIM10Dw+BlnBBZBd7RgJX3dpP1nF3DAs 6Cxzz+mz52kFhymeEuFewHHpw4NM2a5tymAhlADHsOFTxNy43bVx9d+xxw+tVoWjszYh D46qGrLnjA6lOWbPd63v4K16GzbSojjwgQuVuvn3SRWwx76XKoKkaZ9zmLPrF1t4Bdug s0yg==
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; bh=KTFqnoaAavDhfax5G0kJjoAVl/NhnYs0BcDEOec47So=; b=VpMDiYdrVOAPQ6VzqqAfsNfpsYk3Q817138LZ1EcFHm+sZpc1vw/4G3VUzHpqd87AY 6B9YhcsFzR3qaFbDh37TFlLH1M844EtG++9mjTIdmxGnml75MPYr4Pu8MhjqtPW0GufC /R+8YKI35/RhwTlvcJ86F1raGrr3NKApv/ENaynsztgMrFnbOQzLc0oWwTwMa/SczEyt kBsWxaPIOAsy/9h55jrs5hV8VQjbDVwxzB2kzEW/Kv7qFy0B+1hoZOmeylUFK5kdmvFV 0ehn4XVg/sDr2VP0OsNrgCm80dc3J+s/eF7JwguiYOuUhD5mtiSD3wLwOJmYkTuuqV8n LEtg==
X-Gm-Message-State: AOAM531Ry5z5c1181K2AaAz6Hes8n6nexxg6UELU3n/AvFtIoQXmB/MG Zwa5kL/mSB5NFhm8naH53y1Njs7MzvBQ5AFZozgzq+TDIW79oA==
X-Google-Smtp-Source: ABdhPJy79p7G4W+k/b0ibr38kPGQQ1GXTZO1/fsYIIiDDn2TKV8oTuvCrWV1KWD+cngfLtBGpLgXmCk0BvUV6r2iPM4=
X-Received: by 2002:a05:6102:512:: with SMTP id l18mr13261088vsa.33.1620497132221; Sat, 08 May 2021 11:05:32 -0700 (PDT)
MIME-Version: 1.0
References: <161920206063.24889.14522893541582724606@ietfa.amsl.com>
In-Reply-To: <161920206063.24889.14522893541582724606@ietfa.amsl.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Sat, 8 May 2021 11:05:19 -0700
Message-ID: <CAL0qLwZA8fnDEDfh758PJK3=4x=N_wUNmKtcaNymd_3fmbX_RQ@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ecf7a605c1d5639d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/8gWKxn1sDSowa2D93sNdNCLVewk>
Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-02.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, 08 May 2021 18:05:40 -0000

On Fri, Apr 23, 2021 at 11:21 AM <internet-drafts@ietf.org> wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Domain-based Message Authentication,
> Reporting & Conformance WG of the IETF.
>
>         Title           : DMARC Aggregate Reporting
>         Author          : Alex Brotman
>         Filename        : draft-ietf-dmarc-aggregate-reporting-02.txt
>         Pages           : 23
>         Date            : 2021-04-23
>
> Abstract:
>    DMARC allows for domain holders to request aggregate reports from
>    receivers.  This report is an XML document, and contains extensible
>    elements that allow for other types of data to be specified later.
>    The aggregate reports can be submitted to the domain holder's
>    specified destination as supported by the receiver.
>
>    This document (along with others) obsoletes RFC7489.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/
> [...]
>

I've done only a cursory review so far.  (This is *not* an official AD
review; I'm just participating here.)

First, thanks for the work put into this.  It was clearly not a trivial
undertaking.

Two quick comments, with something more detailed to follow:

RFC2119 used to be all there was to BCP 14, but BCP 14 now includes RFC
8174, which changed the boilerplate you need to include if you want to use
MUSTard language in IETF documents.  Please update the references and
boilerplate accordingly.  You'll find it in RFC 8174 itself.

Second, a pet peeve of mine when reviewing documents across all areas (and
you can thank Pete Resnick for this part of my personality): There are many
"naked" SHOULDs in here.  By that, I mean: "SHOULD [NOT]" presents the
implementer with advice but also a choice; an implementation is technically
compliant if it doesn't do what the SHOULD [NOT] says.  It strengthens the
document to provide the reader with some guidance as to when one might make
the informed decision to choose not to follow that advice; or, perhaps more
importantly, the SHOULD [NOT] feels like it's dangling or unjustified
without such guidance.

For instance, the first SHOULD in this draft is this one:

A single report SHOULD contain data for one policy
   configuration.

Why might an implementer not do this?  If there's no good answer to
this question, maybe this ought to be a MUST or a MAY, not a SHOULD.

Sometimes the answer here is backward compatibility. Maybe you really
want this to be a MUST, but existing implementations didn't do it, so
to grandfather them in, you made it a SHOULD.
In such cases, I think you should either say this, or say something
like new implementations MUST do this, but acknowledge that legacy
implementations might not comply, and consumers need
to be prepared to deal with that.

Also worth considering: You can be normative without saying MUST.
Continuing with this example, you could just as easily say: "A single
report contains data for exactly one policy configuration."
That's normative without using any BCP 14 language.

-MSK