Dear colleagues, Many thanks for the review! On Wed, Jun 1, 2022 at 10:24 PM Gould, James <jgo...@verisign.com> wrote:
> Pete, > > Thanks for the review and feedback. My responses are embedded below > prefixed with "JG - ". > > -- > > JG > > > > James Gould > Fellow Engineer > jgo...@verisign.com > <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> > > 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" <nore...@ietf.org> > 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
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
