From ulrich@wisser.se Wed Jun 8 00:50:56 2011 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 A9DD821F8528 for ; Wed, 8 Jun 2011 00:50:56 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ER2ClijyXMM5 for ; Wed, 8 Jun 2011 00:50:56 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id EAB9721F8527 for ; Wed, 8 Jun 2011 00:50:52 -0700 (PDT) Received: by fxm15 with SMTP id 15so159099fxm.31 for ; Wed, 08 Jun 2011 00:50:51 -0700 (PDT) Received: by 10.223.76.219 with SMTP id d27mr1067138fak.87.1307519451641; Wed, 08 Jun 2011 00:50:51 -0700 (PDT) Received: from ulrich-wissers-macbook-pro.local (gw.iis.se [212.247.14.38]) by mx.google.com with ESMTPS id b25sm96768fab.28.2011.06.08.00.50.50 (version=SSLv3 cipher=OTHER); Wed, 08 Jun 2011 00:50:50 -0700 (PDT) Message-ID: <4DEF29D9.10706@publisher.de> Date: Wed, 08 Jun 2011 09:50:49 +0200 From: Ulrich Wisser User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: provreg@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 08 Jun 2011 01:15:50 -0700 Subject: [provreg] Lists and EPP 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: Wed, 08 Jun 2011 07:59:28 -0000 Hi, one of the first question I get everytime I meet registrars is How can I get a list of all my domains? And yes, I believe registrars should be able to keep such a list themself. Even if only for business (invoice) reasons. But what are you going to do if your customers request a specific service? At some point you will have to do it anyway, so why not do it properly. I believe a list extension would be really helpful. Due to system load a registry might need to make some policies about usage but it would make live easier for registries and registrars. /Ulrich From jim@rfc1035.com Wed Jun 8 02:05:24 2011 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 2DA6411E814C for ; Wed, 8 Jun 2011 02:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+KKl1bCBLAf for ; Wed, 8 Jun 2011 02:05:23 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id E8F6611E8128 for ; Wed, 8 Jun 2011 02:05:22 -0700 (PDT) Received: from [192.168.1.64] (router.rfc1035.com [195.54.233.65]) by shaun.rfc1035.com (Postfix) with ESMTP id 8E6F1CBC473; Wed, 8 Jun 2011 10:05:20 +0100 (BST) Message-Id: <88F220D2-4084-41AF-BA59-3944AA4EA8E2@rfc1035.com> From: Jim Reid To: Ulrich Wisser In-Reply-To: <4DEF29D9.10706@publisher.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 8 Jun 2011 10:05:20 +0100 References: <4DEF29D9.10706@publisher.de> X-Mailer: Apple Mail (2.936) Cc: provreg@ietf.org Subject: Re: [provreg] Lists and EPP 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: Wed, 08 Jun 2011 09:05:24 -0000 On 8 Jun 2011, at 08:50, Ulrich Wisser wrote: > one of the first question I get everytime I meet registrars is > > How can I get a list of all my domains? > > And yes, I believe registrars should be able to keep such a list > themself. Even if only for business (invoice) reasons. But what are > you going to do if your customers request a specific service? At > some point you will have to do it anyway, so why not do it properly. IMO that means running some sort of SQL statement over the database and then sending the registrar a bill for the output. This would also encourage registrars to maintain proper records about the domain names they supposedly manage. :-) It's not clear to me an EPP hook is necessary to solve this issue. I wonder too about the practicalities of this sort of EPP transaction if GoDaddy's asking Verisign (to pick a registrar and registry not quite at random). From paf@cisco.com Wed Jun 8 02:12:12 2011 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 82FB611E816C for ; Wed, 8 Jun 2011 02:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-ByDMYxClAK for ; Wed, 8 Jun 2011 02:12:11 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 90EE711E816B for ; Wed, 8 Jun 2011 02:12:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paf@cisco.com; l=825; q=dns/txt; s=iport; t=1307524331; x=1308733931; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=szcDkHy9prNSDDvzBO2esNGJja3TdYI8xKFr2Qyxo7I=; b=ZkCjK7Z9V7uxvG5xOlLVoym0mugy2YylTSP3FIF4ZjYCTq/RZYgODNX7 L/8G6vtL4q3ZHx7uYcECsTHukBp+7Cx6GaJSpMaIWuIwwU1ZxRtU01Kcj QOTzK873HDKY+37VK14V8gXZou89pXeLEH+SVLPn82wKl3U1F8ySEOYZ/ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMQ7702Q/khR/2dsb2JhbABTpi53iHGhep4BhiMEkRuPTQ X-IronPort-AV: E=Sophos;i="4.65,337,1304294400"; d="scan'208";a="92859249" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 08 Jun 2011 09:12:10 +0000 Received: from dhcp-10-55-81-236.cisco.com (dhcp-10-55-81-236.cisco.com [10.55.81.236]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p589CAql028827; Wed, 8 Jun 2011 09:12:10 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <88F220D2-4084-41AF-BA59-3944AA4EA8E2@rfc1035.com> Date: Wed, 8 Jun 2011 11:12:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7C33C30D-12F2-48BA-B937-4305E9EE9A13@cisco.com> References: <4DEF29D9.10706@publisher.de> <88F220D2-4084-41AF-BA59-3944AA4EA8E2@rfc1035.com> To: Jim Reid X-Mailer: Apple Mail (2.1084) Cc: Ulrich Wisser , provreg@ietf.org Subject: Re: [provreg] Lists and EPP 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: Wed, 08 Jun 2011 09:12:12 -0000 On 8 jun 2011, at 11.05, Jim Reid wrote: > It's not clear to me an EPP hook is necessary to solve this issue. I = wonder too about the practicalities of this sort of EPP transaction if = GoDaddy's asking Verisign (to pick a registrar and registry not quite at = random). The main reason this might be needed in some sort of automated fashion = is that some registries do have a policy that imply domains might move = easier between the registrars than at other registries. I.e. it is = easier than one think to end up out-of-sync. There are a number of other sync-mechanisms I would not mind seeing, but = it is important the registries do that the same way... I do see = registrars start to be irritated on the high number of different = implementations of The Same Thing between registries. Patrik From bernie@ietf.hoeneisen.ch Wed Jun 8 02:16:35 2011 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 2A74C11E816B for ; Wed, 8 Jun 2011 02:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-xUBggPFe60 for ; Wed, 8 Jun 2011 02:16:33 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by ietfa.amsl.com (Postfix) with ESMTP id A180111E8169 for ; Wed, 8 Jun 2011 02:16:33 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.71) (envelope-from ) id 1QUEsI-0007Ns-3I; Wed, 08 Jun 2011 11:16:30 +0200 Date: Wed, 8 Jun 2011 11:16:30 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Ulrich Wisser In-Reply-To: <4DEF29D9.10706@publisher.de> Message-ID: References: <4DEF29D9.10706@publisher.de> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Cc: IETF Provreg Mailing List Subject: Re: [provreg] Lists and EPP 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: Wed, 08 Jun 2011 09:16:35 -0000 Hi Ulrich As I understand this functionality is out-of-scope for EPP. Such functionality has been addressed and standardized by the CRISP working group as IRIS protocol. For reference, see RFC 3981 ff. http://tools.ietf.org/html/rfc3981 ff. cheers, Bernie -- http://ucom.ch/ Tech Consulting for Internet Standardization On Wed, 8 Jun 2011, Ulrich Wisser wrote: > Hi, > > one of the first question I get everytime I meet registrars is > > How can I get a list of all my domains? > > And yes, I believe registrars should be able to keep such a list themself. > Even if only for business (invoice) reasons. But what are you going to do if > your customers request a specific service? At some point you will have to do > it anyway, so why not do it properly. > > I believe a list extension would be really helpful. Due to system load a > registry might need to make some policies about usage but it would make live > easier for registries and registrars. > > /Ulrich > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg > From volker.janzen@internetx.de Wed Jun 8 02:19:41 2011 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 3BE4D11E816E for ; Wed, 8 Jun 2011 02:19:41 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRWtFOl2fg+8 for ; Wed, 8 Jun 2011 02:19:40 -0700 (PDT) Received: from web4.internetx.de (gate2.mailgate.de [62.116.129.39]) by ietfa.amsl.com (Postfix) with ESMTP id 4A58111E80B5 for ; Wed, 8 Jun 2011 02:19:40 -0700 (PDT) Received: from [192.168.100.46] (pizza.internetx.de [62.116.129.3]) (authenticated bits=0) by web4.internetx.de (8.13.8/8.13.8) with ESMTP id p589JYL7019211 for ; Wed, 8 Jun 2011 11:19:36 +0200 Message-ID: <4DEF3EA3.2020706@internetx.de> Date: Wed, 08 Jun 2011 11:19:31 +0200 From: InterNetX - Volker Janzen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: provreg@ietf.org References: <4DEF29D9.10706@publisher.de> <88F220D2-4084-41AF-BA59-3944AA4EA8E2@rfc1035.com> <7C33C30D-12F2-48BA-B937-4305E9EE9A13@cisco.com> In-Reply-To: <7C33C30D-12F2-48BA-B937-4305E9EE9A13@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig65BF3D50E18582047FBAF7A2" Subject: Re: [provreg] Lists and EPP 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: Wed, 08 Jun 2011 09:19:41 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig65BF3D50E18582047FBAF7A2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Am 08.06.2011 11:12, schrieb Patrik F=E4ltstr=F6m: > I.e. it is easier than one think to end up out-of-sync. I agree with this. It's very nice for registrars to have a list of all domains in the account to find domains that are out of sync quick. If every registry offers such a list in a different way, you'll always have the pain of writing script for fetching. Would be nice if there is a standard way to provide these lists. Regarding the database load caused by list generation: this could be done by a cron job and the registrar could fetch the last list that has been generated (marked with date, when the list has been generated). Volker Janzen Team Entwicklung --=20 InterNetX GmbH Maximilianstr. 6 93047 Regensburg Germany Tel: +49 941 59559-0 Fax: +49 941 59579-050 www.internetx.com www.facebook.com/InterNetX www.twitter.com/InterNetX Gesch=E4ftsf=FChrer/CEO: Thomas M=F6rz Amtsgericht Regensburg, HRB 7142 GPG-Key: 0x186C5F77 GPG-Fingerprint: 392E 8730 FE23 DCE8 8878 8524 5361 BCCC 186C 5F77 --------------enig65BF3D50E18582047FBAF7A2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3vPqUACgkQU2G8zBhsX3dXKgCgnJpYYzFRibDir4bdj/409sQo CQ0AnAmnbW4/hgiRq+/5UuJDvi+ZHTKY =FYxC -----END PGP SIGNATURE----- --------------enig65BF3D50E18582047FBAF7A2-- From Klaus.Malorny@knipp.de Wed Jun 8 03:00:44 2011 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 99F5021F8518 for ; Wed, 8 Jun 2011 03:00:44 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IK9szWmbJZuG for ; Wed, 8 Jun 2011 03:00:43 -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 93D5F21F8517 for ; Wed, 8 Jun 2011 03:00:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 5EB8F48; Wed, 8 Jun 2011 12:00:34 +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 8QkpbzT3Bxi1; Wed, 8 Jun 2011 12:00:26 +0200 (MESZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 0B5C249; Wed, 8 Jun 2011 12:00:25 +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 p58A0OZZ025769; Wed, 8 Jun 2011 12:00:24 +0200 (MESZ) Message-ID: <4DEF4839.4090703@knipp.de> Date: Wed, 08 Jun 2011 12:00:25 +0200 From: Klaus Malorny User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0a1) Gecko/20110606 Thunderbird/7.0a1 MIME-Version: 1.0 To: Bernie Hoeneisen References: <4DEF29D9.10706@publisher.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ulrich Wisser , IETF Provreg Mailing List Subject: Re: [provreg] Lists and EPP 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: Wed, 08 Jun 2011 10:00:44 -0000 On 08/06/11 11:16, Bernie Hoeneisen wrote: > Hi Ulrich > > As I understand this functionality is out-of-scope for EPP. Such functionality > has been addressed and standardized by the CRISP working group as IRIS protocol. > > For reference, see RFC 3981 ff. > > http://tools.ietf.org/html/rfc3981 ff. > > cheers, > Bernie > Hi, hmm, for some reasons, CRISP never really took off. And are there any alternative transport mechanisms besides BEEP, which does not seem to have widespread library support? Besides this, an implementation with CRISP has probably the same issues as an EPP implementation, namely that you have potentially to deal with hundred thousands domains, which may eat up your resources server-side. However, generally, a reporting mechanism could be done in an incremental way, so that it even could be implemented in EPP: If one considers the list of domains being lexicographically sorted, one can give a starting point from which the names shall be reported. The server returns only the next n names according the given sort order (n ranging from a few tens to a few hundreds). To continue the list, one specifies the last name of the last response as the new starting point. While this seems to be less efficient, it has the benefit that the returned list is nearly up-to-date (compared to generated reports which may be up to 24 hours old), and one can do one's synchronization stuff in a continuous mode if need be. If this is too slow, the client can even use multiple starting points in parallel. We have implemented such methods in different places and it works sufficiently enough. regards, Klaus From jim@rfc1035.com Wed Jun 8 03:13:38 2011 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 649DF11E8097 for ; Wed, 8 Jun 2011 03:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, HOST_MISMATCH_COM=0.311, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtqQG1AT46AF for ; Wed, 8 Jun 2011 03:13:38 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 7972D11E8077 for ; Wed, 8 Jun 2011 03:13:37 -0700 (PDT) Received: from [192.168.1.64] (router.rfc1035.com [195.54.233.65]) by shaun.rfc1035.com (Postfix) with ESMTP id 69FDDCBC474; Wed, 8 Jun 2011 11:13:35 +0100 (BST) Message-Id: From: Jim Reid To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <7C33C30D-12F2-48BA-B937-4305E9EE9A13@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 8 Jun 2011 11:13:35 +0100 References: <4DEF29D9.10706@publisher.de> <88F220D2-4084-41AF-BA59-3944AA4EA8E2@rfc1035.com> <7C33C30D-12F2-48BA-B937-4305E9EE9A13@cisco.com> X-Mailer: Apple Mail (2.936) Cc: Ulrich Wisser , provreg@ietf.org Subject: Re: [provreg] Lists and EPP 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: Wed, 08 Jun 2011 10:13:38 -0000 On 8 Jun 2011, at 10:12, Patrik F=E4ltstr=F6m wrote: > There are a number of other sync-mechanisms I would not mind seeing, =20= > but it is important the registries do that the same way... I do see =20= > registrars start to be irritated on the high number of different =20 > implementations of The Same Thing between registries. Yes, an industry-wide standarised way to do this kind of thing would =20 of course be good Patrik. I'm not convinced EPP is the tool to use =20 though. Not every registry and registrar speaks EPP. There could be =20 icky implementation issues too: eg locking the database while =20 something ploughs through it to generate the list. [We can't have the =20= database changing while the list is generated, eh?] I fear this could =20= be the start of a slippery slope as more SQL reporting type stuff gets =20= shoe-horned into EPP: "gimme a list of all the domain names I =20 registered for this contact that then got transferred to that =20 registrar over the last N months", "which domains I manage reference =20 this nameserver (or contact) object?". Perhaps a BCP might be a better approach than an EPP extension?= From paf@cisco.com Wed Jun 8 04:33:09 2011 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 B0B0A11E80B2 for ; Wed, 8 Jun 2011 04:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-j3y9Uk5Mbi for ; Wed, 8 Jun 2011 04:33:09 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id A7BA511E8081 for ; Wed, 8 Jun 2011 04:33:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paf@cisco.com; l=1901; q=dns/txt; s=iport; t=1307532788; x=1308742388; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ns5unVb39bchTX+x8x9VEq9sezMH+Cc1gM6HDOgRQ5s=; b=mHEx+9jixbqybxOW3QjxZzuoEIPBFkweRUNrXR8XtMtwuBbUPq+Ajvlq jbzeMx6QeZyttwD835k0keAqo14VR0Tm6ulw0b2wLYx+KAd+m9B6oG9N4 b+/HLm076QlUsMI12HWSSTaY6QZ3zze+JRv5maUjSKn5ZB4n9zitPUesd Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMld702Q/khM/2dsb2JhbABTpjB3iHGhOJ1/hiMEkRuPTQ X-IronPort-AV: E=Sophos;i="4.65,338,1304294400"; d="scan'208";a="34245908" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 08 Jun 2011 11:32:44 +0000 Received: from dhcp-10-55-83-144.cisco.com (dhcp-10-55-83-144.cisco.com [10.55.83.144]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p58BWhfJ012267; Wed, 8 Jun 2011 11:32:43 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Wed, 8 Jun 2011 13:32:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DEF29D9.10706@publisher.de> <88F220D2-4084-41AF-BA59-3944AA4EA8E2@rfc1035.com> <7C33C30D-12F2-48BA-B937-4305E9EE9A13@cisco.com> To: Jim Reid X-Mailer: Apple Mail (2.1084) Cc: Ulrich Wisser , provreg@ietf.org Subject: Re: [provreg] Lists and EPP 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: Wed, 08 Jun 2011 11:33:09 -0000 On 8 jun 2011, at 12.13, Jim Reid wrote: > On 8 Jun 2011, at 10:12, Patrik F=E4ltstr=F6m wrote: >=20 >> There are a number of other sync-mechanisms I would not mind seeing, = but it is important the registries do that the same way... I do see = registrars start to be irritated on the high number of different = implementations of The Same Thing between registries. >=20 > Yes, an industry-wide standarised way to do this kind of thing would = of course be good Patrik. I'm not convinced EPP is the tool to use = though. Not every registry and registrar speaks EPP. There could be icky = implementation issues too: eg locking the database while something = ploughs through it to generate the list. [We can't have the database = changing while the list is generated, eh?] I fear this could be the = start of a slippery slope as more SQL reporting type stuff gets = shoe-horned into EPP: "gimme a list of all the domain names I registered = for this contact that then got transferred to that registrar over the = last N months", "which domains I manage reference this nameserver (or = contact) object?". >=20 > Perhaps a BCP might be a better approach than an EPP extension? I agree with this, but the day one of the registries do implement = something like this in epp, I want other registries to follow. And, if you want to know what has been shoe horned into epp, have a look = at what the various registries actually have implemented. I.e. I do not agree this would be the beginning of a slippery slope. We = are already falling down that slippery slope in very high speed as no = registry is compliant with other registries epp implementation. People have, we see now, used the "e" part of epp a bit too much. And I dare to say that as I as Area Director when epp was invented could = have pushed back more, but I did not. So I blame myself. Patrik From shollenbeck@verisign.com Wed Jun 8 04:51:20 2011 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 AFEA211E8081 for ; Wed, 8 Jun 2011 04:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJ8btybk9yZG for ; Wed, 8 Jun 2011 04:51:20 -0700 (PDT) Received: from exprod6og103.obsmtp.com (exprod6og103.obsmtp.com [64.18.1.185]) by ietfa.amsl.com (Postfix) with ESMTP id 5777811E8075 for ; Wed, 8 Jun 2011 04:51:12 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP ID DSNKTe9iL3MY2JaBRD7UhzPh1/u5XAsvNns/@postini.com; Wed, 08 Jun 2011 04:51:13 PDT Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id p58BpB61013802; Wed, 8 Jun 2011 07:51:11 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Jun 2011 07:51:10 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Jun 2011 07:51:09 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF0703B8B1D7@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [provreg] Lists and EPP Thread-Index: Acwlz+6xbhGJYIjpQ+mJGbDTeVc3hAAAP2tA References: <4DEF29D9.10706@publisher.de><88F220D2-4084-41AF-BA59-3944AA4EA8E2@rfc1035.com><7C33C30D-12F2-48BA-B937-4305E9EE9A13@cisco.com> From: "Hollenbeck, Scott" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-OriginalArrivalTime: 08 Jun 2011 11:51:10.0878 (UTC) FILETIME=[5C4C83E0:01CC25D2] Cc: provreg@ietf.org Subject: Re: [provreg] Lists and EPP 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: Wed, 08 Jun 2011 11:51:20 -0000 > -----Original Message----- > From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On > Behalf Of Patrik F=E4ltstr=F6m > Sent: Wednesday, June 08, 2011 7:33 AM > To: Jim Reid > Cc: Ulrich Wisser; provreg@ietf.org > Subject: Re: [provreg] Lists and EPP [snip] > People have, we see now, used the "e" part of epp a bit too much. >=20 > And I dare to say that as I as Area Director when epp was invented > could have pushed back more, but I did not. So I blame myself. Don't, Patrik. The hard part about what we were doing is that we were = trying to produce a protocol to automate a multitude of existing = disparate registration processes and policies. That's not a good = starting point for being able to reach agreement on one way and one way = only. Given the operating environment I don't think we could have ever = produced anything at all without extensibility. I still have "that's policy!" nightmares... :) Scott From paf@cisco.com Wed Jun 8 04:55:51 2011 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 30DAF11E8143 for ; Wed, 8 Jun 2011 04:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSUtmjv24nhd for ; Wed, 8 Jun 2011 04:55:50 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 605C611E80E4 for ; Wed, 8 Jun 2011 04:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paf@cisco.com; l=1295; q=dns/txt; s=iport; t=1307534147; x=1308743747; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=5pmkdn5qas9NDtiYOif8b8jQDlStwy06EScyAWBiY6I=; b=U45xF0dXinmoE1HxyMBxH8+Olh84nhUzqXWiPg0rtjw6oN4UpodFq119 m/DroAeYzRl4Nl/WWmRWeUntaUhvAHxlx59ODet/NA3fUFDj/DEXTIUOa aKs+8wxmBsbffj7B7lrzvfyT5O5t6tJQmkKvSBpFD9Y9GRKnx2+WDV8Bq 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIti702Q/khL/2dsb2JhbABTpjB3iHGhL51/hiMEkRuPTQ X-IronPort-AV: E=Sophos;i="4.65,338,1304294400"; d="scan'208";a="92894284" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 08 Jun 2011 11:55:43 +0000 Received: from dhcp-10-55-83-144.cisco.com (dhcp-10-55-83-144.cisco.com [10.55.83.144]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p58Bthc7029234; Wed, 8 Jun 2011 11:55:43 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <046F43A8D79C794FA4733814869CDF0703B8B1D7@dul1wnexmb01.vcorp.ad.vrsn.com> Date: Wed, 8 Jun 2011 13:55:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4DC964CE-7C0E-4EE2-8A92-DD3EA68C2B7E@cisco.com> References: <4DEF29D9.10706@publisher.de><88F220D2-4084-41AF-BA59-3944AA4EA8E2@rfc1035.com><7C33C30D-12F2-48BA-B937-4305E9EE9A13@cisco.com> <046F43A8D79C794FA4733814869CDF0703B8B1D7@dul1wnexmb01.vcorp.ad.vrsn.com> To: "Hollenbeck, Scott" X-Mailer: Apple Mail (2.1084) Cc: provreg@ietf.org Subject: Re: [provreg] Lists and EPP 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: Wed, 08 Jun 2011 11:55:51 -0000 On 8 jun 2011, at 13.51, Hollenbeck, Scott wrote: > The hard part about what we were doing is that we were trying to = produce a protocol to automate a multitude of existing disparate = registration processes and policies. That's not a good starting point = for being able to reach agreement on one way and one way only. Given = the operating environment I don't think we could have ever produced = anything at all without extensibility. >=20 > I still have "that's policy!" nightmares... :) Yeah, you are the hero that really never gave up!!! What irritates me is though that there are a number of extensions that = are made slightly differently, with slightly different rules on data = format and of course that registries use their own extensions even = though they are very similar, or identical, to what other people are = doing. So yes, we needed extensions, I just think registries could have done = better if they coordinated a bit more the standardization of the = extensions, instead of creating one epp extension per registry/domain = name combination. To conclude: I agree that epp is probably not the most efficient = protocol to do sync:ing, but I rather see one syncing extension than = "one per registry". That was my (only) point. Patrik From marco.schrieck@internetx.de Wed Jun 8 05:29:26 2011 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 1E46621F8496 for ; Wed, 8 Jun 2011 05:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jo-yvSXQxPeu for ; Wed, 8 Jun 2011 05:29:25 -0700 (PDT) Received: from web4.internetx.de (gate2.mailgate.de [62.116.129.39]) by ietfa.amsl.com (Postfix) with ESMTP id F193421F8493 for ; Wed, 8 Jun 2011 05:29:24 -0700 (PDT) Received: from marco-schrieck.intern.internetx.de (pizza.internetx.de [62.116.129.3]) (authenticated bits=0) by web4.internetx.de (8.13.8/8.13.8) with ESMTP id p58CTKtn031340 for ; Wed, 8 Jun 2011 14:29:23 +0200 Message-ID: <4DEF6B26.4080209@internetx.com> Date: Wed, 08 Jun 2011 14:29:26 +0200 From: InterNetX - Marco Schrieck Organization: InterNetX GmbH User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: provreg@ietf.org References: <4DEF29D9.10706@publisher.de><88F220D2-4084-41AF-BA59-3944AA4EA8E2@rfc1035.com><7C33C30D-12F2-48BA-B937-4305E9EE9A13@cisco.com> <046F43A8D79C794FA4733814869CDF0703B8B1D7@dul1wnexmb01.vcorp.ad.vrsn.com> <4DC964CE-7C0E-4EE2-8A92-DD3EA68C2B7E@cisco.com> In-Reply-To: <4DC964CE-7C0E-4EE2-8A92-DD3EA68C2B7E@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [provreg] Lists and EPP 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: Wed, 08 Jun 2011 12:29:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, Am 08.06.11 13:55, schrieb Patrik Fältström: > So yes, we needed extensions, I just think registries could > have done better if they coordinated a bit more the standardization > of the extensions, instead of creating one epp extension per > registry/domain name combination. I agree with that, but most process are in some way the same, but from EPP side there are not recommendations, how to handle this. So it is clear that every one do his own stuff. For example Ownerchanges and Transfers with Ownerchanges. > To conclude: I agree that epp is probably not the most efficient > protocol to do sync:ing, but I rather see one syncing > extension than "one per registry". That was my (only) point. Most registry have a ftp/http download for such list, most lists are quite indentical. So if there was a standard for the minimum requirements it would be nice. eg. list creationdate with date and time some basic fields: domain,created,expire,updated,autorenew,phase (status: redemtionPeriod) Regards Marco Schrieck Bereichsleiter Entwicklung - -- InterNetX GmbH Maximilianstr. 6 93047 Regensburg Germany Tel. +49 941 59559-0 Fax +49 941 59579-050 www.internetx.com www.facebook.com/InterNetX www.twitter.com/InterNetX Geschäftsführer/CEO: Thomas Mörz Amtsgericht Regensburg, HRB 7142 ICQ: 232016987 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJN72smAAoJEN9yMHEBd2HnvEgIALqsMh7PevjT1+gAHUvPS1wB eMdd/4OZxNjy8ZVaD9Ij10w4io6CG1t3uCu+gBUXLq93Ab0SAvcOJfmvJ/7sEGGi GHtH5+VeeozDh0vDDsjEX8NvdNP+5tyQbBx/sfhtbnDc66Oh9qOuFz2ybuH2zJoE W/c9Afx/7IB8ZwBQmmXPANW2Y6LZjZ0S6QDeZNy9buMfSxO0EJh8CuEhU725x/fL bf+byS4mlEMYJnQblTxBKcM62VBHEhgPyGWcvt6N1f4QEoK9IxJsOu7ZdkadRPpa telfWt0idlNyS5VWrmw0FpM1kkVq4q/IE3dHdhRNplw6XDuGLW6N1qZFgC4Ro5w= =BmXO -----END PGP SIGNATURE----- From ajs@anvilwalrusden.com Wed Jun 8 06:31:41 2011 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 3201911E80BE for ; Wed, 8 Jun 2011 06:31:41 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHGNhPAX2JAy for ; Wed, 8 Jun 2011 06:31:40 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 98F6211E80BB for ; Wed, 8 Jun 2011 06:31:40 -0700 (PDT) Received: from shinkuro.com (external.shinkuro.com [66.92.164.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id EA6751ECB426 for ; Wed, 8 Jun 2011 13:31:38 +0000 (UTC) Date: Wed, 8 Jun 2011 09:31:34 -0400 From: Andrew Sullivan To: provreg@ietf.org Message-ID: <20110608133133.GA45314@shinkuro.com> References: <4DEF29D9.10706@publisher.de> <4DEF4839.4090703@knipp.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DEF4839.4090703@knipp.de> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [provreg] Lists and EPP 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: Wed, 08 Jun 2011 13:31:41 -0000 On Wed, Jun 08, 2011 at 12:00:25PM +0200, Klaus Malorny wrote: > However, generally, a reporting mechanism could be done in an > incremental way, so that it even could be implemented in EPP: Why do you want to Extend the protocol so that it's no longer even about Provisioning? I can see a possibly useful extension that requests a report be generated. That is, like other things in EPP, one can request that something be provisioned (in this case, a report). But the response to that should not be a long list of domains in-protocol, I think. EPP is poorly structured for that sort of bulk operation, on purpose. A -- Andrew Sullivan ajs@anvilwalrusden.com From Ed.Lewis@neustar.biz Wed Jun 8 06:40:56 2011 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 499A111E812A for ; Wed, 8 Jun 2011 06:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.499 X-Spam-Level: X-Spam-Status: No, score=-106.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhTQxrR4WWES for ; Wed, 8 Jun 2011 06:40:55 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id DB97511E8114 for ; Wed, 8 Jun 2011 06:40:54 -0700 (PDT) Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p58DeqKh023508; Wed, 8 Jun 2011 09:40:52 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.222] by Work-Laptop-2.local (PGP Universal service); Wed, 08 Jun 2011 09:40:53 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Wed, 08 Jun 2011 09:40:53 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4DEF29D9.10706@publisher.de> <88F220D2-4084-41AF-BA59-3944AA4EA8E2@rfc1035.com> <7C33C30D-12F2-48BA-B937-4305E9EE9A13@cisco.com> Date: Wed, 8 Jun 2011 09:32:22 -0400 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: Re: [provreg] Lists and EPP 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: Wed, 08 Jun 2011 13:40:56 -0000 At 11:13 +0100 6/8/11, Jim Reid wrote: >Yes, an industry-wide standarised way to do this kind of thing would of >course be good Patrik. First let's put the cart and the horse in the right sequence. First solve the problem and then worry about making the solution generally applicable. Before that (zeroth?) define and scope the problem. If "one of the first question I get every time I meet registrars is 'How can I get a list of all my domains?'" really is something common across registries, this sounds like a worthwhile topic to take on. Solving real problems is a lot more fun than making them up. ;) In the "it seems to me" column, efforts with the goal of finding a standard solution usually die on the vine. Efforts that attack the problem regardless of generalization yield better fruit from which we can extract a more general solution. >I'm not convinced EPP is the tool to use though. Not every registry >and registrar speaks EPP. That's a valid point ("the tool to use") but the issue isn't that it isn't ubiquitous. No one is prevented from adopting EPP or deploying it as an interface, but anyone is free to not adopt it. >There could be icky implementation issues too: eg locking the database while >something ploughs through it to generate the list. [We can't have the database >changing while the list is generated, eh?] I fear this could be the start of a >slippery slope as more SQL reporting type stuff gets shoe-horned into EPP: >"gimme a list of all the domain names I registered for this contact that then >got transferred to that registrar over the last N months", "which domains I >manage reference this nameserver (or contact) object?". What's to fear isn't the slippery slope. There's no rules for what any protocol can or can't be made to do. The analysis needed (and Jim begins it) is first to identify the strengths and weaknesses of EPP. Besides its functional abstract, how well does it do the job in certain situations and how poorly does it do the job in others. Then any alterations to the protocol had better not weaken its strong points. Alterations should highlight the strong points. EPP is a registrar-registry protocol. Its role is entering provisioning data. The two are not the same. How well does it handle high latency operations? Why has IRIS failed to bloom? Why did it fail where EPP succeeded? Maybe there are clues there pointing out how EPP might be able to do this. Maybe this is a fit for EPP. But maybe it isn't. Just because EPP was built for one use case (provisioning) doesn't mean it has to stick to that. The "E" stands for Extensible after all. >Perhaps a BCP might be a better approach than an EPP extension? Remember that code trumps spec in the IETF. (Die on the vine, yield fruit, IRIS blooming...hmm maybe I should take the rest of the day off and tend to a garden.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Now, don't say I'm always complaining. Wait, that's a complaint, isn't it? From Ed.Lewis@neustar.biz Wed Jun 8 06:51:06 2011 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 08F0911E817F for ; Wed, 8 Jun 2011 06:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.376 X-Spam-Level: X-Spam-Status: No, score=-105.376 tagged_above=-999 required=5 tests=[AWL=-1.073, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lmk1vAptc9sd for ; Wed, 8 Jun 2011 06:51:05 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2450C11E80BB for ; Wed, 8 Jun 2011 06:51:04 -0700 (PDT) Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p58Dox97023569; Wed, 8 Jun 2011 09:50:59 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.222] by Work-Laptop-2.local (PGP Universal service); Wed, 08 Jun 2011 09:51:00 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Wed, 08 Jun 2011 09:51:00 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4DEF29D9.10706@publisher.de> <88F220D2-4084-41AF-BA59-3944AA4EA8E2@rfc1035.com> <7C33C30D-12F2-48BA-B937-4305E9EE9A13@cisco.com> Date: Wed, 8 Jun 2011 09:47:43 -0400 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= From: Edward Lewis Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: ed.lewis@neustar.biz, provreg@ietf.org Subject: [provreg] Too much 'E'? was Re: Lists and EPP 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: Wed, 08 Jun 2011 13:51:06 -0000 At 13:32 +0200 6/8/11, Patrik F=E4ltstr=F6m wrote: >People have, we see now, used the "e" part of epp a bit too much. Can you quantify this? (Asking out of=20 curiosity.) As in, has there been a failure in=20 the protocol? Has the goal of interoperability=20 failed? Between 2009 and 2010 I poked into EPP 2.0 and=20 found that everyone was happy with EPP 1.0 and=20 the plethora of extensions, especially with=20 Patrick Mevzek (I believe) has implemented the=20 bulk of them in one distribution. >And I dare to say that as I as Area Director when epp was invented could >have pushed back more, but I did not. So I blame myself. As one of the co-chairs, I'm willing to pass the blame on. ;) At 13:55 +0200 6/8/11, Patrik F=E4ltstr=F6m wrote: >So yes, we needed extensions, I just think registries could have done bette= r >if they coordinated a bit more the standardization of the extensions, inste= ad >of creating one epp extension per registry/domain name combination. > >To conclude: I agree that epp is probably not the most efficient protocol t= o >do sync:ing, but I rather see one syncing extension than "one per registry"= =2E >That was my (only) point. I continued in the thread and found this. I thought the same as you expressed when I did=20 some organization for a non-BoF at the Anaheim=20 IETF. Architecturally speaking, I had some=20 misgivings about the path EPP had taken. From=20 March 2010 until May 2010 some efforts ramped up=20 as a result of the IETF-related meeting,=20 including a new mailing list started called=20 regops. In early May, in a CENTR Tech meeting=20 some preliminary results were presented - mostly=20 the estimate of what it would take to "fix" EPP.=20 This presentation was a follow up to a discussion=20 during the October 2009 CENTR Tech meeting that=20 kind of kicked off this short study. The discussion at the May 2009 CENTR Tech meeting=20 came down to "okay, well, EPP 1.0 is sufficient."=20 I took this to mean - in the operations world,=20 EPP is just fine. Operators are satisfied that=20 there is code to do all the versions needed. To=20 an operator having two different "redemption=20 grace period" extensions, one for COM and one for=20 BIZ, is not a problem. Maybe as an architect it=20 sounds ugly - but then who are protocols built=20 for, the architects or the operators? After that meeting I abandoned any upgrade/update=20 to EPP and learned to live with the way it is.=20 Code rules, specs aren't as important. -- -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Now, don't say I'm always complaining. Wait, that's a complaint, isn't it? From paf@cisco.com Wed Jun 8 07:32:24 2011 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 A714311E80F3 for ; Wed, 8 Jun 2011 07:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.924 X-Spam-Level: X-Spam-Status: No, score=-9.924 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxHFCPidBpkL for ; Wed, 8 Jun 2011 07:32:10 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4136811E80E7 for ; Wed, 8 Jun 2011 07:32:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paf@cisco.com; l=4001; q=dns/txt; s=iport; t=1307543530; x=1308753130; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=tN+py+PGYGvT+RJsNDPCUbv+2M9McIG0aTUJmDYta9Y=; b=Pp7yYbSPpNqUhcvBD3/sTwHvCeYMy/b/FCbhPvQNb5DfHY42kCTv/XZu y6Ax26gBjRBYX2Z0inyUoM/SaHfROGL5kkKTcCVUrjzofdp1a5gkh0RcC +71TWd9gwfykXLru2uvD0ZrWr2l7juVtuP20DHmqHjMGTigtQgfp37m2/ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG6G702Q/khN/2dsb2JhbABTpjF3iHGgQJ1+hiMEkRuPTQ X-IronPort-AV: E=Sophos;i="4.65,339,1304294400"; d="scan'208";a="34281585" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 08 Jun 2011 14:32:06 +0000 Received: from dhcp-10-55-83-144.cisco.com (dhcp-10-55-83-144.cisco.com [10.55.83.144]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p58EW5qh026917; Wed, 8 Jun 2011 14:32:05 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Wed, 8 Jun 2011 16:32:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DEF29D9.10706@publisher.de> <88F220D2-4084-41AF-BA59-3944AA4EA8E2@rfc1035.com> <7C33C30D-12F2-48BA-B937-4305E9EE9A13@cisco.com> To: Edward Lewis X-Mailer: Apple Mail (2.1084) Cc: provreg@ietf.org Subject: Re: [provreg] Too much 'E'? was Re: Lists and EPP 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: Wed, 08 Jun 2011 14:32:24 -0000 On 8 jun 2011, at 15.47, Edward Lewis wrote: > At 13:32 +0200 6/8/11, Patrik F=E4ltstr=F6m wrote: >=20 >> People have, we see now, used the "e" part of epp a bit too much. >=20 > Can you quantify this? (Asking out of curiosity.) As in, has there = been a failure in the protocol? Has the goal of interoperability = failed? Yes. I claim that have failed from some point of view. The protocol is = interoperable, but what you transfer inside the protocol is different. Just look at Net::DRI in Perl and you see that every TLD have their own = extension. They have their own rules for for example how a domain name = is to be written (do they accept [a-z] only, or [a-zA-Z]?). Etc... I think personally it is because all development of the protocol, and = the extensions, are made by the registries, and not enough input from = registrars which are the ones that today have to pay the burden of what = I call non-interoperability. Hey, some registries do not even release their specification unless you = pay to become a registrar! Yes, different business models exists for the registries, but I do not = see such diversity is needed as exists today in for example the epp = specs for the various TLDs. > Between 2009 and 2010 I poked into EPP 2.0 and found that everyone was = happy with EPP 1.0 and the plethora of extensions, especially with = Patrick Mevzek (I believe) has implemented the bulk of them in one = distribution. Who are everyone? How many registrars did you talk with that actually = have implemented epp from ground up that have connections with say 5-10 = different registries where a minority are gTLDs? >> And I dare to say that as I as Area Director when epp was invented = could >> have pushed back more, but I did not. So I blame myself. >=20 > As one of the co-chairs, I'm willing to pass the blame on. ;) Ha ha ha! > At 13:55 +0200 6/8/11, Patrik F=E4ltstr=F6m wrote: >=20 >> So yes, we needed extensions, I just think registries could have done = better >> if they coordinated a bit more the standardization of the extensions, = instead >> of creating one epp extension per registry/domain name combination. >>=20 >> To conclude: I agree that epp is probably not the most efficient = protocol to >> do sync:ing, but I rather see one syncing extension than "one per = registry". >> That was my (only) point. >=20 > I continued in the thread and found this. >=20 > I thought the same as you expressed when I did some organization for a = non-BoF at the Anaheim IETF. Architecturally speaking, I had some = misgivings about the path EPP had taken. =46rom March 2010 until May = 2010 some efforts ramped up as a result of the IETF-related meeting, = including a new mailing list started called regops. In early May, in a = CENTR Tech meeting some preliminary results were presented - mostly the = estimate of what it would take to "fix" EPP. This presentation was a = follow up to a discussion during the October 2009 CENTR Tech meeting = that kind of kicked off this short study. >=20 > The discussion at the May 2009 CENTR Tech meeting came down to "okay, = well, EPP 1.0 is sufficient." CENTR is biased to registries. > I took this to mean - in the operations world, EPP is just fine. = Operators are satisfied that there is code to do all the versions = needed. To an operator having two different "redemption grace period" = extensions, one for COM and one for BIZ, is not a problem. Yes, it IS a problem. To have one extension for every TLD, that create a nXm matrix of number = of extensions times number of TLDs. > Maybe as an architect it sounds ugly - but then who are protocols = built for, the architects or the operators? >=20 > After that meeting I abandoned any upgrade/update to EPP and learned = to live with the way it is. Code rules, specs aren't as important. And I think you made the correct decision. Or you would go mad! ;-) Patrik From Klaus.Malorny@knipp.de Wed Jun 8 09:21:17 2011 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 6E9D521F8475 for ; Wed, 8 Jun 2011 09:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRMjXuE0jMqT for ; Wed, 8 Jun 2011 09:21:16 -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 106E621F846C for ; Wed, 8 Jun 2011 09:21:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 83FC147; Wed, 8 Jun 2011 18:21:06 +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 h86G4ieIeqyC; Wed, 8 Jun 2011 18:21:01 +0200 (MESZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 0503831; Wed, 8 Jun 2011 18:21:01 +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 p58GKuM7012981; Wed, 8 Jun 2011 18:20:57 +0200 (MESZ) Message-ID: <4DEFA16A.5050300@knipp.de> Date: Wed, 08 Jun 2011 18:20:58 +0200 From: Klaus Malorny User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0a1) Gecko/20110606 Thunderbird/7.0a1 MIME-Version: 1.0 To: Andrew Sullivan References: <4DEF29D9.10706@publisher.de> <4DEF4839.4090703@knipp.de> <20110608133133.GA45314@shinkuro.com> In-Reply-To: <20110608133133.GA45314@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: provreg@ietf.org Subject: Re: [provreg] Lists and EPP 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: Wed, 08 Jun 2011 16:21:17 -0000 On 08/06/11 15:31, Andrew Sullivan wrote: > On Wed, Jun 08, 2011 at 12:00:25PM +0200, Klaus Malorny wrote: > >> However, generally, a reporting mechanism could be done in an >> incremental way, so that it even could be implemented in EPP: > > Why do you want to Extend the protocol so that it's no longer even > about Provisioning? > > I can see a possibly useful extension that requests a report be > generated. That is, like other things in EPP, one can request that > something be provisioned (in this case, a report). But the response > to that should not be a long list of domains in-protocol, I think. > EPP is poorly structured for that sort of bulk operation, on purpose. > > A > Hi Andrew, I understand the criticism and I am actually ambivalent about such an approach. My posting was just to point out that there is a middle course between having no list and a full list, just from a technical (and not philosophical) perspective. But generally, where to draw the line regarding the functionality? Why is the retrieval of the contents of the the registrar's repository at the registry not part of the provisioning? With the same argument you could argue that the domain:info command is superfluous in most of the cases -- most of the data you should have in your own database. But likely nobody would consider to remove this command from the protocol. I think that a registrar-registry protocol should cover the whole technical interaction between the two parties. Any kind of communication besides this protocol, including downloading reports from FTP servers, reduces the value of the protocol. On the other hand, this requirement collides with a general demand, the frugality of a protocol -- once I read the nice sentence "don't reason about what you can add to a protocol, but what you can remove from it" (or correspondingly). The balance needs to be found. Regards, Klaus From fobispo@isc.org Wed Jun 8 09:49:42 2011 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 3B2CA11E819C for ; Wed, 8 Jun 2011 09:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrU5JDNUCcLH for ; Wed, 8 Jun 2011 09:49:41 -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 0FE5A11E8116 for ; Wed, 8 Jun 2011 09:49:41 -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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 600E55F98B6; Wed, 8 Jun 2011 16:49:12 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [192.168.255.17] (c-24-7-36-20.hsd1.ca.comcast.net [24.7.36.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 41F4A216C7B; Wed, 8 Jun 2011 16:49:10 +0000 (UTC) (envelope-from fobispo@isc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Francisco Obispo In-Reply-To: <4DEFA16A.5050300@knipp.de> Date: Wed, 8 Jun 2011 09:49:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7654F3E9-A536-44C6-9313-531E91B31087@isc.org> References: <4DEF29D9.10706@publisher.de> <4DEF4839.4090703@knipp.de> <20110608133133.GA45314@shinkuro.com> <4DEFA16A.5050300@knipp.de> To: Klaus Malorny X-Mailer: Apple Mail (2.1084) Cc: provreg@ietf.org Subject: Re: [provreg] Lists and EPP 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: Wed, 08 Jun 2011 16:49:42 -0000 I really think that there should be an extension to define such = functionality, but it should be a policy issue whether it is enabled or = not. It's exactly the same case as the domain:check command. there's = currently no limit on how many domain names can be queried (well = technically 2^32 - 4 bytes long with the EPP over TCP transport) with a = single XML document. Some registries limit the number of domain:checks a registrar can = perform within a certain period of time, and that's the way the deal = with this problem. Others limit the total size of the XML payload, etc.=20 We can probably work around the issues that have been surfaced in this = list, specially if there is consensus that this is needed. The technical = barriers, can be worked out. On Jun 8, 2011, at 9:20 AM, Klaus Malorny wrote: > On 08/06/11 15:31, Andrew Sullivan wrote: >> On Wed, Jun 08, 2011 at 12:00:25PM +0200, Klaus Malorny wrote: >>=20 >>> However, generally, a reporting mechanism could be done in an >>> incremental way, so that it even could be implemented in EPP: >>=20 >> Why do you want to Extend the protocol so that it's no longer even >> about Provisioning? >>=20 >> I can see a possibly useful extension that requests a report be >> generated. That is, like other things in EPP, one can request that >> something be provisioned (in this case, a report). But the response >> to that should not be a long list of domains in-protocol, I think. >> EPP is poorly structured for that sort of bulk operation, on purpose. >>=20 >> A >>=20 >=20 >=20 > Hi Andrew, >=20 > I understand the criticism and I am actually ambivalent about such an = approach. My posting was just to point out that there is a middle course = between having no list and a full list, just from a technical (and not = philosophical) perspective. >=20 > But generally, where to draw the line regarding the functionality? Why = is the retrieval of the contents of the the registrar's repository at = the registry not part of the provisioning? With the same argument you = could argue that the domain:info command is superfluous in most of the = cases -- most of the data you should have in your own database. But = likely nobody would consider to remove this command from the protocol. >=20 > I think that a registrar-registry protocol should cover the whole = technical interaction between the two parties. Any kind of communication = besides this protocol, including downloading reports from FTP servers, = reduces the value of the protocol. >=20 > On the other hand, this requirement collides with a general demand, = the frugality of a protocol -- once I read the nice sentence "don't = reason about what you can add to a protocol, but what you can remove = from it" (or correspondingly). The balance needs to be found. >=20 > Regards, >=20 > Klaus > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg Francisco Obispo=20 Hosted@ Programme Manager email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC Key fingerprint =3D 532F 84EB 06B4 3806 D5FA 09C6 463E 614E B38D B1BE From ajs@anvilwalrusden.com Wed Jun 8 10:02:12 2011 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 717B911E8152 for ; Wed, 8 Jun 2011 10:02:12 -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=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHUxNIf9poWB for ; Wed, 8 Jun 2011 10:02:11 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id AE8DA11E8116 for ; Wed, 8 Jun 2011 10:02:11 -0700 (PDT) Received: from shinkuro.com (external.shinkuro.com [66.92.164.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id D12361ECB42A for ; Wed, 8 Jun 2011 17:02:09 +0000 (UTC) Date: Wed, 8 Jun 2011 13:02:09 -0400 From: Andrew Sullivan To: provreg@ietf.org Message-ID: <20110608170208.GG45314@shinkuro.com> References: <4DEF29D9.10706@publisher.de> <4DEF4839.4090703@knipp.de> <20110608133133.GA45314@shinkuro.com> <4DEFA16A.5050300@knipp.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DEFA16A.5050300@knipp.de> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [provreg] Lists and EPP 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: Wed, 08 Jun 2011 17:02:12 -0000 On Wed, Jun 08, 2011 at 06:20:58PM +0200, Klaus Malorny wrote: > But generally, where to draw the line regarding the functionality? > Why is the retrieval of the contents of the the registrar's > repository at the registry not part of the provisioning? With the > same argument you could argue that the domain:info command is > superfluous in most of the cases -- most of the data you should have > in your own database. But likely nobody would consider to remove > this command from the protocol. Right. My real objection is that the protocol is designed to be "retail" rather than "wholesale". That is, most of the protocol (actually, I can't think of an exception) is intended to deal with one object at a time. A report of the proposed kind would return not one object, but instead a set of other objects. This is also why I think it would be fine to define a report object to be provisioned: you make the provisioning request, and get back your answer (I would imagine it would be a URI with the location the report will be, and the validity period -- perhaps "available by" and "expires on", both timestamps). This maintains the model of working on one object at a time. I suppose the return would also include a report identifier, so that you could use the poll queue to find out when your report was ready, if you wanted. A -- Andrew Sullivan ajs@anvilwalrusden.com From JGould@verisign.com Wed Jun 8 10:17:55 2011 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 AA9D021F8584 for ; Wed, 8 Jun 2011 10:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.684 X-Spam-Level: X-Spam-Status: No, score=-5.684 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cju6ue-JeI8R for ; Wed, 8 Jun 2011 10:17:54 -0700 (PDT) Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0929621F8582 for ; Wed, 8 Jun 2011 10:17:53 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKTe+uwLY3OEptt6fKTCIJVcOF3ILRPlpG@postini.com; Wed, 08 Jun 2011 10:17:54 PDT Received: from dul1wnexcn04.vcorp.ad.vrsn.com (dul1wnexcn04.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id p58HHpra003190; Wed, 8 Jun 2011 13:17:51 -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); Wed, 8 Jun 2011 13:17:51 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.01.0270.001; Wed, 8 Jun 2011 13:17:50 -0400 From: "Gould, James" To: Andrew Sullivan , "provreg@ietf.org" Thread-Topic: [provreg] Lists and EPP Thread-Index: AQHMJbRXf9xX6h9w4UqobGsEUTNhE5SzcSYAgAAMRYCAADr/AIAAL1QAgAALgoD//77/ug== Date: Wed, 8 Jun 2011 17:17:50 +0000 Message-ID: References: <4DEF29D9.10706@publisher.de> <4DEF4839.4090703@knipp.de> <20110608133133.GA45314@shinkuro.com> <4DEFA16A.5050300@knipp.de>,<20110608170208.GG45314@shinkuro.com> In-Reply-To: <20110608170208.GG45314@shinkuro.com> 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: 08 Jun 2011 17:17:51.0491 (UTC) FILETIME=[FF2CB530:01CC25FF] Subject: Re: [provreg] Lists and EPP 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: Wed, 08 Jun 2011 17:17:55 -0000 Like Andrew I view EPP as a provisioning protocol for one or a small set of= objects. Reports already serve the purpose of providing a full inventory = of Registrar objects and their relationships. Although EPP could be used t= o support the delivery of reports I don't believe that it was designed for = it and I don't believe that it's appropriate to do so from the provisioning= system. The EPP provisioning systems are setup for provisioning activity = where generating a response of thousands to millions of records is out of s= cope. The systems for the generation and availability of reports are desig= ned for bulk data like what has been discussed. Let's not try to fit the r= ound peg into the EPP square hole. =0A= =0A= ________________________________________=0A= From: provreg-bounces@ietf.org [provreg-bounces@ietf.org] on behalf of Andr= ew Sullivan [ajs@anvilwalrusden.com]=0A= Sent: Wednesday, June 08, 2011 1:02 PM=0A= To: provreg@ietf.org=0A= Subject: Re: [provreg] Lists and EPP=0A= =0A= On Wed, Jun 08, 2011 at 06:20:58PM +0200, Klaus Malorny wrote:=0A= =0A= > But generally, where to draw the line regarding the functionality?=0A= > Why is the retrieval of the contents of the the registrar's=0A= > repository at the registry not part of the provisioning? With the=0A= > same argument you could argue that the domain:info command is=0A= > superfluous in most of the cases -- most of the data you should have=0A= > in your own database. But likely nobody would consider to remove=0A= > this command from the protocol.=0A= =0A= Right. My real objection is that the protocol is designed to be=0A= "retail" rather than "wholesale". That is, most of the protocol=0A= (actually, I can't think of an exception) is intended to deal with one=0A= object at a time. A report of the proposed kind would return not one=0A= object, but instead a set of other objects.=0A= =0A= This is also why I think it would be fine to define a report object to=0A= be provisioned: you make the provisioning request, and get back your=0A= answer (I would imagine it would be a URI with the location the report=0A= will be, and the validity period -- perhaps "available by" and=0A= "expires on", both timestamps). This maintains the model of working=0A= on one object at a time. I suppose the return would also include a=0A= report identifier, so that you could use the poll queue to find out=0A= when your report was ready, if you wanted.=0A= =0A= A=0A= =0A= --=0A= Andrew Sullivan=0A= ajs@anvilwalrusden.com=0A= _______________________________________________=0A= provreg mailing list=0A= provreg@ietf.org=0A= https://www.ietf.org/mailman/listinfo/provreg=0A= From JGould@verisign.com Wed Jun 8 10:29:27 2011 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 D7E2C11E8104 for ; Wed, 8 Jun 2011 10:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.692 X-Spam-Level: X-Spam-Status: No, score=-5.692 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olH6azHBDePf for ; Wed, 8 Jun 2011 10:29:26 -0700 (PDT) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by ietfa.amsl.com (Postfix) with ESMTP id 3806E11E8076 for ; Wed, 8 Jun 2011 10:29:26 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKTe+xdMTclAZ0bf98NdqXY77207CxHo4k@postini.com; Wed, 08 Jun 2011 10:29:26 PDT Received: from dul1wnexcn04.vcorp.ad.vrsn.com (dul1wnexcn04.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id p58HTNjj003779; Wed, 8 Jun 2011 13:29:23 -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); Wed, 8 Jun 2011 13:29:23 -0400 Received: from BRN1WNEXCAS02.vcorp.ad.vrsn.com (10.173.152.206) by brn1wnexcas01.vcorp.ad.vrsn.com (10.173.152.205) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 8 Jun 2011 13:29:22 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.01.0270.001; Wed, 8 Jun 2011 13:29:22 -0400 From: "Gould, James" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Edward Lewis Thread-Topic: [provreg] Too much 'E'? was Re: Lists and EPP Thread-Index: AQHMJeMpxoVxe0R7p0O8ftDcTJkyq5SzyPWA///sDho= Date: Wed, 8 Jun 2011 17:29:22 +0000 Message-ID: References: <4DEF29D9.10706@publisher.de> <88F220D2-4084-41AF-BA59-3944AA4EA8E2@rfc1035.com> <7C33C30D-12F2-48BA-B937-4305E9EE9A13@cisco.com> , In-Reply-To: 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 08 Jun 2011 17:29:23.0286 (UTC) FILETIME=[9B843F60:01CC2601] Cc: "provreg@ietf.org" Subject: Re: [provreg] Too much 'E'? was Re: Lists and EPP 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: Wed, 08 Jun 2011 17:29:28 -0000 I believe that EPP is successful due to it's extensibility. There is littl= e to no way to define a single way for a registry to function which natural= ly leads to custom extensions. Without the ability to extend the protocol = other methods would be used that would be even worse that includes customiz= ing the base protocol itself or utilizing another protocol or method to acc= omplish what is desired. Ideally custom extensions would be opt-in and bac= kward compatible to reduce the impact on clients that don't need or want to= support them. As proposed at the IETF meeting in Anaheim it would be usef= ul to form a working group or a forum for the registries and the registrars= to discuss the existing extensions and planned extensions to identify over= lap and to identify those extensions that should go through the standards p= rocess. The standards process is long and is a lot of effort, so this woul= d not be warranted for every extension but certainty for some. =0A= ________________________________________=0A= From: provreg-bounces@ietf.org [provreg-bounces@ietf.org] on behalf of Patr= ik F=E4ltstr=F6m [paf@cisco.com]=0A= Sent: Wednesday, June 08, 2011 10:32 AM=0A= To: Edward Lewis=0A= Cc: provreg@ietf.org=0A= Subject: Re: [provreg] Too much 'E'? was Re: Lists and EPP=0A= =0A= On 8 jun 2011, at 15.47, Edward Lewis wrote:=0A= =0A= > At 13:32 +0200 6/8/11, Patrik F=E4ltstr=F6m wrote:=0A= >=0A= >> People have, we see now, used the "e" part of epp a bit too much.=0A= >=0A= > Can you quantify this? (Asking out of curiosity.) As in, has there been= a failure in the protocol? Has the goal of interoperability failed?=0A= =0A= Yes. I claim that have failed from some point of view. The protocol is inte= roperable, but what you transfer inside the protocol is different.=0A= =0A= Just look at Net::DRI in Perl and you see that every TLD have their own ext= ension. They have their own rules for for example how a domain name is to b= e written (do they accept [a-z] only, or [a-zA-Z]?). Etc...=0A= =0A= I think personally it is because all development of the protocol, and the e= xtensions, are made by the registries, and not enough input from registrars= which are the ones that today have to pay the burden of what I call non-in= teroperability.=0A= =0A= Hey, some registries do not even release their specification unless you pay= to become a registrar!=0A= =0A= Yes, different business models exists for the registries, but I do not see = such diversity is needed as exists today in for example the epp specs for t= he various TLDs.=0A= =0A= > Between 2009 and 2010 I poked into EPP 2.0 and found that everyone was ha= ppy with EPP 1.0 and the plethora of extensions, especially with Patrick Me= vzek (I believe) has implemented the bulk of them in one distribution.=0A= =0A= Who are everyone? How many registrars did you talk with that actually have = implemented epp from ground up that have connections with say 5-10 differen= t registries where a minority are gTLDs?=0A= =0A= >> And I dare to say that as I as Area Director when epp was invented could= =0A= >> have pushed back more, but I did not. So I blame myself.=0A= >=0A= > As one of the co-chairs, I'm willing to pass the blame on. ;)=0A= =0A= Ha ha ha!=0A= =0A= > At 13:55 +0200 6/8/11, Patrik F=E4ltstr=F6m wrote:=0A= >=0A= >> So yes, we needed extensions, I just think registries could have done be= tter=0A= >> if they coordinated a bit more the standardization of the extensions, in= stead=0A= >> of creating one epp extension per registry/domain name combination.=0A= >>=0A= >> To conclude: I agree that epp is probably not the most efficient protoco= l to=0A= >> do sync:ing, but I rather see one syncing extension than "one per regist= ry".=0A= >> That was my (only) point.=0A= >=0A= > I continued in the thread and found this.=0A= >=0A= > I thought the same as you expressed when I did some organization for a no= n-BoF at the Anaheim IETF. Architecturally speaking, I had some misgivings= about the path EPP had taken. From March 2010 until May 2010 some efforts= ramped up as a result of the IETF-related meeting, including a new mailing= list started called regops. In early May, in a CENTR Tech meeting some pr= eliminary results were presented - mostly the estimate of what it would tak= e to "fix" EPP. This presentation was a follow up to a discussion during th= e October 2009 CENTR Tech meeting that kind of kicked off this short study.= =0A= >=0A= > The discussion at the May 2009 CENTR Tech meeting came down to "okay, wel= l, EPP 1.0 is sufficient."=0A= =0A= CENTR is biased to registries.=0A= =0A= > I took this to mean - in the operations world, EPP is just fine. Operato= rs are satisfied that there is code to do all the versions needed. To an o= perator having two different "redemption grace period" extensions, one for = COM and one for BIZ, is not a problem.=0A= =0A= Yes, it IS a problem.=0A= =0A= To have one extension for every TLD, that create a nXm matrix of number of = extensions times number of TLDs.=0A= =0A= > Maybe as an architect it sounds ugly - but then who are protocols built f= or, the architects or the operators?=0A= >=0A= > After that meeting I abandoned any upgrade/update to EPP and learned to l= ive with the way it is. Code rules, specs aren't as important.=0A= =0A= And I think you made the correct decision. Or you would go mad! ;-)=0A= =0A= Patrik=0A= =0A= _______________________________________________=0A= provreg mailing list=0A= provreg@ietf.org=0A= https://www.ietf.org/mailman/listinfo/provreg=0A= From provreg@contact.dotandco.com Wed Jun 8 11:14:40 2011 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 3EB1021F84F7 for ; Wed, 8 Jun 2011 11:14:40 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1kvA5xNOLE3 for ; Wed, 8 Jun 2011 11:14:39 -0700 (PDT) Received: from mail.dotandco.com (mail.dotandco.com [IPv6:2001:470:1f13:4c2:74aa:293f:3e3d:c181]) by ietfa.amsl.com (Postfix) with ESMTP id 950C921F849E for ; Wed, 8 Jun 2011 11:14:38 -0700 (PDT) Received: from triglav.dotandco.com (localhost.localdomain [127.0.0.1]) by mail.dotandco.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p58IEWdY008981 for ; Wed, 8 Jun 2011 20:14:32 +0200 Received: (from patrick@localhost) by triglav.dotandco.com (8.14.3/8.14.3/Submit) id p58IEWlR008979 for provreg@ietf.org; Wed, 8 Jun 2011 20:14:32 +0200 X-Authentication-Warning: triglav.dotandco.com: patrick set sender to provreg@contact.dotandco.com using -f Date: Wed, 8 Jun 2011 20:14:30 +0200 From: Patrick Mevzek To: provreg@ietf.org Message-ID: <20110608181430.GI6108@home.patoche.org> References: <4DEF29D9.10706@publisher.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DEF29D9.10706@publisher.de> Organization: Dot And Co User-Agent: Mutt/1.5.20 (2009-06-14) X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-3.0 (mail.dotandco.com [127.0.0.1]); Wed, 08 Jun 2011 20:14:33 +0200 (CEST) Subject: Re: [provreg] Lists and EPP 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: Wed, 08 Jun 2011 18:14:40 -0000 Ulrich Wisser 2011-06-08 10:17 > one of the first question I get everytime I meet registrars is > > How can I get a list of all my domains? [..] > I believe a list extension would be really helpful. Due to system > load a registry might need to make some policies about usage but it > would make live easier for registries and registrars. Having been in touch with various registrars dealing with multiple registries, I can see that as a pattern too, so it seems to me worthwhile to pursue. I think we can argue a lot about if this matches EPP goals or not, however among registries one of the only thing really standardized today is EPP. Whois is not, DAS is not, access to recently released domain names is not, registrars reports access is not, etc... As much as it saddens me, IRIS seems to be dead or close to it, specifically now with the creation of the IETF WEIRDS non working group, and having ICANN and ARIN pushing a lot towards REST and against IRIS (for reasons that I do not believe to be technically sound). So investing work to see how this can be done over IRIS would be probably a waste of time or at least registries/registrars should start using IRIS for D-CHECK and then extend it. This leaves us with EPP, as we know today with many extensions doing the same thing, probably due to the NIH syndrom, and as others have said because there is little cooperation from registrars. EPP could be seen as a viable solution. Otherwise everyone is doing the same thing in a different way. And I think there are ways to accomodate SLAs and constraints like that. First, such reports do not need to be realtime. Most often, their content corresponds to the previous day state or even before. So registries could implement that using another DB to offload work and guarantee consistency. I could see such exchange : - registrars ask for some report: here we would need to define what kind of reports, what kind of filters (if any) & constraints, etc. - the registry could reply back immediately with an 1001 return code, so that the report generation would be a background task of low priority that would be done when possible. when the generation is complete, the registry would add a notification message in the registrar queue. It can of course include just an URI as other have suggested, but I'm not sure it is the best way. The report results could be chunked (in slices to be determined by registry policy) and available as registry messages to be fetched by the registrar. If registries/registrars fear the mix of registry notifications messages related to day to day business and report retrieval, registries could have a separate EPP server just for reports (or a separate set of registrars credentials just for that), so that at least registrars could use the same code, just change the connecting parameters. But in both cases we would need to precisely define the content/format of the report, and again maybe trying to accomodate as many cases as possible as seen today and/or defining a way to easily extend things without breaking other implementations... as it has been done in EPP. -- Patrick Mevzek From ebw@nic-naa.net Wed Jun 8 16:38:33 2011 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 E6BCA21F8514 for ; Wed, 8 Jun 2011 16:38:33 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjS3KKKrUI+f for ; Wed, 8 Jun 2011 16:38:33 -0700 (PDT) Received: from nic-naa.net (nic-naa.net [65.99.1.132]) by ietfa.amsl.com (Postfix) with ESMTP id 9981821F8513 for ; Wed, 8 Jun 2011 16:38:33 -0700 (PDT) Received: from nic-naa.net (localhost [127.0.0.1]) by nic-naa.net (8.14.4/8.14.4) with ESMTP id p58Le3Rm063065; Wed, 8 Jun 2011 17:40:03 -0400 (EDT) (envelope-from ebw@nic-naa.net) Message-Id: <201106082140.p58Le3Rm063065@nic-naa.net> From: brunner@nic-naa.net To: paf@cisco.com Date: Wed, 08 Jun 2011 17:40:03 -0400 Sender: ebw@nic-naa.net Cc: provreg@ietf.org Subject: Re: [provreg] Lists and EPP 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: Wed, 08 Jun 2011 23:38:34 -0000 [resent, moderator feel free to ignore prior version from an alternate mailbox.] > I dare to say that as I as Area Director when epp was invented could > have pushed back more, but I did not. So I blame myself. Before you blame yourself, the fundamental choices were never available to the ADs to alter -- XML as the syntax, client-server as the event model, with the universe of communication restricted to registrars and a registry, in a design univers of 6 registries and 60 registrars. However, if you're inviting blame for errors as AD, your personal decision to prevent XML-over-SMTP meant that a lot of registries and registrars in cc-land, where the 3pm drop never presents a race condition, had a transport predicate you thought necessary and I thought unnecessary. If Harald is around he can take the blame for his binary valued "do not publish" mechanism as a putatively useful alternative to data collection policy announcements. With no criticism to Scott, the importance of the VGRS inventory to the ICANN registrars really made any design choices that attempted to extend the 6+60 model were doomed. We didn't get: o containers, so glops of contact, host and domain data could be flushed in either direction; o symmetric event model, so regsitries could notify registrars of things like "your hair is on fire", other than via polling; o generalization of the endpoints, so escrow could be implemented via EPP; o generalization of the endpoints, so registrars could proxy to accredited registrars for registries they lack accreditation (cause the world was com/net/org/biz/info/foo) via EPP; o (and this is not a criticism of anything to time and tech) the means to elegantly exend the XML syntax (the "X" is over-rated); I'm sure I've forgotten many things that are useful for some notion of how a provisioning protocl that doesn't have the 6+60/C-S/tcp/race model set of restrictions. And mistakes are normal, so this isn't a harsh criticism, but the set of pre-IETF constraints has had consequences, and may have more consequences as the model grows beyond 6+60 to more 3166 parties and all the 201x new adds. Eric From jothan@gmail.com Wed Jun 8 17:43:09 2011 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 25B3F21F852A for ; Wed, 8 Jun 2011 17:43:09 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdwFQmYoS6fC for ; Wed, 8 Jun 2011 17:43:04 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id AEC9D21F852F for ; Wed, 8 Jun 2011 17:43:04 -0700 (PDT) Received: by vws12 with SMTP id 12so1136177vws.31 for ; Wed, 08 Jun 2011 17:43:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=L6OGe8m/b6q3Chv6eG8txs/M98hYUTPcIxOPCrnqDRY=; b=tddpsSOl7/tbeNlG9E1Fs0PrPoxZSTBpaXcRhfrtJ0J417XuFsg18RXN0c/EjDBUMG aDLATBSAypubjmHrOwA711mBp1Ypy0ZsxpXSJvgdj22Sd7u1KxRpnH4iMhYlE10soior A+J6E2dHGpAOK8FkEbY+C4MRTG49dnNcBl4N4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=bToJeU/fMGHRugu1urabYyeQWPFUJOyZDF9ftER/CtNX3bog8KrRgTluZd9erqvELU W3KsnWpzS4dB7XZG4kOZoHILDj8Bnsha5EAM+XMa2M3tkPwfx11ojsz827HuEauwUCl4 EaB2m9AX0UwB8s4PFBLMecVc7a4iHRFKzYmSY= Received: by 10.52.173.195 with SMTP id bm3mr158981vdc.17.1307580184053; Wed, 08 Jun 2011 17:43:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.188.231 with HTTP; Wed, 8 Jun 2011 17:42:24 -0700 (PDT) In-Reply-To: <201106082140.p58Le3Rm063065@nic-naa.net> References: <201106082140.p58Le3Rm063065@nic-naa.net> From: Jothan Frakes Date: Wed, 8 Jun 2011 17:42:24 -0700 Message-ID: To: provreg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [provreg] Lists and EPP 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: Thu, 09 Jun 2011 00:43:09 -0000 In a practical sense, I think that the point Jim raised about the impact of GoDaddy requesting their .COM list is one that has a scaling concern. Registries have a web or ftp portal for the reports and materials that are not going to flow through the EPP system in its current form. There's also zone file access and ICANN reports or other types of integrations or systems that a registry operates that are isolated from the EPP system because they can be generated from read-only or reporting snapshots of the databases and not adversely impact the fluidity and pace of responses to the rest of the users. There are simply some things that are more wisely served out of band. With respect to the implementation variance on EPP that I've witnessed over the years... It seems to me that no matter what, there will be different implementations. I'd like to drop in the comment that while this is a technical discussion, we should be mindful that it not be so clinical a discussion that we arrive at something obtuse to meeting the need of the user. I'd infer that the registrar is the user here. A registrar wants to clone as much code and deal with as little delta or re-write as possible, so that they can quickly put a TLD in place and make sure their customer can renew and manage their domain name. This is an area that the incumbent registries have some significant advantage over new ones. If someone's already tied into Afilias for .info or .org, or Neustar for .biz or .co, there's a lot less of a scope to adding another TLD at that registry as opposed to some new setup. ccTLDs are trying to conform to EPP (predominantly this is to have wider adoption in the ICANN registrar world), but they're stuffing their implementations with each of their policy/business logic. Sometimes it is an obtuse fit. This pertains to expiry, grace periods, registrant validation, or other areas of delta that exist (ie Nominet is 2y units (vs 1y) add/renew with max 2 year (vs 10y max)). Each has its own flavor. Some registries like DE offer monthly domains. I am not suggesting that EPP is as good as it will ever get, but wherever we collectively can make provisioning for registrars as consistent and seamless across as many implementations as possible, I think we'd have the reasonable grounds to claim some victory. My basis for recommendation of 'simplimentation' is the 201X newTLD round. We're about to start to see an onslaught of articles where registrars are going to talk about how they can only assimilate 1 TLD per month or perhaps 3 in 2 months. Registrars are also going to have to make pragmatic choices about a variety of factors like the integration time and weigh that against anticipated demand or other factors when they plan out what TLD in what order. In the presence of the alleged thundering herd of TLDs, registrars will have to pick and choose. For a newco registry service provider that has fewer institutional registrar integrations, the more conformity to other existing implementations means the ability to tick the box next to 'can re-use existing code' - and this dissolves resistance points that can leave the TLD(s) on your platform sitting patiently awaiting integration while other more simple ones are getting quickly added at registrars. I realize this sounds more like it came from the sales or business development lines than the technical side of the house, but it really is and will be an important factor that should be considered. -Jothan On Wed, Jun 8, 2011 at 2:40 PM, wrote: > > [resent, moderator feel free to ignore prior version from an alternate > =A0mailbox.] > >> I dare to say that as I as Area Director when epp was invented could >> have pushed back more, but I did not. So I blame myself. > > Before you blame yourself, the fundamental choices were never available > to the ADs to alter -- XML as the syntax, client-server as the event > model, with the universe of communication restricted to registrars and > a registry, in a design univers of 6 registries and 60 registrars. > > However, if you're inviting blame for errors as AD, your personal > decision to prevent XML-over-SMTP meant that a lot of registries and > registrars in cc-land, where the 3pm drop never presents a race > condition, had a transport predicate you thought necessary and I thought > unnecessary. > > If Harald is around he can take the blame for his binary valued "do > not publish" mechanism as a putatively useful alternative to data > collection policy announcements. > > With no criticism to Scott, the importance of the VGRS inventory to the > ICANN registrars really made any design choices that attempted to extend > the 6+60 model were doomed. > > We didn't get: > =A0 =A0 =A0 =A0o containers, so glops of contact, host and domain data > could be flushed in either direction; > =A0 =A0 =A0 =A0o symmetric event model, so regsitries could notify regist= rars > of things like "your hair is on fire", other than via polling; > =A0 =A0 =A0 =A0o generalization of the endpoints, so escrow could be impl= emented > via EPP; > =A0 =A0 =A0 =A0o generalization of the endpoints, so registrars could pro= xy to > accredited registrars for registries they lack accreditation (cause the > world was com/net/org/biz/info/foo) via EPP; > =A0 =A0 =A0 =A0o (and this is not a criticism of anything to time and tec= h) the > means to elegantly exend the XML syntax (the "X" is over-rated); > > I'm sure I've forgotten many things that are useful for some notion of > how a provisioning protocl that doesn't have the 6+60/C-S/tcp/race model > set of restrictions. > > And mistakes are normal, so this isn't a harsh criticism, but the set > of pre-IETF constraints has had consequences, and may have more consequen= ces > as the model grows beyond 6+60 to more 3166 parties and all the 201x new > adds. > > Eric > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg > From paf@cisco.com Wed Jun 8 21:43:54 2011 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 4C50D21F85C6 for ; Wed, 8 Jun 2011 21:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.179 X-Spam-Level: X-Spam-Status: No, score=-10.179 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7G-qNxPWWcG for ; Wed, 8 Jun 2011 21:43:53 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 58FC721F85C3 for ; Wed, 8 Jun 2011 21:43:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paf@cisco.com; l=6505; q=dns/txt; s=iport; t=1307594632; x=1308804232; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=l6o8MFSbYJ0Xre94n3/+PkF/JVRTPR1kkf2eVXRmDgI=; b=jTdbVOfDGOa8JDQ6eqj0te94XO0+J9+pFCIldTzwANK+Tt9PrHJ/sW+m 4IeW4BdZgvNHnyvP/J7CJ+3F+Vt7C3WwwL3Yv4fdvN51EyiBd64Q+2Oh0 U8csDSmBMY0+79bg7WtCFrpRAX1/mrXvnQpZQvt12Pv1BL+IXTPJFLNno M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEtP8E2Q/khN/2dsb2JhbABSpjp3iHGgep4ghiMEkSqPVA X-IronPort-AV: E=Sophos;i="4.65,340,1304294400"; d="scan'208";a="93027860" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 09 Jun 2011 04:43:47 +0000 Received: from ams3-vpn-dhcp7422.cisco.com (ams3-vpn-dhcp7422.cisco.com [10.61.92.253]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p594hlIF009422; Thu, 9 Jun 2011 04:43:47 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Thu, 9 Jun 2011 06:43:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8C81E796-D699-436E-9B28-3F0EF72B0D1E@cisco.com> References: <201106082140.p58Le3Rm063065@nic-naa.net> To: Jothan Frakes X-Mailer: Apple Mail (2.1084) Cc: provreg@ietf.org Subject: Re: [provreg] Lists and EPP 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: Thu, 09 Jun 2011 04:43:54 -0000 Jothan, I think you are right on the spot! Patrik On 9 jun 2011, at 02.42, Jothan Frakes wrote: > In a practical sense, I think that the point Jim raised about the > impact of GoDaddy requesting their .COM list is one that has a scaling > concern. Registries have a web or ftp portal for the reports and > materials that are not going to flow through the EPP system in its > current form. There's also zone file access and ICANN reports or > other types of integrations or systems that a registry operates that > are isolated from the EPP system because they can be generated from > read-only or reporting snapshots of the databases and not adversely > impact the fluidity and pace of responses to the rest of the users. >=20 > There are simply some things that are more wisely served out of band. >=20 > With respect to the implementation variance on EPP that I've witnessed > over the years... It seems to me that no matter what, there will be > different implementations. >=20 > I'd like to drop in the comment that while this is a technical > discussion, we should be mindful that it not be so clinical a > discussion that we arrive at something obtuse to meeting the need of > the user. I'd infer that the registrar is the user here. >=20 > A registrar wants to clone as much code and deal with as little delta > or re-write as possible, so that they can quickly put a TLD in place > and make sure their customer can renew and manage their domain name. > This is an area that the incumbent registries have some significant > advantage over new ones. If someone's already tied into Afilias for > .info or .org, or Neustar for .biz or .co, there's a lot less of a > scope to adding another TLD at that registry as opposed to some new > setup. >=20 > ccTLDs are trying to conform to EPP (predominantly this is to have > wider adoption in the ICANN registrar world), but they're stuffing > their implementations with each of their policy/business logic. > Sometimes it is an obtuse fit. This pertains to expiry, grace > periods, registrant validation, or other areas of delta that exist (ie > Nominet is 2y units (vs 1y) add/renew with max 2 year (vs 10y max)). > Each has its own flavor. Some registries like DE offer monthly > domains. >=20 > I am not suggesting that EPP is as good as it will ever get, but > wherever we collectively can make provisioning for registrars as > consistent and seamless across as many implementations as possible, I > think we'd have the reasonable grounds to claim some victory. >=20 > My basis for recommendation of 'simplimentation' is the 201X newTLD > round. We're about to start to see an onslaught of articles where > registrars are going to talk about how they can only assimilate 1 TLD > per month or perhaps 3 in 2 months. Registrars are also going to have > to make pragmatic choices about a variety of factors like the > integration time and weigh that against anticipated demand or other > factors when they plan out what TLD in what order. In the presence of > the alleged thundering herd of TLDs, registrars will have to pick and > choose. >=20 > For a newco registry service provider that has fewer institutional > registrar integrations, the more conformity to other existing > implementations means the ability to tick the box next to 'can re-use > existing code' - and this dissolves resistance points that can leave > the TLD(s) on your platform sitting patiently awaiting integration > while other more simple ones are getting quickly added at registrars. >=20 > I realize this sounds more like it came from the sales or business > development lines than the technical side of the house, but it really > is and will be an important factor that should be considered. >=20 > -Jothan >=20 >=20 >=20 >=20 > On Wed, Jun 8, 2011 at 2:40 PM, wrote: >>=20 >> [resent, moderator feel free to ignore prior version from an = alternate >> mailbox.] >>=20 >>> I dare to say that as I as Area Director when epp was invented could >>> have pushed back more, but I did not. So I blame myself. >>=20 >> Before you blame yourself, the fundamental choices were never = available >> to the ADs to alter -- XML as the syntax, client-server as the event >> model, with the universe of communication restricted to registrars = and >> a registry, in a design univers of 6 registries and 60 registrars. >>=20 >> However, if you're inviting blame for errors as AD, your personal >> decision to prevent XML-over-SMTP meant that a lot of registries and >> registrars in cc-land, where the 3pm drop never presents a race >> condition, had a transport predicate you thought necessary and I = thought >> unnecessary. >>=20 >> If Harald is around he can take the blame for his binary valued "do >> not publish" mechanism as a putatively useful alternative to data >> collection policy announcements. >>=20 >> With no criticism to Scott, the importance of the VGRS inventory to = the >> ICANN registrars really made any design choices that attempted to = extend >> the 6+60 model were doomed. >>=20 >> We didn't get: >> o containers, so glops of contact, host and domain data >> could be flushed in either direction; >> o symmetric event model, so regsitries could notify registrars >> of things like "your hair is on fire", other than via polling; >> o generalization of the endpoints, so escrow could be = implemented >> via EPP; >> o generalization of the endpoints, so registrars could proxy = to >> accredited registrars for registries they lack accreditation (cause = the >> world was com/net/org/biz/info/foo) via EPP; >> o (and this is not a criticism of anything to time and tech) = the >> means to elegantly exend the XML syntax (the "X" is over-rated); >>=20 >> I'm sure I've forgotten many things that are useful for some notion = of >> how a provisioning protocl that doesn't have the 6+60/C-S/tcp/race = model >> set of restrictions. >>=20 >> And mistakes are normal, so this isn't a harsh criticism, but the set >> of pre-IETF constraints has had consequences, and may have more = consequences >> as the model grows beyond 6+60 to more 3166 parties and all the 201x = new >> adds. >>=20 >> Eric >> _______________________________________________ >> provreg mailing list >> provreg@ietf.org >> https://www.ietf.org/mailman/listinfo/provreg >>=20 From ebw@nic-naa.net Wed Jun 8 22:13:18 2011 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 6AF77228007 for ; Wed, 8 Jun 2011 22:13:18 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQwiZdVMbPFU for ; Wed, 8 Jun 2011 22:13:17 -0700 (PDT) Received: from nic-naa.net (nic-naa.net [65.99.1.132]) by ietfa.amsl.com (Postfix) with ESMTP id C2450228006 for ; Wed, 8 Jun 2011 22:13:17 -0700 (PDT) Received: from nic-naa.net (localhost [127.0.0.1]) by nic-naa.net (8.14.4/8.14.4) with ESMTP id p593EgQ9065011; Wed, 8 Jun 2011 23:14:42 -0400 (EDT) (envelope-from ebw@nic-naa.net) Message-Id: <201106090314.p593EgQ9065011@nic-naa.net> From: brunner@nic-naa.net To: jothan@gmail.com Date: Wed, 08 Jun 2011 23:14:42 -0400 Sender: ebw@nic-naa.net Cc: provreg@ietf.org Subject: Re: [provreg] Lists and EPP 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: Thu, 09 Jun 2011 05:13:18 -0000 > There's also zone file access and ICANN reports ... The access control models for Zone File access and SRS access are distinct. The sink for connections over which Registry Reports are transported is neither a registry, nor a registrar, nor is the data contained in such reports contact, host, or domain objects. > We're about to start to see an onslaught of articles where > registrars are going to talk about how they can only assimilate 1 TLD > per month or perhaps 3 in 2 months. ... Lack of planning on their part, the difference in temporal density of engineering deltas, even if mere repitition of certification checks with no change of state other than the associated name space and account identifiers from the 2004 and 2001 experiences has been a matter of record for over three years now. Registrars which implemented agile clients had foresight. Eric From paf@cisco.com Wed Jun 8 23:42:47 2011 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 BCDA71F0C36 for ; Wed, 8 Jun 2011 23:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiqeDUNdr0Sa for ; Wed, 8 Jun 2011 23:42:47 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id EA5351F0C35 for ; Wed, 8 Jun 2011 23:42:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paf@cisco.com; l=768; q=dns/txt; s=iport; t=1307601766; x=1308811366; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=F1mJo0EpgJZy3xR1YASSw6LRIGU0USaqRTiKL18lm1k=; b=d4tazEhzeICF5hjCGatLWjCSnAoTwWciuKxdBdWYiE0dpZognxYfC3La IwJVP1soS1HId+lMn63rfFgOka36Uifdw32UdJlm2GopuQfCdlx1Z+LA2 REGvgtNnd11Bczg//Nl4cwndBPqtVA4r4rKCgUVDkZKHyo6ROmXMb6lfN I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQHAJVq8E2tJV2Y/2dsb2JhbABSmAeOMneIcaBGniCGIwSRKo9U X-IronPort-AV: E=Sophos;i="4.65,340,1304294400"; d="scan'208";a="333302208" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-3.cisco.com with ESMTP; 09 Jun 2011 06:42:46 +0000 Received: from dhcp-10-61-96-27.cisco.com (dhcp-10-61-96-27.cisco.com [10.61.96.27]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p596giCU001092; Thu, 9 Jun 2011 06:42:45 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <201106090314.p593EgQ9065011@nic-naa.net> Date: Thu, 9 Jun 2011 08:42:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201106090314.p593EgQ9065011@nic-naa.net> To: brunner@nic-naa.net X-Mailer: Apple Mail (2.1084) Cc: provreg@ietf.org Subject: Re: [provreg] Lists and EPP 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: Thu, 09 Jun 2011 06:42:47 -0000 On 9 jun 2011, at 05.14, brunner@nic-naa.net wrote: > Registrars which implemented agile clients had foresight. It is not that simple... A registrar have one user interface, regardless of whether it is a web = page or API. That exposes a certain business logic to the registrants. The registry then translates the business logic regarding registration, = renewal, transfer etc into the specific logic that the registry in = question require. This implies both changes in the business logic and epp requirements. And in many cases it does not matter how agile clients you = have...because the way renewal works for example, and requirements from = the registry that certain things must be exposed to the registrant and = what not. Patrik From jan@ipclearinghouse.org Wed Jun 8 23:50:58 2011 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 56D081F0C36 for ; Wed, 8 Jun 2011 23:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SAypbJMAcyS for ; Wed, 8 Jun 2011 23:50:57 -0700 (PDT) Received: from arthur.vbchosting.be (62-213-193-90.colo.housingcenter.be [62.213.193.90]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBBF1F0C35 for ; Wed, 8 Jun 2011 23:50:55 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by arthur.vbchosting.be (Postfix) with ESMTP id 7D3ECC8A56 for ; Thu, 9 Jun 2011 06:50:53 +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 kg0CfkNfDfov for ; Thu, 9 Jun 2011 08:50:53 +0200 (CEST) Received: from arthur.vbchosting.be (localhost.localdomain [127.0.0.1]) by arthur.vbchosting.be (Postfix) with ESMTP id F0B77C8044 for ; Thu, 9 Jun 2011 08:50:52 +0200 (CEST) Received: (from apache@localhost) by arthur.vbchosting.be (8.13.8/8.13.8/Submit) id p596oqL4023531; Thu, 9 Jun 2011 08:50:52 +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 www.nexperteam.be with HTTP; Thu, 9 Jun 2011 08:50:52 +0200 (CEST) Message-ID: <35744.94.225.68.235.1307602252.squirrel@www.nexperteam.be> In-Reply-To: References: <201106090314.p593EgQ9065011@nic-naa.net> Date: Thu, 9 Jun 2011 08:50:52 +0200 (CEST) From: "Jan Jansen" To: provreg@ietf.org User-Agent: SquirrelMail/1.4.8-5.el5.centos.3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: [provreg] Lists and EPP 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: Thu, 09 Jun 2011 06:50:58 -0000 Hi all, At the risk of opening a bad can of worms ... An alternative to the 'long' list could be to add a reference to the 'next' object similar to the 'DNSSEC zone walk' way. It preserves the EPP object style and allows to generate a list on the receivers side. On the bad side, it does not provide a unique view as things might change while retrieving the list although I guess that as a registrar you wouldn't care to much if you can do this on a regular base, say once a day or so. It might produce some heavy load on registry systems though. (But then again, we had to think more like registrars and less like registries ?) Fitting a round peg in hexagonal shape hole ? -jan- > On 9 jun 2011, at 05.14, brunner@nic-naa.net wrote: > >> Registrars which implemented agile clients had foresight. > > It is not that simple... > > A registrar have one user interface, regardless of whether it is a web > page or API. That exposes a certain business logic to the registrants. > > The registry then translates the business logic regarding registration, > renewal, transfer etc into the specific logic that the registry in > question require. > > This implies both changes in the business logic and epp requirements. > > And in many cases it does not matter how agile clients you have...because > the way renewal works for example, and requirements from the registry that > certain things must be exposed to the registrant and what not. > > Patrik > > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg > From jothan@gmail.com Wed Jun 8 23:52:35 2011 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 6EAE111E8086 for ; Wed, 8 Jun 2011 23:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFG3qMuUZeNw for ; Wed, 8 Jun 2011 23:52:34 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id CF17A11E807D for ; Wed, 8 Jun 2011 23:52:06 -0700 (PDT) Received: by vxg33 with SMTP id 33so1319532vxg.31 for ; Wed, 08 Jun 2011 23:52:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=omkQW8rfMXevC9KOvtS0elZb3yWXH4dHIf6f3BpqYwA=; b=aURiZyAkbToMZ9cZnFY5yon9c1X9ftLxSIFsBrWbkl659Wzu2TmY5JBADUFQlFw4KP KM5vD0U7NiH1e+cjB8FkJJujdbfAyfQqjh2L9hIZQsQlaYPoi7ZyGJ92Wgk5kvkjDLx1 KL5n/VBNmkNWBP1qfDYGS3fGeIPAF0+YjPph4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=djA40kL5SZ9qkOyj/cJAFZpOYtjCdI8hOR4v4QKP374FDW5d9FsqKa7UR+m4FHNUo/ 48mE3UyPtR/ZNNBaY9DnSZb9jHNQ8CVRWdvKCvHrSUhp73FD3DROu1otCojSeP+U5TFF VL3O9En5rRgAxLd/pYJHWvBN7DYMpvzRcUEdI= Received: by 10.52.182.6 with SMTP id ea6mr476777vdc.217.1307602326074; Wed, 08 Jun 2011 23:52:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.188.231 with HTTP; Wed, 8 Jun 2011 23:51:26 -0700 (PDT) In-Reply-To: References: <201106090314.p593EgQ9065011@nic-naa.net> From: Jothan Frakes Date: Wed, 8 Jun 2011 23:51:26 -0700 Message-ID: To: provreg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [provreg] Lists and EPP 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: Thu, 09 Jun 2011 06:52:35 -0000 I agree the agile client approach is wise. Meanwhile, the registrars that are downstream from registries have to make a lot of changes to accommodate delta between implementation A and implementation B of EPP / Business Logic, etc. Many of the changes present themselves once the developers are in the OT&E wading pool and notice the differences between systems, which planning can't necessarily overcome. These 'opportunities' to address the differences simply present themselves with the need to address them, not unlike a jury summons or a flaming paper bag on the doorstep after a ring of the doorbell. Jothan 2011/6/8 Patrik F=E4ltstr=F6m : > On 9 jun 2011, at 05.14, brunner@nic-naa.net wrote: > >> Registrars which implemented agile clients had foresight. > > It is not that simple... > > A registrar have one user interface, regardless of whether it is a web pa= ge or API. That exposes a certain business logic to the registrants. > > The registry then translates the business logic regarding registration, r= enewal, transfer etc into the specific logic that the registry in question = require. > > This implies both changes in the business logic and epp requirements. > > And in many cases it does not matter how agile clients you have...because= the way renewal works for example, and requirements from the registry that= certain things must be exposed to the registrant and what not. > > =A0 Patrik > > From ulrich@wisser.se Thu Jun 9 03:40:08 2011 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 323D511E80B4 for ; Thu, 9 Jun 2011 03:40: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftR2A19lZDf9 for ; Thu, 9 Jun 2011 03:40:07 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4335611E8077 for ; Thu, 9 Jun 2011 03:40:06 -0700 (PDT) Received: by fxm15 with SMTP id 15so1018176fxm.31 for ; Thu, 09 Jun 2011 03:40:06 -0700 (PDT) Received: by 10.223.74.83 with SMTP id t19mr590255faj.149.1307616005786; Thu, 09 Jun 2011 03:40:05 -0700 (PDT) Received: from ulrich-wissers-macbook-pro.local (gw.iis.se [212.247.14.38]) by mx.google.com with ESMTPS id 11sm596642fax.12.2011.06.09.03.40.04 (version=SSLv3 cipher=OTHER); Thu, 09 Jun 2011 03:40:04 -0700 (PDT) Sender: Ulrich Wisser Message-ID: <4DF0A303.10501@publisher.de> Date: Thu, 09 Jun 2011 12:40:03 +0200 From: Ulrich Wisser User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: provreg@ietf.org References: <201106082140.p58Le3Rm063065@nic-naa.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Lists and EPP 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: Thu, 09 Jun 2011 10:40:08 -0000 Hi, seems I've hit a nerve ... I realize that this extension is not for everyone. But ccTLDs often have very small registrars. And these often do not have the expertise or resources to implement a new sync method for every registry. Maybe a registry would enable this extension only for registrars with less than X domains / contacts / hosts? And as much as other protocols are a better fit, it seems they are as dead. Today only EPP is in wide spread use. There are already list extensions "in the wild". The pressure will only increase. I believe a list functionality is needed. Let's take the opportunity to make a EPPish extension before we get overrun by registry specific extensions. /Ulrich From ebw@nic-naa.net Thu Jun 9 06:41:01 2011 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 86D5F21F8473 for ; Thu, 9 Jun 2011 06:41:01 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Beqp-WFXD1Y9 for ; Thu, 9 Jun 2011 06:41:01 -0700 (PDT) Received: from nic-naa.net (nic-naa.net [65.99.1.132]) by ietfa.amsl.com (Postfix) with ESMTP id CA60421F8472 for ; Thu, 9 Jun 2011 06:41:00 -0700 (PDT) Received: from nic-naa.net (localhost [127.0.0.1]) by nic-naa.net (8.14.4/8.14.4) with ESMTP id p59BgKJK068111; Thu, 9 Jun 2011 07:42:20 -0400 (EDT) (envelope-from ebw@nic-naa.net) Message-Id: <201106091142.p59BgKJK068111@nic-naa.net> From: brunner@nic-naa.net To: liste@publisher.de Date: Thu, 09 Jun 2011 07:42:20 -0400 Sender: ebw@nic-naa.net Cc: provreg@ietf.org Subject: Re: [provreg] Lists and EPP 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: Thu, 09 Jun 2011 13:41:01 -0000 The "scale" claim I'm still mulling on. When I wrote the first ICANN escrow spec (registries) I put in the means for an escrow deposit to span more than a single media capacity, a means also present in the second ICANN escrow spec (registrars), which somebody wrote. So the unboundednes of a "record" (or sequence of grouped XML glop) is at least by the capacity bounds of the transport media (current DVDs are big, but not infinite), and the transmit capacity between the source and sink does determine the limit before the trasmission of an instance of a record must also contain updates to data within that record. But I'm not interested in edge cases of EPP-for-Verisign or EPP-for-GoDaddy, or transport-for-domainers-slamming-the-com-drop-pool, but in the more common problem, for which a registry policy declaration of the maximum size of a unit of data (or the equivalent unerlying database access bandwidth) can be announced to the registrar, just like a dcp. For this, a LIST command semantics and syntax can be specified and implemented and interoperability demonstrated, with the option of using the IETF or any equivalent means of making the specification available without liability to its authors, implementors and eventual users. Based upon limited experience with one registry platform operator's dbms, the LIST command and the LIST response may be sufficienty seperated in time to require more bookkeeping overhead than a mere wait() and the assumption of stream semantics. Eric From JGould@verisign.com Thu Jun 9 07:03:58 2011 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 1D66121F851A for ; Thu, 9 Jun 2011 07:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.988 X-Spam-Level: X-Spam-Status: No, score=-5.988 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RR32mny0Ax+M for ; Thu, 9 Jun 2011 07:03:56 -0700 (PDT) Received: from exprod6og114.obsmtp.com (exprod6og114.obsmtp.com [64.18.1.33]) by ietfa.amsl.com (Postfix) with ESMTP id A395121F8524 for ; Thu, 9 Jun 2011 07:03:53 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob114.postini.com ([64.18.5.12]) with SMTP ID DSNKTfDSx5LMi7XL2PCwxlkSFcn+FFtx+T0l@postini.com; Thu, 09 Jun 2011 07:03:56 PDT Received: from dul1wnexcn04.vcorp.ad.vrsn.com (dul1wnexcn04.vcorp.ad.vrsn.com [10.170.12.139]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id p59E3pID021878; Thu, 9 Jun 2011 10:03:51 -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); Thu, 9 Jun 2011 10:03:51 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.01.0270.001; Thu, 9 Jun 2011 10:03:50 -0400 From: "Gould, James" To: "brunner@nic-naa.net" , "liste@publisher.de" Thread-Topic: [provreg] Lists and EPP Thread-Index: AQHMJppKf9xX6h9w4UqobGsEUTNhE5S1DuCA Date: Thu, 9 Jun 2011 14:03:49 +0000 Message-ID: In-Reply-To: <201106091142.p59BgKJK068111@nic-naa.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <4D76C1439BF5834F86F5532D7CAA2635@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Jun 2011 14:03:51.0186 (UTC) FILETIME=[0F6CDF20:01CC26AE] Cc: "provreg@ietf.org" Subject: Re: [provreg] Lists and EPP 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: Thu, 09 Jun 2011 14:03:58 -0000 Eric, I'm sure that a method could be created to support a bulk list command and response in EPP, but I question whether it is appropriate for EPP. This information is already provided via reports and made available via FTP and via a web application, so what is the driver for adding this to the provisioning channel? Creating an XML response of thousands to millions of records does represent a scalability issue for the server and the client. For bulk data it's best to separate format definition from data, which is why for data escrow I'm not a fan of the use of XML. The same holds true for bulk information. I don't believe it's a good use of the limited provisioning resources to support an unbounded bulk data feed, where the focus should continue to serve the provisioning needs and not the reporting and synchronization needs. -- JG James Gould Principal Software Engineer jgould@Verisign.com 703-948-3271 21345 Ridgetop Circle LS2-2-1 Dulles, VA 20166 VerisignInc.com On 6/9/11 7:42 AM, "brunner@nic-naa.net" wrote: >The "scale" claim I'm still mulling on. When I wrote the first ICANN >escrow >spec (registries) I put in the means for an escrow deposit to span more >than >a single media capacity, a means also present in the second ICANN escrow >spec >(registrars), which somebody wrote. > >So the unboundednes of a "record" (or sequence of grouped XML glop) is at >least by the capacity bounds of the transport media (current DVDs are big, >but not infinite), and the transmit capacity between the source and sink >does determine the limit before the trasmission of an instance of a >record=20 >must also contain updates to data within that record. > >But I'm not interested in edge cases of EPP-for-Verisign or >EPP-for-GoDaddy, >or transport-for-domainers-slamming-the-com-drop-pool, but in the more >common >problem, for which a registry policy declaration of the maximum size of a >unit of data (or the equivalent unerlying database access bandwidth) can >be >announced to the registrar, just like a dcp. > >For this, a LIST command semantics and syntax can be specified and >implemented >and interoperability demonstrated, with the option of using the IETF or >any >equivalent means of making the specification available without liability >to >its authors, implementors and eventual users. > >Based upon limited experience with one registry platform operator's dbms, >the LIST command and the LIST response may be sufficienty seperated in >time >to require more bookkeeping overhead than a mere wait() and the assumption >of stream semantics. > >Eric >_______________________________________________ >provreg mailing list >provreg@ietf.org >https://www.ietf.org/mailman/listinfo/provreg From jothan@gmail.com Thu Jun 9 10:43:29 2011 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 62B5811E8130 for ; Thu, 9 Jun 2011 10:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3sXUBQlbHS2L for ; Thu, 9 Jun 2011 10:43:28 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D871711E812C for ; Thu, 9 Jun 2011 10:43:27 -0700 (PDT) Received: by vws12 with SMTP id 12so1926303vws.31 for ; Thu, 09 Jun 2011 10:43:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=MwJ670JZAHMaXMkTkJxPa8peZTVZENMiKkTVcf9Jnzw=; b=oJdyJpEtGL9idzCmC51xg4tC7Ujkp13h2CQy3KX5vvJDWcwPmwbsLHhXoh7q/6F4aq DWW95wQ6BT6g8dQ1+ZnaGBWJVL/PEl1fXvIzGj3KD2xKjEvlYvazFLSLw+P/ORrVAD4t iUlrOtvpUJn9jOnGEQ/BAQr1WDjOxlBrKkqKw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=tXw9Qbp1qRu6nlLTX3FyC5eTldGCIHjcD6Z9TLR2UQOLIUWWtbIqxhRrgbCiOrdMKm fzOOzF7Sa9/iGkWCSM75DpCkwTUCA7aQrJfdkg68LUp3H/PrVuAvGve3qkAsFAjsK6tS iBJQ3hkxMjofQUQjAYNqtoZKJqAH4O7Rp3tks= Received: by 10.52.173.195 with SMTP id bm3mr1412474vdc.17.1307641407162; Thu, 09 Jun 2011 10:43:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.188.231 with HTTP; Thu, 9 Jun 2011 10:42:46 -0700 (PDT) In-Reply-To: References: <201106091142.p59BgKJK068111@nic-naa.net> From: Jothan Frakes Date: Thu, 9 Jun 2011 10:42:46 -0700 Message-ID: To: "provreg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [provreg] Lists and EPP 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: Thu, 09 Jun 2011 17:43:29 -0000 I like that Jan had an Idea about walking the report, but I'd suggest that it would still place a burden on the EPP communications in the case of Jim's jumbo jumbo data packet example. It really shouldn't impact the other users to have such a report happening, and I could still see that our jumbo jumbo example would place additional load on the EPP server, and there's a matter of maintaining state from TRID to TRID on the client side and server side, so it might even be more fugly of a solution than just pushing the whole thing in one response. What about using EPP to trigger a report generation and having the response contain either a URI to that report or a response token that allowed a poll message to retrieve that report URI upon the completion of it being generated? Perhaps even a poll message that generally contains a list of the reports available in its response? Then that data could be retrieved from an out of band process which would not place undue burden on the networks, and it could easily retrofit to existing implementations. -Jothan Jothan Frakes On Thu, Jun 9, 2011 at 7:03 AM, Gould, James wrote: > Eric, > > I'm sure that a method could be created to support a bulk list command an= d > response in EPP, but I question whether it is appropriate for EPP. =A0Thi= s > information is already provided via reports and made available via FTP an= d > via a web application, so what is the driver for adding this to the > provisioning channel? =A0Creating an XML response of thousands to million= s > of records does represent a scalability issue for the server and the > client. =A0For bulk data it's best to separate format definition from dat= a, > which is why for data escrow I'm not a fan of the use of XML. =A0The same > holds true for bulk information. =A0I don't believe it's a good use of th= e > limited provisioning resources to support an unbounded bulk data feed, > where the focus should continue to serve the provisioning needs and not > the reporting and synchronization needs. > > -- > > > JG > > > > James Gould > Principal Software Engineer > jgould@Verisign.com > > 703-948-3271 > 21345 Ridgetop Circle > LS2-2-1 > Dulles, VA 20166 > > VerisignInc.com > > > > > On 6/9/11 7:42 AM, "brunner@nic-naa.net" wrote: > >>The "scale" claim I'm still mulling on. When I wrote the first ICANN >>escrow >>spec (registries) I put in the means for an escrow deposit to span more >>than >>a single media capacity, a means also present in the second ICANN escrow >>spec >>(registrars), which somebody wrote. >> >>So the unboundednes of a "record" (or sequence of grouped XML glop) is at >>least by the capacity bounds of the transport media (current DVDs are big= , >>but not infinite), and the transmit capacity between the source and sink >>does determine the limit before the trasmission of an instance of a >>record >>must also contain updates to data within that record. >> >>But I'm not interested in edge cases of EPP-for-Verisign or >>EPP-for-GoDaddy, >>or transport-for-domainers-slamming-the-com-drop-pool, but in the more >>common >>problem, for which a registry policy declaration of the maximum size of a >>unit of data (or the equivalent unerlying database access bandwidth) can >>be >>announced to the registrar, just like a dcp. >> >>For this, a LIST command semantics and syntax can be specified and >>implemented >>and interoperability demonstrated, with the option of using the IETF or >>any >>equivalent means of making the specification available without liability >>to >>its authors, implementors and eventual users. >> >>Based upon limited experience with one registry platform operator's dbms, >>the LIST command and the LIST response may be sufficienty seperated in >>time >>to require more bookkeeping overhead than a mere wait() and the assumptio= n >>of stream semantics. >> >>Eric >>_______________________________________________ >>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 paf@cisco.com Thu Jun 9 10:58:28 2011 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 2182B11E8202 for ; Thu, 9 Jun 2011 10:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rbfm85YMX7Zy for ; Thu, 9 Jun 2011 10:58:27 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFA611E81EB for ; Thu, 9 Jun 2011 10:58:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paf@cisco.com; l=755; q=dns/txt; s=iport; t=1307642307; x=1308851907; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=GPxSFzP+4x1Ru94lr/XdGuDkJPBWJyCeN2gFDqIHUoM=; b=NMGA9zoYPjojI3cArA6IsmREPazeuXfW+bjkT5S6oYgjKS8WBybwMakD lTgxpovZw4WHpvZfxjKWmgclCVICp9Y2bjNU8M/lYso3H0FY6OICsrweR jpGZF9ZWv9DPzgdnGRRlEVnkdceJrdGgwYlRRT5QhENQwJq6k3ZFM1EKk 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIgJ8U2Q/khM/2dsb2JhbABTpj93iHGgep4UhiMEkSqPVA X-IronPort-AV: E=Sophos;i="4.65,342,1304294400"; d="scan'208";a="34524678" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 09 Jun 2011 17:58:26 +0000 Received: from dhcp-10-61-96-29.cisco.com (dhcp-10-61-96-29.cisco.com [10.61.96.29]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p59Hw1rv017132; Thu, 9 Jun 2011 17:58:24 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Thu, 9 Jun 2011 19:53:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <172B9B25-6A24-4A94-A386-06685D6E3BAD@cisco.com> References: To: "Gould, James" X-Mailer: Apple Mail (2.1084) Cc: "provreg@ietf.org" Subject: Re: [provreg] Lists and EPP 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: Thu, 09 Jun 2011 17:58:28 -0000 On 9 jun 2011, at 16.03, Gould, James wrote: > I'm sure that a method could be created to support a bulk list command = and > response in EPP, but I question whether it is appropriate for EPP. = This > information is already provided via reports and made available via FTP = and > via a web application, so what is the driver for adding this to the > provisioning channel? It does not matter what the mechanism is, as long as _all_ registries = use _exactly_ the same mechanism. Whether epp is used or not is secondary, and from my perspective (with a = registrar hat on) up to the registries. Choose whatever you want, but ONE solution. And then make the = specification of that list that _everyone_ use made public. Patrik From cbbrowne@afilias.info Wed Jun 8 10:33:16 2011 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 4F71E11E81AA for ; Wed, 8 Jun 2011 10:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.643 X-Spam-Level: X-Spam-Status: No, score=-5.643 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYG70l4a9NgT for ; Wed, 8 Jun 2011 10:33:15 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7FAC211E8076 for ; Wed, 8 Jun 2011 10:33:15 -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 1QUMd0-0001e7-5J for provreg@ietf.org; Wed, 08 Jun 2011 17:33:14 +0000 Received: from mail-bw0-f50.google.com ([209.85.214.50]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1QUMd0-0004TD-44 for provreg@ietf.org; Wed, 08 Jun 2011 17:33:14 +0000 Received: by bwz2 with SMTP id 2so650357bwz.9 for ; Wed, 08 Jun 2011 10:33:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.26.132 with SMTP id e4mr1095155bkc.142.1307554392690; Wed, 08 Jun 2011 10:33:12 -0700 (PDT) Received: by 10.204.98.195 with HTTP; Wed, 8 Jun 2011 10:33:12 -0700 (PDT) In-Reply-To: References: <4DEF29D9.10706@publisher.de> <88F220D2-4084-41AF-BA59-3944AA4EA8E2@rfc1035.com> <7C33C30D-12F2-48BA-B937-4305E9EE9A13@cisco.com> Date: Wed, 8 Jun 2011 13:33:12 -0400 Message-ID: From: Christopher Browne To: Jim Reid Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 09 Jun 2011 12:24:50 -0700 Cc: Ulrich Wisser , provreg@ietf.org Subject: Re: [provreg] Lists and EPP 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: Wed, 08 Jun 2011 17:34:27 -0000 2011/6/8 Jim Reid : > On 8 Jun 2011, at 10:12, Patrik F=E4ltstr=F6m wrote: > >> There are a number of other sync-mechanisms I would not mind seeing, but >> it is important the registries do that the same way... I do see registra= rs >> start to be irritated on the high number of different implementations of= The >> Same Thing between registries. > > Yes, an industry-wide standarised way to do this kind of thing would of > course be good Patrik. I'm not convinced EPP is the tool to use though. N= ot > every registry and registrar speaks EPP. There could be icky implementati= on > issues too: eg locking the database while something ploughs through it to > generate the list. [We can't have the database changing while the list is > generated, eh?] I fear this could be the start of a slippery slope as mor= e > SQL reporting type stuff gets shoe-horned into EPP: "gimme a list of all = the > domain names I registered for this contact that then got transferred to t= hat > registrar over the last N months", "which domains I manage reference this > nameserver (or contact) object?". When I think about this, my brain heads down quite a similar trail, as one part of me starts looking for the semantic minutiae of how it ought to work, and the successive set of problems that lead to defining a more and more extensive set of commands to characterize the necessary actions, and to cope with various concurrency and transaction management problems. Franciso, downthread, observes that limits may be indicated in a multiplicity of ways (e.g. - counts, maximum sizes of requests). I quickly leap to "wait, stop here!" since adding in such details winds up mandating quite a lot about implementation, which is something that the protocol ought to generally protect us from, rather than fairly directly implying. I'd be fearful that a "" command would turn out to be so complex in its behavior that it's effectively unusable. CRISP/IRIS was intended to provide this sort of functionality, but, in practice, there has been little adoption, which seems suggestive that something is problematic about it as solution. None of the directions that are evident seem palatable: - The "straightforward" way is undesirable as it leads to unacceptably expensive requests (e.g. - where the response set will be unacceptably large) - Performance-sensitive methods will be complex, and need to specify semantics (e.g. - assumptions about transaction handling, serialization, and such) that are not desirable to have in the protocol. In practice, registry contracts have tended to define a set of mandatory reports (including formats) for the regular release of this sort of information, and while that's not "one stop shopping" (or pick your favorite business-y idiom), it generally does function. Andrew Sullivan's suggestion of passing URIs around using the poll queue facility is plausible, certainly involving a goodly amount of indirection. It implies an interaction between EPP registry and an outside URI server (quite likely a web/ftp server). --=20 Christopher Browne From ebw@nic-naa.net Wed Jun 8 07:30:10 2011 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 B698411E80FD for ; Wed, 8 Jun 2011 07:30:10 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Hfjsuo4TR0F for ; Wed, 8 Jun 2011 07:30:10 -0700 (PDT) Received: from nic-naa.net (nic-naa.net [65.99.1.132]) by ietfa.amsl.com (Postfix) with ESMTP id F172211E80E4 for ; Wed, 8 Jun 2011 07:30:09 -0700 (PDT) Received: from nic-naa.net (localhost [127.0.0.1]) by nic-naa.net (8.14.4/8.14.4) with ESMTP id p58CVi5H058216; Wed, 8 Jun 2011 08:31:44 -0400 (EDT) (envelope-from ebw@nic-naa.net) Message-Id: <201106081231.p58CVi5H058216@nic-naa.net> To: paf@cisco.com Date: Wed, 08 Jun 2011 08:31:44 -0400 From: Eric Brunner-Williams X-Mailman-Approved-At: Thu, 09 Jun 2011 12:24:50 -0700 Cc: provreg@ietf.org Subject: Re: [provreg] Lists and EPP 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: Wed, 08 Jun 2011 18:35:06 -0000 > I dare to say that as I as Area Director when epp was invented could > have pushed back more, but I did not. So I blame myself. Before you blame yourself, the fundamental choices were never available to the ADs to alter -- XML as the syntax, client-server as the event model, with the universe of communication restricted to registrars and a registry, in a design univers of 6 registries and 60 registrars. However, if you're inviting blame for errors as AD, your personal decision to prevent XML-over-SMTP meant that a lot of registries and registrars in cc-land, where the 3pm drop never presents a race condition, had a transport predicate you thought necessary and I thought unnecessary. If Harald is around he can take the blame for his binary valued "do not publish" mechanism as a useful alternative to data collection policy announcements. With no criticism to Scott, the importance of the VGRS inventory to the ICANN registrars really made any design choices that attempted to extend the 6+60 model were doomed. We didn't get: o containers, so glops of contact, host and domain data could be flushed in either direction; o symmetric event model, so regsitries could notify registrars of things like "your hair is on fire", other than via polling; o generalization of the endpoints, so escrow could be implemented via EPP; o generalization of the endpoints, so registrars could proxy to accredited registrars for registries they lack accreditation (cause the world was com/net/org/biz/info/foo) via EPP; o (and this is not a criticism of anything to time and tech) the means to elegantly exend the XML syntax (the "X" is over-rated); I'm sure I've forgotten many things that are useful for some notion of how a provisioning protocl that doesn't have the 6+60/C-S/tcp/race model set of restrictions. And mistakes are normal, so this isn't a harsh criticism, but the set of pre-IETF constraints has had consequences, and may have more consequences as the model grows beyond 6+60 to more 3166 parties and all the 201x new adds. Eric From cbbrowne@afilias.info Thu Jun 9 11:23:58 2011 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 BAF4611E8163 for ; Thu, 9 Jun 2011 11:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.643 X-Spam-Level: X-Spam-Status: No, score=-5.643 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkB6HeNMpmrM for ; Thu, 9 Jun 2011 11:23:56 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id D329511E8162 for ; Thu, 9 Jun 2011 11:23:55 -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 1QUjtb-0003Xj-3J for provreg@ietf.org; Thu, 09 Jun 2011 18:23:55 +0000 Received: from mail-bw0-f50.google.com ([209.85.214.50]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1QUjta-0002RB-5R for provreg@ietf.org; Thu, 09 Jun 2011 18:23:54 +0000 Received: by bwz2 with SMTP id 2so1637323bwz.9 for ; Thu, 09 Jun 2011 11:23:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.26.132 with SMTP id e4mr1059056bkc.142.1307643833234; Thu, 09 Jun 2011 11:23:53 -0700 (PDT) Received: by 10.204.98.195 with HTTP; Thu, 9 Jun 2011 11:23:53 -0700 (PDT) In-Reply-To: References: <201106091142.p59BgKJK068111@nic-naa.net> Date: Thu, 9 Jun 2011 14:23:53 -0400 Message-ID: From: Christopher Browne To: Jothan Frakes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 09 Jun 2011 12:24:50 -0700 Cc: "provreg@ietf.org" Subject: Re: [provreg] Lists and EPP 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: Thu, 09 Jun 2011 18:23:58 -0000 On Thu, Jun 9, 2011 at 1:42 PM, Jothan Frakes wrote: > I like that Jan had an Idea about walking the report, but I'd suggest > that it would still place a burden on the EPP communications in the > case of Jim's jumbo jumbo data packet example. > > It really shouldn't impact the other users to have such a report > happening, and I could still see that our jumbo jumbo example would > place additional load on the EPP server, and there's a matter of > maintaining state from TRID to TRID on the client side and server > side, so it might even be more fugly of a solution than just pushing > the whole thing in one response. When I put my "transactional hat" on, there's a whole lot of ugly there: - If EPP generates a "jumbo jumbo" packet, that induces largeness in several places: 1. Large, long-running transaction against database, which DB guys hate for pretty well-understood reasons. 2. Very large data packet that crosses the network 3. Large amount of network bandwidth is used 4. Very large packet of data that needs to be processed by the client (e.g. - what if there's 17GB of XML needing to be parsed?) - If EPP has protocol added to split this into more "bite-sized" chunks, complexity is induced, as we need to have multiple commands issued, that do partial processing 1. If there's a database, one of two things happen: a) If a transaction is held open, you wind up with the same large-long-running transaction, and perhaps it runs longer b) If there's a new transaction per request, consistency between "chunks" is problematic 2. The data packets may be of more reasonable size, individually, but... 3. There's still a very large amount of bandwidth used. This part is invariant. 4. Individual data packets are smaller, so more manageable to clients, but they have a bigger problem in synchronizing them at the end. That seems to capture the ugliness pretty well. > What about using EPP to trigger a report generation and having the > response contain either a URI to that report or a response token that > allowed a poll message to retrieve that report URI upon the completion > of it being generated? =A0Perhaps even a poll message that generally > contains a list of the reports available in its response? I like that idea quite a bit; I think Andrew Sullivan was the first one to mention it, upthread. It allows pushing the problems to different places, and I don't think this is just a matter of us all fooling ourselves into imagining that it looks better. It's a very common pattern to say "OLTP system only does OLTP, Analytics are done elsewhere." > Then that data could be retrieved from an out of band process which > would not place undue burden on the networks, and it could easily > retrofit to existing implementations. I suspect that there have been enough workarounds going around that some registrars may have accustomed themselves to not using the poll queue facility. *Some* care needs to be taken so that the poll queue doesn't become the scary, fragile component that induces the next round of complaints. From JGould@verisign.com Thu Jun 9 12:28:50 2011 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 66EB711E8097 for ; Thu, 9 Jun 2011 12:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.244 X-Spam-Level: X-Spam-Status: No, score=-6.244 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4D5XSYYfxrW1 for ; Thu, 9 Jun 2011 12:28:48 -0700 (PDT) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) by ietfa.amsl.com (Postfix) with ESMTP id BAFB111E80BF for ; Thu, 9 Jun 2011 12:28:45 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKTfEe6zLmrX5riybRTbpkrEAA2Pjoi0/h@postini.com; Thu, 09 Jun 2011 12:28:48 PDT Received: from dul1wnexcn04.vcorp.ad.vrsn.com (dul1wnexcn04.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id p59JSgho024593; Thu, 9 Jun 2011 15:28:42 -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); Thu, 9 Jun 2011 15:28:42 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.01.0270.001; Thu, 9 Jun 2011 15:28:41 -0400 From: "Gould, James" To: Jothan Frakes , "provreg@ietf.org" Thread-Topic: [provreg] Lists and EPP Thread-Index: AQHMJppKf9xX6h9w4UqobGsEUTNhE5S1DuCAgACAQgD//9qFgA== Date: Thu, 9 Jun 2011 19:28:41 +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.10.0.110310 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: 09 Jun 2011 19:28:42.0741 (UTC) FILETIME=[714C2250:01CC26DB] Subject: Re: [provreg] Lists and EPP 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: Thu, 09 Jun 2011 19:28:50 -0000 I still don't understand the problem that we're trying to solve. What is the problem with generating the reports and making the reports available for consumption by a predetermined schedule and at a predefined location? Moving the report generation or report generation trigger into the provisioning system is mixing provisioning and reporting for little added benefit. Is the problem the lack of a standard report format? Is the problem the need to generate the report on demand? I believe that these problems can be addressed outside of EPP. -- JG James Gould Principal Software Engineer jgould@Verisign.com 703-948-3271 21345 Ridgetop Circle LS2-2-1 Dulles, VA 20166 VerisignInc.com On 6/9/11 1:42 PM, "Jothan Frakes" wrote: >I like that Jan had an Idea about walking the report, but I'd suggest >that it would still place a burden on the EPP communications in the >case of Jim's jumbo jumbo data packet example. > >It really shouldn't impact the other users to have such a report >happening, and I could still see that our jumbo jumbo example would >place additional load on the EPP server, and there's a matter of >maintaining state from TRID to TRID on the client side and server >side, so it might even be more fugly of a solution than just pushing >the whole thing in one response. > >What about using EPP to trigger a report generation and having the >response contain either a URI to that report or a response token that >allowed a poll message to retrieve that report URI upon the completion >of it being generated? Perhaps even a poll message that generally >contains a list of the reports available in its response? > >Then that data could be retrieved from an out of band process which >would not place undue burden on the networks, and it could easily >retrofit to existing implementations. > >-Jothan > >Jothan Frakes > > > >On Thu, Jun 9, 2011 at 7:03 AM, Gould, James wrote: >> Eric, >> >> I'm sure that a method could be created to support a bulk list command >>and >> response in EPP, but I question whether it is appropriate for EPP. This >> information is already provided via reports and made available via FTP >>and >> via a web application, so what is the driver for adding this to the >> provisioning channel? Creating an XML response of thousands to millions >> of records does represent a scalability issue for the server and the >> client. For bulk data it's best to separate format definition from >>data, >> which is why for data escrow I'm not a fan of the use of XML. The same >> holds true for bulk information. I don't believe it's a good use of the >> limited provisioning resources to support an unbounded bulk data feed, >> where the focus should continue to serve the provisioning needs and not >> the reporting and synchronization needs. >> >> -- >> >> >> JG >> >> >> >> James Gould >> Principal Software Engineer >> jgould@Verisign.com >> >> 703-948-3271 >> 21345 Ridgetop Circle >> LS2-2-1 >> Dulles, VA 20166 >> >> VerisignInc.com >> >> >> >> >> On 6/9/11 7:42 AM, "brunner@nic-naa.net" wrote: >> >>>The "scale" claim I'm still mulling on. When I wrote the first ICANN >>>escrow >>>spec (registries) I put in the means for an escrow deposit to span more >>>than >>>a single media capacity, a means also present in the second ICANN escrow >>>spec >>>(registrars), which somebody wrote. >>> >>>So the unboundednes of a "record" (or sequence of grouped XML glop) is >>>at >>>least by the capacity bounds of the transport media (current DVDs are >>>big, >>>but not infinite), and the transmit capacity between the source and sink >>>does determine the limit before the trasmission of an instance of a >>>record >>>must also contain updates to data within that record. >>> >>>But I'm not interested in edge cases of EPP-for-Verisign or >>>EPP-for-GoDaddy, >>>or transport-for-domainers-slamming-the-com-drop-pool, but in the more >>>common >>>problem, for which a registry policy declaration of the maximum size of >>>a >>>unit of data (or the equivalent unerlying database access bandwidth) can >>>be >>>announced to the registrar, just like a dcp. >>> >>>For this, a LIST command semantics and syntax can be specified and >>>implemented >>>and interoperability demonstrated, with the option of using the IETF or >>>any >>>equivalent means of making the specification available without liability >>>to >>>its authors, implementors and eventual users. >>> >>>Based upon limited experience with one registry platform operator's >>>dbms, >>>the LIST command and the LIST response may be sufficienty seperated in >>>time >>>to require more bookkeeping overhead than a mere wait() and the >>>assumption >>>of stream semantics. >>> >>>Eric >>>_______________________________________________ >>>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 Ed.Lewis@neustar.biz Thu Jun 9 12:53:56 2011 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 15A5D11E81A3 for ; Thu, 9 Jun 2011 12:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.332 X-Spam-Level: X-Spam-Status: No, score=-105.332 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlkdxYVza9G5 for ; Thu, 9 Jun 2011 12:53:55 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id A6DB511E80E2 for ; Thu, 9 Jun 2011 12:53:54 -0700 (PDT) Received: from work-laptop-2 (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p59JrqLq035636; Thu, 9 Jun 2011 15:53:52 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.222] by work-laptop-2 (PGP Universal service); Thu, 09 Jun 2011 15:53:53 -0400 X-PGP-Universal: processed; by work-laptop-2 on Thu, 09 Jun 2011 15:53:53 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <172B9B25-6A24-4A94-A386-06685D6E3BAD@cisco.com> References: <172B9B25-6A24-4A94-A386-06685D6E3BAD@cisco.com> Date: Thu, 9 Jun 2011 15:53:29 -0400 To: "provreg@ietf.org" From: Edward Lewis Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: [provreg] Why must there be one solution? was Re: Lists and EPP 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: Thu, 09 Jun 2011 19:53:56 -0000 At 19:53 +0200 6/9/11, Patrik F=E4ltstr=F6m wrote: >It does not matter what the mechanism is, as long as _all_ registries >use _exactly_ the same mechanism. Why? (And I'm not saying it has to be EPP or not has to be EPP.) A few messages back I mentioned that in meetings=20 with some registries, doing the work to increase=20 commonality was judged to be "not worth it." A=20 response on this list was that I was reporting=20 something that was a sampling of a few registries=20 and not representative of registrars. My comeback (which I just didn't get around to=20 asking until now) is the registries do know at=20 some level of familiarity, what registrars go=20 through. The relationship is more symbiotic than=20 adversarial. And, as a challenge, if registries'=20 opinion is not sufficient, is there any data that=20 does come from registrars? I mean, a lot of us want to build nice, neat=20 systems. And I'm sure anyone using the protocol=20 would like something nice and neat. But, are=20 there material complaints against what we have=20 now and a willingness to reinvest in achieving=20 something nicer and neater. I'll grant that having one universal solution is=20 a nice and neat thing to have. But I have yet to=20 see that it is crucial to have "one" universal=20 solution given my experience in operator arenas. -- -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 When talking about a long day keep this in mind (found on wikipedia.org): Because the earliest and latest time zones are 26 hours apart, any given calendar date exists at some point on the globe for 50 hours. From jothan@gmail.com Thu Jun 9 14:32:39 2011 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 73F4711E817C for ; Thu, 9 Jun 2011 14:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, GB_MUTUALBENEFIT=2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EwDSo2PNAm2 for ; Thu, 9 Jun 2011 14:32:36 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8167011E817A for ; Thu, 9 Jun 2011 14:32:36 -0700 (PDT) Received: by vws12 with SMTP id 12so2156912vws.31 for ; Thu, 09 Jun 2011 14:32:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=xFnnEuON3nleXUjuNDWr+t4QaHCHFUp85oepvFgkTr4=; b=D7vkH1qZD48Egjq4/t822CYBv0lVnrbtM9+ItfNiyLTnlzGLRYBJNj+XgQZ0BlAjR5 TM+B7z0dQJRcA/fZkACa9tqt6/G97jF2nHcFvh8RSAz6zFpzQMzLEimlNJs4iVmbduPX S2ye6GP7dA97r76SjpioIbJ9x1UXMoAuuVj2c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=NXEk3Khy5M0Ws+R85ZvHRhBQsUD5nmX7sNwSruOxoFelEsyrg/ayKljUf0wZxHLjQ+ XRFROntNeonu60/BkNQnkOObytgFQvT3CiD+G+f8gfasoN5jHo25vlFXHNWobo7lVfz6 /ACks5wfsMXYgH815hN7ZXrgjqrpHjJ/QYrM8= Received: by 10.52.99.10 with SMTP id em10mr1704107vdb.257.1307655151052; Thu, 09 Jun 2011 14:32:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.188.231 with HTTP; Thu, 9 Jun 2011 14:31:51 -0700 (PDT) In-Reply-To: References: <172B9B25-6A24-4A94-A386-06685D6E3BAD@cisco.com> From: Jothan Frakes Date: Thu, 9 Jun 2011 14:31:51 -0700 Message-ID: To: "provreg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Cc: Edward Lewis Subject: Re: [provreg] Why must there be one solution? was Re: Lists and EPP 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: Thu, 09 Jun 2011 21:32:39 -0000 > > Why? > I think the answer varies. Let's take the circumstance of a more recent registry service provider (RSP) or ccTLD converting/evolving to EPP. If one looks at the list of registrars at the following URL: http://www.icann.org/en/registrars/accredited-list.html You can break them down by RSP I have not adjusted for marketshare nor do I roll-up add storm 'thread-fleets', these are just the raw listing of registrars. .name,.jobs,.com,.net are on VeriSign .aero, .asia, .info, .mobi, .org and .xxx are on Afilias .biz, .travel, .tel are on Neustar Look at rightmost column on that list and map the providers to the registrar mix and the pattern appears clear. Nearly everyone has .com integration (ie VeriSign). Most have Afilias and many are Neustar. Anyway, unless volume of registrations and wider adoption of their namespace is not a priority to them, a new RSP or ccTLD is looking at that URL and saying to themselves that they should make their system work like one of these three providers. A different take : > > Why? > I'd also assert that even though Afilas, Neustar, and VeriSign have been pioneers in the space, and I have had the privilege of working with Scott and Jim to tell you that they're top notch, a company in their position is not really going to have any commercial benefit from adapting their EPP to that of the providers who have a smaller segment of the overall list of registrars on that list. That commercial benefit is often the catalyst for funding projects and updating things. The 201X TLDs could be a vehicle... I'd say the exception to the above is where there is a new implementation benefit or standard that evolves, such as the effort to bring some uniformity to the sunrise/landrush/go-live fields and phases that is currently under way. That kind of uniformity is of mutual benefit to all parties and there is a bit of a level playing field because these all launch about the same time in theory. -Jothan From ebw@nic-naa.net Thu Jun 9 17:07:37 2011 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 8A4EB1F0C4C for ; Thu, 9 Jun 2011 17:07:37 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BVUZw7hfUD5 for ; Thu, 9 Jun 2011 17:07:35 -0700 (PDT) Received: from nic-naa.net (nic-naa.net [65.99.1.132]) by ietfa.amsl.com (Postfix) with ESMTP id B37551F0C34 for ; Thu, 9 Jun 2011 17:07:35 -0700 (PDT) Received: from nic-naa.net (localhost [127.0.0.1]) by nic-naa.net (8.14.4/8.14.4) with ESMTP id p59M8p2k070964; Thu, 9 Jun 2011 18:08:51 -0400 (EDT) (envelope-from ebw@nic-naa.net) Message-Id: <201106092208.p59M8p2k070964@nic-naa.net> From: brunner@nic-naa.net To: Ed.Lewis@neustar.biz Date: Thu, 09 Jun 2011 18:08:51 -0400 Sender: ebw@nic-naa.net Cc: provreg@ietf.org Subject: Re: [provreg] Why must there be one solution? was Re: Lists and EPP 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: Fri, 10 Jun 2011 00:07:37 -0000 Ed, At the Paris ICANN meeting I asked the Registrar Constituency members present which would be doing new gTLDs -- as registrars. No hands were raised. At that point the design space was still "6+60", with a growing, but commercially negligible 3166 auxilliary space of "N+N0", where N was a small, but growing two digit integer, the number of epp-speaking ccTLDs, and 10xN was a handwave at the number of counter-party registrars. Something's changed. The Vertial Integration Botch (tm) now means that we've 600+600 as a design space. 600 registries (legacy ex-RRP-speakers, 2001+2004 EPP-speakers, a "bigger N" number of 3166 registries, and ICANN's 500 (or whatever) of 201x registries, AND the same 60 registrars (ignoring the 600+ shell registrars that exist only for the 3pm race), the same "+N0" registrars pursuing local geo markets, AND each registry-as-a-registrar. I think its a nightmare, but each registry-as-registrar is just as rational as VGRS in pursuing its own effective monopoly in total indifference to the chaos around it. At least until it fails. I suggest, that for straight registrars, that with the rate of transition to delegation of three-per-day, that agility matters more than anything, unless registrars are deliberate "market trailers", and only moving on the additions (if any) to the CNOBI sweet spot of volume and lack of variation in business logical fundamentals. Perhaps PAF will get his One True Thing-a-Majig, or the CNOBI sweet spot will either not enlarge with diversity, or diverge over time, as James suggests. I just don't expect uniformity. I do however expect clustering along policy lines, and along platform independent lines, as well as along platform-captured lines. Eric From pfaltstr@cisco.com Thu Jun 9 14:45:59 2011 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 3813E11E8104 for ; Thu, 9 Jun 2011 14:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.136 X-Spam-Level: X-Spam-Status: No, score=-7.136 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRWjf6YLan6E for ; Thu, 9 Jun 2011 14:45:57 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 87E2C11E80F5 for ; Thu, 9 Jun 2011 14:45:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pfaltstr@cisco.com; l=459; q=dns/txt; s=iport; t=1307655957; x=1308865557; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=6OsVq+jYZGkkKyEAfCYlKCMVVHcvThfVDgJQLFPoBWY=; b=EruGR4wSLqlMUVwt9wdTaZWZcUWBJU24e7dvWjUryoYHxQtE1Jhq79wr hK588ioxlxO3iE7W+/bR8tmsghErl3P7EbYrr1KmSDYXqdluDEFHyj3fo 2N+VavxdXLnL/mlFOoL4c5Y5qFnUJ4WLlNWAYJ+RCdYWcezAh6xHWLurS U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuIFAEA+8U2Q/khL/2dsb2JhbABTiRKcPHACd4hxoXmeCYYjBJEqhFaEMoJrg2E X-IronPort-AV: E=Sophos;i="4.65,343,1304294400"; d="scan'208";a="93217553" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 09 Jun 2011 21:45:56 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p59LjuGn007601; Thu, 9 Jun 2011 21:45:56 GMT Received: from xmb-ams-106.cisco.com ([144.254.74.81]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Jun 2011 23:45:56 +0200 Received: from 144.254.231.95 ([144.254.231.95]) by XMB-AMS-106.cisco.com ([144.254.74.81]) with Microsoft Exchange Server HTTP-DAV ; Thu, 9 Jun 2011 21:45:56 +0000 References: <172B9B25-6A24-4A94-A386-06685D6E3BAD@cisco.com> Content-Transfer-Encoding: quoted-printable From: "Patrik Faltstrom (pfaltstr)" Thread-Topic: [provreg] Why must there be one solution? was Re: Lists and EPP Content-Type: text/plain; charset="us-ascii" Thread-Index: Acwm7py8Xq1kk1xITnSnUbzgkcQImg== In-Reply-To: Message-ID: <47F1E63D-16BD-4B96-AEF2-3A213C82A7DC@cisco.com> Date: Thu, 9 Jun 2011 23:45:13 +0200 To: "Jothan Frakes" MIME-Version: 1.0 (iPhone Mail 8J2) X-OriginalArrivalTime: 09 Jun 2011 21:45:56.0344 (UTC) FILETIME=[9CE83F80:01CC26EE] X-Mailman-Approved-At: Fri, 10 Jun 2011 00:21:02 -0700 Cc: Edward Lewis , provreg@ietf.org Subject: Re: [provreg] Why must there be one solution? was Re: Lists and EPP 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: Thu, 09 Jun 2011 21:45:59 -0000 On 9 jun 2011, at 23:33, "Jothan Frakes" wrote: > Anyway, unless volume of registrations and wider adoption of their > namespace is not a priority to them, a new RSP or ccTLD is looking at > that URL and saying to themselves that they should make their system > work like one of these three providers. Look at net::dri instead and _all_ registries and you get a more complete pi= cture. The world is not gTLD only. Patrik From bernie@ietf.hoeneisen.ch Fri Jun 10 01:40:00 2011 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 72A7111E80D9 for ; Fri, 10 Jun 2011 01:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOqDsU2RB0gZ for ; Fri, 10 Jun 2011 01:39:59 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by ietfa.amsl.com (Postfix) with ESMTP id 5E39111E807D for ; Fri, 10 Jun 2011 01:39:57 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.71) (envelope-from ) id 1QUxFx-0000Ab-FT; Fri, 10 Jun 2011 10:39:53 +0200 Date: Fri, 10 Jun 2011 10:39:53 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Edward Lewis In-Reply-To: Message-ID: References: <172B9B25-6A24-4A94-A386-06685D6E3BAD@cisco.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Cc: "provreg@ietf.org" Subject: [provreg] Where are the Registrars? (was Re: Why must there be one solution? was Re: Lists and EPP) 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: Fri, 10 Jun 2011 08:40:00 -0000 Hi Ed et al. On Thu, 9 Jun 2011, Edward Lewis wrote: > A few messages back I mentioned that in meetings with some registries, doing > the work to increase commonality was judged to be "not worth it." A response > on this list was that I was reporting something that was a sampling of a few > registries and not representative of registrars. > > My comeback (which I just didn't get around to asking until now) is the > registries do know at some level of familiarity, what registrars go through. > The relationship is more symbiotic than adversarial. As you know, I was with you while talking to Registries about EPP improvements. And I came to a similar conclusion: Registries have little motivation to "change a running system". Registries don't appear to have a problem. Registries are often those who set the policies and build the (EPP) systems, sometimes with proprietary EPP extensions. Registrars, on the other hand, usually have to cope with what they get and find ways around the resulting problems. However, those who suffer from such problems are Registars! > And, as a challenge, if registries' opinion is not sufficient, is there > any data that does come from registrars? I have not observed major Registrar participation in the IETF (or other fora where EPP is discussed), which I believe is a significant cause of the mess that happened with real-life "extended" EPP. Does anybody know, why there are so few Registrars active in this field? Any idea how to get more Registrars involved in EPP discussions? cheers, Bernie -- http://ucom.ch/ Tech Consulting for Internet Technology From Richard.Wilhelm@networksolutions.com Mon Jun 13 14:08:12 2011 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 6A4A021F85AA for ; Mon, 13 Jun 2011 14:08:12 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pO5P1l8vUoRw for ; Mon, 13 Jun 2011 14:08:11 -0700 (PDT) Received: from heron.networksolutions.com (heron.networksolutions.com [205.178.190.224]) by ietfa.amsl.com (Postfix) with ESMTP id 2E43721F85A9 for ; Mon, 13 Jun 2011 14:08:11 -0700 (PDT) Received: from NSIVA-EXCHANGE3.CORPIT.NSI.NET (nsivaex3-a.corpit.nsi.net [10.216.32.87]) by heron.networksolutions.com (8.12.10/8.12.10) with ESMTP id p5DL80mR009225; Mon, 13 Jun 2011 17:08:00 -0400 (EDT) Received: from 10.63.79.26 ([10.63.79.26]) by NSIVA-EXCHANGE3.CORPIT.NSI.NET ([10.216.32.92]) with Microsoft Exchange Server HTTP-DAV ; Mon, 13 Jun 2011 21:08:00 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Mon, 13 Jun 2011 17:07:59 -0400 From: "Wilhelm, Richard" To: Bernie Hoeneisen , Ed Lewis Message-ID: Thread-Topic: [provreg] Where are the Registrars? (was Re: Why must there be one solution? was Re: Lists and EPP) Thread-Index: AcwqDfkoPVIN9WUPcECFAEkoTatiqA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "provreg@ietf.org" Subject: Re: [provreg] Where are the Registrars? (was Re: Why must there be one solution? was Re: Lists and EPP) 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, 13 Jun 2011 21:08:12 -0000 There's at least one registrar here. Thx Rick On 6/10/11 4:39 AM, "Bernie Hoeneisen" wrote: > Hi Ed et al. > > On Thu, 9 Jun 2011, Edward Lewis wrote: > >> A few messages back I mentioned that in meetings with some registries, doing >> the work to increase commonality was judged to be "not worth it." A response >> on this list was that I was reporting something that was a sampling of a few >> registries and not representative of registrars. >> >> My comeback (which I just didn't get around to asking until now) is the >> registries do know at some level of familiarity, what registrars go through. >> The relationship is more symbiotic than adversarial. > > As you know, I was with you while talking to Registries about EPP > improvements. And I came to a similar conclusion: Registries have little > motivation to "change a running system". Registries don't appear to have a > problem. > > Registries are often those who set the policies and build the (EPP) > systems, sometimes with proprietary EPP extensions. Registrars, on the > other hand, usually have to cope with what they get and find ways around > the resulting problems. However, those who suffer from such problems are > Registars! > >> And, as a challenge, if registries' opinion is not sufficient, is there >> any data that does come from registrars? > > I have not observed major Registrar participation in the IETF (or other > fora where EPP is discussed), which I believe is a significant cause of > the mess that happened with real-life "extended" EPP. > > Does anybody know, why there are so few Registrars active in this field? > Any idea how to get more Registrars involved in EPP discussions? > > cheers, > Bernie > > -- > > http://ucom.ch/ > Tech Consulting for Internet Technology > > > > > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg From michele@blacknight.ie Mon Jun 13 15:31:26 2011 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 E405111E80BF for ; Mon, 13 Jun 2011 15:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.14 X-Spam-Level: X-Spam-Status: No, score=-0.14 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3sc90IiLdJ19 for ; Mon, 13 Jun 2011 15:31:26 -0700 (PDT) Received: from exchange.blacknight.ie (exchange.blacknight.ie [81.17.243.252]) by ietfa.amsl.com (Postfix) with ESMTP id A443C11E8079 for ; Mon, 13 Jun 2011 15:31:25 -0700 (PDT) Received: from bkexchmbx02.blacknight.local ([fe80::d4d7:819a:4fb5:c923]) by bkexchhubcas01.blacknight.local ([fe80::3ca9:6bf1:bd5d:24b%15]) with mapi id 14.01.0289.001; Mon, 13 Jun 2011 23:31:24 +0100 From: "Michele Neylon :: Blacknight" To: "provreg@ietf.org" Thread-Topic: Where are the Registrars? Thread-Index: AQHMKhmg0UtwjqbL0kCW6mfKutzx2g== Date: Mon, 13 Jun 2011 22:31:24 +0000 Message-ID: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [87.198.196.25] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [provreg] Where are the Registrars? 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, 13 Jun 2011 22:34:11 -0000 I'm here now as well ..=20 Regards Michele Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection ICANN Accredited Registrar http://www.blacknight.com/ http://blog.blacknight.com/ http://blacknight.mobi/ http://mneylon.tel Intl. +353 (0) 59 9183072 US: 213-233-1612=20 UK: 0844 484 9361 Fax. +353 (0) 1 4811 763 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From mje@posix.co.za Mon Jun 13 23:00:08 2011 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 7751611E8120 for ; Mon, 13 Jun 2011 23:00:08 -0700 (PDT) X-Quarantine-ID: <3SmWktBK9wcM> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): X-Spam-Report: ...that system for details.\n \n Content previ[...] 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SmWktBK9wcM for ; Mon, 13 Jun 2011 23:00:05 -0700 (PDT) Received: from mje99.posix.co.za (mje99.posix.co.za [IPv6:2001:42a0:1000:ff02::481]) by ietfa.amsl.com (Postfix) with ESMTP id 2642C11E80FC for ; Mon, 13 Jun 2011 23:00:03 -0700 (PDT) Received: from [2001:42a0:1000:ff02:21b:63ff:fec0:ebd7] by mje99.posix.co.za with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1QWMey-0001QX-LE; Tue, 14 Jun 2011 07:59:41 +0200 From: Mark Elkins To: "Wilhelm, Richard" In-Reply-To: References: Content-Type: multipart/signed; micalg="sha1"; protocol="application/x-pkcs7-signature"; boundary="=-IyAaDaW/VeVYsFxb5ZRA" Organization: Posix Systems Date: Tue, 14 Jun 2011 07:59:32 +0200 Message-ID: <1308031172.5850.56.camel@ilinux.posix.co.za> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Cc: Ed Lewis , "provreg@ietf.org" Subject: Re: [provreg] Where are the Registrars? (was Re: Why must there be one solution? was Re: Lists and EPP) X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mje@posix.co.za List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 06:00:08 -0000 --=-IyAaDaW/VeVYsFxb5ZRA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Mon, 2011-06-13 at 17:07 -0400, Wilhelm, Richard wrote: > There's at least one registrar here. ... quietly listening to the discussions! (.co.za team) >=20 > Thx >=20 > Rick >=20 >=20 > On 6/10/11 4:39 AM, "Bernie Hoeneisen" wrote: >=20 > > Hi Ed et al. > >=20 > > On Thu, 9 Jun 2011, Edward Lewis wrote: > >=20 > >> A few messages back I mentioned that in meetings with some registries,= doing > >> the work to increase commonality was judged to be "not worth it." A r= esponse > >> on this list was that I was reporting something that was a sampling of= a few > >> registries and not representative of registrars. > >>=20 > >> My comeback (which I just didn't get around to asking until now) is th= e > >> registries do know at some level of familiarity, what registrars go th= rough. > >> The relationship is more symbiotic than adversarial. > >=20 > > As you know, I was with you while talking to Registries about EPP > > improvements. And I came to a similar conclusion: Registries have littl= e > > motivation to "change a running system". Registries don't appear to hav= e a > > problem. > >=20 > > Registries are often those who set the policies and build the (EPP) > > systems, sometimes with proprietary EPP extensions. Registrars, on the > > other hand, usually have to cope with what they get and find ways aroun= d > > the resulting problems. However, those who suffer from such problems ar= e > > Registars! > >=20 > >> And, as a challenge, if registries' opinion is not sufficient, is ther= e > >> any data that does come from registrars? > >=20 > > I have not observed major Registrar participation in the IETF (or other > > fora where EPP is discussed), which I believe is a significant cause of > > the mess that happened with real-life "extended" EPP. > >=20 > > Does anybody know, why there are so few Registrars active in this field= ? > > Any idea how to get more Registrars involved in EPP discussions? > >=20 > > cheers, > > Bernie > >=20 > > -- > >=20 > > http://ucom.ch/ > > Tech Consulting for Internet Technology > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > 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 . . ___. .__ Posix Systems - Sth Africa /| /| / /__ mje@posix.co.za - Mark J Elkins, Cisco CCIE / |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496 --=-IyAaDaW/VeVYsFxb5ZRA Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPMjCCB0gw ggYwoAMCAQICAgLSMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMDkxMDMxMDAwMDAxWhcNMTExMDMxMTU0MTEwWjCBujELMAkGA1UEBhMCWkExEDAOBgNVBAgT B0dhdXRlbmcxETAPBgNVBAcTCFByZXRvcmlhMSEwHwYDVQQKExhQb3NpeCBTeXN0ZW1zIChQVFkp IEx0ZC4xLTArBgNVBAsTJFN0YXJ0Q29tIFZlcmlmaWVkIENlcnRpZmljYXRlIE1lbWJlcjEUMBIG A1UEAxMLTWFyayBFbGtpbnMxHjAcBgkqhkiG9w0BCQEWD21qZUBwb3NpeC5jby56YTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAL6KS+4WC5M29OOVGAcVUn/z90w4aoMidneOPY16Bnuo 6V+8C4kcZrVKoyIYRG55Uln2lKRHeSAhPNBTSMRkkQ1kGNSnmH5jCPhdL+VBN1+CAWeiPvblnsX+ 5wOoEM6v/i2FdBcsdMmssYnG7WFhn4BsyFQe0bQgDNHgbbnJbSMFCaiqAICoQljL0ha/Z3SU+Dgz 2IKTo5fe8vN9P6z5QsETqeBgmsLET+MhwnQ8CRNYhq3vjrYqqie31COgE28Cn5+ez08MDnULB/5I cQFzZ5g1ORtaLrRg6VYHITnMn0EedOb9+iz/WF/nstqVwrKlJsp1hGsOeTjqCoOq6ASH3McCAwEA AaOCA4IwggN+MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQUFPCcDnQQWUlHl8TRFshEBYXoA6IwgagGA1UdIwSBoDCBnYAUrlWD b+wxyrn3HfqvazHzyB3jrLuhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQ4wGgYDVR0RBBMwEYEPbWplQHBv c2l4LmNvLnphMIIBQgYDVR0gBIIBOTCCATUwggExBgsrBgEEAYG1NwECATCCASAwLgYIKwYBBQUH AgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQWDVN0 YXJ0Q29tIEx0ZC4wAwIBARqBkUxpbWl0ZWQgTGlhYmlsaXR5LCBzZWUgc2VjdGlvbiAqTGVnYWwg TGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xp Y3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0f BFwwWjAroCmgJ4YlaHR0cDovL3d3dy5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDAroCmgJ4Yl aHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5 BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2Nh MEIGCCsGAQUFBzAChjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNs aWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3 DQEBBQUAA4IBAQBpz4FHy1vCGNfbLP/aw/Jmrr/f7OO2tsSf04YcOZJnyP8kFonV87V2s6I7cloZ pPqujAupGqT+AZCazDF+tPTLdo/jDvp95DpFTbij5bIY6dAHRrlEiJrca59Lw/V5NLOs7fLMfKLu lhSba5hBSG9DX4VTXejLAIgz9z5GqKW31b38Ma67OpKqKGvd+KMgZ+PxLfCrthXrEk1yAL/k6ypt p0tScZpbsHTqWEoSI0ulTG36T3M1/3aeI4NPcJytFXNwvd2DZZLC2IOopDc0nEabfpXgng01k4TB 1p22/58SiU8EVSuEnOfPWKE4KgA2071dwcwxepQmiD+V9bNsLJ7yMIIH4jCCBcqgAwIBAgIBDjAN BgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMjU0WhcNMTIxMDIyMjEwMjU0 WjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIg UHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAyyiFRZwBLPsZ8qulM4wqoA3L0FXtXSKBZ0bEDwhTvsvdpPEStD59zG0NhnfpnoYfRgWf t+rlEAO14/QBjOsID4RBN+LyrX6QDebSfC3Bcb3gzmwiqy+zuVE/VrJwGR7+zmD2EkevJnZpxJyf NzOMEICjtfW/kbfLDwwM/abZELJ7Qp+Bnic4N6tklXOECU4P1h6O8BdmoeSzDnofMSVUihhJnerj 5Em49dd8ijJvL5jabUT5jNfmIJlcHHTmCTowoBbW9rDj+/Y44vLoVkfdcce06TNSt4b/8KwWcH36 5phKVHrlx0bNOyaggrxYfXKCheFEGb3xIPsd/+vcUQs29QIDAQABo4IDWzCCA1cwDAYDVR0TBAUw AwEB/zALBgNVHQ8EBAMCAaYwHQYDVR0OBBYEFK5Vg2/sMcq59x36r2sx88gd46y7MIGoBgNVHSME gaAwgZ2AFE4L7xqkQFulF2mHMMo0aEPQQa7yoYGBpH8wfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p bmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5ggEBMAkGA1UdEgQC MAAwPQYIKwYBBQUHAQEEMTAvMC0GCCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9z ZnNjYS5jcnQwYAYDVR0fBFkwVzAsoCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3Nmc2Nh LWNybC5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQQwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMBEGCWCGSAGG+EIBAQQEAwIABzBQBglghkgBhvhCAQ0EQxZBU3RhcnRDb20gQ2xhc3MgMiBQ cmltYXJ5IEludGVybWVkaWF0ZSBGcmVlIFNTTCBFbWFpbCBDZXJ0aWZpY2F0ZXMwDQYJKoZIhvcN AQEFBQADggIBAB73EBf+9umEeS+QN02uyVdZ07t8PclqqdNPeOaYO7nmvtSlbUf+/8njRQFezD0M pTxPKUThHBlPkcMAxbjZ/XHj3wDMzgU6cv+lRNO+voGJGWuJ/Llmi+QNhVaPLUZhMn6E+IES/QeY ecPGOGckgiQS8n6eIwcssR2k0yFmfEyJMVEC0gXhZ5hymBcGMDGwQNEoG/DjQr6vc3iXKTJJA2nY SUgnwfXPYGaHG2mlR1ak5UnhDUa+f2N9XWqcyEUINj5fVfwOuQqtNykMTFwaV5/B5Czv4NhQreym JCQmk3uqk9iV/LYZgd52/uUZrVkCCEwj/jzzZBUArbOrozrScek5Qy1gPrVe0CzdkPkvfKf0sJ14 raPhltDe5F3C/EAwVbBfJQr8As/iUK71CHFucRM6QFZPcUm6Xj8VSDMzRFEIQaG5BaI4VKhrflcl Nxh//gT9m685eErTidSl7sNhMxbNGovTjLKglBUcocpJujK257J0q6oVkp0kD2CLvs6c8Fgv/LGR caCQsL22yLvuhPgCBmvLT/qWBfnpqT5/+6ZCKE0+C0pJBCMRir1LwyU4fOlQzS/GyCEBNix1Q8HD qvpnEMeNehQAPTcNQwRsqxa+oUHuck1V6yeBu7yaLDURgsD58d9NoKJ2hXcIvvmMqoz8oTzuquH0 Wq2L1sqqeS+lMYICGjCCAhYCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICAtIw CQYFKw4DAhoFAKBdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEx MDYxNDA1NTkzMlowIwYJKoZIhvcNAQkEMRYEFBMkhGqggDoPL5lckUefjxt+U83kMA0GCSqGSIb3 DQEBAQUABIIBAF0CYEt8oYSQpmzPWqfjStZV6igWgTWBtSJkUU2e+EERnEMI7FmgB8rTcjY0wGaG 89jKWXWel51bf4m/DhIhAPMtY4/TAz49V4owgGMSL12SE5xcLYFNQo/L1iEnFmTYaw1cQ5qQAXVl uDGXHnIHQqiU3rGLUz8rLNGSsmCYfy5pV9E6NhT3/mnXnnMesmGs5yW90mcBThq+SSnHrKK7s7Ce cxyNSrI1wAWnbPyPnrB0vwdKX9XyoYaQpbvh1I+34FVHlZSk8s6/xRM+FGIammtynDKdNK/5O4W/ LUjJOmQWMLRqi+gRmG+xGodWS4+D+NXM5ufw8XBI2SW6CLf0asYAAAAAAAA= --=-IyAaDaW/VeVYsFxb5ZRA-- From ajs@anvilwalrusden.com Tue Jun 14 05:31:05 2011 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 8E013228014 for ; Tue, 14 Jun 2011 05:31:05 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkHPObtuhxmM for ; Tue, 14 Jun 2011 05:31:05 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 080BE9E8004 for ; Tue, 14 Jun 2011 05:31:04 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 2A2861ECB41C for ; Tue, 14 Jun 2011 12:31:03 +0000 (UTC) Date: Tue, 14 Jun 2011 08:31:01 -0400 From: Andrew Sullivan To: provreg@ietf.org Message-ID: <20110614112749.GA65259@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [provreg] An alternative to bulk access EPP extensions or IRIS 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, 14 Jun 2011 12:31:05 -0000 Dear colleagues, The recent discussion about bulk access reporting and the widespread lack of IRIS deployment is timely, because some of us are making another run at whois. There are currently four drafts available on this topic: draft-fiorelli-weirds-rws, draft-kucherawy-weirds-requirements, draft-newton-weirds-arin-whoisrws, and draft-sheng-weirds-icann-rws-dnrd. (You can find all of these by going to http://tools.ietf.org/id/weirds). "WEIRDS" stands for WHOIS-based Extensible Internet Registration Data Service. We've also got a mailing list set up: https://www.ietf.org/mailman/listinfo/weirds. We are actively seeking comment on the drafts. Best, Andrew -- Andrew Sullivan ajs@anvilwalrusden.com From gavin.brown@centralnic.com Tue Jun 14 06:33:07 2011 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 2DFA621F8504 for ; Tue, 14 Jun 2011 06:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ql-VIpUviSgN for ; Tue, 14 Jun 2011 06:33:05 -0700 (PDT) Received: from smtp.centralnic.com (smtp.centralnic.com [193.105.170.131]) by ietfa.amsl.com (Postfix) with ESMTP id DAEEE21F84FC for ; Tue, 14 Jun 2011 06:33:04 -0700 (PDT) Received: from [10.63.74.90] (staffgw.zmg.lon.uk.centralnic.net [82.68.174.118]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTP id 6A473712BC9 for ; Tue, 14 Jun 2011 13:33:02 +0000 (UTC) From: Gavin Brown To: provreg@ietf.org Content-Type: text/plain; charset="UTF-8" Organization: CentralNic Ltd Date: Tue, 14 Jun 2011 14:33:02 +0100 Message-ID: <1308058382.22854.27.camel@scimitar.gb.zmg.lon.uk.centralnic.net> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit Subject: [provreg] Another look at the data model for launch phase registrations 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, 14 Jun 2011 13:33:07 -0000 Hi all, I've been cogitating on the sort of data model that would meet our requirements, based on the discussions on this list and also with other people in the trademark world. I'm proposing a new data model for "sunrise" phases, where applicants generally have a claim over a string based on a trade mark, which may be registered with a national authority, or a "common law" trademark such as a company name. The model is flexible in that multiple claims may be submitted - as Jothan suggested previously - and the specific nature of each claim may be described. Applicants can also signal which authority has registered their claim by using normal contact objects to identify trademark offices, company registers, and so on. Here's a rough description of the model. I've included some example request frames below. Comments appreciated. The element of the element: * MUST have an , assigned by the server when the application is created * MUST have 1 or more codes from the set: [pending, validated, invalid, cancelled, allocated] (Q: possibly others?) * MUST have a from the set [SR, LR] (Q: should we let servers define further phases?) * if phase=SR, MAY have one or more elements. a : * MUST have a boolean "preVerified" attribute * if preVerified=1: * MUST have a element * MAY have a element. an : * identities a contact object in the registry * identifies the name, address, contact information of the issuing authority * MAY be created by the client (ie open approach) or the server (ie closed approach), depending on server policy * if preVerified=0: * MUST have at least one: * identifying the text string in which the applicant has a claim, * OR * identifying the registered trade mark * MAY have a from the set [registered, unregistered] ("unregistered" covers company names and "common law" trademarks) * MUST have a from the ISO 3166-alpha2 set * MAY have . a may contain the name of a city, state, province or other region in which the claim is valid * MAY have an . an : * identities a contact object in the registry * identifies the name, address, contact information of the issuing authority * MAY be created by the client (ie open approach) or the server (ie closed approach), depending on server policy * MAY have a from the set [owner, successor, licensee] (Q: any others?) Example request with an application with pre-verified claim: SR abc-12345 CLEARINGHOUSE-CONTACT-ID abc-12345 Example request for a registered trademark with an application with unverified claim: SR Example Corp. TM-1234321 registered US USPTO-CONTACT-ID abc-12345 Example request for a German company name with an application with unverified claim: SR Example GmbH. unregistered DE Bayern MUNICH-COURT-CONTACT-ID abc-12345 Example request for a British company name with an application containing two different claims: > > > > > SR > > abc-12345 > CLEARINGHOUSE-CONTACT-ID > > > > abc-12345 > > > > Example request for a registered trademark with an > application with unverified claim: > > > > > xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> > > > > > > SR > > Example Corp. > TM-1234321 > registered > US > USPTO-CONTACT-ID > > > > abc-12345 > > > > Example request for a German company name with an > application with unverified claim: > > > > > xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> > > > > > > SR > > Example GmbH. > unregistered > DE > Bayern > MUNICH-COURT-CONTACT-ID > > > > abc-12345 > > > > > Example request for a British company name with an > application containing two different claims: > > > > > xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> > 1 0 REQ: urn:ietf:params:xml:ns:rgp-1.0 RES: Command completed successfully As I said, this is just a rough sketch and needs a lot of work, but I believe the basic idea to be sound. I'm very much open to any input. If this is too invasive to the protocol, an alternative would be to have a standard machine-readable format for registries to publish this information. -- Keith Gaughan, Software Developer PGP/GPG key ID: 3E896381 Blacknight Internet Solutions Ltd. 12A Barrowside Business Park, Carlow, Ireland Registered in Ireland, Company No.: 370845 From gavin.brown@centralnic.com Thu Jun 16 10:32:45 2011 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 71FB711E8250 for ; Thu, 16 Jun 2011 10:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moC71VAQ5O7x for ; Thu, 16 Jun 2011 10:32:44 -0700 (PDT) Received: from smtp.centralnic.com (smtp.centralnic.com [193.105.170.131]) by ietfa.amsl.com (Postfix) with ESMTP id 3000411E80E0 for ; Thu, 16 Jun 2011 10:32:43 -0700 (PDT) Received: from [10.42.42.146] (genkt-056-071.t-mobile.co.uk [149.254.56.71]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTP id 2A5F1712B8D; Thu, 16 Jun 2011 17:32:42 +0000 (UTC) References: <4DFA358B.5090605@blacknight.com> In-Reply-To: <4DFA358B.5090605@blacknight.com> Mime-Version: 1.0 (iPad Mail 8H7) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (8H7) From: Gavin Brown Date: Thu, 16 Jun 2011 18:33:45 +0100 To: Keith Gaughan Cc: "provreg@ietf.org" Subject: Re: [provreg] Proposal: A method in EPP for registry policy discovery 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: Thu, 16 Jun 2011 17:32:45 -0000 I'm not sure that server policy should be communicated via EPP. EPP is not a= general-purpose registry-registrar communications protocol, it's an object p= rovisioning and management protocol. As an alternative solution, how about this: an additional element in the ser= ver element that contains a URI, which points to an XML document t= hat describes the policy elements you've suggested? This would have the adva= ntage of being reusable: eg, every CoCCA based registry could point to a pol= icy document on CoCCA's web site. G. --=20 Gavin Brown Chief Technology Officer CentralNic Global Registry Services Innovative Registry Services for ccTLD and gTLD registries https://www.centralnic.com/grs CentralNic Ltd is a company registered in England and Wales with company number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR. On 16 Jun 2011, at 17:55, Keith Gaughan wrote: > This proposal comes out of the comments Jothan has been making recently, w= hich > I agree wholeheartedly with. >=20 > As a registrar, one of our great problems registry policy discovery. This i= s > of particular importance with it comes to ccTLDs, whose policies can vary > drastically. For instance: >=20 > * what commands does the registry support with particular objects, > * what is the lifecycle of a domain in a particular zone, > * does removing a domain from redemption incur a cost to the registrar, > * how long after registration, transfer, and renewal must it be before a > domain can be transferred or renewed, > * what periods does a registry support for registrations, transfers, and > renewals, > * does the registry support the poll command, > * for contacts, which types does the element support (this is= a > crapshoot and registries, in my experience, never document this), > * does the registry support registrant modification, > * are there per-command limits. >=20 > These are just the ones I could think of off the top of my head. >=20 > For this, I'd propose a command, possibly called , which would wor= k > along the following lines. This would take a single child element, either > or , which would contain the URI of the object or extensi= on > whose policy is being queried. For example, here are some rough sketches o= f > response: >=20 > REQ: > > > > urn:ietf:params:xml:ns:epp-1.0 > > >=20 > RES: > > > > > Command completed successfully > > > > > > > > > > > > > >=20 > REQ: > > > > urn:ietf:params:xml:ns:domain-1.0 > > >=20 > RES: > > > > > Command completed successfully > > > > > > > > > > > > > > > > > > 1 > > > > 0 > > > > > > > >=20 > REQ: > > > > urn:ietf:params:xml:ns:rgp-1.0 > > >=20 > RES: > > > > > Command completed successfully > > > > > > > > > > > hasRestoreFee=3D"yes"/> > > > > > >=20 > As I said, this is just a rough sketch and needs a lot of work, but I beli= eve > the basic idea to be sound. I'm very much open to any input. >=20 > If this is too invasive to the protocol, an alternative would be to have a= > standard machine-readable format for registries to publish this informatio= n. >=20 > --=20 > Keith Gaughan, Software Developer > PGP/GPG key ID: 3E896381 > Blacknight Internet Solutions Ltd. > 12A Barrowside Business Park, Carlow, Ireland > Registered in Ireland, Company No.: 370845 > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg From Klaus.Malorny@knipp.de Thu Jun 16 23:50:35 2011 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 BDCB821F84AE for ; Thu, 16 Jun 2011 23:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgXhBa1PLB+o for ; Thu, 16 Jun 2011 23:50:35 -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 3AAC521F84AD for ; Thu, 16 Jun 2011 23:50:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 9C8F749; Fri, 17 Jun 2011 08:50:32 +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 4-LDx+-ruG2v; Fri, 17 Jun 2011 08:50:27 +0200 (MESZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id CE7EA77; Fri, 17 Jun 2011 08:50:26 +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 p5H6oM82003526; Fri, 17 Jun 2011 08:50:26 +0200 (MESZ) Message-ID: <4DFAF92E.90104@knipp.de> Date: Fri, 17 Jun 2011 08:50:22 +0200 From: Klaus Malorny User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Keith Gaughan References: <4DFA2E85.1010607@blacknight.com> In-Reply-To: <4DFA2E85.1010607@blacknight.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: provreg@ietf.org Subject: Re: [provreg] Proposal: A standard EPP OT&E test suite for each object type and extension type 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: Fri, 17 Jun 2011 06:50:35 -0000 On 16/06/11 18:25, Keith Gaughan wrote: > Hello, all. > > [...] Secondly, it would mean that > registrars would only need to run through the test suite *once*, which would > greatly reduce the management overhead for both registrars and registries > during accreditation. A central registry, likely maintained by ICANN, listing > whether a registrar has successfully completed a particular part of the test > suite, would also be useful. > > If ICANN does, in fact, sanction the creation of a large number of new gTLDs, > this could be a big deal. > Hi, as a side note, I'd like to express that accreditation tests that require registrars to perform certain operations on a test system in a certain order with certain parameters is IMHO completely useless and a waste of (human) resources. As soon as a registrar starts to write a custom script to perform the test instead of simply trying to let his registration system interact with the registry's system, the proof loses its value. And to my experience, this happens in most of the cases. For this reason, we as a registry operator are trying to convince the TLD sponsor not to demand the execution of a technical accreditation test by the registrar at all. Regards, Klaus From Klaus.Malorny@knipp.de Fri Jun 17 00:11:49 2011 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 F273011E80CB for ; Fri, 17 Jun 2011 00:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYKnWDO0BGky for ; Fri, 17 Jun 2011 00:11:48 -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 281CA11E8083 for ; Fri, 17 Jun 2011 00:11:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id C1C7282; Fri, 17 Jun 2011 09:11:37 +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 1K8LB0hvVMPZ; Fri, 17 Jun 2011 09:11:32 +0200 (MESZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 4012E80; Fri, 17 Jun 2011 09:11:32 +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 p5H7BU7I007039; Fri, 17 Jun 2011 09:11:30 +0200 (MESZ) Message-ID: <4DFAFE22.4090404@knipp.de> Date: Fri, 17 Jun 2011 09:11:30 +0200 From: Klaus Malorny User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Gavin Brown References: <4DFA358B.5090605@blacknight.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "provreg@ietf.org" Subject: Re: [provreg] Proposal: A method in EPP for registry policy discovery 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: Fri, 17 Jun 2011 07:11:49 -0000 On 16/06/11 19:33, Gavin Brown wrote: > I'm not sure that server policy should be communicated via EPP. EPP is not a > general-purpose registry-registrar communications protocol, it's an object > provisioning and management protocol. > > As an alternative solution, how about this: an additional element in the > server element that contains a URI, which points to an XML > document that describes the policy elements you've suggested? This would have > the advantage of being reusable: eg, every CoCCA based registry could point > to a policy document on CoCCA's web site. > > G. > Hi, this is arguable, but the question of how the policies are accessed is IMHO not the main issue. To me, the big question is how expressive, how flexible such policy descriptors should be. A formalized policy only makes sense if it is targeted to be processed automatically by the registrar's software. If the schema is too restricted, registries cannot express their actual policy and the registrar software will fall into traps; if it is too flexible, the flexibility will mostly stay unused (registry-wise) on the one hand and will require huge implementation efforts on the registrar side to cover all potential cases on the other hand. Regards, Klaus From volker.janzen@internetx.de Fri Jun 17 00:11:53 2011 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 D323011E8109 for ; Fri, 17 Jun 2011 00:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGr2YJGS-SRO for ; Fri, 17 Jun 2011 00:11:52 -0700 (PDT) Received: from web4.internetx.de (gate2.mailgate.de [62.116.129.39]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBC211E80F2 for ; Fri, 17 Jun 2011 00:11:50 -0700 (PDT) Received: from [192.168.100.46] (pizza.internetx.de [62.116.129.3]) (authenticated bits=0) by web4.internetx.de (8.13.8/8.13.8) with ESMTP id p5H7Bj2H023081 for ; Fri, 17 Jun 2011 09:11:48 +0200 Message-ID: <4DFAFE39.1010602@internetx.de> Date: Fri, 17 Jun 2011 09:11:53 +0200 From: InterNetX - Volker Janzen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: provreg@ietf.org References: <4DFA2E85.1010607@blacknight.com> <4DFAF92E.90104@knipp.de> In-Reply-To: <4DFAF92E.90104@knipp.de> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig834E46C4CC1D1CBAC1F89B4E" Subject: Re: [provreg] Proposal: A standard EPP OT&E test suite for each object type and extension type 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: Fri, 17 Jun 2011 07:11:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig834E46C4CC1D1CBAC1F89B4E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, Am 17.06.2011 08:50, schrieb Klaus Malorny: > as a side note, I'd like to express that accreditation tests that > require registrars to perform certain operations on a test system in a > certain order with certain parameters is IMHO completely useless and a > waste of (human) resources. As soon as a registrar starts to write a > custom script to perform the test instead of simply trying to let his > registration system interact with the registry's system, the proof lose= s > its value. I agree with this. I know many registries that have a test catalogue which forces registrars to do such scripting, because the test cases are far away from production use. In this case, 0% to 10% of the productive EPP implementation is tested. In my work I had rare circumstances where a registry instructed us to run our own custom tests. In that cases we run our own test-suite which covers > 90% of EPP production usage. We were very happy with this and it was no problem to send a few extra commands, that were not part of the test to satisfy the registry that we've everything up and running. Volker Janzen Team Entwicklung --=20 InterNetX GmbH Maximilianstr. 6 93047 Regensburg Germany Tel: +49 941 59559-0 Fax: +49 941 59579-050 www.internetx.com www.facebook.com/InterNetX www.twitter.com/InterNetX Gesch=E4ftsf=FChrer/CEO: Thomas M=F6rz Amtsgericht Regensburg, HRB 7142 GPG-Key: 0x186C5F77 GPG-Fingerprint: 392E 8730 FE23 DCE8 8878 8524 5361 BCCC 186C 5F77 --------------enig834E46C4CC1D1CBAC1F89B4E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk36/j0ACgkQU2G8zBhsX3f8vgCeLN7oT5G4cuhcLmv47IkpAUqE zA0An0fSBNU/kHL/xjTXBTpkKqqPS+9H =tnjK -----END PGP SIGNATURE----- --------------enig834E46C4CC1D1CBAC1F89B4E-- From wil@cloudregistry.net Fri Jun 17 01:09:12 2011 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 95F8811E8096 for ; Fri, 17 Jun 2011 01:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qm--VU3l143W for ; Fri, 17 Jun 2011 01:09:12 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id AB2B311E80C2 for ; Fri, 17 Jun 2011 01:09:11 -0700 (PDT) Received: by qyk29 with SMTP id 29so797427qyk.10 for ; Fri, 17 Jun 2011 01:09:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.129.4 with SMTP id m4mr1217696qas.166.1308298150938; Fri, 17 Jun 2011 01:09:10 -0700 (PDT) Received: by 10.229.7.69 with HTTP; Fri, 17 Jun 2011 01:09:10 -0700 (PDT) In-Reply-To: <4DFAF92E.90104@knipp.de> References: <4DFA2E85.1010607@blacknight.com> <4DFAF92E.90104@knipp.de> Date: Fri, 17 Jun 2011 18:09:10 +1000 Message-ID: From: Wil Tan To: Klaus Malorny Content-Type: multipart/alternative; boundary=0016e64ba7188c096f04a5e3e659 Cc: provreg@ietf.org Subject: Re: [provreg] Proposal: A standard EPP OT&E test suite for each object type and extension type 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: Fri, 17 Jun 2011 08:09:12 -0000 --0016e64ba7188c096f04a5e3e659 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 17, 2011 at 4:50 PM, Klaus Malorny wrote: > On 16/06/11 18:25, Keith Gaughan wrote: > >> Hello, all. >> >> [...] Secondly, it would mean that >> >> registrars would only need to run through the test suite *once*, which >> would >> greatly reduce the management overhead for both registrars and registries >> during accreditation. A central registry, likely maintained by ICANN, >> listing >> whether a registrar has successfully completed a particular part of the >> test >> suite, would also be useful. >> >> If ICANN does, in fact, sanction the creation of a large number of new >> gTLDs, >> this could be a big deal. >> >> > Hi, > > as a side note, I'd like to express that accreditation tests that require > registrars to perform certain operations on a test system in a certain order > with certain parameters is IMHO completely useless and a waste of (human) > resources. As soon as a registrar starts to write a custom script to perform > the test instead of simply trying to let his registration system interact > with the registry's system, the proof loses its value. And to my experience, > this happens in most of the cases. For this reason, we as a registry > operator are trying to convince the TLD sponsor not to demand the execution > of a technical accreditation test by the registrar at all. > > Concur. We see no value in it and don't require it on our registry system either. -- Wil Tan CTO Cloud Registry --0016e64ba7188c096f04a5e3e659 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Jun 17, 2011 at 4:50 PM, Klaus M= alorny <Klau= s.Malorny@knipp.de> wrote:
On 16/06/11 18:25, Keith Gaughan wrote:
Hello, all.

