From alexander.mayrhofer@nic.at Tue Apr 17 03:12:15 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA54F21F8534 for ; Tue, 17 Apr 2012 03:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.55 X-Spam-Level: X-Spam-Status: No, score=-7.55 tagged_above=-999 required=5 tests=[AWL=-0.579, BAYES_20=-0.74, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOyd55ZmGNQp for ; Tue, 17 Apr 2012 03:12:09 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id 951B521F84EB for ; Tue, 17 Apr 2012 03:12:07 -0700 (PDT) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel (TLSv1/SSLv3:AES128-SHA:128) with XWall v3.47 ; Tue, 17 Apr 2012 12:12:06 +0200 Received: from NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e]) by NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e%12]) with mapi id 14.01.0355.002; Tue, 17 Apr 2012 12:12:03 +0200 From: Alexander Mayrhofer To: "provreg@ietf.org" Thread-Topic: ICANN TMCH draft specifications available - EPP extensions? Thread-Index: Ac0cgZ2yqkk7vC0QR2GxoVWkIWjphA== Date: Tue, 17 Apr 2012 10:12:03 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE075031012@NICS-EXCH.sbg.nic.at> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.17.175.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-XWALL-BCKS: auto X-Mailman-Approved-At: Tue, 17 Apr 2012 03:26:33 -0700 Subject: [provreg] ICANN TMCH draft specifications available - EPP extensions? X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 10:12:15 -0000 The current version of ICANN's trademark clearinghouse specifications was p= ublished on April 13th. Looking through that document, i noticed that it re= quires a certain set of EPP extensions in order to transmit trademark claim= s/registration related data over EPP. Since the implementation of the TMCH is required for all operators of a new= gTLD, i was wondering whether there is already work going on regarding spe= cification of those EPP extensions? It would certainly not make much sense = if every backend operator of a new gTLD invents their own schema/extension = in order to support those required new data fields (registrars will certain= ly not appreciate those multiple extensions as well..).=20 Therefore, if no work has yet been performed on the specification of those = extensions in an internet draft, i think it makes sense to bundle forces am= ong new gTLD backend operators in order to create such an extension. (Apart= from that, i would also appreciate informal tech contacts to other emergin= g new gTLD backend operators, in order to discuss other operational / techn= ical issues around the EPP implementation). Comments are highly appreciated. thanks Alex Mayrhofer Head of R&D @ nic.at From Klaus.Malorny@knipp.de Tue Apr 17 03:47:06 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1899A21F8494 for ; Tue, 17 Apr 2012 03:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmN6lCZYH5kj for ; Tue, 17 Apr 2012 03:47:05 -0700 (PDT) Received: from kmx10a.knipp.de (clust3c-eth0-0.bbone.knipp.de [195.253.6.130]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF9221F847C for ; Tue, 17 Apr 2012 03:47:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 95D7251; Tue, 17 Apr 2012 12:47:00 +0200 (MESZ) X-Knipp-VirusScanned: Yes Received: from kmx10a.knipp.de ([127.0.0.1]) by localhost (kmx10a.knipp.de [127.0.0.1]) (amavisd-new, port 10004) with ESMTP id 1YUdA9rjcRNw; Tue, 17 Apr 2012 12:46:55 +0200 (MESZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id E463150; Tue, 17 Apr 2012 12:46:54 +0200 (MESZ) Received: from [195.253.2.27] (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id q3HAkslj024810; Tue, 17 Apr 2012 12:46:54 +0200 (MESZ) Message-ID: <4F8D4A1E.5000904@knipp.de> Date: Tue, 17 Apr 2012 12:46:54 +0200 From: Klaus Malorny User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120416 Thunderbird/14.0a1 MIME-Version: 1.0 To: provreg@ietf.org References: <19F54F2956911544A32543B8A9BDE075031012@NICS-EXCH.sbg.nic.at> In-Reply-To: <19F54F2956911544A32543B8A9BDE075031012@NICS-EXCH.sbg.nic.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [provreg] ICANN TMCH draft specifications available - EPP extensions? X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 10:47:06 -0000 On 17/04/12 12:12, Alexander Mayrhofer wrote: > The current version of ICANN's trademark clearinghouse specifications was > published on April 13th. Looking through that document, i noticed that it > requires a certain set of EPP extensions in order to transmit trademark > claims/registration related data over EPP. > > Hi, can you give me a short pointer to that specification? I must have missed that. Thanks in advance. Klaus From lem@isc.org Tue Apr 17 04:08:39 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EBFE21F84FA for ; Tue, 17 Apr 2012 04:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.053 X-Spam-Level: X-Spam-Status: No, score=-2.053 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8x2=0.246] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8SGWJWkb+pB for ; Tue, 17 Apr 2012 04:08:39 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id D511221F84F3 for ; Tue, 17 Apr 2012 04:08:38 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 6A4C65F984C; Tue, 17 Apr 2012 11:08:25 +0000 (UTC) (envelope-from lem@isc.org) Received: from g2x.lem (z65-50-116-115.ips.direcpath.com [65.50.116.115]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 0B1D7216C31; Tue, 17 Apr 2012 11:08:22 +0000 (UTC) (envelope-from lem@isc.org) References: <19F54F2956911544A32543B8A9BDE075031012@NICS-EXCH.sbg.nic.at> User-Agent: K-9 Mail for Android In-Reply-To: <19F54F2956911544A32543B8A9BDE075031012@NICS-EXCH.sbg.nic.at> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: =?ISO-8859-1?Q?Luis_Mu=F1oz?= Date: Tue, 17 Apr 2012 07:08:15 -0400 To: Alexander Mayrhofer , "provreg@ietf.org" Message-ID: <3a0bfa79-2ce9-4d5c-8c01-066983373252@email.android.com> Subject: Re: [provreg] =?utf-8?q?ICANN_TMCH_draft_specifications_available_-_E?= =?utf-8?q?PP=09extensions=3F?= X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 11:08:39 -0000 Alexander Mayrhofer wrote: >Therefore, if no work has yet been performed on the specification of >those extensions in an internet draft, i think it makes sense to bundle >forces among new gTLD backend operators in order to create such an >extension. (Apart from that, i would also appreciate informal tech >contacts to other emerging new gTLD backend operators, in order to >discuss other operational / technical issues around the EPP >implementation). The extensions and the overall process need to be discussed and worked on. It would be interesting to add test sites to that work. Perhaps that could be shared? Count me in... -lem From theo@flame.co.za Tue Apr 17 04:25:56 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B28621F8592 for ; Tue, 17 Apr 2012 04:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVtRPke3zm8a for ; Tue, 17 Apr 2012 04:25:55 -0700 (PDT) Received: from flame.co.za (ns.flame.co.za [160.124.170.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6120F21F8576 for ; Tue, 17 Apr 2012 04:25:55 -0700 (PDT) Received: from [192.168.0.159] (unknown [41.27.98.49]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by flame.co.za (Postfix) with ESMTPSA id D1C9080229 for ; Tue, 17 Apr 2012 13:25:50 +0200 (SAST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1084) From: Theo Kramer In-Reply-To: <3a0bfa79-2ce9-4d5c-8c01-066983373252@email.android.com> Date: Tue, 17 Apr 2012 13:25:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4E9CAD6D-89FD-429C-AEFF-493B00768F8E@flame.co.za> References: <19F54F2956911544A32543B8A9BDE075031012@NICS-EXCH.sbg.nic.at> <3a0bfa79-2ce9-4d5c-8c01-066983373252@email.android.com> To: provreg@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [provreg] ICANN TMCH draft specifications available - EPP extensions? X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 11:25:56 -0000 On 17 Apr 2012, at 1:08 PM, Luis Mu=F1oz wrote: >=20 >=20 > Alexander Mayrhofer wrote: >> Therefore, if no work has yet been performed on the specification of >> those extensions in an internet draft, i think it makes sense to = bundle >> forces among new gTLD backend operators in order to create such an >> extension. (Apart from that, i would also appreciate informal tech >> contacts to other emerging new gTLD backend operators, in order to >> discuss other operational / technical issues around the EPP >> implementation). >=20 > The extensions and the overall process need to be discussed and worked = on. It would be interesting to add test sites to that work. Perhaps that = could be shared? >=20 > Count me in... >=20 Ditto --=20 Regards Theo From jan@ipclearinghouse.org Tue Apr 17 06:33:45 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDBFE21F8592 for ; Tue, 17 Apr 2012 06:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7EQl57lA43v for ; Tue, 17 Apr 2012 06:33:41 -0700 (PDT) Received: from arthur.vbchosting.be (unknown [89.207.184.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1A48B21F861A for ; Tue, 17 Apr 2012 06:33:40 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by arthur.vbchosting.be (Postfix) with ESMTP id 4B276D00E4 for ; Tue, 17 Apr 2012 13:33:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at arthur.vbchosting.be Received: from arthur.vbchosting.be ([127.0.0.1]) by localhost (arthur.vbchosting.be [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pyo+R2K3j4x7 for ; Tue, 17 Apr 2012 15:33:36 +0200 (CEST) Received: from arthur.vbchosting.be (localhost.localdomain [127.0.0.1]) by arthur.vbchosting.be (Postfix) with ESMTP id 55C8AD00E0 for ; Tue, 17 Apr 2012 15:33:36 +0200 (CEST) Received: (from apache@localhost) by arthur.vbchosting.be (8.13.8/8.13.8/Submit) id q3HDXaYu013802; Tue, 17 Apr 2012 15:33:36 +0200 X-Authentication-Warning: arthur.vbchosting.be: apache set sender to jan@ipclearinghouse.org using -f Received: from 94.225.68.235 (SquirrelMail authenticated user jan@nexperteam.be) by mail.nexperteam.be with HTTP; Tue, 17 Apr 2012 15:33:36 +0200 (CEST) Message-ID: <13529.94.225.68.235.1334669616.squirrel@mail.nexperteam.be> In-Reply-To: <4F8D4A1E.5000904@knipp.de> References: <19F54F2956911544A32543B8A9BDE075031012@NICS-EXCH.sbg.nic.at> <4F8D4A1E.5000904@knipp.de> Date: Tue, 17 Apr 2012 15:33:36 +0200 (CEST) From: "Jan Jansen" To: provreg@ietf.org User-Agent: SquirrelMail/1.4.8-5.el5.centos.10 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable Subject: Re: [provreg] ICANN TMCH draft specifications available - EPP extensions? X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jan@ipclearinghouse.org List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 13:33:45 -0000 Hi, Alexander is probably referring to https://community.icann.org/display/cctrdmrkclrnghsiag/Home and more specific to https://community.icann.org/download/attachments/31176258/TMC-Model-Draft= -13apr12.pdf which contains some hints to extensions on the epp scheme. Notice that these are all draft documents. The 'claims'/notification part might be of particular interest too since it involves a lot of interaction between various parties including registry - registrar and registrar - registrant exchange of confirmation. -jan- > On 17/04/12 12:12, Alexander Mayrhofer wrote: >> The current version of ICANN's trademark clearinghouse specifications >> was >> published on April 13th. Looking through that document, i noticed that >> it >> requires a certain set of EPP extensions in order to transmit trademar= k >> claims/registration related data over EPP. >> >> > > Hi, > > can you give me a short pointer to that specification? I must have miss= ed > that. > Thanks in advance. > > Klaus > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg > From alexander.mayrhofer@nic.at Tue Apr 17 05:25:44 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4DB421F85A0 for ; Tue, 17 Apr 2012 05:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.587 X-Spam-Level: X-Spam-Status: No, score=-8.587 tagged_above=-999 required=5 tests=[AWL=0.843, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmZ-GXl51mLu for ; Tue, 17 Apr 2012 05:25:40 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA6E21F85AF for ; Tue, 17 Apr 2012 05:25:39 -0700 (PDT) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel (TLSv1/SSLv3:AES128-SHA:128) with XWall v3.47 ; Tue, 17 Apr 2012 14:25:38 +0200 Received: from NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e]) by NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e%12]) with mapi id 14.01.0355.002; Tue, 17 Apr 2012 14:25:34 +0200 From: Alexander Mayrhofer To: Klaus Malorny , "provreg@ietf.org" Thread-Topic: [provreg] ICANN TMCH draft specifications available - EPP extensions? Thread-Index: AQHNHIdzhthvRywU20qwioetKAKTs5ae8RLg Date: Tue, 17 Apr 2012 12:25:33 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE0750310FB@NICS-EXCH.sbg.nic.at> References: <19F54F2956911544A32543B8A9BDE075031012@NICS-EXCH.sbg.nic.at> <4F8D4A1E.5000904@knipp.de> In-Reply-To: <4F8D4A1E.5000904@knipp.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.17.175.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-XWALL-BCKS: auto X-Mailman-Approved-At: Tue, 17 Apr 2012 07:24:17 -0700 Subject: Re: [provreg] ICANN TMCH draft specifications available - EPP extensions? X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 12:25:44 -0000 > can you give me a short pointer to that specification? I must have missed > that. > Thanks in advance. Sorry, i should have added the link to my initial message. Here you go: https://community.icann.org/download/attachments/31176258/TMC-Model-Draft-1= 3apr12.pdf?version=3D1&modificationDate=3D1334362955253 cheers, Alex From zhoulinlin@cnnic.cn Sun Apr 22 23:13:22 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC38421F8555 for ; Sun, 22 Apr 2012 23:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.818 X-Spam-Level: *** X-Spam-Status: No, score=3.818 tagged_above=-999 required=5 tests=[AWL=3.817, BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ic5O2f8c5CRD for ; Sun, 22 Apr 2012 23:13:19 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 34CFB21F855B for ; Sun, 22 Apr 2012 23:13:16 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: zhoulinlin@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo95e6383c) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 23 Apr 2012 14:13:11 +0800 From: "Linlin Zhou" To: "'Alexander Mayrhofer'" , "'Klaus Malorny'" , References: <19F54F2956911544A32543B8A9BDE075031012@NICS-EXCH.sbg.nic.at> <4F8D4A1E.5000904@knipp.de> <19F54F2956911544A32543B8A9BDE0750310FB@NICS-EXCH.sbg.nic.at> In-Reply-To: <19F54F2956911544A32543B8A9BDE0750310FB@NICS-EXCH.sbg.nic.at> Date: Mon, 23 Apr 2012 14:13:12 +0800 Message-ID: <000301cd2118$29cec1c0$7d6c4540$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHNHIdzhthvRywU20qwioetKAKTs5ae8RLggAkF7FA= Content-Language: zh-cn Subject: Re: [provreg] ICANN TMCH draft specifications available - EPP extensions? X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 06:13:22 -0000 In this draft, it emphasizes the IDN readiness. "The Clearinghouse will accept trademark information in its native form (i.e., using the Unicode character set); specific variant character mappings must be handled by the registry." But it leaves to the Registry to handle IDN variants. When there's a variant domain registration, shall we check all the variant domains for several times with TMCH if no EPP extension is available? > -----Original Message----- > From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On Behalf > Of Alexander Mayrhofer > Sent: Tuesday, April 17, 2012 8:26 PM > To: Klaus Malorny; provreg@ietf.org > Subject: Re: [provreg] ICANN TMCH draft specifications available - EPP > extensions? > > > can you give me a short pointer to that specification? I must have > > missed that. > > Thanks in advance. > > Sorry, i should have added the link to my initial message. Here you go: > > https://community.icann.org/download/attachments/31176258/TMC-Model-D > raft-13apr12.pdf?version=1&modificationDate=1334362955253 > > cheers, > > Alex > > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg From miekg@atoom.net Mon Apr 23 03:51:54 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9E621F86C7 for ; Mon, 23 Apr 2012 03:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEwHB8OU7a-J for ; Mon, 23 Apr 2012 03:51:50 -0700 (PDT) Received: from elektron.atoom.net (elektron.atoom.net [85.223.71.124]) by ietfa.amsl.com (Postfix) with ESMTP id C9B3321F86D1 for ; Mon, 23 Apr 2012 03:51:49 -0700 (PDT) Received: by elektron.atoom.net (Postfix, from userid 1000) id 1ECE840063; Mon, 23 Apr 2012 12:51:48 +0200 (CEST) Date: Mon, 23 Apr 2012 12:51:48 +0200 From: Miek Gieben To: provreg@ietf.org Message-ID: <20120423105147.GA4001@miek.nl> Mail-Followup-To: provreg@ietf.org, regops@nlnetlabs.nl MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZPt4rx8FFjLCG7dd" Content-Disposition: inline User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Cc: regops@nlnetlabs.nl Subject: [provreg] draft-wullink-restful-epp-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 10:51:54 -0000 --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, [I've cross posted this also to regops@nlnetlabs.nl] SIDN, being the registry for .nl, employs EPP as the primary interface for registrars to submit or manipulate domain names. Even though the protocol is working quite well, at SIDN Labs we believed there was room for improvement. Experience over the years revealed certain operational shortcomings in EPP, mainly related to the stateful nature of the protocol: * EPP may pose challenges in load-balanced environments, when a active sess= ion has to be switched from one EPP server to another and state is kept on a = per server basis. * EPP sessions can wind up in a state where they are no longer linked to an active TCP connection. This may raise problems in situations where session limits are enforced. Our draft http://www.ietf.org/id/draft-wullink-restful-epp-00.txt aims to solve these issues, by proposing a RESTful EPP interface. The Abstract reads: This document specifies a 'RESTful interface for EPP' (REPP) with th= e =20 aim to improve efficiency and interoperability of EPP systems. = =20 This document includes a new EPP Protocol Extension as well as a map= ping=20 of [RFC5730] XML-commands to an HTTP based (RESTful) interface. Exis= ting=20 semantics and mappings as defined in [RFC5731], [RFC5732] and [RFC57= 33] =20 are largely retained and reusable in RESTful EPP. = =20 With REPP, no session is created on the EPP server. Each request fro= m =20 client to server will contain all of the information necessary to = =20 understand the request. The server will close the connection after e= ach =20 HTTP request. = =20 As the provreg WG is dormant, we have submitted our draft as an individual submission. Since the provreg mailinglist is still very much alive, we are kindly reque= sting its subscribers to provide us with feedback on our proposal. Kind regards, -- Miek Gieben SIDN Labs --ZPt4rx8FFjLCG7dd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk+VNEMACgkQJYuFzziA0Pa4XQCfVIwedL1a8r45jijARMveT04J kskAoKCWtRcKIfJY/2XiY4cCSI4w3Sdw =F6Og -----END PGP SIGNATURE----- --ZPt4rx8FFjLCG7dd-- From shollenbeck@verisign.com Mon Apr 23 04:10:02 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659EE21F8455 for ; Mon, 23 Apr 2012 04:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POk6O8wcp1vf for ; Mon, 23 Apr 2012 04:10:01 -0700 (PDT) Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by ietfa.amsl.com (Postfix) with ESMTP id 43B1321F8690 for ; Mon, 23 Apr 2012 04:09:58 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP ID DSNKT5U4g0uqVup1uFg7klQR0et7WMFlMC7F@postini.com; Mon, 23 Apr 2012 04:10:01 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q3NB9ohY010483; Mon, 23 Apr 2012 07:09:50 -0400 Received: from dul1wnexcn04.vcorp.ad.vrsn.com ([10.170.12.139]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Apr 2012 07:09:44 -0400 Received: from BRN1WNEXCAS01.vcorp.ad.vrsn.com ([10.173.152.205]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Apr 2012 07:09:45 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Mon, 23 Apr 2012 07:09:34 -0400 From: "Hollenbeck, Scott" To: Miek Gieben , "provreg@ietf.org" Thread-Topic: [provreg] draft-wullink-restful-epp-00.txt Thread-Index: AQHNIT8TEHY7wfqcDEmo/bo/keIE/JaoQBgw Date: Mon, 23 Apr 2012 11:09:39 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D5F056E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20120423105147.GA4001@miek.nl> In-Reply-To: <20120423105147.GA4001@miek.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Apr 2012 11:09:45.0623 (UTC) FILETIME=[9728B270:01CD2141] Cc: "regops@nlnetlabs.nl" Subject: Re: [provreg] draft-wullink-restful-epp-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 11:10:02 -0000 Miek, As I said in our off-list email exchange a few weeks ago, this document des= cribes something that is "EPP-like" as opposed to an extension of EPP. The= document should make that point clear. Scott > -----Original Message----- > From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On > Behalf Of Miek Gieben > Sent: Monday, April 23, 2012 6:52 AM > To: provreg@ietf.org > Cc: regops@nlnetlabs.nl > Subject: [provreg] draft-wullink-restful-epp-00.txt >=20 > Hello, >=20 > [I've cross posted this also to regops@nlnetlabs.nl] >=20 > SIDN, being the registry for .nl, employs EPP as the primary interface > for registrars to submit or manipulate domain names. Even though the > protocol is working quite well, at SIDN Labs we believed there was room > for improvement. >=20 > Experience over the years revealed certain operational shortcomings in > EPP, mainly related to the stateful nature of the protocol: >=20 > * EPP may pose challenges in load-balanced environments, when a active > session > has to be switched from one EPP server to another and state is kept > on a per > server basis. >=20 > * EPP sessions can wind up in a state where they are no longer linked > to an > active TCP connection. This may raise problems in situations where > session > limits are enforced. >=20 > Our draft http://www.ietf.org/id/draft-wullink-restful-epp-00.txt > aims to solve these issues, by proposing a RESTful EPP interface. >=20 > The Abstract reads: >=20 > This document specifies a 'RESTful interface for EPP' (REPP) > with the > aim to improve efficiency and interoperability of EPP systems. >=20 > This document includes a new EPP Protocol Extension as well as a > mapping > of [RFC5730] XML-commands to an HTTP based (RESTful) interface. > Existing > semantics and mappings as defined in [RFC5731], [RFC5732] and > [RFC5733] > are largely retained and reusable in RESTful EPP. >=20 > With REPP, no session is created on the EPP server. Each request > from > client to server will contain all of the information necessary > to > understand the request. The server will close the connection > after each > HTTP request. >=20 > As the provreg WG is dormant, we have submitted our draft as an > individual submission. >=20 > Since the provreg mailinglist is still very much alive, we are kindly > requesting its subscribers to provide us with feedback on our proposal. >=20 > Kind regards, >=20 > -- >=20 > Miek Gieben > SIDN Labs From miekg@atoom.net Mon Apr 23 04:28:15 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8166F21F86AF for ; Mon, 23 Apr 2012 04:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flbTWd2D7W6q for ; Mon, 23 Apr 2012 04:28:15 -0700 (PDT) Received: from elektron.atoom.net (cl-201.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:c8::2]) by ietfa.amsl.com (Postfix) with ESMTP id F23D121F86A8 for ; Mon, 23 Apr 2012 04:28:14 -0700 (PDT) Received: by elektron.atoom.net (Postfix, from userid 1000) id 57ADA3FF87; Mon, 23 Apr 2012 13:28:13 +0200 (CEST) Date: Mon, 23 Apr 2012 13:28:13 +0200 From: Miek Gieben To: "provreg@ietf.org" Message-ID: <20120423112813.GC4001@miek.nl> Mail-Followup-To: "provreg@ietf.org" References: <20120423105147.GA4001@miek.nl> <831693C2CDA2E849A7D7A712B24E257F0D5F056E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mvpLiMfbWzRoNl4x" Content-Disposition: inline In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D5F056E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Subject: Re: [provreg] draft-wullink-restful-epp-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 11:28:15 -0000 --mvpLiMfbWzRoNl4x Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ Quoting in "RE: [provreg] draft-wullink-restfu= l..." ] > Miek, >=20 > As I said in our off-list email exchange a few weeks ago, this document > describes something that is "EPP-like" as opposed to an extension of EPP.= The > document should make that point clear. Yes, we (try to) do that. The problem is that EPP is *defined* as being stateful, which is clearly something we break. Regards, Miek Gieben --mvpLiMfbWzRoNl4x Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk+VPM0ACgkQJYuFzziA0PaANACeNy49jhZi7ZsbWX6YUBfIx3bj sc8AnjDBuTaeqGNMIRRn10wMVHlb8Ki1 =1J17 -----END PGP SIGNATURE----- --mvpLiMfbWzRoNl4x-- From shollenbeck@verisign.com Mon Apr 23 04:37:15 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7459421F8672 for ; Mon, 23 Apr 2012 04:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMO9I-uHAEqD for ; Mon, 23 Apr 2012 04:37:15 -0700 (PDT) Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8D821F85F2 for ; Mon, 23 Apr 2012 04:37:14 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKT5U+6DkPZHdLePTASxKuC+A+suu3mlp1@postini.com; Mon, 23 Apr 2012 04:37:14 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q3NBbB4d011130; Mon, 23 Apr 2012 07:37:12 -0400 Received: from dul1wnexcn04.vcorp.ad.vrsn.com ([10.170.12.139]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Apr 2012 07:37:06 -0400 Received: from BRN1WNEXCAS02.vcorp.ad.vrsn.com ([10.173.152.206]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Apr 2012 07:37:07 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Mon, 23 Apr 2012 07:36:56 -0400 From: "Hollenbeck, Scott" To: Miek Gieben , "provreg@ietf.org" Thread-Topic: [provreg] draft-wullink-restful-epp-00.txt Thread-Index: AQHNIUQn2iNZifnLLkmpMcBCXwJSdJaoRotg Date: Mon, 23 Apr 2012 11:37:00 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D5F0715@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20120423105147.GA4001@miek.nl> <831693C2CDA2E849A7D7A712B24E257F0D5F056E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20120423112813.GC4001@miek.nl> In-Reply-To: <20120423112813.GC4001@miek.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Apr 2012 11:37:07.0107 (UTC) FILETIME=[698F4730:01CD2145] Subject: Re: [provreg] draft-wullink-restful-epp-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 11:37:15 -0000 > -----Original Message----- > From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On > Behalf Of Miek Gieben > Sent: Monday, April 23, 2012 7:28 AM > To: provreg@ietf.org > Subject: Re: [provreg] draft-wullink-restful-epp-00.txt >=20 > [ Quoting in "RE: [provreg] draft-wullink- > restful..." ] > > Miek, > > > > As I said in our off-list email exchange a few weeks ago, this > > document describes something that is "EPP-like" as opposed to an > > extension of EPP. The document should make that point clear. >=20 > Yes, we (try to) do that. The problem is that EPP is *defined* as being > stateful, which is clearly something we break. It's more than just the stateful/stateless change. While you're reusing the= XML data structures, the command and response syntax is different. The com= mand and response processors of an existing server-side implementation will= need to be changed significantly to implement this mapping. Scott From miekg@atoom.net Mon Apr 23 04:45:14 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA77821F86B7 for ; Mon, 23 Apr 2012 04:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZGI2VqXXfWv for ; Mon, 23 Apr 2012 04:45:14 -0700 (PDT) Received: from elektron.atoom.net (cl-201.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:c8::2]) by ietfa.amsl.com (Postfix) with ESMTP id 483E421F86B6 for ; Mon, 23 Apr 2012 04:45:14 -0700 (PDT) Received: by elektron.atoom.net (Postfix, from userid 1000) id 98CA740063; Mon, 23 Apr 2012 13:45:13 +0200 (CEST) Date: Mon, 23 Apr 2012 13:45:13 +0200 From: Miek Gieben To: "provreg@ietf.org" Message-ID: <20120423114513.GD4001@miek.nl> Mail-Followup-To: "provreg@ietf.org" References: <20120423105147.GA4001@miek.nl> <831693C2CDA2E849A7D7A712B24E257F0D5F056E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20120423112813.GC4001@miek.nl> <831693C2CDA2E849A7D7A712B24E257F0D5F0715@BRN1WNEXMBX01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GyRA7555PLgSTuth" Content-Disposition: inline In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D5F0715@BRN1WNEXMBX01.vcorp.ad.vrsn.com> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Subject: Re: [provreg] draft-wullink-restful-epp-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 11:45:15 -0000 --GyRA7555PLgSTuth Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ Quoting in "RE: [provreg] draft-wullink-restfu= l..." ] > > Yes, we (try to) do that. The problem is that EPP is *defined* as being > > stateful, which is clearly something we break. >=20 > It's more than just the stateful/stateless change. While you're reusing t= he > XML data structures, the command and response syntax is different. The co= mmand > and response processors of an existing server-side implementation will ne= ed to > be changed significantly to implement this mapping. Yep, that's true. But those command and reposonse processors do become a lo= t=20 simpler with REPP. Regards, Miek Gieben --GyRA7555PLgSTuth Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk+VQMkACgkQJYuFzziA0PbKjACfYNyrobtTkXX6nb7Zz3F+OSqG XEEAoOtfwjBP1boBcaNgDBMq3JrX+OiA =gCJg -----END PGP SIGNATURE----- --GyRA7555PLgSTuth-- From JGould@verisign.com Mon Apr 23 05:43:01 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 643F621F861E for ; Mon, 23 Apr 2012 05:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAHfh0aPwqla for ; Mon, 23 Apr 2012 05:43:00 -0700 (PDT) Received: from exprod6og104.obsmtp.com (exprod6og104.obsmtp.com [64.18.1.187]) by ietfa.amsl.com (Postfix) with ESMTP id A7A8F21F85D9 for ; Mon, 23 Apr 2012 05:42:57 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP ID DSNKT5VOTz49MuUsaPfe+Dkf3sgml29DBN1X@postini.com; Mon, 23 Apr 2012 05:43:00 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q3NCgsCt021981; Mon, 23 Apr 2012 08:42:54 -0400 Received: from BRN1WNEXCAS02.vcorp.ad.vrsn.com ([10.173.152.206]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Apr 2012 08:42:49 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Mon, 23 Apr 2012 08:42:39 -0400 From: "Gould, James" To: Miek Gieben , "provreg@ietf.org" Thread-Topic: [provreg] draft-wullink-restful-epp-00.txt Thread-Index: AQHNIT8Td2Wno5teB0WLeILaM3K96ZaoWrKA Date: Mon, 23 Apr 2012 12:42:43 +0000 Message-ID: In-Reply-To: <20120423105147.GA4001@miek.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <916BE2E516A80E43B2E5877E0CE52528@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Apr 2012 12:42:49.0026 (UTC) FILETIME=[97206220:01CD214E] Cc: "regops@nlnetlabs.nl" Subject: Re: [provreg] draft-wullink-restful-epp-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 12:43:01 -0000 This is the first time that I've heard of challenges in load-balanced environments or EPP session state not being linked to an active TCP session. Can you go into more detail of these issues? I've been involved with many EPP-based systems through the years and I've never come across any of these issues. This goes to the heart of the reliability of stateful TCP sessions, which is used with many other protocols. It would be good to discuss the problems posed prior to consideration of a new stateless version of EPP on top of REST. -- =20 JG =20 =20 James Gould Principal Software Engineer jgould@verisign.com =20 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On 4/23/12 6:51 AM, "Miek Gieben" wrote: >Hello, > >[I've cross posted this also to regops@nlnetlabs.nl] > >SIDN, being the registry for .nl, employs EPP as the primary interface for >registrars to submit or manipulate domain names. Even though the protocol >is >working quite well, at SIDN Labs we believed there was room for >improvement. > >Experience over the years revealed certain operational shortcomings in >EPP, >mainly related to the stateful nature of the protocol: > >* EPP may pose challenges in load-balanced environments, when a active >session > has to be switched from one EPP server to another and state is kept on >a per > server basis. > >* EPP sessions can wind up in a state where they are no longer linked to >an > active TCP connection. This may raise problems in situations where >session > limits are enforced. > >Our draft http://www.ietf.org/id/draft-wullink-restful-epp-00.txt >aims to solve these issues, by proposing a RESTful EPP interface. > >The Abstract reads: > > This document specifies a 'RESTful interface for EPP' (REPP) with >the =20 > aim to improve efficiency and interoperability of EPP systems. > =20 > > This document includes a new EPP Protocol Extension as well as a >mapping=20 > of [RFC5730] XML-commands to an HTTP based (RESTful) interface. >Existing=20 > semantics and mappings as defined in [RFC5731], [RFC5732] and >[RFC5733] =20 > are largely retained and reusable in RESTful EPP. > =20 > > With REPP, no session is created on the EPP server. Each request >from =20 > client to server will contain all of the information necessary to > =20 > understand the request. The server will close the connection after >each =20 > HTTP request. > =20 > >As the provreg WG is dormant, we have submitted our draft as an individual >submission. > >Since the provreg mailinglist is still very much alive, we are kindly >requesting >its subscribers to provide us with feedback on our proposal. > >Kind regards, > >-- > > Miek Gieben > SIDN Labs >_______________________________________________ >provreg mailing list >provreg@ietf.org >https://www.ietf.org/mailman/listinfo/provreg From maarten.wullink@sidn.nl Mon Apr 23 07:02:58 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B525621F8642 for ; Mon, 23 Apr 2012 07:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpXDbdSwFcKs for ; Mon, 23 Apr 2012 07:02:57 -0700 (PDT) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by ietfa.amsl.com (Postfix) with ESMTP id 8652021F84D3 for ; Mon, 23 Apr 2012 07:02:57 -0700 (PDT) Received: from kahubcas1.SIDN.local ([192.168.2.41]) by ede1-kamx.sidn.nl with ESMTP id q3NE2t7A031915 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=CAFAIL); Mon, 23 Apr 2012 16:02:55 +0200 Received: from KAHUBCASN01.SIDN.local (192.168.2.75) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 23 Apr 2012 16:02:56 +0200 Received: from KAMBX2.SIDN.local ([fe80::b1fd:88d9:e136:9655]) by kahubcasn01.SIDN.local ([::1]) with mapi id 14.02.0247.003; Mon, 23 Apr 2012 16:02:56 +0200 From: Maarten Wullink To: "provreg@ietf.org" Thread-Topic: [provreg] draft-wullink-restful-epp-00.txt Thread-Index: AQHNIT8dLqpQz+y2a0etm9Ue9plxXZaoOSGAgAA0e3A= Date: Mon, 23 Apr 2012 14:02:55 +0000 Message-ID: References: <20120423105147.GA4001@miek.nl> In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.92] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "regops@nlnetlabs.nl" Subject: Re: [provreg] draft-wullink-restful-epp-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 14:02:58 -0000 Stateless EPP makes it possible to load balance individual EPP requests ins= tead of EPP connections. This should make it easier to distribute to load evenly ac= ross the servers. Distributing tcp connections across EPP servers does not guarantee an equal= load on every server. This is because not all EPP connections are equal. Also when there is no persistent tcp connection it should be easier to remo= ve a server from the server pool for maintenance without having to disconnect = the tcp connections of the clients connected to the server. -----Original Message----- From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On Behalf = Of Gould, James Sent: maandag 23 april 2012 14:43 To: Miek Gieben; provreg@ietf.org Cc: regops@nlnetlabs.nl Subject: Re: [provreg] draft-wullink-restful-epp-00.txt This is the first time that I've heard of challenges in load-balanced environments or EPP session state not being linked to an active TCP session. Can you go into more detail of these issues? I've been involved with many EPP-based systems through the years and I've never come across any of these issues. This goes to the heart of the reliability of stateful TCP sessions, which is used with many other protocols. It would be good to discuss the problems posed prior to consideration of a new stateless version of EPP on top of REST. -- =20 JG =20 =20 James Gould Principal Software Engineer jgould@verisign.com =20 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On 4/23/12 6:51 AM, "Miek Gieben" wrote: >Hello, > >[I've cross posted this also to regops@nlnetlabs.nl] > >SIDN, being the registry for .nl, employs EPP as the primary interface for >registrars to submit or manipulate domain names. Even though the protocol >is >working quite well, at SIDN Labs we believed there was room for >improvement. > >Experience over the years revealed certain operational shortcomings in >EPP, >mainly related to the stateful nature of the protocol: > >* EPP may pose challenges in load-balanced environments, when a active >session > has to be switched from one EPP server to another and state is kept on >a per > server basis. > >* EPP sessions can wind up in a state where they are no longer linked to >an > active TCP connection. This may raise problems in situations where >session > limits are enforced. > >Our draft http://www.ietf.org/id/draft-wullink-restful-epp-00.txt >aims to solve these issues, by proposing a RESTful EPP interface. > >The Abstract reads: > > This document specifies a 'RESTful interface for EPP' (REPP) with >the =20 > aim to improve efficiency and interoperability of EPP systems. > =20 > > This document includes a new EPP Protocol Extension as well as a >mapping=20 > of [RFC5730] XML-commands to an HTTP based (RESTful) interface. >Existing=20 > semantics and mappings as defined in [RFC5731], [RFC5732] and >[RFC5733] =20 > are largely retained and reusable in RESTful EPP. > =20 > > With REPP, no session is created on the EPP server. Each request >from =20 > client to server will contain all of the information necessary to > =20 > understand the request. The server will close the connection after >each =20 > HTTP request. > =20 > >As the provreg WG is dormant, we have submitted our draft as an individual >submission. > >Since the provreg mailinglist is still very much alive, we are kindly >requesting >its subscribers to provide us with feedback on our proposal. > >Kind regards, > >-- > > Miek Gieben > SIDN Labs >_______________________________________________ >provreg mailing list >provreg@ietf.org >https://www.ietf.org/mailman/listinfo/provreg _______________________________________________ provreg mailing list provreg@ietf.org https://www.ietf.org/mailman/listinfo/provreg From michael@mwyoung.ca Mon Apr 23 07:18:48 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1426721F8672 for ; Mon, 23 Apr 2012 07:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mx8fCXeXeNKq for ; Mon, 23 Apr 2012 07:18:47 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id CD1D121F864A for ; Mon, 23 Apr 2012 07:18:46 -0700 (PDT) Received: by iazz13 with SMTP id z13so20443319iaz.31 for ; Mon, 23 Apr 2012 07:18:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=PAtFzl2gS6boX1DQaW2Nbts+b+CgYxClh3qo5ynNJYU=; b=JWjTc196vuwSK44wr8i6T+sEglCbYbQXjGvTIimTv3dzG17V77RMekFoLJOcoxHoVD x8MK2mPJt5539dwbGOAYvFd5+svNHmiFk5K72WGuN7cyo40l4GHduLI0LPiroA7nlvmV HwdpSELi2Y3h895F5vokYiRpcj3kIA0zjC1wv5gADM7scee1YApl2NYwiSLUzVq0jaJk S+4lS5BchdZ9OYeb6JmYuN0KBQ0NzrzG6DDnt3Ju/aZ9gxjbxTYaUCmvXt1cfyfYXDgD iIStbFnhp5Hhsc1o2L9JDIhKvvLrfE7E/ocuvJ1NnECJvwpIB42D1p0+WTpQlxddwQGn kOZA== Received: by 10.42.153.10 with SMTP id k10mr1300481icw.24.1335190726410; Mon, 23 Apr 2012 07:18:46 -0700 (PDT) Received: from DUN20111 (CPE7073cbb4404e-CM00080da07047.cpe.net.cable.rogers.com. [99.226.37.72]) by mx.google.com with ESMTPS id ke7sm25942947igc.10.2012.04.23.07.18.43 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Apr 2012 07:18:45 -0700 (PDT) From: "Michael Young" To: "'Maarten Wullink'" , References: <20120423105147.GA4001@miek.nl> In-Reply-To: Date: Mon, 23 Apr 2012 10:18:41 -0400 Message-ID: <004601cd215b$fdcacf80$f9606e80$@mwyoung.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIV5ow05jt68y/PWV2F6dUU7fd3wQJisL+YAfMOtKKV9DriwA== Content-Language: en-ca X-Gm-Message-State: ALoCoQkX8klVi+0St1Nvs050YAqb87KrPEIiIY9QW80s1IoBYtHwqLccVXfZfkIBx06MQhwBjq+J Cc: regops@nlnetlabs.nl Subject: Re: [provreg] draft-wullink-restful-epp-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 14:18:48 -0000 I can see this argument with a high velocity, high volume system, however load-balancing via TCP sessions is a trivial issue with a domain or number registry and individual traffic flows are commonly handled through packet shapers these days. Add in some policy driven rate-limiting and you are more than covered. Now don't assume I am negative on innovating, quite the opposite, I'd love to see us being progressive however I am not sure I see any distinct benefit to moving to a stateless EPP. It would help if you could build a list of pros and cons for stateless EPP and also describe the trust model you would use for the source traffic - so we can understand how the current solution stacks up against what you are proposing. Best Regards, Michael Young -----Original Message----- From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On Behalf Of Maarten Wullink Sent: April-23-12 10:03 AM To: provreg@ietf.org Cc: regops@nlnetlabs.nl Subject: Re: [provreg] draft-wullink-restful-epp-00.txt Stateless EPP makes it possible to load balance individual EPP requests instead of EPP connections. This should make it easier to distribute to load evenly across the servers. Distributing tcp connections across EPP servers does not guarantee an equal load on every server. This is because not all EPP connections are equal. Also when there is no persistent tcp connection it should be easier to remove a server from the server pool for maintenance without having to disconnect the tcp connections of the clients connected to the server. -----Original Message----- From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On Behalf Of Gould, James Sent: maandag 23 april 2012 14:43 To: Miek Gieben; provreg@ietf.org Cc: regops@nlnetlabs.nl Subject: Re: [provreg] draft-wullink-restful-epp-00.txt This is the first time that I've heard of challenges in load-balanced environments or EPP session state not being linked to an active TCP session. Can you go into more detail of these issues? I've been involved with many EPP-based systems through the years and I've never come across any of these issues. This goes to the heart of the reliability of stateful TCP sessions, which is used with many other protocols. It would be good to discuss the problems posed prior to consideration of a new stateless version of EPP on top of REST. -- JG James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On 4/23/12 6:51 AM, "Miek Gieben" wrote: >Hello, > >[I've cross posted this also to regops@nlnetlabs.nl] > >SIDN, being the registry for .nl, employs EPP as the primary interface >for registrars to submit or manipulate domain names. Even though the >protocol is working quite well, at SIDN Labs we believed there was room >for improvement. > >Experience over the years revealed certain operational shortcomings in >EPP, mainly related to the stateful nature of the protocol: > >* EPP may pose challenges in load-balanced environments, when a active >session > has to be switched from one EPP server to another and state is kept >on a per > server basis. > >* EPP sessions can wind up in a state where they are no longer linked >to an > active TCP connection. This may raise problems in situations where >session > limits are enforced. > >Our draft http://www.ietf.org/id/draft-wullink-restful-epp-00.txt >aims to solve these issues, by proposing a RESTful EPP interface. > >The Abstract reads: > > This document specifies a 'RESTful interface for EPP' (REPP) with >the > aim to improve efficiency and interoperability of EPP systems. > > > This document includes a new EPP Protocol Extension as well as a >mapping > of [RFC5730] XML-commands to an HTTP based (RESTful) interface. >Existing > semantics and mappings as defined in [RFC5731], [RFC5732] and >[RFC5733] > are largely retained and reusable in RESTful EPP. > > > With REPP, no session is created on the EPP server. Each request >from > client to server will contain all of the information necessary >to > > understand the request. The server will close the connection >after each > HTTP request. > > >As the provreg WG is dormant, we have submitted our draft as an >individual submission. > >Since the provreg mailinglist is still very much alive, we are kindly >requesting its subscribers to provide us with feedback on our proposal. > >Kind regards, > >-- > > Miek Gieben > SIDN Labs >_______________________________________________ >provreg mailing list >provreg@ietf.org >https://www.ietf.org/mailman/listinfo/provreg _______________________________________________ provreg mailing list provreg@ietf.org https://www.ietf.org/mailman/listinfo/provreg _______________________________________________ provreg mailing list provreg@ietf.org https://www.ietf.org/mailman/listinfo/provreg From Klaus.Malorny@knipp.de Mon Apr 23 07:20:12 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE3B21F8669 for ; Mon, 23 Apr 2012 07:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kbj+7dBrn42x for ; Mon, 23 Apr 2012 07:20:12 -0700 (PDT) Received: from kmx10a.knipp.de (clust3a-eth0-0.bbone.knipp.de [195.253.6.83]) by ietfa.amsl.com (Postfix) with ESMTP id AC56321F864A for ; Mon, 23 Apr 2012 07:20:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 4F6038B; Mon, 23 Apr 2012 16:20:10 +0200 (MESZ) X-Knipp-VirusScanned: Yes Received: from kmx10a.knipp.de ([127.0.0.1]) by localhost (kmx10a.knipp.de [127.0.0.1]) (amavisd-new, port 10004) with ESMTP id 6a-gHUxA4xVe; Mon, 23 Apr 2012 16:20:04 +0200 (MESZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id B9F6C78; Mon, 23 Apr 2012 16:20:04 +0200 (MESZ) Received: from [195.253.2.27] (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id q3NEK41K022304; Mon, 23 Apr 2012 16:20:04 +0200 (MESZ) Message-ID: <4F956514.1050609@knipp.de> Date: Mon, 23 Apr 2012 16:20:04 +0200 From: Klaus Malorny User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120422 Thunderbird/14.0a1 MIME-Version: 1.0 To: Maarten Wullink References: <20120423105147.GA4001@miek.nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "regops@nlnetlabs.nl" , "provreg@ietf.org" Subject: Re: [provreg] draft-wullink-restful-epp-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 14:20:12 -0000 On 23/04/12 16:02, Maarten Wullink wrote: > Stateless EPP makes it possible to load balance individual EPP requests instead of > EPP connections. This should make it easier to distribute to load evenly across the servers. > Distributing tcp connections across EPP servers does not guarantee an equal load on every server. This > is because not all EPP connections are equal. > > Also when there is no persistent tcp connection it should be easier to remove > a server from the server pool for maintenance without having to disconnect the tcp connections of the > clients connected to the server. > Hi all, while I have mixed feelings regarding the REST approach, I agree to the arguments: Although RFC 5734 allows the server to actively terminate the communication with the client, it can only do this by closing the connection. There is no graceful shutdown that would allow the client to prevent an I/O error on the attempt to write a message. Assuming a busy connection, the sudden interruption leaves the client in an ambiguous state whether the (partially) transmitted request has been received and processed by the server. For the benefit of the registrars, we avoid to close connections in our server side EPP implementation except for those connections which are idle over a long period. As a consequence, in a load balanced configuration, the balancing can actually only occur via the assignment of new connections to the server with the lowest load, so an unequal load cannot easily be leveled. Regards, Klaus From ajs@anvilwalrusden.com Mon Apr 23 07:45:12 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFAFE21F869D for ; Mon, 23 Apr 2012 07:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.672 X-Spam-Level: X-Spam-Status: No, score=-2.672 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCcO43OZa+t3 for ; Mon, 23 Apr 2012 07:45:12 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 417E821F8675 for ; Mon, 23 Apr 2012 07:45:12 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id AA5A81ECB41C for ; Mon, 23 Apr 2012 14:45:11 +0000 (UTC) Date: Mon, 23 Apr 2012 10:45:10 -0400 From: Andrew Sullivan To: provreg@ietf.org Message-ID: <20120423144504.GG55520@mail.yitter.info> References: <20120423105147.GA4001@miek.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [provreg] draft-wullink-restful-epp-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 14:45:13 -0000 On Mon, Apr 23, 2012 at 02:02:55PM +0000, Maarten Wullink wrote: > Stateless EPP makes it possible to load balance individual EPP > requests instead of EPP connections. "Stateless N makes it possible to treat formerly-stateful protocol N statelessly." Yes, obviously. The question is partly whether that is a good idea, & I'm not sure I see what the argument is there. A -- Andrew Sullivan ajs@anvilwalrusden.com From michael@mwyoung.ca Mon Apr 23 07:49:09 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB28421F869D for ; Mon, 23 Apr 2012 07:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5Dun6qJmvaB for ; Mon, 23 Apr 2012 07:49:07 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7B25B21F8630 for ; Mon, 23 Apr 2012 07:49:07 -0700 (PDT) Received: by iazz13 with SMTP id z13so20482220iaz.31 for ; Mon, 23 Apr 2012 07:49:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=xvnmCuImuggkO5699+39CfdbQZb+WSi4lDQKWlcggg0=; b=iskXX5T+EzmG9xmsFb3VwEnqCKNbD2OZG0zxMF4ErGx3rWWhRul8qEycW6MoKeCDSX eem+D18NuAtbS44UCCOhvEPUfRceB2iloPH8JnMrb6f0GH0zw7U6DYH2A6YHQdTQ2trl QbUB94qCzRAvxFkUwUDb/1ZOzVU3KJck0aOwYDzQtwXpbRHoU/GE95Vb/ePHRd7GC2Q4 /tpDxzq/khxmFcsaOZm5m/zMD/c3QzhZXELsSg2nvULqNMUNcRuTEhOrFX9PNN0/2LO+ Oae/FMtjHs1XN5+Pn4cHR+XuhV9xXdLVG34bi6EoQiIbm78zZO/864TP/5743lG72aY+ Tr5A== Received: by 10.42.130.199 with SMTP id w7mr11552398ics.23.1335192544762; Mon, 23 Apr 2012 07:49:04 -0700 (PDT) Received: from DUN20111 (CPE7073cbb4404e-CM00080da07047.cpe.net.cable.rogers.com. [99.226.37.72]) by mx.google.com with ESMTPS id em4sm11560933igc.16.2012.04.23.07.49.03 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Apr 2012 07:49:03 -0700 (PDT) From: "Michael Young" To: "'Klaus Malorny'" , "'Maarten Wullink'" References: <20120423105147.GA4001@miek.nl> <4F956514.1050609@knipp.de> In-Reply-To: <4F956514.1050609@knipp.de> Date: Mon, 23 Apr 2012 10:49:01 -0400 Message-ID: <005b01cd2160$39b9fe40$ad2dfac0$@mwyoung.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIV5ow05jt68y/PWV2F6dUU7fd3wQJisL+YAfMOtKICpaPU8JXfE3Zw Content-Language: en-ca X-Gm-Message-State: ALoCoQkDTtgCHty7VFCwssYkqaZRnq36wKNatvGBiWRW/qnLXDv4TQdcJa9aYPRq2URZFu8QMQAO Cc: regops@nlnetlabs.nl, provreg@ietf.org Subject: Re: [provreg] draft-wullink-restful-epp-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 14:49:09 -0000 See my earlier email Klaus but there's no reason why you can't terminate a connection based on a policy for permitted packet flows - so I still don't see this as any kind of a significant problem. You do have to use a persistent connection algorithm when using a load-balancer, however with packet-shapers you can set policies on the maximum flow rate per connection or even across a group of connections. In short, you are expecting the client to take some responsibility for not hammering the server within a single connection and limiting them if they do. I don't see valid use case where a single EPP connection operating against today's equipment and environs would need to apply an excessive amount of load for a server in the course of any normal registry business. If you know of one, I'd love to know about it. Namedrop behaviours of course are another special use case, but segmented special connection pools and rate-limiting have typically solved that one as well. The scope of the namedrop server hammering was also reduced by the now active secondary marketplace that occurs prior to a name being dropped in the first place. Best Regards, Michael Young -----Original Message----- From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On Behalf Of Klaus Malorny Sent: April-23-12 10:20 AM To: Maarten Wullink Cc: regops@nlnetlabs.nl; provreg@ietf.org Subject: Re: [provreg] draft-wullink-restful-epp-00.txt On 23/04/12 16:02, Maarten Wullink wrote: > Stateless EPP makes it possible to load balance individual EPP > requests instead of EPP connections. This should make it easier to distribute to load evenly across the servers. > Distributing tcp connections across EPP servers does not guarantee an > equal load on every server. This is because not all EPP connections are equal. > > Also when there is no persistent tcp connection it should be easier to > remove a server from the server pool for maintenance without having to > disconnect the tcp connections of the clients connected to the server. > Hi all, while I have mixed feelings regarding the REST approach, I agree to the arguments: Although RFC 5734 allows the server to actively terminate the communication with the client, it can only do this by closing the connection. There is no graceful shutdown that would allow the client to prevent an I/O error on the attempt to write a message. Assuming a busy connection, the sudden interruption leaves the client in an ambiguous state whether the (partially) transmitted request has been received and processed by the server. For the benefit of the registrars, we avoid to close connections in our server side EPP implementation except for those connections which are idle over a long period. As a consequence, in a load balanced configuration, the balancing can actually only occur via the assignment of new connections to the server with the lowest load, so an unequal load cannot easily be leveled. Regards, Klaus _______________________________________________ provreg mailing list provreg@ietf.org https://www.ietf.org/mailman/listinfo/provreg From JGould@verisign.com Mon Apr 23 09:26:42 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFFE21F876E for ; Mon, 23 Apr 2012 09:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlmK6mijSf2m for ; Mon, 23 Apr 2012 09:26:40 -0700 (PDT) Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) by ietfa.amsl.com (Postfix) with ESMTP id D63E421F872E for ; Mon, 23 Apr 2012 09:26:36 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKT5WCst9nlnFUrXJKFuu4ki/y+fJxHNT3@postini.com; Mon, 23 Apr 2012 09:26:40 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q3NGQKcZ020477; Mon, 23 Apr 2012 12:26:20 -0400 Received: from dul1wnexcn04.vcorp.ad.vrsn.com ([10.170.12.139]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Apr 2012 12:26:14 -0400 Received: from BRN1WNEXCAS02.vcorp.ad.vrsn.com ([10.173.152.206]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Apr 2012 12:26:15 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Mon, 23 Apr 2012 12:26:04 -0400 From: "Gould, James" To: Rubens Kuhl , Maarten Wullink Thread-Topic: [Regops] [provreg] draft-wullink-restful-epp-00.txt Thread-Index: AQHNIT8Td2Wno5teB0WLeILaM3K96ZaoWrKAgABZbYCAABKhAP//0l+A Date: Mon, 23 Apr 2012 16:26:09 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1889B23BFCDE1B40A3251FA46240FCAB@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Apr 2012 16:26:15.0607 (UTC) FILETIME=[CE124C70:01CD216D] Cc: "regops@nlnetlabs.nl" , "provreg@ietf.org" Subject: Re: [provreg] [Regops] draft-wullink-restful-epp-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 16:26:42 -0000 In reading the messages it looks like the two issues with the stateful TCP session raised include: 1. EPP may pose challenges in load-balanced environments - What has been raised is load-balancing on a per-command basis instead of a per-connection basis. Load balancing the connections distributes the load fine today. If there is a need to load balance on a per command basis, you can keep the state in the gateways and load balance the requests to a tier of stateless application servers. The same thing can be done on a per command type basis, by having the gateways send the commands to the different set of backend application servers. The gateways are typically the least utilized in this scheme, so spreading the load on them doesn't really solve any problems. A case was made that stateless would improve performance, but I believe it will greatly decrease the performance. I'm assuming that the security elements still apply (2-way SSL as well as authentication) which would need to be done on a per-command basis in the stateless model. Creating of the 2-way SSL connection even with SSL session resumption will add a lot of extra overhead on a per command basis. Passing the user credentials to authenticate the user on a per command basis will also add a lot of extra overhead. Can someone describe how these elements will be mitigated in a stateless model? Overall, I don=B9t see how moving from stateful to stateless will benefit either the client or the server from a performance or load perspective. 2. EPP sessions can wind up in a state where they are no longer linked to an active TCP session - Can someone describe this issue? -- =20 JG =20 =20 James Gould Principal Software Engineer jgould@verisign.com =20 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On 4/23/12 11:09 AM, "Rubens Kuhl" wrote: > >Stateless requests also allow for having different pools of servers for >different types of requests. For instance, mapping "domain info" to >servers on a read-only database and "domain create" to servers with write >access to the database. Can improve performance, security, or both. > > >Rubens > > >On Apr 23, 2012, at 11:02 AM, Maarten Wullink wrote: > >> Stateless EPP makes it possible to load balance individual EPP requests >>instead of >> EPP connections. This should make it easier to distribute to load >>evenly across the servers. >> Distributing tcp connections across EPP servers does not guarantee an >>equal load on every server. This >> is because not all EPP connections are equal. >>=20 >> Also when there is no persistent tcp connection it should be easier to >>remove >> a server from the server pool for maintenance without having to >>disconnect the tcp connections of the >> clients connected to the server. >>=20 >> -----Original Message----- >> From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On >>Behalf Of Gould, James >> Sent: maandag 23 april 2012 14:43 >> To: Miek Gieben; provreg@ietf.org >> Cc: regops@nlnetlabs.nl >> Subject: Re: [provreg] draft-wullink-restful-epp-00.txt >>=20 >> This is the first time that I've heard of challenges in load-balanced >> environments or EPP session state not being linked to an active TCP >> session. Can you go into more detail of these issues? I've been >>involved >> with many EPP-based systems through the years and I've never come across >> any of these issues. This goes to the heart of the reliability of >> stateful TCP sessions, which is used with many other protocols. It >>would >> be good to discuss the problems posed prior to consideration of a new >> stateless version of EPP on top of REST. >>=20 >> -- >>=20 >> JG >>=20 >>=20 >>=20 >> James Gould >> Principal Software Engineer >> jgould@verisign.com >>=20 >> 703-948-3271 (Office) >> 12061 Bluemont Way >> Reston, VA 20190 >> VerisignInc.com >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On 4/23/12 6:51 AM, "Miek Gieben" wrote: >>=20 >>> Hello, >>>=20 >>> [I've cross posted this also to regops@nlnetlabs.nl] >>>=20 >>> SIDN, being the registry for .nl, employs EPP as the primary interface >>>for >>> registrars to submit or manipulate domain names. Even though the >>>protocol >>> is >>> working quite well, at SIDN Labs we believed there was room for >>> improvement. >>>=20 >>> Experience over the years revealed certain operational shortcomings in >>> EPP, >>> mainly related to the stateful nature of the protocol: >>>=20 >>> * EPP may pose challenges in load-balanced environments, when a active >>> session >>> has to be switched from one EPP server to another and state is kept on >>> a per >>> server basis. >>>=20 >>> * EPP sessions can wind up in a state where they are no longer linked >>>to >>> an >>> active TCP connection. This may raise problems in situations where >>> session >>> limits are enforced. >>>=20 >>> Our draft http://www.ietf.org/id/draft-wullink-restful-epp-00.txt >>> aims to solve these issues, by proposing a RESTful EPP interface. >>>=20 >>> The Abstract reads: >>>=20 >>> This document specifies a 'RESTful interface for EPP' (REPP) with >>> the =20 >>> aim to improve efficiency and interoperability of EPP systems. >>>=20 >>>=20 >>> This document includes a new EPP Protocol Extension as well as a >>> mapping=20 >>> of [RFC5730] XML-commands to an HTTP based (RESTful) interface. >>> Existing=20 >>> semantics and mappings as defined in [RFC5731], [RFC5732] and >>> [RFC5733] =20 >>> are largely retained and reusable in RESTful EPP. >>>=20 >>>=20 >>> With REPP, no session is created on the EPP server. Each request >>> from =20 >>> client to server will contain all of the information necessary to >>>=20 >>> understand the request. The server will close the connection after >>> each =20 >>> HTTP request. >>>=20 >>>=20 >>> As the provreg WG is dormant, we have submitted our draft as an >>>individual >>> submission. >>>=20 >>> Since the provreg mailinglist is still very much alive, we are kindly >>> requesting >>> its subscribers to provide us with feedback on our proposal. >>>=20 >>> Kind regards, >>>=20 >>> -- >>>=20 >>> Miek Gieben >>> SIDN Labs >>> _______________________________________________ >>> provreg mailing list >>> provreg@ietf.org >>> https://www.ietf.org/mailman/listinfo/provreg >>=20 >> _______________________________________________ >> provreg mailing list >> provreg@ietf.org >> https://www.ietf.org/mailman/listinfo/provreg >>=20 >> _______________________________________________ >> regops mailing list >> regops@nlnetlabs.nl >> http://nlnetlabs.nl/mailman/listinfo/regops > > >_______________________________________________ >regops mailing list >regops@nlnetlabs.nl >http://nlnetlabs.nl/mailman/listinfo/regops From fobispo@isc.org Mon Apr 23 10:05:53 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9FB21F85BE for ; Mon, 23 Apr 2012 10:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2oEFNON-nIx for ; Mon, 23 Apr 2012 10:05:53 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id CCCB821F85B6 for ; Mon, 23 Apr 2012 10:05:52 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 5A3F75F99A5; Mon, 23 Apr 2012 17:05:38 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [192.168.255.106] (c-76-126-250-157.hsd1.ca.comcast.net [76.126.250.157]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 74456216C31; Mon, 23 Apr 2012 17:05:36 +0000 (UTC) (envelope-from fobispo@isc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Francisco Obispo In-Reply-To: Date: Mon, 23 Apr 2012 10:05:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Gould, James" X-Mailer: Apple Mail (2.1257) Cc: "regops@nlnetlabs.nl" , "provreg@ietf.org" , Rubens Kuhl Subject: Re: [provreg] [Regops] draft-wullink-restful-epp-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 17:05:53 -0000 You could initiate a session with a RESTful server, just like most = websites work: - You will use a RESTful URL to create a session: /session/user_id = [POST] - The server would return a cookie, which you will return with every = RESTful request. - When you're done processing requests you can: /session/user_id = [DELETE] The advantage of this model, is that you can use the existing knowledge = on how to scale web-services and apply them to Registry-Registrar = interactions. Francisco On Apr 23, 2012, at 9:26 AM, Gould, James wrote: > Passing the user credentials to authenticate the user on a per > command basis will also add a lot of extra overhead. Can someone = describe > how these elements will be mitigated in a stateless model? Overall, I > don=B9t see how moving from stateful to stateless will benefit either = the > client or the server from a performance or load perspective. Francisco Obispo=20 email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From rubensk@nic.br Mon Apr 23 08:09:46 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 214EB21F85E3 for ; Mon, 23 Apr 2012 08:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDdn0rFMQEDU for ; Mon, 23 Apr 2012 08:09:42 -0700 (PDT) Received: from mail.nic.br (mail.cgi.br [IPv6:2001:12ff:0:4::5]) by ietfa.amsl.com (Postfix) with ESMTP id B64EB21F85E1 for ; Mon, 23 Apr 2012 08:09:41 -0700 (PDT) Received: from rubens.in.registro.br (3.195.net.registro.br [200.160.3.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.nic.br (Postfix) with ESMTPSA id BF7AB2080154; Mon, 23 Apr 2012 12:09:36 -0300 (BRT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Rubens Kuhl In-Reply-To: Date: Mon, 23 Apr 2012 12:09:36 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120423105147.GA4001@miek.nl> To: Maarten Wullink X-Mailer: Apple Mail (2.1257) X-Mailman-Approved-At: Mon, 23 Apr 2012 10:12:45 -0700 Cc: "regops@nlnetlabs.nl" , "provreg@ietf.org" Subject: Re: [provreg] [Regops] draft-wullink-restful-epp-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 17:00:43 -0000 Stateless requests also allow for having different pools of servers for = different types of requests. For instance, mapping "domain info" to = servers on a read-only database and "domain create" to servers with = write access to the database. Can improve performance, security, or = both.=20 Rubens On Apr 23, 2012, at 11:02 AM, Maarten Wullink wrote: > Stateless EPP makes it possible to load balance individual EPP = requests instead of > EPP connections. This should make it easier to distribute to load = evenly across the servers. > Distributing tcp connections across EPP servers does not guarantee an = equal load on every server. This > is because not all EPP connections are equal. >=20 > Also when there is no persistent tcp connection it should be easier to = remove > a server from the server pool for maintenance without having to = disconnect the tcp connections of the > clients connected to the server. >=20 > -----Original Message----- > From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On = Behalf Of Gould, James > Sent: maandag 23 april 2012 14:43 > To: Miek Gieben; provreg@ietf.org > Cc: regops@nlnetlabs.nl > Subject: Re: [provreg] draft-wullink-restful-epp-00.txt >=20 > This is the first time that I've heard of challenges in load-balanced > environments or EPP session state not being linked to an active TCP > session. Can you go into more detail of these issues? I've been = involved > with many EPP-based systems through the years and I've never come = across > any of these issues. This goes to the heart of the reliability of > stateful TCP sessions, which is used with many other protocols. It = would > be good to discuss the problems posed prior to consideration of a new > stateless version of EPP on top of REST. >=20 > -- >=20 > JG >=20 >=20 >=20 > James Gould > Principal Software Engineer > jgould@verisign.com >=20 > 703-948-3271 (Office) > 12061 Bluemont Way > Reston, VA 20190 > VerisignInc.com >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On 4/23/12 6:51 AM, "Miek Gieben" wrote: >=20 >> Hello, >>=20 >> [I've cross posted this also to regops@nlnetlabs.nl] >>=20 >> SIDN, being the registry for .nl, employs EPP as the primary = interface for >> registrars to submit or manipulate domain names. Even though the = protocol >> is >> working quite well, at SIDN Labs we believed there was room for >> improvement. >>=20 >> Experience over the years revealed certain operational shortcomings = in >> EPP, >> mainly related to the stateful nature of the protocol: >>=20 >> * EPP may pose challenges in load-balanced environments, when a = active >> session >> has to be switched from one EPP server to another and state is kept = on >> a per >> server basis. >>=20 >> * EPP sessions can wind up in a state where they are no longer linked = to >> an >> active TCP connection. This may raise problems in situations where >> session >> limits are enforced. >>=20 >> Our draft http://www.ietf.org/id/draft-wullink-restful-epp-00.txt >> aims to solve these issues, by proposing a RESTful EPP interface. >>=20 >> The Abstract reads: >>=20 >> This document specifies a 'RESTful interface for EPP' (REPP) = with >> the =20 >> aim to improve efficiency and interoperability of EPP systems. >>=20 >>=20 >> This document includes a new EPP Protocol Extension as well as a >> mapping=20 >> of [RFC5730] XML-commands to an HTTP based (RESTful) interface. >> Existing=20 >> semantics and mappings as defined in [RFC5731], [RFC5732] and >> [RFC5733] =20 >> are largely retained and reusable in RESTful EPP. >>=20 >>=20 >> With REPP, no session is created on the EPP server. Each request >> from =20 >> client to server will contain all of the information necessary = to >>=20 >> understand the request. The server will close the connection = after >> each =20 >> HTTP request. >>=20 >>=20 >> As the provreg WG is dormant, we have submitted our draft as an = individual >> submission. >>=20 >> Since the provreg mailinglist is still very much alive, we are kindly >> requesting >> its subscribers to provide us with feedback on our proposal. >>=20 >> Kind regards, >>=20 >> -- >>=20 >> Miek Gieben >> SIDN Labs >> _______________________________________________ >> provreg mailing list >> provreg@ietf.org >> https://www.ietf.org/mailman/listinfo/provreg >=20 > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg >=20 > _______________________________________________ > regops mailing list > regops@nlnetlabs.nl > http://nlnetlabs.nl/mailman/listinfo/regops From JGould@verisign.com Mon Apr 23 10:58:10 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8519E21F85A4 for ; Mon, 23 Apr 2012 10:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.723 X-Spam-Level: X-Spam-Status: No, score=-5.723 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHHvL9Ze4JHr for ; Mon, 23 Apr 2012 10:58:09 -0700 (PDT) Received: from exprod6og103.obsmtp.com (exprod6og103.obsmtp.com [64.18.1.185]) by ietfa.amsl.com (Postfix) with ESMTP id 650E221F854D for ; Mon, 23 Apr 2012 10:58:04 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP ID DSNKT5WYJwYdpegRNKWBaIF4Y0ioFpMqYX/2@postini.com; Mon, 23 Apr 2012 10:58:09 PDT Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q3NHvoDd023435; Mon, 23 Apr 2012 13:57:50 -0400 Received: from dul1wnexcn04.vcorp.ad.vrsn.com ([10.170.12.139]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Apr 2012 13:57:44 -0400 Received: from BRN1WNEXCAS01.vcorp.ad.vrsn.com ([10.173.152.205]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Apr 2012 13:57:45 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Mon, 23 Apr 2012 13:57:33 -0400 From: "Gould, James" To: Francisco Obispo Thread-Topic: [provreg] [Regops] draft-wullink-restful-epp-00.txt Thread-Index: AQHNIXNW/QMJrKFNaU6fmilPP1Ol95aoskeA Date: Mon, 23 Apr 2012 17:57:39 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="euc-kr" Content-ID: <972A8D50DE9DDD4199518A3B3C6D771A@verisign.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 23 Apr 2012 17:57:45.0357 (UTC) FILETIME=[9637ABD0:01CD217A] Cc: "regops@nlnetlabs.nl" , "provreg@ietf.org" , Rubens Kuhl Subject: Re: [provreg] [Regops] draft-wullink-restful-epp-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 17:58:10 -0000 RnJhbmNpc2NvLA0KDQpTbyB5b3VyIHByb3Bvc2FsIGlzIHRvIG1ha2UgaXQgc3RhdGVmdWwgYmFz ZWQgb24gdGhlIEhUVFAgc2Vzc2lvbj8gIFRoaXMNCndvdWxkIG1pdGlnYXRlIHRoZSBhdXRoZW50 aWNhdGlvbiBwZXIgY29tbWFuZCBpc3N1ZTsgYWx0aG91Z2ggaXQgaXMNCnN3aXRjaGluZyB0aGUg ZGlzY3Vzc2lvbiBmcm9tIHN0YXRlbGVzcyBiYWNrIHRvIHN0YXRlZnVsLiAgVGhlcmUgaXMgc3Rp bGwNCnRoZSBjb25uZWN0aW9uIGVzdGFibGlzaG1lbnQgb3ZlcmhlYWQgKDItd2F5IFNTTCkgdGhh dCB3aWxsIGRlY3JlYXNlIHRoZQ0KcGVyZm9ybWFuY2UuICBEbyB5b3UgaGF2ZSBhIHByb3Bvc2Fs IHRvIG1pdGlnYXRlIHRoYXQ/ICBJcyB0aGVyZSBhbg0KcGVyY2VpdmVkIHByb2JsZW0gaW4gc2Nh bGluZyByZWdpc3RyeSBzZXJ2aWNlcyB0aGF0IG5lZWRzIHRvIGJlIHNvbHZlZCBhbmQNCmlmIHNv IGNhbiB5b3UgcHJvdmlkZSBhbnkgZGV0YWlscz8gIEkgYmVsaWV2ZSB0aGF0IHRoZSByZWdpc3Ry aWVzIGhhdmUNCnNob3duIHRoYXQgRVBQIGNhbiBzY2FsZSB3aXRob3V0IHRoZSBuZWVkIHRvIGFk ZCBIVFRQIHRvIHRoZSBzdGFjay4gIFdlDQpkZWZpbmVkIGFuZCB1c2VkIGFuIEVQUCBIVFRQIHRy YW5zcG9ydCBmb3Igb3ZlciA2IHllYXJzLCB3aGljaCBkaWQgYWxsb3cNCmZvciBzY2FsaW5nIHRo ZSBzZXJ2ZXItc2lkZSB1c2luZyBzdGFuZGFyZCB3ZWIgc2NhbGluZyB0ZWNobmlxdWVzLiAgSFRU UA0Ka2VlcC1hbGl2ZSB3YXMgdXNlZCB0byBtYWludGFpbiB0aGUgRVBQIHNlc3Npb24gd2l0aCB0 aGUgc2VydmVyLiAgRVBQIFRDUA0KZGlkIHBlcmZvcm0gYmV0dGVyIHNpbmNlIGl0IGRpZG4ndCBp bmNsdWRlIHRoZSBIVFRQIG92ZXJoZWFkIGluIHRoZSBzdGFjay4NCiBUaGUgRVBQIEhUVFAgdHJh bnNwb3J0IHdhcyBsaWdodGx5IHVzZWQgc2luY2UgdGhlIHByZWZlcmVuY2Ugd2FzIHRvIHVzZQ0K RVBQIFRDUCwgYnV0IHRoaXMgaXMgYW4gb3B0aW9uIHRvIGNvbnNpZGVyLg0KDQoNCi0tDQogIA0K SkcNCiANCg0KIA0KSmFtZXMgR291bGQNClByaW5jaXBhbCBTb2Z0d2FyZSBFbmdpbmVlcg0Kamdv dWxkQHZlcmlzaWduLmNvbQ0KIA0KNzAzLTk0OC0zMjcxIChPZmZpY2UpDQoxMjA2MSBCbHVlbW9u dCBXYXkNClJlc3RvbiwgVkEgMjAxOTANClZlcmlzaWduSW5jLmNvbQ0KDQoNCg0KDQoNCg0KDQpP biA0LzIzLzEyIDE6MDUgUE0sICJGcmFuY2lzY28gT2Jpc3BvIiA8Zm9iaXNwb0Bpc2Mub3JnPiB3 cm90ZToNCg0KPg0KPllvdSBjb3VsZCBpbml0aWF0ZSBhIHNlc3Npb24gd2l0aCBhIFJFU1RmdWwg c2VydmVyLCBqdXN0IGxpa2UgbW9zdA0KPndlYnNpdGVzIHdvcms6DQo+DQo+LSBZb3Ugd2lsbCB1 c2UgYSBSRVNUZnVsIFVSTCB0byBjcmVhdGUgYSBzZXNzaW9uOiAvc2Vzc2lvbi91c2VyX2lkIFtQ T1NUXQ0KPg0KPi0gVGhlIHNlcnZlciB3b3VsZCByZXR1cm4gYSBjb29raWUsIHdoaWNoIHlvdSB3 aWxsIHJldHVybiB3aXRoIGV2ZXJ5DQo+UkVTVGZ1bCByZXF1ZXN0Lg0KPg0KPi0gV2hlbiB5b3Un cmUgZG9uZSBwcm9jZXNzaW5nIHJlcXVlc3RzIHlvdSBjYW46IC9zZXNzaW9uL3VzZXJfaWQgW0RF TEVURV0NCj4NCj5UaGUgYWR2YW50YWdlIG9mIHRoaXMgbW9kZWwsIGlzIHRoYXQgeW91IGNhbiB1 c2UgdGhlIGV4aXN0aW5nIGtub3dsZWRnZQ0KPm9uIGhvdyB0byBzY2FsZSB3ZWItc2VydmljZXMg YW5kIGFwcGx5IHRoZW0gdG8gUmVnaXN0cnktUmVnaXN0cmFyDQo+aW50ZXJhY3Rpb25zLg0KPg0K PkZyYW5jaXNjbw0KPg0KPg0KPg0KPg0KPk9uIEFwciAyMywgMjAxMiwgYXQgOToyNiBBTSwgR291 bGQsIEphbWVzIHdyb3RlOg0KPg0KPj4gUGFzc2luZyB0aGUgdXNlciBjcmVkZW50aWFscyB0byBh dXRoZW50aWNhdGUgdGhlIHVzZXIgb24gYSBwZXINCj4+IGNvbW1hbmQgYmFzaXMgd2lsbCBhbHNv IGFkZCBhIGxvdCBvZiBleHRyYSBvdmVyaGVhZC4gIENhbiBzb21lb25lDQo+PmRlc2NyaWJlDQo+ PiBob3cgdGhlc2UgZWxlbWVudHMgd2lsbCBiZSBtaXRpZ2F0ZWQgaW4gYSBzdGF0ZWxlc3MgbW9k ZWw/ICBPdmVyYWxsLCBJDQo+PiBkb26p9nQgc2VlIGhvdyBtb3ZpbmcgZnJvbSBzdGF0ZWZ1bCB0 byBzdGF0ZWxlc3Mgd2lsbCBiZW5lZml0IGVpdGhlciB0aGUNCj4+IGNsaWVudCBvciB0aGUgc2Vy dmVyIGZyb20gYSBwZXJmb3JtYW5jZSBvciBsb2FkIHBlcnNwZWN0aXZlLg0KPg0KPkZyYW5jaXNj byBPYmlzcG8gDQo+ZW1haWw6IGZvYmlzcG9AaXNjLm9yZw0KPlBob25lOiArMSA2NTAgNDIzIDEz NzQgfHwgSU5PQy1EQkEgKjM1NTcqIE5PQw0KPlBHUCBLZXlJRCA9IEIzOERCMUJFDQo+DQoNCg== From fobispo@isc.org Mon Apr 23 11:33:15 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A623E21E8013 for ; Mon, 23 Apr 2012 11:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MuTTu613Pc8T for ; Mon, 23 Apr 2012 11:33:14 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0F921E8012 for ; Mon, 23 Apr 2012 11:33:14 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 931F45F98A2; Mon, 23 Apr 2012 18:32:59 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [192.168.255.106] (c-76-126-250-157.hsd1.ca.comcast.net [76.126.250.157]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id AE322216C31; Mon, 23 Apr 2012 18:32:57 +0000 (UTC) (envelope-from fobispo@isc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=euc-kr From: Francisco Obispo In-Reply-To: Date: Mon, 23 Apr 2012 11:32:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <02ACAD0F-4AED-408A-A08F-C37F2B12B442@isc.org> References: To: "Gould, James" X-Mailer: Apple Mail (2.1257) Cc: "regops@nlnetlabs.nl" , "provreg@ietf.org" , Rubens Kuhl Subject: Re: [provreg] [Regops] draft-wullink-restful-epp-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 18:33:16 -0000 On Apr 23, 2012, at 10:57 AM, Gould, James wrote: > Francisco, >=20 > So your proposal is to make it stateful based on the HTTP session? = This Yes, you can keep HTTP-session information in a shared way across = multiple servers (memcached, SQL-db, etc). so you can have any front-end = server vailidate it. Clients can keep the connection (or session) alive by issuing commands = periodically. > would mitigate the authentication per command issue; although it is > switching the discussion from stateless back to stateful. There is = still > the connection establishment overhead (2-way SSL) that will decrease = the > performance. =20 On the client side, you could have pre-cached connections with multiple = servers. > Do you have a proposal to mitigate that? Is there an > perceived problem in scaling registry services that needs to be solved = and > if so can you provide any details? I believe that the registries have > shown that EPP can scale without the need to add HTTP to the stack. = We > defined and used an EPP HTTP transport for over 6 years, which did = allow > for scaling the server-side using standard web scaling techniques. = HTTP > keep-alive was used to maintain the EPP session with the server. EPP = TCP > did perform better since it didn't include the HTTP overhead in the = stack. > The EPP HTTP transport was lightly used since the preference was to = use > EPP TCP, but this is an option to consider. I guess something like this could be implemented with EPP (over TCP), by = building an extension to deal with the session information: 1) EPP authenticates and generates a cookie (stored in a shared = system)=20 that gets sent in the section 2) Subsequent requests are validated with that cookie 3) EPP destroys the cookie on the server side. That way, clients could contact any EPP server in you pool, and get = service by showing a valid session cookie. Francisco >=20 >=20 > -- >=20 > JG >=20 >=20 >=20 > James Gould > Principal Software Engineer > jgould@verisign.com >=20 > 703-948-3271 (Office) > 12061 Bluemont Way > Reston, VA 20190 > VerisignInc.com >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On 4/23/12 1:05 PM, "Francisco Obispo" wrote: >=20 >>=20 >> You could initiate a session with a RESTful server, just like most >> websites work: >>=20 >> - You will use a RESTful URL to create a session: /session/user_id = [POST] >>=20 >> - The server would return a cookie, which you will return with every >> RESTful request. >>=20 >> - When you're done processing requests you can: /session/user_id = [DELETE] >>=20 >> The advantage of this model, is that you can use the existing = knowledge >> on how to scale web-services and apply them to Registry-Registrar >> interactions. >>=20 >> Francisco >>=20 >>=20 >>=20 >>=20 >> On Apr 23, 2012, at 9:26 AM, Gould, James wrote: >>=20 >>> Passing the user credentials to authenticate the user on a per >>> command basis will also add a lot of extra overhead. Can someone >>> describe >>> how these elements will be mitigated in a stateless model? Overall, = I >>> don=A9=F6t see how moving from stateful to stateless will benefit = either the >>> client or the server from a performance or load perspective. >>=20 >> Francisco Obispo=20 >> email: fobispo@isc.org >> Phone: +1 650 423 1374 || INOC-DBA *3557* NOC >> PGP KeyID =3D B38DB1BE >>=20 >=20 Francisco Obispo=20 email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From miekg@atoom.net Mon Apr 23 11:52:31 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F4721F8633 for ; Mon, 23 Apr 2012 11:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2Ms1Nqh2122 for ; Mon, 23 Apr 2012 11:52:30 -0700 (PDT) Received: from elektron.atoom.net (elektron.atoom.net [85.223.71.124]) by ietfa.amsl.com (Postfix) with ESMTP id B3DFB21F8629 for ; Mon, 23 Apr 2012 11:52:30 -0700 (PDT) Received: by elektron.atoom.net (Postfix, from userid 1000) id 8E75D3FF2B; Mon, 23 Apr 2012 20:52:27 +0200 (CEST) Date: Mon, 23 Apr 2012 20:52:27 +0200 From: Miek Gieben To: provreg@ietf.org, "regops@nlnetlabs.nl" Message-ID: <20120423185227.GC6285@miek.nl> Mail-Followup-To: provreg@ietf.org, "regops@nlnetlabs.nl" References: <02ACAD0F-4AED-408A-A08F-C37F2B12B442@isc.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Clx92ZfkiYIKRjnr" Content-Disposition: inline In-Reply-To: <02ACAD0F-4AED-408A-A08F-C37F2B12B442@isc.org> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Subject: Re: [provreg] [Regops] draft-wullink-restful-epp-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 18:52:31 -0000 --Clx92ZfkiYIKRjnr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ Quoting in "Re: [provreg] [Regops] draft-wulli..." ] > > So your proposal is to make it stateful based on the HTTP session? This >=20 > Yes, you can keep HTTP-session information in a shared way across multiple > servers (memcached, SQL-db, etc). so you can have any front-end server > vailidate it. > > Clients can keep the connection (or session) alive by issuing commands > periodically. Interesting twist :) Reading the other comments, I get the feeling that: Yes, EPP over REST is an interesting idea, but we overcame all (alleged) shortcomings of EPP by implementing sophisticated load balancing techniques. To us EPP over REST is a simplification over EPP and makes stuff possible= =20 without resorting to load balancers. Also EPP over REST is relatively easy to implement as HTTP/REST module exist for numerous languages. Kind regards, Miek Gieben --Clx92ZfkiYIKRjnr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk+VpOsACgkQJYuFzziA0PaO9gCgogcJ7PXauVpAOnyajuvxEImQ AiAAoKi7rmCPLXGfRRMrHJVqIJ3Sfcph =GNJv -----END PGP SIGNATURE----- --Clx92ZfkiYIKRjnr-- From Marco.Davids@sidn.nl Mon Apr 23 12:07:47 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873B521E8027 for ; Mon, 23 Apr 2012 12:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpGBLtfvGaX8 for ; Mon, 23 Apr 2012 12:07:47 -0700 (PDT) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by ietfa.amsl.com (Postfix) with ESMTP id AA9D221F8551 for ; Mon, 23 Apr 2012 12:07:46 -0700 (PDT) Received: from kahubcas1.SIDN.local ([192.168.2.41]) by ede1-kamx.sidn.nl with ESMTP id q3NJ7jaL005295 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Mon, 23 Apr 2012 21:07:45 +0200 Received: from lt01-010.sidn.local (192.168.4.166) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 23 Apr 2012 21:07:46 +0200 Message-ID: <4F95A87E.9080809@sidn.nl> Date: Mon, 23 Apr 2012 21:07:42 +0200 From: "Marco Davids (SIDN)" Organization: SIDN User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: References: In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [192.168.4.166] Subject: Re: [provreg] [Regops] draft-wullink-restful-epp-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 19:07:47 -0000 Op 23-04-12 18:26, Gould, James schreef: > Load balancing the connections distributes the load fine today. Sure, but what happens with an existing EPP-session when one of the application servers suddenly becomes unavailable? > If there is a need to load balance on a per command basis, > you can keep the state in the gateways Yes, but that implies more complexity on the gateways/loadbalancers. Besides that, we noticed there are quite a lot of registrars using a 'login-command-logout' sequence for every request they wish to make. That is, in our view, less efficient than simply issuing one RESTful request each time. > 2. EPP sessions can wind up in a state where they are no longer linked to > an active TCP session - Can someone describe this issue? We've encountered a number of scenario's where clients ran into their session limits unexpectedly. I remember one case where the client forgot to send a , but that is off course their problem. There are also scenario's where a flaky TCP connection or buggy client messes things up. Every so often this results in questions to our supportdesk. -- Marco From maarten.wullink@sidn.nl Mon Apr 23 12:25:19 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECF721F85D8 for ; Mon, 23 Apr 2012 12:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efDYtRqvFqfL for ; Mon, 23 Apr 2012 12:25:18 -0700 (PDT) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by ietfa.amsl.com (Postfix) with ESMTP id F412621F853D for ; Mon, 23 Apr 2012 12:25:17 -0700 (PDT) Received: from kahubcas1.SIDN.local ([192.168.2.41]) by ede1-kamx.sidn.nl with ESMTP id q3NJPGS3005694 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=CAFAIL); Mon, 23 Apr 2012 21:25:16 +0200 Received: from KAHUBCASN02.SIDN.local (192.168.2.74) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 23 Apr 2012 21:25:17 +0200 Received: from KAMBX2.SIDN.local ([fe80::b1fd:88d9:e136:9655]) by kahubcasn02.SIDN.local ([::1]) with mapi id 14.02.0247.003; Mon, 23 Apr 2012 21:25:17 +0200 From: Maarten Wullink To: "regops@nlnetlabs.nl" , "provreg@ietf.org" Thread-Topic: [Regops] [provreg] draft-wullink-restful-epp-00.txt Thread-Index: AQHNIT8dLqpQz+y2a0etm9Ue9plxXZaoOSGAgAA0e3D///SPAIAAFWOAgABRJ6w= Date: Mon, 23 Apr 2012 19:25:16 +0000 Message-ID: References: , In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.4.135] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [provreg] [Regops] draft-wullink-restful-epp-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 19:25:19 -0000 Using HTTP as an additional protocol does add more overhead. requiring the= =0A= use of SSL adds even more overhead. I am not quite sure how to mittegate th= is.=0A= =0A= However, using HTTP/REST does allow for a more efficient transport of reque= st and=0A= response data. For some requests there is no need for a request XML message= because the=0A= resource URL combined with an HTTP method is sufficient. The same goes for = some=0A= response messages. e.g. for the object check response, returning a couple o= f http headers=0A= instead of a complete EPP xml message makes it more efficient.=0A= =0A= The client and the server have to spend much less time creating, validing, = marshalling etc of XML messages.=0A= Maybe this will mittegate some of the added overhead, we have not done any = measurements but i am=0A= interested in such results. =0A= =0A= =0A= =0A= ________________________________________=0A= Van: Gould, James [JGould@verisign.com]=0A= Verzonden: maandag 23 april 2012 18:26=0A= To: Rubens Kuhl; Maarten Wullink=0A= Cc: regops@nlnetlabs.nl; provreg@ietf.org=0A= Onderwerp: Re: [Regops] [provreg] draft-wullink-restful-epp-00.txt=0A= =0A= In reading the messages it looks like the two issues with the stateful TCP= =0A= session raised include:=0A= =0A= 1. EPP may pose challenges in load-balanced environments - What has been=0A= raised is load-balancing on a per-command basis instead of a=0A= per-connection basis. Load balancing the connections distributes the load= =0A= fine today. If there is a need to load balance on a per command basis,=0A= you can keep the state in the gateways and load balance the requests to a= =0A= tier of stateless application servers. The same thing can be done on a=0A= per command type basis, by having the gateways send the commands to the=0A= different set of backend application servers. The gateways are typically= =0A= the least utilized in this scheme, so spreading the load on them doesn't=0A= really solve any problems. A case was made that stateless would improve=0A= performance, but I believe it will greatly decrease the performance. I'm= =0A= assuming that the security elements still apply (2-way SSL as well as=0A= authentication) which would need to be done on a per-command basis in the= =0A= stateless model. Creating of the 2-way SSL connection even with SSL=0A= session resumption will add a lot of extra overhead on a per command=0A= basis. Passing the user credentials to authenticate the user on a per=0A= command basis will also add a lot of extra overhead. Can someone describe= =0A= how these elements will be mitigated in a stateless model? Overall, I=0A= don=B9t see how moving from stateful to stateless will benefit either the= =0A= client or the server from a performance or load perspective.=0A= 2. EPP sessions can wind up in a state where they are no longer linked to= =0A= an active TCP session - Can someone describe this issue?=0A= =0A= =0A= --=0A= =0A= JG=0A= =0A= =0A= =0A= James Gould=0A= Principal Software Engineer=0A= jgould@verisign.com=0A= =0A= 703-948-3271 (Office)=0A= 12061 Bluemont Way=0A= Reston, VA 20190=0A= VerisignInc.com=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= On 4/23/12 11:09 AM, "Rubens Kuhl" wrote:=0A= =0A= >=0A= >Stateless requests also allow for having different pools of servers for=0A= >different types of requests. For instance, mapping "domain info" to=0A= >servers on a read-only database and "domain create" to servers with write= =0A= >access to the database. Can improve performance, security, or both.=0A= >=0A= >=0A= >Rubens=0A= >=0A= >=0A= >On Apr 23, 2012, at 11:02 AM, Maarten Wullink wrote:=0A= >=0A= >> Stateless EPP makes it possible to load balance individual EPP requests= =0A= >>instead of=0A= >> EPP connections. This should make it easier to distribute to load=0A= >>evenly across the servers.=0A= >> Distributing tcp connections across EPP servers does not guarantee an=0A= >>equal load on every server. This=0A= >> is because not all EPP connections are equal.=0A= >>=0A= >> Also when there is no persistent tcp connection it should be easier to= =0A= >>remove=0A= >> a server from the server pool for maintenance without having to=0A= >>disconnect the tcp connections of the=0A= >> clients connected to the server.=0A= >>=0A= >> -----Original Message-----=0A= >> From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On=0A= >>Behalf Of Gould, James=0A= >> Sent: maandag 23 april 2012 14:43=0A= >> To: Miek Gieben; provreg@ietf.org=0A= >> Cc: regops@nlnetlabs.nl=0A= >> Subject: Re: [provreg] draft-wullink-restful-epp-00.txt=0A= >>=0A= >> This is the first time that I've heard of challenges in load-balanced=0A= >> environments or EPP session state not being linked to an active TCP=0A= >> session. Can you go into more detail of these issues? I've been=0A= >>involved=0A= >> with many EPP-based systems through the years and I've never come across= =0A= >> any of these issues. This goes to the heart of the reliability of=0A= >> stateful TCP sessions, which is used with many other protocols. It=0A= >>would=0A= >> be good to discuss the problems posed prior to consideration of a new=0A= >> stateless version of EPP on top of REST.=0A= >>=0A= >> --=0A= >>=0A= >> JG=0A= >>=0A= >>=0A= >>=0A= >> James Gould=0A= >> Principal Software Engineer=0A= >> jgould@verisign.com=0A= >>=0A= >> 703-948-3271 (Office)=0A= >> 12061 Bluemont Way=0A= >> Reston, VA 20190=0A= >> VerisignInc.com=0A= >>=0A= >>=0A= >>=0A= >>=0A= >>=0A= >>=0A= >>=0A= >> On 4/23/12 6:51 AM, "Miek Gieben" wrote:=0A= >>=0A= >>> Hello,=0A= >>>=0A= >>> [I've cross posted this also to regops@nlnetlabs.nl]=0A= >>>=0A= >>> SIDN, being the registry for .nl, employs EPP as the primary interface= =0A= >>>for=0A= >>> registrars to submit or manipulate domain names. Even though the=0A= >>>protocol=0A= >>> is=0A= >>> working quite well, at SIDN Labs we believed there was room for=0A= >>> improvement.=0A= >>>=0A= >>> Experience over the years revealed certain operational shortcomings in= =0A= >>> EPP,=0A= >>> mainly related to the stateful nature of the protocol:=0A= >>>=0A= >>> * EPP may pose challenges in load-balanced environments, when a active= =0A= >>> session=0A= >>> has to be switched from one EPP server to another and state is kept on= =0A= >>> a per=0A= >>> server basis.=0A= >>>=0A= >>> * EPP sessions can wind up in a state where they are no longer linked= =0A= >>>to=0A= >>> an=0A= >>> active TCP connection. This may raise problems in situations where=0A= >>> session=0A= >>> limits are enforced.=0A= >>>=0A= >>> Our draft http://www.ietf.org/id/draft-wullink-restful-epp-00.txt=0A= >>> aims to solve these issues, by proposing a RESTful EPP interface.=0A= >>>=0A= >>> The Abstract reads:=0A= >>>=0A= >>> This document specifies a 'RESTful interface for EPP' (REPP) with= =0A= >>> the=0A= >>> aim to improve efficiency and interoperability of EPP systems.=0A= >>>=0A= >>>=0A= >>> This document includes a new EPP Protocol Extension as well as a= =0A= >>> mapping=0A= >>> of [RFC5730] XML-commands to an HTTP based (RESTful) interface.=0A= >>> Existing=0A= >>> semantics and mappings as defined in [RFC5731], [RFC5732] and=0A= >>> [RFC5733]=0A= >>> are largely retained and reusable in RESTful EPP.=0A= >>>=0A= >>>=0A= >>> With REPP, no session is created on the EPP server. Each request= =0A= >>> from=0A= >>> client to server will contain all of the information necessary to= =0A= >>>=0A= >>> understand the request. The server will close the connection after= =0A= >>> each=0A= >>> HTTP request.=0A= >>>=0A= >>>=0A= >>> As the provreg WG is dormant, we have submitted our draft as an=0A= >>>individual=0A= >>> submission.=0A= >>>=0A= >>> Since the provreg mailinglist is still very much alive, we are kindly= =0A= >>> requesting=0A= >>> its subscribers to provide us with feedback on our proposal.=0A= >>>=0A= >>> Kind regards,=0A= >>>=0A= >>> --=0A= >>>=0A= >>> Miek Gieben=0A= >>> SIDN Labs=0A= >>> _______________________________________________=0A= >>> provreg mailing list=0A= >>> provreg@ietf.org=0A= >>> https://www.ietf.org/mailman/listinfo/provreg=0A= >>=0A= >> _______________________________________________=0A= >> provreg mailing list=0A= >> provreg@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/provreg=0A= >>=0A= >> _______________________________________________=0A= >> regops mailing list=0A= >> regops@nlnetlabs.nl=0A= >> http://nlnetlabs.nl/mailman/listinfo/regops=0A= >=0A= >=0A= >_______________________________________________=0A= >regops mailing list=0A= >regops@nlnetlabs.nl=0A= >http://nlnetlabs.nl/mailman/listinfo/regops=0A= =0A= From JGould@verisign.com Mon Apr 23 14:47:08 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0A721E8028 for ; Mon, 23 Apr 2012 14:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.307 X-Spam-Level: X-Spam-Status: No, score=-6.307 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8z4e8XBclMCb for ; Mon, 23 Apr 2012 14:47:07 -0700 (PDT) Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) by ietfa.amsl.com (Postfix) with ESMTP id C579F21E800F for ; Mon, 23 Apr 2012 14:47:06 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKT5XN2Ez1jxVfUy8l4KdMeT/PsBU34Teq@postini.com; Mon, 23 Apr 2012 14:47:06 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q3NLkxSx005479; Mon, 23 Apr 2012 17:47:03 -0400 Received: from BRN1WNEXCAS01.vcorp.ad.vrsn.com ([10.173.152.205]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Apr 2012 17:46:52 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Mon, 23 Apr 2012 17:46:41 -0400 From: "Gould, James" To: "Marco Davids (SIDN)" , "provreg@ietf.org" Thread-Topic: [provreg] [Regops] draft-wullink-restful-epp-00.txt Thread-Index: AQHNIYRcj6cH+lcq+UWWJmmkaV/ZaZao8hCA Date: Mon, 23 Apr 2012 21:46:47 +0000 Message-ID: In-Reply-To: <4F95A87E.9080809@sidn.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Apr 2012 21:46:52.0869 (UTC) FILETIME=[985F8750:01CD219A] Subject: Re: [provreg] [Regops] draft-wullink-restful-epp-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 21:47:08 -0000 > Sure, but what happens with an existing EPP-session when one of the > application servers suddenly becomes unavailable? It depends where the state is held (gateway or application server). If the application server is stateless, than nothing happens to the EPP session. If the application server is stateful, then hopefully the gateway will recognize the dropped application server connection and will in turn close the client connection. > Yes, but that implies more complexity on the gateways/loadbalancers. Load balancing behind the gateways is just one option, but you are correct that it adds complexity. > Besides that, we noticed there are quite a lot of registrars using a > 'login-command-logout' sequence for every request they wish to make. > That is, in our view, less efficient than simply issuing one RESTful > request each time. We see this as well, but there are another set of registrars that keep long running EPP sessions that get the benefit of stateful sessions. A best practice is to keep a pool of long running sessions for the best performance. =20 > We've encountered a number of scenario's where clients ran into their > session limits unexpectedly. I remember one case where the client forgot > to send a , but that is off course their problem. There are also > scenario's where a flaky TCP connection or buggy client messes things > up. Every so often this results in questions to our supportdesk. You're going to most likely have some sort of server policy on load (connections, bandwidth) in either event that can result in troubleshooting and questions to customer support. I'm not sure if stateless versus stateful will help reduce the server policies and subsequently the troubleshooting. -- =20 JG =20 =20 James Gould Principal Software Engineer jgould@verisign.com =20 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On 4/23/12 3:07 PM, "Marco Davids (SIDN)" wrote: >Op 23-04-12 18:26, Gould, James schreef: > >> Load balancing the connections distributes the load fine today. > >Sure, but what happens with an existing EPP-session when one of the >application servers suddenly becomes unavailable? > >> If there is a need to load balance on a per command basis, >> you can keep the state in the gateways > >Yes, but that implies more complexity on the gateways/loadbalancers. > >Besides that, we noticed there are quite a lot of registrars using a >'login-command-logout' sequence for every request they wish to make. >That is, in our view, less efficient than simply issuing one RESTful >request each time. > >> 2. EPP sessions can wind up in a state where they are no longer linked >>to >> an active TCP session - Can someone describe this issue? > >We've encountered a number of scenario's where clients ran into their >session limits unexpectedly. I remember one case where the client forgot >to send a , but that is off course their problem. There are also >scenario's where a flaky TCP connection or buggy client messes things >up. Every so often this results in questions to our supportdesk. > >-- >Marco >_______________________________________________ >provreg mailing list >provreg@ietf.org >https://www.ietf.org/mailman/listinfo/provreg From lem@isc.org Mon Apr 23 14:47:56 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96AAC21E8028 for ; Mon, 23 Apr 2012 14:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.176 X-Spam-Level: X-Spam-Status: No, score=-2.176 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDWjnagoBK+p for ; Mon, 23 Apr 2012 14:47:56 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 2973021E800F for ; Mon, 23 Apr 2012 14:47:56 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 45FD5C94A8; Mon, 23 Apr 2012 21:47:47 +0000 (UTC) (envelope-from lem@isc.org) Received: from macbookprolem.lem (z65-50-116-115.ips.direcpath.com [65.50.116.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 886DF216C31; Mon, 23 Apr 2012 21:47:45 +0000 (UTC) (envelope-from lem@isc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=euc-kr From: =?iso-8859-1?Q?Luis_Mu=F1oz?= In-Reply-To: Date: Mon, 23 Apr 2012 17:47:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <095F4F9C-C200-4644-9FE7-6E98A45CCA63@isc.org> References: To: "Gould, James" X-Mailer: Apple Mail (2.1257) Cc: "regops@nlnetlabs.nl" , Rubens Kuhl , "provreg@ietf.org" Subject: Re: [provreg] [Regops] draft-wullink-restful-epp-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 21:47:56 -0000 On Apr 23, 2012, at 1:57 PM, Gould, James wrote: > There is still > the connection establishment overhead (2-way SSL) that will decrease = the > performance. I don't think there's a way to completely get rid of this. A new TCP = session will need to be created (or existing connections from a pool = could be multiplexed). Still this proposal could be a big win in performance. -lem From JGould@verisign.com Mon Apr 23 15:22:25 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C68C21E8051 for ; Mon, 23 Apr 2012 15:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.23 X-Spam-Level: X-Spam-Status: No, score=-6.23 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlPtjgu1BJ+k for ; Mon, 23 Apr 2012 15:22:24 -0700 (PDT) Received: from exprod6og109.obsmtp.com (exprod6og109.obsmtp.com [64.18.1.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8846121E804E for ; Mon, 23 Apr 2012 15:22:20 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKT5XWGNqqugpPpn6DZTurigd9L8xeS7n/@postini.com; Mon, 23 Apr 2012 15:22:23 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q3NMM88U006294; Mon, 23 Apr 2012 18:22:08 -0400 Received: from BRN1WNEXCAS02.vcorp.ad.vrsn.com ([10.173.152.206]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Apr 2012 18:22:01 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Mon, 23 Apr 2012 18:21:51 -0400 From: "Gould, James" To: =?iso-8859-1?Q?Luis_Mu=F1oz?= Thread-Topic: [provreg] [Regops] draft-wullink-restful-epp-00.txt Thread-Index: AQHNIXNW/QMJrKFNaU6fmilPP1Ol95aoskeAgACDTgD//8ZwgA== Date: Mon, 23 Apr 2012 22:21:56 +0000 Message-ID: In-Reply-To: <095F4F9C-C200-4644-9FE7-6E98A45CCA63@isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Apr 2012 22:22:01.0932 (UTC) FILETIME=[817900C0:01CD219F] Cc: "regops@nlnetlabs.nl" , Rubens Kuhl , "provreg@ietf.org" Subject: Re: [provreg] [Regops] draft-wullink-restful-epp-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 22:22:25 -0000 What is the basis of the claim that the proposal could be a big win in performance? What is the fundamental performance issues today with EPP TCP and how does REST over HTTP solve it? I heard that stateless will provide benefits, but with SSL and authentication the approach needs to move to a stateful (RESTful login and HTTP keep-alive) model. I heard that there can be load balancing done per command instead of per connection, but per command load balancing can be accomplished today behind the gateways and there is a question of whether the gateway tier itself is a problem area from a performance and scalability perspective. I heard that existing knowledge to scale web-services can be utilized, but the registries already have knowledge on scaling EPP services. I don't see performance and scalability as a key driver for a new provisioning protocol. Is there another driver for this proposal? =20 -- =20 JG =20 =20 James Gould Principal Software Engineer jgould@verisign.com =20 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On 4/23/12 5:47 PM, "Luis Mu=F1oz" wrote: > >On Apr 23, 2012, at 1:57 PM, Gould, James wrote: > >> There is still >> the connection establishment overhead (2-way SSL) that will decrease the >> performance. > >I don't think there's a way to completely get rid of this. A new TCP >session will need to be created (or existing connections from a pool >could be multiplexed). > >Still this proposal could be a big win in performance. > >-lem > From lem@isc.org Mon Apr 23 15:30:18 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 177AA21E804E for ; Mon, 23 Apr 2012 15:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qW3iWbuTgpk for ; Mon, 23 Apr 2012 15:30:17 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 238CE21E8048 for ; Mon, 23 Apr 2012 15:30:17 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 1387F5F9908; Mon, 23 Apr 2012 22:29:57 +0000 (UTC) (envelope-from lem@isc.org) Received: from [21.59.120.187] (mda5536d0.tmodns.net [208.54.85.218]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id F2789216C31; Mon, 23 Apr 2012 22:29:53 +0000 (UTC) (envelope-from lem@isc.org) References: User-Agent: K-9 Mail for Android In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: =?ISO-8859-1?Q?Luis_Mu=F1oz?= Date: Mon, 23 Apr 2012 18:29:39 -0400 To: "Gould, James" Message-ID: <972d8093-d34d-4c79-948e-318ba3c7c6f8@email.android.com> Cc: "regops@nlnetlabs.nl" , Rubens Kuhl , "provreg@ietf.org" Subject: Re: [provreg] [Regops] draft-wullink-restful-epp-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 22:30:18 -0000 The fact that you can more efficiently pool connections will in many scenarios allow you to get away with less connections that are more long lived and potentially, with less authentications. Per command load balancing also removes the need to have gateways rerouting the requests. This function now is easier to "flatten" into the frontend. Of course I suppose mileage will carry. -lem "Gould, James" wrote: >What is the basis of the claim that the proposal could be a big win in >performance? What is the fundamental performance issues today with EPP >TCP and how does REST over HTTP solve it? I heard that stateless will >provide benefits, but with SSL and authentication the approach needs to >move to a stateful (RESTful login and HTTP keep-alive) model. I heard >that there can be load balancing done per command instead of per >connection, but per command load balancing can be accomplished today >behind the gateways and there is a question of whether the gateway tier >itself is a problem area from a performance and scalability >perspective. >I heard that existing knowledge to scale web-services can be utilized, >but >the registries already have knowledge on scaling EPP services. I don't >see performance and scalability as a key driver for a new provisioning >protocol. Is there another driver for this proposal? > >-- > >JG > > > >James Gould >Principal Software Engineer >jgould@verisign.com > >703-948-3271 (Office) >12061 Bluemont Way >Reston, VA 20190 >VerisignInc.com > > > > > > > >On 4/23/12 5:47 PM, "Luis Muñoz" wrote: > >> >>On Apr 23, 2012, at 1:57 PM, Gould, James wrote: >> >>> There is still >>> the connection establishment overhead (2-way SSL) that will decrease >the >>> performance. >> >>I don't think there's a way to completely get rid of this. A new TCP >>session will need to be created (or existing connections from a pool >>could be multiplexed). >> >>Still this proposal could be a big win in performance. >> >>-lem >> From zhoulinlin@cnnic.cn Tue Apr 24 01:25:11 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E4221F86E3 for ; Tue, 24 Apr 2012 01:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[AWL=3.208, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0O1iEl7vHpsS for ; Tue, 24 Apr 2012 01:25:10 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 5705D21F86EA for ; Tue, 24 Apr 2012 01:25:09 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: zhoulinlin@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo95e6383c) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 24 Apr 2012 16:25:07 +0800 From: "Linlin Zhou" To: "'Francisco Obispo'" , "'Gould, James'" References: In-Reply-To: Date: Tue, 24 Apr 2012 16:25:08 +0800 Message-ID: <000301cd21f3$c2759df0$4760d9d0$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0hc1qvaPqYKC+xRB2oy3AO5GDWaAAbbVew Content-Language: zh-cn Cc: regops@nlnetlabs.nl, 'Rubens Kuhl' , provreg@ietf.org Subject: Re: [provreg] [Regops] draft-wullink-restful-epp-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 08:25:11 -0000 You mean cookie based session?=20 Is the cookie stored on the client side or included in the http header = or url for every request? In the first case, if the cookie is disabled by the client, does it = still work? If the second case, things like header or url length limit, replay attack may cause problems. Or we can generate and manage the authentication information by = ourselves, so creating sessions is not necessary. Linlin Zhou CNNIC > -----Original Message----- > From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On = Behalf > Of Francisco Obispo > Sent: Tuesday, April 24, 2012 1:06 AM > To: Gould, James > Cc: regops@nlnetlabs.nl; provreg@ietf.org; Rubens Kuhl > Subject: Re: [provreg] [Regops] draft-wullink-restful-epp-00.txt >=20 >=20 > You could initiate a session with a RESTful server, just like most websites work: >=20 > - You will use a RESTful URL to create a session: /session/user_id = [POST] >=20 > - The server would return a cookie, which you will return with every RESTful > request. >=20 > - When you're done processing requests you can: /session/user_id = [DELETE] >=20 > The advantage of this model, is that you can use the existing = knowledge on how > to scale web-services and apply them to Registry-Registrar = interactions. >=20 > Francisco >=20 >=20 >=20 >=20 > On Apr 23, 2012, at 9:26 AM, Gould, James wrote: >=20 > > Passing the user credentials to authenticate the user on a per = command > > basis will also add a lot of extra overhead. Can someone describe = how > > these elements will be mitigated in a stateless model? Overall, I > > don=B9t see how moving from stateful to stateless will benefit = either > > the client or the server from a performance or load perspective. >=20 > Francisco Obispo > email: fobispo@isc.org > Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE >=20 > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg From Klaus.Malorny@knipp.de Tue Apr 24 01:31:17 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F267521F8639 for ; Tue, 24 Apr 2012 01:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zQSGwznRM+s for ; Tue, 24 Apr 2012 01:31:16 -0700 (PDT) Received: from kmx10a.knipp.de (clust3a-eth0-0.bbone.knipp.de [195.253.6.83]) by ietfa.amsl.com (Postfix) with ESMTP id 64E7021F86A7 for ; Tue, 24 Apr 2012 01:31:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 1EA3191; Tue, 24 Apr 2012 10:31:15 +0200 (MESZ) X-Knipp-VirusScanned: Yes Received: from kmx10a.knipp.de ([127.0.0.1]) by localhost (kmx10a.knipp.de [127.0.0.1]) (amavisd-new, port 10004) with ESMTP id KjFwTtU-UoIc; Tue, 24 Apr 2012 10:31:09 +0200 (MESZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 524C490; Tue, 24 Apr 2012 10:31:09 +0200 (MESZ) Received: from [195.253.2.27] (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id q3O8V9Kx019214; Tue, 24 Apr 2012 10:31:09 +0200 (MESZ) Message-ID: <4F9664CD.3090201@knipp.de> Date: Tue, 24 Apr 2012 10:31:09 +0200 From: Klaus Malorny User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120423 Thunderbird/14.0a1 MIME-Version: 1.0 To: "regops@nlnetlabs.nl" , "provreg@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [provreg] [Regops] draft-wullink-restful-epp-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 08:31:17 -0000 On 23/04/12 19:05, Francisco Obispo wrote: > > You could initiate a session with a RESTful server, just like most websites > work: > > - You will use a RESTful URL to create a session: /session/user_id [POST] > > - The server would return a cookie, which you will return with every RESTful > request. > > - When you're done processing requests you can: /session/user_id [DELETE] > > The advantage of this model, is that you can use the existing knowledge on > how to scale web-services and apply them to Registry-Registrar interactions. > > Francisco > > Hi, if you are using cookies, so why use REST at all? AFAIK, multiple ccTLDs use proprietary implementations of EPP over HTTP(S). These use more or less POST requests to a static URL, containing the command as the POST data and the response in the HTTP response body (hello/greeting, login and logout accordingly). Session state is maintained by cookies. It does not require any changes to the base protocols (RFCs 5730-5733) and also avoids my personal disfavoured REST concepts of giving up the self-containedness of the payload and using different payload formats for requests and responses (which occur to the lesser extent in the proposed standard). So IMHO it would be better to focus on the standardization of the existing flavours if there is a demand of an HTTP-based transport layer. Klaus From maarten.wullink@sidn.nl Tue Apr 24 02:42:26 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42DC521F8770 for ; Tue, 24 Apr 2012 02:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKHz4hzF6N7P for ; Tue, 24 Apr 2012 02:42:25 -0700 (PDT) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by ietfa.amsl.com (Postfix) with ESMTP id D6A2621F8769 for ; Tue, 24 Apr 2012 02:42:24 -0700 (PDT) Received: from kahubcas1.SIDN.local ([192.168.2.41]) by ede1-kamx.sidn.nl with ESMTP id q3O9gNdl020757 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=CAFAIL); Tue, 24 Apr 2012 11:42:23 +0200 Received: from KAMBX2.SIDN.local ([fe80::b1fd:88d9:e136:9655]) by kahubcas1.SIDN.local ([fe80::dff:8232:1563:3a16%14]) with mapi id 14.02.0247.003; Tue, 24 Apr 2012 11:42:24 +0200 From: Maarten Wullink To: "'Klaus Malorny'" , "regops@nlnetlabs.nl" , "provreg@ietf.org" Thread-Topic: [provreg] [Regops] draft-wullink-restful-epp-00.txt Thread-Index: AQHNIXNb2z6BIRm50UGy7RUUa8abNZaphMSAgAAvwSA= Date: Tue, 24 Apr 2012 09:42:24 +0000 Message-ID: References: <4F9664CD.3090201@knipp.de> In-Reply-To: <4F9664CD.3090201@knipp.de> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.92] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [provreg] [Regops] draft-wullink-restful-epp-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 09:42:26 -0000 Using a static URL and the http POST method to submit EPP XML messages will= work fine. But I think using REST will help in creating an easier to use EPP API. As mentioned before, when using REST the EPP request message is optional fo= r commands like check, delete and info. These will (in most cases) no longer = require a request EPP message. The URL and HTTP method provide all the required information to perform the= request. (the authentication info can be transmitted with Authorization: Basic heade= r) "multiple ccTLDs use proprietary implementations of EPP over HTTP(S)." I am interested to know which ccTLDs have such a implementation and what th= eir experiences are. Example domain name info: Rest style GET /domains/example.com VS plain http POST POST /command [postdata =3D epp xml domain name info request] Personally I like the REST style more, no need for XML request message and = informational URL. -----Original Message----- From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On Behalf = Of Klaus Malorny Sent: dinsdag 24 april 2012 10:31 To: regops@nlnetlabs.nl; provreg@ietf.org Subject: Re: [provreg] [Regops] draft-wullink-restful-epp-00.txt On 23/04/12 19:05, Francisco Obispo wrote: > > You could initiate a session with a RESTful server, just like most websit= es > work: > > - You will use a RESTful URL to create a session: /session/user_id [POST] > > - The server would return a cookie, which you will return with every REST= ful > request. > > - When you're done processing requests you can: /session/user_id [DELETE] > > The advantage of this model, is that you can use the existing knowledge o= n > how to scale web-services and apply them to Registry-Registrar interactio= ns. > > Francisco > > Hi, if you are using cookies, so why use REST at all? AFAIK, multiple ccTLDs us= e=20 proprietary implementations of EPP over HTTP(S). These use more or less POS= T=20 requests to a static URL, containing the command as the POST data and the=20 response in the HTTP response body (hello/greeting, login and logout=20 accordingly). Session state is maintained by cookies. It does not require a= ny=20 changes to the base protocols (RFCs 5730-5733) and also avoids my personal= =20 disfavoured REST concepts of giving up the self-containedness of the payloa= d and=20 using different payload formats for requests and responses (which occur to = the=20 lesser extent in the proposed standard). So IMHO it would be better to focu= s on=20 the standardization of the existing flavours if there is a demand of an=20 HTTP-based transport layer. Klaus _______________________________________________ provreg mailing list provreg@ietf.org https://www.ietf.org/mailman/listinfo/provreg From ajs@anvilwalrusden.com Tue Apr 24 04:12:27 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB4D21F871C for ; Tue, 24 Apr 2012 04:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.664 X-Spam-Level: X-Spam-Status: No, score=-2.664 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMx0-2JkvKGl for ; Tue, 24 Apr 2012 04:12:26 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 05EDA21F86C5 for ; Tue, 24 Apr 2012 04:12:25 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 1BD951ECB41C; Tue, 24 Apr 2012 11:12:17 +0000 (UTC) Date: Tue, 24 Apr 2012 07:12:15 -0400 From: Andrew Sullivan To: Maarten Wullink Message-ID: <20120424111206.GB55967@mail.yitter.info> References: <4F9664CD.3090201@knipp.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "regops@nlnetlabs.nl" , "provreg@ietf.org" Subject: Re: [provreg] [Regops] draft-wullink-restful-epp-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 11:12:27 -0000 On Tue, Apr 24, 2012 at 09:42:24AM +0000, Maarten Wullink wrote: > But I think using REST will help in creating an easier to use EPP API. To emphasise what Scott already pointed out, it's not going to create an "easier to use EPP API". It's going to create a new protocol, sort of like EPP. Normally, what we hear is how difficult it is to deal with the plethora of extensions -- the tiny differences in the various extensions make everything too hard for registries and registrars alike. (Given some servers' carelessness with their namespaces, actually, this isn't that surprising. The greeting turns out to be a crummy guide to the extensions actually on offer in many deployed implementations.) I'm finding it a little hard to believe that it will be easier to solve this problem by ditching EPP in favour of a completely new protocol with a new set of such challenges. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From shollenbeck@verisign.com Tue Apr 24 04:45:55 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F95B21F85FD for ; Tue, 24 Apr 2012 04:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YcpRcH1c8BNE for ; Tue, 24 Apr 2012 04:45:54 -0700 (PDT) Received: from exprod6og109.obsmtp.com (exprod6og109.obsmtp.com [64.18.1.23]) by ietfa.amsl.com (Postfix) with ESMTP id 86C0321F85DB for ; Tue, 24 Apr 2012 04:45:54 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKT5aSbZWIPflO2lp8G3unhCIQdYRZpPQ9@postini.com; Tue, 24 Apr 2012 04:45:54 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q3OBjjev000674; Tue, 24 Apr 2012 07:45:48 -0400 Received: from BRN1WNEXCAS02.vcorp.ad.vrsn.com ([10.173.152.206]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Apr 2012 07:45:37 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Tue, 24 Apr 2012 07:45:26 -0400 From: "Hollenbeck, Scott" To: Alexander Mayrhofer , "provreg@ietf.org" Thread-Topic: [provreg] ICANN TMCH draft specifications available - EPP extensions? Thread-Index: Ac0cgZ2yqkk7vC0QR2GxoVWkIWjphAFjYJSQ Date: Tue, 24 Apr 2012 11:45:33 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D5F25EA@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <19F54F2956911544A32543B8A9BDE075031012@NICS-EXCH.sbg.nic.at> In-Reply-To: <19F54F2956911544A32543B8A9BDE075031012@NICS-EXCH.sbg.nic.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 24 Apr 2012 11:45:37.0744 (UTC) FILETIME=[C4560D00:01CD220F] Subject: Re: [provreg] ICANN TMCH draft specifications available - EPP extensions? X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 11:45:55 -0000 > -----Original Message----- > From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On > Behalf Of Alexander Mayrhofer > Sent: Tuesday, April 17, 2012 6:12 AM > To: provreg@ietf.org > Subject: [provreg] ICANN TMCH draft specifications available - EPP > extensions? >=20 > The current version of ICANN's trademark clearinghouse specifications > was published on April 13th. Looking through that document, i noticed > that it requires a certain set of EPP extensions in order to transmit > trademark claims/registration related data over EPP. >=20 > Since the implementation of the TMCH is required for all operators of a > new gTLD, i was wondering whether there is already work going on > regarding specification of those EPP extensions? It would certainly not > make much sense if every backend operator of a new gTLD invents their > own schema/extension in order to support those required new data fields > (registrars will certainly not appreciate those multiple extensions as > well..). >=20 > Therefore, if no work has yet been performed on the specification of > those extensions in an internet draft, i think it makes sense to bundle > forces among new gTLD backend operators in order to create such an > extension. (Apart from that, i would also appreciate informal tech > contacts to other emerging new gTLD backend operators, in order to > discuss other operational / technical issues around the EPP > implementation). Jim Gould and I are interested in working on a standard extension or extens= ions for Verisign, but I'm worried about the timing of the need for these s= pecs and ICANN's launch schedule. Coming to agreement on a standard approac= h in a short amount of time is going to be a challenge. Scott From JGould@verisign.com Tue Apr 24 05:45:51 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3E121F85D5 for ; Tue, 24 Apr 2012 05:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.394 X-Spam-Level: X-Spam-Status: No, score=-6.394 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8DvRDfKqlvp for ; Tue, 24 Apr 2012 05:45:50 -0700 (PDT) Received: from exprod6og113.obsmtp.com (exprod6og113.obsmtp.com [64.18.1.31]) by ietfa.amsl.com (Postfix) with ESMTP id 3860121F85CC for ; Tue, 24 Apr 2012 05:45:47 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob113.postini.com ([64.18.5.12]) with SMTP ID DSNKT5ageWMta2Bcj7437185FiRIJV62qe+J@postini.com; Tue, 24 Apr 2012 05:45:49 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q3OCjfsH031654; Tue, 24 Apr 2012 08:45:42 -0400 Received: from BRN1WNEXCAS02.vcorp.ad.vrsn.com ([10.173.152.206]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Apr 2012 08:45:34 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Tue, 24 Apr 2012 08:45:22 -0400 From: "Gould, James" To: Klaus Malorny , "regops@nlnetlabs.nl" , "provreg@ietf.org" Thread-Topic: [provreg] [Regops] draft-wullink-restful-epp-00.txt Thread-Index: AQHNIXNW/QMJrKFNaU6fmilPP1Ol95ap6VmAgAAD8gA= Date: Tue, 24 Apr 2012 12:45:30 +0000 Message-ID: In-Reply-To: <4F9664CD.3090201@knipp.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 24 Apr 2012 12:45:34.0416 (UTC) FILETIME=[241EA500:01CD2218] Subject: Re: [provreg] [Regops] draft-wullink-restful-epp-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 12:45:51 -0000 Our EPP HTTP transport included the following: 1. Client sends an HTTP GET 2. Server returns the EPP Greeting with session cookie in the header (JSESSIONID) 3. Client sends command with HTTP POST and the session cookie as an HTTP header 4. Server returns EPP Response This is done in a 2-way SSL connection similar to the EPP TCP transport and HTTP keep-alive was used to maintain the stateful connection. We stopped supporting the EPP HTTP transport. -- =20 JG =20 =20 James Gould Principal Software Engineer jgould@verisign.com =20 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On 4/24/12 4:31 AM, "Klaus Malorny" wrote: >On 23/04/12 19:05, Francisco Obispo wrote: >> >> You could initiate a session with a RESTful server, just like most >>websites >> work: >> >> - You will use a RESTful URL to create a session: /session/user_id >>[POST] >> >> - The server would return a cookie, which you will return with every >>RESTful >> request. >> >> - When you're done processing requests you can: /session/user_id >>[DELETE] >> >> The advantage of this model, is that you can use the existing knowledge >>on >> how to scale web-services and apply them to Registry-Registrar >>interactions. >> >> Francisco >> >> > >Hi, > >if you are using cookies, so why use REST at all? AFAIK, multiple ccTLDs >use=20 >proprietary implementations of EPP over HTTP(S). These use more or less >POST=20 >requests to a static URL, containing the command as the POST data and the >response in the HTTP response body (hello/greeting, login and logout >accordingly). Session state is maintained by cookies. It does not require >any=20 >changes to the base protocols (RFCs 5730-5733) and also avoids my >personal=20 >disfavoured REST concepts of giving up the self-containedness of the >payload and=20 >using different payload formats for requests and responses (which occur >to the=20 >lesser extent in the proposed standard). So IMHO it would be better to >focus on=20 >the standardization of the existing flavours if there is a demand of an >HTTP-based transport layer. > >Klaus >_______________________________________________ >provreg mailing list >provreg@ietf.org >https://www.ietf.org/mailman/listinfo/provreg From gberezow@afilias.info Tue Apr 24 06:42:34 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EAE121F8814 for ; Tue, 24 Apr 2012 06:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.642 X-Spam-Level: X-Spam-Status: No, score=-5.642 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0+ZOHdetuAk for ; Tue, 24 Apr 2012 06:42:33 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id 8D66C21F8812 for ; Tue, 24 Apr 2012 06:42:33 -0700 (PDT) Received: from ms5.yyz2.afilias-ops.info ([10.50.129.111] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1SMg0m-0002GQ-4m for provreg@ietf.org; Tue, 24 Apr 2012 13:42:32 +0000 Received: from mail-vb0-f50.google.com ([209.85.212.50]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1SMg0m-0005I4-45 for provreg@ietf.org; Tue, 24 Apr 2012 13:42:32 +0000 Received: by vbnl22 with SMTP id l22so558847vbn.9 for ; Tue, 24 Apr 2012 06:42:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=itNERa29WcrK+H0kf7ooAFvJkE41SF0ErCb2KT/rTtw=; b=WnOGreS+Xm1jyPFnjek5pR/NwLW4t3rG4jj7St7xiGzyRdyhdsd1yW1UfSYvuQqiNE ZjS2yeamb8aKyd/yZDtOIbCrcMW3qg2hCZFD5+LZFy17ewwQifEnjRFE5AaeVWgvEKxB 8tLjlM7f4zxP1TqJ/+c9L/dpG160l2F01twcVf9f6dg9kYWNmPAgcoBRb7OotzrRo62T J9dWMItnq0TCjz90C7zYU67MSaSalPlTfIoRnjdTtv+E4EPSO4qvtlZc1hGOo62gTR3g NoXYbMWfk04WK2Xn4sCYZQBgEKHetvnMBRn+Y3Plnw99AcoU/8mp5QF7otcItPCc/bBq QIzQ== Received: by 10.220.108.16 with SMTP id d16mr18760179vcp.51.1335274951672; Tue, 24 Apr 2012 06:42:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.88.206 with HTTP; Tue, 24 Apr 2012 06:42:11 -0700 (PDT) In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D5F25EA@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <19F54F2956911544A32543B8A9BDE075031012@NICS-EXCH.sbg.nic.at> <831693C2CDA2E849A7D7A712B24E257F0D5F25EA@BRN1WNEXMBX01.vcorp.ad.vrsn.com> From: Gregory Berezowsky Date: Tue, 24 Apr 2012 09:42:11 -0400 Message-ID: To: "Hollenbeck, Scott" Content-Type: multipart/alternative; boundary=f46d0438927d2c04a004be6ced0a X-Gm-Message-State: ALoCoQnHe5S8NLN9Qi2zPHPlUhqtYCN2UoTqnL8NMTlTc9HRLL5Lj0KB1buh+GP2RHFYRlpClnXv Cc: Alexander Mayrhofer , "provreg@ietf.org" Subject: Re: [provreg] ICANN TMCH draft specifications available - EPP extensions? X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 13:42:34 -0000 --f46d0438927d2c04a004be6ced0a Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 24, 2012 at 7:45 AM, Hollenbeck, Scott wrote: > > -----Original Message----- > > From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On > > Behalf Of Alexander Mayrhofer > > Sent: Tuesday, April 17, 2012 6:12 AM > > To: provreg@ietf.org > > Subject: [provreg] ICANN TMCH draft specifications available - EPP > > extensions? > > > > The current version of ICANN's trademark clearinghouse specifications > > was published on April 13th. Looking through that document, i noticed > > that it requires a certain set of EPP extensions in order to transmit > > trademark claims/registration related data over EPP. > > > > Since the implementation of the TMCH is required for all operators of a > > new gTLD, i was wondering whether there is already work going on > > regarding specification of those EPP extensions? It would certainly not > > make much sense if every backend operator of a new gTLD invents their > > own schema/extension in order to support those required new data fields > > (registrars will certainly not appreciate those multiple extensions as > > well..). > > > > Therefore, if no work has yet been performed on the specification of > > those extensions in an internet draft, i think it makes sense to bundle > > forces among new gTLD backend operators in order to create such an > > extension. (Apart from that, i would also appreciate informal tech > > contacts to other emerging new gTLD backend operators, in order to > > discuss other operational / technical issues around the EPP > > implementation). > > Jim Gould and I are interested in working on a standard extension or > extensions for Verisign, but I'm worried about the timing of the need for > these specs and ICANN's launch schedule. Coming to agreement on a standard > approach in a short amount of time is going to be a challenge. > I am also interested in participating on standardizing this. At Afilias, we have similar concerns on the timing. --f46d0438927d2c04a004be6ced0a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 24, 2012 = at 7:45 AM, Hollenbeck, Scott <shollenbeck@verisign.com> wrote:
> -----Original Message= -----
> From: provreg-bounces@ietf= .org [mailto:provreg-bounce= s@ietf.org] On
> Behalf Of Alexander Mayrhofer
> Sent: Tuesday, April 17, 2012 6:12 AM
> To: provreg@ietf.org
> Subject: [provreg] ICANN TMCH draft specifications available - EPP
> extensions?
>
> The current version of ICANN's trademark clearinghouse speci= fications
> was published on April 13th. Looking through that document, i noticed<= br> > that it requires a certain set of EPP extensions in order to transmit<= br> > trademark claims/registration related data over EPP.
>
> Since the implementation of the TMCH is required for all operators of = a
> new gTLD, i was wondering whether there is already work going on
> regarding specification of those EPP extensions? It would certainly no= t
> make much sense if every backend operator of a new gTLD invents their<= br> > own schema/extension in order to support those required new data field= s
> (registrars will certainly not appreciate those multiple extensions as=
> well..).
>
> Therefore, if no work has yet been performed on the specification of > those extensions in an internet draft, i think it makes sense to bundl= e
> forces among new gTLD backend operators in order to create such an
> extension. (Apart from that, i would also appreciate informal tech
> contacts to other emerging new gTLD backend operators, in order to
> discuss other operational / technical issues around the EPP
> implementation).

Jim Gould and I are interested in working on a standard extension or extens= ions for Verisign, but I'm worried about the timing of the need for the= se specs and ICANN's launch schedule. Coming to agreement on a standard= approach in a short amount of time is going to be a challenge.

I am also interested in participating on s= tandardizing this. At Afilias, we have similar concerns on the timing.

--f46d0438927d2c04a004be6ced0a-- From fobispo@isc.org Tue Apr 24 07:10:46 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4614A21F85C6 for ; Tue, 24 Apr 2012 07:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.668 X-Spam-Level: X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[AWL=-0.466, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6g89YRcbZ2Z for ; Tue, 24 Apr 2012 07:10:45 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 69C7221F8599 for ; Tue, 24 Apr 2012 07:10:45 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 1EF05C9574; Tue, 24 Apr 2012 14:10:27 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [192.168.255.104] (c-76-126-250-157.hsd1.ca.comcast.net [76.126.250.157]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 08939216C40; Tue, 24 Apr 2012 14:10:27 +0000 (UTC) (envelope-from fobispo@isc.org) References: <19F54F2956911544A32543B8A9BDE075031012@NICS-EXCH.sbg.nic.at> <831693C2CDA2E849A7D7A712B24E257F0D5F25EA@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-A081A4F7-179C-42FE-B011-95B8304EC117 Message-Id: <17A7E0F0-366C-46D1-8FC2-498C10E83575@isc.org> X-Mailer: iPhone Mail (9B179) From: Francisco Obispo Date: Tue, 24 Apr 2012 07:10:26 -0700 To: Gregory Berezowsky Cc: Alexander Mayrhofer , "provreg@ietf.org" Subject: Re: [provreg] ICANN TMCH draft specifications available - EPP extensions? X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 14:10:46 -0000 --Apple-Mail-A081A4F7-179C-42FE-B011-95B8304EC117 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 Sent from my iPhone On Apr 24, 2012, at 6:42 AM, Gregory Berezowsky wrot= e: > On Tue, Apr 24, 2012 at 7:45 AM, Hollenbeck, Scott wrote: > > -----Original Message----- > > From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On > > Behalf Of Alexander Mayrhofer > > Sent: Tuesday, April 17, 2012 6:12 AM > > To: provreg@ietf.org > > Subject: [provreg] ICANN TMCH draft specifications available - EPP > > extensions? > > > > The current version of ICANN's trademark clearinghouse specifications > > was published on April 13th. Looking through that document, i noticed > > that it requires a certain set of EPP extensions in order to transmit > > trademark claims/registration related data over EPP. > > > > Since the implementation of the TMCH is required for all operators of a > > new gTLD, i was wondering whether there is already work going on > > regarding specification of those EPP extensions? It would certainly not > > make much sense if every backend operator of a new gTLD invents their > > own schema/extension in order to support those required new data fields > > (registrars will certainly not appreciate those multiple extensions as > > well..). > > > > Therefore, if no work has yet been performed on the specification of > > those extensions in an internet draft, i think it makes sense to bundle > > forces among new gTLD backend operators in order to create such an > > extension. (Apart from that, i would also appreciate informal tech > > contacts to other emerging new gTLD backend operators, in order to > > discuss other operational / technical issues around the EPP > > implementation). >=20 > Jim Gould and I are interested in working on a standard extension or exten= sions for Verisign, but I'm worried about the timing of the need for these s= pecs and ICANN's launch schedule. Coming to agreement on a standard approach= in a short amount of time is going to be a challenge. >=20 > I am also interested in participating on standardizing this. At Afilias, w= e have similar concerns on the timing. >=20 > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg --Apple-Mail-A081A4F7-179C-42FE-B011-95B8304EC117 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
+1

Sent from my iPhone

On Apr 24, 2012, at 6:42 AM, Gregory Berezowsky <gberezow@afilias.info> wrote:

On Tue, Apr 24, 2012 at 7:45 AM, Hollenbeck, Scott <shollenbeck@verisign.com> wrote:
> -----Original Message-----
> From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On
> Behalf Of Alexander Mayrhofer
> Sent: Tuesday, April 17, 2012 6:12 AM
> To: provreg@ietf.org
> Subject: [provreg] ICANN TMCH draft specifications available - EPP
> extensions?
>
> The current version of ICANN's trademark clearinghouse specifications
> was published on April 13th. Looking through that document, i noticed
> that it requires a certain set of EPP extensions in order to transmit
> trademark claims/registration related data over EPP.
>
> Since the implementation of the TMCH is required for all operators of a
> new gTLD, i was wondering whether there is already work going on
> regarding specification of those EPP extensions? It would certainly not
> make much sense if every backend operator of a new gTLD invents their
> own schema/extension in order to support those required new data fields
> (registrars will certainly not appreciate those multiple extensions as
> well..).
>
> Therefore, if no work has yet been performed on the specification of
> those extensions in an internet draft, i think it makes sense to bundle
> forces among new gTLD backend operators in order to create such an
> extension. (Apart from that, i would also appreciate informal tech
> contacts to other emerging new gTLD backend operators, in order to
> discuss other operational / technical issues around the EPP
> implementation).

Jim Gould and I are interested in working on a standard extension or extensions for Verisign, but I'm worried about the timing of the need for these specs and ICANN's launch schedule. Coming to agreement on a standard approach in a short amount of time is going to be a challenge.

I am also interested in participating on standardizing this. At Afilias, we have similar concerns on the timing.

_______________________________________________
provreg mailing list
provreg@ietf.org
https://www.ietf.org/mailman/listinfo/provreg
--Apple-Mail-A081A4F7-179C-42FE-B011-95B8304EC117-- From wil@cloudregistry.net Tue Apr 24 07:11:30 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E90E121F85C6 for ; Tue, 24 Apr 2012 07:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TkhJgKJ8kGn for ; Tue, 24 Apr 2012 07:11:30 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id D12D521F87A3 for ; Tue, 24 Apr 2012 07:11:29 -0700 (PDT) Received: by yenm5 with SMTP id m5so429197yen.31 for ; Tue, 24 Apr 2012 07:11:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=K/MWwoeoD7bq0fSQWW9HH1+duEocfRlQV1qkuaLGoKA=; b=MVJ4STzYKLGV8udgu945/xgMuDFRt0pEGHoE3nQi0JJ3nQfmWTJXAB3Dd5DIa+rtkY xlGsgLXG2fOBr1X88PhSeA11jQ3oP+c6lbWiyrDXTg8aI3UBJu7lIRZQhXtu4bPVuRfI 745Y4yvgLpy+CGhqd1bg/PFEFsdpex4apT/LfSbN97bW12KMNUcERU8caVwsi4yuc6VB wHXfOxD1nNqWMm00bYATmiG2JcIeFSj8FcF3QNtRPcXZdebbUgNLJU3xnjluyz7yoM3X nfz8+qyxxTofDJnxKho/bbJ60JMILzsAnf/KLj5ni4SZZagvI4hrunxXhYS5swzS5Y0i atHQ== Received: by 10.50.17.166 with SMTP id p6mr10104700igd.53.1335276687084; Tue, 24 Apr 2012 07:11:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.129.73 with HTTP; Tue, 24 Apr 2012 07:10:46 -0700 (PDT) In-Reply-To: References: <19F54F2956911544A32543B8A9BDE075031012@NICS-EXCH.sbg.nic.at> <831693C2CDA2E849A7D7A712B24E257F0D5F25EA@BRN1WNEXMBX01.vcorp.ad.vrsn.com> From: Wil Tan Date: Wed, 25 Apr 2012 00:10:46 +1000 Message-ID: To: Gregory Berezowsky Content-Type: multipart/alternative; boundary=14dae9340cc99c4c9f04be6d5483 X-Gm-Message-State: ALoCoQkL0h6qid5uSIg10QZQtdRou2YsKG8bcM5Lv/9uKVN9lDHYIS1QOjgcpafpQjKW9r+wcOCk Cc: Alexander Mayrhofer , "provreg@ietf.org" Subject: Re: [provreg] ICANN TMCH draft specifications available - EPP extensions? X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 14:11:31 -0000 --14dae9340cc99c4c9f04be6d5483 Content-Type: text/plain; charset=UTF-8 On Tue, Apr 24, 2012 at 11:42 PM, Gregory Berezowsky wrote: > On Tue, Apr 24, 2012 at 7:45 AM, Hollenbeck, Scott < > shollenbeck@verisign.com> wrote: > >> >> Jim Gould and I are interested in working on a standard extension or >> extensions for Verisign, but I'm worried about the timing of the need for >> these specs and ICANN's launch schedule. Coming to agreement on a standard >> approach in a short amount of time is going to be a challenge. >> > > I am also interested in participating on standardizing this. At Afilias, > we have similar concerns on the timing. > > Cloud Registry is also willing to contribute towards standardizing this. There is at least a small amount of overlap of requirements between the TMCH flows and the launchphase draft that Gavin and I wrote. The Launchphase extension has provisions for carrying the "sunrisecode" (called "pvrc" in the draft) but defines an "application" object which we think is a common need during sunrise and other launch phases where multiple requests for a domain name is allowed. In theory we could integrate the claims data / ack bits from the TMC draft into it, but it doesn't seem the most elegant and smells like scope creep. On the other hand, I think registries and registrars would probably want to see a single extension rather than multiple. The draft expired in the midst of the gTLD application period "extension" but I've made some progress integrating some of James Gould's comments into the draft and we're preparing to work on it further. We're open to collaboration: https://github.com/cloudregistry/EPP-Launch-Phase-Extension-Specification .wil --14dae9340cc99c4c9f04be6d5483 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Apr 2= 4, 2012 at 11:42 PM, Gregory Berezowsky <gberezow@afilias.info>= wrote:
On Tue, Apr 24, 2012 at 7:45 AM, Hollenbec= k, Scott <shollenbeck@verisign.com> wrote:

Jim Gould and I are interested in working on a standard extension or extens= ions for Verisign, but I'm worried about the timing of the need for the= se specs and ICANN's launch schedule. Coming to agreement on a standard= approach in a short amount of time is going to be a challenge.

I am also interested in partic= ipating on standardizing this. At Afilias, we have similar concerns on the = timing.


Cloud Registry is also willing to contribu= te towards standardizing this. There is at least a small amount of overlap = of requirements between the TMCH flows and the launchphase draft that Gavin= and I wrote.

The Launchp= hase extension has provisions for carrying the "sunrisecode" (cal= led "pvrc" in the draft) but defines an "application" o= bject which we think is a common need during sunrise and other launch phase= s where multiple requests for a domain name is allowed. In theory we could = integrate the claims data / ack bits from the TMC draft into it, but it doe= sn't seem the most elegant and smells like scope creep. On the other ha= nd, I think registries and registrars would probably want to see a single e= xtension rather than multiple.

The draft e= xpired in the midst of the gTLD application period "extension" bu= t=C2=A0I've made some progress integrating some of James Gould's co= mments into the draft and we're preparing to work on it further. We'= ;re open to collaboration:=C2=A0https://github.com/cloudregistry= /EPP-Launch-Phase-Extension-Specification

.wil
--14dae9340cc99c4c9f04be6d5483--