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

["Michael Young" <myoung@ca.afilias.info>]

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

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

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