Based on your changes, I now understand the word remaining to refer to URIs that are not malformed.
If that's correct, then I'm fine with these proposed changes. OS On Mon, Mar 3, 2025, 2:29 PM Brotman, Alex <[email protected]> wrote: > Ah, I see. > > > > The Mail Receiver, after preparing a report, **MUST** evaluate the > > provided reporting URIs (See [@!I-D.ietf-dmarc-dmarcbis]) in the order > > given. If any of the URIs are malformed, they SHOULD be ignored. An > > attempt **MUST** be made to deliver an aggregate report to > > every remaining URI, up to the Receiver's limits on supported URIs. > > > > Is that better? I made that a SHOULD as I’ve been told there are some > flexible reporting systems that ignore some versions of “malformed”. > > > > -- > > Alex Brotman > > Sr. Engineer, Anti-Abuse & Messaging Policy > > Comcast > > > > *From:* Orie <[email protected]> > *Sent:* Monday, March 3, 2025 2:07 PM > *To:* Brotman, Alex <[email protected]> > *Cc:* The IESG <[email protected]>; > [email protected]; [email protected]; > [email protected]; [email protected] > *Subject:* [EXTERNAL] Re: Orie Steele's No Objection on > draft-ietf-dmarc-aggregate-reporting-29: (with COMMENT) > > > > My point is that I don't understand what "remaining" means in Section 3. 5. > https: //author-tools. ietf. > org/iddiff?url1=draft-ietf-dmarc-aggregate-reporting-28&url2=draft-ietf-dmarc-aggregate-reporting-29&difftype=--hwdiff > > My point is that I don't understand what "remaining" means in Section 3.5. > > > https://author-tools.ietf.org/iddiff?url1=draft-ietf-dmarc-aggregate-reporting-28&url2=draft-ietf-dmarc-aggregate-reporting-29&difftype=--hwdiff > <https://urldefense.com/v3/__https:/author-tools.ietf.org/iddiff?url1=draft-ietf-dmarc-aggregate-reporting-28&url2=draft-ietf-dmarc-aggregate-reporting-29&difftype=--hwdiff__;!!CQl3mcHX2A!FEyIa2sdZXNQHYWbkoTEs6Sw0G6iNqX100H5bWU8k8BkexuN1htHlkAGBefl93LRdBk5hR2WnAG7HNSDaQ$> > > ``` > > The Mail Receiver, after preparing a report, MUST evaluate the > > provided reporting URIs (See [I-D.ietf-dmarc-dmarcbis]) in the order > > given. > > ... > > An attempt MUST be made to deliver an aggregate report to > > every remaining URI, up to the Receiver's limits on supported URIs. > > ``` > > > > > > > > > > > > > > On Mon, Mar 3, 2025 at 12:45 PM Brotman, Alex <[email protected]> > wrote: > > I'm not sure I understand your comment below. Are you commenting on the " > up to the Receiver's limits on supported URIs" ? That suggests that a > message receiver (report generator, not report receiver) may have a limit > on the number of URIs they're willing to send reports to. If that's your > nit, I can make that more clear. > > -- > Alex Brotman > Sr. Engineer, Anti-Abuse & Messaging Policy > Comcast > > > > -----Original Message----- > > From: Orie Steele via Datatracker <[email protected]> > > Sent: Friday, February 28, 2025 9:46 AM > > To: The IESG <[email protected]> > > Cc: [email protected]; [email protected] > ; > > [email protected]; [email protected]; [email protected] > > Subject: Orie Steele's No Objection on > draft-ietf-dmarc-aggregate-reporting- > > 29: (with COMMENT) > > > > Orie Steele has entered the following ballot position for > > draft-ietf-dmarc-aggregate-reporting-29: 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/state > <https://urldefense.com/v3/__https:/www.ietf.org/about/groups/iesg/state> > > ments/handling-ballot- > > positions/__;!!CQl3mcHX2A!BuRISkuxX4W9qRx2GroqLwMI0nyMJzcXyAQnH > > y3LhLzNiTnk6hqDlEiCFKmWWUf7UYdUVhZWDzITjSZ1E_I$ > > for more information about how to handle DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf- > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-> > > dmarc-aggregate- > > reporting/__;!!CQl3mcHX2A!BuRISkuxX4W9qRx2GroqLwMI0nyMJzcXyAQnH > > y3LhLzNiTnk6hqDlEiCFKmWWUf7UYdUVhZWDzITA-64-NQ$ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thanks for addressing my comments in -29. > > > > ### Nits > > > > In -29, the word remaining here is perhaps no longer needed: > > > > ``` > > An attempt MUST be made to deliver an aggregate report to > > every remaining URI, up to the Receiver's limits on supported URIs. > > ``` > > > > I think the intended behavior with the changes from -29 is to attempt to > > deliver to all URIs. > > > > > >
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
