Nemo, In the -15 draft, we will be removing the following two statements in section 5.3.2 and fix the nit "allow:ed" in section 8. I believe this addresses your issues. Can you clear your "Ready with Issues" status in the tracker?
1. Delete "It can be an extra ASCII email address collected by registrar or registrar-provided proxy email address." from the fifth bullet in section 5.3.2. 2. Delete “The provided address can be an extra ASCII email address collected by registrar or registrar-provided proxy email address." from the last bullet in section 5.3.2. Thanks, -- 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 7/28/22, 5:46 PM, "Takahiro NEMOTO" <n...@go.tuat.ac.jp> wrote: 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....@dmarc.ietf.org>のメール: > > 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://secure-web.cisco.com/1P5eTKqxXvq3fcg13aFHNqKcvPh6yMCpA_0bCwU6cuxzqRId-u7OTrtrNMlPz-ldfcyeyXrMZPzZf1E6qlzoaH6g2rKUMM5T3cweZ0jQrw3WRv_8yfu1ueci6tHGEdfNggSoybH3k-TXVNGEtwXx5PKd93AECv02QGyXmwpS0lEvUJkllyn7s-D-NL-QTnoJZXRTJ1EHR7e04hYK4IxVbmM16qGiSlTmEPUK8XdaNUXD0Du397IW9o3SGL8f2EyWh/https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fregext%2FljIoGJtWaiLv8gw4SsSQVOs0xsM%2F ) 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 > jgo...@verisign.com > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com > > From: Dmitry Belyavsky <beld...@gmail.com> > Date: Friday, June 10, 2022 at 3:49 PM > To: Takahiro Nemoto <n...@go.tuat.ac.jp> > Cc: "a...@ietf.org" <a...@ietf.org>, "draft-ietf-regext-epp-eai....@ietf.org" <draft-ietf-regext-epp-eai....@ietf.org>, "last-c...@ietf.org" <last-c...@ietf.org>, regext <regext@ietf.org> > Subject: [EXTERNAL] Re: Artart last call review of draft-ietf-regext-epp-eai-12 > Resent-From: <alias-boun...@ietf.org> > Resent-To: <gal...@elistx.com>, <beld...@gmail.com>, <francesca.palomb...@ericsson.com>, Jody Kolker <jkol...@godaddy.com>, James Gould <jgo...@verisign.com>, <superu...@gmail.com>, <i...@antoin.nl> > 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 <nore...@ietf.org> 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://secure-web.cisco.com/1tMb8XaFwE_N229_DAyEctjgXHe73sMh7JHZDWesReGK9MrBQ_g2GEN0d4bpGZQxkLdUFPVzWFBIXISeo7JaK37GichhFO4RhnKb0p9Yjs1eKr8Sul4pay3vBl4C9TkdY0Ou8B4ntqnHJXmhWF_sBkbaBmibqplN7mnn0lWVT4sjMqijSxLED6Bt8lspHPb9LpuUz4sSimU6VixGbuod2OHD0C2M9mxbSmbPD6L1db2zZbd2XUtA6nZfxxmHvWuhY/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 > _______________________________________________ > art mailing list > a...@ietf.org > https://secure-web.cisco.com/1xVfl0_iksDN5lki8nYyqC0yuOdvYeOvJEXuqzsEzUfAZFiw_LVmBLbHEI3EtAdjyyMLZCN0zL3CwT21mqup4wK3ZUd1y3SzXM-SjYJdy_7OT5wsyrDae99XgepWgYXJYCKTSNObI2DeKqwwwzCf8tmIw-brUspEnSG3aVRMR52ZtnbZhSj4ewkivGL13uKFZVtWLx6Uv2vL9m4sWtzWIe_nHPZWn3WTOnANmNMbEYRYLHwxbl8Jjv8IbCpJKpqfz/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fart _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
