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 Michael Young
> Sent: Friday, August 12, 2005 10:10 AM
> To: ietf-provreg@cafax.se
> Subject: RE: [ietf-provreg] Services messages in RFC 3730
> 
> 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. 

[snip]
 
> >"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.    

Superlatives and astonishment aside, there are really three issues here:

1. Is priority-based messaging needed?  You obviously think so assuming
that messaging isn't optional, so let's continue.

2. If so, is this a specification issue or an implementation detail?  I
believe it's both.

Implementation detail: how you implement your message queuing system is
up to you.  You might have three queues instead of one, with "high
priority" messages going into one queue, "normal priority" messages
going into a second queue, and "low priority" messages going into a
third.  As registry operator you make an implementation decision to
determine which messages go where.  The <poll> command can then be
implemented to read from them in whatever order makes sense to you.

Specification issue: if multiple queues are implemented, how does one
let the client deal with that fact?  As is, they could be read from in
whatever order the server operator decides to impose on the reader.
That's probably not too helpful.  We also need to look at loosening up
the text as Jim suggested.

3. If a specification issue, should something new be added to the core
specs or should something new be defined in an extension?  Given that
we're talking about adding a new feature that may or may not be useful
to everyone (as you say, "it should all be OPTIONAL"), documenting a new
feature (adding priority marks to messages and allowing a client to
specify how they wish to deal with the priorities) in a standard
extension seems like the least intrusive way to make the functionality
available for these reasons:

a. It truly is optional.
b. It doesn't complicate other existing implementations.
c. It's common IETF practice to add new features via extensions once
proposed standards are published.  Extension development is usually a
good reason to spin up a new working group.
d. It allows us to avoid a core schema change and the resulting new
protocol version.

Think about d. for a moment.  A protocol version rev likely implies an
operational requirement for ALL conforming servers and clients to
support both old and new versions for some TBD period of time.  An
extension can be deployed without introducing version management issues.

-Scott-