Dear all,

I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

I think this I-D is ready for publication. My comments:

**** Technical ****

* Section 8:
> 
> Any EPP client can use this mechanism to put data on the message 
> queue of another EPP client, allowing for the potential of a
> denial of service attack.  However this can, and SHOULD be detected
> by the server.  A server MAY set a server policy which limits or
> rejects a <keyrelay:create> command if it detects the mechanism is
> being abused.

I think you should provide more details regarding e.g. what would be the
conditions under which a server could infer that the mechanism is being
abused.


**** Editorial: ****

* Section 3.2.1, page 8:
Note that in the provided example the second <keyrelay:keyRelayData>
element has a period of zero and thus represents the revocation of a
previouly send key relay object (see Section 2.1.1).

s/send/sent/

* Section 5.1 and Section 5.2:
> conforming to a registry mechanism d

should you s/a/the/?


Thank you,
Tina