Takahiro,
I wanted to follow-up with the feedback that you’ve provided. For the first minor issue, the proposal for “alternate ASCII address” in the message (https://mailarchive.ietf.org/arch/msg/regext/ljIoGJtWaiLv8gw4SsSQVOs0xsM/ ) is to remove the statements from section 5.3.2 since they are associated with registrar (client) policy. For your second minor issue, Dimtry made an update to Section 8 “Security Considerations” in draft-ietf-regext-epp-eai-13 based on your feedback. I do notice a “allow:ed” typo that will be addressed. Does this address your feedback, and do you have any additional feedback? -- JG [cid:[email protected]] James Gould Fellow Engineer [email protected]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: Dmitry Belyavsky <[email protected]> Date: Friday, June 10, 2022 at 3:49 PM To: Takahiro Nemoto <[email protected]> Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, regext <[email protected]> Subject: [EXTERNAL] Re: Artart last call review of draft-ietf-regext-epp-eai-12 Resent-From: <[email protected]> Resent-To: <[email protected]>, <[email protected]>, <[email protected]>, Jody Kolker <[email protected]>, James Gould <[email protected]>, <[email protected]>, <[email protected]> Resent-Date: Friday, June 10, 2022 at 3:49 PM Dear Takahiro, Many thanks for your review! I will update the draft in the middle of the next week according to your guidelines (with Marc's amendment) On Thu, Jun 9, 2022 at 10:32 PM Takahiro Nemoto via Datatracker <[email protected]<mailto:[email protected]>> wrote: Reviewer: Takahiro Nemoto Review result: Ready with Issues I am the assigned ART-ART reviewer for this draft. Summary: I think this document is concise and generally good, but a few things are not explained well enough. Please consider revising the following points. Minor issues: - It is unclear how to provide "alternative ASCII addresses" in Section 5.3.2 and how to distinguish between an EAI address and an alternative ASCII address, so it would be better to add an explanation. - It is unclear how to verify the code points of domain names in Section 8, so it would be better to add an explanation. RFC5892 describes how to determine the code points that can be used in IDNA2008 but does not describe how to validate domain name code points. So it would be easier to convey the intention to the reader to write "validate whether the domain name consists of the code points allowed by IDNA2008" rather than just writing "validate all code points in the domain name according to IDNA2008". Also, if the validation described in this section is intended to be compared to the code points listed in Appendix B.1. of RFC 5892, it would be better to refer to IDNA Rules and Derived Property Values <https://www.iana.org/assignments/idna-tables-12.0.0/idna-tables-12.0.0.xhtml<https://secure-web.cisco.com/1Q6tj3UOLMq6m40inAS38yCoH1j87TNdZJGnXwN_C5I6T64hxAlKic5w4THge5aKs7gCQhFO-HCu_A4P4VMwJb-mqsmjkg3EISbNqnBNZMR0q0xy4V8jNqaa_tUOZmy_GWzFzmaHj7_l9LDRTzK0TZO8gD08B8_7W7PeFivfA8F7nhjiz7-2iF8R-31dcz9xscBwvfDs98CPlWbsQTloKq5iB8QJZ4o6tdt_aaGlXtdSVsNPfJfvUx4uEtbAOACgX/https%3A%2F%2Fwww.iana.org%2Fassignments%2Fidna-tables-12.0.0%2Fidna-tables-12.0.0.xhtml>> listing the latest IDNA Derived Property Values. -- SY, Dmitry Belyavsky
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
