On Fri, Aug 17, 2012 at 1:18 AM, Gavin B= rown <gavin.brown@centralnic.com> wrote:

On 16/08/2012 16:09, Wil Tan wrote:
> On Thu, Aug 16, 2012 at 10:03 PM, Gould, James <JGould@verisign.com

> <mailto:JGould@verisign.com>> wrote:
>
> =C2=A0 =C2=A0 I agree that we should predefine as many known statuses = as possible
> =C2=A0 =C2=A0 in the draft as an enumerated list. =C2=A0How about if w= e take the
> =C2=A0 =C2=A0 approach of the launch phases with the inclusion of a &q= uot;custom"
> =C2=A0 =C2=A0 status and an optional name attribute that can be used f= or define a
> =C2=A0 =C2=A0 sub-status of one of the enumerated statuses or used to = define a
> =C2=A0 =C2=A0 completely custom status? =C2=A0We can expand the enumer= ated list now for
> =C2=A0 =C2=A0 auction statuses if those statuses are known. =C2=A0Trun= g, do you have
> =C2=A0 =C2=A0 any specific statuses that should be added now? =C2=A0Wo= uld this meet the
> =C2=A0 =C2=A0 needs of a predefined list of statuses with some form of= extensibility?
>
>
> Just as a data point, these were the statuses that Cloud Registry used=
> when we last did our sunrise and land rush auctions. They were certain= ly
> adequate for us. Also, while not technically elegant, I suspect we can=
> satisfy the majority of use cases by conveying fine-grained statuses > with <launch:status> textual content:
>
> =C2=A0 <launch:status s=3D"validated">auction in-progr= ess</launch:status>

Wouldn't this effectively be another free text element that serve= rs will
overload with their own special meanings? If anything that appears
inside that element requires client processing, registrars will be in
the same situation as I previously described.

<= br>

Yes, that's why I said it's not elegant, but my (poss= ibly wrong) assumption was that the textual description won't be used b= y registrars for automation. It would primarily be=C2=A0used for answering = customer queries about "I applied for this domain, do I have it yet an= d if not, why not?" The enumerated "s" attribute values are = what matters to the state machine, and it's important to keep it simple= .

I agree that we should try to capture statuses that reg= istries might need, rather than providing yet another extensibility point.<= /div>

.wil

