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
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 6/8/22, 10:30 AM, "Gould, James" <jgo...@verisign.com> 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
    jgo...@verisign.com 
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com>

    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" <nore...@ietf.org> 
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 supporting 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.   


_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Reply via email to