We had just removed that paragraph. Correct, the core document had removed the "ri". We had a short thread about it here, and I removed the piece you're proposing below. Without "ri" being specified, it's up to the report generator. We can tell them "0000UTC, 24hr period", but what if they don't? 1hr? 1m? Should a report receiver discard reports with a frequency less than one day? What if the report generator has decided that they want to operate on a volume-based threshold before generating a report?
I can put the paragraph back (it was there in version -22 I believe), but there should be some consensus if we're going to try to dictate the intervals, and what to do if we find a report sender is outside of that normative language. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > -----Original Message----- > From: Daniel K. <[email protected]> > Sent: Thursday, November 28, 2024 1:06 PM > To: [email protected] > Subject: [dmarc-ietf] Reporting Period is undefined > > The "ri" tag was removed, and as a result the default interval, or reporting > period > is no longer mentioned any place. > > aggregate-reporting has a lot to say about "Changes in Policy During Reporting > Period" but the length of such a period is not defined. > > I think it should be written in aggregate-reporting that the reporting > interval > SHOULD be daily, and that the reporting period SHOULD start at midnight UTC, > lasting until 23:59:59 UTC. > > I do not know the cases when the SHOULD should be disregarded, but I know I've > received data for a lot of strange looking intervals. > > > Daniel K. > > _______________________________________________ > dmarc mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