[...] Secondly, it would mean that

registrars would only need to run through the test suite *once*, which woul= d
greatly reduce the management overhead for both registrars and registries during accreditation. A central registry, likely maintained by ICANN, listi= ng
whether a registrar has successfully completed a particular part of the tes= t
suite, would also be useful.

If ICANN does, in fact, sanction the creation of a large number of new gTLD= s,
this could be a big deal.


Hi,

as a side note, I'd like to express that accreditation tests that requi= re registrars to perform certain operations on a test system in a certain o= rder with certain parameters is IMHO completely useless and a waste of (hum= an) resources. As soon as a registrar starts to write a custom script to pe= rform the test instead of simply trying to let his registration system inte= ract with the registry's system, the proof loses its value. And to my e= xperience, this happens in most of the cases. For this reason, we as a regi= stry operator are trying to convince the TLD sponsor not to demand the exec= ution of a technical accreditation test by the registrar at all.


Concur. We see no value in it and don&= #39;t require it on our registry system either.

--
Wil T= an
CTO
Cloud Registry <ht= tp://www.cloudregistry.net>
--0016e64ba7188c096f04a5e3e659-- From jim@rfc1035.com Fri Jun 17 02:27:38 2011 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 3C1709E800E for ; Fri, 17 Jun 2011 02:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.145 X-Spam-Level: X-Spam-Status: No, score=-2.145 tagged_above=-999 required=5 tests=[AWL=-0.146, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSDXq6GrKe+X for ; Fri, 17 Jun 2011 02:27:37 -0700 (PDT) Received: from hutch.rfc1035.com (hutch.rfc1035.com [195.54.233.70]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB619E8007 for ; Fri, 17 Jun 2011 02:27:37 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id 7ABC215420A1; Fri, 17 Jun 2011 10:27:33 +0100 (BST) Message-Id: <4F856B27-20D8-4807-B6B3-77999521D25A@rfc1035.com> From: Jim Reid To: Keith Gaughan In-Reply-To: <4DFA2E85.1010607@blacknight.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 17 Jun 2011 10:27:33 +0100 References: <4DFA2E85.1010607@blacknight.com> X-Mailer: Apple Mail (2.936) Cc: provreg@ietf.org Subject: Re: [provreg] Proposal: A standard EPP OT&E test suite 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: Fri, 17 Jun 2011 09:27:38 -0000 On 16 Jun 2011, at 17:25, Keith Gaughan wrote: > A standard EPP test suite from OT&E would, I think, serve two > important > purposes. IMO, it would have a much more important benefit than the ones you list. It would encourage registries to stick to the functionality of that test suite and not stray into the world of registry-specific quirks and EPP hooks. That would be a Good Thing. OTOH, this could be difficult for some registries to do, particularly ccTLDs, because local policy and/or legislation requires registry-specific quirks and EPP hooks. > Secondly, it would mean that registrars would only need to run > through the test suite *once*, which would greatly reduce the > management overhead for both registrars and registries during > accreditation. In theory yes. In reality, perhaps not. For instance, the contact object schema for .tel had to be extended to accommodate flags for an opt-out from whois. This was specific to the TLD. That sort of tweak probably wouldn't be in this standard test suite. Those kinds of extensions will sometimes be unavoidable, even in the usual one size fits all model of the gTLD world. The E of EPP is a big hint here. :-) FWIW some registrars initially failed OT&E accreditation for .tel even though they'd done that for other TLDs run by the same registry provider. I don't remember (and today I don't care) what caused those failures. I do recall it was the registrars who said ".tel is just like all the other Neustar-operated gTLDs" that tended to have difficulties. I don't know if they'd used the supplied toolkits or dusted down their own (Neustar-specific?) EPP clients that had been sitting on a shelf somewhere. Maybe they just didn't read the documentation. From ulrich@wisser.se Fri Jun 17 02:40:05 2011 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 1BFDC11E807A for ; Fri, 17 Jun 2011 02:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gW5Z9D+Ru-fO for ; Fri, 17 Jun 2011 02:40:04 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE7B9E800D for ; Fri, 17 Jun 2011 02:40:03 -0700 (PDT) Received: by iwn39 with SMTP id 39so2461274iwn.31 for ; Fri, 17 Jun 2011 02:40:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.161.3 with SMTP id r3mr1779997icx.186.1308303602759; Fri, 17 Jun 2011 02:40:02 -0700 (PDT) Sender: ulrich@wisser.se Received: by 10.42.226.130 with HTTP; Fri, 17 Jun 2011 02:40:02 -0700 (PDT) In-Reply-To: <4DFAFE39.1010602@internetx.de> References: <4DFA2E85.1010607@blacknight.com> <4DFAF92E.90104@knipp.de> <4DFAFE39.1010602@internetx.de> Date: Fri, 17 Jun 2011 11:40:02 +0200 X-Google-Sender-Auth: rUKFip3axjTEfaM0jytVAZ594uo Message-ID: From: Ulrich Wisser To: InterNetX - Volker Janzen Content-Type: multipart/alternative; boundary=90e6ba6e8e588038ae04a5e52b89 Cc: provreg@ietf.org Subject: Re: [provreg] Proposal: A standard EPP OT&E test suite for each object type and extension type 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: Fri, 17 Jun 2011 09:40:05 -0000 --90e6ba6e8e588038ae04a5e52b89 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, at .SE we require such a test. We do provide test data and require registrars to perform some (as we like to think) real world tasks. We do no= t care about issued EPP commands but rather the final state of the objects. We did not get a lot of feedback (none so far) on this procedure from registrars. Please take your chances and mail some feedback on of off list. Thanks in advance Ulrich 2011/6/17 InterNetX - Volker Janzen > Hi all, > > Am 17.06.2011 08:50, schrieb Klaus Malorny: > > as a side note, I'd like to express that accreditation tests that > > require registrars to perform certain operations on a test system in a > > certain order with certain parameters is IMHO completely useless and a > > waste of (human) resources. As soon as a registrar starts to write a > > custom script to perform the test instead of simply trying to let his > > registration system interact with the registry's system, the proof lose= s > > its value. > > I agree with this. I know many registries that have a test catalogue > which forces registrars to do such scripting, because the test cases are > far away from production use. In this case, 0% to 10% of the productive > EPP implementation is tested. > > In my work I had rare circumstances where a registry instructed us to > run our own custom tests. In that cases we run our own test-suite which > covers > 90% of EPP production usage. We were very happy with this and > it was no problem to send a few extra commands, that were not part of > the test to satisfy the registry that we've everything up and running. > > > Volker Janzen > Team Entwicklung > > -- > InterNetX GmbH > Maximilianstr. 6 > 93047 Regensburg > Germany > > Tel: +49 941 59559-0 > Fax: +49 941 59579-050 > > www.internetx.com > www.facebook.com/InterNetX > www.twitter.com/InterNetX > > Gesch=C3=A4ftsf=C3=BChrer/CEO: Thomas M=C3=B6rz > Amtsgericht Regensburg, HRB 7142 > > GPG-Key: 0x186C5F77 > GPG-Fingerprint: 392E 8730 FE23 DCE8 8878 8524 5361 BCCC 186C 5F77 > > > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg > > --90e6ba6e8e588038ae04a5e52b89 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi,

at .SE we require such a test. We do provide test da= ta and require registrars to perform some (as we like to think) real world = tasks. We do not care about issued EPP commands but rather the final state = of the objects.

We did not get a lot of feedback (none so far) on this = procedure from registrars.
Please take your chances and mail some= feedback on of off list.

Thanks in advance

Ulrich



2011/6/17 InterNetX - Volker Janzen <volker.janzen@internetx.de>=
Hi all,

Am 17.06.2011 08:50, schrieb Klaus Malorny:
> as a side note, I'd like to express that accreditation tests that<= br> > require registrars to perform certain operations on a test system in a=
> certain order with certain parameters is IMHO completely useless and a=
> waste of (human) resources. As soon as a registrar starts to write a > custom script to perform the test instead of simply trying to let his<= br> > registration system interact with the registry's system, the proof= loses
> its value.

I agree with this. I know many registries that have a test catalogue
which forces registrars to do such scripting, because the test cases are far away from production use. In this case, 0% to 10% of the productive
EPP implementation is tested.

In my work I had rare circumstances where a registry instructed us to
run our own custom tests. In that cases we run our own test-suite which
covers > 90% of EPP production usage. We were very happy with this and it was no problem to send a few extra commands, that were not part of
the test to satisfy the registry that we've everything up and running.<= br>

Volker Janzen
Team Entwicklung

--
InterNetX GmbH
Maximilianstr. 6
93047 Regensburg
Germany

Tel: +49 941 59559-0
Fax: +49 941 59579-050

www.internetx.com
www.faceboo= k.com/InterNetX
www.twitter.= com/InterNetX

Gesch=C3=A4ftsf=C3=BChrer/CEO: Thomas M=C3=B6rz
Amtsgericht Regensburg, HRB 7142

GPG-Key: 0x186C5F77
GPG-Fingerprint: 392E 8730 FE23 DCE8 8878 8524 5361 BCCC 186C 5F77


_______________________________________________
provreg mailing list
provreg@ietf.org
https://www.ietf.org/mailman/listinfo/provreg


--90e6ba6e8e588038ae04a5e52b89-- From paf@cisco.com Fri Jun 17 02:45:12 2011 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 70CA421F8475 for ; Fri, 17 Jun 2011 02:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.939 X-Spam-Level: X-Spam-Status: No, score=-9.939 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndOCNrRsevqb for ; Fri, 17 Jun 2011 02:45:11 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7132E21F8474 for ; Fri, 17 Jun 2011 02:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paf@cisco.com; l=990; q=dns/txt; s=iport; t=1308303911; x=1309513511; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Xb+xteFrXi62DvfCZAPV+ylkL8mZY90G+dhS3wCKGSQ=; b=LKeHTKNJn3kSjwOHIy3KuK4kz3t+d4B6hNRUuWID7/gW3EHOQZziuD8+ 7oqR6mv+Uc8JDQL30swJs+UFWg+QWIPgl57vk4Zx6YK3pieZtWYwO1IDn gqr9VpoKEVenrurqfz6X+DNq55H0R8VFs164X3l7hpS5ztqMEUmDvYhrF M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALUh+02Q/khL/2dsb2JhbABSpm53iHOhFp4ahicEhx6KQJAK X-IronPort-AV: E=Sophos;i="4.65,380,1304294400"; d="scan'208";a="35708458" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 17 Jun 2011 09:44:43 +0000 Received: from dhcp-10-55-93-9.cisco.com (dhcp-10-55-93-9.cisco.com [10.55.93.9]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5H9ifRR008963; Fri, 17 Jun 2011 09:44:42 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Fri, 17 Jun 2011 17:44:40 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DFA2E85.1010607@blacknight.com> <4DFAF92E.90104@knipp.de> <4DFAFE39.1010602@internetx.de> To: Ulrich Wisser X-Mailer: Apple Mail (2.1084) Cc: provreg@ietf.org Subject: Re: [provreg] Proposal: A standard EPP OT&E test suite for each object type and extension type 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: Fri, 17 Jun 2011 09:45:12 -0000 On 17 jun 2011, at 17.40, Ulrich Wisser wrote: > We did not get a lot of feedback (none so far) on this procedure from > registrars. Good process, largest problem for registrars is (I claim) that different = registries have so different epp and model. Take "how to do a transfer" for example. Or even "register a domain = name". Or requirements on what codepoints can be used for registrations. You registries, can you list what commands are needed for a transfer for = a domain from one registrar to another? Have you been thinking of whether what you require is same/different = from others *before* you decided on how transfers are made in = interactions with you? I do understand if there are say 2-5 different business models etc, but = one per registry, that is (to be honest, but sorry for the language -- I = am exaggerating a bit of course) "just silly". I do not see that being = needed or good for domain name registrations in the world. Patrik From jim@rfc1035.com Fri Jun 17 03:03:41 2011 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 BC2E19E801A for ; Fri, 17 Jun 2011 03:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LO8nh8gxDNes for ; Fri, 17 Jun 2011 03:03:41 -0700 (PDT) Received: from hutch.rfc1035.com (hutch.rfc1035.com [195.54.233.70]) by ietfa.amsl.com (Postfix) with ESMTP id 255989E800D for ; Fri, 17 Jun 2011 03:03:41 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id 208A215420A1; Fri, 17 Jun 2011 11:03:35 +0100 (BST) Message-Id: <94C1FF5C-4155-4FBF-81DC-56E37A2240DF@rfc1035.com> From: Jim Reid To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 17 Jun 2011 11:03:34 +0100 References: <4DFA2E85.1010607@blacknight.com> <4DFAF92E.90104@knipp.de> <4DFAFE39.1010602@internetx.de> X-Mailer: Apple Mail (2.936) Cc: provreg@ietf.org Subject: Re: [provreg] Proposal: A standard EPP OT&E test suite for each object type and extension type 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: Fri, 17 Jun 2011 10:03:41 -0000 On 17 Jun 2011, at 10:44, Patrik F=E4ltstr=F6m wrote: > I do understand if there are say 2-5 different business models etc, =20= > but one per registry, that is (to be honest, but sorry for the =20 > language -- I am exaggerating a bit of course) "just silly". I do =20 > not see that being needed or good for domain name registrations in =20 > the world. True. However with 200+ countries in the world, that pretty much means 200+ =20= different business models because there are 200+ different registry =20 policies or national laws.... :-( It might be better to approach this from a different direction. How =20 about defining a standard set of registry transactions -- create/=20 delete/modify objects, renew and transfer a domain name, etc -- and =20 writing this up as a BCP? Once that's done, the BCP could be encoded =20 in a standard test suite. In other words, document what it is that's =20 to be tested before developing a test suite. Some tests might be =20 optional (for instance IDN and DNSSEC might not be deployed in places) =20= while others are mandatory.= From paf@cisco.com Fri Jun 17 03:09:07 2011 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 E63689E8020 for ; Fri, 17 Jun 2011 03:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.917 X-Spam-Level: X-Spam-Status: No, score=-9.917 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9splliKehxi for ; Fri, 17 Jun 2011 03:09:07 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id C66AF9E801A for ; Fri, 17 Jun 2011 03:09:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paf@cisco.com; l=1482; q=dns/txt; s=iport; t=1308305347; x=1309514947; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=MzajVEmxmYUdxrZs8DcOce4/aKdQ7RyHsH/JYw7HjuI=; b=Y06vpp//ZwhYRI3oNNubr2AgFvaAUpui5YqJ2ZVYSB6xUkxOgK7YzkTm 8q2ADI5h/8gsaJsBUcPJRtrH62iXN7nv43FIT95BhUSvZj0xIlQo5KCSA FWnUuWw55TEVvQI1zjy001H1pwbL9AG/gFWobk1jDh8TPv7KPWGyviZhe E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJ8m+02Q/khM/2dsb2JhbABSpm53iHOgfJ4ahicEhx6KQJAK X-IronPort-AV: E=Sophos;i="4.65,380,1304294400"; d="scan'208";a="94505684" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 17 Jun 2011 10:09:02 +0000 Received: from dhcp-10-55-93-9.cisco.com (dhcp-10-55-93-9.cisco.com [10.55.93.9]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5HA90ed022908; Fri, 17 Jun 2011 10:09:01 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <94C1FF5C-4155-4FBF-81DC-56E37A2240DF@rfc1035.com> Date: Fri, 17 Jun 2011 18:08:59 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DFA2E85.1010607@blacknight.com> <4DFAF92E.90104@knipp.de> <4DFAFE39.1010602@internetx.de> <94C1FF5C-4155-4FBF-81DC-56E37A2240DF@rfc1035.com> To: Jim Reid X-Mailer: Apple Mail (2.1084) Cc: provreg@ietf.org Subject: Re: [provreg] Proposal: A standard EPP OT&E test suite for each object type and extension type 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: Fri, 17 Jun 2011 10:09:08 -0000 On 17 jun 2011, at 18.03, Jim Reid wrote: > However with 200+ countries in the world, that pretty much means 200+ = different business models because there are 200+ different registry = policies or national laws.... :-( Well, not really. Let me take an example: When you do transfer of a domain, what happens with the host and contact = objects that are bound to the domain? What notifications are sent, and = what actions have to be taken? I think, even though we have 200+ different business models, I claim = those can be implemented with only say 3-5 different ways of doing = transfer. > It might be better to approach this from a different direction. How = about defining a standard set of registry transactions -- = create/delete/modify objects, renew and transfer a domain name, etc -- = and writing this up as a BCP? Once that's done, the BCP could be encoded = in a standard test suite. In other words, document what it is that's to = be tested before developing a test suite. Some tests might be optional = (for instance IDN and DNSSEC might not be deployed in places) while = others are mandatory. I fully support this. And is implicitly what I am asking for. That = registries try to, before they invent their own epp architecture, look = carefully at if they can not reuse what someone else is doing. I do not see that happening today. Not as much as I as an implementor in = the registrar side would like to see. Patrik From keith@blacknight.com Fri Jun 17 03:22:25 2011 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 C0E9B9E8024 for ; Fri, 17 Jun 2011 03:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChoSQPjaV03B for ; Fri, 17 Jun 2011 03:22:25 -0700 (PDT) Received: from relay2.blacknight.com (relay2.blacknight.com [78.153.203.205]) by ietfa.amsl.com (Postfix) with ESMTP id 16D039E801A for ; Fri, 17 Jun 2011 03:22:24 -0700 (PDT) Received: from hegemon.blacknight.ie (hegemon.blacknight.ie [81.17.243.239]) by relay2.blacknight.com (Postfix) with ESMTP id 454EC394042 for ; Fri, 17 Jun 2011 11:22:22 +0100 (IST) Message-ID: <4DFB2ADD.8080003@blacknight.com> Date: Fri, 17 Jun 2011 11:22:21 +0100 From: Keith Gaughan Organization: Blacknight Internet Solutions User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: provreg@ietf.org References: <4DFA2E85.1010607@blacknight.com> <4DFAF92E.90104@knipp.de> <4DFAFE39.1010602@internetx.de> <94C1FF5C-4155-4FBF-81DC-56E37A2240DF@rfc1035.com> In-Reply-To: <94C1FF5C-4155-4FBF-81DC-56E37A2240DF@rfc1035.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [provreg] Proposal: A standard EPP OT&E test suite for each object type and extension type 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: Fri, 17 Jun 2011 10:22:25 -0000 On 17/06/11 11:03, Jim Reid wrote: > On 17 Jun 2011, at 10:44, Patrik Fältström wrote: > >> I do understand if there are say 2-5 different business models etc, but one >> per registry, that is (to be honest, but sorry for the language -- I am >> exaggerating a bit of course) "just silly". I do not see that being needed >> or good for domain name registrations in the world. > > True. > > However with 200+ countries in the world, that pretty much means 200+ > different business models because there are 200+ different registry policies > or national laws.... :-( > > It might be better to approach this from a different direction. How about > defining a standard set of registry transactions -- create/delete/modify > objects, renew and transfer a domain name, etc -- and writing this up as a > BCP? Once that's done, the BCP could be encoded in a standard test suite. In > other words, document what it is that's to be tested before developing a test > suite. Some tests might be optional (for instance IDN and DNSSEC might not be > deployed in places) while others are mandatory. That's not a million miles from what I was originally thinking, and personally I'm very much behind this idea. It may help discourage unnecessarily heterodox design decisions by future registry operators. K. -- Keith Gaughan, Software Developer PGP/GPG key ID: 3E896381 Blacknight Internet Solutions Ltd. 12A Barrowside Business Park, Carlow, Ireland Registered in Ireland, Company No.: 370845 From keith@blacknight.com Fri Jun 17 03:32:11 2011 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 488669E8024 for ; Fri, 17 Jun 2011 03:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6eH5IJAk2SD for ; Fri, 17 Jun 2011 03:32:10 -0700 (PDT) Received: from relay2.blacknight.com (relay2.blacknight.com [78.153.203.205]) by ietfa.amsl.com (Postfix) with ESMTP id AC6379E801A for ; Fri, 17 Jun 2011 03:32:10 -0700 (PDT) Received: from hegemon.blacknight.ie (hegemon.blacknight.ie [81.17.243.239]) by relay2.blacknight.com (Postfix) with ESMTP id D2FAC394042 for ; Fri, 17 Jun 2011 11:32:09 +0100 (IST) Message-ID: <4DFB2D29.5090103@blacknight.com> Date: Fri, 17 Jun 2011 11:32:09 +0100 From: Keith Gaughan Organization: Blacknight Internet Solutions User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: provreg@ietf.org References: <4DFA2E85.1010607@blacknight.com> <4F856B27-20D8-4807-B6B3-77999521D25A@rfc1035.com> In-Reply-To: <4F856B27-20D8-4807-B6B3-77999521D25A@rfc1035.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Proposal: A standard EPP OT&E test suite 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: Fri, 17 Jun 2011 10:32:11 -0000 On 17/06/11 10:27, Jim Reid wrote: > On 16 Jun 2011, at 17:25, Keith Gaughan wrote: > >> A standard EPP test suite from OT&E would, I think, serve two important >> purposes. > > IMO, it would have a much more important benefit than the ones you list. It > would encourage registries to stick to the functionality of that test suite > and not stray into the world of registry-specific quirks and EPP hooks. That > would be a Good Thing. OTOH, this could be difficult for some registries to > do, particularly ccTLDs, because local policy and/or legislation requires > registry-specific quirks and EPP hooks. Excellent point. >> Secondly, it would mean that registrars would only need to run through the >> test suite *once*, which would greatly reduce the management overhead for >> both registrars and registries during accreditation. > > In theory yes. In reality, perhaps not. For instance, the contact object > schema for .tel had to be extended to accommodate flags for an opt-out from > whois. Key there is that they used NeuStar's catch-all extension for arbitrary key-value pairs. Frankly, when that thing gets involved, *all* bets are off. > This was specific to the TLD. That sort of tweak probably wouldn't be > in this standard test suite. Those kinds of extensions will sometimes be > unavoidable, even in the usual one size fits all model of the gTLD world. The > E of EPP is a big hint here. :-) Yep, and it happened again with the .tel landrush to a certain degree, but the underlying semantics of the EPP envelope and the domain mapping themselves remained the same. Nothing's perfect. :-) K. -- Keith Gaughan, Software Developer PGP/GPG key ID: 3E896381 Blacknight Internet Solutions Ltd. 12A Barrowside Business Park, Carlow, Ireland Registered in Ireland, Company No.: 370845 From Klaus.Malorny@knipp.de Fri Jun 17 03:37:05 2011 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 A1C6911E80A6 for ; Fri, 17 Jun 2011 03:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iC8JE9pEzIDg for ; Fri, 17 Jun 2011 03:37:04 -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 B7B9911E808C for ; Fri, 17 Jun 2011 03:37:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 207524A; Fri, 17 Jun 2011 12:37:04 +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 Ztrhjdy1SpYw; Fri, 17 Jun 2011 12:36:58 +0200 (MESZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id A419949; Fri, 17 Jun 2011 12:36:58 +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 p5HAawak017712; Fri, 17 Jun 2011 12:36:58 +0200 (MESZ) Message-ID: <4DFB2E4B.6090500@knipp.de> Date: Fri, 17 Jun 2011 12:36:59 +0200 From: Klaus Malorny User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Jim Reid References: <4DFA2E85.1010607@blacknight.com> <4F856B27-20D8-4807-B6B3-77999521D25A@rfc1035.com> In-Reply-To: <4F856B27-20D8-4807-B6B3-77999521D25A@rfc1035.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: provreg@ietf.org Subject: Re: [provreg] Proposal: A standard EPP OT&E test suite 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: Fri, 17 Jun 2011 10:37:05 -0000 On 17/06/11 11:27, Jim Reid wrote: > In theory yes. In reality, perhaps not. For instance, the contact object schema > for .tel had to be extended to accommodate flags for an opt-out from whois. This > was specific to the TLD. That sort of tweak probably wouldn't be in this > standard test suite. Those kinds of extensions will sometimes be unavoidable, > even in the usual one size fits all model of the gTLD world. The E of EPP is a > big hint here. :-) > Hi Jim, sorry, but this was the wrong example for extending the EPP. I could give details, but I don't want to start a general bashing here. :-) Regards, Klaus