[DNSOP] Review of draft-manderson-rdns-xml-01

[Jay Daley <[e-mail]>]

Firstly, just to confirm that I've read the previous email from Terry Manderson that this draft was published more for reasons of transparency and starting a conversation than anything else.  So here are my comments in light of that:

1.  There were a number of places in this draft where I found myself asking "why didn't they just use EPP?".  For example:

- it's a registry provisioning protocol
- it's a registry provisioning protocol for NS and DS records!
- it has a feature for requests to be queued and a message list to be polled


2.  Unless I'm being dumb (and my RelaxNG is not very good) I can't see any definition of either

- responses to non-queued requests
- errors

other than the implicit standard HTTP response/error codes.


3.  It's too tightly bound to the underlying HTTP interface.  The response/errors is one example, another is the queue element field:

# The HTTP method used to update
       attribute method { "PUT" | "DELETE" },

That would be better as a logical operation code (i.e. Add, Delete) that were mapped onto HTTP operations. 

4.  Some of the key data elements that need to be provisioning are defined the most loosely - name the rdata field.

So overall I'm pretty surprised that this path was chosen in 2011 rather than EPP which the rest of the known universe uses for this sort of thing.  I realise ICANN is very much taken with lightweight REST but this seems to be forcing the solution onto every problem, even then solved ones.  However, this is indeed ICANN's choice, it is a trivial protocol and is working in production.  But what it isn't is a candidate for becoming an RFC.

If the authors are interested in doing this in EPP then I would be willing to help.

cheers
Jay

-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: [phone]
mobile: [phone]
linkedin: www.linkedin.com/in/jaydaley