On Wed, Jan 13, 2016 at 05:05:11PM -0800, David Conrad wrote:
a) The proposed operational profile supports the use of tiered access (if, of course, your RDAP server has the code to do it)
Except that, if you're an operator of this code, you're not allowed to use that access unless you get a contractual waiver. So, if you're the development department responsible for this, you have three options: 1. Get legal involved. I hope I don't need to explain to anyone in the technical end of ICANN how desirable that is. 2. Build a piece of functionality and release it in the hopes that your test code actually covered everything everyone might do. 2.1. Later, when whatever new profile with the new rules is released, recall the developers to fix such bugs as show up, with possibly months or years in between when they implemented the bug and when they get to fix it. This is all assuming the same developers are available. 3. Just ignore the desired functionality until such time as the PDP (assuming it completes, which at least in this case seems possible) finishes _and_ the new profile shows up with whatever capabilities specified, and then implement that. (1), of course, is no guarantee that you won't need to do the latter half of (3) anyway, but let's pretend otherwise. (2) is the sort of thing that gets you fired as a program manager. (3) amounts to "do it twice". In contrast to all of this is the outline I sent, any variant of which would allow ICANN to specify now roughly any combination of fields as falling under some tier of differentiation. This has the conspicuous advantage that it provides running-code information to the PDP such that people there know what actually could work or not (a piece of information that, as nearly as I can tell, could benefit many PDPs). It simultaneously gives everyone experience with variable operational profiles before there is any policy requiring correct specification and implementation, which means that we can run various experiments and trials against real servers when we hear about things people want without a lot of deadline pressure. But if we're not to take that approach, why should bueinsses ever have to think about RDAP twice? It creates an implementation burden of a new protocol for practically no benefit to anyone. If mere machine-readability of output were the only desideratum, then we've already run the experiment to find out whether people want that (with IRIS), and the answer was no. The i18n goals are effectively already solved via the required web whois. What is the goal of implementing RDAP quickly without even the capability of differentiated access, except to check off a tick-box on someone's list of stuff to do? I'm myself very much in favour of RDAP implementation, but it's awful hard to justify any effort on this early requirement without any apparent benefit. I can imagine that an interpretation by ICANN that additional functionality that implemented differentiated access -- functionaliry not deemed part of the production service, but that is somehow offered alongside on a best-efforts, experimental basis, and that is not strictly part of the profile -- would go a long way to eliminating this objection. It's hard anyway to see how that would be a registry service as such, since it wouldn't affect any users who didn't want to play in the sandbox and wouldn't be necessary for anyone. The goal of early delivery of RDAP with a universal single-tier interface would be achieved, the PDP would get information probably useful to its work, and nobody would be inconvenienced since the service wouldn't actually make any promises. Best regards, A -- Andrew Sullivan Dyn asullivan@dyn.com