Last Call Review of draft-ietf-uta-email-deep-09
review-ietf-uta-email-deep-09-opsdir-lc-pignataro-2017-10-16-00

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.

Please find some review comments for your consideration, which I hope you find
useful and clear.

Ready with Nits (or Minor Issues)

In general, this document seems to adequately cover the Operational areas
listed in Appendix A of RFC 5706. Deployment, coexistence, migration, and
defaults covered. One area that perhaps deserves more explicit mention of fault
and error condition reporting and notification. Attributes such as indications
to a user are useful tools in the context of this operational review.

Minor Issues and Nits:

I was fairly confused, which could be just an issue on my end, about the use of
 lower and uppercase derivations of the word "recommend". For example, is this
in the Intro non-normative? "In brief, this memo now recommends that:". There
is a total of 17 instances of "recommend" and two of "RECOMMEND".

Idnits complains about:
https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-uta-email-deep-09.txt

   The specific means employed for deprecation of cleartext Mail Access
   Services and Mail Submission Services MAY vary from one MSP to the
   next in light of their user communities' needs and constraints.

Does this MAY denote a requirement, or a statement of fact?

   Also, users previously authenticating with passwords sent as
   cleartext SHOULD be required to change those passwords when migrating
   to TLS, since the old passwords were likely to have been compromised.

How does the editor quantify the likelihood or otherwise extrapolates on
passwords being compromised?

   All DNS records advertised by an MSP as a means of aiding clients in
   communicating with the MSP's servers, SHOULD be signed using DNSSEC.

As struggle a bit with finding this recommendation within scope, as set up in
the Abstract of the document.

   o  MUAs SHOULD be configurable to require a minimum level of
      confidentiality for any particular Mail Account, and refuse to
      exchange information via any service associated with that Mail
      Account if the session does not provide that minimum level of
      confidentiality.  (See Section 5.2.)

Can this refusal to exchange information cause a user-experience black-hole? In
other words, are there requirements for UI and logging of error conditions here?

   o  MUAs SHOULD provide a prominent visual indication of the level of
      confidentiality associated with an account configuration (for
      example, indications such as "lock" icons or changed background
      colors similar to those used by some browsers), at appropriate
      times and locations in order to inform the user of the
      confidentiality of the communications associated with that
      account.

Why are "visual" indications only required? And why color-based indication
levels are exemplified only? These do not seem friendly to color-blind people,
and not useful for visually impaired users, or interfaces that prioritize other
channels. I'd generalize this, and exemplify with icons or colors or...

I hope you find these useful.

Thank you,

-- Carlos Pignataro.