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

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

> -----Original Message-----
> From: owner-ietf-provreg@cafax.se 
> [mailto:owner-ietf-provreg@cafax.se] On Behalf Of Andrew Sullivan
> Sent: Thursday, August 11, 2005 4:30 PM
> To: ietf-provreg@cafax.se
> Subject: Re: [ietf-provreg] Services messages in RFC 3730
> 
> 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:

[snip]

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

I don't see how you can interpret the queuing system as optional.  The
text is completely clear about the need to create and enqueue the
messages.  "dequeue and deliver messages" does NOT mean "route to
/dev/null".  It can mean that messages be delivered via email, made
available for retrieval via ftp, etc.

"dequeue and deliver".  Not "throw away blindly".

[snip]

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

My personal preference leans towards "some class of service messages
(preferably "all the ones not explicitly required") be made optional."
What defines "explicitly required", though?  I thought Jim's definition
was pretty reasonable: if you're a party to a transaction, but not the
recipient of a response, you get a message.  We can't just limit
ourselves to transactions that cost money in the ICANN TLD world.

On the priority-based multiple queue thing: priority is relative.  It
typically either gets ignored or everything becomes "high" priority in
someone's eyes.  I don't get a good feeling about adding complexity to
the mechanism if making it simpler is a viable option.

-Scott-