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

[Jay Daley <[e-mail]>]

On 13/08/2013, at 10:57 AM, Joe Abley <[e-mail]> wrote:

> 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'm not sure how you can describe this as anything other than a private protocol. Yes it is part of the public infrastructure but then there are a myriad of private EPP extensions out there that also work on the public infrastructure and yet would equally not be suitable for an RFC.  So I don't think the 'public infrastructure' argument holds water.

For it to be an RFC I would hope that meets a decent threshold, namely:

1.  there is at least some sense of architectural positioning in relation to other protocols.  This draft doesn't have that as it seems to do a small part of an otherwise perfectly good protocol, EPP, without any reference/recognition of how the two fit together.

2.  there is a relatively clean separation of layers.  This is not the case with this draft as it tightly binds onto HTTP.

3.  it is a public protocol.  For this to be a public protocol the rules are pretty clear - two implementations in different contexts.  AFAICT this has only one server implementation and multiple clients in the same context.

While 2. can be fixed I'm not sure 1. and 3. can be.

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

There is every benefit to this being documented, I am glad that it is and would not wish that to change.  However using the  RFC process for a private protocol is inappropriate and it would be better if there was a web site had a section that documented all the ICANN private protocols, in much the same way many TLD operators do.

> What am I missing?

I really do not mean to cause any offence by this so apologies in advance if I do, but is this a case of ICANN mistaking its position here?  Yes you are the excellent operator of a key part of the public infrastructure but that doesn't mean that every protocol you develop related to your technical function automatically becomes an RFC when documented to a sufficient standard.

cheers
Jay



> 
> (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 <[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
>> 
>> 
>> 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
>> 
>> _______________________________________________
>> DNSOP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnsop
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop


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