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

[Terry Manderson <[e-mail]>]

Hi Jay,

I'll try to answer your questions, but the intent was to solicit reviews
for the RFC-ISE. If you would like to be a reviewer in that direction
please do so!

On 13/08/13 8:05 AM, "Jay Daley" <[e-mail]> wrote:

>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

While it's nice to assume that everyone should use some particular
protocol for a solution, sometimes business desires overtake any
particular technical position.

EPP was considered, and this document should not be "why we didn't use
EPP", but the end consideration was that the objects in question did not
fall into the classical registry/registrar approach as the rights of
assignment of the overarching objects (the IP address blocks) fall in a
process and policy that sits on a level well above the provisioning of
DNSSEC records.

Also EPP, while extensible, was also considered waaaaaay to heavy for the
slim function that was being targeted.

>
>
>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.

Correct, the service is a RESTFUL application, and with that the HTTP
error codes are considered the most atomic feature, and the item that
should be passed back first and foremost.

>
>
>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.

"too tightly"? I think "intended". :-)

While it is possible to abstract such items in the XML, the underlying
statement is that this system will not (ever) operate on anything other
than HTTPS.

It's also note worthy that the HTTP method describes precisely the
operation undertaken.

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

Yes. The RDATA is one part I was never really super-duper ecstatic about.
But it stuck.
(perfect was the enemy of good)

>
>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.

I think, Jay, you might be one step removed from what the problem was. It
wasn't "how can we use EPP here", nor was it "how can we use REST there".

In terms of a candidate becoming an RFC, please cast your eyes over
http://www.rfc-editor.org/indsubs.html and if you still feel that way,
drop me a personal note and we can discuss why/why-not offline.

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

The system is implemented, it has been for a number of years, and operates
precisely as designed.
Should someone, amongst the 'customers' of the system, request ICANN to
make this system EPP and provide good reason - then I will certainly put
you on the top on my "to call" list.

Cheers
Terry