[dmarc-ietf] Extensions in Aggregate Reporting - Feedback Requested

["Brotman, Alex" <[e-mail]>]

Hello folks,

During our interim call last week the topic of extensions within the DMARC aggregate report came up.  There was a discussion about how to best introduce these, but also how they might be best used.  I noted three cases that I could see today; ARC, PSD, and BIMI.   And indeed we have tickets relating to the first two.  The original thought was that the aggregate draft would allow a place for extensions, and then additional drafts would define those within the IETF.  When -02 was originally being worked on, there was a thread about how we might like to see this, though not many responses.  The result is in section 4 of the -02 draft [1]. and I thought we'd enhance that as we progressed.  At the time, I didn't intend to limit the extensions to IETF-approved extensions, though wasn't sure how else this might be used by reporting entities (I mentioned domain reputation-ish things during the call).  I'd consider that if we don't enforce IETF-registered extensions, the receivers could still ignore extensions they don't want to handle.  I'm also aware this could bloat a report in terms of size, though we've already indicated we don't seem overly concerned with the size of the XML body.  A few things I'd like to see the group reach consensus on are:

1) Extensions in their own section (as it is now) or within each <row> element
2) Must extensions be IETF-approved
3) If (2) is true, do we want to define any during the DMARCbis process (essentially a demonstration of how it is to be done)

Thank you for your continued feedback

1: https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-aggregate-reporting-02#section-4

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