Subject: [Uta] Adam Roach's Yes on draft-ietf-uta-email-deep-09: (with COMMENT)
From: Adam Roach <[email-masked]>
To: "The IESG" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Date: Mon, 23 Oct 2017 20:45:05 -0700
List-Id: UTA working group mailing list <uta.ietf.org>

Adam Roach has entered the following ballot position for
draft-ietf-uta-email-deep-09: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-uta-email-deep/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Balloting "Yes" because I think this is a very welcome and important update to
its antecedent documents -- but I think there are a few simple changes needed
before it's ready to go.

Most importantly; section 3.2 contains the following text:

   Clients MUST
   implement the certificate validation mechanism described in [RFC3501]
   and SHOULD implement the certificate validation mechanism described
   in [RFC7817].

I'm not sure this is kosher. The relevant portion of RFC3501 has been removed
by RFC7817 and replaced by the procedures from RFC7817. My understanding is
saying that you MUST implement RFC3501 for validation implies that you MUST
implement RFC7817 for validation, since RFC3501 has been formally updated.
Putting them at different normative levels in this document doesn't make sense.

____

Section 4.3 says what the "value included in this additional clause SHOULD be"
but doesn't indicate that the clause itself SHOULD be included. I assume this
is an oversight?

Sections 4.5 and 4.5.1 use the word "recommended" in a non-normative fashion
(correctly, I believe). For avoidance of doubt, I recommend replacing the
RFC2119 boilerplate with the newer RFC8174 boilerplate.

Section 4.5.3 normatively specifies the use of DNSSEC, which makes some or all
of RFCs 4033-4035 normative references, I believe.

Section 4.5.4 normatively specifies the use of TLSA, which makes RFC6698 a
normative reference, I believe.