Subject: [weirds] Interop report

From: Simon Perreault <[email-masked]>
Date: Thu, 01 Aug 2013 15:48:55 +0200

All,

Here's the interop report in email form, since we didn't have time for a 
live form. The slides form is still here:
http://tools.ietf.org/agenda/87/slides/slides-87-weirds-2.pdf

We had an interoperability testing session on Saturday afternoon. 
Attendance was composed of:

- 8 servers, of which...
	... 5 were "number" servers
	... 2 were "name" servers
	... 1 was a redirect server
- 1 client
- 1 test suite (acting as a client) targeting servers

We ran a survey to know what features were implemented. The features 
_not_ implemented by _most_ implementations were:

draft-ietf-weirds-json-response:
	5.4 lang
draft-ietf-weirds-using-http
	5.2 302 Response with Location:
	5.2 303 Response with Location:
	5.2 307 Response with Location:
	5.5 429 Response
	5.6 Access-Control-Allow-Origin Header
	9.3 Return Content-language Header

Features _not_ implemented by _some_ implementations were:
(some features here are not listed because they are specific for one 
kind of registry (i.e. addresses vs domains))

draft-ietf-weirds-rdap-query
	3.4 /nameserver/<idn a-label>
	3.4 /nameserver/<idn u-label>
	3.6 /help
draft-ietf-weirds-json-response:
	5.3 remarks
	5.6 status
	5.7 port43
	5.8 public id
	6.2.1 secureDNS dsData
	6.2.2 secureDNS keyData

Immediate results of the interop test were:

- We discovered at least 39 issues in implementations. Many were fixed 
on the spot.

- We identified a few questions about the specs.

Question #1: Double Slashes

Should double slashes be allowed? Consider these two examples:

A) http://example.com//ip/1.2.3.4/32
B) http://example.com/ip/1.2.3.4//32

A) looks like it should be allowed, based on common practice. Double 
slashes have commonly been allowed since HTTP servers serving files from 
a Unix-like filesystem don't care about double slashes. However, B) 
looks like it should not be allowed, based on CIDR notation syntax. 
Since we don't see any value in allowing double slashes, we propose to 
explicitly disallow them, and we propose to add text to that effect in 
the query draft.

Question #2: Authentication

How can we return different content depending on whether auth is used or 
not? For example, a domain name registry may want to return basic 
information when authentication is not used, whereas using 
authentication would allow one to also obtain personal contact 
information for a domain name. We want to use HTTP auth for that, but 
the problem is that HTTP auth is triggered by unauthorized access. So 
you can't use the same URL for authorized and unauthorized access.

One proposal discussed during the interop meeting would be to add an 
"auth=<token>" query parameter. The token would identify the clearance 
level, and would be registry-specific. For example, a registry could 
define an "auth=registrar" clearance level allowing their registrars to 
access restricted information. It would be appropriate to have the WG 
view on the proposal.

The feedback from implementers was that it would be good to redo this at 
the next IETF (Vancouver). Given that implementations will be more 
mature, that specs will change, and that the test suite will evolve with 
more comprehensive coverage, this makes a lot of sense. So we plan to do 
it again in Vancouver, and we plan to start testing features higher up 
the stack: IDN support, jCard support, etc.

Simon and Marc
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca