Don't sweat it. None of these issues are blocking. Given how well you managed the last round, I'm inclined to trust your judgment. I'll assume that you will make the right choice. Take your time and I'll do that I can to help if you need it.
On Thu, Jan 30, 2025, at 08:07, Brotman, Alex wrote: > Martin, > > I've been in all-day meetings the past two days, but didn't want you to > think I was ignoring you. I'll respond more appropriately in the next > few days. Apologies > > -- > Alex Brotman > Sr. Engineer, Anti-Abuse & Messaging Policy > Comcast > > >> -----Original Message----- >> From: Martin Thomson via Datatracker <[email protected]> >> Sent: Tuesday, January 28, 2025 8:45 PM >> To: [email protected] >> Cc: [email protected]; [email protected]; last- >> [email protected] >> Subject: Artart telechat review of draft-ietf-dmarc-aggregate-reporting-26 >> >> Reviewer: Martin Thomson >> Review result: Ready with Nits >> >> Thanks for the new sections describing the format. I found them very >> helpful. >> I don't know what your alternatives look like, but I found this quite >> comprehensible. >> >> > S2.5 says "the Mail Receiver MAY send a short report indicating that a >> > report is available but could not be sent" - how? >> >> This issue remains. The text is expanded, but it still includes "the URI >> refers to a >> service that is unreachable". A short report won't get there any better >> than a >> fully one. I get size limits, but not that part. Consider rephrasing. >> >> > It's not clear to me that the strict rules regarding the construction >> > of >> filenames and subjects is justified, especially when the report contains the >> same >> information. >> >> We discussed this and it seems to overly proscribe behaviour, beyond what >> interop calls for. ¯\_(ツ)_/¯ >> >> > S3 defines a validation process that involves querying DNS at >> > "<provider >> > name>._report._dmarc.<target name>". This will fail when this string >> > name>is too >> > long [...] >> >> Discussed and I'm satisfied with the response. However, it is definitely >> worth >> noting that owners of long domains will need to find owners of short domains >> to >> outsource to, or do it for themselves. >> >> > The schema [...] >> >> NEW: I completely missed that this replaces RFC 7489. It's mentioned only >> in the >> document header and acknowledgments. Please add notes to the abstract and >> consider including a section that explains the differences. >> _______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
