From: Dave Crocker Sent: Tuesday, 2 October 2001 1:40 AM To: jo.lim@auda.org.au Subject: Comments on: "dotAU Registry Technical Specification" Importance: High Hello. The following is intended as input for today's Technical Review. Comments on: "dotAU Domain Administration Ltd: Registry Technical Specification" By: D. Crocker Brandenburg InternetWorking 1 October 2001 The dotAU registry authority, auDA, seeks to specify technical requirements for the dotAU registry operator, and to specify related requirements for second-level registries under dotAU. The proposed Registry Technical Specification is a careful and thorough document, offering the explicit intent to use standards-based technology wherever possible, while also paying attention to differences the world of dotAU might have from other Domain Name registry environments. The comments offered here are based on a strong appreciation of the difficulty in balancing competing concerns when creating such a specification. These comments focus on protocol issues for registry/registrar interactions: 1. Make vs. buy -- choosing a protocol 2. Competition and procedures 3. Protocol development effort 4. Data encoding tradeoffs 5. IETF standards process 6. EPP status 7. Walking the tightrope 1. Make vs. buy -- choosing a protocol The current Registry Technical Specification states an intention to adopt the Extensible Provisioning Protocol (EPP), under development by the IETF. The Technical Specification cites recommendations from the Competition Panel, in favor of EPP and XML, noting: "This is important in a multiple registry environment, where not all registries will provide the same features. It also allows support for the policy rich environment to be incorporated in the protocol (e.g. incorporating sign-off procedures from an independent body to approve certain domain names), and will support the different requirements of the various 2LDs within dotAU." Concerns raised in the Technical Specification draft are: (a) "There is considerable uncertainty as to the final arrangement of Registries operating in dotAU and no guarantee that it will be a multiple Registry environment; (b) "It is envisaged that any 'sign-off procedures' in a Registry will be fully automatic decisions and the application of policies for domain name approval will be the responsibility of Registrars only; (c) "There is no indication that different requirements of the 2LDs, within dotAU, will necessitate any intervention on the part of a Registry; (d) "EPP has not yet been adopted as an industry ; standard and (e) "There is no public domain implementation of EPP currently available." Hence the Technical Specification concludes that EPP is not yet appropriate for use by dotAU. The Specification then proceeds to define a new protocol, the Interim Registry Registrar Protocol (IRRP). The remainder of the current note considers these concerns and the pragmatics of available choices. 2. Competition and procedures In considering possible registry competition and possible variations in procedures and policies, it is reasonable to pay attention to uncertainty and flexibility, such as noted in the above excerpt, items a through c. However, these considerations represent only one perspective. The Technical Specification notes that dotAU well might operate without competition and well might operate with a streamlined and automatic, approval procedure. The mere fact that the Technical specification offers only possibilities, rather than certainties, leaves open the potential that these factors will be relevant within dotAU. However, even a simplified, non-competitive dotAU environment is not free from concern about the factors cited in the Competition Panel recommendations. A registrar for dotAU or a dotAU 2LD may well be a registrar for other domain registries, and each is likely to have its own set of policies. If the dotAU world has its own protocol, then any of its registrars wanting to provide service for other domains must support at least one, additional protocol. This requirement places the dotAU- related registrar at a competitive disadvantage, since their cost of doing business will be higher than for a registrar having to support fewer protocols. That is, there is already a competitive registry environment, with respect to the global Internet. Having dotAU proceed down an independent path will penalize all dotAU-related entities that wish to conduct business on behalf of other portions of the Domain Name Service. The dotAU technical work will be unique to dotAU and, therefore, will constitute a "surcharge" for doing business with dotAU. 3. Protocol development effort There is no such thing as a simple or inexpensive protocol, when applied to a serious, multi-organization operating environment. In the software development world, pure engineering costs are roughly fifteen percent of the operating costs for the company. Similarly, designing and programming software for a protocol represent a fraction of the cost for developing a production level service. Other major sources of effort and expense include: * Ensuring that the protocol works correctly * Ensuring interoperability among different implementations * Integrating the software with other service and support software by each participant Even for a single organization, these compose a substantial burden. For any environment with multiple organizations, the burden often is worse than additive, due to the juggling act that results from having to coordinate among all the participants. In other words, a new protocol, used in any sort of open environment, always carries a remarkable and onerous barrier to entry. This is the reason that the Internet tends to re-use existing protocols, for new services, rather than to design new and more tailored protocols. Given the multi-participant nature of a protocol, this onerous barrier is worse than the difference in effort between producing basic demonstration software, versus producing a full, commercial product. 4. Data encoding tradeoffs Much is made of XML. It has achieved the kind of notoriety that often signals hype rather than useful reality. Ultimately, XML is nothing more than a standard syntax, or perhaps even less, a standard lexical analyzer. Still, having that mechanism be a standard permits enormous long- term benefits. * It eliminate such debates as whether to separate things with a comma or a semicolon. * It eliminates having to build, debug and support a parser (or lexical analyzer). * It eliminates questions about handling multiple character sets. * It eliminates questions about extensibility for the syntax. So, what is left for a designer is to focus on the real semantics of their task. That said, it could be argued that the data encoding syntax specified for IRRP has the same benefits as XML. It is textual and similar to the Internet mail header syntax, which has been in use for more than twenty-five years. Indeed there is clearly nothing terribly wrong with the IRRP syntax approach, other than lacking well-supported parsers and lacking support for multiple character sets. (The standard for Internet mail headers, that supports multiple character sets, has never gained wide acceptance.) The biggest problem is that, again, the syntax will be different from that emerging for registries elsewhere on the Internet. 5. IETF standards process The Technical Specification correctly expresses concern that EPP is not yet a standard. The next section will discuss the details of EPP, itself. This section considers general aspects of the IETF process. As with any large standards group, things in the IETF progress slowly... sometimes very slowly. Worse, its process has four levels of standardization. The first in best called "in development". That is, the specification is not yet on the standards track, but can have substantial support in the IETF, via the working group that is developing it. Assessing amount of participation, duration of the effort, and complexity of the resulting specification can give useful indicators for likely success of the work. Limited participation bodes poorly for broad appeal. Protracted working group effort bodes poorly for reaching conclusion in a timely manner. Complex specifications are difficult to implement correctly, and usual signal the inclusion of unnecessary features. A document enters the standards track as a Proposed Standard, then proceeds to Draft Standard and finally (full) Standard. Proposed Standard means that the initial specification is complete. Draft Standard means that at least two implementations have interworked. (full) Standard means that the protocol has gained wide acceptance (and use.) Note that the last status level is, in effect, a post hoc blessing of the specification. In fact the first hurdle, Proposed Standard, is the most difficult. Although a specification can be subject to minor changes, when going to Draft Standard, there is strong pressure to limit the amount of change. Indeed, major changes require re-starting the standards sequence. Therefore, the important questions about EPP standards status should be with respect to Proposed, rather than (full) Standard. 6. EPP status In addition to the procedural and technical issues cited in the previous section, a factor to consider is the degree of innovation, present in a specification. The more innovation, the more surprises. Some, or most, of such surprises with a new protocol are problems. EPP is based on the earlier, RRP production protocol used by Verisign/NSI. Hence it has several years of very large- scale use. In fact, the Provreg working group has been diligent in limiting changes to focus on fixing problems with RRP and adding relatively few features. Hence it is extremely helpful that the editor of the EPP specification is a Verisign employee. EPP work is reaching completion. It was sufficiently far advanced to permit pre-standardization collaboration among current and new ICANN registry operators. Due to the deadlines some have faced, for initiating TLD registry service, each has decided to pursue independent implementations, with no effort to ensure interoperability. However the different protocols are more similar than different. Rather than diverging in terms of the basic protocol, registries appear likely to differ in the options they support, such as transport and asynchrony. 7. Walking the tightrope A general comment that must be made at the outset is simply that "interim never is." New protocols -- even when they are simple -- take time to develop and deploy. Once they fill their intended operational gap, they create a massive barrier to entry for any replacement. Abstractly, dotAU has three choices: * Invent a new protocol * Use an existing protocol * Use an early version of the emerging standard A new protocol is the most likely to be tuned to the specific requirements of a specific registry. Hence it is definitely reasonable to develop a new protocol, if dotAU believes that its requirements are substantially unique. However neither the report from the Competition Panel nor the Technical Specification offer a claim of uniqueness. Instead the technical focus of concerns in the Technical Specification is about the maturity of EPP. The usual reason for rejecting use of an existing protocol is that none is seen as coming close to satisfying requirements for the intended service. The Technical Specification document provides an excellent table, summarizing technical details for gTLD and Commonwealth ccTLD registries. However the document does not explore adequacy of existing solutions, by the other ccTLDs. The most likely problems with the cited ccTLD registry mechanisms are limitations to scaling and/or performance. For example an email-based mechanism is excellent for low- volume transactions that can tolerate high latencies. Although email technology is capable of providing relatively rapid response -- on a par with Instant Messaging -- existing services rarely attain that level of liveliness. Larger registries seek to provide much shorter response time and to process a large number of transactions. Hence they need an interactive transport service. DotAU appears likely to warrant an interactive service, although an email alternative is always useful for the more modest registrars. The benefit of using an early version, of an emerging standard, is that the effort to move up to the final version of the standard is minimized. Indeed, having dotAU participate in EPP would contribute to its more rapid maturation. This applies both to operational testing and to the possibility of contributing to one of the open source implementations of EPP. Rather than following a unique path, dotAU has an opportunity to help both itself and the rest of the Internet community. It can choose to make its "interim" protocol an early version of EPP, thereby helping to ensure the success of that protocol. The effort of providing an early EPP is certain to be no more than for creating and deploying an IRRP. One might debate subtle points about protocol complexity. However the real expenses of a new protocol are not in the protocol engine, but in the overall system development. To the extent that the world of dotAU determines that its requirements are simpler than EPP, it would be worth pursuing an IRRP that is a profile of EPP -- that is, a subset of the EPP specification -- rather than an entirely new protocol. Such a profile approach has two excellent properties: It permits dotAU to migrate to full EPP easily, whenever that becomes appropriate, and it provides the Internet community with an improvement in EPP, in the form of a simplified version that will ensure broader community utility. ---------- Dave Crocker Brandenburg InternetWorking