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 <update> 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 <update> 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 <domain:delete> command has been successfully
       processed is simply in violation of the specification.

   2.  The message queue and <poll> 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 <update> command does not really behave in practice in the
       way that other object-manipulation commands do.  As a practical
       matter, <update> 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 <domain:transfer> 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, <domain:update>
       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 <domain:delete> command can be
   processed.  In many domain repositories, some period of time must
   elapse before the processing is completed.  Under such conditions,
   the <domain:delete> 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 <domain:delete> 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 <update>
   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 <extension> 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 <host:delete> 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 <delete> commands cause
   additional processing to ensure correct DNS entries.

3.3  Granularity of the <update> command

   It is frequently the case that one desires to limit some subset of
   <update> commands.  EPP <update> 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 <update> breaks the
   symmetry between prohibited status values and commands.  But since
   the EPP <update> 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 <poll> 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 <poll> 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
   <update> 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 <poll> command,
   it is desirable to add one OPTIONAL "priority" attribute to the
   <poll> 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 <poll> 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 <poll> command:

      C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
      C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
      C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      C:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
      C:     epp-1.0.xsd">
      C:  <command>
      C:    <poll op="req"
      C:          priority="1"/>
      C:    <clTRID>ABC-12345</clTRID>
      C:  </command>
      C:</epp>






















Sullivan                 Expires January 2, 2006               [Page 11]


Internet-Draft        EPP implementation experience            July 2005


   A <poll> 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:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
      S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
      S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      S:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
      S:     epp-1.0.xsd">
      S:  <response>
      S:    <result code="1000">
      S:      <msg>Command completed successfully</msg>
      S:    </result>
      S:    <msgQ priority="0" count="4" id="12346"/>
      S:    <msgQ priority="1" count="1" id="8910"/>
      S:    <trID>
      S:      <clTRID>ABC-12346</clTRID>
      S:      <svTRID>54322-XYZ</svTRID>
      S:    </trID>
      S:  </response>
      S:</epp>

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]