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