[dmarc-ietf] Roman Danyliw's No Objection on draft-ietf-dmarc-eaiauth-05: (with COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

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.