Subject: Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedback

From: "Gould, James" <[email-masked]>
Date: Tue, 3 Jun 2014 20:51:15 +0000

It has been a while since we’ve discussed this thread.  Have the draft-ietf-eppext-keyrelay authors considered the feedback to include in a new version of the draft?  Is there a plan for an EPPEXT meeting at the next IETF meeting in Toronto, where this can be worked out?  In review, there were three options discussed on the thread:

  1.  Command-Response Extension
     *   Key Relay Command as an extension to an empty domain update similar to the restore command in RFC 3915.
     *   Key Relay Poll Response as an extension to the domain info response.
  2.  Object Extension
     *   Key Relay is an object that can be created via the create command and can get information via the info command and response.  The poll message is simply a key relay info response.
  3.  Protocol and Object Mix Extension
     *   As draft-ietf-eppext-keyrelay is currently defined using a Protocol Extension for the Key Relay Command and using an Object Extension for the Key Relay Poll Message.

As Christopher pointed out, we’re talking about the protocol definition and not if and what is stored in the Registry Database.  In this case, the Key Relay does need to be stored somewhere to support the asynchronous consumption of the poll message by the losing hosting provider.  As stated earlier in this thread, I prefer option 2 “Object Extension” since the gaining hosting provider is creating a poll message to be consumed later by the losing hosting provider.  The poll message does reference the domain but is fundamentally not an attribute of the domain itself.

Thanks,

--

JG

James Gould
Principal Software Engineer
[email-masked]

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

From: Christopher Browne <[email-masked]<mailto:[email-masked]>>
Date: Monday, April 28, 2014 at 11:49 AM
To: James Gould <[email-masked]<mailto:[email-masked]>>
Cc: Antoin Verschuren <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedback

Reactions here were broadly consistent with yours, James.

The proposal that this be an object-less command wasn't terribly popular; several people thought that it would be more logical for this to be something to be added or returned as an extension to the domain object.

I understand there being a desire not to add more data to associate with domains in a registry, but frankly, if, as a registry operator operator, we planned to support this, I think we'd rather associate the data with domains than anything else.

Alternately, to point at the opposite position, were we inclined to refuse to associate key data with domains, we'd be mostly inclined to refuse to support the extension altogether; that's an entirely simpler answer to the matter.  (And if the idea was to "not update anything in the DB", that would indeed need to be the outcome.  If it's not to go in the DB, then it can't go in the Poll Queue, as that is in the DB.)

The common thinking here was that it seemed like a good idea to:
a) Add keyrelay data via an extension to <domain:update>
b) Perhaps pass, to the recipient, a message indicating presence of such data, via Poll Queue, perhaps also including all the data in the poll queue.
c) Access the data via an extension to <domain:info>.  That suggests that there might be storage of data beyond "just" in the poll queue.

The proposal that James Gould just put forth for a Keyrelay object extension seems no worse than that, and that seems cleaner than the initial proposal in that it presents the same sort of object/command division of things as we have elsewhere in the EPP standards.

I have a bit of a meta-comment...  There are several references to databases such as the following:
   "we looked at a way to do this communication step without even touching the DB."

It seems to me that there's something rather peculiar about discussing databases here; while I tend to "live the database" in many of my day-to-day duties, I try to be careful to take that hat off here.  What we're doing here is protocol design, and that should be kept independent of internal implementation considerations.  Whether someone's using a relational database, hash tables, IMS, or passing data through message-oriented middleware shouldn't be tightly encoded into the protocol.

It also seems odd to me that it seems to be imagined that associating data with a domain indicates that there *are* database updates, whereas associating data with a poll queue indicates that there *are not* database updates there, when poll queue entries still need to be kept durable enough to survive until they are sent to their recipients.

(Indeed, and this is certainly an aside, I'm a bit unhappy that RFC 4930 requires having a message count, e.g. - <msgQ count="5" id="12345"/>.  That's more data about what's in the queue than I think there ought to need to be.)