To:
"'Hollenbeck, Scott'" <shollenbeck@verisign.com>, "'ietf-provreg@cafax.se'" <ietf-provreg@cafax.se>
From:
"Liu, Hong" <Hong.Liu@neustar.biz>
Date:
Thu, 28 Feb 2002 11:03:49 -0600
Sender:
owner-ietf-provreg@cafax.se
Subject:
RE: Pending Update
Scott, Thanks for suggesting a solution to this problem. I like your proposal for adding a new response code "Command completed successfully; action pending" and adding a new status "pendingVerification" to the host object. Just to push this a bit further. It would be nice that EPP provides generic mechanisms for asynchronous operations for object creation/update/deletion. (Whether such mechanisms will be used is a matter of registry policy, which is outside of the scope of EPP.) For example, your proposal can also be applied to the contact object. In this case, the new status code will have to be defined in the contact object as well. Another issue that arises in the context of asynchrony is the notification mechansim after the operation is indeed completed by the registry backend. For create and delete, a simple yes or no answer may suffice. For update, the situation is a bit more complex. The registrar may want to know more about whether the changes are made correctly according to the request. Of course, it can use the <info> command. But doing so may generate unnecessary traffics and place burden on the backend database. More importantly, it may not get the correct snapshot of the object state in the database in the face of multiple asynchronous update operations on the same object. Is this an implementation issue or an EPP issue? I would like to hear from you and others on the list. Thanks! Cheers, --Hong -----Original Message----- From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com] Sent: Thursday, February 28, 2002 9:39 AM To: 'Liu, Hong'; 'ietf-provreg@cafax.se' Subject: RE: Pending Update Hong, There's a somewhat analogous situation related to creating domain names in that sometimes the object really shouldn't be instantiated until after some manual process determines that the domain is "valid". Right now the specs include a domain status of "pendingVerification" to note that a domain object create command has been processed, but the action hasn't yet really be completed. As for the discussion requested below, I think it might be helpful to add a response code that says something like "Command completed successfully; action pending". We have to separate command completion from back-end processing such that we maintain the OLTP ACID properties (basically that commands have no partial success or partial failure), so we need to note that the command has been received and processed but that something else needs to happen before some back-end stuff completes. We could also add a "pendingVerification" status to the host mapping to note the situation in subsequent <info> command responses. I'm not going to touch the documents again until we get some feedback from the IESG, but adding a new response code and a new host status could well be done when dealing with IESG comments. -Scott- > -----Original Message----- > From: Liu, Hong [mailto:Hong.Liu@neustar.biz] > Sent: Wednesday, February 27, 2002 12:53 PM > To: 'ietf-provreg@cafax.se' > Subject: Pending Update > > > The current update operation defined in EPP is basically a > two step process: > First, an update request is made by the registrar to the > registry. Second, > the registry either rejects the request or performs the > operation; and a > response is sent back to the registrar. > > A pending update refers to a four step process: First, an > update request is > made by the registrar to the registry. Second, the registry > acknowledges the > request to the registrar but does not take action for the > moment, i.e., the > update is pending. Third, upon further authorization, the > registry either > rejects the request or performs the operation; then posts the > result to the > message queue. Fourth, the registrar polls the message queue > to retrieve the > result of the operation. > > Conceptually, pending update is very similar to the transfer operation > currently defined in EPP. > > I would like to hear from the list how such operation is > supported by EPP. > If this topic has been discussed before on the mailing list, I would > appreciate pointers to the previous discussions. >