RE: Pending Update

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

Eric,

Thanks for the input. Please see my comments in line marked as <HL>.

Regards,

--Hong

-----Original Message-----
From: Eric Brunner-Williams in Portland Maine
[mailto:brunner@nic-naa.net]
Sent: Thursday, February 28, 2002 1:08 PM
To: Liu, Hong
Cc: 'Hollenbeck, Scott'; 'ietf-provreg@cafax.se'; brunner@nic-naa.net
Subject: Re: Pending Update 


> Another issue that arises in the context of asynchrony is the notification
> mechansim ...

push vs poll.

For some reason, and we are indifferent to which, the state of a datum in
the registrar-registry "shared data" is inconsistent, and the instance of
the datum in the registry is later than the instance of the datum in the
(sponsoring) registrar, and we believe that time goes forward most of the
time.

<HL>
Certainly, having a push in place will be of great help. However, my
previous email was based on the current EPP-06, where push is not avaialble.
In fact, what I implied in the email is that it would be nice to return the
snapshot of the object state (not status) for the asynchronous update right
after the operation is completed. Whether that information is put into the
queue (i.e., poll) or pushed to the requesting registrar, is a matter of
messaging. If we do it right, the information returned should be the same
one way or the other. Of course, push seems to be more natural in this
context if it is available.
<HL/>

> Is this an implementation issue or an EPP issue? I would like to hear from
> you and others on the list. Thanks!

push vs poll. Covered in _extensive_ detail in this list. 

[HL] I am aware of that. Again, I am working under the assumption that push
is not available, at least not yet. See above.

> ... multiple asynchronous update operations on the same object.

How does this condition non-trivially arise?

<HL> 
Depending on the how often updates are made,  how long the time interval is
between the request is received and the operation is performed, and how soon
the requesting registrar inquires the result of the operation. 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.
<HL/> 

Is the registry providing synchronization services for a registrar that is
making multiple writes against an object it sponsors, or is this some form
of "dualing registrars" and non-sponsored objects? Please clarify.

<HL>
In this context, I am talking about the sponsoring registrar only. If by
registry synchronization service, you meant that the backend serilizes the
write operations against the same object, then my asnwer is yes as most
databases will do the same. I am not saying it is trivial, but it can be
done.

Do we need more information from EPP, such as time-stamp, to make it easier
for the registry? It certainly would help in the long run as we expand the
usage to EPP to areas other than registry-registrar. I leave it to the WG to
decide whether we want to do it now or later. 
Maybe the transaction ID can serve the purpose for now.
<HL/>

Eric