Re: [eppext] New draft for keyrelay available
"Gould, James" <JGould@verisign.com> Fri, 30 January 2015 14:57 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 83A9B1A0470 for <eppext@ietfa.amsl.com>;
Fri, 30 Jan 2015 06:57:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,
HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 XVBiDzUwGj7h for
<eppext@ietfa.amsl.com>; Fri, 30 Jan 2015 06:57:34 -0800 (PST)
Received: from chip2og123.obsmtp.com (chip2og123.obsmtp.com [64.18.13.92])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client
certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E51121A0072
for <eppext@ietf.org>; Fri, 30 Jan 2015 06:57:29 -0800 (PST)
Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1)
by chip2ob123.postini.com ([64.18.5.12]) with SMTP ID
DSNKVMub2f2OOYE62jQ3ROzSnI1eDst/1HQT@postini.com;
Fri, 30 Jan 2015 06:57:33 PST
Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com
(brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by
brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id
t0UEvSHO004338 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
Fri, 30 Jan 2015 09:57:28 -0500
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by
BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001;
Fri, 30 Jan 2015 09:57:27 -0500
From: "Gould, James" <JGould@verisign.com>
To: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Thread-Topic: [eppext] New draft for keyrelay available
Thread-Index: AdArSKQ+n3FmCyCWSq6l2+OWlzutMwA+eoEAALUP4qAAEcW9gAEmPdEAAANycwAAKyYUgAIEIAGAAAFOhwA=
Date: Fri, 30 Jan 2015 14:57:27 +0000
Message-ID: <46F2F7EA-7FD4-4D47-B80D-CCC795277512@verisign.com>
References: <C80127C588F8F2409E2B535AF968B768B927CDA8@kambx2.SIDN.local>
<0ED7237B-F4E8-45D7-971F-1625350DB0FC@verisign.com>
<C80127C588F8F2409E2B535AF968B768B9280B52@kambx2.SIDN.local>
<472EF001-1A03-4C50-A7DB-3D6B766B3BA8@verisign.com>
<20150119094734.GA27180@miek.nl>
<AF040383-7DED-4DDA-A52A-F40978697DF9@dnsbelgium.be>
<C80127C588F8F2409E2B535AF968B768B9285C2F@kambx2.SIDN.local>
<831693C2CDA2E849A7D7A712B24E257F49F33387@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49F33387@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.173.152.4]
Content-Type: multipart/related;
boundary="_004_46F2F7EA7FD44D47B80DCCC795277512verisigncom_";
type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/KecdPLEU-KOt6s26aTBB_qqzr4U>
Cc: Rik Ribbers <rik.ribbers@sidn.nl>, Miek Gieben <miek@miek.nl>,
Maarten Bosteels <maarten.bosteels@dnsbelgium.be>,
"eppext@ietf.org" <eppext@ietf.org>
Subject: Re: [eppext] New draft for keyrelay available
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: Fri, 30 Jan 2015 14:57:36 -0000
Scott, I believe the intent is to insert the transient object into the poll queue for the target client. The acknowledgement of the poll message should result in the implicit removal of the transient object from the server. With what you’re proposing, the source client would create the transient object that I’m assuming would result in a poll notification containing a signal to the client to submit an info command to get the transient object information? I’m assuming that the target client would then need to delete the transient object once they’re done with processing the message. I believe it’s simpler and consistent with the concept of creating a transient poll message to support the create to create the poll message and the info response poll message for the consumption of the transient object. In this case the poll queue is functioning as the repository for the transient object with the signal and data being one and the same, and the deletion of the transient object handled via the standard poll queue mechanism. — JG [cid:77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com] James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com<http://VerisignInc.com> On Jan 30, 2015, at 9:20 AM, Hollenbeck, Scott <shollenbeck@verisign.com<mailto:shollenbeck@verisign.com>> wrote: -----Original Message----- From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Rik Ribbers Sent: Tuesday, January 20, 2015 3:02 AM To: 'Maarten Bosteels'; Miek Gieben; Gould, James; eppext@ietf.org<mailto:eppext@ietf.org> Subject: Re: [eppext] New draft for keyrelay available Hello Maarten, Thx for the feedback, I hope more people with experience on extending EPP will state their opinion on the list. We have implemented the functionality in our registration system, but it is not very actively used. What we see is that most registrars go insecure. Most of the time we see a transfer command followed (some time later in time) by a domain update to remove the old key material and add new key material. There is even a losing registrar that removes all DNS key data when a registrant requests its authorization token before the actual transfer. One more opinion: After reading through the draft again I believe I would have designed this differently. EPP commands typically act on or read data from objects, and if I'm reading keyrelay correctly the <relay> command isn't doing either of those things. It's pushing information to the server to be stored temporarily (in what?) so that it can be retrieved with a <poll> command. It would be more architecturally consistent to create a temporary relay object with the needed information and use an <info> command to retrieve the data. <poll> can be used to notify the receiving client that the information is there to be retrieved. Anyway, that's my two cents. Rik's "not very actively used" comment is telling. DNSSEC isn't widely supported by registrars, so it makes sense that we're not seeing a lot of use. I don't have an issue with continuing work on this draft if the intention is to document the existing practice of one operator in an informational way, but I'm not comfortable with pursuing the current approach on the standards track. We should confirm the need before doing standards track work. Scott
- [eppext] New draft for keyrelay available Rik Ribbers
- Re: [eppext] New draft for keyrelay available Gould, James
- Re: [eppext] New draft for keyrelay available Rik Ribbers
- Re: [eppext] New draft for keyrelay available Gould, James
- Re: [eppext] New draft for keyrelay available Miek Gieben
- Re: [eppext] New draft for keyrelay available Maarten Bosteels
- Re: [eppext] New draft for keyrelay available Rik Ribbers
- Re: [eppext] New draft for keyrelay available Ulrich Wisser
- Re: [eppext] New draft for keyrelay available Rik Ribbers
- Re: [eppext] New draft for keyrelay available Hollenbeck, Scott
- Re: [eppext] New draft for keyrelay available Gould, James
- Re: [eppext] New draft for keyrelay available Hollenbeck, Scott
- Re: [eppext] New draft for keyrelay available Gould, James
- Re: [eppext] New draft for keyrelay available Hollenbeck, Scott
- Re: [eppext] New draft for keyrelay available Rik Ribbers
- Re: [eppext] New draft for keyrelay available Gould, James
- Re: [eppext] New draft for keyrelay available Hollenbeck, Scott
- Re: [eppext] New draft for keyrelay available Hollenbeck, Scott
- Re: [eppext] New draft for keyrelay available Gould, James
- Re: [eppext] New draft for keyrelay available Rik Ribbers
- Re: [eppext] New draft for keyrelay available Hollenbeck, Scott
- Re: [eppext] New draft for keyrelay available Rik Ribbers
- Re: [eppext] New draft for keyrelay available Gould, James
- Re: [eppext] New draft for keyrelay available Hollenbeck, Scott
- Re: [eppext] New draft for keyrelay available Gould, James
- Re: [eppext] New draft for keyrelay available Santosh Kalsangrah
- Re: [eppext] New draft for keyrelay available Hollenbeck, Scott
- [eppext] FW: New draft for keyrelay available Rik Ribbers
- Re: [eppext] New draft for keyrelay available Hollenbeck, Scott
- Re: [eppext] New draft for keyrelay available Gould, James
- Re: [eppext] New draft for keyrelay available Antoin Verschuren
- Re: [eppext] New draft for keyrelay available Antoin Verschuren
- Re: [eppext] New draft for keyrelay available Maarten Bosteels
- Re: [eppext] New draft for keyrelay available Gould, James
- Re: [eppext] New draft for keyrelay available Hollenbeck, Scott
- Re: [eppext] New draft for keyrelay available Antoin Verschuren
- Re: [eppext] New draft for keyrelay available Gould, James