Last Call Review of draft-ietf-appsawg-mdn-3798bis-15
review-ietf-appsawg-mdn-3798bis-15-secdir-lc-eastlake-2016-12-01-00

My apologies for getting this in late. I have reviewed this document as
part of the security directorate's ongoing effort to review all IETF
documents being processed by the IESG. Document editors and WG chairs
should treat these comments just like any other last call comments.

This draft appears to be ready for publication with some nits..

This draft polishes and advances to Internet Standard level RFC 3798 on
Message Disposition Notifications.

*Security Considerations:*

The Security Considerations seem good except for one minor point: in my
opinion the option to return all or a portion of the original message
significantly increases the possible risk of use MDNs as a traffic
multiplier. I believe this should be mentioned in Section 6.4.

*Miscellaneous:*

The style of this draft is to say that you MUST do this and MUST NOT do
that without indicating what action should be taken if this is violated.
This is like saying a protocol field "MUST be zero" without adding the
usual "and is ignored on receipt". For example, in Section 3 it says that a
message disposition notification MUST NOT itself request an MDN. I believe
it should go on and add the few words to say: "If one does, this is
ignored." (unless that's wrong...) I'm not saying this must always be done
but there may be 1 or 2 other cases like this in the draft where such
wording should be added.

*Wording:*

In Section 3, the wording of the last sentence of point d seems just a bit
obscure. It says

       However, in the case of encrypted messages requesting MDNs,
       encrypted message text MUST be returned, if it is returned at
       all, only in its original encrypted form.

I think it would be a just bit clearer as

       However, in the case of encrypted messages requesting MDNs, if

       the original message or a portion thereof is returned, it MUST

       be in its original encrypted form.


*Trivia:*

I do wonder if the references to X.400 mail are necessary. They seem
archaic. Does anyone run X.400 email any more? It is just used as an
example, along with proprietary mail systems. I think such proprietary
systems still exist, but X.400 mail? I'm not so sure. If it is going to be
retained, maybe there should be an Informational reference for it.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com