Re: [eppext] New draft for keyrelay available

[Antoin Verschuren <[e-mail]>]

I believe this is the essence of the confusion.
The authors believe that like Scott, an "EPP <create> Command" always creates an object in the registry. That is how we read section 2.9.3 of RFC5730.
James believes that a create command can also be used to create "something” in the poll queue only, without creating an object in the registry. Reusing the create command like this is less work.

For relay, it is not desirable to create an object in the registry, as nothing is done with the object data after queueing in the poll queue, and just polutes the registry, let alone the question of who owns the object and what will trigger it to be deleted.

For relay we are looking for a process to place data in the poll queue only without it becomming an object in the registry.
That is why the relay draft sugested a 4th section (2.9.4) of a new type of protocol commands that we will call "Communication Commands” where a command will create a poll queue message, but does not create or change any objects in the registry. 

We cannot call this new command an "EPP <create> Command” under this new "Communication Commands” section, just like there is a difference between an "EPP <transfer> Query Command” under Query Commands, and an "EPP <transfer> Command” under the Object Transform Commands.

I have no deep knowledge of XML namespaces or mixing protocol and command extensions, but this is what this new command needs to do, and is something EPP hasn’t seen the need to do before. All previous commands were meant to touch an object in the registry.

- -- 
Antoin Verschuren

Tweevoren 6, 5672 SB Nuenen, NL
M: [phone]
xmpp:[e-mail]




Op 30 jan. 2015, om 16:08 heeft Hollenbeck, Scott <[e-mail]> het volgende geschreven:

> 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]
> 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]
> 
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
> 
> VerisignInc.com
>  
> On Jan 30, 2015, at 9:20 AM, Hollenbeck, Scott <[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]
> 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
>  
> _______________________________________________
> EppExt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/eppext