Re: [ietf-provreg] Services messages in RFC 3730

[Andrew Sullivan <andrew@ca.afilias.info>]

On Thu, Aug 11, 2005 at 02:24:22PM -0400, James Gould wrote:
> All,
> 
> I believe the current text describing who receives service messages in RFC
> 3730 is too strict.  The text that I'm referring to reads:

I think you're right.  More generally, if I'm reading you correctly,
the principle is that only the uninformed parties are subject to
notification by poll queue for any case where a service message is
required.  But I think your rewording doesn't go far enough.  (I put
some discussion of this in the draft I put up recently -- it's been
submitted since the Paris meeting, but it's still currently only
available at
<http://www.afilias.info/news/events/draft-sullivan-epp-experience-00.txt>,
in case anyone is waiting, breathless).  

To me, one of the strange things about the service message
description in the RFC is that it appears to be both mandatory and
optional.  On the one hand, we have, "Service messages MUST be
created for all clients affected by an action on an object." On the
other hand, we have, "Servers MAY implement other mechanisms to
dequeue and deliver messages if queue maintenance needs exceed server
resource consumption limits."  Since one could easily construct an
argument that any queue at all causes too much overhead, the latter
permission amounts to a permission that the message queue be hooked
up to /dev/null.  Indeed, the description of service messages appears
to require that any effect at all in the repository not explicitly
requested by the client causes a service message to be generated.  So
the repository operator has to be able at least to purge the queue
sometimes, because otherwise it'll consume all the server's
resources.  Hence the provision that servers may use some other
mechanism.

Now, part of the reason for this provision is obviously that
sometimes clients won't clear out their queues.  My impression is
that the "won't clear out" problem is exacerbated by the FIFO nature
of the queue: I know that our registrars want a notification of
things that possibly cost them money (like a transfer loss or an
auto-renewal) way more than they want a notice about something that
costs them nothing (like denying a transfer request).  I'd therefore
like to suggest the addition of a "priority" attribute to the <poll>
command.  This would allow server operators to put messages of
different importance in different queues, and to publish different
retention policies for their different queues.  If a server operator
didn't want to go to the trouble of administering different queues,
the operator could still get the current behaviour by setting all the
priorities to the same value.  A magic priority value (I've suggested
1000, but some other value will do) could be used to indicate "give
me the next highest-priority message".

This approach has the advantage not only that different kinds of
messages can be put into different queues; but that for some of them,
the server could publish (out of band) a retention policy that says,
"queues with priorities 4, 5, and 6 will be retained for 0ms," which
is an effective way of tagging certain kinds of messages as ones that
will never be delivered through the poll queue (internally, an
implementer could just as well drop those messages in the bit
bucket).

If this approach is unacceptable, I think that the message queue should
either be made entirely optional, or that some class of service
messages (preferably "all the ones not explicitly required") be made
optional.  The way 3730 reads today, the message queue is a
bottleneck, and I don't think it was intended to be that way.

Thoughts?

A
-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<andrew@ca.afilias.info>                              M2P 2A8
                                        +1 416 646 3304 x4110