Ben Campbell has entered the following ballot position for draft-ietf-uta-mta-sts-17: 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-mta-sts/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm balloting "Yes" because I want to see this work published. But I have a few concerns: §3 seems to leave much of the interpretation of the TXT record as "implication". It should be explicit. I'd like to see the specific steps the sender is supposed to follow (perhaps the flow in §5.1 could be expanded to include the TXT query and interpretation? For example, the idea that a non-existent record means no MTA-STS support is sort of buried in the description of multiple text records. Would it be reasonable to say that the sender SHOULD NOT query for policy if the id hasn't changed since a previous query? §3.3: - "When fetching a new policy or updating a policy, the HTTPS endpoint MUST present a X.509 certificate which is valid for the "mta-sts" I find this confusing. Which endpoint is doing the fetching? Which one MUST present the cert. Are we talking about this in the context of TLS or something else? - Why is checking for certificate revocation only a MAY? - Does the term "sender" refer to the SMTP sender, or something else? §4.1: Why is checking for certificate revocation only a MAY? _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
