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

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@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://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@Verisign.com
> 
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
> 
> Verisign.com
>  
> From: Dmitry Belyavsky <beldmit@gmail.com>
> Date: Friday, June 10, 2022 at 3:49 PM
> To: Takahiro Nemoto <nemo@go.tuat.ac.jp>
> Cc: "art@ietf.org" <art@ietf.org>, "draft-ietf-regext-epp-eai.all@ietf.org" <draft-ietf-regext-epp-eai.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, regext <regext@ietf.org>
> Subject: [EXTERNAL] Re: Artart last call review of draft-ietf-regext-epp-eai-12
> Resent-From: <alias-bounces@ietf.org>
> Resent-To: <galvin@elistx.com>, <beldmit@gmail.com>, <francesca.palombini@ericsson.com>, Jody Kolker <jkolker@godaddy.com>, James Gould <jgould@verisign.com>, <superuser@gmail.com>, <ietf@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 <noreply@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://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@ietf.org
> https://www.ietf.org/mailman/listinfo/art