Network Working Group A. Sullivan Internet-Draft Afilias Expires: January 2, 2006 July 2005 Some experiences from implementing the Extensible Provisioning Protocol draft-sullivan-epp-experience-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 2, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo presents some experiences of a registry operator using the Extensible Provisioning Protocol (EPP). Some limitations of the protocol definition and associated documents are identified, and some alterations are suggested. Sullivan Expires January 2, 2006 [Page 1] Internet-Draft EPP implementation experience July 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Experiences . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Experiences at Afilias . . . . . . . . . . . . . . . . . . 4 3. Mapping flexibility limitations . . . . . . . . . . . . . . . 6 3.1 RFC 3731 vs RFC 3915 . . . . . . . . . . . . . . . . . . . 6 3.2 Alternative policies for handling nameservers . . . . . . 6 3.3 Granularity of the command . . . . . . . . . . . 7 3.4 Message queue priority . . . . . . . . . . . . . . . . . . 8 4. Suggested alterations . . . . . . . . . . . . . . . . . . . . 9 4.1 Status values and prohibitions . . . . . . . . . . . . . . 9 4.1.1 Suggestions . . . . . . . . . . . . . . . . . . . . . 9 4.1.2 Objections and alternatives . . . . . . . . . . . . . 10 4.2 Polling . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2.1 A priority indication and response . . . . . . . . . . 11 4.2.2 Other polling approaches . . . . . . . . . . . . . . . 12 5. Internationalization Considerations . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . 17 Sullivan Expires January 2, 2006 [Page 2] Internet-Draft EPP implementation experience July 2005 1. Introduction The Extensible Provisioning Protocol (EPP) was first published as [RFC3730] in March 2004, along with an associated Domain Name Mapping ([RFC3731]), Host Mapping ([RFC3732]), and Contact Mapping ([RFC3733]). In September 2004, an additional Mapping, for the Domain Registry Grace Period, was published as [RFC3915]. While EPP is a generic object-provisioning protocol for repositories, its initial application (and the impetus for its development) was in provisioning domain names for registration to DNS zones. The concurrent publication of Domain Name and Host Mappings is consistent with that use. Because of that history, the object status and command definitions in [RFC3731] include limitations that express the community understanding of best domain name registration practices at the time of publication. Subsequent experience has revealed a number of areas where the protocol could use improvement in order to offer the generic provisioning services it intends to offer. 1. The creation of the "Redemption Grace Period" (supported under EPP by [RFC3915] requires that certain provisions of [RFC3731] be violated in order to offer the new service. 2. Experience with implementation suggests that status values may be insufficiently granular. 3. Experience with the poll queue mechanism suggests that a more sophisticated mechanism might be useful, or that the requirements for implementation should be relaxed. 4. Experience with commands suggests either that status values are too coarsely-grained, or that another set of commands entirely needs to be defined. Each of these limitations is discussed in more detail below. Each one would be serious in its own right; but the overall effect of the combined limitations is such that the protocol is not as generic as it aims to be. To the extent that EPP does not provide the flexibility that registries need to accommodate their business objectives and procedures, registries will adopt other protocols. If that happens, the original goal of a common registry protocol will not be met. Sullivan Expires January 2, 2006 [Page 3] Internet-Draft EPP implementation experience July 2005 2. Experiences 2.1 Experiences at Afilias Afilias began experimenting with EPP on the basis of the Internet Drafts from the provreg working group as early as 2001. Afilias provided a working EPP implementation for use by registrar-customers by 28 September 2004. These experiences have led to the conclusion that there are some unfortunate inherent limitations to the protocols as written; these are outlined below. 1. While adding extensions to the functionality defined in the protocol and mapping RFCs is relatively simple, extending those documents in ways that were not foreseen when they were written has proven to be either difficult or impossible. A good example of this is the conflict between [RFC3731] and [RFC3915] (see Section 3.1). Afilias's own attempt at implementing ICANN's Redemption Grace Period, prior to the creation of [RFC3915], also required a violation of [RFC3731]: allowing a domain to be "undeleted" after a command has been successfully processed is simply in violation of the specification. 2. The message queue and command are too limited in the functionality they offer to be very useful to many users, so the message queue content all has to be duplicated using some other notification mechanism. For example, in Afilias's experience, many clients continue to rely on emailed notices to alert them of transfer requests, even though the message queue contains the information. That is partly because email is easily filtered, and can therefore cause certain notices to be processed ahead of others. The message queue, by contrast, can cause a notice of a pending transfer to wait until the delivery and acknowledgement of messages noting the successful completion of a different transfer. (More on the matter of this limitation is discussed below; see Section 3.4.) 3. Inter-registrar host and nameserver issues are a problem. The EPP RFCs are written in such a way that many alternative policies are foreclosed, so a solution, if it ever comes up, will require changes to the protocol itself or to the mapping RFCs. It is undesirable for the protocol to dictate policy this way. 4. The command does not really behave in practice in the way that other object-manipulation commands do. As a practical matter, alters one of several object attributes, whereas most transform operations modify either the whole object, or a predictable and small number of the object's attributes. For example, where always directly modifies at most Sullivan Expires January 2, 2006 [Page 4] Internet-Draft EPP implementation experience July 2005 the domain object's expiration date and sponsor, may modify attributes as diverse as the domain's name servers, contacts, authInfo, or even (in the case of [RFC3915]) pendingDelete status. Yet a prohibition on update remains a prohibition of any update to the object, even though only one or two attributes may be the target of the prohibition. Sullivan Expires January 2, 2006 [Page 5] Internet-Draft EPP implementation experience July 2005 3. Mapping flexibility limitations 3.1 RFC 3731 vs RFC 3915 One of the status values that [RFC3731] defines for a domain object is pendingDelete. In many cases, repository policy requires additional activity before a command can be processed. In many domain repositories, some period of time must elapse before the processing is completed. Under such conditions, the receives a response of 1001 (Command completed successfully; action pending: see [RFC3730] ), and the off-line activity is invoked. This activity may simply be the passage of time. Transform commands against an object with pendingDelete status set are required to be rejected, per [RFC3731]: "With one exception, transform commands MUST be rejected when a pendingCreate, pendingDelete, pendingRenew, pendingTransfer, or pendingUpdate status is set." In effect, then, when a command is issued against a domain, there are two possibilities for activity in the repository: either the domain object is immediately deleted from the repository (with response 1000), or the domain object has the pendingDelete status set, and the client software receives response code 1001. In order to support the ICANN redemption grace period, [RFC3915] extends [RFC3731] to provide the ability to cause the domain to be restored to the repository. The difficulty is that such an command (which is a transform command) is required to fail, because of the pendingDelete status on the object. In addition, [RFC3915] is not allowed to extend [RFC3731] in a way inconsistent with the existing [RFC3731], because that is not part of the extension mechanism defined by [RFC3730]: "Protocol commands and responses MAY be extended by an element that contains additional elements whose syntax and semantics are not explicitly defined by EPP or an EPP object mapping." Therefore, either [RFC3731] must change, or [RFC3915] is unimplementable. The above would be nothing more than a quibble, except that this sort of trouble will occur in any case where extensions are desired, and the extension intends to alter the behaviour defined by the parent mapping. Following are some more examples of possible use-cases foreclosed by the existing documents. 3.2 Alternative policies for handling nameservers It might be desirable to foster some sort of off-line negotiation or Sullivan Expires January 2, 2006 [Page 6] Internet-Draft EPP implementation experience July 2005 processing of commands when a host is associated with a domain as its nameserver. No one to our knowledge has yet proposed a nameserver-management regime that solves all the resolution and lame delegation problems in DNS; but the relationship between hosts and domains, as described in [RFC3731] and [RFC3732], more or less enshrines lame delegation as a fact of life, and provides no allowance for policies that require that commands cause additional processing to ensure correct DNS entries. 3.3 Granularity of the command It is frequently the case that one desires to limit some subset of commands. EPP commands allow client software to make changes to only particular elements of the manipulated object; but the serverUpdateProhibited and clientUpdateProhibited status values block any update from being applied to the object with that status. This hampers the opportunities for control of an object. For instance, a registry might reasonably wish to implement a policy under which name servers MAY be changed on a domain object but no other changes are permitted. The serverUpdateProhibited status would not allow such a change, but no other status is available to enforce the desired behaviour. In Afilias's experience, for instance, it has been occasionally desirable to prohibit changes to registrant data associated with a domain during a period in which non-technical considerations were being satisfied. In such cases, Afilias had to choose between, on the one hand, violating the integrity of the serverUpdateProhibited status value on the domain object in order to allow client software to manage nameserver associations; and prohibiting nameserver management for domains that had unresolved non-technical issues, on the other. Creating support for more granular controls of breaks the symmetry between prohibited status values and commands. But since the EPP command is so much more versatile than the other commands, a different approach is needed to manage it. One might argue that a server that needs more granular control should not use serverUpdateProhibited, and should instead define the more granular prohibitions in an extension. This is an appealing idea, but has the disadvantage that every repository operator may come up with a different extension. These divergent extensions will not cleave to the original goal of EPP: the desire was for client software to be able to work more or less unchanged from one repository to another. That said, it is easy to appreciate that breaking the direct correlation between a command and its prohibition would be at least counterintuitive, and at worst could cause trouble Sullivan Expires January 2, 2006 [Page 7] Internet-Draft EPP implementation experience July 2005 with extending the base documents in the same way as discussed in Section 3.1. 3.4 Message queue priority It is sometimes desirable to offer service messages in a priority- based order. The description of the EPP command in [RFC3730] makes the server message queue a FIFO queue. Some service messages, however, are of greater urgency than others, or may be of greater interest to clients. There may be reasons to prefer the simple (FIFO) nature of the message queue design in some cases. Unfortunately, [RFC3730] also requires that service messages MUST be generated "for all clients affected by an action on an object," where that action either is performed on an object not in direct response to a client request, or where the actions of one client may indirectly affect a second client. This requirement tends to flood the message queue with a large number of messages that are not at all urgent for clients, and further reduces the value of the message queue to the clients. For instance, Afilias's experience indicates that clients are much more sensitive to transactions that entail monetary loss than those that do not. The requirements of the message queue, however, may mean that a large number of notices of domain objects completing their pendingDelete period (and therefore disappearing from the registry) be acknowledged by the client, and dequeued, before the client can find out that a large number of automatic domain renewals have been processed (resulting in financial charges to the client). As a result, Afilias has found itself in the position of having to choose between conformance with the letter of the protocol, and satisfying client demands. The additional provision that "Servers MAY implement other mechanisms to dequeue and deliver messages" is, moreover, just confusing. Perhaps it makes the message queue requirement OPTIONAL, but in a round-about manner. If that is the case, it would be preferable to make the command OPTIONAL, or make generation of service messages OPTIONAL in some cases. Sullivan Expires January 2, 2006 [Page 8] Internet-Draft EPP implementation experience July 2005 4. Suggested alterations In principle, since EPP is extensible, each of the troublesome cases (as well as any not enumerated here) could be rectified by an extension. In the cases above, the extensions mechanism unfortunately does not permit the desired extensions, because the extension would be in contravention of the base document. This restriction on extensions seems to be sensible, because it is paradoxical to violate a base document in order to extend it. It appears, however, that some improvements can be made by making the protocol less strict, on the grounds that many cases currently defined by the protocol or mapping documents are in fact cases of server policy. 4.1 Status values and prohibitions 4.1.1 Suggestions In general, status values should be aligned with exactly one effect on a repository object. For instance, the prohibition against deleting hosts associated with any other object should be lifted, and the matter relegated to repository policy. If the repository wishes to restrict deletion of a host object when the host is associated with any other object, the repository may use the status serverDeleteProhibited. This approach is generalisable: there is no reason that pending* status values need prohibit further action, although in most cases it will be desirable for the server to set prohibitive status values on objects with pending action. Nevertheless, that a domain object is pendingTransfer is no reason to prohibit, at the protocol level, updating its name server associations. By removing the restriction on what may happen when a domain has its pendingDelete status set, the conflict between [RFC3731] and [RFC3915] is resolved. For similar reasons, it is desirable to align the list of prohibited status values to correspond with the actions that may be taken against a repository object. For instance, serverUpdateProhibited and clientUpdateProhibited status values on a domain object prevent a very wide array of activities. If we break apart the serverUpdateProhibited and clientUpdateProhibited status values in [RFC3731] such that each resulting status prohibits exactly one thing, we get the following: Sullivan Expires January 2, 2006 [Page 9] Internet-Draft EPP implementation experience July 2005 clientUpdateNSProhibited,serverUpdateNSProhibited: Requests to update the object nameserver associations MUST be rejected. clientUpdateContactProhibited, serverUpdateContactProhibited: Requests to update the object contact associations MUST be rejected. clientUpdateStatusProhibited, serverUpdateStatusProhibited: Requests to update the object status values MUST be rejected, except for requests to remove this status. clientUpdateRegistrantProhibited, serverUpdateRegistrantProhibited: Requests to change the object registrant MUST be rejected. clientUpdateAuthInfoProhibited, serverUpdateAuthInfoProhibited: Requests to change the object authInfo MUST be rejected. This approach also has the happy consequence that extending (in this case) the domain mapping with additional commands suggests a straightforward addition to the status values as well. In this way, the mapping remains easy to understand. 4.1.2 Objections and alternatives One might object to narrowing the applicability of each status value as being cumbersome and complicated. On such a view, it is preferable to grant that some status values entail that certain other actions are foreclosed, for the sake of the simplicity of implementation. But while this is true in many cases, it need not be true in every case. Moreover, this foreclosure is really a matter of server policy and not of protocol, and so should be left up to the implementor, even if it makes the protocol marginally more difficult to implement. One might object to the addition of attribute-specific updateProhibited values, on the grounds of consistency: the other prohibitions are all command-based. Commands aside from update, however, generally do only one thing: a domain is either deleted or not, according to whether the command completes or fails. Only is special, in that it updates parts of an object and leaves the rest untransformed. That said, the proposed modification is admittedly an ugly one. Additional evidence of need is probably Sullivan Expires January 2, 2006 [Page 10] Internet-Draft EPP implementation experience July 2005 warranted before making a change here. 4.2 Polling 4.2.1 A priority indication and response Finally, in order to improve the utility of the EPP command, it is desirable to add one OPTIONAL "priority" attribute to the command. In case the attribute is not present, the value of the "priority" attribute is 0. If the message queue is not empty, a successful response to a command MUST return the first message from the message queue having an identical priority. If the value of the "priority" attribute is the special value 1000, the command MUST return the first message from the message queue having the highest priority. Example modified command: C: C: C: C: C: ABC-12345 C: C: Sullivan Expires January 2, 2006 [Page 11] Internet-Draft EPP implementation experience July 2005 A acknowledgement response notes the number of messages remaining in the queue and the ID of the next message available for retrieval for each priority: S: S: S: S: S: Command completed successfully S: S: S: S: S: ABC-12346 S: 54322-XYZ S: S: S: 4.2.2 Other polling approaches One might object to the complication of the poll queue mechanism. But there is nothing that requires implementers to use a priority other than "0", so a single FIFO queue is always still available to implementers if that is preferable. Sullivan Expires January 2, 2006 [Page 12] Internet-Draft EPP implementation experience July 2005 5. Internationalization Considerations This memo introduces no internationalization considerations beyond those in [RFC3730]. Sullivan Expires January 2, 2006 [Page 13] Internet-Draft EPP implementation experience July 2005 6. IANA Considerations This memo introduces no IANA considerations beyond those in [RFC3730]. Sullivan Expires January 2, 2006 [Page 14] Internet-Draft EPP implementation experience July 2005 7. Security Considerations This memo introduces no security considerations beyond those in [RFC3730]. Sullivan Expires January 2, 2006 [Page 15] Internet-Draft EPP implementation experience July 2005 8. Acknowledgements The author wishes to thank Scott Hollenbeck and John Klensin for some very helpful remarks on predecessors to this document. Howard Eland, Janusz Sienkiewicz, and Michael Young each provided remarks about Afilias's experience in implementing EPP. Any mangling of their clear thoughts is the responsibility of the author. 9. References [RFC3730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", RFC 3730, March 2004. [RFC3731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", RFC 3731, March 2004. [RFC3732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Host Mapping", RFC 3732, March 2004. [RFC3733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Contact Mapping", RFC 3733, March 2004. [RFC3734] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Transport Over TCP", RFC 3734, March 2004. [RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)", RFC 3915, September 2004. Author's Address Andrew J. Sullivan Afilias 204-4141 Yonge Street Toronto, ON M2P 2A8 CA Phone: +1 416 646 3304 Email: andrew@ca.afilias.info Sullivan Expires January 2, 2006 [Page 16] Internet-Draft EPP implementation experience July 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Sullivan Expires January 2, 2006 [Page 17]