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

Antoin Verschuren <ietf@antoin.nl> Wed, 30 May 2018 20:24 UTC

Return-Path: <ietf@antoin.nl>
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 832DE12DA42 for <regext@ietfa.amsl.com>; Wed, 30 May 2018 13:24:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=antoin.nl
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 yfPrxG6hwhm6 for <regext@ietfa.amsl.com>; Wed, 30 May 2018 13:24:56 -0700 (PDT)
Received: from walhalla.antoin.nl (walhalla.antoin.nl [62.251.108.8]) (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 AE68112D7E6 for <regext@ietf.org>; Wed, 30 May 2018 13:24:55 -0700 (PDT)
Received: from [IPv6:2001:985:b3c0:1:462a:60ff:fef4:e7f2] (unknown [IPv6:2001:985:b3c0:1:462a:60ff:fef4:e7f2]) by walhalla.antoin.nl (Postfix) with ESMTPSA id 760C4280358; Wed, 30 May 2018 22:24:53 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=antoin.nl; s=walhalla; t=1527711893; bh=sKxp7AW0IaK6RIt4VNJlH+vT4Di/kVR36qso8250SqM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=Tp97Yx9SHB60zBCci+TsnCXWcR+3MllzAVtMGjSgyn04gELVdY3oUfANI+53RDNli tJdeB3bxsHHKace6M1jSe2cdfnPjVXuorQD3gzJJJbmqBiiWsBqVIgkiMWTBTYTSAK S04CL/3MF1WheswEx3Jk6H4AJe24+pBxaPkRSaLA=
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_A9ADCC95-F1D4-40BA-8EAC-B368C62C1A19"; protocol="application/pgp-signature"; micalg="pgp-sha256"
X-Pgp-Agent: GPGMail
From: Antoin Verschuren <ietf@antoin.nl>
In-Reply-To: <1527540505.157331.1388343424.0B8EF8F3@webmail.messagingengine.com>
Date: Wed, 30 May 2018 22:24:17 +0200
Cc: regext@ietf.org
Message-Id: <B657C814-1385-4059-B118-2FAC01523470@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> <1527540044.154247.1388335520.68ECC648@webmail.messagingengine.com> <1527540505.157331.1388343424.0B8EF8F3@webmail.messagingengine.com>
To: Patrick Mevzek <pm@dotandco.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/xBCM4oDAj9SGT1P6onsp25AIyc8>
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: Wed, 30 May 2018 20:24:59 -0000

Op 28 mei 2018, om 22:48 heeft Patrick Mevzek <pm@dotandco.com> het volgende geschreven:

> In your quote you missed the other part which is basically: all domain names are not under ICANN policies.

I didn’t want to go in that discussion, but I’m on your side on that one.

> So for all other TLDs currently can you let me know which protocol limitations currently forbid registry to add formatted content in their whois or, let us say just decide to implement RDAP to start with? Do you really think there are almost none because of protocol limitations, especially in the EPP channel, or maybe for other reasons?

Perhaps it’s not only protocol limitations, or perhaps limitation the wrong word, it’s more the pinpointed ICANN RRR model I think that can only be provisioned for now.
I remember a CENTR meeting where ccTLD’s tried to get consensus over if we could harmonize EPP extensions so registrars would not have to code differently for every TLD.
This was before EPPEXT existed.
We all thought this would be a good idea.
But half the registries concluded that they wanted to stick to their own extensions because they felt local legislation or their local constituencies required them so, and the other half had the standpoint that they would only implement as followers, after extensions would be standardized.

Again Patrick, I share your concern of complexity, and we shouldn’t build something nobody uses.
I also shared your concern for double labeling both at the organization and link level, but James managed to convince me it’s a choice between two bad’s where the responsibility of registrars over records they maintain outscores double entries in the database for organizations that do anything for anybody.

The reseller draft was originally requested and supported by cnnic, sidn and dns belgium who also had the intend to implement. If not this standard then their own extension.
Other registries didn’t immediately acknowledge the need for resellers unless mandated by (ICANN) policy, but there was consensus that if we were to standardize something to accommodate resellers, it should be reusable for other emerging "Internet identifier registration related roles" as well. This was not only TLD registries that had an opinion, and I remember some hesitation especially by ICANN registrars as well because they didn't want extra work, but third party dns-operators, ICANN related policy makers, RIR’s, registrants and plain IETF protocol guardians also have an equal voice in the IETF process, even though they don’t implement.


- --
Antoin Verschuren

Tweevoren 6, 5672 SB Nuenen, NL
M: +31 6 37682392