Re: [regext] [Last-Call] [art] Artart last call review of draft-ietf-regext-epp-eai-12

Patrik Fältström <paf@paftech.se> Thu, 18 August 2022 08:11 UTC

Return-Path: <paf@paftech.se>
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 8EDB1C1594AB; Thu, 18 Aug 2022 01:11:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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_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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=paftech.se
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 AHIJmUHLvTgr; Thu, 18 Aug 2022 01:10:58 -0700 (PDT)
Received: from mail.paftech.se (mail.paftech.se [192.165.72.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81482C14CE2B; Thu, 18 Aug 2022 01:10:56 -0700 (PDT)
Received: from [10.13.36.13] (office28.ggv13.sth.netnod.se [77.72.226.28]) by mail.paftech.se (Postfix) with ESMTPSA id 9F51140381; Thu, 18 Aug 2022 10:10:53 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paftech.se; s=2022013001; t=1660810253; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=WXl2pZA44uInsj3w0pw0U6H+Dw1kf8f9rvEctX3syaY=; b=I0ZrT8pdotQed3xR0nKW3PIGE+ZY1fKMMl/xtKQKNzcIEmNioUIe5RNnGrFLgX2hxM7bnv PcIl9F2j3Uoidt6LCyLXdc7aSt80+Jg0iz9njRQT6nwMpfhmUE6nXPVyh4fM08Lt/w74nT tuvrM720JUWnxyNMg+jE8HxAM9A9nsQ=
From: Patrik Fältström <paf@paftech.se>
To: John C Klensin <john-ietf@jck.com>
Cc: "Gould, James" <jgould=40verisign.com@dmarc.ietf.org>, beldmit@gmail.com, art@ietf.org, draft-ietf-regext-epp-eai.all@ietf.org, last-call@ietf.org, regext@ietf.org, i18ndir@ietf.org, gen-art@ietf.org
Date: Thu, 18 Aug 2022 10:10:47 +0200
X-Mailer: MailMate (1.14r5910)
Message-ID: <B12F0D2F-BFEE-4478-9E70-1152CB05A418@paftech.se>
In-Reply-To: <8510291CFDD59E597396E0A4@PSB>
References: <00B2BD2D-63E7-4D73-95BC-DD0650B3A7DA@verisign.com> <8510291CFDD59E597396E0A4@PSB>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_60F8382E-BB45-4282-B8E6-16FEC44BA6E6_="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/37Ski6EKv0VzwEijOQMhNfrmlR0>
Subject: Re: [regext] [Last-Call] [art] Artart last call review of draft-ietf-regext-epp-eai-12
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, 18 Aug 2022 08:11:01 -0000

On 18 Aug 2022, at 7:59, John C Klensin wrote:

> (3) Or if, as I believe one of your recent notes suggested,
> those alternative addresses are strictly a matter between the registrar and registrant, that raises two other questions.
> First, if a registrar is in need of the information to
> adequately communicate with the registrant, why isn't the
> registry and those with legitimate access to registry databases?

Don't forget two (more) things:

- We can not allow new registrar-registrant issues increase trouble for the registrant to transfer a domain from one registrar to another.

- A registrant is doing business with one or more registrars, and a registrar make business with one or more registries (for the same registrant). We do not need more diversity between registries and registrars, we need less. The more similar rules the registries have, the easier it is for the registrant to register their favourite label in more than one TLD. And the more freedom (and difference) in the interface between registry and registrar (the "e" in "epp"), the more complicated it is for the registrar to explain and implement the differences to and on behalf of the registrant. It is already too hard I think. Registries view is that they have many registrants. In the real world, a registrant use multiple registries.

   Patrik