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

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 12 Aug 2005 19:24:01 +0200 (MEST)

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Michael Young
> Sent: Friday, August 12, 2005 10:10 AM
> To: [email-masked]
> 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-

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 12 Aug 2005 19:46:47 +0200 (MEST)

On Fri, Aug 12, 2005 at 01:23:43PM -0400, Hollenbeck, Scott wrote:

> available for these reasons 

[&c.]

I think an extension would be a good idea, too, as long as we make
the current poll queue optional.  In fact, if the requirements in RFC
3730 2.9.2.3 were a little weaker, I'd already have proposed an
extension.

It might be, in fact, that the only thing needed to facilitate that
is a weakening of this: "Service messages MUST be created for all
clients affected by an action on an object."  This is in line with
the suggestion Jim already made.

I'm all for making any changes as painless as possible.  Because I
did have to support two protocols in production at one time, I am
happy to agree with your observation that keeping both going at once
is going to be something shy of fun.  So if there is some way to
address the issues folks have with the existing protocol without
changing it, I'm certainly not opposed.  (But also, of course, if
we're forced to accept a protocol change, I'd much rather see it
happen now, before the installed base gets any bigger.)

A

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

---

From: Edward Lewis <[email-masked]>
Date: Fri, 12 Aug 2005 20:19:47 +0200 (MEST)

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?

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

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

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

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

---

From: Michael Young <[email-masked]>
Date: Fri, 12 Aug 2005 20:24:49 +0200 (MEST)

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

Ok perhaps I was being excessive ;-)

>"You might have three queues instead of one, with "high
>third."

I dont see the flexibility to do that as it stands, can you elaborate on that please?

>extension can be deployed without introducing version management issues

A and B I think in case qualify.  
For C how would suggest this be addressed in an extension?

As for D I completely take your point but isnt this ultimately a cost benefit analysis not a defacto "don't go there" decision?  For example the poll queue is the only item under discussion at this point, there are certainly other contenders that could result in a schema change (see 
 http://www.ietf.org/internet-drafts/draft-sullivan-epp-experience-00.txt ).  Can we really resolve all the raised issues via extensions?  If we can would that be less effort on the implementers and users than a protocol change?  I think it really depends on the complexity of the changes.  With a protocol change the resultant client changes required may be considered minimal by the users involved compared to the gains in capability.  An implementer may find running dual protocol less effort than a series of extensions. As always - it depends and we need some feedback beyond ourselves (some registrar feedback would be helpful here).

Michael

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 12 Aug 2005 20:36:48 +0200 (MEST)

On Fri, Aug 12, 2005 at 02:24:39PM -0400, Michael Young wrote:
> certainly other contenders that could result in a schema change (see 
> http://www.ietf.org/internet-drafts/draft-sullivan-epp-experience-00.txt ). 

That isn't resolving yet, last I checked, just to warn everyone.

A

---

From: janusz <[email-masked]>
Date: Mon, 15 Aug 2005 11:14:26 -0400

I see one more issue with <poll> command.

The mandatory protocol behavior appears to be inconsistent with 
reasonable levels of interoperability.

The XML syntax of <poll> response lacks elements that allow returning 
basic object-specific information such as name and ROID for actions such 
as auto-renewals or deletion and doing so in an interoperable manner. At 
the same time, the specification appears to make it mandatory for the 
server to produce <poll> service messages for such actions.  In 
practice, that implies that server implementors will be forced to either:

-produce generic service messages that will lack object specific 
information and hence will be nearly meaningless for the client
 OR
- use extensions or include object information into message text to make 
the service messages meaningful, but at the cost of interoperability and 
registrar code that is registry/server independent.

I can see 2 ways of solving the conflict.

1. Making poll command OPTIONAL as it was defined in earlier EPP draft 
documents.
2. Adding additional elements to <poll> response for returning basic 
object-specific information.

Option 1 offers no impact on existing EPP deployments.
Option 2 would impact existing EPP deployments but in the long term it 
would give more flexibility to client and server implementers. Basic 
object-information could be even used to prioritize dequeuing items from 
poll queues.

Cheers,

Janusz Sienkiewicz