Skip to main content

Last Call Review of draft-ietf-regext-epp-eai-10

Request Review of draft-ietf-regext-epp-eai
Requested revision No specific revision (document currently at 20)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2022-06-09
Requested 2022-05-26
Authors Dmitry Belyavsky , James Gould
I-D last updated 2022-06-01
Completed reviews I18ndir Early review of -15 by Yoshiro Yoneya (diff)
Genart Last Call review of -10 by Pete Resnick (diff)
Artart Last Call review of -12 by Takahiro Nemoto (diff)
Secdir Last Call review of -12 by Chris M. Lonvick (diff)
Assignment Reviewer Pete Resnick
State Completed
Request Last Call review on draft-ietf-regext-epp-eai by General Area Review Team (Gen-ART) Assigned
Posted at
Reviewed revision 10 (document currently at 20)
Result On the Right Track
Completed 2022-06-01
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


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


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