Skip to main content

Last Call Review of draft-klensin-smtp-521code-05
review-klensin-smtp-521code-05-opsdir-lc-woolf-2015-04-09-00

Request Review of draft-klensin-smtp-521code
Requested revision No specific revision (document currently at 07)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2015-04-07
Requested 2015-03-11
Authors Dr. John C. Klensin
I-D last updated 2015-04-09
Completed reviews Genart Last Call review of -05 by Joel M. Halpern (diff)
Opsdir Last Call review of -05 by Suzanne Woolf (diff)
Assignment Reviewer Suzanne Woolf
State Completed
Request Last Call review on draft-klensin-smtp-521code by Ops Directorate Assigned
Reviewed revision 05 (document currently at 07)
Result Has nits
Completed 2015-04-09
review-klensin-smtp-521code-05-opsdir-lc-woolf-2015-04-09-00
Hi,

As the boilerplate sez….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 with the intent of
improving the operational aspects of the IETF drafts. Comments that are not
addressed in last call may be included in AD reviews during the IESG review. 
Document editors and WG chairs should treat these comments just like any other
last call comments.

(With apologies to the author and my ADs that it's late; I read the draft and
then spaced actually shipping the review after Dallas.)

This is ready to go, with some editorial nits (below).

The IETF Last Call had a few comments, mostly on a specific clarification; they
were supportive of publication. There is a fairly lengthy and substantial
comment from Murray Kucherawy that it appears John agreed to incorporate in the
next rev, explaining a little more closely the relationship between what this
draft suggests and RFC 5321 regarding dropped connections. I thought Murray's
explanation of his suggestion was compelling enough that I'd like to see the
change incorporated.

(I was also surprised that "This document updates RFC 5321 to add descriptions
and text for two reply codes, but there is no registry for those codes." The
workaround looks OK to me from an operational perspective but I'm not an SMTP
implementer.)

This document is a useful update to the standard to support some elements of
current practice and at least one expected separate update also reflecting
practice in the field (nullMX).

Nits:

Sec. 3:

"It SHOULD
   NOT be used for situations in which the server rejects mail from
   particular hosts or addresses or in which mail for a particular
   destination host is not accepted;."

might be clearer as "….hosts or addresses, or situations in which mail for a
particular destination host is not accepted."

The next sentence:

"As discussed in SMTP, reply code
   554 is more appropriate for most of those conditions; an additional
   case, in which the determination that mail is not accepted is
   determined outside the mail system, is covered in the next section
   (Section 4)."

might be clearer as "…more appropriate for most of those conditions. An
additional case, in which the determination that mail is not accepted is made
outside the mail system, is covered…."

Best,
Suzanne