Thanks, Scott! To me (as an individual) this seems ready for last call.
A few items: 1. In the new paragraph in section 1 clarifying requirements, you have an open parens that is never closed. 2. In Section 3.5, I'm concerned with the normative MUST NOT. This would mean .example couldn't receive failure reports the way example.com does. For something like .bank or .com, this is a feature. But for a .google, this is a bug. I really think this MUST NOT is, while well advised, delving into policy and not interop. I really think the guidance in 4.1 is the best way to approach this. Speaking of which, with the normative MUST NOT that's been added, now 4.1 no longer makes any sense. My recommendation would be to roll this change back, and perhaps replace it with a reference to 4.1 and a "if you're a PSD, don't ask for RUF unless you really really know what you're doing." 3. psddmarc.org - I think we need a brief paragraph outlining the experiment, and in it need to explicitly call out that a permanent solution needs to be determined for answering the "what's a PSD" question - which may or may not be psddmarc.org. Thanks again! Seth On Tue, May 7, 2019 at 7:16 PM Scott Kitterman <[email protected]> wrote: > On Tuesday, May 7, 2019 10:10:51 PM EDT [email protected] wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. This draft is a work item of the Domain-based Message > > Authentication, Reporting & Conformance WG of the IETF. > > > > Title : DMARC (Domain-based Message Authentication, > > Reporting, and Conformance) Extension For PSDs (Public Suffix Domains) > > Author : Scott Kitterman > > Filename : draft-ietf-dmarc-psd-03.txt > > Pages : 11 > > Date : 2019-05-07 > > Significant changes from -02: > > Based on offline feedback: > > Added a paragraph on PSD exact domain match issues. > Added a clear MUST NOT for [RFC7489] Section 7.3 Failure Reports > > Finished Appendices: > > Added more text to Appendix B about support for the experiment available > from > psddmarc.org. > Added Appendix C to track implementations. > > If anyone else has an implementation that's not listed, please let me know > and > I'll add it. > > Other than that, I think it's about done. > > Scott K > > > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
