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

[Edward Lewis <Ed.Lewis@Neustar.biz>]

Keeping in mind that a protocol is about communication of 
information, not the processing of information:

Reading Jay's suggestion carefully, it does not "bar" sending replies 
as they are now, just makes them an implicit "MAY".  Is that 
intentional/acceptable?

At 13:23 -0400 8/12/05, Hollenbeck, Scott wrote:
>>  -----Original Message-----
>>  [mailto:owner-ietf-provreg@cafax.se] On Behalf Of Michael Young
>

>1. Is priority-based messaging needed?

I have a hard time imagining that a priority-based message system is 
important in the context of EPP.  EPP is only delivering the 
messages, there's nothing saying that the recipient can't delay 
acting on some.

 From my experience in communications protocols, adding priorities 
into queues winds up gumming up the pipes.  I would reserve 
prioritization for cases where time critical responses are required 
or where one stream of messages has a different tolerance for transit 
latency than another.

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

I dislike protocol features with really complicated rules regarding 
what it means to be conformant.  EPP handles a pretty simple 
client-server conversation, is the benefit of priority queues worth 
having to define all these new rules?  Don't just think of all of the 
specification ink needed, think of having to roll out new tar files 
of EPP code too.

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

On a tangent - do you mean to say that extensions ought to cause a 
new WG?  Up to now some extensions haven't been discussed in a (new) 
WG.

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

I'm not so worried about IETF impacts (like, "respin at PS") as I am 
about software that has been distributed.  That's been the achillies 
heel of many an old protocol.

Do we really gain by no longer delivering messages to the initiator 
has Jay suggests?  (Or can the initiator be counted on to just dump 
the extraneous message?)  Do we really gain with priority queueing?

I'm not sure I'd say yes or no to the first question, my gut tells me 
that answer to the latter is no.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

If you knew what I was thinking, you'd understand what I was saying.