Key Relay Mapping for the Extensible Provisioning Protocol
RFC 8063
Yes
No Objection
Note: This ballot was opened for revision 10 and is now closed.
Alvaro Retana No Objection
(Alissa Cooper; former steering group member) (was No Objection) Yes
(Barry Leiba; former steering group member) Yes
(Alia Atlas; former steering group member) No Objection
(Ben Campbell; former steering group member) No Objection
(Benoît Claise; former steering group member) No Objection
(Brian Haberman; former steering group member) No Objection
I support Stephen's DISCUSS.
(Deborah Brungard; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
Once Stephen's point is addressed I think this is fine with the editorials nit's in Tina TSOU's opsdir review already processed.
(Martin Stiemerling; former steering group member) No Objection
(Spencer Dawkins; former steering group member) No Objection
I also agree with the IPR section of Stephen's discuss.
(Stephen Farrell; former steering group member) (was Discuss) No Objection
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?