Key Relay Mapping for the Extensible Provisioning Protocol
RFC 8063
Yes
(Alissa Cooper)
(Barry Leiba)
No Objection
Alvaro Retana
(Alia Atlas)
(Ben Campbell)
(Benoît Claise)
(Deborah Brungard)
(Jari Arkko)
(Martin Stiemerling)
Note: This ballot was opened for revision 10 and is now closed.
Alvaro Retana
No Objection
Alissa Cooper Former IESG member
(was No Objection)
Yes
Yes
(2016-12-05)
Barry Leiba Former IESG member
Yes
Yes
(for -10)
Alia Atlas Former IESG member
No Objection
No Objection
(for -11)
Ben Campbell Former IESG member
No Objection
No Objection
(for -11)
Benoît Claise Former IESG member
No Objection
No Objection
(for -11)
Brian Haberman Former IESG member
No Objection
No Objection
(2015-12-17 for -11)
I support Stephen's DISCUSS.
Deborah Brungard Former IESG member
No Objection
No Objection
(for -11)
Jari Arkko Former IESG member
No Objection
No Objection
(for -11)
Joel Jaeggli Former IESG member
No Objection
No Objection
(2015-12-15 for -11)
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 IESG member
No Objection
No Objection
(for -11)
Spencer Dawkins Former IESG member
No Objection
No Objection
(2015-12-17 for -11)
I also agree with the IPR section of Stephen's discuss.
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(2016-12-02)
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?