Re: [eppext] New draft for keyrelay available

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

Antoin,

RFC 5730 does not explicitly specify what an object is or is not.  I believe that you are putting unnecessary restrictions on what an object in EPP can be.  To give you an example, the IDN Table Mapping ( https://tools.ietf.org/html/draft-gould-idn-table ) that was posted today defines a new IDN Table object that supports no transform commands and it may or may not be physically stored in the registry database.  Should it be defined as a protocol extension as well based on your restriction?  The protocol does not and should not dictate whether an object is physically stored in the database, is an immutable object that is stored in a queue or in a specific database table, or is cached or generated to provide information to the client.  A blob that is well formed and structured is an object in a programming language as well as in a protocol like EPP.  My recommendation is to create a single EPP extension form in draft-ietf-eppext-keyrelay, where an object extension makes the most sense.  The responses on the list seem to support this approach.

Use of a unique relay identifier is a straight forward mechanism for the consuming client to know that it has or has not processed the message before.  There is no need to rely on some heuristic on the timestamp or comparing a set of fields to address the concern that Scott raised.

Thanks,


—


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 Feb 5, 2015, at 12:07 PM, Antoin Verschuren <[e-mail]<mailto:[e-mail]>> wrote:

Op 5 feb. 2015, om 15:08 heeft Gould, James <[e-mail]<mailto:[e-mail]>> het volgende geschreven:

I believe that RFC 5730 is not limited to a certain class of objects that can be provisioned.  A create of a transient, immutable message object is a transform command and the use of a poll response supports a query command.

Apologies James if I am confused.

So the question boiles down to:

-What is meant by "object” in RFC5730?

The authors believe what is meant here with "object" is something stored in the registry database that requires uniqueness and ownership. Not all EPP commands can be performed on all objects, A database can be extended with new objects which will require an extension to provision the new object, or an existing object could be extended with new records which needs an extension of the command to provision the new records.
You think "object" does not relate to a registry database table and can be any data blob in the communication stream as well.

If we all agree that an object means any blob, should that be clarified in RFC5730?
At least I am confused when object does not refer to an object in the registry database, as I cannot verify uniqueness and consistancy of the EPP processes over the database.

My recommendation to the authors of the Key Relay Extension is to make the draft an object mapping with a create transform command, a the poll response, and with a unique relay identifier to address the end-to-end idempotency concern.

I don’t see the need for a seperate unique relay identifier. Since the timestamp can be part of the calculation of the expiry of the relayed key, no second message is identical. If and only if the timestamp is different and the expiry is not dependant of the timestamp and the rest of the message is identical can the message be disguarded as identical, but we don’t need a duplicate field to identify that, and it is left to the receiver how to interpret that. There may be future use cases where only the timestamp is different but where the message is valid and needs to be processed by the receiver.

- --
Antoin Verschuren

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