RE: Proposed Document Changes - Pending Operations

["Liu, Hong" <Hong.Liu@neustar.biz>]

Patrik,

Rick Wesson has suggested that I reword my response to you to clarify the
issue. So here is my second try. This time, I will use an example to make it
more concrete.

Suppose the registry policy requires that every name registered go over a
formal review before the request for registration is granted. So here is the
typical flow of client (C, registrar) and server (S, registry) interactions,
in the context of the four steps you outlined:

(1) C sends a <create> command to the server, requesting for a name X.
(2) S accepts X, changes its status to "pendingVerification", and sends a
response back to C indicating command success.
At this point, X is not registered, but is reserved so that no one else can
take it while it is under review.
(3) The registry completes the review and grants the registration. S removes
the "pendingVerification" status and puts a notification into the message
queue.
(4) C polls and gets the notification from S that registration for X has
been approved.

What I meant by pending operation (or delayed operation in your word) is
that at step (2), the response from S merely says that the request for
registering X by C is received and the review process has started. The
decision on whether the request will be eventually granted is pending for
further review. So from EPP perspective, the command-response transaction
may be regarded as completed by the end of step (2). However, from
operations perspective, neither C nor S considers that the request for
registering X is completed. I think that is where the misunderstanding kicks
in.

I hope this example explains what I meant by "pending operation". And I hope
that you would not object to allowing EPP to do things like this. Of course,
I am open to using any term that helps to avoid the confusion.

What Scott and I were discussing is about ways to format the notification in
step (3). Scott has already started another thread on this issue [1]...

--Hong

[1] http://www.cafax.se/ietf-provreg/maillist/2002-07/msg00038.html

-----Original Message-----
From: Patrik Fältström [mailto:paf@cisco.com]
Sent: Monday, July 22, 2002 1:32 AM
To: Liu, Hong; ietf-provreg@cafax.se
Subject: RE: Proposed Document Changes - Pending Operations


--On 2002-07-18 22.35 -0400 "Liu, Hong" <Hong.Liu@neustar.biz> wrote:

> I guess we had different definition for "delayed execution". Please refer
> to my response to Scott's email. In short, pending operation does not
> call for delayed response. In fact, it calls for additional information
> once the pending operation is completed.

This is exactly what I mean by "delayed execution".

I.e.:

(1) Client send a command to server
(2) Server respond that it has received command
(3) Server execute the command
(4) Client fetches the result code

This is what I urge this wg to _not_ do.

If you really need asynchronous execution like this (i.e. even delayed
execution like this), you have to (a) convince the IESG that is needed and
(b) redesign the protocol quite extensively, because what you want to do is
not possible with what you have on the table today.

    paf