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. _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
