Re: [eppext] keyrelay draft

[Patrick Mevzek <[e-mail]>]

Rik Ribbers <[e-mail]> 2015-05-01 17:31
> As you might have noticed we've published a new version of the keyrelay draft. Major change is the new XML structure as suggested by the WG. Hopefully this will help the document move forward.
> 
> As always any feedback is appreciated.
 
Here are my comments on draft-ietf-eppext-keyrelay-02 that I've just
implemented:

I really prefer the previous version of your draft, not only
because of the more generic 'relay' framework (more on that below) but
also because of the following points:

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

- 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

- various nitpicks:
* "A REQUIRED <keyRelayData> elements" (should be element), this
 happens twice in the document.
* for your create example, the clTRID in the response does not match
the one in the command
* in XSDs, I believe you have by default minOccurs="1" and
maxOccurs="1" on all elements, so it should not be needed to have
minOccurs="1". In fact I think your mistake is that you really wanted
maxOccurs="1" (for example for the name) and not minOccurs="1"


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.

As for the keyData elements, even if it is straightforward you may
specify more in detail that it is up to registry policy to define the
maximum number of elements that can be provided, and if the threshold
is crossed what error code the registrar will have

"the EPP <resData> element MUST contain a child
   <keyrelay:infData> element that identifies the keyrelay namespace."

I do not understand the "that identified the keyrelay namespace": this
namespace can be defined anywhere from this node up the root node,
this is depending on server policy and has no consequences on the XML
parsing. In fact in your own example after that, the keyrelay:infData
has no namespace declaration since it is already done previously.

Same remark later on for keyrelay:create


As discussed in private, I would really favor the idea of the generic
relay framework…, as it has a lot of technical merits and even if it
would be difficult to make it a standard used by many registries.

I believe it may have some overlapping parts with
draft-gould-change-poll and/or
draft-mayrhofer-eppext-servicemessage.

-- 
Patrick Mevzek