[eppext] Stephen Farrell's Discuss on draft-ietf-eppext-keyrelay-11: (with DISCUSS and COMMENT)

["Stephen Farrell" <[e-mail]>]

Stephen Farrell has entered the following ballot position for
draft-ietf-eppext-keyrelay-11: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


(1) The IPR declaration says that license terms will be available
"later." As things stand, I don't understand how the WG can have
made an informed decision in that case. I looked at the archive
and saw essentially no discussion, other than the announcement. I
also looked at the application and it's not crystal clear to me at
least that none of the claims are relevant. The shepherd write-up
also doesn't help me, but of course there may have been discussion
in a f2f meeting that is documented in minutes or something - I've
not checked for such, or I may have missed out on some list
traffic. Anyway, the DISCUSS is to ask did I miss stuff and if not
how can WG participants have rationally considered an IPR
declaration if the licensing information will only arrive "later"
after the document is approved to become an RFC?  (Note: If I am
explicitly told that this was considered and participants were ok
with the declaration even as-is, then I'll clear.) 

(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.)


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


- 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?