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

From: Alessandro Vesely <[email-masked]>
Date: Mon, 3 May 2021 19:55:22 +0200

Strange...

On Fri 23/Apr/2021 20:21:00 +0200 internet-drafts wrote:
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dmarc-aggregate-reporting-02

This arrives empty:

ale@pcale:~/tmp$ curl  https://tools.ietf.org/html/draft-ietf-dmarc-aggregate-reporting-02| wc
   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                  Dload  Upload   Total   Spent    Left  Speed
   0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
       0       0       0

> https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-aggregate-reporting-02

This looks like the traditional htmlized I-D that was missing in the previous link.

How come?

Best
Ale
--

---

From: "Brotman, Alex" <[email-masked]>
Date: Mon, 3 May 2021 18:48:34 +0000

I apologize, corporate mail gateway does that (I've asked them to exempt ietf.org now). The links have an expiration of a few days.

https://datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

> -----Original Message-----
> From: dmarc <[email-masked]> On Behalf Of Alessandro Vesely
> Sent: Monday, May 3, 2021 1:55 PM
> To: [email-masked]
> Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-02.txt
>
> Strange...
>
> > https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-dmarc-
> aggregate-reporting-02__;!!CQl3mcHX2A!VLHh-
> dyyGaHUPgaAFaPg3qsb8PlhOPrpMNkFUCu3qtCLqzx2JUZXysgpDqBD4n1FbKlO$
>
>
> This arrives empty:
>
> ale@pcale:~/tmp$ curl
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-dmarc-
> aggregate-reporting-02__;!!CQl3mcHX2A!VLHh-
> dyyGaHUPgaAFaPg3qsb8PlhOPrpMNkFUCu3qtCLqzx2JUZXysgpDqBD4n1FbKlO$
> | wc
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-
> dmarc-aggregate-reporting-02__;!!CQl3mcHX2A!VLHh-
> dyyGaHUPgaAFaPg3qsb8PlhOPrpMNkFUCu3qtCLqzx2JUZXysgpDqBD4t4SW-BT$
>
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!
> !CQl3mcHX2A!VLHh-
> dyyGaHUPgaAFaPg3qsb8PlhOPrpMNkFUCu3qtCLqzx2JUZXysgpDqBD4vAtUgBj$

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 3 May 2021 17:03:04 -0700

On Mon, May 3, 2021 at 11:49 AM Brotman, Alex <Alex_Brotman=
[email-masked]> wrote:

> I apologize, corporate mail gateway does that (I've asked them to exempt
> ietf.org now). The links have an expiration of a few days.
>

One of the URLs that came from the datatracker was:
https://tools.ietf.org/html/draft-ietf-dmarc-aggregate-reporting-02

It appears to return blank for me as well.

-MSK

---

From: "Brotman, Alex" <[email-masked]>
Date: Fri, 7 May 2021 14:48:36 +0000

I sent this over to support the other day, and it was forwarded to operations.

From: Murray S. Kucherawy <[email-masked]>
Sent: Monday, May 3, 2021 8:03 PM
To: Brotman, Alex <[email-masked]>
Cc: Alessandro Vesely <[email-masked]>; IETF DMARC WG <[email-masked]>
Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-02.txt

On Mon, May 3, 2021 at 11:49 AM Brotman, Alex <Alex_Brotman=[email-masked]<mailto:[email-masked]>> wrote:
I apologize, corporate mail gateway does that (I've asked them to exempt ietf.org<https://urldefense.com/v3/__http:/ietf.org__;!!CQl3mcHX2A!VV5FMHzQ9IRbWwvLWi6noKzvhvvOVr5GK-OmVlF7Blvv8D0DEjx3PyHIAjwg6Y97QeLs$> now). The links have an expiration of a few days.

https://datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/__;!!CQl3mcHX2A!VV5FMHzQ9IRbWwvLWi6noKzvhvvOVr5GK-OmVlF7Blvv8D0DEjx3PyHIAjwg6bqFdLuE$>

One of the URLs that came from the datatracker was:
https://tools.ietf.org/html/draft-ietf-dmarc-aggregate-reporting-02<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-dmarc-aggregate-reporting-02__;!!CQl3mcHX2A!VV5FMHzQ9IRbWwvLWi6noKzvhvvOVr5GK-OmVlF7Blvv8D0DEjx3PyHIAjwg6Ys_rsaT$>

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 7 May 2021 12:04:45 -0700

I think it's an IETF tools problem.  The URL is theirs, not yours.

On Fri, May 7, 2021 at 7:48 AM Brotman, Alex <[email-masked]>
wrote:

> *From:* Murray S. Kucherawy <[email-masked]>
> *Sent:* Monday, May 3, 2021 8:03 PM
> *To:* Brotman, Alex <[email-masked]>
> *Cc:* Alessandro Vesely <[email-masked]>; IETF DMARC WG <[email-masked]>
> *Subject:* Re: [dmarc-ietf] I-D Action:
> draft-ietf-dmarc-aggregate-reporting-02.txt
>
>
>
> ietf.org
> <https://urldefense.com/v3/__http:/ietf.org__;!!CQl3mcHX2A!VV5FMHzQ9IRbWwvLWi6noKzvhvvOVr5GK-OmVlF7Blvv8D0DEjx3PyHIAjwg6Y97QeLs$>
> now). The links have an expiration of a few days.
>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/__;!!CQl3mcHX2A!VV5FMHzQ9IRbWwvLWi6noKzvhvvOVr5GK-OmVlF7Blvv8D0DEjx3PyHIAjwg6bqFdLuE$>
>
>
>
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-dmarc-aggregate-reporting-02__;!!CQl3mcHX2A!VV5FMHzQ9IRbWwvLWi6noKzvhvvOVr5GK-OmVlF7Blvv8D0DEjx3PyHIAjwg6Ys_rsaT$>
>
>
>

---

From: "John Levine" <[email-masked]>
Date: 7 May 2021 16:25:52 -0400

It appears that Murray S. Kucherawy  <[email-masked]> said:
>-=-=-=-=-=-

tools.ietf.org is running on fumes and will be going away.  The
htmlized version of the draft on the datatracker works:

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 7 May 2021 14:45:34 -0700

> https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-aggregate-reporting-02

Yeah, but it also means the tools team should probably arrange that
announcements of new I-Ds don't use the dead URLs.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Fri, 7 May 2021 15:29:48 -0700

> announcements of new I-Ds don't use the dead URLs.

where's the fun in that?

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
[email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 8 May 2021 11:05:19 -0700

On Fri, Apr 23, 2021 at 11:21 AM <[email-masked]> 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:
> [...]

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