[Last-Call] Artart telechat review of draft-ietf-dmarc-aggregate-reporting-26

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux