Reviewer: Pete Resnick Review result: On the Right Track I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-regext-epp-eai-10 Reviewer: Pete Resnick Review Date: 2022-06-01 IETF LC End Date: 2022-06-09 IESG Telechat date: Not scheduled for a telechat Summary: I think this proposal is reasonable, but I don't think enough explanation has been given regarding the case where one side supports the protocol but the other side doesn't. Major issues: The last bullet item in section 5.3.2 talks about "alternative ASCII address", but I don't see anywhere in the document which defines how to provide an alternative ASCII address in the data. For example, RFC 5733 implies that there will be only one email address in the Contact Mapping; can an implementation simply add a second? Does the server then need to distinguish these by the presence or absence of non-ASCII characters to determine which is an EAI and which is an alternative ASCII address? At the very least, some discussion of this seems necessary in the document. Minor issues: In the bullets in section 5.3.2, there are quite a few SHOULDs with no explanation of why one might choose to violate these. Why are these not MUSTs? I can't think of any reason, for example, that the server would not validate the email property, and it seems like a really bad idea not to. Nits/editorial comments: Abstract: Strike the word "appearing" Section 3: Change "By applying the syntax rules of [RFC5322]" to "By applying the syntax rules of [RFC6532]" -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
