It appears that Brotman, Alex <[email protected]> said: >Hello folks, > >Ale has submitted a PR that (sort of) re-opens a previous PR. There wasn't a >consensus last time, so hoping we can have some >discussion on this one. > >https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-aggregate-reporting/pull/31 >https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-aggregate-reporting/pull/27 > >There was more language in the first PR. The first PR suggested that the >report generator create a report when the policy change was >detected. The second is a bit more terse, and changes the focus of the change. > >In 7489, we had: > > Aggregate reports are most useful when they all cover a common time > period. By contrast, correlation of these reports from multiple > generators when they cover incongruent time periods is difficult or > impossible. Report generators SHOULD, wherever possible, adhere to > hour boundaries for the reporting period they are using. For > example, starting a per-day report at 00:00; starting per-hour > reports at 00:00, 01:00, 02:00; etc. Report generators using a > 24-hour report period are strongly encouraged to begin that period at > 00:00 UTC, regardless of local timezone or time of report production, > in order to facilitate correlation. > >I could restore the language above (which I believe was John's suggestion).
People have been sending aggregate reports for over a decade, so anyone who receives reports has already figured out how to handle the way they arrive now. I don't expect anyone to change their sending schedules so let's just leave it alone. The suggestion to try and sync reports when the policy changes is completely impractical for many reasons even if it were useful, which I do not think it would be, so I hope that's off the table. R's, John _______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
