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

"Hollenbeck, Scott" <> Thu, 08 October 2015 13:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A5D121B33CE for <>; Thu, 8 Oct 2015 06:30:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9j-QIUUBeCxt for <>; Thu, 8 Oct 2015 06:30:06 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4E4AC1B33A3 for <>; Thu, 8 Oct 2015 06:30:06 -0700 (PDT)
Received: by qgev79 with SMTP id v79so3354430qge.3 for <>; Thu, 08 Oct 2015 06:30:05 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:accept-language:content-language:content-type :content-transfer-encoding:mime-version; bh=uPiMS7IQ9ciartpRFFllbEgPEYmRf1LQWt0Rmcx6pq8=; b=M1eF5xQAbBRADKg9vsc+2tTet4Q88Q5rTzFg21a2AEfQlk4SXlG8IEg8V5tYtyca8F WEsdfMVvJ59I7MIK4pThhlz8V5S9KgyvaAC5RL0voIYlmnA+Zd7dbnta8zrgg4F0iz1p gI4EH6+6FXbijneTDxqDrW8jJpjAXKfFc9Hfp/qmRiNYUVCZb1+Rz3pHAW/VuVsyGHYQ XRiKSl30qHzRKN7FyMc1sWrYBIlm8RHmFr9M/O7pgsrZyk6ye0LH+rG6F6YSE3HlVwUk 3nkWtklsXzj3jb31QXzTCCsGW+SeKSrSkVysW+h44k1a6KekIku43sONGoTPoJhEc8mO ZvWw==
X-Gm-Message-State: ALoCoQklvrj+20w2XB9lwaWZ0LfLQ6TvZQFsy6qnlL70W4UQFIJjOnQzNvCHxOWZgezVUOx35p82o3f6sv/g0vp/CYdGLIvYrg==
X-Received: by with SMTP id w75mr8119370qha.86.1444311005445; Thu, 08 Oct 2015 06:30:05 -0700 (PDT)
Received: from ( []) by with ESMTPS id s27sm259908qkl.12.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 08 Oct 2015 06:30:05 -0700 (PDT)
Received: from (brn1wnexcas01 []) by (8.13.8/8.13.8) with ESMTP id t98DU4b6020070 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 Oct 2015 09:30:05 -0400
Received: from ([::1]) by ([::1]) with mapi id 14.03.0174.001; Thu, 8 Oct 2015 09:30:04 -0400
From: "Hollenbeck, Scott" <>
To: Greg Aaron <>, "'Gustavo Lozano'" <>, =?iso-8859-1?Q?=27Patrik_Wallstr=F6m=27?= <>
Thread-Topic: [gtld-tech] [eppext] RDAP server of the registry
Thread-Index: AdEBzXAixTID8a2GTdq8YXRD5ouAwA==
Date: Thu, 8 Oct 2015 13:30:04 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, "" <>
Subject: Re: [eppext] [gtld-tech] RDAP server of the registry
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: EPPEXT <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 08 Oct 2015 13:30:08 -0000

> -----Original Message-----
> From: Greg Aaron []
> Sent: Wednesday, October 07, 2015 11:27 AM
> To: 'Gustavo Lozano'; 'Patrik Wallström'; Hollenbeck, Scott
> Cc:;
> Subject: RE: [gtld-tech] [eppext] RDAP server of the registry
> Gustavo correctly notes some important things --ICANN has contractual
> requirements that tell registries and registrars what data they MUST
> deliver
> (currently via the WHOIS protocol), and ICANN is now working on how
> that
> data should be delivered via RDAP.   Whatever document is created is
> going
> to be binding on registries and registrars.  As per the 2013 RAA, once
> spec is mature "ICANN reserves the right to specify alternative formats
> and
> protocols, and upon such specification, the Registrar will implement
> such
> alternative specification as soon as reasonably practicable."  The new
> gTLD
> registry agreements contain similar.
> RDAP's supposedly been designed to deliver what ICANN might require of
> its
> registrars and registries.  If so, we are embarking on an exercise in
> implementation in the gTLD world, with ICANN as the policy authority.
> BCPs
> for ccTLDs etc. might be nice, but seem like a distraction from the
> immediate task at hand.

Thinking about the best way to implement RDAP is no distraction. It will help reduce implementation costs *and* ensure that we deliver the best technical solutions in the long run. Remember, the agreements you mentioned above were written before the RDAP specifications were completed. There are features in RDAP that aren't mentioned in the agreements or the proposed profile. There are ongoing policy efforts in ICANN that *will* have an impact on RDAP implementers. I'm suggesting that we need to take a big picture approach before we're told to implement current WHOIS operational requirements with RDAP as a transport. That just makes RDAP part of the ongoing problems.

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?

> The implementation requirements should certainly be well-thought-out,
> should
> receive input (and hopefully collegial buy-in) from the parties who
> will
> have to make it work, and should be clearly documented.  As Gustavo
> says,
> ICANN has process to deliver that.  Requiring "community consensus"
> about
> the contents, as Scott suggested, is a different and higher standard
> from
> what has been agreed to in the ICANN contracts.

I'm not a lawyer, so contracts aren't my area of expertise. I do, however, know something about software engineering and the costs associated with software development. Knowing that the new gTLD RA says this:

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