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

Hi Jay,

I'm not sure I understand your conclusion. Why do you think this
running system should not be documented in an RFC?

If it was a private-use protocol being used for private purposes, I
could see what you're getting at. However, it's neither: it's a
protocol in use between different organisations being used to support
an aspect of public infrastructure (the reverse DNS trees).

I don't agree that there's nothing to be gained by documenting it (I
realise that's not exactly what you wrote, but it could be read that
way) and to me, the RFC series is a plausible place for that to
happen.

What am I missing?

(ObDisclaimer: Terry and I work together, but this is a personal
perspective; he's big and ugly enough to fight his own battles :-)

Joe

Aue Te Ariki! He toki ki roto taku mahuna!

On 2013-08-12, at 18:06, Jay Daley <jay@nzrs.net.nz> 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
>
>
> 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: +64 4 931 6977
> mobile: +64 21 678840
> linkedin: www.linkedin.com/in/jaydaley
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop