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

"Gould, James" <jgould@verisign.com> Wed, 08 June 2022 14:30 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 7CDA1C1594A9; Wed, 8 Jun 2022 07:30:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.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, 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 TiGocLFl7pf8; Wed, 8 Jun 2022 07:30:24 -0700 (PDT)
Received: from mail3.verisign.com (mail3.verisign.com [72.13.63.32]) (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 630EEC157B4F; Wed, 8 Jun 2022 07:30:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=3802; q=dns/txt; s=VRSN; t=1654698625; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=QC7R8dVjiLM6yAFrWhiDDXmStLi9BKemaVRR8A3QPS0=; b=bUfHvY7zLlHVs+Fq7Z1ByBmNozLZfjv22xIO8ZEDgHgUxNfxS4ltGtO5 A3M5w9vzvA7CGHNtpnACLnHciTd5qEDj9RhfsyJaqa0ZRrSaRGaDlXFYu MxG4ElbnMhr7m9IRn0Wn6dfpaBZuh2cSAKlGKx8N+47Wu97TdQ5ycGXst 66lB9ZZH9IWk/4Mp2d+1JN+irVzbyDPwxtgZHVCqtqSN1l9ib4OLJgFsF wS/1IBxwLhLp0+d3k1X6w3Qgt01qzUkOhrpYkljbbtiV7YtXAGUdZBPQF oIaIaP9gKE8gvuQhJqtA+W/WeMB3u4lRtWizNeGyMGw357KcaIFtNVoTk w==;
IronPort-Data: A9a23:14fu0KNvEhXbEODvrR2glsFynXyQoLVcMsEvi/4bfWQNrUon0jEHn 2EYDz3Qa62LamXwfdp2aYiy9kIOu5OEnIRlSAZtpSBmQkwRpJueD7x1DKtS0wC6dZSfER09v 63yTvGacajYm1eF/k/F3oAMKRCQ7InQLlbGILes1htZGEk1EU/NtTo5w7Rj2tAw0YDja++wk YiaT/P3aQfNNwFcbzp8B5Kr8HuDa9yr5Vv0FnRnDRx6lAe2e0s9VfrzFonoR5fMebS4K8bhL wr15Orgoj6GpUdF5uSNyd4XemVSKlLbFVbW1ioOA8BOiDAazsA5+v5T2Pbx9S67IthG9jx84 IwliHC+desmFvLdhL0WfxhoKD9/NpJ79uDnH2m44NPGmiUqc1O0qxlvJGsMG9Qn3MtHWTgI6 /cfMihLZxzFmfitxvSwTewEasYLdZGtZdxE/Cg9lneFXZ7KQriaK0nOzd1X2yo0iuhQEOzff MsWb3xkaxGojxhnYwpLWc9iwrfAan/XTQMDknuXp4oM7W3M6xIo2p/wL9jQU4nfLSlStgPCz o7cxEzoBQoaNcaYjyuC9H+9j8fNhTngHokVUr+gntZr2Q2Vym0JIBwbSVX9puO24mayQdtRN wkV9zYg6LI/+0G7UpzwRwX9rXeF+BcYX/JRHvE0rgaXxcL8+QuWC3gYZj9MdNJgs9U5LQHGz XeDhdWwGjpioOXMDGmD7PGRrCj3My9TJ3UEPGkaVxADpdLkpenfky7yczqqK4bt5vWdJN066 2niQPQW71nLsfM26g==
IronPort-HdrOrdr: A9a23:9k8LtK0JUCREJl9ZbtVp0gqjBG8kLtp133Aq2lEZdPUzSL38qy nOpoV46faaslYssR0b9+xoW5PufZq0z/cc3WB7B8bAYOCJggqVBbAnw4fkzybpBiHyssVMvJ 0NT4FOTPn9F0Jzg8q/wgWpeuxL/PC3tISln/3XwXsodxxtcK0I1WpEIxyWCVJ7XzNLApcFFJ 6Rj/Atmwad
X-IronPort-AV: E=Sophos;i="5.91,286,1647302400"; d="scan'208";a="15495468"
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.24; Wed, 8 Jun 2022 10:30:21 -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.024; Wed, 8 Jun 2022 10:30:21 -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: I18ndir early review of draft-ietf-regext-epp-eai-10
Thread-Index: AQHYe0RI97h+WkLOBECkMQ0vYLKOeQ==
Date: Wed, 08 Jun 2022 14:30:21 +0000
Message-ID: <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.59.22031300
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-ID: <2224714B8F7593458C8393D7707A50DD@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/PmWu5gCSsIC-govCdutv_mN1b38>
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: Wed, 08 Jun 2022 14:30:28 -0000

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://verisigninc.com/>

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.