Re: [regext] Artart last call review of draft-ietf-regext-epp-eai-12

["Gould, James" <[e-mail]>]

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:image001.png@01D8A263.178C6AD0]

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/>

From: Dmitry Belyavsky <[e-mail]>
Date: Friday, June 10, 2022 at 3:49 PM
To: Takahiro Nemoto <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, regext <[e-mail]>
Subject: [EXTERNAL] Re: Artart last call review of draft-ietf-regext-epp-eai-12
Resent-From: <[e-mail]>
Resent-To: <[e-mail]>, <[e-mail]>, <[e-mail]>, Jody Kolker <[e-mail]>, James Gould <[e-mail]>, <[e-mail]>, <[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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