Re: [eppext] New draft for keyrelay available

["Gould, James" <[e-mail]>]

Scott,

There are three parties here which include the producing client, the server, and the consuming client.  What you’re referring to in the EPP command is the producing client and server, which does not have any idempotent issue since the message is transient and immutable.  To address your idempotency concern end-to-end, maybe the producing client should add a unique relay identifier that the relaying consumer ensures to process only once.  Messages with a duplicate relay identifier must be processed a single time by the relaying consumer.  Does that work?


—


JG


[cid:[e-mail]]

James Gould
Distinguished Engineer
[e-mail]

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

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

On Jan 30, 2015, at 3:18 PM, Hollenbeck, Scott <[e-mail]<mailto:[e-mail]>> wrote:

> This is the responsibility of the consuming client and not of the server

EPP commands are supposed to be idempotent *without* the client needing to assume responsibility for any special actions. We can do better.

Scott

From: Gould, James
Sent: Friday, January 30, 2015 3:03 PM
To: Hollenbeck, Scott
Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; [e-mail]<mailto:[e-mail]>
Subject: Re: [eppext] New draft for keyrelay available

Scott,

There is a level of indirection here, where the goal of the extension is to create a message to be sent to another party.  There is no idempotency issue with the creation of the message itself since it’s transient and immutable.  Creating a duplicate message  with the same data creates another immutable, transient object.  The consuming client will handle the idempotency aspects by ensuring that receipt of a duplicate message does not change the result.  For example, consumption of the relay of the same key should not result in the key getting duplicated in the resulting zone.  This is the responsibility of the consuming client and not of the server.

—


JG

<image001.png>

James Gould
Distinguished Engineer
[e-mail]<x-msg://31/[e-mail]>

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

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

On Jan 30, 2015, at 2:11 PM, Hollenbeck, Scott <[e-mail]<mailto:[e-mail]>> wrote:


> Since the create is for a transient message object, there is no issue with creating more then one message with the same data.

If two or more messages end up being enqueued, what is the client supposed to assume about any repeats after retrieving and acting on the first message? How is idempotency preserved?

Scott

From: Gould, James
Sent: Friday, January 30, 2015 1:50 PM
To: Hollenbeck, Scott
Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; [e-mail]<mailto:[e-mail]>
Subject: Re: [eppext] New draft for keyrelay available

Yes, each create would result in a new message to get created and enqueued.  Since the create is for a transient message object, there is no issue with creating more then one message with the same data.
—


JG

<image001.png>

James Gould
Distinguished Engineer
[e-mail]<x-msg://30/[e-mail]>

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

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

On Jan 30, 2015, at 1:39 PM, Hollenbeck, Scott <[e-mail]<mailto:[e-mail]>> wrote:



> The intention of the relay command is more of sending a message (with information) then the manipulation of objects, but James explained it pretty well.

I just thought of something else while re-reading this sentence. What happens if the exact same command is sent twice? Is a second message sent?

Scott

From: Rik Ribbers [mailto:[e-mail]]
Sent: Friday, January 30, 2015 11:40 AM
To: Hollenbeck, Scott; Gould, James
Cc: Maarten Bosteels; Miek Gieben; [e-mail]<mailto:[e-mail]>
Subject: RE: [eppext] New draft for keyrelay available

Scott,

The intention of the relay command is more of sending a message (with information) then the manipulation of objects, but James explained it pretty well.

The  thing that triggered me is the second part of your reply:

>  I don't have an issue with continuing work on this draft if the intention is to document the existing practice of one operator in an informational way, but I'm not comfortable with pursuing the current approach on the standards track. We should confirm the need before doing standards track work.

Although I’m not an IETF expert I assumed that when the document was adapted by the WG the WG acknowledges the need for a standard. In Honolulu there was a discussion if the documents from the working group should be informational or standards track. And as far I understood it is not up to the WG to make a document informational, that is something the IESG does. Feel free to correct me if I misunderstood things.

However the real question is: Who can confirm this need?

We see the need for an automated secure transfer of domainnames in our daily operation. As the adoption of validating DNSSEC resolver grows it becomes more and more a problem that domainnames cannot be resolved. We choose the solution which is described in the draft and believe it is a good pragmatic solution for a the problem. But  I agree that the need is not extremely high at this point, but it will be in the near future. Should we wait for that or act upon what we believe is inevitable?  We choose not to wait.

Kind regards,
Rik

