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

Patrick Mevzek <pm@dotandco.com> Mon, 28 May 2018 20:40 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 2B8B612E8A3 for <regext@ietfa.amsl.com>; Mon, 28 May 2018 13:40:48 -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=Rf8c4kKZ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=k9IdpzDo
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 dP8sBK0KkivC for <regext@ietfa.amsl.com>; Mon, 28 May 2018 13:40:46 -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 0B11812E89D for <regext@ietf.org>; Mon, 28 May 2018 13:40:46 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 5A24A21BF9 for <regext@ietf.org>; Mon, 28 May 2018 16:40:45 -0400 (EDT)
Received: from web3 ([10.202.2.213]) by compute3.internal (MEProxy); Mon, 28 May 2018 16:40:45 -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=CsxjxeS/FqTRIppiqH6LpBa5hBK6V Jc8lv07bstOljQ=; b=Rf8c4kKZR1lS//E5+Xnbh5qzCJ5JpWLCnOMgAYChfLg1O e3vatPwTbDwl81n+LF0mR3dwalLxrTwbns6rrbjxy4bjTnmkbO2dbA0WEKOpM9UP s7sqjsnyGTQz2Vc7qz1NK0vj/RVyvRdx+dxZnyYF9EVCKOc6xkd3PGeDbOhUuPgi gT8kI5GeSXjsA1xu1hJv2r/6u61sToQciEMNjBCN0TGuWLJ72g+rEpD8wG9EsdTH RjA6MiHeOB4UYA1bemF/hXcgJf5EGe9CMa1kX6MfsQMtYitLX0y51hNDulJKfpeV MjYypMaSbis1pmdCCcmYC4iOL5xI/U/RFgyzVWLYA==
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=Csxjxe S/FqTRIppiqH6LpBa5hBK6VJc8lv07bstOljQ=; b=k9IdpzDouMXs8y4Bcr1Bw5 Z3DLShDHIazpjV7gMyCbsUtq3GO6py1Ayp0uHXotE+IeOLY4W/IdsrvQpQqoAeW5 qACnE4omQx+h6aiKG+ve0Xyvhapxdnh+CSgeV/SA0SSNABeKnj65aDhCEpdDH0Oe 7iQN3VgyiLyPMgtitYRjboa1tfz1Vsip8Kse8LakhE7AexeaL3hIK1nruwLnkmG4 jK77U0FBeDHfJeVcaBnQSzDLnRN23mB/EN1sdT1GHlVrRlUo5+KAiMo2b1j5E49g gIamfvw+cvqtkt1SBnls8U9M3lgXMHITWuVz3QvCQARwBD0+nL0CoqZM0Av4GDqw ==
X-ME-Proxy: <xmx:TWkMW6tWScxMGGXtTUzdEoqWIGXpYC7rvaOhFXPTjEf0TDSywTHoWg>
X-ME-Proxy: <xmx:TWkMWxCFwtco1iyvFH15hwnZJZLzJdXasP4JEOzIcFNzXGXK4XPHnw>
X-ME-Proxy: <xmx:TWkMW8Hu6qOGMX1uKVFjLWYnxnBlwcLpf12sCwua_YBCvWwE_uKO5w>
X-ME-Proxy: <xmx:TWkMWxBHG8numWbPoOsyio8lCiCBHzcq7YrlMpbGVVjWiaTYRck9sA>
X-ME-Proxy: <xmx:TWkMWymjqrWHR7d7xG0EG35chP-SvUjw1CfFhEKhfSKg2nJOx8mcFw>
X-ME-Proxy: <xmx:TWkMWxHBqZfl4TpCqtRTzJ3WaxMcTrhO_Id7GW37jaljgf3QuSj_yA>
X-ME-Sender: <xms:TWkMWwXP6-zo2S0rAxxp8rMfjeznbpgUUK-CAO-OOfjAEBXueAhUQ3c1NV8>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 16B9A9E3AD; Mon, 28 May 2018 16:40:45 -0400 (EDT)
Message-Id: <1527540044.154247.1388335520.68ECC648@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-397f98d6
Date: Mon, 28 May 2018 22:40:44 +0200
In-Reply-To: <0ADC1E6A-87BF-4C27-B982-EB43FAEB4916@antoin.nl>
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> <0ADC1E6A-87BF-4C27-B982-EB43FAEB4916@antoin.nl>
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/MT7cerTNtQIcldiENuRWXnYWWLc>
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 20:40:48 -0000


On Mon, May 28, 2018, at 21:29, Antoin Verschuren wrote:
> Op 27 mei 2018, om 21:23 heeft Patrick Mevzek <pm@dotandco.com> het 
> volgende geschreven:
> 
> > 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.”
> 
> Ah yes, let’s take the solution of "we can put everything in one non-
> parseble TXT record like DNS can do too if we fail proper design and 
> really want to” ;-)
> Sorry for the sarcasm Patrick, but that one was a too open goal ;-)

I am not sure to see where in the text it says that formatted content is forbidden, can you pinpoint it to me?

Also, I fail to see how any EPP extension would have any impact here
(in the sense that: you can change what is displayed in whois irrespective to what happens on the EPP channel).

> > 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.
> 
> You forget to see that this will benefit registries that want to do the 
> right thing where they are now limited by protocol.

I asked many times who these registries are, I still fail to see broad consensus by registries to implement these extensions (I do not count silence as being "I agree" but just as "I do not care" or "I am not following these discussions, I do not know what to think about it"). Maybe they are thousands of them just anxiously waiting for this work to become an RFC (like it never happened in the past with registries implementing even core EPP documents before they became RFCs...), or maybe there are just not many of them needing all this...

Noone knows but I have my ideas in which case we are.

> It allows innovation. 

Innovations do not need RFCs, that can happen before.
This would be a separate topic.

> I’ve seen registries that want to add reseller data in 
> whois/RDAP at their registrar’s request, registries that want dns-
> operators to be able to roll their registrant’s DNSSEC keys, they want 
> to be transparent as tho which organization has extended RDAP access, 
> etc. And the registrars are still in control over who they trust with 
> these limited registry credentials, but in the end they will save costly 
> customer support and have more extended service if they automate.

Maybe. At least this is not shown by discussions here, which is sad.
Also, I am still not sure the proposed extensions solve all of these problems anyway. Especially if you take into account the drawbacks as any solution has both benefits and drawbacks, nothing is a pure win.

> We took the challenge of doing more work now, to have quicker innovation 
> later. And I see more use cases than just the reseller one.

Maybe. I am not convinced by the data proposed on the table. There may be a lot more elsewhere, but here I do not see.

Anyway, this is moot. The extensions will go forward and become an RFC and then we will be able to jauge really the interest by registries and how it is implemented...

-- 
  Patrick Mevzek