Re: [regext] WGLC: draft-ietf-regext-org-02

Patrick Mevzek <pm@dotandco.com> Sun, 27 May 2018 19:23 UTC

Return-Path: <pm@dotandco.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 2553E12E053 for <regext@ietfa.amsl.com>; Sun, 27 May 2018 12:23:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dotandco.com header.b=SUc8kyxV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nBH9fv3L
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9lZEpyRoJdi for <regext@ietfa.amsl.com>; Sun, 27 May 2018 12:23:18 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32C91126DC2 for <regext@ietf.org>; Sun, 27 May 2018 12:23:18 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 75B9321A6C for <regext@ietf.org>; Sun, 27 May 2018 15:23:17 -0400 (EDT)
Received: from web3 ([10.202.2.213]) by compute3.internal (MEProxy); Sun, 27 May 2018 15:23:17 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dotandco.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=OJWwtSZoRFgbBnMdOEMo9ut7agbFN vN2N+JqE2Eas/M=; b=SUc8kyxVFNuhC9XoBDoPDH/I0KhCeKlOCsDOkIlP7yyLS 1QfkNjBzCzJBqJX7W1xt9sQe84yFzKGlY08dnPBNLbiUIA+ekVTgFGs+qcwqB8eZ 0eLWbceWIXja7HQ7LhH2iTaovsoD/aCWhfSMtKPIEk1gGFuwBk0Xs1RZuPIViV1t hgYtMVw2N6GXKVojTkfaZlboIRlwupaSfwu/fo0HByNsh0PtRXOxBMTKKnkM96z8 tLn1K1oS+pRXLRp+4tTgI5Y1xPvA5rAArO3DWzcpXhE51L7VIFOnzG2XgZkegl4A zV2cVHtBkw8Wd+l/pjoQTHfIVJWmWC2QuZ09WQhTA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=OJWwtS ZoRFgbBnMdOEMo9ut7agbFNvN2N+JqE2Eas/M=; b=nBH9fv3Lp3/Qq+EIDhV3FA PWlw9eSVCkiROkM7aC2Cw9M2kIqfOz4manwfXHllqj6xZbVWosjOpUsOOkJrRAGe GroNvwo2sxuaLwNbRQ50A0lbB8FRo/orTyL4ypf4Tho86MWDT2oQFGrTwXhJZIFP z6PQv9lwUV2iVgaBwKT/1KIrda4NaREIiK+lAPRxg6QwhjgdVTMYKDuUQN8HiZ5z eW2IFyo8j4SmV374lPZeY1tGOjHSt9UzcigDHPZYJIgSlyHI9i1UoO+qUCupftaP ALdUcziO/92r9rsSftEtcDBhRKbR+ArQu6IhaQTJFGjWu+1QiPRy2zuVy8yQ0zPA ==
X-ME-Proxy: <xmx:pQULW7TlJkROdaRyINZ7QJP7sLtd8t__Y9o8Ot5jIC5vPP-0zSpBUQ>
X-ME-Proxy: <xmx:pQULWxVnFN7qoQPtZ1xyxAvk5Axfx2VdmqSOjw-mJa4BLZEA4qmSyA>
X-ME-Proxy: <xmx:pQULW8uyj5f97rc2ASXIInX8ZSrJan_XJEWkxUFDS_sv2HfsxVyG3w>
X-ME-Proxy: <xmx:pQULW3uyaVfuJQRhdyfRCo1pFm6ScuEr5CtSianYPZFT1Q2pMUZmnA>
X-ME-Proxy: <xmx:pQULWw54iAA7BKNy-LHmF3J0jhLjBxX-fxqH6voY2zHzOa3a3fuObQ>
X-ME-Proxy: <xmx:pQULW7VuYwr7LXtHUF-S9XcMIzhFgxzy1QnNRGAHeBfvYWJxtL0mcQ>
X-ME-Sender: <xms:pQULWx78VAOw-ap4gm3i8EgUHZyvxy-CVAZqAF9emLswOvREMmdL72EcFLg>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 377A59E196; Sun, 27 May 2018 15:23:17 -0400 (EDT)
Message-Id: <1527448997.1643063.1387308680.73816387@webmail.messagingengine.com>
From: Patrick Mevzek <pm@dotandco.com>
To: regext@ietf.org
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-29e6b281
References: <80ED56C6-75F7-4DED-927B-E0AB528A71EE@elistx.com> <656C123C-9ECF-434D-948D-4E704ED3E75C@elistx.com> <1526872740.790268.1378875200.662ECDF2@webmail.messagingengine.com> <A9E94F6D-1C51-47C4-B74D-22D40841317C@dnsbelgium.be> <B0F071B4-DF2D-4E46-9002-C7FFAA5DAC25@dnsbelgium.be> <1527140656.2870129.1382989368.51CB4B29@webmail.messagingengine.com> <E200CA5E-FB32-4767-B837-35560EA0EF06@dnsbelgium.be> <DA1F19C3-209A-40B7-A872-21582D25A5A1@verisign.com> <1D86FAEA-9A4D-4BD8-B280-067FFAEB3D54@antoin.nl>
In-Reply-To: <1D86FAEA-9A4D-4BD8-B280-067FFAEB3D54@antoin.nl>
Date: Sun, 27 May 2018 21:23:17 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/Et7TgOsyGsvJuH51ToB5lq7zSz4>
Subject: Re: [regext] WGLC: draft-ietf-regext-org-02
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.22
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: Sun, 27 May 2018 19:23:20 -0000

