Re: [eppext] [gtld-tech] RDAP server of the registry

Marc Groeneweg <Marc.Groeneweg@sidn.nl> Fri, 09 October 2015 08:48 UTC

Return-Path: <Marc.Groeneweg@sidn.nl>
X-Original-To: eppext@ietfa.amsl.com
Delivered-To: eppext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D13551A899B for <eppext@ietfa.amsl.com>; Fri, 9 Oct 2015 01:48:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.084
X-Spam-Level:
X-Spam-Status: No, score=0.084 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 DASQP5BAOQB0 for <eppext@ietfa.amsl.com>; Fri, 9 Oct 2015 01:48:33 -0700 (PDT)
Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F6861A89A1 for <eppext@ietf.org>; Fri, 9 Oct 2015 01:48:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn-nl; c=relaxed/relaxed; h=from:to:cc:subject:thread-topic:thread-index:date:message-id:references:in-reply-to:accept-language:content-language:x-ms-has-attach:x-ms-tnef-correlator:x-originating-ip:content-type:content-transfer-encoding:mime-version; bh=B8oEeRmI3rVSe9qkIgpzBXoUNjGVoej5UMwzh0bFZI4=; b=LZJ7yFbyxXuZnA26qVGQcGj10NZ3pMfh74jFcTgXuuwoskF/kyuHgIPxTRhYxbHKf3Ck+j1J6hGJfygUeOq8bWC1qmzeZ3o55OVdgHoCl+P7TuQIh+FHxg/fnAbSYM4BhU6Criw6IX5JYu6bVnCwqbrnEXfKa02LZNKXvBCgRUisQyeu0MIZHgkk5pDm5adWTQ65x4jsoy8gVADGP2bMM/eqEzCrHV74bNcnZYpcj/A44Z1K73zUdHlMpJ0jiHzJot/n6ZHozB13M1Lb0E2PqZI9+4SGsbzwOikm6RWHgm7wzyrw46+SQ0KIdAr9km8yfvzu5wTWLkStah9JdgK5fw==
Received: from ka-mbx01.SIDN.local ([192.168.2.177]) by arn2-kamx.sidn.nl with ESMTP id t998m9TU016836-t998m9TW016836 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL); Fri, 9 Oct 2015 10:48:09 +0200
Received: from KAHUBCASN02.SIDN.local (192.168.2.74) by ka-mbx01.SIDN.local (192.168.2.177) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 9 Oct 2015 10:48:11 +0200
Received: from KAMBX1.SIDN.local ([fe80::501d:affc:30a9:4edf]) by kahubcasn02 ([192.168.2.74]) with mapi id 14.03.0224.002; Fri, 9 Oct 2015 10:48:10 +0200
From: Marc Groeneweg <Marc.Groeneweg@sidn.nl>
To: "eppext@ietf.org" <eppext@ietf.org>
Thread-Topic: [eppext] [gtld-tech] RDAP server of the registry
Thread-Index: AdEBzXAiq/T/KKd3IEKmeNlNL/dP/QAoPfdA
Date: Fri, 9 Oct 2015 08:48:11 +0000
Message-ID: <5BFD186DCB661E4D951017B0818285AEDE7CAF58@kambx1.SIDN.local>
References: <831693C2CDA2E849A7D7A712B24E257F4A0ACE1C@BRN1WNEXMBX02.vcorp.ad.vrsn.com>
In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F4A0ACE1C@BRN1WNEXMBX02.vcorp.ad.vrsn.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.2.171]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/ZIW5I05CbhjK2MPH0QTwxwMDc1Y>
Cc: "gtld-tech@icann.org" <gtld-tech@icann.org>
Subject: Re: [eppext] [gtld-tech] RDAP server of the registry
X-BeenThere: eppext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: EPPEXT <eppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eppext>, <mailto:eppext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/eppext/>
List-Post: <mailto:eppext@ietf.org>
List-Help: <mailto:eppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eppext>, <mailto:eppext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Oct 2015 08:48:38 -0000

Scott, etal.

>Here's one example: data privacy. WHOIS can't do it, but RDAP can, and it's not part of the profile. 
>Shouldn't it be part of the discussion? Why shouldn't we think about it before we perpetuate a 
>WHOIS issue that becomes an RDAP issue?
Agreed. And data privacy has given us sufficient discussion on the provreg mailinglist in the past :-)

>"Registry Operator shall implement a new standard supporting access to domain name registration data
> ... if ... its implementation is commercially reasonable in the context of the overall operation of the registry."
>
>How does one determine that which is "commercially reasonable"? We know that there are policy 
>development efforts happening in parallel that will produce additional implementation requirements.
> Requirements that conflict with the profile (changes in data privacy requirements, for example) will increase
> implementation costs, and "commercially reasonable" becomes a point of contention. The process I've 
>described should help mitigate that risk. It's not a higher standard, it's a method that can be used to help 
>confirm that the "commercially reasonable" requirement has been met.
I have found this a brilliant escape in not doing RDAP for gTLD's. All investments with respect to new gTLD's
can be considered not "commercially reasonable". Unless a strong business case evolves surrounding the
B2B model using RDAP as a stepping stone in new domain registrations. But alas, I am only technical inclined,
not commercially.

Reagrds,
Marc