Re: [eppext] New draft for keyrelay available
"Gould, James" <JGould@verisign.com> Thu, 05 February 2015 14:08 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 7FF2C1A88BD
for <eppext@ietfa.amsl.com>; Thu, 5 Feb 2015 06:08:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3,
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 yWHyAYDApEUp for <eppext@ietfa.amsl.com>;
Thu, 5 Feb 2015 06:08:18 -0800 (PST)
Received: from exprod6og127.obsmtp.com (exprod6og127.obsmtp.com [64.18.1.78])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id 43BFB1A8863
for <eppext@ietf.org>; Thu, 5 Feb 2015 06:08:09 -0800 (PST)
Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1)
by exprod6ob127.postini.com ([64.18.5.12]) with SMTP
ID DSNKVNN5SChcbq1Lg5kQJQJIEQ8neVvY7KRO@postini.com;
Thu, 05 Feb 2015 06:08:14 PST
Received: from brn1wnexcas01.vcorp.ad.vrsn.com
(brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205])
by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id
t15E87SD009185
(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
Thu, 5 Feb 2015 09:08:07 -0500
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by
brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 5
Feb 2015 09:08:07 -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+eoEAALUP4qAAEcW9gAEmPdEAAANycwAAKyYUgAIEIAGAAAFOhwAAAGLyAAAA03OAAAAZ7YAAAkG4AAAELswAAABaAQAAAMFFgAABzoiAAApRdhD//7ZaAIAATNuwgAidxICAAAjhAIAADnsA
Date: Thu, 5 Feb 2015 14:08:06 +0000
Message-ID: <ECD1F4F1-B5E7-4667-90CC-454204CCB065@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>
<46F2F7EA-7FD4-4D47-B80D-CCC795277512@verisign.com>
<831693C2CDA2E849A7D7A712B24E257F49F3353E@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
<ABCBA930-3045-438C-A526-B6B824390048@verisign.com>
<831693C2CDA2E849A7D7A712B24E257F49F338CE@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
<C80127C588F8F2409E2B535AF968B768B928BC13@kambx2.SIDN.local>
<831693C2CDA2E849A7D7A712B24E257F49F33CD7@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
<9DA4482A-EF0F-4D66-A941-9472F16403E3@verisign.com>
<831693C2CDA2E849A7D7A712B24E257F49F33D6D@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
<6BA91560-54! 25-4BAC-A 17A-25D13EF88A8F@verisign.com>
<831693C2CDA2E849A7D7A712B24E257F49F33F4C@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
<BF69A00E-EBD5-435A-8BF5-1C77A44E4545@verisign.com>
<831693C2CDA2E849A7D7A712B24E257F49F34147@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
<AF85EB99-3250-4BBD-9106-59400D8AF911@antoin.nl>
<831693C2CDA2E849A7D7A712B24E257F49F3AFB9@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49F3AFB9@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_ECD1F4F1B5E7466790CC454204CCB065verisigncom_";
type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/YYTXXDum4DaVOKppuyg_cAUftRw>
Cc: Rik Ribbers <rik.ribbers@sidn.nl>, Miek Gieben <miek@miek.nl>,
Maarten Bosteels <maarten.bosteels@dnsbelgium.be>,
"eppext@ietf.org" <eppext@ietf.org>, Antoin Verschuren <antoin@antoin.nl>
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: Thu, 05 Feb 2015 14:08:23 -0000
Scott, I believe that RFC 5730 is not limited to a certain class of objects that can be provisioned. A create of a transient, immutable message object is a transform command and the use of a poll response supports a query command. In this case the server is being used to support the passing of messages between two clients. There is no idempotency issue between the clients and the server since the object is immutable, but there is an idempotency issue between the participating clients that could be addressed by including a unique relay identifier in the relay message that the consuming client can simply verify against previously applied relay identifiers ahead of applying the relay message. There could be other use cases were clients need to communicate through the server using a transient object message pattern. My recommendation to the authors of the Key Relay Extension is to make the draft an object mapping with a create transform command, a the poll response, and with a unique relay identifier to address the end-to-end idempotency concern. — 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 Feb 5, 2015, at 8:16 AM, Hollenbeck, Scott <shollenbeck@verisign.com<mailto:shollenbeck@verisign.com>> wrote: -----Original Message----- From: Antoin Verschuren [mailto:antoin@antoin.nl] Sent: Thursday, February 05, 2015 7:45 AM To: Hollenbeck, Scott Cc: Gould, James; Rik Ribbers; Miek Gieben; Maarten Bosteels; eppext@ietf.org<mailto:eppext@ietf.org> Subject: Re: [eppext] New draft for keyrelay available Scott, What do you considder a duplication? The exact same message being sent or received more than once. This introduces a risk of inconsistency between client and server if there isn't a way to provide command idempotency, which is one of the reasons I prefer an approach that involves creating a transient object. Note that Section 2 of RFC 5730 includes this statement about EPP commands: "EPP commands fall into three categories: session management commands, query commands, and object transform commands." Which of these categories does the <relay> command fall into? The draft describes it as a "transient" command, and there's no mention of "transient" commands in 5730. 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