Re: [eppext] New draft for keyrelay available

["Hollenbeck, Scott" <[e-mail]>]

> Making draft-ietf-eppext-keyrelay an object extension that includes support for the create command addresses this issue...

I could support this. It's consistent with what I described in this message:

http://www.ietf.org/mail-archive/web/eppext/current/msg00319.html

Scott

From: EppExt [mailto:[e-mail]] On Behalf Of Gould, James
Sent: Thursday, February 05, 2015 10:13 AM
To: Antoin Verschuren
Cc: [e-mail]
Subject: Re: [eppext] New draft for keyrelay available

Antoin,

My understanding of EPP is that it defines 7 object verbs (check, info, create, delete, renew, transfer query / request / cancel / reject / approve, and update), where I don't capture some of the base protocol commands like login, logout, and poll, with the ability to extend the protocol to support new objects in separate specifications that define which verbs are supported for those objects and what is passed in the commands and responses.  Nowhere does it state in RFC 5730 or RFC 3735 that an object extension must support a specific set of verbs and that a create must create "an object in the registry" with a single class of object.  The verbs supported are specific to the object that exists in some form in the registry.  An object could be a standard object like domain, it could be an immutable message object like with the key relay message, or could be a generated object based on a client info command ( Name Suggestion Mapping - http://www.verisigninc.com/assets/epp-sdk/EPP-Suggestion-Mapping.pdf and Balance Mapping - http://www.verisigninc.com/assets/epp-sdk/verisign_epp-extension_balance_v00.html).  I believe the key is that there can be many forms of objects that are supported by the server that can be represented using an EPP object extension.  The specification of the EPP object extension defines the specifics about what verbs are supported.

Reusing a create command is not simply less work but matches what the client is doing.  The client is creating a immutable message object that is delivered to a consuming client via the poll queue.  There is a message object getting created in the registry that is automatically removed once consumed.  I don't view this as a protocol extension based on the extensibility options provided in RFC 5730.

Please show me in the RFC's where it states that all previous commands were meant to touch an object in the registry.  There is no way that RFC 5730 could foresee all of the possible set of objects that a server could support, which is why there is the concept of an object extension.  There is variance in the set of verbs supported by the EPP domain, host, and contact RFC's.  A transfer and renew is not applicable to a host object and a renew is not applicable to a contact object.  EPP provides the ability to specifically define what verbs apply and what data needs to be sent and received to meet the needs of the particular object.

As stated many times on this list, there should be no mixing of a protocol extension and an object extension in a single specification, which is what is currently being done in draft-ietf-eppext-keyrelay.  Making draft-ietf-eppext-keyrelay an object extension that includes support for the create command addresses this issue and is not disallowed by any text that I'm aware of in the EPP RFC'S.

Thanks,


-



JG

[cid:image001.png@01D04134.04B15620]

James Gould
Distinguished Engineer
[e-mail]

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

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

On Feb 5, 2015, at 9:32 AM, Antoin Verschuren <[e-mail]<mailto:[e-mail]>> wrote:


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]<mailto:[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]<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]<mailto:[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]<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

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

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