Subject: [eppext] keyrelay draft

From: Rik Ribbers <[email-masked]>
Date: Fri, 1 May 2015 15:15:42 +0000

Hello,

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.

Regards,
Rik Ribbers

---

From: "Gould, James" <[email-masked]>
Date: Fri, 1 May 2015 16:18:18 +0000

Rik,

Thanks for making the updates.  I reviewed the updated draft and it addresses the concerns that I raised on the mailing list by defining Key Relay as an object mapping.

Thanks,

—

JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com<http://VerisignInc.com>

On May 1, 2015, at 11:15 AM, Rik Ribbers <[email-masked]<mailto:[email-masked]>> wrote:

Hello,

Regards,
Rik Ribbers
_______________________________________________
EppExt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/eppext

---

From: Patrick Mevzek <[email-masked]>
Date: Wed, 27 May 2015 00:04:38 +0200

Rik Ribbers <[email-masked]> 2015-05-01 17:31
> 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

---

From: Rik Ribbers <[email-masked]>
Date: Wed, 27 May 2015 18:58:51 +0000

Hello Patrick,

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

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

I will update the wording to explain.

Kind regards,
Rik Ribbers

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

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

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.

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

[email-masked]