Re: [regext] Genart last call review of draft-ietf-regext-epp-eai-10

[Dmitry Belyavsky <[e-mail]>]

Dear colleagues,
Many thanks for the review!

On Wed, Jun 1, 2022 at 10:24 PM Gould, James <[e-mail]> wrote:

> Pete,
>
> Thanks for the review and feedback.  My responses are embedded below
> prefixed with "JG - ".
>
> --
>
> JG
>
>
>
> James Gould
> Fellow Engineer
> [e-mail]
> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>
>
> 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" <[e-mail]>
> 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