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

"Gould, James" <jgould@verisign.com> Wed, 17 August 2022 12:58 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 10D9DC157B37; Wed, 17 Aug 2022 05:58:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 E_cfCxG6BzAL; Wed, 17 Aug 2022 05:58:43 -0700 (PDT)
Received: from mail2.verisign.com (mail2.verisign.com [72.13.63.31]) (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 CBF56C1522B2; Wed, 17 Aug 2022 05:58:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=7476; q=dns/txt; s=VRSN; t=1660741123; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=UZx/GHWIRW4BUquLKOT/+xjb0B2pVsxLYTLJRwJvLu8=; b=M1dRvFmPM7mZ+WXNa2W5ZC/N/DbPwgsUAV4VTRmkhZHfiQOm3YNlQuvx NgwxQPGrzF6iDRUji8Ayh19pXDWcHiZjwh50LXT6inZrfrRV6XM70khtZ aBRcXtNoxG2d2H/YDD70FbxrMW2tNo0f4mb/51o3O2ywZY0wJwo4fd5Y7 CkOXDGicxAuMgxgOj6rsna+/tMeE24d1GYo8M00xX1Yeu2m01WxAqNi0V I2XTnkiflR18dr8M/6w+RWj1khSL15peEhjOG90CkiLrsVXSzXgdYgkdH YcYC0OrDlWSsIUHpRtqoNyzx6L7Iv3JHCLZEaxnZ1+rtgq2z9nxHryI+E w==;
IronPort-Data: A9a23:UpZdsKqW2edqUiKRbJsxHt3hGqdeBmIdZBIvgKrLsJaIsI4StFCzt garIBmEMv2MNDOkft8la9zj/B9U7ZbcnIBiGwQ5+Co1En8U8JacVYWSI3mrMnLJJKUvbq7FA +Y2MYCccZ9uHhcwgj/3b9ANeFEljfngqoIRjIcoAwgpLeNeYH5JZSlLxqho2eaEvfDjW1nX4 YOr/JWGULOY82Uc3lw8uvrrRCxH4ayaVAMw5jTSstgS4TcyP1FMZH4uDfnZw0nQG+G4LcbjL wr394xVy0uCl/sbIoj8zuukKB1iron6ZmBiglIOM0SrqkYa+nxqis7XPtJEAatco23hc9ycV LyhHHF/IOskFvSkpQgTb/VXO3phOrwW+4b8GFOEt8C/8H3eSXbmnsw7WSnaPaVAkgp2KUt00 6UnDh09NknFmemx2qr9Q+UqmN44Ko/gO4Z3VnNIlGmfVKl9B8meGOOWtbe03x9p7ixKNfTRY NcdZRJxYQ7BeBxAPBEcD5dWcOKA3yenLmwH+QP9Sawf82PLlRxsjb3WP4Toe9aXT/1Op1e4n zeTl4j+KlRAXDCF8hKU9Wmsh/XI2zL8Xo8DHZW67uRxxlaUgG4LYDUXDAu9rfijok+zR9wZL FYbkgIit6E86AmqQ8XzGge1r3OUolsRQ8IVHuQ7rgiJzoLV7hqXQG8eQVZpctEpud8qbT0ny lHPmMnmbQGDq5WfU3TE6bGZvWvrfDMLNykHZDRBRwxD6cPl+cctlAnJCN1kFcZZk+HIJN05+ BjSxABWulnZpZdjO3mTlbwfvw+Rmw==
IronPort-HdrOrdr: A9a23:9npCqqpyKMnQF6W0bdWpvKcaV5r2eYIsimQD101hICG9Ffbo8v xG/c5rtyMc5wxwZJhNo7690cq7Lk80nKQdibX5Vo3SPzUO1lHIEKhSqaXvxDH6EzDz+6p3xc 5bH5RWOZnVAUJhhcj3pCu1A78bquWvweSNif3Fx3lgCTt2bbpthj0VNi+AHlZoSBJ9CZ01KZ qZ6qN8zAadRQ==
X-IronPort-AV: E=Sophos;i="5.93,243,1654560000"; d="scan'208";a="16059799"
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.31; Wed, 17 Aug 2022 08:58:41 -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.031; Wed, 17 Aug 2022 08:58:41 -0400
From: "Gould, James" <jgould@verisign.com>
To: "yoshiro.yoneya@jprs.co.jp" <yoshiro.yoneya@jprs.co.jp>
CC: "i18ndir@ietf.org" <i18ndir@ietf.org>, "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: AQHYsjkTwGNA9GImzUOGmaHfl6Hl4w==
Date: Wed, 17 Aug 2022 12:58:40 +0000
Message-ID: <5B03AFB5-F01E-4DAA-A1E4-B5F8FBB280FA@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: <D75EB3144634B844A29971DDBA90B957@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/LMK6REapwb1eITipklxGDIfvE30>
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, 17 Aug 2022 12:58:48 -0000

Yoshiro,

Now that you're clear, can you change the review "Ready with Issues" status in the tracker?

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 7/28/22, 12:20 PM, "Yoshiro YONEYA" <yoshiro.yoneya@jprs.co.jp> wrote:

    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" <jgould@verisign.com> 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
    > 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/1OramOsWSpbticOdv1E7x6KBVAjaYui6PxRCAtfrgiBp3qOQ7TsI8lmXgsGCiDvpqPgcRinYStYDc4fMragrDVj-7QQ8AgROgOZtMxHV6M_qyDjZ_914ALpP-9K7-79GR0rqJ-yBmIUfQaEGgklBdUfonXGkIrTDgTQ8H5F7xw8GrKxbr3fqY6Uuviz9YaBml50QnnOT_-uRavXamYW_tfBQGmPYr-TslriwStacd2XID_2ge95RpKFXoAbG-YPk2/http%3A%2F%2Fverisigninc.com%2F>
    > 
    > 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 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.   
    > 
    > 
    >