Subject: [apps-discuss] Gen-ART and OPS-Dir review of draft-ietf-appsawg-nullmx-08

From: "Black, David" <[email-masked]>
Date: Tue, 12 Aug 2014 16:29:37 -0400

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-08
Reviewer: David L. Black
Review Date: August 12, 2014
IETF LC End Date: August 25, 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.

Good news: The one remaining nit from the Gen-ART review of the -05
version has been corrected in the -08 version.

Bad news: idnits 2.13.00 noted the added downref to RFC 1846, for which
the draft is now in a second IETF Last Call.  A draft has just been
submitted to replace RFC 1846 (Experimental) with a Standards Track RFC:

	https://datatracker.ietf.org/doc/draft-klensin-rfc1846bis/

The IESG should decide whether to proceed with the downref to RFC 1846bis
vs. publish the 1846bis draft as a standards track RFC and reference it.
That decision is the open issue in this review of the nullmx draft.

>From an operational perspective, the added SMTP status codes for null MX
errors (one of which is the cause of the downref) are an improvement, in
that they enable more precise reporting of the reason for email not being
delivered.

Thanks,
--David

> -----Original Message-----
> From: Black, David
> Sent: Friday, July 25, 2014 10:46 AM
> To: [email-masked]; [email-masked]; General Area Review Team (gen-
> [email-masked]); [email-masked]
> Cc: [email-masked]; [email-masked]; Black, David
> Subject: Gen-ART and OPS-Dir review of draft-ietf-appsawg-nullmx-06
> 
> 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: [email-masked]; [email-masked]; General Area Review Team (gen-
> > [email-masked]); [email-masked]
> > Cc: [email-masked]; [email-masked]; 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
> > [email-masked]        Mobile: +1 (978) 394-7754
> > ----------------------------------------------------

---

From: Barry Leiba <[email-masked]>
Date: Fri, 15 Aug 2014 14:06:14 -0400

Thanks, David, for the re-review.

> A draft has just been

Right, and the decision has already been made, which is why the second
last-call notice says that the document has been "tentatively
approved":
The plan is to put the nullmx draft into the RFC Editor queue.  If we
can do the 1846bis processing quickly, so that when AUTH48 comes for
nullmx we see 1846bis as being essentially done, we will hold nullmx,
process the two documents together, and change the reference.  But if
it looks like 1846bis is getting hung up, we will proceed with
publication of nullmx with the downref.

That plan was discussed on the apps-discuss list a couple of weeks ago.

Barry