Hi, In Francisco's defence, which is nowise to suggest I think authenticated-and-differentiated access less important: On Sat, Feb 06, 2016 at 12:22:48PM -0500, Ann Hammond via gtld-tech wrote:
1. Internationalization? Ok, this is a stretch, but I'll give it to you. But it's not like internationalized characters are disallowed by whois. See, for example: whois -h whois.nic.xn--cg4bki nic.xn--cg4bki There are others.
Actually, it's not that i18n is disallowed or allowed by whois. It's that the whois protocol is _completely broken_ for this, because it has no way to negotiate anything. With whois, you connect on port 43, send something, and get something vomited back. It's probably ASCII, but no promises. That's the whole protocol. That we are still using whois even a little ought to embarrass us all.
2. Standardized query/response/errrors? Again, a stretch. 301, 302, 404, 429... big deal. Anyway, AWIP and CNRA have tried to do the first two.
For machine-to-machine communication, this is a very big deal. And it's not only response codes. You also get JSON objects as opposed to structured text, so the entire result is machine parseable. This was squarely in our sights as a goal when we got the WEIRDS BoF going, and I think it's a successful part of the RDAP design. (Of course, this very machine-parsability is what has so many of us worried that there are unseen opportunities for data leakage without authenticated differential access. I think so far we've not demonstrated such a leak, but that doesn't mean there isn't one.)
3. Ahem... extensibility? Really? Anyone wishing to support anything beyond the profile must undergo the dreaded RSEP, effectively muting this benefit.
The ability is certainly there, though I must concede that an ability that can't be exercised for contractual reasons is perhaps somewhat less useful. Let us hope the PDP is successful!
4. HTTPS? That's more important than authenticated/differentiated access? Who is clamoring for this? Nobody!
I am. Lookups by innocent parties of registration data should no more be trivially observable on the network than anything else. Encrypt it all.
5. Standardized bootstrapping? New gTLDs must all support whois.nic.<tld>
To me, the bootstrapping's sort of a kludge anyway. I would have liked something more flexible and more in keeping with the extensibility, for greater use down the tree, but I was in the rough in the working group.
6. Standardized redirection for thin? There are three thin registries: com, net, tv. All provide the reference to registrar with the same key "whois server:"
The point is that rwhois hasn't been that reliable, and RDAP solves this.
7. Flexibility to support various policies? Okay, maybe someone at ICANN cares a lot about this, but few in the community care, especially given #3 above.
I cared quite a lot about this when WEIRDS was going, but the IANA-based bootstrapping and the tight contractual control makes this feature rather less interesting.
I get the impression of ICANN internal pressure to force-feed the community RDAP to meet a date, rather than a desire to put forth a noteworthy advancement in RDDS. Rather than dictate compliance with a profile that *seems* a product of ICANN's doing, rather than a grass-roots initiative, why doesn't ICANN invest effort in coordinating a solution to the obvious need for authenticated/differentiated access?
I think Francisco's point is that ICANN is doing that co-ordination, but under a PDP; and therefore changes can't be made now. The argument I made before, and still think is true, is that standing up a mandatory profile for contracted parties that contained all the protocol features would mean lower barriers to deployment later. I think ICANN's staff disagree. I think informed people of good will can disagree about this; and in any case I have learned that they have a couple of regular consensus-policy deployment windows a year, which means at least that we can have specific targets. I'd still prefer my approach, though :)
And, if ICANN wishes to dictate something useful, federated authentication amongst registries would be a good start. Better yet, ICANN could be the authenticator - THAT would be useful.
I think Scott has already suggested using the federated-authentication stuff in http(s) to do some auth-provider work. ICANN's ability to authenticate a large number of some kinds of client would indeed seem to be a valuable contribution to that development/PoC effort. Best regards, A -- Andrew Sullivan Dyn asullivan@dyn.com