Re: [eppext] keyrelay draft

[Rik Ribbers <[e-mail]>]

Hello Patrick,

Thanks for your thorough review, below is my feedback:

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


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

>- various nitpicks
Have been fixed in the working document and they will appear in the next version of the draft.


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

I will update the wording and add an error code, this makes sense having updated the XSD with maxOccurs=unbounded 

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

I will update the wording to explain.

Kind regards,
Rik Ribbers

-----Original Message-----
From: EppExt [mailto:[e-mail]] On Behalf Of Patrick Mevzek
Sent: woensdag 27 mei 2015 0:05
To: [e-mail]
Subject: Re: [eppext] keyrelay draft

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

_______________________________________________
EppExt mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/eppext