Last Call Review of draft-ietf-regext-epp-eai-10
review-ietf-regext-epp-eai-10-genart-lc-resnick-2022-06-01-00

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]"