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 <noreply@xxxxxxxx> >> Sent: Tuesday, January 28, 2025 8:45 PM >> To: art@xxxxxxxx >> Cc: dmarc@xxxxxxxx; draft-ietf-dmarc-aggregate-reporting.all@xxxxxxxx; last- >> call@xxxxxxxx >> 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. >> -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
