I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-eppext-keyrelay-10 Reviewer: Robert Sparks Review Date: 25Nov2015 IETF LC End Date: 4Dec2015 IESG Telechat date: (not yet scheduled) Summary: Ready for publication as Proposed Standard with nits This is a small nit, but please consider changing the document to address it. The motivation for this extension leans on improving the security of transferring information between registrars. It should be recast as providing better automation and reliability instead. In practice (and I think in specification), it hinges on passing a password from the registrar of record to the gaining registrar through some unspecified means (though typically through the registrant). That password is required to be placed in the create by the gaining registrar as specified in this document in order for that create to succeed at the registry. While it would be impractical and error-prone, the same channel that was used to hand this password around _could_ be used to pass the keying material this extension addresses. Reading draft-koch-dnsop-operator-change (an informational reference currently) helped greatly with understanding this document. That draft expired in 2014. Please be sure it advances, and consider making it a normative reference. If it is not going to move forward, consider pulling some of the transfer mechanic recommendations and the definitions of losing/gaining entities into this draft, unless they've already made it into the RFC series somewhere else? The security considerations document says a server SHOULD NOT perform any transformation on data under server management when processing a command. Can this point to more detailed discussion somewhere? Why is this not a MUST NOT? (What are the conditions where violating the SHOULD NOT is the right thing to do? What are the risks a server takes if it performs such a transformation?) Micro-nit : In section 2.1 where you say "The element MUST contain one of the following", consider saying "The element MUST contain exactly one of the following". RjS