On Fri, May 25, 2018, at 15:45, Antoin Verschuren wrote:
> 1. I saw the need for some registries to give organizations other than 
> the traditional Registrars and Registrants a role in the registration 
> process, but this was not limited to resellers.

But yet I am not sure to have seen a lot of registries here saying that they need this extension, or that they plan to use it...

> The discussion started because resellers were complaining that their 
> name didn’t show up in the whois for specific registrations, and 
> Registrars were complaining that Registrants of those registrations 
> would call them in stead of their reseller. Registrants simply forgot 
> who they had signed a contract with, so they looked it up in whois. 
> Registrars wanted to list their reseller in whois.

Registrars can today publish reseller data in whois. This does not need to be sent to the registry, nor to have a specific EPP extension.

This is covered I think in ICANN world by section 1.4.2 of the whois specification:

"Additional data elements can be added at the end of the text format outlined below."
So registries/registrars could be free to add reseller data today, even without any change to EPP.

And in other worlds, where there is not necessarily a registrar whois, it all depends on the registry policy to see what will in whois, and no technical change could change this policy, so again I do not see how the EPP extension helps here.

> Appart from resellers, I could see other roles in the future. Working on 
> Keyrelay, and the emerging dnsoperator-to-rrr draft, dns-operators would 
> be another organization registries might want to give special rights to, 
> for example to change NS records or roll DNSKEY material for domains 
> they were responsible for.

This is all true, probably, but how does it goes from there to "these operators need to exist as object in the registry database and be made under control of the registrars"? This sidestep many other points, like, one dns-operator for example, could be operator for domain names sponsored by registrar A and registrar B. Will both registrar A and B need to create an organization object for this same and only dns-operator organization? What exactly does this benefit to?

In a GDPR world you need more and more to be very specific about the data you collect, its use, and how you keep it. While it does not apply exactly as is here, I still fail to see why the registry database need to be populated with all this data.

And while I can understand James argument and design I think we are making things over complex without direct benefit, for what I understood the only use case applicable on the table is "storing reseller data in registry database (and maybe showing it in whois)".
For such a simple need, I think we are over-designing stuff.

Of course things would change a lot if many registries would come showing their support for this extension as it would help them for their various business needs.

-- 
  Patrick Mevzek