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

[George Michaelson <[e-mail]>]

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 <[e-mail]> wrote:

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