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

Rik Ribbers <rik.ribbers@sidn.nl> Thu, 11 June 2015 10:07 UTC

Return-Path: <rik.ribbers@sidn.nl>
X-Original-To: eppext@ietfa.amsl.com
Delivered-To: eppext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFA5D1B2E57 for <eppext@ietfa.amsl.com>; Thu, 11 Jun 2015 03:07:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.085
X-Spam-Level:
X-Spam-Status: No, score=0.085 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIHsc2BKKyLM for <eppext@ietfa.amsl.com>; Thu, 11 Jun 2015 03:07:10 -0700 (PDT)
Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4050C1B2E47 for <eppext@ietf.org>; Thu, 11 Jun 2015 03:07:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn-nl; c=relaxed/relaxed; h=from:to:subject:thread-topic:thread-index:date:message-id:references:in-reply-to:accept-language:content-language:x-ms-has-attach:x-ms-tnef-correlator:x-originating-ip:content-type:mime-version; bh=G+mXGsVaq3kB2rOUV5Buqk3jI9JlneDarKdfjnRGIYQ=; b=YeOwJsHc+i0HmnpxbW0LB9LDWDnaCuVrii/JR/YPbP1WkBoj2ekvvx4D8sgoO2HPDst7oODojK2su15MU/oZTB2L1UehK6GKYLFfS3qgfigph59CTsrs3aS1d4WxTwlCZ+P4iBxFu/meIhfEZnycBq5uSNJ8ZqzvQHKB83G9ayaMLZuoXhG1cDLF7pXSJZsq5z47qsEWpBxQE2sFCyHDpU37GXb1b/NzfKnrgeLTD+FbYIQ7+Ue1p1FS+bLX1teiliBxt+aOs/QQQ1jI41SlJzAvb6hzJaWzTuTZL7mpWnmJxpknab9sOKPn2s2nxg3aF6RLqEjx/pfSOHrN/wJJhQ==
Received: from ka-mbx03.SIDN.local ([192.168.2.179]) by arn2-kamx.sidn.nl with ESMTP id t5BA78hJ024612-t5BA78hL024612 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL); Thu, 11 Jun 2015 12:07:08 +0200
Received: from KAHUBCASN01.SIDN.local (192.168.2.75) by ka-mbx03.SIDN.local (192.168.2.179) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 11 Jun 2015 12:07:13 +0200
Received: from KAMBX2.SIDN.local ([fe80::b1fd:88d9:e136:9655]) by kahubcasn01 ([192.168.2.73]) with mapi id 14.03.0224.002; Thu, 11 Jun 2015 12:07:06 +0200
From: Rik Ribbers <rik.ribbers@sidn.nl>
To: "'Gould, James'" <JGould@verisign.com>, "eppext@ietf.org" <eppext@ietf.org>
Thread-Topic: [eppext] I-D Action: draft-ietf-eppext-keyrelay-03.txt
Thread-Index: AQHQotSKNKtz7fv09UeoGKEVYg0rHp2kVciAgAK8/nA=
Date: Thu, 11 Jun 2015 10:07:06 +0000
Message-ID: <C80127C588F8F2409E2B535AF968B768BA1AAA3F@kambx2.SIDN.local>
References: <20150609165035.21784.63952.idtracker@ietfa.amsl.com> <4FE32467-5C0F-47DD-B3CA-1C04B0409D85@verisign.com>
In-Reply-To: <4FE32467-5C0F-47DD-B3CA-1C04B0409D85@verisign.com>
Accept-Language: nl-NL, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.2.171]
Content-Type: multipart/related; boundary="_004_C80127C588F8F2409E2B535AF968B768BA1AAA3Fkambx2SIDNlocal_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/2l_OdJ2ZwmGa_XKUEB0GEzoDW3s>
Subject: Re: [eppext] I-D Action: draft-ietf-eppext-keyrelay-03.txt
X-BeenThere: eppext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: EPPEXT <eppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eppext>, <mailto:eppext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/eppext/>
List-Post: <mailto:eppext@ietf.org>
List-Help: <mailto:eppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eppext>, <mailto:eppext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Jun 2015 10:07:13 -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:eppext-bounces@ietf.org] On Behalf Of Gould, James
Sent: dinsdag 9 juni 2015 20:03
To: eppext@ietf.org
Subject: Re: [eppext] I-D Action: draft-ietf-eppext-keyrelay-03.txt

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

[cid:image001.png@01D0A43D.8FCCFA40]

James Gould
Distinguished Engineer
jgould@Verisign.com

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

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

On Jun 9, 2015, at 12:50 PM, internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> wrote:


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/

_______________________________________________
EppExt mailing list
EppExt@ietf.org<mailto:EppExt@ietf.org>
https://www.ietf.org/mailman/listinfo/eppext