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

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 12 Aug 2005 13:06:18 +0200 (MEST)

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Andrew Sullivan
> Sent: Thursday, August 11, 2005 4:30 PM
> To: [email-masked]
> 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-

---

From: "Michael Young" <[email-masked]>
Date: Fri, 12 Aug 2005 16:10:28 +0200 (MEST)

Well please see my comments below.  You all know I don't weigh in often but
frankly I needed to say something on this rather painful debate.  However,
before I start arguing heavily, I want to personally acknowledge the huge
amount of effort Scott has put into this work thus far; I have been a
benefactor of those efforts and its not something that I will cease to
appreciate. 

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

>"Servers MAY implement other mechanisms to dequeue and deliver 
> messages if queue maintenance needs exceed server resource consumption 
> limits." 

Lets look at this line for a second, first of all taken in context (in other
words not dropping the sentence after "dequeue and deliver")  it seems to be
describing an out for the operator and the registrar if the message queue
gets out of control.  It is no less and no more specific than that, near as
I can tell from my understanding of the English language.  If you meant
"dequeue and deliver via an alternate mechanism", then that's what you
should say.  Frankly it's a cosmetic change and I don't even see why folks
are wasting breath - it should just be modified.  Of course the minute you
do that you can now output the messages to a proprietary priority based
queue or other such system and then what's point of having the queue defined
in the protocol in the first place?  So really this part of the discussion
seems to be missing the larger point I have commented on further below. 

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

Personally I don't have any issue with making a completely inadequate
mechanism more complex. In case this minimally more complex. 

>"On the priority-based multiple queue thing: priority is relative."

Right that's exactly the point its relative to the registry operator and the
registrar and the policies they are working under.  

>"It typically either gets ignored or everything becomes "high" priority in
someone's eyes."

That's a very old line of argument in history and one that I can't believe I
am hearing applied to this situation.  Who is anyone to make that assertion?
Its saying to someone I am going to dictate how you want your messages and
in what order you must read them because if I give you the freedom to make a
choice - you are too stupid to know what to do with it.  While there are
order of operation arguments applicable to types of notifications, there is
no technical reason you can't populate a priority rating to a message
(define a type) and mark the sequence.  At that point if a registrar wants
to eat his pudding before they've had their supper then that's their poor
choice.  For that matter the Registry Operator can enforce FIFO retrieval
within the priority class but it should all be OPTIONAL if you want a
protocol the industry can stay complaint with.    

Further:

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

It seems to me this argument supports exactly why a priority-based multiple
queue is a necessity.  If you follow Jim's suggestion you are saying then
that it makes sense to populate the poll queue on all Registry Operator
maintenance activities.  Every time you touch an object according to well
communicated policy behavior you have to populate the poll queue.  Well
there's a four letter word for that in this industry "spam".  Imagine if you
had no choice but to read through your email in a enforced FIFO retrieval
when you had those kinds of volumes (wait a second no imagining needed, its
what's defined currently). Its absolutely off the map and it will almost
guarantee eventual non-compliance or foolish workarounds of the protocol(see
earlier comment).  While it should certainly be optional, a priority setting
mechanism in the poll queue is a basic and very necessary feature.     

While I realize no one wants to step up and do more work than necessary on
these documents, its clear that after several years of banging our heads
against walls like this one some changes are required.  This is an emerging
marketplace and the protocol needs to evolve as required if we expect
implementers to remain really compliant with it.  I think however its
important that we see some volunteers here to assist with this, so that
Scott is not again burdened with what was frankly an unjust amount of the
work.  

Michael Young

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 12 Aug 2005 16:22:14 +0200 (MEST)

Hi Scott,

Thanks for your comments.

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

You're right that I'm probably overstating the case.  But consider
cases where the client just doesn't do anything in time for the
notification to have been any use.  For instance, in the ICANN world,
we have 5 days in which a losing registrar may refuse a transfer
(subject to a bunch of policy rules).  If a transfer request message
hasn't been picked up after five days, it's worthless.  Worse, it's
clogging the message queue, and delaying the delivery of other,
potentially useful messages.  The only sane thing to do with such a
message is to throw it away.

As a result of this sort of thing, as near as I can tell, at least
some clients are completely ignoring the poll queue.  We therefore
have to support other kinds of notification mechanisms in parallel to
the poll queue, which is a pointless duplication of effort.  And as
near as I can tell, this is because people find the poll queue less
useful than alternative mechanisms.  I was hoping to make it more
useful.

> ourselves to transactions that cost money in the ICANN TLD world.

No, I totally agree; and I thought Jim's definition was a good one,
too; I support it.  I absolutely do not want to propose anything that
is restricted to the ICANN TLD world, because I think EPP has lots of
potential outside that world.  In fact, my view is that there are
still some things in the protocol and mapping documents that are too
ICANN-TLD-centric, and turn out to be more policy shaped than
protocol shaped.  (Just so I'm clear: I think that's an accident, and
it's just the result of the collective experience of those who were
working on the original protocol definition at the time the WG was
active.)

> typically either gets ignored or everything becomes "high" priority in

Hrm.  This makes me think that "priority" is an infelicitous word
choice.  What about "facility"?  I'm basically thinking of something
like syslog on UNIX here.  You have some arbitrary tags that tell you
what is generating the message; and that tag allows you to apply
additional rules, depending on the tag.  It's sure useful to
sysadmins; I sort of think it might be useful to clients of a
repository as well.

> the mechanism if making it simpler is a viable option.

What about the notion that you could give everything the same
priority (or facility, or whatever we want to call it) value, so that
you'd have something just like the current mechanism?  For that
matter, the attribute could be completely OPTIONAL, and its absense
an indication that the client wants the next message in the queue
regardless of facility.  In that case, those who have implemented the
current mechanism and don't want to do any more work wouldn't have
any work they need to do.

I could be, of course, completely wrong about the utility of a
mechanism like this; I just know that people seem not to be using the
poll queue as I'd like, and I'm trying to figure out how to persuade
them to use it (so I can stop sending reams of email).  

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
                                        +1 416 646 3304 x4110