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

[Jay Daley <[e-mail]>]

Hi Terry

For most of the things that we disagree about I'll just leave it there, but I would like to correct what I think are misconceptions about EPP:

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

EPP is used extensively in scenarios where the request is queued and processed offline by a higher order process that determines rights to the resource.  It was designed with that in mind.

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

I would be interested to know what you think is heavy about EPP?

I've heard it said that EPP is heavy because of the use of a schema to define the message format, but then your draft also does.  I've also heard it said that EPP is heavy because it uses XML but again your draft does that.

At its core EPP is a simple set of verbs that can carry any data payload.  Your application clearly doesn't need the data that would come in the standard domain name payload or all the verbs but it is easy to define a new payload format that has just the data you need and the verbs you want.   This would then be as short as your relaxNG but much cleaner in terms of separation of layers and better supported by libraries and the wider registry community.

cheers
Jay

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