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

From: Jay Daley <[email-masked]>
Date: Tue, 13 Aug 2013 10:05:59 +1200

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

---

From: Joe Abley <[email-masked]>
Date: Mon, 12 Aug 2013 18:57:58 -0400

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 <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Jay Daley <[email-masked]>
Date: Tue, 13 Aug 2013 11:28:41 +1200

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

> way) and to me, the RFC series is a plausible place for that to

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

---

From: Terry Manderson <[email-masked]>
Date: Mon, 12 Aug 2013 16:59:20 -0700

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" <[email-masked]> 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:
>

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.

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

"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

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

---

From: George Michaelson <[email-masked]>
Date: Tue, 13 Aug 2013 10:04:20 +1000

My personal view, from deep time, is that this protocol was offered into
the process facing upwards, as a result of an applications REST interface
which was developed in APNIC facing downwards. Terry may have a different
perspective but thats my sense: we had this working in-house as a
lightweight mechanism to solve a specific problem and it happened to be a
good fit for a very similar problem facing our parents in reverse-DNS
provisioniong.

We have frequently discussed EPP for Internet Number Resources (INR) in the
RIR system, and never found it a good fit. Ed Lewis demonstrated extensions
at an APNIC meeting in my deep memory. The critique is: its hugely complex,
and based on binary prototcols in ways we don't find tractable. The
positives are that many holders of INR have an investment in EPP to do
their provisioning for customers with domain names. The break point is that
while the provisioning investment has been made, its different people
inside the INR holding entity, and the current number holders are more
familiar with textual update mechanisms like RPSL, whois objects, and REST.

I think EPP's time window to be deployed has come and gone. thats just my
personal opinion.

-G

On Tue, Aug 13, 2013 at 9:28 AM, Jay Daley <[email-masked]> wrote:

> 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.
>
> 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.
>
> 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
>
>
>
> >
> and starting a conversation than anything else.  So here are my comments in
> light of that:
> >>
> >> 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
> 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.
> >>

---

From: Jay Daley <[email-masked]>
Date: Tue, 13 Aug 2013 12:16:57 +1200

Hi Terry

> process and policy that sits on a level well above the provisioning of

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.

> 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

---

From: Terry Manderson <[email-masked]>
Date: Mon, 12 Aug 2013 17:55:57 -0700

Hi Jay,

On 13/08/13 9:28 AM, "Jay Daley" <[email-masked]> wrote:

>if I do, but is this a case of ICANN mistaking its position here?

No offence taken, and certainly a good question to ask.

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

I am not sensing that ICANN is mistaking its position here at all. There
are no demands for the document to become an RFC via the ISE. It is a
respectful thought, on my part, to offer the documentation of the
technical portion first to the IETF, and should the IETF choose to not to
absorb that then ICANN has done the appropriate action. In that case then
ICANN might publish the documentation as a whitepaper on a website
somewhere. But the effort has been made to be clear and transparent to the
broader technical community, and not hide nor bury anything.

Cheers
Terry