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

[Christopher Browne <[e-mail]>]

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.)