From: Hollenbeck, Scott [mailto:[e-mail]]
Sent: vrijdag 30 januari 2015 16:35
To: Gould, James
Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; [e-mail]<mailto:[e-mail]>
Subject: RE: [eppext] New draft for keyrelay available

Jim, that’s not how I would have designed it. To each his own.

Scott

From: Gould, James
Sent: Friday, January 30, 2015 10:32 AM
To: Hollenbeck, Scott
Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; [e-mail]<mailto:[e-mail]>
Subject: Re: [eppext] New draft for keyrelay available

Scott,

EPP can be extended to support new types of objects, and objects can support a different set of commands and responses based on the requirements of those objects.   Objects can be created on the server-side without any support for transform by the client.  In this case, the intent is to create a poll queue message object that is consumed and automatically deleted when consumed, so the create functions as an enqueue and the poll info response functions as a dequeue once acknowledged.  With this, the transient object only needs to support the create transform to insert the message in the poll queue and the poll message in the form of an info response to consume the message.  There is no need for the implementation to create any form of a transient object outside the poll queue, since the poll queue is the transient object store for this object type.

—


JG

<image001.png>

James Gould
Distinguished Engineer
[e-mail]<x-msg://29/[e-mail]>

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

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

On Jan 30, 2015, at 10:08 AM, Hollenbeck, Scott <[e-mail]<mailto:[e-mail]>> wrote:

EPP has no concept of “objects” in the poll queue. The poll queue manipulates messages. Objects are manipulated by transform commands like create, delete, etc.

I was thinking that the source client would create a relay object, which would result in a message being queued for the target client. The info could exist in both the poll message (which would be short-lived and lost once dequeued), and in the object (which would be slightly longer-lived, but would be automatically deleted when it expired).

Scott

From: Gould, James
Sent: Friday, January 30, 2015 9:57 AM
To: Hollenbeck, Scott
Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; [e-mail]<mailto:[e-mail]>
Subject: Re: [eppext] New draft for keyrelay available

Scott,

I believe the intent is to insert the transient object into the poll queue for the target client.  The acknowledgement of the poll message should result in the implicit removal of the transient object from the server.  With what you’re proposing, the source client would create the transient object that I’m assuming would result in a poll notification containing a signal to the client to submit an info command to get the transient object information?  I’m assuming that the target client would then need to delete the transient object once they’re done with processing the message.  I believe it’s simpler and consistent with the concept of creating a transient poll message to support the create to create the poll message and the info response poll message for the consumption of the transient object.  In this case the poll queue is functioning as the repository for the transient object with the signal and data being one and the same, and the deletion of the transient object handled via the standard poll queue mechanism.

—


JG

<image001.png>

James Gould
Distinguished Engineer
[e-mail]<x-msg://27/[e-mail]>

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

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

On Jan 30, 2015, at 9:20 AM, Hollenbeck, Scott <[e-mail]<mailto:[e-mail]>> wrote:

-----Original Message-----
From: EppExt [mailto:[e-mail]] On Behalf Of Rik Ribbers
Sent: Tuesday, January 20, 2015 3:02 AM
To: 'Maarten Bosteels'; Miek Gieben; Gould, James; [e-mail]<mailto:[e-mail]>
Subject: Re: [eppext] New draft for keyrelay available

Hello Maarten,

Thx for the feedback, I hope more people with experience on extending
EPP will state their opinion on the list.

We have implemented the functionality in our registration system, but
it is not very actively used. What we see is that most registrars go
insecure. Most of the time we see a transfer command followed (some
time later in time) by a domain update to remove the old key material
and add new key material. There is even a losing registrar that removes
all DNS key data when a registrant requests its authorization token
before the actual transfer.

One more opinion:

After reading through the draft again I believe I would have designed this differently. EPP commands typically act on or read data from objects, and if I'm reading keyrelay correctly the <relay> command isn't doing either of those things. It's pushing information to the server to be stored temporarily (in what?) so that it can be retrieved with a <poll> command. It would be more architecturally consistent to create a temporary relay object with the needed information and use an <info> command to retrieve the data. <poll> can be used to notify the receiving client that the information is there to be retrieved. Anyway, that's my two cents.

Rik's "not very actively used" comment is telling. DNSSEC isn't widely supported by registrars, so it makes sense that we're not seeing a lot of use. I don't have an issue with continuing work on this draft if the intention is to document the existing practice of one operator in an informational way, but I'm not comfortable with pursuing the current approach on the standards track. We should confirm the need before doing standards track work.

Scott