From michael@mwyoung.ca Sun Jan 1 14:48:25 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B545011E8081 for ; Sun, 1 Jan 2012 14:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.32 X-Spam-Level: X-Spam-Status: No, score=-1.32 tagged_above=-999 required=5 tests=[AWL=-2.079, BAYES_05=-1.11, DATE_IN_PAST_06_12=1.069, J_CHICKENPOX_33=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VN0UyW9qDSRv for ; Sun, 1 Jan 2012 14:48:25 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 157ED11E8080 for ; Sun, 1 Jan 2012 14:48:24 -0800 (PST) Received: by qcsf15 with SMTP id f15so10935117qcs.31 for ; Sun, 01 Jan 2012 14:48:24 -0800 (PST) Received: by 10.224.116.144 with SMTP id m16mr55173258qaq.19.1325458104482; Sun, 01 Jan 2012 14:48:24 -0800 (PST) Received: from [172.16.1.47] (CPEf81edff844ad-CM00080da07047.cpe.net.cable.rogers.com. [99.226.80.88]) by mx.google.com with ESMTPS id q14sm88735181qap.4.2012.01.01.14.48.22 (version=SSLv3 cipher=OTHER); Sun, 01 Jan 2012 14:48:23 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Sun, 01 Jan 2012 17:49:41 +0530 From: MICHAEL YOUNG To: Francisco Obispo , Jim Reid Message-ID: Thread-Topic: Domain check in draft-obispo-epp-idn-00.txt In-Reply-To: <5C5A839D-6ED7-4B77-94CE-1B48489C938B@isc.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: provreg@ietf.org Subject: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2012 22:48:25 -0000 BTW on language versus script I agree fully, it should be language not script, On another note: Francisco I am looking again at the old IDN I-D http://tools.ietf.org/id/draft-sienkiewicz-epp-idn-00.txt and note that your draft excludes the check command. An operational nit: So the reason it was included in the sienkiewicz draft is to reduce operational overhead. If the registrar is unsure whether a character is included in the relevant language table (or a combination of characters) they can perform a domain check with the questionable punycode. If its not included in the implementation's language table or the combination is not permitted, the domaincheck comes back as not available with a specified reason. Note that the term script is used interchangeably with the concept of language. It was a poor choice at the time to not clear make the distinction but it was intended in implementation that the idn:script element value was really a "language tag". It probably should read something like idn:langtag instead. These examples are all from the .Info implementation for german "de" C: C: CLI-1097602657409 C: C: C: de C: C: C: C: When a request contains an IDN whose translated punycode value contains character(s) that are not in the script table specified in the element value, the element MUST indicate that the IDN is NOT available. Example response when value has conflict with the value of element: S: S: S: S: Command completed successfully S: S: S: S: S: xn--dn-mja.info S: Character from an invalid script S: S: S: S: S: S: CLI-1065207438144 S: SRO-1097599157873 S: S: S: This saves having to fail a domain create discover the same thing, a more expensive transaction for the registry. Now of course with the excessive add grace policy with GTLDs, you also probably don't want to generate creates experimentally, even if you delete them in the five day add grace period - you might end up getting charged. Best Regards, Michael Young M:647-289-1220 > From keith@blacknight.com Wed Jan 4 10:46:08 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB1F21F86E1 for ; Wed, 4 Jan 2012 10:46:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.855 X-Spam-Level: X-Spam-Status: No, score=-2.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6pEj41Lbrj5 for ; Wed, 4 Jan 2012 10:46:07 -0800 (PST) Received: from relay1.blacknight.com (relay1.blacknight.com [78.153.203.204]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBA221F86AE for ; Wed, 4 Jan 2012 10:46:06 -0800 (PST) Received: from hegemon.blacknight.ie (hegemon.blacknight.ie [81.17.243.239]) by relay1.blacknight.com (Postfix) with ESMTP id 8E41035C46E for ; Wed, 4 Jan 2012 18:46:04 +0000 (GMT) Message-ID: <4F049E6C.7060100@blacknight.com> Date: Wed, 04 Jan 2012 18:46:04 +0000 From: Keith Gaughan Organization: Blacknight Internet Solutions User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: provreg@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 18:46:08 -0000 On 01/01/12 12:19, MICHAEL YOUNG wrote: > BTW on language versus script I agree fully, it should be language not > script, > > On another note: > > Francisco I am looking again at the old IDN I-D > http://tools.ietf.org/id/draft-sienkiewicz-epp-idn-00.txt and note that > your draft excludes the check command. > > An operational nit: > > So the reason it was included in the sienkiewicz draft is to reduce > operational overhead. If the registrar is unsure whether a character is > included in the relevant language table (or a combination of characters) > they can perform a domain check with the questionable punycode. If its not > included in the implementation's language table or the combination is not > permitted, the domaincheck comes back as not available with a specified > reason. No, this simply shoves the responsibility onto the registrar. That means the registrar has two choices: either put in a speed bump to ask the customer the language (bingo! potential lost sale) or use some heuristic to guess the language at checking time using codepoint/language whitelists.[1] Moreover, it complicates slows down the implementation of checking for the registrar. Say a customer decides they want to register a bunch of French-, German-, Italian-, and Spanish-language domains. This isn't unlikely: they might be a pan-European body who wants to register the local variants of their name. If the registrar is forced to include the a language code when checking, that means they have to submit separate check commands for each language. That slows things down a lot unless the registry supports pipelining, which is far from likely. This is the more important issue. So, from a registrar's perspective, requiring a language tag to be specified when checking simply makes the life of the customer and registrar more difficult just so as the registry can save a few cycles. > This saves having to fail a domain create discover the same thing, a more > expensive transaction for the registry. It doesn't, and as I outlined above, it's feasible for the registrar, when they're doing the domain availability check, to make sure that the domain matches at least one of the codepoint tables for a language supported by the registrar. This way they can avoid transactions for domains that would fail anyway (and thus avoid a failing transaction later). There's a big advantage for the registrar to do this: it allows the registrar to narrow down the list of languages that the IDN might be for, and thus impose less of a UI burden on the customer, especially if the IDN matches one and only one table, in which case the customer doesn't need to be asked what language the IDN is in at all. Affordances like these are important to making the process of selling domains as smooth as possible. So, while I'm fine with asking a language code in a request, asking it as part of a request makes no sense from a registrar's or customer's point of view. K. [1] In fact, this is what we do ourselves in our own storefront for .biz and .tel IDNs to avoid having to ask the customer for a language code when all they're doing is seeing if the domain is available in the first place. -- Keith Gaughan, Senior Developer PGP/GPG key ID: 3E896381 Blacknight Internet Solutions Ltd. 12A Barrowside Business Park, Carlow, Ireland Registered in Ireland, Company No.: 370845 From patrik@frobbit.se Wed Jan 4 11:18:17 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1AF811E8087 for ; Wed, 4 Jan 2012 11:18:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.311 X-Spam-Level: X-Spam-Status: No, score=-102.311 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYXDCUM1sxnY for ; Wed, 4 Jan 2012 11:18:17 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 2E04521F865F for ; Wed, 4 Jan 2012 11:18:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id E608C12B662F5; Wed, 4 Jan 2012 20:18:14 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGF6BVumPN25; Wed, 4 Jan 2012 20:18:14 +0100 (CET) Received: from [IPv6:2a02:80:3ffc::14] (unknown [IPv6:2a02:80:3ffc::14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id C2DC412B662EE; Wed, 4 Jan 2012 20:18:14 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <4F049E6C.7060100@blacknight.com> Date: Wed, 4 Jan 2012 20:18:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F049E6C.7060100@blacknight.com> To: Keith Gaughan X-Mailer: Apple Mail (2.1251.1) Cc: provreg@ietf.org Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 19:18:17 -0000 On 4 jan 2012, at 19:46, Keith Gaughan wrote: > No, this simply shoves the responsibility onto the registrar. I agree. Checking MUST be done at the registry. Registrar push whatever domain name it believes might be possible to = register. Either that succeeds or the registry is giving a result back = that can be presented to the user. So the registrar do broad filtering and helps the registrant, but then = registry is doing the work. Patrik From ajs@anvilwalrusden.com Wed Jan 4 12:11:15 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03CE921F8705 for ; Wed, 4 Jan 2012 12:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgfGOoS1mfz6 for ; Wed, 4 Jan 2012 12:10:51 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5EF21F86BE for ; Wed, 4 Jan 2012 12:10:50 -0800 (PST) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 89DE11ECB41C for ; Wed, 4 Jan 2012 20:10:45 +0000 (UTC) Date: Wed, 4 Jan 2012 15:10:38 -0500 From: Andrew Sullivan To: provreg@ietf.org Message-ID: <20120104201038.GA32606@crankycanuck.ca> References: <20111222002234.8359.14617.idtracker@ietfa.amsl.com> <0CB499D3-A9F7-4D3B-A7BA-6410E306BD25@frobbit.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [provreg] New Version Notification for draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 20:11:16 -0000 Hi all, Doing some catch-up. Sorry for coming in late. On Wed, Dec 21, 2011 at 10:10:52PM -0800, Francisco Obispo wrote: > Looking at the IDN implementation guidelines, item #5 states: > > 5.All code points in a single label will be taken from the same > script as determined by the Unicode Standard Annex #24: Script > Names . Exceptions to this > guideline are permissible for languages with established > orthographies and conventions that require the commingled use of > multiple scripts. i.e. "every language in the world". It turns out that there is a major problem with this guideline in general use, even if it turns out to work for some languages for TLDs: most languages need some things from Common or Inherited. That is true even of LDH labels. You might get around this by hand-waving Common and Inherited, but then you have a different problem. For instance, suppose you wanted to permit the traditional digits 0-9; they're Common. But if you said that Latin implicitly included everything in Common, you'd implicitly include 0660..0669, which are ARABIC-INDIC DIGIT ZERO..ARABIC-INDIC DIGIT NINE. Which is presumably not what you wanted. Worse, > So it would not be possible to have multiple languages associated to a label. you're conflating "language" and "script" here, since the restriction above is about scripts and not languages. > XML Schema "language" type[1]: > > [Definition:] language represents natural language identifiers as defined by by [RFC 3066][2] . The ·value space· of language is the set of all strings that I guess this reference ought to be changed to 4646? Anyway, that doesn't wholly help you, becuase just because you have an identifier doesn't mean you have a reasonable repertoire of characters. More broadly, I'd like it a lot if people went and looked at the discussion of zone repertoires and the label generation rules in the recent ICANN Variant Issues Project (announcement here: http://www.icann.org/en/announcements/announcement-2-23dec11-en.htm). I came to believe over the last six or so months that neither "language" nor "script" is what we want here, and I think it would be extremely helpful to have some other eyes on the discussion of this issue in that report. While the report is actually aimed only at the top level, I think this part of the report is broadly applicable to any zone that has to serve a linguistically diverse population (i.e. pretty much every gTLD and some ccTLDs too). Best regards, A -- Andrew Sullivan From ajs@anvilwalrusden.com Wed Jan 4 12:25:17 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D5511E809B for ; Wed, 4 Jan 2012 12:25:17 -0800 (PST) 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=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45FMeSayK2U2 for ; Wed, 4 Jan 2012 12:25:17 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 1F95711E8098 for ; Wed, 4 Jan 2012 12:25:17 -0800 (PST) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 786FC1ECB41C for ; Wed, 4 Jan 2012 20:25:16 +0000 (UTC) Date: Wed, 4 Jan 2012 15:25:14 -0500 From: Andrew Sullivan To: provreg@ietf.org Message-ID: <20120104202514.GB32606@crankycanuck.ca> References: <20111222002234.8359.14617.idtracker@ietfa.amsl.com> <0CB499D3-A9F7-4D3B-A7BA-6410E306BD25@frobbit.se> <4EF35621.4030306@blacknight.com> <26EFA6A5-66F2-4F5D-8E2E-817D4CAB3EDC@rfc1035.com> <4EF36E9B.5000705@blacknight.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4EF36E9B.5000705@blacknight.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [provreg] language (or script?) tagging in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 20:25:17 -0000 On Thu, Dec 22, 2011 at 05:53:31PM +0000, Keith Gaughan wrote: > Instead, 'writing system'[1] would be better: so long as the writing system > contains no homographs[2], there's no issue. Alas, most alphabetic languages are full of homographs. But I bet that isn't what you mean, anyway; homograph turns out to have an established meaning in linguistics, and it isn't "two letters that look the same". In the ICANN VIP discussions we settled on "homoglyph" as a possibly useful alternative. Cary Karp has extensive opinions about this. > [1] By which I mean, all the languages that use the Latin alphabet could be > said to share a common script and writing system, which are both the same > thing. It's not an ideal term, I know. Indeed, it's wrong, as a consideration of the fall-back handling of o-with-diaeresis in Swedish and German illustrates. German considers ö to be an o with an accent on it. In Swedish, it's a separate letter. That's why German orthography can fall back to "oe" but Swedish doesn't. > [3] I can't recall whether Traditional and Simplified Han characters occupy > different code points in general, or the same ones. They're different code points, and different Abstract Characters in Unicode terms; but there are usually pairs (with some nasty corner cases) of the same Conceptual Characters in TC and SC. Also, since they're all part of Unihan, they're all "the same script". Slightly worse, Japanese uses the same code points, and they have a _different_ pair of Old Form/New Form changes that were undertaken, but they don't exactly regard them as the same Conceptual Characters. This is because, I'm told by our friends at JPRS, they consider domain names to be proper nouns and therefore always to be spelled exactly one way. Best regards, A -- Andrew Sullivan From fobispo@isc.org Wed Jan 4 12:36:30 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E38611E80A5 for ; Wed, 4 Jan 2012 12:36:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Nm5M4d-d6VM for ; Wed, 4 Jan 2012 12:36:28 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 7497611E80A1 for ; Wed, 4 Jan 2012 12:36:28 -0800 (PST) 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 258515F98AF; Wed, 4 Jan 2012 20:36:13 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [192.168.1.103] (unknown [190.202.176.226]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 975AD216C6E; Wed, 4 Jan 2012 20:36:10 +0000 (UTC) (envelope-from fobispo@isc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Francisco Obispo In-Reply-To: <20120104201038.GA32606@crankycanuck.ca> Date: Wed, 4 Jan 2012 12:35:48 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111222002234.8359.14617.idtracker@ietfa.amsl.com> <0CB499D3-A9F7-4D3B-A7BA-6410E306BD25@frobbit.se> <20120104201038.GA32606@crankycanuck.ca> To: Andrew Sullivan X-Mailer: Apple Mail (2.1251.1) Cc: provreg@ietf.org Subject: Re: [provreg] New Version Notification for draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 20:36:30 -0000 On Jan 4, 2012, at 12:10 PM, Andrew Sullivan wrote: > Hi all, >=20 > Doing some catch-up. Sorry for coming in late. Hi Andrew, thanks for your comments, >=20 > On Wed, Dec 21, 2011 at 10:10:52PM -0800, Francisco Obispo wrote: >=20 >> Looking at the IDN implementation guidelines, item #5 states: >>=20 >> 5.All code points in a single label will be taken from the same >> script as determined by the Unicode Standard Annex #24: Script >> Names . Exceptions to this >> guideline are permissible for languages with established=20 >> orthographies and conventions that require the commingled use of >> multiple scripts. >=20 > i.e. "every language in the world". It turns out that there is a > major problem with this guideline in general use, even if it turns out > to work for some languages for TLDs: most languages need some things > from Common or Inherited. That is true even of LDH labels.=20 >=20 > You might get around this by hand-waving Common and Inherited, but > then you have a different problem. For instance, suppose you wanted > to permit the traditional digits 0-9; they're Common. But if you said > that Latin implicitly included everything in Common, you'd implicitly > include 0660..0669, which are ARABIC-INDIC DIGIT ZERO..ARABIC-INDIC > DIGIT NINE. Which is presumably not what you wanted. >=20 > Worse, >=20 >> So it would not be possible to have multiple languages associated to = a label. >=20 > you're conflating "language" and "script" here, since the restriction > above is about scripts and not languages. =20 >=20 >> XML Schema "language" type[1]: >>=20 >> [Definition:] language represents natural language identifiers as = defined by by [RFC 3066][2] . The =B7value space=B7 of language is the = set of all strings that >=20 > I guess this reference ought to be changed to 4646? >=20 > Anyway, that doesn't wholly help you, becuase just because you have an > identifier doesn't mean you have a reasonable repertoire of > characters. I wasn't implying that, the appropriate repertoire of characters = associated with a particular value, will be given by the registry.. Most = registries publish their supported registration characters in IANA [1] What might be needed (for additional flexibility), is to remove the = "language" type in the XML Schema, for a simple "String" so that it can = be defined by the registry on will.. Basically it will work as a = 'selector' of a specific registry policy to be applied to the = registration. >=20 > More broadly, I'd like it a lot if people went and looked at the > discussion of zone repertoires and the label generation rules in the > recent ICANN Variant Issues Project (announcement here: > http://www.icann.org/en/announcements/announcement-2-23dec11-en.htm). > I came to believe over the last six or so months that neither > "language" nor "script" is what we want here, and I think it would be > extremely helpful to have some other eyes on the discussion of this > issue in that report. While the report is actually aimed only at the > top level, I think this part of the report is broadly applicable to > any zone that has to serve a linguistically diverse population > (i.e. pretty much every gTLD and some ccTLDs too). >=20 +1 > Best regards, >=20 Thanks! > A >=20 > --=20 > Andrew Sullivan > > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg [1] http://www.iana.org/domains/idn-tables Francisco Obispo=20 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 michael@mwyoung.ca Wed Jan 4 12:37:51 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B10A121F860F for ; Wed, 4 Jan 2012 12:37:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLgoKuE6cTY3 for ; Wed, 4 Jan 2012 12:37:51 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD4A21F860D for ; Wed, 4 Jan 2012 12:37:51 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so15064488vcb.31 for ; Wed, 04 Jan 2012 12:37:50 -0800 (PST) Received: by 10.221.13.196 with SMTP id pn4mr36627207vcb.74.1325709470393; Wed, 04 Jan 2012 12:37:50 -0800 (PST) Received: from [10.78.189.100] ([207.164.79.100]) by mx.google.com with ESMTPS id dr7sm1542442vdb.1.2012.01.04.12.37.48 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Jan 2012 12:37:49 -0800 (PST) References: <4F049E6C.7060100@blacknight.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <4E713373-4FFE-43E7-8625-F81AC86CF1E9@mwyoung.ca> X-Mailer: iPhone Mail (9A405) From: Michael Young Date: Wed, 4 Jan 2012 15:37:43 -0500 To: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= Cc: "provreg@ietf.org" Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 20:37:51 -0000 What can I say, it would be great if the registrar put that kind of intellig= ence in their storefront and didn't send domain creates that violate a given= language table. Most registrars aren't making that extensive of an effort. Why? What if the r= egistrar messes up on their filter and denies the registrant a registration t= he registry actually allows. Ooops starts to sound like a lawsuit, better th= e registrar makes the registry say no. It's cheaper to say no in domain chec= k than a create. However I think there's room here to satisfy both concerns.= Adjust the domain check ext so the language tag element is optional. No lang= uage tag and it assumes a straight ASCII registration. Then those registrars that want to validate their own work can and registrar= s that aren't sure can test a punycode string against the extended domain ch= eck. This seems like a compromise that works, thoughts? -M On 2012-01-04, at 2:18 PM, Patrik F=C3=A4ltstr=C3=B6m wr= ote: >=20 > On 4 jan 2012, at 19:46, Keith Gaughan wrote: >=20 >> No, this simply shoves the responsibility onto the registrar. >=20 > I agree. >=20 > Checking MUST be done at the registry. >=20 > Registrar push whatever domain name it believes might be possible to regis= ter. Either that succeeds or the registry is giving a result back that can b= e presented to the user. >=20 > So the registrar do broad filtering and helps the registrant, but then reg= istry is doing the work. >=20 > Patrik >=20 > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg From fobispo@isc.org Wed Jan 4 12:45:28 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B7711E808F for ; Wed, 4 Jan 2012 12:45:28 -0800 (PST) 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=[AWL=-0.000, BAYES_00=-2.599, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CmU18nQ79a+e for ; Wed, 4 Jan 2012 12:45:28 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 481AC11E8089 for ; Wed, 4 Jan 2012 12:45:25 -0800 (PST) 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 3A54C5F9899; Wed, 4 Jan 2012 20:45:00 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [192.168.1.103] (unknown [190.202.176.226]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 5711C216C6A; Wed, 4 Jan 2012 20:44:56 +0000 (UTC) (envelope-from fobispo@isc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Francisco Obispo In-Reply-To: <4E713373-4FFE-43E7-8625-F81AC86CF1E9@mwyoung.ca> Date: Wed, 4 Jan 2012 12:44:33 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <29AD57F4-D97A-46A7-BDCA-6DABFCE022AB@isc.org> References: <4F049E6C.7060100@blacknight.com> <4E713373-4FFE-43E7-8625-F81AC86CF1E9@mwyoung.ca> To: Michael Young X-Mailer: Apple Mail (2.1251.1) Cc: "provreg@ietf.org" Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 20:45:28 -0000 I don't see a problem with using the extension during the check command, = it could be used as Michael stated, in a complimentary way, and as = stated, its use could be totally optional from the registrar side. I agree that registrars should be performing those tests/validations = ahead of time and shouldn't rely exclusively on the registry for those = types of validation, because that would increase registry load = significantly. Regards, Francisco On Jan 4, 2012, at 12:37 PM, Michael Young wrote: >=20 > What can I say, it would be great if the registrar put that kind of = intelligence in their storefront and didn't send domain creates that = violate a given language table. >=20 > Most registrars aren't making that extensive of an effort. Why? What = if the registrar messes up on their filter and denies the registrant a = registration the registry actually allows. Ooops starts to sound like a = lawsuit, better the registrar makes the registry say no. It's cheaper to = say no in domain check than a create. However I think there's room here = to satisfy both concerns. >=20 > Adjust the domain check ext so the language tag element is optional. = No language tag and it assumes a straight ASCII registration. >=20 > Then those registrars that want to validate their own work can and = registrars that aren't sure can test a punycode string against the = extended domain check. This seems like a compromise that works, = thoughts? >=20 > -M >=20 >=20 > On 2012-01-04, at 2:18 PM, Patrik F=E4ltstr=F6m = wrote: >=20 >>=20 >> On 4 jan 2012, at 19:46, Keith Gaughan wrote: >>=20 >>> No, this simply shoves the responsibility onto the registrar. >>=20 >> I agree. >>=20 >> Checking MUST be done at the registry. >>=20 >> Registrar push whatever domain name it believes might be possible to = register. Either that succeeds or the registry is giving a result back = that can be presented to the user. >>=20 >> So the registrar do broad filtering and helps the registrant, but = then registry is doing the work. >>=20 >> Patrik >>=20 >> _______________________________________________ >> 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 Francisco Obispo=20 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 patrik@frobbit.se Wed Jan 4 12:55:26 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 746A411E80AF for ; Wed, 4 Jan 2012 12:55:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.31 X-Spam-Level: X-Spam-Status: No, score=-102.31 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcvnubL-TWyV for ; Wed, 4 Jan 2012 12:55:26 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id B165711E809F for ; Wed, 4 Jan 2012 12:55:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id D0EFE12B6844A; Wed, 4 Jan 2012 21:55:24 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAVm0Cjem-xw; Wed, 4 Jan 2012 21:55:24 +0100 (CET) Received: from [IPv6:2a02:80:3ffc::14] (unknown [IPv6:2a02:80:3ffc::14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 7E20612B68442; Wed, 4 Jan 2012 21:55:24 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <4E713373-4FFE-43E7-8625-F81AC86CF1E9@mwyoung.ca> Date: Wed, 4 Jan 2012 21:55:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <55C30604-0432-48E1-885E-C691448B08A9@frobbit.se> References: <4F049E6C.7060100@blacknight.com> <4E713373-4FFE-43E7-8625-F81AC86CF1E9@mwyoung.ca> To: Michael Young X-Mailer: Apple Mail (2.1251.1) Cc: "provreg@ietf.org" Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 20:55:26 -0000 On 4 jan 2012, at 21:37, Michael Young wrote: > What can I say, it would be great if the registrar put that kind of = intelligence in their storefront and didn't send domain creates that = violate a given language table. Regardless of whether they do or not, the registry is what finally says = yes or no to a registration, right? > Most registrars aren't making that extensive of an effort. Why? What = if the registrar messes up on their filter and denies the registrant a = registration the registry actually allows. Ooops starts to sound like a = lawsuit, better the registrar makes the registry say no. It's cheaper to = say no in domain check than a create. However I think there's room here = to satisfy both concerns. >=20 > Adjust the domain check ext so the language tag element is optional. = No language tag and it assumes a straight ASCII registration. Yes, check should of course have the same argument(s) etc as create. > Then those registrars that want to validate their own work can and = registrars that aren't sure can test a punycode string against the = extended domain check. This seems like a compromise that works, = thoughts? Makes sense of course but why do a check and not create directly, that = might fail? You are absolutely correct that a registrar might do a create if they = believe they MIGHT have a success. Specifically if you have a race in = the form of backorder you do, and you are limited in the number of = commands per time unit you are allowed to do. And as you say, a = registrar can not risk rejecting a domain registration for a registrant = that might in fact work. If all registries, and I mean all and not only the gTLD registries that = the accredited registrars run against, had a few fewer extensions, and = used similar rules for things like transfer and whatever else... So, can you please explain what the problem is with having the = registries get some creates that will fail? Then I will understand better. Patrik From michael@mwyoung.ca Wed Jan 4 13:20:02 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 636AC21F8624 for ; Wed, 4 Jan 2012 13:20:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nb0i0-bjkrt1 for ; Wed, 4 Jan 2012 13:20:01 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8B121F85D5 for ; Wed, 4 Jan 2012 13:20:01 -0800 (PST) Received: by vbbfo1 with SMTP id fo1so13977281vbb.31 for ; Wed, 04 Jan 2012 13:19:59 -0800 (PST) Received: by 10.52.90.164 with SMTP id bx4mr28445255vdb.128.1325711999803; Wed, 04 Jan 2012 13:19:59 -0800 (PST) Received: from [10.78.189.100] ([207.164.79.100]) by mx.google.com with ESMTPS id iv10sm9551713vdb.18.2012.01.04.13.19.57 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Jan 2012 13:19:59 -0800 (PST) References: <4F049E6C.7060100@blacknight.com> <4E713373-4FFE-43E7-8625-F81AC86CF1E9@mwyoung.ca> <55C30604-0432-48E1-885E-C691448B08A9@frobbit.se> In-Reply-To: <55C30604-0432-48E1-885E-C691448B08A9@frobbit.se> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <03AFAC20-A409-42BA-92CD-48BCBC9C521D@mwyoung.ca> X-Mailer: iPhone Mail (9A405) From: Michael Young Date: Wed, 4 Jan 2012 16:19:52 -0500 To: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= Cc: "provreg@ietf.org" Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 21:20:02 -0000 Well a domain check is a read only transaction in registry, in a create, you= need to hold that create while you validate it in case someone else is raci= ng for the same unique string. Given load balancers and multiple app servers= you either time synch at the app server or the DB. Most would go for the DB= to lock then you face a rollback if the validation fails. Way back when dom= ain drops weren't rate limited registries faced "add storms". It's not tragi= c with today's rate limiting controls but I still note why would I encourage= any system to do more work unnecessarily,..... Michael Young M:647-289-1220 On 2012-01-04, at 3:55 PM, Patrik F=C3=A4ltstr=C3=B6m wr= ote: > On 4 jan 2012, at 21:37, Michael Young wrote: >=20 >> What can I say, it would be great if the registrar put that kind of intel= ligence in their storefront and didn't send domain creates that violate a gi= ven language table. >=20 > Regardless of whether they do or not, the registry is what finally says ye= s or no to a registration, right? >=20 >> Most registrars aren't making that extensive of an effort. Why? What if t= he registrar messes up on their filter and denies the registrant a registrat= ion the registry actually allows. Ooops starts to sound like a lawsuit, bett= er the registrar makes the registry say no. It's cheaper to say no in domain= check than a create. However I think there's room here to satisfy both conc= erns. >>=20 >> Adjust the domain check ext so the language tag element is optional. No l= anguage tag and it assumes a straight ASCII registration. >=20 > Yes, check should of course have the same argument(s) etc as create. >=20 >> Then those registrars that want to validate their own work can and regist= rars that aren't sure can test a punycode string against the extended domain= check. This seems like a compromise that works, thoughts? >=20 > Makes sense of course but why do a check and not create directly, that mig= ht fail? >=20 > You are absolutely correct that a registrar might do a create if they beli= eve they MIGHT have a success. Specifically if you have a race in the form o= f backorder you do, and you are limited in the number of commands per time u= nit you are allowed to do. And as you say, a registrar can not risk rejectin= g a domain registration for a registrant that might in fact work. >=20 > If all registries, and I mean all and not only the gTLD registries that th= e accredited registrars run against, had a few fewer extensions, and used si= milar rules for things like transfer and whatever else... >=20 > So, can you please explain what the problem is with having the registries g= et some creates that will fail? >=20 > Then I will understand better. >=20 > Patrik >=20 From michele@blacknight.ie Wed Jan 4 13:34:12 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F09C911E80A6 for ; Wed, 4 Jan 2012 13:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.399 X-Spam-Level: X-Spam-Status: No, score=-0.399 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIcpt-x-sRIL for ; Wed, 4 Jan 2012 13:34:11 -0800 (PST) Received: from exchange.blacknight.ie (exchange.blacknight.ie [81.17.243.252]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0AA11E808F for ; Wed, 4 Jan 2012 13:34:10 -0800 (PST) Received: from BKEXCHMBX01.blacknight.local ([fe80::76:af74:8c72:96ac]) by bkexchhubcas01.blacknight.local ([fe80::3ca9:6bf1:bd5d:24b%15]) with mapi id 14.02.0247.003; Wed, 4 Jan 2012 21:34:09 +0000 From: "Michele Neylon :: Blacknight" To: Michael Young Thread-Topic: [provreg] Domain check in draft-obispo-epp-idn-00.txt Thread-Index: AQHMyNeMgK43OEXRaUi75C4m8mrDaJX8kIkAgAAI/ICAABY2gIAABPCAgAAG1wCAAAP7gA== Date: Wed, 4 Jan 2012 21:34:08 +0000 Message-ID: <48C133A6-DF30-4F01-8229-1BEB7BB0FBD8@blacknight.ie> References: <4F049E6C.7060100@blacknight.com> <4E713373-4FFE-43E7-8625-F81AC86CF1E9@mwyoung.ca> <55C30604-0432-48E1-885E-C691448B08A9@frobbit.se> <03AFAC20-A409-42BA-92CD-48BCBC9C521D@mwyoung.ca> In-Reply-To: <03AFAC20-A409-42BA-92CD-48BCBC9C521D@mwyoung.ca> 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="Windows-1252" Content-ID: <6ECFD8A5A823284C933AC38A077AE404@blacknight.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "provreg@ietf.org" Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 21:34:12 -0000 On 4 Jan 2012, at 21:19, Michael Young wrote: > Well a domain check is a read only transaction in registry, in a create, = you need to hold that create while you validate it in case someone else is = racing for the same unique string. Given load balancers and multiple app se= rvers you either time synch at the app server or the DB. Most would go for = the DB to lock then you face a rollback if the validation fails. Way back w= hen domain drops weren't rate limited registries faced "add storms". It's n= ot tragic with today's rate limiting controls but I still note why would I = encourage any system to do more work unnecessarily,=85.. So you want us to do the extra work? :) >=20 > Michael Young >=20 > M:647-289-1220 >=20 > On 2012-01-04, at 3:55 PM, Patrik F=E4ltstr=F6m wrote= : >=20 >> On 4 jan 2012, at 21:37, Michael Young wrote: >>=20 >>> What can I say, it would be great if the registrar put that kind of int= elligence in their storefront and didn't send domain creates that violate a= given language table. >>=20 >> Regardless of whether they do or not, the registry is what finally says = yes or no to a registration, right? >>=20 >>> Most registrars aren't making that extensive of an effort. Why? What if= the registrar messes up on their filter and denies the registrant a regist= ration the registry actually allows. Ooops starts to sound like a lawsuit, = better the registrar makes the registry say no. It's cheaper to say no in d= omain check than a create. However I think there's room here to satisfy bot= h concerns. >>>=20 >>> Adjust the domain check ext so the language tag element is optional. No= language tag and it assumes a straight ASCII registration. >>=20 >> Yes, check should of course have the same argument(s) etc as create. >>=20 >>> Then those registrars that want to validate their own work can and regi= strars that aren't sure can test a punycode string against the extended dom= ain check. This seems like a compromise that works, thoughts? >>=20 >> Makes sense of course but why do a check and not create directly, that m= ight fail? >>=20 >> You are absolutely correct that a registrar might do a create if they be= lieve they MIGHT have a success. Specifically if you have a race in the for= m of backorder you do, and you are limited in the number of commands per ti= me unit you are allowed to do. And as you say, a registrar can not risk rej= ecting a domain registration for a registrant that might in fact work. >>=20 >> If all registries, and I mean all and not only the gTLD registries that = the accredited registrars run against, had a few fewer extensions, and used= similar rules for things like transfer and whatever else... >>=20 >> So, can you please explain what the problem is with having the registrie= s get some creates that will fail? >>=20 >> Then I will understand better. >>=20 >> Patrik >>=20 > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg 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 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From JGould@verisign.com Wed Jan 4 13:40:52 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC821F0C3E for ; Wed, 4 Jan 2012 13:40:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xiviJYI+UaWq for ; Wed, 4 Jan 2012 13:40:51 -0800 (PST) Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) by ietfa.amsl.com (Postfix) with ESMTP id D61CC1F0C3B for ; Wed, 4 Jan 2012 13:40:49 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKTwTHU5P7Vg0D40qpQJXSOJ4MliY4EWMG@postini.com; Wed, 04 Jan 2012 13:40:50 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q04LeUaT005355; Wed, 4 Jan 2012 16:40:32 -0500 Received: from dul1wnexcn04.vcorp.ad.vrsn.com ([10.170.12.139]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Jan 2012 16:40:30 -0500 Received: from BRN1WNEXCAS02.vcorp.ad.vrsn.com ([10.173.152.246]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Jan 2012 16:40:29 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.01.0323.003; Wed, 4 Jan 2012 16:40:29 -0500 From: "Gould, James" To: Francisco Obispo , "provreg@ietf.org" Thread-Topic: [provreg] New Version Notification for draft-obispo-epp-idn-00.txt Thread-Index: AQHMwEFAFwOe8K+MEUujcnLx8RoLzJX80mqA Date: Wed, 4 Jan 2012 21:40:28 +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.12.0.110505 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <2D75EDA85E87844A897AA815BAD5D178@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 04 Jan 2012 21:40:29.0622 (UTC) FILETIME=[7A802D60:01CCCB29] Subject: Re: [provreg] New Version Notification for draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 21:40:52 -0000 Francisco, This draft looks very similar to our custom "IDN Language Tag" extension available at the URL http://www.verisigninc.com/assets/idn-language-tag.pdf. In our custom extension only the create is extended; although I believe including it in the info response is an enhancement driven by the login extension services. We only require the extension for punycode encoded IDN domain names, so my question is if the extension is not included, is the default assumed to be language "en"? I'm assuming that this extension would only be required for IDN registrations based on its name, but it's not clear. Our custom extension includes the text "A valid language tag is a required field for ALL IDN registrations". We require puny code encoded domain name values for the IDN registrations, which is the key to determine if the extension is required. Some verbiage in the draft around when the extension is required and what is the expected behavior for registrations when it's not provided (e.g. default of "en") would be helpful. Use of the XML schema language type is flexible from a protocol perspective, but the registries would need to publish the supported language tag values most likely out-of-band. Hopefully we could define a consistent scheme for the possible language tag values. As far as the thread around adding the extension to the check, I don't see a driver for adding the extension to the check since the check command typically only does a simple availability check and doesn't implement all of the business logic validation that is done in the create. The check needs to be fast and it supports multiple domain names that could have different language tags, thus requiring the registrant to execute multiple checks or adding additional complexity to the idn language tag extension. =20 --=20 JG James Gould Principal Software Engineer jgould@Verisign.com 703-948-3271 21345 Ridgetop Circle LS2-2-1 Dulles, VA 20166 VerisignInc.com On 12/21/11 7:32 PM, "Francisco Obispo" wrote: >Draft for EPP-IDN extension has been submitted. > > > >Begin forwarded message: > >> From: internet-drafts@ietf.org >> Subject: New Version Notification for draft-obispo-epp-idn-00.txt >> Date: December 21, 2011 4:22:34 PM PST >> To: pselkirk@isc.org >> Cc: lem@isc.org, fobispo@isc.org, pselkirk@isc.org >>=20 >> A new version of I-D, draft-obispo-epp-idn-00.txt has been successfully >>submitted by Paul Selkirk and posted to the IETF repository. >>=20 >> Filename: draft-obispo-epp-idn >> Revision: 00 >> Title: Internationalized Domain Name Mapping Extension for the >>Extensible Provisioning Protocol (EPP) >> Creation date: 2011-12-21 >> WG ID: Individual Submission >> Number of pages: 8 >>=20 >> Abstract: >> This document describes an Extensible Provisioning Protocol (EPP) >> extension mapping for the provisioning of Internationalized Domain >> Names (IDN) stored in a shared central repository. This mapping >> extends the EPP domain name mapping to provide additional features >> required to implement registrations of domain names in characters >> sets other than ASCII. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat > >Francisco Obispo=20 >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 > > > > > >_______________________________________________ >provreg mailing list >provreg@ietf.org >https://www.ietf.org/mailman/listinfo/provreg From michael@mwyoung.ca Wed Jan 4 13:48:21 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB84511E80C8 for ; Wed, 4 Jan 2012 13:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.753 X-Spam-Level: X-Spam-Status: No, score=-1.753 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MjBywrMN0c8F for ; Wed, 4 Jan 2012 13:48:21 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D3CCC11E80C7 for ; Wed, 4 Jan 2012 13:48:20 -0800 (PST) Received: by vbbfo1 with SMTP id fo1so14000559vbb.31 for ; Wed, 04 Jan 2012 13:48:20 -0800 (PST) Received: by 10.52.91.7 with SMTP id ca7mr28114724vdb.120.1325713700272; Wed, 04 Jan 2012 13:48:20 -0800 (PST) Received: from [10.78.189.100] ([207.164.79.100]) by mx.google.com with ESMTPS id dr7sm1770646vdb.1.2012.01.04.13.48.19 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Jan 2012 13:48:19 -0800 (PST) References: <4F049E6C.7060100@blacknight.com> <4E713373-4FFE-43E7-8625-F81AC86CF1E9@mwyoung.ca> <55C30604-0432-48E1-885E-C691448B08A9@frobbit.se> <03AFAC20-A409-42BA-92CD-48BCBC9C521D@mwyoung.ca> <48C133A6-DF30-4F01-8229-1BEB7BB0FBD8@blacknight.ie> In-Reply-To: <48C133A6-DF30-4F01-8229-1BEB7BB0FBD8@blacknight.ie> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <90FACA6F-F3A7-46BC-8A98-FCAB2BF34E9A@mwyoung.ca> X-Mailer: iPhone Mail (9A405) From: Michael Young Date: Wed, 4 Jan 2012 16:48:13 -0500 To: "Michele Neylon :: Blacknight" Cc: "provreg@ietf.org" Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 21:48:21 -0000 Well you guys with your countless inexpensive multicore Linux boxes do have t= he horsepower advantage,..... Plus let's face it - you're the smart one ;-) On 2012-01-04, at 4:34 PM, "Michele Neylon :: Blacknight" wrote: >=20 > On 4 Jan 2012, at 21:19, Michael Young wrote: >=20 >> Well a domain check is a read only transaction in registry, in a create, y= ou need to hold that create while you validate it in case someone else is ra= cing for the same unique string. Given load balancers and multiple app serve= rs you either time synch at the app server or the DB. Most would go for the D= B to lock then you face a rollback if the validation fails. Way back when do= main drops weren't rate limited registries faced "add storms". It's not trag= ic with today's rate limiting controls but I still note why would I encourag= e any system to do more work unnecessarily,=E2=80=A6.. >=20 >=20 > So you want us to do the extra work? :) >=20 >=20 >>=20 >> Michael Young >>=20 >> M:647-289-1220 >>=20 >> On 2012-01-04, at 3:55 PM, Patrik F=C3=A4ltstr=C3=B6m = wrote: >>=20 >>> On 4 jan 2012, at 21:37, Michael Young wrote: >>>=20 >>>> What can I say, it would be great if the registrar put that kind of int= elligence in their storefront and didn't send domain creates that violate a g= iven language table. >>>=20 >>> Regardless of whether they do or not, the registry is what finally says y= es or no to a registration, right? >>>=20 >>>> Most registrars aren't making that extensive of an effort. Why? What if= the registrar messes up on their filter and denies the registrant a registr= ation the registry actually allows. Ooops starts to sound like a lawsuit, be= tter the registrar makes the registry say no. It's cheaper to say no in doma= in check than a create. However I think there's room here to satisfy both co= ncerns. >>>>=20 >>>> Adjust the domain check ext so the language tag element is optional. No= language tag and it assumes a straight ASCII registration. >>>=20 >>> Yes, check should of course have the same argument(s) etc as create. >>>=20 >>>> Then those registrars that want to validate their own work can and regi= strars that aren't sure can test a punycode string against the extended doma= in check. This seems like a compromise that works, thoughts? >>>=20 >>> Makes sense of course but why do a check and not create directly, that m= ight fail? >>>=20 >>> You are absolutely correct that a registrar might do a create if they be= lieve they MIGHT have a success. Specifically if you have a race in the form= of backorder you do, and you are limited in the number of commands per time= unit you are allowed to do. And as you say, a registrar can not risk reject= ing a domain registration for a registrant that might in fact work. >>>=20 >>> If all registries, and I mean all and not only the gTLD registries that t= he accredited registrars run against, had a few fewer extensions, and used s= imilar rules for things like transfer and whatever else... >>>=20 >>> So, can you please explain what the problem is with having the registrie= s get some creates that will fail? >>>=20 >>> Then I will understand better. >>>=20 >>> Patrik >>>=20 >> _______________________________________________ >> provreg mailing list >> provreg@ietf.org >> https://www.ietf.org/mailman/listinfo/provreg >=20 > 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 > Direct Dial: +353 (0)59 9183090 > Fax. +353 (0) 1 4811 763 > ------------------------------- > Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleat= y > Road,Graiguecullen,Carlow,Ireland Company No.: 370845 >=20 From michele@blacknight.ie Wed Jan 4 13:52:48 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0542811E80CC for ; Wed, 4 Jan 2012 13:52:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Df8UPtbz-uMu for ; Wed, 4 Jan 2012 13:52:47 -0800 (PST) Received: from exchange.blacknight.ie (exchange.blacknight.ie [81.17.243.252]) by ietfa.amsl.com (Postfix) with ESMTP id 197A511E80C9 for ; Wed, 4 Jan 2012 13:52:42 -0800 (PST) Received: from BKEXCHMBX01.blacknight.local ([fe80::76:af74:8c72:96ac]) by bkexchhubcas01.blacknight.local ([fe80::3ca9:6bf1:bd5d:24b%15]) with mapi id 14.02.0247.003; Wed, 4 Jan 2012 21:52:40 +0000 From: "Michele Neylon :: Blacknight" To: Michael Young Thread-Topic: [provreg] Domain check in draft-obispo-epp-idn-00.txt Thread-Index: AQHMyNeMgK43OEXRaUi75C4m8mrDaJX8kIkAgAAI/ICAABY2gIAABPCAgAAG1wCAAAP7gIAAA/GAgAABPAA= Date: Wed, 4 Jan 2012 21:52:39 +0000 Message-ID: References: <4F049E6C.7060100@blacknight.com> <4E713373-4FFE-43E7-8625-F81AC86CF1E9@mwyoung.ca> <55C30604-0432-48E1-885E-C691448B08A9@frobbit.se> <03AFAC20-A409-42BA-92CD-48BCBC9C521D@mwyoung.ca> <48C133A6-DF30-4F01-8229-1BEB7BB0FBD8@blacknight.ie> <90FACA6F-F3A7-46BC-8A98-FCAB2BF34E9A@mwyoung.ca> In-Reply-To: <90FACA6F-F3A7-46BC-8A98-FCAB2BF34E9A@mwyoung.ca> 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="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "provreg@ietf.org" Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 21:52:48 -0000 On 4 Jan 2012, at 21:48, Michael Young wrote: > Well you guys with your countless inexpensive multicore Linux boxes do ha= ve the horsepower advantage,..... >=20 > Plus let's face it - you're the smart one ;-) G'wan - try charming your way out of it :) >=20 > On 2012-01-04, at 4:34 PM, "Michele Neylon :: Blacknight" wrote: >=20 >>=20 >> On 4 Jan 2012, at 21:19, Michael Young wrote: >>=20 >>> Well a domain check is a read only transaction in registry, in a create= , you need to hold that create while you validate it in case someone else i= s racing for the same unique string. Given load balancers and multiple app = servers you either time synch at the app server or the DB. Most would go fo= r the DB to lock then you face a rollback if the validation fails. Way back= when domain drops weren't rate limited registries faced "add storms". It's= not tragic with today's rate limiting controls but I still note why would = I encourage any system to do more work unnecessarily,=85.. >>=20 >>=20 >> So you want us to do the extra work? :) >>=20 >>=20 >>>=20 >>> Michael Young >>>=20 >>> M:647-289-1220 >>>=20 >>> On 2012-01-04, at 3:55 PM, Patrik F=E4ltstr=F6m wro= te: >>>=20 >>>> On 4 jan 2012, at 21:37, Michael Young wrote: >>>>=20 >>>>> What can I say, it would be great if the registrar put that kind of i= ntelligence in their storefront and didn't send domain creates that violate= a given language table. >>>>=20 >>>> Regardless of whether they do or not, the registry is what finally say= s yes or no to a registration, right? >>>>=20 >>>>> Most registrars aren't making that extensive of an effort. Why? What = if the registrar messes up on their filter and denies the registrant a regi= stration the registry actually allows. Ooops starts to sound like a lawsuit= , better the registrar makes the registry say no. It's cheaper to say no in= domain check than a create. However I think there's room here to satisfy b= oth concerns. >>>>>=20 >>>>> Adjust the domain check ext so the language tag element is optional. = No language tag and it assumes a straight ASCII registration. >>>>=20 >>>> Yes, check should of course have the same argument(s) etc as create. >>>>=20 >>>>> Then those registrars that want to validate their own work can and re= gistrars that aren't sure can test a punycode string against the extended d= omain check. This seems like a compromise that works, thoughts? >>>>=20 >>>> Makes sense of course but why do a check and not create directly, that= might fail? >>>>=20 >>>> You are absolutely correct that a registrar might do a create if they = believe they MIGHT have a success. Specifically if you have a race in the f= orm of backorder you do, and you are limited in the number of commands per = time unit you are allowed to do. And as you say, a registrar can not risk r= ejecting a domain registration for a registrant that might in fact work. >>>>=20 >>>> If all registries, and I mean all and not only the gTLD registries tha= t the accredited registrars run against, had a few fewer extensions, and us= ed similar rules for things like transfer and whatever else... >>>>=20 >>>> So, can you please explain what the problem is with having the registr= ies get some creates that will fail? >>>>=20 >>>> Then I will understand better. >>>>=20 >>>> Patrik >>>>=20 >>> _______________________________________________ >>> provreg mailing list >>> provreg@ietf.org >>> https://www.ietf.org/mailman/listinfo/provreg >>=20 >> 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 >> Direct Dial: +353 (0)59 9183090 >> Fax. +353 (0) 1 4811 763 >> ------------------------------- >> Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sle= aty >> Road,Graiguecullen,Carlow,Ireland Company No.: 370845 >>=20 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 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From ajs@anvilwalrusden.com Wed Jan 4 14:01:02 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 025D111E80CB for ; Wed, 4 Jan 2012 14:01:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHSJSCFBgQ0z for ; Wed, 4 Jan 2012 14:01:01 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 786B511E80A6 for ; Wed, 4 Jan 2012 14:01:01 -0800 (PST) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 169C51ECB41C for ; Wed, 4 Jan 2012 22:01:00 +0000 (UTC) Date: Wed, 4 Jan 2012 17:00:58 -0500 From: Andrew Sullivan To: provreg@ietf.org Message-ID: <20120104220058.GD32606@crankycanuck.ca> References: <4F049E6C.7060100@blacknight.com> <4E713373-4FFE-43E7-8625-F81AC86CF1E9@mwyoung.ca> <55C30604-0432-48E1-885E-C691448B08A9@frobbit.se> <03AFAC20-A409-42BA-92CD-48BCBC9C521D@mwyoung.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03AFAC20-A409-42BA-92CD-48BCBC9C521D@mwyoung.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 22:01:02 -0000 On Wed, Jan 04, 2012 at 04:19:52PM -0500, Michael Young wrote: > Well a domain check is a read only transaction in registry, in a > create, you need to hold that create while you validate it in case > someone else is racing for the same unique string. Given load > balancers and multiple app servers you either time synch at the app > server or the DB. Most would go for the DB to lock then you face a > rollback if the validation fails. There are, of course, other possible implementations, some of which would not face this exact problem. (And indeed, the effects of rollback might be implementation-dependent as well.) Therefore, > Way back when domain drops weren't rate limited registries faced > "add storms". the add storm problem was at least partly an issue related to implementation, and not the protocol itself. While it is clearly a good thing that a client attempt to validate its input as well as possible before submission to an EPP server, it's equally obviously true that sometimes a client is going to be in a race to create an object. The protocol cannot rely on the client having checked that a creation meets registry policy prior to submission. So, while I certainly have no objection to including extensions to the check command (and think it's a good idea), I sure want to make sure nobody is planning to rely on check commands to save us from expensive validation of submitted name objects at create time. Best, A -- Andrew Sullivan From michael@mwyoung.ca Wed Jan 4 16:16:04 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C14221F87C6 for ; Wed, 4 Jan 2012 16:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsBHKf8d5Zgl for ; Wed, 4 Jan 2012 16:16:04 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C74D021F879F for ; Wed, 4 Jan 2012 16:15:59 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so15225938vcb.31 for ; Wed, 04 Jan 2012 16:15:59 -0800 (PST) Received: by 10.220.142.16 with SMTP id o16mr34323632vcu.39.1325722559270; Wed, 04 Jan 2012 16:15:59 -0800 (PST) Received: from [10.99.2.67] ([207.164.79.67]) by mx.google.com with ESMTPS id ic3sm39891408vdb.6.2012.01.04.16.15.57 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Jan 2012 16:15:58 -0800 (PST) References: <4F049E6C.7060100@blacknight.com> <4E713373-4FFE-43E7-8625-F81AC86CF1E9@mwyoung.ca> <55C30604-0432-48E1-885E-C691448B08A9@frobbit.se> <03AFAC20-A409-42BA-92CD-48BCBC9C521D@mwyoung.ca> <20120104220058.GD32606@crankycanuck.ca> In-Reply-To: <20120104220058.GD32606@crankycanuck.ca> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9A405) From: Michael Young Date: Wed, 4 Jan 2012 19:15:49 -0500 To: Andrew Sullivan Cc: "provreg@ietf.org" Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 00:16:04 -0000 Short Answer: I agree the create command has to be able to handle the use ca= ses. Somewhere in all that I noted you were ok with the check ext being opti= onal :-) On 2012-01-04, at 5:00 PM, Andrew Sullivan wrote: > On Wed, Jan 04, 2012 at 04:19:52PM -0500, Michael Young wrote: >=20 >> Well a domain check is a read only transaction in registry, in a >> create, you need to hold that create while you validate it in case >> someone else is racing for the same unique string. Given load >> balancers and multiple app servers you either time synch at the app >> server or the DB. Most would go for the DB to lock then you face a >> rollback if the validation fails. >=20 > There are, of course, other possible implementations, some of which > would not face this exact problem. (And indeed, the effects of > rollback might be implementation-dependent as well.) Therefore, >=20 >> Way back when domain drops weren't rate limited registries faced >> "add storms". >=20 > the add storm problem was at least partly an issue related to > implementation, and not the protocol itself. >=20 > While it is clearly a good thing that a client attempt to validate its > input as well as possible before submission to an EPP server, it's > equally obviously true that sometimes a client is going to be in a > race to create an object. The protocol cannot rely on the client > having checked that a creation meets registry policy prior to > submission. So, while I certainly have no objection to including > extensions to the check command (and think it's a good idea), I sure > want to make sure nobody is planning to rely on check commands to save > us from expensive validation of submitted name objects at create time. >=20 > Best, >=20 > A >=20 > --=20 > Andrew Sullivan > > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg From ajs@anvilwalrusden.com Wed Jan 4 19:34:48 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A679711E808F for ; Wed, 4 Jan 2012 19:34:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.742 X-Spam-Level: X-Spam-Status: No, score=-2.742 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ojYaw28AkZJ for ; Wed, 4 Jan 2012 19:34:48 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id F049711E808C for ; Wed, 4 Jan 2012 19:34:41 -0800 (PST) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 4BD611ECB41C for ; Thu, 5 Jan 2012 03:34:38 +0000 (UTC) Date: Wed, 4 Jan 2012 22:34:31 -0500 From: Andrew Sullivan To: provreg@ietf.org Message-ID: <20120105033431.GA33245@crankycanuck.ca> References: <4F049E6C.7060100@blacknight.com> <4E713373-4FFE-43E7-8625-F81AC86CF1E9@mwyoung.ca> <55C30604-0432-48E1-885E-C691448B08A9@frobbit.se> <03AFAC20-A409-42BA-92CD-48BCBC9C521D@mwyoung.ca> <20120104220058.GD32606@crankycanuck.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 03:34:48 -0000 On Wed, Jan 04, 2012 at 07:15:49PM -0500, Michael Young wrote: > the use cases. Somewhere in all that I noted you were ok with the > check ext being optional :-) Actually, you misread, then. I think servers (implementing this extension) MUST support the extension to check. Clients MAY send it or not (which means that implementation is for practical purposes optional for them. Best, Andrew From michael@mwyoung.ca Wed Jan 4 19:45:05 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5157711E808F for ; Wed, 4 Jan 2012 19:45:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.979 X-Spam-Level: X-Spam-Status: No, score=-2.979 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfmEUp1ZC0yA for ; Wed, 4 Jan 2012 19:45:04 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6510811E808C for ; Wed, 4 Jan 2012 19:45:04 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so105451vcb.31 for ; Wed, 04 Jan 2012 19:45:02 -0800 (PST) Received: by 10.52.89.78 with SMTP id bm14mr177245vdb.22.1325735102758; Wed, 04 Jan 2012 19:45:02 -0800 (PST) Received: from [172.16.1.47] (CPEf81edff844ad-CM00080da07047.cpe.net.cable.rogers.com. [99.226.80.88]) by mx.google.com with ESMTPS id bj19sm14072811vdc.16.2012.01.04.19.44.58 (version=SSLv3 cipher=OTHER); Wed, 04 Jan 2012 19:45:02 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Wed, 04 Jan 2012 22:44:51 -0500 From: MICHAEL YOUNG To: Andrew Sullivan , Message-ID: Thread-Topic: [provreg] Domain check in draft-obispo-epp-idn-00.txt In-Reply-To: <20120105033431.GA33245@crankycanuck.ca> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 03:45:05 -0000 Sorry do you mean if you were designing this from scratch this is what you would do? Or do you mean this is how you read one of the existing proposals (and by that I mean any of the ones mentioned so far)? Michael On 12-01-04 10:34 PM, "Andrew Sullivan" wrote: >On Wed, Jan 04, 2012 at 07:15:49PM -0500, Michael Young wrote: > >> the use cases. Somewhere in all that I noted you were ok with the >> check ext being optional :-) > >Actually, you misread, then. I think servers (implementing this >extension) MUST support the extension to check. Clients MAY send it >or not (which means that implementation is for practical purposes >optional for them. > >Best, > >Andrew >_______________________________________________ >provreg mailing list >provreg@ietf.org >https://www.ietf.org/mailman/listinfo/provreg From patrik@frobbit.se Wed Jan 4 22:45:48 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2006B21F865D for ; Wed, 4 Jan 2012 22:45:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.31 X-Spam-Level: X-Spam-Status: No, score=-102.31 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtHz5LWt-ICZ for ; Wed, 4 Jan 2012 22:45:47 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 51F0821F85D3 for ; Wed, 4 Jan 2012 22:45:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 7FF9D12B7136A; Thu, 5 Jan 2012 07:45:33 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDTpSCpLY-d8; Thu, 5 Jan 2012 07:45:33 +0100 (CET) Received: from [IPv6:2a02:80:3ffc::14] (unknown [IPv6:2a02:80:3ffc::14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 3FF2B12B71363; Thu, 5 Jan 2012 07:45:33 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <03AFAC20-A409-42BA-92CD-48BCBC9C521D@mwyoung.ca> Date: Thu, 5 Jan 2012 07:45:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <274382E8-C7AF-4364-BCC9-941350A063AB@frobbit.se> References: <4F049E6C.7060100@blacknight.com> <4E713373-4FFE-43E7-8625-F81AC86CF1E9@mwyoung.ca> <55C30604-0432-48E1-885E-C691448B08A9@frobbit.se> <03AFAC20-A409-42BA-92CD-48BCBC9C521D@mwyoung.ca> To: Michael Young X-Mailer: Apple Mail (2.1251.1) Cc: "provreg@ietf.org" Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 06:45:48 -0000 On 4 jan 2012, at 22:19, Michael Young wrote: > you need to hold that create while you validate it in case someone = else is racing for the same unique string Why? You want the registrar to do it during a registration if the registrar = is to do a check first, and create afterwards. I.e. the need for a lock MIGHT exist anyway at the time of a = registration, and it is only a question who is doing it. In a registry when you do a create you can as well first do a validation = according to your rules before you do the lock and try to actually do = the registration (creation of a connection between a domain object and a = contact object). So I do not agree with you that you have to do a lock before you = validate that the syntax of the domain name is acceptable. Patrik From patrik@frobbit.se Wed Jan 4 22:49:42 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3BCF21F87A5 for ; Wed, 4 Jan 2012 22:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.309 X-Spam-Level: X-Spam-Status: No, score=-102.309 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTFHD58ZPXsW for ; Wed, 4 Jan 2012 22:49:42 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 03CB321F87A2 for ; Wed, 4 Jan 2012 22:49:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 573F712B714C7; Thu, 5 Jan 2012 07:49:41 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMJpAalDcoEZ; Thu, 5 Jan 2012 07:49:41 +0100 (CET) Received: from [IPv6:2a02:80:3ffc::14] (unknown [IPv6:2a02:80:3ffc::14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 10C6D12B714C0; Thu, 5 Jan 2012 07:49:41 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Thu, 5 Jan 2012 07:49:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: MICHAEL YOUNG X-Mailer: Apple Mail (2.1251.1) Cc: provreg@ietf.org Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 06:49:42 -0000 On 5 jan 2012, at 04:44, MICHAEL YOUNG wrote: > Sorry do you mean if you were designing this from scratch this is what = you > would do? Or do you mean this is how you read one of the existing > proposals (and by that I mean any of the ones mentioned so far)? If we designed epp from the beginning: - We would not have the ability for registries to invent their own = extensions without IETF review (i.e. like other protocols) - We would have optimized a few of the commands (specifically create) so = that it is closer to the business models Example of the 2nd are all the registries that require delegation at = time of registration (something that should be forbidden, but now some = registries are like that), that required creation of contact objects and = host objects before the domain object is created and glued together. If = at that point in time the create fails, the creation of the other = objects would have automatically been undone. Maybe as a transaction, I = do not know. We should have thought about it harder. Patrik > Michael >=20 >=20 >=20 >=20 > On 12-01-04 10:34 PM, "Andrew Sullivan" = wrote: >=20 >> On Wed, Jan 04, 2012 at 07:15:49PM -0500, Michael Young wrote: >>=20 >>> the use cases. Somewhere in all that I noted you were ok with the >>> check ext being optional :-) >>=20 >> Actually, you misread, then. I think servers (implementing this >> extension) MUST support the extension to check. Clients MAY send it >> or not (which means that implementation is for practical purposes >> optional for them. >>=20 >> Best, >>=20 >> Andrew >> _______________________________________________ >> provreg mailing list >> provreg@ietf.org >> https://www.ietf.org/mailman/listinfo/provreg >=20 >=20 > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg >=20 From ajs@anvilwalrusden.com Thu Jan 5 04:34:02 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B76C21F8757 for ; Thu, 5 Jan 2012 04:34:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.724 X-Spam-Level: X-Spam-Status: No, score=-2.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wvgm4Ps+k1dI for ; Thu, 5 Jan 2012 04:34:02 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id D818621F86FC for ; Thu, 5 Jan 2012 04:34:01 -0800 (PST) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 6901B1ECB420 for ; Thu, 5 Jan 2012 12:34:00 +0000 (UTC) Date: Thu, 5 Jan 2012 07:33:58 -0500 From: Andrew Sullivan To: provreg@ietf.org Message-ID: <20120105123358.GC31931@shinkuro.com> References: <20120105033431.GA33245@crankycanuck.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 12:34:02 -0000 On Wed, Jan 04, 2012 at 10:44:51PM -0500, MICHAEL YOUNG wrote: > Sorry do you mean if you were designing this from scratch this is what you > would do? Or do you mean this is how you read one of the existing > proposals (and by that I mean any of the ones mentioned so far)? I don't think I mean either. I think what I mean is that the draft should include your suggested extension to the check command, and that such extension (like all the rest of them) be mandatory to implement (i.e. just like the other MUSTs in the draft). Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From michael@mwyoung.ca Thu Jan 5 10:51:23 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AAF721F8864 for ; Thu, 5 Jan 2012 10:51:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.751 X-Spam-Level: X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[AWL=0.848, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nILadBpnvxU for ; Thu, 5 Jan 2012 10:51:20 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 03DDA21F87ED for ; Thu, 5 Jan 2012 10:51:18 -0800 (PST) Received: by vbbfo1 with SMTP id fo1so697026vbb.31 for ; Thu, 05 Jan 2012 10:51:18 -0800 (PST) Received: by 10.52.19.206 with SMTP id h14mr1431935vde.131.1325789477627; Thu, 05 Jan 2012 10:51:17 -0800 (PST) Received: from [10.98.71.210] ([207.164.79.82]) by mx.google.com with ESMTPS id d1sm41956783vdj.22.2012.01.05.10.51.15 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Jan 2012 10:51:16 -0800 (PST) References: <20120105033431.GA33245@crankycanuck.ca> <20120105123358.GC31931@shinkuro.com> In-Reply-To: <20120105123358.GC31931@shinkuro.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: <3EA9272F-37AE-4275-B4F3-AD0480E1ED94@mwyoung.ca> X-Mailer: iPhone Mail (9A405) From: Michael Young Date: Thu, 5 Jan 2012 13:51:09 -0500 To: Andrew Sullivan Cc: "provreg@ietf.org" Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 18:51:23 -0000 Thanks Michael Young M:647-289-1220 On 2012-01-05, at 7:33 AM, Andrew Sullivan wrote: > On Wed, Jan 04, 2012 at 10:44:51PM -0500, MICHAEL YOUNG wrote: >> Sorry do you mean if you were designing this from scratch this is what you >> would do? Or do you mean this is how you read one of the existing >> proposals (and by that I mean any of the ones mentioned so far)? > > I don't think I mean either. I think what I mean is that the draft > should include your suggested extension to the check command, and that > such extension (like all the rest of them) be mandatory to implement > (i.e. just like the other MUSTs in the draft). > > Best, > > A > > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg From michael@mwyoung.ca Thu Jan 5 11:00:14 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB2921F8755 for ; Thu, 5 Jan 2012 11:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pu3tevaHclVA for ; Thu, 5 Jan 2012 11:00:13 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6636321F8742 for ; Thu, 5 Jan 2012 11:00:13 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so713463vcb.31 for ; Thu, 05 Jan 2012 11:00:13 -0800 (PST) Received: by 10.220.153.134 with SMTP id k6mr1820816vcw.23.1325790012886; Thu, 05 Jan 2012 11:00:12 -0800 (PST) Received: from [10.98.71.210] ([207.164.79.82]) by mx.google.com with ESMTPS id hk9sm24233633vdb.13.2012.01.05.11.00.11 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Jan 2012 11:00:12 -0800 (PST) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <9F98E660-2796-4A13-ADE9-F1F61D178D71@mwyoung.ca> X-Mailer: iPhone Mail (9A405) From: Michael Young Date: Thu, 5 Jan 2012 14:00:06 -0500 To: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= Cc: "" Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 19:00:14 -0000 Interesting thoughts - I'm really a big fan of avoiding multiple extensions t= hat effectively do the same thing. I think we could benefit by having some m= ore structure around how ICANN works/depends with IETF efforts. Right now it= seems pretty reactive to industry needs versus maybe trying to anticipate n= eeds.=20 Michael Young M:647-289-1220 On 2012-01-05, at 1:49 AM, Patrik F=C3=A4ltstr=C3=B6m wr= ote: > On 5 jan 2012, at 04:44, MICHAEL YOUNG wrote: >=20 >> Sorry do you mean if you were designing this from scratch this is what yo= u >> would do? Or do you mean this is how you read one of the existing >> proposals (and by that I mean any of the ones mentioned so far)? >=20 > If we designed epp from the beginning: >=20 > - We would not have the ability for registries to invent their own extensi= ons without IETF review (i.e. like other protocols) >=20 > - We would have optimized a few of the commands (specifically create) so t= hat it is closer to the business models >=20 > Example of the 2nd are all the registries that require delegation at time o= f registration (something that should be forbidden, but now some registries a= re like that), that required creation of contact objects and host objects be= fore the domain object is created and glued together. If at that point in ti= me the create fails, the creation of the other objects would have automatica= lly been undone. Maybe as a transaction, I do not know. We should have thoug= ht about it harder. >=20 > Patrik >=20 >> Michael >>=20 >>=20 >>=20 >>=20 >> On 12-01-04 10:34 PM, "Andrew Sullivan" wrote: >>=20 >>> On Wed, Jan 04, 2012 at 07:15:49PM -0500, Michael Young wrote: >>>=20 >>>> the use cases. Somewhere in all that I noted you were ok with the >>>> check ext being optional :-) >>>=20 >>> Actually, you misread, then. I think servers (implementing this >>> extension) MUST support the extension to check. Clients MAY send it >>> or not (which means that implementation is for practical purposes >>> optional for them. >>>=20 >>> Best, >>>=20 >>> Andrew >>> _______________________________________________ >>> provreg mailing list >>> provreg@ietf.org >>> https://www.ietf.org/mailman/listinfo/provreg >>=20 >>=20 >> _______________________________________________ >> provreg mailing list >> provreg@ietf.org >> https://www.ietf.org/mailman/listinfo/provreg >>=20 >=20 From ajs@anvilwalrusden.com Thu Jan 5 11:21:20 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1599D21F8886 for ; Thu, 5 Jan 2012 11:21:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6NvzPYoXnDQ for ; Thu, 5 Jan 2012 11:21:19 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 761DE21F8883 for ; Thu, 5 Jan 2012 11:21:19 -0800 (PST) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 5F1B71ECB41C for ; Thu, 5 Jan 2012 19:21:18 +0000 (UTC) Date: Thu, 5 Jan 2012 14:21:16 -0500 From: Andrew Sullivan To: provreg@ietf.org Message-ID: <20120105192116.GC33552@shinkuro.com> References: <9F98E660-2796-4A13-ADE9-F1F61D178D71@mwyoung.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9F98E660-2796-4A13-ADE9-F1F61D178D71@mwyoung.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 19:21:20 -0000 On Thu, Jan 05, 2012 at 02:00:06PM -0500, Michael Young wrote: > Interesting thoughts - I'm really a big fan of avoiding multiple > extensions that effectively do the same thing. I think we could > benefit by having some more structure around how ICANN works/depends > with IETF efforts. Right now it seems pretty reactive to industry > needs versus maybe trying to anticipate needs. ICANN doesn't actually control a very large number of the registries it deals with, as any ccTLD manager will tell you at length if you mistakenly phrase things as though perhaps ICANN has any influence of any sort on them. So it'd probably just cause heartburn to start by thinking about how ICANN is involved. Anyway, it seems to me that the basic problem with EPP extensions is that everyone thinks everyone else's approach is wrong, because most of the approaches are actually designed around an implicit underlying data model. Nobody ever wants to compromise on that, so you either get extensions that are bloated pigs of optional elements, or else you get a lot of extensions. (The preposterous handling of name servers as both references to host objects and as attributes of domain objects in the original EPP documents is an example of this. I understand why it happened, and I have no criticism that the protocol ended up this way; but if one wanted to design a clean data exchange protocol, something this fundamental would not have two completely different ways of handling the same sort of data.) I think the problem is not only the number of extensions. It seems to me that if they were handled in a more co-ordinated way, that would be good; but since they're not likely to be any time soon, then we need to find another way. The other way would be to fix client systems so that pluggable extensions were considerably less clumsy to use. The main reasons I heard people complaining about extensions in the past was because they needed to do significant development every time one was encountered. But in a well-designed system, that shouldn't be true. For a significant extension of additional data elements, one has to do development anyway in order to make the data store correspond to the new data. For an extension that is really just another, not-invented-here way of achieving the same registration goal, a mapping of existing elements ought to be trivial. In the former case, then, some development is necessary anyway, and it's only a poor client design that would make adding the additional extension a big deal. In the latter case, adding another way of expressing the same data should be pretty trivial (although, obviously, an excellent way to introduce pointless bugs). A -- Andrew Sullivan ajs@anvilwalrusden.com From michael@mwyoung.ca Thu Jan 5 14:28:18 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C30BF21F88EC for ; Thu, 5 Jan 2012 14:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.103 X-Spam-Level: X-Spam-Status: No, score=-3.103 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5e-5W9JrSFO for ; Thu, 5 Jan 2012 14:28:18 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id DFDCD21F88E3 for ; Thu, 5 Jan 2012 14:28:17 -0800 (PST) Received: by vbbfo1 with SMTP id fo1so855709vbb.31 for ; Thu, 05 Jan 2012 14:28:17 -0800 (PST) Received: by 10.52.91.7 with SMTP id ca7mr1784568vdb.120.1325802495297; Thu, 05 Jan 2012 14:28:15 -0800 (PST) Received: from DUN20111 (CPEf81edff844ad-CM00080da07047.cpe.net.cable.rogers.com. [99.226.80.88]) by mx.google.com with ESMTPS id v20sm23588243vdu.12.2012.01.05.14.28.13 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Jan 2012 14:28:14 -0800 (PST) From: "Michael Young" To: "'Andrew Sullivan'" , References: <9F98E660-2796-4A13-ADE9-F1F61D178D71@mwyoung.ca> <20120105192116.GC33552@shinkuro.com> In-Reply-To: <20120105192116.GC33552@shinkuro.com> Date: Thu, 5 Jan 2012 17:28:10 -0500 Message-ID: <04cb01cccbf9$4ee111d0$eca33570$@mwyoung.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQC5lWe3JPoyoTRfLlDAJuU099llMQHv900jAV188wYBydNCz5f8CLPQ Content-Language: en-ca Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 22:28:18 -0000 Andrew, 10 years of reading your emails and I am still amazed with how well you write them,..... Your thoughts on ccTLDs are so true in the current state, maybe that balance changes after a couple of new TLDs application rounds, maybe not. ccTLDs have no entity like ICANN to try and enforce some common practises, with good reason, they represent sovereign states so it's appropriate they are independent. However it would be in everyone's interest to reduce work, effort and confusion by forming standards. A strategy of making client implementation easier is a good idea, but it needs to extend to the registrant and storefront as well. For example different terminology in different registries for a data element or modifier/attribute is confusing for a domain user even if we find a way to make epp client implementation cheaper (look at our discussions of language versus script even). I feel like we are just going to have to work through every common extension and its variations in order to consolidate to a single standardized version - no easier shortcuts . That means that each extension we would try and to do this with has to be flexible enough for everyone's use cases. I feel sometimes we get debating uselessly over the validity of a use case when there's an easy option to accommodate multiple use cases. Its really seldom that accommodating one use case means shutting out another one altogether - although it does happen. So then, how do we organize to try and make some progress here? Does everyone think we should try and organize in the first place? -M -----Original Message----- From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On Behalf Of Andrew Sullivan Sent: January-05-12 2:21 PM To: provreg@ietf.org Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt On Thu, Jan 05, 2012 at 02:00:06PM -0500, Michael Young wrote: > Interesting thoughts - I'm really a big fan of avoiding multiple > extensions that effectively do the same thing. I think we could > benefit by having some more structure around how ICANN works/depends > with IETF efforts. Right now it seems pretty reactive to industry > needs versus maybe trying to anticipate needs. ICANN doesn't actually control a very large number of the registries it deals with, as any ccTLD manager will tell you at length if you mistakenly phrase things as though perhaps ICANN has any influence of any sort on them. So it'd probably just cause heartburn to start by thinking about how ICANN is involved. Anyway, it seems to me that the basic problem with EPP extensions is that everyone thinks everyone else's approach is wrong, because most of the approaches are actually designed around an implicit underlying data model. Nobody ever wants to compromise on that, so you either get extensions that are bloated pigs of optional elements, or else you get a lot of extensions. (The preposterous handling of name servers as both references to host objects and as attributes of domain objects in the original EPP documents is an example of this. I understand why it happened, and I have no criticism that the protocol ended up this way; but if one wanted to design a clean data exchange protocol, something this fundamental would not have two completely different ways of handling the same sort of data.) I think the problem is not only the number of extensions. It seems to me that if they were handled in a more co-ordinated way, that would be good; but since they're not likely to be any time soon, then we need to find another way. The other way would be to fix client systems so that pluggable extensions were considerably less clumsy to use. The main reasons I heard people complaining about extensions in the past was because they needed to do significant development every time one was encountered. But in a well-designed system, that shouldn't be true. For a significant extension of additional data elements, one has to do development anyway in order to make the data store correspond to the new data. For an extension that is really just another, not-invented-here way of achieving the same registration goal, a mapping of existing elements ought to be trivial. In the former case, then, some development is necessary anyway, and it's only a poor client design that would make adding the additional extension a big deal. In the latter case, adding another way of expressing the same data should be pretty trivial (although, obviously, an excellent way to introduce pointless bugs). A -- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ provreg mailing list provreg@ietf.org https://www.ietf.org/mailman/listinfo/provreg From patrik@frobbit.se Thu Jan 5 23:21:22 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3296011E80B0 for ; Thu, 5 Jan 2012 23:21:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.308 X-Spam-Level: X-Spam-Status: No, score=-102.308 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZ7eYyKXF4pP for ; Thu, 5 Jan 2012 23:21:21 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 88D7911E80AE for ; Thu, 5 Jan 2012 23:21:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 83D6612B8F900; Fri, 6 Jan 2012 08:21:16 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQs3YzcWgTD3; Fri, 6 Jan 2012 08:21:16 +0100 (CET) Received: from [IPv6:2a02:80:3ffc::14] (unknown [IPv6:2a02:80:3ffc::14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 32A2412B8F8F9; Fri, 6 Jan 2012 08:21:16 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <04cb01cccbf9$4ee111d0$eca33570$@mwyoung.ca> Date: Fri, 6 Jan 2012 08:21:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4C1CAA44-A9C1-4CD1-B7C3-91AD5D64A5DB@frobbit.se> References: <9F98E660-2796-4A13-ADE9-F1F61D178D71@mwyoung.ca> <20120105192116.GC33552@shinkuro.com> <04cb01cccbf9$4ee111d0$eca33570$@mwyoung.ca> To: "Michael Young" X-Mailer: Apple Mail (2.1251.1) Cc: provreg@ietf.org Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 07:21:22 -0000 On 5 jan 2012, at 23:28, Michael Young wrote: > A strategy of making client implementation easier is a good idea, but = it > needs to extend to the registrant and storefront as well. For example > different terminology in different registries for a data element or > modifier/attribute is confusing for a domain user even if we find a = way to > make epp client implementation cheaper (look at our discussions of = language > versus script even). Michael, the "store front" registrars have MUST have the same taxonomy = etc for all TLDs, so there is already a translation/adoption mechanism = in the registrar system. I.e. differences in terminology and data = elements between TLDs is already today not visible to the end users. If registries did harmonize more, it would make registrar work easier. = And more registrars would become customers to more registries. And more = harmonization would also because the translation engines in the = registrars act more similar which implies the users would get more = similar user interface when comparing registrars. Today, having similar user interfaces for for example .EU, .COM, .ORG = and .SE is not easy. The TLDs are so completely different in the epp = implementation that they are...hmm...different. Patrik From ajs@anvilwalrusden.com Fri Jan 6 04:17:47 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F8D21F8929 for ; Fri, 6 Jan 2012 04:17:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TA5isdHxjC2 for ; Fri, 6 Jan 2012 04:17:43 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 5605121F8921 for ; Fri, 6 Jan 2012 04:17:43 -0800 (PST) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 11AD21ECB41C for ; Fri, 6 Jan 2012 12:17:42 +0000 (UTC) Date: Fri, 6 Jan 2012 07:17:40 -0500 From: Andrew Sullivan To: provreg@ietf.org Message-ID: <20120106121739.GJ33552@shinkuro.com> References: <9F98E660-2796-4A13-ADE9-F1F61D178D71@mwyoung.ca> <20120105192116.GC33552@shinkuro.com> <04cb01cccbf9$4ee111d0$eca33570$@mwyoung.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <04cb01cccbf9$4ee111d0$eca33570$@mwyoung.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 12:17:47 -0000 On Thu, Jan 05, 2012 at 05:28:10PM -0500, Michael Young wrote: > are independent. However it would be in everyone's interest to reduce work, > effort and confusion by forming standards. [. . .] > So then, how do we organize to try and make some progress here? Does > everyone think we should try and organize in the first place? This list is already almost as organized as it gets at the IETF, and I'd suggest that much more organization would hinder, rather than help the effort. "More organized" than this at the IETF usually means a working group. I am not at all convinced that the structure of a WG will help, because in many cases a WG would just add overhead. I'm not even sure one could get chartered, because a BoF might not attract enough interest to get the sort of meaningful review that would be required. Moreover, the simple fact is that there are no protocol cops on the Internet. I suppose that ICANN could require (of gTLD registries) some specific RFCs be the mechanism by which this or that feature be offered in EPP. But that doesn't require additional organization within the IETF. It requires greater participation and support on the part of registries and registrars. Registries have had almost 10 years of extensions in which they could have co-ordinated with one another, but they didn't. If they want to start, brilliant; but that requires no more structure than we have now, because ultimately it's just a matter of coming to agreement about how some extension will work. I guess one thing that perhaps could be a good idea is to promote this mailing list to people outside the circle of those who originally participated in or monitored EPP development. I suspect that there are people around ICANN, for instance, who either would have an opinion about EPP extensions or who employ someone wo does, but who don't know about this list and don't follow it. Getting them involved would be a good idea. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From keith@blacknight.com Fri Jan 6 05:35:57 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4774321F8833 for ; Fri, 6 Jan 2012 05:35:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.475 X-Spam-Level: X-Spam-Status: No, score=-3.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLySNumz5vBS for ; Fri, 6 Jan 2012 05:35:56 -0800 (PST) Received: from relay1.blacknight.com (relay1.blacknight.com [78.153.203.204]) by ietfa.amsl.com (Postfix) with ESMTP id 4211221F8825 for ; Fri, 6 Jan 2012 05:35:55 -0800 (PST) Received: from hegemon.blacknight.ie (hegemon.blacknight.ie [81.17.243.239]) by relay1.blacknight.com (Postfix) with ESMTP id 3684535C4E6 for ; Fri, 6 Jan 2012 13:35:53 +0000 (GMT) Message-ID: <4F06F8B8.3000701@blacknight.com> Date: Fri, 06 Jan 2012 13:35:52 +0000 From: Keith Gaughan Organization: Blacknight Internet Solutions User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: provreg@ietf.org References: <20111222002234.8359.14617.idtracker@ietfa.amsl.com> <0CB499D3-A9F7-4D3B-A7BA-6410E306BD25@frobbit.se> <4EF35621.4030306@blacknight.com> <4EF364A4.7040906@blacknight.com> <034c01ccc0e7$c9e35900$5daa0b00$@mwyoung.ca> In-Reply-To: <034c01ccc0e7$c9e35900$5daa0b00$@mwyoung.ca> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [provreg] New Version Notification for draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 13:35:57 -0000 On 22/12/11 20:25, Michael Young wrote: > First of all Janusz, who submitted that Afilias IDN I-D was working for me > at the time, I thought it seemed like a good idea at the time to encourage > standardization. It was, very much so. > We were thinking primarily languages versus scripts due guidance we had from > John Klensin at the time. > >> Though more specifically, the point of even asking for the language in the > first place is to prevent homograph attacks. The use of languages rather > than scripts leads to slightly odd situations where a person wouldn't be > able to register a domain >like .info (a silly example, I know, but > valid), as though there's no language that uses all those characters in > their alphabet, it's in no way a vector for homograph attacks. > So specifically we thought about the above case and decided that a language > was a construct of sorts, usually indicated by a group or community > declaring and codifying its uniqueness. Even that's not entirely correct, as the linguist Max Weinreich wrote about the social plight of Yiddish, "a shprakh iz a dialekt mit an armey un flot". That's why EURid went down the route of specifying codepoint tables for scripts rather than languages: it's *relatively* easy to deliminate scripts and thus avoid homograph attacks within scripts[1] than it is to decide what language ought to be allowed, especially when that means that going the language route can end up inadvertently discriminating against minority languages for no good reason. > We figured any policy in > registration should be made against a language table that was in turn > defined by a recognized language authority. Now "language authority" is a > wide range, but so are the number of defined languages. Not all recognised languages have language academies though, especially minority languages, and in some parts of the world (India, for example), there's a common folk belief that to be a real language without having its own distinct script, even if those languages with the common script are members of totally different language families, like Indo-Aryan and Dravidian. IIRC, the Grantha script was an historical example of this. And then there's the interesting situation in Chinese that bungs 'dialects' as different as Welsh and Greek are from one another under a single banner as 'Chinese'. > We decided against defining the policies (at that time in 2004, I am not > speaking to anyone's current practise/policy) by script because we didnt > see a graceful way to address different spoken languages that shared the > same script. The graceful way to do this is to have multiple tables per script to check labels against. If all the characters in the label are whitelisted in any one of those tables, then it's valid. That solves the homograph problem without discriminating against minority languages (and Europe still has a lot of them), and copes just fine with situations like Serbian, which uses both the Latin and Cyrillic scripts. All that's saved by requiring a language code is CPU cycles. K. [1] Odd cases like s-comma in Romanian versus s-cedilla in Turkish aside, though that's an example of a near-homograph rather than a true homograph. This kind of thing is the best argument for going down the language rather than the script. -- Keith Gaughan, Senior Developer PGP/GPG key ID: 3E896381 Blacknight Internet Solutions Ltd. 12A Barrowside Business Park, Carlow, Ireland Registered in Ireland, Company No.: 370845 From JGould@verisign.com Fri Jan 6 06:24:40 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD7A21F8550 for ; Fri, 6 Jan 2012 06:24:40 -0800 (PST) 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=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqBtbCyLFWeD for ; Fri, 6 Jan 2012 06:24:39 -0800 (PST) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) by ietfa.amsl.com (Postfix) with ESMTP id F0FA921F8507 for ; Fri, 6 Jan 2012 06:24:38 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKTwcEGB6Ds2K06G6iT0F+CnX+XsRU6pmk@postini.com; Fri, 06 Jan 2012 06:24:39 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q06EOL6H010184; Fri, 6 Jan 2012 09:24:24 -0500 Received: from dul1wnexcn04.vcorp.ad.vrsn.com ([10.170.12.139]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Jan 2012 09:24:22 -0500 Received: from BRN1WNEXCAS02.vcorp.ad.vrsn.com ([10.173.152.246]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Jan 2012 09:24:21 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.01.0323.003; Fri, 6 Jan 2012 09:24:21 -0500 From: "Gould, James" To: Andrew Sullivan , "provreg@ietf.org" Thread-Topic: [provreg] Domain check in draft-obispo-epp-idn-00.txt Thread-Index: AQHMyNd/KIWK9LLq7U2BEGcH3XbUMZX85FsAgAAI/ICAABY2gIAABPCAgAAG1wCAAAt8AIAAJa2AgAA3hICAAALjgIAAM6KAgADMFgCAAAXqAIAANDgAgADnwgD//8+PgA== Date: Fri, 6 Jan 2012 14:24:20 +0000 Message-ID: In-Reply-To: <20120106121739.GJ33552@shinkuro.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <59B3F9B97223F14BBC0FC99D56764A37@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 Jan 2012 14:24:21.0667 (UTC) FILETIME=[E2029F30:01CCCC7E] Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 14:24:40 -0000 I see a combination of both the informal interaction of this list as well as formal interaction of a WG. As I stated before, EPP was built for extensibility and extensibility itself is not evil. EPP's extensibility is a feature but best practices should be followed (e.g. make them opt-in extensions) when creating them and it makes sense to move some of the custom extensions up the standards track to create consistency. There is a lot of work involved with going up the standards track for an extension so it really needs to be warranted. I believe with the launch of a large set of new TLD's it makes sense to at a minimum have a BoF to discuss the custom extensions to see if a set of common / standard extensions can be identified. Also with the work being done on the launch phase policies and approaches being worked out at ICANN it makes sense to consider a parallel IETF WG to define the protocols. There is the launchphase extension drafted by Will Tan and Gavin Brown that is a good starting point for interaction between the Domain Registrar and the Domain Registry, but what about the protocol with the Trademark Clearinghouse (TMCH) that can include the provisioning of trademarks (e.g. Trademark Registrar), the query interface and the notification interface between the Domain Registry and the TMCH, and there might be an interface required for the Domain Registrar. I also have the idea of creating a Domain Registry EPP Mapping that at a minimum would include support for an info command and response for providing the features and policies for a TLD or set of TLD's. This would provide information to the Registrars that could help automate and subsequently scale the number of TLD's. --=20 JG James Gould Principal Software Engineer jgould@Verisign.com 703-948-3271 21345 Ridgetop Circle LS2-2-1 Dulles, VA 20166 VerisignInc.com On 1/6/12 7:17 AM, "Andrew Sullivan" wrote: >On Thu, Jan 05, 2012 at 05:28:10PM -0500, Michael Young wrote: > >> are independent. However it would be in everyone's interest to reduce >>work, >> effort and confusion by forming standards. > >[. . .] >=20 >> So then, how do we organize to try and make some progress here? Does >> everyone think we should try and organize in the first place? > >This list is already almost as organized as it gets at the IETF, and >I'd suggest that much more organization would hinder, rather than help >the effort. > >"More organized" than this at the IETF usually means a working group. >I am not at all convinced that the structure of a WG will help, >because in many cases a WG would just add overhead. I'm not even sure >one could get chartered, because a BoF might not attract enough >interest to get the sort of meaningful review that would be required. > >Moreover, the simple fact is that there are no protocol cops on the >Internet. I suppose that ICANN could require (of gTLD registries) >some specific RFCs be the mechanism by which this or that feature be >offered in EPP. But that doesn't require additional organization >within the IETF. It requires greater participation and support on the >part of registries and registrars. Registries have had almost 10 >years of extensions in which they could have co-ordinated with one >another, but they didn't. If they want to start, brilliant; but that >requires no more structure than we have now, because ultimately it's >just a matter of coming to agreement about how some extension will >work. =20 > >I guess one thing that perhaps could be a good idea is to promote this >mailing list to people outside the circle of those who originally >participated in or monitored EPP development. I suspect that there >are people around ICANN, for instance, who either would have an >opinion about EPP extensions or who employ someone wo does, but who >don't know about this list and don't follow it. Getting them involved >would be a good idea. > >Best, > >A > >--=20 >Andrew Sullivan >ajs@anvilwalrusden.com >_______________________________________________ >provreg mailing list >provreg@ietf.org >https://www.ietf.org/mailman/listinfo/provreg From keith@blacknight.com Fri Jan 6 07:29:03 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5176821F87E6 for ; Fri, 6 Jan 2012 07:29:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.493 X-Spam-Level: X-Spam-Status: No, score=-4.493 tagged_above=-999 required=5 tests=[AWL=1.106, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBxYbLecZ7B3 for ; Fri, 6 Jan 2012 07:29:02 -0800 (PST) Received: from relay1.blacknight.com (relay1.blacknight.com [78.153.203.204]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD9421F87D1 for ; Fri, 6 Jan 2012 07:29:01 -0800 (PST) Received: from hegemon.blacknight.ie (hegemon.blacknight.ie [81.17.243.239]) by relay1.blacknight.com (Postfix) with ESMTP id 6FA8D35C419 for ; Fri, 6 Jan 2012 15:28:59 +0000 (GMT) Message-ID: <4F07133B.9050404@blacknight.com> Date: Fri, 06 Jan 2012 15:28:59 +0000 From: Keith Gaughan Organization: Blacknight Internet Solutions User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: provreg@ietf.org References: <20111222002234.8359.14617.idtracker@ietfa.amsl.com> <0CB499D3-A9F7-4D3B-A7BA-6410E306BD25@frobbit.se> <4EF35621.4030306@blacknight.com> <26EFA6A5-66F2-4F5D-8E2E-817D4CAB3EDC@rfc1035.com> <4EF36E9B.5000705@blacknight.com> <20120104202514.GB32606@crankycanuck.ca> In-Reply-To: <20120104202514.GB32606@crankycanuck.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [provreg] language (or script?) tagging in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 15:29:03 -0000 On 04/01/12 20:25, Andrew Sullivan wrote: > On Thu, Dec 22, 2011 at 05:53:31PM +0000, Keith Gaughan wrote: >> Instead, 'writing system'[1] would be better: so long as the writing system >> contains no homographs[2], there's no issue. > > Alas, most alphabetic languages are full of homographs. But I bet > that isn't what you mean, anyway; homograph turns out to have an > established meaning in linguistics, and it isn't "two letters that > look the same". In the ICANN VIP discussions we settled on > "homoglyph" as a possibly useful alternative. Cary Karp has extensive > opinions about this. I prefer 'homoglyph' myself, but nearly every time I've seen mention of the attack, the word 'homograph' rather than 'homoglyph' is used. >> [1] By which I mean, all the languages that use the Latin alphabet could be >> said to share a common script and writing system, which are both the same >> thing. It's not an ideal term, I know. > > Indeed, it's wrong, as a consideration of the fall-back handling of > o-with-diaeresis in Swedish and German illustrates. German considers > ö to be an o with an accent on it. In Swedish, it's a separate > letter. That's why German orthography can fall back to "oe" but > Swedish doesn't. Although an interesting historical note is that Swedish 'ö' started out as 'oe'. >> [3] I can't recall whether Traditional and Simplified Han characters occupy >> different code points in general, or the same ones. > > They're different code points, and different Abstract Characters in > Unicode terms; but there are usually pairs (with some nasty corner > cases) of the same Conceptual Characters in TC and SC. Also, since > they're all part of Unihan, they're all "the same script". Thought that, but couldn't remember. K. -- Keith Gaughan, Senior Developer PGP/GPG key ID: 3E896381 Blacknight Internet Solutions Ltd. 12A Barrowside Business Park, Carlow, Ireland Registered in Ireland, Company No.: 370845 From ajs@anvilwalrusden.com Fri Jan 6 07:41:31 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F9721F87B5 for ; Fri, 6 Jan 2012 07:41:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.69 X-Spam-Level: X-Spam-Status: No, score=-3.69 tagged_above=-999 required=5 tests=[AWL=0.909, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwCQaTvOpiPb for ; Fri, 6 Jan 2012 07:41:30 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id BA43921F87A4 for ; Fri, 6 Jan 2012 07:41:30 -0800 (PST) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 42F051ECB41C for ; Fri, 6 Jan 2012 15:41:29 +0000 (UTC) Date: Fri, 6 Jan 2012 10:41:27 -0500 From: Andrew Sullivan To: provreg@ietf.org Message-ID: <20120106154126.GL33552@shinkuro.com> References: <20111222002234.8359.14617.idtracker@ietfa.amsl.com> <0CB499D3-A9F7-4D3B-A7BA-6410E306BD25@frobbit.se> <4EF35621.4030306@blacknight.com> <4EF364A4.7040906@blacknight.com> <034c01ccc0e7$c9e35900$5daa0b00$@mwyoung.ca> <4F06F8B8.3000701@blacknight.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F06F8B8.3000701@blacknight.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [provreg] New Version Notification for draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 15:41:32 -0000 This email is a little long. I'm not picking on Keith Gaughan; his email was just a convenient hook for this. If you don't want to read all this, skip to the [Conclusion] at the end. On Fri, Jan 06, 2012 at 01:35:52PM +0000, Keith Gaughan wrote: > The graceful way to do this is to have multiple tables per script to check > labels against. If all the characters in the label are whitelisted in any > one of those tables, then it's valid. That solves the homograph problem > without discriminating against minority languages (and Europe still has a lot > of them), and copes just fine with situations like Serbian, which uses both > the Latin and Cyrillic scripts. All that's saved by requiring a language code > is CPU cycles. I already asked this once, but I do so again: there's considerable discussion of what's called "label generation rules" and "zone repertoires" in the recent ICANN VIP draft report. The report is open for public comment right now: http://www.icann.org/en/announcements/announcement-2-23dec11-en.htm. I'd really like some additional eyes on those sections: I wrote a substantial amount of that text, and I'm not completely sure it's all right. But I think it's a possibly-useful direction. The section that discusses this at length is section 4, starting on page 39. In any case, I think the script/language distinction is invidious for our purposes: both are important considerations. So I want to expand a little on what's in the VIP draft and try to explain in more detail the sort of approach I think will work in the long term. There are, in addition, several problems with this discussion of "tables", the most obvious of which is that we don't have a standard for such tables that actually works for everyone. What that really means is that, for zones that span widely divergent languages and writing systems, we are already in trouble. RFC 3743 was an extremely important and clever answer to the peculiar problems of one sort of writing system. It was also seminal, however, and that's a little unfortunate because the CJK systems are extremely bad analogies for everything else. (Indeed, Korean is almost unique in the history of human writing, and Chinese is completely unusual in the world today.) One issue with RFC 3743 and all of the work that has followed from it (including RFC4290) is that the basic "table" idea conflates a number of functions that just happen to be aligned in the cases for which the JET guidelines were designed. One of these is to specify the code points the registry (i.e. zone operator -- remember that a registry isn't necessarily an operator of TLDs, but just a repository of information for some administrative area, in this case DNS zones) will accept in U-labels for the zone. Another is to associate an identifier with the subset of code points constrained by some rules. Another is to specify alternative labels that may or must be delegated along with some "fundamental" label (e.g. the one that was submitted to the registry). Another is to specify alternative labels that may not be registered in the presence of that fundamental label. And another is to specify alternative labels that must not be active in the zone when that fundamental label is in the zone. (All these "alternative label" bits are one of the kinds of things people call "variants", and what RFC 3743 meant by "variant".) Not all of these purposes are actually achieved in any of the table formats registered with IANA (there is more than one format, alas). For instance, the specification of the first purpose (what code points are permitted, which we can call the "zone repertoire") is actually derivable only from the union of all the tables a registry uses. Similarly, it works out, the alternatives and their associated permissions with respect to activation also need to be derived using all the defined tables. Some table formats can't distinguish between "normally activated" and "must be activated", nor between "not normally activated but may be at applicant's choice" and "must not be activated". None to my knowledge can distinguish between "must be delegated if activated" and "must be aliased if activated". People are actually using the tables for different purposes. Verisign, for instance, has recently submitted a very large number of tables to IANA that effectively permits every Unicode code point that works for IDNA (and I haven't even validated the second part of this), but specifies no alternative forms at all; their submissions include one for the Arabic script. SaudiNIC, on the other hand, registered a table for Arabic language (not script) that includes complicated rules for alternative handling according to the position of a code point in a candidate label; the "table" also has a number of rules written into it. Even if we were to recognise implicitly the different roles outlined above, while maintaining the somewhat-underdefined notion of a "table", I think there are certain basic truths about the functioning of IDN labels at or near the top levels that we're going to need to keep in mind. The first is that, with an extremely large well of potential code points, the DNS registration community is going to have to converge on conventions for most of these code points relatively quickly. If a code point has vastly different behaviour in different zones, either that code points just won't get used at all, or else the code point will come to be a source of a lot of confusion, phishing opportunities, and frustration. (Or else the outlier behaviours will get lost, but that's just a variation of "not used".) The second is that we are never going to be able to cram every user expectation about a given code point's behaviour into the global DNS: there are too many funny ways an identifier system like the DNS can trip people up. Paradoxically, the third is that people will use DNS names based on their preconceptions of how their letters work, and we had better be prepared for those expectations or we will subject people to very nasty surprises. An effect of points (2) and (3) above is that we actually ought to be reluctant, rather than eager, to add additional code points whenever they are not absolutely required. For instance, there are a lot of optional marks in Arabic; I think nobody should ever permit them in high-level zones, because they're just going to cause confusion. There are words in some languages (Farsi and Nepali both come to mind) that can't be written without the ZWNJ; but I think nobody should permit labels of such kinds in multi-language high-level zones _even though it would be useful_, because the danger of interaction with other linguistic rules is just too great. Apostropoids like U+02BC are more or less impossible to get along without in some languages (Ukranian comes to mind), but I think adding such a code point to a high-level multi-language zone is asking for serious trouble (particularly in the case of Ukranian, where most standard keyboards don't even have a keycode that usually generates that code point). Moreover, the way that the zone repertoire gets established is politically fraught. Some cases are simple, even for languages without an academy to establish their rules (English is an excellent example here). But one should consider very carefully the political situation in parts of Eastern Europe and Western Asia before being glib about the problems of who gets to decide whether a language is written in Latin, Cyrillic, or Arabic scripts (and, after that, which subset of each). This is why I like an approach something like the sample "approach 3" from section 4.2 of the VIP report: it doesn't leave us stuck with the Unicode script properties, it doesn't require us to come up with rules for all the code points we don't understand, and it still encourages widespread engagement with relevant language and script users. [Conclusion] Because of all of the above, I'd like to step back a bit from the language-vs-script and table-based way of framing this discussion and focus more on how one selects which set of code points one wants to use and, if there are rules governing the behaviour of those code points, how one expresses one's options under those rules. This will make for a more complicated EPP extension, but it will also make for one that actually matches the different registry policies already in place today. By creating an extension that can accommodate the many different policies in place, we might be able to reduce the number of extensions that actually get deployed. Best, Andrew -- Andrew Sullivan ajs@anvilwalrusden.com From brunner@nic-naa.net Fri Jan 6 08:36:35 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B0D21F8672 for ; Fri, 6 Jan 2012 08:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+GQLuooPCzO for ; Fri, 6 Jan 2012 08:36:35 -0800 (PST) Received: from nic-naa.net (nic-naa.net [65.99.1.132]) by ietfa.amsl.com (Postfix) with ESMTP id D89DF21F8670 for ; Fri, 6 Jan 2012 08:36:34 -0800 (PST) Received: from limpet.local (cpe-67-255-2-48.twcny.res.rr.com [67.255.2.48]) by nic-naa.net (8.14.4/8.14.4) with ESMTP id q06E0xaV001338 for ; Fri, 6 Jan 2012 09:01:00 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-ID: <4F07230B.9030800@nic-naa.net> Date: Fri, 06 Jan 2012 11:36:27 -0500 From: Eric Brunner-Williams Organization: wampumpeag User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: provreg@ietf.org References: <20111222002234.8359.14617.idtracker@ietfa.amsl.com> <0CB499D3-A9F7-4D3B-A7BA-6410E306BD25@frobbit.se> <4EF35621.4030306@blacknight.com> <4EF364A4.7040906@blacknight.com> <034c01ccc0e7$c9e35900$5daa0b00$@mwyoung.ca> <4F06F8B8.3000701@blacknight.com> <20120106154126.GL33552@shinkuro.com> In-Reply-To: <20120106154126.GL33552@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] New Version Notification for draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ebw@abenaki.wabanaki.net List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 16:36:36 -0000 > Because of all of the above, I'd like to step back a bit from the > language-vs-script and table-based way of framing this discussion and > focus more on how one selects which set of code points one wants to > use and, if there are rules governing the behaviour of those code > points, how one expresses one's options under those rules. This will > make for a more complicated EPP extension, but it will also make for > one that actually matches the different registry policies already in > place today. By creating an extension that can accommodate the many > different policies in place, we might be able to reduce the number of > extensions that actually get deployed. Concur. An ASCII (hex) code point repertoire of {(41,61), (45,65), (49,69), (4f,6f), (55,75), (59,79)} (English vowels) is just as reasonable a repertoire {30 ... 39} (digits) and just as reasonable a repertoire as {30, 32, ... (5a,7a)} (even valued points within LDH) as the ASCII LDH set of code points. None are sufficiently characterized as "language" or "script", but are sufficiently characterized as enumerations or rules for the construction of repertoires of code points. For a less mathematician-centric or bottom-half-of-the-tty-driver-centric example, consider the "proper word" requirement of the circa-2006 Arabic Script group. A "is in a dictionary and is not on a reserved list" rule is neither "Arabic" (the language") nor "Arabic Script" (the Unicadette created thingie an earlier instance of the IDN WG, steered by non-contributors, elected to commit _some_ DNS text resource records to). The dictionaries of two "Arabic Language" supporting and "Arabic Script" using registries may differ, as may their reserved lists. Verisign's take on Arabic makes me grin. I hope they'll be just as creative when it comes to Chinese. My two beads worth, Eric From michael@mwyoung.ca Fri Jan 6 08:52:10 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F6721F8982 for ; Fri, 6 Jan 2012 08:52:10 -0800 (PST) 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=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfwgFKN6bm2Y for ; Fri, 6 Jan 2012 08:52:09 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 829AF21F8981 for ; Fri, 6 Jan 2012 08:52:09 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so1473304vcb.31 for ; Fri, 06 Jan 2012 08:52:09 -0800 (PST) Received: by 10.220.227.66 with SMTP id iz2mr4088940vcb.16.1325868728819; Fri, 06 Jan 2012 08:52:08 -0800 (PST) Received: from [10.0.0.103] ([184.175.22.34]) by mx.google.com with ESMTPS id ir2sm44410174vdb.9.2012.01.06.08.52.03 (version=SSLv3 cipher=OTHER); Fri, 06 Jan 2012 08:52:07 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Fri, 06 Jan 2012 11:52:07 -0500 From: MICHAEL YOUNG To: Patrik =?ISO-8859-1?B?RuRsdHN0cvZt?= Message-ID: Thread-Topic: [provreg] Domain check in draft-obispo-epp-idn-00.txt In-Reply-To: <4C1CAA44-A9C1-4CD1-B7C3-91AD5D64A5DB@frobbit.se> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: provreg@ietf.org Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 16:52:10 -0000 :-)=20 -M On 12-01-06 2:21 AM, "Patrik F=E4ltstr=F6m" wrote: > >On 5 jan 2012, at 23:28, Michael Young wrote: > >> A strategy of making client implementation easier is a good idea, but >>it >> needs to extend to the registrant and storefront as well. For example >> different terminology in different registries for a data element or >> modifier/attribute is confusing for a domain user even if we find a way >>to >> make epp client implementation cheaper (look at our discussions of >>language >> versus script even). > >Michael, the "store front" registrars have MUST have the same taxonomy >etc for all TLDs, so there is already a translation/adoption mechanism in >the registrar system. I.e. differences in terminology and data elements >between TLDs is already today not visible to the end users. > >If registries did harmonize more, it would make registrar work easier. >And more registrars would become customers to more registries. And more >harmonization would also because the translation engines in the >registrars act more similar which implies the users would get more >similar user interface when comparing registrars. > >Today, having similar user interfaces for for example .EU, .COM, .ORG and >.SE is not easy. The TLDs are so completely different in the epp >implementation that they are...hmm...different. > > Patrik > From keith@blacknight.com Fri Jan 6 09:03:03 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36BA621F87B9 for ; Fri, 6 Jan 2012 09:03:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.631 X-Spam-Level: X-Spam-Status: No, score=-3.631 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnYtb6TBGnSb for ; Fri, 6 Jan 2012 09:03:02 -0800 (PST) Received: from relay1.blacknight.com (relay1.blacknight.com [78.153.203.204]) by ietfa.amsl.com (Postfix) with ESMTP id 491A321F8981 for ; Fri, 6 Jan 2012 09:03:00 -0800 (PST) Received: from hegemon.blacknight.ie (hegemon.blacknight.ie [81.17.243.239]) by relay1.blacknight.com (Postfix) with ESMTP id 4405335C5D6 for ; Fri, 6 Jan 2012 17:02:58 +0000 (GMT) Message-ID: <4F072941.5050804@blacknight.com> Date: Fri, 06 Jan 2012 17:02:57 +0000 From: Keith Gaughan Organization: Blacknight Internet Solutions User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: "provreg@ietf.org" References: <4F049E6C.7060100@blacknight.com> <4E713373-4FFE-43E7-8625-F81AC86CF1E9@mwyoung.ca> In-Reply-To: <4E713373-4FFE-43E7-8625-F81AC86CF1E9@mwyoung.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 17:03:03 -0000 On 04/01/12 20:37, Michael Young wrote: > What can I say, it would be great if the registrar put that kind of intelligence in their storefront and didn't send domain creates that violate a given language table. I agree completely! > Most registrars aren't making that extensive of an effort. Why? I think I can shed some light on that, and there are a number of ways that registries can help registrars with this. I spent a good amount of time hacking together a set of libraries and tools to help deal with it on our end. The key was to find a way of representing the whitelists that (a) wouldn't consume a tonne of memory, (b) would be quick to unmarshall from disc, (c) would work effectively with both alphabetic scripts and non-alphabetic scripts, and (d) would have minimal CPU overhead. After a number of experiments I hit upon compiling the codepoint whitelist into the following format[1]: First, I imagined each Unicode plane as divided up into 256 slices. This was a useful as it corresponds pretty closely with how codepoints were allocated in the first plane at least, so each slice is typically going to either empty or fairly densely packed with whitelisted codepoints. I used 256b bitvectors to represent non-empty slices, along with a single bitvector with all the bits off for slices with no whitelisted characters. Next, for each slice in a plane, I stored the index of a bitvector that corresponds to the whitelisted codepoints within that slice. In addition, it maintains a bitfield of the planes represented within the table. This allowed for a compact representation of the whitelisted CJK codepoints in the higher planes (especially for Chinese) while having only a minor impact on the size of tables for languages represented BMP and SMP. It also kept the speed of unmarshalling low. Finally, there's an optimisation stop to remove any duplicate non-empty slices. This was particularly useful for Korean. Each table is tagged with a language code and compiled into a set of files, one for each registry. Now, I chose this way of doing things as I needed to be able to load those tables repeatedly into memory from disc from various languages, including C, Python and PHP. If our systems were purely written in C and Python, I'd have just loaded textual representations of the whitelists into memory, but with PHP, compiling the tables into form that can be quickly unmarshalled was a huge win. Getting this right took a lot of thought, however, and the registrar business is very low margin, so the kind of near obsessive attention to detail that I showed with this isn't going to be common amongst registrar because acting fast and loose is more cost-effective. If you want registrars to behave like you'd prefer (which is the way they ought to be acting anyway), you have to make it cost them: a demerit system would help. If a registrar repeatedly sends IDNs to either the or commands that don't match any of the registry's whitelists, that registrar ought to be penalised. As a carrot, registries have to make it easy for registrar to build and maintain whitelists. IANA's Repository of IDN Practices solves half the problem here, but it's still deficient. The tables provided typically aren't trivially parseable. Some, such as Telnic's, are fine, but some of the HTML codepoint table representations seem as if they were designed to frustrate ease of parsing. And don't get me started on the tables submitted as PDFs! It'd also help if IANA provided an Atom feed listing additions and revisions to the repository so that registrars could automatically parse and download. More registry operators should publish their whitelists in IANA's practices repository, and Afilias for one have yet to register anything other than their German whitelist with IANA, even after over five years of supporting seven other languages besides German. These things are hardly business secrets, after all, so I can't see why nobody's got around to emailing the things into IANA yet, nor can I understand why anybody should have to log into the registrar relations area to get their hands on them. > Adjust the domain check ext so the language tag element is optional. No > language tag and it assumes a straight ASCII registration. > Then those registrars that want to validate their own work can and > registrars that aren't sure can test a punycode string against the extended > domain check. This seems like a compromise that works, thoughts? That's not really a compromise: that's the status quo of requiring a language code when checking availability. Here's a compromise that works for me: registrars should be allowed to submit straight ASCII domains and IDN domains to both the and commands, but registries should ensure that the domain is valid against their codepoint whitelists. If a registrar submits domains to either command that don't match at least one whitelist, they should be marked with a demerit and the request rejected. Once a registrar reaches a certain threshold, the registry should notify the offending registrar that they risk sanction for submitting bad IDNs. Once they hit a higher threshold, they should should be notified that they have been penalised for their behaviour. The form of penalisation should be at the registries discretion, and might take the form of a higher cost per transaction, or some other form. That leaves registrars with a choice: either implement IDN support properly in their domain management system and stores or don't offer IDNs. K. [1] I've yet to deal with the issue of variants all that well. That's something currently exercising my mind because until I come up with a solution, our support for CJK IDNs is less than ideal. -- Keith Gaughan, Senior Developer PGP/GPG key ID: 3E896381 Blacknight Internet Solutions Ltd. 12A Barrowside Business Park, Carlow, Ireland Registered in Ireland, Company No.: 370845 From michele@blacknight.ie Fri Jan 6 09:04:09 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE42121F8999 for ; Fri, 6 Jan 2012 09:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fs-rxUnFVWwW for ; Fri, 6 Jan 2012 09:04:08 -0800 (PST) Received: from exchange.blacknight.ie (exchange.blacknight.ie [81.17.243.252]) by ietfa.amsl.com (Postfix) with ESMTP id B2BF021F8994 for ; Fri, 6 Jan 2012 09:04:05 -0800 (PST) Received: from BKEXCHMBX01.blacknight.local ([fe80::76:af74:8c72:96ac]) by bkexchhubcas01.blacknight.local ([fe80::3ca9:6bf1:bd5d:24b%15]) with mapi id 14.02.0247.003; Fri, 6 Jan 2012 17:04:04 +0000 From: "Michele Neylon :: Blacknight" To: MICHAEL YOUNG Thread-Topic: [provreg] Domain check in draft-obispo-epp-idn-00.txt Thread-Index: AQHMyNeMgK43OEXRaUi75C4m8mrDaJX8kIkAgAAI/ICAABY2gIAABPCAgAAG1wCAAAt8AIAAJa2AgAA3hICAAALjgIAAM6KAgADMFgCAAAXqAIAANDgAgACU8YCAAJ+AgIAAA1IA Date: Fri, 6 Jan 2012 17:04:04 +0000 Message-ID: <423A07CB-2414-441A-9F6E-16FC15D0466F@blacknight.ie> References: In-Reply-To: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2a01:a8:ff01:0:cabc:c8ff:fea6:ee0b] Content-Type: text/plain; charset="utf-8" Content-ID: <8FACD7433C7B294ABD514F72D60A55CC@blacknight.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "" Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 17:04:09 -0000 KzEwMDAwIFBhdHJpaw0KDQpSZWdpc3RyeSBvcGVyYXRvcnMgYXJlIHRoZWlyIG93biB3b3JzdCBl bmVtaWVzIQ0KDQpPbiA2IEphbiAyMDEyLCBhdCAxNjo1MiwgTUlDSEFFTCBZT1VORyB3cm90ZToN Cg0KPiA6LSkgDQo+IA0KPiAtTQ0KPiANCj4gDQo+IA0KPiANCj4gT24gMTItMDEtMDYgMjoyMSBB TSwgIlBhdHJpayBGw6RsdHN0csO2bSIgPHBhdHJpa0Bmcm9iYml0LnNlPiB3cm90ZToNCj4gDQo+ PiANCj4+IE9uIDUgamFuIDIwMTIsIGF0IDIzOjI4LCBNaWNoYWVsIFlvdW5nIHdyb3RlOg0KPj4g DQo+Pj4gQSBzdHJhdGVneSBvZiBtYWtpbmcgY2xpZW50IGltcGxlbWVudGF0aW9uIGVhc2llciBp cyBhICBnb29kIGlkZWEsIGJ1dA0KPj4+IGl0DQo+Pj4gbmVlZHMgdG8gZXh0ZW5kIHRvIHRoZSBy ZWdpc3RyYW50IGFuZCBzdG9yZWZyb250IGFzIHdlbGwuIEZvciBleGFtcGxlDQo+Pj4gZGlmZmVy ZW50IHRlcm1pbm9sb2d5IGluIGRpZmZlcmVudCByZWdpc3RyaWVzIGZvciBhIGRhdGEgZWxlbWVu dCBvcg0KPj4+IG1vZGlmaWVyL2F0dHJpYnV0ZSBpcyBjb25mdXNpbmcgZm9yIGEgZG9tYWluIHVz ZXIgZXZlbiBpZiB3ZSBmaW5kIGEgd2F5DQo+Pj4gdG8NCj4+PiBtYWtlIGVwcCBjbGllbnQgaW1w bGVtZW50YXRpb24gY2hlYXBlciAobG9vayBhdCBvdXIgZGlzY3Vzc2lvbnMgb2YNCj4+PiBsYW5n dWFnZQ0KPj4+IHZlcnN1cyBzY3JpcHQgZXZlbikuDQo+PiANCj4+IE1pY2hhZWwsIHRoZSAic3Rv cmUgZnJvbnQiIHJlZ2lzdHJhcnMgaGF2ZSBNVVNUIGhhdmUgdGhlIHNhbWUgdGF4b25vbXkNCj4+ IGV0YyBmb3IgYWxsIFRMRHMsIHNvIHRoZXJlIGlzIGFscmVhZHkgYSB0cmFuc2xhdGlvbi9hZG9w dGlvbiBtZWNoYW5pc20gaW4NCj4+IHRoZSByZWdpc3RyYXIgc3lzdGVtLiBJLmUuIGRpZmZlcmVu Y2VzIGluIHRlcm1pbm9sb2d5IGFuZCBkYXRhIGVsZW1lbnRzDQo+PiBiZXR3ZWVuIFRMRHMgaXMg YWxyZWFkeSB0b2RheSBub3QgdmlzaWJsZSB0byB0aGUgZW5kIHVzZXJzLg0KPj4gDQo+PiBJZiBy ZWdpc3RyaWVzIGRpZCBoYXJtb25pemUgbW9yZSwgaXQgd291bGQgbWFrZSByZWdpc3RyYXIgd29y ayBlYXNpZXIuDQo+PiBBbmQgbW9yZSByZWdpc3RyYXJzIHdvdWxkIGJlY29tZSBjdXN0b21lcnMg dG8gbW9yZSByZWdpc3RyaWVzLiBBbmQgbW9yZQ0KPj4gaGFybW9uaXphdGlvbiB3b3VsZCBhbHNv IGJlY2F1c2UgdGhlIHRyYW5zbGF0aW9uIGVuZ2luZXMgaW4gdGhlDQo+PiByZWdpc3RyYXJzIGFj dCBtb3JlIHNpbWlsYXIgd2hpY2ggaW1wbGllcyB0aGUgdXNlcnMgd291bGQgZ2V0IG1vcmUNCj4+ IHNpbWlsYXIgdXNlciBpbnRlcmZhY2Ugd2hlbiBjb21wYXJpbmcgcmVnaXN0cmFycy4NCj4+IA0K Pj4gVG9kYXksIGhhdmluZyBzaW1pbGFyIHVzZXIgaW50ZXJmYWNlcyBmb3IgZm9yIGV4YW1wbGUg LkVVLCAuQ09NLCAuT1JHIGFuZA0KPj4gLlNFIGlzIG5vdCBlYXN5LiBUaGUgVExEcyBhcmUgc28g Y29tcGxldGVseSBkaWZmZXJlbnQgaW4gdGhlIGVwcA0KPj4gaW1wbGVtZW50YXRpb24gdGhhdCB0 aGV5IGFyZS4uLmhtbS4uLmRpZmZlcmVudC4NCj4+IA0KPj4gIFBhdHJpaw0KPj4gDQo+IA0KPiAN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gcHJv dnJlZyBtYWlsaW5nIGxpc3QNCj4gcHJvdnJlZ0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Byb3ZyZWcNCg0KTXIgTWljaGVsZSBOZXlsb24NCkJsYWNr bmlnaHQgU29sdXRpb25zIOKZng0KSG9zdGluZyAmIENvbG9jYXRpb24sIEJyYW5kIFByb3RlY3Rp b24NCklDQU5OIEFjY3JlZGl0ZWQgUmVnaXN0cmFyDQpodHRwOi8vd3d3LmJsYWNrbmlnaHQuY29t Lw0KaHR0cDovL2Jsb2cuYmxhY2tuaWdodC5jb20vDQpodHRwOi8vYmxhY2tuaWdodC5iaXoNCmh0 dHA6Ly9tbmV5bG9uLnRlbA0KSW50bC4gKzM1MyAoMCkgNTkgIDkxODMwNzINClVTOiAyMTMtMjMz LTE2MTIgDQpVSzogMDg0NCA0ODQgOTM2MQ0KTG9jYWxsOiAxODUwIDkyOSA5MjkNCkRpcmVjdCBE aWFsOiArMzUzICgwKTU5IDkxODMwOTANCkZhY2Vib29rOiBodHRwOi8vZmIubWUvYmxhY2tuaWdo dA0KVHdpdHRlcjogaHR0cDovL3R3aXR0ZXIuY29tL21uZXlsb24NCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCkJsYWNrbmlnaHQgSW50ZXJuZXQgU29sdXRpb25zIEx0ZCwgVW5pdCAx MkEsQmFycm93c2lkZSBCdXNpbmVzcyBQYXJrLFNsZWF0eQ0KUm9hZCxHcmFpZ3VlY3VsbGVuLENh cmxvdyxJcmVsYW5kICBDb21wYW55IE5vLjogMzcwODQ1DQoNCg== From keith@blacknight.com Fri Jan 6 09:09:56 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F4121F862A for ; Fri, 6 Jan 2012 09:09:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.627 X-Spam-Level: X-Spam-Status: No, score=-3.627 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVzc728g8RsA for ; Fri, 6 Jan 2012 09:09:54 -0800 (PST) Received: from relay1.blacknight.com (relay1.blacknight.com [78.153.203.204]) by ietfa.amsl.com (Postfix) with ESMTP id 001CA21F8540 for ; Fri, 6 Jan 2012 09:09:50 -0800 (PST) Received: from hegemon.blacknight.ie (hegemon.blacknight.ie [81.17.243.239]) by relay1.blacknight.com (Postfix) with ESMTP id 3BD9F35C4FE for ; Fri, 6 Jan 2012 17:09:50 +0000 (GMT) Message-ID: <4F072ADD.8050300@blacknight.com> Date: Fri, 06 Jan 2012 17:09:49 +0000 From: Keith Gaughan Organization: Blacknight Internet Solutions User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: provreg@ietf.org References: <4F049E6C.7060100@blacknight.com> <4E713373-4FFE-43E7-8625-F81AC86CF1E9@mwyoung.ca> <29AD57F4-D97A-46A7-BDCA-6DABFCE022AB@isc.org> In-Reply-To: <29AD57F4-D97A-46A7-BDCA-6DABFCE022AB@isc.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 17:09:56 -0000 On 04/01/12 20:44, Francisco Obispo wrote: > I agree that registrars should be performing those tests/validations ahead > of time and shouldn't rely exclusively on the registry for those types of > validation, because that would increase registry load significantly. I very much doubt that it would increase registry load significantly, and I know because I've implemented code to do exactly that kind of validation, and the additional extra load was negligible in terms of overall request processing time. It wasn't even a blip compared to even the overhead of marshalling and unmarshalling EPP stanzas. Both registrars and registries should be checking IDNs against codepoint whitelists. -- Keith Gaughan, Senior Developer PGP/GPG key ID: 3E896381 Blacknight Internet Solutions Ltd. 12A Barrowside Business Park, Carlow, Ireland Registered in Ireland, Company No.: 370845 From fobispo@isc.org Fri Jan 6 09:13:20 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADE3221F863B for ; Fri, 6 Jan 2012 09:13:20 -0800 (PST) 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=[AWL=-0.000, BAYES_00=-2.599, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pFd7nf5UA5K for ; Fri, 6 Jan 2012 09:13:19 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id DC8E121F8778 for ; Fri, 6 Jan 2012 09:12:58 -0800 (PST) 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.pao1.isc.org (Postfix) with ESMTPS id D58FCC941E; Fri, 6 Jan 2012 17:12:44 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [192.168.1.102] (unknown [190.202.176.226]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 3BAC0216C6A; Fri, 6 Jan 2012 17:12:44 +0000 (UTC) (envelope-from fobispo@isc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Francisco Obispo In-Reply-To: <20120104201038.GA32606@crankycanuck.ca> Date: Fri, 6 Jan 2012 09:12:56 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4D64ACFF-A2AC-4C68-9346-97C118750C08@isc.org> References: <20111222002234.8359.14617.idtracker@ietfa.amsl.com> <0CB499D3-A9F7-4D3B-A7BA-6410E306BD25@frobbit.se> <20120104201038.GA32606@crankycanuck.ca> To: Andrew Sullivan X-Mailer: Apple Mail (2.1251.1) Cc: provreg@ietf.org Subject: Re: [provreg] New Version Notification for draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 17:13:20 -0000 Andrew, How about if we change the tag for and its = value will be the "name" of the IDN table as published/offered by the = registry? That way we can remove the discussion of language vs. script from the = extension itself, and it would be broad enough to let each registry = define their own set. Francisco On Jan 4, 2012, at 12:10 PM, Andrew Sullivan wrote: > Hi all, >=20 > Doing some catch-up. Sorry for coming in late. >=20 > On Wed, Dec 21, 2011 at 10:10:52PM -0800, Francisco Obispo wrote: >=20 >> Looking at the IDN implementation guidelines, item #5 states: >>=20 >> 5.All code points in a single label will be taken from the same >> script as determined by the Unicode Standard Annex #24: Script >> Names . Exceptions to this >> guideline are permissible for languages with established=20 >> orthographies and conventions that require the commingled use of >> multiple scripts. >=20 > i.e. "every language in the world". It turns out that there is a > major problem with this guideline in general use, even if it turns out > to work for some languages for TLDs: most languages need some things > from Common or Inherited. That is true even of LDH labels.=20 >=20 > You might get around this by hand-waving Common and Inherited, but > then you have a different problem. For instance, suppose you wanted > to permit the traditional digits 0-9; they're Common. But if you said > that Latin implicitly included everything in Common, you'd implicitly > include 0660..0669, which are ARABIC-INDIC DIGIT ZERO..ARABIC-INDIC > DIGIT NINE. Which is presumably not what you wanted. >=20 > Worse, >=20 >> So it would not be possible to have multiple languages associated to = a label. >=20 > you're conflating "language" and "script" here, since the restriction > above is about scripts and not languages. =20 >=20 >> XML Schema "language" type[1]: >>=20 >> [Definition:] language represents natural language identifiers as = defined by by [RFC 3066][2] . The =B7value space=B7 of language is the = set of all strings that >=20 > I guess this reference ought to be changed to 4646? >=20 > Anyway, that doesn't wholly help you, becuase just because you have an > identifier doesn't mean you have a reasonable repertoire of > characters. >=20 > More broadly, I'd like it a lot if people went and looked at the > discussion of zone repertoires and the label generation rules in the > recent ICANN Variant Issues Project (announcement here: > http://www.icann.org/en/announcements/announcement-2-23dec11-en.htm). > I came to believe over the last six or so months that neither > "language" nor "script" is what we want here, and I think it would be > extremely helpful to have some other eyes on the discussion of this > issue in that report. While the report is actually aimed only at the > top level, I think this part of the report is broadly applicable to > any zone that has to serve a linguistically diverse population > (i.e. pretty much every gTLD and some ccTLDs too). >=20 > Best regards, >=20 > A >=20 > --=20 > Andrew Sullivan > > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg Francisco Obispo=20 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 keith@blacknight.com Fri Jan 6 09:18:15 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC8621F8683 for ; Fri, 6 Jan 2012 09:18:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.625 X-Spam-Level: X-Spam-Status: No, score=-3.625 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAM1Xe0HUhCO for ; Fri, 6 Jan 2012 09:18:14 -0800 (PST) Received: from relay1.blacknight.com (relay1.blacknight.com [78.153.203.204]) by ietfa.amsl.com (Postfix) with ESMTP id C527621F8681 for ; Fri, 6 Jan 2012 09:18:14 -0800 (PST) Received: from hegemon.blacknight.ie (hegemon.blacknight.ie [81.17.243.239]) by relay1.blacknight.com (Postfix) with ESMTP id E322B35C541 for ; Fri, 6 Jan 2012 17:18:13 +0000 (GMT) Message-ID: <4F072CD5.9040202@blacknight.com> Date: Fri, 06 Jan 2012 17:18:13 +0000 From: Keith Gaughan Organization: Blacknight Internet Solutions User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: provreg@ietf.org References: <4F049E6C.7060100@blacknight.com> <4E713373-4FFE-43E7-8625-F81AC86CF1E9@mwyoung.ca> <55C30604-0432-48E1-885E-C691448B08A9@frobbit.se> <03AFAC20-A409-42BA-92CD-48BCBC9C521D@mwyoung.ca> <48C133A6-DF30-4F01-8229-1BEB7BB0FBD8@blacknight.ie> In-Reply-To: <48C133A6-DF30-4F01-8229-1BEB7BB0FBD8@blacknight.ie> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 17:18:15 -0000 On 04/01/12 21:34, Michele Neylon :: Blacknight wrote: > So you want us to do the extra work? :) Now, to be frank, doing the extra work when sending isn't a big deal, but I'd personally prefer to avoid having to divvy up a list of domains into separate requests if at all possible. Being able to batch domain availability checks from multiple customers at once is a big win for us. Language tags in commands negate this benefit. So, yeah... K. -- Keith Gaughan, Senior Developer PGP/GPG key ID: 3E896381 Blacknight Internet Solutions Ltd. 12A Barrowside Business Park, Carlow, Ireland Registered in Ireland, Company No.: 370845 From fobispo@isc.org Fri Jan 6 09:18:46 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8117E21F8799 for ; Fri, 6 Jan 2012 09:18:46 -0800 (PST) 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=[AWL=-0.000, BAYES_00=-2.599, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9raUdrQM2nC for ; Fri, 6 Jan 2012 09:18:46 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6C821F8798 for ; Fri, 6 Jan 2012 09:18:46 -0800 (PST) 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.pao1.isc.org (Postfix) with ESMTPS id 957D2C9465; Fri, 6 Jan 2012 17:18:32 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [192.168.1.102] (unknown [190.202.176.226]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id E10D7216C6D; Fri, 6 Jan 2012 17:18:31 +0000 (UTC) (envelope-from fobispo@isc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Francisco Obispo In-Reply-To: <4F072ADD.8050300@blacknight.com> Date: Fri, 6 Jan 2012 09:18:44 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <83689248-145F-444A-BF27-6F96B7E78C3E@isc.org> References: <4F049E6C.7060100@blacknight.com> <4E713373-4FFE-43E7-8625-F81AC86CF1E9@mwyoung.ca> <29AD57F4-D97A-46A7-BDCA-6DABFCE022AB@isc.org> <4F072ADD.8050300@blacknight.com> To: Keith Gaughan X-Mailer: Apple Mail (2.1251.1) Cc: provreg@ietf.org Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 17:18:46 -0000 On Jan 6, 2012, at 9:09 AM, Keith Gaughan wrote: > On 04/01/12 20:44, Francisco Obispo wrote: >=20 >> I agree that registrars should be performing those tests/validations = ahead >> of time and shouldn't rely exclusively on the registry for those = types of >> validation, because that would increase registry load significantly. >=20 > I very much doubt that it would increase registry load significantly, = and I > know because I've implemented code to do exactly that kind of = validation, and > the additional extra load was negligible in terms of overall request > processing time. It wasn't even a blip compared to even the overhead = of > marshalling and unmarshalling EPP stanzas. >=20 > Both registrars and registries should be checking IDNs against = codepoint > whitelists. >=20 I agree, _both_ should be doing it,... my point above was about = registrars exclusively performing validations using the command. At the end, I think this is implementation-specific, we might argue that = it will or not, but it all comes down to the platform that is handling = it. Thanks=20 > --=20 > Keith Gaughan, Senior 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 Francisco Obispo=20 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 fobispo@isc.org Fri Jan 6 09:22:57 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 496A621F87E0 for ; Fri, 6 Jan 2012 09:22:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZlkb-+486PA for ; Fri, 6 Jan 2012 09:22:57 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id D34AC21F878F for ; Fri, 6 Jan 2012 09:22:56 -0800 (PST) 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.pao1.isc.org (Postfix) with ESMTPS id D579BC944A; Fri, 6 Jan 2012 17:22:42 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [192.168.1.102] (unknown [190.202.176.226]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 3193F216C6A; Fri, 6 Jan 2012 17:22:42 +0000 (UTC) (envelope-from fobispo@isc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Francisco Obispo In-Reply-To: <4F072CD5.9040202@blacknight.com> Date: Fri, 6 Jan 2012 09:22:54 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <4F049E6C.7060100@blacknight.com> <4E713373-4FFE-43E7-8625-F81AC86CF1E9@mwyoung.ca> <55C30604-0432-48E1-885E-C691448B08A9@frobbit.se> <03AFAC20-A409-42BA-92CD-48BCBC9C521D@mwyoung.ca> <48C133A6-DF30-4F01-8229-1BEB7BB0FBD8@blacknight.ie> <4F072CD5.9040202@blacknight.com> To: Keith Gaughan X-Mailer: Apple Mail (2.1251.1) Cc: provreg@ietf.org Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 17:22:57 -0000 you would have to batch them by language, which could be cumbersome. The alternative, would be to provide domain:check with A-labels On Jan 6, 2012, at 9:18 AM, Keith Gaughan wrote: > > Being able to batch domain availability checks from multiple customers at > once is a big win for us. Language tags in commands negate > this benefit. So, yeah... Francisco Obispo email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC Key fingerprint = 532F 84EB 06B4 3806 D5FA 09C6 463E 614E B38D B1BE From fobispo@isc.org Fri Jan 6 09:24:34 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1B221F8977 for ; Fri, 6 Jan 2012 09:24:34 -0800 (PST) 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=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hDe8gjBmpBB for ; Fri, 6 Jan 2012 09:24:34 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 007E921F8961 for ; Fri, 6 Jan 2012 09:24:34 -0800 (PST) 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.pao1.isc.org (Postfix) with ESMTPS id 21BB4C9465; Fri, 6 Jan 2012 17:24:18 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [192.168.1.102] (unknown [190.202.176.226]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 8F80A216C6A; Fri, 6 Jan 2012 17:24:17 +0000 (UTC) (envelope-from fobispo@isc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Francisco Obispo In-Reply-To: Date: Fri, 6 Jan 2012 09:24:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3AFF9C0A-7FC3-4F5F-AF45-4D8D40E94DB2@isc.org> References: <4F049E6C.7060100@blacknight.com> <4E713373-4FFE-43E7-8625-F81AC86CF1E9@mwyoung.ca> <55C30604-0432-48E1-885E-C691448B08A9@frobbit.se> <03AFAC20-A409-42BA-92CD-48BCBC9C521D@mwyoung.ca> <48C133A6-DF30-4F01-8229-1BEB7BB0FBD8@blacknight.ie> <4F072CD5.9040202@blacknight.com> To: Keith Gaughan X-Mailer: Apple Mail (2.1251.1) Cc: provreg@ietf.org Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 17:24:34 -0000 hit "send" to early.... On Jan 6, 2012, at 9:22 AM, Francisco Obispo wrote: > you would have to batch them by language, which could be cumbersome.=20= >=20 > The alternative, would be to provide domain:check with A-labels >=20 and provide an interface in the idn extension to enumerate the language = for each supplied.. but it will most likely by ugly. Francisco >=20 > On Jan 6, 2012, at 9:18 AM, Keith Gaughan wrote: >=20 >>=20 >> Being able to batch domain availability checks from multiple = customers at >> once is a big win for us. Language tags in commands = negate >> this benefit. So, yeah... >=20 > Francisco Obispo=20 > 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 >=20 >=20 >=20 >=20 >=20 Francisco Obispo=20 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 brunner@nic-naa.net Fri Jan 6 09:32:48 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 577FE21F89AD for ; Fri, 6 Jan 2012 09:32:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xl2g-IMbP12b for ; Fri, 6 Jan 2012 09:32:47 -0800 (PST) Received: from nic-naa.net (nic-naa.net [65.99.1.132]) by ietfa.amsl.com (Postfix) with ESMTP id 49B8121F897F for ; Fri, 6 Jan 2012 09:32:46 -0800 (PST) Received: from limpet.local (cpe-67-255-2-48.twcny.res.rr.com [67.255.2.48]) by nic-naa.net (8.14.4/8.14.4) with ESMTP id q06EvB1h001814 for ; Fri, 6 Jan 2012 09:57:12 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-ID: <4F073038.5090405@nic-naa.net> Date: Fri, 06 Jan 2012 12:32:40 -0500 From: Eric Brunner-Williams Organization: wampumpeag User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: provreg@ietf.org References: <20111222002234.8359.14617.idtracker@ietfa.amsl.com> <0CB499D3-A9F7-4D3B-A7BA-6410E306BD25@frobbit.se> <20120104201038.GA32606@crankycanuck.ca> <4D64ACFF-A2AC-4C68-9346-97C118750C08@isc.org> In-Reply-To: <4D64ACFF-A2AC-4C68-9346-97C118750C08@isc.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] New Version Notification for draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ebw@abenaki.wabanaki.net List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 17:32:48 -0000 On 1/6/12 12:12 PM, Francisco Obispo wrote: > How about if we change the tag for and its value will be the "name" of the IDN table as published/offered by the registry? This allows the possibility of per-registry versioning of "name", and of non-unique names (or registry scoped name uniqueness, see "versioning" above). Abstractly, this is a database write access token, and the (ICANN) policy issue of equal access / registry-registrar collusion is non-solved, absent out of band compliance review, so accepting an arbitrary access token may be good generic any-level-in-any-DNS-hierarchy engineering, accepting only an ICANN identified access token for ICANN generic namespaces may be a better IETF protocol parameter choice. YMMV. Eric From keith@blacknight.com Fri Jan 6 09:34:06 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBB021F89B5 for ; Fri, 6 Jan 2012 09:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.622 X-Spam-Level: X-Spam-Status: No, score=-3.622 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNTW5h+tA4MC for ; Fri, 6 Jan 2012 09:34:05 -0800 (PST) Received: from relay1.blacknight.com (relay1.blacknight.com [78.153.203.204]) by ietfa.amsl.com (Postfix) with ESMTP id 8170F21F89B4 for ; Fri, 6 Jan 2012 09:34:05 -0800 (PST) Received: from hegemon.blacknight.ie (hegemon.blacknight.ie [81.17.243.239]) by relay1.blacknight.com (Postfix) with ESMTP id 4679835C524 for ; Fri, 6 Jan 2012 17:34:04 +0000 (GMT) Message-ID: <4F07308C.8090109@blacknight.com> Date: Fri, 06 Jan 2012 17:34:04 +0000 From: Keith Gaughan Organization: Blacknight Internet Solutions User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: provreg@ietf.org References: <4F049E6C.7060100@blacknight.com> <4E713373-4FFE-43E7-8625-F81AC86CF1E9@mwyoung.ca> <29AD57F4-D97A-46A7-BDCA-6DABFCE022AB@isc.org> <4F072ADD.8050300@blacknight.com> <83689248-145F-444A-BF27-6F96B7E78C3E@isc.org> In-Reply-To: <83689248-145F-444A-BF27-6F96B7E78C3E@isc.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 17:34:06 -0000 On 06/01/12 17:18, Francisco Obispo wrote: > > On Jan 6, 2012, at 9:09 AM, Keith Gaughan wrote: > >> On 04/01/12 20:44, Francisco Obispo wrote: >> >>> I agree that registrars should be performing those tests/validations ahead >>> of time and shouldn't rely exclusively on the registry for those types of >>> validation, because that would increase registry load significantly. >> >> I very much doubt that it would increase registry load significantly, and I >> know because I've implemented code to do exactly that kind of validation, and >> the additional extra load was negligible in terms of overall request >> processing time. It wasn't even a blip compared to even the overhead of >> marshalling and unmarshalling EPP stanzas. >> >> Both registrars and registries should be checking IDNs against codepoint >> whitelists. > > I agree, _both_ should be doing it,... my point above was about registrars > exclusively performing validations using the command. Which is exactly why I think registries should be penalising registrars the are plainly not validating IDNs they submit in commands rather than requiring language tags be provided in commands. Essentially, I'd prefer misbehaving registrars were penalised rather than having well-behaved registrars such as ourselves[1]. Without the language tag, we're able to batch multiple checks from multiple customers into a single request. This makes our store more responsive. Requiring a language tag be provided means this ability to batch checks is reduced because we'll have to group domains in batches based upon the language code. I can't emphasise how important it is for a registrar that domain availability checks be quick. Anything that compromises response time in this area means potential loss of sales. > At the end, I think this is implementation-specific, we might argue that it > will or not, but it all comes down to the platform that is handling it. K. [1] Though anybody who's met Michele may disagree! -- Keith Gaughan, Senior 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 Jan 6 09:42:53 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0D021F89C0 for ; Fri, 6 Jan 2012 09:42:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.32 X-Spam-Level: X-Spam-Status: No, score=-3.32 tagged_above=-999 required=5 tests=[AWL=-0.321, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1S+H6dJ19Ey for ; Fri, 6 Jan 2012 09:42:52 -0800 (PST) Received: from relay1.blacknight.com (relay1.blacknight.com [78.153.203.204]) by ietfa.amsl.com (Postfix) with ESMTP id 72E1B21F89B9 for ; Fri, 6 Jan 2012 09:42:52 -0800 (PST) Received: from hegemon.blacknight.ie (hegemon.blacknight.ie [81.17.243.239]) by relay1.blacknight.com (Postfix) with ESMTP id 6B26E35C5B9 for ; Fri, 6 Jan 2012 17:42:51 +0000 (GMT) Message-ID: <4F07329A.9080006@blacknight.com> Date: Fri, 06 Jan 2012 17:42:50 +0000 From: Keith Gaughan Organization: Blacknight Internet Solutions User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: provreg@ietf.org References: <4F049E6C.7060100@blacknight.com> <4E713373-4FFE-43E7-8625-F81AC86CF1E9@mwyoung.ca> <55C30604-0432-48E1-885E-C691448B08A9@frobbit.se> <03AFAC20-A409-42BA-92CD-48BCBC9C521D@mwyoung.ca> <48C133A6-DF30-4F01-8229-1BEB7BB0FBD8@blacknight.ie> <4F072CD5.9040202@blacknight.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 17:42:53 -0000 On 06/01/12 17:22, Francisco Obispo wrote: > you would have to batch them by language, which could be cumbersome. This is what we already do for registry operators, such as Neustar, who already require language codes be provided when performing a . And yes, it is cumbersome, which is why I'm so dead-set against the extension requiring language tags be submitted when making request that contains one or more IDNs. > The alternative, would be to provide domain:check with A-labels We use A-labels internally for everything already. It's less prone to errors such as accidental encoding issues than using U-labels everywhere. The only times we deal with U-labels is when accepting requests from our store and validating IDNs. Unfortunately, that doesn't negate the need to send language codes to registrars. K. -- Keith Gaughan, Senior 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 Jan 6 09:46:23 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8004821F8965 for ; Fri, 6 Jan 2012 09:46:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.296 X-Spam-Level: X-Spam-Status: No, score=-3.296 tagged_above=-999 required=5 tests=[AWL=-0.297, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+vSdOxoL5xg for ; Fri, 6 Jan 2012 09:46:23 -0800 (PST) Received: from relay1.blacknight.com (relay1.blacknight.com [78.153.203.204]) by ietfa.amsl.com (Postfix) with ESMTP id CF9A121F8962 for ; Fri, 6 Jan 2012 09:46:22 -0800 (PST) Received: from hegemon.blacknight.ie (hegemon.blacknight.ie [81.17.243.239]) by relay1.blacknight.com (Postfix) with ESMTP id 0AC1435C537 for ; Fri, 6 Jan 2012 17:46:21 +0000 (GMT) Message-ID: <4F07336D.90803@blacknight.com> Date: Fri, 06 Jan 2012 17:46:21 +0000 From: Keith Gaughan Organization: Blacknight Internet Solutions User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: provreg@ietf.org References: <4F049E6C.7060100@blacknight.com> <4E713373-4FFE-43E7-8625-F81AC86CF1E9@mwyoung.ca> <55C30604-0432-48E1-885E-C691448B08A9@frobbit.se> <03AFAC20-A409-42BA-92CD-48BCBC9C521D@mwyoung.ca> <48C133A6-DF30-4F01-8229-1BEB7BB0FBD8@blacknight.ie> <4F072CD5.9040202@blacknight.com> <3AFF9C0A-7FC3-4F5F-AF45-4D8D40E94DB2@isc.org> In-Reply-To: <3AFF9C0A-7FC3-4F5F-AF45-4D8D40E94DB2@isc.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 17:46:23 -0000 On 06/01/12 17:24, Francisco Obispo wrote: > hit "send" to early.... > > > On Jan 6, 2012, at 9:22 AM, Francisco Obispo wrote: > >> you would have to batch them by language, which could be cumbersome. >> >> The alternative, would be to provide domain:check with A-labels >> > > and provide an interface in the idn extension to enumerate the language for each supplied.. but it will most likely by ugly. That's something I thought of myself, and while preferable because it at least allows for batching, you're right, it would be ugly, not least because it means the same data gets repeated twice in the one request. -- Keith Gaughan, Senior 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 Jan 6 10:01:20 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1101921F897F for ; Fri, 6 Jan 2012 10:01:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.574 X-Spam-Level: X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iA4ebldODSGc for ; Fri, 6 Jan 2012 10:01:19 -0800 (PST) Received: from relay1.blacknight.com (relay1.blacknight.com [78.153.203.204]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFCE21F897C for ; Fri, 6 Jan 2012 10:01:19 -0800 (PST) Received: from hegemon.blacknight.ie (hegemon.blacknight.ie [81.17.243.239]) by relay1.blacknight.com (Postfix) with ESMTP id 4D71635C51F for ; Fri, 6 Jan 2012 18:01:18 +0000 (GMT) Message-ID: <4F0736EE.9050407@blacknight.com> Date: Fri, 06 Jan 2012 18:01:18 +0000 From: Keith Gaughan Organization: Blacknight Internet Solutions User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: provreg@ietf.org References: <4F049E6C.7060100@blacknight.com> <4E713373-4FFE-43E7-8625-F81AC86CF1E9@mwyoung.ca> <55C30604-0432-48E1-885E-C691448B08A9@frobbit.se> <03AFAC20-A409-42BA-92CD-48BCBC9C521D@mwyoung.ca> <20120104220058.GD32606@crankycanuck.ca> <20120105033431.GA33245@crankycanuck.ca> In-Reply-To: <20120105033431.GA33245@crankycanuck.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 18:01:20 -0000 On 05/01/12 03:34, Andrew Sullivan wrote: > On Wed, Jan 04, 2012 at 07:15:49PM -0500, Michael Young wrote: > >> the use cases. Somewhere in all that I noted you were ok with the >> check ext being optional :-) > > Actually, you misread, then. I think servers (implementing this > extension) MUST support the extension to check. Clients MAY send it > or not (which means that implementation is for practical purposes > optional for them. Very true, and that I would be OK with, though I suspect many registrars would simply ignore the extension of , making the requirement that registries support is somewhat pointless. Still, you've left out the most important reason why servers ought to be checking IDNs: registrars and their customers can lie. Just because they've filled out they filled out the language tag doesn't mean that language code has any bearing on reality. At best, if they are validating, it's just a way for the registry to cut down on the number of whitelists they need to check. Now, there are reasonable reasons for a registrar to lie. We, for instance, only take a guess at the language an IDN might be for and for the likes of Neustar who require a language code be provided, we provide that to them. The domain might actually be an Irish-language one like rsrothairnabhaile.biz[1], but that'll fit the table for French, which means as far as the registry is concerned, that's a valid IDNs. K. -- Keith Gaughan, Senior 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 Jan 6 10:17:24 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA0321F89A9 for ; Fri, 6 Jan 2012 10:17:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.576 X-Spam-Level: X-Spam-Status: No, score=-3.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RK4-KpRjg+a6 for ; Fri, 6 Jan 2012 10:17:23 -0800 (PST) Received: from relay1.blacknight.com (relay1.blacknight.com [78.153.203.204]) by ietfa.amsl.com (Postfix) with ESMTP id 4765A21F8988 for ; Fri, 6 Jan 2012 10:17:23 -0800 (PST) Received: from hegemon.blacknight.ie (hegemon.blacknight.ie [81.17.243.239]) by relay1.blacknight.com (Postfix) with ESMTP id 100E035C5C7 for ; Fri, 6 Jan 2012 18:17:21 +0000 (GMT) Message-ID: <4F073AB0.9080101@blacknight.com> Date: Fri, 06 Jan 2012 18:17:20 +0000 From: Keith Gaughan Organization: Blacknight Internet Solutions User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: provreg@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 18:17:24 -0000 On 05/01/12 06:49, Patrik Fltstrm wrote: > - We would not have the ability for registries to invent their own > extensions without IETF review (i.e. like other protocols) An unfortunate consequence of that would be that some registries would just fork the protocol and use something that's almost-but-not-quite EPP. EURid went and did this, and when I wrote our EPP client, it was built to account for nonsense like this, which made the code much more complex than I'd like. > Example of the 2nd are all the registries that require delegation at time > of registration (something that should be forbidden, but now some > registries are like that), that required creation of contact objects and > host objects before the domain object is created and glued together. If > at that point in time the create fails, the creation of the other objects > would have automatically been undone. Maybe as a transaction, I do not > know. We should have thought about it harder. Actually, I've no problem with creating contacts, then having the subsequent registration fail. But what I'd prefer to be different is that I think the split between hosts as objects and hosts as domain attributes was a mistake. In addition, I think that if a , &c., request is made and a set of nameserver hosts are specified on it that have not been explicitly created with , the registry should implicitly create those hosts. Another thing I'd change is provide a way for registries to signal to registrars that they've garbage collected contacts (and possibly hosts too). K. -- Keith Gaughan, Senior 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 Jan 6 10:36:24 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348FF21F87C8 for ; Fri, 6 Jan 2012 10:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.577 X-Spam-Level: X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OiGsv5QF+bFz for ; Fri, 6 Jan 2012 10:36:23 -0800 (PST) Received: from relay1.blacknight.com (relay1.blacknight.com [78.153.203.204]) by ietfa.amsl.com (Postfix) with ESMTP id 44FF121F89DA for ; Fri, 6 Jan 2012 10:36:22 -0800 (PST) Received: from hegemon.blacknight.ie (hegemon.blacknight.ie [81.17.243.239]) by relay1.blacknight.com (Postfix) with ESMTP id ACECD35C5E7 for ; Fri, 6 Jan 2012 18:36:21 +0000 (GMT) Message-ID: <4F073F25.8010004@blacknight.com> Date: Fri, 06 Jan 2012 18:36:21 +0000 From: Keith Gaughan Organization: Blacknight Internet Solutions User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: provreg@ietf.org References: <9F98E660-2796-4A13-ADE9-F1F61D178D71@mwyoung.ca> <20120105192116.GC33552@shinkuro.com> <04cb01cccbf9$4ee111d0$eca33570$@mwyoung.ca> <4C1CAA44-A9C1-4CD1-B7C3-91AD5D64A5DB@frobbit.se> In-Reply-To: <4C1CAA44-A9C1-4CD1-B7C3-91AD5D64A5DB@frobbit.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 18:36:24 -0000 On 06/01/12 07:21, Patrik Fltstrm wrote: > If registries did harmonize more, it would make registrar work easier. After all, we're all in the business of selling domains, and it's not as if registries are in competition with one another. The faster I as a software engineer employed by a registrar can get integrated with you as a registry, the better for us both, and the more profit for all! > And more harmonization would also because the translation engines in the > registrars act more similar which implies the users would get more similar > user interface when comparing registrars. Not to mention a smoother experience for all. But unfortunately politics comes into things and blinds everybody to what's to their mutual advantage. > Today, having similar user interfaces for for example .EU, .COM, .ORG and > .SE is not easy. EURid are, due to gradual registrar pressure, moving towards a less 'special' variation of EPP. That's a positive development. As far as .com goes (and all the VeriSign-managed zones too), I think the best thing they could do for registrars is scrap their NameStore extension. I can't fathom the train of thought that made their developers think that'd be a good idea. It's up there with running .tv and .cc (thin) on the same EPP server as .jobs (thick), which messes up any chance clients have of autodetecting if the registry is thick or thin. .se is on my (long) list of ccTLDs to interface with, so I can't remember how much of a pain that's going to be. > The TLDs are so completely different in the epp > implementation that they are...hmm...different. The worst of it is the pride some registry operators have in how different they are. I've read stuff by non-EPP ccTLDs registrars who practically boast about how they have their own interface and how EPP couldn't possibly suit their use cases. -- Keith Gaughan, Senior Developer PGP/GPG key ID: 3E896381 Blacknight Internet Solutions Ltd. 12A Barrowside Business Park, Carlow, Ireland Registered in Ireland, Company No.: 370845 From shollenbeck@verisign.com Fri Jan 6 10:42:41 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E873B21F8873 for ; Fri, 6 Jan 2012 10:42:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7G7OA1JIGvp9 for ; Fri, 6 Jan 2012 10:42:41 -0800 (PST) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by ietfa.amsl.com (Postfix) with ESMTP id 2C60F21F886C for ; Fri, 6 Jan 2012 10:42:41 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKTwdAjUk5rTWi/fSan6xFKGTKeZoaWUtD@postini.com; Fri, 06 Jan 2012 10:42:41 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q06IgLCZ017744; Fri, 6 Jan 2012 13:42:21 -0500 Received: from BRN1WNEXCAS01.vcorp.ad.vrsn.com ([10.173.152.205]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Jan 2012 13:42:21 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.01.0323.003; Fri, 6 Jan 2012 13:42:20 -0500 From: "Hollenbeck, Scott" To: Keith Gaughan , "provreg@ietf.org" Thread-Topic: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt Thread-Index: AQHMzJ9zLGAJD/4yTU2wJykkwB4pKpX/q/SA Date: Fri, 6 Jan 2012 18:42:19 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D577BEF@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <4F073AB0.9080101@blacknight.com> In-Reply-To: <4F073AB0.9080101@blacknight.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: 06 Jan 2012 18:42:21.0168 (UTC) FILETIME=[EC830700:01CCCCA2] Subject: Re: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 18:42:42 -0000 > -----Original Message----- > From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On > Behalf Of Keith Gaughan > Sent: Friday, January 06, 2012 1:17 PM > To: provreg@ietf.org > Subject: [provreg] Changes we'd make to EPP, was Re: Domain check in > draft-obispo-epp-idn-00.txt >=20 > Actually, I've no problem with creating contacts, then having the > subsequent > registration fail. But what I'd prefer to be different is that I think > the > split between hosts as objects and hosts as domain attributes was a > mistake. It wasn't originally designed that way. The split came about as a result of= a need to build consensus within the working group. Scott From keith@blacknight.com Fri Jan 6 10:45:21 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D791D21F87C5 for ; Fri, 6 Jan 2012 10:45:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qyoFomlGc45W for ; Fri, 6 Jan 2012 10:45:21 -0800 (PST) Received: from relay1.blacknight.com (relay1.blacknight.com [78.153.203.204]) by ietfa.amsl.com (Postfix) with ESMTP id 492E921F87B0 for ; Fri, 6 Jan 2012 10:45:20 -0800 (PST) Received: from hegemon.blacknight.ie (hegemon.blacknight.ie [81.17.243.239]) by relay1.blacknight.com (Postfix) with ESMTP id 5B5BB35C528 for ; Fri, 6 Jan 2012 18:45:20 +0000 (GMT) Message-ID: <4F074140.9060300@blacknight.com> Date: Fri, 06 Jan 2012 18:45:20 +0000 From: Keith Gaughan Organization: Blacknight Internet Solutions User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: provreg@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 18:45:22 -0000 On 06/01/12 14:24, Gould, James wrote: > EPP's extensibility is > a feature but best practices should be followed (e.g. make them opt-in > extensions) when creating them and it makes sense to move some of the > custom extensions up the standards track to create consistency. Severely lacking currently are informational RFCs concerning best current practice for those implementing EPP clients and servers. > I believe with the launch of a large > set of new TLD's it makes sense to at a minimum have a BoF to discuss the > custom extensions to see if a set of common / standard extensions can be > identified. I concur. > I also have the idea of creating a Domain Registry > EPP Mapping that at a minimum would include support for an info command > and response for providing the features and policies for a TLD or set of > TLD's. This would provide information to the Registrars that could help > automate and subsequently scale the number of TLD's. I mentioned that very idea on this list before Christmas. The rough consensus was that things like a registry policy ought to be provided independently of EPP. Some also expressed scepticism that it'd even be possible to account for all the possible variations on registry policy. It's something I've been working on during my free time, but due to my lack of free time lately, is not something I've made as much progress on as I'd like. -- Keith Gaughan, Senior 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 Jan 6 10:47:28 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB9E021F89AE for ; Fri, 6 Jan 2012 10:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.58 X-Spam-Level: X-Spam-Status: No, score=-3.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WisAXxyzpNRS for ; Fri, 6 Jan 2012 10:47:28 -0800 (PST) Received: from relay1.blacknight.com (relay1.blacknight.com [78.153.203.204]) by ietfa.amsl.com (Postfix) with ESMTP id 60E8021F89A0 for ; Fri, 6 Jan 2012 10:47:28 -0800 (PST) Received: from hegemon.blacknight.ie (hegemon.blacknight.ie [81.17.243.239]) by relay1.blacknight.com (Postfix) with ESMTP id DB59F35C528 for ; Fri, 6 Jan 2012 18:47:26 +0000 (GMT) Message-ID: <4F0741BE.4010606@blacknight.com> Date: Fri, 06 Jan 2012 18:47:26 +0000 From: Keith Gaughan Organization: Blacknight Internet Solutions User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: "provreg@ietf.org" References: <4F073AB0.9080101@blacknight.com> <831693C2CDA2E849A7D7A712B24E257F0D577BEF@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D577BEF@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 18:47:29 -0000 On 06/01/12 18:42, Hollenbeck, Scott wrote: > It wasn't originally designed that way. The split came about as a result > of a need to build consensus within the working group. Yes, I remember reading about that when I was going over the list archives a while back. I understand why it happened, but it still appear to have been unfortunate. K. -- Keith Gaughan, Senior Developer PGP/GPG key ID: 3E896381 Blacknight Internet Solutions Ltd. 12A Barrowside Business Park, Carlow, Ireland Registered in Ireland, Company No.: 370845 From ajs@anvilwalrusden.com Fri Jan 6 10:58:31 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6D521F8753 for ; Fri, 6 Jan 2012 10:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.766 X-Spam-Level: X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9qce4Oh9y5c for ; Fri, 6 Jan 2012 10:58:30 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 9837321F8751 for ; Fri, 6 Jan 2012 10:58:30 -0800 (PST) Received: from hardhat (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id A1F741ECB41C for ; Fri, 6 Jan 2012 18:58:29 +0000 (UTC) Date: Fri, 6 Jan 2012 13:58:06 -0500 From: Andrew Sullivan To: provreg@ietf.org Message-ID: <20120106185806.GA99133@crankycanuck.ca> References: <4F073AB0.9080101@blacknight.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F073AB0.9080101@blacknight.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 18:58:31 -0000 On Fri, Jan 06, 2012 at 06:17:20PM +0000, Keith Gaughan wrote: > Another thing I'd change is provide a way for registries to signal to > registrars that they've garbage collected contacts (and possibly hosts too). This, at least, ought to be possible using the poll queue. I think the poll queue as it stands is less than ideal, however. I made a suggestion about how to make the poll queue better for these purposes in a long-expired draft (draft-sullivan-epp-experience-00), but they weren't very popular. -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Fri Jan 6 11:03:38 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1555B21F87E4 for ; Fri, 6 Jan 2012 11:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.753 X-Spam-Level: X-Spam-Status: No, score=-2.753 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fjTiL9u3Noo for ; Fri, 6 Jan 2012 11:03:37 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 9279121F87DB for ; Fri, 6 Jan 2012 11:03:37 -0800 (PST) Received: from hardhat (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id EBF8F1ECB41C for ; Fri, 6 Jan 2012 19:03:36 +0000 (UTC) Date: Fri, 6 Jan 2012 14:03:35 -0500 From: Andrew Sullivan To: provreg@ietf.org Message-ID: <20120106190335.GB99133@crankycanuck.ca> References: <4F049E6C.7060100@blacknight.com> <4E713373-4FFE-43E7-8625-F81AC86CF1E9@mwyoung.ca> <55C30604-0432-48E1-885E-C691448B08A9@frobbit.se> <03AFAC20-A409-42BA-92CD-48BCBC9C521D@mwyoung.ca> <20120104220058.GD32606@crankycanuck.ca> <20120105033431.GA33245@crankycanuck.ca> <4F0736EE.9050407@blacknight.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4F0736EE.9050407@blacknight.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 19:03:38 -0000 On Fri, Jan 06, 2012 at 06:01:18PM +0000, Keith Gaughan wrote: > Very true, and that I would be OK with, though I suspect many registrars > would simply ignore the extension of , making the requirement > that registries support is somewhat pointless. Of course some would ignore it. Many registrars do blind create today, too, rather than performing a check. > Still, you've left out the most important reason why servers ought to be > checking IDNs I had no intention of suggesting that the server side (formally, the repository in EPP-speak) needn't check input. I personally would prefer that gTLD registries do more validation, not less, and I think you're a moron if you don't check your input for minimal compliance with your own policies. > Now, there are reasonable reasons for a registrar to lie. We, for instance, > only take a guess at the language an IDN might be for and for the likes of > Neustar who require a language code be provided, we provide that to them. > The domain might actually be an Irish-language one like > rásrothairnabhaile.biz[1], but that'll fit the table for French, which means > as far as the registry is concerned, that's a valid IDNs. Well, guessing will only get you so far. If your customer sends you a string in NFD form, what do you do? What about in ISO8859-1? A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Fri Jan 6 11:06:49 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5A221F8806 for ; Fri, 6 Jan 2012 11:06:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.742 X-Spam-Level: X-Spam-Status: No, score=-2.742 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AUPElHYUrZR for ; Fri, 6 Jan 2012 11:06:49 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 07C1D21F8805 for ; Fri, 6 Jan 2012 11:06:49 -0800 (PST) Received: from hardhat (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 1DFD81ECB41C for ; Fri, 6 Jan 2012 19:06:48 +0000 (UTC) Date: Fri, 6 Jan 2012 14:06:46 -0500 From: Andrew Sullivan To: provreg@ietf.org Message-ID: <20120106190646.GC99133@crankycanuck.ca> References: <20111222002234.8359.14617.idtracker@ietfa.amsl.com> <0CB499D3-A9F7-4D3B-A7BA-6410E306BD25@frobbit.se> <20120104201038.GA32606@crankycanuck.ca> <4D64ACFF-A2AC-4C68-9346-97C118750C08@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D64ACFF-A2AC-4C68-9346-97C118750C08@isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [provreg] New Version Notification for draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 19:06:49 -0000 On Fri, Jan 06, 2012 at 09:12:56AM -0800, Francisco Obispo wrote: > Andrew, > > How about if we change the tag for and its value will be the "name" of the IDN table as published/offered by the registry? > There will be people annoyed by "table" because they think that's a particular implementation. I'm indifferent. I think it's better than language or script, though. I've just been calling it a repertiore identifier, so what about repID? A -- Andrew Sullivan ajs@anvilwalrusden.com From JGould@verisign.com Fri Jan 6 11:35:39 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8922521F87C8 for ; Fri, 6 Jan 2012 11:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R09RGA73Mo+B for ; Fri, 6 Jan 2012 11:35:38 -0800 (PST) Received: from exprod6og104.obsmtp.com (exprod6og104.obsmtp.com [64.18.1.187]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4C221F87BA for ; Fri, 6 Jan 2012 11:35:38 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP ID DSNKTwdNBumHjjfXllwiauvM2v2J+YaItP6Q@postini.com; Fri, 06 Jan 2012 11:35:38 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q06JZVlm019685; Fri, 6 Jan 2012 14:35:33 -0500 Received: from dul1wnexcn04.vcorp.ad.vrsn.com ([10.170.12.139]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Jan 2012 14:35:31 -0500 Received: from BRN1WNEXCAS02.vcorp.ad.vrsn.com ([10.173.152.246]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Jan 2012 14:35:30 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.01.0323.003; Fri, 6 Jan 2012 14:35:30 -0500 From: "Gould, James" To: "ebw@abenaki.wabanaki.net" , "provreg@ietf.org" Thread-Topic: [provreg] New Version Notification for draft-obispo-epp-idn-00.txt Thread-Index: AQHMzKpZFTlCgpxAHk+PUTucC0QdNw== Date: Fri, 6 Jan 2012 19:35:29 +0000 Message-ID: In-Reply-To: <4F07230B.9030800@nic-naa.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <8511BE54EB1ADF4C8FEFF7E956C4C2B1@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 Jan 2012 19:35:30.0798 (UTC) FILETIME=[59ADF0E0:01CCCCAA] Subject: Re: [provreg] New Version Notification for draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 19:35:39 -0000 Eric, Verisign has posted tables of allowed codepoints with IANA. (http://www.iana.org/domains/idn-tables) I wonder if you might be referring to the Arabic table for the COM namespace. (http://www.iana.org/domains/idn-tables/tables/com_arab_1.0.html) This table reflects codepoints allowed in a COM domain by the Verisign Registry. The codepoints are based on the Unicode Standard, version 6.0. And specifically the scripts.txt file. (http://www.unicode.org/Public/UNIDATA/Scripts.txt) Verisign's goal is to leverage appropriate standards wherever possible, and that's what we tried to do with the Arabic table, and with other tables posted to the IANA site. But we're certainly open to ideas you might have about this or other tables. Constructive feedback is very welcome. --=20 JG James Gould Principal Software Engineer jgould@Verisign.com 703-948-3271 21345 Ridgetop Circle LS2-2-1 Dulles, VA 20166 VerisignInc.com On 1/6/12 11:36 AM, "Eric Brunner-Williams" wrote: >> Because of all of the above, I'd like to step back a bit from the >> language-vs-script and table-based way of framing this discussion and >> focus more on how one selects which set of code points one wants to >> use and, if there are rules governing the behaviour of those code >> points, how one expresses one's options under those rules. This will >> make for a more complicated EPP extension, but it will also make for >> one that actually matches the different registry policies already in >> place today. By creating an extension that can accommodate the many >> different policies in place, we might be able to reduce the number of >> extensions that actually get deployed. > >Concur. An ASCII (hex) code point repertoire of {(41,61), (45,65), >(49,69), (4f,6f), (55,75), (59,79)} (English vowels) is just as >reasonable a repertoire {30 ... 39} (digits) and just as reasonable a >repertoire as {30, 32, ... (5a,7a)} (even valued points within LDH) as >the ASCII LDH set of code points. None are sufficiently characterized >as "language" or "script", but are sufficiently characterized as >enumerations or rules for the construction of repertoires of code points. > >For a less mathematician-centric or >bottom-half-of-the-tty-driver-centric example, consider the "proper >word" requirement of the circa-2006 Arabic Script group. A "is in a >dictionary and is not on a reserved list" rule is neither "Arabic" >(the language") nor "Arabic Script" (the Unicadette created thingie an >earlier instance of the IDN WG, steered by non-contributors, elected >to commit _some_ DNS text resource records to). The dictionaries of >two "Arabic Language" supporting and "Arabic Script" using registries >may differ, as may their reserved lists. > >Verisign's take on Arabic makes me grin. I hope they'll be just as >creative when it comes to Chinese. > >My two beads worth, >Eric >_______________________________________________ >provreg mailing list >provreg@ietf.org >https://www.ietf.org/mailman/listinfo/provreg From JGould@verisign.com Fri Jan 6 12:28:33 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECE4321F8834 for ; Fri, 6 Jan 2012 12:28:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vB4NXmxvUQos for ; Fri, 6 Jan 2012 12:28:33 -0800 (PST) Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) by ietfa.amsl.com (Postfix) with ESMTP id A00CB21F8831 for ; Fri, 6 Jan 2012 12:28:32 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP ID DSNKTwdZYhfaSKbgKBPWPTKr7EopkY+Yvpto@postini.com; Fri, 06 Jan 2012 12:28:32 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q06KSGAI003832; Fri, 6 Jan 2012 15:28:18 -0500 Received: from dul1wnexcn04.vcorp.ad.vrsn.com ([10.170.12.139]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Jan 2012 15:28:16 -0500 Received: from BRN1WNEXCAS02.vcorp.ad.vrsn.com ([10.173.152.246]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Jan 2012 15:28:15 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.01.0323.003; Fri, 6 Jan 2012 15:28:15 -0500 From: "Gould, James" To: Keith Gaughan , "provreg@ietf.org" Thread-Topic: [provreg] Domain check in draft-obispo-epp-idn-00.txt Thread-Index: AQHMyNd/KIWK9LLq7U2BEGcH3XbUMZX85FsAgAAI/ICAABY2gIAABPCAgAAG1wCAAAt8AIAAJa2AgAA3hICAAALjgIAAM6KAgADMFgCAAAXqAIAANDgAgACU8YCAALyfgP//y2wA Date: Fri, 6 Jan 2012 20:28:14 +0000 Message-ID: In-Reply-To: <4F073F25.8010004@blacknight.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2B69500E8B4FB44BA4D65A02E5541A63@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 Jan 2012 20:28:15.0449 (UTC) FILETIME=[B7F55C90:01CCCCB1] Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 20:28:34 -0000 Keith, > As far as .com goes (and all the VeriSign-managed zones too), I think >the best > thing they could do for registrars is scrap their NameStore extension. I >can't > fathom the train of thought that made their developers think that'd be a >good > idea. It's up there with running .tv and .cc (thin) on the same EPP >server as > .jobs (thick), which messes up any chance clients have of autodetecting >if the > registry is thick or thin. The NameStore extension is used for routing requests to the correct back-end registry using a single EPP connection. The question is whether you would want to manage a separate session pool per TLD instead of managing a single session pool per system and passing the NameStore extension to indicate the logical registry to direct the request to. The train of thought is to provide a single destination for a set of EPP services where there might be multiple services that support the same XML namespaces (EPP mappings). Getting meta-data on a TLD level is the goal of the Registry EPP Mapping that I would like to create so that a Registrar can query or be notified of the set of EPP mappings, EPP extensions, features and policies supported on a per TLD level. Knowing only the supported EPP mappings and extensions (auto-detection) I don't believe will be enough to fulfill the goal of automating the enablement of a new TLD. =20 --=20 JG James Gould Principal Software Engineer jgould@Verisign.com 703-948-3271 21345 Ridgetop Circle LS2-2-1 Dulles, VA 20166 VerisignInc.com On 1/6/12 1:36 PM, "Keith Gaughan" wrote: >On 06/01/12 07:21, Patrik F=E4ltstr=F6m wrote: > >> If registries did harmonize more, it would make registrar work easier. > >After all, we're all in the business of selling domains, and it's not as >if registries are in competition with one another. The faster I as a >software engineer employed by a registrar can get integrated with you >as a registry, the better for us both, and the more profit for all! > >> And more harmonization would also because the translation engines in the >> registrars act more similar which implies the users would get more >>similar >> user interface when comparing registrars. > >Not to mention a smoother experience for all. But unfortunately politics >comes into things and blinds everybody to what's to their mutual >advantage. > >> Today, having similar user interfaces for for example .EU, .COM, .ORG >>and >> .SE is not easy. > >EURid are, due to gradual registrar pressure, moving towards a less >'special' >variation of EPP. That's a positive development. > >As far as .com goes (and all the VeriSign-managed zones too), I think the >best >thing they could do for registrars is scrap their NameStore extension. I >can't >fathom the train of thought that made their developers think that'd be a >good >idea. It's up there with running .tv and .cc (thin) on the same EPP >server as >.jobs (thick), which messes up any chance clients have of autodetecting >if the >registry is thick or thin. > >.se is on my (long) list of ccTLDs to interface with, so I can't remember >how >much of a pain that's going to be. > >> The TLDs are so completely different in the epp >> implementation that they are...hmm...different. > >The worst of it is the pride some registry operators have in how different >they are. I've read stuff by non-EPP ccTLDs registrars who practically >boast >about how they have their own interface and how EPP couldn't possibly suit >their use cases. > >--=20 >Keith Gaughan, Senior 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 JGould@verisign.com Fri Jan 6 13:51:53 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDA721F85CD for ; Fri, 6 Jan 2012 13:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ek0Edy2jFQzA for ; Fri, 6 Jan 2012 13:51:52 -0800 (PST) Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9F021F85B0 for ; Fri, 6 Jan 2012 13:51:52 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKTwds4wRA0k08Ka21gAYIxZ8ESqVZXwGe@postini.com; Fri, 06 Jan 2012 13:51:52 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q06LpSGT023489; Fri, 6 Jan 2012 16:51:30 -0500 Received: from dul1wnexcn04.vcorp.ad.vrsn.com ([10.170.12.139]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Jan 2012 16:51:28 -0500 Received: from BRN1WNEXCAS01.vcorp.ad.vrsn.com ([10.173.152.205]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Jan 2012 16:51:27 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.01.0323.003; Fri, 6 Jan 2012 16:51:27 -0500 From: "Gould, James" To: Keith Gaughan , "provreg@ietf.org" Thread-Topic: [provreg] Domain check in draft-obispo-epp-idn-00.txt Thread-Index: AQHMyNd/KIWK9LLq7U2BEGcH3XbUMZX85FsAgAAI/ICAABY2gIAABPCAgAAG1wCAAAt8AIAAJa2AgAA3hICAAALjgIAAM6KAgADMFgCAAAXqAIAANDgAgADnwgD//8+PgIAAnMEA///gKwA= Date: Fri, 6 Jan 2012 21:51:27 +0000 Message-ID: In-Reply-To: <4F074140.9060300@blacknight.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <413E073500738D4BB7BEEE1A655194FD@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 Jan 2012 21:51:27.0464 (UTC) FILETIME=[576E6680:01CCCCBD] Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 21:51:53 -0000 > I mentioned that very idea on this list before Christmas. The rough >consensus > was that things like a registry policy ought to be provided >independently of > EPP. Some also expressed scepticism that it'd even be possible to >account for > all the possible variations on registry policy. It's something I've been > working on during my free time, but due to my lack of free time lately, >is not > something I've made as much progress on as I'd like. A goal is to provide 90% of the feature and policy information to help drive the client logic. The mapping certainly wouldn't be small and might have to make external references for things like reserved names. I have done some work on it, but I wanted to know if there is interest in it. One of the key attributes would be the phases of the TLD (sunrise, rights, steadyState) with start and end dates. I might be dreaming that something useful could be created, but it might be worth a shot. =09 --=20 JG James Gould Principal Software Engineer jgould@Verisign.com 703-948-3271 21345 Ridgetop Circle LS2-2-1 Dulles, VA 20166 VerisignInc.com On 1/6/12 1:45 PM, "Keith Gaughan" wrote: >On 06/01/12 14:24, Gould, James wrote: > >> EPP's extensibility is >> a feature but best practices should be followed (e.g. make them opt-in >> extensions) when creating them and it makes sense to move some of the >> custom extensions up the standards track to create consistency. > >Severely lacking currently are informational RFCs concerning best current >practice for those implementing EPP clients and servers. > >> I believe with the launch of a large >> set of new TLD's it makes sense to at a minimum have a BoF to discuss >>the >> custom extensions to see if a set of common / standard extensions can be >> identified. > >I concur. > >> I also have the idea of creating a Domain Registry >> EPP Mapping that at a minimum would include support for an info command >> and response for providing the features and policies for a TLD or set of >> TLD's. This would provide information to the Registrars that could help >> automate and subsequently scale the number of TLD's. > >I mentioned that very idea on this list before Christmas. The rough >consensus >was that things like a registry policy ought to be provided independently >of >EPP. Some also expressed scepticism that it'd even be possible to account >for >all the possible variations on registry policy. It's something I've been >working on during my free time, but due to my lack of free time lately, >is not >something I've made as much progress on as I'd like. > >--=20 >Keith Gaughan, Senior 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 patrik@frobbit.se Sat Jan 7 01:48:00 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6269E21F856B for ; Sat, 7 Jan 2012 01:48:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.308 X-Spam-Level: X-Spam-Status: No, score=-102.308 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHZ4T5mrPiiv for ; Sat, 7 Jan 2012 01:48:00 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id BA4C221F851E for ; Sat, 7 Jan 2012 01:47:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 5A16912BA49E6; Sat, 7 Jan 2012 10:47:58 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bis-pWc5U9ZG; Sat, 7 Jan 2012 10:47:58 +0100 (CET) Received: from [IPv6:2a02:80:3ffc::14] (unknown [IPv6:2a02:80:3ffc::14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 21E2112BA49E3; Sat, 7 Jan 2012 10:47:58 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <4F073AB0.9080101@blacknight.com> Date: Sat, 7 Jan 2012 10:47:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <859F0583-3DE6-4E3B-80AF-A1D320F0348E@frobbit.se> References: <4F073AB0.9080101@blacknight.com> To: Keith Gaughan X-Mailer: Apple Mail (2.1251.1) Cc: provreg@ietf.org Subject: Re: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2012 09:48:00 -0000 On 6 jan 2012, at 19:17, Keith Gaughan wrote: > Actually, I've no problem with creating contacts, then having the = subsequent > registration fail. The case that could be discussed is how to handle transfer of domain = objects. What happens with the host and contact objects? That would be = good if there was an agreement on that. And I talk about epp here, and = not the business model, although they are hard to separate from each = other. Patrik From patrik@frobbit.se Sat Jan 7 01:49:50 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACF1421F853E for ; Sat, 7 Jan 2012 01:49:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.307 X-Spam-Level: X-Spam-Status: No, score=-102.307 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYkwsrImdJ0e for ; Sat, 7 Jan 2012 01:49:50 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 0C83E21F853D for ; Sat, 7 Jan 2012 01:49:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 611D212BA4AB4; Sat, 7 Jan 2012 10:49:49 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOVGoMiozySR; Sat, 7 Jan 2012 10:49:49 +0100 (CET) Received: from [IPv6:2a02:80:3ffc::14] (unknown [IPv6:2a02:80:3ffc::14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 28FB712BA4AB1; Sat, 7 Jan 2012 10:49:49 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20120106185806.GA99133@crankycanuck.ca> Date: Sat, 7 Jan 2012 10:49:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9362808D-CEF9-44CD-B4FA-542D6788B7A9@frobbit.se> References: <4F073AB0.9080101@blacknight.com> <20120106185806.GA99133@crankycanuck.ca> To: Andrew Sullivan X-Mailer: Apple Mail (2.1251.1) Cc: provreg@ietf.org Subject: Re: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2012 09:49:50 -0000 On 6 jan 2012, at 19:58, Andrew Sullivan wrote: > On Fri, Jan 06, 2012 at 06:17:20PM +0000, Keith Gaughan wrote: >> Another thing I'd change is provide a way for registries to signal to >> registrars that they've garbage collected contacts (and possibly = hosts too). >=20 > This, at least, ought to be possible using the poll queue. I think > the poll queue as it stands is less than ideal, however. I made a > suggestion about how to make the poll queue better for these purposes > in a long-expired draft (draft-sullivan-epp-experience-00), but they > weren't very popular. I rather see the registrar do "garbage_collect()" and the registry = respond with a list of objects that was deleted. That would limit the = amount of time the view of the world on the registry and registrar side = is different. Patrik From keith@blacknight.com Mon Jan 9 06:53:43 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4390421F87B1 for ; Mon, 9 Jan 2012 06:53:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.581 X-Spam-Level: X-Spam-Status: No, score=-3.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2lI761h2BED for ; Mon, 9 Jan 2012 06:53:39 -0800 (PST) Received: from relay1.blacknight.com (relay1.blacknight.com [78.153.203.204]) by ietfa.amsl.com (Postfix) with ESMTP id D0CCA21F87AC for ; Mon, 9 Jan 2012 06:53:31 -0800 (PST) Received: from hegemon.blacknight.ie (hegemon.blacknight.ie [81.17.243.239]) by relay1.blacknight.com (Postfix) with ESMTP id DDB4A35C1E3 for ; Mon, 9 Jan 2012 14:53:29 +0000 (GMT) Message-ID: <4F0AFF69.2090503@blacknight.com> Date: Mon, 09 Jan 2012 14:53:29 +0000 From: Keith Gaughan Organization: Blacknight Internet Solutions User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: provreg@ietf.org References: <4F073AB0.9080101@blacknight.com> <20120106185806.GA99133@crankycanuck.ca> In-Reply-To: <20120106185806.GA99133@crankycanuck.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 14:53:43 -0000 On 06/01/12 18:58, Andrew Sullivan wrote: > On Fri, Jan 06, 2012 at 06:17:20PM +0000, Keith Gaughan wrote: >> Another thing I'd change is provide a way for registries to signal to >> registrars that they've garbage collected contacts (and possibly hosts too). > > This, at least, ought to be possible using the poll queue. Myself and Gavin Brown were chatting about this before Christmas because CentralNIC have big problems with their registrars creating large numbers of contact objects and then not using them. Solving it cleanly is actually suprisingly awkward. It's really something that ideally ought to be on the contact mapping (and possibly the host mapping too). The extra message could be introduced as its own type of object (as some registries have done for low balance notifications), but that's very much a nasty and awkward way to bolt it on. Alternatively, it could be done as an extension, which is less nasty and awkward, but I've yet to come across a single instance of a message queue message introduced as an extension, and thus chances are registrars would be blindsided by poll responses with no response data, which could lead to a lot of bleating[1] from registrars about having to re-engineer how they process the message queue, even though it's something that's always been a possibility according to the RFC[2]. I'm considering writing up an I-D for this, which is one of the reasons I mentioned it. > I think > the poll queue as it stands is less than ideal, however. I made a > suggestion about how to make the poll queue better for these purposes > in a long-expired draft (draft-sullivan-epp-experience-00), but they > weren't very popular. I read that a while back, and I remember not being entirely convinced by the need myself. After all, there's nothing requiring messages on the message queue from having a particular temporal ordering, and there's certainly no requirement for message IDs to be monotonically increasing numbers. After all, there's no requirement for it to be a FIFO. Registrars who want to solve the problem could do so by using a priority queue where queue ordering is based off of the time the message was placed on the queue and a internal numerical priority assigned to it. The queue itself could then be implemented as a binary or fibonacci heap[3], or some other datastructure that might suit the registry's needs better. K. [1] Given I work for a registrar, I think it's safe for me to say things like this. [2] I've experience of this from another mailing list I'm on from one registrar who couldn't understand one is only meant to send back the subset of supported objects and extensions they support that were mentioned in the greeting when they log in. [3] The latter would seem to me to be the better all-round choice, though the cost of insertions and deletions to a binary heap could be lowered by only performing the heapify operations after a small number of pops (say three) and when there are medium- or high-priority messages to be placed on the message queue. -- Keith Gaughan, Senior 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 Mon Jan 9 08:30:56 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B5B11E8072 for ; Mon, 9 Jan 2012 08:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HaQ6zDJH90f0 for ; Mon, 9 Jan 2012 08:30:52 -0800 (PST) Received: from relay1.blacknight.com (relay1.blacknight.com [78.153.203.204]) by ietfa.amsl.com (Postfix) with ESMTP id 00DBD21F8427 for ; Mon, 9 Jan 2012 08:30:51 -0800 (PST) Received: from hegemon.blacknight.ie (hegemon.blacknight.ie [81.17.243.239]) by relay1.blacknight.com (Postfix) with ESMTP id EB75935C92D for ; Mon, 9 Jan 2012 16:30:48 +0000 (GMT) Message-ID: <4F0B1638.6090307@blacknight.com> Date: Mon, 09 Jan 2012 16:30:48 +0000 From: Keith Gaughan Organization: Blacknight Internet Solutions User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: provreg@ietf.org References: <4F049E6C.7060100@blacknight.com> <4E713373-4FFE-43E7-8625-F81AC86CF1E9@mwyoung.ca> <55C30604-0432-48E1-885E-C691448B08A9@frobbit.se> <03AFAC20-A409-42BA-92CD-48BCBC9C521D@mwyoung.ca> <20120104220058.GD32606@crankycanuck.ca> <20120105033431.GA33245@crankycanuck.ca> <4F0736EE.9050407@blacknight.com> <20120106190335.GB99133@crankycanuck.ca> In-Reply-To: <20120106190335.GB99133@crankycanuck.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 16:30:56 -0000 On 06/01/12 19:03, Andrew Sullivan wrote: > Of course some would ignore it. Many registrars do blind create > today, too, rather than performing a check. There's a special circle in hell for people who do that. >> Still, you've left out the most important reason why servers ought to be >> checking IDNs > > I had no intention of suggesting that the server side (formally, the > repository in EPP-speak) needn't check input. I personally would > prefer that gTLD registries do more validation, not less, and I think > you're a moron if you don't check your input for minimal compliance > with your own policies. Very much agreed, though I was mentioning as I felt it needed to be mentioned. What's left unsaid can easily be overlooked, after all. >> Now, there are reasonable reasons for a registrar to lie. We, for instance, >> only take a guess at the language an IDN might be for and for the likes of >> Neustar who require a language code be provided, we provide that to them. >> The domain might actually be an Irish-language one like >> rásrothairnabhaile.biz[1], but that'll fit the table for French, which means >> as far as the registry is concerned, that's a valid IDNs. > > Well, guessing will only get you so far. To be clear, we only cheat like this when checking, and we wouldn't be able to sell .biz IDNs if we didn't, because if we *did* ask what language they were searching in, that places a roadblock in the way of customers when performing availability checks, which makes them less likely to buy from us. Fewer roadblocks means more sales. That's why guessing the language when checking is actually a good thing from both the registrar and customer's point of view. > If your customer sends you a string in NFD form, what do you do? NFD isn't too bad. It's easy enough to detect, and on our end we ensure (insofar as is possible) that everything's in NFC form before checking. Combining characters aren't that difficult to detect. > What about in ISO8859-1? That's potentially a bigger problem because somebody *may* somehow manage to construct a ISO8859-1(5) encoded label that looks like valid UTF-8, but in many cases, it's easy to detect and reject due to unexpected synchronisation bits. It's not perfect, but it at least helps. K. -- Keith Gaughan, Senior 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 Mon Jan 9 08:32:33 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E93D11E808A for ; Mon, 9 Jan 2012 08:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ngki3tAcoDiZ for ; Mon, 9 Jan 2012 08:32:29 -0800 (PST) Received: from relay1.blacknight.com (relay1.blacknight.com [78.153.203.204]) by ietfa.amsl.com (Postfix) with ESMTP id 4772811E8072 for ; Mon, 9 Jan 2012 08:32:29 -0800 (PST) Received: from hegemon.blacknight.ie (hegemon.blacknight.ie [81.17.243.239]) by relay1.blacknight.com (Postfix) with ESMTP id 803CC35C4D5 for ; Mon, 9 Jan 2012 16:32:28 +0000 (GMT) Message-ID: <4F0B169B.2080803@blacknight.com> Date: Mon, 09 Jan 2012 16:32:27 +0000 From: Keith Gaughan Organization: Blacknight Internet Solutions User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: provreg@ietf.org References: <20111222002234.8359.14617.idtracker@ietfa.amsl.com> <0CB499D3-A9F7-4D3B-A7BA-6410E306BD25@frobbit.se> <20120104201038.GA32606@crankycanuck.ca> <4D64ACFF-A2AC-4C68-9346-97C118750C08@isc.org> <20120106190646.GC99133@crankycanuck.ca> In-Reply-To: <20120106190646.GC99133@crankycanuck.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] New Version Notification for draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 16:32:33 -0000 On 06/01/12 19:06, Andrew Sullivan wrote: > On Fri, Jan 06, 2012 at 09:12:56AM -0800, Francisco Obispo wrote: >> Andrew, >> >> How about if we change the tag for and its value will be the "name" of the IDN table as published/offered by the registry? >> > > There will be people annoyed by "table" because they think that's a > particular implementation. I'm indifferent. I think it's better than > language or script, though. I've just been calling it a repertiore > identifier, so what about repID? I'm fine with any of them. 'whitelist' would also be ok. -- Keith Gaughan, Senior Developer PGP/GPG key ID: 3E896381 Blacknight Internet Solutions Ltd. 12A Barrowside Business Park, Carlow, Ireland Registered in Ireland, Company No.: 370845 From brunner@nic-naa.net Mon Jan 9 08:58:33 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D65F521F849C for ; Mon, 9 Jan 2012 08:58:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1Bp2H1icfHp for ; Mon, 9 Jan 2012 08:58:33 -0800 (PST) Received: from nic-naa.net (nic-naa.net [65.99.1.132]) by ietfa.amsl.com (Postfix) with ESMTP id 1A87E21F8499 for ; Mon, 9 Jan 2012 08:58:32 -0800 (PST) Received: from limpet.local (cpe-67-255-2-48.twcny.res.rr.com [67.255.2.48]) by nic-naa.net (8.14.4/8.14.4) with ESMTP id q09EMDpx031375 for ; Mon, 9 Jan 2012 09:22:14 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-ID: <4F0B1CAF.7090706@nic-naa.net> Date: Mon, 09 Jan 2012 11:58:23 -0500 From: Eric Brunner-Williams Organization: wampumpeag User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: provreg@ietf.org References: <20111222002234.8359.14617.idtracker@ietfa.amsl.com> <0CB499D3-A9F7-4D3B-A7BA-6410E306BD25@frobbit.se> <20120104201038.GA32606@crankycanuck.ca> <4D64ACFF-A2AC-4C68-9346-97C118750C08@isc.org> <20120106190646.GC99133@crankycanuck.ca> <4F0B169B.2080803@blacknight.com> In-Reply-To: <4F0B169B.2080803@blacknight.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] New Version Notification for draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ebw@abenaki.wabanaki.net List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 16:58:33 -0000 >> There will be people annoyed by "table" because they think that's a >> particular implementation. I'm indifferent. I think it's better than >> language or script, though. I've just been calling it a repertiore >> identifier, so what about repID? > I'm fine with any of them. 'whitelist' would also be ok. I suggest that repID is almost sufficient. Again, using the LDH set, we have a rule about the H, not the initial or terminal, and not repeated. So repID + rulesetID. e.g., {a,b} = rep, repID = 0 rule0 = initial {a} rule1 = terminal {a} rule2 = no repeated code points {rule0, rule1, rule2} is a ruleset, the rulesetID = 0 Eric From keith@blacknight.com Mon Jan 9 09:44:48 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B30B21F8484 for ; Mon, 9 Jan 2012 09:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06Gq2bp1VMBG for ; Mon, 9 Jan 2012 09:44:44 -0800 (PST) Received: from relay1.blacknight.com (relay1.blacknight.com [78.153.203.204]) by ietfa.amsl.com (Postfix) with ESMTP id 77E9621F8486 for ; Mon, 9 Jan 2012 09:44:43 -0800 (PST) Received: from hegemon.blacknight.ie (hegemon.blacknight.ie [81.17.243.239]) by relay1.blacknight.com (Postfix) with ESMTP id 1773F35C6AB for ; Mon, 9 Jan 2012 17:44:41 +0000 (GMT) Message-ID: <4F0B2789.40509@blacknight.com> Date: Mon, 09 Jan 2012 17:44:41 +0000 From: Keith Gaughan Organization: Blacknight Internet Solutions User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: "provreg@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 17:44:48 -0000 On 06/01/12 21:51, Gould, James wrote: >> I mentioned that very idea on this list before Christmas. The rough >> consensus >> was that things like a registry policy ought to be provided >> independently of >> EPP. Some also expressed scepticism that it'd even be possible to >> account for >> all the possible variations on registry policy. It's something I've been >> working on during my free time, but due to my lack of free time lately, >> is not >> something I've made as much progress on as I'd like. > > A goal is to provide 90% of the feature and policy information to help > drive the client logic. The mapping certainly wouldn't be small and might > have to make external references for things like reserved names. I have > done some work on it, but I wanted to know if there is interest in it. > One of the key attributes would be the phases of the TLD (sunrise, rights, > steadyState) with start and end dates. I might be dreaming that something > useful could be created, but it might be worth a shot. I'd be happy to see what work you've done on this so far, and I'll see if there's anything I can contribute from the work I've done. *Anything* in this regard is a good thing, even if it does provide 90% of the policy information, that means less guesswork and special-purpose hackery for registrars to deal with. Pairing this up with an informational RFC on best current practice would help get us close to 100%. K. -- Keith Gaughan, Senior 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 Mon Jan 9 10:02:09 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D08D21F8777 for ; Mon, 9 Jan 2012 10:02:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.584 X-Spam-Level: X-Spam-Status: No, score=-3.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n65niWrPQAiY for ; Mon, 9 Jan 2012 10:02:04 -0800 (PST) Received: from relay1.blacknight.com (relay1.blacknight.com [78.153.203.204]) by ietfa.amsl.com (Postfix) with ESMTP id 9E99C11E8072 for ; Mon, 9 Jan 2012 10:02:04 -0800 (PST) Received: from hegemon.blacknight.ie (hegemon.blacknight.ie [81.17.243.239]) by relay1.blacknight.com (Postfix) with ESMTP id 6FC3035C204 for ; Mon, 9 Jan 2012 18:02:01 +0000 (GMT) Message-ID: <4F0B2B98.1010709@blacknight.com> Date: Mon, 09 Jan 2012 18:02:00 +0000 From: Keith Gaughan Organization: Blacknight Internet Solutions User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: provreg@ietf.org References: <4F073AB0.9080101@blacknight.com> <859F0583-3DE6-4E3B-80AF-A1D320F0348E@frobbit.se> In-Reply-To: <859F0583-3DE6-4E3B-80AF-A1D320F0348E@frobbit.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 18:02:09 -0000 On 07/01/12 09:47, Patrik Fltstrm wrote: > On 6 jan 2012, at 19:17, Keith Gaughan wrote: > >> Actually, I've no problem with creating contacts, then having the subsequent >> registration fail. > > The case that could be discussed is how to handle transfer of domain objects. > What happens with the host and contact objects? That would be good if there > was an agreement on that. That's a massive grey area. Some registries duplicate the contact objects[1], others appear to have a rule stating that contacts associated with a domain under the control of a registrar are queryable (though naturally not modifiable) even if that registrar is not the actual owner of the contact. I doubt we'll ever be able to achieve consensus on which way of doing this kind of thing is better as both have perfectly reasonable arguments that can be made for them. If my own work, I take the assumption that if a domain has been transferred to us, that we don't own the associated contacts. That's only because it allows our system to ignore the case where the contacts have been duplicated[2], though I've no strong feelings on which policy is better. This is exactly the kind of thing that would fit into the policy document James and I have been discussing here. K. [1] Obviously host objects will get duplicated. It really makes no sense *not* to duplicate them. [2] Which is also an argument for an object deletion notification mechanism. -- Keith Gaughan, Senior 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 Mon Jan 9 10:50:21 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5ED21F85EC for ; Mon, 9 Jan 2012 10:50:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.585 X-Spam-Level: X-Spam-Status: No, score=-4.585 tagged_above=-999 required=5 tests=[AWL=1.014, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0Lu-eaiEAFo for ; Mon, 9 Jan 2012 10:50:20 -0800 (PST) Received: from relay1.blacknight.com (relay1.blacknight.com [78.153.203.204]) by ietfa.amsl.com (Postfix) with ESMTP id 26E6821F8598 for ; Mon, 9 Jan 2012 10:50:20 -0800 (PST) Received: from hegemon.blacknight.ie (hegemon.blacknight.ie [81.17.243.239]) by relay1.blacknight.com (Postfix) with ESMTP id 071B335C4B9 for ; Mon, 9 Jan 2012 18:50:17 +0000 (GMT) Message-ID: <4F0B36E9.7080504@blacknight.com> Date: Mon, 09 Jan 2012 18:50:17 +0000 From: Keith Gaughan Organization: Blacknight Internet Solutions User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: provreg@ietf.org References: <20111222002234.8359.14617.idtracker@ietfa.amsl.com> <0CB499D3-A9F7-4D3B-A7BA-6410E306BD25@frobbit.se> <4EF35621.4030306@blacknight.com> <4EF364A4.7040906@blacknight.com> <4EF37B73.4070101@knipp.de> In-Reply-To: <4EF37B73.4070101@knipp.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [provreg] New Version Notification for draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 18:50:21 -0000 On 22/12/11 18:48, Klaus Malorny wrote: > I agree to you, but the language tag(s) could be helpful in the coice of > possible IDN variants. Take the letter "ö". In German, it is legal to write > "oe" instead of "ö", so "götter" and "goetter" are considered equal and thus a > registry could reserve the other variant for the registrant of the first. For > a different language (maybe Swedish?), the "ö" may exist as well, but there is > no such rule, the two words are considered different and there is no reason to > block the other. I am in no way a language expert, but I guess there is a > similar game with accents and esp. with ideographs in other languages. That's actually a good point, but how exactly they're treated very much depends on registry policy. For instance, does the registry implicitly register ASCII variants (as the .cat registry does) or treat them as totally separate entities (which is EURid's policy), and if you follow a .cat-like policy, and say (queue silly example) 'foo', 'föö' and 'fóó' are considered considered distinct words in the language but the convention is to simply omit the accents, should registering one of them block the others? That's a pretty complex question. > Regarding multiple tags: I personally think it should be legal to mix > languages and scripts under certain (narrow) conditions. > Why should a domain > like "café-mосква.ru" not be possible? ^^ ^^^ ^ Because it's open to homograph attacks, as demonstrated above. To avoid that, you'd have to specify some way of deliminating words within the label (as you did with the hyphen), but that complicates things an awful lot for very little gain, and you'd have people complaining that they can't register "cafémосква.ru", which in their eyes might be equally legitimate. [Aside: To save myself, I'm going to use the abbreviation 'CGL' to refer to Latin, Cyrillic, and Greek together.] Now, script mixing isn't necessarily bad. For instance Latin and Hangeul codepoints in an IDN is safe because there's no chance of homographs. Mixing CGL, OTOH, is dangerous because all three contain an awful lot of identical characters. The problem with the CGL scripts is that they are, in essence, variations on the very same script. Majuscule Latin characters are practically the same as the Euboean variant of the ancient Greek alphabet. Cyrillic started out as a variant on the Greek alphabet that borrowed a number of extra symbols from its predecessor, Glagolitic, to represent sounds that didn't exist in Greek but did exist in Old Church Slavonic (Old Bulgarian). This left us with a situation where three now-distinct scripts ended up with a lot of identical or at least very similar glyphs. > I don't know whether such a domain name > make sense regarding usability, but from a registry viewpoint it shouldn't > matter. A registry without any form of codepoint whitelisting wouldn't care, but if we want to avoid abuse of homographs, the choice is either to require the CGL scripts not be mixed in the one IDN or have rules for how a label should be partitioned up. Not mixing these three scripts together is, without a shadow of a doubt, the least troublesome option. > At the end the basic question is what needs the extension shall cover. As far > as I can see, the existing and future gTLDs seem to be mostly bound to the > visions of ICANN (and this is the "one language" approach), whereas existing > ccTLDs seem to be rather free in their IDN implementations. So the latter > could have the need of a different approach, but are they interested in such > an extension at all? In my experience so far, ccTLDs in countries that use one or more of the CGL scripts chose the ghostbusters option: don't cross the streams. The Serbian registry would be an example of this as they have two national scripts. They allow IDNs in one or the other, but mixing is not allowed. They do not, to my knowledge, use any extensions for determining which script is used. I'm open to correction on this though. K. -- Keith Gaughan, Senior Developer PGP/GPG key ID: 3E896381 Blacknight Internet Solutions Ltd. 12A Barrowside Business Park, Carlow, Ireland Registered in Ireland, Company No.: 370845 From ulrich@wisser.se Tue Jan 17 00:12:35 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78FF21F85EF for ; Tue, 17 Jan 2012 00:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7Xz4A0UcGbw for ; Tue, 17 Jan 2012 00:12:35 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id A333421F85AE for ; Tue, 17 Jan 2012 00:12:34 -0800 (PST) Received: by lagv3 with SMTP id v3so2400816lag.31 for ; Tue, 17 Jan 2012 00:12:33 -0800 (PST) Received: by 10.112.27.74 with SMTP id r10mr3817533lbg.20.1326787953543; Tue, 17 Jan 2012 00:12:33 -0800 (PST) Received: from laptopw-031.office.nic.se (gw.iis.se. [212.247.14.38]) by mx.google.com with ESMTPS id st7sm14916761lab.12.2012.01.17.00.12.31 (version=SSLv3 cipher=OTHER); Tue, 17 Jan 2012 00:12:32 -0800 (PST) Message-ID: <4F152D6E.1040203@wisser.se> Date: Tue, 17 Jan 2012 09:12:30 +0100 From: Ulrich Wisser User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: provreg@ietf.org References: <4F073AB0.9080101@blacknight.com> <20120106185806.GA99133@crankycanuck.ca> <4F0AFF69.2090503@blacknight.com> In-Reply-To: <4F0AFF69.2090503@blacknight.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 08:12:35 -0000 Hi, here at .Se we have done some extension to notify registrars of database changes done by the registry. Today I believe that we do not even need an extension for that. To notify the registrar of changes we could use obj:creData obj:infData obj:delete for the respective change. I realize that obj:delete is actually used as command but there is nothing in the xsd file that prevents reusing it as response. The absence of clTRID would indicate that the command was initiated by the registry. /Ulrich From ulrich@wisser.se Tue Jan 17 00:15:43 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DECD721F8624 for ; Tue, 17 Jan 2012 00:15:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2w3nrY30p0zz for ; Tue, 17 Jan 2012 00:15:41 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB2D21F8621 for ; Tue, 17 Jan 2012 00:15:39 -0800 (PST) Received: by lagv3 with SMTP id v3so2402374lag.31 for ; Tue, 17 Jan 2012 00:15:39 -0800 (PST) Received: by 10.152.146.99 with SMTP id tb3mr8367183lab.7.1326788139116; Tue, 17 Jan 2012 00:15:39 -0800 (PST) Received: from laptopw-031.office.nic.se (gw.iis.se. [212.247.14.38]) by mx.google.com with ESMTPS id nt7sm14915174lab.15.2012.01.17.00.15.37 (version=SSLv3 cipher=OTHER); Tue, 17 Jan 2012 00:15:38 -0800 (PST) Message-ID: <4F152E28.6070503@wisser.se> Date: Tue, 17 Jan 2012 09:15:36 +0100 From: Ulrich Wisser User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: provreg@ietf.org References: <4F073AB0.9080101@blacknight.com> <20120106185806.GA99133@crankycanuck.ca> <9362808D-CEF9-44CD-B4FA-542D6788B7A9@frobbit.se> In-Reply-To: <9362808D-CEF9-44CD-B4FA-542D6788B7A9@frobbit.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 08:15:43 -0000 On 07.01.12 10:49, Patrik F=E4ltstr=F6m wrote: > > On 6 jan 2012, at 19:58, Andrew Sullivan wrote: > >> On Fri, Jan 06, 2012 at 06:17:20PM +0000, Keith Gaughan wrote: >>> Another thing I'd change is provide a way for registries to signal to= >>> registrars that they've garbage collected contacts (and possibly host= s too). >> >> This, at least, ought to be possible using the poll queue. I think >> the poll queue as it stands is less than ideal, however. I made a >> suggestion about how to make the poll queue better for these purposes >> in a long-expired draft (draft-sullivan-epp-experience-00), but they >> weren't very popular. > > I rather see the registrar do "garbage_collect()" and the registry resp= ond > with a list of objects that was deleted. That would limit the amount of time > the view of the world on the registry and registrar side is different. > The answer could be really large and would probably take so much time=20 that the registry would have to answer "pending". So you get the reply=20 through the poll queue anyway. Besides that, it would make the registry=20 dependent on the call from the registrars. What is the incentive for the = registrar to clean the registry database? /Ulrich From theo@flame.co.za Tue Jan 17 00:48:42 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9360221F8634 for ; Tue, 17 Jan 2012 00:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FARhLZq1SqHn for ; Tue, 17 Jan 2012 00:48:41 -0800 (PST) Received: from flame.co.za (ndeventer.co.za [160.124.170.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E3021F85E5 for ; Tue, 17 Jan 2012 00:48:41 -0800 (PST) Received: from theo-kramers-macbook-pro.int.coza.net.za (41-135-50-225.dsl.mweb.co.za [41.135.50.225]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by flame.co.za (Postfix) with ESMTPSA id 6604B80050 for ; Tue, 17 Jan 2012 10:48:36 +0200 (SAST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Theo Kramer In-Reply-To: <4F152E28.6070503@wisser.se> Date: Tue, 17 Jan 2012 10:48:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F073AB0.9080101@blacknight.com> <20120106185806.GA99133@crankycanuck.ca> <9362808D-CEF9-44CD-B4FA-542D6788B7A9@frobbit.se> <4F152E28.6070503@wisser.se> To: provreg@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 08:48:42 -0000 On 17 Jan 2012, at 10:15 AM, Ulrich Wisser wrote: > The answer could be really large and would probably take so much time = that the registry would have to answer "pending". So you get the reply = through the poll queue anyway. Besides that, it would make the registry = dependent on the call from the registrars. What is the incentive for the = registrar to clean the registry database? I can see none. Garbage collection is a function of registry maintenance = imo. --=20 Regards Theo From JGould@verisign.com Tue Jan 17 06:02:14 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D596B21F85EC for ; Tue, 17 Jan 2012 06:02:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.939 X-Spam-Level: X-Spam-Status: No, score=-5.939 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tc6I72yAip94 for ; Tue, 17 Jan 2012 06:02:13 -0800 (PST) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by ietfa.amsl.com (Postfix) with ESMTP id B3C3921F85E6 for ; Tue, 17 Jan 2012 06:02:11 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKTxV/V+E6rVSK6pjQ5mBjDWha97/jb7Do@postini.com; Tue, 17 Jan 2012 06:02:12 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q0HE1wgo028097; Tue, 17 Jan 2012 09:01:58 -0500 Received: from dul1wnexcn04.vcorp.ad.vrsn.com ([10.170.12.139]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Jan 2012 09:01:58 -0500 Received: from BRN1WNEXCAS01.vcorp.ad.vrsn.com ([10.173.152.205]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Jan 2012 09:01:57 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.01.0323.003; Tue, 17 Jan 2012 09:01:56 -0500 From: "Gould, James" To: Ulrich Wisser , "provreg@ietf.org" Thread-Topic: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt Thread-Index: AQHMzKUyDjcivKJtLkGRYG23jmA2o5YEd2yAgAwingCAAA2/AA== Date: Tue, 17 Jan 2012 14:01:55 +0000 Message-ID: In-Reply-To: <4F152D6E.1040203@wisser.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2FEA7F64BDFEDB4EB5300A596CA0236D@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 17 Jan 2012 14:01:57.0313 (UTC) FILETIME=[9341BB10:01CCD520] Subject: Re: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 14:02:14 -0000 Ulrich, Can you provide a reference to the extension created by .SE for registry changes for review? Using a command (obj:delete) in response to a command (poll) would not meet RFC 5730. Use of obj:creData I don't believe would match the context. Use of obj:infData could work since it's the most generic to cover any changes, but it wouldn't provide any specific information on a garbage collection delete except for maybe text in the element (e.g. "deleted - orphaned" or something like that). This is not clean but it wouldn=B9t require any new extensions or mappings. =20 -- =20 JG =20 =20 James Gould Principal Software Engineer jgould@Verisign.com =20 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On 1/17/12 3:12 AM, "Ulrich Wisser" wrote: >Hi, > >here at .Se we have done some extension to notify registrars of database >changes done by the registry. Today I believe that we do not even need >an extension for that. > >To notify the registrar of changes we could use > obj:creData > obj:infData > obj:delete >for the respective change. I realize that obj:delete is actually used as >command but there is nothing in the xsd file that prevents reusing it as >response. The absence of clTRID would indicate that the command was >initiated by the registry. > >/Ulrich > >_______________________________________________ >provreg mailing list >provreg@ietf.org >https://www.ietf.org/mailman/listinfo/provreg From brunner@nic-naa.net Tue Jan 17 06:37:39 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6526921F86D6 for ; Tue, 17 Jan 2012 06:37:39 -0800 (PST) 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=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcgSzmrDRuL0 for ; Tue, 17 Jan 2012 06:37:38 -0800 (PST) Received: from nic-naa.net (nic-naa.net [65.99.1.132]) by ietfa.amsl.com (Postfix) with ESMTP id 0641E21F85C4 for ; Tue, 17 Jan 2012 06:37:36 -0800 (PST) Received: from limpet.local (cpe-67-255-2-48.twcny.res.rr.com [67.255.2.48]) by nic-naa.net (8.14.4/8.14.4) with ESMTP id q0HBxPuS051619 for ; Tue, 17 Jan 2012 06:59:25 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-ID: <4F1587AA.4080105@nic-naa.net> Date: Tue, 17 Jan 2012 09:37:30 -0500 From: Eric Brunner-Williams Organization: wampumpeag User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: provreg@ietf.org References: <4F073AB0.9080101@blacknight.com> <20120106185806.GA99133@crankycanuck.ca> <4F0AFF69.2090503@blacknight.com> <4F152D6E.1040203@wisser.se> In-Reply-To: <4F152D6E.1040203@wisser.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ebw@abenaki.wabanaki.net List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 14:37:39 -0000 On 1/17/12 3:12 AM, Ulrich Wisser wrote: > here at .Se we have done some extension to notify registrars of > database changes done by the registry. I proposed a push mechanism to notify clients, it was not adopted, so the event model is one-sided, having only poll. > ... Today I believe that we do not > even need an extension for that. > > To notify the registrar of changes we could use > obj:creData > obj:infData > obj:delete > for the respective change. I realize that obj:delete is actually used > as command but there is nothing in the xsd file that prevents reusing > it as response. The absence of clTRID would indicate that the command > was initiated by the registry. Overloading. Cute, but if one were to change EPP some restrictions that were reasonable in a universe of a half-dozen registries and about an order of magnitude larger registrars may be worth reconsideration. Eric From patrik@frobbit.se Tue Jan 17 08:20:00 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B1C21F86CE for ; Tue, 17 Jan 2012 08:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.703 X-Spam-Level: X-Spam-Status: No, score=-99.703 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rg+8G708PPJ2 for ; Tue, 17 Jan 2012 08:20:00 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 2466B21F86C4 for ; Tue, 17 Jan 2012 08:20:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 726AE12D599B6; Tue, 17 Jan 2012 17:19:58 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+8wBkZUsFeO; Tue, 17 Jan 2012 17:19:58 +0100 (CET) Received: from [83.243.189.40] (unknown [213.184.192.106]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 20C7C12D599AD; Tue, 17 Jan 2012 17:19:58 +0100 (CET) References: <4F073AB0.9080101@blacknight.com> <20120106185806.GA99133@crankycanuck.ca> <4F0AFF69.2090503@blacknight.com> <4F152D6E.1040203@wisser.se> In-Reply-To: <4F152D6E.1040203@wisser.se> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <7297BA4A-C7C9-42DF-9D54-B5F4B50FE7CD@frobbit.se> X-Mailer: iPhone Mail (9A405) From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= Date: Tue, 17 Jan 2012 17:19:22 +0100 To: Ulrich Wisser Cc: "provreg@ietf.org" Subject: Re: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 16:20:00 -0000 On 17 jan 2012, at 09:12, Ulrich Wisser wrote: > Hi, >=20 > here at .Se we have done some extension to notify registrars of database c= hanges done by the registry. This is a question of definitions. The changes are made in the registry due t= o operations requested by another registrar. I can not remind myself of any o= peration originating in the registry. Ulrich do remind me if I am wrong. Patrik > Today I believe that we do not even need an extension for that. >=20 > To notify the registrar of changes we could use > obj:creData > obj:infData > obj:delete > for the respective change. I realize that obj:delete is actually used as c= ommand but there is nothing in the xsd file that prevents reusing it as resp= onse. The absence of clTRID would indicate that the command was initiated by= the registry. >=20 > /Ulrich >=20 > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg >=20 From patrik@frobbit.se Tue Jan 17 08:27:27 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6F021F855B for ; Tue, 17 Jan 2012 08:27:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.303 X-Spam-Level: X-Spam-Status: No, score=-100.303 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rfDX-oWeSnq for ; Tue, 17 Jan 2012 08:27:27 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id BD77D21F84D3 for ; Tue, 17 Jan 2012 08:27:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 40D5612D59BFB; Tue, 17 Jan 2012 17:27:25 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UyNSxqsgOmO0; Tue, 17 Jan 2012 17:27:25 +0100 (CET) Received: from [83.243.189.40] (unknown [213.184.192.106]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 0D45C12D59BF7; Tue, 17 Jan 2012 17:27:25 +0100 (CET) References: <4F073AB0.9080101@blacknight.com> <20120106185806.GA99133@crankycanuck.ca> <9362808D-CEF9-44CD-B4FA-542D6788B7A9@frobbit.se> <4F152E28.6070503@wisser.se> In-Reply-To: <4F152E28.6070503@wisser.se> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9A405) From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= Date: Tue, 17 Jan 2012 17:26:48 +0100 To: Ulrich Wisser Cc: "provreg@ietf.org" Subject: Re: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 16:27:27 -0000 On 17 jan 2012, at 09:15, Ulrich Wisser wrote: > What is the incentive for the registrar to clean the registry database? Same as all contractual requirements registries have on their registrars. You can only minimize number of contact records by having a different design= of your system so that it is easier for registrars and registry to be in sy= nc. We do btw have a local discussion in Sweden on how to work this out. Patrik From patrik@frobbit.se Tue Jan 17 08:30:28 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF06921F862F for ; Tue, 17 Jan 2012 08:30:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.603 X-Spam-Level: X-Spam-Status: No, score=-100.603 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZZvJB8avCtJ for ; Tue, 17 Jan 2012 08:30:28 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 0981521F861F for ; Tue, 17 Jan 2012 08:30:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 63BB012D59CD0; Tue, 17 Jan 2012 17:30:27 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzl2kSmk6xjy; Tue, 17 Jan 2012 17:30:27 +0100 (CET) Received: from [83.243.189.40] (unknown [213.184.192.106]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id EACAB12D59CC9; Tue, 17 Jan 2012 17:30:26 +0100 (CET) References: <4F073AB0.9080101@blacknight.com> <20120106185806.GA99133@crankycanuck.ca> <9362808D-CEF9-44CD-B4FA-542D6788B7A9@frobbit.se> <4F152E28.6070503@wisser.se> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <444E3664-43C2-457B-BFD6-49E1B66CA14F@frobbit.se> X-Mailer: iPhone Mail (9A405) From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= Date: Tue, 17 Jan 2012 17:29:51 +0100 To: Theo Kramer Cc: "provreg@ietf.org" Subject: Re: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 16:30:28 -0000 On 17 jan 2012, at 09:48, Theo Kramer wrote: > I can see none. Garbage collection is a function of registry maintenance i= mo. A registry can not know if an existing contact record is to be connected to a= domain name that is to be created, as by definition contact records must ex= ist with the registry that is not connected to any domain object. Patrik= From michele@blacknight.ie Tue Jan 17 08:41:51 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B834221F85BD for ; Tue, 17 Jan 2012 08:41:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=-1.080, BAYES_20=-0.74, J_CHICKENPOX_46=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsJAyliU1aqq for ; Tue, 17 Jan 2012 08:41:50 -0800 (PST) Received: from exchange.blacknight.ie (exchange.blacknight.ie [81.17.243.252]) by ietfa.amsl.com (Postfix) with ESMTP id 46DE421F85B6 for ; Tue, 17 Jan 2012 08:41:49 -0800 (PST) Received: from BKEXCHMBX01.blacknight.local ([fe80::76:af74:8c72:96ac]) by bkexchhubcas01.blacknight.local ([fe80::3ca9:6bf1:bd5d:24b%15]) with mapi id 14.02.0247.003; Tue, 17 Jan 2012 16:41:48 +0000 From: "Michele Neylon :: Blacknight" To: =?utf-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= Thread-Topic: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt Thread-Index: AQHM1PTeYhTVBbXL6UmhygsAh2jBXJYQwI+AgAADUgA= Date: Tue, 17 Jan 2012 16:41:47 +0000 Message-ID: <1D76D22D-1B30-4A95-B0A7-6FCDE51EC66F@blacknight.ie> References: <4F073AB0.9080101@blacknight.com> <20120106185806.GA99133@crankycanuck.ca> <9362808D-CEF9-44CD-B4FA-542D6788B7A9@frobbit.se> <4F152E28.6070503@wisser.se> <444E3664-43C2-457B-BFD6-49E1B66CA14F@frobbit.se> In-Reply-To: <444E3664-43C2-457B-BFD6-49E1B66CA14F@frobbit.se> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [81.17.243.251] Content-Type: text/plain; charset="utf-8" Content-ID: <7864909918442D40A09E8046D5A75239@blacknight.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "provreg@ietf.org" Subject: Re: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 16:41:51 -0000 UmVnaXN0cnkgb3BlcmF0b3JzIGhhdmUgZ290IHRvIGdldCBvdXQgb2YgdGhlaXIgdmFjdXVtIG1l bnRhbGl0eQ0KDQoNCk9uIDE3IEphbiAyMDEyLCBhdCAxNjoyOSwgUGF0cmlrIEbDpGx0c3Ryw7Zt IHdyb3RlOg0KDQo+IE9uIDE3IGphbiAyMDEyLCBhdCAwOTo0OCwgVGhlbyBLcmFtZXIgPHRoZW9A ZmxhbWUuY28uemE+IHdyb3RlOg0KPiANCj4+IEkgY2FuIHNlZSBub25lLiBHYXJiYWdlIGNvbGxl Y3Rpb24gaXMgYSBmdW5jdGlvbiBvZiByZWdpc3RyeSBtYWludGVuYW5jZSBpbW8uDQo+IA0KPiBB IHJlZ2lzdHJ5IGNhbiBub3Qga25vdyBpZiBhbiBleGlzdGluZyBjb250YWN0IHJlY29yZCBpcyB0 byBiZSBjb25uZWN0ZWQgdG8gYSBkb21haW4gbmFtZSB0aGF0IGlzIHRvIGJlIGNyZWF0ZWQsIGFz IGJ5IGRlZmluaXRpb24gY29udGFjdCByZWNvcmRzIG11c3QgZXhpc3Qgd2l0aCB0aGUgcmVnaXN0 cnkgdGhhdCBpcyBub3QgY29ubmVjdGVkIHRvIGFueSBkb21haW4gb2JqZWN0Lg0KPiANCj4gICBQ YXRyaWsNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gcHJvdnJlZyBtYWlsaW5nIGxpc3QNCj4gcHJvdnJlZ0BpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Byb3ZyZWcNCg0KTXIgTWljaGVsZSBOZXlsb24N CkJsYWNrbmlnaHQgU29sdXRpb25zIOKZng0KSG9zdGluZyAmIENvbG9jYXRpb24sIEJyYW5kIFBy b3RlY3Rpb24NCklDQU5OIEFjY3JlZGl0ZWQgUmVnaXN0cmFyDQpodHRwOi8vd3d3LmJsYWNrbmln aHQuY29tLw0KaHR0cDovL2Jsb2cuYmxhY2tuaWdodC5jb20vDQpodHRwOi8vYmxhY2tuaWdodC5i aXoNCmh0dHA6Ly9tbmV5bG9uLnRlbA0KSW50bC4gKzM1MyAoMCkgNTkgIDkxODMwNzINClVTOiAy MTMtMjMzLTE2MTIgDQpVSzogMDg0NCA0ODQgOTM2MQ0KTG9jYWxsOiAxODUwIDkyOSA5MjkNCkRp cmVjdCBEaWFsOiArMzUzICgwKTU5IDkxODMwOTANCkZhY2Vib29rOiBodHRwOi8vZmIubWUvYmxh Y2tuaWdodA0KVHdpdHRlcjogaHR0cDovL3R3aXR0ZXIuY29tL21uZXlsb24NCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCkJsYWNrbmlnaHQgSW50ZXJuZXQgU29sdXRpb25zIEx0ZCwg VW5pdCAxMkEsQmFycm93c2lkZSBCdXNpbmVzcyBQYXJrLFNsZWF0eQ0KUm9hZCxHcmFpZ3VlY3Vs bGVuLENhcmxvdyxJcmVsYW5kICBDb21wYW55IE5vLjogMzcwODQ1DQoNCg== From patrik@frobbit.se Tue Jan 17 08:51:26 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D7C21F84DA for ; Tue, 17 Jan 2012 08:51:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.603 X-Spam-Level: X-Spam-Status: No, score=-100.603 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SM-7omuNq5iy for ; Tue, 17 Jan 2012 08:51:24 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 2C43621F84DE for ; Tue, 17 Jan 2012 08:51:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id A16C312D5A32F; Tue, 17 Jan 2012 17:51:11 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yDy2nuAQ3we; Tue, 17 Jan 2012 17:51:10 +0100 (CET) Received: from [10.177.67.223] (host-95-199-131-223.mobileonline.telia.com [95.199.131.223]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 6753012D5A328; Tue, 17 Jan 2012 17:51:10 +0100 (CET) References: <4F073AB0.9080101@blacknight.com> <20120106185806.GA99133@crankycanuck.ca> <9362808D-CEF9-44CD-B4FA-542D6788B7A9@frobbit.se> <4F152E28.6070503@wisser.se> <444E3664-43C2-457B-BFD6-49E1B66CA14F@frobbit.se> <1D76D22D-1B30-4A95-B0A7-6FCDE51EC66F@blacknight.ie> In-Reply-To: <1D76D22D-1B30-4A95-B0A7-6FCDE51EC66F@blacknight.ie> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: X-Mailer: iPhone Mail (9A405) From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= Date: Tue, 17 Jan 2012 17:50:31 +0100 To: "Michele Neylon :: Blacknight" Cc: "provreg@ietf.org" Subject: Re: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 16:51:26 -0000 Something like that ;-) Patrik On 17 jan 2012, at 17:41, "Michele Neylon :: Blacknight" wrote: > Registry operators have got to get out of their vacuum mentality >=20 >=20 > On 17 Jan 2012, at 16:29, Patrik F=C3=A4ltstr=C3=B6m wrote: >=20 >> On 17 jan 2012, at 09:48, Theo Kramer wrote: >>=20 >>> I can see none. Garbage collection is a function of registry maintenance= imo. >>=20 >> A registry can not know if an existing contact record is to be connected t= o a domain name that is to be created, as by definition contact records must= exist with the registry that is not connected to any domain object. >>=20 >> Patrik >> _______________________________________________ >> provreg mailing list >> provreg@ietf.org >> https://www.ietf.org/mailman/listinfo/provreg >=20 > Mr Michele Neylon > Blacknight Solutions =E2=99=9E > Hosting & Colocation, Brand Protection > ICANN Accredited Registrar > http://www.blacknight.com/ > http://blog.blacknight.com/ > http://blacknight.biz > http://mneylon.tel > Intl. +353 (0) 59 9183072 > US: 213-233-1612=20 > UK: 0844 484 9361 > Locall: 1850 929 929 > Direct Dial: +353 (0)59 9183090 > Facebook: http://fb.me/blacknight > Twitter: http://twitter.com/mneylon > ------------------------------- > Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleat= y > Road,Graiguecullen,Carlow,Ireland Company No.: 370845 >=20 From michael@mwyoung.ca Tue Jan 17 08:58:50 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C3321F8703 for ; Tue, 17 Jan 2012 08:58:50 -0800 (PST) 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=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NW-LXT41HP+G for ; Tue, 17 Jan 2012 08:58:49 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 93E8021F8700 for ; Tue, 17 Jan 2012 08:58:49 -0800 (PST) Received: by ggnr5 with SMTP id r5so3848613ggn.31 for ; Tue, 17 Jan 2012 08:58:49 -0800 (PST) Received: by 10.50.51.199 with SMTP id m7mr15649374igo.23.1326819528952; Tue, 17 Jan 2012 08:58:48 -0800 (PST) Received: from [192.168.0.43] (174-155-52-17.pools.spcsdns.net. [174.155.52.17]) by mx.google.com with ESMTPS id g7sm31718550igv.7.2012.01.17.08.58.45 (version=SSLv3 cipher=OTHER); Tue, 17 Jan 2012 08:58:47 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Tue, 17 Jan 2012 10:58:42 -0600 From: MICHAEL YOUNG To: "Michele Neylon :: Blacknight" , Patrik =?ISO-8859-1?B?RuRsdHN0cvZt?= Message-ID: Thread-Topic: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt In-Reply-To: <1D76D22D-1B30-4A95-B0A7-6FCDE51EC66F@blacknight.ie> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Cc: "provreg@ietf.org" Subject: Re: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 16:58:50 -0000 I think there needs to be a reasonable period where you can determine a contact object has been abandoned. Is there really a point to leaving contacts around that haven't been associated for years? That's certainly the case in the older EPP registries - contact bloat. Where this gets to be annoying is in escrow deposits - costs money for no added value to anyone. Why bloat up escrow deposits with a bunch of dead contacts in the first place? Just sayin,=E2=80=A6=E2=80=A6.. Michael On 12-01-17 10:41 AM, "Michele Neylon :: Blacknight" wrote: >Registry operators have got to get out of their vacuum mentality > > >On 17 Jan 2012, at 16:29, Patrik F=C3=A4ltstr=C3=B6m wrote: > >> On 17 jan 2012, at 09:48, Theo Kramer wrote: >>=20 >>> I can see none. Garbage collection is a function of registry >>>maintenance imo. >>=20 >> A registry can not know if an existing contact record is to be >>connected to a domain name that is to be created, as by definition >>contact records must exist with the registry that is not connected to >>any domain object. >>=20 >> Patrik >> _______________________________________________ >> provreg mailing list >> provreg@ietf.org >> https://www.ietf.org/mailman/listinfo/provreg > >Mr Michele Neylon >Blacknight Solutions =E2=99=9E >Hosting & Colocation, Brand Protection >ICANN Accredited Registrar >http://www.blacknight.com/ >http://blog.blacknight.com/ >http://blacknight.biz >http://mneylon.tel >Intl. +353 (0) 59 9183072 >US: 213-233-1612=20 >UK: 0844 484 9361 >Locall: 1850 929 929 >Direct Dial: +353 (0)59 9183090 >Facebook: http://fb.me/blacknight >Twitter: http://twitter.com/mneylon >------------------------------- >Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business >Park,Sleaty >Road,Graiguecullen,Carlow,Ireland Company No.: 370845 > >_______________________________________________ >provreg mailing list >provreg@ietf.org >https://www.ietf.org/mailman/listinfo/provreg From michele@blacknight.ie Tue Jan 17 09:04:24 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE7321F8711 for ; Tue, 17 Jan 2012 09:04:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.309 X-Spam-Level: X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ianbrg3YWE48 for ; Tue, 17 Jan 2012 09:04:23 -0800 (PST) Received: from exchange.blacknight.ie (exchange.blacknight.ie [81.17.243.252]) by ietfa.amsl.com (Postfix) with ESMTP id 5278B21F8710 for ; Tue, 17 Jan 2012 09:04:23 -0800 (PST) Received: from BKEXCHMBX01.blacknight.local ([fe80::76:af74:8c72:96ac]) by bkexchhubcas01.blacknight.local ([fe80::3ca9:6bf1:bd5d:24b%15]) with mapi id 14.02.0247.003; Tue, 17 Jan 2012 17:04:22 +0000 From: "Michele Neylon :: Blacknight" To: =?utf-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= Thread-Topic: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt Thread-Index: AQHM1PTeYhTVBbXL6UmhygsAh2jBXJYQwI+AgAADUgCAAAJ0gIAAA9cA Date: Tue, 17 Jan 2012 17:04:21 +0000 Message-ID: <564EC235-F6E7-4506-BF56-00E19C700876@blacknight.ie> References: <4F073AB0.9080101@blacknight.com> <20120106185806.GA99133@crankycanuck.ca> <9362808D-CEF9-44CD-B4FA-542D6788B7A9@frobbit.se> <4F152E28.6070503@wisser.se> <444E3664-43C2-457B-BFD6-49E1B66CA14F@frobbit.se> <1D76D22D-1B30-4A95-B0A7-6FCDE51EC66F@blacknight.ie> In-Reply-To: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [81.17.243.251] Content-Type: text/plain; charset="utf-8" Content-ID: <3B3D9BFA8F4AB54FAB111956FF31B00A@blacknight.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "provreg@ietf.org" Subject: Re: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 17:04:24 -0000 WWVzIHdlbGwgSSByYXJlbHkgd2luIHByaXplcyBmb3IgYmVpbmcgb3Zlcmx5IGRpcGxvbWF0aWMg OikNCg0KUmVnaXN0cmllcyBuZWVkIHRvIHdvcmsgV0lUSCByZWdpc3RyYXJzDQoNClRoZXJlJ3Mg YW4gYXR0aXR1ZGUgd2l0aCBzb21lIG9mIHRoZW0gdGhhdCByZWdpc3RyYXJzIGFyZSBqdXN0IGFu IGlycml0YXRpb24NClRoZXkgYWxzbyBmb3JnZXQgdGhhdCB0aGV5IGFyZW4ndCB0aGUgb25seSBy ZWdpc3RyeSB0aGF0IGEgcmVnaXN0cmFyIGhhcyB0byBpbnRlcmFjdCB3aXRoDQoNCkVuZCByZXN1 bHQ/IE9ubHkgdGhlIHZlcnkgYmlnIHJlZ2lzdHJpZXMgbWFuYWdlIHRvIGdldCByZWdpc3RyYXJz IG9uYm9hcmQgcXVpY2tseQ0KDQoNCk9uIDE3IEphbiAyMDEyLCBhdCAxNjo1MCwgUGF0cmlrIEbD pGx0c3Ryw7ZtIHdyb3RlOg0KDQo+IFNvbWV0aGluZyBsaWtlIHRoYXQgOy0pDQo+IA0KPiAgIFBh dHJpaw0KPiANCj4gT24gMTcgamFuIDIwMTIsIGF0IDE3OjQxLCAiTWljaGVsZSBOZXlsb24gOjog QmxhY2tuaWdodCIgPG1pY2hlbGVAYmxhY2tuaWdodC5pZT4gd3JvdGU6DQo+IA0KPj4gUmVnaXN0 cnkgb3BlcmF0b3JzIGhhdmUgZ290IHRvIGdldCBvdXQgb2YgdGhlaXIgdmFjdXVtIG1lbnRhbGl0 eQ0KPj4gDQo+PiANCj4+IE9uIDE3IEphbiAyMDEyLCBhdCAxNjoyOSwgUGF0cmlrIEbDpGx0c3Ry w7ZtIHdyb3RlOg0KPj4gDQo+Pj4gT24gMTcgamFuIDIwMTIsIGF0IDA5OjQ4LCBUaGVvIEtyYW1l ciA8dGhlb0BmbGFtZS5jby56YT4gd3JvdGU6DQo+Pj4gDQo+Pj4+IEkgY2FuIHNlZSBub25lLiBH YXJiYWdlIGNvbGxlY3Rpb24gaXMgYSBmdW5jdGlvbiBvZiByZWdpc3RyeSBtYWludGVuYW5jZSBp bW8uDQo+Pj4gDQo+Pj4gQSByZWdpc3RyeSBjYW4gbm90IGtub3cgaWYgYW4gZXhpc3RpbmcgY29u dGFjdCByZWNvcmQgaXMgdG8gYmUgY29ubmVjdGVkIHRvIGEgZG9tYWluIG5hbWUgdGhhdCBpcyB0 byBiZSBjcmVhdGVkLCBhcyBieSBkZWZpbml0aW9uIGNvbnRhY3QgcmVjb3JkcyBtdXN0IGV4aXN0 IHdpdGggdGhlIHJlZ2lzdHJ5IHRoYXQgaXMgbm90IGNvbm5lY3RlZCB0byBhbnkgZG9tYWluIG9i amVjdC4NCj4+PiANCj4+PiBQYXRyaWsNCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4+IHByb3ZyZWcgbWFpbGluZyBsaXN0DQo+Pj4gcHJvdnJl Z0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcHJv dnJlZw0KPj4gDQo+PiBNciBNaWNoZWxlIE5leWxvbg0KPj4gQmxhY2tuaWdodCBTb2x1dGlvbnMg 4pmeDQo+PiBIb3N0aW5nICYgQ29sb2NhdGlvbiwgQnJhbmQgUHJvdGVjdGlvbg0KPj4gSUNBTk4g QWNjcmVkaXRlZCBSZWdpc3RyYXINCj4+IGh0dHA6Ly93d3cuYmxhY2tuaWdodC5jb20vDQo+PiBo dHRwOi8vYmxvZy5ibGFja25pZ2h0LmNvbS8NCj4+IGh0dHA6Ly9ibGFja25pZ2h0LmJpeg0KPj4g aHR0cDovL21uZXlsb24udGVsDQo+PiBJbnRsLiArMzUzICgwKSA1OSAgOTE4MzA3Mg0KPj4gVVM6 IDIxMy0yMzMtMTYxMiANCj4+IFVLOiAwODQ0IDQ4NCA5MzYxDQo+PiBMb2NhbGw6IDE4NTAgOTI5 IDkyOQ0KPj4gRGlyZWN0IERpYWw6ICszNTMgKDApNTkgOTE4MzA5MA0KPj4gRmFjZWJvb2s6IGh0 dHA6Ly9mYi5tZS9ibGFja25pZ2h0DQo+PiBUd2l0dGVyOiBodHRwOi8vdHdpdHRlci5jb20vbW5l eWxvbg0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gQmxhY2tuaWdodCBJ bnRlcm5ldCBTb2x1dGlvbnMgTHRkLCBVbml0IDEyQSxCYXJyb3dzaWRlIEJ1c2luZXNzIFBhcmss U2xlYXR5DQo+PiBSb2FkLEdyYWlndWVjdWxsZW4sQ2FybG93LElyZWxhbmQgIENvbXBhbnkgTm8u OiAzNzA4NDUNCj4+IA0KDQpNciBNaWNoZWxlIE5leWxvbg0KQmxhY2tuaWdodCBTb2x1dGlvbnMg 4pmeDQpIb3N0aW5nICYgQ29sb2NhdGlvbiwgQnJhbmQgUHJvdGVjdGlvbg0KSUNBTk4gQWNjcmVk aXRlZCBSZWdpc3RyYXINCmh0dHA6Ly93d3cuYmxhY2tuaWdodC5jb20vDQpodHRwOi8vYmxvZy5i bGFja25pZ2h0LmNvbS8NCmh0dHA6Ly9ibGFja25pZ2h0LmJpeg0KaHR0cDovL21uZXlsb24udGVs DQpJbnRsLiArMzUzICgwKSA1OSAgOTE4MzA3Mg0KVVM6IDIxMy0yMzMtMTYxMiANClVLOiAwODQ0 IDQ4NCA5MzYxDQpMb2NhbGw6IDE4NTAgOTI5IDkyOQ0KRGlyZWN0IERpYWw6ICszNTMgKDApNTkg OTE4MzA5MA0KRmFjZWJvb2s6IGh0dHA6Ly9mYi5tZS9ibGFja25pZ2h0DQpUd2l0dGVyOiBodHRw Oi8vdHdpdHRlci5jb20vbW5leWxvbg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K QmxhY2tuaWdodCBJbnRlcm5ldCBTb2x1dGlvbnMgTHRkLCBVbml0IDEyQSxCYXJyb3dzaWRlIEJ1 c2luZXNzIFBhcmssU2xlYXR5DQpSb2FkLEdyYWlndWVjdWxsZW4sQ2FybG93LElyZWxhbmQgIENv bXBhbnkgTm8uOiAzNzA4NDUNCg0K From michele@blacknight.ie Tue Jan 17 09:28:08 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCA5511E8072 for ; Tue, 17 Jan 2012 09:28:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnM7kk4xQveu for ; Tue, 17 Jan 2012 09:28:08 -0800 (PST) Received: from exchange.blacknight.ie (exchange.blacknight.ie [81.17.243.252]) by ietfa.amsl.com (Postfix) with ESMTP id AFF6111E8075 for ; Tue, 17 Jan 2012 09:28:07 -0800 (PST) Received: from BKEXCHMBX01.blacknight.local ([fe80::76:af74:8c72:96ac]) by bkexchhubcas01.blacknight.local ([fe80::3ca9:6bf1:bd5d:24b%15]) with mapi id 14.02.0247.003; Tue, 17 Jan 2012 17:28:05 +0000 From: "Michele Neylon :: Blacknight" To: MICHAEL YOUNG Thread-Topic: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt Thread-Index: AQHM1TlSez1C0yl1TEiJ4Hk2wA5MbJYQ0EoA Date: Tue, 17 Jan 2012 17:28:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [81.17.243.251] Content-Type: text/plain; charset="utf-8" Content-ID: <535266AA543FDC4F8B1574E8C3E01D0A@blacknight.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "provreg@ietf.org" Subject: Re: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 17:28:09 -0000 TWljaGFlbA0KDQpJIGRvbid0IGRpc2FncmVlDQoNCkkgdGhpbmsgSSBoYWQgdGhpcyBjb252ZXJz YXRpb24gd2l0aCBzb21lYm9keSwgYnV0IGNhbid0IHJlbWVtYmVyIGlmIGl0IHdhcyBvbiB0aGlz IGxpc3QsIGluIGRpcmVjdCBlbWFpbCBvciBhdCBhIENFTlRSIG1lZXRpbmcNCg0KVGhlIGtleSB0 aGluZyBpcyB0aGF0IHdoYXRldmVyIHdheSBhIHJlZ2lzdHJ5IGhhbmRsZXMgaXQgdGhhdCB0aGV5 IG1ha2UgaXQgY2xlYXIgdG8gcmVnaXN0cmFycyBob3cgdGhleSdyZSBtYWtpbmcgdGhhdCBkZWNp c2lvbiBhbmQgd2hlbiB0aGV5J3JlIGltcGxlbWVudGluZyBpdA0KDQpGb3IgZXhhbXBsZSwgc29t ZSByZWdpc3RyaWVzIGNhdXNlIHBhcnQgb2YgdGhlIGNvbnRhY3QgYmxvYXQgYnkgc2VuZGluZyB0 aGUgY29udGFjdCB3aXRoIGEgZG9tYWluIG9uIHRyYW5zZmVyLCBidXQgdGhlbiBub3QgbGV0dGlu ZyB0aGUgbmV3IHJlZ2lzdHJhciBkbyBhbnl0aGluZyB3aXRob3V0IGZpcnN0IHJlLWNyZWF0aW5n IHRoZSBjb250YWN0IDopDQoNCihBZG1pdHRlZGx5IHRoZSBvbmUgdGhhdCBzcHJpbmdzIHRvIG1p bmQgaXNuJ3QgdXNpbmcgRVBQIC4uICkNCg0KTQ0KDQpPbiAxNyBKYW4gMjAxMiwgYXQgMTY6NTgs IE1JQ0hBRUwgWU9VTkcgd3JvdGU6DQoNCj4gSSB0aGluayB0aGVyZSBuZWVkcyB0byBiZSBhIHJl YXNvbmFibGUgcGVyaW9kIHdoZXJlIHlvdSBjYW4gZGV0ZXJtaW5lIGENCj4gY29udGFjdCBvYmpl Y3QgaGFzIGJlZW4gYWJhbmRvbmVkLiAgSXMgdGhlcmUgcmVhbGx5IGEgcG9pbnQgdG8gbGVhdmlu Zw0KPiBjb250YWN0cyBhcm91bmQgdGhhdCBoYXZlbid0IGJlZW4gYXNzb2NpYXRlZCBmb3IgeWVh cnM/DQo+IA0KPiBUaGF0J3MgY2VydGFpbmx5IHRoZSBjYXNlIGluIHRoZSBvbGRlciBFUFAgcmVn aXN0cmllcyAtIGNvbnRhY3QgYmxvYXQuDQo+IFdoZXJlIHRoaXMgZ2V0cyB0byBiZSBhbm5veWlu ZyBpcyBpbiBlc2Nyb3cgZGVwb3NpdHMgLSBjb3N0cyBtb25leSBmb3Igbm8NCj4gYWRkZWQgdmFs dWUgdG8gYW55b25lLiBXaHkgYmxvYXQgdXAgZXNjcm93IGRlcG9zaXRzIHdpdGggYSBidW5jaCBv ZiBkZWFkDQo+IGNvbnRhY3RzIGluIHRoZSBmaXJzdCBwbGFjZT8NCj4gDQo+IEp1c3Qgc2F5aW4s 4oCm4oCmLi4NCj4gDQo+IE1pY2hhZWwNCj4gDQo+IA0KPiANCj4gT24gMTItMDEtMTcgMTA6NDEg QU0sICJNaWNoZWxlIE5leWxvbiA6OiBCbGFja25pZ2h0Ig0KPiA8bWljaGVsZUBibGFja25pZ2h0 LmllPiB3cm90ZToNCj4gDQo+PiBSZWdpc3RyeSBvcGVyYXRvcnMgaGF2ZSBnb3QgdG8gZ2V0IG91 dCBvZiB0aGVpciB2YWN1dW0gbWVudGFsaXR5DQo+PiANCj4+IA0KPj4gT24gMTcgSmFuIDIwMTIs IGF0IDE2OjI5LCBQYXRyaWsgRsOkbHRzdHLDtm0gd3JvdGU6DQo+PiANCj4+PiBPbiAxNyBqYW4g MjAxMiwgYXQgMDk6NDgsIFRoZW8gS3JhbWVyIDx0aGVvQGZsYW1lLmNvLnphPiB3cm90ZToNCj4+ PiANCj4+Pj4gSSBjYW4gc2VlIG5vbmUuIEdhcmJhZ2UgY29sbGVjdGlvbiBpcyBhIGZ1bmN0aW9u IG9mIHJlZ2lzdHJ5DQo+Pj4+IG1haW50ZW5hbmNlIGltby4NCj4+PiANCj4+PiBBIHJlZ2lzdHJ5 IGNhbiBub3Qga25vdyBpZiBhbiBleGlzdGluZyBjb250YWN0IHJlY29yZCBpcyB0byBiZQ0KPj4+ IGNvbm5lY3RlZCB0byBhIGRvbWFpbiBuYW1lIHRoYXQgaXMgdG8gYmUgY3JlYXRlZCwgYXMgYnkg ZGVmaW5pdGlvbg0KPj4+IGNvbnRhY3QgcmVjb3JkcyBtdXN0IGV4aXN0IHdpdGggdGhlIHJlZ2lz dHJ5IHRoYXQgaXMgbm90IGNvbm5lY3RlZCB0bw0KPj4+IGFueSBkb21haW4gb2JqZWN0Lg0KPj4+ IA0KPj4+ICBQYXRyaWsNCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4+IHByb3ZyZWcgbWFpbGluZyBsaXN0DQo+Pj4gcHJvdnJlZ0BpZXRmLm9y Zw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcHJvdnJlZw0KPj4g DQo+PiBNciBNaWNoZWxlIE5leWxvbg0KPj4gQmxhY2tuaWdodCBTb2x1dGlvbnMg4pmeDQo+PiBI b3N0aW5nICYgQ29sb2NhdGlvbiwgQnJhbmQgUHJvdGVjdGlvbg0KPj4gSUNBTk4gQWNjcmVkaXRl ZCBSZWdpc3RyYXINCj4+IGh0dHA6Ly93d3cuYmxhY2tuaWdodC5jb20vDQo+PiBodHRwOi8vYmxv Zy5ibGFja25pZ2h0LmNvbS8NCj4+IGh0dHA6Ly9ibGFja25pZ2h0LmJpeg0KPj4gaHR0cDovL21u ZXlsb24udGVsDQo+PiBJbnRsLiArMzUzICgwKSA1OSAgOTE4MzA3Mg0KPj4gVVM6IDIxMy0yMzMt MTYxMiANCj4+IFVLOiAwODQ0IDQ4NCA5MzYxDQo+PiBMb2NhbGw6IDE4NTAgOTI5IDkyOQ0KPj4g RGlyZWN0IERpYWw6ICszNTMgKDApNTkgOTE4MzA5MA0KPj4gRmFjZWJvb2s6IGh0dHA6Ly9mYi5t ZS9ibGFja25pZ2h0DQo+PiBUd2l0dGVyOiBodHRwOi8vdHdpdHRlci5jb20vbW5leWxvbg0KPj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gQmxhY2tuaWdodCBJbnRlcm5ldCBT b2x1dGlvbnMgTHRkLCBVbml0IDEyQSxCYXJyb3dzaWRlIEJ1c2luZXNzDQo+PiBQYXJrLFNsZWF0 eQ0KPj4gUm9hZCxHcmFpZ3VlY3VsbGVuLENhcmxvdyxJcmVsYW5kICBDb21wYW55IE5vLjogMzcw ODQ1DQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+PiBwcm92cmVnIG1haWxpbmcgbGlzdA0KPj4gcHJvdnJlZ0BpZXRmLm9yZw0KPj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wcm92cmVnDQo+IA0KPiANCg0KTXIg TWljaGVsZSBOZXlsb24NCkJsYWNrbmlnaHQgU29sdXRpb25zIOKZng0KSG9zdGluZyAmIENvbG9j YXRpb24sIEJyYW5kIFByb3RlY3Rpb24NCklDQU5OIEFjY3JlZGl0ZWQgUmVnaXN0cmFyDQpodHRw Oi8vd3d3LmJsYWNrbmlnaHQuY29tLw0KaHR0cDovL2Jsb2cuYmxhY2tuaWdodC5jb20vDQpodHRw Oi8vYmxhY2tuaWdodC5iaXoNCmh0dHA6Ly9tbmV5bG9uLnRlbA0KSW50bC4gKzM1MyAoMCkgNTkg IDkxODMwNzINClVTOiAyMTMtMjMzLTE2MTIgDQpVSzogMDg0NCA0ODQgOTM2MQ0KTG9jYWxsOiAx ODUwIDkyOSA5MjkNCkRpcmVjdCBEaWFsOiArMzUzICgwKTU5IDkxODMwOTANCkZhY2Vib29rOiBo dHRwOi8vZmIubWUvYmxhY2tuaWdodA0KVHdpdHRlcjogaHR0cDovL3R3aXR0ZXIuY29tL21uZXls b24NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkJsYWNrbmlnaHQgSW50ZXJuZXQg U29sdXRpb25zIEx0ZCwgVW5pdCAxMkEsQmFycm93c2lkZSBCdXNpbmVzcyBQYXJrLFNsZWF0eQ0K Um9hZCxHcmFpZ3VlY3VsbGVuLENhcmxvdyxJcmVsYW5kICBDb21wYW55IE5vLjogMzcwODQ1DQoN Cg== From patrik@frobbit.se Tue Jan 17 09:29:27 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5342811E8083 for ; Tue, 17 Jan 2012 09:29:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.528 X-Spam-Level: X-Spam-Status: No, score=-100.528 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zq4U5ZXfDG9u for ; Tue, 17 Jan 2012 09:29:26 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 82C8E11E8079 for ; Tue, 17 Jan 2012 09:29:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id B942E12D5B1DA; Tue, 17 Jan 2012 18:29:24 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVoYqg2xfUzC; Tue, 17 Jan 2012 18:29:24 +0100 (CET) Received: from [10.177.67.223] (host-95-199-131-223.mobileonline.telia.com [95.199.131.223]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 25AEF12D5B1D6; Tue, 17 Jan 2012 18:29:24 +0100 (CET) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <187D6861-35D1-4B68-A72A-D2E3499039A7@frobbit.se> X-Mailer: iPhone Mail (9A405) From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= Date: Tue, 17 Jan 2012 18:28:43 +0100 To: MICHAEL YOUNG Cc: "provreg@ietf.org" Subject: Re: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 17:29:27 -0000 The problem here is that once again registries talk about "bloat" and "incre= ased cost" and because of that want to do operations that imply inconsistenc= ies with registrars databases, while registrars argue that for them it is no= t a problem at all with many contact records and that it is worse if registr= ies make commands that have implications in their database. Is this not a clear sign we must be better on working together? My suggestion was because of that that registrars make the gc command and re= gistries report back what was deleted. Only then registrars can immediately register again objects that must stay. Patrik On 17 jan 2012, at 17:58, MICHAEL YOUNG wrote: > I think there needs to be a reasonable period where you can determine a > contact object has been abandoned. Is there really a point to leaving > contacts around that haven't been associated for years? >=20 > That's certainly the case in the older EPP registries - contact bloat. > Where this gets to be annoying is in escrow deposits - costs money for no > added value to anyone. Why bloat up escrow deposits with a bunch of dead > contacts in the first place? >=20 > Just sayin,=E2=80=A6=E2=80=A6.. >=20 > Michael >=20 >=20 >=20 > On 12-01-17 10:41 AM, "Michele Neylon :: Blacknight" > wrote: >=20 >> Registry operators have got to get out of their vacuum mentality >>=20 >>=20 >> On 17 Jan 2012, at 16:29, Patrik F=C3=A4ltstr=C3=B6m wrote: >>=20 >>> On 17 jan 2012, at 09:48, Theo Kramer wrote: >>>=20 >>>> I can see none. Garbage collection is a function of registry >>>> maintenance imo. >>>=20 >>> A registry can not know if an existing contact record is to be >>> connected to a domain name that is to be created, as by definition >>> contact records must exist with the registry that is not connected to >>> any domain object. >>>=20 >>> Patrik >>> _______________________________________________ >>> provreg mailing list >>> provreg@ietf.org >>> https://www.ietf.org/mailman/listinfo/provreg >>=20 >> Mr Michele Neylon >> Blacknight Solutions =E2=99=9E >> Hosting & Colocation, Brand Protection >> ICANN Accredited Registrar >> http://www.blacknight.com/ >> http://blog.blacknight.com/ >> http://blacknight.biz >> http://mneylon.tel >> Intl. +353 (0) 59 9183072 >> US: 213-233-1612=20 >> UK: 0844 484 9361 >> Locall: 1850 929 929 >> Direct Dial: +353 (0)59 9183090 >> Facebook: http://fb.me/blacknight >> Twitter: http://twitter.com/mneylon >> ------------------------------- >> Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business >> Park,Sleaty >> Road,Graiguecullen,Carlow,Ireland Company No.: 370845 >>=20 >> _______________________________________________ >> provreg mailing list >> provreg@ietf.org >> https://www.ietf.org/mailman/listinfo/provreg >=20 >=20 >=20 From patrik@frobbit.se Tue Jan 17 09:33:37 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12BD11F0C40 for ; Tue, 17 Jan 2012 09:33:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.783 X-Spam-Level: X-Spam-Status: No, score=-100.783 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9r73dGW0GZgF for ; Tue, 17 Jan 2012 09:33:36 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 7267B21F853D for ; Tue, 17 Jan 2012 09:33:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id D4AA812D5B366; Tue, 17 Jan 2012 18:33:35 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDYWehK43N1P; Tue, 17 Jan 2012 18:33:35 +0100 (CET) Received: from [10.177.67.223] (host-95-199-131-223.mobileonline.telia.com [95.199.131.223]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 8A11B12D5B363; Tue, 17 Jan 2012 18:33:35 +0100 (CET) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <9D023AD9-0F45-4AB9-8634-65C431B846CE@frobbit.se> X-Mailer: iPhone Mail (9A405) From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= Date: Tue, 17 Jan 2012 18:32:55 +0100 To: "Michele Neylon :: Blacknight" Cc: "provreg@ietf.org" Subject: Re: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 17:33:37 -0000 On 17 jan 2012, at 18:28, "Michele Neylon :: Blacknight" wrote: > For example, some registries cause part of the contact bloat by sending th= e contact with a domain on transfer, but then not letting the new registrar d= o anything without first re-creating the contact :) Or, what .SE does, duplicate contact record at time of transfer. A, I think,= good thing but implemented in maybe a bit naive way. Positive things with i= t is though much higher than negative. We just must take care of the negativ= e implications... For all parties. Patrik= From michael@mwyoung.ca Tue Jan 17 09:44:52 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A1E21F8574 for ; Tue, 17 Jan 2012 09:44:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[AWL=-0.998, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lM59ZZOukPE4 for ; Tue, 17 Jan 2012 09:44:51 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6B94621F8557 for ; Tue, 17 Jan 2012 09:44:51 -0800 (PST) Received: by ggnr5 with SMTP id r5so3890196ggn.31 for ; Tue, 17 Jan 2012 09:44:50 -0800 (PST) Received: by 10.50.209.4 with SMTP id mi4mr6615736igc.17.1326822290480; Tue, 17 Jan 2012 09:44:50 -0800 (PST) Received: from [192.168.0.43] (174-155-52-17.pools.spcsdns.net. [174.155.52.17]) by mx.google.com with ESMTPS id g34sm79405962ibk.10.2012.01.17.09.44.48 (version=SSLv3 cipher=OTHER); Tue, 17 Jan 2012 09:44:49 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Tue, 17 Jan 2012 11:44:42 -0600 From: MICHAEL YOUNG To: Patrik =?ISO-8859-1?B?RuRsdHN0cvZt?= Message-ID: Thread-Topic: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt In-Reply-To: <187D6861-35D1-4B68-A72A-D2E3499039A7@frobbit.se> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Cc: "provreg@ietf.org" Subject: Re: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 17:44:52 -0000 You are right about synchronization, the registry needs to inform the registrar what its doing. Not sure the poll queue is a viable mechanism for that, but its the closest thing we have right now. We can do better though. This is definitely an area that should be worked on, some of the new registry use cases introduce new/additional contact types increasing the problem size. -M On 12-01-17 11:28 AM, "Patrik F=C3=A4ltstr=C3=B6m" wrote: >The problem here is that once again registries talk about "bloat" and >"increased cost" and because of that want to do operations that imply >inconsistencies with registrars databases, while registrars argue that >for them it is not a problem at all with many contact records and that it >is worse if registries make commands that have implications in their >database. > >Is this not a clear sign we must be better on working together? > >My suggestion was because of that that registrars make the gc command and >registries report back what was deleted. > >Only then registrars can immediately register again objects that must >stay. > > Patrik > > > > >On 17 jan 2012, at 17:58, MICHAEL YOUNG wrote: > >> I think there needs to be a reasonable period where you can determine a >> contact object has been abandoned. Is there really a point to leaving >> contacts around that haven't been associated for years? >>=20 >> That's certainly the case in the older EPP registries - contact bloat. >> Where this gets to be annoying is in escrow deposits - costs money for >>no >> added value to anyone. Why bloat up escrow deposits with a bunch of dead >> contacts in the first place? >>=20 >> Just sayin,=E2=80=A6=E2=80=A6.. >>=20 >> Michael >>=20 >>=20 >>=20 >> On 12-01-17 10:41 AM, "Michele Neylon :: Blacknight" >> wrote: >>=20 >>> Registry operators have got to get out of their vacuum mentality >>>=20 >>>=20 >>> On 17 Jan 2012, at 16:29, Patrik F=C3=A4ltstr=C3=B6m wrote: >>>=20 >>>> On 17 jan 2012, at 09:48, Theo Kramer wrote: >>>>=20 >>>>> I can see none. Garbage collection is a function of registry >>>>> maintenance imo. >>>>=20 >>>> A registry can not know if an existing contact record is to be >>>> connected to a domain name that is to be created, as by definition >>>> contact records must exist with the registry that is not connected to >>>> any domain object. >>>>=20 >>>> Patrik >>>> _______________________________________________ >>>> provreg mailing list >>>> provreg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/provreg >>>=20 >>> Mr Michele Neylon >>> Blacknight Solutions =E2=99=9E >>> Hosting & Colocation, Brand Protection >>> ICANN Accredited Registrar >>> http://www.blacknight.com/ >>> http://blog.blacknight.com/ >>> http://blacknight.biz >>> http://mneylon.tel >>> Intl. +353 (0) 59 9183072 >>> US: 213-233-1612 >>> UK: 0844 484 9361 >>> Locall: 1850 929 929 >>> Direct Dial: +353 (0)59 9183090 >>> Facebook: http://fb.me/blacknight >>> Twitter: http://twitter.com/mneylon >>> ------------------------------- >>> Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business >>> Park,Sleaty >>> Road,Graiguecullen,Carlow,Ireland Company No.: 370845 >>>=20 >>> _______________________________________________ >>> provreg mailing list >>> provreg@ietf.org >>> https://www.ietf.org/mailman/listinfo/provreg >>=20 >>=20 >>=20 From Klaus.Malorny@knipp.de Tue Jan 17 10:12:20 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA62621F8596 for ; Tue, 17 Jan 2012 10:12:20 -0800 (PST) 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.250, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2TPIaQsN0Yu for ; Tue, 17 Jan 2012 10:12:20 -0800 (PST) Received: from kmx10a.knipp.de (clust3b-eth0-0.bbone.knipp.de [195.253.6.85]) by ietfa.amsl.com (Postfix) with ESMTP id D049121F858B for ; Tue, 17 Jan 2012 10:12:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 560C448; Tue, 17 Jan 2012 19:12:18 +0100 (MEZ) 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 RfBgZ59plxC3; Tue, 17 Jan 2012 19:12:12 +0100 (MEZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id AB8A147; Tue, 17 Jan 2012 19:12:12 +0100 (MEZ) 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 q0HICBQ6009945; Tue, 17 Jan 2012 19:12:11 +0100 (MEZ) Message-ID: <4F15B9FB.1050208@knipp.de> Date: Tue, 17 Jan 2012 19:12:11 +0100 From: Klaus Malorny User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0a1) Gecko/20120116 Thunderbird/12.0a1 MIME-Version: 1.0 To: MICHAEL YOUNG References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "provreg@ietf.org" Subject: Re: [provreg] Changes we'd make to 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: Tue, 17 Jan 2012 18:12:21 -0000 On 17/01/12 18:44, MICHAEL YOUNG wrote: > You are right about synchronization, the registry needs to inform the > registrar what its doing. Not sure the poll queue is a viable mechanism > for that, but its the closest thing we have right now. We can do better > though. > > This is definitely an area that should be worked on, some of the new > registry use cases introduce new/additional contact types increasing the > problem size. > > -M Hi all, interesting discussion so far, just want to throw in two points - depending on the data protection regulations of the country in which the registry is located, unused personal data needs to be deleted after some time. So registries may actually have no other choice if they take data protection serious. - I just had an insane idea to avoid poll messages about the deletion of contacts -- you may forget it just after you have finished reading it (or even before): One could introduce an expiration date for contacts. If a contact is created, it is set to one year in the future. As long as the contact is used at least by one object, it is automatically renewed, let's say a quarter before it expires. The registrar can either track the expiration date (and perform a contact:info/check to check its existence in case his recorded expiration date is in the past) or simply create new contacts, as many registrars do it today. For the registry, if the contact passes its expiration date, it is simply deleted by the registry without any further fuss. There are also some design options to keep the effort in the registrar's database low, e.g. synthesize the expiration date dynamically while the contact is being used. Regards, Klaus From Klaus.Malorny@knipp.de Tue Jan 17 10:15:10 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E4021F85A5 for ; Tue, 17 Jan 2012 10:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zL2PgnP0W32v for ; Tue, 17 Jan 2012 10:15:09 -0800 (PST) Received: from kmx10a.knipp.de (clust3b-eth0-0.bbone.knipp.de [195.253.6.85]) by ietfa.amsl.com (Postfix) with ESMTP id 837DC21F85A4 for ; Tue, 17 Jan 2012 10:15:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id C90B968; Tue, 17 Jan 2012 19:15:08 +0100 (MEZ) 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 11Y4EC7h8u6f; Tue, 17 Jan 2012 19:15:03 +0100 (MEZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 5048B69; Tue, 17 Jan 2012 19:15:03 +0100 (MEZ) 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 q0HIF3uH010940; Tue, 17 Jan 2012 19:15:03 +0100 (MEZ) Message-ID: <4F15BAA7.4010601@knipp.de> Date: Tue, 17 Jan 2012 19:15:03 +0100 From: Klaus Malorny User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0a1) Gecko/20120116 Thunderbird/12.0a1 MIME-Version: 1.0 To: provreg@ietf.org References: <4F15B9FB.1050208@knipp.de> In-Reply-To: <4F15B9FB.1050208@knipp.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Changes we'd make to 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: Tue, 17 Jan 2012 18:15:10 -0000 On 17/01/12 19:12, Klaus Malorny wrote: > There are also some design options to keep the effort in the registrar's > database low, e.g. synthesize the expiration date dynamically while the > contact is being used. > Sorry, should read "in the registry's database", but I guess you already became aware of it. Klaus From brunner@nic-naa.net Tue Jan 17 10:16:49 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6CC45E8006 for ; Tue, 17 Jan 2012 10:16:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.704 X-Spam-Level: X-Spam-Status: No, score=-1.704 tagged_above=-999 required=5 tests=[AWL=-0.594, BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpxaUEW15w0E for ; Tue, 17 Jan 2012 10:16:49 -0800 (PST) Received: from nic-naa.net (nic-naa.net [65.99.1.132]) by ietfa.amsl.com (Postfix) with ESMTP id E35135E8005 for ; Tue, 17 Jan 2012 10:16:48 -0800 (PST) Received: from limpet.local (cpe-67-255-2-48.twcny.res.rr.com [67.255.2.48]) by nic-naa.net (8.14.4/8.14.4) with ESMTP id q0HFcZqG053522 for ; Tue, 17 Jan 2012 10:38:36 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-ID: <4F15BB0A.9000102@nic-naa.net> Date: Tue, 17 Jan 2012 13:16:42 -0500 From: Eric Brunner-Williams Organization: wampumpeag User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: provreg@ietf.org References: <4F15B9FB.1050208@knipp.de> In-Reply-To: <4F15B9FB.1050208@knipp.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Changes we'd make to EPP X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ebw@abenaki.wabanaki.net List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 18:16:49 -0000 On 1/17/12 1:12 PM, Klaus Malorny wrote: > I just had an insane idea to avoid poll messages about the deletion of > contacts ... temporal scope on objects is not insane. i don't recall anyone suggesting it, either in the xrp or the epp workouts. heck, if junk can be signed, it can be dated. -e From patrik@frobbit.se Tue Jan 17 10:22:34 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48ED11E8079 for ; Tue, 17 Jan 2012 10:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.401 X-Spam-Level: X-Spam-Status: No, score=-101.401 tagged_above=-999 required=5 tests=[AWL=0.898, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id feSxJrh44m5Q for ; Tue, 17 Jan 2012 10:22:34 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 557C111E8072 for ; Tue, 17 Jan 2012 10:22:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 59BFE12D5C63E; Tue, 17 Jan 2012 19:22:28 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtgXFq0pbd3q; Tue, 17 Jan 2012 19:22:28 +0100 (CET) Received: from [83.243.189.12] (unknown [213.184.192.106]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id F0CD912D5C638; Tue, 17 Jan 2012 19:22:27 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Tue, 17 Jan 2012 19:22:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9026763F-21C0-4409-861B-486F3A0EDF3A@frobbit.se> References: <4F073AB0.9080101@blacknight.com> <20120106185806.GA99133@crankycanuck.ca> <9362808D-CEF9-44CD-B4FA-542D6788B7A9@frobbit.se> <4F152E28.6070503@wisser.se> <444E3664-43C2-457B-BFD6-49E1B66CA14F@frobbit.se> To: Christopher Browne X-Mailer: Apple Mail (2.1251.1) Cc: "provreg@ietf.org" Subject: Re: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 18:22:35 -0000 On 17 jan 2012, at 18:51, Christopher Browne wrote: > a) Why should a registrar want to issue this command in the first > place? Because the registrar might have services connected with that contact = but not in that specific registry. I.e. one registry do not have any = knowledge about all services connected to one contact record. Patrik From michael@mwyoung.ca Tue Jan 17 10:23:26 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8045711E808D for ; Tue, 17 Jan 2012 10:23:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdXAcZDXWzuL for ; Tue, 17 Jan 2012 10:23:26 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id D8B3C11E8086 for ; Tue, 17 Jan 2012 10:23:25 -0800 (PST) Received: by yenr11 with SMTP id r11so2110585yen.31 for ; Tue, 17 Jan 2012 10:23:25 -0800 (PST) Received: by 10.236.131.45 with SMTP id l33mr25801841yhi.66.1326824605515; Tue, 17 Jan 2012 10:23:25 -0800 (PST) Received: from [192.168.1.144] (c-98-193-182-244.hsd1.tn.comcast.net. [98.193.182.244]) by mx.google.com with ESMTPS id f47sm37821739yhh.8.2012.01.17.10.23.24 (version=SSLv3 cipher=OTHER); Tue, 17 Jan 2012 10:23:24 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Tue, 17 Jan 2012 12:23:16 -0600 From: MICHAEL YOUNG To: Klaus Malorny , Message-ID: Thread-Topic: [provreg] Changes we'd make to EPP In-Reply-To: <4F15BAA7.4010601@knipp.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [provreg] Changes we'd make to 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: Tue, 17 Jan 2012 18:23:26 -0000 I think its a very interesting idea. Michael On 12-01-17 12:15 PM, "Klaus Malorny" wrote: >On 17/01/12 19:12, Klaus Malorny wrote: >> There are also some design options to keep the effort in the registrar's >> database low, e.g. synthesize the expiration date dynamically while the >> contact is being used. >> > >Sorry, should read "in the registry's database", but I guess you already >became >aware of it. > >Klaus > >_______________________________________________ >provreg mailing list >provreg@ietf.org >https://www.ietf.org/mailman/listinfo/provreg From Klaus.Malorny@knipp.de Tue Jan 17 10:29:05 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B1A11E808D for ; Tue, 17 Jan 2012 10:29:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.671 X-Spam-Level: X-Spam-Status: No, score=-2.671 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_05=-1.11, GB_I_LETTER=-2, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qraeziV1H+Sy for ; Tue, 17 Jan 2012 10:29:05 -0800 (PST) Received: from kmx10a.knipp.de (clust3b-eth0-0.bbone.knipp.de [195.253.6.85]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFE511E808F for ; Tue, 17 Jan 2012 10:29:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 4AAD869; Tue, 17 Jan 2012 19:29:03 +0100 (MEZ) 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 XFVjfy1b57RC; Tue, 17 Jan 2012 19:28:57 +0100 (MEZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id CDD9F68; Tue, 17 Jan 2012 19:28:57 +0100 (MEZ) 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 q0HISvWY012973; Tue, 17 Jan 2012 19:28:57 +0100 (MEZ) Message-ID: <4F15BDE9.8090104@knipp.de> Date: Tue, 17 Jan 2012 19:28:57 +0100 From: Klaus Malorny User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0a1) Gecko/20120116 Thunderbird/12.0a1 MIME-Version: 1.0 To: provreg@ietf.org References: <20111222002234.8359.14617.idtracker@ietfa.amsl.com> <0CB499D3-A9F7-4D3B-A7BA-6410E306BD25@frobbit.se> <4EF35621.4030306@blacknight.com> <4EF364A4.7040906@blacknight.com> <4EF37B73.4070101@knipp.de> <4F0B36E9.7080504@blacknight.com> In-Reply-To: <4F0B36E9.7080504@blacknight.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [provreg] New Version Notification for draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 18:29:05 -0000 On 09/01/12 19:50, Keith Gaughan wrote: > On 22/12/11 18:48, Klaus Malorny wrote: > > That's actually a good point, but how exactly they're treated very much= > depends on registry policy. For instance, does the registry implicitly > register ASCII variants (as the .cat registry does) or treat them as to= tally > separate entities (which is EURid's policy), and if you follow a .cat-l= ike > policy, and say (queue silly example) 'foo', 'f=C3=B6=C3=B6' and 'f=C3=B3= =C3=B3' are considered > considered distinct words in the language but the convention is to simp= ly > omit the accents, should registering one of them block the others? > > That's a pretty complex question. Indeed. But even if two differently accented words have different meaning= s, it=20 could make sense to allow only one of them to avoid confusion (at least t= o=20 someone who also thinks that no second tablet computer with rounded corne= rs and=20 a centered display may exist ;-)) > >> Regarding multiple tags: I personally think it should be legal to mix >> languages and scripts under certain (narrow) conditions. > >> Why should a domain >> like "caf=C3=A9-m=D0=BE=D1=81=D0=BA=D0=B2=D0=B0.ru" not be possible? > ^^ ^^^ ^ > Because it's open to homograph attacks, as demonstrated above. To avoid= that, > you'd have to specify some way of deliminating words within the label (= as you > did with the hyphen), but that complicates things an awful lot for very= little > gain, and you'd have people complaining that they can't register > "caf=C3=A9m=D0=BE=D1=81=D0=BA=D0=B2=D0=B0.ru", which in their eyes migh= t be equally legitimate. > This is what I meant with "narrow": e.g. that the words must be separated= by a=20 hyphen and that each word must not entirely consist of letters for which = homographs exist in the other script. I admit that such rules may be complex, likely too complex. The benefit o= f=20 having such domains might be outweighed by programming logic and the task= to=20 explain this to registrars and registrants. Regards, Klaus From theo@flame.co.za Tue Jan 17 10:50:39 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 352FE21F85E7 for ; Tue, 17 Jan 2012 10:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkl17DvLiv8F for ; Tue, 17 Jan 2012 10:50:38 -0800 (PST) Received: from flame.co.za (conficker5.flame.co.za [160.124.170.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E99121F85DF for ; Tue, 17 Jan 2012 10:50:38 -0800 (PST) Received: from [192.168.0.159] (unknown [41.31.12.51]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by flame.co.za (Postfix) with ESMTPSA id 052F08004D for ; Tue, 17 Jan 2012 20:50:33 +0200 (SAST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Theo Kramer In-Reply-To: <4F15B9FB.1050208@knipp.de> Date: Tue, 17 Jan 2012 20:50:22 +0200 Content-Transfer-Encoding: 7bit Message-Id: <4A2D08AC-F142-4F76-AF64-C1862175C54F@flame.co.za> References: <4F15B9FB.1050208@knipp.de> To: provreg@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [provreg] Changes we'd make to 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: Tue, 17 Jan 2012 18:50:39 -0000 On 17 Jan 2012, at 8:12 PM, Klaus Malorny wrote: > Hi all, > > interesting discussion so far, just want to throw in two points > > - depending on the data protection regulations of the country in which > the registry is located, unused personal data needs to be deleted > after some time. So registries may actually have no other choice > if they take data protection serious. > > - I just had an insane idea to avoid poll messages about the deletion of > contacts -- you may forget it just after you have finished > reading it (or even before): One could introduce an expiration date for > contacts. If a contact is created, it is set to one year in the future. > As long as the contact is used at least by one object, it is automatically > renewed, let's say a quarter before it expires. The registrar can either > track the expiration date (and perform a contact:info/check to check > its existence in case his recorded expiration date is in the past) > or simply create new contacts, as many registrars do it today. > For the registry, if the contact passes its expiration date, it is > simply deleted by the registry without any further fuss. > > There are also some design options to keep the effort in the registrar's > database low, e.g. synthesize the expiration date dynamically while the > contact is being used. +1 -- Regards Theo From theo@flame.co.za Tue Jan 17 10:54:14 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 229AF11E8089 for ; Tue, 17 Jan 2012 10:54:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iszMg8BfCS0e for ; Tue, 17 Jan 2012 10:54:13 -0800 (PST) Received: from flame.co.za (conficker5.flame.co.za [160.124.170.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B64211E8086 for ; Tue, 17 Jan 2012 10:54:13 -0800 (PST) Received: from [192.168.0.159] (unknown [41.31.12.51]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by flame.co.za (Postfix) with ESMTPSA id 5D3708004D for ; Tue, 17 Jan 2012 20:54:08 +0200 (SAST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Theo Kramer In-Reply-To: <1D76D22D-1B30-4A95-B0A7-6FCDE51EC66F@blacknight.ie> Date: Tue, 17 Jan 2012 20:54:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F073AB0.9080101@blacknight.com> <20120106185806.GA99133@crankycanuck.ca> <9362808D-CEF9-44CD-B4FA-542D6788B7A9@frobbit.se> <4F152E28.6070503@wisser.se> <444E3664-43C2-457B-BFD6-49E1B66CA14F@frobbit.se> <1D76D22D-1B30-4A95-B0A7-6FCDE51EC66F@blacknight.ie> To: provreg@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 18:54:14 -0000 On 17 Jan 2012, at 6:41 PM, Michele Neylon :: Blacknight wrote: > Registry operators have got to get out of their vacuum mentality Registry operator responsibilities include maintaining the db - can't = see how this is 'vacuum mentality'. --=20 Regards Theo From theo@flame.co.za Tue Jan 17 10:55:45 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8064311E80A4 for ; Tue, 17 Jan 2012 10:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeL7AkYLuNVU for ; Tue, 17 Jan 2012 10:55:45 -0800 (PST) Received: from flame.co.za (conficker5.flame.co.za [160.124.170.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFCCC11E8086 for ; Tue, 17 Jan 2012 10:55:44 -0800 (PST) Received: from [192.168.0.159] (unknown [41.31.12.51]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by flame.co.za (Postfix) with ESMTPSA id 74D488004D for ; Tue, 17 Jan 2012 20:55:41 +0200 (SAST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1084) From: Theo Kramer In-Reply-To: Date: Tue, 17 Jan 2012 20:55:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1E3AE212-407C-4962-8D34-B54E480746BB@flame.co.za> References: <4F073AB0.9080101@blacknight.com> <20120106185806.GA99133@crankycanuck.ca> <9362808D-CEF9-44CD-B4FA-542D6788B7A9@frobbit.se> <4F152E28.6070503@wisser.se> To: provreg@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 18:55:45 -0000 On 17 Jan 2012, at 6:26 PM, Patrik F=E4ltstr=F6m wrote: > On 17 jan 2012, at 09:15, Ulrich Wisser wrote: >=20 >> What is the incentive for the registrar to clean the registry = database? >=20 > Same as all contractual requirements registries have on their = registrars. >=20 So a clause could be that any unlinked contact over a certain age will = be deleted... --=20 Regards Theo From michele@blacknight.ie Tue Jan 17 11:00:18 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE65511E80A5 for ; Tue, 17 Jan 2012 11:00:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dr+JLCVclf5G for ; Tue, 17 Jan 2012 11:00:18 -0800 (PST) Received: from exchange.blacknight.ie (exchange.blacknight.ie [81.17.243.252]) by ietfa.amsl.com (Postfix) with ESMTP id E909711E80A4 for ; Tue, 17 Jan 2012 11:00:17 -0800 (PST) Received: from BKEXCHMBX01.blacknight.local ([fe80::76:af74:8c72:96ac]) by bkexchhubcas01.blacknight.local ([fe80::3ca9:6bf1:bd5d:24b%15]) with mapi id 14.02.0247.003; Tue, 17 Jan 2012 19:00:15 +0000 From: "Michele Neylon :: Blacknight" To: Theo Kramer Thread-Topic: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt Thread-Index: AQHM1PTeYhTVBbXL6UmhygsAh2jBXJYQwI+AgAADUgCAACT4gIAAAbmA Date: Tue, 17 Jan 2012 19:00:14 +0000 Message-ID: <67DD4F3C-D1F8-4F25-A16A-BE1E911C7872@blacknight.ie> References: <4F073AB0.9080101@blacknight.com> <20120106185806.GA99133@crankycanuck.ca> <9362808D-CEF9-44CD-B4FA-542D6788B7A9@frobbit.se> <4F152E28.6070503@wisser.se> <444E3664-43C2-457B-BFD6-49E1B66CA14F@frobbit.se> <1D76D22D-1B30-4A95-B0A7-6FCDE51EC66F@blacknight.ie> In-Reply-To: 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 Cc: "" Subject: Re: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 19:00:19 -0000 On 17 Jan 2012, at 18:54, Theo Kramer wrote: >=20 > On 17 Jan 2012, at 6:41 PM, Michele Neylon :: Blacknight wrote: >=20 >> Registry operators have got to get out of their vacuum mentality >=20 > Registry operator responsibilities include maintaining the db - can't see= how this is 'vacuum mentality'. See my other emails on this subject > --=20 > Regards > Theo >=20 > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg 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 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From brunner@nic-naa.net Tue Jan 17 12:11:35 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A5C21F848F for ; Tue, 17 Jan 2012 12:11:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.33 X-Spam-Level: X-Spam-Status: No, score=-2.33 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yn5KNI3oV+jo for ; Tue, 17 Jan 2012 12:11:35 -0800 (PST) Received: from nic-naa.net (nic-naa.net [65.99.1.132]) by ietfa.amsl.com (Postfix) with ESMTP id B587721F848B for ; Tue, 17 Jan 2012 12:11:34 -0800 (PST) Received: from limpet.local (cpe-67-255-2-48.twcny.res.rr.com [67.255.2.48]) by nic-naa.net (8.14.4/8.14.4) with ESMTP id q0HHXKep053948 for ; Tue, 17 Jan 2012 12:33:20 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-ID: <4F15D5F0.8010005@nic-naa.net> Date: Tue, 17 Jan 2012 15:11:28 -0500 From: Eric Brunner-Williams Organization: wampumpeag User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: provreg@ietf.org References: <4F073AB0.9080101@blacknight.com> <20120106185806.GA99133@crankycanuck.ca> <9362808D-CEF9-44CD-B4FA-542D6788B7A9@frobbit.se> <4F152E28.6070503@wisser.se> <444E3664-43C2-457B-BFD6-49E1B66CA14F@frobbit.se> <1D76D22D-1B30-4A95-B0A7-6FCDE51EC66F@blacknight.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ebw@abenaki.wabanaki.net List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 20:11:35 -0000 On 1/17/12 1:54 PM, Theo Kramer wrote: >> > Registry operators have got to get out of their vacuum mentality > Registry operator responsibilities include maintaining the db - can't see how this is 'vacuum mentality'. Michele has this correct. A registry contract holder exists in isolation. If the contract holder operates its own facilities based registry platform, and has no other tenants, and its registrar "arm" (prospective) only provides access to its own registry, then this dyad of registry operator and registrar operator exist in isolation, relative to the rest of the bells-and-whistles-EEP-verse. A registry platform operator with two or more tenants (or expectations along those lines) exists differently, and has a longer, or broader, view of the bells-and-whistles-EEP-verse and the associated policy space. The degenerate platform operator case is the tenant-only bells-and-policy aware, and otherwise indifferent, operator. A registrar meeting the access requirements of two or more policy distinct (some non-shared bells-and-whistles) registries has to take a very different view of features, changes, and predicable events. Those implementing multi-namespace services, whether server-side or client-side, necessarily take a different view from implementors and operators of mono-namespaces. The "vacuum mentality" is natural, and hard to fault, for each isolated island of misfit toys. Eric From cbbrowne@afilias.info Tue Jan 17 09:51:37 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F5A21F8474 for ; Tue, 17 Jan 2012 09:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.484 X-Spam-Level: X-Spam-Status: No, score=-3.484 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhrueWoFGjo7 for ; Tue, 17 Jan 2012 09:51:36 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id A7ECB21F8473 for ; Tue, 17 Jan 2012 09:51:36 -0800 (PST) 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 1RnDC3-0007ci-93 for provreg@ietf.org; Tue, 17 Jan 2012 17:51:35 +0000 Received: from mail-we0-f178.google.com ([74.125.82.178]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1RnDC3-0001Wk-4i for provreg@ietf.org; Tue, 17 Jan 2012 17:51:35 +0000 Received: by werm1 with SMTP id m1so1807205wer.9 for ; Tue, 17 Jan 2012 09:51:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.139.150 with SMTP id c22mr1312042wej.25.1326822694286; Tue, 17 Jan 2012 09:51:34 -0800 (PST) Received: by 10.180.97.70 with HTTP; Tue, 17 Jan 2012 09:51:34 -0800 (PST) In-Reply-To: <444E3664-43C2-457B-BFD6-49E1B66CA14F@frobbit.se> References: <4F073AB0.9080101@blacknight.com> <20120106185806.GA99133@crankycanuck.ca> <9362808D-CEF9-44CD-B4FA-542D6788B7A9@frobbit.se> <4F152E28.6070503@wisser.se> <444E3664-43C2-457B-BFD6-49E1B66CA14F@frobbit.se> Date: Tue, 17 Jan 2012 12:51:34 -0500 Message-ID: From: Christopher Browne To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 17 Jan 2012 12:33:49 -0800 Cc: "provreg@ietf.org" Subject: Re: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 17:51:37 -0000 2012/1/17 Patrik F=E4ltstr=F6m : > On 17 jan 2012, at 09:48, Theo Kramer wrote: > >> I can see none. Garbage collection is a function of registry maintenance= imo. > > A registry can not know if an existing contact record is to be connected = to a domain name that is to be created, as by definition contact records mu= st exist with the registry that is not connected to any domain object. Indeed. When I have brought this up, the focus is always on the business policy side, not the technical policy. Everyone gets very concerned about the notion that we might be destroying data that "belongs" to the registrars. And yes, indeed, we don't know if a record is about to be used. (Though if it has not been connected to anything for several years, one might take a pretty strong hint that it has been discarded...) My favourite idea, which has seen zero up-take, has been the notion of creating a policy along the lines of "Registrars are allowed to have a certain number of unused contacts 'for free.' If the number exceeds that threshold, we'll bill them something, that'll encourage them to clean up their unused contacts." The bit of economist in me likes that form of feedback, and I certainly don't have in mind for this to be a profit centre, just to make sure that registrars find it of value to clean up after themselves. Pushing that through the various layers of politics seems pretty daunting. Alternatively, it would be in principle plausible to add some logic surrounding the LINKED status, to put a TTL onto contacts any time they change to be unlinked. What should initiate GC, and how to communicate the work done back to the registrars is a good question. Your idea of a "GC" command is certainly interesting, though I see things to have reservations about: a) Why should a registrar want to issue this command in the first place? I suspect we have quite a few registrars that never care to pull data coming from their poll queues, and would expect some overlap between those that don't care about that and those that would never bother issuing a command. b) What should the return result be? 1. Perhaps merely a "Yep, we'll be getting on to that" response. 2. If there are 500000 contacts to trim out, I don't imagine it's reasonable to expect for this request to wait until that is all done. 3. It might be nice to get a list of trimmed contacts, but if there are 500000 of them, that's not likely reasonable. Proposals for EPP extensions offering very large response sets have generally gotten push-back. 4. Perhaps the list of contacts trimmed get thrown into the poll queue. But 500000 of them mayn't be reasonable to process. That may just shove the problem around a little. Fixing the "dead contacts problem" may lead us into having much worse problems with poll queue. From cbbrowne@afilias.info Tue Jan 17 11:50:11 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8AF21F8605 for ; Tue, 17 Jan 2012 11:50:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.564 X-Spam-Level: X-Spam-Status: No, score=-4.564 tagged_above=-999 required=5 tests=[AWL=1.079, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSaypzVcup-I for ; Tue, 17 Jan 2012 11:50:11 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id 190FA21F8600 for ; Tue, 17 Jan 2012 11:50:10 -0800 (PST) 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 1RnF2o-0001Q0-6S for provreg@ietf.org; Tue, 17 Jan 2012 19:50:10 +0000 Received: from mail-we0-f178.google.com ([74.125.82.178]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1RnF2n-0004J0-5l for provreg@ietf.org; Tue, 17 Jan 2012 19:50:09 +0000 Received: by werm1 with SMTP id m1so1924104wer.9 for ; Tue, 17 Jan 2012 11:50:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.139.150 with SMTP id c22mr1527704wej.25.1326829808555; Tue, 17 Jan 2012 11:50:08 -0800 (PST) Received: by 10.180.97.70 with HTTP; Tue, 17 Jan 2012 11:50:08 -0800 (PST) In-Reply-To: <4F15B9FB.1050208@knipp.de> References: <4F15B9FB.1050208@knipp.de> Date: Tue, 17 Jan 2012 14:50:08 -0500 Message-ID: From: Christopher Browne To: Klaus Malorny Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 17 Jan 2012 12:33:49 -0800 Cc: "provreg@ietf.org" Subject: Re: [provreg] Changes we'd make to 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: Tue, 17 Jan 2012 19:50:11 -0000 On Tue, Jan 17, 2012 at 1:12 PM, Klaus Malorny wro= te: > - I just had an insane idea to avoid poll messages about the deletion of > =A0contacts -- you may forget it just after you have finished > =A0reading it (or even before): One could introduce an expiration date fo= r > =A0contacts. If a contact is created, it is set to one year in the future= . > =A0As long as the contact is used at least by one object, it is automatic= ally > =A0renewed, let's say a quarter before it expires. The registrar can eith= er > =A0track the expiration date (and perform a contact:info/check to check > =A0its existence in case his recorded expiration date is in the past) > =A0or simply create new contacts, as many registrars do it today. > =A0For the registry, if the contact passes its expiration date, it is > =A0simply deleted by the registry without any further fuss. I kind of like that, though I have a somewhat different implementation thought, basically tying the expiration date to whether or not the contact is linked. - Upon creation of a contact, it is initially not linked to anything. Registry ties in an expiration date, and I have no disagreement with the notion of that being 1 year in the future. - Upon linking a contact to an object (e.g. - to a domain), that establishes LINKED status. This *removes* that expiration date. - Any time a domain becomes unlinked (e.g. - the last link to a domain or other object disappears), the registry ties in an expiration date again. The clock is ticking on its removal. It seems preferable to me to not have an expiry date when there is no reason to want one. The semantics of what that date means and how it should be manipulated seem rather strange at times when the contact is being 'actively used.' And if it's there, and reported, it seems likely to cause confusion. From JGould@verisign.com Tue Jan 17 12:59:37 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B533111E80C4 for ; Tue, 17 Jan 2012 12:59:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hb218B9ve4pN for ; Tue, 17 Jan 2012 12:59:37 -0800 (PST) Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) by ietfa.amsl.com (Postfix) with ESMTP id 957E111E80AD for ; Tue, 17 Jan 2012 12:59:36 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP ID DSNKTxXhKWAOWoSABIYpnSxK91zqaumVZJVI@postini.com; Tue, 17 Jan 2012 12:59:36 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q0HKxGdP008689; Tue, 17 Jan 2012 15:59:19 -0500 Received: from BRN1WNEXCAS02.vcorp.ad.vrsn.com ([10.173.152.246]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Jan 2012 15:59:17 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.01.0323.003; Tue, 17 Jan 2012 15:59:16 -0500 From: "Gould, James" To: Christopher Browne , Klaus Malorny Thread-Topic: [provreg] Changes we'd make to EPP Thread-Index: AQHM1UOQ6D+I/efY2kewKQWAlaNGyZYRS7gA//+/eAA= Date: Tue, 17 Jan 2012 20:59:16 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 17 Jan 2012 20:59:17.0111 (UTC) FILETIME=[E023B070:01CCD55A] Cc: "provreg@ietf.org" Subject: Re: [provreg] Changes we'd make to 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: Tue, 17 Jan 2012 20:59:37 -0000 I believe this is getting a bit complex and convoluted. Contacts are first class objects in themselves as defined by RFC 5733, so they could be created at any point with no relation to a domain. I don't believe the Registry should take any action to garbage collect them based on the lack of references from other objects like domains. In systems like DotName a contact can be linked to other types of objects (emailfwd, defreg, etc.), so there is no hard dependency with being linked with a domain. The same holds true for orphaned hosts, since hosts are not attributes of the domain unless the host attribute model is chosen. It makes more sense to report on orphaned objects (contacts and hosts) out-of-band and for the Registries to reach out to the Registrars that have an unusually high number of them. I'm not sure if we need a system solution to this that requires protocol changes. -- =20 JG =20 =20 James Gould Principal Software Engineer jgould@verisign.com =20 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On 1/17/12 2:50 PM, "Christopher Browne" wrote: >On Tue, Jan 17, 2012 at 1:12 PM, Klaus Malorny >wrote: >> - I just had an insane idea to avoid poll messages about the deletion of >> contacts -- you may forget it just after you have finished >> reading it (or even before): One could introduce an expiration date for >> contacts. If a contact is created, it is set to one year in the future. >> As long as the contact is used at least by one object, it is >>automatically >> renewed, let's say a quarter before it expires. The registrar can >>either >> track the expiration date (and perform a contact:info/check to check >> its existence in case his recorded expiration date is in the past) >> or simply create new contacts, as many registrars do it today. >> For the registry, if the contact passes its expiration date, it is >> simply deleted by the registry without any further fuss. > >I kind of like that, though I have a somewhat different implementation >thought, basically tying the expiration date to whether or not the >contact is linked. > >- Upon creation of a contact, it is initially not linked to anything. >Registry ties in an expiration date, and I have no disagreement with >the notion of that being 1 year in the future. > >- Upon linking a contact to an object (e.g. - to a domain), that >establishes LINKED status. This *removes* that expiration date. > >- Any time a domain becomes unlinked (e.g. - the last link to a domain >or other object disappears), the registry ties in an expiration date >again. The clock is ticking on its removal. > >It seems preferable to me to not have an expiry date when there is no >reason to want one. > >The semantics of what that date means and how it should be manipulated >seem rather strange at times when the contact is being 'actively >used.' And if it's there, and reported, it seems likely to cause >confusion. >_______________________________________________ >provreg mailing list >provreg@ietf.org >https://www.ietf.org/mailman/listinfo/provreg From michael@mwyoung.ca Tue Jan 17 13:51:17 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF51421F852A for ; Tue, 17 Jan 2012 13:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lFjbaudXVtH for ; Tue, 17 Jan 2012 13:51:15 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A0BB321F8487 for ; Tue, 17 Jan 2012 13:51:15 -0800 (PST) Received: by iaae16 with SMTP id e16so12023914iaa.31 for ; Tue, 17 Jan 2012 13:51:15 -0800 (PST) Received: by 10.50.85.201 with SMTP id j9mr5778746igz.30.1326837075198; Tue, 17 Jan 2012 13:51:15 -0800 (PST) Received: from [192.168.0.43] (174-155-52-17.pools.spcsdns.net. [174.155.52.17]) by mx.google.com with ESMTPS id g7sm32838286igv.7.2012.01.17.13.51.06 (version=SSLv3 cipher=OTHER); Tue, 17 Jan 2012 13:51:14 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Tue, 17 Jan 2012 15:51:00 -0600 From: MICHAEL YOUNG To: "Gould, James" , Christopher Browne , Klaus Malorny Message-ID: Thread-Topic: [provreg] Changes we'd make to EPP 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] Changes we'd make to 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: Tue, 17 Jan 2012 21:51:17 -0000 Sure, you can notify registrars all you want,that doesn't mean they will or are required to do anything about it. On the other hand, if they don't choose to continue to leave contact objects around for years, not linked to anything (domains or other objects), then it's reasonable for a registry to have a policy that allows them to declare them abandoned and clean them up. On the other hand, the registry really shouldn't be changing registrar created/owned objects without synchronizing their activities somehow, someway, as aptly put by others on the list. This problem statement been repeated again and again for years. Clearly, there is a desire for a solution, although James you certainly entitled to your opinion :-) I still think the expiration idea on contacts is graceful and would support that approach. I think it informs registrars that contacts which aren't linked don't last forever and if they are, the contacts auto-renew so there's no work on the registrar side. This approach means the registry isn't randomly mucking with their contacts in a less predictable manner and having to update the registrar somehow that they deleted their contact objects. Some EPP registries have 2x or more abandoned contacts than active/linked contacts (without naming them explicitly). Can you imagine that in .com? A billion some-odd dead contacts sitting around in your escrow deposits. I do think this could use a technical solution. Michael Young On 12-01-17 2:59 PM, "Gould, James" wrote: >I believe this is getting a bit complex and convoluted. Contacts are >first class objects in themselves as defined by RFC 5733, so they could be >created at any point with no relation to a domain. I don't believe the >Registry should take any action to garbage collect them based on the lack >of references from other objects like domains. In systems like DotName a >contact can be linked to other types of objects (emailfwd, defreg, etc.), >so there is no hard dependency with being linked with a domain. The same >holds true for orphaned hosts, since hosts are not attributes of the >domain unless the host attribute model is chosen. It makes more sense to >report on orphaned objects (contacts and hosts) out-of-band and for the >Registries to reach out to the Registrars that have an unusually high >number of them. I'm not sure if we need a system solution to this that >requires protocol changes. > >-- > >JG > > > >James Gould >Principal Software Engineer >jgould@verisign.com > >703-948-3271 (Office) >12061 Bluemont Way >Reston, VA 20190 >VerisignInc.com > > > > > > > >On 1/17/12 2:50 PM, "Christopher Browne" wrote: > >>On Tue, Jan 17, 2012 at 1:12 PM, Klaus Malorny >>wrote: >>> - I just had an insane idea to avoid poll messages about the deletion >>>of >>> contacts -- you may forget it just after you have finished >>> reading it (or even before): One could introduce an expiration date >>>for >>> contacts. If a contact is created, it is set to one year in the >>>future. >>> As long as the contact is used at least by one object, it is >>>automatically >>> renewed, let's say a quarter before it expires. The registrar can >>>either >>> track the expiration date (and perform a contact:info/check to check >>> its existence in case his recorded expiration date is in the past) >>> or simply create new contacts, as many registrars do it today. >>> For the registry, if the contact passes its expiration date, it is >>> simply deleted by the registry without any further fuss. >> >>I kind of like that, though I have a somewhat different implementation >>thought, basically tying the expiration date to whether or not the >>contact is linked. >> >>- Upon creation of a contact, it is initially not linked to anything. >>Registry ties in an expiration date, and I have no disagreement with >>the notion of that being 1 year in the future. >> >>- Upon linking a contact to an object (e.g. - to a domain), that >>establishes LINKED status. This *removes* that expiration date. >> >>- Any time a domain becomes unlinked (e.g. - the last link to a domain >>or other object disappears), the registry ties in an expiration date >>again. The clock is ticking on its removal. >> >>It seems preferable to me to not have an expiry date when there is no >>reason to want one. >> >>The semantics of what that date means and how it should be manipulated >>seem rather strange at times when the contact is being 'actively >>used.' And if it's there, and reported, it seems likely to cause >>confusion. >>_______________________________________________ >>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 theo@flame.co.za Tue Jan 17 13:53:54 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3B221F852C for ; Tue, 17 Jan 2012 13:53:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgeS-0sD0Sqk for ; Tue, 17 Jan 2012 13:53:53 -0800 (PST) Received: from flame.co.za (ns.flame.co.za [160.124.170.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED8821F859B for ; Tue, 17 Jan 2012 13:53:53 -0800 (PST) Received: from [192.168.0.159] (unknown [41.31.12.51]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by flame.co.za (Postfix) with ESMTPSA id 2CDA78004D for ; Tue, 17 Jan 2012 23:53:47 +0200 (SAST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Theo Kramer In-Reply-To: Date: Tue, 17 Jan 2012 23:53:36 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: To: provreg@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [provreg] Changes we'd make to 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: Tue, 17 Jan 2012 21:53:54 -0000 On 17 Jan 2012, at 10:59 PM, Gould, James wrote: > I believe this is getting a bit complex and convoluted. Contacts are > first class objects in themselves as defined by RFC 5733, so they could be > created at any point with no relation to a domain. Yep - so a cost associated with these would solve the problem... -- Regards Theo From michael@mwyoung.ca Tue Jan 17 14:04:14 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C69AF21F8605 for ; Tue, 17 Jan 2012 14:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.066 X-Spam-Level: X-Spam-Status: No, score=-3.066 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EJk2cI9O+BL for ; Tue, 17 Jan 2012 14:04:14 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id DC8C021F85F2 for ; Tue, 17 Jan 2012 14:04:13 -0800 (PST) Received: by iaae16 with SMTP id e16so12039415iaa.31 for ; Tue, 17 Jan 2012 14:04:12 -0800 (PST) Received: by 10.50.181.197 with SMTP id dy5mr19502116igc.13.1326837851131; Tue, 17 Jan 2012 14:04:11 -0800 (PST) Received: from [192.168.0.43] (174-155-52-17.pools.spcsdns.net. [174.155.52.17]) by mx.google.com with ESMTPS id g7sm32889368igv.7.2012.01.17.14.04.09 (version=SSLv3 cipher=OTHER); Tue, 17 Jan 2012 14:04:10 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Tue, 17 Jan 2012 16:04:05 -0600 From: MICHAEL YOUNG To: Theo Kramer , Message-ID: Thread-Topic: [provreg] Changes we'd make to EPP In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [provreg] Changes we'd make to 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: Tue, 17 Jan 2012 22:04:14 -0000 Charging against objects assumes declaring a billing period and addressing deferred revenues. Yes it would work but its expensive since it hits a lot of downstream billing related systems. Best Regards, Michael Young M:647-289-1220 On 12-01-17 3:53 PM, "Theo Kramer" wrote: > >On 17 Jan 2012, at 10:59 PM, Gould, James wrote: > >> I believe this is getting a bit complex and convoluted. Contacts are >> first class objects in themselves as defined by RFC 5733, so they could >>be >> created at any point with no relation to a domain. > >Yep - so a cost associated with these would solve the problem... > >-- >Regards >Theo > >_______________________________________________ >provreg mailing list >provreg@ietf.org >https://www.ietf.org/mailman/listinfo/provreg From ajs@anvilwalrusden.com Tue Jan 17 14:07:13 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3641F0C46 for ; Tue, 17 Jan 2012 14:07:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgwZFmKoGc1J for ; Tue, 17 Jan 2012 14:07:13 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 1655F1F0C35 for ; Tue, 17 Jan 2012 14:07:13 -0800 (PST) Received: from mail.yitter.info (nat-02-mht.dyndns.com [216.146.45.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 1BA7B1ECB422 for ; Tue, 17 Jan 2012 22:07:12 +0000 (UTC) Date: Tue, 17 Jan 2012 17:07:10 -0500 From: Andrew Sullivan To: provreg@ietf.org Message-ID: <20120117220710.GK2221@mail.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [provreg] Changes we'd make to 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: Tue, 17 Jan 2012 22:07:14 -0000 On Tue, Jan 17, 2012 at 03:51:00PM -0600, MICHAEL YOUNG wrote: > registry to have a policy that allows them to declare them abandoned > and clean them up. > > On the other hand, the registry really shouldn't be changing registrar > created/owned objects without synchronizing their activities somehow, > someway, as aptly put by others on the list. > > This problem statement been repeated again and again for years. > Clearly, there is a desire for a solution, although James you I don't understand why this issue is generating such heat on the list. What's the issue? Repositories could have any policy they want on this. You can already do any of what you want with the existing protocol, because the protocol has an "out" for bulk operations where you don't want to fill up the poll queue: Message queues can consume server resources if clients do not retrieve and acknowledge messages on a regular basis. Servers MAY implement other mechanisms to dequeue and deliver messages if queue maintenance needs exceed server resource consumption limits. Server operators SHOULD consider time-sensitivity and resource management factors when selecting a delivery method for service information because some message types can be reasonably delivered using non- protocol methods that require fewer server resources. > I still think the expiration idea on contacts is graceful and would > support that approach. You'd need an extension or a new contact mapping, though. A -- Andrew Sullivan ajs@anvilwalrusden.com From michael@mwyoung.ca Tue Jan 17 14:21:14 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77EF521F8452 for ; Tue, 17 Jan 2012 14:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.2 X-Spam-Level: X-Spam-Status: No, score=-3.2 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7u1HiTVqxBd for ; Tue, 17 Jan 2012 14:21:14 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id DB54821F844E for ; Tue, 17 Jan 2012 14:21:13 -0800 (PST) Received: by iaae16 with SMTP id e16so12059711iaa.31 for ; Tue, 17 Jan 2012 14:21:13 -0800 (PST) Received: by 10.50.222.233 with SMTP id qp9mr17091186igc.1.1326838873362; Tue, 17 Jan 2012 14:21:13 -0800 (PST) Received: from [192.168.0.43] (174-155-52-17.pools.spcsdns.net. [174.155.52.17]) by mx.google.com with ESMTPS id lu10sm40983108igc.0.2012.01.17.14.21.11 (version=SSLv3 cipher=OTHER); Tue, 17 Jan 2012 14:21:12 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Tue, 17 Jan 2012 16:21:08 -0600 From: MICHAEL YOUNG To: Andrew Sullivan , Message-ID: Thread-Topic: [provreg] Changes we'd make to EPP In-Reply-To: <20120117220710.GK2221@mail.yitter.info> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [provreg] Changes we'd make to 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: Tue, 17 Jan 2012 22:21:14 -0000 >You'd need an extension or a new contact mapping, though. > Yes we would, however the poll queue approach is a LOT of chatter even if you clean it out periodically like some registries do. Its clunky. More to the bigger question of doing work or not doing work, EPP has been rolling for 10 years, I think we could suffer a few well thought out improvements at this point. -M From jaap@bartok.nlnetlabs.nl Tue Jan 17 14:23:22 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B85D21F845B for ; Tue, 17 Jan 2012 14:23:22 -0800 (PST) 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_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovy7PN9FJCK9 for ; Tue, 17 Jan 2012 14:23:22 -0800 (PST) Received: from bartok.nlnetlabs.nl (bartok.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:3c02]) by ietfa.amsl.com (Postfix) with ESMTP id 44CE421F845A for ; Tue, 17 Jan 2012 14:23:21 -0800 (PST) Received: from bartok.nlnetlabs.nl (localhost [127.0.0.1]) by bartok.nlnetlabs.nl (8.14.5/8.14.5) with ESMTP id q0HMNI7f041767 for ; Tue, 17 Jan 2012 23:23:19 +0100 (CET) (envelope-from jaap@bartok.nlnetlabs.nl) X-DKIM: OpenDKIM Filter v2.4.2 bartok.nlnetlabs.nl q0HMNI7f041767 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=sleutel; t=1326838999; i=@nlnetlabs.nl; bh=3pAPRYd5MzqnSoJyl3zICgFBIytUSJSPo4R6y4lL/6Y=; h=To:Subject:In-reply-to:References:Date:From; b=XXpwJHLWOZsO05Rd6SPVmj8pq1TQ3+L6t9CqmQ+30lyk/h0bZ76n6DK1fcgoTMkIm kPSgMNwLRuAINa9i1CUlEM20lM4l9G2B9MtlIa44ONanWullldexkBIt+G8EDFz81Y ROg98HXzWSPw/Ndqir4Xok9LD7oprMANI4jiXXqM= Message-Id: <201201172223.q0HMNI7f041767@bartok.nlnetlabs.nl> To: "provreg@ietf.org" In-reply-to: References: Comments: In-reply-to MICHAEL YOUNG message dated "Tue, 17 Jan 2012 15:51:00 -0600." Date: Tue, 17 Jan 2012 23:23:18 +0100 From: Jaap Akkerhuis X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (bartok.nlnetlabs.nl [127.0.0.1]); Tue, 17 Jan 2012 23:23:19 +0100 (CET) X-Mailman-Approved-At: Tue, 17 Jan 2012 14:25:34 -0800 Subject: Re: [provreg] Changes we'd make to 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: Tue, 17 Jan 2012 22:23:22 -0000 Sure, you can notify registrars all you want,that doesn't mean they will or are required to do anything about it. On the other hand, if they don't choose to continue to leave contact objects around for years, not linked to anything (domains or other objects), then it's reasonable for a registry to have a policy that allows them to declare them abandoned and clean them up. It might even be required to do so. If I remember well, the Dutch Data Protection Authority requires that old (privacy related) data which is superfluous should be removed after 7 years. Something like that. There are likely similar rules under different jurisdictions. jaap From ajs@anvilwalrusden.com Tue Jan 17 14:31:28 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1CE21F8483 for ; Tue, 17 Jan 2012 14:31:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WN4fsxR9ie7y for ; Tue, 17 Jan 2012 14:31:28 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 0A92E21F847E for ; Tue, 17 Jan 2012 14:31:27 -0800 (PST) Received: from mail.yitter.info (nat-02-mht.dyndns.com [216.146.45.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 271741ECB420 for ; Tue, 17 Jan 2012 22:31:27 +0000 (UTC) Date: Tue, 17 Jan 2012 17:31:25 -0500 From: Andrew Sullivan To: provreg@ietf.org Message-ID: <20120117223125.GL2221@mail.yitter.info> References: <20120117220710.GK2221@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [provreg] Changes we'd make to 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: Tue, 17 Jan 2012 22:31:28 -0000 On Tue, Jan 17, 2012 at 04:21:08PM -0600, MICHAEL YOUNG wrote: > Yes we would, however the poll queue approach is a LOT of chatter even if > you clean it out periodically like some registries do. Please read again the section of RFC 5730 I quoted. There is no requirement that you put in a poll queue entry for each of these changes. That's actually the point of that passage. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From michael@mwyoung.ca Tue Jan 17 14:35:40 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 607A21F0C49 for ; Tue, 17 Jan 2012 14:35:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.279 X-Spam-Level: X-Spam-Status: No, score=-3.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CIfX-fGtJTU for ; Tue, 17 Jan 2012 14:35:40 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id E00CE1F0C35 for ; Tue, 17 Jan 2012 14:35:39 -0800 (PST) Received: by iaae16 with SMTP id e16so12076174iaa.31 for ; Tue, 17 Jan 2012 14:35:39 -0800 (PST) Received: by 10.50.76.225 with SMTP id n1mr19670922igw.11.1326839739445; Tue, 17 Jan 2012 14:35:39 -0800 (PST) Received: from [192.168.0.43] (174-155-52-17.pools.spcsdns.net. [174.155.52.17]) by mx.google.com with ESMTPS id b20sm81771229ibj.7.2012.01.17.14.35.28 (version=SSLv3 cipher=OTHER); Tue, 17 Jan 2012 14:35:38 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Tue, 17 Jan 2012 16:35:15 -0600 From: MICHAEL YOUNG To: Christopher Browne Message-ID: Thread-Topic: [provreg] Changes we'd make to EPP 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] Changes we'd make to 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: Tue, 17 Jan 2012 22:35:40 -0000 Interesting, you'd have to ask the accountants about it, they do like precise allocations :-) Michael Young On 12-01-17 4:26 PM, "Christopher Browne" wrote: >On Tue, Jan 17, 2012 at 5:04 PM, MICHAEL YOUNG wrote: >> Charging against objects assumes declaring a billing period and >>addressing >> deferred revenues. Yes it would work but its expensive since it hits a >> lot of downstream billing related systems. > >Maybe, if you try to bill it in a really detailed way against the objects. > >What I imagine is better is to be very much NOT detailed about it, to >NOT try to tie fees to individual objects, rather, charging round >amounts for ranges. > >"Dear Registrar: >On the evaluation date for this quarter, you had 5430 unlinked >contacts. See your reports for a list. >We charge $250 for storing 1000 to 10000 unused contacts, $500 for >10000 to 100000, and bulk storage of over 100000 contacts will be >billed $2500 per quarter for each 100000. >Your bill, for 5430 unused contacts, is $250." > >What is most preferable is to never need to issue a bill for this, as >dead, unvaluable objects get cleaned out before the evaluation date. From michael@mwyoung.ca Tue Jan 17 14:39:02 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8D5E1F0C4A for ; Tue, 17 Jan 2012 14:39:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.353 X-Spam-Level: X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[AWL=-0.714, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbItHGz5O-dy for ; Tue, 17 Jan 2012 14:39:02 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 522D71F0C35 for ; Tue, 17 Jan 2012 14:38:55 -0800 (PST) Received: by obbwc12 with SMTP id wc12so3869727obb.31 for ; Tue, 17 Jan 2012 14:38:54 -0800 (PST) Received: by 10.50.222.193 with SMTP id qo1mr19714329igc.22.1326839933817; Tue, 17 Jan 2012 14:38:53 -0800 (PST) Received: from [192.168.0.43] (174-155-52-17.pools.spcsdns.net. [174.155.52.17]) by mx.google.com with ESMTPS id py4sm33054654igc.2.2012.01.17.14.38.52 (version=SSLv3 cipher=OTHER); Tue, 17 Jan 2012 14:38:53 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Tue, 17 Jan 2012 16:38:48 -0600 From: MICHAEL YOUNG To: Andrew Sullivan , Message-ID: Thread-Topic: [provreg] Changes we'd make to EPP In-Reply-To: <20120117223125.GL2221@mail.yitter.info> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [provreg] Changes we'd make to 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: Tue, 17 Jan 2012 22:39:03 -0000 That leaves you with out of band, why is that better? Michael Young On 12-01-17 4:31 PM, "Andrew Sullivan" wrote: >On Tue, Jan 17, 2012 at 04:21:08PM -0600, MICHAEL YOUNG wrote: >> Yes we would, however the poll queue approach is a LOT of chatter even >>if >> you clean it out periodically like some registries do. > >Please read again the section of RFC 5730 I quoted. There is no >requirement that you put in a poll queue entry for each of these >changes. That's actually the point of that passage. > >Best, > >A >-- >Andrew Sullivan >ajs@anvilwalrusden.com >_______________________________________________ >provreg mailing list >provreg@ietf.org >https://www.ietf.org/mailman/listinfo/provreg From jim@rfc1035.com Tue Jan 17 15:06:22 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543E921F8441 for ; Tue, 17 Jan 2012 15:06:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eotsjWitGVHR for ; Tue, 17 Jan 2012 15:06:21 -0800 (PST) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABB221F843F for ; Tue, 17 Jan 2012 15:06:21 -0800 (PST) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) by shaun.rfc1035.com (Postfix) with ESMTP id 77BE0CBC44C; Tue, 17 Jan 2012 23:06:18 +0000 (GMT) Message-Id: From: Jim Reid To: Jaap Akkerhuis In-Reply-To: <201201172223.q0HMNI7f041767@bartok.nlnetlabs.nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 17 Jan 2012 23:06:18 +0000 References: <201201172223.q0HMNI7f041767@bartok.nlnetlabs.nl> X-Mailer: Apple Mail (2.936) Cc: "provreg@ietf.org" Subject: Re: [provreg] hooks for purging stale contact data X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 23:06:22 -0000 On 17 Jan 2012, at 22:23, Jaap Akkerhuis wrote: > If I remember well, the Dutch Data Protection Authority requires > that old (privacy related) data which is superfluous should be > removed after 7 years. Something like that. > > There are likely similar rules under different jurisdictions. Yup. IIRC it's the fifth principle of the EU Directive that Personal Data can't be kept or processed for longer than is necessary. This will be enacted in the national Data Protection law for each EU member state. The directive's principles may well underpin legislation in other parts of the world too. So some sort of timer for contact objects could be useful. I would have thought though that contact objects would automagically get deleted from the registry whenever their reference count from domain objects and the like dropped to zero. From ajs@anvilwalrusden.com Tue Jan 17 17:25:55 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E78C1F0C4C for ; Tue, 17 Jan 2012 17:25:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LhNA47pnyhH for ; Tue, 17 Jan 2012 17:25:54 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id ADCD31F0C35 for ; Tue, 17 Jan 2012 17:25:54 -0800 (PST) Received: from mail.yitter.info (unknown [100.44.91.115]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 9C9B61ECB420 for ; Wed, 18 Jan 2012 01:25:53 +0000 (UTC) Date: Tue, 17 Jan 2012 20:25:49 -0500 From: Andrew Sullivan To: provreg@ietf.org Message-ID: <20120118012549.GA3123@mail.yitter.info> References: <20120117223125.GL2221@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [provreg] Changes we'd make to 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, 18 Jan 2012 01:25:55 -0000 On Tue, Jan 17, 2012 at 04:38:48PM -0600, MICHAEL YOUNG wrote: > That leaves you with out of band, why is that better? Perhaps because EPP is badly tailored for bulk operations. I can think of ways in which it might have been otherwise, but the WG decided not to go that way. Since the protocol is poorly adapted to such operations, why try to force them in there? Or, put it another way: EPP is by no means the only relationship between an EPP repository operator and the clients: much of the system depends on pre-existing relationships anyway. Therefore, it seems at least as good to use those other communication channels for bulk operations as to add features to EPP for this. I am not saying that it is better or worse; but that there are other options, and before one is going to change deployed systems to deal with new desired behaviour, one needs an argument that alterations to those deployed systems is the right approach to satisfy the desire. A -- Andrew Sullivan ajs@anvilwalrusden.com From michael@mwyoung.ca Tue Jan 17 17:53:11 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C2221F861D for ; Tue, 17 Jan 2012 17:53:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCY-OKvuHvC5 for ; Tue, 17 Jan 2012 17:53:10 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA1621F861C for ; Tue, 17 Jan 2012 17:53:10 -0800 (PST) Received: by yenr11 with SMTP id r11so2344708yen.31 for ; Tue, 17 Jan 2012 17:53:08 -0800 (PST) Received: by 10.236.181.198 with SMTP id l46mr28800303yhm.40.1326851588826; Tue, 17 Jan 2012 17:53:08 -0800 (PST) Received: from [172.16.7.24] ([12.71.212.226]) by mx.google.com with ESMTPS id r1sm39858019yhh.14.2012.01.17.17.53.06 (version=SSLv3 cipher=OTHER); Tue, 17 Jan 2012 17:53:08 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Tue, 17 Jan 2012 19:53:01 -0600 From: MICHAEL YOUNG To: Andrew Sullivan , Message-ID: Thread-Topic: [provreg] Changes we'd make to EPP In-Reply-To: <20120118012549.GA3123@mail.yitter.info> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [provreg] Changes we'd make to 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, 18 Jan 2012 01:53:11 -0000 I completely agree with the balance you are talking about. No one wants to meddle lightly with deployed systems. However, maintaining standardization means (I think) keeping a protocol relevant to the use cases that evolve. We are talking about addressing bulk communications around an EPP object in this case - so I think its fair enough to consider short-comings in the protocol. EPP probably should have had more focus right from the start in addressing bulk operations. However, that thought aside, I still think that one could probably address the abandoned contact use case with an extension approach BUT I would really want to see that particular extension be standardized. There are always going to be 2 camps in these discussions, those who are more than willing to update existing EPP systems with newer protocol versions/features because they achieve a net benefit, and those whose existing implementations do a good enough job and don't want to incur the cost or anticipated risk. It's a balance between the two positions, always, but I think its safe to say we had better be prepared to work on the next iteration of EPP. There are a lot of new use cases coming down the pipe, as well as a backload of ccTLD use cases. If we don't address these, the protocol will eventually become irrelevant and after all the good work done here, I think it would be a shame to let it's usefulness erode. Ok done preaching for tonight. -M On 12-01-17 7:25 PM, "Andrew Sullivan" wrote: >On Tue, Jan 17, 2012 at 04:38:48PM -0600, MICHAEL YOUNG wrote: >> That leaves you with out of band, why is that better? > >Perhaps because EPP is badly tailored for bulk operations. I can >think of ways in which it might have been otherwise, but the WG >decided not to go that way. Since the protocol is poorly adapted to >such operations, why try to force them in there? > >Or, put it another way: EPP is by no means the only relationship >between an EPP repository operator and the clients: much of the system >depends on pre-existing relationships anyway. Therefore, it seems at >least as good to use those other communication channels for bulk >operations as to add features to EPP for this. I am not saying that >it is better or worse; but that there are other options, and before >one is going to change deployed systems to deal with new desired >behaviour, one needs an argument that alterations to those deployed >systems is the right approach to satisfy the desire. > >A > >-- >Andrew Sullivan >ajs@anvilwalrusden.com >_______________________________________________ >provreg mailing list >provreg@ietf.org >https://www.ietf.org/mailman/listinfo/provreg From brunner@nic-naa.net Tue Jan 17 18:02:49 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3811E11E808F for ; Tue, 17 Jan 2012 18:02:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtI1z33a3IzA for ; Tue, 17 Jan 2012 18:02:48 -0800 (PST) Received: from nic-naa.net (nic-naa.net [65.99.1.132]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFA511E8083 for ; Tue, 17 Jan 2012 18:02:48 -0800 (PST) Received: from limpet.local (cpe-67-255-2-48.twcny.res.rr.com [67.255.2.48]) by nic-naa.net (8.14.4/8.14.4) with ESMTP id q0HNOUOG057068 for ; Tue, 17 Jan 2012 18:24:30 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-ID: <4F162841.5040007@nic-naa.net> Date: Tue, 17 Jan 2012 21:02:41 -0500 From: Eric Brunner-Williams Organization: wampumpeag User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: provreg@ietf.org References: <20120117223125.GL2221@mail.yitter.info> <20120118012549.GA3123@mail.yitter.info> In-Reply-To: <20120118012549.GA3123@mail.yitter.info> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Changes we'd make to EPP X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ebw@abenaki.wabanaki.net List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 02:02:49 -0000 On 1/17/12 8:25 PM, Andrew Sullivan wrote: > Perhaps because EPP is badly tailored for bulk operations. I can > think of ways in which it might have been otherwise, but the WG > decided not to go that way. Yup. One way was in the XRP drafts. From ulrich@wisser.se Wed Jan 18 00:23:36 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00B2921F847E for ; Wed, 18 Jan 2012 00:23:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4o+lA7jccb1c for ; Wed, 18 Jan 2012 00:23:35 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1A37621F8476 for ; Wed, 18 Jan 2012 00:23:34 -0800 (PST) Received: by lagv3 with SMTP id v3so3202389lag.31 for ; Wed, 18 Jan 2012 00:23:33 -0800 (PST) Received: by 10.112.23.229 with SMTP id p5mr4972775lbf.21.1326875013788; Wed, 18 Jan 2012 00:23:33 -0800 (PST) Received: from laptopw-031.office.nic.se (gw.iis.se. [212.247.14.38]) by mx.google.com with ESMTPS id nu4sm17641520lab.4.2012.01.18.00.23.30 (version=SSLv3 cipher=OTHER); Wed, 18 Jan 2012 00:23:32 -0800 (PST) Message-ID: <4F168181.5000205@wisser.se> Date: Wed, 18 Jan 2012 09:23:29 +0100 From: Ulrich Wisser User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , provreg@ietf.org References: <4F073AB0.9080101@blacknight.com> <20120106185806.GA99133@crankycanuck.ca> <4F0AFF69.2090503@blacknight.com> <4F152D6E.1040203@wisser.se> <7297BA4A-C7C9-42DF-9D54-B5F4B50FE7CD@frobbit.se> In-Reply-To: <7297BA4A-C7C9-42DF-9D54-B5F4B50FE7CD@frobbit.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 08:23:36 -0000 On 17.01.12 17:19, Patrik F=E4ltstr=F6m wrote: > On 17 jan 2012, at 09:12, Ulrich Wisser wrote: > >> Hi, >> >> here at .Se we have done some extension to notify registrars of databa= se changes done by the registry. > > This is a question of definitions. The changes are made in the registry= due to operations requested by another registrar. I can not remind mysel= f of any operation originating in the registry. Ulrich do remind me if I = am wrong. =2ESE puts message in the poll queue for any change done to the objects i= n=20 the database. Transfer, expire, deactivate, delete, changes to status=20 (e.g. SERVER_HOLD on ADR), ... /Ulrich > > Patrik > >> Today I believe that we do not even need an extension for that. >> >> To notify the registrar of changes we could use >> obj:creData >> obj:infData >> obj:delete >> for the respective change. I realize that obj:delete is actually used = as command but there is nothing in the xsd file that prevents reusing it = as response. The absence of clTRID would indicate that the command was in= itiated by the registry. >> >> /Ulrich >> >> _______________________________________________ >> provreg mailing list >> provreg@ietf.org >> https://www.ietf.org/mailman/listinfo/provreg >> From marco.schrieck@internetx.de Wed Jan 18 01:00:06 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC7E21F8768 for ; Wed, 18 Jan 2012 01:00:06 -0800 (PST) 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_35=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+QQVJPndJvg for ; Wed, 18 Jan 2012 01:00:05 -0800 (PST) Received: from web4.internetx.de (gate2.mailgate.de [62.116.129.39]) by ietfa.amsl.com (Postfix) with ESMTP id 7515A21F8760 for ; Wed, 18 Jan 2012 01:00:04 -0800 (PST) Received: from Marco-Schriecks-MacBook-Pro-2.local (95-130-167-175.hsi.glasfaser-ostbayern.de [95.130.167.175] (may be forged)) (authenticated bits=0) by web4.internetx.de (8.13.8/8.13.8) with ESMTP id q0I8xx4w007632 for ; Wed, 18 Jan 2012 10:00:02 +0100 Message-ID: <4F168A0A.7070007@internetx.com> Date: Wed, 18 Jan 2012 09:59:54 +0100 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.25) Gecko/20111213 Lightning/1.0b2 Thunderbird/3.1.17 MIME-Version: 1.0 To: provreg@ietf.org References: <4F073AB0.9080101@blacknight.com> <20120106185806.GA99133@crankycanuck.ca> <4F0AFF69.2090503@blacknight.com> <4F152D6E.1040203@wisser.se> <7297BA4A-C7C9-42DF-9D54-B5F4B50FE7CD@frobbit.se> <4F168181.5000205@wisser.se> In-Reply-To: <4F168181.5000205@wisser.se> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 09:00:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi All, At 18.01.12 09:23, worte Ulrich Wisser: > > .SE puts message in the poll queue for any change done to the objects > in the database. Transfer, expire, deactivate, delete, changes to > status (e.g. SERVER_HOLD on ADR), ... We as registrar that have implemented many registry APIs must already handle this. This is done by other registries in the same kind. So there is only a map between this poll messages to existing method like "contact deleted by registry". If we have an out of band notification we have to manage extra credentials, protocol implementations, montoring, etc... This is from the operative and development view bad. My opinion is using the poll queue is good. The registry should do the GC periodically, to avoid many poll messages, maybe it can send many deleted contacts via one poll message with a maximum on contacts per message (eg 1000). Maybe there should also be a limit per day? Btw. a kind of bulk operation is still existing with obj:check where it is allowed to check multiple objects at once. Marco -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPFooKAAoJEN9yMHEBd2Hnz2oIAKeoaFda0TOPGN/TLkni7+l3 SWQpS9/s4PKwFpLP8NT/lMbQh+7KRBktxDHGgth+R5P0wljuSI4662dFQyXWa7ZS y8Rpsf/VTJcksdnzEIO142HgQbm92AVI1O5HXa9tkBdu5T9Z72mjfoEzH5IQtpTq IOXCj2L1XeCJJ6yyZwhNsMHIzehWIFEIZMJZvayU8DN08L6FYhVOHc49Dt6PEdSz bBsuwsFp+zZyL7IdoYHm6qX0/NxDBybiTmKDpK44GE9MS4q453UaV+FVdwE2s+Cs vKoOd+CTMg4SkGQ2tYf0ZNrvNetV+UKsFfu5UDOmXJDznffUY0J14IiLY6iVomk= =45Um -----END PGP SIGNATURE----- From cbbrowne@afilias.info Tue Jan 17 14:26:03 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE5C21F85F9 for ; Tue, 17 Jan 2012 14:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.103 X-Spam-Level: X-Spam-Status: No, score=-5.103 tagged_above=-999 required=5 tests=[AWL=0.540, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQyi0LlAW0N8 for ; Tue, 17 Jan 2012 14:26:03 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id ED9C621F85B6 for ; Tue, 17 Jan 2012 14:26:02 -0800 (PST) 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 1RnHTe-00041f-7j for provreg@ietf.org; Tue, 17 Jan 2012 22:26:02 +0000 Received: from mail-ww0-f52.google.com ([74.125.82.52]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1RnHTe-0007tp-3i for provreg@ietf.org; Tue, 17 Jan 2012 22:26:02 +0000 Received: by wgbdr12 with SMTP id dr12so3111029wgb.21 for ; Tue, 17 Jan 2012 14:26:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.180.106.33 with SMTP id gr1mr31957651wib.6.1326839161080; Tue, 17 Jan 2012 14:26:01 -0800 (PST) Received: by 10.180.97.70 with HTTP; Tue, 17 Jan 2012 14:26:01 -0800 (PST) In-Reply-To: References: Date: Tue, 17 Jan 2012 17:26:01 -0500 Message-ID: From: Christopher Browne To: MICHAEL YOUNG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 18 Jan 2012 01:15:21 -0800 Cc: provreg@ietf.org Subject: Re: [provreg] Changes we'd make to 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: Tue, 17 Jan 2012 22:26:03 -0000 On Tue, Jan 17, 2012 at 5:04 PM, MICHAEL YOUNG wrote: > Charging against objects assumes declaring a billing period and addressin= g > deferred revenues. =A0Yes it would work but its expensive since it hits a > lot of downstream billing related systems. Maybe, if you try to bill it in a really detailed way against the objects. What I imagine is better is to be very much NOT detailed about it, to NOT try to tie fees to individual objects, rather, charging round amounts for ranges. "Dear Registrar: On the evaluation date for this quarter, you had 5430 unlinked contacts. See your reports for a list. We charge $250 for storing 1000 to 10000 unused contacts, $500 for 10000 to 100000, and bulk storage of over 100000 contacts will be billed $2500 per quarter for each 100000. Your bill, for 5430 unused contacts, is $250." What is most preferable is to never need to issue a bill for this, as dead, unvaluable objects get cleaned out before the evaluation date. From paf@frobbit.se Tue Jan 17 16:33:27 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCEC21F86C4 for ; Tue, 17 Jan 2012 16:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bj9xge6tydzI for ; Tue, 17 Jan 2012 16:33:27 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id B7C5621F86C3 for ; Tue, 17 Jan 2012 16:33:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id D0B3212D63F9D; Wed, 18 Jan 2012 01:33:24 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilGEb-mBCPEi; Wed, 18 Jan 2012 01:33:24 +0100 (CET) Received: from [83.243.189.12] (unknown [213.184.192.106]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 90DDF12D63F9A; Wed, 18 Jan 2012 01:33:24 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <1E3AE212-407C-4962-8D34-B54E480746BB@flame.co.za> Date: Wed, 18 Jan 2012 01:33:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <79EE3909-0A69-4E93-8917-C2BFD927CB81@frobbit.se> References: <4F073AB0.9080101@blacknight.com> <20120106185806.GA99133@crankycanuck.ca> <9362808D-CEF9-44CD-B4FA-542D6788B7A9@frobbit.se> <4F152E28.6070503@wisser.se> <1E3AE212-407C-4962-8D34-B54E480746BB@flame.co.za> To: Theo Kramer X-Mailer: Apple Mail (2.1251.1) X-Mailman-Approved-At: Wed, 18 Jan 2012 01:15:21 -0800 Cc: provreg@ietf.org Subject: Re: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 00:33:27 -0000 On 17 jan 2012, at 19:55, Theo Kramer wrote: > On 17 Jan 2012, at 6:26 PM, Patrik F=E4ltstr=F6m wrote: >=20 >> On 17 jan 2012, at 09:15, Ulrich Wisser wrote: >>=20 >>> What is the incentive for the registrar to clean the registry = database? >>=20 >> Same as all contractual requirements registries have on their = registrars. >>=20 >=20 > So a clause could be that any unlinked contact over a certain age will = be deleted... No, if you do not do a gc now and then, we might revoke your registrar = accreditation. Or whatever. As I said, same as other contractual = agreements between registries and registrars. Patrik From ulrich@wisser.se Wed Jan 18 02:12:54 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C3F21F8777 for ; Wed, 18 Jan 2012 02:12:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9n85ELEKZ2X for ; Wed, 18 Jan 2012 02:12:53 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9020D21F8795 for ; Wed, 18 Jan 2012 02:12:53 -0800 (PST) Received: by lagv3 with SMTP id v3so3279465lag.31 for ; Wed, 18 Jan 2012 02:12:52 -0800 (PST) Received: by 10.112.32.9 with SMTP id e9mr5005955lbi.38.1326881572042; Wed, 18 Jan 2012 02:12:52 -0800 (PST) Received: from laptopw-031.office.nic.se (gw.iis.se. [212.247.14.38]) by mx.google.com with ESMTPS id fq5sm17875312lab.2.2012.01.18.02.12.49 (version=SSLv3 cipher=OTHER); Wed, 18 Jan 2012 02:12:50 -0800 (PST) Message-ID: <4F169B20.1020903@wisser.se> Date: Wed, 18 Jan 2012 11:12:48 +0100 From: Ulrich Wisser User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Gould, James" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "provreg@ietf.org" Subject: Re: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 10:12:54 -0000 James, I believe I've been a bit to vague on my proposal. I would of course=20 embed these answers in the part of the poll response.=20 5730 specifies that this can be done with , so=20 and should be possible too. This way at=20 least for create/update/renew/transfer should be covered by rfc 5730.=20 The problem is to determine if the message is in response to a former=20 request from the registrar or registry initiated. But that might not=20 even be so important. In any case the registry is letting the registrar=20 know that an object has been changed. And yes, the usage of is "creative". Unfortunately is is=20 no defined. But I certainly can get Command completed successfully; ack to dequeue 2000-06-08T22:00:00.0Z Transfer requested. 12345 ABC-12345 54321-XYZ to validate. So maybe we take that as "allowed by rfc 5730". /Ulrich > Ulrich, > > Can you provide a reference to the extension created by .SE for registr= y > changes for review? Using a command (obj:delete) in response to a comm= and > (poll) would not meet RFC 5730. Use of obj:creData I don't believe wou= ld > match the context. Use of obj:infData could work since it's the most > generic to cover any changes, but it wouldn't provide any specific > information on a garbage collection delete except for maybe text in the= > element (e.g. "deleted - orphaned" or something like that)= =2E > This is not clean but it wouldn=B9t require any new extensions or mappi= ngs. > > > > On 1/17/12 3:12 AM, "Ulrich Wisser" wrote: > >> Hi, >> >> here at .Se we have done some extension to notify registrars of databa= se >> changes done by the registry. Today I believe that we do not even need= >> an extension for that. >> >> To notify the registrar of changes we could use >> obj:creData >> obj:infData >> obj:delete >> for the respective change. I realize that obj:delete is actually used = as >> command but there is nothing in the xsd file that prevents reusing it = as >> response. The absence of clTRID would indicate that the command was >> initiated by the registry. >> >> /Ulrich >> >> _______________________________________________ >> provreg mailing list >> provreg@ietf.org >> https://www.ietf.org/mailman/listinfo/provreg > From ulrich@wisser.se Wed Jan 18 02:17:56 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5A3321F85F6 for ; Wed, 18 Jan 2012 02:17:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Zw26aX1oJ-t for ; Wed, 18 Jan 2012 02:17:55 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8C34321F85F7 for ; Wed, 18 Jan 2012 02:17:55 -0800 (PST) Received: by lagv3 with SMTP id v3so3283846lag.31 for ; Wed, 18 Jan 2012 02:17:54 -0800 (PST) Received: by 10.112.98.132 with SMTP id ei4mr5424661lbb.5.1326881874533; Wed, 18 Jan 2012 02:17:54 -0800 (PST) Received: from laptopw-031.office.nic.se (gw.iis.se. [212.247.14.38]) by mx.google.com with ESMTPS id ix6sm10442721lab.11.2012.01.18.02.17.52 (version=SSLv3 cipher=OTHER); Wed, 18 Jan 2012 02:17:53 -0800 (PST) Message-ID: <4F169C4F.4020004@wisser.se> Date: Wed, 18 Jan 2012 11:17:51 +0100 From: Ulrich Wisser User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Gould, James" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "provreg@ietf.org" Subject: Re: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 10:17:56 -0000 Sorry forgot the pointer to our extension: https://www.iis.se/en/domaner/bli-registrar/epp Here you find our extension, manual and some other EPP stuff. The extensions defines some tags with action in=20 create/update/delete/transfer. Inside these tags we embed = etc. But I believe that the extra tags are not needed. /Ulrich Am 17.01.12 15:01, schrieb Gould, James: > Ulrich, > > Can you provide a reference to the extension created by .SE for registr= y > changes for review? Using a command (obj:delete) in response to a comm= and > (poll) would not meet RFC 5730. Use of obj:creData I don't believe wou= ld > match the context. Use of obj:infData could work since it's the most > generic to cover any changes, but it wouldn't provide any specific > information on a garbage collection delete except for maybe text in the= > element (e.g. "deleted - orphaned" or something like that)= =2E > This is not clean but it wouldn=B9t require any new extensions or mappi= ngs. > > > > > -- > > JG > > > > James Gould > Principal Software Engineer > jgould@Verisign.com > > 703-948-3271 (Office) > 12061 Bluemont Way > Reston, VA 20190 > VerisignInc.com > > > > > > > > On 1/17/12 3:12 AM, "Ulrich Wisser" wrote: > >> Hi, >> >> here at .Se we have done some extension to notify registrars of databa= se >> changes done by the registry. Today I believe that we do not even need= >> an extension for that. >> >> To notify the registrar of changes we could use >> obj:creData >> obj:infData >> obj:delete >> for the respective change. I realize that obj:delete is actually used = as >> command but there is nothing in the xsd file that prevents reusing it = as >> response. The absence of clTRID would indicate that the command was >> initiated by the registry. >> >> /Ulrich >> >> _______________________________________________ >> provreg mailing list >> provreg@ietf.org >> https://www.ietf.org/mailman/listinfo/provreg > From keith@blacknight.com Wed Jan 18 03:10:53 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5595221F87DE for ; Wed, 18 Jan 2012 03:10:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.625 X-Spam-Level: X-Spam-Status: No, score=-3.625 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waP39GL-Je3J for ; Wed, 18 Jan 2012 03:10:33 -0800 (PST) Received: from relay1.blacknight.com (relay1.blacknight.com [78.153.203.204]) by ietfa.amsl.com (Postfix) with ESMTP id E340C21F8642 for ; Wed, 18 Jan 2012 03:10:07 -0800 (PST) Received: from hegemon.blacknight.ie (hegemon.blacknight.ie [81.17.243.239]) by relay1.blacknight.com (Postfix) with ESMTP id C4C8135C216 for ; Wed, 18 Jan 2012 11:10:05 +0000 (GMT) Message-ID: <4F16A88D.3050902@blacknight.com> Date: Wed, 18 Jan 2012 11:10:05 +0000 From: Keith Gaughan Organization: Blacknight Internet Solutions User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: provreg@ietf.org References: <4F073AB0.9080101@blacknight.com> <20120106185806.GA99133@crankycanuck.ca> <9362808D-CEF9-44CD-B4FA-542D6788B7A9@frobbit.se> <4F152E28.6070503@wisser.se> <444E3664-43C2-457B-BFD6-49E1B66CA14F@frobbit.se> In-Reply-To: <444E3664-43C2-457B-BFD6-49E1B66CA14F@frobbit.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 11:10:53 -0000 On 17/01/12 16:29, Patrik Fltstrm wrote: > On 17 jan 2012, at 09:48, Theo Kramer wrote: > >> I can see none. Garbage collection is a function of registry maintenance imo. > > A registry can not know if an existing contact record is to be connected to a > domain name that is to be created, as by definition contact records must exist > with the registry that is not connected to any domain object. Those registries that already do garbage collection (.fr comes to mind immediately) have rules on when garbage collection happens. In their case, it's six months of inactivity on the contact. Besides, I'm proposing a (contact) garbage collection mechanism for the benefit registries, not registrars. It has a secondary benefit for registrars in that it gives a standard mechanism for those registries that wish to do garbage collection to notify registrars of the pending deletion of object. The data management needs of a registry can get quite unwieldy. Moreover, certain countries have data retention laws that affect how long a registry might be able to legally hold on to data that they don't actually have a reason for retaining. In both cases, and those are far from the only ones, it ought to be possible for a registry to perform garbage collection on effectively dead unlinked objects, just so long as the registrar who created them receives notification. An open question is when the the registrar should receive notification. I think the notification ought to be a notification that the objects are due to be deleted, maybe the day before the object is due to be purged, as this would give the registrar an opportunity to clean up on their end to avoid situations such as the one you raised. K. -- Keith Gaughan, Senior 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 Wed Jan 18 03:14:01 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2FD321F8715 for ; Wed, 18 Jan 2012 03:14:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.624 X-Spam-Level: X-Spam-Status: No, score=-3.624 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFNemVwy0FRO for ; Wed, 18 Jan 2012 03:14:00 -0800 (PST) Received: from relay1.blacknight.com (relay1.blacknight.com [78.153.203.204]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC7D21F8711 for ; Wed, 18 Jan 2012 03:14:00 -0800 (PST) Received: from hegemon.blacknight.ie (hegemon.blacknight.ie [81.17.243.239]) by relay1.blacknight.com (Postfix) with ESMTP id 6DF4E35C21B for ; Wed, 18 Jan 2012 11:13:59 +0000 (GMT) Message-ID: <4F16A976.9090403@blacknight.com> Date: Wed, 18 Jan 2012 11:13:58 +0000 From: Keith Gaughan Organization: Blacknight Internet Solutions User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: provreg@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 11:14:01 -0000 On 17/01/12 16:58, MICHAEL YOUNG wrote: > I think there needs to be a reasonable period where you can determine a > contact object has been abandoned. Is there really a point to leaving > contacts around that haven't been associated for years? AFNIC (.fr, &c.) do garbage collection already, albeit without notifications. Their policy is that a contact that has been unlinked for six continuous months is purged. Is a reasonable policy, although from a registrar's perspective, a notification on the message queue would be nice. > That's certainly the case in the older EPP registries - contact bloat. > Where this gets to be annoying is in escrow deposits - costs money for no > added value to anyone. Why bloat up escrow deposits with a bunch of dead > contacts in the first place? I'm in full an total agreement, not to mention the legal implications as far as data retention laws go. K. -- Keith Gaughan, Senior 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 Wed Jan 18 03:19:15 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866DE21F873C for ; Wed, 18 Jan 2012 03:19:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.623 X-Spam-Level: X-Spam-Status: No, score=-3.623 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azt9+Snvlhhe for ; Wed, 18 Jan 2012 03:19:14 -0800 (PST) Received: from relay1.blacknight.com (relay1.blacknight.com [78.153.203.204]) by ietfa.amsl.com (Postfix) with ESMTP id 219CD21F8737 for ; Wed, 18 Jan 2012 03:18:58 -0800 (PST) Received: from hegemon.blacknight.ie (hegemon.blacknight.ie [81.17.243.239]) by relay1.blacknight.com (Postfix) with ESMTP id 5AEFE35C21B for ; Wed, 18 Jan 2012 11:18:58 +0000 (GMT) Message-ID: <4F16AAA2.9010209@blacknight.com> Date: Wed, 18 Jan 2012 11:18:58 +0000 From: Keith Gaughan Organization: Blacknight Internet Solutions User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: provreg@ietf.org References: <187D6861-35D1-4B68-A72A-D2E3499039A7@frobbit.se> In-Reply-To: <187D6861-35D1-4B68-A72A-D2E3499039A7@frobbit.se> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 11:19:15 -0000 On 17/01/12 17:28, Patrik Fältström wrote: > The problem here is that once again registries talk about "bloat" and > "increased cost" and because of that want to do operations that imply > inconsistencies with registrars databases, while registrars argue that > for them it is not a problem at all with many contact records and that > it is worse if registries make commands that have implications in > their database. Keep in mind that this is actually a proposal coming from an employee of a registrar! > Is this not a clear sign we must be better on working together? > > My suggestion was because of that that registrars make the gc command > and registries report back what was deleted. I personally would prefer it happen automatically as the registry feels is necessary, but that the notification is sent out at least a day before the purge occurs. K. -- Keith Gaughan, Senior 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 Wed Jan 18 03:31:07 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7FA21F87FA for ; Wed, 18 Jan 2012 03:31:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.622 X-Spam-Level: X-Spam-Status: No, score=-3.622 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpKi3xTAdZT8 for ; Wed, 18 Jan 2012 03:31:06 -0800 (PST) Received: from relay1.blacknight.com (relay1.blacknight.com [78.153.203.204]) by ietfa.amsl.com (Postfix) with ESMTP id 8517C21F87F4 for ; Wed, 18 Jan 2012 03:31:06 -0800 (PST) Received: from hegemon.blacknight.ie (hegemon.blacknight.ie [81.17.243.239]) by relay1.blacknight.com (Postfix) with ESMTP id 95DF135C276 for ; Wed, 18 Jan 2012 11:31:05 +0000 (GMT) Message-ID: <4F16AD79.4080002@blacknight.com> Date: Wed, 18 Jan 2012 11:31:05 +0000 From: Keith Gaughan Organization: Blacknight Internet Solutions User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: provreg@ietf.org References: <4F15B9FB.1050208@knipp.de> In-Reply-To: <4F15B9FB.1050208@knipp.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Changes we'd make to 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, 18 Jan 2012 11:31:07 -0000 On 17/01/12 18:12, Klaus Malorny wrote: > - I just had an insane idea to avoid poll messages about the deletion of > contacts -- you may forget it just after you have finished > reading it (or even before): One could introduce an expiration date for > contacts. If a contact is created, it is set to one year in the future. > As long as the contact is used at least by one object, it is automatically > renewed, let's say a quarter before it expires. The registrar can either > track the expiration date (and perform a contact:info/check to check > its existence in case his recorded expiration date is in the past) > or simply create new contacts, as many registrars do it today. > For the registry, if the contact passes its expiration date, it is > simply deleted by the registry without any further fuss. That's effectively what AFNIC do with their GC mechanism, but the lack of notification is a bit of an irritation because it's easy for the registrar to lose track of when the contact actually expires. The notification--which can be ignored if the registrar wishes--means that the registry's exact policy on when GC happens has no effect on the registrar, which is very much advantageous. I think it's best to think of *:check commands as putting a stay of execution on the object, given they're essentially a signal that the registrar wishes to use the object within a very short amount of time. If a registrar performs a *:check and the registrar responds that said GC-able object exists, that ought to guarantee that the the object is still around for enough time for it to be used, maybe fifteen minutes. K. -- Keith Gaughan, Senior 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 Wed Jan 18 03:37:10 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDC721F86CA for ; Wed, 18 Jan 2012 03:37:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.622 X-Spam-Level: X-Spam-Status: No, score=-3.622 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNs8wL3b-7CL for ; Wed, 18 Jan 2012 03:37:09 -0800 (PST) Received: from relay1.blacknight.com (relay1.blacknight.com [78.153.203.204]) by ietfa.amsl.com (Postfix) with ESMTP id 285BE21F86B8 for ; Wed, 18 Jan 2012 03:37:05 -0800 (PST) Received: from hegemon.blacknight.ie (hegemon.blacknight.ie [81.17.243.239]) by relay1.blacknight.com (Postfix) with ESMTP id 1F61D35C35C for ; Wed, 18 Jan 2012 11:37:05 +0000 (GMT) Message-ID: <4F16AEE0.1000508@blacknight.com> Date: Wed, 18 Jan 2012 11:37:04 +0000 From: Keith Gaughan Organization: Blacknight Internet Solutions User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: provreg@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Changes we'd make to 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, 18 Jan 2012 11:37:10 -0000 On 17/01/12 20:59, Gould, James wrote: > I believe this is getting a bit complex and convoluted. Contacts are > first class objects in themselves as defined by RFC 5733, so they could be > created at any point with no relation to a domain. Whether a registry supports it is entirely down to their policy, and they can declare that they support the extension in their greeting document. Whether an object is first class or not doesn't really effect whether it may expire. > I don't believe the > Registry should take any action to garbage collect them based on the lack > of references from other objects like domains. In systems like DotName a > contact can be linked to other types of objects (emailfwd, defreg, etc.), > so there is no hard dependency with being linked with a domain. Then in that case, the registry need not support the extension, in which case the objects will hang around in the registry's systems until they're explicitly deleted. K. -- Keith Gaughan, Senior 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 Wed Jan 18 03:42:38 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D041A21F87C9 for ; Wed, 18 Jan 2012 03:42:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.621 X-Spam-Level: X-Spam-Status: No, score=-3.621 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YobUKlISQM3r for ; Wed, 18 Jan 2012 03:42:38 -0800 (PST) Received: from relay1.blacknight.com (relay1.blacknight.com [78.153.203.204]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABC121F87D2 for ; Wed, 18 Jan 2012 03:42:37 -0800 (PST) Received: from hegemon.blacknight.ie (hegemon.blacknight.ie [81.17.243.239]) by relay1.blacknight.com (Postfix) with ESMTP id 1366F35C363 for ; Wed, 18 Jan 2012 11:42:29 +0000 (GMT) Message-ID: <4F16B024.9020503@blacknight.com> Date: Wed, 18 Jan 2012 11:42:28 +0000 From: Keith Gaughan Organization: Blacknight Internet Solutions User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: provreg@ietf.org References: <20120117220710.GK2221@mail.yitter.info> In-Reply-To: <20120117220710.GK2221@mail.yitter.info> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Changes we'd make to 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, 18 Jan 2012 11:42:38 -0000 On 17/01/12 22:07, Andrew Sullivan wrote: > You'd need an extension or a new contact mapping, though. I was the one who proposed the idea originally, and I discussed that. I think the extension route is best, mainly because it allows the notifications to be general and doesn't require the update on an existing RFC. -- Keith Gaughan, Senior 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 Wed Jan 18 04:01:59 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 422BE21F8723 for ; Wed, 18 Jan 2012 04:01:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.62 X-Spam-Level: X-Spam-Status: No, score=-3.62 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1jaqI-H+DMM for ; Wed, 18 Jan 2012 04:01:58 -0800 (PST) Received: from relay1.blacknight.com (relay1.blacknight.com [78.153.203.204]) by ietfa.amsl.com (Postfix) with ESMTP id 8A52921F8609 for ; Wed, 18 Jan 2012 04:01:58 -0800 (PST) Received: from hegemon.blacknight.ie (hegemon.blacknight.ie [81.17.243.239]) by relay1.blacknight.com (Postfix) with ESMTP id 701CC35C2AD for ; Wed, 18 Jan 2012 12:01:57 +0000 (GMT) Message-ID: <4F16B4B4.5000303@blacknight.com> Date: Wed, 18 Jan 2012 12:01:56 +0000 From: Keith Gaughan Organization: Blacknight Internet Solutions User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: provreg@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Changes we'd make to 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, 18 Jan 2012 12:01:59 -0000 On 17/01/12 22:21, MICHAEL YOUNG wrote: >> You'd need an extension or a new contact mapping, though. > > Yes we would, however the poll queue approach is a LOT of chatter even if > you clean it out periodically like some registries do. Its clunky. More to > the bigger question of doing work or not doing work, EPP has been rolling > for 10 years, I think we could suffer a few well thought out improvements > at this point. When it happens is up to the registry: they can make it as chatty or not as they like. These would, after all, be batch notifications: it doesn't make much sense to send a separate notification for each and every separate (pending) deletion. Using the queue need not be chatty so long as registries choose when they send them in a suitable manner. K. -- Keith Gaughan, Senior 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 Wed Jan 18 04:11:26 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBA0E21F851C for ; Wed, 18 Jan 2012 04:11:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.619 X-Spam-Level: X-Spam-Status: No, score=-3.619 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfoUsnsxl6Kx for ; Wed, 18 Jan 2012 04:11:25 -0800 (PST) Received: from relay1.blacknight.com (relay1.blacknight.com [78.153.203.204]) by ietfa.amsl.com (Postfix) with ESMTP id AAAAE21F84C8 for ; Wed, 18 Jan 2012 04:11:25 -0800 (PST) Received: from hegemon.blacknight.ie (hegemon.blacknight.ie [81.17.243.239]) by relay1.blacknight.com (Postfix) with ESMTP id C5D8B35C301 for ; Wed, 18 Jan 2012 12:11:24 +0000 (GMT) Message-ID: <4F16B6EC.5010804@blacknight.com> Date: Wed, 18 Jan 2012 12:11:24 +0000 From: Keith Gaughan Organization: Blacknight Internet Solutions User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: provreg@ietf.org References: <4F169B20.1020903@wisser.se> In-Reply-To: <4F169B20.1020903@wisser.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Changes we'd make to EPP, was Re: Domain check in draft-obispo-epp-idn-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 12:11:26 -0000 On 18/01/12 10:12, Ulrich Wisser wrote: > James, > > I believe I've been a bit to vague on my proposal. I would of course embed > these answers in the part of the poll response. 5730 specifies > that this can be done with , so and > should be possible too. This way at least for > create/update/renew/transfer should be covered by rfc 5730. The problem is to > determine if the message is in response to a former request from the registrar > or registry initiated. But that might not even be so important. In any case > the registry is letting the registrar know that an object has been changed. > > And yes, the usage of is "creative". Unfortunately is is no > defined. My one objection to that is that it doesn't really allow for batch notifications: there's a separate notification sent out for each and every object being garbage collected, which is chatty. Deletion notifications are something, just like with availability checks, that are amenable to batching, and, in fact, benefit from being batched, so batching is a win. K. -- Keith Gaughan, Senior Developer PGP/GPG key ID: 3E896381 Blacknight Internet Solutions Ltd. 12A Barrowside Business Park, Carlow, Ireland Registered in Ireland, Company No.: 370845 From shollenbeck@verisign.com Wed Jan 18 04:27:48 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1BF821F87D2 for ; Wed, 18 Jan 2012 04:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEHUrR14JAtq for ; Wed, 18 Jan 2012 04:27:48 -0800 (PST) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by ietfa.amsl.com (Postfix) with ESMTP id 180AD21F87BD for ; Wed, 18 Jan 2012 04:27:47 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKTxa6trRc3izDs+dpMwGN0wyfr+yIvRGB@postini.com; Wed, 18 Jan 2012 04:27:48 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q0ICRV53006808; Wed, 18 Jan 2012 07:27:33 -0500 Received: from BRN1WNEXCAS01.vcorp.ad.vrsn.com ([10.173.152.205]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Jan 2012 07:27:31 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.01.0323.003; Wed, 18 Jan 2012 07:27:30 -0500 From: "Hollenbeck, Scott" To: MICHAEL YOUNG , "provreg@ietf.org" Thread-Topic: [provreg] Changes we'd make to EPP Thread-Index: AQHM1UOQ6D+I/efY2kewKQWAlaNGyZYRS7gA//+/eACAAGJNAIAABIUAgAAD5wCAAALfgIAAAhAAgAAuqoCAAAeagIAAV7Zw Date: Wed, 18 Jan 2012 12:27:30 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D57D69A@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20120118012549.GA3123@mail.yitter.info> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 18 Jan 2012 12:27:31.0492 (UTC) FILETIME=[8C93CE40:01CCD5DC] Subject: Re: [provreg] Changes we'd make to 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, 18 Jan 2012 12:27:49 -0000 > -----Original Message----- > From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On > Behalf Of MICHAEL YOUNG > Sent: Tuesday, January 17, 2012 8:53 PM > To: Andrew Sullivan; provreg@ietf.org > Subject: Re: [provreg] Changes we'd make to EPP >=20 >=20 > I completely agree with the balance you are talking about. No one wants > to > meddle lightly with deployed systems. However, maintaining > standardization means (I think) keeping a protocol relevant to the use > cases that evolve. We are talking about addressing bulk communications > around an EPP object in this case - so I think its fair enough to > consider > short-comings in the protocol. EPP probably should have had more focus > right from the start in addressing bulk operations. The use case for bulk operations *was* carefully considered - and not selec= ted for inclusion in the core protocol. It's now 10 years later and no one = has written an extension draft that describes that functionality. Maybe som= eone who feels the need should think about documenting an approach in an I-= D. I was going to suggest that text from the expired XRP draft(s) might be a g= ood place to start, but I don't see the words "bulk" or "batch" anywhere in= draft-brunner-xrp-00. Maybe Eric can explain how the concept was addressed= . On a slightly different topic, all this debate about contact synchronizatio= n is making me laugh. Be careful what you wish for, thick registry proponen= ts! :) Scott From keith@blacknight.com Wed Jan 18 04:42:25 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F71521F8790 for ; Wed, 18 Jan 2012 04:42:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.619 X-Spam-Level: X-Spam-Status: No, score=-3.619 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-at5Lo2VCio for ; Wed, 18 Jan 2012 04:42:24 -0800 (PST) Received: from relay1.blacknight.com (relay1.blacknight.com [78.153.203.204]) by ietfa.amsl.com (Postfix) with ESMTP id A4C3921F8745 for ; Wed, 18 Jan 2012 04:42:24 -0800 (PST) Received: from hegemon.blacknight.ie (hegemon.blacknight.ie [81.17.243.239]) by relay1.blacknight.com (Postfix) with ESMTP id B4CF235C2F0 for ; Wed, 18 Jan 2012 12:42:22 +0000 (GMT) Message-ID: <4F16BE2E.5060108@blacknight.com> Date: Wed, 18 Jan 2012 12:42:22 +0000 From: Keith Gaughan Organization: Blacknight Internet Solutions User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: provreg@ietf.org References: <20120118012549.GA3123@mail.yitter.info> <831693C2CDA2E849A7D7A712B24E257F0D57D69A@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D57D69A@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Changes we'd make to 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, 18 Jan 2012 12:42:25 -0000 On 18/01/12 12:27, Hollenbeck, Scott wrote: > On a slightly different topic, all this debate about contact > synchronization is making me laugh. Be careful what you wish for, thick > registry proponents! I dunno... I prefer the hell of thick registries over the hell other registrar's WHOIS servers any day! -- Keith Gaughan, Senior Developer PGP/GPG key ID: 3E896381 Blacknight Internet Solutions Ltd. 12A Barrowside Business Park, Carlow, Ireland Registered in Ireland, Company No.: 370845 From shollenbeck@verisign.com Wed Jan 18 04:50:15 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2191B21F86C9 for ; Wed, 18 Jan 2012 04:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRzbEyz70oHy for ; Wed, 18 Jan 2012 04:50:14 -0800 (PST) Received: from exprod6og111.obsmtp.com (exprod6og111.obsmtp.com [64.18.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFCF21F86C5 for ; Wed, 18 Jan 2012 04:50:14 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob111.postini.com ([64.18.5.12]) with SMTP ID DSNKTxbABePsVpbT1iRQyKlnOd9arzY7KWpB@postini.com; Wed, 18 Jan 2012 04:50:14 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q0ICoDuo004671 for ; Wed, 18 Jan 2012 07:50:13 -0500 Received: from BRN1WNEXCAS01.vcorp.ad.vrsn.com ([10.173.152.205]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Jan 2012 07:50:13 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.01.0323.003; Wed, 18 Jan 2012 07:50:12 -0500 From: "Hollenbeck, Scott" To: "provreg@ietf.org" Thread-Topic: Standard Extensions Thread-Index: AczV37W4iCnZ4oZDR9SQ1tim3W6hqQ== Date: Wed, 18 Jan 2012 12:50:11 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {67AB64EF-295F-4576-BA0E-708E21A22645} x-cr-hashedpuzzle: ACrt AkLj BQ5p B7ds CrL1 Dsw1 FKVb FSW+ FWs6 Ft8I GmFY HmoU H7Uq IjG5 JsXY L810; 1; cAByAG8AdgByAGUAZwBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {67AB64EF-295F-4576-BA0E-708E21A22645}; cwBoAG8AbABsAGUAbgBiAGUAYwBrAEAAdgBlAHIAaQBzAGkAZwBuAC4AYwBvAG0A; Wed, 18 Jan 2012 12:50:09 GMT; UwB0AGEAbgBkAGEAcgBkACAARQB4AHQAZQBuAHMAaQBvAG4AcwA= 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: 18 Jan 2012 12:50:13.0232 (UTC) FILETIME=[B83CD700:01CCD5DF] Subject: [provreg] Standard Extensions X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 12:50:15 -0000 Let's assume for a moment that we have enough interest to form a working gr= oup focused on the development of a set of standard EPP extensions. If we h= ad to start writing a charter today, what functionality would people most l= ike to see included? If there really is interest I will offer to help us get organized. Scott From brunner@nic-naa.net Wed Jan 18 05:15:11 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2773F21F87F4 for ; Wed, 18 Jan 2012 05:15:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cp54yN+LJ5h7 for ; Wed, 18 Jan 2012 05:15:10 -0800 (PST) Received: from nic-naa.net (nic-naa.net [65.99.1.132]) by ietfa.amsl.com (Postfix) with ESMTP id 2F01121F87E8 for ; Wed, 18 Jan 2012 05:15:10 -0800 (PST) Received: from limpet.local (cpe-67-255-2-48.twcny.res.rr.com [67.255.2.48]) by nic-naa.net (8.14.4/8.14.4) with ESMTP id q0IAajJM061971 for ; Wed, 18 Jan 2012 05:36:45 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-ID: <4F16C5D7.80708@nic-naa.net> Date: Wed, 18 Jan 2012 08:15:03 -0500 From: Eric Brunner-Williams Organization: wampumpeag User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: provreg@ietf.org References: <20120118012549.GA3123@mail.yitter.info> <831693C2CDA2E849A7D7A712B24E257F0D57D69A@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D57D69A@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Changes we'd make to EPP X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ebw@abenaki.wabanaki.net List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 13:15:11 -0000 On 1/18/12 7:27 AM, Hollenbeck, Scott wrote: > I was going to suggest that text from the expired XRP draft(s) might be a good place to start, but I don't see the words "bulk" or "batch" anywhere in draft-brunner-xrp-00. Maybe Eric can explain how the concept was addressed. My mistake. The idea didn't make it into the XRP draft, but into the EPP Containter drafts. This memo documents how these generic object management operations are extended to hierarchies of objects, called container objects or Brunner-Williams Expires December 2002 [Page 2] ^L Internet-Draft EPP Container May 2002 containers. Eric From keith@blacknight.com Wed Jan 18 05:20:56 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F06D21F87A8 for ; Wed, 18 Jan 2012 05:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.618 X-Spam-Level: X-Spam-Status: No, score=-3.618 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYvTG9QG34v8 for ; Wed, 18 Jan 2012 05:20:56 -0800 (PST) Received: from relay1.blacknight.com (relay1.blacknight.com [78.153.203.204]) by ietfa.amsl.com (Postfix) with ESMTP id D53EF21F87A3 for ; Wed, 18 Jan 2012 05:20:55 -0800 (PST) Received: from hegemon.blacknight.ie (hegemon.blacknight.ie [81.17.243.239]) by relay1.blacknight.com (Postfix) with ESMTP id 36EE435C339 for ; Wed, 18 Jan 2012 13:20:51 +0000 (GMT) Message-ID: <4F16C732.1030409@blacknight.com> Date: Wed, 18 Jan 2012 13:20:50 +0000 From: Keith Gaughan Organization: Blacknight Internet Solutions User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: provreg@ietf.org References: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Standard Extensions X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 13:20:56 -0000 On 18/01/12 12:50, Hollenbeck, Scott wrote: > Let's assume for a moment that we have enough interest to form a working > group focused on the development of a set of standard EPP extensions. If > we had to start writing a charter today, what functionality would people > most like to see included? > > If there really is interest I will offer to help us get organized. I'm interested. I've already proposed the garbage collection mechanism and both James Gould and I have proposed a mechanism for registrars to get registry policy information, though I proposed it be done separately from EPP (though ultimately linked to EPP, and possibly listed in the greeting), and James proposed the use of an object mapping. Those two are things I personally would like to see developed, and I'm planning on writing up an I-D on the former at the very least. -- Keith Gaughan, Senior Developer PGP/GPG key ID: 3E896381 Blacknight Internet Solutions Ltd. 12A Barrowside Business Park, Carlow, Ireland Registered in Ireland, Company No.: 370845 From bruno.premont@restena.lu Wed Jan 18 05:36:07 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9101321F86D9 for ; Wed, 18 Jan 2012 05:36:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tcgAlIUESJV for ; Wed, 18 Jan 2012 05:36:06 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id B113A21F876F for ; Wed, 18 Jan 2012 05:36:06 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 6886C10A01 for ; Wed, 18 Jan 2012 14:36:05 +0100 (CET) Received: from pluto.restena.lu (pluto.restena.lu [IPv6:2001:a18:1:8:230:5ff:fefe:5152]) by smtprelay.restena.lu (Postfix) with ESMTPS id 5794D106C2 for ; Wed, 18 Jan 2012 14:36:05 +0100 (CET) Date: Wed, 18 Jan 2012 14:36:01 +0100 From: Bruno =?UTF-8?B?UHLDqW1vbnQ=?= To: provreg@ietf.org Message-ID: <20120118143601.084e8af7@pluto.restena.lu> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Organization: Fondation RESTENA X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.5; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/Vp8Uca2Bu.DZerlzpA8vYqE"; protocol="application/pgp-signature" X-Virus-Scanned: ClamAV Subject: Re: [provreg] Standard Extensions X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 13:36:07 -0000 --Sig_/Vp8Uca2Bu.DZerlzpA8vYqE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, 18 Jan 2012 12:50:11 Hollenbeck, Scott wrote: > Let's assume for a moment that we have enough interest to form a > working group focused on the development of a set of standard EPP > extensions. If we had to start writing a charter today, what > functionality would people most like to see included? >=20 > If there really is interest I will offer to help us get organized. Another extension that could be useful and was requested by one of our registrars would be for them to check their status. It would need: - their contact data, similar to aggregation of one or more contact objects [admin, tech, billing] - their credit balance (the most important information) it should be possible to add extra information such as soft/hard limits and possibly some forecast of probable future needs). - extra key/value pairs, preferably with a few pre-defined types (string, currency, number, array) for further information --=20 Bruno Pr=C3=A9mont Ing=C3=A9nieur syst=C3=A8me et d=C3=A9veloppements Fondation RESTENA 6, rue Coudenhove-Kalergi L-1359 Luxembourg T=C3=A9l: (+352) 424409 Fax: (+352) 422473 http://www.restena.lu http://www.dns.lu --Sig_/Vp8Uca2Bu.DZerlzpA8vYqE Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk8WysQACgkQc2cOy4nMX1bqtACgs5v9hhjcTOJYqYzxTCZqI1Um 3ZIAnjMka+jvYtAe7rbEAbHKL+C+6Tox =HXzU -----END PGP SIGNATURE----- --Sig_/Vp8Uca2Bu.DZerlzpA8vYqE-- From michael@mwyoung.ca Wed Jan 18 05:48:44 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D00B321F86DE for ; Wed, 18 Jan 2012 05:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXBox88R8ERy for ; Wed, 18 Jan 2012 05:48:42 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9E62B21F872A for ; Wed, 18 Jan 2012 05:48:42 -0800 (PST) Received: by yenl5 with SMTP id l5so162235yen.31 for ; Wed, 18 Jan 2012 05:48:40 -0800 (PST) Received: by 10.236.146.36 with SMTP id q24mr31864468yhj.85.1326894520431; Wed, 18 Jan 2012 05:48:40 -0800 (PST) Received: from [172.16.7.24] ([12.71.212.226]) by mx.google.com with ESMTPS id a24sm1639568ana.13.2012.01.18.05.48.39 (version=SSLv3 cipher=OTHER); Wed, 18 Jan 2012 05:48:39 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Wed, 18 Jan 2012 07:48:39 -0600 From: MICHAEL YOUNG To: "Hollenbeck, Scott" , "provreg@ietf.org" Message-ID: Thread-Topic: [provreg] Standard Extensions In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [provreg] Standard Extensions X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 13:48:44 -0000 Happy to help. Some things on my interest list: IDNs Launch Activities Possibly Trademark extensions and interactions with the Trademark Clearinghouse Possibly some work around compliance enforcement measures (in response to abuse) Michael Young On 12-01-18 6:50 AM, "Hollenbeck, Scott" wrote: >Let's assume for a moment that we have enough interest to form a working >group focused on the development of a set of standard EPP extensions. If >we had to start writing a charter today, what functionality would people >most like to see included? > >If there really is interest I will offer to help us get organized. > >Scott >_______________________________________________ >provreg mailing list >provreg@ietf.org >https://www.ietf.org/mailman/listinfo/provreg From michele@blacknight.ie Wed Jan 18 05:50:34 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A64121F8753 for ; Wed, 18 Jan 2012 05:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.692 X-Spam-Level: X-Spam-Status: No, score=-2.692 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TU1RsQIls4XL for ; Wed, 18 Jan 2012 05:50:32 -0800 (PST) Received: from exchange.blacknight.ie (exchange.blacknight.ie [81.17.243.252]) by ietfa.amsl.com (Postfix) with ESMTP id 308A521F87E0 for ; Wed, 18 Jan 2012 05:50:32 -0800 (PST) Received: from BKEXCHMBX01.blacknight.local ([fe80::76:af74:8c72:96ac]) by bkexchhubcas01.blacknight.local ([fe80::3ca9:6bf1:bd5d:24b%15]) with mapi id 14.02.0247.003; Wed, 18 Jan 2012 13:50:30 +0000 From: "Michele Neylon :: Blacknight" To: MICHAEL YOUNG Thread-Topic: [provreg] Standard Extensions Thread-Index: AczV37W4iCnZ4oZDR9SQ1tim3W6hqQACCweAAAAP8gA= Date: Wed, 18 Jan 2012 13:50:29 +0000 Message-ID: <9F5AE39D-4592-4F79-BBC1-DE852D2B230F@blacknight.ie> References: In-Reply-To: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [81.17.243.251] Content-Type: text/plain; charset="utf-8" Content-ID: <3B490FDE4B06814E992FB644DECBCD1C@blacknight.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "provreg@ietf.org" Subject: Re: [provreg] Standard Extensions X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 13:50:34 -0000 V2Fzbid0IHRoZXJlIGFscmVhZHkgc29tZSB3b3JrIGJlaW5nIGRvbmUgYnkgR2F2aW4gQnJvd24g YW5kIFdpbCBUYW4gb24gaGFuZGxpbmcgc3VucmlzZXMgZXRjPw0KDQoNCk9uIDE4IEphbiAyMDEy LCBhdCAxMzo0OCwgTUlDSEFFTCBZT1VORyB3cm90ZToNCg0KPiBIYXBweSB0byBoZWxwLiAgU29t ZSB0aGluZ3Mgb24gbXkgaW50ZXJlc3QgbGlzdDoNCj4gDQo+IElETnMNCj4gTGF1bmNoIEFjdGl2 aXRpZXMNCj4gUG9zc2libHkgVHJhZGVtYXJrIGV4dGVuc2lvbnMgYW5kIGludGVyYWN0aW9ucyB3 aXRoIHRoZSBUcmFkZW1hcmsNCj4gQ2xlYXJpbmdob3VzZQ0KPiBQb3NzaWJseSBzb21lIHdvcmsg YXJvdW5kIGNvbXBsaWFuY2UgZW5mb3JjZW1lbnQgbWVhc3VyZXMgKGluIHJlc3BvbnNlIHRvDQo+ IGFidXNlKQ0KPiANCj4gDQo+IE1pY2hhZWwgWW91bmcNCj4gDQo+IA0KPiANCj4gDQo+IE9uIDEy LTAxLTE4IDY6NTAgQU0sICJIb2xsZW5iZWNrLCBTY290dCIgPHNob2xsZW5iZWNrQHZlcmlzaWdu LmNvbT4gd3JvdGU6DQo+IA0KPj4gTGV0J3MgYXNzdW1lIGZvciBhIG1vbWVudCB0aGF0IHdlIGhh dmUgZW5vdWdoIGludGVyZXN0IHRvIGZvcm0gYSB3b3JraW5nDQo+PiBncm91cCBmb2N1c2VkIG9u IHRoZSBkZXZlbG9wbWVudCBvZiBhIHNldCBvZiBzdGFuZGFyZCBFUFAgZXh0ZW5zaW9ucy4gSWYN Cj4+IHdlIGhhZCB0byBzdGFydCB3cml0aW5nIGEgY2hhcnRlciB0b2RheSwgd2hhdCBmdW5jdGlv bmFsaXR5IHdvdWxkIHBlb3BsZQ0KPj4gbW9zdCBsaWtlIHRvIHNlZSBpbmNsdWRlZD8NCj4+IA0K Pj4gSWYgdGhlcmUgcmVhbGx5IGlzIGludGVyZXN0IEkgd2lsbCBvZmZlciB0byBoZWxwIHVzIGdl dCBvcmdhbml6ZWQuDQo+PiANCj4+IFNjb3R0DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4gcHJvdnJlZyBtYWlsaW5nIGxpc3QNCj4+IHByb3Zy ZWdAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcHJv dnJlZw0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IHByb3ZyZWcgbWFpbGluZyBsaXN0DQo+IHByb3ZyZWdAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wcm92cmVnDQoNCk1yIE1pY2hlbGUg TmV5bG9uDQpCbGFja25pZ2h0IFNvbHV0aW9ucyDimZ4NCkhvc3RpbmcgJiBDb2xvY2F0aW9uLCBC cmFuZCBQcm90ZWN0aW9uDQpJQ0FOTiBBY2NyZWRpdGVkIFJlZ2lzdHJhcg0KaHR0cDovL3d3dy5i bGFja25pZ2h0LmNvbS8NCmh0dHA6Ly9ibG9nLmJsYWNrbmlnaHQuY29tLw0KaHR0cDovL2JsYWNr bmlnaHQuYml6DQpodHRwOi8vbW5leWxvbi50ZWwNCkludGwuICszNTMgKDApIDU5ICA5MTgzMDcy DQpVUzogMjEzLTIzMy0xNjEyIA0KVUs6IDA4NDQgNDg0IDkzNjENCkxvY2FsbDogMTg1MCA5Mjkg OTI5DQpEaXJlY3QgRGlhbDogKzM1MyAoMCk1OSA5MTgzMDkwDQpGYWNlYm9vazogaHR0cDovL2Zi Lm1lL2JsYWNrbmlnaHQNClR3aXR0ZXI6IGh0dHA6Ly90d2l0dGVyLmNvbS9tbmV5bG9uDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpCbGFja25pZ2h0IEludGVybmV0IFNvbHV0aW9u cyBMdGQsIFVuaXQgMTJBLEJhcnJvd3NpZGUgQnVzaW5lc3MgUGFyayxTbGVhdHkNClJvYWQsR3Jh aWd1ZWN1bGxlbixDYXJsb3csSXJlbGFuZCAgQ29tcGFueSBOby46IDM3MDg0NQ0KDQo= From brunner@nic-naa.net Wed Jan 18 05:50:57 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B89121F8816 for ; Wed, 18 Jan 2012 05:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdQUALPXlJmV for ; Wed, 18 Jan 2012 05:50:56 -0800 (PST) Received: from nic-naa.net (nic-naa.net [65.99.1.132]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE0621F880C for ; Wed, 18 Jan 2012 05:50:55 -0800 (PST) Received: from limpet.local (cpe-67-255-2-48.twcny.res.rr.com [67.255.2.48]) by nic-naa.net (8.14.4/8.14.4) with ESMTP id q0IBCTDX062127 for ; Wed, 18 Jan 2012 06:12:30 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-ID: <4F16CE38.1060907@nic-naa.net> Date: Wed, 18 Jan 2012 08:50:48 -0500 From: Eric Brunner-Williams Organization: wampumpeag User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: provreg@ietf.org References: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Standard Extensions X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ebw@abenaki.wabanaki.net List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 13:50:57 -0000 On 1/18/12 7:50 AM, Hollenbeck, Scott wrote: > If there really is interest I will offer to help us get organized. I don't know that there is, but if there is I think your offer is both generous and useful. Eric From ulrich@wisser.se Wed Jan 18 06:10:46 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D00521F87F5 for ; Wed, 18 Jan 2012 06:10:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.089 X-Spam-Level: X-Spam-Status: No, score=-3.089 tagged_above=-999 required=5 tests=[AWL=0.510, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7vRsYqzfL8J for ; Wed, 18 Jan 2012 06:10:45 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9574621F880F for ; Wed, 18 Jan 2012 06:09:57 -0800 (PST) Received: by lagv3 with SMTP id v3so3454668lag.31 for ; Wed, 18 Jan 2012 06:09:56 -0800 (PST) Received: by 10.112.87.3 with SMTP id t3mr5230590lbz.96.1326895796437; Wed, 18 Jan 2012 06:09:56 -0800 (PST) Received: from laptopw-031.office.nic.se (gw.iis.se. [212.247.14.38]) by mx.google.com with ESMTPS id lo13sm18375205lab.8.2012.01.18.06.09.54 (version=SSLv3 cipher=OTHER); Wed, 18 Jan 2012 06:09:55 -0800 (PST) Message-ID: <4F16D2B2.1080406@wisser.se> Date: Wed, 18 Jan 2012 15:09:54 +0100 From: Ulrich Wisser User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: provreg@ietf.org References: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Standard Extensions X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 14:10:46 -0000 Definition on notifications from the registry to registrars. (Like i proposed i my earlier mail). The earlier proposed sunrise-period extension Most european registries have some kind of extension for VAT numbers and/or tax-id. /Ulrich > Let's assume for a moment that we have enough interest to form a working group focused on the development of a set of standard EPP extensions. If we had to start writing a charter today, what functionality would people most like to see included? > > If there really is interest I will offer to help us get organized. > > Scott From JGould@verisign.com Wed Jan 18 06:19:49 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0FCC21F8797 for ; Wed, 18 Jan 2012 06:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.47 X-Spam-Level: X-Spam-Status: No, score=-6.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sy4aSayqELIe for ; Wed, 18 Jan 2012 06:19:49 -0800 (PST) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by ietfa.amsl.com (Postfix) with ESMTP id B0FCB21F86A6 for ; Wed, 18 Jan 2012 06:19:48 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKTxbU92Y8mGgtguqat3K1kehZUTzc1BTG@postini.com; Wed, 18 Jan 2012 06:19:48 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q0IEJWBO009826; Wed, 18 Jan 2012 09:19:34 -0500 Received: from BRN1WNEXCAS01.vcorp.ad.vrsn.com ([10.173.152.205]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Jan 2012 09:19:32 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.01.0323.003; Wed, 18 Jan 2012 09:19:31 -0500 From: "Gould, James" To: MICHAEL YOUNG , "Hollenbeck, Scott" , "provreg@ietf.org" Thread-Topic: [provreg] Standard Extensions Thread-Index: AczV37W4iCnZ4oZDR9SQ1tim3W6hqQAMhT2A//+0ygA= Date: Wed, 18 Jan 2012 14:19:30 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <72CA66EE9624204290D143E02FF92576@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 18 Jan 2012 14:19:32.0766 (UTC) FILETIME=[32C4D3E0:01CCD5EC] Subject: Re: [provreg] Standard Extensions X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 14:19:49 -0000 Scott, I mirror Michael's interest list with some small additions: IDNs Launch Activities (EPP mappings / extensions) 1. Registrar to Trademark Clearinghouse 2. Registry to Trademark Clearinghouse 3. Registrar to Registry Registry Mapping - Provide features and policies for a TLD or set of TLD's. =20 Consolidate / Standardize Custom Extensions - For example some of the ones we have created: 1. IDN Language Tag - Already being worked on with draft-obispo-epp-idn-00.txt 2. RGP Poll Mapping 3. ConsoliDate Mapping 4. NameStore Mapping - Renamed 5. Low Balance Mapping 6. WhoWas Mapping 7. Client Object Attribute Mapping I fully support this effort. -- =20 JG =20 =20 James Gould Principal Software Engineer jgould@verisign.com =20 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On 1/18/12 8:48 AM, "MICHAEL YOUNG" wrote: >Happy to help. Some things on my interest list: > >IDNs >Launch Activities >Possibly Trademark extensions and interactions with the Trademark >Clearinghouse >Possibly some work around compliance enforcement measures (in response to >abuse) > > >Michael Young > > > > >On 12-01-18 6:50 AM, "Hollenbeck, Scott" wrote: > >>Let's assume for a moment that we have enough interest to form a working >>group focused on the development of a set of standard EPP extensions. If >>we had to start writing a charter today, what functionality would people >>most like to see included? >> >>If there really is interest I will offer to help us get organized. >> >>Scott >>_______________________________________________ >>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 theo@flame.co.za Wed Jan 18 06:20:15 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA4021F8812 for ; Wed, 18 Jan 2012 06:20:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81JVxRERUN7A for ; Wed, 18 Jan 2012 06:20:14 -0800 (PST) Received: from flame.co.za (flame.co.za [160.124.170.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8334C21F880F for ; Wed, 18 Jan 2012 06:20:14 -0800 (PST) Received: from theo-kramers-macbook-pro.int.coza.net.za (41-132-13-5.dsl.mweb.co.za [41.132.13.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by flame.co.za (Postfix) with ESMTPSA id 4B02E800C3 for ; Wed, 18 Jan 2012 16:20:11 +0200 (SAST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Theo Kramer In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Wed, 18 Jan 2012 16:20:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3C621C42-5B30-478C-8D61-986D1982C238@flame.co.za> References: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: provreg@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [provreg] Standard Extensions X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 14:20:15 -0000 On 18 Jan 2012, at 2:50 PM, Hollenbeck, Scott wrote: > Let's assume for a moment that we have enough interest to form a = working group focused on the development of a set of standard EPP = extensions. If we had to start writing a charter today, what = functionality would people most like to see included? Zone policy definitions --=20 Regards Theo From gavin.brown@centralnic.com Wed Jan 18 06:23:51 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C0221F8554 for ; Wed, 18 Jan 2012 06:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAkELiO324S4 for ; Wed, 18 Jan 2012 06:23:51 -0800 (PST) Received: from smtp.centralnic.com (smtp.centralnic.com [193.105.170.131]) by ietfa.amsl.com (Postfix) with ESMTP id DB40521F867E for ; Wed, 18 Jan 2012 06:23:50 -0800 (PST) Received: from Gavins-iMac.local (fs-3.zmg.lon.uk.centralnic.net [82.68.174.114]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTP id 751D9712C52; Wed, 18 Jan 2012 14:23:48 +0000 (UTC) Message-ID: <4F16D5F3.508@centralnic.com> Date: Wed, 18 Jan 2012 14:23:47 +0000 From: Gavin Brown User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Michele@ietfa.amsl.com, "Neylon:"@ietfa.amsl.com:Blacknight References: <9F5AE39D-4592-4F79-BBC1-DE852D2B230F@blacknight.ie> In-Reply-To: <9F5AE39D-4592-4F79-BBC1-DE852D2B230F@blacknight.ie> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "provreg@ietf.org" Subject: Re: [provreg] Standard Extensions X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 14:23:51 -0000 On 18/01/2012 13:50, Michele Neylon :: Blacknight wrote: > Wasn't there already some work being done by Gavin Brown and Wil Tan on handling sunrises etc? We still intend to develop the LaunchPhase extension draft, but both Wil and I are very busy right now. Apparently there's a new gTLD round! One other thing on my wishlist for EPP is an extension to add a legal/personal attribute to contact objects, for EU data protection laws. G. -- Gavin Brown Chief Technology Officer CentralNic Ltd Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private domain name registries https://www.centralnic.com/ CentralNic Ltd is a company registered in England and Wales with company number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR. From heland@afilias.info Wed Jan 18 06:26:19 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C63121F86A2 for ; Wed, 18 Jan 2012 06:26:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAa1neoGxQ4o for ; Wed, 18 Jan 2012 06:26:18 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id C75DD21F863C for ; Wed, 18 Jan 2012 06:26:18 -0800 (PST) Received: from ms6.yyz2.afilias-ops.info ([10.50.129.112] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1RnWSw-0003po-6e for provreg@ietf.org; Wed, 18 Jan 2012 14:26:18 +0000 Received: from mail-yw0-f50.google.com ([209.85.213.50]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1RnWSv-0005Mj-94 for provreg@ietf.org; Wed, 18 Jan 2012 14:26:17 +0000 Received: by yhfq11 with SMTP id q11so2172578yhf.9 for ; Wed, 18 Jan 2012 06:26:17 -0800 (PST) Received: by 10.236.156.101 with SMTP id l65mr30364031yhk.69.1326896777289; Wed, 18 Jan 2012 06:26:17 -0800 (PST) Received: from alamo.elandmeadery.info (cpe-72-177-97-55.austin.res.rr.com. [72.177.97.55]) by mx.google.com with ESMTPS id f47sm42960735yhh.8.2012.01.18.06.26.16 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 Jan 2012 06:26:16 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Howard Eland In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Wed, 18 Jan 2012 08:26:15 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: provreg@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [provreg] Standard Extensions X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 14:26:19 -0000 I'll be glad to help as well. -Howard Eland Afilias On Jan 18, 2012, at 6:50 AM, Hollenbeck, Scott wrote: > Let's assume for a moment that we have enough interest to form a = working group focused on the development of a set of standard EPP = extensions. If we had to start writing a charter today, what = functionality would people most like to see included? >=20 > If there really is interest I will offer to help us get organized. >=20 > Scott > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg From patrik@frobbit.se Wed Jan 18 06:50:52 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A4021F86C4 for ; Wed, 18 Jan 2012 06:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.817 X-Spam-Level: X-Spam-Status: No, score=-100.817 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMWsFOHHxdg6 for ; Wed, 18 Jan 2012 06:50:52 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id A66EF21F86B7 for ; Wed, 18 Jan 2012 06:50:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 3C4A112D776E2; Wed, 18 Jan 2012 15:50:50 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyYC1Cwp-hFr; Wed, 18 Jan 2012 15:50:49 +0100 (CET) Received: from [10.184.146.98] (host-95-199-146-98.mobileonline.telia.com [95.199.146.98]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 7D83212D776DB; Wed, 18 Jan 2012 15:50:49 +0100 (CET) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9A405) From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= Date: Wed, 18 Jan 2012 15:50:10 +0100 To: MICHAEL YOUNG Cc: "provreg@ietf.org" Subject: Re: [provreg] Standard Extensions X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 14:50:52 -0000 I am happy to help but want live extensions harmonized and standardized befo= re we add even more bloat to the protocol. Patrik On 18 jan 2012, at 14:48, MICHAEL YOUNG wrote: > Happy to help. Some things on my interest list: >=20 > IDNs > Launch Activities > Possibly Trademark extensions and interactions with the Trademark > Clearinghouse > Possibly some work around compliance enforcement measures (in response to > abuse) >=20 >=20 > Michael Young >=20 >=20 >=20 >=20 > On 12-01-18 6:50 AM, "Hollenbeck, Scott" wrote:= >=20 >> Let's assume for a moment that we have enough interest to form a working >> group focused on the development of a set of standard EPP extensions. If >> we had to start writing a charter today, what functionality would people >> most like to see included? >>=20 >> If there really is interest I will offer to help us get organized. >>=20 >> Scott >> _______________________________________________ >> provreg mailing list >> provreg@ietf.org >> https://www.ietf.org/mailman/listinfo/provreg >=20 >=20 > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg >=20 From keith@blacknight.com Wed Jan 18 08:48:03 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E3E21F86E2 for ; Wed, 18 Jan 2012 08:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.618 X-Spam-Level: X-Spam-Status: No, score=-3.618 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykqwQTQoEy-F for ; Wed, 18 Jan 2012 08:48:02 -0800 (PST) Received: from relay1.blacknight.com (relay1.blacknight.com [78.153.203.204]) by ietfa.amsl.com (Postfix) with ESMTP id 114D621F859F for ; Wed, 18 Jan 2012 08:48:01 -0800 (PST) Received: from hegemon.blacknight.ie (hegemon.blacknight.ie [81.17.243.239]) by relay1.blacknight.com (Postfix) with ESMTP id A3EA735C4D5 for ; Wed, 18 Jan 2012 16:47:58 +0000 (GMT) Message-ID: <4F16F7BE.3030009@blacknight.com> Date: Wed, 18 Jan 2012 16:47:58 +0000 From: Keith Gaughan Organization: Blacknight Internet Solutions User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: provreg@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Standard Extensions X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 16:48:03 -0000 On 18/01/12 14:19, Gould, James wrote: > I mirror Michael's interest list with some small additions: > Launch Activities (EPP mappings / extensions) > 1. Registrar to Trademark Clearinghouse > 2. Registry to Trademark Clearinghouse > 3. Registrar to Registry Wil Tan's work covers at least the Registrar to Registry part of this well enough. > 2. RGP Poll Mapping Might it be best to fold this into a revised version of RFC 3915? > 5. Low Balance Mapping This might be best generalised into an account information mapping. It'd be nice to be able to programmatically update various notification addresses and balance watermarks in addition to querying or being notified of the balance. K. -- Keith Gaughan, Senior Developer PGP/GPG key ID: 3E896381 Blacknight Internet Solutions Ltd. 12A Barrowside Business Park, Carlow, Ireland Registered in Ireland, Company No.: 370845 From JGould@verisign.com Wed Jan 18 08:57:10 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2CC21F8734 for ; Wed, 18 Jan 2012 08:57:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJeMDiav1HnM for ; Wed, 18 Jan 2012 08:57:09 -0800 (PST) Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by ietfa.amsl.com (Postfix) with ESMTP id E416921F8724 for ; Wed, 18 Jan 2012 08:57:08 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKTxb50a/llX2cYPyxvWaxS3rx1CKYv+C4@postini.com; Wed, 18 Jan 2012 08:57:08 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q0IGukwR012455; Wed, 18 Jan 2012 11:56:48 -0500 Received: from BRN1WNEXCAS01.vcorp.ad.vrsn.com ([10.173.152.205]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Jan 2012 11:56:47 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.01.0323.003; Wed, 18 Jan 2012 11:56:46 -0500 From: "Gould, James" To: Keith Gaughan , "provreg@ietf.org" Thread-Topic: [provreg] Standard Extensions Thread-Index: AczV37W4iCnZ4oZDR9SQ1tim3W6hqQAMhT2A//+0ygCAAH1PAP//rp8A Date: Wed, 18 Jan 2012 16:56:45 +0000 Message-ID: In-Reply-To: <4F16F7BE.3030009@blacknight.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <0A0D24408E586D43A87DCF4ED4D2A8AF@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 18 Jan 2012 16:56:47.0238 (UTC) FILETIME=[2A270260:01CCD602] Subject: Re: [provreg] Standard Extensions X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 16:57:10 -0000 > Wil Tan's work covers at least the Registrar to Registry part of this >well > enough. I believe Wil's work is a good starting point, but it is highly dependent on the flow of sunrise and the rights periods. All 3 interfaces are dependent on each other based on the TMCH flow that has yet been fully defined. =20 > Might it be best to fold this into a revised version of RFC 3915? I originally asked for this to be in RFC 3915 but there was objection to it, so I had to create my own custom extension. Combining these would be a good item to discuss. -- =20 JG =20 =20 James Gould Principal Software Engineer jgould@verisign.com =20 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On 1/18/12 11:47 AM, "Keith Gaughan" wrote: >On 18/01/12 14:19, Gould, James wrote: > >> I mirror Michael's interest list with some small additions: > > > >> Launch Activities (EPP mappings / extensions) >> 1. Registrar to Trademark Clearinghouse >> 2. Registry to Trademark Clearinghouse >> 3. Registrar to Registry > >Wil Tan's work covers at least the Registrar to Registry part of this well >enough. > >> 2. RGP Poll Mapping > >Might it be best to fold this into a revised version of RFC 3915? > >> 5. Low Balance Mapping > >This might be best generalised into an account information mapping. It'd >be >nice to be able to programmatically update various notification addresses >and balance watermarks in addition to querying or being notified of the >balance. > >K. > >--=20 >Keith Gaughan, Senior 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 provreg@contact.dotandco.com Wed Jan 18 16:13:02 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19BA811E8093 for ; Wed, 18 Jan 2012 16:13:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.105 X-Spam-Level: X-Spam-Status: No, score=0.105 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_62=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbNw-9+nBdnF for ; Wed, 18 Jan 2012 16:13:00 -0800 (PST) Received: from mail.dotandco.com (unknown [194.242.114.22]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0F311E8089 for ; Wed, 18 Jan 2012 16:13:00 -0800 (PST) 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 q0J0AqcT027853; Thu, 19 Jan 2012 01:10:52 +0100 Received: (from patrick@localhost) by triglav.dotandco.com (8.14.3/8.14.3/Submit) id q0J0ApQH027851; Thu, 19 Jan 2012 01:10:51 +0100 X-Authentication-Warning: triglav.dotandco.com: patrick set sender to provreg@contact.dotandco.com using -f Date: Thu, 19 Jan 2012 01:10:51 +0100 From: Patrick Mevzek To: "provreg@ietf.org" Message-ID: <20120119001051.GF17564@home.patoche.org> References: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> 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]); Thu, 19 Jan 2012 01:10:53 +0100 (CET) Subject: Re: [provreg] Standard Extensions X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 00:13:02 -0000 Hollenbeck, Scott 2012-01-18 13:51 > Let's assume for a moment that we have enough interest to form a working group focused on the development of a set of standard EPP extensions. If we had to start writing a charter today, what functionality would people most like to see included? First and foremost, finding an incentive for current registry operators to implement those extensions instead of their own proprietary, otherwise we will just have even more extensions and even less consolidations. To me, it looks more difficult and more important, than creating the extensions themselves. At the very minimum any new extension created that is a factorisation of extensions already existing should have a section explaining how it will replace the current existing ones. You will also soon, I think, hit the kind of question like "is this not a limit of the protocol, and should'nt the protocol itself be amended" aka EPP v2.0 ? I'm thinking for example about result codes that each registry extend in some way with new values, more or less properly... Same for object status. And for something a little more new, handling of contacts and DNSSEC related content during a domain:transfer. As for the extensions themselves, the whole section 3 of http://www.deepcore.org/ietf/draft-mevzek-epp-implementor-experience-00.txt may give ideas. Or the source of the opensource client that made me write this draft in the past, which contains numerous current registry extensions. HTH, -- Patrick Mevzek From Patrick.Mevzek@afnic.fr Thu Jan 19 00:53:03 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6756121F86E2 for ; Thu, 19 Jan 2012 00:53:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vT8l+mRj9RW8 for ; Thu, 19 Jan 2012 00:53:02 -0800 (PST) Received: from mx2.nic.fr (mx2.nic.fr [IPv6:2001:660:3003:2::4:11]) by ietfa.amsl.com (Postfix) with ESMTP id 9999021F86DA for ; Thu, 19 Jan 2012 00:53:02 -0800 (PST) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 40EA81C00F4 for ; Thu, 19 Jan 2012 09:53:01 +0100 (CET) Received: by mx2.nic.fr (Postfix, from userid 500) id 2F98E1C00F7; Thu, 19 Jan 2012 09:53:01 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [IPv6:2001:67c:2218:9::4:163]) by mx2.nic.fr (Postfix) with ESMTP id 1BCAB1C00F4 for ; Thu, 19 Jan 2012 09:53:01 +0100 (CET) Received: from [IPv6:2001:67c:2219:7::86:96] (citrine.tech.prive.nic.fr [IPv6:2001:67c:2219:7::86:96]) by relay2.nic.fr (Postfix) with ESMTP id E8BA7B3805C; Thu, 19 Jan 2012 09:52:59 +0100 (CET) From: Patrick Mevzek To: "provreg@ietf.org" In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D57D69A@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20120118012549.GA3123@mail.yitter.info> <831693C2CDA2E849A7D7A712B24E257F0D57D69A@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Content-Type: text/plain; charset="UTF-8" Organization: AFNIC Date: Thu, 19 Jan 2012 09:53:00 +0100 Message-ID: <1326963180.2651.1470.camel@citrine> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=1.1.5 X-PMX-Version: 5.4.6.353000, Antispam-Engine: 2.6.1.350677, Antispam-Data: 2012.1.19.84214 X-PerlMx-Spam: Gauge=IIIIIII, Probability=8%, Report='BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_500_599 0, BODY_SIZE_7000_LESS 0, INVALID_MSGID_NO_FQDN 0, NO_URI_FOUND 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __PHISH_SPEAR_STORAGE_LIMIT 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0' Subject: Re: [provreg] Changes we'd make to 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, 19 Jan 2012 08:53:03 -0000 Le mercredi 18 janvier 2012 à 12:27 +0000, Hollenbeck, Scott a écrit : > > EPP probably should have had more focus > > right from the start in addressing bulk operations. > > The use case for bulk operations *was* carefully considered - and not selected for inclusion in the core protocol. In my view it is done in part, since you can use multiple objects in check operations. Which also creates some nice interoperability issues since each registry put a limit on the number of objets per check command... -- Patrick Mevzek From Patrick.Mevzek@afnic.fr Thu Jan 19 00:58:46 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1037E21F8592 for ; Thu, 19 Jan 2012 00:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jt8pWteDFxBf for ; Thu, 19 Jan 2012 00:58:45 -0800 (PST) Received: from mx2.nic.fr (mx2.nic.fr [IPv6:2001:660:3003:2::4:11]) by ietfa.amsl.com (Postfix) with ESMTP id D7B3221F8591 for ; Thu, 19 Jan 2012 00:58:35 -0800 (PST) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 3E97F1C00F4 for ; Thu, 19 Jan 2012 09:58:35 +0100 (CET) Received: by mx2.nic.fr (Postfix, from userid 500) id 275401C00F7; Thu, 19 Jan 2012 09:58:35 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [IPv6:2001:67c:2218:9::4:162]) by mx2.nic.fr (Postfix) with ESMTP id 1AA271C00F4 for ; Thu, 19 Jan 2012 09:58:35 +0100 (CET) Received: from [IPv6:2001:67c:2219:7::86:96] (citrine.tech.prive.nic.fr [IPv6:2001:67c:2219:7::86:96]) by relay1.nic.fr (Postfix) with ESMTP id 1803D4C007D; Thu, 19 Jan 2012 09:58:35 +0100 (CET) From: Patrick Mevzek To: provreg@ietf.org In-Reply-To: <4F16AD79.4080002@blacknight.com> References: <4F15B9FB.1050208@knipp.de> <4F16AD79.4080002@blacknight.com> Content-Type: text/plain; charset="UTF-8" Organization: AFNIC Date: Thu, 19 Jan 2012 09:58:34 +0100 Message-ID: <1326963514.2651.1480.camel@citrine> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=1.1.5 X-PMX-Version: 5.4.6.353000, Antispam-Engine: 2.6.1.350677, Antispam-Data: 2012.1.19.84515 X-PerlMx-Spam: Gauge=IIIIIII, Probability=8%, Report='BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1500_1599 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, INVALID_MSGID_NO_FQDN 0, NO_URI_FOUND 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __PHISH_PHRASE2 0, __PHISH_SPEAR_STORAGE_LIMIT 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0' Subject: Re: [provreg] Changes we'd make to 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, 19 Jan 2012 08:58:46 -0000 Le mercredi 18 janvier 2012 à 11:31 +0000, Keith Gaughan a écrit : > On 17/01/12 18:12, Klaus Malorny wrote: > > > - I just had an insane idea to avoid poll messages about the deletion of > > contacts -- you may forget it just after you have finished > > reading it (or even before): One could introduce an expiration date for > > contacts. If a contact is created, it is set to one year in the future. > > As long as the contact is used at least by one object, it is automatically > > renewed, let's say a quarter before it expires. The registrar can either > > track the expiration date (and perform a contact:info/check to check > > its existence in case his recorded expiration date is in the past) > > or simply create new contacts, as many registrars do it today. > > For the registry, if the contact passes its expiration date, it is > > simply deleted by the registry without any further fuss. > > That's effectively what AFNIC do with their GC mechanism, but the lack of > notification is a bit of an irritation because it's easy for the registrar > to lose track of when the contact actually expires. .FR do send notifications when contacts are garbage collected. There is one notification per contact. Also, when the registrant does not fulfill the charter, after some specific out-of-EPP procedure, domain names may be blocked and later deleted, both actions which are also notified, with one notification per domain (the notification is basically some part of domain:infData content) -- Patrick Mevzek From mcanix@gmail.com Thu Jan 19 03:15:08 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556C421F8606 for ; Thu, 19 Jan 2012 03:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65YKHy0H7kBK for ; Thu, 19 Jan 2012 03:15:06 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 96C4D21F85C5 for ; Thu, 19 Jan 2012 03:15:06 -0800 (PST) Received: by wgbdq11 with SMTP id dq11so3145502wgb.13 for ; Thu, 19 Jan 2012 03:15:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=5qvflIOThEqQvxSwrStjTh9XGRhBtXoeeG5ItzJCdhI=; b=Q+JOzX2xDessnqR+6ikCcpcKvPctsr3DbVKlB4tEls2drdDN18So4I9MP81dRr8j8b W5ZMWdIuP1SCs+vgLuIAncywoYcnQjRTirmWJAtUbSmG2EDj/51F2MsrJSAJoga7JlUk NMVIgTOdzKIzGo/Fqzq/nlfZ6JdPkHohdkvQE= Received: by 10.180.95.199 with SMTP id dm7mr43356986wib.9.1326971705825; Thu, 19 Jan 2012 03:15:05 -0800 (PST) Received: from [192.168.0.72] (41-135-11-209.dsl.mweb.co.za. [41.135.11.209]) by mx.google.com with ESMTPS id bj10sm27437000wib.9.2012.01.19.03.15.03 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Jan 2012 03:15:05 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1084) From: Mike O'Connell In-Reply-To: <20120118143601.084e8af7@pluto.restena.lu> Date: Thu, 19 Jan 2012 13:15:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20120118143601.084e8af7@pluto.restena.lu> To: provreg@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [provreg] Standard Extensions X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 11:15:08 -0000 We (.co.za EPP) have had a few requests for the credit balance from our = registrars too, as well as the ability to fetch an invoice or statement = (which I think should remain out-of-band). Leading from that I think a synchronization extension would be very = helpful which could possibly include: Domain Listing: I know domain listing functions have come up before = but the sheer volume is staggering.=20 What about fine tuning a listing to search by contact and/or = creation date?=20 Or retrieving the data in batches and fetching the delta at the end? Contact Listing: To list all contacts associated with the registrar as = well as very basic information.=20 These commands would only be run by a registrar to retrieve their own = objects. -- Michael O'Connell On 18 Jan 2012, at 3:36 PM, Bruno Pr=E9mont wrote: > On Wed, 18 Jan 2012 12:50:11 Hollenbeck, Scott wrote: >> Let's assume for a moment that we have enough interest to form a >> working group focused on the development of a set of standard EPP >> extensions. If we had to start writing a charter today, what >> functionality would people most like to see included? >>=20 >> If there really is interest I will offer to help us get organized. >=20 > Another extension that could be useful and was requested by one of our > registrars would be for them to check their status. >=20 > It would need: > - their contact data, similar to aggregation of one or more contact > objects [admin, tech, billing] > - their credit balance (the most important information) > it should be possible to add extra information such as soft/hard > limits and possibly some forecast of probable future needs). > - extra key/value pairs, preferably with a few pre-defined types > (string, currency, number, array) for further information >=20 >=20 > --=20 > Bruno Pr=E9mont > Ing=E9nieur syst=E8me et d=E9veloppements >=20 > Fondation RESTENA > 6, rue Coudenhove-Kalergi > L-1359 Luxembourg >=20 > T=E9l: (+352) 424409 > Fax: (+352) 422473 > http://www.restena.lu http://www.dns.lu > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg From mcanix@gmail.com Thu Jan 19 03:18:14 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F8721F8540 for ; Thu, 19 Jan 2012 03:18:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIiTu5Sn3oEf for ; Thu, 19 Jan 2012 03:18:14 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0776221F853C for ; Thu, 19 Jan 2012 03:18:13 -0800 (PST) Received: by wgbdq11 with SMTP id dq11so3147913wgb.13 for ; Thu, 19 Jan 2012 03:18:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=aL+1MCX1hMheXoSm0PTSTXs581x8WKaldGLd16JAffs=; b=WpyK8FmAhhvp0/umZt6P+5EDHdsgOV2T3RetsSRM2LO02jxTDvnlpz2iSR1K6VwGkp i1UEPL6SRALuTdjljMlwBLh+pfv2CRjGNZeyA+DFNLMf61MvnJqc1ee0hwdwcR+LbNjA Zm3LFUIZMcqbQW+MxFE+5iCHS/kamuowgnHgY= Received: by 10.180.102.169 with SMTP id fp9mr43156651wib.9.1326971893290; Thu, 19 Jan 2012 03:18:13 -0800 (PST) Received: from [192.168.0.72] (41-135-11-209.dsl.mweb.co.za. [41.135.11.209]) by mx.google.com with ESMTPS id em13sm27455851wid.7.2012.01.19.03.18.11 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Jan 2012 03:18:12 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Mike O'Connell In-Reply-To: <20120119001051.GF17564@home.patoche.org> Date: Thu, 19 Jan 2012 13:18:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6759AE9A-EF79-4F82-B5A4-0D468EC583DE@gmail.com> References: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20120119001051.GF17564@home.patoche.org> To: provreg@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [provreg] Standard Extensions X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 11:18:14 -0000 > And for something a little more new, handling of contacts and DNSSEC > related content during a domain:transfer. This would be extremely handy, if we can specify the future contact and = DNSSEC information when performing the domain:transfer we would save on = contact GC (touchy subject). I'll happy assist here... -- Michael O'Connell= From keith@blacknight.com Thu Jan 19 03:58:11 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1044621F8572 for ; Thu, 19 Jan 2012 03:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.617 X-Spam-Level: X-Spam-Status: No, score=-3.617 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8CwBRAyzGwY for ; Thu, 19 Jan 2012 03:58:10 -0800 (PST) Received: from relay1.blacknight.com (relay1.blacknight.com [78.153.203.204]) by ietfa.amsl.com (Postfix) with ESMTP id 4604021F854A for ; Thu, 19 Jan 2012 03:58:09 -0800 (PST) Received: from hegemon.blacknight.ie (hegemon.blacknight.ie [81.17.243.239]) by relay1.blacknight.com (Postfix) with ESMTP id B84C235C2EA for ; Thu, 19 Jan 2012 11:58:06 +0000 (GMT) Message-ID: <4F18054E.8090403@blacknight.com> Date: Thu, 19 Jan 2012 11:58:06 +0000 From: Keith Gaughan Organization: Blacknight Internet Solutions User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: provreg@ietf.org References: <4F15B9FB.1050208@knipp.de> <4F16AD79.4080002@blacknight.com> <1326963514.2651.1480.camel@citrine> In-Reply-To: <1326963514.2651.1480.camel@citrine> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [provreg] Changes we'd make to 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, 19 Jan 2012 11:58:11 -0000 On 19/01/12 08:58, Patrick Mevzek wrote: > Le mercredi 18 janvier 2012 à 11:31 +0000, Keith Gaughan a écrit : > >> That's effectively what AFNIC do with their GC mechanism, but the lack of >> notification is a bit of an irritation because it's easy for the registrar >> to lose track of when the contact actually expires. > > .FR do send notifications when contacts are garbage collected. There is > one notification per contact. Sorry, yes, that's correct. I was also inaccurate about the length of time before deletion, which is actually 90 days, with a 15-day grace period after that. For reference in the discussion, the notification looks like this, more or less: Command completed successfully; ack to dequeue 2012-01-19T11:50:00.0Z Contact deletion completed ABC-123 XYZ-123 Anyway, the overriding point is that AFNIC are an example of an existing registry that already do object garbage collection. My bad though. I'd their procedures mixed up in my head with another registry that does (irregular, and unnotified) garbage collection. K. -- Keith Gaughan, Senior Developer PGP/GPG key ID: 3E896381 Blacknight Internet Solutions Ltd. 12A Barrowside Business Park, Carlow, Ireland Registered in Ireland, Company No.: 370845 From shollenbeck@verisign.com Thu Jan 19 04:17:28 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706AC21F85BB for ; Thu, 19 Jan 2012 04:17:28 -0800 (PST) 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=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODCa8af3HBBO for ; Thu, 19 Jan 2012 04:17:28 -0800 (PST) Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) by ietfa.amsl.com (Postfix) with ESMTP id E9CAF21F8575 for ; Thu, 19 Jan 2012 04:17:23 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKTxgJxeWQDKlPU6mYTOM/ScLFYWqwLE8T@postini.com; Thu, 19 Jan 2012 04:17:27 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q0JCH6Cm022497; Thu, 19 Jan 2012 07:17:06 -0500 Received: from dul1wnexcn04.vcorp.ad.vrsn.com ([10.170.12.139]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Jan 2012 07:17:07 -0500 Received: from BRN1WNEXCAS02.vcorp.ad.vrsn.com ([10.173.152.246]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Jan 2012 07:17:05 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.01.0323.003; Thu, 19 Jan 2012 07:17:06 -0500 From: "Hollenbeck, Scott" To: Patrick Mevzek , "provreg@ietf.org" Thread-Topic: [provreg] Standard Extensions Thread-Index: AQHM1j7NiCnZ4oZDR9SQ1tim3W6hqZYTmxCA Date: Thu, 19 Jan 2012 12:17:05 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D57E99F@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20120119001051.GF17564@home.patoche.org> In-Reply-To: <20120119001051.GF17564@home.patoche.org> 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: 19 Jan 2012 12:17:05.0833 (UTC) FILETIME=[42119190:01CCD6A4] Subject: Re: [provreg] Standard Extensions X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 12:17:28 -0000 > -----Original Message----- > From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On > Behalf Of Patrick Mevzek > Sent: Wednesday, January 18, 2012 7:11 PM > To: provreg@ietf.org > Subject: Re: [provreg] Standard Extensions >=20 > You will also soon, I think, hit the kind of question like "is this > not a limit of the protocol, and should'nt the protocol itself be > amended" aka EPP v2.0 ? > I'm thinking for example about result codes that each registry extend > in some way with new values, more or less properly... > Same for object status. We've actually considered that question more than once in recent years. I'm= still unconvinced that there's a need to reopen the core protocol, especia= lly for niche data structures that can be specified in an extension. I don'= t yet see the benefit outweighing the cost. Having said that, maybe it make= s sense to create a standard extension for additional result codes and stat= us values. Scott From Ed.Lewis@neustar.biz Thu Jan 19 08:21:10 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E998D21F86A9 for ; Thu, 19 Jan 2012 08:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.585 X-Spam-Level: X-Spam-Status: No, score=-104.585 tagged_above=-999 required=5 tests=[AWL=0.525, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgSnBh6xS8vg for ; Thu, 19 Jan 2012 08:21:08 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 31B4121F869D for ; Thu, 19 Jan 2012 08:21:04 -0800 (PST) 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 q0JGL2Wh005392; Thu, 19 Jan 2012 11:21:02 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.137] by work-laptop-2 (PGP Universal service); Thu, 19 Jan 2012 11:21:02 -0500 X-PGP-Universal: processed; by work-laptop-2 on Thu, 19 Jan 2012 11:21:02 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20120119001051.GF17564@home.patoche.org> References: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20120119001051.GF17564@home.patoche.org> Date: Thu, 19 Jan 2012 11:21:00 -0500 To: "provreg@ietf.org" From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: Re: [provreg] Standard Extensions X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 16:21:11 -0000 At 1:10 +0100 1/19/12, Patrick Mevzek wrote: >First and foremost, finding an incentive for current registry >operators to implement those extensions instead of their own >proprietary, otherwise we will just have even more extensions and even >less consolidations. >To me, it looks more difficult and more important, than creating the >extensions themselves. I think that is a very important point. In Oct 2009 I began a short look into EPP 2 after comments at a CENTR Tech meeting. There was a "bar bof" at the IETF in March 2010 and a follow up discussion at the CENTR Tech meeting in May 2010. (Dates given to set date context.) At the follow up, the consensus was that the cost to upgrade from an EPP 1 to an EPP 2 was not worth any perceived benefit. I'm not saying there will never be a need for EPP 2 but Patrick is very right. We have to justify the move to an upgraded EPP, not just define a new EPP version. Analogously, DNSSEC stalled until Kaminsky's work increased the "perceived benefit". DNSSEC didn't change and the basic problem it was meant to solve didn't change, but the perception of the benefit shifted. And, to borrow from IPv6, we need to consider the transition from EPP as it is today to any follow on version. And I should add this. Before significant work happens on this list, the list has to be publicized as widely as needed. Part of what was learned in 2009-2010 was that once the WG that used to cover this list was closed, few newcomers learned of the list. I'm not saying, don't do work but keep in mind there may be interested and informed parties that are not aware of this discussion. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Vote for the word of the day: "Papa"razzi - father that constantly takes photos of the baby Corpureaucracy - The institution of corporate "red tape" From keith@blacknight.com Thu Jan 19 08:49:16 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C9C21F863C for ; Thu, 19 Jan 2012 08:49:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.617 X-Spam-Level: X-Spam-Status: No, score=-3.617 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0LQXlYy4XsG for ; Thu, 19 Jan 2012 08:49:15 -0800 (PST) Received: from relay1.blacknight.com (relay1.blacknight.com [78.153.203.204]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCFF21F8634 for ; Thu, 19 Jan 2012 08:49:14 -0800 (PST) Received: from hegemon.blacknight.ie (hegemon.blacknight.ie [81.17.243.239]) by relay1.blacknight.com (Postfix) with ESMTP id E7A7C35C4CA for ; Thu, 19 Jan 2012 16:49:11 +0000 (GMT) Message-ID: <4F184987.5010609@blacknight.com> Date: Thu, 19 Jan 2012 16:49:11 +0000 From: Keith Gaughan Organization: Blacknight Internet Solutions User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: provreg@ietf.org References: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20120119001051.GF17564@home.patoche.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Standard Extensions X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 16:49:16 -0000 On 19/01/12 16:21, Edward Lewis wrote: > At 1:10 +0100 1/19/12, Patrick Mevzek wrote: > >> First and foremost, finding an incentive for current registry >> operators to implement those extensions instead of their own >> proprietary, otherwise we will just have even more extensions and even >> less consolidations. >> To me, it looks more difficult and more important, than creating the >> extensions themselves. That reminds me of this: http://xkcd.com/927/ > I think that is a very important point. In Oct 2009 I began a short look into > EPP 2 after comments at a CENTR Tech meeting. There was a "bar bof" at the > IETF in March 2010 and a follow up discussion at the CENTR Tech meeting in May > 2010. (Dates given to set date context.) At the follow up, the consensus was > that the cost to upgrade from an EPP 1 to an EPP 2 was not worth any perceived > benefit. > > I'm not saying there will never be a need for EPP 2 but Patrick is very > right. We have to justify the move to an upgraded EPP, not just define a new > EPP version. Analogously, DNSSEC stalled until Kaminsky's work increased the > "perceived benefit". Any new extension or object mappings we come up with do have one advantage given ICANN's new gTLD program. ccTLDs and gTLDs differ in that ccTLDs have captive national audiences and can largely do what they like. gTLDs are different: as they're global, they lack the inherent registrant audience of a new ccTLD would have. Thus any new gTLD is going to be competing with other new gTLDs for registrar mindshare. Speaking as a registrar, we're more likely to integrate our systems with registries that require less work no our part, thus fewer proprietary extension and object mappings they have, the more likely a registrar is to go to the trouble of integrating their systems. That's our "perceived benefit". It's the same reason incumbents in the gTLD arena have a built-in advantage: registrars will likely have already implemented their proprietary extensions, so the barriers to integration are lower. Of course, things are going to be a bit more complex than that, and ease of integration isn't the only factor that's going to sway which new gTLDs registrars deal with, but it's a powerful incentive nonetheless. K. -- Keith Gaughan, Senior Developer PGP/GPG key ID: 3E896381 Blacknight Internet Solutions Ltd. 12A Barrowside Business Park, Carlow, Ireland Registered in Ireland, Company No.: 370845 From brunner@nic-naa.net Thu Jan 19 09:39:12 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BCB721F8611 for ; Thu, 19 Jan 2012 09:39:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVmC5IxwN3Vw for ; Thu, 19 Jan 2012 09:39:11 -0800 (PST) Received: from nic-naa.net (nic-naa.net [65.99.1.132]) by ietfa.amsl.com (Postfix) with ESMTP id 879D821F8609 for ; Thu, 19 Jan 2012 09:39:11 -0800 (PST) Received: from limpet.local (cpe-67-255-2-48.twcny.res.rr.com [67.255.2.48]) by nic-naa.net (8.14.4/8.14.4) with ESMTP id q0JF0TID025197 for ; Thu, 19 Jan 2012 10:00:29 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-ID: <4F185538.1000504@nic-naa.net> Date: Thu, 19 Jan 2012 12:39:04 -0500 From: Eric Brunner-Williams Organization: wampumpeag User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: provreg@ietf.org References: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20120119001051.GF17564@home.patoche.org> <4F184987.5010609@blacknight.com> In-Reply-To: <4F184987.5010609@blacknight.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Standard Extensions X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ebw@abenaki.wabanaki.net List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 17:39:12 -0000 On 1/19/12 11:49 AM, Keith Gaughan wrote: > ... the consensus was >> that the cost to upgrade from an EPP 1 to an EPP 2 was not worth any perceived >> benefit. ... YMMV, but there may a fundamental difference of interests between registrars selling VGRS inventory and hoping to cover as many other protocol-and-logically distinct sources of inventory at the lowest cost and registrars (possibly co-owned by registry market entrants) hoping to cover some distinct sources of inventory, and incidentally also selling inventories for which protocol-and-logic clients exist. Consensus among legacy-centric-registrars isn't in itself attractive to a registry operator sharing no fate with legacy registry operators, and adequately served by OT&E interoperable registrars. Eric From nkong@cnnic.cn Thu Jan 19 19:18:46 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C882721F858F for ; Thu, 19 Jan 2012 19:18:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0MBRv0wxqir for ; Thu, 19 Jan 2012 19:18:45 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 44DF621F858B for ; Thu, 19 Jan 2012 19:18:45 -0800 (PST) X-EYOUMAIL-SMTPAUTH: nkong@cnnic.cn Received: from unknown127.0.0.1 (HELO naptrthink) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 20 Jan 2012 11:18:34 +0800 From: "Ning Kong" To: "'Hollenbeck, Scott'" , References: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Fri, 20 Jan 2012 11:18:22 +0800 Message-ID: <00a901ccd722$2a49a0b0$7edce210$@cnnic.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFaePOLLIzkEJiADav3KhDyBEwwLpb31VrA Content-Language: zh-cn Subject: Re: [provreg] Standard Extensions X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 03:18:46 -0000 > Let's assume for a moment that we have enough interest to form a working > group focused on the development of a set of standard EPP extensions. If we > had to start writing a charter today, what functionality would people most > like to see included? I'm very interested in developing EPP extensions for IDNs (especially for variant IDNs) in order to simplify the synchronization of some or all the attributes among variant IDNs. I'd like to write such drafts based on the ideas of draft-kong-epp-cdn-mapping-00 and draft-kong-epp-cdn-dnssec-mapping-00. > If there really is interest I will offer to help us get organized. Thanks, Scott. You know, there are a few guys interested in EPP extensions for variant IDNs on this list. So I was going to organize a bar bof @ IETF 83 to discuss EPP extensions for (variant) IDNs. But I would be glad if there could be a more general bof to discuss EPP extensions. Cheers, Ning From provreg@contact.dotandco.com Mon Jan 23 16:01:16 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E276221F863E for ; Mon, 23 Jan 2012 16:01:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.04 X-Spam-Level: X-Spam-Status: No, score=-0.04 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BP8zgs7pefxN for ; Mon, 23 Jan 2012 16:01:16 -0800 (PST) Received: from mail.dotandco.com (triglav.dotandco.com [194.242.114.22]) by ietfa.amsl.com (Postfix) with ESMTP id B2B3521F8637 for ; Mon, 23 Jan 2012 16:01:15 -0800 (PST) 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 q0NNxDYa010240 for ; Tue, 24 Jan 2012 00:59:13 +0100 Received: (from patrick@localhost) by triglav.dotandco.com (8.14.3/8.14.3/Submit) id q0NNxD3i010238 for provreg@ietf.org; Tue, 24 Jan 2012 00:59:13 +0100 X-Authentication-Warning: triglav.dotandco.com: patrick set sender to provreg@contact.dotandco.com using -f Date: Tue, 24 Jan 2012 00:59:12 +0100 From: Patrick Mevzek To: provreg@ietf.org Message-ID: <20120123235912.GM17564@home.patoche.org> References: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20120119001051.GF17564@home.patoche.org> <831693C2CDA2E849A7D7A712B24E257F0D57E99F@BRN1WNEXMBX01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D57E99F@BRN1WNEXMBX01.vcorp.ad.vrsn.com> 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]); Tue, 24 Jan 2012 00:59:13 +0100 (CET) Subject: Re: [provreg] Standard Extensions X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 00:01:17 -0000 Hollenbeck, Scott 2012-01-19 13:18 > Having said that, maybe it makes sense to create a standard extension for additional result codes and status values. I believe so. And then, if you make it happen that everyone switch from their current homegrown version to this extension, you may find out that all registries or almost all of them need this extension, which in a way shows that the feature should be in the core protocol. But things will technically work out the same way while in an extension. *If* everyone switches to it. Which I'm far to believe. Hence another argument to include it in some EPPv2 if there is some work on that one day, because then the feature will be "free" when you switch to this version, no more extension. And in that way it is really an incentive (one extension less to code for registrars). -- Patrick Mevzek From shollenbeck@verisign.com Tue Jan 24 04:00:05 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFF021F8504 for ; Tue, 24 Jan 2012 04:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxV4idqsK8xF for ; Tue, 24 Jan 2012 04:00:04 -0800 (PST) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8E621F8507 for ; Tue, 24 Jan 2012 03:59:59 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKTx6dPotVX2U0i0uPjh3cCT47Bzpwn40/@postini.com; Tue, 24 Jan 2012 04:00:04 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q0OBxtPg013324; Tue, 24 Jan 2012 06:59:55 -0500 Received: from dul1wnexcn04.vcorp.ad.vrsn.com ([10.170.12.139]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Jan 2012 06:59:56 -0500 Received: from BRN1WNEXCAS01.vcorp.ad.vrsn.com ([10.173.152.205]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Jan 2012 06:59:55 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Tue, 24 Jan 2012 06:59:54 -0500 From: "Hollenbeck, Scott" To: Patrick Mevzek , "provreg@ietf.org" Thread-Topic: [provreg] Standard Extensions Thread-Index: AQHM2itOj/i360+wIUmDESBoAXVIyJYbagCQ Date: Tue, 24 Jan 2012 11:59:53 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D5906F2@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20120119001051.GF17564@home.patoche.org> <831693C2CDA2E849A7D7A712B24E257F0D57E99F@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20120123235912.GM17564@home.patoche.org> In-Reply-To: <20120123235912.GM17564@home.patoche.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 24 Jan 2012 11:59:55.0269 (UTC) FILETIME=[AFDEBB50:01CCDA8F] Subject: Re: [provreg] Standard Extensions X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 12:00:05 -0000 > -----Original Message----- > From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On > Behalf Of Patrick Mevzek > Sent: Monday, January 23, 2012 6:59 PM > To: provreg@ietf.org > Subject: Re: [provreg] Standard Extensions >=20 > Hollenbeck, Scott 2012-01-19 13:18 > > Having said that, maybe it makes sense to create a standard extension > for additional result codes and status values. >=20 > I believe so. >=20 > And then, if you make it happen that everyone switch from their > current homegrown version to this extension, you may find out that all > registries or almost all of them need this extension, which in a way > shows that the feature should be in the core protocol. > But things will technically work out the same way while in an > extension. >=20 > *If* everyone switches to it. >=20 > Which I'm far to believe. I'm with you on the switching part, but I'm not convinced that there really= is significant demand. How many registries are using custom result codes a= nd status values? Scott From JGould@verisign.com Tue Jan 24 05:04:56 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9ED221F850F for ; Tue, 24 Jan 2012 05:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSpoTt8WG8qy for ; Tue, 24 Jan 2012 05:04:55 -0800 (PST) Received: from exprod6og117.obsmtp.com (exprod6og117.obsmtp.com [64.18.1.39]) by ietfa.amsl.com (Postfix) with ESMTP id E6D2E21F84F6 for ; Tue, 24 Jan 2012 05:04:51 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKTx6sc59QgO2UjrDUPdsJ8X4H6orc0awV@postini.com; Tue, 24 Jan 2012 05:04:55 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q0OD4m0s012906; Tue, 24 Jan 2012 08:04:48 -0500 Received: from BRN1WNEXCAS01.vcorp.ad.vrsn.com ([10.173.152.205]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Jan 2012 08:04:48 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Tue, 24 Jan 2012 08:04:47 -0500 From: "Gould, James" To: "Hollenbeck, Scott" , Patrick Mevzek , "provreg@ietf.org" Thread-Topic: [provreg] Standard Extensions Thread-Index: AczV37W4iCnZ4oZDR9SQ1tim3W6hqQAiQCOAABldCYAA4a/TAAAZK2mA//++TAA= Date: Tue, 24 Jan 2012 13:04:46 +0000 Message-ID: In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D5906F2@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 24 Jan 2012 13:04:48.0258 (UTC) FILETIME=[C045B620:01CCDA98] Subject: Re: [provreg] Standard Extensions X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 13:04:57 -0000 We haven't had the need for an extension for result codes or status values for root, .com, .net, .edu, .cc, .tv, .jobs and our additional services (name suggestion, whowas, etc.). For .name we only needed to include a sub-result code of 2305 "Object association prohibits operation" on the create response of domain and emailfwd for providing more clarity on which object prohibits the operation (1 "Corresponding service exists" or 2 "Conflicting defensive registration exists"). I'm not sure if any of the Registrars for .name are utilizing this feature of the "Personal Registration" extension to drive their client-side logic. In general we stick with the result codes and status values defined in the RFC's. -- =20 JG =20 =20 James Gould Principal Software Engineer jgould@verisign.com =20 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On 1/24/12 6:59 AM, "Hollenbeck, Scott" wrote: >> -----Original Message----- >> From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On >> Behalf Of Patrick Mevzek >> Sent: Monday, January 23, 2012 6:59 PM >> To: provreg@ietf.org >> Subject: Re: [provreg] Standard Extensions >>=20 >> Hollenbeck, Scott 2012-01-19 13:18 >> > Having said that, maybe it makes sense to create a standard extension >> for additional result codes and status values. >>=20 >> I believe so. >>=20 >> And then, if you make it happen that everyone switch from their >> current homegrown version to this extension, you may find out that all >> registries or almost all of them need this extension, which in a way >> shows that the feature should be in the core protocol. >> But things will technically work out the same way while in an >> extension. >>=20 >> *If* everyone switches to it. >>=20 >> Which I'm far to believe. > >I'm with you on the switching part, but I'm not convinced that there >really is significant demand. How many registries are using custom result >codes and status values? > >Scott >_______________________________________________ >provreg mailing list >provreg@ietf.org >https://www.ietf.org/mailman/listinfo/provreg From jay@nzrs.net.nz Tue Jan 24 16:01:33 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A9521F8589 for ; Tue, 24 Jan 2012 16:01:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XU94EgR+Jio for ; Tue, 24 Jan 2012 16:01:31 -0800 (PST) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id F2CF911E809D for ; Tue, 24 Jan 2012 16:01:30 -0800 (PST) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 22C092CE185; Wed, 25 Jan 2012 13:01:28 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ut0yBweOMiL3; Wed, 25 Jan 2012 13:01:27 +1300 (NZDT) Received: from [192.168.22.132] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 56EDF2CE179; Wed, 25 Jan 2012 13:01:27 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Jay Daley In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Wed, 25 Jan 2012 13:02:10 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: "Hollenbeck, Scott" X-Mailer: Apple Mail (2.1251.1) Cc: "provreg@ietf.org" Subject: Re: [provreg] Standard Extensions X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 00:01:33 -0000 On 19/01/2012, at 1:50 AM, Hollenbeck, Scott wrote: > Let's assume for a moment that we have enough interest to form a = working group focused on the development of a set of standard EPP = extensions. If we had to start writing a charter today, what = functionality would people most like to see included? Two extensions that are on my todo list to write up but never get to the = top: 1. Cryptographic signatures. Lots of XML apps do this using a variety = of mechanisms: - PGP in special tags - S/MIME as used in XMPP (Jabber) - SAMLv2.0 HTTP POST 'SimpleSign=92 Binding - Detached PGP signatures (as per .nz DNRS protocol) - but not XML-Dsig =96 complete disaster = (http://www.cs.auckland.ac.nz/~pgut001/pubs/ xmlsec.txt) 2. Delegation errors/warnings. A variety of TLDs check the delegation = data and the nameservers before entering the data into their zones = (note, in .nz we do not). Such checks include whether the nameserver = are serving the zone, whether the serial numbers are the same, whether = all the authorities reported are being configured in the parent zone and = so on. =20 A standard extension around this would be useful for - a TLD that does checks advertising that fact (and what those checks = are) - reporting failures if doing checks - optional support for a TLD that will provide this information to a = registrar upon request, but not run proactive checks or interfere with = the delegation process Then there is the big change to the core protocol I've always wanted to = do: 3. Change the command extension mechanism to use SubstitutionGroup to = give first class extensions. =20 And finally something for us to think about: 4. Currently EPP *defines* a data model for domain name registrations, = which fits gTLDs and some ccTLDs but not all (note, it does fit the .nz = data model). If the ICANN data model changes at any point then = amending EPP will require lots of effort all round. It might be better = to pre-empt this by moving to an alternative approach where the EPP = protocol is used to *describe* the registration data expected. If then = it was agreed that all gTLD registrations must include say a registrant = type as they have in .uk, then this could be added merely by updating = the description the servers send rather than the protocol. cheers Jay --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 From provreg@contact.dotandco.com Tue Jan 24 16:03:46 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7FAC11E80A2 for ; Tue, 24 Jan 2012 16:03:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.32 X-Spam-Level: X-Spam-Status: No, score=-1.32 tagged_above=-999 required=5 tests=[AWL=1.280, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9EYY5jjM9E+d for ; Tue, 24 Jan 2012 16:03:45 -0800 (PST) Received: from mail.dotandco.com (triglav.dotandco.com [194.242.114.22]) by ietfa.amsl.com (Postfix) with ESMTP id C3C0011E80BB for ; Tue, 24 Jan 2012 16:03:44 -0800 (PST) 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 q0P01hcS013093; Wed, 25 Jan 2012 01:01:43 +0100 Received: (from patrick@localhost) by triglav.dotandco.com (8.14.3/8.14.3/Submit) id q0P01g5t013091; Wed, 25 Jan 2012 01:01:42 +0100 X-Authentication-Warning: triglav.dotandco.com: patrick set sender to provreg@contact.dotandco.com using -f Date: Wed, 25 Jan 2012 01:01:42 +0100 From: Patrick Mevzek To: "Hollenbeck, Scott" Message-ID: <20120125000142.GT17564@home.patoche.org> References: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20120119001051.GF17564@home.patoche.org> <831693C2CDA2E849A7D7A712B24E257F0D57E99F@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20120123235912.GM17564@home.patoche.org> <831693C2CDA2E849A7D7A712B24E257F0D5906F2@BRN1WNEXMBX01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D5906F2@BRN1WNEXMBX01.vcorp.ad.vrsn.com> 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, 25 Jan 2012 01:01:43 +0100 (CET) Cc: "provreg@ietf.org" Subject: Re: [provreg] Standard Extensions X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 00:03:46 -0000 Hollenbeck, Scott 2012-01-24 13:01 > How many registries are using custom result codes and status values? Indeed, I rewrote myself saying almost any registry, because I had in mind VeriSign which does not need custom codes. However as an EPP client implementor I've seen registries using their own result codes/status values in such ways: - either just adding items to the associated lists, breaking the EPP XML Schema validation (for the brave souls doing it live) - or adding "sub" values, that is besides standard ones - or creating a true EPP extension, in the RFC 3735 sense, with new values. Looking at my code I see at least the following: .FR .AT / IENUMAT .BE .EU .LU .NO .NL .CA but I'm not really keeping track of list of specific statuses, so there may be some more, maybe some registrars could provide more info. -- Patrick Mevzek From gavin.brown@centralnic.com Wed Jan 25 01:43:38 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC08821F8618 for ; Wed, 25 Jan 2012 01:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAGsqkxsm60y for ; Wed, 25 Jan 2012 01:43:37 -0800 (PST) Received: from smtp.centralnic.com (smtp.centralnic.com [193.105.170.131]) by ietfa.amsl.com (Postfix) with ESMTP id CD5F421F860F for ; Wed, 25 Jan 2012 01:43:37 -0800 (PST) Received: from Gavins-iMac.local (fs-3.zmg.lon.uk.centralnic.net [82.68.174.114]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTP id C82CD712BE5; Wed, 25 Jan 2012 09:43:35 +0000 (UTC) Message-ID: <4F1FCEC7.4070904@centralnic.com> Date: Wed, 25 Jan 2012 09:43:35 +0000 From: Gavin Brown User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Jay Daley References: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "provreg@ietf.org" Subject: Re: [provreg] Standard Extensions X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 09:43:39 -0000 On 25/01/2012 00:02, Jay Daley wrote: > > On 19/01/2012, at 1:50 AM, Hollenbeck, Scott wrote: > > Two extensions that are on my todo list to write up but never get to the top: > > 1. Cryptographic signatures. Lots of XML apps do this using a variety of mechanisms: > > - PGP in special tags > - S/MIME as used in XMPP (Jabber) > - SAMLv2.0 HTTP POST 'SimpleSign’ Binding > - Detached PGP signatures (as per .nz DNRS protocol) > - but not XML-Dsig – complete disaster (http://www.cs.auckland.ac.nz/~pgut001/pubs/ xmlsec.txt) I had a stab at an Internet-Draft for this: https://raw.github.com/jodrell/draft-brown-eppSig/master/draft-brown-eppsig.txt There's PHP code that implements signing and validation here: https://github.com/jodrell/draft-brown-eppSig/tree/master/tests it uses XML-DSig, which I accept has some issues. G. -- Gavin Brown Chief Technology Officer CentralNic Ltd Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private domain name registries https://www.centralnic.com/ CentralNic Ltd is a company registered in England and Wales with company number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR. From JGould@verisign.com Wed Jan 25 06:11:02 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D4521F86DF for ; Wed, 25 Jan 2012 06:11:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Um0fBY5y58+y for ; Wed, 25 Jan 2012 06:11:01 -0800 (PST) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE1B21F86DA for ; Wed, 25 Jan 2012 06:11:01 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKTyANYUEKXLAToCGEw+1RM4VZvaIAdq11@postini.com; Wed, 25 Jan 2012 06:11:01 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q0PEAcEi000430; Wed, 25 Jan 2012 09:10:40 -0500 Received: from BRN1WNEXCAS01.vcorp.ad.vrsn.com ([10.173.152.205]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Jan 2012 09:10:39 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Wed, 25 Jan 2012 09:10:37 -0500 From: "Gould, James" To: Jay Daley , "Hollenbeck, Scott" Thread-Topic: [provreg] Standard Extensions Thread-Index: AczV37W4iCnZ4oZDR9SQ1tim3W6hqQFPsh8AABMmyAA= Date: Wed, 25 Jan 2012 14:10:37 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 25 Jan 2012 14:10:39.0185 (UTC) FILETIME=[1D9F1410:01CCDB6B] Cc: "provreg@ietf.org" Subject: Re: [provreg] Standard Extensions X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 14:11:03 -0000 Jay, <4. Currently EPP *defines* a data model for domain name registrations, which fits gTLDs and some ccTLDs but not all (note, it does fit the .nz data model). If the wrote: > >On 19/01/2012, at 1:50 AM, Hollenbeck, Scott wrote: > >> Let's assume for a moment that we have enough interest to form a >>working group focused on the development of a set of standard EPP >>extensions. If we had to start writing a charter today, what >>functionality would people most like to see included? > >Two extensions that are on my todo list to write up but never get to the >top: > >1. Cryptographic signatures. Lots of XML apps do this using a variety >of mechanisms: > > - PGP in special tags > - S/MIME as used in XMPP (Jabber) > - SAMLv2.0 HTTP POST 'SimpleSign=B9 Binding > - Detached PGP signatures (as per .nz DNRS protocol) > - but not XML-Dsig =AD complete disaster >(http://www.cs.auckland.ac.nz/~pgut001/pubs/ xmlsec.txt) > >2. Delegation errors/warnings. A variety of TLDs check the delegation >data and the nameservers before entering the data into their zones (note, >in .nz we do not). Such checks include whether the nameserver are >serving the zone, whether the serial numbers are the same, whether all >the authorities reported are being configured in the parent zone and so >on. =20 > >A standard extension around this would be useful for >- a TLD that does checks advertising that fact (and what those checks are) >- reporting failures if doing checks >- optional support for a TLD that will provide this information to a >registrar upon request, but not run proactive checks or interfere with >the delegation process > > >Then there is the big change to the core protocol I've always wanted to >do: > >3. Change the command extension mechanism to use SubstitutionGroup to >give first class extensions. > > >And finally something for us to think about: > >4. Currently EPP *defines* a data model for domain name registrations, >which fits gTLDs and some ccTLDs but not all (note, it does fit the .nz >data model). If the ICANN data model changes at any point then amending >EPP will require lots of effort all round. It might be better to >pre-empt this by moving to an alternative approach where the EPP protocol >is used to *describe* the registration data expected. If then it was >agreed that all gTLD registrations must include say a registrant type as >they have in .uk, then this could be added merely by updating the >description the servers send rather than the protocol. > > >cheers >Jay > >--=20 >Jay Daley >Chief Executive >.nz Registry Services (New Zealand Domain Name Registry Limited) >desk: +64 4 931 6977 >mobile: +64 21 678840 > >_______________________________________________ >provreg mailing list >provreg@ietf.org >https://www.ietf.org/mailman/listinfo/provreg From theo@flame.co.za Wed Jan 25 06:32:18 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4720521F84FB for ; Wed, 25 Jan 2012 06:32:18 -0800 (PST) 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_22=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dh8blFs+TTqL for ; Wed, 25 Jan 2012 06:32:16 -0800 (PST) Received: from flame.co.za (ns.flame.co.za [160.124.170.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62C0821F84EB for ; Wed, 25 Jan 2012 06:32:13 -0800 (PST) Received: from theo-kramers-macbook-pro.int.coza.net.za (cache.coza.net.za [206.223.136.211]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by flame.co.za (Postfix) with ESMTPSA id 8883A800BE for ; Wed, 25 Jan 2012 16:32:08 +0200 (SAST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Theo Kramer In-Reply-To: Date: Wed, 25 Jan 2012 16:32:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3F6EC3CF-497B-456D-9A07-E5FCAF1C89D6@flame.co.za> References: To: provreg@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [provreg] Standard Extensions X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 14:32:18 -0000 On 25 Jan 2012, at 4:10 PM, Gould, James wrote: > Jay, >=20 > <4. Currently EPP *defines* a data model for domain name = registrations, > which fits gTLDs and some ccTLDs but not all (note, it does fit the = .nz > data model). If the EPP will require lots of effort all round. It might be better to = pre-empt > this by moving to an alternative to *describe* the registration data expected. If then it was agreed = that > all gTLD registrations must include say a .uk, then this could be added merely by updating the description the > servers send rather than the protocol. and > On 1/24/12 7:02 PM, "Jay Daley" wrote: >=20 >> And finally something for us to think about: >>=20 >> 4. Currently EPP *defines* a data model for domain name = registrations, >> which fits gTLDs and some ccTLDs but not all (note, it does fit the = .nz >> data model). If the ICANN data model changes at any point then = amending >> EPP will require lots of effort all round. It might be better to >> pre-empt this by moving to an alternative approach where the EPP = protocol >> is used to *describe* the registration data expected. If then it was >> agreed that all gTLD registrations must include say a registrant type = as >> they have in .uk, then this could be added merely by updating the >> description the servers send rather than the protocol. +1 - the co.za (and .za) team would be prepared to provide input into = this model. --=20 Regards Theo From jay@nzrs.net.nz Wed Jan 25 16:47:34 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1599D21F8498 for ; Wed, 25 Jan 2012 16:47:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKMFMIWgis6O for ; Wed, 25 Jan 2012 16:47:32 -0800 (PST) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id 2090821F8497 for ; Wed, 25 Jan 2012 16:47:31 -0800 (PST) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 5762A2CE18E; Thu, 26 Jan 2012 13:47:27 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Fw45eii3MZi; Thu, 26 Jan 2012 13:47:27 +1300 (NZDT) Received: from 17.51.69.111.dynamic.snap.net.nz (17.51.69.111.dynamic.snap.net.nz [111.69.51.17]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 35EAD2CE186; Thu, 26 Jan 2012 13:47:23 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Jay Daley In-Reply-To: Date: Thu, 26 Jan 2012 13:48:08 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Gould, James" X-Mailer: Apple Mail (2.1251.1) Cc: "provreg@ietf.org" Subject: Re: [provreg] Standard Extensions X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 00:47:34 -0000 On 26/01/2012, at 3:10 AM, Gould, James wrote: > Could this item be addressed with a Registry EPP Mapping, as I've = shortly > described previously, that provides the meta-data (features and = policies) > for each TLD supported by the EPP server? Possibly, though that is widening it as I was only thinking of = registration data. Specifically I meant an alternative to RFC 5733 that = provides a syntax for a registry to specify what data is expected for = their contact objects. e,g. Using the HTML5 syntax for type, pattern etc so we don't need to = reinvent it and so that a registrar can extract the data and directly = create a web form from it. > Examples of attributes that > could be included in a Registry Info Response is defined below. This = EPP > Mapping would be large and it would need to be flexible to define the > features and policies of Registries that support the RFC's. I would = like > to have the working group, if formed, help define this mapping so that > multiple registries support it and it is useful for the registrars. Reading your mapping below I would suggest that it might be useful split = this out into different chunks and tackle each one separately. My = initial split would be (a) Registration data requirements (b) Nameserver data requirements (c) Nameserver configuration requirements (d) State machine details. What states, how long in each one, etc (e) Services =20 and my thoughts on doing these: - (a) Is what I was on about above - (c) I mentioned in my earlier post as 'delegations/warnings' - (d) may be very ambitious, but then others have successfully done it = in order to produce a fully customisable registry server (co.za for = example!) - (e) sounds impossible to standardise given how much our market is = developing cheers Jay >=20 > O name=20 > O phase=20 > - sunrise? (Optional to support existing TLD's) > + startDate > + endDate > - rights? (Optional to support existing TLD's) > + startDate > + endDate > - open=20 > + startDate > + endDate? > O services=20 > - namespace URI's+ (note - A single EPP connection could support = more > than one TLD with a different set of supported services) > O extensions > - namespace URI's* (note - A single EPP connection could support = more > than one TLD with a different set of supported extensions) > O domain > - level+ > + minLength > + maxLength > + regex+ > + reservedNames? > - ns > + min > + max > - requiredContacts? (Optional to support thin registries) > + registrant > + admin? > + tech? > + billing? > - gracePeriods > + create > + renew > + autoRenew > + transfer > - period > + create > # min (unit) > # max (unit) > + renew=20 > # min (unit) > # max (unit) > + transfer > # min (unit) > # max (unit) > - rgpPeriod=20 > + redemptionPeriod > + pendingRestore > + pendingDelete > - dnssec=20 > + dsData? > # min > # max > # algorithm+ > # digestType+ > + keyData? > # min > # max > # algorithm+ > + maxSigLife > # supported > # default > # min? > # max? > + urgent > # supported > - authInfo > + regex+ > - pendingActions? > - create > - update > - renew > - idn > ... > O Host > ... > O Contact > ... >=20 >=20 > -- >=20 > JG >=20 >=20 >=20 > James Gould > Principal Software Engineer > jgould@verisign.com >=20 > 703-948-3271 (Office) > 12061 Bluemont Way > Reston, VA 20190 > VerisignInc.com >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On 1/24/12 7:02 PM, "Jay Daley" wrote: >=20 >>=20 >> On 19/01/2012, at 1:50 AM, Hollenbeck, Scott wrote: >>=20 >>> Let's assume for a moment that we have enough interest to form a >>> working group focused on the development of a set of standard EPP >>> extensions. If we had to start writing a charter today, what >>> functionality would people most like to see included? >>=20 >> Two extensions that are on my todo list to write up but never get to = the >> top: >>=20 >> 1. Cryptographic signatures. Lots of XML apps do this using a = variety >> of mechanisms: >>=20 >> - PGP in special tags >> - S/MIME as used in XMPP (Jabber) >> - SAMLv2.0 HTTP POST 'SimpleSign=B9 Binding >> - Detached PGP signatures (as per .nz DNRS protocol) >> - but not XML-Dsig =AD complete disaster >> (http://www.cs.auckland.ac.nz/~pgut001/pubs/ xmlsec.txt) >>=20 >> 2. Delegation errors/warnings. A variety of TLDs check the = delegation >> data and the nameservers before entering the data into their zones = (note, >> in .nz we do not). Such checks include whether the nameserver are >> serving the zone, whether the serial numbers are the same, whether = all >> the authorities reported are being configured in the parent zone and = so >> on. =20 >>=20 >> A standard extension around this would be useful for >> - a TLD that does checks advertising that fact (and what those checks = are) >> - reporting failures if doing checks >> - optional support for a TLD that will provide this information to a >> registrar upon request, but not run proactive checks or interfere = with >> the delegation process >>=20 >>=20 >> Then there is the big change to the core protocol I've always wanted = to >> do: >>=20 >> 3. Change the command extension mechanism to use SubstitutionGroup = to >> give first class extensions. >>=20 >>=20 >> And finally something for us to think about: >>=20 >> 4. Currently EPP *defines* a data model for domain name = registrations, >> which fits gTLDs and some ccTLDs but not all (note, it does fit the = .nz >> data model). If the ICANN data model changes at any point then = amending >> EPP will require lots of effort all round. It might be better to >> pre-empt this by moving to an alternative approach where the EPP = protocol >> is used to *describe* the registration data expected. If then it was >> agreed that all gTLD registrations must include say a registrant type = as >> they have in .uk, then this could be added merely by updating the >> description the servers send rather than the protocol. >>=20 >>=20 >> cheers >> Jay >>=20 >> --=20 >> Jay Daley >> Chief Executive >> .nz Registry Services (New Zealand Domain Name Registry Limited) >> desk: +64 4 931 6977 >> mobile: +64 21 678840 >>=20 >> _______________________________________________ >> provreg mailing list >> provreg@ietf.org >> https://www.ietf.org/mailman/listinfo/provreg >=20 --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 From jay@nzrs.net.nz Wed Jan 25 17:32:01 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B94D21F84DF for ; Wed, 25 Jan 2012 17:32:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dq7m-VOb-1lz for ; Wed, 25 Jan 2012 17:32:01 -0800 (PST) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id CFD0E21F84DE for ; Wed, 25 Jan 2012 17:32:00 -0800 (PST) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 612632CE18E for ; Thu, 26 Jan 2012 14:31:59 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MARh3avbBhCh for ; Thu, 26 Jan 2012 14:31:59 +1300 (NZDT) Received: from 17.51.69.111.dynamic.snap.net.nz (17.51.69.111.dynamic.snap.net.nz [111.69.51.17]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 37D7D2CE186 for ; Thu, 26 Jan 2012 14:31:59 +1300 (NZDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1251.1) From: Jay Daley In-Reply-To: Date: Thu, 26 Jan 2012 14:32:48 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: provreg@ietf.org X-Mailer: Apple Mail (2.1251.1) Subject: Re: [provreg] Standard Extensions X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 01:32:01 -0000 On 25/01/2012, at 1:02 PM, Jay Daley wrote: > Then there is the big change to the core protocol I've always wanted = to do: >=20 > 3. Change the command extension mechanism to use SubstitutionGroup to = give first class extensions. =20 To explain this a bit better, here is some XML Schema: =20 =20 =20 =20 =20 =20 cheers Jay --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840