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@xxxxxxxxx; mx0dot@xxxxxxxxx; General Area Review Team (gen- > art@xxxxxxxx); ops-dir@xxxxxxxx > Cc: apps-discuss@xxxxxxxx; ietf@xxxxxxxx; 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@xxxxxxx Mobile: +1 (978) 394-7754 > ----------------------------------------------------