Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedback

"Gould, James" <JGould@verisign.com> Tue, 11 March 2014 16:36 UTC

Return-Path: <JGould@verisign.com>
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 3B32C1A048D for <eppext@ietfa.amsl.com>; Tue, 11 Mar 2014 09:36:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.894
X-Spam-Level:
X-Spam-Status: No, score=-2.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, TRACKER_ID=1.306] autolearn=ham
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 QPqYif_klZpa for <eppext@ietfa.amsl.com>; Tue, 11 Mar 2014 09:36:16 -0700 (PDT)
Received: from exprod6og127.obsmtp.com (exprod6og127.obsmtp.com [64.18.1.78]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE461A0450 for <eppext@ietf.org>; Tue, 11 Mar 2014 09:36:13 -0700 (PDT)
Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob127.postini.com ([64.18.5.12]) with SMTP ID DSNKUx87d0dwQijhaiGeD9iLuMzUaoylkrlf@postini.com; Tue, 11 Mar 2014 09:36:10 PDT
Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s2BGa4H9007606 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Mar 2014 12:36:06 -0400
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0123.003; Tue, 11 Mar 2014 12:36:04 -0400
From: "Gould, James" <JGould@verisign.com>
To: Antoin Verschuren <antoin.verschuren@sidn.nl>, "eppext@ietf.org" <eppext@ietf.org>
Thread-Topic: [eppext] draft-ietf-eppext-keyrelay-00 Feedback
Thread-Index: AQHPPTZwhTqnVBiC0UudESqSbZQK05rcFYQA
Date: Tue, 11 Mar 2014 16:36:03 +0000
Message-ID: <CF44A31F.5969B%jgould@verisign.com>
In-Reply-To: <531F0E41.9070201@sidn.nl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.6.130613
x-originating-ip: [10.173.152.4]
Content-Type: multipart/alternative; boundary="_000_CF44A31F5969Bjgouldverisigncom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/cijke-6F9YGfWt4KF2oDx6Eueis
Subject: Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedback
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: Tue, 11 Mar 2014 16:36:19 -0000

Antoin,

Thanks for the clarification.  Two other approaches could be taken to satisfy the requirement, which include:

  1.  Create a Key Relay Object Mapping that references the domain name.  The server can define who is authorized to invoke an operation on a Key Relay object.
  2.  Create a Command-Response Extension of the domain mapping that creates a new keyrelay verb similar to the restore verb in RFC 3915, which is an extension of an empty domain update.  The server can define who is authorized to invoke the new verb on the domain name.

By defining Key Relay as a new object or a new verb extension to the domain object, you get all of the advantages of an object mapping (extensions, client and server transaction identifier).  My recommendation is to go with option #2, since I view Key Relay as a verb.  In summary, I don’t believe there is the need to create a protocol extension for this.

Thanks,

--

JG



James Gould
Principal Software Engineer
jgould@verisign.com

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com



On 3/11/14, 9:23 AM, "Antoin Verschuren" <antoin.verschuren@sidn.nl<mailto:antoin.verschuren@sidn.nl>> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I'd like to answer the question asked in London why EPP keyrelay is
not an object extension or domain update.

Regular EPP commands are submitted to a registry by the current
registrar of record for that object in the database. Only the
registrar of record is allowed to change attributes to a domain object.

EPP keyrelay is a command that typically is sent to a registry by a
registrar NOT being the registrar of record for that domain object. So
the registrar sending the command is not permitted to change anything
in the database to that object.

EPP keyrelay is therefor only a communication command, and the domain
object is only used to identify the registrar of record for that
domain object as a recipient. The domain object is only queried to
identify the registrar of record, but no attributes are allowed to be
changed.

Hope that clarifies the questions raised in London.

- --
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  M: +31 6 23368970
Mailto: antoin.verschuren@sidn.nl<mailto:antoin.verschuren@sidn.nl>
XMPP: antoin.verschuren@jabber.sidn.nl<mailto:antoin.verschuren@jabber.sidn.nl>
HTTP://www.sidn.nl/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJTHw5BAAoJEDqHrM883AgnLzQIAKlTgwWXRnWqcR134FO2JVhm
Jwq8URAlmBVG7neAUMiLBJLKP+kiz1CwvPyCH4pHlsJKNKDpBtVsqInQ4aAaU8px
X39A1skBXIhjUzdMUXx3xmw8I8xHDIHenj1SL4LUFTqOdZ6U0QqNtVMdMrXapti2
BlRGDwOCP583r3HUkvryYDHdVdVWSlboFn+rkhsW9jVboT7XfYx0YRoPCY+ru6+3
HYop/C3N3WhjveSyRwyWrqlRdAbrr0ZIZDJBps4nvq5jZD0NQMuUQoVy0k3ob0KC
mUjKmilvf/2RX2tQYrqdT0Io3NmsB2548eYi7noPw0saoMgufGK3UpyxUM28Be0=
=k5MB
-----END PGP SIGNATURE-----

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