Skip to main content

Last Call Review of draft-ietf-dmarc-interoperability-14
review-ietf-dmarc-interoperability-14-secdir-lc-turner-2016-06-17-00

Request Review of draft-ietf-dmarc-interoperability
Requested revision No specific revision (document currently at 18)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2016-06-14
Requested 2016-05-26
Authors Franck Martin , Eliot Lear , Tim Draegen , Elizabeth Zwicky , Kurt Andersen
I-D last updated 2016-06-17
Completed reviews Genart Last Call review of -14 by Peter E. Yee (diff)
Genart Telechat review of -16 by Peter E. Yee (diff)
Secdir Last Call review of -14 by Sean Turner (diff)
Assignment Reviewer Sean Turner
State Completed
Request Last Call review on draft-ietf-dmarc-interoperability by Security Area Directorate Assigned
Reviewed revision 14 (document currently at 18)
Result Ready
Completed 2016-06-17
review-ietf-dmarc-interoperability-14-secdir-lc-turner-2016-06-17-00
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. 
Document editors and WG chairs should treat these comments just like any other
last call comments.

This informational draft describes interoperability issues between DMARC and
indirect email flows as well as possible methods for addressing these
interoperability issues.  Indirect email flows are messages that do not flow
directly from the author's administrative domain to the final recipient(s).

Summary: I think it’s ready, but just wanted to check on one thing.  The
difference between the following sentences in s1 and s4:

s1:  Note that some practices which are in use at the time of this document may
or may not be "best practices", especially as future standards evolve.

s4: Note that these particular mechanisms may not be considered "best
practices" and may, in some cases, violate various conventions or expectations.

made me wonder whether the two identified sections in the security
considerations are the only sections that contain text that "violates various
conventions or exceptions".  I don’t want wanting to grind the security axe on
eMail, DKIM, SPF only on what’s changed.

Ramblings follow:

Rave:

Appreciate that this wasn’t trying to be passed off as a BCP and that there’s
no 2119-language.

Appreciate your examples using TLS1.2 and at-this-time-known-to-be-good
algorithms.

Rant:

s1 2nd para could probably be deleted.  It sounds a lot like marketing to me :)

Nits:

I found some.  Peter found way more so look for his GenArt review.

spt