Dear colleagues,
Many thanks for the review!
On Wed, Jun 1, 2022 at 10:24 PM Gould, James <jgould@xxxxxxxxxxxx> wrote:
Pete,
Thanks for the review and feedback. My responses are embedded below prefixed with "JG - ".
--
JG
James Gould
Fellow Engineer
jgould@xxxxxxxxxxxx <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@xxxxxxxxxxxx>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com <http://verisigninc.com/>
On 6/1/22, 1:14 PM, "Pete Resnick via Datatracker" <noreply@xxxxxxxx> wrote:
Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
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://secure-web.cisco.com/1K6cgCFLakXfTnPIeaE2ZwevlkM0KiD6YlQuPilL-K-FXI75spzFhwPbrTminlCoOV1FdlZ-bTNGfTViEpxNNwpy3pP1zuhfVsE4ZUjY7vULMuNEt3p-qQ62KtoXfXHC_KpjCFJHvW7GqkJC_qLRyJ-N78dFJBhWHSKNXlYl2cJL2QXsuMUzInqccq9AGZZJodZnSZU_J1df7jwu242lQtR1zAq0RHYomOugyloQ1oaUDFUXOeh3j2WkUwpPpY3hA/https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fgen%2Fwiki%2FGenArtfaq>.
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.
JG - The reference to the "alternative ASCII email address" is for the client (registrar) when it's recognized that the server does not support EAI. If the registrar collected an EAI address and an ASCII address, then the ASCII address MUST be provided; otherwise, the optional property SHOULD be omitted. The use of an ASCII proxy email address can be used as well. In this case, the server does not support EAI addresses, so it's up to the EAI-supporting client to handle it. Most likely the server validates that the address is only an ASCII address, but there is no guarantee of it.
I agree but I don't think that explanations of registrar operational practices (e.g. collection of backup email addresses, etc) is in the scope of protocol documents.
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.
JG - I cover each of the SHOULDs below:
1. For the required email property with a client that doesn't signal support for EAI, the server needs to satisfy the negotiated services . This should be a MUST to comply with the negotiated namespaces, since the downside is that the client will receive an error response with an info command if they still don't support EAI in the login services. The error response is a MUST in the third bullet.
2. For the optional email property falls the same case as the required email property, since the info response will result in an error. It should be a MUST as well. The error response is a MUST in the fourth bullet.
I replaced both these SHOULDs with MUST
Nits/editorial comments:
Abstract: Strike the word "appearing"
JG - Yes, that can be removed.
Done
Section 3: Change "By applying the syntax rules of [RFC5322]" to "By applying
the syntax rules of [RFC6532]"
JG - I'll leave this one for Dmitry to respond to, but changing RFC5322 to RFC6532 looks correct to me.
I think the proper RFC is 6531 here. Done.
SY, Dmitry Belyavsky
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
