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

Dmitry Belyavsky <beldmit@gmail.com> Thu, 18 August 2022 12:15 UTC

Return-Path: <beldmit@gmail.com>
X-Original-To: i18ndir@ietfa.amsl.com
Delivered-To: i18ndir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA2FC15270F; Thu, 18 Aug 2022 05:15:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 yemXGf8q_vGQ; Thu, 18 Aug 2022 05:15:06 -0700 (PDT)
Received: from mail-yw1-x1136.google.com (mail-yw1-x1136.google.com [IPv6:2607:f8b0:4864:20::1136]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 6C170C15270C; Thu, 18 Aug 2022 05:15:06 -0700 (PDT)
Received: by mail-yw1-x1136.google.com with SMTP id 00721157ae682-31f445bd486so35085187b3.13; Thu, 18 Aug 2022 05:15:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=lWumQhVo3ofj0WwxhrGMm4yiT91CBYulACZEHqqGoVY=; b=c7NNEhGehmQEwuJUbYIlbhaCLxirkrg4LuB7z+q92rMX0lFgiz1jMGudh0kH9qJ/D3 g9xs+6YvjZtcF0RLUA+lTPwiDVzZy9dr/uYG8LKwIW9viaOJYA67wVg2Lwpcq7qVWq6c Iv7QGvuc9UBMJZY+0kyuKYemWwGd911REg3H1oKKVXhKl6EV4NmZenv3GSamFEFntvz9 QM7TUJeO3RfrZFSXJNGQtfrOPl1xgG/TmAaubzJYUBzI+gDp/VXtID5Wdm5ldWzjsV+m 65WluTd2IrQp5J0s45ZYbSWGgC2tZ18gXaTVA0M5ZMe1wLXcoTJEsQeFRYb9kmYC4JLM Zf8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=lWumQhVo3ofj0WwxhrGMm4yiT91CBYulACZEHqqGoVY=; b=GHw4CysAiHTsNsTwu8JLo70+x+JqbyrFLehbtRhTnNCcF7yhNu+cj9LnXeWggmyUuU mftR4bzlv0YgJ15EtktAbjnafbVhupEMshkOp46PMnHXd6s5a8ZdW/PYNKkVvhyKxRej aT5kcTZ9UF3Tde2eSDKJ/d71J4g6sGewzx+3ziduH4oI6KqxJyiMH/EqjI9aTPWMgCfX nq9Rh6v744MEuizkkKfnAy7/3jOvh2hmj+PCJv2zZFFntF/tf/aOFWpCbSBUgQ4UJ6Wg d7CCINzYk92Y+6eaNrKQaTBcPMgQa+moHWka5TczOzLdOGWmyh0/o1bdz/oN3DIHlcCe 5xvw==
X-Gm-Message-State: ACgBeo1ij7WyRFfanIh5y5/O/DhaPI82Gkn7Gqzo5XQtnJuXTx2SMl6t 4DJjOd8qhkmgiINPOIqVeF77SJ0ahyGsMNA4ezc=
X-Google-Smtp-Source: AA6agR4S03SRw56gswhoDAINvfkdDVnB1tRdALQvgVCPTO22AgdjlKh+wXe4TwK2FYnITyN1GmuYV/OpqDt+GCpIkmc=
X-Received: by 2002:a25:55c2:0:b0:684:4159:38f4 with SMTP id j185-20020a2555c2000000b00684415938f4mr2476376ybb.288.1660824905585; Thu, 18 Aug 2022 05:15:05 -0700 (PDT)
MIME-Version: 1.0
References: <00B2BD2D-63E7-4D73-95BC-DD0650B3A7DA@verisign.com> <8510291CFDD59E597396E0A4@PSB> <B12F0D2F-BFEE-4478-9E70-1152CB05A418@paftech.se>
In-Reply-To: <B12F0D2F-BFEE-4478-9E70-1152CB05A418@paftech.se>
From: Dmitry Belyavsky <beldmit@gmail.com>
Date: Thu, 18 Aug 2022 14:14:54 +0200
Message-ID: <CADqLbzLvN2JXpMH6iVUpLCb74wpEyahAu4hgb-6s_UAofc87kw@mail.gmail.com>
To: Patrik Fältström <paf@paftech.se>
Cc: John C Klensin <john-ietf@jck.com>, "Gould, James" <jgould=40verisign.com@dmarc.ietf.org>, art@ietf.org, draft-ietf-regext-epp-eai.all@ietf.org, last-call@ietf.org, regext <regext@ietf.org>, i18ndir@ietf.org, gen-art@ietf.org
Content-Type: multipart/alternative; boundary="0000000000008817bd05e682ee44"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i18ndir/ozycL25OMqhghfr1XH720DFiuZA>
Subject: Re: [I18ndir] [Last-Call] [art] Artart last call review of draft-ietf-regext-epp-eai-12
X-BeenThere: i18ndir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Internationalization Directorate <i18ndir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i18ndir>, <mailto:i18ndir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i18ndir/>
List-Post: <mailto:i18ndir@ietf.org>
List-Help: <mailto:i18ndir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i18ndir>, <mailto:i18ndir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Aug 2022 12:15:07 -0000

Dear Patrik,
Many thanks for your letter!
see my answers below.

On Thu, Aug 18, 2022 at 10:10 AM Patrik Fältström <paf@paftech.se> wrote:

> 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.
>

Well... From my point of view (being a registrar for a while), it's a
registrar's responsibility to reflect the changes in the registry technical
policy in its software.


> - 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.
>

Well...

End users hardly feel the difference between registry, registrar, anr
registrar's reseller. They have a service company that provides smth
they need, and find out that there is some difference only when smth
happens to their domain.
These companies, in turn, encapsulate the difference between registries'
requirements in their software. It's their burden - and they get money for
that. They may collect extra data, may provide some extra services - but
serving as the registrar is their burden.

I agree that we need less diversity between registries - but at least this
diversity is inevitable until countries exist :)
If we try to provide uniform requirements, I'm not sure we should do it via
preventing/limiting usage of non-ASCII email, speaking about this case.

-- 
SY, Dmitry Belyavsky