RE: Pending Update

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

Eric,

You raised some good points about the semantics of pending update. We are
well aware of these issues you raised. My approach, at least from what I
learned on this list, is that I'd better state the problem clearly first
before dwelling into solutions, -:)

I take it that you are not objecting to pending update, but want to get the
semantics right regarding whether multiple pending updates should be
serialized on the registrar side. Am I correct?

For those who want to get a quick understanding of this thread, there are
three issues Eric raised in his email. [Eric, please correct me if I
misunderstood your views.]:

(1) Is the registrar allowed to cancel a pending update before it is
confirmed of the execution of the operation?

(2) Is the registrar allowed to issue multiple updates to the same object
before it is confirmed of the execution of the first operation?

(3) What is the mechanism to correlate messages in pending update situation?

To some extent, some of these questions have touched upon the overlapping
areas between registry policy and protocol mechanism. I would like to hear
more discussions from the list.

Please see my comments in line.

--Hong

-----Original Message-----
From: Eric Brunner-Williams in Portland Maine
[mailto:brunner@nic-naa.net]
Sent: Friday, March 01, 2002 4:02 AM
To: Liu, Hong
Cc: 'Eric Brunner-Williams in Portland Maine'; 'Hollenbeck, Scott';
'ietf-provreg@cafax.se'; brunner@nic-naa.net
Subject: Re: Pending Update 



>                                                           ... The
registrar
> may not serilize the update operations on an object, i.e., wait for the
> first update to be completed before requesting another. At least we are
not
> making such an assumption.

[snip...]

How does a registrar revoke a hung job (an asychronous write)?  

<HL> 
Whether revocation of a pending update is allowed or not in EPP is an issue
independent of the serialization of update requests from the registrar side.
So we have a decision to make. Then we can talk about possible solutions.
<HL/>


Wouldn't it be simpler to simply do a transport mapping for an existing
filesystem (over tcp) with the semantics you require?

As you observe, data bases do do this (serialize operations against object).

Putting a data base, or at least this bit of semantics, "into" the protocol
is an option. It seems simpler to observe, as Scott did, that asynchronous
exchanges might result in higher error rates if a client issues commands
without waiting to receive the responses for prior commands, rather than to
attempt to guarantee that they won't.

<HL>
Good point. Forcing the serialization of multiple updates on the same object
on the registrar side does simplify the problem, especially on the registry
side. I would like to hear from the registrars what they think of this
issue.
<HL/>

> Do we need more information from EPP, such as time-stamp ...

Scott and Klaus discussed roll-back last September, on-list, and I privately
discussed temporal identifier requirements with Scott on 8 Feb '01.

<HL>
Actually, I was talking about a different problem. Since pending update is
an "extended" transaction, meaning beyond the simple request-response
two-way handshake, we need to have a way to correlate the messages in the
same transaction. The transaction ID can be used for that purpose IF we make
it mandatory in pending update requests. This is another issue we need to
address.
<HL/>

Eric