Subject: [eppext] I-D Action: draft-ietf-eppext-keyrelay-03.txt

From: [email-masked]
Date: Tue, 09 Jun 2015 09:50:35 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Extensible Provisioning Protocol Extensions Working Group of the IETF.

        Title           : Key Relay Mapping for the Extensible Provisioning Protocol
        Authors         : Rik Ribbers
                          Marc Groeneweg
	Filename        : draft-ietf-eppext-keyrelay-03.txt
	Pages           : 16
	Date            : 2015-06-09

Abstract:
   This document describes an Extensible Provisioning Protocol (EPP)
   mapping for a key relay object that relays DNSSEC key material
   between EPP clients using the poll queue defined in [RFC5730].

   This key relay mapping will help facilitate changing the DNS operator
   of a domain while keeping the DNSSEC chain of trust intact.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-eppext-keyrelay/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-eppext-keyrelay-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-eppext-keyrelay-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Gould, James" <[email-masked]>
Date: Tue, 9 Jun 2015 18:02:45 +0000

In reviewing the latest draft, I have the following feedback:

  1.  The <authInfo> element is required for the create and the poll message (info response)?  Would it make sense to make it required only on the create, since it used for authorization and really doesn’t need to reside in the poll message itself.
  2.  The <keyrelay:crDate>, <keyrelay:reID>, and <keyrelay:acID> are described as OPTIONAL in section 3.1.2, but they are required by the XML schema (no minOccurs=“0”).
  3.  I believe that the description of the REQUIRED <keyRelayData> element in section 3.1.2 was incorrectly removed.

—

JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com<http://VerisignInc.com>

On Jun 9, 2015, at 12:50 PM, [email-masked]<mailto:[email-masked]> wrote:

Abstract:

_______________________________________________
EppExt mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/eppext

---

From: Rik Ribbers <[email-masked]>
Date: Thu, 11 Jun 2015 10:07:06 +0000

Hello James,

Thanks for the feedback. My comments are:

1.       It would make sense for me. However adding the authInfo element to the poll response was added explicitly to the response on request of our registrars to give them the opportunity to validate the provided token by themselves.

2.       The fields should be OPTIONAL. I have updated the working copy of the document

3.       A little bit of over enthousiastic editing from my side.

We have received some feedback from our registrars to handle the usecase when the server is aware that the losing Registrar does not support DNSSEC (or secure transfers). The server could simply reject the keyrelay create command in that case. For the gaining Registrar this is a signal to continue with the transfer.  I will add this request to the draft the upcoming weeks).

I will post a new version in a few weeks. (At least before the IETF meeting)

Gr,
Rik

From: EppExt [mailto:[email-masked]] On Behalf Of Gould, James
Sent: dinsdag 9 juni 2015 20:03
To: [email-masked]
Subject: Re: [eppext] I-D Action: draft-ietf-eppext-keyrelay-03.txt

—

JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Abstract:

_______________________________________________
EppExt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/eppext