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

"Gould, James" <jgould@verisign.com> Mon, 28 May 2018 13:00 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 1E99C127909 for <regext@ietfa.amsl.com>; Mon, 28 May 2018 06:00:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnN0w0Ak6UXV for <regext@ietfa.amsl.com>; Mon, 28 May 2018 06:00:19 -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 CF4F11271FD for <regext@ietf.org>; Mon, 28 May 2018 06:00:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=4819; q=dns/txt; s=VRSN; t=1527512419; h=from:to:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=X1v4MBQW4mV95HY9HegRBJkCWtRlhd6f/gtuBsnnsRI=; b=aUO10zSQVhj24QmBNwEQuJcZr9Rn7CqvT+n4rp59LHSnbdUm5juG4QUH kkPM54gSFefVul3aAXbSCO/LkFZ6jHE2eU3ERlBxJ/hsyLd5lyIbp/QN9 CXkeD+XAr40AjMQLN1/qXfHsP8MMBrAK1kaKKFoyC/gCoGWdhYXySvJg4 jC25eX0NnKUc6Opy0cWfUoX/XxTqiedUAwq2dr5WkvnqipC0Rh8RLuiKX HB2D5Y1sH0qpiHYyhyLszZaP85ddWSjC5U3n7tIvuED0TeNYJq/s0X0oy MTJovKw3hzPNoJojayxonpJRLj+r0h5XI7Q/0teA/yhefumlpXulFuQk9 Q==;
X-IronPort-AV: E=Sophos;i="5.49,452,1520899200"; d="scan'208";a="4796487"
IronPort-PHdr: 9a23:c0qrMB3UDdkpBC32smDT+DRfVm0co7zxezQtwd8ZseIfKfad9pjvdHbS+e9qxAeQG9mDsLQc06L/iOPJYSQ4+5GPsXQPItRndiQuroEopTEmG9OPEkbhLfTnPGQQFcVGU0J5rTngaRAGUMnxaEfPrXKs8DUcBgvwNRZvJuTyB4Xek9m72/q99pHPbQhEniaxba9vJxiqsAvdsdUbj5F/Iagr0BvJpXVIe+VSxWx2IF+Yggjx6MSt8pN96ipco/0u+dJOXqX8ZKQ4UKdXDC86PGAv5c3krgfMQA2S7XYBSGoWkx5IAw/Y7BHmW5r6ryX3uvZh1CScIMb7Vq4/Vyi84Kh3SR/okCYHOCA/8GHLkcx7kaZXrAu8qxBj34LYZYeYP+d8cKzAZ9MXXWpPUNhMWSxdDI2ybIUPAOgAPelEoIfyqEADrQenBQSoGO/j1iNEi3/w0KYn0+ohCwbG3Ak4Et4AsXrUq8j1NKMPXuyt0aLGyS/Mb/ZI1jfm5oTDbxcsofODXbJ3bMrRzVQgGhjbjlqOs4zlPiiV1uUCs2id9eZvSeWvi2s+pgx3vzOhyMAsiozTiYIUzFDJ7SR5z5gpJd22UkJ7ZsSkEJRWuiqHNIV2WtsvT3x0tCog17ELu5C2cDIXxJknyRPTcfOKfouO7xn+TuieOy14i2hgeL+nghay9lWvxfPkW8mv1VZKsjJFkt7RtnARzxDT6taISv96/kq5xDuByxjd5vxELk4smqTUKoItzqMqmpoNrUvDGTX2mF3sgKCMa0oo4Pao6/78YrXgvJOTK4h0igTmPqQvnMywH/g4PxATU2SH4+iwyb/u8EPjTLlXjvA7nLPVvZ/ZKMgDo662GQ5V0oIt6xalCDem1cwVnXsILFJCZRKHi5XmNkrQIP/mF/e/gk+skDZkx/DAJLHuHpLNLn3bnLf7Ybl981JcyBY0zd1H/5JUD6oML+/0Wk/trtPYCAI2PBCzw+r9FNp90YYeU3qVAqCFKKPSrUOI5uU3LumWeoAVtyjyKvc55/P1jH82h0Mdfaez0ZsQcnC4EacuH0LMWXPwmNYKEi8vsxQsQe+i3EWHeTJUe3+0U6k7oDo8DdTiRc3ZS4+gkKCp3SqnENtRfG8MQgSWHHjlZ5msWvoQZmSVOMA3wRIeUr30AaAmyBWi8EfYwr9qNaCcri8Xso/n2PBr6vfSjhA983p/CMHLgDLFdH19gm5dH2x+56t4u0Eojw7biaU=
X-IPAS-Result: A2H3AgDE/Atb/zCZrQpcHAEBAQQBAQoBAYQmgScKmlSBD5UsBwsYCwuDeEYCgjE3FQECAQEBAQEBAgEBAoEEDII1JAEOLxwvAQEBAQEBUAJELAEBAQECAQEBbBALAgEIDgMEAQEBCiQnCx0IAgQBEggTgwmBdxenFYg9gWMFCQGKAT6BD4MNgxEBAYE5KYMugiQCjCqMOAMGAptkiWqGegICAgIEBQIUgVdjgRJwFTuCQ4sQhT5vjW+BLoEZAQE
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_128_GCM_SHA256) id 15.1.1466.3; Mon, 28 May 2018 09:00:17 -0400
Received: from BRN1WNEXCAS02.vcorp.ad.vrsn.com (10.173.152.206) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1466.3 via Frontend Transport; Mon, 28 May 2018 09:00:17 -0400
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0301.000; Mon, 28 May 2018 09:00:17 -0400
From: "Gould, James" <jgould@verisign.com>
To: Patrick Mevzek <pm@dotandco.com>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-org-02
Thread-Index: AQHT6SxtFmwLJhW10Uq7HDW8W/3T1aQ51aEAgAHPawCAAeAogIABMAIAgABSC4D//+01gIAB2XgAgAODG4CAAOI+QA==
Date: Mon, 28 May 2018 13:00:16 +0000
Message-ID: <C41D7AF7FCECBE44940E9477E8E70D7A80FB20F5@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
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>, <1527448997.1643063.1387308680.73816387@webmail.messagingengine.com>
In-Reply-To: <1527448997.1643063.1387308680.73816387@webmail.messagingengine.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.173.153.48]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/KjK_fhB8B0zXrjooA4QFrbBwxT8>
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: Mon, 28 May 2018 13:00:22 -0000

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

The different design options were discussed at IETF 98, where a targeted solution for resellers is certainly simpler than supporting a generic organization.  The direction from the working group was to support the more generic and complex organization.  I believe the two use cases that have value now is the reseller use case and the registrar use case.  The registrar information should be available directly available from with EPP instead of having to use WHOIS / RDAP.  I see having a generic organization object and extension as being a better solution than attempting to create role-specific objects and extensions for reseller, registrar, and other organization types that come up in the future.  

Jim

________________________________________
From: regext [regext-bounces@ietf.org] on behalf of Patrick Mevzek [pm@dotandco.com]
Sent: Sunday, May 27, 2018 3:23 PM
To: regext@ietf.org
Subject: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-org-02

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

_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext