All, I’ve uploaded a new version of the keyrelay draft that contains all the remarks made during the IESG review period (last december): https://datatracker.ietf.org/doc/draft-ietf-eppext-keyrelay/
For the authors this version addresses all issues except the IPR-disclosure (point 1 of Stephen Farrell’s comments). This means that also point 2 of Stephen Farrell’s (from the authors point of view) is dealt with. If not please let us know if you have a different opinion. Below is an overview of all the changes and if applicable a link to the mail archive on why this change was made. Kind regards, Rik ----------------------------------------------------------------------- Change 1) More introduction wording in chapter 1 Mail reference: https://mailarchive.ietf.org/arch/msg/eppext/beKdOVhgWsbC-1sS0vBM3cpA84o https://mailarchive.ietf.org/arch/msg/eppext/LSw7yUjm4uBVInkC-5GulNweRfQ 135,138c135,136 < In this document we define an EPP extension to sent DNSSEC key < material between EPP clients. This allows DNS operators to bootstrap < automatically, reliable and securely the transfer of a domain name < while keeping the DNSSEC chain of trust intact. --- > In this document we define an EPP extension to provide automation and > a reliable transfer of DNSSEC key material. 164a163,164 ----------------------------------------------------------------------- Change 2) Updated reference in section 2.1.1 Mail reference: https://mailarchive.ietf.org/arch/msg/eppext/BM-D3P-3VWlDdTQ2e1tk0NY8NQE 234c234 < material as described in [RFC5910], Section 4 --- > material as described in [RFC5910], Section 4.2. ----------------------------------------------------------------------- Change 3) Typo Mail reference: https://mailarchive.ietf.org/arch/msg/eppext/BM-D3P-3VWlDdTQ2e1tk0NY8NQE 439c439 < previouly sent key relay object (see Section 2.1.1). --- > previouly send key relay object (see Section 2.1.1). 653c653 < This document uses URNs to describe a XML namespace conforming to the --- > This document uses URNs to describe a XML namespace conforming to a 666c666 < This document uses URNs to describe a XML schema conforming to the --- > This document uses URNs to describe a XML schema conforming to a ----------------------------------------------------------------------- Change 5) updated wording mail reference: https://mailarchive.ietf.org/arch/msg/eppext/_y-1kbSrcOW-M0IZCFvuvdiJHak 707,711c707 < management when processing a <keyrelay:create> command. The intent < of this command is to put DNSSEC key material on the poll queue of < another client. To make sure that this EPP extension is < interoperable with the different server policies that already have < implemented EPP this extension it is not classified as must not. --- > management when processing a <keyrelay:create> command. 715c711 ----------------------------------------------------------------------- Change 6) SHOULD is not a normative reference here. mail reference: Remark made by Tina TSOU (ops-dir) < of service attack. However this can, and should be detected by the --- > of service attack. However this can, and SHOULD be detected by the 721c717 < element should be used as an indication that putting the key material --- > element SHOULD be used as an indication that putting the key material ----------------------------------------------------------------------- Change 7) Remarks made by Stephen given the suggestion to add wording concerning the verification of the key transfer through DNS. mail reference: on the IESG mailing list. 723a720,723 > to perform DNS changes is not covered in this document as it depends > on registry specific policy. > > 733,744d732 < to perform DNS changes is not covered in this document as it depends < on registry specific policy. < < A client that uses this mechanism to send DNSSEC key material to < another client could verify through DNS that the DNSSEC key material < is added to the authoritive zone of the domain. This check can be < used to verify that the DNSSEC key material has traveled end-to-end < from the gaining DNS operator to the losing DNS operator. This check < does not tell anything about the DNSSEC chain of trust and can merely < be used as a verification of a succesful transfer of the DNSSEC key < material. < 778,788d765 ----------------------------------------------------------------------- Change 8) Removed unuses namespace reference from XSD. 582d581 < xmlns:epp="urn:ietf:params:xml:ns:epp-1.0" 596d594 < <import namespace="urn:ietf:params:xml:ns:epp-1.0" /> 613a612,613
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
