Re: Statements of EPP "missing methods"
This is an answer to Mr. Hollenbeckâs posting on ICANNâs Forum for Public Comments for DotNet RFP Applications regarding an EPP extension proposed by CORE++ that allows the registrar to retrieve the result of a previously submitted command to deal with the situation of a lost EPP response, e.g. due to communication problems. The author of this answer is involved in the application submitted by CORE++ and responds on behalf of CORE++. For all entities operating with large amounts of data, a reliable data processing is essential. Decades ago, the processing model of transactions has evolved, which provides the so-called ACID properties -- atomicity, consistency, isolation, and durability. The value of this model is indisputable. While this model has been extended to operate on multiple components via the distributed transaction model, up to now there is no established standard that is able to cope with loosely coupled systems not operating in a single sphere of responsibility, as they typically appear in the Internet. New standards are in development, like the Business Transaction Protocol [1], but are still far from being ready for deployment. Looking at the complexity of the related problems, it is understandable that most current protocols, including RRP and EPP, do not provide reliability comparable to the distributed transaction model. While EPP highly improved the flexibility and extensibility in comparison to RRP and other registration protocols, it added scarcely anything in the context of reliability. As a result, CORE++ regards EPP as a valuable step but not as an endpoint of the development of domain registration protocols. In so far, the proposed small extension is not aimed to cure the inherent problems, but to cure the symptoms only. The claim of Mr. Hollenbeck, EPP commands would share the property of idempotency, is entirely based on the registry perspective and is not maintainable in the global view. The term idempotency describes the property that a successful operation can be repeated without any side effects. It has its roots in the research of database systems and is considered as a building block for reliability, but does not provide reliability by itself. Mr. Hollenbeck ignores the fact that the response, which the registry generates on the execution of the request, is an integral part of the operation and a side effect. He himself gives an example that EPP does actually not have the property: If a command (e.g. the creation of the domain) is executed a second time, an error is reported. According to the rules of idempotency, a success would have to be reported again. In addition, the assumption that the first command was executed if the second attempt fails is just wrong. In the example of a domain creation, some time may pass between the first and second attempt. If the first attempt actually failed, another registrar may successfully create the domain in the meantime. In this situation the second attempt would also fail, although the first attempt was not executed at all. This is not an theoretical example -- after the redemption phase of a domain or during the introduction of new domains (e.g. because of new allowed characters for IDN), there is a contention between multiple registrars over a specific domain. While in most cases it is not entirely impossible for a registrar to find out with standard EPP whether a previously submitted command, whose response has been lost, has been executed or not, it is rather cumbersome. For each command type, a different sequence of checks has to be performed. It complicates the implementation of a reliable EPP interface a lot, providing an additional hurdle for small registrars with limited budget. It also causes communication problems to be handled in the application layer where it should not be done. In contrast, the proposed EPP extension allows a handling of communication problems in a consistent manner in the communication layer. There is no need for the communication layer to understand the commands in detail to provide this service. Neither a registrar nor other registries are required to support this extension. It is fully optional. The questions that Mr. Hollenbeck raises are legal, but have already been considered. While the extension itself does not define any limitations, it is reasonable to assume that the registry policy will limit the availability of previous responses to a certain time frame and also to a certain set of commands (typically to so-called âwriteâ operations). Responsible registries will store commands and their responses for some time anyway in order to be able to track down problems and to provide means for internal quality assurance. While this may be non-optimal from an academic viewpoint, it is much better than ignoring this problem at all -- as EPP does it today. It is clear that no response can be provided for duplicate client transaction identifiers. However, providing unique identifiers for each command is not rocket science. Registrars who want to use this feature wonât have any problems with it. It is a known fact that standardization processes tend to agree on the lowest common denominator, especially if the panel consists of people with diverging opinions. EPP is no exception from this. Based on the experience gained as a registrar of several registries, staff members of CORE (which is part of CORE++) have proposed the addition of similar functionality within the ProvReg working group. This addition has been rejected by Mr. Hollenbeck with the same arguments as today, ignoring any counter arguments. As a consequence, the fruitless discussion had been abandoned, especially as EPP does allow the implementation of such a functionality as an extension. CORE++ is fully committed to support EPP. However, EPP is not considered as perfect and final in respect to the evolution of domain registration protocols. CORE++ views the proposed extension as a valuable means to allow the improvement of the quality of service and overall data integrity on the side of the registrar until a more suitable standard has been defined and established -- either within EPP or by a completely new protocol. Regards, Klaus Malorny
|