Last Call Review of draft-ietf-appsawg-nullmx-05
review-ietf-appsawg-nullmx-05-opsdir-lc-black-2014-07-21-00

This is a combined Gen-ART and OPS-DIR review.
Boilerplate for both follows ...

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at:

<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These comments 
were written primarily for the benefit of the operational area directors.  
Document editors and WG chairs should treat these comments just like any other 
last call comments.

Document: draft-ietf-appsawg-nullmx-05
Reviewer: David L. Black
Review Date: July 16, 2014
IETF LC End Date: July 17, 2014
IESG Telechat Date: August 7, 2014

Summary: This draft is on the right track, but has open issues
		described in the review.

This draft is a short specification of a NULL MX resource record whose
publication in the DNS indicates that a domain does not accept email.

I found one relatively minor issue.

Minor Issues:

Something is wrong with this paragraph in the Security Considerations section:

   In the unlikely event that a domain legitimately sends email but does
   not want to receive email, SMTP servers that reject mail from domains
   that advertise a NULL MX risk losing email from those domains.  The
   normal way to send mail for which a sender wants no responses remains
   unchanged, by using an empty RFC5321.MailFrom address.

Why is that treated as a security consideration?  In light of the first
paragraph in Section 4.3 stating that it's acceptable for SMTP clients to
not send email to domains that publish NULL MX records, this text ought to
be recommending that such a domain (legitimately sends email but does not
want to receive email) SHOULD NOT publish a NULL MX record and SHOULD provide
an SMTP server that promptly rejects all email delivery attempt.  It can
then further explain that not following the "SHOULD NOT" causes lost email
as described in the quoted text, and not following the "SHOULD" causes long
delivery timeouts as described in Section 2.  I'd also suggest moving this
discussion to Section 4.3 so that it follows the first paragraph there.

Nits:

Section 1 is missing from Table of Contents.

First paragraph in Section 4.1:
	"address is not deliverable" -> "the email is not deliverable"

Second  paragraph in Section 4.1 assumes that all or most domains that
do not accept email also publish NULL MX records.  That assumption should
be stated as part of the first sentence of the paragraph, as the immediately
preceding paragraph is about the benefits of individual domains publishing
NULL MX records.

In Section 4.3, please provide text descriptions of the 550 reply code and
5.1.2 enhanced status code.

OLD 
   550 reply code
NEW
   550 reply code (Requested action not taken: mailbox unavailable) [RFC5321]

OLD
   5.1.2 enhanced status code
NEW
   5.1.2 enhanced status code (Permanent Failure, Bad destination system address)

idnits 2.13.01 didn't find anything to complain about.

--- Selected RFC 5706 Appendix A Q&A for OPS-Dir review ---

A.1.1  Has deployment been discussed?

	Yes, and NULL MX records are already deployed in the DNS.

A.1.5.  Has the impact on network operation been discussed?

	Yes, in general, NULL MX records have significant operational
	benefits as described in the draft.

A.2.  Do you anticipate any manageability issues with the specification?

	No.  This is a minor extension to an existing use of DNS resource records.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
david.black at emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------