Re: [regext] I18ndir early review of draft-ietf-regext-epp-eai-10

[Yoshiro YONEYA <[e-mail]>]

Hi James,

My apologies not responding sooner.
Thank you for your detailed explanation and I'm clear now.
As Dmitry responded, this operational clarification hopefully to be explained in UA guidance or so of ICANN.

Regards,

Yoshiro YONEYA

On Thu, 28 Jul 2022 13:41:49 +0000 "Gould, James" <[e-mail]> wrote:

> Yoshiro,
> 
> I wanted to follow-up on your feedback.  I provided clarification in my response below to your feedback.  Does this clarification address your feedback, or do you have any additional feedback?
> 
> Thanks,
> 
> -- 
>  
> JG
> 
> 
> 
> 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/>
> 
> On 6/8/22, 10:30 AM, "Gould, James" <[e-mail]> wrote:
> 
>     Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. 
> 
>     Yoshiro, 
> 
>     Thank you for the review and feedback.  I include a response to your minor issue embedded below.
> 
>     -- 
> 
>     JG
> 
> 
> 
>     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://secure-web.cisco.com/12swQqASHG8jp3SfU6_L5bdYhd9OAfDo5_SQ4fTugrPKdCWtO_1ImxGQx4EtOqsKKRHP4-1QTdckOEZXPm-X1Y9XfiasMrTp6z8h3g1-eatwTUjs-46UZ-twKbk1b6YIWg6yRelianQNOmqTFV_WygyjVuR0wuHDXGW5YJFhxJbcDVjzURW_LTyojBDF_AoIUhkpHUqHIFYeLhc0A7TXdek4hayZ-IPSMpomt7PpHccWiZaCHIeS5s2cF9h0yQB7e/http%3A%2F%2Fverisigninc.com%2F>
> 
>     On 6/1/22, 9:04 PM, "Yoshiro Yoneya via Datatracker" <[e-mail]> wrote:
> 
>         Reviewer: Yoshiro Yoneya
>         Review result: Ready with Issues
> 
>         Summary:
> 
>           This draft is in good shape regarding protocol.  Regarding to operation,
>           having an additional guidance for registrar transfer from EAI supporting
>           registrar to non EAI supporting registrar would be better.
> 
>         Major issues:
> 
>           None.
> 
>         Minor issues:
> 
>           When a registrant who has only EAI contact addresses attempts to transfer a
>           domain from EAI supporting registrar to another non EAI supporting registrar,
>           then transfer of contact information will cause failure.  If there were
>           additional operational guidance addressing this issue in this draft will be
>           helpful for registrar operators.  For example, when loosing registrar who is
>           supporting EAI received a transfer request, it should check whether the
>           registrant has only EAI contact addresses, and if it was true, the registrar
>           should advice the registrant to provide alternative ASCII contact addresses
>           in advance for the successful transfer.
> 
>     Technically a transfer of the domain name doesn't include a transfer of the contact information, where the gaining registrar can create a new contact to link to the domain name once the domain name transfer completes.  Transfers of a contact in EPP is rarely done, but it is supported in EPP RFC 5733.  In section 5.3.2 of the draft, we cover the obligations of the client and the server when the opposite party doesn't support EAI.  For the case of a non EAI supporting registrar that wants to transfer the contact object via EPP RFC 5733, there is nothing that will cause an error in the transfer process.  Post the transfer, when the non EAI supporting registrar executes a contact info command, the EAI supporting server will return the 2308 "Data management policy violation" error response, per section 5.3.2 of the draft.  Most likely this will result in the non EAI supporting registrar reaching out to the registry out-of-band, with the error being mitigated by the registrar support
 ing EAI or the registrar updating the email property of the contact with an ASCII email, which will be allowed.  The obligations outlined in section 5.3.2 of the draft ensures that EAI addresses are not passed with a non-supporting party at the protocol level.   
> 
> 
>