Roman Danyliw has entered the following ballot position for draft-ietf-dmarc-eaiauth-05: No Objection
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-dmarc-eaiauth/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the clarifications this draft provides to deployed technologies. A few comments: (1) Support Ben’s first DISCUSS asking questions about macro expansion (2) A process question – are there any issues with a IETF stream proposed standard draft (this draft) updating an ISE stream published document (RFC7489)? (3) Section 3, Please expand “EAI” on first use. It isn’t in the RFC Editor Abbreviations List -- https://www.rfc-editor.org/materials/abbrev.expansion.txt (4) Section 4 says, “Since the EHLO command precedes the server response that tells whether the server supports the SMTPUTF8 extension , an IDN argument MUST be represented as an A-label.” Is the “IDN argument” in question the hostname used in the EHLO? If this is the only argument, I would recommend explicitly saying s/an IDN argument/an IDN hostname used in EHLO/). (5) Section 6, Recommend making the reference clearer by s/described in section 7/described in section 7.1 of [RFC7208]/ (6) Section 5, Recommend making the reference clearer by s/When computing or verifying the hash in a DKIM signature as described in section 3.7/ When computing or verifying the hash in a DKIM signature as described in section 3.7 [RFC6376]/ (7) Section 6, Recommend making the reference clearer by s/Section 6.6.1 specifies/Section 6.6.1 of [RFC7489]/ s/Sections 6.7 and 7.1/Sections 6.7 and 7.1 of [RFC7489]/ (8) Section 6 says “Section 6.6.1 specifies, somewhat imprecisely”. What does the “somewhat” mean? I recommend more precision in describing the ambiguity left by RFC7489 or dropping that word. (9) Section 8. Recommend making more specific statements about the Security Considerations: s/This document attempts to slightly mitigate some of them but does not, as far as the author knows, add any new ones. / This document provides clarifications to existing protocols to improve their handling of internationalized email./ Recommend adding something as follows as the last sentence: “It introduces no additional security considerations beyond those already identified in the base specifications of [RFC7208], [RFC6376] and [RFC7489].” – pending resolution of Ben’s first DISCUSS. _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
