Stephen Farrell has entered the following ballot position for draft-ietf-eppext-keyrelay-12: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-eppext-keyrelay/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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? _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
