Re: [eppext] keyrelay draft

[Patrick Mevzek <[e-mail]>]

Rik Ribbers <[e-mail]> 2015-05-27 20:59
> >- you describe the notification message under the "info response"
>   section; I believe this is wrong, since you never got this reply by doing a command info, only by a result of a poll. Hence, like previously you should leave the info section empty and describe the notification message in a section clearly labeled "poll"
> And for this same reason, I prefered the previous paData node name, instead of the new infData, but this is almost cosmetic.
> 
> The infData is more inline with other EPP extensions, therefor we chose the infData
 
The node name is a matter of taste, so no arguing there, however
document wise, most of drafts/rfcs are written with such a structure
where you list each EPP command and you specify if the extension adds
something to a given command name or its reply.
In your case, even if the node is called infData it is never returned
in a domain:info reply, so it should not be listed here in the
document, but indeed as a reply of the poll command.
So it is just a kind of document architecture issue.

> >- I really prefer the previous relay verb/extension instead of piggy
> >  backing the create one, since keyrelay are not really registry 
> >objects, only EPP messages. And EPP is a provisioning protocol, a 
> >keyrelay:create command seem to imply that you are provisioning some 
> >kind of new objects inside the registry system, where you are in fact 
> >only queueing a message into another registry polling queue
> 
> From a personal perspective I totally agree, however going for Standards Track is also to comply with the WG feedback. There was an explicit discussion thread in the mailing list where several people stated that the current xml structure is the way to proceed. However we are thinking of publishing the relay framework as a separate document. The goal would be to help move the discussion forward on 3rd party access to the registry system from a technical point of view.
 
I would support your work on the relay draft, and implement it in my
software.

> >Also, taking a step back, I do not fully agree with "There is no clear distinction in the EPP protocol between Registrars
> >   and DNS-operators."
> > The EPP protocol is clearly between a registry and a registrar. A registrar can also be a DNS-operator but this has no relationship to its role as a sponsor of a domain name.
> 
> I definitely do not agree with the last. The EPP protocol is defined between an EPP client and an EPP server. In practice most (99.99%) clients will belong to a registrar. However given the current discussion on 3rd party DNS operators (like Cloudfare) to get access to the registry system I think the model where EPP clients are automatically registrars will change in the future. This draft is one the firsts where it is an implementation issue.
 
The question is indeed on the table, and we have to see if the EPP
channel is good enough to be used by other parties than registrars
currently. It would have my favor too, for obvious reasons, in order
not to design a new protocol, and even if the tool "du jour" is more
JSON than XML.
I'm not aware of any area where this work is currently handled
publicly. Are there other relevant mailing-lists?

-- 
Patrick Mevzek