Key Relay Mapping for the Extensible Provisioning Protocol
draft-ietf-eppext-keyrelay-12

I support Stephen's DISCUSS.

Once Stephen's point is addressed I think this is fine with the editorials nit's in Tina TSOU's opsdir review already processed.

I also agree with the IPR section of Stephen's discuss.

Thanks for confirming that the WG are ok with the IPR declaration.

OLD COMMENTS and cleared-DISCUSS point below. (There's
no need to read beyond here:-)

(2) So I can see at least two ways in which this kind of thing can
be done and you don't clearly say which this supports. Option (a)
would be for the gaining DNS operator to provide new public keys
to the losing operator for inclusion before a transfer so that
continuity is maintained during the transfer. Option (b) would be
where the KSK private material is not known by either
operator, but e.g. by the registrant. In the case of option (b)
the DNSKEY would be transferred from the losing to the gaining DNS
operator. (And the arrow in Figure 1 would be in the other
direction.) I think you need to be clear about which of these
cases is actually being supported and about the overall sequence
of events needed. (If you tell me that you really want to do
whatever is in draft-koch, then that's fine but then this draft is
probably premature and draft-koch would need to be a normative
ref.)

- I think I'm missing an overview of EPP here. The intro could
maybe do with a short para, and/or a pointer to something general.
(Ah, I get it in section 3 - the ref to 5730 might be better in
the intro.)

- general: I think it'd be better to talk about public key values
and not "key material" as the latter is often used to describe
secret/private values which aren't at issue here. (Or else
I'm mis-reading stuff:-)

- nit, p8: s/previously send/previously sent/

- Section 6: I'm surprised that you don't recommend or even note
that the gaining registrar/dns operator should be able to check
that the DNSKEY value it sees in XML is or is not the same as one
that is published in the DNS and verifiable there. Wouldn't that
kind of cross check be useful?