--e89a8f23596b4be8b404c763cd85-- From gavin.brown@centralnic.com Thu Aug 16 08:40: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 D067D21F85FF for ; Thu, 16 Aug 2012 08:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjCDwEJOJmEA for ; Thu, 16 Aug 2012 08:40:46 -0700 (PDT) Received: from smtp.centralnic.com (smtp.centralnic.com [193.105.170.131]) by ietfa.amsl.com (Postfix) with ESMTP id 294E521F85F0 for ; Thu, 16 Aug 2012 08:40:46 -0700 (PDT) Received: from Gavins-iMac.local (82-68-174-118.in-addr.centralnic.net [82.68.174.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTP id C5B41712DB9; Thu, 16 Aug 2012 15:40:44 +0000 (UTC) Message-ID: <502D147C.2030307@centralnic.com> Date: Thu, 16 Aug 2012 16:40:44 +0100 From: Gavin Brown User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Wil Tan References: <82E430196867974ABF392D9B8BEAA53F5141CA14@STNTEXCH02.cis.neustar.com> <20120816094139.A6C9433C0D0@merlin.blacknight.ie> <20120816102500.GR29229@nineve.blacknight.ie> <502D0F55.50909@centralnic.com> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "provreg@ietf.org" Subject: Re: [provreg] Launch Phase EPP Extension Version 02 Posted X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 15:40:46 -0000 On 16/08/2012 16:35, Wil Tan wrote: > Yes, that's why I said it's not elegant, but my (possibly wrong) > assumption was that the textual description won't be used by registrars > for automation. It seems more likely to me that registries would decide to overload this field and then compel registrars to create business logic to handle it. However, I don't think that his has happened with the element for domains, contacts, and hosts (unless someone wants to correct me), so perhaps I am overstating the risks. 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 keith@blacknight.com Thu Aug 16 08:57: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 B627921F855D for ; Thu, 16 Aug 2012 08:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHCKPG1ePDHr for ; Thu, 16 Aug 2012 08:57:42 -0700 (PDT) Received: from nineve.blacknight.ie (nineve.blacknight.ie [81.17.243.129]) by ietfa.amsl.com (Postfix) with ESMTP id 032FB21F8464 for ; Thu, 16 Aug 2012 08:57:41 -0700 (PDT) Received: by nineve.blacknight.ie (Postfix, from userid 1010) id 59E9C5806B; Thu, 16 Aug 2012 16:57:39 +0100 (IST) Date: Thu, 16 Aug 2012 16:57:39 +0100 From: Keith Gaughan To: "Gould, James" Message-ID: <20120816155739.GS29229@nineve.blacknight.ie> References: <82E430196867974ABF392D9B8BEAA53F5141CA14@STNTEXCH02.cis.neustar.com> <20120816094139.A6C9433C0D0@merlin.blacknight.ie> <20120816102500.GR29229@nineve.blacknight.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "provreg@ietf.org" Subject: Re: [provreg] Launch Phase EPP Extension Version 02 Posted X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 15:57:42 -0000 On Thu, Aug 16, 2012 at 12:03:08PM +0000, Gould, James wrote: > I agree that we should predefine as many known statuses as possible in the > draft as an enumerated list. How about if we take the approach of the launch > phases with the inclusion of a "custom" status and an optional name attribute > that can be used for define a sub-status of one of the enumerated statuses or > used to define a completely custom status? We can expand the enumerated list > now for auction statuses if those statuses are known. Trung, do you have any > specific statuses that should be added now? Would this meet the needs of a > predefined list of statuses with some form of extensibility? The problem there is that it essentially makes the statuses freeform again, just in a more awkward fashion. This kind of thing is harmful to interop. It's better to have a well-defined set of statuses and a well-defined set of state transitions that nobody is absolutely happy with but everyone at least agrees is good enough than a mess of mutually slightly-incompatible riffs off of the same theme. I'd prefer to say YAGNI to this unless a strong case can be made to the contrary. K. -- Keith Gaughan, Development Lead PGP/GPG key ID: 82AC3634 Blacknight Internet Solutions Ltd. 12A Barrowside Business Park, Carlow, Ireland Registered in Ireland, Company No.: 370845 From keith@blacknight.com Thu Aug 16 09:14: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 36FB921F863B for ; Thu, 16 Aug 2012 09:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETQuVlou2cWT for ; Thu, 16 Aug 2012 09:14:02 -0700 (PDT) Received: from nineve.blacknight.ie (nineve.blacknight.ie [81.17.243.129]) by ietfa.amsl.com (Postfix) with ESMTP id 3407C21F8532 for ; Thu, 16 Aug 2012 09:14:02 -0700 (PDT) Received: by nineve.blacknight.ie (Postfix, from userid 1010) id 3D0D65806B; Thu, 16 Aug 2012 17:14:01 +0100 (IST) Date: Thu, 16 Aug 2012 17:14:01 +0100 From: Keith Gaughan To: provreg@ietf.org Message-ID: <20120816161401.GT29229@nineve.blacknight.ie> References: <82E430196867974ABF392D9B8BEAA53F5141CA14@STNTEXCH02.cis.neustar.com> <20120816094139.A6C9433C0D0@merlin.blacknight.ie> <20120816102500.GR29229@nineve.blacknight.ie> <502D0F55.50909@centralnic.com> <502D147C.2030307@centralnic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <502D147C.2030307@centralnic.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [provreg] Launch Phase EPP Extension Version 02 Posted X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 16:14:03 -0000 On Thu, Aug 16, 2012 at 04:40:44PM +0100, Gavin Brown wrote: > On 16/08/2012 16:35, Wil Tan wrote: > > Yes, that's why I said it's not elegant, but my (possibly wrong) > > assumption was that the textual description won't be used by registrars > > for automation. > > It seems more likely to me that registries would decide to overload this > field and then compel registrars to create business logic to handle it. > > However, I don't think that his has happened with the element > for domains, contacts, and hosts (unless someone wants to correct me), > so perhaps I am overstating the risks. What's happened in those cases is that the registry operators create their own extensions to fit the extra semantics they--being the beautiful and unique snowflakes that they are--feel they absolutely can't possibly live without. You're not at all overstating the risks. The thing that gets missed in this kind of discussion is that when a registry has discretion over the implementation of some element of EPP or a non-optional extension or object mapping, they effectively multiply the amount of work that needs to be done to implement that by the number of registrars integrated with them. The more that can be done so that registrars don't have to implement dozens of subtly-incompatible variations on the same spec. K. -- Keith Gaughan, Development Lead PGP/GPG key ID: 82AC3634 Blacknight Internet Solutions Ltd. 12A Barrowside Business Park, Carlow, Ireland Registered in Ireland, Company No.: 370845 From trung.tran@neustar.biz Thu Aug 16 15:12: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 6860111E80B8 for ; Thu, 16 Aug 2012 15:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.822 X-Spam-Level: X-Spam-Status: No, score=-5.822 tagged_above=-999 required=5 tests=[AWL=0.776, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgJg3e6yc75D for ; Thu, 16 Aug 2012 15:12:43 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id E5A3B11E80AE for ; Thu, 16 Aug 2012 15:12:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1345154922; x=1660511785; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=YTaImP5b3IDUH8bXtt2Z/+pOVTBQVKCSu3nIvyorH54=; b=Lm/1U1rJQoXF8xW3gk+agmzZreXraggQgnLfw6OOezw+yawcn8IOPipt5EvZzx GrxF5VgQctc63hiFTZTVL5Og== Received: from ([10.31.13.242]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.9964701; Thu, 16 Aug 2012 18:08:41 -0400 Received: from STNTEXCH02.cis.neustar.com ([fe80::28fd:d8c6:49f0:619b]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Thu, 16 Aug 2012 18:12:36 -0400 From: "Tran, Trung" To: 'Wil Tan' , Gavin Brown Date: Thu, 16 Aug 2012 18:12:35 -0400 Thread-Topic: [provreg] Launch Phase EPP Extension Version 02 Posted Thread-Index: Ac17xOg4ZTns5MqAR8KzjnovZ18IrQAABayw Message-ID: <82E430196867974ABF392D9B8BEAA53F5141CA2B@STNTEXCH02.cis.neustar.com> References: <82E430196867974ABF392D9B8BEAA53F5141CA14@STNTEXCH02.cis.neustar.com> <20120816094139.A6C9433C0D0@merlin.blacknight.ie> <20120816102500.GR29229@nineve.blacknight.ie> <502D0F55.50909@centralnic.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: fiqoJeKLxOQHM0bmZoYX4g== Content-Type: multipart/alternative; boundary="_000_82E430196867974ABF392D9B8BEAA53F5141CA2BSTNTEXCH02cisne_" MIME-Version: 1.0 Cc: "provreg@ietf.org" Subject: Re: [provreg] Launch Phase EPP Extension Version 02 Posted X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 22:12:44 -0000 --_000_82E430196867974ABF392D9B8BEAA53F5141CA2BSTNTEXCH02cisne_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIHRoZSBhZHZhbnRhZ2VzIG9mIGhhdmluZyBlbnVtZXJhdGVkIGxpc3Qgb2Yg c3RhdHVzZXMuICBIb3dldmVyIEkgY2Fu4oCZdCBiZWxpZXZlIHRoYXQgd2Uga25vdyBlbm91Z2gg YWJvdXQgZWFjaCByZWdpc3RyeSBwb2xpY3kgdGhhdCB3b3VsZCB0YWtlIGludG8gYWNjb3VudCBh bGwgb2YgdGhlIGRpZmZlcmVudCBzdGF0dXMgdmFyaWF0aW9ucy4gIFNvIHNvbWVvbmUgd2lsbCBl bmQgdXAgdXNpbmcgY3VzdG9tIEVQUCBleHRlbnNpb24gdG8gY2FwdHVyZSB0aGVzZSBvdGhlciBz dGF0dXNlcyB0aGF0IHdlcmUgbm90IGRlZmluZWQgaW4gdGhpcyBkcmFmdC4NCg0KQ29uY2Vybmlu ZyBhdWN0aW9uIHJlbGF0ZWQgc3RhdHVzZXMsIHdlIGhhdmUgdXNlZCBhdWN0aW9uIHBlbmRpbmcs IGF1Y3Rpb24gYXdhcmRlZCwgYW5kIGF1Y3Rpb24gcmVqZWN0ZWQuICBJZiB0aGVyZSBhcmUgb3Ro ZXIgd2F5cyB0byBjYXB0dXJlIHRoaXMgaW5mbyBiZXNpZGVzIHN0YXR1cywgcGxlYXNlIGxldCBt ZSBrbm93Lg0KDQpUcnVuZw0KDQoNCkZyb206IHByb3ZyZWctYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOnByb3ZyZWctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFdpbCBUYW4NClNlbnQ6 IFRodXJzZGF5LCBBdWd1c3QgMTYsIDIwMTIgMTE6MzUgQU0NClRvOiBHYXZpbiBCcm93bg0KQ2M6 IHByb3ZyZWdAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbcHJvdnJlZ10gTGF1bmNoIFBoYXNlIEVQ UCBFeHRlbnNpb24gVmVyc2lvbiAwMiBQb3N0ZWQNCg0KDQpPbiBGcmksIEF1ZyAxNywgMjAxMiBh dCAxOjE4IEFNLCBHYXZpbiBCcm93biA8Z2F2aW4uYnJvd25AY2VudHJhbG5pYy5jb208bWFpbHRv OmdhdmluLmJyb3duQGNlbnRyYWxuaWMuY29tPj4gd3JvdGU6DQoNCk9uIDE2LzA4LzIwMTIgMTY6 MDksIFdpbCBUYW4gd3JvdGU6DQo+IE9uIFRodSwgQXVnIDE2LCAyMDEyIGF0IDEwOjAzIFBNLCBH b3VsZCwgSmFtZXMgPEpHb3VsZEB2ZXJpc2lnbi5jb208bWFpbHRvOkpHb3VsZEB2ZXJpc2lnbi5j b20+DQo+IDxtYWlsdG86SkdvdWxkQHZlcmlzaWduLmNvbTxtYWlsdG86SkdvdWxkQHZlcmlzaWdu LmNvbT4+PiB3cm90ZToNCj4NCj4gICAgIEkgYWdyZWUgdGhhdCB3ZSBzaG91bGQgcHJlZGVmaW5l IGFzIG1hbnkga25vd24gc3RhdHVzZXMgYXMgcG9zc2libGUNCj4gICAgIGluIHRoZSBkcmFmdCBh cyBhbiBlbnVtZXJhdGVkIGxpc3QuICBIb3cgYWJvdXQgaWYgd2UgdGFrZSB0aGUNCj4gICAgIGFw cHJvYWNoIG9mIHRoZSBsYXVuY2ggcGhhc2VzIHdpdGggdGhlIGluY2x1c2lvbiBvZiBhICJjdXN0 b20iDQo+ICAgICBzdGF0dXMgYW5kIGFuIG9wdGlvbmFsIG5hbWUgYXR0cmlidXRlIHRoYXQgY2Fu IGJlIHVzZWQgZm9yIGRlZmluZSBhDQo+ICAgICBzdWItc3RhdHVzIG9mIG9uZSBvZiB0aGUgZW51 bWVyYXRlZCBzdGF0dXNlcyBvciB1c2VkIHRvIGRlZmluZSBhDQo+ICAgICBjb21wbGV0ZWx5IGN1 c3RvbSBzdGF0dXM/ICBXZSBjYW4gZXhwYW5kIHRoZSBlbnVtZXJhdGVkIGxpc3Qgbm93IGZvcg0K PiAgICAgYXVjdGlvbiBzdGF0dXNlcyBpZiB0aG9zZSBzdGF0dXNlcyBhcmUga25vd24uICBUcnVu ZywgZG8geW91IGhhdmUNCj4gICAgIGFueSBzcGVjaWZpYyBzdGF0dXNlcyB0aGF0IHNob3VsZCBi ZSBhZGRlZCBub3c/ICBXb3VsZCB0aGlzIG1lZXQgdGhlDQo+ICAgICBuZWVkcyBvZiBhIHByZWRl ZmluZWQgbGlzdCBvZiBzdGF0dXNlcyB3aXRoIHNvbWUgZm9ybSBvZiBleHRlbnNpYmlsaXR5Pw0K Pg0KPg0KPiBKdXN0IGFzIGEgZGF0YSBwb2ludCwgdGhlc2Ugd2VyZSB0aGUgc3RhdHVzZXMgdGhh dCBDbG91ZCBSZWdpc3RyeSB1c2VkDQo+IHdoZW4gd2UgbGFzdCBkaWQgb3VyIHN1bnJpc2UgYW5k IGxhbmQgcnVzaCBhdWN0aW9ucy4gVGhleSB3ZXJlIGNlcnRhaW5seQ0KPiBhZGVxdWF0ZSBmb3Ig dXMuIEFsc28sIHdoaWxlIG5vdCB0ZWNobmljYWxseSBlbGVnYW50LCBJIHN1c3BlY3Qgd2UgY2Fu DQo+IHNhdGlzZnkgdGhlIG1ham9yaXR5IG9mIHVzZSBjYXNlcyBieSBjb252ZXlpbmcgZmluZS1n cmFpbmVkIHN0YXR1c2VzDQo+IHdpdGggPGxhdW5jaDpzdGF0dXM+IHRleHR1YWwgY29udGVudDoN Cj4NCj4gICA8bGF1bmNoOnN0YXR1cyBzPSJ2YWxpZGF0ZWQiPmF1Y3Rpb24gaW4tcHJvZ3Jlc3M8 L2xhdW5jaDpzdGF0dXM+DQpXb3VsZG4ndCB0aGlzIGVmZmVjdGl2ZWx5IGJlIGFub3RoZXIgZnJl ZSB0ZXh0IGVsZW1lbnQgdGhhdCBzZXJ2ZXJzIHdpbGwNCm92ZXJsb2FkIHdpdGggdGhlaXIgb3du IHNwZWNpYWwgbWVhbmluZ3M/IElmIGFueXRoaW5nIHRoYXQgYXBwZWFycw0KaW5zaWRlIHRoYXQg ZWxlbWVudCByZXF1aXJlcyBjbGllbnQgcHJvY2Vzc2luZywgcmVnaXN0cmFycyB3aWxsIGJlIGlu DQp0aGUgc2FtZSBzaXR1YXRpb24gYXMgSSBwcmV2aW91c2x5IGRlc2NyaWJlZC4NCg0KDQpZZXMs IHRoYXQncyB3aHkgSSBzYWlkIGl0J3Mgbm90IGVsZWdhbnQsIGJ1dCBteSAocG9zc2libHkgd3Jv bmcpIGFzc3VtcHRpb24gd2FzIHRoYXQgdGhlIHRleHR1YWwgZGVzY3JpcHRpb24gd29uJ3QgYmUg dXNlZCBieSByZWdpc3RyYXJzIGZvciBhdXRvbWF0aW9uLiBJdCB3b3VsZCBwcmltYXJpbHkgYmUg dXNlZCBmb3IgYW5zd2VyaW5nIGN1c3RvbWVyIHF1ZXJpZXMgYWJvdXQgIkkgYXBwbGllZCBmb3Ig dGhpcyBkb21haW4sIGRvIEkgaGF2ZSBpdCB5ZXQgYW5kIGlmIG5vdCwgd2h5IG5vdD8iIFRoZSBl bnVtZXJhdGVkICJzIiBhdHRyaWJ1dGUgdmFsdWVzIGFyZSB3aGF0IG1hdHRlcnMgdG8gdGhlIHN0 YXRlIG1hY2hpbmUsIGFuZCBpdCdzIGltcG9ydGFudCB0byBrZWVwIGl0IHNpbXBsZS4NCg0KSSBh Z3JlZSB0aGF0IHdlIHNob3VsZCB0cnkgdG8gY2FwdHVyZSBzdGF0dXNlcyB0aGF0IHJlZ2lzdHJp ZXMgbWlnaHQgbmVlZCwgcmF0aGVyIHRoYW4gcHJvdmlkaW5nIHlldCBhbm90aGVyIGV4dGVuc2li aWxpdHkgcG9pbnQuDQoNCi53aWwNCg== --_000_82E430196867974ABF392D9B8BEAA53F5141CA2BSTNTEXCH02cisne_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBs ZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz5JIGFncmVlIHdpdGggdGhlIGFkdmFudGFnZXMgb2YgaGF2aW5nIGVudW1lcmF0 ZWQgbGlzdCBvZiBzdGF0dXNlcy7CoCBIb3dldmVyIEkgY2Fu4oCZdCBiZWxpZXZlIHRoYXQgd2Ug a25vdyBlbm91Z2ggYWJvdXQgZWFjaCByZWdpc3RyeSBwb2xpY3kgdGhhdCB3b3VsZCB0YWtlIGlu dG8gYWNjb3VudCBhbGwgb2YgdGhlIGRpZmZlcmVudCBzdGF0dXMgdmFyaWF0aW9ucy7CoCBTbyBz b21lb25lIHdpbGwgZW5kIHVwIHVzaW5nIGN1c3RvbSBFUFAgZXh0ZW5zaW9uIHRvIGNhcHR1cmUg dGhlc2Ugb3RoZXIgc3RhdHVzZXMgdGhhdCB3ZXJlIG5vdCBkZWZpbmVkIGluIHRoaXMgZHJhZnQu PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz5Db25jZXJuaW5nIGF1Y3Rpb24gcmVsYXRlZCBzdGF0dXNlcywg d2UgaGF2ZSB1c2VkIGF1Y3Rpb24gcGVuZGluZywgYXVjdGlvbiBhd2FyZGVkLCBhbmQgYXVjdGlv biByZWplY3RlZC7CoCBJZiB0aGVyZSBhcmUgb3RoZXIgd2F5cyB0byBjYXB0dXJlIHRoaXMgaW5m byBiZXNpZGVzIHN0YXR1cywgcGxlYXNlIGxldCBtZSBrbm93LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ VHJ1bmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2 IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIic+IHByb3ZyZWctYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnByb3Zy ZWctYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mIDwvYj5XaWwgVGFuPGJyPjxiPlNl bnQ6PC9iPiBUaHVyc2RheSwgQXVndXN0IDE2LCAyMDEyIDExOjM1IEFNPGJyPjxiPlRvOjwvYj4g R2F2aW4gQnJvd248YnI+PGI+Q2M6PC9iPiBwcm92cmVnQGlldGYub3JnPGJyPjxiPlN1YmplY3Q6 PC9iPiBSZTogW3Byb3ZyZWddIExhdW5jaCBQaGFzZSBFUFAgRXh0ZW5zaW9uIFZlcnNpb24gMDIg UG9zdGVkPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpw PiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206 MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5PbiBG cmksIEF1ZyAxNywgMjAxMiBhdCAxOjE4IEFNLCBHYXZpbiBCcm93biAmbHQ7PGEgaHJlZj0ibWFp bHRvOmdhdmluLmJyb3duQGNlbnRyYWxuaWMuY29tIiB0YXJnZXQ9Il9ibGFuayI+Z2F2aW4uYnJv d25AY2VudHJhbG5pYy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48YnI+T24gMTYvMDgvMjAxMiAxNjowOSwgV2lsIFRhbiB3cm90ZTo8YnI+ Jmd0OyBPbiBUaHUsIEF1ZyAxNiwgMjAxMiBhdCAxMDowMyBQTSwgR291bGQsIEphbWVzICZsdDs8 YSBocmVmPSJtYWlsdG86SkdvdWxkQHZlcmlzaWduLmNvbSI+SkdvdWxkQHZlcmlzaWduLmNvbTwv YT48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFy Z2luLWJvdHRvbToxMi4wcHQnPiZndDsgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86SkdvdWxk QHZlcmlzaWduLmNvbSI+SkdvdWxkQHZlcmlzaWduLmNvbTwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnI+ Jmd0Ozxicj4mZ3Q7ICZuYnNwOyAmbmJzcDsgSSBhZ3JlZSB0aGF0IHdlIHNob3VsZCBwcmVkZWZp bmUgYXMgbWFueSBrbm93biBzdGF0dXNlcyBhcyBwb3NzaWJsZTxicj4mZ3Q7ICZuYnNwOyAmbmJz cDsgaW4gdGhlIGRyYWZ0IGFzIGFuIGVudW1lcmF0ZWQgbGlzdC4gJm5ic3A7SG93IGFib3V0IGlm IHdlIHRha2UgdGhlPGJyPiZndDsgJm5ic3A7ICZuYnNwOyBhcHByb2FjaCBvZiB0aGUgbGF1bmNo IHBoYXNlcyB3aXRoIHRoZSBpbmNsdXNpb24gb2YgYSAmcXVvdDtjdXN0b20mcXVvdDs8YnI+Jmd0 OyAmbmJzcDsgJm5ic3A7IHN0YXR1cyBhbmQgYW4gb3B0aW9uYWwgbmFtZSBhdHRyaWJ1dGUgdGhh dCBjYW4gYmUgdXNlZCBmb3IgZGVmaW5lIGE8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7IHN1Yi1zdGF0 dXMgb2Ygb25lIG9mIHRoZSBlbnVtZXJhdGVkIHN0YXR1c2VzIG9yIHVzZWQgdG8gZGVmaW5lIGE8 YnI+Jmd0OyAmbmJzcDsgJm5ic3A7IGNvbXBsZXRlbHkgY3VzdG9tIHN0YXR1cz8gJm5ic3A7V2Ug Y2FuIGV4cGFuZCB0aGUgZW51bWVyYXRlZCBsaXN0IG5vdyBmb3I8YnI+Jmd0OyAmbmJzcDsgJm5i c3A7IGF1Y3Rpb24gc3RhdHVzZXMgaWYgdGhvc2Ugc3RhdHVzZXMgYXJlIGtub3duLiAmbmJzcDtU cnVuZywgZG8geW91IGhhdmU8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7IGFueSBzcGVjaWZpYyBzdGF0 dXNlcyB0aGF0IHNob3VsZCBiZSBhZGRlZCBub3c/ICZuYnNwO1dvdWxkIHRoaXMgbWVldCB0aGU8 YnI+Jmd0OyAmbmJzcDsgJm5ic3A7IG5lZWRzIG9mIGEgcHJlZGVmaW5lZCBsaXN0IG9mIHN0YXR1 c2VzIHdpdGggc29tZSBmb3JtIG9mIGV4dGVuc2liaWxpdHk/PGJyPiZndDs8YnI+Jmd0Ozxicj4m Z3Q7IEp1c3QgYXMgYSBkYXRhIHBvaW50LCB0aGVzZSB3ZXJlIHRoZSBzdGF0dXNlcyB0aGF0IENs b3VkIFJlZ2lzdHJ5IHVzZWQ8YnI+Jmd0OyB3aGVuIHdlIGxhc3QgZGlkIG91ciBzdW5yaXNlIGFu ZCBsYW5kIHJ1c2ggYXVjdGlvbnMuIFRoZXkgd2VyZSBjZXJ0YWlubHk8YnI+Jmd0OyBhZGVxdWF0 ZSBmb3IgdXMuIEFsc28sIHdoaWxlIG5vdCB0ZWNobmljYWxseSBlbGVnYW50LCBJIHN1c3BlY3Qg d2UgY2FuPGJyPiZndDsgc2F0aXNmeSB0aGUgbWFqb3JpdHkgb2YgdXNlIGNhc2VzIGJ5IGNvbnZl eWluZyBmaW5lLWdyYWluZWQgc3RhdHVzZXM8YnI+Jmd0OyB3aXRoICZsdDtsYXVuY2g6c3RhdHVz Jmd0OyB0ZXh0dWFsIGNvbnRlbnQ6PGJyPiZndDs8YnI+Jmd0OyAmbmJzcDsgJmx0O2xhdW5jaDpz dGF0dXMgcz0mcXVvdDt2YWxpZGF0ZWQmcXVvdDsmZ3Q7YXVjdGlvbiBpbi1wcm9ncmVzcyZsdDsv bGF1bmNoOnN0YXR1cyZndDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ V291bGRuJ3QgdGhpcyBlZmZlY3RpdmVseSBiZSBhbm90aGVyIGZyZWUgdGV4dCBlbGVtZW50IHRo YXQgc2VydmVycyB3aWxsPGJyPm92ZXJsb2FkIHdpdGggdGhlaXIgb3duIHNwZWNpYWwgbWVhbmlu Z3M/IElmIGFueXRoaW5nIHRoYXQgYXBwZWFyczxicj5pbnNpZGUgdGhhdCBlbGVtZW50IHJlcXVp cmVzIGNsaWVudCBwcm9jZXNzaW5nLCByZWdpc3RyYXJzIHdpbGwgYmUgaW48YnI+dGhlIHNhbWUg c2l0dWF0aW9uIGFzIEkgcHJldmlvdXNseSBkZXNjcmliZWQuPG86cD48L286cD48L3A+PGRpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD5ZZXMsIHRoYXQncyB3aHkgSSBzYWlkIGl0J3Mgbm90IGVsZWdhbnQs IGJ1dCBteSAocG9zc2libHkgd3JvbmcpIGFzc3VtcHRpb24gd2FzIHRoYXQgdGhlIHRleHR1YWwg ZGVzY3JpcHRpb24gd29uJ3QgYmUgdXNlZCBieSByZWdpc3RyYXJzIGZvciBhdXRvbWF0aW9uLiBJ dCB3b3VsZCBwcmltYXJpbHkgYmUmbmJzcDt1c2VkIGZvciBhbnN3ZXJpbmcgY3VzdG9tZXIgcXVl cmllcyBhYm91dCAmcXVvdDtJIGFwcGxpZWQgZm9yIHRoaXMgZG9tYWluLCBkbyBJIGhhdmUgaXQg eWV0IGFuZCBpZiBub3QsIHdoeSBub3Q/JnF1b3Q7IFRoZSBlbnVtZXJhdGVkICZxdW90O3MmcXVv dDsgYXR0cmlidXRlIHZhbHVlcyBhcmUgd2hhdCBtYXR0ZXJzIHRvIHRoZSBzdGF0ZSBtYWNoaW5l LCBhbmQgaXQncyBpbXBvcnRhbnQgdG8ga2VlcCBpdCBzaW1wbGUuPG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+SSBhZ3JlZSB0aGF0IHdlIHNob3VsZCB0cnkgdG8gY2FwdHVy ZSBzdGF0dXNlcyB0aGF0IHJlZ2lzdHJpZXMgbWlnaHQgbmVlZCwgcmF0aGVyIHRoYW4gcHJvdmlk aW5nIHlldCBhbm90aGVyIGV4dGVuc2liaWxpdHkgcG9pbnQuPG86cD48L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+LndpbDxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvZGl2Pjwv Ym9keT48L2h0bWw+ --_000_82E430196867974ABF392D9B8BEAA53F5141CA2BSTNTEXCH02cisne_-- From JGould@verisign.com Thu Aug 16 15:18: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 11D4821F8582 for ; Thu, 16 Aug 2012 15:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.432 X-Spam-Level: X-Spam-Status: No, score=-6.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7aIg1YNQhyZ for ; Thu, 16 Aug 2012 15:18:23 -0700 (PDT) Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6F821F8499 for ; Thu, 16 Aug 2012 15:18:16 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKUC1xp8sV2Mgg6lFkCNUnK5e7Hv4uk31w@postini.com; Thu, 16 Aug 2012 15:18:22 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q7GMICm9004828 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Aug 2012 18:18:12 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Thu, 16 Aug 2012 18:18:12 -0400 From: "Gould, James" To: Keith Gaughan , "provreg@ietf.org" Thread-Topic: [provreg] Launch Phase EPP Extension Version 02 Posted Thread-Index: AQHNe5lkJJjhYFaphkGrGRzSIlyiJpdcVN5xgAB5YoCAAAJ1gIAABKoAgAABewCAAAlMgIAAHOHR Date: Thu, 16 Aug 2012 22:18:11 +0000 Message-ID: References: <82E430196867974ABF392D9B8BEAA53F5141CA14@STNTEXCH02.cis.neustar.com> <20120816094139.A6C9433C0D0@merlin.blacknight.ie> <20120816102500.GR29229@nineve.blacknight.ie> <502D0F55.50909@centralnic.com> <502D147C.2030307@centralnic.com>, <20120816161401.GT29229@nineve.blacknight.ie> In-Reply-To: <20120816161401.GT29229@nineve.blacknight.ie> 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 Subject: Re: [provreg] Launch Phase EPP Extension Version 02 Posted X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 22:18:24 -0000 In reviewing the thread on the status element of the draft, these are the f= ollowing options:=0A= =0A= 1. Keep the status element as a non-extensible enumerated list. =0A= 2. Change the status element to use a enumerated list of status values as a= n attribute and allow for the element text to be free-form. The free-form = text could be returned to the registrant. =0A= 3. Add an optional name attribute to the status element along with a "custo= m" status enumerated value to support sub-statuses or custom statuses simil= ar to the approach taken in the draft with the phase element. =0A= 4. Make the status element a token instead of a enumerated list. I don't b= elieve anyone really proposed this, but I left it in for completeness. =0A= =0A= I would like to have all of the possible known statuses defined in the draf= t, where if we did a good job in gathering them all, option #1 is the best.= If we don't do a good job of gathering them all then some form of extensi= bility like option #3 would be needed to enable adding the missing statuses= without requiring the creation of a registry specific custom extension. I= believe option #2 is close to using the optional name attribute of option = #3 as a sub-status with a slightly different intent of not using the value = to drive client-side logic. =0A= =0A= Does anyone know of any concrete statuses that need to be added to help wit= h options #1, #2, and #3? I don't want the draft to make it too difficult = for the clients to handle and I don't want it to be too restrictive to meet= specific registry policies that would result in the creation of additional= custom extensions. I believe option #3 is a good compromise, but that's p= robably obvious since I was the one that originally proposed it. =0A= =0A= I would like to hear from the list if there are any additional options to c= onsider and which option is preferred. =0A= =0A= Jim =0A= =0A= ________________________________________=0A= From: provreg-bounces@ietf.org [provreg-bounces@ietf.org] on behalf of Keit= h Gaughan [keith@blacknight.com]=0A= Sent: Thursday, August 16, 2012 12:14 PM=0A= To: provreg@ietf.org=0A= Subject: Re: [provreg] Launch Phase EPP Extension Version 02 Posted=0A= =0A= On Thu, Aug 16, 2012 at 04:40:44PM +0100, Gavin Brown wrote:=0A= > On 16/08/2012 16:35, Wil Tan wrote:=0A= > > Yes, that's why I said it's not elegant, but my (possibly wrong)=0A= > > assumption was that the textual description won't be used by registrars= =0A= > > for automation.=0A= >=0A= > It seems more likely to me that registries would decide to overload this= =0A= > field and then compel registrars to create business logic to handle it.= =0A= >=0A= > However, I don't think that his has happened with the element=0A= > for domains, contacts, and hosts (unless someone wants to correct me),=0A= > so perhaps I am overstating the risks.=0A= =0A= What's happened in those cases is that the registry operators create their = own=0A= extensions to fit the extra semantics they--being the beautiful and unique= =0A= snowflakes that they are--feel they absolutely can't possibly live without.= =0A= =0A= You're not at all overstating the risks. The thing that gets missed in this= kind=0A= of discussion is that when a registry has discretion over the implementatio= n of=0A= some element of EPP or a non-optional extension or object mapping, they=0A= effectively multiply the amount of work that needs to be done to implement = that=0A= by the number of registrars integrated with them. The more that can be done= so=0A= that registrars don't have to implement dozens of subtly-incompatible varia= tions=0A= on the same spec.=0A= =0A= K.=0A= =0A= --=0A= Keith Gaughan, Development Lead=0A= PGP/GPG key ID: 82AC3634=0A= Blacknight Internet Solutions Ltd. =0A= 12A Barrowside Business Park, Carlow, Ireland=0A= Registered in Ireland, Company No.: 370845=0A= _______________________________________________=0A= provreg mailing list=0A= provreg@ietf.org=0A= https://www.ietf.org/mailman/listinfo/provreg=0A= From trung.tran@neustar.biz Fri Aug 17 11:21: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 0A2F721F8462 for ; Fri, 17 Aug 2012 11:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.21 X-Spam-Level: X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[AWL=0.389, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KiH+7IOYstc5 for ; Fri, 17 Aug 2012 11:21:18 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id C71EE21F845F for ; Fri, 17 Aug 2012 11:21:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1345227940; x=1660580962; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=BGAkrdmtrif48ecYkhOQ0 FtLPgYfc2h4EdUx9tlAp/M=; b=Y+rPZjvW3l17K3cTfxcJDWNBG+UcLyQ/7qzYi IYc4VxO9AFVJXfAvLcAQWjt2ZstPq30Tlja7SoDWfSODIfBdQ== Received: from ([10.31.13.228]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.13190007; Fri, 17 Aug 2012 14:25:39 -0400 Received: from STNTEXCH02.cis.neustar.com ([fe80::28fd:d8c6:49f0:619b]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Fri, 17 Aug 2012 14:21:04 -0400 From: "Tran, Trung" Date: Fri, 17 Aug 2012 14:21:02 -0400 Thread-Topic: [provreg] Launch Phase EPP Extension Version 02 Posted Thread-Index: AQHNe5lkJJjhYFaphkGrGRzSIlyiJpdcVN5xgAB5YoCAAAJ1gIAABKoAgAABewCAAAlMgIAAHOHRgAE8XvA= Message-ID: <82E430196867974ABF392D9B8BEAA53F5141CA3C@STNTEXCH02.cis.neustar.com> References: <82E430196867974ABF392D9B8BEAA53F5141CA14@STNTEXCH02.cis.neustar.com> <20120816094139.A6C9433C0D0@merlin.blacknight.ie> <20120816102500.GR29229@nineve.blacknight.ie> <502D0F55.50909@centralnic.com> <502D147C.2030307@centralnic.com>, <20120816161401.GT29229@nineve.blacknight.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: iIrDxG9s75eKkCS4sP/mMg== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 To: "'Gould, James'" , Keith Gaughan , "provreg@ietf.org" Subject: Re: [provreg] Launch Phase EPP Extension Version 02 Posted X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 18:21:19 -0000 Jim, I agree with you and prefer option #3. What are your thoughts on the aucti= on related statuses that I sent out earlier? Trung -----Original Message----- From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On Behalf = Of Gould, James Sent: Thursday, August 16, 2012 6:18 PM To: Keith Gaughan; provreg@ietf.org Subject: Re: [provreg] Launch Phase EPP Extension Version 02 Posted In reviewing the thread on the status element of the draft, these are the f= ollowing options: 1. Keep the status element as a non-extensible enumerated list. =20 2. Change the status element to use a enumerated list of status values as a= n attribute and allow for the element text to be free-form. The free-form = text could be returned to the registrant. =20 3. Add an optional name attribute to the status element along with a "custo= m" status enumerated value to support sub-statuses or custom statuses simil= ar to the approach taken in the draft with the phase element. =20 4. Make the status element a token instead of a enumerated list. I don't b= elieve anyone really proposed this, but I left it in for completeness. =20 I would like to have all of the possible known statuses defined in the draf= t, where if we did a good job in gathering them all, option #1 is the best.= If we don't do a good job of gathering them all then some form of extensi= bility like option #3 would be needed to enable adding the missing statuses= without requiring the creation of a registry specific custom extension. I= believe option #2 is close to using the optional name attribute of option = #3 as a sub-status with a slightly different intent of not using the value = to drive client-side logic. =20 Does anyone know of any concrete statuses that need to be added to help wit= h options #1, #2, and #3? I don't want the draft to make it too difficult = for the clients to handle and I don't want it to be too restrictive to meet= specific registry policies that would result in the creation of additional= custom extensions. I believe option #3 is a good compromise, but that's p= robably obvious since I was the one that originally proposed it. =20 I would like to hear from the list if there are any additional options to c= onsider and which option is preferred. =20 Jim=20 ________________________________________ From: provreg-bounces@ietf.org [provreg-bounces@ietf.org] on behalf of Keit= h Gaughan [keith@blacknight.com] Sent: Thursday, August 16, 2012 12:14 PM To: provreg@ietf.org Subject: Re: [provreg] Launch Phase EPP Extension Version 02 Posted On Thu, Aug 16, 2012 at 04:40:44PM +0100, Gavin Brown wrote: > On 16/08/2012 16:35, Wil Tan wrote: > > Yes, that's why I said it's not elegant, but my (possibly wrong)=20 > > assumption was that the textual description won't be used by=20 > > registrars for automation. > > It seems more likely to me that registries would decide to overload=20 > this field and then compel registrars to create business logic to handle = it. > > However, I don't think that his has happened with the element=20 > for domains, contacts, and hosts (unless someone wants to correct me),=20 > so perhaps I am overstating the risks. What's happened in those cases is that the registry operators create their = own extensions to fit the extra semantics they--being the beautiful and uni= que snowflakes that they are--feel they absolutely can't possibly live with= out. You're not at all overstating the risks. The thing that gets missed in this= kind of discussion is that when a registry has discretion over the impleme= ntation of some element of EPP or a non-optional extension or object mappin= g, they effectively multiply the amount of work that needs to be done to im= plement that by the number of registrars integrated with them. The more tha= t can be done so that registrars don't have to implement dozens of subtly-i= ncompatible variations on the same spec. K. -- Keith Gaughan, Development Lead PGP/GPG key ID: 82AC3634 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 _______________________________________________ provreg mailing list provreg@ietf.org https://www.ietf.org/mailman/listinfo/provreg From JGould@verisign.com Fri Aug 17 12:26: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 BE03221F851C for ; Fri, 17 Aug 2012 12:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.474 X-Spam-Level: X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnbjzCli+ri7 for ; Fri, 17 Aug 2012 12:26:11 -0700 (PDT) Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by ietfa.amsl.com (Postfix) with ESMTP id CA12D21F8432 for ; Fri, 17 Aug 2012 12:26:03 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKUC6ay/eM6gabuwbsNUejJNVWQ9oEzutN@postini.com; Fri, 17 Aug 2012 12:26:11 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q7HJQ0RH010284 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Aug 2012 15:26:00 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Fri, 17 Aug 2012 15:26:00 -0400 From: "Gould, James" To: "Tran, Trung" , Keith Gaughan , "provreg@ietf.org" Thread-Topic: [provreg] Launch Phase EPP Extension Version 02 Posted Thread-Index: AQHNe5lkJJjhYFaphkGrGRzSIlyiJpdcVN5xgAB5YoCAAAJ1gIAABKoAgAABewCAAAlMgIAAHOHRgAE8XvCAACuTgA== Date: Fri, 17 Aug 2012 19:25:58 +0000 Message-ID: In-Reply-To: <82E430196867974ABF392D9B8BEAA53F5141CA3C@STNTEXCH02.cis.neustar.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <5C3F00937600134FAE462580F8B01643@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [provreg] Launch Phase EPP Extension Version 02 Posted X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 19:26:12 -0000 Tran, We must have been typing at the same time yesterday, since I got your e-mail with the auction statuses after sending my message. I recommend adding the pendingAuction status and merging the "auction awarded" status into the existing allocated status and the "auction rejected" status into the existing rejected status. The description of the pendingAuction status could be "application pending based on results of auction". The state transition section could add the optional pendingAuction status between the validated status and the rejected, allocated statuses. What do you think of this? Are there any other additional known statuses that we should add? -- =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 8/17/12 2:21 PM, "Tran, Trung" wrote: >Jim, >I agree with you and prefer option #3. What are your thoughts on the >auction related statuses that I sent out earlier? > >Trung > >-----Original Message----- >From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On >Behalf Of Gould, James >Sent: Thursday, August 16, 2012 6:18 PM >To: Keith Gaughan; provreg@ietf.org >Subject: Re: [provreg] Launch Phase EPP Extension Version 02 Posted > >In reviewing the thread on the status element of the draft, these are the >following options: > >1. Keep the status element as a non-extensible enumerated list. >2. Change the status element to use a enumerated list of status values as >an attribute and allow for the element text to be free-form. The >free-form text could be returned to the registrant. >3. Add an optional name attribute to the status element along with a >"custom" status enumerated value to support sub-statuses or custom >statuses similar to the approach taken in the draft with the phase >element. =20 >4. Make the status element a token instead of a enumerated list. I don't >believe anyone really proposed this, but I left it in for completeness. > >I would like to have all of the possible known statuses defined in the >draft, where if we did a good job in gathering them all, option #1 is the >best. If we don't do a good job of gathering them all then some form of >extensibility like option #3 would be needed to enable adding the missing >statuses without requiring the creation of a registry specific custom >extension. I believe option #2 is close to using the optional name >attribute of option #3 as a sub-status with a slightly different intent >of not using the value to drive client-side logic. > >Does anyone know of any concrete statuses that need to be added to help >with options #1, #2, and #3? I don't want the draft to make it too >difficult for the clients to handle and I don't want it to be too >restrictive to meet specific registry policies that would result in the >creation of additional custom extensions. I believe option #3 is a good >compromise, but that's probably obvious since I was the one that >originally proposed it. > >I would like to hear from the list if there are any additional options to >consider and which option is preferred. > >Jim=20 > >________________________________________ >From: provreg-bounces@ietf.org [provreg-bounces@ietf.org] on behalf of >Keith Gaughan [keith@blacknight.com] >Sent: Thursday, August 16, 2012 12:14 PM >To: provreg@ietf.org >Subject: Re: [provreg] Launch Phase EPP Extension Version 02 Posted > >On Thu, Aug 16, 2012 at 04:40:44PM +0100, Gavin Brown wrote: >> On 16/08/2012 16:35, Wil Tan wrote: >> > Yes, that's why I said it's not elegant, but my (possibly wrong) >> > assumption was that the textual description won't be used by >> > registrars for automation. >> >> It seems more likely to me that registries would decide to overload >> this field and then compel registrars to create business logic to >>handle it. >> >> However, I don't think that his has happened with the element >> for domains, contacts, and hosts (unless someone wants to correct me), >> so perhaps I am overstating the risks. > >What's happened in those cases is that the registry operators create >their own extensions to fit the extra semantics they--being the beautiful >and unique snowflakes that they are--feel they absolutely can't possibly >live without. > >You're not at all overstating the risks. The thing that gets missed in >this kind of discussion is that when a registry has discretion over the >implementation of some element of EPP or a non-optional extension or >object mapping, they effectively multiply the amount of work that needs >to be done to implement that by the number of registrars integrated with >them. The more that can be done so that registrars don't have to >implement dozens of subtly-incompatible variations on the same spec. > >K. > >-- >Keith Gaughan, Development Lead >PGP/GPG key ID: 82AC3634 >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 >_______________________________________________ >provreg mailing list >provreg@ietf.org >https://www.ietf.org/mailman/listinfo/provreg From trung.tran@neustar.biz Fri Aug 17 14:28: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 7693421E8063 for ; Fri, 17 Aug 2012 14:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.34 X-Spam-Level: X-Spam-Status: No, score=-6.34 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJPIuUFvUniF for ; Fri, 17 Aug 2012 14:28:54 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 3309921E8045 for ; Fri, 17 Aug 2012 14:28:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1345238689; x=1660596089; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=EbNR2vMrj4w8liOW3CMcR gsTgR/V1ocCq0BzNAg9420=; b=rrrL8Ex0dWm4lwTJYlwkoO9Oj6X/TZHiOgMPi i9tDLJ4RzSinWFEWxoOzlqRO6mAGexcg0roPRgrSDcgzvltRg== Received: from ([10.31.13.242]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.9998994; Fri, 17 Aug 2012 17:24:48 -0400 Received: from STNTEXCH02.cis.neustar.com ([fe80::28fd:d8c6:49f0:619b]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Fri, 17 Aug 2012 17:28:42 -0400 From: "Tran, Trung" Date: Fri, 17 Aug 2012 17:28:41 -0400 Thread-Topic: [provreg] Launch Phase EPP Extension Version 02 Posted Thread-Index: AQHNe5lkJJjhYFaphkGrGRzSIlyiJpdcVN5xgAB5YoCAAAJ1gIAABKoAgAABewCAAAlMgIAAHOHRgAE8XvCAACuTgIAAH3HQ Message-ID: <82E430196867974ABF392D9B8BEAA53F5141CA3E@STNTEXCH02.cis.neustar.com> References: <82E430196867974ABF392D9B8BEAA53F5141CA3C@STNTEXCH02.cis.neustar.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: dYYRZvO2No8tZbOU8Yi52Q== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 To: "'Gould, James'" , Keith Gaughan , "provreg@ietf.org" Subject: Re: [provreg] Launch Phase EPP Extension Version 02 Posted X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 21:28:55 -0000 Jim, Sounds good. I think that will work. There's no other status I can think of...at this time. Trung -----Original Message----- From: Gould, James [mailto:JGould@verisign.com]=20 Sent: Friday, August 17, 2012 3:26 PM To: Tran, Trung; Keith Gaughan; provreg@ietf.org Subject: Re: [provreg] Launch Phase EPP Extension Version 02 Posted Tran, We must have been typing at the same time yesterday, since I got your e-mai= l with the auction statuses after sending my message. I recommend adding the pendingAuction status and merging the "auction award= ed" status into the existing allocated status and the "auction rejected" st= atus into the existing rejected status. The description of the pendingAuct= ion status could be "application pending based on results of auction". The= state transition section could add the optional pendingAuction status betw= een the validated status and the rejected, allocated statuses. What do you= think of this? Are there any other additional known statuses that we should add? -- =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 8/17/12 2:21 PM, "Tran, Trung" wrote: >Jim, >I agree with you and prefer option #3. What are your thoughts on the=20 >auction related statuses that I sent out earlier? > >Trung > >-----Original Message----- >From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On=20 >Behalf Of Gould, James >Sent: Thursday, August 16, 2012 6:18 PM >To: Keith Gaughan; provreg@ietf.org >Subject: Re: [provreg] Launch Phase EPP Extension Version 02 Posted > >In reviewing the thread on the status element of the draft, these are=20 >the following options: > >1. Keep the status element as a non-extensible enumerated list. >2. Change the status element to use a enumerated list of status values=20 >as an attribute and allow for the element text to be free-form. The=20 >free-form text could be returned to the registrant. >3. Add an optional name attribute to the status element along with a=20 >"custom" status enumerated value to support sub-statuses or custom=20 >statuses similar to the approach taken in the draft with the phase=20 >element. >4. Make the status element a token instead of a enumerated list. I=20 >don't believe anyone really proposed this, but I left it in for completene= ss. > >I would like to have all of the possible known statuses defined in the=20 >draft, where if we did a good job in gathering them all, option #1 is=20 >the best. If we don't do a good job of gathering them all then some=20 >form of extensibility like option #3 would be needed to enable adding=20 >the missing statuses without requiring the creation of a registry=20 >specific custom extension. I believe option #2 is close to using the=20 >optional name attribute of option #3 as a sub-status with a slightly=20 >different intent of not using the value to drive client-side logic. > >Does anyone know of any concrete statuses that need to be added to help=20 >with options #1, #2, and #3? I don't want the draft to make it too=20 >difficult for the clients to handle and I don't want it to be too=20 >restrictive to meet specific registry policies that would result in the=20 >creation of additional custom extensions. I believe option #3 is a=20 >good compromise, but that's probably obvious since I was the one that=20 >originally proposed it. > >I would like to hear from the list if there are any additional options=20 >to consider and which option is preferred. > >Jim > >________________________________________ >From: provreg-bounces@ietf.org [provreg-bounces@ietf.org] on behalf of=20 >Keith Gaughan [keith@blacknight.com] >Sent: Thursday, August 16, 2012 12:14 PM >To: provreg@ietf.org >Subject: Re: [provreg] Launch Phase EPP Extension Version 02 Posted > >On Thu, Aug 16, 2012 at 04:40:44PM +0100, Gavin Brown wrote: >> On 16/08/2012 16:35, Wil Tan wrote: >> > Yes, that's why I said it's not elegant, but my (possibly wrong)=20 >> > assumption was that the textual description won't be used by=20 >> > registrars for automation. >> >> It seems more likely to me that registries would decide to overload =20 >>this field and then compel registrars to create business logic to=20 >>handle it. >> >> However, I don't think that his has happened with the =20 >> element for domains, contacts, and hosts (unless someone wants to=20 >> correct me), so perhaps I am overstating the risks. > >What's happened in those cases is that the registry operators create=20 >their own extensions to fit the extra semantics they--being the=20 >beautiful and unique snowflakes that they are--feel they absolutely=20 >can't possibly live without. > >You're not at all overstating the risks. The thing that gets missed in=20 >this kind of discussion is that when a registry has discretion over the=20 >implementation of some element of EPP or a non-optional extension or=20 >object mapping, they effectively multiply the amount of work that needs=20 >to be done to implement that by the number of registrars integrated=20 >with them. The more that can be done so that registrars don't have to=20 >implement dozens of subtly-incompatible variations on the same spec. > >K. > >-- >Keith Gaughan, Development Lead >PGP/GPG key ID: 82AC3634 >Blacknight Internet Solutions Ltd. 12A=20 >Barrowside Business Park, Carlow, Ireland Registered in Ireland,=20 >Company >No.: 370845 _______________________________________________ >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 shollenbeck@verisign.com Wed Aug 22 04:32: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 D262121F859E for ; Wed, 22 Aug 2012 04:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_LOAN=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJuDsR5QjfcE for ; Wed, 22 Aug 2012 04:32:12 -0700 (PDT) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by ietfa.amsl.com (Postfix) with ESMTP id B514C21F8575 for ; Wed, 22 Aug 2012 04:32:08 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKUDTDOBST/AqpB9YwxOltcoW+bmwm8h4B@postini.com; Wed, 22 Aug 2012 04:32:11 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q7MBW43x006408 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 22 Aug 2012 07:32:07 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Wed, 22 Aug 2012 07:32:04 -0400 From: "Hollenbeck, Scott" To: "provreg@ietf.org" Thread-Topic: [provreg] Standard Extensions Thread-Index: AQHM2vR/cKk19fHBuEeqynxZAXG/1pdm+HDw Date: Wed, 22 Aug 2012 11:32:04 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D664DB1@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 22 Aug 2012 11:32:12 -0000 It's been a long time since I started this thread back in January. Someone = recently asked me a question about an EPP extension, so I thought it wise t= o see if I could revisit the discussion and post a summary. Here's the orig= inal question: > Let's assume for a moment that we have enough interest to form a=20 > working group focused on the development of a set of standard EPP=20 > extensions. If we had to start writing a charter today, what=20 > functionality would people most like to see included? and here's a summary of the suggestions (my apologies if I missed any), inc= luding new efforts that have recently surfaced: 1. A garbage collection mechanism. 2. Extension for registrars to get registry/zone policy information. 3. Extension to provide account status information to registrars. 4. An IDN extension*. 5. A TLD launch extension*. 6. A trademark management extension*. 7. Standardized registry-to-registrar notifications. 8. An extension for VAT and/or tax ID information. 9. An extension for a legal/personal attribute on contact objects. 10. An extension for additional status value and/or result codes, perhaps w= ith an associated IANA registry. 11. An extension for cryptographic signatures. 12. An extension for delegation errors/warnings. Those that are described in a draft I've seen are marked with an asterisk. = IMHO twelve is probably too many to bootstrap a new working group. If we co= uld whittle this down to 6 or 7 AND we have actual drafts written for consi= deration it may be possible for us to get something going. Which of the above topics has been addressed in a draft? Who is willing to = write drafts for those topics that haven't yet been addressed? Scott From patrik@frobbit.se Wed Aug 22 04:36: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 E58C421F8683 for ; Wed, 22 Aug 2012 04:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.149 X-Spam-Level: X-Spam-Status: No, score=-101.149 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_LOAN=2.3, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRPati647p45 for ; Wed, 22 Aug 2012 04:36:57 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id DA16321F86A1 for ; Wed, 22 Aug 2012 04:36:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 0DCE914FD7443; Wed, 22 Aug 2012 13:36:55 +0200 (CEST) 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 ea0EsL9qkImh; Wed, 22 Aug 2012 13:36:49 +0200 (CEST) Received: from [IPv6:2a02:80:3ffc::12] (unknown [IPv6:2a02:80:3ffc::12]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 9A93714FD73AE; Wed, 22 Aug 2012 13:36:49 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 $1485$) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D664DB1@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Wed, 22 Aug 2012 13:36:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6495B102-D56C-43E0-9163-5CBDB7109840@frobbit.se> References: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F0D664DB1@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: "Hollenbeck, Scott" X-Mailer: Apple Mail (2.1485) 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, 22 Aug 2012 11:37:00 -0000 I think registries should first list whatever private extensions they = have, and see whether they can not be standardized. Do not increase the = number of extensions... Patrik 22 aug 2012 kl. 13:32 skrev "Hollenbeck, Scott" = : > It's been a long time since I started this thread back in January. = Someone recently asked me a question about an EPP extension, so I = thought it wise to see if I could revisit the discussion and post a = summary. Here's the original question: >=20 >> Let's assume for a moment that we have enough interest to form a=20 >> working group focused on the development of a set of standard EPP=20 >> extensions. If we had to start writing a charter today, what=20 >> functionality would people most like to see included? >=20 > and here's a summary of the suggestions (my apologies if I missed = any), including new efforts that have recently surfaced: >=20 > 1. A garbage collection mechanism. >=20 > 2. Extension for registrars to get registry/zone policy information. >=20 > 3. Extension to provide account status information to registrars. >=20 > 4. An IDN extension*. >=20 > 5. A TLD launch extension*. >=20 > 6. A trademark management extension*. >=20 > 7. Standardized registry-to-registrar notifications. >=20 > 8. An extension for VAT and/or tax ID information. >=20 > 9. An extension for a legal/personal attribute on contact objects. >=20 > 10. An extension for additional status value and/or result codes, = perhaps with an associated IANA registry. >=20 > 11. An extension for cryptographic signatures. >=20 > 12. An extension for delegation errors/warnings. >=20 > Those that are described in a draft I've seen are marked with an = asterisk. IMHO twelve is probably too many to bootstrap a new working = group. If we could whittle this down to 6 or 7 AND we have actual drafts = written for consideration it may be possible for us to get something = going. >=20 > Which of the above topics has been addressed in a draft? Who is = willing to write drafts for those topics that haven't yet been = addressed? >=20 > Scott > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg >=20 From shollenbeck@verisign.com Wed Aug 22 04:45: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 E03D421F8639 for ; Wed, 22 Aug 2012 04:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.171 X-Spam-Level: X-Spam-Status: No, score=-5.171 tagged_above=-999 required=5 tests=[AWL=-1.172, BAYES_00=-2.599, MANGLED_LOAN=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXNbT5pyTM4f for ; Wed, 22 Aug 2012 04:45:02 -0700 (PDT) Received: from exprod6og111.obsmtp.com (exprod6og111.obsmtp.com [64.18.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id F2EB121F861C for ; Wed, 22 Aug 2012 04:44:49 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob111.postini.com ([64.18.5.12]) with SMTP ID DSNKUDTGMT9KxXVvljsVRo86zn9rV7GDDXby@postini.com; Wed, 22 Aug 2012 04:44:52 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q7MBigRn006717 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Aug 2012 07:44:45 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Wed, 22 Aug 2012 07:44:41 -0400 From: "Hollenbeck, Scott" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Thread-Topic: [provreg] Standard Extensions Thread-Index: AQHM2vR/cKk19fHBuEeqynxZAXG/1pdm+HDwgABJioD//72UUA== Date: Wed, 22 Aug 2012 11:44:41 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D664E69@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F0D664DB1@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <6495B102-D56C-43E0-9163-5CBDB7109840@frobbit.se> In-Reply-To: <6495B102-D56C-43E0-9163-5CBDB7109840@frobbit.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 22 Aug 2012 11:45:07 -0000 At least one person did that, Patrik (and I inadvertently missed them when = compiling the list below): http://www.ietf.org/mail-archive/web/provreg/current/msg06776.html I didn't see any follow-up to the list provides by James. I believe that so= me of the items in the list below *are* implemented private extensions. Yes= , it would be helpful to identify those. Could you identify any extensions you've had to implement to work with diff= erent registries? Scott > -----Original Message----- > From: Patrik F=E4ltstr=F6m [mailto:patrik@frobbit.se] > Sent: Wednesday, August 22, 2012 7:37 AM > To: Hollenbeck, Scott > Cc: provreg@ietf.org > Subject: Re: [provreg] Standard Extensions >=20 > I think registries should first list whatever private extensions they > have, and see whether they can not be standardized. Do not increase the > number of extensions... >=20 > Patrik >=20 > 22 aug 2012 kl. 13:32 skrev "Hollenbeck, Scott" > : >=20 > > It's been a long time since I started this thread back in January. > Someone recently asked me a question about an EPP extension, so I > thought it wise to see if I could revisit the discussion and post a > summary. Here's the original question: > > > >> 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? > > > > and here's a summary of the suggestions (my apologies if I missed > any), including new efforts that have recently surfaced: > > > > 1. A garbage collection mechanism. > > > > 2. Extension for registrars to get registry/zone policy information. > > > > 3. Extension to provide account status information to registrars. > > > > 4. An IDN extension*. > > > > 5. A TLD launch extension*. > > > > 6. A trademark management extension*. > > > > 7. Standardized registry-to-registrar notifications. > > > > 8. An extension for VAT and/or tax ID information. > > > > 9. An extension for a legal/personal attribute on contact objects. > > > > 10. An extension for additional status value and/or result codes, > perhaps with an associated IANA registry. > > > > 11. An extension for cryptographic signatures. > > > > 12. An extension for delegation errors/warnings. > > > > Those that are described in a draft I've seen are marked with an > asterisk. IMHO twelve is probably too many to bootstrap a new working > group. If we could whittle this down to 6 or 7 AND we have actual > drafts written for consideration it may be possible for us to get > something going. > > > > Which of the above topics has been addressed in a draft? Who is > willing to write drafts for those topics that haven't yet been > addressed? > > > > Scott > > _______________________________________________ > > provreg mailing list > > provreg@ietf.org > > https://www.ietf.org/mailman/listinfo/provreg > > From patrik@frobbit.se Wed Aug 22 04:58: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 AE10821F8625 for ; Wed, 22 Aug 2012 04:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.766 X-Spam-Level: X-Spam-Status: No, score=-100.766 tagged_above=-999 required=5 tests=[AWL=-0.767, BAYES_00=-2.599, MANGLED_LOAN=2.3, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mu4-cTIXajxi for ; Wed, 22 Aug 2012 04:58:30 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 3615721F8624 for ; Wed, 22 Aug 2012 04:58:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id B3E5A14FDC6F3; Wed, 22 Aug 2012 13:58:27 +0200 (CEST) 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 lpvgnd4epAXG; Wed, 22 Aug 2012 13:58:17 +0200 (CEST) Received: from [IPv6:2a02:80:3ffc::12] (unknown [IPv6:2a02:80:3ffc::12]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 5460714FDC648; Wed, 22 Aug 2012 13:58:17 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.0 $1485$) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D664E69@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Wed, 22 Aug 2012 13:58:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <57F5CC66-8DF9-40A1-B771-9C8BC4E684C2@frobbit.se> References: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F0D664DB1@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <6495B102-D56C-43E0-9163-5CBDB7109840@frobbit.se> <831693C2CDA2E849A7D7A712B24E257F0D664E69@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: "Hollenbeck, Scott" X-Mailer: Apple Mail (2.1485) 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, 22 Aug 2012 11:58:35 -0000 22 aug 2012 kl. 13:44 skrev "Hollenbeck, Scott" = : > At least one person did that, Patrik (and I inadvertently missed them = when compiling the list below): >=20 > http://www.ietf.org/mail-archive/web/provreg/current/msg06776.html >=20 > I didn't see any follow-up to the list provides by James. I believe = that some of the items in the list below *are* implemented private = extensions. Yes, it would be helpful to identify those. >=20 > Could you identify any extensions you've had to implement to work with = different registries? If your question is "what where you forced to implement differently with = different registries" the answer is so far for me: - DNSSEC, clarification if DS or DNSKEY is to be passed to registry - Notifications (as you listed) - Deletion of domain names (before expiration) - Management of NS records when a transfer occurs - Management of dates for expiration, deactivation etc - Addition of personal or organisational number (i.e. identifier of the = registrant) - VAT information of registrant : : Let me phrase things differently. This list... http://search.cpan.org/~pmevzek/Net-DRI/ ...have too many entries. Make that 25% of what it is now, and you have success. I.e. OF COURSE I thing it is good if IETF work is starting on these = issues that you list, or else we will get even more extensions that are = specific per registry. What I am worried about is the lack of interest = from registries to try to minimize the number of extensions they have = that are private. Of course, many of these I have now implemented which implies that if = they change towards a standard, I have to change my code again :-P, but = I rather do that than continue to spend time on endless (as it seems) = specific implementations for specific registries. If there was ONE epp flavor to move towards. Patrik > Scott >=20 >> -----Original Message----- >> From: Patrik F=E4ltstr=F6m [mailto:patrik@frobbit.se] >> Sent: Wednesday, August 22, 2012 7:37 AM >> To: Hollenbeck, Scott >> Cc: provreg@ietf.org >> Subject: Re: [provreg] Standard Extensions >>=20 >> I think registries should first list whatever private extensions they >> have, and see whether they can not be standardized. Do not increase = the >> number of extensions... >>=20 >> Patrik >>=20 >> 22 aug 2012 kl. 13:32 skrev "Hollenbeck, Scott" >> : >>=20 >>> It's been a long time since I started this thread back in January. >> Someone recently asked me a question about an EPP extension, so I >> thought it wise to see if I could revisit the discussion and post a >> summary. Here's the original question: >>>=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 >>> and here's a summary of the suggestions (my apologies if I missed >> any), including new efforts that have recently surfaced: >>>=20 >>> 1. A garbage collection mechanism. >>>=20 >>> 2. Extension for registrars to get registry/zone policy information. >>>=20 >>> 3. Extension to provide account status information to registrars. >>>=20 >>> 4. An IDN extension*. >>>=20 >>> 5. A TLD launch extension*. >>>=20 >>> 6. A trademark management extension*. >>>=20 >>> 7. Standardized registry-to-registrar notifications. >>>=20 >>> 8. An extension for VAT and/or tax ID information. >>>=20 >>> 9. An extension for a legal/personal attribute on contact objects. >>>=20 >>> 10. An extension for additional status value and/or result codes, >> perhaps with an associated IANA registry. >>>=20 >>> 11. An extension for cryptographic signatures. >>>=20 >>> 12. An extension for delegation errors/warnings. >>>=20 >>> Those that are described in a draft I've seen are marked with an >> asterisk. IMHO twelve is probably too many to bootstrap a new working >> group. If we could whittle this down to 6 or 7 AND we have actual >> drafts written for consideration it may be possible for us to get >> something going. >>>=20 >>> Which of the above topics has been addressed in a draft? Who is >> willing to write drafts for those topics that haven't yet been >> addressed? >>>=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 Antoin.Verschuren@sidn.nl Wed Aug 22 05: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 6A04221F86BB for ; Wed, 22 Aug 2012 05:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20nILr2J-wMq for ; Wed, 22 Aug 2012 05:16:44 -0700 (PDT) Received: from kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by ietfa.amsl.com (Postfix) with ESMTP id BA50521F86A0 for ; Wed, 22 Aug 2012 05:16:44 -0700 (PDT) Received: from kahubcasn01.SIDN.local (unknown [192.168.2.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by kamx.sidn.nl (kamx.sidn.nl) with ESMTPS id 8E3C1FD7 for ; Wed, 22 Aug 2012 14:16:43 +0200 (CEST) Received: from KAHUBCAS1.SIDN.local (192.168.2.41) by kahubcasn01.SIDN.local (192.168.2.73) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 22 Aug 2012 14:16:33 +0200 Received: from [94.198.156.18] (94.198.156.18) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 22 Aug 2012 14:16:33 +0200 Message-ID: <5034CD9F.4050809@sidn.nl> Date: Wed, 22 Aug 2012 14:16:31 +0200 From: Antoin Verschuren User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: References: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F0D664DB1@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <6495B102-D56C-43E0-9163-5CBDB7109840@frobbit.se> <831693C2CDA2E849A7D7A712B24E257F0D664E69@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <57F5CC66-8DF9-40A1-B771-9C8BC4E684C2@frobbit.se> In-Reply-To: <57F5CC66-8DF9-40A1-B771-9C8BC4E684C2@frobbit.se> X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Originating-IP: [94.198.156.18] 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, 22 Aug 2012 12:16:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 22-08-12 13:58, Patrik F�ltstr�m wrote: > If your question is "what where you forced to implement differently > with different registries" the answer is so far for me: > > - DNSSEC, clarification if DS or DNSKEY is to be passed to > registry Apart from the DS/DNSKEY question for the delegation, there is also a request to have an EPP extension for registrars to send ZSK information (a KEY) to be relayed by the registry in case of a dns-operator change (http://tools.ietf.org/html/draft-koch-dnsop-dnssec-operator-change-04). As this is a rather new topic, after some registries made their initial decision to use DS in stead of DNSKEY, I think this might influence consensus on using DNSKEY. We actually need the "key to be relayed" as an EPP extension to facilitate automated DNSSEC secure transfers, and will implement it regardless of standardisation. But if it needs a request: We would like the "key to be relayed" as a standard EPP extension. It contains a KEY. - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren@sidn.nl xmpp:antoin@jabber.sidn.nl http://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJQNM2eAAoJEDqHrM883AgnYDAH/0Q/DtSrt4PPxxHGYM1CwwG9 9w79Vqp0t1K7H5bPaUUBF9uggzwxD341FPjqbRz2EJM9Djwj9L0WjqLZ7WmACH7U Lo4W7S1NvLlX3Vcw7VvCsfoqaPqOfV7nD0UlxqArMsN3aLR/m1EUJXnhqvMEZV96 r+VhxYSNjkLIoYRbyjXmzKPsTd2SmfzeUfqE5HheKk93OA7N+2m/ERNnzyCj2zHo RKS+arKJs+lRyNoNTdfgYKmvaconvFRhfREtWEXrlJJ8Kb2Srz4oP6MnqKNWQ41M Ifc2XTE24evxUSP4D+vxCVTFkYXcHjZUuoJocvI1BggQwwqS8S+dqNTgcar+Eds= =Jp+n -----END PGP SIGNATURE----- From zhoulinlin@cnnic.cn Wed Aug 22 21:03: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 C62B121F8501 for ; Wed, 22 Aug 2012 21:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[AWL=-1.099, BAYES_00=-2.599, MANGLED_LOAN=2.3, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hETesFoK3gr4 for ; Wed, 22 Aug 2012 21:03:09 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id A27FC21F84FB for ; Wed, 22 Aug 2012 21:03:02 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: zhoulinlin@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo95e6383c) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 23 Aug 2012 12:02:08 +0800 From: "Linlin Zhou" To: "'Hollenbeck, Scott'" , =?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?= References: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F0D664DB1@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <6495B102-D56C-43E0-9163-5CBDB7109840@frobbit.se> <831693C2CDA2E849A7D7A712B24E257F0D664E69@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D664E69@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Thu, 23 Aug 2012 12:02:06 +0800 Message-ID: <018501cd80e4$10396c70$30ac4550$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHM2vR/cKk19fHBuEeqynxZAXG/1pdm+HDwgABJioD//72UUIABB9sA Content-Language: zh-cn 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, 23 Aug 2012 04:03:09 -0000 Now we already had the draft-kong-epp-cdn-dnssec-mapping, which is the DNSSEC mapping for the provisioning and management of Chinese Domain = Names. We also want to do a DNSSEC extension for IDN based on the above draft. Regards, Linlin Zhou > -----Original Message----- > From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On = Behalf > Of Hollenbeck, Scott > Sent: Wednesday, August 22, 2012 7:45 PM > To: Patrik F=E4ltstr=F6m > Cc: provreg@ietf.org > Subject: Re: [provreg] Standard Extensions >=20 > At least one person did that, Patrik (and I inadvertently missed them = when > compiling the list below): >=20 > http://www.ietf.org/mail-archive/web/provreg/current/msg06776.html >=20 > I didn't see any follow-up to the list provides by James. I believe = that some of > the items in the list below *are* implemented private extensions. Yes, = it would > be helpful to identify those. >=20 > Could you identify any extensions you've had to implement to work with > different registries? >=20 > Scott >=20 > > -----Original Message----- > > From: Patrik F=E4ltstr=F6m [mailto:patrik@frobbit.se] > > Sent: Wednesday, August 22, 2012 7:37 AM > > To: Hollenbeck, Scott > > Cc: provreg@ietf.org > > Subject: Re: [provreg] Standard Extensions > > > > I think registries should first list whatever private extensions = they > > have, and see whether they can not be standardized. Do not increase > > the number of extensions... > > > > Patrik > > > > 22 aug 2012 kl. 13:32 skrev "Hollenbeck, Scott" > > : > > > > > It's been a long time since I started this thread back in January. > > Someone recently asked me a question about an EPP extension, so I > > thought it wise to see if I could revisit the discussion and post a > > summary. Here's the original question: > > > > > >> 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? > > > > > > and here's a summary of the suggestions (my apologies if I missed > > any), including new efforts that have recently surfaced: > > > > > > 1. A garbage collection mechanism. > > > > > > 2. Extension for registrars to get registry/zone policy = information. > > > > > > 3. Extension to provide account status information to registrars. > > > > > > 4. An IDN extension*. > > > > > > 5. A TLD launch extension*. > > > > > > 6. A trademark management extension*. > > > > > > 7. Standardized registry-to-registrar notifications. > > > > > > 8. An extension for VAT and/or tax ID information. > > > > > > 9. An extension for a legal/personal attribute on contact objects. > > > > > > 10. An extension for additional status value and/or result codes, > > perhaps with an associated IANA registry. > > > > > > 11. An extension for cryptographic signatures. > > > > > > 12. An extension for delegation errors/warnings. > > > > > > Those that are described in a draft I've seen are marked with an > > asterisk. IMHO twelve is probably too many to bootstrap a new = working > > group. If we could whittle this down to 6 or 7 AND we have actual > > drafts written for consideration it may be possible for us to get > > something going. > > > > > > Which of the above topics has been addressed in a draft? Who is > > willing to write drafts for those topics that haven't yet been > > addressed? > > > > > > Scott > > > _______________________________________________ > > > provreg mailing list > > > provreg@ietf.org > > > https://www.ietf.org/mailman/listinfo/provreg > > > >=20 > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg From xiejiagui@cnnic.cn Wed Aug 22 21:14: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 07B9521E8034 for ; Wed, 22 Aug 2012 21:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_LOAN=2.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 332oVo9mGvzQ for ; Wed, 22 Aug 2012 21:14:26 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id AE24911E808D for ; Wed, 22 Aug 2012 21:14:24 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: xiejiagui@cnnic.cn Received: from unknown218.241.111.81 (HELO [218.241.111.81]) (218.241.111.81) by 159.226.7.146 with SMTP; Thu, 23 Aug 2012 12:14:18 +0800 From: Kevin Tse To: Linlin Zhou In-Reply-To: <018501cd80e4$10396c70$30ac4550$@cn> References: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F0D664DB1@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <6495B102-D56C-43E0-9163-5CBDB7109840@frobbit.se> <831693C2CDA2E849A7D7A712B24E257F0D664E69@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <018501cd80e4$10396c70$30ac4550$@cn> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-4PUx2TsAjD7qN+01gAte" Organization: CNNIC Date: Thu, 23 Aug 2012 12:14:19 +0800 Message-ID: <1345695259.1615.23.camel@zenus> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: 'Patrik =?ISO-8859-1?Q?F=E4ltstr=F6m=27?= , provreg@ietf.org Subject: Re: [provreg] Standard Extensions X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: xiejiagui@cnnic.cn List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 04:14:27 -0000 --=-4PUx2TsAjD7qN+01gAte Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello all, We have several private extensions which are not summited as rfc drafts and some extensions which are summited as rfc drafts. Not summit: 1.Real information extension for the contact object. 2.Information for purveyor for both contact and domain objects. If you are interest in these, I'd like to share some information. RFC Draft: 1.CDN(chinese domain name) extension for the domain object;(draft-kong-epp-cdn-mapping) 2.CDN DNSSEC extension for the domain object;(draft-kong-epp-cdn-dnssec-mapping) 3.IDN extension for the domain object;(draft-kong-epp-idn-mapping) BTW,we have interest to form a working group focused on the development of a set of standard EPP extensions. Kind regards, --=20 Kevin Tse CNNIC On Thu, 2012-08-23 at 12:02 +0800, Linlin Zhou wrote: > Now we already had the draft-kong-epp-cdn-dnssec-mapping, which is the > DNSSEC mapping for the provisioning and management of Chinese Domain Name= s. > We also want to do a DNSSEC extension for IDN based on the above draft. >=20 > Regards, > Linlin Zhou >=20 > > -----Original Message----- > > From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On Beh= alf > > Of Hollenbeck, Scott > > Sent: Wednesday, August 22, 2012 7:45 PM > > To: Patrik F=C3=A4ltstr=C3=B6m > > Cc: provreg@ietf.org > > Subject: Re: [provreg] Standard Extensions > >=20 > > At least one person did that, Patrik (and I inadvertently missed them w= hen > > compiling the list below): > >=20 > > http://www.ietf.org/mail-archive/web/provreg/current/msg06776.html > >=20 > > I didn't see any follow-up to the list provides by James. I believe tha= t > some of > > the items in the list below *are* implemented private extensions. Yes, = it > would > > be helpful to identify those. > >=20 > > Could you identify any extensions you've had to implement to work with > > different registries? > >=20 > > Scott > >=20 > > > -----Original Message----- > > > From: Patrik F=C3=A4ltstr=C3=B6m [mailto:patrik@frobbit.se] > > > Sent: Wednesday, August 22, 2012 7:37 AM > > > To: Hollenbeck, Scott > > > Cc: provreg@ietf.org > > > Subject: Re: [provreg] Standard Extensions > > > > > > I think registries should first list whatever private extensions they > > > have, and see whether they can not be standardized. Do not increase > > > the number of extensions... > > > > > > Patrik > > > > > > 22 aug 2012 kl. 13:32 skrev "Hollenbeck, Scott" > > > : > > > > > > > It's been a long time since I started this thread back in January. > > > Someone recently asked me a question about an EPP extension, so I > > > thought it wise to see if I could revisit the discussion and post a > > > summary. Here's the original question: > > > > > > > >> 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? > > > > > > > > and here's a summary of the suggestions (my apologies if I missed > > > any), including new efforts that have recently surfaced: > > > > > > > > 1. A garbage collection mechanism. > > > > > > > > 2. Extension for registrars to get registry/zone policy information= . > > > > > > > > 3. Extension to provide account status information to registrars. > > > > > > > > 4. An IDN extension*. > > > > > > > > 5. A TLD launch extension*. > > > > > > > > 6. A trademark management extension*. > > > > > > > > 7. Standardized registry-to-registrar notifications. > > > > > > > > 8. An extension for VAT and/or tax ID information. > > > > > > > > 9. An extension for a legal/personal attribute on contact objects. > > > > > > > > 10. An extension for additional status value and/or result codes, > > > perhaps with an associated IANA registry. > > > > > > > > 11. An extension for cryptographic signatures. > > > > > > > > 12. An extension for delegation errors/warnings. > > > > > > > > Those that are described in a draft I've seen are marked with an > > > asterisk. IMHO twelve is probably too many to bootstrap a new working > > > group. If we could whittle this down to 6 or 7 AND we have actual > > > drafts written for consideration it may be possible for us to get > > > something going. > > > > > > > > Which of the above topics has been addressed in a draft? Who is > > > willing to write drafts for those topics that haven't yet been > > > addressed? > > > > > > > > Scott > > > > _______________________________________________ > > > > provreg mailing list > > > > provreg@ietf.org > > > > https://www.ietf.org/mailman/listinfo/provreg > > > > > >=20 > > _______________________________________________ > > provreg mailing list > > provreg@ietf.org > > https://www.ietf.org/mailman/listinfo/provreg >=20 > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg --=-4PUx2TsAjD7qN+01gAte Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iJwEAAECAAYFAlA1rhgACgkQatMoyEN1mK+sKgP/WrrPiNJwZ7lWOUwJGtXnBVF1 +YOu7vX4j5az1g57PmhMLjq/29WDG6s8X+EsfGuUGtGh6OTXln5OX6Tv6ipNoG55 NeaxdwuSAYYC8Y/arVhK2jwmAoKVXVv7/Wp6Kj8KcHXHmZVFb+Vmc8pRN4yEEjhL SGtU7Qh4kfX2J1KLtTI= =b9y0 -----END PGP SIGNATURE----- --=-4PUx2TsAjD7qN+01gAte-- From patrik@frobbit.se Wed Aug 22 22: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 675FA21F8413 for ; Wed, 22 Aug 2012 22:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.724 X-Spam-Level: X-Spam-Status: No, score=-101.724 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnuLMElwhgM6 for ; Wed, 22 Aug 2012 22:37:34 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id B857921F8514 for ; Wed, 22 Aug 2012 22:37:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id DD945150BD024; Thu, 23 Aug 2012 07:37:31 +0200 (CEST) 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 w3EgXDMaBJMz; Thu, 23 Aug 2012 07:37:31 +0200 (CEST) Received: from [192.168.1.63] (frobbit.cust.teleservice.net [85.30.128.225]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id AE63A150BD01C; Thu, 23 Aug 2012 07:37:31 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 $1485$) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <1345695259.1615.23.camel@zenus> Date: Thu, 23 Aug 2012 07:37:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <09E63EDE-2712-4DC9-8E69-E8F8C9CCEB0E@frobbit.se> References: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F0D664DB1@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <6495B102-D56C-43E0-9163-5CBDB7109840@frobbit.se> <831693C2CDA2E849A7D7A712B24E257F0D664E69@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <018501cd80e4$10396c70$30ac4550$@cn> <1345695259.1615.23.camel@zenus> To: xiejiagui@cnnic.cn X-Mailer: Apple Mail (2.1485) 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, 23 Aug 2012 05:37:39 -0000 On 23 aug 2012, at 06:14, Kevin Tse wrote: > We have several private extensions which are not summited as rfc > drafts and some extensions which are summited as rfc drafts. Btw, I do not as registrar care much whether extensions are RFCs or not, = but whether extensions are actually implemented by all(!) registries, = and whether I can communicate with a specific registry without = implementing the extensions that registry support. I already see registries that require extensions (compared to registries = that have features that are optional implemented as extensions) do not = end up being as popular among registrars as other registries. So, I want to see registries harmonize their implementations. Talk with = each other. Coordinate. Have someone say "we have a cool extension, but = we will not implement this before we have ten other registries also = agreeing to implementing it". Patrik From keith@blacknight.com Thu Aug 23 03:18: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 1A60B21F8581 for ; Thu, 23 Aug 2012 03:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.54 X-Spam-Level: X-Spam-Status: No, score=-1.54 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVpX2B0SXhy8 for ; Thu, 23 Aug 2012 03:18:11 -0700 (PDT) Received: from nineve.blacknight.ie (nineve.blacknight.ie [81.17.243.129]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCEB21F857E for ; Thu, 23 Aug 2012 03:18:10 -0700 (PDT) Received: by nineve.blacknight.ie (Postfix, from userid 1010) id 38DA95822D; Thu, 23 Aug 2012 11:18:09 +0100 (IST) Date: Thu, 23 Aug 2012 11:18:09 +0100 From: Keith Gaughan To: "provreg@ietf.org" Message-ID: <20120823101809.GO15704@nineve.blacknight.ie> References: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20120822113243.09FD033C35E@merlin.blacknight.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120822113243.09FD033C35E@merlin.blacknight.ie> User-Agent: Mutt/1.5.20 (2009-06-14) 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, 23 Aug 2012 10:18:12 -0000 On Wed, Aug 22, 2012 at 11:32:04AM +0000, Hollenbeck, Scott wrote: > It's been a long time since I started this thread back in January. Someone > recently asked me a question about an EPP extension, so I thought it wise to > see if I could revisit the discussion and post a summary. Here's the original > question: > > > 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? > > and here's a summary of the suggestions (my apologies if I missed any), > including new efforts that have recently surfaced: I'd like to add something to that. We've been talking to a ccTLD registry who are contemplating moving from their own proprietary protocol to EPP. One thing they'll need to do that is a ticket object mapping for managing pending domain applications and attaching documentation to those applications programmatically. It's early days, and thus a long-finger project currently, but it seems like the kind of thing that ought to be of general use, but of especial use to ccTLDs and sponsored gTLDs. > 1. A garbage collection mechanism. This is currently being worked on, though I haven't been able to get as much time to write up the initial I-D as I'd like. > 2. Extension for registrars to get registry/zone policy information. I think the consensus back when this was discussed was that it ought to be kept more-or-less independent of EPP. > 8. An extension for VAT and/or tax ID information. > > 9. An extension for a legal/personal attribute on contact objects. These can surely be merged? > Which of the above topics has been addressed in a draft? Who is willing to > write drafts for those topics that haven't yet been addressed? K. -- Keith Gaughan, Development Lead PGP/GPG key ID: 82AC3634 Blacknight Internet Solutions Ltd. 12A Barrowside Business Park, Carlow, Ireland Registered in Ireland, Company No.: 370845 From keith@blacknight.com Thu Aug 23 03:23: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 1F32D21F8456 for ; Thu, 23 Aug 2012 03:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9R3rhH3vA7nz for ; Thu, 23 Aug 2012 03:23:05 -0700 (PDT) Received: from nineve.blacknight.ie (nineve.blacknight.ie [81.17.243.129]) by ietfa.amsl.com (Postfix) with ESMTP id 6F36621F8447 for ; Thu, 23 Aug 2012 03:23:05 -0700 (PDT) Received: by nineve.blacknight.ie (Postfix, from userid 1010) id 16D665822D; Thu, 23 Aug 2012 11:23:03 +0100 (IST) Date: Thu, 23 Aug 2012 11:23:03 +0100 From: Keith Gaughan To: provreg@ietf.org Message-ID: <20120823102302.GP15704@nineve.blacknight.ie> References: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F0D664DB1@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <6495B102-D56C-43E0-9163-5CBDB7109840@frobbit.se> <831693C2CDA2E849A7D7A712B24E257F0D664E69@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <018501cd80e4$10396c70$30ac4550$@cn> <1345695259.1615.23.camel@zenus> <20120823053758.4B88533C362@merlin.blacknight.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20120823053758.4B88533C362@merlin.blacknight.ie> User-Agent: Mutt/1.5.20 (2009-06-14) 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, 23 Aug 2012 10:23:06 -0000 On Thu, Aug 23, 2012 at 07:37:30AM +0200, Patrik F�ltstr�m wrote: > On 23 aug 2012, at 06:14, Kevin Tse wrote: > > > We have several private extensions which are not summited as rfc drafts > > and some extensions which are summited as rfc drafts. > > So, I want to see registries harmonize their implementations. Talk with each > other. Coordinate. Have someone say "we have a cool extension, but we will not > implement this before we have ten other registries also agreeing to > implementing it". Agreed. From a registrar's perspective, the proliferation of registry 'quirks' is the single biggest source of headaches we have. -- Keith Gaughan, Development Lead PGP/GPG key ID: 82AC3634 Blacknight Internet Solutions Ltd. 12A Barrowside Business Park, Carlow, Ireland Registered in Ireland, Company No.: 370845 From guenther.mair@hoslo.ch Thu Aug 23 03:39: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 0949021F8610 for ; Thu, 23 Aug 2012 03:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6k5uSwtpWVU for ; Thu, 23 Aug 2012 03:39:40 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 07E2821F85AF for ; Thu, 23 Aug 2012 03:39:38 -0700 (PDT) Received: by wicr5 with SMTP id r5so634792wic.13 for ; Thu, 23 Aug 2012 03:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hoslo.ch; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=yyDH6jwYtz/R4jbFtnNzhZFHU2/qCWiWqGec9IOy9Kg=; b=bUjbS2tfvS9HkhqkhFxyYRECdkA354VP04BgdeVYE+BGQJvtv8QbMgDXm/dDcRF2N6 6I9gz4n2TXvMa0hFZ9kRgV0ovzhJWpLUKRTOeX1HyeSbl3xxuCmmKsIKM+rE/ueFV5gA Pn2M7h/SormXGvu4X0eQHD3tG9nAIVdAz9h8E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=yyDH6jwYtz/R4jbFtnNzhZFHU2/qCWiWqGec9IOy9Kg=; b=pSg9QAmdmYGB3dAzZvi0a/R/JmYAQ5va3JdwYcgYg5RUQrUkFP9pqGiKtHp0hq2WCz w5jXSxRSAc5z5HDPMGBz4VZZgWh0SPxkzcm4cJB22ZthUcYQzhQvvDjX0eMXyUChXuPX u7dPq52Ik1sUNeGVrrcJrinPntEOS3WZ5rDCWl51GiChUjfNSgzpOPT3SJWAuqUlmF4l UtRJaBcsHjJgKdRDHUmatXzmKFdkkt7Jfq5rV7n+LsKGObLV1nHfl5wSwEsBqz6eY6Pc TME8uXUveSXBwFnVW3RP41vWpqGkFLZqLv8zPCSRt2cQ2B0LxhRgg/pG/J6ycDlDmDE7 VHig== Received: by 10.180.19.169 with SMTP id g9mr13901919wie.9.1345718377813; Thu, 23 Aug 2012 03:39:37 -0700 (PDT) Received: from [192.168.1.2] (net-93-66-194-108.cust.dsl.vodafone.it. [93.66.194.108]) by mx.google.com with ESMTPS id h9sm44164361wiz.1.2012.08.23.03.39.35 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 23 Aug 2012 03:39:36 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_63999456-3FAA-4908-9987-27ADD9B6149F"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.0 $1485$) From: =?iso-8859-1?Q?G=FCnther_Mair?= In-Reply-To: <20120823102302.GP15704@nineve.blacknight.ie> Date: Thu, 23 Aug 2012 12:39:32 +0200 Message-Id: References: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F0D664DB1@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <6495B102-D56C-43E0-9163-5CBDB7109840@frobbit.se> <831693C2CDA2E849A7D7A712B24E257F0D664E69@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <018501cd80e4$10396c70$30ac4550$@cn> <1345695259.1615.23.camel@zenus> <20120823053758.4B88533C362@merlin.blacknight.ie> <20120823102302.GP15704@nineve.blacknight.ie> To: Keith Gaughan X-Mailer: Apple Mail (2.1485) X-Gm-Message-State: ALoCoQlubGzGYvBDQyILKRDid4kVXofPTuF6oup0sU+FYFIQ+uyVz5sGF/35DkZSRYy1YjCAUHj3 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, 23 Aug 2012 10:39:41 -0000 --Apple-Mail=_63999456-3FAA-4908-9987-27ADD9B6149F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 >> So, I want to see registries harmonize their implementations. Talk = with each >> other. Coordinate. Have someone say "we have a cool extension, but we = will not >> implement this before we have ten other registries also agreeing to >> implementing it". >=20 > Agreed. =46rom a registrar's perspective, the proliferation of = registry 'quirks' > is the single biggest source of headaches we have. Add me as one more registrar in this line-up. As Keith already suggested a few times (btw. I loved the one about "the = beautiful and unique snowflakes that they are") and Patrik confirmed, = the various registries behavior is a nightmare to us. Just think about the internet where every country had it's own "protocol = quirks" because of some "internal policies". But in the long term I hope it will be in the registries own best = interest to help standardize and then stick to the agreed upon standard. = Think about it the way Patrik explained. Regards G=FCnther= --Apple-Mail=_63999456-3FAA-4908-9987-27ADD9B6149F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINXDCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHIDCCBgig AwIBAgIDBJ8NMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTIwNzMxMjAyMDQxWhcNMTMwODAyMDU1NDI1WjBjMRkwFwYDVQQNExA1ODh6UjA2YU45dFVQckI4 MR8wHQYDVQQDDBZndWVudGhlci5tYWlyQGhvc2xvLmNoMSUwIwYJKoZIhvcNAQkBFhZndWVudGhl ci5tYWlyQGhvc2xvLmNoMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6g+CDJJFWgoy 1CI4ebXZm9JrXFKsMu6Ne48uRg++ZoZdqwZgDnCpKYqEMMxbby71242IhSyWuc5ZQrQcNOpApeCA ijFpA4JGBBlLLPtqREURStJB6TKeywEQ65OaGmXue0svF9Pu0C8iUv3J0UNWLQ28+267ws2aiSbQ bprVcqUeE3a2ACzUDKMIra0uPUZRPCob7zeak7wXNbeEtfU8ICALd9GptSv3CkD2cqJQOQ3LDpKq 2fiyBmU0nqmq/g1VUjBY70tGqFRjrwLlWcVdJtuRZLPENCLrK66ZouGCys6Xo78JLP/78NcJ1LN7 qvEN2YanDB0aW3JnS/ik6fCEsQIDAQABo4IDsTCCA60wCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBROxgHKumr2rOpVUyhlLmfa tgdcdTAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAhBgNVHREEGjAYgRZndWVudGhl ci5tYWlyQGhvc2xvLmNoMIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEW KGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHq MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmlj YXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWly ZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBp bnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdh dGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTADAgECGmRMaWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9u ICJMZWdhbCBhbmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1Ud HwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsG AQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xh c3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMv c3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wu Y29tLzANBgkqhkiG9w0BAQUFAAOCAQEAJEn3gGGpgWJYbr9gENaYEO9YTTDnnNOZs1KVboEMVSZn Qkk0gcayQQRclF+ofXvkTpjnfK1mggbsYtq3T08PQR8PREQMv4G2mVQhgv4hgU0MkP/Mytmivhmn ZWg3cuJi4c83LiiEASwLaL25ncTymaoCYrm2Es84lrHjuuW1sPYqezOLparQ12d79s9+k8eTJ+Tk tiBVAbibZq6FgeEl6mhcpJqlHnk0sSdlIDF5WsWKlORRlVBs/nK4SJaq0V0bH4wL1VZ+QRZfbYAn lih4u4XqBnN+li1rmX7vNjN3hSlGtvCgQe8Jq6DudcARWuSCw3Z0njLcw3hW0KEZIuBxmjGCA28w ggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwSfDTAJBgUrDgMCGgUAoIIB rzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA4MjMxMDM5MzNa MCMGCSqGSIb3DQEJBDEWBBRxVHmxYWZKLnVGmQFZrxjk9JmKITCBpQYJKwYBBAGCNxAEMYGXMIGU MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJl IERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQ cmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwSfDTCBpwYLKoZIhvcNAQkQAgsxgZeggZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBJ8NMA0GCSqGSIb3DQEBAQUABIIBAGFlCiPc xEbD7bRrS6XDacuVkVA9lryczftoxOADyc6BDn39akclbsLI4UEVky8S7gYy7uHoCaAM3Y/hWd7+ O1ouPIR5qk43mOxuRbFkEP/W/K/eIRnTz2Dmfnln3A1AAp/Zjb/kJdG9EUPvNywd9PtcEtk02j74 melex3a5CAK6n/84G5Y3mtkII+iSOuYuDvDvgL1K+pWqYEf8gic6cgZwClxE3Z6nRtwg4/oNi3xh GeGEAlO/opo4nLS5nlsrc0D6DyFb0zXG6IZhJPSLG4Ioth87kz+OwM8zXwDuZFW/2cb8qCPHCT/S 1f8TaPulbmLnRp5MAmmTS11C0pMq1L0AAAAAAAA= --Apple-Mail=_63999456-3FAA-4908-9987-27ADD9B6149F-- From shollenbeck@verisign.com Thu Aug 23 04:48: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 0F54A21F85AA for ; Thu, 23 Aug 2012 04:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.204 X-Spam-Level: X-Spam-Status: No, score=-6.204 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6625Nq6Viy72 for ; Thu, 23 Aug 2012 04:48:33 -0700 (PDT) Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by ietfa.amsl.com (Postfix) with ESMTP id E179F21F85A5 for ; Thu, 23 Aug 2012 04:48:31 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP ID DSNKUDYYj6L3n6MLLXneTkhHr50CvZQBGexT@postini.com; Thu, 23 Aug 2012 04:48:33 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q7NBmQ2r027407 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Aug 2012 07:48:27 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Thu, 23 Aug 2012 07:48:26 -0400 From: "Hollenbeck, Scott" To: =?iso-8859-1?Q?G=FCnther_Mair?= Thread-Topic: [provreg] Standard Extensions Thread-Index: AQHNgRlHcKk19fHBuEeqynxZAXG/1pdneAQA///PopA= Date: Thu, 23 Aug 2012 11:48:25 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D6656EE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F0D664DB1@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <6495B102-D56C-43E0-9163-5CBDB7109840@frobbit.se> <831693C2CDA2E849A7D7A712B24E257F0D664E69@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <018501cd80e4$10396c70$30ac4550$@cn> <1345695259.1615.23.camel@zenus> <20120823053758.4B88533C362@merlin.blacknight.ie> <20120823102302.GP15704@nineve.blacknight.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 23 Aug 2012 11:48:34 -0000 > -----Original Message----- > From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On > Behalf Of G=FCnther Mair > Sent: Thursday, August 23, 2012 6:40 AM > To: Keith Gaughan > Cc: provreg@ietf.org > Subject: Re: [provreg] Standard Extensions >=20 > >> So, I want to see registries harmonize their implementations. Talk > >> with each other. Coordinate. Have someone say "we have a cool > >> extension, but we will not implement this before we have ten other > >> registries also agreeing to implementing it". > > > > Agreed. From a registrar's perspective, the proliferation of registry > 'quirks' > > is the single biggest source of headaches we have. >=20 > Add me as one more registrar in this line-up. > As Keith already suggested a few times (btw. I loved the one about "the > beautiful and unique snowflakes that they are") and Patrik confirmed, > the various registries behavior is a nightmare to us. >=20 > Just think about the internet where every country had it's own > "protocol quirks" because of some "internal policies". > But in the long term I hope it will be in the registries own best > interest to help standardize and then stick to the agreed upon > standard. Think about it the way Patrik explained. Serious question: as a registrar, why do you do business with registries th= at give you nightmares? Scott From patrik@frobbit.se Thu Aug 23 04:59: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 936F621F85A2 for ; Thu, 23 Aug 2012 04:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQLUANtAtT31 for ; Thu, 23 Aug 2012 04:59:56 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id CE50621F8593 for ; Thu, 23 Aug 2012 04:59:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id BC6BB15112D2A; Thu, 23 Aug 2012 13:59:53 +0200 (CEST) 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 ka8ELwrQePU0; Thu, 23 Aug 2012 13:59:53 +0200 (CEST) Received: from junior.frobbit.se (unknown [192.165.72.12]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 8F5C515112D23; Thu, 23 Aug 2012 13:59:53 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.0 $1485$) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D6656EE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Thu, 23 Aug 2012 13:59:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <00D749BC-2DEB-4847-9BBC-BFE92A350D4F@frobbit.se> References: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F0D664DB1@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <6495B102-D56C-43E0-9163-5CBDB7109840@frobbit.se> <831693C2CDA2E849A7D7A712B24E257F0D664E69@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <018501cd80e4$10396c70$30ac4550$@cn> <1345695259.1615.23.camel@zenus> <20120823053758.4B88533C362@merlin.blacknight.ie> <20120823102302.GP15704@nineve.blacknight.ie> <831693C2CDA2E849A7D7A712B24E257F0D6656EE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: "Hollenbeck, Scott" X-Mailer: Apple Mail (2.1485) 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, 23 Aug 2012 11:59:56 -0000 On 23 aug 2012, at 13:48, "Hollenbeck, Scott" = wrote: > Serious question: as a registrar, why do you do business with = registries that give you nightmares? The first registry does not give me as a registrar nightmare. The 2nd = that differ from the first do. And the question is then, why do we work on implementing this 2nd = anyway? The simple answer is that our customers want us to be able to = manage all of their domains, in all of the TLDs of their choice. We can do it as registrars by either implementing epp for all of those = TLDs or by being a reseller to someone that did bite the bullet for the = problematic ones (or started with a different one). So, the reason why I think registrars like myself are a bit concerned is = I guess because we see that it is we (registrars) that have to take all = the cost (i.e. implementing epp) for the differences between two = registries. I.e. if registry A and registry B implement epp even the slightest = differently, that imposes a direct cost on the registrars that work with = A and B. A cost that is to be balanced against the potential extra = income we can get by using epp instead of being a reseller. If the differences in epp also imposed an extra cost on the registries, = so that there was an economical penalty on a registry to implement = something "different from other registries", then I think we might have = seen a different evolution of epp. Patrik From shollenbeck@verisign.com Thu Aug 23 05:08: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 7325521F855D for ; Thu, 23 Aug 2012 05:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.213 X-Spam-Level: X-Spam-Status: No, score=-6.213 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQ1DJEb0n5Mg for ; Thu, 23 Aug 2012 05:08:43 -0700 (PDT) Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2E821F84FC for ; Thu, 23 Aug 2012 05:08:40 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKUDYdR/x0J3bp5KPpxuuHgLOa4PdPYU8T@postini.com; Thu, 23 Aug 2012 05:08:42 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q7NC8Wwm027991 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Aug 2012 08:08:36 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Thu, 23 Aug 2012 08:08:32 -0400 From: "Hollenbeck, Scott" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Thread-Topic: [provreg] Standard Extensions Thread-Index: AQHNgRlHcKk19fHBuEeqynxZAXG/1pdneAQA///PopCAAEbKgP//vT2Q Date: Thu, 23 Aug 2012 12:08:31 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D66574D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F0D57D6E0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F0D664DB1@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <6495B102-D56C-43E0-9163-5CBDB7109840@frobbit.se> <831693C2CDA2E849A7D7A712B24E257F0D664E69@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <018501cd80e4$10396c70$30ac4550$@cn> <1345695259.1615.23.camel@zenus> <20120823053758.4B88533C362@merlin.blacknight.ie> <20120823102302.GP15704@nineve.blacknight.ie> <831693C2CDA2E849A7D7A712B24E257F0D6656EE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <00D749BC-2DEB-4847-9BBC-BFE92A350D4F@frobbit.se> In-Reply-To: <00D749BC-2DEB-4847-9BBC-BFE92A350D4F@frobbit.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: