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
- [eppext] draft-ietf-eppext-keyrelay-00 Feedback Antoin Verschuren
- Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedba… Gould, James
- Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedba… Antoin Verschuren
- Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedba… Gould, James
- Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedba… Gould, James
- Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedba… Antoin Verschuren
- Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedba… Gould, James
- Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedba… Christopher Browne
- Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedba… Gould, James
- Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedba… Marc Groeneweg
- Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedba… Hollenbeck, Scott
- Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedba… Gould, James
- Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedba… Hollenbeck, Scott
- Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedba… Antoin Verschuren
- Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedba… Gould, James
- Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedba… Hollenbeck, Scott