RE: draft-ietf-provreg-epp-06.txt

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

Patrik,

Since you said it was OK to respond to this message to the provreg mailing
list so that everyone can see your questions and concerns, here we go.
Thanks for the feedback.

To the WG:
Patrik, Randy, Ned, and I have been talking about Patrik's questions a bit
over this past weekend.  One topic raised concerned allowing clients and
servers to send/receive multiple commands/responses in a single TCP
read/write operation.  Folks who've been following the WG for a while may
well remember that the earliest protocol drafts were written such that each
TCP read/write operation moved a single protocol command or response.
During the course of WG discussion the WG decided that this wasn't
acceptable from a performance perspective, and so the drafts were changed
such that multiple commands or responses could be moved in a single TCP
read/write.  Some of the IESG reviewers have said that they have concerns
(command synchronization and filling pipelines resulting in deadlock were
specifically mentioned) with this approach.  My use of the term
"asynchronous" (which can imply timing delays between commands and
responses) to describe this operational form might also be misleading, so
that might need to be changed.

Questions and my responses below.

-Scott-

> -----Original Message-----
> From: Patrik Fältström [mailto:paf@cisco.com]
> Sent: Friday, June 21, 2002 9:43 PM
> To: Scott Hollenbeck
> Cc: Jaap Akkerhuis; Edward Lewis; Randy Bush; Ned Freed
> Subject: draft-ietf-provreg-epp-06.txt
> 
> 
> I have a number of things which I must ask you about.
> 
> The overall protocol seems to be stable and sound, but, I can 
> not from the
> document understand how the asynchronous handling of commands is made.
> 
> Here are a number of statments, and I want to know if they 
> are true or not.
> It _might_ be that clearfications should be made -- if you think other
> people are as confused as I after reading the document.
> 
> (1) It seems that the client is always master. The server can 
> not send any
> message to the client except as a response to a client command.

This is true per the first paragraph in section 2:

"Protected using lower-layer security protocols, clients exchange
identification, authentication, and option information, and then engage in a
series of client-initiated command-response exchanges".

There was a lengthy WG debate on allowing the server to push unsolicited
data to the client, but we eventually agreed to go with the simpler model in
the base protocol, and that unsolicited server pushing can be defined as a
protocol extension if needed.

> (2) When the client send a command, it is always tagged with 
> a clientID, so
> the client later on understand what command a response belong to.

Client transaction identifiers are OPTIONAL per section 2.4, so commands
aren't always tagged.  Admittedly this might not help the client associate a
response with a given command, but it's done this way because of the
tracking requirements imposed by the <status> command (described below).
The vast majority of the commands issued by a client are query commands that
don't really need to be logged for future <status> checking, so we allow the
client to leave off the client transaction identifier for commands that it
doesn't care to check for status in the future.

I'd be OK with making client transaction identifiers mandatory iff we can
ditch the <status> command.  Given that there is no harm in retrying any
command, the need to see if a command was received and processed seems
dubious to me -- if the client isn't sure that a command was received and
processed, all they have to do is try it again.

> (3) A server must not acknowledge that it has received a 
> command. Should it
> not always do that? I.e. that the command was sound, syntax 
> correct etc.

A server MUST always provide a response to a command.  The response confirms
that the command was received and processed.  It can also return information
requested by the client depending on the command itself.

> (4) All requests from clients (except commands which handle the status
> queue itself) are executed in the server in order.

Yes, but I'm not sure of what you mean by "the status queue".  Each and
every command is processed in order, and the server MUST produce a response
for each command.  There is a <status> command that can be used to confirm
that some earlier command was received and processed, but it gets executed
just like any other command.  There are server queues for client service
messages that can be retrieved using the <poll> command, but these queues
have nothing to do with command execution order.

> (5) Any response from a server can include responses from any client
> command which have resulted in positive or negative responses 
> since the
> last "chance" the server had to send responses. I.e. a message from a
> server can include zero or more response objects.

A server MUST produce an immediate response for each command.  The TCP
transport draft currently allows the client to move multiple commands in one
TCP write operation (which the server can retrieve in one TCP read), and the
server can return multiple responses with one TCP write (which the client
can retrieve in one TCP read).  The earliest TCP transport draft document
allowed only one command or response per TCP operation, but WG discussion
led to the behavior you see described now.  There should never be an empty
response.

