Hi James, Sorry I couldn't reply sooner. I have checked the update in -14 and future changes. I agree to remove the sentence in section 5.3.2. This change will make Section 5.3.2 clear. I've also confirmed that the link in section 8 had been corrected to the link Marc suggested. I have also agreed to fix the typo. I'm concerned about John's comments (I saw them on the Gen-ART archive as well as here), but I'm sure you will reflect my feedback here in the next update for the time being. Regards, Nemo > 2022/07/28 22:19、Gould, James <jgould=40verisign.com@xxxxxxxxxxxxxx>のメール: > > 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 > > <image001.png> > > James Gould > Fellow Engineer > jgould@xxxxxxxxxxxx > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com > > From: Dmitry Belyavsky <beldmit@xxxxxxxxx> > Date: Friday, June 10, 2022 at 3:49 PM > To: Takahiro Nemoto <nemo@xxxxxxxxxxxxx> > Cc: "art@xxxxxxxx" <art@xxxxxxxx>, "draft-ietf-regext-epp-eai.all@xxxxxxxx" <draft-ietf-regext-epp-eai.all@xxxxxxxx>, "last-call@xxxxxxxx" <last-call@xxxxxxxx>, regext <regext@xxxxxxxx> > Subject: [EXTERNAL] Re: Artart last call review of draft-ietf-regext-epp-eai-12 > Resent-From: <alias-bounces@xxxxxxxx> > Resent-To: <galvin@xxxxxxxxxx>, <beldmit@xxxxxxxxx>, <francesca.palombini@xxxxxxxxxxxx>, Jody Kolker <jkolker@xxxxxxxxxxx>, James Gould <jgould@xxxxxxxxxxxx>, <superuser@xxxxxxxxx>, <ietf@xxxxxxxxx> > 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 <noreply@xxxxxxxx> 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> >> listing the latest IDNA Derived Property Values. >> >> > > > -- > SY, Dmitry Belyavsky > _______________________________________________ > art mailing list > art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/art -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
