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 wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-eppext-keyrelay-11 Reviewer: Robert Sparks Review Date: 14Dec2015 IETF LC End Date: 4Dec2015 IESG Telechat date: 17Dec2015 Summary: (Still) ready for publication as Proposed Standard Thanks for addressing most of my nits. I think it's a problem (not for this document, but for the overall work) that draft-koch-dnsop-operator-change isn't moving forward. I think the group should spend energy on how to capture what it was saying. I also still think you would have a stronger document if it discussed the SHOULD NOT in the security section as I suggest below. I think you read that to be me suggesting you change it to MUST NOT. That was not the intent. I was asking you to add to the document _why_ it wasn't MUST NOT. On 11/25/15 3:45 PM, Robert Sparks wrote: > 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 > >