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

[Hollenbeck, Scott]

> -----Original Message-----
> From: Greg Aaron [mailto:greg at illumintel.com]
> Sent: Wednesday, October 07, 2015 11:27 AM
> To: 'Gustavo Lozano'; 'Patrik Wallström'; Hollenbeck, Scott
> Cc: gtld-tech at icann.org; eppext at ietf.org
> 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
> RDAP
> 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.

Scott