Last Call Review of draft-ietf-appsawg-nullmx-06
review-ietf-appsawg-nullmx-06-genart-lc-black-2014-07-31-00

The -06 version of this draft addresses the topics raised in the Gen-ART
review of the -05 version, except that Section 1 is still missing from
the Table of Contents (possible xml2rfc problem?).

Summary: Ready with nits. 

Thanks,
--David


> -----Original Message-----
> From: Black, David
> Sent: Thursday, July 17, 2014 12:39 AM
> To: standards at taugh.com; mx0dot at yahoo.com; General Area Review Team (gen-
> art at ietf.org); ops-dir at ietf.org
> Cc: apps-discuss at ietf.org; ietf at ietf.org; Black, David
> Subject: Gen-ART and OPS-Dir review of draft-ietf-appsawg-nullmx-05
> 
> 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
> ----------------------------------------------------