> (6) A client can poll the server, and explicitly fetch result objects.

Not exactly.  The client can poll the server, but what they get are queued
service messages (such as "we're going down for maintenance at 0200UTC").
Results are only returned in response to a command, and they can't be
retrieved again at a later date.  However, a client _can_ determine if an
earlier command was received and processed (see response to your next
question) using the <status> command.  If they don't like the answer they
get from the <status> command they can retry the original command, and an
appropriate response will be generated.  The <status> command depends on
archived client transaction identifiers to work properly, so support for
this command can put a significant archival burden on a high-volume server.

> (7) A client can check explicitly what the status of a 
> command is. My view
> is that result can be either (a) still queued, (b) executing 
> or (c) done
> (and the result is in the result queue) + of course substates.

Again, not exactly.  A client can check the status of a command that
completed in the past, but this is limited to "was it received and
processed".  There is no concept of delayed responses or pending execution.
Each command is processed in real time, producing an immediate response.

However, some commands can have back-end coordination dependencies that
delay completion of the requested action.  For example, a <delete> operation
might not actually remove an object immediately, though the server will
respond to the client immediately to note that the command has been received
and processed.  Likewise, a <transfer> command might require approval from a
second client to be fully completed; in between the time that the command is
received and the second client acts the transfer action is indeed "pending".
In this case, there is a query command to check on the status of the
transfer, and when the transfer is completed both clients are notified (the
active client receives a response to their command, the passive client gets
a message added to their service message queue for retrieval via the <poll>
command.

> (8) The term "Available" is a bit weird. You seem to show 
> that "available"
> means that the object does _NOT_ exists, which for me means 
> that it is not
> available. Should it be that way? If you ask if an object is 
> available, and
> the result is "no", then for me it is ok to do a "registration" and
> allocate the object.

Hmm, I though I'd cleaned up all of the "available" language.  I do see some
in section 2.8.2.1; that needs to be cleaned up.  I tried to change all of
those "available" descriptions to "can be provisioned or not".  A positive
response means "yes, it can be provisioned".  A negative response means "no,
it can't be provisioned".  Looks like I missed at least one spot.

> Now, personally I think the following is a bit weird (part 
> from 8 which I
> talk about above):
> 
> Regarding (3) I think the server should _always_ send an ack 
> back. Either
> with a result immediately, or a message that the command is queued.

Agreed that the server should always respond to a command.

> If (5) is true, why is (6) needed?

(6) isn't needed as you described it.  Hopefully my clarification for (5)
explains why.

> When doing (7), can a result object be included, or must the 
> client always
> do a poll?

I hope it's now clear that the <poll> command doesn't return command results
as the <status> command also doesn't return command results.  It returns a
simple yes/no type of response to let the client know if some older command
was received and processed by the server.  If the client is unsure of the
results for any command (say because of a network or server failure or poor
client record keeping), they can always try the command again.  If the
second attempt "works", the proper results are returned.  If the second
attempt fails, the first attempt succeeded and the results can typically be
retrieved using one of the query commands.

> My view is that it should help if
> 
> [A] You had some ascii-art which show a state diagram for 
> actual commands

OK, this would make sense in the transport document since the state machine
tends to depend on the type of transport protocol.  The state machine for a
connection-oriented protocol would likely be a little different than the
state machine for a connectionless transport protocol.

> [B] You divided more clearly between the different kind of commands:
>    - Session management, negotiation of extensions etc
>        Login / Logout ...
>    - Status/command management
>        Poll / Status ...
>    - Actual commands
>        Create / Transfer / Delete ...

That's certainly easy to do.

> [C] You change what you mean by "available" (or change term 
> from available
> to something else)

Definitely agreed.  This came up in the WG some time ago, and any existing
confusing language is still there only because I missed it during WG review.

> The questions I have are so substantial that I want to have 
> them answered
> before I send the document to IESG, so unfortunately this set 
> of documents
> will slip to after Yokohama. The requirements document will 
> be discussed
> next week though.
> 
> I have absolutely no problem if you bring up these issues on 
> the mailing
> list, and say I have questions. This so the wg see that something is
> happening.
> 
>     paf

Thanks -- we're all looking forward to progress!

-Scott-