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

"Gould, James" <jgould@verisign.com> Thu, 28 July 2022 13:42 UTC

Return-Path: <jgould@verisign.com>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14C5C14EB1E; Thu, 28 Jul 2022 06:42:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.109
X-Spam-Level:
X-Spam-Status: No, score=-7.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kk2djkStzXdy; Thu, 28 Jul 2022 06:41:58 -0700 (PDT)
Received: from mail1.verisign.com (mail1.verisign.com [72.13.63.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF553C157B3A; Thu, 28 Jul 2022 06:41:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=5334; q=dns/txt; s=VRSN; t=1659015718; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/o+HJhvXFzlPiyEU96VPa/mVbD0zwbJendrtj7OsT9M=; b=mFISGYjLFIUFry1NInTpemueBJb4ityjpLnbnx0Z195uv0tAZRRhGTU/ gufUp8GVjKS34LKOhLcIjwc2YylBcFDs4mBiTe7kc0pZAwDBV7w9ubj5i Rvl1q+Pq0fneQYRe7j6fo/PmG5lUhvn2RE4X4BswPWVpfe/ArvqQiRsk3 VHAfB/b3UKhxcwi+twb/yF9qQ6oQAM7TE3yd67UgrGPr/MbCXicJXYLhv evW9su2ccgC4jcvxHqm8WVbKx4TMH8GAXkL2qkL/5/NKT08xFZ5m1Ddzk 5vh5ij0cJzUFn7okVWJtj1TiWUpkLHQuu+y0gy5YiSLFz13ktAnbdO0Rj Q==;
IronPort-Data: A9a23:kOKnv6zHvb7yJDYybN96t+cyxyrEfRIJ4+MujC+fZmUNrF6WrkVWy DccUW6AbPyDa2egKtsgbdi/pBkOu5XQnNNqGQJu/C00HyNBpPSeCIXCJC8cHc8wwu7rFxs7s ppEOrEsCOhuExcwcz/0auCJQUGRUchkf5KkYAL+EnkZqTRMFWFw0nqPp8Zj2tQy2YfjU1vX0 T/Pi5a31GGNimYc3l08tvrrRCNH5JwebxtB4zTSzdgS1LPvvyF94KA3fMldHFOhKmVgJdNWc s6YpF2P1jiAo0pyUIPNfoHTKSXmSpaKVeSHoiQOB/j62nCurARqukowHKJ0hUu6F1xlNj2+o TlAncXYdOsnAkHDsOpGaAhoTxAjBqcY0ZmZGlbmnZeRkVKTJhMAw902ZK03Faci3L9IJ0x+r aZeNjsKdAjFju7w3qigTK9ngcFLwMvDZdtZ4y47i2iEVrB6EPgvQI2TjTNc9DU/gd1KEd7Aa tAYcjtgalLLZBgn1lI/Uc1jwLzz2SSXnztwiUnMiJhqvGTokE8tgKK9d5nWX4OEfJAA9qqfj iecl4jjOTkLM8efyCCCtGOrgOLelAv5QJgJUra/sPxy6HWSnzwVBBwMfVq2vff/jVSxM/pTM UUa5m8voLQ8sVamQdTtQ1i1uGbBsxcdHdNUF8U75R2DjK3O7G6xHGULQy5dQN0rqMFwQiYlv mJlhPvjHzo2r7uYWSrHs6yKt3W3ODNQJ2hEbzUCFE0b+cLl5oo0i3ojU+peLUJ8tfWtcRmY/ txAhHJWa2k75SLT65iGwA==
IronPort-HdrOrdr: A9a23:+Y1Rfqm3jmiGL3DZHybJWQDTJt3pDfLx3DAbv31ZSRFFG/Fw8P re+cjztCWE6gr5N0tBpTntAse9qBDnmqKdiLN5VYtKNzOW21dAQrsC0aLShxPtHCHk/vNQ2O NKY8FFZOHYPBxfgdzh6Ae1V/Qt0LC8mpyAtKP7w212RQ9nL5t86Rx0Yzz3LmRtSBJYCYECGJ 2Q28pCq1ObEkgqUg==
X-IronPort-AV: E=Sophos;i="5.93,198,1654560000"; d="scan'208";a="17543375"
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.28; Thu, 28 Jul 2022 09:41:50 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([10.173.153.48]) by BRN1WNEX01.vcorp.ad.vrsn.com ([10.173.153.48]) with mapi id 15.01.2375.028; Thu, 28 Jul 2022 09:41:50 -0400
From: "Gould, James" <jgould@verisign.com>
To: "yoshiro.yoneya@jprs.co.jp" <yoshiro.yoneya@jprs.co.jp>, "i18ndir@ietf.org" <i18ndir@ietf.org>
CC: "draft-ietf-regext-epp-eai.all@ietf.org" <draft-ietf-regext-epp-eai.all@ietf.org>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: Re: I18ndir early review of draft-ietf-regext-epp-eai-10
Thread-Index: AQHYe0RI97h+WkLOBECkMQ0vYLKOea2UGQqA
Date: Thu, 28 Jul 2022 13:41:49 +0000
Message-ID: <C43FF879-D091-49F0-AA5B-067E2A92A445@verisign.com>
References: <8E7CE5FC-3A1D-419A-9DD2-3444A2E91C4B@verisign.com>
In-Reply-To: <8E7CE5FC-3A1D-419A-9DD2-3444A2E91C4B@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.62.22061100
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-ID: <DB4A5D605E20D140AAD8DCA98AD7961C@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/Q2hkzwGq1YzRcjg5V93heD9QL68>
Subject: Re: [regext] I18ndir early review of draft-ietf-regext-epp-eai-10
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jul 2022 13:42:03 -0000

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
jgould@Verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@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" <jgould@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
    jgould@Verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@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" <noreply@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.