Subject: [regext] New version of key relay draft

From: Rik Ribbers <[email-masked]>
Date: Tue, 31 May 2016 09:53:53 +0000

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